Modélisation 2.

5
Dr. Ing. Mohamed Bécha Kaâniche
Maître-assistant, Département IR

1
Unified Modeling Language

u Langage de modélisation graphique à base de

pictogrammes (représentation graphique schématique) pour
modéliser et concevoir des logiciels orientés objet.

u Une notation standard et extensible utilisé dans le cadre

d’une méthodologie de génie logiciel afin de spécifier,
visualiser, modifier et construire les documents nécessaires
au bon développement d'un logiciel orienté objet .
2
Logiciel ? Génie Logiciel ?

u Logiciel : ensemble d'informations relatives à des traitements

effectués automatiquement par un appareil informatique. Y sont
incluses les instructions de traitement, regroupées sous forme
de programmes, des données et de la documentation.

u Génie Logiciel : branche du génie informatique qui étudie les

méthodes de travail et les bonnes pratiques des ingénieurs
qui développent des logiciels.
3
Génie Logiciel

u Le génie logiciel s'intéresse aux procédures systématiques qui

permettent d'arriver à ce que des logiciels correspondent aux
attentes du client, soient fiables, aient un coût d'entretien
réduit et de bonnes performances tout en respectant les
délais et les coûts de construction.

u C’est aussi l’ensemble des activités de conception et de mise

en œuvre des produits et des procédures tendant à rationaliser
la production du logiciel et son suivi.
4
Méthodologie de Développement

u Développement logiciel : étudier, concevoir, construire,

transformer, mettre au point, maintenir et améliorer
des logiciels.

u Méthodologie de développement : spécifier l’ordre dans

lequel sont effectués les différents travaux de
développement d'un logiciel ainsi que la manière dont ces
travaux se déroulent.
5
Cycle de vie d’un logiciel
Livraison d'une
Tests de validation version Analyse des risques

Tests d'intégration Analyse des besoins

Tests unitaires Spécifications

Conception de
Codage l'architecture
Conception détaillée

6
Historique d’UML

7
UML 2.5
u 14 types de diagrammes permettant de délivrer une documentation
technique sur un logiciel pendant les phases d’analyse, de
spécification et de conception.
u Le nombre de diagrammes utilisés ainsi que leur distributions sur les
étapes du cycle de vie dépendent de la méthodologie de
développement choisie.
u Certaines méthodologies s’axent sur un type particulier de diagramme
(p.ex. la méthodologie « Unified Process » est axé sur les « cas
d’utilisation »).

8
Vues d’UML

Vue d’implémentation Vue Logique

Vue des Cas

d’Utilisation

Vue de déploiement Vue des Processus

9
Diagrammes UML

Diagrammes UML 2.5

Diagrammes Diagrammes de
structurels comportement

10
Diagrammes UML

Diagrammes
structurels

Diagramme de
Diagramme de classes
composants

Diagramme de
Diagramme d’objets
structure composite
Diagramme de Diagramme de
déploiement paquetages

Diagramme de profils 11
Diagrammes UML

Diagrammes UML 2.5

Diagrammes Diagrammes de
structurels comportement

12
Diagrammes UML
Diagrammes de
comportement
Diagramme des cas
Diagramme d’activités
d’utilisation
Diagramme états-
transitions Diagrammes
Diagramme de d’interactions
Diagramme de temps
séquence
Diagramme de Diagramme global
communications d’interaction

13
Vues et Diagrammes UML
Vue d’implémentation:
Diagramme de composants
Diagramme de paquetages
Vue Logique:
Diagramme de classes
Diagramme d’objets
Diagramme de structure
composite

Vue des Cas d’Utilisation:

Diagramme des cas d’utilisation
Diagramme de communication

Vue des Processus:

Vue de déploiement:
Diagramme d’activités
Diagramme de déploiement
Diagramme états-transitions
Diagramme de composants
Diagrammes d’interaction
14
Exemple de Séquence de Création

Diagramme étape du cycle de vie

1. Diagramme de cas d'utilisation
2. Diagramme de communication Analyse & Spécification des
3. Diagramme de composants besoins
4. Diagramme de paquetage
5. Diagrammes de classes / d’objets
6. Diagramme de séquence
7. Diagramme d’activités Conception Architecturale
8. Diagramme états-transitions
9. Diagramme de déploiement

15
Diagramme des Cas d’utilisation

u Diagramme de comportements permettant de

décrire un ensemble d’actions / réactions (Cas
d’utilisation) qu’un sous-système ou un système
(sujet) doit ou peut prendre en compte / induire
en collaborant avec un ou plusieurs utilisateurs
externes au système (Acteur).
u UML 2.5 décrit le diagramme des cas d’utilisation
comme une spécialisation du diagramme des
classes. 16
Diagramme des Cas d’utilisation

u Un diagramme des cas d’utilisation est utilisé pour spécifier:

u Les exigences (externes) d’un sujet: usages requis d’un

système : Qu’est ce qu’est-supposé faire un système ?

u Les fonctionnalités offertes par un sujet : Que peut-faire un

système ?

u Les exigences sur l’environnement du sujet : Comment les

acteurs peuvent interagir avec le système.
17
Diagramme des Cas d’utilisation

u Les cas d’utilisation permettent aux

utilisateurs de structurer leurs besoins ; ils
les obligent à définir la manière dont ils
voudraient interagir avec le système, à
préciser quelles informations ils entendent
échanger et à décrire ce qui doit être fait
pour obtenir le résultat escompté.
18
Diagramme des Cas d’utilisation

19
Diagramme des Cas d’utilisation

u Sujet (subject) : Un sujet (des cas d’utilisation) est le

système en cours d’analyse auquel un ensemble de cas
d’utilisation s’appliquent.
u Le comportement requis d’un sujet est spécifié par un ou
plusieurs cas d’utilisation qui sont à leur tour définis en
fonction des besoins des acteurs.
u Un sujet est représenté par un rectangle avec son nom
dans le coin du haut. Les cas d’utilisations applicables
sont à l’intérieur du rectangle et les acteurs sont en
dehors.
20
Diagramme des Cas d’utilisation

Exemple Stéréotype (>=2.4.1)

21
Diagramme des Cas d’utilisation
Cas d’utilisation applicable à Cas d’utilisation possédés
un sujet par un sujet

22
Diagramme des Cas d’utilisation

u Acteur (actor) : Un acteur est un classificateur de

comportement qui spécifie un rôle joué par une entité
externe interagissant avec un sujet (en échangeant des
signaux et/ou des données)
u Une seule entité peut jouer plusieurs rôles et un rôle
spécifique peut être joué par une ou plusieurs instances.
u Une entité peut être un utilisateur humain ou un autre
système logicielle ou matérielle utilisant les services du
sujet.
23
Diagramme des Cas d’utilisation

On distingue différents types d’acteurs:

u Les acteurs p rincipaux : cette catégorie regroupe les personnes qui utilisent les

fonctions principales du système.

u Les acteurs secondaires : cette catégorie regroupe les personnes qui effectuent

des tâches administratives ou de maintenance.

u Le matériel externe : cette catégorie regroupe les dispositifs matériels
incontourna bles qui font partie du domaine de l’application et qui doivent ê tre
utilisés.
u Les autres systèmes : cette catégorie regroupe les systèmes avec lesquels le

système développé doit interagir.

24
Diagramme des Cas d’utilisation

25
Diagramme des Cas d’utilisation

u Acteur Abstrait

u Acteurs Concrets

26
Diagramme des Cas d’utilisation

27
Diagramme des Cas d’utilisation

u Cas d’utilisation (Use Case) : Un cas d’utilisation spécifie

un comportement d’un sujet en décrivant un ensemble
de séquences d’actions/réactions exécuté par le système
afin d’aboutir à un résultat observable par un ou plusieurs
acteurs.

u Chaque cas d’utilisation décrit une (sous-)fonctionnalité

complète et utile que le sujet offre à ses acteurs.
28
Diagramme des Cas d’utilisation

u Cette fonctionnalité, initiée par un acteur, doit toujours être

terminée pour que le cas d’utilisation termine.
u Elle sera considérée comme terminée si après son exécution,
le sujet se trouve dans un état où aucune autre entrée ou action
n’est attendu.
u Dans ce cas, le cas d’utilisation peut être:
u Initié à nouveau (réitéré).
u Dans un état d’erreur.

29
Diagramme des Cas d’utilisation

u Par convention le nombre total des cas d’utilisation pour un

sujet donné ne doit pas dépasser 20 afin d’éviter une
granularité (niveau de détails) trop fine.

u Pour décrire un cas d’utilisation, il nous faut décrire un

maximum de chemins d’exécutions possibles pour la
séquence d’actions correspondant à ce cas. On étudiera
donc un certain nombre de scénarios d’un cas d’utilisation.
30
Diagramme des Cas d’utilisation

u Un scénario est donc une instance d’un cas d’utilisation. On essaye de

chercher le ou les scénarios nominaux et plusieurs scénarios
alternatifs (qui se terminent de façon normale) ou d’exception (qui se
terminent en échec). Nous aurons donc deux niveaux de description :
u Description générale d’un cas d’utilisation reprenant les divers
chemins pouvant être réunis en un même cas.
u Description des scénarios alternatifs et d’exception les plus
pertinents.

31
Diagramme des Cas d’utilisation

u Exemple : Scénario nominal « Retirer de l’argent ».

a. Le client de la banque s’identifie.
b. Le système lui pose les différents comptes sur lesquels il peut
effectuer un retrait.
c. Le client choisit le compte à débiter et spécifie le montant du retrait.
d. Le système vérifie si le retrait est autorisé, si oui il déduit le montant
du compte et délivre l’argent, sinon il renvoie un message de rejet
de l’opération.

32
Diagramme des Cas d’utilisation

u Les scénarios permettent de mieux comprendre le

fonctionnement du système, en particulier ils sont utiles dans la
description des cas d’erreurs et des cas limites d’utilisation
du système. Ils permettent d’expérimenter les exécutions du
système et sont donc très utiles pour les phases de tests et de
maintenance.
u Un cas d’utilisation peut donner lieu à un ensemble de
scénarios.
33
Diagramme des Cas d’utilisation

34
Diagramme des Cas d’utilisation

u Structuration des cas d’utilisation:

u Relation d’inclusion : formalisée par le stéréotype «include».

u Relation d’extension : formalisée par le stéréotype «extend».

u Relation de généralisation/spécialisation.

35
Diagramme des Cas d’utilisation

u Relation d’inclusion : Lors de la description des cas

d’utilisation, il apparaît qu’il existe des sous ensembles
communs à plusieurs cas d’utilisations, il convient
donc de factoriser ces fonctionnalités en créant de
nouveaux cas d’utilisation qui seront utilisés par les cas
d’utilisation qui les avaient en commun.

36
Diagramme des Cas d’utilisation

u Une autre utilisation de la relation d’inclusion s’impose

lorsqu'un cas d’utilisation large et complexe, nécessite
d’être détailler en plusieurs cas d’utilisation obligatoires.

u On remarque que dans une relation d’inclusion, le cas

d’utilisation de base utilise systématiquement les
enchaînements provenant des cas inclus.

37
Diagramme des Cas d’utilisation

Scanner un Déposer des

article fonds «inclut»
«inclut»

S’authentifier
«inclut» Calculer
Checkout total et «inclut»
Retirer de
taxes
l’argent

«inclut»

Transaction
Payer S’identifier
DAB «inclut»

38
Diagramme des Cas d’utilisation

u Relation d’extension : elle permet d’étendre les interactions et

donc les fonctions décrites par les interactions. Le cas
d’utilisation de base peut fonctionner tout seul, mais il peut
également être complété par un autre, sous certaines
conditions, et uniquement à certains points de son flot
d’événements. On utilise principalement cette relation pour
séparer le comportement optionnel du comportement
obligatoire.
39
Diagramme des Cas d’utilisation

«étend» Consulter Transaction «étend» Consulter

S’enregistrer
l’aide DAB l’aide

Condition : {lien d’aide cliqué}

Point d’extension : Aide sur l’enregistrement

S’enregistrer
Consulter
Points d’extension : l’aide
Aide sur l’enregistrement «étend»

40
Diagramme des Cas d’utilisation

u Relation de généralisation : Cette relation est à prendre

au sens classique de généralisation / spécialisation. La
généralisation peut être vue aussi comme un
polymorphisme de cas.

u Le cas d’utilisation fils hérite les propriétés et le

comportement du père et peut « surcharger » (remplacer)
un certain aspect comportemental.
41
Diagramme des Cas d’utilisation

Authentification
Internaute

S’authentifier Se rappeler de Single Sign-On

moi

Transaction Retrait
DAB d’argent

42
Diagramme des Cas d’utilisation

u UML permet de regrouper des cas d’utilisation dans une

entité appelée « paquetage ». Le regroupement peut se
faire par acteur ou par domaine fonctionnel.

u Un diagramme de cas d’utilisation peut contenir plusieurs

paquetages et des paquetages peuvent être inclus dans
d’autres paquetages.

43
Diagramme des Cas d’utilisation

u Un paquetage permet d’organiser des éléments de

modélisation en groupe. Un paquetage peut contenir des

classes, des cas d’utilisations, des interfaces, etc.

u Le découpage des cas d’utilisation est un découpage

macroscopique et c’est le premier découpage du modèle.

44
Diagramme des Cas d’utilisation

Client

Support

Stock

Dépendance entre paquetages

qui reflète ici l’inclusion des cas
d’utilisation
45