UML ET LE PROCESSUS

UML ET LE PROCESSUS UNIFIE HRICHI Mohamed

Agenda Présentation générale dUML o

Déf inition inition

et Historique

o

Vue statique

o

Vue dynamique

Présentation de Processus Unifie o

Déf inition inition

o

Vue densemble

o

Démarche

de processus unif ie ie

Démarche à suivre dans le PFE hrichi.mohamed @gmail.co m

2

Agenda Présentation générale dUML o

Déf inition inition

et Historique

o

Vue statique

o

Vue dynamique

Présentation de Processus Unifie o

Déf inition inition

o

Vue densemble

o

Démarche

de processus unif ie ie

Démarche à suivre dans le PFE hrichi.mohamed @gmail.co m

2

Définition UML est un langage de mod élisation graphique Un langage universel pouvant servir de support pour tout langage orienté objet Une notation graphique simple, compréhensible même par des non in f ormaticiens ormaticiens UML f acilite acilite la communication entre Client et concepteur hrichi.mohamed @gmail.co m

3

Historique

[email protected]

4

Vues dUML Vue Statique Diagramme

de cas dutilisation Diagramme de classe Diagramme de composants Diagramme dobjets Diagramme de déploiement

Vue dynamique Diagrammes

de séquence Diagrammes de collaboration Diagrammes d'états-transitions Diagrammes d'activités [email protected]

5

Vue Statique Diagramme de cas dutilisation

Comportement de système de point de vue utilisateur Structurer les besoins des utilisateurs et les objectif s correspondants du système Un cas dutilisation sp écif ie une séquence dinteractions, entre les acteurs et le système

cas dutilisation

Fonctionnalité système

Acteur

[email protected]

6

Vue Statique Diagramme de classe

Structure statique de système Décrit le type des objets ou données du système ainsi que les di fférentes f ormes de relation statiques qui les relient entre eux Déterminer les attributs des classes Déterminer les méthodes et leurs paramètres

[email protected]

7

Vue Statique Diagramme de composants

Le diagramme de composant permet de représenter les composants logiciels dun système ainsi que les liens existant entre ces composants. Les composants logiciels peuvent être de deux origines : soit des composants métiers propres à une entreprise soit des composants disponibles sur le marché comme par exemple les composants .NET, WSDL, etc.

[email protected]

8

Vue Statique Diagramme dobjets

permet de représenter les instances des classes exprime les relations qui existent entre les objets et leurs relations à un moment donné. permet d'exprimer des contextes d'exécution

[email protected]

9

Vue Statique Diagramme de déploiement

permet de représenter larchitecture physique du système comprend des nuds correspondant aux supports physiques (serveurs, routeurs) la répartition des artef acts logiciels (bibliothèques, exécutables) sur ces nuds JBDC Connection

Save/load the highscore

Game Computer  SGBD computer 

Play the game

File System

[email protected]

Maybe a Remote a file system

10

Vue Dynamique Diagramme de séquence

représenter les interactions entre objets en indiquant la chronologie des échanges capturer le comportement de tous les objets et acteurs impliqués dans un cas dutilisation Il constitue une spécication utile pour le codage dun algorithme

[email protected]

11

Vue Dynamique Diagramme de collaboration

mettre en évidence les interactions entre objets, ainsi que les messages échangés permet de décrire les interactions entre objets intervenant dans la réalisation dun scénario dun cas dutilisation

[email protected]

12

Vue Dynamique Diagramme d'états-transitions

Létat dun objet est déf ini, à un instant donné, par lensemble des valeurs de ses propriétés Le passage dun état à un autre état sappelle transition Un événement est un f ait survenu qui déclenche une transition

[email protected]

13

Vue Dynamique Diagramme d'activités

présente un certain nombre de points communs avec le diagramme détat-transition il concerne le comportement interne des opérations ou des cas dutilisation le comportement visé sapplique aux f lots de contrôle et aux f lots de données

[email protected]

14

Présentation de processus unifie Définition : Le processus unif ié a été élaboré par Jacobson piloté par des cas d'utilisation un processus de développement logiciel itératif  et incrémental centré sur l'architecture orienté vers la diminution des risques

[email protected]

15

Vue densemble dUP L'objectif  d'un processus unif ié est de maîtriser la complexité des projets inf ormatiques en diminuant les risques. UP répond aux préoccupations suivantes : - QUI participe au projet ? - QUOI, qu'est-ce qui est produit durant le projet ? - COMMENT doit-il être réalisé ? - QUAND est réalisé chaque livrable ?

[email protected]

16

Vue densemble dUP

[email protected]

17

Démarche de processus unifie

[email protected]

18

Démarche UP pour le PFE En fonction de temps le processus unifie est divisé en quatre phase :

Phase Lancement Phase Elaboration Phase Construction Phase Transition En fonction dactivités en cinq :

Expression des besoins Analyse

Conception Implémentation Test [email protected]

19

Phase Lancement Initialiser le projet porte essentiellement sur les besoins principaux du point de vue de l'utilisateur Identif ier les risques les délais et les coûts une identif ication des principaux cas dutilisation accompagnée dune description générale Il est possible réaliser des maquettes sur les cas dutilisation identif iés

[email protected]

20

Phase Elaboration permet de préciser la plupart des cas dutilisation de concevoir larchitecture du système Déf inition les besoins f onctionnels et non f onctionnels

(perf ormance , sécurité, etc.) raff iner le modèle initial de cas d'utilisation

[email protected]

21

Phase Construction la production dune première version du produit capturer tous les besoins restants centrée sur les activités de conception, dimplémentation implémentation de tous les cas d'utilisation identif iés

[email protected]

22

Phase Transition Traiter tout les actions liées au déploiement vérif ier si le système off re véritablement les services exigés par les utilisateurs Détecter les anomalies

livrer le produit pour une exploitation réelle

[email protected]

23

Les Diagrammes suffisants pour un PFE 1. Cas dutilisation

[email protected]

24

Les Diagrammes suffisants pour un PFE 2. Modèle de traçabilité du cas dutilisation

[email protected]

25

Les Diagrammes suffisants pour un PFE 3.

Diagramme

de classe danalyse du cas dutilisation

[email protected]

26

Les Diagrammes suffisants pour un PFE 4.

Diagramme

de collaboration

PEC = Prise en charge BT = Bouton UI = User Interf ace [email protected]

27

Les Diagrammes suffisants pour un PFE 5.

Diagramme

de classe de conception

[email protected]

28

Les Diagrammes suffisants pour un PFE 6.

Diagramme

de séquence

[email protected]

29

Les Diagrammes suffisants pour un PFE 7.

Diagramme

de classe entité

[email protected]

30

Les Diagrammes suffisants pour un PFE 8.

Diagramme

de composant

[email protected]

31

Les Diagrammes suffisants pour un PFE 9.

Diagramme

de déploiement

[email protected]

32