Do the informal & formal software modeling notations satisfy practitioners for software architecture modeling?

Information and Software Technology xxx (xxxx) xxx–xxx

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 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: A survey Software architectures Informal/formal semantics ADLs UML Formal specification languages

Context: Software architectures can be modeled using semantically informal (i.e., ambiguous) or formal (i.e., mathematically precise) software modeling notations. Objective: In this paper, 115 different practitioners from 28 different countries who work in companies that perform software development have been surveyed. The goal is to understand practitioners’ knowledge and experience about informal and formal modeling notations in specifying software architectures. 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 informal 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 stakeholders, 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 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 components 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 documented as an architectural model, which can be communicated among

different stakeholders, analysed for design errors, and improved to better meet the software requirements [2]. Architecture modeling is performed via the modeling notations that allow for textually or visually representing the architectural models at various levels of abstractions. 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 notations can be distinguished in various aspects, such as the textual/visual specifications of software architectures, semantical basis, general-purpose/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: [email protected]. 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 0950-5849/ © 2017 Elsevier B.V. All rights reserved.

Please cite this article as: Ozkaya, M., Information and Software Technology (2017), http://dx.doi.org/10.1016/j.infsof.2017.10.008

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

examined here in three groups, i.e., early general purpose ADLs, domain-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 nonfunctional 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.

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 semantics 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 notations may not always enable specifying the details of software architecture 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 languages and simple boxes/lines may not be executed via analysis tools for, e.g., syntax/semantics checking, behaviour analysis or code generation. Unlike natural languages and simple boxes/lines techniques, informal 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 notation for meeting new requirements or adapt UML for particular domains. Besides UML and its derivatives, there are architecture description languages (ADLs) that offer architecture-oriented notation sets consisting of architectural elements such as components, ports, connectors, 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., textual/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 Process Modeling Languages (BPMLs) [12], etc.

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) practitioners’ 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 architecture 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 statistically in three parts, i.e., the participants profile, informal architecture modeling notations, and formal modeling notations respectively. Lastly, the discussion and conclusion are given.

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 specification 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 languages 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-purpose 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

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 specifications of UML architectures and their formal analysis. UMLsec [30] is one of the most prominent UML extension that formalises UML for the

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.

2 See the analysis of the architecture modeling notations in https://sites.google.com/ site/ozkayamert1/als.

2

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

Caracciolo et al. interviewed 14 architects from 6 different companies. They focus on 7 different key quality requirements, which are performance, 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 managers, and tried to understand what software architecture is to these people in terms of four different views, i.e., blueprint (logical components and their relationships), language (i.e., notation), decision (e.g., behavioural, interaction and concurrency decisions), and literature (i.e., documenting software architectures).

formal specification and analysis of security properties. Among the formal modeling notations, AADL is one of the top-used one by practitioners [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, schedulability, 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.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., UMLbased 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 framework that categorise ADLs based on a number of requirements that the authors focussed in defining ADLs. Clements and Medvidovic surveyed a small group of 8–9 ADLs that they have determined for assessing 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 patterns, and the specifications of client requirements and architects’ design 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. analysed 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 interest 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., usability, formal analysis, and realisability. In [29], Malavolta et al. conducted a comprehensive survey of 52 questions among 48 practitioners from 40 companies in 15 countries. Their goal was to understand practitioners’ expectations from architecture modeling notations in general, focussing on the advantages and disadvantages of architecture modeling notations from practitioners’ perspective. In [43], Ali et al. surveyed among 8 different ADLs that support the software architecture specifications of distributed and mobile systems. Ali et al.’

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 software 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 interviews. 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 industry 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 demotivate 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 designing 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. Christensen et al. have chosen 4 well-known Danish companies and interviewed and observed the architects in the companies 31 times during 5 months. Christensen et al. determined and analysed 124 different situations of architects (i.e., the different types of works that they perform). In [35], Caracciolo et al. conducted a survey to determine the quality requirements of interest for architects and the approaches preferred in specifying and formally analysing those requirements. 3

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

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 inadequately supported by the formal notations. Indeed, it will further be possible to compare the formal and informal software modeling approaches 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 question will aid in comparing ADLs with other formal modeling notations in terms of the practitioners’ needs and expectations.

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-studies, and the presentation of the analysis results). 3. Research questions

4. Survey design, execution, and sampling

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 development. RQ 2: Which informal software modeling notations are mainly used by practitioners? This question is intended for learning the informal software modeling notations used by practitioners in specifying software architectures. 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 decisions 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 requirements fulfilled by the informal software modeling notations and those that are either missing or inadequately supported by the informal notations. 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

4.1. Survey design This survey has been constructed over the knowledge and experience 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 questions that are categorised into three sections, i.e., (i) profile, (ii) informal 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 included in the list of multiple-choice for the question. During the analysis of answers for each question, the free text answers are analysed and validated manually to check whether the typed answer(s) are relevant 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 experience in informal software modeling notations. The questions 23–26 are concerned with RQ5 and RQ6 in Section 3, which focus on practitioners’ level of interest shown towards formal software modeling notations. The questions 27–35 are concerned with RQ7 and RQ8 in Section 3, which focus on ADLs. 4

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

Table 1 Survey questions. Res. Que.

Survey questions

Multiple answers

Free text (Other)

Yes/No question

Integer Answer

RQ 1:

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

N N N N Y Y N N Y N Y N Y N Y Y N N Y N Y Y N Y Y Y N Y Y Y Y Y Y Y Y

Y Y Y Y Y Y N N Y N Y N Y N Y Y Y N Y Y Y Y N Y Y Y N Y Y Y Y Y Y Y Y

N N N N N N N N N N N N N N N N N Y N N N N Y N N N Y N N N N N N N N

N N N N N N Y Y N Y N Y N N N N N N N N N N N N N N N N N N N N N N N

RQ 2: RQ 3:

RQ 4: RQ 5: RQ 6: RQ 7:

RQ 8:

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 emails 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 responsiveness, 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.

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 nonprobability – 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 population. 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 sampling 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

3

https://docs.google.com/forms/.

5

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

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 undergraduate, 40% for postgraduate) have studied different fields, including electrical and electronics engineering, civil engineering, machine engineering, material engineering, management and finance. Note however 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.

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 different responses from 28 different countries around the world.

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 Assurance (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. 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 participants, 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.5. Work experience (Q7 and Q8) Fig. 4 shows the participants’ years of experience on software development and software architecture modeling. Note that software development herein is essentially concerned with the activities such as requirements gathering&analysis and software implementation&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.3. The academic majors of the participants (Q3, Q4, Q5) The questions Q3, Q4, and Q5 have been answered by the participants who has graduated from a university. Fig. 1 depicts the percentages of the participants who have studied various majors in universities. 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 participants 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

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. According to the results, IT and telecommunications is the top choice of the

4 The computer engineering and computer science majors are essentially the same and used in a mutually exclusive manner by the universities.

6

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

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 engineers 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 participants 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 applications (45%). The rest of the listed fields include systems software5 (37%), scientific/engineering applications software (23%), and safetycritical 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. 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, consumer electronics, defense/military & aviation, and healthcare and biomedical, 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, cosmetics, entertainment, human resources, energy, and media.

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.

7

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

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

Fig. 6. The number of software engineers working in the companies.

systems are developed most by the Defense/Military & Aviation industry. 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 projects 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

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

Fig. 7. Participants’ project types.

6 Software developers are assumed here to be the people who perform the design and implementation of software systems.

8

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

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

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

Automative

Consumer Electronics

Defense

Finance

Government

Healthcare

IT & telec.

21% 20% 18% 17% 10% 14% 100%

23% 14% 22% 18% 14% 9% 100%

15% 15% 15% 25% 15% 15% 100%

28% 31% 20% 17% 2% 2% 100%

37% 32% 19% 6% 0% 6% 100%

28% 20% 13% 13% 13% 13% 100%

30% 23% 18% 16% 7% 6% 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 participants 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 architectures. 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 modeling 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%).

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 domain-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 interaction) design decisions are focussed, which are the two essential aspects 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

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 profile) to extend UML for different platforms or domains. While UML is the top used language, it is a general purpose

Fig. 8. The types of the software that the participants who use informal or formal notations develop.

9

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

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

1–5 people 5–10 people 10+ people

Business app.

Mobile app.

Safety-critical software

Scientific app.

Systems software

Web app.

56% 22% 22%

57% 25% 18%

54% 23% 23%

64% 21% 15%

52% 24% 24%

43% 45% 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 participants 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 component diagram, which is understood to be frequently used by many participants. However, the object diagram is the least used diagram for 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, flow diagrams, and UML’s other diagrams (e.g., sequence diagrams, use case diagrams, and state machine diagrams). Fig. 14 shows that UML or any other informal software modeling languages are not the top choice of the participants for specifying behavioural and interaction design decisions. Instead, the natural languages (e.g., English) are the most popular technique among the participants, which allows for specifying software architectures textually without having to obey any syntactical (or semantical) constraints. Indeed, the number of the participants voting for always (100% of the time) and much of the time ( > 75%) is the greatest for natural languages. Concerning the UML diagrams considered in the question, the sequence diagram seems to be the most popular one. The least popular UML diagram is the state diagram, for which most of the participants have indicated their usage frequency as sometimes and never.

Fig. 11. The informal software modeling approaches used by the participants.

the participants have chosen all these three advantages at the same time. So, they essentially wish for a language that allows for the visual specifications of any types of systems in a way that does not require a steep learning curve. Moreover, 46% of the participants are motivated by the familiarity of the informal modeling notations, which essentially facilitates the communication among different stakeholders of the projects. Surprisingly, the participants do not show the expected level of interest to tool support. Indeed, the analysis tool support are shown the least interest (11%). This is probably because the participants are not satisfied with the analysis capabilities of the informal languages, which lack for instance in the support for exhaustive analysis. Specifying complex design decisions is again not the reason of choice for informal notations (20%). Indeed, as discussed in Section 5.2.3, the participants 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) reasons, such as the extensibility of the languages and easiness in communication.

5.2.4. Participants’ reasons for using informal software modeling notations in specifying software architectures (Q21) In this question, the goal is to analyse the possible reasons that affect the participants’ choice of using informal software modeling languages. Fig. 15 points out the three following advantages that many of the participants have chosen: (i) easy to learn and use (79%), (ii) general-purpose scope (66%), and (iii) visuality (62%). Indeed, 31% of

5.2.5. Practitioners’ further expectations from informal software modeling notations (Q22) In this question, the requirements that are either missing in informal software modeling notations or inadequately satisfied but at the same Fig. 10. The roles that a typical project involves.

10

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

Fig. 12. The informal modeling languages used by the participants.

The questions 24–35 discussed in this part have been answered by the participants who stated to use the formal software modeling notations in question 23. The participants who never use formal notations have not been provided with those questions, and, they have been directed to submit the survey form.

5.3.2. The formal specification languages used by the participants (Q24) In this question, the goal is to learn the formal specification languages 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 participants (39%), which allows for specifying the behaviours of Java programs using the Design-by-Contract (DbC) approach [51] and analysing 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 specification 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.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 notations, 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).

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 languages. Fig. 20 indicates the two relevant reasons that have been selected 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 languages 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

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 generation. 5.3. Formal software modeling

Fig. 13. The informal modeling tools for specifying structural design decisions.

11

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

Fig. 14. The informal modeling tools for specifying behavioural (and interaction) design decisions.

sometimes ( < 50% of the time) use ADLs, while the remaining participants use ADLs more frequently (26% of them vote for much of the time, 6% vote for often, and 8% vote for always).

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 expectations. 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 communications 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 participants 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.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 focussed, i.e., Darwin [62], Wright [23], Rapide [25], and C2 [63]. According 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-purpose scope (44%) for the high-level specifications of any types of systems 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 practitioners than other more recent languages. 19% of the participants stated that they use early general-purpose ADLs because of their

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 languages instead). Concerning the rest (77%), 37% of the participants

Fig. 15. Participants’ reasons for using informal software modeling notations

12

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

Fig. 16. Practitioners’ further expectations from informal 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 lowerlevel 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 generalpurpose 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 extensible 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.

Fig. 17. The participants who use formal software modeling notations.

5.4.8. Participants’ reasons for using extensible ADLs (Q34) According to the results in Fig. 29, 55% of the participants use extensible ADLs for combining the capabilities of different ADLs. These capabilities include the tool support for, e.g., analysis and code generation, and other benefits such as complex connector support, nonfunctional 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/connector 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. Fig. 18. The informal software modeling notations used by the participants who never use formal modeling (55%).

5.4.9. Participants concerns about ADLs (Q35) In Section 5.3.4, the participants’ top concerns about formal specification 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-touse formal analysis tools and lack of neat visual/text editors), and functional issues (e.g., inadequate support for checking any well-definedness 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 support, scalability issues, and usability of the tools. Note lastly that 19% of

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 (nonlisted) 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. 13

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

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 involved 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 participants use simple boxes/lines. Note that 6% of them do not use informal software modeling notations for architecture specifications. Q15: UML is the most popular software modeling language for architecture specifications (83%). Besides the general-purpose UML, some participants (36%) use domain-specific languages for

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 modeling notations, and formal software modeling notations. The key outcomes 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.

Fig. 20. Participants’ reasons for using formal specification languages.

14

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

Fig. 21. Participants concerns about formal specification 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 language 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 develop their own domain-specific formal specification languages using, e.g., GME and Metaedit. Q25: The primary reason of the participants for using formal specification languages is the ability of specifying complex design decisions (64%) and formally analysing them (46%). Besides, the participants are also interested in formally specifying the nonfunctional 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 tutorials/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 generalpurpose ADLs is the general-purpose scope (44%), which promotes the high-level specifications of any types of systems. The participants are also motivated by the opportunity of using a first-generation language that is expected to be relatively familiar in industry (38%) and the support for analysis tools (31%).

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 structural 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 participants 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 activity and state diagrams. Q21: The participants essentially focus on three reasons that motivate them using the informal approaches: (i)easy to learn and use (79%), (ii)general purpose (66%), (iii)visual (62%). The other relatively 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)precise (i.e., unambiguous) notation set (33%), (ii)modeling and analysing complex design decisions (e.g., behaviour and interaction)

Fig. 23. The groups of ADLs used by the participants.

15

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

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 semantics 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 stakeholders’ 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 design 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 academic 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 architecture 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 notations 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

Q30: Among the three popular domain-specific ADLs (i.e., AADL, Koala, and Weaves), the top used domain-specific ADL by the participants is AADL. Q33: The top reason for the use of domain-specific ADLs is the ability of the automated formal analysis for domain-specific properties (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 following 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) developing 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 potential participants to forward the survey invitations to any other potential participants whom they know.

Fig. 25. The reasons for using early ADLs.

16

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

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

Fig. 27. The reasons for using domain-specific ADLs. Fig. 28. The extensible ADLs used by the participants.

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

Fig. 30. Participants concerns about ADLs.

17

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

7. Conclusion and further work

type of informal modeling notation addressed in the survey where each question is specialised with the related set of answers. So, the participants 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.

In this survey, it has been observed that informal modeling notations (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 languages and simple boxes/lines) satisfactory for their software architecture design tasks. An interesting outcome is that the ad-hoc approaches 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 support 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 modeling. 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 notations. One particular survey may focus on the possible architectural design decisions and aim at understanding software architects’ knowledge 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.

6.3. Threats to validity 6.3.1. Internal validity The internal validity of a survey is concerned with the causal relationships between the survey findings and any independent variables (i.e., unknown) that may affect the results unexpectedly. The independent variables must be minimised to maximise the internal validity of a survey study. One of the main reasons that causes independent 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 performed 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 categorised 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 platforms 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.

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.

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.

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 software 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 systems 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-45800X_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,

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, industries, companies, education levels, experiences, etc. 18

Information and Software Technology xxx (xxxx) xxx–xxx

M. Ozkaya

[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 prediction 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 cloudbased collaborative tool infrastructure, in: D. Balasubramanian, C. Jacquet, P.V. Gorp, S. Kokaly, T. Mészáros (Eds.), Proceedings of the 8th Workshop on MultiParadigm 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 programmingin-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.

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 specification 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 architectures, 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 development 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.

19