Examen de rattrapage en Analyse et Conception Orientées Objet

Questions de réflexion

Question 1 - Différence entre acteur principal et acteur secondaire

Un acteur principal est l'entité (utilisateur ou système externe) qui initie le cas d'utilisation pour atteindre un objectif précis. C'est lui qui déclenche l'interaction avec le système. Un acteur secondaire (ou acteur de support) ne déclenche pas le cas d'utilisation. Il est sollicité par le système lors du déroulement d'un cas d'utilisation pour fournir un service, une information, ou exécuter une action spécifique (par exemple, une base de données externe, un service bancaire ou un système d'authentification tiers).

Question 2 - Différence entre composition, agrégation et héritage

Ces trois concepts définissent la nature des relations entre les classes dans un système orienté objet :

• L'agrégation est une relation d'association asymétrique de type "fait partie de" ou "possède". Elle représente un couplage faible : l'élément contenu peut exister indépendamment de l'élément contenant. Si le contenant est détruit, le contenu survit.
  • Exemple : Une classe Equipe et une classe Joueur. Un joueur fait partie d'une équipe, mais si l'équipe est dissoute, le joueur existe toujours.
• La composition est une forme forte de l'agrégation. Elle implique une coïncidence des durées de vie : l'élément composant n'a de sens qu'au sein de l'élément composite. Si le composite est détruit, ses composants le sont également.
  • Exemple : Une classe Maison et une classe Piece. Si la maison est détruite, ses pièces le sont aussi.
• L'héritage (ou généralisation) est une relation de type "est un". Elle permet de créer une nouvelle classe (classe dérivée ou fille) à partir d'une classe existante (classe de base ou mère). La classe fille hérite des attributs et méthodes de la classe mère et peut les redéfinir ou en ajouter de nouveaux.
  • Exemple : Une classe mère Vehicule et des classes filles Voiture et Moto. Une voiture "est un" véhicule.

Question 3 - Différence entre activité et action

Dans un diagramme d'activité UML :

• Une action est l'unité fondamentale de comportement. Elle est considérée comme atomique, indivisible et son exécution est ininterrompue. Elle représente une étape simple (ex: faire un calcul, appeler une méthode).
• Une activité est un comportement plus complexe qui peut être décomposé en un ensemble d'actions ou de sous-activités. Contrairement à l'action, l'activité n'est pas atomique et son exécution peut prendre du temps ou être interrompue.

Question 4 - Analyse d'un diagramme de séquence

L'image ou le texte descriptif du diagramme de séquence mentionné dans l'énoncé est manquant dans le document source fourni. Les éléments nécessaires (les lignes de vie, les messages, les acteurs) n'étant pas visibles, il est impossible de compléter le tableau des interactions ou de rédiger le scénario en langage naturel.

Exercice 1 : Diagramme de cas d'utilisation

1. Identification et justification des acteurs

Le système de récupération et de mise à jour des informations compte trois acteurs :

1. Personnel (Acteur principal) : Tout employé de l'entreprise qui initie une interaction avec le système pour consulter l'existence d'un produit ou parcourir librement les informations.
2. Ingénieur (Acteur principal) : Un type particulier de personnel ayant des droits étendus. Il initie des interactions pour effectuer des opérations de mise à jour (ajout, retrait, modification) sur les produits dont il est responsable. (Note : L'Ingénieur hérite du Personnel).
3. Système de gestion des personnels (Acteur secondaire) : Il est sollicité par le système étudié (et non l'inverse) lors de la procédure d'authentification approfondie des ingénieurs pour vérifier leur mot de passe.

2. Modélisation du diagramme de cas d'utilisation

Voici la description des éléments du diagramme, suivie de sa représentation sous forme de code PlantUML :

• Cas d'utilisation principaux : "Consulter les produits", "Gérer les produits" (qui peut être spécialisé en Ajout, Retrait, Modification).
• Relations <<include>> : L'énoncé précise que toute consultation nécessite une authentification légère et que toutes les opérations donnent lieu à un enregistrement. On a donc :
  • "Consulter les produits" inclut "S'authentifier (Léger)"
  • "Consulter les produits" inclut "Enregistrer dans le journal"
  • "Gérer les produits" inclut "S'authentifier (Approfondi)"
  • "Gérer les produits" inclut "Enregistrer dans le journal"
• Relations <<extend>> : L'impression est optionnelle. "Imprimer le document" étend donc les cas "Consulter les produits" et "Gérer les produits".

@startuml
left to right direction
skinparam packageStyle rectangle

actor "Personnel" as personnel
actor "Ingénieur" as ingenieur
actor "Système de Gestion\ndes Personnels" as sys_rh

ingenieur -|> personnel

rectangle "Logiciel Textile" {
  usecase "Consulter les produits" as consult
  usecase "Gérer les produits" as maj
  
  usecase "S'authentifier (Léger)" as auth_leg
  usecase "S'authentifier (Approfondi)" as auth_app
  usecase "Enregistrer dans le journal" as log
  usecase "Imprimer les documents" as imprimer
  
  personnel -- consult
  ingenieur -- maj
  
  consult ..> auth_leg : <<include>>
  consult ..> log : <<include>>
  
  maj ..> auth_app : <<include>>
  maj ..> log : <<include>>
  
  auth_app -- sys_rh
  
  imprimer .> consult : <<extend>>
  imprimer .> maj : <<extend>>
}
@enduml

Exercice 2 : Diagramme d'états-transitions

Modélisation du fonctionnement de la montre

Le diagramme doit représenter les états de la montre et les transitions déclenchées par la batterie ou les trois boutons (A, B, C).

• État initial / final : La montre s'arrête si on enlève la batterie ou si elle est épuisée.
• États principaux : Affichage Heure (état de base), Affichage Date.
• États de réglage : Réglage Secondes, Réglage Minutes, Réglage Heures, Réglage Jour, Réglage Mois.
• Transitions d'éclairage : Une action interne "Allumer/Eteindre" (déclenchée par C) est possible dans l'état de fonctionnement normal.

@startuml
[*] --> AffichageHeure : Mise en place batterie

state AffichageHeure {
  AffichageHeure : Bouton C / Basculer l'éclairage
}

state AffichageDate {
  AffichageDate : Bouton C / Basculer l'éclairage
}

AffichageHeure --> AffichageDate : Bouton B
AffichageDate --> AffichageHeure : Bouton B

AffichageHeure --> ReglageSecondes : Bouton A

ReglageSecondes --> ReglageSecondes : Bouton C [ajustement]
ReglageSecondes --> ReglageMinutes : Bouton A

ReglageMinutes --> ReglageMinutes : Bouton C [ajustement]
ReglageMinutes --> ReglageHeures : Bouton A

ReglageHeures --> ReglageHeures : Bouton C [ajustement]
ReglageHeures --> ReglageJour : Bouton A

ReglageJour --> ReglageJour : Bouton C [ajustement]
ReglageJour --> ReglageMois : Bouton A

ReglageMois --> ReglageMois : Bouton C [ajustement]
ReglageMois --> AffichageHeure : Bouton A

ReglageSecondes --> AffichageHeure : Bouton B
ReglageMinutes --> AffichageHeure : Bouton B
ReglageHeures --> AffichageHeure : Bouton B
ReglageJour --> AffichageHeure : Bouton B
ReglageMois --> AffichageHeure : Bouton B

AffichageHeure --> [*] : Batterie enlevée / épuisée
AffichageDate --> [*] : Batterie enlevée / épuisée
ReglageSecondes --> [*] : Batterie enlevée / épuisée
ReglageMinutes --> [*] : Batterie enlevée / épuisée
ReglageHeures --> [*] : Batterie enlevée / épuisée
ReglageJour --> [*] : Batterie enlevée / épuisée
ReglageMois --> [*] : Batterie enlevée / épuisée
@enduml

Exercice 3 : Diagramme de classes + diagramme d'objets

1 - Diagramme de classes

Sur la base de la description, nous pouvons extraire les entités, leurs attributs et leurs relations :

• Agent : nom, poste_telephone.
• Chambre : numero, type (single, double, suite), vue_mer (booléen).
• Client : nom, adresse, telephone, num_cin_passeport.
• Reservation : date_arrivee, date_depart, date_reservation, type_origine (téléphone, fax, mail, sur_place), statut (maintenue, confirmée, annulée).
• Facture : numero.
• Avance (classe abstraite mère) : date_reception, montant.
  • Especes (hérite de Avance).
  • Cheque (hérite de Avance) : num_cheque, banque.
  • Virement (hérite de Avance) : num_compte, banque.

Associations et cardinalités :

• Un Client effectue une ou plusieurs Reservation (1..*). Une Reservation est effectuée par un seul Client (1..1).
• Un Agent gère zéro ou plusieurs Reservation (0..*). Une Reservation est gérée par un seul Agent (1..1).
• Une Reservation réserve une ou plusieurs Chambre (1..). Une Chambre peut faire l'objet de zéro ou plusieurs Reservation au fil du temps (0..).
• Une Reservation est garantie par zéro ou une Avance (0..1). Une Avance concerne une seule Reservation (1..1).
• Une Reservation confirmée génère zéro ou une Facture (0..1). Une Facture concerne une seule Reservation (1..1). (L'agent établit la facture, mais fonctionnellement elle est liée à la réservation).

@startuml
skinparam classAttributeIconSize 0

class Client {
  - nom : String
  - adresse : String
  - telephone : String
  - num_cin_passeport : String
}

class Agent {
  - nom : String
  - poste_telephone : String
}

class Chambre {
  - numero : int
  - type : String
  - vue_mer : boolean
}

class Reservation {
  - date_arrivee : Date
  - date_depart : Date
  - date_reservation : Date
  - type_origine : String
  - statut : String
}

class Facture {
  - numero : int
}

abstract class Avance {
  - date_reception : Date
  - montant : float
}

class Especes {
}

class Cheque {
  - num_cheque : String
  - banque : String
}

class Virement {
  - num_compte : String
  - banque : String
}

Avance <|-- Especes
Avance <|-- Cheque
Avance <|-- Virement

Client "1" -- "1..*" Reservation : effectue >
Agent "1" -- "0..*" Reservation : gère >
Reservation "0..*" -- "1..*" Chambre : réserve >
Reservation "1" -- "0..1" Avance : garantie par >
Reservation "1" -- "0..1" Facture : génère >

@enduml

2 - Diagramme d'objets pour le scénario d'Ali et Salah

Le texte nous donne l'état précis du système aux dates des 4 et 5 novembre, puis après les paiements. Le diagramme capture l'état final du scénario (réservations confirmées, avances payées, factures éditées).

• Agent commun : L'objet Agent (Mohamed) est partagé par les deux réservations.
• Objets d'Ali :
  • Client : Ali
  • Réservation : Téléphone (le 04/11), du 11 au 16/11.
  • Chambre : N° 213 (Single, vue mer).
  • Avance : Virement (payé le lendemain, soit le 05/11). Le montant est de 25% du total (5 nuits × 55d = 275d, donc avance de 68.75d).
  • Facture : N° 1234.
• Objets de Salah :
  • Client : Salah
  • Réservation : Sur place (le 05/11), du 11 au 16/11.
  • Chambre : N° 419 (Single, pas de vue mer).
  • Avance : Espèces (payée sur place le 05/11).
  • Facture : N° 1256.

@startuml
object "mohamed: Agent" as mohamed {
  nom = "Mohamed"
}

object "ali: Client" as ali {
  nom = "Ali"
}

object "salah: Client" as salah {
  nom = "Salah"
}

object "ch213: Chambre" as ch213 {
  numero = 213
  type = "single"
  vue_mer = vrai
}

object "ch419: Chambre" as ch419 {
  numero = 419
  type = "single"
  vue_mer = faux
}

object "resAli: Reservation" as resAli {
  date_arrivee = "11/11/2013"
  date_depart = "16/11/2013"
  date_reservation = "04/11/2013"
  type_origine = "téléphone"
  statut = "confirmée"
}

object "resSalah: Reservation" as resSalah {
  date_arrivee = "11/11/2013"
  date_depart = "16/11/2013"
  date_reservation = "05/11/2013"
  type_origine = "sur place"
  statut = "confirmée"
}

object "virementAli: Virement" as virAli {
  date_reception = "05/11/2013"
  montant = 68.75
}

object "especesSalah: Especes" as espSalah {
  date_reception = "05/11/2013"
  montant = 68.75
}

object "fact1234: Facture" as factAli {
  numero = 1234
}

object "fact1256: Facture" as factSalah {
  numero = 1256
}

' Relations pour Ali
ali -- resAli
mohamed -- resAli
resAli -- ch213
resAli -- virAli
resAli -- factAli

' Relations pour Salah
salah -- resSalah
mohamed -- resSalah
resSalah -- ch419
resSalah -- espSalah
resSalah -- factSalah
@enduml

Méthode

Pour réussir ce type d'examen d'analyse et de conception UML, voici les points fondamentaux à respecter lors de vos révisions et de l'épreuve :

1. Traquer le vocabulaire du domaine : Lors de la modélisation statique (diagramme de classes), soulignez chaque nom (qui deviendra une classe ou un attribut) et chaque verbe (qui deviendra une méthode ou une association) dans le texte de l'énoncé. Ne négligez pas les adjectifs qui qualifient souvent les propriétés (ex: chambre "single", "vue sur mer").
2. Distinguer la généralisation de la spécialisation : Face à des éléments ayant des comportements ou des attributs en commun mais des moyens de traitement différents (comme les types de paiements dans l'exercice 3), ayez le réflexe de créer une classe parente abstraite pour mutualiser ce qui est générique (la date et le montant de l'avance).
3. Inclusion vs Extension : Dans les cas d'utilisation, utilisez <<include>> si l'action B est obligatoire pour que l'action A puisse se terminer (l'authentification avant la mise à jour). Utilisez <<extend>> si l'action B est un comportement optionnel ou alternatif venant greffer une fonctionnalité à l'action A (l'impression du document).
4. Complétude des transitions : Dans un diagramme d'états-transitions, assurez-vous d'avoir prévu un moyen d'entrer dans la machine à états (état initial) et de retourner à l'état de fonctionnement nominal depuis chaque branche de réglage (comme le bouton B qui interrompt le cycle dans l'exercice 2).
5. Ne pas inventer l'invisible : Comme pour la question 4 où la figure manquait, en examen réel, signalez immédiatement l'anomalie au surveillant. Si c'est impossible, écrivez explicitement sur la copie que la résolution dépend d'une donnée manquante, sans essayer d'inventer un diagramme arbitraire.