17/03/2017

Université d’Alger 1-Ben Youcef Ben Khedda

Faculté des Sciences
Département de Mathématiques et Informatique
« Ensemble de moyens humains et matériels et
de méthodes permettant de réaliser les
traitements nécessaires sur les différentes
formes d’information pour la bonne conduite
de l’organisation »

nécessité d’une conception efficace

A. Benghalia
abderaoufb@yahoo.fr méthodes d’analyse et de conception

1 2

Programme Chapitre 1 : Le Génie Logiciel

1. Chapitre 1 : Le Génie Logiciel 1. Introduction : le logiciel
1.1 Introduction : le logiciel Où se trouve le logiciel ?
1.2 Génie logiciel : définition, objectif et développement de logiciel
1.3 Les cycles de développement du logiciel
1.4 Introduction à la modélisation, Modèle
Modélisation orienté objet (Historique + Concepts)

2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique
2.3 Les différents diagrammes d’UML

3. Chapitre 3 : Modélisation de S.I. avec UML

3.1 La vue fonctionnelle
3.2 La vue dynamique
3.3 La vue statique

1
 17/03/2017

Chapitre 1 : Le Génie Logiciel Chapitre 1 : Le Génie Logiciel

1. Introduction : le logiciel 1. Introduction : le logiciel
Logiciel- définition :
Traduction du terme anglais « software » en 197 par Philippe Logiciel- définition :
Renard, Commission spécialisée de terminologie et de
néologie de l'informatique et des composants, Tout simplement un logiciel est
« Ensemble de programmes, procédés et règles, et
« est un ensemble de programmes qui permet à
éventuellement de la documentation, relatifs au
fonctionnement d'un ensemble de traitement de données », l'ordinateur ou à un système informatique de
Le terme « programme » se définissant comme une suite réaliser une ou plusieurs tâches particulières »
d'instructions permettant de réaliser une ou plusieurs
tâche(s), de résoudre un problème, de manipuler des
données. Le programme est l'expression d'un algorithme
dans un langage donné pour une machine donnée

Chapitre 1 : Le Génie Logiciel Chapitre 1 : Le Génie Logiciel

1. Introduction : le logiciel 1. Introduction Fermeture de
Vraiment je suis la trappe
Ferme
fatigué la trappe C'est fermé.
Décider des actions. Système de decision Ca grince,
il faudra
graisser

Démarre
Collecter, mémoriser,
traiter et
distribuer l’information. La réparation Démarrage
Système de la facture du camion
d’information Préparez la facture
Chef
C'est
Ca ne bâché
Allez graisser
c'est
couleplein
plus
La réparation
la trappe
Assurer les fonctions : Comptabilité de la trappe
. facturer les clients, Système opérant Maintenance
. fabriquer les produits,

2
 17/03/2017

Chapitre 1 : Le Génie Logiciel Chapitre 1 : Le Génie Logiciel

1. Introduction 1. Introduction
La coordination automatique Capteur
La coordination à distance

Automate

Il faut bâcher
Capteur avant de
partir Capteur

Trappe
motorisé

Comptabilité Maintenance
Finance Gestion Tech. Maintenance Facture 10

Logiciel - caractéristiques :
Diversité Produit non palpable,
des produits Augmentation Développé par l’être humain ,
de la qualité
Augmentation Dont l’assemblage est difficile,
de la concurrence
et sa maintenance devant être assurée par ceux qui
l’ont développé,
Peut être :
Augmentation Un logiciel système : Propriétaire d’un constructeur, qui est très
Ouverture des
de la réactivité dépendant du matériel (OS, Logiciel de firewall, Drivers,…) ou
marchés
propriétaire d’un éditeur qui est une boîte noire généralement
paramétrable (SGBD)
Améliorer en permanence la qualité, le coût et la productivité :
C’est l’enjeu majeur des entreprises Un logiciel application : Propriétaire d’un éditeur et assurant une
fonction précise (ERP, Bureautique, application de loisir); ou
Quels outils donner au décideur pour comprendre, développé pour les besoins spécifiques de l’entreprise, soit par
dimensionner, piloter, et gérer ces systèmes elle-même, soit par l’intermédiaire de sociétés de services.

3
 17/03/2017

Logiciel – caractéristiques - la qualité : Chapitre 1 : L’entreprise

Qu’est ce qu’un bon logiciel ? Plusieurs 1. Notion de l’entreprise
exigences (critères existent, les plus complets Logiciel – caractéristiques – la qualité :
sont ceux de l’ISO/IEC 9126 qui distingue deux
structures de la qualité du logiciel :
La qualité interne et externe est modélisée à
travers les six dimensions : fonctionnalité,
fiabilité, utilisabilité, efficacité, maintenabilité
et portabilité;
La qualité du logiciel en usage est modélisée à
travers quatre autres dimensions : efficacité,
productivité, sécurité et satisfaction.

Chapitre 1 : L’entreprise Chapitre 1 : L’entreprise

1. Notion de l’entreprise 1. Notion de l’entreprise
Logiciel caractéristiques - la qualité : Logiciel – caractéristiques – la qualité :
Il faut ajouter à ces exigences deux critères :
Le coût,
Le délai.
Les objectifs de qualité doivent être définis
pour chaque logiciel, qu’il faut contrôler durant
son développement et après,
Ces différentes exigences de qualité ne sont
pas toujours compatibles, ni même réalisables;
Il est nécessaire de trouver des compromis;

4
 17/03/2017

Chapitre 1 : L’entreprise Chapitre 1 : L’entreprise

1. Notion de l’entreprise 1. Notion de l’entreprise
Logiciel – caractéristiques – la qualité : Logiciel – caractéristiques – la qualité :

Comme tout
projet, la
réalisation d'un
logiciel est soumise
à des exigences
contradictoires et
difficilement
conciliables
(triangle coût-
délai-qualité).

« Ensemble de moyens humains et matériels et

Introduction
de méthodes permettant de réaliser les
Génie Logiciel : Enjeux, Modèles de cycle de vie traitements nécessaires sur les différentes
formes d’information pour la bonne conduite
d’un logiciel
de l’organisation »
Modélisation, Modèle
nécessité de conception
Modélisation orienté objet (Historique + Concepts)

méthodes d’analyse et de conception

19 20

5

L’objectif est de réaliser un bon logiciel.
Qu’est ce qu’un logiciel d’abord ?
Un logiciel est un ensemble de programmes qui
permet à l'ordinateur ou à un système informatique
de réaliser une ou plusieurs tâches particulières.
21
Concepts du Génie logiciel
23
17/03/2017
Qu’est ce qu’un bon logiciel ?
- Il doit être maintenable : changement régulier,
bonne documentation.
- Le Software doit être robuste : plusieurs utilités.
- Le Software doit être efficace : bonne utilisation
des ressources (Processeur, Mémoires…)
- Le Software doit fournir une interface appropriée
à l’utilisateur : l’interaction Homme/Machine.
22
Réduire les différents coûts de développement du
logiciel en optimisant le processus de production d'un
logiciel,
Produire des logiciels de qualité selon les besoins des
client,
Satisfaire les clients en respectant le délai de livraison et
le coût de réalisation prévu.
Logiciel maintenable, robuste, fiable,
efficace et doit offrir une interface
utilisateur appropriée
24
6
 17/03/2017

Le génie logiciel (software engineering) représente Cycle de vie d’un logiciel

l'application de principes d'ingénierie au domaine de la
création de logiciels,
Analyse et spécification des besoins
Le « génie logiciel, Software Engineering » a été
introduit en 1968 lors d’une conférence internationale sur
la « crise du logiciel » pour faire face à la mauvaise
Conception du logiciel
qualité des logiciels et le non respect des besoins des
clients,
Il consiste à identifier et à utiliser des méthodes, des Implémentation du logiciel
pratiques et des outils permettant de maximiser les
chances de réussite d'un projet logiciel,
Test du logiciel
Le génie logiciel et la méthodologie s’efforcent de couvrir
tous les aspects de la vie du logiciel (Cycle de vie
standard d’un logiciel).
Maintenance du logiciel

25 26

Le cycle de vie en cascade

Etude de faisabilité

Modèles de cycles Validation

Définition des besoins

de vie d’un logiciel Validation

Conception générale

Vérification
Conception détaillée
Vérification
Codage

Tests unitaires Intégration

Tests d ’intégration Implémentation

27 28

7
 17/03/2017

Les phases traditionnelles de développement sont

effectuées les unes après les autres
autres, avec un retour sur les
Le cycle de vie en V
précédentes, voire au tout début du cycle,
Analyse des besoins Test d ’acceptation
Le processus de développement utilisant un cycle en
cascade exécute des phases qui ont pour caractéristiques :
Conception du système Test du système
◦ de se terminer à une date précise ;
◦ de ne se terminer que lorsque les livrables sont jugés Conception du
Test du composant i
composant i
satisfaisants lors d'une étape de validation-vérification.
Codage du composant i

29 30

Une activité peut commencer avant d’avoir terminé la

précédente,
Toute description d'un composant est accompagnée de Le cycle de vie en spirale
◦ fournir le plus rapidement possible un prototype pour
tests,
valider les concepts
Ce modèle est une amélioration du modèle en cascade qui ◦ se rapprocher progressivement de l’application finale

permet en cas d'anomalie, de limiter un retour aux étapes Conception du système Analyse des besoins

précédentes,
1

Les phases de la partie montante doivent renvoyer de 2

3
Développement Exploitation
l'information sur les phases en vis-à-vis lorsque des défauts
sont détectés afin d'améliorer le logiciel.
31 32

8
 17/03/2017

Système de décision

Décisions ?

Analyse des aspects Informationnels

Système d’information
On cherche à concevoir
Modélisation et Concepts Informations ?

Flux physique ? Les objets manipulés dans l’entreprise

Système opérant

Objets d’entreprise Relations entre les objets

Concevoir un logiciel

33 34

Flux physique ?
Analyse des aspects fonctionnels
Système opérant
On cherche à décrire
La modélisation est la conception d'un modèle.
Objectif principal de la modélisation = maîtriser la complexité
Ce que fait l’entreprise en termes de taches à exécuter
Modéliser = abstraire la réalité pour mieux comprendre le
système à réaliser
Le modèle doit être relié au monde réel La fonctionnalité de l’entreprise Le comportement de l’entreprise
un modèle permet de modéliser le fonctionnement d'un
ensemble de programmes informatiques.
Un modèle permet de communiquer : entre les membres de
l’équipe génie logiciel et même avec les utilisateurs pour Activité Processus
vérifier et valider la cohérence de l’architecture logiciel et leur
contexte,

35 36

9
 17/03/2017

Activité Processus
Processus
informa Entrée
tion Acitivité1

Entrée (I) Sortie (O) Matières- Activité2

Sortie
Activité … Activité n Objectif
premières
Énergie Biens matériels
Activité : Informations ou immatériels
Ressources Est une transformation qui ajoute de la valeur.
elle implique un certain nombre de ressources
( des personnes, de l’argent , des matières et Enchainement logique d’activités
du matériel ) pour transformer un objet
d’entrée en un objet de sortie.
Processus :
Est un enchainement logique d’activités dans le temps afin de réaliser un but.

37 38

Les premières méthodes d'analyse (années 70)

L'approche systémique (années 80)

◦ Modélisation des données + modélisation des
Modélisation Orienté Objet traitements (Merise).
L'émergence des méthodes objet (1990-1995)
◦ Analyse sur les données et les traitements
◦ Plus de 50 méthodes objets (dont OMT, OOSE)

39

10

1995 : Premier consensus
◦ OMT : Notation graphique riche (General Electric)
◦ OOD : concept de package ( élèment d’organisation des
modèles)
◦ OOSE : La méthodologie repose sur l'analyse des besoins
des utilisateurs (Ericsson).
Unification et la normalisation des méthodes (1995-
1997)
◦ OMG : Object Management Group. Association de
professionnels de l'informatique orientée objet.
◦ 14 novembre 1997 : UML adopté par l’OMG
Relier le modèle au monde réel par la notion d’objet
Orienté objet = abstraire et décomposer le système
informatique en objets
◦ Le monde réel est constitué d’objets physiques ou
immatériels
◦ Tracer les objets virtuels de modélisation depuis les objets
du monde réel
Relier les objets (réels) du problème et les objets
(virtuels) de la solution
43
17/03/2017
Fournir une boite à outils pour la modélisation
S'occuper de l'interface utilisateur.
Prendre le problème de maintenance en compte
Structurer la démarche projet
Favoriser le dialogue utilisateur - informaticien
Objets possédant un nom, qualifiables, classables,
polymorphes, dé-/composables, interagissants avec d’autres
objets, etc.
Meilleure capacité d’adaptation et d’évolution du modèle
lorsque des fonctionnalités sont modifiées ou ajoutées
L’approche orientée objet est une façon d’aborder un
problème et de le découper en petits sous-problèmes. On
commence par rechercher les objets du système puis leurs
interactions.
44
11
 17/03/2017

Programme
1. Chapitre 1 : Le Génie Logiciel
1.1 Introduction : le logiciel
1.2 Génie logiciel : définition, objectif et développement de logiciel
Rechercher les différents types d’objets qui font partie du 1.3 Les cycles de développement du logiciel
1.4 Introduction à la modélisation, Modèle
système à réaliser :
1.5 Modélisation orienté objet (Historique + Concepts)

la banque, les clients, les comptes bancaires, les conseillers 2. Chapitre 2 : UML
2.1 Introduction
clients, les transferts, les placements, les emprunts.
2.2 Historique
Etudier ensuite les interactions entre ces différents types 2.3 Les différents diagrammes d’UML

d’objets : par exemple, la création d’un compte bancaire 3. Chapitre 3 : Modélisation de S.I. avec UML
3.1 La vue fonctionnelle
nécessite des interactions entre le client et un conseiller client 3.2 La vue dynamique
3.3 La vue statique
45

(Rappel)
Génie logiciel
N'est pas que l'activité de programmation
Fournir une boite à outils pour la modélisation Mais l'ensemble des méthodes, des techniques et outils
concourant à la production d'un logiciel
S'occuper de l'interface utilisateur.

Prendre le problème de maintenance en compte Cycle de vie du logiciel

Structurer la démarche projet
Favoriser le dialogue utilisateur - informaticien
Toutes les phases de la création du logiciel
L'analyse des besoins, l'élaboration des spécifications,
La conceptualisation du mécanisme interne au logiciel
Le développement
La phase de test et finalement la maintenance.

47 48

12
 17/03/2017

Historique
Modéliser en orienté objet 1995 : Premier consensus
OMT : Notation graphique riche (General Electric)
Orienté objet = abstraire et décomposer le système OOD : concept de package ( élèment d’organisation
informatique en objets des modèles)
OOSE : La méthodologie repose sur l'analyse des
Le monde réel est constitué d’objets physiques ou besoins des utilisateurs (Ericsson).
immatériels Unification et la normalisation des méthodes
(1995-1997)
Relier les objets (réels) du problème et les objets OMG : Object Management Group. Association de
(virtuels) de la modélisation professionnels de l'informatique orientée objet.
14 novembre 1997 : UML adopté par l’OMG
A partir de 1998
Evolution d’UML par l’OMG (UML 2.5) : 0101//03
03//2015

49 50

UML (Unified Modeling Language, « langage de

modélisation unifié ») est un langage graphique de
modélisation objet des données et des traitements.

C'est une formalisation utilisée en génie logiciel.

UML (Unified
(Unified Modeling Language ) UML est un langage pour visualiser, spécifier, construire et
documenter les artefacts d’un système à base logicielle.

UML a unifié les modélisations objet concurrentes et s'est

imposé comme modélisation pour la conception de logiciel
orienté objet

51 52

13
 17/03/2017

langage de modélisation objet unifié

langage de modélisation objet unifié
UML est un langage pour :
UML n’est pas une méthode
Visualiser
Chaque symbole graphique possède une sémantique c'est un langage de modélisation dédié à l'objet.
Spécifier
De manière précise et complète, sans ambiguïté L'approche est faites par des diagrammes
destinés à modéliser plusieurs domaines :
Construire
Une partie du code des classes peut être généré Les diagrammes structurels (vue statique)
automatiquement Les diagrammes comportementaux (vue
Documenter fonctionnelle)
Les différents diagrammes, notes, contraintes, exigences Les diagrammes d'interaction (vue dynamique)
sont conservés dans un document

53 54

Un diagramme UML est une représentation

graphique, qui s'intéresse à un aspect précis du
modèle.
Chaque type de diagramme UML possède une
structure (les types des éléments de modélisation
qui le composent sont prédéfinis).
Les différents types de diagrammes UML offrent
une vue complète des aspects statiques et
dynamiques d'un système.
55 56

14
 17/03/2017

Programme I ) Diagramme de Cas d’utilisation

1. Chapitre 1 : Le Génie Logiciel - vue fonctionnelle -
1.1 Introduction : le logiciel
1.2 Génie logiciel : définition, objectif et développement de logiciel
1.3 Les cycles de développement du logiciel
1.4 Introduction à la modélisation, Modèle
1.5 Modélisation orienté objet (Historique + Concepts)

2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique
2.3 Les différents diagrammes d’UML

3. Chapitre 3 : Modélisation de S.I. avec UML

3.1 La vue fonctionnelle
3.2 La vue dynamique
3.3 La vue statique
58

Est une personne ou un système extérieur au système en

Un diagramme de cas d’utilisation représente
les fonctions du système du point de vue des
utilisateurs (ou acteurs). Il permet de
comprendre ce que doit faire un système plutôt
que comment faire.
cours de modélisation qui interagit avec notre système.
C'est pour des acteurs que le système est construit sans
acteurs le système n'a pas de raison d'être
Une personne peut être plusieurs acteurs pour le système
(un thésard vacataire est à la fois un étudiant et un
professeur).

Il est composé de deux volets: d’une part le
renseignement des acteurs qui bénéficient de
l’utilisation du système, d’autre part, les
fonctionnalités attendues par le futur système.
59
On utilise aussi les acteurs pour modéliser des systèmes
externes comme une imprimante, un autre logiciel, etc.
Il faut décrire les acteurs en fonctions des fonctionnalités
qu'ils demandent au système et/ou des fonctionnalités
que le système leur demandent.
60

15
 17/03/2017

est un classificateur qui modélise une fonctionnalité d'un

système ou d'une classe. L'instanciation d'un cas
Ils peuvent être : d'utilisation se traduit par l'échange de messages entre le
soit des humains ; système et ses acteurs.
soit des logiciels ;
Les cas d'utilisation sont représentés par des ellipses à
soit des automates.
l'intérieur desquelles il y a le nom du cas d'utilisation.

On distingue :
Ils peuvent être contenus dans un rectangle qui représente
• les acteurs primaires : ceux sont les utilisateurs du
les limites du système.
système ;
• les acteurs secondaires : ceux qui administrent le
Les acteurs sont alors forcément en dehors du rectangle
système.
puisqu'ils ne font pas partie du système. La relation entre
un acteur et un cas d'utilisation est une association
représentée par une ligne.
61 62

Cas d’utilisation Programme

•structurer les besoins des utilisateurs et les objectifs correspondants du
1. Chapitre 1 : Le Génie Logiciel
système.
1.1 Introduction : le logiciel
•Préoccuper des cas "réels" des utilisateurs ; ils ne présentent pas de 1.2 Génie logiciel : définition, objectif et développement de logiciel
solutions d'implémentation et ne forment pas un inventaire fonctionnel du
système. 1.3 Les cycles de développement du logiciel
1.4 Introduction à la modélisation, Modèle
Notation
1.5 Modélisation orienté objet (Historique + Concepts)
Objectif du système, motivé par un besoin
d'un (ou plusieurs) acteur(s) 2. Chapitre 2 : UML
Cas d’utilisation
2.1 Introduction
2.2 Historique
Personne ou composant d’origine d’une
interaction avec le système 2.3 Les différents diagrammes d’UML
Acteur
3. Chapitre 3 : Modélisation de S.I. avec UML
Documente un élément du modèle
3.1 La vue fonctionnelle
Note 3.2 La vue dynamique
Relation d’utilisation
3.3 La vue statique

16

Avant de développer un système :
Il faut savoir précisément à QUOI il devra servir,
c.-à-d. à quels besoins il devra répondre.
Modéliser les besoins permet de faire l'inventaire
des fonctionnalités attendues et d'organiser les
besoins entre eux de manière à faire apparaître
des relations.
Diagramme des cas d’utilisation
Il est composé de deux volets, d’une part le
renseignement des acteurs qui bénéficient de
l’utilisation du système ; d’autre part les
fonctionnalités attendues par le système.
Description de l’interaction entre l’utilisateur
et le système
Recensement des besoins des utilisateurs
Descriptions textuelles + diagrammes de tous
les cas d’utilisation
67
17/03/2017
Avec UML, nous modélisons les besoins au moyen
de diagrammes de cas d'utilisation.
Un cas d'utilisation est un service rendu à
l'utilisateur, il implique des séries d'actions plus
élémentaires.
Un acteur est une entité extérieure au système
modélisé, et qui interagit directement avec lui.
Un cas d'utilisation est l'expression d'un service
réalisé de bout en bout, avec un déclenchement, un
déroulement et une fin, pour l'acteur qui l'initie.
Par ailleurs, il faut savoir qu'un acteur correspond
à un rôle et non pas à une personne physique.
◦ Réutilisation de cas en utilisant les relations
d’inclusion include…
Inclusion
◦ Une instance contient le comportement d’une autre
instance
« include »
payer
S’inscrire
« include » accepter
68
17
 17/03/2017

La relation extend est une relation entre 2 instances de cas

La relation extend est une relation entre 2 instances de cas
d'utilisation
On dit qu'un cas d'utilisation A extend un cas d'utilisation B
lorsque le cas d'utilisation A peut être appelé au cours de
l'exécution du cas d'utilisation B. Exécuter B peut
éventuellement entraîner l'exécution de A : contrairement à
l'inclusion, l'extension est optionnelle. Cette dépendance est
symbolisée par le stéréotype << extend >>
d'utilisation
On dit qu'un cas d'utilisation A extend un cas d'utilisation B
lorsque le cas d'utilisation A peut être appelé au cours de
l'exécution du cas d'utilisation B. Exécuter B peut
éventuellement entraîner l'exécution de A : contrairement à
l'inclusion, l'extension est optionnelle. Cette dépendance est
symbolisée par le stéréotype << extend >>

Un cas A est une généralisation d'un cas B si B est un cas

particulier de A. Cette relation de généralisation est présente
dans la plupart des diagrammes UML et se traduit par le
« extend » concept d'héritage dans les langages orientés objet.
69 70

la vérification du solde
du compte n'intervient
que si la demande de
retrait dépasse 20 euros

la consultation d'un
compte via Internet
est un cas particulier
de la consultation.
71
l'accès aux informations d'un
compte inclut nécessairement
une phase d'authentification
72

18
 17/03/2017

Description textuelle
– Transcription textuelle de la description des cas d’utilisation
– Compléments aux diagrammes
– Avantages:
• La rédaction permet de corriger le diagramme
• Le diagramme oblige à rédiger chaque cas

cas Inscription d’un élève

Procédure d’inscription d’un élève jusqu’à la
résumé délivrance de sa carte
acteur primaire L’élève EXERCICES
acteur secondaire La scolarité, l’administration
pré-conditions Vérification préalable des conditions d’inscription

résultats Dossier d’inscription, paiement, délivrance carte élève

1. l’élève présente sa demande
2. Saisie des infos
Scénario nominal 3. Calcul du coût
4. ……

Alternatif Pas de délivrance de carte si …

73 74

Système de réservation Agence de Voyages

Une agence de voyages organise des voyages Réserver un taxi

où l’hébergement se fait en hôtel. Le client

doit disposer d’un taxi quand il arrive à la Réserver une Réserver un billet
gare pour se rendre à l’hôtel. chambre de train

Organiser un
voyage

Client

75 76

19
 17/03/2017

Certains clients demandent à l’agent de

voyages d’établir une facture détaillée. Cela
donne donc naissance à un cas ?
« Établir une facture détaillée ». Comment
mettre cela en relation avec les cas existants ?

77 78

Programme
1. Chapitre 1 : Le Génie Logiciel Résumé
1.1 Introduction : le logiciel UML est une notation, pas une méthode
1.2 Génie logiciel : définition, objectif et développement de logiciel UML est un langage de modélisation objet
UML est un standard
1.3 Les cycles de développement du logiciel
1.4 Introduction à la modélisation, Modèle
Programmation Orientée Objet
1.5 Modélisation orienté objet (Historique + Concepts)
modéliser informatiquement des éléments d'une partie du monde réel
en un ensemble d'entités informatiques (objets)
2. Chapitre 2 : UML
2.1 Introduction
Intérêt d'une méthode objet
2.2 Historique
définir le problème à haut niveau sans rentrer dans les spécificités du
2.3 Les différents diagrammes d’UML langage
définir un problème de façon graphique
3. Chapitre 3 : Modélisation de S.I. avec UML
utiliser les services offertes par l’objet sans rentrer dans le détail de
3.1 La vue fonctionnelle programmation
3.2 La vue dynamique Réutilisation du code

3.3 La vue statique

80

20
 17/03/2017

Un diagramme de cas d’utilisation représente les

fonctions du système du point de vue des utilisateurs (ou
acteurs).
Il permet de comprendre ce que doit faire un système
plutôt que comment faire.
Il est composé de deux volets:
◦ d’une part le renseignement des acteurs qui bénéficient
de l’utilisation du système,
◦ d’autre part, les fonctionnalités attendues par le futur
système.

81 82

2 ) Diagramme d’activité
- vue Dynamique -

83 84

21

UML permet de représenter graphiquement le
comportement d'une méthode ou le déroulement
d'un cas d'utilisation, à l'aide de diagrammes
d'activités.
Une activité représente une exécution d'un
mécanisme, un déroulement d'étapes séquentielles.
Le passage d'une activité vers une autre est
matérialisé par une transition.
85
Le diagramme d'activité est une représentation proche
de l'organigramme ; la description d'un cas d'utilisation
par un diagramme d'activité correspond à sa traduction
algorithmique. Une activité est l'exécution d'une partie
du cas d'utilisation, elle est représentée par un
rectangle aux bords arrondis.
Diagramme d’activité = ensemble d’activités liés
par:
◦ Transition (sequentielle)
◦ Transitions alternatives (conditionnelle)
◦ Synchronisation (disjonction et conjonctions d’activités)
◦ Itération
+ 2 états: état initial et état final
87
17/03/2017
La fiche descriptive d’un cas d’utilisation peut
contenir plusieurs scénarios alternatifs et/ou
d’exception.
Il est alors difficile d’avoir une vision de
l’ensemble des actions.
Le diagramme d’activité est un moyen graphique
pour donner cette vision d’ensemble
86
Etat de départ / état initial
l'état initial du système au début du processus.
Etat de fin / final, ou point de sortie
Un processus peut avoir plusieurs points de
sortie, chacun relié à une post-condition
spécifique (c.a.d. une condition vérifiée quand le
processus se termine)
Swim lanes (Couloirs)
optionnels. Ils montrent comment différents
objets prennent la responsabilité d'effectuer
certaines actions…
88
22
 17/03/2017

•Etat de départ
•Etat de final
•Transition •Transition alternative
(conditionnelle)
•Elle permet d’indiquer les
différents scénarios du
cas d’utilisation dans un
même diagramme.

89 90

La synchronisation
indique qu’il faut
avoir réalisé deux
actions pour
pouvoir réaliser la Synchronisation
troisième en-
dessous. disjonctive et
conjonctive

91 92

23
 17/03/2017

1. Identifiez la portée du diagramme d'activité

Commencez en identifiant ce que vous allez
modéliser. Un seul use case? Une partie d'un use
case ? Un « workflow » qui inclut plusieurs use
cases ?
2. Ajouter l’état de départ et de terminaison
Swimlanes
(Couloirs) 3. Ajouter les activités
Ils permettent
4. Ajouter des transitions (séquentielles), des
d’indiquer qui réalise transitions alternatives (conditionelles), des
les actions synchronisations entre des activités, des
itérations.

5. Identifier des swimlanes (Couloirs) et répartir

des activités identifiées dans ces swimlanes.

93 94

95 96

24
 17/03/2017

Décrire le fonctionnement d'un distributeur de billets. Le

client introduit sa carte dont la validité est immédiatement
vérifiée. Il est ensuite invité à saisir le code de la carte.
Après trois tentatives infructueuses, la carte est avalée.
EXERCICES Sinon le client peut indiquer le montant qu'il désire retirer,
le solde de son compte bancaire est alors consulté pour
s'assurer que le retrait est possible. En cas de solde
insuffisant, le client en est informé et peut alors saisir un
montant inférieur. Si le solde du compte est suffisant, le
distributeur restitue la carte et délivre alors les billets
accompagnés d'un reçu.

97 98

25
 14/04/2017

Université d’Alger 1-Ben Youcef Ben Khedda

Faculté des Sciences
Département de Mathématiques et Informatique
« Ensemble de moyens humains et matériels et
de méthodes permettant de réaliser les
traitements nécessaires sur les différentes
formes d’information pour la bonne conduite
de l’organisation »

nécessité d’une conception efficace

A. Benghalia
abderaoufb@yahoo.fr méthodes d’analyse et de conception

1 2

Cycle de vie d’un logiciel (Rappel)

Analyse et spécification des besoins Génie logiciel
N'est pas que l'activité de programmation
Mais l'ensemble des méthodes, des techniques et outils
Conception du logiciel concourant à la production d'un logiciel

Cycle de vie du logiciel

Implémentation du logiciel Toutes les phases de la création du logiciel
L'analyse des besoins, l'élaboration des spécifications,
La conceptualisation du mécanisme interne au logiciel
Test du logiciel Le développement
La phase de test et finalement la maintenance.

Maintenance du logiciel

3 4

1
 14/04/2017

Modéliser en orienté objet

Orienté objet = abstraire et décomposer le système

informatique en objets

Le monde réel est constitué d’objets physiques ou

immatériels
EXERCICES
Relier les objets (réels) du problème et les objets
(virtuels) de la modélisation

5 6

Décrire le fonctionnement d'un distributeur de billets. Le

client introduit sa carte dont la validité est immédiatement
vérifiée. Il est ensuite invité à saisir le code de la carte.
Après trois tentatives infructueuses, la carte est avalée.
Sinon le client peut indiquer le montant qu'il désire retirer,
le solde de son compte bancaire est alors consulté pour
s'assurer que le retrait est possible. En cas de solde
insuffisant, le client en est informé et peut alors saisir un
montant inférieur. Si le solde du compte est suffisant, le
distributeur restitue la carte et délivre alors les billets
accompagnés d'un reçu.

7 8

2
 14/04/2017

Programme 3 ) Diagramme de séquence

1. Chapitre 1 : Le Génie Logiciel - vue Dynamique -
1.1 Introduction : le logiciel
1.2 Génie logiciel : définition, objectif et développement de logiciel
1.3 Les cycles de développement du logiciel
1.4 Introduction à la modélisation, Modèle
1.5 Modélisation orienté objet (Historique + Concepts)

2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique
2.3 Les différents diagrammes d’UML

3. Chapitre 3 : Modélisation de S.I. avec UML

3.1 La vue fonctionnelle
3.2 La vue dynamique
3.3 La vue statique
10

Diagramme de séquence Diagramme de séquence

Introduction Introduction
Les diagrammes d’interaction sont utilisés pour modéliser ◦ L’ensemble des différentes étapes à accomplir s’appelle
les aspects dynamiques d’un système une interaction.
◦ Ils aident à visualiser comment le système exécute ses ◦ Un diagramme d’interaction montre différents types de
tâches. communication entre objets, acteurs et sous-systèmes:
L’objectif est de montrer comment un ensemble E.g. appel à des méthodes, information envoyés sur un
d’objets peut réaliser une tâche demandée par un acteur réseau
◦ Un diagramme d’interaction montre comment un Ceux-ci sont appelés messages.
ensemble d’objets et d’acteurs communiquent ensemble
afin: ◦ Il existe deux sortes de diagramme d’interaction
de réaliser un cas-type Diagramme de séquence
de réaliser une certaine fonctionnalité Diagramme de collaboration
11 12

3
 14/04/2017

Diagramme de séquence Diagramme de séquence

◦ Les diagrammes de cas d'utilisation modélisent à QUOI sert le
système, en définissant les interactions possibles avec les acteurs.
◦ Les diagrammes de séquences permettent de décrire
COMMENT les éléments du système interagissent entre eux et
avec les acteurs.
◦ Chaque cas d’utilisation se traduit par un certain nombre de
scénarios. Chaque scénario peut être spécifié par un diagramme
de séquence.
◦ IL faut savoir qu’un scénario décrit une extension particulière
d’un cas d’utilisation du début à la fin. Il correspond à un
enchaînement du cas d’utilisation se terminant par une fin
normale ou erreur.
◦ En générale, il n’est pas possible de décrire tous les scénarios
d’un cas d’utilisation, il faudra choisir les principaux scénarios
nominaux (ceux qui sont fréquent) et quelques uns d’exception
◦ Un diagramme de séquence montre la séquence temporelle
d’échange de message entre l’acteur et les objets réalisant une
certaines tâche
◦ Les objets sont disposés horizontalement
◦ L’acteur qui initie l’interaction se trouve généralement à
l’extrême gauche
◦ La dimension verticale représente le temps

13 14

Diagramme de séquence utilis ateur

«dialogu e »
form ulaire
d'inscription
«contôle»
c trlC réerC om pte
«en titté»
utilisateur

◦ Une ligne verticale, appelée ligne de vie, est accrochée à chaque rem plirForm ulaire()
objet ou acteur
vérifieratric ule()
◦ La ligne de vie s’épaissie pour devenir une boite d’activation
recherc her()
lorsque l’objet est actif, i.e., durant la période d’activation.
◦ Un message est représenté par une flèche joignant une boite
Alt
d’activation. iden tifié
[m atricu le
identifié]
◦ Un message a un nom et peut aussi avoir une liste d’arguments create() «entité»
utilisateur
et une valeur de retour.
[m atriculer
◦ Les diagrammes de séquences et les diagrammes d'état- non identifié]
non identifié

m essage d'erreur
transitions sont les vues dynamiques les plus importantes
d'UML

15 16

4
 14/04/2017

Ligne de vie Ligne de vie

• Les diagrammes de séquence permettent de représenter les

périodes d’activité des objets.
• Une période d’activité correspond au temps pendant lequel
un objet effectue une action, soit directement, soit par
l’intermédiaire d’un autre objet qui lui sert de sous-traitant.
• Les périodes d’activité se représentent par des bandes
rectangulaires placées sur les lignes de vie.
• Le début et la fin d’une bande correspondent respectivement
au début et à la fin d’une période d’activité.

17 18

Ligne de vie Messages synchrones et Messages

asynchrones

Les diagrammes de séquence distinguent deux grandes

catégories d’envoi de message:
Les envois synchrones pour lesquels l’émetteur est bloqué et attend que
l’appelé ait fini de traiter le message.
Les envois asynchrones pour lesquels l’émetteur n’est pas bloqué et peut
continuer son exécution.

19 20

5

Message asynchrones
Une interruption ou un événement sont de bons exemples de
signaux. Ils n'attendent pas de réponse et ne bloquent pas
l'émetteur qui ne sait pas si le message arrivera à destination,
le cas échéant quand il arrivera et s'il sera traité par le
destinataire. Un signal est, par définition, un message
asynchrone.
Graphiquement, un message asynchrone se représente par une
flèche en traits pleins et à l'extrémité ouverte partant de la
ligne de vie d'un objet expéditeur et allant vers celle de l'objet
cible
21
23
14/04/2017
Messages synchrones
Dans la pratique, la plupart des invocations sont synchrones,
l'émetteur reste alors bloqué le temps que dure l'invocation de
l'opération.
Graphiquement, un message synchrone se représente par une
flèche en traits pleins et à l'extrémité pleine partant de la ligne
de vie d'un objet expéditeur et allant vers celle de l'objet cible.
Ce message peut être suivi d'une réponse qui se représente par
une flèche en pointillé
22
Messages de création et destruction
d'instance
• La création d'un objet est matérialisée par une flèche qui
pointe sur le sommet d'une ligne de vie.
• La destruction d'un objet est matérialisée par une croix qui
marque la fin de la ligne de vie de l'objet.
• La destruction d'un objet n'est pas nécessairement
consécutive à la réception d'un message.
24
6
 14/04/2017

«dialogu e » «contôle» «en titté»

form ulaire c trlC réerC om pte utilisateur
d'inscription
utilis ateur

rem plirForm ulaire()

vérifieratric ule()
Période
d’activité recherc her()
de l’objet :
ligne de vie

Alt
iden tifié
[m atricu le
identifié] create() «entité»
utilisateur

[m atriculer
non identifié
non identifié]
m essage d'erreur

25 26

Fragments d'interaction combinés

Un fragment combiné se représente de la même façon qu'une
interaction. Il est représenté dans un rectangle dont le coin
supérieur gauche contient un pentagone.
Les opérandes d'un opérateur d'interaction sont séparés par
une ligne pointillée.
Les conditions de choix des opérandes sont données par des
expressions booléennes entre crochets
Par le biais de cadres d'interaction, on peut préciser les
spécificités d'un ensemble de messages :
alt : fragments multiple alternatifs (si alors sinon)
opt : fragment optionnel
loop : le fragment s'exécute plusieurs fois
ref : référence à une interaction dans un autre diagramme

27 28

7
 14/04/2017

Opérateur alt « d ia lo g u e »
form ulaire
«contôle»
ctrlS 'authentifier
«entitté»
utilisateur

L'une ou l'autre des alternatives sera réalisée. Le choix se utilis ateur

d'authentification

fera grâce à la condition de garde (condition entre crochets).

rem plirForm ulaire()
L'opérateur alternative, ou alt, est un opérateur conditionnel
vérifierA utehtific ation()
possédant plusieurs opérandes. C'est un peu l'équivalent
d'une exécution à choix multiple (condition switch ). rec herc her()

Chaque opérande détient une condition de garde. L'absence

de condition de garde implique une condition vraie (true). La A lt
identifié
condition else est vraie si aucune autre condition n'est vraie. [utilis ateur
identifié] «dialogue» create()
session
Exactement un opérande dont la condition est vraie est
exécuté. [utilis ateur
non identifié
non identifié]
m es s age d'erreur
Si plusieurs opérandes prennent la valeur vraie, le choix est
non déterministe.

29 30

Opérateur Loop
L'opérateur "Loop" (boucle) est noté "loop". Cet opérateur
est utilisé pour décrire un ensemble d'interaction qui
s'exécutent en boucle. En général, une contrainte
appelée garde indique le nombre de répétitions (minimum et
maximum) ou bien une condition booléenne à respecter.

31 32

8
 14/04/2017

Opérateur Ref

Il fait Référence à un autre diagramme de séquence pour

alléger le diagramme en cours.

33 A.BENGHALIA Université du Havre 16/10/2015

Opérateur Opt
L'opérateur "opt" désigne un fragment combiné optionnel
comme son nom l'indique : c'est à dire qu'il représente un
comportement qui peut se produire... ou pas. Un fragment
optionnel est équivalent à un fragment "alt" qui ne
posséderait pas d'opérande else (qui n'aurait qu'une seule
branche). Un fragment optionnel est donc une sorte
de SI...ALORS.
Les interactions contenues dans le fragment ne seront
réalisées que si la condition est vérifiée.
Équivalent à un opérateur alternative avec une seule
condition

35 36

9
 14/04/2017

37

10
 22/04/2017

Université d’Alger 1-Ben Youcef Ben Khedda

Faculté des Sciences
Département de Mathématiques et Informatique

UML (Unified
(Unified Modeling Language )

A. Benghalia
abderaoufb@yahoo.fr

1 2

Programme 4) Diagramme de classes - vue

1. Chapitre 1 : Le Génie Logiciel statique-
statique -
1.1 Introduction : le logiciel
1.2 Génie logiciel : définition, objectif et développement de logiciel
1.3 Les cycles de développement du logiciel
1.4 Introduction à la modélisation, Modèle
1.5 Modélisation orienté objet (Historique + Concepts)

2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique
2.3 Les différents diagrammes d’UML

3. Chapitre 3 : Modélisation de S.I. avec UML

3.1 La vue fonctionnelle
3.2 La vue dynamique
3.3 La vue statique
4

1

En UML, le modèle structurel ou statique d’un système est
décrit à l'aide de deux sortes de diagrammes :
− Diagrammes de classes (description de tout ou d'une partie
du système d'une manière abstraite en termes de classes et de
relations).
− Diagrammes d'objets (description d'exemples de
configuration de tout ou partie du système, en termes
d'objets, de valeurs et de liens).
5 6
Une classe est la description d'un ensemble d'objets ayant
une sémantique, des attributs, des méthodes et des relations
en commun.
Elle spécifie l'ensemble des caractéristiques qui composent
des objets de même type.
Une classe est composée d'un nom, d'attributs et
d'opérations.
Selon l'avancement de la modélisation ces informations ne
sont pas forcément toutes connues.
7 8
22/04/2017
Les diagrammes de cas d'utilisation modélisent à QUOI sert
le système.
Le système est composé d'objets qui interagissent entre eux
et avec les acteurs pour réaliser ces cas d'utilisation.
Les diagrammes de classe permettent de spécifier la structure
et les liens entre les objets dont le système est composé.
Intérêt
Le diagramme de classes est considéré comme le plus important de
la modélisation orientée objet. Il est le seul obligatoire lors d’une
telle modélisation. Il permet de:
Définir les futures composantes du système final.
Structurer le travail de développement de manière très efficace.
Séparer les composantes de manière à pouvoir répartir le travail
de développement entre les membres (développeurs), dans le cas
de travaux réalisés en groupe (surtout dans les milieux
industriels).
· Construire le système de manière correcte.
2
 22/04/2017

Décrit la structure interne du système, sous forme de La notion de classe est essentielle en programmation
classes (attributs + opérations) et de relations entre orientée objet : elle définit une abstraction, un type abstrait
classes. Ne montre pas comment utiliser les
opérations = description statique. qui permettra plus tard d’instancier des objets.
On distingue généralement des classes abstraites (qui ne
DEFINITION : peuvent pas être instanciées) et des classes "normales", qui
• Classe : servent à définir des objets.
modélisation de l’ensemble des objets ayant : La classe intègre les concepts de type (en tant que «moule
• attributs similaires à instances »)
• comportement en commun
• relations communes avec d’autres objets

9 10

Le premier indique une chaîne de caractères correspondant au

nom de la classe qui doit commencer par un caractère
alphabétique.
NOTATION : Le deuxième compartiment indique les attributs de la classe et le
troisième ses opérations.
• Tout nom de classe commence par une majuscule Ne pas représenter les attributs ou les méthodes d'une classe,
•Une classe est un classeur représenté par un rectangle divisé en trois
compartiments.
n'indique pas que cette classe n'en contient pas. Il s'agit juste d'un
filtre visuel, destiné à donner un certain niveau d'abstraction.

NomAttribut : type = ValeurInitiale

NomOpération(ListeArguments) : typeRetour

attributs NomClasse

opérations

11 12

3
 22/04/2017

La visibilité déclare la possibilité pour un élément de

modélisation de référencer un élément
Dans une classe, le marqueur de visibilité se situe au niveau de
chacune de ses caractéristiques (attributs et opération). Il attributs NomClasse
permet d’indiquer si une autre classe peut y accéder.

+ public (visible par tous) : l’élément est visible pour tous les
opérations
clients de la classe
- privé (visible dans la classe uniquement) : l’élément n’est
visible que par les objets de la classe dans laquelle il est déclaré
# protégé (visible dans la classe et ses sous classes)

13 14

Les attributs définissent les propriétés des objets de la classe.
Un attribut est défini par un nom, un type de données, une
visibilité et peut être initialisé. Le nom de l’attribut doit être
unique dans la classe.
Les attributs représentent les données encapsulées dans les
objets de cette classe.
La syntaxe d'un attribut est la suivante :
Visibilité nomAttribut [multiplicité] : typeAttribut = Initialisa
tion ;
Nom de l'attribut
Il ne doit pas comporter d'espaces, de signes de ponctuation ou
d'accents. Pour remplacer les espaces, plusieurs conventions
existent : on peut utiliser le symbole _ ou changer la première
lettre du mot en majuscule
Exemple :
nom de l'objet peut s’écrire nomObjet ou nom_objet).
Multiplicité
La multiplicité représente le nombre de fois que la variable peut
exister. Elle est représentée entre crochets.
Par exemple : si une personne possède 2 numéros de téléphone,
on préfèrera noTelephones[2] à noTelephone1 et noTelephone2.

15 16

4
 22/04/2017

Un attribut peut être un attribut de classe, il est alors souligné. Il garde

une valeur unique et partagée par toutes les instances de la classe. Les
instances ont accès à cet attribut mais n’en possèdent pas une copie.

17 18

Une méthode ou opération est un service qu’une instance d’une classe

peut exécuter. Elle doit être unique. La notion de visibilité est la même
que celle des attributs.
Opération : effectuée par l’objet
attributs NomClasse
Méthode : effectuée par la classe

opérations
Sa syntaxe est la suivante :
Visibilité nomFonction(directionParamètreN nomParamètreN : type
ParamètreN) : typeRetour

19 20

5
 22/04/2017

Direction du paramètre Comme pour les attributs de classe, il est possible de déclarer des
Indique si le paramètre est rentrant (in), s'il est sortant (out) ou s'il est méthodes de classe.
rentrant et sortant (inout). Une méthode de classe ne peut manipuler que des attributs de classe et
Exemple ses propres paramètres.
+ getAge() : int ->méthode publique qui retourne un entier Cette méthode n’a pas accès aux attributs des instances de la classe.
# calculerAge(in dateNaissance : Date) : void -> L’accès à une méthode de classe ne nécessite pas l’existence d’une
instance de cette classe. Graphiquement, une méthode de classe est
méthode protégée prenant comme paramètre dateNaissance de type Date
soulignée.
et ne retournant rien (void)

21 22

une classe abstraite est une classe dont l'implémentation n'est pas
complète et qui n'est pas instanciable. Elle sert de base à d'autres
classes dérivées (héritées). Pour indiquer qu’une classe est abstraite,
on ajoute le mot-clé abstract derrière son nom.
Le mécanisme des classes abstraites permet de définir des
comportements (méthodes) dont l'implémentation (le code dans la
méthode) se fait dans les classes héritées. Relation entre les classes
Prenons l'exemple suivant : vous avez une classe Humain, à partir
de laquelle dérivent la classe Homme et la classe Femme. En toute
logique, Homme et Femme sont instanciables (les objets créés ont
une existence en soi), mais la classe Humain sera déclarée abstraite
car un objet Humain n'existe pas en tant que tel, puisqu'il manque
l'information sur le sexe.
Ici, la classe Humain servira à implémenter des méthodes qui
seront utilisées à la fois pour Homme et pour Femme.
23 24

6
 22/04/2017

La généralisation est une relation d’héritage entre une classe générale
(super classe ou classe parent) et une classe spécialisée (sous-classe ou
classe enfant).
La classe spécialisée est intégralement cohérente avec la classe de
base, mais comporte des informations supplémentaires (attributs,
opérations, associations).
Les propriétés principales de l’héritage sont :
Tous les attributs qui se trouvent dans la Super-Classe sont vrais
dans toutes les sous-classes.
La classe enfant possède toutes les propriétés de ses classes parents,
mais elle ne peut accéder aux propriétés privées de celle-ci.
Toutes les associations de la classe parent s’appliquent aux classes
dérivées.

Le symbole utilisé pour la relation d’héritage ou de généralisation est

une flèche avec un trait plein dont la pointe est un triangle fermé
désignant le cas le plus général.

25 26

Classe plus
spécialisation
généralisation

SUPER CLASSE
générale
Une association est une relation entre deux classes (association
binaire) ou plus (association n-aire), qui décrit les connexions
SOUS Classe plus structurelle entre leurs instances ("est produit par", "est affilié
CLASSE détaillée à","se trouve à", "est conduit par"…).
TYPES ASSOCIATIONS
Association binaire : Association n-aire :
associe 2 classes associe plus de 2 classes

OEUVRE AUTEUR PERSONNE PROJET

créer

affecter
FONCTION

27 28

7

Une classe-association possède à la fois les propriétés des
associations et des classes : elle se connecte à deux ou plusieurs
classes et possède également des attributs et des opérations.
Une classe-association est reliée par un trait discontinu à
l’association qu’elle représente.
29
Une agrégation est une forme spéciale d’association exprimant une
relation d’inclusion structurelle ou comportementale d’éléments
(agrégés) dans un ensemble (agrégat).
Graphiquement, on ajoute un losange vide du côté de l’agrégat.
La composition, également appelée agrégation composite, décrit
une contenance structurelle (contenance physique) entre instances.
Ainsi, la destruction de l’objet composite implique ladestruction
de ses composants.
Graphiquement, on ajoute un losange plein du côté de l’agrégat.
31
22/04/2017
Une agrégation est une forme spéciale d’association exprimant une
relation d’inclusion structurelle ou comportementale d’éléments
(agrégés) dans un ensemble (agrégat).
Graphiquement, on ajoute un losange vide du côté de l’agrégat.
La composition, également appelée agrégation composite, décrit
une contenance structurelle (contenance physique) entre instances.
Ainsi, la destruction de l’objet composite implique ladestruction
de ses composants.
Graphiquement, on ajoute un losange plein du côté de
l’agrégat.
30
32
8
 22/04/2017

Multiplicités :
1 un et un seul M..N de M à N (entiers naturels)
* plusieurs 1..* de 1 à plusieurs
Chaque extrémité d’une association permet
de préciser le Rôle joué par chaque 0..1 zéro ou un 0..* de zéro à plusieurs
Classe dans l’Association. Pour un rôle, il
est possible de préciser
Emploie >
Nom du rôle Personne
Multiplicité
Université 0..1 *
Employeur Employé
Exactement 1
1

0..* Zero ou plus Contrairement aux cardinalités de Merise, les

multiplicités UML sont placées du côté de la destination.
1..* Au minimum 1
Une Université emploie plusieurs Personnes : le symbole
0..1 Zero ou 1 * est placé du côté Personne. à une Personne est
associée zéro ou une Université (avec le rôle
2..7 Plage de valeurs Employeur) : le symbole 0..1 est placé du côté Université.

33 34

UML : DIAGRAMME DE CLASSES

MULTIPLICITES (cardinalités):

SERVICE 1 Un et un seul
0.. Zéro ou Un Encapsulation, Héritage et Polymorphisme
1
0 .. 1 0 .. 1 0 .. 1
M.. De M à N (entiers
rattacher à

N naturels)
diriger

prêter

0..* De Zéro à plusieurs

1 *
1 .. *
*
PERSONNE
1..* De Un à plusieurs
N Exactement N (entier
naturel)
35 36

9

L’encapsulation est le fait qu’un objet renferme ses propres attributs et
ses méthodes.
Une classe encapsule les propriétés (attributs et méthodes) des objets
qu‘elle regroupe.
L'encapsulation est un mécanisme consistant à rassembler les
données et les méthodes au sein d'une structure. L'encapsulation permet
donc de garantir l'intégrité des données contenues dans l'objet.
37
C’est un mécanisme qui permet à une sous classe de redéfinir une
méthode dont elle a hérité tout en gardant la même signature de la méthode
héritée.
Ainsi on peut avoir une méthode avec la même tête (même signature) et
des corps différents (codes différents) : polymorphisme.
Un même message peut ainsi déclencher des traitements différents selon
l’objet auquel il fait appel.
Un message polymorphe poserait un problème à la compilation car on ne
saurait identifier précisément la méthode qu’il vise.
39
22/04/2017
Chaque sous classe peut avoir une ou plusieurs sous classes formant
ainsi une hiérarchie d’objet. On parle de classe ancêtre (ou mère) et de
classes descendant (ou fille).
L’héritage est un mécanisme qui permet d’assurer une grande variabilité
dans la réutilisation des objets.
38
Une démarche couramment utilisée pour élaborer un
diagramme de classes consiste à :
Trouver les classes du domaine étudié. Cette étape empirique
se fait généralement en collaboration avec un Expert du
domaine. Les classes correspondent généralement à des
concepts ou des substantifs du domaine.
Trouver les associations entre classes. Les associations
correspondent souvent à des verbes, ou des constructions
verbales, mettant en relation plusieurs classes, comme « est
composé de », « pilote », « travaille pour ».
Il faut se méfier de certains attributs qui sont en réalité des
relations entre classes.
40
10
 22/04/2017

Trouver les attributs des classes. Les attributs correspondent

souvent à des groupes nominaux, tels que « la masse d’une Heuristiques d’élaboration du modèle structurel
voiture » ou « le montant d’une transaction ». Les adjectifs et Bien comprendre le problème
les valeurs correspondent souvent à des valeurs d’attributs.
Faire simple
Organiser et simplifier le modèle en éliminant les classes
Bien choisir les noms
redondantes et en utilisant l’héritage.
Bien Expliciter les associations
Vérifier les chemins d’accès aux classes.
Ne pas trop “généraliser”
Itérer et raffiner le modèle (tout en complétant les classes
Relire
avec les opérations nécessaires). Un modèle est rarement
correct dès sa première construction. La modélisation objet Documenter
est un processus non pas linéaire mais itératif. De nombreuses révisions sont nécessaires !

41 42

Exercice

Concevoir le diagramme de classe d’une application de gestion d’hôtel.

Voici ce que vous devez modéliser :

Un hôtel est constitué d'un certain nombre de chambres. Un responsable

de l'hôtel gère la location des chambres. Chaque chambre se loue à un
prix donné.

L'accès aux salles de bain est compris dans le prix de la location d'une
chambre. Certaines chambres comportent une salle de bain, mais pas
toutes. Les hôtes de chambres sans salle de bain peuvent utiliser une
salle de bain sur le palier. Ces dernières peuvent être utilisées par
plusieurs hôtes.

Les pièces de l'hôtel qui ne sont ni des chambres, ni des salles de bain
(hall d'accueil, cuisine...) ne font pas partie de l'étude (hors sujet).

Des personnes peuvent louer une ou plusieurs chambres de l'hôtel, afin

d'y résider. En d'autre termes : l'hôtel héberge un certain nombre de
personnes, ses hôtes (il s'agit des personnes qui louent au moins une
chambre de l'hôtel...).

11

Définition et intérêt :
Un diagramme d’objets est une instance d’un diagramme
de classes (instanciation des classes et des associations) qui
montre l’état du système modélisé à un instant donné.
Un diagramme d’objets peut être utilisé pour :
· Illustrer le modèle de classes en montrant un exemple qui
explique le modèle;
· Préciser certains aspects du système en mettant en
évidence des détails imperceptibles dans le diagramme de
classes;
45
Lorsque des objets ont les mêmes attributs et
comportements : ils sont regroupés dans une famille
appelée : Classe.
Les objets appartenant à celle-ci sont les instances de cette
classe.
L’instanciation est la création d’un objet d’une classe.
47
22/04/2017
Vérifier les multiplicités des associations;
· Exprimer une exception en modélisant des cas
particuliers ou des connaissances non généralisables qui ne
sont pas modélisés dans un diagramme de classes;
· Prendre une image d’un système à un moment donné.
Le diagramme de classes modélise les règles et le
diagramme d’objets modélise des faits.
46
Le nom d’un objet est toujours souligné. Il peut prendre trois
formes :
nom_objet (on indique le nom de l’objet)
nom_objet : Nom_classe (le nom et la classe de l’objet
séparés par un double point)
: Nom_classe (seulement la classe de l’objet est indiquée,
l’objet est alors dit anonyme).
48
12
 22/04/2017

◦ Une classe peut apparaître dans différents packages (avec le même

Un package permet de regrouper un ensemble de classes,
d’associations et éventuellement d’autres packages.
Il permet de découper un système en plusieurs parties
représentées chacune par un package.
nom).
◦ On y trouve même des classes qui n’appartiennent pas au package mais
qui sont référencées par les classes propres.
◦ On désigne une classe d’un package par :
nomPackage :: nomClasse

Les packages peuvent avoir des actions entre eux. Client

Facturation :: Facture
Facturation
Client
1 * 1
Client Société
Concerner
1
Acheter
1 *

Commande Produit
Comptabilité

49 50

13
 14/05/2017

Université d’Alger 1-Ben Youcef Ben Khedda

Faculté des Sciences
Département de Mathématiques et Informatique

UML (Unified
(Unified Modeling Language )

A. Benghalia
abderaoufb@yahoo.fr

1 2

Programme 5) Diagramme d'états-

d'états-transitions
1. Chapitre 1 : Le Génie Logiciel
1.1 Introduction : le logiciel
1.2 Génie logiciel : définition, objectif et développement de logiciel
1.3 Les cycles de développement du logiciel
1.4 Introduction à la modélisation, Modèle
1.5 Modélisation orienté objet (Historique + Concepts)

2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique
2.3 Les différents diagrammes d’UML

3. Chapitre 3 : Modélisation de S.I. avec UML

3.1 La vue fonctionnelle
3.2 La vue dynamique
3.3 La vue statique
4

1

Les diagrammes d'états-transitions d'UML décrivent le
comportement interne d'un objet à l'aide d'un automate à états
finis.
Ils présentent les séquences possibles d'états et d'actions
qu'une instance de classe peut traiter au cours de son cycle de
vie en réaction à des événements discrets.
Objectif : Décrire le comportement dynamique d'une entité
Un diagramme d’états-transitions modélise le cycle de vie
(comportement) d’un objet ou d’un système pris dans son
ensemble.
5 6
Représentation du comportement des objets d’une classe en
terme d’états et de transitions d’états
Comportement décrit par états + transitions entre les états
◦ État : abstraction d'un moment de la vie d'une entité pendant lequel
elle satisfait un ensemble de conditions
◦ Transition : changement d'état
7 8
14/05/2017
Un automate à états finis est un ensemble fini d'états, l'état
où il se trouve est appelé l'« état courant ». Le passage d'un
état à un autre est dirigé par un événement ou une condition ;
ce passage est appelé une « transition ».
Un automate est défini par la liste de ses états et par les
conditions des transitions.
On rencontre couramment des automates finis dans de
nombreux appareils qui réalisent des actions déterminées en
fonction des événements qui se présentent.
Exemple : un distributeur automatique de boissons qui
délivre l'article souhaité quand le montant introduit est
approprié
Le comportement est modélisé par un graphe :
◦ Nœuds = états possibles des objets
◦ Arcs = transitions d’état à état.
Une transition :
◦ exécution d’une action
◦ réaction de l’objet sous l’effet d’une occurrence d’évènement
Lorsque les événements se produisent, les objets changent
d’état en respectant les règles décrites
Les diagrammes d’états-transitions sont des graphes
orientés
Les états sont reliés par des connexions unidirectionnelles
appelées transitions
2

Un diagramme d’états-transition est toujours associé à une
et une seule classe. Un objet peut passer par plusieurs états
pendant sa durée de vie.
Un état représente une période dans la vie d'un objet
pendant laquelle ce dernier attend un événement ou
accomplit une activité.
L'état de l'objet correspond à un moment de son cycle de
vie.
9 10
Son rôle, est de décrire le fonctionnement d’une machine
(ou d’un objet) ayant un comportement séquentiel.
Il représente les différents états (situations) dans lesquels
peut se trouver ainsi que la façon dont cette machine (ou
l'objet) passe d’un état à l’autre en réponse à des
événements.
Il considère les concepts suivants :
◦ les états
◦ les transitions et les événements
◦ les actions et les activités.
11
14/05/2017
L'ensemble des états du cycle de vie d'un objet contient un
état initial.
Il peut également contenir un ou plusieurs états finaux.
Ceux-ci correspondent à une phase de destruction de
l'objet.
Il arrive également qu'il n'y ait pas d'état final car un objet
peut ne jamais être détruit.
un état, se représente graphiquement dans un diagramme
d'états-transitions par un rectangle aux coins arrondis
Un diagramme d’états a toujours un et un seul état initial
pour un niveau hiérarchique donné.
Il peut n’avoir aucun état final ou plusieurs.
Un état correspond à la situation d’un objet pendant un
certain temps.
12
3
 14/05/2017

Un événement est quelque chose qui se produit pendant

l'exécution d'un système.
Les diagrammes d'états-transitions permettent de spécifier
les réactions d'une partie du système à des événements
discrets.
Un événement se produit à un instant précis et est dépourvu
de durée.
Quand un événement est reçu, une transition peut être
déclenchée et faire basculer l'objet dans un nouvel état.
On peut diviser les événements en plusieurs types : signal,
appel, changement et temporel.

13 14

syntaxe d’un événement Événement de type signal (signal) : Correspond à la

Nom de l’événement (Nom de paramètre : Type, …)
Remarques :
une transition peut ne pas avoir d’ événement associé;
on ne peut pas associer plus d’un événement à une
transition ;
un même type d’ événement peut être associé à plusieurs
transitions ;
réception d’un signal asynchrone émit par un autre objet ou
par un acteur. La réception d'un signal est un événement
pour l'objet destinataire. Un même objet peut être à la fois
expéditeur et destinataire.
Les signaux sont déclarés dans le diagramme de classes de la
même manière qu’une classe mais en ajoutant le stéréotype
<<signal>> au dessus du nom de la classe.

15 16

4
 14/05/2017

Événement de changement (change) : Un événement de

Événement appel d'opération (call event) : Un événement changement est généré par la satisfaction (de faux à vrai).
d'appel représente la réception de l'appel d'une opération par Il s'agit d'attendre qu'une condition soit satisfaite. La syntaxe
un objet. d'un événement de changement est la suivante :
La syntaxe d'un événement d'appel est la même que celle when (condition_booléenne )
d'un signal.
Les événements d'appel sont des méthodes déclarées au
niveau du diagramme de classes.

17 18

II.I) Transition externe

Les événements temporels sont générés par le passage du
temps. Une transition externe est une transition qui modifie l'état
actif. Elle indique le passage d’un état (état source) vers un
Ils sont spécifiés soit de manière absolue (date précise), soit
autre (état cible).
de manière relative (temps écoulé). Par défaut, le temps
commence à s'écouler dès l'entrée dans l'état courant. Il s'agit du type de transition le plus répandu. Elle est
représentée par une flèche orientée de l’état source vers l’état
Manière absolue (déclenchement à une date précise)
cible.
◦ Syntaxe : when (date = expression précise d’une date)
ex : when(date=
when(date=25
25//04
04//2017
2017)) L'événement qui détermine le franchissement de la transition
Manière relative (déclenchement après une certaine durée est indiqué sous forme de texte.
passée dans l’état actuel)
actuel)..
◦ Syntaxe : after(expression
after(expression d’une durée)
ex : after(
after(15secondes)
15secondes)

19 20

5
 14/05/2017

Une transition est déclenchée par un événement.

C'est l'arrivée d'un événement qui conditionne la transition.
Les transitions peuvent aussi être automatiques, lorsqu'on ne
spécifie pas l'événement qui les déclenche.
En plus de spécifier un événement précis, il est aussi possible
de conditionner une transition, à l'aide de "gardes" : il s'agit
d'expressions booléennes, exprimées en langage naturel (et
encadrées de crochets).

21 22

La condition de garde est évaluée uniquement lorsque

l'événement déclencheur se produit.
Si l'expression est fausse à ce moment-là, la transition ne se
déclenche pas, si elle est vraie, la transition se déclenche.
Par contre, la différence entre une condition de garde et un
événement de changement.
changement La première est évaluée une fois
que l'événement déclencheur de la transition a lieu. Si elle est
fausse, la transition ne se déclenche pas et la condition n'est
pas réévaluée. Un événement de changement est évalué
continuellement jusqu'à ce qu'il devienne vrai, et c'est à ce
moment-là que la transition se déclenche.
Une transition sans nom d’événement est appelée transition
automatique, elle est déclenchée lorsque l’activité de l’état
source est terminée.
23
II.II. Transition interne
les transitions internes ne sont pas représentées par des arcs,
mais sont spécifiées dans un compartiment de leur état
associé
Les transitions internes possèdent des noms d'événement
prédéfinis correspondant à des déclencheurs
particuliers : entry, exit, do, on et include.
Ces mots-clefs réservés viennent prendre la place du nom de
l'événement dans la syntaxe d'une transition interne.
24

6
 14/05/2017

entry : définit l’activité à exécuter lors de l’entrée dans l’état.

exit : définit l’activité à exécuter lors de la sortie de l’état.
do : définit l’activité à exécuter dès que celle définie par entry
est terminée.
on : (optionnel) définit l’activité à exécuter à chaque fois que
nous avons un événement particulier.
Include : permet d'invoquer un sous-diagramme
d'états-transitions.
Les transitions internes s’écrivent à l’intérieur de l’état,
séparé du nom de l’état par un trait.

25 26

Le mode courant est le mode Affichage .

Quand on appuie une fois sur le bouton A, la montre passe en
modification heure .
Chaque pression sur le bouton B incrémente l’heure d’une
unité.
Quand on appuie une nouvelle fois sur le bouton A, la montre
passe en modification minute .
Chaque pression sur le bouton B incrémente les minutes d’une
unité. Quand on appuie une nouvelle fois sur le bouton A, la
montre repasse en mode Affichage

27 28

7
 14/05/2017

Il est possible de représenter des alternatives pour le

franchissement d'une transition en utilisant des pseudo-états
particuliers : les points de jonction et les points de décision.
a) Point de jonction :
Les points de jonction sont représentés par un cercle plein : Ils
permettent à plusieurs transitions d’avoir une partie commune
en partageant des segments de transition.
L’utilisation de points de jonction a pour but de rendre la
notation des transitions alternatives plus lisible.
Un point de jonction peut avoir plusieurs segments de
transition entrante et plusieurs segments de transition sortante.
Par contre, il ne peut avoir d'activité interne ni des transitions
sortantes dotées de déclencheurs d'événements.
29 30

31 32

8

B) Point de décision : Les points de décision sont représentés
par des losanges : Ils ont un fonctionnement similaire à celui
du point de jonction mise à part que nous pouvons sortir de
l’état d’origine dès que le segment avant le point de décision
est franchissable (même si aucun des segments après le point
de décision n’est franchissable).
Le choix du segment à franchir derrière le point de décision se
fait au moment de l’arrivée sur le point de décision.
Un point de décision possède une entrée et au moins deux
sorties.
Si, quand le point de décision est atteint, aucun segment en
aval n'est franchissable, c'est que le modèle est mal formé.
33
35
14/05/2017
Remarque :
Lorsque nous arrivons sur un point de décision, il faut qu’un
des segments de transition qui suit, soit franchissable (une
transition n’ayant pas de durée, nous ne pouvons pas rester à
attendre quelque chose au niveau du point de décision).
Pour éviter ce problème nous pouvons ajouter un segment
avec la garde [else] qui est automatiquement franchie si
aucune des gardes des autres segments n’est vraie.
34
9
 14/05/2017

Université d’Alger 1-Ben Youcef Ben Khedda

Faculté des Sciences
Département de Mathématiques et Informatique

Processus unifié (UP)

A. Benghalia
abderaoufb@yahoo.fr

1 2

Un processus ou une démarche, est dans la majorité des
cas, un ensemble d’activités inter reliées et menées dans le
but de définir un produit.
Un processus ou une démarche est un ensemble cohérent
d’activités permettant la construction d’un SI.
Il représente l’ensemble des étapes permettant de spécifier
◦ • Les décisions à prendre
◦ • Comment les prendre
◦ • Dans quel ordre
La partie produit est la cible désirée d’un développement de
SI.
La partie processus (aussi appelée « partie démarche ») est
la route à suivre pour atteindre ce but.
Plus le projet est grand plus le processus de construction
devient complexe et se doit d’être :
◦ clair et précis pour une utilisation optimale de la
modélisation.

3 4

1

UP (Unified Process, « processus unifié ») est un
processus de développement logiciel itératif, centré sur
l'architecture, piloté par des cas d'utilisation et orienté vers
la diminution des risques
C'est un processus pouvant être adaptée à une large classe
de systèmes logiciels, à différents domaines d'application, à
différents types d'entreprises, à différents niveaux de
compétences et à différentes tailles de l'entreprise.
5 6
Le but principal d'un système informatique est de
satisfaire les besoins du client.
Le processus de développement sera donc accès sur
l'utilisateur.
Les cas d'utilisation permettent d'illustrer ces besoins. Ils
détectent puis décrivent les besoins fonctionnels (du point
de vue de l'utilisateur),
S’il est vrais que les cas d’utilisation guident le processus
de développement, ils ne sont pas sélectionnés de façon
isolée, mais doivent absolument être développés "en
tandem" avec l’architecture du système.
7 8
14/05/2017
Le processus unifié est à base de composants,
Le processus unifié utilise le langage UML (ensemble
d'outils et de diagramme),
Le processus unifié est piloté par les cas d’utilisation,
Centré sur l’architecture,
Itératif et incrémental
Le développement d’un logiciel peut s’étendre sur
plusieurs mois. Tout le logiciel ne sera pas développer
d’un coup.
On peut découper le travail en plusieurs parties qui sont
autant de mini projets. Chacun d’entre eux représentant
une itération qui donne lieu à un incrément.
Une itération désigne la succession des étapes de
l’enchaînement d’activités,
tandis qu’un incrément correspond à une avancée dans
les différents stades de développement.
2
 14/05/2017

A chaque itération, les développeurs identifient et

spécifient les cas d’utilisations pertinents,
créent une conception en se laissant guider par
l’architecture choisie,
implémentent cette conception sous forme de composants
et vérifient que ceux ci sont conformes aux cas
d’utilisation.
Dés qu’une itération répond aux objectifs fixés le
développement passe à l’itération suivante.

9 10

Permet de limiter les retards, les coûts, en termes de
risques, aux dépenses liées à une itération.
Identification des problèmes dès les premiers stades de
développement et non pas en phase de test comme avec
l’approche « classique »).
Permet d’accélérer le rythme de développement grâce à des
objectifs clairs et à court terme.
Permet de prendre en compte le fait que les besoins des
utilisateurs et les exigences correspondantes ne peuvent
être intégralement définis à l’avance et se dégagent peu à
peu des itérations successives
Dès le démarrage du processus, on aura une vue sur
l'architecture à mettre en place.
L’architecture d’un système logiciel peut être décrite
comme les différentes vues du système
L’architecture logicielle équivaut aux aspects statiques et
dynamiques les plus significatifs du système.
L’architecture émerge des besoins de l’entreprise, tels
qu’ils sont exprimés par les utilisateurs et autres
intervenants et tels qu’ils sont reflétés par les cas
d’utilisation.

11 12

3
 14/05/2017

Les cas d’utilisation doivent une fois réalisés, trouver leur Le processus unifié répète un certain nombre de fois une
place dans l’architecture. série de cycles.
L’architecture doit prévoir la réalisation de tous les cas Tout cycle se conclut par la livraison d’une version du
d’utilisation. produit aux clients et s’articule en
L’architecture et les cas d’utilisation doivent évoluer de 4 phases et Chaque phase se subdivise à son tour en
façon concomitante. itérations.
L’architecture se dévoile peu à peu, au rythme de la Un groupe de 4 phases = un cycle
spécification et de la maturation des cas d’utilisation, qui Les 4 phases qui composent le processus UP
favorisent, à leur tour, le développement d’un nombre 1-Création 3-Construction
croissant de cas d’utilisation. 2- Elaboration 4-Transition

13 14

Itération

Chaque cycle (Création, Construction, Elaboration,

Transition) se traduit par une nouvelle version du système.
Ce produit se compose d’un corps de code source réparti
sur plusieurs composants pouvant être compilés et exécutés

Une itération comporte les activités suivantes :

Expression des besoins
Analyse
Conception
Implémentation
Test
15 16

4

Analyse des besoins
Cette phase Comprend :
La définition des objectifs pour établir les limites du projet
La réduction des risques majeurs
L’identification des cas d’utilisation principaux
L’identification d’une architecture provisoire
L’étude de rentabilité
La planification de la phase d’élaboration
17
Construction
Consiste à concevoir et implanter l’ensemble des éléments
opérationnel.
Développement du logiciel exécutable.
L’architecture de référence devient un produit complet.
Le produit contient tous les cas d’utilisation que les chefs
de projet ont décidé de mettre au point pour cette version.
La première version peut encore avoir des anomalies qui
peuvent être en partie résolues lors de la phase de
transition.
19
14/05/2017
Elaboration
Permet de définir et de construire l’architecture de base du
système de manière stable.
Identifie et décrit la majorité des besoins utilisateurs en
précisant la plupart des cas d’utilisation.
Précise l’étude commerciale puisqu’à l’issue de cette
phase, le chef de projet doit être en mesure de prévoir les
activités et d’estimer les ressources nécessaires à
l’achèvement du projet.
18
Transition
Permet de faire passer l’application des développeurs aux
utilisateurs finaux.
C’est la mise en production du logiciel, avec la conversion
des données, la formation des utilisateurs, le déploiement,
les beta-tests.
Un groupe d’utilisateurs essaye le produit et détecte les
anomalies et défauts.
Peut nécessiter la mise en œuvre d’un service d’assistance
ou la correction des anomalies. détectées (ou le report à la
version suivante).
20
5

Expression des besoins
L'expression des besoins comme son nom l'indique, permet
de définir les différents besoins :
Recenser les besoins fonctionnels (du point de vue de
l'utilisateur) qui conduisent à l'élaboration des modèles de
cas d'utilisation
Le modèle de cas d'utilisation présente le système du point
de vue de l'utilisateur et représente sous forme de cas
d'utilisation et d'acteurs, les besoins du client.
21
La conception
permet d'acquérir une compréhension approfondie des
contraintes liées au langage de programmation, à
l'utilisation des composants et au système d'exploitation.
Elle détermine les principales interfaces et les transcrit à
l'aide d'une notation commune.
Elle constitue un point de départ à l'implémentation :
elle décompose le travail d'implémentation en sous-
système
elle créée une abstraction transparente de l'implémentation
23
14/05/2017
Analyse
L'objectif de l'analyse est d'accéder à une compréhension
des besoins et des exigences du client.
Il s'agit de livrer des spécifications pour permettre de
choisir la conception de la solution.
Un modèle d'analyse livre une spécification complète des
besoins issus des cas d'utilisation et les structure sous une
forme qui facilite la compréhension (scénarios), la
préparation (définition de l'architecture), la modification et
la maintenance du futur système.
22
Implémentation
L'implémentation est le résultat de la conception pour
implémenter le système sous formes de composants,
Les objectifs principaux de l'implémentation sont de
planifier les intégrations des composants pour chaque
itération, et de produire les classes et les sous-systèmes
sous formes de codes sources.
24
6

Test
Les tests permettent de vérifier des résultats de
l'implémentation en testant la construction.
Pour mener à bien ces tests, il faut les planifier pour
chaque itération, les implémenter en créant des cas de tests,
effectuer ces tests et prendre en compte le résultat de
chacun.
25
14/05/2017
Permet d’accélérer le rythme de développement grâce à des
objectifs clairs à court terme
Les éléments sont intégrés progressivement et non pas en
fin de cycle
Permet de limiter les risques de retard car : identification
des problèmes dès les premiers stades de développement
=> les premières itérations sont déroulées et vous examinez
tous les composants du processus au fur et à mesure
Peut permettre de fournir rapidement un produit avec des
fonctionnalités réduites
L’itération favorise la réutilisation du code
26