Software design concepts and architecture notes — Unit 3

Design is the first step in the development phase for any engineered product or system. While requirements engineering focuses on what the system should do, software design focuses on how to build it.

⇒1.1 The Design Process

The design process translates the SRS into a representation of the software that can be assessed for quality before coding begins. It is an iterative process through which requirements are translated into a 'blueprint' for constructing the software.

⇒1.2 Design Quality

A good design should:

• Implement all explicit requirements contained in the analysis model, and accommodate implicit requirements desired by customers.
• Be a readable, understandable guide for those who generate code and those who test and maintain the software.
• Provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

⇒2.1 Abstraction

Abstraction permits one to concentrate on a problem at some level of generalization without regard to irrelevant low-level details. At the highest level, a solution is stated in broad terms using the language of the problem environment. At lower levels, abstraction takes a more procedural orientation.

• Data Abstraction: A named collection of data that describes a data object (e.g., a 'Door' object having attributes like open/closed, dimensions, weight).
• Procedural Abstraction: A sequence of instructions that have a specific and limited function (e.g., an 'openDoor' function).

⇒2.2 Refinement

Stepwise refinement is a top-down design strategy. A program is developed by successively refining levels of procedural detail. Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data internally but suppress the need for 'outsiders' to have knowledge of low-level details. Refinement helps the designer to reveal low-level details as design progresses.

Software architecture and design patterns embody modularity. Software is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements.

⇒3.1 Why Modularity?

Modularity is the single attribute of software that allows a program to be intellectually manageable. A monolithic program (a single large module) cannot be easily grasped by a software engineer.

⇒3.2 The 'Cost' of Modularity

As the number of modules increases, the cost/effort to develop individual modules decreases. However, as the number of modules grows, the cost/effort associated with integrating those modules increases. There is an optimal number of modules that results in minimum overall development cost.

These two metrics measure the quality of a modular design. The golden rule of software design is: Strive for High Cohesion and Low Coupling.

⇒4.1 Cohesion (High is Good)

Cohesion is a measure of the relative functional strength of a module. A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing.

• Functional Cohesion (Best): Every part of the module contributes to a single, specific function.
• Coincidental Cohesion (Worst): Parts are grouped arbitrarily with no meaningful relationship.

⇒4.2 Coupling (Low is Good)

Coupling is a measure of interconnection among modules. Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

• Data Coupling (Best): Modules share only the specific data needed (e.g., passing simple parameters).
• Content Coupling (Worst): One module directly modifies the internal data or code of another module.

The principle of information hiding suggests that modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information.

⇒5.1 Implementation details

Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function.

• In Object-Oriented languages, this is enforced using access modifiers like `private` and `protected`.
• It drastically reduces the likelihood that an error in one module will propagate and break another module (reducing the 'ripple effect').

Software architecture encompasses the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. It is the highest level of design.

⇒6.1 Why is Architecture Important?

• Representations of software architecture enable communication among all stakeholders.
• The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, ultimately, on the system's success.
• It constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together.

Architecture does not concern itself with the algorithmic details of individual components, but rather how those components are integrated and communicate.

An architectural style is a description of component types and a pattern of their runtime control and/or data transfer. It describes a system category that encompasses a set of components, a set of connectors that enable communication, and constraints on how they can be integrated.

⇒7.1 Data-Centered Architecture

A data store (e.g., a file or database) resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store.

⇒7.2 Data-Flow Architecture

Applied when input data are to be transformed through a series of computational or manipulative components into output data. A pipe-and-filter pattern is a classic example, where filters transform data and pipes transmit it (like Unix command line piping).

⇒8.1 Call and Return Architecture

This architectural style enables you to achieve a program structure that is relatively easy to modify and scale.

• Main program/subprogram architectures: Decomposes function into a control hierarchy where a 'main' program invokes a number of program components.
• Remote procedure call (RPC) architectures: The components of a main program/subprogram architecture are distributed across multiple computers on a network.

⇒8.2 Layered Architecture

A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set. At the outer layer, components service user interface operations. At the inner layer, components perform operating system interfacing.

The Client-Server model is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients.

⇒9.1 Components

• Servers: Standby machines that wait for requests. They manage data, business logic, or hardware resources.
• Clients: User-facing applications that initiate communication with the server to request a service.

⇒9.2 Fat vs Thin Clients

• Thin Client: The client handles only the UI. All processing and data management happen on the server (e.g., a simple web browser).
• Fat Client: The client handles the UI and significant processing logic, while the server mostly handles data storage (e.g., a complex desktop video game).

OOD is a design methodology that views a system as a collection of interacting objects rather than a set of top-down functions.

⇒10.1 Core Concepts

• Classes and Objects: A class is a blueprint; an object is a runtime instance of that blueprint.
• Encapsulation: Bundling data (attributes) and the methods that operate on that data into a single unit, and hiding internal state.
• Inheritance: Creating new classes based on existing ones, promoting code reuse.
• Polymorphism: The ability of different objects to respond to the same method call in their own specific way.

OOD maps very cleanly to the real world, making it easier to model complex business domains compared to procedural design.

SOLID is an acronym representing five design principles intended to make software designs more understandable, flexible, and maintainable.

⇒11.1 S and O

• Single Responsibility Principle (SRP): A class should have one, and only one, reason to change. It should do exactly one thing.
• Open/Closed Principle (OCP): Software entities should be open for extension, but closed for modification. You should be able to add new functionality without changing existing code (often via interfaces/inheritance).

⇒11.2 L, I, and D

• Liskov Substitution Principle (LSP): Subtypes must be completely substitutable for their base types without altering the correctness of the program.
• Interface Segregation Principle (ISP): Clients should not be forced to depend upon interfaces that they do not use. (Keep interfaces small and specific).
• Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces).

A design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into code, but a template for how to solve a problem.

⇒12.1 Gang of Four (GoF)

The concept was popularized by the 'Gang of Four' book, which cataloged 23 fundamental patterns into three categories:

• Creational Patterns: Deal with object creation mechanisms.
• Structural Patterns: Deal with object composition and relationships.
• Behavioral Patterns: Deal with communication and assignment of responsibilities between objects.

⇒13.1 Singleton Pattern

Ensures a class has only one instance, and provides a global point of access to it. Useful for centralized managers (e.g., a database connection pool or a configuration manager).

⇒13.2 Factory Method Pattern

Defines an interface for creating an object, but lets subclasses decide which class to instantiate. It defers instantiation to subclasses.

⇒13.3 Abstract Factory Pattern

Provides an interface for creating families of related or dependent objects without specifying their concrete classes (e.g., creating Mac OS UI buttons vs Windows UI buttons).

⇒14.1 Adapter Pattern

Converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces (like a power plug adapter).

⇒14.2 Decorator Pattern

Attaches additional responsibilities to an object dynamically at runtime. Decorators provide a flexible alternative to subclassing for extending functionality (e.g., adding 'scrollbars' or 'borders' to a UI window object without creating a `ScrollingWindowWithBorder` subclass).

⇒14.3 Facade Pattern

Provides a unified, high-level interface to a set of interfaces in a subsystem, making the subsystem easier to use (e.g., a `Car` facade hiding the complexities of the engine, transmission, and electrical subsystems).

⇒15.1 Observer Pattern

Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The foundation of modern Event-Driven architectures and UI frameworks (MVC).

⇒15.2 Strategy Pattern

Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it (e.g., swapping between 'Zip Compression' and 'RAR Compression' algorithms at runtime).

⇒15.3 Command Pattern

Encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

User interface (UI) design creates an effective communication medium between a human and a computer. Following a set of interface design principles helps uncover problems early.

⇒16.1 Golden Rules of UI Design (Theo Mandel)

• Place the user in control: Do not force the user into rigid sequences. Allow undo operations.
• Reduce the user's memory load: The system should remember things so the user doesn't have to. Rely on recognition rather than recall.
• Make the interface consistent: Visuals, terminology, and behavior should be predictable across all screens.

⇒16.2 User-Centered Design

UI design should be an iterative process involving users early and often. Prototyping (from paper sketches to high-fidelity interactive mockups) is the primary mechanism for eliciting UI feedback.

Component-level design translates the design model into operational software. It occurs after the data, architectural, and interface designs have been established.

⇒17.1 Procedural Design

The algorithms required to perform the module's functions are specified in detail using structured programming constructs (Sequence, Condition, Iteration).

⇒17.2 Tools for Component Design

• Flowcharts: Graphical representation of the control flow.
• Pseudocode (PDL - Program Design Language): Structured English used to describe algorithms before actual coding. It cannot be compiled but is readable by humans.
• UML Activity Diagrams: Used in modern OOD to show flow of control.

Data design translates data objects defined in the analysis model into data structures at the software component level and into a database architecture at the application level.

⇒18.1 Database Architecture

For systems requiring persistent data, the data dictionary and class diagrams are transformed into a database schema (tables, foreign keys, indexes).

⇒18.2 Data Structures

At the component level, the designer must select the appropriate internal data structures (Arrays, Linked Lists, Hash Tables, Trees) that will optimize the specific algorithms needed by that component.

A modern architectural style that structures an application as a collection of loosely coupled, fine-grained services.

⇒19.1 Characteristics

• Independent Deployment: Each service can be updated and deployed without deploying the entire application.
• Decentralized Data: Each service manages its own database, preventing tight data coupling.
• Technology Heterogeneity: Different services can be written in different programming languages.
• Communication: Services communicate over networks using lightweight protocols (REST HTTP, gRPC, Message Queues).

⇒19.2 Contrast with Monoliths

In a Monolith, everything is compiled into a single executable. It is easier to test and deploy initially, but becomes a tangled, unscalable mess as the application grows massively. Microservices solve scaling issues but introduce immense operational complexity (network latency, distributed tracing).

The output of the design phase is the Software Design Document (SDD).

⇒20.1 Purpose of the SDD

The SDD describes the software architecture, the specific components, and the interfaces between them. It is the primary document used by programmers to begin writing code.

⇒20.2 Standard Contents

• Architecture Description: High-level diagrams (Context, Layered architecture).
• Data Design: Database schema, ER diagrams.
• Interface Design: API definitions, UI mockups, communication protocols.
• Component Design: Detailed pseudocode, state diagrams, or sequence diagrams for complex modules.

In Agile environments, the SDD is often much lighter, sometimes consisting only of living UML diagrams and well-documented API contracts rather than a massive Word document.