Management des Systèmes d’Information (MSI) Cours : chapitre 2 UML Use cases Classes - Objets

UML : Unified Modelling Language Historique : Grady Booch 1981, ADA, « Object Oriented Development » James Rumbaugh 1991, OMT, JOOP (Journal of OO programming) Ivar Jacobson, OOSE sept 97, UML 1.1. Références : http://www.omg.org http://uml.free.fr/ site en français en France Pierre Alain Muller (U-Mulhouse) et Valtech http://uml.developpez.com/ UML 2 : De l'apprentissage à la pratique, 2009, Ellipses, Laurent Audibert Conception & Réalisation des bases de données: de UML à SQL, Jacques Guyot, 2002, éditions Internet. Conception de bases de données avec UML, Gilles Roy, PUQ, 2007, ISBN 2760519449, 9782760519442, 511 pages Outils : StarUML version 5.1 Rational ROSE , http://www.rational.com plus de 30 outils de modélisation et de CASE (Computer Aided Software Engineering)

Architecture Technologie UML modelling information systems propriétés Constituant UML modelling information systems at conceptual level at logical level : acteur (intéragissant avec VEGA2) Système (VEGA2) message Technologie Architecture

Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 Creating the UML UML 2.0 2003 OOSE Other methods UML 0.9 Web - June ´96 UML 1.3 Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 UML 1.1 OMG Acceptance, Nov 1997 public feedback UML 1.0 UML partners Unified Method 0.8 OOPSLA ´95 Booch method OMT

Contributions to the UML Harel Statecharts Meyer Before and after conditions Gamma, et al Frameworks and patterns, HP Fusion Operation descriptions and message numbering Booch Booch method Embley Singleton classes and high-level view Rumbaugh OMT Wirfs-Brock Responsibilities Jacobson OOSE Shlaer - Mellor Object lifecycles Odell Classification

Axes de modélisation d’un système Statique (ce que le système EST) diagramme de classes diagramme d’objets diagramme de composants diagramme de déploiement Dynamique (comment le système EVOLUE) Fonctionnel (ce que le système FAIT) diagramme de séquence diagramme de collaboration diagramme d’états-transitions diagramme d’activités diagramme de cas d’utilisation diagramme de collaboration

Niveaux d’abstraction d’un SI Grenoble INP Génie industriel 2A ICL MSI – UML 1 Niveaux d’abstraction d’un SI En UML, les mêmes modèles peuvent être utilisés à différents niveaux d’abstraction du plus conceptuel à l’implémentation. On peut donc appliquer des mécanismes de transformation continue. Conceptuel organisationnel logique physique

Grenoble INP Génie industriel 2A ICL MSI – UML 1 Les 9 diagrammes UML 1.0 diagramme de cas d’utilisation diagramme de classes diagramme de séquence diagramme de collaboration diagramme d’objets diagramme d’états-transitions diagramme d’activités (nous utiliserons IDEF 0) diagramme de composants diagramme de déploiement

Description UML des 9 diagrammes UML 1.0 Ceci est un commentaire Cas d ’utilisation Cas d ’utilisation Classes Etats Transitions Séquence Classes Etats Transitions Séquence Collaboration Composants Déploiement Activité Objets

Exemples : Quelques diagrammes Grenoble INP Génie industriel 2A ICL MSI – UML 1 Exemples : Quelques diagrammes : acteur (intéragissant avec VEGA2) Système (VEGA2) message Diagramme de séquence Chaque cas d'utilisation apparaît comme un scénario, décrit par un ou plusieurs diagrammes de séquence. Un diagramme de séquences montre les interactions entre les acteurs et le système selon un point de vue temporel pour accomplir une fonctionnalité attendue du système (un cas d ’utilisation). C’est une ensemble de messages échangés entre les acteurs et le système, ordonnés chronologiquement. cas d'utilisation Acteur Cas d’utilisation une fonctionnalité attendue du système (VEGA2) par les différents acteurs. Diagramme de Classes

do / préparer livraison Pas de confirmation client après 1 mois cas d'utilisation cas d'utilisation Acteur 1 article code désignation prix-U rayon ss-rayon * contient> 1 Sous rayon emplacement nom Implantation comporte Rayon Nom Display () Number-product cas d'utilisation Acteur 2 En préparation do / ajout article état initial état final Confirmée do / préparer livraison Livrée do / attente paiement Payée Confirmation client paiement effectué 10 ans après paiement Pas de confirmation client après 1 mois

Modèle Fonctionnel Use Cases : cas d’utilisation diagramme de collaboration

Diagramme de cas d’utilisation Représente les fonctions du système de point de vue de l ’utilisateur. Ceci est un cas d’utilisation Ceci est une relation un acteur relation Cas d’utilisation Acteur Eléments du diagramme : acteur : un rôle joué par une personne, un service, etc. qui interagit avec le système étudié cas d’utilisation : manière spécifique d ’utiliser un système. Image d’une fonctionnalité attendue, déclenchée en réponse à la stimulation d’un acteur relations entre cas d’utilisations et acteurs

Relations entre cas d’utilisations Trois types de relations : relation de communication : entre un acteur et un cas d’utilisation. Exprime l’échange d’informations entre l’acteur et le système. Effectue virement client relation d’utilisation : entre deux cas d’utilisation. Exprime que le cas d’utilisation source comprend également le comportement décrit par le cas d’utilisation destinataire (utile pour la factorisation de cas). virement identification « use » relation d’extension : entre deux cas d’utilisation. Exprime que le cas d’utilisation source étend le comportement du cas d’utilisation cible (utile pour la spécialisation de cas). Virement par Internet virement « extend »

Acteurs : diagramme de cas d’utilisation Grenoble INP Génie industriel 2A ICL MSI – UML 1 Acteurs : diagramme de cas d’utilisation Acteur humain : il s’agit ici d’un rôle et non d’un acteur identifié. Acteur non humain : exemple un logiciel de comptabilité ou d’ERP avec lequel le système interagit Conçoit les schémas et nomenclatures Récupère les schémas Exemple Gestion des schémas Récupère les Développeur contraintes Définit les contraintes mécaniques Gestion des contraintes Responsable CFAO Responsable Gestion des jobs Gère la création et les révisions d ’un job BE <<dépend>> Gère la création et les révisions des dossiers variantes Gestion des dossiers

Bien recueillir les besoins Bien souvent, la maîtrise d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d’exprimer leurs besoins. C’est précisément le rôle des diagrammes de cas d’utilisation qui permettent de recueillir, d’analyser et d’organiser les besoins, et de recenser les grandes fonctionnalités d’un système. Il s’agit donc de la première étape UML d’analyse d’un système. Un diagramme de cas d’utilisation capture le comportement d’un système, d’un sous-système, d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d’utilisation, ayant un sens pour les acteurs. Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système, ils sont donc une vision orientée utilisateur de ce besoin au contraire d’une vision informatique. Compréhensibles par toutes les personnes, même par les non-informaticiens.

Formalisme des diagrammes de cas d’utilisation Acteur Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou une chose (matériel ou immatériel) qui interagit avec un système. ou Plusieurs utilisateurs peuvent avoir le même rôle, et donc correspondre à un même acteur, et inversement une même personne physique peut jouer des rôles différents vis-à-vis du système, et donc correspondre à plusieurs acteurs.

Acteur humain : il s’agit ici d’un rôle et non d’un acteur identifié. Acteur complément Un acteur représente un ensemble cohérent de rôles joués vis-à-vis d’un système (mettre « comptable » plutôt que « madame Dupont »). Plusieurs personnes peuvent avoir le même rôle (exemple : « client » pour une banque) Tout ce qui est à l’extérieur du système et qui interagit avec le système est un acteur Acteur humain : il s’agit ici d’un rôle et non d’un acteur identifié. Acteur non humain : exemple un logiciel de comptabilité ou d’ERP avec lequel le système interagit

Formalisme des diagrammes de cas d’utilisation 2.3  Représentation d’un diagramme de cas d’utilisation Nom du Système Frontière du système Cas d’Utilisation Acteur Relation d’Association

Relations entre cas d’utilisation Il existe principalement 2 types de relations: Dépendances stéréotypées, dont les plus usitées sont : Inclusion Extension Formalisme : Généralisation / spécialisation

Relations entre cas d’utilisation Relation d’inclusion Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B : le cas A dépend de B. Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A. Cette dépendance est symbolisée par le stéréotype << include >> Les inclusions permettent essentiellement de factoriser une partie de la description d’un cas d’utilisation qui serait commune à d’autres cas d’utilisation. Les inclusions permettent également de décomposer un cas complexe en sous-cas plus simples (attention, ce n’est pas une décomposition fonctionnelle). Attention, il n’existe pas de temporalité

Relations entre cas d’utilisation Relation d’extension Un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >> . L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle le point d’extension.

Relations entre cas d’utilisation Relation de généralisation Un cas A est une généralisation d’un cas B, si B est un cas particulier de A. Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés objet la consultation d’un compte via Internet est un cas particulier de la consultation.

Relations entre cas d’utilisation Relations entre acteurs La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.

Relations entre cas d’utilisation

Comment identifier les acteurs ? (1/2) Les acteurs (utilisateurs) d’un système sont les entités externes à ce système qui interagissent (saisie de données, réception d’information, …) avec lui. Les acteurs sont à l’extérieur du système et dialoguent avec lui. Ces acteurs permettent de cerner l’interface que le système va devoir offrir à son environnement. (attention à ne pas oublier qu’un acteur peut être humain, matériel ou immatériel). Chaque acteur doit être nommé. Ce nom doit refléter son rôle, car un acteur représente un ensemble cohérent de rôles joués vis-à-vis du système.

Comment identifier les acteurs ? (2/2) Les différents acteurs d’un système peuvent être : des utilisateurs (ex : responsable clientèle, responsable d’agence, administrateur, approbateur, …) les périphériques manipulés par le système (imprimantes, hardware d’un distributeur de billet, …) ; des logiciels déjà disponibles à intégrer dans le projet ; des systèmes informatiques externes au système, mais qui interagissent avec lui, etc. Pour faciliter la recherche des acteurs, on peut imaginer les frontières du système. Tout ce qui est à l’extérieur et qui interagit avec le système est un acteur, tout ce qui est à l’intérieur est une fonctionnalité à réaliser. (exemple de la caisse enregistreuse, le Client est-il un acteur ?)

Comment recenser les cas d’utilisation ? (1/2) L’ensemble des cas d’utilisation décrit exhaustivement les exigences fonctionnelles du système. Chaque cas d’utilisation correspond à une fonction métier du système, selon le point de vue d’un de ses acteurs (exemple du distributeur de billet : Retirer de l’argent ou Distribuer de l’argent ?). Aussi, pour identifier les cas d’utilisation, il faut se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi il se sert du système.

Comment recenser les cas d’utilisation ? (2/2) Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon niveau d’abstraction. Nommez les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément en vous plaçant du point de vue de l’acteur, et non pas de celui du système. De par la nature fonctionnelle, et non objet, des cas d’utilisation, et en raison de la difficulté de trouver le bon niveau de détail, il faut être très vigilant pour ne pas retomber dans une décomposition fonctionnelle descendante hiérarchique. Un nombre trop important de cas d’utilisation est en général le symptôme de ce type d’erreur. Dans tous les cas, il faut bien garder à l’esprit qu’il n’y a pas de notion temporelle dans un diagramme de cas d’utilisation.

Exemple : gestion de voyages personnalisés Cas d’étude de l’agence de voyage Exemple : gestion de voyages personnalisés Réserver une chambre d’hotel Réserver un taxi Réserver un billet de train Organiser un voyage Agent de voyage Une agence de voyages organise des voyages où l’hébergement se fait en hôtel. Le client doit disposer d’un taxi quand il arrive à la gare pour se rendre à l’hôtel Certains clients demandent à l’agent de voyages d’établir une facture détaillée. Cela donne lieu à un nouveau cas d’utilisation appelé « Etablir une facture détaillée». Comment mettre ce cas en relation avec les cas existants? Le voyage se fait soit par avion, soit par train. Comment modéliser cela ?

Cas d’étude de l’agence de voyage

Cas d’étude de la médiathèque

Modèle Statique diagramme d’objets Diagramme de classes

Objets et classes Objet : une entité concrète avec une identité bien définie qui encapsule un état et un comportement. L’état est représenté par des valeurs d’attribut et des associations, le comportement par des méthodes. Un objet est une instance d’une classe. Classe : une description d’un ensemble d’objets qui partagent les mêmes attributs, opérations, méthodes, relations et contraintes. Une classe peut posséder des attributs ou des méthodes « de classe ». MaVoiture : Voiture marque = Renault Modèle = Nevada Immatriculation = 648ADX38 AnnéeModele = 1992 Kilométrage = 285 000 Voiture marque : chaîne Modèle : chaîne Immatriculation : chaîne (8) AnnéeModele : date Kilométrage : entier Rouler ( ) Kilometrage_annuel_moyen ( )

Diagramme d’Objets Concrétisation Abstraction Structure statique d’un système, en termes d’objets et de liens entre ces objets. Ces objets et ces liens possèdent des attributs qui possèdent des valeurs. Un objet est une instance de classe et un lien est une instance d’association. Nom de l’objet : Classe Attributs = valeurs Opérations = méthodes Etienne : personne Date-naissance= 30/6/89 âge ? Personne Date-naissance (date) âge (): entier collaborateur * patron patron 1 collaborateur Concrétisation Abstraction Jean-Luc : personne Date-naissance= 22/6/99 âge ? emploie> Diagramme de classes Diagramme d ’objets

Diagramme de classes exemple : Structure statique d’un système, en termes de classes et de relations entre ces classes. Voiture Couleur Cylindrée Vitesse max Démarrer () Accélérer () Freiner () Nom de classe Attributs Opérations () exemple : Syntaxe: nom_attribut : type_attribut = valeur initiale nom_opération (nom_argument : type_argument = valeur_par_défaut, …) : type_retourné Visibilité : trois niveaux de visibilité pour les attributs et les opérations: public (+) : élément visible à tous les clients de la classe protégé ( #) : élément visible aux sous-classes de la classe privé (-) : élément visible à la classe seule

Diagramme de classes : Relations entre classes Agrégation : quand une classe fait partie d’une autre classe (agrégat - composant) Association : toute relation structurelle entre classes, autre que l’agrégation et la généralisation Généralisation : factorisation des éléments communs d’un ensemble de classes dits sous-classes dans une classe plus générale dite super-classe. Elle signifie que la sous-classe est un ou est une sorte de la super-classe. Le lien inverse est appelé spécialisation. classe 2 généralisation spécialisation association Véhicule classe 1 1 1..* 1 1..* Constructeur Moteur classe 3 agrégation Voiture Camion Avion classe 4

Associations Agrégation: Rôle et multiplicité : Association transitive : si voiture est composée de moteur et si moteur est composé de courroie, alors voiture est composée de courroie Association non symétrique : si voiture est composée de moteur, moteur ne peut pas être composé de voiture Association qui peut être réflexive : une fonction peut être composée d’autres fonctions Rôle et multiplicité : Une classe a un rôle dans une association. Les rôles portent une information de multiplicité précisant le nombre d’associations auquel une instance d’objet peut être associée. Les multiplicités les plus courantes sont : 1 / 0..1 / m..n / * / 0..* / 1..*

Nommage des associations constructeur véhicule Construire> produit fabricant <construit par <Transporte passager véhicule personne véhicule Conduit> conducteur véhicule propriétaire Possède> véhicule <Emploie employé employeur personne entreprise Dirige> directeur société Possède> société actionnaire

Multiplicité des associations 1 0 .. 1 m .. n * ou 0 .. * 1 .. * Un et un seul (obligatoire) Zéro ou un (optionnel) De m à n (entiers) quelconque Au moins 1 Personne Société Employeur Employé 1 0..* N°SS Nom prénom N°SIREN

Classe-association Etudiant Travail 1 Réalise > 0 .. * 0 .. * 0..* Diplôme Note Mention Valeur = [0, 20] 0..1 Chambre Numéro

Contraintes personne compte Est_titulaire> {Ordonnée} personne 0 .. * 1 {Ordonnée} 0 .. * personne classe Parent d ’élève {Sous ensemble} 0 .. * Délégués 0 .. * personne université Enseignants {Ou-exclusif} 0 .. * Etudiants

Grenoble INP Génie industriel 2A ICL MSI – UML 1 Agrégation Livre Chapitre 1 .. * {Ordonnée} 1 {Ordonnée} 1 .. * Paragraphe

La composition traduit une dépendance existentielle forte. Homme Tête 1 1 Bâtiment Salle 1 * La composition traduit une dépendance existentielle forte.

Merci de « jouer » les animations du ppt Complément de modélisation statique : Classes / objets, Héritage, Agrégation, composition patron de normalisation ou Métaclasse2 ou Type-exemplaire2 Merci de « jouer » les animations du ppt L’exemple des classes héritées est issu du site de Pierre Alain Muller (http://uml.free.fr/) Métaclasse et Type-exemplaire sont les appellations retenues par Laurent AUDIBERT

est_interprété_par> Exemple d’héritage Oeuvre Titre Date-sortie Auteur est_créée_par> * Nom Date naissance Nationalité 1 …* Livre Nbre pages ISBN Représentation Film Durée format - jouer-bande-annonce Opéra Durée est_joué> Lieu Date deb Date fin * 1 * interprète> * * Role est_interprété_par> Acteur BD Roman Nom Nom Date naissance Nationalité * Les attributs, méthodes (opérations) et associations de la classe mère sont « héritées » par les classes filles Si Y hérite de X, cela signifie que "Y est une sorte de X" (analogie entre classification et théorie des ensembles).

est_interprété_par> Exemple d’héritage : diagrammes d’objets et tableaux à compléter Oeuvre Titre Date-sortie Auteur est_créée_par> * Nom Date naissance Nationalité 1 …* Livre Nbre pages ISBN Représentation Film Durée format - jouer-bande-annonce Opéra Durée est_joué> Lieu Date deb Date fin * 1 * * interprète> * Role BD Roman est_interprété_par> Acteur Nom Date naissance Nationalité * Chaque instance de la classe “Livre” hérite et value TOUS les attributs définis dans Livre et dans la superclasse “oeuvre”

Autre exemple d’héritage pour un antiquaire Article Date-entrée Prix date-vente Vendeur Acquis de> * Nom Adresse mail 1 …* Meuble Poids Lampe puissance Bicyclette Type (VTT, VTC, course) Chaise Table Armoire Longueur largeur Les attributs, méthodes (opérations) et associations de la classe mère sont « héritées » par les classes filles Si Y hérite de X, cela signifie que "Y est une sorte de X" (analogie entre classification et théorie des ensembles).

Eléments de l’ensemble “Oeuvre” Héritage : vision ensembliste Oeuvre Titre Date-sortie Film Durée format - jouer-bande-annonce Livre Nbre pages ISBN Opéra BD Roman Article Date-entrée Prix date-vente Lampe puissance Meuble Poids Bicyclette Type (VTT, VTC, course) Chaise Table Longueur largeur Armoire Oeuvre Article Film Opéra Livre Lampe Velo Meuble Roman BD Chaise Table Armoire Eléments de l’ensemble “Oeuvre”

Agrégation -- composition Appartement Date-construction Prix Adresse Classe energie 1 Pièce Nom surface Un appartement est composé de pièces, elle-même constituée de meubles. Le nombre de pièces et la surface de l’appartement peuvent se calculer à partir des pièces qui le composent Le losange qui désigne l’agrégation suffit pour « qualifier » l’association (pas besoin de la nommer). Le cout du mobilier peut être calculé à des fins d’assurance. Surface ? Nbre pièces Cout-mobilier * 1 * Meuble Nom Poids État Prix-estimé L’agrégation définit l’appartenance d’éléments à un sur-ensemble. Se note par un losange ajouté à l’association. Si Y est composé de X, cela signifie que « X est un élément de Y".

Patron normalisation – Famille de produits Modèle véhicule Des exemples Le livre au sens œuvre (ouvrage) et l’exemplaire de livre Le modèle de véhicule et l’exemplaire de véhicule immatriculé Le type de machines et l’exemplaire dans l’atelier Le modèle d’enregistrement qualité et l’enregistrement (daté). L’itinéraire et la sortie dans un système comme www.skitour.fr Nom Constructeur Longueur Largeur Taille pneus Nbre places Véhicule N°immatriculation Kilométrage Date last maintenance couleur Nom ? Constructeur ? Longueur ? Largeur ? Taille pneus ? Nbre places ? 1 A pour modèle> * Nbre moyen panne Nbre véhicules Chaque instance de la classe “Véhicule” value les attributs définis dans Véhicule : N°immatriculation, Kilométrage, Date last maintenance, couleur Chaque véhicule appartient à une “famille” (modèle) qui lui permet d’accéder aux valeurs des attributs de la famille : Nom, Constructeur, Longueur, Largeur, Taille pneus, Nbre places Le « patron » normalisation permet de définir et partager des propriétés entre les exemplaires d’une même famille de produits ou d’enregistrements. Les attributs communs (resp. associations) sont définis au niveau du « modèle, les attributs spécifiques (resp. associations) au niveau de l’exemplaire. Des méthodes permettent d’accéder à tout ou partie des attributs communs à partir des exemplaires.

Patron normalisation – Exemples Un exemple Le livre au sens œuvre (ouvrage) et l’exemplaire de livre Ouvrage-Livre Auteurs Titre Editeur ISBN Format Nbre pages Exemplaire Date acquisition Titre ? Auteurs ? disponible ? 1 A pour modèle> * Nbre moyen emprunts Nbre exemplaires Et plus exactement Ouvrage-Livre Abonné Numero Nom Adresse Titre Editeur ISBN Format Nbre pages Auteur Exemplaire Date acquisition Titre ? Auteurs ? disponible ? A pour modèle> * 1 …* 1 Nom Date naissance Nationalité écrit_par> * 1 Prêt Date emprunt Nbre moyen emprunts Nbre exemplaires Souscrit> * * * concerne>

Domaine des réservations Domaine de l’offre de vols Patron normalisation – Exemples Un exemple Les vols hebdomadaires et les vols effectifs Exemple traité en cours Compagnie Vol-générique 1 0 .. * départ> 1 nom numéro heureDépart heureArrivée capacité Aeroport propose> affréteur arrivée> 0 .. * 1 1 .. * Domaine des réservations 0 .. * faitEscale> * {ordered} Vol 1 dateDépart dateArrivée 1 InfosEscale Est-décrit-par> Client Réservation concerne> heureDépart heureArrivée nom téléphone e-mail Fax adresse 0..* date effectue> 0..* ouvrirRéservation () fermerRéservation () Horaires ? Capacité ? Domaine de l’offre de vols 1 0..* annuler () confirmer () totalfacturé ()

3 façons de modéliser des dépendances entre instances de classes Conclusion 3 façons de modéliser des dépendances entre instances de classes Héritage, spécialisation, généralisation (inclusion ensembliste) – Partage de structures, mais valeurs indépendantes des propriétés. Agrégation, composition (objets composites) Patron de Métaclasse - normalisation – Lien Produit – Famille ; Type-exemplaire (partage de valeurs de propriétés entre objets d’une même famille)

Exemple de diagramme de classes Outil Simulation Créer_Projet() Modifier_Projet() ModifierParamètre_Projet() Créer_Problème() Modifier_Problème() ModifierParamètre_Problème() Créer_Etude() Modifier_Etude() ModifierParamètre_Etude() FaireAppelAUneAncienne_Etude() Conclure_Etude() Créer_Cycle() Modifier_Cycle() ModifierPramètre_Cycle() Rajouter_Entité() Conclure_Cycle() 1..* Projet NomProjet NuméroPDM DateDebutProjet Projet() Tes_infos?() Nouv_Paramètres() Problème Titre_Problème Objectif Delai Prix NiveauPriorite FicheEtude Conclusion Problème() Nou_Paramètres() Etude Titre_Etude NomPièce ButEtude TypeEtude Etude() Tes_infos() Ajouter_Conclusion() 1 1..* 1..* 1 Induit 1..* 1..* 1..* LesProjets LesProblèmes 1 1 EstResoluPar 0..* 0..* 0..1 0..1 0..1 0..1 Suivant ComplétéePar 0..* 0..* 0..* 0..* LesEtudes 1..* 1..*

Passage Classes -- relationnel Passage d’un diagramme de classe à un modèle relationnel – Implémentation dans MS-ACCESS

Règle 0 & 1: attribut et classe Passage du modèle statique UML au relationnel : les associations produit Réf-produit Libellé-p Prix-vente-p fournisseur Code-fournisseur Adresse Téléphone Classe Relation / Table Produit (Réf-produit, Libellé-p, Prix-vente-p) Fournisseur (Code-fournisseur, Adresse, Téléphone)

Règle 2 : relation de multiplicité (1) Passage du modèle statique UML au relationnel : les associations fournisseur Code-fournisseur Adresse Téléphone Classe < fournir 1 produit Réf-produit Libellé-p Prix-vente-p remise Produit (Réf-produit, Libellé-p, Prix-vente-p, Code-fournisseur, remise) Fournisseur (Code-fournisseur, Adresse, Téléphone) Relation / Table

Règle 3 : relation de multiplicité (0-1) Grenoble INP Génie industriel 2A ICL MSI – UML 1 Règle 3 : relation de multiplicité (0-1) Passage du modèle statique UML au relationnel : les associations Classe produit Réf-produit Libellé-p Prix-vente-p fournisseur Code-fournisseur Adresse Téléphone * < fournir 0-1 remise Produit (Réf-produit, Libellé-p, Prix-vente-p, remise, Code-fournisseur) Fournisseur (Code-fournisseur, Adresse, Téléphone) Relation / Table

Règle 4 : relation de multiplicité (0..*) (1..*) Passage du modèle statique UML au relationnel : les associations fournisseur Code-fournisseur Adresse Téléphone < fournir 0..* ou 1..* produit Réf-produit Libellé-p Prix-vente-p remise Classe Produit (Réf-produit, Libellé-p, Prix-vente-p) Fournisseur (Code-fournisseur, Adresse, Téléphone) Relation / Table Fournir (Réf-produit, Code-fournisseur, remise)

Règle 5 : relation réflexive orientée Passage du modèle statique UML au relationnel : les associations Père (nom-fils, nom-père) Relation / Table Classe Personne nom 0..* 1 père de >

Règle 6 relation réflexive symétrique Passage du modèle statique UML au relationnel : les associations Relation / Table Personne (Nom) Frère (nom, nom) Classe Personne nom 0..* Attention, la relation étant transitive, des traitements devront être associés au modèle. 0..* frère de

http://theses.ulaval.ca/archimede/fichiers/19524/ch02.html