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.

Méthodologies de Conception Orientée Objet

Document source

Méthodologies de Conception Orientée Objet

Object-Oriented Design, Programming, Class Diagrams · Institut Supérieur d'Informatique de Mahdia · PDF · 2 pages · 2020

Afficher l'aperçu du document

Consulter le document original →

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èce 1).

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 : TransactionBoursiere est la super-classe (classe mère). Achat et Vente sont 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) : PersonnePhysique et PersonneMorale héritent d'une classe abstraite Personne.
  • Relation 2 (Association) : Une association entre CompteBancaire et Personne. 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 : Peripherique est la classe mère. Modem et Clavier en 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

  1. 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.
  2. Attributs et méthodes de classes :
    • Enseignant : date de prise de fonction, indice.
    • Etudiant : année d'entrée, méthodes calculerMoyenneGenerale(), afficherMatieresNonNotees().
    • Matiere : méthode calculerMoyenne().
    • Departement : méthode calculerMoyenne().
  3. 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 Etudiant et Matiere porte une "note". En UML, une relation plusieurs-à-plusieurs portant une donnée se modélise par une classe d'association (que nous appellerons Evaluation).

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

  1. Hiérarchie de contenance : Un Document contient 1 à plusieurs (1..*) Feuille (composition). Une Feuille contient 0 à plusieurs (0..*) ObjetGraphique (agrégation ou composition).
  2. Polymorphisme : Texte, FormeGeometrique, et Groupe héritent de la classe abstraite ObjetGraphique.
  3. Le motif Composite : La classe Groupe possède une relation d'agrégation vers la classe ObjetGraphique (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).
  4. Spécialisation des formes : Cercle, Ellipse, Rectangle, Carre, Ligne héritent de FormeGeometrique.

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

  1. 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é").
  2. 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..* ou 0..*).
    • 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).

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 :

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 à * (ou n).

Partager

Commentaires

Aucun commentaire pour le moment. Posez la première question.

Les commentaires sont relus avant publication. Votre e-mail n'est jamais affiché.

← Toutes les révisions