The document provides an overview of architectural languages (ALs) over 25 years, detailing their evolution from first to second generation, highlighting their essential features, concerns, and historical context. It discusses the need for clear documentation and automated analysis in software architecture, emphasizing the importance of component and connector specifications. The transition from early technology-focused ALs to more integrated modeling approaches is illustrated with examples like UML 2.0 and AADL, addressing their strengths and limitations.

1. Ivano Malavolta
ARCHITECTURAL
LANGUAGES
VRIJE
UNIVERSITEIT
AMSTERDAM

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

3. 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)
“An architectural system
representation is often essential
to the analysis and description of
the high-level properties of a
complex system” (GS1994)

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

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

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

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

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

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

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

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

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

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

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

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

16. A return…

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

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

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

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

21. UML 2.0
Reasonably applicable to software architectures…

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

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

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

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

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

27. Real Koala model

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

29. Today
http://www.di.univaq.it/malavolta/al/
100+ ALs
(better to say, languages that consider themselves to be ALs)

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

31. Readings
1. Bagheri, Hamid, et al. "Software architectural principles in
contemporary mobile software: from conception to practice." Journal
of Systems and Software 119 (2016): 31-44.
2. 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.

32. References

33. Acknowledgement
Some contents of this part of lecture extracted from Henry Muccini’s
lecture on architectural languages at the University of L’Aquila (Italy)

34. Contact
Ivano Malavolta |
Assistant professor
Vrije Universiteit Amsterdam
iivanoo
i.malavolta@vu.nl
www.ivanomalavolta.com