![](bg2.png)
2 BACKGROUND
In software verification, model checking is increas-
ingly used to verify that a formally specified model
satisfy some desired property (Lamsweerde, 2009).
In the most frequent form of model checking, the in-
puts to the checker are a formal state machine model
and a desired property formalized in temporal logic.
Applying this technique in an industrial context suf-
fer from the combinatorial explosion induced by the
internal complexity of the software to be verified.
One way to circumvent this problem consists of
specifying/restricting the context in which the system
will be used. This context corresponds to well-defined
operational phases, such as, for example, initializa-
tion, reconfiguration, degraded mode, etc. The sys-
tem is then tightly synchronized with its environment
so that properties can be checked in specific contexts
which limits the size of the generated state space.
In this context, CDL aims to ease the construction
of context models and to specify properties. CDL de-
scribes a system environment using activity and se-
quence diagrams, together with a textual syntax. Ac-
tivity and sequence diagrams are used to describe con-
texts, and the textual syntax to describe properties to
be checked. The properties are specified using prop-
erty description patterns and attached to specific ele-
ments in the activity diagram describing the context.
CDL have demonstrated its usefulness in porting
formal verifications into industrial practices through
several industrial projects (Dhaussy et al., 2009).
However, CDL models construction remains a man-
ual process requiring time and efforts to understand
the system specifications in order to produce precise
contexts’ interactions.
3 USER CONTEXT MODELS
The main idea is to encourage engineers to put enough
details in their daily constructed models. This en-
couragement is made through the UCM framework
that presents guidelines for constructing contexts and
specifying properties as well as algorithms to auto-
mate formal models generations from these models.
Figure 1 shows an overview of UCM content. The
left side of figure 1 presents different steps leading to
the generation of formal models describing the behav-
ior of different actors of the environment, i.e. context.
The right side shows the property specification activ-
ities that aims to formalize properties to be checked.
We have defined and formalized the generation
of behavioral models of the context using a model
based approach (the left side of figure 1). We use
UCM
Capture and formalization
of system contexts
Property specificaiton
Requirement
Documents
User
Models
Requirement
decomposition
Pattern
identification
Property
formalisation
Extended
use cases
Activity
diagram per
UC
Activity
diagram per
Actor
CDL
Figure 1: UCM content overview.
an extended form of use cases to capture system re-
quirements as well as possible exceptions and corre-
sponding handlers if any. The idea behind this step
is to gather all useful information about the system
behavior and its interactions with environment actors.
Constructed use cases are then used as input in our
model transformation to generate formal models di-
rectly processable by a model checker.
Extended use cases are similar to traditional use
cases except that they capture system requirements as
well as possible exceptions and corresponding han-
dlers if any (Mustafiz et al., 2009).In fact, many ex-
ceptional situations might appear during the execu-
tion of an application. The difficulties arising during
verification process are usually related to the missing
of relevant information about system behavior, espe-
cially when an exception endangers the normal execu-
tion of a use case. To encounter this problem, we pro-
pose that engineers (whom designed the system in the
first place) specify their systems using extended use
cases to foresee these exceptional situations and doc-
ument how the system should deal with them. This
approach leads engineers to systematically investigate
all possible exceptions arising in the environment that
the system may be exposed to.
We have proposed a metamodel of the extended
use cases (figure 2) and an algorithm to derive the be-
havior of different actors involved in the use case.
In figure 2, classes with a white background are
imported from the UML metamodel, and should be
related to the identical ones presented in (OMG,
2007). The classes with the filled background was in-
troduced to deal with exceptions and handlers in tra-
ditional use cases. The important point in the pro-
USER CONTEXT MODELS - A Framework to Ease Software Formal Verifications
381