Michel Tollenaere U.M.L. fondamentaux 1 Modélisation objet des données et processus UML (Unified Modelling Language) Michel Tollenaere (INPG) tollenam/Ipro3

Michel Tollenaere U.M.L. fondamentaux1

Modélisation objet des données et processus

UML (Unified Modelling Language)

Michel Tollenaere (INPG)http://www.g-scop.fr/~tollenam/Ipro3

Master 2 Mécanique et Génie MécaniqueParcours : Intégration en Conception de Produit


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.orghttp://uml.free.fr/ site en françaisen France Pierre Alain Muller (U-Mulhouse) et Valtechhttp://uml.developpez.com/

Outils : StarUML 5.0 Objecteering http://www.objecteering.com/us/produits_pe.php

Rational ROSE , http://www.rational.complus de 30 outils de modélisation et de CASE(Computer Aided Software Engineering)


TechnologieTechnologie

ArchitectureArchitecture

PERSONNE Num_securite_sociale Nom Prenom Code_postal Telephonen-uplet1 1 76 02 99 167 098 Dupont Marcel 41500 06 08 78 65 88n-uplet2 2 76 04 95 165 008 Durand Elisabeth 31900 02 99 167 098n-uplet3 1 78 12 38 122 4332 Faure Bertrand 38700 04 38 56 45 32n-uplet4 1 68 02 99 5649 876 Dumontier Michel 75016 01 55 45 34 87

STAGE Num_securite_sociale D_type_stageTitren-uplet1 1 76 02 99 167 098 Inge_Adjoint Définition d'une politique Qualitén-uplet2 2 76 04 95 165 008 Inge_Adjoint Mise en place d'un SI pour la maintenancen-uplet3 1 68 02 99 5649 876 EDT Reconfiguration des achatsn-uplet4 2 76 04 95 165 008 EDT Reconfiguration des achatsn-uplet5 1 76 02 99 167 098 PFE Mise en place d'un ERP

propriétés propriétés

Constituant ConstituantConstituantConstituant

Document Adobe

Acrobat

: acteur (intéragissant avec VEGA2)

Système (VEGA2)

message

messagemessage

message

objet 1

objet 3

objet 2 objet 4

lien exprimant que "objet 2 est

composé de objet 3"

lien exprimant que "objet 2 a une relation avec objet 4"

lien exprimant que "objet 2 est une sorte de objet 1"

UML • modelling information systems• at conceptual level• at logical level


Booch method OMT

Unified Method 0.8OOPSLA ´95

OOSEOther methods

UML 0.9Web - June ´96

publicfeedback

Final submission to OMG, Sep ‘97

First submission to OMG, Jan ´97

UML 1.1OMG Acceptance, Nov 1997

UML 1.3

UML 1.0UML partners

Creating the UML

UML 2.0 2005UML 2.22009


Meyer

Before and after conditions

Harel

StatechartsGamma, et al

Frameworks and patterns,

HP Fusion

Operation descriptions and message numbering

Embley

Singleton classes andhigh-level view

Wirfs-Brock

Responsibilities

Odell

Classification

Shlaer - Mellor

Object lifecycles

Rumbaugh

OMT

Booch

Booch method

Jacobson

OOSE

Contributions to the UML


• diagramme de classes

• diagramme d’objets

• diagramme de composants

• diagramme de déploiement

Statique (ce que le système EST)

• diagramme de séquence

• diagramme de collaboration

• diagramme d’états-transitions

• diagramme d’activités

Fonctionnel (ce que le système FAIT)

Dynamique(comment le système EVOLUE)

• diagramme de cas d’utilisation


Axes de modélisation d ’un système


• Conceptuel• organisationnel• logique• physique

En UML, les mêmes modèles peuvent être utilisés à différents niveaux d’abstraction du plus conceptuel à l’implantation.

On peut donc appliquer des mécanismes de transformation continue.

Niveaux d’abstraction d’un SI


• diagramme de cas d’utilisation

• diagramme de classes

• diagramme de séquence


• diagramme d’objets

• diagramme d’états-transitions

• diagramme d’activités (nous utiliserons IDEF 0)

• diagramme de composants

• diagramme de déploiement

Les 9 diagrammes d’UML 1.1 (13 diag en 2.0)


Diagramme

Classes

Composants DéploiementCollaboration

Etats Transitions Séquence

Objets

Cas d ’utilisationCas d ’utilisation Classes Etats Transitions Séquence

Ceci est un commentaire

Description UML des diagrammes UML

Activité


Cas d’utilisation

une fonctionnalité attendue du système par les différents acteurs.

cas d'utilisation

Exemples : Quelques diagrammes

: acteur (intéragissant avec VEGA2)

Système (VEGA2)

message

messagemessage

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.

Diagramme de Classes

objet 1

objet 3

objet 2 objet 4

lien exprimant que "objet 2 est

composé de objet 3"

lien exprimant que "objet 2 a une relation avec objet 4"

lien exprimant que "objet 2 est une sorte de objet 1"


Modèle Fonctionnel

• Use Cases = cas d’utilisation• diagramme de collaboration


Représente les fonctions du système de point de vue de l ’utilisateur.

Cas d ’utilisationActeur

relation

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

Ceci est un cas d’utilisation

Ceci est une relation

Ceci est un acteur

Diagramme de cas d’utilisation


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.

Déclencher virementclient

• 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).

Déclencher 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

Déclencher virement

« extend »

Relations entre cas d ’utilisation


Source http://uml.free.fr/


Récupère les

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

Exemple

Définit les contraintes mécaniques

Conçoit les schémas et nomenclatures

Gère la création et les révisions des dossiers variantes

Gère la création et les révisions d ’un job

DéveloppeurGestion des schémas

Responsable

CFAO

Gestion des jobs

Gestion des contraintes

Gestion des dossiers

<<dépend>>

Responsable BE

schémas

Récupère les contraintes

Acteurs : diagramme de cas d’utilisation


Interactions entre objets du système avec un accent particulier sur la structure spatiale statique des objets (contexte des objets). Les messages sont numérotés pour indiquer l’ordre des envois.

Permet de situer le contexte du système.

Message : Simple, Asynchrone, Synchrone, Minuté

: ascenseur

: cabine

: porte

: lumière

1 : monter

3 : fermer

2 : allumer

Objet 1

Objet 2

Objet 3

1 : message

3 : message

2 : message

4 : message 5 : message

Diagramme de Collaboration


Modèle Statique

• diagramme d ’objets• Diagramme de classes


TaVoiture : Voiture

Marque = Renault

Modèle = Megane

Immatriculation = 648DBX38

1re immatriculation = 16 sept 2009

Kilométrage = 125 000

Kilométrage-annuel ? ()

AutreVoiture : Voiture

Marque = Renault

Modèle = Megane





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».

Objets et classes

Voiture

Marque : chaîne

Modèle : chaîne

Immatriculation : chaîne (8)

1re immatriculation : date

Kilométrage : entier

Kilométrage-annuel ? ( )

Kilometrage_annuel_moyen ( )

MaVoiture : Voiture

Marque = Renault

Modèle = Megane






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.

Personne

âge : entier

patron

collaborateur

1

*

Diagramme de classes

Nom de l’objet : Classe

Attributs = valeurs

Liens diagramme d’objets -/- diagramme de classes

Etienne : personne

âge = 35

Jean-Luc : personne

âge = 25

patron

Diagramme d ’objets

collaborateur

emploie>

Abs

trac

tionConcrétisation


Structure statique d’un système, en termes de classes et de relations entre ces classes.

Nom de classe

Attributs

Opérations ()

Voiture

Couleur

Cylindrée

Vitesse max

Démarrer ()

Accélérer ()

Freiner ()

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

Syntaxe:

• nom_attribut : type_attribut = valeur initiale

• nom_opération (nom_argument : type_argument = valeur_par_défaut, …) : type_retourné

exemple :

Diagramme de classes


Nommage des associations

véhiculeconstructeur

<construit par

Construire>fabricant

produit

véhiculepersonneConduit>conducteur véhicule

Possède>propriétaire véhicule

<Transportepassager véhicule

entreprisepersonneDirige>directeur société

Possède>actionnaire société

<Emploieemployé employeur


Personne SociétéEmployeur

Employé 1

0..*

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

Multiplicité des associations


Agrégation:

• 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 systémique : si voiture est composée de moteur, moteur ne peut pas être composé de voiture

• Association qui peut être réflexive : exemple, une fonction peut être composée d’autres fonctions, un sous ensemble d’autres sous ensembles.

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..*

Associations


Classe-association

Permet de «qualifier» plus finement une association

Commande

+Num-commande+date+PoidsTotal

SociétéTransport

+NumSIRET+NomCommercial+TypeTransport

Véhicule

+NumImmatriculation+ChargeUtile

Chauffeur

+Nom+Prénom+Adresse+TypePermis

conduit

0..1

1...2

affrète

1..*

0..1

traite

*

0..1

SociétéTransport

+NumSIRET+NomCommercial+TypeTransport

Véhicule

+NumImmatriculation+ChargeUtile+PermisRequis

Chauffeur

+Nom+Prénom+Adresse+TypePermis

+KilometrageAnnée()

conduit

0..*

0..*

affrète 1..*

0..1PeriodeConduite

+t0+tf+kilometrage


Placement des attributs et des associations

Diplôme

TravailEtudiant

Chambre

Réalise >

Note- valeur

Numéro

Mention

0..* 0..*

1

0..1

0..*

1


Contraintes

comptepersonne

{Ordonnée}

Est_titulaire>

10 .. *

classepersonne{Sous ensemble}

0 .. *

0 .. *

Parent d ’élève

Délégués

universitépersonne

{Ou-exclusif}

0 .. *

0 .. *

Enseignants

Etudiants


Agrégation

ChapitreLivre

{Ordonnée}1

1 .. *

Paragraphe

{Ordonnée}1 .. *


Composition

TêteHomme 1 1

La composition traduit une dépendance existentielle forte.


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

NomProjetNuméroPDMDateDebutProjet

Projet()Tes_infos?()Nouv_Paramètres()Créer_Problème()

Problème

Titre_ProblèmeObjectifDelaiPrixNiveauPrioriteFicheEtudeConclusion

Problème()Tes_infos?()Nou_Paramètres()Créer_Etude()

Etude

Titre_EtudeNomPièceButEtudeTypeEtudeConclusion

Etude()Tes_infos()Nouv_Paramètres()Créer_Cycle()Ajouter_Conclusion()

11..*

1..*

1

0..*

EstResoluPar

1

0..*

1..*

11..* Induit

1..*

LesProblèmes LesProjets

1..*1..*LesEtudes

0..1

ComplétéePar

0..*

0..1

0..*

0..1

Suivant

0..*

0..1

0..*

Exemple de diagramme de classes


Modèle Statique Passage d’un diagramme de classe UML

à un modèle relationnel pour SGBD


Relation / Table

Produit (Réf-produit, Libellé-p, Prix-vente-p)

Fournisseur (Code-fournisseur, Adresse, Téléphone)

Règle 0 & 1: attribut et classe

produitRéf-produitLibellé-pPrix-vente-p

fournisseurCode-fournisseurAdresseTéléphone

ClassePassa

ge du modèle statique

UML au relationnel :

les associations


Produit (Réf-produit, Libellé-p, Prix-vente-p, Code-fournisseur, remise)


Relation / Table

Règle 2 : relation de multiplicité (1)


Classe

< fournir 1produitRéf-produitLibellé-pPrix-vente-p

Passage du modèle sta

tique UML au

relationnel :

les associations

Remise- valeur


Classe

Produit (Réf-produit, Libellé-p, Prix-vente-p, remise, Code-fournisseur)


Relation / Table

Règle 3 : relation de multiplicité (0-1)


< fournir 0-1produitRéf-produitLibellé-pPrix-vente-p


tique UML au

relationnel :

les associations

*

Remise- valeur


Produit (Réf-produit, Libellé-p, Prix-vente-p)


Relation / Table

Fournir (Réf-produit, Code-fournisseur, remise)

Règle 4 : relation de multiplicité (0..*) (1..*)


< fournir 0..*ou1..*

produitRéf-produitLibellé-pPrix-vente-p

ClassePassa

ge du modèle statiq

ue UML au

relationnel :

les asso

ciations

Remise- valeur


Père (nom-fils, nom-père)

Relation / Table

Personne

nom

père de >

Classe

0..*

1

Règle 5 : relation réflexive orientée


tique UML au

relationnel :

les associations


Personne

nom

frère de

Classe

Personne (Nom)Frère (nom, nom)

Relation / Table

Règle 6 relation réflexive symétrique


tique UML au

relationnel :

les associations

Attention, la relation étant transitive, des traitements devront être associés au modèle.


Modèle Dynamique

• Diagramme d’état transition• Diagramme de séquences


Diagramme d ’états-Transition

Description des séquences possibles d’états et d ’actions par lesquelles un objet peut passer tout au long de sa vie. Ces séquences résultent de sa réaction à des événements discrets.

Eléments du diagramme :

• état : situation d’un objet à un moment donné

• transition : connexion entre deux états, permettant le passage d’un état à l’autre

• événement : occurrence d ’une situation donnée dans le domaine du système qui déclenche la transition

• garde : condition booléenne qui valide ou non le déclenchement d’une transition lors de l’occurrence d’un événement (cas de plusieurs transitions exclusives déclenchées par le même événement)

• action : opération exécutée pendant que l’objet est dans un état donné ou lorsque une transition est déclenchée (correspondant à des opérations déclarées dans la classe de l’objet destinataire). Une action d’un état est dite activité quand l’opération associée a un temps d’exécution non négligeable (do : nom_opération) (exemple notification)

Etat A

action

do:opération

Etat BEvénement [garde] / Action

…. ….

état initial état final


Personne

age Société0..11..*

Les personnes ne possèdent pas toutes un emploi et se trouvent, à un moment donné, dans un des états suivants : en activité, au chômage, à la retraite

L’état d ’une personne donnée est déterminé selon son âge et la présence ou non d ’un lien vers une société.

Diagramme d ’états-Transition

Exemple

Diagramme de classes Diagramme d ’états-transitions

En activité

do: travailler

Au chômage

A la retraite

Perte d ’emploi

Embauche

Plus de 60 ans

Plus de 60 ans


Diagramme de Séquences

Pour chaque cas d’utilisation , nous pouvons décrire un ou plusieurs scénario, décrit chacun par un diagramme de séquences.

Diagramme de séquence : exprime la séquence des interactions entre objets du système selon un point de vue temporel, pour réaliser le cas d’utilisation.



Objet 1 Objet 2

1 : [condition A] message

2 : message synchrone

4 : message

6 : [condition B] message

9 : message asynchrone

7 : message réflexif

Evénement / Communication

entre objets

Objet 33 : message de création

5 : message

8 : message de destruction

Période d’activité de l’objet


• message synchrone: l’émetteur est bloqué et attend que l’appelé ait fini de traiter le message (message 1)

message asynchrone: l’émetteur n’est pas bloqué et peut continuer son exécution (message 6)

• Un message réflexif indique souvent un point d ’entrée dans une activité de plus bas niveau qui s ’exerce entre objets contenus par l ’objet composite (message 7)

• Un message dont les délais de transmission sont non négligeables est matérialisé par une flèche oblique (message 4)

• Messages conditionnés : flèches prenant leur origine au même instant avec des conditions mutuellement exclusives (messages 1 et 6)

• Possibilité de compléments d ’informations sous forme de texte libre ou de pseudo-code à côté du diagramme

• Période d ’activité : temps pendant lequel un objet effectue une action, directement ou par l ’intermédiaire d ’un autre objet sous-traitant

• Des contraintes temporelles peuvent être exprimées en graduant la ligne de vie (pour dire par exemple: « 10 secondes plus tard »)


Cas particuliers



Exemple

AppelantLigne

téléphonique Appelé

décroche

tonalité

numérotation

sonnerieindication de sonnerie

décroche

allô


Gestion des composants externes: Création composant constance

: BE

système

demande création

vérifier droit utilisateur

afficher dialogue de création [droit = OK]

Saisie code composant - Valider

rechercher infos dans fichier export de

constanceaffichage infos relatifs au composant [composant existe]

affichage dialogue sans infos [composant inexistant]

valider création

création du composant dans VEGA

fabricantréf-fabricantdésignation

saisie manuelle infos relatifs au composant


Gestion des composants externes: Mise à jour composant constance

Solution N°1 (non retenue): Avec validation par l’opérateur Système

: BE

fichier export de constance

arrivée (mise à disposition)

créer collection des composants modifiés

afficher collection

sélectionner composants

valider modification

mise à jour des composants sélectionnés dans VEGA

rechercher composants constance dans VEGA non

marquésrechercher les composants

comparer fichier par rapport à composants

fournir composants (désignation / fabricants / réf_fabricant)

marquer composants modifiés

informer de l'arrivée de la collection

demander collection

démarquer les composants sélectionnés


fichier export de constance

Système

arrivée (mise à disposition)

mise à jour composants dans

rechercher les composants dans fichier d'export

fournir composants (désignation / fabricants / réf_fabricant)

comparer fichier par rapport aux composants constance dans VEGA [ si composant

present dans fichier constance]

fabricantdésignationréf-fabricant

rechercher dans VEGA les composants constance

enregistrer les modifications dans un fichier Log

Gestion des composants externes: Mise à jour composant constance

Solution N°2 (retenue): avec validation par l’opérateur


Modèle Organisationnel de Traitements (MOT) de Merise

• Enchaînement des opérations ou taches• condition d’enchaînement• acteur affecté (qui ?)• période de traitement (quand ?)




Diagramme de Classes Métier

comp. externe comp. externe

plan CIP<<rep>>

plan mécanique<<rep>>

comp. interne

CdC<<rep>>

structure

schema<<rep>>

plan CIM<<rep>>

composant

Spec de test<<rep>>

Accessoires

sous-ensembleEM

<<rep>>

comp. mécanique

caractéristiques<<rep>>

plan-mécanique<<rep>>

comp. interne

CdC<<rep>>

CIP

plan<<rep>>

conditionnement

Master<<rep>>

soft

étiquette vierge

etiquette

comp. électronique

Micro-processeurCarte electronique

notice<<rep>>

Documentation


Modélisation de S.I.Étude de cas

Compagnie aérienne : CRM

ENSGI – MSI 2ème annéeMichel Tollenaere

http://gilco.inpg.fr/~tollenaere/msi/MSI2A-etude-cas.ppt

Inspiré deUML par la pratique

2ème EditionPascal Roque

Groupe Eyrolles, 2003ISBN : 2-212-11246-7


ÉTUDE D’UN SYSTÈME DE GESTION DE LA RELATION CLIENT POUR UN RESEAU D’AGENCES DE VOYAGES

Un réseau d’agences de voyages désire améliorer son système d’information pour la relation avec sa clientèle. Il a été convenu de commencer ce travail par la gestion de la composante « transport aérien ».Les fonctions principales attendues du système sont :-- permettre une sélection dans l’offre de vols et de places disponibles.-- assurer les réservations pour les passagers.-- permettre aux compagnies aériennes partenaires d’ouvrir ou de fermer des vols-- mettre en place des tableaux de bord permettant de mieux connaître les clients.

Les principaux utilisateurs visés par le système sont :-- les hôtesses dans les agences qui sont en contact avec les clients.-- les opérateurs de guichets dans les aéroports qui délivrent les cartes d’embarquement aux passagers-- les responsables du réseau d’agences qui désirent disposer de tableaux de bord sur l’activité-- les clients et les passagers via Internet-- les compagnies aériennes partenaires

Les interviews des experts métier ont permis de résumer leur connaissance du domaine sous la forme des phrases suivantes :1. Des compagnies aériennes proposent différents vols.2. Un vol est ouvert à la réservation et refermé sur ordre de la compagnie.3. Un client peut réserver un ou plusieurs vols, pour des passagers différents.4. Une réservation concerne un seul vol et un seul passager.5. Une réservation peut être annulée ou confirmée.6. Un vol a un aéroport de départ et un aéroport d’arrivée.7. Un vol a un jour et une heure de départ, et un jour et une heure d’arrivée.8. Un vol peut comporter des escales dans des aéroports.9. Une escale a une heure d’arrivée et une heure de départ.10. Chaque aéroport dessert une ou plusieurs villes.


Fonctions et acteurs : Cas d’utilisation

réserver

Hôtesse d’agence

Fonctions : permettre une sélection dans l’offre de vols et de places disponibles.-- assurer les réservations pour les passagers.-- permettre aux compagnies aériennes partenaires d’ouvrir ou de fermer des vols-- mettre en place des tableaux de bord permettant de mieux connaître les clients.

Délivrer carte embarquement

Guichet aéroport

Ouvrir et fermer des vols

Compagnie

Consulter disponibilités

Les principaux utilisateurs visés par le système sont :-- les hôtesses dans les agences qui sont en contact avec les clients.-- les opérateurs de guichets dans les aéroports qui délivrent les cartes d’embarquement aux passagers-- les responsables du réseau d’agences qui désirent disposer de tableaux de bord sur l’activité-- les clients et les passagers via Internet-- les compagnies aériennes partenaires

Consulte tableaux de bord

Responsable agence

« extend »

Réserver par Internet

Consulter disponibilités par

Internet

Client et passager

« extend »


Modèle statique : classes et objets

1. Des compagnies aériennes proposent différents vols.

VolCompagnie

propose>1.. ? 1 .. *

nom numéro


Modèle statique : classes et objets

2. Un vol est ouvert à la réservation et refermé sur ordre de la compagnie.

VolCompagnie

propose>1 1 .. *

nom NuméroÉtat : (ouvert, fermé)

affréteur


Modèle statique : classes, états - transitions

2. Un vol est ouvert à la réservation et refermé sur ordre de la compagnie.

VolCompagnie

propose>1 1 .. *

nom

affréteur

NuméroÉtat : (ouvert, fermé)

Ouvert état

initial

Fermé

Ouverture par compagnie

état final

Fermeture par compagnie

Diagramme d’état – transition de la classe « Vol »

Dia

gram

me

d’ét

at –

tran

siti

onD

iagr

amm

e de

cla

sses

OuvrirRéservation ()FermerRéservation ()


Modèle dynamique : diagramme de collaboration

VolCompagnie

propose>1 1 .. *

nom

affréteur

Numéro

Dia

gram

me

de c

olla

bora

tion

Dia

gram

me

de c

lass

es

ouvrirRéservation ()fermerRéservation ()

AirFrance : Compagnie

AF506 : Vol

AF519 : Vol

AF714 : Vol

1 : ouvrirRéservation ()

2 : fermerRéservation ()

3 : ouvrirRéservation ()


Continuons d’affiner la classe « Vol »

VolCompagnie

propose>1

1 .. *nom

affréteur

numérodateDépartheureDépartdateArrivéeheureArrivée

Ouvert état

initial

Fermé


état final




6. Un vol a un aéroport de départ et un aéroport d’arrivée.7. Un vol a un jour et une heure de départ, et un jour et une heure d’arrivée.8. Un vol peut comporter des escales dans des aéroports.9. Une escale a une heure d’arrivée et une heure de départ.10. Chaque aéroport dessert une ou plusieurs villes.


Les aéroports

Vol

21 .. *

numérodateDépartheureDépartdateArrivéeheureArrivéeaeroportdépartaeroportArrivée


6. Un vol a un aéroport de départ et un aéroport d’arrivée.

{ordered}

utilise>

Aeroport

nompays


Les aéroports (suite)

Vol

1

1 .. *

numérodateDépartheureDépartdateArrivéeheureArrivée



part-de>

Aeroport

nompays

arrive-à>

1

AeroportArrivée

Aeroportdépart

1 .. *


Les aéroports (fin)

Vol

11 .. *numérodateDépartheureDépartdateArrivéeheureArrivée



départ>

Aeroport

nompays

11 .. * arrivée>


Les villes

Vol



départ>

Aeroport

nompays

11 .. * arrivée>

10. Chaque aéroport dessert une ou plusieurs villes.

Ville

nompays

1.. *?dessert>


Association « dessert » (multiplicité)

Aeroport

nompays

10. Chaque aéroport dessert une ou plusieurs villes.

Ville

nompays

1.. **

dessert>

Charles de Gaulle : Aeroport Paris :Ville

Orly : Aeroport

Metz-nancy-lorraine : Aeroport

Metz :Ville

Nancy :Ville

Passage par les diagrammes

d’objets


ou…. factorisation des attributs

Aeroport Ville

1.. **

dessert>

Lieu-geo

nompaysdecalage-horaireAffiche(carte)

Affiche(carte)Affiche(carte)


Vol



départ>

Aeroport

nompays

10 .. * arrivée>

*0 .. * faitEscale>

InfosEscale

heureDépartheureArrivée

Les escales

{ordered}


Vol



départ>

Aeroport

nompays

10 .. *arrivée>

*0 .. *faitEscale>

InfosEscaleheureDépartheureArrivée

Ville

nompays

1.. **dessert>

Compagnie

propose>1

1 .. *

nom

affréteur

Récapitulons (1)

Ouvert état

initial

Fermé


état final



+

{ordered}


Vol

numérodateDépartheureDépartdateArrivéeheureArrivéecapacité


Réservation

concerne>0..*

1annuler ()confirmer ()

Les réservations

3. Un client peut réserver un ou plusieurs vols, pour des passagers différents.4. Une réservation concerne un seul vol et un seul passager.5. Une réservation peut être annulée ou confirmée.

Passagernomprénomtéléphonee-mailnum-cartenb-pts

créditer-pts (res)

concerne>

1


Vol



Réservation

concerne>0..*

1annuler ()confirmer ()

Les réservations

3. Un client peut réserver un ou plusieurs vols, pour des passagers différents.


créditer-pts (res)

conc

erne

>

1

0..*

Clientnomtéléphonee-mailFaxadresse

totalfacturé ()

effectue>

1 0..*

date


Vol

10 .. *numérodateDépartheureDépartdateArrivéeheureArrivéecapacité


départ>Aeroport

10 .. *arrivée>

*0 .. *faitEscale>

InfosEscale

heureDépartheureArrivée

Ville

1.. **dessert>

Compagnie

propose>

1

1 .. *

nom

affréteur

Récapitulons (2)

Ouvert

état initial

Fermé


état final



+

Réservation conc

erne

>

0..*

1

annuler ()confirmer ()


créditer-pts (res)

conc

erne

>

1

0..*


totalfacturé ()

effectue>

1 0..*

date

Lieu-geonompaysdecalage-horaire

{ordered}


Dynamique de la réservation

Vol


ouvrirRéservation ()fermerRéservation ()Réservation

conc

erne

>

0..*

1


Passager

nomprénomtéléphonee-mailnum-cartenb-ptscréditer-pts (res)

conc

erne

>

1

0..*

date


Guichet aéroport

Guichet aéroport

Liste passagers (n° vol)

Diagramme de séquences

Passager

Vol Réservation Passager

Présente identité

passagers (etat =

confirmé)

Délivrer carte

Si {état = attente paiement ; Demande

paiement}

Passager-id ()

Liste passagers ()

Passer (état = embarqué)

Sélectionne réservation

Passager-id


Dynamique de la réservation

Etat – transition de « réservation »

Guichet aéroport


Passager


Présente identité

passagers (etat =

confirmé)

Délivrer carte


paiement}

Passager-id ()



Vol


ouvrirRéservation ()fermerRéservation ()Réservation

conc

erne

>

0..*

1


Passager

nomprénomtéléphonee-mailnum-cartenb-pts

créditer-pts (res)

conc

erne

>

1

0..*

date

Passager-id

Liste passagers ()

Demandée

état initial

Confirmée

par client

état final

par compagnie

Diagramme d’état – transition de la classe « Réservation »

Payée

par aéroport embarquée

Annulée Jvol - 8



Implémentation dans MSAccess

Notez les pertes sémantiques sur : • les états – transitions, • les associations {ordered}, • l’héritage ville-aéroport ……. etc


Analyse de la classe « Vol »

• comporte de nombreuses responsabilités

• est elle en troisième forme normale ?

• la clef primaire « Num-vol » est elle correcte ?

• parle-t-on des vols « réguliers » ou affrétés ?

Vol

10 .. *numérodateDépartheureDépartdateArrivéeheureArrivéecapacité


départ>Aeroport

10 .. *arrivée>

*0 .. *faitEscale>


*

Compagnie

propose>

1

1 .. *

nom

affréteur

Réservation conc

erne

>

0..*

1



conc

erne

>

1


totalfacturé ()

effectue>

1 0..*

date

{ordered}

Domaine de l’offre de volsl’offre de volsDomaine des réservations


Analyse de la classe « Vol »

• Les éléments de l’offre sont plus stables que ceux des réservations

Vol-générique

10 .. *numéro

heureDépart

heureArrivée

capacité

départ>Aeroport

10 .. *arrivée>

*0 .. *faitEscale>


*

Compagnie

propose>

1

1 .. *

nom

affréteur

Réservationconcerne>

0..*

1



conc

erne

>

1


totalfacturé ()

effectue>

1 0..*

date

{ordered}

Domaine de l’offre de volsl’offre de vols

Vol

dateDépart

dateArrivée


Est-dé

crit-p

ar>

1

0..*

Domaine des réservations

== > les responsabilités sont mieux établies


Implémentation dans MSAccess

Reste à traiter l’aspect dynamique : • les requètes, • les formulaires et interfaces, • ……. etc


Traitement de l’embarquement

Guichet aéroport


Passager


Présente identité

passagers (etat =

confirmé)

Délivrer carte


paiement}

Passager-id ()



Vol


ouvrirRéservation ()fermerRéservation ()Réservatio

n conc

erne

>

0..*

1


Passagernomprénomtéléphonee-mailnum-cartenb-ptscréditer-pts (res)

conc

erne

>

1

0..*

date

Passager-id

Liste passagers ()

Demandée état

initial

Confirmée

par

client état

final

par compag

nie


Payée

par aéroport

embarquée

Annulée

Jvol - 8


Traitement de l’embarquement

Guichet aéroport


Passager


Présente identité

passagers (etat =

confirmé)

Délivrer carte


paiement}

Passager-id ()



Vol


ouvrirRéservation ()fermerRéservation ()Réservatio

n conc

erne

>

0..*

1


Passagernomprénomtéléphonee-mailnum-cartenb-ptscréditer-pts (res)

conc

erne

>

1

0..*

date

Passager-id

Liste passagers ()

Demandée état

initial

Confirmée

par

client état

final

par compag

nie


Payée

par aéroport

embarquée

Annulée

Jvol - 8



Guichet aéroport


Pays de Loire

ENS Cachan

ENSAM

Ile de France

Auvergne

Toulouse

Rhône Alpes Ouest

Lorraine

Nord Pas de calais

Dauphiné Savoie

Franche comté

Centrale Paris

Documents

Michel Tollenaere U.M.L. fondamentaux 1 Modélisation objet des données et processus UML (Unified Modelling Language) Michel Tollenaere (INPG) tollenam/Ipro3