Software Engineering - Designing the Architecture

Chapter 5: Software Engineering - Designing the Architecture (Part 1)

5.0 Objectives

  • Examine different types of decomposition.

  • Compare competing designs.

  • Document the design.

  • Verify architecture meets the requirements.

5.1 The Design Process

  • Definition of Design

    • Design is the creative process of figuring out how to implement all of the customer’s requirements.

    • Early design decisions address the system’s architecture.

    • Later design decisions address how to implement the individual units.

  • Design as a Creative Process

    • It is an intellectually challenging task with numerous possibilities the system must accommodate.

    • Must consider non-functional design goals such as ease of use and ease to maintain.

    • External factors include:

    • Standard data formats.

    • Government regulations.

    • Improvement in design skills can be achieved by studying examples of good design.

    • Most design work is routine; designers solve problems by reusing and adapting solutions from similar problems.

  • Software Architectures

    • Software architectures have generic solutions, termed architectural styles.

    • Good design involves selecting, adapting, and integrating several architectural design styles to achieve the desired result.

  • Design Process Model

    • Designing a software system is an iterative process.

    • The final outcome is the Software Architecture Document (SAD).

5.3 Decomposition and Views

  • Decomposition

    • Provides a high-level description of the system’s key elements.

    • Involves creating a hierarchy of information with increasing detail:

    • Top-level description.

    • First level of decomposition.

    • Second level of decomposition.

  • Popular Design Methods

    • Not all design problems have existing solutions; designers must decompose to isolate key problems.

    • Common design methods include:

    • Functional Decomposition

      • Partitions functions or requirements into modules, breaking them down into sub-functions assigned to smaller modules.

      • Describes the interaction between modules.

    • Feature-Oriented Decomposition

      • Assigns features to modules, describing the system in terms of services and features.

      • Lower-level designs detail how each feature interacts with the service.

    • Data-Oriented Decomposition

      • Focuses on how data will be partitioned into modules, with high-level designs describing conceptual data structures.

      • Lower-level designs provide details on data distribution among modules.

    • Process-Oriented Decomposition

      • Partitions the system into concurrent processes, identifying main tasks and their coordination.

      • Lower-level designs describe these processes in more detail.

    • Event-Oriented Decomposition

      • Focuses on events the system must handle, assigning responsibilities to different modules.

    • Object-Oriented Design

      • Assigns objects to modules, detailing object types, attributes, and operations.

    • A design is modular when each activity is performed by exactly one software unit, and when inputs and outputs of each unit are well-defined.

  • Component-Based Software Engineering (CBSE)

    • Refers to a method of software development that assembles preexisting components.

    • A component is defined as “a self-contained piece of software with a well-defined set of interfaces.”

    • The goal of CBSE is to support rapid development of new systems and ease maintenance, though it is still largely theoretical with ongoing research.

  • Architectural Views

    • Design views show the various services offered by the system and how they operate together.

    • Types of architectural views include:

    • Decomposition View: Portrays the system as programmable units, often hierarchical.

    • Dependencies View: Illustrates dependencies among software units such as function calls or data reliance.

    • Generalization View: Shows software units that are generalizations or specializations, useful for abstract or extendable units (e.g., inheritance).

    • Execution View: Traditional box-and-arrow diagrams illustrating runtime structure, with components as executing entities and connectors for communication.

    • Implementation View: Maps code units to their respective source files, assisting in finding implementation details.

    • Work-Assignment View: Breaks the design into tasks assignable to project teams, aiding in resource planning and tracking progress.

5.4 Architectural Styles and Strategies

  • Architectural Styles

    • They are large-scale patterns or recognizable structures, acting as templates that coordinate communications and help achieve quality attributes like security.

Common Architectural Styles

  • Pipes-and-Filter

    • Consists of streams of data (pipes) for input/output and transformation of data (through filters); emphasizes independence among filters and ease of reuse.

    • Important properties include:

    • Understanding the system's effects on input and output through filter composition.

    • Simple evolution through addition or substitution of filters.

    • Facilitates concurrent execution of filters.

    • Drawbacks: May complicate the introduction and removal of filters due to I/O restrictions; output from one filter must match the input of the next.

  • Client-Server

    • Composed of servers providing services and clients accessing them via request/reply protocol.

    • Variants include single, distributed, or multiple discrete servers. Typically, servers are passive reacting to client requests with the client knowing the server's identity.

    • Advantages:

    • Improves performance by shuffling components.

    • Enhances modularity and provides flexibility.

    • Reusability in servers offering common services for various applications.

  • Peer-to-Peer (P2P)

    • Each component acts as its own process, serving both as a client and server.

    • Any component can initiate requests, providing scalability and tolerance of failures through data replication.

  • Publish-Subscribe

    • Interaction occurs by broadcasting events, with components subscribing to events they are interested in. They react when events are published, ensuring no knowledge of one another.

  • Repositories

    • Features a central data store accessed by components for operations (traditional databases).

    • Advantage: Centralized management of the system's key data.

  • Layering

    • Consists of hierarchical layers where each layer provides services to the outer layer and acts as a client to the inner layer.

    • Requires protocols to explain interactions between layers.

    • Advantages: High levels of abstraction and relative ease of adding/modifying layers.

    • Disadvantages: Difficult structuring of system layers and potential performance issues due to extra coordination among layers.

  • Combining Architectural Styles

    • Actual software architectures frequently combine multiple styles to cater to specific interactions or layers (e.g., overall client-server architecture with layered server components).

    • Documentation is essential to show relations between models when combining architectural styles.

Secure Software Development: A Security Programmer’s Guide

2 Objectives

  • Understand, analyze, and interpret assets.

  • Identify assets in the requirements.

  • Devise misuse cases.

3 Understanding Requirements

  • Software requirements describe the "what" of software applications. Interpreting these requirements is crucial as often the artifacts are not detailed enough for developers to begin coding.

4 Gathering Software Requirements

  • Challenges include misinterpretation, reliance on user communication, and subjective statements. Eliciting requirements should involve dialogue with stakeholders.

5 Identifying Assets

  • Assets are anything valuable to stakeholders; identifying and classifying them is critical for security and risk management.

    • Valuation: Consider development costs, asset benefits, and additional costs to prevent vulnerability.

6 Devising Misuse Cases

  • Misuse cases identify potential threats by defining actor (attacker), means of attacks, and connecting these attacks with appropriate countermeasures.