Article Preview
Top1. Introduction
In recent years, SoSs have experienced an increasing evolution and interest from the computer science community. SoSs are not designed in a top-down way, they have been designed to integrate multiple independent functional systems into a larger system in several important application domains. However, these Constituent-Systems (CSs) are becoming larger, more complex, and difficult to develop as well. Examples of these large-scale systems can be found in several fields such as Robotics, Avionics, Military, Intelligent systems (Smart-Grids, Smart-Cities, Smart-Homes, etc.). An SoS is characterized by offering new functionalities to users that cannot be offered by its CSs, but emerging from their combination. The CSs making up an SoS are independent, geographically distributed, developed with different technologies and intended for several platforms.
As SoSs get more and more complex, engineers need to pay a lot of attention to early-stage design decisions rather than focusing on implementation and writing code. This will facilitate the process of developing such large-scale systems. Additionally, Architecture Frameworks are a recent discipline in Software Engineering (SE) that consider Architectural Viewpoints as first-class entities in software development. The viewpoints have become the major paradigm in which the SE will be able to open a door to the development representation and provide a new way of designing systems. In the context of SoSs, we argue that our architecture framework encompassing the knowledge on how to design SoSs would ease the application of this process and, consequently, produce an SoS of higher quality. A single comprehensive viewpoint of an SoS’ architecture is often too complex to be understood and communicated in its most detailed form, showing all the relationships between the various business, structural and behavioral aspects. Therefore, we are seeking to represent by means of one or more architecture viewpoints that together can provide a unified AF of SoS’ architecture.
1.1 Context and Problematic
The field of SoSs comes up against constraints during the engineering process. The difficulty of modeling SoSs lies in the complexity resulting from the interaction, cooperation and collaboration of their heterogeneous CSs, which each have specific goals to accomplish, different roles to play, and they are not easily interoperable. Independent evolution and dynamic changes can cause these CSs to be- have differently. These changes can affect their interactions and communications within the SoS and consequently, it can derail the overall mission of the SoS. Architecting an SoS helps to understand how it works, as well as to master its complexity before its implementation.
In this new perspective, SoSs development does not follow the normal system development process. As SoSs’ capabilities are based on the contributions of the individual CSs, their interdependences make a document-centric development impractical as an exorbitant effort. The development processes refer to activities that can guide an SoS’ lifecycles from the system requirements level down to the software implementation level, and naturally, by coordinating the various processes for the development of a new system (Dridi et al., 2020).
From a SE perspective, design decisions made at the architectural level have a direct impact on the fulfillment of functional and quality requirements of SoSs development. At this stage, the SoS’ Stakeholders identify functional and non-functional characteristics through the use of their own theoretical backgrounds, notations and environments. In addition, the SoSs’ architectures are still created without the support of a systematic processes and traditional design approaches do not adequately support the creation of these types of systems due to their composed nature, their large-scale, their decentralized control mechanism, their evolving environments, and their large number of stakeholders (Dridi et al., 2020).