© Tomi Männistö, 2007
1
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.5150 SoftwareArchitecture
Architectural Views
© Tomi Männistö, 2007
2
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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)
© Tomi Männistö, 2007
3
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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?
© Tomi Männistö, 2007
4
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
[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
© Tomi Männistö, 2007
5
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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]
© Tomi Männistö, 2007
6
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
© Tomi Männistö, 2007
7
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
© Tomi Männistö, 2007
8
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Scenarios
! Redundant with other views (thus +1), but
! Helps designers to discover architectural elements
! Validates architectural design
! Idea is not to specify them all!
© Tomi Männistö, 2007
9
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
© Tomi Männistö, 2007
10
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
4+1 may not be enough
! For addressing particular concerns a different set
of views may be needed
© Tomi Männistö, 2007
11
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Views and viewpoints
IEEE Standard 1471-2000
© Tomi Männistö, 2007
12
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
© Tomi Männistö, 2007
13
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
© Tomi Männistö, 2007
14
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
© Tomi Männistö, 2007
15
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
© Tomi Männistö, 2007
16
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
© Tomi Männistö, 2007
17
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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?
© Tomi Männistö, 2007
18
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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.
© Tomi Männistö, 2007
19
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
© Tomi Männistö, 2007
20
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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.
© Tomi Männistö, 2007
21
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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]
© Tomi Männistö, 2007
22
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
23
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Functional view, example
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
24
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
25
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
26
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Information view, examples
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
27
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Information view, examples (2)
[Woods 2006 WICSA Tutorial]
Access rights:Create, Read, Update, Delete
© Tomi Männistö, 2007
28
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
29
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
30
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Concurrency view, example
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
31
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
32
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
33
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Development view, example
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
34
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
35
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
36
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Deployment view, example
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
37
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Deployment view, example (2)
© Tomi Männistö, 2007
38
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
39
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
40
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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
[Woods 2006 WICSA Tutorial]
© Tomi Männistö, 2007
41
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
R&W’s Book vs. 4+1
Physical view
Logical view
Process view
Development view
Scenarios
Deployment
Operational
Development
Functional
Information
Concurrency
© Tomi Männistö, 2007
42
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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]
© Tomi Männistö, 2007
43
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Perspective – one more concept
! Sometimes a concern may span multiple views
! For example, security
! Deployment view
! Information view
! Development view
© Tomi Männistö, 2007
44
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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...
© Tomi Männistö, 2007
45
SoberITSoftware Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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.