Introduction to (software) design

Abstraction

Abstraction is an essential principle used by designers to deal with complexity. This strategy recommends representing an element only by its “essential characteristics that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries relative to the perspective of the viewer” . Considering this approach, the element representation tends to be simpler, since unnecessary details are put aside, and eventually easier to understand, communicate, and analyze.

As a matter of fact, most of the techniques presented help the designer to raise the level of abstraction of the design process in order to lower the level of complexity of the solution.

Information hiding

“Information hiding involves concealing the details of a [system entity's] implementation from its clients” . By doing this, the coupling between entities is minimized and their contribution to system complexity is restricted to what information they expose.

There are several approaches to perform information hiding: by modularizing the system, by separating its concerns, by separating interface and implementation, or by separating policy and implementation.

Modularization

Modularization is the meaningful decomposition of a system into modules. It introduces well-defined and documented partitions (modules) within a system by deciding how to physically package the logical structure entities of an application. Some benefits of modularization follow:

• It promotes understanding, since each module can be grasped at a time,
• It eases development, since each module can be designed, implemented, and tested separately,
• It shortens development time, since modules can be implemented in parallel or reused or even bought, and
• It promotes product flexibility, since a module can replace by another if both respect the same interfaces.

Separation of concerns

Separation of concerns is tightly coupled to the modularization technique. Actually, it is a rule of thumb to define how modules should be separated to each other: different or unrelated concerns should be restricted to different modules.

Coupling and cohesion

Coupling and cohesion are principles used to measure whether the design was well divided into modules.

Coupling is the strength of interdependence between software modules. The more dependent is module A to module B internals, the stronger is the coupling between A and B. Strong coupling implies the modules involved are harder to understand because they must be understood together, harder to change because these changes will impact more than one module, and harder to correct because the problem may be spread over the tightly coupled modules.

Opposed to coupling, cohesion is an intra-module measure. Cohesion is the strength of relation between tasks performed by a module. The tasks of a module can be related to each other by several levels, then converted on types of cohesion:

• Functional cohesion:

  tasks are grouped because of the similarity of their functions.

• Sequential cohesion:

  tasks are grouped because they belong to the same sequence of operations, they share data at each step, but they don't make up a complete task when done together.

• Communicational cohesion:

  tasks are grouped because they make use of the same data and aren't related in any other way.

• Temporal cohesion:

  tasks are grouped because they are executed at the same time.

• Procedural cohesion:

  tasks are grouped because they are executed in a specified order.

• Logical cohesion:

  tasks are grouped only by a shared control flag that will indicate which task will be performed during execution.

• Coincidental cohesion:

  tasks are grouped without any criteria.

In order to achieve sound designs, we can also sort the types of cohesion from the most to the least desirable on design : functional, sequential, communicational, temporal, procedural, logical, and coincidental.

Separation of policy and implementation

This technique enables separation of concerns. The separation of policy and implementation technique simply states: “A [module] of a software system should deal with policy or implementation, but not both.” Modules responsible for implementation should only execute algorithms without any context/domain-sensitive decisions. These decisions must be left to policy modules, which are often application-specific and are often responsible of supplying arguments for the implementation modules.

This separation eases reuse and maintenance of implementation modules, since they are less specific than policy modules.

Separation of interface and implementation

Separation of interface and implementation eases modularization. This technique recommends the description of functionality by means of contracts, also called interfaces. Modules will eventually implement these interfaces in order to be part of the system.

Using this technique, the coupling between modules and clients is lowered, since clients are only bound only to interfaces – not to implementations.

Summary

The purpose of this chapter was to provide the fundamental knowledge on Software Design in order to enable the reader to be ready for the study of Software Architecture. We expect that, by now, the reader is able to understand:

• what software design is and what are its characteristics and benefits,
• how software design problems can be decomposed, and
• what are the general enabling techniques for performing software design.

As a matter of fact, since there are many great books on Software Design for the same audience of ours – the inexperienced reader, it was not our intention to go deeper on the subject covered in this chapter. Our intention was just to introduce it. For more detailed information, we recommend the reader to check the books on Software Design indicated in this chapter's bibliography.