Uml 1

Analyse et Conception
Orientées Objet
UML
OFPPT/ EL KASSMI
1
2
Comment modéliser avec UML ?

UML est un langage qui permet de représenter des modèles, mais il ne
définit pas le processus d'élaboration des modèles !
Dans le cadre de la modalisation d’une application informatique, les

auteurs d’UML préconisent d’utiliser une démarche :
 Itérative et incrémentale,
 Guidée par les besoins des utilisateurs du système,
 Centrée sur l'architecture logicielle
D'après les auteurs d'UML, un processus de développement qui possède

ces qualités devrait favoriser la réussite d'un projet.
2013 - 2014 OFPPT/ EL KASSMI

Pourquoi des méthodes ?
3
Rien ne dicte a priori comment modéliser

un système de manière pertinente
• Besoin de méthodologie
Outils
Entreprise Informatiques

Pourquoi des méthodes ?
4
Démarche reproductible pour obtenir des résultats fiables

Construire des modèles à partir d'éléments (concepts)
Possibilité de représenter à partir de formalismes
Mise en œuvre
Démarche qui distingue les étapes du développement dans le cycle de vie du logiciel
Modularité, réduction de la complexité, réutilisabilité, abstraction
Un formalisme de représentation qui facilite la communication, l’organisation
et la vérification
Production de documents (modèles) qui facilitent les retours sur conception
et l’évolution des applications

Atouts
5
Universalité de l’Objet
La notion d’objet, plus proche du monde réel, est compréhensible par tous et
facilite la communication entre tous les intervenants d’un projet.
Omniprésence technique de l’Objet

dans les langages de programmation, les bases de données, les interfaces
graphiques, ... et les méthodes d’analyse et de conception.

Approche fonctionnelle
6
Décomposition fonctionnelle depuis le cahier

des charges jusqu’au sous-programmes

Approche Objet
7
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
8
Architecture Flexible
Evolution du système
Réutilisation des objets
Etc

Unification des méthodes orientées objet
9
Méthode = Processus + Langage
La guerre des méthodes ne fait plus avancer la

technologie des objets
Recherche d’un langage commun unique

Utilisable par toutes les méthodes
Adapté à toutes les phases du développement
Compatible avec toutes les techniques de réalisation

Unification des langages de modélisation orientés objet
10

Unification des langages de modélisation orientés objet
11
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

Résumé
12
En résumé
UML est un 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

Diagrammes UML
OFPPT/ EL KASSMI
13
Qu’est ce que UML
14
la structuration
des objets les
Vue statique Vue composants
implantation logiciels
Diagrammes
classes, objets Diagrammes
composants
les fonctions Vue externe

du système Cas
d’utilisation
Vue Vue
dynamique déploiement
le Diagrammes
comportement collaborations Diagrammes l’architecture
des objets séquences, déploiement physique
états, activités
Concepts utilisables tout au long du projet :
analyse conception implantation
Diagrammes des cas d’utilisation
OFPPT/ EL KASSMI
15
Origine
16
Formalisés par Ivar Jacobson : Object-Oriented

Software Engineering (Addison-Wesley, 1992)
Décrivent le comportement du système (actions

et de réactions), selon le point de vue de
l’utilisateur
Chaque cas d’utilisation décrit le comportement

du système suite à une stimulation externe
Modèle
Acteurs + Cas d’utilisation + Relations

Intérêts
17
Déterminer les besoins fonctionnels du système
Utilisés par les utilisateurs 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

Acteurs
18
Un acteur est une entité externe qui interagit avec

le système (fournir, recevoir, échanger de
l’information)
On trouve les acteurs en observant les utilisateurs

directs du système ainsi que les autres systèmes
qui interagissent avec le système

Acteurs – Les utilisateurs-
19
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)
Plusieurs personnes peuvent également jouer le

même rôle, et donc agir comme le même acteur
(tous les clients)

Cas d’utilisation
20
Notation
Les cas d’utilisations 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’utilisations doivent être vus comme

des classes de scénarios

Détermination des cas d’utilisation
21
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

Relations
22
Include
Le comportement de B est obligatoire pour réaliser le

comportement de A

Relations (suite)
23
Extend
Le comportement de B est optionnel et ne se déclenche que
par une condition dans le comportement de A

Relations (suite)
24
Généralisation:
Le cas B est une abstraction du cas A

Mise en œuvre des cas d’utilisations
25
Identifier la plupart des cas d’utilisations (<20)
Décrire brièvement chaque cas d’utilisation (2 à

3 phrases)
Décrire en détails chaque cas d’utilisation

-Début
-Fin
- Interaction entre acteur et le cas d’utilisation
- Chronologie
- Echange d’informations

Précautions
26
Un cas d’utilisation est une abstraction d’un

ensemble de comportement (Scénarios)
fonctionnellement liés
Un cas d’utilisation est un outil d’analyse et non pas

de conception
Eviter l’utilisation des expressions floues telles que
faible, assez, moyen dans la description d’un cas
d’utilisation

Etude de cas (guichet automatique de banque GAB)
27
On considère le système suivant de gestion d’un GAB :
- le distributeur délivre de l’argent à tout porteur d’une carte de la

banque (autorisation d’un certain montant par le Système
d’Information de la banque) ou d’une carte de crédit (autorisation à
distance par le Système d’Autorisation),
- Pour les clients de la banque, il permet en plus :

 la consultation du solde du compte
 le dépôt d’argent (chèque ou numéraire)
- Toute transaction est sécurisée et nécessite par conséquent une

authentification (code personnel vérifié avec le code enregistré sur la
puce de la carte - la carte est avalée après trois échecs).
- Dans le cas où une carte est avalée par le distributeur, un opérateur de

maintenance se charge de la récupérer. C’est la même personne qui
collecte également les dépôts d’argent et qui recharge le distributeur.
Étape 1 - Identification des acteurs du GAB
28
Quelles sont les entités externes qui interagissent directement avec le GAB ?
tout Porteur de carte . . .

Les clients de la banque porteurs d’une carte de crédit de cette dernière.
le Système d’autorisation global Carte Bancaire, pour les transactions de retrait
le Système d’information de la banque, pour autoriser toutes les transactions effectuées
par un client avec sa carte de la banque, mais également pour accéder au solde des
comptes
Opérateur de maintenance pour le rechargement en billets du
distributeur, la récupération des cartes avalées, etc.
Attention !
le lecteur de carte et le distributeur de billets font partie du GAB ) ce ne
sont pas des acteurs !

Étape 2 - Identification des cas d’utilisation
29
Préparez une liste préliminaire des cas d’utilisation du GAB, par acteur.
Porteur de carte :
Retirer de l’argent.
Client de la banque :
Retirer de l’argent.
Consulter le solde de son compte courant.
Déposer de l’argent (du numéraire ou des chèques).
Opérateur de maintenance :
Recharger le distributeur.
Maintenir l’état opérationnel (récupérer les cartes avalées, récupérer les
chèques déposés, remplacer le ruban de papier, etc.).

Étape 3 - Réalisation de diagrammes de cas d’utilisation
30

Acteurs secondaires
31
Complétez le diagramme de cas d’utilisation préliminaire en

ajoutant les acteurs secondaires.
Un problème se pose pour le cas d’utilisation partagé Retirer de l’argent.

Pour le Porteur de carte non client, il faudra faire appel au Sys.
Auto. (qui se chargera de contacter le SI de la banque du porteur),
Pour un client de la banque, le GAB contactera directement le SI
banque.
Acteurs secondaires
32
Solution : distinguer deux cas d’utilisation pour le retrait d’argent :

Retirer de l’argent
Retirer de l’argent avec une carte de la banque.

Étape 4 - Description textuelle des cas d’utilisation
33
Description du cas d’utilisation RETIRER DE L’ARGENT (pour l’acteur

non client de la banque).
Sommaire d’identification
Titre : Retirer de l’argent
Résumé : ce cas d’utilisation permet à un Porteur de carte, qui n’est pas client
de la banque, de retirer de l’argent, si son crédit hebdomadaire le permet.
Acteurs : Porteur de carte (principal), Système d’autorisation (secondaire).

Pré-Conditions
34
Préconditions
• La caisse du GAB est alimentée (il reste au moins un billet !).

• Aucune carte ne se trouve déjà coincée dans le lecteur.
• La connexion avec le Système d’autorisation est opérationnelle.

Scénario nominal
35
Scénario nominal
1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB.
2. Le GAB vérifie que la carte introduite est bien une carte bancaire.
3. Le GAB demande au Porteur de carte de saisir son code d’identification.
4. Le Porteur de carte saisit son code d’identification.
5. Le GAB compare le code d’identification avec celui qui est codé sur la
puce de la carte.
6. Le GAB demande une autorisation au Système d’autorisation.
7. Le Système d’autorisation donne son accord et indique le solde hebdomadaire.
8. Le GAB demande au Porteur de carte de saisir le montant désiré du retrait.
9. Le Porteur de carte saisit le montant désiré du retrait.
10. Le GAB contrôle le montant demandé par rapport au solde hebdomadaire.
11. Le GAB demande au Porteur de carte s’il veut un ticket.
12. Le Porteur de carte demande un ticket.
13. Le GAB rend sa carte au Porteur de carte.
14. Le Porteur de carte reprend sa carte.
15. Le GAB délivre les billets et un ticket.
16. Le Porteur de carte prend les billets et le ticket.
Scénario nominal
36
2a. Carte illisible ou non valable :

Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se termine en échec.
2b. Carte périmée :
Le GAB avertit le Porteur et confisque la carte ; le cas d’utilisation se termine en échec.
4a. Délai de saisie du code expiré :
Le GAB avertit le porteur et éjecte la carte ; le cas d’utilisation se termine en échec.
4a2. Le Porteur annule la transaction :
Le GAB éjecte la carte ; le cas d’utilisation se termine en échec.
5a. Code d’identification erroné pour la première ou deuxième fois :
5a1. Le GAB enregistre l’échec sur la carte.
5a2. Le GAB avertit le Porteur et le scénario nominal reprend à l’étape 3.
5b. Code d’identification erroné pour la troisième fois :
Le GAB avertit le Porteur et confisque la carte ; le cas d’utilisation se termine en échec.
7a. Transaction refusée par le Système d’autorisation :

Scénario nominal
37
7b. Délai de réponse du Système d’autorisation expiré :

9a. Délai de saisie du montant expiré :
10a. Montant demandé supérieur au solde hebdomadaire :
10a1. Le GAB avertit le Porteur et le scénario nominal reprend à l’étape 8.
10b. Solde hebdomadaire insuffisant :
12a. Le Porteur ne demande pas de ticket :
Le cas d’utilisation continue à l’identique, sauf l’impression du ticket.
14a. Délai de retrait de la carte expiré :
14a1. Le GAB confisque la carte et annule la transaction ;
14a2. Le GAB avertit le Système d’autorisation et le cas d’utilisation se termine en échec
16a. Délai de retrait des billets expiré :
Le GAB confisque les billets et annule la transaction ; le cas d’utilisation se termine en
échec.
1-7a. Coupure réseau avec le Système d’autorisation :
Diagrammes d’interaction
Les scénarios
OFPPT/ EL KASSMI
38
Définition
39
Un scénario est une instance d’un cas

d’utilisation
Chaque cas d’utilisation a un WEB de scénarios
Les scénarios sont modélisés par les diagrammes

d’interaction:
Diagrammes de séquence
Diagrammes de collaboration

Scénarios du cas d’utilisation: Inscription-cours
40
On distingue deux types de scénarios
Scénarios principaux
Cas normaux de fonctionnement du système
Scénarios secondaires
Exceptions des scénarios principaux
Créer un calendrier
Consulter son calendrier
Changer son calendrier

Scénarios et Objets
41
Les objets représentent des entités concrètes

(Physique) ou abstraites (concept)
Notation
Un objet est caractérisé par:
Son état
Son comportement
Son identité

Etat d’un objet
42
L’état d’un objet est représenté par les valeurs

des propriétés de l’objet à un instant donné
L’état évolue au cours du temps
Exemple :
L’objet Cours de l’application SIA
Si nombre d’étudiants inscris>10 => Cours est fermé
Si nombre d’étudiants inscris 3<..<10 => Cours ouvert

Comportement d’un objet
43
Le comportement décrit les actions et les

réactions d’un objet avec les autres objets
Le comportement est déterminé par les

opérations qu’un objet peut réaliser
Exemple :
L’objet Cours de l’application SIA
Ajouter-étudiant
Suprimer-étudiant
Affecter-enseignant

Comportement d’un objet(suite)
44
L’état et le comportement sont liés
L’état est modifié par le comportement
Le comportement dépend de l’état

Identité d’un objet
45
Tout objet possède une identité qui lui est

propre et qui le caractérise
L’identité permet de distinguer tout objet de

façon non ambiguë, indépendamment de l’état
Les langages objets utilisent généralement des

clés pour réaliser un identifiant

Détermination des objets
46
Les objets sont déterminés à partir des cas

d’utilisation et des scénarios (entités manipulées)
Exemples: SIA

Interaction entre Objets
47
Application = société d'objets collaborants
Les objets travaillent en synergie afin de réaliser

les fonctions de l’application
Le comportement global d’une application

repose donc sur la communication entre les
objets qui la composent

Scénarios et Interaction entre Objets
48
Scénario = Interaction entre un sous ensemble

d'objets de l’application
Les scénarios sont modélisés par les diagrammes

d’interaction
Se basent sur l’aspect temporel
Montrent les flots de données

49
Les diagrammes de séquence montrent les

interactions qui surviennent dans une séquence
de temps d’un scénario donné.
Caractéristiques d’un diagramme de séquence:
Dimension verticale qui représente le temps ainsi que la

durée de vie des objets
Dimension horizontale qui représente les différents objets
Les messages échangés entre les objets sont représentés

horizontalement par une ligne fléchée.

Exercices: Diagrammes de séquence
50
Identifier les objets du scénario Créer-calendrier
Donner le diagramme de séquence du scénario

Créer-calendrier.

Diagrammes de séquence (suite)
51
Exemple: Scénario Créer-calendrier

Intérêts des diagrammes de séquence
52
Permettre de mieux comprendre le système
Représenter les différents types d’envoi de

messages (synchrones, asynchrones, time-out, etc.)
D’être utiles dans la description des cas d’erreur

et des cas limites d’utilisation du système
D’être une aide précieuse pour documenter les

méthodes des classes

53
Les diagrammes de collaboration montrent les

interactions et les liens entre les objets
Diagrammes de collaboration vs Diagrammes de

Séquence
Montrent les liens entre les objets

Les flots de données entre les objets.

54
Donner le diagramme de collaboration du

scénario Créer-calendrier en indiquant les flots
de données entre certains objets

Diagrammes de collaboration (suite)
55
Exemple: Scénario créer-calendrier

Diagrammes de classes
OFPPT/ EL KASSMI
56
Préalable
57
Les diagrammes de classes proviennent principalement de OMT de

Rumbaugh et de OOD de Booch
Une classe est une description d’un ensemble d’objets ayant:
Les mêmes propriétés (attributs)

Les mêmes comportements (opérations)
Les mêmes relations avec d’autres objets
Notation

Recherche des classes
58
Examiner et regrouper les objets identifiés à partir

des cas d’utilisation et des scénarios
Une classe doit indiquer un et un seul niveau

d’abstraction
Classe Etudiant dans SIA
Mauvaise conception : la classe Etudiant contient les
informations relatives à l’étudiant et aussi le calendrier de
l’étudiant
Bonne conception: deux classes associées: Etudiant
et Calendrier.

Stéréotype
59
Un stéréotype est un mécanisme qui permet la

classification d’une classe lorsque la sémantique
de base est insuffisante.
 Boundary class
 Entity class
 Controller class
 Exception class
 Surrogate class
 Parameterized class
 Utility class

Stéréotype (suite)
60
Classe << Boundary >>
Modélise la communication entre le système et son

environnement externe
Classes des différentes interfaces du système avec son

environnement (Acteurs)
Exemple: SIA
Classes: Registration form et Billing form

Stéréotype (suite)
61
Classe <<Utility>>
Contient un ensemble de méthodes à accès libre
Ces méthodes n’appartiennent à aucune classe
En général, ces méthodes offrent un ensemble de

fonctionnalités utiles dans plusieurs contextes:
Fonctions mathématiques,
Algorithmes de tri
Algorithmes de recherche,
Etc.

Relations entre classes
62
Trois types de relations:
 Association
 Agrégation
 Généralisation
Les liens entre les objets dans les scénarios sont

des instances des relations reliant les classes
Un lien entre deux objets implique une relation

entre les classes des deux objets

Association
63
Une association est une abstraction des liens qui

existent entre les objets instances des classes
associées

Nom, Rôles, Multiplicité d’une association
64

Associations multiples
65
Deux classes peuvent être liées par plusieurs

associations indépendantes

Contraintes sur une association
66
Une contrainte est une condition sur une

association qui doit être préservée. Elle est
placée entre accolades.

Clé d’une association
67
Une clé permet la sélection d’un sous

ensemble d’objets parmi l’ensemble d’objets
qui participent à une association

Association réflexive
68

Association représentée par une classe
69
Une association peut être représentée par

une classe
Besoin : on veut pour chaque étudiant

mentionner la note obtenue dans un cours
Problème : Où on va placer l’attribut “Note”?

Association représentée par une classe (suite)
70
Solution : Créer une classe pour représenter

l’association
Une seule classe par association

Agrégation
71
Une agrégation est une forme particulière

d’une association dans laquelle une classe
joue un rôle prédominant que l’autre
Une agrégation exprime souvent la relation

« composant-composé »

Indicateurs d’une Agrégation
72
Si l’expression « est un composant » est

utilisée pour décrire la relation
La porte est un composant de la voiture
S’il existe des opérations, s’appliquant sur le
tout, s’appliquent aussi sur les composants
La voiture se déplace, la porte se déplace
S’il existe des attributs dont les valeurs se
propagent à ceux des composants
La voiture est bleue, la porte est bleue
Si la relation est asymétrique
La porte est un composant de la voiture, la voiture n’est
pas un composant de la porte

Agrégation
73
Les parties (les composants) sont séparables de L’agrégat (le tout)
La suppression d’une équipe n’implique pas la suppression des personnes qui

la composent
T itre
0..1
1..1
Destinataire E-Mail Fichier

1..* 0..*
* 0..*
Ici, on exprime qu'un fichier peut être attaché à un email (ou a

1..1 plusieurs, ou même à aucun) et qu'un email peut (ou non)
attacher (contenir une copie) une ou plusieurs fichiers.
0..1
T exte

Composition
74
La composition est un cas particulier d’une agrégation dans laquelle la

vie des composants (élément) est liée à celle de l’agrégat (composé) : si
l’agrégat est détruit (ou déplacé), ses composants le sont aussi.
D’un autre côté, et contrairement à l’agrégation, une instance de

composant ne peut être liée qu’a un seul agrégat.
La composition se représente par un losange noir (plein).

Composition
75
Un document est composé de plusieurs paragraphes, qui, à son tour, est

composé de plusieurs phrases
Remarquer la propagation des opérations (copie, suppression,…)

Agrégation réflexive
76
Une agrégation peut être réflexive

Association vs Agrégation
77
Si les objets des deux classes sont considérés

indépendants => Association
Si les objets des deux classes sont

inséparables => agrégation
L’agrégation entraîne un couplage très fort

entre les objets => effets sur la maintenabilité
de l’application

Navigation d’une Association et d’une Agrégation
78
Dans l’étape d’analyse, une association et une

agrégation sont supposées être bi-directionnelle
Dans l’étape de conception, l’association et

l‘agrégation peuvent être uni-directionnelle
Indicateurs de navigation
Etant un objet de la classe A, est-il nécessaire de

connaître les objets associés de la classe B?
Etant un objet de la classe B, est-il nécessaire de

connaître les objets associés de la classe A?

Navigation d’une Association et d’une Agrégation (suite)
79
Exemple
Si dans l’application, je m’intéresse à chercher tous

les fournisseurs d’un produit particulier
Si dans l’application, je m’intéresse à chercher tous

les produit d’un fournisseur particulier

Navigation d’une Association et d’une Agrégation (suite)
80
Une agrégation ne peut être naviguée que dans le

sens de la classe composante

Généralisation et Spécialisation
81
La généralisation permet la création de super-classes

regroupant les propriétés et les comportements
communs aux sous-classes (factorisation).
La spécialisation permet la création de sous-classes

afin d’ajouter ou modifier certaines propriétés ou
comportements définis dans les super-classes
Elles permettent donc la création d’arborescences de

classes d’abstraction croissante

Généralisation et Spécialisation (suite)
82

83
Factorisation des relations

84
Propriétés de la généralisation: non-réflexive, non-

symétrique et transitive
Généralisation vs Composition
Généralisation = est un: un Windows-avec-

scrolbar est un Windows
Composition = a un: un Windows-avec-scrolbar a un

scrolbar
Généralisation Multiple
85
A utiliser seulement quand c’est nécessaire et avec

précautions!!

Héritage
86
L’héritage est propre aux langages orientés objet
C’est la technique la plus utilisée pour réaliser la

Généralisation
Consommateur en temps de calcul
Problème des Langages ne supportant pas

l’héritage?

Héritage
87
L’héritage est propre aux langages orientés objet
C’est la technique la plus utilisée pour réaliser la

Généralisation
Consommateur en temps de calcul
Problème des Langages ne supportant pas

l’héritage?

Diagrammes d’états-transitions
OFPPT/ EL KASSMI
88
Définition
89
Les diagrammes d’états-transitions sont utilisés pour décrire
les états qu’un objet d’une classe peut prendre au cours de

sa vie
Les événements causant les transitions entre les états

possibles d’un objet
Les actions déclenchées suite à un changement d’états
L’ensemble des états possibles des objets d’une classe constitue l’espace
d’états de cette classe.

Notation
90

Etats et Attributs
91
Les états d’un objet d’une classe peuvent être distingués par les valeurs de
certains attributs de l’objet

Etats et Liens
92
Les états d’un objet d’une classe peuvent être distingués par l’existence de
certains liens avec d’autres objets

Événements
93
Un événement est une occurrence d’une situation

particulière dans le domaine du problème
L’état en cours de l’objet détermine la réaction de

l’objet
Exemples
Ajouter-étudiants dans un cours
Ajouter-cours dans le catalogue

Transitions
94
Une transition est le changement d’états d’un objet

suite à un événement
Le nouveau état peut être le même que le précédent

Actions
95
Une action est une opération exécutée lorsque la

transition est déclenchée:
Atomique: non-interruptible
Rapide: temps d’exécution très court

Activités
96
Une activité est une opération qui prend un temps

non négligeable et qui est exécutée pendant que
l’objet est dans un état donné:
Une activité est associée à un état plutôt qu’à une transition
Une activité peut être interrompue par une transition

Transition automatique
97
Le but d’un état est d’exécuter une activité
Activité achevée => Transition

Actions Entry et Exit
98
Une action du type Entry (resp. Exit) est exécutée

de manière instantanée dès l’entré (resp. sortie)
dans l’état
Ces actions sont indépendantes des transitions

ayant générées l’état

Imbrications des états
99
L’objectif est de simplifier un diagramme d’états

quand le nombre de connexions devient très élevé

Imbrications des états avec un historique
10
0
Le mécanisme d’historique permet de mémoriser le

dernier sous-état visité et le rejoindre lors d’une
transition entrant dans le super-état qui l’englobe

Exemple
101


Uml 1

Transféré par

Informations du document

Titre original

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é ?

Droits d'auteur :

Formats disponibles

Uml 1

Transféré par

Droits d'auteur :

Formats disponibles

Analyse et Conception

Comment modéliser avec UML ?

Dans le cadre de la modalisation d’une application informatique, les

D'après les auteurs d'UML, un processus de développement qui possède

2013 - 2014 OFPPT/ EL KASSMI

Rien ne dicte a priori comment modéliser

2013 - 2014 OFPPT/ EL KASSMI

Démarche reproductible pour obtenir des résultats fiables

2013 - 2014 OFPPT/ EL KASSMI

Omniprésence technique de l’Objet

2013 - 2014 OFPPT/ EL KASSMI

Décomposition fonctionnelle depuis le cahier

2013 - 2014 OFPPT/ EL KASSMI

1966 une idée à Oslo

2013 - 2014 OFPPT/ EL KASSMI

2013 - 2014 OFPPT/ EL KASSMI

Méthode = Processus + Langage

La guerre des méthodes ne fait plus avancer la

Recherche d’un langage commun unique

2013 - 2014 OFPPT/ EL KASSMI

2013 - 2014 OFPPT/ EL KASSMI

Basée sur les méthodes de BOOCH, OMT et OOSE

2013 - 2014 OFPPT/ EL KASSMI

UML est un langage de modélisation, pas une méthode

UML est le langage standard

2013 - 2014 OFPPT/ EL KASSMI

les fonctions Vue externe

Formalisés par Ivar Jacobson : Object-Oriented

Décrivent le comportement du système (actions

Chaque cas d’utilisation décrit le comportement

2013 - 2014 OFPPT/ EL KASSMI

Déterminer les besoins fonctionnels du système

Utilisés par les utilisateurs pour exprimer leur

Permettent d’impliquer les utilisateurs dès les

Constituent une base pour les tests fonctionnels

2013 - 2014 OFPPT/ EL KASSMI

Un acteur est une entité externe qui interagit avec

On trouve les acteurs en observant les utilisateurs

2013 - 2014 OFPPT/ EL KASSMI

Un acteur représente un rôle joué par un

La même personne physique peut jouer le rôle de

Plusieurs personnes peuvent également jouer le

2013 - 2014 OFPPT/ EL KASSMI

Les cas d’utilisations représentent le dialogue

Ensemble de scénarios au sein d’une description

Les cas d’utilisations doivent être vus comme

2013 - 2014 OFPPT/ EL KASSMI

Quelles sont les tâches de l’acteur ?

Quelles informations l’acteur doit-il créer,

Le système devra-t-il informer l’acteur de

2013 - 2014 OFPPT/ EL KASSMI

Le comportement de B est obligatoire pour réaliser le

2013 - 2014 OFPPT/ EL KASSMI

2013 - 2014 OFPPT/ EL KASSMI

2013 - 2014 OFPPT/ EL KASSMI

Identifier la plupart des cas d’utilisations (<20)

Décrire brièvement chaque cas d’utilisation (2 à

Décrire en détails chaque cas d’utilisation

2013 - 2014 OFPPT/ EL KASSMI

Un cas d’utilisation est une abstraction d’un

Un cas d’utilisation est un outil d’analyse et non pas

2013 - 2014 OFPPT/ EL KASSMI

On considère le système suivant de gestion d’un GAB :