Software Architecture

Chapter 2: Software Architecture

Acronyms

Acronym	Full Form
AD	Architecture Description
ADL	Architecture Description Language
API	Application Programming Interface
ASR	Architecturally Significant Requirement
ATAM	Architectural Tradeoff Analysis Method
IDL	Interface Description Language
MVC	Model View Controller
QAW	Quality Attribute Workshop
RA	Reference Architecture
REST	Representational State Transfer
SAAM	Software Architecture Analysis Method
UML	Unified Modeling Language

Introduction

This chapter covers software architecture, which has grown into a significant discipline warranting its own Knowledge Area (KA), separate from Software Design. Software architecture is examined from several perspectives, including its fundamental concepts, its representation in work products, the processes and methods used to create it, and its analysis and evaluation.

Breakdown of Topics for Software Architecture

The Software Architecture KA is broken down into the following major topics:

• Software Architecture Fundamentals
• Software Architecture Description
• Software Architecture Process
• Software Architecture Evaluation

1. Software Architecture Fundamentals

1.1 The Senses of “Architecture”

The term “architecture” is used in several ways:

1. As a discipline: The art and science of constructing software-intensive systems, involving a set of concepts, principles, and processes.
2. As a process: The activities through which the discipline is applied. Software architecture is a key part of the larger software design process, which is often divided into architectural, high-level, and detailed design stages.
3. As an outcome: The result of applying the architectural discipline and process. This outcome is expressed in an Architecture Description (AD).

Definitions of architecture have evolved from a focus on structure (e.g., “The organizational structure of a system”) to a more comprehensive view. A modern definition describes architecture as the “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.” Key ideas here are that architecture is about what is fundamental and that it considers the system within its broader environment.

1.2 Stakeholders and Concerns

A software system has many stakeholders (e.g., customers, users, developers, operators), each with different interests. These interests are termed concerns, a concept based on Dijkstra’s “separation of concerns,” which advocates for studying different aspects of a subject in isolation.

• What is considered fundamental about a system depends on the stakeholder’s concerns.
• Concerns can be functional, non-functional, or constraints, and they can be influenced by developmental, business, operational, and social factors.
• Examples of architectural concerns include performance, security, maintainability, cost, and usability.
• Concerns evolve over the system’s life cycle. For instance, energy efficiency has become a more prominent concern recently due to growing environmental awareness.

1.3 Uses of Architecture

A system’s architecture has several primary uses:

• Shared Understanding: It provides a common model for stakeholders to guide the system’s design and construction.
• Analysis and Evaluation: It serves as a basis for analyzing design alternatives before significant investment is made.
• Reverse Engineering: It helps in understanding an existing system for maintenance or modification.
• Organizational Structure: Per Conway’s Law, a system’s architecture often mirrors the communication structure of the organization that built it. This can be used to enhance team communication.
• Reusability: A well-planned architecture forms the basis for creating reusable components and developing software product lines.

2. Software Architecture Description

For complex systems, a tangible representation of the architecture is essential for team collaboration, analysis, and guiding implementation. These work products are called Architecture Descriptions (ADs). An AD documents the architecture for stakeholders, serving as a blueprint for designers, programmers, testers, and maintainers.

2.1 Architecture Views and Viewpoints

Because different stakeholders have different concerns, an AD often uses multiple architecture views.

• An architecture view represents one or more aspects of an architecture to address specific concerns. For example:
  • Logical View: Shows how functional requirements are satisfied.
  • Process View: Depicts concurrency aspects.
  • Physical View: Shows how the system is deployed on hardware.
  • Development View: Breaks the design into implementation units.
• An architecture viewpoint defines the conventions (notations, models, rules) for constructing and interpreting a specific type of view. It links stakeholder concerns to representation conventions. Common viewpoints include the module, component-and-connector, information, and deployment viewpoints.

The use of multiple views can lead to the “multiple views problem,” where inconsistencies arise between views. This can be managed by either deriving all views from a single, unified model (projective approach) or by defining correspondence rules to link elements across different views (synthetic approach).

2.2 Architecture Patterns, Styles, and Reference Architectures

• An architectural style is a particular manner of construction that defines a family of systems in terms of their large-scale organization (e.g., layered, client-server, pipes-and-filters).
• An architectural pattern is a common, reusable solution to a recurring problem within a specific context. The line between styles and patterns is blurry; a style can often be expressed as a pattern.
• Examples of architectural patterns and styles include:
  • General Structures: Layered, Blackboard, Microservices
  • Distributed Systems: Client-Server, Broker, Publish-Subscribe, REST
  • User Interaction: Model-View-Controller (MVC)
• A Reference Architecture (RA) is a standardized architecture that guides the development of other architectures within a specific domain (e.g., automotive, healthcare). It captures commonalities to promote interoperability, integration, and ease of development.

2.3 Architecture Description Languages and Architecture Frameworks

• An Architecture Description Language (ADL) is a formal language used to express a software architecture. ADLs provide a precise syntax and semantics for describing architectural elements and their relationships, often enabling analysis or code generation. UML is frequently used as an ADL.
• An architecture framework establishes the conventions, principles, and practices for creating ADs within a specific domain or community. It often consists of a set of interlocking viewpoints or ADLs (e.g., AUTOSAR for the automotive industry).

2.4 Architecture as Significant Decisions

Architectural design is a creative process involving a series of decisions that have a profound impact on the system.

• Architecture Rationale: This is the explicit documentation of why an architectural decision was made, including the alternatives considered and the trade-offs made. Recording rationale helps future teams understand the design context.
• Architectural Technical Debt: This concept reflects the long-term consequences of design decisions made today. Deferring important design work (e.g., forgoing modularity to meet a deadline) creates a “debt” that must be “paid” later, often through costly refactoring.

3. Software Architecture Process

3.1 Architecture in Context

Architectural design occurs in various contexts:

• Traditional Lifecycle: It’s a distinct stage driven by requirements.
• Product Lines: A reference architecture is created first, which then guides the development of individual product instances.
• Agile Approaches: A formal architecture design stage is often absent. The architecture is said to “emerge” from development cycles, though this can be risky for systems with critical non-functional requirements.

Architecture is distinct from design in that it often deals with a wider range of concerns and helps shape requirements, whereas design typically works with an established set of requirements.

3.2 Architectural Design

Architectural design is an iterative process composed of three major activities:

1. Architecture Analysis: Gathers and formulates Architecturally Significant Requirements (ASRs)—those requirements that influence the architecture.
2. Architecture Synthesis: Develops candidate architectural solutions to address the ASRs, making trade-offs between different design options.
3. Architecture Evaluation: Validates whether the synthesized solutions satisfy the ASRs and determines where rework is needed.

3.3 Architecting in the Large

Software architecting extends beyond the initial design phase to encompass the entire life cycle. It includes activities such as:

• Architecture Implementation: Overseeing the implementation to ensure it conforms to the architecture.
• Architecture Maintenance: Managing the evolution of the architecture after deployment.
• Architecture Management: Managing an organization’s entire portfolio of architectures.
• Architecture Knowledge Management: Sharing and reusing architectural assets (e.g., decisions, patterns, lessons learned) across the organization.

4. Software Architecture Evaluation

Evaluation is crucial for assessing the quality of an architecture.

4.1 “Goodness” in Architecture

What makes an architecture “good” is multi-faceted. Inspired by the Roman architect Vitruvius, a good software architecture should exhibit:

• Strength (Firmitas): Is it robust and able to evolve?
• Utility (Utilitas): Is it fit for its intended purpose?
• Beauty (Venustas): Is it clear, understandable, and cost-effective to build?

A good architecture successfully addresses all stakeholder concerns and manages the trade-offs between them. The Architecture Tradeoff Analysis Method (ATAM) is a well-known method for systematically evaluating an architecture based on quality attribute trade-offs.

4.2 Reasoning about Architectures

Effective evaluation relies on robust Architecture Descriptions (ADs). Different concerns require specialized representations and analysis techniques. For example, security analysis may rely on threat models, while performance analysis may use queuing models. In the absence of formal documentation, evaluation must rely on the knowledge of project participants. Use cases are often employed to check an architecture’s completeness.

4.3 Architecture Reviews

Reviews are a common and effective technique for assessing an architecture’s quality and identifying risks. Reviews can be:

• Informal and expertise-based.
• Structured, using checklists.
• Active reviews, where reviewers perform specific activities to obtain information rather than just reading documentation.

4.4 Architecture Metrics

An architecture metric is a quantitative measure of an architectural characteristic. Metrics help in objectively assessing quality.

• Structural Metrics: Many metrics are adapted from code analysis, such as module coupling, cohesion, and cyclomatic complexity.
• Process Metrics: In continuous development paradigms like DevOps, metrics often focus on process outcomes that reflect architectural quality, such as lead time for changes, deployment frequency, and change failure rate.