Méthodes de Conception OO

Exercice 1 - Modélisation dynamique du prêt de cassettes

Puisqu'il n'est pas possible de tracer graphiquement le diagramme de séquences ici, nous allons détailler les acteurs, les objets et la chronologie exacte des messages (le scénario) que vous devez représenter sur votre copie.

Acteurs et Objets identifiés

1. Adhérent (Acteur externe initiant le cas d'utilisation)
2. Contrôleur (Objet interface gérant les droits d'accès)
3. Système (Objet gérant la logique métier du prêt)
4. Catalogue (Objet contenant les informations sur les films et cassettes, bien qu'il puisse être fusionné avec le Système selon le niveau de détail attendu).

Chronologie des messages (Scénario nominal et alternatif)

La séquence suit un enchaînement avec des blocs conditionnels (fragments alt et opt en UML).

• Message 1 : L'Adhérent envoie une demandeEmprunt(CIN, nom, prénom) au Contrôleur.
• Fragment alt [Demande acceptée]
  • Message 2 : Le Contrôleur renvoie un message afficherAutorisation() à l'Adhérent.
  • Message 3 : Le Système envoie demanderReferenceFilm() à l'Adhérent.
  • Message 4 : L'Adhérent renvoie fournirReference(film) au Système.
  • Message 5 : Le Système s'envoie un message réflexif ou l'envoie au Catalogue : verifierExistence(film).
  • Message 6 : Le Système s'envoie un message réflexif : verifierDisponibilite(cassette).
  • Sous-fragment alt [Film et cassette disponibles]
    • Message 7 : Le Système renvoie un message afficherAccord() à l'Adhérent.
    • Fragment opt [Adhérent confirme]
      • Message 8 : L'Adhérent envoie confirmerDemande() au Système.
      • Message 9 : Le Système effectue un traitement interne (message réflexif) : reserverCassette().
  • Sous-fragment else [Cassette ou film indisponible]
    • Message 10 : Le Système renvoie un message afficherImpossibilite() à l'Adhérent.
• Fragment else [Demande refusée par le contrôleur]
  • Message 11 : Le Contrôleur renvoie un message afficherRefus(raisons) à l'Adhérent.

Note de correction : Assurez-vous d'utiliser des lignes de vie verticales pour chaque entité et de placer les blocs conditionnels (cadres) pour illustrer les conditions de succès ou d'échec.

Exercice 2 - Passage du diagramme d'objets au diagramme de classes

Le diagramme d'objets présenté illustre des instances (PN, N, FN) qui appartiennent toutes à la même classe : la classe Noeud. Le passage au diagramme de classes requiert d'identifier les associations entre les objets de cette même classe, ce que l'on appelle des associations réflexives.

Classe unique

• Nom de la classe : Noeud

Associations réflexives

D'après les liens entre les objets, nous déduisons deux associations qui bouclent sur la classe Noeud :

1. Relation hiérarchique (Parent/Fils) :
   • Le lien entre PN et N indique une relation de parenté.
   • Sur le diagramme de classes, tracez une association réflexive sur la classe Noeud.
   • Rôles : d'un côté est parent, de l'autre est fils.
   • Multiplicités : Un nœud peut avoir zéro ou un parent (0..1) et de zéro à plusieurs fils (0..*).
2. Relation de voisinage :
   • Le lien entre N et FN indique "est voisin". La double mention suggère une relation symétrique.
   • Tracez une seconde association réflexive sur la classe Noeud.
   • Rôle : est voisin.
   • Multiplicités : Un nœud peut avoir de zéro à plusieurs voisins (0..*).

Problème - Gestion des ventes SOCIM

Question 1 - Diagramme de classes

Pour construire le diagramme de classes, nous devons extraire les entités (classes), leurs attributs, et les liens (associations) qui les unissent à partir du texte de l'énoncé.

1. Identification des Classes et de leurs Attributs

• Immeuble
  • nom
  • adresse
• Appartement
  • numero (composé du numéro de l'étage et du numéro dans l'étage)
  • superficie
  • nb_chambres
  • prix_previsionnel
• Client
  • CIN
  • nom
  • prenoms (valeur multiple allant de 1 à 2)
  • adresse
  • telephone
  • profession
• Avocat
  • nom
  • prenom
  • adresse
  • telephones (valeur multiple allant de 1 à 3)
  • num_autorisation
• PromesseVente
  • prix_HT
  • prix_TTC (règle de calcul : prix_HT + (prix_HT × taux_TVA))
  • avance
  • date_signature
• Desistement
  • numero
  • date
  • causes
• ContratVente
  • description_appartement
  • prix_vente
  • type_payement
  • date_signature
• ProcesVerbal
  • date_signature

2. Associations et Multiplicités

• Composition/Agrégation : Immeuble et Appartement. Un immeuble (1) contient un à plusieurs appartements (1..*). Un appartement appartient à un seul immeuble (1).
• Classe d'association : La relation de visite entre Client et Appartement porte des données.
  • Un client (0..*) visite des appartements (0..*).
  • Cette association se résout par une classe d'association Visite contenant les attributs : date, remarques, decision.
• Promesse de vente : C'est une association qui lie un Client (acquéreur), un Appartement et un Avocat.
  • Un client (1) signe une promesse pour un appartement (1) devant un avocat (1).
  • Contrainte stipulée par l'énoncé : l'appartement concerné par la promesse doit avoir été préalablement visité par le client (à noter sous forme de contrainte UML).
  • Contrainte d'intégrité : avance > 20% du prix TTC.
• Désistement : Une PromesseVente (1) peut donner lieu à zéro ou un (0..1) Desistement.
• Contrat de vente : Si la promesse n'est pas annulée, un contrat lie un Client (1), un Appartement (1) et un Avocat (1). L'énoncé précise qu'il est "rédigé par l'avocat et signé par l'acquéreur et le directeur commercial".
• Remise des clés (Procès Verbal) : Un ProcesVerbal concerne un Appartement (1) et un Client (1).

Question 2 - Diagramme d'états-transitions de l'objet APPARTEMENT

Le diagramme d'états-transitions décrit le cycle de vie d'un objet spécifique (l'appartement) en fonction des événements extérieurs.

États et Transitions :

1. État initial : L'appartement est nouvellement créé dans le système.
2. État : Disponible (ou "En Vente")
   • Événement : visite du client. Cet événement ne change pas l'état global de l'appartement qui reste disponible à l'achat pour tout client.
   • Transition : signature_promesse (condition : [avance > 20% TTC]) → Passage à l'état Promis.
3. État : Promis (ou "Sous promesse")
   • Transition 1 : annulation_promesse → Retour à l'état Disponible.
   • Transition 2 : signature_contrat_definitif → Passage à l'état Vendu.
4. État : Vendu
   • Transition : payement_integral ET signature_PV → Passage à l'état Livré (ou "Remis").
5. État final : Livré
   • L'appartement sort du processus de vente de la SOCIM.

Méthode

Face à une épreuve de conception orientée objet (UML), la lecture attentive du texte est votre meilleur atout. Chaque mot a son importance.

• Les noms communs (société, client, appartement) deviennent généralement vos Classes.
• Les adjectifs et informations caractérisant ces noms (numéro, superficie, date) deviennent vos Attributs.
• Les verbes d'action (visiter, annuler, acheter) définissent vos Associations entre les classes ou vos Événements dans un diagramme d'états-transitions.
• Les règles métier (comme "Un client ne peut acheter un appartement qu’après l’avoir visité" ou "L'avance doit être supérieure à 20%") ne doivent pas être ignorées. Si elles ne rentrent pas naturellement dans les cases d'un diagramme, notez-les en toutes lettres à côté, sous forme de "contraintes" UML (souvent notées entre accolades {}). La justesse logique prime toujours sur l'esthétique du schéma.