Università degli Studi dell’Aquila

1

Software Architecture: styles, families, and research

Henry Muccini DISIM, University of L’Aquila

henry.muccini@univaq.it, @muccinihenry, henrymuccini.com

@Gran Sasso Science Instutitue (GSSI) – Nov. 2013

The Software Architecture is the earliest model of the whole software system created along the software lifecycle

A set of components and connectors communicating through interfacesA set of architecture design decisionsFocus on set of views and viewpointsWritten according to architectural styles

Soft

war

e A

rchi

tect

ure

Prescriptive vs descriptive

Prescriptive vs descriptive use of an architectural language

Descriptive = unconstraintPrescriptive = constraint

The Classical Style

The Gothic Style

The Californian Style

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

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

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

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

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

Let us take a look to some Architectural Styles…

10

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

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

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

The Blackboard Style

Blackboad style

1..*

Blackboard1..*

KS

Controller

The Blackboard StyleThis 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 capacity

Propertydifferent KSs may not communicate directly

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

Example: Facebook, GoogleDocs, …

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

3-Tier Client/Server Systems (example)

WHAT IS P2P?

3rd: SKYPE

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

Some References

[Garlan94] Exploiting Style in Architectural Design Environments, David Garlan, Robert Allen and John Ockerbloom. Proceedings of SIGSOFT '94 Symposium on the Foundations of Software Engineering, December 1994. [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.[Shaw96] Some Patterns for Software Architectures, M. Shaw, In John Viissides, James O. Coplien, and Norman L. Kerth, editors,

Pattern Languages of Program Design 2. Addison-Wesley, 1996.

22

The Software Architecture is the earliest model of the whole software system created along the software lifecycle

A brief Introduction to Product Lines (i.e., families of products)

Soft

war

e A

rchi

tect

ure

Product Lines and Product Families

Product Line:→ This term was introduced by the US community

Product Family:→ This term originated within a series of European

industrial-cooperation projects

Product LineDefinition:A software product line is a set of software intensivesystems sharing a common, managed set of features thatsatisfy the specific needs of a particular market segment or mission and that are developed from a common set ofcore assets in a prescribed way.

[P. Clements - L. M. Northrop, 2001]

(Software Engineering Institute, CMU)

The general idea…

The idea behind a system-family approach is to:

→ build a new system or application from a common set of assets…

─ A software asset might be a component, known requirements or design elements, models, artifacts that an engineer uses to build or modify a software product…

→ in the same line (i.e., domain)…─ pertaining to a general production line of a company

An example27

An example

• Car product line

Keywords > 1/3Variability:

→ Variability is the ability to change or customize a software system [Jan Bosch, 2002]

Variation point:→ A variation point refers to a delayed design decision, i.e., it

indicates a specific point in the development or deployment phase of a software system

→ The intention of designing a variation point into a system is to insert a variant (alternative) at a later phase in the lifecycle

Keywords > 2/3

Features: → Underlying def: a feature groups related requirements→ Features are an abstraction mechanism to express variability→ Cross-cutting features→ FODA: Feature Oriented Domain Analysis

Keywords > 3/3Levels:

→ Domain→ Application

Why Product Lines?

Feature Model33

Product Lines and Reuse

SPLC Conference35

The Software Architecture is the earliest model of the whole software system created along the software lifecycle

Our current research on Architecture Description Languages and Frameworks

Soft

war

e A

rchi

tect

ure

37

My

Rese

arch

ADL (according to ISO/IEC/IEEE 42010)

ADL = Architecture Description Language = any mode of expression used in an architecture description

38

Informal FormalUML-based

FormalPro: formal semantics computable

Cons: difficult to learn general lack of tools prolifetarion

UML-basedPro: not too difficult same notation for SA and design modeling

Cons: not a 100% fit tool investment

Informal Pro: of immediate use perfect for sketching communicative

Cons: ambiguous non automated

39

Main Finding: Introvert versus extrovert nature of architects role ADLs should combine features supporting both communication and

disciplined development.

But.. What Industry needs from Architectural Languages?I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, A. Tang. IEEE TSE 2012 (pre-print)

But, what industry needs from ALs?

41

Industrial needs on ALs

Medvidovic et al. [12]

Woods and Hilliard [17]

Woods [18]

Pandey [19]

Hilliard and Rice [20]

Clements [21]

42

The study population

Participants = 48─ 25 interviews─ 23 on-line questionnaires

Localization: 15 countries→ USA (9), Sweden (6), Germany (5), Netherlands (5), Canada (4), Australia

(4), France (4), Argentina (2), UK (2), Austria (1), Belgium (1), Chile (1), Croatia (1), India (1), Switzerland (1), unknown (1)

Number of employees

18%

34%23%

25%A(0-99)

B(100-999)

C(1000-4999)

D(5000-above)

usefulness of ADL features in past and future projects

Challenges and Opportunities in ALs

C1: need of models interoperability multiple languages are used to describe the architecture of a

software system

C2: need of extending existing ALs

C3: need of creating, storing, re-using, views and Architecture Frameworks

C4: need of communicative and analytic AL

47

Our solutions

S1. DUALLY (dually.di.univaq.it)→An MDE interoperability framework for existing ADLs [TSE2010,SOSYM2012]

S2.ByADL (byadl.di.univaq.it)→An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010]

S3.MEGAF (megaf.di.univaq.it)→A repository and a framework for creating your architecture description based on different viewpoints/views/concerns [ASE2010, WICSA/ECSA2012]

S4.WIKI & AL

48 DUALLY supports interoperability among ADLs. One model written in an ADL, can be then automatically transformed into another model conforming to a different ADL. Moreover, if a change is applied to one model in the transformation network, it is propagated to all the models.

C1. Need of models interoperability

•Use of different ALs to model or analyze different architectural aspects of a system

• Ongoing work we surveyed more than 120 Architecture Description Languages

49

Bridging the different descriptions to be kept consistent and coherent is of paramount relevance

DUALLY Motivating Example

Performance Model PM

Security Model

System

Performance analysis

Security analysis

?

?

Tech Foundation: Model Transformations and Weaving

Model 2 Model From design to analysis models From one view to another

Model 2 Code: Executable code Simulation code

53

Transformation

ADLa

ADLb

How to relate the notations?

1)Full-mesh topology:

n notations n (n-1)/2 weaving models

2)Star topology:

n notations n weav. modelsConsistency of models may be

verified in A0

Darwin/LTSA

ACME

AADL

SA UMLprofiles

OtherADLs

A0 Profile

Darwin/LTSA

ACME

AADLSA UMLprofiles

OtherADLs

Our solutions

S1. DUALLY (dually.di.univaq.it)→An MDE interoperability framework for existing ADLs [TSE2010,SOSYM2012]

S2. ByADL (byadl.di.univaq.it)→An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010]

MEGAF (megaf.di.univaq.it)→A repository and a framework for creating your architecture description based on different viewpoints/views/concerns [ASE2010, WICSA/ECSA2012]

→S4.WIKI & AL

ByADL is Eclipse-based solution for extending and customizing architecture description languages (or, more in general, domain specific modeling languages) to adapt an ADL to better fit stakeholders’ concerns.

Extending ALs

ByADL (byadl.di.univaq.it)→An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010]

current ADLs mostly fail to capture multiple (and varying) stakeholders concerns

extending and customizing existing ADLs w.r.t. to domain- & organization- specific concerns

PROBLEM

SOLUTION

Tech Foundation: Metamodel Composition59

Metamodels (and models) can be “composed” so to generate a new metamodel (model)

MMMMext

composition model

MMcomp

transformations

Our solutions

S1.DUALLY (dually.di.univaq.it)→An MDE interoperability framework for existing ADLs [TSE2010,SOSYM2012]

S2.ByADL (byadl.di.univaq.it)→An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010]

S3.MEGAF (megaf.di.univaq.it)→A repository and a framework for creating your architecture description based on different viewpoints/views/concerns [ASE2010, WICSA/ECSA2012]

S4.WIKI & AL

MEGAF allows software architects to create new and re-usable architecture frameworks

Goal of this work

MEGAF is an MDE approach to create new architecture frameworks by means of mechanisms:i. to store, retrieve, and combine existing viewpoints, by properly

selecting and reusing models previously defined and resident in MEGAF;

ii. to define correspondences among views, viewpoints, stakeholders, system concerns and their elements;

iii. to enforce consistency and completeness checks based on defined architectural relationships and rules among elements.

To provide an infrastructure that enables to build reusable architecture frameworks

by treating views, viewpoints, concerns as first-class entities.

Tech. Foundation: Megamodeling

A megamodel is a kind of model in which elements could represent and/or refer to models or metamodels [Bézivin et al., OOPSLA/GPCE 2004]

A megamodel specifies properties and rules governing model construction, including multiple models and metamodels

→Models and metamodels are first-class entities→It offers also the possibility to specify relationships between them and to navigate them.

A megamodel can be seen as a map to find and link together all the involved models

Our solution

Darwin/FSP

ACME

AADL

xADL

SA UML profiles

other ADLs

pivotmetamodel

(A0)

Extended/customized ADL generated in byADL

BPMN

FTVP1

VP2St1

MK1

Composed AF generated in MEGAF

MEGAF: a model-driven infrastructure for building reusable and extensible architecture frameworks

DUALLy: an automated approach for ADLs interoperability

byADL: an approach to adapt and customize existing ADLs

Tool Support

MEGAFDUALLy

EMF

AM3 AMW ATL

AMMA

byADL other engines

MEGAF

megaf.di.univaq.it•Preliminary prototype in Eclipse, using megamodeling techniques

dually.di.univaq.it•Prototype in Eclipse, using model-driven engineering techniques

byadl.di.univaq.it•Prototype in Eclipse, using model-driven engineering techniques

Automation