This tutorial is adapted from the Web Age course https://www.webagesolutions.com/courses/WA2325-solution-architect-training-sa-practitioner-s-guide-extended-.
1.1 Abstraction
- Abstraction enables you to recognize how things are similar and to ignore differences, to think in general terms and not in specifics.
- This simplifies the analysis by separating attributes that are relevant from those that are not.
Abstraction Mechanisms
Abstraction by parameterization abstracts from the identity of the data by replacing them with parameters. It generalizes modules so that they can be used in more situations.
Abstraction by specification abstracts from the implementation details (how the module is
implemented) to the behavior users can depend on (what the module does). It isolates modules from one another’s implementations; we require only that a module’s implementation supports the behavior being relied on.
Types of Abstraction
Procedural abstraction lets us think about a series of computational steps as an abstract unit. The product of procedural abstraction is a procedure. By separating procedure definition and invocation, a programming language makes two important methods of abstraction possible: abstraction by parameterization and abstraction by specification (see below).
Data abstraction lets us think about collections of data as abstract entities. the product of data abstraction is an abstract data type (ADT). This is useful for:
- Grouping related pieces of information.
- Defining and understanding what meaningful operations can be performed on the data.
- Enforcing certain restrictions on the use of the data.
- Simplifying the task of reasoning about the data.
- Separating the implementation from the abstraction itself, so we can change the internal representation and/or implementation without changing the abstract behavior, and so people can use the abstraction without needing to understand the internal implementation.
Iteration abstraction allows us to iterate over items in a collection without revealing details of how the items are obtained. Also known as control abstraction.
1.2 Coupling
- Some exchange of data between modules is required and this makes themodules interdependent on one another.
- The extent to which modules are interdependent is called coupling.
- The greater the coupling than any modification done in one module will require changes in the other.
- If modules are highly coupled, the modification & debugging is harder.
- Well-designed software should have low coupling.
Coupling Types
| Type | Description |
| Data coupling: | Necessary exchange of data elements between modules. |
| Stamp coupling | Data are passed in the form of data structures or records. Exchange of data structures instead of data elements tend to make the system more complicated. |
| Control coupling | When one module passes a piece of data or signal to control the action of another module. The control information tells the recipient module what actions it should perform. |
| Common coupling | When two modules refer to the same global data area. The level of the module interdependence becomes quite high in such cases. |
| Content coupling | Involves one module directly referring to the inner workings of another module. Statement coded into another module. Modules are tightly intertwined. |
1.3 Cohesion
In a good design, all instructions in a module relates to a single function. The extent to which
the instructions of a module contribute to performing a single unified task is called
cohesion. There are multiple types of cohesion, but Functional Cohesion is the most desirable
type. A functionally cohesive module is when all instructions contained in the module pertain to a single task or function. A good design must maintain the right balance in achieving a high level of cohesion and minimum coupling.
| Type | Description |
| Functional Cohesion | If an aspect of a design can be achieved using a functionally cohesive module then it is normally best to do so. |
| Layer Cohesion | Layer cohesion should typically have higher priority. Dividing systems into layers has been shown to considerably simplify systems. |
| Communication Cohesion | Communicational cohesion, as embodied in the classes of an object-oriented system, should have high priority. Here we list it below layer cohesion since modules may access the same kind of data in different layers. |
| Sequential Cohesion | Sequential cohesion is effectively a strong form of temporal cohesion, but is weaker than communicational cohesion since different data types may be involved in the different stages of a sequentially cohesive module. |
| Temporal Cohesion | Temporal cohesion should typically be considered weaker than other types of cohesion. It is important, but only if the other types of cohesion have been achieved. |
| Utility Cohesion | Utility cohesion is the weakest kind of cohesion since it serves to group together those parts of the system that do not seem to logically belong anywhere else. |
1.4 Decomposition & Modularization
When you modularize a design, you are defining a decomposition of your design into units that are more readily maintained, managed, and tuned.
The diagram illustrates the decomposition of:
Value Chain to
• Business Process to
• Process to
• Sub-Process to
• Sub-Sub-Process to
• Activity to
• Procedure to
• Steps
