michel tollenaere version 2.1 du 20 novembre 2012 grenoble inp génie industriel 2a icl msi – uml...

Michel Tollenaereversion 2.1 du 20 novembre 2012

Grenoble INP Génie industriel 2A ICL MSI – UML 1

1

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

Outils : 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)



2

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



3

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 UMLUML 2.0 2003



4

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



5

• 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



6

• 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



7

• 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 UML 1



8

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 9 diagrammes UML

Activité



9

Cas d’utilisation

une fonctionnalité attendue du système (VEGA2) 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"



10

cas d'utilisation

cas d'utilisation

cas d'utilisation

Acteur 1

Acteur 2

article

codedésignationprix-Urayonss-rayon

*

contient>1

Sous rayon

Rayonemplacementnom

Implantation

comporte

Rayon

Nomemplacement *

1

Implantation

Nomemplacement

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

état final

Pas de confirmation client après 1 mois



11

Modèle Fonctionnel

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



12

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



13

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.

virementclient

déclenche

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

Relations entre cas d’utilisations



14

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



15

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



16

Modèle Statique

• diagramme d ’objets• Diagramme de classes



17

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

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 ( )



18

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

Diagramme d’Objets

Etienne : personne

âge = 35

Jean-Luc : personne

âge = 25

patron

Diagramme d ’objets

collaborateur

emploie>

Abs

trac

tionConcrétisation



19

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



20

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 4

classe 3

classe 2

classe 1

agrégation

associa

tion

généralisation sp

écia

lisa

tion

véhicule

voiture camion avion

moteurconstructeur1 1..* 1..*1

Diagramme de classes : Relations entre classes



21

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

Associations



22

Nommage des associations

véhiculeconstructeur

<construit parConstruire>

fabricantproduit

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



23

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



24

Arité des associations

Salle

EnseignantEtudiant

DébutFin

Courslieu

Association d’arité 3



25

Placement des attributs et des associations

Diplôme

TravailEtudiant

Chambre

Réalise >

Note

Numéro

Mention

0..* 0..*

1

0..1

0..*

1



26

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



27

Agrégation

ChapitreLivre

{Ordonnée}1

1 .. *

Paragraphe

{Ordonnée}1 .. *



28

Composition

TêteHomme 1 1

La composition traduit une dépendance existentielle forte.



29

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



30

Modèle Statique

• Passage d ’un diagramme de classe à un modèle relationnel



31

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



32

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

remise

Passage du modèle sta

tique UML au

relationnel :

les associations



33

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

remise


tique UML au

relationnel :

les associations

*



34

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

remise

ClassePassa

ge du modèle statique UML au

relationnel :

les associations



35

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



36

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.

0..*

0..*

michel tollenaere version 2.1 du 20 novembre 2012 grenoble inp génie industriel 2a icl msi – uml...

Documents

uml uml

uml page

icl msi uml

methods uml

uml partners

squence diagramme

composants diagramme

systme est diagramme