Guide du Stagiaire pour réaliser un projet de fin d`étude

Université Méditerranéenne Libre de Tunis
Faculté Méditerranéenne Privée des Sciences Informatiques,
Economiques et de Gestion de Tunis
Département d’Informatique
LICENCE INFORMATIQUE
Guide du Stagiaire
pour réaliser un projet de fin d’étude
selon la démarche UML
Version Enseignant
Mongi TRIKI
Docteur en Informatique
Université Paris Dauphine
1
.
Sommaire
1. Sommaire-type du Mémoire de Stage ...........................................................3
2. Rapports à remettre et Planning de réalisation des travaux ......................8
3. Bibliographie................................................................................................... 8
4. Quelques consignes de présentation ............................................................8
5. Quelques consignes pour la conduite de l’encadrement ...........................9
6. Barème de Notation ......................................................................................9
7. Annexe ...........................................................................................................9
2
1. SOMMAIRE-TYPE DU MEMOIRE DE STAGE
Introduction (1 page au maximum)
L’introduction traite des points suivants :
 Présentation du domaine et du projet
 Présentation des travaux demandés.
 Présentation de l’organisation du mémoire (contenu de chaque chapitre).
Chapitre 1 : MODELISATION DU METIER (10 à 15 pages)
Le but de la modélisation du métier est de comprendre le domaine ou le métier de
l’entreprise et des personnes qui y travaillent pour mieux satisfaire leurs besoins. Il
s'agit aussi de construire un modèle de l’organisation étudiée.
La modélisation des métiers permet de cerner la formulation du système d’information
(SI) à informatiser et de décrire les éléments essentiels pour définir le périmètre de
l’étude. Le but de la modélisation du métier est de comprendre le domaine ou le métier
de l’entreprise et des personnes qui y travaillent pour mieux satisfaire leurs besoins. Il
s'agit aussi de construire un modèle de l’organisation étudiée.Dans ce chapitre, nous
allons présenter les éléments suivants :
 définition de la mission,
 analyse de l'existant,
 repérage du domaine,
 Diagramme de cas d’utilisation métier.
1. Définition de la mission
Concernant cette partie, il s’agit de présenter les quatre points essentiels suivants :
 Présentation de l’application
 Objectifs à atteindre
 Repérage du domaine
 Diagramme de cas d’utilisation métier
1.1. Présentation du logiciel
Il s’agit de décrire l’application à réaliser en termes de fonctionnalités offertes aux
utilisateurs.
1.2. Objectifs à atteindre
Ce sont les buts à atteindre par l’organisme en question suite à la réalisation de ce
projet.
1.3. Repérage du domaine
Il s'agit de trouver les acteurs métier et de représenter les limites du domaine. Le
diagramme utilisé est un diagramme de collaboration qui représente le domaine
comme boite noire et les messages échangés entre ce domaine et les acteurs métier.
1.4. Diagramme de cas d’utilisation métier
Il s'agit de définir les travailleurs du métier, de décrire leur rôle et de représenter les
différents processus du métier et les liens entre eux. Ainsi, il faut construire un
diagramme de cas d'utilisation dans lequel on représente chaque processus métier par
un cas d'utilisation. Ensuite on doit décrire chaque processus métier en précisant les
3
flots d’événements de chacun, les activités qui le composent et les règles de gestion à
respecter pour ces activités. Cette description est textuelle.
2. Analyse de l’existant
Cette partie consiste à présenter l’étude de l’existant et critique de l’existant.
2.1. Etude de l'existant
Il s’agit de décrire le système d’information actuel relatif au domaine à automatiser.
L’étudiant peut commencer par présenter tout d’abord l’organisme puis se focaliser sur tout ce
qui concerne le domaine étudié : postes de travail, procédures, documents utilisés,
informations échangées avec l’environnement, etc.
2.2. Critique de l'existant
Il s'agit de critiquer les processus de travail et le processus de gestion des informations
et de montrer et répertorier leurs points forts et points faibles. Les points forts sont à
consolider et les points faibles sont à éviter dans le nouveau système.
Chapitre 2 : CAPTURE DES BESOINS (10 à 15 pages)
Le but de ce chapitre est de présenter un recueil des besoins fonctionnels et techniques
envers le système à développer.
La capture des besoins permet de cerner le système d’information (SI) à informatiser
et de décrire ses spécifications fonctionnelles. Dans ce chapitre, nous allons présenter
les éléments suivants :
 acteurs du système informatisé,
 modélisation de contexte du système informatisé,
 élaboration du modèle des cas d’utilisation.
1. Formulation du problème
Concernant cette partie, il s’agit de formuler le problème afin de limiter le champ de
l’étude.
1.1. Acteurs du système informatisé
On doit définir les différents acteurs du futur système et décrire leur rôle.
Un acteur est un objet actif qui produit ou consomme des valeurs de données. Les
acteurs constituent les extrémités d’un diagramme de flux de données. Ils sont
représentés par un rectangle pour montrer qu’ils correspondent à des objets. L’acteur
est relié au reste du diagramme par des flèches en entrée et en sortie.
1.2. Modèle de contexte du système informatisé
Il s'agit de modéliser le contexte du système pris comme boîte noire en montrant les
messages qu'il échange avec ses acteurs. Le diagramme nécessaire est un diagramme
de collaboration.
2. Elaboration du modèle des cas d’utilisation
L’élaboration du modèle des cas d’utilisation consiste à présenter :
 Diagramme des cas d’utilisation
 Description textuelle des cas d’utilisation
4
2.1. Diagramme des cas d’utilisation
Il s'agit de représenter sous forme d'un diagramme de cas d'utilisation les
fonctionnalités du système comme vues par les futurs utilisateurs et les liens entre
elles.
2.2. Description textuelle des cas d’utilisation
Dans cette section, chaque cas d'utilisation doit être décrit de façon exhaustive suivant
le format présenté dans l'annexe. Tous les scénarios des cas d'utilisation doivent être
pris en comptes (nominaux, alternatifs et d'exception.]
Chapitre 3 : ANALYSE (10 à 15 pages)
La phase d’analyse est une étape du cycle de développement dans laquelle le problème
du monde réel est examiné afin d’en comprendre les spécifications, sans entreprendre
d’implémentation.[RUM 98]
En effet, le modèle d’analyse répond à plusieurs nécessités : il clarifie les besoins et
devient le cadre pour la conception et l’implémentation futures.
L’objet de ce chapitre est de développer un modèle de ce que le système doit faire, ce
modèle est exprimé en termes d’objets et de relations, de flux dynamiques et de
transformation fonctionnelle. Ce chapitre s’articule autour deux volets :
 Construction du diagramme de classe,
 Développement du modèle dynamique.
1. Construction du diagramme de classes
Il faut donner dans cette section le diagramme de classes du domaine, en précisant
leurs attributs, les relations entre elles, leurs multiplicités et les contraintes attachées
aux éléments du diagramme. Un dictionnaire de données doit être construit à la suite
du diagramme de classes pour donner la signification des classes et des attributs de ces
classes. Ce section s’articule autour deux volets :
 Diagramme de classe,
 Dictionnaire de données,
 Représentation des méthodes par classe.
1.1. Diagramme de classe
1.2. Dictionnaire de données
1.3. Représentation des méthodes par classe
2. Développement du modèle dynamique
Le développement du modèle dynamique comprend :
 Construction des diagrammes de séquence,
 Construction des diagrammes d’états
2.1. Construction des diagrammes de séquence
Cette section doit contenir la spécification des scénarios de cas d'utilisation. Elle doit
formaliser leur comportement et montrer les différents objets du domaine qui sont
impliqués dans chaque scénario et les messages échangés entre eux.
2.2. Construction des diagrammes d’états
Il s'agit de représenter et de commenter les diagrammes d'états transitions construits
pour les classes à comportement dynamique complexe.
5
Chapitre 4 : CONCEPTION (10 à 15 page)
1. Environnement de réalisation
L’environnement de réalisation comprend :
 Matériel et logiciel de base,
 Outils de développement.
1.1. Matériel et logiciel de base
1.2. Outils de développement
2. Conception du système
La conception du système comprend :
 Conception des classes,
 Diagramme de navigation.
2.1. Conception des classes
Cette section est nécessaire pour une implémentation orientée objet. Elle consiste à
concevoir les classes, les états des classes, les associations, les attributs et les
opérations. Les diagrammes à présenter dans cette section sont : des diagrammes de
classes qui décrivent les classes de conception et des diagrammes d'activité ou de
séquences qui décrivent les algorithmes des méthodes complexes. Même pour un
développement non objet, l'étudiant doit donner les algorithmes des procédures
complexes. Quelque soit l'environnement de développement utilisé, l'étudiant doit
décrire le rôle des modules et/ou programmes primordiaux, ainsi que les tables que
chacun utilise pour son fonctionnement.
2.2. Diagramme de navigation
Il s'agit de représenter graphiquement l'activité de navigation entre les différentes
interfaces spécifiées au niveau des diagrammes de séquence. Le diagramme d'étatstransitions devra être utilisé pour modéliser cette navigation. Ce diagramme est
optionnel, mais conseillé pour les applications web.
4. Conception des schémas logiques et physique des données
A partir de la description conceptuelle que nous avons effectuée, on peut réaliser le
modèle relationnel; vu que le système d'information ne peut pas le manipulé
directement; et ça en utilisons des règles de passages de l'UML vers le relationnel.
Quelques notions essentielles
 Domaine : c'est l'ensemble des valeurs d'un attribut.
 Relation : c'est un sous ensemble du produit cartésien d'une liste de domaines.
C'est en fait un tableau à deux dimensions dont les colonnes correspondent aux
Domaines et dont les lignes contiennent des tuples. On associe un nom à
Chaque colonne
 Attribut : c'est une colonne d'une relation, caractérisé par un nom.
 Tuple : c'est la liste des valeurs d'une ligne d'une relation.
 Cardinalité : elle permet de définir les conditions de participation d'une entité à
une relation. Toutefois, une entité peut participer à plusieurs relations.
 L'arité : est le nombre d'attributs d'une relation.
 Clé : On distingue deux types de clés:
6
Clé primaire : ensemble d'attributs dont les valeurs permettent de distinguer les nuplets les uns des autres (notion d'identifiant).
Clé étrangère : Attribut qui est clé primaire d'une autre entité.
NB : pour la notation, nous avons choisi de mettre en gras les clés primaires et de
mettre # à la fin de chaque clé étrangère.
Les règles de passage
1. Transformation des classes : chaque classe du diagramme UML devient une
relation, il faut choisir un attribut de la classe pouvant jouer le rôle de clé.
Transformation des associations : Nous distinguons trois familles d'associations
2. Association 1.. : il faut ajouter un attribut de type clé étrangère dans la relation fils
de l'association. L'attribut porte le nom de la clé primaire de la relation père de
l'association.
3. Association *..* et n-aire et classes-association : la classe-association devient une
relation. La clé primaire de cette relation est la concaténation des identifiants des
classes connectées à l'association.
4. Association 1.. 1 : il faut ajouter un attribut de type clé étrangère dans la relation
dérivée de la classe ayant la multiplicité minimale égale à un. L'attribut porte le nom
de la clé primaire de la relation dérivée de la classe connectée à l'association. Si les
deux multiplicités minimales sont à un, il est préférable de fusionner les deux classes
en une seule.
4.1. Construction du schéma logique des classes brut.
4.2. Construction du schéma logique des classes optimisé
4.3. Construction du schéma physique des classes
Conclusion (1 page au maximum)
La conclusion traite des points suivants :
 Rappel de l’objet du projet.
 Présentation rapide des travaux réalisés et des solutions apportées.
 Analyse critique de ces solutions :
- Points forts et apports,
- Points faibles et limites.
 Perspectives : améliorations et extensions possibles, définition d’autres projets,
etc.
7
2. RAPPORTS A REMETTRE ET PLANNING DE
REALISATION DES TRAVAUX
N°
ETAPES
1
2
Etude Préalable
Modélisation
Conceptuelle
Modélisation
Organisationnelle
& logique
Réalisation Technique
& préparation du
mémoire
3
4
PRODUIT
DUREE
DE
L’ETAPE
3 semaines Rapport N° 1
3 semaines Rapport N° 2
DATE AU PLUS
TARD DE DEPOT
4 semaines Rapport N° 3
4 semaines Mémoire de
stage + DVD
contenant le
logiciel
. Bibliographie
 P. A. Muller & N. Gaertner,
Modélisation objet avec UML,
Les éditions Eyrolles, 2005
 P. Roques & F. Vallée,
UML 2 en action,
Les éditions Eyrolles, 2002
 C. Morley, J. Hugues, B.
UML pour l’analyse d’un système d’information
Leblanc, Dunod, 2003.
4. Quelques consignes de présentation
4.1. Typographie
L’ensemble des textes est composé en style simple Times New Roman, corps 12 ou 14
minuscules, interligné comme sur la présente sortie (option au moins 16 points). La
page de garde doit être conforme au modèle ci-après présenté.
4.2. Format
Tous les textes sont justifiés. Les marges haut, bas, gauche et droite sont égales à 2,5
cm.
4.3. Numéros et titres des paragraphes
Même présentation que celle utilisée dans le sommaire-type, mais tous les paragraphes
commencent en début de ligne.
4.4. Présentation de la couverture du mémoire
La couverture du rapport doit être en carton.
8
5. Quelques consignes pour la conduite de l’encadrement
1) Les étudiants peuvent entamer les travaux de réalisation juste après la modélisation
conceptuelle, en suivant l’approche RAD (Développement Rapide d’Applications).
Cette approche postule que l’on peut passer par trois ou quatre versions du logiciel à
développer pour arriver à la version finale. La première version vise d’abord une prise
de connaissance du domaine d’étude et de l’environnement de réalisation. La
deuxième version vise une conformité par rapport au modèle organisationnel et au
modèle logique. Les autres versions visent des améliorations successives du prototype
considéré. Il est à noter qu’il est possible, lors de ces améliorations, de revenir aux
modèles conceptuels, organisationnel et logique pour les compléter et/ou corriger.
2) L’évaluation des rapports écrits (y compris le mémoire) et des deux premiers
prototypes est à faire par l’enseignant encadrant et l’enseignant responsable de
l’équipe pédagogique.
3) L’évaluation du prototype final est à faire par tous les enseignants de l’équipe
pédagogique, suite à une démonstration de ce prototype par l’étudiant concerné
(environ 15 minutes).
6. Barème de Notation





Rapport N° 1 : 3 points
Rapport N° 2 : 4 points
Rapport N° 3 : 4 points
Mémoire : 4 points
Présentation & Démonstration : 5 points
7. Annexe :
A. Exemple de description textuelle de UC
Identification :
Titre : Gérer commandes
Acteurs : Vendeur
Objectif : Ce UC est utilisé pour passer et suivre les commandes clients.
Date de création : 09/09/2009
Date de mise à jour : 14/09/2009
Version : 1.1
Description des scénarios
Précondition : Le vendeur est authentifié
Au moins un produit est disponible.
Postconditions : La date de la commande validée est inférieure à la date du jour.
Le client ayant passé la commande validée figure dans la liste des clients.
Les quantités de produits commandées sont toutes inférieures ou égales à celles
disponibles dans le stock.
Scénario nominal : Enregistrer une nouvelle commande
Le UC débute quand le vendeur demande de créer une nouvelle commande.
a) Identification du client
9
1. Le système propose au vendeur de chercher le client selon plusieurs critères
(numéro, nom, nom incomplet)
2. Le vendeur saisit un critère de recherche.
3. Le système affiche la liste des clients répondant au critère de recherche. Si
aucun client n’est trouvé, il faut appeler le UC "Gérer clients".
4. Le vendeur sélectionne le client.
5. Le système affiche toutes les informations nécessaires sur ce client
(nom, prénom, adresse, téléphone, CA).
b) Saisie des produits commandés
1. Le vendeur demande la liste des produits.
2. Le système affiche la liste de tous les produits.
3. Pour tout produit commandé :
3.1. Le vendeur sélectionne un produit et saisit la quantité commandée.
3.2. Le système vérifie que la quantité de produit est disponible. Si elle ne l'est
pas, alors il faut exécuter Exception 1. Sinon, le système affiche le PHT du
produit sélectionné ainsi que le MHT et le TVA.
4. Après la saisie de tous les produits commandés, le système affiche le
THT et le TTC de la commande.
c) Saisie de la date
1. Le vendeur saisit la date de passation de la commande.
2. Le système vérifie qu’elle est inférieure à la date du jour. En cas d’anomalie,
il faut exécuter Exception 2
d) Validation de la commande
1. Le vendeur demande la validation de la commande.
2. Le système vérifie que toutes les données obligatoires sont saisies. S’il y’a
une information manquante, il faut exécuter Exception 3.
3. Le scénario se termine lorsque le système enregistre la commande et lui
affecte un numéro.
4. Tant que la commande n'est pas enregistrée, elle peut être à tout moment
annulée.
Scénarios alternatifs :
1 . Modifier une commande existante…
2 . Consulter les commandes existantes…
3. Annuler une commande existante…
Exceptions :
1. Le système affiche " Quantité demandée n'est pas disponible" et donne la
main au vendeur pour changer la quantité.
2. Le système refuse la saisie, affiche le message : « date de la commande doit
être inférieure à la date du jour » et donne la main au vendeur pour modifier
la date.
3. Le système affiche le message : « L’information …. est manquante » et
retourne à la position de la première information manquante.
B. Page de garde
C. Fiche des Notes des étudiants
10
Université Méditerranéenne Libre de Tunis
Faculté Méditerranéenne Privée des Sciences Informatiques,
Economiques et de Gestion de Tunis
Département d’Informat ique
MEMOIRE DE STAGE
POUR L’OBTENTION DE LA LICENCE FONDAMENTALE
EN INFORMATIQUE APPLIQUEE A LA GESTION
TITRE DU MEMOIRE
Réalisé par
Prénom et NOM de l’étudiant
Encadré par
Prénom et NOM de l’enseignant
JURY
Prénom et NOM de l’enseignant 1 : Président
Prénom et NOM de l’enseignant 2 : Examinateur
Prénom et NOM de l’enseignant 3 : Examinateur
Prénom et NOM de l’enseignant 4 : Examinateur
Année universitaire
2014 - 2015
11
FICHE DES NOTES DES ETUDIANTS
N°
Matricule
Nom
&
Prénom
Note
Rapport
1
3 points
Note
Rapport
2
3 points
1
2
3
4
5
12
Note
Rapport
3
3 points
Mémoire
4 points
Présentation
&
Démonstration
5 points
Note
Finale