Introduction to (software) design  (Page 8/9)

Design solutions mirror the problem complexity , usually having many attributes and interrelationships. We can observe this characteristic, for example, when designing a solution for managing the inventory of a DVD rental store. Whatever the solution is, it must contain attributes such as movies, DVDs, clients, and genres, which will represent the elements inherent to the problem. However, this is not enough. It must also contain relations such as “a client can rent one or more DVDs”, “a movie have one or more genres”, or “a DVD must contain one or more movies”, which will behave just like the relations on the problem domain. Consequently, when many different attributes have different interrelationships between themselves, complexity emerges.

It is difficult to validate design solutions. The complexity of the solution renders many points of possible validation against design goals. The very problem resides on how well the design goals are described. Usually, only high-level goals are specified for very complex problems, so validation is hardened.

Lastly, most design problems have many acceptable solutions. This is intrinsic to design problems. Since many alternatives can be generated for a single design problem, as many design solutions are eventually reproduced.

The product of the design process is always a design solution. However, despite being a description enabling system construction, nothing is said about the level of detail a solution must incorporate. It comes out that the software design process can occur in many levels of detail. These levels of software design are the subjects of the next section.

Levels of software design

According to the Guide to Software Engineering Body of Knowledge (SWEBOK) , software design consists of two activities: top-level design and detailed design .

The top-level design, also called architectural design, is concerned on describing the fundamental organization of the system, identifying its various components and their relationships to each other and the environment in order to meet the system's quality goals. In contrast to top-level design, detailed design is more concerned on describing each component sufficiently to allow for its construction according to the top-level design.

The clear separation of these activities may not always occur during software development process. Sometimes a designer performs both activities in parallel, conceiving a design that will both meet the quality requirements and also allow for the construction of the system. Nevertheless, we primarily consider this conceptual separation to keep the focus only on software architecture, which is the main subject of this book and will be discussed in the following chapters.

However, just before starting our studies on Software Architecture, we would like to present some principles essential to every design activity, which are called enabling techniques.

Enabling techniques

Enabling techniques are guidelines, approaches, and key notions that are known to result on generally good and sound software designs. Since there are many great books and articles on enabling techniques, the purpose of this section is just to scratch the surface of this subject by giving an overview of it. The essential enabling techniques for an aspiring designer are: