projet module uml - e

Formation continue
MOD24
PROJET MODULE UML
Projet tuteuré
UVSQ
SUJET
Introduction.
Comme vu dans le cours, le langage UML est extensible et peut s'adapter à d'autres contextes et
paradigmes que celui stricto sensu de l'orienté objet. La formation que vous avez suivie est
traversée par trois axes majeurs. Le système Linux, les bases de données relationnelles et le langage
JAVA dans ses orientations technologiques pour applications d'entreprise (JAVA EE).
La frontière entre ces axes est très fine et perméable. Notamment dans le cadre de la
correspondance Objet-Relationnel (object-relational mapping) où la double compétence objet et
relationnelle est nécessaire pour avoir la maîtrise de cette technologie.
Ainsi dans les cahiers des charges des projets qui mettent en œuvre les solutions de mapping objet
relationnel, les concepteurs doivent être en mesure de modéliser l'un et l'autre de ces paradigmes
avec le langage UML. Cela est possible grâce à la notion de profil UML (voir les ressources
documentaires dans l'espace e-campus). Le travail que vous devez produire est une analyse d'un cas
d'étude avec une partie qui concerne les applications et une autre les données correspondantes
stockées dans une base de données relationnelle.
Mission à réaliser.
L'étude porte sur le cas décrit ci-dessous. Le travail consiste à en faire l'analyse et à en modéliser
d'un côté les classes des applications qui représentent les concepts métier et de l'autre les données
stockées dans la base de données qui représentent ces mêmes concepts.
SI
niveau abstrait
(système d'information)
applications
tables métier
classes métier
base de données
Les trois contextes peuvent être modélisés avec UML ; le niveau abstrait encore appelé diagramme
de domaine, le niveau applicatif avec le diagramme de classes et le niveau base de données avec le
diagramme de classes UML augmenté par un profil UML adapté.
JJLC
1/4
FC-UVSQ
Le cas TCR partie 1.
Vous faites votre stage dans la société de services du numérique Open&Free Software. Vous êtes
incorporé dans l'équipe projet qui est chargée de développer une application pour un des clients
d'Open&Free Software.
Ce client est l'entreprise TCR chargée des transports en commun d'une grande ville française.
L'application a pour nom « gestion des parcours des autobus ». Une première ébauche a été
réalisée par l'équipe projet. Et notamment le schéma relationnel de la base de données qui permet le
stockage du système d'information (SI) de l'application.
La gestion des parcours des autobus comprend deux fonctionnalités. La première est la gestion du
personnel. Cette dernière porte en particulier sur la gestion des conducteurs d'autobus.
La seconde fonctionnalité est la gestion de l'entretien. Elle porte sur l'entretien du parc d'autobus. Le
parc est constitué d'environ deux cents autobus. Cette fonctionnalité est importante puisque c'est
elle qui permet de déterminer les autobus disponibles (non en panne) afin de les affecter aux
parcours à venir.
Ces deux fonctions ont déjà fait l'objet d'une étude et une base de données a été implémentée. Voici
ci-dessus les relations qui composent la base de données relationnelle.
L'attribut HORAIRE_DEPART est sous la forme AAAAMMJJHHmm. Il notifie l'année, le mois,
le jour, l'heure et les minutes auxquels un conducteur doit se présenter à l'arrêt départ pour prendre
son service.
Les services sont entrecoupés de temps de repos, si bien que le même jour deux parcours peuvent
concerner le même conducteur, la même ligne et le même autobus.
JJLC
2/4
FC-UVSQ
Travail.
1. Votre chef de projet vous demande de réaliser la rétro-conception (reverse engineering) de
la base de données sous la forme d'un modèle de domaine avec le diagramme de classe
UML débarrassé de toute orientation (relationnelle et objet). Il vous précise qu'il ne
désire voir que le nom des entités du domaine et leurs relations avec leurs cardinalités.
Le cas TCR partie 2.
Votre chef de projet vous demande de réfléchir à la prise en compte des nouveaux besoins qu'ont
fait remontés les décideurs de la TCR.
Ils souhaitent pouvoir stocker le moment d'arrivée (même format que HORAIRE_DEPART) d'un
autobus à son terminus. Ainsi ils pourront réaliser des statistiques sur les temps de transport par
ligne.
Ils souhaitent également que le personnel qui pilote la gestion des parcours soit en capacité de
connaître la liste de tous les arrêts par ligne, du départ jusqu'au terminus. En sachant qu'à une ligne
correspondent plusieurs arrêts et qu'à un arrêt peut correspondre plusieurs lignes (arrêts communs).
De plus ils souhaitent également pouvoir stocker dans la base de données tout ce qui concerne les
événements graves arrivés lors des parcours. La TCR enregistre statistiquement trois cents accidents
par an et une cinquantaine d'incidents (accident voyageur, agression, insultes, etc.). Vous devez
réfléchir à l'intégration de la gestion de ces événements dans le système d'information existant.
Un événement est caractérisé par une date (même format que HORAIRE_DEPART), un type
(accident de la route, accident voyageur, agression, vol, insultes, etc.) et correspond à un parcours.
L'événement s'est passé soit à une station soit entre deux stations.
Travail.
1. Votre chef de projet vous demande de modifier le système d'information stocké dans la base
de données pour tenir compte de ces nouvelles règles de gestion. La solution doit être
représentée par un diagramme de classe UML avec injection d'un profil relationnel.
Le cas TCR partie 3.
Votre chef de projet vous confie la tâche de faire évoluer le modèle en tenant compte des nouvelles
spécifications fournies par les représentants de la compagnie de transport en commun TCR.
En, effet les responsables de la TCR souhaitent que le système d'information offre la possibilité de
gérer précisément la situation géographique et urbaine des arrêts d'autobus. Vous devez travailler
avec eux, analyser leurs explications et rédiger le cahier des charges des spécifications
fonctionnelles de ce nouveau besoin exprimé par la TCR.
Pour la TCR, un arrêt correspond à une voie et une voie correspond à un ou plusieurs arrêts. Une
voie est caractérisée par un type voie (rue, avenue, boulevard), un nom et un secteur géographique
dans la ville.
JJLC
3/4
FC-UVSQ
Travail.
1. Votre chef de projet vous demande de modifier le diagramme de la partie 2 afin que soient
prises en compte les nouvelles spécifications.
Le cas TCR partie 4.
Votre chef de projet vous confie la tâche de faire évoluer le modèle en tenant compte des nouvelles
spécifications fournies par les représentants de la compagnie de transport en commun TCR.
En, effet les responsables de la TCR souhaitent que le système d'information offre la possibilité de
gérer les accidents. Vous devez travailler avec eux, analyser leurs explications et rédiger le cahier
des charges des spécifications fonctionnelles de ce nouveau besoin exprimé par la TCR.
Pour la TCR, un accident est caractérisé par l'heure (HHMM) à laquelle il est survenu. Un accident
concerne un parcours. Un parcours est caractérisé par zéro ou un accident. Car lorsqu'un accident
arrive à un autobus, celui-ci rentre directement au dépôt (donc pas de possibilité de second
accident).
Un accident est soit un accident de la route soit un accident de passager. Un accident de la route est
caractérisé par le résumé du constat d'accident et également par l'immatriculation du véhicule avec
lequel l'autobus a eu l'accident.
Un accident passager est caractérisé par le nom du passager accidenté et la description des blessures
occasionnées par cet accident.
Travail.
1. Votre chef de projet vous demande de réaliser le diagramme UML des classe métier du
sujet afin que soient prises en compte les anciennes et les nouvelles spécifications.
Références.
Le document : profilUMLv3
Le document : JPA en image
Le lien: http://www.uml.org.cn/umlapplication/pdf/tp185.pdf
Le lien:
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1392/1392_naiburg7.pdf
Le lien : http://www.uml.org.cn/oobject/tp180.pdf
Le lien : http://databaserefactoring.com/
Le lien : http://martinfowler.com/articles/evodb.html
JJLC
4/4
FC-UVSQ