Cours Uml

UML Langage Unifié pour la Modélisation Objet M.TARIK BOUHASSE 1

Plan • Présentation d’UML • Modèle Fonctionnel (étude de cas) • Modèles Statiques (étude de cas) • Modèles Dynamiques (étude de cas) • UML et les méthodologies de développement logiciel • Conception centrée sur l ’architecture

2

Présentation d’UML • Références • Historique • Principes généraux • Axes de modélisation d ’un système • Listes des Diagrammes • Exemples : Quelques diagrammes • Vocabulaire • Paquetage • Dépendance entre paquetages • Stéréotypes :Mécanismes d ’extension • Le processus : Principes • Processus : rôle des cas d ’utilisation

3

Références Livres :

Références :

Grady Booch 1981, ADA, « Object Oriented Development » James Rumbaugh 1991, OMT, JOOP (Journal of OO programming) Ivar Jacobson, OOSE sept 97, UML 1.1. UML 2 par la Pratique (EYROLLS, Pascal Roques) http://www.omg.org http://uml.free.fr/ site en français

Outils : Rational ROSE, http://www.rational.com

4

Historique (1/2)

UML 2.0 UML 1.3

OMG Acceptance, Nov 1997

UML 1.1

Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 public feedback UML partners

UML 0.9

Web - June ´96 OOPSLA ´95

Unified Method 0.8

Booch method Other methods

UML 1.0

OMT OOSE 5

Historique (2/2) Harel

Meyer Before and after conditions

Statecharts

Gamma, et al Frameworks and patterns,

HP Fusion

Booch

Operation descriptions and message numbering

Booch method

Embley

Rumbaugh

Singleton classes and high-level view

OMT

Jacobson

Wirfs-Brock

OOSE

Responsibilities

Shlaer - Mellor Object lifecycles

Odell Classification 6

Principes généraux (1/4) 

L ’orientation Objet



Langage (Concepts, sémantique, méta-modèle, Notation)



Indépendante d ’un processus



Généricité de l ’approche





Indépendante d ’un langage de programmation



Indépendante d ’un type d ’architecture



Indépendante d ’une classe de système

Une capitalisation des bonnes pratiques de la C.O.O.

7

Principes généraux (2/4) 

Un langage de modélisation des systèmes 





systèmes logiciels (SI, télécomm..) ou autre

Objectifs du langage 

pour documenter les besoins, les architectures, la conception, le code...



pour visualiser



pour spécifier



pour construire

Un langage visuel 

Génération de 13 diagrammes

8

Principes généraux (3/4) 

Un langage unifiant les concepts et les notations du niveau métier et informatique  Objets de l’espace du problème et objets de l ’espace de la solution  La description d’un système organisé selon une architecture 3tiers :  les objets de l ’interface  Les objets du serveur d ’application  Les objets du serveurs de données



Utilisation des concepts objet mais pas seulement



Un noyau et des mécanismes d’extension

9

Principes généraux (4/4) 

Un système peut être modélisé selon différents points de vue 

Le point de vue des utilisateurs (spécification fonctionnelles)



Le point de vue de l ’analyste (structurel, logique)



Le point de vue constructeur (déploiement, matériel)



Avec les facteurs de qualité nécessaires pour chaque point de vue



Le résultat de la modélisation selon un certain point de vue est un ou plusieurs modèles



Un modèle est un ensemble de diagrammes



La définition des vues (Quelles vues ?) et des modèles (quels diagrammes ?) n’est pas figée

10

Axes de modélisation d ’un système Statique (ce que le système EST)

Dynamique



diagramme de classes



diagramme d’objets



diagramme de package



diagramme de composants



diagramme de déploiement

(comment le système EVOLUE) 

diagramme de séquence



diagramme de collaboration (d.Comm)



diagramme d’états-transitions



diagramme d’activités

Fonctionnel (ce que le système FAIT) 

diagramme de cas d’utilisation



diagramme de collaboration (d.Comm)

diagramme

d’activités 11

Liste des Diagrammes Diagrammes structurels ou diagrammes statiques (UML Structure) D. de classes (Class diagram) D. d’objets (Object diagram) D. de composants (Component diagram) D. de déploiement (Deployment diagram) D. de paquetages (Package diagram) D. de structures composites (Composite structure diagram)

Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) D.de cas d’utilisation (Use case diagram) D. d’activités (Activity diagram) D. d’états-transitions (State machine diagram) Diagrammes d’interaction (Interaction diagram) D. de séquence (Sequence diagram) D. de communication (Communication diagram) D. global d’interaction (Interaction overview diagram) D. de temps (Timing diagram)

12

Exemples : Quelques diagrammes Système

cas d'utilisation : acteur ( intéragissant avec le Système

Cas d’utilisation une fonctionnalité attendue du système par les différents acteurs.

message

message message

Diagramme de Classes objet 1

message

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

Diagramme de séquence objet 2

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

lien expri mant que "obj et 2 est composé de objet 3" objet 3

objet 4

A chaque cas d'utilisation, on peut associer un scénario, décrit par un diagramme 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 un ensemble de messages échangés entre les acteurs et le système, ordonnés chronologiquement. 13

Vocabulaire UML Constituants Constituants de base

Relations

Dépendances Associations Diagrammes Généralisation Structure Groupement D. Cas d ’utilisation Package Cas d ’utilisation D. de classe Classe Comportement. Modèle Sous-système D. d ’objet Classe Active Interface Interaction Framework D. de séquence Composant Machine d ’état D. de collaboration Collaboration D. d ’état/transition Noeud D. d ’activité D. de composant D. de déploiement Annotation note

14

Paquetage 

Définition  Groupement d ’éléments de modélisation.  Il correspond à un sous ensemble de modèle. Il contient selon le modèle, des classes, des objets, des composants



Exemple Client

passer

Commandes Client Commande Ligne de commande Article

Ligne de commande

Commande

Article

Commander 15

Dépendance entre paquetages 

Une association sémantique entre 2 (ou plus) éléments de modèle (classes, paquetages, etc....)



Cette dépendance indique une situation dans laquelle un changement sur l’élément cible peut exiger un changement sur l’élément source de la dépendance Statistiques ventes Catégorie article Chiffre d’affaire etc...

Commandes dépend de

Client Commande Ligne de commande Article

16

Stéréotypes : Mécanismes d ’extension 

Le stéréotype permet d’étendre l’ensemble de base des éléments de modélisation. Ceci facilite la documentation des particularités spécifiques à un projet ou un processus.



Plusieurs stéréotypes sont fournis par les AGL (Rational Rose par exemple), néanmoins l’utilisateur a la possibilité d ’en ajouter d ’autres spécifiques à ses besoins



Exemple : 3 stéréotypes prédéfinis pour l’analyse: interface, entité, contrôleur <<entité>> Commande

Commande « interface » Interface distributeur

Interface distributeur <<entité>> Superviseur

>

Superviseur

17

Le processus : Principes

Processus : ensemble d’étapes, destinées à livrer et dans les délais (et le budget) une application qui correspond aux besoins du client et des utilisateurs. Cas d’utilisation

Architecture « centré sur»

« piloté par » Langage « basé sur » UML

Itératif et Processus configurable « se déroule » incrémental

UML est un langage de modélisation (de notation) indépendant des processus.

Processus A

Processus B 18

Processus : rôle des cas d ’utilisation Modèle des cas d’utilisation spécialisé par Modèle d’Analyse

élaboré par Modèle de Conception

distribué par réalisé par Modèle de Déploiement Modèle d ’implantation

vérifié par Modèle de Test

19

Plan • Présentation d’UML • Modèle Fonctionnel • Modèles Statiques • Modèles Dynamiques • UML et les méthodologies de développement logiciel • Conception centrée sur l ’architecture

20

Modèle Fonctionnel • Les cas d’utilisations • Exemple d’Application • Le virage vers l’objet • En conclusion

21

Modèle Fonctionnel / Les cas d’utilisation • Définitions • Intérêt des cas d’utilisations • Diagramme de cas d’utilisation • Les acteurs • Détermination des cas d’utilisations • Relations entre cas d ’utilisations 22

Définitions 

Formalisés par Ivar Jacobson : Object-Oriented Software Engineering (Addison-Wesley, 1992)



Expression du comportement du système (actions et de réactions), selon le point de vue de l’utilisateur



Un cas d’utilisation est une manière spécifique d’utiliser un système.



C’est l’image d’une fonctionnalité du système, déclenchée en réponse à la stimulation d’un acteur externe

23

Intérêt des cas d’utilisation(1/2) 

Constituent un moyen pour déterminer les besoins d’un système



Utilisés par les utilisateurs finaux pour exprimer leur attentes et leur besoins



Permettent d’impliquer les utilisateurs dès les premiers stades du développement



Constituent une base pour les tests fonctionnels

24

Intérêt des cas d’utilisation (2/2) Utilisateur C

Ensemble des besoins

Utilisateur A

Utilisateur B

Les cas d’utilisation partitionnent l’ensemble des besoins d’un système

Cahier des charges

25

Diagramme de cas d’utilisation • Un 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

relation Acteur

Ceci est un acteur

Cas d ’utilisation

Ceci est une 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

26

Les acteurs(1/3) 

Un acteur est une personne ou un système qui interagit avec un système, en échangeant de l’information (en entrée et en sortie)



On trouve les acteurs en observant les utilisateurs directs du système, ceux qui sont responsable pour sa maintenance, ainsi que les autres systèmes qui interagissent avec le système 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 27

Les acteurs(2/3)



Un acteur Principal: celui pour qui le cas d’utilisation produit un résultat observable.



Un acteur Secondaire: celui qui peut juste consulter ou informer le système lors de l’exécution du cas d’utilisation

28

Les acteurs(3/3) Exemple Conçoit les schémas et nomenclatures

Développeur

Récupère les schémas

Gestion des schémas

Récupère les contraintes

Définit les contraintes mécaniques Gestion des contraintes

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

Gestion des jobs <>

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

Gestion des dossiers

29

Détermination des cas d’utilisations 

Quelles sont les tâches de l’acteur ?



Quelles informations l’acteur doit-il créer, sauvegarder, modifier, détruire ou simplement lire ?



L’acteur devra-t-il informer le système de changements externes ?



Le système devra-t-il informer l’acteur de conditions internes au système ?

30

Les relations dans un diagramme cas d’utilisation    

La relation de communication La relation de généralisation La relation d’inclusion La relation d’extension <>

Virement Client distant

Identification <<extend>>

montant > 500

Virement par Internet

Vérification solde compte 31 [PAM-00 p156]

La relation d’inclusion La relation d’inclusion a un caractère obligatoire, la source spécifiant à quel endroit le cas d’utilisation cible doit être inclus. <>

Virement Client distant

Identification <<extend>>

montant > 500

Virement par Internet

Vérification solde compte

32 [PAM-00 p156]

La relation d’extension Dans une relation d’extension entre cas d’utilisation, le cas d’utilisation source ajoute son comportement au cas d’utilisation destination (cible). L’extension peut être soumise à une condition. <>

Virement Client distant

Identification <<extend>>

montant > 500

Virement par Internet

Vérification solde compte

33 [PAM-00 p156]

Modèle Fonctionnel / Exemple d’Application

• Existant • Définition du problème • Phase d'Initialisation • Diagramme des Cas d’Utilisation

34

Existant • L ’exemple d ’application est intitulé « Cas Scolarité » • Les étudiants remplissent des imprimés et les envoient au service d'inscription. • Des employés saisissent les sélections des étudiants dans une base de données, et fournissent les emplois du temps pour les étudiants. • L'université décide d'utiliser un système d'inscription en temps réel. • Ce système doit être utilisé par : – Les professeurs pour leur indiquer les cours qu'ils doivent assurer, par les étudiants pour choisir leurs 35 cours

Définition du problème (1/2) • Au début de chaque semestre les étudiants doivent

obtenir un catalogue des cours proposés : contenu du cours, professeur, département, et pré-requis. • Le nouveau système doit permettre aux étudiants de sélectionner leurs cours pour le semestre. • En plus, chaque étudiant doit indiquer un choix alternatif pour chaque cours choisi, au cas où ce cours serait supprimé. • Aucun cours ne doit avoir plus de vingt étudiants. Un cours auquel moins de dix étudiants sont inscrit doit être supprimé.

36

Définition du problème (2/2) • Une fois que le processus d'inscription par l'étudiant est terminé, le système fournit les droits d'inscription à percevoir pour le semestre. • Les professeurs doivent pouvoir renseigner le système sur les cours qu'ils assurent. Ils doivent aussi savoir quels étudiants se sont enregistrés à leurs cours. • Lors de chaque début de semestre, il est défini une période de temps où les étudiants peuvent modifier leurs choix. • Les étudiants doivent pouvoir accéder au système 37 pour modifier leurs choix.

Phase d'Initialisation • Définition des risques – Le risque principal est constitué par l'interface IHM (bonne acceptation par les étudiants et professeurs)

• Identifier les acteurs – – – –

Étudiant Professeur Employé du service enregistrement Système de facturation des droits d'inscription (externe)

38

Diagramme des Cas d’Utilisation (1/2) SYSTEME

Système Facturation

Inscription aux cours

Interrogation étudiants inscrits aux cours

Sélection cours

Étudiant

Professeur

Préparation catalogue cours Employé Inscription

Màj des informations professeurs

Màj des informations étudiants

Màj des listes de cours

39

Diagramme des Cas d’Utilisation (2/2) Un cas d'utilisation peut c ontenir des diagrammes de cas d'utilisation, formant ainsi une arboresc ence.



En pratique, l'arborescence des cas d'utilisations correspondra à l'arborescenc e du menu de l'application.



Les fonc tionnalités élémentaires classiques (ajouter un item, modifier un item, supprimer un item) correspondront aux scénarii contenus dans un c as d'utilisation



40

Modèle Fonctionnel / Le virage vers l’objet • Principe de la collaboration • Du Cas d’utilisation à la décomposition structurée • Du Cas d’utilisation à la décomposition Objet • Cas d’utilisation et scénarios • Description Textuelle d’un Use Case

41

Principe de la collaboration • Le passage à l’approche objet s’effectue en associant une ou plusieurs collaboration à chaque cas d ’utilisation. • Collaboration : description des objets d ’un domaine , les connexions entre ces objets et les messages échangés par les objets.

1

42

Du Cas d’utilisation à la décomposition structurée C as 1 <>

C as 2

Cas 3

Une approche structurée réalise un cas d ’utilisation au moyen d’une décomposition fonctionnelle

43

Du Cas d’utilisation à la décomposition objet

C as 1 <>

C as 2

Cas 3

Une approche objet réalise un cas d ’utilisation au moyen d ’une collaboration entre objets

44

Cas d’utilisation et scénarios 

Les cas d’utilisation doivent être vus comme une machine de production de différents scénarios.



Chaque fois qu’un acteur interagit avec le système, le cas d’utilisation instantie un scénario.



Un scénario correspond au flot de messages échangés par les objets durant l’interaction particulière qui correspond au scénario.

45 [PAM-00 p155]

Cas d’utilisation et2 scénarios Scénario 3 Scénario 1 Scénario Cas d’utilisation

Un cas d’utilisation décrit, de manière abstraite, une famille de scénarios. 46

Description Textuelle d’un Use Case 1.

Sommaire d’identification      

1.

Titre Résumé Acteurs Date de création Version Responsables

Description des enchaînements     

Préconditions Scénario nominal Enchainements alternatifs Enchainements d’erreur Postconditions

47

Description Textuelle d’un Use Case(Complément) Exigences non fonctionnelles:

Contraintes

Descriptif

Temps de réponse Concurrence Disponibilité Sécurité/Intégrité Confidentialité Traçabilité Besoins d’IHM 48

En conclusion 

Les cas d'utilisation recentrent l'expression des besoins sur les utilisateurs



Outil d ’aide à l ’identification et à la structuration des besoins. On structure la démarche par rapport aux interactions d'une seule catégorie d'utilisateurs à la fois.



Outil d ’aide à l’analyse et à la conception objet. On s ’intéresse à un ensemble de classes qui collaborent dans un certain contexte (celui du cas d ’utilisation)





Description de la structure de la collaboration



Description du comportement de la collaboration

Outil de communication 49

Plan • Présentation d’UML • Modèle Fonctionnel • Modèles Statiques • Modèles Dynamiques • UML et les méthodologies de développement logiciel • Conception centrée sur l ’architecture

50

Modèle Statique • Diagramme d ’objets • Diagramme de classes • Diagramme des composants • Diagramme de déploiement • Exemple d’application

51

Diagramme d’Objets • 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. Nom de l’objet : Classe

Ahmed : personne âge = 35

Attributs = valeurs

Personne âge : entier

patron collaborateur

Ali : personne

collaborateur *

patron 1 emploie>

âge = 25 Diagramme de classes Diagramme d ’objets

Un objet est une instance de classe et un lien est une instance d’association. 52

Modèle Statique / Diagramme des Classes • • • • • • • • • • • • • •

Définitions Relations entre classes Associations Nommage des associations Multiplicité des associations Arité des associations Placement des attributs et des associations Contraintes Agrégation Composition Cardinalité des compositions Exemple de diagramme de classes La hiérarchie des classes Paquetage de classe

53

Définitions / Exemple Structure statique d’un système, en termes de classes et de relations entre ces classes. Voiture Couleur

Nom de classe Attributs

exemple :

Opérations ()

Cylindrée Vitesse max Démarrer () Accélérer ()

Syntaxe:

Freiner ()

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

Relations entre classes

classe 2

généralisation

classe 1

n tio a i oc ass

spécialisation

A chaque famille de liens entre objets correspond une relation entre les classes de ces mêmes objets. constructeur

1

1..*

véhicule

1

1..*

moteur

classe 3 voiture

camion

avion

agrégation

classe 4

Agrégation Association Généralisation 55

Association • L’association exprime une connexion sémantique bidirectionnelle entre classes. • Une association est une abstraction des liens qui existent entre les objets instances des classes associées. • Les associations se représentent de la même manière que les liens.

56

Association Rôle • Il est possible de préciser le rôle d’une classe au sein d’une association: un nom de rôle peut être spécifié de part et d’autre de l’association.

57

Nommage des associations constructeur

personne

personne

produit

fabricant

Construire>
passager


véhicule

conducteur

Conduit>

véhicule

propriétaire

Possède>

véhicule

employé

<Emploie

employeur

directeur

Dirige>

société

actionnaire

Possède>

véhicule

véhicule

entreprise

société

58

Multiplicité des associations • Les rôles portent également une information de multiplicité qui précise le nombre d’instances qui participent à la relation 1

Un et un seul (obligatoire)

0 .. 1

Zéro ou un (optionnel)

m .. n

De m à n (entiers)

* ou 0 .. * 1 .. *

Personne

quelconque Au moins 1

0..* Employeur Employé 1

Société

59

Arité des associations Association d’arité 3 Salle lieu

Etudiant

Cours

Enseignant

Début Fin

60

Placement des attributs et des associations

Etudiant

1 0..* Diplôme Mention

Réalise > 0..* 0..*

Travail

1 Note

0..1 Chambre Numéro

61

Contraintes personne

Est_titulaire> 1

personne

0 .. *

compte

{Ordonnée}

0 .. * Parent d ’élève

classe

{Sous ensemble}

0 .. * Délégués

personne

0 .. * Enseignants

0 .. *

université

{Ou-exclusif}

Etudiants

62

Exemple de diagramme de classes

•

•

Un client peut exister sans avoir de lien avec une commande. Par contre, une commande n’a pas de sens sans lien vers son « parent » le client. → Notion d’agrégat Une ligne de commande n’est en aucun cas partageable entre plusieurs commandes; la suppression d’une commande implique nécessairement la suppression de toutes ses lignes. → Notion de composition

63

Agrégation (1/2) • L’association représente un couplage faible, les classes associées restent relativement indépendantes l’une de l’autre. • L’agrégation est une forme particulière d’association qui exprime un couplage plus fort entre classes. • Une des classes joue un rôle plus important que l’autre dans la relation. • L’agrégation permet de représenter des relations de type maître et esclaves, tout et parties ou composés et composants 64

Agrégation (2/2) Livre

1 .. * 1

Chapitre

{Ordonnée}

Agrégation

{Ordonnée}

• transitive : si voiture est composée de moteur et si moteur est composé de courroie alors voiture est composée de courroie

1 .. *

Paragraphe

• non symétrique : si voiture est composée de moteur, moteur ne peut pas être composé de voiture • Éventuellement réflexive : une fonction peut être composée d’autres fonctions 65

Composition (1/2) Homme

1

1

Tête

Composition La composition traduit une dépendance existentielle forte.

66

Composition (2/2) • La composition est une forme d’agrégation avec un couplage plus important. • Ce couplage de composition indique que les composants ne sont pas partageables et que la destruction de l’agrégat entraîne la destruction des composants agrégés. • La valeur maximale de multiplicité du côté du conteneur ne doit pas excéder 1 puisque les objets, instances de la classe des composants, doivent tous appartenir au même objet conteneur.

67

Cardinalité des compositions /Composants

• Une galerie peut exister sans être installée sur une voiture: Agrégat

0..1

• Une galerie ne peut exister que comme partie d’une voiture : Composition

1

• Physiquement impossible! Un composant ne peut être partie de plus d’un composite. • Une galerie ne peut être installée, simultanément, sur plus d’une voiture.

0..*

68

Cardinalité des compositions / Composite

0..1

• Une voiture n’est pas obligatoirement équipée d’une galerie. • La galerie peut être assimilée à un attribut optionnel.

1

• Toute voiture est équipée d’une galerie. • La galerie peut être assimilée à un attribut obligatoire.

0..*

• Une voiture peut être équipée de plusieurs galeries. 69

Les hiérarchies de classes Les

hiérarchies de classes ou classifications permettent de

gérer la complexité en ordonnant les objets au sein d’arborescences de classes d’abstraction croissante. La

généralisation: il s’agit de prendre des classes existantes

(déjà mises en évidence) et de créer de nouvelles classes qui regroupent leurs parties communes; il faut aller du plus spécifique vers le plus général. La

spécialisation: il s’agit de sélectionner des classes

existantes (déjà identifiées) et d’en dériver de nouvelles classes plus spécialisées, en spécifiant simplement les différences. 70

Les hiérarchies de classes / Généralisation La

généralisation consiste à factoriser les éléments communs d’un ensemble de classes dans une classe plus générale appelée super-classe.

Les

classes sont ordonnées selon une hiérarchie; une superclasse est une abstraction de ses sous-classes.

La

généralisation est une démarche assez difficile car elle demande une bonne capacité d’abstraction. La mise au point d’une hiérarchie est délicate et itérative.

Les

arbres de classes ne poussent pas à partir de leur racine. Au contraire, ils se déterminent en partant des feuilles car les feuilles appartiennent au monde réel alors que les niveaux supérieurs sont des abstractions construites pour ordonner et 71 comprendre.

Les hiérarchies de classes / Généralisation Abstractions plus générales

Il y a généralisation car on s’intéresse d’abord aux voitures, motos, avions et hélicoptères et ensuite seulement on les classe en véhicules.  L’itération de la démarche se justifie pour opérer un classement plus fin sous forme de véhicules terrestres et de véhicules aériens. 72 

Les hiérarchies de classes / Généralisation

Extension par spécialisation



Il y a spécialisation car on a classé les transmissions par technologies différentes et ensuite seulement on s’intéresse aux réalisations techniques: variateur, dérailleur ou boîte de vitesses.

73

Généralisation

noit asil ai cé p S

Les hiérarchies de classes / Règles de Généralisation



La généralisation ne porte aucun nom particulier; elle signifie toujours: est un ou est une sorte de.



La généralisation ne concerne que les classes, elle n’est pas instantiable en liens et, de fait, ne porte aucune indication de multiplicité. 74

Les hiérarchies de classes / L’héritage 

L’héritage est une technique offerte par les langages de programmation pour construire une classe à partir d’une ou de plusieurs autres classes, en partageant des attributs, des opérations et parfois des contraintes au sein d’une hiérarchie de classes.



Les classes enfants héritent des caractéristiques de leurs classes parents.



Les attributs et les opérations déclarés dans la classe parent, sont accessibles dans la classe enfant, comme s’ils avaient été déclarés localement. 75 [PAM-00 p57]

Les hiérarchies de classes / Héritage multiple (1) 

La généralisation - sous sa forme dite multiple – existe également entre arbres de classes disjoints.

76

Les hiérarchies de classes / Héritage multiple (2) 

Pour que l’héritage multiple puisse être mise en œuvre, il faut qu’il puisse être supporté par les langages de programmation « objets » .



Dans l’exemple, comment le compilateur peut-il garantir, lors de l’implémentation de la classe Z, qu’il n’y ait pas de conflit entre les propriétés A héritée de la classe X et A héritée de la classe Y?



Par exemple, JAVA ne supporte pas l’héritage multiple.

77

Les hiérarchies de classes / Classe abstraite (1) 

Une classe abstraite ne donne pas directement des objets.



Elle sert en fait de spécification plus abstraite pour des objets instances de ses sous-classes.



Le principal intérêt de cette démarche est de réduire le niveau de détails dans les descriptions des sous-classes.



Le nom d’une classe abstraite est en italique dans les diagrammes de classes.

78

Les hiérarchies de classes / Classe abstraite (2) Exemple Classes abstraites

Classes concrètes les classes Transmission, Continue et Discrète ne servent qu’à classer les objets réels que sont les variateurs, les dérailleurs et les boîtes de vitesses. 79

Les hiérarchies de classes / Le polymorphisme (1) 

Le terme polymorphisme décrit la caractéristique d’un élément qui peut prendre plusieurs formes, comme l’eau qui se trouve à l’état solide, liquide ou gazeux.



En informatique, le polymorphisme désigne un concept de la théorie des types, selon lequel une méthode peut s ’appliquer à des de classes différentes issues d’une même arborescence.

80

Les hiérarchies de classes / Le polymorphismeExemple (2)

•

La classe Animal est un exemple de classe abstraite

•

L’opération dormir() de la classe Animal est abstraite; elle est polymorphe et réalisée par chacune des sous-classes Lion, Tigre et Ours.

•

la classe Animal comporte: ¬ Une propriété privée Nom ¬ Une opération protégée tonNom() qui permet à chacune des sous-classes de récupérer le nom de l’animal. 81

Les hiérarchies de classes / Le (suite) polymorphismeExemple (3)

•

Ce diagramme ne contient pas d’objets de la classe Animal.

•

La classe Animal étant abstraite, la représentation des animaux ne peut se faire que par les sous-classes, Lion, Trigre et Ours qui permettent l’instantiation d’objets. 82