Keywords: Systems-of-Systems, SoS, Model-Based Engineering, Software Architecture, Simulation

Context: Software-intensive systems have been increasingly interoperated forming alliances termed as Systems-of-Systems (SoS). SoS comprises a collection of systems joined to achieve a set of missions that none of the systems can accomplish on its own. Each constituent system keeps its own management, goals, and resources while coordinating within the SoS and adapting to meet SoS goals. Applications of SoS range from traffic control to emergency response and crisis management. As SoS often support critical domains, such systems must be correct by dealing with malfunction or defects and avoiding failures that could cause extensive damage and losses to the users.

Problem: Correct SoS operations depend on a precise specification and a rigorous attestation of its operational consistency. However, besides limitations on languages to jointly capture SoS structure and behavior, predictions on the SoS operational consistency rely on constituent systems not totally known at design-time. Therefore, SoS have been developed and deployed without evaluating their operations, since current languages do not support such precision in evaluation.

Objectives: This thesis provides solutions founded on a formal architectural description language to support an early evaluation of SoS operation regarding SoS structure and behavior by means of simulations.

Contribution:

The main contributions of this project comprise (i) a model transformation approach for automatically producing simulation models from SoS software architecture descriptions, combining SoS structure and behavior description in a same solution, (ii) a SoS software architecture evaluation method for SoS operation prediction considering the inherent changes that can occur, (iii) environment modelling and automatic generation of stimuli generators to sustain the SoS simulation, delivering data to feed such simulation, and (iv) a method for the automatic synchronization between the runtime descriptive architecture (changed at runtime due to dynamic architecture) and its original prescriptive architecture based on model discovery and recovery mechanisms and a backward model transformation.

Evaluation:

We conducted case studies to assess our solutions using Flood Monitoring Une approche dirigée par les simulations à base de modèles pour concevoir les architectures de systèmes-des-systèmes à logiciel prépondérant Valdemar Vicente Graciano Neto 2019 SoS and Space SoS.

Results: Our solutions support a high accuracy to (i) produce fault-free and fully operational simulations for SoS software architectures, (ii) support evaluation and prediction of SoS operation at design-time, (iii) automatically generate stimuli generators to sustain and feed the simulation execution, and (iv) maintain the synchronization between the runtime architecture and the intended version of the SoS architecture.

Conclusions: We concluded that the proposed solutions advance the state of the art in SoS software architecture evaluation by offering solutions to predict the SoS operations effectiveness to maintain a continuous operation despite architectural changes, providing more trust for users that futurely shall rely on SoS services.

RESUMO

GRACIANO NETO, V. V. Uma abordagem digirida por simulação e baseada em modelos para projeto de arquiteturas de sistemas de sistemas intensivos em software . 2018. 217 p. Tese (Doutorado em Ciências -Ciências de Computação e Matemática Computacional) -Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Carlos -SP, 2018.

Contexto: Sistemas intensivos em software tem sido interoperados para formar alianças conhecidas como Sistemas-de-Sistemas (SoS). Domínios de aplicação de SoS variam do controle de tráfego ao gerenciamento de situações de crises e emergência. Devido à criticidade destes domínios, tais sistemas precisam ser confiáveis e robustos, lidando com potenciais defeitos e mal funcionamento, e evitando falhas que poderiam causar ameaças à integridade dos usuários.

Problema: O funcionamento correto de um SoS depende da especificação precisa e da garantia rigorosa da consistência de suas operações. Entretanto, além das limitações nas linguagens quanto à especificação de ambos estrutura e comportamento do SoS, prever seu comportamento depende da especificação de constituintes que não são totalmente conhecidos em tempo de projeto e de seu comportamento emergente. Neste sentido, SoS têm sido desenvolvidos e implantados sem a devida avaliação de seus comportamentos, uma vez que as linguagens disponíveis atualmente não dão suporte a uma especificação precisa destes comportamentos.

Objetivos: Este projeto de doutorado relata avanços teóricos e práticos fundamentados em uma linguagem de descrição arquitetural formal para permitir a predição e avaliação do comportamento e estrutura dos SoS com base em simulações.

Contribuições: As principais contribuições deste projeto envolvem (i) uma transformação de modelos para produzir automaticamente modelos de simulação para descrições de arquitetura de software de SoS, combinando estrutura e comportamento em uma mesma solução, (ii) um método de avaliação de arquitetura de software de SoS para prever o comportamento do SoS considerando sua dinâmica inerente, (iii) modelagem do ambiente e derivação automática de geradores de estímulos entregando dados continuamente e sustentando a execução de simulações de SoS, e (iv) um método para promover a sincronização automática entre modelos descritivos e prescritivos de arquitetura de software de SoS baseados em mecanismos de descoberta e recuperçaão de modelos, e transformação de modelos reversa.

Avaliação: Estudos de caso foram conduzidos para avaliar as soluções nos domínios de Monitoramento de Enchentes e Espacial.

Resultados: As abordagens propostas exibem alta acurácia no que tange (i) a produzir simulações operacionais e sem falhas para arquiteturas de software de SoS, (ii) ao suporte à avaliação, ainda em tempo de projeto, do comportamento que emerge da operação do SoS, (iii) à derivação automática de geradores de estímulos para entrega contínua de dados e manutenção da execução das simulações geradas, e (iv) à manutenção do alinhamento entre os modelos descritivos e prescritivos da arquitetura do SoS avaliado.

Conclusões: Conclui-se que as abordagens propostas avançam o estado da arte no projeto de arquiteturas de Software de SoS ao permitir prever, em tempo de projeto, como o SoS vai operar em tempo de execução, permitindo estabelecer estratégias para manter a simulação rodando, e sua operação contínua, mesmo com as mudanças arquiteturais inerentes ao seu funcionamento, provendo mais confiabilidade para os usuários futuramente dependerão de seus serviços.

Palavras-chave: Sistemas-de-sistemas, SoS, Arquitetura de Software, Engenharia Baseada em Modelos, Simulação.

R ÉSUM É

GRACIANO NETO, V. V. Une approche dirigée par les simulations et basée sur les modèles pour la conception des architectures logicielles des systèmesdes-systèmes à logiciels prépondérants. 2018. 217 p. Tese (Doutorado em Ciências -Ciências de Computação e Matemática Computacional) -Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Carlos -SP, 2018.

Contexte: Les systèmes à logiciels prépondérants sont de plus en plus intéropérables formant des alliances nommées: Systèmes-des-Systèmes (SdS). Les applications des SdS peuvent aller des systèmes de gestion du trafic jusqu'aux systèmes de gestion de crises. Étant donné que les SdS supportent souvent les domaines critiques, ils doivent être fiables en traitant les disfonctionnements ou les défauts et en évitant les défaillances qui pourraient causer des dégâts et pertes importantes aux utilisateurs.

Problème: Ajuster les opérations d'un SdS dépend d'une spécification précise et une attestation rigoureuse de sa consistance opérationnelle. Cependant, en plus des limitations des langages pour capturer conjointement la structure et le comportement des SdS, les prédictions de la consistance opérationnelle des SdS reposent sur leurs systèmes constitutifs qui ne sont pas totalement connus au moment de la conception. Par conséquent, les SdS ont été développés et déployés sans évaluation de leurs opérations, puisque les langages actuels ne supportent pas ce type de précision lors de l'évaluation.

Objectif: Ce projet de thèse fournit des solutions théoriques et pratiques basées sur un langage formel de description d'architectures pour supporter une évaluation précoce des opérations du SdS par rapport à la structure et le comportement du SdS à travers les simulations.

Contributions: Les contributions essentielles de ce projet comprennent (i) une approche de transformation des modèles pour produire automatiquement des modèles de simulation à partir des descriptions des architectures logicielles du SdS, combinant la description structurelle et comportementale du SdS dans la même solution, (ii) une méthode d'évaluation de l'architecture logicielle du SdS pour la prédiction des opérations du SdS tout en considérant les changements inhérents qui peuvent se produire, (iii) modélisation de l'environnement et génération automatique des générateurs de stimulus pour soutenir la simulation des SdS, livrant des données pour nourrir tel simulation, et (iv) une méthode pour la synchronisation automatique entre l'architecture descriptive d'exécution (qui change à l'exécution par suite de l'architecture dynamique) et son architecture prescriptive d'origine basée sur des mécanismes de découverte et de récupération de modèles et une transformation de modèle rétrograde.

Évaluation: Nous avons conduit des cas d'études pour évaluer nos approches en utilisant le SdS de surveillance des inondations et le SdS d'espace.

Résultats: Notre approche montre une précision importante pour (i) produire des simulations des architectures logicielles des SdS sans failles et complètement opérationnelles, (ii) supporte une évaluation et une prédiction fiable des opérations du SdS à la phase de conception, (iii) génère de manière automatique des générateurs de stimuli pour soutenir et nourrir l'exécution de la simulation et (iv) maintien la synchronisation entre les versions descriptives et prescriptives de l'architecture du SdS.

Conclusion:

Nous avons conclu que les approches proposées font évoluer l'état de l'art de l'évaluation des architectures logicielles des SdS en offrant des solutions pour prédire l'efficacité des opérations du SdS pour maintenir une opération continue malgré les changements architecturaux, fournissant plus de confidence aux utilisateurs qui reposent dans l'avenir sur les services du SdS. .

Mots

INTRODUCTION

Software has been increasingly embedded into mechanical, electrical, hydraulic, and pneumatic systems. Software supports them to offer a higher precision of their functionalities with automation of operation, which makes them smarter. Such systems have become software-intensive, i.e., software intensively contributes, influences, and impacts on their design, construction, deployment, and evolution (ISO, 2011;[START_REF] Goncalves | Towards a conceptual model for software-intensive system-of-systems[END_REF]. Our society has become highly dependent on services provided by software-intensive systems, and due to that, increasingly more complex solutions have been required. However, systems operating alone have not achieved them successfully, which has pressured them to interoperate, i.e., communicate, exchange data, and use the information exchanged to deliver results (HIMSS, 2013). In this perspective, a distinct class of systems, known as Software-Intensive Systems-of-Systems (SoS) 1 has emerged. A SoS comprises a number of operationally and managerially independent software-intensive constituent systems that work together to offer complex functionalities that could not be delivered by any one of them in isolation (MAIER, 1998;[START_REF] Jamshidi | System of systems engineering -new challenges for the 21st century[END_REF][START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF]INCOSE, 2016). Moreover, SoS are often designed to accomplish missions, i.e., high-level goals assigned to the entire SoS to be achieved through exploiting the set of functionalities delivered by the constituent systems [START_REF] Silva | On the characterization of missions of systems-of-systems[END_REF]. SoS are likely to form the next generation of software-intensive systems [START_REF] Jamshidi | System of systems engineering -new challenges for the 21st century[END_REF][START_REF] Boehm | A view of 20th and 21st century software engineering[END_REF] and often support missions in critical domains, such as smart traffic control and emergency and crisis response [START_REF] Road2sos | Road2SoS Project -Roadmaps for Systems-of-Systems Engineer[END_REF]. Important investments in SoS Engineering have been made; for instance, Saudi Arabia has invested 70 billion dollars in smarter cities and South Africa has conducted a 7.4 billion dollars smart city project [START_REF] Cerrudo | Keeping Smart Cities Smart: Preempting Emerging Cyber Attacks in U.S. Cities[END_REF]. Therefore, their correct operation is of paramount interest and the construction of reliable SoS must be 1 For sake of simplicity, the acronym SoS will be used herein to express both singular and plural. SoS share important dimensions (MAIER, 1998), such as: (i) managerial independence, i.e., constituents are owned and managed by distinct organizations and stakeholders; (ii) operational independence, since constituents also perform their own activities, even when they are not accomplishing one of the SoS' missions; (iii) distribution, i.e., their constituents are dispersed requiring connectivity to communicate; (iv) evolutionary development, since SoS evolve due to the evolution of their constituents parts; and (v) emergent behavior, which corresponds to complex functionalities that emerge from the interoperability among constituents. Constituents cooperate with their individual capabilities to deliver complex functionalities, some of them deliberately planned to be accomplished as emergent behaviors, which comprise a realization of the pre-established missions (DAHMANN; JR.; [START_REF] Dahmann | A software engineering perspective on environmental modeling framework design: The object modeling system[END_REF]INCOSE, 2016). Moreover, SoS can exhibit an opportunist nature, i.e., a system can become spontaneously available for joining other systems to form a SoS, and leave the SoS when the mission finishes. Remarkable examples include smart cities, smart grids, smart buildings, and all a plethora of smart-* systems (OQUENDO, 2016c;ICS-CERT, 2015;[START_REF] Fitzgerald | Model-based Engineering for Systems of Systems: the COMPASS Manifesto[END_REF].

Software-intensive SoS holds software architectures. Software architectures correspond to the fundamental structure of a software system, which comprises software elements, relations among them, and the rationale, properties, and principles governing their design and evolution (BASS; CLEMENTS; KAZMAN, 2012;ISO, 2011). A software-intensive architecture of a SoS is its fundamental structure, which includes its constituents and connections between them, their properties as well as those of the environment [START_REF] Nielsen | Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions[END_REF]. SoS software architectures are particularly highly dynamic, i.e., they continuously change in response to addition, substitution, and deletion of constituents. In SoS software architectures, an architectural configuration is the current state and organization of an arrangement of interoperable software-intensive systems at a given point of time, also known as coalition in SoS domain. A dynamic architecture can change its own structure at runtime, exhibiting several architectural configurations during its execution, whereas a dynamic reconfiguration is the ability of an architecture or simulation has to reconfigure its own structure at runtime. Therefore, a dynamic architecture incorporates dynamic reconfiguration support.

Single systems can be validated and verified in a satisfactory way using analytical methods and techniques. However, complex systems, a class of systems of which SoSs are part, require methods that support their proper validation and verification. Emergent behavior is a particular SoS characteristic triggered by the reception of stimuli and data exchanged between the constituents, and between them and their environment [START_REF] Graham | Nature's Patterns -Exploring Her Tangled Web[END_REF]. Such behaviors are an holistic phenomenon manifested through a certain number of interactions among the constituents that produce a global result that could not be delivered from any one of them in isolation (MAIER, 1998). Emergent behaviors comprise a scenario in which the whole possesses properties not possessed by their parts, so that if a whole is reduced to its parts in analysis the emergent properties are not discoverable by the analysis [START_REF] Oquendo | π-ADL: An Architecture Description Language Based on the Higher-order Typed π-calculus for Specifying Dynamic and Mobile Software Architectures[END_REF]. Examples of emergent behaviors include home security behavior, which could emerge from a set of individual systems installed in a smart home, and a traffic jam, which is the resultant behavior that several cars may raise together depending on the traffic network and conditions, which is not predictable by knowing only the behavior of cars. Another example is the so-called phantom traffic jams, where fast-moving traffic suddenly congeals into a slow-moving jam for no apparent reason [START_REF] Oquendo | π-ADL: An Architecture Description Language Based on the Higher-order Typed π-calculus for Specifying Dynamic and Mobile Software Architectures[END_REF].

Emergence is deliberately and intentionally planned and designed for SoS (BOARD-MAN;SAUSER, 2006), i.e., the SoS engineer is the major player for creatively exploring the functionalities delivered by the constituents, assembling them for innovative purposes. Hence, guaranteeing that SoS are going to exhibit an expected set of behaviors highly depend on predicting how constituents interoperate at runtime. As the level of uncertainties and variables increases due to the number of constituents involved, analytic solutions for SoS evaluation demand a dynamic view, i.e., a model that captures the SoS behavior and enables its evaluation at design-time. SoS must be analyzed under a multitude of perspectives, and the views can be distinguished into two families (CARLE et al., 2012): static views, focusing on systems properties, and dynamic views, focusing on the representation of the software architecture behavior. As SoS exhibit emergent behaviors, dynamic views are especially interesting. Simulations allow to observe, at design-time, the behaviors (intended or not) that emerge at runtime, allowing SoS engineers to verify and validate them.

Emergent behaviors can be classified under two perspectives (MITTAL; [START_REF] Mittal | Harnessing Emergence: The Control and Design of Emergent Behavior in System of Systems Engineering[END_REF]: Intention and Type. An emergent behavior can be Predicted or Unpredicted [START_REF] Chalmers | Strong and weak emergence[END_REF]. Predicted emergent behavior consists of behaviors intentionally designed to emerge at runtime, whilst unpredicted emergent behavior corresponds to that one that emerges as a co-lateral effect of specific conditions or runtime configurations, with the potential to cause losses to the SoS operation. Considering the type, four categories exist (MITTAL; RAINEY, 2015): Simple, predicted, strong, and spooky. Simple emergent behaviors are emergent properties readily predicted by simplified models of the SoS. They are produced in lower complexity through models that abstract the SoS (only intentional predicted behaviors emerge since the model is overly simple). Predicted emergent behaviors are those readily and consistently reproducible in simulations of the system, but not in static models. They are partially predicted in advance (desired behaviors are predicted, Chapter 1. Introduction but undesired can also appear). Strong emergent behaviors are consistent with SoS known properties, but are not reproducible in any model of the system. Direct simulations may reproduce the behavior, but inconsistently, and simulations do not predict where the property will occur (desired behaviors exist, but unpredicted behaviors are the majority). Finally, spooky emergent behaviors are inconsistent with known properties of the SoS, not reproducible or subject to simulation, such as life itself, not predicted. For the scope of this thesis, we deal with the predicted ones.

Problem Statement and Justification for the Research

Single systems can cause serious damage while operating alone. When they are combined to work together, the possibilities of failures dramatically increase. Hence, due to dynamic properties as emergent behaviors and dynamic architectures, and to the high complexity that can be faced in regards to the amount and variety of different systems involved into the SoS operation, SoS also exhibits a high degree of uncertainty. As SoS aim at supporting critical domains, risks of damages, financial losses, and threats to human lives may arise. Therefore, SoS must be constructed to be trustworthy, i.e., their operation should be reliable for users that trust on their services to correctly operate, work as expected, and keep operations in progress, with no failure or accidents (NAMI; SURYN, 2013;[START_REF] Steinhogl | Trustworthy systems of systems -a prerequisite for the digitalization of industry[END_REF][START_REF] Oquendo | π-ADL: An Architecture Description Language Based on the Higher-order Typed π-calculus for Specifying Dynamic and Mobile Software Architectures[END_REF][START_REF] Oquendo | Formal Architecture Description of Trustworthy Systemsof-Systems with SosADL[END_REF]GRACIANO NETO;[START_REF] Oquendo | π-ADL: An Architecture Description Language Based on the Higher-order Typed π-calculus for Specifying Dynamic and Mobile Software Architectures[END_REF]NAKAGAWA, 2016). Hence, trust influences the degree at which users will rely on the services provided by a SoS [START_REF] Mohammadi | Trustworthiness attributes and metrics for engineering trusted internet-based software systems[END_REF].

Problem I. Lack of notations that encompass representation of static and dynamic aspects of SoS software architectures.

For the avoidance of rework and delays in the SoS development project, evaluation activities must start early in the development process. Requirements models, such as UML sequence models, textual requirements, use case diagrams, SysML block diagrams (KASSAB; NEILL; LAPLANTE, 2014), or architecture models (one of the 4+1 viewsdevelopment view, logical view, physical view, process view, and scenarios [START_REF] Kruchten | The 4+1 view model of architecture[END_REF] could be used for evaluation purposes. However, requirement models are often not rich enough in details to provide support for SoS evaluation. In turn, architectural models (i) inherently hold the SoS structure, including constituent elements, their relation, dynamics, and non-functional requirements description, (ii) enable SoS specification for verification and validation (V&V), and evaluation purposes, and (iii) are richer in details than requirement models, which can be incomplete, imprecise, and rudimentary to support a reliable evaluation process. Problem II. SoS are critical and their software architectures should be specified and designed using an approach that supports the prediction of their behaviors.

Architectural evaluation enhances quality attributes, including those related to trustworthiness, and minimizes faults and failures that affect software quality [START_REF] Balci | Principles of simulation model validation, verification, and testing[END_REF]LEMOS;[START_REF] Lemos | ICSE 2002 workshop on architecting dependable systems[END_REF][START_REF] Lemos | ICSE 2002 workshop on architecting dependable systems[END_REF][START_REF] Nami | Software trustworthiness: Past, present and future[END_REF]SURYN, 2013). Therefore, the support of evaluation activities in SoS guarantees the software governing the SoS operation yields the expected results (MICHAEL;[START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF]. In particular, SoS evaluation demands an association between static and dynamic views and automation for detecting as many potential failures as possible. Manual approaches for evaluation are often unfruitful, as they deal only with static aspects and small-scale samples. Architectural models can be adopted due to the level of details they exhibit and dynamic models, as simulations, can be employed to anticipate failure, and exhibit the SoS behavior prior to its deployment.

However, SoS impose barriers on evaluation activities, as they exhibit dynamic properties, as emergent behaviors and dynamic architectures. Emergent behaviors comprise a holistic phenomenon that occurs at runtime as a consequence of interoperability of constituents and is explicitly planned (or not) by SoS engineers as a form of exploiting constituents' capabilities (MAIER, 1998;[START_REF] Nielsen | Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions[END_REF][START_REF] Graham | Nature's Patterns -Exploring Her Tangled Web[END_REF]FITZGERALD;LARSEN;[START_REF] Fitzgerald | Foundations for model-based engineering of systems of systems[END_REF]WACHHOLDER;STARY, 2015;MIT-TAL;[START_REF] Mittal | Harnessing Emergence: The Control and Design of Emergent Behavior in System of Systems Engineering[END_REF]. Dynamic architectures regard the ability of SoS to self-adapt their own architecture at runtime, i.e., join new constituents, rearrange their own structure, and substitute or eliminate constituents, which are recurrent activities during their normal operation. Such characteristics cannot be totally validated through the adoption of static specification, demanding non-static specifications that externalize the SoS dynamics and enables its visualization (MICHAEL;[START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Dobrica | A survey on software architecture analysis methods[END_REF][START_REF] Dobrica | A survey on software architecture analysis methods[END_REF][START_REF] Michael | Verification and validation for trustworthy software systems[END_REF].

Problem III. An evaluation method for SoS software architectures should adopt descriptions that combine static and dynamic view to precisely capture their structure and behavior, enabling the observation of the impact of dynamic architecture on the functionalities being provided.

Architectural evaluation activities demand some type of specification and SoS engineering requires strategies and means for dealing with the inherent dynamics, complexity, and often large dimensions of SoS. Model-Based Software Engineering (MBSE) has been recommended as a response to those demands, as it comprises a software development approach that prescribes models to capture knowledge acquired from the domain, supporting the specification required for evaluation purposes (RAMOS; FERREIRA; [START_REF] Ramos | Model-based Systems Engineering: An Emerging Approach for Modern systems[END_REF]RAMOS;FERREIRA;[START_REF] Ramos | Lithe: An agile methodology for humancentric model-based systems engineering[END_REF]INCOSE, 2016). MBSE also prescribes model transformations for automating the generation of software code from abstract models, taming complexity and enabling the processing of SoS properties for specification, evaluation, verification, and validation purposes [START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF]FALKNER et al., 2016). Moreover, MBSE can also make models executable, i.e., they support the management of dynamic aspects visualized at runtime. Currently, we could mention four major categories of techniques for evaluating software architectures (DOBRICA; [START_REF] Dobrica | A survey on software architecture analysis methods[END_REF]MICHAEL;[START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF]ABRAHAO;[START_REF] Abrahao | Evaluating software architecture evaluation methods: An internal replication[END_REF]: scenario-based, simulation-based, mathematical/logicalbased, and experience-/metric-based. Since SoS architectures demand a dynamic approach, simulation-based approach matches such requirements. Nonetheless, despite the architectural description languages (ADL) support for evaluating software architectures, known ADL have not supported evaluation of both static and dynamic properties in a same approach, in particular including the entire set of requirements imposed by SoS, as emergent behaviors, dynamic architectures, complexity, and a large variety and amount of systems [START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF].

Problem IV. Inconsistent operational states in a SoS can lead to malfunction, disasters, and losses. Representation of the surrounding environment of a SoS should then involve representation of potentially unpredicted conditions and continuous variables related to the environment where it will be deployed.

As we selected simulations as the dynamic view for SoS architectural specifications, other problems arise. Another source of uncertainty of SoS is its surrounding environment. Even using a simulation to predict behavior of SoS and its constituents, and how they achieve missions, the behavior of a SoS in real world is dramatically influenced by its surrounding environment. Architectural specifications often hold details about the intended environment of a systems, documenting how this influences the system results. However, many languages used to describe software architectures have not tackled environment representation. Moreover, when dealing with simulations, it is important to support it with data that represent the environment, and continuously delivering it during its execution. Problem V. New architectural arrangements that arise at runtime due to dynamic architecture can potentially originate harmful inconsistencies between SoS architectural description and SoS architecture at runtime, which should be prevented.

Finally, as SoS progresses with its operation, constituents can join it, leave it, or the entire architectural arrangement can be organized to better fit a set of requirements. As such, an increasing inconsistency between the initial architectural specification and the runtime 1.2. Scientific Methodology version of such SoS can take place. These inconsistencies, which characterize architectural drift, can cause a phenomenon called architectural erosion. For software architectures of single software systems, architectural erosion is known to have a negative impact on the quality of software systems, such as for maintainability, evolvability, performance, and reliability [START_REF] Gurgel | Blending and reusing rules for architectural degradation prevention[END_REF][START_REF] Terra | Recommending refactorings to reverse software architecture erosion[END_REF], potentially interrupting the operation of the system. Tailored mechanisms have been established for the identification and prevention of architectural erosion as well as for attaining architectural consistency. However, architectural erosion of SoS software architectures has not been properly addressed by any existing mechanism (SILVA; BALASUBRAMANIAM, 2012).

Scientific Methodology

This thesis was conducted as scientific research project. As such, a methodology was followed according to well-defined steps, as depicted in Figure 1, which involved: Step 0. Research question elaboration. At the first moment, a research question motivated the conduction of this PhD research: How can we evaluate SoS software architectures at design-time? Once such question was raised, the scientific research itself was started. SoS are often huge and complex, involving several constituents with many restrictions, policies, and business rules. Moreover, SoS are often built for critical domains, and they must be reliable. At this direction, evaluation activities could be considered essential, as they can reduce potential errors, failures, and misunderstandings at specification and design levels. Evaluation demand some sort of specification. Hence, models could solve this need, which led us to consider the research hypothesis;

Step 1. Elaboration of hypothesis. In light of all the identified and aforementioned requirements, the hypothesis established was a model-based (MB) approach can support architectural evaluation activities for software-intensive SoS at design-time. Models (i) capture the domain expertise acquired during the software development, and (ii) support automated evaluation. Moreover, models leverage abstraction, i.e., unnecessary details are excluded, and the attention can be focused on specific facets Chapter 1. Introduction of the problem. Besides, MB approaches bring automation about code generation, potential for simulation (and a consequent anticipation of problems before coding and deploying the product), and potential of reuse;

Step 2. Literature review and gaps identification. Literature was reviewed to identify the gaps about specification and evaluation of SoS software architecture models, and to elicit existent mechanisms, methods, models, and approaches in the state of the art about MB approaches for SoS. Results were published in a workshop paper [START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF]. During the review, we identified that the application of MB methods in SoS engineering were still embryonic and could be further exploited [START_REF] Steinhogl | Trustworthy systems of systems -a prerequisite for the digitalization of industry[END_REF]. Later, we identified that MB approaches are a common systems engineering practice [START_REF] Nielsen | Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions[END_REF], and were adopted for several studies (around 59.38% of included studies in a systematic mapping) for managing systems complexity by enabling engineers to better understand requirements, develop candidate architectures, and verify design decisions early in the development process [START_REF] Lana | Systems-of-systems development: Initiatives, trends, and challenges[END_REF];

Step 3. Solution proposal and implementation. Considering the results of our literature review, we decided to adopt a model transformation to harmonize formalisms that could support both the precise specification of SoS software architectures and the execution of such models. SoSADL and DEVS were selected from the state of the art. We associated them by means of a model transformation (SoSADL2DEVS). We relied on such model transformation to build other advances, namely (i) an automatic generation of a mechanism for dynamic reconfiguration control, (ii) the externalization of patterns to automatically generate constituents behaviors with no conflicting rules (for simulation purposes), (iii) automatic generation of stimuli generators to feed the simulation and sustain its execution, preventing the need of a human interaction during the study conduction, and (iv) the elaboration of an evaluation method on such transformation. Moreover, we also identified the emergence of architectural erosion due to dynamic architecture, also proposing a solution for reconciliation between the runtime architecture and the intended one, as further explained later.

Step 4. Empirical studies conduction for solution evaluation. Once solutions were proposed and implemented, we evaluated them according to rigorous scientific protocols. Experiments were not feasible, as such studies require another technique to compare the results with. We did not find directly related solutions. Hence, we opted for an exploratory but relevant empirical method, namely case studies (RUNESON; [START_REF] Runeson | Guidelines for conducting and reporting case study research in software engineering[END_REF], as our empirical source of evidence; 1.3. Research Questions,and Objectives Step 5. Results communication, confirmation of refutation of hypothesis.

Once all the proposed approaches were evaluated, we confirmed our hypothesis that claim a model-based (MB) approach can support architectural evaluation activities for software-intensive SoS at design-time. Results were communicated through reporting and scientific publications.

Next section detail the research questions, and solution drawn as a result of the conduction of the aforementioned research methodology.

Research Questions, and Objectives

We claim an MB approach can aid this endeavor as it: (i) fosters the creation and adoption of software specifications expressed as models, (ii) relies on those models to automatize architectural evaluation activities through simulations, (iii) predicts the SoS behavior and dynamics under environmental conditions, and (iv) reduces uncertainty by predicting runtime conditions.

The following research questions were derived from the main research question: RQ1: How can the evaluation of SoS architectures be supported? Rationale: Considering the aforementioned difficulties, a novel evaluation approach must be established to support evaluation of SoS architectures. Such approach must combine dynamic and static characteristics of SoS, covering representation of structure and behavior.

RQ2: How can SoS dynamic behaviors be anticipated and predicted at design-time? Rationale: SoS development suffers from challenges imposed by the inherent uncertainty related to its operation. Hence, a novel approach must predict, at design-time, how changes in the SoS architecture impact on the behaviors designed to be accomplished, and anticipate how changes must be performed to reactivate SoS operation in cases that an architectural change cause malfunction.

RQ3: How can SoS architectural description be continually consistent with its runtime configuration, despite its inherent dynamic architecture? Rationale: As SoS progresses its operation, dynamic architecture results in different architectural configurations. New configurations can cause a lack of conformance with the original SoS architectural specification, what can cause mismatches between the implemented SoS in execution and the planned one. Hence, it is prominent to establish some mechanism to keep its documentation continually synchronized with its current RQ4: How can the surrounding environment be modelled for a SoS simulation purpose? Rationale: SoS are developed to be deployed in a highly dynamic environment that must be modeled for the prediction of situations to which they will be subjected.

The following solutions were defined in this thesis:

1. Automatic generation of simulation models for SoS : we aimed at establishing a model-based transformation approach to combine dynamic and static descriptions of a SoS software architecture in a unique approach. We decided to describe SoS software architectures with the use of SosADL models and automatically transforming them into simulation models documented in Discrete Event System Specification (DEVS), a formalism for systems simulation;

2. Modeling of a SoS surrounding environment and automatic generation of stimuli generators that support SoS simulation: the surrounding environment is an important concern for SoS, as it directly impacts on the way they perform their activities. We aimed at modeling the environment at a certain abstraction level and automatically creating a structure that continuously produces stimuli for SoS simulation, anticipating possible failures, imitating the environment, and reducing costs of an early and inadvisable SoS deployment;

3. Evaluation of SoS software architectures through simulations: we aimed at considering a established and well-defined method to support evaluation of SoS architectural descriptions in regards to the functionalities it should offer, despite the dynamics of its architecture. SoS architectures could then be analyzed at runtime based on the simulations produced by our transformation approach; and 4. A platform to support SoS architectural evaluation by means of simulation: one of the contributions is the development of a platform that advances the state of the practice by supporting SoS architectural evaluation activities through SoS architectural simulation and evaluation;

5. Automatic restoration of software architectural models: an approach should be established to support analyzing the emerging architectural configurations. After the selection the best architectural configuration that matched the quality attributes expected for a trustworthy SoS, the architectural model can be updated according to that configuration, to proceed with SoS development.

Summary of Contributions

The next section addresses the contributions of the thesis in accordance with the proposed objectives.

Summary of Contributions

This PhD thesis reports results of the establishment of approaches to deal with the highlighted gaps. 1. ASAS, an evaluation approach for SoS software architectures based on simulations -we consider a pre-defined set of metrics associated with quality attributes related to trustworthiness ((i) correctness, (ii) configuration quality, (iii) dependability, and (iv) performance

Thesis Outline

This chapter presented an overview of the context in which this research is settled, the problems that exist and that must be overcome, and the contributions that this thesis offer considering the highlighted gaps. The remaining chapters of this thesis are organized as follows.

Chapter 2 addresses the state of the art of MBSE for SoS, an overview of the foundations on which this thesis has been built, terminology and key concepts and results of the systematic literature review conducted. The results published in [START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF] were updated to be included in the thesis.

Chapter 3 describes ASAS approach, which is the core of our proposal. ASAS is based on a model transformation from SoS architectural models to simulation models. SoS models were specified using SoSADL, whilst simulation models used DEVS. The chapter also presents an approach for the automatic generation of SoS simulation with support to dynamic reconfigurations at runtime. Results were reported in (GRACIANO NETO, 2016;GRACIANO NETO et al., 2018b;GRACIANO NETO et al., 2018c) and the content was extended to the thesis body and submitted to a journal (GRACIANO NETO et al., 2018a).

Chapter 4 presents Back-SoS, an approach to prevent architectural drift in SoS architectures, and reconcile the runtime architectural arrangement with the SoS software architectural description. Results were published in (GRACIANO NETO et al., 2018a) and submitted to a journal (GRACIANO NETO et al., 2018b).

Chapter 5 presents Stimuli-SoS, an approach that automatically produces structures known as stimuli generators, which are virtual entities deployed in a simulation for imitating the surrounding environment. Results were published in (GRACIANO NETO et al., 2016;GRACIANO NETO et al., 2017).

Finally, Chapter 6 concludes the thesis, revisiting contributions, summarizing limitations, and presenting perspectives for future research.

CHAPTER

2

STATE OF THE ART ON MODEL-BASED SOFTWARE ENGINEERING FOR SYSTEMS-OF-SYSTEMS

Model-Based Software Engineering (MBSE) has been applied to SoS development. Models comprise a resource to tame complexity, leveraging the abstraction of software production, and documenting the design decisions in a computer-based format that allows to process it and even automatically generate software code. This chapter covers the state of the art about how model-based approaches have been exploited in SoS domain. Section 2.1 briefly presents foundations about model-based approaches. Section 2.2 presents a review on the state of the art on MBSE approaches for SoS. Section 2.3 concludes the chapter.

Foundations on MBSE and SoS

A model is a selective, reduced, and accurate representation of a system that concisely captures all the essential properties for a given set of concerns [START_REF] Selic | The pragmatics of model-driven development[END_REF]. Such model is, essentially, a machine-readable abstraction of the reality represented using a given language (textual or visual). Examples of languages used to represent models in MBSE approaches include UML [START_REF] Omg | Meta Object Facility (MOF) Core Specification Version 2.0. Object Management Group[END_REF], SySML [START_REF] Omg | The OMG Systems Modeling Language (SySML) Version 1.5[END_REF], and π-ADL [START_REF] Oquendo | π-ADL: An Architecture Description Language Based on the Higher-order Typed π-calculus for Specifying Dynamic and Mobile Software Architectures[END_REF]. These models are often driven by a more abstract concept that restricts how a model can be built. These abstract models are known as metamodels. Metamodels encapsulate the lexicon (the canonical constructs of a language) and the syntactic rules (the relations between the elements) that are allowed in the construction of a certain type of model. Models necessarily need to conform to their respective metamodels [START_REF] Canovas | An architecture-driven modernization tool for calculating metrics[END_REF][START_REF] Canovas | An architecture-driven modernization tool for calculating metrics[END_REF]CICCHETTI et al., 2008), and this is analyzed during a validation of a model against its metamodel. After the model is validated, a transformation can be performed. Models are part of the state of the practice in software development. They capture the expertise acquired to realize complex problems and potential solutions through the use of abstraction [START_REF] Selic | The pragmatics of model-driven development[END_REF], being successively transformed along the software development process until reaching software code. In short, requirements are input for architectural design; architectural design is refined to a detailed design; and the detailed design culminates in software code properly. Then, the software development process can be considered a difficult, expensive, and error-prone (OPHEL; OPHEL, 1993) manual succession of model transformations.

Along decades of software engineering, some portions of the aforementioned model transformations were automated through the use of model transformers, as a result of emergence of Model-Driven Architecture (MDA) specification by OMG (MILLER; [START_REF] Miller | [END_REF]. Model transformers are model compilers that receive models and their respective metamodels as input and, through the use of model transformations, transform source models in target models. Target models can be graphical or textual (code). As models are described by metamodels, metamodels are described by metametamodels, and metametamodels describes themselves. The OMG standard metametamodel is the Meta Object Facility Language (MOF) [START_REF] Omg | Meta Object Facility (MOF) Core Specification Version 2.0. Object Management Group[END_REF]. Another metametamodel is Ecore 1 , an Eclipse standard used for implementations in Eclipse Modelling Framework (EMF) (KLEPPE; WARMER; [START_REF] Kleppe | MDA Explained: The Model Driven Architecture: Practice and Promise[END_REF].

Transformations are mappings between a source metamodel and a target metamodel, according to a transformation definition [START_REF] Levendovszky | Model reuse with metamodel-based transformations[END_REF]. A transformation definition is a set of transformation rules that describe how a model in a language can be transformed into another model [START_REF] Mens | Applying a model transformation taxonomy to graph transformation technology[END_REF]GORP, 2006). Such rules establish a traceability relation between source and target models, linking their language constructs through a mapping between those elements.

Model transformations are classified in three categories (MENS; GORP, 2006): Model-to-Model (M2M), Model-to-Text (M2T), and Text-to-Text (T2T). The first type encompasses the situation where the input of a model transformation is a model (as a diagram) and the output is a model as well (for instance, textual requirements to architectural models). Target and source models in a M2M transformation can also conform to the same metamodel, which is known as a endogenous transformation. Second type consists of a model transformation where the input is a model and output is a textual 1 http://eclipse.org/ecoretools/ artifact (as HTML pages, software code, or scripts). And the last consists of transformation from a textual model to another textual model (as XML for PostgreSQL). Transformations may be unidirectional or bidirectional. Unidirectional transformations can be executed in one direction only, for example when a target model is computed (or updated) based on a source model. A transformation from a source model to a target model is termed as forward transformation, whilst a transformation from a given target model back to a source model is known as backward transformation. Bidirectional transformations can be executed in both directions, which is useful in the context of synchronization between models and code (CZARNECKI;[START_REF] Czarnecki | Sysml executable systems of system architecture definition: A working example[END_REF][START_REF] Stevens | A landscape of bidirectional model transformations[END_REF][START_REF] Czarnecki | Bidirectional transformations: A cross-discipline perspective[END_REF][START_REF] Stevens | A landscape of bidirectional model transformations[END_REF]ZAN;[START_REF] Zan | Writing bidirectional model transformations as intentional updates[END_REF]HU, 2014). Bidirectional transformations can be achieved using bidirectional rules or by defining two separate complementary unidirectional rules, one for each direction. Most of the approaches do not provide bidirectionality (CZARNECKI;[START_REF] Czarnecki | Sysml executable systems of system architecture definition: A working example[END_REF].

M2M transformations usually use graph patterns [START_REF] Lara | Formal support for model driven development with graph transformation techniques[END_REF][START_REF] Lara | Formal support for model driven development with graph transformation techniques[END_REF][START_REF] Mens | Applying a model transformation taxonomy to graph transformation technology[END_REF]SCHURR;[START_REF] Schurr | Applications of Graph Transformations with Industrial Relevance[END_REF][START_REF] Schurr | Applications of Graph Transformations with Industrial Relevance[END_REF][START_REF] Greenyer | Applying advanced tgg concepts for a complex transformation of sequence diagram specifications to timed game automata[END_REF][START_REF] Greenyer | Applying advanced tgg concepts for a complex transformation of sequence diagram specifications to timed game automata[END_REF]. M2M transformations translate between source and target models, which can be instances of the same or different metamodels (CZARNECKI;[START_REF] Czarnecki | Sysml executable systems of system architecture definition: A working example[END_REF]. In this approach, a model is considered as a graph, with nodes (as classes) and edges (as the relations among classes), and a transformation is essentially performed as a graph transformation, when manipulations are performed to transform nodes in other nodes, merge nodes, separate nodes, creating and removing edges. Other approaches are direct-manipulation, relational, structuredriven, and hybrid approaches (CZARNECKI;[START_REF] Czarnecki | Sysml executable systems of system architecture definition: A working example[END_REF]. M2T (or Model-to-code (M2C)) category is distinguished between visitor-based and template-based approaches (CZARNECKI;[START_REF] Czarnecki | Sysml executable systems of system architecture definition: A working example[END_REF]. In former, a very basic code generation approach consists of providing some visitor mechanism to traverse the internal representation of a model and write code to a text stream to generate code. In latter, a template of a program in the target technology is filled with code transformed from a source model.

MBSE for SoS

SoS is challenging, as they are highly dynamic, assembled by constituents often developed with COTS (Commercial Off-The-Shelf), engineered in all sort of heterogeneities comprising distinct operational systems, communication mechanisms, programming languages, and middleware technologies [START_REF] Gokhale | Model driven middleware: A new paradigm for developing distributed real-time and embedded systems[END_REF]. Efforts have been performed to establish strategies, techniques, and methods to deal with the classic concerns of software engineering regarding software-intensive SoS [START_REF] France | Model-driven development of complex software: A research roadmap[END_REF][START_REF] France | Model-driven development of complex software: A research roadmap[END_REF][START_REF] Calinescu | Software engineering techniques for the development of systems of systems[END_REF][START_REF] Calinescu | Software engineering techniques for the development of systems of systems[END_REF], as SoS impose complexity, namely:

Combining constituents, allowing them to interoperate, requires working on COTS with which they are usually engineered. Indeed, SoS require configuring middleware support to enable constituents communication, abstracting inherent heterogeneities regarding external data representation, operating systems, programming languages, network patterns, and communication mechanisms [START_REF] Bay | Recent advances in the design of distributed embedded systems[END_REF][START_REF] Gokhale | Model driven middleware: A new paradigm for developing distributed real-time and embedded systems[END_REF]BALASUBRAMANIAN et al., 2009;[START_REF] Farcas | Addressing the integration challenge for avionics and automotive systems -from components to rich services[END_REF][START_REF] Kazman | Understanding patterns for system of systems integration[END_REF]; Managing constituent systems requires controlling their presence in the SoS, taking into account their intrinsic dynamics and volatility in a running SoS [START_REF] Bryans | Semi-formal and formal interface specification for system of systems architecture[END_REF][START_REF] Batista | Challenges for sos architecture description[END_REF];

Configuring and deploying SoS usually relies on manually creating and handling large text files. This is necessary to ensure a suitable and correct configuration and deployment. However, this is a laborious and error-prone task, since those files have huge dimensions and high complexity [START_REF] Barbi | A model-driven approach for configuring and deploying systems of systems[END_REF];

Ensuring that the software generated for SoS faithfully corresponds to models used to specify them is currently a manual process. There is a lack of specialized tools to address SoS complexities, and a low consensus due to diversity of models and languages for SoS modeling [START_REF] Farcas | Addressing the integration challenge for avionics and automotive systems -from components to rich services[END_REF]; Assuring, in the opposite side, that software of SoS keeps synchronized with models used to generate it [START_REF] Farcas | Addressing the integration challenge for avionics and automotive systems -from components to rich services[END_REF]; and

Constituents must also perform their functions independently, not only exclusively to accomplish a mission of the whole SoS. This requires that code of independent work and mission need to co-exist in a same software entity, claiming for an adequate and modularized architecture (MAIER, 1998).

At this direction, MBSE has received attention to solve some of the aforementioned problems, specially in SoS domain [START_REF] France | Model-driven development of complex software: A research roadmap[END_REF][START_REF] France | Model-driven development of complex software: A research roadmap[END_REF][START_REF] Farcas | Addressing the integration challenge for avionics and automotive systems -from components to rich services[END_REF][START_REF] Fischer | Overcoming the Generation Gap in aircraft designs with executable specifications[END_REF][START_REF] Fischer | Overcoming the Generation Gap in aircraft designs with executable specifications[END_REF][START_REF] Barbi | A model-driven approach for configuring and deploying systems of systems[END_REF]MITTAL;[START_REF] Mittal | Model-driven systems engineering for netcentric system of systems with DEVS unified process[END_REF]. MBSE considers models as the primary artifacts of software development and has achieved prestige by gains in time-to-market, reducing effort and cost, and increasing productivity, traceability, and software quality (SENDALL; [START_REF] Sendall | Model transformation: The heart and soul of modeldriven software development[END_REF][START_REF] Selic | The pragmatics of model-driven development[END_REF]. Besides, automation in the generation of software code adds value to the production of software, promoting traceability between models and code. As knowledge is registered in abstract models and model transformations, MBSE also potentially fosters reuse.

Domain-Specific Modeling Languages for Systems-of-Systems

Adoption of MBSE requires the use of models and domain-specific languages (DSL). Such DSL comprise a computer language specialized to a particular application domain. In regards to SoS, an specific type of DSL is often used termed as ADL. As SoS must be trustworthy, they must be carefully evaluated about their functional and non-functional properties. Hence, a enough detailed model is required for such evaluation activities. For this context, architectural models are the best option, since they inherently hold the SoS structure (constituent elements, their relation, and dynamics), which are important elements for validation and verification. Besides, architectural elements are potentially executable, which can support validation of dynamic properties. Moreover, architectural models are richer in details than requirement models, which can be too incomplete, imprecise, rudimentary to support a reliable V&V process. Hence, in this section we broadly discuss ADL and other languages for SoS architecture specification.

MBE or MBSE has been adopted in several studies situations [START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF][START_REF] Nielsen | Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions[END_REF][START_REF] Lana | Systems-of-systems development: Initiatives, trends, and challenges[END_REF]. Literature reviews have reported a systematic use of MBSE in SoS development. Lana et al. report that around 59.38% (19 out of 32 included studies from 1994Lana et al. report that around 59.38% (19 out of 32 included studies from too 2015) ) of included studies in a systematic mapping use MBSE principles for managing systems complexity by enabling engineers to better understand requirements, develop candidate architectures, and verify design decisions early in the development process [START_REF] Lana | Systems-of-systems development: Initiatives, trends, and challenges[END_REF]. Nielsen et. al also discuss an overview of MBSE techniques to SoS. Nevertheless, MBSE has also been recognized as a challenge for SoS engineering. Methods and supporting tools need to be adapted and evolved to support SoS. Diverse approaches involving models and model transformations have been reported in literature [START_REF] Bryans | Semi-formal and formal interface specification for system of systems architecture[END_REF]MITTAL;[START_REF] Mittal | Model-driven systems engineering for netcentric system of systems with DEVS unified process[END_REF]RAMOS;FERREIRA;[START_REF] Ramos | Model-based Systems Engineering: An Emerging Approach for Modern systems[END_REF][START_REF] Lewis | A testing framework for devs formalism implementations[END_REF]SMITH;[START_REF] Lewis | A testing framework for devs formalism implementations[END_REF][START_REF] Barbi | A model-driven approach for configuring and deploying systems of systems[END_REF][START_REF] Tu | Harmonized and reversible development framework for HLA based interoperable application[END_REF][START_REF] Tu | Harmonized and reversible development framework for HLA based interoperable application[END_REF][START_REF] Tu | Harmonized and reversible development framework for HLA based interoperable application[END_REF][START_REF] Neema | Model based integration and experimentation of Information Fusion and C2 Systems[END_REF][START_REF] Gokhale | Model driven middleware: A new paradigm for developing distributed real-time and embedded systems[END_REF][START_REF] Lang | Model driven security accreditation (MDSA) for agile, interconnected it landscapes[END_REF][START_REF] Lang | Model driven security accreditation (MDSA) for agile, interconnected it landscapes[END_REF]. Figure 3 visually summarizes the most common formalisms that have been adopted in the last years in literature. Arrows indicate model transformations directions, illustrating sources and targets used in each considered study. The most relevant aspects to be analyzed in studies that adopt MBSE for SoS development are (i) languages, models, metamodels, and purposes/concerns represented in those models during model-based software development for SoS (requirements, architecture, testing); and (ii) types of transformation executed (M2M, M2T, T2T), and whether they are unidirectional (forward or backward) or bidirectional; and (iv) the tools adopted, if they are customized and/or commercial, and which models play the role of source and target models in those transformations. Hence, our discussion is made on top of these parameters.

Many models and languages have been used or suggested to represent SoS. We discuss, as follows, which models have been used to describe SoS and what they have documented.

Missions in SoS

SoS are concerned with the fulfillment of missions, i.e., a set of goals to be accomplished by (i) performing tasks based on capabilities (functionalities) of constituent systems, and (ii) interactions among constituent systems leading to emergent behaviors. Individual missions are realized by constituent systems themselves whereas global missions of an SoS are accomplished through emergent behaviors [START_REF] Silva | On the characterization of missions of systems-of-systems[END_REF]SILVA;[START_REF] Batista | Challenges for sos architecture description[END_REF]CAVALCANTE, 2015;[START_REF] Silva | Bridging missions and architecture in software-intensive systems-of-systems[END_REF]SILVA;CAVALCANTE;[START_REF] Silva | Refining missions to architectures in softwareintensive systems-of-systems[END_REF]. [START_REF] Silva | On the characterization of missions of systems-of-systems[END_REF] have reviewed the literature to collect studies investigating how to deal with mission specification for SoS. After analyzing 12 studies with initiatives in this direction, they have elaborated a conceptual model of missions for SoS. They have proposed mKAOS, an extension of KAOS methodology [START_REF] Lamsweerde | Goal-oriented requirements engineering: A guided tour[END_REF] to model missions (SILVA; BATISTA; CAVALCANTE, 2015) in a goal-oriented notation. mKAOS encompasses six different models that allow specifying missions of SoS and defining relationships between these missions and other aspects of the SoS (such as emergent behavior and capabilities of the constituent systems), regardless of implementation details.

Lorenzo Alvarez et al. also progress on missions specification for SoS using a MBSE approach [START_REF] Alvarez | Model-based system engineering approach for the Euclid mission to manage scientific and technical complexity[END_REF]. They adopt SySML to model scientific space missions involving many constituents of a SoS in European Space Agency. They use ESAAF (European Space Agency Architectural Framework), which consists of a prescriptive modeling methodology based on a set of architectural views to guide System-of-systems (SoS) design and integration. ESAAF is based on the well-known architectural frameworks, such as DoDAF (USA Dept of Defense AF), MoDAF (UK Ministry of Defence AF), TOGAF (Open Group AF) and Zachman Framework. Their model is organized in the following views: (i) Requirements view: Modeling of Euclid requirements, including traceability, budgeting, justification and change control; (ii) Architecture view: Modeling of architecture and structure of the Euclid system, including interaction and interconnection between elements, characteristics, models; (iii) Verification view: Modeling of system verification logic, including activities, levels and flows; and (iv) Lifecycle view: Modeling of operational and data flows for the Euclid system, including operational timelines, data transmission and communication flows. They adopt Enterprise Architect to support mission modeling through SySML notation.

Software Architecture for SoS

Software-intensive SoS exhibit a software architecture, which comprise the fundamental structure of a software system, its software elements, relations among them, and the rationale, properties, and principles governing their design and evolution (BASS; CLEMENTS; KAZMAN, 2012;ISO, 2011). In SoS context, a software architecture involves the SoS in its fundamental structure, including its constituents and connections between them, properties of the constituents and of the environment [START_REF] Nielsen | Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions[END_REF]. These concepts are important, as architectural models can be adopted for evaluation activities, contributing to improve the SoS quality [START_REF] Nakagawa | The state of the art and future perspectives in systems of systems software architectures[END_REF].

Constituents and SoS itself are often specified using some ADL. An ADL is a domain specific language adopted to specify the structure of a system (ISO, 2011;[START_REF] Nielsen | Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions[END_REF][START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF]. While current ADL support both representation and evaluation of SoS [START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF], they still lack mechanisms to capture uncertainty, dynamism, and potentially undesired behaviors that can emerge from SoS architecture configurations [START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF]. Languages often adopted to describe software architectures, such as UML2 , SysML3 , and CML4 , lack expressiveness for describing SoS, specially regarding to: (i) a partial description of constituents, which are not totally known at design time; (ii) environmental modeling; and (iii) dynamic architecture. Other initiatives have proposed approaches that use model transformations from an architectural model (π-ADL, SySML, HLA, DoDAF5 ) to some simulation formalism (Go language, Simulink6 ). However, these approaches do not support: (i) SoS software architecture specification (CAVALCANTE; [START_REF] Oquendo | π-ADL: An Architecture Description Language Based on the Higher-order Typed π-calculus for Specifying Dynamic and Mobile Software Architectures[END_REF]BATISTA, 2014;[START_REF] Cavalcante | Statistical model checking of dynamic software architectures[END_REF], (ii) dynamic architecture and constituents not known at design time (FALKNER et al., 2016), and (iii) the concept of SoS software architecture with all the necessary details to guarantee precision in representation [START_REF] Xia | A model-driven approach for evaluating system of systems[END_REF][START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF].

Many languages have been adopted for specifying SoS architectures (GUESSI et al., 2015;KLEIN;[START_REF] Klein | A systematic review of system-of-systems architecture research[END_REF].

Composable Adaptive Software Systems (COMPASS) defines a modeling paradigm that allows a SoS to be deployed via mediators. Besides, it allows to model constituents and aspects of the application, validate syntactic, semantic, and binary compatibility of the assembled constituents, and generate the systemic meta-data as descriptors to be used for middleware purposes [START_REF] Gokhale | Model driven middleware: A new paradigm for developing distributed real-time and embedded systems[END_REF]. They assume a SoS as a net-centric and distributed set of intercommunicating systems.

Pavon present an approach to engineer SoS based on agents simulation. Models are used to specify/document SoS, analyze it, validate it, tackle target platform heterogeneity, using of transformations and model-driven technologies to generate graphical editors and model transformations/code generation and deployment (PAVON; GOMEZ-SANZ; PAREDES, 2011), with evaluation using a Water Management Policies System. Self-Management Modeling Language (SelfMML) is adopted to model the self-adaptation ability of a SoS architecture.

Systems Modeling Language (SySML), a semi-formal systems modeling notation, is adopted in many studies to model SoS architectures (MITTAL;[START_REF] Mittal | Model-driven systems engineering for netcentric system of systems with DEVS unified process[END_REF][START_REF] Bryans | Semi-formal and formal interface specification for system of systems architecture[END_REF][START_REF] Andrews | Model-based development of fault tolerant systems of systems[END_REF]. Despite that fact, SysML (OMG, 2017) lacks of specific structures to model some aspects of SoS software architecture SoS. It can represent multiple systems through the use of block diagrams, but its models are static, preventing representation of dynamic properties, as dynamic architecture and emergent behaviors [START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF]. Dahmann recently advocated the adoption of SySML as a suitable language to represent SoS architectures (DAHMANN et al., 2017). They provide a working example of a Cross-Domain Maritime Surveillance and Targeting (CDMaST) SoS developed in Defense Advanced Research Projects Agency (DARPA), and report the use of IBM Rational Rhapsody to animate SySML models, making them executable. They indeed report the adoption of Unified Profile for DoDAF and MODAF (UPDM) as the architectural framework to document SoS using SySML. However, no clue on dynamic architectures and reconfiguration is given.

Unified Modeling Language (UML) is also proposed as a possible language to represent SoS software architectures [START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF]. Dagli and Kilicay-Ergin suggest to create a language for SoS stakeholders using DoDAF and use UML for capturing different SoS static views via models [START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF]. Cook et al. also propose MSC Assertions, which is a formal-language extension for UML message sequence diagram superimposed with UML statecharts to validate SoS runtime behaviors (COOK;[START_REF] Cook | validation and run-time monitoring of soa based system-of-systems temporal behaviors[END_REF][START_REF] Cook | validation and run-time monitoring of soa based system-of-systems temporal behaviors[END_REF][START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF]. Griendling and Mavris propose to use UML in a methodology termed Architecture-based Technology Evaluation and discuss UML limitations to represent executable models, suggesting the use of Discrete Event notations [START_REF] Griendling | Development of a dodaf-based executable architecting approach to analyze system-of-systems alternatives[END_REF][START_REF] Griendling | Development of a dodaf-based executable architecting approach to analyze system-of-systems alternatives[END_REF]. Capability Tradeoff (ARCHITECT) UPDM is also another formalism identified to model SoS. It consists of an ADL that provides UPDM (Unified Profile for DoDAF and MODAF) provides a consistent, standardized means to describe DoDAF 1.5 and MODAF 1.2 architectures in UML-based tools as well as a standard for interoperability (HAUSE, 2010b;HAUSE, 2010a). Mordecai et al. also propose the use of UML and/or a UML profile (such as SySML) to implement MoBIE ontology, an ontology of a conceptual modeling framework for modelbased interoperability engineering (MoBIE) for SoS (MORDECAI; ORHOF; DORI, 2017).

Even eXtensible Markup Language (XML) has been recommended at some level to represent some aspect of a SoS [START_REF] Barbi | A model-driven approach for configuring and deploying systems of systems[END_REF]MITTAL;[START_REF] Mittal | Model-driven systems engineering for netcentric system of systems with DEVS unified process[END_REF][START_REF] Gokhale | Model driven middleware: A new paradigm for developing distributed real-time and embedded systems[END_REF]. In general, XML is automatically generated to specify some configuration files for middleware or deployment.

Bigraph-based modeling offers a solution for mathematically representing SoS using graphs (WACHHOLDER; STARY, 2015; GASSARA; BOUASSIDA; JMAIEL, 2017; GAS-SARA et al., 2017). Nodes represent constituents, and edges represent their interoperability links. Authors claim that bigraphs allow the modeling of SoS including their constituents (e.g., sub-systems, features, in-formation resources, etc.) by means of their structural as well as behavioral characteristics. Structural characteristics are materialized by links (i.e. system connectivity). They further specify reaction rules to model SoS constituents behaviors and reaction to external stimuli. SosADL is a novel ADL for specifying SoS (OQUENDO, 2016a;OQUENDO, 2016b;OQUENDO, 2016c). SosADL supports the specification of abstract architectures in which constituents are known at design-time and abstract connectors (also referred to as mediators) that can be dynamically realized for composing concrete architectures of this SoS. SoSADL is formally founded on π-calculus, while still offer a syntax for specification in highlevel of abstraction (OQUENDO, 2016c). In SoSADL, architectures are abstractly defined by coalitions, which represent temporary alliances among constituents that collaborate via mediators (OQUENDO, 2016c). Such coalitions can be dynamically formed and changed at runtime. Coalition behaviors document how constituents interoperate to accomplish a given set of missions. Figure 4 shows an excerpt of SoSADL metamodel. Mediators are first-class elements representing communication links between two or more constituents [START_REF] Weyns | On the challenges of self-adaptation in systems of systems[END_REF]. The architecture of a SoS defines policies for assembling abstract types of systems and mediators as coalitions, which are further characterized by behavior, data type, and gate declarations. Gates are abstractions that enable the establishment of connections. A connection can receive stimulus from or act on the environment, hence enabling the communication among independent elements. Data types can have inherent functions, and functions can be associated to expressions. Mediators and systems can also specified in terms of gates, data types, and behaviors.

SoSADL is an executable language, as it exhibits an operational semantics, i.e., a recipe of how SosADL statements should be interpreted to be converted in executable models [START_REF] Plotkin | Structural operational semantics the origins of structural operational semantics[END_REF]OQUENDO, 2016b). If an execution mechanism is not available, strategies (as model transformations) can be established to provide a dynamic view to enable the visualization of SoS dynamic architectures, a topic discussed in the next section.

Dynamic Software Architectures

SoS software architectures are inherently dynamic since constituents can freely join or leave the SoS structure at any moment. SoS dynamic architectures, also known as evolutionary architecture, are considered a consequence of the inherent operational and managerial independence of SoS constituents (OQUENDO, 2016a). Dynamic software architectures (DSA) are not a novel trend [START_REF] Oreizy | Issues in modeling and analyzing dynamic software architectures[END_REF]ALLEN;[START_REF] Allen | Specifying and analyzing dynamic software architectures[END_REF][START_REF] Allen | Specifying and analyzing dynamic software architectures[END_REF]LEMOS;[START_REF] Lemos | ICSE 2002 workshop on architecting dependable systems[END_REF][START_REF] Lemos | ICSE 2002 workshop on architecting dependable systems[END_REF]COSTA;[START_REF] Costa | Dynamic adaptation of aspect-oriented components[END_REF][START_REF] Costa | Dynamic adaptation of aspect-oriented components[END_REF]MEDVIDOVIC;TAYLOR, 2010). They comprise of software architectures that exhibit dynamic reconfiguration ability, i.e., the ability to self-adapt its own structure at runtime due to a diversity of reasons [START_REF] Zuniga-Prieto | Dynamic reconfiguration of cloud application architectures. Software: Practice and Experience[END_REF], including faulttolerance (LEMOS; GUERRA; [START_REF] Lemos | A fault-tolerant architectural approach for dependable systems[END_REF][START_REF] Andersson | Software engineering for selfadaptive systems[END_REF]. Such ability is essential to minimize system disruptions while new or modified constituents are being joined into a SoS. Therefore, such characteristic is inherent to SoS and required to provide trust for SoS operation.

Several dynamic architecture description languages (DADLs) were proposed, including Rapide (LUCKHAM; VERA, 1995), Darwin (MAGEE;KRAMER, 1996), Dynamic ACME (GARLAN; MONROE; WILE, 1997), Chemical Abstract Machine-based formalism (WERMELINGER, 1998), Dynamic Wright (ALLEN;[START_REF] Allen | Specifying and analyzing dynamic software architectures[END_REF][START_REF] Allen | Specifying and analyzing dynamic software architectures[END_REF]. However, they worked at component-level of single systems, dealing only with predicted components, with no support for multiple systems interoperating, constituents not known at design-time, and constituents joining or leaving a whole SoS at runtime. Such languages relied purely on structural models and captured a very limited perspective of the application being represented, consequently failing to support prediction of runtime behavior and sustainment of software operation, even for isolated systems [START_REF] Oreizy | Issues in modeling and analyzing dynamic software architectures[END_REF].

Advances have recently been achieved regarding DSA management. Cavalcante et al. addressed the existing gap between architecture descriptions and their respective implementations in the context of large-scale, dynamic software systems. They introduced the dynamic reconfiguration support provided by π-ADL (OQUENDO, 2004), a formal ADL for describing dynamic software architectures under structural and behavioral viewpoints based on an initial running architecture decomposed into its constituent architectural elements, modified and (re)composed to form a new, evolved architecture (CAVALCANTE; BATISTA; OQUENDO, 2015). They also advanced the state of the art by proposing two approaches for managing dynamic reconfiguration, namely: (i) an exogenous approach, in which an architectural element has the control over the other architectural elements and centralizes the reconfiguration actions to be applied on the architecture; and (ii) an endogenous, decentralized approach, in which the architectural elements themselves are able to perform the reconfiguration actions.

Research groups have investigated and proposed self-adaptation abilities for SoS architectures [START_REF] Firesmith | Profiling Systems Using the Defining Characteristics of Systems of Systems (SoS)[END_REF][START_REF] Romay | On self-adaptation in systemsof-systems[END_REF][START_REF] Romay | On self-adaptation in systemsof-systems[END_REF][START_REF] Romay | On self-adaptation in systemsof-systems[END_REF][START_REF] Batista | Challenges for sos architecture description[END_REF]WEYNS;[START_REF] Weyns | On the challenges of self-adaptation in systems of systems[END_REF]. However, there is still a lack of studies on the specification and implementation of DSA, besides studies on their simulation and dynamic reconfiguration support.

Prescriptive and Descriptive Architectural Models

To attain to best practices when developing SoS, software architectures must be specified under two complementary perspectives (VALERDI; ROSS; RHODES, 2007; TAYLOR; MEDVIDOVIC; DASHOFY, 2010): (i) prescriptive models, which captures the design decisions made prior to the system's construction (it is the as-conceived or as-intended architecture); and (ii) descriptive models, which describe how the system has been built (it is the as-implemented or as-realized architecture). Abstract architectures are the prescriptive architectures for SoS, as they define at design time the baseline from which a family of SoS architectural configurations (or concrete architectures) can be dynamically established. In turn, concrete architectures can be regarded as descriptive models, describing how individual actions of constituents are combined to produce a desired behavior. The concrete architecture is subject to simulation. As such architecture dynamically evolves, the new concrete architecture that results from such changes may conform (or not) to the original abstract architecture. When considering SoS context, such changes are frequent, and can be beneficial or harmful for SoS behaviors. A new architectural configuration may even offer better functionalities than the original architecture because it has new functionalities or a new structure that was not envisaged, and that emerged from the architectural changes. Regardless, abstract and concrete architectural models of a SoS can grow further apart, becoming increasingly inconsistent with each other.

Three different models are used for description of SoS architectures (PERRY; [START_REF] Perry | Assisting the evolutionary development of sos with reconfiguration patterns[END_REF][START_REF] Heldal | Descriptive vs prescriptive models in industry[END_REF]VALERDI;ROSS;[START_REF] Valerdi | Foundations of modelling and simulation of complex systems[END_REF]TAYLOR;MEDVIDOVIC;[START_REF] Taylor | Software Architecture -Foundations, Theory, and Practice[END_REF]: SoS abstract architecture, which captures the SoS intended general structure, specifying the potential types of constituents that can join the SoS and the feasible links that they can establish to interoperate; SoS architectural instance, which consists of one possible SoS software architecture models. This model is one realization (between many possible instances) of the abstract architecture. It specifies the exact number and types of each constituent that can be part of such SoS, and the connections to be established between them; and SoS concrete architecture, which shows the runtime version of a SoS. Such models are often materialized as simulation models or the runtime real architecture and its corresponding model.

To prevent inconsistencies between these models, anti-erosion techniques can provide mechanisms for (GURP; [START_REF] Gurp | Design erosion: problems and causes[END_REF][START_REF] Gurgel | Blending and reusing rules for architectural degradation prevention[END_REF]: (i) explicitly defining the intended architecture of a system, which includes the description of dependency rules among components, and (ii) checking whether the system implementation conforms to the intended design. Mechanisms for controlling architecture erosion have been traditionally centered on architecture repair. This process typically involves (SILVA; BALASUBRAMA-NIAM, 2012): (i) using some reverse engineering mechanism to extract the implemented architecture from source artifacts (recovery); (ii) mechanisms to infer its intended architecture (model discovery); and (iii) applying fixes to the eroded parts of the implementation (reconciliation). Regarding SoS, mechanisms must be established to bridge prescriptive and descriptive architectural models in order to avoid the aforementioned problems derived from architectural degradation. However, for SoS context, these techniques are still scarce. Besides, the concepts of architectural drift and erosion for SoS domain have not even been consensual.

Simulation Models for SoS

The ability to animate models can help one better understand modeled behavior. Novices and experienced developers will both benefit from the visualization of modeled behavior provided by model animators. Model animation can give quick visual feedback to novice modelers and can thus help them identify improper use of modeling constructs. Experienced modelers can use model animation to understand designs created by other developers better and faster [START_REF] France | Model-driven development of complex software: A research roadmap[END_REF][START_REF] France | Model-driven development of complex software: A research roadmap[END_REF]. Simulations provide animations for models.

SoS architectures should offer a dynamic viewpoint to support a suitable evaluation of their dynamic behavior and architecture, besides predicting and preventing unexpected behaviors. Simulation-based approach is a well-known and well-accepted formalism for SoS development and for software architecture evaluation (DOBRICA; [START_REF] Dobrica | A survey on software architecture analysis methods[END_REF]MICHAEL;[START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Bosch | Design and Use of Software Architectures: Adopting and Evolving a Product-line Approach[END_REF]. Nonetheless, despite the ADL support for validation of software architectures and the crosscutting nature of ADL to the validation strategies, the majority of the known ADL have not supported both the specification and dynamic properties (emergent behaviors and dynamic architecture) of SoS architectures [START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF]. Simulations have supported dynamic properties for SoS [START_REF] Nielsen | Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions[END_REF]MITTAL;[START_REF] Mittal | Harnessing Emergence: The Control and Design of Emergent Behavior in System of Systems Engineering[END_REF]MICHAEL;[START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF]SAUSER;BOARDMAN;[START_REF] Sauser | Systomics: Toward a Biology of System of Systems[END_REF][START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF]WACHHOLDER;STARY, 2015;[START_REF] Fran Ça | Reporting guidelines for simulation-based studies in software engineering[END_REF][START_REF] Fran Ça | Reporting guidelines for simulation-based studies in software engineering[END_REF]. Such approaches [START_REF] Michael | Verification and validation for trustworthy software systems[END_REF][START_REF] Fran Ça | Reporting guidelines for simulation-based studies in software engineering[END_REF][START_REF] Fran Ça | Reporting guidelines for simulation-based studies in software engineering[END_REF]WACHHOLDER;STARY, 2015;[START_REF] Xia | A model-driven approach for evaluating system of systems[END_REF]: (i) support the validation of expected emergent behaviors, (ii) empower the observation of unexpected emergent behaviors; (iii) enable the prediction of errors, diagnosing them and permitting corrections; and (iv) provide a visual and dynamic viewpoint, reproducing stimuli that the system can receive from an operational environment. DEVS is a well-known SoS simulation language to achieve SoS simulation [START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF].

DEVS is a modeling formalism for SoS based on the idea of atomic and coupled models (TENDELOO; VANGHELUWE, 2017;[START_REF] Valerdi | Foundations of modelling and simulation of complex systems[END_REF]ZEIGLER et al., 2.2. MBSE for SoS 29 2012;[START_REF] Mittal | Modeling and simulation for systems of systems engineering[END_REF]. Atomic models represents individual entities in the SoS (for instance, systems), while coupled models represent a combination of atomic models. Atomic models have the following elements: (i) a labeled state diagram, that performs transitions due to input or output events; (ii) abstract data types definition, (iii) global variables definition, (iv) variables initialization, (v) ports definition, and (vi) events definition. An atomic model with only a state diagram specification and ports definition is already executable. Coupled models are expressed as a System Entity Structure (SES), i.e., a formal structure governed by a small number of axioms that expresses how atomic models communicate.

Bagdatli and Dimitri developed a notation and a simulation execution engine to model and execute a high level architecture of a system of systems, it was named as a High-level Architecture (HLA) Discrete Event Simulation: HADES (BAGDATLI; MAVRIS, 2012). They discuss a plethora of underlying simulation paradigms, including Probability Calculations, Markov Chains, Queueing Models, Petri Nets, Discrete Event Systems Specification (DEVS), and Agent Based. They conclude that DEVS is the best approach, and implemented their engine on that. Recently, Falcone et al. also proposed a simulation based on HLA [START_REF] Falcone | Experiences in simplifying distributed simulation: The HLA development kit framework[END_REF].

Tomson and Preden propose MACE simulation framework, consisting of a simulator application and a binding mechanism for agent and mediator code for simulating complex SoS that make use of a proactive middleware (TOMSON; PREDEN, 2013).

Stimuli Generators

Modelling and simulation (M&S) are vital elements within processes for analysis and design of SoS. M&S enable visualization of SoS dynamics [START_REF] Valerdi | Foundations of modelling and simulation of complex systems[END_REF][START_REF] France | Model-driven development of complex software: A research roadmap[END_REF][START_REF] France | Model-driven development of complex software: A research roadmap[END_REF]CARLE et al., 2012;[START_REF] Baldwin | Simulation approaches for system of systems: Events-based versus agent based modeling[END_REF]SAUSER;[START_REF] Baldwin | Simulation approaches for system of systems: Events-based versus agent based modeling[END_REF]FALKNER et al., 2016). Several application domains adopt M&S [START_REF] Valerdi | Foundations of modelling and simulation of complex systems[END_REF]. Simulations correspond to an imitation of the operation of a real-world process or system over time, and involve generation of artificial stimuli and the observation of its outcome to draw inferences about the operation of real systems that they represent [START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF][START_REF] Valerdi | Foundations of modelling and simulation of complex systems[END_REF]BANKS, 1999). As such, M&S promote: (i) a visual and dynamic viewpoint for SoS software architectures, reproducing stimuli the system can receive from a real environment; (ii) prediction of errors, diagnosing them and enabling corrections, and (iii) observation of expected and unexpected emergent behaviors of an SoS [START_REF] Bosch | Design and Use of Software Architectures: Adopting and Evolving a Product-line Approach[END_REF]SANTOS et al., ).

Baldwin et al. summarize current techniques found in the literature to simulate SoS (BALDWIN; SAUSER; CLOUTIER, 2015). Event-based modeling is the most prominent approach, as researchers can program different states a system undergoes to comprehend the behavior of the SoS as a whole (BALDWIN; SAUSER; CLOUTIER, 2015). In particular, DEVS is the most popular event-based simulation formalism (CHOI; KANG, 2013). It represents SoS, providing the required dynamic view of SoS. However, a straightforward generation of DEVS code does not guarantee the simulation is executable. This happens because the SoS operation is deeply related to the stimuli received from the environment that triggers the simulation execution. Hence, it is necessary to elaborate a specific entity in the simulation model that is responsible for delivering expected stimuli that drive the operation of the SoS: the stimuli generator.

Regardless of the approach adopted to simulate SoS, simulations often depend on some internal structure that imitates the surrounding environment of an SoS, delivering stimuli that are assumed to be received by the SoS to trigger its operation (INCOSE, 2016). The environment comprises the SoS surroundings, such as temperature, wind, water level, and noise; and and/or conditions in which a system operates, such as battery level and geographic position (GRACIANO NETO et al., 2016). Environment is local to each system. By the nature of SoS, environments are only partially known at design-time (OQUENDO, 2016a).

There are two alternatives to deliver stimuli to a simulation (SANCHEZ-MONTANES; KONIG; [START_REF] Sanchez-Montanes | Learning sensory maps with real-world stimuli in real time using a biophysically realistic learning rule[END_REF][START_REF] Bruneau | Diasim: a simulator for pervasive computing applications[END_REF][START_REF] Bruneau | Diasim: a simulator for pervasive computing applications[END_REF][START_REF] Rahman | Stimulus generation technique for code simulation of fpga based gamma spectroscopy system[END_REF]PIC-COLBONI;[START_REF] Piccolboni | Simplified stimuli generation for scenario and assertion based verification[END_REF][START_REF] Yang | Coverage-driven stimuli generation[END_REF]. The first one is adding a portion of code to the body of each constituent in the simulation, randomly producing data (BOGADO; GONNET; LEONE, 2014). However, this approach brakes the separation of concerns principle, decreasing maintainability, as this code will be tangled to the constituent operational code. The second alternative is to materialize all stimuli into a single artificial entity known as stimuli generator. This structure becomes part of the simulated SoS, continuously delivering stimuli to SoS. Hence, stimuli generators imitates the SoS surrounding environment, automating the stimuli input [START_REF] Rahman | Stimulus generation technique for code simulation of fpga based gamma spectroscopy system[END_REF][START_REF] Piccolboni | Simplified stimuli generation for scenario and assertion based verification[END_REF][START_REF] Piccolboni | Simplified stimuli generation for scenario and assertion based verification[END_REF][START_REF] Yang | Coverage-driven stimuli generation[END_REF][START_REF]The Art of Simulation Using PSpice: Analog and Digital[END_REF][START_REF] Kitchen | Stimulus generation for constrained random simulation[END_REF][START_REF] Kitchen | Stimulus generation for constrained random simulation[END_REF][START_REF] Plaza | Toggle: A coverage-guided random stimulus generator[END_REF][START_REF] Plaza | Toggle: A coverage-guided random stimulus generator[END_REF][START_REF] Plaza | Toggle: A coverage-guided random stimulus generator[END_REF].

Developing stimuli generators require a careful investigation of SoS requirements and architecture specification to elicit which stimuli should be provided. Such tasks can bring additional cost to the SoS development and might be error-prone when a manual approach is used to transform architectural elements in software code. Moreover, stimuli generator can be used as an interface between the simulator actually employed and other industrial simulators used to imitate real environments, such as flight simulators, or a river simulation for flood monitoring SoS. This association between two types of simulator is known as co-simulation (BARTON; [START_REF] Barton | Modeling of combined discrete/continuous processes[END_REF][START_REF] Gomes | Foundations for continuous time hierarchical co-simulation[END_REF]. This approach is broadly adopted by industry to large-scale test. Meanwhile, despite the potential of stimuli generators to support co-simulation approaches in SoS development, such approaches for automatically creating this stimuli generator for simulation of SoS have not been widely investigated.

Model-Based Engineering (MBE) techniques have been investigated in the context of SoS (FRANCE;[START_REF] France | Model-driven development of complex software: A research roadmap[END_REF][START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF]FALKNER et al., 2016;GRACIANO NETO et al., 2016;[START_REF] Lana | Systems-of-systems development: Initiatives, trends, and challenges[END_REF]. They represent a software engineering approach in which models are the main basis, spanning all activities that make up the software development process [START_REF] Sendall | Model transformation: The heart and soul of modeldriven software development[END_REF][START_REF] Sendall | Model transformation: The heart and soul of modeldriven software development[END_REF][START_REF] Nielsen | Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions[END_REF]. MBE has been supported by a broad set of tools that are available to achieve a proper level of automation using transformation tools, such as Xtend [START_REF] Bettini | Implementing Domain-Specific Languages with Xtext and Xtend[END_REF] and Acceleo (ECLIPSE, 2012). Model transformations are the heart of MBE (SENDALL; [START_REF] Sendall | Model transformation: The heart and soul of modeldriven software development[END_REF]. Model transformations are a well-accepted approach that aids software engineers in establishing correspondences between models [START_REF] Sun | Model Transformations Require Formal Semantics[END_REF]. It consists of a program, often written in a declarative manner, that transforms an input model in an output model [START_REF] Sendall | Model transformation: The heart and soul of modeldriven software development[END_REF][START_REF] Sendall | Model transformation: The heart and soul of modeldriven software development[END_REF]. MBE can be exploited to generate stimuli generators.

2.2.8. Evaluation, Testing, Verification, and Validation for SoS Michael et al. discuss verification and validation in SoS domain (MICHAEL;[START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Michael | Verification and validation for trustworthy software systems[END_REF]. They propose alternatives for validation and verification in that domain, and introduce a mathematical model to link nonfunctional requirements of software systems to their SoS architecture, and present an approach to evaluate the quality of software architecture considering requirements. Zapata et al., in turn, investigate testing for SoS (ZAPATA et al., 2013). Authors claim that an important challenge in SoS Testing methodologies is to establish a test suite that check that the complete SoS mission and objectives are achieved. This is a hard problem, as testing for every interface in the SoS leads to an exponential complexity. They propose a software testing technique named Basis Path Testing, which is a white-box technique that creates a control flow graph from each of the constituents behaviors to design an optimal test suite. This test suite is a set of paths that traverse through the functions, which are assumed linearly independent and that can be used to create a test strategy that will exercise all of the program's functions at least once to verify and validate their functionality. By applying Basis Path Testing analysis to the constituent systems in a SoS, the tester can develop an optimal test suite that will guarantee that all possible independent paths, all possible logical decisions, and all their interfaces are executed at least once.

Falkner et al. propose an approach for measuring performance of SoS architectures (FALKNER et al., 2016). They developed an environment called MEDEA, which is a MBSE-based system execution environment that supports evaluation and performance prediction. They model SoS using many views through GraphML, a platform-independent language that supports modelling of interfaces, behavior, and workload of SoS and its constituents. They also perform simulations in their environment.

Meinke reports preliminary results of the creation of a Learning-based testing (LBT) for cyber-physical systems-of-systems (CO-CPS). Author proposes a paradigm for fully automated requirements testing that combines machine learning with model-checking techniques (MEINKE, 2017) Yun et al. propose a mutation analysis approach for SoS policy testing (YUN; SHIN; BAE, 2017). Mutation analysis is a systematic way of evaluating test cases using artificial faults called mutants. As a general mutation framework for SoS policy testing, we present an overview of mutation analysis in SoS policy testing as well as the key aspects that must be defined in practice. Authors provide a case study using a traffic management SoS with the Simulation of Urban Mobility (SUMO) simulator. The results show that the mutation analysis is effective at evaluating fault detection effectiveness of test cases for SoS policies at a reasonable cost.

Deployment and Maintainability

Barbi et al. present a model-driven approach to configure and deploy SoS based on a framework for distributed applications [START_REF] Barbi | A model-driven approach for configuring and deploying systems of systems[END_REF]. Configuration of SoS involves the production of many configuration files (at least, at this framework-based approach) which describes the structure of the SoS in general, configuration parameters, and interoperability issues. Such configuration files uses to reach a considerable size and complexity due to the hundreds of lines of code. Additionally, handle text files manually is error-prone. Possibly, repetitive code must also exist in the resultant configuration file (not explicitly mentioned); the lack of a supporting tool. Three different architectural views are used: Structure View: it describes the structure of the components of a SoS with the relations and interactions between them; Deployment View: it describes the components distribution on the nodes (e.g. the A Process runs on the F Server); Activity View: it describes the boot and shutdown order of the system components. They create a tool called ACTUAL (Automation of the Configuration and deploymenT of distribUted AppLications) based on GMF. OCL constraints were added to to the metamodel to support the error control mechanism. XSLT and XSL were used to implement the transformations from models to configuration files.

Andren et al. also work on SoS deployment by proposing a DSL for Smart Grid Architecture Model (SGAM), using MBSE principle to automate and shorten the design process of use cases, also automating code generation and deployment of power utility applications (ANDR ÉN; STRASSER; KASTNER, 2017).

Model Transformations

Model transformations are a valuable resource. Transformations in MBSE can be seen as a specialization of reduction procedures in computability theory, in which an algorithm transforms one problem into another problem. A transformation establishes traceability between two models, besides enabling a conversion of one formalism into another one. Many transformations have been carried out in MBSE domain for a diversity of purposes, including mapping between static and dynamic models, and automatic refinements in a same model (usually, a M2M transformation). Table 1 summarizes some instances of these transformations found in literature, the type of transformation, source models, and target models found.

Neema et al. present a framework for SoS simulation with Information Fusion capabilities [START_REF] Neema | Model based integration and experimentation of Information Fusion and C2 Systems[END_REF]. DEVS is used to model the simulation environment; GME for infrastructure model interpretation; and Simulink to model the Unmanned Aerial Vehicles (UAV). A Case study on Command and Control (C2) domain is presented with a simulation of a urban atack with bombs. The combat team is based on autonomous vehicles (constituents) and those together acts as a SoS. Model-driven practices (MIC, specifically) are used to support a simulation environment for that scenario, and to perform models fusion. Transformations and metamodels are used, but there are no details about technologies they use to transform models, except for GME. Solution reported works only on one proprietary middleware platform. They use a set of views to describe the system (analogous to 4+1 Kruchten views set), and a mission scenario is mentioned as a kind of model to represent missions, and they use Colored Petri Nets to model such missions. Tu et al. present an ongoing research which uses MBSE to perform reverse engineering over legacy Enterprise Information Systems, and using the originated models to compose a Federation of Information Systems, with broad coverage of interoperability issues [START_REF] Tu | Harmonized and reversible development framework for HLA based interoperable application[END_REF][START_REF] Tu | Harmonized and reversible development framework for HLA based interoperable application[END_REF][START_REF] Tu | Harmonized and reversible development framework for HLA based interoperable application[END_REF]. As legacy information systems (IS) often are required to interoperate and costs to implement new ones are high, they propose a process based on MDA to address what they call Model Reverse Engineering, culminating in a bidirectional transformation approach, to extract models from legacy IS, and to generate a Federation. Thus, bidirectionality does not cover the Federation/SoS reverse engineering as a whole, but only from their federates (constituents). They use High Level Architecture (HLA) as a basis to create the environment of distribution simulations (it is a framework for simulation too). They use MoDisco, a integrant part of Eclipse Modeling Project used to perform Model Discovery, an approach to extract models from legacy code. Barbi et al. perform bidirectional transformations 7 by conducting a M2T transformation via XSLT to map SoS functionalities to configuration files for deployment purposes, from ACTUAL-model to XML, and vice-versa (BARBI et al., 2012). OCL constraints were added to to the metamodel to support the error control mechanism. XSLT and XSL were used to implement the transformations from models to configuration files.

Gezgin et al. perform a M2M graph transformation to deal with dynamic architecture of SoS [START_REF] Gezgin | Towards a Rigorous Modeling Formalism for Systems of Systems[END_REF]. They propose a visual approach and tool that run a graph transformation to automatically update a SoS architecture, converting one architectural configuration into another one. They mention a variation of UML called MECHATRONIC UML, and show an example of a SoS changing its architecture.

Hellestrand address cars as constituents of SoS [START_REF] Hellestrand | Engineering safe autonomous mobile systems of systems using specification (model) based systems architecture amp; engineering[END_REF]. He models a car using a DSL called Vehicle Dynamics Model (VDM), and transforms it to another formalism termed Specification-Based Architecture (SBA). He claims that many SBA models can be simulated in association, forming an executable model of SoS.

Belloir et al. transformed requirements expressed in a requirements engineering 7 Currently, a bidirectional transformation is understood by MBSE community as a single mapping that works for both sides (source and target), i.e., it is capable of linking two models and identically transforming in forward and backward directions using the same transformation. This type of transformation is often specified in a bidirectional transformation language (such as BiGUL (KO; ZAN; HU, 2016)). However, as this is not a reality for SoS domain yet, for the scope of this thesis, a bidirectional transformation is that one in which a pair of transformations (one forward and another one backward) are used to link two SoS models.

For the scope of this thesis, such type of transformation can also be referred as a round-trip engineering approach. Systems are critical to many areas and uses to be interconnected via networks to form systems of systems [START_REF] Gokhale | Model driven middleware: A new paradigm for developing distributed real-time and embedded systems[END_REF]. They claim additionally that delivering DRE systems supporting Quality of Service (QoS) properties is complex since DRE are mostly engineered using Component-Based Software Engineering and based on COTS of hardware and software, and since they have to be deployed with a middleware-based communication, and this part is subject to changes along the DRE development lifecycle because changes and evolution in COTS technologies (specially hardware) demands evolution in middleware configuration, what spend substantial time and effort. They propose an approach based on Model-Driven Middleware (MDM), which combines MBSE and QoS-enabled middleware to address composition and integration of such constituents, deploying them in a environment with a correct middleware configuration. They describe CoSMIC (Component Synthesis using Model-Integrated Computing), a technology that relies on COMPASS (COMPosable Adaptive Software Systems), a well-established language to solve problem of packaging component functionalities. They represent SoS using COMPASS, transforming such model for a combination of Option Configuration Modeling Language (OCML) and Event QoS Aspect Language (EQAL) (OCML+EQAL). Such models are subsequently transformed by CoSMIC tool in metadata documented in XML that can be used in the underlying middleware. Guessi et al. propose a methodology to address refinenement of SoS abstract architectures, automatically deriving feasible concrete architectures, i.e., SoS software architectures that are able to achieve pre-defined goals and properties (GUESSI; OQUENDO; NAKAGAWA, 2016). They adopt SosADL to specify abstract and concrete SoS software architectures. Besides, they adopt Alloy to specify constraints and properties on the abstract architectural model. This association of Alloy and SosADL is input for a model transformation, that generates a feasible SoS concrete architecture as output. Silva et al. (SILVA;CAVALCANTE;[START_REF] Silva | Refining missions to architectures in softwareintensive systems-of-systems[END_REF] proposed a M2M modeltransformation to automatically refine m-KAOS missions, transforming them into SosADL models, in which constituents match the goals, if they are at the same semantic granularity.

Andren et al. (ANDR ÉN; STRASSER; KASTNER, 2017) present a model-based approach that proposes a Domain-Specific Language (DSL) termed Power System Automation Language (PSAL) based on Smart Grid Architecture Model (SGAM) 8 to support a formal description a smart grid architecture (in particular its use cases). They implemented PSAL using the Xtext environment for the Eclipse IDE, and implemented a a validation test case for a laboratory environment. A transformation between PSAL and SCL (System Configuration Language) 9 was implemented. Graciano Neto et al. propose a model transformation to map SosADL models in DEVS models, as explained during this thesis (GRACIANO NETO, 2016; GRACIANO NETO, 2017;GRACIANO NETO et al., 2018b). In (GRACIANO NETO, 2016), simulation models created from SosADL models are used to validate emergent behaviors. In (GRACIANO NETO, 2017), a SosADL construct is used to automatically extract from the SoS software architectural description details about the surrounding environment modeling. As a result, a model transformation creates stimuli generators to immitate the surrounding environment of a SoS during its simulation execution. After, (GRACIANO NETO et al., 2018b) report the use of SosADL2DEVS transformation as a means to obtain dynamic models that support architectural evaluation of SoS software architecture according to pre-defined functional properties, i.e., missions. [START_REF] Holden | A ROSETTA framework for live / synthetic aviation tradeoffs: Preliminary Report[END_REF][START_REF] Holden | A ROSETTA framework for live / synthetic aviation tradeoffs: Preliminary Report[END_REF] designed a model-based conceptual framework for termed Relational Oriented Systems Engineering and Technology Tradeoff Analysis (ROSETTA) framework for performing technology tradeoff and design studies with respect to flight training system of systems (FTSoS). They mention the 8 A layered three-dimensional architectural framework to design smart grid architectures [START_REF] Andr Én | Analyzing the need for a common modeling language for smart grid applications[END_REF]). 9 an XML based description language used to write configuration files for smart grid domain.

potential of their approach to support capability assignment to constituents, and an automated assessment of the resulting architecture via simulations. They propose to model missions in SySML via behavioral diagrams, and assess the SoS architecture via Monte Carlo Simulation.

Transformation Tools, Models, and Languages

Several MBSE tools and models have emerged and been used for SoS development. We can mention transformation languages as Acceleo and Xtend for M2T transformations (GRACIANO NETO et al., 2018b); and ATL and QVT for M2M transformations. Xtext and Ecore are the most common platforms to specify models, metamodels, and grammars (ANDR ÉN; STRASSER; [START_REF] Én | Engineering Smart Grids: Applying Model-Driven Development from Use Case Design to Deployment[END_REF]SILVA;CAVALCANTE;[START_REF] Silva | Refining missions to architectures in softwareintensive systems-of-systems[END_REF].

With respect to tools, Eclipse Modeling Framework (EMF), constructed under the Eclipse Modeling Projecta (EMP) 10 , is a well-known instance that provides a large set of tools that deliver, besides model transformations support, several useful functionalities, as model management, model edition, visual model designs, and animation. Many of such tools offer both M2M and M2T transformations (CZARNECKI;[START_REF] Czarnecki | Sysml executable systems of system architecture definition: A working example[END_REF]. EMF, in particular, is a complete modeling framework that offers a large range of tools and functionalities to support MBSE. It supports code generation facility, capabilities for building tools, and other applications based on structured models [START_REF] Steinberg | EMF: Eclipse Modeling Framework[END_REF]. It offers a complete set of technologies to perform all sort of operations over models.

EMF offers tools for [START_REF] Steinberg | EMF: Eclipse Modeling Framework[END_REF] , 2013). They propose a methodology to solve incompatibilities issues between systems intended to be interoperated through the use of adapters, also known by them as mediators or glue logic. They define an adapter as a (small) additional system that is compatible with each of the original systems. They represent constituents using petrinets, and automatically produce adapters (mediators) to support their communication.

Pavon presents INGENME (supports metamodel management, graphical editor generation for a metamodel, and code generation), INGENIAS Development Kit (IDK) as an agent-oriented language to model such systems; SelfMML to support self-management modeling (PAVON; GOMEZ-SANZ; PAREDES, 2011).

Baddour et al. propose SCV 2 tool, which allows SoS simulation. They adopted XSLT with the SAXON transformation engine to automate the simulator code-generation procedure, by automatically converting statechart diagrams (documented in SySML) into executable SystemC code. Gassara et al. propose BiGMTE (BiGraph Matching & Transformation Engine), a tool for bigraph rewriting (GASSARA; BOUASSIDA; JMAIEL, 2017). BiGMTE tool provides an implementation of bigraph matching and transformation. It allows to execute the application of a reaction rule on a given bigraph to be rewritten. Execution is based on graph rewriting. Actually, they represent a SoS and its constituents by means of agents having a certain structure and behavior.

Final Remarks

MBSE is not a panacea. There is an associated cost associated with its usage. However, it is precisely the attempt to bring benefits that avoids the damages already seen in other engineering by the use or neglect of models (SELIC, 2012). Literature reviews have been conducted in the last years about the adoption of models and their applications for SoS (RAMOS; FERREIRA; [START_REF] Ramos | Model-based Systems Engineering: An Emerging Approach for Modern systems[END_REF][START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF][START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF][START_REF] Lana | Systems-of-systems development: Initiatives, trends, and challenges[END_REF][START_REF] Wortmann | A systematic mapping study on modeling for industry 4.0[END_REF][START_REF] Wortmann | A systematic mapping study on modeling for industry 4.0[END_REF][START_REF] Wortmann | A systematic mapping study on modeling for industry 4.0[END_REF].

Recently, Wortmann et al. proposed MBSE as a key enabler for complex SoS, and an element of what is known as Industry 4.0 (WORTMANN; COMBEMALE; BARAIS, 2017). After analyzing 222 studies, they noticed that 47 employ UML and variants, 36 use DSLs specific to Industry 4.0 challenges, 26 employ knowledge representation techniques, and 19 papers use AutomationML. 40% of the contributions address Industry 4.0 challenges with new DSLs, language profiles of UML or SysML, or metamodeling techniques, which can also be considered challenges for SoS.

We surveyed the literature to find a formalism that could properly support SoS software architecture modeling and simulation [START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF]. For this purpose, such formalism should meet the following language requirements, supporting: Table 2 summarizes the comparison between potential formalisms to support SoS software architecture representation, simulation, and stimuli generator derivation.

We decided to search for a software architecture notation, an ADL or modeling notation, that could support all the concepts necessary to represent SoS and that could be simulated. The following modeling languages have been identified as the key ones used for SoS architecture description: Darwin (semi-formal) [START_REF] Foster | Specification and analysis of dynamically-reconfigurable service architectures[END_REF], Wright (formal) et al., 2015).

Wright and Darwin were not designed to model SoS architectures. The aforementioned requirements are not covered as these ADL were created to model monolithic systems. SysML was the backbone of two European projects (COMPASS 33 and DANSE 34 ) for which they developed extensions for SoSs. DANSE did not develop an ADL, but used SysML for semi-formally describe executable architectures that are then tested against contracts. However, SysML is a UML Profile, and not necessarily an ADL. Moreover, the adoption of SysML to model SoS would require multiple models, each one being simulated individually, and the simulations being interoperated, what is costly. Then, SysML does match our approach requirements, and, despite being adopted for software architecture modeling, is not strictly an ADL. UML shares the same drawbacks.

COMPASS developed a formal approach, in contrast to DANSE that extended a semi-formal one. In COMPASS, CML was specifically designed for SoS modeling and analysis. However, CML is not an ADL. It is a contract-based formal specification language to complement SysML: SysML is used to model the constituent systems and interfaces among them in a SoS and CML is used to enrich these specifications with contracts. A CML model is defined as a collection of process definitions (based on CSP/Circus), which encapsulate state and operations written in VDM as well as interactions via synchronous communications. CML is a low-level formal language, of which a key drawback is that SysML models when mapped to CML results in huge unintelligible descriptions (it was 31 http://www.omg.org/spec/UML/2.5/ 32 http://www.omg.org/spec/SysML/1.4/ 33 http://www.compass-project.eu/ 34 http://danse-ip.eu/home/ one of the lessons learned from COMPASS) (OQUENDO, 2016a).

Finally, π-ADL is a formal language to model distributed architectures. However, despite π-ADL provides architectural description models for concurrent and communication processes, it does not provide straightforward abstractions for some SoS' particular concepts, such as mediator, coalition, environment modeling, and it does not support modeling of abstract architectures and simulations. SoSADL is more expressive than π-ADL for the description of SoS software architectures, with additional elements, such as gates, duties, guarantees, properties and mediators. In SoSADL, architectural descriptions are intentional and abstract, whereas in π-ADL, such descriptions are declarative and concrete. In addition, from a formal point of view, SoSADL includes other formalisms besides the π-calculus, which is the only one that π-ADL possesses.

Hence, only SoSADL matched the majority of requirements we raised. SoSADL is a language formally founded on π-Calculus for SoS, a novel process calculus extended from original π-calculus, conceived for enabling the formal architecture description of softwareintensive SoS. It can be considered correct by construction, as the formal semantics of such calculus is defined by means of a formal transition system, expressed as labeled transition rules, which are formulated as proof rules (OQUENDO, 2016b). In short, SoSADL describes SoS, which can be expressed as a combination of architecture, systems, and mediators declarations 35 . Each architecture declaration is expressed in terms of its intrinsic behavior, data types, and gates, i.e., abstractions that enable the establishment of connections. A connection is established to receive stimulus from or act on the environment, or to simply communicate with other constituents. Furthermore, a connection can be used to receive, send, or do both actions. Data types can have inherent functions, and functions can have associated expressions. Mediators and systems as well as the SoS architecture itself also have gates, data types, and behaviors. Systems play the role of constituents in an Architecture Behavior Declaration, and systems are mediated by mediators. SoSADL supports representation of emergent behavior by means of a coalition, i.e., a temporary alliance that allows constituents to perform a combined action. These emergent behaviors are specified as part of the coalition behavior, documenting how constituents should interact to accomplish a given set of missions 36 .

SoSADL an executable language founded on an operational semantics defined in a formalism termed as π-calculus (OQUENDO, 2016b). SoSADL demands an execution mechanism that runs their models, converting the specification of the SoSADL constructs 35 Mediators are architectural elements that establish communication between two or more constituents (WIEDERHOLD, 1992) 36 Additional details about the syntax of architecture descriptions in SoSADL can be found in (OQUENDO, 2016a).

in operational portions. Such mechanism, materialized as a model transformation that generates simulation models, matches the majority of our requirements and offers a denotational executable semantics with DEVS that conforms to the operational semantics in π-Calculus for SoS. SosADL holds the environment description, whilst a simulation formalism run the stimuli generators created.

Simulation formalisms (or notations subject to simulation) such as Simulink/MAT-LAB 37 , Executable UML (HU et al., 2014a), or SySML 38 do not support any one of the aforementioned requirements. Even if such formalisms could represent SoS constituents by means of multiple models, each one representing one individual constituent, hence, simulating them would require interoperability between individual simulations (known as distributed simulations), which demands further adaptations and costly implementations. DEVS, in turns, was developed specially to represent SoS architectures. Hence, we chose DEVS as the formalism to simulate our SoS software architectures.

However, even DEVS lacks important characteristics for expressing SoS software architectures, such as: (i) the language only deals with the notion of ports; there is no notion of connections and gates separately, that is a remarkable paradigm of software architectures (Components, Connections, and Values/Constraints define a software architecture (BASS; CLEMENTS; KAZMAN, 2012;ISO, 2011)) used by SoS modeling (CAVALCANTE; BATISTA; OQUENDO, 2015); (ii) In DEVS, every major entity of an architecture is represented as the same type of model (called atomic model). As the single abstraction available, an atomic model prevents a complete characterization of the software architecture with the diversity and typical heterogeneity of constituents that form a SoS; (iii) even though it supports environment modeling, its inherent syntax does not have any specific mechanism for representing the surrounding environment, which is an important aspect of any software architecture, including software architectures of SoS (ISO, 2011); (iv) it does not offer a mechanism to automatically create stimuli generators; and, finally, (v) since SoS architectures are dynamic, i.e., their constituents are not necessarily known at design-time and they can join or leave the SoS at runtime, it lacks the notion of abstract architectures, i.e., a description of constituents and their potential connections with other constituents, and how they could be adapted at runtime. Even though DEVS supports dynamic reconfiguration, i.e., the modeling and simulation of architectures of SoS that adapt themselves at runtime, the language still lacks support for abstract architectures, thus requiring all constituents that take part in the simulation to be known. Therefore, it is not allowed for a new constituent, i.e., a constituent that has not been predicted at design-time, to join the coalition at runtime. 37 https://www.mathworks.com/products/simulink.html 38 http://www.omgsysml.org/ As observed in this chapter, model transformations have been conducted between different formalisms, and around 20 different formalisms have been proposed and used to describe and simulate SoS architectures and other aspects. However, many of them still lack support for dynamic architectures, emergent behaviors, and environmental modeling, which are essential for SoS software architectures. Next chapter discusses how we associated SosADL models and DEVS models in an approach termed ASAS, which deals with SoS software architecture evaluation considering its inherent dynamic architecture.

CHAPTER 3 ASAS: A MODEL-BASED APPROACH FOR THE SIMULATION AND EVALUATION OF SOFTWARE ARCHITECTURES OF SYSTEMS-OF-SYSTEMS

Systems-of-Systems (SoS) often support critical application domains and exhibit dynamic architectures that, despite their several different configurations at runtime, they should assure a correct operation. Architectural description languages (ADL) have not captured the SoS inherent dynamism or enabled architectural visualizations, which hampers the making of decisions on possible, valid, or best architectural configurations assumed by a SoS during runtime. This chapter presents ASAS, an approach for the automatic generation of simulation models by a model transformation and support to SoS architectural evaluation. ASAS also predicts architectural arrangements that leverage SoS operation and supports the evaluation of pre-determined quality attributes. The approach was evaluated by means of a case study with two different scenarios, namely Space SoS and Flood Monitoring, in which the model transformation and support for the evaluation of SoS behaviors were assessed. ASAS successfully supported the evaluation through automatically generated simulations, enabling the observation of (i) multiple missions in a same SoS, (ii) SoS dynamic architecture, and (iii) the percentage of achievement of each mission in each SoS, with a large set of constituents in both cases.

Chapter 3. ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

Presentation of ASAS Approach

ASAS prescribes the use of SosADL for the documentation of SoS software architectures, DEVS as a formalism for simulation (ZEIGLER; KIM; PRAEHOFER, 2000), and a model transformation that maps both formalisms. SosADL is semantically founded on π-calculus for SoS (OQUENDO, 2016b) and provides all abstractions required for the specification and validation of SoS behaviors. As a matter of fact, the transformation establishes an approach that maps all those abstractions related to SosADL to DEVS. To be executable, a language must have an operational semantics, i.e., a recipe for the interpretation of SosADL statements, so that they become executable models [START_REF] Plotkin | Structural operational semantics the origins of structural operational semantics[END_REF].

Our approach provides such an operational semantics for SosADL through an equivalent denotational semantics, i.e., a formalism that specifies the meanings of statements and expressions in programming languages [START_REF] Stoy | Denotational Semantics: The Scott-Strachey Approach to Programming Language Theory[END_REF]. Model transformations provide the operational semantics for SosADL models through DEVS executable models, i.e., DEVS models have equivalent definitions of the way SosADL models should be executed.

ASAS is structured according to the following steps:

Step 1. Design of a SoS architecture in SosADL: the SoS software architecture must be specified, and, in our approach, this step must be performed using SosADL. A SoS software architecture can be specified in abstract or concrete level. Abstract architectures represent potential connections that can be established between the potential types of constituents to be part of such SoS, as constituents are not necessarily known at design-time. The derivation of concrete instances of an abstract SoS software architecture was investigated in (GUESSI; OQUENDO; NAKAGAWA, 2016). In our approach, we adopted an initial concrete instance that can be changed at runtime for a better fitting of stakeholders' requirements and adaptation to the stimuli received from the environment;

Step 2. Evaluation planning: this step comprises the selection of metrics and aspects to be measured during the SoS architectural evaluation that must be deliberately planned, and include a set of missions to be evaluated through SoS simulations;

Step 3. Execution of the model transformation: after the evaluation plan has been structured and the SoS software architecture has been specified in SosADL, the model transformation can be executed for the production of the DEVS simulation code used for evaluation purposes;

Step 4. Deployment: this step involves the management of the files obtained as the outcome of the transformation, and their deployment in a MS4ME 1 environment;

Step 5. Simulation Execution and Architectural evaluation: this step consists in the launching of the simulation in an MS4ME environment, monitoring through observation 1 http://goo.gl/NmBBuu and possible interaction with the simulation through the exercising of multiple SoS architectural configurations. Data and execution traces are logged in text files during this process to be further examined; and Step 6. Analysis: it consists in the inspection of the execution traces in log files, and drawing of conclusions according to a pre-established set of missions and corresponding metrics.

Correspondences between SosADL and DEVS models

ASAS is based on a DEVS dialect called DEVS Natural Language (DEVSNL) [START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF], which enables the programming of atomic and coupled models expressed as DEVS in a human-like format by tools, as MS4ME. Since DEVS and SosADL are founded upon rigorous formalizations, a transformation should preserve the correspondences between the fundamental concepts. Expressions and values are suppressed in this representation2 . Correspondences were established between both models, as shown in Table 3. SoS concepts are mapped onto SosADL and DEVS, as follows: Connections. A connection can be established for receiving stimuli from an environment, acting on the environment or simply enabling communication between constituents. A communication is established when data are sent by a constituent and received by another. Connections are mapped, in DEVS, into ports (input and output ports). Constituent System. Systems play the role of constituents in SoS. When transformed into DEVS models, constituents become atomic models. They are represented as single entities in the simulation model, and their behaviors are expressed as a state machine. Data Type Declaration. Data types can be specified for the scope of a SoS or constituent or a mediator. Data types and values in SosADL become data types in DEVS. They can be abstract data types (ADT) or simple data, as state variables, and become state variables, global values, or ADT, which can be exchanged in messages among systems in DEVS, since the state transitions in DEVS are triggered by message content. Functions. Functions are blocks of code that can be used within a behavior specification.

Function declarations are converted to functions in DEVS.

Gates. In SoS and SosADL, gates are abstractions that enable the establishment of connections, and connections are abstractions of links between gates of distinct communicating entities. The gate concept is suppressed, and the connections linked to that gate become a DEVS Port. Mediator. Systems are mediated by mediators, which are architectural elements concerned with the establishment of communication links between two or more constituents [START_REF] Weyns | On the challenges of self-adaptation in systems of systems[END_REF][START_REF] Inverardi | Automatic synthesis of modular connectors via composition of protocol mediation patterns[END_REF][START_REF] Inverardi | Automatic synthesis of modular connectors via composition of protocol mediation patterns[END_REF]. When transformed into DEVS models, they follow the same rationale of constituent systems, i.e., mediators also become atomic models. SoS Architecture. An architecture declaration has an intrinsic behavior declaration (coalition), data types, and gates declarations. SoS can be expressed as a combination of architecture, systems, and mediators. Coalitions constitute temporary alliances for combined actions among systems connected via mediators and are dynamically formed to fulfill the SoS mission through emergent behaviors (OQUENDO; LEGAY, 2015). In fact, they guide the way interactions between the constituents will be performed and how their functionalities are explored to accomplish a mission. Such structures are summarized in the coupled model and specify the way they compose the SoS architecture and promote the SoS operation.

Figure 5 shows the approach for the implementation of the solution proposed. An SoS architectural description written in SosADL is verified against the EBNF abstract syntax of SosADL described in Xtext3 . If the SosADL code conforms to the Xtext grammar, the code is submitted as input to an Xtend4 script that represents the Code Generator. A functional code written in DEVSNL is generated as output.

Generation of Constituent Models

Listing 11 shows a simplified code of a mediator specified in SosADL. This code is mapped into an atomic model written in DEVS depicted in Listing 13. The transformation is performed by the code specified in Xtend available in Listing 12. In Listing 11, data types are defined on Lines 2-6. Duties (in this context, only a name for the designation of gates and mediators) with their respective connections are defined on Lines 8-16. The behavior of the mediator is specified between Lines 18 and 23, and shows that the mediator (i) receives constituents coordinates (Lines 19 and 20), (ii) receives data from the sensors (Line 22) and (iii) forwards such data to a gateway (Line 23). This sequence of actions is performed in a loop. Details on the model transformation that maps SoSADL models into DEVS models are available in Anex B.

Patterns for SoS Simulation

Simulations are software that rely on dozens of lines of code and demands techniques for its engineering. Simulation codes are often driven by labeled state machines based on discrete input and output events, as Discrete Event Systems (DEVS) [START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF]. However, some of the instructions are conflicting, and the number of lines of code can be huge, which leads to difficulties and high costs for production and maintainability. Such state machines can reach large dimensions, which makes the production of codes repetitive and error-prone. Under this perspective, the identification of patterns can aid the conception of simulations for SoS, supporting the automatic generation of codes from specifications in a high level of abstraction, such as architectural specifications of software of SoS.

Patterns are standard solutions for recurrent problems that emerge in a domain [START_REF] Vlissides | Design patterns: Elements of reusable object-oriented software[END_REF]. As they enable the reuse of solutions, they can (i) contribute to the trustworthiness expected from SoS, once the reuse of a well-succeeded solution can foster the construction of the correct product, and (ii) reduce costs and time. Since simulation has become increasingly dominant and used by various industries, techniques and methods must be designed for the effectiveness of developers (GRAY; RUMPE, 2016). However, the literature lacks techniques and software engineering methods for simulations in SoS context. SoSE is a novel discipline, and general principles and patterns still must be discovered 5 . DEVS is well-recognized formalism for specification of SoS simulations. In DEVS, constituents operations are specified via a labeled state machine, i.e., a state machine in which transitions occur due to data input or output, or time elapsed. DEVS variants include probabilistic, non-deterministic, and finite deterministic ones. As nondeterminism is unfeasible, deterministic DEVS versions are more common on platforms, such as FD-DEVS (Finite Deterministic DEVS), implemented in platforms as MS4ME 6 .

In DEVS, a constituent system is driven by a state machine specified according to The code of a state diagram in DEVS is based on inputs and outputs, and consists of an arrangement of statements that guide the operation of a constituent. However, System Engineering guides usually do not teach how to group those statements conveniently for the avoidance of conflicts (for example, a hold state also marked as passivate causes conflicts), which may cause fail, error, or interruption of the simulation.

Since DEVS is based on inputs and outputs, we have established one pattern for input and another one for output. The context is the same for both (DEVS simulation models), and recurrent problem changes only in function of the purpose, i.e., input or output. The former prescribes an input causes a transition when, at some state, it receives a datum, whereas, according to the latter, once an output occurs spontaneously (without any triggering event), it should remain in that state for one second (the time can be specified according to convenience), perform the output, and transit to the next state. type of data is received and causes the transition from one state to one and only one another state. DEVS Output rules specify a HoldRule that holds in one and only one state for a pre-determined amount of time. From that state, an output event occurs for the delivery of some data, and the execution flow transits to another state.

Statement/ Statement Table 4 shows the potential conflicts identified:

PS HS IS IT OT ET HS X IS IT X X OT X X
HS-PS: A hold state cannot be concomitantly a passivate state, and vice versa.

Specification of a state as hold and passivate might cause a conflict in a state, as such state should, at the same time, wait for some pre-specified time and also wait indefinitely. Therefore, such combination is unfeasible;

IT-PS: Internal transitions are automatically triggered after an amount of time, e.g., after one second, go to another state. As such, a state should not be specified as a passivate state together with a specification of an internal transition, as it might cause a spontaneous transition at any moment;

IT-ET: An internal transition cannot be concomitantly an external transition, and vice versa, since they have a different nature;

OT-PS: Technically, an output transition is an internal transition. Since a passive state cannot have an internal transition, it cannot have an output transition.

OT-ET: Since an internal transition cannot be an external transition it cannot be an output transition.

Such conflicts must be taken into consideration in the design of robust SoS simulations. Therefore, two patterns have emerged to encapsulate such principles: one that groups codes representing input transitions and their sub-activities involved, and another representing output transitions. Their establishment relied on the classical Gamma's structure [START_REF] Vlissides | Design patterns: Elements of reusable object-oriented software[END_REF], i.e., recurrent problem, context, and solution. Since DEVS is based on inputs and outputs, we have established one pattern for input (Table 5) and

Name

DEVS Input Recurrent Problem Specification of a set of simulation instructions that characterize an input event without conflicts with other instructions. Solution passivate in s < < fromState > >! when in s < < fromState > > and receive << → dataReceived > > go to s < < → toState > >! another for output (Table 6). The context is the same for both (DEVS simulation models) and the recurrent problem changes only in function of the purpose, i.e., input or output.

DEVS Input

According to the DEVS Input pattern, an input will cause a transition when, at some state, it receives a datum. If passivate comes after input instruction when, it might cause a conflict with a hold of a following output instruction. DEVS Input (Figure 6) specifies a PassivateRule that passivates in one and only one state, whose name is represented by a label. From this state, an InputTransition occurs when a pre-determined type of data is received and causes the transition to another state.

DEVS Output

Once an output occurs spontaneously (with no triggering event), the execution flow should remain in a state for one second (this time can be specified according to convenience), perform the output, and transit to the next state. If the next state causes an input, it will be subject to either a passivate instruction, or a new hold. DEVS Output (Figure 6) specifies a HoldRule that holds in one and only one state for a pre-determined amount of time. From that state, an output event occurs, delivering some data, and transiting from one state to another state.

Generation of Coupled Models

In ASAS approach, a SoS architectural description specified in SosADL is verified against its metamodel expressed in Xtext conforms to this metamodel, the code is used as input to an Xtend 8 script that performs the transformation mechanism and returns a functional code written in DEVS. Coupled models in DEVS specify the way constituent systems exchange data with each other to exhibit an emergent behavior. The code of such coupled models systematically specifies the entities involved in the SoS and the way they interact, i.e.,the systems that send data and those that receive them. In SosADL, SoS software architectures are modeled as coalitions.

The correspondences between SosADL and DEVS are summarized in Table 25. Interfaces. The concept of interface encapsulates the communication between two entities (in this case, systems). Consequently, a detailed analysis of an interface should contain (explicitly or not) functions send located in one system element, and receive located in another 9 . In SosADL, interfaces are specified through bindings, which correspond to the list of all combinations between output ports and input ports that establish a communication between two entities in a SoS. In DEVS, each binding is mapped into a coupling, i.e., a statement describes the way information flows between two systems in the SoS.

Sos Architecture. Finally, the software architecture of an SoS is represented as an abstract architecture in SosADL, which specifies a coalition and a set of bindings, and subsequently mapped in a coupled model, which is a set containing a decomposition and couplings.

Listing 16 depicts a SosADL code that represents the specification of a software architecture of an FMSoS. In Listing 16, the software architecture of SoS represented comprises four sensors, one gateway, and four transmitters (types of mediators) (Lines 4 to 12). bindings (Lines 13 to 23) represent the way connections between constituents and mediators are established through gates, and SoS dynamics for data transmission until a gateway. A sensor collects the water level through actuators, encapsulates it with the specific location in which the collecting was performed, and a time stamp. The sensor then transmits the data to the closest mediator, which forwards them to the next sensor, until the gateway has been reached. Source code 3 -Description of an architecture of an FMSoS in SosADL.

1 sos FloodMonitoringSos is { 2 architecture F l o o d M o n i t o r i n g S o s A r c h i t e c t u
In SosADL, a connection is specified as system :: gate :: connection. Indeed, the same gate can hold one or more connections. A unification is established for each pair of sensors with a mediator between them by a unify statement (Lines [15][16][17][18][START_REF] Lara | Formal support for model driven development with graph transformation techniques[END_REF][START_REF]Comparison between related approaches[END_REF][START_REF][END_REF][22][START_REF]A sample of data sent by sensors[END_REF]. According to such statements, an output connection measure from the gate measurement is linked to the input connection fromSensors of the closest mediator. A mediator gathers data from a sensor (Lines 11 to 14) and forwards them to the next sensor. Mediators have an output connection termed as towardsGateway. Such connections are linked to the sensors through an input connection called pass in the gate measurement to receive the data transmitted and forward them to the gateway ( Lines 16,18,20 and 22). Lines 22 and 23 link the output connection of the mediator to the gateway connection called measure. In this case, a mediator mediates a constituent and the gateway. The relay statement establishes the communication between the SoS and external systems, connecting the notification gate of a gateway to an external connection. Each binding specified in SosADL is mapped into a coupling in DEVS. Listing 18 shows the equivalent code derived from the coalition according to the transformation rules specified in Xtend depicted in Listing 17, available in details in Anex B. Line 1 in Listing 18 shows FloodMonitoringSoSArchitecture is formed by the same systems specified in the SosADL code. Lines 2 to 9 show the data exchange among all systems and mediators derived from the specification of the coalition. These lines are created by iterating on the unifying statements. A line is created for each of the unifying connections specified in the SosADL model. Finally, DEVS tool converts that code into an executable simulation model.

According to Listing 18, sensors transmit data to their closest mediator (Lines 2, 4, 6, and 8), which receives them in Lines 3,5,7,and 9 forwards Measure to the next sensors. Since Sensor2 and Sensor4 send their data to Mediator2 and Mediator4, respectively (Lines 4 and 6), the gateway is reached (Lines 5 and9). When data arrive in the gateway, their values are tested against a pre-determined depth threshold. If they are higher, the gateway emits a flood alert. Therefore, the network of exchanged messages between constituents and the flood alert trigger indicate the SoS mission has been accomplished.

A Dynamic Reconfiguration Mechanism for Supporting SoS Dynamic Architectures

SoS architectures are inherently dynamic. Therefore, coupled models generated by the model transformation must provide strategies for dealing with changes that may occur in the software structure. Such changes must be well-defined and the final result must be the same whenever a change is performed, as a change should conduct the SoS to a new functional state. The literature reports well-established sets of architectural changes for single systems software architectures (CAVALCANTE; BATISTA; OQUENDO, 2015). However, when multiple interoperable systems that form a SoS are considered, a gap must still be bridged. This section provides a canonical set of dynamic changes that can affect the SoS software architectures and well-defined steps for their execution.

Dynamic reconfiguration in a SoS is based on four types of architectural changes, namely addition of constituent, deletion of a constituent, substitution of the constituent, and reorganization of the architecture. They are invoked at simulation time by the simulation user and executed by a reconfiguration controller (further explained), which will perform the necessary changes in the architecture.

Addition. Addition of a constituent into the simulation of a SoS software architecture depends on a well-defined set of steps. Firstly, a new constituent must be created and added to the simulation. It must be linked to the SoS for effectively joining it. A constituent is selected in the architecture to be linked to the new constituent. Then an appropriate mediator is instantiated and added to the simulation. Connections between constituents and the mediator are established. The following steps are performed, as shown in Figure 7:

1. The SoS simulation user issues a request to add a particular constituent to a reconfiguration controller. Scene 1 represents the state of SoS at that time. The constituent to be added is C3;

2. Constituent C3 is instantiated and added to the simulation;

3. The controller selects another constituent in the simulation to be connected to C3 (in this case the C2);

4. The controller instantiates and adds an appropriate mediator M2 to the simulation; and

5. The controller adds connections between C2 and C3, which are then mediated by M2.

Remotion. The remotion process is initiated by the user who explicitly chooses a constituent to be removed. Such a constituent sends a unique identifier to the controller, and constituents connected to it are listed. These connections are eliminated and mediators are removed. The controller searches for constituents in the architecture that can be connected to the remaining ones. This important step maintains the SoS operation in progress. At the end of the process, the controller removes the constituent from the simulation, as described in the steps below and illustrated in Figure 8.

1. The SoS simulation user issues a remotion request for a particular constituent. Scene 1 represents the state of SoS at that time. The constituent chosen to be deleted is C1;

2. The connection between constituent 1 and the mediator that connects it with the remainder of the SoS is undone;

3. The binding between mediator 1 and the remainder of the SoS is undone and mediator 1 is selected to be deleted; and 4. Both (C1 and M1) are removed. Substitution. It is performed as a concatenation of the remotion and addition operators.

Steps are followed as shown in Figure 9 1. The SoS simulation user issues a request for the removal of constituent C1;

2. The connection between constituent 1 and the mediator that connects it with the remainder of the SoS is undone;

3. The connection between mediator 1 and the remainder of the SoS is undone, mediator 1 is selected to be eliminated and C2 is chosen to connect C3;

4. Both (C1 and M1) are eliminated, and the user adds the constituent C3 which is instantiated and added to the simulation;

5. The controller instantiates and adds a compatible mediator (M2) to the simulation; and

6. The controller adds the necessary connections to connect C3 with C2. M2 starts to mediate them.

Reorganization. Architectural reorganization process consists in the complete dissolution of the architectural configuration, and reestablishment of new connections between the constituents, which leads to a new operational state of SoS, as shown in Figure 10. The controller removes all connections between the constituents and all mediators, except connections between the controller and the constituents. The controller arbitrarily chooses a constituent in the simulation (random process) and tries to establish its connections with other constituents. The process is repeated until all elements have been connected in SoS, which results in an architecture configuration different from the original one.

The SoS dynamic architecture is managed at runtime by a Dynamic reconfiguration controller (DRC). Figure 41 shows the way DRC interacts with the SoS architecture simulated. DRC is an artificial architectural element that manages every architectural change that occurs. It is added to the simulation to enable the simulation user to perform architectural changes at runtime. From the DEVS simulation model perspective, the reconfiguration controller is an atomic model that (i) adds constituents to the simulation, and the necessary connections and mediators, and relinks the properties of the initial architecture; (ii) removes the constituents of the simulation, connections and mediators, relinking the remaining constituents for maintaining an operational SoS architecture; (iii) removes the constituent and replaces it for another one; and (iv) reorganizes the architecture by removing all connections and mediators and thereafter establishing different mediated connections for creating a new architectural configuration while retaining the initial

Evaluation

ASAS was conceived to support the evaluation of the SoS software architectures functional characteristics, i.e., missions. ASAS enables architects to evaluate SoS behaviors, as well as their dynamic architecture. A case study for investigation on the feasibility of ASAS was conducted. The protocol encompasses the following steps (RUNESON; HöST, 2009): (i) Case study design (Preparation and planning for data collection), (ii) Execution (Collection of evidence), (iii) Analysis of collected data, and (iv) Reporting. Goal-Question-Metric (GQM) technique was adopted for case study (BASILI; CALDIERA; ROMBACH, 1992). Goal: to assess whether ASAS approach enables the transformation, simulation, and evaluation of SoS software architectures in regards to its functionalities, while still considering dynamic architecture. The following research questions and respective set of metrics were established:

RQ1: Can the transformation successfully produce functional simulation models? Rationale. Since the simulation model is automatically generated, soundness of the produced model must be checked. Therefore, a transformation can be considered successful if the simulation runs without errors, and its output is similar to the behavior observed in the real SoS. Metric M1. Simulation failures: given by the number of detected failures during model simulation.

RQ2: Does ASAS support evaluation of SoS and their dynamic software architectures? Rationale. Along the SoS operation, constituents can join or leave the SoS, which pro- RQ3: Is ASAS domain-independent? Rationale. ASAS should be applied to multiple domains to be considered a valid simulation-based evaluation approach for SoS software architectures. Therefore, this question investigates whether ASAS can be adopted to more than one domain. Metric M3. Number of application domains: given by the number of different domains in which ASAS was successfully applied;

RQ4: Can simulation patterns be recurrently applied? Rationale. We proposed patterns for automatically generating behaviors with no conflicting instructions for constituents simulation. Therefore, we aimed at assessing whether such patterns could be broadly reused in different solutions. This research question supports the investigation on the potential of reuse of the solutions proposed. Metric M4. Effectiveness: given by the number of functional atomic models and state machine lines of code effectively generated for constituents in DEVS, which represent the number of times the same patterns were recurrently applied.

ASAS was evaluated in two different scenarios, namely a Flood Monitoring SoS and a Space SoS, so that data from different sources could be gathered for the drawing of conclusions 10 . Context and results are reported in the following sections.

Scenario 1: Flood Monitoring SoS

ASAS was evaluated in a case study on a Flood Monitoring SoS (FMSoS), which is a SoS intended to be part of a smart city. FMSoS monitors rivers crossing urban areas, which pose great danger in rainy seasons, potentially damaging property, threatening lives, and spreading diseases. It notifies possible emergency situations to residents, businesses owners, pedestrians, and drivers located near the flooding area, and governmental entities and emergency systems. Moreover, it is intended to be part of a larger SoS composed of Wireless River Sensors, Telecommunication Gateways, Unmanned Aerial Vehicles (UAVs), Vehicular Ad Hoc Networks (VANETs), Meteorological Centers, Fire and Rescue Services, Hospital Centers, Police Departments, Short Message Service Centers and Social Networks, as described in (OQUENDO, 2016c). Such SoS involves the National Center for Natural Disaster Monitoring, which monitors 1000 cities, with 4700 sensors, including 300 hydrological sensors, and 4400 rain gauges.

Step 1. Design of an SoS architecture in SosADL: FMSoS was specified via SoSADL.

Its architecture was designed to be composed of five different types of constituents, as illustrated in Figure 34, and described below:

1. smart sensors: cyber-physical systems that monitor flood occurrences in urban areas, located on river edges;

2. gateways: devices that gather data from constituents and share them with external entities;

10 R3 and R4 are both answer in Section 3.2.4 during the case study synthesis process. 3. crowd-sourcing systems: mobile applications used by citizens for real-time communication of water level rising. In such systems, the danger level is a pre-defined value between one and six. One represents no risk, whilst six represents a flood effectively occurring. Human users can classify flood risk according to their observations;

Data Preparation. We chose a dataset collected by the actual FMSoS over four days, from November 23th 2015 to November 27th 2015. This interval was important because during these months a number of floods occurred. This enabled us to establish whether or not our simulation results in a diversity of situations. We established a 4-window strategy implemented at the gateways that receive data from constituents to confirm floods. For each set of four data that subsequently arrives, the gateway checks them. For the period studied, the river had an average rise from 35 to 50 cm, depending on the location. Thus, in this context, the threshold of a flood is defined as a rise of 100 cm or more. If at least one pair of data that arrived have both their depth levels at least 100 cm (the threshold established for that city), a flood alarm is triggered. Data were stored in text files and delivered by the stimuli generators along the FMSoS, feeding the simulation. These stimuli generators delivered 1,000 samples for each sensor. Timestamps represented that each data sample was sent every five minutes for each sensor (i.e., 12 samples by hour, 288 per day, totalizing 3,47 days of data simulated). We also considered an amount of 1,000 samples for each crowd-sourcing system that is part of the SoS. We adapted our dataset so to have similar data for stimuli generators for crowd-sourcing systems. For crowd-sourcing systems, the aforementioned scale was used to classify risk between 0 and 6. Zero means that crowd-sourcing systems is not contributing to flood diagnosis. We mapped the height of water in original data to a scale of risk between 1 and 6, 1 being no risk, and 6 being flood effectively occurring. Human users can classify a risk between these values according to what he/she sees. So we could imitate how people would react and behave according to the changes in water level registered before by sensors. Then, we created a dataset corresponding to the data used to feed sensors.

Step 2. Evaluation planning: This step was conducted according to the research questions and metrics established and presented in this Section. A comprehensive data set provided by a real project that combines crowd-sourcing and sensor data for detecting floods was chosen [START_REF] Horita | Development of a spatial decision support system for flood risk management in Brazil that combines volunteered geographic information with wireless sensor networks[END_REF] and data collected from November 23th 2015 to November 27th 2015 (four days), a period of intense rains and floods were used.

Step 3. Execution of the model transformation: After the preparation of all material, the model transformation was run and produced the corresponding DEVS models with no errors.

Step 4. Deployment: All DEVS models were accordingly deployed, and the next step was initiated.

Step 5. Simulation and architectural evaluation: During simulation, we analyzed whether it exhibited the FMSoS behavior, i.e., flood alerts whenever collected data had exceeded a predetermined threshold. 50 different architectural configurations of varied numbers of sensors, crowd-sourcing systems, and gateways and mediators dynamically appearing between the constituents were analyzed. We started with a configuration of four sensors, one gateway, and zero crowd-sourcing systems (besides the necessary mediators).

Progressively, the number of sensors was increased, followed by the number of gateways and crowd-sourcing systems. The Simulation lasted 6 hours and 20 minutes.

Step 6. Analysis: Since the results of the simulation were stored in log files, the corresponding value of the aforementioned metrics could be calculated and compared for the selection of configurations with the best results.

Figure 13 shows a summary of the simulation outcome. We plotted (i) the percentage The data were analyzed according to the aforementioned metrics. Good results were achieved when FMSoS involved many constituents. However, results were not better than using only five constituents. Hence, unless a geographic area to be covered is huge, the use of a small number of constituents can achieve the same results of the use of a large number 11 .

Our approach successfully supported the automatic generation of simulation models for FMSoS specifications, and facilitated the evaluation of different architectural configurations.

Results. Gateways were the critical element for improvements in FMSoS operation.

The results of a SoS architecture composed of four sensors were as good as those of 70 constituents, an support architects towards saving efforts and budget, e.g., during the acquisition of constituents for construction of a real SoS. Such a conclusion would not be drawn at the design stage without ASAS.

RQ1: Can the transformation successfully produce functional simulation models?

Answer. The simulation ran accordingly with no failures. Therefore, transformation was feasible and well-succeeded for this particular context. Further applications should be tested, however, M1 (Simulation failures, given by the number of failures detected during model simulation) currently equals 0.00%.

RQ2: Does ASAS enable architects to evaluate a SoS software architecture considering its inherent dynamics?

A flood alert (mission assessed in this case study) was accurately triggered. Therefore, our results imply a high level of confidence and feasibility. This case was carried out by a SoS architect, who interacted with the SoS simulation, triggering changes for observing the SoS behavior after the architectural change. Despite changes, SoS operation was preserved. Data acquired enable the architect to draw conclusions on the efficiency of different architectural configurations. Therefore, M2.1 (the percentage of well-succeeded SoS behaviors in a diversity of architectural configurations, achieving pre-defined missions) was 100,00% for this case.

Regarding data loss (M2.2), Figure 14 shows the results collected along the simulation execution. Different architectural configurations showed different data transmission efficiency. Figure 15 displays the statistical analysis of the results. The maximum percentage of data received was 77.48%, whilst the average was 55.95%12 50 (M2.3: scale) different architectural configurations with a diversity of constituents were exhibited during architectural evaluation. Indeed, metrics were collected for each different set of constituents. ASAS provided good results and enabled data collection and analysis and supported the decisions on architectural configurations that exhibited the best results. Hence, ASAS supported decisions on different SoS architectural configurations for 100% of the cases (M2.4: support for decision on best architectural configurations). RQ3 and RQ4 were answered as a result for the triangulation process of case studies investigation, being answered later in this section.

Threats to Validity. The threats to validity for Case 1 include the scale of our evaluation, verification of correctness of the transformation rules, and SoS topology. Our solution can scale, as scaling SoS consists in the specification of further bindings in the coalitions in SoSADL and replications of atomic models in DEVS. Regarding transformation correctness, correspondences were established between entities in both models. The results relieved the threat, once ASAS produced functional simulations in more than one situation. Further investigations of topologies and different numbers of constituents will be conducted. Due to the limited time window and suitability of the period for our purposes, the selection of data might show bias. However, as the limited period has a plurality of inputs, including sunny (dry) and rainy days, this bias is aliviated.

Scenario 2: Space SoS with One Satellite

A Space SoS is a SoS composed of constituents in ground and space that accomplish missions such as telecommunication, global position (GPS), weather forecast, Earth and space observation, meteorology, resource monitoring, and military observation. Space SoS can contain approximately 800 constituents (YAMAGUTI; ORLANDO; PEREIRA, 2009). Space systems are usually divided into three main segments, namely Spatial, which is the part placed in orbit (satellites, space probes, space stations); Launcher, used for placing the space instruments and constituents in orbit (rockets, space shuttles); and Ground, which supervises satellite operations. Ground consists of a mission control system, an operation control system, ground stations and data communication networks (WERTZ; [START_REF] Wertz | Space mission analysis and design[END_REF]ECSS, 2008). Each segment materializes one or more systems that have their own attributions. In systems engineering, missions are defined and constituents are articulated for a certain space mission.

Satellites are the main constituents of a space SoS. Each satellite is divided into several subsystems, namely onboard computer, power system, propulsion system, attitude control, and communication system. Satellites are considered in two parts: payload and structural. The payload part, composed of sensors and infrared cameras, assures a system accomplishes the mission. The structural part maintains the satellite in operation. It includes a solar panel, batteries, and reaction control system. The satellite establishes contact only when it passes over the geographic location of the ground station.

The launching of a satellite into space is costly to space systems. The lauching of a CubeSat, an open source architecture of 10cm X 10cm X 10cm, for example, is estimated as $80,000 dollars. Due to such high costs and relevant potential losses, the system is considered critic domain.

Examples of missions for a Space SoS include (i) monitoring of the Amazon forest, taking pictures and observing deforestation; (ii) telecommunication to support Internet Worldwide and TV; (iii) scientific missions, such as study of solar behavior, and exploration of other planets; (iv) river monitoring, for example, in the case of Rio Doce ecological disasters; and (v) detection of tsunamis and hurricanes.

Step 1. Design of a SoS architecture in SosADL: The following concepts are specially important in the space domain.

Telemetry: a technical name given to the information received from the status of the satellite during its passage on the ground stations;

Telecommand: an operation remotely sent to satellites requiring them to perform actions, such as, capturing images or opening of the solar panel.

Space SoS is composed of the following different types of constituents:

1. Command and Control Center (C2): located in São José dos Campos, it generates a telecommand and telemetry packet;

2. Satellite: a synchronous polar orbit satellite that generates images of the planet every 5 days.

3. Ground Station: located in Cuiabá, it involves reception and satellite data transfer (telemetry and telecommand), and temporarily stores image data and satellites tracking;

4. Remote Sensing Data Center: receives records, processes, storage, and distributes images and data from remote sensing; 5. Data Collection Platform (DCP): a device whose electronic sensors measure environmental variables such as precipitation, atmospheric pressure, solar radiation, temperature, air humidity, dew point, wind direction and speed, and detect variations in water bodies levels 13 . In the Brazilian Space Mission, such DCP data are automatically transferred to artificial satellites in the Earth orbit and retransmitted to ground stations to be distributed to end users, thus enabling the monitoring of large territorial extensions and remote areas.

Every mission in a Space SoS is performed according to a meta-process, called Meta-process for Payload missions in Space SoS, as shown in Figure 17 and follows the steps described below:

1. Remote Sensing Data Center requests payload data for Command and Control Center (C2); 2. C2 Center creates the operations(telecommand and telemetry) and schedules their execution; As this is a meta-process, it is conducted by meta-activities and meta-constituents. The instantiation of a concrete process consists in the identification of the constituents and activities that replace those elements in the process.

Missions:

The general mission of such Space SoS is Data Collection. The several types of data collection include water and deforestation index, which can be accessed online. This SoS was designed to undertake two missions, namely (i) Taking pictures (monitor) of the Amazon region, and (ii) Distribution of environmental data collected by Data Collection Platforms (DCP).

We conducted requirements elicitation meetings with an expert from the Brazilian National Institute of Space Research for modeling a software architecture of a Space SoS. The expert helped us understand the SoS structure, its main constituents, and the way they interoperate to achieve the main results expected. A small-scale SoS was modelled with only one mission to be accomplished. After we conducted this pilot study, we planned on the generation and execution of two other simulations. For both, the Space SoS was composed of one data center, one C2 center, and one ground station.

We designed an architecture in SosADL with an initial set of 126 data collection platforms (DPC), and one satellite, representing the current architecture of some Brazilian states. Figure 18 highlights the states involved. DCPs are spread in the territory of each Brazilian state to monitor environmental data. Apart from DCP stations without coordinates and/or available data, the State of São Paulo (SP) has 67 DCP stations. Minas Gerais (MG) has 48 and Rio de Janeiro (RJ) has 11, which totalizes 126 DPC stations. The states of Paraná (PR -12 stations), Goiás (GO -48 stations), Mato Grosso (MT -40), and Amazonas (AM) -due to its importance (81 DPC stations) were also considered, as shown in Figure 18.

The architecture designed was comprised of one data center, a C2 center, a ground station, a satellite, and 126 DPC (SP + MG + RJ) (130 constituents, apart from mediators). DCP are located in land or water (rivers or ocean). The simulation was executed, and DCP from other states (PR, GO, MT, AM) were dynamically included until 307 platforms ( a total of 311 constituents) had been reached, as illustrated in Table 9. This procedure was performed in five steps, one at a time, and originated five different architectural configurations, as shown in Table 9.

Data Preparation. The official website 14 of the Brazilian Institute of Space Research (INPE) offers a query interface that enables access to data from all DPC platforms in operation in the Brazilian territory. To use realistic data, we manually performed the The data used were collected by DCPs for one year. During the simulation, DCP stations of four states were progressively added. Data were separated into 73-day slots (365 days divided into five blocks). As the simulation progressed, DCP from the aforementioned states were added and the simulation was fed with corresponding data, considering the sequence shown in Table 9. The initial configuration involved DCPs from three states, and progressively increased until eight states had been reached. Data were delivered according to the remaining simulation time. In the case of Paraná, for example, 292 days (1 year -73 days) were analyzed, as it was added only after 73 days of simulation were fed. The DCP from Goiás received 219 days of data, and so on. This was necessary to guarantee a homogeneous delivery of data between different states. Otherwise, data from São Paulo state would be over while Amazon would still be receiving remaining data.

Real data was also used to feed orbits trajectories. We gathered data from a real orbit of a Brazilian satellite that covers the territory 15 .

Step 2. Evaluation planning: This study aims at assessing the behavior of the SoS architecture, checking the results as we increased the number of DCP stations until 300, exercising dynamic architecture and its impact on the functionalities provided by a SoS.

Step 3. Execution of the model transformation: Model transformation was executed with SosADL files used as input, producing DEVS simulation models as outcome.

Step 4. Deployment: Simulation models were accordingly deployed in MS4ME.

Step 5. Simulation Execution and Architectural evaluation: Due to the huge amount of data, a more powerful machine was required to conduct the study. Both simulations run in an Intel(R) Xeon(R) CPU E5-2620 v3, with 30 GB RAM, 2 TB HD, in a server running on Ubuntu 16.04.3 LTS.

Step 6. Results and Analysis. The simulation lasted 1,676 minutes (approximately 27 hours), spent 2-3 core processors, and used about 90% of each, whilst IO used the maximum processing power during the whole simulation. MS4ME console was redirected 15 We used an app written in Python for accessing the Satellite data server 16 . A script was created to access and took this data, treat them, and write them in a file once per second, creating a realistic orbit of a real satellite (China-Brazil Earth Resources Satellite 4 (CBERS-4)). Yes. The model transformation produced functional simulation models, with 0.00% simulation failures (M1).

RQ2: Does ASAS approach support evaluation of SoS software architectures considering its inherent dynamics?

ASAS enabled comparisons and evaluations of the entire SoS from a holistic point of view and considering different architectural configurations. Accuracy (M2.1), i.e., the percentage of effectiveness delivered by SoS operation in the different architectural configurations varied from 89.82% to 94.49%. Data losses (M2.2) increased due to the increase in the number of DCP and competition for resource (satellite), from 5.51% to 10.18%. Scale (M2.3) was also examined with variations in the number of constituents up to 311. Results achieved by different architectural configurations were also analyzed through simulations, and confirmed ASAS could support SoS architectural evaluations through simulations (M2.4).

Scenario 3: Space SoS with Satellites Constellation

In this scenario, we aimed at investigating the results of the use of a satellite constellation, i.e., a set of satellites used in association for the improvement in the services provided (as telecommunications). Such constellation is to be soon launched to space17 by the Brazilian Space Agency.

We were concerned to simulate the Space SoS with all DCP stations in Brazil, increasing the number of satellites from one to six (as it will be done soon by the Brazilian Space Agency) to check (i) the level of resource competition, the percentage with which the missions were met in relation to the expected, and (ii) how the increase in the number of satellites improves the performance of a SoS as a whole, reducing the waiting time to receive a requested data from the satellite.

Step 1. Architecture design: We modelled an architecture with a C2 center, a data center, a ground station, six satellites, and 249 DCP stations (a total of 262 constituents). The orbits were defined according to a study on the constellation of satellites [START_REF] Carvalho | CONASAT -Constellation of Nano Satellites for Environmental Data Collection[END_REF]. Maximum and average contact times, maximum and average revisit times, percentage of satisfactory revisits and average number of contacts per day were observed during the preparation for simulation. The configuration chosen was three orbital planes with two satellites in each plane were adopted, as recommended by Carvalho et al. (CAR-VALHO et al., 2013), and shown in Figure 19. In their case, the revisit was less than one hour in 100% of cases. Data Preparation. Data that fed the second simulation were prepared according to the same rationale defined for the first simulation. We obtained a data set from INPE corresponding to data collected between January 1st, 2017 and October 31st, 2017 from each DCP station in operation the entire Brazilian territory. The first SoS architectural configuration for the simulation was composed of all the 249 DCPs in operation and one satellite. A satellite was then added and another 1/6 of the dataset was fed. The same procedure was performed until six satellites had been added. Six satellites were then added for enabling the study of the Space SoS performance. Listing 21 in Appendix C shows an excerpt of the code of a satellite modelled in SosADL.

The satellites used for the second simulation were: a) Sino-Brazilian Satellite of Earth Resources (CBERS-4) (Period: 100.3 minutes); b) Data Collection Satellite 1 (SCD 1) (Period: 99.7 minutes), and c) Data Collection Satellite 2 (SCD 2) (Period: 99.7 minutes). A script was also developed for accessing an external link that provide these coordinates, which enabled a revisit period of 30 minutes18 .

Chapter 3. ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems Step 2. Evaluation planning: This study aims at assessing the behavior of the SoS architecture, checking whether the results exhibited by the SoS can be improved with new satellites being deployed. This endeavor is important, as the Brazilian government intends to launch such satellite constellation in the next years. Dynamic architecture is also intended to be evaluated, increasing the number of DCP stations until 300.

Step 3. Execution of the model transformation: Model transformation was executed with SosADL files used as input, producing DEVS simulation models as outcome.

Step 4. Deployment: Simulation models were accordingly deployed in MS4ME.

Step 5. Simulation Execution and Architectural evaluation: Due to the huge amount of data, a more powerful machine was required to conduct the study. Both simulations run in a Intel(R) Xeon(R) CPU E5-2620 v3, with 30 GB RAM, 2 TB HD, in a server running on Ubuntu 16.04.3 LTS.

Step 6. Results and Analysis. ASAS supported the architectural evaluation for Space SoS according to pre-established metrics, as shown in Tables 14,15, and 16. An increase in the number of satellites reduced the competition between DCP stations, which enabled the SoS to better perform its missions, thus reducing conflicts and concurrency between the DCP for the satellites.

The total simulation time was approximately 34 hours, as shown in As the data feeding was homogeneous (1/6 of the data set for each architectural configuration), data were delivered as follows: 39,895 samples of meteorological data, 61,519 samples of hydrological data, 12,780 samples of agricultural data, and 970 samples of Qagua data, which totaled 115,164 samples processed by Space SoS. Table 14 shows the percentage of such data effectively received in ground stations during the simulation, as well as the respective percentages of the amounts used to feed the simulation through stimuli generators. For all cases, an increase in the number of satellites reduced the competition between missions and DCP stations, and increased the number of data effectively transferred.

Conflicts occurred between missions, i.e., in some cases, the DCP data were not received in the satellite because it was performing another action related to an Amazon monitoring mission, as taking a photograph. In other cases, DCPs were very close geographically. Consequently, only one of them could transmit the data to the satellite. In other cases, the conflict occurred because the satellite was passing a region to take both a photograph and collect some DCP data (the same situation occurred for the telemetry). As DCP-satellite transmission is more elaborate, it requires more time to be performed. Hence, in situations that a satellite passes far from a region to be monitored or passes very fast, a lack of time to capture the photograph can occur. Analogically, the same situation can occur for telemetry. In addition, the satellite takes a photograph of a pre-established region only when it is close enough.

Table 15 shows complementary data of Table 14, i.e., the percentage of data loss. An increase in the number of satellites reduced data losses, as expected.

Table 16 shows the amount of telecommand sent to each architectural configuration, number of photographs captured and not captured, and number of photographs returned and not returned to the ground station.

Table 17 displays the percentage of accomplishment of each mission, according to mission requests shown in Table 16. ASAS accordingly supported a robust analysis of the success of each architectural configuration for the accomplishment of missions, and revealed an increase in the number of satellites was beneficial for the Space SoS, as the percentage of mission accomplishments was increased. Moreover, an increase in the number of satellites improved the trustworthiness of such SoS by increasing the precision with which Space SoS missions were achieved.

RQ1: Can the transformation successfully produce functional simulation models?

Yes. The model transformation was well-succeeded to produce simulation codes for a Space SoS with a constellation of satellites, producing functional simulation models, with 0.00%

Synthesis

We applied triangulation technique (RUNESON; HöST, 2009), which involves taking different angles towards the studied object and providing a broader picture. In this study we used Data (source) triangulation, which consists in the use of more than one data source or collection of the same data in different occasions. Three different simulations were conducted in the context of two different SoS (one for Flood Monitoring SoS and two simulations for Space SoS). For simplicity, we will name them S1, S2, and S3. S1 is the FMSoS simulation, S2 is the first simulation for Space SoS, and S3 is the second Space SoS simulation. A synthesis of results was performed through a comparison between the data acquired from the different simulations. Triangulation enabled us on drawing broad and reliable conclusions about the effectiveness of ASAS approach to support simulation and evaluation of SoS software architectures. Figure 20 shows, respectively, data on simulation duration, maximum number of constituents, number of architectural reconfigurations, and diversity of constituents (number of different types) for each simulation. In simulation S1, we exercised dynamic architecture due to the major number of architectural changes, whilst in S2 and S3 we focused on the number and types of constituents, and the way they might affect the success of the SoS in accomplishing missions.

Simulations were performed so that metrics associated with the architecture, as accuracy and data loss could be collected. Our claim is ASAS supports architects in the capture of data such as accuracy and data loss for assessing a SoS software architecture. Loss of data is complementary to the accuracy. Generally, an increase in elements that receive data such as gateways or satellites, reduces the data loss. Therefore, no correlation between the metrics collected was investigated.

RQ1: Can the transformation successfully produce functional simulation models? Answer. No simulation failure was detected. Hence, this measure was of 0.00% for our case study. RQ2: Does ASAS approach support evaluation of SoS software architectures considering its inherent dynamics?

Yes. ASAS enables observation of even unexpected results, as an equally good result with a small number of constituents and large in the case of flood monitoring; and to confirm previous predictions, such as the fact that increasing the number of satellites improves Space SoS results. Future investigations might also lead to conclusions on the impact of more satellites on other services provided by the Space SoS, such as telecommunication.

We related accuracy (M2.1), data loss (M2.2) and scale (M2.3), as shown in Figure 24, and plotted the largest number achieved by each metric in the three simulations regarding each simulation (S1, S2, and S3) and their respective amounts of constituents (70, 311, and 262). We also considered the difference between mission one and two for simulation S3. Regarding M5 (support for decisions on architectural configurations, i.e., whether the simulation enables collection of data and analysis to decide which architectural configuration offers best results), ASAS supported decisions of the best architectural configurations according to the aforementioned metrics in all cases.

RQ3: Is ASAS approach domain-independent?

Possibly yes, according to M3 (given by the amount of different domains to which ASAS was applied). ASAS was applied to two different domains, namely flood monitoring in a smart city, and space SoS. Initial evidence indicated ASAS is domain-independent, but RQ4: Can patterns be recurrently applied? 3487 lines of code (LOC) were produced by the patterns in Flood Monitoring SoS, including the behaviors of constituent systems and mediators. No conflicting instructions occurred and the systems ran accordingly as predicted at design-time. As the average number of lines for each pattern is 2.5 (2 for one pattern and 3 for the another pattern), patterns were applied almost 1,000 times (M4 for FMSoS = 934). Table 3.3 summarizes the data. In simulation 2, the patterns were also successfully applied during the model transformation for the generation of systems behaviors. Table 19 shows the number of LOC generated for each simulation. No conflicting instructions occurred and the systems ran accordingly as predicted at design-time. Under the same rationale, patterns were successfully applied almost 5,000 times (M4 for Space SoS = 4,896) for automatic generation of simulation models for software architectures of a Space SoS.

Discussion

ASAS approach exhibits robustness, as case studies were conducted in different scenarios, with a large and increasing number and diversity of constituents and architectural arrangements. It also supports collection of data and establishment of conclusions and comparisons between SoS architectural configurations. More than 15 KLOC of functional simulation code were produced (as shown in Tables and19), and this number does not even consider code generated to describe the SoS structure itself. The following observations raised can possibly be generalized for other domains and SoS applications: The co-existence of missions must be accordingly planned. A conjecture that we extract is Mediators can hold the logics to trigger a mission accomplishment., as illustrated in Figure 25 19 for Flood Monitoring and Space SoS. For the former case, a mediator emerges and enables data transmission in the SoS software architecture when the distance between two sensors is shorter than or equal to 50 meters. For the latter, the approximation of the satellite to the DCP station is examined by the mediators, and when it is shorter than or equal to a specific value, the data transmission is enabled. Hence, in both cases, mediators are pivotal elements for the control of data transmission and triggering of a mission. choose and switch structures in SosADL syntax enable the design of those solutions without causing non-determinism in the resulting state machine-driven constituents simulation, as shown in Listing 21, lines 73-112.

Co-existence of missions in a SoS

Another conclusion is if a resource (constituent) in a SoS software architecture is part of more than one mission accomplishment, both the scheduling and the context switching must be implemented in the shared resource. Behavior in satellites followed this rule, as they were specified using a switch structure the enable the alternation between missions being achieved.

Types of Missions

We distinguished two types of missions: a data forwarding mission, and business process-oriented mission. The former type is hold by DCP stations in Space SoS, and sensors in Flood Monitoring SoS. In neither cases, constituents were aware of the destination of the data collected and forwarded. On the other hand, we perceive that the data requisition made by the Data Center is business process oriented, i.e., the activities being accomplished are interdependent and there is (i) an order in which they are executed, (ii) a systematic separation of responsibilities, (iii) many roles being played, and (iv) many institutions involved. Moreover, the mission show a request-response nature. As such, we conjecture that those two types of missions may co-exist in the Space SoS specified; and SoS domain comprehends, at least, two types of missions, namely data forwarding and business-process oriented.. We believe another SoS probably exhibits one, both or more types of missions may co-exist in their architecture, sharing and competing for resources. Strategies must be established for resources scheduling.

Threats to Validity. The following threats were identified for cases 1 and 2: (i) scale: although it is not a problem, since our simulation can handle a larger number of constituents, it hampers data visualization and processing, as a large number of constituents is hardly visualized in a simulation and a more powerful processor would be required. Such problems are reduced as the resulting data are saved in spreadsheets to be properly analyzed; (ii) the order in which changes were performed in the architecture: The order in which constituents were added probably would not influence the final results; (iii) the set of changes proposed for the architecture: substitution and removal of constituents were not performed. Constituents were only added in the context of this study20 . However, in the types of SoS investigated, addition was the main dynamic architecture operator, as removal and substitution were not performed in the real cases that inspired our investigation. This threat, therefore, does not influence our results; Lastly, (iv) correctness of the transformation rules: correspondences were established between entities in both models and the resulting simulation model relieved the threat, as a solution was presented. The same model transformation was successfully applied in three different simulations for two different application domains, which reinforces the claim of the transformation correctness.

Regarding internal validity (FELDT; MAGAZINIUS, 2010), variables and metrics were assigned to the pre-established research questions. We believe the important causal relations were accordingly mentioned and examined. External validity, which comprises the extent to which is possible to generalize the findings, our results exhibit potential for generalization, as we analyzed two different domains, and exploited scale (number and diversity of constituents), besides proposing conjectures related to our findings. About construction validity, ASAS approach adopts simulations that enable architects to carefully examine the casual relationship between the the planning of our study and the observed outcome. We carefully examined the simulation traces to be sure that the observed outcome correspond to the effect we intended to measure. Conclusion validity was not considered, as we did not investigated the statistical significance of our findings.

Related work. Although model transformations from architecture descriptions to another formalism for evaluation purposes is not a new research subject (MICHAEL; RIEHLE; [START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Wang | Executable system architecting using systems modeling language in conjunction with colored petri nets in a model-driven systems development process[END_REF][START_REF] Wang | Executable system architecting using systems modeling language in conjunction with colored petri nets in a model-driven systems development process[END_REF][START_REF] Ge | A data-centric capability-focused approach for system-of-systems architecture modeling and analysis[END_REF][START_REF] Trubiani | Model-based performance analysis of software architectures under uncertainty[END_REF]CAV-ALCANTE;[START_REF] Oquendo | π-ADL: An Architecture Description Language Based on the Higher-order Typed π-calculus for Specifying Dynamic and Mobile Software Architectures[END_REF]BATISTA, 2014;[START_REF] Alexander | Model-based evaluation and simulation of software architecture evolution[END_REF][START_REF] Alexander | Model-based evaluation and simulation of software architecture evolution[END_REF][START_REF] Alexander | Model-based evaluation and simulation of software architecture evolution[END_REF][START_REF] Cavalcante | Statistical model checking of dynamic software architectures[END_REF], most proposals deal with architecture representation and evaluation for single systems or SoS architectures at systems-level, and do not tackle software concern. Many formalisms have been adopted to represent SoS architectures, such as UML, SySML, Colored Petri Nets (CPN), with their inherent advantages and drawbacks. ASAS is a model-based approach for simulation and evaluation of SoS software architectures using a visual approach based on simulations. As such, co-related approaches must be analyzed under the following perspectives: (i) Formalism adopted for describing SoS software architectures; (ii) Formalism adopted for SoS simulation; (iii) Adoption of MBE approaches and model transformations; (iv) Support to SoS dynamic architectures; and (v) Evaluated concern (functional or non-functional). Table 20 shows comparisons between related approaches regarding the aforementioned parameters.

Huynh and Osmundson proposed a systems engineering methodology for performing architecture analysis of SoS, involving process modeling with SysML, the conversion of the resulting SysML models into an executable simulation model for a tool called Extend, and the subsequent analysis via simulation results (HUYNH THOMAS; [START_REF] Huynh Thomas | A Systems Engineering Methodology for Analyzing Systems of Systems Using the Systems Modeling Language (SysML)[END_REF]. However, the drawbacks of SySML were already discussed, besides the limitations about dynamic architectures.

Ackermann et al. dealt with the concept of software architectures in SoS, and proposed a method for architecture compliance checking, as they claim other previous approaches focused solely on structural characteristics and ignored behavioral conformance (ACKERMANN; LINDVALL; CLEAVELAND, 2009). They modeled the desired behavioral specification in UML sequence diagram notation and behaviors were extracted from the SoS implementation, and mapped for the model of the desired behavior. They explore how their approach can be applied to investigate reliability issues in SoS. However, their approach is manual (ours is automatic) and the architecture is represented in a box-and-lines style, which hampers precision in representation. Michael et al. (MICHAEL;[START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF][START_REF] Michael | The verification and validation of software architecture for systems of systems[END_REF]) introduced a mathematical model to tie the non-functional requirements of software systems to their SoS software architecture, and developed an approach for the evaluation of the quality of software architecture in light of meeting the requirements. Three levels of evaluation, namely domain reference architecture, platform-independent architecture, and platform-/technology-dependent architecture were proposed. The authors illustrate a SoS software architecture by means of a hypothetical missile defense SoS that consists of a Command, Control and Battle Management (C2BM) system, a set of sensors, and a set of airborne interceptors. They specify the SoS architecture using UML diagrams, as class and activity diagrams. However, they provided no definition for SoS software architecture, or a method for its evaluation, but only reviewed the literature on methods to be adopted or extended for the Verification and Validation (V&V) of SoS software architectures.

Griendling and Mavris investigated the development of a DODAF-based executable architecture approach to analyze SoS alternatives (GRIENDLING; MAVRIS, 2011). They adopted a discrete event simulation using a Petri Net implementation to examine the expected time to complete missions. They also adopted a combination of Microsoft Excel and MATLAB for creating an executable environment prototype. They model a SoS as a graph represented by an adjacency matrix. However, they only analyze two architectural alternatives. [START_REF] Ge | A data-centric capability-focused approach for system-of-systems architecture modeling and analysis[END_REF]. They document SoS through static models based on SySML, such as activity diagrams, and activities, resources, rules, performers, and locations in a static way under DoDAF framework. They also constructed executable models using ExtendSim (formerly called Extend) as the dynamic simulation platform and ran them to check whether the parts were operating as expected. Their claim is the design of the architecture enables the exploration of alternative solutions, and possible behaviors and potentially reachable states can be predicted. Moreover, every simulation can be viewed as a possible evolution of actual SoS. Their simulation does not address dynamic architectures (as they require multiple simulations to see different architectural alternatives), and no explanation on the way their executable model was constructed is provided. [START_REF] Xia | A model-driven approach for evaluating system of systems[END_REF] evaluated SoS architectures regarding performance and effectiveness, and adopted a model-based approach for transforming system architecture models in Simulink 22 into executable models. Their approach supports measurement of non-functional properties, such as feasibility and efficiency, but it does not consider software architectures (they work on systems level, also addressing hardware and other low-level aspects). They illustrated many SoS architectural viewpoints in conformance with DoDAF, and adopted MagicDraw as the environment for describing the architecture and UML as the basis to represent SoS architecture. They also employed ATL (JOUAULT; KURTEV, 2006)(ATLAS Transformation Languages, which is a model transformation language and toolkit proposed by ATLAS research group based on the QVT (Query/View/Transformation, a model transformation standard proposed by OMG [START_REF] Kurtev | State of the Art of QVT: A Model Transformation Language Standard[END_REF][START_REF] Omg | Meta Object Facility (MOF) Core Specification Version 2.0. Object Management Group[END_REF])) to map architectural and Simulink models. They did not evaluate the success of a SoS in accomplishing missions, and adopted UML with all limitations. ASAS supports the evaluation of functional achievements and adopts SosADL as the formalism. Dynamic architecture is not mentioned in their study.

Tomson and Preden introduced Multi-agent Communication Environment (MACE), an agent-based framework for simulation of complex SoS that uses middleware (TOMSON; PREDEN, 2013). They describe SoS as a heterogeneous network of collaborating agents that strive to improve the performance of the resulting system by harmonizing the behaviors of individual agents. Their method to validate the behavior of a SoS adopts the simulation of the system behavior in a controlled environment. Their canonical constructs are Environment (space and time in which agents act), Agent (an autonomous entity in the environment), Mediator (an independent software layer between the agent, environment and other agents), and Connection (a direct link between agents that describes the 22 www.mathworks.com/products/simulink/ Chapter 3. ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems communication channel). They evaluated their approach using a distributed monitoring system that detects asymmetric threats based on the work done in the scope of the European Defence Agency's program using UAV (unmanned aerial vehicle) and UGS (unmanned ground sensor). They report the simulation according to time units and information packets transferred in the SoS architecture during simulation. It is not clear how functional properties are evaluated, and dynamic architecture is not mentioned.

Fang et al. reported results on evolving SoS architectures to satisfy capability and performance objectives through adding new systems, replacing existing systems, and changing links between constituents (FANG; DELAURENTIS; DAVENDRALINGAM, 2013). They employed Colored Petri Nets (CPN) (a discrete event dynamic simulation tool) to model, simulate and evaluate the existing and evolving architectures, while still considering the cost of architecture evolutions. They included dynamic complexity as a complexity metric for SoS, and claimed an appropriate evolution choice could be achieved through the examination of the tradeoff space between complexity and performance. The authors conducted a literature review and detected five common approaches for SoS executable architecting, which are Markov chains, Petri nets, system dynamics models, mathematical graphs and Agent Based Modeling (ABM). ABM is suitable for representing an environment composed of interactive parties, however it suffers from computational workload. CPN is a formal language in low level of abstraction, while we adopt SosADL, an ADL in high-level of abstraction conceived especially for SoS software architecture context.

Bocciarelli and D'Ambrogio addressed an automatic generation of simulation from SySML to High-Level Architecture (HLA) 23 simulation (BOCCIARELLI; D' AMBROGIO, 2014). They conducted two model transformations: SysML-to-HLA model-to-model transformation, which takes the SysML-based system specification as input and yields the HLA-based simulation model as output; and a HLA-to-Code model-to-text transformation, which takes the simulation model as input and yields the code that implements the HLA-based simulation as output. A distributed simulation (DS) is performed and the results are checking whether or not the system behavior satisfies the user's requirements and constraints. According to such an evaluation, the SysML specification drives the implementation of the system. Otherwise, a system must be redesigned. However, in their approach, they generate code for distributed simulations, which demand a larger number of computer and simulation peers. This is costly than using a single computer, as we are able with ASAS. Moreover, in their approach, constituents must be known at design-time, not covering dynamic architectures, as it is required for SoS.

Guariniello and DeLaurentis evaluate and compare different architectures regarding their reliability and robustness under attack (GUARINIELLO; DELAURENTIS, 2014a; GUARINIELLO; DELAURENTIS, 2014b). They reported an ongoing study for the evaluation of SoS architectures by a tool for Functional Dependency Network Analysis (FDNA) in the aerospace SoS domain. They evaluated the impact of cyberattacks, delivering, as outcome, a number that represents the variation in the operability of the directly affected constituent system, and identifying the critical systems and the critical links with respect to their impact on the overall behavior when cyberattacks occur. The authors claim a future improvement will use an agent based model test bed to validate the inputs required by the methods to analyze specific problems. They do not adopt simulations, which can hamper the SoS dynamics visualization.

Falkner et al. (FALKNER et al., 2016) proposed a change of emphasis from SoS specifications to executable models for the purposes of performance prediction. They developed an environment called MEDEA, which is a MDE-based system execution environment that supports evaluation and performance prediction of SoS. The methodology underpinning MEDEA follows a performance analysis and prediction process, which consists of three phases, namely modelling, execution (simulation), and performance analysis and evaluation. The process is guided by formulating a performance question, such as What is the utilization of constituent UAV?. Th authors model SoS under many views using GraphML, a platform-independent language that supports modelling of interfaces, behavior, and workload of SoS and its constituents. Despite they adopt GraphML to represent SoS architectures, not exactly the SoS software architecture. MEDEA uses the Jenkins continuous integration environment to automate the code generation, compilation, deployment and execution to ensure simulation, reliability and repeatability. Authors evaluate different architectural configurations, but not as a result of changes from another past one. A definition of SoS performance is not given, but they offer a number that measures the utilization related to each constituent to achieve a mission. However, the proposal shows limitations related to: (i) description of SoS architectures (not SoS software architecture), (ii) emulation (not simulation) of performance models above existing middleware and hardware to support early performance evaluation within multiple deployment scenarios, and (ii) lack of evaluation support for dynamic and functional properties. [START_REF] Vierhauser | Reminds : A flexible runtime monitoring framework for systems of systems[END_REF]. They externalized challenges for monitoring system-ofsystems architectures, which include (i) monitoring a SoS at different layers and levels of granularity, (ii) monitoring across different systems with respect to checking global SoS properties, different constituent systems and their interaction, (iii) monitoring of different technologies, (iv) monitoring systems with different speeds, (v) diversity of system requirements and monitors, and (vi) performance of the monitoring solution. They created an entire framework for SoS monitoring from scratch based on Java and C++ and developed a DSL on top of a Java-based incremental checker (no name was given) implemented by Xtext and Xtend. Hence, their framework is co-related to MS4ME environment, for example, with more functionalities. However, they do not work with software architecture concepts, and dynamic architectures, and do not evaluate SoS. [START_REF] Gassara | A bigraphical multi-scale modeling methodology for system of systems[END_REF]BOUASSIDA;[START_REF] Gassara | A bigraphical multi-scale modeling methodology for system of systems[END_REF][START_REF] Gassara | A bigraphical multi-scale modeling methodology for system of systems[END_REF] introduced a tool that supports modeling of SoS architectures through Bigraphs, following the research of [START_REF] Wachholder | Enabling emergent behavior in systems-of-systems through bigraph-based modeling[END_REF]STARY, 2015;STARY;WACH-HOLDER, 2015). Bigraphs (Bigraphical Reactive Systems(BRS) (MILNER, 2009)) is a formal/mathematical theory for modeling systems. Authors claim it has also been applied to capture software architectures and modeling applications for context-aware systems and ubiquitous computing environments; and enables the modeling of SoS constituents through their structural and behavioral characteristics. They use GMTE (a tool for graph transformation and matching [START_REF] Hannachi | A tool for graph transformation and exact/inexact graph matching[END_REF]) and model air cargo SoS and its constituents by agents of a certain structure and behavior. The approach also addresses structural modifications in architecture. However, no evaluation method or simulation has been established.

Apart from SoSADL, several other notations have been used for expressing SoS architectures, e.g. [START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF] UML 24 (semi-formal), SysML 25 (semi-formal), and CML26 (formal). Since UML and SySML are general-purpose languages, they lack support for the specification and validation of dynamic properties of SoS. On the other hand, CML is a formal language especially conceived for SoS formal specification within the context of Comprehensive Modelling for Advanced Systems of Systems (COMPASS) alliance. However, CML does not focus on emergent behaviors [START_REF] Fitzgerald | Model-based Engineering for Systems of Systems: the COMPASS Manifesto[END_REF].

Transformations from other models to DEVS have also been proposed (CETINKAYA; VERBRAECK; SECK, 2012; [START_REF] Gonzalez | Towards an automatic model transformation mechanism from UML state machines to DEVS models[END_REF]HU et al., 2014b). However, no approach has supported the transformation of SosADL descriptions into DEVS models. Considering that, we have established a model transformation approach that takes SosADL models of the software systems constituting a SoS and produces DEVS simulation models. None of the aforementioned approaches cover the requirements addressed in ASAS, as discussed.

Patterns for SoS simulations. Other proposals have explored patterns for simulation in DEVS, however under distinct perspectives (CETINKAYA; VERBRAECK, 2011; HAMRI; MESSOUCI; [START_REF] Hamri | Discrete event design patterns[END_REF]HAMRI;[START_REF] Hamri | On using design patterns for devs modeling and simulation tools[END_REF][START_REF] Éron | Predictability of Sequence Patterns in Discrete Event Systems[END_REF][START_REF] Schulz | Discrete event system specification (devs) and statemate statecharts equivalence for embedded systems modeling[END_REF][START_REF] Schulz | Discrete event system specification (devs) and statemate statecharts equivalence for embedded systems modeling[END_REF][START_REF] Schulz | Discrete event system specification (devs) and statemate statecharts equivalence for embedded systems modeling[END_REF]. Cetinkaya and Verbraeck established an approach for the management of models and metamodels in the simulation engineering (CETINKAYA; VERBRAECK, 2011). They listed a set of properties model transformation rules should maintain to produce reliable simulations. However, they neither tackle SoS context, nor externalize patterns for the conception of a simulation. [START_REF] Hamri | On using design patterns for devs modeling and simulation tools[END_REF] present a specific catalogue of design patterns for DEVS context that addresses problems such as (i) selection of a method based on type of target and type or value of one other variable without hardwiring the selection as a conditional statement or (ii) Changes in constituent behavior, depending on its internal state, without hardwired multi-part conditional code. However, they do not provide details on how to group DEVS instructions for designing constituents behavior, avoiding conflicts between them. [START_REF] Hamri | Discrete event design patterns[END_REF] report behavioral design patterns to design DEVS behaviors to supply DEVS designers with software engineering techniques (HAMRI; MESSOUCI; FRYDMAN, 2013). However, their patterns are only related to state changes. Differently from out proposal, they provide no grouping of instructions as a set of patterns. Jéron et al. investigated prediction of occurrences of a pattern in a partially-observed discrete-event system. They consider a pattern a set of event sequences modeled by a finite-state automaton. The occurrences of the pattern are predictable if any of them are inferred before the pattern is completely executed. They proposed an off-line algorithm that verifies the property of predictability, but did not address patterns for the conception of simulation, rather than for the automatic identification of patterns in DEVS simulations. Shulz et al. also present a mapping involving DEVS (SCHULZ; EWING; [START_REF] Schulz | Discrete event system specification (devs) and statemate statecharts equivalence for embedded systems modeling[END_REF]. They argue that the DEVS formalism is more expressive than that of StateCharts and present a mapping of the two system modeling formalisms promises to combine the benefits of formally well-defined models and a sound tool implementation, as we do. However, they do not externalize any pattern applied in this model transformation as we do.

Final Remarks

This chapter introduced ASAS, an approach conceived as a joint effort of two research groups27 that supports the simulation-based evaluation of functional concerns of SoS software architectures. We explained details on the transformation that maps SoS software architecture descriptions documented in SosADL in DEVS simulation models, and how the resulting models can be used to evaluate different architectural configurations SoS can assume along its life cycle. ASAS enables software architects to identify one or more configurations that yield best results towards achieving the trustworthiness expected from SoS operating in critical domains (GRACIANO NETO, 2017;GRACIANO NETO et al., 2018b). The model transformation adopted in ASAS materializes the SosADL operational semantics, defined in (OQUENDO, 2016a), complementing SosADL models with executable models of SoS software architecture.

Among the contributions from the advances reported in this chapter, we can cite:

1. A model-based approach to produce simulations of SoS software architecture: ASAS enables software architects to automatically produce simulation models with exogenous dynamic reconfiguration, i.e., one of the architectural elements being simulated (also automatically created) is responsible for the management of reconfiguration actions at runtime. Simulations (i) represent the SoS inherent dynamics, (ii) offer a visual approach, (iii) a more precise control over the topology of the architecture, and (iv) how communication is established between constituents. This approach advances the precedent ones by harmonizing static and dynamic views of SoS architectural documentation, enriching the existent approaches based only on static or dynamic models. Moreover, ASAS focuses on SoS software architectures, isolating the software view from hardware and operational concerns (inherent to system engineering approaches), abstracting low-level issues, and automating the production of simulation models from a specification of SoS software architectures in a high level of abstraction; [START_REF] Nielsen | Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions[END_REF]. pected emergent behaviors; (iii) enable the prediction of errors, diagnosing them and permitting corrections; and (iv) provide a visual and dynamic viewpoint, reproducing stimuli the system can receive from an operational environment. Moreover, ASAS possibly enables the exploration of non-predicted behaviors that may emerge at runtime due to some specific set of stimuli. Emergence is a term to denote the study of emergent behaviors in a range of situations. Emergent behavior is a particular SoS characteristic triggered by the reception of stimulus and data exchanged between the constituents, and between constituents and their environment [START_REF] Graham | Nature's Patterns -Exploring Her Tangled Web[END_REF]. Such behaviors are an holistic phenomena that occurs through a certain number of interactions among the constituents that produce a global result that could not be delivered from any one of them in isolation.

4. Patterns for the creation of DEVS SoS simulations: Another contribution refers to patterns to automatically derive excerpts of code representing behaviors of constituents that form a SoS simulation. This solution was recurrently applied during the exploration of different cases and showed potential for reuse. The idea can be generalized and externalized for automatic generation of any discrete-event based simulation formalism, and the model transformation itself can be reused in other contexts;

5. Operational Semantics and Animation for SosADL: Executable models demand an operational semantics, i.e., a structured description of the expected result of each construct of the source language, realizing an entire framework that drives how a model will represent the dynamics of a system. The model transformation conceived also comprises a definition of the operational semantics for SosADL, and as a consequence, originates executable (simulation) models equivalent to the source models. Indeed, simulations are animations for SosADL models. Animations can help one to better understand modeled behaviors. Novices and experienced developers can benefit from the visualization of modeled behaviors provided by model animators.

Model animation can provide quick visual feedback to novice modelers and help them identify improper uses of modeling constructs. Experienced modelers can use model animation to understand designs created by other developers better and faster [START_REF] France | Model-driven development of complex software: A research roadmap[END_REF][START_REF] France | Model-driven development of complex software: A research roadmap[END_REF]. π-Calculus for SoS specifies the operational semantics of SosADL (any language with an operative semantics is executable) (OQUENDO, 2016b). ASAS contributes by defining a denotational executable semantics with DEVS that conforms to the operational semantics defined in π-Calculus for SoS for the subset of SosADL that was implemented. ASAS offers the first execution system for SosADL. Model transformations generate simulations, which comprise the executable semantics for SoSADL, accordingly supporting implementation and validation of SoS operation at design-time.

6. Domain Independence: One of the concerns evaluated in our case study was the domain independence of our solution. We evaluated ASAS using two orthogonally different domains, namely space and urban flood monitoring. For both, the model transformation successfully produced functional simulation models that supported the evaluation of SoS software architectures regarding their functional requirements. Therefore, we claim our approach can be applied to other domains.

Results of this research can open possibilities for the emergence of new research branches and several applications in the forthcoming years. Among such possibilities, we can cite:

1. Industrial simulation and co-simulation: Despite the success of ASAS for predicting SoS behaviors and evaluating SoS software architectures regarding their effectiveness to offer functionalities, the evaluation of some non-functional properties require a more industrial approach. Co-simulation is the name given to the practice of combining two or more simulators for reliably representing real conditions to which a system can be submitted in order for the evaluation of specific properties, as river, sea, wind, and rain simulators, electricity and automotive simulators, or network protocols and cyber attacks simulators [START_REF] Gomes | Cosimulation: State of the art[END_REF]. ASAS shall be extended towards an automatic generation for other simulators, or even to fit the combination of multiple simulators;

2. Continuous Value Delivery for SoS: Most SoS undergo periodic rearchitecting. However, this does not necessarily occur at the 'speed of need [START_REF] Ricci | Considering alternative strategies for value sustainment in systems-of-systems[END_REF].

Value robustness is the ability of a system to deliver stakeholder value in the face of the dynamic world in which the system operates over its lifespan. Sustaining stakeholder value delivery in an operational system is a continual and difficult challenge (ROSS; [START_REF] Rhodes | [END_REF]. ASAS can also be extended to analyze such deliverable value; Solutions and strategies that deal with such issues must be investigated and designed;

5. Methodology for the Validation of SoS Behaviors (including emergent ones): ASAS offers a visual approach for the evaluation of SoS architecture behaviors. However, when the number of constituents and functionalities offered by SoS increases, this visualization is no longer trivial. Then, signals that characterize the emergent behaviors and conclusion of behaviors foreseen in SoS at large scale must be defined so that the conformance between missions and their corresponding emergent behaviors can be checked (GRACIANO NETO, 2016). Therefore, a robust and reliable methodology must be established for the validation of emerging behaviors, and ASAS is an approach upon which this advance can be built.

6. Visual monitoring of SoS dynamics: ASAS supports the simulation of SoS from an operational perspective, i.e., simulation provides a mechanism to visualize how data is exchanged between the constituents during the accomplishment of missions. However, DEVS simulators do not use to support the simulation of constituents movements, for example. A future work shall provide an extension of ASAS to automatically provide a visual simulation of constituents movements over their environments. This would be particularly useful to study dynamics of a constellation of satellites over a territory, or to simulate the movement and interaction of autonomous cars in a smart city.

Next chapter presents a strategy to reestablish the consistency between simulation models and architectural models through a reverse engineering transformation approach.

CHAPTER 4 BACK-SOS: A MODEL-BASED APPROACH FOR RECONCILIATION BETWEEN DESCRIPTIVE AND PRESCRIPTIVE MODELS OF SYSTEMS-OF-SYSTEMS SOFTWARE ARCHITECTURES

As SoS progresses its operation, architectural changes result in several different architectural configurations at runtime. Frequent reconfigurations can quickly degrade the quality of the SoS architecture as it further deviates from its initial prescriptive architecture. This chapter presents Back-SoS, a model-based approach that supports the verification of the conformance between architectural configurations to be executed at runtime and their prescriptive architecture. Back-SoS is complementary to ASAS as, whilst ASAS (presented in Chapter 3) enables us to evaluate many different architectural configurations that arise at runtime regarding their impact on SoS operation, Back-SoS enables the architect to realign, during design-time, the conformance between the prescriptive SoS architectural model with its corresponding runtime version (the descriptive architecture). We demonstrated the feasibility of this approach in an urban Flood Monitoring SoS (FMSoS) and concluded that Back-SoS could bring important support to avoid architecture drift and, as a consequence, to improve the quality of SoS and their architectures.

Presentation of Back-SoS Approach

Back-SoS prescribes a backward model transformation that reconciles consistency between the intended architecture and runtime models. In our approach, SoS execution models are represented using DEVS, which is a notation that supports representation of SoS at runtime, besides supporting architectural reconfigurations [START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF]. In turn, SoS prescriptive models are documented in SosADL (OQUENDO, 2016c). For the context of this chapter, we solve the problem of restoring the alignment between concrete architecture and architectural instance. Other gaps to be bridged and challenges regarding this research area are mentioned in Section 4.3. Back-SoS is illustrated in Figure 26, and consists of the following steps:

Step 1. Model recovery activity and model discovery activity: After SoS simulation starts, a number of architectural configurations can arise. Changes can take place for a number of reasons, which potentially cause inconsistencies between current SoS architectural configuration and models that document its intended architecture. Every change that occurs at SoS architectural level triggers a model recovery and discovery mechanism. Model recovery for SoS software architectures comprises the identification of the architectural elements that are currently in operation at the SoS architecture. After recovery is performed, model discovery is performed, querying the simulation about the existing links between architectural elements (constituents and mediators) after the change is completed. Step 1 produces a DEVS model as an output. As changes can be beneficial or harmful for SoS behaviors, the conclusion of model discovery mechanism triggers the following step;

Step 2. Architectural evaluation: As a SoS can exhibit a diversity of coalitions, a set of parameters is chosen by the software architect for assessing the novel architectural configuration, obtained by changes, in regards to the precedent ones (HOFMEISTER et al.,4.1. Presentation of Back-SoS Approach 107 2007). These parameters can include behaviors that are intentionally designed for a SoS and triggered by specific stimuli (GRACIANO NETO et al., 2017), or non-functional properties, such as performance. Then, an architectural analysis activity takes place (GRACIANO NETO, 2016;GRACIANO NETO, 2017;GRACIANO NETO et al., 2018b). Architects evaluate the new architectural configuration according to the set of parameters chosen, and classify them in beneficial, neutral, or harmful for SoS operation. After evaluating each of them, architects can design strategies for maintaining beneficial SoS architectural configurations in spite of SoS dynamic architecture, and perform the following step;

Step 3. Reconciliation: Between several architectural configurations, SoS architects select one that exhibited best results, such as performance, and functional response. Then, the chosen architectural configuration is submitted to reverse transformation, being updated on the source prescriptive SoS architectural model.

Architectural Drift in SoS architectures

In SoS domain, an architectural deviation is any architectural change that violates the SoS prescriptive architectural model, i.e., the architecture initially intended for a SoS. Hence, a SoS architectural drift occurs due to the introduction of any new design decisions (architectural deviation) in a descriptive model (constituents, mediators, or interfaces) Prescriptive Models of Systems-of-Systems Software Architectures that were not predicted at the SoS prescriptive architecture. Actually, deviations often occur in SoS architectures, as any new constituent that join a SoS will change its current architectural configuration. Changes can be beneficial or harmful. But, as software architects are concerned to build architectures that offer the best results for their clients, beneficial architectural configurations are intended to be propagated to the official architectural documentation materialized by the SoS prescriptive architectural model. Hence, preventing such an architectural drift requires reestablishment of consistency and synchronization between the descriptive SoS current model and the correspondent prescriptive model documented using an ADL.

Cavalcante et al. defined a canonical set of architectural changes that can arise at any type of dynamic architecture, which are (CAVALCANTE; BATISTA; OQUENDO, 2015): insertion of architectural element, removal of architectural element, substitution of architectural element, and rearrangement of the entire architecture establishing, hence, new connections. In SoS, the basic architectural elements are constituent systems, mediators, and coalitions (OQUENDO, 2016c;[START_REF] Nielsen | Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions[END_REF]. Then, these aforementioned architectural changes could be rewritten for SoS domain as: insertion of new constituent, removal of constituent, substitution of constituent, and coalition rearrangement.

This group/set of architectural changes could also be applied to mediators that form the SoS architecture. As a matter of fact, considering that all constituent systems interoperate with others solely by means of a mediator, any of these operations on constituents cause identical operations on their respective mediators, i.e., deleting a constituent necessarily requires removal of mediators attached to it; and adding a constituent also requires adding mediators to connect the new constituent, allowing its participation in the coalition.

Model Recovery and Discovery Mechanism at SoS Concrete Architectural Level

For simulation purposes and for our context, model recovery and discovery are performed at the same step. Java objects are available in MS4ME environment to support access to the simulation model that represents the running SoS. Figure 27 illustrates a simulation of a small instance of a SoS composed by smart sensors, mediators, and gateways, and mechanisms to reconfigure and discover models in DEVS simulations. The strategy that we designed consists of adding two additional structures in the SoS architecture simulation: one is dynamic architecture controller, which supports dynamic architecture during SoS simulation in DEVS, and a model discovery mechanism (MDM), which accesses the simulation at runtime to map the current SoS architecture to SosADL. When an architectural change occurs or is required in a SoS simulation, the SoS dynamic architecture controller performs such change (for instance, removal of a constituent). After that, the controller calls the model discovery mechanism. MDM accesses the Java simulation object managed by MS4ME, reads the coupled model, and maps back the simulation model to SoSADL model, updating the original specification. Listing 5 presents excerpts of code written in XTend that automatically generates a mechanism for model discovery in DEVS SoS simulations. Listing 5 shows a method called mSyncModel, which is responsible to deploy a Java method (syncModel) within the Model Discovery Mechanism (MDM) to write the SosADL model that corresponds to the current running architectural configuration. Line 6 creates the file in which the new SosADL model will be written. Line 8 writes the definition of SoS gates (as Lines 1-12 in Listing 7). Lines 10-13 write the definition of constituents within the coalition specification (Lines 13-21 in Listing 7). Lines 16-18 writes the bindings, which correspond to all combinations between output ports and input ports that establish a communication between two systems (Lines Source code 5 -Model discovery mechanism.

Architectural Evaluation

Step 2, architectural evaluation is performed using an approach termed ASAS (A Model-Based Approach to Simulate and Evaluate Software Architectures of Systemsof-systems) (GRACIANO NETO et al., 2018b), initially defined in Chapter 3. ASAS approach supports SoS simulation and architectural evaluation of different configurations of SoS software architectures. After a simulation model for a SoS software architecture is produced, such model is executed, and analysis of functional and non-functional properties is performed to choose between the diverse architectural configurations that emerge at runtime due to changes.

This step consists of the following parts:

Producing a simulation model for a SoS software architecture;

Monitoring simulation execution;

Assessing SoS architecture according to a pre-defined set of metrics.

ASAS methodology is applied herein as a means for supporting the evaluation of the new architectural configuration that emerges from Step 1 (model recovery and discovery), assessing whether it exhibits better results than the precedent one. If yes, reconciliation step is triggered to be performed.

Reconciling Descriptive and Prescriptive SoS Software Architectures

To establish Back-SoS, we adopted mappings between DEVS and SosADL metamodels, as presented in Table 25. In DEVS, a coupled model specifies how constituent systems exchange data between themselves. The code of such coupled models systematically specifies which entities are involved in the SoS and how they interoperate, i.e., which systems send data and which systems receive such sent data. In SosADL, SoS software architectures are modeled by a concept termed coalition. Coalitions represent a temporary alliance among constituents that can be dynamically formed at runtime to fulfill the SoS mission through emergent behaviors. Mediators, in turn, are architectural elements concerned with establishing communication between two or more constituents) [START_REF] Weyns | On the challenges of self-adaptation in systems of systems[END_REF][START_REF] Inverardi | Automatic synthesis of modular connectors via composition of protocol mediation patterns[END_REF][START_REF] Inverardi | Automatic synthesis of modular connectors via composition of protocol mediation patterns[END_REF]. output ports and input ports that establish a communication between two systems. In DEVS, each one of the bindings is mapped into a coupling, i.e., a statement that tells how information flows between a pair of two specific systems in the SoS.

Sos Architecture. Finally, the SoS software architecture is represented as a concrete architecture in SosADL, which specifies a coalition and a set of bindings, and mapped subsequently in a coupled model, which is a set of a decomposition and couplings.

For exemplification purposes, our following listings present excerpts of real code of a software architecture of a Flood Monitoring and Emergency Response SoS (FMSoS). Flood Monitoring and Emergency Response SoSs address the problem of flash floods, which raise critical harms in different countries over rainy seasons. This becomes particularly critical in cities that are crossed by rivers (OQUENDO, 2016a). This SoS involves the National Center for Natural Disaster Monitoring, which monitors 1000 cities, with 4700 sensors, including 300 hydrological sensors, and 4400 rain gauges. We will use a subset of this Flood Monitoring and Emergency Response SoS, which is itself an SoS, i.e., the Urban River Monitoring System, henceforth, FMSoS (GRACIANO NETO et al., 2017). Such SoS includes wireless river sensors, telecommunication gateways, unmanned aerial vehicles (UAVs), Vehicular Ad Hoc Networks (VANETs), Meteorological Centers, Fire and Rescue Services, Hospital Centers, Police Departments, Short Message Service Centers and Social Networks. For this context, we focus on smart sensors, which are fixed smart cyberphysical systems monitoring flood occurrences in urban areas, located on river edges. In that SoS, such sensors are responsible by collecting data from the river (such as the water level), and forwarding such data through mediators until gateways, that can deliver data for specific purposes of public authorities.

Listing 6 shows a coupled model that represents the current state of a SoS simulation that can be discovered and originate a correspondent SoS software architecture specification in SosADL. Sensors in Listing 6 transmit data to their closest mediator (Lines 2,4,6,and 8). These mediators receive such data in Lines 3, 5, 7, and 9 forward them to the neighbor sensors. Since Sensor2 and Sensor4 sent their data to Mediator2 and Mediator4 respectively (Lines 4 and 6), the gateway was reached (Lines 5 and 9). When these data arrive at the gateway, their values are tested against a pre-determined depth threshold. If they are higher, the gateway emits a flood alert. Thus, the network of exchanged messages between constituents and the flood alert trigger indicate that the SoS mission, i.e., producing flood alerts, has been accomplished by these constituent system.

1 From the top perspective , W ns M o n i t o r i n g S os A r ch i t ec t u re is made of Sensor1 , → Sensor2 , Sensor3 , Sensor4 , Gateway , Mediator1 , Mediator2 , Mediator3 , → and Mediator4 ! 2 From the top perspective , Sensor1 sends Measure to Mediator1 ! Listing 7 presents a SoS architectural specification in SosADL. A SoS architectural specification has a set of gates (Lines 3-10), and a coalition (Lines 12-22). Coalition is the name given for the arrangement of constituents that form a specific architectural configuration. As such, a coalition has a set of constituents, and bindings, i.e., their interfaces and how constituents are connected to each other (Lines 22-32). Listing 7 shows the result achieved by applying Back-SoS in a DEVS simulation model, obtaining a SosADL model as output, as shown in Listing 6. Once the SoS architectural instance (SosADL description of a SoS software architecture intance) is reconciled with current SoS concrete architecture (DEVS simulation model), it is necessary to check whether the novel architectural instance is still adherent to the original abstract architecture. This activity is explained in the next section.

Mechanisms to Check Conformance between Abstract and Concrete Software Architectures

A SoS abstract architecture comprises a set of the types of constituents that can compose a SoS software architecture. Hence, an abstract architecture specification involves only the candidate type of constituents that are allowed to join and be part of a SoS, and the potential connections that can be established between them. Listing 8 depicts an example of an abstract architecture of a SoS documented in SosADL (OQUENDO, 2016a). As shown in such listing, a coalition may involve possibly many sensor constituents, exactly one gateway constituent and possibly many transmitter mediators. The abstract architecture specification does not specify which constituent systems will exist at runtime, but simply which are the possible systems that may exist and which are the required conditions for forming a coalition among the systems identified at runtime to participate in the SoS (OQUENDO, 2016a).

1 architecture W n s M o n i t o r i n g So s A r c h i t e c t ur e () is { . . . // m u l t i p l i c i t i e s are 'one ' , 'none ' , A mechanism to check conformance between concrete architectural instances of a SoS and its associated abstract architecture can be manual or automatic. Essentially, checking the conformance of an architectural instance to an abstract architecture involves assessing whether there is any type of constituent that was not predicted and that currently composes the SoS architecture, and whether there exist, in the current architectural instance, any association between two types of constituents that was not originally specified.

Evaluation

We conducted a case study to investigate whether Back-SoS model transformation is feasible, i.e., if it is possible to update the SoS architectural prescriptive model considering the current descriptive SoS architectural model. Case study execution plan: We evaluated Back-SoS approach using FMSoS. Rivers that cross urban areas represent great danger to the population in raining seasons, often causing flash-floods that may damage properties, businesses, and spread diseases. The FMSoS used to evaluate our approach is composed of smart sensors that use software to monitor the occurrences of flooding in urban areas, and crowdsourcing systems that enable the population to communicate threats of flood while they walk or move in the city. The FMSoS used can trigger a single emergent behavior: flood alert. Smart sensors are scattered along the river at a regular distance and their communication is mediated by transmitters between them. Data collected by each sensor are transmitted to a gateway that can emit an alarm for the public authorities when it detects a flooding event. Crowdsourcing systems are installed in citizen mobiles and can also communicate floods or increasing in the water level. Case study execution plan: We evaluated Back-SoS approach using FMSoS. Rivers that cross urban areas represent great danger to the population in raining seasons, often causing flash-floods that may damage properties, businesses, and spread diseases. The FMSoS used to evaluate our approach is composed of smart sensors that use software to monitor the occurrences of flooding in urban areas, and crowdsourcing systems that enable the population to communicate threats of flood while they walk or move in the city. The FMSoS used can trigger a single emergent behavior: flood alert. Smart sensors are scattered along the river at a regular distance and their communication is mediated by transmitters between them. Data collected by each sensor are transmitted to a gateway that can emit an alarm for the public authorities when it detects a flooding event. Crowdsourcing systems are installed in citizen mobiles and can also communicate floods or increasing in the water level. Case study execution plan: We evaluated Back-SoS approach using FMSoS. Rivers that cross urban areas represent great danger to the population in raining seasons, often causing flash-floods that may damage properties, businesses, and spread diseases. The FMSoS used to evaluate our approach is composed of smart sensors that use software to monitor the occurrences of flooding in urban areas, and crowdsourcing systems that enable the population to communicate threats of flood while they walk or move in the city. The FMSoS used can trigger a single emergent behavior: flood alert.

Smart sensors are scattered along the river at a regular distance and their communication is mediated by transmitters between them. Data collected by each sensor are transmitted to a gateway that can emit an alarm for the public authorities when it detects a flooding event. Crowdsourcing systems are installed in citizen mobiles and can also communicate floods or increasing in the water level.

Scenario: A simulation model was produced by a DEVS expert from an initial SoS architecture model. As simulation proceeds, SoS architecture changes due to addition, removal, and substitution of constituents, besides rearrangement of the entire architecture. To make the SoS software architecture specification sustainable, it is important to maintain the runtime architectural configuration synchronized with the source architectural specification. Then, we established the following research question: Research Question: How efficient is Back-SoS approach to maintain the synchronization between a SoS concrete architecture at runtime and its original architectural instance model? Rationale: As we established a reverse model-based approach to reconcile descriptive and prescriptive SoS architectural models, we want to assure that our approach is successful in its intended purpose in regards to the relations between concrete architecture and architectural instance 1 . This research question evaluates the correctness of the model transformation to generate the expected outcome.

Metrics:

The following metrics were established to evaluate our approach: M1 -Correctness: Number of resulting SoS prescriptive architectural instance models correctly extracted from the simulation model. Correctness is assessed via manual inspection. M2 -Mutation coefficient: Aiming at assessing the degree in which changes were being performed across the architectural reconfigurations, we defined a mutation coefficient (mc), i.e., a rate that represents the similarity between the original model in SosADL and

1 Correspondences and automatic matching and reconciliation between architectural instance and abstract architecture at prescriptive model level is not matter of investigation for this case study.

the current version obtained from the current architectural configuration originated by the reverse transformation. This coefficient measures how many lines are different between two models, and divide by the total amount of lines of the larger model. The more similar these models are, closer to one is the coefficient value. The more distant these models are, closer to zero is this value. This metric was established to ensure that there was significant difference between the initial architectural configuration and those arising from the dynamic architecture.

Method: To perform such investigation, we followed Back-SoS steps described in Section 4.1, which involves 1) model recovery and discovery after changes on SoS simulation model, 2) architectural evaluation, 3) reconciliation, and 4) architectural consistency checking.

Reporting

Context Settle: We specified an initial version of a FMSoS software architecture with a configuration structured with four sensors, four mediators, and one gateway, as illustrated in Figure 28. Considering a first architectural version of a FMSoS software architecture, we performed a well-defined set of changes. We added one sensor per time (and the corresponding mediators), until reaching a set of 30 different sensors in the SoS architecture, resulting in 26 different architectural configurations. After that, we increased the number of gateways until reaching ten. Next, one crowdsourcing gateway was added. Lastly, crowdsourcing systems were added until 20, and crowdsourcing gateways until 9. At total, 65 different architectural configurations were obtained due to architectural changes.

We performed a set of 65 architectural changes in FMSoS simulation. Each change originated a new architectural configuration of the simulated SoS as outcome. As such, we performed the procedures below for each one of the architectural configurations. It is important to highlight that architectural evaluation is not the focus of the approach reported herein. Hence, since the aim of this evaluation is to assess the model recovery, discovery, and reconciliation mechanisms, architectural evaluation was not performed and every change performed in the SoS simulation model was propagated to the SosADL model in order to exercise the aforementioned mechanisms.

Our investigation involved seven SoS software architects: one that designed and implemented the model discovery, recovery, and reverse transformation solutions (SA1); one that specified the initial architectural configuration in DEVS simulation models (SA2); one to execute and monitor changes in the SoS simulation model during its execution and to report on model recovery and discovery mechanism (SA3), one to perform the reverse model transformation execution (SA4), and three SoSADL experts to perform a peer-review on the SosADL models originated from the reverse transformation (SA5, SA6, and SA7). We report below the results obtained during the conduction of the well-defined steps.

Step 1. Model recovery and discovery: SA1, SA2, and S3 worked together on this activity. SA1 and SA2 observed the FMSoS simulation while SA3 was performing changes in the simulation model. Every time a change was performed, a new architectural configuration emerged as a result. SA1 and SA2 observed if the FMSoS maintained its operation despite the change performed. As the dynamic reconfiguration was linked to the MDM mechanism, every time a change was performed, the MDM mechanism was triggered to be aware of the new architectural configuration acquired by such SoS. SA3 monitored the outcomes of such process. Model recovery mechanism addressed the identification of the current operational architectural elements at the SoS architecture. After recovery was performed, model discovery mechanism was performed, querying the simulation about the existing links between architectural elements (constituents and mediators) after the change is completed. As an outcome, a new DEVS simulation model is produced as output, being submitted to the reverse transformation;

Step 2. Architectural evaluation: This step is intended to be performed before architectural reconciliation. However, as the aim of this evaluation was to exercise MDM mechanisms and reverse transformation, this step is suppressed from this evaluation;

Step 3. Reconciliation: As model recovery and discovery was completed, and SA1, SA2, and SA3 agreed about the correctness of results from Step 1, SA4 performs the reverse transformation. This step materializes the reconciliation between DEVS current model and SosADL prescriptive architectural instance. Currently, an entire new SosADL model is produced as outcome, conducting to step 4; The procedure described above was performed 65 times, as 65 architectural changes were performed during this investigation. Results are discussed, as follows.

Results. Table 22 shows the results that document changes between some of the architectural configurations (difference of only one sensor) 2 . Each line shows the number of the architectural configuration, the amount of sensors, gateways, and crowdsourcing systems (CS) that form such SoS architecture, and the mutation coefficient (M2).

A single constituent model for representing a sensor in a simulation (in DEVS) has around 70 lines of code (LoC). A mediator holds 53 LoC, a gateway has 57, and a crowdsourcing system has 65 LoC. Mediators for crowdsystems have 39 LoC, and gateways for this crowd systems hold 49 LoC. Adding the amount of the code necessary to specify their interoperability links (30, for the first architectural configuration), a simple simulation After the architectural changes were performed, we manually inspected the resulting models. We concluded that for all reverse transformation uses, our model transformation was effective to automatically generate a SosADL model totally adherent to what was expected as a result, i.e., an equivalent form of the current SoS architectural configuration at runtime that is in conformance with the SoS abstract architecture.

Figure 29 shows the resulting code obtained through applying the reverse model transformation to the instance number 2 (#2) shown in Table 22. Over the initial simulation model (#1), a new sensor was added, creating a new architectural configuration. As the dynamic controller is triggered to change the architecture, the Model Discovery Mechanism is called to extract an updated SosADL model version, which is termed WnsMonitoringSosArchitectureREC1.sosadl. Figure 29 depicts such SosADL resulting code highlighting the parts that were added as result of the reverse transformation.

4.2. Evaluation 121 q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q 0 10 20 Moreover, we also plotted a chart to show the relation between the number of constituents and the differences between the resulting SoS architectural model in regards to the initial version. This chart is shown in Figure 30. X axis shows the identifier of the architectural model, whilst y-axis shows the mutation coefficient for each architectural instance. The lower the mutation coefficient, the greater the change of the model than the current one. The downward curve shows mutation coefficient number decreasing contrasting with line that expresses increasing in the number of constituents. In parallel, Figure 31 depicts a box plot that represents the average of mutation coefficients. Outliers are almost 1 and almost 0, showing configurations one and eight in Table 22. The average is close to 0.2. As this is a value close to 0, this means that the mutation rate was predominantly high, showing consistent differences between the initial architectural configuration (that conformed to the initial version of the prescriptive model) and the resulting architectures derived from the dynamic architecture reconfiguration at runtime. Hence, we can affirm that M1 (correctness), for this case study, was 100%, despite the high degree of mutation achieved by the 65 different architectural configurations obtained during the study. This means that for all reverse transformations executed over the 65 different architectural models obtained from the MDM execution, correct SosADL models were obtained and their correctness was attested by a manual cross-reviewed inspection conducted by three software architects. Then, we can assume and answer the arisen RQ, affirming that Back-SoS approach is well-succeeded to maintain synchronization between a SoS architectural instance and its corresponding concrete architecture at runtime. We discuss our findings as follows.

q q q q 0.2

Discussion

In our investigation, we exercised addition of constituents, as Back-SoS approach is concerned to model recovery, discovery, and reconciliation mechanisms. A priori, established mechanisms are not even aware of the operation that was performed to cause an architectural change and trigger their action, as such mechanisms are only concerned to support updating of SoS architectural specification. As a matter of fact, the change performed to the SoS architecture at runtime was not an issue for Back-SoS approach, as the reverse model transformation only took the current configuration of the runtime architecture and generated, a corresponding SosADL architectural model, as outcome. However, further investigation still must be performed on other operators.

In our approach, Back-SoS is intended to be used when the result of an architectural evaluation over a SoS change shows that the new configuration is potentially beneficial by offering new features, new business exploration opportunities, or even resource savings or better performance, such as faster response time or reduced energy costs to perform an action. Due to that, we have included in our approach a step of architectural evaluation, since we believe that reverse transformations will not be performed deliberately without any criteria. Moreover, not all changes need to be or will be propagated to the architectural specification. Actually, behavior correctness is supposed to be assured using an architectural evaluation approach. In addition, in previous investigations (GRACIANO NETO, 2016;GRACIANO NETO et al., 2016;GRACIANO NETO et al., 2017;GRACIANO NETO et al., 2018b), we show how the architectural evaluation of a SoS can be conducted using simulations as a platform. However, since the SoS architectural evaluation is not the focus of this chapter or the assessment reported herein (apart from space constraints), we have not explicitly included this step when reporting our results. Indeed, we did not solve all the problems related to architectural erosion in SoS software architectures. We make up important contributions on such topic and, in parallel, we open a novel research branch for software engineering of SoS. Deviations in SoS are very common due to the high dynamism expected of this type of system, especially when considering systems such as smart cities, in which cars and people can enter and leave the city carrying their constituents, and making the architecture highly dynamic. In cases where it will be worth evaluating whether changes are beneficial or maleficent for SoS operation, an in which changes must be propagated to the architectural documentation, we offer insights of solutions, gaps that must be bridged, and mechanisms to model recovery, discovery, and reconciliation via reverse model transformation. Considering this, we can not disregard the advances and contributions brought by our approach and reported in this chapter, despite the numerous challenges and gaps that still remain.

Threats to Validity. Threats to the validity of our results include: (i) scale (external validity and generalization potential), which we considered it was covered, as we extended our results to 65 different architectural configurations, reaching 120 constituents in a same SoS model. Further investigations with more constituents must be carried out; (ii) bias in construction validity: the mutation coefficient was established as a means of comparing the differences between the seed architectural model and those ones resulting from the architectural changes. The selection of such metric could be seen as a threat. However, we established this metric inspired on data clusters method to group data and see differences between groups. As we treat architectural models as groups of data, this threat is relieved by the solid results that are often acquired from the adoption of such approach;

(iii) bias during inspection is also a threat, as we performed manual inspections in all the resulting models of the reverse transformation. However, this threat was relieved by a careful and long inspection, guaranteeing that errors and tiring did not bring any mistake for our analysis. Besides, we also applied Back-SoS to regenerate the simulation model from the architecture recovered in every resulting model. This also relieved this threat, generating functional simulation models in all the cases; (iv) transformation correctness: this is a recurrent problem in model-based software engineering solutions. To relieve this threat, we carefully checked the transformation rules established, and whether the correspondences between models were being preserved. Then, this threat was reduced; finally, (v) architectural changes set: we only performed the addition of constituents in this study. Substitution, removal, and rearrangement were not investigated.

Related Work. In 2014, a Systematic Literature Review (SLR) was carried out to investigate how model-based practices have been applied to engineer SoS [START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF]. From that SLR, two studies reported reverse transformation approaches. In one of them, [START_REF] Tu | Harmonized and reversible development framework for HLA based interoperable application[END_REF][START_REF] Tu | Harmonized and reversible development framework for HLA based interoperable application[END_REF][START_REF] Tu | Harmonized and reversible development framework for HLA based interoperable application[END_REF] reported an ongoing research and illustrated how transformations can be used only to generate constituents software code (not for SoS software architecture as a whole) and how to apply model-based software engineering (MBSE) to perform reverse engineering over legacy enterprise information systems, with coverage of interoperability issues, forming a class of SoS known as Systems-of-Information Systems (SoIS) [START_REF] Yahia | On the move to meaningful internet systems: OTM 2009 Workshops[END_REF]. [START_REF] Bruneliere | Modisco: A generic and extensible framework for model driven reverse engineering[END_REF] also report a reverse engineering that is executed by a model discovery mechanism, motivating an automatic update of the source model in execution time for software-intensive SoS. Barbi et al. discuss the generation of configuration and deployment code, and models from code as well, and is the only one study which really performs both kinds of transformations (forward and backward), but only these configuration and deployment aspects are generated [START_REF] Barbi | A model-driven approach for configuring and deploying systems of systems[END_REF]. However, for all the aforementioned related work, their notion of SoS does not include dynamic architecture, emergent behavior, abstract architectures, and other essential features of software-intensive SoS.

Other approaches, including manual and bidirectional approaches such as graph transformations, could be used to solve the problem of synchronizing SoS architectural specifications (prescriptive architectures) and their correspondent runtime configurations (descriptive architectures). However, manual approaches would suffer from the low, repet-itive, and error-prone task of manually transforming the current runtime architectural configuration to SoS architectural specification, besides checking conformance between models. In turn, Bidirectional transformations (BXs) provide a mechanism for maintaining consistency between two related models, one referred to as the source and the other as the view [START_REF] Cheney | On principles of least change and least surprise for bidirectional transformations[END_REF]. A bidirectional transformation consists of a pair of transformations (a forward and a backward) that satisfy round-trip engineering laws. Bidirectional programming languages have been designed to aid the user in writing bidirectional transformations, with which the programmer only needs to write one program that can be interpreted either as get or put, and the two interpretations are guaranteed to be well-behaved (KO; ZAN; HU, 2016). However, such approach still presents some pitfalls, as it is not totally mature yet, specially considering applying that for large scale context as SoS applications domain.

De Silva and Balasubramaniam (SILVA; BALASUBRAMANIAM, 2012) presented a comprehensive survey on how to control software architecture erosion and techniques for architectural restoration, covering methods for recovering and reconciling an eroded architecture with its intended architecture. They highlight techniques and tools for reconciling software architectures of single systems, such as (i) adaptation of the running software architecture to the first one by semi-automated changes; (ii) refactorings, and pattern-based approaches; and (iii) architecture discovery, which consists of extracting the architectural model from a running system. However, they highlight that their survey did not identified architecture discovery methods that are specifically geared towards addressing architecture erosion. Moreover, no one technique is mentioned for SoS context.

Other options of ADL and simulation formalisms were also analyzed about the suitability to represent SoS and to bridge the gap between descriptive and prescriptive models in SoS. However, current ADL lack mechanisms to capture uncertainty, dynamism, and potentially undesired behaviors that can emerge from SoS architecture configurations [START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF], which can hamper the prediction and guaranteeing of SoS correct operation. Languages often adopted to describe SoS architectures, such as UML 3 , SysML 4 , and CML 5 , lack expressiveness for describing SoS architectures, with drawbacks that can difficult SoS architectural specifications, as they do not support, in particular, partial description of constituents not known at design time. Other initiatives have proposed approaches that use model transformations from an architectural model (SySML, HLA, DoDAF 6 , π-ADL) to some simulation formalism (Go language, Simulink 7 ) Chapter 4. Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and Prescriptive Models of Systems-of-Systems Software Architectures (CAVALCANTE; BATISTA; OQUENDO, 2015;FALKNER et al., 2016;[START_REF] Xia | A model-driven approach for evaluating system of systems[END_REF][START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF]. However, these approaches do not support: (i) SoS software architecture specification (CAVALCANTE; BATISTA; OQUENDO, 2015); (ii) dynamic architecture and constituents not known at design time (FALKNER et al., 2016); and (iii) the concept of SoS software architecture with all the necessary details to guarantee precision in representation [START_REF] Xia | A model-driven approach for evaluating system of systems[END_REF][START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF]. SosADL was recently conceived to support specification of SoS architecture descriptions (OQUENDO, 2016c). SosADL is an executable language. However, SosADL models demand an execution mechanism that interpret the operational semantics of such language. The establishment of a mapping between SoS descriptive and prescriptive models enables such mechanism by automatically generating a denotational executable semantics based on DEVS that conforms to the original Pi-Calculus for SoS operational semantics for the subset of SosADL that we worked on.

Contributions of our work. Back-SoS brings the following contributions.

1. A characterization of architectural drift in SoS: Architectural deviations, drift, and erosion has been broadly exploited in software engineering literature, including model recovery, discovery, and reconciliation mechanisms. However, for SoS context, this discussion is still scarce. Then, we make a contribution on characterizing such elements in regards to SoS software architectures;

2. A list of architectural changes that may cause drifts: in Back-SoS approach, we envisioned the types of changes that can cause deviations in a SoS, creating a first taxonomy for this that can be reused in forthcoming research;

3. A Model recovery and discovery for SoS: We also create a model-based mechanism that automatically recovery architectural elements from a SoS runtime model, and creates, as outcome, a model that represents the SoS current configuration. This can also be seen as a contribution, as the mechanism can be replicated and extended for other contexts;

4. A reconciliation mechanism: We also report the creation and evaluation of a reconciliation mechanism. We implemented it through the use of a reverse model transformation, that takes the result from model discovery approach, and produces an updated version of the SoS software architecture documented in SosADL; and 5. Results of an evaluation: We also report results reported on the conduction of a case study performed using part of the mechanisms prescribed in Back-SoS approach;

6. A process to deal with architectural drift in SoS software architectures: well-defined steps communicated in Section 4.1 can also be seen as a contribution, as it is technology agnostic, and could be adapted for any model recovery, discovery, and reconciliation mechanism that can be chosen for SoS context.

Challenges for SoS Architecture Drift. We raise some open issues and challenges that must be still addressed in the next years about SoS architecture drift, erosion, degradation, and reestablishment of consistency, as follows:

1. Mechanisms to edit only the parts that need to be updated in concrete SoS architectural model: Currently, architectural reconciliation mechanisms are often concerned to restore, in the prescriptive model, only the parts that have been effectively changed at runtime. This is specially important for systems that are too large. In our approach, we generate, as outcome of the reverse transformation, an entire SosADL model that corresponds to the architectural specification (we do not perform reverse engineering of the constituent codes, but only from the specification of how they interoperate). Further research must be conducted to deal with this issue and enable automatic partial editing of SoS architectural prescriptive models;

2. Multiple concurrent changes: In a real SoS, many concurrent changes can occur in the SoS architecture. Further investigation must be conducted to deal with the scheduling of these changes and how this will impact on architectural recovery, discovery, evaluation, and reconciliation.

Final Remarks

This chapter presented Back-SoS, a reverse model transformation approach for supporting the checking of the consistency between descriptive and prescriptive SoS architectural models. As some architectural configurations that emerge at runtime can categorically affect and hamper the SoS entire performance (GRACIANO NETO et al., 2018b), it is important to establish strategies to keep beneficial SoS architectural configurations, maintaining both models (descriptive and prescriptive ones) synchronized to avoid problems that come from architectural drifts and erosion. After beneficial architectural configurations are identified, our approach also supports maintaining a synchronization between such configurations and the prescriptive model. This procedure could avoid architectural degradation and problems emerged from it, undoubtedly consisting of a novel investigation area of utmost importance. This work is probably the first one that deals with architectural drifts in SoS software architectures; therefore, there is still a lot of work to be done. Besides the reverse transformation, we also externalized an approach to deal with model discovery in SoS simulations, and a list of challenges for the future. We hope our insights contribute for the forthcoming research and for fostering the development of reliable, useful SoS that have been recurrently found in critical application domains. Simulations can contribute to guarantee SoS trustworthiness. They consist of a recurrent approach in SoS Engineering to anticipate failures early in SoS life cycle. Simulations externalize how the whole SoS behaves at runtime (WACHHOLDER; STARY, 2015;MITTAL;[START_REF] Mittal | Harnessing Emergence: The Control and Design of Emergent Behavior in System of Systems Engineering[END_REF][START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF][START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF]. To be reliable, a simulation must faithfully reproduce the conditions under which a SoS operates. These conditions must involve SoS surrounding environment (such as rain and temperature) and constituents operational conditions (such as battery level and GPS location) [START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF][START_REF] Valerdi | Foundations of modelling and simulation of complex systems[END_REF]. A manual approach can fail to reproduce the real frequency of such stimuli, since an expert would have to simultaneously inform inputs for all constituents at runtime until the end of the simulation. Moreover, a manual approach to generate inputs for such simulation can be costly. For example, to reproduce SoS dynamics, for each unit of time, each constituent in the simulation must be fed. A stimulus is often delivered to a constituent system through a user interface interaction. For each stimulus, one user interaction is needed. Considering a SoS formed by six constituents, if each one of them requires one stimulus by unit of time, after only 100 units of time, 600 interactions (such as clicks) need to be performed. Thus, the effort needed to feed a simulation with a greater number of constituents or for a longer period of time is extremely high, making this approach unfeasible to simulate real SoS.

In this scenario, stimuli generators can support SoS simulation. They consist of a virtual simulation entity responsible for playing the role of the environment, delivering input to a SoS [START_REF] Sanchez-Montanes | Learning sensory maps with real-world stimuli in real time using a biophysically realistic learning rule[END_REF][START_REF] Sanchez-Montanes | Learning sensory maps with real-world stimuli in real time using a biophysically realistic learning rule[END_REF][START_REF] Sanchez-Montanes | Learning sensory maps with real-world stimuli in real time using a biophysically realistic learning rule[END_REF]. However, manually coding of such stimuli generator is equivalently not feasible. Stimuli generators are domaindependent and totally adherent to the environment modeling, which is itself challenging for SoS development [START_REF] Rajkumar | Cyber-physical systems: The next computing revolution[END_REF][START_REF] Selic | The pragmatics of model-driven development[END_REF][START_REF] Hehenberger | modelling, simulation and integration of cyber physical systems: Methods and applications[END_REF]. For example, if we want to simulate a reactive system (such as a temperature sensor), it is important to predict a subset of stimuli that it can receive in order to establish how it will react to them. This entity should encompass details such as the scale in which it will work (celsius, fahrenheit, kelvin, or another scale), a range of acceptable values (from -50 to 60 degrees celsius, for example), the description of the data as a data structure (with value and type), instances that could be received, and frequency in which it must be delivered. Additionally, its development is costly, as it requires writing additional simulation code, often in a lower abstraction level, such as state machines, ports, inputs and outputs details. Aiming to reduce costs associated to the engineering of a stimuli generator, we can explore the possibility of automating its creation, hence supporting: (i) the prediction of the surrounding environment dynamics; and (ii) an anticipation of possible events and natural phenomena that could hamper SoS correct operation.

In context, it is noteworthy to pose the following research question: How is it possible to automatically obtain a functional stimuli generator that reproduces environmental conditions to the simulation of a SoS ? To answer this question, in this chapter we present a model-based derivation approach for automatically producing stimuli generators to feed a SoS simulation at runtime. In this approach, architectural descriptions play the role of input model as they inherently store information about expected inputs and outputs of the SoS, supporting environmental modeling. We evaluate our approach with regard to its correctness/reliability in automatically producing stimuli generators for the simulation of a real SoS that monitors flash floods risk in a river that crosses urban areas. Results of this study reveal that our approach is reliable and capable of deriving stimuli generators that conforms with the expected inputs that must be received by simulated constituents, and that effectively triggers the SoS simulation. This chapter presents Stimuli-SoS, a model-based approach to support the creation of stimuli generators to be used in the simulation of SoS. Stimuli-SoS takes advantage of software architecture descriptions for automating the creation of such generators. Specifically, this approach transforms SosADL into dynamic models expressed in DEVS.

We carried out a case study in which Stimuli-SoS was used to automatically produce stimuli generators for a simulation of a Flood Monitoring SoS.

Presentation of Stimuli-SoS

Stimuli-SoS is a model-based approach established to automatically derive stimuli generators for SoS simulations. For each distinct type of constituent in a SoS, a dedicated stimuli generator is created. Architectural models often bring some sort of environment description (ISO, 2011). To establish the basis of Stimuli-SoS, we decided to use a SoS architectural model to derive stimuli generators for a SoS simulation via a model transformation.

A Systematic Approach to Derive Stimuli Generators

We established Stimuli-SoS as a systematic approach based on well-defined activities. The systematic approach involves a reference workflow to derive stimuli generators. Figure 33 shows the proposed workflow which is represented through an UML activity diagram using SPEM 1 stereotypes. Each activity is developed by a SoS architect. The result of the execution is the generation of work products. Our approach consists of the following activities:

1. Specification of SoS software architecture: In the first activity, an architectural description of the SoS software architecture is specified using SoSADL. The work 3. Inclusion of stimuli generators in the target simulation model: After delivering the DEVS files, they must be included in a project that is deployed in MS4ME tool to support the launching and execution of the simulation; and 4. Execution and monitoring of simulation: This activity uses the stimuli generator and collects data from the simulation to observe emergent behaviors, to perform statistical analysis and to collect evidence for validation and verification of properties of the SoS software architecture.

Model Transformation

All SoSADL elements must be traduced to DEVS to create a functional simulation. In SoSADL, there is a special type of connection called environment, which abstracts interaction of a SoS with the surrounding environment, emitting outputs to the environment, or receiving stimuli from it, e.g., when the system is a sensor. However, there are no straightforward elements in DEVS to automatically produce environment stimuli. We decided to harmonize both formalisms (SoSADL and DEVS) through a model transformation. Such transformation enables the creation of stimuli generators that deliver the expected inputs the constituents wait to perform transitions and to start their execution.

Listing 9 shows an excerpt of a code in SoSADL that depicts part of the specification of one constituent: in this case, a sensor. Some parts are hidden because they do not influence in the derivation of stimuli generation. It is possible to see, for example, that the gate energy offers two environment connections (Lines 12 and 13): one to receive a threshold (a limit of energy that is considered enough to keep the sensor in operation), and power, which is used to receive the level of battery available. A connection in SoSADL has a name and a data type that can be transferred through that communication channel. Then, when a connection is specified with the environment modifier, it actually models what is expected to be received from the environment and the data type expected. Each type of constituent requires a different stimuli generator. Then, such architectural model is used as an input for a model transformation that collects the set of environment connections, extracting the data type, and creating one respective output state transition for each one of them. These state transitions are assembled in sequence to form an entire state diagram that will drive the stimuli generator operation. Then, each state transition will deliver one of the expected data to the correspondent constituent whose architectural specification model was used to create that stimuli generator. Each stimuli generator is associated to a data flow that receives data from a textual file. That file holds the data that feeds the constituent. Then, these data are read from the text file and sent to constituent, triggering the simulation to run. This happens in a periodic and constant rhythm so as to keep the simulation running. Source code 9 -A specification of a sensor in SoSADL.

The following steps are followed by the transformation chain that produces stimuli generators:

1. All connections of all the constituents are mapped into a specification format and saved in a text file;

2. Connections are read from the text file and analyzed. Such connections are parsed from the architectural description of the SoS to be in the following format: measurement::

sense;RawData-true. This first part is the name of the gate in which the connection has been specified. The second part is the name of the connection. The third part represents the data type that can be transferred across that communication channel. The last part of each connections descriptions is a boolean: it has a true value if the connection is of the type environment and false if it is not. The transformation algorithm searches for environment connections. Each connection specified as an environment connection produces one transition in the specification of the state diagram in the resulting stimuli generator. Hence, the stimuli generator consists of a special type of system (in the context of the simulation) that has a continuous behavior (a behavior materialized as a loop) to emit stimulus by output state transitions, starting and keeping the SoS in operation.

Listings available externally 2 show and bring explanations about the Xtend code that materializes the model transformation. We evaluate our approach as follows.

2 https://goo.gl/vPbKcL 5.2. Evaluation 137

Evaluation

To investigate the reliability of Stimuli-SoS approach, we performed a case study using a Flood Monitoring and Emergency Response SoS.

Scenario Description

We specified a FMSoS architecture with 42 sensors, 9 crowdsourcing systems, and 18 drones, following the model shown in Figure 34. Each drone has its own base (18 drone bases), and transmits the information collected through its own 3G gateway (a gateway that will be in the vicinity). 18 gateways are spread along the river boards. Mediators were produced as much as necessary to mediate these constituents, and 20 gateways were also used to receive these transmissions. FMSoS monitors occurrences of floods in an urban area. Rivers cross the city and, when the rains are intense, floods frequently occur, causing losses, damage, and imminent danger for the population. FMSoS is composed by five different types of constituents: Our FMSoS is concerned with one specific mission: emitting flood alerts to public authorities that can draw strategies to protect the population. It consists of a collaborative SoS, with no a central authority that orchestrates the constituents functionalities to accomplish missions. Data are gathered in gateways, analyzed according to flood risk, and a status (alert or no alert) is transmitted to public authorities. Figure 35 gives an illustration of FMSoS deployed in a river 3 . Sensors are spread on the river's edges with a regular distance among them, and mediators exist between every pair of sensors in a pre-established distance between them. Data collected by sensors are transmitted until reaching the gateway. Besides, drones fly on the river and return to their bases to recharge and eventually communicate with gateways to alert about a flood threat. In parallel, people that walk close to the river can also contribute by communicating that water level is increasing if they perceive this happening. In case of flood, gateways emit alarms for public authorities. Authorities cross data coming from all the constituents to draw a conclusion of an imminent flood, taking decisions to protect population.

FMSoS exhibits the following characteristics (MAIER, 1998; OQUENDO, 2016a) 4 :

Operational independence of the constituents: Each constituent (sensor, crowdsourcing system, or drone) operates in a way that is independent of other constituents, as they belong to different city councils and have different missions in the region of São Carlos;

Moreover, our example scenario also covers constituents heterogeneity, autonomy, and SoS scale, characteristics that are commonly assigned to SoS, as well [START_REF] Jamshidi | System of systems engineering -new challenges for the 21st century[END_REF]. Emergent behavior: One unique constituent could not deliver a flood alert by itself. For instance, if only one sensor, or crowdsourcing system or drone performs its activities in an urban area, it could not notify a flood on time, being not effective. It might emit a false alert, since the flood could be limited to another place. Hence, the flood alert is result of the interoperability among a diversity of constituents working in cooperation, spread along the riverbank.

For each one of the constituent types, a specific type of stimuli generator was automatically produced using our model transformation approach. For each constituent type, connections were specified in SoSADL with the environment modifier to support the automatic derivation of stimuli generators. Mediators do not need a stimuli generator as they receive stimuli from other constituents and they do not have environment connections. We discuss the rationale behind each one of the environment connections for each type of constituent, as follows:

Smart sensors: battery (power level), coordinate (GPS location), water level, and power threshold. Rationale: they receive battery level and power threshold, and a coordinate to start their work. After that, the stimuli generator will deliver water level to them, imitating the data obtained by sensors to verify if the SoS will detect possible floods;

Gateways: battery (power level), coordinate (GPS location), and power threshold.

Rationale: The gateway (materialized by an industrial computer linked to the internet) provides the base station for collecting these measures and processing them, possibly warning the risk of imminent flood (OQUENDO, 2016a). Data are transmitted from other constituents and gathered in gateways. Hence, only power level, coordinate, and power threshold are necessary.

crowdsourcing systems: battery (power level), coordinate (GPS location), visual perception, and power threshold.

Rationale: crowdsourcing systems are apps that enable population to communicate a possible flood threat by interacting with mobile. It is possible to communicate the risk level and to send pictures to show the situation. These systems do not interact with environment, but with humans. Hence, operational aspects are documented as environment issues (power level, coordinate, and power threshold), and a specified behavior enables citizen to send information according to a pre-defined danger scale and pictures that endorse their perception [START_REF] Albuquerque | Leveraging volunteered geographic information to improve disaster resilience: Lessons learned from agora and future research directions[END_REF]. However, this perception also represents the environment. Hence, we defined in SoSADL that the danger level is a pre-defined value (between 1 and 6, 1 being no risk, and 6 being flood effectively occurring) that can be classified by the human user according to what he/she sees. Figure 36 shows a real picture of a human dummy painted in river wall in front of USP. People use it as a reference to classify the flood risks according to the aforementioned levels. In turn, Figure 37 shows how the numbers and the co-related water level appear in the mobile app so that a person can classify the risk. Looking at the painting available in Figure 36, it can classify the risk according to the scale available in Figure 37, and send to gateways. Then, an environment connection called perception was defined in SoSADL specification, enabling that these pre-defined data can be sent according to what the user selects. Then, it is still possible to automatically create a stimuli generator that delivers these data;

Drones: battery (power level), coordinate (GPS location), water depth, and power threshold, image, and distance flown.

Rationale: Most professional radio control systems reach 2km of radius extension.

A drone has an average autonomy range of 10 minutes. After that, it is required to come back and recharge its battery. Its average speed is 16 meters per second. Hence, it can fly 5 minutes to go, and return in the next 5 minutes to recharge. Then, he can fly a route of 2400 meters one way, and 2400 meters back. As the Monjolinho River, where we are applying the case study, has an extension of 43 kilometers, it will take 18 drones to individually cover 2.4 km each. We will call the drone connection as water depth, since it measures the height of water differently from the sensor. In addition, a connection called image will be responsible for taking a photo of the place that has altered water height and send via 3G to responsible authorities, initiating the alert. Photos are taken only when the water depth exceeds a given threshold.

For measurement purposes, the flown distance will also be delivered constantly to the drone, within the limit of 2.4 kilometers. The GPS position is also delivered constantly by the stimulus generator, changing its values over time, to simulate the autonomous movement.

Drone basis: battery (power level), coordinate (GPS location), and power threshold. Rationale: This is the radio control basis, for where drones come back to recharge battery. Only its own battery level, coordinate, and power threshold are necessary to model its environment of interest.

Case Study Protocol

The case study was conducted according to the following steps (RUNESON; HöST, 2009): (i) Case study design (Preparation and planning for data collection); (ii) Execution (Collection of evidence); (iii) Analysis of collected data, and (iv) Reporting.

Scenario: Our case study consists of a Flood Monitoring SoS (FMSoS) concerned to monitor a river that crosses an urban area, aiming to detect potential flash floods, i.e., floods that can occur quickly with huge damage and risk for population. It consists of the description of part of a SoS already in operation in São Carlos, Brazil, monitoring the Monjolinho river that crosses the urban area and that causes recurrent flash floods, causing damage and losses.The goal of this case study is:

Goal: to evaluate with regard to its correctness if stimuli generators automatically produced are able to trigger and feed a simulation until the end of its execution. Rationale. Our approach was designed to support simulations of SoS software architectures by automatically producing stimuli generators. As such, we claim that to be reliable, a simulation must reproduce the conditions under which a SoS operates, considering both its surrounding environment (such as rain and temperature) and constituents operational conditions (such as battery level and GPS location). Then, our evaluation is based on the success of our approach to support automatic production of stimuli generators that can (i) reproduce the surrounding environment and constituents operational conditions, and (ii) maintain the simulation running until the end of data input. Considering that we use a software architecture description as the basis to produce three different types of stimuli generators. If the software architecture is faithfully described and the generation method is correct, the stimuli generators created will address our claims. Then, we established the following research question: How is it possible to automatically obtain a functional stimuli generator that reproduces environmental conditions to the simulation of a SoS ? To answer this question, we established a model-based approach that produces such stimuli generators from a SoS software architecture description, and established the following goal to the case study (that matches our first research question). From this general goal, we derived the following research questions with their respective metrics:

RQ1. Are the (automatically created) stimuli generators functional? Rationale. This question establishes whether or not the stimuli generators automatically generated are functional, that is, if they can work into the context of a simulation after deployed, exactly how they were created, without any manual intervention or modification. Metric -Success fee: percentage of data correctly delivered to the correspondent constituent, considering the amount of that data that is intended to be delivered.

RQ2. Is the stimuli generator capable of triggering a simulation correctly? Rationale. The simulation only starts when the correct stimuli are received by the constituents and they start their operation, making the entire SoS operate. This research question evaluates if the simulation starts correctly. Metric -Efficiency: A participant observes if the simulation is successfully triggered by the stimuli received during its entire execution cycle.

RQ3. Is the stimuli generator capable of supporting an entire simulation execution correctly?

Rationale. The aim of a stimuli generator is supporting a simulation with a continuous emission of stimuli that keep the simulation running. Metric -Number of problems during simulation execution: given by the proportion of errors during simulations compared to the total execution of the simulation.

Research Instruments

We used a FMSoS to collect all data used in the simulation. We adopted Eclipse Modeling Framework (EMF) as the platform to develop SoSADL models based on Xtext. Xtend is the transformation language, MS4ME 5 is the simulation platform, and DEVS (in particular, a DEVS dialect called DEVS) is the formalism for running the generated

Data preparation

We obtained data collected by the sensors that are under supervision of a Brazilian entity responsible for monitoring natural disasters (Brazilian Center for Monitoring and Warnings of Natural Disasters -CEMADEN) [START_REF] Horita | Development of a spatial decision support system for flood risk management in Brazil that combines volunteered geographic information with wireless sensor networks[END_REF]. These data were parsed, and stored in a text file. Stimuli generator are fed with them, emitting them to the simulation, stimulating it until the end of the execution. The input of data triggers the constituents operation, cause their interoperability, reach the gateway, are processed creating new data that correspond to positive or negative flood alerts. We also collect these data to analyze results.

We chose a large sample of data collected by the real FMSoS from November 23th 2015 to December 31th 2015. This interval was important because during these months a number of floods occurred. This enabled us to establish whether or not our simulation results in a diversity of situations. We sent 1000 samples for each sensor, being sent every 5 minutes, and 1000 for crowdsourcing systems. Considering that we only had data to feed sensors in a simulation, we adapted them so to have similar data for stimuli generators for crowdsourcing systems and drones. For crowdsourcing systems, the aforementioned scale was used to classify risk between 0 and 6. So we could simulate how people would react and behave due to the changes in water level registered before by sensors. Then, we created a dataset correspondent to the data used to feed sensors. This dataset is available externally 6 . For drones, we used 5000 drone data, since the drone receives every 500 meters a measurement and 2500 meters flown every 5 minutes, totalizing this amount for the entire days that we consider in our sample.

Analysis procedures of collected data.

Stimuli-SoS approach is concerned to the automatic production of stimuli generators. Hence, we need to evaluate if the stimuli generators automatically produced (i) conform to an expected structure of a DEVS model that send stimuli to a simulation, and (ii) are functional, correctly delivering data to the respective constituents that wait for their stimuli. Thus, a quantitative analysis can be adopted to (i) measure the correctness and similarity of stimuli generators to the expected form of a functional DEVS atomic model that deliver data, (ii) evaluate if the stimuli generator keep its operation, delivering data along the entire simulation cycle, and (iii) evaluate if the simulation is correctly triggered and maintained in operation until the end of the input procedure. Hence, we adopted a quantitative analysis in our case study [START_REF] Runeson | Guidelines for conducting and reporting case study research in software engineering[END_REF][START_REF] Runeson | Guidelines for conducting and reporting case study research in software engineering[END_REF]. We follow a systematic approach divided in well-established steps, reporting the collection and measurement of pre-defined expected data, observing and measuring the scenario via simulation according to pre-defined metrics, and drawing conclusions from these results to answer the research questions established.

Reporting

We report our results based on the steps systematically followed to achieve the derivation of the stimuli generators for FMSoS constituents. A video shows a summary of the entire procedure 7 .

1) SoS Software Architecture Specification

The specification of the software architectural description of the FMSoS was conceived as a joint work between SofTware ARchitecture Team (START/ICMC) at University of São Paulo and ArchWare (IRISA) at University of South Britanny, in France. Such specification was conducted by a team of four people using SoSADL language. This step was accomplished after two months of work, and received four iterations to perform refinements on the SoSADL syntax, to cover some gaps that were not identified before, and to refine the software architectural description itself until reaching an acceptable format. We specified an FMSoS architecture with 42 sensors, 9 crowdsourcing systems, and 18 drones, as described in Figure 34. Such specification was validated by a peer-review procedure composed by the SoSADL creator and other SoS experts. The complete SoSADL architecture specification is available externally 8 .

2) Automatic Derivation of Stimuli Generators

After the accomplishment of the first step, the automatic derivation step was conducted. The software architectural description produced in step 1 was used as input for this step, being processed by the model transformation script, delivering a stimuli generator for sensors that compose the FMSoS. At this step, a distinct stimuli generator is produced for each distinct type of constituent. In FMSoS case, three types of stimuli generator are conceived: one stimuli generator for sensors, another one for crowdsourcing systems, and another for drone system. The transformation runs and delivers the code in two seconds. The products of this activity (the stimuli generators themselves) were evaluated using the metrics defined in RQ1 (similarity and correctness). Figure 38 illustrates how an automaton is derived from SoSADL system specification to create a functional stimuli generator. In DEVS, transitions can occur due to (i) a data received, expressed as ?data, (ii) a data sent, expressed as !data, and (iii) a spontaneous transition, without any input or output. This is the approach we used to generate atomic models for each one of the constituent types 9 . In turn, derivation of the stimuli generator is quite different. In SoSADL, there is a special type of connection called environment, that abstracts interaction of an SoS with the surrounding environment, emitting outputs to the environment, or receiving stimulus from it, e.g., when the system is a sensor, as shown in the code available in Figure 38. Some parts are hidden since they do not influence in the discussion of stimuli generation derivation. It is possible to see that the gate energy offers two environment connections (Lines 12 and 13): one to receive a threshold (a limit of energy that is considered enough to keep the sensor in operation), and power, that is used to receive the level of battery available. Connection sense is that one responsible to receive raw data, i.e., the water level from that is being measured from the river by sensor actuators. Lastly, connection coordinate receives GPS coordinate from the sensor GPS.

SoSADL models are analyzed by the transformation algorithm, searching for environment connections. Each connection specified as an environment connection (underlined in Figure 38) produces one transition in the specification of the state diagram in the resulting stimuli generator. Hence, the stimuli generator consists of a special type of model that has a continuous behavior (a behavior materialized as a loop) to emit stimuli by output state transitions, starting and maintaining the SoS operation. Figure 38 depicts a state diagram equivalent that is created with state transitions created to deliver each of one of the connection data types underlined. It delivers the aforementioned data, and comes 9 We do not discuss this mechanism with details in this paper, since the focus is the representation and derivation of a stimulus generator. Other details are discussed in a forthcoming paper.

back to the state s0, forming a loop that continuously offer stimuli for SoS simulation.

Order is not important, as constituents are only triggered when the data received matches the input data expected in the state transition in which its operation is at that moment.

Source code 10 -DEVS code for a stimuli generator.

Listing 15 shows the code in DEVS that specifies part of the stimuli generator produced using our approach. The stimuli generator is created not only with the automaton that guides its operation, but also with specification of ports, data types, and all the apparatus necessary to make it executable and to enable the execution of the target simulation (some parts are hidden for the reader convenience). In Listing 15, the stimuli generator has four output ports (Lines 1 to 4) that delivers the collection of the geographic positions (coordinate), power threshold, power level (battery energy) and the water level sensed by sensors.

3) Inclusion of Stimuli Generators in the Target Simulation Model

After the automatic derivation, the stimuli generator must be deployed in the simulation code specified in DEVS and already deployed in MS4ME environment. This step consists of moving the stimuli generator file to the simulation project in MS4ME environment. MS4ME environment automatically generates a Java file that corresponds to the execution entity of each stimuli generator. The SoS architectural description in DEVS is also adapted to include stimuli generators, and to specify that they must emit data to their correspondent constituents, that is, those that hold environment connections that were used as input to produce the respective stimuli generators. Figure 34 illustrates an example of FMSoS architecture during simulation. Mediators enable transmission of data received by sensors from stimuli generators until the nearest gateway. This activity was evaluated by checking if, after deployed, the simulation become executable. The simulation took for six hours and twenty minutes (6.20h) in Processor Intel core i5-3230M 2.60GHz (x64), with 4 GB of RAM Memory, HD of 1TB, and running Ubuntu 16.04 64 bits. The data corresponds to 38 days of monitoring data from the Monjolinho River. Data were stored in text files and delivered by the stimuli generators along the FM-SoS, feeding the simulation. This step was evaluated according to the metrics established in research questions two and three (efficiency and number of problems during simulation execution).

4) Simulation Execution and Monitoring

We established a four-window strategy implemented at the gateways that receive data from constituents to confirm floods. For each four data that subsequently arrives, the gateway checks it by pairs (three possible combination of pairs of four data that arrives). If at least one pair that arrived have both their depth levels equals to or major than 100 cm (the threshold established for that city), a flood alarm is triggered. Experts remarked that one sensor could trigger a false alarm due to the possibility of sediment accumulation, which can increase the measured collected in a location, but that does not represent a flood. Hence, taking pairs was considered a valid strategy. Table 23 illustrates an example. It corresponds to real data that arrived sequentially at the gateway. Each four data that arrive are chronologically ordered, and pairs of data given by (S2,S3), (S1,S3), and (S3,S4) are analyzed. If at least one of the pairs has two measures equal or greater than 100 cm, a flood is confirmed. We did allow the sum of four measures that generate false alarms (for example, S1=90cm, S2=90cm, S3=90cm, S4=130cm). This can represent an increasing in the level of water, but not a flood. Subsequent measures will confirm if it is an actual flood or not. After all the data were analyzed, we compared our results to the original results to evaluate the confidence of the automatically generated simulation. However, it is possible to remark in Table 23, data do not arrive in order. Hence, if a flood occurs, S1 will be the first to increase its measure, followed by S2, S3, and S4 respectively. Thus, a false negative can occur due to the delay to arrive at the gateway and possible losses of data. One possible situation occurs when only one transmit data with more than 100 cm to the gateway, because it was the last one in that sequence of four measures, but the other measures, even if not 100 cm yet, can have already slightly increased, indicating a possible a flood coming. To avoid this, a new test was done: we added both measures of the other combinations that were not checked in the first cycle to avoid false diagnostics. For example, considering Table 23, we obtain the values of depth from (S2+S3), (S2+S4), and (S1+S4).

After the simulation terminated we analyzed the perceptions from the observation and answered the research questions, as follows. Figure 39 shows the biggest averages of depth of water reached in each of the days analyzed. Considering that the four-window strategy exhibits a threat of flood, days November 23th, and December 21st and 30th are the most relevant. Other moments exhibit values bigger than 100 cm, but only as a momentary occurrence. The graphic enables us to analyze that the stimuli generator was capable of delivering the data continuously during all the simulation execution. Next we discuss the answers to the research questions.

RQ1. Are the (automatically created) stimuli generators functional?

Yes. The stimuli generators were analyzed by a specialist that agreed that it contains all necessary structures to deliver the expected behavior. Moreover, we observed their behavior during the simulation execution, and the data that arrived in the gateways. 100% of the data were correctly delivered to the simulation.

RQ2. Are the stimuli generators capable of triggering a simulation correctly? Yes. We followed the entire cycle of operation of the simulation. The stimuli generators were capable of receiving the input data from the database and generating the expected stimuli for the constituents, triggering the SoS interoperability. Hence, the stimuli generator was well-succeeded. Three types of stimuli generators were derived from the specifications in SoSADL, as available externally 10 . For all of them, they were able to receive data stored in text files and deliver them to the simulation.

RQ3. Is the stimuli generator capable of supporting an entire simulation execution correctly?

During the entire cycle, the generator stimulated the simulation, completing the operation cycles of this SoS. The group of samples were grouped in four measures each to give a flood alert or not, depending on the analysis of the data. We followed the same strategy implemented in the real gateway: from four data that arrives, if two are above the threshold, the flood alert is triggered. 29 flood alerts occurred along some hours of flood (considering that each group of four data received that whose sum was more than the threshold triggered the alert). During the considered period, besides one effective flood (November 23th), in which the level of water arrived at almost seven meters, two other real threats of flood occurred on December 7th and 21st. With no failures, the stimuli generator was capable of supporting the simulation during its entire cycle of operation.

Discussion

Our solution promotes the automatic production of stimuli generators from architectural descriptions of SoS. It can create a distinct stimuli generator for each distinct type of constituent that forms a SoS. We applied the same methodology to produce three different types of functional stimuli generators: one for a smart sensor, one for crowdsourcing system, and another one for a drone, diversifying our data sources and characterizing the required multiple source of datas of a case study.

Considering our context, requirements elicitation for Flood Monitoring SoS was a joint effort between several institutions, such as ICMC/USP, IRISA/UBS, CEMADEN, and Franhoufer Institute. They elaborated the requirements, describing the surrounding environment for such SoS. After that, we used this document as an input to create the architectural description in SoSADL. Despite the environment being highly dynamic, a SoS is concerned only with a subset of the possible stimuli that can be received. Stimuli set completeness is a SoS requirements engineering issue. Considering a Flood Monitoring SoS as an example, data used in our example (such as water level) are relevant and enough to draw conclusions about a possible flood and the respective flood alert (as this is the 10 https://goo.gl/xk5h3z 5.3. Discussion 151 intended purpose for this SoS). Dynamics of the environment is handled by the sensors actuators themselves (at hardware level). Oscillations in values are passed to software-level, received and processed to draw actions. Then, we believe that the success of our approach relies on the effectiveness of a SoS to deal with the set of environment data delivered to it (even if this data set is specific and restrict). Moreover, at simulation level, we can observe how SoS will behave considering specific data received. If we notice that data delivered are not sufficient to draw conclusions, a new study can be conducted to increase data expected in order to increase precision of floods detection. However, considering the data set that we worked on and these types of constituents, SoS was able to detect all the flood threats that effectively occurred. Hence, we can conjecture that the stimuli set completeness is acceptable.

We also addressed scale, heterogeneity, and autonomy, which are important concerns for SoS. About scale, we run an example with 69 constituents, without considering gateways, mediators, and drone bases. For all constituent types, stimuli generators were automatically derived and worked correctly. About heterogeneity, we used five different types of constituents. About autonomy, all of these constituents exhibit their own structure, behavior, and independent operation.

It is important to highlight on how much the adoption of stimuli generators reduces the manual work of the SoS simulation. To perform this work manually, considering that each of the stimuli would consist of a click. Each click demands a reasoning from the human analyst. If each click needs 10 seconds to be decided and executed by a human, in a sample of 1000 data for each crowdsourcing system, 1000 for each sensor, and 5000 for each drone, this would result in an amount of 141,000 samples to be entered by the human user into an architecture of 42 sensors, 9 crowdsourcing systems, and 18 drones. Therefore, this work would require 1,410,000 seconds, which amounts to almost 392 hours of work, or almost 50 days of work in 8-hour days. Our procedure needed little more than 6 hours to run.

Contributions. The contributions of our approach are listed as follows:

Productivity: We claim that Stimuli-SoS contributes to the productivity in the SoS engineering. Using our approach, we simulated 38 days in little more than six hours. The effort necessary to correctly simulate the activities of a human to reproduce real data accordingly would be significantly larger than using our solution, as discussed earlier. Thus, our approach is almost 65 times more productive than a manual approach, considering the architecture we used.

Reuse: Programming the model transformation to automatically produce a stimuli generator by one specialist with integral dedication took five days of work (a total of approximately 40 hours). Despite learning curve associated to DEVS modeling, Xtend programming, and domain-specific knowledge to adapt model transformations, the model transformation can be reused in a myriad of other domains. Producing a stimuli generator for each type of constituent of a SoS takes the same amount of time. The same specialist that produced the model transformation also produced an operational stimuli generator to realize the final format that should be achieved.

Model-Based Engineering for SoS: Application of model-based methods in SoS

engineering is still at the beginning [START_REF] Steinhogl | Trustworthy systems of systems -a prerequisite for the digitalization of industry[END_REF]. Moreover, a recent study reveals that MBE has been adopted for the development of SoS (around 60% of included studies in a systematic mapping applied MBE for development of SoS [START_REF] Lana | Systems-of-systems development: Initiatives, trends, and challenges[END_REF]). MBE has been applied in SoS context for managing systems complexity, developing candidate architectures, and verifying design decisions early in the development process. Thus, we believe that our approach contributes to SoS software engineering by establishing a novel model-based approach to support SoS simulation and environment modeling. The automatic generation of stimuli generator for simulation of software architectures of SoS purposes is a contribution for Software Engineering for SoS and SoSE, as these techniques were broadly adopted for hardware benchmarking, but rarely applied in software engineering, in particular, Software Engineering for SoS; Environment Modeling: Environment modeling is an emerging issue, not only for simulation domain or SoS domain, but also for modern software engineering as a whole (DAVID et al., 2013;[START_REF] Iqbal | Environment modeling and simulation for automated testing of soft real-time embedded software[END_REF][START_REF] Iqbal | Environment modeling and simulation for automated testing of soft real-time embedded software[END_REF][START_REF] Iqbal | Environment modeling and simulation for automated testing of soft real-time embedded software[END_REF]. It is important to improve techniques and methods to model the surrounding environment in which systems will be deployed, predicting situations that could not be dealt with effectively without this type of modeling, and preventing failures not envisioned before. These are vital issues as SoS becomes increasingly autonomous and ubiquitous, working on domains such as flood monitoring (OQUENDO, 2016c) and crisis management (SANTOS et al., 2015).

Stimuli-SoS Workflow: Stimuli generators are produced using a SoS software architecture description as input, following well-defined systematic steps that achieve the production of functional stimuli generators deployed in a simulation. The proposed workflow is also a contribution of our work, as it exhibits potential to be reproduced in other scenarios and contributes by prescribing how to produce this type of simulation structure.

Threats to Validity. Considering conclusion validity, we conjecture that it is not a remarkable threat for this study, since we do not have a statistical strength in our conclusions and we do not compare our approach with others, but use an exploratory study to draw our conclusions and justify our claims. Considering internal validity, we can raise the strategy to divide the data received by the gateway in a four window strategy. As this is the number of constituents, we do not perform remarkable partitions in data. Hence, we consider that this is not a significant threat. Considering construction validity, we draw our conclusions based on an approach that was systematically followed to automatically derive stimuli generators. Hence, we more observe than we measure. Further quantitative studies must be carried out to compare other forthcoming generations for different domains and that one we worked on here. Considering external validity, we run a case study in which, using approach, three different types of stimuli generators were produced, each one for a different type of system: a crowdsourcing system, a drone, and a sensor. As such, we increased our sources of evidence, even considering that all of them work in a same single simulation. Further investigation must be carried out, but there is some potential to application in other domains and generalization.

Regarding other threats, we can mention the possibility of failures if the SoS architect does not qualify the environment connections in SoSADL with the keyword environment. If it occurs, simulation can fail because expected input can be never received. Indeed, any error regarding the declaration of environment connections at design time can affect the final simulation. Moreover, more accurate evaluation in larger contexts and applications are still required. Our approach was evaluated in regards to its success to support automatic production of stimuli generators that can correctly (i) reproduce the surrounding environment and constituents operational conditions. Considering that we use a software architecture description as the basis to produce stimuli generators, if the software architecture is not faithfully described, the stimuli generators created can not be correctly produced. We relieved this threat by submitting the software architecture description to a specialist. Another threat to validity is the correctness of the model transformation. To minimize the impact of this threat, a specialist conducted a manual inspection and carefully evaluated if each transformation rule produced exactly the expected output considering each input given. Related Work. Recent studies have investigated the adoption of simulation in software engineering (FRAN ÇA; TRAVASSOS, 2016), and simulation has certainly been applied for SoS development [START_REF] Graciano | Investigating the model-driven development for systems-of-systems[END_REF][START_REF] Xia | A model-driven approach for evaluating system of systems[END_REF][START_REF] Bogado | Modeling and simulation of software architecture in discrete event system specification for quality evaluation[END_REF][START_REF] Bogado | Modeling and simulation of software architecture in discrete event system specification for quality evaluation[END_REF][START_REF] Bogado | Modeling and simulation of software architecture in discrete event system specification for quality evaluation[END_REF]. Additionally, initiatives have invested in the simulation of software architectures, but not specifically for software architectures of SoS, such as SySML The development of stimuli generators for simulation purposes is not a new trend [START_REF] Yang | Coverage-driven stimuli generation[END_REF][START_REF]The Art of Simulation Using PSpice: Analog and Digital[END_REF][START_REF] Kitchen | Stimulus generation for constrained random simulation[END_REF][START_REF] Kitchen | Stimulus generation for constrained random simulation[END_REF]. Initiatives have investigated the adoption of stimuli generators for hardware benchmarking. For example, Al-Hashimi (AL-HASHIMI, 1995) describes the use of stimuli generators to produce digital input signals for simulation purposes of analogic-digital systems. Kitchen and Kuehlmann present an approach to stimulate simulations of hardware with a stimuli generator that performs a random generation of input stimuli that obey a set of declaratively specified input constraints. [START_REF] Rahman | Stimulus generation technique for code simulation of fpga based gamma spectroscopy system[END_REF] describe the development of a software that systematically generates stimulus required for code simulation (functional and timing) of new digital processors in gamma spectroscopy system. [START_REF] Yang | Coverage-driven stimuli generation[END_REF] adopts simulations for verification purposes to evaluate the correctness of System-on-Chips. They apply stimuli generator to offer a broader coverage of test cases aiming to confirm the correctness of the chip operation. Thus, they do not work on top of software architectures, automating only the generation of the stimuli but not the infrastructure that will forward stimuli to the simulation.

For simulations in the context of SoS software engineering and software architecture, only few works have investigated stimuli generators. Table 24 compares closest related approaches considering the following six characteristics addressed by our approach:

1. Description of SoS Software Architectures: Does the highlighted approach adopt some formalism to describe SoS software architectures?

2. Simulation of SoS Software Architectures: Does the approach support simulation of SoS Software Architectures?

3. Environment Modeling: Does this approach adopt some type of environment modeling for simulation purposes?

4. Environment simulation: Does the approach adopt some type of environment simulation?

5. Adoption of Stimuli Generator: Does the approach adopt stimuli generator as the technique to inject inputs into the simulation;

Stimuli-SoS Yes Yes Yes Yes Yes Yes DEVS is a well-established formalism for simulating SoS in virtual environments [START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF]. DEVS deals with the system architecture, i.e., a simulation model in DEVS considers software and hardware aspects of all the constituents that compose a SoS, and for the SoS itself. DEVS takes into account several important characteristics of software architectures, such as data types, constituent systems (represented as atomic models), constituent behaviors (expressed as labeled input diagrams), SoS dynamics and how constituent exchange data (coupled models), events, and the overall organization of such constituents. However, it does not preserve the architectural details of SoS software architecture specification and relies on a low-level abstraction formalism, as discussed before. Kewley et al. claim that constituents should be simulated by isolated simulations, and that such simulations should be federated, that is, they should interoperate in a synergistic way to form the whole simulation of a SoS [START_REF] Kewley | Federated simulations for systems of systems integration[END_REF]. They adopt a framework called SySHub to play the role of glue that enables federations of models to support SoS simulation. However, they do not work on the level of software architecture (simulation or representation), despite the fact that they consider Distributed Interactive Simulation (DIS) and High Level Architecture (HLA) as potential architectural and interoperability methods for description and federated simulations of SoS (IEEE, 2010). However, even these notations do not tackle the concepts we address in our approach related to software architecture. They consider environment modeling as a potential forthcoming contribution of the SySHub system. However, we did not find continuity at this research topic or more recent papers that report supporting environmental modeling in SySHub context. Therefore, automatic derivation of stimuli generator is not currently covered in that approach. [START_REF] Soyez | A Multilevel Agent-Based Approach to model and simulate Systems of Systems[END_REF]. Their formalism is based on the multi-level agent-based model IRM4MLS, which allows the representation of multiple entities that can interoperate at different levels, i.e., a constituent can be itself an SoS, hence supporting different levels of granularity (MORVAN; VEREMME; DUPONT, 2011). To evaluate their approach, they implemented a co-simulation of a directed SoS coping with a reconfiguration problem in the domain of Intelligent Autonomous Vehicles. Despite the use of co-simulation, they do not provide any evidence of concerns with the notion of software architecture, nor automatic code generation or stimuli generators. They support the modeling of environment and claim that their formalism is suitable for simulation. However, there is no evidence strengthening their claim.

Considering these previous works, there is a gap regarding the automatic derivation of stimuli generators based on software architectural descriptions of SoS. Our approach bridges these gaps and contributes by advancing the state of the art about simulation of software architectures of SoS.

By the nature of SoS, environments are only partially known at design-time (OQUENDO, 2016a). It is important to emphasize that our approach is to generate stimuli for simulation, not to automatically create the data to be used in the simulation. A prototype of the data is created that is functional, but there is no technique for creating data that is reliable to reality. Currently, this type of data is collected from other sources, and inserted via Java code into the body of the stimulus generator. Nonetheless, there is an important contribution towards environmental modeling in SoS engineering. In this stage of the contribution, we automatically create a virtual entity for the simulation capable of delivering the data in a rhythmic rhythm, imitating the surrounding environment from the data provided to the stimulus generator to feed the simulation. In a next step, we intend to invest in the automatic creation of these data by a more accurate description of the environment. Next section brings final remarks and potential for future research.

Final Remarks and Forthcoming Steps

This chapter presented Stimuli-SoS, an approach to systematically and automatically derive stimuli generators to support the execution of simulation of SoS. We established the following research question to be answered: How is it possible to automatically obtain a functional stimuli generator that reproduces environmental conditions to the simulation of a SoS ? We concluded that the stimuli generators automatically created:

1. conform expected format. The transformation derived is what was expected; Stimuli-SoS approach successfully produced a functional stimuli generator, which was thereby able to trigger the execution of a SoS architecture simulation. The stimuli generator correctly forwarded data to the simulation, which was able to reproduce 29 flood alerts triggered by the SoS during a flooding event. In particular, Stimuli-SoS is almost 15 times more productive than a manual approach to produce data for this simulation. From another perspective, we noticed that for our context, the effort necessary to manually create a stimuli generator for a particular SoS could require approximately the same effort that we invested to develop the model transformation that we adopt in our approach, with the additional benefit that the transformation can be reused for a myriad of other domains. Our approach succeeded in automatically deriving a functional stimuli generator that can reproduce environmental conditions for simulating an SoS. In particular, we presented new contributions regarding productivity and automation for the use of a model-based approach in SoS engineering.

Potential applications and forthcoming investigation can be conducted relying on the advances produced by our research. Co-simulation, for instance, is an important but significant challenge. It exhibits the potential to establish a communication between industrial simulators. However, even for the context of simulation of single subsystems that compose a whole monolithic system, co-simulation is still matter of investigation [START_REF] Gomes | Foundations for continuous time hierarchical co-simulation[END_REF][START_REF] Schweizer | Co-simulation method for solver coupling with algebraic constraints incorporating relaxation techniques[END_REF]LU;[START_REF] Schweizer | Co-simulation method for solver coupling with algebraic constraints incorporating relaxation techniques[END_REF]. Stimuli generators have the potential to be the interface that enables receiving the injection of values from industrial simulators. The automatic derivation of these stimuli generators from software architectural descriptions of SoS with support for environment modeling may enhance the fidelity of the code generated and the proximity with the environmental modeling provided by industrial simulators.

Simulations have been recognized as source of empirical evidences for software engineering [START_REF] Fran Ça | Reporting guidelines for simulation-based studies in software engineering[END_REF][START_REF] Fran Ça | Reporting guidelines for simulation-based studies in software engineering[END_REF]. Hence, the adoption of our approach can leverage the research on empirical software engineering supported by simulations. Adopting our approach can aid in the automation of simulation-based studies, deriving stimuli generators to be applied during the simulation operation.

Stimuli generators materialize an infrastructure to support Verification, Validation and Testing (VV&T) activities in an automated way [START_REF] Anand | An orchestrated survey of References methodologies for automated software test case generation[END_REF]. They can be applied to benchmark a SoS, working as a platform for VV&T of SoS. Each transition in an atomic model can work as a test case, and data can be provided by external files that hold test cases that are automatically generated by a testing tool [START_REF] Anand | An orchestrated survey of References methodologies for automated software test case generation[END_REF][START_REF] Korel | Automated software test data generation[END_REF]. Moreover, VV&T for SoS is currently a challenging research issue and point of investigation in Software Engineering for SoS [START_REF] Lana | Systems-of-systems development: Initiatives, trends, and challenges[END_REF].

Our approach also exhibits a potential to become an architectural pattern for modeling of simulations. As stimulating a simulation is a recurrent problem, we can establish a stimuli generator as a systematic and repetitive solution that can be adapted according to the context in which it will be applied. Simulation is an important branch of Software Engineering for SoS. It exhibits a remarkable potential to be largely adopted in Software Engineering for SoS in the forthcoming years. Then, investigating potentials of automation in the coverage of tests and correctness of operation is paramount to avoid damages, losses, and financial problems that could be brought by an SoS deployed with errors. We believe that our approach can contribute to leverage the degree of trustworthiness delivered by an SoS. CHAPTER 6

CONCLUSIONS

During this PhD project, an infrastructure was developed to support the functional evaluation of SoS software architectures and to answer the research question How can we evaluate SoS software architectures at design-time?. Such infrastructure consists of (i) a solution for automatic generation of simulations for SoS software architectures with support for dynamic reconfiguration, (ii) representation of the environment and automatic generation of stimuli generators, and (iii) a means to reestablish consistency between the runtime architecture and the original SoS architectural documentation. This infrastructure supported an analysis of the impact of the SoS dynamic architecture on functionalities provided. Such analysis were performed for two different domains (Flood Monitoring and Space) using several simulations automatically obtained.

Solutions

To answer RQ1 (How can the evaluation of SoS architectures be supported) and RQ2 (How can SoS dynamics be anticipated and predicted at design-time?), in chapter 3 we proposed ASAS and described how it enabled us to evaluate SoS operation in all the simulations produced and executed. We could measure and evaluate the success fee achieved by the Flood Monitoring SoS and by Space SoS to accomplish their missions, despite their inherent dynamic architectures, and the percentage of success with which they were able to offer their functionalities (GRACIANO NETO et al., 2018b). We evaluated those architectures regarding to 1) the percentage of success with which a SoS achieves one or more missions considering its dynamic architecture and uncertainty, 2) its inherent capacity to maintain its operation in course, despite all these impacting factors, and 3) the percentage of success with which the data are transported and delivered in the final destination to be used and communicated. Moreover, we were also able to analyze results achieved by different architectural configurations, successfully predicting which architectural configuration was best for the context of a FMSoS, and confirm that increasing the number of satellites would improve the services provided by a Space SoS. We also provided a set of simulation instructions as patterns, which enabled us to automatically generate functional simulations with no conflicting specification rules (GRACIANO NETO et al., 2018c).

As SoS continuously changes its architectural arrangement due to its inherent dynamics, to answer RQ3 (How can SoS architectural description be continually consistent with its runtime configuration, despite its inherent dynamics?), in Chapter 4, we presented Back-SoS, which consists of an approach that supports the synchonization between current SoS architectural configuration and the actual SoS architectural description in SosADL (GRACIANO NETO et al., 2018a). We proposed the concept of architectural drift for SoS software architectures, and how it can be dealt with.

Finally, to answer RQ4 (How can the surrounding environment be modelled for a SoS simulation purpose?), we established Stimuli-SoS (GRACIANO NETO et al., 2016;GRACIANO NETO et al., 2017), a model-based solution to automatically derive stimuli generators from a SoS software architectural description specified in SosADL. Stimuli generators are used in simulations of SoS software architectures to make them executable, reproducing the real conditions in which those architectures should be deployed, playing the role of the SoS surrounding environment, continuously delivering stimuli to feed the SoS simulation, maintaining the SoS operation, and supporting the prediction of SoS reaction due to a diversity of stimuli that it can receive.

Limitations

This section describes limitations of this thesis and how these can be addressed in future research.

1. SosADL grammar was not fully implemented. Some language constructs such as protocols, properties, and ask/tell operators have not been exploited. Protocols and properties have not been mapped to DEVS because part of these properties is described in other parts of a SoS architectural model, and because the focus of the solution of this thesis is on the reliability under a SoS functional perspective. Ask/tell are synchronous constructions that allow SoS to tell the environment around its functionalities and to obtain from this environment functionalities available from to DEVS, simulation reliability is tied to the correctness of the SoS architectural specification. In this case, some type of inspection or evaluation must be performed by a specialist before basing the conclusions on the simulation. After all, the quality of the conclusions can be affected if the architectural specification is imprecise. We conducted peer-reviewing during SoS architectural specifications to avoid inaccuracy in specification. Moreover, our method enables monitoring SoS dynamics at runtime. Hence, simulations serve as a proof of concept for architectural specifications.

3. SosADL is an ADL, but not a ML (modeling language). Despite the advances made by SosADL, a complementary model is still needed to support architects with a visual evaluation of the SoS model. Currently, this is only possible through simulation, i.e., there is no visual architectural description prior to the simulation. In this sense, a modeling language can be constructed (based on UML Profile, for example), to use the formal foundation of the language, and provide an alternative, more intuitive and agile way of visualizing SoS architecture configurations and their dynamics.

Possible Extensions and Future Work

Several opportunities of research emerge to further the achievements of this thesis, described as follows. However, when simulations are used for the purpose of evaluating architectures (regarding their functional aspect), simulations must exercise as many as possible scenarios to which a SoS can be submitted. Otherwise, the simulation will not be reliable as an evaluation method. In this sense, a SoS software engineering test approach can be designed to help the simulation cover as many scenarios as possible, increasing the reliability of the designed solution. The need for exhaustion of the scenarios can raise branches like test case set generation and mutation analysis for this specific situation. Testing strategies for SoS simulation models must be established, as it has been proposed for embedded systems in Simulink formalism 2. SoS Architectural Evaluation Method through Non-Functional Properties with Monitoring via Simulation: As a complementary branch for cosimulation, ASAS approach can also be expanded to involve architectural evaluation about non-functional properties. A valuable outcome for software architecture community can be automatic trade-off analysis, i.e., given the non-functional properties and the percentage in which they are achieved by the SoS, how varying constituents can impact on these values, considering the optimization functions that drive such trade-off analysis.

3. Solutions were created based on simulations. Simulations are pivotal elements in the development of SoS, especially when considering the human integrity risks to which SoS users will be subjected, and the costs of acquiring a SoS and its constituent systems. However, when SoS applications start to be built and deployed in the real world, adaptations in the proposed methods will need to be performed to achieve the same results, such as generating functional constituent code, or performing automatic discovery of constituents and their available functionalities, and updating the architectural description.

4. Trustworthiness for SoS: Trustworthiness requires, in addition to the operation correctness, also the safety and security. This thesis covers only correctness in the sense that the simulation allows to validate whether the SoS is correct in terms of emergent behaviors. Security has also been dealt with for SoS context [START_REF] Hachem | Model driven software security architecture of systems-of-systems[END_REF]. Safety must also be tackled, and the association of the threefold SoS trustworthiness.

SoS Acquisition:

Cost is perhaps the primary driver to decide whether to build a SoS or to create a new specialized system [START_REF] Johnson | System health management[END_REF]. ASAS enables to evaluate the performance of different arrangements of constituents. For example, in a case study that we conducted, we concluded that using a small number of constituents could achieve the same results than using a large number of constituents. Owing to such information, it is possible to anticipate which constituents are effectively necessary to build a SoS, and predict the budget necessary to acquire them. Hence, ASAS can also be extended to have a finantial prediction branch;

6. Systems-of-Information Systems (SoIS) modeling and evaluation: A SoIS is a set of interoperable Information Systems (IS) that are combined to achieve some broader business value and/or to exploit some business opportunity (CARLSSON; [START_REF] Carlsson | On the nature, function and composition of technological systems[END_REF][START_REF] Breschi | Sectoral innovation systems: technological regimes, schumpeterian dynamics, and spatial boundaries[END_REF][START_REF] Breschi | Sectoral innovation systems: technological regimes, schumpeterian dynamics, and spatial boundaries[END_REF][START_REF] Saleh | Information Systems: Towards a System of Information Systems[END_REF][START_REF] Saleh | Information Systems: Towards a System of Information Systems[END_REF][START_REF] Majd | An architectural model for system of information systems[END_REF][START_REF] Majd | An architectural model for system of information systems[END_REF]ALOK, 2015). A SoIS is formed from a specific cluster of the firms, technologies, and industries involved in the generation and diffusion of new technologies and in the knowledge flow that takes place among them. Under this perspective, SoIS have a strong business nature (GRACIANO NETO; OQUENDO; NAKA-GAWA, 2017). As SoIS are often formed by constituent systems that are managed and operated by independent organizations and they can cooperate to accomplish inter-organizational missions and, as a consequence, inter-organization business processes. This raises the need of establishing representation and management strategies to support concepts such as sequence of activities and interdependence between roles and goals (GRACIANO NETO et al., 2017). ASAS must also be extended to deal with such specific types of SoS. Regarding the transformation of data types, Xtend code in Listing 12 establishes the following strategy: if the type of data is not an ADT (Line 2), by default, it will be converted to an Integer type (Lines 3-5). Xtend accesses the name of the data type available in the Abstract Syntax Tree and substitutes it in the appropriate places in the template of DEVSNL code (Line 3, Listing 12). In DEVSNL, a simple type has a value (as specified in Line 3), and tfhe range of this type (in case of simple types) is Integer (Line 4). A variable of such a type is declared in another statement to be used for processing purposes (Line 5). Statements in DEVSNL end with an exclamation mark. Conversely, if the data type specified in SosADL is a tuple (such as Coordinate (Line 4), and Measure (Line 6) in Listing 11), then are executed. In this case, a type declaration in DEVS receives the name of the data type in SosADL, and their fields through an iteration structure (Lines 10-12 in Listing 12), and lines, such as Lines 11-14 in Listing 13, are generated.

Lines 18-31 in Listing 12 buffer the definitions of ports and state transitions in DEVSNL to be printed at the end of the process (this detail is hidden from the code presented). If the transformation consists of an input transition, the code in Lines [START_REF] Lara | Formal support for model driven development with graph transformation techniques[END_REF][START_REF]Comparison between related approaches[END_REF][START_REF][END_REF][22][START_REF]A sample of data sent by sensors[END_REF][START_REF]Comparison between co-related approaches[END_REF][25] are executed. If it consists of an output transition, the are executed. Since the specification of a state diagram in DEVSNL follows a declarative style, the order of the instructions generated in DESVNL does not matter. The concepts of duty and gate are suppressed in DEVSNL. Therefore, the Xtend code takes the name of the connections in SosADL and uses them (Lines 21 and 27, Listing 12) to create ports in DEVSNL. The type of data received or sent are used in the typification of the data to be transmitted in a DEVS port (Lines 21 and 27, Listing 12). Receive instructions in In DEVS, transitions can occur due to (i) a data received (expressed as ?data), (ii) a data sent (expressed as !data), and (iii) a spontaneous transition, with no input or output event. Listing 14 illustrates a behavior called sensing of a smart sensor, which senses the depth of the water in a river and is a constituent within the context of FMSoS. Line 2 is an assignment statement in which a coordinate called lps is assigned to a variable called sensorcoordinate. In Line 3, the lps assigned to a sensorcoordinate in Line 2 is sent via a connection called a coordinate that has a gate called a location. Line 6 depicts a repeat statement in which the powerlevel is received via a connection called power in a gate called energy. The system receives the battery level to test whether the energy is enough to perform the instructions. Line 8 tests if the power level is above an established threshold. Within the scope of the conditional statement, a choose statement (Lines 9 to 16) is triggered if the condition returns a true value. System will behave depending on the stimulus received: if it receives a data delivered by its own sensor, Line 10 is executed, and the data is received via a connection called sense at the gate called measurement. This data is forwarded to the closest mediator towards the gateway via the connection measure (Lines [11][START_REF] Fp) Graciano | Web Enterprise Information Systems Engineering -A Path and the Road Ahead[END_REF]. If the sensor receives a data collected by another sensor and transmitted across the SoS, Line 14 is executed. The data are received via a connection called pass at the gate measurement and forwarded via the connection called measure at the same gate (Line 15).

A mapping from a SosADL behavior for a DEVS code produces a state diagram. To illustrate this procedure, we depict a state diagram in Figure 40 that corresponds to subsequently mapped in a coupled model, which is a set containing a decomposition and couplings.

Listing 16 depicts a SosADL code that represents the specification of a software architecture of an FMSoS. In Listing 16, the software architecture of SoS represented comprises four sensors, one gateway, and four transmitters (types of mediators) (Lines 4 to 12). bindings (Lines 13 to 23) represent the way connections between constituents and mediators are established through gates, and SoS dynamics for data transmission until a gateway. A sensor collects the water level through actuators, encapsulating it with the specific location in which the collecting was performed, and with a time stamp. The sensor then transmits the data to the closest mediator, which forwards it to the next sensor, until the gateway has been reached. In SosADL, a connection is specified as system :: gate :: connection. Indeed, the same gate can hold one or more connections. An unification is established for each pair of sensors with a mediator between them by a unify statement (Lines [15][16][17][18][START_REF] Lara | Formal support for model driven development with graph transformation techniques[END_REF][START_REF]Comparison between related approaches[END_REF][START_REF][END_REF][22][START_REF]A sample of data sent by sensors[END_REF]. According to such statements, an output connection measure from the gate measurement is linked to the input connection fromSensors of the closest mediator. A mediator gathers data from a sensor (Lines 11 to 14) and forwards it to the next sensor. Mediators have an output connection termed as towardsGateway. Such connections are linked to the sensors through an input connection called pass in the gate measurement, which enables it to receive the data transmitted and forward them to the gateway ( Lines 16,18,20 and 22). Lines 22 and 23 link the output connection of the mediator to the gateway connection called measure. In this case, a mediator mediates a constituent and the gateway. The relay statement establishes the communication between the SoS and external systems, connecting the notification gate of a gateway to one external connection.

Listing 17 provides the rules for the transformation of a specification of an FMSoS software architecture into a coupled model in DEVS. It depicts three transformation rules: one that receives a SosADL type called ArchitectureDecl as input, one that receives an ArchBehaviorDecl as input, and one that compiles the Unify statements. Lines 1 to 5 produce the first line of the DEVS code which declares a Decomposition. It takes the name of the architecture, puts it in upper case, and delivers the remaining part to next transformation rules4 . In the second transformation rule (Lines 7 to 20), a list of the systems that compose the architecture is enumerated in the DEVS target model (Lines 12 to 15), thus completing the DEVS Decomposition. Bindings are compiled in the next transformation rule (Lines 21 to 50) invoked in Line 17. The compilation of the unifications, i.e., the specification of the data exchanged between systems involved in the SoS, proceeds as follows: both sender and the receiver names are required for the documentation of the communication between systems in DEVS. They are separated from the data available in the unifications, using the :: as a marker that splits the String (Lines 23 to 33). However, the type of data transferred between two systems in the SoS must be known so that the simulation code can be specified. This data is not available in the architecture specification in SosADL, but it is available in the specification of the constituents and mediators in SosADL.

Line 35 hides a code that opens a file containing a specification of the connections and their respective data types. The code in Lines 37 to 44 compares the name each pair gate-connection with the gates and connections specified in the coalition, inferring the type of data that they transmit. This data is assigned to the variable data when it is found (Line 42). Line 46 shows the format of the output String, with sender, receiver, and data, and Line 49 prints the result. The transformation rule for Unify is called as many times an operational SoS architecture; (iii) substitutes the constituents of the simulation for another constituent by removing the constituent and replacing it to the architecture being simulated; and (iv) reorganizes the architecture by removing all connections and mediators and thereafter establishing different mediated connections to create a new architectural configuration while retaining the initial architectural properties. For addition of a constituent, it is necessary to send a signal to the controller to add it to the simulation. When an addition is invoked by the controller, mediators are also created to establish the communication between the existing constituents and the new one that is being added to the SoS. Stimuli generators also can be added during this process to feed the new constituents with the data necessary to trigger its interaction within the SoS simulation.

For the removal, a signal is sent to the constituent to be removed. As a response, this constituent sends a reference of its own simulation object to the controller, enabling direct access so that it can be removed. Mediators and connections that communicate

  -clés: Systèmes de systèmes, SoS, architecture logicielle, simulation, évaluation. APPENDIX B Specification and Details on Transformation of SoSADL models into DEVS models . . . . . . . . . . . . . . . . . . . . . . . B.0.1. Generation of atomic models . . . . . . . . . . . . . . . . . . . . . . B.0.2. Generation of coupled models . . . . . . . . . . . . . . . . . . . . . . B.0.2.1. Dynamic reconfiguration controller structure . . . . . . . . . APPENDIX C A Satellite specified in SosADL . . . . . . . . . . . . . . . . . 1 CHAPTER 1

2 Chapter

 2

1. 1 .

 1 Problem Statement and Justification for the Research

Figure 1 -

 1 Figure 1 -Scientific methodology.

Figure 2 -

 2 Figure 2 -Proposed solutions.

Figure 2

 2 Figure2summarizes the contributions of this thesis, which are a compilation of three separate solutions. The solutions were designed to match the highlighted problems. Those solutions comprise:

Figure 4 -

 4 Figure 4 -An excerpt of SosADL abstract syntax (GRACIANO NETO, 2016).

1 .

 1 SoS simulation, 2. Specification of dynamic architectures, 3. Multiple constituents modeling, 4. Constituents interoperability modeling, and 5. SoS software architecture specificities and precision, including environment modeling.

Figure 5 -

 5 Figure 5 -An approach for the transformation of SosADL models into DEVS simulation models (GRACIANO NETO, 2017).

Figure 6 -

 6 Figure 6 -Patterns expressed as diagram classes in UML.

Figure 6

 6 Figure 6 depicts our patterns expressed as UML class diagrams. DEVS Input rules specify a PassivateRule that passivates in one and only one state, whose name is represented by a label. From this state, an InputTransition occurs when a pre-determined

3. 1 .1 5

 15 Presentation of ASAS Approach 59 From the top perspective , F l o o d M o n i t o r i n g S o s A r c h i t e c t u r e is made of 2 Sensor1 , Sensor2 , Sensor3 , Sensor4 , Gateway , Mediator1 , Mediator2 , Mediator3 , 3 and Mediator4 ! 4 From the top perspective , Sensor1 sends Measure to Mediator1 ! 6 From the top perspective , Mediator1 sends Measure to Sensor2 ! 7 From the top perspective , Sensor2 sends Measure to Mediator2 ! 8 From the top perspective , Mediator2 sends Measure to Gateway ! 9 From the top perspective , Sensor3 sends Measure to Mediator3 ! 10 From the top perspective , Mediator3 sends Measure to Sensor4 ! 11 From the top perspective , Sensor4 sends Measure to Mediator4 ! 12 From the top perspective , Mediator4 sends Measure to Gateway ! Source code 4 -Coupled model for FMSoS generated in DEVS.

Chapter 3 .Figure 7 -

 37 Figure 7 -Illustration of the addition of a constituent in a simulation of SoS software architecture.

Figure 8 -

 8 Figure 8 -Process of remotion of constituent in a simulation of a SoS software architecture.

Figure 9 -

 9 Figure 9 -Substitution of constituent in the simulation of a SoS.

Chapter 3 .Figure 10 -

 310 Figure 10 -Process of reorganization of architecture in the simulation of a SoS software architecture.

Figure 11 -

 11 Figure 11 -An illustration of the relation between DRC and constituents simulated.

  duces different architectural configurations (coalitions). This question investigates if the approach supports the comparison of different architectural configurations, and election of the one that best suits SoS needs. Metric M2.1 Accuracy, the percentage in which the SoS operat ion is reliable in a diversity of architectural configurations for the achievement of their pre-defined missions; Metric M2.2 Data loss, i.e., the percentage of data that does not arrive in the final destination due to data collision; Metric M2.3 Scale: Number and diversity of constituents achieved by SoS during its simulation; and Metric M2.4 Support for decision on architectural configuration, whether the simulation enables collection of data and analysis to decide which architectural configuration offers best results.

Figure 12 -

 12 Figure 12 -A flood monitoring system-of-systems (FMSoS) (GRACIANO NETO et al., 2016).

Chapter 3 .

 3 ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

Figure 13 -

 13 Figure 13 -Relation between percentage of data received in gateways and alerts triggered.

Chapter 3 .

 3 ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

Figure 14 -

 14 Figure 14 -Relation between data received in one or more gateways and SoS scale.

Chapter 3 .Figure 15 -

 315 Figure 15 -Box plot for data received for 50 different architectural configurations.

Chapter 3 .Figure 16 -

 316 Figure 16 -Illustration of a Brazilian SoS for data collection via satellites (INPE, 2017).

Figure 17 -

 17 Figure 17 -Activity diagram of the business process followed by a space SoS for the monitoring of the Amazon.

Tables 10 ,

 10 11, and 12 show the results of percentage of data transmitted to the satellite, percentage of data received, simulation time; data loss; and data on telecommands, respectively. No telecommand was lost.RQ1: Can the transformation successfully produce functional simulation mod-Chapter 3. ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems els?

Figure 19 -

 19 Figure 19 -Three orbital trajectories containing two satellites each (CARVALHO et al., 2013).

Chapter 3 .

 3 ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

Chapter 3 .Figure 20 -Figure 21 -

 32021 Figure 20 -Comparison between data obtained in case study: simulation time.

Figure 22 -Figure 23 -

 2223 Figure 22 -Number of architectural changes at runtime.

Chapter 3 .

 3 ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

Figure 24 -

 24 Figure 24 -Relation between accuracy and data loss.

Chapter 3 .

 3 ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

Figure 25 -

 25 Figure 25 -An illustration of communication between DCP and a satellite.

Chapter 3 .

 3 ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

  23 HLA (High Level Architecture) is an IEEE standard(IEEE 1516(IEEE -2010;; IEEE 1516 IEEE .1-2010;; IEEE 1516 IEEE .2-2010) ) providing a general architecture for the implementation of distributed simulatons (BOCCIARELLI; D'AMBROGIO, 2014), a distributed simulation (DS) formalism. HLA provides the specification of a common technical architecture for use across all classes of simulations in the US Department of Defense (DoD)[START_REF] Dahmann | High level architecture for simulation[END_REF] IEEE, 2010).

Chapter 3 .

 3 ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

Chapter 3 .

 3 ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

Chapter 4 .

 4 Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and Prescriptive Models of Systems-of-Systems Software Architectures

Figure 26 -

 26 Figure 26 -Model discovery mechanism for SoS software architectures.

Step 4 .

 4 Architectural consistency checking: After the prescriptive model (architectural instance part) is updated, mechanisms must check whether the new version of the concrete SoS architectural description (propagated to the current architectural instance) still conforms to the original SoS abstract architecture. If yes, the processes is finished until a new change at runtime occurs. If not, a new architectural configuration is sought and reverse transformed until a right one emerges to match the original abstract architecture.Step 1 requires a characterization of changes that can cause deviations in a SoS software architectures, and the creation of a model recovery and discovery mechanism to automatically recover SoS architectural configuration elements, and link them to materialize the current architectural configuration (also achieving a model discovery mechanism for SoS). Hence, Section 4.1.1 reports the characterization of architectural drifts that we created and used to establish model recovery and discovery mechanisms (discussed in Section 4.1.2) for SoS architectures at runtime. Step 2 (architectural evaluation) is briefly discussed in Section 4.1.3, as it is presented in Chapter 3. Section 4.1.4 details the reverse model transformation used in Step 3 (Reconciliation), and Section 4.1.5 discusses mechanisms to check architectural consistency in Step 4.

Chapter 4 .

 4 Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and

Figure 27 -

 27 Figure 27 -Model discovery mechanism for SoS software architectures.

Chapter 4 .

 4 Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and Prescriptive Models of Systems-of-Systems Software Architectures 23-39 in Listing 7).

4. 1 .3

 1 Presentation of Back-SoS Approach 113 From the top perspective , Mediator1 sends Measure to Sensor2 ! 4 From the top perspective , Sensor2 sends Measure to Mediator2 ! 5 From the top perspective , Mediator2 sends Measure to Gateway ! 6 From the top perspective , Sensor3 sends Measure to Mediator3 ! 7 From the top perspective , Mediator3 sends Measure to Sensor4 ! 8 From the top perspective , Sensor4 sends Measure to Mediator4 ! 9 From the top perspective , Mediator4 sends Measure to Gateway ! Source code 6 -Coupled model for FMSoS generated in DEVS.

114 Chapter 4 . 26 }

 114426 17 unify one { mediator1 :: transmit :: measure } to one { sensor2 :: → measurement :: measure } and 18 unify one { sensor2 :: measurement :: measure } to one { mediator2 :: → transmit :: measure } and 19 unify one { mediator2 :: transmit :: measure } to one { gateway :: → notification :: measure } and 20 unify one { sensor3 :: measurement :: measure } to one { mediator3 :: → transmit :: measure } and 21 unify one { mediator3 :: transmit :: measure } to one { sensor4 :: → measurement :: measure } and 22 unify one { sensor4 :: measurement :: measure } to one { mediator4 :: → transmit :: measure } and 23 unify one { mediator4 :: transmit :: measure } to one { gateway :: → notification :: measure } 24 } Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and Prescriptive Models of Systems-of-Systems Software Architectures 25 } Source code 7 -Coalition specified in SosADL.

20 /

 20 / ' lone ' (none or one) , some ' (one or more) , ' a l l ' 23 } 24 } guarantee { . . . } Source code 8 -A SoS abstract architecture specified in SosADL.

Chapter 4 .

 4 Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and Prescriptive Models of Systems-of-Systems Software Architectures

Chapter 4 .

 4 Figure 28 -An illustration of the initial state of the FMSoS architectural configuration.

Step 4 .

 4 Architectural consistency checking: SA4, SA5, and SA6 perform a manual architectural consistency checking. After the prescriptive model (architectural instance) documented in SosADL is created as outcome of reverse transformation, software architects check whether the new version of the concrete SoS architectural description (propagated to the current architectural instance) still conforms to the original SoS abstract architecture. If yes, the processes is finished until a new change at runtime occurs. If not, a new architectural configuration is sought and reverse transformed until a right one emerges to match the original abstract architecture.

Chapter 4 .

 4 Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and Prescriptive Models of Systems-of-Systems Software Architectures of a the first architectural configuration shown in

Figure 29 -

 29 Figure 29 -Excerpt of a FMSoS architecture restored through reverse transformation (part of the code is hidden for the reader convenience).

Figure 30 -

 30 Figure 30 -Relation between number of constituents and mutation coefficient.

122Chapter 4 .

 4 Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and Prescriptive Models of Systems-of-Systems Software Architectures

Figure 31 -

 31 Figure 31 -Average of mutation coefficient samples.

Chapter 4 .

 4 Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and Prescriptive Models of Systems-of-Systems Software Architectures

Chapter 5 .

 5 Stimuli-SoS: A Model-Based Approach for Automatic Creation of Stimuli Generators in Simulations of Software Architectures of Systems-of-Systems

Figure 32 -

 32 Figure 32 -SoSADL2DEVS transformation (GRACIANO NETO, 2017).

5. 1 .

 1 Figure 33 -Stimuli-SoS workflow.

Chapter 5 .

 5 Stimuli-SoS: A Model-Based Approach for Automatic Creation of Stimuli Generators in Simulations of Software Architectures of Systems-of-Systems

Figure 34 -

 34 Figure 34 -A flood monitoring system-of-systems (FMSoS) Architecture.

Figure 35 -

 35 Figure 35 -An illustration of part of a FMSoS.

Chapter 5 .

 5 Stimuli-SoS: A Model-Based Approach for Automatic Creation of Stimuli Generators in Simulations of Software Architectures of Systems-of-Systems

Chapter 5 .

 5 Figure 36 -A real picture of a human dummy used to classify floods risk.

Figure 37 -

 37 Figure 37 -Water level with a human dummy.

5

  http://www.ms4systems.com/pages/ms4me.php Chapter 5. Stimuli-SoS: A Model-Based Approach for Automatic Creation of Stimuli Generators in Simulations of Software Architectures of Systems-of-Systems simulation models.

7Figure 38 -

 38 Figure 38 -Illustration of how an automaton is derived from SoSADL system specification to create a functional stimuli generator.

Chapter 5 .

 5 Stimuli-SoS: A Model-Based Approach for Automatic Creation of Stimuli Generators in Simulations of Software Architectures of Systems-of-Systems

Figure 39 -

 39 Figure 39 -Monitoring depth of water in simulation during data processing.

Chapter 5 .

 5 Stimuli-SoS: A Model-Based Approach for Automatic Creation of Stimuli Generators in Simulations of Software Architectures of Systems-of-Systems Soyez et al. propose an agent-based tool to support modeling of static and dynamic aspects of SoS

5. 4 .

 4 Final Remarks and Forthcoming Steps 157 2. were capable of receiving input data from the database and generating expected stimuli for the constituents, triggering the SoS;3. were capable of correctly supporting an entire simulation execution; and 4. reproduce the environmental conditions of an SoS to become simulations functional without manual intervention.

Chapter 5 .

 5 Stimuli-SoS: A Model-Based Approach for Automatic Creation of Stimuli Generators in Simulations of Software Architectures of Systems-of-Systems

  DELAMARO;[START_REF] Baresi | Test oracles for simulink-like models[END_REF], and are still scarce for DEVS formalism(LI et al., 2011);

208

  APPENDIX B. Specification and Details on Transformation of SoSADL models into DEVS models

  2011)), evaluating SoS architectural descriptions based on the simulations produced by our transformation approach, and through a an evaluation method so-named ASAS (A Model-Based Approach to Simulate and Evaluate Software Architectures of Systems-of-systems). The main aim of ASAS approach is the support for the evaluation of SoS software architectures for increasing the level of trustworthiness for SoS. The core of ASAS is a model transformation that receives SoSADL models as input and produces simulation models documented in DEVS (GRACIANO NETO et al., 2018b); 2. Specification of patterns for conception of functional DEVS simulations with no conflicting rules -engineering simulations can be unfruitful, as many instructions can be conflicting and simulation guides do not use to teach how to engineer such type of software. We discovered and reported patterns to guide how to engineer SoS simulations, and encapsulated them in the model transformation used in ASAS approach to automatically generate consistent simulations. Moreover, such knowledge can be reused to specify other simulations that use DEVS formalism.

2 (MOHAMMADI et al., 2014; KUMAR; KHAN; KHAN, 2015; HASSELBRING; REUSSNER, 2006; NAMI; SURYN, 2013; MICHAEL 2

In our research, we do not focus on other aspects such as security, privacy, data, or usability et al., Results were reported in a conference paper (GRACIANO NETO et al., 2018c); 3. A mechanism for supporting SoS dynamic architectures -we proposed SoS dynamic architecture canonical operations, and supported SoS simulation comprising all such operators, reproducing at runtime how a SoS could behave when deployed in the real world (MANZANO; GRACIANO NETO; NAKAGAWA, 2018) (such mechanism is included in ASAS); 4. Stimuli-SoS, a method for representation of the SoS surrounding environment and automatic creation of stimuli generators to sustain SoS simulations -the surrounding environment is an important concern for SoS, as it directly impacts on the way they perform their activities. As a software architecture description often documents environmental issues at some level, we automatically create structures that continuously produce stimuli for SoS simulation, anticipating possible failures, imitating the environment, and reducing costs of an early and inadvisable SoS deployment (GRACIANO NETO et al., 2016; GRACIANO NETO et al., 2017); 5. Back-SoS, a mechanism for reconciliation between current SoS and its respective architectural documentation through a backward model transformation -as a SoS progresses its operation, new architectural configurations take place, arising inconsistencies between original architectural documentation and current one. A backward model transformation was established, together with mechanisms for model recovery, discovery, and reconciliation, for realign both models, the runtime, and the original (GRACIANO NETO et al., 2018b).

20

  Chapter 2. State of the Art on Model-Based Software Engineering for Systems-of-Systems Figure3-Formalisms and models used in studies of MBSE for SoS, as shown in Table1.

Table 1 -

 1 Transformations for SoS domain (Entries marked with asterisk (*) represent that transformations are actually mentioned or considered as a possibility of future work, but not performed).

	Study ID		Types	Source languages and models:	TARGET Languages and Mod-
			of		els
			trans-
			forma-
			tions
	(BAY, 2002)	M2T	MATLAB	Code for Embedded systems
	(TOLK;	DIALLO;	M2M	Ontology	Ontology
	TURNITSA, 2007)*
	(GOKHALE et al.,	M2M,	COMPASS to OCML+EQAL, and	XML code for Middleware for
	2008)		M2T	later to XML (target)	deployment purposes
	(DICKERSON;	M2M	SysML	SySML
	VALERDI, 2010)
	(CALINESCU;	M2T	Metamodels in XML	C# .NET
	KWIATKOWSKA,
	2010)
	(GE et al., 2012)	M2M	DoDAF Metamodel (DM2) -Core	Colored Petri Nets (CPN)
				Data Elements
	(GEZGIN	et al.,	M2M	Mechatronic UML	Mecnatronic UML
	2012)
	(BARBI et al., 2012) M2T	Ecore, GMF, + OCL	XML
	(HOLDEN; DICK-	M2M	SysML	Tactical Situation/Mission Sce-
	ERSON, 2013)*			nario (TacSit/MS) Models
	(BRYANS et al.,	M2M	SySML	CML
	2013; BRYANS et al.,
	2014a; BRYANS et
	al., 2014b)
	(ANDREWS et al.,	M2M	SysML	CML
	2013)
	(HELLESTRAND,	M2M,	Vehicle Dynamics Model (VDM)	Specification-Based	Architec-
	2013)		M2T		tures, Finite state machines,
					and software code for Electronic
					Control Unit (ECU)
	(MOOIJ; VOORHO-	M2T	Petri-Net Models	Executable Adapters
	EVE, 2013)
	(HU et al., 2014a; HU	M2M,	UML/SySML Activity Diagram	DEVS -> DEVS
	et al., 2014d; HU et	M2T	(AD) -> SoaML ->
	al., 2014c)
	(BELLOIR et al.,	M2M,	Textual to RELAX, RELAX to	KAOS to OrBAC or KAOS to
	2014)*		M2T	KAOS	SySML (transformation chain,
					but as a possible work)
	(BROWN	et al.,	M2M	SySML, UML	Simulink
	2015)*
	(GROGAN; WECK,	M2M	HLA (High-Level Architecture)	FOM
	2015)			(IEEE, 2010)
	(BADDOUR; PAS-	M2M,	SySML and Statecharts	SystemC
	PALIARIS;	HER-	M2T
	RERA, 2015)
	(GRACIANO	M2M	SosADL	DEVS
	NETO, 2016)
	(GUESSI;		M2M	SosADL+Alloy	SosADL
	OQUENDO; NAKA-
	GAWA, 2016)
	(GRACIANO NETO	M2M	SosADL	DEVS
	et al., 2017)
	(SILVA;	CAVAL-	M2M	mKAOS	SosADL
	CANTE; BATISTA,
	2017)
	(GRACIANO NETO	M2M	SosADL	DEVS
	et al., 2018b)

:

  Abstract Syntax Development: Net4J 11 , Teneo 12 ; Concrete Syntax Development: Graphical Modeling Framework 13 , Graphiti 14 , Xtext 15 (BETTINI et al., 2013); Model Development: BPMN2 16 , eTrice 17 , MoDisco 18 , OCL 19 , Papyrus 20 , Sphinx 21 ; Model Transformation: ATL (M2M) 22 , Acceleo 23 , JET 24 , Xpand (M2T) 25 ; Technology and Research: Atlas MegaModel Management 26 , Atlas Model Weaver 27 , MOFScript 28 , VIATRA2 29 , Epsilon 30 ; Barbi et al. created a tool called ACTUAL (Automation of the Configuration and deploymenT of distribUted AppLications) based on GMF to implement the transformations from models to configuration files (BARBI et al., 2012). Mooij and Voorhoeve model a SoS using Petri net models in a tool called Marlene (MOOIJ; VOORHOEVE

Table 2 -

 2 Comparison between formalisms for SoS simulation and software architecture specification considering aforementioned language requirements.

	Approach	1	2	3	4	5
	Simulink/MATLAB	Yes	No	Yes	Yes	No
	SysML	Yes	No	Yes	Yes	No
	UML/Executable UML	Yes	No	Yes	No	No
	DEVS (ZEIGLER et al.,	Yes	Yes	Yes	Yes	No
	2012)
					Yes	No
	SoSADL	No	Yes	Yes	Yes	Yes

(ALLEN;

GARLAN, 1997)

, π-ADL (formal)

[START_REF] Oquendo | π-ADL: An Architecture Description Language Based on the Higher-order Typed π-calculus for Specifying Dynamic and Mobile Software Architectures[END_REF]

, UML 31 (semi-formal), SySML 32 (semi-formal), and SoSADL (OQUENDO, 2016a) (GUESSI

Table 3 -

 3 Mapping between SosADL and DEVS.

	SoS concept	SosADL	DEVS
	Capability	Behavior Declaration Atomic Model Behav-
			ior
	Connection	Connection Declara-	DEVS Port
		tion
	Constituent System	System Declaration	Atomic Model
	Data Types	Data Type Declara-	Data Type
		tion
	Function	Function Declaration	DEVS Function
	Gate	Gate Declaration	DEVS Port
	Mediator	Mediator Declaration Atomic Model
	SoS Architecture	Coalition	Coupled Model

  Source code 1 -Code in SosADL for a mediator. Lines 2-6 in Listing 11 represent the definition of data types in SosADL. Data types are transformed by Lines 1-16 in Listing 12 to produce Lines 1-22 in Listing 13. Lines 8-16, which specify the connections and duties (gates) of a mediator in SosADL in Listing 11, are transformed into Lines 24-27 in Listing 13, whereas Lines 18-23, which represent the behavior of a mediator specified in SosADL in Listing 11, are transformed into Lines 24-42 in Listing 13. A Distance has a value ! the range of Distance ' s value is Integer ! use distance with type Distance ! A Abscissa has a value ! the range of Abscissa ' s value is Integer ! use abscissa with type Abscissa ! A Ordinate has a value ! the range of Ordinate ' s value is Integer ! use ordinate with type Ordinate ! Coordinate has x and y ! the range of Coordinate ' s x is Abscissa ! the range of Coordinate ' s y is Ordinate ! use coordinate with type Coordinate ! A Depth has a value ! the range of Depth ' s value is Integer ! use depth with type Depth ! Measure has coordinate and depth ! the range of Measure ' s coordinate is Coordinate ! the range of Measure ' s depth is Depth ! use measure with type Measure ! accepts input on FromCoordinate with type Coordinate ! accepts input on ToCoordinate with type Coordinate ! accepts input on FromSensors with type Measure ! generates output on Measure with type Measure ! Source code 2 -An atomic model for a mediator generated in DEVSNL.

	3.1. Presentation of ASAS Approach	51
	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 } to start hold in s0 for time 1! mediator Transmitter ( d is tancebetweengates : Distance ) is { datatype Abscissa datatype Ordinate datatype Coordinate is tuple { x : Abscissa , y : Ordinate } datatype Depth datatype Measure is tuple { coordinate : Coordinate , depth : Depth } duty transmit is { connection fromSensors is in { Measure } connection towardsGateway is out { Measure } } duty location is { connection fromCoordinate is in { Coordinate } connection toCoordinate is in { Coordinate } } behavior transmitting is { via transmit :: fromSensors receive measure via transmit :: towardsGateway send measure } hold in s0 for time 1! from s0 go to s1 ! //Unobservable passivate in s1 ! when in s1 and receive Coordinate go to s2 ! passivate in s2 ! when in s2 and receive Coordinate go to s3 ! 37 when in s3 and receive Measure go to s4 ! 38 hold in s4 for time 1! 39 after s4 output Measure ! 40 from s4 go to s5 ! 41 hold in s5 for time 1! via location repeat { } 42 from s5 go to s3 ! //Unobservable
	passivate in s3 !

:: fromCoordinate receive coordinate 20 via location :: toCoordinate receive coordinate Chapter 3. ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

  Chapter 3. ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems a well-defined set of primitives. A state in DEVS can be either a 'hold state', or a 'passive state' (exclusively). The execution flow is maintained at a hold state for a certain amount of time until it is automatically changed to another state (via an internal transition). On the other hand, in a passivate state, simulation remains indefinitely (or until it receives a message that triggers an external transition). Below are the basic constructs for a state machine in DEVS: Passivate State (PS). State in which the execution flow remains until some event (input or output) has caused a transition to another state. Transition that defines an input message the model might receive. Such a message causes a transition from a state to another. Both states and the expected input message must be specified. Any state can have one or more external transitions defined. The syntax is:

	when in FROMSTATE and receive INPUTMESSAGE go to TOSTATE !

passivate in STATENAME ! Hold State (HS). State in which the execution flow remains for a well-defined time, such as 5 seconds. hold in STATENAME for time 5! Initial State (IS). State marked as initial for the simulation execution. A simulation holds only one initial state specified by the following syntax: to start passivate in STATENAME ! or to start hold in STATENAME for time 5! Internal Transition (IT). A simple transition that specifies the current state and a next state. Every HS must exhibit one internal transition. from FROMSTATE go to TOSTATE ! Output Transition (OT). A transition that produces an output of a message prior to the internal transition. after STATENAME output OUTPUTMESSAGE ! External Transition (ET).

Table 4 -

 4 Conflicts and compatible instructions in DEVS.

Table 5 -

 5 Patterns for input in DEVS simulation models.

  7 during the transformation. If the SosADL code Chapter 3. ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

	Name	DEVS Output
	Recurrent Problem Specification of a set of simulation instructions that char-
		acterize an output event without conflicts with other
		instructions.
	Solution
		hold in s < < fromState > > for time 1!
		after s < < fromState > > output <<
		→ dataType > >!
		from s < < fromState > > go to s < < toState
		→ > >!

Table 6 -

 6 Output pattern for DEVS simulation models.

Table 7 -

 7 Mapping of SosADL into DEVS. In SosADL, the list of all constituent systems that compose the software architecture of an SoS is represented by a Coalition. By definition, coalitions are alliances of constituents connected via mediators. When translated into DEVS, coalitions are mapped into a DEVS Decomposition, i.e., a statement of the coupled model that systematically lists all inner structures (e.g., systems, mediators, among others) that form the software architecture of the SoS[START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF]. .e., connections with a specific type of data. Data types must be preserved by the transformation and properly converted into DEVS format.Gate/Connection. Gates are a structure through which connections can be established.

	SoS concept	Representation in	DEVS
		SosADL
	Constituent Systems	Coalition	Decomposition
	Data Types	Data Type	Data Type
	Gate/Connection	Gate/Connection	DEVS Port
	Interfaces	Binding	Coupling
	SoS Architecture	Coalition + Binding	Coupled Model
	Constituent Systems.

Data Types. When a communication is established between constituents and they start to interoperate, data are exchanged between them. Indeed, SoSADL relies on typed 8 xtend-lang.org/ 3.1. Presentation of ASAS Approach 57 connections, i

  Table 8 illustrates a numerical instance. It corresponds to real data that arrived sequentially at the gateway. Data that arrive are chronologically ordered, and pairs of data are analyzed. If at least one pair has two measures equal or greater than 100 cm, a flood is confirmed. Subsequent measures will confirm if it is an actual flood or not.

Table 8 -

 8 A sample of data collected by a sensor and sent to a gateway.

	sample	sensor timestamp	depth
	id			(cm)
	#1	S2	2015-11-23 01:58 58

  Chapter 3. ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems

	3. Ground Station configures antennas and rotors;
	4. Ground Station establishes links with Satellite;
	5. Ground station sends remote control;
	6. Satellite executes commands;
	7. Satellite stores payload data;
	8. Ground Station requests payload data;
	9. Satellite forwards telemetry data;
	10. Ground Station stores raw data;
	11. Remote Sensing Data Center searches for telemetry data;

12. Remote Sensing Data Center tags and stores data; 13. Remote Sensing Data Center distributes payload data to the Mission Center.

Table 9 -

 9 14 <http://sinda.crn2.inpe.br/PCD/SITE/novo/site/index.php> Number of DCP constituents and data for each space SoS architectural configuration. Chapter 3. ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems queries, and collected one-year data within the data availability period for each DCP platform. Such data refer to the 75 DPC stations in São Paulo state, 51 stations in Minas Gerais, and 12 in Rio de Janeiro, which totaled 138 PCD stations (constituents) that compose the initial architecture of the Space SoS.

	3.2. Evaluation

Figure 18 -Brazilian territory map adapted from (DNIT, 2017).

Table 10 -

 10 Percentage of data transmitted to the satellite and simulation time.

	3.2. Evaluation

Table 11 -

 11 Data loss for the space SoS simulation.

	# Data Loss	Data Loss	Data	Percentage	Percentage	Percentage
	(Land	(Water	Loss	of	Data	of	Data	of	Data
	DCP)	DCP)	(To-	Loss (Land	Loss (Wa-	Loss (To-
			tal)	DCP)		ter DCP)	tal)
	1 2,749	2,214	4,963 5.03%		6.26%		5.51%
	2 3,118	2,269	5,388 5.53%		5.50%		5.52%
	3 4,792	3,475	8,267 6.44%		6.59%		6.50%
	4 6,573	6,037	12,610 8.56%		6.34%		7.33%
	5 6,077	18,708	24,786 7.20%		11.77%	10.18%

Table 12 -

 12 Telecommands in space SoS simulation.

	# Telecommands	Telecommands	Pictures	Pictures	Pictures	Pictures
	sent	Received	Cap-	Not Cap-	returned	not	re-
			tured	tured	to Ground	turned to
					Station	Ground
						Station
	1 4,000	4,000	3,996	4	3,095	1
	2 4,000	4,000	4,000	0	3,994	6
	3 4,000	4,000	3,998	2	3,995	3
	4 4,000	4,000	3,999	1	3,994	5
	5 4,000	4,000	4,000	0	3,998	2
	to /dev/null, otherwise the simulation would be slow. The satellite passed over each DCP
	station every 201 minutes (every 3,35 hours).

Table 13 -

 13 Space SoS architectural configurations for Constellation of Satellites.

	# Architectural Configuration Number of Satellites Simulation time
	1	1	283
	2	2	287
	3	3	286
	4	4	285
	5	5	289
	6	6	292
		TOTAL	2,014 minutes (33.56 hours)

Table 13 .

 13 The simulation involved four types of DCP stations, in conformance with data delivered by INPE: 133 meteorological DCP stations, 36 agricultural DCP stations, 77 hydrological stations, and three PCDQagua, which totaled 249 DCP stations, distributed in 21 states

as follows: 'PR': 1, 'SC': 2, 'MG': 23, 'MT': 2, 'MA': 16, 'BA': 19, 'RS': 7, 'SP': 20, 'AM': 4, 'CE': 46, 'PB': 1, 'TO': 14, 'RJ': 3, 'PA': 10, 'ES': 3, 'MS': 4, 'PE': 15, 'GO': 10, 'RN': 27, 'RO': 7, 'SE': 15.

Table 14 -

 14 Percentage of data transmitted by each architectural configuration and received in ground.

	# Architectural Configuration % Total Data Received
	1	89.81%
	2	91.24%
	3	91.70%
	4	94.85%
	5	95.85%
	6	97.94%

Table 15 -

 15 Percentage of data loss in satellite constellation simulation.

	# Architectural Configuration % Total Data Loss
	1	10.19%
	2	8.76%
	3	8.30%
	4	5.15%
	5	4.15%
	6	2.06%

Table 16 -

 16 Results of telecommands and photographs requests, taken, and returned to ground.

	# Telecomand	Tele-	Tele-	Captured	Non-	Photographs	Photographs
	sent	com-	com-	pho-	Captured	returned	not	re-
		mand	mand	tographs	photo-	to Ground	turned to
		Re-	Lost		graphs	Station	Ground
		ceived
	1 4,000	4,000	0	3,948	52	3,948	0
	2 4,000	4,000	0	3,967	33	3,965	2
	3 4,000	4,000	0	3,981	19	3,980	1
	4 4,000	4,000	0	3,994	6	3,994	0
	5 4,000	4,000	0	4,000	0	4,000	0
	6 4,000	4,000	0	4,000	0	4,000	0

Table 17 -

 17 Percentage of missions accomplished in Scenario 3.ASAS enabled comparisons and evaluations of the entire SoS from a holistic point of view and considering different architectural configurations. The best accuracies (M2.1) achieved by Space SoS were 97.94% for data collection, and 100.00% for the obtaining of pictures from the Amazon region. Data loss (M2.2) reached 2.06% of the total loss when six satellites were used. Therefore, an increase in the number of satellites significantly reduces data collision, resources competition, consequently reducing data losses. Arrangements of constituents were tried, including satellites at runtime, exercising M2.3 (scale). ASAS enabled us to evaluate six different architectural configurations, drawing conclusions to decide which architectural configuration offers best results (M2.4).

	#	% Percentage of accomplish-	% Percentage of accomplish-
		ment Data collection.	ment Obtain picture from
			Amazon.
	1	89.81%	98.70%
	2	91.24%	99.13%
	3	91.70%	99.50%
	4	94.85%	99.85%
	5	95.85%	100.00%
	6	97.94%	100.00%

Table 18 -

 18 Number of lines of code produced by our patterns for FMSoS.

	Model	Number	of	Lines per model Lines per
		Models			model type
	Sensor	43		24	1,032
	Gateway	20		18	360
	Crowd	9		22	198
	CrowdGateway	3		17	51
	Transmitter	43		13	559
	CrowdTransmitter 9		15	135
	TOTAL	127		109	2,335

Table 19 -

 19 Number of lines automatically generated for simulations 1 and 2 of space SoS -NoM means Number of Models.

	Simulation 1	Simulation 2

Table 20 -

 20 Comparison between related approaches.

	Approach (Crono-	Formalism adopted	Formalism		Adoption	Support	Type of concern
	logical Order)		for description of	adopted	for	of	MBE	to	SoS	evaluated
				SoS software archi-	SoS	simula-	ap-		dynamic
				tectures	tion			proaches	architec-
								and model	tures
								transfor-
								mations
	Huynh	and	Os-	SySML	Executable		Yes		No	Non-Functional
	mundson (HUYNH		models (Tool			(Network	Uti-
	THOMAS;	OS-		called	Ex-			lization	and
	MUNDSON JOHN,		tend)					Throughput)
	2006)
	Ackermann	et	UML	None			No		No	Functional	and
	al.	(ACKER-							non-functional
	MANN; LINDVALL;							(reliability)
	CLEAVELAND,
	2009)
	Michael	et	al.	UML	None			No		No	Functional	and
	(MICHAEL;								Non-Functional
	RIEHLE;	SHING,
	2009)
	Griendling		Petri Nets	Petri Nets		No		No	Functional (Mis-
	and	Mavris							sion)
	(GRIENDLING;
	MAVRIS, 2011)
	Ge et al. (GE et al.,	DoDAF views docu-	ExtendSim		No		No	Functional
	2013)			mented in SySML
	Xia et al.(XIA et al.,	UML	Simulink		Yes		No	Non-Functional
	2013)
	Tomson and Pre-	Agents 21	None			No		No	Functional
	den	(TOMSON;
	PREDEN, 2013)
	Fang (FANG; DE-	Colored Petri Nets	Colored Petri	No		Yes	Non-Functional
	LAURENTIS; DAV-	(CPN)	Nets (CPN)			(Complexity and
	ENDRALINGAM,							Perfomance)
	2013)
	Bocciarelli	and	SySML	HLA			Yes		No	Functional
	D'Ambrogio
	(BOCCIARELLI;
	D'AMBROGIO,
	2014)
	Guariniello	and	FNDA	None			No		Yes	Functional	and
	DeLaurentis (GUAR-							Non-Functional
	INIELLO; DELAU-							(Security	and
	RENTIS, 2014a)								Robustness)
	Falkner	et	al.	GraphML*	Customized	Yes		No	Non-Functional
	(CHIPRIANOV	et		Tool					(Performance)
	al., 2014; FALKNER
	et al., 2016)
	Fuchs and Niklas	UML/SySML	None			Yes		No	Not clear
	(FUCHS;	LIND-
	MAN, 2014)
	Vierhauser et al.	Own DSL	ReMinds envi-	Yes		No	Not done
	(VIERHAUSER et		ronment
	al., 2016)
	Gassara et al. (GAS-	Bigraph	None			Yes		Yes	None
	SARA;	BOUAS-
	SIDA;	JMAIEL,
	2017; GASSARA et
	al., 2017)
	ASAS Approach	SosADL	DEVS			Yes		Yes	Functional
	(GRACIANO NETO
	et al., 2018b)

  Fuchs and Niklas reported the state-of-the-practice techniques and technologies used in modeling and simulation of SoS in the European Space Agency (ESA) (FUCHS; LINDMAN, 2014). They model SoS architectures under many views (using UML and Chapter 3. ASAS: A Model-Based Approach for the Simulation and Evaluation of Software Architectures of Systems-of-Systems SysML) through MagicDraw. Profiles are generated from the Ecore metamodel, involving UPDM, and the accompanying standards, SysML and SoaML. The profiles are used in the application of ESA-specific stereotypes to standard UML entities in MagicDraw. The general approach taken in the ESA-Architecture Framework (ESA-AF) is based on the Eclipse framework and uses of its inherent extensibility, and diagramming functionality is based on the Eclipse Graphical Modeling Framework (GMF). It is nor clear how they deal with SoS architecture dynamics, as SySML offer only static models. Vierhauser et al. developed a tool called ReMinds (REquirements Monitoring INfrastructure for Diagnosing Systems of Systems), which is a flexible framework for the development of monitoring solutions that cover different systems forming an SoS

  Finally, Petitdemange et al. established a solution based on patterns for reconfiguration of SoS software architectures (PETITDEMANGE; BORNE; BUISSON, 2016). Despite involving SoS domain and reconfiguration, no patterns were created for simulation.

  2. A method to evaluate SoS inherent dynamics and architectural alternatives: ASAS comprises a method to support the assessment of different architectural configurations that can emerge at runtime. Architectural decisions can be drawn considering a pre-established set of metrics, enabling the selection of the best architectural configurations, which is a contribution over the past approaches, especially regarding SoS software architectures; 3. A means for the validation of SoS behaviors (including emergent ones): ASAS, by means of the simulation models automatically produced, comprises a method that allows an architect to evaluate the SoS software architecture about the functionalities intended to be offered. Besides predicted behaviors, ASAS also supports prediction of SoS behaviors in case of non-predicted failures and exceptions. SoS behaviors are deliberately and intentionally designed (BOARDMAN; SAUSER, 2006), i.e., the SoS engineer is the major player for creatively exploring the functionalities delivered by the constituents, assembling them for innovative purposes. Validation activity consists in the checking of the conformance between the missions specified at the requirements level and the corresponding emergent behaviors that accomplish such missions (IEEE, 2012; IEEE Computer Society, 2014). However, due to the nature of such behaviors, a validation approach for SoS software architectures requires a dynamic viewpoint that externalizes emergent behaviors. It should support software architects to predict and validate desired emergent behaviors. The following four major categories of techniques for validating software architectures 28 : scenariobased, simulation-based, mathematical/logical-based, and experience-/metric-based. Considering the dynamic nature of SoS software architectures, a simulation-based approach is undoubtedly the appropriate one 29 . Simulation-based approaches have supported the validation of dynamic properties for SoS (NIELSEN et al.

	, 2015; MIT-
	TAL; RAINEY, 2015; MICHAEL; RIEHLE; SHING, 2009; SAUSER; BOARDMAN;
	VERMA, 2010; ZEIGLER et al., 2012; WACHHOLDER; STARY, 2015; FRAN ÇA;
	TRAVASSOS, 2016). Such approaches (MICHAEL et al., 2011; FRAN ÇA; TRAVAS-
	SOS, 2016; WACHHOLDER; STARY, 2015; XIA et al., 2013): (i) support the
	validation of expected emergent behaviors, (ii) empower the observations of unex-

28

Dobrica and Niemela discuss further details about validation methods for software architecture (DOBRICA; NIEMELE, 2002; MICHAEL; RIEHLE; SHING, 2009; MICHAEL et al., 2011). 29 Nielsen et al. deeply discuss simulation approaches for SoS

  OQUENDO, 2015). On the other hand, a branch of Software Engineering has been founded on simulation-based studies[START_REF] Fran Ça | Reporting guidelines for simulation-based studies in software engineering[END_REF][START_REF] Fran Ça | Reporting guidelines for simulation-based studies in software engineering[END_REF][START_REF] Fran Ça | Reporting guidelines for simulation-based studies in software engineering[END_REF][START_REF] Fran Ça | Reporting guidelines for simulation-based studies in software engineering[END_REF] TANIR, 2017), as simulations enable an early anticipation of inconsistencies at design-time, preventing propagation of errors for the final product. ASAS can also foster the development of this branch research using other simulations formalisms and tools, as many of them have been proposed (TENDELOO; VANGHELUWE, 2017), and strategies can be established to use simulations as source of evidence and validity, benchmarking SoS software models, and advancing verification and validation towards a simulation-based sofware engineering; 4. Multiple missions (deadlocks and resource competition): We investigated how a small set of missions can share a finite set of constituents to accomplish SoS missions. However, in a larger context, the concurrency of many missions being accomplished by a finite set of constituents can lead to deadlocks, bottlenecks, and other recognized problems from the domain of multiple communicating processes.

	3. Simulation-based Software Engineering for SoS: Software Engineering is the
	application of systematic principles to the planning, design, development, testing,
	implementation, and maintenance of software-based systems (TANIR, 2017). Due to
	particular characteristics of SoS and their importance, researchers have investigated

on ways of properly engineering software for SoS, which has created the so-called new area of interest Software Engineering for Systems-of-Systems (SESoS)

[START_REF] Guessi | A systematic literature review on the description of software architectures for systems of systems[END_REF][START_REF] Calinescu | Software engineering techniques for the development of systems of systems[END_REF][START_REF] Calinescu | Software engineering techniques for the development of systems of systems[END_REF] NAKAGAWA et al., ; DRIRA;

Table 21 -

 21 Mapping between DEVS and SosADL.Set of Constituent Systems. They become a Decomposition, i.e., a statement of the coupled model that systematically lists all the inner structures (e.g., systems, mediators, among others) that form the SoS software architecture[START_REF] Zeigler | Guide to Modeling and Simulation of Systems of Systems[END_REF]. Chapter 4. Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and Prescriptive Models of Systems-of-Systems Software Architectures

	SoS concept	DEVS	SosADL
	Set of Constituent Systems	Decomposition	Coalition
	Data Types	Data Type	Data Type
	Gate/Connection	DEVS Port	Gate/Connection
	Interfaces	Coupling	Binding
	SoS Architecture	Coupled Model	Coalition + Binding
	Data Types. Constituents exchange data according to a pre-defined data type. Hence,
	data types are preserved and properly converted into DEVS data types format.

Gate/Connection. SosADL Connections are mapped into DEVS ports.

Interfaces. Interfaces encapsulate the communication between two systems. In SosADL, interfaces are specified through bindings, which correspond to all combinations between

Table 22 -

 22 Part of the results collected during the case study.

	# Sensors Gateways CS mc
	1	5	1	0	0.88
	2	6	1	0	0.80
	3	7	1	0	0.74
	4	8	1	0	0.69
	5	30	2	0	0.22
	6	30	5	0	0.21
	33	30	10	8	0.17
	65	30	10	20 0.12

  Table22has 579 LoC; while the last architectural configuration, with 30 sensors, 30 mediators, 10 gateways, 20 crowdsourcing systems, 20 crowd mediators and 10 crowd gateways, and 411 LoC for interoperating them reach the amount of 7,241 LoC. On the other hand, considering SosADL, A single constituent model for representing a sensor in a simulation has 69 lines of code (LoC). A mediator holds 49 LoC, a gateway has 53, a crowdsourcing system has 65 LoC, 39 LoC for crowd mediators and 49 LoC for crowd gateways. Adding the amount of the code necessary to specify their interoperability links materializing the architectural description (77 LoC in first configuration, and 376 LoC in last one), the last configuration reaches more than 7,000 LoC. Back-SoS approach was well-succeeded for dealing with this large amount of LoC, with well-succeeded reverse transformations.

		Listing 1: Description of an architecture of an FMSoS in SoSADL.
	1 sos MonitoringSos is {
	2	architecture M o n i t o r i n g S o s A r c h i t e c t u r e R e c 1 () is {
	3	// identical code
	4	behavior coalition is compose {
	5	// identical code
	6	mediatorRec1 is Mediator
	7	sensorRec1 is Sensor
	8	} binding {
	9	// identical code
	10	unify one { sensorRec1 :: location :: coordinate } to one
		{ mediatorRec1 :: location :: coordinate } and
	11	unify one { sensorRec1 :: measurement :: measure } to one
		{ mediatorRec1 :: transmit :: measure } and
	12	unify one { mediatorRec1 :: transmit :: measure } to one {
		Sensor1 :: measurement :: measure } and
	13	unify one { sensorRec1 :: location :: coordinate } to one {
		mediatorRec1 :: location :: coordinate }
	14	}
	15	}
	16 }
		1

3 .

 3 Transient changes: Changes can occur due to failures or attacks, and self-healing mechanisms can be established for restoring SoS operational integrity. In such cases, changes are not permanent, and model recovery and discovery should not be necessarily triggered. Such topics must be further exploited, and strategies shall be provided to deal with security, self-healing, and transient changes in SoS software architecture.4.Open SoS and Discovery of models for non-predicted constituents. SoS are inherently open systems. As such, architectural changes could be possible to occur involuntarily, i.e., not necessarily started by a human codifier that adds a new rule not prescribed in the original architectural description, but as a result of the possibility of new constituents joining the SoS. Therefore, it is necessary to define operations to be performed to reestablish the conformity between the concrete model and the abstract SoS model after the concrete model has been restored in relation to the runtime architecture. 4. Back-SoS: a Model-Based Approach for Reconciliation between Descriptive and Prescriptive Models of Systems-of-Systems Software Architectures 5. Model comparison mechanisms. In MBSE approaches, model comparison is the procedure of comparing two models to support, between other functionalities, version controlling in a models repository and models maintenance, enabling that only parts that were changed are updated in an original source model. Currently, our approach only conserves parts of SosADL models that did not change in regards to the original version that created the simulation models used as target to apply Back-SoS. Model comparison mechanisms must be established for SoS specification and simulation languages. 6. Reestablishment of architectural configurations. Architectural changes can originate a defective SoS architectural configuration. Self-adaptive mechanisms must be established to undo changes, recovering, at runtime, a functional SoS architecture; 7. Consistency with SoS's initial abstract architecture. In Section 4.1.5, we discuss the requirements for supporting the reestablishment of consistency between SoS descriptive architecture (simulation model) and SoS architectural instance at prescriptive level, and the conditions that characterize and effective architectural deviation between both levels of abstraction in SoS prescriptive model. In our evaluation, conformance between SoS architectural instance and SoS abstract architecture was manually performed by experts. However, we envision a potential to automate such task. Mechanisms to check conformance between the SoS architectural instance models and the SoS abstract architecture model must be established, assuring architectural consistency, and avoiding SoS architectural erosion, even in abstract level; 8. Techniques for Hierarchic SoS. SoS are often hierarchic and have different characteristics to system of components. Systems can also be members of multiple other systems. Hence, discovery mechanisms must be expanded and also address the multiple levels of hierarchy that can be exhibited by a SoS at runtime; 9. Model discovery mechanisms for an Operational SoS. Once we have been able to perform a reverse transformation from simulation to SoS architectural specification, the next steps proceed towards doing it for an operational SoS. An correspondent animated SoS linked to the operational SoS (represented similarly to a simulation and visualizable in a screen) could add to monitor architectural changes and restoration of SoS architectural consistency via the same transformation.

	Chapter

  Chapter 5. Stimuli-SoS: A Model-Based Approach for Automatic Creation of Stimuli Generators in Simulations of Software Architectures of Systems-of-Systems products delivered are used as input for the next activity. Environment modeling is a sub-activity performed in this step; 2. Automatic derivation of stimuli generators: This activity comprises running the model transformation, receiving SoSADL work products as inputs, and delivering DEVS files as outputs, including the stimuli generators;

	1 SPEM	-	Software	&	Systems	Process	Engineering	Metamodel:
	http://www.omg.org/spec/SPEM/

  1. smart sensors, which are fixed embedded systems monitoring flood occurrences in urban areas, located on river edges; 2. gateways, which gather data from constituents and share them with other systems; 3. crowdsourcing systems, which are mobile applications used by citizens for realtime communication of water level rising; 4. drones, which are UAVs also concerned to complement sensors observations by monitoring the river water level while they fly over it, sending pictures if some change in the water level occurs; and 5. drone bases, which are fixed basis from where drones departure, and for where they come back to recharge battery, and transmit their data.

Table 23 -

 23 A sample of data sent by sensors.

	5.2. Evaluation

  Chapter 5. Stimuli-SoS: A Model-Based Approach for Automatic Creation of Stimuli Generators in Simulations of Software Architectures of Systems-of-Systems (OMG, 2017), MatLab/Simulink (MATLAB, 2010), Palladio 11 (BECKER; KOZIOLEK; REUSSNER, 2009), Bogado et al. (BOGADO; GONNET; LEONE, 2014) and Alexander et al. (ALEXANDER; NICOLAESCU; LICHTER, 2015). Other initiatives invested in modeling and simulating SoS, but with no support for software architecture concept (ZEIGLER et al., 2012).

  6.3. Possible Extensions and Future Work 161 other constituents, establishing new connections with them, and potentially providing new functionalities. 2. Correctness of the simulation model is related to the correctness of the architectural model. Since we use a model transformation that maps SoSADL

1 .

 1 Simulation-based SoS Software Testing: Simulations can support empirical evaluation in Software Engineering (FRAN ÇA; TRAVASSOS, 2012; FRAN ÇA; TRAVASSOS, 2013; FRAN ÇA; TRAVASSOS, 2015; FRAN ÇA; TRAVASSOS, 2016).

  201 21 accepts input on << connectionName . toFirstUpper > > with type << dataReceived . type > >! ' ' ' 22 23 if ( e instanceOf Action ) transitions += ' ' ' passivate in s < < fromState > >! 24 when in s < < fromState > > and receive << dataReceived > > go to s < < toState > >! ' ' ' 25 26 } else if (( connection . type == OUTPUT ) or ( action . type == SEND ) ) { 27 if ( e instanceOf Connection ) ports += ' ' ' generates output on << this . Source code 12 -Transformation code specified in Xtend.

		connection . typeName > >
	28	with type << dataSent . type > >! ' ' '
	29
	30	if ( e instanceOf Action ) transitions += ' ' ' hold in s < < fromState > > for time
		1!
	31	after s < < fromState > > output << this . connection . typeName > >!
	32	from s < < fromState > > go to s < < toState > >!
	33	' ' '
	34	}
	35 }

  Source code 14 -Code in SosADL for a behavior called sensing of a smart sensor.

	1 behavior sensing is {
	2	value sensorcoordinate is Coordinate = lps
	3	via location :: coordinate send sensorcoordinate
	4	via energy :: threshold receive powerthreshold
	5
	6	repeat {
	7	via energy :: power receive powerlevel
	8	if ( powerlevel > powerthreshold ) then {
	9	choose {
	10	via measurement :: sense receive data
	11	via measurement :: measure send tuple {
	12	coordinate = lps , depth = data :: convert ( ) }
	13	} or {
	14	via measurement :: pass receive data
	15	via measurement :: measure send data
	16	} //end choose
	17	} // end i f
	18	} //end repeat
	19 } //end sensing

  Source code 16 -Description of an architecture of an FMSoS in SosADL.

	1 sos FloodMonitoringSos is {
	2	architecture F l o o d M o n i t o r i n g S o s A r c h i t e c t u r e ( ) is {
	3	behavior coalition is compose {
	4	sensor1 is Sensor
	5	sensor2 is Sensor
	6	sensor3 is Sensor
	7	sensor4 is Sensor
	8	gateway is Gateway
	9	mediator1 is Mediator
	10	mediator2 is Mediator
	11	mediator3 is Mediator
	12	mediator4 is Mediator
	13	} binding {
	14	relay gateway :: notification :: alert to warning :: alert and
	15	relay gateway :: request to request and
	16	unify one { sensor1 :: measurement :: measure }
	17	to one { mediator1 :: fromSensors } and
	18	unify one { mediator1 :: transmit :: towardsGateway }
	19	to one { sensor2 :: measurement :: pass } and
	20	unify one { sensor2 :: measurement :: measure }
	21	to one { mediator2 :: fromSensors } and
	22	unify one { mediator2 :: transmit :: towardsGateway }
	23	to one { gateway :: notification :: measure } and
	24	unify one { sensor3 :: measurement :: measure }
	25	to one { mediator3 :: fromSensors } and
	26	unify one { mediator3 :: transmit :: towardsGateway }
	27	to one { sensor4 :: measurement :: pass } and
	28	unify one { sensor4 :: measurement :: measure }
	29	to one { mediator4 :: fromSensors } and
	30	unify one { mediator4 :: transmit :: towardsGateway }
	31	to one { gateway :: notification :: measure }
	32 } }

Une approche dirigée par les simulations à base de modèles pour concevoir les architectures de systèmes-des-systèmes à logiciel prépondérant Valdemar VicenteGraciano Neto 2019

Une approche dirigée par les simulations à base de modèles pour concevoir les architectures de systèmes-des-systèmes à logiciel prépondérant Valdemar VicenteGraciano Neto 2019 Une approche dirigée par les simulations à base de modèles pour concevoir les architectures de systèmes-des-systèmes à logiciel prépondérant Valdemar VicenteGraciano Neto 2019

UML, http://www.uml.org/

SysML, http://sysml.org/

CML, http://www.compass-research.eu/approach.html

DoDAF, US Department of Defense Architecture Framework, 2010.

Simulink, www.mathworks.com/products/simulink/

http://www.eclipse.org/modeling/

https://wiki.eclipse.org/Net4j

https://wiki.eclipse.org/Teneo

http://eclipse.org/modeling/gmp/

https://eclipse.org/graphiti/

https://eclipse.org/Xtext/

http://eclipse.org/bpmn2-modeler/

https://eclipse.org/etrice/

https://eclipse.org/MoDisco/

http://www.omg.org/spec/OCL/

http://eclipse.org/papyrus/

http://sphinx-doc.org/develop.html

More details on the syntax of architecture descriptions in SosADL and its elements can be found in (OQUENDO, 2016a).

<https://eclipse.org/Xtext/>

<http://www.eclipse.org/Xtend/> Une approche dirigée par les simulations à base de modèles pour concevoir les architectures de systèmes-des-systèmes à logiciel prépondérant Valdemar VicenteGraciano Neto 2019

J. Fitzgerald, S. Foster, C. Ingram, P. G. Larsen, and J. Woodcock. Model-based engineering for systems of systems: the COMPASS manifesto. COMPASS, October 2013.

http://www.ms4systems.com/pages/main.php

https://eclipse.org/Xtext/ Une approche dirigée par les simulations à base de modèles pour concevoir les architectures de systèmes-des-systèmes à logiciel prépondérant Valdemar VicenteGraciano Neto 2019

SEBoK. Guide to the systems engineering body of knowledge, version1.6, 2016. Une approche dirigée par les simulations à base de modèles pour concevoir les architectures de systèmes-des-systèmes à logiciel prépondérant Valdemar VicenteGraciano Neto 2019

At least for this domain, configurations defined, and types of constituents

In this simulation, no data delivery guarantee was provided. A supplementary simulation was conducted, performing the guarantee of reception. 100% of the data were received, and all the flood alerts were accordingly triggered.

On September

18, 19 and 20, University of Brasilia held the 1st BRICS Remote Sensing Satellite Constellation Forum, a meeting to bring together representatives of the BRICS space agencies -Brazil, Russia, India, China and South Africa -to discuss technical aspects related to the five countries' initiative in establishing a constellation of six (6) remote sensing satellites. Source: <https://goo.gl/mhPGtq>.

Each orbit contains two satellites with different movements that enable them to revisit the same DCP station each 30 minutes.

Credits for the images used to compose the Figure: <https://goo.gl/npTLdm>, <https: //goo.gl/DCU3L7>

In another study (MANZANO; GRACIANO NETO; NAKAGAWA, 2018), we exercised all the dynamic architecture operators. But this was not part of the scope of this study, specifically

http://www.uml.org/

http://sysml.org/

http://www.compass-research.eu/approach.html Une approche dirigée par les simulations à base de modèles pour concevoir les architectures de systèmes-des-systèmes à logiciel prépondérant Valdemar VicenteGraciano Neto 2019

SofTware ARchitecture Team (START/ICMC-USP) and ArchWare (IRISA/UBS)

Due to space reasons, the complete list of architectural changes, architectural configuration, and mutation coefficient are externally available at <>.

UML, http://www.uml.org/

SysML, http://sysml.org/

CML, http://www.compass-research.eu/approach.html

DoDAF, US Department of Defense Architecture Framework, 2010.

Simulink, www.mathworks.com/products/simulink/ Une approche dirigée par les simulations à base de modèles pour concevoir les architectures de systèmes-des-systèmes à logiciel prépondérant Valdemar VicenteGraciano Neto 2019

Credits for the images used to compose the figure: http://goo.gl/TTOlAa, http://goo.gl/QCUAKY, http://goo.gl/a9Y0Dw, https://goo.gl/rFkYJ6, https://goo.gl/8YojYj, https://goo.gl/XyWEZw, https://goo.gl/VpftdV, https://goo.gl/dfMPLl.

http://www.inf.ufg.br/ valdemarneto/journalMaterials/stimuli-sos.html Une approche dirigée par les simulations à base de modèles pour concevoir les architectures de systèmes-des-systèmes à logiciel prépondérant Valdemar VicenteGraciano Neto 2019

http://www.palladio-simulator.com/

https://eclipse.org/Xtext/

xtend-lang.org/

These transformation rules were structured as presented for separation of concerns, reuse, and modularization purposes

ACKNOWLEDGEMENTS

It's closing time again. And as it is broadly known, the best part of a journey is the path, not the final destination. I have been surrounded by phenomenal people during these almost five years of walking. I met many people who changed my life. By the way, change was one of the most constant words in the trajectory. I moved out five times during the doctorate course. And in all the changes, I found people with open hearts willing to LIST OF SOURCE CODES Source code 1. Code in SosADL for a mediator. . . . . . . . . . . . . . . . . . . . 49 Source code 2. An atomic model for a mediator generated in DEVSNL. . . . . . 50 Source code 3. Description of an architecture of an FMSoS in SosADL. . . . . . . 57 Source code 4. Coupled model for FMSoS generated in DEVS. . . . . . . . . . . 59 Source code 5. Model discovery mechanism. . . . . . . . . . . . . . . . . . . . . . 110 Source code 6. Coupled model for FMSoS generated in DEVS. . . . . . . . . . . 112 Source code 7. Coalition specified in SosADL. . . . . . . . . . . . . . . . . . . . . 113 Source code 8. A SoS abstract architecture specified in SosADL. . . . . . . . . . 114 Source code 9. A specification of a sensor in SoSADL. . . . . . . . . . . . . . . . 136 Source code 10. DEVS code for a stimuli generator. . . . . . . . . . . . . . . . . . 147 Source code 11. Code in SosADL for a mediator. . . . . . . . . . . . . . . . . . . . 199 Source code 12. Transformation code specified in Xtend. . . . . . . . . . . . . . . 200 Source code 13. An atomic model for a Mediator generated in DEVSNL. . . . . . 202 Source code 14. Code in SosADL for a behavior called sensing of a smart sensor. . 203 Source code 15. State diagram code corresponding to a Smart sensor behavior generated in DEVSNL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Source code 16. Description of an architecture of an FMSoS in SosADL. . . . . . . 207 Source code 17. Transformation rules specified in Xtend for the transformation of a SosADL model into DEVS model. . . . . . . . . . . . . . . . . . . . . . . . . 209 Source code 18. Coupled Model for FMSoS generated in DEVS. . . . . . . . . . . 210 Source code 19. Dynamic reconfigurator controller structure. . . . . . . . . . . . . 211 Source code 20. A transformation excerpt that supports generation of DEVS simulation of SoS software architecture with support to dynamic reconfiguration.213 Source code 21. Excerpt of a satellite modelled in SosADL. . . . . . . . . . . . . . 215

Data

APPENDIX A

LIST OF PUBLICATIONS

During the PhD, 23 authored and co-authored papers were published by the candidate. From them, nine were totally related to the thesis, and other 14 are indirect contributions. From the nine, six are full papers (FP): two conferences, one student research competition, one doctoral symposium, two workshops; one is a full journal article (JA); and two are workshop short papers (SP). It is important to highlight that the paper entitled Supporting Simulation of Systems-of-Systems Software Architectures by a Model-Driven Derivation of a Stimulus Generator received a best paper award. From the other contributions, five were full conferences and workshop papers, six short conference and workshop papers, two book chapters (BC), and one technical report (TR). All of these papers were totally related to advances in software engineering for SoS. Five other authored and co-authored article journals are already submitted to evaluation at the thesis submission time.

The list of publications is displayed, as follows:

Publications related to the solutions developed in the thesis: APPENDIX B

SPECIFICATION AND DETAILS ON TRANSFORMATION OF SOSADL MODELS INTO DEVS MODELS

For the reader convenience, this chapter presents details on how a model transformation was specified to map SosADL models into DEVS models. For didactic reasons, such transformation is discussed below in two parts: generation of atomic models, and generation of coupled models. Examples are discussed in regards to a Flood Monitoring SoS.

B.0.1. Generation of atomic models

Listing 11 shows a simplified code of mediator specified in SosADL. This code is mapped into an atomic model written in DEVS depicted in Listing 13. The transformation is performed by the code specified in Xtend available in Listing 12. In Listing 11,data types are defined on Lines 2-6. Duties (in this context, only a name for the designation of gates and mediators) with their respective connections are defined on Lines 8-16. Behavior of the mediator is specified between Lines 18 and 23, and shows that a mediator (i) receives constituents coordinates (Lines 19 and 20), (ii) receives data from the sensors (Line 22) and (iii) forward such data towards a gateway (Line 23). This sequence of actions is performed in a loop. 40). Line 4 expresses a receive assignment, with an analogous treatment (s 2 ⇒ s 3 ). This is an output event, and as such, originates a labeled output transition (s 1 ⇒ s 2 ). The other one-line statements (we term them action statements) in line 4, lines 10 and 11, and 14 and 15 follow the same rationale. As every statement within a repeat command must be repeated, a new state called s n is created for amalgamating the execution flow at the end of the loop, and transiting it from s n to s 3 , creating a loop. Line 7 depicts the transition ?powerLevel. Two transitions are created: one for a true value returned by the statement, and another for false values, i.e., when the battery level is not enough to perform the behavior. Transition to s 5 is created for ?true, and the transition to s 6 is created for ?false. Since no else statement exists, the flow is forwarded to s n spontaneously, i.e., without receiving or sending anything, converging the execution flow. The same procedure is followed for the transformation of simple assignments, and two execution flows are created and chosen depending on which event occurs first. Two flows are created for each set of statements, and finally, the flows are amalgamated again by spontaneous transitions in a state previously created by the repeat statement (s n ), and the transformation for the behavior is finalized. A transition (s n to s 3 ) restarts the execution. which entities are involved in the SoS and how they interact, i.e., which systems send data and which systems receive these data. In SosADL, SoS software architectures ares modeled as coalitions. The correspondences between SosADL and DEVS are summarized in Table 25. Interfaces. The concept of interface encapsulates the communication between two entities (in this case, systems). Consequently, a detailed analysis of an interface should contain (explicitly or not) functions send located in one system element, and receive located in another 3 . In SosADL, interfaces are specified through bindings, which correspond to the list of all combinations between output ports and input ports that establish a communication between two entities in a SoS. In DEVS, each one of the bindings is mapped into a coupling, i.e., a statement describes the way information flows between two systems in the SoS.

Sos Architecture. Finally, the software architecture of an SoS is represented as an abstract architecture in SosADL, which specifies a coalition and a set of bindings, and as there are lines of unifications in the specification of the binding. Each binding specified in SosADL is mapped into one coupling in DEVS. Listing 18 shows the equivalent code derived from the coalition using the transformation rules specified in Xtend depicted in Listing 17. Line 1 shows that the FloodMonitoringSoSArchitecture is formed by the same systems specified in the SosADL code. Lines 2 to 9 show the data exchange among all systems and mediators derived from the specification of the coalition. These lines are created by iterating on the unifying statements. One line is created for each of the unifying connections specified in the SosADL model. Finally, DEVS tool converts that code into a simulation model that is executable.

Considering Listing 18, sensors transmit data to their closest mediator (Lines 2, 4, 6, and 8). Then, these mediators receive these data in Lines 3, 5, 7, and 9 forward Measure to the next sensors. Since Sensor2 and Sensor4 sent their data to Mediator2 and Mediator4 respectively (Lines 4 and 6), the gateway is already reached (Lines 5 and9). When these data arrive in the gateway, their values are tested against a pre-determined depth threshold. If they are higher, the gateway emits a flood alert. Thus, the network of exchanged messages between constituents and the flood alert trigger indicate that the SoS mission, i.e., producing flood alerts, has been accomplished by these constituent system.

B.0.2.1. Dynamic reconfiguration controller structure

Dynamic reconfiguration controller is an artificial architectural element that manages every architectural change that occurs. It is added to the simulation to support the simulation user to perform architectural changes at runtime. From the DEVS simulation model perspective, the reconfiguration controller is an atomic model, that: (i) adds constituents to the simulation, also adding the necessary connections and mediators, maintaining the properties of the initial architecture; (ii) removes the constituents of the simulation, connections and mediators, relinking the remaining constituents to maintain with it are also removed. If necessary, new connections and mediators can be added to reestablish the path inside the SoS architecture that enable the communication with other constituents that communicated with the constituent removed.

Substitution of constituent is a sequence of both removal and addition. In turn, for the reorganization of the architecture, a signal is sent to the controller, which removes all the connections and mediators between the constituents. After that, the controller creates new connections and mediators between constituents to raise a new functional architectural configuration.

Adding Support to Dynamic Reconfiguration through a Model Transformation. All SoSADL elements are mapped to DEVS to create a functional simulation.

Transformation rules automatically create the dynamic reconfiguration controller and add it in the simulation model. This controller holds and makes available to the simulation user all the dynamic architecture operators. The canonical changes are addition and removal, i.e., fundamental operations that are bases for any type of change. Replacement of constituent was performed as a sequence of removal and addition. Reorganization was also implemented, leading to deconstruction of the entire architecture, being rebuilt again for a new architectural arrangement. The model transformation generates three main elements related to dynamic architecture into the target simulation model, which are:

Dynamic reconfiguration controller: it consists of an atomic model that manages all the changes in the simulation, as shown in Figure 41. For that it manages the connections and mediators between the constituents, so that the new arrangement still remains consistent with the original architecture;

Identification flags: In DEVS, single elements that compose a SoS are atomic models. Mediators and all the types of constituents are handled as the same type of entity. As consequence, it could be possible to put a sensor to play the role of a mediator, i.e., a sensor mediating other sensors, which is not desired as it hampers architectural precision. Hence, two identification flags are inserted into all the atomic models: one to check if the system is a mediator or not (boolean), and another one that is the constituent type name, such as Sensor, Transmitter, or Gateway.

Connections of all the constituents with the dynamic reconfiguration controller in the coupled model: This is necessary to enable the controller to communicate with all the constituents and remove them if necessary. Source code 20 -A transformation excerpt that supports generation of DEVS simulation of SoS software architecture with support to dynamic reconfiguration.

Listing 20 shows an excerpt of code of the model transformation 5 . This method specified in Xtend was created to add dynamic reconfiguration support for all the existing elements of the simulation. The addition of the support to the reconfiguration is done after the compilation of the SoSADL models. All elements of the concrete architecture in 5 Some parts of the code are hidden for the reader convenience.

APPENDIX B. Specification and Details on Transformation of SoSADL models into DEVS models

SoSADL are iterated, and before each compiled file is created, each element receives some code snippets referring to the communication with the dynamic reconfiguration controller, the identification flags, and the connections that support the controller operations on the simulation model. If the SoSADL architectural element is a mediator or system, they will be handled in a similar way. If the input for the model transformation is an architecture, all the required bindings will be added. In Listing 20, Line 2 shows the transformation code that checks whether sfile, which is the model being compiled, is a system or a mediator.

If it is one between both options, the method performs the procedures of lines 4-8, where in line 4 will be added external transition so that the model can receive the signal to it be removed, in line 6 output transitions so that it can send its reference to the controller to request for its removal and in line 8 its identification flags. Otherwise, if the element being analyzed is an architecture, all the necessary associations will be added to the coupled model (lines 10 to 16). Next we discuss the protocol and results of our evaluation.

APPENDIX C

A