Towards suitable description of reference architectures

Reference architectures

During the last around 30 years, both academia and industry have invested effort to consolidate the area of reference architecture by proposing definitions to reference architectures (Kruchten, 2000; Nakagawa, Oliveira & Becker, 2011), their benefits and drawbacks (Martínez-Fernández et al., 2017), and means to engineer (Angelov, Grefen & Greefhorst, 2012; Nakagawa et al., 2014; Muller, 2008; Galster & Avgeriou, 2011) and describe them (Eklund et al., 2012; Guessi, Oquendo & Nakagawa, 2014b; Gherardi & Brugali, 2014).

Reference architectures can be used to provide (Muller, 2008): (i) a common lexicon and taxonomy that facilitate the communication among stakeholders; (ii) a common architectural vision, which manages the efforts of the several people and teams involved; and (iii) modularization and complementary context that assist in the division and integration of efforts posteriorly. It is worth highlighting that, more importantly, reference architectures avoid the reinvention and revalidation of solutions to problems that were already solved (Nakagawa, Oliveira & Becker, 2011).

To systematize the building of reference architectures, the scientific community has already contributed with different initiatives. Muller (2008) proposed recommendations to build and evolve reference architectures, where these architectures should be easy to understand and evolve. Bayer et al. (2004) and  Pohl, Böckle & Linden (2005) proposed a systematic approach to define reference architectures from the knowledge of existing systems in the context of software product line (SPL). Cloutier et al. (2010) presented a high-level model for reference architecture development in systems engineering. Nakagawa et al. (2014) proposed a process, called ProSA-RA, that systematizes the design, representation, and evaluation of reference architectures. Angelov, Grefen & Greefhorst (2012) developed a classification that can support the design of reference architectures. Finally, Galster & Avgeriou (2011) proposed a six-step procedure for reference architecture design. It is important to observe these different approaches include an activity for architectural description of reference architectures, but without detailing or specifying guidelines for that. Hence, other complementary studies, like those found in this work and discussed in ‘Results’ have emerged to cover this lack.

Software architecture description

Serving as an important support to the communication and cooperation in software project teams, the architecture description of a software system should be adequately available to a variety of stakeholders. An architecture description should serve as (International Organization for Standardization, 2011): (i) a baseline for system design and development activities; (ii) a baseline to analyze and evaluate alternative implementations of an architecture; (iii) a support to the system development and maintenance; (iv) a support to document characteristics, features, and design of a system for potential clients, acquirers, owners, operators, and integrators; (v) a basis to analyze and evaluate alternative architectures; and (vi) a means to share lessons learned and reuse architectural knowledge through viewpoints, patterns, and styles.

The ISO/IEC/IEEE 42010 established definitions and relationships among the main elements that compose architecture descriptions, e.g., stakeholder, concern, architecture decision, architecture view, architecture viewpoint, and architecture model, but it does not suggest or impose any specific process, method, model, notation, or technique to produce an architecture description. Hence, this standard can serve as a basis for different approaches, such as document-centric, model-based, and repository-based techniques (International Organization for Standardization, 2011). Due to this flexibility, this standard becomes popular and is to some extent widely adopted by both academia and industry.

With regard to views to describe software architectures, Kruchten (1995) proposed 4+1 view model containing five views: (i) logic view that shows the components (objects) of the system and their interactions; (ii) process view that shows processes/workflow rules of a system and how these processes communicate with each other; (iii) development view that presents a building block view of the system; (iv) physical view that shows the system execution environment; and (v) scenario view (also use case view) that shows a set of use cases serving to illustrate and validate the architecture design. Another well-established work is “Views and Beyond” by Clements et al. (2011) and, to describe an architecture, most relevant architectural views are firstly documented, and then additional documentation to the views are developed. Views are classified into three main categories: (i) modular view that describes the structure of the system as a set of implementation units; (ii) component-and-connector view that describes the structure of the system at the time it is running; and (iii) implementation view that describes how the system relates to other structures in its environment.

Sustainability of reference architectures

Sustainability was brought to the software architecture area as an important concept related to the capacity of software architectures to tolerate modifications throughout the software systems life cycle (Avgeriou, Stal & Hilliard, 2013). In parallel, due to reference architectures encompass a valuable knowledge of a given domain, their sustainability is also considered of utmost importance.

While several reference architectures have been proposed for various application domains, many of them have not survived. For instance, Volpato et al. (2017) analyzed 20 reference architectures, most of them destined to software systems based on service-oriented architecture (SOA), an architectural style widely adopted to develop software-intensive systems for different and even critical domains. Results showed 12 of them did not present any evidence (publications, projects, and/or websites) indicating updates or initiatives for using or disseminating them. In addition, these architectures did not have a good architectural description in the sense that it provided good support for the use and dissemination of these architectures. It is important to mention that other factors, such as financial support, economic viability, and the existence of a consortium, also impact the sustainability of reference architectures (Volpato et al., 2017).

On the other hand, reference architectures that have a good description have survived for decades, being constantly updated accordingly to the advance of their application domain. For instance, AUTOSAR, a well-known reference architecture for the automotive sector, adopts an update policy with release and version control of its documentation to manage evolution (Venters et al., 2018). Their current version is described in 22,271 pages organized into 220 files. The same occurs in other reference architectures, such as AXMEDIS and ARC-IT with life cycles of over 14 and 25 years, respectively.

In this scenario, sustainability in the context of reference architectures can have two perspectives (Volpato et al., 2017): (i) the perspective “IN” is about understanding how sustainable the concrete software architectures that are instantiated from a given reference architecture are; and (ii) the perspective “OF” (which is addressed in this work) refers to how the reference architectures themselves are sustainable. Regarding this last perspective, this study also highlights the reference architecture description must be continually updated and aligned with the state of practice to achieve sustainable architectures; also, this study exemplifies eight reference architectures that have sustained over time by keeping their description updated.

Related work

With regard to the related work, we identified a systematic literature review (SLR) on architectural description of software architectures and reference architectures of embedded systems (Guessi et al., 2012). This work identified 24 studies to answer: (i) how software architectures and reference architectures of the embedded systems have been modeled; and (ii) which approaches have been adopted for that. As the main result, the authors concluded that there is no consensus on how to better describe the architectures of embedded systems. They also identified a range of quality requirements and constraints that have been considered in the architectural description of embedded systems.

Another SLR was conducted to understand how Systems-of-Systems (SoS) software architectures have been described (Guessi et al., 2015). The authors selected 38 primary studies to answer their research questions: (i) how the literature has addressed the architecture description of SoS; and (ii) which techniques have been used in the description of software architectures of SoS. The authors suggested that more research should be conducted for effectively using architecture descriptions in the evaluation and evolution of SoS. They also proposed a set of research lines to be further addressed, including the establishment of architecture viewpoints framing important quality attributes for SoS and a consensus on the formalism level required at each stage of their life cycle.

As far as we know, there are not literature surveys, systematic mapping study (SMS), or other SLR on approaches for describing reference architectures. Then, the novelty of our work is to present a wider panorama of these approaches (independently of the domain of the reference architectures or type of systems) and also analyze how well-known, successful reference architectures have been described.

Planning

We adopted the GQM (Goal Question Metric) approach (Basili, Caldiera & Rombach, 1994) to support the conduction of our SMS and also to examine the four reference architectures. GQM is composed of three parts (Basili, Caldiera & Rombach, 1994): (i) the goal to be achieved; (ii) a set of questions that must be answered to achieve the goal; and (iii) a set of metrics needed to answer the questions. Hence, the goal of this work is:

Analyze approaches to describe reference architectures

for the purpose of their evaluation and classification

with respect to adherence to the ISO/IEC/IEEE 42010

from the viewpoint of the software engineering research

in the context of sustainability.

It is worth highlighting that we adopted the international standard ISO/IEC/IEEE 42010.²

Table 1 presents the three research questions (RQs) and their respective metrics.

RQ1 aims to collect possibly all existing approaches to describe reference architectures through metrics M_1.1 to M_1.4. RQ2 intends to analyze the adherence of the approaches to ISO/IEC/IEEE 42010, which is an international standard for architecture descriptions of systems and software. Metrics M_2.1 to M_2.9 aim to collect nine elements directly related to the description of reference architectures: view, viewpoint, type of model, stakeholder, concern, architectural decision, rationale, ADL, and type of architectural decisions. RQ3 aims to analyze how well-known, successful reference architectures have been described and is answered by examining four reference architectures through metrics M _3.1 to M_3.7.

To define the search string of our SMS, we selected two keywords: reference architecture and software architecture. As reference architecture is a well-known, disseminated term, we did not consider other related terms. Otherwise, we considered the following similar terms of software architecture as also used in Qureshi, Usman & Ikram (2013): software structure, software design, system architecture, system structure, and system design. Hence, the final search string³ was: (“reference architecture” and (“software architecture” or “software structure” or “software design” or “system architecture” or “system structure” or “system design”)). As shown in Table 2, we accordingly adapted this string to the specific syntax of each publication database to perform the searches.

With regard to the publication databases, we selected those recommended in (Kitchenham et al. (2009): Scopus (http://scopus.com), Web of Science (http://isiknowledge.com), IEEE Xplore (https://ieeexplore.ieee.org), ACM Digital Library (http://dl.acm.org), ScienceDirect (http://sciencedirect.com), and SpringerLink (http://link.springer.com). Scopus, ScienceDirect, and Web of Science are general indexing systems and allow us to cover a broader scope for our search. IEEE Xplore, ACM Digital Library, and SpringerLink publish works of the most important venues (conferences and journals) related to software architectures. We also defined one inclusion criterion (IC) and three exclusion criteria (EC):

1. IC1: The study proposes an approach to describe reference architectures.

2. EC1: The study does not address an approach to describe reference architectures.

3. EC2: The study does not permit to identify information about the approaches, because it is a table of contents, short course description, invited talk of events, summary of events, among others, or written in other languages than English.

4. EC3: The study was not peer-reviewed.

Conduction

This SMS was first conducted from January to July 2018 by four researchers from both industry and academia and with experience in reference architectures and software architectures, besides their experience in researching, conducting, and updating a number of SMS and SLR. Figure 1 depicts the steps of the selection process. By adapting the search string for each database, we performed the searches and obtained a total of 989 studies. After removing the duplicated studies, 589 studies remained. After the first selection where we applied the selection criteria on title, abstract, and keywords, 183 studies were selected. After reading the full text of these studies and applying the selection criteria again, 17 studies were finally selected. Besides that, an inspection of the list of references of each selected study (through snowballing approach (Wohlin, 2014)) made us possible to include other two relevant studies, totaling 19 studies. To support this selection process, we used JabRef (http://www.jabref.org).

Considering the need of updating our SMS (Mendes et al., 2020), in December 2020, we updated it aiming at including studies published in 2018 (i.e., months not covered in the first version of the SMS), 2019, and 2020. For that, we used the snowballing approach that refers to using the reference list of a study or the citations to a given study to identify additional studies. According to Wohlin (2014), snowballing is particularly useful for extending an SLR or SMS, since new studies almost certainly must cite at least one study among the previously relevant studies. Hence, snowballing is by deduction a better approach than a database search for extending SMS (Wohlin, 2014). Felizardo et al. (2016) also found that snowballing presents an overall precision to search for new studies similar to searches in databases.

In particular, we applied forward snowballing, since it could identify new studies published in 2018, 2019, and 2020. For that, the reference lists of the 19 studies initially included in our SMS were considered. Following, we used information made available in Google Scholar to find all studies that cited those 19 studies and, as a result, we identified 108 candidate studies. We checked the title, abstract, and keywords of the 108 studies and applied the inclusion and exclusion criteria. Hence, 82 studies were excluded and 26 remained. Following, we read the full text of the 26 studies and applied again the inclusion and exclusion criteria. As a result, no new study published between 2018 and 2020 was suitable to answer our RQ; hence, no new study was included in our SMS.

We used an online form for the data extraction and analysis of each study. This form was designed to collect data to answer RQ1 and RQ2. Data from each study was then extracted by one researcher involved in this study and when there were doubts, discussions with other researchers were conducted. The dataset gathered from this form together with a qualitative and qualitative analysis supported us to synthesize results, answer these RQs, and further draw conclusions.

To answer RQ3 and identify the state of the practice about how reference architecture has been described, we examined four reference architectures (AUTOSAR, ARC-IT, IIRA, and AXMEDIS), which are from different application domains. Based on our experience of more than 15 years at researching and establishing reference architectures, we selected such architectures because they are widely known in the industry, besides presenting long-time existence. We also have previously investigated them in our research group, i.e., we have followed the evolution of these architectures over the years.

Overview of studies

Table 3 lists the 19 studies included in our SMS, together with their ID (S1 to S19), title, publication year, reference, publication venue (i.e., W = workshop, TR = technical report, C = conference, J = journal, or BC = book chapter), context where the approach was developed (i.e., A = academia or I = industry), quantity of reference architectures described using the approach, domain for which the approach was created, and type of the approach (e.g., process, method, model, among others).

It is observed that the first three studies (S1, S2, and S3, published in 1994, 1998, and 1998, respectively) were published in workshops when the first events in this area were proposed. Hence, regarding the publication venues, while around one-third of studies were published in workshops, around half part of the studies were published in conferences; besides that, only two studies were published in journals, equally as the two technical reports, and only one book chapter. The concentration of studies in events (conference and workshops) may be related to the fact that studies are not still enough mature to be published in high-impact journals.

It is also worth highlighting that the first studies were published in 1994 and 1998 and, after that, there is a gap until 2003 when other studies started to be published. This gap may have happened because only after the 2000s, reference architectures started to show their value to the software systems development and, hence, they became more popular together with the software architecture area. Consequently, studies concerning representation/description of these architectures become necessary and have been published in the last almost two decades.

Moreover, around one-third of the studies focused on describing reference architectures of specific application domains, mainly those critical, while around two-thirds intended to be generic enough to address different domains. In these 19 studies, we found the description of only five reference architectures using the proposed approaches. Similarly, only four studies were developed in the industry context. Hence, the research topic of reference architecture description is still relatively new and requires to be matured and disseminated.

Approaches to reference architecture description

This section deeps the analysis of the existing approaches through data collected using metrics M_1.1 (Number of approaches proposed by year), M_1.2 (Number of approaches proposed in academia and industry, i.e., the Context), M_1.3 (Application Domains targeted by the approach), and M_1.4 (Type of contribution). Regarding M_1.1, the first study was published in the early of 1990s and most of them are concentrated in the last decade, as illustrated in Fig. 2, showing a trend to an increased interest in this area. Concerning the other three metrics, a summary of the analysis is shown in Fig. 3 and is detailed below.

Adherence of the approaches to ISO/IEC/IEEE 42010

Figure 4 summarizes the results.

An architecture view considers one or more of the concerns held by the system’s stakeholders, i.e., it expresses the architecture of a system from the perspective of specific system concerns (International Organization for Standardization, 2011). To identify the architecture views in the studies, we considered those views proposed, used, and/or cited throughout each study. Table 5 shows the 21 different views (exactly as mentioned and found in nine studies), together with a description of each view.

An architecture viewpoint establishes the conventions for the construction, interpretation, and use of architecture views to frame specific system concerns (International Organization for Standardization, 2011). We identified 25 architectural viewpoints that were proposed, used, and/or cited in one-third of the studies (6 of 19). Table 6 presents these viewpoints and studies that addressed them. Still in this table, we present a description of each viewpoint to help architects and researchers to better understand them and further select them to represent their reference architectures. As shown in Table 6, S5 is the most complete study compared with the others by proposing seven viewpoints, while S17 only considered one viewpoint.

A model kind defines the conventions for one type of architecture model (International Organization for Standardization, 2011). We identified 13 different model kinds (i.e., diagrams) to describe reference architectures in approximately half part of the studies (9 of 19), as shown in Table 7. Model kinds that can represent the behavior of components and systems built from the reference architectures were the most recurrent in the studies. More specifically, S3, S4, S5, S7, and S8 used UML behavior diagrams: use case diagram, activity diagram, sequence diagram, state diagram, and collaboration diagram. UML structure diagrams were also suggested: component diagram, package diagram, and class diagram. Moreover, S17 explored the SysML internal block diagram, while two studies (S3 and S5) used the workflow diagram.

A stakeholder can be an individual, team, or organization that have an interest in a system (International Organization for Standardization, 2011). As presented in Table 8, we identified ten different stakeholders in six studies to be considered during the description of reference architectures, including mainly software architects, project managers, and developers. However, these studies did not present how to involve them and which their tasks are.

A concern refers to any interest in the system (International Organization for Standardization, 2011). A concern can appear in different forms, such as quality attributes, architecture decisions, risks, and other issues. Only two studies (S4 and S7) addressed concerns, but few details were presented. S4 provided means to describe the stakeholders’ concerns in the viewpoints and, for this, a set of questions guide architects to understand stakeholders’ concerns. S7 considered concerns related to business rules to describe reference architectures, but few details were provided on how these concerns should be considered.

An architecture decision affects the architecture description elements and pertains to one or more concerns (International Organization for Standardization, 2011). Only three studies (S7, S14, and S15) addressed architectural decisions for the design of reference architectures. S7 represented architectural decisions in a semi-formal way using architectural patterns and a meta-model, while S14 and S15 represented such decisions in an informal way through text description.

A rationale refers to the explanation, justification, or reasoning about architecture decisions that have been made and also architectural alternatives not chosen (International Organization for Standardization, 2011). Only S7 and S14 considered rationale. S7 addressed rationales for architectural decision-making through a textual description, while S14 used a meta-model and textual description to represent rationales.

An ADL refers to any form of expression for the architecture description (International Organization for Standardization, 2011). Some representative examples are Rapide, SysML, and ArchiMate. Only S2 considered a formal ADL, namely Rapide ADL, for the reference architecture description and specified from simple protocols for interaction to more complicated requirements regarding information flow.

We also looked for types of architectural decisions (e.g., architectural patterns, styles, and technologies) which approaches considered. However, three studies (S4, S7, and S15) only mentioned the possibility of using them, without in fact using them. S4 mentioned the architectural styles client–server, Model-View-Controller, layered, event-driven, and blackboard. S7 mentioned the SOA architectural style, while S15 mentioned the Jade and AGLOBE patterns.

As described along with this section, we can observe that three common elements (architectural view, viewpoint, and model kind) proposed by ISO/IEC/IEEE 42010 are recurrent in the state of the art, but the other six elements are not widely treated in the approaches. Finding 4: The existing approaches do not consider important elements proposed by ISO/IEC/IEEE 42010 that could describe reference architectures suitably.

The next section examines the description of four reference architectures, also analyzing which elements of ISO/IEC/IEEE 42010 they considered in their descriptions.

Analysis of four successful reference architectures

AUTOSAR (https://www.autosar.org) is a well-known reference architecture for the automotive sector and has brought several significant benefits related to standardization, interoperability facilitation, knowledge reuse, and improvement in the communication among interested parties (e.g., vehicle manufacturers, suppliers, and other companies from the electronics, semiconductors, and software industry). This architecture was established in 2002 and is currently maintained by the core partners of manufacturers, such as BMW Group, PSA Group, Ford, Toyota, Volkswagen, and Bosch. To maintain the 18-year life cycle, AUTOSAR adopts an update policy with release and version control of its documentation. Similarly, ARC-IT (Architecture Reference for Cooperative and Intelligent Transportation) (https://local.iteris.com/arc-it/index.html) was designed by the US Department of Traffic in 1996. After 24 years, this architecture has 13 versions with updates in the communication standards among intelligent vehicles and refinement in their description. Another reference architecture analyzed is for Industry 4.0. IIRA (Industrial Internet Reference Architecture) (https://www.iiconsortium.org/IIRA-1.7.htm) enables architects of industrial internet of things systems to design systems based on a common framework and concepts. The architecture team maintains a living document that is updated to reflect learnings from real-world projects and the latest technologies. AXMEDIS (Architecture for Automating Production of Cross Media Context) (http://www.axmedis.org/com/) is also a sustainable reference architecture. In its 15-year life cycle, the AXMEDIS team provided three big releases with updates in standards to content management of partners, such as BBC and HP, and refinement of their description with new viewpoints.

Following, we depict our analysis of how these architectures were described.

Threats to validity

To minimize biases of our study, we present below the potential threats to validity and actions that we performed to mitigate them:

• Missing of important studies: Studies that proposed approaches to describe reference architectures may not have been considered in our analysis. To mitigate this threat, we systematically followed the SMS protocol, besides adopting six databases considering as the most relevant sources in the software engineering area. We also carried out a manual search using Google Scholar, conferences and journals of the area, technical reports, and book chapters.

• Data extraction: During data extraction, we created a data extraction form to fill and save all answers from each study. However, not all the information were obvious to be extracted from the studies and, then, some information had to be interpreted; for instance, the elements of ISO/IEC/IEEE 42010 considered by each approach. In addition, in the event of a disagreement among reviewers, discussions were conducted.

• Relevance of studies: The amount and relevance of the studies selected in our SMS may be considered as a threat to validity to the generalization of the results. To minimize this threat, we systematically followed the SMS protocol to select relevant studies together with the entire involvement of all authors of this work.