SE464/CS446/ECE452

Introduction to Software Architecture

Instructor: Krzysztof Czarnecki

 Sources used in preparing these slides:

Lecture slides on Architecture by David Garlan, see
http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/

Lecture slides on Architecture by Marc Roper and Murray Wood, see

https://www.cis.strath.ac.uk/teaching/ug/classes/52.440/

M. Shaw and D. Garlan. Software Architecture: Perspectives on a Emerging Discipline. Prentice Hall, Englewood Cliffs, NJ, 1996 F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture. A System of Patterns. John Wiley & Sons Ltd., Chichester, UK, 1996 2

Overview
Context What is software architecture? Example: Mobile Robotics

What Is Design?
Requirements specification was about the WHAT the system will do Design is about the HOW the system will perform its functions
provides the overall decomposition of the system allows to split the work among a team of developers also lays down the groundwork for achieving nonfunctional requirements (performance, maintainability, reusability, etc.) takes target technology into account (e.g., kind of middleware, database design, etc.)
4

Levels of Design
Architectural design
also: high-level design architecture - the overall structure: main modules and their connections design that covers the main use-cases of the system addresses the main non-functional requirements (e.g., throughput, reliability) hard to change

Detailed design
also: low-level design the inner structure of the main modules may take the target programming language into account detailed enough to be implemented in the programming language

Overview
Context What is software architecture? Example: Mobile Robotics

What Is Software Architecture?

Captures the gross structure of a system
How it is composed of interacting parts How the interactions take place Key properties of the parts

Provides a way of analysing systems at a high level of abstraction Illuminates top-level design decisions
7

Definition by Shaw and Garlan

Abstractly, software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. In general, a particular system is defined in terms of a collection of components and interactions among these components. Such a system may in turn be used as a (composite) element in a larger system design. [Garlan&Shaw]
8

Definition by Buschmann et al.

A software architecture is a description of the subsystems and components of a software system and the relationships between them. Subsystems and components are typically specified in different views to show the relevant functional and nonfunctional properties of a software system. The software architecture of a system is an artifact. It is the result of the software development activity. [POSA] See http://www.sei.cmu.edu/architecture/definitions.html for 60+ other definitions

Issues Addressed by an Architectural Design

Gross decomposition of a system into interacting components
Typically hierarchical Using rich abstractions for glue Often using common design idioms/styles

Emergent system properties

Performance, throughput, latencies Reliability, security, fault tolerance, evolvability

Rationale
Relates requirements and implementations

Envelope of allowed change

Load-bearing walls Design idioms and styles
10

Good Properties of an Architecture

Good architecture (much like good design):
Result of a consistent set of principles and techniques, applied consistently through all phases of a project Resilient in the face of (inevitable) changes Source of guidance throughout the product lifetime Reuse of established engineering knowledge
11

Getting Rid of Architecture

Martin Fowler, IEEE Software Sep/Oct 2003 Architecture is the decisions that you wish you could get right early in a project (Ralph Johnson) Architecture is things that people perceive as hard to change Goal in agile approaches: reducing the irreversibility of decisions Technology can sometimes turn things that used to be hard into easy ones
E.g., changing the database schema
12

Architecture Development
Unified Process:
Focus on implementing the most valuable and critical use cases first Produce an architectural description by taking those design elements that are needed to explain how the system realizes these use cases at a high level

Use past and proven experience by applying architectural styles and patterns
13

Architectural Styles
The architecture of a system includes
Components: define the locus of computation
Examples: filters, databases, objects, ADTs

Connectors: define the interactions between components

Examples: procedure call, pipes, event announce

An architectural style defines a family of architectures constrained by

Component/connector vocabulary Topology Semantic constraints
14

Overview
Context What is software architecture? Example: Mobile Robotics

15

Example: Mobile Robotics

Design the control software for a mobile robot with the following requirements:
R1: Accommodate deliberative and reactive behavior, e.g., achieve an overall goal such as collecting a rock sample, avoid obstacles R2: Allow for uncertainty, e.g., continue to operate even if inconsistent sensor readings R3: Account for safety, e.g., certain conditions must not be violated R4: Allow for flexibility, e.g., easy reconfiguration, adding new algorithms and solutions
16

Solution 1: Control Loop

Controller
Active component of the robot

Actuators

Sensors

Environment
17

Solution 1: Control Loop

R1: Simple to implement for predictable interaction; hard to handle interaction in unpredictable environments (many industrial robots use this architecture) R2: Internal uncertainty can be resolved by repeated trials; no other sophisticated mechanisms available (such as delegation to specialized agents) R3: Safety supported well through simplicity (reduced risk of error) R4: Major components (supervisor, sensors, motors) are separated and can be changed individually; more sophisticated configuration not well supported (e.g., finetuning and reconfiguring algorithms)
18

Solution 2: Layered Architecture

Supervisor Global planning Control Navigation Real-world modeling Sensor integration Sensor interpretation Robot control

Environment
19

Solution 2: Layered Architecture

R1: Organizes operation into different areas, but does not fit the actual data and control-flow patterns; direct communication between nonadjacent layers may be necessary R2: Internal uncertainty may need to be resolved in different layers, or even worse, by the interaction of nonadjacent layers, e.g., inconsistent sensor readings may sometimes be consolidated at the sensor interpretation or integration layers, but this may also require the context available only in the world model layer R3: Abstraction supports safety (reduced risk of error) R4: The complex interlayer dependencies make it hard to add and replace components.
20

Solution 3: Implicit Invocation

Task
Message

Task
Exception

Ether
Dispatched message Wiretap

Task Task
21

Task

Solution 3: Implicit Invocation

Dynamic, self-organizing substructures, e.g., a task hierarchy Gather rock

Go to position Move left Move forward

Grab rock

Lift rock

22

Solution 3: Implicit Invocation

R1: Can deal with unpredictable environments using exception and observation mechanisms R2: Less clear how internal uncertainty is to be handled (e.g., inconsistent sensor readings) R3: Safety may be supported by placing supervisors enforcing certain conditions (aka defensive programming); may still result in complicated interactions with some unpredictability R4: Very flexible; can add and replace components by registering them
23

Solution 4: Blackboard
Lookout (monitors the Environment for landmarks) Capitan (overall supervisor) Map Navigator (high-level path planner) Pilot (low-level path planner and motor controller)

Blackboard (common state incl. Consolidated Sensor readings, the path, world representation, etc.) Perception subsystem (gets raw sensor input and integrates into coherent SensorN interpretation) Sensor2 Sensor3
24

Sensor1

Solution 4: Blackboard
R1: Components register interest for certain info with the blackboard; interaction with unpredictable environment can be achieved through observation R2: Internal uncertainty can be resolved in the blackboard; the individual components may be assigned rights and priorities for correcting certain type of information R3: Safety may be supported by placing supervisors enforcing certain conditions plus the blackboard can be easily inspected, monitored, and managed R4: Very flexible; can add and replace components by registering them with the blackboard
25

Comparison
Control Layers Implicit loop invocation Task coordination Dealing with uncertainty Fault tolerance Safety Performance Flexibility ++++++++++ ++ + ++ + Blackboard + + + + + +
26