© drexel university software engineering research group (serg) 1 based on the paper by philippe...

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


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


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.


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


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


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


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


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


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


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


The Process View

Components for the process view include: Processes and threads

Connectors include Messages, shared memory, pipes

Process View


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


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


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


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


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


From the mid-90’s to current thinking…

Structural Packaging

Behavioral Infrastructure

Requirements,Test/Validation

Criteria


View


Scenarios Then

Now


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




Criteria


View


Scenarios



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




Criteria


View


Scenarios


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




Criteria


View


Scenarios



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




Criteria


View


Scenarios


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.

© drexel university software engineering research group (serg) 1 based on the paper by philippe...

Documents

view logical view slide

boxes software architecture

individual views slide

logical components

multiple views

multiple concurrent

architecture widgets

different notation