Software Design

Chapter 3: Software Design

Acronyms

Acronym	Full Form
API	Application Programming Interface
AOD	Aspect-Oriented Design
CBD	Component-Based Design
CRC	Class Responsibility Collaborator (Or Collaboration)
DFD	Data Flow Diagram
DSL	Domain-Specific Language
ERD	Entity Relationship Diagram
FOSS	Free And Open Source Software
IDL	Interface Description Language
MBD	Model-Based Design
MDD	Model-Driven Design
OO	Object-Oriented
PDL	Program Design Language
SDD	Software Design Description
SoC	Separation of Concerns
UML	Unified Modeling Language

Introduction

This chapter examines software design concepts, its context, processes, qualities, strategies, and methods for recording and evaluating designs. The term “design” can refer to a discipline, the processes within that discipline, the result of those processes, or the life cycle stage where they occur.

A Software Design Description (SDD) documents the outcome of the design process. It serves as a blueprint or model of the system, communicating design information. The SDD defines the software’s components, their organization, and their interfaces in sufficient detail for construction. As a life cycle activity, software design transforms requirements into a definition of the software’s external characteristics and internal structure.

The software design process typically involves three stages:

Architectural design
High-level (external-facing) design
Detailed (internal-facing) design

Breakdown of Topics for Software Design

The Software Design Knowledge Area (KA) is broken down into the following major topics:

Software Design Fundamentals
Software Design Processes
Software Design Qualities
Recording Software Design
Software Design Strategies and Methods
Software Design Analysis and Evaluations

1. Software Design Fundamentals

This section covers the basic concepts, terminology, and scope of software design.

1.1 Design Thinking

Design can be viewed as a form of problem-solving. Design thinking involves two key aspects: understanding the problem and devising a solution. A five-step process for design thinking includes:

Crystallize a purpose or objective.
Formulate a concept for achieving the purpose.
Devise a mechanism to implement the concept.
Introduce a notation to express the mechanism’s capabilities.
Describe the notation’s usage to achieve the purpose.

This process emphasizes the linguistic nature of software design, where much of the work consists of creating a vocabulary to express a problem and its solution.

1.2 Context of Software Design

Software design is a critical part of the software development life cycle, transforming requirements into implementable design specifications. Its context includes relationships with:

Software requirements: The requirements establish the set of problems the design must solve.
Software architecture: If an architecture exists, it constrains the design by defining major components, APIs, patterns, and principles.
Software construction: The design must provide a clear guide for implementors to build the system.
Software testing: The design provides a foundation for the overall testing strategy and specific test cases.

1.3 Key Issues in Software Design

Design must address many key issues. Some are fundamental quality concerns like performance, security, reliability, and maintainability. Others involve how to refine, organize, and package software components. Another set of issues, often called aspects, deals with behaviors that are not in the application domain but support it, often crosscutting the system’s functionality.

1.4 Software Design Principles

Design principles are key notions that guide decision-making during design. They include:

Abstraction: Focusing on information relevant to a particular purpose while ignoring the rest. It helps identify essential properties of entities.
Separation of Concerns (SoC): Identifying and separating different areas of interest (concerns) to focus on each one in isolation.
Modularization: Structuring software into smaller components or units, each with a name and well-defined interfaces. The goal is to place distinct functionalities in different components.
Encapsulation (or Information Hiding): Building on abstraction and modularization to make nonessential information less accessible, allowing users to focus on the essential interface elements. This leads to the separation of interface and implementation.
Coupling: A measure of the interdependence among modules. Design methods generally advocate for loose or weak coupling.
Cohesion: A measure of the strength of association of elements within a module. Designs should aim to maximize module cohesion.
Uniformity: Ensuring consistency across software components, such as in naming schemes, notations, and interfaces.
Completeness: Ensuring a component captures all important characteristics of an abstraction. The design must be complete enough to demonstrate how requirements will be met.
Verifiability: Ensuring that information is available to verify the design against its requirements, which is crucial for high-assurance systems.
Ethically Aligned Design: Addresses concerns such as human rights, well-being, data agency, transparency, and accountability, which are increasingly important for autonomous and AI-driven systems.

2. Software Design Processes

Software design is a multi-stage process, typically divided into:

Architectural design stage: Addresses the fundamentals of the system as a whole and its environment. It defines the computational model, major elements, and strategies for crosscutting concerns.
High-level design stage: This outward-facing stage develops the top-level structure, identifying major components and how they interact with the environment.
Detailed design stage: This inward-facing stage specifies the internal details of each component sufficiently for its construction.

While these stages are distinct, the boundaries between them are not strict.

2.1 High-Level Design

High-level design specifies the interactions of a system’s major components with each other and with the external environment. It addresses:

External events and messages the system must handle.
Events and messages the system must produce.
Data formats and protocols.
Ordering and timing relationships between inputs and outputs.
Data persistence strategies.

This stage operates within the constraints established by the software architecture.

2.2 Detailed Design

The detailed design stage works within the constraints of the high-level design. It specifies the internal characteristics of components, including:

Refinement of components into modules or program units.
Allocation of responsibilities to modules.
Interactions, scope, and visibility among modules.
Data organization and implementation.
User interfaces.
Required algorithms and data structures.

3. Software Design Qualities

Design qualities are characteristics that software should exhibit, guided by requirements and architectural directives. They are a major subclass of design concerns. Key qualities include:

Concurrency: How software is refined into concurrent units like processes and threads, and the consequences for efficiency and synchronization.
Control and Event Handling: How control flow is organized and how reactive or temporal events are managed.
Data Persistence: How data is stored and managed throughout the system.
Distribution of Components: How software components are distributed across hardware and how they communicate.
Errors and Exception Handling: How to prevent, tolerate, and process errors and exceptional conditions.
Integration and Interoperability: How heterogeneous systems or components interoperate by exchanging data or services.
Assurance, Security, and Safety: Ensuring the software behaves as intended in critical situations. Security involves preventing unauthorized access and limiting damage from attacks. Safety pertains to managing behavior to prevent harm.
Variability: The ability to create permissible variations in a software system for different contexts or markets, often seen in software product lines.

4. Recording Software Design

The outputs of the design process are work products that record accumulated knowledge. These design descriptions capture the problem, the solution vocabulary, key decisions, and the rationale for those decisions. Effective communication of the design among all stakeholders is a fundamental aspect of the process.

4.1 Model-Based Design (MBD)

MBD is an approach where models play a central role in recording the design. This reflects a shift away from document-based artifacts, which can be ambiguous or incomplete. MBD, supported by tooling, enables simulation, analysis, rapid prototyping, and better knowledge management. Model-Driven Development (MDD) is a paradigm that uses models as the primary artifacts of the entire development process.

4.2 Structural Design Descriptions

These notations, mostly graphical, describe a design’s static structure, including major components and their interconnections. Examples include:

Class and object diagrams: Show a set of classes, objects, and their relationships.
Component diagrams: Represent a system’s replaceable components and their interconnections.
Class Responsibility Collaborator (CRC) cards: Denote component names, responsibilities, and collaborators.
Deployment diagrams: Model the physical deployment of software on hardware nodes.
Entity Relationship Diagrams (ERDs): Represent conceptual models of data.
Interface Description Languages (IDLs): Define the interfaces of software components.
Structure charts: Describe the calling structure of programs.

4.3 Behavioral Design Descriptions

These notations describe the dynamic behavior of software. Examples include:

Activity diagrams: Show the flow of a computation from one activity to another, including concurrency.
Interaction diagrams (Sequence and Communication): Characterize interactions among objects, emphasizing either temporal ordering (sequence) or links (communication).
Data Flow Diagrams (DFDs): Show the flow of data among computing elements.
Decision tables and diagrams: Represent complex combinations of conditions and actions.
State diagrams and statecharts: Show state transitions and how behavior changes based on current state and events.
Formal specification languages: Use mathematical notations to rigorously define component interfaces and behavior.
Pseudocode and Program Design Languages (PDLs): Structured, programming-like notations to describe procedural logic.

4.4 Design Patterns and Styles

A pattern is a “common solution to a common problem in a given context”. Design patterns document proven solutions and establish a shared vocabulary. They are often categorized as:

Creational (e.g., factory, singleton)
Structural (e.g., adapter, façade, proxy)
Behavioral (e.g., command, observer, strategy)

Architectural styles can be seen as patterns “in the large” that solve architecture-level problems.

4.5 Specialized and Domain-Specific Languages (DSLs)

A Domain-Specific Language (DSL) is a computer language created to codify concepts from a specific application domain. This approach blurs the line between modeling, design, and programming, as representing the design in a DSL can lead directly to an executable implementation.

4.6 Design Rationale

Design rationale captures why a design decision was made, including assumptions, alternatives considered, and trade-offs analyzed. Documenting rationale is crucial for long-term maintainability, as it helps future teams understand the reasoning behind the design when making modifications.

5. Software Design Strategies and Methods

Various strategies and methods exist to guide the design process. Most methods emphasize certain design concepts (like objects or functions) as primary organizing themes.

5.1 General Strategies

Common strategies include divide-and-conquer, stepwise refinement, top-down vs. bottom-up approaches, using heuristics and patterns, and iterative or incremental development.

5.2 Function-Oriented (or Structured) Design

This classic method focuses on identifying major software functions and elaborating them in a top-down manner through decomposition. It often follows structured analysis and the use of DFDs.

5.3 Data-Centered Design

This approach begins with the data structures a program will manipulate, rather than its functions. The designer specifies input and output data structures and then develops the transformations between them.

5.4 Object-Oriented Design (OOD)

OOD methods have evolved from early approaches focused on inheritance and polymorphism to modern component-based design. A key principle is responsibility-driven design. Mnemonics like SOLID (for class design) and SOFA (for method design) provide guidance.

5.5 User-Centered Design

This is a multidisciplinary approach that emphasizes a deep understanding of users and their needs as the basis for designing user experiences. It involves gathering user requirements, creating prototypes, and evaluating the design solution.

5.6 Component-Based Design (CBD)

CBD decomposes a system into standalone, independent components that communicate through well-defined interfaces and conform to a standard component model. The goal is to improve reuse by providing, developing, and integrating components.

5.7 Event-Driven Design

In this approach, a system or component’s operations are invoked in reaction to events (indirect invocation). Publish/subscribe messaging is often used to decouple event producers and consumers.

5.8 Aspect-Oriented Design (AOD)

AOD constructs software using aspects to implement crosscutting concerns that were identified in the requirements.

5.9 Constraint-Based Design

This approach uses constraints to limit the design space, excluding infeasible or unacceptable alternatives. By forcing early decisions, constraints can accelerate the design process.

5.10 Domain-Driven Design

In this method, the designer uses a domain-specific language shared with stakeholders to describe the target system. This shared language connects requirements directly to the software design.

5.11 Other Methods

Other design approaches exist, such as iterative and adaptive methods that reduce emphasis on rigorous upfront design, and service-oriented methods that build distributed software from web services.

6. Software Design Quality Analysis and Evaluation

6.1 Design Reviews and Audits

Design reviews are comprehensive examinations of a design to assess its completeness, coverage of requirements, and potential issues. A design audit is more narrowly focused on a specific set of characteristics.

6.2 Quality Attributes

Many attributes contribute to design quality, including “ilities” (e.g., maintainability, portability, usability) and “nesses” (e.g., correctness, robustness). Some qualities, like performance and security, are observable at runtime, while others, like modifiability and testability, are not.

6.3 Quality Analysis and Evaluation Techniques

Techniques for analyzing design quality include:

Software design reviews: Both informal and rigorous techniques like inspections and scenario-based walkthroughs.
Static analysis: Non-executable analysis of design artifacts, such as fault-tree analysis or automated cross-checking for security vulnerabilities.
Formal design analysis: Uses mathematical models to predict behavior and validate software properties, helping to detect errors early.
Simulation and prototyping: Dynamic techniques to evaluate a design, such as performance simulations or feasibility prototypes.

6.4 Measures and Metrics

Measures can be used to quantitatively estimate aspects of a design’s size, structure, or quality. They are often categorized as:

Function-based (structured) design measures: Derived from analyzing a functional decomposition, often represented by a structure chart.
Object-oriented design measures: Computed from a class diagram, considering properties of classes and their relationships.

6.5 Verification, Validation, and Certification

Systematic evaluation of a design is essential for:

Verification: To confirm that the design satisfies its stated requirements.
Validation: To establish that the design will allow the system to meet stakeholder expectations.
Certification: A third-party attestation that the design conforms to its specification and intended use.