03/11/2015
Modélisation Orientée Objet
par UML
ZAKRANI Abdelali
ENSAM – CASABLANCA
Année universitaire 2015-2016
Module: Système d’exploitation et
Programmation orientée objet
Ce module comprend 3 éléments:
1. Modélisation orientée Objet par UML
6 séances de cours (2h) --- S1->S6
5 séances de TD (2h)
2. Programmation orientée objet par C++
6 séances de cours (2h) --- S7->S12
3 séances de TP (3h)
3. Système d’exploitation Linux
6 séances de cours (2h) --- S1->S6
4/5 séances de TP (2h)
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 2
1
03/11/2015
Plan
Introduction
◦ Cycle de vie d’un logiciel
◦ Approche objet
◦ Historique d’UML
Diagrammes de l’UML
Modélisation Fonctionnelle
◦ Diagramme de cas d’utilisation
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 3
Introduction
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 4
2
03/11/2015
Cycle de vie d’un logiciel
◦ Processus (ensemble d’activités) nécessaire au
développement et à la maintenance d’un logiciel
◦ Composé de plusieurs phases autonomes mais
dépendantes (interdépendantes).
◦ Chaque étape se termine par la remise de un ou
plusieurs documents validé conjointement par
l’utilisateur et le développeur.
Relation
MOA-MOE
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 5
Cycle de vie d’un logiciel
La qualité du logiciel dépend des activités de
production (les étapes):
◦ Analyse – Est-ce que le programme va rencontrer les besoins
de l’utilisateur (client)?
◦ Conception– Est-ce que la conception est efficace? Est-ce
que j’ai fait une bonne décomposition et créé une hiérarchie qui
est “lisible” hiérarchie de modules (haut niveau) et fonctions
(bas niveau)? Aie-je choisis le bon design?
◦ Implémentation – Est-ce que le code est solide, bien
documenté et complet?
◦ Tests – Est-ce que les tests sont suffisants?
◦ Maintenance – Changements avec effets secondaires
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 6
3
03/11/2015
Cycle de vie d’un logiciel
Les cinq étapes que nous venons de voir sont souvent
représentés graphiquement comme une chute d’eau;
donc le modèle en cascade:
Analyse
Design
Implémentation
Tests
Maintenance
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 7
Modélisation
Un modèle est “une description complète d’un
système à partir d’une vue particulière”. Un modèle
est une simplification de la réalité.
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 8
4
03/11/2015
Intérêt de la modélisation
Modéliser le processus de développement
permet de
◦ Bien répartir les tâches et d'automatiser certaines d'entre
elles ;
◦ Réduire les coûts et les délais ;
◦ Assurer un bon niveau de qualité et une maintenance
efficace.
Modéliser un système avant sa réalisation permet de
◦ Comprendre le fonctionnement du système ;
◦ Maîtriser sa complexité ;
◦ Assurer sa cohérence ;
◦ Pouvoir communiquer au sein de l'équipe de réalisation.
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 9
Démarches de modélisation pour le
logiciel
Approche fonctionnelle
◦ Approche traditionnelle utilisant des procédures et
des fonctions.
◦ Les grand programmes sont ainsi décomposés en
sous programmes.
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 10
5
03/11/2015
Modélisation par décomposition
fonctionnelle
Approche descendante :
Décomposer la fonction globale jusqu'à obtenir des
fonctions simples à appréhender et donc à programmer.
C'est la fonction qui donne la forme du système
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 11
Critique de l'approche fonctionnelle
Avantages :
◦ Organisée, réfléchie, logique.
◦ Ordonnée, réduit la complexité.
Inconvénients :
◦ Comment assurer l'évolution du logiciel ?
◦ Comment réutiliser les parties déjà développées ?
◦ Comment structurer les données ?
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 12
6
03/11/2015
Approche Objet
1966 : une idée à Oslo
1980 : Smalltalk
1988 : Schlaer/Mellor (OOSA)
Les objets sont des entités autonomes qui collaborent
afin de fournir les fonctionnalités du système
Les objets représentent des entités du monde réel de
l’application
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 13
Objectifs de l’approche Objet
Architecture flexible
Evolution du système
Réutilisation des objets
Etc
De 1989 à 1994
Plus de 50 méthodes d’analyse
et de conception orientées objet
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 14
7
03/11/2015
Unification des langages de
modélisation orientés objets
Méthode = Démarche + Langage
La guerre des méthodes ne fait plus avancer la technologie
des objets méthodes
Recherche d’un langage commun unique
◦ Utilisable par toutes les méthodes
◦ Adapté à toutes les phases de développement
◦ Compatible avec toutes les techniques de réalisation
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 15
Historique de l’UML 2.4.1
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 16
8
03/11/2015
Historique de l’UML (suite)
Basée sur les méthodes de BOOCH, OMT et OOSE
Influencée par les bonnes idées des autres méthodes
Mûrie par le travail en commun
Gamma et al. Harel
HP Fusion
Frameworks, State charts
Description des opérations,
patterns et notes numérotation des messages
Booch
Booch methods Embley
Classes singleton
UML Objets composites
Rumbaugh
OMT Wirfs-Brok
Responsabilités (CRC)
Odell
Jacobson Shlear-Mellor Classification
OOSE Cycle de vie des
objets
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 17
En résumé
UML est langage de modélisation, pas une méthode
UML est un langage de modélisation objet
UML convient pour toutes les méthodes objet
UML est dans le domaine public
UML est le langage standard de
modélisation orientée objet
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 18
9
03/11/2015
Diagrammes UML
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 19
Diagrammes UML
Il existe 2 types de vues du système qui comportent
chacune leurs propres diagrammes :
Les vues statiques:
◦ diagrammes de cas d'utilisation
◦ diagrammes d'objets
◦ diagrammes de classes
◦ diagrammes de composants
◦ diagrammes de déploiement
Les vues dynamiques:
◦ diagrammes de collaboration
◦ diagrammes de séquence
◦ diagrammes d'états-transitions
◦ diagrammes d'activités
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 20
10
03/11/2015
Diagrammes de cas d’utilisation
Formalisés par Ivar Jacobson: Object-Oriented Software
Engineering (Addison-Wesley, 1992)
Expression du comportement du système (actions et de
réactions), selon le point de vue de l’utilisateur
Décrivent le système et les relations entre le système et
l’environnement
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 21
Intérêts des cas d’utilisation
Constituent un moyen de déterminer les besoins d’un
système
Utilisés par les utilisateurs finaux pour exprimer leur
attentes et leur besoins
Permettent d’impliquer les utilisateurs dès les premiers
stades du développement
Constituent une base pour les tests fonctionnels
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 22
11
03/11/2015
Cas d’utilisation
Représentation graphique
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 23
Cas d’utilisation (Exemple)
Diagramme de cas d’utilisation modélisant
une borne d’accès à une banque
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 24
12
03/11/2015
Les acteurs
Un acteur est une personne ou un système qui
interagit avec le système, en échangeant
l’information (en entrée et en sortie)
« actor » Acteur humain
Acteur non-humain
On trouve des acteurs en observant les
utilisateurs directs du système, ceux qui sont
responsables pour sa maintenance, ainsi que les
autres systèmes qui interagissent avec le système.
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 25
Acteurs – Les utilisateurs -
Un acteur représente un rôle joué par un utilisateur qui
interagit avec le système.
La même personne physique peut jouer le rôle de
plusieurs acteurs (vendeur, client).
D’autre part, plusieurs personnes peuvent également
jouer le même rôle, et donc agir comme le même
acteur (tous les clients)
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 26
13
03/11/2015
Acteurs et cas d’utilisation
Les cas d’utilisation représentent le dialogue entre
l’acteur et le système de manière abstraite
Ensemble de scénarios au sein d’une description unique
Les cas d’utilisation doivent être vus comme des classes
de scénarios.
Représentation des scénarios
d’un cas d’utilisation
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 27
Détermination des cas d’utilisation
Quelles sont les tâches de l’acteur?
Quelles informations l’acteur doit-il créer, sauvegarder,
modifier, détruire ou simplement lire?
L’acteur devra-t-il informer le système de changements
externes?
Le système devra-t-il informer l’acteur de conditions
internes au système?
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 28
14
03/11/2015
Fiche de description textuelle d’un
cas d’utilisation
Sommaire Inclut titre, résumé, dates de création et de
d’identification modification,
(obligatoire) version, responsable, acteurs...
Description des Décrit le scénario nominal, les scénarios (ou
scénarios enchaînements) alternatifs, les scénarios (ou
(obligatoire) enchaînements) d’erreur, mais aussi les préconditions
et les postconditions.
Exigences non Ajoute, si c’est pertinent, les informations suivantes :
fonctionnelles fréquence, volumétrie, disponibilité, fiabilité, intégrité,
(optionnel) confidentialité, performances, concurrence, etc.
Précise également les contraintes d’interface
homme-machine comme des règles d’ergonomie, une
charte graphique, etc.
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 29
Relations
Include
Le comportement de B est obligatoire pour réaliser
le comportement de A
Exemple:
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 30
15
03/11/2015
Relations (suite)
Extend
Le comportement de B est optionnel et ne se déclenche
que par une condition dans le comportement de A
Exemple:
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 31
Relations (suite)
Généralisation
Le cas B est une abstraction du cas A
Exemple:
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 32
16
03/11/2015
Relations (Exemple)
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 33
Exercice 1
Choisissez et dessinez les relations entre les cas suivants :
1. Une agence de voyages organise des voyages où l’hébergement se fait en hôtel.
Le client doit disposer d’un taxi quand il arrive à la gare pour se rendre à l’hôtel.
Diagramme incomplet des cas
d’utilisation d’une agence de voyages
2. Certains clients demandent à l’agent de voyages d’établir une facture détaillée.
Cela donne lieu à un nouveau cas d’utilisation appelé « Établir une facture
détaillée ». Comment mettre ce cas en relation avec les cas existants ?
3. Le voyage se fait soit par avion, soit par train. Comment modéliser cela ?
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 34
17
03/11/2015
Solution
1. Relations entre cas d’utilisation et cas
internes
Include
Include
Include
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 35
Solution
2. Relation d’extension
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 36
18
03/11/2015
Solution
3. Relation de généralisation
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 37
Etude d’un Guichet Automatique de
Banque
Cette étude de cas concerne un système simplifié de Guichet Automatique de
Banque (GAB). Le GAB offre les services suivants :
1. Distribution d’argent à tout Porteur de carte de crédit, via un lecteur de
carte et un distributeur de billets.
2. Consultation de solde de compte, dépôt en numéraire et dépôt de
chèques pour les clients porteurs d’une carte de crédit de la banque
adossée au GAB.
N’oubliez pas non plus que :
3. Toutes les transactions sont sécurisées.
4. Il est parfois nécessaire de recharger le distributeur, etc.
À partir de ces quatre phrases, nous allons progressivement :
identifier les acteurs ;
identifier les cas d’utilisation ;
construire un diagramme de cas d’utilisation ;
décrire textuellement les cas d’utilisation ;
compléter les descriptions par des diagrammes dynamiques ;
organiser et structurer les cas d’utilisation.
ENSAM – Casablanca
ZAKRANI / MOO par UML / 15-16 38
19
