Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 2
Surveyed five similar approaches to documenting software architecture
To identify:
•Their strengths and weaknesses
•An optimum approach to documenting software architecture
Overview
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 3
Background:
• Software architecture
• Documentation approaches Survey:
• Comparison Framework
• Review of the five approaches Conclusions Questions
Contents
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 4
What is Software Architecture?
Structures = Components and Connectors
Styles = Constraints on Composition.
Rationale = Non-Functional Requirements
Background
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 5
Adapted from “IEEE Recommended Practice for Architectural Description of Software Intensive Systems”. IEEE (2000)
Background - IEEE Standard 1471-2000
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 6
Viewpoint models utilize perspectives to separate the concerns.
Perspectives are variously called views, viewtypes, and viewpoints.
Different viewpoint models focus on the different uses of documentation.
• Communication.
• Design.
• Re-use.
Other frameworks exist for classifying documentation.
Background - Viewpoint Models
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 7
Framework• based on IEEE 1471-2000, IEEE (2000).
Viewpoint Models:• “4+1” View Model, Kruchten, P. (1997).
• SEI View Model, Clements, P. et al. (2002b).
• ISO RM-ODP, ISO (1994).
• Siemens Four View Model, Soni, D. et al. (1995).
• Rational ADS, Norris, D. (2004).
Survey
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 8
Stakeholderseg. Architects, Testers, Managers.from “Documenting Software Architectures: views and beyond” (Clements et al, 2002a, page 10).
Concernseg. Performance, Implementation, Privacy. from “Software Engineering” (Sommerville, 2000, page 101).
Structureseg. Decomposition, Layer, Process from “Software Architecture in Practice” (Bass et al., 2003, page 39).
Survey - Comparison Framework
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 9
StakeholdersImplementers: Programmers and
Systems Engineers.
ConcernsReliability: Quality of Service, Fault Tolerance,
Availability, and Failure Modes.
StructuresDeployment: Hardware and Software
components.
Survey – Example Translations
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 10
Survey – Summary of Models
Focus Features Viewpoints
SEI Communication Independent viewpoints 3 viewpoints
“4+1” Design Iterative design process 5 views
Siemens DesignFlow of information through viewpoints
4 views
RM-ODP Re-useDefines a common vocabulary
5 viewpoints
Rational ADS DesignDefined mappings between views
4 viewpoints
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 11
0
2
4
6
8
10
12 "4+1"
SEI
RM-ODP
Siemens
RationalADS
Total
Stakeholders
Structures Concerns
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 12
Conclusions - Viewpoint Groups
“4+1”model
SEImodel
Siemensmodel
RationalADS
FunctionalLogical
viewModule
viewtypeModule
view-
BehaviouralProcess
viewC&C
viewtypeExecution
view-
ExternalDevelopment
viewAllocationviewtype
Codeview
Realizationviewpoint
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 13
Rational ADS - Requirements viewpointSEI - Module viewtypeSEI - C&C viewtypeSEI - Allocation viewtype
Conclusions - Optimum Set
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 14
Map Stakeholders to Concerns
Determine Implicit Stakeholders
Verify Optimum Viewpoint Set using Case Studies
Conclusions - Future Work
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 15
Software Architecture can be documented using different approaches
Viewpoint models use multiple perspectives based on the separation of concerns
Surveyed five viewpoint models
Identified their relative strengths and weaknesses
Identified an optimum set of viewpoints
Finale - summary
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 16
Thankyou
Questions
Finale
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 17
Adapted from “Architectural Blueprints – the 4+1 view model of software architecture”, Kruchten, P. (1997)
Survey - “4+1” View Model
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 18
Module Viewtype
Component & Connector Viewtype
Allocation Viewtype
Survey - SEI View Model
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 19
Enterprise View
Information View
Computational View
Engineering View
Technology View
Survey - RM-ODP
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 20
Adapted from “Applied Software Architecture”, Hofmeister, C. et al. (2000).
Survey - Siemens Four View Model
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 21
Adapted from “Communicating Complex Architectures with UML and the Rational ADS”, Norris, D. (2004).
Survey - Rational ADS
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 22
Conclusions – Number of viewpoints addressing Structures
0 5 10 15 20
Number of Viewpoints
Decomposition
Uses
Layered
Abstraction
Process
Concurrency
Shared Data
Client-Server
Deployment
Implementation
Work Assignment
"4+1" SEI RM-ODP Siemens Rational ADS
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 23
Conclusions – Number of viewpoints addressing Concerns
0 5 10 15 20
Number of Viewpoints
Usability
Performance
Space
Reliability
Portability
Delivery
Implementation
Standards
Interoperability
Ethical
Privacy
Safety
"4+1" SEI RM-ODP Siemens Rational ADS
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 24
Conclusions – Number of viewpointsaddressing Stakeholder Roles
0 5 10 15 20
Number of Viewpoints
Architects /Requirements Engineers
Sub- System Architects /Designers
Implementers
Testers /Integrators
Maintainers
External System Architects /Designers
Managers
Product Line Managers
Quality Assurance Team
End User
Standard Writers
"4+1" SEI RM-ODP Siemens Rational ADS
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 25
Bass, L. et al. (2003). Software Architecture in Practice. Addison Wesley, Boston, MA, USA, 2nd edition. ISBN 0-321-15495-9.
Clements, P. et al. (2002a)
Documenting Software Architecture: Views and Beyond. Addison Wesley, Boston, MA, USA, 1st edition. ISBN 0-201-70372-6.
Clements, P. et al. (2002b)
A practical method for documenting software architectures. http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/icse03-dsa/submitted.pdf viewed on 20th September, 2004. Draft.
Hofmeister, C. et al. (2000).
Applied Software Architecture. Object Technology Series. Addison Wesley, Boston, MA, USA, 1st edition. ISBN 0-201-32571-3.
IEEE (2000) IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. Institute of Electrical and Electronics Engineers. IEEE Std 1471-2000.
References
Tuesday, 29th March 2005 A Survey of Software Architecture Viewpoint Models Slide 26
ISO (1994) Reference Model of Open Distributed Processing (RM-ODP). International Organization for Standardization. Technical Report 10746.
Kruchten, P. (1997) Architectural Blueprints - The “4+1” View Model of Software Architecture. IEEE Software, 12(6):42–50.
Norris, P(2004)
Communicating Complex Architectures with UML and the Rational ADS. In Proceedings of the IBM Rational Software Development User Conference, 2004. Copyright 2004 IBM Australia.
Sommerville, I. (2000)
Software Engineering. Addison Wesley, Boston, MA, USA, 6th edition. ISBN 0-201-39815-X.
Soni, D. et al. (1995) Software architecture in industrial applications. In International Conference on Software Engineering, pages 196–207.
References - Continued