Automated Analysis of Multi-View Software Architectures Chih-Hong Cheng Yassine Hamza Harald Ruess fortiss GmbH Munich, Germany cheng@fortiss.org Technische Universität München Munich, Germany yassine.hamza@tum.de fortiss GmbH Munich, Germany ruess@fortiss.org arXiv:1704.07097v1 [cs.SE] 24 Apr 2017 ABSTRACT Software architectures usually are comprised of different views for capturing static, runtime, and deployment aspects. What is currently missing, however, are formal validation and verification techniques of multi-view architecture in very early phases of the software development lifecycle. The main contribution of this paper therefore is the construction of a single formal model (in Promela) for certain stylized, and widely used, multi-view architectures by suitably interpreting and fusing sub-models from different UML diagrams. Possible counter-examples produced by model checking are fed back as test scenarios for debugging the multi-view architectural model. We have implemented this algorithm as a plug-in for the Enterprise Architect development tool, and successfully used SPIN model checking for debugging some industrial architectural multi-view models by identifying a number of undesirable corner cases. KEYWORDS multi-view architecture analysis, SPIN model checker ACM Reference format: Chih-Hong Cheng, Yassine Hamza, and Harald Ruess. 2016. Automated Analysis of Multi-View Software Architectures. In Proceedings of ACM Conference, Washington, DC, USA, July 2017 (Conference’17), 4 pages. DOI: 10.1145/nnnnnnn.nnnnnnn 1 INTRODUCTION Software architectures usually are comprised of different views for capturing static, runtime, and deployment aspects [1, 4]. The static/component view describes the logical decomposition of the system into building blocks (e.g., packages, components, classes), whereas the runtime view describes the behavior and interaction of the building blocks as runtime elements in the running system, using diagrams such as sequence diagrams, activity diagrams, or state machines, and the deployment view shows how software is assigned to hardware processing and communication elements. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. Conference’17, Washington, DC, USA © 2016 ACM. 978-x-xxxx-xxxx-x/YY/MM. . . $15.00 DOI: 10.1145/nnnnnnn.nnnnnnn In the current state-of-the-practice, architectural models are analyzed in early phases in the software development cycle, mainly by means of manual and resource-intensive review frameworks such as the Architectural Trade-off Analysis Method (ATAM) [4]. What is currently missing, however, are formal analysis techniques of multi-view architectures for early and automated detection of, say, unwanted behavior due to under-specification. In this paper, we therefore reconstruct a single model of a multi-view architecture, which is suitable for formal analysis, by fusing sub-models of different views in UML diagrams [15], as provided, for example in architectural development tools such as Enterprise Architect. Our fusion algorithm proceeds by taking deployment views as skeletons to offer basic communication structure over processes and channels in the actual system. The concrete behavior of each deployed software component — as documented in the static view — is captured by run-time views. One notable challenge is to cope with under-specification among views, as dynamic architectural views often only capture certain scenarios but not the complete component behavior and all possible interactions. To this end, semantic extrapolation is needed for constructing a model-checkable verification model and we enumerate possible extrapolation strategies. We have implemented our fusion algorithm as a plugin for Enterprise Architect (EA). This plug-in generates verification models in the Promela language, which are used as inputs to the SPIN model checker [6]. Counter-examples generated by the model-checkers are used as test cases for debugging the multi-view architectural model. We evaluated this EA plug-in in early phases of developing two missioncritical distributed software systems in industrial projects, and successfully identified undesired corner cases due to under-specification in the model. (Related work) There is a rich literature on the verification of UML-like diagrams. For example, refinement of activity diagrams has been based on LTL model checking [13], and state machine diagrams have been translated to hierarchical automata as the basis for model checking [11, 14, 16]. Moreover, sequence diagrams have a straightforward correspondence to communicating processes and process algebras [3, 10, 17]. Use case diagrams can be checked for consistency or containment by means of viewing them as programs with constraints [7] or by a translation into activity diagrams [8]. Lastly, using annotations such as UML Marte profile [5], one may verify extra-functional properties such as timing [12]. In contrast to these approaches we are analyzing multi-view architectural models, which include static, runtime, and deployment views, being restricted to a certain stylized use and linking between Conference’17, July 2017, Washington, DC, USA Chih-Hong Cheng, Yassine Hamza, and Harald Ruess Elements Static View (Software Component) Link among views SC1 SC2 SC3 Runtime View Deployment View StateMachine 1 Device2 State1 (SequenceDiagram1) C2: SC1 act0: SC1 Network1 act2: SC2 abc Device1 C1: SC2 Device3 C3: SC2 def ... State2 (Sequence Diagram 2) C4: SC3 Figure 1: Example of a stylized multi-view software architecture model. views. We therefore do not address or even try to solve the general multi-view consistency problem for UML [9]. 2 MULTI-VIEW SOFTWARE ARCHITECTURE AND VIEW LINKING Using architectural development tools such as Enterprise Architect (EA), the designer may maintain links among multiple views by creating components in the static view, by building runtime and deployment view using components in the static view, and by associating each diagram with a component or a sub-structure. Figure 1 illustrates these concepts using a simple architectural example.1 There are three software components SC1, SC2, and SC3 in the static view. In the deployment view, three devices Device1, Device2, Device3 are included in the final deployed system, where for each device, the underlying software components are created (using drag-and-drop in EA) as an instantiation of components in the static view. For example, for the Device2 in Figure 1, C2 is an instance of the software component SC1 from the static view. For each software component in the static view there is a state machine or activity diagram in the behavioral view, where each of the states provides behavioral scenarios for different execution modes (for example, normal and error modes). Behavior and interaction in each state (or mode) are expressed in terms of scenarios expressed as sequence diagrams. In Figure 1, for example the behavior of component SC1 is refined to StateMachine1, where internally, State1 is further refined into SequenceDiagram1. Notice also that in SequenceDiagram1, the actor act0 is surrounded by a dashed component. This is often used in UML modeling as a modeling trick to capture system boundary. Such a boundary allows modeling the interaction of multiple instantiations of the same component, as commonly seen in fault-tolerant systems where redundancy and distributed voting are applied. 1 For the example in Figure 1, a model in Enterprise Architect (freely available for model viewing) which maintains such symbolic links can be downloaded at https://www.dropbox.com/s/hg8jiddxh6rs5xs/ NFM Model.eap. We also refer readers to https://youtu.be/9Mg 2UH5vDM for a video showing how the link of views are maintained under Enterprise Architect, together with how our prototypical tool automatically generates verification models in Promela form. Meaning Corresponding Promela construct Messages Set of message with con- mtype = {abc, def}; {abc, def} tents chan1 Synchronous channel chan chan1 = [0] of ∈ Channels mtype; chan2[3] Asynchronous channel chan chan2 = [3] of named chan2 with buffer mtype; ∈ Channels size 3 Action Program label ”S3”, S3: hLabel: S3i move to next action in the process Action Non-deterministically int i; select (i : 0..1); hGoto{S3, S4}i jump to label S3 or S4 if :: i != 1 -> goto S3 :: i == 1 -> goto S4 fi; Action Send message abc to chan1 !abc; hchan1 !abci channel chan1 Action Receive message def from chan2 ?def; hchan2 ?defi channel chan2 Table 1: Constructs in verification model and their corresponding formulation in Promela. We are now providing a formal signature for these multiview architectural concepts; hereby, A.B is used to denote the projection of A with respect to B. A multi-view architectural model Arch is a triple hComponentView, RuntimeView, DeploymentViewi. ComponentView consists of set of software components where SCi ∈ ComponentView can again be refined to a set of components; for expressing, for example, a ”uses” structure. For the purposes of this paper, such a hierarchical component view can always considered to be in flattened form. The DeploymentView is a pair hDevices, Networki of sets. First, every device Devicei ∈ Devices is a set itself of instantiated software components, and for every Ci ∈ Devicei is of type SCj where SCj ∈ ComponentView. We use Ci .type to denote the typing information. Second, pairs of devices Devicei , Devicej ∈ Network, where Devicei , Devicej ∈ Devices, are interpreted as directed (from left-to-right) edges between devices. Finally, the RuntimeView is a quadruple hStateMachines, SequenceDiagrams, mapSC→State , mapState→Seq i. • StateMachines is the set of state machines with each element SMi := statesi , s0i , trani having a set of states statesi , an initial state s0i and the set of transitions strani . We use SMi .s to denote a state s in state machine SMi . • SequenceDiagrams is the set of sequence diagrams. Again for simplifying formulation, let elements in sequence diagrams be variable-free, straight-line (i.e., no if-else or while) programs. An element SeqDiagram ∈ SequenceDiagrams is a tuple Act, act0 , where Act is the set of actors and act0 is the one that is in the system boundary (cf. act0 in Figure 1). Each actor acti ∈ Act is a tuple htypei , Msgi i where typei ∈ ComponentView indicates the typing of the actor by referencing the element in component view, and Msg is the finite concatenation of messages msgi0 msgi1 . . . msgik , where forall j = 0, . . . , k, msgik ∈ {!, ?}×{syn, asyn}× Σ ×Act. In message msgik , {!, ?} indicates if the message is being sent Automated Analysis of Multi-View Software Architectures Algorithm 1: View fusing algorithm Input 1 2 3 4 5 6 7 8 9 10 11 12 13 14 : Multi-view architecture model: hComponentView, RuntimeView, DeploymentViewi Output : Verification model: Processes, Channels, Messages foreach SeqDiagram ∈ RuntimeView.SequenceDiagrams do for acti = SCi , Msgi ∈ SeqDiagram.Act do Messages := Messages ∪ Msgi ; foreach Devicei , Devicej ∈ DeploymentView.Network do Channels = Channels ∪ {chanDevicei →Devicej } foreach Devicei ∈ DeploymentView.Device do for Cj , Ck ∈ Devicei do Channels = Channels ∪ {chanCj →Ck }; foreach Devicei ∈ DeploymentView.Device do foreach Cj ∈ Devicei do let SMj = mapSC→SM Cj .type; let Prj := hGoto{s0 }i, where s0 be the initial state of SMj ; foreach State s ∈ SMj .states do Prj := Prj · hLabel: si ; let SeqDiagramj = Actj , act0j := mapState→Seq s; foreach message κ, syn, σ, act′ ∈ act0j .Msg, κ ∈ {“!”, “?”} do if κ = “!” then Prj := Prj · hchanCj →Ck !σi, where Ck ∈ Devicei s.t. Conference’17, July 2017, Washington, DC, USA 1 mtype = { abc, def }; // By line 1-2 ... 2 chan Network1_Device2toDevice1Channel = [0] of {mtype}; 3 chan Network1_Device2toDevice3Channel = [0] of {mtype}; 4 chan Network1_Device1toDevice2Channel = [0] of {mtype}; 5 chan Network1_Device3toDevice2Channel = [0] of {mtype}; ... 6 active proctype Device2_C2(){ // By line 7,8,22 7 /* Jump to initial state*/ 8 goto State1; // By line 10 9 State1: // By line 12 10 /* Contents from sequence diagram */ 11 Network1_Device2toDevice1Channel!abc; // By line 17 12 Network1_Device2toDevice3Channel!abc; 13 Network1_Device1toDevice2Channel?def; // By line 20 14 Network1_Device3toDevice2Channel?def; 15 /* Implement the transition*/ 16 goto State2; // By line 21 17 State2: 18 /* ... (details omitted) ... */ 19 goto State1; 20 } Figure 2: Verification model in Promela form, by running Algorithm 1 over the example in Figure 1. where Messages is the set of messages, Channels is the set of (synchronous or asynchronous-with-fixed-buffer) channels, 16 and Processes is a set of processes. Hereby, each process ′ Ck .type = act .type; Process is a sequence of atomic actions, including labels, non17 Prj := Prj · hchanDevicei →Devicek !σi, where deterministic goto primitives, and message send/receive. The ′ Ck ∈ Devicek s.t. i , j and Ck .type = act .type; semantics of a verification model is based on Promela [6]. 18 else For the purpose of reference, however, we are listing some 19 Prj := Prj · hchanCk →Cj ?σi, where Ck ∈ Devicei s.t. correspondence of constructs in the architectural model and Ck .type = act′ .type; corresponding verification models in Table 1. 20 Prj := Prj · hchanDevicek →Devicei ?σi, where Now, the workflow presented in Algorithm 1 translates ′ Ck ∈ Devicek s.t. i , j and Ck .type = act .type a multi-view architecture into a formal verification model. /* Jump to successor in state-machine For ease of explanation assume all message passing to be diagram. */ synchronous for now. Lines 1 and 2 in Algorithm 1 collect ′ ′ 21 Prj := Prj · hGoto{ s | s ∈ SMj .trans }i; all messages by scanning all actors in the given sequence 22 Processes := Processes ∪ {Prj } diagrams. Next, lines 3 and 4 define device-to-device channels by scanning through the given network element, and lines 5 and 6 define point-to-point channels within a device. Lines 7 (!) or received (?), {syn, asyn} indicates synchronous/asynto 11 start instantiating processes for every deployed software chronous message passing, Σ is used to capture all possible component in the deployment view, where the process starts message contents, and the last item is the entity being by moving to the initial state (line 10). The for-loop in Line 11 communicated. Consider act0 in Figure 1, it is represented traverses through the state-machine diagram, establishes a as hSC1, !, syn, abc, act2?, syn, def, act2i. label for entry (line 12), and creates outgoing transitions to • mapSC→SM maps an element in ComponentView to a state successor states (line 21). Internally, the algorithm jumps machine in StateMachines. For the example in Figure 1, to the corresponding sequence diagram (line 13), and tries mapSC→SM SC1 = StateMachine1. to parse each message being sent or received (line 14) into • mapState→Seq maps a state in a state machine to zero the corresponding channel (line 16-20), where, by probing or one sequence diagram, where if mapSC→State SCi = the deployment view, messages are communicated in the SMj and if for state sj in state machine SMj we have internal channel if the source and destination components mapState→Seq sj = SeqDiagramk = hActk , actk = typek , Msgk i, are located in the same device (line 16, 19). Otherwise, then typek = SCi . For the example in Figure 1, intra-device channels are used for communication (line 17, mapState→Seq StateMachine1.State1 = SequenceDiagram1. 20). Notice that the algorithm simply communicates with all the components having the same type, provided that they are supported by the communication architecture in the 3 MULTI-VIEW FUSION deployment view. This provides the basis for the so-called Based on signatures for multi-view architectural models as extrapolation in standard UML semantics, as discussed below. defined above, we are now describing the process of providing For the example in Figure 1, we use the generated vera behavioral semantics based on fusing multiple views. A ification model in Figure 2 to explain the concept, where verification model is a triple Messages, Channels, Processes, comments in Figure 2 indicates corresponding actions done 15 Conference’17, July 2017, Washington, DC, USA Chih-Hong Cheng, Yassine Hamza, and Harald Ruess Under-specification scenarios In the deployment view, allow components within a device to communicate with each other? Operation over variables both in a state of a state-machine diagram and in the refinement sequence diagram of that state? Unclear requirement in communication buffer size, for asyn. communication? An actor sends to one entity in the sequence diagram, while multiple receivers exists in the deployment view? Mitigation strategies Allow / Disallow / Trigger the designer for actions in Algorithm 1. Notice that the presentation of the translation algorithm is simplified in that it does not support variables, branches and loops. These kinds of extensions are straightforward and are also supported in our prototype implementation. Most interestingly, lines 16-20 in Figure 1 make various assumptions about the architectural model under consideration, and semantic extrapolation is used to determine choices being made during the translation. Such a semantic extrapolation, due to lack of proper semantics in (combining) UML and sometimes due to underspecification in modeling, can be explicitly stated and controlled. Table 2 enumerates some important cases and corresponding strategies for semantic extrapolation in order to complete translation. Table 2: Semantic extrapolation for handling underspecification in diagrams; the underlined items are strategies used in creating the Promela model in Figure 2. 4 REFERENCES EVALUATION AND CONCLUDING REMARKS We have implemented a plug-in for the Enterprise Architect development tool based on the presented translation. We summarize our findings on using this tool in the architectural design and analysis for two industrial developments. • The first case study is a modular adaptive automotive runtime environment. Since this platform has been designed to be fault-tolerant, we annotate possible faults in the deployment view, such as power-outage of a device (fail silent) or lost communication messages. Our tool translates these faults annotation by non-deterministically injecting faults into the generated verification model. In one deployment scenario, a counter-example generated by the SPIN model checker demonstrates that the overall system does not function correctly whenever there are certain faults during start-up, thereby preventing consensus to be reached between computing nodes. • Our second case study is a control automation architecture based on the concept of micro-services and a cloud platform. Again, test cases as generated from SPIN model checking of the fused Promela model were instrumental in debugging and improving the design at an early phase in the development. On the other hand, we have also been experiencing a number of ”automation surprises” due to implicit assumptions on the architecture and the generated fused model. For example, the fused model does not capture the fact that service handlers may be viewed as a non-terminating whileloop program that can handle various requests using switch statements, even though (at least) some designers made such an implicit assumption. These kinds of automation surprises might be hard to avoid when applying formal analysis to architectural notations with ambiguous semantics. It would be most interesting to specify some of the encodings presented here also in a theorem proving environment such as PVS, and to experimentally compare the proposed semantic extrapolation of the behavior of architectural designs with logic- and constraint-based approaches for partially specified systems. Variable operations over variables in a state should appear {before, after} actions in sequence diagram Use pre-defined value / Trigger the designer for actions Send to all entities / Send to one randomly selected entity / Trigger exception [1] The Arc42 portal: http://www.arc42.com. [2] Enterprise architect: http://www.sparxsystems.com.au/. [3] M. Ait Oubelli, N. Younsi, A. Amirat, and A. Menasria. From UML 2.0 sequence diagrams to Promela code by graph transformation using Atom 3. In: CIIA, 2011. [4] L. Bass, P. Clenents, and R. Kazman. Software architecture in practice, 3rd edition. Pearson Education, 2011. [5] S. Gérard and B. Selic. The UML-Marte standardized profile. IFAC Proceedings Volumes, 41(2):6909–6913, 2008. [6] G. J. Holzmann. The SPIN model checker: Primer and reference manual. Addison-Wesley, 2004. [7] R. Klimek and P. Szwed. Formal analysis of use case diagrams. In: Computer Science, 11:115–131, 2010. [8] G. Kösters, H.-W. Six, and M. Winter. Validation and verification of use cases and class models. In: REFSQ, 2001. [9] A. Knapp and T. Mossakowski. Multi-view Consistency in UML. In: arXiv:1610.03960, 2016. [10] V. Lima, C. Talhi, D. Mouheb, M. Debbabi, L. Wang, and M. Pourzandi. Formal verification and validation of UML 2.0 sequence diagrams using source and destination of messages. In: EPTCS, 254:143–160, 2009. [11] S. Liu, Y. Liu, E. André, C. Choppy, J. Sun, B. Wadhwa, and J.-S. Dong. A formal semantics for complete UML state machines with communications. In: iFM, pages 331–346. Springer, 2013. [12] A. Louati, K. Barkaoui, and C. Jerad. Temporal Properties Verification of Real-Time Systems Using UML/MARTE/OCL-RT, In: Formalisms for Reuse and Systems Integration, pages 133–147. Springer, 2015. [13] F. UL Muram, H. Tran, and U. Zdun. Automated mapping of UML activity diagrams to formal specifications for supporting containment checking. FESCA, EPTCS 147:93–107, 2014. [14] A. Niewiadomski, W. Penczek, and M. Szreter. Towards checking parametric reachability for UML state machines. In: PSI, pages 319–330. Springer, 2009. [15] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Pearson Higher Education, 2004. [16] T. Schäfer, A. Knapp, and S. Merz. Model checking UML state machines and collaborations. ENTCS, 55(3):357–369, 2001. [17] S. Sieverding, C. Ellen, and P. Battram. Sequence diagram test case specification and virtual integration analysis using timed-arc Petri nets. In: FESCA, EPTCS 108:17–32, 2013.