Elements of Software Architecture CSPC 464 Fall 2014 Son Nguyen

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

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

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

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

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

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

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

View Model of Software Architecture

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

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)

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

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

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)

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

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

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

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

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

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

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

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

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

Data Reduction Admin Use Case

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.

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

Summary of “4+1” Model Tool support Rose/Rhapsody Visio, Apex HP Openview Rhapsody, Visio

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.

SW Architecture Document - a typical outline

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