Software Engineering: Comprehensive Notes on Software Design and Architecture

Overview of Software Design

Software design is a central phase in the software engineering lifecycle. Within the Context of the BITP 2213 Software Engineering course (Sem 1 2022/2023), design follows Requirements and Specification and precedes Implementation, Testing, Deployment, and Maintenance.

  • Definition of Design: Software design is a creative transformation process. It involves deriving a solution that satisfies the identified software requirements. It serves as the bridge between the problem domain and the solution domain.

  • Primary Goal: The objective in this stage is to make the subsequent implementation simple and efficient. It transforms the Software Requirements Specification (SRS) into a Software Design Document (SDD) by breaking the system into workable pieces.

  • Formal Definition (Thayer, 2004): "The process of defining the software architecture, components, modules, interfaces, and data for a software system to satisfy specified requirements."

  • Operational Structure:

    • Decomposes the system into distinct parts.

    • Assigns responsibilities to those parts.

    • Ensures that individual parts fit together to achieve a global goal.

The Software Design Process

According to the model proposed by Ian Sommerville (2004), the software design process is composed of specific design activities that lead to corresponding design products. The process takes a Requirements Specification and Software Specification as inputs.

Design Activities and Products

  1. Architectural Design: Identifying and defining the sub-systems of the overall software. The product is the System Architecture.

  2. Abstract Specification: Specifying the identified sub-systems. The product is the Software Specification.

  3. Interface Design: Describing the interfaces of the sub-systems. This ensures that components can interact without needing to know the internal working of other components. The product is the Interface Specification.

  4. Component Design: Decomposing sub-systems into individual components. The product is the Component Specification.

  5. Data Structure Design: Designing the specific data structures required to solve data-related problems in the system. The product is the Data Structure Specification.

  6. Algorithm Design: Designing the specific logic and algorithms needed to solve functional problems. The product is the Algorithm Specification.

Software Architecture

Definitions and Concepts

  • Jerrold Grochow and Pressman (Ch 10): "The architecture of a system is a comprehensive framework that describes its form and structure - its components and how they fit together."

  • A High Level of Abstraction: Architecture allows for analyzing systems at a high level. It maps the analysis model (which emphasizes the problem domain) to the design model (which emphasizes the solution domain).

  • Foundational Framework: It provides the structure for the system and guides the entire development of the design. The output of this specific architectural design process is the formal description of the software architecture.

What Architecture Describes

  • Detailed organization of sub-systems (large-scale).

  • Components and their internal organization.

  • Global control structures.

  • Protocols for communication between parts.

  • Management of system data.

The Role of Software Architecture

  • Stakeholder Communication: Serves as a focal point for discussion among system stakeholders.

  • System Analysis: Allows for the analysis of non-functional requirements. It provides a blueprint that makes understanding the implications of system changes easier.

  • Large-Scale Reuse: Architectures may be reused across a range of similar systems.

Architectural Design Decisions

When designing the architecture, engineers must answer several critical questions:

  • Is there a generic application architecture that can be used?

  • How will the system be distributed across various platforms?

  • What architectural styles are appropriate for the specific needs?

  • What approach will be used to structure the system?

  • How will the system be decomposed into modules?

  • What control strategy should be used (centralized vs. distributed)?

  • How will the architectural design be evaluated for effectiveness?

  • How should the architecture be documented?

How Architecture Affects Implementation

Architectural choices directly impact the non-functional qualities of the final software:

  • Performance: To maximize performance, one should localize critical operations and minimize communications. This often involves using large-grain components rather than fine-grain ones.

  • Security: This is best handled by using a layered architecture, with critical assets placed in the innermost layers.

  • Safety: To ensure safety, safety-critical features should be localized in a small, manageable number of sub-systems.

  • Availability: This is achieved by including redundant components and incorporating mechanisms for fault tolerance.

  • Maintainability: This is promoted by using fine-grain, easily replaceable components.

Architectural Models

Architectural models are divided into three primary categories: Structural Models, Control Models, and Modular Decomposition Models.

1. Structural Models

  • Repository Model: Used when sub-systems must exchange or share large amounts of data.

    • Operation: There are two methods. First, shared data is held in a central repository accessed by all sub-systems. Second, each sub-system maintains its own database and passes data explicitly.

    • Example: A CASE (Computer-Aided Software Engineering) Tool Set, including components like a Project Repository, Design Translator, Program Editor, Design Editor, Code Generator, Design Analyser, and Report Generator.

    • Advantages: Efficient for large data; sub-systems do not need to know how data is produced; centralized management (backup, security); the schema is a published model.

    • Disadvantages: Sub-systems must agree on a data model (often a compromise); data evolution is expensive; no scope for specific sub-system management policies; difficult to distribute efficiently.

  • Client-Server Model: A distributed model showing how data and processing are spread across components.

    • Operation: A set of stand-alone servers providing services (printing, data management) and a set of clients that access these services via a network.

    • Example: A Film and Picture Library system where an Internet connection links clients to a Web Server, Catalogue Server, Video Server (film clips), and Picture Server (digitized photos).

    • Advantages: Straightforward data distribution; effective use of networked, potentially cheaper hardware; easy to upgrade or add new servers.

    • Disadvantages: Lack of a shared data model leads to inefficient interchange; redundant management across servers; no central register makes finding services difficult.

  • Abstract Machine (Layered) Model: Models the interfacing of sub-systems by organizing them into layers.

    • Operation: Each layer provides a set of services. It supports incremental development. Changes to a layer interface only affect the adjacent layer.

    • Example: A Version Management System with layers for the Operating System, Database System, Object Management System, and Configuration Management System.

    • Disadvantage: It can be artificial to force a system into this structure.

2. Control Models

Control models concern the flow of control between sub-systems, distinct from how the system is decomposed.

  • Centralised Control: One sub-system has overall responsibility for starting and stopping others.

    • Call-Return Model: A top-down subroutine hierarchy where control moves downwards. Applies to sequential systems.

    • Manager Model: Applies to concurrent systems. One component controls starting, stopping, and coordination. In sequential systems, this might look like a case statement.

    • Example: A Real-time system where a System Controller manages a User Interface, Fault Handler, Computation processes, Actuator processes, and Sensor processes.

  • Event-Based Control: Sub-systems respond to external events from other parts of the system or the environment.

    • Broadcast Models: Events are broadcast to all sub-systems. Any sub-system interested in the event handles it. The control policy is not embedded in the handler; individual sub-systems decide what is relevant. However, the sender doesn't know when or if an event is handled.

    • Interrupt-Driven Models: Used in real-time systems where fast response is critical. Specific interrupt types are defined, and hard-wired switches trigger specific handlers via an interrupt vector.

3. Modular Decomposition Models

At this level, sub-systems are further broken down into modules. A sub-system is an independent system in its own right, whereas a module provides services but is not a standalone system.

  • Object Models: Structure the system as a set of loosely coupled objects with well-defined interfaces. Decomposition identifies object classes, attributes, and operations.

    • Example: An Invoice Processing System including classes for Invoice, Receipt, Payment, and Customer with operations like issue()issue(), sendReminder()sendReminder(), acceptPayment()acceptPayment(), and sendReceipt()sendReceipt().

    • Advantages: Loose coupling allows modification without affecting other objects; reflects real-world entities; widely supported by languages.

    • Disadvantages: Interface changes can be problematic; complex entities are sometimes hard to map to objects.

  • Function-Oriented Pipelining (Pipe and Filter): Functional transformations process inputs to produce outputs.

    • Operation: Often seen in UNIX shells. Sequential transformations form a "batch sequential" model common in data processing.

    • Example: An Invoice Processing System that reads issued invoices, identifies payments, issues receipts, and finds payments due to issue reminders.

    • Advantages: Supports transformation reuse; intuitive; easy to add new transforms; simple to implement sequentially or concurrently.

    • Disadvantages: Requires a common data format for transfer; poor support for interactive or event-based systems.

Architectural Conflicts

Design often involves balancing conflicting goals:

  • Performance vs. Maintainability: Large-grain components help performance but hurt maintainability.

  • Availability vs. Security: Redundant data improves availability but complicates security measures.

  • Safety vs. Performance: Localizing safety features usually increases communication overhead, degrading performance.

Detailed Design Levels

Interface Design

An interface is a set of operations describing the externally observable behavior of a class. Components include:

  • User Interface (UI).

  • External interfaces to other systems.

  • Internal interfaces between design components.

  • Modeling Tool: UML Collaboration Diagrams.

Component Level Design

This describes the internal details of software components, defining:

  • Data structures for local objects.

  • Algorithmic detail for processing functions.

  • Interfaces for accessing operations.

  • Modeling Tools: UML Component and Activity diagrams, and Pseudocode (PDL - Program Design Language).

Data Structure Design

  • Focuses on identifying data structures and operations through systematic analysis.

  • Uses a Data Dictionary to guide design.

  • Applies Information Hiding principles.

  • Defers low-level decisions until late in the process.

  • Encourages the use of Abstract Data Types (ADTs).

Algorithms and Their Expression

An algorithm is a general solution to a problem described as a precise, logical sequence of actions (e.g., cooking recipes or assembly instructions). A computer program is an algorithm expressed in a specific programming language.

Methods of Expression

  1. Natural Language: Often verbose and ambiguous; rarely used for complex technical algorithms.

  2. Pseudocode and Flowcharts: Structured, independent of implementation language, and avoid many ambiguities of natural language.

  3. Programming Languages: Express algorithms in an executable form for computers.

Example: Login Verification Logic

  • Flowchart logic: Start →\rightarrow Read User ID/Password →\rightarrow Query Database →\rightarrow Decision (Valid?) →\rightarrow Yes (Display Main Page), No (Display Error) →\rightarrow End.

  • Pseudocode Example:

    • Start

    • Connect to database

    • Get user id and password from database

    • If record size >1> 1: Display error "Invalid user id and password"; return false

    • Else: Display main page; return true

    • End

  • Java Code Implementation:java public void verifyLogin(String userid, String pwd) { ResultSet rs = new ResultSet(); rs = dbUser.getUser(); if(rs.size() > 1) { Message m = new Message(); m.displayMessage("Invalid user id and password"); } else { MainPage mp = new MainPage(); mp.setVisible(true); } }     

Software Design Document (SDD) Structure

A standard SDD contains the following sections:

  1. Front Matter: Cover, Document Approval, Table of Contents, Lists of Figures/Tables.

  2. 1.0 Introduction: Identification, System Overview, Document Overview.

  3. 2.0 Referenced Documents: Government and Non-Government documents.

  4. 3.0 Preliminary Design: CSCI (Computer Software Configuration Item) Overview and Design Description.

  5. 4.0 Detailed Design.

  6. 5.0 CSCI Data: Data Type Definitions and Constants.

  7. 6.0 CSCI Data Files.

  8. 7.0 Requirement Traceability.

  9. 8.0 Notes.

Characteristics of a "Good" Design

In software engineering, a "good" design is defined as one that balances trade-offs to minimize the total cost of the system over its entire lifetime. Specific attributes include:

  • Economy of resources.

  • High efficiency and reliability.

  • Effective exception identification and handling.

  • Fault prevention and fault tolerance.

  • Produces code that is easier to debug, test, maintain, change, and extend.