Component-Level Design Guidelines | Cohesion | Coupling

Component-Level Design Guidelines

• Introduction : 
• In addition to the principles , a set of pragmatic (Practical) design guidelines can be applied as component-level design proceeds. 
• These guidelines apply to 
• Components, 
• Interfaces 
• Dependencies and inheritance 
• Components 
• Naming conventions should be established for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model
• Interfaces 
• Interfaces provide important information about communication and collaboration.
• Dependencies and Inheritance 
• it is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes).

Cohesion

• Introduction : As per context of component-level design for 
• Conventional view:
• the “single-mindedness” of a module
• OO view (Object Oriented View):
• cohesion implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself
• Levels of cohesion OR different types of cohesion
• Functional
• Layer
• Communicational

(1) Functional

• Exhibited primarily by operations, this level of cohesion occurs when a component performs a targeted computation and then returns a result.

(2) Layer

• Exhibited by packages, components, and classes, this type of cohesion occurs when a higher layer accesses the services of a lower layer, but lower layers do not access higher layers.
• For example, the SafeHome security function requirement to make an outgoing phone call if an alarm is sensed. It might be possible to define a set of layered packages as shown in Figure.

(3) Communicational

• All operations that access the same data are defined within one class. In general, such classes focus only on the data for accessing and storing it.
• Classes and components that exhibit functional, layer, and communicational cohesion are relatively easy to implement, test, and maintain.
• It is important to note, however, that pragmatic (Practical) design and implementation issues sometimes force you to opt for lower levels of cohesion.

Coupling

• As per 
• Conventional view coupling is : 
• The degree to which a component is connected to other components and to the external world 
• OO view coupling is :
• A qualitative measure of the degree to which classes are connected to one another 
• As classes (and components) become more interdependent, coupling increases. An important objective in component-level design is to keep coupling as low as is possible. 
• Coupling categories  OR Level of coupling 
• Content Coupling 
• Common coupling 
• Control coupling 
• Stamp coupling 
• Data coupling 
• Routine call coupling 
• Type use coupling 
• Inclusion or import coupling 
• External coupling
• Content Coupling 
• It occurs when one component “secretly modifies data that is internal to another component” 
• This violates information hiding—a basic design concept.
• Common coupling 
• It Occurs when a number of components all make use of a global variable. 
• Although this is sometimes necessary (e.g., for establishing default values that are applicable throughout an application)
• Control coupling 
• It Occurs when operation A() invokes operation B() and passes a control flag to B. The control flag then “directs” logical flow within B. 
• Stamp coupling
• It Occurs when ClassB is declared as a type for an argument of an operation of ClassA. Because ClassB is now a part of the definition of ClassA, modifying the system becomes more complex.
• Data coupling
• It Occurs when operations pass long strings of data arguments.
• The “bandwidth” of communication between classes and components grows and the complexity of the interface increases. 
• Testing and maintenance are more difficult. 
• Routine call coupling 
• It Occurs when one operation invokes another.
• This level of coupling is common and is often quite necessary. 
• However, it does increase the connectedness of a system.
• Type use coupling 
• It Occurs, when component A uses a data type defined in component B (e.g., this occurs whenever “a class declares an instance variable or a local variable as having another class for its type”.
• If the type definition changes, every component that uses the definition must also change.
• Inclusion or import coupling
• It  Occurs when component A imports or includes a package or the content of component B. 
• External coupling 
• It Occurs when a component communicates or collaborates with infrastructure components (e.g., operating system functions, database capability, telecommunication functions).
• Although this type of coupling is necessary, it should be limited to a small number of components or classes within a system.