EXAMEN

Semestre : 1 2
Session : Principale Rattrapage

Module : Langage de modélisation UML

Enseignant(s) : Équipe UML
Classes : 3ème année A
Documents autorisés : OUI NON Nombre de pages : 1
Calculatrice autorisée : OUI NON Internet autorisée : OUI NON
Date : 06-01-2020 Heure :15h00 Durée : 1h30

Étude de cas :

Une plateforme web « UnTokTok » de réservation de voitures tricycle « toktok » offre à ses
clients la possibilité de réserver un « toktok » avec chauffeur professionnel. Le chauffeur est
choisi en fonction des deux critères : le nombre d’années d’expérience et sa note d’évaluation.
Cette plateforme est accessible en temps réel via un « PC » ou un smartphone connecté.

Un internaute s’inscrit sur la plateforme en tant que chauffeur ou client. Le chauffeur est un
propriétaire du « toktok ». Il s’inscrit en introduisant le numéro de CIN, le numéro du permis
de conduire ainsi qu’une photo. Il fournit aussi toutes les informations nécessaires sur son
« toktok » : le numéro d’immatriculation, la marque du toktok, la date de la mise en
circulation et une copie de l’assurance. Le client quant à lui s’inscrit en introduisant son mail,
son mot de passe et son numéro de téléphone.

Pour chaque réservation qu’il souhaite effectuer, le client intéressé est tenu de renseigner le
jour et l’heure de rencontre ainsi que le point de départ et le point d’arrivée. Il consulte, par la
suite la liste des « toktok » proches et disponibles renvoyée par le système. Si la liste n’est pas
vide, le client finalise son choix en sélectionnant le « toktok » qui lui semble le plus adéquat.
En cas de réservation, le système notifie le chauffeur qui a la possibilité de la valider ou de la
refuser.

Le jour convenu, en cas de retard du chauffeur par rapport à l'heure précisée, il doit notifier le
client via le système.

Le client peut annuler une réservation validée en précisant les raisons de son annulation.
L’administrateur de la plateforme a le droit de désactiver le compte client si ce dernier annule
plus de trois réservations validées.

Tous les utilisateurs accèdent aux services de la plateforme en se connectant avec un login et
un mot de passe.

Travail demandé :

1. Élaborer un diagramme de cas d’utilisation de la plateforme « UnTokTok ». (5 pts)

2. Élaborer un diagramme d’activités lié au processus de réservation d’un « toktok ». (3 Pts)
3. Élaborer un diagramme de séquence objets du processus « Réserver un toktok » en suivant
une architecture en couches. (4 pts)
4. Déduire une partie du diagramme de classes de conception. (5 pts)
5. Proposer un diagramme de déploiement sachant que les utilisateurs des appareils mobiles
doivent installer le fichier « UnTokTok.apk », la base de données «UnTokTok.sql » est
déployée sur un serveur de base des données indépendant alors que le reste de
l’application «UnTokTok.war » est déployé sur le serveur web « Sun Java System Web
Server ». (3 pts)
1
 On désire réaliser une application pour la gestion des Rapports Quotidiens de Vol
(RQV) de véhicules dans les départements de police, via le web.

On distingue initialement deux types d’utilisateurs pour ce système : les victimes

et les témoins. Chacun de ces utilisateurs peut créer une déclaration de vol, en y
indiquant son rôle (victime, témoin ou bien les deux), ses informations personnelles
(son n°CIN, nom, prénom, adresse, tél), le type de la propriété volée (véhicule à
moteur ou bien bicyclette) ainsi que les différentes informations disponibles qui
l’identifient (couleur, marque, numéro de série pour les bicyclettes, matricule pour
les véhicules à moteur, description générale), la date, l’heure et le lieu (avec tous les
détails disponibles : n° de la rue, ville, code postal,…) du vol.

Le système attribue à chaque déclaration un identifiant, que l’utilisateur peut

utiliser pour pouvoir éditer la déclaration (ajouter des informations, supprimer la
déclaration), avant de sauvegarder la déclaration. Le système doit enregistrer, pour
chaque déclaration, la date de sa dernière modification.

On distingue également un autre type d’utilisateurs : l’agent policier qui se charge

de la création des Rapports Quotidiens de Vol. Un RQV est relatif à une date
particulière, il contient toutes les déclarations de vols effectuées ou bien modifiées
dans ce jour. Lorsqu’un véhicule déclaré est retrouvé, l’agent policier modifier l’état
de la déclaration concernée. Evidemment, l’agent policier doit s’authentifier pour
pouvoir accéder à cette application.

On désire déterminer pour chaque RQV la liste des nouvelles déclarations, la liste
des déclarations mises à jour, ainsi que les déclarations qui ont été résolues.

1. Décrire les différentes fonctionnalités de ce système en utilisant un diagramme

de cas d’utilisation
2. Décrire la structure de ce système en utilisant un diagramme de classe
3. Représenter les diagrammes de séquences correspondant aux fonctionnalités
suivantes :
a. Créer une nouvelle déclaration

:UINlleDeclarati :Gestion de Creation de

: Utilisateur
on Declarations

saisir rôle

saisir info perso

saisir info vehicule

valider

enregistrer Declaration

créer

N : Déclaration

déclaration créée
afficher msg

b. Créer un rapport quotidien de vol

 :UI :Gestion :Declaration
: Agent
CreationRQV Creation RQV

creerRQV
creerRQV
getNllesDeclarations(date actuelle)

getmàjDeclaration(date actuelle)

créer() : RQV

RQVcréé

afficher msg

4. Représenter le diagramme d’états / transitions de l’objet « Déclaration »

Module : Méthodes de Conception OO Institut Supérieur d'Informatique
Niveau : 2ème année ARS Année Universitaire : 2010-2011
Enseignants : N. Zoubeir, L.Sfaxi

MÉTHODES DE CONCEPTION OO
EXAMEN PRINCIPAL

NB: La propreté de la feuille sera notée sur 2 points.

Exercice 1 (4 pts)
Soit le diagramme d'objets suivants:

Proposer le diagramme de classes correspondant.

Problème (14 pts)

On désire réaliser une application pour la gestion des Rapports Quotidiens de
Vol (RQV) de véhicules dans les départements de police, via le web.

On distingue initialement deux types d’utilisateurs pour ce système : les

victimes et les témoins. Chacun de ces utilisateurs peut créer une déclaration
de vol, en y indiquant son rôle (victime, témoin ou bien les deux), ses
informations personnelles (son n°CIN, nom, prénom, adresse, tél), le type de la
propriété volée (véhicule à moteur ou bien bicyclette) ainsi que les différentes

Meth. de Conception OO Page 1/2

Examen Principal 2010-2011

informations disponibles qui l’identifient (couleur, marque, numéro de série

pour les bicyclettes, matricule pour les véhicules à moteur, description
générale), la date, l’heure et le lieu (avec tous les détails disponibles : n° de la
rue, ville, code postal,…) du vol.

Le système attribue à chaque déclaration un identifiant, que l’utilisateur peut

utiliser pour pouvoir éditer la déclaration (ajouter des informations, supprimer
la déclaration), avant de sauvegarder la déclaration. Le système doit
enregistrer, pour chaque déclaration, la date de sa dernière modification.

On distingue également un autre type d’utilisateurs : l’agent policier qui se

charge de la création des Rapports Quotidiens de Vol. Un RQV est relatif à une
date particulière, il contient toutes les déclarations de vols effectuées ou bien
modifiées dans ce jour. Lorsqu’un véhicule déclaré est retrouvé, l’agent policier
modifier l’état de la déclaration concernée. Evidemment, l’agent policier doit
s’authentifier pour pouvoir accéder à cette application.

On désire déterminer pour chaque RQV la liste des nouvelles déclarations, la

liste des déclarations mises à jour, ainsi que les déclarations qui ont été
résolues.

1. Décrire les différentes fonctionnalités de ce système en utilisant un

diagramme de cas d’utilisation

2. Décrire la structure de ce système en utilisant un diagramme de classe

3. Représenter les diagrammes de séquences correspondant aux

fonctionnalités suivantes :

a. Créer une nouvelle déclaration

b. Créer un rapport quotidien de vol

4. Représenter le diagramme d’états / transitions de l’objet « Déclaration »

Bon Travail

Meth. de Conception OO Page 2/2

UML REFERENCE CARD E.g.: Associations (relationships between classes) Implementation Inheritance
Some_class «abstract»
{ author: George Jetson 1..* relationship 1..* SuperClass
modified: 10/6/2999 A A’s role in B B’s role in A B
- void concrete();
© 1998 Allen I. Holub. All Rights Reserved. checked_out: y + int override();
• Associated classes are connected by lines.
}
• The relationship is identified, if necessary, with a < or
Available from <http://www.holub.com>. • Guillemets identify stereotypes. E.g.: «static»,
> to indicate direction (or use solid arrowheads). SubClass
«abstract» «JavaBean». Can use graphic instead of
• The role that a class plays in the relationship is identi- + int override();
word.
fied on that class's side of the line. + int additional();
Static Model Diagrams • Access privileges (see below) can precede name.
• Stereotypes (like «friend») are appropriate. Outline arrows identify derivation relationships: extends,
• Inner (nested) classes identify outer class as prefix
• Unidirectional message flow can be indicated by an implements, is-a, has-properties-of, etc. Variations include:
of class name: (Outer.Inner or Outer::Inner).
arrow (but is implicit in situations where there is only
Packages 2. The attributes compartment (optional):
one role):
• During Analysis: identify the attributes (i.e. defin-
ing characteristics) of the object. Sender Receiver
• During Design: identify a relationship to a stock
Java.awt class. • Cardinality:
com.hulub
This: 1 Usually omitted if 1:1
Application
Person n Unknown at compile time, but bound.
Tools String name; 0..1 (1..2 1..n)
Interface Inheritance
1..* 1 or more
Oracle
Database
Interfaces is a more compact (and less informative) version of * 0 or more User
this:
• Example: f() { x.operation() }
Sybase
Person String Company relationship
give_me_a_raise(Employee e) x
• C++ namespace. name Implementer Iface Name
• Group together functionally-similar classes. operation()
• Derived classes need not be in the same package. Everything, here, is private. Always. Period. Employee
boss
operation()
1 <works for 1..n you_re_fired()
• Packages can nest. Outer packages are sometimes 3. The operations compartment (optional) contains employer peon
1

method definitions. Use implementation-language In C++, an interface is a class containing nothing but pure
called domains. (In the diagram, “Tools” is arguably 1..* flunkies
syntax, except for access privileges: virtual methods. Java supports them directly (c.f. “abstract
an outer package, not a domain).
class Company class,” which can contain method and field definitions in
• Package name is part of the class name (e.g. given the + public { addition to the abstract declarations.)
class fred in the flintstone package, the fully-qualified private Employee[] peon = new Employee[n];
# protected
class name is flintstone.fred). public void give_me_a_raise( Employee e ) { ... }
- private } My extension to UML: rounded corners identify interfaces.
• Generally needed when entire static-model won’t fit
If the full interface specification is in some other diagram, I
on one sheet. ~ package (my extension to UML) 1
class Employee use:
{
Classes (Box contains three compartments) • Abstract operations (C++ virtual, Java non-final) private Company employer; Implementer Name User
indicated by italics (or underline). private Employee boss;
private Vector flunkies = new Vector(); Strict UML uses the «interface» stereotype in the name
Class name • Boldface operation names are easier to read. public void you_re_fired() { ... }
Attributes: compartment of a standard class box:
}
If attributes and operations are both omitted, a more com- InterfaceName
«interface»
Operations: plete definition is assumed to be on another sheet. (A Java Vector is a variable-length array. In this case it
Operations
will hold Employee objects)
1
Java, unfortunately, defaults to “package” access when no modifier is present. In my Interfaces contain no attributes, so the attribute compart-
“flavor” of UML, a missing access privilege means “public”. ment is always empty.
1. The name compartment (required) contains the class
name and other documentation-related information:
Aggregation (comprises) • In official UML, put arbitrary constraints that affect • Top boxes represent objects, not classes. You may Loops (extension to UML)
more than one relationship in a “comment” box, as optionally add “:class” to the name if desired.
Whole Part shown. I usually leave out the box. • Vertical lines represent the objects “life line”, or exist- Sender Every
• Destroying the “whole” does not destroy the parts. ence. do_it() Receiver
Qualified Association • Broken lifeline indicates the object is inactive, a rect-
• Cardinality is allowed.
angle indicates the object is active. message()
User
Composition (has) relationship • represent messages being sent.
add(String key, key Item
Item value) bag • (optional if synchronous) represent method
Container Item
role return. (May label arrow with name/type of returned • Don’t think loops, think what the loop is accomplish-
• Hash tables, associative arrays, etc. ing.
object).
• The parts are destroyed along with the whole. • Typically, you need to send some set of messages to
• Sending object’s class must have:
• Doesn’t really exist in Java. class User
every element in some collection. Do this with every.
{ 1. An association of some sort with the receiving
• In C++: • You can get more elaborate (every receiver where x<y)
// A Hashtable is an associative array, indexed objects class.
// by some key and containing some value. • The diagram above comes from:
class Container private Hashtable bag = new HashTable();
2. The receiver-side class’s “role” must be the same as
{ the name of the receiving object. sender_class receiver_class
Obj item1; private void add(String key, Item value) { 1 n
Obj *item2; void do_it() void message()
bag.put(key, value); Object Creation sender receiver
public: }
Whole() { item2 = new Obj; } }
~Whole(){ delete item2; } Sender
and maps to the following code:
};
Association Class class sender_class
new {
Constraint <travels on Receiver receiver_class receiver[n];
Airline Person
carrier passenger public do_it() {
Item for(int i = 0; i < n; ++i)
{ordered}
Container receiver[i].message();
role Identity key() Ticket }
• The new instance appears at end of creation message
Date when; <buys }
Seat where; arrow.
Container Airport to; • Destruction is accomplished by terminating the lifeline
Collection {or} Airport from; Arrow Styles for Messages
with a large X:
Container
Sender
• Use when a class is required to define a relationship. Symbol Type Description
* member-of *
• Somewhere, an additional relationship is required to Simple Don’t care. Usually read as the
Comittee {subset} Person new
show ownership. (The one between person and Ticket Receiver same as synchronous.
chair-of *
1 in the current example).
message() x Synchronous Sender blocks until return.
employee employer Asynchronous Handler returns immediately and
Comittee * 0..1 Comittee Dynamic-Model (Sequence) Diagrams both sender and receiver work
simultaneously.
0..1 *
Objects and Messages (new style) Conditions
boss peon Asynchronous Callbacks
{person.employer ==
Person.boss.employer} Sender Receiver
Sender Receiver
Sender Receiver

[cond_expr] message()
message() message()
• A constrained relationship requires some rule to be
applied (e.g. {ordered}). Often combined with aggre- callback()
gation, composition, etc.
message() • Message sent only if conditional expression is true.
• In the case of {or}, only one of the indicated relation-
• The cond_expr is typically expressed in the imple-
ships will exist at any given moment (a C++ union, or
mentation language. • Callback occurs while Sender is potentially executing
reference to a base class).
something else.
• {subset} does the obvious.
 UML Quick Reference Card
Copyright © 2001 Laurent Grégoire

Class diagram Composition Active Class Collaboration diagram

EventQMgr
Class
Maths
Dependency Event + post(e : Event) Name
+ suspend( )
+ BigInteger
Abstract Class − flush( )
+ Fractional
Window Package + Trigonometrics
Visibility Signature
Random
+ postEvent(Event)
# processEvent(Event) Windows should
not implement
Event processing + RandomGenerator
Abstract operation Specialization Dependency
Class Name Interface realization Note − RandomSeed
Package content
Frame Interface
+ menuBar : MenuBar MenuContainer «import»
Attributes
+ setTitle(String) Association
Import dependency
+ remove(Menu)
Aggregation
Simulation
Operations # paramString( ) : String

Responsabilities : MenuBar
*
− Manage a MenuBar NeuralNetwork
− Process events MenuItem
Extra compartments Generalization

Component diagram State diagram

Name Realization
Component Final state
Interface
libjpeg.so Nested state
State
{version=62.0.0} Displayable off / Reset
Decode.o mode
on Hour editing
XUtils.o Time keeping
Tagged value decoder.cfg
Utils.o watchdog / check( ) set [timeOk]
Initial state
Contents File Minute editing
set / setTime( ) Guard
Internal transition
decoder Time editing
(executable) Table Transition
Event
Action
states.tbl

Dependency

Sequence diagram

Object Anonymous object

Activity diagram Comm. subsystem a: AppCtrl : NetCtrl Callback
Object flow Initial a1 : hCom()
send(x) Object creation
state
: TMsg
Build message Sequence label
[ready] Call Temporary object
Concurrent fork Action «create»
Message : Socket
state
connect()
Focus of control
Inform application Send message send(x)
Return
«destroy»
Swimlane
Recursion
Concurrent join [timeout] Object destruction
Retry comm. Lifeline

Sequential branch [ack]

Final
state