Analyse et conception orientée

objet
Jamal BAKKAS
Université Cadi Ayyad
Ecole supérieur de Technologie-Safi

Jamal BAKKAS
Analyse et conception orientée objet

• Approche fonctionnelle : la modélisation est réalisée à partir

de fonctions que doit réaliser le système.

• Approche orientée objet : on identifie les objets manipulés

par le système, avec leurs états et leurs comportements.

Jamal BAKKAS
Approche objet
• L’approche orientée objet considère le logiciel comme une collection d’objets dissociés
et identifiés par des propriétés et des comportements.
• Les fonctionnalités du logiciel résultent de l’interaction entre les différents objets qui le
constituent.
• Se base sur le paradigme Objet (de la programmation OO) qui rassemble les données
et les traitements au sein d’un unique concept.
• Avantages
 regrouper ce qui a été séparé,
 construire le complexe à partir de l’élémentaire,
 intégrer statiquement et dynamiquement les constituants d’un système.

Jamal BAKKAS
Approche objet : Historique
• L’idée est connue depuis 1976
• Programmation orientée objet : 1980, version industrielle de SmallTalk
• Langages de programmation : Ada, C++, Java
• Début des années 90: la programmation par objets prend de l’importance  la
nécessité d’une méthode qui lui soit adaptée devient évidente.
• Plus de cinquante méthodes apparaissent entre 1990 et 1995 (Booch, Classe-
Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE, etc.) mais aucune ne
parvient à s’imposer.
• En 1994, le consensus se fait autour de trois méthodes « the Amigos » :
 OMT de James Rumbaugh (General Electric) fournit une représentation
graphique des aspects statique, dynamique et fonctionnel d’un système ;
 OOD de Grady Booch, définie pour le Department of Defense, introduit le
concept de paquetage (package) ;
 OOSE d’Ivar Jacobson (Ericsson) fonde l’analyse sur la description des
besoins des utilisateurs (cas d’utilisation, ou use cases).
Jamal BAKKAS
UML :Unified Modeling Language
UML 2

Soumission OMG UML 1.3 juin 1999

UML 1.2 juin 1998

Standardisation OMG
Soumission OMG UML 1.1 Novembre 1997
Septembre 1997
Soumission OMG
UML 1.0
Janvier 1997
OOPSLA ‘ 96 UML 0.9
Juin 1996

OOPSLA ‘ 95 Méthode Unifiée 0.8 Octobre 1995

Booch ’93 OMT-2

Autres méthodes Booch ’91 OMT-1 OOSE Partenaires

Jamal BAKKAS
Historique: Il était une fois.. UML
 Ces trois méthodes se mirent d’accord pour définir un outil commun qui
fédérerait leurs apports respectifs.
 UML (Unified Modeling Language) est né de cet effort de convergence:
 L’adjectif Unified est là pour marquer qu’UML unifie, et donc remplace.
 Langage est pour dire que UML n’a pas l’ambition d’être exactement une
méthode : c’est un langage : c'est-à-dire une description normative des
étapes de la modélisation .
 UML est donc un langage qui permet la modélisation d’un système complexe
via un nombre de diagrammes graphiques dont l’enchainement n’est guère
imposé.

Jamal BAKKAS
UML :Unified Modeling Language
 UML :Unified Modeling Language, en français langage unifié pour la modélisation
 Un standard, utilisé par des AGL
 C'est un langage de modélisation objet
 UML convient pour toutes les méthodes objet, mais ce n’est pas une méthode,
 UML se base sur une notation graphique expressive.
 Il permet de modéliser de manière claire et précise la structure et le comportement d'un
système indépendamment de toute méthode ou de tout langage de programmation
 La notation UML repose sur plusieurs diagrammes adaptés au développement logiciel
pour les phases de spécification, conception et implémentation du cycle de vie.

Jamal BAKKAS
UML :Unified Modeling Language
• UML 2.0 comporte treize types de diagrammes représentant autant de vues distinctes
pour représenter des concepts particuliers du logiciel.
• Les diagrammes se repartissent en trois grands niveaux:
Niveau Diagrammes
Fonctionnel Diagramme de Cas d’Utilisation
Structurel diagramme de classes
diagramme d’objets
diagramme de composants
diagramme de déploiement
diagramme de paquetages
diagramme de structures composites
Comportemental diagramme d’activités (Activity diagram)
diagramme d’états-transitions (State machine diagram)
diagrammes d’interaction (Interaction diagram)
diagramme de séquence (Sequence diagram)
diagramme de communication (Communication diagram)
diagramme global d’interaction (Interaction overview diagram)
diagramme de temps (Timing diagram)
Jamal BAKKAS
 Terminologie
• Maître d'ouvrage
• On appelle maître d'ouvrage (parfois maîtrise d'ouvrage, notée MOA) l'entité porteuse du besoin.
• Le maître d'ouvrage est responsable de l'expression fonctionnelle des besoins mais n'a pas
forcément les compétences techniques liées à la réalisation de l'ouvrage.
• Maître d'œuvre
• Le maître d'œuvre (ou maîtrise d'oeuvre, notée MOE) est l'entité retenue par le maître d'ouvrage
pour réaliser l'ouvrage
• La maîtrise d'oeuvre est donc responsable des choix techniques à la réalisation de l'ouvrage
conformément aux exigences de la maîtrise d'ouvrage.

Jamal BAKKAS
Diagramme de cas d’utilisation

Jamal BAKKAS
Diagramme de cas d’utilisation
• La maîtrise d'ouvrage et les utilisateurs ne sont pas des informaticiens.
• Il leur faut donc un moyen simple d'exprimer leurs besoins.
• C'est précisément le rôle des diagrammes de cas d'utilisation qui permettent de recueillir, d'analyser
et d'organiser les besoins, et de recenser les grandes fonctionnalités d'un système.
• Un diagramme de cas d'utilisation capture le comportement d'un système, d'un sous-système, d'une
classe ou d'un composant tel qu'un utilisateur extérieur le voit.
• Il scinde la fonctionnalité du système en unités cohérentes, les cas d'utilisation, ayant un sens pour
les acteurs.
• Les cas d'utilisation permettent d'exprimer le besoin des utilisateurs d'un système, ils sont donc une
vision orientée utilisateur de ce besoin au contraire d'une vision informatique.
• Pour élaborer les cas d'utilisation, il faut se fonder sur des entretiens avec les utilisateurs.

Jamal BAKKAS
Diagramme de cas d’utilisation
• Les diagrammes de cas d’utilisation modélisent à QUOI
sert le système.
• Le système est composé d’objets qui interagissent entre
eux et avec les acteurs pour réaliser ces cas d’utilisation
• Les diagrammes de classes permettent de spécifier QUI
intervient à l’intérieur du système
• Le DC spécifie également quels liens peuvent entretenir
les objets du système

Jamal BAKKAS
Acteur
• Un acteur est l'idéalisation d'un rôle joué par une
personne externe, un processus ou une chose qui
interagit avec un système.
• Il se représente par un petit bonhomme avec son nom
(i.e. son rôle) inscrit dessous.
• Il est également possible de représenter un acteur
sous la forme d'un stéréotypé << actor >>.

Jamal BAKKAS
Acteur
• Un acteur est un rôle joué par une personne externe,
un processus ou une chose qui interagit avec un
système.
• Il se représente par un petit bonhomme avec son nom
(i.e. son rôle) inscrit dessous.
• Il est également possible de représenter un acteur
sous la forme d'un stéréotypé << actor >>.

Jamal BAKKAS
Cas d'utilisation
• Un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de
l'extérieur.
• Un cas d'utilisation modélise un service rendu par le système, sans imposer le mode
de réalisation de ce service.
• Un cas d'utilisation se représente par une ellipse contenant le nom du cas (un verbe à
l'infinitif), et optionnellement, au-dessus du nom, un stéréotype
• Quand un cas n'est pas directement relié à un acteur, il est qualifié de cas d'utilisation
interne.
• Attention également au fait que, les cas d'utilisation ne s'enchaînent pas, puisqu'il n'y
a aucune représentation temporelle dans un diagramme de cas d'utilisation.

Jamal BAKKAS
Représentation d’un cas d’utilisation

Jamal BAKKAS
Relation entre acteur et CU
• Une relation d'association est chemin de communication entre un
acteur et un cas d'utilisation et est représenté un trait continu

■ Acteur principal et acteur secondaire

■ Un acteur est qualifié de principal pour un cas d'utilisation lorsque ce cas rend service à
cet acteur.
■ Les autres acteurs sont alors qualifiés de secondaires.
■ Un cas d'utilisation a au plus un acteur principal.
Jamal BAKKAS
Relations entre cas d'utilisation
• Il existe principalement deux types de relations :
• les dépendances stéréotypées, qui sont explicitées par
un stéréotype (les plus utilisés sont l'inclusion et
l'extension) ;
• la généralisation/spécialisation.

Jamal BAKKAS
Relations entre cas d'utilisation
• Inclusion:
• Un cas A inclut un cas B si le comportement décrit par le cas A inclut le
comportement du cas B :
• le cas A dépend de B. Lorsque A est sollicité, B l'est obligatoirement,
comme une partie de A.
• Cette dépendance est symbolisée par le stéréotype << include >>
• Par exemple :
• l'accès aux informations d'un compte bancaire inclut nécessairement une phase
d'authentification avec un identifiant et un mot de passe

Jamal BAKKAS
Relations entre cas d'utilisation
• Extension:
• On dit qu'un cas d'utilisation A étend un cas d'utilisation B lorsque le cas
d'utilisation A peut être appelé au cours de l'exécution du cas d'utilisation B.
• Exécuter B peut éventuellement entraîner l'exécution de A : contrairement à
l'inclusion, l'extension est optionnelle. Cette dépendance est symbolisée par le
stéréotype << extend >>

Jamal BAKKAS
Relations entre cas d'utilisation
• Relation de généralisation
• Un cas A est une généralisation d'un cas B si B est un cas particulier de A.
• la consultation d'un compte via Internet est un cas particulier de la
consultation

Jamal BAKKAS
Jamal BAKKAS
Relation de généralisation entre acteurs
• Un acteur A est une généralisation d'un acteur B si l'acteur A peut être substitué par l'acteur B.
• Dans ce cas, tous les cas d'utilisation accessibles à A le sont aussi à B, mais l'inverse n'est pas
vrai.
• Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait plein.

Jamal BAKKAS
Exercice d’application
• Un gérant de bibliothèque désire automatiser la gestion des prêts. Il commande un
logiciel permettant aux utilisateurs de connaître les livres présents, d'en réserver
jusqu'à 2.
• L'adhérent peut connaître la liste des livres qu'il a empruntés ou réserves.
• L'adhérent possède un mot de passe qui lui est donné à son inscription.
• L'emprunt est toujours réalisé par les employés qui travaillent à la bibliothèque.
Après avoir identifié l'emprunteur, ils savent si le prêt est possible (nombre max de
prêts = 5), et s'il a la priorité (il est celui qui a réservé le livre).
• Ce sont les employés qui mettent en bibliothèque les livres rendus et les nouveaux
livres. Il leur est possible de connaître l'ensemble des prêts réalisés dans la
bibliothèque

Jamal BAKKAS