5th of April 2016. My presentation done at the 3rd Architecture Centric Virtual Integration Workshop (ACVI) workshop, co-located with WICSA and Comparch 2016, Venice, Italy. Accompanying paper: http://www.ivanomalavolta.com/files/papers/IEEESoftware_2015.pdf

1. The road ahead for architectural languages
Ivano Malavolta
Gran Sasso Science Institute, L’Aquila, Italy

2. Roadmap
What industry needs from ALs?
Requirements for next-generation ALs
MDE as technological enabler
Conclusions

3. What industry needs from ALs?

4. INDUSTRIAL NEEDS
ON ALS
RQ1: Whatare the
architecturaldescription
needs of practitioners?
RQ2: Whatfeatures typically
supported by existing ALs
are useful (or not useful) for
the software industry?
4

5. ANALYSIS (IS A NEED)
Is analysis perceived as a need when architectinga software
system?
63%
37%
10%
Need for analysis
yes
no
blank

6. ANALYSIS (IS A PRACTICE)
Did you analyse your architecturedescriptionproduced with the
AL?
(why you analyse: 48%for extra functional)
(why not: no value, ADLs too limited/imprecise,...)
74%
26%
Analysis
Yes
No

7. ANALYSIS (IS FOR EXTRA FUNCTIONAL)
48%
4%
8%
24%
12%
Kind of analyzed properties
Extra-functional properties
Functional properties
HW/SW integration
Behavior
No info

8. ANALYSIS (IS STILL CHALLENGING)
35%
20%
45%
Level of satisfaction
Satisfied
Neutral
Not satisfied

9. (One interviewed practitioner)
DESIRABLE FEATURES

10. Requirements for next-generation ALs

11. FRAMEWORK OF AL REQUIREMENTS

12. 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 unambiguoussemantics to the language
• It is an important enabler for analysisand 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 rapidlybuilding a
model

13. LANGUAGE FEATURES
B.1 – Multiview management
• Each viewgives a different perspectiveon the same architecture, addressing
different concerns
• Integration of different views
• Consistency across the views
B.2 – Extensibility and customization
• To betterexpress domain- and project-specificconcepts and constraints
• For enabling additional analysis capabilities
B.3 – Programmingframework
• Homogeneous representation of architecturemodels that can be
programmaticallyaccessed 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 rolein the integration into developmentprocesses

14. TOOL SUPPORT (1)
C.1 – Automated analysis
• Specially against non-functionalproperties
• Mask the complexity of the analysis engine in order to reduce the demand
of specific skills andcompetencies
C.2 – Support for architecture-centric design
• SAs should be used as a high-level compassfor guiding system
development and for maintenance
C.3 – Large views management
• Architecture descriptions may encompassseveral large heterogeneous
and interrelated views
• Information relevantfor a specific stakeholder may be scattered across
different views

15. TOOL SUPPORT (2)
C.4 – Support for collaboration
• Synchronouscollaboration for real-time co-modeling
• Asynchronouscollaborationin which each stakeholder can collaborate athis
own convenience and schedule; this comes at the cost of possible delays of
interaction
C.5– Supportfor versioning
• special emphasis on keeping track of the various versionsof architectural
models throughoutthe 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

16. MDE as technological enabler

17. MDE AS TECHNOLOGICAL ENABLER
By applying the MDE principlesaying that
“models are precise artifactsthatcanbe understood by
computersand can be automaticallymanipulated”
MDE techniques can be used to satisfy the AL requirements with a
focus on automationand reuse
Language definitionA
Language featuresB
Tool supportC

18. MDE can be used to define precise and unambiguous ALs
Language definitionA
Support to specify extra-functional propertiesA.1
M2
M1
metamodel
model
context SoftwareArchitectureinv:
self.components−>collect(name)
−>asSet().size() = self.components.size()

19. WHY METAMODELLING?
Apart from classical benefits of modeling…
1. Precisely define languages in a way that allows us to use tools to
manipulatethem
2. Straightforward creation of well-formed models thatconform to the
concepts and logic expressed in the metamodel
it distinguishes models thatcan be loaded into an editor (e.g., an Eclipse
editor) from those thatcannot
3. Standard languages for transformingmodels into other artifacts
no parser development(in principle)
4. Enable traceability use cases
links between machine-processableartifacts to each other and to
external artifacts (ie those withoutmetamodels)
5. Enable straightforward model comparison

20. The metamodel defines the static semantics of an AL
Static semantics can be further constrained by usingconstraintlanguages, like:
• OCL – the Object Constraint Language proposed by OMG
• EVL – the Epsilon Validation Languageproposed by Epsilon
• Topcased OCL tools
MDE can providetools for giving behavioral semantics to an AL by mappingthe
structure of a languageonto a semantic domain (e.g., via model transformations)
Language definitionA
FormalsemanticsA.2

21. EXAMPLE
ProCom model à finite state machine formalismàUPPAAL
Aneta Vulgarakis,JagadishSuryadevara,Jan Carlson,Cristina Cerschi Seceleanu, PaulPettersson:
Formal Semanticsof the ProCom Real-Time ComponentModel.EUROMICRO-SEAA 2009: 478-485

22. MDE provides a setof engines for different kinds of editor, like:
graphical
Eclipse GMF
Epsilon Eugenia
Eclipse Graphiti
textual
xText
emfText
tree-based
default EMF generic editor
Epsilon Exeed
Thanks to the unification power of models, various levels of automation are
supported
Language definitionA
Support for graphical & textual specificationA.3
AADL
Reuseware CSDL
Eclipse BPMN2

23. MDE promotes the useof multipleviews linked together by means of suitable
relationships
Why linkingmodels together?
• Tool interoperability
• Transformation to analysis notations
• Linkingentities across models
• Traceability
• Model merging
• Model annotation
• …
Language mechanismsB
Multi-view managementB.1
Main MDE techniques:
• model weaving
• model transformation
(see req C.1)

24. MODEL WEAVING
Model weaving is a generic operationthat 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 courtesyof Jordi Cabot
Epsilon ModeLink

25. MDE provides different techniques to manage language and tools
extensibility
Example: UML profiling
However…
some languages maynot support extensibility by design
MDE also provides lightweight extension mechanisms (eg EMF Facet)
• withoutaffecting the original language
• withoutpollutingthe original models
• easily processableby humans and tools
Language mechanismsB
Extensibility andcustomizationB.2

26. MDE offers different facilities for building programmingframeworks
based on the structure of DSL metamodels
Two championimplementations:
Language mechanismsB
ProgrammingframeworkB.3
Eclipse Modeling Framework (EMF)
- full generation of Java domain classes
- XML model persistency
- models validation
- transactions
TEXO
EMFT Texo
- Generation of POJO classes
- Generation of ORM mappings
- Extensible code generation

27. Model transformationscan be used to automaticallygenerate analysis
models from architectural models
Tool supportC
AutomatedanalysisC.1
UML2LTSA
UML model Finite state processes
in LTSA tool

28. Model transformationscan be used to automaticallyobtain various types
of artifacts spanning throughoutthe development life-cycle
Weaving models can be used to define typed links between architectural
models, eg:
• for storing traceability information
eg, betweenSA elementsandrequirements, designdecisions,generated skeletoncode,
financialprospects,etc.
• for change impactanalysis whilemaintainingthesystem
• for managingarchitectural erosion
Tool supportC
Support for SA-centric designC.2

29. EXAMPLE
IvanoMalavolta,HenryMuccini,V.Smrithi Rekha(2011). SupportingArchitecturalDesignDecisions
EvolutionthroughModelDrivenEngineering.In Proceedings of the 3rd InternationalWorkshopon
Software Engineering for ResilientSystems (SERENE 2011), pp.63-77.

30. Tool supportC
Large views managementC.3
The 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

31. MDE techniques provide means to support the managementof different
versions of any kind of model
Also, MDE provides means to effectively matchand merge different
versions of one model, and to identify andsolve 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...

32. 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 sharingtools
Tool supportC
Support for knowledge managementC.6
Software
architects
continuous
alignment
Wiki-based
knowledge base
m1 m2
mn
access and
record AK
reason on the
architecture design
create, access,
and tune models ...
Baroni, Muccini, Malavolta, Woods(2014). ArchitectureDescription LeveragingModelDriven Engineeringand
Semantic Wikis. In SoftwareArchitecture(WICSA), 2014 IEEE/IFIP Conferenceon, pp. 251–254.

33. LET’S CHALLENGE AADL
AL 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 ✕ Notas first-class aspect
Extensibility andcustomization ✓ Ecosystemof AADL annexes
Programming framework ✓ Java-based,provided by EMF
Automated analysis ✓ Many tools available
Architecture-centric design ✕ Notas first-class aspect
Large view management ~ Only namespaces via AADL packages
Supportfor versioning
✓
Via any versioning system
(e.g., SVN plugin installable in OSATE)
Supportfor collaboration ~
Same as above, also no synchronous
collaboration
Knowledge management ✕ Notas first-class aspect

34. CONCLUSIONS

35. 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
35
18%
34%23%
25%
A(0-99)
B(100-999)
C(1000-4999)
D(5000-above)

36. MDE LIGHTWEIGHT EXTENSION TOOL
Image courtesyof Hugo Bruneliere (http://goo.gl/TzA7k6)

37. AVAILABLEMODEL TRANSFORMATION
LANGUAGES
http://en.wikipedia.org/wiki/Model_transformation_language

38. OTHER INSTRUMENTS FORMODELINGIN THE LARGE
EMF views Wires*
Epsilon ANT tasks

39. INVOLVED STAKEHOLDERS
Metamodeling expert
creates modelinglanguages (see metamodeling later)
develops the modelingenvironmentfor a language
develops analysis tools for the models
creates transformations for, e.g., code generation
creates the infrastructure for managingsets of interconnected models
…
SoftwareArchitect
models a specific system
runs analytical tools on the models
runs the transformations for obtainingadditional artifacts
discusses languageupdates with the metamodeling expert
…
CREATESthe infrastructure
USES the infrastructure