The document discusses the evolution and challenges of architectural languages (ALs) over 25 years, highlighting the transition from first generation ALs, which focused on technological aspects, to second generation ALs that incorporate more complex modeling for configuration management and distribution. It emphasizes the need for flexible architectural frameworks, traceability in designs, and the ability to support various stakeholder concerns through the effective communication of software architecture. Finally, the lecture presents open research challenges aimed at bridging the gap between formal specifications and practical applications in software architecture.

1. Ivano Malavolta
ARCHITECTURAL
LANGUAGES

2. Roadmap
Architectural languages
Open research challenges

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

4. Historical View
25+ years back
I have to share with
architects the
architecture
solution I have in
mind.
What shall I use?
software architect

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

6. Historical View
core
concerns
Comp&
Con
Spec
Interco
nnectio
n
Compo
sition
Abstracti
on
Reusabil
ity
Configur
ation
Hetero
geneity
Analysi
s
Components and connectors
Distribution and configuration
Expected behaviour
Patterns, styles
HW/SW Deployment

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

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

9. 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

10. 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

11. C2 composition rules
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

12. C2 composition rules
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

13. C2 composition rules
3. There is no bound on the number of components or
connectors that may be attached to a single
connector.
Comp1 Comp2 Comp3
Permitted

14. C2 composition rules
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

15. C2 composition rules
5. Components can communicate only through
connectors
Comp1
Comp2
NOT Permitted
Permitted:
Following rule 4

16. 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

17. 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
• Inadequate tool support
• UML
– Video killed the radio star...

18. Historical View
core
concerns
Config.
managem
ent
Distributi
on
Product
lines
Styles
Different
domains
…
…

19. 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

20. 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

21. UML 2.0
• De facto standard software design language
– Developed by OMG
• A “Swiss Army Knife” of notations
• Has a number of architectural constructs

22. UML 2.0
Reasonably applicable to software architectures…
https://code.google.com/p/staff/wiki/SoaApplicationStruct

23. 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

24. AADL
• Architecture Analysis and Design Language
• 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 – real-time embedded systems

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

26. 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

27. Koala
model provides
interface
required
interface
Component type definition
Component instances
subcomponent
module switch
interface

28. Real Koala model

29. From a different perspective…
Formal
Pro:
.formal semantics
.computable
Cons:
.difficult to learn
.general lack of
industry-ready tools
UML-based
Pro:
.trained people
.same notation for SA
and design modeling
Cons:
.not a 100% fit
.complexity
Informal
Pro:
.of immediate use
.perfect for sketching
.communicative
Cons:
.Ambiguous
.not automated

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

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

32. 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

33. 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

34. 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

35. Open research challenges
on software architecture

36. Open research challenges
• Reconciling SA for analysis and communication
– how to manage formal specifications that can be also used for
communication?
Documents for
communications
Analytic artifactsvs

37. 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
...

38. Open research challenges
• Flexible architectural frameworks
– support for combining different views, viewpoints, languages, etc.
Architectural Assets
Repository
Viewpoints
Stakeholders
Model Kinds
System Concerns Architectural languages
Correspondences
Architecture
Description
B
Architecture
Description
C
Architecture
Description
A
Architecture
Framework

39. Open research challenges
• Traceability between requirements, design decisions, and
architecture

40. 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 (http://www.flyaq.it)

41. What this lecture means to you?
Software Architecture
what is essential about the system
w.r.t. some specific concern

42. Why software architecture?
Components and connectors
Distribution and configuration
Expected behaviour
Patterns, styles
HW/SW Deployment
Extra-functional properties
scalability, performance, testability,
security

43. Modern software architecture
Focus on views and viewpoints
looking at stakeholders and their concerns

44. 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

45. References

46. Contact
Ivano Malavolta |
Post-doc researcher
Gran Sasso Science Institute
iivanoo
ivano.malavolta@gssi.infn.it
www.ivanomalavolta.com