Information Technology Reference
In-Depth Information
7.6.10 Coupling and Cohesion
Coupling measures the degree of independence and interaction between modules.
A module's independence results from its freedom from the modification of its
variables by other objects (Burch
1992
). Thus, if two modules have very little
interaction they are said to be loosely coupled. The opposite being tightly cou-
pled, or when two modules have a great level of interaction. When two modules
are tightly coupled they are said to be dependent on the other. Dependency causes
one module to be modified when the other is modified.
If two modules have no interaction then they would have no relationship. This,
however, is not relevant as it is only pertinent to realize coupling when it extends
to coexisting entities. The coupling to be concerned with is that of two modules
that interact. Good coupling is that of when two modules share data. Better cou-
pling results from smaller pieces of data. In general, the smaller and less complex
the data is, the looser the coupling.
The measure of how closely components are related is known as cohesion.
Cohesion, unlike coupling, is better the more of it that there is. There are several
forms of cohesion: coincidental, logical, temporal, procedural, communicational,
sequential and functional (Sommerville
2004
). Modules should be loosely cou-
pled, meaning they communicate by passing the most basic data available. Highly
cohesive means that they should maintain as many forms of cohesion with the
modules in the system.
7.7 Architectural System Design
Architecture, when concerning software concerns the implementation or design.
This is how you can name UNIX applications and client-server or embedded
systems as an architectural style. Similarly, these concepts when applied to design
can form multiple genres of design styles which can include Model Driven
Architecture, Service-Oriented Architecture, Object-oriented Architecture and the
like. All these methodologies have some things in common such as iteration and
implementation in small increments.
The architectural system design is used to reflect the system as planned and to
help flush out problems before implementation. A common model is typically used
for the platform on which a model is designed, though it is not necessarily con-
sistent due to the complexity of large system design. A system design model
consists of diagrams and text in some uniform notation. The model should contain
classes, interactions, and how these classes and interactions build a working sys-
tem. Schach describes a three step iterative and incremental system for class
design (Schach
2008
):
Step 1: The first step is functional model. This is where the scenarios are designed
using use case models.
