Modélisation Orientée Objet

1

1

Modélisation Orientée Objet

Hassan El Mansouri

2

Qu'est-ce qu'un modèle ?

� Le monde réel est composé de :

� Des entités tangibles (matérielles) : voiture, bâtiments, chiens, etc� Des entités conceptuelles (virtuelles) : le temps, compte bancaire, planning de réunions, etc.

� Un modèle est une représentation abstraite mais simple du monde réel.

Pourquoi modéliser ?

� La modélisation est nécessaire car nous sommes incapables d'appréhender la complexité des systèmes dans leur intégralité : Un modèle est une abstraction (simplification) d’une réalité.

� La modélisation est nécessaire car nous n’intéressons pas qu’à une partie du système ou à l’un des aspects du ce système : un modèle présente le point de vue du modélisateur (sa perception). Un modèle n’est pas la réalité mais une vue subjective de la réalité.

� Un modèle facilite l’évolutivité des systèmes : Il les documente et aide à les organiser et à les comprendre.

Comprendre la modélisation

Modélisation Orienté Objet H. El mansouri

3

Trois objectifs

� Spécifier la structure (approche statique) et les comportements (approche dynamique) attendus du système observé ou à mettre en place.

� Visualiser l’architecture pour mieux la comprendre.

� Documenter les choix effectués

Principes de modélisation

� Un modèle doit coller à la réalité.

� Plusieurs modèles peuvent être nécessaire pour appréhender le système. Un seul modèle peut s’avérer insuffisant.

� Le modèle choisi impacte directement les solutions mises en place.

� Tout modèle peut être exprimé à différents niveaux de précision (abstraction). (direction / employé)



4

Approches de Modélisation (1)

� Approche fonctionnelle

� Objectif

� On modélise ce que fait le système et pas le système lui-même.� Décompose le système en fonctions, sous-fonctions, etc

� avantage

� Démarche facile car intuitive.

� Inconvénient

� Les fonctions restent dépendantes : les fonctions ont une vision hiérarchiquement limitée du système (pas de visibilité globale).

� Couplage fort : La remise en cause d’une fonction peut conduire à une remise en cause plusieurs autres fonctions :

� Les fonctions sont dépendantes d’un seul état partagé: Modification de l’état partagépeut impacté fonctionnement de l’intégralité du système.

� Difficile à maintenir (conséquence) et réutilisabilité est très difficile à mettre œuvre.



2

5

Approches de Modélisation (2)

� Approche Objet

� Objectif

� Modélise le système lui-même (contrairement à l’approche fonctionnelle� en le décomposant en objets et en précisant leur liens respectifs.

� avantage

� Stabilité du modèle par rapport au monde réel : un objet est une traduction 1-1 d’une entité du monde réel.

� Un objet est une entité + ou - autonome : il encapsule sont état et il peut la partager selon des règles strictes.

� Un objet est réutilisable = facile à maintenir.� Facilité de modélisation : Il y a uniquement 5 concepts fondateurs : les objets, les messages, les classes, l’héritage et le polymorphisme.

� Inconvénient

� Difficile pour ceux qui ont une culture fonctionnelle de modélisation.



6

L’objet (1)

� Un objet est une entité vivante

� C’est une représentation abstraite d’une entité du monde réel.� C’est entité atomique : le niveau d’abstraction le moins élevé.� Il dispose d’un comportement.� Il dispose d’un cycle de vie : un objet se crée, vit et disparaît.

� Un objet est entité collaborative

� Il fait partie d’un système.� Il dispose d’une responsabilité.� Il dispose d’une relation faible avec les autres objets du système.� Il communique avec les autres via des messages selon un ou plusieurs scénario de

communication.

Corpus de la MOO


7

L’objet (2)

� Caractéristiques d’un objet (1)

La question : qu’est-ce qui définit un objet ?

Objet = [Etat]+ [Comportement] + Identité

� État

� Un objet dispose d’un ensemble de propriétés.

� Chaque propriété d’un objet peut se voir attribuer une valeur.

� L’état d’un objet regroupe les valeurs de toutes ces propriétés, à un instant donné.

� Exemple : Etat de deux objets étudiants avec 4 propriétés.

Corpus de la MOO


8

L’objet (2)


� Remarque : L’état d’un objet évolue dans le temps pour refléter les comportements passés. Exemple:

Evolution de l’état d’un objet

Corpus de la MOO


3

9

L’objet (3)


� Le comportement

� Le comportement d’un objet est l’ensemble ces compétences : Ce qu’il est capable de faire.

� Un atome de comportement est appelé opération.

Exemple : un avion peut effectuer plusieurs opérations comme celle de l’atterrissage et du décollage.

� Une opération est déclenchée à la suite d’un message (stimulus) reçu d’un autre objet.

Corpus de la MOO


10

L’objet (3)


� L’identité

� n’a pas de représentation spécifique en modélisation.� Lorsque implémente un objet. On n’est capable de l’identifié sans aucune ambiguïté.� Ne pas confondre l’identité et l’identifiant d’un objet (ex. N° Sécu, N° d’immatriculation).� Exemple : On est capable de distinguer entre deux personnes qui ont le même âge et le même nom.

� Remarque :

Un objet a obligatoirement une identité, mais il se peut que l’on rencontre des objets sans état ou sans comportement.

Corpus de la MOO


11

L’objet (4)

� La persistance des objets

� Désigne la possibilité de sauvegarder l’état d’un objet au-delà de la durée de vie du processus qui l’avait crée. Cela signifie:

� que le support de sauvegarde est permanent : BD, fichiers, etc.

� Qu’il possible à un autre processus (autre que celui qui avait déjà crée l’objet) de reconstruire l’objet et retrouver son état. L’objet va donc va se comporter exactement de la même façon que dans le processus initial.

� En règle générale les langages objet ne proposent pas de moyens pour assurer la persistance des objets.

� Les constructeurs de BD fournissent des solutions pour la sauvegarde des objets : API spécialisées, etc.

� Remarque : Les objets non persistant sont appelés transitoires. Par défaut, les objets ne sont pas persistants.

Corpus de la MOO


12

La classe (1)

� Naissance du concept de classe

� Le monde réel est constitué de très nombreux objets en interaction.

� Ces objets et leur interactions sont trop complexe pour être appréhender facilement.

� Pour réduire voire maîtriser cette complexité , l’être humain a appris à regrouper les éléments qui se ressemblent et à distinguer des structures de plus haut niveau, débarrassées de détails inutiles.

� Pour structurer les objets (identification des caractéristiques communes) on a fait appel au concept de classe.

� La définition de classe

� C’est un artéfact structurant d’objets.

� C’est une "structure" (moule) à partir de laquelle des objets sont issus.

� Un objet est donc un instanciation d’une classe (objet = instance = occurrence)

Corpus de la MOO


4

13

La classe (2)

� La structure d’une classe

Une classe est composée en deux parties : les attributs et les méthodes.

� Les attributs

� Se sont les propriétés de la classe.� Sont définis par un nom, par un type, et éventuellement une valeur initiale

� Exemple

Corpus de la MOO


14

La classe (3)


� Instanciation des attributs

� Chaque objet dispose d’une valeur pour les attributs définis dans sa classe.� A un instant t tous les attributs d’une classe pour un objet peuvent ne pas avoir tous une valeur.

� Exemple

Corpus de la MOO


15

La classe (3)


� Les méthodes

� Ce sont les Implémentations des opérations (services) offertes par les instances de la classe.

� Il existe 5 principales catégories d’opérations :

� Les constructeurs créent des nouveaux objets.� Les destructeurs détruisent des objets existants (pas tous les langages).� Les sélecteurs (getXXX(…)) renvoient une partie de l’état (valeur des attributs) des objets.

� Les modificateurs (setXXX()) mettent à jour l’état des objets.� Les itérateurs (uneCollection.iterator().next()) parcourent l’état d’un objet ou le contenud’une structure de données contenant plusieurs objets.

� Exemple

Corpus de la MOO


16

La classe (3)

� Encapsulation

� Les attributs d’un objet ne sont accessibles que via ces méthodes : c’est le principe de l’encapsulation.

� Les méthodes représentent donc l’interface de l’objet permettant d’accéder à ses attributs.� Par défaut les valeurs attributs sont encapsulés dans l’objet.

Encapsulation des attributs

Corpus de la MOO


5

17

La classe (4)

� Avantages

� Garantir l’intégrité des données. Par exemple : conformité du type des données fourni par rapport au type attend. Les données fournies sont comprises dans l’intervalle attendu, mises à jour en cascade, etc.

� Masquer la complexité de l’implémentation. L’objet est vu comme une boîte noire.� En disposant des interfaces, on s’occupe plus de l’implémentation.� Le traitement des erreurs est géré par l’utilisateur de l’objet.

Corpus de la MOO


18

La classe (7)

� La visibilité

� Les règles de visibilité viennent compléter ou préciser la notion d’encapsulation (assouplir). 3 niveaux de visibilité sont généralement retenus :

� Un attribut est dit "privé" (représenté par - ) lorsqu’il n’est visible que pour les méthodes de sa classe.

� Un attribut est dit "protégé" (représenté par # ) lorsqu’il n’est visible que pour les méthodes de sa classe et pour les méthodes des classes dérivées de celle-ci.

� Un attribut est dit "public" (représenté par + ) lorsqu’il est visible pour toutes les classes. Cela revient à se passer de la notion d’encapsulation.

� Autre représentation graphique :

� Remarque :� L’intérêt d’assouplir d’encapsulation est de réduire

le temps d’accès aux attributs en supprimant la nécessité de recourir à des opérations de type sélecteur.

� La visibilité porte également sur les méthodes.

Corpus de la MOO


19

Origine et Intérêt d’UML (Unified Modeling Language)

� Un lagage né de la fusion de plusieurs méthodes objet antérieures, standard de fait : OMT (ObjectModeling Technique) , OOD (Object Oriented Design), OOSE (Object Oriented Software Engineering), etc

� langage conçu pour représenter des modèles, mais il ne définit pas le processus d'élaboration des modèles (ce n’est pas une méthode).

� utilisable pour visualiser, spécifier, construire et documenter.

� Peut servir de support pour tout langage objet.

� Notations graphiques simples compréhensibles par des non informaticiens et facilitant la communication.

� Préconise l’utilisation d’une démarche :� itérative et incrémentale : en affinant l’analyse d’une façon progressive et par étapes.� guidée par les besoins des utilisateurs du système : Le processus de modélisation doit être

cadré par les besoins des utilisateurs.� centrée sur l'architecture logicielle : afin de construire une architecture adaptée garantissant

la production d’un logiciel de qualité (adaptabilité, performances, fiabilité, etc.).

� A été fortement inspiré par le modèle d'architecture de Kruchten [1995] (les 4+1 vues) . Ce modèle propose 5 vues, indépendantes mais complémentaires.

UML : Langage de Modélisation


20

Le modèle d'architecture des 4+1 vues (1)

Ce modèle propose 5 vues.

� Vue logique (ou de conception) :

� Modélise les éléments statiques (classes, objets, diagramme de classes) et dynamiques du système (diagramme d’interaction, d’états-transaction et d’activité).

� Elle organise également ces éléments en "catégories" afin de répartir les tâches au sein des équipes.



6

21

Le modèle d'architecture des 4+1 vues (2)

� Vue des processus

� utilisée dans un environnement multitâches. � décompose le système en processus et en threads.� Identifie leur communication, leur concurrence et leur synchronisation.

� Vue des composants (développement, implémentation ou encore implantation) :

� identifie les modules (au sens physique) (fichiers sources, bibliothèques dynamiques, bases de données, exécutables, fichiers de configuration, etc...) qui implémentent les classes de la vue logique.

� identifie contraintes de développement (bibliothèques externes...).

� Vue de déploiement (physique)

� décrit les ressources matérielles.� décrit la répartition du système sur ces ressources. � décrit les exigences en terme de performances (temps de réponse, tolérance de pannes,

etc.).

� Vue des besoins des utilisateurs (des cas d’utilisation)� présente une abstraction des exigences fonctionnelles. � Elle sert de guide à toutes les autres vues.



22

UML: Les diagrammes de modélisation (1)

� UML modélise le système selon deux vues différentes mais complémentaires : statique et dynamique.

� Vue statique : modélisation par des diagrammes structuraux.� Vue dynamique : modélisation par des diagrammes comportementaux.



23


� Vue statique

� diagrammes de cas d’utilisation : décrit les fonctions du système selon le point de vue des utilisateurs.

� diagrammes de classes : structure leu système et définit les relations entre ces classes.

� diagrammes d’objets : illustre des objets et de leur relations.

� diagrammes de composants : décrit l’architecture des composants physiques d’un système.

� diagrammes de déploiement : décrit le déploiement des composants sur les dispositifs matériels (nœuds, etc.).



24


� Vue dynamique

� diagrammes de séquence : représente des interactions temporelles entre objets

� diagrammes de collaboration : représente les interactions entre objets.

� diagrammes d’états-transition : représente le comportement des objets d’une classe en terme d’états et de transitions d’états.

� diagrammes d’activités : structure les opérations en actions

� En résumé :

� Chaque diagramme met en avant des aspects différents pour modéliser un système.

� Les organigrammes ne sont pas tous utilisés systématiquement dans les projets réels: UML n’impose aucun modèle. Chaque modélisateur peut utiliser le type de diagramme qui lui parait le plus adapté pour représenter son problème.

� L’ordre que nous allons utiliser pour présenter ces organigrammes ne reflète pas un ordre de mise en œuvre dans un projet réel, mais simplement une démarche pédagogique.



7

25

Les composants d’un diagramme de Cas d’Utilisation

– 3 composants :

� Les Cas d’Utilisation

� Les acteurs

� Les associations

Diagramme de Cas d’Utilisation


26

Qu’est-ce qu’un cas d’utilisation ?

Un Cas d’utilisation (Use Case = UC)

� Capture les besoins de l’utilisateur : modélise une fonctionnalité du système qui est significative pour ses utilisateurs (humains, matériels, logiciels, etc.) :

� Utilise le vocabulaire des utilisateurs.

� De ce fait, c'est un outil puissant pour valider rapidement les exigences des utilisateurs (Requirements).

� Représenté graphiquement par une ellipse :



27

Qu’est-ce qu’un cas d’utilisation ?

� Conséquences

� L’élaboration des différents cas d’utilisation permet de délimiter le périmètre d'un système : ce qui doit faire partie du système à développer et ce qui n’en fait pas partie.

� Les cas d’utilisation guident la communication entre les participants du projet tout au long du projet : un langage commun.

� Un projet est constitué de plusieurs collaborations. Une "collaboration" est une réalisation d’un certain nombre de cas d'utilisation.



28

Un acteur (1)

� Un acteur représente un rôle joué par un individu, un système, un processus, une organisation ou une chose qui bénéficie d'un cas d'utilisation. Exemple : emprunteur de livre.

� Il interagit (depuis l’extérieur) avec le système : un acteur est donc situé à l'extérieur d'un système.

� L'acteur peut consulter ou modifier l'état du système.

� En réponse à l'action d'un acteur, le système fournit un service qui correspond à la fonctionnalité désirée.

� Comment sont déterminés les acteurs :

� en observant les utilisateurs directs du système, ceux qui sont responsables de son exploitation ou de sa maintenance.

� Les autres systèmes qui interagissent avec le système.

� Représenté graphiquement par un petit personnage ou une classe.



8

29

Un acteur (2)

� Remarques :

� Le nom de l’acteur décrit son rôle lorsqu’il interagit avec le système : le nom de être significatif de sa responsabilité : il peut avoir plusieurs rôles

� Les acteurs doivent être décrits d’une manière claire et concise, avec notamment le détail de leurs responsabilités respectives, en 3 ou 4 lignes maximum.

� La même personne physique peut jouer le rôle de plusieurs acteurs (vendeur, client).

� Plusieurs personnes (système, processus, etc.) peuvent jouer le même rôle, et donc agir comme seul et même acteur. Exemple :



30

Un acteur (3)

� Catégories d’acteurs

� Acteurs principaux : Bénéficiaires directs du service décrit par un cas d’utilisation. Exemples : Emprunteur de livres, client d’un distributeur de billets.

� Acteurs secondaires (ou de support) : Participant offrant un service (administratif ou maintenance) qui contribue à la réalisation du cas d’utilisation. Exemples : Libraire, agent alimentant la caisse d’un distributeur de billets.



31

Les associations

� L’interaction entre acteur et cas d’utilisation se fait par envoie de message.

� Une interaction est représentée par une association :



32

Exemple :


Modélisation d’un atelier de réparation de voiture par un diagramme de UC

Cas d’utilisation ? :Acteurs ? :Associations ? :


Réparer, vendreMécanicien, Vendeur

Mécanicien/Réparer, Vendeur/Vendre

– On peut imaginer le cas d’un petit atelier, où un employé effectue des tâches polyvalentes. Son activité principale est mécanicien, mais vend d’une façon occasionnelle des voitures.

– Les 2 acteurs ont une réalité physique matérialisée en une seule et unique personne.

9

33

Question :


Pourquoi ce diagramme serait faux :


Le système observé

34

Instance de Cas d’Utilisation: scénario (1)

Scénario

• C’est instance d’un cas d’utilisation.

• Une instance de Cas d’Utilisation représente l’une réalisation particulière de ce UC.

• Un scénario est donc :

� Instance d’un Cas d’Utilisation.� Décrit une exécution possible d’un cas d’utilisation.� Séquence spécifique d’actions et d’interactions entre les acteurs et le système.� Un cas d’utilisation est composé :

• D’un scénario principal (scénario nominal ou main flow).• D’aucun ou plusieurs scénarios secondaires (variantes, alternative flow).



35

Détermination des scénarios

Deux étapes :

1. On détermine le déroulement normal (càd la séquence d’actions) du Cas d’utilisation : le scénario principal.

2. On recherche le ou les déroulements alternatifs : des scénarios secondaires

� Y a t'il d’autres actions possibles qui pourrait s’effectuer en dehors du scénario principal ?

� Y a t' il « quelque chose » qui pourrait mal fonctionner lors de l’exécution des différentes actions ?

� Y 'a t'il quelques événements qui pourraient se produire lors de l’exécution des différentes actions ?



36

Instance de Cas d’utilisation: scénario (2)

� Exemple : Système de prêt dans une bibliothèque

� Cas d’utilisation: Prêt d’un livre

� Description :

� Acteur (s) : Emprunteur de livres

� Pré-conditions :L’emprunteur de livres se présente avec un exemplaire de livre à emprunter et sa carte de lecteur.

� Scénario principal :– La carte de lecteur est lue.– Le système vérifie si (1) l’emprunteur est bien inscrit à la bibliothèque et (2) qu’il n’a pas dépassé le quota de livres en prêt autorisé.

– Les deux vérifications sont réussies. Le code de l’exemplaire à emprunter est entréet le système vérifie alors si l’exemplaire est réservé (3).

– L’exemplaire n’étant pas réservé, le système enregistre le prêt. Un ticket est émis indiquant la date de retour.



10

37

Instance de Cas d’utilisation: scénario (3)

� Scénario secondaire (A) :– L’emprunteur n’est pas inscrit à la bibliothèque (1).– Le système signale le problème et refuse la demande de prêt.

� Scénario secondaire (B) :– L’emprunteur a dépassé le quota de livres en prêt autorisé.– Le système signale le problème et refuse la demande de prêt.

� Scénario secondaire (C) :– Le code de l’exemplaire à emprunter est entré et le système signale que l’exemplaire est réservé.

– Le système signale le problème et refuse la demande de prêt.

� Post-conditions:Si le cas d’utilisation s’est déroulé normalement, le prêt de l’exemplaire est enregistré par le système et l’emprunteur détient un ticket lui indiquant l’échéance du prêt.



38

Relations (1)

� Des relations peuvent exister :

� Entre acteurs et cas d’utilisation� Entre cas d’utilisation� Entre acteurs

� 4 types de relations

� Relation de communication :� Le sens de la flèche désigne qui initie la communication.



39

Relations (2)

� Relation d'utilisation (Include) :

• C’est le fait qu’un UC inclus un autre.• Le cas inclus est nécessairement exécuté si le cas de base est instancié.

"gérer les profils" est inclus forcement dans "gère système"

• Les relations d’inclusion sont le résultat :– de la factorisation en sous-fonctions communes à d’autres cas d’utilisation.– de la décomposer en sous-fonctions un cas d’utilisation complexe.



40

Relations (3)

� Relation d'extension (Extend) :

� Cette relation permet de modéliser des variantes de comportement d’un UC (ex. selon les interactions des acteurs et l’environnement du système).

� Ces variantes de comportement sont modélisées par d’autres UC.

� Ces UC étendent le comportement du UC de base.

� Un UC d’extension n’est pas nécessairement exécuté même si le UC de base est instancié.

� L’extension peut être soumise à une condition.

« gère le système à distance" est une variante "gère le système"



11

41


Relations (4)

� Relation de généralisation entre UC

� Permet à un UC (UC enfant) de spécialiser le comportement d’un UC de base (UC parent).

� Le UC parent peut être abstrait. Les UC enfant qui sont généralement concrets(exécutés concrètement).


42

Relations (5)

� Relation de généralisation entre acteurs

• Un acteur peut spécialiser un autre acteur.

• Plusieurs acteurs peuvent spécialiser le même acteur.

• Conséquences : Les acteurs "enfants" seront alors capables de communiquer avec les mêmes UC que l’acteur "parent".

Un superviseur peut communiquer avec le cas d’utilisation "affichage"



43

Construire un diagramme de cas d’utilisation (1)

� 1. Identifier les tâches significatives du système visibles de l’extérieur (cas d’utilisation).

� Les exigences d’un système sont essentiellement centrées sur les besoins de l’utilisateur.� On se concentre ici sur les préoccupations réelles des utilisateurs ; pas de solutions

d'implémentation, pas d’inventaire fonctionnel du système. tentation à éviter: faire la liste des tâches et procédures du système.

� 2. Identifier les acteurs qui interagissent avec chacune de ces tâches.

� Qui démarre et arrête le système ?� Qui gère et/ou initie les mises à jour ?� Le « temps » est-il un acteur (ex. si le système réagit aux événements temporels…) ?� Qui administre le système ?� Etc.



44

Construire un diagramme de cas d’utilisation (2)

� 3. Pour chacun des acteurs, identifier les objectifs principaux qu’il souhaite voir réaliser puisqu’il en est le bénéficiaire direct.

� 4. Définir les UC à partir des objectifs principaux définis en 3. Utiliser un verbe d’action pour nommer chaque UC.

� 5. Structurer les cas d’utilisation:

� Regrouper les UC en Packages : relations sémantiques très fortes.� Identifier les relations d’héritage, « include », « extend » et découvrir ainsi les éventuels cas

d’utilisation internes (limiter la hauteur de la hiérarchie de relation à 2).

Remarque :

� Les UC serviront de base à la validation et à la traçabilité du système. Ils seront le fil conducteur de tout le développement.

� Savoir juger du bon niveau de granularité à adopter pour assurer une décomposition qui demeure claire et compréhensible. Pas plus de 20 cas d’utilisation même pour les systèmes très complexes.



12

45

Exemple 1 : Système de prêt dans une bibliothèque



46

Exemple 2 : Système de traitement des commandes



47

� Exemple 3 : Modélisation d’une école (correction)

Considérer la modélisation d’une école pour laquelle on utilise les concepts de:

– École– Département– Directeur– Professeur– Étudiant– Cours– Bulletin– Notes– Examens

Dans un premier temps on souhaite établir le diagramme d’UC.



48

Exemple 3 : Modélisation d’une école (correction)



13

49

Représentation des objets

� Quelques représentations graphiquement :

• Une instance nommée d’une classe anonyme(modélisation incomplète, la classe de l’objet n’est pas encore précisée).

• Une instance nommée de la classe Voiture.

• Une instance anonyme de la classe Voiture.

• Une instance anonyme de la classe Voiture,dont les valeurs 2 d’attributs sont spécifiées explicitement.

• Collection d’instances anonymes de la classe Voiture

Diagramme d’Objets


50

Communication entre les objets

� Un système est un ensemble d’objets qui interagissent entre eux afin de réaliser les différentes fonctionnalités du système.

� Pour collaborer à la réalisation de ces fonctionnalités, les objets sont reliés par des liens de

communication.

� Ces liens représentent des connexions entre les objets un instant donné seulement

� L’interaction entre les objets dépend de leur type respectifs -> le type de l’objet définit donc son comportement au sein du système



51

Typologie des objets

Trois types d’objets :

les acteurs, les serveurs et les agents.

� Les acteurs (objets actifs) :

� sont à l’origine des interactions

� possèdent un fil d’attente d’exécution.

� passent la main aux autres objets

� Les serveurs (objets passifs) :

� Sont des fournisseurs de services.

� Ne sont jamais à l’origine des interactions.

� Sont en attente que d’autres objets aient

besoin de leurs services. Dans ce cas, le contrôle

est passé au serveur par le client et est récupéréaprès l’exécution du service demandé. Le client

ne peut pas reprendre ses activités avant la réponse du serveur.



52

Typologie des objets

� Les agents

� Cumulent les caractéristiques les acteurs et des serveurs.

� Peuvent interagir avec les autres à tout moment (de leur propres initiative ou suite à une sollicitation externe).

� Sont à la base des mécanismes de délégation : font le lien entre les des clients et des serveurs qui ne se connaissent pas directement.

� Exemple : Mécanisme de délégation.Le client communique indirectement avec les serveurs sans les connaître via l’agent.(O. formulaire/O. requêteur/Os. accès aux basesde données)

Diagramme d’objets


14

53

Cas d’un lien réflexif

• Un objet peut lié à lui même.

Exemple 1 : Denis est patron de lui-même.

Exemple 2 : un formulaire peut s’envoyer un message à lui-même en cas d’une mauvaise saisie.



54

Les objets composites

• Les objets composites qui se compose d’autres objets.

• Représentation graphique des objets composites

Ce diagramme d’objet est une instance du diagramme de classe suivant :



55

La notion de message (1)

� Un message :

� Un support de communication entre les objets,

� Support de collaboration des objets pour réaliser les différentes fonctionnalités du système.

� Peut contenir des flots de données et/ou des flots de contrôle,

� Relie dynamiquement les objets qui été séparés durant le processus de modélisation (décomposition).

� a pour objet :

� Invocation d’une opération.

� Interruption d’un processus.

� Déclenchement d’un événement.

� Etc.

� représenté graphique par une flèche étiquetée;



56

La notion de message (2)

– Exemple : Les objets communiquent

entre pas échanges de messages.

� Notion de synchronisation

– La notion de synchronisation décrit la communication entre les objets, et les règles qui régissent le passage des messages entre eux.

– Elle prend tout son intérêt lorsque plusieurs objets sont actifs simultanément et qu’il faut, par

exemple, protéger l’accès à des objets partagés (doc partagé) . La synchronisation des envois

de messages devient fondamentale pour que les objets puissent continuer à collaborerensemble.



15

57

Les formes de synchronisation

• Messages simple

• Le contrôle passe de l’objet actif à un objet passif

• Un seul objet est actif

• Messages synchrones

• L’expéditeur est bloqué jusqu’à ce que le destinataire accepte le message



58


• Messages dérobant

• Le destinataire est en attente de messages

• L’expéditeur n’attend pas que le destinataire soit disponible.

• Messages minutés

• L’expéditeur est bloqué pendant le temps alloué au récepteur pour répondre au message



59


• Messages asynchrones

• L’expéditeur envoie le message sans savoir quand, ni même si, le message sera traité par le

destinataire.



60

Exemple les diagrammes d’objet

• Diagramme d’objets pour la modélisation du personnel d’une société



16

61

Exemple 2 : soit le diagramme objet représentant une voiture avec 4 roues et un moteur.

Ce diagramme d’objets peut être traduit pas le diagrammes de classes suivant :



62

Les relations entre les classes

• Les liens reliant les objets peuvent être vus de manière abstraite dans le monde des classes :

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

objets.

• De même que les objets sont des instances de classes, les liens sont des instances des relations

entre classes.

Diagramme de classes

Un lien est une instance d’une association


63

Les relations entre les classes

� 3 sortes de relations entre les classes

– Les associations

– Les agrégations

– Les compositions



64

Association

� Le concept

• 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 dans le cas des objets.


Les liens entre les étudiants et les universités sont tous des instances de l’association entre la classe Universiteet la classe Etudiant.


17

65

Les décorations des associations

• Les associations peuvent être décorées par une expression verbale traduisant cette association. • Le sens de la lecteur (navigation) est représenté pas les signe � et � ou par les flèches à

l’extrémité de l’association.

• Il est possible de préciser le rôle des classes intervenant dans une association : un non de rôle peut être spécifier à chaque extrémité d’une association :

Clarification du rôle des associations par une forme nominale



66

Les décorations des associations

• Une association peut également être décorées par une information de multiplicité. La multiplicité précise le nombre d’instances qui participent à l’association.

• Une université regroupe plusieurs personnes. Certains jouent le rôle d’étudiant, d’autres jouent le rôle d’employer. Un étudiant donné est inscrit à une et une seule université. Un employer donné peut être en activité ou non (retraité).

De un àplusieurs

1..*

De zéro àplusieurs

* ou 0..*

De M à N

(entier naturels)

M..N

Zéro ou un0..1

Un et un seul1 ou 1..1

Représentation du nombre d’instances participant aux

associations



67

Association récursive

• Une classe peut être connectée à elle-même via une association récursive.

• Une instance d’une classe est liée à une autre instance de cette même classe.


Toute personne possède deux parents. Toute personne peut avoir 0 ou plusieurs enfants. La décoration de l’association pas des rôles des deux

extrémités est essentiel à la la compréhension de l’association.


68

Classe-association (1)

Le concept

Également appelée classe associativeC’est une association qui dispose des attributs et des méthodes, comme toute autre classe.Son but des d’ajouter des attributs et des méthodes au lien.

Conséquence: Possède à la fois les caractéristiques d’une classe et d’une association.Peut participer à d’autres relations dans le modèle.

Représenté graphiquement: une ligne pointillée attache la classe associative au lien.



18

69

Classe-association (2)

association attribuéeC’est Une association qui contient des attributs et des méthodes mais ne participe à des relations

avec d’autres classesNe porte pas de nom.



70

Classe-association – exemple

Un exploitant possède plusieurs salles de cinéma. Un film fait généralement l'objet de plusieurs séances par jour. Décrire un schéma qui permet à l'exploitant d'obtenir des renseignements sur le chiffre d'affaire d'un film, d'une salle, d'une séance où d'un jour déterminé .



71

Agrégation

• Par défaut, l’association représente un couplage faible, les classes associées restant 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 agrégation définit une relation entre un tout et ses parties, composé et composants, conteneur et contenus ou agrégat et agrégés.

• Une agrégation est association non symétrique : Une des classes joue donc un rôle plus important que l’autre dans la relation. L’agrégation permet de représenter des relations de subordination de type maître et esclaves.

• Une agrégation se représente graphiquement comme une association, avec un petit losange vide (diamant) placé du côté de l’agrégat.

• Exemple d’agrégation



72

Agrégation

• Remarque :

– Un objet agrégé peut exister sans l’objet agrégat (et inversement) : leurs durées de vie sont indépendantes. Dans l’exemple : Un fichier peut être attaché à 0 ou plusieurs email. Et un email peut (ou non) attacher 0 ou plusieurs fichiers.

– Un objet agrégé peut faire partie de plusieurs objets agrégats.

– Une agrégation favorise la propagation de l’état et des opérations de l’agrégat vers les composants. Envoyer un mail avec un fichier attaché entraîne l’envoi de celui-ci également



19

73

Composition

Aussi il s'agit en fait d'une agrégation à laquelle on impose des contraintes internes : un seul objet peut faire partie d'un composite (l'agrégat de la composition), et celui-ci doit gérer toutes ses parties :

• La composition est appelée aussi "agrégation forte" ou "agrégation par valeur".• La composition est une forme d’agrégation avec un couplage plus important.• les composants sont totalement dépendants du composite : Les cycles de vies des composants

et du composite sont liés : si le composite est détruit (ou copié), ses composants le sont aussi.• La valeur maximale de multiplicité du côté du l’objet composite ne doit pas excéder 1 puisque les

objets composants doivent tous appartenir au même objet composite.• la composition est représentée graphiquement de la même manière que l'agrégation, mais le

diamant est plein.



74

la hiérarchie des classes

• Objectif :

Permettre de gérer la complexité en ordonnant les objets au sein d’une arborescencede classes d’abstraction croissante.

• Remarque : la hiérarchie des classes est appelée également classification.



75

• la hiérarchie des classes, La généralisation

• C’est une démarche ascendante .• Consiste à prendre des classes existantes (déjà mises en évidence) et de créer de nouvelles

classes qui regroupent leurs attributs et leurs méthodes communs. • Il faut aller du plus spécifique vers le plus général.• La nouvelle classe est appelée super-classe.


Exemple de hiérarchie de classes construite par généralisation


76

• la hiérarchie des classes, Spécialisation ou héritage

• C’est démarche descendante.• Consiste à 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 (ajout ou modification).• Exemple d’extension par spécialisation


Exemple de hiérarchie de classes construite par spécialisation


20

77

• la hiérarchie des classes, Généralisation et spécialisation

• La généralisation est employée une fois que les éléments du domaine ont étéidentifiés, afin de dégager une description détachée des solutions.

• La spécialisation, quant à elle, est à la base de la programmation par extension et de la réutilisation. Les nouveaux besoins sont encapsulés dans des sous-classes qui étendent les fonctions existantes.

• Conséquence de la hiérarchie des classes

le principe propagande des caractéristiques :

– la classes enfant accède (hérite) aux caractéristiques de sa classe parente (attributs et méthodes) comme si celles-ci étaient déclarées localement.

– La classe enfant peut elle aussi jouer le rôle de la classe parent pour d’autres classes. Dans ce cas les caractéristiques de sa classe parente sont accessibles àses classes enfants.

– Plusieurs classes peuvent partager les mêmes caractéristiques d’une classe parente commune.



78

Règles à respecter:

La classification doit être équilibrée: à tous les niveaux, toutes les sous-classes d'une classe doivent

être (à peu près) de même niveau conceptuel :


Mauvaise classification

Bonne classification


79

Exercice : Application hôtelière

Un hôtel est composé d’au moins deux chambres. Chaque chambre dispose d'une salle d'eau qui peut une douche ou une salle de bain. L'hôtel héberge des personnes. Il peut employer du personnel et est dirigé par un des employés. L'hôtel a les caractéristiques suivantes : une adresse, le nombre de pièces, la catégorie. Une chambre est caractérisée par le nombre et le type de lits, le prix et le numéro. On peut calculer le chiffre d'affaire, le loyer en fonction des occupants.

On vous propose de modéliser cette application au moyen d’un diagramme de classe


Correction


80

Surcharge de méthodes

� Consiste à définir pour une même classe plusieurs méthodes portant le même nom qui diffèrent seulement par leur signature (=liste des paramètres et leur type respectif) (la signature d’une méthode est parfois définie par son nom et la liste de ses paramètres).

� En fonction des paramètres passés, le programme qui détermine dynamiquement quelle méthode invoquée.

� exemple :

� Remarque:

� L’ordre des paramètres est important : les deux méthodes suivantes sont différentes car elles ont des signatures différentes.

methode(int a, long b)methode(long b, int a)

� Le nom des paramètres n’a pas d’importance : les deux méthodes suivantes ne peuvent pas être contenues dans la même classe car elles ont une signature identique.

methode(int a, long b)methode(int c, long d)



21

81

� La méthode main() de la classe Animaux crée une nouvelle réf pour 1 objet de type Canari et lui affecte un un nouvel objet de cette classe (new). Le paramètre 3 est passé au constructeur de la classe Canari.

� Le constructeur de Canari appelle le constructeur de la classe parente (super()) en lui transmettant le paramètre reçu.

� main() appel la méthode vieillir() qui n’est pas redéfinie dans la classe Canari, mais y cependant disponible par héritage.

� main() appel la méthode crier() qui est redéfinie dans la classe canari. C’est donc cette version qui est exécuté et affiche le cri du canari.

Redéfinition de méthodes

� Consiste à définir dans une classe fille une méthode existant déjà dans une classe parente.� Permet d'adapter le comportement d'un objet selon sa position dans la hiérarchie.� Exemple :



82

Comment classer ?

� Créer des super-classes

Nécessite des facultés d'abstraction

� Réalisation de sous-classes

Nécessite une expertise métier

� Une relation d'héritage est une relation de type : « est un »

� L'héritage est transitif.

� Critère: une bonne classification est stable et extensible.



83

Typologie des classes : Les classes abstraites (1)

� Le concept

• Un classe abstraite sont une classe pour laquelle certaines méthodes sont définies sans être implémentées. De telles méthodes sont dites abstraites.

• L'implémentation des méthodes abstraites se fait dans les classes filles.

• Les classes abstraites ne peuvent être instanciées: ne donnent pas naissance à des objets.• Par convention, le nom des classes abstraites est en italique.



84

Remarque : En Java une méthode abstraite est une méthode qui n'a pas de code. A distinguer des méthodes vides qui ne font rien…abstract void p(); // Une méthode est abstraitevoid p(){} // Une méthode vide qui ne fait rien

Typologie des classes : Les classes abstraites (2)

� Exemple


Deux implémentations de la méthode

abstraite crier() de la classe Abstraite Animal


22

85

Typologie des classes : Les interfaces (2)

• Une classe dont toutes les méthodes sont abstraites.

• Deux représentations graphiques:

On dit que la classe NomClasse implémente l’interface NomInterfaceOu la classe NomClasse réalise l’interface NomInterface

Remarque : Une interface se différencie d’une classe abstraite puisque qu’elle ne peut pas posséder des attributs.



86

Typologie des classes : Les interfaces (2)

• Une interface peur fournir une vue totale ou partielle d’un ensemble de services offerts par un ou plusieurs classe.


La classe UneClasse réalise les interfaces VueA et VueB.

L’interace VueB est réalisée par la classe UneClasse et UneAutreClasse

Exemple : Diagramme de classe modélisant deux interfaces Crédit et Assurance

d’une classe Banque.


87

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 un objet peut désigner des instances de classes différentes issues d'une même arborescence.

• Exemple : soit le diagramme suivant :



88


• Ainsi : • La classe Vehicule décrit toutes les sortes de véhicules.• Tous les véhicules savent se déplacer, mais chaque véhicule à sa façon de se déplacer.• La spécification du véhicule dit que les véhicules peuvent tous se déplacer.• Les sous-classe particularise l’opération seDeplacer() selon le type du véhicule.• La classe Vehicule est connue de la classe ParcMobile.

• Sans besoin de connaître les détails propres à chaque véhicule, le centre de commandement peut ordonner aux véhicules du parc mobile de se déplacer.

• En programmation, cela revient à visiter la collection ParcMobile en utilisant un itérateur, et àenvoyer le message seDeplacer à chaque véhicule.



23

89


• Exemple de code indicatif :



90


Conclusion

• Le mécanisme qui déplace les véhicules est indépendant des véhicules.• Le nombre de chaque type de véhicule n’est pas inscrit dans l’algorithme qui se contente

d’exploiter un itérateur sur une collection.• Supposons maintenant que l’on veut rajouter un autre type de véhicule : Engin de Neige dont la

mode de déplacement est encore différent. Les particularités du nouveau véhicule sont encapsulées dans leur classe qui est ajoutée dans le modèle par dérivation de la classe Vehiculedéjà existante.

• Il n’est pas nécessaire de modifier le code qui déplace les véhicules.



91

Le polymorphisme (5) - Autre exemple :


� La classe Fruit est abstraite car on ne souhaite pas qu’il soit possible de l’instancier : on ne souhaite pas créer un fruit sans indiquer de quel type de fruit il s’agit.

� le constructeur de Pomme et Orange qui étendent Fruit admet comme argument un entier initialisant le poids.

� A noter que Pomme et Orange ne possèdent pas de champs poids.

� La méthode main de La classe Panier crée une instance de Pomme et une instance de Orange. Puis appelle la méthode peseavec l’objet orange.

� Voir exécution : Avant de créer une Pomme, le programme crée un Fruit (idem pour une Orange).

� Le constructeur de Pomme est exécuté avec 85 comme poids. Ce champs correspond à la variable d’instance poids de la classe Fruit.

� La partie la plus intéressante du programme: main appelle la méthode pese avec un objet orange alors que cette méthode prend Fruit comme argument: l’objet passé est certes de type Orange, mais également de type Fruit.


92

Structuration des classes : les packages (1)

� Par analogie les packages ont le même rôle fondamental que les répertoire dans le cas d’un système de gestion de fichier. Ils permettent :

� de structurer les diagrammes de classes complexe (gérer la complexité du diagramme de classes)

� d’avoir une meilleure lisibilité : vision modulaire du diagramme de classe.� Il facilite La réutilisabilité (importation des packages).

� Représentation graphique (sous forme d’un dossier/folder) :

� La regroupement dans un package est basé sur la base de lien sémantique: un package est donc un ensemble d’éléments qui un lien sémantique en elles.

� Un package peut contenir :

� Des classes qui lui sont propres� Des classes appartenant à d’autres packages.� D’autres packages.

� Exemple : Soit un Diagramme de Classe pour la gestion commercial. On vous demande de le revoir en utilisant des packages.



24

93

Organisation des classes : les packages (2)


Package comptabilité

Package "gestion"

Package "tiers"

Diagramme de classe


94


� Espace de nommage

� Chaque package définit un espace de nom:

� Tout élément du modèle se distingue par rapport au package qui le contient.� Deux éléments (classe ou package) du même nom appartenant à deux packages différents peuvent être utilisées dans le même package : il s’agit de deux éléments différents.



95


� Dépendance des packages

� Dépendance d’utilisation : � Lorsqu’un package utilise des éléments d’un autre package.� Toute modification dans la classe est visible dans les packages utilisateurs.

� Dépendance d’appartenance : � Lorsqu’un package est contenu dans un autre package.

� Remarque : Un package ne peut pas être instancié : il n’a pas d’existence dans le monde réel



96

Etapes pour établir un diagramme de classes (1)

UML ne propose aucune démarche pour aboutir à un diagramme de classe. Néanmoins, le respect des étapes suivantes peut aboutir à un diagramme de classe satisfaisant.

1. Identifier un premier ensemble de classes candidates.

2. Identifier les attributs.

3. Identifier les méthodes.

4. Identifier les associations.

5. Identifier les généralisations

6. S’assurer que le schéma répond à la demande

7. Itérer jusqu’à satisfaction…



25

97


1. Identifier un premier ensemble de classes candidates:

� Extraire des classes candidates à partir des différents documents (description des exigences, cas d’utilisation, etc.).

� Éliminer les redondances (la redondance doit tenir compte des classes existantes s’il s’agit d’une évolution d’un système existant)

� Donner des noms significatifs pour les nouvelles classes.

2. Identifier attributs

� Un attribut doit contenir une valeur atomique� Un attribut doit être unique.

3. Identifier les méthodes

� Chaque exigence fonctionnelle doit être attribuée à nouvelle une classe ou à une classe existante.

� Une exigence fonctionnelle peut être traduite par plusieurs méthodes de la même classe ou de classes différentes (nouvelles ou existantes).

� Si une fonctionnalité est sans classe, créer une nouvelle classe� Si une classe n’a aucune responsabilité, elle est inutile ? (pas sûr! une classe

disposant des seuls attributs peut être utile, besoin de généralisation par exemple)



98


4. Identifier les associations

� Lier les classes par des verbes claires.� Indiquer éventuellement les rôles pour les classes.� Indiquer les multiplicités.

5. Identifier les généralisations

� Approche de généralisation : identifier les attributs et les méthodes commun àplusieurs classes pour en créer des nouvelles classes.

� Approche de spécialisation : spécialiser des classes générales nouvellement identifiées ou existantes.

Remarque : le diagramme de classe qui résulte de cette méthode peut être enrichi ou même modifié en élaborant les autres diagrammes.



99

Qualité d’un diagramme de classes

� Pour modéliser un système, plusieurs modèles sont possibles

� Facteurs de qualité :

� Minimalité : pas de redondance.� Lisibilité : présenté lisiblement.� Simplicité : nombre de concepts minimum.� Cohérence : Le diagramme de classe doit rester cohérent avec les autres

diagrammes

� Une modélisation correcte et pertinente demande une grande expérience !



Documents

Modélisation Orientée Objet