Cycle de vie du logiciel

Client

Unified Modeling Language Besoins

UML
Version Déploiement Analyse
Salima Hassas
Test
Conception

Cours sur la base des transparents de : Gioavanna Di Marzo Serugendo et Frédéric Julliard
Implémentation
1 2

Développement Logiciel UML: définition

• A faire • UML permet de • Unified Modeling Language
– Comprendre et – Spécifier, visualiser et – Langage servant à décrire des modèles d’un système
conceptualiser le comprendre le problème
problème (besoins,
matériel ou logiciel basé sur des concepts orienté-objets
analyse)
– Capturer, communiquer et – Système de notations pour modéliser les systèmes en
utiliser des connaissances utilisant des concepts orienté-objets
– Résoudre le problème
pour la résolution du – Langage de modélisation visuelle (graphique) qui permet de:
(conception)
problème
• Spécifier le problème et sa solution
– Donner une solution • Visualiser le problème et la solution sous différents angles
(implémentation) – Spécifier, visualiser et
construire la solution • Construire la solution
– Documenter • documenter
– Documenter la solution
3 4
 Modèles et Vues Les vues d’UML (1/3)
• Les modèles du système sont visualisés par des vues
• Chaque vue correspond à une facette différente du système
• Vue Utilisateur
• Chaque participant au développement du système en a une vue – Buts et objectifs des clients du systèmes
différente – Besoins requis par la solution

• Vue structurelle
Structure Implémentation – Aspects statiques représentatnt la structure du problème
Utilisateur
• Vue Comportementale
Comportement Environnement – Aspects dynamiques du comportement du problème et de
sa solution
– Interactions et collaborations entre éléments de la solution
5 6

Les vues d’UML (2/3) Les vues d’UML (3/3)

• Vue implémentation
– Aspects de la structure et du comportement de la
solution
• Vue environnementale
– Aspects de la structure et du comportement du
domaine dans lequel est réalisée la solution
• Les vues doivent être consistantes entre elles
• Elles doivent accompagner le cycle de vie du
logiciel
• La modification d’une vue implique la
modification des autres vues

7 8
 Les diagrammes d’UML Les diagrammes d’UML
• Les diagrammes sont des graphes (nœud et arcs) qui • 5 diagrammes structurels (vue statique)
permettent de représenter le problème et sa solution selon – Cas d’utilisation (Use case)
différents points de vue – Classes
• Les diagrammes forment ainsi des modèles du système – Objets
(spécifier et visualiser) – Composants
– Déploiement
• La combinaison de diagrammes représentent les vues du
système • 4 diagrammes comportementaux (vue dynamique)
– Séquence
• Il existe 9 diagrammes représentants les deux aspects:
– Activités
– Statiques et structurels : relations
– États -Transitions (Stateshart)
– Dynamiques: comportement, collaborations, responsabilités
– Collaboration

9 10

Diagrammes de Cas
d’Utilisation

Use Cases

11 12
Les Cas d’Utilisation Les Cas d’Utilisation (Use Case : Jacobson 92)

• Représenter les besoins

– La phase d’analyse des besoins nécessite de comprendre
les besoins, de les exprimer et les formaliser
• Moyens pour représenter les besoins en
UML :
– Diagramme de cas d’utilisation: exprime l’organisation de
l’utilisation du système par ses acteurs
– Diagramme de séquence: pour chaque cas d’utilisation
donne une description temporelle de l’interaction d’un
acteur avec le système (scénario)
– Diagramme Objets/classes: informations échangées entre
système et acteurs
– Diagramme de collaboration: interactions entre les objets
métiers du système
• Décrit la fonctionnalité que le
système délivre à ses utilisateurs
(humains ou autre système) et les
liens qui peuvent exister entre eux
(include, uses ou extends)
• Acteur (Actor) : Rôle joué par un
utilisateur du système
• Cas d’utilisation (Use case):
séquence d’actions que le logiciel
garantit. Il définit les besoins du
client

13 14

Les Cas d’Utilisation (Use Case : Jacobson 92) Les Cas d’Utilisation (Use Case : Jacobson 92)

• Cas d’utilisation: définition Exemple

• Acteur: définition
– Entité externe (humain
ou système) qui agit
selon un rôle sur le
système
– Identifié par un nom
correspondant à son rôle
– Il peut être accompagné
d’une description
textuelle du rôle
– ensemble des actions Retirer de l’argent
réalisées par le système en
réponse à une action d’un Déposer de l’argent
Client de la banque
acteur
– Suite d’interactions entre un Effectuer des virements
acteur et le système Entre comptes
– Correspond à une fonction
visible par l’utilisateur
Employé de banque Consulter le solde
– Permet d’atteindre un
objectif aux yeux de
l’utilisateur Alimenter le distributeur
– Doit être utile
– Les cas d’utilisation ne
doivent pas se chevaucher Dépanner le distributeur
15
Agent de maintenance 16
Les Cas d’Utilisation (Use Case : Jacobson 92) Les Cas d’Utilisation (Use Case : Jacobson 92)

• Relations entre cas • Relations entre cas d’utilisations

d’utilisations
– Il n’existe pas de
communications entre
les cas d’utilisation d’un
système mais
simplement des
relations d’utilisation
(uses ou include) ou
d’extension (extends)

– Les communications
entre acteurs ne sont
pas représentées

17 18

Les Cas d’Utilisation (Use Case : Jacobson 92) Les Cas d’Utilisation (Use Case : Jacobson 92)

• Relations entre cas d’utilisations • Relations entre cas d’utilisations

19 20
Les Cas d’Utilisation (Use Case : Jacobson 92) Les Cas d’Utilisation (Use Case : Jacobson 92)

• Cas d’utilisation et scénario • Cas d’utilisation et scénario

21 22

Les Cas d’Utilisation (Use Case : Jacobson 92)

• Cas d’utilisation et scénario

Diagramme de Classes
et
diagramme d’objets

23 24
Diagramme de Classes Diagramme de Classes

25 26

Diagramme de Classes Diagramme de Classes

27 28
Diagramme de Classes Diagramme de Classes

29 30

Diagramme de Classes Diagramme de Classes

31 32
Diagramme de Classes Diagramme de Classes

33 34

Diagramme de Classes Diagramme de Classes

35 36
Diagramme de Classes Diagramme de Classes

37 38

Diagramme de Classes Diagramme de Classes

39 40
Diagramme de Classes Diagramme de Classes

41 42

Diagramme de Classes Diagramme de Classes

43 44
Diagramme de Classes Diagramme de Classes

45 46

Diagramme de Classes Diagramme de Classes

47 48
Diagramme de Classes Diagramme de Classes

49 50

Diagramme d’objets Diagramme d’objets

51 52
Diagramme d’objets Diagramme d’objets

53 54

Diagramme d’objets

Diagramme de séquence

55 56
Diagramme de séquence Diagramme de séquence

57 58

Diagramme de séquence Diagramme de séquence

59 60
Diagramme de séquence Diagramme de séquence

61 62

Diagramme de séquence Diagramme de séquence

63 64
Diagramme de séquence Diagramme de séquence

65 66

Diagramme de séquence

Diagramme de Collaboration

67 68
Diagramme de Collaboration Diagramme de Collaboration

69 70

Diagramme de Collaboration Diagramme de Collaboration

71 72
Diagramme de Collaboration Diagramme de Collaboration

73 74

Diagramme de Collaboration Diagramme de Collaboration

75 76
Diagramme de Collaboration Diagramme de Collaboration

77 78

Diagramme de Collaboration Diagramme de Collaboration

79 80
 Diagramme Etats-Transitions

Diagramme d’Etats-Transitions
Statecharts

81 82

Diagramme Etats-Transitions Diagramme Etats-Transitions

83 84
Diagramme Etats-Transitions Diagramme Etats-Transitions

85 86

Diagramme Etats-Transitions Diagramme Etats-Transitions

87 88
Diagramme Etats-Transitions Diagramme Etats-Transitions

89 90

Diagramme Etats-Transitions Diagramme Etats-Transitions

91 92
Diagramme Etats-Transitions Diagramme Etats-Transitions

93 94

Diagramme Etats-Transitions Diagramme Etats-Transitions

95 96
Diagramme Etats-Transitions

Diagramme d’activités

97 98

Diagramme d’activités Diagramme d’activités

99 100
Diagramme d’activités Diagramme d’activités

101 102

Diagramme d’activités Diagramme d’activités

103 104
Diagramme d’activités Diagramme d’activités

105 106

Autres diagrammes UML et méthodologies

107 108