Doradjen Pregled Kursa i Tipovi Arhitektura 100 Slajdova

8/3/2019 Doradjen Pregled Kursa i Tipovi Arhitektura 100 Slajdova

1/170

Software Architecture

New wine in old bottles?

(i.e., software architecture

global design?,architect designer)

Dr Ljubomir LaziDr Ljubomir Lazi , ,

DocentDocent

Kljent Server Sistemi (Softverske Arhitekture)Kljent Server Sistemi (Softverske Arhitekture) @@ 20072007Doc. Dr Ljubomir Lazi


2/170

Overview

What is it, why bother?

Architecture Design

Viewpoints and view models

Architectural styles

Architecture asssessment

Role of the software architect



3/170

3

The Role of the Architect

client,

users architect developers

appearance,

behaviour

construction,

co-operation

architectural

design

visualises prescribes

requirements solutions

createsassess assess



4/170

4

Pre-architecture life cycle

requirements

agreement

quality

development

stakeholders

(few)



5/170

5

Characteristics

Iteration mainly on functional requirements

Few stakeholders involved

No balancing of functional and quality requirements



6/170


7/170

Architecture in the life cycle

requirements

architecture

quality

agreement

stakeholders

(many)

development



8/170


9/1709

Why Is Architecture Important?

Architecture is the vehicle for stakeholdercommunication

Architecture manifests the earliest set of designdecisions Constraints on implementation

Dictates organizational structure

Inhibits or enable quality attributes

Architecture is a transferable abstraction of a system Product lines share a common architecture

Allows for template-based development

Basis for training



10/17010

Where did it start?

1992: Perry & Wolf

1987: J.A. Zachman; 1989: M. Shaw

1978/79: David parnas, program families

1972 (1969): Edsger Dijkstra, program families

1969: I.P. Sharp @ NATO Software Engineering

conference:

I think we have something in addition to software

engineering [..] This is the subject of softwarearchitecture. Architecture is different from

engineering.



11/17011

Software architecture, definition (1)

The architecture of a software system defines that

system in terms of computational components and

interactions among those components.

(from Shaw and Garlan, Software Architecture,

Perspectives on an Emerging Discipline, Prentice-

Hall, 1996.)



12/17012


statement

procedure

module

(design) pattern

architecture



13/17013

Software Architecture, definition (2)

The software architecture of a system is the

structure or structures of the system, which

comprise software elements, the externally visible

properties of those elements, and the relationshipsamong them.

(from Bass, Clements, and Kazman, Software

Architecture in Practice, SEI Series in SoftwareEngineering. Addison-Wesley, 2003.)



14/17014


Important issues raised in this definition: multiple system structures;

externally visible (observable) properties of components.

The definition does not include: the process;

rules and guidelines;

architectural styles.



15/17015

Architectural Structures

module structure

conceptual, or logical structure

process, or coordination structure

physical structure

uses structure

calls structure

data flow

control flow

class structure



16/17016

Software Architecture, definition (3)

Architecture is the fundamental organization of a

system embodied in its components, their

relationships to each other and to the environmentand the principles guiding its design and evolution

(from IEEE Standard on the Recommended Practice

for Architectural Descriptions, 2000.)



17/17017


Architecture is conceptual.

Architecture is about fundamentalthings.

Architecture exists in some context.



18/17018

Other points of view

Architecture is high-level design

Architecture is overall structure of the system

Architecture is the structure, including the principles

and guidelines governing their design and evolution

over time

Architecture is components and connectors



19/17019

Software Architecture & Quality

The notion of quality is central in software

architecting: a software architecture is devised to

gain insight in the qualities of a system at the

earliest possible stage.

Some qualities are observable via execution:

performance, security, availability, functionality,

usability

And some are not observable via execution:

modifiability, portability, reusability, integrability,

testability Kljent Server Sistemi (Softverske Arhitekture)Kljent Server Sistemi (Softverske Arhitekture) @@ 20072007Doc. Dr Ljubomir Lazi


20/17020

Overview


Architecture Design







21/17021

Attribute-Driven Design (Bass et al, Ch 7)

Choose module to decompose

Refine this module:

choose architectural drivers (quality is driving force) choose pattern that satisfies drivers

apply pattern

Repeat steps



22/17022

Example ADD iterations

Top-level: usability separate user interface Seeheim/three tier architecture

Lower-level, within user interface: security authenticate users

Lower-level, within data layer: availability activeredundancy



23/17023

Generalized model

Understand problem

Solve it

Evaluate solution



24/17024

Global workflow in architecture design

context

requirementsevaluation

results

architecture

backlog

synthesis

evaluation



25/17025

Generalized model (contd)

backlog

sign.reqs

constraints

ideas

assets

architecture

eval results

synthesis

evaluation



26/17026

Design issues, options and decisions

A designer is faced with a series ofdesign issues These are sub-problems of the overall design problem.

Each issue normally has several alternative solutions (or

design options)

The designer makes a design decision to resolve each issue.

This process involves choosing the best option from among

the alternatives.



27/17027

Taking decisions Designproblem

sub-problem(or issue)

sub-problem(or issue)

Designoption

Designoption

Designoption

Designoption

Problemspace

Decisionspace

Alternativesolutions

Alternativesolutions

Decision =best option

Decision =best option



28/170

28

Decision space

The space of possible designs that can be achieved by

choosing different sets of alternatives.

client-server

monolithic

fat-client

thin-client

client in aseparateuser interfacelayer

no separateuser interfacelayer

Programmed in Java

Programmed in Visual Basic

Programmed in C++

clientstyle



29/170

29

Tree or graph?

Issues and options are not independent ...

client-server

monolithic

fat-client

thin-client

client in aseparateuser interfacelayer

no separateuser interfacelayer

clientstyle

flexibility

layered MVC



30/170

30

More than just IT

Technical and non-techical issues and options are

intertwined Architects deciding on the type of database

versus Management deciding on new strategic partnership

or Management deciding on budget



31/170

31

Some (tacit) decisions are related to

norms and values



32/170

32

Types of decisions

Implicit, undocumented Unaware, tacit, of course knowledge

Explicit, undocumented

Vaporizes over time Explicit, explicitly undocumented

Tactical, personal reasons

Explicit, documented

Preferred, exceptional situation



33/170

33

Why is documenting design decisions

important?

Prevents repeating (expensive) past steps

Explains why this is a good architecture

Emphasizes qualities and criticality for

requirements/goals

Provides context and background



34/170

34

Uses of design decisions

Identify key decisions for a stakeholder Make the key decisions quickly available. E.g., introducing new

people and make them up2date.

..., Get a rationale, Validate decisions against reqs

Evaluate impact If we want to change an element, what are the elements

impacted (decisions, design, issues)?

..., Cleanup the architecture, identify important architectural

drivers



35/170

35

Elements of a design decision

Issues: design issues being addressed

Decision

Status: e.g., pending, approvedAssumptions: underlying assumptions

Alternatives

Rationale; the whyof the decision taken

Implications: e.g. need for further decisions



36/170

36

Pointers on design decisions

Hofmeister et al, Generalizing a Model of Software

Architecture Design from Five Industrial Approaches, Journal

of Systems and Software, 2007

Tyree and Ackerman, Architecture decisions: demystifying

architecture, IEEE Software, vol. 22(2), 2005. Kruchten, Lago and van Vliet, Building up and exploiting

architectural knowledge, WICSA, 2005.

Lago and van Vliet, Explicit assumptions enrich architectural

models, ICSE, 2005.



37/170

37

Overview


Architecture Design







38/170

38

Software design in UML

Class diagrams, state diagrams, sequence diagram,etc

Who can read those diagrams?

Which type of questions do they answer?

Do they provide enough information?



39/170

39

Who can read those diagrams?

Designer, programmer, tester, maintainer, etc.

Client?

User?



40/170

Which type of questions do they

answer?

How much will it cost?

How secure will the system be?

Will it perform? How about maintenance cost?

What if requirement A is replaced by requirement B?

Kljent Server Sistemi (Softverske Arhitekture)Kljent Server Sistemi (Softverske Arhitekture) @@ 20072007Doc. Dr Ljubomir Lazi40


41/170

41

Analogy with building architecture

Overall picture of building (client)

Front view (client, beauty committee)

Separate picture for water supply (plumber) Separate picture for electrical wiring (electrician)

etc



42/170

Where We Started: Object-Oriented Programming

Object-oriented (OO) programming simplifiedsoftware development through higher level

abstractions & patterns, e.g.,

Well-written OO programs exhibit recurring structures that

promote abstraction, flexibility, modularity, & elegance

Decoupling interfaces & implementations

Associating related data & operations

operation1()

operation2()

operation3()

operationn()

data

class X


43/170

Next Step: Distributed Object Computing (DOC)

Applies the Broker pattern toabstract away lower-level OS &

protocol-specific details for

network programming

Creates distributed systems

that are easier to model & build

using OO techniques

Result: robust distributed

systems built with distributed

object computing (DOC)middleware

e.g., CORBA, Java RMI, etc.

1 1Proxy

service

Service

service

AbstractService

service

Client

We now have more robust software & more powerful distributed systems

operation()Object :

Interface X: Client

Middleware


44/170

Component-based software

engineering


45/170


46/170

Topics covered

Components and component models

The CBSE process

Component composition


47/170

Component-based development

Component-based software engineering (CBSE) is an

approach to software development that relies on

software reuse.

It emerged from the failure of object-orienteddevelopment to support effective reuse. Single object

classes are too detailed and specific.

Components are more abstract than object classes

and can be considered to be stand-alone service

providers.


48/170

CBSE essentials

Independent components specified by their

interfaces.

Component standards to facilitate component

integration.Middleware that provides support for component

inter-operability.

A development process that is geared to reuse.


49/170

CBSE and design principles

Apart from the benefits of reuse, CBSE is based on

sound software engineering design principles: Components are independent so do not interfere with each

other;

Component implementations are hidden;

Communication is through well-defined interfaces;

Component platforms are shared and reduce development

costs.


50/170

CBSE problems

Component trustworthiness - how can a component

with no available source code be trusted?

Component certification - who will certify the quality of

components?

Emergent property prediction - how can the emergent

properties of component compositions be predicted?

Requirements trade-offs - how do we do trade-off

analysis between the features of one component and

another?


51/170

Components

Components provide a service without regard towhere the component is executing or itsprogramming 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;


52/170


53/170

Component as a service provider

The component is an independent, executable entity.

It does not have to be compiled before it is used with

other components.

The services offered by a component are madeavailable through an interface and all component

interactions take place through that interface.


54/170


55/170

Component characteristics 2

Deployable To be deployable, a component has to be self-contained and

must be able to operate as a stand-alone entity on some

component platform that implements the component model.This usually means that the component is a binary component

that does not have to be compiled before it is deployed.

Documented Components have to be fully documented so that potentialusers of the component can decide whether or not they meet

their needs. The syntax and, ideally, the semantics of allcomponent interfaces have to be specified.


56/170


57/170

Component interfaces

Provides interfaceRequires interface

ComponentDefines the servicesfrom the components

environment that it

uses

Defines the servicesthat are provided

by the component

to other components


58/170


59/170

A data collector component

Provides interfaceRequires interface

Data collector

addSensor

removeSensorstartSensor

stopSensor

testSensor

listAll

report

initialise

sensorManagement

sensorData


60/170

Components and objects

Components are deployable entities.

Components do not define types.

Component implementations are opaque.

Components are language-independent.Components are standardised.


61/170

Component models

A component model is a definition of standards forcomponent implementation, documentation anddeployment.

Examples of component models EJB model (Enterprise Java Beans) COM+ model (.NET model)

Corba Component Model

The component model specifies how interfaces

should be defined and the elements that should beincluded in an interface definition.


62/170


63/170

Middleware support

Component models are the basis for middleware that

provides support for executing components.

Component model implementations provide:

Platform services that allow components written according to

the model to communicate;

Horizontal services that are application-independent services

used by different components.

To use services provided by a model, components are

deployed in a container. This is a set of interfaces usedto access the service implementations.


64/170

Component model services

Platform services

AddressingInterface

definitionComponent

communications

Exception

management

Horizontal services

Security

Transaction

management

Concurrency

Component

management

Persistence

Resource

management


65/170

Component development for reuse

Components are rarely created by simply using part

of the code of another application system

Rather, components for reuse have to be specifically

developed so that they are reusable across a range of

applications


66/170


67/170


68/170


69/170


70/170

Reusable components

The development cost of reusable components may

be higher than the cost of specific equivalents. This

extra reusability enhancement cost should be an

organization rather than a project cost.

Generic components may be less

space-efficient and may have longer execution times

than their specific equivalents.


71/170


72/170

The CBSE process

When reusing components, it is essential to maketrade-offs between ideal requirements and theservices actually provided by available components.

This involves: Developing outline requirements; Searching for components then modifying requirements

according to available functionality.

Searching again to find if there are better components that meetthe revised requirements.


73/170

The CBSE process

Identify candidate

components

Outline

system

requirements

Modify

requirements

according to discovered

components

Identify candidate

components

Architectural

design

Compose

components to

create system


74/170


75/170

Component identification issues

Trust. You need to be able to trust the supplier of a

component. At best, an untrusted component may not

operate as advertised; at worst, it can breach your

security.

Requirements. Different groups of components willsatisfy different requirements.

Validation.

The component specification may not be detailed enough to

allow comprehensive tests to be developed. Components may have unwanted functionality. How can you

test this will not interfere with your application?


76/170


Designing a system by integrating a number of

components.


77/170


The process of assembling components to create a

system.

Composition involves integrating components with

each other and with the component infrastructure.

Normally you have to write glue code to integrate

components.


78/170

Types of composition

Sequential composition where the composed

components are executed in sequence. This involves

composing the provides interfaces of each component.

Hierarchical composition where one component calls

on the services of another. The provides interface ofone component is composed with the requires

interface of another.

Additive composition where the interfaces of two

components are put together to create a newcomponent.


79/170

Types of composition

(a)

A A

B B

A B

(b) (c)


80/170


81/170

Hierarchical composition

In this case, one component (defined in the requires

interface) is called directly from within the body of the

other component.

The calling component must know the name and the

interface signature of the called component.


82/170

Additive composition

In this case, we put two components together so that

the provides interface includes operations that come

from both of the composed components.

Essentially, this is normally implemented by defining

a new small component that offers the combined

interface and which than calls one of the composed

components, depending on the call to the composed

component.


83/170


84/170


85/170


86/170

Adaptor components

Address the problem of component incompatibility byreconciling the interfaces of the components that arecomposed.

Different types of adaptor are required depending on

the type of composition.An addressFinder and a mapper component may be

composed through an adaptor (calledpostCodeStripper) that strips the postal code from anaddress and passes this to the mapper component.


87/170


88/170

Adaptor for data collector

Data collector

addSensor

removeSensorstartSensor

stopSensor

testSensor

listAll

report

initialise

sensorManagement

sensorData

Adaptersensor

start

getdata

stop


89/170


90/170


91/170

Photo library composition

Photo

Library

adaptorImage

Manager

getImage

User

Interface

getCatalogEntry

addItem

retrieve

catEntry


92/170

Photo Library documentation

This method adds a photograph to the library and

associates the photograph identifier and catalogue descriptor

with the photograph.

what happens if the photograph identifier is already

associated with a photograph in the library?

is the photograph descriptor associated with the catalogue

entry as well as the photograph i.e. if I delete the photograph,

do I also delete the catalogue information?


93/170

The Object Constraint Language

The Object Constraint Language (OCL) has been

designed to define constraints that are associated

with UML models.

It is based around the notion of pre and post

condition specification - similar to the approach used

in Z as described in Chapter 10.


94/170

Formal description of photo library


95/170

Photo library conditions

As specified, the OCL associated with the Photo

Library component states that:

There must not be a photograph in the library with the same

identifier as the photograph to be entered;

The library must exist - assume that creating a library adds asingle item to it;

Each new entry increases the size of the library by 1;

If you retrieve using the same identifier then you get back the

photo that you added; If you look up the catalogue using that identifier, then you get

back the catalogue entry that you made.


96/170

Composition trade-offs

When composing components, you may find conflictsbetween functional and non-functional requirements,and conflicts between the need for rapid delivery andsystem evolution.

You need to make decisions such as:

What composition of components is effective for delivering thefunctional requirements?

What composition of components allows for future change?

What will be the emergent properties of the composed system?


97/170

Data collection and report generation

(a) Data

collection

(b)

Data

management

Report

generator

Data

collectionData base

Report

Report


98/170

Composition trade-offs

For composition (a), reporting and data management

are separate so there is more flexibility if changes in

one of these functions but not the other have to be

made.

For composition (b), there are fewer discrete

components so faster communications within the

component offering both data management and

report generation.


99/170

Key points

CBSE is a reuse-based approach to defining and

implementing loosely coupled components into

systems.

A component is a software unit whose functionality

and dependencies are completely defined by itsinterfaces.

A component model defines a set of standards that

component providers and composers should follow.

During the CBSE process, the processes ofrequirements engineering and system design are

interleaved.


100/170

Key points

Component composition is the process of wiring

components together to create a system.

When composing reusable components, you normally

have to write adaptors to reconcile different

component interfaces.

When choosing compositions, you have to consider

required functionality, non-functional requirements

and system evolution.


101/170

Solution: Component MiddlewareCreates a standard

virtual boundaryaround application

component

implementations that

interact only via well-

defined interfaces

Define standard

containermechanisms needed

to execute

components in

generic component

servers

Specify the infrastructur

needed to configure &deploy components

throughout a distributed

system

...GPS-RateGenRefresha_GPSPulsea_RateGenNavDisplay-GPSRefresha_NavDisplayReadya_GPS

...

Container

Birdseye View of Component Middleware


102/170

Components encapsulate application

business logic

Components interact via portsProvided interfaces, e.g.,facetsRequired connection points, e.g.,

receptaclesEvent sinks & sources

AttributesContainers provide execution

environment for components with

common operating requirements

Components/containers can also

Communicate via a middlewarebus &

Reuse common middleware

services

SecurityReplication NotificationPersistence

SchedulingA/V Streaming Load Balancing

Container

Middleware Bus

Container

Component middleware defines interfaces, policies, & some implementations


103/170

Component-based Software: Component

Component

Modular

Encapsulates its contents

Replaceable black box,

conformance defined by interfacecompatibility

Component Interface

Ports consist of provided interfaces (facets) & required (used)

interfaces (receptacles)Attributes

Component Implementation

Monolithic (i.e., executable software) or

Assembly-based (a set of interconnected subcomponents)


104/170

CCM Features Retained in LwCCM Subset All types of ports, i.e.,

Facets

Receptacles

Event sources & sinks

Attributes

Component homes

Generic port management

operations in CCMObject

Monolithic implementations

Session/service component/

container types

Attributes

E

vent

S

inks

Facets

Receptacles

Event

Sourc

es

ComponentReference

ComponentHome

Offered

Ports

Required

Ports

Rece

iv es

From

Sends

To

Container


105/170

Overview of CIAO Component IntegratedACE ORB

Lightweight CCM implementation

atop TAO

Supports component-oriented

paradigm for DRE applications

Provides Real-time CORBApolicies & mechanisms

required for DRE applications

Key DRE aspects are supported

as first-class metadata

First official release (CIAO 0.4) was at

end of December 2003

Latest release is downloadable from

deuce.doc.wustl.edu/Download.html
http://deuce.doc.wustl.edu/Download.htmlhttp://deuce.doc.wustl.edu/Download.html


106/170

106

Architecture presentations in practice

By and large two flavors: Powerpoint slides for managers, users, consultants, etc

UML diagrams, for technicians

A small sample



107/170

107Kljent Server Sistemi (Softverske Arhitekture)Kljent Server Sistemi (Softverske Arhitekture) @@ 20072007Doc. Dr Ljubomir Lazi


108/170



109/170



110/170



111/170



112/170

112

So,

Different representations

For different people

For different purposes

These representations are both descriptive and

prescriptive



113/170

113

IEEE model for architectural

descriptionsMission

SystemEnvironment Architecture

RationaleArchitectureDescription

Concern

LibraryViewpoint

Viewpoint

Stakeholder

Model

View

Mission

SystemEnvironment Architecture

RationaleArchitectureDescription

Concern

LibraryViewpoint

Viewpoint

Stakeholder

Model

View



114/170

114

Some terms (from IEEE standard)

System stakeholder: an individual, team, or

organization (or classes hereof) with interests in, or

concerns relative to, a system.

View: a representation of a whole system from the

perspective of a related set of concerns.

Viewpoint: A viewpoint establishes the purposes and

audience for a view and the techniques or methods

employed in constructing a view.



115/170

115

Stakeholders

Architect

Requirements engineer

Designer (also of other systems)

Implementor

Tester, integrator

Maintainer

Manager

Quality assurance people



116/170

116

Viewpoint specification

Viewpoint name

Stakeholders addressed

Concerns addressed Language, modeling techniques



117/170

117

Kruchtens 4+1 view model

LogicalViewpoint

ImplementationViewpoint

ProcessViewpoint

DeploymentViewpoint

Scenarios

End-userFunctionality

ProgrammersSoftware management

IntegratorsPerformanceScalability

System engineersTopology

Communications



118/170



119/170


Checklist for Architecture Reviews


120/170




121/170




122/170




123/170

123

4 + 1: Logical Viewpoint

The logical viewpoint supports the functional

requirements, i.e., the services the system should

provide to its end users.

Typically, it shows the key abstractions (e.g., classes

and interactions amongst them).



124/170

124

4 + 1: Process Viewpoint

Addresses concurrent aspects at runtime (tasks,

threads, processes and their interactions)

It takes into account some nonfunctional

requirements, such as performance, system

availability, concurrency and distribution, system

integrity, and fault-tolerance.



125/170

125

4 + 1: Deployment Viewpoint

The deployment viewpoint defines how the variouselements identified in the logical, process, andimplementation viewpoints-networks, processes,

tasks, and objects-must be mapped onto the variousnodes.

It takes into account the system's nonfunctionalrequirements such as system availability, reliability

(fault-tolerance), performance (throughput), andscalability.



126/170

126

4 + 1: Implementation Viewpoint

The imlementation viewpoint focuses on the

organization of the actual software modules in the

software-development environment.

The software is packaged in small chunks-program

libraries or subsystems-that can be developed by

one or more developers.



127/170

127

4 + 1: Scenario Viewpoint

The scenario viewpoint consists of a smallsubset of important scenarios (e.g., use cases)to show that the elements of the fourviewpoints work together seamlessly.

This viewpoint is redundant with the otherones (hence the "+1"), but it plays two criticalroles: it acts as a driver to help designers discover architectural elements

during the architecture design;

it validates and illustrates the architecture design, both on paperand as the starting point for the tests of an architectural prototype.


Architectural views from Bass et al


128/170

128

Architectural views from Bass et al

(view = representation of a structure) Module views Module is unit of implementation

Decomposition, uses, layered, class

Component and connector (C & C) views These are runtime elements

Process (communication), concurrency, shared data (repository),

client-server

Allocation views

Relationship between software elements and environment Work assignment, deployment, implementation



129/170

129

Module views

Decomposition: units are related by is a submodule

of, larger modules are composed of smaller ones

Uses: relation is uses (calls, passes information

to, etc). Important for modifiability

Layered is special case of uses, layern can only use

modules from layers


130/170

130

Component and connector views

Process: units are processes, connected by

communication or synchronization

Concurrency: to determine opportunities for

parallelism (connector = logical thread)

Shared data: shows how data is produced and

consumed

Client-server: cooperating clients and servers



131/170

131

Allocation views

Deployment: how software is assigned to hardware

elements

Implementation: how software is mapped onto file

structures

Work assignment: who is doing what



132/170

132

How to decide on which viewpoints

What are the stakeholders and their concerns?

Which viewpoints address these concerns?

Prioritize and possibly combine viewpoints



133/170

133

Decision visualization



134/170

134

Business

viewpoint


A t lit


135/170

135

A caveat on quality

A view can be used to assess one or more quality

attributes

E.g., some type of module view can be used to

assess modifiability

It should then expose the design decisions that

affect this quality attribute


O i


136/170

136

Overview


Architecture Design






A hit t l t l


137/170

137


An architectural style is a description of component

and connector types and a pattern of their runtime

control and/or data transfer.

Examples: main program with subroutines

data abstraction

implicit invocation

pipes and filters repository (blackboard)

layers of abstraction


Al d tt


138/170

138

Alexanders patterns

There is abundance evidence to show that high buildingsmake people crazy.

High buildings have no genuine advantage, except in

speculative gains. They are not cheaper, they do not help to

create open space, they make life difficult for children, they

wreck the open spaces near them. But quite apart from this,

empirical evidence shows that they can actually damage

peoples minds and feelings.

In any urban area, keep the majority of buildings four stories

high or less. It is possible that certain buildings should

exceed this limit, but they should never be buildings for

human habitation.


G l fl f tt


139/170

139

General flavor of a pattern

IF you find yourself in , for example

, with

THEN for some , apply to

construct a solution leading to a and


C t d C t


140/170

140

Components and Connectors

Components are connected by connectors.

They are the building blocks with which anarchitecture can be described.

No standard notation has emerged yet.


T f t


141/170

141

Types of components

computational: does a computation of some sort.

E.g. function, filter.

memory: maintains a collection of persistent data.

E.g. data base, file system, symbol table.

manager: contains state + operations. State is

retained between invocations of operations. E.g. adt,

server.

controller: governs time sequence of events. E.g.

control module, scheduler.


T f t


142/170

142

Types of connectors

procedure call (including RPC)

data flow (e.g. pipes)

implicit invocation

message passing

shared data (e.g. blackboard or shared data base)

instantiation


Framework for describing architectural


143/170

143

Framework for describing architectural

styles

problem: type of problem that the style addresses.

Characteristics of the reqss guide the designer in

his choice for a particular style.

context: characteristics of the environment thatconstrain the designer, reqs imposed by the style.

solution: in terms ofcomponents and connectors

(choice not independent), and control structure (order

of execution of components) variants

examples


Main program with subroutines style


144/170

144

Main-program-with-subroutines style

problem: hierarchy of functions; result of functional

decomposition, single thread of control

context: language with nested procedures

solution: system model: modules in a hierarchy, may be weak or strong,

coupling/cohesion arguments

components: modules with local data, as well as global data

connectors: procedure call

control structure: single thread, centralized control: main program pullsthe strings

variants: OO versus non-OO


Abstract data type style


145/170

145

Abstract-data-type style

problem: identify and protect related bodies of information. Data

representations likely to change.

context: OO-methods which guide the design, OO-languages

which provide the class-concept

solution:

system model: component has its own local data (= secret it hides)

components: managers (servers, objects, adts)

connectors: procedure call (message)

control structure: single thread, usually; control is decentralizedvariants: caused by language facilities


Implicit invocation style


146/170

146

Implicit-invocation style

problem: loosely coupled collection of components. Useful

for applications which must be reconfigurable.

context: requires event handler, through OS or language.

solution: system model: independent, reactive processes, invoked when an

event is raised

components: processes that signal events and react to events

connectors: automatic invocation

control structure: decentralized control. Components do not know whois going to react.

variants: Tool-integration frameworks, and languages with

special features.


Pipes and filters style


147/170

147

Pipes-and-filters style

problem: independent, sequential transformations on ordereddata. Usually incremental, Ascii pipes.

context: series of incremental transformations. OS-functionstransfer data between processes. Error-handling difficult.

solution: system model: continuous data flow; components incrementally

transform data components: filters for local processing connectors: data streams (usually plain ASCII) control structure: data flow between components; component has own

flow

variants: From pure filters with little internal state to batchprocesses


Repository style


148/170

148

Repository style

problem: manage richly structured information, to be

manipulated in many different ways. Data is long-lived.context: shared data to be acted upon by multiple clients

solution:

system model: centralized body of information. Independent

computational elements.

components: one memory, many computational

connectors: direct access or procedure call

control structure: varies, may depend on input or state of

computation

variants: traditional data base systems, compilers, blackboard

Shared Data

Client

Client

Client

Layered style


149/170

149

Layered style

problem: distinct, hierarchical classes of services.

Concentric circles of functionality

context: a large system that requires decomposition (e.g.,

virtual machines, OSI model)

solution:

system model: hierarchy of layers, often limited visibility

components: collections of procedures (module)

connectors: (limited) procedure calls

control structure: single or multiple threads

variants: relaxed layering

Layern

Layer2

Layer1


Model-View-Controller (MVC) style


150/170

150

Model View Controller (MVC) style

problem: separation of UI from application is desirable due to

expected UI adaptations

context: interactive applications with a flexible UI

solution:

system model: UI (View and Controller Component(s)) is decoupled

from the application (Model component)

components: collections of procedures (module)

connectors: procedure calls

control structure: single thread

variants: Document-View

Model

ViewControllernn


Overview


151/170

151

Overview


Architecture Design






Architecture evaluation/analysis


152/170

152

Architecture evaluation/analysis

Assess whether architecture meets certain qualitygoals, such as those w.r.t. maintainability,modifiability, reliability, performance

Mind: the architecture is assessed, while we hopethe results will hold for a system yet to be built


Software Architecture Analysis


153/170

153

Software Architecture Analysis

Software

architectureSystem

Properties Qualities

implementation

properties


Analysis techniques


154/170

154

Analysis techniques

Questioning techniques: how does the system reactto various situations; often make use of scenarios

Measuring techniques: rely on quantitative

measures; architecture metrics, simulation, etc



155/170

Preconditions for successful


156/170

156

Preconditions for successful

assessment Clear goals and requirements for the architecture

Controlled scope

Cost-effectiveness

Key personnel availability

Competent evaluation team

Managed expectations

Kljent Server Sistemi (Softverske Arhitekture)Kljent Server Sistemi (Softverske Arhitekture)

@@

20072007Doc. Dr Ljubomir Lazi


157/170

Benefits


158/170

158

Benefits

Financial gains

Forced preparation

Captured rationale

Early detection of problems

Validation of requirements

Improved architecture

Kljent Server Sistemi (Softverske Arhitekture)Kljent Server Sistemi (Softverske Arhitekture)

@@

20072007Doc. Dr Ljubomir Lazi

Participants in ATAM


159/170

159

Participants in ATAM

Evaluation team

Decision makers

Architecture stakeholders


Phases in ATAM


160/170

160

Phases in ATAM

0: partnership, preparation (informally)

1: evaluation (evaluation team + decision makers, one

day)

2: evaluation (evaluation team + decision makers +

stakeholders, two days)

3: follow up (evaluation team + client)


Steps in ATAM (phase 1 and 2)


161/170

161

Steps in ATAM (phase 1 and 2)

Present method Present business drivers (by project manager of system)

Present architecture (by lead architect)

Identify architectural approaches/styles

Generate quality attribute utility tree (+ priority, and how

difficult) Analyze architectural approaches

Brainstorm and prioritize scenarios

Analyze architectural approaches

Present results


Example Utility tree


162/170

162

Example Utility tree

Utility

Performance

Usability

Maintainability

Transaction response time (H, M)

Throughput

Training

150 transactions/sec

Database vendor releases

new version

Normal operations


Outputs of ATAM


163/170

163

Outputs of ATAM

Concise presentation of the architecture Articulation of business goals

Quality requirements expressed as set of scenarios

Mapping of architectural decisions to quality

requirements Set of sensitivity points and tradeoff points

Set of risks, nonrisks, risk themes


Important concepts in ATAM


164/170

164

Important concepts in ATAM

Sensitivity point: decision/property critical forcertain quality attribute

Tradeoff point: decision/property that affects more

than one quality attribute

Risk: decision/property that is a potential problem

These concepts are overlapping


Software Architecture Analysis Method


165/170

165

Software Architecture Analysis Method

(SAAM) Develop scenarios for

kinds of activities the system must support

kinds of changes anticipated

Describe architecture(s) Classify scenarios

direct -- use requires no change

indirect -- use requires change

Evaluate indirect scenarios: changes and cost

Reveal scenario interaction

Overall evaluation


Scenario interaction in SAAM


166/170

166

Scenario interaction in SAAM

Two (indirect) scenarios interact if they requirechanges to the same component

Scenario interaction is important for two reasons: Exposes allocation of functionality to the design

Architecture might not be at right level of detail


Overview


167/170

167

Overview

What is it, why bother? Architecture Design








168/170

168

o e o t e so t a e a c tect

Key technical consultant Make decisions

Coach of development team

Coordinate design

Implement key parts

Advocate software architecture


Summary


169/170

169

y

new and immature field proliferation of terms: architecture - design pattern -

framework - idiom

architectural styles and design pattern describe

(how are things done) as well asprescribe (howshould things be done)

stakeholder communication

earlyevaluation of a design

transferable abstraction


Further reading


170/170

g

Mary Shaw and David Garlan, Software Architecture;Perspectives of an Emerging Discipline, 1995.

Philippe B. Kruchten, The 4+1 view model of architecture,

IEEE Software, 12(6):42-50, November 1995.

Frank Buschmann et al., Pattern-Oriented Software

Architecture: A System of Patterns, 1996. Part II: 2001.

Erich Gamma et al., Design Patterns: Elements of Reusable

Object-Oriented Software, 1995.

Len Bass et al, Sofware Architecture in Practice, 2003 (2nd

edition).

C. Hofmeister et al., Applied Software Architecture, 1999.

Documents

Doradjen Pregled Kursa i Tipovi Arhitektura 100 Slajdova