1. 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

2. 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?

3. 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

4. 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

5. 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

6. 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

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

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

9. Architectural Abstraction
Components
Connectors
Events

10. 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.

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. Example Architecture – Compiler
Sequential
Parallel

18. CASE toolset architecture

19. Version management system

20. Packing robot control system

21. Film and picture library

22. 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

23. 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

24. 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

25. 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