Conception Orientée Objets des Systèmes d’informations

Introduction à UML

Elaboré par Dr. Emna HKIRI

[email protected]

Polytech de Monastir 2022-2023

Bibliographie UML
 « UML 2.0, guide de référence »
 James Rumbaugh, Ivar Jacobson, Grady Booch
 Editions Campus Press (2005)
 « UML 2.0 »
 Benoît Charoux, Aomar Osmani, Yann Thierry-Mieg
 UML 2.0 SupEditions Pearson, Education France (2008)
 « UML 2.0 Superstructure » et « UML 2.0 Infrastructure »
 OMG (Object Management Group)
 www.uml.org (2004).

2
Plan
 Concepts de l’approche objets et présentation d’UML2
 Modélisation des besoins
 Diagrammes de cas d’utilisation
 Modélisation de la structure statique
 Diagramme de classes
 Diagramme d’objets
 Modélisation du comportement dynamique
 Diagrammes d’interaction
 Diagramme de séquence
 Diagramme de collaboration
 Diagramme d’états-transition
 Diagramme d’activités

3
Introduction à la Modélisation Orientée
Objet
Phases de développement d’un logiciel

5
Phases de développement d’un logiciel
 7 étapes dans la vie d’un logiciel:
 Planification (Étude de la faisabilité)

1. Spécification des besoins (Requirement analysis/ cahier des charges)

2. Analyse (Spécification formelle/ Que fait le système ?)

3. Conception (Spécification technique/ Comment faire le système ?, )

4. Implémentation (Codage)
5. Tests unitaires
6. Intégration et tests
7. Livraison et Maintenance

6
 Phases de développement d’un logiciel
1. Spécification des besoins À partir du cahier des charges, description du problème à
traiter
2. Analyse Répondre au « Que fait le système ? », modélisation du domaine d
’application, analyse de l ’existant et des contraintes de réalisation
3. Conception Répondre au « Comment faire le système ?, Décomposition modulaire/
• Activités :
• Définition de l ’architecture du logiciel
• Définition de chaque constituant du logiciel : informations traitées, traitements
effectués, résultats fournis, contraintes à respecter
4. Implémentation : Réalisation des programmes dans un (des) langage(s) de
Programmation, Tests selon les plans définis lors de la conception
5. Tests unitaires : test séparé de chacun des composants du logiciel en vue de leur
intégration
6. Intégration et test : Intégration des modules et test de tout le système
7. Livraison, maintenance, évolution : Livraison du produit final à l'utilisateur, Suivi,
modifications, améliorations après livraison.

7
8
Poids de la maintenance

9
Méthode d ’analyse et de conception
 Objectif:
 Proposition d ’une démarche distinguant les étapes du développement dans le cycle de vie du
logiciel (modularité, réduction de la complexité, réutilisabilité éventuelle, abstraction)
 Utilisation d’un formalisme de représentation qui facilite la communication, l’organisation et
la vérification
 Production de documents (modèles) qui facilitent les retours sur conception et l’évolution des
applications
 Méthodes fonctionnelles hiérarchiques
• Data-Flow/SADT/SA-SD, Structure-Chart, ...
 Méthodes données
• Entité-Relation, MERISE, ...
 Méthodes objets
• OMT, OOA, Classe-Relation, OOD, ...
 ...

10
Méthodes fonctionnelles hiérarchiques
 Approche descendante :
 Décomposer la fonction globale jusqu'à obtenir des fonctions simples à
appréhender et donc à programmer.
 Les fonctions communiquent entre elles en utilisant des données partagées ou
des transferts de paramètres.
C'est la fonction qui donne la forme du système.

11
 Méthodes fonctionnelles hiérarchiques
 Limites:
 Les fonctions sont dissociées des données
 La structuration du système se base sur des fonctions. Ainsi tout
changement de fonctions causera des difficultés de changement du
système
 Coût de maintenance important

12
Méthodes objets
 L’approche orientée objet considère le logiciel comme une collection d’objets.

 Diminution de l’écart entre le monde réel et sa présentation informatique

 Un objet est une abstraction de données définis par des propriétés et contenant de
fonctions.

 Les objets communiquent en échangeant des messages pour accomplir une tâche.

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

le forme.

13
Méthodes objets: Avantages:

Très proche du monde réel

Réutilisation aisée

Rapproche les données et leurs

traitements associés au sein d’un
unique objet
Cacher l’information avec
l’encapsulation
Adaptée au systèmes complexes
Cout de développement moins
élevé avec l’héritage

14
 Méthodes objets:Objet et Classe
Employé Employé: Tounsi identité
nom
Numéro=25
Numéro Nom=Tounsi
Nom Qualification=Ingénieur
attributs Qualification Site-travail=Monastir état
Site-travail
afficherInfoEmployé() afficherInfoEmployé()
consulterEmployé() consulterEmployé()
méthodes SalaireEmployé() comportement
SalaireEmployé()

Employé

15
Unification des méthodes objet
 Constat : au début des années 90, existe une cinquantaine de méthodes objet, liées
uniquement par un consensus autour d ’idées communes (objet, classe, sous-
systèmes, …) MAIS avec chacune sa propre notation, SANS arriver à remplir tous
les besoins et à modéliser correctement les divers domaines d ’application.

 Recherche d ’un langage commun unique

 Utilisable par toute méthode objet, dans toutes les phases du cycle de vie,

 Compatible avec les techniques de réalisation actuelles.

16
Unified Modeling Language (UML)
 Au milieu des années 90, les auteurs de Booch, OOSE et OMT ont décidé de créer
un langage de modélisation unifié avec pour objectifs :
 Modéliser un système des concepts à l'exécutable, en utilisant les techniques orientée
objet ;
 Réduire la complexité de la modélisation ;
 Utilisable par l'homme comme la machine :

 Officiellement UML est né en 1994.

 UML v2.0 date de 2005. Il s'agit d'une version majeure apportant des
innovations radicales et étendant largement le champ d'application d'UML.

17
UML: les différents modèles

18
Modèle
 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.

 Permet de mieux comprendre le système afin de mieux aborder le problème à traiter

 Fournit un moyen de communication entre les développeurs
 Réduit les erreurs et permettre leurs détections tôt dans les phases de développement
 Réduit le coût de développement

19
Modélisation des besoins

Diagrammes de cas d’utilisation

UML: les différents modèles

21
Exemple de diagramme de cas d'utilisation

Un cas d'utilisation est un

service rendu à
l'utilisateur, il implique des
séries d'actions plus
élémentaires.

Un acteur est une entité extérieure au système

modélisé, et qui interagit directement avec lui.
22
Exemple de diagramme de cas d'utilisation

23
Acteur
 Les acteurs n ’appartiennent pas au système, MAIS ils interagissent avec celui-ci.
• Ils fournissent de l’information en entrée.
• et/ou reçoivent de l’information en sortie.
 Bien identifier les acteurs admissibles, et évaluer comment ils vont interagir avec
le système.
 Les acteurs ne sont pas forcément des personnes.
 Possibilité de spécialiser des acteurs à partir d’autres acteurs
 Le nom de l ’acteur correspond au rôle joué par la personne

Client
24
Cas d'utilisation
 Un cas d'utilisation est l'expression d'un service réalisé de bout en bout, avec un
déclenchement, un déroulement et une fin, pour l'acteur qui l'initie.
• Modélisant un dialogue entre un acteur et le système…
• Représentant une fonctionnalité offerte par le système.
 L’ensemble des cas d’utilisation forme toutes les façons dont le système pourra
être utilisé.
 Un Use Case sert : à délimiter le système, à analyser les besoins, à concevoir des
interfaces, à distribuer le travail, à préparer les tests , etc...

25
Relations entre cas d'utilisation et acteurs
 Les acteurs impliqués dans un cas d'utilisation lui sont liés par une association.
 Un acteur peut utiliser plusieurs fois le même cas d'utilisation.

26
 Relations entre cas d'utilisation: include
 Inclusion : «  include » ou « inclut »
 Le cas A inclut le cas B (B est une partie obligatoire de A).
 Le comportement décrit par le cas B est inclu dans le comportement du cas B

 Exemple

27
 Exemple
Inclusion : X « include » Y
X implique Y
Y est nécessaire pour X

28
Relations entre cas d'utilisation: Extend
 Extension : « extend » ou « étend »

 Le cas B étend le cas A (B est une partie optionnelle de A).

 Une extension est souvent soumise à condition.

 L’extension peut intervenir à un point précis du cas étendu et est éventuellement

associé à une contrainte indiquant le moment où l’extension intervient.

29
Relations entre cas d'utilisation: Extend
 Exemple:
Un porteur de carte a le droit de consulter son solde juste avant qu’il ne choisisse le
montant de son retrait .
Il peut ainsi ajuster le montant demandé avec qu’il lui reste à ce moment sur son compte

<<extend>>

Retirer de l’argent Consulter solde

Condition: {porteur choisit consultation solde}

30
 Exemple
Extension : X « extend » Y
X peut être provoqué par Y
 X est optionnel pour Y

31
Relations entre cas d'utilisation : Généralisation
 Généralisation/spécialisation : le cas A est une généralisation du cas B (B est un
cas particulier de A).

 Cette relation se traduit par le concept d’héritage dans les langages orientés objet.

32
Généralisation/spécialisation
 Un virement est un cas particulier de paiement.
Un virement est une sorte de paiement.

 La flèche pointe vers l'élément général.

 Cette relation de généralisation/spécialisation est présente dans la plupart des

diagrammes UML et se traduit par le concept d'héritage dans les langages orientés
objet.

33
Exemple

34
Exemple
Généralisation :
X est un cas particulier de Y

35
Réutilisabilité avec les inclusions et les extensions
 Les relations entre cas permettent la réutilisabilité du cas « s'authentifier » : il
sera inutile de développer plusieurs fois un module d'authentification.

36
Décomposition grâce aux inclusions et aux extensions
 Quand un cas est trop complexe (faisant intervenir un trop grand nombre
d'actions), on peut procéder à sa décomposition en cas plus simples.

37
Exemple Récap

38
Relations entre acteurs
Relation d’héritage
 La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation
 d’un acteur B si l’acteur A peut être substitué par l’acteur B.
 Tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.

39
Relations entre acteurs

40
Identification des acteurs
 Les principaux acteurs sont les utilisateurs du système.
Un acteur correspond à un rôle, pas à une personne physique.
 Une même personne physique peut être représentée par plusieurs acteurs si elle a
plusieurs rôles.
 Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles seront
représentées par un seul acteur.

 En plus des utilisateurs, les acteurs peuvent être :

 Des logiciels déjà disponibles à intégrer dans le projet ;
 Des systèmes informatiques externes au système mais qui interagissent avec lui, etc.

41
Acteurs principaux et secondaires
 L'acteur est dit principal pour un cas d'utilisation lorsque l'acteur est à l'initiative
des échanges nécessaires pour réaliser le cas d'utilisation.

 Les acteurs secondaires sont sollicités par le système alors que le plus souvent, les
acteurs principaux ont l'initiative des interactions.
 Le plus souvent, les acteurs secondaires sont d'autres systèmes informatiques avec
lesquels le système développé est inter-connecté.
 Exemple:

42
 Recenser les cas d'utilisation
 Il n'y a pas une manière mécanique et totalement objective de repérer les cas
d'utilisation.
 Il faut se placer du point de vue de chaque acteur et déterminer comment il se sert du
système, dans quels cas il l'utilise, et à quelles fonctionnalités il doit avoir accès.
 Il faut éviter les redondances et limiter le nombre de cas en se situant au bon niveau
d'abstraction
 Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il faut rester au
niveau des grandes fonctions du système.
 Il ne doit pas y avoir de notion temporelle dans un diagramme de cas d’utilisation.

43
Regroupement de cas d’utilisation en package
 UML permet de regrouper des cas d’utilisation dans une entité appelée «
paquetage ».

 Le regroupement peut se faire par acteur ou par domaine fonctionnel.

 Un diagramme de cas d’utilisation peut contenir plusieurs paquetages et des

paquetages peuvent être inclus dans d’autres paquetages.

44
Regroupement de cas d’utilisation en package(2)

Exemple:

45
Description des cas d'utilisation
 Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du
point de vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les
acteurs et les cas d'utilisation.

 Un simple nom est tout à fait insuffisant pour décrire un cas d'utilisation.

Chaque cas d'utilisation doit être documenté pour qu'il n'y ait aucune ambiguïté
concernant son déroulement et ce qu'il recouvre précisément.

46
Description textuelle

47
 Classe de scénarios :
 Un use case comprend au moins deux scénarios: un où tout se passe bien, et un
autre où il y a problème.
 instance d’un cas d’utilisation: séquence de transactions entre le système et
l’acteur qui mène à un résultat tangible pour un acteur.
 Un cas d’utilisation est une famille de scénarios

Nom : Achat ticket Scenario :

Acteur : Passager 1. Passager choisit le nombre de zones traversées.
Condition entrée : 2. Le distributeur affiche la somme due.
• Passager devant le distributeur de 3. Passager insère l’argent correspondant à au
ticket. moins la somme due.
• Passager a suffisamment d’argent 4. Distributeur rend la monnaie.
pour acheter le ticket. 5. Distributeur donne le ticket
Condition de sortie :
• Passager a le ticket.
48
Description textuelle (1)
 Identification :
 Nom du cas : Payer CB
 Objectif : Détailler les étapes permettant à client de payer par carte bancaire
 Acteurs : Client, Banque (secondaire)
 Date : 18/09
 Responsables : Toto
 Version : 1.0

49
 Description textuelle(2)
 Séquencements :
 Le cas d'utilisation commence lorsqu'un client demande le paiement par carte bancaire
 Pré-conditions
 Le client a validé sa commande

 Enchaînement nominal
 1) Le client saisit les informations de sa carte bancaire
 2) Le système vérifie que le numéro de CB est correct
 3 ) Le système vérifie la carte auprès du système bancaire
 4) Le système demande au système bancaire de débiter le client
 5 ) Le système notifie le client du bon déroulement de la transaction
 Enchaînements alternatifs
 1) En (2) : si le numéro est incorrect, le client est averti de l'erreur, et invité à recommencer
 2) En (3) : si les informations sont erronées, elles sont re-demandées au client
 Post-conditions
 La commande est validée
 50Le compte de l'entreprise est crédité
Description textuelle(3)
 Rubriques optionnelles
 Contraintes non fonctionnelles :
 Fiabilité : les accès doivent être sécurisés
 Confidentialité : les informations concernant le client ne doivent pas être divulgués
 Contraintes liées à l'interface homme-machine :
 Toujours demander la validation des opérations bancaires

51
 Exercice
  Considérons le système informatique qui gère une station-service de distribution
d’essence.
 On s’intéresse à la modélisation de la prise d’essence par un client.

1. Le client se sert de l’essence de la façon suivante. Il prend un pistolet accroché à une

pompe et appuie sur la gâchette pour prendre de l’essence. Qui est l’acteur du système ?
Est-ce le client, le pistolet ou la gâchette ?
2. Le pompiste peut se servir de l’essence pour sa voiture. Est-ce un nouvel acteur ?
3. La station a un gérant qui utilise le système informatique pour des opérations de
gestion. Est-ce un nouvel acteur ?
4. La station-service a un petit atelier d’entretien de véhicules dont s’occupe un
mécanicien.
5. Le gérant est remplacé par un chef d’atelier qui, en plus d’assurer la gestion, est aussi
mécanicien. Comment modéliser cela ?

52
Solution :

53
Application
 Dans un établissement scolaire, on désire gérer la réservation des salles de cours ainsi que
du matériel pédagogique (ordinateur portable ou/et Vidéo projecteur).

 Seuls les enseignants sont habilités à effectuer des réservations (sous réserve de
disponibilité de la salle ou du matériel).

 Le planning des salles peut quant à lui être consulté par tout le monde (enseignants et
étudiants).

 Par contre, le récapitulatif horaire par enseignant (calculé à partir du planning des salles)
ne peut être consulté que par les enseignants.

 Enfin, il existe pour chaque formation un enseignant responsable qui seul peut éditer le
récapitulatif horaire pour l’ensemble de la formation

54
Solution

55
Exercice (Gestion de bibliothèque universitaire )
Une bibliothèque universitaire souhaite automatiser sa gestion. Cette bibliothèque est gérée par un
gestionnaire chargé des inscriptions et des relances des lecteurs quand ceux-ci n'ont pas rendu leurs
ouvrages au-delà du délai autorisé. Les bibliothécaires sont chargés de gérer les emprunts et la restitution
des ouvrages ainsi que l'acquisition de nouveaux ouvrages.
Il existe trois catégories d'abonnés. Tout d'abord les étudiants qui doivent seulement payer une somme
forfaitaire pour une année afin d'avoir droit à tous les services de la bibliothèque. L'accès à la bibliothèque
est libre pour tous les enseignants. Enfin, il est possible d'autoriser des étudiants d'une autre université à
s'inscrire exceptionnellement comme abonné moyennant le versement d'une cotisation. Le nombre
d'abonnés externes est limité chaque année à environ 10 % des inscrits. Un nouveau service de
consultation du catalogue général des ouvrages doit être mis en place.
Les ouvrages, souvent acquis en plusieurs exemplaires, sont rangés dans des rayons de la bibliothèque.
Chaque exemplaire est repéré par une référence gérée dans le cata­logue et le code du rayon où il est rangé.
Chaque abonné ne peut emprunter plus de trois ouvrages. Le délai d'emprunt d'un ouvrage est de trois
semaines, il peut cependant être prolongé exceptionnellement à cinq semaines.
 
Il est demandé d'élaborer le diagramme des cas d'utilisation.

56
SOLUTION
Six cas d'utilisation peuvent être identifiés :
 Inscription à la bibliothèque;
 Consultation du catalogue;
 Emprunt d'ouvrage;
 Restitution d'ouvrage;
 Approvisionnement d'ouvrage;
 Relance emprunteur.

Cinq types d'acteurs peuvent être identifiés : 

 étudiant ;
 externe ; 
 emprunteur;
 gestionnaire
 bibliothécaire.

57