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 • Les vues doivent être consistantes entre elles
– Aspects de la structure et du comportement de la
solution • Elles doivent accompagner le cycle de vie du
logiciel
• Vue environnementale
– Aspects de la structure et du comportement du • La modification d’une vue implique la
domaine dans lequel est réalisée la solution 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 • Décrit la fonctionnalité que le
• Moyens pour représenter les besoins en système délivre à ses utilisateurs
(humains ou autre système) et les
UML : liens qui peuvent exister entre eux
– Diagramme de cas d’utilisation: exprime l’organisation de (include, uses ou extends)
l’utilisation du système par ses acteurs
• Acteur (Actor) : Rôle joué par un
– Diagramme de séquence: pour chaque cas d’utilisation utilisateur du système
donne une description temporelle de l’interaction d’un
acteur avec le système (scénario) • Cas d’utilisation (Use case):
– Diagramme Objets/classes: informations échangées entre séquence d’actions que le logiciel
système et acteurs garantit. Il définit les besoins du
– Diagramme de collaboration: interactions entre les objets client
métiers du système
13 14
Les Cas d’Utilisation (Use Case : Jacobson 92) Les Cas d’Utilisation (Use Case : Jacobson 92)
• Cas d’utilisation: définition Exemple
– ensemble des actions Retirer de l’argent
• Acteur: définition réalisées par le système en
réponse à une action d’un Déposer de l’argent
Client de la banque
– Entité externe (humain acteur
ou système) qui agit – Suite d’interactions entre un Effectuer des virements
selon un rôle sur le acteur et le système Entre comptes
système – Correspond à une fonction
– Identifié par un nom visible par l’utilisateur
Employé de banque Consulter le solde
correspondant à son rôle – Permet d’atteindre un
objectif aux yeux de
– Il peut être accompagné l’utilisateur Alimenter le distributeur
d’une description – Doit être utile
textuelle du rôle – 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
