1. Pedro Mejia Alvarez CINVESTAV-PN
Component Design
Pedro Mejia Alvarez
CINVESTAV-PN

2. Main Contents Basic design principles
What is component design
Basic design principles
Modularity and Information hiding
Component design process

3. 1. What is component design ——What is a Component?
OMG Unified Modeling Language Specification [OMG01] defines a component as
“… a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”
OO view: a component contains a set of collaborating classes
Conventional view: logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it.

4. 1. What is component design —— OO Component

5. 1. What is component design —— Conventional Component

6. 2. Basic Design Principles
Class Design Principles
Package Design Principles
Package Coupling Principles

7. 2. Basic Design Principles ——Class Design Principles
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
a.k.a. Design by Contract
Dependency Inversion Principle (DIP)
Interface Segregation Principle (ISP)

8. 2. Basic Design Principles —— Single Responsibility Principle (SRP)
A class should have only one reason to change
Robert Martin
Related to and derived from cohesion, i.e. that elements
in a module should be closely related in their function
Responsibility of a class to perform a certain function
is also a reason for the class to change

9. 2. Basic Design Principles —— SRP Example
All-in-one wonder
Separated responsibilities
Always changes to 4vector
Changes to rotations or boosts
don't impact on 4vector

10. 2. Basic Design Principles —— SRP Summary
Class should have only one reason to change
Cohesion of its functions/responsibilities
Several responsibilities
mean several reasons for changes → more frequent changes
Sounds simple enough
Not so easy in real life
Tradeoffs with complexity, repetition, opacity

11. 2. Basic Design Principles —— Open/Closed Principle (OCP)
Modules should be open for extension,
but closed for modification
Bertrand Meyer
Object Oriented Software Construction
Module: Class, Package, Function
New functionality → new code, existing code remains unchanged
"Abstraction is the key" →
cast algorithms in abstract interfaces develop concrete implementations as needed

12. 2. Basic Design Principles —— Abstraction and OCP
Client is closed to changes
in implementation of Server
Client is open for extension
through new Server
implementations
Without AbsServer the Client
is open to changes in Server

13. 2. Basic Design Principles —— Liskov Substitution Principle (LSP)
All derived classes must be substituteable
for their base class
Barbara Liskov, 1988
The "Design-by-Contract" formulation:
All derived classes must honor the contracts
of their base classes
Bertrand Meyer

14. 2. Basic Design Principles —— LSP: The Square-Rectangle Problem
Clients (users) of Rectangle expect
that setting height leaves width
unchanged (and vice versa)
Square does not fulfill this expectation
Client algorithms can get confused

15. 2. Basic Design Principles —— Dependency Inversion Principle (DIP)
Details should depend on abstractions.
Abstractions should not depend on details.
Robert Martin
Why dependency inversion? In OO we have ways to
invert the direction of dependencies, i.e. class inheritance
and object polymorphism

16. 2. Basic Design Principles —— DIP Example
Dependency changed from
concrete to abstract ...
The abstract class
is unlikey to change
... at the price of a dependency
here, but it is on an abstraction.
Somewhere a dependency on
concrete Server must exist,
but we get to choose where.

17. 2. Basic Design Principles —— DIP and Procedural Design
Call more concrete routines
Dependence on (reuseable)
concrete modules
In reality the dependencies are
cyclic → need multipass link and
a "dummy library"
The BaBar Framework classes
depend on interfaces
Can e.g. change data store
technology without disturbing
the Framework classes

18. 2. Basic Design Principles —— ISP Explained
Multipurpose classes
Methods fall in different groups
Not all users use all methods
Can lead to unwanted dependencies
Clients using one aspect of a class also depend indirectly on the dependencies of the other aspects
ISP helps to solve the problem
Use several client-specific interfaces

19. 2. Basic Design Principles —— ISP Example: UIs
The Server "collects" interfaces
New UI → Server interface changes
All other UIs recompile
UIs are isolated from each other
Can add a UI with changes in
Server → other UIs not affected

20. 2. Basic Design Principles —— Three Package Design Principles
Reuse-Release Equivalency Principle
Common Closure Principle
Common Reuse Principle

21. 2. Basic Design Principles —— Reuse-Release Equivalency Principle (REP)
The unit of reuse is the unit of release
Bob Martin
It is about reusing software
Reuseable software is external software,
you use it but somebody else maintains it.
There is no difference between commercial
and non-commercial external software for reuse.

22. 2. Basic Design Principles —— REP Summary
Group components (classes) for reusers
Single classes are usually not reuseable
Several collaborating classes make up a package
Classes in a package should form a reuseable and releaseable module
Module provides coherent functionality
Dependencies on other packages controlled
Requirements on other packages specified
Reduces work for the reuser

23. 2. Basic Design Principles —— Common Closure Principle (CCP)
Classes which change together belong together
Bob Martin
Minimise the impact of change for the programmer.
When a change is needed, it is good for the programmer
if the change affects as few packages as possible, because
of compile and link time and revalidation

24. 2. Basic Design Principles —— CCP Summary
Group classes with similar closure together
package closed for anticipated changes
Confines changes to a few packages
Reduces package release frequency
Reduces work for the programmer

25. 2. Basic Design Principles —— Commom Reuse Principle (CRP)
Classes in packages should be reused together
Bob Martin
Packages should be focused, users should
use all classes from a package
CRP for packages is analogous to SRP for classes

26. 2. Basic Design Principles —— CRP Summary
Group classes according to common reuse
avoid unneccessary dependencies for users
Following the CRP often leads to splitting packages
Get more, smaller and more focused packages
Reduces work for the reuser

27. 2. Basic Design Principles —— Three more package design principles
Acyclic Dependencies principles
Stable Dependencies principles
Stable Abstractions principles

28. 2. Basic Design Principles —— The Acyclic Dependencies Principle (ACP)
The dependency structure for packages must be
a Directed Acyclic Graph (DAG)
Stabilise and release a project in pieces
Avoid interfering developers  Morning after syndrome
Organise package dependencies in a top-down hierarchy

29. 2. Basic Design Principles —— Dependencies are a DAG
It may look complicated,
but it is a DAG (Directed
Acyclic Graph)
Can exchange
ObjyIO and RootIO

30. 2. Basic Design Principles —— Dependency Cycles
A cycle between Framework
and ObjyIO
Must develop together
May need multipass link

31. 2. Basic Design Principles ——Stable Dependencies Principle (SDP)
Dependencies should point in the direction of stability
Robert Martin
Stability: corresponds to effort required to change a package
stable package  hard to change within the project
Stability can be quantified

32. 2. Basic Design Principles —— SDP Example
Bad
Good
A is responsible
for B, C and D.
It depends on E,
→ irresponsible
A is responsible for
B, C, D and E. It will
be hard to change
E depends on
F, G and H. A
depends on it. E
is responsible and
irresponsible.
E depends on A,
F, G and H. It is
irresponsible and
will be easy to
modify.

33. 2. Basic Design Principles —— SDP Summary
Organise package dependencies in the direction of stability
Dependence on stable packages corresponds to DIP for classes
Classes should depend upon (stable) abstractions or interfaces
These can be stable (hard to change)

34. 2. Basic Design Principles —— Stable Abstractions Principle (SAP)
Stable packages should be abstract packages.
Unstable packages should be concrete packages.
Robert Martin
Stable packages contain high level design. Making them
abstract opens them for extension but closes them for
modifications (OCP). Some flexibility is left in the stable
hard-to-change packages.

35. 3. Modularity and Information hiding ——Modularity
Computer systems are not monolithic:
they are usually composed of multiple, interacting modules.
Modularity has long been seen as a key to cheap, high quality software.
The goal of system design is to decide:
– what the modules are;
– what the modules should be;
– how the modules interact with one-another.

36. 3. Modularity and Information hiding —— What is a module?
Common view: a piece of code. Too limited.
Compilation unit, including related declarations and interface
David Parnas: a unit of work.
Collection of programming units (procedures, classes, etc.)
with a well-defined interface and purpose within the entire system,
that can be independently assigned to a developer

37. 3.Modularity and Information hiding —— Why modularize a system?
Management: Partition the overall development effort
– Divide and conquer
Evolution: Decouple parts of a system so that changes to one part are isolated from changes to other parts
Principle of directness (clear allocation of requirements to modules, ideally one requirement (or more) maps to one module)
– Principle of continuity/locality (small change in requirements triggers a change to one module only)
Understanding: Permit system to be understood
as composition of mind-sized chunks, e.g., the 7±2 Rule
with one issue at a time, e.g., principles of locality, encapsulation, separation of concerns
Key issue: what criteria to use for modularization?

38. 3. Modularity and Information hiding —— Information hiding
Hide secrets. OK, what’s a “secret”?
Representation of data
Properties of a device, other than required properties
Implementation of world models
Mechanisms that support policies
Try to localize future change
Hide system details likely to change independently
Separate parts that are likely to have a different rate of change
Expose in interfaces assumptions unlikely to change

39. 3. Modularity and Information hiding —— Interface vs. Implementation
Users and implementers of a module have different views of it.
Interface: user’s view of a module.
describes only what a user needs to know to use the module
makes it easier to understand and use
describes what services the module provides, but not how it’s able to provide them

40. 3. Modularity and Information hiding —— What Is an Interface?
Interface as a contract - whatever is published by a module that
Provided interface: clients of the module can depend on and
Required interface: the module can depend on from other modules
Syntactic interfaces
How to call operations
List of operation signatures
Sometimes also valid orders of calling operations
Semantic interfaces
What the operations do, e.g.,
Pre- and post-conditions
Use cases

41. 3. Modularity and Information hiding —— Further Principles
Explicit interfaces
Make all dependencies between modules explicit (no hidden coupling)
Low coupling - few interfaces
Minimize the amount of dependencies between modules
Small interfaces
Keep the interfaces narrow
Combine many parameters into structs/objects
Divide large interfaces into several interfaces
High cohesion
A module should encapsulate some well-defined, coherent piece of functionality (more on that later)

42. 3. Modularity and Information hiding —— Coupling and Cohesion
Cohesion is a measure of the coherence of a module amongst the pieces of that module.
Coupling is the degree of interaction between modules.
You want high cohesion and low coupling.

43. 3. Modularity and Information hiding —— Degrees of Cohesion

44. 3. Modularity and Information hiding —— Coincidental cohesion
The result of randomly breaking the project into modules to gain the benefits of having multiple smaller files/modules to work on
Inflexible enforcement of rules such as: “every function/module shall be between 40 and 80 lines in length” can result in coincidental coherence
Usually worse than no modularization
Confuses the reader that may infer dependencies that are not there

45. 3. Modularity and Information hiding —— Logical cohesion
A “template” implementation of a number of quite different operations that share some basic course of action
variation is achieved through parameters
“logic” - here: the internal workings of a module
Problems:
Results in hard to understand modules with complicated logic
Undesirable coupling between operations
Usually should be refactored to separate the different operations

46. 3. Modularity and Information hiding —— Example of Logical Cohesion

47. 3. Modularity and Information hiding —— Temporal Cohesion
Temporal cohesion concerns a module organized to contain all those operations which occur at a similar point in time.
Consider a product performing the following major steps:
Initialization, get user input, run calculations, perform appropriate output, cleanup.
Temporal cohesion would lead to five modules named initialize, input, calculate, output and cleanup.
This division will most probably lead to code duplication across the modules, e.g.,
Each module may have code that manipulates one of the major data structures used in the program.

48. 3. Modularity and Information hiding —— Procedural Cohesion
A module has procedural cohesion if all the operations it performs are related to a sequence of steps performed in the program.
For example, if one of the sequence of operations in the program was “read input from the keyboard, validate it, and store the answers in global variables”, that would be procedural cohesion.
Procedural cohesion is essentially temporal cohesion with the added restriction that all the parts of the module correspond to a related action sequence in the program.
It also leads to code duplication in a similar way.

49. 3. Modularity and Information hiding —— Procedural Cohesion

50. 3. Modularity and Information hiding —— Communicational Cohesion
Communicational cohesion occurs when a module performs operations related to a sequence of steps performed in the program (see procedural cohesion) AND all the actions performed by the module are performed on the same data.
Communicational cohesion is an improvement on procedural cohesion because all the operations are performed on the same data.

51. 3. Modularity and Information hiding —— Functional Cohesion
Module with functional cohesion focuses on exactly one goal or “function”
(In the sense of purpose, not a programming language “function”).
Module performing a well-defined operation is more reusable, e.g.,
Modules such as: read_file, or draw_graph are more likely to be applicable to another project than one called initialize_data.
Another advantage of is fault isolation, e.g.,
If the data is not being read from the file correctly, there is a good chance the error lies in the read_file module/function.

52. 3. Modularity and Information hiding —— Informational Cohesion
Informational cohesion describes a module as performing a number of actions, each with a unique entry point, independent code for each action, and all operations are performed on the same data.
In informational cohesion, each function in a module can perform exactly one action.
It corresponds to the definition of an ADT (abstract data type) or object in an object-oriented language.
Thus, the object-oriented approach naturally produces designs with informational cohesion.
Each object is generally defined in its own source file/module, and all the data definitions and member functions of that object are defined inside that source file

53. 3. Modularity and Information hiding —— Levels of Coupling

54. 3. Modularity and Information hiding —— Content Coupling
One module directly refers to the content of the other
module 1 modifies a statement of module 2
Assembly languages typically supported this, but not high-level languages
COBOL, at one time, had a verb called alter which could also create self-modifying code (it could directly change an instruction of some module).
module 1 refers to local data of module 2 in terms of some kind of offset into the start of module 2.
This is not a case of knowing the offset of an array entry - this is a direct offset from the start of module 2's data or code section.
module 1 branches to a local label contained in module 2.
This is not the same as calling a function inside module 2 - this is a goto to a label contained somewhere inside module 2.

55. 3. Modularity and Information hiding —— Common Coupling
Common coupling exists when two or more modules have read and write access to the same global data.
Common coupling is problematic in several areas of design/maintenance.
Code becomes hard to understand - need to know all places in all modules where a global variable gets modified
Hampered reusability because of hidden dependencies through global variables
Possible security breaches (an unauthorized access to a global variable with sensitive information)
It’s ok if just one module is writing the global data and all other modules have read-only access to it.

56. 3. Modularity and Information hiding —— Common Coupling
Sometimes necessary, if a lot of data has to be supplied to each module

57. 3. Modularity and Information hiding —— Control Coupling
Two modules are control-coupled if module 1 can directly affect the execution of module 2, e.g.,
module 1 passes a “control parameter” to module 2 with logical cohesion, or
the return code from a module 2 indicates NOT ONLY success or failure, but also implies some action to be taken on the part of the calling module 1 (such as writing an error message in the case of failure).
The biggest problem is in the area of code re-use: the two modules are not independent if they are control coupled.

58. 3. Modularity and Information hiding —— Stamp Coupling
It is a case of passing more than the required data values into a module, e.g.,
Passing an entire employee record into a function that prints a mailing label for that employee. (The data fields required to print the mailing label are name and address. There is no need for the salary, SIN number, etc.)
Making the module depend on the names of data fields in the employee record hinders portability.
If instead, the four or five values needed are passed in as parameters, this module can probably become quite reusable for other projects.
As with common coupling, leaving too much information exposed can be dangerous.

59. 3. Modularity and Information hiding —— Data Coupling
Data coupling exhibits the properties that all parameters to a module are either simple data types, or in the case of a record being passed as a parameter, all data members of that record are used/required by the module. That is, no extra information is passed to a module at any time

60. 3. Modularity and Information hiding —— Others Coupling
Routine call
increases connectedness of a system
Type use
use in ClassA types from ClassB (complex modifications)
Inclusion or import
occurs when CompA incs./imports CompB
External
occurs when calling OS system calls, DBMS services, etc.

61. 4. Component design process ——Component Level Design-I
Step 1. Identify all design classes that correspond to the problem domain.
Step 2. Identify all design classes that correspond to the infrastructure domain.
Step 3. Elaborate all design classes that are not acquired as reusable components.
Step 3a. Specify message details when classes or component collaborate.
Step 3b. Identify appropriate interfaces for each component.
Step 3c. Elaborate attributes and define data types and data structures required to implement them.
Step 3d. Describe processing flow within each operation in detail.

62. 4. Component design process —— Component-Level Design-II
Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage them.
Step 5. Develop and elaborate behavioral representations for a class or component.
Step 6. Elaborate deployment diagrams to provide additional implementation detail.
Step 7. Factor every component-level design representation and always consider alternatives.