The road ahead for architectural languages

Ivano Malavolta

Gran Sasso Science Institute, L’Aquila, Italy

Roadmap

What industry needs from ALs?

Requirements for next-generation ALs

MDE as technological enabler

Conclusions

What industry needs from ALs?

INDUSTRIAL NEEDS

ON ALS

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?

4

ANALYSIS (IS A NEED)

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

63%37%

10%

Needforanalysis

yes

no

blank

ANALYSIS (IS A PRACTICE)

Did you analyse your architecture description produced with the AL?

(why you analyse: 48% for extra functional)

(why not: no value, ADLs too limited/imprecise, ...)

74%

26%

Analysis

Yes

No

ANALYSIS (IS FOR EXTRA FUNCTIONAL)

48%

4%8%

24%

12%

Kindofanalyzedproperties

Extra-functional properties

Functional properties

HW/SWintegration

Behavior

Noinfo

ANALYSIS (IS STILL CHALLENGING)

35%

20%

45%

Levelofsatisfaction

Satisfied

Neutral

Not satisfied

(One interviewed practitioner)

DESIRABLE FEATURES

Requirements for next-generation ALs

FRAMEWORK OF AL REQUIREMENTS

LANGUAGE DEFINITION

A.1 - Support to specify extra functional properties• e.g., data flow analysis, run-time dependencies analysis, performance,

scalability, security, requirements and change impact analysis

A.2 - Well-defined semantics• Provide a precise and unambiguous semantics to the language

• It is an important enabler for analysis and other automatic tasks

A.3 – Support for graphical and textual specification• Graphical representations can be used for knowledge sharing and

discussion

• Textual representations might be used by experts for rapidly building a model

LANGUAGE FEATURES

B.1 – Multiview management• Each view gives a different perspective on the same architecture, addressing

different concerns • Integration of different views

• Consistency across the views

B.2 – Extensibility and customization• To better express domain- and project-specific concepts and constraints• For enabling additional analysis capabilities

B.3 – Programming framework• Homogeneous representation of architecture models that can be

programmatically accessed via dedicated APIs• Expose APIs to manage, create, and modify models belonging to different

abstractions (from requirements, to architecture, to code) in a coordinated way• These facilities play a key role in the integration into development processes

TOOL SUPPORT (1)

C.1 – Automated analysis• Specially against non-functional properties• Mask the complexity of the analysis engine in order to reduce the demand

of specific skills and competencies

C.2 – Support for architecture-centric design• SAs should be used as a high-level compass for guiding system

development and for maintenance

C.3 – Large views management• Architecture descriptions may encompass several large heterogeneous

and interrelated views• Information relevant for a specific stakeholder may be scattered across

different views

TOOL SUPPORT (2)

C.4 – Support for collaboration• Synchronous collaboration for real-time co-modeling

• Asynchronous collaboration in which each stakeholder can collaborate at his own convenience and schedule; this comes at the cost of possible delays of interaction

C.5– Support for versioning• special emphasis on keeping track of the various versions of architectural

models throughout the project duration

C.6 – Support for knowledgement• Leverage knowledge sharing tools (e.g., wikis, semantic wikis, etc.) to record

and discuss architectural design decisions and their rationale

• Connected to the well-known problem of architectural knowledge vaporization

MDE as technological enabler

MDE AS TECHNOLOGICAL ENABLER

By applying the MDE principle saying that

“models are precise artifacts that can be understood by computers and can be automatically manipulated”

MDE techniques can be used to satisfy the AL requirements with a focus on automation and reuse

Language definitionA

Language featuresB

Tool supportC

MDE can be used to define precise and unambiguous ALs

Language definitionA

Support to specify extra-functional properties A.1

M2

M1

metamodel

model

context SoftwareArchitecture inv:self.components−>collect(name)

−>asSet().size() = self.components.size()

WHY METAMODELLING?

Apart from classical benefits of modeling…

1. Precisely define languages in a way that allows us to use tools to manipulate them

2. Straightforward creation of well-formed models that conform to the concepts and logic expressed in the metamodel

it distinguishes models that can be loaded into an editor (e.g., an Eclipse editor) from those that cannot

3. Standard languages for transforming models into other artifactsno parser development (in principle)

4. Enable traceability use caseslinks between machine-processable artifacts to each other and to external artifacts (ie those without metamodels)

5. Enable straightforward model comparison

The metamodel defines the static semantics of an AL

Static semantics can be further constrained by using constraint languages, like:

• OCL – the Object Constraint Language proposed by OMG

• EVL – the Epsilon Validation Language proposed by Epsilon

• Topcased OCL tools

MDE can provide tools for giving behavioral semantics to an AL by mapping the structure of a language onto a semantic domain (e.g., via model transformations)

Language definitionA

Formal semanticsA.2

EXAMPLE

ProCom model à finite state machine formalism àUPPAAL

Aneta Vulgarakis, Jagadish Suryadevara, Jan Carlson, Cristina Cerschi Seceleanu, Paul Pettersson: Formal Semantics of the ProCom Real-Time Component Model. EUROMICRO-SEAA 2009: 478-485

MDE provides a set of engines for different kinds of editor, like:

graphicalEclipse GMFEpsilon EugeniaEclipse Graphiti

textualxTextemfText

tree-baseddefault EMF generic editorEpsilon Exeed

Thanks to the unification power of models, various levels of automation are supported

Language definitionA

Support for graphical & textual specification A.3

AADL

Reuseware CSDL

Eclipse BPMN2

MDE promotes the use of multiple views linked together by means of suitable relationships

Why linking models together?

• Tool interoperability

• Transformation to analysis notations

• Linking entities across models

• Traceability

• Model merging

• Model annotation

• …

Language mechanismsB

Multi-view managementB.1

Main MDE techniques:

• model weaving• model transformation

(see req C.1)

MODEL WEAVING

Model weaving is a generic operation that establishes fine-grained links between model elements

In general a dedicated weaving model contains the set of links among models

As any kind of model, a weaving model can be

saved, stored, transformed, generated, etc.

Image courtesy of Jordi CabotEpsilon ModeLink

MDE provides different techniques to manage language and tools extensibility

Example: UML profiling

However…

some languages may not support extensibility by design

MDE also provides lightweight extension mechanisms (eg EMF Facet)• without affecting the original language

• without polluting the original models

• easily processable by humans and tools

Language mechanismsB

Extensibility and customizationB.2

MDE offers different facilities for building programming frameworks based on the structure of DSL metamodels

Two champion implementations:

Language mechanismsB

Programming frameworkB.3

Eclipse Modeling Framework (EMF)

- full generation of Java domain classes

- XML model persistency

- models validation

- transactions

TEXOEMFT Texo

- Generation of POJO classes

- Generation of ORM mappings

- Extensible code generation

Model transformations can be used to automatically generate analysis models from architectural models

Tool supportC

Automated analysisC.1

UML2LTSA

UMLmodel FinitestateprocessesinLTSAtool

Model transformations can be used to automatically obtain various types of artifacts spanning throughout the development life-cycle

Weaving models can be used to define typed links between architectural models, eg:• for storing traceability information

eg, between SA elements and requirements, design decisions, generated skeleton code, financial prospects, etc.

• for change impact analysis while maintaining the system

• for managing architectural erosion

Tool supportC

Support for SA-centric designC.2

EXAMPLE

Ivano Malavolta, Henry Muccini, V. Smrithi Rekha (2011). Supporting Architectural Design Decisions Evolution through Model Driven Engineering. In Proceedings of the 3rd International Workshop on Software Engineering for Resilient Systems (SERENE 2011), pp. 63-77.

Tool supportC

Large views managementC.3The activitiy of representing references to models and relationships

between them as a model called

The AM3 (AtlanMod MegaModel Management) project is a concrete implementation of megamodeling

MEGAMODEL

MDE techniques provide means to support the management of different versions of any kind of model

Also, MDE provides means to effectively match and merge different versions of one model, and to identify and solve possible conflicts

Champion implementation:

Tool supportC

Support for collaborationC.4 Support for versioningC.5

- Graphical editor to see and merge model diffs

- Extensible: can integrate new differencing policies

- Scalable (uses model gragments)

- Integrated with Eclipse Team Apis: Git, CVS, SVN...

MDE can be an enabler for a seamless integration of all artifacts used throughout the project (e.g., financial prospects, architecture models, stakeholder concerns) and knowledge sharing tools

Tool supportC

Support for knowledge managementC.6

Software architects

continuousalignment

Wiki-basedknowledge base

m1 m2 mn

access and record AK

reason on the architecture design

create, access, and tune models ...

Baroni, Muccini, Malavolta, Woods (2014). Architecture Description Leveraging Model Driven Engineering and Semantic Wikis. In Software Architecture (WICSA), 2014 IEEE/IFIP Conference on, pp. 251–254.

LET’S CHALLENGE AADLAL requirement Supported Notes

Specify extra functional properties ✓ Yes (mainly timing, safety, reliability, …)

Formal semantics ✓ Yes (mainly via semantic anchoring)

Graphical and textual specification ✓Both graphical and textual (main), XML for tools

Multiview management ✕ Not as first-class aspect

Extensibility and customization ✓ Ecosystem of AADL annexes

Programming framework ✓ Java-based, provided by EMF

Automated analysis ✓ Many tools available

Architecture-centric design ✕ Not as first-class aspect

Large view management ~ Only namespaces via AADL packages

Support for versioning✓

Via any versioning system (e.g., SVN plugin installable in OSATE)

Support for collaboration ~Same as above, also no synchronous collaboration

Knowledge management ✕ Not as first-class aspect

CONCLUSIONS

THE STUDY POPULATION

Participants = 48

25 interviews

23 on-line questionnaires

Localization: 15 countriesUSA (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

35

18%

34%23%

25%

A(0-99)

B(100-999)

C(1000-4999)

D(5000-above)

MDE LIGHTWEIGHT EXTENSION TOOL

Image courtesy of Hugo Bruneliere (http://goo.gl/TzA7k6)

AVAILABLE MODEL TRANSFORMATION

LANGUAGES

http://en.wikipedia.org/wiki/Model_transformation_language

OTHER INSTRUMENTS FOR MODELING IN THE LARGE

EMF views Wires*

Epsilon ANT tasks

INVOLVED STAKEHOLDERS

Metamodeling expertcreates modeling languages (see metamodeling later)develops the modeling environment for a languagedevelops analysis tools for the modelscreates transformations for, e.g., code generationcreates the infrastructure for managing sets of interconnected models…

Software Architectmodels a specific systemruns analytical tools on the modelsruns the transformations for obtaining additional artifactsdiscusses language updates with the metamodeling expert…

CREATESthe infrastructure

USES the infrastructure