Vous êtes sur la page 1sur 16

8.

ANALYSE ET CONCEPTION
ORIENTEES OBJETS

8.1. INTRODUCTION AUX OBJETS


8.1.1. Encapsulation données traitements
Nous avons vu dans le chapitre précédent les types abstraits permettant le masquage de
l'information. Les objets peuvent être considérés comme des instanciations de types abstraits
en ce sens qu'ils permettent d'encapsuler traitements et données ayant une forte cohésion.

8.1.2. Héritage
Les langages à objets proposent en outre les notions d'héritage (introduit en simula 67)
qui permettent de définir de nouveaux types de données comme extensions de types
précédents. Un type abstrait supportant l'héritage est appelé une classe; les classes sont les
structures de base de tous les langages à objets.
Exemple :
Soit la classe Personne et l'objet Jean Dupont une instance de Personne. Jean Dupont a les
attributs de Personne, à savoir Nom, Prénom, Age . Il possède l'opération attachée à Personne,
imprimer. En langage objet, une opération est appelée méthode. Lors de la création de Jean
Dupont , objet de la classe Personne, les valeurs de ses attributs lui sont affectées ( Dupont,
Jean, 37)
Soit les sous-classes Étudiant et Employé. Ces sous-classes héritent des attributs de
Personne et ont également des attributs qui leur sont propres comme Droits de scolarité pour
étudiant et salaire pour Employé. De même les deux sous-classes héritent de la méthode
imprimer si celle ci n'est pas redéfinie dans chacune des sous classes. Il est en effet possible de
rajouter des nouvelles méthodes dans les sous-classes ou de redéfinir les méthodes définies
dans la sur-classe comme nous le verrons un peu plus loin.

Implémentation en C++
class Personne
{
private
char nom
char prenom
int age
public:
// déclaration des opérations liées à personne et en particulier d'imprimer
}

class Employe: public Personne


{
int salaire
public
// déclaration des opérations liées à Employé comme par exemple calcul des
charges sociales
}

class Etudiant : public Personne


Analyse et Conception objets Anne-Marie Hugues 8 -1
{
int droits
public
// déclaration des opérations liées à Etudiant comme par exemple envoi des
convocations aux examens
}

8.1.3. Héritage multiple


Si on souhaite définir la sous-classe des assistants, elle hérite à la fois de Employé et
d'étudiant car un assistant est inscrit en thèse et fait des cours. Cette notion est supportée par
la plupart des langages à objets actuels.

8.1.4. Aspects syntaxiques


La similarité de traitement entre données et traitements est visible sur la syntaxe d'appel
utilisée en C++. On décrit de la même façon un appel à une méthode d'une classe ou l'accès
au champ d'une structure de cette classe.
Exemple
accès au champ : Jean.age
accès à la méthode: Jean.imprimer

8.1.5. Polymorphisme et typage dynamique


On considère l'exemple suivant.(Schach). On a une classe fichier et trois sous-classes
fichier disque, fichier disquette et fichier bande. La méthode ouvrir doit être redéfinie pour
chacune des 3 sous-classes car il n'est pas équivalent d'ouvrir un fichier disque, disquette ou
bande. On procède alors en définissant une méthode virtuelle dans la classe fichier.
A l'exécution, lors de l'appel
monfichier.ouvrir,
la méthode appropriée sera choisie par le système en fonction du type de l'objet monfichier
Comme cette détermination du typage se fait à l'exécution, on appelle cela typage
dynamique. Comme la méthode ouvrir porte le même nom alors qu'elle recouvre des codes
différents on dit que le langage supporte le polymorphisme.

classe-fichier

méthode virtuelle ouvrir

Classe fichier-disque Classe fichier-bande Classe fichier-disquette


implémentation d'ouvrir implémentation d'ouvrir
implémentation d'ouvrir pour bande pour disquette
pour disque

8.1.6. Généricité
La notion de généricité a été introduite par le langage Ada et récemment introduite en
C++.
Définir une méthode ou une procédure générique permet de décrire une fois pour toutes
un processus qui pourra être ensuite instancié en différentes circonstances.

Analyse et Conception orientées objets Anne-Marie Hugues 1996 8- 2


Exemples en Ada
procedure ECHANGER (X,Y : in out INTEGER) is
T : INTEGER := X;
begin
X := Y;
Y := T;
end ECHANGER;

procedure ECHANGER (X,Y : in out POMME) is


T : POMME := X;
begin
X := Y;
Y := T;
end ECHANGER;

procedure ECHANGER (X,Y : in out POIRE) is


T : POIRE := X;
begin
X := Y;
Y := T;
end ECHANGER;

On remplace cette écriture fastidieuse par celle ci plus pratique:

Déclaration:
generic
type ELEMENT is private;
procedure ECHANGER (X,Y : in out ELEMENT) is
T : ELEMENT := X;
begin
X := Y;
Y := T;
end ECHANGER;

On en fait ensuite 3 instantiations


procedure ECHANGER is new ECHANGER (INTEGER);

procedure ECHANGER is new ECHANGER (POMME);

procedure ECHANGER is new ECHANGER (POIRE);

Autre exemple
generic
type ELEMENT is private;
with function SOMME (X,Y : ELEMENT) return ELEMENT;

package VECTEURS is
type VECTEUR is array (INTEGER range <>) of ELEMENT;
function SOMME (A,B : VECTEUR) return VECTEUR;
function SIGMA (A : VECTEUR) return ELEMENT;
end VECTEURS;

package body VECTEURS is

function SOMME (A,B : VECTEUR) return VECTEUR is


Analyse et Conception objets Anne-Marie Hugues 8 -3
RESULTAT : VECTEUR (A'RANGE);
begin
for I in A'RANGE loop
RESULTAT(I):=SOMME(A(I),B(I));
end loop;
return RESULTAT;
end SOMME;

function SIGMA (A:VECTEUR) return ELEMENT is


TOTAL:ELEMENT:=A(A'FIRST);
begin
for I in A'FIRST + 1.. A'LAST loop
TOTAL(I):=SOMME(TOTAL,A(I));
end loop;
return TOTAL;
end SIGMA;

end VECTEURS;

package VECTEURS_ENTIERS is new


VECTEURS (ELEMENT => INTEGER SOMME => "+");
use VECTEURS_ENTIERS;
V : VECTEUR (1..5) := (10,20,30,40,50);
N : INTEGER := SIGMA (V); -- 150

On utilise les génériques pour


- Étendre l'utilité d'un composant,
- Accroître la flexibilité d'un logiciel
- Accroître la portabilité
- Personnaliser le comportement d'un composant
Exemple:
generic
with procedure ERREUR(MESSAGE:STRING)
is ERREUR_STANDARD;
procedure P;
L'Utilisateur peut proposer sa propre procédure d'affichage des messages
d'erreurs

L'utilisation de génériques permet d'isoler les caractéristiques de la machine ou du système


d'exploitation du composant logiciel lui-même afin de faciliter les opérations de portage.
EXEMPLE:
generic
type FICHIER is private;
with function OPEN (NOM_DE_FICHIER,MODE: STRING)
return FICHIER is <>;
package ...

8.1.7. Cohésion et couplage


Une classe définit un type abstrait ayant une forte cohésion. Le masquage de l'information
se traduit par la notion de "private" vue précédemment. Les méthodes dites publiques
permettent d'invoquer des fonctions d'une classe et d'assurer ainsi un couplage. L'héritage est
une forme de couplage.

Analyse et Conception orientées objets Anne-Marie Hugues 1996 8- 4


Lorsque deux classes sont dites amies (friends) cela signifie que la deuxième a accès à
toutes les parties de la première.

8.1.8. Réutilisation
Le développement de classes et de génériques permet de généraliser les problèmes à
résoudre et facilite ainsi la réutilisation.

8.2. METHODE DE BOOCH


Booch a été l'un des premiers (86) à proposer une méthode de conception orientée objets.
Aujourd'hui cette méthode a évolué et est en cours de fusion avec la méthode OMT définie
plus loin (dans le produit Rational Rose).
On retiendra de la méthode l'aspect itératif et la définition d'un formalisme de conception
repris dans la plupart des méthodes de conception orientées objets qui ont suivi.
Dans cette méthode les phases d'analyse et conception sont étroitement mêlées, les
objets découverts pendant la phase d'analyse étant des candidats pour devenir des classes.
Dans sa première version de la méthode Booch visait Ada comme langage
d'implémentation puis en 91 il publie une version objets incluant l'héritage et proposant une
bibliothèque de classes C++.
Le formalisme proposé dans cette dernière version prend en compte le temps et permet de
suive l'ordonnancement des créations et destructions d'objets ( instances de classes)

8.2.1. Étapes de la méthode


- Définir le problème.
- Développer une stratégie informelle de résolution
- Identifier les objets et leurs attributs
- Identifier les opérations sur les objets.
- Établir les interfaces pour ces opérations.
- Implémenter les objets.
- Éventuellement répéter le processus récursivement

Définition du problème
Définir l'essentiel du problème en une seule phrase grammaticalement correcte
- Après spécifications fonctionnelles
- Exprimer la vue du concepteur
- Être en accord avec la vue client ou utilisateur
- Se concentrer sur ce qui est réellement important, trouver le niveau adéquat
- Ne pas essayer de résoudre le problème
- Éviter les phrases imprécises

Analyse et clarification des données.


Analyse des implications du problème
- Rassembler toute l'information pertinente, la mettre en forme, répondre aux
questions
- Décrire les contraintes, les traitements d'erreur, l'interface utilisateur
- Doit permettre d'évaluer l'effort de choisir les outils, les composants existants

Développement d'une stratégie informelle


Exprimer les éléments essentiels de la solution en un seul paragraphe grammaticalement
correct
Ceci constitue une étape essentielle de la conception orientée objet selon Booch-
Analyse et Conception objets Anne-Marie Hugues 8 -5
Il est important de s'exprimer dans un langage compris de tous
Ceci est censé prendre environ 4 heures
Il est important que ce travail soit revu et approuvé.

Formalisation de la stratégie: Identification des objets


- Souligner les formes nominales
- Éliminer les noms qui ne font pas partie du domaine de la solution
- Reléguer dans les opérations les noms représentant des activités
exemple: la mise à jour est effectuée
- Associer aux objets des identificateurs corrects (conventions de nommage)
- Regrouper les objets de même types
- Associer des attributs aux objets et aux types
Exemple: CAPTEURS sont lus tous les 100 millisecondes
existe pour pression, température

Formalisation de la stratégie: Identification des opérations,


- Souligner les formes verbales
- Associer un identificateur à chaque opération
- Associer à chaque opération un objet ou un type
- Déterminer sur quel objet une opération est réalisée
Exemple:
METTRE un ARBRE sur la PILE
opération: METTRE
opère sur: PILE (pas ARBRE)
- Associer des attributs aux opérations en examinant les formes adverbiales
Exemple
Déclencher alarme quand les valeurs sont trop hautes
- En particulier faire attention aux conditions de synchronisation
- Identifier les relations entre opérations
Exemple
Allouer un buffer à l'ouverture d'un fichier

Regroupement des opérations, des objets et des types,


- Définir les spécifications des types, objets et opérations visibles
- Déterminer les dépendances et l'imbrication des unités

Analyse et clarification de la conception globale

- Examiner les variantes et les changements possibles


- Expliquer les choix de conception
- Donner toutes les indications nécessaires à la réalisation
- Identifier les regroupements possibles, rechercher l'héritage et la généricité

Notations graphiques
Les diagrammes de classes sont à rapprocher du modèle entité relation, on peut
représenter l'héritage, l'instanciation, l'utilisation, les classes peuvent être regroupées en
catégories.
Les diagrammes d'objets montrent l'aspect dynamique (création suppression d'objets,
envois de message entre objets.
Les diagrammes de temps permettent de suivre l'ordonnancement des créations et
suppressions d'objets (seule méthode aujourd'hui à proposer cela)

Analyse et Conception orientées objets Anne-Marie Hugues 1996 8- 6


Les diagrammes de modules et de process permettent de suivre les dépendances entre
module.
Pour plus d'informations sur la méthode on se reportera à Booch 91.
L'exemple ci-après en Ada donne un aperçu des formalismes les plus courants

8.2.2. Exemple (d'après Booch)


COMPTER LES FEUILLES D'UN ARBRE BINAIRE COMPLET
Maintenir une pile des parties d'arbre qui n'ont pas encore été comptées. Initialement
obtenir un arbre et le mettre sur une pile vide; le compteur de feuilles est initialisé à zéro.
Tant que la pile n'est pas vide, enlever un arbre de la pile et l'examiner. Si l'arbre consiste
d'une seule feuille, incrémenter le compteur de feuilles et jeter cet arbre. Sinon, l'arbre
possède deux sous-arbres; séparer l'arbre dans son sous-arbre droit et son sous-arbre
gauche et remettre ces arbres sur la pile. Une fois que la pile est vide, imprimer le compteur
de feuilles.

Formalisation de la stratégie

- Isoler noms et adjectifs


Maintenir une pile des parties d'arbre qui n'ont pas encore été comptées. Initialement
obtenir un arbre et le mettre sur une pile vide; le compteur de feuilles est initialisé à zéro.
Tant que la pile n'est pas vide, enlever un arbre de la pile et l'examiner. Si l'arbre consiste
d'une seule feuille, incrémenter le compteur de feuilles et jeter cet arbre. Sinon, l'arbre
possède deux sous-arbres; séparer l'arbre dans son sous-arbre droit et son sous-arbre
gauche et remettre ces arbres sur la pile. Une fois que la pile est vide, imprimer le compteur
de feuilles.

- Isoler verbes et adverbes


Maintenir une pile des parties d'arbre qui n'ont pas encore été comptées. Initialement
obtenir un arbre et le mettre sur une pile vide; le compteur de feuilles est initialisé à zéro.
Tant que la pile n'est pas vide, enlever un arbre de la pile et l'examiner. Si l'arbre consiste
d'une seule feuille, incrémenter le compteur de feuilles et jeter cet arbre. Sinon, l'arbre
possède deux sous-arbres; séparer l'arbre dans son sous-arbre droit et son sous-arbre
gauche et remettre ces arbres sur la pile. Une fois que la pile est vide, imprimer le compteur
de feuilles.

-Identifier les objets et leurs attributs


COMPTEUR_DE_FEUILLES
PILE
SOUS_ARBRE_GAUCHE, SOUS_ARBRE_DROIT, ARBRE
Note: il y a 3 types d'objets:
- COMPTEUR, PILE et ARBRE

- Identifier les opérations sur les objets


COMPTEUR _DE_FEUILLES
INITIALISER_A_ZERO
INCREMENTER
IMPRIMER
PILE
N_EST_PAS_VIDE
METTRE
PRENDRE
ARBRES
Analyse et Conception objets Anne-Marie Hugues 8 -7
OBTENIR
A_UNE_SEULE_FEUILLE
SEPARER
JETER

Définir la conception graphiquement


PACKAGE_ARBRES

ARBRE_BINAIRE
COMPTER_FEUILLES_SUR_ARBR
OBTENIR

SEPARER

JETER

PACKAGE_PILES

PILE_D_ARBRES

N_EST_PAS_VIDE PACKAGE_COMPTEURS

METTRE COMPTEUR

PRENDRE IMPRIMER

INCREMENTER

INITIALISER

Établir les interfaces (en ada)


package COMPTEURS is

type COMPTEUR is private;


procedure INITIALISER (COMPTE : out COMPTEUR);
procedure INCREMENTER
(COMPTE : in out COMPTEUR);
procedure IMPRIMER(COMPTE : in COMPTEUR);
end COMPTEURS;

with ARBRES;

package PILES is
type PILE_D_ARBRES is private;
function N_EST_PAS_VIDE
(PILE : in PILE_D_ARBRES)
return BOOLEAN;
procedure METTRE
(ARBRE : in ARBRE_BINAIRE;
SUR : in out PILE_D_ARBRES);
procedure PRENDRE
(ARBRE : out ARBRE_BINAIRE;
DE : in out PILE_D_ARBRES);
end PILES;

package ARBRES is

Analyse et Conception orientées objets Anne-Marie Hugues 1996 8- 8


type ARBRE_BINAIRE is private;
procedure OBTENIR(ARBRE : out ARBRE_BINAIRE);
function A_UNE_FEUILLE
(ARBRE: in ARBRE_BINAIRE);return BOOLEAN;
procedure SEPARER
(ARBRE : in out ARBRE_BINAIRE;
EN : out ARBRE_BINAIRE;
ET : out ARBRE_BINAIRE);
procedure JETER (ARBRE :in out ARBRE_BINAIRE) ;
end ARBRES ;

with ARBRES, PILES, COMPTEURS;

procedure COMPTER_FEUILLES_SUR_ARBRE is
COMPTEUR_DE_FEUILLES : COMPTEUR;
PILE : PILE_D_ARBRES;
ARBRE : ARBRE_BINAIRE;
SOUS_ARBRE_DROIT : ARBRE_BINAIRE;
SOUS_ARBRE_GAUCHE : ARBRE_BINAIRE;

begin
OBTENIR (ARBRE);
METTRE (ARBRE, SUR => PILE);
INITIALISER (COMPTEUR_DE_FEUILLES);

while N_EST_PAS_VIDE (PILE) loop


PRENDRE (ARBRE, DE => PILE);
if A_UNE_FEUILLE (ARBRE) then
INCREMENTER
(COMPTEUR_DE_FEUILLE);
JETER (ARBRE);
else
SEPARER (ARBRE,
EN => SOUS_ARBRE_DROIT,
ET =>SOUS_ARBRE_GAUCHE);
METTRE (SOUS_ARBRE_DROIT,
SUR => PILE);
METTRE (SOUS_ARBRE_GAUCHE,
SUR => PILE);
end if;
end loop;
IMPRIMER (COMPTEUR_DE_FEUILLES);
end COMPTER_FEUILLES_SUR_ARBRE;

8.3. METHODE HOOD


Hierachical Object Oriented Design
Cette méthode a été mise au point dans le cadre du projet ESA, et elle a été mise en oeuvre
dans les débuts du projet Hermès. Elle est supportée en particulier par l'outil CONCERTO
qui permet de générer des squelettes de programmes ADA. Elle est essentiellement appliquée
dans l'industrie spatiale pour certains types de logiciels:
logiciels embarqués
logiciels de contrôle
vérifications
Analyse et Conception objets Anne-Marie Hugues 8 -9
simulation
présentant les caractéristiques suivantes
temps réel
fiabilité
distribution (des systèmes et du développement)

Elle va de pair avec le cycle de vie en Z (variante du cycle de vie en V) qui prévoit
l'intégration de sous systèmes. Elle est très liée au langage ADA bien qu'elle puisse aboutir à
un code en C, Pascal ou assembleur. Elle est assimilable à une mise en oeuvre de la méthode
de Booch avec adjonction de deux hiérarchies
hiérarchie d'inclusion
hiérarchie d'utilisation
Elle permet la prise en compte de flots de données et flots d'exception mais non celle de
l'héritage.

8.3.1. Historique

1986: Le projet ESA (européen) vise à définir une méthode de conception


pour ada
pour des applications spatiales avec support de formation

1987: CRI,CISI Ingéniérie, MATRA


HOOD 2.0 Reference Manual

1988:
Projets pilotes
Columbus, Hermes
HOOD 2.2 (ESA)
Premières boites à outils
premiers user's groups,
premiers groupes de travail

1989
HOOD 3.0 ref. manual
HOOD manuel utilisateur

1992 Ateliers de Génie Logiciel supportant HOOD


CONCERTO (SEMA)
ENTREPRISE 2 (SYSECA)
EAST (SFGL) et dans une moindre mesures des outils supportant Ada
De ces outils seul CONCERTO est aujourd'hui très utilisé

8.3.2. HOOD en quelques mots

- Objet: unité de modularité


encapsule données et opérations
encapsule aucun, un ou plusieurs flots de contrôle parallèle.
fournit une interface d'utilisation à ses utilisateurs

Analyse et Conception orientées objets Anne-Marie Hugues 1996 8- 10


- Objets passifs
ils fournissent des opérations séquentielles, le flot de contrôle de l'utilisateur est
transféré à l'opération demandée

- Objets actifs
ils ont un état interne propre
ils ont leur propre comportement
ils fournissent à leurs utilisateurs des opérations "contraintes"
le flot de contrôle de l'utilisateur d'une opération contrainte n'est pas transféré à cette
opération et peut être contraint par l'intervention d'autres flots de contrôle.

- Relation use
Hiérarchie d'utilisation au sens ADA

- Relation d'inclusion (parent enfant)


au sens de l'inclusion d'une procédure dans une autre

8.4. MODELE A TROIS PLANS


Ces méthodes apparues plus tard différencient clairement les phases d'analyse et
conception. Elles reprennent les outils d'analyse vus précédemment et analysent le problème
selon 3 plans
- vue temps contrôle
- vue fonctionnelle
- vue données

On dit encore que chaque modèle est composé de 3 plans orthogonaux

8.4.1. Plan structure


Il exprime l'architecture statique du système; on le représente avec des graphes d'héritage,
des modèles entités relations...

8.4.2. Plan communication


Il exprime les différentes caractéristiques des interactions entre objets, on le représente
avec des diagrammes de flux de données (De Marco), SADT, SSD de Jackson...

8.4.3. Plan comportement


Il exprime les propriétés de comportement dynamique de chaque objet , on le représente
avec des diagrammes de transitions d'états, des réseaux de Pétri, grafcet...

NB: Certains formalismes tels que CCS, CSP, ESTEREL se situent à la frontière entre le
plan communication et comportement.

8.4.4. Méthodes
Plusieurs méthodes relèvent de cette catégorie: OMT, OOA-OOD (Shlaer-Mellor),
Fusion, la méthode implémentée dan l'outil de Rational Rose représentant une fusion des
méthodes Booch et OMT.

Analyse et Conception objets Anne-Marie Hugues 8 -11


La méthode OMT est aujourd'hui la plus utilisée sans doute à cause de sa souplesse, et du
grand nombre d'outils qui l'implémentent. Ses partisans vantent aussi la richesse de son
formalisme qui permet de décrire la plupart des constructions de C++.1
La méthode de Shlaer et Mellor est souvent préférée par les gestionnaires de gros projets
car elle est beaucoup plus stricte et commence par un découpage en sous domaines. La
méthode de Shlaer et Mellor est également présente dans des outils comme Teamwork,
Maestro...

8.5. METHODE OMT


La méthode OMT a été décrite par Rumbaugh en 91. Elle est depuis en constante
évolution. Outre les modèles classiques d'analyse vus précédemment (modèle de classes,
modèle dynamique, modèle fonctionnel), elle fournit un formalisme pour décrire les scenario
d'utilisation qui sont le point de départ de l'analyse. Danns ue version récente de la méthode,
Rumbaugh conseille d'abandonner le formalisme DFD et de le remplacer par un mécanisme
d'assertions permettant de décrire les prédicats d'entrée et de sortie de chaque fonction.
Le plus gros reproche que l'on puisse faire à cette méthode est sans doute le manque de fil
conducteur pour passer de l'analyse à la conception.
C'est une méthode qui se prête bien à la réalisation de petits projets.
Nous décrivons dans les pages qui suivent la réalisation d'un exemple avec la méthode
OMT. L'exemple est tiré de [Rumbaugh91] et traité avec l'outil Paradigm +, il s'agit de
réaliser un guichet bancaire automatique ou pas.

1Ses détracteurs prétendent qu'il est plus simple d'utiliser directement les notations C++

Analyse et Conception orientées objets Anne-Marie Hugues 1996 8- 12


Analyse et Conception objets Anne-Marie Hugues 8 -13
8.6. METHODE OOA-OOD SHLAER ET MELLOR
Cette méthode est très formalisée. Elle distingue un niveau système, un niveau domaine et
un niveau sous système. Elle s'adapte mieux aux grand projets impliquant un grand nombre
d'équipes distinctes.
On y retrouve les 3 niveaux décrits précédemment (objets, dynamique et fonctionnel),
ainsi que deux modèles induits: le modèle de communication entre objets et le modèle
d'accès aux objets.
Les pages suivantes décrivent la réalisation d'un exemple en OOA Shlaer et Mellor,
l'exemple a été traité avec l'outil Teamwork OOA, le sujet est similaire à celui traité en OMT,
il s'agit de modéliser le fonctionnement de comptes bancaires munis de cartes permettant
d'efectuer des retraits.

Analyse et Conception orientées objets Anne-Marie Hugues 1996 8- 14


Analyse et Conception objets Anne-Marie Hugues 8 -15
8.7 REFERENCES
G. BOOCH
INGENIERIE DU LOGICIEL AVEC ADA,
INTEREDITIONS, 1988

G. BOOCH
SOFTWARE COMPONENTS WITH ADA,
BENJAMIN/CUMMINGS, 1987

G BOOCH
Object oriented analysis
Yourdon Press 2ème edition 1991

B. MEYER
CONCEPTION ET PROGRAMMATION PAR OBJETS,
Interéditions 93

SHLAER et MELLOR
Object oriented System Analysis
Modelling the world in data
Yourdon Press 1988

Rumbaugh, Blaha, Premerlani


Object Oriented Modelling and Design
Prentice Hall 1991

Analyse et Conception orientées objets Anne-Marie Hugues 1996 8- 16