Cours 3

Cours de Génie Logiciel
Introduction à la
méthode OMT
Laurent Henocque
Maître de Conférences
Ecole Supérieure d’Ingénieurs de Luminy
Université de la Méditerranée Aix-Marseille II

Cours de Génie Logiciel Laurent Henocque La méthode OMT
Cours de génie logiciel

Introduction à la méthode OMT
ESIL / ES2I
Université de la Méditerranée
par Laurent Henocque
(henocque@esil.univ-mrs.fr)
(http://www.esil.univ-mrs.fr/Staff/Prof/henocque/)
version 1.1 en date du 4 octobre 1996
Ce document peut être librement reproduit dans son intégralité pourvu que la présente mention de copyright
ainsi que celles présentes en tête et en pied de page y restent attachées. Toute autre forme de copie est interdite.
Auteur Laurent Henocque, maître de conférences.
Ce document est un cours de l’
Ecole Supérieure d’Ingénieurs de Luminy,
département Etudes Supérieures en Ingénierie Informatique,
163 Avenue de Luminy, case 925, 13288 Marseille Cedex 9
(http://www.esil.univ-mrs.fr)
1. Présentation générale de la méthode OMT
1.1. esprit de la méthode

modélisation d'objets du monde réel
utilisation de ces objets pour concevoir un système indépendamment des langages
d'implantation
Ecole Supérieure d’Ingénieurs de Luminy / département ES2I, Marseille 1

1.2. avantages
meilleure compréhension des besoins
spécification et conception plus précise
meilleure maintenabilité des systèmes réalisés
1.3. les outils

un jeu de concepts orientés objet
une notation graphique indépendante du langage de programmation, OMT, utilisable pour :
• analyser les besoins
• spécifier et concevoir
• implanter la solution
1.4. avantages
la même méthode (concepts + notations) peut être utilisée tout au long du cycle de
développement
il n'est donc pas nécessaire de traduire une formulation en une autre à chaque étape, comme le
nécessitent d'autres approches
1.5. le cycle de vie logiciel (abrégé)

définition des besoins
spécification des besoins
spécification de conception
programmation
1.6. généralité de la méthode

OMT n'est pas une méthode dédiée explicitement à la programmation orientée objet
on montre l'intérêt de la méthode pour spécifier des applications dont le langage cible n'est pas
orienté objet :
• bases de données relationnelles
• langages classiques
OMT est une méthode de pensée organisée autour d'abstractions pertinentes, qui écarte les à
priori techniques liés aux langages de programmation
OMT permet l'échange clair et non ambigu des idées

1.7. à priori fondamentaux de OMT

l'accent est mis sur l'utilisation des objets pour modéliser le monde réel plutôt que comme un
mécanisme d'un langage particulier
les relations inter objets sont élevées à un rang aussi élevé que les classes
moins d'accent est mis sur l'héritage et les méthodes
les mécanismes subtils liés à l'héritage sont laissés de côté
un accent particulier est mis sur le typage, les classes, la modélisation
la terminologie utilisée est celle qui domine quand elle existe
1.8. contenu du cours

Ce cours s'appuie pour l'essentiel sur l'ouvrage en anglais :
Object oriented Modelling and Design,
par James Rumbaugh, Michael Blaha, William Premerlan, Frederick Eddy, William Lorensen,
publié chez Prentice Hall International Editions, 1991
partie 1 : les concepts d'orientation objet
• indépendants de tout langage
• la notation graphique est présentée dans cette partie

partie 2 : méthodologie, processus de mise en oeuvre
• le processus est suivi étape par étape jusqu'à la conception détaillée

partie 3 : la programmation
• on montre la projection d'OMT sur divers langages cible, les choix techniques associés
partie 4 : études de cas
2. Introduction
la modélisation et la spécification orientée objet est méthode pour penser et décrire des
problèmes organisée autour de concepts du monde réel
la construction fondamentale y est l'objet, qui combine données et comportement
les modèles objets sont utiles pour :
• comprendre des problèmes
• communiquer avec des experts
• modéliser des organisations
• préparer de la documentation
• concevoir des programmes et des bases de données

le processus comporte les étapes suivantes :

• on réalise un modèle analytique des aspects essentiels de l'application, sans aucun a priori
d'implémentation. Ce modèle comporte les objets essentiels du domaine applicatif avec leurs
relations
• ensuite on prend des décisions de conception et on affine le modèle initial pour préciser et
optimiser l'implémentation
• les objets applicatifs ainsi décrits forment le cadre de la programmation à venir
• enfin, on traduit le modèle dans un langage de programmation quelconque

le même modèle sert tout au long du cycle de développement
2.1. Qu'est ce que l'orientation objet

on déclare orienté objet un logiciel organisé autour d'entités groupant des données arbitraires
(comme les struct C, et les record Pascal) et des procédures.
on appelle encapsulation le processus d'agrégation de ces données et procédures
d'autres caractéristiques sont habituellement requises des objets au sens propre :
• l'identité
• la classification
• le polymorphisme
• l'héritage
2.1.1. l'identité
les objets sont des entités qui peuvent être distinguées. Notamment, deux objets distincts
peuvent avoir exactement les mêmes données membres
2.2. … Qu'est ce que l'orientation objet
2.2.1. la classification
les objets ayant des attributs (données et comportements) similaires sont groupés dans une
classe.
la classe décrit toutes les caractéristiques des objets de son type
une classe qui abstrait un objet du monde réel intègre les données qui semblent pertinentes en
fonction du degré de détail voulu. (les classes vélo, ou polygone)
2.2.2. le polymorphisme
la même fonction peut avoir des effets différents sur des objets de classes distinctes

2.2.3. l'héritage
des caractéristiques partagées par différentes classes peuvent être décrites dans une classe
intermédiaire dont les autres héritent, ce qui permet de les décrire par les seules modifications
qu'elles apportent au schéma de base
l'héritage apporte un grande puissance d'expression et d'abstraction au modèle objet
2.3. Qu'est ce que le développement orienté objet?

le développement orienté objet est une nouvelle approche du logiciel basée sur des abstractions
qui existent dans le monde réel
dans ce contexte, le terme développement renvoie aux étapes amont du cycle de vie logiciel :
• analyse et spécification
• conception
• programmation
l'approche objet consiste à se concentrer sur les concepts inhérents à un domaine applicatif
plutôt que sur les conditions de mise en oeuvre dans un langage cible, qu'il soit orienté objet ou non
la complexité de réalisation d'un logiciel est plus due à la difficulté de manipuler ces concepts
qu'aux aléas de la mise en oeuvre, toujours facilement contournés
2.3.1. modélisation de concepts plutôt que de programmes

les progrès des langages de programmation ont le défaut d'encourager à centrer la réflexion sur
la programmation plus que sur la modélisation initiale
les gains les plus importants proviennent pourtant de l'effort amont d'analyse
les défauts de spécification et de conceptions sont plus difficiles à corriger que ceux
d'implémentation
concentrer sa réflexion sur les aspects techniques conduit souvent à un produit moins bon
le développement orienté objet encourage précisément l'effort d'analyse des concepts, qui une
fois terminé sert de base précise à la définition des structures de données et des traitements
le développement orienté objet est fondamentalement une nouvelle façon de penser, non pas
une technique de programmation
2.3.2. méthodologie orientée objet

OMT (Object Modelling Technique) apporte deux choses :
• une méthodologie pour le développement orienté objet
• une notation graphique pour la communication de concepts orientés objet

la méthodologie consiste en la réalisation d'un modèle du domaine applicatif, complété par des
détails d'implémentation au cours de la phase de spécification et conception du système
le processus comporte les étapes suivantes : analyse, modélisation du système, modélisation
des objets, programmation

analyse
à partir d'un énoncé du besoin, l'analyste construit (avec le demandeur) un modèle du monde
réel qui fasse apparaître ses propriétés pertinentes
le modèle issu de l'analyse est une description précise, concise, de ce que le client demande,
non de comment on peut le faire
les objets du modèle sont des objets du domaine, jamais des objets issu de l'informatique
une bonne analyse peut être comprise et critiquée par des experts du domaine qui ne sont pas
informaticiens
une bonne analyse ne comporte aucune décision d'implantation
exemple : des fenêtres sont décrites par leur fonctionnalités accessibles à l'utilisateur final
modélisation du système
l'ingénieur (system designer en anglais) prend des décisions de haut niveau sur l'architecture du
système
pendant cette phase, le système cible est organisé en sous systèmes pertinents relativement au
modèle initial et aux choix d'architecture.
l'ingénieur décide des caractéristiques à optimiser, définit une stratégie pour aborder le
problème, et fait une première évaluation des besoins en ressources humaines
exemple : le concepteur pet décider que le rafraîchissement écran soit rapide, et décider en
conséquence du protocole de communication à utiliser, et d'une stratégie de bufferisation
modélisation des objets
l'ingénieur décrit un modèle détaillé basé sur l'analyse et le modèle du système, qui respecte les
choix stratégiques
l'accent est ici porté sur les structures de données et les algorithmes nécessaires pour réaliser
chaque classe
les classes initiales restent pertinentes, mais elles sont complétées par les classes
d'implémentation, choisies en fonction de besoins concrets en performance exprimés pour le système
final
les objets initiaux et les objets informatiques sont décrits dans le même langage, bien qu'ils
figurent dans des plans conceptuels distincts
exemple : les actions de la classe fenêtre sont maintenant décrites en fonction du système
graphique sous jacent, peut être même du hardware et de l'OS
programmation
dans cette phase bien connue, les classes et relations décrites précédemment sont traduites
dans un langage de programmation, sgbd, ou hardware
la programmation devrait être une part mineure de l'ensemble du processus, les décisions
importantes ayant déjà été prises
le langage cible influence toujours la conception dans une certaine mesure, mais celle ci ne
devrait jamais dépendre de détails trop pointus d'un langage donné
la programmation doit obéir à des règles de contrôle qualité suffisantes pour :
• garantir la traçabilité des programmes para rapport à la spécification (vérification)

• aboutir à un résultat suffisamment réutilisable, maintenable, extensible, portable …
2.3.3. les trois modèles de OMT

OMT utilise trois modèles pour décrire un système : objet, dynamique et fonctionnel
QUOI : le modèle objet définit la structure statique des objets et leurs interrelations
• classes
• liens
• héritage
QUAND : le modèle dynamique décrit les interactions entre les objets
• diagrammes de transition d'états
• contrôle (conditions de déclenchement d'une opération)
• événements, messages
COMMENT : le modèle fonctionnel décrit les transformations appliquées aux données
• diagrammes de flots de données
• processus
ces trois modèles sont orthogonaux et complémentaires et interreliés
le modèle objet est fondamental et préalable aux deux autres
2.3.4. différences avec l'approche fonctionnelle

l'approche classique d'un problème par la fonctionnalité est naturelle mais conduit à des
systèmes peut robustes et peu flexibles
notamment, des systèmes ainsi conçus peuvent mal résister à des modifications des besoins
bien que moins immédiate, l'approche objet résiste mieux à des changements dans l'expression
des besoins, notamment parce que de tels changements affectent rarement le modèle du domaine,
dont les objets fondamentaux demeurent, même si ils sont légèrement modifiés
2.4. Concepts sous jacents aux objets
2.4.1. abstraction
penser le quoi avant le comment
montrer le quoi sans le comment
2.4.2. encapsulation
séparer les aspects externes et utiles au client des aspects internes utiles aux seuls mécanismes

2.4.3. combinaison de données et de comportement

en permettant le polymorphisme, cela autorise l'appel d'une fonctionnalité sans devoir chercher
quelle est la fonction qui implante l'algorithme voulu
on économise ainsi de nombreux tests
la maintenance est également plus facile, car l'ajout d'une classe ne nécessite pas de modifier les
programmes existants
2.5. … Concepts sous jacents aux objets
2.5.1. le partage
l'objet permet le partage à différents niveaux
via l'héritage :
• on partage des données et des traitements, en faisant l'économie de répétitions
• on gagne en compréhension des concepts, car on peut unifier certains traitements en un seul
traitement conceptuel : cela réduit le nombre de cas à envisager
entre programmes :
• la réusabilité n'est pas spontanée, mais elle est possible
• la programmation objet permet la réalisation de bibliothèques de composants réutilisables
2.6. Concepts sous jacents aux objets
2.6.1. l'accent porte sur la structure des donn ées, non sur celle des
traitements
on insiste sur ce qu'est un objet, avant de décrire ce qu'il fait
lorsque les besoins changent, on observe que la structure des objets est bien plus stable que les
fonctionnalités qui les intéressent
de ce point de vue, l'approche objet est plus proche de celles en usage dans le domaine des
bases de données que des approches par décomposition fonctionnelle
2.6.2. synergie
la puissance de l'approche objet vient de ce que les caractéristiques énoncées plus haut sont
disponibles ensemble
l'héritage est en fait une facilité, alors que l'encapsulation est fondamentale

2.7. Preuves de l'utilité de ces concepts en programmation

OMT a été utilisée avec succès dans de très nombreux projets industriels et scientifiques:
• développement de compilateurs
• applications graphiques
• interfaces utilisateur
• bases de données
• des langages objet avancés
• CAO
• simulation
• systèmes de contrôle de process
• documentation de programmes existants mal structurés
• communication avec des experts
• •
les langages cibles sont soit objet (Smalltalk, C++) soit classiques (C) soit relationnels
2.8. Organisation du cours

une première partie explique les concepts et présente la notation graphique OMT
• chapitre 2 : la notation OMT
• chapitre 3 et 4 : le modèle objet
• chapitre 5 : le modèle dynamique
• chapitre 6 : le modèle fonctionnel

la partie 2 montre le processus de réalisation d'un modèle objet
• chapitre 7 : un aperçu de la méthodologie
• chapitre 8 : l'analyse
• chapitre 9 : la spécification de haut niveau (modèle du système)
• chapitre 10 : la spécification détaillée et la conception
• chapitre 11 : résumé de l'approche

• chapitre 12 : comparaison de OMT avec d'autres approches populaires
2.9. … Organisation du cours

la partie 3 explore des considérations liées aux langages cibles
• chapitre 13 : un aperçu de la programmation
• chapitre 14 : conseils pour accroître la réutilisabilité et la maintenabilité
• chapitre 15 : le langage cible est objet
• chapitre 16 : le langage cible est classique (C, Ada)
• chapitre 17 : le langage cible est un langage SGBD

la partie 4 présente plusieurs études de cas
• chapitre 18 un compilateur de diagrammes objet
• chapitre 19 :un système d'animation 3D
• chapitre 20 : un outil d'aide à la conception de réseaux de distribution électrique
2.10. concepts fondamentaux du chapitre

abstraction
analyse
classification
modèle dynamique
encapsulation
modèle fonctionnel
identité
implantation
héritage
modèle objet
conception des objets
orienté objet
OMT
polymorphisme
conception de système
2.11. exercice
quels problèmes majeurs avez vous rencontré lors de vos projets passés
quel pourcentage du temps a été consacré aux différentes phases
quelle approche avez vous pour évaluer l'effort nécessaire sur un projet

2.12. exercice
rappelez vous un système que vous avez réalisé; décrivez le brièvement
quels obstacles avez vous rencontré lors de sa conception
quelle méthodologie avez vous utilisé
quelles raisons aviez vous pou la choisir, ou ne pas en choisir
êtes vous satisfaits du système tel qu'il existe
est il maintenable
est-ce difficile de lui ajouter des fonctionnalités
2.13. exercice
décrire un grand système qui s'est trouvé hors délais, hors budget, ou bien a échoué à atteindre
l'ensemble des besoins
quels facteurs sont en cause
comment l'échec aurait pu être évité
2.14. exercice
tous les objets ont une identité et sont identifiables. D'un point de vue informatique, il n'est pas
toujours évident de prévoir tout ce qui permet de les distinguer. Pour chacun de ces collections
d'objets, décrire de quelle façon on pourrait les distinguer :
• tous les humains, dans l'idée de leur envoyer du courrier
• tous les humains, pour des enquêtes criminelles
• tous les clients qui possèdent un coffre dans une banque
• tous les téléphones du monde
• tous les clients d'une compagnie de téléphone, pour la facturation
• toutes les adresses électroniques
• tous les employés d'une compagnie pour limiter les accès pour des raisons de sécurité
2.15. exercice
d'un point de vue utilisateur, critiquer un système qui possède des défauts qui vous ennuient
particulièrement
décrire le système, le défaut, pourquoi il est apparu, et comment il aurait pu être évité avec un
peu plus de réflexion au départ

2.16. exercice
étudier ce que les objets suivants ont en commun. On peut ajouter de nouvelles classes à
chaque liste
• microscope électronique, lunettes, télescope, jumelles
• tuyau, soupape, robinet, filtre, manomètre de pression
• vélo, bateau, voiture, camion, planeur, avion, moto, cheval
• clou, vis, boulon, rivet
• tente, cave, hangar, garage, étable, maison, immeuble
• racine carrée, exponentielle, sinus, cosinus
2.17. exercice
imaginer une liste des objets que l'on peut attendre à voir surgir dans les systèmes suivants :
• un programme pour réaliser un journal
• un programme pour calculer et stocker des scores de bowling
• un répondeur téléphonique
• une télécommande de vidéo
• un système de saisie de commandes à partir d'un catalogue de magasin
2.18. exercice
on donne une liste de classes, et une liste d'opérations. Pour chaque classe, sélectionner les
opérations pertinentes. Etudier le comportement de chaque fonction de chaque classes
classes:
• tableau à taille variable : collection ordonnée d'objets, indexée par un entier
• table des symboles : une table qui fait correspondre des mots clef et leur description
• ensemble : non ordonné, sans doublons

opérations
• ajoute : un objet à la fin d'une collection
• copie : copie une collection

• compte : les objets d'une collection
• détruit : supprime un élément d'une collection
• index : retrouve un élément à une position donnée
• intersecte : détermine les éléments communs à deux collections
• insère : place un objet dans une collection à une position donnée
• modifie : écrit un objet dans une collection, par dessus ce qui existe éventuellement déjà
3. La modélisation comme technique de conception

un modèle est l'abstraction d'une réalité devant servir à la comprendre, et ensuite
éventuellement à la construire
en oubliant des détails non pertinents, un modèle facilite cette compréhension
l'abstraction est une capacité humaine fondamentale nous permettant d'aborder la complexité
après une discussion générale, ce chapitre présente les trois modèles :
• le modèle objet
• le modèle dynamique
• le modèle fonctionnel
3.1. modélisation
dans tous les domaines les concepteurs utilisent des modèles :
• maquette architecturale
• maquette díavions pour les essais aérodynamiques en tunnels
• croquis crayonné avant de peindre
• storyboard de dessin animé ou de publicité
• résumé de livre
• plan d'une machine

ces modèles servent différents objectifs :
• tester une entité avant de la construire (maquette de cathédrale, d'avion, simulation

informatique)
• communiquer avec des clients (architectes)

• visualiser (artistes, dessins animés)
• réduire la complexité, la principale raison pour modéliser
3.1.1. abstraction
c'est l'examen sélectif des différents aspects d'un problème
3.2. OMT
OMT permet de modéliser un système selon trois points de vue complémentaires, chacun
capturant des aspects essentiels du système, tous requis pour une description complète
• le modèle objet est le point de vue des données
• le modèle dynamique est le point de vue du contrôle, des comportements
• le modèle fonctionnel est le point de vue des transformations apportées aux données
un logiciel combine normalement ces trois aspects : il transforme (modèle 3) des données
(modèle 1) d'une façon ordonnée dans letemps (modèle 2)
exemple : les fonctions sont attachées aux objets dans le modèle objet, mais ne sont
complètement définies que par les deux autres modèles
3.3. … OMT
chaque modèle comporte des références aux deux autres ; ces liens sont limités et explicites
chaque modèle peut être examiné d'un façon relativement indépendante des deux autres
chaque modèle évolue durant le cycle de développement :
• pendant l'analyse un modèle du domaine applicatif est réalisé sans idée d'implantation
• pendant la conception, ce modèle est complété par des éléments relatifs au domaine de la
solution
• pendant l'implantation, ces deux aspects sont réalisés

ATTENTION : le terme modèle recouvre deux réalités distinctes, généralement claires par le
contexte :
• la vue du système : modèle objet, dynamique, fonctionnel. On devrait dire

sous modèle
• une étape dans le développement : analyse, conception, implantation
3.3.1. le modèle objet

ce modèle décrit la structure des objets d'un système :
• leur identité

• leurs relations
• leurs attributs
• leurs opérations
les objets sont les éléments sur lesquels les autres modèles s'appuient
les objets sont les atomes (au sens grec : insécable) de nos modèles
a l'issue de l'analyse le modèle objet comporte des termes familiers aux personnes du domaine,
et normalement aucune référence informatique
le modèle de conception comporte lui des références informatiques bien évidement
le modèle objet est représenté par des diagrammes décrivant les différentes classes,
hiérarchisées, et comportant les attributs et les opérations utiles
3.3.2. le modèle dynamique

il décrit les aspects d'un système où interviennent :
• le temps
• les séquences
• les événements
• séquences d'événements
• les états qui définissent le contexte pour des événements
• l'organisation des événements et des états

le modèle dynamique décrit le contrôle : les séquences d'opérations qui ont lieu, sans égard
pour:
• ce qu'elles font
• ce sur quoi elles opèrent
• comment elles sont programmées
diagrammes d'état
le modèle dynamique est représenté graphiquement à l'aide de

diagrammes d'états
chaque diagramme décrit les états et séquences d'événements permises pour une classe d'objets
ces diagrammes comportent des références aux autres modèles :
• les actions correspondent aux fonctions du modèle fonctionnel
• les événements deviennent des opérations des objets du modèle objet
3.3.3. le modèle fonctionnel

ce modèle décrit les aspects d'un système concernés par des changements de valeurs :

• fonctions
• applications
• contraintes
• dépendances fonctionnelles
ce modèle décrit ce que fait un système, sans considération pour quand ou comment il le fait
le modèle fonctionnel est représenté par desdiagrammes de flots de données(DFD)
les DFD montrent :
• les dépendances entre valeurs
• le calcul de données de sortie en fonction de données en entrée et de traitements sans

considérer quand, ni si, les fonctions correspondantes sont exécutées
exemple : la feuille de calcul informatique est un pur modèle fonctionnel
les fonctions sont vues comme :
• des actions dans le modèle dynamique
• des opérations dans le modèle dynamique
3.3.4. relations entre les modèles

on a vu que chaque modèle décrit un aspect d'une réalité, avec des références aux deux autres
modèles
le modèle objet décrit les structures de données utilisées par les modèles dynamique et
fonctionnel
les opérations du modèle objet correspondent à des événements du modèle dynamique et à des
fonctions du modèle fonctionnel
le modèle dynamique décrit la structure de contrôle des objets
il montre les décisions qui dépendent de valeurs dans l'objet et qui provoquent des actions qui
changent cet état et appellent des fonctions
le modèle fonctionnel décrit les fonctions invoquées par des opérations du modèle objet et des
actions du modèle dynamique
les fonctions opèrent sur des données décrites dans le modèle objet
le modèle fonctionnel décrit aussi des contraintes sur les valeurs des objets
3.3.5. difficultés
on ne sait pas toujours décider si une information doit ou non figurer dans un modèle
c'est normal car un modèle décrit ses frontières de façon toujours brutale au début, et certaines
limites doivent être déplacées
certaines propriétés d'un système peuvent parfois être mal représentées par OMT
c'est également normal, aucun méthode ne peut être complète
dans ce cas, le recours à tout autre langage ou méthode (graphique ou non, spécifique au
domaine ou non) est souhaitable ou même nécessaire

3.4. résumé
les modèles sont des abstractions construites pour comprendre un problème avant d'implanter
une solution informatique
les abstractions sont des sous ensembles de la réalité isolés dans un but précis
OMT consiste en trois sortes de modèles :
• le modèle objet décrit la structure statique d'un système en terme d'objets et de relations
• le modèle dynamique décrit la structure de contrôle d'un système en termes d'états et

d'événements
• le modèle fonctionnel décrit la structure fonctionnelle d'un système en termes de valeurs et

de fonctions
chaque système placera une emphase particulière sur l'un des sous modèles, mais les trois sont
généralement nécessaires et sont interreliés
3.5. concepts clé du chapitre 2

abstraction
modèle dynamique
modèle fonctionnel
modélisation
modèle objet
relations entre modèles
3.6. exercice
parmi les caractéristiques d'un pneu on trouve sa taille, son composant, sa construction interne
(carcasse radiale), dessin, prix, poids, durée de vie.
quels facteurs sont importants pour celui qui :
• achète un pneu pour sa voiture
• réalise un système de simulation de performance d'un système anti-glissement pour voitures
• construit une balançoire
3.7. exercice
on utilise du fil dans différentes situations
pour chaque application, préparer une liste de caractéristiques pertinentes et expliquer
pourquoi elles sont importantes
• câble transatlantique

• fil pour faire de l'artisanat coloré
• système électrique d'un avion
• suspendre une mangeoire à oiseaux sous un arbre
• construire un piano
• réaliser le filament d'un ampoule électrique
3.8. exercice
votre baignoire est bouchée. Vous voulez la déboucher avec un fil électrique. Vous en avez de
plusieurs types (isolés ou non).
quelles caractéristiques considérez vous pour en choisir un. Expliquez :
• insensibilité au bruit électrique
• couleur de l'isolant
• résistance de l'isolant au sel
• résistance de l'isolant au feu
• coût
• rigidité
• facilité à enlever l'isolant
• poids
• disponibilité
• résistance à l'effort
• résistance à de hautes températures
• résistance à l'étirement
3.9. exercice
vous réalisez un protocole de transfert de fichiers sur des lignes téléphoniques
quels aspects sont pertinents :
• bruit électrique

• la vitesse de transmission (300 à 9600 bits par seconde par ex)
• disponibilité d'une base de données relationnelle
• disponibilité d'un bon éditeur plein écran
• bufferisation et contrôle de flot tel que le protocole Xon Xoff pour réguler un flux de
données arrivant
• nombre de pistes et secteurs sur un disque dur ou un floppy
• interprétation de caractères tels que les caractères de contrôle
• organisation des fichiers (flot de bits linéaire, ou orienté enregistrement)
• co processeur
3.10. exercice
on possède différents modèles pour spécifier et concevoir les moteurs électriques :
• un modèle électrique décrit des voltages, courants, champs, inductance et résistance
• un modèle mécanique décrit la rigidité, densité, mouvement, force, couple
• un modèle thermique décrit les transferts, production, dissipation de chaleur
• un modèle fluide décrit le flux d'air de refroidissement

quels modèles sont pertinents pour répondre aux questions suivantes :
• combien d'énergie est requise pour animer un moteur ; combien est perdue en chaleur
• combien pèse un moteur
• quelle température un moteur peut atteindre
• combien de vibrations un moteur peut engendrer
• combien de temps faudra il pour que les roulements soient usés
3.11. exercice
décider quels modèles (objet, dynamique, fonctionnel) sont pertinents pour les aspects suivants
d'un programme de jeu aux échecs
le jeu et les pièces sont visualisés sur un écran
les coups de l'humain sont décrits par un curseur et une souris
• l'interface utilisateur qui décrit les coups

• représentation d'une configuration de pièces sur le plateau de jeu
• représentation d'une séquence de coups possibles
• validation d'un coup joué par l'humain
4. Modélisation Objet
Un modèle objet capte les caractéristiques statiques d'un système en isolant :
• les objets du système : éléments insécables, ou atomes
• les relations entre les différents objets et ensembles d'objets
• les caractéristiques des attributs et des comportements des objets

ce modèle est le plus important, les autres s'appuyant sur lui
le modèle objet utilise une représentation graphique intuitive et est utile pour communiquer
entre les différents contractants d'un projet
les concepts fondamentaux présentés dans ce chapitre sont :
• la classe
• le lien
• l'association
• la généralisation
• l'héritage
4.1. objets et classes
4.1.1. objets
on définit un objet comme une entité identifiable, ayant des limites connues et précises, et une
pertinence particulière pour le problème considéré.
les objets ont deux vertus :
• ils permettent la communication
• ils servent de base pratique à la programmation

il n'existe pas pour un problème de découpage en objets meilleur que tous les autres ; c'est une
affaire de jugement

4.1.2. classes
une classe désigne un ensemble d'objets ayant en commun :
• les attributs
• le comportement
• les liens avec d'autres classes
• la signification ou sémantique
deux objets distincts d'une même classe peuvent avoir des attributs identiques
deux classes distinctes peuvent décrire les mêmes schémas d'attributs et de comportement sans
pour autant avoir des sémantiques comparables
chaque objet connaît sa classe : la classe est une propriété implicite de l'objet
c'est l'utilisation des classes qui permet d'abstraire un problème
ce qui peut être décrit au niveau de la classe n'a pas à être répété au niveau des objets instances
4.1.3. diagrammes objets

les diagrammes objets fournissent une notation graphique pour les concepts de classes et
d'objets
on dispose de deux types de diagrammes :
• les diagrammes de classes
• les diagrammes d'instances

les diagrammes de classes décrivent des ensembles d'objets, leurs caractéristiques et les liens
inter classes
Individu
les diagrammes d'instances décrivent des objets effectifs avec leurs liens
ils sont utiles pour documenter des jeux de tests (scénarios), et pour discuter des exemples
(Individu) (Individu) (Individu)
James Bond Bruce Willis Schwarzie
on utilise principalement les diagrammes de classe

les diagrammes d'instances servent à documenter des diagrammes de classe complexes
4.1.4. attributs
un attribut est une donnée maintenue par les instances d'une classe
exemple : nom,âge, poids, marque d'un véhicule
un attribut reçoit une valeur pour chaque instance
un attribut est une valeur d'un type fondamental, pas un objet

contrairement aux objets, les attributs n'ont pas d'identité

notation pour les attributs dans les classes :
Individu
nom : string
age : integer
le nom d'un attribut peut être suivi par différents descripteurs (à volonté), principalement :
• le type de la donnée
• la valeur par défaut
4.1.5. … attributs
OMT proscrit l'utilisation d'attributs d'identification
Individu
nom : string
age : integer
ID individu : ID
d'une manière générale, on ne doit pas confondre les attributs à usage interne et ceux qui
possèdent une signification dans le domaine que l'on modélise
notation des attributs pour les instances :
(Individu) (Individu) (Individu)
James Bond Bruce Willis Schwarzie
canonique 38 2024
4.1.6. opérations et méthodes

une opération est une transformation qui peut être appliquée à ou par des objets d'une classe
une opération possède comme paramètre implicite l'objet pour lequel elle est invoquée
une opération utilise et/ou modifie des attributs de l'objet
une opération peut être définie pour plusieurs classes (polymorphisme)
l'implantation effective d'une opération pour une classe s'appelle une méthode (ou encore
fonction membre)
toutes les méthodes qui implantent une opération doivent avoir :
• le même rôle symbolique
• la même signature
• le même type de valeur de retour

Individu Fichier Objet Géométrique
nom : string nom : string position

age : integer taille : integer couleur
déménage imprime bouge(delta:vecteur)
change de job édite sélectionne (p:point):bool
4.1.7. caractéristiques
caractéristique est un terme général qui désigne indifféremment un attribut ou une méthode
d'un classe
il est utile de distinguer parmi les méthodes :
• celles qui modifient leur objet
• celles qui laissent leur objet inchangé (accesseurs, requêtes)

quand elles ne prennent pas d'argument, celles du deuxième type peuvent être vues comme des
attributs dérivés
un bon modèle choisit une politique parmi :
• soit clairement distinguer les attributs de base et les attributs dérivés
• soit unifier leur notation de façon à rendre le modèle insensible à des changements ultérieurs
Rumbaugh conseille de les distinguer
4.1.8. résumé de la notation pour les classes
Nom de la Classe
attribut1 : type1 = valeur par défaut 1

attribut i : type i = valeur par défaut i
opération 1 (args 1) : type retour 1
opération j (args j) : type retour j
les attributs et opérations peuvent être ou non tous mentionnés suivant le niveau de détail visé

4.2. liens et associations
4.2.1. concepts généraux
les liens
les liens et associations permettent de définir des relations entre objets

un lien est une connexion physique entre instances d'objets
exemple : James Bondtravaille pour l'intelligence service
mathématiquement, un lien est un n-uple : une liste ordonnée d'objets
un lien est une instance d'association
les associations
une association est un groupe de liens avec une structure commune et une sémantique
identique
exemple : un agent secrettravaille pour un service secret
mathématiquement, une association est une relation
une association est bi directionnelle
la direction induite par le nom est dite direction
normale
l'autre direction est dite directioninverse
l'association inverse possède parfois un nom, mais ce n'est pas nécessaire
exemple : un service secretemploie un agent secret
liens et associations vs pointeurs
les liens sont souvent implantés via des pointeurs

ils ne peuvent être modélisés ainsi
les pointeurs masquent le caractère bidirectionnel des liens
c'est encore plus criant quand l'association est plus que binaire
les associations ne sont pas seulement des notions utiles en bases de données : toutes les
connexions entre classes devraient être modélisées par des associations
utilisation des directions
un lien est fait pour être parcouru

lorsque toutes les possibilités de parcours ne sont pas utiles, l'implantation du lien peut se faire
plus simplement
notation pour une association binaire 1-1
Ville est capitale de Pays

nom nom
le même diagramme est obtenu pour des instances et non des classes
le nom d'association est en italique
il peut être omis si c'est évident par le contexte (rare)

il est préférable de permettre une lecture gauche droite si possible
notation pour une association plus complexe

diagramme de classes
Ligne intersecte en Point

nom 2+ nom
le cas concret
L2
L3 P1 P2
L5 L4
L1
diagramme d'instances
(Ligne)
L1
(Ligne)
L2 (Point)
(Ligne) P1
L3 (Point)
(Ligne) P2
L4
(Ligne)
L5
associations ternaires et plus
une association peut être d'arité quelconque

en pratique on dépasse rarement trois
la très grande majorité des associations est binaire, ou binaire qualifiée
les associations d'arité dépassant trois sont difficiles à dessiner, à penser, à expliquer
exemple : tout programmeur utilise un langage de programmation sur un projet

Projet Langage
Personne
cette relation est atomique
elle ne peut pas être réduite à des associations binaires sans perdre d'informations
le nom (optionnel) d'une telle association est écrit à côté du losange
diagramme d'instances pour un lien ternaire :
(Projet) (Langage)
réseau C++
(Personne)
Steve
(Projet) (Langage)
système Perl
4.2.2. multiplicité
la multiplicité désigne le nombre d'instances d'une classe qui peuvent être liées à une instance
d'une classe associée
la multiplicité est souvent d'ordre "1", ou d'ordre "plusieurs", mais en fait toutes les situations
sont possibles
un rond noir signifie "zéro ou plus"
un rond blanc signifie "zéro ou un"
la multiplicité peut toujours être précisée : 2+ à coté d'un rond noir signifie "2 ou plus"
la multiplicité est écrite du côté de la classe qui porte la multiplicité, c'est à dire dont les
instances sont comptées
exemple : il faut au moins deux lignes pour un point d'intersection
exemple : une station de travail affiche zéro ou une fenêtre "console"
Station Fenêtre
console
choix des multiplicités
la détermination précise des multiplicités se fait en général lorsque le modèle est assez avancé
et bien compris
le choix des multiplicités dépend souvent de conditions importantes sur le domaine
exemple : est ce que la relation "travaille pour" est 1-1?
la distinction la plus importante est entre 1 et plusieurs

sous estimer la multiplicité peut conduire à une mauvaise flexibilité de l'application

exemple : une personne a t'elle un ou plusieurs numéro de téléphone?
sur estimer la multiplicité conduit à des coûts inutiles
note : la notation utilisant les ronds blancs et noirs est ambiguë pour les associations n-aires
4.2.3. l'importance des associations

les associations sont utilisées dans le monde des bases de données
peu de langages les offrent de façon explicite
pendant la modélisation, on doit refuser de représenter une relation via un pointeur ou une
référence noyé(e) dans les attributs d'un classe
on doit au contraire utiliser une association, qui a le mérite de signaler que l'association dépend
de deux ou plus classes, et n'est pas "contrôlée" par une seule
certains auteurs clament que les associations violent le principe d'encapsulation
Rumbaugh dit que les associations constituent une information qui est fondamentalement
extérieure aux classes (je suis d'accord avec ce point de vue)
4.3. notions avancées de liens et associations
4.3.1. attributs de liens

un attribut de lien est une propriété des liens d'une association
exemple : "droit d'accès" est une propriété du lien "accessible par" entre un utilisateur et un
fichier
accessible par
Fichier Utilisateur
droit d'accès
/etc/termcap (read) Steven

/etc/termcap (read write) PMM
/usr/henocque/.login (read write) Henocque
un tel attribut est sans conteste une propriété du lien, qui ne peut être attachée à aucun des
deux objets liés
4.3.2. … attributs de liens

exemple : des personnes travaillent pour exactement une société ; l'une d'elle est le patron qui
note ses employés

Personne Société
travaille pour
patron nom nom
adresse adresse
n° SSociale n° Siret
salaire
fonction
employé
dirige
évaluation
modéliser le salaire et la fonction par un attribut de lien est plus flexible que par un attribut de
personne
le modèle ci dessus survit même si l'on décide qu'un salarié peut travailler pour plusieurs
entreprises
ce choix n'existe que dans le cas d'associations n-1
attributs d'associations ternaires
Equipe de
Base Ball
Lanceur Année
matches gagnés
matches perdus
(un lanceur peut jouer pour plusieurs équipes la même année)
4.3.3. modéliser une association comme une classe

il est parfois utile de modéliser une association comme une classe :
• quand un lien peut participer à des associations avec d'autres classes
• quand un lien peut comporter des opérations

dans ce cas, chaque lien devient une instance de la classe

autorisé sur
Utilisateur Station
Autorisation
priorité
privilèges
session
home directory
Répertoire
4.3.4. noms de rôles

un rôle est une extrémité d'association
une association binaire a deux rôles, et chacun peut recevoir un nom
un rôle permet de voir une association comme un moyen de naviguer d'un objet à un ensemble
d'objets liés
le nom de rôle est le nom que l'on donnerait au champ de la classe opposée qui pourrait
implanter le lien
un nom de rôle est un attribut dérivé de la classe opposée dont la valeur est un ensemble
d'objets liés (et donc accessibles)
parfois le nom de la classe est suffisant et permet l'omission des noms de rôles, notamment
lorsque deux classes ne participent ensemble qu'à une seule association
travaille pour
Individu Société
employé employeur
4.3.5. … noms de rôles

les noms de rôles sont nécessaires pour des associations liant des objet d'une même classe
les noms de rôles au bout des associations attachées à une classe doivent être uniques
ils ne peuvent non plus être en conflit avec des noms d'attributs
propriétaire
conteneur
User Répertoire
utilisateur authorisé
contenu
une association n-aire a un nom de rôle à chaque extrémité
toutefois, cela ne représente plus une possibilité de parcours simple comme auparavant

4.3.6. ordre
habituellement, les objets du côté "plusieurs" ne sont pas ordonnés, et sont vus comme
appartenant à un ensemble
dans certaines situations, l'ordre est souhaité
l'ordre est un cas particulier de contrainte
{ordered}
Fenêtre Ecran
visible sur
4.3.7. qualification
une association qualifiée fait intervenir deux classes et un qualifieur
le qualifieur est un attribut particulier qui permet de réduire la multiplicité d'une association
les associations 1-n et m-n peuvent être qualifiées
le qualifieur distingue parmi les objets d'un côté "n"
une association qualifiée peut être vue comme une forme d'association ternaire
exemple : un répertoire contient de nombreux fichiers, distingués par leur nom
Répertoire nom de fichier Fichier
la qualification ne réduit pas toujours à l'unité
souvent, la qualification réduit à l'unité, c'est à dire que le qualifieur identifie exactement un
objet
ce n'est pas toujours le cas
Société fonction Individu

une même personne peut être directeur de plusieurs sociétés
une société peut avoir plusieurs directeurs
en connaissant la fonction dans la société, on réduit cependant le nombre des individus éligibles
pour le lien
le qualifieur peut parfois être vu comme un attribut
on peut parfois modéliser un qualifieur par un attribut

exemple : les sociétés sont identifiées sur chaque place boursière par une abréviation télex,
toujours la même

Bourse Bourse
abbréviation
Société Société
abbréviation
Non Qualifiée Qualifiée

la version qualifiée est préférable, car elle résisterait au fait qu'une même société possède des
abréviations télex différentes sur des places boursières distinctes
4.3.8. agrégation
l'agrégation est la relation de la partie au tout, des composants à l'assemblage
exemples : les parties d'une automobile, les parties de la déclaration d'une fonction C
sa propriété significative est la transitivité
remarquable également est son antisymétrie
enfin, certaines propriétés de structure se propagent aux composants
l'utilisation de l'agrégation n'est pas toujours évidente ; dans le doute il faut utiliser une
association habituelle
une relation d'agrégation lie une classe assemblage à une classe composant
un assemblage avec plusieurs composants correspond à plusieurs relations d'agrégation
on peut décrire la multiplicité des composants dans l'assemblage
Document Paragraphe Phrase

l'existence d'un composant peut dépendre de l'existence du conteneur (cas précédent)
dans d'autres cas les composants peuvent avoir une existence indépendante (pièces d'une radio)
…agrégation
une agrégation peut comporter plusieurs niveaux

on attend d'un diagramme d'agrégation d'expliciter les différents niveaux de structure d'un
assemblage si possible

PC
1+
Moniteur Boitier Système Souris Clavier
Chassis CPU RAM Ventilateur
4.4. généralisation et héritage
4.4.1. concepts généraux

héritage et généralisation sont utiles pour partager des concepts entre plusieurs classes tout en
préservant les différences
la généralisation est la relation entre une classe et une ou plusieurs versions raffinées de la
même classes
la classe précisée est lasuperclasse
les autres sont dessous classes
exemples : équipement est une super classe de toit ouvrant et de rétroviseur
les attributs et opérations décrits pour la super classe sont
hérités par les sous classes
l'héritage est le mécanisme par lequel des caractéristiques décrites pour une super classe sont
rendues disponibles dans une sous classe
la relation de généralisation est souvent appelée relation "est un", ou bien "est une sorte de"
(en anglais "is a"
sa relation réciproque est appeléespécialisation
propriétés
héritage et généralisation sont transitives

on utilise les termes de (classe) ancêtre et de (classe) descendante pour dénoter la fermeture
transitive de la généralisation
une instance de sous classe est aussi instance de toutes ses classes ancêtre
un instance d'une sous classe comporte des données pour tous les champs de ses ancêtres
toute opération ancêtre (non privée) peut être appliquée à une classe

notation graphique
Equipement
nom
poids
coût type équipement
Pompe Radiateur Réservoir

pression surface ••• volume
débit pression
type pompe
Pompe centrifuge Pompe diaphragme Pompe a pistons

diamètre type membranne •••
num cylindres
nombre de pales
type réservoir
Rvr pressurisé Rvr sphérique Rvr toit flottant

••• diamètre diamètre diamètre
hauteur hauteur
discriminateurs
les mentions "type de" sont des discriminateurs

un discriminateur est un attribut de type énuméré qui indique quelle propriété est abstraite par
la relation de généralisation
seulement une propriété peut être généralisée par niveau
exemple : la classe véhicule peut être discriminée de deux façons :
• par le mode de propulsion (humaine, à cheval, à charbon, diesel …)
• par le milieu (eau, air, terre, espace …)

le discriminateur n'est qu'un nom donné à la généralisation
les valeurs de discriminateurs sont dans une correspondance bijective (un-un) avec les sous
classes
les discriminateurs ne sont pas forcément implantés dans les programmes
les discriminateurs ne sont pas impératifs dans les diagrammes objet

héritage de méthodes
Figure
couleur
centre
épaisseur trait
move
select
rotate
display dimensionalité
dimension 0 dimension 1 dimension 2

orientation orientation
remplissage
resize
resize fill
Point Ligne Arc Polygone Cercle

points rayon num de côtés diamètre
angle arc arêtes display
angle départ rotate
display display display display
4.4.2. utilisation de la généralisation

la généralisation permet de capturer ce qui est commun et ce qui diffère entre classes
en général, on ne dépasse pas dix niveaux d'héritage dans un projet
l'héritage d'opérations permet de réutiliser des programmes
les langages objet offrent de bonnes possibilités d'héritage
les bases de données pas du tout (sauf nouveauté des BDOO et du relationnel étendu)
après la modélisation d'un système, le concepteur analyse les classes produites, et tente de
définir des entités abstraites groupant des caractéristiques : permet de réutiliser les programmes
associés
l'importance première de l'héritage vient cependant de la simplification conceptuelle
4.4.3. surdéfinition (surcharge) de caractéristiques

une sous classe peut surdéfinir une caractéristique (attribut ou opération) en en définissant une
nouvelle de même nom
il peut y avoir plusieurs raisons pour vouloir cela :

• pour définir un comportement qui dépend de la sous classe
• pour une meilleure performance
• pour durcir la spécification d'une caractéristique

on peut surcharger les valeurs par défaut d'attributs, les méthodes des opérations
on ne doit jamais modifier la signature d'une méthode
on ne doit jamais modifier la sémantique d'une opération
restreindre le type d'un argument de méthode ou d'un attribut à une sous classe du type original
est une forme de restriction qui doit être utilisée avec précautions (vue en détail plus loin)
on peut souvent profiter des caractéristiques d'une sous classe pour améliorer les performances
d'une opération (rotate pour la classe cercle)
on doit s'en tenir strictement à ce que la relation de généralisation représente "une sorte de" et
ne jamais hériter d'un classe sous prétexte qu'elle "ressemble" à ce qu'on souhaite
4.5. structuration du modèle
4.5.1. le module
le module est une unité logique qui groupe des classes, associations et généralisations
c'est une vue du problème (exemple : électricité, plomberie …)
les limites d'un module sont parfois subjectives
un modèle objet consiste en un ou plusieurs modules
les noms de classes et d'associations doivent être uniques dans un module
il est préférable d'avoir des conventions de nommage uniformes et cohérentes entre les
modules
le nom du module est habituellement mentionné en haut de chaque feuille
mentionner la même classe dans plusieurs modules est le mécanisme par lequel on lie les
modules entre eux
raisonnablement, les liens externes entre modules doivent être bien moins nombreux que les
liens internes
4.5.2. la feuille
la feuille permet de découpe le modèle objet complet en une série de pages
chaque feuille consiste en une unique page
un module consiste de une ou plusieurs pages
jamais plusieurs modules sur une page
chaque feuille possède un titre et un numéro
chaque association ou généralisation apparaît sur une seule feuille
une classe peut apparaître sur plusieurs feuilles, créant de ce fait le lien entre les feuilles
on peut (non obligatoire) mentionner dans un cercle auprès d'une classe les nom et/ou numéros
des feuilles qui complètent la description de la classe

4.6. un exemple de modèle objet : feuille 1
Window
x1; y1;
x2; y2;
display
undisplay
raise
lower
Scrolling Canvas Panel

Window cx1;cy1
x-offset cx2;cy2
y-offset
scroll add elem
del elem
Text Scrolling
Window Canvas
string
insert
delete

window Shape
Canvas elements color
line width
Line Closed shape

x1 ; y1 ; x2 ; y2; fill color
draw fill pattern
Ellipse Polygon Point

vertices
x;y;a;b
draw {ordered}
x;y;
draw
Panel
item name Event
notify event action
Panel keyboa
Item rd
event
x
y
label
Button Choice Text item

string item max length
depressed {member} current string
current choices
Choice
entry
string
value

4.8.1. défauts du modèle

type rectangle, pour fenêtres et canvas
line cas particulier de polyline, auquel cas polyline et polygone héritent d'un type qui définit
une liste ordonnée de points
il manque beaucoup d'attributs et d'opérations
il manque des associations entre fenêtres (recouvrement par ex)
etc. ...
il est important de remarquer que l'on peut critiquer les détails justement parce que le modèle
dit quelque chose de précis
4.9. trucs pratiques

ne pas se jeter sur le modèle : réfléchir en premier
garder le modèle simple
choisir les noms avec attention
ne pas mettre de pointeurs dans les attributs
éviter les associations ternaires ou plus
ne pas préciser les multiplicités trop tôt
ne pas placer les attributs de liens dans une classe
utiliser des associations qualifiées autant que possible
éviter les généralisations trop profondes
bien vérifier le bien fondé des associations 1-1
se préparer à des moutures successives du modèle
faire lire son travail par d'autres
toujours documenter son modèle : cela guide le lecteur sur la compréhension des choix faits et
explique les noms utilisés
ne pas nécessairement utiliser toutes les constructions d'OMT
4.10. résumé du chapitre

les modèles objet décrivent la structure statique d'objets, de classes et leurs relations
liens et associations réalisent des relations entre classes
un lien connecte deux ou plusieurs objets
pour modéliser les associations, on dispose de plus d'attributs de liens, de qualifieurs, de
multiplicité, de noms de rôles
l'agrégation est une forme particulière d'association
généralisation et héritage sont des outils fondamentaux pour l'abstraction de concepts
un modèle objet est organisé en modules et en feuilles
dès lors qu'il existe, un modèle peut être critiqué, complété, comparé au monde réel qu'il
représente

4.11. concepts clef

agrégation association
attribut attribut de lien
caractéristique classe
discriminateur feuille
généralisation héritage
identité instance
lien méthode
multiplicité objet
opération ordre
qualification rôle
signature spécialisation
surcharge
4.12. exercice préparer un diagramme de classes pour le diagramme d'instances

suivant :
(Point) a a (Point)
10 10
-10 10
(Polygone)
(Point) (Point)
-10 -10
a a
-10 10
expliquer les choix de multiplicité
chaque point possède une coordonnée x et y. Quel est le nombre minimal de points pour
construire un polygone
cela fait il une différence qu'un point soit ou non partagé par plusieurs polygones
comment exprimer le fait que des points soient en séquence
4.13. exercice sur la base de l'exercice précédent, préparer un diagramme d'instances

pour deux triangles ayant une arête commune dans les cas suivants :
• un point figure dans exactement un polygone
• un point peut figurer dans deux ou plus polygones

4.14. exercice préparer un diagramme d'instances pour l'expression (X+Y/2)/(X/3+Y)

selon le diagramme de classes suivant :
premier opérande
Terme
second opérande
Expression Variable Constante

opérateur nom valeur
binaire
modifier ce diagramme de classes de sorte que les termes ne soient plus partagés, et afin de
prendre en compte le "-" unaire
4.15. exercice préparer un diagramme de classes pour le înerd des philosophes

• il y a cinq philosophes et cinq fourchettes autour d'une table
• chaque philosophe peut prendre les 2 fourchettes qu'il a à ses côtés
• chaque fourchette est partagée par deux philosophes
• chaque fourchette est soit sur la table soit utilisée par un philosophe
• un philosophe doit avoir deux fourchettes pour manger
4.16. exercice préparer un modèle objet pour définir des graphes non directionnels
un tel graphe est constitué d'un ensemble de noeuds et d'un ensemble d'arêtes
les arêtes connectent des paires de noeuds
le modèle ne doit s'intéresser qu'à la structure logique d'un tel graphe, et non aux détails de
représentation (positions des noeuds, longueur des arêtes par ex)
4.17. exercice préparer un modèle pour des graphes directionnels cette fois ci
modéliser la direction par un qualifieur de sorte que l'on puisse distinguer le noeud qui est
connecté à la tête ou à la queue de chaque arête

4.18. exercice améliorer le modèle esquissé ci dessous
Individu Voiture Crédit auto Société Banque

nom ID propriétaire ID véhicule nom nom
age ID véhicule type client ID société ID banque
ID employeur 1 type propriétaire ID client
ID employeur 2 modèle n° compte
ID employeur 3 année ID banque
ID individu taux
adresse solde courant
5. Modélisation Objet Avancée
5.1. l’agrégation
l’agrégation est la relation de la partie au tout
un objet est un agrégat de ses composants
des composants peuvent ou non avoir une existence autonome
certaines propriétés des objets se propagent aux composants
l’agrégation récursive est courante
5.1.1. agrégation et association comparées

l’agrégation est une forme particulière d’association
critères de distinction : relation de la partie au tout, propagation, antisymétrie naturelle de la
relation?
Société Division Département
Individu
5.1.2. agrégation et généralisation comparées

l’agrégation lie des instances, alors que la généralisation décrit des classes
on parle parfois d’héritage structurel pour qualifier la propagation de valeurs et d’opérations
dans les agrégats

Lampe
Lampe fluo Incandesc. Pied Cable
baillonnette
Transfo Starter Monture
5.1.3. agrégats fixes, variables et récursifs

la lampe ci dessus est un agrégat fixe
un agrégat variable a un nombre fini et déterminé de niveaux, mais le nombre des éléments
peut varier
un agrégat récursif est défini par un objet du même type; le nombre de niveaux potentiels est
illimité
Programme
Block
Instruction composée Instruction simple
5.1.4. propagation d’opérations

les agrégats permettent la propagation d’opérations : déplacement d’un paragraphe dans un
texte, copie de ce paragraphe,
les agrégats permettent la propagation de valeurs : la couleur d’un automobile aux parties de
sa carrosserie
5.2. les classes abstraites

une classe abstraite ne possède pas d’instances, mais décrit des attributs et opérations
communs à plusieurs sous classes
une classe concrète peut avoir des sous classes abstraites

Objet
la classe dans un éditeur graphique est typiquement abstraite
toutes les opérations non définies, mais simplement nommées dans une classe abstraite doivent
recevoir une implémentation dans les sous classes concrètes
une classe abstraite décrit (une partie de) l’interface de programmation de ses sous classes
concrètes sans être capable de produire une implantation effective de la plupart des opérations
5.3. la généralisation vue comme extension et restriction

l’héritage donne a toute instance d’une classe le type de ses super classes
cela interdit qu’une classe héritée altère ou supprime un attribut ou une opération
l’interface d’appel d’une opération ne peut pas non plus changer
on appelle extension l’ajout de caractéristiques nouvelles par une sous classe
on appelle restriction le fait qu’une sous classe contraigne ses attributs
exemple : le cercle est une ellipse particulière
une sous classe doit interdire des modifications de ses attributs qui la feraient sortir de “son
type” : certaines opérations accessibles à la super classe doivent être interdites (étirement non
contrôlé d’un cercle)
des attributs ayant subi une restriction doivent pouvoir être renommés (axe -> diamètre)
5.3.1. surcharge d’opérations

l’héritage doit être vu conceptuellement comme implantant la relation “est un”. Malgré tout, il
permet de partager des implantations et cela engendre des conflits ou ambiguïtés. On distingue :
• la surcharge pour extension : l’opération est la même que dans la classe d’origine, mais elle
affecte des données membres nouvelles
• la surcharge pour restriction : la nouvelle opération restreint l’interface, notamment en donnant
des types plus précis à ses arguments
• la surcharge pour optimisation
• la surcharge de confort (on hérite d’une classe qui ressemble) : A EVITER
OMT propose de suivre les règles suivantes :
• tous les accesseurs sont hérités par toutes les sous classes
• tous les modifieurs sont hérités par toutes les extensions
• les modifieurs qui changent les attributs “contraints” d’une restriction sont contrôlés ou interdits
• une méthode ne peut changer de sémantique lors d’une surcharge
• toutes les surcharges d’une opération possèdent la même signature
• les opérations héritées peuvent être redéfinies pour gérer les extensions de la classe
5.4. héritage multiple

l’héritage multiple n’est pas une coquetterie, mais d’utilité véritable
5.4.1. définition
une classe peut incorporer des mécanismes provenant de plusieurs super classes

les conflits entre symboles hérités doivent être levés par le programme
Véhicule
V. Terrestre V. Aquat
Auto Amphibie Bateau

la classe Amphibie hérite de façon multiple de véhicule terrestre et aquatique
ce deux classes héritent de façon virtuelle de Véhicule, ce qui est figuré par un triangle noir :
cela signifie que si les caractéristiques sont héritées plusieurs fois, elles ne seront pas dupliquées
OMT décourage fortement, voire “interdit” l’héritage multiple non virtuel d’une même classe
de base
5.4.2. héritage multiple “accidentel”

une instance d’une sous classe est automatiquement instance de toutes ses super classes. Il est
ainsi possible de dire qu’un assistant d’université est à la fois enseignant et étudiant
mais comment permettre qu’un professeur attitré, non plus un assistant, soit aussi étudiant
dans une (autre) université
l’approche habituelle est de traiter une personne comme un agrégat de ses multiples statuts
universitaires possibles :
Individu Universitaire
Enseignant Etudiant
Assistant
5.4.3. que faire en son absence?

si on ne dispose pas d’héritage multiple, le plus simple est de le simuler en héritant de la classe
la plus importante, et en construisant des instances des autres classes dites classes déléguées

5.5. métadata
les métadonnées sont des données qui en décrivent d’autres : cf. la définition d’une classe
les modèles sont des métadonnées
les bases de données en comportent toujours
5.5.1. motifs
un patron décrit des instances du patron, comme une classe décrit ses instances
OMT utilise des flèches pointillées pour relier les instances à leur patron
Jim
Personne
nom
age
poids
Jack
5.6. … métadata
une partie d’un modèle du monde réel peut également décrire des méta données. OMT permet
de les représenter et de lier métadonnées et données
Modèle Voiture
nom numéro de série
année color
prix options
Constructeur Individu
5.6.1. descripteurs de classe

les classes peuvent aussi être considérées comme des objets :
• gérer des informations propres
• avoir des opérations propres
l’opération de construction d’une instance d’un type est typiquement une opération de la classe

Objet
nom
$liste des objets
$nom par défaut
$new-Objet()
$affiche-liste()
5.7. clefs minimales - candidate keys

une clef minimale (“candidate key“ en anglais) est un ensemble minimal d’attributs qui identifie
uniquement un objet ou un lien
une classe ou une association peut avoir plusieurs clefs minimales
l’id d’un objet est toujours une clef minimale
Individu
possède actions
Société
{candidate key : (Individu), (Société)}

les clefs minimales sont utiles pour expliciter les associations ternaires et plus : savoir si on doit
disposer de deux ou trois objets pour identifier le lien est une information très importante
{candidate key : (Etudiant), (Université)}
Etudiant Université
Professeur
5.8. … clefs minimales - candidate keys

on détermine les clefs minimales en étudiant des jeux d’instances

{candidate key : (Projet),(Individu),(Langage)}
Projet Langage
Individu
pour comprendre l’intérêt de cette notion, il faut se rappeler que l’on peut associer des
informations aux liens : la clef minimale permet de dire quelles sont les éléments qu’il faut fournir
pour retrouver ces informations “à coup sûr”.
5.9. contraintes
5.9.1. définition
une contrainte est une condition logique qui s’applique à des entités du modèle : objets,
classes, attributs,liens, associations
une contrainte limite les valeurs que peuvent prendre certains attributs, soit à tout moment
(contrainte universelle), soit au cours du temps (contrainte dynamique)
les contraintes sont exprimées de façon déclarative de préférence
un bon modèle décrit de nombreuses contraintes
patron
Travailleur Process
salaire priorité
{salaire < patron.salaire} {priorité décroissante ou stationnaire}
5.9.2. contraintes sur liens

la multiplicité contraint une association
la notation {ordered} est aussi une contrainte sur une association
5.9.3. contraintes générales

les contraintes générales lient plusieurs classes ou associations. Ce lien est mentionné par des
flèches pointillées assorties d’un énoncé commenté de la contrainte
elles doivent être exprimées sous forme naturelle ou en équations (meilleur)
lorsque trop de classes sont liées par la contrainte, il vaut mieux la décrire à part que de ruiner
le modèle
membre
Personne Association
{sous ensemble}
président

5.9.4. objets, liens et attributs dérivés

un objet dérivé est fonction d’un ou plusieurs objets, peut être dérivés eux mêmes
un tel objet est déterminé totalement par ses “arguments”
la notation pour ce type nouveau est une ligne diagonale
voici un exemple d’attribut dérivé :
Individu Date du jour
date de naissance
/age
{age = date du jour - date de naissance}
5.9.5. … objets, liens et attributs dérivés

un exemple de classe dérivée
Tout Ensemble Partie
Pos. relative Pos. relative
position position
Pos. absolue
position
{position = tout-ensemble.pos + ensemble-partie.pos}
les modèles concrets comportent toujours de nombreuses entités dérivées
5.9.6. homomorphismes
un homomorphisme décrit une application entre deux associations
se projette en
Entrée catalogue Pièce
référence décrit n° de série
item1 contient item2 implique item1.référencecontient item2.référence

le cas général est décrit ainsi :

r
MA A
t u
{u(a,b) -> t(a.r,b.s)}
MB B
s
5.10. résumé du chapitre - mots clef

agrégation
classe abstraite
classe concrète
clef minimale
contrainte
entité dérivée
généralisation
héritage
héritage multiple
homomorphisme
instantiation
méta données
propagation
signature
surcharge
5.11. exercices
5.11.1. exercice
décrire la structure d’une automobile
5.11.2. exercice
préparer un diagramme objet pour un éditeur graphique qui permette de grouper les objets
un document est constitué de plusieurs feuilles
les objets sont du texte, des formes et des groupes
6. Modélisation dynamique

les aspects d’un système qui ont à voir avec le temps et les changements s’appellent le modèle
dynamique
ce chapitre décrit le flot de contrôle dans un modèle OMT
les notions fondamentales sont les états (accessibles d’un système) et les événements qui
permettent de produire des changements d’état
6.1. événements et états

les attributs d’un objet à un moment donné décrivent son état
la réponse à un événement dépend de l’état, et en retour est susceptible de modifier cet état, ou
même l’état d’autres objets
6.1.1. événements
un événement se produit à un instant donné dans le temps, et ne possède pas de durée
les événements sont séquencés dans le temps
deux événements sans lie de causalité sont dits concurrents, ou parallèles (sans qu’ils doivent
nécessairement se produire simultanément)
chaque événement est unique, mais on décrit des classes d’événements, munies d’une
organisation hiérarchique
certains événements sont de simples signaux, mais d’autres portent des informations -
transmise d’un objet à un autre-
les informations associées à un événement sont des attributs de sa classe
exemples :
• décollage d’avion : avion, n° de vol, vile
• appui sur la souris (n° de bouton, coordonnées)
• on décroche le téléphone
les événements groupent événements normaux et conditions d’erreur
6.1.2. scénarios et traces

un scénario est une séquence réelle d’événements qui se produit pendant une exécution du
système
les scénarios sont comparables aux instances dans leur relation aux classes d’objets : des
instances`
exemple : les événements successifs lors d’une communication téléphonique
l’étape qui suit le listing d’un scénario est l’identification des objets impliqués
une trace associe les événements et les objets source et destination des informations associées
dans le cas du téléphone on aurait :

appelant ligne appelé

l’appelant lève le combiné
tonalité
compose(1)
fin de tonalité
compose(i) //répété
tonalité sonnerie sonnerie
décroche
fin de tonalité sonnerie fin de sonnerie
connexion connexion
raccroche
fin de connexion fin de connexion
tonalité fin de connexion
raccroche
6.1.3. états
un état est une abstraction des valeurs d’attributs et de liens d’un objet et décrit un ensemble
de valeurs
un état est stable entre deux événements reçus par un objet et possède une durée
l’ensemble des valeurs d’un attribut correspondant à un état est souvent décrit en intention par
une condition logique ou une contrainte (exemple des températures)
la description des événements et états dépend du niveau d’abstraction auquel on se place : un
seul événement dans un modèle peut être décomposé en de nombreux événements et états dans un
modèle plus précis (exemple du vol Paris New York
la description des états ignore les attributs non pertinents
Etat : l'alarme sonne

Description : l'alarme du réveil sonne pour indiquer que l'heure prévue est
atteinte
Séquence qui produit l'état :
set alarm(heure)
toute séquence ne comportant aucun "clear alarm"
heure courante = heure prévue
Condition qui caractérise l'état
alarm = on,
0² heure courante - heure prévue<30 s
aucun bouton n'a été poussé depuis le début de la sonnerie
Evénements acceptés dans l'état:
heure = heure prévue + 30 arrêt sonnerie alarm set
bouton poussé (sauf alarm on/off) arrêt sonnerie alarm set
alarm on/off poussé arrêt sonnerie alarm off
6.1.4. diagrammes d’états

un diagramme d'état associe des événements et des états
quand un événement est reçu, l'état suivant dépend de l'état courant et de l'événement
un changement d'état du fait d'un événement est appelé une transition
un diagramme d'état est un graphe dont les noeuds sont des états et les arcs des transitions
marquées par leur événement associé
quand les conditions d'une transition sont réunies, on dit que celle ci "déclenche"
un diagramme d'états décrit le comportement d'une seule classe d'objets
chaque instance obéit au même diagramme, mais se trouve dans un état "personnel"
un diagramme d'états peut représenter une boucle, ou bien un traitement unique
les diagrammes de traitement unique possèdent un état initial et un état final
de tels diagrammes peuvent être vus comme des sous programmes pour un diagramme
complet

raccroche repos raccroche
décroche
délai
tonalité occupé
numéro (n) délai
composition message
invalide
message numéro valide
traffic
connexion
occupé appelé occupé routage effectué
sonnerie
appelé décroche
connecté
appelant raccroche
déconnecté
un diagramme de traitement unique :

début
mat noir gagne
à blanc
jeu impossible
blanc joue
noir joue nul
jeu impossible
à noir blanc gagne

mat
6.1.5. conditions
une condition est une fonction booléenne de l'état d'un objet, valide sur un intervalle de temps
un état peut être défini par une condition
être dans un état est une condition

les conditions peuvent être utilisées pour garder des transitions, qui ne peuvent être
déclenchées que si la condition est satisfaite
6.2. opérations
6.2.1. contrôle des opérations

le diagramme d'état comme tel est de peu d'utilité s'il ne permet pas de décrire comment les
objets réagissent aux événement
les opérations attachées aux états et aux transitions sont effectuées en réponse aux stimulations
associées
une activité est une opération qui "dure" un certain temps, et est associée à un état
on compte comme activités les opérations continues : fonctionnement d'un moteur par exemple
et les opérations non instantanées (exécution d'un programme, déplacement du bras d'un robot)
la notation "do:A" dans une boite d'état traduit l'exécution d'une activité A associée à l'état, dès
l'instant d'entrée dans l'état
une action est une opération sans durée, associée à une transition, ou à l'entrée dans un état
traduire une activité par une action est légitime dès lorsque l'on ne s'intéresse pas à la structure
de contrôle de l'opération. Sinon c'est impossible
la notation /A est utilisée pour associer un action A à une transition
6.2.2. résumé de la notation
Etat 1 évt(param)[cond]/a,b,c… Etat 2

do: A, B, C, D… do: …
6.2.3. exemple
compléter le diagramme d'états pour la ligne téléphonique avec des actions et des activités
6.3. diagrammes d’états imbriqués
6.3.1. défauts des diagrammes “plats”

les diagrammes d’états classiques deviennent couramment inextricables pour des problèmes
réels
les situations réelles limitent rarement les transitions possibles d'un état à un autre, et donc la
taille du graphe grandit polynomialement par rapport au nombre de noeuds
la solution à cette difficulté tient à l'abstraction : via la généralisation et l'agrégation
on décrit ainsi des états "abstraits", qui combinent un ensemble d'états, et permettent de réduire
le nombre de transitions dans les diagrammes
par la généralisation, on permet de décrire à un certain niveau une activité, qui pourra
ultérieurement être décrite par un diagramme d'états spécifique

également, on peut décrire les états et événements dans des structures hiérarchiques avec
héritage de la structure partagée et des comportements communs
par l'agrégation, on permet à un état d'être décrit par une collection d'états orthogonaux
concurrents (parallèles)
les états concurrents correspondent normalement à des agrégats d'objets qui interagissent, et
parfois au système entier
6.3.2. imbriquer lesétats

une activité (resp. un événement) d'un diagramme peut être décrite par un diagramme de plus
bas niveau, à exécution unique, qui possède donc une transitions d'entrée et une ou plusieurs
transitions de sortie. Un telle description est analogue à celle d'un sous programme
voici l'exemple d'un distributeur automatique
pièce(valeur)/ajoute
Attente Entrée de pièces
pièce(valeur)/ajoute
annulation/rendre
choisit(article)
[article vide]
[rendu < 0]
do : vérifie choix non vide et calcule

le rendu de monnaie
[rendu == 0] [rendu > 0]
do : délivre article do : rend

monnaie
on peut décrire un sous diagramme pour l'activité "délivre article" : déplacement du bras robot
puis saisie puis lâcher par exemple
on peut aussi fournir un sous diagramme pour l'événement "choisit article" : saisie successive
des chiffres du code article
6.3.3. généralisation d’états

l'imbrication de diagrammes est une forme de généralisation : l'objet doit être dans l'un
exactement des états du sous diagramme quand l'état abstrait est actif (cf. "délivre article" ci dessus)
mais les états du sous diagramme sont alors non sensibles aux événements externes, ce qui
n'est pas le cas général
les états peuvent avoir des sous états qui héritent des transitions de leurs super-états. Toute
transition qui s'applique à un super)état s'applique à chacun de ses sous états
exemple de la boite de vitesses automatique :

R
Point mort M.Arrière
N
N F
M. Avant
stop accélère accélère
1 2 3
décélère décélère
on peut aussi représenter les situations suivantes :

• transition directe vers un état imbriqué
• transition directe vers un état extérieur
6.3.4. généralisation d’événements

on peut décrire des classes d'événements et décrire des raffinements par héritage : par exemple
les événements générés par un système clavier plus souris
la classe la plus général dans ce cas est la classe event :
Event
instant
Entrée utilisateur
device
…
6.4. parallélisme
6.4.1. parallélisme d’agrégation

un modèle dynamique décrit les états possibles des objets du système
chaque objet est dans un état propre, et de ce fait évolue de façon quasi indépendante du reste
du monde

un diagramme d’états pour un assemblage est une collection de diagrammes : un pour chaque
composant
les transitions gardées pour un objet peuvent dépendre de l’état d’un autre
exemple : dans une voiture : le contact, la boite de vitesse, le frein, l’accélérateur évoluent de
façon indépendante; le démarreur ne fonctionne que si la voiture est au point mort :
[ boite de vitesse IN point mort]
6.4.2. concurrence au sein d’un objet

un objet peut avoir des sous états concurrents
on le représente en séparant les états concurrents par les lignes pointillées
6.5. concepts avancés
6.5.1. actions d’init et d’exit

les actions marquées sur les transitions peuvent également être mentionnées en scripts d’init
d’un état
c’est possible quand toutes les transitions qui conduisent à l’état portent la même action
les actions d’init et d’exit sont puissantes dans le cas de diagrammes imbriqués car elles évitent
de nombreuses répétitions
lors d’une transition qui franchit le contour de plusieurs états imbriqués, plusieurs actions d’init
et d’exit peuvent être déclenchées
6.5.2. actions internes

un événement peut déclencher une action qui ne résulte pas en un changement d’état
dans ce cas, plutôt que de faire une flèche en boucle, la paire événement/action est décrite à
l’intérieur de l’état
le fait de rester dans l’état suppose que les actions d’init et d’exit ne sont pas exécutées
on peut forcer le déclenchement de init et exit en décrivant explicitement des transitions qui
reviennent sur l’état
Etat 1 evt1 (att1) [cond1] / action1 Etat 2
do: activité 1
entry / action2
exit / action3
evt / action4
6.5.3. transitions automatiques

souvent on modélise des activités séquentielles
quand cette activité est terminée, une transitions automatique déclenche vers un état suivant
on représente cette situation par une transition sans nom d’événement associé

si aucune activité n’est associée à l’état, cette transition déclenche immédiatement, mais les
actions d’init et d’exit sont toujours appelées
de telles transitions peuvent être gardées, ce qui permet de sélectionner celle qui va être
activée en fonction d’une condition logique particulière
si aucune condition n’est satisfaite pour les transitions automatiques), l’objet reste dans l’état
courant jusqu’à ce que cela se produise, ou qu’une autre transition soit déclenchée par un événement
6.5.4. envoi d’événements

un objet peut envoyer des événements à d’autres objets
une action appeléesend le permet : send Event(attr.)
tout objet ayant une transition sur l’événement le traite en parallèle
une notation graphique existe aussi pour le concept :
Etat 1 evt1 (att1) [cond1] / action1 Etat 2

do: activité 1
entry / action2
exit / action3
evt / action4
evt2 (att2)
Classe
la flèche peut être connectée directement à une transition de l’objet cible pour indiquer que
celui ci dépend de l’événement
si un état accepte des événements en provenance de plusieurs objets, on se trouve en présence
d’une situation appelée “race condition” (course). L’ordre dans lequel les événements peuvent se
produire influe sur l’état final. La conception doit éviter soigneusement ces situations quand elles ne
sont pas désirées
dans de nombreux cas, l’envoi d’événements ne peut pas être distingué d’une action (l’activité
“sonnerie occupé“ est en fait un événement entre la ligne et l’appelant.

6.5.5. synchronisation d’activités concurrentes

parfois, des activités concurrentes doivent être terminées pour permettre une transition : on
doit les synchroniser
le flot de contrôle traduit par les transitions peut être divisé, ou combiné
exemple :
donne billets
do :donne billets ok billets

prêt
préparation fin transaction
do :rend carte ok carte
toute transition vers un état ayant des sous états concurrents les active tous
en l’absence d’information supplémentaire, c’est l’état initial par défaut qui est choisi
dans le cas de fusion du contrôle, la transition déclenche quand les deux événements ont eu
lieu, sans qu’ils doivent pour cela être simultanés
lorsqu’une transition déclenche la sortie d’un état composite concurrent, cela provoque la fin
des activités en cours dans tous les sous états, avec appel des actions d’exit
fusionner le flot de contrôle permet aux transitions de s’attendre, ce qui n’est donc pas le cas
par défaut
6.6. relation entre les modèles objet et dynamique

un modèle dynamique décrit tout ou partie du comportement des objets d’une classe donnée
les états sont des classes d’équivalence d’attributs et de valeurs de liens pour des objets
les événements sont des opérations du modèle objet
chaque sous état d’un état contraint plus les valeurs des attributs, ainsi que le fait la restriction
un hiérarchie d’états est équivalente à une hiérarchie de restriction pour la classe
les modèles et langages orientés objet ne permettent pas habituellement de décrire la
généralisation par restriction dan l’héritage, d’où l’intérêt d’un modèle dynamique
héritage de restriction et héritage d’états sont deux points de vue sur la même chose : l’un
statique (un objet ne peut pas changer de classe), et l’autre dynamique (il peut changer d’état dans sa
classe)
le modèle objet décrit des différences inhérentes aux objets
le modèle dynamique décrit des différences temporaires
6.6.1. états composites

un état composite est un agrégat d’un ou plusieurs sous états
il y a trois sources complémentaires de parallélisme :
• chaque composant d’un agrégat possède son état propre
• des groupes d’attributs et de liens d’un objet peuvent avoir des états indépendants

• l’exécution concurrente d’opérations

le modèle dynamique d’une classe est hérité par les sous classes, qui possèdent les mêmes
transitions et les mêmes états
les sous classes possèdent leurs propres diagrammes d’états : comment interagissent ils?
• si ces diagrammes portent sur des ensembles d’attributs disjoints : pas de problème
• sinon : le diagramme pour la sous classe doit être un raffinement de celui de la superclasse
ou encore : le diagramme de la super classe doit être une projection de ceux des sous classes
on ne peut donc pas introduire de modifications dans les diagrammes d’une classe mère sans
tenir compte des classes filles
habituellement, le diagramme de la sous classe est une contribution orthogonale, indépendante
du diagramme de la super classe
6.6.2. événements
la hiérarchie des événements est indépendante de celle des classes en pratique
les événements sont fondamentaux, partagés par plusieurs classes en général
chaque états sont définis indirectement par les objets et les événements
les transitions sont souvent implantées par des transitions sur les objets, de même nom
les événements sont plus expressifs que les opérations, puisque leur effet dépend aussi de l’état
de l’objet
6.7. trucs pratiques

ne fournir un modèle dynamique que pour les classes qui le nécessitent
vérifier la cohérence des événement partagés
utiliser des scénarios pour mettre au point
ne définir un état que sur la base des attributs pertinents
prendre en compte les besoins applicatifs lors du découpage en états et événements (plus ou
moins précis comme on a vu)
procéder de même en ce qui concerne activités et événements
utiliser les états composites seulement pour relater le parallélisme interne aux objets : le
parallélisme d’agrégat est implicite
rendre les diagrammes des sous classes indépendants de ceux des super classes
attention aux situations de priorité (“race conditions”) qui se produisent quand un objet attend
des événements en provenance de plusieurs autres
6.8. résumé
action activité
agrégation condition
contour contrôle
diagramme d’étatsdiagramme imbriqué
état événement
garde généralisation
modèle dynamiqueopération

parallélismerace condition
scénario trace
transition
6.9. exercices
6.9.1. exercice
faire le diagramme d’états d’un robinet de douche, avec levier de sélection bain douche, qui
retombe automatiquement en position bain quand on ferme le robinet
id pour une échelle à deux pans, avec corde et cliquet
id pour une montre digitale
id pour un répondeur
id pour un moteur à deux bobinages (démarrage et action normale) qui fonctionne quand sa
commande est on, et s’arrête automatiquement en surchauffe ou sur l’appui sur off
id pour une installation de chauffage central avec sélection de température dans chaque pièce
id pour un magnétoscope
7. Modélisation fonctionnelle
le modèle fonctionnel décrit les calculs effectués par un système : un calcul est une
transformation de données
on décrit les résultats des transformations de données, sans dire quand ces transformations se
produisent
l'exposé qui est fait dans cette partie ressemble aux DFD habituels
7.1. le modèle fonctionnel

ce modèle décrit la signification - le rôle - des opérations et des actions des modèles objet et
dynamique
le modèle fonctionnel est central pour certains systèmes (compilateurs, feuilles de calcul
électronique, le code des impôts)
7.2. les diagrammes de flot de données

un diagramme de flots de données (DFD) décrit les relations fonctionnelles qui existent entre
les différentes valeurs calculées par un système
un DFD est un graphe qui relie essentiellement des sources de données et des processus
normalement, un tel graphe ne mentionne pas le flot de contrôle
les éléments d'un DFD sont :
• des process : qui transforment des données
• des flots de données : qui déplacent des données

• des acteurs : qui produisent et consomment des objets

• des mémoires : qui stockent et rendent disponibles des informations
7.2.1. un exemple
Définitions des icones Fenêtre
taille position
vecteurs vecteurs
nom d’icone transforme de base coupe à la fenêtre déplace de
en vecteurs taille de la fenêtre l’offset de la fenêtre
emplacement
vecteurs écran
Buffer Ecran traduit

en pixels
pixels
7.2.2. les process

un process transforme des données
ceux de plus bas niveau correspondent tout simplement à des fonctions sans effets de bord
un DFD complet peut être vu comme un process de haut niveau : par exemple, le DFD
précédent devient :
nom d’icone
affiche
icone
pixels à dessiner
position
le diagramme montre les différents chemins suivis par les données, sans préjuger de celui qui
sera effectivement utilisé
un process a plusieurs entrées, et souvent plusieurs sorties :
dividende quotient
division
entière
reste
divisor
7.2.3. …les process

un diagramme plus précis décrit ce qui est à l'oeuvre dans un process de haut niveau

au bout du compte, il peut devenir nécessaire de décrire un process de bas niveau par d'autres
moyens : algorithme, équations, langage courant etc...
les process sont programmés par des méthodes (ou des fragments de méthodes)
l'objet qui implante cette méthode est souvent une classe qui apporte les données d'un des flots
d'entrée du processus, surtout lorsque cette même classe est aussi un flot de sortie
parfois, l'objet cible est implicite : dans l'exemple de l’icône, il s'agit de la fenêtre qui reçoit les
pixels à dessiner
7.2.4. les flots de données

un flot relie une sortie d'un objet ou process ou mémoire à l'entrée d'un autre de ces éléments
il représente une donnée inchangée dans son transport
la même valeur peut être transmise à plusieurs consommateurs
date
une donnée peut être décomposée en éléments (attributs)

nom
adresse ville
pays
7.2.5. les acteurs

un acteur est un objet actif qui produit ou consomme des valeurs
de tels objets sont liés aux entrées et aux sorties d'un DFD
on les appelle aussi terminateurs, du fait de leur position périphérique
exemples : l'utilisateur d'un programme, un thermostat, un moteur
les opérations des acteurs sont sans objet pour le DFD, mais doivent être décrites par les
diagrammes dynamiques (recevoir une donnée en "entrée" est forcément traduit en un événement)
un acteur est représenté avec la notation usuelle pour les classes : c'est un objet
7.2.6. les banques de données

une banque de donnée (data store) est un objet passif, qui stocke des données ou des objets
pour une utilisation future
contrairement aux acteurs, elles n’implantent pas d'autres opérations que celles de stocker et
rendre des informations
le statut habituel d'une base de données est une banque de données dans un DFD
une banque de données peut restituer un élément isolé mémorisé ou bien l'intégralité d son
contenu
les banques de données sont des objets du point de vue OMT
d'un point de vue pratique, elles peuvent être implantées par des fichiers

7.2.7. exemple
max
Archives météo
min
température
7.2.8. exemple : retrouver et stocker par le m

ême process
Compte en banque
solde
montant retrait
Client
7.2.9. exemple : entrées et sortie séparées

référence
Liste de prix
prix
référence calcule prix

prix
7.2.10. exemple : une banque de données constante
Table Périodique
élément trouve masse atomique

masse

7.2.11. exemple : la sélection d'un objet comme résultat de

processus
Sélection
Banque de compte Compte
nom solde
requête modification
Client
7.2.12. exemple : la création d'un objet comme résultat de processus
Création compte
de compte Banque
nom, dépot initial

Client Compte
numéro
7.2.13. les diagrammes imbriqués

les DFD forment naturellement une structure d'arbre, puisque chaque process peut être
décomposé en un sous DFD
un diagramme imbrique peut comporter des banques de données non visibles au niveau
supérieur
un processus récursif est représenté par un diagramme qui s'auto référence
le niveau terminal d'imbrication fait habituellement figurer des fonctions au sens habituel, mises
en oeuvre au travers d'opérations membres des classes d'objet définies par ailleurs
7.2.14. le flot de contrôle

le flot de contrôle est normalement décrit par des diagrammes dynamiques
en cas de besoin, il peut être incorporé aux DFD
il est compris comme une donnée booléenne (en vrai/faux) qui intervient en entrée et/ou en
sortie de processus, et représenté par une flèche pointillée

Compte en banque
code crypté
vérification solde
ok
code
montant
retrait
Client
billets
7.3. la spécification d'opérations

tout process de bas niveau est une opération
ceux de plus haut niveau sont en général organisés de façon à satisfaire des besoins
d'optimisation
les processus de bas niveau sont spécifiés par des moyens appropriés, dont entre autres :
• des fonctions mathématiques ou de bibliothèques externes
• des tables de données énumérées pour de petits ensembles
• des équations ou contraintes
• des descriptions axiomatiques (pré, post et delta conditions)
• des tables de décision
• du pseudocode
• du langage naturel
7.4. …la spécification d’opérations

spécifier une opération requiert de définir sa signature (en conformité avec ce qui est connu
par le modèle objet) et la transformation qu'elle opère sur ses arguments, dont l'objet cible lui même
ainsi que la donnée qu'elle retourne
la spécification externe d'une opération ne nécessite pas de décrire des changements
temporaires à son exécution
la modification de données privées (invisibles de l'extérieur) d'un objet est considérée comme
ne changeant pas son état logique (toujours distingué de l'état physique)
les opérations d’accès lisent ou écrivent des attributs ou des liens de l’objet
elles permettent de décrire précisément les droits d’accès aux données membres et sont
précisées dans les phases aval de la modélisation
les opérations on triviales entrent dans trois catégories :
• les requêtes (ou accesseurs)
• les actions
• les activités

7.5. …la spécification d’opérations
7.5.1. les requêtes

une requête ne possède pas d’effet de bord
une requête sans paramètre est un attribut dérivé
7.5.2. les actions

une action possède des effets de bord, et n’a pas de durée. Elle procède par des modifications
d’attributs et de liens sur l’objet lui même ou d’autres
une action peut être définie en termes de l’état du système avant et après son exécution, de
façon formelle ou non, mais en tout cas sans ambiguïté
on peut aussi décrire son algorithme, par exemple en pseudo code
7.5.3. les activités

une activité possède une durée, “donc” des effets de bord
elles ne sont pertinentes que pour les objets de type “acteur”, et pas pour les mémoires ou
banques de données
les activités sont spécifiées par le modèle dynamique et par le modèle fonctionnel
dans beaucoup de situations, une activité correspond à un diagramme d’états du modèle
dynamique
7.6. les contraintes

les contraintes portant sur des valeurs permises d’attribut d’objets sont appelées des invariants
les contraintes sont spécifiées à l’aide de fonctions, qui implantent toutes les possibilités de
propagation rendues nécessaires par l’exploitation du système
celles du modèle objet spécifient que certains objets dépendent entièrement ou partiellement
d’autres objets
les contraintes dynamiques montrent les relations entre des états et des événements
les contraintes fonctionnelles spécifient des restrictions sur les opérations
7.7. la relation entre les trois modèles

le modèle fonctionnel montre ce qui doit être fait par un système
les process de plus bas niveau y sont des opérations d’objets : implantés par des méthodes des
classes appropriées
souvent, on observe une correspondance directe à chaque niveau de modélisation
le modèle dynamique montre dans quel ordre les opérations peuvent avoir lieu
souvent, une des entrées d’un process est l’objet support de la méthode associée, le reste étant
des paramètres
l’objet support est client des autres objets mentionnés dans le DFD (les fournisseurs) car il
utilise leurs ressources

la distribution en clients-fournisseurs oriente la conception des classes : les classes clientes

dépendent des autres (i.e. sont implantées en termes des autres)
7.7.1. règles empiriques pour la détermination de l’objet support d’un

méthode
si la même classe est en entrée et en sortie d’un process, c’est la classe support de la méthode
id si une banque de donnée est en entrée ou en sortie d’un process
souvent, un process avec une entrée vers ou une sortie d’une banque de données est traduit par
deux méthodes, dont l’une est un select ou update implicite vers la banque de données
si un acteur est en entrée ou en sortie, c’est le support
si une entrée est un objet, et une sortie est le même objet ou un voisin dans le diagramme objet,
l’objet est support
si un objet est créé à partir de parties indépendantes, la méthode est une méthode de la classe
résultat (construction d’objet)
si aucune de ces règles n’est applicable, l’objet support est vraisemblablement implicite, et ne
figure ni dans les entrées ni dans les sorties du process
souvent, le support d’un process est celui d’un sous diagramme entier
7.7.2. les acteurs

les acteurs sont des objets explicites dans le modèle objet : les flots de données qui en partent
ou y arrivent représentent des opérations appliquées à ou effectuée par ces objets. Dans ce cas, les
valeurs des flots sont des arguments ou des résultats de ces opérations
7.7.3. les banques de données

les banques de données sont des objet ou des attributs du modèle objet. Les flots qui les lient
sont des requêtes de sélection ou de modification sans effet de bord
7.7.4. les flots de données

les flots eux mêmes sont des données du modèle objet, le plus souvent d’un type de base, ou
des listes ou tableaux de ces types
ces valeurs peuvent être implantées par des objets informatiques, mais du point de vue OMT
ne possèdent pas d’identité :
OMT ne distingue pas entre les deux tableaux [1,”abc”,5] et [1,”abc”,5], alors que l’on a vu
que deux objets distincts pouvaient être identiques par leur contenu
les flots peuvent être des objets.
en entrée d’un processus, ce sont souvent des objets support sur lesquels le process invoque
des opérations
dans d’autres cas, les objets sont juste passés de process en process, et ne sont que des
arguments aux opérations
7.7.5. du point de vue du modèle fonctionnel

le modèle objet montre la structure des acteurs, banques de données et flots

le modèle dynamique montre la séquence dans laquelle les opérations sont réalisées
7.7.6. du point de vue du modèle objet

le modèle fonctionnel montre les opérations des classes et leurs arguments, et témoigne de la
polarité client-fournisseur
le modèle dynamique montre les états des objets et les opérations déclenchées quand des
événements se produisent
7.7.7. du point de vue du modèle dynamique

le modèle fonctionnel définit les actions et activités non spécifiées dans le modèle dynamique
le modèle objet montre la structure de ce qui change d’état et de ce qui subit des opérations
7.8. mots clef

acteur
action
activité
banque de données
client
contrainte
diagramme de flots de données
flot de contrôle
flot de données
fonction
invariant
modèle fonctionnel
opération
process
requête
signature
terminateur
7.9. exercices
7.9.1. exercice
décrire un DFD pour le calcul le volume et la surface d’un cylindre
7.9.2. exercice
id pour calculer la moyenne d’un séquence de valeurs en entrée
on dispose d’une entrée de contrôle pour faire un reset
détailler le diagramme jusqu’aux multiplications et additions

7.9.3. exercice
représenter le DFD de calcul des solution d’une équation du deuxième degré
7.9.4. exercice
représenter le DFD de cut et paste pour le diagramme objet suivant :
Boite
texte
x haut gauche 2 Lien
y haut gauche
hauteur
largeur select
deselect
cut Collection toggle selection
select
deselect
toggle selection
1,2
Segment Point
2
Sélection Buffer Feuille cut x
cut y
paste delete
copy
move
Dessin Fichier dessin

nom nom
add sheet
next sheet
previous sheet
save
load

Cours 3

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours 3

Transféré par

Droits d'auteur :

Formats disponibles

Cours de Génie Logiciel

Ecole Supérieure d’Ingénieurs de Luminy

Université de la Méditerranée Aix-Marseille II

Cours de génie logiciel

par Laurent Henocque

version 1.1 en date du 4 octobre 1996

1. Présentation générale de la méthode OMT

1.1. esprit de la méthode

Ecole Supérieure d’Ingénieurs de Luminy / département ES2I, Marseille 1

1.3. les outils

• analyser les besoins

1.5. le cycle de vie logiciel (abrégé)

1.6. généralité de la méthode

• bases de données relationnelles

Ecole Supérieure d’Ingénieurs de Luminy / département ES2I, Marseille 2

1.7. à priori fondamentaux de OMT

1.8. contenu du cours

• indépendants de tout langage

• la notation graphique est présentée dans cette partie

• le processus est suivi étape par étape jusqu'à la conception détaillée

• comprendre des problèmes

• communiquer avec des experts

• modéliser des organisations

• concevoir des programmes et des bases de données

Ecole Supérieure d’Ingénieurs de Luminy / département ES2I, Marseille 3

• les objets applicatifs ainsi décrits forment le cadre de la programmation à venir

• enfin, on traduit le modèle dans un langage de programmation quelconque

2.1. Qu'est ce que l'orientation objet

2.2. … Qu'est ce que l'orientation objet

Ecole Supérieure d’Ingénieurs de Luminy / département ES2I, Marseille 4

2.3. Qu'est ce que le développement orienté objet?

2.3.1. modélisation de concepts plutôt que de programmes

2.3.2. méthodologie orientée objet

• une méthodologie pour le développement orienté objet

• une notation graphique pour la communication de concepts orientés objet

Ecole Supérieure d’Ingénieurs de Luminy / département ES2I, Marseille 5

modélisation des objets

• garantir la traçabilité des programmes para rapport à la spécification (vérification)

Ecole Supérieure d’Ingénieurs de Luminy / département ES2I, Marseille 6

• aboutir à un résultat suffisamment réutilisable, maintenable, extensible, portable …

2.3.3. les trois modèles de OMT

• diagrammes de transition d'états

• contrôle (conditions de déclenchement d'une opération)

• diagrammes de flots de données

2.3.4. différences avec l'approche fonctionnelle

2.4. Concepts sous jacents aux objets

Ecole Supérieure d’Ingénieurs de Luminy / département ES2I, Marseille 7

2.4.3. combinaison de données et de comportement

2.5. … Concepts sous jacents aux objets

• on partage des données et des traitements, en faisant l'économie de répétitions

• la réusabilité n'est pas spontanée, mais elle est possible

• la programmation objet permet la réalisation de bibliothèques de composants réutilisables

2.6. Concepts sous jacents aux objets

Ecole Supérieure d’Ingénieurs de Luminy / département ES2I, Marseille 8

2.7. Preuves de l'utilité de ces concepts en programmation

• des langages objet avancés

• systèmes de contrôle de process

• documentation de programmes existants mal structurés

• communication avec des experts

2.8. Organisation du cours

• chapitre 2 : la notation OMT

• chapitre 3 et 4 : le modèle objet

• chapitre 5 : le modèle dynamique