3 Introduction aux méthodes orientées objet

Il existe plusieurs méthodes d’analyses ou conception orientées objet regroupées en trois groupes
:
 Les méthodes fondées sur les langages
 Les méthodes fondées sur la tradition
 Les méthodes fondées sur le développement

Nous en proposons quelques exemples, présentées rapidement dans l’intention de fournir un

panorama sommaire et des points d’entrées sur les méthodes disponibles .

3.1 Les méthodes fondées sur les langages de programmation

Elles sont parues les premières. Elles répondaient à la nécessité pressante de guider les
réalisations dans les nouveaux langages orientés objet . D’abord méthodes de programmation
elles se sont étendues jusqu’ à l’analyse . Leur pragmatisme et leur inspiration très concrète les
rendent d’un accès généralement facile , et permettent une mise en pratique quasi
immédiate.
Elles comportent de nombreux inconvénients :
 Elles portent le plus souvent sur une seule phase .
 Si elles reconnaissent pleinement leur détermination par la technique
d’implémentation (les outils intellectuels mis à disposition pour le ou les
langages), elles négligent la détermination «par le haut» : la situation de
modélisation .
 Elles n’abordent pas les problèmes liés auX projets de moyenne et de
grande envergure .
 Elles raisonnent assez peu en terme de métiers.
 Elles n’ambitionnent pas de fournir une vision totale du projet
informatique, et laissant de côté les préoccupations de pilotage et de
démarche d qualité .

3.1.1 COAD et YOURDON

OOA (Objet Oriented Analysis) est l’un des premiers ouvrages à s’être imposé dans le courant
méthodologique objet. C’est l’œuvre de Peter COAD et de Edward YOURDON . l’approche
développée est simple et pragmatique et est fondée sur les trois principes d’organisation de la
pensée :
 La différentiation de l’expérience entre les objets et leurs attributs (aspects,
qualités, …)
 La distinction entre partie et tout .
 La constitution des classes .

Trois types de comportements orientent la recherche des classes :

 La causalité immédiate
 La similarité génétique (évolution historique)
 La similarité fonctionnelle.
Méthodes orientées objet
3.1.1.1 La démarche
OOA est une méthode métier plus que développement . Elle se présente plus comme le guide
de l’analyste .Elle a été complétée par OOD(Object Oriented Design) et OOI(object Oriented
Implementation).
OOA ordonne l’analyse en cinq activités :
 Trouver les classes et objets.
 Identifier les structures .
 Identifier les sujets
 Identifier les attributs
 Identifier les services

OOA a inspiré différents travaux . La société Corélis Technologie utilise le System Model
OSSASS.
O Object identification
S Structure identification
S Subject definition
A Attribute definition
S Service definition
S State definition
Remarque : on passe de OOA à OOD, par addition d’attributs et de services imposés par les
choix d’architecture matérielle et logicielle .
Pour COAD et YOURDON , la normalisation du modèle objet doit être repoussée vers la
conception .

3.1.1.2 La modélisation
a) Identification des objets

Les terminateurs externes , identifiés sur le diagramme de contexte, peuvent être

représentés par des objets dans la modélisation, de façon à permettre la communication .
On commence par établir une liste de candidats objets , puis, pour chacun, on évalue sa
pertinence . On doit être capable de lui trouver un nom ( et non un verbe ) . On ne retient
un objet que si on peut lui affecter un attribut ou un service .

b) Définition de la structure

On établie les relations structurelles entre les objets .Pour cela , on applique les méthodes
d’organisation logique :
 Agrégation : abstraction des caractéristiques dans la définition de l’objet.
 Assemblage : des composants dans le tout
 Classification : généralisation et spécialisation des objets .

c) Identifiation des sujets

Il s’agit en fait , de la délimitation de domaine grâce à quoi on pourra repartir le travail . Les
frontières ne doivent pas couper les liens structurels. Les domaines définis doivent manifester
une cohésion interne forte et un couplage faible . Cette délimitation ne se confond pas
avec le découpage en sous-systèmes.

Page 2/16
Méthodes orientées objet
d) Définition des attributs

Point n’est besoin de s’embarrasser ici de l’épineuse question de l’identifiant . En effet c’est
là une préoccupation d’implémentation , étrangère donc à l’analyse .
Au cours de cette tâche ,on fixe également les cardinalités des connexions entre objets
(connexions d’instances ) .Une connexion porteuse d’attribut devient un objet (avec
cardinalité 1,1) .Il convient d’isoler les propriétés multivaluées et d’en faire des objets
(éventuellement reliés à un objet parent par le lien d’assemblage ).
A ce niveau , on ne s’interroge pas encore sur le caractère public ou privé des attributs .

e) Définition des services

On distingue :
 Les constructeurs (constructors) : créer l’objet ,le mettre à jour , le détruire.
 Les accesseurs (selectors) : fournir une information (attributs ou calculs)
 Les transformateurs (behaviors) : modifier , démarrer , arrêter , …

L’analyse applique cette typologie sur chaque objet .

Les constructeurs existent par défaut . S’il est utile de les présenter sur le schéma , il faut les
documenter : ils peuvent constituer jusqu’à 50% de l’application ( par exemple le service « créer»
affecte des valeurs par défaut à l’objet et déclenche des services ) .
L’analyste étudie le dictionnaire des évènements ; ceux-ci peuvent gérer de nouveaux
services .
Les messages recouvrent les évènements , les réponses et les flux de données qui s’échangent
entre les objets .Ils transitent le long des connexions d’instances .
La spécification d’un service est complète quand on a indiqué pour chaque service : la fonction
qu’il réalise, les paramètres d’entrée et de sortie, le degré de concurrence et le parallélisme
interne .

f) Définition des états

OOA recourt à la métaphore des automates à états finis par un diagramme états-transitions .
Dans le schéma suivant on appelle action soit des services locaux, appartenant à l’objet
considéré , soit des services externes appartenant à d’autres objets .

Etat 1

Condition
Liste d’actions Condition
Liste d’actions

Etat 2
Condition
Liste d’actions

Etat 3

Exemple de diagramme états-transitions

Page 3/16
Méthodes orientées objet
3.1.1.3 Formalisation (représentation des objets dans OOA)

Objet Classification
Nom de l’objet
Mobilier
Attributs
Style
Services Couleur
Prix

Déplacer

Table Lampe

Capacité Voltage

Allumer
Assemblage

Automobile

Moteur Carrosserie

3.1.2 BOOCH
Grady BOOCH s’était acquis une réputation avec son livre ingénierie du logiciel avec Ada . Il a
récidivé en proposant ses réflexions basées cette fois-ci sur l’application de plusieurs langages
orientés objets (pascal Object, C++, Clos , ADA) dans conception Orientée Objet et Application .
BOOCH proposait le découpage suivant :
 Identifier les objets et leurs attributs
 Identifier les opérations qui affectent chaque objet et les opérations que chaque
objet doit déclencher .
 Etablir la visibilité de chaque objet vis-à-vis des autres.
 Etablir l’interface de chaque objet
 Implémenter chaque objet .

Retenons l’apparition des considérations nouvelles par rapport à l’analyse : la visibilité

,l’interface ,typiques du langage ADA . Par contre ADA n’est pas un langage orienté objet , à
strictement parler , mais un langage basé sur les objets . Il lui manque en effet de supporter
l’héritage .

Page 4/16
Méthodes orientées objet
Conception Orientée Objet et Applications tient compte du changement et propose pour la
conception les activités suivantes :
 Identifier les classes et les objets.
 Identifier la sémantique des classes et objets
 Identifier les relations entre les classes et objets
 Implémenter les classes et les objets.

Quant au cycle de développement général ; BOOCH substitue au cycle classique en cascade , un

cycle assoupli où joue en fond le caractère incrémental et itératif du processus .
Dans ce cycle , l’analyse et la conception conservent leur définition traditionnelle . L’évolution
est une phase qui combine la programmation, les tests et l’intégration. Procédant par
prototypage , elle tolère des changements apportés au modèle objet . BOOCH en énumère les
catégories ( par ordre croissant de bouleversement) :

Analyse

Conception

Evolution

Modification

Le cycle de développement d’après BOOCH

 Addition d’une nouvelle classe
 Changement de l’implémentation
 Changement de la représentation de la classe
 Réorganisation de la structure de la classe
 Changement de l’interface de la classe

La phase de modification correspond à la maintenance .

BOOCH élabore une notation sophistiquée qui régit les outils de représentation : diagrammes de
classes, diagrammes de transition d’états ( changement d’état à l’intérieur d’un même objet ),
diagrammes d’objets ,diagrammes chronologiques ( graphique cartésien indiquant la succession
des opérations demandées à différents objets) , diagrammes de modules ( architecture physique),
diagrammes de processus ( pour systèmes indiquant plusieurs programmes sur plusieurs
machines ) .
La méthode de Grady BOOCH est diffusée par la société Rational . Elle est supportée par l’outil
Rose .

Page 5/16
Méthodes orientées objet
3.1.3 HOOD (Hierarchical Object Oriented Design)
Cette méthode s’inspire des travaux de Grady BOOCH . Elle est issue d’un projet mené par CISI
en réponse à un appel d’offre de l’ESA en 1986 . Elle s’adapte parfaitement aux structures de
représentation propres à ADA .
Son principe de structuration est la hiérarchie parent-enfant au sens du paquetage ADA . Un
enfant n’existe pas de manière autonome dans le système ; il n’est pas visible en conséquence ,
aucun autre objet que son père ne peut l’utiliser . Il s’agit d’une logique d’imbrication .
L’héritage n’est pas représenté (puisque ADA ne le supporte pas) . La méthode favorise le
développement en couches ; elle est très proche de la méthode par décomposition descendante,
mais plus sûre car insistant sur les notions de visibilité et d’interface .
Ses facultés de représentation des comportements en font un bon outil pour la modélisation du
temps réel .
De plus , elle offre un formalisme textuel poussé : Object Description Skeleton .

Représentation de l’objet dans HOOD

OBJET

Enfant1

Services Enfant1 Données

E Environnement
Interface Enfant3

Enfant2
3 Autre objet

Par ailleurs, CISI a cherché à intégrer ses deux méthodes , KOD (Knowledge Oriented Design ) et
HOOD . L’occasion a été fournie par le SERNIT (France Télécom ) . L’idée centrale est la suivante :
Utiliser SDM/S (System Developpement Management distribué en France par Cégélog) comme
coquille vide et y insérer chacune des méthodes pour ce qu’elle peut apporter de meilleur .
Ainsi , l’ordonnancement des travaux et toutes les activités de conduite et de vérification se
définissent dans le respect scrupuleux des préceptes de SDM/S .Mais KOD et HOOD se glissent
dans le cycle de développement, resectiveent comme méthode de spécification et méthode de
conception . on aura recours à KOD quand le système étudié présente « un peu de facteur
humain » c’est-à-dire quand il s’agit de modéliser une forte expertise . Autrement , on utilisera
les méthodes classiques .

Page 6/16
Méthodes orientées objet

Connaissances Système

SPECIFICATION
SGS DBS
SDS Définition des fonctionnalités
Analyse du système de souhaitées
représentation proposée par
l’expert

Choix de l’environnement

BCO

Conception globale
CGS
Définition de l’architecture du
système
Modélisation hiérarchique des
transactions
Conception
détaillée
CDS CDS
PRG PRG
Traduction des formats Compilation
réutilisation

Par rapport au cycle de base SDM/S , on note quelques évolutions . Il est significatif qu’un peu de
spécifications externes « passe avant » les choix techniques .Par exemple les utilisateurs peuvent
réclamer un mode de représentation particulier ou des aptitudes du logiciel qui conditionnent le
choix d’architecture . Ces desiderata apparaissent très naturellement au moment des
spécifications externes , c’est-à-dire selon SDM/S quand les choix techniques sont entérinés .
Or ils peuvent se révéler incompatibles avec ces choix .
La répartition entre KOD et HOOD n’est pas seulement verticale ( une méthode par phase ), car la
considération des connaissances incluse dans le système introduit une nouvelle coupure En effet ,
pour une même phase , on pourra choisir KOD pour la modélisation des connaissances , et HOOD
pour la modélisation des traitements (KOD rend compte de la statique tandis que HOOD est
adaptée par l’aspect dynamique et l’architecture ). HOOD a la réputation de mieux analyser les
traitements que MERISE .

3.1.4 MEYER
MEYER ne prétend pas apporter une méthode de conception , mais son œuvre notamment autour
du langage Eiffel , est douée d’une telle rigueur et d’une telle profondeur qu’elle mérite d’inspirer
l’analyste et le concepteur ; d’autant que la « conception utilise les mêmes mécanismes
intellectuels que la programmation , simplement à un niveau d’abstraction plus élevé » . La
réflexion menée par MEYER se développe surtout autour du matériau logiciel , s’interrogent sur
l’obtention de la qualité.

Page 7/16
Méthodes orientées objet
La qualité du logiciel s’exprime en terme de validité , robustesse ,extensibilité (dont , d’une part la
simplicité de la conception , d’autre part , la décentralisation ), réutilisabilité , couplabilité
(compatibilité) .
L’analyse de la modularité du logiciel dégage 5 critères indépendants :
 Décomposition modulaire : une méthode de conception répond au critère de
décomposabilité modulaire si elle aide à décomposer un nouveau problème en
plusieurs sous problèmes dont la solution peut être recherchée séparément.
 Composabilité modulaire : caractère d’une méthode qui favorise la productivité
d’élements de logiciel qui peuvent être combinés librement les uns avec les autres
pour produire de nouveaux systèmes .
 Compréhensibilité modulaire : une méthode favorise la compréhensibilté modulaire
si elle aide à produire des modules dont chacun peut-être compris par un lecteur
humain .
Contre-exemple : dépendances sequentielles .
 Continuité modulaire : une méthode répond au critère de continuité modulaire si
une petite modification de la spécification du problème n’amène à modifier qu’un
seul module , ou peu de modules , d’un système produit . D’où une limitation de
l’impact sur l’architecture du système .
 Protection modulaire : caractère d’une méthode qui conduit à des architectures
dans lesquelles l’effet d’une condition anormale , se produisant à l’exécution d’un
module , reste localisé à ce module , tout au moins ne se propage qu’à quelques
modules voisins .

La continuité modulaire aboutit à la formulation d’un principe qu’on souhaiterait voir repris par
tous les langages : le principe du référent uniforme qui stipule : « Le client n’a pas à connaitre la
nature de l’information qu’il sollicite » c’est-à-dire un objet doit pouvoir demander une
information à un autre objet dans une syntaxe unique , quelle que soit l’implémentation de la
propriété informative (attribut ou fonction) .

3.2 Les méthodes fondées sur la tradition

Ces méthodes ont pour caractéristique de récupérer ( ou de vouloir récupérer) un patrimoine
méthodologique reconnu . Elles cherchent à préserver les compétences disponibles et se
proposent de faire fructifier une base théorique qui a prouvé son efficacité.
La contrepartie est qu’elles ne prennent encore que partiellement le paradigme orienté objet .
Mais il est indubitable quelles peuvent apporter aux futures constructions méthodologiques un
fond de préceptes et une richesse théorique qui font souvent défaut aux actuelles méthodes
objet . Nous verrons pour illustration «Autour de MERISE» .
MERISE est une méthode française d’analyse et de conception assez complète et pertinente la
plus utilisée en France. Son succès se justifie par une assise théorique rigoureuse, complétée par
des règles opératoires assez finement définies . Ainsi, à la puissance d’une réflexion théorique
fondée d’abord sur le modèle entité-relation de CHEN, elle allie le détail des procédés
méthodiques qui plaisent à .
Les travaux en vue d’enrichir MERISE, ou de l’adapter à l’esprit objet présentent un double
intérêt :
 préserver les compétences méthodologiques actuelles en favorisant une transition
douce vers l’orientation objets.

Page 8/16
Méthodes orientées objet
 lester l’approche orientée objets des résultats théoriques et des expériences de
MERISE .

Le propre des travaux autour de MERISE « objectifié» est de conserver les anciens postulats , les
anciennes structures . Cette attitude risquerait de bloquer le changement profond apporté par le
nouveau paradigme . On arrivera jamais à exprimer dans la géométrie euclidienne des résultats
des géométries non euclidiennes .

3.2.1 MERISE OBJET

NB : Il ne faut pas confondre MERISE Objet avec MERISE 2 de H.TARDIEU à la SEMA.
Le dilemme pour l’adaptation de MERISE est le suivant :
Doit-on maintenir l’axiome de la séparation données/traitements ? Mais alors on ne peut pas
décemment se prétendre orienté objet.
Ou doit-on renoncer à cet axiome, et simplement élargir la notion de propriété aux fonctions et
procédures ? Alors, on préserve l’apparence du modèle de données, mais quelle transformation
subit la rigueur sémantique de la modélisation et que devient la normalisation ?
Le débat se situe surtout dans le cadre de l’informatique de gestion. Les procédures
administratives qui caractérisent ces systèmes de gestion sont bien rendues par les modèles de
traitement que préconisent MERISE. En particulier, la modélisation des aspects organisationnels
convient bien à ce domaine.
Pour fournir une expression équivalente en orienté objet, on doit exprimer les processus,
opérations, procédures et taches en tant que suites d’appels aux propriétés des objets. Mais en
procédant de cette façon, c’est-à-dire en suivant une orientation différente des postulats
paradigmatiques, on encourt le risque d’élaborer des opérations plus complexes dans leur
contenu qu’il n’est nécessaire. Dans ces conditions, soit l’analyste ou le concepteur vérifie la
cohérence des opérations par rapport au cycle de vie des objets, travail délicat et fastidieux, soit le
réalisateur récupère une spécification de traitement entachée d’une complexité dangereuse.
Au contraire, certaines expériences semblent montrer qu’une approche strictement par les objets
tend à simplifier la conception des processus et procédures. Concentrée sur les spécifications dans
leur signification dans l’espace du problème, l’approche objet compacte les spécifications dans
leur petit corps, et révèle bien souvent que les procédures administratives se sont inutilement
compliquées. Si cette intuition se confirme, la question sera de savoir si les organisations,
administrations et entreprises, seront prêtes à utiliser la puissance simplificatrice de l’approche
objet.
Pendant le développement, MERISE autorise la modélisation des données parallèlement à celle
des traitements c’est-à-dire qu’il y a concours d’une approche orientée données et d’une autre
orientée traitements. Une telle équivalence n’entre pas dans la perspective objet. L’approche
orientée objet, si on peut dire qu’elle considère indifféremment données et traitements, ne le fait
qu’en tant qu’ils sont propriétés de l’objet. Il ne s’agit donc de la même chose que les traitements
au sens de MERISE.
On constate donc que l’incompatibilité entre les fondements de MERISE et le paradigme orienté
objet ne concerne pas seulement la modélisation, mais aussi l’organisation du développement.

3.2.2 Le Modèle des Objets Naturels

Cette méthode a été élaborée par Paul André BRES de la société CONCIS. Elle enrichit MERISE par
diverses innovations et est supportée par l’outil de conception Tramis (outil de <<bureautique du
concepteur>> doté d’une génération de maquette à partir du modèle conceptuel).
Le modèle des objets Naturels part d’un bon sentiment : faciliter la validation par les utilisateurs.
BRES pense en effet que le classique modèle conceptuel des données reste très abscons pour
permettre une véritable validation par les utilisateurs : cela conduit à introduire dans sa démarche
deux considérations :
Page 9/16
Méthodes orientées objet
 La visibilité : tous les objets repérés par le modélisateur ne concernent pas l’utilisateur, ou, plus
exactement, l’utilisateur ne les perçoit pas tous ;
 La pondération : parmi les objets, l’utilisateur établit des hiérarchies d’importance.
L’utilisateur perçoit l’objet avant tout à travers le comportement de ce dernier. La définition de
l’objet doit donc englober l’aspect comportemental. C’est le principe de l’encapsulation.

Définition
Un objet naturel est une construction synthétique
- qui possède une structure et un comportement,
- qui appartient au champ de perception de l’utilisateur, et
- sur laquelle celui-ci désire effectuer des transactions.
-
Le modélisateur obtient le modèle des Objets Naturels en procédant comme suit :
1. Il réalise le modèle conceptuel des données tel que défini dans MERISE, avec entités et relations
mais avec un formalisme enrichi pour présenter l’héritage et les contraintes d’intégrité
ensembliste.
2. Il surimpose à ce modèle le dessein des Objets Naturels, chacun de ces objets réalisant une
partition composée d’entité et de relations.
Au terme de la seconde étape, aucune entité ni aucune relation ne doit rester en dehors d’un
objet. Les frontières des objets se dessinent de telle manière qu’ils correspondent à une unité de
manipulation naturellement reconnue par l’utilisateur.
Apres cela, le concepteur s’intéresse aux accès d’objet à objet naturellement impliqués par la
vision de l’utilisateur. Cela l’emmène à spécifier des comportements qui s’activeront dans les
transactions. Les accès possibles sont de deux sortes :
- la gestion dynamique (contraire : opacité)
- l’ouverture (contraire : fermeture).
La gestion dynamique autorise un objet (EX : COMMANDE) à créer un objet qui lui est relie (EX :
CLIENT).
L’ouverture est un accès plus faible, elle signifie simplement qu’un objet peut se rattacher à un
autre. Elle porte donc uniquement sur les instances de relations, contrairement à la gestion
dynamique qui permet au même instant la création d’un objet et la liaison à lui.
Le formalisme graphique s’enrichit donc pour représenter :
- les objets naturels, paquets non vides d’entités et de relations logiquement agrégées,
- la gestion dynamique,
- l’ouverture,
- l’héritage.
A cela s’ajoute les règles de constructions que doit vérifier le modèle, et qui jettent les bases d’une
normalisation objet.
Le modèle ainsi construit exprime suffisamment d’informations pour spécifier les interfaces
homme-machine. Tramis/Dialog fournit une maquette à partir de la seule interprétation du
modèle des Objets Naturels. Contrairement aux outils qui fonctionnent à partir d’un modèle des
données classique, la maquette issue de Tramis présente une spécification plus conforme au
besoin :
 d’une part, elle montre non pas des entités mais l’équivalent des vues externes (les Objets
Naturels, unités de manipulation) ;
 d’autre part, elle propose les accès aux voisins, dans le respect des spécifications
d’ouverture/fermeture et de gestion dynamique/opacité c’est-à-dire qu’elle tient compte d’une
sémantique de la navigation, point de départ des habilitations.
La maquette réalise les contraintes d’intégrité. En outre, la maquette enregistre les jeux d’essai
qu’elle récupère d’une version à l’autre. Le concepteur peut retourner le modèle, la nouvelle
maquette générée alors réutilisera le même jeu d’essai.
Page 10/16
Méthodes orientées objet
En conclusion, le modèle des Objets Naturels satisfera les concepteurs familiers de MERISE et
désirant lui adjoindre une plus grande puissance. ils seront servis en cela par les outils Tramis,
souples et faciles à maitriser.

3.2.3 Classes-Relation
Cette méthode proposée par la société SOFTEAM s’appuie sur :
 le modèle entité-relation, d’une part, dans lequel ; l’entité cède le place à la classe, c’est-à-dire
qu’on y adjoint des aspects comportementaux
 la métaphore des machines abstraites d’autre part.
Les machines abstraites représentent les systèmes par analogie à des composants d’un
mécanisme, ce qui offre une approche précise des interactions.
Cette méthode, vue à travers le cycle de développement, procède par raffinements successifs,
manifestement, elle n’offre pas le même découpage rigoureux que OOA. Son souci est d’arriver
rapidement et le plus naturellement possible au langage de programmation l’occurrence C++.
Le modèle classe- relation représente des objets avec :

Page 11/16
Méthodes orientées objet
1. les liens d’objets (classifications <<est un>>) sous-tendant l’héritage.
2. les relations entre objets, à l’instar d’un modèle entité-relation (cardinalités comprises).

La méthode contient à la fois une modélisation graphique et une expression syntaxique, laquelle
apparait comme premier pas vers le code final.

3.3. Les méthodes fondées sur le développement

Plus récemment ont été rendues publiques des méthodes mieux construites, embrassant à peu
près tous les aspects du projet, au point qu’elles abordent de la méthode de modélisation (analyse
et/ou conception) pour justifier l’appellation de méthodes de développement. C’est dans de telles
méthodes au nous pouvons placer nos espoirs pour la maitrise des projets orientés objet.

Page 12/16
Méthodes orientées objet
3.3.1 OMT

OMT est le sigle de Object Modeling Technique, méthode exposée dans l’ouvrage Collectif Object-
Oriented Modeling and Design.

OMT se définit comme une méthode de modélisation orienté objet, c’est-à-dire organisée autour
des concepts du monde réel. Elle s’enrichit de considérations sur la conception technique du
système informatique et s’aventure un peu dans la méthodologie de développement.

3.3.1.1 Les bases théoriques

Les caractéristiques des objets que les auteurs donnent comme centrales sont :

 l’identité : dans le monde réel, un objet simplement existe, mais à l’intérieur d’un langage de
programmation chaque objet a un handle (référence d’objet) unique par lequel il peut être
référencé univoquement.
 la classification : qu’il faut comprendre comme l’abstraction en tant que symétrie de l’instanciation,
c'est-à-dire le fait que les objets se regroupent en classes. Une classe est une abstraction qui décrit
les propriétés importantes du point de vue de l’application et qui ignore le reste.
 le polymorphisme : possibilité pour une opération de se réaliser en comportements différents.
 l’héritage : partage d’attributs et d’operations entre classes établies en hiérarchie.

OMT utilise le terme <<opération>> pour signifier une abstraction de comportement analogue à
travers différentes sortes d’objets. L’implémentation d’une opération est une méthode.

Le vocabulaire OMT distingue deux niveaux – conceptuel et technique – pour les fonctions de la
classe : opération et méthode, mais qu’il n’y a qu’un terme pour les propriétés informatives :
attribut. S’il n’y a qu’un terme, c’est qu’il n’y a qu’une perception.

Deux catégories d’attributs sont distingués : les attributs de base (indépendants) et les attributs
dérivés (dont la valeur se déduit des premiers).

3.3.1.2 Les trois modèles

A travers toutes les phases du projet, coexistent trois modèles reflétant les différents aspects du
système informatique :

 Le modèle objet : structure statique des objets de leur relations. Pour OMT, un lien est une
connexion physique ou conceptuelle entre plusieurs instances, ce qu’on appelle connexion
d’instances. Une association est un groupe de liens ayant la même structure et la même
sémantique. OMT prévoit les relations ternaires et n-aires, ainsi que les relations porteuses. Une
innovation intrigante est la qualification des associations. C’est un procédé de représentation par
lequel on réduit la cardinalité d’une association. Dans l’exemple suivant, une personne peut
appartenir à plusieurs entreprises mais assume une et une seule fonction dans chaque entreprise.
Le point noir au bout de la ligne indique une cardinalité 1, n.

PERSONNE ENTREPRISE

FONCTION

Exemple d’association sans qualification

Page 13/16
Méthodes orientées objet

La cardinalité se lit à l’oppose de l’habitude merisienne, c’est-à-dire près de la cible et non près de
l’origine de l’association considérée uni directionnellement. Dans l’exemple suivant d’une
association qualifiée, le point noir reste du coté de PERSONNE parce que l’entreprise emploie
plusieurs personnes. Par contre, pour une personne et une fonction données, on ne trouvera
qu’une entreprise.

PERSONNE FONCTION ENTREPRISE

Exemple d’association avec qualification

 Le modèle dynamique : description des aspects temporels et dynamiques du système et des objets.
Un évènement est un stimuli externe visible, avec ses réponses. On commence la modélisation
dynamique par l’extraction d’un résumé des séquences d’évènements ; pour chaque objet il faut
établir un diagramme d’états avec les évènements entrants et sortants et qui montre les
interactions entre objets. On n’établit pas d’algorithme, ce qui relève e l’implantation, si
l’évènement n’est pas externe. Ces diagrammes sont essentiels pour les systèmes interactifs,
contrairement aux systèmes statiques comme les Bases de Données. Il faut aussi noter qu’ils ne
sont pas suffisants pour les systèmes temps réel. Un scenario est une séquence type
d’évènements, il permet de décrire les interactions courantes pour l’extraction des évènements et
l’identification des objets cibles. Le suivi des séquences et des états permet d’établir les
diagrammes d’états et de les comparer afin d’obtenir la correspondance évènement-objet.
L’ensemble des diagrammes d’états définit le modèle dynamique
La modélisation dynamique passe par les phases suivantes :
- Préparation des scenarios
- Identification des évènements entre objets
- Préparation d’un suivi d’évènements pour chaque scenario
- Construction du diagramme d’états
- Confrontation des diagrammes pour vérifier la correspondance évènement-objet et
l’homogénéité de l’ensemble
 Le modèle fonctionnel s’intéresse au traitement des données sans tenir compte du séquencement,
des décisions ni de la structure des objets. Il montre les dépendances et les relations entre les
valeurs. Le modèle fonctionnel est représenté par des diagrammes à flot de données où, par
comparaison avec les diagrammes d’état des classes, les traitements correspondent aux activités
et aux actions, et les flots correspondent aux objets et aux valeurs d’attributs.

Les modèles sont traités dans cet ordre de préséance du <<quoi>>, <<quand>>, <<comment>>. On
assiste à un renversement par rapport aux méthodes fonctionnelles puisqu’on s’intéresse aux
objets avant les fonctions. Cela favorise l’évolutivité.
On peut déplorer la faiblesse de OMT en ce qui concerne les aspects organisationnels. La question
<<quand>> doit souvent être complétée par <<où>> et <<qui>>. Un tel manque pénalise
gravement l’application d’OMT à l’information de gestion.
OMT précise la définition du modèle : c’est une abstraction de quelque chose dans le but de la
comprendre avant de la construire ; ce à quoi s’ajoutent les buts particuliers :
 Tester une entité physique avant de la construire ;
 Communiquer avec le client ;
 Visualiser ;
 Réduire la complexité.

Page 14/16
Méthodes orientées objet
Dans OMT chaque modèle se positionne dans deux dimensions :
 La vue du système (objet, dynamique, fonctionnel) ;
 L’étape de développement (analyse, conception, implémentation).

Le modèle objet présente des concepts du monde réel importants pour l’application. Le modèle
dynamique fournit le contrôle, c’est-à-dire l’aspect du système qui décrit les séquences
d’opérations qui surviennent, sans considération pour ce que font ces opérations. Il met en jeu les
notions d’états, d’évènements et de transitions. Le modèle fonctionnel, quant a lui, décrit ce que
le système fait, sans considération pour le « quand ».
Les outils de représentation sont : le modèle objet, avec un formalisme graphique assez poussé ; le
diagramme d’états-transitions ; le diagramme de flux de données.
Sans entrer dans les détails, la figure ci-dessous représente les relations entre les différentes
notions impliquées dans les trois modèles.

OBJET

Structure de données
Opérations
Structure des objets
Valeurs

Modifient dépendent de Agissent sur

Fonctions
évènements
Contraintes (sur valeurs)
contrôle
décisions Appellent, déclenchent
actions

FONCTIONNEL
DYNAMIQUE

3.3.1.3 La méthode de développement

La Méthode OMT suit les étapes suivantes :
Analyse
décrire le but du système et non pas la façon dont il sera réalisé. Il ne faut prendre aucune
décision d’implantation ; préciser le QUOI du système ;

Conception système
définit le découpage du système en sous-systèmes ; à partir des résultats de l’analyse et
dans l’objectif de définir le choix de l’architecture ;
Conception des objets
raffiner les structures de données et les algorithmes en y ajoutant les détails
d’implantation et en tenant compte de l’environnement ;
Page 15/16
Méthodes orientées objet
Implémentation (mise en œuvre)
transcrire le modèle objet définit dans le langage et le système de gestion des données
retenus.

La différence avec l’approche fonctionnelle réside dans le fait que l’on utilise des objets qui
appartiennent au domaine de l’application plutôt que des fonctionnalités ; ce qui garantit une
meilleure évolution du système.

OMT détaille chacune des phases à un niveau suffisant pour organiser un travail d’équipe. Elle
précise surtout les taches à mener sur les trois modèles à chaque phase. Par contre elle n’offre pas
un édifice suffisant pour la maitrise des projets importants.

Page 16/16