1. Elements of Software Architecture
CSPC 464 Fall 2014
Son Nguyen

2. References
Architecture Blueprints _ The “4+1” View Model of Software Architecture, Phiippe Kruchten
Software Architecture for Developers, Simon Brown
An Introduction to Software Architecture, David Garlan and Mary Shaw
Software Architecture, A. Bijlsma, B.J. Heerendr., E.E> Roubtovair, S. Stuurman

3. 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

4. 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?

5. 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

7. 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 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
Shared
Libraries
Database Server
Oracle
Enterprise
Manager (OEM)
Oracle RDBMS
Web Browser
JDBC
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
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 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