Uml Ensam 2015-2016

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++
 3 séances de TP (3h)
3. Système d’exploitation Linux
 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
Introduction
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

 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
3
03/11/2015

 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
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é.
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.
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.
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
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 ?
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
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
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
Historique de l’UML 2.4.1
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
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
9
03/11/2015
Diagrammes UML
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
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
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
11
03/11/2015
Cas d’utilisation
Représentation graphique
Cas d’utilisation (Exemple)

Diagramme de cas d’utilisation modélisant
une borne d’accès à une banque
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.
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)
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
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?
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.
Relations
 Include
Le comportement de B est obligatoire pour réaliser

le comportement de A
Exemple:
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:
Relations (suite)
 Généralisation
Le cas B est une abstraction du cas A
Exemple:
16
03/11/2015
Relations (Exemple)
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 ?
17
03/11/2015
Solution
1. Relations entre cas d’utilisation et cas
internes
Include
Include
Include
Solution
2. Relation d’extension
18
03/11/2015
Solution
3. Relation de généralisation
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.
19

Uml Ensam 2015-2016

Transféré par

Informations du document

Description :

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Uml Ensam 2015-2016

Transféré par

Description :

Droits d'auteur :

Formats disponibles

03/11/2015

Modélisation Orientée Objet

Module: Système d’exploitation et

Cycle de vie d’un logiciel

Cycle de vie d’un logiciel

Cycle de vie d’un logiciel

 Modéliser un système avant sa réalisation permet de

Démarches de modélisation pour le

Modélisation par décomposition

Critique de l'approche fonctionnelle

Objectifs de l’approche Objet

Plus de 50 méthodes d’analyse

Unification des langages de

 Recherche d’un langage commun unique

Historique de l’UML 2.4.1

Historique de l’UML (suite)

UML est le langage standard de

Diagrammes de cas d’utilisation

 Formalisés par Ivar Jacobson: Object-Oriented Software

Intérêts des cas d’utilisation

 Constituent un moyen de déterminer les besoins d’un

Cas d’utilisation (Exemple)

« actor » Acteur humain

 On trouve des acteurs en observant les

Acteurs – Les utilisateurs -

Acteurs et cas d’utilisation

Détermination des cas d’utilisation

Fiche de description textuelle d’un

Description des Décrit le scénario nominal, les scénarios (ou

Le comportement de B est obligatoire pour réaliser

Diagramme incomplet des cas

2. Certains clients demandent à l’agent de voyages d’établir une facture détaillée.

Etude d’un Guichet Automatique de

Centres d'intérêt liés

Vous aimerez peut-être aussi