ANALYSE ET CONDUITE DE PROJETS

P. Bourmanne HELMo

PLAN DU COURS

Partie I : Introduction : (#3)

Prsentation Evaluation Les mtiers de linformaticien dans le cadre dun dveloppement logiciel Buts du cours Le modle entit-association Le modle de Bachman Bases de donnes : gnralits Le modle relationnel Introduction (#80) UML : point de vue statique (diagrammes et notation) (#91) UML : point de vue fonctionnel (diagrammes et notation) (#111) UML : point de vue dynamique (diagrammes et notation) (#138) Tableau rcapitulatif (#180) Vers une mthode de dveloppement (#181) Applications (#187)

Partie II : Les mthodes danalyse : (#17)

Partie III : La modlisation objet avec UML : (#78)

PARTIE I
Introduction

INTRODUCTION: PRESENTATION

Cours: Laboratoires :

1.5

1.5

1.5

1.5

1.5

Patricia Bourmanne
0 2 2 1.5 1.5 0

Patricia Bourmanne Danile Bayers

SUPPORTS ET REFERENCES

Syllabi :

Mthodes danalyse ; A. Clarinval; septembre 2002 Initiation aux bases de donnes ; P. Bourmanne, 2002 Concepts et mthodes de la programmation par objets; A. Clarinval; novembre 2002 Modlisation objet avec UML , P.A. Muller, d. Eyrolles, 1997 UML et C++, guide pratique du dveloppement orient objet ; R.C. Lee, W.M. Tepfenhart, d. Prentice Hall, 1998 Guide pratique du RUP , P. Koll, Ph. Kruchten, CampusPress, 2003 UML 2 par la pratique , P. Roques, Eyrolles, 2005 The unified modeling language, user guide , G. Booch, J. Rumbaugh, I. Jacobson, d. Addison-Wesley, 1999 UML 2 en concentr, manuel de rfrence , D. Pilone, d. OReilly UML 2 et les design patterns, analyse et conception orientes objet et dveloppement itratif ,C. Larman, d. Pearson Education

Livres de rfrence :

SUPPORTS ET REFERENCES (suite)

Diaporamas du cours (P. Bourmanne) Sites :

http://www.hemes.be/saint-laurent/informatique/ressources.php http://www.gramme.be/infopb UML :

http://www.omg.org/technology/documents/formal/uml.htm http://sparxsystems.com.au/uml-tutorial.html http://sparxsystems.com.au/UML2_tutorial/UML2_Tutorial_Intro.htm

INTRODUCTION: EVALUATION

Votre participation active aux cours thoriques et pratiques Vos travaux lors des sances de laboratoires Une interrogation (le lundi 24 novembre) Un examen sur la thorie, des exercices raliser, un projet prsenter Modalits : cf. http://www.gramme.be/infopb/coursSL/analyse/evaluations/Modalites_generales.pdf

INTRODUCTION : METIERS DINFORMATICIEN

Catgories:

Dveloppement logiciel Gestion dun parc informatique Assistance clientle (technique et/ou logicielle) Formation

INTRODUCTION: METIERS DU DEVELOPPEMENT LOGICIEL

Les mtiers de linformaticien dans le cadre dun dveloppement logiciel:

1) Le chef de projet : responsable de llaboration et de la modification du plan de dveloppement logiciel

Rle complexe :

Les personnes Le produit = lobjectif Le processus = feuille de route de lquipe Le projet grer, planifier, contrler, rectifier Le budget

Comptences diffrentes pour tre capable dune ORIENTATION et ADAPTATION dynamiques :

Aptitudes techniques Talents de communication

Sera jug sur les rsultats

INTRODUCTION: METIERS
2) Lanalyste : responsable de dfinir et de communiquer aux intervenants les fonctionnalits qui sont attendues du systme

Tches de haut niveau :

Comprendre les besoins des diffrents intervenants (utilisateurs, investisseur, acheteur, chef de produit, ) Ngocier les exigences et faciliter lacceptation de lapplication par le client Documenter, hirarchiser et communiquer les exigences

Implication dans les disciplines suivantes :

Modlisation mtier/systme Gestion et expression des exigences Analyse (= modlisation de la description du problme) Conception (= modlisation de la solution du problme)

10

INTRODUCTION: METIERS
Lanalyste : (suite)

Qualits requises :

Habilet grer les relations entre plusieurs intervenants Bonne comprhension du domaine du problme ou capacit de lacqurir rapidement Aptitude communiquer oralement de faon claire et concise Capacit rdiger succinctement et clairement les exigences Comprhension globale du cycle de vie du dveloppement du logiciel

11

INTRODUCTION: METIERS
3) Larchitecte logiciel : dirige et coordonne les activits techniques (technologies, structure et organisation du systme logiciel) tout au long du projet; il est un centre de la communication

Rle pluridisciplinaire :

Exprience des problmes (comprhension approfondie des exigences) et de lingnierie logicielle (vision globale du projet, comprhension des technologies, ) Leadership technique ( chef de projet : leadership pour les aspects mtier et administratif) Sens de la communication Concentration sur les objectifs et la proactivit: pour axer le projet sur les rsultats

12

Source de travail : principalement exigences tablies par les analystes Doit tre capable de cerner rapidement les situations et les problmes, dmettre des jugements aviss et critiques en labsence dinformations compltes Collaboration troite avec le chef de projet (architecte + chef de projet = gestionnaires)

INTRODUCTION: METIERS
Larchitecte logiciel : (suite) Architecture logicielle =

structure du systme logiciel + aspects suivants:

Usage Fonctionnalit Performance Robustesse Rutilisation Comprhensibilit Contraintes et compromis conomiques et technologiques Aspects esthtiques

13

en se concentrant uniquement sur les dcisions de conception importantes (effets long terme sur les performances, la qualit, lvolutivit du systme)

INTRODUCTION: METIERS
4) Le dveloppeur : charg de traduire les exigences en code excutable dune qualit suffisante

Tches de haut niveau :

Comprendre les exigences (notamment par les cas dutilisation) et les contraintes de conception Matriser la technologie dimplmentation et des outils utiliser Concevoir, implmenter et tester les logiciels et les bases de donnes Intgrer ses travaux de dveloppement ceux des autres dveloppeurs tre cratif en restant rationnel Veiller la qualit avec larchitecte pour garantir que la conception respecte larchitecture globale avec lanalyste pour lui faire part dincohrences ou de lacunes au niveau des exigences ; lanalyste pourra alors procder aux corrections ncessaires

Collaboration troite :

14

INTRODUCTION: METIERS
5) Le testeur : charg de lvaluation de la qualit du logiciel et du respect des objectifs

Mission :

valuer le produit logiciel en fonction de critres appropris (qualit perue, conformit aux normes, dcouverte de dfauts, ) Communiquer ses valuations aux dveloppeurs, aux managers, ventuellement aux clients rsoudre les conflits entre les diffrentes visions dune bonne qualit (rle ingrat : cot de la qualit) Amener ventuellement lquipe se rendre compte que les spcifications ntaient pas compltes Dtecter les conditions exceptionnelles qui pourraient rendre le logiciel inutilisable

15

INTRODUCTION: METIERS

Un rle peut tre tenu par une ou plusieurs personnes Une personne peut endosser plusieurs rles, entirement ou partiellement
Le dveloppement logiciel est avant tout un travail dquipe(s). Linformaticien doit tre capable :
- dautonomie - danticipation - de rigueur - de communiquer (oralement et par crit) Linformaticien doit pouvoir rester concentr sur ses propres activits, tout en collaborant harmonieusement avec dautres personnes organiquement lies.

16

INTRODUCTION : BUTS DU COURS

Vous amener tre capable danalyser un problme, une situation modliser Par ce cours et vos cours de programmation: vous amener tre capable de concevoir un logiciel de qualit:

Correct : rpond aux spcifications Robuste : rsiste aux situations difficiles Extensible : peut tre amlior et tendu Rutilisable : peut tre utilis par dautres logiciels

Vous amener communiquer

17

INTRODUCTION : BUTS DU COURS (suite)

Vous sensibiliser et vous former la qualit :

Confrence Espace Horizon Qualit par lASBL Entreprise & Qualit (le 16/09/2008 3me info) Ides principales (cf. folder fourni) :

Exigence de chaque client : La qualit pour tous et partout Qualit = atteinte de la satisfaction des clients internes et externes Qualit

est un besoin universel et vital est la rponse adapte un ensemble de besoins (qui voluent) ne simprovise pas, se construit chaque jour se trouve tous les niveaux de lorganisation et chacun y tient une responsabilit nest pas une recherche du coupable, mais la recherche du progrs continu

La recherche de la qualit:

Apprentissage des principes du RUP (processus de dveloppement logiciel)

18

ET VOUS ?
-

Dans quelle catgorie mtier vous voyezvous le mieux actuellement ? Pourquoi ? Si vous travaillez dans le dveloppement logiciel, quel mtier vous semble le mieux convenir votre idal ? Pourquoi ?

19

PARTIE II
Les mthodes danalyse
(mthodes orientes gestion de donnes )

20

CONCEPT DE DONNEE
1. Dune faon gnrale, tout ce qui est manipul par un ordinateur est appel DONNEE. 2. Une DONNEE ELEMENTAIRE dcrit un lment atomique du monde rel. 3. On appelle STRUCTURE DE DONNES l'association d'un ou plusieurs noms et d'un ensemble de donnes lmentaires auxquelles ce ou ces noms permettent d'accder.

21

TYPE (ABSTRAIT) DE DONNEES

Quand un informaticien dveloppe un programme, il est normal, qu'au dpart, il ne se proccupe pas de la reprsentation physique des donnes. On parle alors de TYPE ABSTRAIT DE DONNES. Celui-ci dfinit la syntaxe de la donne ou de la structure de donnes et les oprations que l'on va effectuer sur ce type de donnes ou de structure.

22

NOTION DENTITE
ENTIT = concept concret ou abstrait qui prsente un intrt pour les besoins de gestion de l'entreprise. Il est affect dun NOM et porteur de PROPRIETES (donnes lmentaires).

INSTANCE D ENTITE = un lment particulier d'un type d'entits, caractris par un identifiant et des valeurs des proprits.
IDENTIFIANT = proprit ou ensemble de proprits qui dfinit une et une seule instance d'un type d'entit.

23

NIVEAUX DABSTRACTION
3 niveaux de reprsentation :

24

LES NIVEAUX DABSTRACTION

Le NIVEAU EXTERNE correspond la vision particulire de chaque utilisateur par rapport au systme d'informations de l'entreprise. Il est vident que chacune de ces vues externes est incomplte et partielle. Chaque utilisateur peut travailler sur des donnes diffrentes ou sur des donnes communes d'autres utilisateurs. Le NIVEAU CONCEPTUEL ou schma conceptuel constitue la synthse de tous les schmas externes intgrs dans un schma unique qui est un invariant de l'organisation, car il est indpendant des traitements et du type d'organisation des donnes choisi. Il va regrouper toutes les donnes lmentaires, tous les objets recenss dans les vues externes, toutes les associations entre objets et ventuellement toutes les rgles auxquelles doivent satisfaire toutes les donnes.

25

LES NIVEAUX DABSTRACTION

Le NIVEAU ORGANISATIONNEL OU LOGIQUE constitue une tape intermdiaire entre le niveau conceptuel et le niveau interne. La description logique des donnes devra par exemple tenir compte du type de base de donnes choisie, mais s'affranchira encore de la reprsentation spcifique en mmoire des donnes lmentaires par exemple. Le NIVEAU INTERNE ou schma physique dcrit les choix d'organisation physique des donnes (fichiers, BD, mthodes d'accs, types d'index...).

26

MODELE : DEFINITIONS

Modle conceptuel de donnes (MCD) :

Ensemble de rgles de structuration ou de modlisation de l'information . Ensemble de rgles qui permet de passer du concret inaccessible (l'univers rel) un abstrait manipulable . Un modle ne doit pas seulement dcrire l'organisation des donnes, mais aussi la faon dont on opre sur ces donnes ; il peut tre peru comme un ensemble de structures avec un ensemble d'oprations dfinies dessus .

27

METHODES DANALYSE: UTILITE

Une mthode dfinit une dmarche reproductible pour obtenir des rsultats fiables Une mthode dfinit gnralement une reprsentation (souvent graphique) qui permet:

de manipuler aisment les modles de communiquer et dchanger linformation entre les diffrents intervenants

28

METHODES DANALYSE: LE MODELE ENTITE-ASSOCIATION

Le modle entit-association exprime la smantique des donnes laide des concepts: - dentit

- dassociation entre entits

- dattribut dcrivant les entits et associations
29

DEFINITION CONCEPTUELLE DE DONNEES : le modle entit-association

1. ASSOCIATION = un lien logique entre 2 entits ou plus. Elle est souvent dfinie par un verbe ou un nom (lien smantique) et une ou plusieurs proprits. 2. CARDINALITS d'une entit dans une association qui le lie une autre entit = le nombre minimum et le nombre maximum d'instances de l'association auxquelles doit tre rattache chacune des instances de l'entit.

30

A FAIRE A DOMICILE

Lire

Mthodes danalyse ; A. Clarinval; septembre 2002 : chap. 3.1 : Le modle entit-association Initiation aux bases de donnes ; P. Bourmanne, 2002 : chap. 2 : Les donnes

31

DEFINITION LOGIQUE DES DONNEES : le diagramme de Bachman

Enregistrement logique
( = record = segment) avec ses champs (= fields)

Entit
avec ses proprits

Lien

Association

32

diagramme de Bachman

DIAGRAMME DE BACHMAN

Rgles de transformation dun modle entitassociation en un diagramme de Bachman :

1 entit 1 segment (propritaire ou membre)

segment propritaire segment membre

cardinalit (0,1) ou (1,1)

1 association porteuse dau moins une cardinalit (0,1) ou (1,1) 1 lien 1 association totalement porteuse de cardinalits (0,N) ou (1,N) 1 segment membre + liens (autant de liens que dentits
associes lassociation)

33

A FAIRE A DOMICILE

Lire

Mthodes danalyse ; A. Clarinval; septembre 2002 : chap. 4 : Schma logique du stockage des donnes Initiation aux bases de donnes ; P. Bourmanne, 2002 : chap. 5.3. : Types de bases de donnes

34

Bases de donnes : gnralits

35

Base de donnes : dfinition

Ensemble structur de donnes enregistres sur des supports accessibles par l'ordinateur, reprsentant des informations du monde rel et pouvant tre interrog et mis jour par une communaut d'utilisateurs. Fichiers informatiques regroupant un ensemble dinformations thmatiques sous forme structure et indexe.

36

Systme de gestion de base de donnes

Logiciel gnral qui permet l'utilisateur, qu'il soit programmeur ou utilisateur final, de manipuler les donnes dans des termes abstraits, sans tenir compte de la faon dont l'ordinateur les voit.

37

Objectifs dun S.G.B.D.

Indpendance physique des programmes aux donnes :

indpendance entre structures de stockage et structures des donnes du monde rel, indpendance entre schma interne et conceptuel

Indpendance logique des programmes aux donnes :

possibilit de modifier un schma externe (vue) sans modifier le schma conceptuel et inversment

Manipulation des donnes par des langages non procduraux Administration facilite des donnes (fcts pour dfinir les
donnes et changer leur dfinition)

38

Objectifs dun S.G.B.D.

Efficacit des accs aux donnes (dbit + temps de rponse) Partage des donnes Cohrence des donnes

contrainte dintgrit (= rgle spcifiant les valeurs permises pour certaines donnes, ventuellement en fonction dautres donnes, et permettant dassurer une certaine cohrence de la base de donnes) : - unicit de cl - contrainte rfrentielle - contrainte de domaine

Redondance contrle des donnes Scurit des donnes (confidentialit + cohrence si panne : une
transaction doit tre totalement excute ou pas du tout)

39

Fonctions dun S.G.B.D.

Description des donnes :

commandes pour dfinir les schmas interne, conceptuel et externe

Recherche des donnes :

commandes pour retrouver les donnes de la base rpondant un critre plus ou moins complexe (= qualification = expression logique de critres simples, chaque critre permettant soit de comparer un attribut une valeur, soit de parcourir une association )

Mise jour des donnes :

commandes pour insrer des donnes dans la base, modifier des donnes, supprimer des donnes

Fonctions qui assurent les objectifs prcits

(transformation des donnes, contrle de lintgrit des donnes, gestion de transactions et scurit)

40

TYPES DE BD

Modle hirarchique Modle rseau

Modle relationnel

41

LE MODELE RELATIONNEL

Introduit par Codd Rsultat d'une approche formelle mathmatique qui modlise dans une mme thorie la notion de donnes et de manipulations de donnes et ne fait aucune rfrence au niveau physique Permet de rpondre aux objectifs prcits

42

Bibliothque
Titre

(hypothse : 1 auteur/livre)

Date achat

Prix TVAC

Auteur

Info auteur

Germinal
Le rouge et le noir Les mots La bte humaine

10/05/90

22.5

Emile Zola

1840-1902

05/08/97 01/02/98 01/06/97

25 17 30

Stendhal Jean-Paul Sartre Emile Zola

1783-1842 1905-1980 1840-1902

43

Titre Germinal Le rouge et le noir Les mots La bte humaine

Date_achat 10/05/90 05/08/97 01/02/98 01/06/97

Prix TVAC 22.5 25 17 30

Auteur Emile Zola Stendhal Jean-Paul Sartre

Emile Zola

Auteur Emile Zola

Info auteur 1840-1902

Stendhal Jean-Paul Sartre

1783-1842 1905-1980

Dfinitions

ATTRIBUT : champ ou proprit du lot d'informations RELATION (ou TABLE) : liste d'attributs a1, a2, ..., an; ensemble de lignes du tableau dfini par les attributs. Notation : r(a1, a2, ..., an) o r est le nom de la relation

45

Dfinitions

TUPLE (ou LIGNE) : ligne du tableau, instance du lot d'informations. Une relation est donc un ensemble de tuples et elle ne possde pas deux tuples identiques. COLONNE : attribut ou ensemble des valeurs de l'attribut

46

Dfinitions

DOMAINE : ensemble de dfinition des valeurs des attributs.

Soit r(a1, a2, ..., ai, ..., an) une relation, la liste des domaines: D1, D2, ...,Di, ..., Dn dans laquelle Di est le domaine de l'attribut ai . La relation r est un sous-ensemble du produit cartsien: D1 x D2 x ... x Di x ... x Dn.

47

Dfinitions

ARITE d'une relation : nombre de ses attributs. La relation r(a1, a2, ..., ai, ..., an) est d'arit n. L'arit d'une relation est aussi le nombre de colonnes de la table. CARDINALIT d'une relation r : nombre de tuples (ou de lignes) de la table.

48

Dfinitions

CL D'UNE RELATION r: ensemble d'attributs dont les valeurs identifient un tuple et un seul de la relation r. Une relation possde toujours au moins une cl, c'est-dire l'ensemble de ses attributs: deux tuples d'une relation diffrent entre eux au moins par les valeurs d'un attribut.

49

Dfinitions

CL CANDIDATE : cl d'une relation telle que tout sous-ensemble d'attributs de cette cl n'est pas une cl. Une cl candidate constitue donc un sous-ensemble minimal d'attributs pouvant jouer le rle de cl. CL PRIMAIRE : la cl unique qui sera retenue parmi les cls candidates. Par la suite, la cl primaire d'une relation sera dsigne par le terme cl .

50

Dfinitions

CL ETRANGERE dans une table :

cl primaire ou candidate dans une autre table

51

Dfinitions

CONTRAINTES D'INTGRIT : rgles smantiques auxquelles les donnes dune base doivent obir. Elles font partie du schma conceptuel. But : garantir la cohrence des donnes lors des mises jour de la base (les donnes ne sont pas indpendantes)

52

Dfinitions

Contrainte dintgrit :

Contrainte de domaine :
exprime la smantique des donnes au moyen de proprits vrifies par les attributs

Contrainte dintgrit dentit :

une table doit toujours avoir une cl primaire

Contrainte dintgrit rfrentielle :

toute valeur attribue une cl trangre dans une table doit exister dans la table o cette cl se retrouve comme cl primaire ou candidate

53

Par exemple dans la relation r (employ, salaire, patron): "un salaire est compris entre 1 000 et 2 000 " "un employ n'a qu'un seul patron" "un patron a au plus 15 employs" sont des contraintes d'intgrit dfinies sur la relation r.

ALGEBRE RELATIONNELLE
Elle dfinira un cadre formel pour la dfinition d'un langage de manipulation de donnes dont les primitives seront les oprations de base. Ces primitives constitueront des oprations de haut niveau comparables certains traitements classiques de fichiers (tri, fusion, extraction, dition)

54

Somme et diffrence

La somme de deux relations r et s, note r s est l'union ensembliste des tuples de r et des tuples de s. La diffrence r - s est l'ensemble des tuples de r qui n'appartiennent pas s.

55

Produit cartsien

Soient les relations r et s d'arits respectives k1 et k2. Le produit cartsien r X s est la relation d'arit k1 + k2 dont les tuples sont le rsultat de la concatnation des tuples de r avec ceux de s.

56

Projection

Projection Ps(r) d'une relation r sur un sousensemble s de ses attributs : relation obtenue en supprimant dans la table les colonnes des attributs qui n'appartiennent pas s et en ne gardant dans la nouvelle table ainsi dfinie qu'une seule occurrence de chaque tuple.

57

Slection

Soit :

un ensemble d'oprateurs arithmtiques et logiques: =, , <,>, OU, ET, NON des oprandes: attributs et constantes une formule F dfinie sur les attributs de r par les oprateurs et les oprandes.

La slection dfinie par F sur r, note sF (r), est une relation, ensemble des tuples de r qui vrifient la formule F.
58

Date
1/02 2/02 2/02 3/02 3/02

Vendeur
JFD JFD RF LM RF

Secteur
17 17 17 19 19

Client
DUPONT DURAND DUPONT MARTIN BRUYNE

Code
C1212 C1217 C1212 C1420 C1435

Adresse
LIEGE BRUXELLES LIEGE NIVELLES NAMUR

vente
3050 4200 1200 12500 5200

4/02
4/02

LM
JFD LM

17
17 17

DUPONT
DAMS DURAND

C1212
C1120 C1217

LIEGE
VIRTON BRUXELLES

4800
11200 7500

59

5/02

Intersection

Intersection de 2 tables r1 r2 = r1 - ( r1 - r2) est dfinie comme une table qui est constitue des tuples communs aux relations r1 et r2

60

Jointure

Jointure de 2 relations r et s suivant la relation i q j ( est un oprateur, i et j les rangs des attributs respectivement dans r et s) : ensemble des tuples du produit cartsien r x s qui satisfont la relation i j. On la note : rs
iqj

61

i et j peuvent tre remplacs par le nom des attributs correspondants. Cas particulier : quijointure rs
i=j

Schma relationnel

Rgles de transformation dun diagramme de Bachman en un schma relationnel :

62

Tout segment est transpos en une relation Une relation issue d'un segment propritaire se voit attribuer, comme cl, l'identifiant du segment et comme proprits les attributs du segment. Une relation issue d'un segment membre ayant un identifiant, se voit attribuer, comme cl, l'identifiant du segment et comme proprits les attributs du segment ainsi que le ou les identifiants du ou des segments propritaires. Une relation issue d'un segment membre n'ayant pas d'identifiant, se voit attribuer, comme cl, le ou les identifiants du ou des segments propritaires et comme proprits les attributs du segment membre.

Les formes normales

63

Bibliothque
Titre

(hypothse : 1 auteur/livre)

Date achat

Prix TVAC

Auteur

Info auteur

Germinal
Le rouge et le noir Les mots La bte humaine

10/05/90

22.5

Emile Zola

1840-1902

05/08/97 01/02/98 01/06/97

25 17 30

Stendhal Jean-Paul Sartre Emile Zola

1783-1842 1905-1980 1840-1902

64

Titre Germinal Le rouge et le noir Les mots La bte humaine

Date_achat 10/05/90 05/08/97 01/02/98 01/06/97

Prix TVAC 22.5 25 17 30

Auteur Emile Zola Stendhal Jean-Paul Sartre Emile Zola

Auteur Emile Zola

Info auteur 1840-1902

Stendhal Jean-Paul Sartre

1783-1842 1905-1980

Dcomposition d'une relation universelle

Relation universelle : Table unique dont le schma est compos par union de tous les attributs des tables constituant la base Dcomposition : Remplacement dune relation R(A1,A2, ,Am) par une collection de relations R1, R2, , Rn obtenues par des projections de R sur des sous-ensembles dattributs dont lunion contient tous les attributs de R Dcomposition sans perte : Dcomposition dune relation R en R1, R2, , Rn telle que on ait : R = R1 R2 Rn

66

Relation Voiture

NV

Type

Marque Puissance Couleur

872RH75 P206A Peugeot

Bleue

975AB80 P206A Peugeot

Rouge

67

Dcomposition 1
NV Type Couleur Bleue

872RH75 P206A

975AB80 P206A

Rouge

Type

Marque Puissance 7

P206A Peugeot

68

Dcomposition 2
NV
872RH75 975AB80 Type P206A P206A Puissance 7 7 Type P206A

Type
P206A P206A Couleur Bleue Rouge Marque Peugeot

69

Relations Vin1 et Vin2

NV
100 200

Cru
Volnay Chablis

Qualit
Moyen Excellent

300 400 500

Chablis Volnay Sancerre

Moyen Mdiocre Excellent

Cru
Volnay

Anne
1992

Degr
11.5

Chablis Chablis Sancerre

1997 1999 2002

12.3 12.1 12.0

Dpendance fonctionnelle
Dpendance fonctionnelle : Soit une relation R(A1,A2, , An), et X et Y des sousensembles de {A1,A2, , An}. Y dpend fonctionnellement de X (XY) si pour tout tuple t1 et t2 de R, on a : X(t1) = X(t2) => Y(t1) = Y(t2) Cl de relation : Sous-ensemble X des attributs dune relation R(A1,A2, , An) tel que 1. X A1 A2 An 2. Il nexiste pas de sous-ensemble Y X tel que Y A1 A2 An

71

Dpendance fonctionnelle
Dpendance fonctionnelle lmentaire: Dpendance fonctionnelle de la forme X A, o A est un attribut unique nappartenant pas X et o il nexiste pas X X tel que X A

72

Forme normale 1
Pre (numro national, nom, prnom, prnom_enfants)
NN Nom Prenom
Andr Ren

Prenom_ enfants
Paul Anne Eric Jol Vincent

70101210130 Dupont 68042110331 Durand

73

Forme normale 1
NN
70101210130 68042110331

Nom
Dupont Durand

Prenom
Andr Ren

NN 70101210130 70101210130 70101210130

Prenom_enfant Paul Anne Eric Jol Vincent

74

68042110331 68042110331

Forme normale 2
Tarif (nom, adresse, article, prix)
Nom Adresse Article Prix

Dupont Dupont Durand Durand

Angleur Angleur Mons Mons

Bureau Chaise Bureau Chaise

420 100 400 110

75

Forme normale 2
Nom Dupont Article Bureau Prix 420

Dupont Durand Durand Nom Dupont Durand

Chaise Bureau Chaise Adresse Angleur Mons

100 400 110

76

Forme normale 3
Vente(date, vendeur, nom_client, adresse_client)
Date 25/02/02 11h 25/02/02 12h Vendeur Dupont Durand Nom client Detaille Quevy Adresse client Bruxelles Bruxelles

06/03/02 9h
10/03/02 10h

Durand
Dupont

Labro
Detaille

Lige
Bruxelles

77

Forme normale 3
Date
25/02/02 11h

Vendeur
Dupont

Nom client
Detaille

25/02/02 12h
06/03/02 9h 10/03/02 10h

Durand
Durand Dupont

Quevy
Labro Detaille

Nom client Detaille Quevy

Adresse client Bruxelles Bruxelles Lige

78

Labro

Forme normale de Boyce-Codd

Stage(personne, sport, entraneur)
Personne Paul Anne Jol Sophie Sport tennis Entraneur Durand

escalade Van Loock tennis tennis Durand Detaille

79

Paul

escalade Van Loock

Forme normale de Boyce-Codd

Personne
Paul
Anne Jol Sophie Paul

Entraneur
Durand
Van Loock Durand Detaille Van Loock

Entraneur
Van Loock Durand

Sport
escalade tennis tennis

80

Detaille

PARTIE III
La modlisation objet avec UML
P. Bourmanne

D. Bayers

81

PREREQUIS

Relire le document ConceptionObjet.pdf de P. Bourmanne (cours de POO)

82

INTRODUCTION
PLAN : - Introduction : lapproche objet - UML : introduction - UML : dfinition - UML : les trois points de vue de la modlisation - UML : les diagrammes
83

Introduction : lapproche objet

La mtaphore du Client et du Serveur : syllabus Concepts et mthodes de la programmation par objets dA. Clarinval Un programme orient objets est conu et ralis comme un rseau dobjets clients et serveurs les uns des autres, qui schangent des messages.

84

UML : introduction

UML = Unified Modeling Language (langage unifi pour la modlisation objet) Norme de standardisation des applications dveloppes selon le concept de programmation objet, labore en 1994 par les Amricains G. BOOCH et J. RUMBAUGH et le Sudois I. JACOBSON pour la socit "Rational". Cette norme - base sur la modlisation et la formalisation de projets informatiques, permettant de quantifier les besoins, ressources et relations existantes entres eux - facilite la r-utilisation des composants programms d'une application l'autre. Standardis par lOMG (Object Management Group) depuis 1997 La mthode UML simplifie le processus complexe de conception d'un systme informatique en dfinissant 3 points de vue (9 diagrammes) de modlisation . Utilis par des centaines de projets dans le monde Indispensable votre formation dinformaticien

85

UML : dfinition
UML est un langage danalyse et de conception se basant sur la cration de modles successifs de plus en plus affins afin de mettre en place une solution au problme tudi. Le cadre de cette modlisation est orient objet. UML a pour objectif de se rendre indpendant de certaines parties techniques comme par exemple le langage de programmation. Les diffrentes phases du dveloppement avec UML peuvent tre reprsentes au moyen dune srie de diagrammes permettant de comprendre de manire visuelle les concepts dfinis. Tous les modles senchanent en passant de lanalyse la conception, gagnant en complexit, saffinant au fur et mesure pour arriver llaboration finale du modle. Les diagrammes permettent de comprendre sous diffrents angles la globalit du cas tudi en prsentant une vue fonctionnelle, statique et dynamique de celui-ci. Chaque diagramme exprime une partie de la structure totale, tout en tant un aspect particulier du systme. Les diagrammes sont crs par un modlisateur (analyste); ils doivent gnralement tre valids par un expert mtier (non informaticien)

86

MODELE, ANALYSE ET CONCEPTION

Modle =

description abstraite dun systme ou dun processus reprsentation simplifie qui permet de :

Comprendre Simuler

Modlisation =

Description dun problme : ANALYSE Description de la solution dun problme : CONCEPTION

87

UML : OBJECTIFS ET UTILISATION

Objectif : Fournir une reprsentation de concepts qui facilite et rende efficace la communication entre les diffrents protagonistes dun projet :

Informaticiens Experts mtier Utilisateurs

Utilisations :

Analyser et concevoir des logiciels informatiques Communiquer sur des processus logiciels ou dentreprises Prsenter sous forme dtaille lanalyse dun systme (reprsentation graphique, vue dun systme) Documenter un systme, un processus ou une organisation existants

88

UML : les 3 points de vue de la modlisation

FONCTIONNEL
diagramme de cas dutilisation

STATIQUE
diagramme de classes diagramme de packages diagramme dobjets diagramme de structure composite

DYNAMIQUE
diagramme dtats diagramme dactivit diagramme de squence diagramme de collaboration (ou de communication)

89

UML : les 3 points de vue de la modlisation (suite)

Statique:

Identifier les concepts du mtier, les modliser en tant que classes Identifier les associations pertinentes entre les concepts Rflchir aux multiplicits chaque extrmit dassociation Ajouter des attributs aux classes Rpertorier tous les messages que les acteurs peuvent envoyer au systme et recevoir

Dynamique:

Fonctionnel:

Dtailler les diffrentes faons dont les acteurs peuvent utiliser le systme.

90

UML : diagrammes
Point de vue fonctionnel :
Diagramme de cas dutilisation : Premire tape dans le processus de modlisation, un cas dutilisation dcrit textuellement une situation, une fonctionnalit, dans la problmatique tudie. Il sagit dun scnario typique accompli par un ou plusieurs objets modliss. Le diagramme de cas dutilisation illustre les liens entre les diffrents cas et les intervenants dans les diffrents scnarios considrs.

Point de vue statique :

Diagramme de classes : Le diagramme de classes a pour caractristique dillustrer les diffrents acteurs, leurs compositions et leurs associations. Une classe est la description dun groupe dobjets possdant des proprits communes ainsi que des comportements similaires. Lobjet est linstance dune classe particulire. Le diagramme de classes est une reprsentation statique des diffrentes classes du modle dvelopp.

91

UML : diagrammes (suite)

Point de vue dynamique :
Diagramme dtats : Ce type de diagramme dcrit les diffrentes transitions dtats qui soprent au cours du temps de vie dun objet. Un tat se caractrise par sa dure et sa stabilit, il reprsente une conjonction instantane des valeurs des attributs d'un objet et des liens avec dautres objets. Les diffrents tats de lobjet sont lis entre eux et leurs transitions sont dclenches par certains vnements. Diagramme dactivit : Le diagramme dactivit reprsente les activits qui ont lieu dans le droulement dun processus. Ils reprennent des concepts des diagrammes dtats insistant plus sur la modlisation de certaines activits avec des notions de concurrence et de synchronisation. Les diffrentes activits reprsentent les ralisations de certaines oprations. Le diagramme permet donc de reprsenter la succession des oprations au cours des flux de travail (workflows).

92

UML : diagrammes (suite)

Diagrammes dinteraction : Le comportement dynamique des objets et des acteurs est

reprsent au moyen des diagrammes dinteraction :

a) Diagramme de squence : Dans ce type de diagramme, il se dgage une structure temporelle des messages qui sont changs entre les diffrents objets impliqus dans la ralisation dun cas dutilisation. La dimension verticale montre les enchanements temporels des messages. Les rponses des diffrents objets aux messages reus sont aussi clairement reprsentes et comprhensibles (dynamique de fonctionnement).
b) Diagramme de collaboration : Les diagrammes de collaboration sont une autre forme de reprsentation du comportement dynamique des objets illustrant la ralisation dun cas dutilisation. Cette reprsentation est quivalente, mais elle se focalise davantage sur lorganisation des objets : ils mettent en vidence les relations entre objets par la disposition des objets.

93

UML : POINT DE VUE STATIQUE

PLAN: - Concepts et dfinitions de base:
-

Diagramme de classes Classe et objet Attribut et opration Association Agrgation et composition Gnralisation, super-classe, sous-classe Dpendance Package

Exercice : diagrammes de classes

94

DIAGRAMME DE CLASSE

Objectif : dcrire la structure des entits manipules par les utilisateurs Reprsente la structure dun code orient objet Reprsentation :
Classes (avec attributs et oprations), relies par:

des associations, ou des gnralisations

95

REPRESENTATION DUNE CLASSE DANS UN DIAGRAMME DE CLASSE

Classe1
nomA1 : type = valeur initiale nomA2 : type = valeur initiale

Nom de classe Attributs

nomM1 ( nomArg1:type = valeurDefaut, ) : typeRetourn nomM2 ( nomArg1:type = valeurDefaut, ) : typeRetourn

Mthodes

96

CLASSE ET OBJET

Classe :

Reprsente la description les mmes caractristiques type dobjets Exemples : classe Voiture classe Personne

abstraite dun ensemble dobjets possdant

Objet :
-

Entit aux frontires bien dfinies, possdant une identit et encapsulant un tat et un comportement instance (occurrence) dune classe Exemples : ma voiture est une instance de la classe Voiture Ch. Mathy est une instance de la classe Personne

97

ATTRIBUT ET OPERATION

Attribut :

Reprsente un type dinformation contenu dans une classe Exemples : cylindre, numro dimmatriculation de la classe Voiture Cas particulier : attribut driv Reprsente un lment de comportement (service) contenu dans une classe Exemples : dmarrer(), avancer(), tourner() de la classe Voiture

Opration :

98

Visibilit des attributs et des oprations

+ public # protected - private Soulign : static (variables et oprations de classe)

99

ASSOCIATION

Association:

Reprsente une relation smantique durable entre 2 classes Exemple : la relation possde est une association entre les classes Personne et Voiture : une personne peut possder des voitures
Personne Voiture

possde
1

> 0 .. *

100

ASSOCIATION : caractristiques

Lassociation est nomme (indication en italique - sur le type de la relation). Mme si le terme qui nomme lassociation semble privilgier un sens, une association entre concepts est par dfaut bidirectionnelle. Donc, implicitement, lexemple cit inclut galement le fait quune voiture est possde par une personne. Par dfaut, un lien est donc navigable dans les 2 sens. Un objet (dit objet utilisateur) peut utiliser les services dun autre objet (dit objet utilis) selon le sens de navigation indiqu par lassociation. Pour utiliser un service dun objet, lobjet utilisateur envoie un message lobjet utilis.

101

ASSOCIATION : caractristiques (suite)

Indication de multiplicit aux 2 extrmits de lassociation: intervalle dentiers >= 0 ou * : nombre dobjets pouvant participer la relation avec un objet de lautre classe. Lindication par dfaut (non note) est 1..1 que lon peut galement noter 1. Exemple : une personne peut possder entre 0 et un nombre quelconque de voitures; une voiture est possde par une seule personne
(= nombre quelconque)

Possibilit dindiquer le rle jou par chaque objet dans la relation. Ex. entre les classes Societe et Personne : employeur, employe La personne voit la socit comme son employeur; la socit voit la personne comme son employ En gnral, les rles sont indiqus si plusieurs associations relient 2 classes.

102

Valeurs conventionnelles de multiplicit

1 0 .. 1 M .. N * 0 .. * 1 .. * Un et un seul (par dfaut) Zro ou un De M N (entiers) De zro plusieurs De zro plusieurs De un plusieurs

103

AGREGATION

Agrgation : cas particulier dassociation non symtrique* : une classe joue un rle prdominant par rapport lautre. Exemple courant: agrgation exprimant une relation de contenance. Inutile de nommer cette association : implicitement, elle signifie : contient, est compos de
lagrgat utilise les services du composant, pas linverse

104

AGREGATION FORTE: composition

Agrgation forte : agrgation non partage :

Donc, multiplicit du ct de lagrgat : 1

un lment ne peut appartenir qu un seul objet, dit agrgat composite

Responsabilit de lagrgat composite concernant le cycle de vie des parties :

la destruction de lagrgat composite entrane la destruction de tous ses lments

Exemples : le solde dun compte les dents dune personne

105

AGREGATION FAIBLE

Agrgation faible :

agrgation partageable Lexistence du composant ne dpend pas de celle du compos un mme composant peut faire partie de plusieurs agrgats

Exemples : une quipe sportive est compose de personnes une classe de 2me info est compose de personnes

106

GENERALISATION

super-classe : classe plus gnrale relie une ou plusieurs autres classes spcialises (sous-classes) par une relation de gnralisation Les sous-classes hritent des proprits de leur super-classe et peuvent comporter des proprits spcifiques supplmentaires Exemples : les voitures, les bateaux, les avions sont des moyens de transport Une classe abstraite ne sinstancie pas. Elle se note en italique.

107

GENERALISATION : EXEMPLE
MoyenDeTransport
marque
modele vitesseMax

Voiture numeroImmatriculation

Bateau nombreVoiles

108

cylindree

DEPENDANCE

Relation dutilisation unidirectionnelle Lien temporaire entre objets : association momentane Par exemple : un objet A:a reoit en paramtre dun message une rfrence sur un objet C:c dpendance de A vers C (A utilise C)

A
109

>C

PACKAGE

Package :

mcanisme de regroupement dlments (classes et associations) Espace de noms

Structuration dun modle en packages:

Cohrence (regroupement des classes selon la smantique) Indpendance (minimisation des relations entre classes de packages diffrents)

Exemple : package Clientle et package Voitures

110

CONVENTION DE NOMMAGE

111

Nom de classe : commence par une majuscule Ex. : Client, Aeroport Nom dattribut, dopration, dassociation, de rle : commence par une minuscule, puis, ventuellement plusieurs mots concatns commenant par une majuscule Ex. : nom, numTel, heureDepart Nom dassociation en italique, et souvent par forme verbale (active ou passive) avec ventuellement un petit triangle dirig vers la classe dsigne par la forme verbale Ex. entre les classes Societe et Personne: <Travaille pour, <Est employee par Nom de rle : forme nominale, ou participe prsent/pass Ex. entre les classes Societe et Personne : employeur, employe Ex. entre les classes Client et Compte : titulaire (ou possdant), possd Prfrable : pas daccents, de caractres spciaux

EXERCICE

Etude dun systme de rservation de vol (cf. pages 80 et suivantes de UML 2 par la pratique , P. Roques, Eyrolles, 2005, 4me dition ou pages 66 et suivantes dans la 2me dition: http://www.gramme.be/infopb/coursSL\analyse\references\externes/Modelisation_statique_by_Roques.pdf ) Notions supplmentaires vues dans lexercice ( noter !) :

Instance persistante Attribut driv Classe dassociation Contrainte sur une association({ordered}) Qualificatif

112

A FAIRE A DOMICILE

Lire le chapitre 1 Objet et message du syllabus Concepts et mthodes de la programmation par objets dA. Clarinval Lire le chapitre 3 Le schma conceptuel de donnes : 3 Apports du paradigme objet du syllabus Mthodes danalyse dA. Clarinval

113

UML : POINT DE VUE FONCTIONNEL

PLAN : - Concepts et dfinitions de base:
-

Acteur (principal/secondaire) Cas dutilisation (CU) Scnario

Exemples de cas dutilisation

114

Exemple de diagramme de cas dutilisation

Entrer Dbloquer les portes Porteur de carte Capteur alarme incendie Sortir

Contrler les fraudes Grer les cartes Gardien Administrateur

Systme de contrle daccs

Exemple de diagramme de cas dutilisation

Retirer de largent Client

Banque centrale

Consulter son compte

Transporteur de billets

Recharger en billets

Assurer la maintenance

Technicien

Distributeur de billets

Diagramme de cas dutilisation

Un diagramme de cas dutilisation :

dcrit

les acteurs les cas dutilisation le systme des descriptions textuelles

contient

117

Le systme

Le systme est un ensemble de cas dutilisation Le systme ne comprend pas les acteurs.
Nom du systme

Nom du systme

118

Acteur

lment extrieur au systme qui interagit avec le systme Rle typique jou par un humain ou un systme connexe par rapport au systme
Ex. : un client, un guichetier, un responsable maintenance,

Une mme personne peut jouer plusieurs rles

Ex. : Maurice est directeur mais peut faire le guichetier

Plusieurs personnes peuvent jouer un mme rle

Ex. : Paul et Pierre sont deux clients

Un acteur nest pas forcment un tre humain (dispositif matriel, )

Ex. : un distributeur de billets peut tre vu comme un acteur

119

Un acteur excute un ou plusieurs cas dutilisation

Acteur

Est reprsent par:

un petit bonhomme (stick man) avec son nom dessous ou par un rectangle contenant le mot-cl << actor>> avec son nom dessous ou Par un mlange de ces 2 reprsentations <<actor>> Nom de lacteur

Nom acteur

Nom de lacteur

acteur humain

acteur non humain

Pour les identifier :

Quelles sont les entits externes au systme qui interagissent directement avec le systme ?

120

Description des acteurs

Pour chaque acteur :

choisir un identificateur reprsentatif de son rle donner une brve description textuelle

Guichetier

121

Un guichetier est un employ de la banque. Interface entre le systme informatique et les clients. Peut effectuer une srie doprations : cration d un compte, dpt et retrait d argent, etc.

Utilit des acteurs

La dfinition dacteurs permet

didentifier les cas dutilisation

Ex. : que peut faire un guichetier ? un client ? le directeur ?

de voir le systme de diffrents points de vues de dterminer des droits daccs par type dacteur de fixer des ordres de priorit entre acteurs ...

122

Cas dutilisation

Un cas dutilisation (use case) dcrit:

Une fonctionnalit du systme vue par un acteur (et utile ce dernier) une suite dinteractions entre un utilisateur et le systme qui produit un rsultat observable et intressant pour un acteur particulier Un comportement attendu du systme du point de vue dun ou de plusieurs acteurs Un service rendu par le systme

123

Analyse : CU dcrit CE QUE le futur systme devra faire, sans spcifier COMMENT il le fera

Cas dutilisation

Est reprsent par un ovale. Le nom du cas est inclus dans lellipse ou figure en-dessous Reli par des associations participe ses acteurs Lensemble des cas dutilisation dcrit exhaustivement les fonctionnalits du systme (1 CU : 1 fonction mtier du systme) Pour les identifier : par acteur, quelles sont les diffrentes manires dutiliser le systme ?
Nom du CU
Nom CU

Nom du CU

Liste des proprits (sommaire didentification)

124

Description des cas dutilisation

Pour chaque cas d utilisation

choisir un identificateur reprsentatif : commencer par un verbe linfinitif, puis un complment du point de vue de lacteur (pas du point de vue du systme) raliser une description dtaille plus ou moins formelle : prciser ce que fait le systme, ce que fait lacteur

Les cas dutilisation ne doivent pas se chevaucher Si un cas dutilisation concerne beaucoup dacteurs, il faut probablement le dcouper en plusieurs CU

125

Exemple de description dtaille dun CU: sommaire didentification

Titre : Retirer de largent Rsum : CU qui permet un client de la banque de retirer de largent Acteurs : client Prcondition : Le distributeur contient des billets, il est en attente dune opration, il nest ni en panne, ni en maintenance Dbut : lorsqu un client introduit sa carte bancaire dans le distributeur. Fin : lorsque la carte bancaire et les billets sont sortis. Postcondition : Le GAB contient moins de billets quau dbut du CU. Transaction de retrait enregistre par le GAB.
Hors CU, car fonctionnalit de la banque du client : Si de largent a pu tre retir, la somme dargent sur le compte est gale la somme d argent quil y avait avant, moins le montant du retrait. Sinon la somme d argent sur le compte est la mme quavant.

Retirer de largent

126

Exemple de description dtaille dun CU: description des scnarios

Scnario nominal = droulement normal :
(1) le client introduit sa carte bancaire (2) le systme lit la carte et vrifie si la carte est valide (3) le systme demande au client de saisir son code (4) le client saisit son code confidentiel (5) le systme vrifie que le code correspond la carte (6) le client choisit une opration de retrait (7) le systme demande le montant retirer

Retirer de largent

Scnarios derreurs (se terminent brutalement) :

Carte invalide : au cours de l tape (2) si la carte est juge invalide, le systme affiche un message derreur, rejette la carte et le cas d utilisation se termine. Code erron (pour la 3me fois) : au cours de l tape (5) ...

Scnarios alternatifs

127

Montant demand suprieur au solde du compte Code erron (pour la 1re ou 2me fois)

Exemple de description dtaille dun CU: exigences non-fonctionnelles

Exigences non-fonctionnelles : (A) Performance : le systme doit ragir dans un dlai infrieur 4 secondes, quelle que soit laction de lutilisateur. (B) Rsistance aux pannes : si une coupure de courant ou une autre dfaillance survient au cours du cas dutilisation, la transaction sera annule, l argent ne sera pas distribu. Le systme doit pouvoir redmarrer automatiquement dans un tat cohrent et sans intervention humaine. (C) Rsistance la charge : le systme doit pouvoir grer plus de 1000 retraits d argent simultanment ...

Retirer de largent

128

Exemple de description dtaille dun CU: besoins IHM

Besoins dIHM : dispositifs dentre-sortie la disposition de lacteur principal:
Retirer de largent

-Lecteur de carte bancaire -Clavier numrique -Ecran pour laffichage des messages du GAB -Touches autour de lcran -Distributeur de billets -Distributeur de tickets

129

Remarque : les IHM seront appliques lors de votre cours de POO/java en 2me et de votre cours de Dveloppement Web et applications distribues en 3me

Scnario

CU = ensemble de scnarios dutilisation dun systme relis par

un but commun du point de vue dun acteur

Le CU a un dbut et une fin identifis Scnario = succession particulire denchanements, sexcutant du dbut la fin du CU. Un enchanement = unit de squence dactions Un CU contient en gnral: Lobjectif de

130

un scnario nominal diffrents scnarios alternatifs (qui se terminent de faon normale) des scnarios derreur (qui se terminent en chec)

lacteur principal est atteint

DESCRIPTION TEXTUELLE DUN CU (en rsum)

Non normalis par UML Exemple:

1) Identification :

Titre Rsum Dates de cration/modification Version Responsable

2) Description des scnarios (nominal, alternatifs, derreur) + prconditions + postconditions 3) Optionnel : Exigences non-fonctionnelles (fiabilit, frquence, confidentialit, intgrit, ) et besoins IHM

131

Acteurs principaux et secondaires

Acteur principal dun CU

Celui pour qui le CU produit un rsultat observable A gauche des CU Rle indiqu ventuellement sur lassociation ct acteur : <<principal>> (valeur par dfaut) Celui pour qui le CU ne produit pas un rsultat observable par lutilisateur Souvent sollicits pour des informations complmentaires Peuvent uniquement consulter ou informer le systme (pas dobjectif part entire de la part de lacteur secondaire) A droite des CU Rle indiqu ventuellement sur lassociation ct acteur : <<secondaire>> Ex. : systme dauthentification appel par le distributeur de billets

Acteur secondaire dun CU

132

Relations entre acteurs et cas dutilisation

Guichetier

Crer Un Compte

Relation dassociation ( participe ) :

Lien entre un acteur et un cas dutilisation quil peut excuter

Un cas dutilisation doit tre reli au moins un acteur

133

Relations entre cas dutilisation

include

B
Retirer de largent

A
fragment Identifier le client

134

Relation dinclusion (utilisation) Utilise pour enlever la rptition entre plusieurs cas dutilisation Utilisation du strotype include Un cas A (identifier le client) est inclus dans un cas B (retirer de largent) si le comportement dcrit par le cas A est inclus dans le comportement de B Le CU de base B incorpore explicitement le CU A de faon obligatoire un endroit spcifi dans ses enchanements Le CU inclus peut porter le strotype fragment

Relations entre cas dutilisation (2)

Sur demande du client

Relation dextension

extend

optionnelle : le CU de base

Retirer de largent B incorpore un CU A de faon Consulter solde optionnelle : Ex. Le CU Consulter solde se fait uniquement sur demande du client de la banque; il tend le CU Retirer de largent

135

Utilise lorsquun cas d'utilisation est semblable un autre, mais ajoute de la fonctionnalit. Utile pour reprsenter les exceptions Utilise pour dcrire une variation du comportement normal Souvent soumise condition exprime sous la forme dune note Utilisation du strotype extend

Relations entre cas dutilisation (3)

Relation de gnralisation Un cas A est une gnralisation dun cas B si B est un cas particulier de A
A Dposer de largent Dposer du liquide

Dposer des chques

136

Dposer de largent est cas dutilisation gnralis. Il devient abstrait (italique) car il ne sinstancie pas directement, mais uniquement par le biais de lun des 2 cas spcialiss Distinguer 2 CU spcialiss possibilit de leur associer des acteurs secondaires diffrents

Relations entre acteurs

Uniquement relation de gnralisation/spcialisation A est une gnralisation de B si tous les CU accessibles A sont accessibles B, mais pas linverse

137

Structuration en package

Si les cas dutilisation sont nombreux

les regrouper par acteur

Oprations client Oprations administrateur etc. Grer les contrats Grer les clients Etc.

les regrouper par domaine fonctionnel

Grer les clients

138

ETAPES DE LA MODELISATION FONCTIONNELLE

Identification des acteurs Identification des CU (par acteur) Ralisation des diagrammes de CU Description textuelle des CU (scnarios) * Organisation des CU (relations entre CU + packages)

PUIS description graphique * * des CU : Modlisation dynamique: diagramme de squence systme diagramme dactivit

139

* Pour communiquer facilement avec les utilisateurs et sentendre sur la terminologie mtier employe * * Pour mieux montrer la succession des enchanements

EXEMPLES DE CAS DUTILISATION

Etude dun guichet automatique de banque (GAB) (cf. pages 19 et suivantes de UML 2 par la pratique , P. Roques, Eyrolles, 2005) Etude dune caisse enregistreuse (cf. pages 52 et suivantes de UML 2 par la pratique , P. Roques, Eyrolles, 2005)

Notion supplmentaire vue ( noter !) :

140

Navigabilit sur lassociation

UML : POINT DE VUE DYNAMIQUE

PLAN: - Concepts et dfinitions de base:
-

Diagramme de squence (#140) Diagramme de collaboration (non vu en 2me) (#147) Diagramme dtats (#148)
-

Etat Transition Evnement Message Condition Effet : action ou activit

Diagramme dactivit (#162) Interaction Overview Diagram (non vu en 2me) (#178)

141

Exemples de diagrammes dynamiques UML

Rle des diagrammes dynamiques

Montrer la succession des enchanements Montrer la chronologie des messages envoys et reus Montrer quel moment un acteur est sollicit

142

DIAGRAMME DE SEQUENCE: rle

Visualisation des interactions entre objets selon un point de vue temporel Insistance sur la chronologie des envois des messages Mise en vidence du fonctionnement du programme avec visualisation du temps

143

DIAGRAMME DE SEQUENCE: reprsentation

Reprsentation des objets :

nomObjet : NomClasse

rectangle avec le nom de lobjet soulign ligne de vie

Axe du temps

144

DIAGRAMME DE SEQUENCE : reprsentation (suite)

Acteur principal : gauche Objet reprsentant le systme en bote noire au milieu Acteurs secondaires : droite Echange de message : flche horizontale, de lmetteur vers le destinataire
acteurPrincipal
systeme acteurSecondaire
Transition : instant dmission dun message; peut tre nomm (ex. : x,y)

Contrainte temporelle

145

{y-x < 5s } x y

message

DIAGRAMME DE SEQUENCE : reprsentation (suite)

Flche de retour en pointill

:PorteurCarte :GAB :SystemeAutorisation Demande autorisation
Bande rectangulaire sur ligne de vie : Priode dactivit = temps pendant lequel un objet effectue une action

Autorisation (solde)

146

DIAGRAMME DE SEQUENCE : utilisations

Documentation des CU (description de linteraction, pas de dtail de synchronisation):

Diagramme de squence systme :

Scnario nominal

Diagramme de squence enrichi = Diagramme de squence systme +

Principales actions internes du systme Renvois aux scnarios alternatifs et derreur

Usage + informatique : messages au sens des langages de programmation

147

DIAGRAMME DE SEQUENCE : catgories de messages

Synchronisation des messages:

Message simple (objet client et serveur agissent dans le mme processus) Message synchrone (metteur bloqu: attend que rcepteur ait fini de traiter le message) Message minut (comme synchrone, sauf que lattente est limite par un timeout) Message drobant (minut par un dlai dattente nul) Message asynchrone (metteur non bloqu)

Message rflexif : un objet senvoie un message lui-mme (exemple : pour indiquer des interactions internes entre composants d un objet composite)

148

DIAGRAMME DE SEQUENCE : plus loin

Prcondition et postcondition : Prcondition

Postcondition

Inclusion : cadre ref pour faire rfrence un autre diagramme de squence Rptition : cadre loop lignes de vie Condition : cadre alt ref loop

149

DIAGRAMME DE COLLABORATION

Montre les objets, les liens qui les unissent et les messages quils schangent Mise en vidence des relations entre objets

Rem. : nappartient pas la matire de 2me

150

DIAGRAMME DETATS

= statechart = cycle de vie dune instance gnrique dune classe au fil de ses interactions avec le monde Utile : pour dcrire avec prcision des comportements complexes Seulement pour certaines classes du modle statique :

Comportement ractif: si la raction un vnement dun objet dune classe dpend de son tat tat caractrise un type de raction Ncessit dtats squentiels pour prciser une chronologie dvnements

Un objet suit globalement le comportement dcrit pour sa classe

151

DIAGRAMME DETATS : construction

Construction : Description du comportement nominal dun objet : squence dtats + transitions associes Ajout des transitions dues aux comportements alternatifs ou derreur (cf. CU) Reprsentation : graphe orient dtats et de transitions
Etat 1 Etat 2 Un objet passe par une succession dtats durant son existence

152

Etat 3

ETAT

Reprsente une situation durant la vie dun objet : Condition particulire satisfaite Activit particulire en cours Evnement particulier en attente Identification des tats : Recherche intuitive base sur lexpertise mtier Etude des attributs et des associations : valeur seuil dun attribut qui modifie la dynamique, Etablissement des interactions dans le comportement de chaque classe Un tat a une dure finie, variable selon larrive dvnements Un objet est toujours dans un tat donn pour un certain temps; il ne peut tre dans un tat inconnu ou non dfini Un tat est limage dune conjonction instantane des valeurs des attributs de lobjet et de la prsence (ou absence) de liens entre lobjet et dautres objets Etat initial : cration de linstance Etat final : destruction de linstance (il peut exister de 0 n tats finaux)
systme qui ne sarrte pas conditions de fin diffrentes

153

TRANSITION

Description de la raction dun objet suite un vnement Connexion unidirectionnelle reliant 2 tats (parfois non distincts)
Etat
Etat 1 Etat 2

Passage dun tat lautre : instantan (car objet toujours dans un tat connu) Constitution :

154

vnement dclencheur Condition de garde Effet tat cible

EVENEMENT

Occurrence dun stimulus localis dans le temps et lespace: sert de dclencheur pour que lobjet passe dun tat un autre (objet contrl par les vnements en provenance du systme, dun autre objet) 4 types : Evnements externes

Signal : rception dun message (envoi asynchrone) Call event : appel dune opration sur lobjet rcepteur (appel synchrone) Time event : passage du temps (after dure) Change event : changement de la satisfaction dune condition (when expression_boolenne)

(message au systme par un acteur, un autre objet) Evnements internes (au systme)

Le passage de faux vrai de lexpression boolenne dclenche la transition

Spcification:

155

Nom de lvnement Liste des paramtres (information circulant entre objets) Objet expditeur Objet destinataire Description de la signification de lvnement

MESSAGE

Transmission dinformation unidirectionnelle entre lobjet metteur et lobjet rcepteur Communication :

Synchrone (ex.: call event) Asynchrone (ex.: envoi dun message)

La rception du message est un vnement trait par le rcepteur

156

CONDITION (ou condition de garde)

Expression boolenne qui doit tre VRAIE lorsque lvnement arrive pour que la transition soit dclenche Concerne par :

Attributs de lobjet Paramtres de lvnement dclencheur

1 vnement plusieurs transitions possibles, si conditions de garde diffrentes Gardes dun vnement : mutuellement exclusives Notation : [condition]
Etat 1 vnement [condition] Etat 2

157

EFFET

Comportement optionnel de lobjet spcifi par une transition 2 types :

Action (non interruptible) Activit : squence atomique (non interruptible) dactions

Laction (ou les actions) correspond une opration dclare dans la classe de lobjet destinataire de lvnement A accs :

aux paramtres de lvnement aux attributs de lobjet MAJ dun attribut Appel dopration Cration/destruction dun autre objet Envoi dun signal un autre objet
vnement /effet

Exemples daction :

158

Notation : /effet

Etat 1

Etat 2

EFFET (suite)

Effet dentre : entry / Effet de sortie : exit /

Un effet dentre (de sortie) reprsente une action ou une activit qui est excute chaque fois que lon entre (sort) dans (de) ltat factorisation de leffet dclench par toutes les transitions qui entrent (sortent) dans (de) ltat

Etat A entry/A_In exit/A_Out

Remarques :

une transition rflexive entrane lexcution des effets de sortie et dentre Un vnement interne nentrane pas lexcution des effets dentre et de sortie

159

Une activit interruptible sera associe un tat, non une transition; il sagit dune activit durable (do-activity); notation : do/activit. Cas particulier : Lorsquune activit squentielle se termine, une transition automatique (sans vnement, avec garde ventuelle) est dclenche

EFFET (suite)
Points dexcution des oprations

/ opTransitionIn Etat
entry / opEntry do / opDo exit / opExit

/ opTransitionOut when(vn. interne;condition) / opChangeEventWhen after(dure) / opTimeEventAfter

160

Modlisation dun message reu/mis

Message reu vnement qui dclenche une transition entre tats Message mis action (effet) sur la transition

161

NOTATION GENERALE DU DIAGRAMME DETATS

Etat initial de lobjet : cration Etat 1
do/activit 1

Evnement(paramtres) [condition] / effet Transition avec condition et effet

Etat 2
do/activit 2

Etats avec activit durable

Etat final de lobjet : destruction

162

EXERCICE

Etude dun publiphone pices (cf. pages 156 et suivantes de UML 2 par la pratique , P. Roques, Eyrolles, 2005) Notions supplmentaires vues dans lexercice ( noter !) :

Diagramme de squence : oprateur opt Diagramme dtats :

Etat composite ou super-tat Transition :

propre (retour de lobjet au sous-tat initial) interne (pas deffet sur ltat courant) factorise (un super-tat permet de factoriser la transition)

Pseudo-tat history Envoi de message un autre objet sur dclenchement dune transition : / send cible.message

163

EXERCICE

Etude dun rveil (cf. pages 181 et suivantes de UML 2 par la pratique , P. Roques, Eyrolles, 2005)

164

DIAGRAMME DACTIVITE

Reprsentation de lensemble des actions ralises par le systme, avec tous les branchements conditionnels et toutes les boucles possibles : reprsentation de la dynamique globale du CU Graphe orient dactions et de transitions :

Transitions automatiques* :

franchies la fin des actions ventuellement gardes par des conditions boolennes mutuellement exclusives en parallle ou en squence

tapes :

165

* Pas de transition interne, ni de transition dclenche par un vnement

REPRESENTATION
dbut actions

flots
Action 1 Action 2

[Not OK]
conditions fin Action 3

dcision
[OK]

166

EXEMPLE DE TRANSITION GARDEE

Mesurer la temprature

[trop froid]
chauffer
Mesurer la temprature

[trop chaud]
refroidir

REPRESENTATION 1

REPRESENTATION 2 [trop froid] chauffer [trop chaud] refroidir

167

FLOTS DE CONTROLE

Les flots de contrle connectent des actions (rectangles avec coins arrondis) pour indiquer que laction pointe par la flche ne peut pas dmarrer tant que laction source nest pas termine
Casser loeuf

Action source

168

Sparer le blanc du jaune

Action pointe

FLOTS DOBJETS

Les flots dobjets connectent des nuds dobjets (rectangles) pour fournir des entres (inputs) aux actions. Le nom dun tat peut tre mis entre crochets ( [nomEtat] ).
Faire fondre le chocolat

chocolat

Nud dobjet :
- objet soulign - tat entre crochets

169

Input pour laction suivante

[fondu]

Exemple : activits dune commande

se renseigner La responsabilit des diffrentes activits peut tre rpartie sur diffrents objets (client, vendeur, service dexpdition) tablir un devis commander

commande [passe]

facturer

payer

commande [paye]

livrer

170

bon de livraison

BARRE DE SYNCHRONISATION

Une barre de synchronisation :

reprsente une synchronisation entre flots de contrle parallles permet douvrir (fork = barre dembranchement) ou de fermer (join = barre de jointure) des branches parallles au sein dun flot dexcution dune mthode ou dun CU

171

FORK

fork : barre dembranchement

Sparer les blancs des jaunes

Action

fork

jaunes

blancs

Nuds dobjets

172

FORK (suite)

Refroidir

Les transitions au dpart dune barre de synchronisation sont dclenches simultanment Arer

Arrter le chauffage

173

JOIN

join : barre de jointure (fusion de flots)

chocolat [fondu] join jaunes

Ajouter les jaunes au chocolat fondu

174

JOIN (suite)

Arrter le chauffage

Arer

Une barre de synchronisation ne peut tre franchie que lorsque toutes les transitions en entre sur la barre ont t dclenches

Mesurer la temprature

175

ACCEPT TIME EVENT

Accept time event

Mettre les rcipients de mousse au frigo

Accept time event

176

Attendre 3h

REGION DEXPANSION

Une rgion dexpansion est un nud dactivit structur qui sexcute 1 fois pour chaque lment dans une collection dentres. Les entres et sorties de la collection (nud dexpansion) sont matrialiss sur la frontire de la rgion (rectangle en pointills avec coins arrondis) par des petits rectangles de plusieurs compartiments
Rgion dexpansion
Mlanger les blancs la prparation chocolat

Mlange
Verser dans un rcipient

177

Rcipients

Mettre au frigo

REGION INTERRUPTIBLE

Une rgion interruptible est un ensemble de nuds et darcs dactivit au sein duquel lactivit se termine si un vnement dsign se produit. Cet vnement dinterruption apparat comme une flche clair
Faire fondre le chocolat

Rgion interruptible : gestionnaire dinterruption

Flot dexception :

chocolat est brl

chocolat [fondu]

Recette rate

178

Nettoyer et ranger

ENVOI/RECEPTION DUN SIGNAL

Envoi dun signal

Rception dun signal

179

EXERCICE

Etude dun guichet automatique de banque (GAB) (cf. pages 19 et suivantes de UML 2 par la pratique , P. Roques, Eyrolles, 2005) : diagramme dactivit pour le retrait dargent page 37

180

Interaction Overview Diagram

Fusion des diagrammes dactivit et de squence Actions remplaces par des interactions

Rem. : nappartient pas la matire de 2me

181

A FAIRE A DOMICILE

Lire le chapitre 8 Mthodes orientes objets du syllabus Mthodes danalyse dA. Clarinval

182

TABLEAU RECAPITULATIF
Diagrammes de
cas dutilisation classes
Objets Liens

Point de vue des cas dutilisation

Acteurs CU

Point de vue logique

Classes Relations Classes Objets Liens

objets

squence

Acteurs Objets Messages

Acteurs Objets Liens Messages Etats Transitions Activits Transitions

Acteurs Objets Messages

Acteurs Objets Liens Messages Etats Transitions Activits Transitions

collaboration

tats

183

activit

VERS UNE METHODE DE DEVELOPPEMENT

Cycle de vie itratif et incrmental:

Abandon de la mthode en cascade pour un dveloppement itratif Exemple : RUP (cf. le document : Le processus RUP )

184

VERS UNE METHODE DE DEVELOPPEMENT (suite)

Extrait de lavant-propos de : Guide pratique du RUP , P. Koll, Ph. Kruchten, CampusPress, 2003

185

VERS UNE METHODE DE DEVELOPPEMENT (suite)

186

VERS UNE METHODE DE DEVELOPPEMENT (suite)

187

VERS UNE METHODE DE DEVELOPPEMENT (suite)

188

6 ETAPES dun processus de dveloppement (par Expert-IT SA)

Un processus dcrit:

Quoi faire Comment le faire Qui le fera Quand le faire Pourquoi le faire utilise UML comme langage de modlisation est un guide sur la manire dutiliser UML Besoins Analyse des Business Process (BP) Recueil des besoins du projet informatique Analyse et design de lapplication Implmentation Logiciel fourni

Un processus :

6 tapes dun processus de dveloppement logiciel:

A. B. C.

D.
E. F.

189

6 ETAPES dun processus de dveloppement (suite)

1) 2)

Besoins : lentreprise, dcompose en processus mtier, subit les actions du monde extrieur Analyse des BP : analyse du systme dinformation humain: a) Est alimente par :
Business Process Modeling Notation (BPMN) Business Process Execution Language (BPEL) Business Process Modeling Language (BPML) Diagrammes dactivit Diagrammes dtat diagr. de classe Business UC b) Produit les artefacts suivants : BP Model Glossaire Model Concepts

190

6 ETAPES dun processus de dveloppement (suite)

3)

191

Recueil des besoins du projet informatique: a) Est aliment par : - diagrammes CU - diagrammes dactivit, dtat, de squence, de classes b) Produit les artefacts suivants : - modlisation des concepts (UML) - catalogue des acteurs (UML) - catalogue des CU (UML) - catalogue des business rules (rgles communes tous les CU) - catalogue des besoins non fonctionnels (temps de rponse, infrastructure Web, multilinguisme, ) - glossaire (commenc ventuellement dans lanalyse des besoins)

Non UML: rgles de bonne pratique

6 ETAPES dun processus de dveloppement (suite)

4)

Analyse et design de lapplication : (= comment va-t-on faire ?) :

1) 2)

Organisation des classes du point de vue structurel et dynamique Point de vue technique, de linfrastructure

5)

192

a) Est alimente par : - diagrammes de classe - diagrammes dynamiques b) Produit les artefacts suivants : - diagrammes de classe - modlisation dynamique Implmentation du logiciel : Do un feed-back sur les autres tapes b) Produit les artefacts suivants : - System Sequence Diagram (SSD): oprations systme avec prconditions et post-conditions

6 ETAPES dun processus de dveloppement (suite)

6)

Logiciel fourni : A chaque itration dimplmentation, un incrment est fourni au client.

Exemples dincrment : - un cran de cration de devis - association de lcran la cration dun plan mdia

Limplication du client doit tre forte Seront rgulirement runis : analyste + dveloppeur + client

NB : Recommandation : un artefact doit tre produit sur maximum 3 semaines (sinon prvoir de plus petits artefacts)

193

Travaux pratiques

Utilisation du logiciel Rational Rose Enterprise 2003

Rational Rose est le Leader Mondial en outil de Modlisation UML, c'est aussi l'un des plus coteux. Rational propose par ailleurs de nombreux outil pour faciliter la gestion des projets de dveloppement. Rational a par ailleurs pass un accord avec la Socit Ensemble pour distribuer le Rose Link qui procure une liaison bidirectionnelle synchronise entre un modle UML de Rose et un code Java ou Delphi par exemple. Avec cette combinaison le reverse engineering partir d'une application Java ou Delphi est possible. Rose Link Java est disponible pour Borland, JBuilder, Visual Caf, Oracle JDeveloper, & IBM's VisualAge.

Utilisation du logiciel Microsoft Office Visio 2003 (cf. http://www.microsoft.com/france/office/visio/decouvrez.mspx )

Cf. les 6 TPs proposs sur http://www.gramme.be/infopb/coursSL/analyse/TP

194

Avec de lexprience

Etre comptent en UML, cest comprendre ce que chaque type de diagramme peut offrir et savoir quand il faut lutiliser. Souvent, un concept pourra tre exprim au moyen de plusieurs diagrammes; lutilisateur expriment dUML saura utiliser le(s) plus adapt(s) sa modlisation.

195