Cours2 Génie Logiciel 1

Faculté des Sciences - Département MI
2ème année Licence Ingénierie S.I. et Génie Logiciel
Génie Logiciel LG1

N
Chapitre 1 – Section 1 : Le Génie Logiciel - Introduction UEF41 – 2016/2017
A. Benghalia , abderaoufb@yahoo.fr
N. Taibouni, n_taibouni@esi.dz
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
1.3 Les cycles de développement du logiciel
1.4 Introduction à la modélisation
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
UEF41 – 2016/2017
Chapitre 1 : Le Génie Logiciel
Où se trouve le logiciel ?
UEF41 – 2016/2017
Logiciel- définition :
 Traduction du terme anglais « software » en 1967 par
Philippe Renard, Commission spécialisée de terminologie et
de néologie de l'informatique et des composants :
 « Ensemble des programmes, procédés et règles, et
éventuellement de la documentation, relatifs au
fonctionnement d'un ensemble de traitement de données »,
 Le terme « programme » se définissant comme une suite
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
UEF41 – 2016/2017
Logiciel- définition :
Tout simplement 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 »
UEF41 – 2016/2017
1.1 Introduction
O N
U TI
C
E XE
Achats Production Distribution Marketing/Ventes
Usine
Administration
École
Banque
Entreprise /organisation Association
Université
Cabine
Etc …Hôpital
desportive
service
0
Définie des stratégies
1
25
20
2
3
4
5
6
Fixe les objectifs
15
10
7
8
9
10
11
12
Système de décision Décide des choix
5 13
14
00246810
12
14
16
18
15
20
16
Matières premières décisions

Énergie CapitaliseBiens
les connaissances
Informations Services
S st e d’i fo atio Gère les données
Entrées sorties
informations
Flux physique
t a sfo e u flu d’e t e
Système opérant en flux de sortie (produits finis).
A. Benghalia , abderaoufb@yahoo.fr Système dynamique 6
UEF41 – 2016/2017
1.1 Introduction
Vraiment je suis Fermeture de
la trappe
fatigué Ferme
la trappe C'est fermé.
Cas d’u e usi e Ca grince,
il faudra
graisser
Démarre
La réparation Démarrage
de la facture du camion
Préparez la facture
Chef
C'est
Ca ne bâché
Allez graisser c'est plein
coule plus
La réparation
la trappe
Comptabilité de la trappe
Maintenance
UEF41 – 2016/2017 7
1.1 Introduction
La coordination à distance
Automate
Il faut bâcher
Capteur avant de
partir
Trappe
motorisé
Comptabilité Maintenance
UEF41 – 2016/2017
1.1 Introduction Capteur
La coordination automatique
Capteur
Finance Gestion Tech. Maintenance Facture
9
UEF41 – 2016/2017
Chapitre 1 : L’entreprise
1.1 Notion de l’entreprise
Logiciel - caractéristiques :
 Produit non palpable,
 Développé par l’être humain (non industrialisé),
 Dont l’assemblage est difficile,
 et la maintenance devant être assurée par ceux qui l’ont
développé,
 Le logiciel peut être :
 Un logiciel système : Propriétaire d’u constructeur, qui est très dépendant
du matériel (OS, Logiciel de firewall, Drivers,…) ou propriétaire d’u éditeur
qui est une boîte noire généralement paramétrable (SGBD)
 Un logiciel application : Propriétaire d’u éditeur et assurant une fonction
précise (ERP, Bureautique, application de loisir); ou développé pour les
besoins spécifiques de l’e t ep ise, soit par elle-même, soit par
l’i te édiai e de sociétés de services.
UEF41 – 2016/2017
Logiciel – caractéristiques – la qualité :
 Le logiciel doit être de qualité, une erreur dans le
logiciel entraine des conséquences néfastes :
 En 1962, la sonde Mariner qui devait effectuer un passage
à 5 000 km de Vénus s'est perdue à 5 000 000 km de ladite
planète à cause d'une erreur de programme Fortran : le
point avait été remplacé par une virgule (format US des
nombres).
 En 1983, toute la vallée du Colorado a été inondée. La

cause ? Une mauvaise modélisation dans le logiciel du
temps d'ouverture du barrage.
UEF41 – 2016/2017
 Le logiciel doit être de qualité, une erreur dans le
logiciel entraine des conséquences néfastes :
 Le 4 juin 1996, lors du premier lancement de la fusée
Ariane V, celle-ci explose en vol. La cause : un logiciel
utilisé sous Ariane IV et intégré sans nouvelle validation
dans Ariane V. Un module convertissait des réels 64 bits en
des entiers signés 16 bits ce qui a cause un
fonctionnement anormal des moteurs. La fusée s’est
désintégrée après 40 secondes de vol. Coût : 1/2 milliard
de dollars
UEF41 – 2016/2017
Logiciel – caractéristiques - la qualité :
Qu’est ce u’u bon logiciel ? Plusieurs exigences (critères
existent, les plus complets 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.
UEF41 – 2016/2017
UEF41 – 2016/2017
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, u’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;
UEF41 – 2016/2017
UEF41 – 2016/2017
UEF41 – 2016/2017
Comme tout projet,

la réalisation d'un
C’est l’un des buts
logiciel est soumise
à des exigences
du
contradictoires et Génie Logiciel
difficilement
conciliables
(triangle coût-délai-
qualité).
UEF41 – 2016/2017
Réunion préparatoire
au Comité Exécutif
Merci
N
Génie Logiciel LG1

N
Programme
2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique

3.3 La vue statique
UEF41 – 2016/2017
1.2 Le Génie Logiciel
1.2.1 Définition :
Génie : « Aptitude naturelle de l'esprit de quelqu'un qui le
rend capable de concevoir, de créer des choses, des concepts
d'une qualité exceptionnelle » (Le Dictionnaire Larousse);
Logiciel : «Un ensemble de programmes qui permet à
l'ordinateur ou à un système informatique de réaliser une ou
plusieurs tâches particulières »
Génie Logiciel :
D’après la Norme IEEE 610.12 : « Le Génie Logiciel est
l’application d’une approche systématique, disciplinée et
quantifiable au développement, à l’exploitation et à la
maintenance du logiciel. C’est-à-dire, l’application de
l’ingénierie au logiciel »
UEF41 – 2016/2017
1.2.1 Définition :
Génie Logiciel :
Tout simplement :
« Le génie logiciel (software engineering) représente
l'application de principes d'ingénierie au domaine de la
création de logiciels. Il consiste à identifier et à utiliser des
méthodes, des pratiques et des outils permettant de
spécifier, concevoir, réaliser et faire évoluer le logiciel en
maximisant les chances de réussite d'un projet logiciel »
UEF41 – 2016/2017
1.2.2 Objectifs :
La première motivation du Génie Logiciel est la réduction des
coûts de développement du logiciel (efficience) par la
rationalisation et l’optimisation du processus de
production d'un logiciel;
Produire des logiciels répondants à des critères de
qualité définis au préalable :
Adéquation aux besoins du client,
Respect des délais et des coûts de réalisation prévus,
En plus, il doit être maintenable, fiable, efficace et doit
offrir une interface utilisateur appropriée.
UEF41 – 2016/2017
1.2.3 Apparition du Génie Logiciel :
Le terme « génie logiciel, Software Engineering » a été
introduit pour la première fois en 1968 lors d’une
conférence internationale consacrée à des discussions
sur la « crise du logiciel »,
La crise est apparue lorsque l’on a pris conscience que :
le coût du logiciel dépassait le coût du matériel
(Aujourd’hui, il le dépasse très largement),
Les logiciels étaient de mauvaise qualité et ne
répondaient pas aux besoins,
N. Taibouni, n_taibouni@esi.dz UEF41 – 2016/2017

1.2.3 Apparition du Génie Logiciel :
En 1993, la branche informatique (Computer Society) de
l’IEEE (Institute of Electrical and Electronics Engineers) et
l’ACM (Organisation professionnelle américaine des
informaticiens) ont établi un comité conjoint dont la tâche
était de définir un ensemble de critères et de normes
appropriés pour la pratique professionnelle du Génie Logiciel
(SWEBOK Guide : The Guide to the Software Engineering
Body of Knowledg), aujourdhui, le guide est à sa 4ème version
(ACM s’est retirée en 2000)
UEF41 – 2016/2017
1.2.3 Apparition du Génie Logiciel – Crise du logiciel :
Rapport de 1979 sur la réussite et l’échec des projets
UEF41 – 2016/2017
1.2.3 Apparition du Génie Logiciel – Crise du logiciel:
Rapports CHAOS du Standish Group :
Le premier rapport : 1994.
UEF41 – 2016/2017
1.2.3 Apparition du Génie Logiciel – Crise du logiciel:
Facteurs de réussite / échec des projets :
UEF41 – 2016/2017
1.2.4 Développement de logiciels :
Fait en TD
UEF41 – 2016/2017
Cycle de vie d’un logiciel
Analyse et spécification des besoins
Conception du logiciel
Implémentation du logiciel
Test et validation du logiciel
Maintenance du logiciel
12
Modèles de cycles
de vie d’un logiciel
13
Le cycle de vie en cascade
Etude de faisabilité
Validation
Définition des besoins
Validation
Conception générale
Vérification
Conception détaillée
Vérification
Codage
Tests unitaires Intégration
Tests d ’intégration Implémentation
14
Les phases traditionnelles de développement sont
effectuées les unes après les autres, avec un retour sur les
précédentes, voire au tout début du cycle,
Le processus de développement utilisant un cycle en
cascade exécute des phases qui ont pour caractéristiques :
◦ de se terminer à une date précise ;
◦ de ne se terminer que lorsque les livrables sont jugés
satisfaisants lors d'une étape de validation-vérification.
15
Le cycle de vie en V
Analyse des besoins Test d ’acceptation
Conception du système Test du système
Conception du
Test du composant i
composant i
Codage du composant i
16
Une activité peut commencer avant d’avoir terminé la
précédente,
Toute description d'un composant est accompagnée de
tests,
Ce modèle est une amélioration du modèle en cascade qui
permet en cas d'anomalie, de limiter un retour aux étapes
précédentes,
Les phases de la partie montante doivent renvoyer de
l'information sur les phases en vis-à-vis lorsque des défauts
sont détectés afin d'améliorer le logiciel.
17
Le cycle de vie en spirale
◦ fournir le plus rapidement possible un prototype pour
valider les concepts
◦ se rapprocher progressivement de l’application finale
Conception du système Analyse des besoins
3
Développement Exploitation
18
Un modèle est une représentation simplifiée d’une réalité
que l’on veut étudier (plan d’une maison, carte
géographique, schéma électronique…),
Un modèle n’est pas la réalité; MAIS SE CONSTRUIT A
PARTIR DE L’OBSERVATION DE LA REALITE,
Un modèle est une abstraction, une synthèse (ne garde
que l’essentiel) d’un aspect de la réalité étudiée.
Nécessité donc de plusieurs modèles pour représenter
plusieurs aspects de cette réalité,
Un modèle, généralement graphique, s’exprime avec un
ensemble de concepts dotés de règles d’utilisation et de
représentation (Entité-Association, UML…),
UEF41 – 2016/2017
Les modèles servent à :
Communiquer : entre analystes, analystes et
concepteurs..; et même avec les utilisateurs pour vérifier
et valider la compréhension de la réalité et du problème
étudiés,
Documenter : les modèles constituent une
documentation qui sera utilisée pour la maintenance,
Préparer la phase d’implémentation (codage) de la
solution (en phase de conception),
UEF41 – 2016/2017
Système de
décision
Décisions
?
Analyse des aspects Informationnels
Système
d’information
On cherche à concevoir
Informations ?
Flux physique ? Les objets manipulés dans l’entreprise

Système opérant
Objets d’entreprise Relations entre les objets
Concevoir une partie du logiciel
21
La modélisation est la conception d'un modèle.
Objectif principal de la modélisation = maîtriser la complexité
Modéliser = abstraire la réalité pour mieux comprendre le
système à réaliser
Le modèle doit être relié au monde réel
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
vérifier et valider la cohérence de l’architecture logiciel et leur
contexte,
22
Flux physique ?
Analyse des aspects fonctionnels
Système opérant
On cherche à décrire
Ce que fait l’entreprise en termes de taches à exécuter
La fonctionnalité de l’entreprise Le comportement de l’entreprise
Activité Processus
23
Activité
informa
tion
Entrée (I) Sortie (O)

Activité Activité :
Est une transformation qui ajoute de la
valeur.
elle implique un certain nombre de
Ressources
ressources
( des personnes, de l’argent , des
matières et
du matériel ) pour transformer un objet
d’entrée en un objet de sortie.
24
Processus
Processus
Entrée
Acitivité1
Activité2
Sortie
Matières-
… Activitén Objectif
premières
Énergie Biens matériels
Informations ou immatériels
Enchainement logique d’activités
Processus :
Est un enchainement logique d’activités dans le temps afin de réaliser un but
25
Modélisation Orienté Objet
26
Principes de l’orienté objet :
1. L’abstraction : l’essentiel d’un objet
C’est une action de l’esprit, à partir d’un objet réel donné, on extrait
une signification utile et construit une idée ou un concept
manipulable [Association française du Génie Logiciel version 1995],
Grady Booch la définit par : « Une abstraction définit les
caractéristiques essentielles d’un objet qui le différencie de tous les
autres objets, et trace ses frontières. Ceci est toujours relatif à la
perspective de l’observateur »
Ces caractéristiques sont liées au domaine d’étude,
On ignore les détails, on ne garde que l’essentiel
Exemple : L’objet « Etudiant » dans une gestion de scolarité :
Matricule, Nom & prénom, Adresse, téléphone, Filière BAC,
Moyenne Bac, son parcours à l’université….
On ignore : les détails sur sa personnalité, les détails sur sa vie
personnelles,…
UEF41 – 2016/2017
Principes de l’orienté objet :
1. La Hiérarchie : l’organisation
La hirarchie est lorganisation des connaissances sous forme
pyramidale. Cest diviser les comportements dune classe de faon
hirarchique. Cela permet une comprhension plus rapide du problme.
Cest aussi un systme de classification.
UEF41 – 2016/2017
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
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)
1995 : Premier consensus
◦ OMT : Object Modeling TechniqueNotation graphique
riche (General Electric, 1980 par Rambaugh)
◦ OOD : Object Oriented Design (Grady Booch) concept de
package ( élément d’organisation des modèles)
◦ OOSE : Object Oriented Software Engineering ( Ivar
Jacobson Ericsson) repose sur l'analyse des besoins des
utilisateurs.
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
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
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
32
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.
33
Rechercher les différents types d’objets qui font partie du
système à réaliser :
la banque, les clients, les comptes bancaires, les conseillers
clients, les transferts, les placements, les emprunts.
Etudier ensuite les interactions entre ces différents types
d’objets : par exemple, la création d’un compte bancaire
nécessite des interactions entre le client et un conseiller client
34
Merci
N
Génie Logiciel LG1

N
Chapitre 2 – UML UEF41 – 2016/2017
Programme
2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique

3.3 La vue statique
UEF41 – 2016/2017
Chapitre 2 : UML – Unified Modeling Language
2.1 Introduction
 La produ tio d’u logi iel essite :
 Méthode :
 qui structure les différentes activités du cycle de vie
(démarche),
 Qui possède des modèles avec le formalisme pour leur
construction,
 Outils :
 Langage de modélisation (généralement offert par la
méthode),
 Outils technologiques (modélisation, écriture de code,
tests…AGL, ALM,…
UEF41 – 2016/2017
2.1 Historique de UML
 Les principaux acteurs dans la définition de UML sont :
 G.Booch, J.Rumbaugh et I.Jacobson
 Booch91 et OMT1 étaient les premiers modèles,
 1993, les nouvelles versions Booch93 et OMT2 sont pratiquement
identiques,
 1994, J. Rumbaugh entre dans la société Rational de G.Booch,
 1995, publication de la première version UM 0.8 (Unified Method),
 1996, Ivar Jacobson se rejoint avec son modèle OOSE, la première
version de UML 0.9 paraît,
 997 la versio UML . est propos e à l’OMG O je t Modelling
Group) pour standardisation,
 Nove re 997, la versio . est sta dardis e par l’OMG,
 L’ volutio de UML peut tre suivie sur le site de l’OMG.
UEF41 – 2016/2017
Chapitre 2 : UML – Unified Model Language
2.1 Historique de UML
 Mars 2015 UML 2.5; UML est utilisée pout tout type de
logiciel.
UEF41 – 2016/2017
 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 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
6
langage de modélisation objet unifié
 UML est un langage pour :
 Visualiser
 Chaque symbole graphique possède une sémantique
 Spécifier
 De manière précise et complète, sans ambiguïté
 Construire
 Une partie du code des classes peut être généré
automatiquement
 Documenter
 Les différents diagrammes, notes, contraintes, exigences
sont conservés dans un document
7
 langage de modélisation objet unifié
 UML n’est pas une méthode
 c'est un langage de modélisation dédié à l'objet.
 L'approche est faites par des diagrammes

destinés à modéliser plusieurs domaines :
 Les diagrammes structurels (vue statique)
 Les diagrammes comportementaux (vue
fonctionnelle)
 Les diagrammes d'interaction (vue dynamique)
8
 Un diagramme UML est une représentation
graphique, qui s'intéresse à un aspect du système
à réaliser,
 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.
9
Il est utilisé dans l’activité de
spécification des besoins. Il montre
les interactions fonctionnelles entre
les acteurs et le système à l’étude
10
représente les règles d’enchaînement des
actions et décisions au sein d’une activité.
Il peut également être utilisé comme
alternative au diagramme d’états pour
décrire la navigation dans le système
11
est le point central dans un développement
orienté objet. Il a pour objet de décrire la
structure des entités manipulées par les
utilisateurs.
12
Il montre les instances des éléments
structurels et leurs liens à l’exécution.
13
représente le cycle de vie commun aux
objets d’une même classe. Ce diagramme
complète la connaissance des classes en
analyse et en conception en montrant les
différents états et transitions possibles des
objets d’une classe à l’exécution
14
Il montre la séquence verticale des
messages passés entre objets au sein
d’une interaction
15
montre l’organisation logique du modèle
et les relations entre packages. Il permet
de structurer les classes d’analyse et de
conception, mais aussi les cas d’utilisation
16
 Points forts d’UML :

 Unifie l’équipe de développement autour d’une seule
notation qui couvre tout le cycle de développement du
logiciel;
 Permet de gérer la complexité des systèmes. Grâce au
raffinement possible de ses modèles, il est possible
d’utiliser UML pour concevoir un logiciel ou une navette
spatiale;
 Propose des modèles adaptés aux humaines (concepteurs,
utilisateurs) et aux machines (artefact manipulable par une
machine)
 C’est un langage ouvert, extensible à d’autres concepts
UEF41 – 2016/2017
 Points faibles d’UML :

 Nécessite un temps d’apprentissage et d’adaptation avant
sa mise en pratique,
 N’est pas une méthode, elle ne définit pas comment et
quand réaliser les différentes activités de développement
du logiciel,
 Son intégration à une méthode n’est pas évidente (De
Merise à UML, N. Kettani et al., Eyrolles, 1998)
UEF41 – 2016/2017
Chapitre 2 : UML
Bibliographie
MA.Mostefai, S.Batata, “Support de cours GL de l’ESI », 2012
P. Roques, « UML 2 par la pratique. N°12322, 6e édition », 2008,
P.Roques, « les Cahiers du Programmeur UML2, Modéliser une

application web 4e édition », 2008
Jacques Guyot, « CONCEPTION & REALISATION DES BASES DE

DONNEES : De UML à SQL », 2008
www.uml.org
Uml.free.fr
UEF41 – 2016/2017
Merci
N
Chapitre 2 – UML UEF41 – 2016/2017
Génie Logiciel LG1

N
Chapitre 3 : Modélisation du SI avec UML
UEF41 – 2016/2017
Le Diagra e des cas d’utilisatio
Programme
2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique

3.3 La vue statique
UEF41 – 2016/2017
Chapitre 3 : Modélisation des SI avec UML
3.1 Diagra e des cas d’utilisatio
 U cas d’utilisatio (« use case ») représente un ensemble de
s ue es d’a tio s ui so t alis es pa le s st e et ui
produisent un résultat observable intéressant pour un acteur
particulier.
 Cha ue as d’utilisatio sp ifie un comportement attendu du
système. Il permet de décrire ce que le futur système devra faire
(fonctionnalités), sans sp ifie comment il le fera.
 Un acteur représente un rôle joué par une entité externe au
système étudié (utilisateur humain, dispositif matériel ou autre
système) qui interagit directement avec le système étudié.
 Un acteur peut consulter et/ou odifie di e te e t l’ tat du
système, en émettant et/ou en recevant des messages porteurs de
données.
UEF41 – 2016/2017
 Est une personne ou un système extérieur au système en
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).
 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.
4
 Représentation graphique de l’acteur :
 Il est préférable d’utiliser la forme graphique du « stick man »

pour les acteurs humains et une représentation rectangulaire
pour les systèmes connectés
 Représentation graphique du cas d’utilisation :
UEF41 – 2016/2017
 Tous les acteurs n’utilisent pas forcément le système en étude
de la même façon,
 Acteur principal : celui pour qui le cas d’utilisation produit un
résultat observable.
 Acteurs secondaires : les autres participants du cas
d’utilisation. Les acteurs secondaires sont souvent sollicités
pour des informations complémentaires; ils peuvent
uniquement consulter ou informer le système lors de
l’exécution du cas d’utilisation.
 Une bonne pratique consiste à faire figurer les acteurs
principaux à gauche des cas d’utilisation et les acteurs
secondaires à droite.
UEF41 – 2016/2017
3.1 Diagra e des cas d’utilisatio Association qui signifie ici :
 Diagramme de cas d’utilisation : « participe à »
UEF41 – 2016/2017
 Relation entre acteur et cas d’utilisation :
 Signifie : « participe à » ;
 La présence de flèche sur le trait de la relation signifie
alimentation en information dans le sens unique de la flèche,
 La non présence de flèche signifie alimentation en
information dans les deux sens,
UEF41 – 2016/2017
 Relation entre cas d’utilisation :
 Une relation d’inclusion : formalisée par le mot-clé
<<include>>: le cas d’utilisation de base en incorpore
explicitement un autre, de façon obligatoire.
 Un cas d’utilisation peut avoir plusieurs cas d’utilisation
d’inclusion,
 Le cas d’utilisation
ne s’exécute que si tous ces
cas d’inclusion ont été exécutés
UEF41 – 2016/2017
 Une relation d’extension : formalisée par le mot-clé
<<extend>>: le cas d’utilisation de base en incorpore
implicitement un autre, de façon optionnelle
 SOIT deux CU : CU1 et CU2
 CU2 étend CU1 par un comportement optionnel qui a lieu sous
une certaine condition
 Cette o ditio est appel « poi t d’e te sio »
UEF41 – 2016/2017
 Une relation de généralisation/spécialisation : les cas
d’utilisation descendants héritent de la description de leur
parent commun. Chacun d’entre eux peut néanmoins
comprendre des interactions spécifiques supplémentaires.
UEF41 – 2016/2017
Acteur
généralisé Relation de type
Généralisation/sp
écialisation
Relation de type
extension
Relation « participe
à » avec échange
d’i for atio du
système vers
l’acteur
Relation de type
inclusion
UEF41 – 2016/2017
 Acteur généralisé :
 Dans le cas où deux acteurs, ou plus, présentent des similitudes
dans leurs relations aux cas d’utilisation; alors il y a lieu de
créer un acteur généralisé, éventuellement abstrait, qui
modélise les aspects communs aux différents acteurs concrets.
 Dans l’exemple précédent, l’acteur Internaute est la

généralisation abstraite des rôles Visiteur et Client.
 Le nom de l’acteur abstrait s’écrit en italique.
UEF41 – 2016/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
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. ……
post-conditions L’état du système après l’exécution du cas
Alternatif Pas de délivrance de carte si …
14
 Bonnes pratiques :
 Comment identifier les acteurs ?
Les acteurs candidats sont systématiquement :
 les utilisateurs humains directs : faites donc en sorte
d’identifier tous les profils possibles, sans oublier
l’administrateur, l’opérateur de maintenance, etc. ;
 les autres systèmes connexes qui interagissent aussi
directement avec le système étudié, souvent par le biais de
protocoles bidirectionnels.
UEF41 – 2016/2017
 Comment identifier les cas d’utilisation ?
Les cas d’utilisation doivent décrire exhaustivement les exigences
fonctionnelles du système.
 Chaque cas d’utilisation correspond à une fonction métier du
système, selon le point de vue d’un de ses acteurs.
 Pour chaque acteur, il convient de :
 rechercher les différentes intentions métier avec lesquelles il
utilise le système,
 déterminer dans le cahier des charges les services
fonctionnels attendus du système,
UEF41 – 2016/2017
 Une erreur fréquente concernant les cas d’utilisation consiste à
détailler de façon très fine les séquences d’actions.
 Le cas d’utilisation ne doit donc pas se réduire
systématiquement à une seule séquence, et encore moins à
une simple action. Le cas d’utilisation représente un ensemble
de séquences d’actions réalisées par le système, et le lien entre
ces séquences d’actions est précisément l’objectif métier de
l’acteur.
UEF41 – 2016/2017
EXERCICES
18
EXERCICE -1-
• Une agence de voyages organise des voyages
où l’h e ge e t se fait e hôtel. Le lie t
doit dispose d’u ta i ua d il a ive à la ga e
pou se e d e à l’hôtel.
19
Système de réservation Agence de Voyages
Réserver un taxi
Réserver une Réserver un billet

chambre de train
Organiser un
voyage
Client
20
 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 ?
21
22
23
24
Bibliographie


www.uml.org
Uml.free.fr
UEF41 – 2016/2017
Merci
N
Le Diagra e des cas d’utilisatio UEF41 – 2016/2017
Génie Logiciel LG1

N
UEF41 – 2016/2017
Le Diagramme d’activité
Programme
2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique

3.3 La vue statique
UEF41 – 2016/2017
3.2 Diagramme d’activité
3.2.1 Présentation :
Un cas d’utilisation décrit ce que le futur système devra
faire (fonctionnalités), sans spécifier comment il le fera;
Le diagramme d’activité permet de spécifier le
« comment » doit faire le système pour accomplir ses
fonctionnalités,
 Un diagramme d’activité permet de représenter un
comportement du système (sa dynamique). Ce
comportement peut être celui d’un cas d’utilisation, une
méthode d’une classe, un processus métier…
UEF41 – 2016/2017
Les diagrammes d’activité sont adaptés à la modélisation
des processus métiers (achat, production, vente, …),
Les diagrammes d’activité sont très utilisés dans la phase

d’analyse car ils sont simples à comprendre par les
utilisateurs,
UEF41 – 2016/2017
3.2.2 Les éléments de base d’un DA :
1. Les actions : c’est l’unité fondamentale de spécification
comportementale en UML 2.0. Elle représente un
traitement ou une transformation. Les actions sont
contenues dans les activités.
Elle est représentée graphiquement : AAction
2. Connecteurs / transition / flot de contrôle : C’est un

contrôle de séquençage pendant l’exécution des
actions. Ce sont de simples flèches reliant deux
actions qui montre le passage du flot de contrôle :
UEF41 – 2016/2017
3. L’état initial : Il montre le point de départ de la
première action. Il n’y a qu’un seul état initial par
activité.
Il est représenté graphiquement par :
4. L’état final : Il montre le point d’arrivée de la dernière
action. Il peut y avoir plusieurs états finaux pour une
activité.
Il est représenté graphiquement par :
UEF41 – 2016/2017
UEF41 – 2016/2017
3.2.2 Exemple : Inscription aux universités
1. Etape 1: Annonce des résultats du bac : récupération
des documents de réussite,
2. Etape 2- Préinscription via Internet et remplissage de
la fiche de vœux
3. Etape 3: Confirmation de la préinscription, possibilité
de modifier la fiche de vœux
4. Etape 4: Affectations et recours en ligne
5. Etape 5: Inscription définitive auprès de
l'Etablissement
UEF41 – 2016/2017
3.2.2 Exemple : Inscription aux universités
UEF41 – 2016/2017
3.2.3 Autres éléments d’un DA :
1. Les Décisions (Branchement Conditionnels) et fusions :
Une décision est un nœud de contrôle représentant un
choix entre plusieurs conditions.
Il est représenté par un losange qui possède un arc
entrant et plusieurs arcs sortants. Le flot de contrôle
suit le chemin de la condition vérifiée.
La fusion est l’emplacement où tous les chemins
alternatifs vont se rencontrer.
UEF41 – 2016/2017
1. Les Décisions (Branchement Conditionnels) et fusion :
Exemple : une fois une

commande reçue,
si le stock est disponible
faire l’inventaire du reste,
sinon lancer un
approvisionnement
UEF41 – 2016/2017
2- Actions parallèles :
 En utilisant les nœuds « fork » et « join ».
 Le nœud « fork » montre les actions qui se dérouleront

en parallèle,
 Il ya lieu de savoir, qu’elles ne se terminent pas
nécessairement au même moment,
 Le nœud « join » est nécessaire, car le flot de contrôle ne
peut continuer que si toutes les actions parallèles ont
finies,
UEF41 – 2016/2017
2- Actions parallèles :
Exemple : après réception

d’une commande,
deux activité sont lancées
en parallèle, une pour
la vérification du paiement
et l’autre pour la préparation
(vérifier) du stock
UEF41 – 2016/2017
3- Les partitions :
 Permet de montrer le rôle organisationnel chargé de
l’exécution d’une ou plusieurs actions de l’activité,
 Une partition désigne généralement le rôle exécutant l’action
en cours,
 Les partitions rendent les DAs plus faciles à lire et plus
expressifs,
 Les partitions peuvent être représentées d’une manière
horizontale ou verticale,
 Un DA représenté avec des partitions ressemble au MOT de
MERISE
UEF41 – 2016/2017
3- Les partitions :
Exemple :
pour valider une
facture, le gestionnaire
lance la validation,
le magasinier prépare
le stock et enfin,
le comptable vérifie
le paiement
UEF41 – 2016/2017
3- Les Nœuds d’objet :
 Il est utilisé dans une transition entre deux actions,
 Il montre qu’une instance d’une classe (objet) est utilisée,
créée ou modifiée un emplacement précis de l’activité,
 Il permet aussi de représenter le flux de données durant
l’exécution de l’activité,
 Il est représenté graphiquement par un rectangle :
UEF41 – 2016/2017
3- Les Nœuds
d’objet :
Exemple : dans le génie-logiciel

la phase spécification produit
un cahier de charges et
La phase de développement
produit un prototype
UEF41 – 2016/2017
3- Les Nœuds d’objet :
 Peuvent être représentés par des « PINS » qui montrent l’objet
en entrée et en sortie d’une action :
UEF41 – 2016/2017
3.2 Diagramme d’activité - Exercice
Recette Mousse au chocolat :
UEF41 – 2016/2017
3.2 Diagramme d’activité - Exercice
Recette Mousse au chocolat :
UEF41 – 2016/2017
Bibliographie

P.Roques, F.Vallée, « UML2 en action, de l’analyse des besoins à la
conception J2EE », Eyrolles 2004
K.Hamilton et R.Miles, « Learning UML 2.0 », Editions O’reilly, 2006
www.uml.org
UEF41 – 2016/2017
Merci
N
Le Diagramme des cas d’utilisation UEF41 – 2016/2017
Génie Logiciel GL1

N
UEF41 – 2016/2017
Le Diagramme de séquence Première partie
Programme
2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique

3.3 La vue statique
UEF41 – 2016/2017
3.3 Diagramme de séquence
3.3.1 Introduction :
UEF41 – 2016/2017
 Le DS décrit les interactions entre les objets et les acteurs
du système d’u point de vue temporel ;
 Une interaction est un échange d’i fo atio s, appelé
message, entre les objets qui composent le système et/ou
entre le système et ses acteurs.
 Le DS a pour but de décrire un des différents scénarios
d’e écutio d’u cas d’utilisatio en montrant comment les
objets (au sens large : acteur, système, instance d’u e
classe…) collaborent au cours du temps et quelles
responsabilités ils assument (que font-ils comme
traitement)
UEF41 – 2016/2017
 Le DS élaboré durant la phase d’a al se est dit
« Diagramme de Séquence Système DSS » : pour
souligner le fait que le système en étude est considéré
comme une boîte noire dans le diagramme. Seuls les
échanges entre le système et tous ses acteurs sont
représentés en insistant sur la chronologie. La boite noire
sera ouverte en phase de conception où les objets qui
composent le système auront été identifiés et les
interactions entre eux seront représentées dans le
diagramme.
UEF41 – 2016/2017
Source : Pascal Roques & Franck Vallée, UML 2 en action,

De l’analyse des esoins à la on eption 4e édition, 2007
UEF41 – 2016/2017
3.3.2 Elément de base d’un DS :
1. Participant :
Tout objet participant à l’interaction
1. Ligne de vie :
Ligne de temps où sera représenté
les moments d’activité du participant
1. Message :
L’échange d’informations entre
participants
1. Fragment :
Notions avancés pour représentés
des diagrammes plus complexes
UEF41 – 2016/2017
1. Participant :
 Envoi, reçoit et traite des messages
 Peut être :
 Un objet (instance d’une classe)
 Une classe
 Un acteur principal ou secondaire
 Le système dans un DSS
UEF41 – 2016/2017
1. Participant
2. Ligne de vie :
 Est associée à chaque participant,
 Indique les périodes d’activité
de l’objet (le moment où le participant
exécute un traitement)
 peut être considérée comme
un axe temporel (le temps s’écoule
du haut vers le bas )
 La ligne de vie peut se terminer par
Ba de d’activatio
une croix lorsque l’objet est détruit
UEF41 – 2016/2017
1. Participant
2. Ligne de vie
3. Message :
 Représente une communication entre
deux lignes de vie,
 C’est à la réception d’u message que
la ligne de vie obtient son activation,
La réception d’u message est
considérée par le récepteur comme un
événement u’il faut traiter (ou pas)
 On distingue le message d’appel
Et le message de retour qui est le résultat direct du message
précédent,
UEF41 – 2016/2017
1. Participant
2. Ligne de vie
3. Message :
 Les types de messages :
-Un message synchrone est un
appel où l’é etteu se bloque
en attente de la réponse, sinon
le message est asynchrone
(on l’appel signal).
-Le message récursif représente un comportement interne important
que l’o veut montrer,
UEF41 – 2016/2017
1. Participant
2. Ligne de vie
3. Message :
 Les types de messages :
-La création d’u objet se fait
avec le message standardisé create
pointant vers le rectangle
en tête de la ligne de vie
et la destruction se fait avec le
message standardisé destroy
représenté par la croix sur la ligne
de vie
UEF41 – 2016/2017
3.3.3 Quelques compléments du DS :
1. Messages retours implicites et explicites :
 Le retour d’u appel de message synchrone peut ne pas être
représenté sur le diagramme, le retour est alors implicite,
 le retour d’u appel de message doit être explicite et doit figurer
sur le diagramme, sauf si, bien entendu, il ’est pas attendu un
retour.
1. Dédoublement de la bande d’activation :
Lorsque la ligne de vie d’u participant est activée, et que ce dernier
reçoit un message ou u’il s’e voie un message (exécuter un
traitement interne), on représente cela par un dédoublement de
la bande d’activatio .
UEF41 – 2016/2017
3.3.3 Quelques compléments du DS :
UEF41 – 2016/2017
Exercice :
Un représentant exclusif de produits médicaux a des difficultés à satisfaire les
commandes des clients à cause d’une grande affluence des clients dans ses locaux.
Pour améliorer ses processus, il demande à son service informatique de
développer un système de gestion des commandes en ligne.
Quand le client s’authentifie sur le site, il peut créer une nouvelle commande. Une
commande est constituée d’un entête et de plusieurs lignes. Le système calcule le
montant de la commande en calculant le prix des articles de chaque ligne, de leurs
quantités et éventuellement une remise dont pourrait bénéficier le client. Une fois
la commande créée, le client doit régler le montant. Il peut régler la commande
par virement bancaire ou par envoi de chèque. Une fois la commande payée, deux
services s’occupent de la traiter, le service de finances et le service de stock.
Le financier valide la commande puis génère une facture. Le gestionnaire de stock
prépare les articles commandés par le client. Si le stock est insuffisant, il crée alors
une commande de réapprovisionnement. Une fois la facture générée et les articles
préparés, le commercial envoie la facture au client et l’invite à se présenter pour
récupérer les articles qu’il a commandés. UEF41 – 2016/2017
Exercice :
Un représentant exclusif de produits médicaux a des difficultés à satisfaire les
commandes des clients à cause d’une grande affluence des clients dans ses locaux. Pour
améliorer ses processus, il demande à son service informatique de développer un
système de gestion des commandes en ligne.
quantités et éventuellement une remise dont pourrait bénéficier le client. Une fois la
commande créée, le client doit régler le montant. Il peut régler la commande par
virement bancaire ou par envoi de chèque. Une fois la commande payée, deux services
s’occupent de la traiter, le service de finances et le service de stock.
prépare les articles commandés par le client. Si le stock est insuffisant, il crée alors une
commande de réapprovisionnement. Une fois la facture générée et les articles préparés,
le commercial envoie la facture au client et l’invite à se présenter pour récupérer les
articles qu’il a commandés.
UEF41 – 2016/2017
Bibliographie

http://www.uml-sysml.org
UEF41 – 2016/2017
Merci
N
Le Diagramme de séquence Première partie UEF41 – 2016/2017
Génie Logiciel LG1

N
UEF41 – 2016/2017
Le Diagramme des classes
Programme
2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique

3.3 La vue statique
UEF41 – 2016/2017
3.2 Diagramme de classes
 Le diagramme de classes est au cœur d’un développement
orienté objet,
Il représente l’aspect statique de la réalité étudiée,
Il est utilisé d’abord dans la phase d’analyse où :
 il a pour objectif de décrire la structure des entités
manipulées par les utilisateurs, en identifiant les Classes
Candidates (appelées aussi Concepts)
 Il est ensuite affiné dans la phase de conception où :
 le diagramme de classes représente la structure d’un
code orienté objet : les classes sont détaillées
UEF41 – 2016/2017
3.2.2 Définition des concepts de base :
 Le diagramme de classes est constitué de classes, qui sont
reliées entre elles par des associations ou des
généralisations. Chaque classe contient des attributs et
des opérations,
Représentation graphique
d’un diagramme de classes :
UEF41 – 2016/2017
1. Une classe est un descripteur d’un ensemble d’objets qui
possèdent les mêmes caractéristiques et les mêmes
comportements. On peut parler également de type.
 Exemples : la classe Enseignant, la classe Module.
2. Un objet est une abstraction d'une entité de la réalité
étudiée, qui est décrit par un ensemble d’attributs et un
ensemble d'opérations.
 Exemples : les attributs (NomEnseignant,
GradeEnseignant, NomModule, VhoraireModule,…);
les opérations (Affecter(),Consulter(),AvancerGrade()…)
UEF41 – 2016/2017
 Un objet possède une frontière bien définie, une identité
et encapsule un état et un comportement. Un objet est
une instance (ou occurrence) d’une classe.
 Exemple : Nora TAIBOUNI est un objet instance de la
classe Enseignant. Le cours Génie Logiciel est une
instance de la classe Module.
L’état de l’objet est l’ensemble des valeurs de ses attributs
Le comportement de l’objet est représenté par les
opérations qu’il peut effectuer.
UEF41 – 2016/2017
 Notation :
 Quatre façons de représenter graphiquement une classe :
UEF41 – 2016/2017
 Notation classe :
UEF41 – 2016/2017
 Notation :
 Utiliser la convention UpperCamelCase. Le nom de classe
est en minuscules et la première lettre en majuscules. Si le
nom de la classe est composite, le nom de chaque mot
composant est en minuscule et la première lettre en
majuscule. Par exemple : Agent, Compte, LigneFacture,
MandatPostalValide.
 Eviter les abbréviations : par exemple utiliser
FactureValideDetaillee au lieu de FactureVD.
 La visibilité s’applique aussi bien aux attributs qu’aux
opérations. Elle n’est pas importante durant la phase
analyse.
UEF41 – 2016/2017
 Notation :
Visibilité Nom Description
+ publique Accès depuis la même classe et à
l’extérieur de la classe
- privée Accès depuis la même classe
uniquement
# protégée Accès depuis la même classe et les
classes descendantes
~ paquet Accès depuis la même classe et toutes
les classes appartenant au même
paquet
UEF41 – 2016/2017
3. Une association représente une relation sémantique
entre deux classes. Elle se traduit par un lien entre deux
instances de ces classes.
 Exemple : Un enseignant peut enseigner plusieurs
modules. La relation « enseigner » est une association
entre la classe Enseignant et la classe Module.
 L’association est par défaut bidirectionnelle, elle se lit
dans les deux sens : un module est enseigné par un
enseignant.
UEF41 – 2016/2017
 La multiplicité spécifie le nombre d’objets qui peuvent
participer à l’association. Elle est représentée aux deux
extrémités de l’association.
Multiplicité
UEF41 – 2016/2017
 Les cas de multiplicité :
Multiplicité Signification
0..1 Zéro ou 1
1 Exactement 1
0..* Zéro ou plusieurs
* Zéro ou plusieurs
1..* 1 ou plusieurs
1..9 1 à 9 (intervalle)
9 Exactement 9
UEF41 – 2016/2017
 Lecture de l’association avec la multiplicité :
Une voiture possède exactement 4 pneus
Voiture Pneu
1 4
Un pneu appartient à exactement une voiture
UEF41 – 2016/2017
 Lecture de l’association avec la multiplicité :
Une société peut avoir 0, 1 ou plusieurs employés
Société Employe
1 *
Un employé est employé par exactement 1 société
UEF41 – 2016/2017
3.2.2 Définition des concepts de base : Exemple
Un représentant exclusif de produits médicaux a des difficultés à satisfaire les commandes
des clients à cause d’une grande affluence des clients dans ses locaux. Pour améliorer ses
processus, il demande à son service informatique de développer un système de gestion
des commandes en ligne.
commande est constituée d’un entête et de plusieurs lignes. Le système calcule le montant
de la commande en calculant le prix des articles de chaque ligne, de leurs quantités et
éventuellement une remise dont pourrait bénéficier le client. Une fois la commande créée,
le client doit régler le montant. Il peut régler la commande par virement bancaire ou par
envoi de chèque. Une fois la commande payée, deux services s’occupent de la traiter, le
service de finances et le service de stock.
commande de réapprovisionnement. Une fois la facture générée et les articles préparés, le
commercial envoie la facture au client et l’invite à se présenter pour récupérer les articles
qu’il a commandés.
UEF41 – 2016/2017
3.2.2 Définition des concepts de base : Exemple
processus, il demande à son service informatique de développer un système de gestion des
commandes en ligne.
quantités et éventuellement une remise dont pourrait bénéficier le client. Une fois la
commande créée, le client doit régler le montant. Il peut régler la commande par virement
bancaire ou par envoi de chèque. Une fois la commande payée, deux services s’occupent de
la traiter, le service de finances et le service de stock.
Le financier valide la commande puis génère une facture. Le gestionnaire de stock prépare
les articles commandés par le client. Si le stock est insuffisant, il crée alors une commande
de réapprovisionnement. Une fois la facture générée et les articles préparés, le commercial
envoie la facture au client et l’invite à se présenter pour récupérer les articles qu’il a
commandés.
UEF41 – 2016/2017
«entity»
«entity» Produit
Facture
- prix :double
- date :Date - quantite :double
1 1 1..*
- montant :double
«entity»
0..*
Ligne
1..* - prix :double
- quantite :double
- remise :double
1..*
1
1
«actor»
Client «entity»
Commande
1 0..* - date :Date

- montant :double
1 «entity»
Entête
1
0..*
«entity»
ModeReglement
«entity»
Virement
«entity»
Cheque
UEF41 – 2016/2017
 Les types d’association :
1. La dépendance :
 La relation de dépendance entre deux classes signifie que les
objets d’une classe utilisent les objets de l’autre classe.
 Cette relation est généralement utilisée en phase d’analyse

pour montrer les relations entre les classes qui représentent
les objets métiers et celles qui représentent le système
(interface, contrôle…)
UEF41 – 2016/2017
2. L’agrégation :
 C’est une association particulière qui exprime une relation de
contenance. Elle n’a pas besoin d’être nommée, elle signifie
implicitement « est composé de » ou « contient ».
0..*
Commande Produit
1..*
UEF41 – 2016/2017
1. La composition :
 C’est une agrégation forte. Un élément ne peut appartenir
qu’à un seul agrégat composite.
 La destruction de l’agrégat composite entraîne la destruction
de tous ses éléments.
1
Commande LigneCommande
1..*
UEF41 – 2016/2017
1. L’héritage :
 C’est une relation de généralisation entre une super-classe (classe
plus générale) et une ou plusieurs autres classes plus spécialisées
(sous-classes). Les sous-classes « héritent » des propriétés et
comportement de leur super-classe et peuvent comporter des
propriétés et comportements spécifiques supplémentaires.
 Parfois une classe ne peut exister que par l’existence des classes
descendantes. Elle n’a pas d’existence propre : c’est la classe
abstraite :
 Elle ne s’instancie pas, son nom est noté en italique pour la
différencier. Exemple : MoyenDeTransport.
UEF41 – 2016/2017
3.2.3 Autres concepts :
1. L’attribut dérivé :
 C’est un attribut dont la valeur peut s’obtenir d’autres
informations disponibles dans le modèle (de la même classe,
ou de classes en association).
 Il est considéré comme redondant, mais comme il est
important pour les utilisateurs, alors il est représenté sur le
modèle avec un « / » qui précède le nom de l’attribut.
Exemple : /age, /montantFacture,
UEF41 – 2016/2017
1. Les contraintes :
 C’est une condition entre éléments du modèle qui doit être
vérifiée par les éléments concernés,
 Elle est notée entre accolades {} et peut être insérée au besoin
dans une note graphique,
 La contrainte prédéfinie {ordered} ajoute, dans une
association, une précision sur une multiplicité supérieure à 1.
Cette précision est la notion de séquence des objets de la
classe concernée.
 UML définit plusieurs contraintes prédéfinies (frozen, xor,…)
UEF41 – 2016/2017
1. Les contraintes :
Commande
DateCommande
Client 1..* ModePaiement
FraisLivraison
CodeClient /MontantProduit
{ordered}
NomClient /MontantTotal
PrenomClient 1 {Montant total =
MontantProduit
+FraisLivraison}
UEF41 – 2016/2017
1. La classe d’association :
 Lorsque l’association entre deux classes est porteuse
d’attributs (les attributs ne peuvent être dans aucune des
classes), alors elle devient une classe. Elle possède les
caractéristiques d’une association et celles d’une classe.
Etudiant Module
* *
Note
+ valeur: double
UEF41 – 2016/2017
3.3 Diagramme d’objets
3.3.1 Définition et utilité :
 Il permet de présenter l’interaction entre les objets à un instant
donné (les objets et leurs relations) : C’est une instance du
diagramme de classe,
 Il est composé :
 d’objets (instances de classes),
 de liens (instances d’associations).

gl1 : Module
taibouni:Enseigant
si : Module
UEF41 – 2016/2017
3.3 Diagramme d’objets
 Le diagramme d’objet est utile pour :
 donner des exemples sur des situations complexes mettant
en relation plusieurs concepts (structure d’objet complexe)
 Montrer l’état du système avant ou après une interaction
particulière.
 Les diagrammes d’objet sont facultatifs et souvent les
diagrammes de classes sont suffisants pour décrire le domaine.
UEF41 – 2016/2017
3.4 Diagramme de paquet (Package)
 Mécanisme général de regroupement et d’organisation des
éléments en UML,
 Un paquet UML peut contenir plusieurs éléments UML dont
éventuellement d’autres paquets (cas d’utilisation, classes),
 Chaque élément UML appartient à exactement un paquet
Paquet
UEF41 – 2016/2017
3.4 Diagramme de paquet (Package)
 Le paquet définit une frontière où les noms des éléments
doivent être uniques,
 Les relations entre paquets sont des relations de dépendances
: Un paquet P1 dépend de P2 si un élément de P1 utilise d’une
manière ou d’une autre un élément de P2.
UEF41 – 2016/2017
3.2.3 Autres types de classes :
 Les premières classes importantes à identifier sont celles des
entités qui relèvent du domaine étudié (classes « entity »),
 I. Jacobson a proposé d’autres types afin de compléter
l’analyse du système à développer :
 Les classes « boundary » qui permettent de représenter la
limite du système qui s’interface avec l’utilisateur, ou bien
les interactions entre le système et ses utilisateurs comme
par exemple : les formulaires de saisie, les résultats de
recherche, etc.
 Ces classes sont identifiées de l’analyse de la maquette du
système (Il y a au moins un dialogue pour chaque paire
acteur-cas d’utilisation).
UEF41 – 2016/2017
3.2.3 Autres types de classes :
 Les classes de type « control » qui représentent un contrôleur.
Un contrôleur est un intermédiaire entre les limites (interfaces)
et les entités (classes d’objets métiers). Le contrôleur se charge
de l’exécution des commandes provenant de la limite.
 Les classes de type « actor » qui représentent les différents
acteurs (utilisateurs) du système
Utilisateur
UEF41 – 2016/2017
Exemple commander en ligne :
Commande LigneCommande Produit Client
GestionnaireCommandes
InterfaceWeb
N. Taibouni, n_taibouni@esi.dz Utilisateur

UEF41 – 2016/2017
Bibliographie

www.uml.org
UEF41 – 2016/2017
Merci
N
Génie Logiciel LG1

N
UEF41 – 2016/2017
Le Diagramme d’états-transitions
Programme
2. Chapitre 2 : UML
2.1 Introduction
2.2 Historique

3.3 La vue statique
UEF41 – 2016/2017
3.7 Diagramme d’états-transitions (State Machine Diagram)
 L’un des diagrammes comportementaux d’UML;
 Ce diagramme est une reprise du concept « machine à
états finis » ou « automate à états finis »,
 Permet de représenter le cycle de vie d’un objet (instance
d’une classe) :
 les différents états par lesquels passent un objet durant
son existence, ainsi que la façon avec laquelle l’objet
passe d’un état à un autre (les évènements qui
provoquent ces changements d’états et leurs effets).
UEF41 – 2016/2017
 Un diagramme d’états-transition correspond à une et une
seule classe;
 Toutes les classes ne nécessitent pas un diagramme d’état,
il ya lieu de chercher celle qui possèdent un comportement
dynamique complexe tel que :
➢ Les objets de la classe réagissent différemment à un même
événement (chaque réaction caractérise un état particulier de
l’objet : le calcul de l’IRG sera différent pour les salariés dans le cas
d’une augmentation de salaire )
➢ Le comportement des objets a un impact sur le comportement
d’autres parties du système ( la création de la facture intervient
après validation de la commande )
UEF41 – 2016/2017
3.7.2 Concepts de base :
 Etat initial :
Correspond à la création
de l’instance
Etat :
Situation de l’objet
À un instant T
Transition :
Décrit la réaction d’un objet à un évènement,
elle possède un événement déclencheur,
une condition de garde, un effet et un état cible.
Etat final : Correspond à la destruction de l’instance
UEF41 – 2016/2017
Signification et lecture du diagramme :
Les objets de la classes sont à « l’état 1 »:

- Ils vont y rester tan que l’évènement ne s’est pas produit,
- Si l’évènement se produit et la condition est vérifiée, alors
les objets passent à l’état « état 2 » après exécution de l’effet.
UEF41 – 2016/2017
L’état
UEF41 – 2016/2017
L’état d’un objet :
➢ représente une période dans la vie d'un objet (un moment
de son cycle de vie), qui satisfait une certaine condition;
➢ Durant cet état, l’objet peut être :
✓ Inactif : il attend un évènement, un signal d’autre objet;
✓ Actif : il réalise une activité (exécution d'une série de
méthodes et d'interactions avec d'autres objets)
➢ L’objet peut avoir plusieurs états finaux, comme il peut ne
pas en avoir (il n’est pas détruit)
➢ L’état de l’objet n’est pas représenté sur le diagramme de
classes en phase de conception. Mais en phase de
conception, les différents états identifiés seront des valeurs
d’un
N. Taibouni, attribut « Statut » à ajouter dans la classe
n_taibouni@esi.dz de l’objet.
UEF41 – 2016/2017
La transition
UEF41 – 2016/2017
La transition :
➢ Représente la réponse d'un objet à l'arrivée d'un événement,
➢ Elle indique qu'un objet peut passer « transiter » vers un état
cible. Durant ce passage, l’objet peut éventuellement
exécuter certaines activités, si un événement déclencheur se
produit et qu'une condition de garde est vérifiée.
➢ C’est à la fin d’exécution des activités (l’effet), que l’objet
devient à l’état cible.
➢ Ce type de transition est appelé transition externe.
UEF41 – 2016/2017
L’évènement
UEF41 – 2016/2017
L’évènement :
➢ C’est un fait qui déclenche le changement d'état de l’objet,
➢ Il existe 4 types d’évènements :
✓ Evènement Signal : c’est un message asynchrone provenant d’un
autre objet ou d’un acteur (programmation évènementielle)
✓ Evènement Appel d’opération : c’est un appel d’une méthode de

l’objet, il est généralement synchrone;
❖ Syntaxe des deux premiers évènements : nom_évènement, ou

nom_évènement(paramètres).
UEF41 – 2016/2017
L’évènement :
✓ Evènement de changement : lorsque les valeurs de certains
attributs de l’objet vérifient à vrai ou faux une certaine expression
booléenne. L’expression est testée en permanence.
❖ Syntaxe : when (expression booléenne)
✓ Evènement temporel : représente l’écoulement du temps, une

durée. Le temps commence à s'écouler dès l'entrée dans l'état
courant.
❖ Syntaxe : after (durée)
UEF41 – 2016/2017
La condition de garde
C’est une expression booléenne qui doit être vraie lorsque
l’événement arrive pour que la transition soit déclenchée. Elle
peut concerner les attributs de l’objet ainsi que les paramètres
de l’événement déclencheur.
UEF41 – 2016/2017
L’effet, activité ou action
UEF41 – 2016/2017
L’effet ou Activité ou action :
➢ C’est le traitement optionnel réalisé par l’objet lorsque la
transition est déclenchée (en UML 2.0 il est appelé effet), il
ne doit pas être interrompu;
➢ Il peut être une simple action élémentaire ou une activité
(séquence d’actions élémentaires) :
✓ Une action élémentaire est un traitement atomique ne
pouvant être interrompue; (mise à jour d’un attribut, un appel
d’opération, la création ou la destruction d’un autre objet, ainsi que
l’envoi d’un signal à un autre objet)
✓ Une activité est un ensemble d’actions élémentaires,
UEF41 – 2016/2017
3.7.3 Concepts avancés :
 Transition interne :
➢ Dans certaines situations, le passage d’un état initial à un état
cible peut entrainer, en plus de l’effet de la transition,
l’exécution d’actions ou activités successives ou parallèles par
l’objet. On parle de transition interne sans changement d’état
de l’objet.
➢ La syntaxe d’une transition interne est la même que la
transition externe : évènement [condition]/effet;
➢ Les transitions internes s’écrivent à l’intérieur de l’état, séparé
du nom de l’état par un trait.
UEF41 – 2016/2017
 Transition interne :
➢ UML définit des mots clé correspondant à des événements
particuliers :
❖ entry : définit le traitement à exécuter lors de l’entrée
dans l’état,
❖ exit : définit le traitement à exécuter lors de la sortie de
l’état,
❖ do : définit le traitement à exécuter pendant la durée de
l’état,
❖ on : (optionnel) définit le traitement à exécuter à chaque
fois qu’il un événement particulier interne.
UEF41 – 2016/2017
 Transition réflexive :
➢ UML autorise la transition réflexive qui fait sortir l’objet de
son état puis le retourner à cet état, et ce suite à la
survenance d’un évènement sous éventuellement une
condition et devant exécuter un traitement.
UEF41 – 2016/2017
3.7.4 Exemples : (source http://remy-manu.no-ip.biz)
UEF41 – 2016/2017
3.7.4 Exemples : le cas de l’antivirus
Quand un élément est analysé, l’antivirus le met dans l’état en

analyse. S’il trouve une menace confirmée dans l’élément, il le
met en quarantaine. Si l’antivirus trouve une menace non
confirmée, il envoie la signature de la menace au service web de
la compagnie et marque l’élément comme suspect. Le serveur
web analyse la menace puis redonne son analyse à l’antivirus. Si
l’élément est infecté, le fichier est mis en quarantaine sinon il est
remis à l’état normal.
UEF41 – 2016/2017
3.7.4 Exemples : le cas de l’antivirus
Quand un élément est analysé, l’antivirus le met dans l’état en

analyse. S’il trouve une menace confirmée dans l’élément, il le
met en quarantaine. Si l’antivirus trouve une menace non
confirmée, il envoie la signature de la menace au service web de
la compagnie et marque l’élément comme suspect. Le serveur
web analyse la menace puis redonne son analyse à l’antivirus. Si
l’élément est infecté, le fichier est mis en quarantaine sinon il
est remis à l’état normal.
UEF41 – 2016/2017
3.7.4 Exemple : Gestion Commandes
commandes en ligne.
Le financier valide la commande puis génère une facture. Le gestionnaire de stock prépare
les articles commandés par le client. Si le stock est insuffisant, il crée alors une commande
de réapprovisionnement. Une fois la facture générée et les articles préparés, le commercial
envoie la facture au client et l’invite à se présenter pour récupérer les articles qu’il a
commandés.
UEF41 – 2016/2017
3.7.4 Exemple : Gestion Commandes
commandes en ligne.
commande de réapprovisionnement. Une fois la facture générée et les articles préparés, le
commercial envoie la facture au client et l’invite à se présenter pour récupérer les articles
qu’il a commandés.
UEF41 – 2016/2017
Bibliographie

www.uml.org
UEF41 – 2016/2017
Merci
N

Cours2 Génie Logiciel 1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours2 Génie Logiciel 1

Transféré par

Droits d'auteur :

Formats disponibles

Faculté des Sciences - Département MI

2ème année Licence Ingénierie S.I. et Génie Logiciel

Génie Logiciel LG1

Chapitre 1 – Section 1 : Le Génie Logiciel - Introduction UEF41 – 2016/2017

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

Tout simplement un logiciel est

Matières premières décisions

Finance Gestion Tech. Maintenance Facture

 En 1983, toute la vallée du Colorado a été inondée. La

Comme tout projet,

Chapitre 1 – Section 1 : Le Génie Logiciel - Introduction UEF41 – 2016/2017

Génie Logiciel LG1

Chapitre 1 – Section 1 : Le Génie Logiciel - Introduction UEF41 – 2016/2017

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

N. Taibouni, n_taibouni@esi.dz UEF41 – 2016/2017

Le premier rapport : 1994.

Analyse et spécification des besoins

Test et validation du logiciel

Définition des besoins

Tests unitaires Intégration

Tests d ’intégration Implémentation

Conception du système Test du système

Conception du système Analyse des besoins

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

Objets d’entreprise Relations entre les objets

Concevoir une partie du logiciel

Ce que fait l’entreprise en termes de taches à exécuter

La fonctionnalité de l’entreprise Le comportement de l’entreprise

Entrée (I) Sortie (O)

Enchainement logique d’activités

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

Chapitre 1 – Section 1 : Le Génie Logiciel - Introduction UEF41 – 2016/2017

Génie Logiciel LG1

Chapitre 2 – UML UEF41 – 2016/2017

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

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

 UML est un langage pour visualiser, spécifier, construire et

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

 L'approche est faites par des diagrammes

 Points forts d’UML :

 Points faibles d’UML :

MA.Mostefai, S.Batata, “Support de cours GL de l’ESI », 2012

P. Roques, « UML 2 par la pratique. N°12322, 6e édition », 2008,

P.Roques, « les Cahiers du Programmeur UML2, Modéliser une

Jacques Guyot, « CONCEPTION & REALISATION DES BASES DE

Chapitre 2 – UML UEF41 – 2016/2017

Génie Logiciel LG1

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

 C'est pour des acteurs que le système est construit, sans

 Une personne peut être plusieurs acteurs pour le système

 On utilise aussi les acteurs pour modéliser des systèmes

 Il faut décrire les acteurs en fonctions des fonctionnalités

 Il est préférable d’utiliser la forme graphique du « stick man »

 Dans l’exemple précédent, l’acteur Internaute est la

cas Inscription d’un élève

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

Réserver une Réserver un billet

MA.Mostefai, S.Batata, “Support de cours GL de l’ESI », 2012

P. Roques, « UML 2 par la pratique. N°12322, 6e édition », 2008,

P.Roques, « les Cahiers du Programmeur UML2, Modéliser une

Jacques Guyot, « CONCEPTION & REALISATION DES BASES DE

Génie Logiciel LG1

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

Les diagrammes d’activité sont très utilisés dans la phase