A CASE Tool for Information System Project and Development

A. Boccalatte, D. Giglio, and M. Paolucci

DIST - University of Genova
Via Opera Pia 13,I-16145 Genova, Italy
nino,giglio,paolucci@dist.unige.it
ABSTRACT
The project of a tool that aims at supporting the design of
Information Systems and the development of its first prototype,
which includes all the functionalities directed to the definition of
the dynamic part of ISs, are presented in this paper. The purpose
is to develop a CASE tool that can even be used by semiinexperienced users (i.e. users without particular knowledges
about logical and physical structuring of an IS). The Information
System DEsign Support system (ISYDES) is composed of two
main parts: the former allows the definition of the static structure
of data through a simple conceptual model which can be directly
translated into a relational one (to this end, an object-oriented
generalization of an entity-relationship diagram is proposed),
whereas the latter allows the definition of functions, which
constitute the dynamic part of an IS, through a simple graphical
formalism (based on the UML activity diagrams). In this paper,
attention is focused on the second part of the tool. The adopted
formalism is described in a detailed way and the procedure that
transforms such formalism in a labelled and controlled Petri net
is presented. In fact, all the dynamics of an IS is provided by the
utilization of Petri nets as they can be embedded into the
relational database management system through their
representation in terms of relations.
1.

INTRODUCTION

The project of an Information System (IS) is a very delicate and

fundamental activity and its development has to be carried out
with great attention. In the age we live in, everything tends to be
computer-based and, for this reason, having an efficient IS is a
necessary condition to organize and manage in the best way the
activities of a system. Ambiguity and inaccuracy that usually
characterize the beginning phases of the design process could be
reduced by the use of tools for formal specification. In particular,
the translation of requirements into a system conceptual model
can be aided. Such a role is the one played by CASE designing
tools which support the system specification and the design
documentation, trying to automate, at least partially, the
development of a logical system design [l]. In this paper, we
present an Information System DEsign Support system
(ISYDES): a CASE tool for IS design. In particular, this tool
aims at supporting the phase of system conceptual design, the
successive definition of the logical IS structures and the physical
implementation of the IS as Relational DataBase Management
System (RDBMS).

In conceptual designing, both passive and active information,

which provides the static data structures and defines the
functions to be implemented, has to be modeled [3]. The need of
a modeling tool which allows to integrate such classes of
information has suggested to the authors the use of an Object
Oriented (00)approach. Consistency of model views, improved

0-7803-5731-0/99$$10.0001999 IEEE

problem domain abstraction, enhanced facilities for reuse and in

presence of changes, better support for reliability and
concurrency, are the main advantages of an object oriented
approach. Let us briefly discuss about these advantages. One of
the primary problem in design information systems is the
difficulty in mapping analysis views to design views. In object
oriented approach the same set of modeling views is used in all
phases of the development (object and classes used during the
analysis phase have a direct representation in the code). Object
oriented systems can be developed using either an elaborative
or a translative approach [SI. The representation of domain
abstraction is more powerful using 00 approach because object
oriented modeling mantains a strong cohesion between
operations and data. A small change in requirements may have a
catastrophic effect in the software structure; using object
oriented system abstraction (i.e. objects and classes) the
changing requirements are limited to adding or removing object
rather than a global restructuring of the system. Also the reuse
problem can be easily solved. A component that matches exactly
with specific needs it can be reused by adding the component to
the existing code (inheritance). For these reasons, an object
oriented approach has been used in our work adopting the
Unified Modeling Language (UML) to express constructs and
relationships of a system. UML is a complete method for
supporting the modeling of complex systems [4]; its major
features includes: object modeling, use case and scenarios,
packaging of various types of identities, representation of tasks
and task synchronization, models of phisical topology, models of
source code organization, support for object oriented patterns.
However, most of the current ISs are based, and in the next years
will probably be based, on the relational data model. For this
reason, not only the problem of adopting formalisms for static
and dynamic conceptual modeling that can be effectively
integrated has to be faced, but also the one of finding an efficient
physical implementation for the above information model. As
already stated, an IS should be used both to collect and store data
and to elaborate them in order to lead the behavior of a system
according to the needs. An approach for dealing with the above
two features based on the integration of two standard
methodologies, Relational Databases (RDBs) and Petri Nets
(PNs), has been proposed in [2]. With such an approach the
static behavior can be represented by means of relations,
whereas all dynamic characteristics are modeled through PNs; to
reach a higher level of uniformity, the model of the dynamic
behavior can be embedded in the existent static information
structure by including into the RDB a relational description of
PNs.
This paper is organized as follows. In paragraph 2 a description
of the overall structure of ISYDES is presented; paragraph 3
introduces the chracteristics of the conceptual data modeling
process, whereas in paragraph 4 conceptual functional design is

III - 1042

Authorized licensed use limited to: Universitaet Bielefeld. Downloaded on April 20,2010 at 05:16:17 UTC from IEEE Xplore. Restrictions apply.

considered and the use of UML activity diagrams and labelled

and controlled PNs are discussed. The details of the procedure
for translating a functional conceptual model expressed as UML
activity diagrams into labelled and controlled PNs are illustrated
in paragraph 5 . An example of application and future
developments are finally presented in paragraph 6.
2.

THE OVERALL SYSTEM STRUCTURE

ISYDES has been designed as a CASE tool that allows the user
to specify by means of a standard formalism both the static data
structure and the dynamic processed characterizing an IS. Such a
tool has been defined in order to support the development of ISs
based on a relational structure, but even with the possibility to
use it for Object-Oriented Database (OODB) management
systems. Also for this reason, the ISYDES tool has been based
on the object model, taking into account that it includes most of
the features that could be exploited both during the conceptual
design and the logical one phase. The basic idea is then to define
and store in an OODB all the semantic information that
characterize the conceptual design of an IS and to provide such a
system with procedures for translating in an automatic way both
data structures and procedures into an IS based on a relational
model.

I
Class Diagram

can be easily represented by means of Petri Nets (PNs), in order

to follow the approach already discussed by the authors in [2,3].
With reference to figure 1, let us briefly discuss about the main
characteristics of the overall system. ISYDES tool consists of
two main parts: the former directed to the development of the
static structure of IS whereas the latter aimed at the definition of
dynamic features. Each of such two parts has been developed
independently and they have to be considered seriatim by the
user: to start the definition of dynamic part is necessary to have
previously defined the static part. In fact, once entirely defined
static features of our system, ISYDES tool automatically inserts
the database containing the static part into a RDBMS, and
creates and provides a data dictionary which will be further used
by the UML activity diagram editor. Such a data dictionary is the
trait dunion between development of static part and
development of dynamic one. Once defined static characteristics,
it is possible by the user to start with dynamic feature definition;
this can be done drawing functions adopting UML activity
diagram formalism. All defined functions are modeled through
labelled, and controlled Petri net through a synthesis procedure;
at that point, ISYDES tool automatically inserts the relational
representation of every obtained Petri nets into the pre-existent
database inside the RDBMS. The database is now completely
defined and the IS too: using a simple external module which
performs Petri nets token game [lo] we have an information
system which is able to automatically update own data, carrying
out in a totally autonomous way a set of activities which before
had to be performed through external occurrences of IS user.

3.
Activity Diagram
Editor

CONCEPTUAL DATA DESIGN

The first fundamental step that should be performed in designing

an IS is represented by the definition of the conceptual model of
the information. The conceptual design requires the specification
of all the operational data to be collected and processed. Such a
formal specification yelds several documents usually including
an Entity-Relationship (ER) representation of the static structure
of information, a data dictionary and a list of integrity constraints
on the data.

HDBMS

INFORMATION SYSTEM

Fig. 1 - Overall System

The problem of defining a formalism for the the conceptual
design has been faced during the beginning phases of the project.
A suitable possibility seemed .to use two different diagrams
included into the Unified Modeling Language [4]to define the
static data structure during the Conceptual Data Design (CDD)
phase and the system functions during the successive Conceptual
Function Design (CFD) phase. UML includes several
representation formalisms that can be exploited to generally
support a system modeling activity. In particular, UML class
diagram is well suited for 00 modeling. Class diagrams can be
even considered a superset of the Entity-Relationship model,
usually adopted in the project of relational DB for conceptual
modeling, and then it seems quite natural to base the CDD on
such a diagram. More complicated has been the choice of UML
activity diagrams for the CFD phase: the problem in this case has
been represented by the necessity of adopting a formalism which

The purpose of such a phase of IS design is twofold:

to allow the designer to effectively fix in a formal way the
concepts that have been catched during the first analysis of
the problem and the definition of the system requirements;
to provide a simple and shareable documentation that easily
allows to modify and improve the system.
In order to design ISs based on a Relational DBMS, the ER
model is adopted for the conceptual data design (CDD) as such a
model is quite simple to use and easy to understand, and, in
particular, because simple rules to produce the relational
structure from ER diagrams exist. However, the use of the ER
model for CDD has some drawbacks:
the semantic structure, which is clearly represented in terms
of entities and relationships, is successively lost by
translating an ER model into a relational one. The
description of the meaning of the information provided by
ER models usually remains as a documentation of the design
process and cannot be exploited by the actual system users;
the representation primitives available for the ER model are
not sufficient to formally describe neither the integrity
constraints on data, nor, as already observed, allow any
representation of the dynamic IS processes; in addition, a
formalism for data functional design that can be effectively
integrated with the ER model does not seem available.

III - 1043

Authorized licensed use limited to: Universitaet Bielefeld. Downloaded on April 20,2010 at 05:16:17 UTC from IEEE Xplore. Restrictions apply.

The application of object-oriented (00) modeling to database

has been stimulated even by the fact that 00 models can fill the
gap between conceptual and logical design that is usually
reffered to as impedance mismatch [ 111. OODBs allow the
designer to directly use the data structure defined during the
CDD phase as logical structure for the database; in addition,
classes and objects could include methods to embed in the static
structure the representation of processes as well.

Class Diagram
Editor

Relational DataFkase
Management System

3-t

Dictiona

some host language that should be invoked from the outside

of the RDBMS.
The output of the UML2RM is then a relational model that is
described by an object data dictionary stored in the OODB of the
design system. Associated with the data dictionary a set of SQL
statements, whose execution creates the relational data
structures, is generated. The important role of the object data
dictionary should be made clearer. Besides providing a
representation of the relational database in the design system, the
dictionary is fundamental to properly perform the successive
conceptual functional design phase. As a matter of facts, each
class of the conceptual data model is connected in the system
OODB by a proper association link to the data dictionary object
associated with its relational representation. As stated in the
introduction, this paper is particularly devoted to the description
of the approach adopted for supporting the modeling of the
functions of a IS and for integrating then in the development of a
relational database. Such an approach comes from the need to
define a formalism that, in a way similar to ER first and then to
UML class diagrams, can be almost automatically translated in
procedures on data directly executable by the target RDBMS.
4.

Fig. 2 - Conceptual data design

ISYDES, the design support system that is described in this
work, tries to join together the need for a modeling tool based on
a standard formalism, and the consideration that the relational
model will continue to be used in most of the application
contexts for the next future. Moreover, the 00 model can be
adopted for CDD as they generalize the representation primitives
of ER models and could directly provide the logical data
structure for an OODB. For these reasons the proposed design
support tool is based on an 00 model and, more specifically,
utilizes an OODB, to define the conceptual data model. In
addition, the UML has been selected as reference standard
representation formalism for object model. To specify the class
taxonomy corresponding to the conceptual data model, a UML
class diagram can be defined by means of a graphic editor
window of ISYDES. Then, as depicted in Figure 2, the CDD
phase is perfomed simply defining the hierarchy of classes and
their associations to represent entities and relationships in a way
that is quite similar to the one of ER diagrams. However, the
representation power of UML class diagrams go beyond the one
of ER ones: as for the latter, class diagrams allow to include
attributes for the classes, but in this case even integrity
constraints can be represented by means of functions (methods)
embedded in the same classes. This feature can also be exploited
for relationships among classes by the defintion of methods for
the relevant association classes. The CDD produces a class
diagram that is a persistent part of the ISYDES Object Database.
The system then can derive the associated relational structure by
invoking a translation module, that identifies the relational data
structures, tables, fields and the different kinds of keys,
corresponding to the object model. In the current version of the
prototype of ISYDES several simplifications have been
introduced:
the presence of generalizations in the class diagram is
resolved by asking to the user to select the strategy more
appropriate for the context under concern (e.g., generate a
table associated with the upper class in the hierarchy or more
tables according the lower classes);
the methods used to verify the integrity of data can produce
simple expressions to be checked before data manipulation,
or, in more complicated cases, they produce a function in

CONCEPTUAL FUNCTIONAL DESIGN

The definition of the dynamic part of an IS makes use of UML

activity diagrams [4,5]and of a particular class of Petri nets [9,
IO], the labelled and controlled ones. UML activity diagrams are
explicitly used to define functions and activities: ISYDES tool
provides an UML activity diagram editor; furthermore, to each
element of drawn diagrams is associated a dialog window which
allows the user to define in a detailed way all functionalities of
the element itself (also through the information makes available
by the OODB data dictionary). As functions and activities are
defined, an object oriented database, which contains all needed
information, is create. Through the utilization of such an OODB
and once all functions have been defined, ISYDES tool
automatically perform the synthesis procedure which converts
the UML structure into labelled and controlled Petri nets.
Always in a automatic way, the tool provides the relational
model of such a class of nets and inserts as instances all
information previously stored into the object oriented database.
Figure 3 simply illustrates such concepts.

t%yJ
Dictiona

Activity Diagram

Relational DataBase
Management System

Procedure
Petri Nets

Fig. 3 - Conceptual functional design

Labelled and Controlled Petri Nets

Labelled and controlled Petri nets are a particular class of PNs
which allow to impose external transition activation policies to
the net and to influence the token flow inside the net itself; such
policies are accomplished through the so-called control places

III - 1044

Authorized licensed use limited to: Universitaet Bielefeld. Downloaded on April 20,2010 at 05:16:17 UTC from IEEE Xplore. Restrictions apply.

[6]. The concept of control place and of CPNs was first

introduced by Krogh [8] and Ichikawa and Hiraishi [7].
Following the formalism adopted in defining ordinary PNs, we
make use of the next definition:
Definition 1: A labelled and controlled Petri net is a six-tuple
LCPN = {P, CP, T, LT, F, W} where P is a finite set of n = I P I
places; CP is a finite set of n = I CP I control places; T is a finite
set of m = I T I transitions; LT is a finite set of m = I LT I
labelled transition; P n CP n T n LT = 0 i.e. places, control
places, transitions and labelled transitions are disjoint sets; F c
(P x T) U (P x LT) U (CP x T) U (T x P) U (LT x P) is the flow
relation (set of directed arcs); W : F -+ NC assigns a weight to
each arc.
LCPNs are structurally composed by four disjoint sets of objects:
the innovation is in the use of a new typology of places, control
places, and of a new typology of transitions, labelled transitions.
The main role of control places is to communicate with the
modeled system: the marking of a control place doesnt depend
of the PN evolution (token game) but is a function of the state of
the system; in such a way, it is possible to force the firing of one
or more transition according to the observation of the system
state. To the labelled transitions could be associate a label: in our
tool, such a label is the name of an external program to be
executed every time a token pass through the labelled transition.
LCPNs are very suited to solve the sequence synchronizing
problem [2].
5.

FROM UML ACTIVITY DIAGRAMS

TO PETRI NETS

In the previous paragraph UML activity diagrams have been

introduced, and it has been shown as all processes, which can be
logically divided into a sequential set of indipendent operations,
are modelable through such diagrams. Each of these operations
is represented as an indipendent module and all modules are
interconnetted between them through directed arcs; furthermore,
it is possible to have simple and conditioned routing and loops to
repeat the same operation. In this paragraph, it is shown how the
labelled and controlled Petri net that models an UML activity
diagram can be obtained. A labelled and controlled Petri subnet
is defined for each UML activity diagram atomic element (initial
state, action state, activity state, branching, forking and joining,
multiple trigger, and final state): through the interconnection of
every subnets (UML activity diagram synthesis procedure) the
net which models the whole diagram is obtained. In the
following all atomic representations are presented.

action state. The firing of labelled transition It,, other than

inserting a token into place pl, allows the beginning of execution
of function F. The presence of a token inside p1 means that the
modeled function is being executed. When the execution of F
ends, a token is automatically inserted into control place cpl and
the token game of the labelled and controlled Petri subnet can
start again through the firing of transition t,. Finally, the
presence of a token inside place p2 means that the modeled
function is ended.

[T)

EO
Fig. 6 - Petri subnet which models an activity state

+
I

CP2

FALSE
P

P3

Fig. 7 - Petri subnet which models a branching

Likewise modeling an action state, an activity state can be
represented by a labelled and controlled Petri subnet. With
reference to figure 6, the firing of labelled transition Itl allows
the beginning of external activity A and puts a token into place
pl. This marking does not change until A is not ended: when it
happens, a token is automatically inserted into control place cp,
allowing the firing of transition tl which inserts a token into
place p2; the presence of a token inside pz means that the
considered activity is ended. The labelled and controlled Petri
subnet which models a branching (element directed to the check
of a condition or a choice, in the left side of figure 7) is
represented in the right side of figure 7. The firing of labelled
transition tl models the command of starting the check of
condition C: it inserts a token into place pI and allows the
beginning of checking; the token inside p1 means that the check
of C is in progress. As soon as the check ends, a token is
automatically inserted into control place cp, or into control place
cp2 if the considered condition or choice has been verified
negatively or not, respectively. According to the result of check,
one among transition t2 and transition t3 is fireable: the evolution
of the subnet will then go on with a token inside place pz
(meaning that the check is ended and the check itself had a
negative outcome) or with a token inside p3 (check ended with
positive result).

Fig. 4 - Petri subnet which models initial state

+ t8--b
PI

Pz

Fig. 8 - Petri subnet which models a forking

Fig. 5 -Petri subnet which models an action state
The labelled and controlled Petri subnet which models an initial
state (figure 4) is composed by only one control place. Every
time the modeled activity has to be performed, a token is
automatically inserted into the control place cp, and the
execution of the net can start. In the right side of figure 5 is
represented the labelled and controlled Petri net which models an

Fig. 9 - Petri net which model a joining

To model forking and joining through labelled and controlled
Petri subnets, two very simple subnets can be used (figures 8 and
9). The firing of transition tl in the right side of figure 8 puts

III - 1045

Authorized licensed use limited to: Universitaet Bielefeld. Downloaded on April 20,2010 at 05:16:17 UTC from IEEE Xplore. Restrictions apply.

both a token into place p, and a token into place p2. In such a
way, it is possible to begin the execution of actions or activities,
which have to be carried out in concurrent way. Transition t, in
the right side of figure 9 can only be fired if both places which
precede it have tokens (such a concept will be much evident after
the presentation of the UML activity diagram synthesis
procedure) and the inserting of a token into place p1 means that it
is possible to go on with the following function or activity.
Multiple triggers (the execution of a function more than once)
can be considered as the series of an action state and a branching
(figure IO) which takes up the role of exit condition. If it is no
more necessary to carry out function F (condition C verified) the
execution can proceed with the remains of activity diagram.
Whereas if F have still to be performed (condition C not
verified) the flow returns to the action state to carry out again the
considered function. From a modeling point of view, the labelled
and controlled Petri subnet that represents a multiple trigger
(right side of figure 11) is the synthesis of the subnet that models
an action state and the one which models a branching (compare
figure 1 1 with figures 5 and 7). The only differences are in the
existence of transition t, and place pI (necessary to properly
route tokens) and of directed arc among transition t3 and pI
(necessary to immediately perform again F when the exit
condition has negative result).

The UML Activity Diagram Synthesis Procedure

In the previous part of the current paragraph, It has been shown
how it is possible to model all UML activity diagram
components through labelled and controlled Petri subnets. In
order to obtain the final net which models an UML activity
diagram, it is necessary to develop a procedure directed to join
all subnets together. Such a UML activity diagram synthesis
procedure is constituted by the following steps:
1. in the first step all indipendent parts inside the UML activity
diagram have to be recognized. In this way, the diagram is
no more considered as a whole structure, but as a set of
structures logically connected between them;
2. now, it is possible to substitute the diagram representation
with the labelled and controlled Petri subnets previously
defined which model the recognized parts. The obtained
structure is a set of separate subnets;
3. in the third and final step all subnets have to be actually
joined together. Such an operation is performed opportunely
adding arcs to connect all subnets. One can note that all the
defined labelled and controlled Petri subnets start with a
transition (labelled or not) and end with one or more places
(controlled or not, see figures 4 to 9, 1 I , and 12). In this way,
to connect two consecutive parts, it is only necessary to put
an arc which comes from the end place of the subnet
modeling the former part and which goes to the start
transition of the subnet modeling the latter part. At the end of
this step, the whole labelled and controlled Petri net has been
produced.
6.

The Information System DEsign Support system has a great

sphere of application. First of all, the overall tool has been
designed thinking about needs usually relevant in the
management of production processes and, more precisely, of
flexible manufacturing systems. In fact, a typical field in which
information system technology has been widely used is the
representation (in terms of systems specifications), monitoring
and control of production processes. In particular, an IS should
be used both to collect and store data about production and to
elaborate such data in order to lead the behavior of the system
according to the needs. According to such a consideration, we
the development of a CASE tool seemed quite important. But it
is immediate to think about further applications of ISYDES:
adding opportune predefined libraries seems very simple to
extend such a tool in order to develop ISs directed to, for
example, the management of other kind of systems, such as
logistic systems or communication ones.

(FALSE

Fig. 10 - Multiple triggers as conditioned loop

,;zT
I*

It,

OP,

Fig. 1 1 - Petri subnet which models a multiple trigger

The last UML activity diagram element considered is the final
state. The labelled and controlled Petri subnet which models a
final state is made up of labelled transition It, and of place p,: It,
allows to give the execution to other UML activity diagrams and
puts a token into p l ; such a token means that the whole modeled
UML activity is ended. The UML activity diagram synthesis
procedure can be now presented.

Fig. 12 - Petri subnet which models a final state

APPLICATIONS AND FUTURE DEVELOPMENTS

As an example, a simple application is presented which makes

clear the meaning of conceptual functional design and explains
how the labeled and controlled Petri net which models the
presented activity could be obtained. The activity in question is
relative to the building of houses: the UML activity diagram is
represented in figure 13 and such a diagram is the one that has to
be drawn by an ISYDES user to implement the activity building
of a house inside an hypothetical information system directed to
the management of companies which operate in a construction
context. Furthermore observe that the presented activity [4]is an
extreme simplification of what really is a construction process,
but it is very suited for our purposes. The UML activity diagram
is created thinking about the sequence of operations which have
to be performed: first of all, the company selects a site where
build the house, then the project is commissioned to an architect
that develops construction plans until one is accepted; now, it is
possible to begin the real building phase which can be

HI - 1046

Authorized licensed use limited to: Universitaet Bielefeld. Downloaded on April 20,2010 at 05:16:17 UTC from IEEE Xplore. Restrictions apply.

partitioned into the parallel function do site work and do

trade work; once both are ended it is possible to finish the
construction.

As future developments of the present work, the authors assume

that will be interesting to extend ISYDES tool in a way that will
be possible to generate ISs not only characterized by a relational
logical model. Through a dialog window it could be possible to
select the kind of logical model. As it can be easily observed, the
natural extension of the proposed CASE tool is for the design of
00-based information systems. Including in ISYDES
appropriate translation procedures such a tool could be highly
generalized, making it utilizable with different kinds of database
management systems.

Select sue

c
archfiecl

Develop

Develop

1
Do site

Do trade
work()

work

are the ones from cpl to Itl, from p2 to It,, from p4 to t3, from p9
to t,, from ploto It,, from pI1to It,, from p13 to tlo,from pls to tlo,
from pI6 to It, and, finally, from pI8 to It,. After this step, the
considered activity has been completely modeled through a
labelled and controlled Petri net.

ld

In this paper, the authors presented a methodology to develop

ISs, without refering to a particular class of problems: then, from
an applicative point of view, the working out of a set of libraries
directed to the IS development for particular kinds of systems as,
among other things, production systems, logistic systems and
communication ones has been hypothesized.

Ycpi

REFERENCES

Finish
construction

Fig. 13 - Example of UML activity diagram

.PP2
i
Ps

Fig. 14 - Petri net which models the example diagram

As mentioned in the previous paragraph, the labeled and
controlled Petri net which models such an activity is obtained
through the joining of all subnets which model each UML
activity diagram element. With reference to figure 14, control
place cp, models the initial state, action state select site is
modeled with nodes (places, control places, transitions or
labelled transitions) from Itl to p,, action state commission
architect is modeled with nodes from It, to p4, nodes from t3 to
p9 model the multiple trigger which includes action develop
plan and the check on acceptance, transition t7 and places plo
and pl I model the forking, action state do site work is modeled
with nodes from It, to pI3, activity state do trade work is
modeled with nodes from It, to pi,, transition tlo and place pI6
model the joining, action state finish construction is modeled
with nodes from It, to pI8and, finally, labelled transition It, and
place p I 9model the final state. Now, as stated in the third step of
UML activity diagram synthesis procedure, it is only necessary
to add arcs to connect all subnets: arcs which have to be added

R. Barker, C. Lovyman, CASE* Method: Function and

Process Modelling, Wokingam, UK: Addison Wesley,
1992.
A. Boccalatte, D. Giglio, M. Paolucci, An Approach to
Information System Management based on Relational
Databases and Petri Net Integration, Proceedings of the
1998 IEEE International Conference on System, Man, and
Cybernetics, IEEE, 1998, pp. 220-225.
A. Boccalatte, D. Giglio, M. Paolucci, An ObjectOriented Modeling Approach based on Entity-Relationship
Diagrams and Petri Nets, Proceedings of the 1998 IEEE
International Conference on System, Man, and
Cybernetics, IEEE, 1998, pp. 1347-1352.
G. Booch, J. Rumbaugh, I. Jacobson, The Unified
Modeling Language User Guide, Addison Wesley, 1998.
B. P. Douglas, Real Time UML, Addison Wesley, 1998.
L.E. Holloway, B.H. Krogh, A. Giua, A Survey of Petri
Net Methods for Controlled Discrete Event Systems,
Discrete Event Dynamic Systems: Theory and
Applications, Vol. 7, Boston, MA: Kluwer Academic
Publishers, 1997, pp. 151-190.
A. Ichikawa, K. Hiraishi, Analysis and Control of
Discrete Event Systems represented by Petri Nets,
Discrete Event Systems: Models and Applications, Lecture
Notes in Computer Sciences, Vol. 103, New York, NY:
Springer Verlag, 1988, pp. 1 15-134.
B.N. Krogh, Controlled Petri Nets and Maximally
Permissive Feedback Logic, Proceedings of the 25*
Anmal Allerton Conference, 1987, pp. 3 17-326.
T. Murata, Petri Nets: Properties, Analysis and
Applications, Proceedings of the IEEE, Vol. 77, No. 4,
April 1989, pp. 54 1-580, Invited Paper.
M. Silva, Practice of Petri Nets in Manufacturing, Chapter
1, London, UK: Chapman & Hall, 1993, pp. 1-62.
S. Woodfield, The Impedance Mismatch Between
Conceptual Models and Implementation Environments,
Proceedings of the ER97 Workshop on Behavioral Models
and Design Transformations: Issues and Opportunities in
Conceptual Modeling, November 1997.

IlI - 1047

Authorized licensed use limited to: Universitaet Bielefeld. Downloaded on April 20,2010 at 05:16:17 UTC from IEEE Xplore. Restrictions apply.