Educational process based on real life case. It was designed using well-known modeling languages as BPMN and UML. The Bizagi environment for implementation.

1. PROCESS AND SERVICE MODELING ANALYSIS
Gestione Missioni DIAG
Simone Agostinelli 1523559
Matteo Stabile 1547019
CONTENTS
1 General description of the process 2
2 BPMN formalization of the process 3
3 UML Class Diagram and Artifact 4
4 Data manipulation part 5
5 Implementative choices 6
5.1 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 Bizagi studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6 General description of software operation 7
7 Used tools 10
1

2. 1 GENERAL DESCRIPTION OF THE PROCESS
We are interested in managing missions of the DIAG department. Among all the potential
subjects that can perform a mission we are interested to just professors. Each mission must be
preliminary authorized. A professor must compile and deliver the related request module as
expected by ordinance in art. 5 comma 8. In particular this provides the following data to be
inserted:
1. Biodata of professor,
2. Destination of the mission,
3. Start date and time,
4. End date and time,
5. Mission goal that hopefully explains the reasons about mission functionality,
6. Means of transport used,
7. Fund on which the mission is based.
The ordinance has to be delivered to missioni@diag.uniroma1.it which will occupy to deliver
that request module to the Direttore del Dipartimento, to the Responsabile Amministrativo
Delegato (RAD) , to the Responsabile dei fondi and to the Giunta del Dipartimento. These
subjects will have to verify:
1. Financial availability on the specified fund by RAD and Responsabile dei fondi;
2. Teaching suspension, if requested, in that period by Giunta del Dipartimento;
3. Mission adequacy by Direttore del Dipartimento itself.
Therefore, who signs the request module compiled by professor is:
1. Direttore del Diparitmento;
2. Responsabile dei Fondi;
3. Giunta del Dipartimento in the case that professor has requested teaching suspension.
If the professor asks for the usage of special means (taxi or rented means) it has to be accepted.
If he/she specifies that wants to use own means, 24 hours before mission starts he/she has to
send the insurance benefit to missioni@diag.uniroma1.it (previously requested). This latter
will provide to authorize the own means usage as reported in article 8 of the ordinance. For
foreign missions, the professor may ask the alternative treatment instead of the reimbursement
request at the mission request time. The alternative treatment computation is performed
by missioni@diag.uniroma1.it. If the professor requires a mission variation (before going in
mission but after the Direttore has already accepted the first authorization module) then it
has to fill the provided field in the expected module and deliver anew that request which will
2

3. have to be signed by all the subjects mentioned above. In the case the professor requests the
preview of 75 % of the expenses he/she has to carry out to give an estimation of total mission
cost. This preview can be granted at least 30 days before the mission starts. Furthermore,
if the mission is not performed that preview has to be paid back. The preview cannot be
given to someone who has debts with University (for the law).missioni@diag.uniroma1.it
will decided wheter granting it or not. Whenever the granted preview will be greater than
the effective total cost of the mission requested in the reimbursement, the professor will
have to give back the difference. At the end of the mission, the professor can start with the
reimbursement request procedure (if he/she did not requested the alternative treatment). The
reimbursement has to contain a detailed description of all the expenses. Afterwards it has to
be sent to missioni@diag.uniroma1.it again within 6 months after the end of mission (with
related invoices). In the case that the mission has been not performed the professor has to
provide to cancel all the reservations and he/she can request a reimbursement without already
repaid expenses.
2 BPMN FORMALIZATION OF THE PROCESS
In the process formalization we identified four different pools:
1. Professore: represents the workflow of a single professor that requests, performs and
asks for the reimburse of a mission;
2. missioni@diag.uniroma1.it: represents what the responsible of missions management
has to do in order to allow professors to go in mission;
3. Controllori: this is the complex one and involves three lanes referred to Direttore, Re-
sponsabile amministrativo delegato and Responsabile dei fondi. These subjects occupy
to check whether all the conformance principles are satisfied;
4. Giunta del dipartimento: represents the workflow that is triggered just whether a teach-
ing suspension is requested by professor.
We preferred to put out the pool Giunta del dipartimento just because it seems more logical
than putting it into the Controllori pool as a lane. In fact, Giunta is activated not every time as
it would be a seprated entity (that has to meet) for special cases.
What we can think to do is ideally dividing the process execution over time. Therefore we can
identify two scenarios:
1. mission authorization scenario where all the system parts work in order to allow profes-
sor to go in mission;
2. reimbursement reception where all the parts work in order to grant the expenses reim-
bursement to the professor.
With this in mind we want to point out the usage of data objects and database ones in the
model. We have just two data objects:
3

4. • Richiesta autorizzazione that regards the first time moment of our process (as described
before) and it passes thorugh activities until its state becomes ”approved" or ”rejected".
• Modulo liquidazione that is referred to the second part of the process and it passes
through activities till its state becomes ”verified".
As last observation the database object. We represent just one database named ”Missioni DB".
Later on this document we are going to explain how it is composed. The process control flow
can be expressed as the BPMN diagram in figure 2.1 .
3 UML CLASS DIAGRAM AND ARTIFACT
We want to represent data requirements as UML Class Diagram, shown in the figure 3.1. About
this schema we want to point out just one consideration:
we chose to represent the own means of professor as a proper class that belongs to the
disjointed and completed set of generalized classes of transport means. This because
actually, Straordinario and Normale should identify a categorical information without
any other deeper details (so it is useless to model the categorical information as classes
like Mezzo Proprio). For this reason, since Mezzo Proprio has many other information
to be managed, we model it as a class.
Now we have to link the two models: this means that every atomic activity and every message
payload must be captured in terms of UML Class Diagram. For this reason we have to set the
Artifact as shown at the end of this paragraph. The artifact is the set of process variables used
to store some extra information in order to properly carry out the process itself. For example,
in our case, the artifact is based on:
• all the boolean variables in charge of taking decisions over BPMN model gateways, in a
way that they allows to decide the correct branches to take at each time.
• A reference to an instance of Missione from which we can navigate through the entire
diagram.
• One variable referred to the effective chilometers to be confirmed by professor.
• A float field to hold the possible case in which the expenses preview will not be used
entirely and then it will be paid back to the fund.
Now we have in place the entire information model made up by UML class diagram and the
artifact itself.
4

5. 4 DATA MANIPULATION PART
For a correct representation of the process, we created a database involving two tables:
• Professore formed as follows:
• Fondo formed as follows:
First of all, these two tables are the only ones to be used during the execution of our system. As
shown in the BPMN model (figure 2.1) there are some activities perform actions on database
5

6. tables. The first one is when RAD checks the financial availability for mission and affects the ta-
ble Fondo veryfing the field totale. The second one occurs when at missioni@diag.uniroma1.it
the professor debt situations gets verified. On the other hand write operation on tables occur
in several other activities as, for instance, Restituisci anticipazione, Calcola rimborso, Restitu-
isci differenza, Calcola trattamento alternativo and Concedi anticipazione that affect tables
depending on the particulare situation. On the implementation point of view we imported the
two cited entities directly from database (as replicated entities), in the Bizagi studio project.
5 IMPLEMENTATIVE CHOICES
5.1 WEB SERVICES
We integrated three Web Services in order to improve the usability of the software. These
services are:
• MezzoProprioWS: it is in charge of handling the request of own means usage. The idea
is that at the end of mission each professor that used its own means must confirm the
total amount of chilometers made.
• CancellazionePrenotazioni: it is in charge of better handling the mission annulation
requested by professor. In particular, it simulates the cancellation of reservations for
accomodation, meals and travel. Furthermore, it gives back to the professor an amount
of reimbursement (later on, we are going to explain how).
• CoperturaAssicurativaWS: it is in charge of handling the own means insurance benefits
that university has to send to professor in order to complete all the needed documenta-
tion.
The protocol we used for realizing these Web services is SOAP. The platform used for developing
is NetBeans integrated with Tomcat.
5.2 BIZAGI STUDIO
We used Bizagi studio as environment for developing the final product. Due to implementative
needs we moved our BPMN model in a single pool differentiating among lanes. In this way,
all the message exchanged between different pools have been deleted. This brings several
semplifications by preserving the sense of the process (as shown in figure 5.1). On the other
hand as already shown in figure 4.1 we built a model data by following some principles that in
somewhow Bizagi dictates. The decoupling degree between UML class diagram and Bizagi
model data is due to the fact that actually Bizagi is not interested specifically to the UML
relations. It is interested to relations among process variables we have. More precisely it is
interested to model those relations that allow us to compute all the information we need.
Actually we want to point out some important differences between what is represented in the
original BPMN modeler and what is on the unified one:
6

7. • we could not properly handle the timer event on the activity Richiedi copertura assi-
curativa since the simulation environment of Bizagi Modeler seems to leave out some
tokens (it is a technical issue of Bizagi itself).
• The same activity did not stay within the Bizagi Studio model as we implemented its
functionalities by means of web service and therefore we encapsulated it into Consegna
copertura assicurativa.
• We did not model the timer over activity Missione in the original BPMN model while
we did model it in the unified one for implementative reasons (in order to handle the
duration of the mission itself).
• We assumed that missioni@diag.uniroma1.it decides how much is the reimbursement
amount by hand instead of automating all the mechanism.
6 GENERAL DESCRIPTION OF SOFTWARE OPERATION
In order to describe how the system works we have to start from notice that each single subject
of the system will log in with its own credentials. Therefore we are going to describe how
generally a mission has to be requested and reimbursement as well.
First of all, a professor that wants to request a mission has to fill all the fields of request starting
from its own biodata:
The system provides a search mechanism in order to find itself within the table Professore just
by typing own surname and automatically all the fields will be filled. Afterwards the professor
has to insert information about mission in the part that follows:
7

8. Notice that fields in this part are all requested therefore it is needed to insert them in or-
der to go on in the workflow. Next step consists on choosing whether hanging didactic work
or not. This is possible by selecting the suited field and eventually choosing the substitute
professor as done for the first step in the database table:
Now it is the moment to give information about economical aspect of mission by select-
ing the fund that the mission will affect, again by searching on the Fondo database table. On
the other hand, there exists the possibility to request the expense preview or not (and it is
requested to chose):
8

9. Last choice the professor has to do is to select which means to be used for the mission among
ordinary, special ones and own means:
Notice that all the presented field belong to one single form the professor has to fill when
he/she starts the system.
Now that all the information have been collected, the mission request will be sort to all the
other subjects of the system. Each of these entity has its own goal depending on the professor
choices. It is important to notice that whenever one subject (among Controllori) decides to
refuse the mission for some reason, the professor will receive the related motivation and the
process ends. At this point we expect that professor goes in mission. The system will provide to
him/her the possibility to interrupt the mission before the expected end date. Regardless this
possibility, the professor is going to be able to ask the expense reimbursement. In particular,
the reimbursement module is made up by the following information:
Here the professor has to state whether he/she used train or airplain for foreign mission
and specify boarding and landing time with related boarding pass. Second requested action
for who is filling the module is to give information about expense details as, for instance, about
travel expenses:
9

10. Notice that this details are present for each single kind of expenses about a mission (vari-
ous, overnight and meals). At the end of this module the professor automatically can calculate
the total cost of the mission and send the reimbursement request. On the other hand if he/she
requested the alternative treatment on authorization time, this form will not have to be filled.
In fact, in that case, professor has to just specify which means he/she used during mission and
the reimbursement will be calculated.
When whatever kind of reimbursement will be approved, professor will receive the related
notification and the system will end.
Last but not least we want to point out that there exists both the possibility that professor does
not ask for reimbursement and the possibility that the reimbursement will not be granted.
7 USED TOOLS
In addition to Bizagi (for implementing the BPMN model), we used these other tools:
• Modelio for the UML class diagram and Artifact.
• Netbeans integrated with Tomcat for developing the web services.
Moreover, we used SQLEXPRESS Server for building the database Missions.
10

11. Figure2.1:BPMNschema
11

12. Figure3.1:UMLschema
12

13. Figure4.1:Datamodelschema.NoticethatweusedthenameArtefattoinordertomarkthatactuallythatentityistotallyunrelated
fromtheentiredomain.
13

14. Figure5.1:UnifiedBPMNmodel
14