2.3 Software design  (Page 3/5)

Architectural structures and viewpoints

Different high-level facets of a software design can and should be described and documented. These facets are often called views: “A view represents a partial aspect of a software architecture that shows specific properties of a software system”. These distinct views pertain to distinct issues associated with software design - for example, the logical view (satisfying the functional requirements) vs. the process view (concurrency issues) vs. the physical view (distribution issues) vs. the development view (how the design is broken down into implementation units). Other authors use different terminologies, like behavioral vs. functional vs. structural vs. data modeling views. In summary, a software design is a multi-faceted artifact produced by the design process and generally composed of relatively independent and orthogonal views.

An architectural style is “a set of constraints on an architecture [that] defines a set or family of architectures that satisfies them”. An architectural style can thus be seen as a meta-model which can provide software’s high-level organization (its macroarchitecture).

• General structure (for example, layers, pipes, and filters, blackboard)
• Distributed systems (for example, client-server, threetiers, broker)
• Interactive systems (for example, Model-View-Controller, Presentation-Abstraction-Control)
• Adaptable systems (for example, micro-kernel, reflection)
• Others (for example, batch, interpreters, process control, rule-based).

Design patterns

Succinctly described, a pattern is “a common solution to a common problem in a given context.” While architectural styles can be viewed as patterns describing the high-level organization of software (their macroarchitecture), other design patterns can be used to describe details at a lower, more local level (their microarchitecture).

• Creational patterns (example: builder, factory, prototype, and singleton)
• Structural patterns (example: adapter, bridge, composite, decorator, façade, flyweight, and proxy)
• Behavioral patterns (example: command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor)

Families of programs and frameworks

One possible approach to allow the reuse of software designs and components is to design families of software, also known as software product lines. This can be done by identifying the commonalities among members of such families and by using reusable and customizable components to account for the variability among family members.

In OO programming, a key related notion is that of the framework: a partially complete software subsystem that can be extended by appropriately instantiating specific plug-ins (also known as hot spots).

Software design quality analysis and evaluation

This section includes a number of quality and evaluation topics that are specifically related to software design.

Quality attributes

Various attributes are generally considered important for obtaining a software design of good quality - various “ilities” (maintainability, portability, testability, traceability), various “nesses” (correctness, robustness), including “fitness of purpose”.