Introduction to ARCHITECTURAL LANGUAGES

Ivano Malavolta

ARCHITECTURAL

LANGUAGES

Roadmap

Architectural languages

Multi-views architecting

Open research challenges

Some contents of this part of lecture extracted from Henry Muccini’s lecture on architectural languages at the University of L’Aquila (Italy)

Architectural languages

Historical View

25+ years back

I have to share with architects the architecture

solution I have in mind.

What shall I use?

software architect

Historical View

But architecting makes sense if we can run some automated analysis (and more)! academia

“Aside from providing clear and precise documentation, the primary purpose of specifications is to provide automated analysis of the document and to expose various kinds of problems that would otherwise go undetected” (PW1992)

“Fourth, an architectural system representation is often essential to the analysis and description of the highl-level properties of a complex system” (GS1994)

Historical View

core concerns

Comp&Con Spec

Interconnectio

n

Composition

Abstraction

Reusability

Configuration

Heterogeneity

Analysis

Components and connectors Distribution and configuration Expected behaviour Patterns, styles HW/SW Deployment

1st generation ALs

Darwin FSP

ACME

Rapide Wright

ACME

1st generation ALs Support components and connectors specification, their overall interconnection, composition, abstraction, reusability, configuration, heterogeneity, and analysis.

Examples of 1st generation ALs

Nenad Medvidovic, Eric M. Dashofy, Richard N. Taylor: Moving architectural description from under the technology lamppost. Information & Software Technology 49(1): 12-31 (2007)

Basic example: C2

Designed for systems that have a GUI •  component-based

–  written in any programming language –  easily reused and substituted

•  scalability –  no assumption about how components communicate –  components may be running in a distributed, heterogeneous

environment

•  flexibility –  architectures may be changed dynamically

The C2 communication rules •  The communication between components and

connectors is achieved solely exchanging messages •  The communication is based on notifications and

requests •  Both 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

The C2 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

The C2 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

Permitted


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

Comp1

NOT Permitted Comp1

Connector Bottom

Connector Top

Permitted


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

Comp1 Comp2 Comp3

Permitted

The C2composition 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


5.  Components can communicate only through connectors

Comp1

Comp2

NOT Permitted Permitted:

Following rule 4

Example: elevator system

ElevatorADT1

ElevatorPanel1

Scheduler

BuildingPanel

ElevatorADT2

ElevatorPanel2

ElevatorSynchronizer

ElevatorADT1

ElevatorPanel1

Scheduler

BuildingPanel

ElevatorADT2

ElevatorPanel2

ElevatorSynchronizer

C2 connector

C2 component

request

notification

comm. channel

Issues of 1st generation ALs

•  Focus exclusively on technology •  The broader context was completely missing

–  Relation to system requirements –  Constraints imposed by implementation platforms –  Characteristics of application domains –  Organizational structure and politics

•  Often targeted at research environments –  Awkward syntax and/or semantics –  Modeling rigidity

•  Limited and idiosyncratic analysis support •  Inadequate tool support •  UML

–  Video killed the radio star...

Historical View

core concerns

Config. manage

ment

Distribution

Product lines

Styles Different domains

…

…

2nd generation ALs

UML 2.0 AADL

Koala xADL 2.0

ACME

2nd generation Als Modeling support for: configuration management, distribution, and product lines. Structural specifications integrated with behavior with the introduction of many formalisms such as pre- and post-conditions, process algebras, statecharts, POSets, CSP, π-calculus

Examples of 2nd generation ALs

Nenad Medvidovic, Eric M. Dashofy, Richard N. Taylor: Moving architectural description from under the technology lamppost. Information & Software Technology 49(1): 12-31 (2007)

•  UML 2.0 ß UML 1.x •  AADL ß MetaH

–  we will have a dedicated lecture about it

•  Koala ß Darwin ß Conic

UML 2.0

•  De facto standard software design language –  Developed by OMG

•  A “Swiss Army Knife” of notations •  Has a number of architectural constructs

UML 2.0

Reasonably applicable to software architectures…

https://code.google.com/p/staff/wiki/SoaApplicationStruct

But…

•  Meaningful Modeling: What’s the Semantics of “Semantics”? http://goo.gl/mbTloA [HarelRumpe04]

“In its current form, the Object Management Group’s documents do not offer a rigorous definition of UML’s true semantics, not even of the semantic domain. Rather, they concentrate on the abstract syntax, intermixed with informal natural language discussions of what the semantics should be. These discussions certainly contain much interesting information on the semantics, but they are a far cry from what developers, as well as tool vendors, really need. As recent research shows, they still lack many clarifying details and contain many inconsistencies. ”

•  The State of Practice in Model-Driven Engineering http://goo.gl/h5YRtv [WHR14]

“UML 2.0, for example, a major revision of the UML standard, didn’t reflect the literature on

empirical studies of software modeling or software design studies. Consequently, current approaches force developers and organizations to operate in a way that fits the approach instead of making the approach fit the people. ”

Less formal and much more ambiguous than existing ALs

AADL

•  Architecture Analysis and Design Language –  initially stood for “Avionics ADL”

•  Primarily textual •  Very detailed

–  An AADL component runs on a processor, which runs one or more processes, each of which contains one or more threads of control, all of which can receive instructions through in ports and send data through out ports over a bus...

•  Primary focus – embedded, real-time, hybrid systems

AADL model

Ivano Malavolta, Henry Muccini, Patrizio Pelliccione: Integrating AADL within a Multi-domain Modeling Framework. ICECCS 2009: 341-346

Koala

•  Developed at Philips –  in collaboration with Imperial College London

•  Used in the consumer electronics domain –  allows to specify hierarchical architectures –  makes a distinction between component types and instances –  allows to construct configurations by instantiating components and

connectors and explicitly models optional interfaces

•  Both graphical and textual •  Primary focus – management of product populations

–  Modeling –  Analysis –  Implementation generation –  Deployment

Koala model

provides interface

required interface

Component type definition

Component instances

subcomponent

module switch

interface

Real Koala model

From a different perspective…

Pro: .formal semantics .computable

Cons: .difficult to learn .general lack of industrial tools .prolifetarion

Pro: .not too difficult .same notation for SA and design modeling

Cons: .not a 100% fit .tool investment

Pro: .of immediate use .perfect for sketching .communicative

Cons: .Ambiguous .not automated

Today

AL Name

AADL

ABC/ADL

ACME

ADAGE

ADLARS

ADML

AESOP

ArchJava

ArchWare

ArchiTRIO

ARTECH

C2

C2 AML

C2 SADEL

CommUnity

DAOP ADL

DARWIN

DICAM

EAST ADL

EXPRESSION

GEN VOCA

HMDES

ISDL

JACAL

KOALA

LILEANNA

AL Name

LISA

LITTLE JIL

MAE

MADL

MAFIIA

MAUDE

M(énage / xADL

META H

MIMOLA

MODE CHART

PALANTIR

PRISMA

RADL

RAPIDE

RESOLVE

SADL

SATURN

SKWYRL

UDL/i

UNICON

WEAVES

WRIGHT

WSDL

xArch / xAcme

xArch / xADL

xC2

100+ ALs

(better to say, languages that consider themselves to be ALs)

100+ ALs? http://www.di.univaq.it/malavolta/al/

Why So Many ALs?

There are many reasons for having many ALs:

•  Different ALs for different “stakeholder concerns” – Different domains – Different analysis – Different viewpoints

•  Some of them are really similar, with just small semantic or syntactic differences

– Many are just prototipal languages, research-specific

Issues (1/2)

Proliferation of languages for (SA) description §  without a clear understanding of their merits and limitations

Tens of ALs, characterized by slightly different conceptual architectural elements, different syntax, or semantics

§  Focussing on a generic or a specific operational domain

Some support automated analysis

Issues (2/2)

An IDEAL and general purpose AL is NOT likely to exist

§  Stakeholder concerns are various, ever evolving, and adapting to changing system requirements

§  Difficult to capture all such concerns with a single, narrowly focused notation.

Architectural languages must be able to focus on what is needed by the stakeholders involved in the architecting

process.

Two examples of modern ALs

•  Diasuite

–  https://dl.dropboxusercontent.com/u/3558185/11_DIASUITE.pdf

•  Evolve –  https://dl.dropboxusercontent.com/u/3558185/05_EVOLVE.pdf

Multi-views architecting

Some contents of this part of lecture extracted from Henry Muccini’s lecture on architectural views at the University of L’Aquila (Italy)

Views and Viewpoints

Architectural views

Typically, two different views are used:

User1

Router Server

Timer

AlarmUR AlarmRS (c)Check1

Nofunc

Clock

AckSR (c)

AckRU1

User2

AlarmUR1

AlarmUR2

Check2

Check

AckRU2

0 1 2

3

4

5

Structural Spec. Behavioral Spec.

- Component-based languages - UML notations

- Posets, pre-post conditions - Process algebras - Labeled transition systems, IO Automata, Buchi automata - Statechart, UML state machines

Stakeholder concerns à multiple views Using multiple views has become standard practice in industry

–  IEEE Std 1471 (2000) -> … -> ISO/IEC/IEEE 42010 (2011) –  Based on a survey we conducted with 48 practitioners about

the usage of architectural languages in industry –  85% uses multiple views

ISO/IEC/IEEE 42010: 2011

Architecture description

Architecture Description is the practice of expressing architectures (ISO/IEC 42010) “The practices of recording software, system and enterprise architectures so that architectures can be understood, documented, analysed and realized.” “Architecture descriptions are created by architects and used by architects and other stakeholders throughout all stages of a system’s life cycle, from development through operation and maintenance.”

Architecture description mechanisms

Architecture Viewpoints •  define the contents of each architecture view

Architecture Description Languages (ADLs) •  any mode of expression used in an architecture description. •  ADL provides model kinds selected to frame one or more

concerns

Architecture Frameworks •  coordinated set of viewpoints for use within a particular

stakeholder community or domain of application (e.g., Kruchten’s 4+1, GERAM, TOGAF, MODAF)

ISO/IEC/IEEE 42010: 2011 Concerns functionality, feasibility, usage,

structure, behavior, performance, resource utilization, security, cost,

data accessibility, privacy, compliance to regulation,

business goals and strategies

Stakeholders Developer Architect End-user

Tester Project manager

Stakeholder concerns

•  the nature of the system •  project-specific constraints •  organizational constraints •  the application domain •  …

Stakeholders concerns can vary tremendously (and change over time), depending on:

Example: BusOnAir

BusOnAir stakeholders and concerns


Views and viewpoints […] “a viewpoint is a way of looking at a system; a view is what you see” “A viewpoint defines the conventions (such as notations, languages and types of models) for constructing a certain kind of view” ”viewpoint refers to the conventions for representing an architecture relative to one set of concerns.” “A view is the result of applying a viewpoint to a particular system of interest” “viewpoints as first-class entities of architecture descriptions.”

view : viewpoint = program : programming language

BusOnAir viewpoints

BusOnAir architectural languages

BusOnAir architectural languages: DiaSpec

Declarative language for describing applications that orchestrate entities interacting with an environment Supports code generation and interactive simulation

BusOnAir architectural languages: UML

UML is a good starting point for defining the behaviour of the system More commonky known à used for sharing architectural knowledge among stakeholders Focus on: •  component diagrams •  state machine diagrams

BusOnAir architectural languages: FSP

FSP = Finite State Process Formal language Focus on the behaviour of concurrent systems Allows us to perform property checks and deadlock freedom analysis

BusOnAir architectural languages: REST

Domain-specific language for specifying services according to the REST architectural style Deliberate choice: interface between the Bus+mobile app to the central server as a set of RESTful web service


BusOnAir correspondence rules •  COMP_REST

–  each resource defined in a REST model in the WebServices view must be associated to at least a UML component in the System view

•  UML_UML –  in the System view, each UML component must contain a UML

state machine describing its behaviour

•  UML_FSP –  in the Behaviour view, for each UML state machine in the System

view there must be a process definition with the same name in the FSP model

•  DIASUITECOMP_UML –  in the System view, for each generic component in the DiaSpec

model there must be a UML component with the same name

Architecture Framework (AF)

Coordinated set of viewpoints for use within a particular stakeholder

community or domain of application (e.g., GERAM, TOGAF, MODAF);

BusOnAir architectural framework

BusOnAir views

BusOnAir Diaspec model

BusOnAir UML component diagram

BusOnAir UML state diagram (Trip Manager)

BusOnAir FSP (Trip Manager)

BusOnAir FSP (in the tool)

BusOnAir REST model

BusOnAir summary 1

Definition of Stakeholders and

Concerns

Definition of Viewpoints

Import of the needed ADLs

Definition of Correspondence

Rules

Definition of Architecture Views

Architecture Description

Architecture Framework

Conformance checks with respect to the

framework

BusOnAir summary 2

Model the Bus System with DiaSpec

Get a UMLCC model of the

BusOnAir system

Define behaviour of the BusOnAir system in UMLCC

Get an FSP model of the

BusOnAir system

Analyse the FSP model

Define a RESTLANG model of the BusOnAir services

System view Behaviour view

WebServices view

1

4

5

6

7

8

Manual step

Automatic step

Logical View

End-user

Functionality

Implementation (Development) View

Programmers Software management

Process View

Performance Scalability Throughput

System integrators

Deployment View

Conceptual Physical

Use Case View

Object Model of Design

Static Organization of the Software

Concurrency and Synchronization

Software Mapping To Hw System engineering

System topology Delivery, installation Communication

Kruchten’s 4+1 views

Open research challenges on software architecture

Refresh 1

Example: SA research questions

FEASIBILITY

CHARACTERIZATION

METHOD/MEANS

GENERALIZATION

DISCRIMINATION

Is it possible to automatically generate code from an architectural specification?

What are the important concepts for modeling software architectures?

How can we exploit domain knowledge to improve software development?

What patterns capture and explain a significant set of architectural constructs?

How can a designer make tradeoff choices among architectural alternatives?

Refresh 2

Example: SA research results QUALITATIVE & DESCRIPTIVE MODELS

TECHNIQUES

SYSTEM EMPIRICAL MODELS ANALYTIC MODELS

Early architectural models Architectural patterns Domain-specific software architectures UML to support object-oriented design

Architectural languages Communication metrics as indicator of impact on project complexity Formal specification of higher-level architecture for simulation

Refresh 3

Example: SA research validation PERSUASION

IMPLEMENTATION

EVALUATION ANALYSIS

Formal model Empirical model

EXPERIENCE

Qualitative model Decision criteria Empirical model

Early architectural models

Early architectural languages

Taxonomies, performance improvement

Formal schedulability analysis User interface structure

Architectural patterns Domain-specific architectures Communication and project complexity


•  Reconciling SA for analysis and communication –  how to manage formal specifications that can be also used for

communication?

Documents for communications Analytic artefacts vs

First prototype…

Software architects

continuous alignment

Wiki-based knowledge

base

m1 m2 mn

access and record AKs

reason on the architecture design

create, access, and tune models

...

Open research challenges •  Support for multiple views

–  consistency and completeness checking


•  Flexible architectural frameworks –  support for combining different views, viewpoints, languages, etc.

Architectural Assets Repository

Viewpoints

Stakeholders

Model Kinds System Concerns Architectural languages

Correspondences


B


C


A

Architecture Framework


•  Traceability between requirements, design decisions, and architecture

Other main research challenges

•  Fluid architectures •  for example, think about robot teams working together

–  support (self-) adaptation and changes –  trade-off with qualities (e.g., safety and performance)

•  End-user architecting –  in the future end-users will assemble components at wish –  which architectural environment to show them?

•  Example: Yahoo! Pipes

–  Task oriented interfaces? •  Example: FLYAQ

•  Architectural languages for cyber-physical systems –  Must include physical elements

and manage large-scale networks

What this lecture means to you?

Software Architecture

what is essential about the system w.r.t. some specific concern

Why software architecture?

Components and connectors Distribution and configuration Expected behaviour Patterns, styles HW/SW Deployment Extra-functional properties

scalability, performance, testability, security

Modern software architecture

Focus on views and viewpoints looking at stakeholders and their concerns

Suggested readings 1.  Patricia Lago, Ivano Malavolta, Henry Muccini, Patrizio Pelliccione,

Antony Tang (2013). What Industry Needs from Architectural Languages: A Survey. IEEE Transactions on Software Engineering, 39(6), pp. 869-891.

2.  ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Systems and software engineering -- Architecture description". Retrieved 2012-09-12.

3.  Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.

4.  Ivano Malavolta (2012). Software Architecture Modeling by Reuse, Composition and Customization. PhD Thesis. University of L'Aquila, Computer Science Department. http://goo.gl/iZEVbH

References

Contact Ivano Malavolta |

Post-doc researcher Gran Sasso Science Institute

iivanoo

[email protected]

www.ivanomalavolta.com