Figures – Chapter 4 · Cas d’utilisation 13 Ensemble de séquences d’actions réalisées par...

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

5ÈME PARTIE – UML

(UNIFIED MODELING LANGUAGE)

Faculté des Sciences et Techniques

[email protected]

http://perso.univ-st-etienne.fr/jacquene

Plan de cette partie de cours 2

Généralités et Historique d’UML

Diagrammes de Cas d’Utilisation

Diagrammes de Séquences

Diagrammes d’Etat

UML – Généralités et Historique

3

UML = Unified Modeling Language

Langage graphique de modélisation des données et traitements

Basé sur la technologie objet

Deux classes de diagrammes

Aspects statiques

Aspects dynamiques

Objectif : schémas clairs et lisibles facilitant la communication entre intervenants du projet

UML n’est pas une méthode

UML est un langage de modélisation pour construire et documenter


4

Business process

modeling notation

Domain specific

languages System Modeling

Language

Unified Modeling

Language

Object Modeling

Technique

Object Oriented

Soft Engin.

Rational Unified

Process


5


6


7

UML – Outils

8

Libres

ArgoUML (http://argouml.tigris.org/)

Papyrus (http://www.eclipse.org/papyrus/)

StarUML (http://staruml.sourceforge.net)

…

Commerciaux

Rational Rose

Borland Together

PowerDesigner

…

Liste plus complète : http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools

http://argouml.tigris.org/

http://www.eclipse.org/papyrus/

http://www.eclipse.org/papyrus/

http://staruml.sourceforge.net

http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools

http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools

9

Diagramme

de cas d’utilisation

Diagramme de cas d’utilisation

10

Le diagramme de cas d’utilisation fait partie des diagrammes de

comportement

UML – Cas d’utilisation (Use Case)

11

Technique pour capturer les exigences fonctionnelles d’un

système

Déterminer ses limites

Déterminer ce qu’il devra faire, quels services il rendra

Mais pas comment il devra le faire

Point de vue de l’utilisateur

Déterminer les acteurs qui interagissent avec le système

Rôles

Déterminer les grandes catégories d’utilisation

Cas d’utilisation

Décrire textuellement des interactions

scénarios

Acteur

12

Entité (humain ou machine) située hors du système

Permet de déterminer les limites du système

Un acteur joue un rôle par rapport au système

Soit déclenche un stimulus entraînant une réaction du système

Soit est sollicité par le système au cours d’un scénario

Un acteur est décrit précisément en quelques lignes

Catégories d’acteurs

Acteurs principaux (fonctions principales du système)

Acteurs secondaires (administration/maintenance)

Matériel externe

Autres systèmes

Cas d’utilisation

13

Ensemble de séquences d’actions réalisées par le

système, produisant un résultat observable pour un

acteur particulier

Exemple : s’identifier, retirer du liquide, répondre à un mail

Un cas d’utilisation

Définit un ensemble de scénarios d’exécutions impliquant le

même acteur (déclencheur) avec le même objectif utilisateur

Recense les informations échangées et les étapes dans la

manière d’utiliser le système, les différents points

d’extension et tous les cas d’erreur

Scénario

14

Séquence particulière d’étapes dans la réalisation d’un cas d’utilisation

Séquence particulière de messages dans le cas d’utilisation pendant une

interaction particulière

Chemin dans le cas d’utilisation

Tous les scénarios d’un cas d’utilisation sont issus du même acteur et ont le

même objectif

Description du cas d’utilisation

Ensemble de scénarios couvrant le cas d’utilisation

Documents avec flot d’événements

Détaille ce qui se passe entre l’utilisateur et le système quand le cas d’utilisation est

exécuté

Flot nominal des événements

Flot d’événements alternatifs

Flots d’exceptions (terminaison incorrecte)

Serviront de base pour les jeux d’essais

Exemple de cas d’utilisation

15

Inclusion/extension/généralisation

16

Include

Un cas A inclut un cas B si le comportement décrit par le cas A inclut

systématiquement le comportement du cas B

Extend

Un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A

peut être appelé au cours de l’exécution du cas d’utilisation B

Generalize

héritage

Faire virement

Internet

Faire virement

S’identifier Vérifier

solde compte

«include» «extend»

montant>80 Client

local

Client

distant

Représentation textuelle du cas d’utilisation

17

A la représentation graphique est associée une

représentation textuelle (c’est en fait la chose la plus utile)

Ensemble de champs de description (nom, préconditions, …)

Lisible et informelle (langage naturel, pas trop long, …)

Décrit

Un scénario nominal (suite d’étapes avec objectufs de l’acteur bien identifiés et

menés à bien

Des points d’extension et étapes d’extension

Des points d’échec

Des liens vers d’autres scénarios s’il y a trop d’étapes

Représentation textuelle du cas d’utilisation

18

Complément de description

Tout ce qui permet de mieux comprendre le cas d’utilisation

Diagramme de séquence

Diagramme d’activité, de machine d’états

Dessin ou maquette d’interface

Documents quelconques

Texte vs diagrammes

19

+ Les diagrammes sont simples à comprendre pour les décideurs

Les différents acteurs

Leurs interactions avec le système

Les limites du système

- Les diagrammes peuvent devenir illisibles (grande hiérarchie,

spaghettis)

- Les diagrammes ne sont pas précis

Texte vs diagrammes

20

Les cas d’utilisation sont issus du dialogue entre concepteurs

(informaticiens) et futurs utilisateurs (non informaticiens) pour

Passer du flou du cahier des charges à des fonctionnalités exprimées

dans le langage du domaine, donc celui des utilisateurs

Exprimer complètement les besoins tout au long du processus de

conception

Les cas d’utilisation doivent être validés par les futurs utilisateurs

lisibilité impérative

L’utilisateur ne doit pas faire confiance à l’informaticien, il doit

comprendre et réagir s’il n’est pas d’accord

Un cas d’utilisation textuel raconte l’histoire du futur utilisateur avec

le futur système

En résumé

21

Privilégier les descriptions textuelles, les seules qui

décrivent réellement les besoins fonctionnels de

façon partageable

N’utiliser les diagrammes de cas d’utilisation que

comme table des matières donnant accès aux

différentes descriptions textuelles

Rédaction de cas d’utilisation

22

Généralités

Intérêts et intervenants

Portée de conception

Acteurs et objectifs

Préconditions, garanties et déclencheurs

Scénarios

Extensions

Variantes et technologies et de données

Formats de cas d’utilisation

Divers

Rédaction de cas d’utilisation (généralités)

23

A quoi servent les cas d’utilisation ?

Clarifier les processus métier

Bien comprendre le domaine, l’organisation pour laquelle on

conçoit le système

Fixer les limites du système

Bien comprendre ce qui relève du système à concevoir et à

construire

Et ce qui n’en relève pas

Orienter la discussion

Entre les concepteurs, le client, les futurs utilisateurs


24

A quoi servent les cas d’utilisation ?

Découvrir et fixer les exigences fonctionnelles

Préparer les tests

Unir tous les modèles d’un projet

Tout choix de conception vient d’un cas d’utilisation

Les cas d’utilisation sont un point d’entrée vers la

documentation de la conception


25

Rédaction de cas d’utilisation (exemple)

26


27


28

Récapitulatif (cas d’utilisation)

29

Dans un diagramme de cas d’utilisation nous

avons mis en avant :

Les acteurs

Les cas d’utilisation

Les relations entre cas d’utilisation

Include

Extend

Generalize

Les relations entre acteurs

Generalize


30

ATTENTION. Lorsqu’on a un diagramme comme

par exemple

On ne fait pas apparaître l’ordre d’exécution

de fonctionnalités


31

Dans la description textuelle d’un cas d’utilisation, comme

par exemple :

on fait apparaître (dans le scénario) l’ordre

d’exécution de fonctionnalités

32

Diagramme

de séquence


33

Un diagramme de séquence va permettre de représenter

graphiquement un scénario.


34

Le diagramme de séquence fait partie des diagrammes

d’interactions


35

S’intéresse aux messages échangés entre des lignes de vie

Ligne de vie

Élément nommé représentant un participant dans l’interaction

Boite possèdant un nom et une classe

Ligne verticale

:User x [k] :User

Nom d‘objet Nom de la

classe


36

Message : élément nommé qui définit une catégorie spécifique de

communication entre des lignes de vie d’une interaction

Un message reflète

L’appel d’une opération (méthode) et le début de l’exécution

Envoi et réception d’un signal

Un message peut être

Un appel synchrone

Un appel asynchrone

Une création

Une destruction

Une réponse


37

Appel synchrone

Représente un appel de méthode

L’émetteur envoi un message

Il suspend son exécution durant l’attente de la réponse

Flêche pleine à son extrémité


38

Appel asynchrone

Représente un appel de méthode

L’émetteur envoi un message

Il continue son exécution sans attendre la réponse

Flêche ouverte à son extrémité


39

Message de Création

Message envoyé à une ligne de vie

Flêche pointillée, ouverte à son extrémitié, pointant sur la tête

d’une ligne de vie


40

Message de Destruction

Message envoyé à une ligne de vie pour la terminer

La ligne de vie se termine par une croix


41

Message de Réponse

Message envoyé en réponse à un appel

Flêche pointillée avec extrémité ouverte


42

Les différents événements liés à un message

Envoi du message

Réception du message

Début d’exécution

Fin d’exécution


43

Objet actif / Objet passif

Objet actif

initie et contrôle le flux d’activités.

La ligne pointillée verticale est remplacée par un double trait vertical

Objet passif

A besoin qu’on lui donne le flux d’activité pour pouvoir exécuter une méthode

La spécification de l’exécution d’une réaction sur un objet passif se représente par

un rectangle blanc ou gris placé sur la ligne de vie en pointillée


44

Exécutions simultanées sur la même ligne de vie


45

Fragments d’interactions combinés 12 opérateurs

Principalement 8 utilisés

Opérateurs de choix et de boucle

alternative

option

Loop

break

Opérateurs contrôlant l’envoi en parallèle de messages

parallel

critical region

Opérateurs fixant l’ordre d’envoi des messages

strict sequencing

weak sequencing


46

Fragments d’interactions combinés - Opérateur alternative

Le fragment représente un choix

Similaire à un switch en C


47

Fragments d’interactions combinés - Opérateur alternative

Autre exemple


48

Fragments d’interactions combinés - Opérateur option

Équivalent à un opérateur alternative avec une seule condition


49

Fragments d’interactions combinés - Opérateur loop

Permet de spécifier une boucle

Boucle qui s’exécute 10 fois

Boucle qui s’exécute possiblement

une infinité de fois


50

Fragments d’interactions combinés - Opérateur loop

Permet de spécifier une boucle

Si la condition est fausse, on sort

de la boucle, quel que soit le nombre

d’exécutions de la boucle

La boucle s’exécute au minimum

5 fois et au maximum 10 fois


51

Fragments d’interactions combinés - Opérateur break

Si la condition du break est vraie, on exécute le fragment associé et on

ignore le reste du fragment dans lequel le break est inclus

Si la condition du break est fausse on passe directement à la suite du

fragment englobant


52

Fragments d’interactions combinés - Opérateur parallel

Spécifie l’exécution en parallèle de plusieurs sous fragments


53

Fragments d’interactions combinés - Opérateur parallel

Autre exemple

heatFood()

cookedFood


54

Fragments d’interactions combinés - Opérateur strict sequencing

Les fragments s’exécutent les uns après les autres


55

Fragments d’interactions combinés - Opérateur strict sequencing

Autre exemple


56

Fragments d’interactions combinés - Opérateur weak sequencing

Si les lignes de vie atteintes sont les mêmes exécution séquentielle

Si les lignes de vie atteintes sont différentes exécution parallèle

Google en parallèle avec bing et/ou yahoo

Bing puis yahoo

weak


57

Utilisation d’interactions

Possibilité de faire référence à une interaction dans la définition

d’une autre interaction

Permet la réutilisation d’une définition dans des contextes différents

58

Diagrammes

d’activités

Diagramme d’activités

59

Le diagramme d’activités fait partie des diagrammes de

comportement


60

Permet de s’intéresser aux traitements

Modélisation du flôt de contrôle et du flôt de

données

Permet de représenter graphiquement

Le comportement d’une méthode

Le déroulement d’un cas d’utilisation

Offre une vision très proche des langages de

programmation impératifs


61

Action

Plus petit traitement exprimé en UML

équivalent instruction d’un langage de programmation

Principales actions

Action appeler (call operation)

Action comportement (call behavior)

Action envoyer (send)

Action accepter événement (accept event)

Action accepter appel (accept call)

Action répondre (reply)

Action créer (create)

Action détruire (destroy)

Action lever exception (raise exception)


62

Graphiquement les actions apparaissent dans des nœuds action

Rectangle avec bords arrondis

Notation spéciale pour actions de communication


63

Activité

Définit un comportement décrit par un séquencement organisé d’unités dont les

éléments simples sont les actions

Le flot d’exécution est modélisé par des nœuds reliés par des arcs (transitions)

Groupe d’activités

Activité regroupant des nœuds et des arcs

Un diagramme d’activités est lui-même un groupe d’activités

Nœuds d’activités

Transition


64

Exemple de diagramme


65

Nœuds de contrôle

nœud initial (initial node)

nœud de fin d’activité (final node)

nœud de fin de flot (flow final)

nœud de décision (decision node)

nœud de fusion (merge node)

nœud de bifurcation (fork node)

nœud d’union (join node)


66

Nœuds de contrôle


67

Nœud d’objet

Les autres types de nœuds permettent de modéliser les flôts de contrôle

Un nœud objet permet de définir un flôt de données

Pins d’entrée ou sortie

Flôt d’objets

Permet de passer des valeurs d’une activité à une autre


68

Nœud d’objet

Nœud buffer central

Nœud de stockage des données


69

Partitions

Permettent d’organiser les nœuds d’activités en opérant des regroupements

Graphiquement, les partitions sont délimitées par des lignes continues

On les appelle des couloirs ou des lignes d’eau


70

Exceptions

Une activité peut déclencher une exception

Une exception peut être récupérée par un gestionnaire d’exception


71

Exceptions


72

Exemple 1


73

Exemple 2


74

Exemple 3

75

FIN DE LA 5ème PARTIE

Figures – Chapter 4 · Cas d’utilisation 13 Ensemble de séquences d’actions réalisées par...

Documents

Transcript of Figures – Chapter 4 · Cas d’utilisation 13 Ensemble de séquences d’actions réalisées par...