Mongi TRIKI Docteur en Informatique Université Paris Dauphine

Transcription

1 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

2 . Sommaire 1. Sommaire-type du Mémoire de Stage Rapports à remettre et Planning de réalisation des travaux Bibliographie Quelques consignes de présentation Quelques consignes pour la conduite de l encadrement Barème de Notation Annexe...9 2

3 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 Objectifs à atteindre Ce sont les buts à atteindre par l organisme en question suite à la réalisation de ce projet 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 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

4 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 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 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 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 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

5 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 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 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 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

6 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 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 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 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

7 Clé primaire : ensemble d'attributs dont les valeurs permettent de distinguer les n- uplets 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 : 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 Construction du schéma logique des classes brut 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

8 2. RAPPORTS A REMETTRE ET PLANNING DE REALISATION DES TRAVAUX N ETAPES DUREE PRODUIT DE L ETAPE 1 Etude Préalable 3 semaines Rapport N 1 2 Modélisation 3 semaines Rapport N 2 Conceptuelle 3 Modélisation 4 semaines Rapport N 3 Organisationnelle & logique 4 Réalisation Technique 4 semaines Mémoire de & préparation du stage + DVD mémoire contenant le logiciel DATE AU PLUS TARD DE DEPOT. 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, 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é Format Tous les textes sont justifiés. Les marges haut, bas, gauche et droite sont égales à 2,5 cm 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 Présentation de la couverture du mémoire La couverture du rapport doit être en carton. 8

9 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

10 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 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 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

11 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 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

12 FICHE DES NOTES DES ETUDIANTS N Matricule 1 Nom & Prénom Note Rapport 1 3 points Note Rapport 2 3 points Note Rapport 3 3 points Mémoire 4 points Présentation & Démonstration 5 points Note Finale