ELEMENTS OF
SOFTWARE
ARCHITECTURE
CSPC 464 Fall 2014
Son Nguyen
2
References
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
1.
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
<<process>>
Database Server
Oracle
Enterprise
Manager (OEM)
<<process>>
Web Browser
HTTPS
<<process>>
Database Backup
Oracle RDBMS
Shared
Libraries
JDBC
<<process>>
Java EE Application
Server
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 - Examples
Physical blueprint for a larger PABX showing process allocation
25
Physical View - Example
Shows 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
Oracle RDBMS & Utilities
DDL
Stored Procedures & Packages
Installation & Configuration Scripts
Data Reduction
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