SOAR
The whole development process is a large set of processes that are multiple and interdependent in terms of work products. In this context, SOAR was conceived to allow for creating process instances in consonance with whole SoS development process. For this, we established an interface with inputs and outputs that must be adequately dealt in the general development process. Our approach is compatible with the general process for SoS development from DoD, which describes a general development process at systems engineering level that reflects the current the state-of-the-art in Acknowledged SoS projects. The figure below represents how SOAR can be executed in the context of an iterative and evolutionary development cycle of Acknowledged SoS projects. At the central strip, the architecting processes are executed receiving the general context analysis performed at system engineering level and delivering to implementation stages the SoS validated architecture with its different layers, i.e., physical, organizational, software, etc. SOAR is conceived to support the architecting process at software layer and its activities are performed at this stage, delivering the respective software architecture. Despite the communication with other external processes of SoS development is considered in SOAR structure, software architecture is the central concern to be encompassed in SOAR instances.
SOAR was conceived to provide a well-defined documentation that includes activities, work products, and guidelines to apply them. For this, we adopted the OMG’s Essence Standard that includes a process authoring language, named the Essence Language, which is a flexible notation that allows the authoring of software engineering processes in different scopes and levels of specificity, and a general kernel for software development process, named the Essence Kernel, which provides the a basis of general concepts useful for any software engineering project. Despite the existence of more mature languages for process authoring such as SPEM, this new standard was proposed to be flexible, easy to use, and adequate to evolutionary developments projects, in which the processes can also evolve itself maintaining its alignment with different development stages of development.
Each SoS also has particular issues surrounding its development and a general process as SOAR must have an adequate level o abstraction. Being too general can result in useless processes, since main SoS challenges could be not encompassed. Conversely, being too specific can generate very exclusive solutions which low exploration of SoS common challenges and low impact for reuse. Due to the complex, multidisciplinary nature of SoS and their software architectures, we adopted to SOAR structure a modular strategy with two levels of abstraction. The first level is suited for experienced teams, which must only check if their already well established processes adequately encompass the design of Acknowledged SoS software architectures and if improvements can be planned. The second abstraction level provides more detailed guidance for project teams not experienced in SOAR scope. Furthermore, SOAR is also independent of specific architectural styles, architectural patterns, and application domains in order to reach the affordable balance between generality and specificity. The proposition of different abstraction levels, and consequently possibilities of use, was possible by using two main elements of Essence Language, the Kernels and the Practices. Figure below shows SOAR organization in terms of its main elements and basic workflow. Since the complexity of the design processes does not allow the establishment of a mandatory workflow with a regular sequence of execution. The presented workflow is only a reference of execution and the project teams must plan and adopt the necessary workflow at each development context and evolution stage. These elements are briefly introduced as follows.
The SOAR Kernel is the SOAR element at highest level of abstraction and was conceived to provide a common ground on the construction of Acknowledged SoS software architectures including common vocabulary, concepts, and general guidelines.
The SOAR-A Practice is proposed to guide how to perform architectural analysis in the SOAR scope describing a set of specific activities and related work products recommended to architectural analysis of Acknowledged SoS software architectures. The main output of this practice is the architectural requirements, which must be elicited to guide the further architectural design activities.
The SOAR-S Practice is proposed to guide the architectural synthesis in SOAR scope. In this context, it describes a set of specific activities and related work products recommended to architectural synthesis of Acknowledged SoS software architectures. A central concern in SoS development is the definition of an SoS architecture capable of express the structures of the SoS with its constituent systems including their relationships, connections, interactions, and parameters. In synthesis phase, the fundamental design decisions are made and the main output is a candidate architecture proposed to meet the SoS architectural requirements.
Finally, the SOAR-E Practice is proposed to guide the architectural evaluation in SOAR, also providing a set of activities and work products to encompass the architectural evaluation on Acknowledged SoS software architectures. The main output of this practice is a validated architectural version and the respective evaluation reporting information.
Copyright © 2016 ICMC Instituto de Ciências Matemáticas e de Computação, University of São Paulo (USP), Brasil - IRISA Institut de Recherche en Informatique et Systèmes Aléatoires, Université de Bretagne-Sud (UBS), France, ver. 1.0