04 Architecture Intro

7/28/2019 04 Architecture Intro

1/26

1

SE464/CS446/ECE452

Introduction to SoftwareArchitectureInstructor:

Krzysztof Czarnecki


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


3/26

3

Overview

Context

What is software architecture? Example: Mobile Robotics


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


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


6/26

6

Overview

Context

What is software architecture?

Example: Mobile Robotics


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


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]


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


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


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


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


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


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


15/26

15

Overview

Context

What is software architecture?

Example: Mobile Robotics


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


17/26

17

Solution 1: Control Loop

Controller

Active component of the robot

Actuators Sensors

Environment


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)


19/26

19

Solution 2: Layered ArchitectureSupervisor

Environment

Global planning

Control

Navigation

Real-world modeling

Sensor integration

Sensor interpretation

Robot control


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.


21/26

21

Solution 3: Implicit Invocation

TaskTask

Task Task

Task

Ether

Exception

Dispatched

message

Wiretap

Message


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


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


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


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


26/26

26

Comparison

++-+-Flexibility

++++-+-Performance

+++-+-Safety

+++-+-Fault tolerance

++-+--Dealing with

uncertainty

++-+-Task

coordination

BlackboardImplicit

invocation

LayersControl

loop

Documents

04 Architecture Intro