1

Advanced Software EngineeringURL: http://lore.com/Advanced-Software-Engineering-Univaq/

DISIMDep.nt of Information Engineering, Computer Science and MathematicsUniversity of L’Aquila, Italy

SA Styles, Patterns, and Tactics

Henry Muccini DISIM, University of L’Aquila henry.muccini@univaq.it,

@muccinihenry

SEA Group

Copyright Notice

The material in these slides may be freely reproduced and distributed, partially or totally, as far as an explicit reference or acknowledge to the material author is preserved.

Henry Muccini

SEA Group

A brief summary

SEA Group

SA STYLES

SEA Group

Prescriptive vs descriptive

Prescriptive vs descriptive use of an architectural language

Descriptive = unconstraintPrescriptive = constraint

SEA Group

Architectural Styles

“A set of design rules that identify the kinds of components and connectors that may be used to compose a system or subsystem, together with local or global constraints on the way the composition is done” (Shaw & Clements, 1996)

A set of constraints you put on your development to elicit desirable properties from your software architecture.

Constraints may be:TopologicalBehavioralCommunication-orientedetc. etc.

IMP

SEA Group

Architectural Style properties

Architectural styles typically determine four kinds of properties [AAG93]:1. They provide a vocabulary of design elements – component and connector

types such as pipes, filters, clients, servers, parsers, databases etc.2. They define a set of configuration rules – or topological constraints – that

determine the permitted compositions of those elements. 3. They define a semantic interpretation, whereby compositions of design

elements, suitably constrained by the configuration rules, have well-defined meanings.

4. They define analyses that can be performed on systems built in that style. Examples include schedulability analysis for a style oriented toward real-time processing [Ves94] and deadlock detection for client-server message passing [JC94].

IMP

SEA Group

The Classical Style

The Gothic Style

The Californian Style

SEA Group

Architectural Styles vs. Design Patterns

Many similarities between patterns and stylesGoal: packaged engineering experienceFormulation: organization and interaction among “key” components

But they have come from different communitiesMany architectural styles have been well known for a long time in the

software engineering communityPatterns are a relatively recent development in OO design

Differences

Architectural Styles Design Patterns

Few Many

Large-scale system organization

Localized, small-scale design solutions

SEA Group

The C2 style Composition Rules

1. The top of a component may be connected to the bottom of a single connector.

2. The bottom of a component may be connected to the top of a single connector.

3. There is no bound on the number of components or connectors that may be attached to a single connector.

4. When two connectors are attached to each other, it must be from the bottom of one to the top of the other.

5. Components can communicate only through connectors

SEA Group

The C2 style Communication Rules

The communication between components and connectors is achieved solely exchanging messagesThe communication is based on notifications and requestsBoth component top domain and bottom domain can notify or request messages

Comp1

Comp2

Top

Top

Bottom

Bottom Comp1 receives a request

Comp1 sends a request

Comp2 receives a request Comp2 sends a notification

Comp1 receives a notification

Comp1 sends a notification

Requests Notifications

SEA Group

Example: Elevator System in the C2 style

ElevatorADT1

ElevatorPanel1

Scheduler

BuildingPanel

ElevatorADT2

ElevatorPanel2

ElevatorSynchronizer

ElevatorADT1

ElevatorPanel1

Scheduler

BuildingPanel

ElevatorADT2

ElevatorPanel2

ElevatorSynchronizer

C2 connector

C2 component

request

notification

comm. channel

SEA Group

MORE ABOUT THE C2 STYLE

SEA Group

The C2 style Composition Rule 1

1. The top of a component may be connected to the bottom of

a single connector.

Comp1 NOT Permitted

Comp1

Connector Bottom

Connector Top

SEA Group

The C2 style Composition Rule 2

2. The bottom of a component may be connected to the top of a single connector.

Comp1

NOT PermittedComp1

Connector Bottom

Connector Top

SEA Group

The C2 style Composition Rule 3

3. There is no bound on the number of components or connectors that may be attached to a single connector.

Comp1 Comp2 Comp3

Permitted

SEA Group

The C2 style Composition Rule 4

4. When two connectors are attached to each other, it must be from the bottom of one to the top of the other.

Connector Bottom

Connector Top

Connector Bottom

Connector Top

Connector Bottom

Connector Top

Permitted

Connector Bottom

Connector Top

Connector Bottom

Connector Top

NOT Permitted

SEA Group

The C2 style Composition Rule 5

5. Components can communicate only through connectors

Comp1

Comp2

NOT PermittedPermitted:

Following rule 4

SEA Group

ADL and stylesADL TOOLS DATE SUPPORT FOR ARCHITECTURAL STYLES

AADL Osate 2001

Descrizione di proprietà ed interfacce relative a componenti

+

configurazioni di intercambio XML/XMI

ACME Acme Studio+Armani

1995 Interscambio architetturale prevalentemente a livello strutturale

ArchiTrio Trident 1990 Unisce lo stile delle notazioni standard UML 2.0 ai formalismi logico-temporali di TRIO

ArchJava AcmeArchJava 2002 Supporta uno stile di programmazione flessibile orientato agli oggetti

CommUnity

CommUnity WorkBench

2002 Linguaggio che si rispecchia negli stili UNITY ed IP

DARWIN LTSA-WS + SAA 1991 Architetture di sistemi distribuiti il cui dinamismo è guidato da un supporto severo e formale

EAST-ADL AutoFocus22001/200

4 La descrizione degli elementi del linguaggio è suddivisa in sei parti (domini)

Ménage/xADL

ArchStudio+Ménage 2000 Introduce la distinzione tra prescription e description della SA

PRISMA PrismaCase 2002 Definizione di elementi architetturali a due diversi livelli di astrazione

xArch/xAcme Acme Studio 2001

Versione recente del linguaggio Acme che ne mantiene le caratteristiche di base, specificate però in XML

xArch/xADL ArchStudio+Apigen 2000 Introduce la distinzione tra prescription e description della SA

SEA Group

SOME OF THE MOST KNOWN STYLES

SEA Group

Common Software Architectural Styles (Shaw & Garlan 96) + SA In

PracticeC2 StylePipes and filtersLayered systemsBlackboard styleImplicit InvocationIdealized FT Component ModelPeer to peer

Client ServerThree tierThird Generation Peer to peer

Hypertext style (!)MVCRUP

SEA Group

Styles by Example

For each style, we will identify:ComponentsConnectors

and

AdvantagesDisadvantages

SEA Group

Layered Style (Virtual Machine Example)

Java Virtual Machine

Processor

Operating

System

Java

Virtual Machine

Java

Application

(Virtual Machine Style)

SEA Group

The Layered System Style

A layered system is organized hierarchically, each layer providing service to the layer above and below

ComponentsPrograms or subprograms deployed in a layer

ConnectorsProtocols

Procedure calls or system calls

Stylistic invariantsEach layer provides a service only to the immediate layer “above” (at the

next higher level of abstraction) and uses the service only of the immediate layer “below” (at the next lower level of abstraction)

SEA Group

Layered System Example: OSI Protocol Stack

Application

Presentation

Session

Transport

Network

Data Link

Physical

Application

Presentation

Session

Transport

Network

Data Link

Physical

Network

Data Link

Physical

Network

Data Link

Physical

SEA Group

POPEYE Project

SEA Group

Layered System Advantages and Disadvantages

AdvantagesDecomposability: Effective separation of concerns and different level of

abstractionsMaintainability: Changes that do not affect layer interfaces are easy to makeAdaptability/Portability: Can replace inner layers as long as interfaces remain

the same Understandability: Strict set of dependencies allow you to ignore outer layers

DisadvantagesNot all systems are easily structured in a layered fashionPerformance degrades with too many layersCan be difficult to cleanly assign functionality to the “right” layer

SEA Group

Example

1..11..1

1..11..1

1..1

1..1

1..1

1..11..11..1

1..11..1

1..21..1

1..21..1

XCONN1

XCONN

…

GLOBAL

SHELF

PERIPHERAL

XCONN2

XCONN3

1..11..1

1..11..1

1..1

1..1

1..1

1..11..11..1

1..11..1

1..21..1

1..21..1

XCONN1

XCONN

…

XCONN2

XCONN3

SEA Group

The Blackboard Style

Blackboad style

1..*

Blackboard1..*

KS

Controller

SEA Group

The Blackboard Style

This style is characterized by a central data structure and a collection of components operating on the central data store

The Blackboard is characterized by three main types of components (Corkill, 1991):

the knowledge sources (KS), which are independent modules that contain the knowledge needed to solve the problem,

the blackboard, which is a global repository containing input data and partial solutions, and

the controller, which is responsible for managing the course of problem solving (e.g. coordinating the different KS).

ConnectorBlackboard: shared data repository, possibly with finite capacityPropertydifferent KSs may not communicate directly

SEA Group

Blackboard Advantages and Disadvantages

AdvantagesSimplicity: Only one connector (the blackboard) that

everyone usesEvolvability: New types of components can be added easily

DisadvantagesBlackboard becomes a bottleneck with too many clients

SEA Group

Example: Facebook, GoogleDocs, …

SEA Group

Distributed Peer-to-Peer Systems

ComponentsIndependently developed objects and programs offering public operations or

services

ConnectorsRemote procedure call (RPC) over computer networks

ConfigurationsTransient or persistent connections between cooperating components

Computational modelSynchronous or asynchronous invocation of operations or services

SEA Group

Client/Server Style (Example: The World Wide Web)

HTTP(asynchronous RPC)

www.website.com

NetscapeNavigator

MicrosoftIE

Browser Clients

WebServers

• Load balancing • Cooperative caching• Use of geographic distribution of the server machines.

www.sitoweb.it

www.laudaweb.it

SEA Group

Client/Server Systems

Client/Server systems are the most common specialization (restriction) of the peer-to-peer style

One component is a server offering a service

The other components are clients using the service

Server implementation is transparent but can be centralized or distributed, single-threaded or multi-threaded

Single interface point with physically distributed implementationDynamic, transparent selection from among multiple interface points

SEA Group

3-Tier Client/Server Systems (example)

SEA Group

3-Tier Client/Server Systems

3-Tier Client/Server systems are a common class of distributed business systems

Increasing competition requires business to find new ways of exploiting legacy information assets

First tier: Client (user interface) tierPresentation logic

Second (middle, “business logic”) tier: Servers acting as “business objects”, encapsulating abstract, integrated models of multiple, disparate data sources

Computation

Third (back-end, database) tier: Legacy business applications providing data services

Database

SEA Group

WHAT IS P2P?

There are 3 types of P2P System:

1st: Napster

SEA Group

WHAT IS P2P?

2nd: Gnutella

SEA Group

Gnutella P2P (from the SAInPractice book)

SEA Group

WHAT IS P2P?

3rd: SKYPE

SEA Group

Peer-to-Peer Advantages and Disadvantages

AdvantagesInteroperability A natural high-level architectural style for heterogeneous

distributed systemsReusability: Especially with regard to legacy applicationsScalability: Powerful enough server tiers can accommodate many clientsDistributability: Components communicate over a network, generally

DisadvantagesVisibility, Maintainability: Difficult to analyze and debug

Distributed statePotential for deadlock, starvation, race conditions, service outages

Simplicity: Require sophisticated interoperability mechanismsData marshalling and unmarshallingProxies and stubs for RPCLegacy wrappers

SEA Group

SOA Style

image from Google Images

SEA Group

Normal Processing

Idealized FT Component Model

Error Processing

Local Exception

Return to normal

Service Request

Service Request Reply

Reply

Interface Exception Failure Exception

Failure ExceptionInterface Exception

Program unit (object, process, block, module, method, class, component, etc.)

SEA Group

Idealized FT Component Model

• The normal part implements the component’s normal services • The exceptional part implements the responses of the

component to exceptional situations, by means of exception-handling techniques.

• When the normal behavior of a component raises an exception (local exception) its exception handling part is automatically invoked. If the exception is successfully handled the component resumes its normal behavior, otherwise an external exception is signalled.

• External exceptions are signalled to the enclosing context when the component realizes that is not able to provide the service.

SEA Group

Idealized FT Component Model

Example

SEA Group

Model View Controller

MVC:Model: data and business logicView: content Controller: applications coordinator

Input --> Processing --> OutputController --> Model --> View

SEA Group

Model, View and Controller

Model The model represents enterprise data and the business rules that govern access to and updates of this

data.This is the domain-specific representation of the information on which the application operates. It maps requests coming from clients into operations over the model

View The view renders the contents of a model. It accesses enterprise data through the model and specifies

how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. MVC is often seen in web applications, where the view is the HTML page and the code which gathers

dynamic data for the page.

Controller The controller translates interactions with the view into actions to be performed by the model.This responds to events, typically user actions, and invokes changes on the model and perhaps the view. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web

application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

SEA Group

MVCFig 13.7, SA in Practice book

1..*

1

1..*

SEA Group

System usage scenario There is some smoke on the first apartment in the 4th floor, on Avenue de Fortune 26. A smoke sensor detects the smoke, potential source of a fire, and informs a local server. The local server posts the information on-line, and this information is accessible from the fire station. The fire station has a view on all the alarms and warnings happening at the all time. The system monitors the status of alarms and informs the fire fighters about the entity of the fire, the time it started, the area covered by it, and other sensitive information. Based on such information, the system decides where to send the fire trucks (in case only a limited set of fires can be managed in parallel). The fire fighters jump into the fire truck, turn in their onboard computing system, and get information about the fastest way to get to destination. During the trip, they get all possible updates about the state of the fire. Based on this information, they may decide that a second truck is needed, or one is closer to Avenue de Fortune, or that their service is not needed anymore. When the fire fighters arrive to Avenue de Fortune 26, the entire 4th floor is on fire. By using other sensors, they may know how many people is trapped inside the building: this information is displayed on their devices. Fortunately, nobody is inside the building at this time. Before starting extinguishing the fire, the system discovers that there are some gas cylinders on the 6th floor. They first start securing those devices, and in parallel extinguishing the fire on the 4th floor.

SEA Group

Styles by Example

SEA Group

Tactics

Patterns are constructed from different tactics

A tactic promotes a specific quality attribute

Tactics can be used to enhance existing patterns

SEA Group

What you shall have learned

You shall:Know at least those styles discussed during this lecture

Layered systemsBlackboard stylePeer to peer…

Be able to apply the style to your architectural designBe able to understand pros and cons of styles

SEA Group

Readings

Software Architecture in Practice, chapter 13

[SC97] A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems, M. Shaw and P. Clements, In Proc. COMPSAC97, 21st Int'l Computer Software and Applications Conference, August 1997, pp. 6-13.