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
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
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
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
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
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)
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