Keywords

1 Introduction

Software architecture is considered an important area of Software Engineering, as it is useful for managing the development and maintenance of large scale software-intensive systems [1]. The emphasis of mapping the components and their connectors of a software system is generally recognized, and has led to better control over the design, development, and maintenance of these systems [2].

The software architecture community has developed numerous technologies to support the architecture process (analysis, design, and review) [1]. Besides, in order to facilitate and assist the software architecture documentation, a number of contributions have been made in the last decades in terms of architecture standards, as for, Kruchten 4+1 View Model [4], Siemens’ 4 View Model [4] and Zachman Framework [5]. In addition, a standard was also proposed. Its first version, the ANSI/IEEE 1471-2000, was published as a standard in 2000. Then, it was revised in 2007, and finally published in its current format, the ISO/IEC/IEEE 42010:2011 standard, in 2011.

By reading the ISO/IEC/IEEE 42010:2011 standard, it is clear that it describes many architectural elements in its chapters, including, to mention a few, architecture description, frameworks, viewpoints, relations, rationale, and also the relationship from this specific architectural standard to others, as for instance, the ISO/IEC 12207:2008 [6], which establishes a common framework for software life cycle processes, and ISO/IEC 15288:2008 [7], which establishes a common framework for describing the life cycle of systems created by humans. Therefore, from all these elements, there is no commonly known hierarchy, or at least a notion of minimal architecture, or even which parts most be considered by software architects. In summary, users do not know which elements are the most important ones, and as a result there are elements that are barely mentioned in the literature.

The main objective of this paper is to present a Systematic Mapping Study (SMS) for describing studies that explicitly used the ISO/IEC/IEEE 42010:2011 standard, and identifying which parts of this standard were most considered in the literature.

2 Brief Introduction to ISO/IEC/IEEE 42010:2011 - Systems and Software Engineering - Architecture Description

In this section, we present a brief overview of the standard ISO/IEC/IEEE 42010:2011 [8], which is the focus of our SMS. The ISO/IEC/IEEE 42010:2011 is a new version with improvements of former ANSI/IEEE 1471-2000 and it specifies the best practices for documenting enterprise, system and software architectures.

By considering the terms in Fig. 1, one can notice that systems have architectures that are expressed by architecture descriptions. In addition, Systems have multiple stakeholders who have different concerns. These concerns drive multiple architecture views, and each architecture view consists of architecture models, and adheres to the modeling conventions of its Architecture Viewpoint. A full information of ISO/IEC/IEEE 42010:2011 can be find in the official standard document [8].

Fig. 1.
figure 1

Adapted from [8].

Conceptual model of an architecture description -

3 Research Methodology

This section presents the design and execution of the SMS, which is based on [9]. A SMS provides a structure of the type of research reports and results that have been published by classifying them, and often provides a visual summary, the map of its results [9]. Besides, in this section it is given the process for conducting the SMS, which is composed by Research Question (RQ), Research String, Data Source Selection and Selection of Primary Studies. Therefore, all these steps were considered to understand the use of ISO/IEC/IEEE 42010:2011 regarding its most used items.

3.1 Research Questions

The following research question is proposed: “What studies in the literature have used ISO/IEC/IEEE 42010:2011 as a reference for designing their software architectures?”. In order to answer this research question, a set of questions is defined, as displayed in Table 1.

Table 1. Research questions

The domains cited in Question Q4 are the main final activities to which the software architecture will be applied in software and systems development, as for instance, Education, Transportation, Communication, and so on.

Identification of the possible types of validation mentioned in Question Q5 are those proposed in [10]: Analysis, Experience, Evaluation, Example, Persuasion, and Blatant assertion.

Types of research strategy mentioned in question Q6 are those presented in [11]: Experiments, Surveys, Case Studies, Ethnography, Grounded Theory, Action Research, Phenomenology, Simulation, Mathematical and Logical Proof.

3.2 Search Strategy

A test research was performed to prepare the generic search string, and to choose the databases of papers. First of all, the authors searched on IEEE Explorer, using the string “ISO 42010”. Then, further words of other papers were found, resulting on the following keywords: ISO 42010, ISO/IEC 42010, IEEE 42010, ISO-IEC-IEEE 42010, ISO/IEC/IEEE 42010, ISO STANDARD 42010. Then, at the end of this stage, the following bibliographic bases were chosen: ACM Digital Library, IEEE Xplore, ScienceDirect, Scopus and WebOfScience.

The defined generic search string is displayed in Table 2.

Table 2. Generic search string.

Due to the fact that the first draft of ISO/IEC/IEE 42010:2011 was published in 2007, papers with a date of publication prior to this year were discarded. Also, the inclusion and exclusion criteria were defined to identify relevant works to this research, which are presented as follows:

Inclusion criteria (IC):

  • IC1 - Studies that use ISO/IEEC/IEEE 42010:2011 for defining, evaluating, describing, or developing software architectures.

Exclusion criteria (EC):

  • EC1 - Duplicated papers;

  • EC2 - Secondary study papers;

  • EC3 - Papers written in languages other than English;

  • EC4 - Posters;

  • EC5 - Standards;

The search was conducted on September 12, 2018, returning 128 papers. The results from the databases were exported via bibtex file, and imported into tool StArt [12], which assists Systematic Literature Reviews. This tool is used to organize the references of articles, and then all the references were exported to an online spreadsheet, in this case Google Sheets.

4 Results and Analysis

Figure 2 describes the organization of the SMS’s steps, and the amount of studies resulting in each one. First, using the adopted support tool and manual analysis, 74 papers were rejected regarding the defined Exclusion criteria.

Fig. 2.
figure 2

Representation flow of the SMS.

Second, a selection step was performed. In order to avoid bias, all papers were analyzed independently by two researchers, who applied the defined inclusion and exclusion criteria by reading the title, the keywords and the abstract. At the end of this stage, a meeting was held to resolve doubts or conflicts from the selection, resulting in the final list of 18 papers, 7 from IEEE Xplore, 4 from ScienceDirect, 4 from WebOfScience, 2 from Scopus and 1 from ACM Digital Library.

Finally, data were extracted from the 18 papers in order to answer the questions defined in Table 1. In addition, in the selection phase, data extraction was performed individually by each researcher. Then, at the end of that phase, a meeting was held again to solve doubts or conflicts.

4.1 Q1 - When Was the ISO/IEC/IEEE 42010:2011 Used?

We found that the years of 2016, 2017 and 2018 have the majority of papers, three, four and five respectively, as depicted in Fig. 3. On the other hand, the years that have less papers are 2014 and 2015.

Fig. 3.
figure 3

Q1 - Paper’s Distribution.

4.2 Q2 - What Was the Venue of Publication?

The purpose of this research question was to evaluate from what sources these papers came from. The majority of papers was published in conferences, 12 papers, and the remainder was published in journals, 6 papers. This result may indicate that researchers in Computer Science, specifically in Software Engineering, prefer to publish in conferences, or that the papers are still not mature and with enough details to be published in journals. Additionally, there are 17 different locals of publication, just two locals are mentioned twice: Journal of Systems and Software and IEEE International Conference on Software Architecture (ICSA).

This is an important finding of our research, because it allows other researchers to know in which venues articles about ISO/IEC/IEEE 42010:2011 have been published.

4.3 Q3 - What Aspects from ISO/IEC/IEEE 42010:2011 Are Most Considered?

The purpose of this research question is to identify the most used points of the standard ISO/IEC/IEEE 42010:2011 by the researchers. As a research paper most often has a limited number of pages, we infer that the researchers may not write all the possible aspects from the standard. We listed the main ones to be checked on each paper: Stakeholders (Stkh), Concerns (Conc), View, Viewpoint (Vp), Model, Model Kind (M. Kind), Correspondence (Corr), Correspondence Rule (C. Rule) and Rationale.

These aspects may take a considerable area in the selected papers because they require explanation. Thus, it is possible that the authors preferred to omit them, and not necessarily that they were not considered in their research.

Table 3. Aspects of ISO/IEC/IEEE 42010:2011 found in the papers.

The most used aspects are Concerns and Rationales, mentioned by all papers, as depicted in Fig. 4. When defining the stakeholders, concerns came as a consequence. There is one paper, [29], that did not explicitly mentioned stakeholders and all the requirements were extracted from academic literature. Rationales are presented in any software architecture, because they are the reason for decisions.

Stakeholders are the key to any architecture, as they define the main elements of a Software Architecture, 17 papers mentioned this aspect.

The third most mentioned architectural element is Model and Model Kind, 14 out of 18 papers mentioned them. Model and Model Kind refers basically to the type of diagrams, and the most used modeling language is UML, in 10 papers, followed by SysML (3 papers) and SoaML (1 paper). One paper used together UML and SysML, and another used UML and SoaML. This result may be expected because UML is probably the most used modeling language in Software Engineering [31, 32].

Another finding of this SMS is that some of the papers that identified the views did not mention what views they used. In contrast, others, explicitly, mention what views they used: [15, 17,18,19, 22, 24, 27, 29] and [23].

Fig. 4.
figure 4

Q3 - Most considered Architectural Aspects of ISO/IEC/IEEE 42010:2011.

Q3.1- Which Models Were Used? When analyzing the Model Kinds used in the papers, the Use Case, Class and State Machine diagrams are the most mentioned ones, as shown in Fig. 5. This may be an expected result because Use Case diagrams describe scenarios and functional requirements [33], making easier to understand what the system does and give a good means of communication about the system [34]. Furthermore, Class Diagrams can be directly mapped to object-oriented languages, and they are the basis of software construction. Component diagram is the fourth most mentioned model, in four papers, followed by the Sequence diagram, 2 times.

In paper [22], Definition Block and Internal Block diagrams were mentioned. Publication [30] adopted SysML diagrams, and used the following models: Sequence, Package, Use Case, State Machine and Definition Block. As the Sequence, Package, Use Case and State Machine diagrams are part of the UML, they were also included in Fig. 5.

Finally, diagrams mentioned from SoaML were Service Architecture, Participant and Data Exchange.

Fig. 5.
figure 5

Q3.1 - UML diagrams that were mentioned on the architectures.

Fig. 6.
figure 6

Q4 - Domains in which the Architecture Description was applied.

4.4 Q4 - in Which Domains Was ISO/IEC/IEEE 42010:2011 Used?

As depicted in Fig. 6, the Transportation domain is the subject of study in six articles. The second domain in which the standard was applied is Industry.

ISO/IEC/IEEE 42010:2011 was also applied in the Energy and Health domain. For the rest of the domains mentioned in Fig. 6, the standard was mentioned once. Furthermore, we could not identify the domain of paper [16].

4.5 Q5 - What Type of Validation Was Considered?

In Software Engineering, the type of validation plays a big role for a good software project. The research presented in paper [10] reports that the most successful types of validation were based on analysis and real-world experience. Figure 7 shows that Experience is the most used type of validation. Thus, one way to know if a software project will be successful is testing it, preferably in the real world. Besides, if the project fails, it is also useful to know the problems that cause it.

The second most used type of validation is Analysis with 4 papers. Analysis is also a good type of validation because the authors can show if their solution is worth or not by applying the solution in realistic examples.

Fig. 7.
figure 7

Q5 - Types of Validations found in the papers.

4.6 Q6 - What Type of Research Strategy Was Considered?

According to [11], a research strategy is an overall plan for conducting a research study, and the strategy guides a researcher in planning, executing, and monitoring the study. Among the types of research strategy proposed in paper [11], we found 3 types in 15 papers of this study. Besides, it was not possible to define the research strategy of 4 papers.

Case Study was found in the majority of papers, in a total of 8 studies. This may be the research strategy near to the real world with less cost. However, the fact that the research is successful in one case does not mean that it will be in any case. Action Research is the second considered one with 5 papers. This research strategy is used to solve problems in a real environment, and most of them was found in industry, health, financial and transportation domains. The last one is simulation, found in the Energy domain.

Based on the definitions offered in [11], the authors could not classify the research in papers [16, 19], since they did not provide enough information about the type of research strategy adopted in these papers. Additionally, papers [30] and [29] did not explicitly provided a research strategy, but in their future work, they will consider a case study for their research.

5 Threats to Validity

The results of this research may have been affected by several factors that are categorized as follows.

Selection Bias. Some studies may be included or excluded into the SMS incorrectly. With the purpose of reducing this threat, the research protocol was discussed between the researchers to guarantee a common understanding, and the researchers made decisions together in a meeting for each item that they were in doubt.

Data Extraction. Bias or problem of extraction can influence classifications and the analysis of selected studies. For reducing this bias, the researchers discussed the definitions of each item used to respond the questions. The data extraction form was a spreadsheet composed of 16 columns (data extraction attributes), which was structured as follows: 5 columns related to article identification, 2 columns related to context of the research, and 9 columns related to attributes of ISO/IEC/IEEE 42010:2011.

Generalization. It is possible to generalize the information from this research. Even though the number of papers addressing ISO/IEC/IEEE 42010:2011 standard can be considered small, the search string was wide as possible, to reach the majority of papers in the databases.

External. We can not generalize this information because there is not a significant number of scientific papers addressing the ISO/IEC/IEEE 42010:2011 standard. Furthermore, we may not identify other papers that are suitable to the standard, but do not make reference to it. In order to mitigate this threat, the search string was created to reach as many papers as possible.

6 Conclusions and Future Works

In this paper we presented a Systematic Mapping Study that investigates studies which used ISO/IEC/IEEE 42010:2011 on their software architectures. The most relevant findings from this research are as follows.

First, the number of researches that are using ISO/IEC/IEEE 42010:2011 are increasing since 2016, and most of them are published in conferences. Second, the most used architectural aspects are Stakeholders and Concerns, 18 out of 19 papers mentioned them. Third, UML is the authors’ preferred modelling language in software/system architecture, found in 10 papers. Fourth, transportation is the domain in which the standard is most applied, followed by industry, health and energy. Fifth, Experience is the most used type of validation, and Case Study is the most used type of research strategy in projects that used ISO/IEC/IEEE 42010:2011.

The results of this Systematic Mapping Study should provide insights and encourage further research applying ISO/IEC/IEEE 42010:2011 in software architectures.

As a future work, we suggest a further research analyzing all the aspects of the standard. Besides, an industrial study which will analyze companies that use the standard and verify what aspects can be performed.