ELEMENTS OF SOFTWARE ARCHITECTURE CSPC 464 Fall 2014

Son Nguyen

References

1. Architecture Blueprints _ The “4+1” View Model of Software Architecture, Phiippe Kruchten

2. Software Architecture for Developers, Simon Brown

3. An Introduction to Software Architecture, David Garlan and Mary Shaw

4. Software Architecture, A. Bijlsma, B.J. Heerendr., E.E> Roubtovair, S. Stuurman

2

Agenda• Attendance/Roster• Review topics from last week• Today’s topics: Elements of SW Architecture

• Key architecture description concepts:• Viewpoint• View• Model

• “4+1” View Model• Logical View• Process View• Development View• Physical View

• Documenting SW Architecture

Review• What are things in the method content? • How many types of process are there?• What are the major problems in waterfall model?• What are major phases in iterative process according to

OpenUP?

Review• What are things in the method content? • How many types of process are there?

• Method Content• Work products• Tasks• Roles

• Types of Process• Waterfall• Iterative• Agile

Review• What are the major problems in waterfall model?

• Project progress cannot be measured accurately• Completing requirements without doing any architecture, development,

or testing will NOT give you an accurate indication of how long project would take

• User feedback cannot obtained until late in the project – when the system is available for use

• Resolution of certain risks (e.g., activity identifies flaws in design or requirements) is deferred until late in the project – after the system is built, integrated, and tested

• Project that follow a waterfall approach are prone to schedule slippage

What are major phases in iterative process according to OpenUP? Inception Phase, Elaboration phase, Construction Phase, Transition Phase

8

Architectural Viewpoints• The key architecture description concepts are:

• Viewpoint• View• Model

• Defined in IEEE 1471-2000 Recommended Practice for Architectural Description

• An architectural viewpoint defines a product in terms of a related set of concerns

9

Architectural Viewpoints (continued)• Basic viewpoints

• Requirements• System requirements that shape architecture• Include functional requirements, qualities, growth, and constraints

• Functional• Concerned with elements support functionality of system, such as

components, their relationships and behavior

• Deployment• Concerned with elements support distribution of system, such as nodes,

devices, and connections among them

• Validation• Provide an indication of whether the system will provide required

functionality, required qualities, required growth, and accommodate the defined constraints

10

Architectural Views• A view, in general, is what you see from your view point• A view is a window onto the whole architecture from a particular

vantage point • An architectural view shows part of product consistent with a

viewpoint• A requirements view will be different than a functional view of a product• However, the views MUST be consistent within and between themselves• Different views, single version of Truth

• In most cases, views are diagram types,

with multiple pages or sections

(e.g., sequence diagram)• These diagrams are models of the product

Like civil engineering models,

make the product easier to envision

and understand

11

Architectural Views (continued)• Model represent a work product that participates in a view• Models may represent different levels of realization

• A logical model shows how the product may be envisioned• A physical model shows how the product will be constructed

12

View Model of Software Architecture• The 4+1 View Model of Software Architecture is a commonly

used architecture description framework by Philippe Kruchten• To describe a software architecture, we use a model composed

of multiple views or perspectives• Consist of five main views:

• Logical view, which is the object model of the design (when an object-oriented design method is used).

• Process View, which captures the concurrency and synchronization aspects of the design,

• Development View, which describes the static organization of the software in its development environment.

• Physical View, view, which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect,

• Scenarios or use cases the description of an architecture is illustrated by a few selected uses cases or scenarios

13

View Model of Software Architecture

14

Logical View• The logical architecture primarily supports the functional requirements—

what the system should provide in terms of services to its users.• The system is decomposed into a set of key abstractions (e.g.,

packages), taken (mostly) from the problem domain, in the form of objects or object classes.

• The style we use for the logical view is an object-oriented style. The main guideline for the design of the logical view is to try to keep a single, coherent object model across the whole system

• Notation for the logical blueprint

15

Logical View - Examples• Shows the main classes (conversation, terminal, controller) using set of

services (translation, connection) involved in the Télic PABX architecture• Blueprint for an Air Traffic Control System (class diagram contains 8 class

categories (i.e., group of classes)

16

Logical View - Examples• Shows the overall decomposition of a DB Subsystem component into sub-

packages

17

Process View• Several styles for the process view: pipes and filters, or client/server,

with variants of multiple client/single server and multiple clients/multiple servers,

• Notation for the process blueprint

18

Process View - Examples• Shows the process blueprint for the Télic PABX architecture (partial)• All terminals are handles by a single process. Controller objects are

executed on one of three tasks (low rate -200ms, high rate 10ms)

19

Process View - Examples• Shows the distribution of DB subsystem across processes

HTTPS

<<process>>Database Backup

SharedLibraries

<<process>>Database Server

OracleEnterpriseManager (OEM)

Oracle RDBMS

<<process>>Web Browser 

JDBC

<<process>>Java EE ApplicationServer

20

Development View• Style for the process view: layered style • Notation for the development blueprint

21

Development View - Examples• The five layers of Hughes Air Traffic Systems (HATS)

22

Development View – Examples (cont)• The six layers of the development view of a typical SW architecture.• Shows allocation of the DB subsystem and its dependent software

components to the development view of the architecture

23

Physical View • Notation for the Physical blueprint – could be very messy in large

systems

24

Physical View - ExamplesPhysical blueprint for a larger PABX showing process allocation

25

Physical View - ExampleShows DB subsystem is deployed on a Database server

The deployment view of the software architecture shows where executables (COTS and non-COTS) and data for the software are installed.

Administrator Workstation

Web Browser

Database Server

Data Reduction

Installation & Configuration Scripts

Oracle RDBMS & Utilities

Stored Procedures & Packages

DDL

High Availability Support

26

Scenarios

• Put it all together• Notation for the Scenarios:

• The notation is very similar to the Logical view for the components (objects), but uses the connectors of the Process view for interactions between objects (message, RPC, message, bidirectional)

• Note that object instances are denoted with solid lines. As for the logical blueprint, we capture and manage object scenario diagrams using Rational Rose or Rhapsody Architecture tools

27

A scenario for a local call (small PABX)

The corresponding script reads:1. The controller of Joe’s phone detects and validate the transition from on-hook to off-hook and sends a message to wake up the corresponding terminal object.2. The terminal allocates some resources, and tells the controller to emit some dial-tone.3. The controller receives digits and transmits them to the terminal.4. The terminal uses the numbering plan to analyze the digit flow.5. When a valid sequence of digits has been entered, the terminal opens a conversation

28

Data Reduction Admin Use Case

29

Tailoring the Model• Not all software architecture need the full “4+1” views.

Views that are useless can be omitted from the architecture description, such as the physical view, if there is only one processor, and the process view if there is only process or program.

• For very small system, it is even possible that the logical view and the development view are so similar that they do not require separate descriptions.

• Especially using COTS products in your architecture (no need development view)

• The scenarios are useful in all circumstances.

30

Summary• The “4+1” view model has been used with success on several large projects

with or without some local customization and adjustment in terminology.• It actually allowed the various stakeholders to find what they want to know

about the software architecture. • Systems engineers approach it from the Physical view, then the Process view. • End-users, customers, data specialists from the Logical view. • Project managers, software configuration staff see it from the Development view..

31

Summary of “4+1” Model

Tool support Rose/Rhapsody Visio, Apex HP Openview Rhapsody, Visio

32

Documenting Software Architectures• IEEE 1471/ISO 42010 defines a standard for documenting

software architectures• Describes what constitutes a viewpoint and views, but does not

define a specific set of either to be used.

• Many different candidate views suggested by various authors• No consensus about even viewpoints

• Typically, the documentation produced during the architectural design is captured in two documents:• A Software Architecture Document, whose organization follows

closely the “4+1” views• • A Software Design Guidelines, which captures (among other

things) the most important design decisions that must be respected to maintain the architectural integrity of the system.

33

SW Architecture Document - a typical outline

34

Coming Next…• Next, we will take a look at architectural design process• Homework assignments this week –

• Read Chapter 4• Review Chapter 1,2, and 3

• Assignment #1 will be posted on TITANium on Thursday Sept 4 due Tuesday 9 7PM