Information and Software Technology 95 (2018) 15–33

Contents lists available at ScienceDirect

Information and Software Technology

journal homepage: www.elsevier.com/locate/infsof

Do the informal & formal software modeling notations satisfy practitioners T

for software architecture modeling?
Mert Ozkaya
Altinbas University, Department of Computer Engineering, Istanbul TURKEY

A R T I C L E I N F O A B S T R A C T

Keywords: Context: Software architectures can be modeled using semantically informal (i.e., ambiguous) or formal (i.e.,
A survey mathematically precise) software modeling notations.
Software architectures Objective: In this paper, 115 different practitioners from 28 different countries who work in companies that
Informal/formal semantics perform software development have been surveyed. The goal is to understand practitioners’ knowledge and
ADLs
experience about informal and formal modeling notations in specifying software architectures.
UML
Formal specification languages
Method: The survey consists of 35 different questions, divided into three parts, i.e., the participant profile, the
informal modeling, and formal modeling. The results of the survey lead to many interesting findings:
Results: (1) Informal software modeling notations (especially UML) are practitioners’ top choice in specifying
software architectures (94%). (2) Despite many informal languages, some practitioners (40%) insist using in-
formal ad-hoc techniques (i.e., simple boxes/lines and natural languages) to specify complex design decisions
(e.g., structure, behaviour, and interaction). (3) Practitioners using informal notations are impressed by their
low learning-curve (79%), visuality (62%), and general-purpose scope (66%). (4) Practitioners still criticise
informal notations too, essentially for the lack of support for complex design decisions and their exhaustive
analysis. (5) While formal modeling notations bridge this gap mentioned in step-4, many practitioners (70%)
rarely use formal notations due essentially to the high-learning curve, the lack of knowledge among stake-
holders, and the lack of popularity in industry. (6) Among the considered formal notations (i.e., process algebras,
high-level formal specification languages, and architecture description languages (ADLs)), process algebras are
never used and ADLs are the least used formal languages are ADLs (i.e., 12% frequently use ADLs). (7)
Practitioners complain about ADLs’ weak tool support (38%) and their lack of tutorials/guidance/etc (33%).
Conclusion: The survey results will let the community realise the advantages and disadvantages of informal and
formal modeling notations for software architecture modeling from practitioners’ viewpoint.

1. Introduction different stakeholders, analysed for design errors, and improved to

Software architectures have been proposed in the nineties as a way
of specifying important design decisions for software systems and their
reasoning. As Garlan and Shaw proposed in their seminal work [1],
several complex design decisions, including structural (i.e., the com-
ponents and connectors), behavioural (the component behaviours),
interaction (the interaction protocols), non-functional property (e.g.,
reliability and performance), and concurrency (i.e., synchronisation
and data access) decisions can be specified and reasoned about at the
early stages of software design.
1.1. Software architecture modeling
Design decisions made for a software system to be built are docu-
mented as an architectural model, which can be communicated among
better meet the software requirements [2]. Architecture modeling is
performed via the modeling notations that allow for textually or vi-
sually representing the architectural models at various levels of ab-
stractions. Architectural modeling notations can be considered as
simple as any natural language or simple boxes/lines or any modeling
languages with syntax and semantics (e.g., ADLs [3]). Modeling nota-
tions can be distinguished in various aspects, such as the textual/visual
specifications of software architectures, semantical basis, general-pur-
pose/domain-specific scope, language features (e.g., extensibility,
multiple views, etc.), and tool support for different operations (e.g.,
analysis and code generation). In this study, architectural modeling
notations are considered based on their semantical basis, which can be
defined either formally or informally. The software modeling notations
with formal semantics (aka formal modeling notations) are defined
mathematically using formal methods [4]. Formal modeling notations

E-mail address: mert.ozkaya@kemerburgaz.edu.tr.

https://doi.org/10.1016/j.infsof.2017.10.008
Received 16 May 2017; Received in revised form 30 September 2017; Accepted 12 October 2017
Available online 13 November 2017
0950-5849/ © 2017 Elsevier B.V. All rights reserved.
M. Ozkaya
enable precision, which promotes the detailed and exact specifications
of software architectures. Also, formal architectural models can be
analysed exhaustively using the formal techniques such as model
checking and theorem proving, which are based on mathematical
proofs. The software modeling notations without formally defined se-
mantics are called as informal modeling notations in this paper. The
semantics of informal modeling notations are either defined informally
in plain English or semi-formally. Lacking in precision, informal nota-
tions may not always enable specifying the details of software archi-
tecture models and thus the resulting models may be ambiguous that
can be interpreted by different stakeholders differently.
1.1.1. Informal modeling notations
Informal architecture modeling notations can be considered in three
groups, i.e., (i) simple boxes/lines, (ii) natural languages (e.g., English),
and (iii) modeling languages. Natural languages (e.g., English) and
simple boxes/lines allow for specifying any complex design decisions
without having to stick to any notations. Note that the former is textual
and the latter is graphical. However, the specifications in natural lan-
guages and simple boxes/lines may not be executed via analysis tools
for, e.g., syntax/semantics checking, behaviour analysis or code gen-
eration.
Unlike natural languages and simple boxes/lines techniques, in-
formal software modeling languages offer concrete notations that have
well-defined syntax and semi-formal semantics (if any). UML [5] is one
of the most well-known informal modeling languages, which offers
visual diagram types for specifying several important design decisions
including structural, behavioural, interaction, and deployment. UML
has inspired many other informal modeling languages (e.g., SysML [6],
Secure-UML [7], and Agent-UML [8]), which either extend UML’s no-
tation for meeting new requirements or adapt UML for particular do-
mains. Besides UML and its derivatives, there are architecture de-
scription languages (ADLs) that offer architecture-oriented notation sets
consisting of architectural elements such as components, ports, con-
nectors, and connections [3,9]. The literature includes tens of different
ADLs that vary in many aspects, such as tool support, language features
(e.g., extensibility and multiple views), language definition (e.g., tex-
tual/visual notation sets or formal/informal semantics)1. Some other
informal notations include the domain-specific languages (e.g., Liszt
[10] for PDE solvers and NDL [11] for device derivers), Business Pro-
cess Modeling Languages (BPMLs) [12], etc.
1.1.2. Formal modeling notations
Formal modeling notations can be examined in two parts, i.e., (i)
formal specification languages and (ii) formal ADLs. Formal specifica-
tion languages offer notations for precisely specifying complex design
decisions, which can then be formally (i.e., exhaustive) analysed
against safety and liveness properties. Some formal languages are also
supported with the formal analysis tools that exhaustively check for
non-functional properties. The most common formal specification lan-
guages are process algebras [13], which allow for specifying systems in
terms of processes that interact with each other concurrently (e.g., CSP
[14], FSP [15], and pi-calculus [16]). There are also high-level formal
specification languages that practitioners can more easily learn and use
for specifying their software systems. Some of them offer general-pur-
pose scope (e.g., ProMeLa [17], LOTOS [18], and Alloy [19]); some
offer domain-specific scopes (e.g., UPPAAL’s input language [20] for
real-time systems); and, some are platform-specific (e.g., Java Modeling
Language (JML) [21] for Java and Spec# [22] for C#).
The formal ADLs are considered in this survey as the ADLs that offer
formally precise architecture-oriented notation sets. Formal ADLs are
1
The following link leads to the up-to-date list of ADLs and those indicated to have no
formally defined semantics are the informal ADLs: https://sites.google.com/site/
ozkayamert1/als.
16
Information and Software Technology 95 (2018) 15–33
examined here in three groups, i.e., early general purpose ADLs, do-
main-specific ADLs, and extensible ADLs. General-purpose ADLs (e.g.,
Wright [23], Darwin [24], and Rapide [25]) offer high-level notation
sets for specifying any types of systems and mainly focus on the formal
analysis of architectural specifications. Domain-specific ADLs (e.g.,
AADL [26] for embedded systems) offer relatively low-level (i.e., more
detailed) notation sets for the domain of interest. They essentially tend
to focus on formally analysing the low-level specifications for non-
functional properties (e.g., AADL’s tools for performance analysis) and
generating low-level software code (AADL’s tool for C code). Lastly,
extensible ADLs’ notation sets (e.g., e.g., Acme [27] and XADL [28])
allow practitioners to extend a generic language with several features
such as formal semantics, formal analysis, complex connectors, and tool
support.
1.2. Paper motivation and goal
While there are too many informal and formal software modeling
notations existing today, it is not possible to understand (i) practi-
tioners’ knowledge and experience about informal and formal modeling
notations and (ii) what motivate/demotivate practitioners for using
either type of the notations. The existing analytical studies on software
architectures and modeling languages rather focus on different issues
including the definition of software architecture, practitioners’ needs
and concerns about software architecture, ADLs’ support for several
different features (e.g., expressiveness, tool support, analysis, usability,
realisability), or practitioners’ expectations from ADLs.
Therefore, in this study, a survey has been conducted, which focuses
on understanding the practitioners’ level of knowledge and experience
and their views about the informal and formal software architecture
modeling notations. With the survey results discussed in this paper, the
goal is to enlighten the software architecture community about the
level of tendency towards informal and formal modeling notations and
their motivating/demotivating features for practitioners. It will also be
possible to learn about the popular informal and formal software
modeling notations that practitioners highly prefer for software archi-
tecture specifications or the notations that are rarely used.
1.3. Paper structure
In the rest of the paper, the similar surveys in the literature are
discussed firstly. Next, the survey’s research questions are introduced,
which is followed by the explanations of the survey design, execution,
and sampling respectively. Then, the survey results are discussed sta-
tistically in three parts, i.e., the participants profile, informal archi-
tecture modeling notations, and formal modeling notations respec-
tively. Lastly, the discussion and conclusion are given.
2. Related work
According to the up-to-date research of literature, there are more
than 120 different known architecture modeling notations2, which can
be categorised based on their semantics definitions as discussed in
Sections 1.1.1 and 1.1.2 (i.e., formal or informal). Unsurprisingly, UML
is by far the top-used informal modeling language by practitioners [29],
which inspired many other notations, e.g., Systems Modeling Language
(SysML) [6] for system engineering requirements, Agent-UML [8] for
the specifications of multi-agent software systems, and Secure-UML [7]
for the specifications of non-functional properties and their analysis.
Some modeling notations even formalise UML for the precise specifi-
cations of UML architectures and their formal analysis. UMLsec [30] is
one of the most prominent UML extension that formalises UML for the
2
See the analysis of the architecture modeling notations in https://sites.google.com/
site/ozkayamert1/als.
M. Ozkaya
formal specification and analysis of security properties. Among the
formal modeling notations, AADL is one of the top-used one by prac-
titioners [29], which offers domain-specific notation set for specifying
the multiple views (i.e., logical, physical, deployment, and behaviour)
of embedded system architectures. AADL is also supported with a
powerful toolset for the verifications of embedded system specifications
against many non-functional properties, e.g., performance, schedul-
ability, security, and reliability. Despite so many formal and informal
modeling notations that exist, literature analysis shows that there is not
any study made on the practitioners’ knowledge and experience about
formal and informal software modeling notations. So, it is not easy to
understand to what extent the practitioners use either type of notations,
and their motivation/demotivation in doing so. Moreover, there is also
not any analytical study that allows practitioners to find out the formal
and informal software modeling notations and compare the modeling
notations based on their needs. In the rest of this section, the existing
survey studies are discussed in two parts. Firstly, the surveys about
software architectures are discussed and this is followed by discussions
of the surveys conducted on software modeling notations.
2.1. Surveys on software architectures
The literature includes many surveys on software architectures that
intend to shed light on various issues about software architectures.
However, none of these surveys consider the formal (i.e., precise and
exhaustively analysable) and informal (i.e., ambiguous) specifications
of software architectures and tried to observe practitioners’ knowledge
and experience about both types of specifications, which is essentially
the main point of interest in this paper. As discussed in the rest of this
sub-section, the current surveys essentially focus on such issues of
software architectures as specifying design decisions, reviewing soft-
ware architectures, and quality requirements, and try to understand
practitioners’ concerns or perspectives about those issues. Moreover,
unlike the author’s survey conducted as questionnaire, most of the
current surveys on software architectures have been performed as in-
terviews. Therefore, these surveys may be relatively subjective that
could reflect the ideas of the interviewers and applied on a smaller
sample.
In [31], Tang et al. conducted a survey (with 39 questions) among
81 participants, consisting of the architects/designers working in in-
dustry and some post-graduate students, to understand their knowledge
and experience in documenting different design decisions. Their survey
also focussed on the reasons from the architects’ perspectives that de-
motivate them for specifying the design decisions and also the possible
improvements. In [32], Babar and Gorton aimed in their survey at
analysing software architecture reviewing for the purpose of ensuring
the quality of design decisions. Babar and Gorton’s survey consists of 26
questions, answered by 86 different participants who hold one of the
following job positions, i.e., software developer, executive/manager,
project manager, business analyst, and architect. In [33], Soni et al.
interviewed many architects who are involved in the design process of
large software systems from diverse domains (i.e., real-time operating
systems, communication systems, instrumentation and control systems,
image and signal processing systems, and user interface systems). They
focussed on the issues about the role of software architecture in de-
signing and developing large software systems. In [34], Christensen
et al. conducted a survey on software architects to better understand
their concerns about several aspects of software architectures including
analysis & design, realisation, management, and interaction. Chris-
tensen et al. have chosen 4 well-known Danish companies and inter-
viewed and observed the architects in the companies 31 times during 5
months. Christensen et al. determined and analysed 124 different si-
tuations of architects (i.e., the different types of works that they per-
form). In [35], Caracciolo et al. conducted a survey to determine the
quality requirements of interest for architects and the approaches pre-
ferred in specifying and formally analysing those requirements.
17
Information and Software Technology 95 (2018) 15–33
Caracciolo et al. interviewed 14 architects from 6 different companies.
They focus on 7 different key quality requirements, which are perfor-
mance, compatibility, usability, reliability, security, maintainability,
and portability. In [36], Smolander et al. surveyed among 3 different
organisations that produce telecommunications software, IT software,
and handheld software development. Smolander et al. interviewed for
each organisation 3–4 people who are architects, designers, or man-
agers, and tried to understand what software architecture is to these
people in terms of four different views, i.e., blueprint (logical compo-
nents and their relationships), language (i.e., notation), decision (e.g.,
behavioural, interaction and concurrency decisions), and literature
(i.e., documenting software architectures).
2.2. Surveys on software architecture modeling notations
Besides the surveys about software architectures, the literature also
includes many surveys on architectural modeling notations. Those
surveys focus on a group of architecture modeling notations (e.g., UML-
based languages) and analyse their level of support for some particular
features, (e.g., expressiveness, usability, and realisability) or particular
domains (e.g., mobile systems and self-managing systems). Some of the
surveys have been conducted over the practitioners to understand their
lack of interest about architectural modeling notations in general.
However, unlike the author’s survey in this paper, none of the existing
surveys consider the formal and informal semantics definitions of
modeling notations. It is not possible to understand practitioners’ point
of view about the informal and formal modeling notations and their
choice of use between the two types of notations.
Clements [37] and Medvidovic [3] have proposed their own fra-
mework that categorise ADLs based on a number of requirements that
the authors focussed in defining ADLs. Clements and Medvidovic sur-
veyed a small group of 8–9 ADLs that they have determined for asses-
sing their framework. Medvidovic et al. later on conducted another
survey in 2006, where they again categorised 8 different ADLs based on
their definition of the ”three lamppost” (i.e., technology, domain, and
business) [38]. In [39], Hilliard and Rice focussed on the possible issues
that affect the expressiveness of the ADLs proposed in the nineties,
including multiple viewpoints, first-class elements, architectural pat-
terns, and the specifications of client requirements and architects’ de-
sign decisions separately. In [40], Zhang et al. surveyed among 17
different formal modeling notations, consisting of formal ADLs and
formal specification languages, which have the potential to be used for
model checking. Zhang et al. focused on understanding their for formal
model checking and analysed those 17 formal notations in terms of
their support for (i) the software architecture specifications, (ii) the
non-functional property specifications, and (iii) the model checking
support. In [41], Bradbury et al. surveyed 14 different formal software
modeling notations to determine their support for the architectural
specifications of self-managing software systems. Bradbury et al. ana-
lysed the formal notations for the expressiveness and scalability, which
they consider as the two important language features for maximising
the support for self-management. In [42], Pandey surveyed 9 different
ADLs so as to understand the reasons why ADLs are shown lack of in-
terest by the practitioners in industry and compared the ADLs with the
widely accepted UML language. In [9], Ozkaya et al. surveyed among
13 different ADLs that are grouped as first- (proposed in the nineties)
and second-generation ADLs (proposed after 2000s) and analysed for
three key features that the authors focussed in their study, i.e., us-
ability, formal analysis, and realisability. In [29], Malavolta et al.
conducted a comprehensive survey of 52 questions among 48 practi-
tioners from 40 companies in 15 countries. Their goal was to under-
stand practitioners’ expectations from architecture modeling notations
in general, focussing on the advantages and disadvantages of archi-
tecture modeling notations from practitioners’ perspective. In [43], Ali
et al. surveyed among 8 different ADLs that support the software ar-
chitecture specifications of distributed and mobile systems. Ali et al.’
M. Ozkaya
survey aimed at understanding the level of support that the ADLs in
question provide for mobile systems. The survey focussed on several
features, including location, graphical support, formalisation, mobility,
and tool support. In [44], Balsamo et al. surveyed among 15 different
modeling notations to understand their support for system performance
predictions. These 15 notations are grouped as queueing network based
notations, process-algebra-based notations, petri-net-based notations,
the notations based on stochastic processes. Balsamo et al.’s survey
analysed each notation for the software architecture specifications,
performance model specifications, the evaluation methods, and tool
support for the automated analysis of performance. In [45], Bernardi
et al. surveyed among 39 different UML-based modeling notations that
support the specifications of system dependability and their analysis.
Bernardi et al. analysed these approaches for three groups of criteria,
i.e., the software development support (e.g., types of UML diagrams
used, tool support, supported domains, supported phases of software
development), the dependability characteristics (e.g., the attributes of
dependability considered, the type of the dependability analysis used,
and the analysis models used), and the quality of the surveyed notations
(e.g., the use of any dependability standards, validation via case-stu-
dies, and the presentation of the analysis results).
3. Research questions
Given the goal of this survey in Section 1.2, the following eight
research questions are defined that need to be answered so as to meet
the goal.
RQ 1: What are the profiles of the participants?
To minimise any threats against the validity of the survey results,
the survey should target participants from various background who can
be generalised to the entire population of software development. This
includes people from different countries, with education degrees/levels,
holding different job positions, working in different types of projects,
and with different levels of experience and knowledge in software de-
velopment.
RQ 2: Which informal software modeling notations are mainly used by
practitioners?
This question is intended for learning the informal software mod-
eling notations used by practitioners in specifying software archi-
tectures. The research question focuses on three types of informal
modeling notations, i.e., (i) simple boxes/lines, (ii) natural languages,
and (iii) software modeling languages. Note that if the participants use
software modeling languages, they are prompted to state the names of
the languages.
RQ-3: Which informal software modeling notations do practitioners use
for specifying the structural and behavioural (also including interaction)
design decisions?
This question focuses on the structural and behavioural design de-
cisions that are highly important for software systems and aims at
learning the informal notations used for specifying these two types of
design decisions. The structural design decisions are concerned with
how systems are decomposed into components and their relationships
(i.e., connectors). The behavioural design decisions are concerned with
how the components change their state according to events occurring in
their environment and connectors’ interaction protocols that impose an
order of message exchanges on the interacting components.
RQ 4: What do motivate/demotivate practitioners for using informal
software modeling approaches?
In this question, the goal is to understand the appealing require-
ments fulfilled by the informal software modeling notations and those
that are either missing or inadequately supported by the informal no-
tations.
RQ 5: Which formal software modeling notations are mainly used by
practitioners?
In this question, the goal is to learn the formal software modeling
notations that practitioners use for specifying their software
18
Information and Software Technology 95 (2018) 15–33
architectures. The research question focuses on two types of formal
notations, i.e., (i) formal specification languages (process algebras and
high-level formal languages) and (ii) ADLs.
RQ 6: What do motivate/demotivate practitioners for using formal
software modeling languages?
Similarly to RQ4, this question focuses on formal notations and aims
at understanding the appealing requirements fulfilled by the formal
software modeling notations and those that are either missing or in-
adequately supported by the formal notations. Indeed, it will further be
possible to compare the formal and informal software modeling ap-
proaches in terms of their capabilities and understand when to use and
not use each type of notations.
RQ 7: Which ADLs are mainly used by practitioners?
In this research question, the goal is to understand the ADLs used by
practitioners. As introduced in Section 1.1.2, the ADLs in this question
are presented in three groups, i.e., general-purpose, domain-specific,
extensible.
RQ 8: What do motivate/demotivate practitioners for using ADLs?
Similarly to RQ4 and RQ6, this question aims at understanding the
appealing requirements fulfilled by the ADLs and those that are either
missing or inadequately supported by the ADLs. Answering this ques-
tion will aid in comparing ADLs with other formal modeling notations
in terms of the practitioners’ needs and expectations.
4. Survey design, execution, and sampling
4.1. Survey design
This survey has been constructed over the knowledge and experi-
ence that had been gained via the design of a previous survey on
software architectures [46]. While that was a relatively short and quick
survey and focuses on the notion of software architectures, it helped
with a lot of issues, such as the preparation of the questions and their
structures and the methodologies for collecting data.
The survey questions have been finalised after a series of reviews
together with the experts in the field. The survey consists of 35 ques-
tions that are categorised into three sections, i.e., (i) profile, (ii) in-
formal architectural modeling notations, and (iii) formal architectural
modeling notations. The list of questions is given in Table 1. So, as
shown in Table 1, most questions have multiple-choice answers and at
the same time offer the “free text” option. Practitioners can use the free
text options (if given) to type any additional answers that are not in-
cluded in the list of multiple-choice for the question. During the ana-
lysis of answers for each question, the free text answers are analysed
and validated manually to check whether the typed answer(s) are re-
levant to the question. Those relevant answers are considered together
with the answers chosen via the multiple-choice list of the question. For
instance, the question ”Which informal modeling language(s) do you
use” has a free text option for stating any languages that are not given
in the multiple-choice list. If any answers that have been freely typed do
really exist in the literature as informal modeling languages they are
added to the list of the voted languages by the participants. Regarding
the Yes/No survey questions indicated in Table 1, they require more
informative answers from the participants. For instance, the question
“Do you use any ADLs” is answered with either one of the following
answers: always (100%), much of the time ( > 70%), often (> =50%),
sometimes ( < 50%), and never (0%).
The first 13 questions in Table 1 are concerned with RQ1 in
Section 3, which aims at understanding the profiles of the participants.
The questions 14–22 are concerned with RQ2, RQ3 and RQ4 in
Section 3, which aim at determining practitioners’ knowledge and ex-
perience in informal software modeling notations. The questions 23–26
are concerned with RQ5 and RQ6 in Section 3, which focus on practi-
tioners’ level of interest shown towards formal software modeling no-
tations. The questions 27–35 are concerned with RQ7 and RQ8 in
Section 3, which focus on ADLs.
M. Ozkaya Information and Software Technology 95 (2018) 15–33

Table 1
Survey questions.

Res. Que. Survey questions Multiple Free Yes/No Integer

answers text (Other) question Answer

RQ 1: 1- Which country do you work in? N Y N N

2- What is your highest academic degree? N Y N N
3- What is your university degree? N Y N N
4- What is your undergraduate degree? N Y N N
5- What are you graduate degrees? Y Y N N
6- What is(are) your current job position(s)? Y Y N N
7- How many years of experience do you have in software development? N N N Y
8- How many years of experience do you have in software architecture modeling? N N N Y
9- What are the types of products that are developed by your company? Y Y N N
10- How many employees do work as a software engineer in your company? N N N Y
11- What are the types of software projects that are developed in your company? Y Y N N
12- What are the typical size of the software project development teams in your company? N N N Y
13- What are the roles that a typical project in your company involves? Y Y N N
RQ 2: 14- Which informal modeling approaches do you prefer for specifying software architectures? N N N N
15- Which informal software modeling language(s) do you use? Y Y N N
RQ 3: 16- What do you use for specifying the structural aspect of software architectures? Y Y N N
17- If you use any other approaches for specifying the structure of systems, please state here. N Y N N
18- Do you specify the behavioural aspect of software architectures? N N Y N
19- What do you use for specifying the behavioural aspect of software architectures? Y Y N N
20- If you use any other approaches for specifying the behaviour of systems, please state here. N Y N N
RQ 4: 21- Why do you prefer informal software modeling approaches for specifying software architectures? Y Y N N
22- What are the features that you cannot benefit using informal approaches but you wish to do so? Y Y N N
RQ 5: 23- Do you use formal software modeling notations for specifying software architectures? N N Y N
24- Which formal specification languages do you use? Y Y N N
RQ 6: 25- Why do you prefer formal specification languages? Y Y N N
26- Did you have any complaints about formal specification languages? Y Y N N
RQ 7: 27- Do you use any ADLs? N N Y N
28- Which of the following types of architecture description languages do you use? Y Y N N
29- If you use early ADLs, which of the following early languages do you use? Y Y N N
30- If you use domain-specific architecture description languages, which of the following languages do you use? Y Y N N
31-If you use extensible ADLs, which of the following languages do you use? Y Y N N
RQ 8: 32- Why do you prefer early ADLs? Y Y N N
33- Why do you prefer domain-specific ADLs? Y Y N N
34- Why do you prefer extensible ADLs? Y Y N N
35- Did you have any complaints about ADLs? Y Y N N

Y: Yes, N: No, Integer: Numeric answers

4.2. Survey execution 4.3. Survey sampling

The survey has been prepared in Google forms3 and was accessible
online. The survey has accepted responses for six months during the
second-half of 2016.
The survey targets the practitioners from diverse industries who are
involved in software development, holding positions such as architect,
developer, programmer, tester, analyst, and managerial positions. The
potential participants have been invited to fill in the survey in many
different ways. Initially, the personal contacts who hold various related
positions around the world have been invited via e-mail. Then, google
search has been made in order to find out the web-sites of as many
companies as possible that are involved in software development and
exhibit an e-mail address in their contact forms. In the e-mail, the
companies have been kindly requested to share the survey with their
employees performing software development jobs. After sending e-
mails to those companies, the social networking platforms have been
addressed. This includes Linkedin, Facebook, Google and Yahoo groups
about software development. Lastly, the well-cited academic papers on
software engineering, especially the ones on software architectures,
have been identified via Google scholar. Each such paper has been
checked and the authors with industry background have been sent an
invitation e-mail for the survey. Note also that to maximise the re-
sponsiveness, in every e-mail sent the recipient(s) have been requested
to forward the e-mail to any relevant potential participants who may
want to contribute to the survey.
3
https://docs.google.com/forms/.
The samples in surveys are created via the sampling method, which is
the process of selecting a group of people from the entire population who
represent the differences observed in the entire population to minimise
biases [47]. Sampling can be in one of the two forms – probability or non-
probability – depending on the way the potential participants are selected.
In probability sampling, the survey designers have access to the entire
population and thus every member of the population has equal chance of
being selected. By doing so, any biases regarding the selection of the
participants are minimised and the findings can be generalised to the
population. Non-probability sampling is applicable in the cases where the
survey designers have no chance of knowing every member of the popu-
lation. So, unlike probability sampling where the potential participants are
chosen randomly, in non-probability sampling, the participants are chosen
in a subjective manner (i.e., non-random). Non-probability sampling is
essentially useful for the cases where the survey designers do not have
enough time and money to target the entire population.
In this survey, initially, the goal was to imitate the probabilistic sam-
pling on the data collected from the participants. To do so, as mentioned in
Section 4.2, many big companies that produce IT products have been
contacted so that their employees involved in software development can
contribute to the survey. From their contributions, it could be possible to
randomly select a sub-set of contributions for the survey evaluation.
However, since the survey did not require the participants to share their
company details, it was not possible to group the participants based on
their companies. Moreover, despite so many companies contacted, many
of them did not respond to the e-mails for confirmation. So, it may also not
be possible to select the same amount of participants for each companies

19
M. Ozkaya
randomly. Therefore, in the survey, non-probability sampling has been
used, in which the participants have been selected without applying any
random selection algorithms. Essentially, the convenience non-probability
sampling has been applied, which promotes survey designers to select the
groups of participants who are willing to participate in the survey [48].
Indeed, as also mentioned in Section 4.2, the participants have been got to
contribute to the survey in the following ways: (i) the personal contacts,
(ii) the IT companies and their employees who accepted to participate, (iii)
the practitioners reached via the social media, and (iv) the practitioners
who contributed to the scientific papers about software architectures and
accepted to participate in. As a result, the survey has received 115 dif-
ferent responses from 28 different countries around the world.
5. Survey findings and results
5.1. Profiles
5.1.1. The countries of the participants (Q1)
In order to minimise any biases, the survey has been shared in many
online social groups regardless of the countries that the groups mainly
serve in. So, the survey managed to attract the participants from 28
different countries. These countries are Turkey, Canada, USA, Germany,
the Netherlands, United Kingdom (UK), Switzerland, France, Austria,
Russia, Finland, Mexico, Iran, Palestine, Belgium, Argentina, India,
Indonesia, Sweden, Brasil, Australia, Somalia, Italy, China, Tunisia,
Poland, Ireland, and Syria.
5.1.2. The highest academic degree (Q2)
In order to understand the education background of the partici-
pants, the survey tries to learn the highest academic degrees of the
participants. Most of the participants (80%) hold university degrees,
where 40% hold MSc or MA level post-graduate degrees, 30% hold BSc
or BS level undergraduate degrees, and 10% hold PhD level doctoral
degrees. The rest 20% of the participants lower-level degrees such as
college (i.e., vocational school) and high-school degrees.
5.1.3. The academic majors of the participants (Q3, Q4, Q5)
The questions Q3, Q4, and Q5 have been answered by the partici-
pants who has graduated from a university. Fig. 1 depicts the percen-
tages of the participants who have studied various majors in uni-
versities. Note that the blue lines represent the participants with
undergraduate degrees and the orange lines represent those with
postgraduate degrees (e.g., MSc, MA, and PhD). So, 70% of the parti-
cipants with undergraduate degrees and 60% of the participants with
post-graduate degrees have studied computer science and other related
subjects (i.e., computer engineering4, software engineering, and
4
The computer engineering and computer science majors are essentially the same and
used in a mutually exclusive manner by the universities.
20
Information and Software Technology 95 (2018) 15–33
Fig. 1. The academic majors of the participants. (For
interpretation of the references to color in this figure
legend, the reader is referred to the web version of
this article.)
information technology). The rest of the participants (27% for under-
graduate, 40% for postgraduate) have studied different fields, including
electrical and electronics engineering, civil engineering, machine en-
gineering, material engineering, management and finance. Note how-
ever that given their profiles (i.e., IT-related job positions, the software
development projects involved, and the years of work experiences)
observed in the survey, those participants seem to improve themselves
on software architecture modeling and be capable of answering the
survey confidently.
5.1.4. The Participants’ job positions (Q6)
Fig. 2 depicts the different job positions held by the participants.
The software developer/programmer position is the top chosen one,
selected by more than 50% of the participants. This is followed by the
software architect position, chosen by 30% of the participants. The
question also reveals several different job positions of the participants
such as analyst, consultant, system engineer, tester, Quality and As-
surance (QA) engineer, and managerial positions. Some participants
have used the other option and specified non-listed positions such as
researcher and Research and Development (R&D) director. Note that
this is a multiple-choice question, allowing the participants to choose
multiple job position that they handle at the same time. As shown in
Fig. 3, while 61% of the participants hold a single position, the rest 39%
of the participants hold 2, 3, or 4+ different job positions at the same
time. Among those holding a single position, 43% of them hold the
software developer/programmer position, 19% of the hold any one of
the managerial positions shown in Fig. 2 (e.g., high-level manager,
design team lead, and project manager), 9% of them hold the software
architect position, and another 9% of them hold the system engineer
position.
5.1.5. Work experience (Q7 and Q8)
Fig. 4 shows the participants’ years of experience on software de-
velopment and software architecture modeling. Note that software
development herein is essentially concerned with the activities such as
requirements gathering&analysis and software im-
plementation&testing. According to the results, most of the participants
(70%) have 6+ years of experience on software development, while
this is reduced to 39% for architecture modeling. Surprisingly, 30% of
the participants have no any experience on software architecture
modeling at all. To minimise any biases, those participants have been
directed to submit the survey form without answering the questions
about the informal/formal modeling notations.
5.1.6. Participants’ work industries (Q9)
Fig. 5 shows the different industries that the participants work in. Note
that the participants are allowed to choose multiple industries if their
companies perform software development for different industries. Ac-
cording to the results, IT and telecommunications is the top choice of the
M. Ozkaya
Fig. 3. The number of the job positions held by the participants.
participants (47%), which is followed by finance and accounting (33%).
The industries, such as automative and transportation, government, con-
sumer electronics, defense/military & aviation, and healthcare and bio-
medical, have been selected by 7–10% of the participants. Note lastly that
the 23% of the participants have stated other industries that are not listed
in the question, including supply chain planning and management, cos-
metics, entertainment, human resources, energy, and media.
21
Information and Software Technology 95 (2018) 15–33
Fig. 2. The participants’ job positions.
5.1.7. The number of software engineers in the companies (Q10)
In this question, the goal is to learn the number of software en-
gineers with whom the participants work together. Assuming that the
participants represent the other software engineers working in their
companies, the survey can therefore be considered to target at a much
greater number of people. As shown in Fig. 6, most of the participants
work with 0–9 software engineers (36%), which is followed by the
companies with 10–50 software engineers (28%). Besides, there are
also participants from the companies with sizes 51–100 (11%),
101–500 (12%), and 1000+ (12%).
5.1.8. Participants’ project types (Q11)
Fig. 7 shows the different types of projects that participants develop.
Note that this question is a multiple-choice question and the partici-
pants are allowed choose to multiple types of projects. So, most of the
participants develop web applications (71%) or business applications
software (60%). The third most popular project type is the mobile ap-
plications (45%). The rest of the listed fields include systems software5
(37%), scientific/engineering applications software (23%), and safety-
critical and mission-critical software (17%).
Table 2 shows the correlation between the types of the projects
developed and the industries that the participants work in. So, one can
easily observe which industries produce which type(s) of software
systems more/less. Indeed, the web applications are developed most by
the companies working for Government and IT & Telecommunication.
Scientific applications, systems software, and safety-critical software
Fig. 4. Participants’ years of experience.
5
Systems software are those that are used by other software systems and users, such as
operating systems, web browsers, etc.
M. Ozkaya
Fig. 6. The number of software engineers working in the companies.
systems are developed most by the Defense/Military & Aviation in-
dustry. Mobile applications are developed most by the Consumer
Electronics and Healthcare industries. Lastly, the business application
software are developed most by the Finance industry.
Fig. 8 gives another correlation, which shows the types of the pro-
jects that are preferred to be developed by the participants who use just
informal modeling notations or use formal modeling notations too. The
types of software systems do not really affect the participants’ choice of
using formal modeling notations. The percentages of the participants
using just informal modeling notations and the participants using
formal modeling notations too are close to each other for each type of
Fig. 7. Participants’ project types.
22
Information and Software Technology 95 (2018) 15–33
Fig. 5. Participants’ work industries.
software systems considered. Indeed, the web applications are the top
preferred software type developed by the participants. The second top
preferred software types differ however, which is business applications
for the participants using just informal notations and mobile applica-
tions for those using formal notations too. The rest of the software types
are preferred by equal percentages of the participants using informal
notations and those using formal too.
5.1.9. Participants’ project team sizes (Q12)
Fig. 9 depicts the typical size of the software development teams
that the participants are involved in. 54% of the participants work in
small teams consisting of 1–5 people. 23% of the participants work in a
team of 5–10 people. A few of them (17%) work in relatively large
teams consisting of 10+ people.
Table 3 shows the correlation between the project types and the
team sizes. As the results show, the teams consisting of 1–5 people are
the most common team size, which is preferred most by the project
types considered. Note however for web applications, the team size
with 5–10 people is popular too.
5.1.10. The roles that a typical project involves (Q13)
A typical software development project may comprise various roles
including designer, analyst, tester, software engineer, and architect,
programmer and developer. Fig. 10 shows the different roles that the
participants’ projects include. So, most of the participants stated that
their projects involve software developer6 (72%) and software architect
(62%) roles. Moreover, the software engineer (56%) and tester (57%)
roles have also been selected by more than half of the participants.
While the analyst (48%), programmer (40%), and software designers
6
Software developers are assumed here to be the people who perform the design and
implementation of software systems.
M. Ozkaya Information and Software Technology 95 (2018) 15–33

Table 2
The correlation between the types of industry and the project types developed.

Automative Consumer Electronics Defense Finance Government Healthcare IT & telec.

Web app. 21% 23% 15% 28% 37% 28% 30%

Business app. software 20% 14% 15% 31% 32% 20% 23%
Mobile app. 18% 22% 15% 20% 19% 13% 18%
Systems software 17% 18% 25% 17% 6% 13% 16%
Scientific app. 10% 14% 15% 2% 0% 13% 7%
Safety- critical software 14% 9% 15% 2% 6% 13% 6%
Total 100% 100% 100% 100% 100% 100% 100%

(35%) roles have been chosen by fewer participants, they are also
considered as essential roles for several projects.

5.2. Informal software modeling

In this part, the questions 15–22 have been answered by the parti-
cipants who stated to use the informal software modeling notations in
question 14. Those who stated to never use informal notations have not
been provided with those questions 14–22, and instead, they have been
forwarded to the formal modeling questions discussed in Section 5.3.

5.2.1. Informal software modeling notations for specifying software

architectures (Q14)
In this question, the goal is to learn whether the participants who
have some experiences in software architecture modeling (see
Section 5.1.5) prefer informal software modeling languages (e.g., UML)
with rigorous syntax or non-rigorous informal notations (e.g., natural
languages and simple boxes/lines).
The results in Fig. 11 show firstly that almost all the participants
(94%) who stated to have experiences on architecture modeling use
informal software modeling notations for specifying their software ar-
chitectures. Concerning the rest 6%, 2% of the participants prefer to
exclusively use the formal software modeling notations, and the other
4% stated that they do not use any types of the informal/formal mod-
eling notations considered in the survey.
Among the two types of informal modeling notations considered,
software modeling languages are the most popular notation type (53%).
While non-rigourous notations are not that popular, natural languages
(e.g., English) are used quite a lot more participants (27%) than those
using simple boxes/lines (14%).
5.2.2. Popular informal software modeling languages (Q15)
According to Fig. 12, the top used informal software modeling
language for specifying software architectures is UML (83%). Note that
a few participants (19%) use UML’s extension mechanism (UML’s pro-
file) to extend UML for different platforms or domains.
While UML is the top used language, it is a general purpose
Fig. 9. Participants’ project team sizes
language and may not be useful for the practitioners who need to model
their domain-specific features (e.g., the timer feature for real-time
systems and asynchronous event-based communications for embedded
systems). Indeed, the results show 36% of the participants prefer do-
main-specific modeling languages for that reason.
The other listed languages, i.e., BPMLs [12], SysML, SoAML [49],
are used quite rarely by the participants (12-17%). Lastly, one of the
participants has chosen the other option to state that they use the
Generic Modeling Environment (GME) tool [50] for creating their own
informal modeling languages.
5.2.3. Modeling complex decisions of software architectures (Q16, Q17,
Q18, Q9, and Q20)
In this set of questions, the structural and behavioural (and inter-
action) design decisions are focussed, which are the two essential as-
pects of software architectures that need to be specified and analysed
before the software systems are built. Concerning the structural design
decisions, the questions (Q16, Q17) offer as choices the simple boxes/
lines and UML’s popular diagrams (i.e., class diagram, object diagram,
and component diagram) that also inspired many other notations in

Fig. 8. The types of the software that the participants

who use informal or formal notations develop.

23
M. Ozkaya Information and Software Technology 95 (2018) 15–33

Table 3
The correlation between the software project team size and the types of the software projects .

Business app. Mobile app. Safety-critical software Scientific app. Systems software Web app.

1–5 people 56% 57% 54% 64% 52% 43%

5–10 people 22% 25% 23% 21% 24% 45%
10+ people 22% 18% 23% 15% 24% 12%

specifying structural decisions. For the behavioural (and interaction)

design decisions, the questions (Q18, Q19) offer (i) natural languages
(e.g., English), (ii) sequence diagram, (iii) activity diagram, and (iv)
state diagram. Note that the latter three diagram types are essentially
the part of UML’s notation set, which may again be inspired by some
other languages too. However, the participants are also allowed to
specify other notations that they may use (Q20).
According to Fig. 13, simple boxes/lines are the most popular
technique for specifying the structure of systems. Indeed, most parti-
cipants always (100% of the time) use boxes/lines or use it much of the
time ( > 75% of the time). Among the UML’s diagrams considered, class
diagram is the top used notation by the participants. Indeed, the
number of the participants voting for often and much of the time is the
greatest for the class diagram. Class diagram is followed by the com-
ponent diagram, which is understood to be frequently used by many
participants. However, the object diagram is the least used diagram for Fig. 11. The informal software modeling approaches used by the participants.
specifying software architectures, which many participants never use.
Lastly, note that 20% of the participants specified some additional (i.e.,
non-listed) notations, including their own domain-specific languages, the participants have chosen all these three advantages at the same
flow diagrams, and UML’s other diagrams (e.g., sequence diagrams, use time. So, they essentially wish for a language that allows for the visual
case diagrams, and state machine diagrams). specifications of any types of systems in a way that does not require a
Fig. 14 shows that UML or any other informal software modeling steep learning curve. Moreover, 46% of the participants are motivated
languages are not the top choice of the participants for specifying be- by the familiarity of the informal modeling notations, which essentially
havioural and interaction design decisions. Instead, the natural lan- facilitates the communication among different stakeholders of the
guages (e.g., English) are the most popular technique among the par- projects.
ticipants, which allows for specifying software architectures textually Surprisingly, the participants do not show the expected level of
without having to obey any syntactical (or semantical) constraints. interest to tool support. Indeed, the analysis tool support are shown the
Indeed, the number of the participants voting for always (100% of the least interest (11%). This is probably because the participants are not
time) and much of the time ( > 75%) is the greatest for natural lan- satisfied with the analysis capabilities of the informal languages, which
guages. Concerning the UML diagrams considered in the question, the lack for instance in the support for exhaustive analysis. Specifying
sequence diagram seems to be the most popular one. The least popular complex design decisions is again not the reason of choice for informal
UML diagram is the state diagram, for which most of the participants notations (20%). Indeed, as discussed in Section 5.2.3, the participants
have indicated their usage frequency as sometimes and never. rarely use the informal modeling languages for specifying the system
structure and behaviours.
Lastly, two of the participants had some other (i.e., non-listed)
5.2.4. Participants’ reasons for using informal software modeling notations reasons, such as the extensibility of the languages and easiness in
in specifying software architectures (Q21) communication.
In this question, the goal is to analyse the possible reasons that af-
fect the participants’ choice of using informal software modeling lan- 5.2.5. Practitioners’ further expectations from informal software modeling
guages. Fig. 15 points out the three following advantages that many of notations (Q22)
the participants have chosen: (i) easy to learn and use (79%), (ii) In this question, the requirements that are either missing in informal
general-purpose scope (66%), and (iii) visuality (62%). Indeed, 31% of software modeling notations or inadequately satisfied but at the same

Fig. 10. The roles that a typical project involves.

24
M. Ozkaya
time desired by the participants are discussed. According to the results
given in Fig. 16, one third of the participants (35%) stated that informal
software modeling notations meet their all expectations. Concerning
the rest of the participants, they focus on four requirements that are
missing in informal modeling notations, i.e., (i) precise notation set
(33%), (ii) modeling and analysing complex design decisions (33%) and
non-functional properties (30%), and (iii) tool support for exhaustive
(i.e., formal) analysis (30%). Note that these issues are essentially
handled by the formal software modeling notations discussed in the
next section. So, those participants seem to look for a language that
combines the benefits of both informal and formal software modeling
approaches. Some of the participants (19%) who essentially use generic
informal modeling notations (e.g., natural languages, simple boxes/
lines, and UML) stated their expectations for constrained notation sets
for particular domains, e.g., embedded systems and mobile systems.
Lastly, a few participants (5%) stated other (i.e., unlisted) expectations
that are about more user-friendly tools for modeling and code genera-
tion.
5.3. Formal software modeling
The questions 24–35 discussed in this part have been answered by
the participants who stated to use the formal software modeling nota-
tions in question 23. The participants who never use formal notations
have not been provided with those questions, and, they have been di-
rected to submit the survey form.
5.3.1. The participants who use formal software modeling notations for
specifying software architectures (Q23)
The results of this question shown in Fig. 17 reveal that among those
participants with experiences on software architecture modeling (see
Section 5.1.5), 55% of them never use formal software modeling no-
tations, who instead prefer informal notations that are discussed in
Section 5.2. Fig. 18 reflect the participants never using formalisms and
shows the percentages of them using each type of informal software
modeling notations considered in this paper.
Concerning the rest, 14% of the participants sometimes ( < 50% of
the time) use formal modeling notations. The remaining 31% of the
participants use formal notations more frequently (16% vote for much
of the time, 12% vote for often, and 3% vote for always).
Fig. 13. The informal modeling tools for specifying structural design decisions.
25
Information and Software Technology 95 (2018) 15–33
Fig. 12. The informal modeling languages used by
the participants.
5.3.2. The formal specification languages used by the participants (Q24)
In this question, the goal is to learn the formal specification lan-
guages used by the participants who perform formal software modeling
(45% as resulted from the previous question). According to the results
given in Fig. 19, JML is the top preferred formal language by the par-
ticipants (39%), which allows for specifying the behaviours of Java
programs using the Design-by-Contract (DbC) approach [51] and ana-
lysing them via the supporting toolsets. Another DbC based formal
specification language is Spec# that is used by 14% of the participants,
which is intended to be used for C# programs. ArchJava [52] is another
formal specification language that combines the software architecture
specification with the software implementation in Java, which is
however rarely used by the participants (7%). Other formal specifica-
tion languages, e.g., ProMeLa [17], LOTOS [18], Alloy [19], UPPAAL’s
input language [20], Spark [53], and Petri Nets [54], are rarely used
too (0-7%). Note also that process algebra based formal languages (i.e.,
CSP and FSP) and Z notation [55] are not used at all by the participants.
32% of the participants stated to use some other (non-listed) formal
languages via the free text option. Upon analysing the free-text answers,
the related languages have also been added to the end of the chart,
which are Logic Model Processing languages (e.g., Prolog [56]), the
formal languages implementing SAT solvers (e.g., NuSMV language
[57]), Event-B language [58], the languages based on Category theory
[59], and State-machine based languages. Also, some practitioners
stated that they use their own domain specific languages which they
have developed using, e.g., Eclipse Xtext, GME, Metaedit, etc.
5.3.3. Participants’ reasons for using formal specification languages in
specifying software architectures (Q25)
In this question, the goal is to analyse the possible reasons that
motivate the participants for using formal software modeling lan-
guages. Fig. 20 indicates the two relevant reasons that have been se-
lected most by the participants, which are (i) modeling complex design
decisions (64%) and (ii) their automated formal analysis (50%).
Moreover, some of the participants stated that they use formal lan-
guages due to their benefits of specifying domain-specific details (32%)
and non-functional properties for their systems (32%), which may then
be formally analysed. Note however that most of the participants are
not interested in using formal specification languages for generating
software code from software architectures (18%). Lastly, a few
M. Ozkaya
Fig. 14. The informal modeling tools for specifying behavioural (and interaction) design decisions.
participants have specified other (non-listed) reasons, such as software
testing and the simulation tools.
5.3.4. Participants’ concerns about formal specification languages (Q26)
As the results given in Fig. 21, 30% of the participants are happy
with the formal specification languages and have no any further ex-
pectations. The top concern of the participants (47%) is the high
learning curve of the formal techniques. This is especially the case with
process algebras as they essentially require some extra skills such as
math knowledge and concurrent programming. The learning curve may
also get steep due to the difficult-to-use formal analysis tools (i.e.,
model checkers), which produce results that are sometimes difficult to
understand and trace. Some participants (37%) are concerned about the
fact that nobody knows the formal specification languages in the
companies. Likewise, some (37%) also emphasise the lack of popularity
in industry. These two issues hinder essentially the effective commu-
nications of the formal architectural models among stakeholders with
different backgrounds. The other issues that are quite less critical are (i)
the lack of support for architectural elements (e.g., components and
connectors) (26%) and (ii) the lack of tutorials/guidance/etc. (20%).
Note also that most participants are not concerned about the formal
specification languages’ visual notation support. Lastly, a few partici-
pants suffer from another (non-listed) issue, i.e., the weak analysis tools
of the formal techniques that are not scalable for large systems and thus
cause the state space explosion problem.
5.4. Formal software modeling - architecture description languages (ADLs)
5.4.1. The participants who use ADLs (Q27)
Fig. 22 shows that 23% of the participants who use formal software
modeling notations never use ADLs (using formal specification lan-
guages instead). Concerning the rest (77%), 37% of the participants
26
Information and Software Technology 95 (2018) 15–33
sometimes ( < 50% of the time) use ADLs, while the remaining parti-
cipants use ADLs more frequently (26% of them vote for much of the
time, 6% vote for often, and 8% vote for always).
5.4.2. The groups of ADLs used by the participants (Q28)
Fig. 23 shows the three groups of ADLs used by the participants. So,
the domain-specific ADLs (e.g., AADL, Koala [60], and Weaves [61])
are the top choice of the participants (50%), while the general-purpose
and extensible ADLs have been each chosen by 25% of the participants.
5.4.3. The early general-purpose ADLs used by the participants (Q29)
In this question, four pioneer early general-purpose ADLs are fo-
cussed, i.e., Darwin [62], Wright [23], Rapide [25], and C2 [63]. Ac-
cording to the results in Fig. 24, Darwin is the top used early ADL by the
participants (46%). Wright and Rapide ADLs are each used by 23% of
the participants. The least used domain-specific ADL is C2 (8%). Lastly,
some participants have specified other (non-listed) ADLs, which are
East-ADL [64] and Autosar [65]. However, while East-ADL and Autosar
are early ADLs, they are essentially specific to embedded systems and
thus should be considered under the categories of domain-specific
ADLs.
5.4.4. Participants’ reasons for using early general-purpose ADLs (Q32)
According to the results given in Fig. 25, the top two reasons of the
participants for using early general-purpose ADLs are (i) general-pur-
pose scope (44%) for the high-level specifications of any types of sys-
tems and (ii) tool support for the exhaustive (i.e., formal) analysis of the
high-level specifications (44%). The third most selected reason (38%) is
being first-generation languages, which have been developed during
the nineties and thus are expected to be more familiar to the practi-
tioners than other more recent languages. 19% of the participants
stated that they use early general-purpose ADLs because of their
Fig. 15. Participants’ reasons for using informal
software modeling notations
M. Ozkaya
Fig. 17. The participants who use formal software modeling notations.
Fig. 18. The informal software modeling notations used by the participants who never
use formal modeling (55%).
support for complex design decisions (e.g., structural, behavioural, and
concurrency). Lastly, the level of maturity for ADLs (i.e., how much the
languages are evolved in terms of their syntax, semantics, and tool
support) is not so interesting to the participants (6%).
5.4.5. The domain-specific ADLs used by the participants (Q30)
This question focus on the three pioneer domain-specific ADLs, i.e.,
AADL, Koala [60] and Weaves [61]. According to the results in Fig. 26,
AADL is preferred by more participants (36%) than Koala (27%) and
Weaves (27%). Some of the participants stated that they use other (non-
listed) domain-specific ADLs, such as East-ADL [64] and Autosar [65],
and their own domain-specific ADLs that they have developed using,
e.g., GME and Metaedit.
27
Information and Software Technology 95 (2018) 15–33
Fig. 16. Practitioners’ further expectations from in-
formal software modeling notations.
5.4.6. Participants’ reasons for using domain-specific ADLs (Q33)
According to the results in Fig. 27, the top reason of the participants
(62%) is the automated formal analysis of software architectures for
domain-specific properties (e.g., schedulability analysis for embedded
systems). 46% of the participants are motivated by the automatic code
generation. Indeed, domain-specific languages typically offer lower-
level notation sets that allow for specifying the domain-specific details
in software architectures. Therefore, the code generated from such
detailed specifications will be more useful relatively to code generated
from high-level software architectures specified using early general-
purpose ADLs.
5.4.7. The extensible ADLs used by the participants (Q31)
In this question, the pioneer extensible ADLs are focussed, i.e.,
Acme and XADL. According to Fig. 28, Acme is the top selected ex-
tensible language, used by 50% of the participants, while XADL is used
by 37% of the participants. Some participants used other (non-listed)
extensible ADLs that they developed using e.g., GME and Metaedit.
5.4.8. Participants’ reasons for using extensible ADLs (Q34)
According to the results in Fig. 29, 55% of the participants use ex-
tensible ADLs for combining the capabilities of different ADLs. These
capabilities include the tool support for, e.g., analysis and code gen-
eration, and other benefits such as complex connector support, non-
functional properties, and support for multiple viewpoints. Moreover,
45% of the practitioners use extensible ADLs for introducing a new
feature for their own problem domain (e.g., a new component/con-
nector type or a new feature for the existing components/connectors)
that are not considered in any of the existing ADLs or removing the
existing features as they look for a really basic language with some
fundamental requirements only.
5.4.9. Participants concerns about ADLs (Q35)
In Section 5.3.4, the participants’ top concerns about formal speci-
fication languages have been determined as the high learning curve, the
lack of knowledge among stakeholders, and the lack of popularity in
industry. Likewise, as shown in Fig. 30, 29% of the participants who use
ADLs have the same concerns. However, the participants using ADLs
are essentially most concerned about the weak tool support (38%). The
weak tool support herein includes the usability issues (e.g., difficult-to-
use formal analysis tools and lack of neat visual/text editors), and
functional issues (e.g., inadequate support for checking any well-de-
finedness rules, model completeness/consistency, and syntax errors).
The second most concerning issue of the participants about ADLs is the
lack of tutorials/guidance/etc. (33%). This is because most of the ADLs
today existing have been developed for research purposes and remained
as immature approaches without any consideration of, e.g., user sup-
port, scalability issues, and usability of the tools. Note lastly that 19% of
M. Ozkaya
the participants who use ADLs have no any complaints.
6. Discussions
6.1. Summary of findings
The survey consists of 35 different questions that are grouped into
three parts, i.e., the participant information, informal software mod-
eling notations, and formal software modeling notations. The key out-
comes of the survey questions that are discussed in Section 5 are
summarised as follows.
Q1: The survey attracted participants from 28 different countries.
Q2: Most of the participants (80%) hold university degrees, where
50% of them hold post-graduate degrees (including PhD).
Q3, Q4, Q5: Most of the participants (70%) have studied computer
science (or computer engineering).
Q6: More than half of the participants (53%) work as a software
developer/programmer and almost one third of the participants
(30%) work as a software architect.
Q7, Q8: Most of the participants (70%) have 5+ years of experience
on software development, while this is reduced to 39% when the
experience on software architectural modeling is considered.
28
Information and Software Technology 95 (2018) 15–33
Fig. 19. The formal specification languages used by
the participants.
Q9: The most popular industries that the participants work in are IT
& Telecommunications (47%) and Finance & Accounting (33%).
Q10: Many participants (63%) work in companies that employ less
than 50 software engineers. Note however that survey also attracted
a few participants (10%) whose companies employ more than 1000
software engineers.
Q11: The most popular project types that the participants are in-
volved in are web applications (71%) and business applications
software (60%).
Q12: Most of the participants (80%) work in small teams with 1–10
people, while a few participants (17%) work in larger teams with
more than 10 people working.
Q13: The most popular roles that the participants play in their
software development teams are the software developer (73%) and
software architect (62%).
Q14: More than half of the participants (53%) use informal software
modeling languages for specifying software architectures, while
27% use natural languages (e.g., English) and 14% of the partici-
pants use simple boxes/lines. Note that 6% of them do not use in-
formal software modeling notations for architecture specifications.
Q15: UML is the most popular software modeling language for ar-
chitecture specifications (83%). Besides the general-purpose UML,
some participants (36%) use domain-specific languages for
Fig. 20. Participants’ reasons for using formal spe-
cification languages.
M. Ozkaya
Fig. 22. The participants who use ADLs.
specifying the detailed decisions about the domain of their interest.
Q16, Q17: Simple boxes/lines are the top preferred technique by the
participants for specifying the structural design decisions (i.e.,
components and connectors). The second top preferred technique is
UML’s class diagram, which is preferred more than UML’s object and
component diagrams.
Q18, Q19, Q20: 77% of the participants not only specify the struc-
tural design decisions but also the behavioural design decisions (i.e.,
component behaviours and connectors’ interaction protocols). The
top preferred technique is the natural languages, in which the par-
ticipants specify their system behaviours textually in English
without using any notations. The second top preferred technique is
UML’s sequence diagram, which is preferred more than UML’s ac-
tivity and state diagrams.
Q21: The participants essentially focus on three reasons that moti-
vate them using the informal approaches: (i)easy to learn and use
(79%), (ii)general purpose (66%), (iii)visual (62%). The other re-
latively less chosen reasons are familiarity among stakeholders
(46%), modeling tool support (25%), and code generation tool
support (18%), extensive notation set (20%).
Q22: 65% of the participants who use informal software modeling
notations are not fully satisfied with the informal notations. They
focus on the following missing or inadequate requirements: (i)pre-
cise (i.e., unambiguous) notation set (33%), (ii)modeling and ana-
lysing complex design decisions (e.g., behaviour and interaction)
29
Information and Software Technology 95 (2018) 15–33
Fig. 21. Participants concerns about formal specifi-
cation languages.
(33%) and non-functional properties (30%), and (iii)exhaustive (i.e.,
formal) analysis (30%).
Q23: 55% of the participants never use formal software modeling
notations for specifying software architectures.
Q24: The top used formal specification language is JML [21] (39%),
which has been developed for specifying the contractual behaviours
of Java programs. Spec# [22] is another contractual formal lan-
guage that is adapted to the C# programs, used by 14% of the
participants. The other formal specification languages like ProMela
[17], LOTOS [18], Alloy [19], UPPAAL [20] are used quite rarely
(4-7%). Process algebras (e.g., CSP and pi-calculus) are not used by
the participants. Many participants have also stated that they de-
velop their own domain-specific formal specification languages
using, e.g., GME and Metaedit.
Q25: The primary reason of the participants for using formal spe-
cification languages is the ability of specifying complex design de-
cisions (64%) and formally analysing them (46%). Besides, the
participants are also interested in formally specifying the non-
functional properties for their systems (32%) and their analysis too
(25%). Note that the participants are not so interested in generating
software code from formal specifications (18%).
Q26: The participants are concerned most with the following issues
about formal specification languages: (i)the high learning curve
(37%), (ii)stakeholders’ lack of knowledge about formal languages
(37%), and (iii)the lack of popularity in industry (37%). Some other
concerning issues are the lack of support for architectural elements
(26%), difficult-to-use analysis tools (26%), and the lack of tutor-
ials/guidance (20%).
Q27: ADLs are the least popular notations among the participants.
Indeed, among those who use formal modeling notations (45% of
the participants), just 77% of them use ADLs.
Q28: Domain specific ADLs (50%) are more preferred than early
general-purpose ADLs (25%) and extensible ADLs (25%).
Q29: Among the four popular early general-purpose ADLs (i.e., C2,
Darwin, Rapide, and Wright), the top used ADL by the participants is
Darwin (46%).
Q32: The top reason of the participants for using early general-
purpose ADLs is the general-purpose scope (44%), which promotes
the high-level specifications of any types of systems. The partici-
pants are also motivated by the opportunity of using a first-gen-
eration language that is expected to be relatively familiar in industry
(38%) and the support for analysis tools (31%).
Fig. 23. The groups of ADLs used by the participants.
M. Ozkaya
Q30: Among the three popular domain-specific ADLs (i.e., AADL,
Koala, and Weaves), the top used domain-specific ADL by the par-
ticipants is AADL.
Q33: The top reason for the use of domain-specific ADLs is the
ability of the automated formal analysis for domain-specific prop-
erties (e.g., real-time features for embedded systems) (62%). This is
followed by generating software implementation code from the
domain-specific software architectures (46%).
Q31: Among the two extensible ADLs considered (i.e., ACME and
XADL), the top used ADL is ACME (50%).
Q34: The top selected reason for the use of extensible ADLs is the
ability of combining the capabilities of different ADLs (55%). This is
followed by the ability of introducing new features (or removing the
undesired features) for their domain of interest (45%).
Q35: Lastly, the top selected concerns about the ADLs are the weak
tool support (33%) and the lack of tutorials/user-guidance (33%).
Following these two, the participants are also concerned about the
same issues as they are for the formal specification languages, i.e.,
high learning curve (29%), the stakeholders’ lack of knowledge
about ADLs (29%), and the lack of popularity in industry (29%).
6.2. Lessons learned
As discussed in Section 4.1, this survey has been conducted fol-
lowing author’s another survey [46]. This enabled the author to gain
experiences about designing and implementing a survey, including (i)
determining the research questions and target population, (ii) devel-
oping the survey questions (e.g., the types of the questions, writing
good questions, and the response format of the questions), and (iii)
piloting the survey. Based on the feedback received for the previous
survey, the author improved this survey’s sample size too. Indeed,
searching the related scientific papers and extracting the names and
emails of the practitioners contributed has been learned. Moreover, the
snowball sampling method has been applied, which requires the po-
tential participants to forward the survey invitations to any other po-
tential participants whom they know.
Fig. 25. The reasons for using early ADLs.
30
Information and Software Technology 95 (2018) 15–33
Fig. 24. The early ADLs used by the participants.
Many lessons have also been learned about the software modeling
notations and their categorisation based on the formal/informal se-
mantics definition. As the survey results indicate, despite the benefits
such as the precise specifications and exhaustive analysis, formally
defined modeling notations are not preferred by practitioners due to
their high learning curve, their lack of popularity industry, and stake-
holders’ lack of knowledge about them. Practitioners are more inclined
to the UML-like informal modeling notations that are visual, familiar
(with low learning curve), and generally applicable. However, most
practitioners do still use the informal ad-hoc modeling techniques (e.g.,
simple boxes/lines and natural languages) for specifying complex de-
sign decisions, such as system structures, behaviours, and interactions.
The profiles of the participants may essentially impact their choice
of using formal/informal modeling notations. For example, the choice
of any participants with PhD degrees may differ from those with BSc
degrees; or, the participants with 10+ years of experiences may be
more willing to use one type of notation against the other. However,
any changes in the profiles of the participants have been observed to
not affect the participants’ choice of using formal or informal modeling
notations. Indeed, the profile data for the participants, such as aca-
demic majors, highest academic degrees, and the years of experiences,
do not vary considerably depending on the use of informal/formal
modeling notations. Therefore, practitioners’ choice herein depends
essentially on their needs and expectations from their software archi-
tecture specifications. Indeed, while formal modeling may be a good
choice for precise and formally analysable specifications, informal
modeling may be better for eased communication among different
stakeholders.
Lastly, the survey provided the author with useful feedback about
some of the survey questions, which can be taken into account for the
future surveys. Particularly, the question 21 (see Section 5.2.4) that
aims at learning the reasons for using informal software modeling no-
tations is too general. That is, it is not so easy to understand which type
of informal modeling notation (i.e., natural languages, simple boxes/
lines, or software modeling languages) that the participant focus in the
question. Therefore, this question can be defined in the future for each
M. Ozkaya Information and Software Technology 95 (2018) 15–33

Fig. 26. The domain-specific ADLs used by the par-

ticipants.

Fig. 27. The reasons for using domain-specific ADLs.

Fig. 28. The extensible ADLs used by the partici-

pants.

Fig. 29. Participants’ reasons for using extensible ADLs.

Fig. 30. Participants concerns about ADLs.

31
M. Ozkaya
type of informal modeling notation addressed in the survey where each
question is specialised with the related set of answers. So, the partici-
pants can answer any of the specialised questions that match with the
type of informal modeling notation they use and it will be possible to
judge the reasons behind using the specific types of informal modeling
notations.
6.3. Threats to validity
6.3.1. Internal validity
The internal validity of a survey is concerned with the causal re-
lationships between the survey findings and any independent variables
(i.e., unknown) that may affect the results unexpectedly. The in-
dependent variables must be minimised to maximise the internal va-
lidity of a survey study. One of the main reasons that causes in-
dependent variables in survey studies is the biased selection of the
participants (i.e., non-random selection).
As discussed in Section 4.3, the participants for the survey have
been selected using the non-probability sampling (i.e., non-random). To
minimise any biases, a comprehensive selection process has been per-
formed systematically for reaching a variety of practitioners who are
involved in the software development related tasks. Indeed, the survey
attracted participants from very different profiles that can be cate-
gorised by the (i) countries, (ii) levels of education, (iii) studied subjects
in universities, (iv) job positions, (v) levels of experiences, (vi) work
industries, (vii) project types involved, (viii) team scales, and (ix) team
roles. Regarding the participant selection, firstly, the personal contacts
have been contacted. Then, the companies around the world that are
involved in software development have been searched via google and
contacted by e-mail. The social media (e.g., Linkedin, fFcebook, Yahoo
groups) has also been used intensely to reach the individuals who work
in software development jobs. Lastly, the practitioners in industry who
contributed to software architecture related research studies have been
identified via the google scholar and contacted too. To maximise the
responsiveness, the companies, personal contacts or social media plat-
forms that have been thought to not participate adequately have been
sent reminder e-mails too. Moreover, the survey has been kept available
online for 6 months during the second-half of 2016.
6.3.2. Construct validity
There is no any threats against the construct validity either, which is
concerned with whether the survey measures what it is intended to do.
The gathered data are analysed statistically. That is, to reach a result for
each question, the number of votes given for each answer is counted,
which is essentially the common practice among all survey studies.
Moreover, since the survey is intended for the practitioners working in
industry, the survey has not also been sent to any recipient who work in
academia. To further minimise any threats, the survey initially informs
the participants about the aim of the survey and its content so that the
participants will understand what they are about to fill. Lastly, the
survey content exactly reflect its goal (i.e., to understand the knowledge
and experience of the practitioners on informal and formal software
architecture modeling notations). Indeed, the survey is composed of
three parts: (i) participant profile, (ii) informal modeling notations and
(iii) formal modeling notations.
6.3.3. External validity
There is again no threats to the external validity and the survey
results can, with no doubt, be generalised to the entire population.
Indeed, the survey received 115 different responses from the randomly
chosen participants who are involved in IT related jobs that that belong
to the participants chosen randomly among diverse countries, in-
dustries, companies, education levels, experiences, etc.
32
Information and Software Technology 95 (2018) 15–33
7. Conclusion and further work
In this survey, it has been observed that informal modeling nota-
tions (94%) are far more popular among practitioners than formal
modeling notations (30%) in specifying software architectures. 53% of
the participants use UML-like informal software modeling languages,
while the rest find the informal ad-hoc approaches (i.e., natural lan-
guages and simple boxes/lines) satisfactory for their software archi-
tecture design tasks. An interesting outcome is that the ad-hoc ap-
proaches are the top-choices of the participants for specifying complex
design decisions such as system structures, behaviours and interaction.
So apparently, considering informal modeling languages’ lack of sup-
port for the precise specifications that can be exhaustively analysed,
practitioners do not want to burden themselves with their constrained
notations. Indeed, many participants (65%) already recognised the
importance of the precise specifications of complex design decisions
and their exhaustive analysis. While requirements such as precision and
exhaustive analysis are dealt with by the formal software modeling
notations, most practitioners (70%) are reluctant against formal mod-
eling. Practitioners who have some experience about formal modeling
notations point out three issues, i.e., the high learning curve (47%),
stakeholders’ lack of knowledge about formal modeling (37%), and the
lack of popularity in industry (37%). Another interesting outcome is the
formal ADLs’ lowest usage frequencies among all types of formal
modeling notations despite the ADLs’ architecture-oriented notations
(i.e., components and connectors). The very few practitioners who use
formal ADLs stated to suffer from the weak tool support and the lack of
guidance/tutorials/etc.
In the future, this survey may be improved to new ones that focus on
more specific issues about software architectures and its modeling no-
tations. One particular survey may focus on the possible architectural
design decisions and aim at understanding software architects’ knowl-
edge and experience about them and the software modeling notations
that are used for specifying each design decisions. Another survey may
be for understanding software architects’ concerns about ADLs in a
much more detailed way, focussing on the issues found out in the
current survey such as weak tool support and high learning curve.
Acknowledgments
This work has been supported by the project of the Scientific and
Technological Research Council of Turkey (TUBITAK), Grant No.
215E159. I also would like to express my deep gratitude to Deniz Akdur
who constantly shared his thoughts and provided invaluable feedback
during the preparation of the survey questions.
References
[1] D. Garlan, M. Shaw, An Introduction to Software Architecture, Technical Report,
(1994). Pittsburgh, PA, USA.
[2] R.N. Taylor, N. Medvidovic, E.M. Dashofy, Software Architecture: Foundations,
Theory, and Practice, John Wiley & Sons, 2010. ISBN-13: 978-0470167748
[3] N. Medvidovic, R.N. Taylor, A classification and comparison framework for soft-
ware architecture description languages, IEEE Trans. Software Eng. 26 (1) (2000)
70–93.
[4] E.M. Clarke, J.M. Wing, Formal methods: state of the art and future directions, ACM
Comput. Surv. 28 (4) (1996) 626–643, http://dx.doi.org/10.1145/242223.242257.
[5] J. Rumbaugh, I. Jacobson, G. Booch, Unified Modeling Language Reference Manual,
The, (2nd ed.), Pearson Higher Education, 2004.
[6] L. Balmelli, An overview of the systems modeling language for products and sys-
tems development, J. Obj. Tech. 6 (6) (2007) 149–177. http://www.sysml.org .
[7] T. Lodderstedt, D.A. Basin, J. Doser, Secureuml: a uml-based modeling language for
model-driven security, in: J. Jézéquel, H. Hußmann, S. Cook (Eds.), UML 2002 - The
Unified Modeling Language, 5th International Conference, Dresden, Germany,
September 30, - October 4, 2002, Proceedings, Lecture Notes in Computer Science,
vol. 2460, Springer, 2002, pp. 426–441, , http://dx.doi.org/10.1007/3-540-45800-
X_33.
[8] B. Bauer, J.P. Müller, J. Odell, Agent uml: a formalism for specifying multiagent
software systems, Int. J. Software Eng. Knowl. Eng. 11 (3) (2001) 207–230.
[9] M. Ozkaya, C. Kloukinas, Are we there yet? analyzing architecture description
languages for formal analysis, usability, and realizability, in: O. Demirörs,
M. Ozkaya
O. Türetken (Eds.), EUROMICRO-SEAA, IEEE, 2013, pp. 177–184.
[10] Z. DeVito, N. Joubert, F. Palacios, S. Oakley, M. Medina, M. Barrientos, E. Elsen,
F. Ham, A. Aiken, K. Duraisamy, E. Darve, J. Alonso, P. Hanrahan, Liszt: A domain
specific language for building portable mesh-based pde solvers, Proceedings of
2011 International Conference for High Performance Computing, Networking,
Storage and Analysis, SC ’11, ACM, New York, NY, USA, 2011, pp. 9:1–9:12, http://
dx.doi.org/10.1145/2063384.2063396.
[11] C.L. Conway, S.A. Edwards, Ndl: a domain-specific language for device drivers,
SIGPLAN Not. 39 (7) (2004) 30–36, http://dx.doi.org/10.1145/998300.997169.
[12] M. Weske, Business Process Management: Concepts, Languages, Architectures,
Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2007.
[13] J.A. Bergstra, Handbook of Process Algebra, Elsevier Science Inc., New York, NY,
USA, 2001.
[14] C.A.R. Hoare, Communicating sequential processes, Commun. ACM 21 (8) (1978)
666–677.
[15] J. Magee, J. Kramer, Concurrency - state models and java programs (2. ed.), Wiley,
2006.
[16] R. Milner, J. Parrow, D. Walker, A calculus of mobile processes, i, Inf. Comput. 100
(1) (1992) 1–40.
[17] G.J. Holzmann, The Spin Model Checker, vol. 23, (1997), pp. 279–295.
[18] Formal Description Technique Lotos: Results of the Esprit Sedos Project, in:
P.V. Eijk, M. Diaz (Eds.), Elsevier Science Inc., New York, NY, USA, 1989.
[19] D. Jackson, Alloy: a lightweight object modelling notation, ACM Trans. Softw. Eng.
Methodol. 11 (2) (2002) 256–290.
[20] K.G. Larsen, P. Pettersson, W. Yi, UPPAAL in a nutshell, STTT 1 (1–2) (1997)
134–152.
[21] P. Chalin, J.R. Kiniry, G.T. Leavens, E. Poll, Beyond assertions: advanced specifi-
cation and verification with JML and ESC/Java2, in: F.S. de Boer, M.M. Bonsangue,
S. Graf, W.P. de Roever (Eds.), FMCO, Lecture Notes in Computer Science, vol.
4111, Springer, 2005, pp. 342–363.
[22] M. Barnett, K.R.M. Leino, W. Schulte, The spec# programming system: an overview,
Proceedings of the 2004 international conference on Construction and Analysis of
Safe, Secure, and Interoperable Smart Devices, CASSIS’04, Springer-Verlag, Berlin,
Heidelberg, 2005, pp. 49–69, http://dx.doi.org/10.1007/978-3-540-30569-9_3.
[23] R. Allen, D. Garlan, A formal basis for architectural connection, ACM Trans. Softw.
Eng. Methodol. 6 (3) (1997) 213–249.
[24] J. Magee, N. Dulay, S. Eisenbach, J. Kramer, Specifying distributed software ar-
chitectures, in: W. Schäfer, P. Botella (Eds.), ESEC, Lecture Notes in Computer
Science, vol. 989, Springer, 1995, pp. 137–153.
[25] D.C. Luckham, J. Kenney, L. Augustin, J. Verra, D. Bryan, W. Mann, Specification
and analysis of system architecture using rapide, IEEE Trans. Softw. Eng. 21 (4)
(1995) 336–355.
[26] P.H. Feiler, B.A. Lewis, S. Vestal, The SAE architecture analysis & design language
(AADL): A standard for engineering performance critical systems, in: IEEE Intl
Symp. on Intell. Control, 2006 //aadl.info, pp. 1206–1211. doi:10.1109/CACSD.
2006.285483.
[27] D. Garlan, R.T. Monroe, D. Wile, Acme: An architecture description interchange
language, Proceedings of CASCON’97, (1997), pp. 169–183. Toronto, Ontario
[28] E.M. Dashofy, A. van der Hoek, R.N. Taylor, An infrastructure for the rapid de-
velopment of xml-based architecture description languages, Proceedings of the 22rd
International Conference on Software Engineering (ICSE), Orlando, Florida, ACM,
2002, pp. 266–276.
[29] I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, A. Tang, What industry needs from
architectural languages: a survey, IEEE Trans. Softw. Eng. 99 (2012), http://dx.doi.
org/10.1109/TSE.2012.74.
[30] J. Jürjens, Secure Systems Development with UML, Springer, 2005, http://dx.doi.
org/10.1007/b137706.
[31] A. Tang, M.A. Babar, I. Gorton, J. Han, A survey of architecture design rationale, J.
Syst. Softw. 79 (12) (2006) 1792–1804, http://dx.doi.org/10.1016/j.jss.2006.04.
029.
[32] M.A. Babar, I. Gorton, Software architecture review: the state of practice, Computer
42 (7) (2009) 26–32, http://dx.doi.org/10.1109/MC.2009.233.
[33] D. Soni, R.L. Nord, C. Hofmeister, Software architecture in industrial applications,
Proceedings of the 17th International Conference on Software Engineering, ICSE
’95, ACM, New York, NY, USA, 1995, pp. 196–207, http://dx.doi.org/10.1145/
225014.225033.
[34] H.B. Christensen, K.M. Hansen, K.R. Schougaard, An empirical study of software
architects’ concerns, in: S. Sulaiman, N.M.M. Noor (Eds.), 16th Asia-Pacific
Software Engineering Conference, APSEC 2009, 1–3 December 2009, Batu
Ferringhi, Penang, Malaysia, IEEE Computer Society, 2009, pp. 111–118, , http://
dx.doi.org/10.1109/APSEC.2009.12.
[35] A. Caracciolo, M.F. Lungu, O. Nierstrasz, How do software architects specify and
validate quality requirements? in: P. Avgeriou, U. Zdun (Eds.), Software
Architecture - 8th European Conference, ECSA 2014, Vienna, Austria, August
25–29, 2014. Proceedings, Lecture Notes in Computer Science, vol. 8627, Springer,
2014, pp. 374–389, , http://dx.doi.org/10.1007/978-3-319-09970-5_32.
[36] K. Smolander, M. Rossi, S. Purao, Software architectures: blueprint, literature,
language or decision? EJIS 17 (6) (2008) 575–588, http://dx.doi.org/10.1057/ejis.
2008.48.
[37] P.C. Clements, A survey of architecture description languages, Proceedings of the
8th International Workshop on Software Specification and Design, IWSSD ’96, IEEE
Computer Society, Washington, DC, USA, 1996, p. 16.
[38] N. Medvidovic, E.M. Dashofy, R.N. Taylor, Moving architectural description from
under the technology lamppost, Inf. Softw. Technol. 49 (1) (2007) 12–31, http://
dx.doi.org/10.1016/j.infsof.2006.08.006.
33
Information and Software Technology 95 (2018) 15–33
[39] R. Hilliard, T. Rice, Expressiveness in architecture description languages,
Proceedings of the Third International Workshop on Software Architecture, ISAW
’98, ACM, New York, NY, USA, 1998, pp. 65–68, http://dx.doi.org/10.1145/
288408.288425.
[40] P. Zhang, H. Muccini, B. Li, A classification and comparison of model checking
software architecture techniques, J. Syst. Softw. 83 (5) (2010) 723–744, http://dx.
doi.org/10.1016/j.jss.2009.11.709.
[41] J.S. Bradbury, J.R. Cordy, J. Dingel, M. Wermelinger, A survey of self-management
in dynamic software architecture specifications, Proceedings of the 1st ACM
SIGSOFT Workshop on Self-managed Systems, WOSS ’04, ACM, New York, NY,
USA, 2004, pp. 28–33, http://dx.doi.org/10.1145/1075405.1075411.
[42] R.K. Pandey, Architectural description languages (adls) vs uml: a review, SIGSOFT
Softw. Eng. Notes 35 (3) (2010) 1–5, http://dx.doi.org/10.1145/1764810.
1764828.
[43] N. Ali, C. Solís, I. Ramos, Comparing architecture description languages for mobile
software systems, Proceedings of the 1st International Workshop on Software
Architectures and Mobility, SAM ’08, ACM, New York, NY, USA, 2008, pp. 33–38,
http://dx.doi.org/10.1145/1370888.1370897.
[44] S. Balsamo, A.D. Marco, P. Inverardi, M. Simeoni, Model-based performance pre-
diction in software development: a survey, IEEE Trans. Softw. Eng. 30 (5) (2004)
295–310, http://dx.doi.org/10.1109/TSE.2004.9.
[45] S. Bernardi, J. Merseguer, D.C. Petriu, Dependability modeling and analysis of
software systems specified with uml, ACM Comput. Surv. 45 (1) (2012) 2:1–2:48,
http://dx.doi.org/10.1145/2379776.2379778.
[46] M. Ozkaya, What is software architecture to practitioners: a survey, in:
S. Hammoudi, L.F. Pires, B. Selic, P. Desfray (Eds.), MODELSWARD 2016 -
Proceedings of the 4rd International Conference on Model-Driven Engineering and
Software Development, Rome, Italy, 19–21 February, 2016. SciTePress, 2016, pp.
677–686, , http://dx.doi.org/10.5220/0005826006770686.
[47] T. Punter, M. Ciolkowski, B.G. Freimut, I. John, Conducting on-line surveys in
software engineering, 2003 International Symposium on Empirical Software
Engineering (ISESE 2003), 30 September - 1 October 2003. Rome, Italy, IEEE
Computer Society, 2003, pp. 80–88, http://dx.doi.org/10.1109/ISESE.2003.
1237967.
[48] B. Kitchenham, S.L. Pfleeger, Principles of survey research: part 5: populations and
samples, SIGSOFT Softw. Eng. Notes 27 (5) (2002) 17–20, http://dx.doi.org/10.
1145/571681.571686.
[49] B. Elvesæter, A. Berre, A. Sadovykh, Specifying services using the service oriented
architecture modeling language (soaml) - a baseline for specification of cloud-based
services, in: F. Leymann, I.I. Ivanov, M. van Sinderen, B. Shishkov (Eds.), CLOSER
2011 - Proceedings of the 1st International Conference on Cloud Computing and
Services Science, Noordwijkerhout, Netherlands, 7–9 May, 2011, SciTePress, 2011,
pp. 276–285.
[50] M. Maróti, T. Kecskés, R. Kereskényi, B. Broll, P. Völgyesi, L. Jurácz,
T. Levendovszky, Á. Lédeczi, Next generation (meta)modeling: web- and cloud-
based collaborative tool infrastructure, in: D. Balasubramanian, C. Jacquet,
P.V. Gorp, S. Kokaly, T. Mészáros (Eds.), Proceedings of the 8th Workshop on Multi-
Paradigm Modeling co-located with the 17th International Conference on Model
Driven Engineering Languages and Systems, MPM@MODELS 2014, Valencia,
Spain, September 30, 2014. CEUR Workshop Proceedings, vol. 1237, CEUR-WS.org,
2014, pp. 41–60.
[51] B. Meyer, Applying “design by contract”, IEEE Comput. 25 (10) (1992) 40–51.
[52] J. Aldrich, C. Chambers, D. Notkin, Archjava: connecting software architecture to
implementation, in: W. Tracz, M. Young, J. Magee (Eds.), ICSE, ACM, 2002, pp.
187–197.
[53] J.G.P. Barnes, High Integrity Software - The SPARK Approach to Safety and
Security, Addison-Wesley, 2003.
[54] T. Murata, Petri nets: properties, analysis and applications, Proc. IEEE 77 (4) (1989)
541–580, http://dx.doi.org/10.1109/5.24143.
[55] J.M. Spivey, Z notation - a reference manual, (Second ed.), Prentice Hall
International Series in Computer Science, Prentice Hall, 1992.
[56] L. Sterling, E.Y. Shapiro, The Art of Prolog - Advanced Programming Techniques,
Second ed., MIT Press, 1994.
[57] A. Cimatti, E. Clarke, F. Giunchiglia, M. Roveri, Nusmv: a new symbolic model
checker, Int. J. Softw. Tools Technol. Trans. 2 (4) (2000) 410–425, http://dx.doi.
org/10.1007/s100090050046.
[58] J.-R. Abrial, Modeling in Event-B: System and Software Engineering, First ed.,
Cambridge University Press, New York, NY, USA, 2010.
[59] M. Barr, C. Wells, Category theory for computing science, (Second ed.), Prentice
Hall international Series in Computer Science, Prentice Hall, 1995.
[60] R.C. van Ommering, F. van der Linden, J. Kramer, J. Magee, The koala component
model for consumer electronics software, IEEE Comput. 33 (3) (2000) 78–85.
[61] M. Gorlick, A. Quilici, Visual programming-in-the-large versus visual programming-
in-the-small, Proceedings of 1994 IEEE Symposium on Visual Languages, (1994),
pp. 137–144, http://dx.doi.org/10.1109/VL.1994.363631.
[62] J. Magee, J. Kramer, Dynamic structure in software architectures, SIGSOFT FSE,
(1996), pp. 3–14.
[63] N. Medvidovic, P. Oreizy, J.E. Robbins, R.N. Taylor, Using object-oriented typing to
support architectural design in the c2 style, SIGSOFT FSE, (1996), pp. 24–32.
[64] P. Cuenot, P. Frey, R. Johansson, H. Lönn, M.-O. Reiser, D. Servat, R. Tavakoli
Kolagari, D. Chen, Developing automotive products using the east-adl2 : an autosar
compliant architecture description language, Automob. Eng. 793 (2008).
[65] D. Kum, G.M. Park, S. Lee, W. Jung, Autosar migration from existing automotive
software, 2008 International Conference on Control, Automation and Systems,
(2008), pp. 558–562, http://dx.doi.org/10.1109/ICCAS.2008.4694565.