©Medvidovic, Van Vliet, Mejia-AlvarezSlide 1 Architectural Design l Establishing the overall structure of a software system l Objectives To introduce architectural.

©Medvidovic, Van Vliet, Mejia-Alvarez Slide 1

Architectural Design

Establishing the overall structure of a software system

Objectives• To introduce architectural design and to discuss its

importance• To explain why multiple models are required to

document a software architecture• To describe types of architectural model that may be

used


What is Architecture? A high-level model of a thing

• Describes critical aspects of the thing

• Understandable to many stakeholders

• Allows evaluation of the thing’s properties before it is built

• Provides well understood tools and techniques for constructing the thing from its blueprint

Which aspects of a software system are architecturally relevant? How should they be represented most effectively to enable

stakeholders to understand, reason, and communicate about a system before it is built?

What tools and techniques are useful for implementing an architecture in a manner that preserves its properties?


What is Software Architecture? A software system’s blueprint

• Its components• Their interactions• Their interconnections

Informal descriptions• Boxes and lines• Informal prose

A shared, semantically rich vocabulary• Remote procedure calls (RPCs)• Client-Server• Pipe and Filer• Layered• Distributed• Object-Oriented


From Requirements to Architecture From problem definition to requirements specification

• Determine exactly what the customer and user want

• Specifies what the software product is to do From requirements specification to architecture

• Decompose software into modules with interfaces

• Specify high-level behavior, interactions, and non-functional properties

• Consider key tradeoffs» Schedule vs. Budget

» Cost vs. Robustness

» Fault Tolerance vs. Size

» Security vs. Speed

• Maintain a record of design decisions and traceability

• Specifies how the software product is to do its tasks


Another View:The Twin Peaks Model


Focus of Software Architectures Two primary foci

• System Structure, Behavior, Interactions, Topology, Data, and key Properties

• Correspondence between requirements and implementation

A framework for understanding system-level concerns

• Global rates of flow

• Communication patterns

• Execution Control Structure

• Scalability

• Paths of System Evolution

• Capacity

• Throughput

• Consistency

• Component Compatibility


Why Software Architecture? A key to reducing development costs

• Component-based development philosophy• Explicit system structure

A natural evolution of design abstractions• Structure and interaction details overshadow the choice of algorithms

and data structures in large/complex systems Benefits of explicit architectures

• A framework for satisfying requirements• Technical basis for design• Managerial basis for cost estimation & process management• Effective basis for reuse• Basis for consistency, dependency, and tradeoff analysis• Avoidance of architectural erosion


aTruck aShip aAirplane theWarehouseCo llecti on

theVehicleCollection

UML-A Generated Dependency Class:theRouter Dependency (1.0)

theStorage

aVehicle


availableVehicleCollection

UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Genera ted As socia tion C lass: theVehicleC ollec tion Genera lization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML- A Generated Ass ociati on Cl ass:theVehi cleCo llection Generali zation (1.0 )UML-A Generated Association Class:theVehicleCollection Generalization (1.0)


availableGoods

aPort

aPortC ollec tion

aSurp lus aDifficiency

theTimeNeeded

theGoods

UML-A Generated Association Class:aWarehouse Association (0.5)


UML-A Generated Association Class:availableGoods Association (0.5)

aRouteCollection

UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)

UML-A Generated Dependency Class:theRouter Dependency (0.5)UML-A Generated Dependency Class:theRouter Dependency (1.0)


theAWT

aVehiceDialog aWarehouseDialog aPortDialog aRouterDialog

aWarehouse

UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)

UML-A Generated Association Class:aDifficiency Association (1.0)U ML-A Generated Association Class:aD ifficiency Associ ation (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)U ML-A Generated Association Class:aD ifficiency Associ ation (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Genera ted Associ ation C lass:aSurp lus Associ ation (1.0)UML-A Generated Association Class:aSurplus Association (0.5)

UML-A Generated Associ ation Class:aRoute Association (0.5)

aLocation

UML-A Generated Association Class:aNavPoint Association (1.0)



UML-A Generated Association Class:aNavPoint Association (0.5)UML-A Generated Association Class:aNavPoint Association (0.5)

UML-A Generated Association Class:aWarehouse Association (0.5)aNavPoint


UML-A Generated Association Class:aWarehouse Association (0.5)UML-A Generated Association Class:aWarehouse Association (0.5)



UML-A Generated Association Class:aRoute Association (0.5)

aRoute

UML-A Genera ted Dependency C lass :aRou teCol lection Ass ociation (0.25)



UML-A Generated Dependency Class:aRouteCollection Association (0.5)

UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)



UML-A Generated Dependency Class:theRouter Association (0.25)


theCargoRouter

UML-A Generated Association Class:theRouter Association (0.25)

UML-A Genera ted As socia tion C lass: theWarehouseCo llection Dependency ( 0.25)



t heRou ter

UML-A Generated Association Class:theWarehouseCollection Dependency (0.5)

UML-A Generated Association Class:theWarehouseCollection Dependency (0.5)

UML-A Genera ted Dependency Class :aRouteCollection Ass ociation (0.5)UML-A Generated Association Clas s:theWarehouseCollec tion Dependency (0.5)

UML-A Generated Association Class:theVehicleCollection Dependency (0.5)UML-A Generated Association Class:availableVehicleCollection Dependency (0.5)UML- A Generated Generaliz ation Class :avail ableVehicleCollection Dependenc y (1.0 )


UML-A Generated Dependency Class:theRouter Association (0.5)UML-A Generated Dependency Class:theRouter Association (1.0)


UML-A Generated Dependency Class:theWarehouseCollection Dependency (1.0)

UML-A Generated Dependency Class:theRouter Association (1.0)UML-A Generated Dependency Class:theRouter Association (1.0)

What is the Problem?This is a simple

software system!


aTruck aShipaAirplane

availableVehicleCollection

theAWT

aVehiceDialogaWarehouseDialog

aPortDialog

aRouterDialog

aRouteCollection

aVehicle

theVehicleCollection

theCargoRouter

theRouter

theTim eNeeded

aRoute

aDeficiency

theWarehouseCollection

aNavPoint

theStorage

RefrigeratedStorage

RegularStorage

availableGoods

aPortCollection

aLocation

theGoods

aWarehouse

aSurplus

aPort

The Usual Tool: Design Abstraction

We have to do better!


VehicleDel iveryPort

CargoRouter

RouterConn

GraphicsBinding : GraphicsBinding

GraphicsConn

Warehouse

ClockConn

Clock : Clock

10: notification9: notification

5: request

3: request4: request

2: notification

1: request

7: request

6: notification

8: request

Architectural Abstraction


What is Software Architecture? Definition:

• A software system’s architecture is the set of principal design decisions about the system

Software architecture is the blueprint for a software system’s construction and evolution

Design decisions encompass every facet of the system under development• Structure

• Behavior

• Interaction

• Non-functional properties


Other Definitions of Software Architecture Perry and Wolf

• Software Architecture = { Elements, Form, Rationale }what how why

Shaw and Garlan• Software architecture [is a level of design that] involves

» the description of elements from which systems are built, » interactions among those elements, » patterns that guide their composition, and » constraints on these patterns.

Kruchten• Software architecture deals with the design and implementation of the high-

level structure of software.• Architecture deals with abstraction, decomposition, composition, style, and

aesthetics.


Architectural design process System structuring

• The system is decomposed into several principal sub-systems

• Communications between these sub-systems are identified

Control modelling• A model of the control relationships between the different parts

of the system is established

Modular decomposition• The identified sub-systems are decomposed into modules


Key Architectural Concepts Three canonical building blocks

• components• connectors• configurations

A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems

A module is a system component that provides services to other components but would not normally be considered as a separate system


Components A component is a unit of computation or a data store Components are loci of computation and state

• clients• servers• databases• filters• layers• ADTs

A component may be simple or composite• composite components describe a (sub)system• an architecture consisting of composite components describes a system

of systems


Components Elements that encapsulate processing and data in a system’s

architecture are referred to as software components Definition

• A software component is an architectural entity that

» encapsulates a subset of the system’s functionality and/or data

» restricts access to that subset via an explicitly defined interface

» has explicitly defined dependencies on its required execution context

Components typically provide application-specific services


Software components In most engineering disciplines, systems are

designed by composing existing components that have been used in other systems

Software engineering has been more focused on original development

It is now recognized that to achieve • better software• more quickly • at lower cost

we need to adopt a design process that is based on systematic reuse


Components Components provide a service without regard to

where the component is executing or its programming language• A component is an independent executable entity that

can be made up of one or more executable objects

• The component interface is published and all interactions are through the published interface

Components can range in size from simple functions to entire application systems


A software component: Implements some functionality

Has explicit dependencies through provided and required interfaces

Communicates through its interfaces only

Has structure and behavior that conforms to a component model


LEGO analogy Set of building blocks in different shapes and

colors Can be combined in different ways Composition through small stubs in one and

corresponding holes in another building block LEGO blocks are generic and easily

composable LEGO can be combined with LEGO, not with

e.g. MEGA Bloks


Component abstractions Functional abstraction

• The component implements a single function such as a mathematical function

Casual groupings • The component is a collection of loosely related entities that might be data

declarations, functions, etc.

Data abstractions • The component represents a data abstraction or class in an OO language

Cluster abstractions • The component is a group of related classes that work together

System abstraction • The component is an entire self-contained system


Why CBSE?

CBSE increases quality, especially evolvability and maintainability

CBSE increases productivity

CBSE shortens development time


Hiding of component internals

Black box: only specification is known Glass box: internals may be inspected, but not

changed Grey box: part of the internals may be inspected,

limited modification is allowed While box: component is open to inspection and

modification


Development process in CBSE

Two separate development processes:• Development of components

• Development of systems out of components

Separate process to assess components


CBSE system development process

Requirements: also considers availability of components (as in COTS)

Analysis and design: very similar to what we normally do Implementation: less coding, focus on selection of

components, provision of glue code Integration: largely automated Testing: verification of components is necessary Release: as in classical approaches Maintenance: replace components


Component assessment

Find components

Verify components

Store components in repository


Component development process Components are intended for reuse

Managing requirements is more difficult More effort required to develop reusable

components More effort in documentation for consumers


Component development process Requirements: combination of top-down (from

system) and bottom-up (generality) Analysis and design: generality is an issue,

assumptions about system (use) must be made Implementation: largely determined by

component technology Testing: extensive (no assumptions of usage!),

and well-documented Release: not only executables, also metadata


Software Connector Architectural element that models

• Interactions among components• Rules that govern those interactions

Simple interactions• Procedure calls• Shared variable access

Complex & semantically rich interactions• Client-server protocols• Database access protocols• Asynchronous event multicast

Each connector provides• Interaction duct(s)• Transfer of control and/or data


Where are Connectors in Software Systems?

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.


Benefits of First-Class Connectors

Separate computation from interaction Minimize component interdependencies Support software evolution

• At component-, connector-, & system-level

Potential for supporting dynamism Facilitate heterogeneity Become points of distribution Aid system analysis & testing


An Example of Explicit Connectors



An Example of Explicit Connectors



Software Connector Roles

Communication Coordination Conversion Facilitation


Connector Types Procedure call Data access Event Stream Linkage Distributor Arbitrator Adaptor


A Framework for Classifying Connectors



Procedure Call Connectors



Event Connectors



Data Access Connectors



Linkage Connectors



Stream Connectors



Arbitrator Connectors



Adaptor Connectors



Distributor Connectors



How Does One Select a Connector?

Determine a system’s interconnection and interaction needs

• Software interconnection models can help Determine roles to be fulfilled by the system’s connectors

• Communication, coordination, conversion, facilitation For each connector

• Determine its appropriate type(s)

• Determine its dimensions of interest

• Select appropriate values for each dimension For multi-type, i.e., composite connectors

• Determine the atomic connector compatibilities


Configurations/Topologies An architectural configuration or topology is a connected

graph of components and connectors that describes architectural structure

• proper connectivity

• concurrent and distributed properties

• adherence to design heuristics and style rules

Composite components are configurations

C3 C4 C5

A

B C

D

C2C1

C7C6


Scope of Software Architectures Every system has an architecture. Details of the architecture are a reflection of system

requirements and trade-offs made to satisfy them Possible decision factors

• Performance• Compatibility with legacy software• Planning for reuse• Distribution profile

» Current and Future

• Safety, Security, Fault tolerance requirements• Evolvability Needs

» Changes to processing algorithms» Changes to data representation» Modifications to the structure/functionality


Example Architecture – Compiler

Lexer

Parser

Semantor

Optimizer

CodeGenerator

Lexer Parser Semantor

InternalRepresentation

OptimizerCode

Generator

Sequential Parallel


CASE toolset architecture

Projectrepository

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator


Version management system

Operatingsystem

Database system

Object management

Version management


Packing robot control systemVisionsystem

Objectidentification

system

Armcontroller

Grippercontroller

Packagingselectionsystem

Packingsystem

Conveyorcontroller


Film and picture library

Catalogueserver

Catalogue

Videoserver

Film clipfiles

Pictureserver

Digitizedphotographs

Hypertextserver

Hypertextweb

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network


Architecture in Action: Product Line

Motivating example• A consumer is interested in a 35-inch HDTV with a built-in

DVD player for the North American market.

Such a device might contain upwards of a million lines of embedded software.

This particular television/DVD player will be very similar to a 35-inch HDTV without the DVD player, and also to a 35-inch HDTV with a built-in DVD player for the European market, where the TV must be able to handle PAL or SECAM encoded broadcasts, rather than North America’s NTSC format.

These closely related televisions will similarly each have a million or more lines of code embedded within them.


Growing Sophistication of Consumer Devices


Families of Related Products


The Necessity and Benefit of PLs Building each of these TVs from scratch would

likely put Philips out of business Reusing structure, behaviors, and component

implementations is increasingly important to successful business practice • It simplifies the software development task

• It reduces the development time and cost

• it improves the overall system reliability

Recognizing and exploiting commonality and variability across products


Reuse as the Big Win Architecture: reuse of

• Ideas

• Knowledge

• Patterns

• engineering guidance

• Well-worn experience

Product families: reuse of • Structure

• Behaviors

• Implementations

• Test suites…


Added Benefit – Product Populations


The Centerpiece – Architecture


Analogies to Software Architecture

Hardware architecture• small number of design elements

• scale by replication of (canonical) design elements

Network architecture• focus on topology

• only a few topologies considered» e.g., star, ring, grid

Building architecture• multiple views

• styles


Architectural models Different architectural models may be produced

during the design process Each model presents different perspectives on the

architecture• Static structural model that shows the major system components

• Dynamic process model that shows the process structure of the system

• Interface model that defines sub-system interfaces

• Deployment model shows the relationship between system elements and hosts


An Example Static Model

Deployment Strategies Repository

Simulation Agent

Sym

me

tric

C_DataRepository

C_Troops Manager

C_Display Manager

C_AppManager

Deployment Advisor

Strategy Analyzer

Asymmetric

Asymmetric

Display Manager

Asymmetric

Asymmetric

S_Troops Manager

S_Display Manager

Asymmetric

Asymmetric

Asymmetric

Offensive Strategy

Defensive Strategy

Decision Module

DataRepository

Sym

me

tric



An example Deployment Model

Headquarters

Commander

Deployment Strategies Repository

Simulation Agent

Sym

met

ric

C_DataRepository

C_Troops Manager

C_Display Manager

C_AppManager

Deployment Advisor

Strategy Analyzer

Asymmetric

Asymmetric

Display Manager

Distributed Asymmetric


Asymmetric

Asymmetric

Dis

trib

uted

S

ymm

etric

Soldier

S_Troops Manager

S_Display Manager


Asymmetric

Distributed

S

ymm

etric

Asymmetric

Asymmetric

Offensive Strategy

Defensive Strategy

Decision Module

DataRepository



Key points The software architect is responsible for deriving

a structural system model, a control model and a sub-system decomposition model

Large systems rarely conform to a single architectural model

Key architectural concepts are components, connectors, and configurations


Bibliography The material of this class come from the Software

Engineering class of Ian Sommerville, Nenad Medvidovic, and Han Van Vliet.

©Medvidovic, Van Vliet, Mejia-AlvarezSlide 1 Architectural Design l Establishing the overall structure of a software system l Objectives To introduce architectural.

Documents

van vliet

software systems

software product

architectural design

primary foci system

requirements specification

design managerial basis

twin peaks model slide