Definitiondesbesoinsuml

Plan du coursIntroduction

Le problème, Les techniques objet, Genèse d’UML Intro UML

Les 13 diagrammes, les diagrammes expression de besoin, notion de modèle

Les cas d’utilisation (modélisation métier et application)

Les diagrammes statiquesLe diagramme de classe et de package

Les diagrammes dynamiquesSéquence, automate, activité,…

Etude de cas2

Le problème

3

Importance de l’expression des besoins

4

Source Borland (Juin 2003 à Juin 2004)

5

Il faut une méthode

Booch-93 Rumbaugh( OMT2)

Oct-950.8

Jacobson (use case - sdl)

Juillet-960.9

Janv-971.0

Nov-971.0

Sept-971.1 (OMG)

20001.4

20052.0

DOC-PDF UML1.3 = 4,7MBDOC-PDF UML2.0 = 5.8 MB

20062.1

6

UML

7

Les cycles de DVP

• Conceptualisation• Analyse• Conception• Codage• Tests unitaires• Intégration

8

ExpertMetier ExpertObjet

TrainOméoplasmose

Sténotype

ClassePolymorphisme

Relinker

Langagecommun

• Décrire ce que l’on doit faire(UC) => langage commun• Langage commun => Glossaire• Glossaire => Tout ce qui est mis dans un modèle doit avoir

une définition associée

9

Les UC :• Décrire les acteurs et ce qu’ils attendent du système• Décrire l’ensemble des messages entrant et sortant du système• Ne pas décrire comment on fait

• Décrire l’ensemble des contraintes• Réutilisation d’un autre système• Problème de capacité-volume (des chiffres)• Problème de temps de réponse (des chiffres)• Choix technique quelconque imposé

10

Architecte

Analyste-Concepteur

• Partir des diagrammes de UC• Trouver les classes d’analyse (Boundary et Control)

• Partir de la description des UC• Trouver les classes entity• Faire tourner le programme

• Diagramme de séquence• Cas nominal• Les cas d’exception

• Affiner le diagramme statique (attributs, opérations, nouvelles classes)

• Refaire des sous-systèmes• Affiner les classes complexes : Automate

RMQ : Ne pas se vautrer dans l’héritage

11

UML & Méthode

12

13

14

XP propose une un ensemble de pratiques organisées autour des principes suivants :

• Le client (maîtrise d'ouvrage) pilote lui-même le projet, et ce de très près grâce à des cycles itératifs extrêmement courts (1 ou 2 semaines).

• L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de nouvelles versions s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback maximal sur l'avancement des développements.

• L'équipe s'organise elle-même pour atteindre ses objectifs, en favorisant une collaboration maximale entre ses membres.

• L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle développe, ce qui garantit au produit un niveau de robustesse très élevé.

• Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles et rapides.

Regis Medina

Source : the corporate Use Of Object Technology

17

11

81714

11

7

6

2

2

5

IncreasedProductivity

Cost savings

Improvedinterfaces

Software reuse

Improvedapplicationmaintenance

Encapsulateexistingapplications

Develop strategicapplicationsquickly

Developapplications asrevenue source

Access new OSand tools

15

Dvp = 20%

Maintenance = 50%

C++ C++ C++ C C CV0 V1 V2 V0 V1 V2

Average Function LOC 6,66 6,2 6,11 29,62 32,5 37,11Min Function LOC 2 1 1 3 3 3Avg Cyclomatic Complex 1,66 1,59 1,59 5,88 6,25 6,56Avg Comparison Complex 0,25 0,24 0,3 1,38 1,62 2,22Avg Logic Flow Complex 1,91 1,83 1,89 7,25 7,88 8,78Avg Function Complexity 3,69 3,59 3,7 9 9,62 10,56eLoc/100 2,07 2,5 2,68 2,68 2,91 3,53eLOC 207 250 268 268 291 353

16

Les Concepts Objet

17

Une bonne société qui développe des programmes est celle qui fabrique des programmes de qualité qui satisfont les besoins des clients (livraison à temps, utilisation des ressources humaines et matérielles optimales)

Le but principal n’est donc pas de produire de beaux documents,ni de conduire de nombreuses réunions, ni de proclamer de beaux slogans, ni de gagner des prix Pulitzer sur les lignes de code;mais simplement de produire des programmes capables de satisfaire le client aujourd’hui et demain.

Tout le reste est secondaire

UML est fait pour:• Spécifier• Comprendre• Communiquer• Documenter

source : UML-User Guide

Un dvpObjet

18

Un modèle contient :• Des éléments de modélisation

• Des classes (reliées à d'autres classes) avec des opérations etdes attributs

• Des informations supplémentaires sur le comportement des classes (automates, activité)

• Des informations concernant le cahier des charges (UC)• La description des fichiers et des machines supportant l'application

• Des dessins (vues) explicatifs liés les uns aux autres• Des diagrammes de classes réduits• Des diagrammes montrant comment les objets se partagent le

travail (interaction)• Des diagrammes montrant les objets existant à un moment donné

• Toutes ces informations sont organisées dans des packages

19

20

Un modèle contient :• Un diagramme de Use Case

• Des diagrammes d’interraction• Des diagrammes d’automate• Des diagrammes d’activité• Des diagrammes de vues d’ensemble des interractions

• Des diagrammes de classes• Les contraintes techniques

Toutes ces informations sont organisées dans des packages

Introduction

21

22

Les diagrammes pour la définition des besoins

23

24

25

Navigateur

Définitions

Boutons génériques

Boutons Spécifiques

Les diagrammes

ClasseUse Case

Composants

26

Un stéréotype est une nouvelle classe d’un élément de modélisation qui est introduit au moment de la modélisation. Cela représente une sous classe d’un élémentde modélisation existant avec la même forme, mais avecune intention différente.

• Exemple : un acteur est "comme" une classe, mais il ne fait paspartie du système. Un acteur pourrait être un stéréotype d'une classe

• On peut stéréotyper les classes, les associations, les packages, …..• On peut associer un nouvel icône pour chaque nouveau stéréotype.

Z<<nouveauStereotype>>

27

28

{ceci est une contrainte}

Rmq : On peut écrire des contraintes en OCLUne contrainte est raccrochée à un élément de modélisation

Personne

+age: int age > 0

Diagramme de Use case

Un acteur est un rôle d’un ou plusieurs objetssitués à l’extérieur du système et qui interagissentavec lui pour remplir une fonctionnalité donnée de ce système.Un acteur caractérise le rôle joué par un objet àl’extérieur du système.

Uti lisateur

• Un acteur parle au système (Acteur principal)• Le système parle à un acteur (Acteur secondaire)• Un acteur est :

• Un humain (via une IHM)• Du soft• Du hard

30

Un Cas d’utilisation ( use case ) est une fonctionnalité importante pour un acteur remplie par le système et qui semanifeste par un ensemble de messages échangésentre le système et un ou plusieurs acteurs.

UtilisateurVerifierBonneMarche

CapteurTemperature

31

Description

32

• Titre et numérotation• Résumé• Les acteurs

– Acteur principal– Acteurs

secondaires• Pré-conditions• Description• Exceptions• Post-conditions

(3-5 pages)Ce n ’est pas une

description formelleMais doit être très détaillé

Ceci est l ’usagemais ne fait partiede la norme UML

33

Payer cash

Payer par carte

Manger

Demander facture

Maitre d'hotel

Prendre la commande

clientAller au restaurant<<include>>

<<include>>

Caissier

Payer

<<include>>

<<extend>>

SommelierCommander pinard

<<extend>>

Serveur

Retourner plat en cuisine

<<extend>>

34

35

Manger

Descriptions

A

A1()A2()A3()

B

B1()B2()

C

C1()C2()C3()C4()

Distribuer le comportement des fonctionnalitésaux méthodes des objets

36

User Stories et Use Cases formalisent les besoins utilisateurs et sont orientés ButIls font facilement l'objet d'ateliers de travail avec les utilisateurs pour les découvrir, les expliciterIls vont être priorisés et vont ainsi guider les développementsIls mettent en avant les rôles, les différents profils d'utilisateursIls ne traitent que des exigences fonctionnelles (les aspects non fonctionnels sont décrits dans les spécifications supplémentaires(contexte UP) et dans les "Constraints Cards" (contexte XP))Ils sont textuels et obéissent à des règles de construction très précises Ils ne traitent pas des aspects interface et ergonomieIls aident à organiser le modèleIls facilitent le choix du contenu des itérationsIls peuvent être rédigés par les analystes (UC) ou le client (US)

37

38

39

Cas d'utilisation :Essentiellement un ensemble d'interactions

Acteur: Élément externe qui interagit avec le système (humain ou

autre système) Scénario :

Une lecture particulière d'un cas d'utilisation, son instanciation Relation de communication :

Le vecteur de l'échange (l'interaction) entre acteur et système <<include>> :

Relation qui, lorsqu'elle existe entre deux cas, est obligatoirement appliquée. C'est une dépendance entre le cas source qui inclut . <<extend>> :

Relation de dépendance optionnelle. Il s'agit d'étendre les interactions d'un cas avec celles d'un autre. Spécialisation de cas :

La même finalité, mais obtenue par des interactions différentes .

Une société de vente par correspondance vous demande de développer sonsystème informatique. Ce système doit pouvoir prendre en compte descommandes passées par la poste et des commandes passées par internet. Ildoit suivre les expéditions qui ne sont effectuées que si le paiement est OK.Les paiements se font par carte bancaire dans le cas d'internet et par chèquedans le cas de la poste. Les paiements sont validés par un système bancaire appartenant à la société et existant. Il faut récupérer ce système. Lenouveau système est chargé aussi de la gestion de stocks, lorsqu'un articleatteint un seuil minimal, alors il faut passer une nouvelle commande aufournisseur adéquat. A la réception de la commande, la mise à jour de la base est faite par un employé. Dans le cas d'un paiement accepté et de stockdisponible, l'expédition est faite par un robot existant au quel il suffit depasser les coordonnées du client, et la liste des produits achetés. En cas d'indisponibilité, une lettre doit être envoyé au client.

40

La première étape de la définition d’un système d’informationconsiste donc à s’interroger sur l’organisation (l’entreprise) pourlaquelle ce système d’information fonctionne, sur son identité, sur ce qui en fait partie et sur ce qui n’en fait pas partie

Utilisé par L’entreprise

Comment fait l’entrepriseLes objets de l’entreprise

Utilisateur

Employés deL’entreprise

Ce que fait l’entreprise

41

42

Selon Alistair Cockburn, il existe trois niveaux principaux qu'il situe allégoriquement par rapport à un niveau de référence qui est "celui de la mer".

Mouette :Au-dessus de la mer, représente plutôt des cas d'utilisation

métier Mer:

Le cas d'utilisation "système" dans son acceptation classique : une situation qui génère une bonne valeur ajoutée pour l'un des utilisateurs (acteurs) ; une fonctionnalité au sens habituel du terme (un micro-onde offre deux fonctionnalités principales qui sont "Décongélation" et la "Cuisson"). Crabe :

Quelques interactions qui ne constituent pas vraiment une situation d'utilisation en tant que telle. Ce seront généralement des cas qui seront réinjectés dans le modèle via des relations include ou extend.

•De quelle entreprise s'agit-il? Trouver les acteurs, entités (objets), use case, les employés …..

• Voyageur• Métro• Station• Couloir• Client• Inspecteur• Wagon

• Guichetier• Panneau publicitaire• Conducteur• Clochard• Commerciaux• Voyager• Acheter• Louer

43

Diagramme de classe

• Statique :– Ne pas utiliser de verbes d'action pour relier les classes– Une classe isolée est une classe inutile– Doit être vrai tout le temps– Représente LE programme– On ne peut pas tout montrer sur un seul schéma

Un diagramme de classe montre la structure statiquedu modèle, les choses qui existent, leur structureinterne et les relations aux autres choses.

45

Personne

nom : Stringpoids : intsexetaille : intage : int = 0/ dateNaissance : String$ nbPersonne : int

Manger(calories : int, lipide : float)Dormir() : voidTravailler(duree : int) : int$GetNbPersonne() : int//FaireBonneAction()

Dentiste

adresseCabinet

Travailler()

Abstrait

Nom : type [= Initialisation]

Syntaxe libre

Attribut dérivé

Attribut de classe

Opération de classe

Responsabilité

{abstract}

46

Personne


Manger(calories : int, lipide : float)Dormir() : voidTravailler(duree : int) : int$GetNbPersonne() : int//FaireBonneAction()

Personne


Manger()Dormir()Travailler()$GetNbPersonne()//FaireBonneAction()

Personne

nom : Stringpoids : intsexetai lle : intage : int = 0/ dateNaissance : String$ nbPersonne : int

Personne

Manger()Dormir()Travai ller()$GetNbPersonne()//FaireBonneAction()

Personne

Manger()Dormir()Travailler()$GetNbPersonne()//FaireBonneAction()Personne

47

48

Personne

+nom+adresse+age

+travailler()

Dentiste

+adresse cabinet

+travailler()

Boulanger

+type de pain

+travailler()

Vehicule

+carte grise

Avion

+aile

Bateau

+quille

Hydravion

Type de pain<<enumeration>>

+baguette+gros pain+poilane

Association & Dépendance

49

Les associations (relations) connectent deux ou plusieurs classes.

Elles peuvent porter un nom.Si une association connecte une classe à elle-

même, elle est dite réflexive.Une classe peut simplement dépendre d’une

autre classe

Personne

+Guerir(m: Medecin)

EcoleformationMedecin

Personne

+nom+adresse+age

+travailler()

+enfants

+parent

0..*

2

Personne SocieteEst Employée par

Nom d'association

Personne SocieteEst Employée par

-employeur-employeNom de rôle

Personne

employeur : Societe

Societe

employe : Personne

SocietePersonne1..* 0..1

-employe -employeur

1..* 0..1Cardinalité-Multiplicité

Personneemployeur : Societe

Societeemploye : ListeOfPersonne

NavigabilitéSocietePersonne1..*

-employes

1..*

Societeemployes : Personne

Personne

50

51

PersonneEntreprise

**

Contrat de travail

+date embauche+titre-salaire

52

Personne

Coeur

1

J ambe

2

Entreprise

ANPE

*

1

{ou}

53

Un package est un regroupement des éléments du model. Cela s’applique à tous les élémentsUML ainsi qu’aux différents diagrammes.Les packages sont la base de la gestion deconfiguration

P0

On peut montrer ce qu’il y a à l’intérieur du packageUne classe appartient à un package et un seule, mais peutêtre utilisée dans d'autres package.

P1

+ C1C2C3

P2

global

55

Notion de package

• Un paquetage est un regroupement d’éléments de modélisation, mais aussi une encapsulation de ces éléments. A l’image des classes, les paquetages possèdent une interface et une réalisation.

• Chaque élément contenu par un paquetage possède un paramètre qui signale si l’élément est visible ou non à l’extérieur du paquetage.

• Les valeurs prises par le paramètre sont : public ou implémentation (privé).

56

Cela signifie que :• Un élément de P0 au moins

utilise un élément publique de P3 et de P1

• Un élément de P3 au moins utilise un élément publique de P1

• P0, P3 et P1 peuvent utiliser les éléments publiques de p2

P2

global

P1

+ C1C2C3

P0

P3

57

K

L

A B

I

E

J

G

D

H

C

F

58

K

L

A B

I

E

J

G

D

H

C

F

59

Environnement

Métier

Fonctionnel

B

C

E

Control

Fonctionnel

Entite

Métier

Boundary

Environnement

60

Aiguilleur

Pilote

Decoller

Atterrir

Aeroport

Voler

61

Aiguilleur

Pilote

Decoller

Atterrir

Aeroport

VolerCtrlVoler

CtrlDecoller

CtrlAtterrir

DecollerForm

VolerForm

AtterrirForm

AeroportForm

AiguilleurForm

TrainAtterrissage

Reacteur

Frein

62

Immeuble

Famille

Appartement

Pièce

Cuisine

Salon

Gardemanger

Chien

Chat

Animal

Location

Vente

Nourriture

Lapin

Whisky

Mariage

CompteBanquaire

Personne

63

Diagrammes dynamiques

• Diagrammes d'interaction (Séquence collaboration) servent à montrer comment les objets se parlent les une aux autres.Ils montrent le déroulement d'un ou d'une partie d'un Use case(cas nominal, cas des exceptions, …)

• Automates servent à montrer le comportement d'une classe qui réagit différemment selon son état.

• Activités montrent le déroulement d'une méthode d'une classe oucelui d'un Use case

65

: Clienta : A b : B c1 : C : C

A2( )

A3( )

B2( )C2( )

C4( )

new

66

a : A

: Client

b : B

c1 : C

: C

1: A2( )

2: A3( )

3: B2( )

4: C2( )5: C4( )

67

68

69

Un automate est accroché à une classe (ou un UC) et est composé d'états etde transitions. Les transitions permettent de passer d'un état àun autre …

Arret Marche

On

Off

Casse

Casse

70

Etat

entry/ Action1exit/ Action2on Ev1/ Action2do/ Activité

E1 E2Ev1( a1,a2 )[ i == 0 ] / ActionDeTransition ^Cible.SendEv2(a3, a4)

Événement qui déclenche la transition

Garde

Action effectuée sur la transition

Envoie de Ev2 à un objet Cible

Action en entrant dans l'état

Action en sortant de l'étatAction déclenchée sur réception de Ev1

Activité

71

72

73

E1

ST1

entry: i = 0exit: i++

ST2

entry: i++exit: i++on E4: i ++

E1 / i++

ST3ST4

on E2: i = i - 2

E3[ i == 5 ]

E2

E1

E1

E3

E3

E1E3E1E3E1E2E1E2

E3

74

75

76

• Les diagrammes d’interaction générale fusionnent les diagrammes d’activité et de séquence en autorisant l’utilisation de fragments (diagrammes de séquence) avec des points de décision et des flots de contrôle (diagrammes d’activité).

77

Interaction Diagram

Requirements

Sequence

Collaboration

Use Cases

GUI

Class diagram

State Activity

Implementation

Component

Deployment

Code

Code

Code

Code

Tests

78

79

Patron du dossier d'expression des besoinsProjet<<nom du projet>>Version < ?. ?>Historique des révisionsIntroductionPrésentation du documentObjectifs du documentContenu du documentDescription du Métier (Optionnel) Les entités métiers (diagramme de classe) Les processus métiers (diagramme d’activité + états des objets)Description du produit Les objectifs du produit, les avantages qu'apporte le produit Les fonctionnalités du produit (UC) Les utilisateurs du produit et leurs caractéristiques (acteurs humains) Les contraintes du produit, règles métier Les hypothèses (conditions d'utilisation) et les dépendances (acteurs système)

80

Les besoins-exigences non fonctionnelsExigence en terme de qualité Utilisabilité (Maniabilité)[Par exemple: le temps de formation nécessaire à la prise en main du produit, exigence de standardisation, …] Fiabilité (Conformité)[On trouve ici les caractéristiques principales de la fiabilité comme, par exemple: temps moyen entre 2 pannes, le temps moyen d'intervention,…] Performance (Efficacité)[Par exemple: Temps de réponse moyen et maximal pour une transaction, le nombre d'utilisateurs simultanés, les fonctionnements dégradés acceptables, l'utilisation des ressources (mémoire, disque, communications,...) ] Documentation et aide en ligneAutres exigences Contraintes de conception (langage, machine, BD persistence,…..) Les composants non développés dans l'application (Réutilisation) Les interfaces (API, Corba,….) acteurs secondaires? Les interfaces utilisateurs, érgonomie…..construites à partir des boundary

81

Objectifs : décrire les besoins d’un système informatique. La première description est faite par le client. Cas de l’étude : logiciel de Gestion d’Affaires (GA) demandé par un client tertiaire, 250 personnes, 10000 affaires). Le logiciel de gestion d’affaires doit permettre de gérer, par collaborateur, les affaires dont il s’occupe. Une affaire peut posséder un nom, un client, une date de création, une date de fin prévue, un état (en cours, en retard, en cours mais en retard, abandonnée, terminée), une description.Les actions possibles sur une affaire sont : création, modification, suppression.Les affaires devront être présentées en 4 listes : en cours et en retard, en retard, toutes, terminées.La sélection doit se faire par collaborateur, ou bien par client.

82

1. Faire un diagramme de Use Case2. Faire un diagramme d’activité, présentant les étapes pour créer, modifier et supprimer une affaire.3.Faire un diagramme de classe4.Faire un Automate concernant les affaires5.Faire un diagramme de séquence6.Dessiner l’IHM

1

23

4

65

83

Robot

ClientPoste

ClientInternet

Verifier StockFournisseur

Passer Commande Internet

include

Passer Commande Posteinclude

SystemBancaireVerifier Paiement

Include

Include

Expedier Commande

Extend

AdministrateurGérer Stocks et fournisseurs

8484

85

86

87

88

89

90

91

92

93

94

95

Business Actor(client)



Business Worker(employée)



96

Business use caseLes fonctions





Business Entité(les objets)

97

98

9999

100

Utilisateur

Gerer les affaires

101

Selectionner un Client ou un collaborateur

Choisir un état

en coursen retarden cours mais en retardterminéeabandonnée

Selectionner une affaire

[N OK]

Creer une Affaire

[NOK]

Modifier l'affaire

[OK]

Afficher les affaires correspondantes

nomclient(si non selectionné)collaborateur(si non selectionné)date de findescription

nomclientcollaborateurdate de débutdate de finetatdescription

102

Affaire

+nom+description+date debut+date fin+etat: EtatEtat

<<enumeration>>

+en cours+en retard+en retard et en cours+abandonné+terminée

Client

+nom

Collaborateur

+nom

+client

1

0..*

+collaborateur0..1

1..*

103

en cours en cours et en retard

[ date>date de fin ]

terminée

fin

fin

Abandonnée

abandonner abandonner

en retard

attendre

reprendre

attendre

[ date<date de fin ]

La date de fin a été repoussée

104

actif

en cours en cours et en retarden cours en cours et en retarddate > date fin

date < date fin

terminée

abandonnée

en retard

attendrereprendre

105

: Utilisateur

GA

Selectionner Client/Collaborateur()

Selectionner un état()

Rechercher des Affaires()

Afficher les afffaires()

Selectionner une affaire()

Afficher les infos de l'affaire()

Modifier un ou plusieurs champps de l'affaire()

Valider la ou les modifications()

106

delete valider