Software Architectural Design - Part 1

Why Architecture?

The architecture is not the operational software. Rather, it is a representation that enables a software engineer to:

• analyze the effectiveness of the design in meeting its stated requirements,
• consider architectural alternatives at a stage when making design changes is still relatively easy, and
• reduce the risks associated with the construction of the software.

Why is Architecture Important?

• Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system.
• The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.
• Architecture “constitutes a relatively small, intellectually graspable mode of how the system is structured and how its components work together” [BAS03].

Architectural Descriptions

• The IEEE Computer Society has proposed IEEE-Std-1471-2000, Recommended Practice for Architectural Description of Software-Intensive System, [IEE00]
  • to establish a conceptual framework and vocabulary for use during the design of software architecture,
  • to provide detailed guidelines for representing an architectural description, and
  • to encourage sound architectural design practices.
• The IEEE Standard defines an architectural description (AD) as a “a collection of products to document an architecture.”
  • The description itself is represented using multiple views, where each view is “a representation of a whole system from the perspective of a related set of [stakeholder] concerns.”

Architectural Genres

• Genre implies a specific category within the overall software domain.
• Within each category, you encounter a number of subcategories.
  • For example, within the genre of buildings, you would encounter the following general styles: houses, condos, apartment buildings, office buildings, industrial building, warehouses, and so on.
  • Within each general style, more specific styles might apply. Each style would have a structure that can be described using a set of predictable patterns.

Architectural Styles

Each style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

• Data-centered architectures
• Data flow architectures
• Call and return architectures
• Object-oriented architectures
• Layered architectures

Data-Centered Architecture

Data Flow Architecture

Call and Return Architecture

Layered Architecture

Architectural Patterns

• Concurrency—applications must handle multiple tasks in a manner that simulates parallelism
  • operating system process management pattern
  • task scheduler pattern
• Persistence—Data persists if it survives past the execution of the process that created it. Two patterns are common:
  • a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture
  • an application level persistence pattern that builds persistence features into the application architecture
• Distribution— the manner in which systems or components within systems communicate with one another in a distributed environment
  • A broker acts as a ‘middle-man’ between the client component and a server component.

Architectural Design

• The software must be placed into context
  • the design should define the external entities (other systems, devices, people) that the software interacts with and the nature of the interaction
• A set of architectural archetypes should be identified
  • An archetype is an abstraction (similar to a class) that represents one element of system behavior
• The designer specifies the structure of the system by defining and refining software components that implement each archetype

Reference: Software Engineering A Practitioner's Approach (7th Ed.) ~ Roger S. Pressman