A refinement-based approach for specifying multi-scale software architectures: application to SoS

Abstract

Specifying correct software-intensive Systems of Systems architectures is a challenging research direction requiring new modeling abstractions and techniques. For this purpose, we provide a refinement-based approach for multi-scale description of software architectures. We define an incremental process starting from a coarse-grained description, and leading to a fine-grained description. The refinement process involves both system-independent structural features ensuring the model correctness, and specific features related to the expected behavior of the modeled domain. In this paper, we propose a formal method to represent structural as well as behavioral features of multi-scale architectures. We elaborate a set of refinement rules to build correct-by-design architectures. Features and rules are specified formally in Event-B specifications. We implement these specifications under the Rodin platform and we use the ProB theorem prover to prove specification consistency. In order to illustrate and validate our solution, we experiment our approach with a case study dedicated to the Smart Home System of Systems (SoS).

Full text

A refinement-based approach for specifying multi-scale
soware architectures: Application to SoS∗
Extended Abstract†
Ilhem Khlif
ReDCAD Research Laboratory
Sfax, Tunisia
ilhem.khlif@redcad.org
Imen Tounsi
ReDCAD Research Laboratory
Sfax, Tunisia
imen.tounsi@redcad.org
Mohamed Hadj Kacem
ReDCAD, ISIMS
Sfax, Tunisia
mohamed.hadjkacem@redcad.org
Cédric Eichler
LIFO
Centre Val de Loire, France
cedric.eichler@insa-cvl.fr
Ahmed Hadj Kacem
ReDCAD, FSEGS
Sfax, Tunisia
ahmed.hadjkacem@fsegs.rnu.tn
ABSTRACT
Specifying correct software-intensive Systems of Systems archi-
tectures is a challenging research direction requiring new model-
ing abstractions and techniques. For this purpose, we provide a
renement-based approach for multi-scale description of software
architectures. We dene an incremental process starting from a
coarse-grained description, and leading to a ne-grained descrip-
tion. The renement process involves both system-independent
structural features ensuring the model correctness, and specic fea-
tures related to the expected behavior of the modeled domain. In this
paper, we propose a formal method to represent structural as well
as behavioral features of multi-scale architectures. We elaborate
a set of renement rules to build correct-by-design architectures.
Features and rules are specied formally in Event-B specications.
We implement these specications under the Rodin platform and
we use the ProB theorem prover to prove specication consistency.
In order to illustrate and validate our solution, we experiment our
approach with a case study dedicated to the Smart Home System
of Systems (SoS).
CCS CONCEPTS
•Software and its engineering →Software design engineering;
KEYWORDS
Software Architectures, multi-scale description, formal method ,
Event-B specications, renement techniques, System of Systems
(SoS).
ACM Reference Format:
Ilhem Khlif, Imen Tounsi, Mohamed Hadj Kacem, Cédric Eichler, and Ahmed
Hadj Kacem. 2018. A renement-based approach for specifying multi-scale
∗Produces the permission block, and copyright information
†The full version of the author’s guide is available as acmart.pdf document
Permission to make digital or hard copies of part or all of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for third-party components of this work must be honored.
For all other uses, contact the owner/author(s).
SAC’18, April 9-13, 2018, Pau,France
©2018 Copyright held by the owner/author(s).
ACM ISBN 978-1-4503-5191-1/18/04.. .$15.00
https://doi.org/10.1145/3167132.3167309
software architectures: Application to SoS: Extended Abstract. In Proceedings
of ACM SAC Conference (SAC’18). ACM, New York, NY, USA, Article 4,
8 pages. https://doi.org/10.1145/3167132.3167309
1 INTRODUCTION
The design and development of software-intensive Systems Of Sys-
tems (SoSs) is a complex and challenging activity that requires
a careful and detailed analysis of all involved components and
their inter-relations. A formal approach to this activity can help
architects by increasing designers condence in the correctness
of the modeled system. Architecture descriptions provide the con-
ceptual abstraction for modeling software-intensive SoSs during
development. Our objective is to provide solutions for modeling
and specifying software architectures to facilitate their validation
at dierent description levels for Systems of Systems (SoSs). This
paper makes a contribution in this direction by proposing a for-
mal method which aims to help the architect designing correct
multi-scale architectures. In this work, we propose a formal method
in order to guarantee the correctness of the designed architec-
ture. In order to formalize the multi-scale characterization process
and to use it in the design process, we have chosen to follow a
renement-based approach that captures diverse perspectives of
the performance modeling of software-intensive SoSs. We dene a
renement process starting from a coarse-grained description and
leading to a ne-grained description to build correct-by-design soft-
ware architectures. Some high level properties can be expressed on
informal descriptions with a high level of abstractions and checked
on simple formal descriptions. Some other properties need more
detailed descriptions to be expressed and requiring the elaboration
of adequate formal specications. Our approach supports the veri-
cation of system properties through model checking, an automated
technique for formally verifying concurrent systems where the
validity of a system property is checked. We implement these spec-
ications under the Rodin platform and we use the ProB theorem
prover to automatically prove specication consistency. In order
to illustrate our solution, we experiment our approach with a case
study dedicated to the Smart home SoS. The remainder of the paper
is organized as follows. We describe the approach in Section 2. We
present the architecture specications in Section 3. We present the

SAC’18, April 9-13, 2018, Pau,France I. Khlif et al.
case study in Section 4. In Section 5, we present a survey of related
work. We conclude with some perspectives in Section 6.
2 APPROACH IN A NUTSHELL
We present a multi-scale description for modeling software-intensive
systems and particularly adequate for SoS. At the rst scale, the
system is described by a simple model that can be reduced to a
single component. This component is successively rened to reach
a ner grain description that contains all relevant details. The pro-
posed multi-scale approach relies on a two dimensional renement
process including both vertical and horizontal transformations. We
dene a vertical scale as a model that provides additional details of
design (decomposition details) that pertain to the abstract descrip-
tion. Under each vertical scale there are several horizontal scales
providing more communication details of a given current descrip-
tion. A core aspect of the proposed approach is its formality, to avoid
ambiguities that may be introduced by an informal description, and
expose the properties that are crucial to the success of the design
and development of software-intensive systems. Accordingly, we
provide a formal description of both the scales and the renement
rules to enable verication and guarantee of correctness. We use the
Event-B method to dene both structural and behavioral features
of software architectures. We implement a rule-based generator
that automatically translates UML-based architectural models into
Event-B specications. We use the Rodin theorem prover tool sup-
porting Event-B, and check the syntax and the correctness of the
generated specications. During changes, the system must be left
in a correct and coherent state. This concern is twofold. The rst
aspect is related to architectural style. The system must maintain its
conformity to the style and its intrinsic constraints. The last scale
allows us to determine the architectural style of the application
that can be for example
“Publish-Subscribe", “Client-Server", “SOA"
or another style. This paper addresses only a very specic style of
the architecture, the Publish-Subscribe style. It is an increasingly
commonly used architectural style for component-based systems.
The strength of this event-based interaction style lies in the full
decoupling between the two categories of components: the produc-
ers, and the consumers. This decoupling is realized by the event
service. In the context of this style, we guarantee the preservation
of the principle of information dissemination, which dictates that
produced information reaches all subscribed consumers. The sec-
ond aspect relates to multi-scale architecture and renement-based
approaches. Accordingly, we prove the consistency between the
scales through the proposed formal renement process.
3 SCALES FORMAL SPECIFICATIONS
The aim of formal modeling is to achieve a rigorous specication
of the intended structures and behaviors [
5
]. The advantage of
such specications is to determine whether a modeled structure
can successfully satisfy a set of given properties derived from the
user requirements. We tackle here the specication of multi-scale
architectures using Event-B, a renement-centric formal method
[
13
]. We use the Event-B method and its associate renement pro-
cesses and tools for the formal verication of the correctness of a
multi-scale architecture. An Event-B model is made of two types
of components: contexts and machines [
1
]. Machines and contexts
can be inter-related: a machine can be rened by another, and can
see one or several contexts, while a context can be extended by
another [
7
]. In a multi-scale architecture, each scale is specied by
both a structural and a behavioral description.
In what follows, we present a meta-model for multi-scale archi-
tectures especially for the Publish-Subscribe style (which will be
later instantiate in the example of an SoS) and which provides the
axioms and the “structure" for the description of a real Publish-
Subscribe system.
3.1 Structural features
Structural features are specied with one or several contexts. Each
context has a name and other clauses like “Constants", “Sets" to
declare a new data type, “Axioms" that denotes the type of the
constants and the various predicates which the constants obey,
“Extends" to extend another context and make use of all constants
and axioms declared in. In what follows, we present our renement
strategy.
3.1.1 Scale 0: global system. At the rst large scale of the model-
ing step, an abstract model is specied which is further rened in the
next scales to add more details. We specify the rst scale description
using an Event-B specication named Context0. In the Context0,
we specify the global system with a component as constants. The
component, that composes the architecture at this abstract scale, is
named System. This is specied by using a partition in the AXIOMS
clause named (C0_partition). In this initial model, we dene the car-
rier set Component of all components and we axiomatize that it is
nite. We dene a (function) constant “composition" that, together
with axioms, formalizes the transitive composition of binary rela-
tions between Components (Axm1). Then, we specify the forward
relational composition that is noted with “;" (Axm3). For example,
two components
A
and
B
can be in relation and if
B
and
C
are in
relation then the composition of r = {(A, B), (B, C)} is r
∪{(A,C)}
.
In fact, the relations between components are symmetric transitive
and composition is the transitive closure of these relations (Axm3,
Axm4). A component
A
and a component
B
communicate (poten-
tially indirectly) via the relation r, which implies that the pair (A,
B) is necessarily included in the composition (r). By ensuring this
property, we ensure the dissemination of data between these two
components.
CONTEXT
Co nt e xt 0
SETS
Com pon en t
CONSTANTS
Syst e m,com pos i ti on
AXIOMS
Application_partition :par t i t io n(C ompo ne nt ,
{Syst em } )
Axm0 :f in it e(Com pon en t )
Axm1 :com pos i ti on ∈ (C omp one nt ↔C omp on en t )
→(Comp one nt ↔C omp on en t )
Axm2 :∀r·r⊆comp os i ti on (r))
Axm3 :∀r·comp os i ti on (r);r⊆com pos i tion (r)
Axm4 :∀r,s·r⊆s∧s;r⊆s⇒comp os i ti on (r) ⊆ s
END
3.1.2 Scale 1: (sub-)components and relations. The renement
of the architecture continues until reaching all the levels of details
necessary to verify the associated architectural properties. Each
new iteration either renes components with new components or

A refinement-based approach for specifying multi-scale soware architectures: Application to SoS SAC’18, April 9-13, 2018, Pau,France
introduces connectors. A new context named Context1 extends the
Context0 and species the type of components constituting the
system. We dene two new kind of constants, a set of components
(
C1
,
C2
, .. ,
Cn
) as constants and the established link between them.
Formally, links are specied with an Event-B relation between
components (Association_part).
CONTEXT
Co nt e xt 1
EXTENDS
Co nt e xt 0
CONSTANTS
Com pon en t,C1,C2, .., Cn,
Ass oc ia t io n,Lin k1, . ., Li nk m
AXIOMS
Component_part :
par t i t io n(C ompo ne nt ,{C1},{C2}, . ., {Cn })
Association_part :
Ass oc ia t io n ∈Com pon en t ↔Com pon en t
Link_part :
par t i t io n(As so ci at i on,{Li nk 1}, . ., {L in km })
END
3.1.3 Scale 2: message-based communication. A Context2 is us-
ing the previous Context1, and is rening the architecture with
new sub-components and connections between them.
CONTEXT
Co nt e xt 2
EXTENDS
Co nt e xt 1
SETS
Me s sa дeT ype
CONSTANTS
Su bC ompo ne nt ,Co nsu me r,Eve nt S e rvi c e,
Pr o du ce r ,Con ne ct o r,P us hC _E S,
Pu sh E S_C,P us h P _ES ,Pu sh E S_P
Me s sa дe,ACK M e ss aдe,
Ca n_S en d,n
AXIOMS
axm1 :par t i t io n(C ompo ne nt ,Su bC omp one nt )
axm2 :par t i t io n(S ub Com pon en t,{C onsum er },
{Even tS e r vic e },{Pr oduc er })
axm3 :Co nne ct o r ∈Su bC ompo ne nt ↔S ub Com pon en t
axm4 :par t i t io n(C onn ec t or ,{Pu sh C_E S },
{Pu sh E S_C},{P us hP _E S },{Pus h ES _P})
axm5 :dom ({ Pu s hC _ES }) ={C onsu mer }
axm6 :r an( {P u shC _E S }) ={Event S e rvi ce }
axm7 :dom ({ Pu s hE S _C}) ={Event S e r vic e }
axm8 :r an( {P u sh ES _C}) ={C onsum er }
axm9 :r an( {P u sh P _ES } ) ={Pr odu ce r }
axm10 :dom ({ Pu s hE S _P}) ={P rod uce r }
axm11 :par t i t io n(M e ss aдeT yp e,{M e ss aдe},
{ACK M e ss aдe})
axm12 :Ca n_S en d ∈Com pon en t ↔Mes sa дeT yp e
axm13 :Ca n_S en d =Co nsu me r 7→ Me s sa дe,
Even tS e r vic e 7→ ACK M e ss aдe
axm14 :n=2
END
At this scale, components are possibly composed of new sub-
components named SubComponent (axm1). We specify the roles
of components (axm2) as producers, consumers or event service
using three constants: “Producer", “Consumer" and “EventService".
Formally, connectors between components are specied with an
Event-B relation between two components (axm3). Connector’s
name (PushC_ES, PushES_C, PushP_ES, PushES_P) are specied
with constants in the CONSTANTS clause. The set of connectors
is composed of all their names (axm4). Axioms 5 to 10 specify
sources and targets of each connector type. For example, PushC_ES
is the Connector and is establishing the communication link from
Consumer to the EventService. The Can_Send relation is specied
with (axm11). Components can exchange two types of messages; the
initially sent message (Message) and acknowledgement message
(ACKMessage), as specied by axioms (axm11, axm14). Type of
components are formally related to the kind of messages they can
send through the Can_Send relation (axm12, axm13).
3.2 Behavioral specications
Behavioral features are specied with one or several machines. A
machine has a name and consists of clauses such as “Renes" to
rene another one, “Sees" to use a context’s sets, constants and
axioms, “Variables" to initialize their values, “Invariants" that are
predicates that should be true for every reachable state, and “Events"
to assign new values to variables. The guards of an event specify
under which conditions it might occur. The initialization of the
machine is a special case of an event. An event leads to a state
change of the modeled system through a transition. It is either
parameterized and composed of clauses such as “Status" dening
the status of an event that can be ordinary, convergent (the event
must decrement the value of the variant), or anticipated (the event
must not increment the value of the variant), “Renes" declaring the
abstract event eventually rened by the event described, “Any" de-
scribing the names of the possible parameters of the event, “Where"
expressing the conditions for taking control of the event, “With" ex-
pressing cookies (predicates declared in the rened event to dene
the value of each variable and/or parameter of the abstract event
that disappears in the rened event). The witnesses are used in
proofs of proper event renement. In fact, rening event in Event-B
is a complex task since renement does not necessarily preserve
an event signature and, in particular, its input parameters. For an
abstract event E(a) to be rened in a concrete event E’(), we have
to prove that for each possible application of E’(), there exists
a
such as E’() and E(a) are equivalent. Proofs with existential quan-
tication are often hard to do, so Event-B uses the construct of a
“witness" as a predicate of the abstract parameter with the name of
the variable as label [
1
]. In the proposed approach, we specify the
abstract description scale with a machine at a high level of abstrac-
tion. Then, we add all necessary details to the rst machine through
renements. The description of the Event-B model is associated to
proof obligations ensuring the internal consistency of the model.
In the rst machine, we specify the system requirements by using
Context0. This is the beginning of traceability. In fact, each trace is
analyzed for consistency, completeness, and correctness to verify
that all system requirements are specied in the software and are
associated with the correct design.
3.2.1 Scale 1-1: Link suppression and addition. In the Machine0,
we formalize the behavior of the system, where links (represented
as pairs of components) may be created or removed at any time.
We specify two events (AddLink, RemoveLink) to insert or delete
a link between two components. There are direct one-way links
between certain pairs of distinct components. These links represent
the possibility of performing directed communication between two
components. The variable “AddedLinks" represents the set of links
that are currently created. The variable “RemovedLinks" represents
the set of links that have previously been inserted, but are now
deleted. These sets are disjoint (inv03) since a link cannot be both
created and removed. In fact, a link can be in “RemovedLinks" if
it is removed with “RemoveLink" and it was previously added to
Added-Links with “AddLink" (since no other events change the
state of “AddedLinks" and “Removed-Links") and was previously

SAC’18, April 9-13, 2018, Pau,France I. Khlif et al.
added. A link is only in AddedLinks
∪
Removed-Links if it is added
or was previously created.
MACHINE
Ma ch in e0
SEES
Co nt e xt 0
VARIABLES
Add ed Li nk s,R emo ved Li nk s
INVARIANTS
inv01 :Add ed Li nk s ∈C ompo ne nt ↔C omp one nt
inv02 :Removed L ink s ∈C omp one nt ↔C omp one nt
inv03 :Add ed Links ∩R em oved Li nk s =∅
EVENTS
INITIALISATION
BeginAct
ac t 01 : Add ed Li nk s :=∅
ac t 02 : Re move dL in ks :=∅
EndAct
EVT
Add Li nk :
ANYLi nk
WHERE дrd 1 : L ink <Ad d ed Li nk s
THEN ac t 01 : Add ed Li nk s :=Ad de d Lin ks ∪ { Li nk }
ac t 02 : Re move dL in ks :=R emo ved Li nk s \ {Li nk }
Remove Li nk :
ANYLi nk
WHERE дrd 2 : L ink ∈Ad d ed Li nk s
THEN ac t 03 : Add ed Li nk s :=Ad de d Lin ks \ { Li nk }
ac t 04 : Re move dL in ks :=R emo ved Li nk s ∪ {Li nk }
END
3.2.2 Scale 1-2: The first refinement: Update links information by
components . Machine1 is a renement of Machine0, using Con-
text1. We start by modeling the details of the system. This rst
renement is helpful to introduce the event for checking stable
states and add system events to model how components update
their link information. We state that each component stores infor-
mation about the links available. This information can be updated
when a link is established or removed. We introduce two variables
“addedlinks" and “removedlinks" that represent the current infor-
mation stored by each component about links states. The rst two
invariants formalize that each component stores its own local infor-
mation (a binary relation between Components about the status of
links). If a component has some information about a link, then this
link must currently be either added or removed. This is represented
by the invariants inv033 and inv044. The last invariant inv055 states
that a component can not store contradictory information about
the same link. We specify the “PreserveLink" event. This event
has no eect on the system state as its action is skip. Its guard is
used to dene the notion of a stable state of the system. The rst
two guards require that every component knows the correct status
of all its inward links, and has detected all architectural changes
aecting its links. The last guard requires that if there is a path
from a component m to n, then n has the same (added/removed)
information as m for all links to m.
MACHINE
Ma ch in e1
REFINES
Ma ch in e0
SEES
Co nt e xt 0
VARIABLES
add e dl i nk s,r em oved l inks
INVARIANTS
inv011 :
add e dl i nk s ∈Com ponen t → (Com pon en t ↔Com po ne nt )
inv022 :
r emove d li nk s ∈C ompo ne nt → (Co mpo ne nt ↔C ompo ne nt )
inv033 :
∀n.add e dl i nk s(n) ⊆ Add edL ink s ∪R emo ved Li nk s
inv044 :
∀n.re move d li nk s (n) ⊆ Ad de d Lin ks ∪R em oved Li nk s
inv055 :
∀n.re move d li nk s (n) ∪ add e dl i nk s(n)=∅
EVENTS
INITIALISATION
BeginAct
ac t 011 : ad de dl i nk s :=∅
ac t 022 : r emo ved l in ks :=∅
EndAct
EVT
add l in k :
ANYn,li nk
WHERE
дrd 11 : n∈C omp onent
дrd 12 : l i nk ∈Ad de d Li nk s ∪Rem oved Li nk s
THEN
ac t 021 : ad de d Lin ks (n):=ad d ed Li nk s (n) ∪ {l ink }
ac t 023 : r emo ved l in ks (n):=r em oved l in ks (n) \ {l ink }
r emove l in k :
ANYn,li nk
WHERE
дrd 11 : n∈C omp onent
дrd 12 : l i nk ∈Ad de d Li nk s ∪Rem oved Li nk s
THEN
ac t 021 : r emo ved Li nk s (n):=re move d Li nk s(n) \ { link }
ac t 023 : r emo ved l in ks (n):=r em oved l in ks (n) ∪ {l ink }
Pr e s er ve Li nk :
statusor di na ry
WHERE
дrd 11 : ∀x,y.x7→ y∈Ad de d Li nk s ⇔x7→ y∈add e dl i nk s(y)
дrd 12 : ∀x,y.x7→ y∈R emo ved Li nk s ⇔
x7→ y∈r emove d li nk s (y)
дrd 13 : ∀n,n.m7→ n∈c omp os it i on(Ad d ed Li nk s) ⇒
∀k.k7→ m∈add e dl i nk s(n⇔k7→ m∈add ed l in ks (m))∧
k7→ m∈r emove d li nk s (n) ⇔ k7→ m∈r em oved l in ks (m)))
END
3.2.3 Scale 2: Message based communication. We will now spec-
ify communication messages occurring in these links. A second
machine named Machine2 which renes Machine1, using Con-
text2 and adding communication between the sub-components is
illustrated. Before modeling communication, we rst model how
components track which information is updated (whether the link
information received is new or not). In order to track updated link-
state information, we introduce the sequence number stored at each
component for each link. This is specied with a new variable called
sequenceNumber
∈
Component
→
(Component
∗
Component
∈
N). We introduce a variable Message that measures the occurrence
of the two events (Sending_Message, Sending_ACK). This variable
will not be used in the guards of the event, that is, it will not af-
fect the execution of the events, hence we can safely remove this
variable in the subsequent renement. The invariants (Send, dispo)
are specied in the INVARIANTS clause to check that each sub-
component sends a message or receives an acknowledgment only
if it is authorised (inv2). The behavior is specied as follows: the
producer sends a Message to the consumer. When the consumer
becomes available, it receives the Message, processes it and sends
the Ack-Message. When the producer becomes available, it receives

A refinement-based approach for specifying multi-scale soware architectures: Application to SoS SAC’18, April 9-13, 2018, Pau,France
the ACK-Message. The invariant (inv1) species what is the sent
message, who is the sender and the receiver.
MACHINE
Ma ch in e2
REFINES
Ma ch in e1
SEES
Co nt e xt 2
VARIABLES
Se nd ,Di sp o,se q N um
INVARIANTS
inv0 :se qu en ce N u mb er ∈Com ponen t
−→ (Comp one nt ∗C omp one nt ∈N)
inv1 :Se nd ∈C onn ec t or ↔M e ss aдe T ype
inv2 :Di sp o ∈Su bC omp one nt 7→ BO O L
Can_Send_INV :
z,x,yz∈Compon en t ∧x7→ y∈Co nne ct or ↔
Me s sa дeT ype ↔M e ss aдe T ype ∧d om(x)=z∧ (x7→ y)
∈Se nd ⇒ (z7→ y) ∈ Ca n_S en d
EVENTS
INITIALISATION
BeginAct
ac t 1 : Se nd :=∅
ac t 2 : Di sp o :={Co nsume r 7→ T RU E ,
Even tS e r vic e 7→ F ALS E }
EndAct
EVT
Se nd in д_Me s sa дe
WHERE
дrd 1 : C on sum er ∈d om (Di sp o)
∧Di sp o(Co ns ume r )=T RU E
дrd 2 : S e nd =∅
THEN ac t 1 : Se nd :=S e nd ∪P us hC _ES 7→ M e ss aдe
Se nd in д_ACK
WHERE
дrd 1 : Eve nt S e rvi c e ∈dom (Di s po)
∧Di sp o(Eve nt S er vi ce )=T RU E
дrd 2 : (P us hC _E S 7→ Me s sa дe) ∈ S en d
дrd 3 : (P us h ES _C7→ ACK M e ss aдe∈S e nd
THEN
ac t 1 : Se nd ∈S e nd ∪P us hE S _C7→ ACK M es s aдe
END
3.3 Checking properties using proofs
obligations
Mathematical proofs allow to verify model consistency and con-
sistency between renement levels. Theorem proving technique
allows to check properties which can be experimented either as
predicates (INVARIANTS, AXIOMS, THEOREMS) or with guards
in the events, or also ensured by proof obligations. We implement
the Event-B specications under the Rodin platform and we use the
ProB theorem prover to prove specication consistency. In particu-
lar, we check behavioral properties like liveness and reachability.
The reachability means that the components are able to capture
all exchanged messages. We formulate those properties as pred-
icates (INVARIANTS, AXIOMS). We check that each component
only sends a message if it is authorised. This is controlled by the
invariants (Send, Dispo). Besides, dierent properties of correctness
have to be maintained between the models at the dierent levels
of iterations. The decoupling property states that producers and
consumers do not communicate directly, but their interactions have
to be mediated by the event service. Then, the produced informa-
tion must reach all the subscribed consumers. This is to ensure the
principle of information dissemination. Let MessageType be the
produced information, represented as a message with a type. For all
producers in the system, there is one consumer that must receive
the sent message. We formulate this property as predicates in the
Context2 that are noted (axm11,axm12). We check that each com-
ponent only sends a message if it is authorised. This is controlled
by the invariants (Can_Send_Inv) in the Machine2. Reaching the
last scale description by using renement techniques, we guaran-
tee that rened models are not contradictory and we ensure that
they are correct-by-design. The multi-scale modeling helps to au-
tomate the construction of correct architectures. The renement
techniques proposed by this method allow to represent architec-
tures at dierent abstraction levels and are implemented using the
Rodin platform.
4 APPLICATION TO SOS: THE SMART HOME
CASE STUDY
This section focuses on modeling the smart home SoS for the home-
care monitoring of elderly and disabled persons.
4.1 System of Systems: Motivation
At design level, an SoS is the composition of components (con-
stituent system), themselves systems, that are large scale and inde-
pendent, separately discovered, selected and composed to form a
more complex system. This composition forms a larger system that
performs a mission not possible by one of the constituent systems
alone, i.e., it creates an emergent behavior [11].
4.1.1 SoS defining features. A set of characteristics presented
by SoSs distinguish them from complex systems. The intrinsic
characteristics of an SoS are proposed by Maier [
10
]:
Operational
Independence:
The constituent systems operate independently of
each other, each having its own mission.
Managerial Independence:
The constituents of an SoS are separately integrated but managed
their own resources independently.
Evolutionary Development:
As
a consequence of the independence of the constituent systems, an
SoS as a whole may evolve over time to respond to changing char-
acteristics of its surrounding environment, constituent systems or
of its own mission.
Emergent Behavior:
The SoS is capable to deliver
new functions that are obtained from the composition of its con-
stituents rather than from a singular constituent. These behaviors
are emergent properties of the SoS and cannot be localized to any
constituent system.
Geographic Distribution:
the constituent sys-
tems are physically decoupled and may be widely geographically
distributed in such a way the interaction between them is limited
to information exchange.
4.1.2 Classification of SoSs. Based on these characteristics, SoSs
can be classied as: directed, collaborative, virtual, and acknowl-
edged.
Directed SoS
is a set of centrally managed systems that have
been developed to t specic purposes in the SoS, as they operate
under tight subordination [
10
].
Collaborative SoS
in which there is
no central management and constituent systems voluntarily agree
to fulll central purposes. They are distinct from directed SoS in
the inability of the central management to run the system [
10
].
Virtual SoS
lacks a central management authority and an agreed
purpose for the SoS. Indeed, large scale behavior emerges, and may
be desirable, but the SoS must rely upon relatively invisible mecha-
nisms to maintain it [
10
]. Finally,
acknowledged SoS
in which there
are recognized objectives, a designated manager, and changes in
the systems are agreed on collaboration between the SoS and the
systems [12].
4.1.3 Case study: an acknowledged SoS. In order to show the vi-
ability and usefulness of our solution, we experiment our approach

SAC’18, April 9-13, 2018, Pau,France I. Khlif et al.
to deal with the case study dedicated to the smart home system.
We specify the essential information architecture and we illustrate,
the constituent elements of the smart home system [
3
]. The con-
Smart
Phone
Tablet
PC
Fall
SensorPresence
Sensor
Humidity
Sensor
Air Conditionner
Video
Camera
Microphone
Convector
Blood
Pressure
Sensor Oximeter
Pulse
WeightScale
sensor
Temperature
Sensor
Doctor Nurse
HomeCare Actor
Medical Surveillance
Center
Environment Control &
Comfort Management
Monitoring CenterEquipement
Wifi
Device
Physiological Sensor Medical
Assistant
Emergency
Service
Emergency Surveillance
Center
Eldery
Person
Relatives
User
Activity Sensor
Environment Sensor
Figure 1: Smart Home SoS [9]
stituent elements of the smart home application are: the monitoring
center is composed of three systems: the Environment Control and
Comfort Management, the Emergency Surveillance Center, and
the Medical Surveillance Center. The Home Care Actor interacts
with the monitoring center, by setting medical or emergency con-
ditions; the Equipment includes sensors and house devices; the
emergency surveillance center controls critical situations using
the activity sensors. Activity sensors include fall sensors, presence
sensors, video camera and microphone. The medical surveillance
center monitors physiological sensors. While there are problems,
the center requires the medical assistant intervention (the doctor,
the nurse). The comfort management and the environment control
system guarantees a comfort life for the users. This center enables
communications between users, control the environment sensors
(Humidity and Temperature Sensors), and commands the house
devices (Convectors, Air conditioners).
The smart home system is an acknowledged SoS as it is cen-
trally managed and operate under loose subordination, and the con-
stituents retain their operational independence. This SoS presents
the following ve characteristics:
Operational independence:
The
smart home for the homecare monitoring can use information pro-
vided by a monitoring system but will operate normally its mission
even if this information is not available.
Managerial independence:
Independent managerial areas with own action strategies for SoS
(patient safety, comfort life).
Evolutionary development:
The SoS
evolves to accommodate changes in smart home environment, for
instance when patient health condition evolves.
Emergent behavior:
Detecting an emergency critical situation and immediately reacting
is an emergent functionality provided by the cooperative work of
the monitoring center, the equipment (in particular the smart sen-
sors), and the emergency dispatch center.
Geographic distribution:
The smart home constituent systems are largely distributed in the
house area. The main issue is to ensure ecient management of
the optimized comfort, and the safety of the elderly and disabled
person at home.
4.2 Event-B specications of the smart home
SoS
The multi-scale approach contributes to the understanding of the
SoS as a simple composition of individual systems. Models and
techniques presented in the previous section are instanced and
applied to the Smart Home SoS.
CONTEXT
Co nt e xt 2
EXTENDS
Co nt e xt 1
CONSTANTS
Act S en so r,D evi c e,En vSe ns or ,P hysS e ns or ,
Eme r Su r vCe nt e r,E nvC ont r ol ,M ed Sur vCe nt e r ,
U se r,M ed As si s t ant ,Em er S er vi ce
AXIOMS
Equipement_partition :
par t i t io n(E qui peme nt ,{Act Se nsor },{D evi ce },
{EnvS ens or },{Phys Sen sor })
Management_partition :
par t i t io n(M on it o r inдC e nt e r,{E mer S u rvC e nt er
{EnvC ont rol },{M edS ur Cen ter } )
HomeCareActor_partition :
par t i t io n(H om eC ar e Ac to r,{E me r Se r vic e },{U ser },
{Me dAs sis ta nt })
Connector-partition :
par t i t io n(C onn ec t or ,{Pu sh H CA_M C },
{Pu sh M C_H C A }, .. . )
Message-partition :
par t i t io n(M e ss aдeT yp e,{S e nd Ale r t },
{Se ndAC K })
Can-Send :
Ca n_S en d =H ome Ca r eAc t or 7→ S en dAl e r t,
Mo ni to r i nдCe nt e r 7→ S en dAC K
END
In the Context0, we have one Component dedicated to the SoS
named: SmartHome. In the Context1, we specify only three Com-
ponent that are the SoS constituent elements: Equipment, Home-
CareActor and MonitoringCenter. We specify in the Context2, the
sub-components as constants and are grouped within three sub-
sets (Equipment-partition, Management-partition, HomeCareActor-
partition). We did not present all details. We dene the MessageType
set, two constants SendAlert and SendACK and then the message
partition. To specify behavioral features, we have two steps. First,
we specify the rst machine at a high level of abstraction where the
Smart Home SoS requirements are specied. A Machine1 specify
three type of components (Equipment, MonitoringCenter, Home-
CareActor) and links between them. We illustrate an example of
machines called Machine1 that is rening the Machine0, adding
connectors between the Smart Home components. The behavior
is specied as follows: the Equipment starts the behavior by send-
ing an alert message to the MonitoringCenter. This one responds
by an acknowledgment message to the equipment. The monitor-
ing center sends the information to the HomeCareActor that will
respond immediately and send return message describing the situa-
tion after the care. The invariants (Send_Alert, Send_Ack) species
what is the sent message, who is the sender and the receiver (The
same description for the message from the MonitoringCenter to
the HomeCareActor).

A refinement-based approach for specifying multi-scale soware architectures: Application to SoS SAC’18, April 9-13, 2018, Pau,France
MACHINE
Ma ch in e1
REFINES
Ma ch in e0
SEES
Co nt e xt 1
EVENTS
INITIALISATION
EVT
Se nd in д_Ale r t
WHERE
дrd 1 : H om eC ar e Ac to r ∈d om (Di sp o)
∧Di sp o(H om eC ar e Act o r )=T RU E
дrd 2 : S e nd =∅
THEN
ac t 1 : Se nd :=S e nd ∪P us hH C A_MC 7→ S e nd Ale r t
Se nd in д_ACK
WHERE
дrd 1 : H om eC ar e Ac to r ∈d om (Di sp o)
∧Di sp o(H om eC ar e Act o r )=T RU E
дrd 2 : (P us h HC A_M C 7→ Se nd Al e r t ) ∈ S e nd
дrd 3 : (P us h MC _H CA 7→ S e nd ACK ∈S e nd
THEN ac t 1 : Se nd AC K ∈Se nd ∪
Pu sh S MC _H CA 7→ Se nd ACK
END
4.3 Verication
During the renement process, we check the correct transmission
of messages between actors and we prove the correctness property
using the Event-B specications. This is to guarantee a correct by
construction multi-scale architectures. We implement our multi-
scale approach using the Event-B method and we check the local
properties using the proof obligations generated automatically by
Rodin. These are generally obligations of preserving invariants or
theorem proving (in the invariant part of the machine). These the-
orems can be used to prove the deadlock freedom of the machine
in a particular state. Event-B now spurs the Rodin platform, which
is based on Eclipse and can be extended via plug-ins. In this paper,
model checking in the proposed approach relies in particular on a
plug-in for animation and a plug-in for interactive proof support,
called a disprover. Both plug-ins are based on the ProB tool as well
as a translation of Event-B to classical B. In Figure 2, we start the
animation by adding components and links. In order to verify the
feasibility of the case study, we create a the contexts and machines
representing the Smart Home SoS at dierent scales. Then, we ap-
ply the rule for adding links between its components and we check
the correctness of the system. Model checking and animation are
two techniques used to show the dynamic behavior of a model and
they allow to systematically explore all its reachable states. We use
the model checker ProB to check the correct behavior of the system.
Some behavioral properties are veried like liveness (no deadlocks
present in the model) and information dissemination (prove that
each produced information will be necessarily consumed) proper-
ties.
5 RELATED WORK
Considerable research studies have been proposed on the descrip-
tion of software architectures. A multi-scale description is intro-
duced [
6
] to specify behaviours and properties of the system across
multiple scales in order understanding without ambiguity the sys-
tem and mastering the description details.
Some research studies have been presented on modeling soft-
ware architectures for SoSs. An adequate representation of SoS
software architectures is crucial for the success of such systems.
In [
16
], Mordecai and Dori developed a design approach to model
Figure 2: Screenshot of unloaded proof obligations and dead-
lock freedom checked property
interfaces and interactions among SoS constituents. They proposed
a framework for SoS integration, to facilitate the transition from
the constituent systems’ view to a consolidated integrated model.
Bryans et al., in [
4
], presented a model-based approach to assist
in the integration of new or modied constituent systems into an
SoS. The authors dened two levels for SoS composition, the high-
level structural view that considers the connections within the SoS,
and the low-level behavioral view that deals with the behavior of
contractual specications. They treated an industrial case study for
modeling Audio/Video SoS. In [
8
], we have proposed a multi-scale
modeling perspective for Systems of Systems (SoS) architecture
description. The proposed design approach is founded on SysML
(System modeling language) notations and uses block diagrams. The
diagrams are subject to vertical and horizontal transformations for
renement, since reaching a ne-grain description. The multi-scale
modeling solution has only considered a xed number of scales and
describes the renement from a generic model describing a given
point of view at a given scale to a specic model describing this
point of view at another scale. We have adopted SySML notations
for multi-scale architectures. We experimented our approach by
a case study modeling an Integrated Air Defense (IAD) SoS using
SysML models.
Other research studies have been proposed for the specication
of software systems using formal methods. Model verication ac-
tivity [
15
] is performed to ensure the correctness of model. Formal
verication means that any errors found in the design of the sys-
tem should be corrected. Tounsi et al. [
14
] proposed an approach
for modeling and formalizing message-oriented SOA design pat-
terns. First, the authors are modeling SOA design patterns with a

SAC’18, April 9-13, 2018, Pau,France I. Khlif et al.
semi-formal language based on Service oriented architecture Mod-
eling Language (SoaML-based). Second, they proposed a generic
formalisation of these patterns using the Event-B method. This
step is enhanced with the automatic transformation of SoaML pat-
tern diagrams to Event-B pattern specications with respect to
transformation rules. Finally, they used the Rodin theorem prover
tool supporting Event-B, they check the syntax of the generated
Event-B SOA design pattern models as well as their correctness
(i.e., no deadlocks...). Ben Younes et al. [
2
] proposed a meta-model
transformation between UML Activity Diagram and Event B mod-
els. A formal framework is dened to ensure the correctness of the
proposed transformations, and the event B method is used for the
formal verication of applications.
We can note that the previous research activities deal only with
structural features during the design of the architecture. They do
not take into account the respect of behavioral features to validate
the architecture. Whereas, in our work, we deal with both structural
and behavioral features.
Although there are a number of limitations associated with this
work the contribution presented here hold signicant implications
for architects. In particular, the contribution of this study presents
some important implications for the development of design ap-
proach to validate software architectures at dierent description
scales through the renement techniques using a formal method
and to check the correctness properties related to the expected
behavior of the modeled system.
6 CONCLUSION
In this paper, we presented a formal renement-based design ap-
proach supporting the specication of multi-scale software archi-
tectures and particularly adequate for SoS. We formally specied
both structural and behavioral features of these architectures using
the Event-B method. We implemented the elaborated specications
under the Rodin platform and we proved specication consistency
using the ProB theorem prover. We showed the viability and useful-
ness of our solution through the design of the smart home system of
systems. The applicability of our approach is demonstrated through
this case study. In our future work, we expect to leverage the in-
herent appropriateness of multi-scale modeling for other SoSs (e.g.
The Integrated Air Defense System). We intend to extend formal
verication to predict emergent properties and behaviors using
multi-scale SoS architectures descriptions.
REFERENCES
[1]
Jean-Raymond Abrial. 2010. Modeling in Event-B: System and Software Engineering
(1st ed.). Cambridge University Press, New York, NY, USA.
[2] A. Ben Younes, Y.B. Hlaoui, and L. Jemni Ben Ayed. 2014. A Meta-model Trans-
formation from UML Activity Diagrams to Event-B Models. In Computer Software
and Applications Conference Workshops (COMPSACW), 2014 IEEE 38th Interna-
tional. 740–745.
[3]
S. Bonhomme, E. Campo, D. Esteve, and J. Guennec. 2008. Methodology and
tools for the design and verication of a smart management system for home
comfort. In Intelligent Systems, 2008. IS ’08. 4th International IEEE Conference,
Vol. 3. 24–2–24–7.
[4]
J. Bryans, J. Fitzgerald, R. Payne, A. Miyazawa, and K. Kristensen. 2014. SysML
contracts for systems of systems. In System of Systems Engineering (SOSE), 2014
9th International Conference on. 73–78.
[5]
Carlos Canal, Ernesto Pimentel, and JosÃľ M. Troya. 2001. Compatibility and
inheritance in software architectures. Science of Computer Programming 41, 2
(2001), 105 – 138. https://doi.org/10.1016/S0167- 6423(01)00002-8
[6]
Philip Cash, Ben Hicks, and Steve Culley. 2015. Activity Theory as a means for
multi-scale analysis of the engineering design process: A protocol study of design
in practice. Design Studies 38 (2015), 1 – 32. https://doi.org/10.1016/j.destud.2015.
02.001
[7]
Thai Son Hoang, Hironobu Kuruma, David Basin, and Jean-Raymond Abrial. 2009.
Integrated Formal Methods: 7th International Conference, IFM 2009, Düsseldorf,
Germany, February 16-19, 2009. Proceedings. Springer Berlin Heidelberg, Berlin,
Heidelberg, Chapter Developing Topology Discovery in Event-B, 1–19.
[8]
Ilhem Khlif, Mohamed Hadj Kacem, Ahmed Hadj Kacem, and Khalil Drira. 2014.
A Multi-scale Modelling Perspective for SoS Architectures. In Proceedings of
the 2014 European Conference on Software Architecture Workshops (ECSAW14).
30:1–30:5.
[9]
Ilhem Khlif, Mohamed Hadj Kacem, Ahmed Hadj Kacem, and Khalil Drira. 2016.
Software architectures: Multi-scale renement. In the 14th International Confer-
ence on Software Engineering Research, Management and Applications (SERA2016).
[10]
Mark Maier. 1998. Architecting principles for systems-of-systems. Systems
Engineering 1, 4 (1998), 267–284.
[11]
Elisa Yumi Nakagawa, Marcelo Gonçalves, Milena Guessi, Lucas B. R. Oliveira,
and Flávio Oquendo. 2013. The state of the art and future perspectives in systems
of systems software architectures. In SESoS. 13–20.
[12]
ODUSD. 2008. DoD. System Engineering Guide for Systems of Systems. Technical
Report. Oce of the Deputy Under Secretary of Defense for Acquisition and
Technology.
[13]
Wen Su, Jean-Raymond Abrial, and Huibiao Zhu. 2014. Formalizing hybrid
systems with Event-B and the Rodin Platform. Sci. Comput. Program. 94 (2014),
164–202.
[14]
Imen Tounsi, Mohamed Hadj Kacem, Ahmed Hadj Kacem, and Khalil Drira. 2015.
A renement-based approach for building valid SOA design patterns. IJCC 4, 1
(2015), 78–104.
[15]
B.N. Uchevler and K. Svarstad. 2013. Assertion based verication using PSL-like
properties in Haskell. In Design and Diagnostics of Electronic Circuits Systems
(DDECS), 2013 IEEE 16th International Symposium on. 254–257.
[16]
Mordecai Yaniv and Dori Dov. 2013. 6.5.1 I5: A Model-Based Framework for
Architecting System-of-Systems Interoperability, Interconnectivity, Interfacing,
Integration, and Interaction. INCOSE International Symposium 23, 1 (2013), 1234–
1255.