Vous êtes sur la page 1sur 80

Génie logiciel Orienté objet

Pr. Hiba Chougrad


Année-universitaire: 2019-2020

1
Planning
Cours Génie Logiciel Orienté Objet:
• Mardi matin
• Cours + TD

La note :
• TD et devoirs libres
• Contrôle continu le 05/11
• Examen final

2
3

Plan
1. Introduction générale
2. Diagramme de cas d’utilisation
3. Diagrammes de classes
4. Diagrammes de packages et objets
5. Diagrammes de séquences
6. Diagrammes d’états et Transitions
7. Diagrammes d’activités
8. Diagrammes de composant et de déploiement
4

Introduction générale
5

Introduction
• L’informatisation est le phénomène le plus important de notre époque.
• Actuellement, l’informatique est au cœur de la vie quotidienne des individus,
entreprises, organisations, gouvernements, ….
• Les Systèmes Informatiques se composent de :
• 80 % de logiciel,
• 20 % de matériel.
• Depuis quelques années, la fabrication du matériel est assurée par quelques
fabricants seulement.
• Le matériel est relativement fiable.
• Le marché est standardisé.
6

Introduction
• Les problèmes liés à l'informatique sont essentiellement des problèmes de logiciel.

• Construction d’applications

Besoin code

• Simplification à l’extrême:
On peut dire que la construction d’une application informatique se résume à réaliser
du code pour répondre au besoin d’un utilisateur.
7

Introduction
• Exemple de LaTex, qui a été conçu pour permettre à ses utilisateurs d’écrire
des livres, des articles….

Avoir un logiciel
pour écrire un livre LaTex
ou un article

• Cette simplification peut être considérée comme une simplification brute.


• La réalisation du code n’est pas la seule activité à effectuer lorsque nous
souhaitons construire un logiciel de qualité.
8

Logiciel: Définition
• Un logiciel ou une application:
• Est un ensemble de programmes,
• Qui permet à un ordinateur d’assurer une tâche ou une fonction bien précise.
Exemples : Word office, Paint, Media Player ,…

• Les logiciels, suivant leur taille, peuvent être développés par:


• Une personne seule,
• Une petite équipe,
• Un ensemble d’équipes coordonnées.
9

Le talon d’Achille du Logiciel

• Le coût
• Le temps
• La qualité
10

Les critères de qualité du logiciel


• Validité : Conformité d'un logiciel avec sa spécification
• Robustesse : Capacité à fonctionner même dans des conditions anormales
• Extensibilité : Facilité d'adaptation à des changements de spécifications
• Réutilisabilité : Capacité à être réutilisé en tout ou partie dans une nouvelle
application
• Compatibilité : Facilité avec laquelle des composants logiciels peuvent être
combinés
• Efficacité : Utilisation optimale des ressources matérielles
• Portabilité : Facilité de transfert dans différents environnements
• Vérifiabilité : Facilité à valider ; bien structuré et modulaire
• Intégrité : Aptitude à protéger les codes et les données
• Facilité d'utilisation : Ergonomie, Facilité d'apprentissage, bien documenté
11

Crise du logiciel

Constats du développement logiciel fin années 60 :

 délais de livraison non respectés


 budgets non respectés
 ne répond pas aux besoins de l'utilisateur ou du client
 difficile à utiliser, maintenir, et faire évoluer
12

Crise du logiciel
Étude du Department of Defense des États-Unis en 1995 sur les logiciels
produits dans le cadre de 9 gros projets militaires
13

Crise du logiciel
Étude du Standish group
Enquête sur des milliers de projets,
de toutes tailles et de tous secteurs

• Projets réussis : livré à temps, sans dépassement de budget, accompagné de toutes


les fonctionnalités initialement spécifiées.
• Projets mitigés : livré et opérationnel, mais avec moins de fonctionnalités que prévu et
un dépassement de budget et/ou de temps.
• Projets ratés : abandonnés avant la fin ou livrés mais jamais utilisés
14

Crise du logiciel
• La crise de l’industrie du logiciel était principalement due à :
• La spécification non correcte des besoins,
• Les difficultés de maintenance et d’évolution,
• La non fiabilité,
• Le non respect des délais,
• L’augmentation des coûts,
• ….

 une nouvelle discipline est née : le génie logiciel.


15

Génie logiciel
• Le génie logiciel est un domaine de recherche qui a été défini en 1968 à
Garmisch (Allemagne) « 1st conference on software engineering ».

• Il essai de réponde au questions suivantes:


• Qu'attend-on d'un logiciel ?
• Comment construire des logiciels de qualité ?
• Quels sont les méthodes utilisés pour la construction?
• Etc.
16

Génie logiciel
Définition :
• Ensemble des méthodes, des techniques et des outils dédiés à la conception, au
développement et à la maintenance des systèmes informatiques.

Objectif :
Avoir des procédures systématiques pour des logiciels de grande taille afin que :
• la spécification corresponde aux besoins réels du client
• le logiciel respecte sa spécification
• les délais et les coûts alloués à la réalisation soient respectés
17

Génie logiciel
À part le code on a besoin de considérer plusieurs activités, Parmi elles :

1. S’assurer d’avoir bien compris le besoin de l’utilisateur afin de réaliser une application
satisfaisante.
2. S’assurer d’avoir réalisé un code facilement modifiable, permettant de prendre en
compte des évolutions futures.
3. Définir l’architecture de l’application (définition de ses différents composants,
indépendamment du langage de programmation) pour bien comprendre les relations
entre les composants de l’application.
4. Planifier et réaliser des tests afin de mesurer la qualité du code.
18

Génie logiciel
5. Effectuer un suivi des besoins de l’utilisateur afin d’intégrer des améliorations.
6. Effectuer des corrections de bogues.
7. Écrire la documentation pour l’utilisateur(help), la documentation d’installation de
l’application et la documentation de l’application afin qu’une autre équipe de
développeurs puisse reprendre le développement.
8. Effectuer une séparation des tâches de développement afin de raccourcir les délais de
livraison de l’application.
9. De plus, il faut noter que certaines activités dépendent d’autres. Alors, il faut
impérativement effectuer une activité avant d’en démarrer une autre: Planification
(Gestion de projet).
19

Génie logiciel
 La construction d’un logiciel est complexe quand elle met en œuvre de nombreuses
ressources : humaines ; matérielles et technologiques.

 D’où la nécessité de suivre un processus bien défini => le cycle de vie d’un logiciel
• prévoir et planifier les travaux ;
• coordonner les activités de conception, de fabrication, de validation, …
• réagir à l’évolution des objectifs.

 Une méthode rigoureuse basée sur des Modèles:


• représentations sémantiques d’un système de façon simplifiées mais juste visant à
l’analyser et le comprendre pour mieux le concevoir.
20

Cycle de vie
• Un projet de réalisation d'un système d’information est composé d'étapes.

• Le découpage d'un projet en étapes et l'organisation de ces étapes varie selon


le modèle utilisé.

• On appelle cycle de vie d'un logiciel l'ensemble des étapes à suivre lors de la
création du logiciel ainsi que leur enchainement.
21

Les étapes du cycle de vie


L’expression des besoins : élaboration par le client et le fournisseur d’un cahier des charges décrivant :
Client /
Fournisseur  les fonctionnalités du système étudié ;
 comment utiliser ce système ;

Utilisateurs, les spécifications du système : lever les ambiguïtés, éliminer les redondances du cahier des charges ;
Experts / l’analyse : phase indépendante du toute considération technique et informatique visant à définir le
Fournisseur système (s’accorder sur le « quoi ») ;

la conception : prise en compte de l’environnement technique pour déterminer la manière de résoudre le


Experts problème posé (s’accorder sur le « comment ») ;
Informatiques l’implémentation : traduction de la conception dans un langage de programmation, en une base de
données, ...

Experts les tests : vérification que l’implémentation est correcte ;


Informatiques

Utilisateurs,
Experts / la validation : vérification que le système correspond aux besoins ;
Fournisseur

la maintenance et l’évolution pendant la phase d’exploitation.


22

Les étapes du cycle de vie


 Un cycle de vie suivant un modèle objet se caractérise par :
• une bonne traçabilité : les même concepts servent, depuis l’analyse jusqu’à
l’implémentation (par exemple les classes implémentées sont découvertes pendant la
phase d’analyse) ;
• un caractère itératif :

• un caractère incrémental : une série de prototypes (sous-ensemble logiciel intégrable,


réutilisable et évolutif) évoluent jusqu’à la version finale.
23

Cycle de vie d’un logiciel


• Étapes nécessaires à la réalisation d’un logiciel:

1. Expression des besoins et spécifications:

• Mise du logiciel dans son contexte: type de produit, nouveau/altéré,…etc


• Etude de l’existant:
• Etude des produits similaires dans le marché (national et international)
• Critiquer les produits concurrents (points positifs et négatifs)
• Etude du processus/logiciels existants à l’entreprise
• Comment fonctionnait l’entreprise avant le produit à créer?
La description du fonctionnement du processus de l’entreprise peut aider à la conception du produit
24

Cycle de vie d’un logiciel


• Étapes nécessaires à la réalisation d’un logiciel:
1. Expression des besoins et spécifications:
• Description des besoins et conditions qui doivent être respectées
• Besoins fonctionnels : les fonctionnalités que le produit doit automatiser
• Exemple: lister les produits, calculer le panier, trier, etc
• Besoins non fonctionnels:
• Besoins de performance ( disponibilité, rapidité de calcul, rapidité de réponse, taille en mémoire, sécurité,
ergonomie,..)
• Besoins logiciels : si l’entreprise exige l’utilisation d’un outil logiciel.
• Le cahier de charge
• Dans les grands projets, le cahier de charges est signé.

Cette phase est difficile car le client et les informaticiens(développeurs, analystes,


concepteurs, etc) ne parlent pas le même langage.
25
26

Cycle de vie d’un logiciel


• Étapes nécessaires à la réalisation d’un logiciel:
2. L’analyse:
• Elle a pour but de dégager le problème à étudier.
• Le résultat de l'analyse est le cahier de charges (exprimé dans une langue naturelle) contenant les
besoins du futur système.
• 3 phases: Faisabilité, Spécifications des besoins, Organisation du projet.
3. Conception:
• Permet de fournir une description fonctionnelle du système en utilisant une méthode.
• Les méthodes proposent des formalismes (dans la plupart des temps graphiques) pour concevoir le
système.
• Deux types de conception : Conception générale et Conception détaillée.
27

Cycle de vie d’un logiciel


• Étapes nécessaires à la réalisation d’un logiciel:
4. Implémentation:
• Des programmes seront élaborés afin de mettre en œuvre des solutions techniques précédemment
retenues.
• Plusieurs types langages sont utilisés: Langages classiques (C, Pascal, …) et langages orientés
objets (C++, Java, C#, …).
5. Tests :
• Essayer le logiciel sur des données d'exemple pour s'assurer qu'il fonctionne correctement.
• Différentes types: Test unitaire, d’intégration, test système, alpha, bêta, …
28

Cycle de vie d’un logiciel


Étapes nécessaires à la réalisation d’un logiciel:
6. Validation:
• assurer que les besoins du client sont satisfaits (au niveau de la spécification, du produit fini…).
• assurer que le logiciel satisfait sa spécification
7. Maintenance:
• Mettre à jour et améliorer le logiciel.
• Maintenance Corrective, Adaptative et Évolutive.
8. Documentation:
• Cahier des charges, Modèle Objet, Scénarios des cas d’utilisation, Calendrier du projet, Plan de
test, Manuel d’utilisateur, Code source, Rapport des tests, Rapport des défauts…
29

Types de cycle de vie


• Développement en cascade:
• Chaque étape ne débute que lorsque la précédente est achevée.

• Développement en V:
• Chaque étape correspond à une étape de test spécifique.
• Les tests peuvent être définis avant les phases de test.

• Cycle de vie en spirale:


• Ce modèle est beaucoup plus général que le précédent.
• Il met l’accent sur l’activité d’analyse des risques.
30

Types de cycle de vie


• Développement en cascade:
• Chaque étape ne débute que lorsque la précédente est achevée.
31

Types de cycle de vie


• Développement en cascade:
• Chaque étape ne débute que lorsque la précédente est achevée.

• Développement en V:
• Chaque étape correspond à une étape de test spécifique.
• Les tests peuvent être définis avant les phases de test.

• Cycle de vie en spirale:


• Ce modèle est beaucoup plus général que le précédent.
• Il met l’accent sur l’activité d’analyse des risques.
32

Types de cycle de vie


• Développement en V:
• Chaque étape correspond à une étape de test spécifique.
• Les tests peuvent être définis avant les phases de test.
33

Types de cycle de vie


• Développement en cascade:
• Chaque étape ne débute que lorsque la précédente est achevée.

• Développement en V:
• Chaque étape correspond à une étape de test spécifique.
• Les tests peuvent être définis avant les phases de test.

• Cycle de vie en spirale:


• Ce modèle est beaucoup plus général que le précédent.
• Il met l’accent sur l’activité d’analyse des risques.
34

Types de cycle de vie


• Cycle de vie en spirale:
• Ce modèle est beaucoup plus général que le précédent.
• Il met l’accent sur l’activité d’analyse des risques.
35

Pourquoi modéliser ?
• Modéliser un système avant sa réalisation permet:
• De mieux comprendre le fonctionnement du système.
• De maîtriser la complexité et d’assurer la cohérence.
• C’est un langage commun, précis, qui est connu par tous les membres de l’équipe : facilité
la communication.

• Remarque:
• Cette communication est essentielle pour aboutir à une compréhension commune et
précise d’un problème donné par les différentes parties prenantes.
36

Pourquoi modéliser ?
• Dans le domaine de l’ingénierie du logiciel:

• Le modèle permet de mieux répartir les tâches et d’automatiser certaines d’entre elles.
• C’est un facteur de réduction des coûts et des délais.
• Le modèle est indispensable pour assurer un bon niveau de qualité et une maintenance
efficace.
• Le choix du modèle a une influence capitale sur les solutions obtenues.
37

Qui doit modéliser ?


• Deux acteurs principale dans le domaine du génie logiciel:
• Maîtrise d'ouvrage (MOA) : Le client du projet (mais pas forcément l'utilisateur),
• Maîtrise d’œuvre (MOE) : L'organe réalisateur du projet, représenté par le chef de projet.

• La modélisation est souvent faite par la maîtrise d’œuvre informatique (MOE).

• La relation MOA et MOE est définie par un contrat qui précise leurs
engagements mutuels.

• Le MOE est responsable de la qualité technique de la solution.


38

Modélisation des SI

• Généralement, on distingue 2 approches :


− Approches fonctionnelles,
− Approches objet,
39

Modélisation des SI
• Approches fonctionnelles :
− Proposée, développée et utilisée jusqu’à 1970,
− Mettent l’accès sur les traitements,
− Ce type approches fait la distinction entre les données et les traitements,
− Exemple de Merise (MCD, MCT, ..),

• Approches objet :
• Dès 1980,
• Mettent l’accès sur le concept de l’objet,
• Chaque objet est caractérisé par des données et des traitements,
• Exemple de UML.
40

Modélisation des SI
1) Méthodes fonctionnelles

• Généralement, qualifiées de méthodes structurées.


• Trouvent leurs origines dans les langages procéduraux.
• Elles mettent en évidence les fonctions à assurer.
• Elles proposent une approche hiérarchique descendante et modulaire.
• Chaque niveau est décomposé en respectant les entrées/sorties du niveau supérieur.
• La décomposition se poursuit jusqu’à arriver à des composants maîtrisables.
41

Modélisation des SI
1) Méthodes fonctionnelles

• L’approche fonctionnelle dissocie le problème de la représentation des


données, du problème du traitement de ces données.

• L’accès peut être :


• Direct: les données sont regroupées dans une base de données,
• Indirect: réalisé par le passage de paramètre depuis le programme principal.
42

Modélisation des SI
1) Méthodes fonctionnelles
Programme
principale
Données

Sous fonction 1 Sous fonction 2 Sous fonction 3

Sous Sous Sous


Sous Sous
fonction fonction fonction
fonction 1.2 fonction 2.2
1.1 2.1 3.1

Sous
fonction
1.2…
43

Modélisation des SI
2) L’approche orientée objet

• Considère le logiciel comme une collection d’objets dissociés, identifiés et


possédant des caractéristiques.

• Une caractéristique:
• Soit un attribut (une donnée caractérisant l’état de l’objet),
• Soit une fonction (entité comportementale de l’objet).

• La fonctionnalité du logiciel émerge de l’interaction entre les différents objets


qui le constituent.
44

Modélisation des SI
2) L’approche orientée objet
• L’une des particularités de cette approche est qu’elle rapproche les données
et leurs traitements associés au sein d’un unique unité: objet.

• Un objet est caractérisé par plusieurs notions :


• L’identité:
− Permet de distinguer l’objet des autres, indépendamment de son état.
− Exemple un produit pourra être repéré par un code, une voiture par un numéro de série,...
• Les attributs:
− Il s’agit des données caractérisant l’objet.
− Ce sont des variables stockant des informations sur l’état de l’objet.
45

Modélisation des SI
2) L’approche orientée objet
• Un objet est caractérisé par plusieurs notions :
• Les méthodes:
− Les méthodes d’un objet caractérisent son comportement,
− C’est l’ensemble des actions (appelées opérations) que l’objet va réaliser.
− Ces opérations permettent de faire réagir l’objet aux sollicitations extérieures (ou d’agir sur les
autres objets).
− De plus, les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des
valeurs des attributs, ou bien les modifier.
• La Conception Orientée Objet (COO) est la méthode qui conduit à des
architectures logicielles fondées sur les objets du système, plutôt que sur la
fonction qu’il est censé réaliser.
46

Besoin de modéliser
Besoin de modéliser pour construire un logiciel
• Modélisation des aspects statiques et dynamiques
• Modélisation à différents niveaux d'abstraction et selon plusieurs vues
• Indépendant du processus de développement

Besoin de langages normalisés pour la modélisation


• Langage semi-formel
• Standard très utilisé

Conception orientée objet


• Façon efficace de penser le logiciel
• Indépendance du langage de programmation (langages non objet)
47

Méthodes de conception
Conception fonctionnelle
• Système = ensemble de fonctions
• État du système (données) centralisé et partagé par les fonctions

Conception guidée par les données


• Système = base de données
• Fonctions communes à toutes les données
• Adaptée à l’élaboration de grandes bases de données

Conception orientée objet


• Système = ensemble d’objets
• Objet = données + fonctions
• État du système distribué entre tous les objets
48

Conception orientée objet


Principes
• Concept du domaine d'application = objet
• Décrit par état (attributs) + comportement (méthodes)
• Liens entre concepts : héritage, agrégation, composition...

Caractéristiques des objets


• Identité : objet = entité unique (mêmes attributs ⇏ même objet) même objet)
• Classification : regroupement des objets de même nature (attributs + méthodes)
• Polymorphisme : comportement différent d'une même méthode dans différentes classes
• Héritage : partage hiérarchique des attributs et des méthodes
49

Conception orientée objet avec UML


UML

• Langage graphique : Ensemble de diagrammes permettant de modéliser le logiciel selon différentes


vues et à différents niveaux d'abstraction
• Modélisation orientée objet : modélisation du système comme un ensemble d'objets interagissant.

• Dans le cadre de la modélisation d'une application informatique, les auteurs d'UML


préconisent d'utiliser une démarche :
• itérative et incrémentale,
• guidée par les besoins des utilisateurs du système,
• centrée sur l'architecture logicielle.

D'après les auteurs d'UML, un processus de développement qui possède ces qualités devrait
favoriser la réussite d'un projet.
50

Une démarche itérative et incrémentale ?


• Pour modéliser (comprendre et représenter) un système complexe, il vaut
mieux s'y prendre en plusieurs fois, en affinant son analyse par étapes. 

• Cette démarche devrait aussi s'appliquer au cycle de développement dans


son ensemble, en favorisant le prototypage. 

• Le but est de mieux maîtriser la part d'inconnu et d'incertitudes qui


caractérisent les systèmes complexes.
51

Une démarche pilotée par les besoins des utilisateurs ?

• Avec UML, ce sont les utilisateurs qui guident la définition des modèles :

• Le périmètre du système à modéliser est défini par les besoins des


utilisateurs (les utilisateurs définissent ce que doit être le système).

• Le but du système à modéliser est de répondre aux besoins de ses


utilisateurs (les utilisateurs sont les clients du système).
 
52

Une démarche pilotée par les besoins des utilisateurs ?


 
• Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de
développement (itératif et incrémental) :

• A chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des
utilisateurs.

• A chaque itération de la phase de conception et de réalisation, on veille à la prise en


compte des besoins des utilisateurs.

• A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont
satisfaits.
53

Une démarche pilotée par les besoins des utilisateurs ?

• L'expression des besoins est un travail difficile. C'est la qualité de ce travail qui détermine
quel sera le coût du système développé.

• Il faut être certain que les utilisateurs et les informaticiens ont la même vision des concepts
du domaine à informatiser et de la manière dont ils sont liés les uns aux autres.

• Il faut s'accorder sur l'organisation générale du système :


• Quelles en sont les grandes parties,
• Quels en sont les utilisateurs? quels rôles jouent-ils exactement?
• Quels sont les grand flots d'informations entre utilisateurs et parties du système ?

• Il faut enfin spécifier les différentes manières d'utiliser le système, du point de vue de
l'utilisateur, et la manière dont le système est perçu par son environnement (interfaces).
54

Une démarche centrée sur l'architecture ?


• Une architecture adaptée est la clé du succès d'un développement. Elle décrit
des choix stratégiques qui déterminent en grande partie les qualités du logiciel
(adaptabilité, performances, fiabilité...).
55

Vue ("4+1")
• Diagrammes UML utilisables tout au long du projet.
• Cette vue ("4+1") a fortement inspiré UML
56

La vue logique
 Cette vue de haut niveau se concentre sur l'abstraction et l'encapsulation,
elle modélise les éléments et mécanismes principaux du système.

 Elle identifie les éléments du domaine, ainsi que les relations et interactions
entre ces éléments :
• les éléments du domaine sont liés au(x) métier(s) de l'entreprise,
• ils gagnent à être réutilisés (ils représentent un savoir-faire).

 Cette vue organise aussi les éléments du domaine en "catégories" :


• pour répartir les tâches dans les équipes,
• regrouper ce qui peut être générique.
57

La vue des composants


Cette vue de bas niveau (aussi appelée "vue de réalisation"), montre :
• L'allocation des éléments de modélisation dans des modules (fichiers sources,
bibliothèques dynamiques, bases de données, exécutables, etc...).

• En d'autres termes, cette vue identifie les modules qui réalisent physiquement les
classes de la vue logique.

• L'organisation des composants, c'est-à-dire la distribution du code en gestion de


configuration, les dépendances entre les composants...

• La vue des composants montre aussi l'organisation des modules en "sous-systèmes",


les interfaces des sous-systèmes et leurs dépendances (avec d'autres sous-systèmes ou
modules).
58

La vue des processus


• Cette vue est très importante dans les environnements multitâches, elle
montre :
• La décomposition du système en terme de processus (tâches).
• Les interactions entre les processus (leur communication).
• La synchronisation et la communication des activités parallèles (threads).
59

La vue de déploiement
• Cette vue est très importante dans les environnements distribués, elle décrit
les ressources matérielles et la répartition du logiciel dans ces ressources :

• La disposition et nature physique des matériels, ainsi que leurs performances.


• L'implantation des modules principaux sur les nœuds du réseau.
• Les exigences en terme de performances (temps de réponse, tolérance aux fautes et
pannes...).
 
60

La vue des besoins des utilisateurs


Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les
autres.
• Dessiner le plan (l'architecture) d'un système informatique n'est pas suffisant, il
faut le justifier !
• Cette vue définit les besoins des clients du système et centre la définition de
l'architecture du système sur la satisfaction (la réalisation) de ces besoins.
• A l'aide de scénarios et de cas d'utilisation, cette vue conduit à la définition d'un
modèle d'architecture pertinent et cohérent.
• Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture.
• Elle motive les choix, permet d'identifier les interfaces critiques et force à se
concentrer sur les problèmes importants.
61

Conception et modélisation
• La description de la programmation par objets a fait ressortir l’étendue du
travail conceptuel nécessaire :
− définition des classes,
− de leurs relations,
− des attributs et méthodes,
− des interfaces
− etc.
• Pour programmer une application, il ne convient pas de se lancer tête baissée
dans l’écriture du code :
− Il faut d’abord organiser les idées,
− Les documenter,
− Puis organiser la réalisation en définissant les modules et étapes de la réalisation.
62

Que signifie UML ?


• UML(Unified Modeling Language) un langage de modélisation unifié graphique et textuel.

• Langage = syntaxe + sémantique :


− Syntaxe : notations graphiques consistant essentiellement en des représentations conceptuelles d'un
système.
− Sémantique : sens précis pour chaque notation.

• Destiné à:
− Comprendre et décrire des besoins,
− Spécifier et documenter des systèmes,
− Esquisser des architectures logicielles,
− Concevoir des solutions,
− Communiquer des points de vue.
63

Qu’est ce que UML ?


• UML est caractérisé par :
− Un travail d'expert,
− Utilise l’approche orientée objet,
− Normalisé et riche,
− Formel : sa notation limite les ambiguïté et les incompréhensions,
− Langage ouvert: Indépendant du langage de programmation,
− Domaine d'application : permet de modéliser n'importe quel système.
• Supporté par plusieurs outils : Objecteering, Open tools, IBM Rational Rose,
PowerAMC, WinDesign, argoUML, StarUML,
• Attention: UML est un langage et non pas une méthode qui :
− Permet de représenter les modèles,
− Permet de définir le processus d'élaboration des modèles.
64

UML: Historique
• Pionnier de l ’Orienté-Objet
− Article en 1981: ‘ Object Oriented Development ’
− Au début, méthode pour le développement d ’applications en Ada pour le ‘ Department de
la Défense ’
− Etendue au C++
• Distingue 2 niveaux:
− Logique
• Diagrammes de classes
• Diagramme d’instance
• Diagramme états/transitions
− Physique
• Diagrammes de modules (principe des packages) Grady Booch
• Diagramme de processus
65

UML: Historique
• Object Modeling Technique
− Livre de James Rumbaugh (1991)

• 3 axes
− Statique
− Dynamique
− Fonctionnel

James Rumbaugh
66

UML: Historique
• Object Oriented Software Engineering (OOSE).
− Souvent appelée Objectory
• 5 modèles
− Besoins
− Analyse
− Conception
− Implantation
− Test
Ivar Jacobson
• Utilisation: Use Cases
67

UML: Historique
Les méthodes objet

• En 1994, plus de 50 méthodes OO


• Fusion, Shlaer-Mellor, ROOM, Classe-Relation, Wirfs-Brock, Coad-Yourdon, MOSES,
Syntropy, BOOM, OOSD, OSA, BON, Catalysis, COMMA, HOOD, Ooram, DOORS...
• Les notations graphiques sont toutes différentes
• L’industrie a besoin de standards
68

UML: Historique
• 1993-1994: Booch’93, OMT-2
− Les 2 méthodes sont leaders sur le marché
− Elles sont de plus en plus proches
• Octobre 1994
− J. Rumbaugh (OMT) rejoint G. Booch chez Rational
− Annonce de l’unification des deux méthodes
• Octobre 1995: Méthode Unifiée v0.8
• Fin 1995: le fondateur d ’Objectory, Ivar Jacobson, rejoint à son tour Rational
69

UML: Historique
• Janvier 97 : Soumission à l’OMG de la version UML 1.0
• Septembre 97 : UML 1.1
• La dernière version diffusée par l’OMG est UML 2.5.1 (2017). 
• OMG :
− Organisme à but non lucratif fondé en 1989.
− Est un regroupement d’industriels dont l’objectif est de standardiser autour des
technologies objet, afin de garantir l’interopérabilité des développements.
− Comprend actuellement plus de 800 membres, dont les principaux acteurs de l’industrie
informatique (Sun, IBM, etc.), mais aussi les plus grandes entreprises utilisatrices dans
tous les secteurs d’activité.
70

UML: Historique
Définition en cours par une UML 2.0
commission de révision
Soumission à l’OMG UML 1.x 1999-2002

UML 1.2 Juin 1998


Standardisation par l’OMG
Novembre 1997
Soumission à l’OMG UML 1.1
Septembre 1997
Soumission à l’OMG UML 1.0 Janvier 1997
Version bêta OOPSLA’96 UML 0.9 Juin 1996

OOPSLA’95 Méthode unifiée 0.8 Octobre 1995

Booch’93 OMT-2

Autres méthodes Booch’91 OMT-1 OOSE Partenaires


71

Comment "rédiger" un modèle avec UML ?

• UML permet de définir et de visualiser un modèle, à l'aide de diagrammes.

• Un diagramme UML est une représentation graphique, qui s'intéresse à un


aspect précis du modèle ; c'est une perspective du modèle, pas "le 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).
72

Comment "rédiger" un modèle avec UML ?

• Un type de diagramme UML véhicule une sémantique précise (un type de


diagramme offre toujours la même vue d'un système).

• Combinés, les différents types de diagrammes UML offrent une vue complète
des aspects statiques et dynamiques d'un système.

• Par extension et abus de langage, un diagramme UML est aussi un modèle


(un diagramme modélise un aspect du modèle global).
73

Diagrammes d'UML
• UML s’articule autour de treize types de diagrammes.

• Chacun étant dédié à la représentation des concepts particuliers d’un système


logiciel.

• Il définit deux types de diagrammes:


− 7 diagrammes comportementaux (dynamiques ),
− 6 diagrammes structurels (statiques).
74

Diagrammes d'UML
Sept diagrammes dynamiques :
− Diagramme de cas d’utilisation: modélise les interactions fonctionnelles entre les acteurs et
le système à l’étude.
− Diagramme de séquence: montre la séquence verticale des messages passés entre objets
au sein d’une interaction.
− Diagramme de communication: représente la communication entre objets dans le plan au
sein d’une interaction.
− Diagramme d’activité: montre l’enchaînement des actions et décisions au sein d’une activité.
− Diagramme d’états: montre les différents états et transitions possibles des objets d’une
classe.
− Diagramme de vue d’ensemble des interactions: fusionne les diagrammes d’activité et de
séquence pour combiner des fragments d’interaction avec des décisions et des flots.
− Diagramme de temps: fusionne les diagrammes d’états et de séquence pour montrer
l’évolution de l’état d’un objet au cours du temps.
75

Diagrammes d'UML
Six diagrammes statiques :
− Diagramme de classes: montre les briques de base statiques : classes, associations,
interfaces, attributs, opérations, généralisations, etc.
− Diagramme d’objets: montre les instances des éléments structurels et leurs liens à
l’exécution.
− Diagramme de packages: représente l’organisation logique du modèle et les relations
entre packages.
− Diagramme de composants: montre des structures complexes, avec leurs interfaces
fournies et requises.
− Diagramme de déploiement: montre le déploiement physique des « artefacts » sur les
ressources matérielles.
− Diagramme de structure composite: représente l’organisation interne d’un élément
statique complexe.
76

Diagrammes d’UML
UML 2.5 est composé de plusieurs diagrammes :
77

Quelques caractéristiques des diagrammes UML

• Les diagrammes UML supportent l'abstraction. Leur niveau de détail


caractérise le niveau d'abstraction du modèle.

• La structure des diagrammes UML et la notation graphique des éléments de


modélisation est normalisée (document "UML notation guide").

Rappel : la sémantique des éléments de modélisation et de leur utilisation est


définie par le métamodèle UML.
78

Quelques caractéristiques des diagrammes UML

• Le recours à des outils appropriés est un gage de productivité pour


la rédaction des diagrammes UML, car :
• ils facilitent la navigation entre les différentes vues,

• ils permettent de centraliser, organiser, partager et synchroniser les diagrammes


(indispensable avec un processus itératif),

• facilitent l'abstraction, par des filtres visuels,

• simplifient la production de documents et autorisent (dans certaines limites) la


génération de code.
79

L’enchaînement des modèles


80

Vues et diagramme UML


VUE Des cas Logique Des composants Des processus De déploiement
Diagramme d’utilisation

Cas Acteurs
d'utilisation Cas d'utilisation

Objets Acteurs, Objets Acteurs, Classes


Liens Objets, Liens

Collaboration Acteurs, Objets Acteurs, Classes Classes, Objets


Liens, Message Objets, Liens Liens

Séquence Acteurs, Objets Acteurs, Objets Objets


Message Messages Messages

Acteurs, Classes
Classes Paquetages
Relations

États-transition Etats États États


Transitions Transitions Transitions

Activités Activités Activités Activités


Transitions Transitions Transitions

Composants composants composants composants

déploiement Noeuds, Liens