Méthodologies de Conception Orientée Objet
Exercice 1 - Description du diagramme de classes L'énoncé demande de décrire un diagramme de classes et d'expliciter ses multiplicités. Cependant, le diagramme source est manquant dans le document fourni. Il est donc impossible de répondre à cette question sans inventer des données. Dans une situation d'examen réel, il faudrait signaler cette omission au surveillant.
D'après le document Méthodologies de Conception Orientée Objet
Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.

Document source
Object-Oriented Design, Programming, Class Diagrams · Institut Supérieur d'Informatique de Mahdia · PDF · 2 pages · 2020
Afficher l'aperçu du document
Exercice 1 - Description du diagramme de classes
L'énoncé demande de décrire un diagramme de classes et d'expliciter ses multiplicités. Cependant, le diagramme source est manquant dans le document fourni.
Il est donc impossible de répondre à cette question sans inventer des données. Dans une situation d'examen réel, il faudrait signaler cette omission au surveillant. Nous passons directement à l'exercice 2.
Exercice 2 - Identification des relations UML
Pour traduire ces phrases en UML, il faut identifier les concepts de base (qui deviendront les classes) et la nature de leurs interactions (qui définiront le type de relation : association simple, agrégation, composition ou héritage).
Voici le code PlantUML générant les diagrammes, suivi de l'explication pour chaque cas.
@startuml
' Cas 1
class Repertoire
class Fichier
Repertoire "1" *-- "0..*" Fichier : contient >
' Cas 2
class Piece
class Mur
Piece "1" *-- "1..*" Mur : est composée de >
' Cas 3
class TransactionBoursiere
class Achat
class Vente
TransactionBoursiere <|-- Achat
TransactionBoursiere <|-- Vente
' Cas 4
class Personne
class PersonnePhysique
class PersonneMorale
class CompteBancaire
Personne <|-- PersonnePhysique
Personne <|-- PersonneMorale
Personne "1" -- "0..*" CompteBancaire : possède >
' Cas 5
class Peripherique
class Modem
class Clavier
Peripherique <|-- Modem
Peripherique <|-- Clavier
@enduml
Cas 1 : Un répertoire contient des fichiers
Il s'agit d'une relation de contenance forte (ou parfois faible selon le système de fichiers). Une composition est la plus appropriée, car si on détruit un répertoire, on détruit généralement les fichiers qu'il contient (bien qu'une agrégation soit tolérée si on considère les raccourcis).
- Relation : Composition.
- Multiplicités : Un répertoire contient zéro ou plusieurs fichiers (
0..*), et un fichier appartient à un seul répertoire (1).
Cas 2 : Une pièce contient des murs
Un mur fait partie intégrante d'une pièce de manière vitale. La destruction de la pièce entraîne la destruction conceptuelle de ses murs.
- Relation : Composition.
- Multiplicités : Une pièce est composée de plusieurs murs (au moins un, généralement 3 ou plus, donc
1..*), et un mur délimite une pièce (ou deux si partagé, mais pour simplifier, rattaché à la définition de la pièce1).
Cas 3 : Une transaction boursière est un achat ou une vente
L'expression "est un(e)" est le déclencheur typique d'une relation de généralisation/spécialisation.
- Relation : Héritage.
- Structure :
TransactionBoursiereest la super-classe (classe mère).AchatetVentesont les sous-classes (classes filles).
Cas 4 : Un compte bancaire peut appartenir à une personne physique ou morale
Nous avons deux concepts liés. D'une part, la notion de "Personne" qui se décline en deux types (héritage). D'autre part, la possession d'un compte (association).
- Relation 1 (Héritage) :
PersonnePhysiqueetPersonneMoralehéritent d'une classe abstraitePersonne. - Relation 2 (Association) : Une association entre
CompteBancaireetPersonne. Un compte appartient à une personne (1), et une personne peut avoir plusieurs comptes (0..*).
Cas 5 : Les modems et claviers sont des périphériques d’entrée / sortie
Même logique que pour le cas 3 ("sont des").
- Relation : Héritage.
- Structure :
Peripheriqueest la classe mère.ModemetClavieren sont les classes filles.
Exercice 3 - Gestion des cours d'une académie
Pour cet exercice, la difficulté réside dans la factorisation des attributs communs (grâce à l'héritage) et dans la modélisation correcte des notes attribuées aux étudiants (qui nécessite une classe d'association).
Démarche de modélisation
- Héritage : Les enseignants et les étudiants partagent les attributs "nom", "prénom", "tél" et "mail", ainsi que l'opération "imprimer la fiche signalétique". Il est judicieux de créer une classe mère
Personne. - Attributs et méthodes de classes :
Enseignant: date de prise de fonction, indice.Etudiant: année d'entrée, méthodescalculerMoyenneGenerale(),afficherMatieresNonNotees().Matiere: méthodecalculerMoyenne().Departement: méthodecalculerMoyenne().
- Relations clés :
- L'enseignant "Responsable" du département justifie une association spécifique (1..1) différente de l'appartenance au département (1..*).
- La relation entre
EtudiantetMatiereporte une "note". En UML, une relation plusieurs-à-plusieurs portant une donnée se modélise par une classe d'association (que nous appelleronsEvaluation).
Code du diagramme
@startuml
class Academie
class College {
+ siteInternet : String
}
class Departement {
+ calculerMoyenne() : float
}
abstract class Personne {
+ nom : String
+ prenom : String
+ tel : String
+ mail : String
+ imprimerFiche() : void
}
class Enseignant {
+ datePriseFonction : Date
+ indice : int
}
class Etudiant {
+ anneeEntree : int
+ calculerMoyenneGenerale() : float
+ afficherMatieresNonNotees() : void
}
class Matiere {
+ calculerMoyenne() : float
}
class Salle {
+ nbPlaces : int
}
class Evaluation << (A,#FFAAAA) Association >> {
+ note : float
}
Academie "1" -- "1..*" College : gère >
College "1" *-- "1..*" Departement : est structuré en >
Departement "1" - "1..*" Enseignant : regroupe >
Departement "1" -- "1" Enseignant : a pour responsable >
Personne <|-- Enseignant
Personne <|-- Etudiant
Enseignant "1..*" -- "1" Matiere : enseigne >
Etudiant "1..*" - "1..*" Matiere : suit >
(Etudiant, Matiere) .. Evaluation
Matiere "1..*" -- "1" Salle : a lieu dans >
@enduml
Exercice 4 - Éditeur de documents graphiques
Le point central de cet exercice est le motif de conception Composite. Un Groupe est un objet graphique qui contient d'autres objets graphiques (qui peuvent eux-mêmes être des groupes).
Démarche de modélisation
- Hiérarchie de contenance : Un
Documentcontient 1 à plusieurs (1..*)Feuille(composition). UneFeuillecontient 0 à plusieurs (0..*)ObjetGraphique(agrégation ou composition). - Polymorphisme :
Texte,FormeGeometrique, etGroupehéritent de la classe abstraiteObjetGraphique. - Le motif Composite : La classe
Groupepossède une relation d'agrégation vers la classeObjetGraphique(sa propre classe mère). L'énoncé précise qu'un groupe doit contenir au moins deux éléments (multiplicité2..*du côté du composant). - Spécialisation des formes :
Cercle,Ellipse,Rectangle,Carre,Lignehéritent deFormeGeometrique.
Code du diagramme
@startuml
class Document
class Feuille
abstract class ObjetGraphique
class Texte
abstract class FormeGeometrique
class Groupe
class Cercle
class Ellipse
class Rectangle
class Carre
class Ligne
Document "1" *-- "1..*" Feuille : se compose de >
Feuille "1" *-- "0..*" ObjetGraphique : contient >
ObjetGraphique <|-- Texte
ObjetGraphique <|-- FormeGeometrique
ObjetGraphique <|-- Groupe
Groupe o-- "2..*" ObjetGraphique : rassemble >
FormeGeometrique <|-- Cercle
FormeGeometrique <|-- Ellipse
FormeGeometrique <|-- Rectangle
FormeGeometrique <|-- Carre
FormeGeometrique <|-- Ligne
@enduml
Exercice 5 - Gestion du parc informatique
Cet exercice requiert d'identifier les entités principales de l'infrastructure et de bien gérer les cardinalités liées à la sécurité et à l'usage des périphériques.
Démarche de modélisation
- Les entités et leurs attributs :
Ordinateur: numInventaire, adresseIP, modele, dateAcquisition, dateProchaineMaintenance, systemeExploitation.Logiciel: numLicence, nom, version.Employe: nom, prenom, fonction.Peripherique: numInventaire, adresseIP, type, modele, dateAcquisition, dateProchaineMaintenance.Bureau: numBureau, numBatiment (les deux forment l'identifiant, car "Un numéro de bureau est unique dans un bâtiment donné").
- Les relations :
- Ordinateur - Logiciel : Un ordinateur possède de 0 à plusieurs logiciels, un logiciel est installé sur 0 à plusieurs ordinateurs. Relation
*..*. - Ordinateur - Employé : Un employé n'a le droit d'utiliser qu'un seul ordinateur (
1), mais un ordinateur peut être utilisé par plusieurs employés (1..*ou0..*). - Ordinateur - Périphérique : Périphériques en réseau. Un ordinateur utilise plusieurs périphériques, un périphérique sert à plusieurs ordinateurs. La phrase "un indice de priorité est affecté à chaque ordinateur pour chaque périphérique auquel il est connecté" exige une classe d'association entre Ordinateur et Périphérique, portant l'attribut
indicePriorite. - Localisation : Un bureau contient de 0 à plusieurs ordinateurs et périphériques. Un ordinateur/périphérique est localisé dans 1 bureau exact (
1).
- Ordinateur - Logiciel : Un ordinateur possède de 0 à plusieurs logiciels, un logiciel est installé sur 0 à plusieurs ordinateurs. Relation
Code du diagramme
@startuml
class Employe {
+ nom : String
+ prenom : String
+ fonction : String
}
class Ordinateur {
+ numInventaire : String
+ adresseIP : String
+ modele : String
+ dateAcquisition : Date
+ dateProchaineMaintenance : Date
+ systemeExploitation : String
}
class Logiciel {
+ numLicence : String
+ nom : String
+ version : String
}
class Peripherique {
+ numInventaire : String
+ adresseIP : String
+ type : String
+ modele : String
+ dateAcquisition : Date
+ dateProchaineMaintenance : Date
}
class ConnexionReseau << (A,#FFAAAA) Association >> {
+ indicePriorite : int
}
class Bureau {
+ numBureau : String
+ numBatiment : String
}
Employe "1..*" -- "1" Ordinateur : utilise >
Ordinateur "0..*" -- "0..*" Logiciel : installe <
Ordinateur "0..*" - "0..*" Peripherique : est connecté à >
(Ordinateur, Peripherique) .. ConnexionReseau
Bureau "1" -- "0..*" Ordinateur : abrite >
Bureau "1" -- "0..*" Peripherique : abrite >
@enduml
Méthode
Face à une épreuve de modélisation UML (diagramme de classes) telle que celle-ci, voici les réflexes à adopter :
- Repérage des substantifs et verbes : Lisez l'énoncé avec deux surligneurs. Les noms communs (ordinateur, logiciel, étudiant) sont généralement des candidats pour devenir des Classes. Les verbes (contient, utilise, dispense) définissent les Associations.
- Identification des attributs vs classes : Ne transformez pas une simple chaîne de caractères (comme le numéro de téléphone ou l'adresse IP) en classe. Si le concept n'a pas lui-même de propriétés, c'est un attribut.
- Le test du "Est un(e)" : Dès que vous lisez qu'un concept "est un" type particulier d'un autre concept (ex: un achat est une transaction), modélisez un héritage. N'oubliez pas que l'héritage permet de remonter tous les attributs communs dans la classe mère.
- Les classes d'association : Soyez très attentifs aux propriétés qui n'appartiennent ni à la classe A, ni à la classe B, mais à la rencontre des deux. Une note n'appartient pas à un étudiant en soi (il a plusieurs notes), ni à une matière (elle a plusieurs notes d'élèves différents). Elle appartient au fait qu'un étudiant a suivi une matière. C'est le marqueur absolu d'une classe d'association.
- Vérification des multiplicités (cardinalités) : Lisez la relation dans les deux sens pour fixer les bornes minimales et maximales (ex: 1 employé utilise 1 ordinateur MAXIMUM, mais 1 ordinateur est utilisé par au minimum 1 employé). Un pluriel dans le texte implique au moins une borne max à
*(oun).
Commentaires
Aucun commentaire pour le moment. Posez la première question.