Architectural Design Objectives Architectural Design You will be

Architectural Design

Objectives: Architectural Design You will be able to: n List the attributes of good architectures n Investigate the “ 4+1” view of architecture n Explain the purpose of component diagrams n Explain the purpose of deployment diagrams

Architectural Vision n n Two traits common to virtually all successful OO projects are: q The existence of a strong architectural vision q The application of a well-managed, iterative and incremental lifecycle The architecture should be simple q Common behavior achieved through common abstractions and common mechanisms

Attributes of Good Architectures n n Good architectures are constructed in well-defined layers of abstraction: q Each layer represents a coherent abstraction q Each layer has a well-defined and controlled interface q 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 q Changes to the implementation of a layer do not violate assumptions made by its clients

Developing the System Architecture n n n 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: q Defining and maintaining the architectural integrity of the system q Approving all changes to package interfaces q Assessing project risks q Proposing the order and content of each iteration

Dimensions of Software Architecture n n Different perspectives for different stakeholders q End user, customer, project manager q System engineer, developer, architect, tester Multiple perspectives require multiple views q Class diagrams don’t show the system maps to hardware q Hardware block diagrams don’t depict what parts of the system are COTS

An Architecture Requires Multiple Views n n To completely describe an architecture, four views are needed: q The logical view to provide a static picture of the primary classes and their relationships q The development view to show the code is organized into packages and libraries and the use of commercial off-the-shelf (COTS) software q The process view to show the processes and tasks q 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

The “ 4+1 View” Model Logical View Development View Functionality Software Management, Reuse, Portability End-Users Scenarios Understandability Usability Software Engineers Process View Physical View Performance, Availability, Fault Tolerance, Scalability, Delivery and Installation System Integrators System Engineers

Logical View n n n The logical view of architecture addresses the functional requirements of the system q 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

Global Logical Packages n n Certain packages are used by all other packages q Foundation classes l Sets, lists, queues, etc. q Error handling classes These packages are marked global

Dependency Implications n Some of the implications of package dependency are: q Whenever a change is made to the supplier package, the Client package must, potentially, be recompiled and retested q The Client package cannot be reused independently because it depends on the supplier package

Avoiding Circular Dependencies n n n It is desirable that the package hierarchy be acyclic This means that the following situation should be avoided (if possible) q 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 q 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

Circular Dependency in the Registration System Changed to

Development View n n n 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 q Shows the allocation of classes to components q Shows the allocation of components to packages The packages are organized in a hierarchy of layers where each layer has a well defined interface

Component n n 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. q 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:

Component Diagram n A component diagram shows the allocation of classes and objects to implementation components as well as their compilation dependencies Name 1 Name 2 Name 1 Name 3

Component Diagrams n n 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

Example: Component Diagram Curriculum Course

Packages in the Development View n n n 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:

Top-level Component Diagrams n n A top-level component diagram is a family of packages connected by directed links that represent dependencies Example: MFC Registration. User Interface Registration System

Correspondence Between Packages in the Logical and Development Views n n 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: q Packages in the logical view are merged, e. g. , to keep closelycommunicating objects together for implementation q Packages in the development view are added to implement lowlevel functionality not represented during analysis q The work breakdown structure of the development team influences the allocation of packages and components in the development view

Example: Correspondence Between Logical and Physical Structure Gui. Widgets Registration. User Interface Registration System Logical View Top-Level Diagram MFC Registration. User Interface Registration System Development View Top-Level Diagram

Process View n n n The process view of architecture focuses on process decomposition q 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

Process Components n Executables and linked libraries are represented as components in UML q Package specification (DLL) q Task specification (EXE) Package specification (DLL) Task Specification (EXE)

Component Diagram for a Process n Each component may depend on other components My. Process. exe Name 1 Name 2 Name 1

Processes for the Course Registration System Curriculum. exe Registration. exe Process for the creation and maintenance of the curriculum Process for course selection by students and professors

Physical View n n n 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

Deployment Diagrams n n n A deployment diagram shows the allocation of processes to nodes in the physical view of a system q Processors and devices are common stereotypes of 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

Notation for Deployment Diagrams n n A node is a run-time physical object representing computational resources A connection indicates communication, usually by means of direct hardware coupling name label node connection

Example: Registration System Deployment Diagram n This diagram shows two nodes and the devices with which the Registration System communicates Database Registration System Dorm <<device>> Library Main Building <<device>>

Processes n n A process is the execution of one thread of control of an (OO) program or system q 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: Processor Name process 1, process 2, . . . process n

Mapping Development Packages to Executable Processes n n Mapping development packages to executable processes involves understanding the system topology and system priorities including: q Processor architecture, speed and capacity q Keeping class associations together to minimize interprocess communication (IPC) q IPC strategy -- client/supplier or other? q Distributed processing techniques Must resolve issues involving multiple hardware processors or distributed systems during system design

Mapping Executable Processes to Hardware n n Processes must be assigned to a hardware device for execution Among the considerations are: q Response time and system throughput q Communication bandwidth/capacity q Physical location of hardware required q Distributed processing needs q Processor overloading or balance in a distributed system q Fault tolerance q. . .

Scenarios n n Scenarios are the glue that hold the four views together q Drivers for the architecture design l Abstractions of large, complex requirements l Identification of critical interfaces l Force designers to focus on concrete issues They demonstrate and validate the logical, process, development, and physical views of the architecture

Sample Scenarios n n Development view q Port to new platform Logical view q Message change impact q Replacement of custom objects with COTS objects Process view q Peak loading overhead q Critical thread transaction Physical view q Node failure q Node off-line for preventive maintenance

How Is the Architecture Documented? n n The architecture is documented in an architecture document q Approximately 100 pages for a large system The document includes: q A textual description of the architectural philosophy (the views) and the key driving requirements q Tradeoffs made and alternatives considered q A top-level view of the logical view (5 -50 key classes) q Architecture-specific scenarios q Top-level views of the development, process and physical views q The key mechanisms

Exercise: Architecture Design n n Discuss architecture considerations for the problem Add packages to the model as needed

Summary: Architectural Design n n 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: q Good architectures are constructed in well-defined layers of abstraction q There is a clear separation between the interface and implementation of each layer q The architecture is simple

Summary: Architectural Design n The logical view of architecture addresses the functional requirements of the system q 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 q 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 q Component diagrams are created to show the packages and components that make up the system

Summary: Architectural Design n n The physical view of architecture maps software to processing nodes q 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