7/28/2019 04 Architecture Intro
1/26
1
SE464/CS446/ECE452
Introduction to SoftwareArchitectureInstructor:
Krzysztof Czarnecki
7/28/2019 04 Architecture Intro
2/26
2
Sources used in preparing these slides:
Lecture slides on Architecture by David Garlan, seehttp://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/
Lecture slides on Architecture by Marc Roper andMurray Wood, seehttps://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. ASystem of Patterns. John Wiley & Sons Ltd.,Chichester, UK, 1996
7/28/2019 04 Architecture Intro
3/26
3
Overview
Context
What is software architecture? Example: Mobile Robotics
7/28/2019 04 Architecture Intro
4/26
4
What Is Design?
Requirements specification was about the WHATthe system will do
Design is about the HOW the system will performits 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 non-functional requirements (performance, maintainability,reusability, etc.)
takes target technology into account (e.g., kind ofmiddleware, database design, etc.)
7/28/2019 04 Architecture Intro
5/26
5
Levels of Design Architectural design
also: high-level design
architecture - the overall structure: main modules and theirconnections
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
7/28/2019 04 Architecture Intro
6/26
6
Overview
Context
What is software architecture?
Example: Mobile Robotics
7/28/2019 04 Architecture Intro
7/26
7
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/28/2019 04 Architecture Intro
8/26
8
Definition by Shaw and Garlan Abstractly, software architecture involves the
description ofelements from which systems are
built, interactions among those elements,patterns that guide their composition, andconstraints on these patterns. In general, aparticular system is defined in terms of acollection of components and interactions among
these components. Such a system may in turn beused as a (composite) element in a larger systemdesign. [Garlan&Shaw]
7/28/2019 04 Architecture Intro
9/26
9
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. Subsystemsand components are typically specified indifferent views to show the relevant functionaland nonfunctional properties of a softwaresystem. The software architecture of a system is
an artifact. It is the result of the softwaredevelopment activity. [POSA]
See http://www.sei.cmu.edu/architecture/definitions.html for 60+other definitions
7/28/2019 04 Architecture Intro
10/26
10
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
7/28/2019 04 Architecture Intro
11/26
11
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 productlifetime
Reuse of established engineering knowledge
7/28/2019 04 Architecture Intro
12/26
12
Getting Rid of ArchitectureMartin Fowler, IEEE Software Sep/Oct 2003
Architecture is the decisions that you wish youcould get right early in a project (Ralph Johnson)
Architecture is things that people perceive ashard to change
Goal in agile approaches: reducing theirreversibility of decisions
Technology can sometimes turn things that usedto be hard into easy ones
E.g., changing the database schema
7/28/2019 04 Architecture Intro
13/26
13
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 toexplain how the system realizes these use cases
at a high level Use past and proven experience by
applying architectural styles and patterns
7/28/2019 04 Architecture Intro
14/26
14
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
7/28/2019 04 Architecture Intro
15/26
15
Overview
Context
What is software architecture?
Example: Mobile Robotics
7/28/2019 04 Architecture Intro
16/26
16
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 rocksample, avoid obstacles
R2: Allow for uncertainty, e.g., continue to operateeven if inconsistent sensor readings
R3: Account for safety, e.g., certain conditions mustnot be violated
R4: Allow for flexibility, e.g., easy reconfiguration,adding new algorithms and solutions
7/28/2019 04 Architecture Intro
17/26
17
Solution 1: Control Loop
Controller
Active component of the robot
Actuators Sensors
Environment
7/28/2019 04 Architecture Intro
18/26
18
Solution 1: Control Loop R1: Simple to implement for predictable interaction; hard
to handle interaction in unpredictable environments (manyindustrial robots use this architecture)
R2: Internal uncertainty can be resolved by repeated trials;no other sophisticated mechanisms available (such asdelegation to specialized agents)
R3: Safety supported well through simplicity (reducedrisk of error)
R4: Major components (supervisor, sensors, motors) areseparated and can be changed individually; moresophisticated configuration not well supported (e.g., fine-tuning and reconfiguring algorithms)
7/28/2019 04 Architecture Intro
19/26
19
Solution 2: Layered ArchitectureSupervisor
Environment
Global planning
Control
Navigation
Real-world modeling
Sensor integration
Sensor interpretation
Robot control
7/28/2019 04 Architecture Intro
20/26
20
Solution 2: Layered Architecture R1: Organizes operation into different areas, but does not fit the
actual data and control-flow patterns; direct communicationbetween nonadjacent layers may be necessary
R2: Internal uncertainty may need to be resolved in differentlayers, or even worse, by the interaction of nonadjacent layers,e.g., inconsistent sensor readings may sometimes beconsolidated at the sensor interpretation or integration layers,
but this may also require the context available only in the worldmodel layer
R3: Abstraction supports safety (reduced risk of error)
R4: The complex interlayer dependencies make it hard to addand replace components.
7/28/2019 04 Architecture Intro
21/26
21
Solution 3: Implicit Invocation
TaskTask
Task Task
Task
Ether
Exception
Dispatched
message
Wiretap
Message
7/28/2019 04 Architecture Intro
22/26
22
Solution 3: Implicit InvocationDynamic, self-organizing substructures, e.g., a task hierarchy
Gatherrock
Go to
position
Grab
rock
Lift
rock
Move
left
Move
forward
7/28/2019 04 Architecture Intro
23/26
23
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
7/28/2019 04 Architecture Intro
24/26
24
Solution 4: Blackboard
Perception subsystem
(gets raw sensor input and
integrates into coherent
interpretation)
Lookout
(monitors the
Environment
for landmarks)
Capitan
(overall
supervisor)
Map Navigator
(high-level
path planner)
Pilot
(low-level
path planner
and motor
controller)
Sensor1
Sensor2 Sensor3
SensorN
Blackboard
(common state incl. Consolidated
Sensor readings, the path,
world representation, etc.)
7/28/2019 04 Architecture Intro
25/26
25
Solution 4: Blackboard R1: Components register interest for certain info with the
blackboard; interaction with unpredictable environmentcan be achieved through observation
R2: Internal uncertainty can be resolved in the blackboard;the individual components may be assigned rights andpriorities for correcting certain type of information
R3: Safety may be supported by placing supervisorsenforcing certain conditions plus the blackboard can be
easily inspected, monitored, and managed
R4: Very flexible; can add and replace components byregistering them with the blackboard
7/28/2019 04 Architecture Intro
26/26
26
Comparison
++-+-Flexibility
++++-+-Performance
+++-+-Safety
+++-+-Fault tolerance
++-+--Dealing with
uncertainty
++-+-Task
coordination
BlackboardImplicit
invocation
LayersControl
loop
Recommended