CS302: Software Engineering

Software design is a process of defining the architecture, components, interfaces, and other characteristics of a system or component and planning for a software solution. After the purpose and specifications of software is determined, software developers will design or employ designers to develop a plan for a solution.

A software design may be platform-independent or platform-specific, depending on the availability of the technology called for by the design.

Viewed as a process, software design is the software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software's internal structure that will serve as the basis for its construction. More precisely, a software design (the result) must describe the software architecture and the interfaces between those components. It must also describe the components at a level of detail that enables their construction.

Software design plays an important role in developing software: it allows software engineers to produce various models that form a kind of blueprint of the solution to be implemented. We can analyze and evaluate these models to determine whether or not they will allow us to fulfill the various requirements. We can also examine and evaluate various alternative solutions and trade-offs. Finally, we can use the resulting models to plan the subsequent development activities, in addition to using them as input and the starting point of construction and testing.

In a standard listing of software life cycle processes such as IEEE/EIA 12207 Software Life Cycle Processes, software design consists of two activities that fit between software requirements analysis and software construction:

• Software architectural design (sometimes called top-level design): describing software's top-level structure and organization and identifying the various components.
• Software detailed design: describing each component sufficiently to allow for its construction.

Concepts of software design

The concepts, notions, and terminology introduced here form an underlying basis for understanding the role and scope of software design.

General Design Concepts

Software is not the only field where design is involved. Generally, we can view design as a form of problem-solving. For example, the concept of a wicked problem–a problem with no definitive solution–is interesting in terms of understanding the limits of design. A number of other notions and concepts are also of interest in understanding design in its general sense: goals, constraints, alternatives, representations, and solutions.

Context of Software Design

To understand the role of software design, it is important to understand the context in which it fits, the software engineering life cycle. Thus, it is important to understand the major characteristics of software requirements analysis vs. software design vs. software construction vs. software testing.

Software Design Process

Software design is generally considered a two-step process:

Architectural design

Architectural design describes how software is decomposed and organized into components (the software architecture).

Detailed design

Detailed design describes the specific behavior of these components. The output of this process is a set of models and artifacts that record the major decisions that have been taken.

Enabling Techniques

According to the Oxford English Dictionary, a principle is "a basic truth or a general law … that is used as a basis of reasoning or a guide to action". Software design principles, also called enabling techniques, are key notions considered fundamental to many different software design approaches and concepts.

Abstraction

Abstraction is "the process of forgetting information so that things that are different can be treated as if they were the same". In the context of software design, two key abstraction mechanisms are parameterization and specification. Abstraction by specification leads to three major kinds of abstraction: procedural abstraction, data abstraction, and control (iteration) abstraction.

Coupling and cohesion

Coupling is defined as the strength of the relationships between modules, whereas cohesion is defined by how the elements making up a module are related.

Decomposition and modularization

Decomposing and modularizing large software into a number of smaller independent ones, usually with the goal of placing different functionalities or responsibilities in different components.

Encapsulation/information hiding

Encapsulation/information hiding means grouping and packaging the elements and internal details of an abstraction and making those details inaccessible.

Separation of interface and implementation

Separating interface and implementation involves defining a component by specifying a public interface known to the clients, separate from the details of how the component is realized.

Sufficiency, completeness, and primitiveness

Achieving sufficiency, completeness, and primitiveness means ensuring that a software component captures all the important characteristics of an abstraction, and nothing more.

Figure 1. Breakdown of topics for the Software Design

Software Structure and Architecture

In its strict sense, a software architecture is "a description of the subsystems and components of a software system and the relationships between them". Architecture thus attempts to define the internal structure -according to the Oxford English Dictionary, "the way in which something is constructed or organized" - of the resulting software. During the mid-1990s, however, software architecture started to emerge as a broader discipline involving the study of software structures and architectures in a more generic way. This gave rise to a number of interesting ideas about software design at different levels of abstraction. Some of these concepts can be useful during the architectural design (for example, architectural style) of specific software, as well as during its detailed design (for example, lower-level design patterns). But they can also be useful for designing generic systems, leading to the design of families of programs (also known as product lines). Interestingly, most of these concepts can be seen as attempts to describe and thus reuse generic design knowledge.

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 that can provide software's high-level organization (its macroarchitecture).

• General structure (for example, layers, pipes, and filters, blackboard)
• Distributed systems (for example, client-server, three tiers, 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 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 several 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".

An interesting distinction is the one between quality attributes discernable at run-time (performance, security, availability, functionality, usability), those not discernable at run-time (modifiability, portability, reusability, integrability, and testability), and those related to the architecture's intrinsic qualities (conceptual integrity, correctness, and completeness, buildability).

Quality Analysis and Evaluation Techniques

Various tools and techniques can help ensure a software design's quality.

• Software design reviews: informal or semiformal, often group-based, techniques to verify and ensure the quality of design artifacts.
• Static analysis: formal or semiformal static (non-executable) analysis that can be used to evaluate a design (for example, fault-tree analysis or automated cross-checking).
• Simulation and prototyping: dynamic techniques to evaluate a design (for example, performance simulation or feasibility prototype.

Measures

Measures can be used to assess or to quantitatively estimate various aspects of a software design's size, structure, or quality. Most measures that have been proposed generally depend on the approach used for producing the design. These measures are classified into two broad categories:

• Function-oriented (structured) design measures: the design's structure, obtained mostly through functional decomposition; generally represented as a structure chart (sometimes called a hierarchical diagram) on which various measures can be computed.
• Object-oriented design measures: the design's overall structure is often represented as a class diagram, on which various measures can be computed. Measures of the properties of each class's internal content can also be computed.

Software Design Notations

Many notations and languages exist to represent software design artifacts. Some are used mainly to describe a design's structural organization, others to represent software behavior. Certain notations are used mostly during architectural design and others mainly during detailed design, although some notations can be used in both steps. In addition, some notations are used mostly in the context of specific. Here, they are categorized into notations for describing the structural (static) view vs. the behavioral (dynamic) view.

Structural Descriptions (static view)

The following notations, mostly (but not always) graphical, describe and represent the structural aspects of a software design - that is, they describe the major components and how they are interconnected (static view):

• Architecture description languages (ADLs): textual, often formal, languages used to describe a software architecture in terms of components and connectors.
• Class and object diagrams: used to represent a set of classes (and objects) and their interrelationships.
• Component diagrams: used to represent a set of components ("physical and replaceable part[s] of a system that [conform] to and [provide] the realization of a set of interfaces") and their interrelationships.
• Class responsibility collaborator cards (CRCs): used to denote the names of components (class), their responsibilities, and their collaborating components' names.
• Deployment diagrams: used to represent a set of (physical) nodes and their interrelationships and, thus, to model the physical aspects of a system.
• Entity-relationship diagrams (ERDs): used to represent conceptual models of data stored in information systems.
• Interface description languages (IDLs): programming-like languages used to define the interfaces (names and types of exported operations) of software components.
• Jackson structure diagrams: used to describe the data structures in terms of sequence, selection, and iteration.
• Structure charts: used to describe the calling structure of programs (which module calls and is called by which other module).

Behavioral Descriptions (dynamic view)

The following notations and languages, some graphical and some textual, are used to describe the dynamic behavior of software and components. Many of these notations are useful mostly, but not exclusively, during detailed design.

• Activity diagrams: used to show the control flow from activity ("ongoing non-atomic execution within a state machine") to activity.
• Collaboration diagrams are used to show the interactions that occur among a group of objects, where the emphasis is on the objects, their links, and the messages they exchange on these links.
• Data flow diagrams (DFDs): used to show data flow among a set of processes.
• Decision tables and diagrams: used to represent complex combinations of conditions and actions.
• Flowcharts and structured flowcharts: used to represent the flow of control and the associated actions to be performed.
• Sequence diagrams: used to show the interactions among a group of objects, with emphasis on the time-ordering of messages.
• State transition and state-chart diagrams: used to show the control flow from state to state in a state machine.
• Formal specification languages: textual languages that use basic notions from mathematics (for example, logic, set, sequence) to rigorously and abstractly define software component interfaces and behavior, often in terms of pre- and post-conditions.
• Pseudocode and program design languages (PDLs): structured-programming-like languages used to describe, generally at the detailed design stage, the behavior of a procedure or method.

Software Design Strategies and Methods

There exist various general strategies to help guide the design process. In contrast with general strategies, methods are more specific in that they generally suggest and provide a set of notations to be used with the method, a description of the process to be used when following the method and a set of guidelines in using the method. Such methods are useful as a means of transferring knowledge and as a common framework for teams of software engineers.

General Strategies

Some often-cited examples of general strategies useful in the design process are divide-and-conquer and stepwise refinement, top-down vs. bottom-up strategies, data abstraction and information hiding, use of heuristics, use of patterns and pattern languages, use of an iterative and incremental approach.

Function-Oriented (Structured) Design

This is one of the classical methods of software design, where decomposition centers on identifying the major software functions and then elaborating and refining them in a top-down manner. Structured design is generally used after structured analysis, thus producing, among other things, data flow diagrams and associated process descriptions. Researchers have proposed various strategies (for example, transformation analysis, transaction analysis) and heuristics (for example, fan-in/fan-out, scope of effect vs. scope of control) to transform a DFD into a software architecture generally represented as a structure chart.

Object-Oriented Design

Numerous software design methods based on objects have been proposed. The field has evolved from the early object-based design of the mid-1980s (noun = object; verb = method; adjective = attribute) through OO design, where inheritance and polymorphism play a key role, to the field of component-based design, where meta-information can be defined and accessed (through reflection, for example). Although OO design's roots stem from the concept of data abstraction, responsibility-driven design has also been proposed as an alternative approach to OO design.

Data-Structure-Centered Design

Data-structure-centered design (for example, Jackson, Warnier-Orr) starts from the data structures a program manipulates rather than from the function it performs. The software engineer first describes the input and output data structures (using Jackson's structure diagrams, for instance) and then develops the program's control structure based on these data structure diagrams. Various heuristics have been proposed to deal with special cases – for example, when there is a mismatch between the input and output structures.

Component-Based Design (CBD)

A software component is an independent unit, having well-defined interfaces and dependencies that can be composed and deployed independently. Component-based design addresses issues related to providing, developing, and integrating such components in order to improve reuse.

Other Methods

Other interesting but less mainstream approaches also exist: formal and rigorous methods and transformational methods.

---

Source: Hung Vo, https://cnx.org/contents/zx4yYVWR@1.1:g1PX3LT1@2/Software-Design
This work is licensed under a Creative Commons Attribution 4.0 License.