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.