software architecture 2001-2002 m.r.v. chaudron m.r.v

1

MRV Chaudron

Software Architecting

Prof. Dr. M.R.V. Chaudron

[email protected]

Chalmers | Gothenburg University

Sweden

1

MRV Chaudron

ScheduleWeek Date Time Lecture Reading Note

36 L1 4 sept 13:00 – 15:00 Introduction & Organization

37 L2 11 sept 13:00 – 14:30 Architecting Process & Views Ch 1 & 2

37 S1 12 sept 10:15 – 12:00 << Supervision/Assignment>>

38 L3 18 sept 13:00 - 15:00 Requirements & Quality Attributes Ch 3 & 4


38 L4 20 sept 13:15 – 15:00 Architectural Styles 1 Ch 13

39 L5 25 sept 13:15 – 15:00 Architectural Styles 2 Ch 15 & 16


39 L6 27 sept 13:15 – 15:00 Roles and Responsibilities Check Canvas

40 L7 2 Oct 13:15 – 15:00 To be determined UG

40 S4 3 Oct 10:15 – 12:00 << Supervision/Assignment>> UG

41 4 Oct 13:00 – 15:00 To be determined UG

42 L8 9 Oct 13:15 – 15:00 Technical Debt (t.b.confirmed) PhD

defence

41 S5 10 Oct 10:15 – 12:00 << Supervision/Assignment>>

42 L9 16 Oct 13:15 – 15:00 Design Principles Ch 21

42 S6 17 Oct 10:15 – 12:00 << Supervision/Assignment>> check!

43 L10 18 Oct 13:15 – 15:00 Architecture Evaluation tbd

43 L11 23 Oct 13:15 – 15:00 Reverse Engineering & Correspondence

43 L12 24 Oct 13:15 – 15:00 To be determined (slack) Ch 20

43 L13 25 Oct 13:00 – 15:00 To be determined (exam practice?)

mailto:[email protected]

2

MRV Chaudron

Supervision session• Group formation

• Hand in ‘pairs of names’

• We will randomly allocate 2 pairs into a team of 4 students

• Peer-evaluation for assessing individual contribution to assignments

• Assignment follows typical steps:

• Understand requirements (apply knowledge from RE course)

• Identify stakeholders

• Identify architectural drivers

• Iterate:

• Identify components & behaviours

• Use patterns and tactics to achieve quality properties

• Hand in: RE doc & SW ARCH DESIGN doc

MRV Chaudron

Software Architecture Books

• Software Architecture in Practice, 3rd Edition,

L. Bass, P. Clements, R. Kazman,

SEI Series in Software Engineering,

Addison-Wesley, 2003

• Software Architecture: Perspectives on an

Emerging Discipline, Mary Shaw, David Garlan,

242 pages, 1996, Prentice Hall

• Recommended Practice for Architectural Description,

IEEE STD 1471-2000, 23 pages

4

3

MRV Chaudron

UML book

• UML Distilled

4th or 3rd edition

MRV Chaudron

Outline

6

• Recap : What is Software Architecture?

• Stakeholders

• How to do Software Architecting?

• 4+1 Views

• Concluding Remarks

4

MRV Chaudron

What is Software Architecture?

• recap

MRV Chaudron


8

Classic Definitions 1

An architecture is the set of significant decisions about

• the organization of a software system,

• the selection of the structural elements and their interfaces by which

the system is composed, together with their behaviour as specified in

the collaborations among those elements,

• the composition of these structural and behavioural elements into

progressively larger subsystems,

• the architectural style that guides this organization

The UML Modeling Language User Guide, Addison-Wesley, 1999

Booch, Rumbaugh, and Jacobson

5

MRV Chaudron

SE, Software Architecture, Hans van Vliet, ©2008 9

MRV Chaudron

What is a subsystem?A sub-system is a logical grouping of functionality

• Operations on the same data

• Functionality that belongs to the same responsibility

Nice to have’s:

• Encapsulates functionality/data (information hiding)

• Explicit interfaces

• Explicit dependencies

6

MRV Chaudron

Connectors

What is a connector?

A connector is an architectural element tasked with

effecting and regulating interactions among

components

Often implicit: arrow means ‘request-response’

Many alternatives possible:

fire & forget, blackboard, publish/subscribe, …

MRV Chaudron


12

Definition 2

The fundamental organization of a system embodied by its components, their relationships to each other and to the environment and the principles guiding its design and evolution

IEEE Standard P1471 Recommended Practice forArchitectural Description of Software-Intensive Systems

7

MRV Chaudron

A B

C D

bus

Connector example

MRV Chaudron

Architecture Model with

explicit connectors

8

MRV Chaudron

Why, When and for Whom?

• Why architecting?

• For whom?

• When architecting?

MRV Chaudron

Developing a shared vision

Requirements emerge

from a process of

co-operative learning in

which they are explored,

prioritized, negotiated,

evaluated, and

documented.

19

9

MRV Chaudron

20

Software Architecture & Quality

• The notion of quality is central in software architecting: a software architecture is devised to gain insight in the qualities of a system at the earliest possible stage.

• Some qualities are observable via execution: performance, security, availability, functionality, usability

• And some are not observable via execution, but in the development process: modifiability, portability, reusability, integrability, testability

MRV Chaudron

Architecting = Balancing Objectives

21

StructureFunctionality

Component interfacesComponent configurations

Local/Global BehaviorControl modes

Activities/TransactionsC&S protocols

GeneralScalabilityFlexibility

MaintainabilityReusabilityOpenness

User-FriendlinessCostprize

•••

Composability

Interoperability

Reusability

Dependability

Performance

TimelinessReliabilityAvailabilitySafetySecurityRobustness

Functional dimensions

Extra-Functional dimensions

10

MRV Chaudron

Some more examples of

*ilities

Accessibility, Understandability, Usability, Generality, Operability,

Simplicity, Mobility, Nomadicity, Portability, Accuracy, Efficiency,

Footprint, Responsiveness, Scalability, Schedulability, Timeliness, CPU

utilization, Latency, Throughput, Concurrency, Flexibility, Changeability,

Evolvability, Extensibility, Modifiability, Tailorability, Upgradeability,

Expandability, Consistency, Adaptability, Composability, Interoperability,

Openness, Integrability, Accountability, Completeness, Conciseness,

Correctness, Testability, Traceability, Coherence, Analyzability,

Modularity, Reusability, Configurability, Distributeability, Availability,

Confidentiality, Integrity, Maintainability, Reliability, Safety, Security,

Affordability, Serviceablility, …

22

MRV Chaudron

ISO standard on Software

Product Quality

11

MRV Chaudron

Extra Functional Properties

25

Performance

Reliability

Timeliness

Schedulability

Scalability

EfficiencyCPU, Memory Use

Maintainability

Essential system engineering problem:

• a plurality of contradictory goals

• a plurality of means (technology, process)

each of which provides a varying degree of help or hindrance in achieving a given goal

System

MRV Chaudron

Development Objectives of Software Architecture

• Management of complexity

• Define a model of a system that is intellectually manageable

• Answering of what-if questions

• Allows stakeholders to evaluate different architectural solutions and their consequences (e.g. on satisfying requirements)

• Feasibility study & risk analysis

• Analysis of various (non-)functional features of the future product; identification of possible problems during development, production & operation

• Project estimation, planning & organization

• Allocation of components to concurrent teams

12

MRV Chaudron


Complexity Analysis: EMsn has quite many connections. Maybe we should split it up.

MRV Chaudron


What if we change CSMS?

13

MRV Chaudron



MRV Chaudron



14

MRV Chaudron

What if

• What happens if the load peaks?

• What happens if this connection fails?

• What happens if this technology changes?

• …

MRV Chaudron

Feasibility and Risk

• Is there a business case for the system?

• Will the system be affordable?

• Will the system be able to handle peak load?

• Is the security/compression/… fast enough?

Risks

• Which things can go wrong and what would their consequences be?

• Both development and operation

• Which things do we not yet know enough about?

15

MRV Chaudron


Team 510 man-years

Team 6

24 man-years

Team 312 man-years

Team 4

50 man-years

Team 230 man-years

Planning & Estimation

Team 110 man-years

MRV Chaudron

Software Architecting =

Designing

Respond to change:

• Iterative

• Feedback

• Evolve

16

MRV Chaudron

Forces that affect the Design

The "software forces" image of below is from Grady Booch's Models09 keynote, The Other Side of Model Driven Development (2009):

"In physics, a force is any influence that causes an object to undergo a certain change, either concerning its movement, direction, or geometrical construction.“(wikipedia, Force)

MRV Chaudron

Architectural Drivers• Architectural drivers are the design forces that will influence the

early design decisions the architects make

• Architectural drivers are not all of the requirements for a system, but they are those requirements that are most influential to the architectures design.

• The ’art’ of the architect is to identify which forces have the strongest effect on the architecture-design.

37

Design

http://www.cs.colostate.edu/models09/TechnicalPresentations/0K3OtherSideOfMDD.pdf

http://en.wikipedia.org/wiki/Force

17

MRV Chaudron

Positioning Architecture

38

The question:

Require-ments

The answer:

Architecture

Deployment:

Executable

Implementation:

Source code

• Features

• Use cases

• Dependability

Timing

Reliability

Security

• Quality

• Standards

• Etc.

• HL-Design

Components

Interfaces

Interactions

• Styles

• Constraints

• Guidelines

• Reuse

• Etc.

• Decomposition

• Algorithms

• Data structures

• Distribution

• Scheduling

• Recovery

• Language

• Encryption

• Etc.

• Memory

allocation

• Dynamic

Instantiation

• Call stacks

• Garbage

collection

• Machine code

• Etc.

MRV Chaudron

Levels of architecture*

39* Mowbray and Malveau

Macro-architecture Frameworks

Micro-architecture Design patternsObserverupdate()

Subjectattach(Observer)detach(Observer)notify()

ConcreteObserverupdate()

ConcreteSubjectgetState()

forall o in observers

o.update()

System architecture Subsystem

Enterprise architecture

Application architecture Application

18

MRV Chaudron

Outline

41

• Recap : What is Software Architecture?

• Stakeholders

• How to do Software Architecting?

• 4+1 Views

• Concluding Remarks

MRV Chaudron

SE, Software Architecture, Hans van Vliet, ©200842

The Role of the Architect

client,

usersarchitect developers

appearance,

behaviour

construction,

co-operation

architectural

design

visualises prescribes

requirements solutions

createsassess assess

19

MRV Chaudron

For Whom?

• An architecture is a (common) means of understanding of a system

• Customers, Users, Domain Experts

• Engineers:

• Analysts

• Architects

• Programmers: maintenance, development, testing

• New members of the development team

• Marketing

• Sales

• Management

4

4

DIT541 – Software Architecture

Stakeholders

SoftwareSystem

Developer:

easy to design;

easy to maintain;

easy to reuse its parts

User:

easy to learn;

efficient to use;

helps get work done

Customer:

solves problems at

an acceptable cost in

terms of money paid and

resources used

Development manager:

sells more and

pleases customers

while costing less

to develop and maintain

Figure from: Lethbridge and Laganiere

‘‘4.16 Stakeholder: An interested party having a right, share or claim

in the system or in its possession of qualities that meet their needs.’’

Draft Standard ISO/IEC 15288 (ISO/IEC 1999)

45

20


Stakeholders

46

Stakeholders & their Concerns 1/2

Stakeholder Concern (Examples)

Customer Business goals

Schedule & budget estimation

Feasibility and risk assessment

Requirements traceability & progress tracking

Product-line compatibility

User Consistency with requirements & use cases

Future requirements growth accommodation

Support of dependability & other X-abilities

Service manager Reliability, availability and maintainability

(Table 3.1 in BCK)

21

Stakeholders & their Concerns 2/2

Stakeholders Concern (Examples)

System engineer Requirements traceability

Support of tradeoff analyses

Completeness of architecture

Consistency of architecture with requirements

Developer Sufficient detail for design and development

Workable framework for system construction,

e.g. selection/assembly of components &

technologies

Resolution of development risks

Maintainer Guidance on software modification

Guidance on architecture evolution

Interoperability with existent systems


When Architecting?

• When developing a new system

• When changing a system

– if an architecture description is not available, or insufficient, as a

basis for change

– adapt the architecture documentation to changes

• When integrating existing systems

• For special communication needs to provide a common

ground for understanding

51

22

MRV Chaudron

Outline

52

• What is Software Architecture?

• Stakeholders

• How Software Architecting?

• 4+1 Views

• Concluding Remarks & References

MRV Chaudron

53

23

MRV Chaudron

Architecture is making

decisions

54

The life of a software architect

is a long (and sometimes painful)

succession of suboptimal decisions

made partly in the dark.

• You will not have all information available

• You will make mistakes, but you should learn from them

• There is no absolute measure for ‘goodness’

Grady Booch

MRV Chaudron

No ideal solution

55

Discovery may

be exploratory

There is no ideal

system to be

discovered.

24

MRV Chaudron

Process: Working Together

56

Stakeholders

Close and effective interaction between these actors is essential!

Make process transparent: Get/Give feedback early and often

Quality

CostsBusinessDrivers

WHAT?

Requirements

HOW?

Implementation

System

SWHW

Architect

MRV Chaudron

How to Bridge the Gap?

57

WHAT?

Requirements

HOW?Implementation

?

25

MRV Chaudron

Traditional Answer

58

WHAT?

Requirements

• Ad-hoc - not repeatable, not predictable• Requires Magic (Wizards/Gurus)• Costly

HOW?

ImplementationMiraclehappens

MRV Chaudron

Software Architecture Design Process

Requirements

FunctionalRequirements

Extra-FunctionalRequirements

DomainRequirements

UserRequirements

Group Functionalityin subsystems

Design approach forrealizing extra-functional

quality properties Select Architectural StyleReference ArchitectureArchitecture TacticsSynthesize

Analyze

refine

Guide & MonitorImplementation

Business case (sec 3.2 in the BCK book)

26

MRV Chaudron

Business Case

• Will benefits outway costs?

• How much does the product cost

• To develop

• & to maintain!

• What is the time-to-market of the system?

• Market: Who are the customers?

• How many? What will they pay?

MRV Chaudron

Business Model Canvas

27

MRV Chaudron

Software Architecture Design Process

Requirements

FunctionalRequirements

Extra-FunctionalRequirements

DomainRequirements

UserRequirements

Group Functionalityin subsystems

Design approach forrealizing extra-functional

quality properties Select Architectural StyleReference ArchitectureArchitecture TacticsSynthesize

Analyze

refine

Guide & MonitorImplementation

Business case (sec 3.2 in the BCK book)

Requirements Eng & Sw Analysis & Designcourses

MRV Chaudron

Twin Peaks Process

64

Progressing understanding of architecture & design provides a basis for discovering further problem space & requirements and vice versa.

WHAT: problem structuring

There is interaction between available solutions and requirements

Separate but concurrent development of requirements & architecture

HOW: solution structuring

28

MRV Chaudron

Focus over timeDiscovery Invention

Focus

Implementation

From : Bran Selic

Time

MRV Chaudron

Outline

68


• Stakeholders


• 4+1 Views

• Concluding Remarks & References

29

MRV Chaudron

Overview (According to IEEE 1471)

69

stakeholder

concern

viewpoint

view

model

has

conforms toestablishesmethods for

consists of

is covered by

architectural description

system

architecture

has

has

described by

is organised by

1..*

1..*

1..*

1..*

1

MRV Chaudron

ISO/IEC/IEEE 42010:2011 Conceptual Framework

7

0

Rationale

Architectural Description

Model

View

Concern

Architecture System

Environment Mission

Viewpoint

LibraryViewpoint

Stakeholder

provides

1..*aggregates

participates in

consists of

participates in

1..*

1..*organized by

establishes methods for

described by

selects1..*

used to cover1..*identifies

1..*

has is important to

1..*

1..*

identifies 1..*

1..*

has

conforms to1..* has source

has an

1..*fulfillsinhabits

influences

1..*

is addressed to

30

MRV Chaudron

Outline

71


• Stakeholders


• 4+1 Views

• Summary

MRV Chaudron

Viewpoints & views

72

viewpoint

31

MRV Chaudron

View: Definition (from IEEE 1471)

73

3.4 Architectural Description (AD): A collection of products to document an architecture.

3.9 View: A representation of a whole system from the perspective of a related set of concerns.

A view may consist of one or more architectural models

Each such architectural model is developed using the methods established by its associated architectural viewpoint.

An architectural model may participate in more than one view.

MRV Chaudron

Architectural view

• An architectural view is a simplified

description (an abstraction) of a system from

a particular perspective/view point, covering

particular concerns, and omitting entities that

are not relevant to this perspective

74

32

Example 4+1 Views model

76

Structure view:class/component-diagram

Behaviour view:

Sequence diagram

A B

C D

A B C D

Deployment view:

physical model + mapping

AB

C D

Use cases

BC/WC e2e-response times, freq. bandwidth, availability

TCP/IP over Ethernet

file ownership

Config. Mngnt view

versioning policies

…

Development view

MRV Chaudron

The 4 + 1 View Model (Kruchten95)

Statechart diagrams (intra)

Interaction diagrams (inter)

Deployment diagrams

structure of infrastructure

rules for mapping of design

and process view onto infra

Process

view

Deployment

view

Development

view

Structure

view

Use case

view

Use case

models

Structure: Component diagrams Config. Mngnt policies

33

MRV Chaudron

4+1 Views Representation of

System Architecture

Structure View

Functionality (Decomposition)

Development View

Programmers

Configuration management

Process ViewSystem Architect

Deployment View

System topology

Delivery, installation, maintenance

Performance, Scalability, Throughput

System engineering

Use Case View

Concurrency, Communication,

Synchronization

End-user System Architect

How is the system structured?

How to build / configure ?

Where to install ?What hw\nw is used?

How does the system behave?

How does the system perform ?

What can/does the system do ?

AGFE

1 Model = union of multiple viewseach view has one or more diagrams

Class-diagrams

Sequence diagrams

AE

GF

A B C D

A B

C D

Structural View

BehaviourView

System Model

Use Case View

Deployment View

Development View

34

Behaviour View!

Most illustrations of software architecture us structural views, but the behavioural views as just as important!

:Student :Course :Exam:Lecture

enroll

attend

attend

writes

:Exercise

makes

Other modeling languages can be used for describing the behaviour(e.g. activity diagrams)

Other ‘Views’-paradigms exist• Soni-and-Nord (4-views, Siemens)

• Zachman (36-views, IBM)

– Mostly for Enterprise Architecture

https://en.wikipedia.org/wiki/Zachman_Framework

https://en.wikipedia.org/wiki/Zachman_Framework

35

MRV Chaudron

Overview - example

stakeholder

concern

viewpoint

view

model

has

conforms toestablishesmethods for

consists of

is covered by


system

architecture

has

has

described by

is organised by

1..*

1..*

1..*

1..*

1

Traffic light Driver

Timeliness

Timing-viewpoint

Traffic LightArchitecture

TLADescription

Timing-diagrams

Safety

MRV Chaudron

Example (According to IEEE 1471)

safety

safety-viewpoint

models

has

conforms to

consists of

is covered by


Railway safety

architecture

has

has

described by

is organisedby

1..*

1..*

1..*

1..*

1

Passenger

behaviour

deployment …

structureMethod:Fault trees

36

Views for Extra-Functional PropertiesPerformance View

*ility

+ load model

Reliability View

+ reliability model

+ …model

Additional views can sometimes be generated from the ‘basic’ views.Benefits are: reduced effort & up-to-date- & consistent views

MRV Chaudron

Domain

Solution Design view

Solution Construction view

37

MRV Chaudron

Discussion

• Why should we use different diagrams?

• Why should we use different views?

• What is the relation between ‘forces’ and

‘qualities’?

MRV Chaudron

Summary - 1

9

0

Stakeholders

Design Forces

Architecture Drivers

Architecture DesignEnables / Constrains System Qualities

System

Requirements Business goals

38

MRV Chaudron

Summary - 2

91

Architecture Design process

Iterative

Feedback early and often

Architecture Description

Multiple concerns => multiple views (e.g. 4 + 1)

Include Design Rationale

MRV Chaudron

Knowledge Profile

Architect

39

MRV Chaudron

Knowledge Profile

Programmer

MRV Chaudron

Disclaimer

101

No matter how good your architecture, it can always be ruined by bad implementation!

Is this a reason for not doing architecture?

Guide & MonitorImplementation !

40

MRV Chaudron

Types of Architectures

103

Image

Sound

100 Hz100 Hz

qualityquality

DolbyDolby

AC3AC3

Data

Processing

User

Interface

TxtTxt

EPGEPG

menusmenus

animationanimation

3D3D

Connectivity

P50P50

13941394

Storage

Device

VCRVCR

DVDDVD

TVCRTVCR

HDHD

Broadcasting

Standard

DTVDTV

RegionEuEu

USUSAPAP

Video Output Device

PTVPTV

FTVFTVLCTV

LCTV

Price

UTVUTV

MTVMTV

Image

Sound

100 Hz100 Hz

qualityquality

DolbyDolby

AC3AC3

Data

Processing

User

Interface

TxtTxt

EPGEPG

menusmenus

animationanimation

3D3D

Connectivity

P50P50

13941394

Storage

Device

VCRVCR

DVDDVD

TVCRTVCR

HDHD

Broadcasting

Standard

DTVDTV

RegionEuEu

USUSAPAP

Video Output Device

PTVPTV

FTVFTVLCTV

LCTV

Price

UTVUTV

MTVMTV

Broadcasting

Standard

DTVDTV

Broadcasting

Standard

DTVDTV

RegionEuEu

USUSAPAP

RegionEuEu

USUSAPAP

Video Output Device

PTVPTV

FTVFTVLCTV

LCTV

Video Output Device

PTVPTV

FTVFTVLCTV

LCTV

Price

UTVUTV

MTVMTV

Price

UTVUTV

MTVMTV

• Single product Future-proof with respect to a particular product

• Product family – e.g. TVs / Telephones Instantiation of many related products Stable with respect to a restricted set of Quality

attributes Future-proof with respect to a product type

Tim

e/P

rod

uct

Sco

pe

MRV Chaudron

Automotive Product Line

software architecture 2001-2002 m.r.v. chaudron m.r.v

Documents