t-76.5150 software architecture · 2007-02-01 · [ran 2001 icse tutorial] separation of...

© Tomi Männistö, 2007

1

SoberITSoftware Business and Engineering Institute

HELSINKI UNIVERSITY OF TECHNOLOGY

T-76.5150 SoftwareArchitecture

Architectural Views


2



Overview

! Architectural views

! Stakeholders

! Separation of concerns

! Sample views

! 4+1 view model (Kruchten)

! Viewpoints and views

! IEEE 1471 Standard

! Course book’s viewpoint catalogue (Rozanski, Woods)


3



Sample views and purposes

SW system

c1

c12

c2

c3c11

[Adapted from Ran 1996ISAW-2 WS@SIGSOFT]

release view

module view

p2 p4

p1p3

process viewHow fast system reacts to exception e9?How many parallel requestit can handle?

Where is functionality f1implemented?How to abstract variety in X?

When will functionality f1 be available?Who will fix bug326?


4



[Ran 2001 ICSE Tutorial]

Separation of concerns

! Multiple views are necessary because it is not possible to represent all

important information in a single view

! If it were possible such a view would be too complex defeating the

purpose of software architecture

! An architectural view that answers an important question about a system

is useful

! If however architectural views are used to design or change the system

they should be selected in such a way that there is minimal dependency

between them

! Effective selection of architectural views should achieve separation of

concerns

! Views of independent or loosely dependent architectural structures

provide essential information about the system and achieve an effective

separation of concerns


5



Key stakeholder roles

Stakeholder/role Typical tasks

Customer Buying the system

Setting requirements

Utilizing the system

Running the system

Designer Detailed design

Programming

Project manager Project management

Architect Evaluation of high level solutions

Deciding about technology

High-level design

Customer manage-

ment & marketing

Selling

Negotiation

General

management

Resource management

Deciding strategies

[Smolander 2003]


6



Different stakeholders! Customer

! Acquirer, client

! User, operator,

technical staff

! Architect

! SA design, docum.

! Chief / project architect

! Business

! Customer relations

! Marketing

! Sales

! Product portfolio

management

! General management

! CEO, CIO, ...

! Department manager

! Project steering group

! Team leader

! Product manager

! Project manager

! Domain engineer

! System analyst

! Developers

! Tester, quality assurance

! Config. management

! Documentation

! Data administration

! UI design, usability

! Technical designer

! Usability testing

! User experience team

! Suppliers

! Subcontractors

! Systems to connect to

! Hardware vendors

! Production organization

! Customer support

! Training

! Maintenance

! Technology management

! Process development

! Authorities

! Politics, politicians

! Legislation

! Environment

! Auditors

! Auditor

! External assessor

! Solution provider

! Hardware integrator

! Consultant


7



Integrators System engineers

4+1 view model

Physical view

Logical view

Functional requirementsObject and classes, OO-styleDomain concepts Solves the “main” problem

Process view

Development view

Modules and subsystemsLayersSoftware managementindependent developmentSystem buildTesting

Scenarios

[Kruchten 1994]

End users

Programmers

Non-functional requirements availability, reliability, performance, scalability, integrity, synchronisationstyle: pipe-filter, client-server...

How it all works togetherStart up, shut downCritical eventsDevelopment increments

System topologyDeliveryInstallationThroughput


8



Scenarios

! Redundant with other views (thus +1), but

! Helps designers to discover architectural elements

! Validates architectural design

! Idea is not to specify them all!


9



Views may collapse

! Especially in small systems

! Conceptual and module view may be similar enough to

be described together

! Only one process (or program) " no need for process

view

! No distribution " no need for physical view


10



4+1 may not be enough

! For addressing particular concerns a different set

of views may be needed


11



Views and viewpoints

IEEE Standard 1471-2000


12



View

! View

! A representation of a whole system from the

perspective of a related set of concerns

! Viewpoint

! A specification of the conventions for constructing and

using a view


13



Viewpoint

! Establishes conventions by which a view is

created, depicted and analysed

! Determines languages for describing a view

! Including, notations, model or product types

! E.g., a company may define its own library of

viewpoints to address typical set of concerns


14



Identification of stakeholders andconcerns! Stakeholders, at minimum

! Users

! Acquirers

! Developers

! Maintainers

! Concerns, at minimum

! The purpose of missions of the system

! The appropriateness of the system in fulfilling its mission

! The feasibility of constructing the system

! The risk of system development and operation to users, acquirers

and developers

! Maintainability, deployability and evolvability


15



A viewpoint shall be specified by

! The stakeholders to be addressed by the viewpoint

! The concerns to be addressed by the viewpoint

! The language, modelling techniques, analytical methods to be

used in constructing a view based upon the viewpoint

! May also include

! Consistency and completeness tests to be applied to the models

! Evaluation and analysis techniques

! Heuristics, patterns or other guidelines

! Architecture description shall include a rationale for the selection

of each viewpoint


16




17



Example: Structural viewpoint (1)

! Concerns

! What are the computational elements of a system and

the organization of those elements?

! What software elements compose the system?

! What are their interfaces?

! How do they interconnect?

! What are the mechanisms for interconnection?


18



Example: Structural viewpoint (2)

! Viewpoint language

! Components (individual units of computation)

! Components have ports (interfaces)

! Connectors (represent interconnections between components

for communication and coordination)

! Connectors have roles (where they attach to components)

! Components and connectors may be typed

! All of the previously listed entities may have attributes of

varying kinds.


19



Another example: Behavioural viewpoint

! Concerns

! What are the dynamic actions of and within a system?

! What are the kinds of actions the system produces and participates

in?

! How do those actions relate (ordering, synchronization, etc.)?

! What are the behaviours of system components? How do they

interact?

! Modelling methods

! Events, processes, states, and operations on those entities

! Analytic methods

! Some examples are: communicating sequential processes, the pi-

calculus, and partially ordered sets of events


20



Deployment

Operational

Development

Functional

Information

Concurrency

Course Book’s viewpoint catalog

Functional elements, their responsibilities and maininteractions. Cornerstone of most ADs.

How information is stored, manipulated, managed anddistributed

Concurrency structure, maps functional elements toconcurrency units. Process and thread structures.Interprocess communication and coordination.

How SA supports development process. Building, testing,maintaining and enhancing system.

Hardware: processing nodes, network, disk storage.Dependencies system has to runtime environment.

How system will be operated, administered and supportedin production environment.


21



Functional viewpoint 1/2

!Functional capabilities

!External interfaces

!Internal structure

!Design qualities

Concerns

Design of runtime functional elements and their

responsibilities, interfaces and primary interactions

Content

Functional structure of systemFocus

[Woods 2006 WICSA Tutorial]


22



Functional viewpoint 2/2

!Poorly defined interfaces

!Poorly understood responsibilities

!Infrastructure modelled as functional elements

!Overloaded view

!Just drawing pictures

!Wrong level of detail

!“God” elements

!Too many dependencies

Pitfalls

Functional structure modelsModels



23



Functional view, example



24



Information viewpoint 1/2

!Information structure and content

!Information flow

!Data ownership and quality

!Timeliness, latency and age

!References and mapping

!Transaction management and recovery

!Data volumes

!Archives and data retention

!Regulation

Concerns

Design of storage, manipulation, management and

distribution of information

Content

Information structure, ownership and processingFocus



25



Information viewpoint 2/2

!Data incompatibilities

!Poor data quality

!Unavoidable multiple updaters

!Key matching deficiencies

!Poor information latency

!Interface complexity

!Inadequate volumetrics

Pitfalls

!Static data and metadata structure models

!Information flow models

!Information lifecycle models

!Data ownership and access models

!Volumetric models

Models



26



Information view, examples



27



Information view, examples (2)


Access rights:Create, Read, Update, Delete


28



Concurrency viewpoint 1/2

!Task structure

!Mapping of functionality elements to tasks

!Inter-process communication and re-entrancy

!State management

!Synchronization and integrity

!Task start-up, shutdown and recovery from failure

Concerns

The concurrency structure, mapping functionality

elements to concurrency units to clearly indentify part

of system that can execute concurrently, and how this

is coordinated and controlled

Content

Packaging elements into processes and threadsFocus



29



Concurrency viewpoint 2/2

!Modelling of wrong concurrency

!Excessive complexity

!Resource contention

!Deadlock and race conditions

Pitfalls

!System-level concurrency model

!System level state model

Models



30



Concurrency view, example



31



Development viewpoint 1/2

!Module organisation

!Codeline organisation

!Common processing

!Standardisation of design

!Standardisation of testing

!Instrumentation

Concerns

architectural design that supports and constraints the

software development process

Content

Architectural constraints on software development

process

Focus



32



Development viewpoint 2/2

!Too much detail

!Overburdening architectural description

!Uneven focus

!Lack of developer focus

!Lack of precision

!Problems with specified environment

Pitfalls

!Module structure models

!Common design models

!Codeline models

Models



33



Development view, example



34



Deployment viewpoint 1/2

!Types of hardware required

!Specification and quantity of hardware required

!Third-party software requirements

!Technology compatibility

!Network requirements

!Network capacity required

!Physical constraints

Concerns

Design of environment into which system will be

deployed, including system’s runtime dependencies

Content

Runtime environment structure and distribution of

software across it

Focus



35



Deployment viewpoint 2/2

!Unclear or inaccurate dependencies

!Unproven technology

!Lack of specialist technical knowledge

!Late consideration of deployment environment

Pitfalls

!Runtime platform models

!Network models

!Technology dependency models

Models



36



Deployment view, example



37



Deployment view, example (2)


38



Operational viewpoint 1/2

!Installation and upgrade

!Functional and data migration

!Operational monitoring and control

!Operational configuration management

!Performance monitoring

!Support responsibilities and procedures

!Backup and restore

Concerns

Defines strategies for how system will be operated,

administered and supported when running in production

environment

Content

System installation, migration, operation and supportFocus



39



Operational viewpoint 2/2

!Lack of engagement with operational staff

!Lack of backout planning

!Lack of migration planning

!Insufficient migration window

!Missing management tools

!Lack of integration into production environment

!Inadequate backup and recovery modelling

Pitfalls

!Installation models

!Migration models

!Configuration management models

!Administration models

!Support and escalation models

Models



40



Operational view contents, example

! Installation model

! Installation groups

! Dependencies and constraints

! Backout strategy

! Operational Configuration Management model

! Configuration groups and dependencies

! Configuration parameter sets

! Operational control (switching between sets)

! Administration model

! Monitoring and control facilities required and provided

! Required routine operational procedures

! Required operational action in case of error conditions



41



R&W’s Book vs. 4+1

Physical view

Logical view

Process view

Development view

Scenarios

Deployment

Operational

Development

Functional

Information

Concurrency


42



Used viewpoints in architecturedescription [Smolander 2002]

! Original objective: find out the general combinations

between rationale, stakeholders, and viewpoints

! More than 20 diverging viewpoints identified:

! Networks, hardware, functional scenarios, used technology,

cost-benefit mappings, failure plans, memory allocation,

security, laws and regulations involved, stakeholders,

systems integration, legacy interfaces + many other features

requiring separate attention

[Smolander 2002]


43



Perspective – one more concept

! Sometimes a concern may span multiple views

! For example, security

! Deployment view

! Information view

! Development view


44



Conclusions

! Viewpoint

! Stakeholder

! Concerns

! Architecturally significant issues including requirements, drivers,

constraints, qualities, …

! Component characteristics, behaviour, interaction

! Means for describing a view

! What exactly is meant boxes, lines, arrows, symbols,…

! How should they be used

! View

! Actual description of the architecture (from a point of view!)

! Perspective...


45



References

! Kruchten. The 4+1 View Model of Architecture, IEEE Software, 1994

! Ran, ARES conceptual framework for software architecture. Chapter 1 in

Jazayeri, Ran, Linden (eds.) Software architecture for product

families—Principles and practice, Addison-Wesley, 2000.

! Rozanski, Woods. Software System Architecture. Addison-Wesley, 2005.

! Smolander, On the role of Architecture in Systems Development.,Ph.D.

Thesis, Lappeenranta University of Technology, 2003.

! IEEE Recommended Practice for Architectural Description of Software-

Intensive Systems. IEEE Std 1471-2000, 2000.

t-76.5150 software architecture · 2007-02-01 · [ran 2001 icse tutorial] separation of...

Documents