Cours UML généalogie de UML – Cours et formation gratuit

(1)

Jean-Marc Jézéquel

IRISA/CNRS et

Yves Le Traon IRISA/Ifsic

Unified Modeling Language

(2)

PLAN PLAN

 Introduction à la modélisation selon UMLIntroduction à la modélisation selon UML

– historique, intérêts de la modélisationhistorique, intérêts de la modélisation – cycles de viecycles de vie

 Les 9 vues d’un modèle UMLLes 9 vues d’un modèle UML

– Use CasesUse Cases, diagrammes de classes, modèles dynamiques, , diagrammes de classes, modèles dynamiques, packages...

packages...

 Processus de développement avec UMLProcessus de développement avec UML

– Expression des besoins Expression des besoins (étude de cas télécom : serveur SMDS(étude de cas télécom : serveur SMDS))

– Analyse (Technique de découverte des classes...)Analyse (Technique de découverte des classes...) – Conception (Systémique, notion de Conception (Systémique, notion de Design Patterns)Design Patterns) – Réalisation et ValidationRéalisation et Validation

(3)

Généalogie de

Généalogie de UML UML

OOA

(P. Coad) OMT

(J. Rumbaugh et al.)

Data-Flow SADT/SA-SD

(De Marco)

OOA - OODLE (Schlaer & Mellor)

Diagrammes Etat-Transition

(HAREL)

FUSION

(HP-Labs)

(Rumbaugh, Booch, Jacobson)UML

Use-Case (I.Jacobson)

Entite-Relation Merise

(Chen)

OOA-OOD

(G.Booch)

CLASSE- RELATION (P. Desfray)

CRC

(R. Wirf-Brooks) JSD

(M. Jackson)

(4)

De OMT à UML De OMT à UML

 1990 : Object-oriented Modeling Technique 1990 : Object-oriented Modeling Technique ⁽⁽Rumbaugh et al., G.E.)Rumbaugh et al., G.E.)

– Succès de la méthode du aux qualités de la notation :Succès de la méthode du aux qualités de la notation : – Concise, assez précise, simple à utiliser et à outillerConcise, assez précise, simple à utiliser et à outiller – Rien de fondamentalement nouveauRien de fondamentalement nouveau

» Inspirée “ entité-relation ” pour la modélisation des objetsInspirée “ entité-relation ” pour la modélisation des objets

» Notation de Harel pour la dynamique des objetsNotation de Harel pour la dynamique des objets

» De Marco/Yourdon flots de données & transformationsDe Marco/Yourdon flots de données & transformations

 1995 : Version préliminaire de UML1995 : Version préliminaire de UML

– extensions et améliorations, publications extensions et améliorations, publications JOOPJOOP, ..., ...

– inspirées par les auteurs eux-mêmes et par Boochinspirées par les auteurs eux-mêmes et par Booch

 1997 : UML version 1.01997 : UML version 1.0

– Intégration de la méthode OOSE de Jacobson (Intégration de la méthode OOSE de Jacobson (use-cases), et des use-cases), et des

(5)

La consécration des méthodes La consécration des méthodes

fondées sur la modélisation fondées sur la modélisation



L’approche par modélisation facilite L’approche par modélisation facilite

– Communication (et sa précision)Communication (et sa précision)

» avec donneur d’ordreavec donneur d’ordre

» entre différentes phases de développement et de maintenanceentre différentes phases de développement et de maintenance

– Capacité de vérificationCapacité de vérification

» CohérenceCohérence

» ComplétudeComplétude

– Continuité entre les différentes phases du cycle de vieContinuité entre les différentes phases du cycle de vie

» cf. Jackson et JSDcf. Jackson et JSD

» N.B.: continuité <> isomorphique ou plongement/projectionN.B.: continuité <> isomorphique ou plongement/projection

(6)

Un peu de Méthodologie...



Une méthode de développement de logiciels, c’est : Une méthode de développement de logiciels, c’est :

– Une notationUne notation

» La syntaxe --- graphique dans le cas de UMLLa syntaxe --- graphique dans le cas de UML

– Un méta-modèleUn méta-modèle

» La sémantique --- paramétrable dans UML La sémantique --- paramétrable dans UML (stéréotypes(stéréotypes))

– Un processusUn processus

» Détails dépendants du domaine d’activité :Détails dépendants du domaine d’activité :

 Informatique de gestionInformatique de gestion

 Systèmes réactifs temps-réelsSystèmes réactifs temps-réels

 Shrink-wrapShrink-wrap software (PC) software (PC)

(7)

Activités du développement de logiciels Activités du développement de logiciels

Définir ce qui sera développé

Définir comment il sera développé

Développer un des composants

Assembler les composants

Valider le logiciel



L’organisation de ces activités et leur L’organisation de ces activités et leur enchaînement définit le

enchaînement définit le cycle de développement cycle de développement du logiciel

du logiciel

(8)

Processus «classique»

• Expression du besoin

Analyse

• Analyse détaillée

• Codage

Réalisation

• Validation

Validation

• Mise en œuvre

• Etude technique préalable

• Conception préliminaire

Conception

• Conception détaillée

• Intégration

Intégration

• Tests d'Intégration



Cycle de vie normalisé AFNOR Cycle de vie normalisé AFNOR

(9)

Problèmes avec le processus classique...

Ce que l’analyste a spécifié

Ce que demande l’utilisateur

Ce que prévoit le concepteur

(10)

Problèmes du processus classique Problèmes du processus classique



Organisation « industrielle » héritée du XIX Organisation « industrielle » héritée du XIX

^ème^ème

siècle siècle

– rassurant pour les managersrassurant pour les managers

– hiérarchie malsaine dans les rôleshiérarchie malsaine dans les rôles

– antinomie : Coplien ’s organizational pattern antinomie : Coplien ’s organizational pattern

» Architects Also Implement Architects Also Implement



cycle management <> cycle développement cycle management <> cycle développement



linéarité implicite linéarité implicite

– temps d ’approbation des documents => effet tampontemps d ’approbation des documents => effet tampon – coût de la (non-) modification d ’un document « final »coût de la (non-) modification d ’un document « final » – irréaliste pour un projet innovant, donc à risquesirréaliste pour un projet innovant, donc à risques

(11)

Cycle de vie en « spirale » Cycle de vie en « spirale »

Intégration Réalisation

Conception

Analyse détaillée

Analyse

préliminaire « (de risque) »

V1 V2

Validation

Synergie avec approche par objets

(12)

Cycle de vie en « spirale » Cycle de vie en « spirale »



Bien adapté au développements innovants Bien adapté au développements innovants

– les progrès sont tangibles : c ’est du logiciel qui « tourne » les progrès sont tangibles : c ’est du logiciel qui « tourne » et pas seulement des kilos de documents

et pas seulement des kilos de documents

– possibilité de s ’arrêter « à temps », i.e. avant que possibilité de s ’arrêter « à temps », i.e. avant que l ’irréalisabilité du projet ait crée un gouffre financier l ’irréalisabilité du projet ait crée un gouffre financier



Moins simple à manager Moins simple à manager

– difficile à gérer en situation contractuelledifficile à gérer en situation contractuelle

– mal contrôlé => on retombe dans le mal contrôlé => on retombe dans le hackinghacking



Production des incréments asservie sur 2 parmi 3 : Production des incréments asservie sur 2 parmi 3 :

– période (e.g. release toutes les 2 semaines)période (e.g. release toutes les 2 semaines)

(13)

Vision «générique» d’un cycle UML Vision «générique» d’un cycle UML

INCEPTION

• Cas d'utilisation

• Modèle des objets du domaine

• Interfaces

• Maquettes

VALIDATION

• Validation technique

• Validation par les utilisateurs

ELABORATION

• Architecture

• Modèles des objets et scénarios

• Règles de transformation (Design patterns)

CONSTRUCTION

• Modèle détaillé des objets

• Scénarios détaillés

• Algorithmes

• Codage - Mise au point

• Intégration

UML

Modèle utilisateur Modèle statique Modèle dynamique Modèle d’implantation

(14)

Modélisation UML Modélisation UML



Modélisation selon 4 points de vue principaux : Modélisation selon 4 points de vue principaux :

– Vision utilisateur du systèmeVision utilisateur du système

» Cas d’utilisationCas d’utilisation

– Aspects statiques du systèmeAspects statiques du système

» Description des données et de leurs relationsDescription des données et de leurs relations

» Structuration en paquetagesStructuration en paquetages

– Aspects dynamiques du système (comportemental)Aspects dynamiques du système (comportemental)

» Diagramme de séquences (scénarios)Diagramme de séquences (scénarios)

» Diagramme de collaborations (entre objets)Diagramme de collaborations (entre objets)

» Diagramme d’états-transitions (Harel)Diagramme d’états-transitions (Harel)

» Diagramme d’activitésDiagramme d’activités

(15)

Température des diagrammes UML Température des diagrammes UML

Besoins Conception V & V Analyse Réalisation



Diagramme de cas d’utilisations Diagramme de cas d’utilisations



Diagramme de classes Diagramme de classes



Diagramme de paquetages Diagramme de paquetages



Diagramme de séquences Diagramme de séquences



Diagramme de collaborations Diagramme de collaborations



Diagramme d’états-transitions Diagramme d’états-transitions



Diagramme d’activités Diagramme d’activités



Diagramme d’implantation Diagramme d’implantation

«Température»

(16)

Modélisation UML Modélisation UML



Modélisation selon 4 points de vue principaux : Modélisation selon 4 points de vue principaux :

» Cas d’utilisationCas d’utilisation

(17)



Sujet longtemps négligé (e.g. OMT) Sujet longtemps négligé (e.g. OMT)



Question de l'expression des besoins pourtant Question de l'expression des besoins pourtant fondamentale

fondamentale

– Et souvent pas si facile Et souvent pas si facile (cible mouvante)(cible mouvante)

» cf. syndrome de la balançoirecf. syndrome de la balançoire



Object-Oriented Software Engineering (Ivar Object-Oriented Software Engineering (Ivar Jacobson et al.)

Jacobson et al.)

– Principal apport : la technique des acteurs et des cas Principal apport : la technique des acteurs et des cas d'utilisation

d'utilisation

– Cette technique est intégrée a UMLCette technique est intégrée a UML

Expression des besoins et OOAD

(18)



Se comprendre Se comprendre



Représenter le système Représenter le système



Exprimer le service rendu Exprimer le service rendu



Décrire la manière dont le système est perçu Décrire la manière dont le système est perçu

Quatre objectifs

(19)

Les moyens Les moyens

 Les acteurs UML Les acteurs UML

 Les Les use-cases use-cases UML UML

 Utilisation d’un dictionnaire du domaine Utilisation d’un dictionnaire du domaine

(20)



Outil de dialogue Outil de dialogue



Informel, évolutif, simple a réaliser Informel, évolutif, simple a réaliser



Etablir et figer la terminologie Etablir et figer la terminologie

– Permet de figer la terminologie du domaine d'application.Permet de figer la terminologie du domaine d'application.

– Constitue le point d'entrée et le référentiel initial de Constitue le point d'entrée et le référentiel initial de l'application ou du système.

l'application ou du système.

Intérêt du dictionnaire

(21)

Exemple de dictionnaire Exemple de dictionnaire

– Dictionnaire d'un simulateur de volDictionnaire d'un simulateur de vol

Notion Définition Traduit en ... Nom informatique

Pilotage Action de piloter un avion en enchaînant des manoeuvres élémentaires

Pilotage Package

Manette

des gaz Instrument qui permet d'agir sur la quantité de carburant injectée dans le moteur

Classe abstraite

Manette_gaz Classe

Instrument Instrument Organe d'interaction entre le

pilote et l'avion ou entre l'avion et le pilote

Mettre_a_fond Opération

Mettre les gaz à fond

Action qui permet d’injecter le maximum de carburant pour atteindre la vitesse maximale

Action Définition Traduit en ... Nom informatique

(22)

Acteurs Acteurs



Entité externe au système et amenée à interagir Entité externe au système et amenée à interagir avec lui. Un acteur «joue un rôle» vis-a-vis du avec lui. Un acteur «joue un rôle» vis-a-vis du

système système



Un acteur est une classe Un acteur est une classe



Un acteur peut représenter un être humain, un Un acteur peut représenter un être humain, un autre système, ...

autre système, ...



L'identification des acteurs permet de délimiter le L'identification des acteurs permet de délimiter le système

système

(23)

Acteurs : notations Acteurs : notations

«Actor»

SUPERVISEUR CLIENT

«Actor»

EXPEDITEUR

Système de vente par correspondance (VPC)

(24)

Les cas d'utilisation (use-cases) Les cas d'utilisation (use-cases)



Un cas d'utilisation est une manière particulière Un cas d'utilisation est une manière particulière d'utiliser le système

d'utiliser le système

– séquence d'interactions entre le système et un ou séquence d'interactions entre le système et un ou plusieurs acteurs

plusieurs acteurs

– Ils s’expriment par des diagrammes de séquences Ils s’expriment par des diagrammes de séquences



La compilation des cas d'utilisation décrit de La compilation des cas d'utilisation décrit de

manière informelle le service rendu par le système manière informelle le service rendu par le système

– fournissent une expression "fonctionnelle" du besoinfournissent une expression "fonctionnelle" du besoin – peuvent piloter la progression d ’un cycle en spiralepeuvent piloter la progression d ’un cycle en spirale



Les cas d'utilisation sont nommes en utilisant la Les cas d'utilisation sont nommes en utilisant la

(25)

Cas d'utilisation : exemple et notation Cas d'utilisation : exemple et notation

CLIENT

EXPEDITEUR

Traiter commande

MAJ catalogue

Etablir crédit

SUPERVISEUR Commander

Consulter

VPC

(26)

Relations sur les

Relations sur les use-cases use-cases



Communication Communication

– Lien entre le use case et l’acteur. Lien entre le use case et l’acteur.

– De type « association »De type « association »



Utilisation Utilisation («uses») («uses»)

– Utilisation d’autres use-cases pour en préciser la Utilisation d’autres use-cases pour en préciser la définition

définition Extension

Extension («extends») : utilisation « optionnelle » (attention («extends») : utilisation « optionnelle » (attention au sens des flèches.

au sens des flèches.

Inclusion (« includes ») : utilisation systématique Inclusion (« includes ») : utilisation systématique

(27)

Relations sur les

Relations sur les use-cases use-cases : notation : notation

Commander Commander échantillon

«extends»

Organiser paiement Lire données client

Sélectionner produit

«includes»

Consulter Catalogue

(28)

Exprimer le service rendu Exprimer le service rendu

 Besoins fondamentaux : manières d'utiliser le systèmeBesoins fondamentaux : manières d'utiliser le système

– Représentation globale par cas d'utilisationReprésentation globale par cas d'utilisation

   taille du système, seulement de 3 à 10 Use Casestaille du système, seulement de 3 à 10 Use Cases

 Besoins opérationnels : interactions avec le systèmeBesoins opérationnels : interactions avec le système

– Représentation détaillée par raffinement des cas d'utilisationReprésentation détaillée par raffinement des cas d'utilisation – Début de décomposition fonctionnelle : ne pas aller trop loinDébut de décomposition fonctionnelle : ne pas aller trop loin

(29)

Besoins fondamentaux et opérationnels Besoins fondamentaux et opérationnels



Besoin fondamental : Besoin fondamental :

– Conduire une voitureConduire une voiture



Besoins opérationnels Besoins opérationnels

– Ouvrir la porteOuvrir la porte – Mettre le contactMettre le contact – AccélérerAccélérer

– Tourner le volantTourner le volant – ...

conduire une voiture

{fondamental}

conduire une voiture

{fondamental}

ouvrir la porte

{opérationnel}

mettre le contact

{opérationnel}

accélérer

{opérationnel}

tourner le volant

{opérationnel}

«includes»

(30)

Utiles pour l’établissement de scénarios Utiles pour l’établissement de scénarios



Modélisation d’exemples issus des use-cases Modélisation d’exemples issus des use-cases

Domaine de l’application

Utilisateur 1

Utilisateur 2

besoin1

besoin2

besoin3

besoin4

service1() service3() service1() service2() service3()

service5() service6() service1() service6()

Objet1 Objet2 Objet3

service1

service2 service3

service4

service5

service3 scénario du use case

«besoin 2»

service4() service5()

(31)

Modélisation UML Modélisation UML



Modélisation selon 4 points de vue principaux : Modélisation selon 4 points de vue principaux :

» Description des données et de leurs relationsDescription des données et de leurs relations

– Vision implantation Vision implantation

» Diagramme de composants et de déploiementDiagramme de composants et de déploiement

(32)

Notations UML pour classes et objets Notations UML pour classes et objets



Représentation d’une classe Représentation d’une classe

CL805699 : Compte

Représentation simplifiée

Nom de la classe

Compartiment des Attributs Compartiment des Opérations

Compte

solde: Somme plancher: Somme créditer (Somme) débiter (Somme)

Représentation des objets

Nom de l’objet

(33)

Constituants d’une classe Constituants d’une classe



Concept représenté (nom) Concept représenté (nom)



Classes héritées (concepts précisés) Classes héritées (concepts précisés)



Relations avec autres classes Relations avec autres classes



Attributs (classe, nom, visibilité) Attributs (classe, nom, visibilité)



Opérations (paramètres) Opérations (paramètres)



Contraintes, invariants Contraintes, invariants



Généricité (classes paramétrées) Généricité (classes paramétrées)



Stéréotypes Stéréotypes

(34)

Représentation des attributs Représentation des attributs



Caractérisation des attributs Caractérisation des attributs

Nom de l'attribut

Type de l'attribut ATTRIBUTS

Compte

(35)

Attributs dérivés Attributs dérivés



Attributs dont la valeur peut être déduite d ’autres Attributs dont la valeur peut être déduite d ’autres éléments du modèle

éléments du modèle

– e.g. e.g. âgeâge si l ’on connaît la date de naissance si l ’on connaît la date de naissance – notation : /agenotation : /age



En termes d ’analyse, indique seulement une En termes d ’analyse, indique seulement une contrainte

contrainte entre valeurs et non une indication de entre valeurs et non une indication de

ce qui doit être calculé et ce qui doit être mémorisé

(36)

Représentation des opérations Représentation des opérations



Vues graphiques Vues graphiques

Nom de l’opération

Nom de paramètre

Classe du paramètre

Compte

solde: Somme plancher: Somme

créditer (montant: Somme) débiter (montant: Somme)

(37)

Représentation des invariants Représentation des invariants



Des contraintes peuvent être ajoutées aux éléments Des contraintes peuvent être ajoutées aux éléments du modèle UML

du modèle UML

– notation entre notation entre { }{ }



Invariants = Propriétés vraies pour l'ensemble des Invariants = Propriétés vraies pour l'ensemble des instances de la classe

instances de la classe

– dans un état stable, chaque instance doit vérifier les dans un état stable, chaque instance doit vérifier les invariants de sa classe

invariants de sa classe – exprimés à l ’aide d ’OCL exprimés à l ’aide d ’OCL

» Object Constraint LanguageObject Constraint Language

– e.g. {solde >= plancher} e.g. {solde >= plancher}

Compte

{solde>=plancher}

(38)

Représentation des pré/post conditions Représentation des pré/post conditions



Préconditions Préconditions

– {«precondition» expression booléenne{«precondition» expression booléenne OCL} OCL}

– Abrégé en: {pre: Abrégé en: {pre: expression booléenneexpression booléenne OCL} OCL}



Postconditions Postconditions

– {«postcondition» expression booléenne{«postcondition» expression booléenne OCL} OCL}

– Abrégé en: {post: Abrégé en: {post: expression booléenneexpression booléenne OCL} OCL}

– Operateur « valeur précédente » (idem Operateur « valeur précédente » (idem oldold Eiffel): Eiffel):

» expression OCL expression OCL @pre @pre

(39)

Etre abstrait

Etre abstrait et et précis avec UML précis avec UML

Compte

{solde>=plancher}

solde: Somme plancher: Somme

créditer (montant : Somme)

{pre: montant > 0}

{post: solde = solde @pre + montant}

débiter (s: Somme)

{pre: montant > 0 and montant<=solde-plancher}

{post: solde = solde @pre - montant}

Analyse précise ou “analyse par contrat”

(40)

Relation entre classes Relation entre classes



Deux points de vue : Deux points de vue :

– Une relation met en correspondance des éléments Une relation met en correspondance des éléments d’ensembles

d’ensembles

– Une relation permet la description d'un concept à l’aide Une relation permet la description d'un concept à l’aide d’autres concepts

d’autres concepts



Une contrainte : Une contrainte :

– Une relation est un lien stable entre deux objetsUne relation est un lien stable entre deux objets

(41)

Relation entre classes Relation entre classes

Personne Voiture

Possession

Personne propriétaire ^possession propriété Voiture



Notation Notation



Vue ensembliste = Graphe de la relation Vue ensembliste = Graphe de la relation

Une association met en correspondance des éléments d’ensembles

1 *

(42)

Représentation des relations Représentation des relations

Nom de relation Rôle

Cardinalité précisée



Relation, direction, rôle, cardinalité Relation, direction, rôle, cardinalité

Voiture Personne

* passager moyen_de_transport

transporte

direction de relation

Rôle

(43)

**

Cardinalité d'une relation Cardinalité d'une relation

Classe Exactement une

Classe Plusieurs (0 à n)

Classe Optionnelle (0 ou 1)

Classe 1,2,4

Classe 1-10

0,1 1

Cardinalité spécifiée Intervalle

(44)

Cas particuliers de relations Cas particuliers de relations

Une relation réflexive lie des objets de même classe

encadre

sous-fifre chef1



Relations réflexives Relations réflexives

Personne

1..*

(45)



Cas particuliers de relations : Cas particuliers de relations :

– Notion de Notion de touttout et et partiesparties

Composition et Agrégation Composition et Agrégation

1

4,6 Roue

Voiture Personne

* passager moyen_de_transport

transporte

Chassis

1

Composition

Agrégation

1 1

roulement >

structure >

(46)



Différentes formes suggérant Différentes formes suggérant l’inclusion l’inclusion

Autre vues de la Autre vues de la

composition/agrégation composition/agrégation

Voiture

roulement[4-6]: Roue structure: Chassis

Voiture

Roue Chassis roulement 4-6

structure 1

(47)

Relations n-aires Relations n-aires



Relations entre plus de 2 classes Relations entre plus de 2 classes

(à éviter si possible)(à éviter si possible)

MATIERE

CLASSE

Enseignement

1..*

Enseignant Enseignée

Destinataire PROFESSEUR ^*

1..*

Enseignant Enseignée

1..*

Destinataire

1

PROFESSEUR Enseignement ^1..* MATIERE

1..*

0..*

(48)



L'attribut porte sur le lien L'attribut porte sur le lien

Relations attribuées Relations attribuées

Etudiant candidat Matière

objet_épreuve n..k

Note épreuve

(49)

Qualifieurs de relations Qualifieurs de relations



Un qualifieur est un attribut spécial qui permet, Un qualifieur est un attribut spécial qui permet, dans le cas d'une relation 1-vers-plusieurs ou dans le cas d'une relation 1-vers-plusieurs ou

plusieurs-vers-plusieurs, de réduire la cardinalité.

Il peut être vu comme une clé qui permet de Il peut être vu comme une clé qui permet de

distinguer de façon unique un objet parmi distinguer de façon unique un objet parmi

plusieurs.

Fichier

Répertoire Répertoire Nom du fichier Fichier

Relation non qualifiée

Nom du fichier

Relation qualifiée

Un répertoire + un nom de fichier identifient de façon unique un fichier

0..* 0..*

(50)

Représentation de la généralisation Représentation de la généralisation

(héritage) (héritage)

AVION

Héritage simple Héritage multiple

AEROPLANE _AEROPLANE VEHICULE_DE_TRANSPORT

AVION



Héritage simple et multiple Héritage simple et multiple

(51)

Interfaces et « lollipop » Interfaces et « lollipop »

AVION MOBILE

Raffinement _AVION

MOBILE

« interface »

(52)

Héritage des relations Héritage des relations

REPERTOIRE

1..*lien logique FICHIER



Les relations sont héritées par les sous classes : Les relations sont héritées par les sous classes :

VEHICULE MOTEUR

1..2

VOITURE CAMION

motorisation

*

(53)

Représentation de classes abstraites Représentation de classes abstraites



Classes sans instances immédiates Classes sans instances immédiates

Une instance de «Forme» est obligatoirement une instance de la classe Carre ou de la classe Cercle

Cercle Carre

Forme {abstract}

(54)

Représentation des opérations Représentation des opérations

abstraites abstraites



Opération sans corps d’une classe abstraite Opération sans corps d’une classe abstraite

calculer_surface () {abstract}

Forme {abstract}

calculer_surface()

Carre Cercle

calculer_surface()

(55)

Visibilité Visibilité



Différentes visibilités des membres d'une classe Différentes visibilités des membres d'une classe

Interface

corps

implémenteur

usager

héritier

privé = - protégé = #

public = +

(56)

Visibilité Visibilité

#m1 (p1,P2,p3) +a1 : T1

-a2 : T2

+m2 (p1,P2,p3)

Classe



Représentation Représentation

(57)

Classes paramétrées (Généricité) Classes paramétrées (Généricité)

Tableau element : T taille : Entier

T , Entier : Integer

Tableau

<<bind>> <Point, 3>

Classe générique

Classe effective

paramètres génériques

paramètres effectifs

(58)

Les relations en tant que classes Les relations en tant que classes



Pratique dans certains cas Pratique dans certains cas

– Relations ternaires.Relations ternaires.

– La relation a des opérations appelées : La relation a des opérations appelées : classe de liaisonclasse de liaison

utilisateur station de

travail autorisation

priorité privilèges session de démarrage

home directory autorisation sur

* *

*

(59)

Les stéréotypes Les stéréotypes



Nouveaux éléments de modélisation instanciant Nouveaux éléments de modélisation instanciant

– Des classes du méta modèle UML (pour les stéréotypes Des classes du méta modèle UML (pour les stéréotypes de base UML)

de base UML)

– Des extensions de classes du méta modèle UML (pour Des extensions de classes du méta modèle UML (pour les stéréotypes définis par l’utilisateur)

les stéréotypes définis par l’utilisateur)



Peuvent être attachés aux éléments de Peuvent être attachés aux éléments de modélisations et aux diagrammes :

modélisations et aux diagrammes :

– Classes, objets, opérations, attributs, généralisations, Classes, objets, opérations, attributs, généralisations,

relations, acteurs, uses-cases, événements, diagrammes relations, acteurs, uses-cases, événements, diagrammes de collaboration ...

de collaboration ...

(60)

Notations pour les stéréotypes Notations pour les stéréotypes

«persistent»

CLIENT nom : string adresse : string

«persistent»

CLIENT nom : string adresse : string

CLIENT CLIENT

nom : string adresse : string

stéréotype

(61)

Les notes Les notes



Compléments de modélisation Compléments de modélisation

– Attachés à un élément du modèle ou libre dans un Attachés à un élément du modèle ou libre dans un diagramme

diagramme

– Exprimés sous forme textuelleExprimés sous forme textuelle

– Elles peuvent être typées par des stéréotypesElles peuvent être typées par des stéréotypes

modèle réalisé par John Doe

PERSONNE * 0..1 ENTREPRISE

employé employeur

0..1 chef

{PERSONNE.employeur = PERSONNE.chef.employeur}

(62)

Conseils pratiques Conseils pratiques



Réfléchir au problème avant de commencer Réfléchir au problème avant de commencer

– Soigner le nommage, insister sur le nommage des Soigner le nommage, insister sur le nommage des relations et des rôles

relations et des rôles



Faire simple! Faire simple!

– ««Things must be as simple as possible, but no simplerThings must be as simple as possible, but no simpler». ».

A. Einstein A. Einstein

– éviter toute complication nuisibleéviter toute complication nuisible

» utiliser les qualifieurs utiliser les qualifieurs

» éviter les relations ternaires, quaternaires (trop complexe)éviter les relations ternaires, quaternaires (trop complexe)

» se dégager de l’implémentation : raisonner objets, classes, se dégager de l’implémentation : raisonner objets, classes, messages, relations, attributs, opérations

messages, relations, attributs, opérations

(63)

Conseils pratiques (suite) Conseils pratiques (suite)



Approche incrémentale Approche incrémentale

– ItérerItérer

– Confronter ses modèles aux autresConfronter ses modèles aux autres

– Savoir s'arrêter avant d’atteindre la perfection...Savoir s'arrêter avant d’atteindre la perfection...

» prise en compte qualité (niveau de précision), coûts, délais...prise en compte qualité (niveau de précision), coûts, délais...

» asservissement au processus de développementasservissement au processus de développement



Faire simple (encore) Faire simple (encore)

– Un bon modèle n’est pas un modèle où l’on ne peut plus Un bon modèle n’est pas un modèle où l’on ne peut plus rien ajouter, mais un modèle où on ne peut plus rien

rien ajouter, mais un modèle où on ne peut plus rien enlever

enlever. . (d’après A. de St-Exupéry)(d’après A. de St-Exupéry)

(64)

Modélisation UML Modélisation UML



Modélisation selon 4 points de vue principaux : Modélisation selon 4 points de vue principaux :

» Structuration en paquetagesStructuration en paquetages

(65)

Notion de package Notion de package



Élément structurant les classes Élément structurant les classes

– Modularisation à l'échelle supérieureModularisation à l'échelle supérieure – Un package partitionne l'application :Un package partitionne l'application :

» Il référence ou se compose des classes de l’applicationIl référence ou se compose des classes de l’application

» Il référence ou se compose d’autres packagesIl référence ou se compose d’autres packages

– Un package réglemente la visibilité des classes et des Un package réglemente la visibilité des classes et des packages qu’il référence ou le compose

packages qu’il référence ou le compose

– Les packages sont liés entre eux par des liens d'utilisation, Les packages sont liés entre eux par des liens d'utilisation, de composition et de généralisation

de composition et de généralisation

– Un package est la représentation informatique du contexte Un package est la représentation informatique du contexte de définition d’une classe

de définition d’une classe

(66)

Représentation d’un package Représentation d’un package



Vue graphique externe Vue graphique externe



Vue graphique externe et interne Vue graphique externe et interne

P1

P2

P3

C1 C2

P1

(67)



Définition de vues partielles d'une application Définition de vues partielles d'une application

Partitionnement d’une application Partitionnement d’une application

ENSEMBLE DES CLASSES DE L'APPLICATION

SYNTHÈSE EN PACKAGES

N.B.: une classe appartient à un et un seul package

(68)



Réglementation de la visibilité des classes Réglementation de la visibilité des classes

– Classes de visibilité publiqueClasses de visibilité publique : :

» classes utilisables par des classes d’autres packagesclasses utilisables par des classes d’autres packages

– Classes de visibilité privéeClasses de visibilité privée : :

» classes utilisables seulement au sein d’un packageclasses utilisables seulement au sein d’un package



Représentation graphique Représentation graphique

Visibilité dans un package Visibilité dans un package

{public } {private }^Classe Package::Classe

(69)

Utilisation entre packages Utilisation entre packages



Définition Définition

– Il y a utilisation entre packages si des classes du package Il y a utilisation entre packages si des classes du package utilisateur accèdent à des classes du package utilisé

utilisateur accèdent à des classes du package utilisé

– Pour qu’une classe d’un package p1 puisse utiliser une Pour qu’une classe d’un package p1 puisse utiliser une classe d’un package p2, il doit y avoir au préalable une classe d’un package p2, il doit y avoir au préalable une déclaration

déclaration expliciteexplicite de l’utilisation du package p2 par le de l’utilisation du package p2 par le package p1

package p1



Représentation graphique Représentation graphique

P2 P1

Vue externe du package P1

(70)

Utilisation entre packages Utilisation entre packages



Exemple (vue externe du package livraisons) Exemple (vue externe du package livraisons)

LIVRAISONS

VEHICULES COLIS

LIVREURS

(71)

Héritage entre packages Héritage entre packages



Exemples Exemples

JeuPlateau

JeuDame

JeuEchec

Windowing System

Motif MicrosoftWindows

(72)

Utilité des packages Utilité des packages



Réponses au besoin Réponses au besoin

– Contexte de définition d'une classeContexte de définition d'une classe – Unité de structurationUnité de structuration

– Unité d'encapsulationUnité d'encapsulation – Unité d'intégrationUnité d'intégration

– Unité de réutilisationUnité de réutilisation – Unité de configurationUnité de configuration – Unité de productionUnité de production

(73)

Structuration par packages Structuration par packages

(vs) (vs)

décomposition hiérarchique décomposition hiérarchique

 Pour les grands systèmes, il est nécessaire de disposer d’une unité de structuration :

 À un niveau supérieur,

 Plus souple que :

La composition de classe

Le référençage de packages

=> domaines de structuration :

Packages décomposables en packages

(74)

Exemple : Package entreprise Exemple : Package entreprise



Exemple de composition Exemple de composition

ENTREPRISE

COMPTABILITÉ COMMERCIAL

LIVRAISON

(75)

Exemple : Package entreprise Exemple : Package entreprise



Ensemble des packages terminaux de l’application Ensemble des packages terminaux de l’application

Véhicules

Personnel Colis

Clientèles

Livraisons Facturation

Bilan

Livreurs

Commerciaux Tenue

Comptes

(76)

Exemple : Package entreprise Exemple : Package entreprise



Composition des packages en sous-packages Composition des packages en sous-packages

COMMERCIAL

ENTREPRISE

COMPTABILITÉ

Facturation

Tenue

Comptes Personnel

Bilan

LIVRAISONS

Véhicules

Livreurs Livraisons

Colis

(77)

Modélisation UML Modélisation UML



Modélisation selon 4 points de vue principaux : Modélisation selon 4 points de vue principaux :

– Aspects dynamiques du système (comportemental)Aspects dynamiques du système (comportemental)

(78)

Aspects dynamiques du système Aspects dynamiques du système



Jusqu’ici, système décrit Jusqu’ici, système décrit statiquement statiquement : :

– Décrivent les messages (méthodes ou opérations) que Décrivent les messages (méthodes ou opérations) que les instances des classes peuvent recevoir mais ne

les instances des classes peuvent recevoir mais ne décrivent pas l’émission de ces messages

décrivent pas l’émission de ces messages

– Ne montrent pas le lien entre ces échanges de messages Ne montrent pas le lien entre ces échanges de messages et les processus généraux que l’application doit réaliser et les processus généraux que l’application doit réaliser



Il faut maintenant décrire comment le système Il faut maintenant décrire comment le système évolue dans le temps

évolue dans le temps

(79)

Modélisation UML Modélisation UML



Modélisation selon 4 points de vue principaux : Modélisation selon 4 points de vue principaux :

» Diagramme de séquences (scénarios)Diagramme de séquences (scénarios)

(80)

Diagrammes de séquences (scénarios) Diagrammes de séquences (scénarios)



Dérivés des scénarios de OMT : Dérivés des scénarios de OMT :

– Montrent des exemples de coopération entre objets dans Montrent des exemples de coopération entre objets dans la réalisation de processus de l’application

la réalisation de processus de l’application

– Illustrent la dynamique d’enchaînement des traitements à Illustrent la dynamique d’enchaînement des traitements à travers les messages échangés entre objets

travers les messages échangés entre objets

– le temps est représenté comme une dimension explicitele temps est représenté comme une dimension explicite

» en général de haut en basen général de haut en bas



Les éléments constitutifs d’un scénario sont : Les éléments constitutifs d’un scénario sont :

– Un ensemble d’objets (et/ou d’acteurs)Un ensemble d’objets (et/ou d’acteurs) – Un message initiateur du scénario Un message initiateur du scénario

– La chronologie des messages échangés La chronologie des messages échangés subséquemment

subséquemment

(81)

Syntaxe graphique Syntaxe graphique



Objets et messages Objets et messages

Nom Objet1:NomClasse1 Nom Objet:NomClasse

Objets = Instances de classes

nom message (paramètres)

Message nom message émis par Nom Objet

vers Nom Objet1

Temps

(82)

Ligne de vie et activation Ligne de vie et activation



La «ligne de vie» représente l’existence de l’objet à La «ligne de vie» représente l’existence de l’objet à un instant particulier

un instant particulier

– Commence avec la création de l’objetCommence avec la création de l’objet – Se termine avec la destruction de l’objetSe termine avec la destruction de l’objet



L’activation est la période durant laquelle l’objet L’activation est la période durant laquelle l’objet exécute une action lui-même ou via une autre exécute une action lui-même ou via une autre

procédure

(83)

Notation Notation

objet1:Classe1

objet2:Classe2

objet3:Classe3

Client

op ( )

m1 ( )

m2 ( )

m3 ( )

Objet créé dans le scénario

Activité de l’objet

Objet existant avant et après l’activation du scénario

Ligne de vie

(84)

Messages Messages



Communication entre objets Communication entre objets

– Des paramètresDes paramètres – Un retourUn retour



Cas particuliers Cas particuliers

– Les messages entraînant la construction d’un objetLes messages entraînant la construction d’un objet – La récursionLa récursion

– Les destructions d’objetsLes destructions d’objets