Cours 1 :

Prise de contact / Présentation de la matière / Mode d’évaluation.

Objectifs de l'enseignement :

Contenu de la matière :
Chapitre 1 : Introduction
Introduction à la modélisation orientée objet.
Concepts de base : modèle, modélisation, UML...
Chapitre 2 :Modélisation en UML :
1. Concepts importants de l'approche objet, Histoire de la modélisation par objet, UML.
2. Éléments et mécanismes généraux
3. les diagrammes UML.
4. Paquetages
Chapitre 3 : Diagramme de cas d'utilisation
1. Définition , intérêt et notation
2. …
Chapitre 4 : Diagramme de classes et d'objets : vue statique
1.Diagramme de classe
2. Diagramme d' objet
Chapitre 5 : Diagrammes UML : vue dynamique
1. Diagramme de séquence et de collaboration
2. diagramme d'activité
3. diagramme état/transition

Chapitre 1 : Introduction

Définitions de bases : Concepts qui reviendront souvent dans le cours.

Introduction à la modélisation orientée objet :

Systèmes informatiques : 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é
Les problèmes liés à l'informatique sont essentiellement des problèmes de logiciel.
La crise du logiciel : taux de succès décroit avec la taille des projets.
Génie logiciel => software Engineering :
• comment faire des logiciels de qualité ?
• Qu'attend-on d'un logiciel ?
• Quels sont les critères de qualité d'un logiciel ?
Critères de qualité d'un logiciel :
Utilité (correspond au besoins de l'utilisateur)
Utilisabilité.
Fiabilité.
Interopérabilité (interaction avec les autres logiciels).
Performance.
Portabilité.
Ré-utilisabilité.
Facilité de maintenance.

La qualité du processus de fabrication est garante de la qualité du produit.

Pour obtenir un logiciel de qualité, il faut en maîtriser le processus d'élaboration.
• la vie d'un logiciel est composée de différentes étapes
• la succession de ces étapes forme le cycle de vie du logiciel
• il faut contrôler la succession de ces différentes étapes
=> suivre une méthode décrivant clairement les étapes à suivre pour élaborer un logiciel.

Cycle de vie d'un logiciel et cycle de développement :

Le cycle de vie d'un logiciel : c'est l'ensemble des phases par lesquels un logiciel passe au cours de
sa vie, allant de sa création jusqu’à sa maintenance.
Le cycle de développement d'un logiciel : C’est l’ensemble des étapes nécessaires au bon
développement d’un logiciel.
Analyse des besoins : comprendre les besoins du client (établir un cahier des charges).
Spécification : Établir une description claire de ce que doit faire le logiciel (Clarifier le cahier des
charges)
Conception : Déterminer la façon dont dont le logiciel fournit les différentes fonctionnalités
recherchées
Réalisation : codage et programmation, traduction dans des langages exploitables par des
ordinateurs.
Tests : vérification du logiciel => produit conforme aux besoins ?
validation du logiciel => produit conforme fonctionnalités déterminées par le client.
Exploitation : utilisation du logiciel
Maintenance : correction des erreurs, améliorations des fonctions, ajout de nouvelles
fonctionnalités...

Les méthodes de développement

Il n’existe pas une seule méthode ou approche pour développer un logiciel, c’est un domaine qui est
toujours en pleine évolution.
Les principales approches du développement qui seront commentées :
– Modèle en cascade et cycle en V, le modèle en spirale ou RUP...
1) Processus de développement en Cascade :
Chaque étape doit être terminée avant que ne commence la suivante
À chaque étape, production d'un document base de l'étape suivante
Caractéristiques :
• Hérité des méthodes classiques d'ingénierie
• Découverte d'une erreur entraîne retour à la phase à l'origine de l'erreur et nouvelle cascade,
avec de nouveaux documents...
• Coût de modification d'une erreur important, donc choix en amont cruciaux (typique d'une
production industrielle)
• Pas toujours adapté à une production logicielle, en particulier si besoins du client changeants
ou difficiles à spécifier

Processus de développement en V
Caractéristiques :
● Variante du modèle en cascade
● Mise en évidence de la complémentarité des phases menant à la réalisation et des phases de test
permettant de les valider

Inconvénients : les mêmes que le cycle en cascade

● Processus lourd, difficile de revenir en arrière
●Nécessite des spécifications précises et stables
●Beaucoup de documentation
Recette : faite par le client, validation par rapport aux besoins initiaux
(tests, validation des documents, conformité aux normes...)
Processus de développement en Spirale
Le cycle se compose de plusieurs itérations.
C’est un cycle assez intéressant pour les développements objets.
On produit d’abord un prototype qui est affiné au cours des différents tours de la spirale.
Ce modèle est reconnu pour certains avantages : une plus grande attention sur la ré utilisabilité ,
meilleure élimination des erreurs, objectifs de qualité pris en compte dès le commencement du
processus de développement et intègre maintenance et développement dans un même contexte.

Modèle et modélisation :
Pour mettre en œuvre un logiciel (qui est créer pour pallier a des problème de la réalité), il faut
passer par la modélisation.
Un modèle est une représentation abstraite de la réalité qui exclut certains détails du monde réel.
il permet de réduire la complexité d' un phénomène en éliminant les détails qui n’influencent pas
son comportement de manière significative.
Il reflète ce que le concepteur croit important pour la compréhension et la prédiction du phénomène
modélisé

Langages de modélisation :
Un langage de modélisation doit définir :
sémantique des concepts modélisés.
La notation pour la représentation de concepts
les règles de construction et d'utilisation des concepts.
Il en existe plusieurs à différents niveaux de formalisation :
Langages de modélisation formels ( Z, B, VDM) : le plus souvent ayant des bases
mathématiques solides et permettant des preuves formelles sur les spécifications
Langages semi-formels (MERISE, UML...) : le plus souvent graphiques au pouvoir
d'expression moindre mois plus faciles a comprendre et a utiliser.

L'industrie du logiciel dispose de nombreux langages de modélisation :

adaptés aux systèmes procéduraux (MERISE...)
adaptés aux systèmes temps réel (ROOM, SADT...)
adaptés aux systèmes à objets ( OMT, Booch, UML...)
Le rôle des outils (ateliers génie logiciel) est primordial pour l'utilisabilité pratique des langages de
modélisation.
Chapitre 2 :Modélisation en UML :
Concepts importants de l'approche objet
Modélisation, modèle ?
Un modèle est une abstraction de la réalité. Il s'agit d'un processus qui consiste à identifier les
caractéristiques intéressantes d'une entité en vue d'une utilisation précise. L'abstraction
désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des caractéristiques
essentielles d'une entité, retenues par un observateur.

Historique la modélisation objet :

Pourquoi la modélisation objet??

Pallier aux insuffisances de la programmation objet :
1)l'approche objet est moins intuitive que l'approche fonctionnelle. Malgré les apparences, il est
plus naturel pour l'esprit humain de décomposer un problème informatique sous forme d'une
hiérarchie de fonctions atomiques et de données, qu'en terme d'objets et d'interaction entre
ces objets.
2)l'application des concepts objet nécessite une très grande rigueur. Le vocabulaire
précis est un facteur d'échec important dans la mise en œuvre d'une approche objet (risques
d’ambiguïtés et d'incompréhensions). Beaucoup de développeurs (même expérimentés) ne
pensent souvent objet qu'à travers un langage de programmation.
Pour remédier à ces inconvénients majeurs de l'approche objet, il nous faut donc :
1) un langage (pour s'exprimer clairement à l'aide des concepts objets), qui doit permettre de
•représenter des concepts abstraits (graphiquement par exemple),
•limiter les ambiguïtés (parler un langage commun, au vocabulaire précis, indépendant
des langages orientés objet),
•faciliter l'analyse (simplifier la comparaison et l'évaluation de solutions) .

2) une démarche d'analyse et de conception objet, pour

• ne pas effectuer une analyse fonctionnelle et se contenter d'une implémentation
objet, mais penser objet dès le départ,
• définir les vues qui permettent de décrire tous les aspects d'un système avec des
concepts objets.

UML
UML (Unified Modeling Language, traduisez "langage de modélisation objet unifié") est né
de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des

années 90 : OMT, Booch et OOSE. UML est le résultat d'un large consensus. De très nombreux
acteurs industriels ont adopté UML et participent à son développement.
En l'espace de quelques années, UML est devenu un standard incontournable.
UML, ainsi que les méthodes dont il est issu, s'accordent sur un point : une analyse objet passe
par une modélisation objet.
Fin 1997, UML est devenu une norme OMG (Object Management Group).
L'OMG est un organisme à but non lucratif, créé en 1989 à l'initiative de grandes sociétés (HP,
Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fédère plus de 850 acteurs du
monde informatique. Son rôle est de promouvoir des standards qui garantissent
l'interopérabilité entre applications orientées objet, développées sur des réseaux hétérogènes.

Vue d'ensemble sur les diagrammes fournis par UML :

Comme UML n'impose pas de méthode de travail particulière, il peut être intégré à n'importe
quel processus de développement logiciel de manière transparente. UML est une sorte de boite
à outils, qui permet d'améliorer progressivement vos méthodes de travail, tout en préservant
vos modes de fonctionnement.

Diagramme d’objets
représente les objets et leurs relations
• Appelé aussi diagramme d’instances, il représente la structure statique
• permet représentation des instances
• S’utilise de manière ponctuelle pour montrer l’effet d’une interaction

Diagramme de classes
Représente la structure statique en terme de classes et de relations.
objectifs
• Point central de la modélisation du système pour décrire ce que le système doit faire
(analyse) et comment il va le faire (conception)
• Représentation de la structure statique du système d’information
• Modélisation des classes et de leurs relations
• un Diagramme de package permet de représenter les dépendances entre les différents
package du système

Diagramme de composants
Représente les composants physiques d’une application.
objectifs
• Description des composants logiciels et de leurs dépendances
• Composant : un fichier de programme source, une
bibliothèque, un programme exécutable, réutilisable
• Utilisé en conception de logiciel pour allouer les classes et objets aux composants

Diagramme de déploiement
Représente le déploiement des composants sur les dispositifs matériels.
objectifs
• Description
– de la configuration matérielle des unités de traitements (hard et soft).
– de l’architecture technique, des nœuds et de leur interconnexion
• Nœuds de l’architecture : serveurs, postes de travail et périphériques
• Les composants sont alloués aux différents nœuds

Diagramme de cas d’utilisation

 Représente les objectifs en terme de fonctionnalités du système du point de vue de
l’utilisateur.
• Description de ce que l'application doit (ou ne doit pas) être capable de prendre en compte
Description de la manière dont une organisation ou un système externe doivent interagir avec
le système .
Du Point de vue de l’utilisateur , il sert à mettre en évidence les services rendus par le
système.

Diagramme de séquence
 Représentation temporelle des objets et de leurs interactions.
objectifs
• Validation des cas d'utilisation, pour comprendre la logique de l'application
• Complète le diagramme des cas d’utilisation en mettant en évidence les objets et leurs
interactions d’un point de vue temporel
• Outils de documentation, peu rigoureux, pas tout le temps nécessaires

Diagramme de collaboration
 Représentation spatiale des objets, des liens et des interactions.
(correspond à un diagramme de d'objets étendu, avec représentation des envois de messages).
objectifs
• Faire apparaître les classes, spécifier l’usage des instances
• Montrer les interactions entre objets par leurs liens et les messages échangés

Diagramme d’états-transitions
Représente le cycle de vie d’un objet
Représentation du cycle de vie des instances d’une classe
• Spécification des états, des transitions entre ces états et des actions associées aux
transitions
• S’utilise pour la modélisation de la dynamique de certaines classes

Diagramme d’activité
 Représente un enchaînement d’activités au sein d’une opération, d’un cas d’utilisation ou
d’un processus métier.
• Représentation
– un processus d’une organisation
– du comportement d’opérations d'une classe
• Plusieurs points de vue pour analyser un processus pour concevoir un objet

Paquetages
Un package en UML est utilisé pour regrouper un ensemble d’éléments et fournir un espace de
noms pour ces éléments regroupés. Il peut contenir d'autres packages, et par conséquent offre une
organisation hiérarchique des éléments (packages).
La plupart des éléments qui composent les différents diagrammes UML peuvent être regroupés en
packages, entre autres : les classes, les objets, les cas d'utilisation, les composants, les nœuds ...etc.
Chapitre 3: Diagrammes de cas d'utilisation.
Chapitre 4 : Diagramme de classes et d'objets : vue statique
Chapitre 5 : Diagrammes UML : vue dynamique
1. Diagramme de séquence
( Regarder la deuxième partie du cours )