Modeling Requirements Should be Language Agnostic!
Example of a Formal Definition of Simple Behavioral Decomposition Models
Gurvan Le Guernic
DGA Ma
ˆ
ıtrise de l’Information, 35998 Rennes Cedex 9, France
Keywords:
Modeling Language, Domain Specific, Modeling Requirements, Model Validation, Formal Definition.
Abstract:
This paper argues in favor of expressing modeling requirements in a modeling language agnostic way, at
least whenever those requirements are part of a contracting relationship between some of the stakeholders.
Contracting authorities may require from contractors specific design models in order to perform early design
(functional, safety, security, etc.) analyses. However, in order to allow contractors to use the compatible mod-
eling language of their choice with the compatible modeling guidelines of their choice, the formal definition of
the model requirements must be independent from any concrete modeling language or guideline. This paper
introduces, based on the example of Behavioral Decomposition Models, an approach to express such agnostic
requirements. This is achieved by defining a semantic domain, some correctness constraints and, later, the
necessary mappings between them and the desired concrete syntaxes.
1 INTRODUCTION
The DGA (Direction G
´
en
´
erale de l’Armement) is the
French military procurement agency. As such, it
buys off-the-shelf products, but also emits requests
for proposals (or tenders) regarding the development
of specific products. With regard to specific prod-
ucts, the DGA MI (DGA Ma
ˆ
ıtrise de l’Information)
is involved, among other things, with products built
to secure information systems. Those products often
require the development of specific hardware, have
to satisfy strong non-functional requirements, and
have to pass strict national or international evalua-
tion processes before being deployed. Due to those
aspects, their development does not fit well with ag-
ile processes (Cockburn, 2007), and usually follows
an overall Vee model of development (Forsberg and
Mooz, 1998; INCOSE, 2015). However, the develop-
ment process implemented by contractors in interac-
tion with the DGA still follows one of the pillars of
agile development and IBM’s Continuous Engineer-
ing (Shamieh, 2014): early feedback. The DGA is an
active contracting authority which has accumulated
knowledge on how to build a product that satisfies
the strong non-functional requirements desired, and
on the standards a product needs to meet in order to
pass the strict national or international evaluation pro-
cesses. Near the end of the development process and
as could be expected, the DGA performs evaluation
of the first versions of the product in order to advise
the prime contractor on modifications to perform in
order to meet DGA’s requirements and the standards
of the national or international evaluation processes.
In addition, in the early phases of the development
process, the DGA requires the prime contractor to de-
liver design documentation. Those documents are an-
alyzed by the DGA in order to spot, as early as pos-
sible, bad design decisions which would prevent the
proposed system from meeting certain requirements
(either from the DGA or from the evaluation authori-
ties).
As it is well known, natural language textual doc-
uments suffer from incoherences, ambiguities or in-
completeness. In order to improve the quality of its
design analyses, the DGA is moving towards a pro-
cess where some of the design documentation is re-
quired to include (semi-)formal models. In order to
maximize the benefits of using models, those mod-
els are required to follow strict constraints. Without
such constraints (and even with them but to a lesser
degree), it is still possible to produce an incomplete
model full of incoherences and ambiguities. More-
over, those constraints ensure that the analysis team
is able to easily identify the information it needs to
perform its analyses. In addition, those constraints
are also used as “smoke and sanity tests” (Mcconnell,
1996; ISTQB Glossary Working Group, 2015) before
accepting the design documentations in order to en-
sure a minimal quality of the models and therefore
an efficient use of the time and effort of the DGA’s
design analysis teams. However, those constraints
should minimize the burden they impose on the con-
Guernic, G.
Modeling Requirements Should be Language Agnostic! - Example of a Formal Definition of Simple Behavioral Decomposition Models.
DOI: 10.5220/0005795205550562
In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 555-562
ISBN: 978-989-758-168-7
Copyright
c
 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
555

tractors. Ideally, they should not prevent contractors
from applying the development processes and tools
they are used to. In particular, if a contractor is al-
ready using a particular type of modeling language
supported by some specific tools, he should still be
able to use those while providing to the DGA the
models it needs.
One of DGA’s early design analyses is focused
on the specification of high level interleavings of
environment solicitations and product reactions (un-
der the form of messages emitted or operations per-
formed). The goal is mainly to verify that user scenar-
ios (Alexander and Maiden, 2004) are allowed by the
current specification. For example, for a generic OS,
user scenarios may request that it is possible to switch
off a computer without logging in if no user is cur-
rently logged in (or potentially the reverse for a device
with high availability requirements); other scenarios
may request that a given operation is always possi-
ble. Pushing this analysis further, it is also verified
that the first level of product decomposition into com-
ponents allows the black box behaviors specified (for
example, verifying that interactions between compo-
nent behaviors can not deadlock the whole product).
In order to perform those analyses a so called Be-
havioral Decomposition Model (BDM) is requested.
BDMs are formally defined by a set of modeling re-
quirements. Those modeling requirements are similar
to well-formedness constraints (Kolovos et al., 2009);
however, they are expressed independently from the
concrete modeling language used, which is not usu-
ally the case for well-formedness constraints.
This paper does not focus on BDMs, but on an
example of how such an agnostic
1
model definition
can be formalized. This paper presents in Sect. 2
a running example before introducing in Sect. 3 the
proposed approach to formally define modeling re-
quirements independently from the specific modeling
language which will be used to concretely model the
product or system. Section 4 presents an application
of this approach on the example of a simplified for-
mal definition of BDM. And possible exploitations
of those formal agnostic definitions are proposed in
Sect. 5 before concluding.
2 RUNNING EXAMPLE
The running example used in this paper is a simplified
network pump (Moore, 2000), called NP and based on
the American “Pump” architecture (Kang et al., 2005)
roughly described in Fig. 1.
1
“independent of any concrete modeling language”
High Microprocessor
High LAN
Administrator
interface
Dual Port
RAM
Low Microprocessor
Low LAN
Power
interface
Figure 1: Simplified architecture of the “Pump” (Kang
et al., 2005)
In order to save space and simplify the running
example to the minimum required for this paper, NP’s
structural architecture is simplified to two organs
2
: a
high part and a low part. The power interface is con-
nected to both parts and its behavior is simplified to
only receiving information about the state of the main
power and battery. NP’s behavior is reduced to: for-
warding on the high LAN interface every packet re-
ceived on the low LAN interface; and providing a log
file on the administrator interface if requested on the
same interface.
Fig. 2 provides some diagrams of a SysML
(OMG, 2012b) model of the running example. Those
are only “views” on the underlying SysML model.
Indeed, diagrams are not part of the SysML meta-
model. And, for example, the environment state ma-
chine diagram has been produced with a tool (Pa-
pyrus (G
´
erard et al., 2010; The Eclipse Foundation,
2015)) which, near a transition, displays its name, and
not a label constructed from the trigger, guard and
effect of the transition. It is the naming convention
of those transitions that ensures that a transition label
reflects information on its trigger, guard and effect.
However, even if Papyrus does not follow strictly the
graphical representation of SysML diagrams, the un-
derlying (abstract syntax) SysML model produced by
Papyrus still respects the SysML meta-model. And
transitions in this underlying SysML model do have
trigger, guard and effect, if needed. The agnostic re-
quirements defining BDMs have to be checked on the
(abstract syntax) underlying model, and not on the
graphical (concrete syntax) diagrams.
2
In this paper, the word “organ” is used with the fol-
lowing definition: “a subordinate group or organization that
performs specialized functions” (Merriam-Webster)
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
556

bdd [model] NetworkPump [Black Box View]
stm [stateMachine] Environment [Solicitations]
Off
packet on Low LAN /
get-log /
StandBy
packet on Low LAN /
get-log / getLog()
On
battery-on / battery = True
battery-off / battery = False
packet on Low LAN / transferPacket()
get-log / getLog()
/ battery = False
main-on
battery-on / battery = True
battery-off / battery = False
main-on
main-off
[battery = False]
main-off
[battery = True]
stm [stateMachine] NetworkPump [Reactions to Solicitations]
ibd [block] Network Pump [Decomposition]
act [activity] PT [Dec.]
Off
battery-on /
battery-off /
packet on Low LAN /
On
battery-on /
battery-off /
packet on Low LAN / receivePacket()
main-on
main-off
stm [stateMachine] LowPart [Reactions to Solicitations]
Off
packet on Low IC /
get-log /
StandBy
packet on Low IC /
get-log / getLog()
On
battery-on / battery = True
battery-off / battery = False
packet on Low IC / sendPacket()
get-log / getLog()
/ battery = False
main-on
battery-on / battery = True
battery-off / battery = False
main-on
main-off
[battery = False]
main-off
[battery = True]
stm [stateMachine] HighPart [Reactions to Solicitations]
Figure 2: Diagrams of the Network Pump’s SysML Model.
Modeling Requirements Should be Language Agnostic! - Example of a Formal Definition of Simple Behavioral Decomposition Models
557

3 AGNOSTIC MODELING
REQUIREMENTS
An obvious approach, to define requirements on mod-
els fit for a special purpose, is to choose a mod-
eling language as generic and standard as possible,
SysML (OMG, 2012b) or B (Abrial, 2010) for ex-
ample, and express constraints in a compatible lan-
guage, potentially in OCL (OMG, 2012a) or B itself
in the previous examples. In order to cover as much
use cases as possible, those general purpose model-
ing languages (GPMLs) often provide different means
to express similar concepts, each one adapted to a
particular aspect with its own subtleties. For exam-
ple SysML allows to express behaviors using state
machines, activity diagrams or sequence diagrams.
However, this large expressiveness of GPMLs comes
with an increased complexity of their abstract syntax
structure and semantics. This increased complexity
makes it more difficult to formally define modeling
requirements directly on the abstract syntax and se-
mantics of those GPMLs. Indeed, high level proper-
ties can often be expressed using different “means” of
GPMLs. For example, possible operation interleav-
ings can be expressed using state machines, activity
diagrams or sequence diagrams. And the expression
of modeling requirements have to take into considera-
tion all those means with all their subtle and complex
constructions. Moreover, this approach does not sat-
isfy the DGA’s need for the definition to be flexible
regarding the concrete modeling language used in or-
der to let contractors choose (in agreement with the
DGA) the modeling language they prefer, as long as
it can carry the information needed. Similarly, when
requiring models fit for a special purpose, another ap-
proach commonly used is to design a new Domain
Specific Modeling Language (DSML) (Luoma et al.,
2004). However, with this approach, the modeling
language is fixed once again; and the contractors have
to use this DSML to design their product or translate
their design models into this DSML.
Even if the approach proposed in this paper may
seem similar in practice to the design of a DSML, the
goal in this paper is not to design a new DSML, but to
constrain and formalize the use of GPMLs for a spe-
cific purpose. An analogy can be made with the use
of natural languages to express requirements. Natural
language texts are often ambiguous, incomplete and
formally incoherent. This is mainly due to the po-
tential complexity of sentences and broad meaning of
words. In order to limit the impact of those charac-
teristics on the expression of requirements, it is usu-
ally considered good practice (ISO, 2011) to use re-
quirement patterns and a word glossary tailored to the
specific domain and type of requirements that have to
be expressed. It may seem that a new language with
its own grammar and vocabulary as then been created
(and from a certain point of view, it is the case); how-
ever, the goal is really to still use the original natural
language, but in a constrained way. This paper at-
tempts to do the same on the use of GPMLs in a con-
strained way for a specific purpose (modeling BDMs
for the example of this paper).
The proposed process (of formal definition of
models fit for a specific purpose) bears resemblance
to programming language design (Pierce, 2002). The
first step consists in defining a semantic domain and
some correctness constraints that are specifically tai-
lored for the concepts that the specific model has
to carry, and are as simple as possible in order to
simplify the formal expression of the modeling re-
quirements. In a second step, only skimmed through
in this paper, the concrete syntax (of those special
purpose models, BDMs for example) is defined by
reusing the concrete syntax of a GPML and map-
ping its abstract syntax to the semantic domain pre-
viously defined (defining a semantics) and translating
the correctness constraints to the GPML abstract syn-
tax (defining typing rules). This mapping is done in
a way that respects as much as possible the original
semantics of the GPML with regard to the aspects re-
flected in the semantic domain of the special purpose
models.
The next section provides an agnostic definition of
BDMs through the definition in sect. 4.1 of a semantic
domain tailored to what is to be expressed in BDMs.
Sect. 4.2 relies on this previously defined semantic
domain to define what are “valid BDMs” through cor-
rectness constraints. Due to space limitation, those
definitions are simplified to a fragment still sufficient
to support the paper’s claim in favor of agnostic mod-
eling requirements.
4 AGNOSTIC DEFINITION OF
BDMS
The goal of a BDM is first to model the behavioral in-
teractions between a product (called “system” there-
after) and its environment, i.e. the reactions of a sys-
tem to the potential solicitations of its environment.
In a second step, the behaviors of those internal oper-
ations are decomposed into interactions between the
organs of the system. BDMs have to express rela-
tions between occurrences of events generated by the
environment, the system or its organs, i.e. how the
occurrence of one of those events can influence the
occurrence of the other events. The events of interest
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
558

generated by the environment are the solicitation mes-
sages sent to the system. With regard to the system
generated events, the interesting ones for BDMs are
the messages emitted towards the environment, the
system’s internal messages and the internal operations
performed by the system or its organs.
The approach chosen to express the possible inter-
actions between events is to define the set of possible
traces (Def. 2) of events (Def. 1) generated by the en-
vironment, the system or its organs.
Definition 1 (Event).
An event, denoted by e, is the occurrence of: an ex-
change of a message between two entities, or of an
operation which is internal to an entity (has no ob-
servable effect outside of the entity).
Definition 2 (Trace).
A trace on a set of events E, denoted by t, is a totally
ordered sequence of events from E.
The remainder of this paper uses the following
definitions:
/
0 is the empty trace (no events); e is the
trace of length 1 composed of the single event e; t.t
0
is
the trace whose sequence of events is the sequence of
events of t followed by the sequence of events of t
0
;
traces(E), for E a set of events, is the set of all traces
containing only events in E.
Definition 3 (Trace germ: t ≺
E
t
0
).
Stating that a trace t is a germ
3
of a trace t
0
over
a set of events E, denoted t ≺
E
t
0
, means that t is
a potential solicitation trace triggering the trace t
0
,
when considering t complete over E. For all traces
t and t
0
, event e and set of events E, ≺ is formally
defined as follows:
•
/
0 ≺
E
t
0
;
• e.t ≺
E
e.t
0
if t ≺
E
t
0
;
• t ≺
E
e.t
0
if e 6∈ E ∧ t ≺
E
t
0
.
4.1 Semantic Domain of BDMs
The semantic domain of BDMs defines the possible
meanings of BDMs. This semantic domain is de-
fined by a set of requirements that BDMs have to re-
spect. Those requirements are expressed at a level
of abstraction which is independent of the concrete
modeling language which could be used to construct
a BDM.
The definition of BDM’s semantic domain in this
paper relies on the implicit
4
definition by any BDM
3
“germ” is used with the meaning “something that initi-
ates development or serves as an origin” (Merriam-Webster)
4
It has to be implicit in this paper due to the space limita-
tion related simplification of the original BDM’s definition.
of: a set MSG
env
of messages generated by the envi-
ronment; a set MSG
sys
of messages generated by the
system; and a set OP
sys
of internal operations that can
potentially be executed by the system in reaction or
not to the solicitation of the environment.
For example, considering that the underlying
SysML model associated to the diagrams of Fig. 2
is a valid BDM of NP, depending on the BDM’s
semantics given to SysML models, MSG
env
would
likely be related to elements whose type is “Packet”
valuetype or one of the enumeration appearing in
the “Black Box View” bdd (“Admin Msg” or “Power
Msg”); MSG
sys
would likely be related to elements
whose type is “Packet” or “LogFile” valuetype;
OP
sys
would most likely be the set of operations
of the “Network Pump” block. However, those sets
could be defined in many different ways in a SysML
model.
A BDM (denoted by BDM) of a system (denoted
by sys) in an environment (denoted by env) defines
a set of sub-models reflecting different aspects of the
decomposition.
Req. 1. BDM defines: a sub-model EBM specifying
the behavior of env towards sys; a sub-model SBM
specifying the global behavior (black box) of sys in
reaction to the solicitations of env; a sub-model SDM
specifying the decomposition of sys into organs; a set
ODM of sub-models ODM
i
specifying the decomposi-
tions of the internal operations of sys; a set OBM of
sub-models OBM
i
specifying the black box behaviors
of the organs of sys.
For Fig. 2, EBM would likely be related to the
stateMachine element named “Environment”, and
be identified as such in a comment associated to this
element. SBM would likely be the stateMachine
element named “NetworkPump”. SDM would likely
be the block element named “Network Pump”. The
activity element named “PT” would likely be in the
set ODM. And the stateMachine elements named
“LowPart” and “HighPart” would likely be in the set
OBM.
EBM defines the set of solicitation traces (se-
quences of messages belonging to MSG
env
or MSG
sys
)
for which SBM must define the black box reactions of
sys. Depending on the purpose of the model, those
solicitation traces could be only those that a compli-
ant environment would generate, or it could include
traces that could only be generated by an attacker.
Req. 2. EBM defines the set T
SOL
of solicitation traces
taken into account in BDM. Elements of those traces
belong to MSG
env
or MSG
sys
.
T
SOL
⊆ traces( MSG
env
∪ MSG
sys
) (1)
Modeling Requirements Should be Language Agnostic! - Example of a Formal Definition of Simple Behavioral Decomposition Models
559

For Fig. 2, T
SOL
would likely be all the sequences
of transition triggers (related to MSG
sys
) and effects
(related to MSG
env
) corresponding to at least one “ex-
ecution” of the stateMachine element named “En-
vironment”. This trace set could also potentially be
defined using interaction or activity elements.
SBM describes the possible system “reactions” (if
any) to all the possible environment solicitations.
Req. 3. SBM defines the set T
SYS
of possible traces
corresponding to reactions of sys to env’s solicita-
tions taken into account in BDM. Elements of those
traces belong to MSG
env
, MSG
sys
or OP
sys
.
T
SYS
⊆ traces( MSG
env
∪ MSG
sys
∪ OP
sys
) (2)
For Fig. 2, T
SYS
would likely be all the sequences
of transition triggers (related to MSG
env
) and effects
(related to MSG
sys
or OP
sys
) corresponding to at least
one “execution” of the stateMachine element named
“NetworkPump”.
SDM describes the organs (components) of sys
and the connections among themselves and with the
environment. By convention, every BDM identifies E
as the environment, in the sub-models related to sys’s
organs.
Req. 4. SDM defines:
a) the set ORG
sys
of organs composing sys in the
decomposition modeled in BDM.
b) the set OP
org
of sys’s organs internal opera-
tions.
c) the operations executable by each organ;
this definition is done through a total function
OP2ORG from OP
org
to ORG
sys
.
OP2ORG : OP
org
→ ORG
sys
(3)
d) the set MSG
org
of messages that sys’s organs
can send and receive.
e) the direct unidirectional connections among
sys’s organs themselves and with the environment
(bidirectional connections of the architecture are
modeled by two unidirectional connections); this
definition is done through a set CON
org
of triplets
made of a message belonging to MSG
org
and two
elements among sys’s organs and env.
CON
org
⊆

(ORG
sys
× MSG
org
× ORG
sys
)
∪ ({E} × MSG
org
× ORG
sys
)
∪ (ORG
sys
× MSG
org
× {E})

(4)
For Fig. 2, ORG
sys
would likely contain only
the “highPart” and “lowPart” parts; OP
org
would
likely contain only the “receivePacket”, “sendPacket”
and “getLog” operations; OP2ORG would map “re-
ceivePacket” to “lowPart” and “sendPacket” and “get-
Log” to “highPart”. MSG
org
would likely be the union
of MSG
env
and MSG
sys
with the addition of messages
related to values of type “Packet” transiting on the in-
ternal connection between “lowPart” and “highPart”.
For all sys’s internal operations, BDM contains an
ODM
i
in ODM which describes the functional decom-
position of this internal operation in a sequence of or-
gans internal operations. BDM also implicitly defines
a total function OP2ODM from OP
sys
to ODM which
maps every sys’s operation to its functional decom-
position.
Req. 5. Each ODM
i
of ODM defines the call graph
of a sys’s operation o (o = OP2ODM
−1
(ODM
i
)). This
call graph is defined by a labeled transition system;
itself defined by a set of edges CG
OP
o
whose associated
nodes belong to OP
org
or {E} and labels to MSG
org
.
CG
OP
o
⊆

(OP
org
× MSG
org
× OP
org
)
∪ ({E} × MSG
org
× OP
org
)
∪ (OP
org
× MSG
org
× {E})

(5)
For Fig. 2, the ODM
i
corresponding to the
operation “transferPacket” would likely be related
to the activity “PT”. This information could also
be embedded in an interaction element.
For every organ identified in SDM, BDM contains
an OBM
i
in OBM describing the possible “reactions”
of this organ to the solicitations of its environment
(env and other organs). BDM also implicitly defines
a total function OR2OBM from ORG
sys
to OBM which
maps every sys’s organ to its behavior.
Req. 6. Each OBM
i
defines the set T
ORG
o
of possi-
ble traces corresponding to reactions of sys’s organ
o (o = OR2OBM
−1
(OBM
i
)) to its environment solici-
tations. Elements of those traces belong to MSG
env
,
MSG
sys
, MSG
org
or OP2ORG
−1
(o).
For Fig. 2, T
ORG
lowPart
would likely be all the se-
quences of transition triggers and effects correspond-
ing to at least one “execution” of the stateMachine
element named LowPart, and similarly for T
ORG
highPart
.
Those trace sets could also potentially be defined us-
ing interaction or activity elements.
4.2 Correctness Constraints of BDMs
Every entity belonging to the semantic domain of
BDMs is not necessarily a valid (complete, unam-
biguous and coherent) BDM. Additional constraints
are expressed to refine the definition of “correct”
BDMs.
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
560

Req. 7. For every trace t
env
of T
SOL
, T
SYS
contains
at least one trace that is a potential description of the
reaction of sys to the solicitation t
env
.
∀t
env
∈ T
SOL
, ∃t
sys
∈ T
SYS
s.t. t
env
≺
MSG
env
t
sys
(6)
This requirement does not ensure that the mod-
eling of T
SYS
is correct. However, if this requirement
does not hold, then the modeling of T
SYS
is incomplete
with regard to T
SOL
; and BDM must be corrected.
Req. 8. Each ODM
i
is such that every (data or con-
trol) message exchanged between two organs’ opera-
tions or with env is physically allowed by the organic
architecture.
∀ (S, M, D) ∈ CG
OP
OP2ODM
−1
(ODM
i
)
,
∃ (S
0
, M, D
0
) ∈ CON
org
s.t.
(S = S
0
∨ OP2ORG(S) = S
0
)
∧ (D = D
0
∨ OP2ORG(D) = D
0
)
(7)
This requirement ensures that message exchange
in the functional decomposition of operations is com-
patible with the physical connections between organs.
Section 4 formally defines some modeling re-
quirements for BDMs. Expressing the same con-
straints directly on SysML would have been more dif-
ficult due to the inherent complexity coming with the
expressive power of SysML.
5 USE OF THE AGNOSTIC
DEFINITION
A seemingly obvious way to use the above agnostic
modeling requirements for BDMs would be to define:
an abstract syntax for BDMs mapping closely the el-
ements in BDM’s semantic domain; and a translation
from the abstract syntax of a GPML to this newly de-
fined BDM’s abstract syntax. However, this approach
is not practical in general as some elements in the se-
mantic domain are infinite (traces and trace sets for
BDMs). Moreover, it would go against the philoso-
phy of the proposed approach which is to tailor the
use of a GPML, and not to create a new DSML.
Figure 3 illustrates how to exploit such agnostic
modeling requirements to tailor the use of GPMLs.
Sections 4 exposed the definition process of the top
part of the figure (semantic domain and correctness
constraints). For every GPML L (SysML, AADL, B,
etc.) that is to be used to describe a BDM, what re-
mains to be done is to define: a semantics of L on the
semantic domain of BDM which respects the original
semantics of L with regard to the concepts featured
in BDM (this semantics describes how a contractor
Semantic Domain
of BDM
Correctness
Constraints
of BDM
Abstract Syntax
of SysML
Abstract Syntax
of . . .
Abstract Syntax
of AADL
Concrete Syntax
of BDM in SysML
Concrete Syntax
of BDM in AADL
Concrete Syntax
of BDM in . . .
defined on
semantics on
semantics on
semantics on
translation to
translation to
translation to
Figure 3: Associating concrete syntaxes.
can express a BDM in L, and how a model written in
L is to be interpreted as a BDM by the contracting
authority); a translation of the agnostic correctness
constraints to the abstract syntax of L that is coherent
to the previously defined semantics (those new con-
straints allow one to directly verify that a model ex-
pressed in L is a valid BDM). Once this is done, con-
tractors are able to write BDM in the modeling lan-
guage of their choice (CS). The DGA is able to verify
directly that the delivered CS models are indeed valid
BDMs (some of the constraints could even be verified
automatically), and to interpret the delivered CS mod-
els as BDMs in order to perform efficient early design
analyses. Moreover, as all the modeling languages for
which a BDM’s semantics has been defined share the
same BDM’s semantic domain, it could be envisioned
to write BDMs mixing different modeling languages.
6 CONCLUSION
This paper addresses the problem of defining model-
ing requirements from a contracting authority (CA)
to a contractor (Co), while still providing flexibility
to the contractor regarding the concrete modeling lan-
guage used.
Using a well-formedness constraints approach,
this task would require: a) the CA to pick a Gen-
eral Purpose Modeling Language (GPML) expressive
enough for the information to carry in the models;
b) the CA to define well-formedness constraints on
the GPML; and c) the Co to use this GPML while re-
specting the constraints defined in b).
Using a DSML approach, this task would require:
a) the CA to build a DSML whose expressiveness
maps closely the one needed for the modeling require-
ments; b) the CA to define correctness constraints on
the DSML defined in a); and c) the Co to use the
DSML defined in a) and respect the constraints of b).
This paper introduces, based on an example, an
Modeling Requirements Should be Language Agnostic! - Example of a Formal Definition of Simple Behavioral Decomposition Models
561

approach to tailor the use of General Purpose Mod-
eling Languages (GPMLs) to a specific purpose, in-
stead of defining a new Domain Specific Modeling
Language (DSML). Our approach is based on the for-
mal definition of Domain Specific Semantic Domains
(DSSDs) with associated correctness constraints. The
tailoring of the GPML is achieved by defining a spe-
cific semantics from the GPML syntax to the DSSD.
Using this approach requires: a) the CA to build a
DSSD D whose expressiveness maps closely the one
needed to carry the information of interest; b) the CA
to define correctness constraints C on D; c) the CA to
define a semantics S
L
i
on D for every GPML L
i
of in-
terest; d) the CA to translate C to C
L
i
for every GPML
L
i
while respecting S
L
i
(C
L
i
= S
−1
L
i
(C)); and e) the Co
to use any GPML L
i
of its choice while respecting S
L
i
and C
L
i
.
This approach allows contractors to use the mod-
eling language of their choice, while still providing
the contracting authorities with the information they
need in order to perform early design analyses. In ad-
dition, by providing a simplified purpose-fit semantics
to a GPML, such as SysML, it simplifies the task to
verify the validity and interpret a model written in this
GPML for a given precise purpose.
The author experience on the specific subject
of this paper is mainly experimental and industrial.
Which can explain why, to the author’s knowledge,
there is no other work directly related to the ap-
proach proposed in this paper. There is a vast amount
of work on programming language design (Pierce,
2002), DSML design (Luoma et al., 2004) or model
validation (Debbabi et al., 2010). However, the author
does not know of a closely related work which would
also be using the DSSD approach.
Future work, already started or planned, include
the definition of the mapping from the abstract syn-
tax of SysML to the semantic domain of BDM, and
the development of an integrated environment for the
development and verification of valid BDM SysML
models.
ACKNOWLEDGEMENTS
The author wishes to acknowledge the authors of the
insightful reviews which helped improve and clarify
this manuscript.
REFERENCES
Abrial, J.-R. (2010). Modeling in Event-B: System and Soft-
ware Engineering. Cambridge University Press.
Alexander, I. F. and Maiden, N. (2004). Scenarios, Stories,
Use Cases: Through the Systems Development Life-
Cycle. John Wiley & Sons, Inc., 1
st
edition.
Cockburn, A. (2007). Agile Software Development: The
Cooperative Game. Pearson Education, 2
nd
edition.
Debbabi, M., Hassa
¨
ıne, F., Jarraya, Y., Soeanu, A., and
Alawneh, L. (2010). Verification and Validation in
Systems Engineering: Assessing UML/SysML Design
Models. Springer-Verlag, Berlin Heidelberg, 1
st
edi-
tion.
Forsberg, K. and Mooz, H. (1998). System Engineering for
Faster, Cheaper, Better. INCOSE International Sym-
posium, 8(1):917–927.
G
´
erard, S., Dumoulin, C., Tessier, P., and Selic, B. (2010).
Papyrus: A UML2 Tool for Domain-specific Lan-
guage Modeling. In Proc. 2007 Model-based Engi-
neering of Embedded Real-time Systems, volume 6100
of LNCS, pages 361–368. Springer.
INCOSE, editor (2015). Systems Engineering Handbook: A
Guide for System Life Cycle Processes and Activities.
John Wiley and Sons, 4
th
edition.
ISO (2011). Systems and software engineering – Life cy-
cle processes –Requirements engineering. Standard
ISO/IEC/IEEE 29148:2011(E), International Organi-
zation for Standardization.
ISTQB Glossary Working Group (2015). Standard Glossary
of Terms Used in Software Testing. Technical report,
International Software Testing Qualifications Board.
Version 3.01.
Kang, M. H., Moskowitz, I. S., and Chincheck, S. (2005).
The Pump: A Decade of Covert Fun. In Proc. Annual
Computer Security Applications Conference, pages
352–360. IEEE Computer Society.
Kolovos, D. S., Paige, R. F., and Polack, F. A. C. (2009). On
the Evolution of OCL for Capturing Structural Con-
straints in Modelling Languages. volume 5115 of Lec-
ture Notes in Computer Science, pages 204–218.
Luoma, J., Kelly, S., and Tolvanen, J.-P. (2004). Defin-
ing Domain-Specific Modeling Languages: Collected
Experiences. In Workshop on Domain-Specific Mod-
eling.
Mcconnell, S. (1996). Daily Build and Smoke Test. IEEE
Software, 13(04):144,143.
Moore, A. P. (2000). Network Pump (NP) Security Target.
Common Criteria’s Security Target NRL/MR/5540–
00-8459, Naval Research Laboratory.
OMG (2012a). Object Constraint Language (OCL). Stan-
dard ISO/IEC 19507:2012(E), International Organiza-
tion for Standardization. Version 2.3.1.
OMG (2012b). OMG Systems Modeling Language (OMG
SysML
TM
). Standard, Object Management Group.
Version 1.3.
Pierce, B. C. (2002). Types and Programming Languages.
MIT Press, Cambridge, MA, USA.
Shamieh, C. (2014). Continuous Engineering For
Dummies
R

. IBM Limited Edition. John Wiley &
Sons, Inc.
The Eclipse Foundation (2015). Papyrus.
https://eclipse.org/papyrus/. [Online; accessed
9-December-2015].
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
562