software architecture views and viewpoints
DESCRIPTION
Part of the course on Advanced Software Engineering, a.a. 2014-2015 http://lore.com/Advanced-Software-Engineering-Univaq/TRANSCRIPT
1
Advanced Software EngineeringURL: http://lore.com/Advanced-Software-Engineering-Univaq/
DISIMDep.nt of Information Engineering, Computer Science and MathematicsUniversity of L’Aquila, Italy
Views and Viewpoints
Henry Muccini [email protected]
SEA Group
Copyright Notice
The material in these slides may be freely reproduced and distributed, partially or totally, as far as an explicit reference or acknowledge to the material author is preserved.
Henry Muccini
SEA Group
Non Functional S.E.Performance modelingPerformance analysis
UML UML ProfilingLab
Intro to SASA Case study SA styleADLs Design Decisions Views/Viewpoints
Software Architecture
UML Extra Functional
Lectures
SEA Group
Software ArchitectureThe Software Architecture is the earliest model of the whole software system created along the software lifecycle
“Traditional” definition:→A set of components and connectors communicating through interfaces
“Recent/Future” understanding:→Focus on set of Views and Viewpoints, looking at stakeholders and their concern
→A set of architecture design decisions taken to generate the architecture artifact
SEA Group
Architecture as a set of Viewpoints
SEA Group
Views and Viewpoints
Structure
Behavior
Hw/Sw
Real-time
…
SEA Group
Views and Viewpoints
SEA Group
Architectural views
Two important views
User1
Router Server
Timer
AlarmUR AlarmRS (c)Check1
Nofunc
Clock
AckSR (c)
AckRU1
User2
AlarmUR1
AlarmUR2
Check2
Check
AckRU2
0 12
3
4
5
Structural Spec. Behavioral Spec.
-Formal ADLs-UML notations
- Posets, pre-post conditions- Process Algebras- Labeled Transition Systems, IO Automata, IOLTS- Statechart, UML state machine
SEA Group
SEA Group
FireFighter example: overall
SEA Group
FireFighter example: SW viewpoint
SEA Group
FireFighter example: WSN viewpoint
SEA Group
FireFighter example: Behavior viewpoint
SEA Group
ISO/IEC/IEEE 42010: 2011
ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011
SEA Group
Architecture Description Architecture Description is the practice of expressing
architectures (ISO/IEC 42010) “The practices of recording software, system and
enterprise architectures so that architectures can be understood, documented, analysed and realized.”
“Architecture descriptions are created by architects and used by architects and other stakeholders throughout all stages of a system’s life cycle, from development through operation and maintenance.”
SEA Group
Architecture Description: 3 mechanisms
1) Architecture Viewpoints: define the contents of each architecture view;
2) Architecture Frameworks (AFs): coordinated set of viewpoints for use within a particular stakeholder community or domain of application (e.g., GERAM, TOGAF, MODAF);
3) Architecture Description Languages (ADLs): any mode of expression used in an
architecture description.
ADL provides model kinds selected to frame one or more concerns.
SEA Group
ISO/IEC/IEEE 42010: 2011
ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011
SEA Group
Stakeholder concerns
• the nature of the system• project-specific constraints• organizational constraints• the application domain • …
Stakeholders concerns can vary tremendously (and change over time), depending on:
SEA Group
Stakeholders and their concernsSoftware Architect
Software Developer
Financial manager
Business manager…
…
SEA Group
Example
SEA Group
ISO/IEC/IEEE 42010: 2011
ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011
SEA Group
Def of View and Viewpoint[…] “a viewpoint is a way of looking at a system; a view is what you see”
“A viewpoint defines the conventions (such as notations, languages and types of models) for constructing a certain kind of view”
[…]”viewpoint refers to the conventions for representing an architecture relative to one set of concerns.”
“A view is the result of applying a viewpoint to a particular system of interest”
[…] “viewpoints as first-class entities of architecture descriptions.”
view : viewpoint :: program : programming language
From the ISO/IEC/IEEE 42010
SEA Group
ISO/IEC/IEEE 42010: 2011
ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011
SEA Group
Architecture Framework (AF)
ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011
2) Architecture Frameworks (AFs): coordinated set of viewpoints for use within a particular stakeholder community or domain of application (e.g., GERAM, TOGAF, MODAF);
SEA Group
Logical View
End-user
Functionality
Implementation (Development) View
Programmers Software management
Process View
PerformanceScalabilityThroughput
System integrators
Deployment View
Conceptual Physical
Use Case View
Object Model of Design
Static Organization of the Software
Concurrency and Synchronization
Software Mapping To HwSystem engineering
System topology Delivery, installationCommunication
RUP 4+1 views
SEA Group
RUP-based view
Views
Models
Use CaseModel
DesignModel
Depl.Model
Impl.Model
TestModel
AnalysisModel
SEA Group
[Applied]
Still based on Architectural views…→Conceptual →Module→Execution→Code
… but more Diagrams for each view
[UMLProcess]
[Applied] C. Hofmeister, R. Nord and D. Soni. Applied Software Architecture. Addison-Wesley. 1998.
Architectural views: Applied SA [Applied] & UML Process [UMLProcess]
[UMLProcess] I. Jacobson, G. Booch and J. Rumbaugh.The Unified Software Development Process. Addison Wesley, Object Technology Series, 1999.
SEA Group
Stakeholder concerns -> Multiple views
Using multiple views has become standard practice in industry
• IEEE Std 1471 (2000) -> … -> ISO/IEC/IEEE 42010 (2011) • Based on a survey we conducted with 48 practitioners
[Survey2012], and about the usage of ALs in industry 85% uses multiple views
[Survey2012] “What Industry needs from Architectural Languages: A Survey”, I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, A. Tang (under review)
SEA Group
Service Provider Client WSN
DeveloperMobile App Developer
System Integrator
Dependability X X X XEnergy
Consumption X
Networking & Communication X X X
Usability X X X Performance X X X
Security X X XCost X X
Views and ViewpointsBased on the informal description of the SA, identify:• Stakeholders• Concerns • Concern–Stakeholder Traceability (see example below)
SEA Group
System Architecture View
Small overview of the System view.
Design Decisions
In this section, you are required to document the three (3) most important design decisions using the QOC Template. For “most important” we mean those that may have a bigger impact on your architecture, those that you discussed more, or you think are the most relevant. The QOC Template is available in SVN. You are required to provide both the tabular representation and the graphical one inside this document.
Models
In this section, you are required to show a picture of the SID model (by using any graphical tool such as Powerpoint, Visio, OmniGraffle, etc.), the FSP specification (only its textual representation), and to describe all of them in details. The models must address all of the concerns framed by the view’s governing viewpoint and cover the whole system from that viewpoint.
Known Issues
Document any discrepancies between the view and its viewpoint conventions. Each architecture view must adhere to the conventions of its governing architecture viewpoint. Known issues could include: inconsistencies, items to be completed, open or unresolved issues, exceptions and deviations from the conventions established by the viewpoint. Open issues can lead to decisions to be made. Exceptions and deviations can be documented as decision outcomes and rationale.