Vous êtes sur la page 1sur 19

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