IFT6803:

Génie logiciel du
commerce électronique

Chapitre 2: Analyse orientée objet

Section 1: Introduction au paradigme objet et
à UML

Julie Vachon,
Hiver 2003
 Sommaire
Chapitre 2, Section 1
“Introduction au paradigme objet et à UML”

2.1.1 Vers une approche orientée objet…

2.1.2 Introduction à UML
2.1.3 Rappel de quelques concepts objets

Chap.2, Sect.1, p.2

 2.1.1 Vers une approche orientée
objet…
Approche à saveur
« fonctionnelle » dfd-0
F0
(procédures & routines, types de
données abstraits, DFD etc.) … Données AB

 Approche logique, dfd-1 F2

cohérente, intuitive F1
F3
 « Diviser pour régner »
 Séparation des données et dfd-2
des traitements F5 F6
F8
 Conception par F4 F7
décomposition et
factorisation respectives des Données A Données B
données et traitements.

Chap.2, Sect.1, p.3

 Vers une approche orientée objet…
Approche « orientée
objet » Objet C
Données +
UML
Traitements
 Approche un peu moins
Objet A
intuitive Données +
 Penser en termes d’objets Traitements
msg
qui s’envoient des messages
 Encapsulation des données msg
et leurs traitements dans une Objet B
Données +
même unité. Traitements

Chap.2, Sect.1, p.4

 Vers une approche orientée objet…

Tel que vu dans la phase de conception, la modularisation

doit tendre vers
 Minimisationdu couplage
 Maximisation la cohésion

Qualités qui facilitent la maintenance du système.

L’approche orientée objet favorise un bon design

 Encapsulation des données et des traitements (cohésion
forte – favorise cohésion fonctionnelle)
 Masquage d’information (couplage faible – limité au
couplage par les données)
 Héritage (généralisation et réutilisation)

Chap.2, Sect.1, p.5

 Vers une approche orientée objet…
L’approche objet d’hier à aujourd’hui

Les concepts objet sont stables et éprouvés (issus du terrain)

 1967: Simula, implémente le concept de type abstrait de

données (à l'aide de classes).
 1976: Smalltalk implémente les concepts fondateurs de
l'approche objet (encapsulation, agrégation , héritage) à
l'aide de : classes, associations entre classes, hiérarchies de
classes, messages entre objets, etc.
 1980: 1er compilateur C++, normalisé par l'ANSI.

 Ensuite: de nombreux langages orientés objets académiques

ont étayé les concepts objets : Eiffel, Objective C, Loops...
Chap.2, Sect.1, p.6
 Vers une approche orientée objet…
Pour exploiter les concepts de l’approche orientée
objet lors de l’analyse et de la conception…
 Définirun langage (syntaxe et sémantique) pour exprimer les
concepts objet qu’on utilise, afin de pouvoir
 Représenter concepts abstraits (ex. graphiquement)
 Limiter ambiguïtés (langage commun)
 Faciliter l’analyse (modèle pour comparaison et évaluation de solutions)
 Guider la conception et l’implémentation (développement de types abstraits de
données)
 Définir une démarche d’analyse et de conception objet pour:
 Éviter de retomber dans une analyse fonctionnelle.
 Définir des vues qui permettent de couvrir tous les aspects d’un
système avec concepts objets.
Chap.2, Sect.1, p.7
 Vers une approche orientée objet…
Besoin d’une méthode de développement
orientée objet

MÉTHODE
=
concepts +
notation +
processus de développement

Chap.2, Sect.1, p.8

 2.1.2 Introduction à UML
Méthodes existantes
 Les premières méthodes d'analyse (années 70)
 Découpe cartésienne (fonctionnelle et hiérarchique)
 Exemples:
 Méthode structurée (DFD, dictionnaire de données, etc.)
 Méthode de Jackson et programmation structurée
 L'approche systémique (années 80)
 Modélisation des données + modélisation des traitements
 Exemples: Merise, Axial, IE, etc.
 L'émergence des méthodes objet (1990-1995)
 Plusde 50 méthodes objet sont apparues durant cette période
 Exemples: Booch, Classe-Relation, Fusion, HOOD, OMT, OOA,
OOD, OOM, OOSE…

-- Aucune méthode ne s'est réellement imposée. --

Chap.2, Sect.1, p.9
 Introduction UML
Les premiers consensus (1995)
 OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un
système
 Issue du centre de R&D de General Electric.
 Notation graphique riche et lisible.
 A inspiré: diagrammes de classes…
 OOD (Grady Booch) : vues logiques et physiques du système
 Définie pour le DOD, afin de rationaliser de développement d'applications ADA,
puis C++.
 Ne couvre pas la phase d'analyse dans ses 1ères versions (préconise SADT).
 Introduit le concept de package (élément d'organisation des modèles).
 A inspiré: diagrammes de composants, de déploiement, de collaboration…
 OOSE (Ivar Jacobson) : couvre tout le cycle de développement
 Issue d'un centre de développement d'Ericsson, en Suède.
 La méthodologie repose sur l'analyse des besoins des utilisateurs.
 A inspiré: diagramme de cas d’utilisation…

Chap.2, Sect.1, p.10

 Introduction UML
Fusion et synthèse de méthodes dominantes:
UML (Unified Modeling Language)
UML 1.1 (Septembre 97)
Standardisation
par l ’OMG UML 1.0 (Janvier 97)

UML 0.9 (96)

UML 0.8 (95)

Autres méthodes Booch OMT OOSE Partenaires industriels

Chap.2, Sect.1, p.11

 Introduction UML
UML c’est …

 une norme (OMG)

 un langage de modélisation pseudo-formel
(rigoureux) visuel
 Propose des éléments de modélisation (classes,
association, agrégation, package, etc.)
 Définit (informellement) la sémantique de ces éléments
 Propose une représentation graphique de ces
éléments

Chap.2, Sect.1, p.12

 Introduction UML
UML c’est …
 Un support de communication performant, qui
facilite la représentation et la compréhension de
solutions objets:
 Notation graphique: permet d'exprimer visuellement une solution
objet, ce qui facilite la comparaison et l'évaluation de solutions.
 Notation rigoureuse: limite les ambiguïtés et les
incompréhensions.
 Notation abstraite: son indépendance par rapport aux langages
de programmation, aux domaines d'application et aux processus,
en font un langage universel.

UML permet aux concepteurs de parler un langage

commun, normalisé et accessible.
Chap.2, Sect.1, p.13
 Introduction UML
UML c’est …
 Un cadre d’analyse objet
 proposant différents types de diagrammes pouvant être
regroupés pour offrir différentes vues du système.
 où l’analyse et la conception se fait graduellement par
l’élaboration des modèles:
 pas de barrière stricte entre analyse et conception.
 les modèles d'analyse et de conception ne diffèrent que par
leur niveau d’abstraction (ajout de détails)
 approprié pour une approche de développement incrémentale
et itérative.
 Ajout de diagrammes, raffinement, construction de prototype
Chap.2, Sect.1, p.14
 Introduction UML
UML c’est…
en BREF
Un langage de modélisation visuelle qui permet
de
 Spécifier, visualiser et comprendre un problème
 Capturer, communiquer et utiliser des connaissances
pour la résolution du problème
 Spécifier, visualiser sous différent angles et construire
la solution du problème
 Documenter la solution.

Chap.2, Sect.1, p.15

 Introduction UML
Diagrammes UML et vues
Le modèle UML d’un système peut être étudié sous différentes perspectives
appelées « vues ».
 Modèle UML = ensemble de diagrammes décrivant le système développé.
 Vue = angle particulier sous lequel un participant au développement voit le
système. Combinaison de diagrammes intéressant un participant.

structure implémentation

Utilisateur

comportement environnement

Chap.2, Sect.1, p.16

 Introduction UML
Les vues de UML
 Vue utilisateur:
 Définit les buts et objectifs des clients du système.
 Définit les besoins (contraintes) requis par la solution
 Vue unificatrice des autres vues en ce sens qu’elle sert de référence à
leur validation.
 Vue structurelle
 Décrit les aspects statiques, représentant la structure du problème.
 Identification des éléments du domaine (classes, attributs, packages, etc.)
et des relations (association, compositions, dépendance, etc.) entre eux.
 Vue comportementale
 Décrit les aspects dynamiques, du comportement du problème et de sa
solution
 Spécifie les interactions et collaborations entre éléments de la solution.
 Montre la décomposition du système en termes de processus,
d’interactions entre processus, de synchronisation et de communication
entre activités.

Chap.2, Sect.1, p.17

 Introduction UML
Les vues de UML
 Vue implémentation
 Décrit les aspects de structure et de comportement de la solution.
 Description de la réalisation, de l’organisation en composants, des
contraintes de développement, etc.
 Vue environnementale
 Décrit les aspects de structure et de comportement du domaine dans
lequel la solution est réalisée.
 Décrit les ressources matérielles (disposition, nature, performance, etc.)
et comment elles sont utilisées par le logiciel.

Chap.2, Sect.1, p.18

 Introduction UML
Les diagrammes de UML
Deux grandes catégories de diagrammes

 Diagrammes décrivant les aspects statiques: structures

et relations.
 Diagramme de classes: décrit les données du système (structure,
relations, contraintes, qualification, rôle,...)
 Diagramme d’objets: diagramme de classes instancié. Utilisé pour
illustrer un exemple particulier.
 Diagramme de composants: montre l'architecture physique du
matériel et l'affectation des objets aux différents composants de
cette architecture.
 Diagramme de déploiement: montre la configuration des différents
composants à l'exécution. Distribution des composants sur le
nœuds…
Chap.2, Sect.1, p.19
 Introduction UML
Les diagrammes de UML
Deux grandes catégories de diagrammes

 Diagrammes décrivant les aspects dynamiques:

comportement, collaboration, responsabilités, etc.
 Diagramme de cas d’utilisation: montre à un haut niveau
d'abstraction une collection de cas d'utilisation caractérisant le
comportement de tout le système.
 Diagramme de séquence: montre l'échange de messages entre
objets en fonction du temps.
 Diagramme de collaboration: s'intéresse à la structure de
collaboration entre les objets (séquence, itération, concurrence,...).
 Diagramme d’états: permet de décrire le comportement dynamique
d'un objet (changements d’états)
 Diagramme d’activités: montre l'ensemble des traitements associés
à une classe, une opération de classe ou à un cas d'utilisation
(workflow).
Chap.2, Sect.1, p.20
 Introduction UML
Diagrammes UML et vues
Diagramme de
Diagramme cas d’utilisation
de classes Diagramme de
composants
Diagramme
d’objets structure implémentation

Utilisateur
Diagramme de
collaboration comportement environnement

Diagramme de
séquence Diagramme de
Diagramme déploiement
Diagramme d’activités
d’états
Chap.2, Sect.1, p.21
 Introduction UML
UML ce N’est toutefois PAS
une méthode standardisée de développement:
c’est une NOTATION.
 Le choix du processus de développement dépend des
contraintes et du domaine de l’application. Les auteurs de
UML suggèrent l’utilisation d’un processus de nature
incrémentale, itérative et dirigé par les besoins de
l’utilisateur.
 Des processus de développement et des techniques de
design, basés sur l’utilisation d’UML, ont été proposés :
 RUP: Rational Unified Process (pdf ici)
 2TUP: 2 Tracks Unified Process
 Design patterns
 Etc.

Chap.2, Sect.1, p.22

 Introduction UML
Élaboration des vues et diagrammes pendant le
cycle de développement

Comment développer un système avec UML ?

On préconise une démarche itérative et incrémentale…

A chaque itération, on verra à :

 Compléter le modèle par de nouveaux diagrammes.

 Raffiner les diagrammes déjà développés pour graduellement
réduire leur degré d’abstraction.
 Développer des prototypes.
 Valider le système par rapport aux cas d’utilisation spécifiés.

… et ce, depuis l’analyse jusqu’à l’implémentation

Chap.2, Sect.1, p.23

 Introduction UML
Élaboration des vues et diagrammes
pendant l’analyse et la conception
 Phase d’analyse:
 Vues utilisateur, structurelle et comportementale.
 Accent mis sur diagrammes: cas d’utilisation, classes, séquence,
états.
 Phase de conception
 Conception détaillée:
 Révision de la vue utilisateur
 Raffinement de vues structurelle et comportementale
 Anticipation de la vue implémentation.
 Accent mis sur diagrammes: séquence, collaboration, états, activités,
cas d’utilisation et classes. ( … diagramme de packages)
 Conception architecturale:
 Vues implémentation et environnementale.
 Accent mis sur diagrammes: composants, déploiement.
Chap.2, Sect.1, p.24
 Introduction UML
Références
 Documentation sur UML:
[Link]
 Rational Unified Process: « Best practices for Software Development
teams ». (pdf ici)
 Quelques outils CASE supportant UML:
 Commerciaux : Rational Rose, Together, MagicDraw, Rhapsody,
Objecteering/UML, Describe, UML Studio
 Gratuits: Poseidon, ArgoUML, ClassBuilder
 Disponible au DIRO: Rational Rose
 Se connecter à une machine linux.
 Taper « inclure rose ».
 Démarrer à l’aide de la commande « rose & ».

Chap.2, Sect.1, p.25

 2.1.3 Rappel de quelques concepts
objets

Adrien_le_chat_
de_PierreTremb
 Objet lay_NAS_99999
9999
 Caractéristiques
 Un état
 Poil gris-vert, yeux bruns, heureux, nommé_Adrien.
 Un comportement
 miauler, courir, sauter, manger.
 Identité
 Adrien_le_chat_de_PierreTremblay_NAS_999999999
 N.b. Deux objets peuvent être égaux mais ne sont jamais
identiques.
Chap.2, Sect.1, p.26
 Rappel de quelques concepts objets

 Classe Classe Chat

 Description générale d’un ensemble d’objets
 Attributs (état)
 Opérations (comportements)
 Moule (template) général sur lequel on crée des objets du même
type.
 Partie publique: interface. Partie cachée: implémentation
 Instance (objet) = objet crée sur le modèle de la classe. Le chat
Adrien est une instance de la classe Chat.

Chap.2, Sect.1, p.27

 Rappel de quelques concepts objets

 Héritage
 Relation
entre deux classe.
Classe Félin
 Sémantique de l’héritage
 Enrichissement
 Substitution
 Type d’héritage
 Simple (hiérarchie)
 Multiple (possibilité de conflits…) Classe Chat

Chap.2, Sect.1, p.28

 Rappel de quelques concepts objets

 Message
 Communication entre deux objets
 Objet serveur
 Nom de l’opération
 Arguments et paramètre de sorties.

roger.fait_le_beau()
roger

Chap.2, Sect.1, p.29

 Rappel de quelques concepts objets

 Polymorphisme et liaison dynamique

 Aptitude d'un même message à déclencher des
opérations différentes, selon le type dynamique (type
réel) de l'objet auquel il est destiné.

Surcharge
 Dans une classe, un même nom est employé pour
définir deux opérations (ou attributs) de signatures
différentes.
Chap.2, Sect.1, p.30