1. OOAD Using UML, v. 3.0 Architectural Design, p. 1 Copyright © 1997 by Rational Software Corporation R Architectural Design

2. OOAD Using UML, v. 3.0 Architectural Design, p. 2 Copyright © 1997 by Rational Software Corporation R Objectives: Architectural Design You will be able to: List the attributes of good architectures Investigate the “4+1” view of architecture Explain the purpose of component diagrams Explain the purpose of deployment diagrams

3. OOAD Using UML, v. 3.0 Architectural Design, p. 3 Copyright © 1997 by Rational Software Corporation R Architectural Vision Two traits common to virtually all successful OO projects are:  The existence of a strong architectural vision  The application of a well-managed, iterative and incremental lifecycle The architecture should be simple  Common behavior achieved through common abstractions and common mechanisms

4. OOAD Using UML, v. 3.0 Architectural Design, p. 4 Copyright © 1997 by Rational Software Corporation R Attributes of Good Architectures Good architectures are constructed in well-defined layers of abstraction:  Each layer represents a coherent abstraction  Each layer has a well-defined and controlled interface  Each layer is built upon well-defined and controlled facilities at lower levels of abstraction There is a clear separation between the interface and implementation of each layer  Changes to the implementation of a layer do not violate assumptions made by its clients

5. OOAD Using UML, v. 3.0 Architectural Design, p. 5 Copyright © 1997 by Rational Software Corporation R Developing the System Architecture Architecture design deals with risk management Good architectures are best determined through iterative and incremental development A small, experienced architecture team, led by a Chief Architect, should be assigned responsibility for:  Defining and maintaining the architectural integrity of the system  Approving all changes to package interfaces  Assessing project risks  Proposing the order and content of each iteration

6. OOAD Using UML, v. 3.0 Architectural Design, p. 6 Copyright © 1997 by Rational Software Corporation R Different perspectives for different stakeholders  End user, customer, project manager  System engineer, developer, architect, tester Multiple perspectives require multiple views  Class diagrams don’t show how the system maps to hardware  Hardware block diagrams don’t depict what parts of the system are COTS Dimensions of Software Architecture

7. OOAD Using UML, v. 3.0 Architectural Design, p. 7 Copyright © 1997 by Rational Software Corporation R An Architecture Requires Multiple Views To completely describe an architecture, four views are needed:  The logical view to provide a static picture of the primary classes and their relationships  The development view to show how the code is organized into packages and libraries and the use of commercial off-the-shelf (COTS) software  The process view to show the processes and tasks  The physical view to show the processors, devices, and links in the operational environment Finally, a scenario view explains how the other four views work together

8. OOAD Using UML, v. 3.0 Architectural Design, p. 8 Copyright © 1997 by Rational Software Corporation R The “4+1 View” Model Development View Process ViewPhysical View Scenarios Logical View Functionality End-Users Software Management, Reuse, Portability Software Engineers Performance, Availability, Fault Tolerance System Integrators Performance, Availability, Fault Tolerance, Scalability, Delivery and Installation System Engineers Understandability Usability

9. OOAD Using UML, v. 3.0 Architectural Design, p. 9 Copyright © 1997 by Rational Software Corporation R Logical View The logical view of architecture addresses the functional requirements of the system  What the system will provide in terms of services to its users Provides a static picture of the primary classes and their relationships The logical view is captured in class diagrams which contain the packages, classes, and relationships that represent the key abstractions of the system under development

10. OOAD Using UML, v. 3.0 Architectural Design, p. 10 Copyright © 1997 by Rational Software Corporation R Global Logical Packages Certain packages are used by all other packages  Foundation classes Sets, lists, queues, etc.  Error handling classes These packages are marked global

11. OOAD Using UML, v. 3.0 Architectural Design, p. 11 Copyright © 1997 by Rational Software Corporation R Dependency Implications Some of the implications of package dependency are:  Whenever a change is made to the supplier package, the Client package must, potentially, be recompiled and retested  The Client package cannot be reused independently because it depends on the supplier package

12. OOAD Using UML, v. 3.0 Architectural Design, p. 12 Copyright © 1997 by Rational Software Corporation R Avoiding Circular Dependencies It is desirable that the package hierarchy be acyclic This means that the following situation should be avoided (if possible)  Package A uses package B which uses package A Such a circular dependency means that packages A and B will effectively have to be treated as a single package Circles wider than two packages must also be avoided  e.g., package A uses package B which uses package C which uses package A Circular dependencies may be able to be broken by splitting one of the packages into two smaller packages

13. OOAD Using UML, v. 3.0 Architectural Design, p. 13 Copyright © 1997 by Rational Software Corporation R Circular Dependency in the Registration System Changed to

14. OOAD Using UML, v. 3.0 Architectural Design, p. 14 Copyright © 1997 by Rational Software Corporation R Development View The development (or component) view of architecture is concerned with the actual software module organization within the development environment Component diagrams are created to show the (developmental) packages and components that make up the system under development  Shows the allocation of classes to components  Shows the allocation of components to packages The packages are organized in a hierarchy of layers where each layer has a well defined interface

15. OOAD Using UML, v. 3.0 Architectural Design, p. 15 Copyright © 1997 by Rational Software Corporation R Component A component is a unit of source code that serves as a building block for the physical structure of a system Stereotypes (with alternate icons) may be used to define specific kinds of components.  Examples: exe, dll, main programs, headers, modules, forms Group classes in a component that either have a cooperative function or that need to be in close proximity for implementation efficiency Component notation:

16. OOAD Using UML, v. 3.0 Architectural Design, p. 16 Copyright © 1997 by Rational Software Corporation R Component Diagram A component diagram shows the allocation of classes and objects to implementation components as well as their compilation dependencies Name1 Name3 Name2 Name1 Name2

17. OOAD Using UML, v. 3.0 Architectural Design, p. 17 Copyright © 1997 by Rational Software Corporation R Component Diagrams A name is required for each component; this name typically denotes the simple name of the corresponding physical file in the development workspace The only relationship is a compilation dependency, represented by a directed dashed line pointing to the module upon which the dependency exists In C++, a compilation dependency is indicated by #include directives There may be no cycles within a set of compilation dependencies

18. OOAD Using UML, v. 3.0 Architectural Design, p. 18 Copyright © 1997 by Rational Software Corporation R Example: Component Diagram Curriculum Course

19. OOAD Using UML, v. 3.0 Architectural Design, p. 19 Copyright © 1997 by Rational Software Corporation R Packages in the Development View A package in the development view is a collection of components, some of which are visible to other packages and others of which are hidden A package groups components that are logically related A package groups components in a similar way to that in which a package groups classes Each component in a system must live in a single package or at the top level of the system Notation:

20. OOAD Using UML, v. 3.0 Architectural Design, p. 20 Copyright © 1997 by Rational Software Corporation R Top-level Component Diagrams A top-level component diagram is a family of packages connected by directed links that represent dependencies Example: MFCRegistrationUser Interface Registration System

21. OOAD Using UML, v. 3.0 Architectural Design, p. 21 Copyright © 1997 by Rational Software Corporation R Correspondence Between Packages in the Logical and Development Views In general, a package in the logical view can correspond directly to a package in the development view The logical structure and the physical structure may vary for the following reasons:  Packages in the logical view are merged, e.g., to keep closely- communicating objects together for implementation  Packages in the development view are added to implement low- level functionality not represented during analysis  The work breakdown structure of the development team influences the allocation of packages and components in the development view

22. OOAD Using UML, v. 3.0 Architectural Design, p. 22 Copyright © 1997 by Rational Software Corporation R Example: Correspondence Between Logical and Physical Structure Logical View Top-Level DiagramDevelopment View Top-Level Diagram MFC RegistrationUser Interface Registration System GuiWidgetsRegistrationUser Interface Registration System

23. OOAD Using UML, v. 3.0 Architectural Design, p. 23 Copyright © 1997 by Rational Software Corporation R Process View The process view of architecture focuses on process decomposition  This view shows the allocation of components to processes The component diagram is updated to show the allocation of components to processes The process view addresses the system’s availability, reliability, performance, system management, synchronization

24. OOAD Using UML, v. 3.0 Architectural Design, p. 24 Copyright © 1997 by Rational Software Corporation R Process Components Executables and linked libraries are represented as components in UML  Package specification (DLL)  Task specification (EXE) Package specification (DLL) Task Specification (EXE)

25. OOAD Using UML, v. 3.0 Architectural Design, p. 25 Copyright © 1997 by Rational Software Corporation R Component Diagram for a Process Each component may depend on other components Name1 Name2 Name1 Name2 MyProcess.exe

26. OOAD Using UML, v. 3.0 Architectural Design, p. 26 Copyright © 1997 by Rational Software Corporation R Processes for the Course Registration System Curriculum.exeRegistration.exe Process for the creation and maintenance of the curriculum Process for course selection by students and professors

27. OOAD Using UML, v. 3.0 Architectural Design, p. 27 Copyright © 1997 by Rational Software Corporation R Physical View The physical view of architecture maps processes to processing nodes Requirements such as throughput, performance, and fault-tolerance are taken into account Deployment diagrams are created to show the different nodes (processors and devices) in the system

28. OOAD Using UML, v. 3.0 Architectural Design, p. 28 Copyright © 1997 by Rational Software Corporation R Deployment Diagrams A deployment diagram shows the allocation of processes to nodes in the physical view of a system  Processors and devices are common stereotypes of Node. Nodes are connected in a diagram that reflects the communication paths between them The essential elements of a deployment diagram are nodes and their connections

29. OOAD Using UML, v. 3.0 Architectural Design, p. 29 Copyright © 1997 by Rational Software Corporation R Notation for Deployment Diagrams A node is a run-time physical object representing computational resources A connection indicates communication, usually by means of direct hardware coupling nodeconnection name label

30. OOAD Using UML, v. 3.0 Architectural Design, p. 30 Copyright © 1997 by Rational Software Corporation R Example: Registration System Deployment Diagram This diagram shows two nodes and the devices with which the Registration System communicates Registration System Database Dorm Main Building Library >

31. OOAD Using UML, v. 3.0 Architectural Design, p. 31 Copyright © 1997 by Rational Software Corporation R Processes A process is the execution of one thread of control of an (OO) program or system  A large system can be broken into multiple processes or threads of control Objects are assigned to processes (their assignments can be dynamic) Processes are assigned to processors (the set of processes can be dynamic) Notation: process 1, process 2,... process n Processor Name

32. OOAD Using UML, v. 3.0 Architectural Design, p. 32 Copyright © 1997 by Rational Software Corporation R Mapping Development Packages to Executable Processes Mapping development packages to executable processes involves understanding the system topology and system priorities including:  Processor architecture, speed and capacity  Keeping class associations together to minimize interprocess communication (IPC)  IPC strategy -- client/supplier or other?  Distributed processing techniques Must resolve issues involving multiple hardware processors or distributed systems during system design

33. OOAD Using UML, v. 3.0 Architectural Design, p. 33 Copyright © 1997 by Rational Software Corporation R Mapping Executable Processes to Hardware Processes must be assigned to a hardware device for execution Among the considerations are:  Response time and system throughput  Communication bandwidth/capacity  Physical location of hardware required  Distributed processing needs  Processor overloading or balance in a distributed system  Fault tolerance ...

34. OOAD Using UML, v. 3.0 Architectural Design, p. 34 Copyright © 1997 by Rational Software Corporation R Scenarios Scenarios are the glue that hold the four views together  Drivers for the architecture design Abstractions of large, complex requirements Identification of critical interfaces Force designers to focus on concrete issues They demonstrate and validate the logical, process, development, and physical views of the architecture

35. OOAD Using UML, v. 3.0 Architectural Design, p. 35 Copyright © 1997 by Rational Software Corporation R Sample Scenarios Development view  Port to new platform Logical view  Message change impact  Replacement of custom objects with COTS objects Process view  Peak loading overhead  Critical thread transaction Physical view  Node failure  Node off-line for preventive maintenance

36. OOAD Using UML, v. 3.0 Architectural Design, p. 36 Copyright © 1997 by Rational Software Corporation R How Is the Architecture Documented? The architecture is documented in an architecture document  Approximately 100 pages for a large system The document includes:  A textual description of the architectural philosophy (the views) and the key driving requirements  Tradeoffs made and alternatives considered  A top-level view of the logical view (5-50 key classes)  Architecture-specific scenarios  Top-level views of the development, process and physical views  The key mechanisms

37. OOAD Using UML, v. 3.0 Architectural Design, p. 37 Copyright © 1997 by Rational Software Corporation R Exercise: Architecture Design Discuss architecture considerations for the problem Add packages to the model as needed

38. OOAD Using UML, v. 3.0 Architectural Design, p. 38 Copyright © 1997 by Rational Software Corporation R Summary: Architectural Design The purpose of the design phase is to create an architecture for the implementation and establish the common tactical policies that must be used throughout the system The attributes of good architectures are:  Good architectures are constructed in well-defined layers of abstraction  There is a clear separation between the interface and implementation of each layer  The architecture is simple

39. OOAD Using UML, v. 3.0 Architectural Design, p. 39 Copyright © 1997 by Rational Software Corporation R Summary: Architectural Design The logical view of architecture addresses the functional requirements of the system  Class diagrams which represent the key abstractions of the system The process view of architecture addresses the system’s availability, reliability, scalability, integrity, performance, system management, and synchronization  System is decomposed into a set of independent tasks which are grouped into processes The development view of architecture addresses the software organization of the system  Component diagrams are created to show the packages and components that make up the system

40. OOAD Using UML, v. 3.0 Architectural Design, p. 40 Copyright © 1997 by Rational Software Corporation R Summary: Architectural Design The physical view of architecture maps software to processing nodes  Deployment diagrams are created to show the different processors and devices in the system Scenarios demonstrate and validate the logical, process, development, and physical views of architecture

41. OOAD Using UML, v. 3.0 Architectural Design, p. 41 Copyright © 1997 by Rational Software Corporation R 