Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)

Università degli Studi dell’Aquila

1

Needs, Challenges, and Opportunites in Architecture Languages

Henry Muccini DISIM, University of L’Aquila

[email protected], @muccinihenry, henrymuccini.com

Seminar lecture @Uni Bozen – Dec 2013

mailto:[email protected]

Introduction to (Modern) Software Architecture

Components and Connectors

Design Decisions

Views and Viewpoints

Architectural Languages

Our TSE 2013 Study

2

My

Back

grou

ndResearch interestsOn developing methods and tools for the analysis and design of software architectures

→Using MDE for Architecture Description:→Interoperable Software Architecture Descriptions→ Multi-view Architecture Framework→Extensible Architecture Languages

→Nagivation Design of Mobile Applications→Architecting Wireless Sensor Network

→Architecting Fault Tolerant Systems→Architecture-driven Model-based Testing→Model-checking Architectures

3

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 viewpoints

Soft

war

e A

rchi

tect

ure4

Software Architecture definitions

Perry and Wolf, ’92 (aspects):→“Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.”

→Elements are divided into processing elements, data elements and connection elements

Garlan and Shaw, ’93 (elements):→ Architecture for a specific system may be captured as “a collection of computational components - or simply components - together with a description of the interactions between these components - the connectors –”

5

6

Let us reason about the Gaudi’s Sagrada Familia

Soft

war

e/Sy

stem

Arc

hite

ctur

e6

Software Architecture…the power of abstraction…

7

STM-4/16

ADMADM

ADMADM

STM-1/4

ADMADM

ADMADM ADMADM

SXC4/1

SXC4/1

Urban Level

SXASXA

STM-1/4

ADMADM

ADMADM ADMADM

ADMADM

STM-4/16

ADMADM

ADMADM

Regional level

STM-1/4

ADMADM

ADMADM

ADMADM ADMADM

SXASXA

TELECOM ITALIA NETWORK ARCHITECTURE

WDM

STM-4/16

ADMADM

ADMADM

SXASXA

WLWL

STM-16 Ring

National Level

ADMADMADMADM

ADMADM

ADMADMADMADM

ADMADM

ADMADMADMADM

ADMADM WLWL ADMADMADMADM

ADMADM

ADMADMADMADM

ADMADM

ADMADMADMADM

ADMADM

STM-16 Ring

Exam

ple8

eGov Architecture: basics

standard

standardstandard

standard

standard

process

laws

9

(some of the) Requirements for e-Gov

Privacy e confidentiality

Autenticity

Need of Standards

Shared Process Management

Scalability

Docs digitalization

10

SA with Decentralized data SA with Centralized Data

But which Architecture?

Implications on privacy, confidentiality, performance, scalability, maintainability, etc.

11

SA with Centralized Data, v1

But which Architecture?

Implications on privacy, confidentiality, performance, scalability, maintainability, etc.

SA with Centralized Data, v2

12



Soft

war

e A

rchi

tect

ure

SA with Centralized

Data, v1

SA with Centralized

Data, v2

13

Architecture Design Decisions

Decisions about:

Selected components/interfaces/connectorsDistribution/Configuration of

components/connectorsExpected behavior

SA Styles, Patterns and TacticsHW/SW/Deployment and other views

Components’ Nesting and sub-systemsNF attributes

14

Architecture as a set of design decisions15

A set of architecture design decisions taken to generate the architecture artifact

Designproblem

sub-problem

(or issue)

sub-problem (or issue)

Designoption

Designoption

Designoption

Designoption

Problem space

Solution space

Alternativesolutions

Alternativesolutions

Decision =best option

Decision =best option

Best, with respect to some

criterionJansen, A.; Bosch, J., "Software Architecture as a Set of Architectural Design Decisions," Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP

Conference on , vol., no., pp.109,120, 2005. doi: 10.1109/WICSA.2005.61

Notations and ToolsArchium: A meta-model and tool developed by Anton Jansen et al

ADDSS: a web based tool developed by Rafael Capilla et al

AREL: a rationale based model developed by Antony Tang et al

DAMSAK: Data Model for Software Architecture Knowledge developed by Babar et al

PAKME : a tool that supports DAMSAK

SEURAT: Software Engineering using Rationale, which integrates tools for rationale capture, visualization, and use into a standard software engineering environment

16

ADD: what is interesting to discuss?

1. Granularity of design decisions

2. Dependencies among decisions

3. ADD taken in a collaborative way

4. ADD that uses genetic algorithms in order to find the optimal solution

5. Evolving ADD

Smrithi Rekha V, and Henry Muccini. A Study on Group Decision-Making in Software Architecture. To appear @ WICSA 2014

17



Soft

war

e A

rchi

tect

ure18

Views and Viewpoints19

20

Architectural Views Vie

ws

User1

Router Server

Timer

AlarmUR AlarmRS (c)Check1

Nofunc

Clock

AckSR (c)

AckRU1

User2

AlarmUR1

AlarmUR2

Check2

Check

AckRU2

0 12

3

4

5

ISO/IEC/IEEE 42010: 2011

ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011

21

Logical View

End-user

Functionality

Implementation (Development) View

Programmers Software management

Process View

PerformanceScalability

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 HwSystem engineering

System topology Delivery, installation

Communication

RUP 4+1 views2222


Architecture Languages

Soft

war

e A

rchi

tect

ure23

HOW TO DOCUMENT SOFTWARE ARCHITECTURES?

Documenting Software Architecture (how to)

26

Architecture Description Languages (ADLs): any mode of expression

used in an architecture description.

ADL provides model kinds selected to frame one or more concerns.


ADL (according to ISO/IEC/IEEE 42010:2011)

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

27

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

28

100+ ALs29

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, some others do not

30

Issues (2/2) An IDEAL and general purpose ADL is NOT likely to exist

Stakeholder concerns are various, ever evolving, and adapting to changing system requirements. [ISO/IEC/IEEE 42010]

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.

31

But, what industry needs from Architectural Languages?

32

Industrial needs on ALs

Medvidovic et al. [12]

Woods and Hilliard [17]

Woods [18]

Pandey [19]

Hilliard and Rice [20]

Clements [21]

33

What Industry needs from ALs: A survey

Goal of the study:→ to better understand the real needs about using ALs for

software architecture modeling in industry

─ RQ1: What are the architectural description needs of practitioners?─ RQ2: What features typically supported by existing ALs are useful

(or not useful) for the software industry?

34

Ivano Malavolta, Patricia Lago, Henry Muccini, Patrizio Pelliccione, Antony Tang: What Industry Needs from Architectural Languages: A Survey.

IEEE Trans. Software Eng. 39(6): 869-891 (2013),http://doi.ieeecomputersociety.org/10.1109/TSE.2012.74

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)

35

36

Usefulness of ADL features in past and future projects37

Needs, Challenges and Opportunities in ALs

C1: need of communicative and analytic AL

C2: need of models interoperability, and extensibility.

C3: need of multi-view management

C4: need of analysis (especially, extra functional)

C5: need of versioning and collaborative work

38

Models Interoperability

Multi View Management

(DS)LanguageExtensibility

Usable & Analytic DSL

Group Design

Decision

Resilience

SA-based Testing and

MC

Needs and Challenges Domains

WSN

Mobile

any

Technical Foundations

MetamodelComposition

Model Transformation

Model Weaving

Semantic Wiki

DLSs Editors

Megamodeling

Survey TSE 2013 +

Software Architecture

39

MDE


Dual role of a software architect: as communication bridge

the extrovert nature of the architect role and as design and analyst means

realizing its introvert nature

Need to cover a combination of features…

40

Analysis

Implem

entati

on

Communication

Design

Proces

s

Documen

tation

05

10152025

-1+1

-1+1

Type of needs

Type of needs

also in Kruchten [59] and Hoorn et

al. [60]

The two forces…ALs for formal analysis (academic focus)

Analytic and expressive languages, but expensive for industries

ALs for communicating DD and solutions (industry focus) UML as the most used language, but less suitable for analysis

41

0153045

Standard notation types

UML only: 24%

C1: Our solution42

Software architect

s

continuous alignment

Domain-specificknowledge base

m1 m2 mn

access and record AK

reason on the architecture

design

create, access,

and tune models

...

MDE engine with a “domain-specific, user-usual” input

Experience so far: Semantic Wiki <-> MDE

just accepted @ WICSA 2014 Mobile <-> MDE

Architecture description leveraging MDE and Semantic Wikis

43

idea

implementation

C2.1 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

44

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

Motivating Example

Performance Model PM

Security Model

System

Performance analysis

Security analysis

?

?

45

C2.1 Our Solution

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

46DUALLY 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.

46

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

47

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

48

Transformation

ADLa

ADLb

A0

DUALLY’s features A0 extension mechanisms

Lost-in-translation

Change propagation

49

C2.2 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

PROBLEM

SOLUTION

50

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

byADL: adapting ADLs to stakeholder concerns

• adding domain specificities,• new architectural views,• new analysis constructs, • fine tuning it

newADL

o byADL allows to define a new ADL by starting from an

existing one and

51

Tech Foundation: Metamodel Composition52

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

MMMMext

composition model

MMcomp

transformations

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

53

Tool Support

MEGAFDUALLy

EMF

AM3 AMW ATL

AMMA

byADL other engines

MEGAF

54

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

Automation55

Needs, Challenges and Opportunities in ALs


C2: need of models interoperability, and extensibility.

C3: need of multi-view management

C4: need of analysis (especially, extra functional)

C5: need of versioning and collaborative work

56

C3: Viewpoints (1/2)

RQ3: Which is the role of Viewpoints when architecting a software system?

→ 85% uses multiple views

→ Use of multiple views for architectural description.

─ Types of views→ 50% of multi view users apply consistency check

Architecture Descriptions


C3: Viewpoints (1/2)

RQ3: Which is the role of Viewpoints when architecting a software system?

→ Use of multiple views for architectural description.

─ Types of views→ 50% of multi view users apply consistency check

Structu

ral

Behav

ioral

Physical

Require

ments

Conceptual

Implem

entati

on

Actor in

teracti

on

Business

Propert

y-rela

ted0

5

10

15

20

25

30

35

40

45

Type of views

Type of views

Henry_2

##D13.a##

C3 : Viewpoints (2/2)→ About 33% model/focus on relevant system concerns

→ 43% extended ADLs for adding new views

→ Tool support─ (tool feature missing: 14% viewpoint)

→ Additional feature required to ADLs─ (cross-view consistency)

Summary:→ Practitioners use multiple views and others would like to do so.

They also apply consistency checking. Better Tool support is required

Yes, b

ut at a

very

abstr

act le

vel

Yes in

detail

Just for s

ome speci

fic view

point

No, it is

too complex

No, the u

sed notati

on does not a

llow it

0

10

20

30

40

Is the focus on modeling the entire system?

Is the focus on modeling the entire system?

Henry_2

##D10##

Henry_2

##D15##

Henry_2

##D19##

Henry_2

##D27.c##

Henry_2

##D10

C3 : Viewpoints (2/2)→ About 33% model/focus on relevant system concerns

→ 43% extended ADLs for adding new views

→ Tool support─ (tool feature missing: 14% viewpoint)

→ Additional feature required to ADLs─ (cross-view consistency)

Summary:→ Practitioners use multiple views and others would like to do so.

They also apply consistency checking. Better Tool support is required

With

analy

sis-orie

nted in

formati

on

Informall

y

With

new vi

ewpoints

With

additional

constr

aints

Minimall

y, lan

guag

e adap

tation

0

10

20

30

40

Extension/customization: how?

Extension/customization: how?

Henry_2

##D15##

Henry_2

##D19##

Henry_2

##D27.c##

C3: Summary

Using multiple views has become standard practice in industry

• IEEE Std 1471 (2000) -> … -> ISO/IEC/IEEE 42010 (2011) • Based on our survey

85% uses multiple views

[Survey2012] “What Industry needs from Architectural Languages: A Survey”, I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, A. Tang (under review)

62

C4 : analysis

Is analysis perceived as a need when architecting a software system?

→ Need to analyze an architecture

→ Most important needs ─ need: 30%─ Dissadisfaction with ADL: 45% of those needing analysis

(the second most important unsatisfactory need was about analysis)

→ Did you analyse your architecture description produced with the ADL?─ (did you analyse: 74% is yes, but 32% is manual)─ (why you analyse: 48% for extra functional)─ (why not: no value, ADLs too limited/imprecise, ...)

63%37%

10%

Need for analysis

yesnoblank

Henry_2

##C2.AA##

C4 : analysis



→ Most important needs ─ need: 30%─ Dissadisfaction with ADL: 45% of those needing it

(the second most important unsatisfactory need was about analysis) ????????


Analysis

Implem

entati

on

Communication

Design

Proces

s

Documen

tation

0

5

10

15

20

25

-1

+1

-1

+1

Type of needs

Type of needs

Henry_2

##D6##

C4 : analysis



→ Most important needs ─ need: 30%─ Dissadisfaction with ADL: 45% of those needing analysis



35%

20%

45%

level of satisfaction

Satisfied Neutral Not satisfied

Henry_2

##D6##

C4 : analysis

RQ2: Is analysis perceived as a need when architecting a software system?


→ Most important needs─ need: 30%─ Dissadisfaction with ADL: 45% of those needing analysis



74%

26%

Analysis

Yes No

Henry_2

##D11##

C4 : analysis



→ Needs but unsatisfaction with current ADLs─ need: 30%─ Dissadisfaction with ADL: 45% of those needing it



48%

4%

8%

24%

12%

Kind of analyzed properties

Extra-functional proper-tiesFunctional propertiesHW/SW integrationBehaviorNo info

Henry_2

##D11##

C4 : analysis



→ Needs but unsatisfaction with current ADLs─ need: 30%─ Dissadisfaction with ADL: 45% of those needing it


→ Did you analyse your architecture description produced with the ADL?─ (did you analyse: 74% is yes, but 32% is manual)─ (why you analyse: 48% for extra functional)─ (why not: 26%. no value, ADLs too limited/imprecise, ...)

Henry_2

##D11##

Concluding Remarks69

20+ years of research, but still a lot to be done to bridge the gap between academic research and industry needs

•MDE can be a valuable technological tool, but…

Notation

•Known issue… stop the “mine is the best” war!!•D

omain models + MDE could be a solution!

Analytic vs Communicative

•A topic that deserves more investigation•N

ot simply a consistency checking problem

Multi-view

•Need of Integration of different functional and extra-functiona approaches

Analysis

•Still little has been done in this domain

Empirical studies

Università degli Studi dell’Aquila

70

Needs, Challenges, and Opportunites in Architecture Languages

Henry Muccini DISIM, University of L’Aquila

[email protected], @muccinihenry, henrymuccini.com

Seminar lecture @Uni Bozen – Dec 2013

mailto:[email protected]

Education

Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)