Received: 30 March 2017 Revised: 21 October 2017 Accepted: 3 December 2017

DOI: 10.1002/spe.2561

RESEARCH ARTICLE

The analysis of architectural languages for the needs of

practitioners

Mert Ozkaya

Department of Computer Engineering,

Altinbas University/Istanbul
Kemerburgaz University, Istanbul,Turkey
Correspondence
Mert Ozkaya, Department of Computer
Engineering, Altinbas University,
Istanbul, Turkey.
Email: mert.ozkaya@kemerburgaz.edu.tr
Funding information
Scientific and Technological Research
Council of Turkey (TUBITAK),
Grant/Award Number: 215E159
Summary
Architectural languages (ALs) have attracted much attention as the modeling
notations for specifying and reasoning about important design decisions. In this
study, 124 different existing ALs have been analyzed for a set of requirements
that are crucial for practitioners. These requirements are concerned with lan-
guage definition, language features, and tool support. Some of the important
findings obtained from the analysis are as follows: (1) performance is the top
popular nonfunctional requirement supported by ALs; (2) no ALs offer both
textual and visual notation sets, one of which could be used independently;
(3) process algebras are the top preferred formal method by formal ALs; (4) the
physical, deployment, and operational viewpoints are rarely supported by ALs;
(5) the top preferred extension mechanism of the extensible ALs is XML for
syntax extension; (6) Java is the top preferred programming language in gen-
erating software code; (7) the exhaustive model checking is the top preferred
automated analysis method; (8) the logic-based formal techniques are so popular
in specifying system requirements; (9) among the analysis properties consid-
ered, consistency is the top supported property for the automated checking; and
(10) most ALs do not provide any discussion platform (eg, forums). Hence, these
findings can be used by the new AL developers in addressing the needs of practi-
tioners and bridging the gaps in the field. Practitioners can also use the findings
to find out about the existing ALs and compare them to choose the one(s) that
suits their needs best.

K E Y WO R D S
ADLs, architectural languages, software architectures, survey, UML

1 I N T RO DU CT ION

The notion of software architecture has been proposed in the early 1990s by Perry and Wolf,1 who view software architec-
tures as a set of decisions about the decompositions of software systems into independent components, the interactions
among the components, and any constraint needed to meet system requirements. Since then, the definition of software
architectures has evolved so as to maximize its benefits for the specifications of software systems. Allen and Garlan2
introduced the notion of complex architectural connectors, which are used to specify the high-level complex interac-
tion protocols for the components. Kruchten3 considers software architectures in terms of 4 separate views—logical,
process, physical, and development—and proposed an iterative effort for these 4 phases that are refined in each iteration

Softw Pract Exper. 2018;48:985–1018. wileyonlinelibrary.com/journal/spe Copyright © 2018 John Wiley & Sons, Ltd. 985
986 OZKAYA

until the architecture design reaches a satisfactory level. Taylor et al4 focus on the set of principal design decisions as
the software architectures of systems, which need to be specified and analyzed for meeting system requirements. These
design decisions include system structures, behaviors, interactions, nonfunctional properties, and concurrency issues
(eg, synchronization and threading).
Software architectures are modeled using architecture modeling notations. These notations can be as simple as natural
languages and simple boxes/lines or architectural languages (ALs) with well-defined syntax and semantics. Natural lan-
guages (eg, English) offer a textual way of specifying design decisions under no constraints at all. While natural languages
are supported by many text editors that can be used for specifying the design decisions, none of those text editors enable the
analysis of the specifications or any other operations such as code generation. Simple boxes/lines offer a visual notation
set that can be used with no constraints either. Practitioners can use any graphical editor (eg, Microsoft Office Power-
Point) to specify their design decisions, but again, they cannot be processed for, eg, analysis and code generation. ALs
have been proposed since the early 1990s, which offer precise architecture-oriented notation sets for specifying software
architectures (eg, components, connectors, ports, and roles) with well-defined syntax and semantics.
The topic of ALs has been so active since the 1990s, which led to many different languages.5-9 ALs can either have a
general-purpose scope that can be used to specify any type of systems (eg, Wright,10 Darwin,11,12 and Rapide13 ) or offer
notations that are specific to particular domains (eg, AADL14,15 for embedded real-time systems, Koala16 for consumer elec-
tronics, π-net ADL17 for multiagent systems, and Mobis18 for mobile systems). ALs are essentially distinguished in terms
of several aspects such as its textual/visual notation set, support for nonfunctional requirements, semantics definition,
multiple-viewpoint support, extensibility, formal verification, tool support, etc.

1.1 Paper motivation goal

The topic of ALs has been shown great interest by the software architecture community, and the number of ALs has been
increasing swiftly. Indeed, Malavolta et al keep an up-to-date list of the existing ALs, and they have thus far determined
tens of different ALs.19 However, it is not so easy for practitioners to compare the ALs with each other for the requirements
of their interest and to choose the one(s) that best suits their needs. There have been many surveys conducted on ALs so
far (see Section 9). Those studies either consider so few ALs or ignore the needs of practitioners and do not try to learn
to what extent the ALs satisfy practitioners' needs. This gap also prevents the software architecture community from
understanding the current standing of the ALs in terms of the important language requirements for practitioners.
Therefore, in this study, the goal is to analyze all the existing ALs that have been determined by Malavolta et al19 for a
set of requirements that are highly important for practitioners. By doing so, it is also aimed to aid the new AL developers
in comparing the existing ALs and determining their weaknesses and strengths in terms of the support for a number of
requirements.

1.2 Paper structure

In the rest of this paper, the language requirements that are considered for the analysis of the existing ALs are discussed
firstly in Section 2. In Section 3, the methods used in selecting the ALs to be analyzed, gathering the requirements data,
and analyzing those requirements data are discussed. Next, the analysis of the ALs is presented in 3 sections, one for each
group of requirements, ie, Sections 4, 5, and 6 for language definition, language features, and tool support, respectively.
After discussing the analysis results, the summary of the findings is given for each group of requirements in Section 7.
In Section 8, threats against the validity of the analysis results are discussed. Lastly, the conclusion and future works are
discussed in Section 10.

2 THE REQUIREMENTS FOR ARCHITECTURAL LANGUAGES

Lago et al20 have recently proposed a framework of language requirements upon Malavolta et al's survey21 that has
been conducted on 48 practitioners from 40 IT companies and aimed at understanding practitioners' needs from ALs.
Lago et al's framework is therefore the result of the feedback/comments received from the practitioners about their expec-
tations from ALs. In their framework, Lago et al categorize the language requirements into 3 groups, ie, (1) language
definition, (2) language features, and (3) tool support.
OZKAYA 987

2.1 Language definition

Language definition is concerned with defining the language syntax and semantics, which are addressed in 3 aspects:
(1) nonfunctional properties, (2) textual and visual notation sets, and (3) formal semantics. Nonfunctional properties
(eg, reliability, security, and performance) can be specified as part of the software architecture specifications and then
analyzed to ensure their satisfaction for the software systems specified. The notation set of an AL can be either textual or
visual (diagrammatic), either of which is preferred by practitioners depending on their experience and needs. Lastly, the
semantics of an AL are defined either formally or informally. Formal semantics are defined using mathematically based
formal techniques (eg, π-calculus22 and CSP23 ), whereas informal semantics are generally defined using plain English.

2.2 Language features

Language features are concerned with specifying, modifying, and maintaining software architectures. Language features
are also addressed in 3 aspects: (1) multiple viewpoints, (2) extensibility and customization, and (3) programming frame-
work. Multiple viewpoints are concerned with managing the complexity of software architectures by specifying them in
terms of separate views that each document the design decisions from a different perspective. Kruchten3 has proposed
the notion of viewpoints, which has later on been extended by many seminal works, eg, Taylor et al's4 and Rozanski and
Woods's.24 Given these works, the logical, information, physical, deployment, behavior, concurrency, development, and
operational viewpoints are believed to be commonly used by practitioners and, thus, focused on in this study. Extensi-
bility and customization is needed for extending the ALs with some desired capabilities, eg, domain-specific elements,
analysis support, and support for different views. Inspired by the work of Di Ruscio et al,25 in this study, 2 types of exten-
sion mechanisms are considered, which are the syntax and semantic extensions. Lastly, the programming framework is
concerned with the consideration of a modeling environment that allows for specifying, modifying, and maintaining soft-
ware architectures and then using the specifications for other purposes such as syntax and semantics error checking and
software implementation code generation.

2.3 Tool support

Tool support is addressed in terms of the following requirements: (1) automated analysis, (2) large-view management,
(3) support for collaboration, (4) support for versioning, (5) support for knowledge management, and (6) support for
software architecture–centric design. The automated analysis is considered as the automated checking for the analysis
goals proposed by Taylor et al4 : completeness, consistency, correctness, and compatibility. In addition, other important
analysis capabilities are also considered, eg, exhaustive model checking, simulation, and user-defined requirements. The
large-view management deals with the techniques and methods for specifying large and complex views of software archi-
tectures in a more manageable way that can easily be understood and analyzed. The support for collaboration deals with
specifying software architectures collaboratively that allows for practitioners at physically different locations to write the
specifications synchronously or asynchronously. The support for versioning deals with keeping a repository of the soft-
ware architecture specifications with some version details. The support for knowledge management is about publishing
via some website relevant information about the AL (eg, tools and case studies, publications, and user manuals) and
providing some discussion platforms (eg, forums) for the practitioners to exchange ideas with each other and find solu-
tions to their language-related problems. Lastly, the support for software architecture–centric design is concerned with
the tools for integrating the software architecture level of design with other stages of software development, including
requirements specification and analysis, low-level software design, and software implementation.

3 R E S E A RC H METH O D O LO GY

As aforementioned, the list of ALs analyzed in this study has been retrieved from Malavolta et al's up-to-date list of
existing ALs.19 Malavolta et al have thus far published here 125 different ALs and provide their resource links. Note that
some of the ALs in Malavolta et al's list have been the extensions of some other ALs in the same list. Table 1 shows those
ALs that extend others. Hence, all these ALs have been considered in this study (except the XSSA AL that lacks in any
English-written resources). Moreover, the XCD AL26 contributed by the author has also been added to the list.
988 OZKAYA

TABLE 1 The architectural languages

(ALs) that extend some other ALs
Extended ALs Extending ALs
Wright10 AWright27
Prisma28 Ambient-Prisma29,30
MetaH31 AADL14,15 , East-ADL32
XADL33 Secure XADL34
Acme35,36 Aspectual Acme37
Korrigan38 KADL39
C240 C2SADEL41 , XC242
Darwin11,12 RADL43
Leda44 AspectLeda45
Fractal46,47 FAC48
Rapide13 AO-Rapide49

For each AL to be analyzed, a folder has been created, which consists of a number of subfolders. Firstly, the web address
of the AL has been recoded (if any) in one of the subfolders. Note that each AL is searched via Google to access any website
that exposes the supporting materials of the AL. In another subfolder, the publications about the AL that are accessible
via our IEEE/ACM/Springer-link/Elsevier/Wiley accounts have been collected. The publications herein have been either
found out via the AL's website or via Google Scholar search. Any technical reports/theses that are freely downloadable
have also been added to the subfolder. In another subfolder, the supporting toolset (if any) has been downloaded to be
able to experiment with the AL. Lastly, the user manuals of the ALs (if any) have been retrieved and stored in a subfolder.
The next goal was to determine the requirements to be used for the analysis of the ALs. As discussed in Section 2,
Lago et al's20 requirements have been used in this study, which are grouped as language definition, language features, and
tool support. However, some of the requirements may not be used as they are for the analysis of the ALs. Indeed, they
may need to be decomposed into subrequirements for addressing the requirements precisely. For instance, nonfunctional
requirements and formal semantics can be used as they are. However, multiple viewpoints are decomposed into logical,
information, physical, deployment, behavior, concurrency, development, and operational views. In the case of decom-
positions, the requirements descriptions of Lago et al20 have been used, which generally tell about the subrequirements
that need to be focused in on. For some requirements whose requirements descriptions are not found adequate (eg, mul-
tiple viewpoints and analysis properties), the seminal software architecture publications (including journal/conference
papers and books) about the requirements have been consulted (eg, the works of Taylor et al4 for analysis properties and
Rozanski and Woods24 for multiple viewpoints). Table 2 shows the requirements that have been further decomposed.
After identifying the language requirements, each AL has been analyzed for those requirements in several iterations.
In the first iteration, the publications of each AL have been gone through to be familiar with the characteristics of the AL.
In cases where theoretical knowledge is not so useful in understanding the AL's characteristics, the AL's toolset has been
installed (if available), and the AL has been experimented with some simple case studies (eg, client-server and shared
data). Then, a table has been created in an Excel sheet for storing the data to be collected for the ALs, with the column
size equal to the number of requirements and the row size equal to the number of ALs. In the next iteration, each AL's
publications have been gone through for the requirements of interest, and the gathered data for each requirement are
stored in the Excel table. The Excel table has also been checked in another iteration to determine any missing data for each
AL. If any detected, the AL developers have been contacted by email to determine the AL's support for the corresponding
requirement(s). To minimize any wrong interpretation, each AL has been gone through again, and the support for the
requirements has been recorded in another Excel table. The 2 Excel tables have been compared for any discrepancy.
After gathering the data of the ALs in several iterations, the ALs' data have been analyzed. Initially, for each group
of requirements (ie, language definition, language features, and tool support), each requirement of that group has been
analyzed individually using the MS Office Excel* and SPSS† tools. Then, again with the same tools, the requirements of
that group have been analyzed together to focus on the correlations between different related requirements of the same

* https://products.office.com/en-us/excel
†
http://www.spss.com.hk/
OZKAYA 989

TABLE 2 The requirements that can be decomposed into subrequirements

Requirement Group Requirement Subrequirements
Nonfunctional NA
Language requirements
definition Notation set Textual and visual
Formal semantics NA
Multiple Logical, information, physical, deployment, behavior,
viewpoints concurrency, development, and operational
Language Extensibility and
features customization Syntax extension, semantic extension
Programming
framework Modeling editor and software code generation
Automated
analysis Consistency, completeness, correctness, and compatibility
Large-view
Tool management NA
support Versioning NA
Knowledge NA
management
Collaboration Synchronous and asynchronous
Software architecture NA
–centric design
Abbreviation: NA, not applicable.

group. Lastly, the requirements of the different groups have been analyzed together to determine any correlation between
the requirements of the different groups.

4 LANGUAGE DEFINITION A NALYSIS

4.1 Nonfunctional properties

Nonfunctional properties describe the quality requirements for a software system, eg, performance and security require-
ments, which are essentially specified as part of the system requirement specifications reports.50 Nonfunctional require-
ment specifications can also be used during the architectural design of software systems, and the design decisions specified
can be checked against the nonfunctional requirement specifications.
Table 3 shows the (1) 26 ALs (21%) that support nonfunctional requirements, (2) the particular nonfunctional require-
ment(s) supported, and (3) the notation used for specifying the nonfunctional requirements. Hence, apparently, 16 ALs
use informal modeling (sub)notations for specifying nonfunctional requirements, which can be either textual or visual
depending on the notation set of the languages. Four of those ALs (ie, AO-ADL,51 AWright,27 Prisma,28 and Aspectual
Acme37 ) offer aspect-oriented notation sets and allow practitioners to specify any cross-cutting nonfunctional require-
ment in terms of aspects. Another 10 ALs use formal methods for specifying nonfunctional requirements precisely,
which can then be formally analyzed via model checkers (or theorem provers). These formal methods are π-calculus,22
real-time logic,52 finite-state machine, timed automata, graphical model behavior,53 Design by Contract (DbC),54 and
Object Constraint Language (OCL).55
Figure 1 shows the percentages of different nonfunctional requirements that are supported by the ALs given in Table 3.
Performance (29%) is the top supported nonfunctional property, followed by the reliability (17%) and security (12%) prop-
erties. Note that 14% of the ALs support the specifications of any type of nonfunctional requirements via the use of aspects
and formal methods.

4.2 Textual and visual notation sets

ALs can have either a textual notation set (ie, code-like) or a visual notation set (ie, graphical). Practitioners may prefer to
use either one of them depending on their experiences. If they are expert in the field, they may prefer to use a textual nota-
tion set for quick modeling. Note also that textual notation sets let practitioners specify really large and complex systems
in a reasonable space. Visual notation sets may essentially be preferred by practitioners who do not have that experience
990 OZKAYA

TABLE 3 The architectural languages that support nonfunctional properties

Nonfunctional Properties Notation
AADL14,15 Performance, schedulability, and reliability -Annex
-Informal notation
ABACUS56 Performance and reliability Informal notation
Primitive-C57 Safety security, performance, portability Informal notation
AO-ADL51 General Aspect-oriented notation
AWright27 General Aspect-oriented
CBabel58,59 General QoS contracts
Clara60 Timeliness Timed Petri nets
ConMoto61 General π-calculus
Cosa62 General Informal notation
DADL63 Performance Informal notation
Drems ML64 Security, schedulability, network resource, performance Object Constraint Language
East ADL32 Safety, performance -Extension packages
-Informal notation
Modechart65,66 Performance Real-time logic
Palladio67 Performance Informal graphical notation
Prisma28 General Aspect-oriented notation
Aspectual Acme37 General Aspect-oriented notation
RADL43 Reliability Finite-state machine
SADL68 Schedulability Informal graphical notation
SARA53 Performance Graphical model behavior (GMB)
ScudADL69,70 Resource consumption π-calculus
Secure XADL34 Security XML-based notation
TADL71 Safety, performance, security, availability, and reliability Timed automata
UNAS/SALE72 Performance, reliability, and scalability Informal graphical notation
X-MAN73,74 Reliability Design-by-Contract–based notation
MetaH31 Schedulability, reliability, and security Informal graphical notation
Stratus ML75 Availability, performance Informal graphical notation

FIGURE 1 The percentages of the architectural languages that support different nonfunctional properties [Colour figure can be viewed at
wileyonlinelibrary.com]

in architectural modeling and, thus, prefer to express their software architectures by drawing visual diagrams (as is done
with the UML language). Visual notation sets can also be preferred if the main intent is effective communication.
For an AL to be usable, it is desired to have both a textual notation set and a visual notation set that can be used by
practitioners independently depending on their experiences and needs. The analysis results are depicted in Figure 2,
which shows that 42 ALs (34%) offer both textual and visual notation sets. Table 4 groups the ALs that have both textual
and visual notation sets based on their release years. In the Figure, 49 ALs (39%) just offer a textual notation set, whereas
33 ALs (27%) offer a visual notation set only.
OZKAYA 991

TABLE 4 The architectural languages that offer textual and visual notation
sets together
Architectural Languages Release Years
SARA53 1986
Artek,76 Acme,35,36 C2SADL,41 Darwin,11,12 UniCon,77
SADL (Structure)78 1994-1997
ADML,79 Koala,16 Olan,80,81 π-space,82 AEmilia,83,84
Zeta,85 ComUnity,86,87 DAOP-ADL,88 Korrigan,89
AADL,14,15 Mae,90 π-ADL,91 Service-ADL92 2000-2004
ADLARS,93 Clara,60 East-ADL,32 π-net ADL,17
SafArchie,94 Secure X-ADL,34 AspectualAcme,37
Backbone,95 EAADL,96 Prisma,28,97 Ambient-Prisma,29,30
ALI,98,99 WADL,100 DEMO,101 DiaSpec,102 Dedal,103
EADL,104,105 AO-ADL,51 MontiArc,104,105 C3,106
DPD,107 Primitive-C57 2005-2012

FIGURE 2 The percentages of the architectural languages that offer textual/visual notation set [Colour figure can be viewed at
wileyonlinelibrary.com]

4.3 Formal semantics

The semantics of an AL can be defined either informally or formally. The informal semantics of an AL are defined sim-
ply in plain English. Hence, the informal semantics of languages may not always be understood clearly and, thus, lead to
ambiguous specifications that are misinterpreted by different stakeholders. The formal semantics of an AL are defined pre-
cisely using the mathematically based formal methods. Such formal methods can be in different forms, ie, operational,108
denotational,109 and axiomatic.110 Moreover, the semantics of some ALs are defined using the formal specification lan-
guages (eg, π-calculus,22 CSP,23 Petri nets,111 Z notation,112 rewriting logic,113 and temporal logic114 ). The biggest advantage
of the formally defined ALs is that they are precise languages that allow for the specifications of detailed and exact software
architectures. Formally defined ALs also enable the exhaustive analysis of software architectures using model checkers
that are based on mathematical proofs.
Table 5 shows the 60 ALs (48%) that are formally defined and the formal methods used in defining their formal seman-
tics. Hence, apparently, the process algebra–based formal specification languages are the top preferred choice of AL
developers. Indeed, 12 ALs use π-calculus, and 6 ALs use one of the CSP, FSP, Alloy, Anna, and ProMeLa process alge-
bras. Eight ALs use the logic-based formal methods (eg, temporal logic,114 first-order logic,115 transaction frame logic,116
real-time logic,52 and formal theory of rational action117 ). Furthermore, 7 ALs use the operational semantics108 , and 3 ALs
use automated-based techniques (eg, ω-automata,118 I/O automata,119 and automata theory120 ). Formal methods such as
Petri nets111 and Z notation112 are preferred by 2-3 ALs.
992 OZKAYA

TABLE 5 The architectural languages that have formal semantics and

the formal methods in which their formal semantics are defined
Architectural Languages Formal Semantics
Darwin,11,12 LEDA,44 π-space,82
PiLar,121 π-ADL,91 ConMoto,61
π-net ADL,17 Prisma,28,97
AspectLEDA,45 SOADL,122
ScudADL,69,70 ACDL123 π-calculus22
OSAN,124 Jacal125 Petri nets111
XCD26 ProMeLa126
Backbone95 Alloy127
CBabel58,59 Rewriting logic113
SARA53 Graph Model of Behavior128
Modechart65,66 Real-time logic52
Lileanna129 Anna130
Resolve131 Natural reasoning132
Weaves133 Classic134
C2SADEL41 Type theory135
Cham-ADL136 Chemical Abstract Machine137
ASDL,138,139 OOADL,140 C240 Z notation112
Aster141 Larch Prover142
Rapide13 Event patterns
AO-Rapide49 Event patterns and coalgebra143
Polis,144,145 PADL,146 Korrigan,38
Clara,60 SkwyRL,147 ADR,148
Olan80,81 Operational semantics108
Wright,10 AWright27 CSP23
GenVoca149 Constraint satisfaction problem150
AEmilia83,84 Timed process algebra (EMPA)151
ArchJava152 ArchFJ153
Metaoasis154 Transaction Frame Logic116
Mobis18 Tuple spaces155
RADL43 Automata theory120
SOFA156,157 Behavior protocol156,157
Zeta85 Formal theory of rational action117
CommUnity86,87 Category theory158
ArchiTrio159 Higher-order TRIO160
XYZ/ADL,161 AC2 ADL162 Temporal logic114
KADL39 Symbolic transition system
Ambient-Prisma29 Ambient calculus163
Maude164 Real-Time Maude164
TADL71 Set theory
EADL165 ω-Automata118
MontiArc104,105 I/O Automata119
X-Man,73,74 SADL (Structure)78 First-order logic115
Connect166 FSP167

4.4 Discussion
As shown in Table 3, 26 different ALs (21%) support the specifications of one or more of the following nonfunctional
properties: performance, security, reliability, safety, availability, schedulability, and resource consumption. However,
specifying nonfunctional properties would not be so useful unless it was possible to analyze the specified design deci-
sions (eg, system behaviors and interaction) against the property specifications. When the automated analysis was also
OZKAYA 993

TABLE 6 The architectural languages that support the automated analysis for
nonfunctional properties
Architectural Languages Nonfunctional Properties
AADL14,15 Performance, schedulability, security,
dependability, and reliability
CBabel58,59 Via a QoS language59
Clara60 Performance
ConMoto61 Any
Drems ML64 Security, schedulability, resource consumption,
performance
East ADL32 Safety, performance
Palladio67 Performance
TADL71 Safety, security, availability, and reliability
UNAS/SALE72 Performance, reliability, and scalability

considered, only the 9 ALs shown in Table 6 have been observed to support the automated analysis of the design decisions
for the nonfunctional requirements.
The notation set is also important for the practical use of ALs, which can be defined either textually or visually. While
a textual notation set is more preferred for quick coding, a visual notation set is preferred for better communication.
However, none of the ALs have been found out to offer cleanly separate textual and visual notation sets, one of which can
be preferred by practitioners depending on their needs. Among the 42 ALs (34%) given in Table 4 that support both the
textual and visual notation sets, their textual and visual notation sets are complementary to each other. That is, those ALs
use the visual notation set for the structural views and the textual notation set for the behavioral views.
Regarding the semantics of the ALs, 60 different ALs (48%) given in Table 5 have formal semantics that are based
on mathematical formal methods. Process algebra–based formal specification languages (eg, π-calculus, FSP, CSP, Alloy,
ProMeLa, EMPA, and Anna) are the top preferred formal methods used for defining the formal semantics of ALs. Note,
however, that while formally defined ALs are indeed helpful for the precise and exhaustively analyzable specifications of
software architectures, practitioners rarely use them. As Malavolta et al's survey indicates,21 practitioners find the process
algebra–based ALs as requiring a steep learning curve due to their mathematical syntax that also requires concurrent
programming.

5 LANGUAGE FEATURES ANALYSIS

5.1 Multiple viewpoints

Multiple viewpoints are considered in this study in terms of the logical, information, physical, deployment, behavior,
concurrency, development, and operational viewpoints. The logical viewpoint describes the logical components and con-
nectors that together compose a software system. The information viewpoint describes how the components store their
data, change their data, and exchange them between each other. The physical viewpoint describes the hardware compo-
nents that are needed for specifying the devices in which the software components will be located and the relationships
between those devices. The deployment viewpoint describes the mapping between the hardware components and the log-
ical components. The behavioral viewpoint describes the behaviors of system components and any complex interaction
mechanism (ie, interaction protocols). The concurrency view describes the concurrency-related issues, such as threading
and synchronization between components. The development viewpoint describes how the components and connectors
are to be implemented and tested. Lastly, the operational viewpoint describes how the software system that is specified
will be run in its environment, including the plans for installing the system, any configuration, support for users, system
monitoring, and backup/restore issues.
According to the results, all 113 ALs (91%) support the logical viewpoint, and 96 of them (78%) also support the infor-
mation viewpoint. When the behavior viewpoint is also considered, 59 ALs (46%) allow for the behavior specifications of
software architectures. When the concurrency viewpoint is considered together with the logical and behavior viewpoints,
only 58 ALs (45%) that are shown in Table 7 support the concurrent behavior specifications of components. Moreover,
32 of those 58 ALs that are shown in Table 8 support the development viewpoint and allow for generating software code
from the concurrent behavior specifications.
994 OZKAYA

TABLE 7 The architectural languages that support logical, information, behavior,

and concurrent viewpoints
Architectural Languages Release Years
SARA53 1986
Statemate,168,169 Modechart,65,66 MetaH,31 OCA,170,171
UNAS/SALE,72 Cham-ADL,136 Darwin,11,12 UML172 1990-1995
ASDL,138,139 Rapide,13 Jacal,125 Polis,144,145 Wright,10
DADL,63 Leda,44 PADL,146 π-Space82 1996-2000
ABC/ADL,173 AEmilia,83 Pilar,121 SADL,68
Community,86,87 DAOP-ADL,88 Korrigan,89
AADL,14,15 COSA,62 ADLARS,93 East-ADL,32
CBabel,58,59 Clara,60 π-net ADL,17 SafArchie,94 AO-Rapide49 2001-2005
EAADL,96 Fractal,46,47 Little-JIL,174 KADL,39
Prisma,28,97 FAC,48 Ambient-Prisma,29,30 OSAN,124
AC2-ADL,162 AWright,27 ExSAVN,175
Maude,164 TADL,71 Palladio,67 ScudADL,69,70
ACDL,123 Archface,176 EADL,165 AO-ADL,51
MontiArc,104,105 Connect,166 Drems ML,64
Primitive-C,57 Stratus ML75 2006-2015

TABLE 8 The architectural languages that support logical, information,

behavior, concurrent, and development viewpoints
Architectural Languages Release Years
SARA53 1986
Statemate,168,169 Modechart,65,66 MetaH,31 OCA,170,171
UNAS/SALE,72 Darwin11,12 1990-1995
DADL,63 Leda44 1996-2000
DAOP-ADL,88 Korrigan,89 AADL,14,15 East-ADL,32
CBabel,58,59 Clara60 2001-2005
EAADL,96 Fractal,46,47 Little-JIL,174 KADL,39
Prisma,28,97 FAC,48 Ambient-Prisma,29,30 OSAN,124
Maude,164 Palladio,67 Archface,176 EADL,165
AO-ADL,51 MontiArc,104,105 Drems ML,64 Stratus ML75 2006-2015

TABLE 9 The architectural languages that support physical and

deployment viewpoints
Architectural Languages Release Years
MetaH,31 UNAS/SALE,72 UML172 1994-1995
AIL Transport,177 AADL,14,15 Abacus,56 East-ADL,32
FuseJ,178 SafArchie,94 Con Moto61 2002-2005
EAADL,96 Ambient-Prisma,29,30 Palladio,67
Dedal,103 EADL,104,105 Autosar,179 Drems ML,64 C3,106
DEMO101 2006-2015

Concerning the physical and deployment viewpoints, only the 19 ALs (15%) that are shown in Table 9 support the
specifications of hardware architectures and the mapping of the logical components to the hardware components. Like-
wise, the operational viewpoint is not popular among the ALs either. Indeed, as shown in Table 10, only 13 ALs consider
specifying the operational issues that occur while the system is in use.
When all the viewpoints in question are considered together, only the AADL,14,15 Palladio,67 and Ambient-Prisma29
ALs support all the logical, information, physical, deployment, behavior, concurrency, development, and operational
viewpoints together.

5.2 Extensibility and customization

Extensibility and customization herein is concerned with the ability of extending a language with the requirements of
interest. This includes the support for new viewpoints, adding domain-specific features (eg, specifying and analyzing
OZKAYA 995

TABLE 10 The architectural languages that

support the operational viewpoint
Architectural Languages Release Year
AIL Transport177 2002
SOFA156,157 2002
HappyWork180 2004
ABACUS56 2005
AADL14,15 2006
FAC48 2006
FRACTAL46,47 2006
Autosar179 2008
ArchiMate181,182 2009
Palladio67 2009
Ambient-Prisma29,30 2010
Dedal103 2010
Stratus ML75 2015

TABLE 11 The extensible architectural languages and their extension mechanisms

Architectural Languages Extension Mechanism Syntax Extension Semantic Extension
AADL,14,15 EAADL,96 East-ADL32 Annex libraries X
MontiArc104,105 Language inheritance X
Acme,35,36 Aspectual Acme,37 Armani,183 Property annotation X
ASDL (Structure)184
Secure X-ADL,34 X-ADL,42 XC2,42 Mae,90 XML X
ADML,79 XAcme185
SOFA156,157 Aspect-oriented development X
Korrigan,89 LISA186 Tool support X
UML,172 ArchiMate181,182 UML profiles and stereotypes X
SADL (Structure)78 Subtyping and algebraic extension X X

nonfunctional properties), extending tool support with the necessary facilities (eg, formal analysis, simulation, and
code generation), adding/removing new elements (eg, complex connectors), or introducing a subnotation (eg, a visual
notation set).
Table 11 shows the 20 different ALs (16%) that support extensibility and customization and also groups the extensible
ALs by the extension mechanisms employed and the type of the extension. Note that 2 types of extension have been con-
sidered herein, which are the syntax and semantic extensions. The syntax extensions are concerned with extending the
language syntax by, eg, adding new architectural elements without changing the language semantics, removing any unde-
sired elements, or introducing new syntax rules for the existing elements. The semantic extensions promote extending the
language semantics in various ways, including the support for new viewpoints (eg, formal behavior specifications, con-
currency, etc), the support for nonfunctional properties (eg, performance and security), and the support for interaction
protocols for connectors.
Hence, apparently, East-ADL and its extensions (ie, AADL and EAADL) use annex documents, which can be used to
extend the language semantics by introducing new viewpoints, eg, formal behavior specification, nonfunctional property
specifications, concurrency, etc. MontiArc offered the language inheritance through which the syntax of the language
can be extended with new rules. Note that MontiArc does not support semantic extension. Acme and its extensions
(ie, Aspectual Acme and Armani) offer the property construct that can be attached to the architectural elements for
extending their semantics (eg, the interaction protocols, nonfunctional properties). Likewise, ASDL (Structure) is another
AL that offers a property annotation for the semantic extension. There are also some XML-based ALs that benefit the
XML's extensible nature and allow practitioners to specify software architectures using XML and easily extend the syn-
tax of the architectural elements, such as adding new component types and adding a data structure within an existing
component type. Note, however, that XML-based ALs do not support semantic extension. SOFA is also offered as an exten-
sible AL, which uses aspects for extending components for different views or platforms. Indeed, SOFA has already been
extended for dynamic architectures and for different execution platforms including Java ME and Lejos NXJ platforms‡ .

‡
SOFA extensions can be obtained here: http://sofa.ow2.org/extensions/index.html
996 OZKAYA

Korrigan and Lisa are the 2 languages that offer extensible toolsets, which can be extended for generating code in differ-
ent programming languages or formal methods without changing the language semantics. The tools can also be extended
with some new modules (eg, syntax/semantics checker). ArchiMate uses UML's profile and stereotype notations through
which any domain-specific or platform-specific elements can be introduced. Note that such elements derive from UML's
structure diagram (eg, class diagram and component diagram), and it is not possible to introduce a semantically new type
of diagram. Lastly, SADL (Structure) supports subtyping, which enables to define a syntactically new type that derives
from the existing predefined types. For semantic extension, SADL allows for defining the semantics of connectors via the
use of the temporal logic of actions.187

5.3 Programming framework

The programming framework has to do with the modeling editors of ALs that can be used for specifying and modifying
the different views that the ALs support and for performing some further operations such as software implementa-
tion code generation. As shown in Table 12, 70 ALs (56%) offer a modeling editor for specifying software architectures
textually/visually and checking them against the syntax and semantics rules of the ALs. Moreover, 45 ALs among the 70
given in Table 13 also support the automated code generation from the software architecture specifications. Figure 3 also
depicts the percentages of those ALs that support each programming language. Hence, apparently, code generation in
Java has the highest proportion, which is followed by C (20%), C++ (11%), and Ada (11%).

TABLE 12 The architectural languages that offer a programming framework

Architectural Languages Release Years
SARA53 1986
STATEMATE,168,169 Kaptur,188,189 Modechart,65,66 Aesop,190 1990-1994
Artek,76 OCA,170,171 Resolve,131 UNAS/SALE,72 MetaH31
Acme,35,36 C2SADEL,41 Darwin,11,12 UML,172 UniCon,77 1995-1999
Gestalt,191 Rapide,13 Room,192 DADL,63 Jacal,125 Polis,144,145
Wright,10 C2SADEL,41 GenVoca,149 Leda,44 UniCon77
Korrigan,38 AADL,14,15 HappyWork,180 Mae,90 π-ADL,91 2000-2004
XC2,42 ABC/ADL,173 Knit,193 Koala16
ABACUS,56 ArchiMate,181,182 Cbabel,58,59 Clara,60 2005
Con Moto,61 East-ADL,32 FuseJ,178 SafArchie,94 XADL33
Backbone,95 Fractal,46,47 Kadl,39 Little-Jil,174 Prisma,28,97 2006
Aspectual Acme37
Ambient-PRISMA,29,30 AspectLEDA,45 FAC,48 OSAN124 2007
ADLV,194,195 Maude,164 TADL,71 WADL100 2008
Archface,176 Clacs,196,197 Dedal,103 EADL,165 LISA186 2010
AO-ADL,51 Autosar,179 MontiArc,104,105 X-MAN,73,74 XCD,26
DREMS-ML,64 Stratus ML75 2011-2015

TABLE 13 The architectural languages that support automated code

generation and the programming languages supported
Architectural Languages Programming
Language
C2SADEL,41 XC2,42 ArchJava,152 SOFA,156,157 Java
Zeta,85 π-ADL,91 X-ADL,34 Backbone,95 Fractal,46,47
KADL,39 AspectLeda,45 FAC,48 DiaSpec,102 Palladio,67
ArchFace,176 Korrigan,38 MontiArc,104,105 ABC/ADL,173
Dedal,103 Lisa,186 FuseJ,178 AO-ADL,51 Resolve131
UniCon,77 Gestalt,191 Knit,193 Koala,16 Autosar,179 C
X-Man,73,74 Statemate,168,169 OCA,170,171 ADLV194,195
UNAS/SALE,72 MetaH,31 Resolve,131 Statemate,168,169 Ada
OCA170,171
ADLV,194,195 Aesop,190 Room,192 Drems ML,64 Korrigan89 C++
Ambient-Prisma,29,30 Prisma,28,97 LISA186 C#
OZKAYA 997

FIGURE 3 The percentages of the programming languages that are supported by the architectural languages for code generation [Colour
figure can be viewed at wileyonlinelibrary.com]

5.4 Discussion
Supporting the software architecture specifications in terms of multiple viewpoints is important for the practical use
of ALs among the practitioners with different design goals. Focusing on the logical, information, behavior, develop-
ment, physical, deployment, concurrency, and operational viewpoints, the analysis of the existing ALs just reveals 3 ALs
(ie, AADL,14,15 Palladio,67 and Ambient-PRISMA29 ) that support all those viewpoints. The logical and information view-
points are highly popular, which are supported together by 96 ALs. Among those, 59 ALs (46%) allow for specifying the
behaviors of logical elements (ie, components and connectors), which may then be exhaustively analyzed using the for-
mal methods. Moreover, 58 of them (46%) also support the concurrency aspects of software systems. However, only 32 ALs
(26%) support the generation of software implementation from those view specifications. The least popular viewpoints are
the physical, deployment, and operational viewpoints. Indeed, only 19 ALs (15%) support the specifications of hardware
architectures of systems, and only 13 ALs consider the specifications of the operational issues at an architectural level.
Another important feature analyzed is the extensibility, which is supported by 20 ALs (16%) that are given in Table 11.
While 12 ALs support the syntax extension, the rest support the semantic extension. Among the syntax extensions, XML
is the top popular mechanism, preferred by 6 ALs. Acme and East-ADLs are the 2 inspiring extensible ALs for the seman-
tics extensions via the use of the property annotations and annex libraries, respectively. A couple of ALs support the
syntax extension via the extensible tools, which can be extended for producing code in different formalisms or different
programming languages. In addition, MontiArc uses the inheritance principle of object-oriented paradigm for the syntax
extension, and SOFA uses the aspect-oriented paradigm for the semantic extensions. Lastly, SADL (Structure) is the only
language that supports both the syntax and semantic extensions via subtyping and the algebraic extension, respectively.
Furthermore, 70 ALs (56%) given in Table 12 deal with the programming framework via a modeling editor that allows
for the specifications and modifications of software architectures in a textual/visual way, which can then check for syntax
and semantics rules. In addition, 45 ALs given in Table 13 also support the implementation code generation from software
architectures, where Java is the top preferred programming language.

6 TO O L S U P PORT ANALY SIS

6.1 Automated analysis

Among the 124 different ALs, only 58 ALs (47%) support the automated analysis of software architectures, which have
been examined in terms of the completeness, consistency, correctness, and compatibility properties. Completeness is con-
cerned with the level of details that the specifications of the design decisions (eg, system behaviors and interaction) contain
and is used to check whether the design decisions consider all the requirements of the system. Consistency is concerned
998 OZKAYA

with any contradictions between the architectural elements (eg, components, interfaces, and connectors). This includes
the consistency between the name of a service required and provided by the ports, connecting a required component
port with a provided component port, the consistency between the required and provided behaviors of a service, and the
consistency between the order of services required and the order of services provided. Correctness herein is considered
for checking whether the specified design decisions satisfy the desired system properties. The desired properties can be
either determined by the AL developers (eg, well-definedness rules) or the commonly used properties (eg, deadlock and
race conditions). Lastly, compatibility is concerned with checking whether the software architecture specifications match
with any architectural style or design guidelines. As shown in Table 14, none of the ALs supporting automated analy-
sis consider all these 4 goals of analysis. Consistency is supported by 24 different ALs, regarding it as the top preferred
analysis goal. The completeness, correctness, and compatibility goals are addressed by a few ALs (7-11) however.
The examinations of the ALs also revealed many other requirements that the ALs commonly support. These are simula-
tion, model checking, deadlock checking, reachability, and user-defined properties. Simulation is for imitating a running
software system in terms of the sequence of actions performed by the system components at a time. With simulation, the
behavioral and interaction specifications of the systems can be analyzed. Model checking (or theorem proving) is per-
formed by model checker tools (or theorem provers), which are based on mathematical proofs and allow for the exhaustive
analysis of software architecture specifications. That is, every single state that a system can be in at any time is checked for
the properties of interest. Note that while simulation just shows the system execution at a single path of the system state
space, model checkers check all system paths. Deadlock is used to check whether the system components ever get into
a deadlocking situation, where the components are each waiting for a response from another component that will never
occur. Reachability allows to check the system states that are never reached during the system execution and reveals any
part of the component behaviors or interactions that are not operated as expected. The support for user-defined properties
is concerned with providing practitioners with a (sub)language or a notation set for specifying their desired properties
that can checked for their software architectures later on. Table 15 shows the ALs that support each of those requirements.
Hence, apparently, model checking is the top popular analysis technique, supported by 35 ALs. Note that these ALs essen-
tially enable the translation of software architecture specifications in the input language of the model checkers. Moreover,
28 ALs among those 35 ALs have been observed to support the automated detection of deadlock via the model check-
ers that they support. In addition, 25 ALs support simulation, many of which are essentially those that support model
checkers with the simulation capability (eg, the model checkers of ProMeLa and FSP). Some ALs (Rapide, SADL, and
Palladio) offer their own simulation tools. The user-defined property specification is supported by 24 ALs, most of which
offer logic-based notations, eg, linear temporal logic and first-order logic. Other notations include π-calculus, UML, OCL,
channel ambient calculus,198 and Design by Contract (DbC).54 Lastly, the reachability analysis is considered by a few of
the analyzed ALs only.

6.2 Large-view management

In Section 5.1, the analysis of the ALs for multiple views (ie, logical, information, physical, deployment, behavior,
concurrency, development, and operational) has been discussed. While multiple-view support is so crucial for the con-
siderations of different aspects of software systems, the ALs should also support the specification of large views. That is,
one should be able to specify large and complex systems that consist of many components with many interactions in an
understandable way.
According to the analysis results, 70 ALs (56%) have been observed to address the large views. As shown in Table 16,
these ALs are grouped based on the techniques used for handling large views. The top 3 rows comprise the ALs that
handle scalability via the structural composition of software architectures. Apparently, the top preferred technique is
the composite components (the first row), which promotes the specifications of component structures in terms of other
(sub)components and their interactions. Some ALs use composition for the connector structures (the second row), which
enables the specifications of complex interaction protocols in terms of simpler interaction mechanisms. The third row
gives the ALs that support both the composite component and connector structures. A few ALs adopt the inheritance
principle of object-oriented software engineering paradigm (rows 4 and 5) and support the ability of extending a compo-
nent specification with another component specification(s). By doing so, depending on the semantical constraints of the
languages, the structure and behaviors of components may be inherited. The ALs indicated in row-6 support the compos-
ite specifications of component behaviors in terms of the behaviors of existing components. Rows 7 and 8 group the ALs
that support aspect-oriented software engineering in which the complex cross-cutting design decisions (eg, behaviors and
nonfunctional properties) can be specified modularly as aspects.
OZKAYA 999

TABLE 14 The architectural languages that support completeness, consistency, correctness,

and compatibility
Architectural Language Completeness Consistency Correctness Compatibility
SARA53 X
STATEMATE168,169
Modechart65,66 X
Aesop190 X X
OCA170,171 X X
Resolve131
UNAS/SALE72 X
C2SADL41 X
Cham-ADL136 X
Darwin11,12 X
UniCon77 X
Gestalt191 X
Rapide13 X
AO-Rapide49 X
Polis144,145
Wright10 X X
GenVoca149
Leda44 X
Armani183 X
Knit193
xC242 X
AEmilia83,84 X X
ArchJava152 X X
SADL68
SOFA156,157 X
DAOP ADL88 X
AADL14,15 X X
HappyWork180 X X
Mae90 X X
π-ADL91
Abacus56
CBabel58,59 X
Clara60 X
Con Moto61
East-ADL32
π-net ADL17
SafArchie94
xADL33 X
Backbone95
KADL39 X
Prisma28,97 X
Ambient-Prisma29,30 X
AspectLEDA45 X
OSAN124
SOADL122 X
Maude164
TADL71 X X
DiaSpec102
Palladio67
Archface176 X X
EADL165
LISA186 X X
MontiArc104,105
Connect166
X-Man73,74 X X
XCD26 X X X
Drems ML64
Stratus ML75 X X X
TOTAL 10 24 11 8
1000 OZKAYA

TABLE 15 The architectural languages that support the different requirements of automated analysis
Architectural Language Simulation Model Deadlock Reachabiltiy User-Defined
Checking Property
SARA53 X X X X
STATEMATE168,169 X X X
Modechart65,66 X X X First-order logic
Aesop190 X X
OCA170,171
Resolve131 X
UNAS/SALE72
C2SADL41
Cham-ADL136 X X X X
Darwin11,12 X X X X
UniCon77
Gestalt191
Rapide13 X Event pattern
AO-Rapide49 X Event pattern
Polis144,145 X Temporal logic
Wright10 X X X
GenVoca149 X
Leda44 X X
Armani183 First-order logic
Knit193 Informal notation
xC242
AEmilia83,84 X X
ArchJava152 X
SADL68 X
SOFA156,157 X X X LTL
DAOP ADL88
AADL14,15 X X X Anne
HappyWork180
Mae90 First-order logic
π-ADL91 X X π-calculus & temporal logic
Abacus56 X
CBabel58,59 X X X LTL
Clara60 X X X
Con Moto61 X X X X π-calculus
East-ADL32 X X X X UML-based notation
π-net ADL17 X X X X
SafArchie94 X X X X
xADL33 C2
Backbone95 X X X
KADL39 X X X X Temporal logics
Prisma28,97 Temporal logics
Ambient-Prisma29,30 π-calculus and channel ambient calculus
AspectLEDA45 X X
OSAN124 X X
SOADL122 X X
Maude164 X X X LTL
TADL71 X X
DiaSpec102 X
Palladio67 X UML-like notation
Archface176 X X X X LTL
EADL165 X X X Temporal logic
LISA186
MontiArc104,105 X X
Connect166 X X X
X-Man73,74 X X DbC
XCD26 X X X LTL
Drems ML64 X OCL
JACAL125 X
TOTAL 25 35 28 16 24

6.3 Support for versioning

Versioning support is concerned with keeping and accessing different versions of software architecture specifications.
As shown in Table 17, 18 different ALs (15%) support versioning. These ALs essentially offer the use of repositories via
their modeling editors. Repositories can be used for storing any supported architectural elements (eg, components and
connectors), versioning those elements, accessing any versions needed, and reusing the versions for constructing different
system configurations.
OZKAYA 1001

TABLE 16 The architectural languages that support large-view management

Architectural Languages Large-View Management Techniques
SARA,53 STATEMATE,168,169
Modechart,65,66 Aesop,190 OCA,170,171
MetaH,31 Adage,199 Darwin,11,12
UniCon,77 ASDL,138,139 C2SADEL,41
OOADL,140,193 Koala,16 Olan,80,81
ArchJava,152 Pilar,121 RADL,43
SOFA,156,157 AADL,14,15 HappyWork,180
1 Mae,90 Abacus,56 ADLARS,93 Structural composition (components)
ArchiMate,181,182 ArchiTrio,159 East-ADL,32
SafArchie,94 SKwyRL,147 Backbone,95
EAADL,96 SOADL,122 ALI,98,99
Maude,164 Grasp,200 Palladio,67
Archface,176 Clacs,196,197 Dedal,103
EADL,165 LISA,186 Autosar,179
MontiArc,104,105 Fractal46,47
2 Gestalt191 Structural composition (connectors)
C2SADL,41 Armani,183 CommUnity,86,87 Structural composition (components
3 COSA,201 Secure XADL,34 XADL,42 & connectors)
AVDL,202 KADL,39 X-MAN,73,74 C3106
4 Zeta85 Inheritance
5 LILEANNA,129 P++,203 Leda,44 Structural composition (components)
Korrigan38 & inheritance
6 Room,192 π-ADL,91 TADL71 Structural and behavioral compositions
7 Prisma,28,97 Ambient-PRISMA,
AO-Rapide49,29,30 Aspect-oriented specifications
8 AspectLEDA,45 AC2-ADL,162 Structural composition (components)
AO-ADL,51 FAC48 & aspect-oriented specifications

TABLE 17 The architectural languages that

support versioning
Architectural Languages Release Years
Kaptur188,189 1992
Artek76 1994
JACAL125 1998
XC242 2001
SOFA156,157 2002
DAOP-ADL88 2003
Mae,90 Service-ADL92 2004
Abacus,56 XADL42 2005
Prisma28,97 2006
Palladio67 2009
ArchiMate181,182 2009
Dedal103 2010
AO-ADL,51 Autosar179 2011
X-MAN73,74 2012
Drems ML64 2015

6.4 Support for knowledge management

Another important issue is knowledge management, which needs to be taken seriously by the AL developers. Indeed,
practitioners need to access any knowledge about the ALs easily and share their knowledge with other practitioners and
the AL developers. As proposed by Lago et al,20 knowledge about ALs can be managed via websites that publish any
material that may be of use to the practitioners and direct practitioners in any discussion platform (eg, forums and user
groups).
Table 18 gives the 29 ALs (23%) that offer publicly available websites. When the websites of those ALs have been exam-
ined carefully, a number of features have been determined which the websites support (at least partially). These features
1002 OZKAYA

TABLE 18 The architectural languages (ALs) that have websites

ALs AL Website
Acme35,36 http://acme.able.cs.cmu.edu/
XAcme185 http://www.cs.cmu.edu/~acme/pub/xAcme/
UML172 http://www.uml.org/
UniCon77 https://www.cs.cmu.edu/~Vit/unicon/
Rapide13 http://complexevents.com/stanford/rapide/
Wright10 http://www.cs.cmu.edu/~able/wright/
East-ADL32 http://www.east-adl.info/
ADML79 http://www.opengroup.org/architecture/adml/adml_home.htm
SOFA156,157 http://sofa.ow2.org/
DAOP-ADL88 http://caosd.lcc.uma.es/CAM-DAOP/
AADL14,15 http://www.aadl.info/
ArchiMate181,182 https://www.archimatetool.com/
Secure XADL34 http://www.ics.uci.edu/~jie/SecureSoftwareArchitecture.html
XADL42 http://isr.uci.edu/projects/xarchuci/
Fractal46,47 http://fractal.ow2.org/
Little JIL174 http://laser.cs.umass.edu/tools/littlejil.shtml
Prisma28,97 http://prisma.dsic.upv.es/model_language.html
Ambient-Prisma29,30 http://prisma.dsic.upv.es/distribution_mobility.html
Maude164 http://maude.cs.uiuc.edu/maude1/
DiaSpec102 http://phoenix.inria.fr/research-projects/diasuite
Palladio67 http://www.palladio-simulator.com
AO-ADL51 http://caosd.lcc.uma.es/aoadl/
Autosar179 https://www.autosar.org/
Montiarc104,105 http://www.se-rwth.de/topics/Software-Architecture.php
X-Man73,74 http://www.cs.man.ac.uk/~tranc/xman/X-MAN_tool/
Stratus ML75 http://www.stargroup.uwaterloo.ca/~mhamdaqa/stratusml/
XCD26 https://sites.google.com/site/ozkayamert1/home/xcd
Jacal125 http://www-2.dc.uba.ar/profesores/nicok/jacal.htm
ADR148 http://www.albertolluch.com/research/adr

are introductory knowledge about the ALs, tutorials, toolset, user manual, case studies, forum, publications, mailing list,
membership, and contact info. Table 19 groups the ALs given in Table 18 in terms of those features that the ALs support.
Hence, apparently, forum, mailing list, and membership are the least supported requirements by the ALs' websites. On
the other hand, almost all AL websites have the introduction, publications, toolset, and contact parts.

6.5 Software architecture–centric design

All the analyzed languages allow for the high-level specifications of software architectures with their architecture-oriented
notation sets (ie, components, connectors, interfaces, roles, etc). To promote the software architecture–centric design,
some ALs provide tool support that enables to utilize from the software architecture specifications for different purposes.
These include the automated analysis of software architectures (see Section 6.1), the automated generation of imple-
mentation code (see Section 5.3), and reusing software architecture specifications via repositories (see Section 6.3). Some
ALs integrate software architecture specifications with requirement specifications. As discussed in Section 6.1, those ALs
extend their notation sets with another (mostly logic based) notation set for specifying system requirements and allow for
automatically analyzing the software architectures for those requirements. Moreover, a few ALs also support the specifi-
cations and analysis of nonfunctional requirements, discussed in Section 4.1. When all those capabilities were considered
together, Palladio67 and Drems ML64 are the only ALs that support the specifications of software architectures and any
desired functional and nonfunctional properties that can then be analyzed automatically and generated into software
implementation.

6.6 Collaboration
To develop high-quality software systems within the expected time and budget constraints, team work should be the
essential part of software development. Team work requires a group of people to work on the same project collaboratively,
OZKAYA 1003

TABLE 19 The architectural languages (ALs) that support the knowledge management requirements in their websites
ALs Intro- Tutorials Toolset User Case Forum Publi- Mailing Member- Contact
duction Manual Studies cation List ship
Acme35,36 X X X X X X X X X
XAcme185 X X X X X
UML172 X X X X X X X X X
UniCon77 X X X
Rapide13 X X X X X X X
Wright10 X X X
East-ADL X X X X X X X X X
ADML79 X X X X
SOFA156,157 X X X X X X
DAOP-ADL88 X X X X
AADL14,15 X X X X X X X X
ArchiMate181,182 X X X X X X X X
Secure XADL34 X X X
XADL42 X X X X
Fractal46,47 X X X X X X X
Little JIL174 X X X X X
Prisma28,97 X X X X
Ambient-Prisma29,30 X X X X
Maude164
DiaSpec102 X X X X
Palladio67 X X X X X X X X
AO-ADL51 X X X X X X
Autosar179 X X X X X X
Montiarc104,105 X X X X X X
X-Man73,74 X X X X X X
Jacal125 X X X X
Stratus ML75 X X X X
XCD26 X X X X X X
ADR148 X X

which reduces the development time and enhances the product quality. As Lago et al20 suggested, the collaboration
within the team of people can be either synchronous or asynchronous. Synchronous collaboration requires the users
to work on the software architecture specifications at the same time, while they may be physically located at different
places. In asynchronous collaboration, different users may work on the specifications at different times that suit their
time schedule best.
Table 20 shows the 10 ALs (8%) that enable collaboration via their tools and groups them on their tool support for
synchronous and asynchronous collaborations. Hence, only the AADL and UML ALs provide tool support that enables
both synchronous and asynchronous collaborations between multiple practitioners. AADL's Osate plugin§ enables the
use of Eclipse's team synchronization capability. Concerning UML, many tools have been proposed by researchers, which
considered the synchronous collaboration, eg, those by Thum et al,204 De Lucia et al,205 and Mehra et al.206 The rest of the
7 ALs rather focus on asynchronous collaboration via the use of repositories. That is, practitioners can use their tools to
store any architectural element specifications in the repository asynchronously that may be accessed by other users at any
time for editing purposes.

6.7 Discussion
The automated analysis of software architectures is supported by 58 ALs (47%) in different ways. Firstly, the analysis
support for the completeness, consistency, correctness, and compatibility properties has been examined, and the results
in Table 14 show that none of the ALs support all these 4 issues. While consistency is quite popularly handled by 24 ALs,
completeness and correctness are not so (9-11 ALs), and compatibility is the least supported property (7 ALs). Concerning
the other requirements observed in the ALs, 35 ALs shown in Table 15 support the exhaustive model checking via some

§
AADL's Osate plugin can be accessible via the link: https://wiki.sei.cmu.edu/aadl/index.php/Osate_2
1004 OZKAYA

TABLE 20 The architectural languages (ALs) that support collaboration

ALs Synchronous Collaboration Asynchronous Collaboration
ArchiMate181,182 X
AADL14,15 X X
UML172 X X
Palladio67 X
AO-ADL51 X
DAOP-ADL88 X
X-Man73,74 X
Abacus56 X
Autosar179 X
Mae90 X

model checkers. These model checkers also let the ALs benefit from several other facilities such as simulation, deadlock
checking, and reachability analysis. Again, in Table 15, 24 of the ALs have been observed to support the requirements
specification and analysis. These ALs mainly use the logic-based notations for requirement specifications, eg, first-order
logic and linear temporal logic.
Large-view management is handled by 70 ALs (56%) given in Table 16, so as to facilitate the specifications and
understanding of large and complex software systems with many components and interactions. Many ALs (58 ALs)
offer composite components for specifying large component structures hierarchically in terms of other components and
connectors. Furthermore, 11 different ALs offer composite connector structures that can be used to specify complex inter-
action mechanisms out of simpler ones. However, the composite specifications of complex component behaviors or any
other means of handling complex behaviors are adopted just by 3 ALs. Three of the aspect-oriented ALs handle the com-
plexity of components via aspects. Lastly, 4 ALs use the inheritance principle of object-oriented software engineering,
which simplifies the specifications of components via the reuse of existing component specifications.
In addition, 18 ALs (15%) shown in Table 17 support the versioning of software architecture specifications via
repositories that are accessible via the modeling editors.
As given in Table 18, 29 ALs (23%) support knowledge management via their websites. While most of them share some
introductory knowledge about the ALs, any tools available, and publications, they mainly lack in the discussion platforms
such as forums and user groups.
The current ALs have been examined for the software architecture–centric design. Herein, the focus is on the speci-
fications of software architectures, the functional/nonfunctional requirements, the analysis of the software architecture
specifications for the desired requirements, and the generation of software code from the specifications. The ALs do not
unfortunately support all these activities of software development, except Palladio67 and Drems ML.64
Lastly, 10 ALs (8%) provide tool support that enables collaboration among practitioners. Unsurprisingly, only UML and
AADL enable synchronous collaboration in which multiple people may work on the same task at the same time and their
work get synchronized with each other continuously. Note also that UML and AADL are highly mature languages, which
have been extended with powerful modeling tools. Moreover, Malavolta et al21 observed UML and AADL as the top used
languages by practitioners for the software architecture specifications.

7 SUMMARY OF FINDINGS

In Sections 4, 5, and 6, the analysis of the 124 ALs for language definition, language features, and tool support require-
ments, respectively, has been discussed. The analysis results show firstly that none of the 124 different ALs support all
the requirements of language definition, language features, and tool support together. Now, in the rest of this section, the
findings obtained from the analysis of the ALs for each set of requirements are summarized.

7.1 Language definition

Nonfunctional requirements are shown a lack of interest. Although the nonfunctional properties are highly crucial
in ensuring the quality of software systems, just 26 ALs (21%) consider them as part of software architecture specifica-
tions. Among the 26 ALs, only 7 of them support the automated analysis of software architectures for the nonfunctional
requirements; the rest just support their specifications for communication purposes.
OZKAYA 1005

Nonfunctional requirements are specified either formally or informally. Among the 26 ALs that support non-
functional requirements, 16 of them extend their notation set with an informal notation for specifying the nonfunctional
requirements supported. Four of those ALs are aspect oriented and offer aspects for nonfunctional requirements. The rest
of the 10 ALs use formal methods for the specification and formal analysis of the nonfunctional requirements.
Performance is the most popular nonfunctional requirement. Of the ALs that consider nonfunctional
requirements, 29% support the specifications of performance-related issues such as resource contention, execution/
waiting/response times of operations, deadlines of operations, etc.
No any AL offers cleanly separate textual and visual notation sets. Here, 42 ALs (34%) have been observed to
offer both textual and visual notation sets. However, these ALs essentially offer hybrid notation sets that combine the
textual and visual notation sets together. Practitioners are not given the flexibility of specifying their design decisions
using purely a textual notation set or a visual notation set depending on their experience and needs.
Formal semantics are supported by almost half of the ALs. The semantics of 60 ALs (48%) have been defined
using the mathematically based formal methods. Hence, these ALs lead to precise software architecture specifications
that promote the detailed specifications of the design decisions in an exact way. Note that formal ALs also enable the
formal (ie, exhaustive) analysis of software architectures via the supporting model checkers (ie, theorem provers) of the
formal methods.
Process algebras (especially 𝛑-calculus) are the top preferred formal method. Of the 60 ALs, 18 (32%) have
their formal semantics defined using process algebras (eg, π-calculus, CSP, FSP, Alloy, and ProMeLa), which promote the
specifications of software systems in terms of processes that concurrently interact with each other. The π-calculus process
algebra22 is the top choice of AL developers, used by 12 ALs among 18.
The language definition requirements are supported by just 4 ALs. SARA,53 Clara,60 Prisma,28,97 and X-Man73,74
are the only ALs that offer formally based textual and visual notation sets for the precise specifications of software archi-
tectures and some nonfunctional requirements. Note, however, that Clara is the only AL among them that supports the
automated analysis of the nonfunctional requirements.

7.2 Language features

The logical and information viewpoints are supported together by most of the ALs. Here, 96 ALs (78%) support
the logical and information viewpoints together. Hence, using these ALs, practitioners can basically specify their soft-
ware systems in terms of (1) the components and their interactions (ie, connectors) and (2) the data that are stored and
manipulated by the components.
The behavior viewpoint is not as popular as logical and information viewpoints. Here, 59 ALs (46%) support
the behavior viewpoint and allow for specifying the formal/informal behaviors of components and connectors. Note also
that almost all of those ALs (58 ALs) also support the concurrency viewpoint and, thus, allow in their notation set for
specifications of concurrency-related issues such as synchronization and threading.
The physical and deployment viewpoints are shown a lack of interest. The physical and deployment viewpoints
are supported by only 19 ALs (15%), which allow for specifying the hardware architectures of systems and their mapping
to the systems' software architectures.
The operational viewpoint is the least popular among all the viewpoints considered. The operational viewpoint
is supported by 13 ALs (10%), which consider in their notation set the operational issues that occur during the systems
running in their environment (ie, user support, installing/uninstalling, monitoring, upgrading, etc).
Extensibility is shown a lack of interest. The number of extensible ALs is just 20 (16%), which allows practitioners
to extend the language notations either syntactically or semantically in a way that better meet their needs. The syntax
extension is provided through different extension mechanisms, which consist of language inheritance, XML, UML pro-
files and stereotypes, and subtyping. The semantic extension is provided through annex libraries, property annotations,
aspects, and tool support. SADL (Structure)78 is the only language that supports both the syntax and semantic extensions.
XML is the top preferred extension mechanism. Among the 20 extensible ALs, 6 of them are XML-based languages
and use XML's extensible nature to enable the syntax extensions for adding new types of architectural elements that may
better satisfy practitioners' needs.
The support for a modeling editor is quite popular among the ALs. Here, 70 ALs (56%) are supported with a
modeling editor for specifying different views of software architectures using the ALs' textual/visual notation sets and
analyzing the view specifications for the syntax and semantics rules of the ALs. Moreover, 45 ALs that offer a modeling
1006 OZKAYA

editor also enable the translation of the specified and analyzed software architectures into software implementation code.
Furthermore, as will be discussed in the next section, some ALs also support the versioning of software architectures via
their modeling editors.
Java is the top preferred programming language for software code generation. Among the 45 ALs that support
software code generation, 24 ALs (52%) use Java as the target programming language. The rest of them use C, C++, Ada,
and C#.
The language feature requirements are supported together by just one AL. AADL14,15 is the only language
that offers a modeling editor for specifying the logical, physical, deployment, behavior, concurrency, development, and
operational views using an extensible notation set.

7.3 Tool support

Model checking is the top preferred automated analysis method. Among the 58 ALs (47%) that support the auto-
mated analysis of software architectures, 35 of them support model checkers (or theorem provers) for the exhaustive
verification. These ALs are essentially supported with some translators that translate the software architecture specifica-
tions in the model checkers' input languages, which enable the use of model checkers. Note also that some of those model
checkers support the simulation of software architectures and the deadlock and reachability analyses.
The user-defined system requirements can also be automatically analyzed. Among 58 ALs, 24 ALs (41%) extend
their notations with subnotations (ie, mostly logic based) for specifying system-level functional requirements.
The completeness, consistency, correctness, and compatibility analysis properties are not all supported at
the same time. Given the completeness, consistency, correctness, and compatibility goals proposed by Taylor et al,4 none
of the ALs have been observed to support the automated analysis of software architectures for all of these properties at
the same time.
The consistency checking of software architectures is quite popular among the ALs. Among the 58 ALs
supporting the automated analysis, 24 ALs (41%) support the consistency checking, which is concerned with any contra-
diction between the interconnected components (eg, behavioral consistencies, interface-type consistencies, and service
consistencies).
The compatibility checking of software architectures is the least popular property among the ALs. Among
the 58 ALs supporting the automated analysis, 8 of them (12%) support the compatibility checking, which is concerned
with determining whether the software architecture specifications match some architectural styles (or patterns).
The structural composition is the top preferred technique for managing large software architecture views.
Here, 70 ALs (56%) consider the specifications of large and complex software architectures, and 59 of them offer composite
component and connector structures that can be used for specifying large and complex components and connectors out
of simpler ones hierarchically.
The versioning of software architectures is shown a lack of interest. According to the analysis results, only 18
ALs (15%) support the versioning of software architectures by means of keeping the repositories of architectural elements
for later use.
Knowledge management is shown a lack of interest. Despite the importance of sharing knowledge and experience,
only 29 ALs (23%) have websites for accessing AL-related information. This includes the AL's introductory information,
tutorials, user manuals, toolsets, case studies, publications, and any discussion platform.
Discussion platforms for ALs are shown a lack of interest. Among the 29 ALs that have websites, only Acme,35,36
AADL,14,15 ArchiMate,181,182 and Autosar179 offer practitioners a discussion platform (eg, forums and user groups) through
which any language-related concept or practitioners' specification-related issues can be discussed together with the
language developers and other users of the languages.
The software architecture–centric design is shown a lack of interest. All the ALs considered in this study offer
an architecture-oriented notation set. However, when some other activities of software design are considered such as
functional/nonfunctional requirement specifications, the analysis of software architectures for the requirements, and
the translation of architectures into software implementation, just Palladio67 and Drems-ML64 support all these activities
together.
The collaborative specifications of software architectures are shown a lack of interest. There are only 10 ALs
(8%) that support the collaborative specifications of software architectures via their tools. Among those 10 ALs, AADL
and UML are the only 2 ALs that support both the synchronous and asynchronous collaborations; the rest support only
the asynchronous collaboration.
OZKAYA 1007

8 THREATS TO VA LIDITY

8.1 Internal validity

Internal validity is concerned with the causal relationships between the analysis results and any independent variable
that lead to the results (ie, the cause). The goal is to ensure that the analysis results herein derive from the language
requirements considered and no unknown independent variables affect the results.
In this study, nonprobability sampling was used, and the ALs to be analyzed have been selected nonrandomly. That is,
the ALs have been retrieved from Malavolta et al's work, who conduct active research studies on ALs and their practical
use by industry. They essentially maintain an up-to-date list of the current ALs,19 which meet the definition of an AL
proposed by the IEEE standard: “any form of expression for use in architecture descriptions”.¶ Currently, their list consists
of 124 different ALs, which have been analyzed in this study. Moreover, the ALs have been analyzed for 3 groups of
requirements, which are language definition, language features, and tool support. The requirements herein are based on
the research of Lago et al,20 who work in the same research group as Malavolta. Lago et al determined those requirements
after Malavolta et al's comprehensive survey among practitioners from 40 different companies in 15 countries, with the
goal of understanding the needs of practitioners from ALs.21 Note that some of the requirements that are not precise
enough by itself have been decomposed further into subrequirements (see Table 2). By doing so, more precise analysis
results have been aimed to be reached. The decomposition herein has been performed using the requirement definitions
of Lago et al and the definition of concepts from the seminal book of Taylor et al.4
The analysis of the ALs for the determined set of requirements has been conducted by one experienced researcher on
software architectures, who is the author himself. By doing so, the goal was to avoid any instrumentation biases that may
occur when the researcher who gathers the data and analyze them changes, and this change affects the analysis results due
to the varying profiles of the researchers. As discussed in Section 3, the author has conducted the analysis systematically
in several iterations. Initially, the supporting materials of each AL including the publications, tutorials, and tools have
been studied to gain some familiarity with the ALs. Then, in another iteration, the supporting materials of the ALs have
been gone through to determine the level of support for the requirements in question. This process has been repeated in
exactly the same way so as to detect any discrepancy.

8.2 External validity

External validity is concerned with the possibility of generalizing the analysis results to the entire population.
As discussed in Section 8.1, the ALs to be analyzed have been determined from the up-to-date list of Malavolta et al,19
which contains all the known ALs in the literature. Therefore, the results of this analytical study can safely be generalized
to the entire field of software architecture languages.

8.3 Construct validity

Construct validity is concerned with how well an analysis aids in achieving the research goal(s).
The goal of this study is essentially to analyze the existing ALs for the set of requirements that are important to prac-
titioners and propose a platform for the practitioners to compare the existing ALs for choosing the one(s) that best
satisfies their needs. As discussed in Section 7, the analysis of ALs leads to many interesting findings for each group of
requirements, which are expected to be so useful for practitioners.

9 RELATED WORK

In this section, the surveys that have been conducted on software architectures are discussed in 2 parts. Firstly, the surveys
that analyze the existing ALs are discussed. This is followed by the discussions of the surveys on practitioners that aim at
learning the practitioners' perspectives about some architectural aspects.

¶
ISO/IEC/IEEE 42010 Website: http://www.iso-architecture.org/ieee-1471/
1008 OZKAYA

9.1 Surveys on architectural languages

Table 21 summarizes a number of similar surveys in terms of their domain of interest, the number of ALs considered for
analysis, and the criteria used in analyzing the ALs. Hence, apparently, these studies consider at most 12 ALs for their
analysis. Also, their goals are either to (1) define the notion of ALs, (2) understand ALs' support for particular domains
(eg, distributed and mobile systems, embedded systems, simulation systems, or retargetable compilers), or (3) observe ALs'
support for particular aspects of software development such as expressiveness, usability, formal analysis, and realizability.
The analytical study presented in this paper is distinguished with its (1) consideration of the comprehensive list of ALs
including 124 different ALs; (2) the systematic approach for analysis in terms of language definition, language features,
and tool support; and (3) focus on the needs of practitioners in industry. In the rest of this section, the similar analytical
studies summarized in Table 21 are discussed.
Medvidovic and Taylor9 and Clements6 analyzed a group of ALs in the late 1990s to offer a framework for defin-
ing ALs. Since their surveys have been conducted in the 1990s, only a few languages that have been existing in that
period were included in their surveys. Medvidovic et al207 have later on extended their previous study that essentially
focuses on the technological aspect of software architectures. Now, in their new survey, they focus on what they call the
lamppost—technology, domain, and business aspects—and try to understand the ALs in terms of these aspects. Note,
however, that Medvidovic et al surveyed only 8 different languages, categorizing them as first-generation (developed in
the 1990s) and second-generation (developed in the 2000s) languages. Another survey has been conducted by Vestal5 in
the 1990s, who analyzed 4 main ALs for many criteria such as the support for components and connectors, formal analy-
sis, and automatic code generation. Vestal's survey led to interesting results about the structural commonality between the
4 ALs and the behavioral and semantical differences among them due to their domain of interest. In the work of Hilliard
and Rice,208 the ALs developed during the 1990s have been analyzed to measure their expressiveness. Hilliard and Rice
considered expressiveness as a way of documenting the design decisions precisely that makes explicit several details such
as when the decisions are made for whom and by whom. To evaluate the expressiveness of the ALs, Hilliard and Rice
focused on several features including multiple viewpoints, first-class constraints, and the support for architectural styles
and patterns.
In the work of Ali et al,209 the authors focused on understanding whether the ALs offer explicit constructs in their nota-
tions for specifying the distributed and mobile software systems. To this end, Ali et al analyzed 8 different ALs for a set of
relevant characteristics, including location, mobility, formalism, and visual notation set. In the work of McKenzie et al,210
the authors focused on using formal ALs for the analysis and design of simulation systems and their important charac-
teristics. McKenzie et al used 2 of the mainstream ALs (ie, Rapide and Acme) and experimented with them using some
well-known simulation architectures (ie, EnviroFed and ModSAF). They found out that ALs bring many advantages for
the specifications of simulation systems, such as robustness, composability, and risk reduction. In the work of Qin and
Malik,211 the authors surveyed among 8 different ADLs for the specifications and formal analysis of retargetable compiler
systems (eg, assemblers and simulators). Qin and Malik focused on several important features, including the compiler
and simulator support, behavioral and structural specifications, etc. Qin and Malik pointed out their observations about
missing structural and behavioral requirements of the ALs for modeling retargetable compiler systems. In the work of
Mishra and Dutt,212 the authors classified the ALs into 3 groups: the structural ADLs, the behavioral ADLs, and mixed
ALs. While structural ADLs support the logical view and behavioral ALs support the behavioral view, the mixed ones
support both views at the same time. Mishra and Dutt analyzed 2-3 ALs from each group to understand their support for
programmable embedded systems. In their analysis, they essentially focused in on tool generation (ie, compilers and sim-
ulators), generating a prototype for system hardware, and the verification of software architectures. Lastly, Ozkaya and
Kloukinas8 analyzed 12 ALs for formal analysis, usability, and realisability. Usability herein is considered in terms of mod-
ularity (ie, support for components and complex connectors) and the notation used for behavior specifications. Ozkaya
and Kloukinas pointed out that the ALs that enable formal analysis via the formal behavior specification (ie, mostly alge-
braic) sacrifice from usability. They also introduced the realizability feature, which is the capability of guaranteeing that
software implementations reflect their software architecture specifications consisting of the same components with the
same communications.

9.2 Surveys on practitioners

Besides the surveys on the ALs, the literature also includes several surveys that discuss practitioners' perspectives about
some particular issues of software architectures. Rost et al,213 for instance, surveyed 147 practitioners for understanding
OZKAYA 1009

TABLE 21 The classifications of the related works

Domain of Interest Number of ALs
Survey Analysis Criteria
Medvidovic and Taylor9 Defining an AL's 9 ALs Architecture modeling
capabilities features and tool support
Clements6 Defining an AL's 8 ALs Language-oriented features,
capabilities System-oriented features,
Process-oriented features
Medvidovic et al207 Defining an AL's 9 ALs Three lamppost (ie,
capabilities technology, domain,
and business)
Components, connections,
hierarchical composition,
computation and
Vestal5 AL comparison 4 ALs communication paradigms,
formal models, modeling,
analysis, evaluation, and
verification, and code
generation
Multiple views,
closed-world,
The ALs capturing architects' intent,
Hilliard and Rice208 Expressiveness developed first-class constraints,
until 1998 computational independence,
quantification, architectural
pattern and styles
Distributed Location, location awareness,
Ali et al209 and mobile 8 ALs mobility, coordination,
software systems formalism, graphical support,
middleware, tool support
Simulation Architectural elements,
McKenzie et al210 systems 2 ALs graphical support, simulation
output, simulation tool support
Retargetable Compiler, simulator, behavior
Qin and Malik211 compilers 12 ALs view, structure view, constraint
specifications, control path
Compiler, simulator,
cycle-accurate simulation,
formal verification,
hardware generation,
Mishra and Dutt212 Programmable 9 ALs test generation, JTAG
embedded systems interface generation,
instruction set information,
structural information,
memory information
components, complex
Ozkaya and Kloukinas8 Formal analysis, 13 ALs connectors, formal behavior
usability, realizability specification, formal analysis,
realizability
Abbreviation: ALs, architectural languages.

their expectations from software architecture documentation methods. Babar and Gorton214 surveyed 235 practitioners
for understanding their knowledge and experience about software architecture reviewing techniques. Ameller 215 sur-
veyed among 13 software architects for understanding the architects' knowledge and experience about nonfunctional
property specifications and analysis. Tofan et al216 surveyed among 43 architects to understand the difficulties of the
design decisions made by the architects, what affects those decisions, and what makes them considered as good or bad
decisions. Hence, the results of these surveys reveal practitioners' current level of knowledge and experience for some
important aspects of software architectures, and the results can be used for further analytical studies such as analyzing
the ALs' support for those aspects. Moreover, the results can also be helpful for the new AL developers who wish to bridge
1010 OZKAYA

the gap about those aspects. However, using these survey results, it is not easy to understand the needs of practitioners
from ALs and to what extent the existing ALs satisfy their needs. The general needs of practitioners from ALs have been
addressed by Malavolta et al,21 who conducted a really comprehensive survey among 48 different participants working
for IT companies in 15 different countries with the goal of understanding practitioners' expectations from ALs. Malavolta
et al found out many interesting results, including the rare use of the ALs (except AADL and UML), ALs' steep learning
curve, practitioners' high interest toward the architectural analysis and multiple viewpoints, and the lack of interest for
code generation. The analysis of the existing 124 ALs discussed in this paper essentially uses Lago et al's framework of
language requirements20 that is based on Malavolta et al's survey results. Unlike the other approaches, this study focuses
on the ALs and analyzes them based on their support for Lago et al's language requirements. Using the analysis results,
practitioners not only determine the AL(s) that satisfies any of the language requirements that they care about but also
understand the weak and strong points of the existing ALs in terms of those requirements.

10 CO NCLUSIONS A ND FURT HER WORK

In this study, the goal is to analyze the existing ALs to understand their support for the requirements that are important
to the practitioners in industry. To this end, the 124 different ALs have been addressed, which have been determined
from the up-to-date list of Malavolta et al.19 These ADLs have been analyzed for the 3 groups of requirements—language
definition, language features, and tool support—that have been determined by Lago et al upon surveying among a number
of practitioners in industry and understanding their needs.20 Language definition has been examined for (1) nonfunctional
properties, (2) textual and visual notation sets, and (3) formal semantics. The language features have been examined for
(1) multiple viewpoints, (2) extensibility, and (3) programming framework. Lastly, tool support has been examined for
(1) automated analysis, (2) large-view management, (3) support for collaboration, (4) support for versioning, (5) support
for knowledge management, and (6) support for software architecture–centric design. The analysis of the 124 ALs for the
above requirements leads to many interesting results that are believed to be highly useful for practitioners who want to
understand the capabilities of the existing ALs and compare the ALs with each other to find the AL(s) that best satisfies
their needs. Moreover, the results are also expected to be helpful for the new AL developers, who can understand the
weaknesses of the current ALs and address them in their ALs.
In the future, the analysis results obtained here may be used for developing a new AL that supports all the requirements
of language definition, language features, and tool support groups. This will indeed bridge the gap as none of the analyzed
124 ALs manage to do so. Moreover, a survey may also be conducted in the future so as to understand the views of
practitioners about the requirements discussed here. Such a survey could also aid in observing which of the requirements
practitioners highly care about in their design, what specific properties of those requirements are more interesting to
them, and why.

ACKNOWLEDGEMENT
This work was supported by a project of the Scientific and Technological Research Council of Turkey (TUBITAK) under
grant 215E159.

ORCID

Mert Ozkaya http://orcid.org/0000-0002-3464-6489

REFERENCES
1. Perry DE, Wolf AL. Foundations for the study of software architecture. SIGSOFT Softw Eng Notes. 1992;17(4):40-52. https://doi.org/10.
1145/141874.141884; http://doi.acm.org/10.1145/141874.141884
2. Allen R, Garlan D. Formalizing architectural connection. Paper presented at: Proceedings of the Sixteenth International Conference on
Software Engineering; 1994; Sorrento, Italy.
3. Kruchten P. The 4+1 view model of architecture. IEEE Softw. 1995;12(6):42-50. https://doi.org/10.1109/52.469759
4. Taylor RN, Medvidovic N, Dashofy EM. Software Architecture: Foundations, Theory, and Practice. Hoboken, NJ: Wiley; 2010. http://eu.
wiley.com/WileyCDA/WileyTitle/productCd-EHEP000180.html
5. Vestal S. A Cursory Overview and Comparison of Four Architecture Description Languages. Technical Report. Honeywell Technology
Center; 1993.
OZKAYA 1011

6. Clements PC. A survey of architecture description languages. Paper presented at: Proceedings of the 8th International Workshop on
Software Specification and Design, IWSSD'96; 1996; Washington, DC.
7. Woods E, Hilliard R. Architecture description languages in practice session report. Paper presented at: Proceedings of the 5th Working
IEEE/IFIP Conference on Software Architecture, WICSA'05; 2005; Washington, DC. https://doi.org/10.1109/WICSA.2005.15
8. Ozkaya M, Kloukinas C. Are we there yet? Analyzing architecture description languages for formal analysis, usability, and realizability.
In: Demirörs O, Türetken O, eds. EUROMICRO-SEAA; 2013; Prague, Czech Republic.
9. Medvidovic N, Taylor RN. A classification comparison framework for software architecture description languages. IEEE Trans Software
Eng. 2000;26(1):70-93.
10. Allen R, Garlan D. A formal basis for architectural connection. ACM Trans Softw Eng Methodol. 1997;6(3):213-249.
11. Magee J, Dulay N, Eisenbach S, Kramer J. Specifying distributed software architectures. In: Schäfer W, Botella P, eds. European Software
Engineering Conference. New York, NY: Springer; 1995:137-153. Lecture Notes in Computer Science; vol. 989.
12. Giannakopoulou D, Kramer J, Cheung SC. Behaviour analysis of distributed systems using the tracta approach. Autom Softw Eng.
1999;6(1):7-35.
13. Luckham DC, Kenney J, Augustin L, Verra J, Bryan D, Mann W. Specification and analysis of system architecture using Rapide. IEEE
Trans Software Eng. 1995;21(4):336-355.
14. Feiler PH, Lewis BA, Vestal S. The SAE Architecture Analysis & Design Language (AADL) a standard for engineering performance
critical systems. Paper presented at: 2006 IEEE International Symposium on Intelligent Control; 2006; Munich, Germany. https://doi.
org/10.1109/CACSD-CCA-ISIC.2006.4776814
15. Franca RB, Bodeveix JP, Filali M, Rolland JF, Chemouil D, Thomas D. The AADL behaviour annex – experiments and roadmap. Paper
presented at: Proceedings of the 12th IEEE International Conference on Engineering Complex Computer Systems, ICECCS'07; 2007;
Washington, DC. https://doi.org/10.1109/ICECCS.2007.41
16. van Ommering RC, van der Linden F, Kramer J, Magee J. The koala component model for consumer electronics software. IEEE Comput.
2000;33(3):78-85.
17. Yu Z, Cai Y, Wang R, Han J. π-net ADL: an architecture description language for multi-agent systems. In: Huang D, Zhang X, Huang G, eds.
International Conference on Intelligent Computing. New York, NY. Springer; 2005. Lecture Notes in Computer Science; vol. 3645. https://
doi.org/10.1007/11538356_23
18. Mascolo C. MobiS: a specification language for mobile systems. In: Ciancarini P, Wolf AL, eds. Coordination Languages and Models, Third
International Conference, COORDINATION'99, Amsterdam, The Netherlands, April 26-28, 1999, Proceedings. New York, NY: Springer;
1999. Lecture Notes in Computer Science; vol. 1594. https://doi.org/10.1007/3-540-48919-3_5
19. Malavolta I, Lago P, Muccini H, Pelliccione P, Tang A. Architectural Languages Today. http://www.di.univaq.it/malavolta/al/. Published
June 2017. Accessed October 12, 2017.
20. Lago P, Malavolta I, Muccini H, Pelliccione P, Tang A. The road ahead for architectural languages. IEEE Softw. 2015;32(1):98-105. https://
doi.org/10.1109/MS.2014.28
21. Malavolta I, Lago P, Muccini H, Pelliccione P, Tang A. What industry needs from architectural languages: a survey. IEEE Trans Softw
Eng. 2012;39(6):869-891. http://doi.ieeecomputersociety.org/10.1109/TSE.2012.74
22. Milner R, Parrow J, Walker D. Calculus of mobile processes, I. Inf Comput. 1992;100(1):1-40.
23. Hoare CAR. Communicating sequential processes. Commun ACM. 1978;21(8):666-677.
24. Rozanski N, Woods E. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Upper Saddle River,
NJ: Addison-Wesley Professional; 2005.
25. Di Ruscio D, Malavolta I, Muccini H, Pelliccione P, Pierantonio A. Developing next generation ADLs through MDE techniques. Paper
presented at: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering, ICSE'10; 2010; New York, NY.
http://doi.acm.org/10.1145/1806799.1806816
26. Ozkaya M, Kloukinas C. Design-by-contract for reusable components and realizable architectures. In: Seinturier L, de Almeida ES, Carl-
son J, eds. Paper presented at: CBSE'14, Proceedings of the 17th International ACM SIGSOFT Symposium on Component-Based Software
Engineering (part of CompArch 2014), Marcq-en-Baroeul, Lille, France, June 30-July 4, 2014; 2014; New York, NY. http://doi.acm.org/
10.1145/2602458.2602463
27. Wang B, Wen C, Zhu W, Sheng J. AWright-ADL for aspectual component composition platform. Paper presented at: 2008 International
Symposium on Computer Science and Computational Technology; 2008; Shanghai, China. https://doi.org/10.1109/ISCSCT.2008.357
28. Pérez J, Ali N, Carsí JA, et al. Integrating aspects in software architectures: PRISMA applied to robotic tele-operated systems. Inf Softw
Technol. 2008;50(9-10):969-990. https://doi.org/10.1016/j.infsof.2007.08.007
29. Ali N, Ramos I, Solís C. Ambient-PRISMA: ambients in mobile aspect-oriented software architecture. J Syst Softw. 2010;83(6):937-958.
https://doi.org/10.1016/j.jss.2009.12.009; http://www.sciencedirect.com/science/article/pii/S0164121209003161. Software Architecture
and Mobility.
30. Ali N, Pérez J, Costa C, Ramos I, Carsí JA. Mobile ambients in aspect-oriented software architectures. In: Software Engineering Techniques:
Design for Quality. New York, NY: Springer; 2007:37-48. https://doi.org/10.1007/978-0-387-39388-9_4
31. McDuffie JH. Using the architecture description language MetaH for designing and prototyping an embedded reconfigurable sliding
mode flight controller. Paper presented at: Proceedings of the 21st Digital Avionics Systems Conference; 2002; Irvine, California. https://
doi.org/10.1109/DASC.2002.1052937
32. Debruyne V, Simonot-Lion F, Trinquet Y. EAST-ADL – an architecture description language. In: Architecture Description Languages.
New York, NY: Springer; 2005:181-195. https://doi.org/10.1007/0-387-24590-1_12
33. Dashofy EM, Hoek Avd, Taylor RN. A comprehensive approach for the development of modular software architecture description
languages. ACM Trans Softw Eng Methodol. 2005;14(2):199-245. http://doi.acm.org/10.1145/1061254.1061258
1012 OZKAYA

34. Ren J, Taylor RN. A secure software architecture description language. Paper presented at: Workshop on Software Security Assurance
Tools, Techniques, and Metrics, Co-located with the 20th IEEE/ACM International Conference on Automated Software Engineering
(ASE 2005); 2005; Long Beach, CA.
35. Garlan D, Monroe RT, Wile D. ACME: an architecture description interchange language. Paper presented at: Proceedings of CASCON'97;
1997; Toronto, ON.
36. Garlan D, Monroe RT, Wile D. Acme: architectural description of component-based systems. In: Foundations of Component-Based
Systems. New York, NY: Cambridge University Press; 2000:47-67. http://dl.acm.org/citation.cfm?id=336431.336437
37. Batista T, Chavez C, Garcia R, Kulesza U, Lucena C. Aspectual connectors: Supporting the seamless integration of aspects and ADLs.
Paper presented at: 20th Brazilian Symposium on Software Engineering (SBES); 2006; Florianopolis, Brazil.
38. Choppy C, Poizat P, Royer J. The Korrigan environment. J Univers Comput Sci. 2001;7(1):19-36. https://doi.org/10.3217/jucs-007-01-0019
39. Poizat P, Royer JC. A formal architectural description language based on symbolic transition systems and modal logic. J Univ Comput
Sci. 2006;12(12):1741-1782. https://doi.org/10.3217/jucs-012-12-1741; https://hal.archives-ouvertes.fr/hal-00342156
40. Taylor RN, Medvidovic N, Anderson KM, et al. A component- and message-based architectural style for GUI software. IEEE Trans
Software Eng. 1996;22(6):390-406.
41. Medvidovic N, Rosenblum DS, Taylor RN. A language and environment for architecture-based software development and evolution. In:
Boehm BW, Garlan D, Kramer J, eds. Paper presented at: Proceedings of the 1999 International Conference on Software Engineering,
ICSE'99; 1999; Los Angeles, CA. http://portal.acm.org/citation.cfm?id=302405.302410
42. Khare R, Guntersdorfer M, Oreizy P, Medvidovic N, Taylor RN. xADL: Enabling architecture-centric tool integration with XML. Paper
presented at: Proceedings of the 34th Annual Hawaii International Conference on System Sciences; 2001; Maui, Hawaii. https://doi.org/
10.1109/HICSS.2001.927248
43. Reussner RH, Schmidt HW, Poernomo IH. Reliability prediction for component-based software architectures. J Syst
Softw. 2003;66(3):241-252. https://doi.org/10.1016/S0164-1212(02)00080-8; http://www.sciencedirect.com/science/article/pii/
S0164121202000808. Software Architecture–Engineering Quality Attributes.
44. Canal C, Pimentel E, Troya JM. Specification and refinement of dynamic software architectures. In: Donohoe P, ed. Software Architecture.
New York, NY: Springer; 1999:107-126. IFIP Conference Proceedings; vol. 140.
45. Martínez AN, Pérez MA, Murillo JM. AspectLEDA: extending an ADL with aspectual concepts. In: Oquendo F, ed. Software Architecture,
First European Conference, ECSA 2007, Aranjuez, Spain, September 24-26, 2007, Proceedings. New York, NY: Springer; 2007:330-334.
Lecture Notes in Computer Science; vol. 4758. https://doi.org/10.1007/978-3-540-75132-8_36
46. Bruneton E, Coupaye T, Leclercq M, Quéma V, Stefani JB. The FRACTAL component model and its support in Java. Softw Pract Exper.
2006;36(11-12):1257-1284.
47. Bruneton E, Coupaye T, Leclercq M, Quéma V, Stefani J. An open component model and its support in Java. In: Crnkovic I, Stafford
JA, Schmidt HW, Wallnau KC, eds. Component-Based Software Engineering, 7th International Symposium, CBSE 2004, Edinburgh, UK,
May 24-25, 2004, Proceedings. New York, NY: Springer; 2004:7-22. Lecture Notes in Computer Science; vol. 3054. https://doi.org/10.1007/
978-3-540-24774-6_3
48. Pessemier N, Seinturier L, Coupaye T, Duchien L. A model for developing component-based and aspect-oriented systems. In: Software
Composition. New York, NY: Springer; 2006:259-274. https://doi.org/10.1007/11821946_17
49. Eterovich Y, Murillo JM, Palma K. Managing components adaptation using aspect oriented techniques. In: First International Workshop
on Coordination and Adaptation Techniques for Software Entities (WCAT04, held in conjunction with ECOOP 2004); 2004.
50. Dorfman M, Thayer RH. Standards, Guidelines and Examples: System and Software Requirements Engineering. Los Alamitos, CA: IEEE
Computer Society Press; 1990.
51. Pinto M, Fuentes L, Troya JM. Specifying aspect-oriented architectures in AO-ADL. Inf Softw Technol. 2011;53(11):1165-1182. https://
doi.org/10.1016/j.infsof.2011.04.003; http://www.sciencedirect.com/science/article/pii/S0950584911001005. AMOST 2010.
52. Jahanian F, Mok AK. Safety analysis of timing properties in real-time systems. IEEE Trans Softw Eng. 1986;12(9):890-904. http://dl.acm.
org/citation.cfm?id=12868.12870
53. Estrin G, Fenchel RS, Razouk RR, Vernon MK. SARA (System ARchitects Apprentice): modeling, analysis, and simulation support for
design of concurrent systems. IEEE Trans Softw Eng. 1986;SE-12(2):293-311. http://dl.acm.org/citation.cfm?id=9794.9805; https://doi.
org/10.1109/TSE.1986.6312945
54. Meyer B. Applying ‘design by contract’. IEEE Comput. 1992;25(10):40-51.
55. Richters M, Gogolla M. OCL: Syntax, semantics, and tools. In: Clark T, Warmer J, eds. Object Modeling with the OCL, The Rationale
behind the Object Constraint Language. New York, NY: Springer; 2002:42-68. Lecture Notes in Computer Science; vol 2263. https://doi.org/
10.1007/3-540-45669-4_4
56. Dunsire K, O'Neill T, Denford M, Leaney J. The ABACUS architectural approach to computer-based system and enterprise evolution.
Paper presented at: 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS'05);
2005. Greenbelt, MD. https://doi.org/10.1109/ECBS.2005.66
57. Magableh B, Barrett S. Primitive component architecture description language. Paper presented at: 7th International Conference on
Informatics and Systems (INFOS); 2010; Cairo, Egypt.
58. Rademaker A, Braga C, Sztajnberg A. A rewriting semantics for a software architecture description language. Electron Notes Theor Comput
Sci. 2005;130:345-377. https://doi.org/10.1016/j.entcs.2005.03.018
59. Loques O, Sztajnberg A, Curty R, Ansaloni S. A contract-based approach to describe and deploy non-functional adaptations in software
architectures. J Braz Comput Soc. 2004;10(1):5-20. https://doi.org/10.1007/BF03192350
60. Faucou S, Déplanche AM, Trinquet Y. An ADL centric approach for the formal design of real-time systems. In: Architecture Description
Languages. New York, NY: Springer; 2005:67-82. https://doi.org/10.1007/0-387-24590-1_5
OZKAYA 1013

61. Gruhn V, Schäfer C. Architecture description for mobile distributed systems using typed 𝜋-calculus. Electr Notes Theor Comput Sci.
2006;150(1):51-60. https://doi.org/10.1016/j.entcs.2005.12.023
62. Oussalah M, Smeda A, Khammaci T. An explicit definition of connectors for component-based software architecture. Paper presented
at: Proceedings of the 11th IEEE International Conference and Workshop on the Engineering of Computer-Based Systems; 2004; Brno,
Czech Republic.
63. Burback R. Distributed Architecture Definition Language: A DADL. Technical Report. Stanford, CA: Stanford University, InfoLab; 1998.
64. Balasubramanian D, Dubey A, Otte W, et al. DREMS ML: a wide spectrum architecture design language for distributed computing
platforms. Science of Computer Programming. 2015;106:3-29. https://doi.org/10.1016/j.scico.2015.04.002; http://www.sciencedirect.com/
science/article/pii/S0167642315000684. Special Issue: Architecture-Driven Semantic Analysis of Embedded Systems.
65. Jahanian F, Mok AK. Modechart: a specification language for real-time systems. IEEE Trans Softw Eng. 1994;20(12):933-947. https://doi.
org/10.1109/32.368134
66. Clements PC. Formal methods in describing architectures. Paper presented at: Proceedings of the Workshop on Formal Methods and
Architecture; 1995; Monterey, CA.
67. Becker S, Koziolek H, Reussner R. The Palladio component model for model-driven performance prediction. J Syst Softw. 2009;82(1):3-22.
https://doi.org/10.1016/j.jss.2008.03.066; http://www.sciencedirect.com/science/article/pii/S0164121208001015. Special Issue: Software
Performance - Modeling and Analysis.
68. Ricks KG, Weirs JM, Wells BE. SADL: simulation architecture description language. I J Comput Appl. 2002;9(3):126-138.
69. Wu Q, Li Y. ScudADL: an architecture description language for adaptive middleware in ubiquitous computing environments. Paper
presented at: 2009 ISECS International Colloquium on Computing, Communication, Control, and Management; 2009; Sanya, China.
https://doi.org/10.1109/CCCM.2009.5267500
70. Wu Q, Hu W, Ding W. A semantic and adaptive middleware architecture for pervasive computing systems. J Softw. 2009;4(10):1061-1068.
71. Mohammad M, Alagar VS. A formal approach for the specification and verification of trustworthy component-based systems. J Syst Softw.
2011;84(1):77-104. https://doi.org/10.1016/j.jss.2010.08.048
72. Kruchten P, Thompson CJ. An object-oriented, distributed architecture for large-scale Ada systems. Paper presented at: Proceedings of
the Conference on TRI-Ada '94, TRI-Ada '94; 1994; New York, NY. http://doi.acm.org/10.1145/197694.197728
73. Lau K, Tran CM. X-MAN: an MDE tool for component-based system development. In: Cortellessa V, Muccini H, Demirörs O, eds. 38th
Euromicro Conference on Software Engineering and Advanced Applications, SEAA 2012; September 5-8, 2012; Izmir, Turkey. https://
doi.org/10.1109/SEAA.2012.32
74. He N, Kroening D, Wahl T, et al. Component-based design and verification in X-MAN. Paper presented at: Proceedings of Embedded
Real Time Software and Systems; 2012; Toulouse, France.
75. Hamdaqa M, Tahvildari L. Stratus ML: A layered cloud modeling framework. Paper presented at: 2015 IEEE International Conference
on Cloud Engineering; 2015; Tempe, AZ. https://doi.org/10.1109/IC2E.2015.42
76. Terry A, Hayes-Roth F, Erman L, et al. Overview of Teknowledge's domain-specific software architecture program. SIGSOFT Softw Eng
Notes. 1994;19(4):68-76. http://doi.acm.org/10.1145/190679.190686
77. Shaw M, DeLine R, Klein DV, Ross TL, Young DM, Zelesnik G. Abstractions for software architecture and tools to support them. IEEE
Trans Softw Eng. 1995;21(4):314-335.
78. Moriconi M, Riemenschneider RA. Introduction to SADL 1.0: A Language for Specifying Software Architecture Hierarchies. Technical
Report SRI-CSL-97-01. SRI International; March 1997.
79. ADML document type definition. Group TO. http://www.opengroup.org/architecture/adml/adml_home.htm. Published December
1999. Accessed October 12, 2017.
80. Bellissard L, De Palma N, Féliot D. The Olan Architecture Definition Language. Technical Report. c3DS; 2000.
81. Balter R, Bellissard L, Boyer F, Riveill M, Vion-Dury JY. Architecturing and configuring distributed application with Olan. Paper pre-
sented at: Proceedings of the IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing; 1998;
The Lake District, UK. https://doi.org/10.1007/978-1-4471-1283-9_15
82. Chaudet C, Oquendo F. /spl pi/-space: A formal architecture description language based on process algebra for evolving software systems.
Paper presented at: The Fifteenth IEEE International Conference on Automated Software Engineering, ASE 2000; September 11-15, 2000.
Grenoble, France. https://doi.org/10.1109/ASE.2000.873669
83. Bernardo M, Ciancarini P, Donatiello L. ÆMPA: A process algebraic description language for the performance analysis of software archi-
tectures. Paper presented at: Proceedings of the 2nd International Workshop on Software and Performance, WOSP'00; 2000; New York,
NY. http://doi.acm.org/10.1145/350391.350394
84. Balsamo S, Bernardo M, Simeoni M. Combining stochastic process algebras and queueing networks for software architecture analysis.
Paper presented at: Proceedings of the 3rd International Workshop on Software and Performance, WOSP '02. ACM; 2002; New York, NY.
http://doi.acm.org/10.1145/584369.584398
85. Alloui I, Oquendo F. Supporting decentralised software-intensive processes using zeta component-based architecture description
language. In: Enterprise Information Systems III. Dordrecht, The Netherlands: Kluwer Academic Publishers; 2001.
86. Oliveira C, Wermelinger M, Fiadeiro JL, Lopes A. Modelling the GSM handover protocol in community. Electronic Notes in Theo-
retical Computer Science. 2005;141(3):3-25. https://doi.org/10.1016/j.entcs.2005.06.031; http://www.sciencedirect.com/science/article/
pii/S1571066105051637. Proceedings of the Second International Workshop on Formal Foundations of Embedded Software and
Component-based Software Architectures (FESCA 2005).
1014 OZKAYA

87. Fiadeiro JL, Lopes A, Wermelinger M. Chapter 5. A mathematical semantics for architectural connectors. In: Generic Programming:
Advanced Lectures. New York, NY: Springer; 2003:178-221. https://doi.org/10.1007/978-3-540-45191-4_5
88. Pinto M, Fuentes L, Troya JM. DAOP-ADL: an architecture description language for dynamic component and aspect-based devel-
opment. In: Generative Programming and Component Engineering. New York, NY: Springer;2003:118-137. https://doi.org/10.1007/
978-3-540-39815-8_8
89. Poizat P, Royer JC. Korrigan: A Formal ADL with Full Data Types and a Temporal Glue. Technical Report 83. Laboratoire de Methodes
Informatiques; 2003.
90. Roshandel R, Hoek AVD, Mikic-Rakic M, Medvidovic N. Mae—a system model and environment for managing architectural evolution.
ACM Trans Softw Eng Methodol. 2004;13(2):240-276. http://doi.acm.org/10.1145/1018210.1018213
91. Oquendo F. π-ADL: an architecture description language based on the higher-order typed π-calculus for specifying dynamic and mobile
software architectures. ACM SIGSOFT Software Engineering Notes. 2004;29(3):1-14. http://doi.acm.org/10.1145/986710.986728
92. Kruger IH, Mathew R. Systematic development and exploration of service-oriented software architectures. Paper presented at: Proceed-
ings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA 2004); 2004; Oslo, Norway. https://doi.org/10.1109/
WICSA.2004.1310701
93. Bashroush R, Brown TJ, Spence I, Kilpatrick P. ADLARS: An architecture description language for software product lines. Paper
presented at: 29th Annual IEEE/NASA Software Engineering Workshop; 2005; Greenbelt, MD. https://doi.org/10.1109/SEW.2005.17
94. Barais O, Duchien L. Safarchie studio: ArgoUML extensions to build safe architectures. In: Architecture Description Languages. Boston,
MA: Springer; 2005:85-100. https://doi.org/10.1007/0-387-24590-1_6
95. McVeigh A, Kramer J, Magee J. Using resemblance to support component reuse and evolution. Paper presented at: Proceedings of the
2006 Conference on Specification and Verification of Component-based Systems, SAVCBS '06; 2006; New York, NY. http://doi.acm.org/
10.1145/1181195.1181206
96. Oh Y, Lee DH, Kang S, Lee JH. Extended architecture analysis description language for software product line approach in embedded
systems. Paper presented at: Proceedings of the 5th IEEE/ACM International Conference on Formal Methods and Models for Codesign,
MEMOCODE '07; 2007; Washington, DC. https://doi.org/10.1109/MEMCOD.2007.371243
97. Pérez J, Ramos I, Martínez JJ, Letelier P, Navarro E. PRISMA: Towards quality, aspect oriented and dynamic software architectures.
Paper presented at: Proceedings of the Third International Conference on Quality Software; 2003; Dallas, TX.
98. Bashroush R, Spence I, Kilpatrick P, Brown J. Towards more flexible architecture description languages for industrial applications. In:
Software Architecture. New York, NY: Springer; 2006:212-219. https://doi.org/10.1007/11966104_16
99. Bashroush R, Spence ITA, Kilpatrick P, Brown TJ, Gilani W, Fritzsche M. ALI: An extensible architecture description language for
industrial applications. Paper presented at: 15th Annual IEEE International Conference and Workshop on Engineering of Computer
Based Systems (ECBS 2008); March 31-April 4, 2008; Belfast, Northern Ireland. https://doi.org/10.1109/ECBS.2008.55
100. Cervantes H, Donsez D, Touseau L. An architecture description language for dynamic sensor-based applications. Paper presented at:
2008 5th IEEE Consumer Communications and Networking Conference; 2008; Las Vegas, NV. https://doi.org/10.1109/ccnc08.2007.40
101. Op't Land M, Zwitzer H, Ensink P, Lebel Q. Towards a fast enterprise ontology based method for post merger integration. Paper presented
at: Proceedings of the 2009 ACM Symposium on Applied Computing, SAC '09; 2009; New York, NY. http://doi.acm.org/10.1145/1529282.
1529336
102. Cassou D, Bertran B, Loriant N, Consel C. A generative programming approach to developing pervasive computing systems. SIGPLAN
Not. 2009;45(2):137-146. http://doi.acm.org/10.1145/1837852.1621629
103. Zhang HY, Urtado C, Vauttier S. Architecture-centric component-based development needs a three-level ADL. In: Software Architecture.
New York, NY: Springer; 2010:295-310. https://doi.org/10.1007/978-3-642-15114-9_22
104. Haber A, Ringert JO, Rumpe B. MontiArc-Architectural Modeling of Interactive Distributed and Cyber-Physical Systems. Technical
Report. Aachen, Germany: RWTH Aachen University; February 2012. http://aib.informatik.rwth-aachen.de/2012/2012-03.pdf
105. Ringert JO, Rumpe B, Wortmann A. MontiArcAutomaton: Modeling architecture and behavior of robotic systems. Computing Research
Repository; 2014. http://arxiv.org/abs/1409.2310
106. Amirat A, Oussalah MC. First-class connectors to support systematic construction of hierarchical software architecture. J Object Technol.
2009;8(7):107-130. https://doi.org/10.5381/jot.2009.8.7.a3; http://www.jot.fm/contents/issue_2009_11/article3.html
107. Zheng L, Wu Z, Zhang C, Yang F. Developing an architecture description language for data processing product line. Paper presented at:
2010 Seventh International Conference on Information Technology: New Generations; 2010; Las Vegas, NV. https://doi.org/10.1109/
ITNG.2010.25
108. Plotkin GD. The origins of structural operational semantics. J Log Algebr Program. 2004;60-61:3-15. https://doi.org/10.1016/j.jlap.2004.
03.009
109. Schmidt DA. Denotational Semantics: A Methodology for Language Development. Dubuque, IA: William C. Brown Publishers; 1986.
110. Hervey SGJ. Axiomatic Semantics: A Theory of Linguistic Semantics. Edinburgh, Scotland: Scottish Academic Press; 1979.
111. Murata T. Petri nets: properties, analysis and applications. Proc IEEE. 1989;77(4):541-580. https://doi.org/10.1109/5.24143
112. Spivey JM. The Z Notation - A Reference Manual. 2nd ed. Oxford, England: Prentice Hall; 1992. Prentice Hall International Series in
Computer Science.
113. Meseguer J. Conditional rewriting logic: deduction, models and concurrency. In: Kaplan S, Okada M, eds. Conditional and Typed
Rewriting Systems. New York, NY: Springer; 1990:64-91. Lecture Notes in Computer Science; vol. 516.
114. Pnueli A. The temporal logic of programs. Paper presented at: SFCS '77 Proceedings of the 18th Annual Symposium on Foundations of
Computer Science; 1977; Washington, DC.
OZKAYA 1015

115. Smullyan RM. First-Order Logic. Berlin, Germany: Springer-Verlag; 1968.

116. Kifer M. Deductive and object data languages: a quest for integration. In: Deductive and Object-Oriented Databases. New York, NY:
Springer; 1995:187-212. https://doi.org/10.1007/3-540-60608-4_41
117. Cohen PR, Levesque HJ. Rational Interaction as the Basis for Communication. Technical Report 433. AI Center SRI International; April
1988.
118. Kurshan RP. Computer-Aided Verification of Coordinating Processes: The Automata-Theoretic Approach. Princeton, NJ: Princeton Uni-
versity Press; 1994.
119. Aarts F, Vaandrager F. Learning I/O automata. In: CONCUR 2010 - Concurrency Theory. New York, NY: Springer; 2010:71-85. https://
doi.org/10.1007/978-3-642-15375-4_6
120. Hopcroft JE, Motwani R, Ullman JD. Introduction to Automata Theory, Languages, and Computation. 3rd ed. Boston, MA: Addison-Wesley
Longman Publishing Co, Inc; 2006.
121. Quintero CEC, de la Fuente P, Barrio-Solórzano M, Gutiérrez MEB. Coordination in a reflective architecture description language. In:
Arbab F, Talcott CL, eds. Coordination Models and Languages. New York, NY: Springer; 2002:141-148. Lecture Notes in Computer Science;
vol 2315.
122. Jia X, Ying S, Zhang T, Cao H, Xie D. A new architecture description language for service-oriented architectures. Paper presented at:
Sixth International Conference on Grid and Cooperative Computing (GCC 2007); 2007; Los Alamitos, CA. https://doi.org/10.1109/GCC.
2007.18
123. Su G, Ying M, Zhang C. An ADL-approach to specifying and analyzing centralized-mode architectural connection. Software Architecture.
New York, NY: Springer; 2010:8-23. https://doi.org/10.1007/978-3-642-15114-9_4
124. Kamandi A, Habibi J. Toward a new analyzable architectural description language based on OSAN. Paper presented at: International
Conference on Software Engineering Advances (ICSEA 2007); 2007; Cap Esterel, France. https://doi.org/10.1109/ICSEA.2007.78
125. Kicillof N, Yankelevich D. Detecting and solving architectural problems with JACAL. Paper presented at: Proceedings of the 1st Australian
Workshop on Constructing Software Engineering Tools; 1998; Sydney, Australia.
126. Holzmann GJ. The model checker SPIN. IEEE Trans Softw Eng. 1997;23(5):279-295.
127. Jackson D. Alloy: a lightweight object modelling notation. ACM Trans Softw Eng Methodol. 2002;11(2):256-290.
128. Gardner Jr RI. A Methodology for Digital System Design Based on Structural and Functional Modeling [PhD thesis]. Los Angeles, CA:
University of California; 1974. AAI7514053.
129. Tracz W. LILEANNA: A parameterized programming language. Paper presented at: 1993 Proceedings Advances in Software Reuse; 1993;
Lucca, Italy. https://doi.org/10.1109/ASR.1993.291716
130. Luckham DC, Henke FW, Krieg-Brueckner B, Owe O. ANNA: A Language for Annotating Ada Programs. New York, NY: Springer; 1984.
131. Sitaraman M, Atkinson S, Kulczycki G, et al. Reasoning about software-component behavior. Paper presented at: Proceedings of the 6th
International Conference on Software Reuse: Advances in Software Reusability, ICSR-6; 2000; London, UK. http://dl.acm.org/citation.
cfm?id=645546.656050
132. Heym WD. Computer Program Verification: Improvements for Human Reasoning [PhD thesis]. Columbus, OH: Ohio State University;
1995. UMI Order No. GAX96-12193.
133. Gorlick M, Quilici A. Visual programming-in-the-large versus visual programming-in-the-small. Paper presented at: Proceedings of the
1994 IEEE Symposium on Visual Languages; 1994; St. Louis, MO. https://doi.org/10.1109/VL.1994.363631
134. Brachman RJ, McGuinness DL, Patel-Schneider PF, Resnick LA, Resnick LA, Borgida A. Living with CLASSIC: When and how to use a
KL-ONE-like language. In: Sowa J, ed. Principles of Semantic Networks: Explorations in the Representation of Knowledge. San Mateo, CA:
Morgan Kaufmann Publishers; 1991:401-456.
135. Medvidovic N, Oreizy P, Robbins JE, Taylor RN. Using object-oriented typing to support architectural design in the C2 style. SIGSOFT
Softw Eng Notes. 1996;21(6):24-32. http://doi.acm.org/10.1145/250707.239106
136. Inverardi P, Wolf AL. Formal specification and analysis of software architectures using the chemical abstract machine model. IEEE Trans
Softw Eng. 1995;21(4):373-386. https://doi.org/10.1109/32.385973
137. Berry G, Boudol G. The chemical abstract machine. Theoretical Computer Science. 1992;96(1):217-248. https://doi.org/10.1016/
0304-3975(92)90185-I; http://www.sciencedirect.com/science/article/pii/030439759290185I
138. Rice M, Seidman S. Using Z as a Substrate for an Architectural Style Description Language. Technical Report CS-96-120. Fort Collins,
CO: Department of Computer Science, Colarado State University; September 1996.
139. Georg G, Seidman S. The use of architecture description languages to describe a distributed measurement system. Paper presented at: 7th
IEEE International Symposium on Engineering of Computer-Based Systems (ECBS 2000); April 3-7, 2000; Edinburgh, Scotland. https://
doi.org/10.1109/ECBS.2000.839876
140. Tsai JJP, Xu K. Architecture specification of multimedia software systems. Paper presented at: Proceedings of the IEEE International
Conference on Multimedia Computing and Systems; 1999; Florence, Italy. https://doi.org/10.1109/MMCS.1999.779127
141. Issarny V, Bidan C. Aster: A framework for sound customization of distributed runtime systems. Paper presented at: Proceedings of
16th International Conference on Distributed Computing Systems; 1996; Hong Kong, Hong Kong. https://doi.org/10.1109/ICDCS.1996.
508009
142. Guttag JV, Horning JJ. Larch: Languages and Tools for Formal Specification. New York, NY: Springer-Verlag New York, Inc; 1993.
143. Arbab F, Rutten JJMM. A coinductive calculus of component connectors. In: Wirsing M, Pattinson D, Hennicker R, eds. Recent Trends
in Algebraic Development Techniques. New York, NY: Springer; 2002:34-55. WADT, Lecture Notes in Computer Science; vol. 2755.
144. Ciancarini P, Franzé F, Mascolo C. Using a coordination language to specify and analyze systems containing mobile components. ACM
Trans Softw Eng Methodol. 2000;9(2):167-198. http://doi.acm.org/10.1145/350887.350893
1016 OZKAYA

145. Ciancarini P, Mazza M, Pazzaglia L. A logic for a coordination model with multiple spaces. Sci Comput Program. 1998;31(2-3):231-261.
https://doi.org/10.1016/S0167-6423(97)00022-1
146. Bernardo M, Ciancarini P, Donatiello L. On the formalization of architectural types with process algebras. SIGSOFT Softw Eng Notes.
2000;25(6):140-148. http://doi.acm.org/10.1145/357474.355064
147. Mouratidis H, Kolp M, Faulkner S, Giorgini P. A secure architectural description language for agent systems. Paper presented at: Pro-
ceedings of the Fourth International Joint Conference on Autonomous Agents and Multiagent Systems, AAMAS'05; 2005; New York,
NY. http://doi.acm.org/10.1145/1082473.1082561
148. Bruni R, Lluch Lafuente A, Montanari U, Tuosto E. Architectural Design Rewriting as an Architecture Description Language. Technical
Report MSR-TR-2008-61. Microsoft Research; 2008.
149. Warshaw L, Miranker DP, Ulrich KS. Definition and application of a GenVoca component description language; 2007.
150. Kumar V. Algorithms for constraint-satisfaction problems: a survey. AI Mag. 1992;13(1):32-44. http://dl.acm.org/citation.cfm?id=140370.
140377
151. Bernardo M. Theory and Application of Extended Markovian Process Algebra [PhD thesis]. Padova, Venezia: University of Bologna;
February 1999.
152. Aldrich J, Chambers C, Notkin D. ArchJava: connecting software architecture to implementation. 2002:187-197.
153. Aldrich J, Chambers C, Notkin D. Architectural reasoning in ArchJava. Paper presented at: Proceedings of the 16th European Conference
on Object-Oriented Programming, ECOOP '02. Springer-Verlag; 2002; London, UK. http://dl.acm.org/citation.cfm?id=646159.680031
154. Lorenzo A, Ramos I, A Carsi J, Ferrer J. METAOASIS: An architecture description language for open distributed systems modeling. Paper
presented at: Proceedings of the 6th International Multiconference on Circuits, Systems, Communications and Computers (CSCC 2002);
2002; Phuket, Thailand.
155. Ciancarini P, Franze F, Mascolo C. A coordination model to specify systems including mobile agents. Paper presented at: Proceedings
of the 9th International Workshop on Software Specification and Design, IWSSD '98; 1998; Washington, DC. http://dl.acm.org/citation.
cfm?id=857205.858295
156. Plasil F, Visnovsky S. Behavior protocols for software components. IEEE Trans Softw Eng. 2002;28(11):1056-1076.
157. Bures T, Hnetynka P, Plasil F. Sofa 2.0: Balancing advanced features in a hierarchical component model. Paper presented at: Fourth
International Conference on Software Engineering Research, Management and Applications (SERA'06); 2006; Seattle, WA.
158. Fiadeiro JL. Categories for Software Engineering. New York, NY: Springer; 2005. https://doi.org/10.1007/b138249
159. Pradella M, Rossi M, Mandrioli D. ArchiTRIO: A UML-compatible language for architectural description and its formal seman-
tics. In: Formal Techniques for Networked and Distributed Systems - FORTE 2005. Berlin; Heidelberg: Springer-Verlag; 2005:381-395.
https://doi.org/10.1007/11562436_28
160. Furia CA, Mandrioli D, Morzenti A, Pradella M, Rossi M, San Pietro P. Higher-Order TRIO. Technical Report 2004.28. Dipartimento di
Elettronica e Informazione: Politecnico di Milano; September 2004.
161. Rao Y. Temporal logical-based web services architecture description. In: Grid and Cooperative Computing - GCC 2005. New York, NY:
Springer; 2005:214-219. https://doi.org/10.1007/11590354_31
162. Jing W, Shi Y, LinLin Z, YouCong N. AC2-ADL: Architectural description of aspect-oriented systems. Paper presented at: 2008 Adv Softw
Eng Appl; 2008; Hainan Island, China. https://doi.org/10.1109/ASEA.2008.11
163. Cardelli L, Gordon AD. Mobile ambients. In: Foundations of Software Science and Computation Structures. Berlin; Heidelberg:
Springer-Verlag; 1998:140-155. https://doi.org/10.1007/BFb0053547
164. Jerad C, Barkaoui K, Touzi AG. On the use of real-time Maude for architecture description and verification: A case study. Paper presented
at: Proceedings of the 2008 International Conference on Visions of Computer Science: BCS International Academic Conference, VoCS'08;
2008; Swindon, UK. http://dl.acm.org/citation.cfm?id=2227536.2227562
165. Li J, Pilkington NT, Xie F, Liu Q. Embedded architecture description language. J Syst Softw. 2010;83(2):235-252. https://doi.org/10.1016/
j.jss.2009.09.043; http://www.sciencedirect.com/science/article/pii/S0164121209002520. Computer Software and Applications.
166. Issarny V, Bennaceur A, Bromberg YD. Middleware-layer connector synthesis: Beyond state of the art in middleware interoperability.
In: Bernardo M, Issarny V, eds. Formal Methods for Eternal Networked Software Systems. New York, NY: Springer; 2011:217-255. SFM,
Lecture Notes in Computer Science; vol. 6659.
167. Magee J, Kramer J. Concurrency - State Models and Java Programs. 2nd ed. Hoboken, NJ: Wiley; 2006.
168. Harel D, Lachover H, Naamad A, et al. STATEMATE: A working environment for the development of complex reactive systems. Paper
presented at: Proceedings of the 10th International Conference on Software Engineering; April 11-15, 1988; Singapore, Singapore. http://
dl.acm.org/citation.cfm?id=55861
169. Harel D, Naamad A. The STATEMATE semantics of statecharts. ACM Trans Softw Eng Methodol. 1996;5(4):293-333. http://doi.acm.org/
10.1145/235321.235322
170. Robert Krut J. Integrating 001 tool support into the feature-oriented domain analysis methodology. Pittsburgh, PA: Software Engineering
Institute, Carnegie Mellon University; 1993. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=11881
171. Peterson AS, Stanley Jr JL. Mapping a Domain Model and Architecture to a Generic Design. Technical Report. Pittsburgh, PA: Software
Engineering Institute, Carnegie Mellon University; 1994.
172. Rumbaugh J, Jacobson I, Booch G. Unified Modeling Language Reference Manual. 2nd ed. London, UK: Pearson Higher Education; 2004.
173. Mei H, Chen F, Wang Q, Feng Y. ABC/ADL: An ADL Supporting Component Composition. In: Formal Methods and Software Engineering.
New York, NY: Springer; 2002:38-47. https://doi.org/10.1007/3-540-36103-0_6
OZKAYA 1017

174. Raunak MS, Osterweil LJ. Process definition language support for rapid simulation prototyping. In: Unifying the Software Process
Spectrum. Berlin; Heidelberg: Springer-Verlag; 2005. https://doi.org/10.1007/11608035_34
175. Zhang Q. Visual software architecture description based on design space. Paper presented at: The Eighth International Conference on
Quality Software; 2008; Oxford, UK. https://doi.org/10.1109/QSIC.2008.59
176. Ubayashi N, Nomura J, Tamai T. Archface: a contract place where architectural design and code meet together. In: Kramer J, Bishop J,
Devanbu PT, Uchitel S, eds. ICSE. Paper presented at: 2010 ACM/IEEE 32nd International Conference on Software Engineering; 2010;
Cape Town, South Africa.
177. Elloy JP, Simonot-Lion F. An architecture description language for in-vehicle embedded system development. IFAC Proceed-
ings Volumes. 2002;35(1):349-354. https://doi.org/10.3182/20020721-6-ES-1901.00060; http://www.sciencedirect.com/science/article/
pii/S1474667015384810. 15th IFAC World Congress.
178. Suvee D, Fraine BD, Cibran MA, et al. Evaluating FuseJ as a Web service composition language. Paper presented at: Third European
Conference on Web Services (ECOWS'05); 2005; Vaxjo, Sweden. https://doi.org/10.1109/ECOWS.2005.13
179. Kum D, Park GM, Lee S, Jung W. AUTOSAR migration from existing automotive software. Paper presented at: 2008 International
Conference on Control, Automation and Systems; 2008; Seoul, South Korea. https://doi.org/10.1109/ICCAS.2008.4694565
180. Kang B, Lee MK. HappyWork: A software architecture design environment. July 2004.
181. Lankhorst M, Proper H, Jonkers H. The anatomy of the archimate language. Int J Inf Syst Model Des. 2010;1(1):1-32. https://doi.org/10.
4018/jismd.2010092301
182. Lankhorst MM, Proper HA, Jonkers H. The Architecture of the ArchiMate Language. In: Enterprise, Business-Process and Information
Systems Modeling. New York, NY: Springer; 2009:367-380. https://doi.org/10.1007/978-3-642-01862-6_30
183. Monroe RT. Capturing Software Architecture Design Expertise with Armani. Technical Report CMU-CS-98-163. Pittsburgh, PA: Carnegie
Mellon University; 1996.
184. Eixelsberger W, Gall HC. Describing software architectures by system structure and properties. Paper presented at: COMPSAC'98 - 22nd
International Computer Software and Applications Conference; August 19-21, 1998; Vienna, Austria. https://doi.org/10.1109/CMPSAC.
1998.716645
185. Schmerl B. xAcme: CMU Acme extensions to xArch. http://www.cs.cmu.edu/~acme/pub/xAcme/. Published March 23, 2001. Accessed
October 15, 2017.
186. Weinreich R, Buchgeher G. Paving the road for formally defined architecture description in software development. Paper presented at:
Proceedings of the 2010 ACM Symposium on Applied Computing, SAC'10; 2010; New York, NY. http://doi.acm.org/10.1145/1774088.
1774571
187. Lamport L. The temporal logic of actions. ACM Trans Program Lang Syst. 1994;16(3):872-923. http://doi.acm.org/10.1145/177492.177726
188. Truszkowski W. Advances in knowledge-based software engineering. Paper presented at: Proceedings of the 2nd National Technology
Transfer Conference and Exposition. NASA Goddard Space Flight Center; 1991; Greenbelt, MD. https://ntrs.nasa.gov/archive/nasa/casi.
ntrs.nasa.gov/19920013227.pdf
189. Bailin SC, Moore JM. KAPTUR: Knowledge Acquisition for Preservation of Tradeoffs and Underlying Rationales. Technical Report.
Rockville, MD: CTA Incorporated; 1991.
190. Garlan D, Allen R, Ockerbloom J. Exploiting style in architectural design environments. SIGSOFT Softw Eng Notes. 1994;19(5):175-188.
http://doi.acm.org/10.1145/195274.195404
191. Schwanke RW, Strack VA, Werthmann-Auzinger T. Industrial software architecture with Gestalt. Paper presented at: Proceedings of the
8th International Workshop on Software Specification and Design; 1996; Schloss Velen, Germany. https://doi.org/10.1109/IWSSD.1996.
501164
192. Selic B. Tutorial: Real-time object-oriented modeling (ROOM). Paper presented at: Proceedings Real-Time Technology and Applications;
1996; Brookline, MA. https://doi.org/10.1109/RTTAS.1996.509538
193. Reid A, Flatt M, Stoller L, Lepreau J, Eide E. Knit: Component composition for systems software. Paper presented at: Proceedings of the
4th Conference on Symposium on Operating System Design & Implementation, OSDI'00; 2000; Berkeley, CA. http://dl.acm.org/citation.
cfm?id=1251229.1251253
194. Bouzoualegh A, Marcadet D, Boulanger F, Jacquet C. An architecture description language for verification in component-based soft-
ware. Paper presented at: 2008 32nd Annual IEEE International Computer Software and Applications Conference; 2008. Turku, Finland.
https://doi.org/10.1109/COMPSAC.2008.107
195. Jacquet C, Boulanger F, Marcadet D. From data to events: Checking properties on the control of a system. Paper presented at: 6th ACM
& IEEE International Conference on Formal Methods and Models for Co-Design (MEMOCODE 2008); June 5-7, 2008; Anaheim, CA.
https://doi.org/10.1109/MEMCOD.2008.4547682
196. Tibermacine C, Dony C, Sadou S, Fabresse L. Software architecture constraints as customizable, reusable and composable entities.
Software Architecture. New York, NY: Springer; 2010:505-509. https://doi.org/10.1007/978-3-642-15114-9_51
197. Tibermacine C, Sadou S, Dony C, Fabresse L. Component-based specification of software architecture constraints. Paper presented at:
Proceedings of the 14th International ACM Sigsoft Symposium on Component Based Software Engineering, CBSE '11; 2011; Boulder,
CO. http://doi.acm.org/10.1145/2000229.2000235
198. Phillips ANJB. Specifying and Implementing Secure Mobile Applications in the Channel Ambient System [PhD
thesis]. London, UK: University of London; April 2006. https://www.microsoft.com/en-us/research/publication/
specifying-and-implementing-secure-mobile-applications-in-the-channel-ambient-system/
199. Batory D, Coglianese L, Goodwin M, Shafer S. Creating reference architectures: an example from avionics. SIGSOFT Softw Eng Notes.
1995;20(SI):27-37. http://doi.acm.org/10.1145/223427.211786
1018 OZKAYA

200. de Silva L, Balasubramaniam D. A model for specifying rationale using an architecture description language. Software Architecture. New
York, NY: Springer; 2011:319-327. https://doi.org/10.1007/978-3-642-23798-0_34
201. Smeda A, Oussalah M, Khammaci T. A multi-paradigm approach to describe software systems. Paper presented at: Proceedings of the
WSEAS International Conferences on Software Engineering, Parallel and Distributed Systems; 2004; Salzburg, Austria.
202. Ryoo J, Saiedian H. AVDL: a highly adaptable architecture view description language. J Syst Softw. 2006;79(8):1180-1206. https://doi.org/
10.1016/j.jss.2006.02.045; http://www.sciencedirect.com/science/article/pii/S0164121206000690
203. Singhal V, Batory D. P++: a language for large-scale reusable software components. Paper presented at: Proceedings of the Sixth Annual
Workshop on Software Reuse; 1993; Owego, NY.
204. Thum C, Schwind M, Schader M. SLIM–a lightweight environment for synchronous collaborative modeling. In: Model Driven Engineering
Languages and Systems. Berlin; Heidelberg: Springer-Verlag; 2009. https://doi.org/10.1007/978-3-642-04425-0_11
205. De Lucia A, Fasano F, Scanniello G, Tortora G. Enhancing collaborative synchronous UML modelling with fine-grained versioning of
software artefacts. J Vis Lang Comput. 2007;18(5):492-503. https://doi.org/10.1016/j.jvlc.2007.08.005
206. Mehra A, Grundy J, Hosking J. A generic approach to supporting diagram differencing and merging for collaborative design. Paper
presented at: Proceedings of the 20th IEEE/ACM International Conference on Automated Software Engineering, ASE '05; 2005; New
York, NY. http://doi.acm.org/10.1145/1101908.1101940
207. Medvidovic N, Dashofy EM, Taylor RN. Moving architectural description from under the technology lamppost. Inf Softw Technol.
2007;49(1):12-31. https://doi.org/10.1016/j.infsof.2006.08.006
208. Hilliard R, Rice T. Expressiveness in architecture description languages. Paper presented at: Proceedings of the Third International
Workshop on Software Architecture, ISAW'98; 1998; New York, NY. http://doi.acm.org/10.1145/288408.288425
209. Ali N, Solís C, Ramos I. Comparing architecture description languages for mobile software systems. Paper presented at: Proceedings
of the 1st International Workshop on Software Architectures and Mobility, SAM'08; 2008; New York, NY. http://doi.acm.org/10.1145/
1370888.1370897
210. Mckenzie FD, Petty MD, Xu Q. Usefulness of software architecture description languages for modeling and analysis of federates and
federation architectures. Simulation. 2004;80(11):559-576. https://doi.org/10.1177/0037549704050185
211. Qin W, Malik S. Architecture description languages for retargetable compilation. The Compiler Design Handbook. 2nd ed; Boca Raton,
FL: CRC Press; 2007:16.
212. Mishra P, Dutt N. Architecture description languages for programmable embedded systems. IEE Proc - Comput Digital Tech.
2005;152(3):285-297. https://doi.org/10.1049/ip-cdt:20045071
213. Rost D, Naab M, Lima C, von Flach Garcia Chavez C. Software architecture documentation for developers: A survey. In: Software
Architecture. New York, NY: Springer; 2013:72-88. https://doi.org/10.1007/978-3-642-39031-9_7
214. Babar MA, Gorton I. Software architecture review: the state of practice. Computer. 2009;42:26-32. https://doi.ieeecomputersociety.org/
10.1109/MC.2009.233
215. Ameller D. How do software architects consider non-functional requirements: An exploratory study. Paper presented at: Proceedings of
the 2012 IEEE 20th International Requirements Engineering Conference (RE), RE'12; 2012; Washington, DC. https://doi.org/10.1109/
RE.2012.6345838
216. Tofan D, Galster M, Avgeriou P. Difficulty of architectural decisions – A survey with professional architects. In: Software Architecture.
New York, NY: Springer; 2013:192-199. https://doi.org/10.1007/978-3-642-39031-9_17

How to cite this article: Ozkaya M. The analysis of architectural languages for the needs of practitioners. Softw
Pract Exper. 2018;48:985–1018. https://doi.org/10.1002/spe.2561