ACM Student Research Competition Validating Emergent Behaviors in Systems-of-Systems through Model Transformations Valdemar Vicente Graciano Neto University of São Paulo, São Carlos, Brazil IRISA-UMR CNRS/Université de Bretagne-Sud, Vannes, France Universidade Federal de Goiás, Goiânia, Brazil valdemarneto@usp.br Abstract 2006), often supporting missions in critical domains, such as emer- Systems-of-Systems (SoS) are formed by independent systems gency and crisis response in smart cities (ROAD2SOS 2013). termed as constituents. SoS exhibit dynamic properties called One remarkable feature of SoS is its software architecture. emergent behaviors, which are a global functionality that appears Software architectures play a fundamental role in software qual- as a result of the interoperability among constituents. However, ity (Nakagawa et al. 2013). Thus, it is prevalent to adopt models software architecture descriptions of SoS are often static. In turn, that capture precisely such software architectures (Nielsen et al. dynamic models such as simulation models (also adopted to spec- 2015). However, besides structure and individual systems behav- ify SoS) do not use to preserve software architecture details, which iors, SoS exhibit a dynamic property called emergent behavior can hamper the software quality. In this paper, we propose a model (Maier 1998; Boardman and Sauser 2006; Cavalcante et al. 2014; transformation approach to harmonize software architecture de- Mittal and Rainey 2015). This property emerges at runtime as a re- scriptions of SoS and simulation models to support validation of sult of the interoperability of the constituent systems (Maier 1998). emergent behaviors. We model a software architecture of SoS by However, this property has not been captured by modern archi- the adoption of SosADL, a novel architectural description lan- tectural description languages (ADL) (Michael et al. 2009, 2011; guage (ADL) for SoS, and transform it to DEVS, a formalism Guessi et al. 2015b). The operation and success of an SoS is intrin- for simulation of SoS. Our approach offers a dynamic view to sically associated with the emergent behaviors and its underlying architectural descriptions of SoS, preserving the architectural in- software architecture. Thus, an approach to support validation of tegrity of the SoS, and supporting the visualization and validation emergent behaviors in SoS software architectures is prominent and of emergent behaviors. We evaluate our proposal through a case still an issue (Zave 1993; Sauser et al. 2010; Nielsen et al. 2015). study conducted within the context of a real SoS in operation for Under another perspective, the Systems Engineering (SE) com- flood monitoring in an urban area. Preliminary results show that the munity has developed approaches based on simulations to support transformation is feasible, generating functional simulation models dynamic properties for SoS (Michael et al. 2009; Sauser et al. 2010; that support the validation of emergent behaviors. Zeigler et al. 2012; Mittal and Rainey 2015; Wachholder and Stary 2015). However, SE approaches do not properly support software Categories and Subject Descriptors Software and its engineering architecture description (Guessi et al. 2015b). Their formalisms use [Software system models]: Model-driven software engineering to rely on notations based on input/output events and state dia- grams, which sacrifices the high-level of abstraction required for Keywords Systems-of-Systems, Emergent Behaviors, Model Trans- SoS software architecture descriptions. formations, Software Architecture. Then, we pose the following research question: How to vali- date emergent behaviors in SoS preserving their software archi- 1. Motivation and Research Problem tectures? SofTware ARchitecture Team (START/ICMC-USP) and ArchWare (IRISA/UBS) research groups have worked on support- Systems-of-Systems (SoS)1 are a set of independent, heteroge- ing both specification and validation of SoS software architectures. neous constituent systems that form a larger system in order to As a result, a new ADL called SosADL was proposed (Oquendo accomplish a set of missions, that is, functional goals assigned to and Legay 2015; Oquendo 2016a,b). However, SosADL is not sub- the SoS as a whole (Maier 1998). They are likely to form the next ject to simulation, yet. In this direction, this paper proposes a trans- generation of software-intensive systems (Jamshidi 2008; Boehm formation approach from SosADL to DEVS (Discrete Event Sys- tem Specification) (Zeigler et al. 2012), a simulation formalism. 1 For sake of simplicity, SoS will be used interchangeably to express singu- Our approach harmonizes both the software architecture of the SoS lar and plural. and a simulation perspective, supporting the validation of emergent behaviors, while still preserving the SoS software architecture de- scription. The remainder of this paper is structured as follows. Sec- tion 2 describes foundations. Section 3 outlines the mapping from SoSADL to DEVS. Section 4 discusses our preliminary results, and Section 5 brings final remarks. Validating Emergent Behaviors in SoS through Model Transformations 1 2016/12/9 2. Foundations while still considering their software architecture, and to deal with SoS share five well-defined characteristics postulated by Maier constituents that are known at design-time. SosADL is formally (Maier 1998): (i) operational independence, since constituents op- founded on π-calculus for SoS (Oquendo 2016b), a novel formal- erate both autonomously and in the SoS context; (ii) managerial in- ism to describe intercommunicating processes. Figure 1 shows an dependence of constituents, that is, distinct stakeholders and insti- excerpt of SosADL metamodel. In short, SosADL describes SoS, tutions can own them; (iii) emergent behavior, a synergistic behav- which can be expressed as a combination of architectures, sys- ior yielded by the constituents interoperability; (iv) evolutionary tems, and mediators declarations. Mediators are architectural ele- development, once the SoS evolves as a result from the evolution ments concerned with establishing communication between two or of its constituents; and (v) distribution, since their communication more constituents (Wiederhold 1992). An architecture has an in- relies on some network technology. trinsic structure and behavior declaration (materialized as a coali- Emergent behavior is a singular characteristic of SoS. It is trig- tion), data types, and gates declarations. Gates are abstractions that gered by the reception of stimulus and data exchanged between enable the establishment of connections. A connection can be es- the constituents, and between the SoS and the environment (Gra- tablished to receive stimulus from or act on the environment, or ham 2013). Such behaviors are a holistic phenomena manifested simply for a communication between constituents. Data types can after a certain number of interactions among the constituents that have inherent functions, and functions can have associated expres- produces a superior result that could not be delivered by any one sions. Mediators and systems have gates, data types, and behaviors, of them in isolation. Examples include a home security behavior as well as the SoS architecture itself. Coalitions are an arrange- that could emerge from a set of individual systems installed in a ment of systems (constituents), and Systems are mediated by me- smart home. In short, an emergent behavior is classified, despite diators (Oquendo and Legay 2015). SosADL supports specifying further refinements, as Weak or Strong (Chalmers 2006; Mittal and weak emergent behavior by the idea of coalition, a temporary al- Rainey 2015). The former is reducible to a simulation, whilst the liance for combined action among constituents connected by medi- latter can not be simulated by a computer (for example, life as a ators. Those behaviors are specified as part of the coalition behav- result from the parts that constitute alive organisms). Even when ior, documenting how constituents should interact to accomplish a working on weak emergent behaviors, unexpected behaviors can given set of missions. Expressions and values are suppressed in this emerge, jeopardizing involved stakeholders, with potential to cause representation2 . hazards and losses (Chalmers 2006). Then, it is paramount vali- SosADL models are not executable yet. Hence, a dynamic view dating such behaviors, that is, checking the conformance between for architectural descriptions based on SosADL is still required. the pre-established missions and the respective emergent behaviors Model transformations are a well-accepted approach that aid soft- that accomplish them. ware engineers to establish correspondences between models (Sun Under another perspective, software architectures correspond et al. 2008). In particular, Model-Driven Development techniques to the fundamental structure of a software system. They comprise have been investigated in the context of SoS (Graciano Neto et al. software elements, relations among them, and the rationale, prop- 2014; Graciano Neto et al. 2015). Besides, a broad set of tools is erties, and principles governing their design and evolution (Bass available to achieve a proper level of automation using transfor- et al. 2012; iso 2011). In turn, a software architecture of an SoS mation tools, such as Xtend (Bettini 2013) and Acceleo (Eclipse is its fundamental structure, including its constituents and connec- 2012). Thus, a model transformation can be carried out between tions between them, properties of the constituents and of the en- SosADL models and a simulation model in order to preserve the vironment (Nielsen et al. 2015). Indeed, architectural descriptions architectural descriptions and to achieve the dynamics required to are the main work product that express a software architecture (iso visualize and validate emergent behaviors. 2011). They are often specified based on ADL (iso 2011). A validation approach for emergent behaviors in SoS soft- ware architectures requires a dynamic view that externalizes such behaviors. Such an approach should allow software architects to predict and validate desired emergent behaviors, and also prevent unexpected behaviors by monitoring the SoS dynam- ics. Currently, there are four major categories of techniques for validating software architectures3 : scenario-based, simulation- based, mathematical/logical-based, and experience-/metric-based. Considering the dynamic nature of SoS software architectures, a simulation-based approach is undoubtedly the best choice4 . Nonetheless, known ADL for SoS are not subject to runtime exe- cution or simulation. Thus, they do not provide a dynamic view for SoS software architecture descriptions (Guessi et al. 2015a). Simulation-based approaches have supported the validation of dynamic properties for SoS (Nielsen et al. 2015; Mittal and Rainey 2015; Michael et al. 2009; Sauser et al. 2010; Zeigler et al. 2012; Wachholder and Stary 2015) and have recently been investigated in the context of software engineering (de França and Travassos 2016). Such approaches (Michael et al. 2011; de França and Travas- Figure 1. An excerpt of the SosADL metamodel. 2 More details about the syntax of architecture descriptions in SosADL and its elements can be found in (Oquendo 2016a). SosADL is a novel ADL conceived to support the specification 3 Dobrica and Niemela discuss further details about validation methods for of architectural descriptions for software architecture of SoS. It has software architecture (Dobrica and Niemele 2002; Michael et al. 2009, been created to overcome the drawbacks exhibited by precedent 2011). ones (Oquendo and Legay 2015; Oquendo 2016a,b), such as the 4 Nielsen et al. deeply discuss simulation approaches for SoS (Nielsen et al. difficulties to specify multiple individual systems interoperating, 2015). Validating Emergent Behaviors in SoS through Model Transformations 2 2016/12/9 Support for Support for Software Architectural Support for Validation Approach Specification of Description of SoS of Emergent Behaviors Emergent Behaviors Bigraph (Wachholder and Stary 2015) 7 X 7 Cavalcante et al. (Cavalcante et al. 2014) 7 X 7 CML (Woodcock et al. 2012) X 7 7 DEVS (Zeigler et al. 2012) 7 X X Michael et al. (Michael et al. 2011) 7 X 7 Systomics (Sauser et al. 2010) 7 X 7 SySML (OMG 2016a) X 7 7 UML (OMG 2016b) X 7 7 Xia et al. (Xia et al. 2013) 7 7 X Our approach X X X Table 1. Comparison between co-related approaches. sos 2016; Wachholder and Stary 2015; Xia et al. 2013): (i) support of abstraction for architectural descriptions of SoS and the required the validation of expected emergent behaviors, (ii) empower the dynamic view for validation of emergent behaviors. observation of unexpected emergent behaviors; (iii) enable the pre- Related Work. Several initiatives have been proposed to address diction of errors, diagnosing them and permitting corrections; and the description of SoS software architectures, representation, and (iv) provide a visual and dynamic view, reproducing stimuli that the validation of emergent behaviors of SoS. Table 1 shows a compar- system can receive from the environment. ison among related work and characteristics offered by them. Bigraph-based modeling offers a solution for mathematically representing emergent behaviors in SoS through a formalism based on a special type of graphs (Wachholder and Stary 2015). However, there is not a support for description of software architectures of SoS, nor a validation approach. Cavalcante et al. (Cavalcante et al. 2014) report a model trans- formation approach that adopts π-ADL architectural models to describe dynamic architectures, that is, software architectures in which components and connectors can be created, interconnected, and/or removed during system execution, transforming π-ADL models in Go software code. Their work does not have focus on the validation of SoS’ emergent behaviors, and Go is not a simu- lation model. Although π-ADL provides architectural description models for concurrent and communication processes, it does not provide straightforward abstractions of some particular concepts of SoS, such as mediator and coalition. Figure 2. DEVS simplified metamodel for DEVSNL, adapted Xia et al. (Xia et al. 2013) perform evaluation of SoS architec- from (Cetinkaya et al. 2012). tures documented in DoDAF (dod 2010) through a model-driven approach that transforms system architecture models in executable DEVS is an option to support SoS simulation (Zeigler et al. models described in Simulink6 . More precisely, their approach is 2012). It corresponds to a modeling formalism for SoS based on concerned with the entire SoS, including hardware issues, while atomic and coupled models. Atomic models represent individual our approach is focused only on software architecture. Moreover, entities in the SoS (for instance, systems), while coupled models they focus their evaluation on technical aspects of the SoS, mea- represent a combination of atomic models. Figure 2 depicts DEVS suring non-functional properties such as feasibility and efficiency. basic elements. Atomic models comprise the following elements: Validation of the rationality and correctness of logic and behavior (i) ports (input and output); (ii) a labeled state diagram that per- of the architectural models are considered supported and a possi- forms transitions due to input or output events; (iii) functions that bility, but validation is not properly performed. can be used to process data; (iv) data types; and (v) events. In par- Another perspective involves bio-inspired initiatives, such as the ticular, a state diagram is a set of states and transitions, in which Systomics approach (Sauser et al. 2010), establishing analogies to a transition is necessarily from one state to another state. Cou- construct models to represent emergent behaviors in SoS. However, pled models are expressed as a System Entity Structure (SES), that it does not properly offer a validation for emergent behaviors. In is, a formal structure governed by a small number of axioms that turn, Michael et al. (Michael et al. 2011) propose a mathematical expresses how atomic models communicate between themselves notation to deal with verification and validation of software archi- (Zeigler et al. 2012). We chose SosADL and DEVS to compose our tectures of SoS (as a whole). Simulation is mentioned, focusing approach since SosADL suppresses the disadvantages of the other on verification of non-functional requirements, with no mention to ADL as aforementioned, and DEVS was conceived especially for validation of emergent behaviors. Moreover, all of those notations simulation of SoS. We adopted a DEVS dialect called DEVS Nat- do not exhibit a suitable level of abstraction for the purposes of ural Language (DEVSNL) that enables programming atomic and software architecture description of SoS. coupled models in a human-like format in tools such as MS4ME5 . DEVS itself is an approach for SoS simulation and validation The combination of SosADL and DEVS offers the necessary level of emergent behavior (Zeigler et al. 2012). However, it does not 5 http://goo.gl/NmBBuu 6 www.mathworks.com/products/simulink/ Validating Emergent Behaviors in SoS through Model Transformations 3 2016/12/9 support a representation, relying on systems engineering concepts, transitions that cause the emission of data to another system or tran- which can be unsuitable for software architects. Transformations sitions that are triggered by the reception of data, respectively. from distinct models to DEVS in order to make the former exe- Architecture, Coalition, and SoS. These structures are mapped cutable have been proposed (Cetinkaya et al. 2012; Gonzalez et al. into coupled models, being converted in the specification of how 2015; Hu et al. 2014). However, no focus on software architectural they promote the SoS operation. descriptions of SoS in DEVS has been found. Connections and Gates. In SosADL, connections are abstractions In parallel, languages for specifying SoS architectures can of links between gates from different communicating entities that be identified (Guessi et al. 2015b): UML (OMG 2016b) (semi- establish a channel to transmit data. Multiple connections (input formal), SysML (OMG 2016a) (semi-formal), CML (Woodcock and output), can be established on the same gate. Translating to et al. 2012) (formal). UML does not support a suitable specifica- SES/DEVS, the gate concept is suppressed, and connections are tion of software architectures of SoS (Guessi et al. 2015b). SysML mapped into ports (input and output ports). lacks specific structures for modeling some aspects of software Data Types. Data types in SosADL become data types in DEVS. architecture of SoS and it is also a static specification, with no They can be Abstract Data Types (ADT) or simple types, such as support for validation of emergent behaviors (Guessi et al. 2015b). integer. They can be exchanged in messages among systems. CML is a formal language especially conceived for SoS formal Functions. Analogously, function declarations of SosADL are con- specification within the context of the Comprehensive Modelling verted in functions in DEVS. The discussion of their mapping is for Advanced Systems of Systems (COMPASS) alliance. However, beyond the scope of this paper. it focuses on the verification of emergent behaviors, not on their During the transformation, a SoS architectural description writ- validation (Fitzgerald et al. 2013). ten in SosADL is verified against the abstract syntax of SosADL described in Xtext7 . If the SosADL code conforms to the Xtext 3. A Transformation Approach to Support grammar, the code is submitted as input for an Xtend8 script that materializes the code generator. A functional code written in DE- Validation of Emergent Behaviors VSNL is generated as output. We established a model-based transformation approach to map SosADL models into SES/DEVS models. In our approach, we dis- tinguish two main roles involved in SoS conception: Software Ar- Listing 1. A transformation rule corresponding to chitect and System Architect. From the software architect’s view- receive statement in SosADL, which becomes an point, a SoS is examined under a static perspective regarding the input transition in DEVSNL. 1 def String g e n e r a t i o n O f I n p u t T r a n s i t i o n () ’’’ software architecture itself without support for visualizing emer- 2 passivate in s < < fromState > >! gent behaviors. From the systems architect’s viewpoint, the SoS is 3 when in s < < fromState > > and receive << analyzed from a dynamic perspective considering state diagrams, dataReceived > > go to s < < toState > >! constituents, inputs and outputs, with support for emergent behav- 4 ’’’ ior validation but without an explicit software architecture. To over- come the drawbacks exhibited, our approach merges the advantages offered by systems and software architecture bridging both models Listing 1 shows an excerpt of a transformation rule used to by means of a mapping between them, supporting both software map a statement receive written in SosADL in an input transition architecture and validation of emergent behaviors for SoS software specification in DEVS. This rule is in the context of an ADT architecture, offering dynamic and static views. defined within the Xtend transformation code. This ADT is an Table 2 presents the correspondences between SosADL and abstraction of a DEVS Transition and gives access to the states DEVS to establish the transformation. involved in the transition (source and target), and to the data being received. The automata is extracted using Xtend and constructed according to the abstract syntax tree provided by Xtext/Xtend. Table 2. Mapping between SoSADL and SES/DEVS Then, these data are used to create a couple of lines of code in SoSADL SES/DEVS DEVS. Line 2 in Listing 1 expresses that the execution waits in Architecture Coupled Model the state sn (where n is the number that identifies an specific state) Behavior State Diagram until receiving a specific data. Then, Line 3 declares that when this Connection DEVS Port occurs, a transition to a second state occurs. Line 4 closes the scope Coalition Coupled Model of the method specified in Xtend. Data Type Data Type Function DEVS Function Mediator Atomic Model 4. Preliminary Results SoS Coupled Model We adopted our approach in a practical case study: a Flood Mon- System Atomic Model itoring SoS (FMSoS), that is, an SoS composed of smart sensors that use software to monitor the occurrences of floods in an ur- ban area of the city of São Carlos in Brazil. Rivers cross the city and, when the rains are intense, floods often occur, causing property loss, damage, and serious danger to the population. The FMSoS is System and Mediator. Both concepts become atomic models in used to illustrate the validation of a single emergent behavior: flood DEVS. They are represented as single entities in the simulation alert. Constituents are smart sensors. They are spread on the river model. They have their own behavior expressed as a state diagram. edges at a regular distance with mediators between them. The data Behavior Declaration. Behaviors in SosADL are specified by a is collected by sensors and transmitted until reaching the gateway. list of statements. These statements are similar to basic instruc- When flooding occurs, the gateway emits an alarm for the public tions available in programming languages, such as type declaration, authorities. and sequences. Each statement becomes one or more transitions 7 https://eclipse.org/Xtext/ in a a state diagram (automaton) in DEVS. Important operations in SosADL include send and receive, that are translated into state 8 xtend-lang.org/ Validating Emergent Behaviors in SoS through Model Transformations 4 2016/12/9 The transformation was successfully run and the atomic and 5. Final Remarks coupled models accordingly generated. A brief video demonstrat- This paper presented preliminary results of a research being con- ing the generated simulation is available9 . Some important points ducted to answer this question: How to validate emergent behaviors must be highlighted about this specific transformations, as follows: in SoS preserving their software architectures? We proposed a so- lution to transform a software architecture description written in SosADL to a simulation model in DEVS, harmonizing both for- • Adaptations in source model. Specification of such a transfor- malisms by means of a mapping between them. Our approach con- mation helped in the improvement of the source model, since tributes by: (i) offering a solution as how to transform an software some conflicting names of variables were diagnosed during architecture description of SoS into a simulation formalism, guar- the transformation, good practices of specification for SosADL anteeing traceability between those models, high-level of abstrac- models were discovered, and even incomplete specification be- tion in the SoS software architecture specification and automation; came evident when the transformation started to be executed, (ii) supporting validation of weak emergent behaviors by analyzing aiding in the completion of the source code. Hence, a possible the conformance between SoS missions and emergent behaviors conjecture is that the adoption of model transformations in our manifested during SoS operation; and (iii) offering a visual and approach may have helped in the improvement of the quality of dynamic view for SoS software architecture descriptions. a source model of SoS, since this approach offers a visualization Uniqueness. Our approach is the only one reported that provides of the resultant dynamics, and the consequences of decisions in a dynamic view for SoS software architectural descriptions and the specification of the source model; validation support for emergent behaviors by means of a trans- • Maturity of the language. A model-driven approach for spec- formation. SosADL supports representation of dynamic properties ification and execution of software architectures of SoS helped such as emergent behaviors. Furthermore, as a consequence, model even in the maturity of the SosADL language itself. Since the transformations provide the operational semantics for SosADL ADL is quite novel and still subject to adaptations, some is- models, that is, the meaning of SosADL statements in terms of sues about the possibility of multiple behaviors in a same con- execution, translating it in simulation models (Sun et al. 2008), stituent were discussed and some points about the definition of such as (Shakshuki et al. 2015). data types were also clarified, such as the convention of assign Contributions. Specification of an SoS in SosADL is more ab- the type Integer for any type of data that were specified as ab- stract and leads to programming in a language closer to software stract (such as a type Energy), but without an explicit attribute architect’s current practices. Indeed, SosADL is the unique for- type assigned to be effectively used. mal current state of the art notation for describing software archi- tectures of SoS that deals with emergent behaviors (Guessi et al. • Stimuli Generator. It is important to highlight that there exist 2015b; Oquendo 2016a). Moreover, our approach provides some atomic models in the functional example called stimuli genera- contribution (directly or indirectly) to some of the topics of interest tors. They consist of abstractions of systems that continuously for the MODELS community, such as: emit the stimuli necessary to trigger the SoS operation, such as delivering the coordinates lps originally delivered by a GPS, or the level of water collected by a sensor. Stimuli generator is • Development and use of models: providing an operational se- used to create the first two portions of code, sending lps coor- mantics by means of a model transformation is a quite novel ap- dinates, powerLevel, and a first sense, that is, a data collected proach. Moreover, we establish this for an ADL that describes by the sensor that will trigger systems behavior execution in all software architectures of SoS. As far as we know, we do not of the systems. We also automatically derive it from the spec- know other initiatives in this direction; ification of the source models written in SosADL. This struc- ture makes the simulation functional. More details about this • Integration of modeling languages and tools (hybrid multi- approach are found in (Graciano Neto et al. 2016). modeling approaches): Our approach harmonizes distinct • Transformations execution. Each transformation takes no paradigms of model-based engineering (software engineering and systems engineering) by means of transformation. It is not more than milliseconds to be run. They run without errors. Two a new trend (Sun et al. 2008; Shakshuki et al. 2015), but com- different types of transformations are executed. One to generate bining a software architecture model for SoS and a simulation atomic models, and another to generate coupled models. Hence, model is unique and a novel approach. we run the transformation four times: one to generate sensor, another one to generate mediator, another one to generate gate- • Modeling with, and for, new and emerging systems and way (all atomic models), and a last one to generate the coupled paradigms: Software-intensive SoS is an emergent domain. A model. This is necessary because the structures that model an recent systematic literature review revealed that about 75% of architecture in SosADL do not hold definitions about the data the publications addressing SoS appeared in the last five years types being transferred (essential for coupled models). Thus, it and approximately 90% in the last 10 years (Guessi et al. 2015b; is necessary to infer the type being transferred between atomic Oquendo and Legay 2015), whilst most of those studies com- models to generate it automatically in the coupled models. The municates open issues on SoS software architecture and engi- strategy adopted was: (i) generation of all the atomic models, neering. Software Engineering of SoS (SESoS), in turn, is even (ii) saving the definition of the connections in the SosADL more recent and subject to investigation. Hence, we believe our specification (format connection::gate;dataTypeName) in solution represents an advance towards a more accurate treat- a text file and (iii) reading it during the coupled model genera- ment of emergent behaviors in SoS software architectures; tion. Since the name of the pair connection::gate is unique for the entire SoS, it is possible to infer the type of the data being transferred. Future works include (i) further case studies and experiments, (ii) the extension of our approach to validate multiple concurrent emergent behaviors, and (iii) a deeper investigation on the emer- gence of unpredicted behaviors, establishing techniques to prevent 9 https://goo.gl/cf6sef them. Validating Emergent Behaviors in SoS through Model Transformations 5 2016/12/9 Acknowledgments J. Hu, L. Huang, B. Cao, and X. Chang. Extended DEVSML as a Model Transformation Intermediary to Make UML Diagrams Executable. In The author thanks CNPq (grant:201230/2015-1/SWE) and FAPESP SEKE, 2014. (grant: 2013/20317-9) for the financial support. M. Jamshidi. System of systems - innovations for 21st century. In 2008 IEEE Region 10 and the Third international Conference on Industrial References and Information Systems, pages 6–7, Dec 2008. The DoDAF Architecture Framework Version 2.02. US. Department of M. W. Maier. Architecting principles for systems-of-systems. Systems Defense, Aug. 2010. Engineering, 1(4):267–284, 1998. J. B. Michael, R. Riehle, and M. T. Shing. The verification and validation ISO/IEC/IEEE Systems and software engineering – Architecture descrip- of software architecture for systems of systems. In SoSE, pages 1–6, tion. ISO/IEC/IEEE 42010:2011, pages 1–46, Dec 2011. Albuquerque, NM, USA, May 2009. L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. J. B. Michael, D. Drusinsky, T. W. Otani, and M.-T. Shing. Verification Addison-Wesley Professional, 3rd edition, 2012. and validation for trustworthy software systems. IEEE Software, 28(6): L. Bettini. Implementing Domain-Specific Languages with Xtext and Xtend. 86–92, 2011. Packt Publishing, 2013. S. Mittal and L. Rainey. Harnessing Emergence: The Control and Design J. Boardman and B. Sauser. System of systems - the meaning of of. In of Emergent Behavior in System of Systems Engineering. In SCS, pages SOSE, pages 6 pp.–, Los Angeles, California, USA, April 2006. 1–10, San Diego, CA, USA, 2015. SCSI. B. Boehm. A view of 20th and 21st century software engineering. In Pro- E. Y. Nakagawa, M. Gonçalves, M. Guessi, L. B. R. Oliveira, and ceedings of the 28th International Conference on Software Engineering, F. Oquendo. The state of the art and future perspectives in systems of ICSE ’06, pages 12–29, New York, NY, USA, 2006. ACM. systems software architectures. SESoS ’13, pages 13–20, New York, NY, USA, 2013. ACM. E. Cavalcante, F. Oquendo, and T. V. Batista. Architecture-Based Code Generation: From π-ADL Architecture Descriptions to Implementations C. B. Nielsen, P. G. Larsen, J. Fitzgerald, J. Woodcock, and J. Peleska. in the Go Language. In ECSA, pages 130–145, Vienna, Austria, 2014. Systems of Systems Engineering: Basic Concepts, Model-Based Tech- niques, and Research Directions. ACM Comput. Surv., 48(2):18:1– D. Cetinkaya, A. Verbraeck, and M. D. Seck. Model Transformation from 18:41, Sept. 2015. BPMN to DEVS in the MDD4MS Framework. In STMS, pages 1–6, Orlando, USA, 2012. OMG. SysML Open Source Specification Project, 2016a. Available in: http://sysml.org/. Last Access: June 2016. D. J. Chalmers. Strong and weak emergence. In P. Davies and P. Clay- ton, editors, The Re-Emergence of Emergence. Oxford University Press, OMG. UML: Unified Modeling Language, 2016b. 2006. http://www.omg.org/spec/UML. April 2016. B. B. N. de França and G. H. Travassos. Experimentation with dy- F. Oquendo. Formally Describing the Software Architecture of Systems-of- namic simulation models in software engineering: planning and re- Systems with SosADL. In SOSE, pages 1–6, Kongsberg, Norway, June porting guidelines. Empirical Software Engineering, 21(3):1302–1345, 2016a. IEEE. 2016. F. Oquendo. π-Calculus for SoS: A Foundation for Formally Describing Software-intensive Systems-of-Systems. In SOSE, pages 7–12, Kongs- L. Dobrica and E. Niemele. A survey on software architecture analysis berg, Norway, June 2016b. IEEE. methods. IEEE Trans. Softw. Eng., 28(7):638–653, July 2002. F. Oquendo and A. Legay. Formal Architecture Description of Trustworthy Eclipse. Acceleo, 2012. URL http://www.eclipse.org/acceleo/. Systems-of-Systems with SosADL. ERCIM News, (102), 2015. J. Fitzgerald, S. Foster, C. Ingram, P. G. Larsen, and J. Woodcock. Model- ROAD2SOS. Road2SoS Project - Roadmaps for Systems-of-Systems based Engineering for Systems of Systems: the COMPASS Manifesto. Engineering, 2013. http://road2sos-project.eu/cms/front_ Technical Report Manifesto Version 1.0, COMPASS Interest Group, Oc- content.php. Last Access: July 2016. tober 2013. URL http://www.compass-research.eu/Project/ Publications/MBESoS.pdf. B. Sauser, J. Boardman, and D. Verma. Systomics: Toward a Biology of System of Systems. IEEE Trans. on Systems, Man, and Cybernetics, 40 A. Gonzalez, C. Luna, M. Daniele, R. Cuello, and M. Perez. Towards an (4):803–814, 2010. automatic model transformation mechanism from UML state machines to DEVS models. CLEI Electron. J., 18(2), 2015. E. Shakshuki, S. Galland, A.-U.-H. Yasar, N. Messaoudi, A. Chaoui, and M. Bettaz. An operational semantics for uml 2 sequence diagrams V. V. Graciano Neto, M. Guessi, L. B. R. Oliveira, F. Oquendo, and E. Y. supported by model transformations. Procedia Computer Science, 56: Nakagawa. Investigating the model-driven development for systems-of- 604 – 611, 2015. systems. ECSAW ’14, pages 22:1–22:8, New York, NY, USA, 2014. ACM. Y. Sun, Z. Demirezen, T. Lukman, M. Mernik, and J. Gray. Model Transfor- mations Require Formal Semantics. In J. Lawall and L. Réveillère, edi- V. V. Graciano Neto, M. Guessi, L. B. R. de Oliveira, F. Oquendo, L. Garcs, tors, Domain-Specific Program Development, page 5, Nashville, United and E. Y. Nakagawa. A conceptual map of model-driven development States, 2008. for systems-of-systems. WDES’ 15, pages 89–92, Belo Horizonte, D. Wachholder and C. Stary. Enabling emergent behavior in systems-of- Brazil, 2015. SBC. systems through bigraph-based modeling. In SOSE, pages 334–339, San V. V. Graciano Neto, C. E. B. Paes, F. Oquendo, and E. Y. Nakagawa. Antonio, TX, USA, May 2015. IEEE. Supporting simulation of systems-of-systems software architectures by G. Wiederhold. Mediators in the architecture of future information systems. a model-driven derivation of a stimulus generator. WDES’ 16, pages Computer, 25(3):38–49, March 1992. 1–10, Maringá, Brazil, 2016. SBC. J. Woodcock, A. Cavalcanti, J. Fitzgerald, P. Larsen, A. Miyazawa, and B. Graham. Nature’s Patterns - Exploring Her Tangled Web. FreshVista, S. Perry. Features of CML: A formal modelling language for Systems 2013. of Systems. In SOSE, pages 1–6, Genova, Italy, July 2012. M. Guessi, E. Cavalcante, and L. B. R. Oliveira. Characterizing architecture X. Xia, J. Wu, C. Liu, and L. Xu. A model-driven approach for evaluating description languages for software-intensive systems-of-systems. In 3rd system of systems. In ICECCS, pages 56–64, Singapore, July 2013. SESoS, pages 12–18, Florence, Italy, May 2015a. IEEE. P. Zave. Feature interactions and formal specifications in telecommunica- M. Guessi, V. V. Graciano Neto, T. Bianchi, K. R. Felizardo, F. Oquendo, tions. Computer, 26(8):20–29, Aug. 1993. and E. Y. Nakagawa. A systematic literature review on the description of software architectures for systems of systems. In SAC, pages 1433– B. P. Zeigler, H. S. Sarjoughian, R. Duboz, and J.-C. Souli. Guide to Modeling and Simulation of Systems of Systems. Springer, 2012. 1440, Salamanca, Spain, April 2015b. Validating Emergent Behaviors in SoS through Model Transformations 6 2016/12/9