architectural blueprints – the “4+1” view model of software architecture
Post on 23-Jan-2016
46 Views
Preview:
DESCRIPTION
TRANSCRIPT
1© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Based on the paper by Philippe Kruchten from Rational Software
Architectural Blueprints – The “4+1” view Model of Software Architecture
2© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Complexity Management via Views
Modeling software architectures is best done using multiple concurrent viewsThis approach is consistent with the “Views and Beyond” approach outlined by the SEI for documenting software architecturesIndividual views divide thecomplexity, and create artifactsthat separately address the concernsof different stakeholders
3© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Lines and Boxes
Software architecture and design documentation is often modeled using box and line diagramsModelers often struggle with: What do the lines and boxes represent? Do the lines and boxes represent the same
abstractions from one model to another? Do models developed by more than one
individual have the same meaning for the lines and boxes?
Is the goal of the model clear - are the lines network messages, procedure calls, or structural relationships? – are the boxes functions, classes, components, servers, etc.
4© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Requirements for Modeling SW Architectures
Use multiple views, each view addressing one specific set of concernsOrganize the views into categories, with each category being specifically targeted to be used by a different constituency Use consistent notation for the individual views
5© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The 4+1 View Model
Each view is consumed by a different stakeholder
Logical ViewDevelopment
View
Process View Physical View
Scenarios
Architects Developers
Integrators InfrastructureEngineers
BusinessAnalysts
6© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The Architecture Widgets
Each view is expressed using a set of elements and connectorsEach view can be guided by using patterns or architectural styles to introduce constraints on downstream design artifactsEach view is developed taking the appropriate set of requirements into mindEach view might use different notation that is most appropriate for the view
The “Widgets” of Architecture
Component A Component B
Connector Interface
Connector
7© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The Logical View
This view expresses the key abstractions from the problem domain
Classes, Components
Think in terms of the services that the system will provide to the userExpress the relationships between the logical components
Use, generalize, aggregate
Define the important interfaces of the components and connectors associated with this view
Logical View
8© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The Logical View
Choose a “style” for the logical view Object-oriented style Component style Service-oriented style
The style helps define the structure and semantics of the elements captured in the logical view
Logical View
9© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The Process View
The process view takes into account non-functional requirements such as performance, availabilityThis view also deals with concurrency, showing the different threads of control Intra-process threads Inter-process coordination (messages to
and from different servers)
Process View
10© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The Process View
A “process” in the process view groups tasks into logical execution units. Execution units have a: Well defined point where they start and
stop as well as rule for dealing with exceptions to the normal course of operation
Possible styles for the process views: Client/Server, MVC, pipe and filter.
Process View
11© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The Process View
Components for the process view include: Processes and threads
Connectors include Messages, shared memory, pipes
Process View
12© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The Development View
The development view defines the actual software modules to be constructedThe granularity of the components in this view should be at the level where they can be implemented by one or a small set of developers Classes, Packages, Subsystems
This view should clearly define the import and output relations We will hear more about this later when we
talk about provided and required interfaces…
DevelopmentView
13© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The Development View
Connectors for the development view may include: Function/procedure calls, inheritance,
includes, uses, etc.
Styles for the development view include the layer style Subsystems, components,
modules/classes, functions/procedures
DevelopmentView
14© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The Physical View
The physical view maps the software components to the hardware (deployment)Elements include networks, processes, and tasks; Connectors include network links and interprocess communicationDifferent physical views might be needed for development, test and productionA good design promotes the flexibility to map the software components to different physical configurations for different phases of the software development lifecycle
PhysicalView
15© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The +1 View - Scenarios
Scenarios are abstractions of the most important requirementsMap closely to use casesTies the other views togetherThe scenario view is redundant to the other views (+1) but is a cross-cutting aspect tying the architecture together
Scenarios
16© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The +1 View - Scenarios
Why scenarios: A mechanism to discover the key
architectural elements and connectors
Validation of the architecture design after the other views are created
Addresses the concerns of both the functional and non-functional requirements
Scenarios
17© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
From the mid-90’s to current thinking…
Structural Packaging
Behavioral Infrastructure
Requirements,Test/Validation
Criteria
Logical ViewDevelopment
View
Process View Physical View
Scenarios Then
Now
18© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
What’s Different Now?
The logical view and development view are combined into the structural view The structural view
combines both the abstract logical view and the more detailed development view
Structural Packaging
Behavioral Infrastructure
Requirements,Test/Validation
Criteria
Logical ViewDevelopment
View
Process View Physical View
Scenarios
19© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
What’s Different Now?
The process view has been incorporated into the behavioral view. The process view only
defines units of execution where the behavioral view includes these plus important behavioral interactions between the architectural elements
Structural Packaging
Behavioral Infrastructure
Requirements,Test/Validation
Criteria
Logical ViewDevelopment
View
Process View Physical View
Scenarios
20© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
What’s Different Now?The packaging view is new, as newer component oriented languages allow grouping of structural elements into components
Examples: COM, CORBA, Java Beans, EJB, Services
The packaging of the components, their interfaces and metadata are very important design artifacts
The infrastructure view in the new maps closely with the physical view in the older model
Structural Packaging
Behavioral Infrastructure
Requirements,Test/Validation
Criteria
Logical ViewDevelopment
View
Process View Physical View
Scenarios
21© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
What’s Different Now?
The Scenario view in the old model, which was reflective of the requirements now includes a logical rendering of the requirements (typically rendered as use-cases), as well as definition of test cases needed to verify the software product
Structural Packaging
Behavioral Infrastructure
Requirements,Test/Validation
Criteria
Logical ViewDevelopment
View
Process View Physical View
Scenarios
22© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The “newer” 4+1 model and SOAStructural Packaging/Implementation
Behavioral Infrastructure/Environment
Requirements, Test/Validation Criteria
Service Contract(s)
Classes and Componentsthat physically representthe service
Workflows showing how the service fulfils a logical business-unit-of-work (BUOW). Also includes intra-service behavioral models
Service interface (schema) and usage semantics, perhaps WSDL. Includes service policy definitions and metadata
Deployment on .Net and/or J2EE – emphasis on reliability,availability and security.
top related