A formal model for a requirements engineering tool
Fernando Valles Barajas
Computer Science Department, Engineering Faculty, Regiomontana University
15 de Mayo 567 Pte., C.P. 64000 colonia centro, Monterrey, Nuevo León, México
Tel. +52 81 82204733
[email protected]
ABSTRACT
This paper presents the formal specification for a tool that
models the functional requirements of a system based on
use case models. The formal model of such a tool is made
using Alloy, which is a lightweight modeling language. The
structure of the model as well as an analysis of the model
are specified using Alloy. As a complement of the formal
model, a model diagram is also presented using the Alloy
notation.
Categories and Subject Descriptors
D.2.1 [ Requirements/Specifications ]: Tools; D.2.2
[ Design Tools and Techniques ]: Computer-aided software engineering; D.2.4 [ Software/Program Verification ]: Formal methods
General Terms
Design, Verification
Keywords
Use case models, formal specification, requirements engineering
1. INTRODUCTION
Software engineering is an engineering discipline that is concerned with all aspects of software production [14]. Formal
methods are mathematical approaches for the specification,
design and verification of software systems. Recently a lightweight approach of formal methods have captured the attention of the scientific community [1]; the important characteristics of these methods are partiality in language (they
use a less expressive language), analysis and modeling [7].
UML is a modeling language used to design software [12];
this language has a set of diagrams that allows to have several views of a system. Some modern processes like RUP
use UML to make software models [8].
This paper presents the formal specification for a requirements engineering tool that models the functional require-
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. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
First Alloy workshop ’06 Portland, Oregon, USA
ments based on use case diagrams. The modeling language
applied in this paper is Alloy; which uses a lightweight approach [4].
The motivation to use a formal approach to model the requirements engineering tool is that, there are several tools
that specify the requirements of a system, but in the experience of the author of this paper, some of these tools present
a weak design that is reflected in a unpredictable behavior;
for example one useful tool to model the functional requirements of a system using a use case diagram is ArgoUML
[11], but unfortunately in this tool it is possible to specify
in a use case diagram that use case 1 extends use case 2
and vice versa; that use case 2 extends use case 1. The
reason to use a lightweight approach is to make the specification of the requirements engineering tool concise but at
the same time analyzable. Because the previous two points
the author of this paper selected Alloy as the appropriate
modelling language to make the formal model of the requirements engineering tool.
The formal model includes the system structure as well as
an analysis of the model. To have an overview of the requirements engineering tool, first at all, a model diagram is
built using the Alloy notation.
In this section an overview of the paper has been given.
Section 2 presents concepts related to use case models. Section 3 gives some fundamental concepts of Alloy. Section 4
contains a metamodel for the requirements engineering tool.
Section 5 shows the formal specification. Finally section 6
contains some concluding remarks.
2.
USE CASE MODELS
A use case model is a graphical representation of the system
functional requirements. This model is one of the artifacts
created during the requirements work flow of RUP. A use
case model is useful to specify the system that will be constructed and the entities that interact with it. The entities
that can interact with the system are the users and other
computer systems; these are called actors [9]. An actor expects some useful services to satisfy specific requirements.
The interactions between the system and the actors are specified in the use cases. A use case can have one or more scenarios, which are particular instances of a use case. There
are three kinds of relations between the use cases: extend,
include and inheritance. The extend and include relation are
useful to factorize common behavior; both relations add the
behavior of one use case to another but the extend relation
allows an optional inclusion depending on if some conditions are met or not. The point in a use case where other
! name !
UseCaseModel !
Name
Classifier
? inheritance ?
! scenarios +
<UseCaseModel>.use
inheritance
include
extend
User
Scenario
UseCase
Actor
Computer
System
useCase !
Extension
MainSuccess
! extensionPoints
ExtensionPoint
Normal
Exceptional
Figure 1: Metamodel for a use case model using the Alloy notation
use cases can be added by the extend relation is called extension point. The include relation permits to specify when
the inclusion of one use case in another is mandatory. The
inheritance relation between use cases is used when one use
case is more general than other uses case. The only relation
between actors is the inheritance. The relation between uses
cases and actors is represented using an associative relation.
Actors and uses cases are classifiers, which are mechanisms
that include structural and behavioral characteristics [12].
3. ALLOY: A LIGHT WEIGHT MODELING
LANGUAGE
Alloy is a modeling language that allows to specify and analyze a software model [3]. Some of the applications of Alloy
are: file system synchronization [10], finding bugs [6] and
specification and analysis of role based access control extensions [13].
The entities of a model and the relation between them are
specified using signatures, which are the building blocks of
the model structure. There are two types of constraints that
can be declared in an Alloy model; constraints that always
must be met, which are specified using facts, and constraints
that only sometimes must be met, which are specified using predicates. The constraints of an Alloy model can be
declared in two styles: first order predicate style and relational calculus style. Alloy has functions to reuse segments
of a model. This language was developed at the M.I.T. by
the software design group [4]. Two of the advantages of
Alloy are:
• it permits to develop the model incrementally; one can
make a piece of the model, analyze it, and then change
or extend it.
• it is not necessary to have a special tool to write the
model because the model is written in ASCII format.
Theorems about a specification are packaged as assertions
[5].
4.
THE METAMODEL
This section contains a model diagram for the tool that models the functional requirements. The purpose to make a
model diagram is to have an overview of the system that is
being modeled. Because the requirements engineering tool
is based on use case models, the chosen approach was to
model the building blocks and the rules to build use case
models resulting this in the construction of a metamodel.
An analysis of the model can not be made using a model
diagram, this will be performed using the formal approach
in the next section.
Alloy contains some notation similar to that used in UML
class diagrams. In a model diagram the entities of the system and its relations can be specified; also some constraints
on this model can be defined. The disadvantage of a model
diagram is that only simple constraints can be declared, so it
is necessary to define in another document more precise constraints. Fig. 1 presents a metamodel for a use case model.
Every rectangle in this figure represents a set of entities and
the arrows denote relations between the entities. The inheritance relation expresses generalization and is represented
with a fat arrow; for example Classifier is a more general
form of Actor and UseCase; note in fig. 1 that Actor and
UseCase were connected to Classifier with a fat arrow. Actor
is divided in two categories: User and ComputerSystem [9].
Two classes of Scenario were identified, MainSuccess scenario and Extension scenario, where the latter was divided
in Normal and Exceptional scenario. Associations between
entities are represented with a small arrow; for example in
fig. 1 an association from Actor to Actor was drawn. The
name of the association and the multiplicity can be specified
near the arrow; for example in the association from Actor
to Actor its name is inheritance (an actor can inherit from
another) and the multiplicity was specified using the ? symbol. The symbols to specify multiplicity and the meaning
are: ? zero or one, ! exactly one, + one or more and * any
number (the default).
Ovals are used to represent a single entity; see for example
that an oval was used to represent UseCaseModel.
An abstract class, which is a class that can not generate instances, is specified in the Alloy notation writing the name
of the entity using italic font; Classifier, Actor, Scenario and
Extension are abstract classes.
The reader is refered to [12] to see a concise explanation of
use case models.
1
2
3
5. THE FORMAL MODEL
This section presents the formal specification for the tool
that models the system functional requirements. According
with [14] functional requirements are statements of services
the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.
A model with the elements of a use case diagram built by
the requirements engineering tool will be constructed, but
in this case an analysis of the model as well as further constraints on the model will be specified using Alloy. For an
easier explanation, the formal model will be incrementally
constructed.
Fig. 2 presents an initial model for the use case model. The
first line is the header of the model and it declares that the
name of the model is useCaseFormalModel and that it is
in the subdirectory umlFormalModels. Line 2 defines the
signature Name. Next, a signature labeled as Classifier is
declared; this signature is marked as abstract which means
that no instances of this signature are generated. Two subtypes of the signature Classifier are defined: Actor and UseCase; see line 4. The extend keyword together with the
abstract keyword implies that Actor and UseCase form a
partition of Classifier. The next signature defines the UseCaseModel; inside this signature some relations are declared:
actors, useCases and use; which are respectively relations
between the use case model and the actors, the use case
model and use cases and the last one is a ternary relation of
the form use case model->actors->use cases. Every use case
model should have at least one actor, it makes no sense to
have a system that nobody uses. The keyword some defines
multiplicity and indicates one or more. A use case can have
zero or more actors and an actor can have zero or more use
cases; this is specified in line 8 using the keyword set. Line
11 specifies an invariant on Name. Next a constraint is declared using a predicate. The last line of this model is used
to generate an instance of the model.
It is important to mention that the relations actors and useCases of the UseCaseModel signature were omitted in the
model diagram of section 4 for the purpose of simplicity.
This section has presented the first version of the formal
model, the following sections will improve this model.
5.1 Extend relation in use cases
As it was stated in section 2, one of the relations between
uses cases is the extend relation. Fig. 3 contains the declaration of the extend relation (2) and some constraints (6), (7),
(8) on this relation. In this model the noReflexive invariant
is inside of the Acyclic invariant, then these two invariants
can be substituted by the invariant
fact AcyclicNoReflexive{ no iden & ˆextend }
Figs. 4(a) and 4(b) contain two instances of the Alloy model
that illustrate the extend relation. Fig. 4(a) presents an instance of the model without the constraints defined in fig.
4
5
6
7
8
9
10
11
12
13
module umlFormalModels/useCaseFormalModel
sig Name{}
abstract sig Classifier{ name: one Name }
sig Actor, UseCase extends Classifier{}
sig UseCaseModel{
actors: some Actor,
useCases: some UseCase,
use: actors set -> set useCases
}
-- invariants on Name
fact nameIsABijection{
name: Classifier one -> one Name
}
16
pred showInstance(ucm: UseCaseModel){
#ucm.useCases = 4
}
17
run showInstance for 4 but 1 UseCaseModel
14
15
Figure 2: Initial model for the use case model
1
2
3
4
5
6
7
8
sig Actor extends Classifier{}
sig UseCase extends Classifier{
extend: set UseCase
}
-- properties of the extend relation
fact noSymmetric{ no ˜extend & extend }
fact noReflexive{ no iden & extend }
fact Acyclic{ no iden & ˆextend }
Figure 3: Constraints on the extend relation
3 while fig. 4(b) includes the constrains on the extend relation. The problems that fig. 4(a) presents are: a use case is
related with itself (use case 3), a use case extends another
use case and the latter use case extends the former (use case
1 and 2) and an actor uses two use cases related with the
extend relation (actor 0 and use cases 1 and 2). It is important to mention that in figs. 4(a) and 4(b) the relation
between an actor and a use case has been labeled as uses.
5.1.1
Extension points
The point in a use case where another use case can be included using the extend relation is called extension point.
Fig. 5 presents a model that considers the extension points.
Lines 7 and 8 are signature facts, which allow to declare
constraints related to a signature in a easier way. Every use
case should have zero or more extension points and each extension point should be assigned to exactly one use case (line
12). The useCaseIsATotalFunction fact is implicit from the
(a) Instance with unconstrained extend
(b) Instance with constrained extend
Figure 4: Analysis of the extend relation
declaration, but is written as a part of the documentation.
The noSelfCall fact allows to constraint that a use case can
not call to itself.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
sig ExtensionPoint{ useCase: one UseCase }
sig UseCase extends Classifier{
-- as before
extensionPoints: set ExtensionPoint
}
{
#extend = #extensionPoints
all e: extensionPoints | extend in e.useCase
}
-- invariants on the extension points
fact useCaseIsATotalFunction{
useCase: ExtensionPoint set -> one UseCase
}
fact extensionPointsIsAnInjectiveRelation{
extensionPoints:
UseCase one -> set ExtensionPoint
}
fact noSelfCall{
no u: UseCase | u in extensionPoints.useCase[u]
}
writing constrains for these relations, the constrains of the
extend relation defined in fig. 3 are rebuilt in fig. 6 to take
advantage of the re usability using polymorphic functions;
see lines 11 and 14 of fig. 6.
5.3
5.4
5.2 Inheritance and include relations in use
cases
These relations must have the two properties of the extend
relation; noSymmetric and AcyclicNoReflexive. Instead of
Actors
Fig. 10 defines the two types of actors in a use case model:
users and computer systems. Line 5 declares some invariants
on the actors. As it can be seen in lines 7 and 8 the two
properties of the relations of the uses cases are also defined
in the inheritance relation of actors.
Fig. 10 also defines some constraints that control how the
actors and use cases can be associated. In figs. 8 and 9 some
undesirable instances are presented; where lines (17), (21)
and (30) of fig. 10 correspond respectively to figs. 8(a), 8(b)
and 9(b).
5.5
Figure 5: Extension points for use cases
Scenarios
In fig. 7 the formal specification has been improved by including the concept of scenarios. According with the model
diagram defined in section 4 the scenarios are classified in
main success scenario and the extension scenario, where the
latter are divided in normal and exceptional scenario. The
fact of line 16 constrains that every use case must have exactly one main success scenario [2].
Analyzing the model
The Alloy analyzer is a tool that can be used to check the
properties that the model must have. Fig. 11 presents the
analysis for a particular property of the model: that an actor
is connected either to a use case or to another actor. Line 1
defines a function that returns the ancestors of an actor and
line 4 defines a function that returns the descendants of an
actor. In line 15 an assertion is defined.
In order to check a model property, the Alloy analyzer tries
to find a counterexample for an assertion by using the check
1
2
3
4
5
6
7
8
sig UseCase extends Classifier{
-- as before
inheritance: set UseCase,
include: set UseCase
}
{
-- as before
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
-- properties of the actor and
-- use case relations
pred AcyclicNoReflexive(r: univ -> univ) {
no iden & ˆr
}
pred noSymmetric(r: univ -> univ){ no ˜r & r }
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
-- invariants on the extend relation of
-- use cases
fact{
AcyclicNoReflexive(extend)
noSymmetric(extend)
}
-- invariants on the inheritance relation of
-- use cases
fact{
AcyclicNoReflexive(UseCase <: inheritance)
noSymmetric(UseCase <: inheritance)
}
-- invariants on the include relation of
-- use cases
fact{
AcyclicNoReflexive(include)
noSymmetric(include)
}
Figure 6: Invariants of use cases relations
command (line 19). Fig. 12 shows the counterexample found
by the Alloy analyzer when the check command was run. As
it can be seen the model does not posses the property stated
above; the actor ComputerSystem0 is not connected neither
with a use case nor with another actor. The reader can see
that, in fig. 12 the actor that does not achieve the property
is marked with the label connectedActors a; this label was
built by chaining the name of the assertion with the variable
a used in that assertion (this variable is defined in line 16).
To fix this problem it was necessary to add to the model the
invariant
fact{
all a: Actor |not isConnected(a) =>
some useCasesAssociatedWith(a)
}
15
16
17
18
19
abstract sig Scenario{}
sig MainSuccess extends Scenario{}
abstract sig Extension extends Scenario{}
sig Normal, Exceptional extends Extension{}
sig UseCase extends Classifier{
-- as before
scenarios: some ( MainSuccess + Extension )
}
{
-- as before
}
-- invariants on scenarios
fact scenariosIsAnInjectiveRelation{
scenarios: UseCase one -> some Scenario
}
fact oneMainSuccessScenario{
all u: UseCase |
one s: u.scenarios | s in MainSuccess
}
Figure 7: Scenarios for use cases
After this invariant was added to the model, the Alloy analyzer did not generate any counterexample.
Using this analysis as a base, it can be argued that with very
little effort, properties of a model can be effectively checked
by using the Alloy analyzer; as it can be seen in fig. 11 the
number of the lines used in this analysis was only 20.
6.
CONCLUSIONS
The Alloy modeling language has a very clear way to model
the states of a system and the legal transitions between
them. The states are specified by modeling the entities of
a system and their relations; this is made by using signatures. The specification of constraints over the states and
their transitions using first-order logic is a good characteristic of Alloy; there are some modeling languages that use
higher-order logic but the model obtained with these languages are often harder to analyze. The generation of instances of the model with the Alloy analyzer is a good help
to incrementally make the model; the person that makes the
specification can detect a modeling error at the early stage
of the specification instead of at the end. The Alloy notation
to make a model diagram constitutes a tool to complement
the formal model; an overview of the system can be specified
using this notation. The automatic checking of the model
properties using the Alloy analyzer makes easier to establish
whether the model has these properties or not.
All the previous points helped to the author of this paper to
build the formal specification of the requirements engineering tool as well as to make the model diagram.
Some properties of the model that were not considered at
the beginning of the specification resulted latter in modeling errors; these were detected generating instances with the
Alloy analyzer. The author of this paper believes that the
models generated in this paper are an excellent source for
the requirements document of the requirements engineering
(a) A use case associated with two actors
related with inheritance
(b) An actor associated with two use
case related with inheritance
Figure 8: Undesirable instances in the specification
of the requirements engineering tool (part I)
(a) Two actors of different subtype related with inheritance
(b) Two use cases related with inheritance associated with two actors related
with inheritance
Figure 9: Undesirable instances in the specification
of the requirements engineering tool (part II)
1
2
3
1
2
3
4
abstract sig Actor extends Classifier{
inheritance: lone Actor
}
sig User, ComputerSystem extends Actor{}
4
5
6
7
5
6
7
8
9
10
11
12
13
14
15
16
17
18
-- invariants on actors
fact{
AcyclicNoReflexive(Actor <: inheritance)
noSymmetric(Actor <: inheritance)
Actor<:inheritance: Actor lone -> lone Actor
}
sig UseCaseModel{
-- as before
}
{
-- a use case can not be associated with
-- two actors related with inheritance
all u: useCases, disj a, a’: use.u |
a not in a’.ˆinheritance
8
9
10
11
12
13
14
15
16
17
18
19
20
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
-- an actor can not be associated with two
-- use cases having any relation
all a: actors, disj u, u’: use[a] |
u not in elementsRelatedWith(u’)
---all
no parents of an actor associated with
a use case can be associated with
a use case
a: actors | some use[a] => no use[ a.ˆinheritance ]
-- two actors related with inheritance can
-- not be associated with two use cases
-- having any relation
all disj a, a’: actors, disj u, u’: useCases |
{
a in a’.ˆinheritance
u in elementsRelatedWith(u’)
isAssociatedWith(u, a+a’)
} =>
not isAssociatedWith(u’,a+a’)
}
fun elementsRelatedWith(u’: UseCase): set UseCase{
u’.^extend + u’.^include + u’.^inheritance
}
pred isAssociatedWith(u: UseCase, actors: set Actor){
u in UseCaseModel.use[actors]
}
Figure 10: Actors
fun parentsOf(a: Actor): lone Actor{
a.(Actor<:inheritance)
}
fun childrenOf(a: Actor): lone Actor{
(Actor<:inheritance).a
}
pred isConnected(a: Actor){
some parentsOf(a) or some childrenOf(a)
}
fun useCaseAssociatedWith(a: Actor): set UseCase{
UseCaseModel.use[a]
}
-- every actor is associated with either a
-- use case or with another actor
assert connectedActors{
all a: Actor | some useCaseAssociatedWith(a)
or isConnected(a)
}
check connectedActors for 6, exactly 2 Actor,
exactly 4 UseCase
Figure 11: Analysis of the model
tool.
7.
REFERENCES
[1] S. Agerholm and P. G. Larsen. A lightweight approach
to formal methods. Proceedings of the International
Workshop on Current Trends in Applied Formal
Methods, 1998.
[2] M. Fowler. UML Distilled: A Brief Guide to the
Standard Object Modeling Language. Addison-Wesley,
3rd edition, 2003.
[3] D. Jackson. A comparison of object modelling
notations: Alloy, uml and z. 1999.
[4] D. Jackson. Software Abstractions: Logic, Language
and Analysis. MIT Press, England, 2006.
[5] D. Jackson, I. Shlyakhter, and M. Sridharan. A
micromodularity mechanism. In Proc. ACM SIGSOFT
Conf. Foundations of Software Engineering, Vienna,
Austria, 2001.
[6] D. Jackson and M. Vaziri. Finding bugs with a
constraint solver. In Proc. International Conference on
Software Testing and Analysis, Portland, Oregon,
United States, 2000.
[7] D. Jackson and J. Wing. Lightweight formal methods.
IEEE Computer, 1996.
[8] P. Kroll and P. Kruchten. The Rational Unified
Process Made Easy. Addison Wesley, USA, 2003.
Figure 12: Counterexample found by the Alloy analyzer for the connectedActors assertion
[9] C. Larman. Applying UML and Patterns : An
Introduction to Object-Oriented Analysis and Design
and Iterative Development. Prentice Hall, USA, 3rd
edition, 2004.
[10] T. Nolte. Exploring Filesystem Synchronization with
Lightweight Modeling and Analysis. PhD thesis,
M.I.T., U.S.A., 2002.
[11] A. Ramı́rez, P. Vanpeperstraete, A. Rueckert,
K. Odutola, J. Bennett, and L. Tolke. Argouml user
manual. http://argouml.tigris.org/, 2006.
[12] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified
Modeling Language Reference Manual.
Addison-Wesley Professional, 2nd edition, 2004.
[13] A. Schaad and J. D. Moffett. A lightweight approach
to specification and analysis of role based access
control extensions. In ACM SACMAT 2002, Monterey,
California, USA, 2002.
[14] I. Sommerville. Software Engineering. Prentice Hall,
USA, 7th edition, 2004.