Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance To explain why multiple models are required to document a software architecture To describe types of architectural model that may be used

What is Architecture? A high-level model of a thing Describes critical aspects of the thing Understandable to many stakeholders Allows evaluation of the thing’s properties before it is built Provides well understood tools and techniques for constructing the thing from its blueprint Which aspects of a software system are architecturally relevant? How should they be represented most effectively to enable stakeholders to understand, reason, and communicate about a system before it is built? What tools and techniques are useful for implementing an architecture in a manner that preserves its properties?

What is Software Architecture? A software system’s blueprint Its components Their interactions Their interconnections Informal descriptions Boxes and lines Informal prose A shared, semantically rich vocabulary Remote procedure calls (RPCs) Client-Server Pipe and Filer Layered Distributed Object-Oriented

From Requirements to Architecture From problem definition to requirements specification Determine exactly what the customer and user want Specifies what the software product is to do From requirements specification to architecture Decompose software into modules with interfaces Specify high-level behavior, interactions, and non-functional properties Consider key tradeoffs Schedule vs. Budget Cost vs. Robustness Fault Tolerance vs. Size Security vs. Speed Maintain a record of design decisions and traceability Specifies how the software product is to do its tasks

Focus of Software Architectures Two primary foci System Structure Correspondence between requirements and implementation A framework for understanding system-level concerns Global rates of flow Communication patterns Execution Control Structure Scalability Paths of System Evolution Capacity Throughput Consistency Component Compatibility

Why Software Architecture? A key to reducing development costs Component-based development philosophy Explicit system structure A natural evolution of design abstractions Structure and interaction details overshadow the choice of algorithms and data structures in large/complex systems Benefits of explicit architectures A framework for satisfying requirements Technical basis for design Managerial basis for cost estimation & process management Effective basis for reuse Basis for consistency, dependency, and tradeoff analysis Avoidance of architectural erosion

What is the Problem? This is a simple software system!

The Usual Tool: Design Abstraction We have to do better!

Architectural Abstraction Components Connectors Events

Definitions of Software Architecture Perry and Wolf Software Architecture = { Elements, Form, Rationale } what how why Shaw and Garlan Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. Kruchten Software architecture deals with the design and implementation of the high-level structure of software. Architecture deals with abstraction, decomposition, composition, style, and aesthetics.

Architectural design process System structuring The system is decomposed into several principal sub-systems Communications between these sub-systems are identified Control modelling A model of the control relationships between the different parts of the system is established Modular decomposition The identified sub-systems are decomposed into modules

Key Architectural Concepts Three canonical building blocks components connectors configurations A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems A module is a system component that provides services to other components but would not normally be considered as a separate system

Components A component is a unit of computation or a data store Components are loci of computation and state clients servers databases filters layers ADTs A component may be simple or composite composite components describe a (sub)system an architecture consisting of composite components describes a system of systems

Connectors A connector is an architectural element that models interactions among components rules that govern those interactions Simple interactions procedure calls shared variable access Complex and semantically rich interactions client-server protocols database access protocols asynchronous event multicast piped data streams

Configurations/Topologies An architectural configuration or topology is a connected graph of components and connectors that describes architectural structure proper connectivity concurrent and distributed properties adherence to design heuristics and style rules Composite components are configurations

Scope of Software Architectures Every system has an architecture. Details of the architecture are a reflection of system requirements and trade-offs made to satisfy them Possible decision factors Performance Compatibility with legacy software Planning for reuse Distribution profile Current and Future Safety, Security, Fault tolerance requirements Evolvability Needs Changes to processing algorithms Changes to data representation Modifications to the structure/functionality

Example Architecture – Compiler Sequential Parallel

CASE toolset architecture

Version management system

Packing robot control system

Film and picture library

Analogies to Software Architecture Hardware architecture small number of design elements scale by replication of (canonical) design elements Network architecture focus on topology only a few topologies considered e.g., star, ring, grid Building architecture multiple views styles

Architectural models Different architectural models may be produced during the design process Each model presents different perspectives on the architecture Static structural model that shows the major system components Dynamic process model that shows the process structure of the system Interface model that defines sub-system interfaces Deployment model shows the relationship between system elements and hosts

System structuring Concerned with decomposing the system into interacting sub-systems The architectural design is normally expressed as a block diagram presenting an overview of the system structure More specific models showing how sub-systems share data, are distributed, and interface with each other may also be developed

Key points The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model Large systems rarely conform to a single architectural model Key architectural concepts are components, connectors, and configurations