Examen de rattrapage en Analyse et Conception Orientées Objet

Questions de réflexion

Question 1 - Acteur principal et acteur secondaire

Un acteur principal est une entité externe (utilisateur humain ou système) qui utilise le système pour atteindre son propre but. Il est à l'origine du déclenchement du cas d'utilisation (ex: un client qui retire de l'argent). Un acteur secondaire (ou acteur de support) est une entité externe sollicitée par le système pour l'aider à réaliser un cas d'utilisation et accomplir un service (ex: le système bancaire externe ou une base de données d'authentification).

Question 2 - Composition, agrégation et héritage

• Héritage (Généralisation) : C'est une relation de type "est un". Une classe enfant hérite des attributs et méthodes d'une classe parent.
  • Exemple : Une Voiture et un Camion héritent de la classe Véhicule.
• Agrégation : C'est une relation de type "a un" ou "fait partie de", mais faible. Le cycle de vie du composant est indépendant de celui du composite. Si le composite est détruit, le composant peut continuer à exister.
  • Exemple : Un Professeur et un Département. Si le département est fermé, le professeur existe toujours.
• Composition : C'est une relation de type "a un" forte. Le cycle de vie du composant est lié à celui du composite. Le composant ne peut exister sans le composite.
  • Exemple : Un Mur et une Maison. Si la maison est détruite, le mur l'est également.

Question 3 - Activité et action

Dans un diagramme d'activité, une action est l'unité fondamentale de comportement. Elle est atomique, c'est-à-step indivisible, et ne peut pas être décomposée en sous-étapes. Une activité est un comportement complexe modélisé par un graphe de nœuds. Contrairement à l'action, l'activité est décomposable : elle peut être interrompue et peut contenir d'autres activités ou de multiples actions.

Question 4 - Analyse du diagramme de séquence

L'image du diagramme de séquence est manquante dans le document source fourni. Il est par conséquent impossible de résoudre cette question avec exactitude. Les réponses ci-dessous indiquent ce qui est attendu en présence de l'image.

a. Tableau des interactions En l'absence du diagramme, les acteurs, objets et messages ne peuvent pas être recensés.

b. Scénario en langage naturel En l'absence du diagramme, le scénario ne peut pas être retranscrit.

Exercice 1 : Diagramme de cas d’utilisation

Question 1 - Acteurs du système

1. Le Personnel : Acteur principal. Il interagit avec le système de son propre chef pour vérifier l'existence d'un produit ou parcourir librement les informations.
2. L'Ingénieur : Acteur principal. C'est un type d'utilisateur spécifique qui déclenche les opérations de mise à jour des produits. (Il peut être modélisé comme héritant de l'acteur Personnel).
3. Le Système de gestion des personnels : Acteur secondaire. Il est sollicité par le système de récupération pour vérifier le mot de passe lors de l'authentification approfondie des ingénieurs.

Question 2 - Représentation du diagramme de cas d'utilisation

Voici la modélisation sous forme textuelle des relations devant apparaître sur le diagramme :

Cas d'utilisation et relations :

• Consulter le système (Acteur associé : Personnel)
  • Relation <<include>> vers le cas S'authentifier (légère).
  • Relation <<include>> vers le cas Enregistrer accès (journal).
  • Relation <<extend>> depuis le cas Imprimer documents (optionnel).
• Mettre à jour les produits (Acteur associé : Ingénieur)
  • Ce cas généralise les sous-cas "Ajouter un produit", "Retirer un produit", "Modifier un produit".
  • Relation <<include>> vers le cas S'authentifier (approfondie).
  • Relation <<include>> vers le cas Enregistrer accès (journal).
  • Relation <<extend>> depuis le cas Imprimer documents (optionnel).
• S'authentifier (approfondie)
  • Acteur associé (secondaire) : Système de gestion des personnels.

(Note : L'acteur "Ingénieur" hérite de l'acteur "Personnel", ce qui lui donne également accès au cas "Consulter le système").

Exercice 2 : Diagramme d’états-transitions

Voici les états et les transitions modélisant le comportement de la montre digitale.

États principaux :

• Arrêt (État initial ou état suite à une perte de batterie)
• Affichage Heure
• Affichage Date
• Réglage Secondes
• Réglage Minutes
• Réglage Heures
• Réglage Jour
• Réglage Mois

Le rétroéclairage (bouton C) peut être modélisé comme une action interne ou un état orthogonal Éclairage [Allumé / Éteint] indépendant des états ci-dessus.

Tableau des transitions :

État Source	Événement (Déclencheur)	État Cible
(Tout état)	Enlever batterie ou batterie épuisée	Arrêt
Arrêt	Insérer batterie (chargée)	Affichage Heure
Affichage Heure	Appui bouton A	Réglage Secondes
Réglage Secondes	Appui bouton A	Réglage Minutes
Réglage Minutes	Appui bouton A	Réglage Heures
Réglage Heures	Appui bouton A	Réglage Jour
Réglage Jour	Appui bouton A	Réglage Mois
Réglage Mois	Appui bouton A	Affichage Heure
Réglage (tous les états)	Appui bouton B	Affichage Heure
Affichage Heure	Appui bouton B	Affichage Date
Affichage Date	Appui bouton B	Affichage Heure
Réglage (tous les états)	Appui bouton C prolongé / répété	Maintien dans le même état (Action : Ajustement de la valeur)
(Tout état de marche)	Appui bouton C (court)	Maintien dans le même état (Action : Bascule Allumer/Éteindre l'écran)

Exercice 3 : Diagramme de classes et diagramme d’objets

Question 1 - Diagramme de classes

Voici la liste des classes, leurs attributs et les associations qui les relient.

Classes et Attributs :

• Hôtel : pas strictement nécessaire si le système est développé pour un seul hôtel, mais utile si on gère un groupe.
• Chambre
  • numero : Entier
  • type : Chaine (single, double, suite)
  • vueSurMer : Booléen
• AgentReception
  • nom : Chaine
  • posteTelephone : Chaine
• Client
  • nom : Chaine
  • adresse : Chaine
  • telephone : Chaine
  • numPieceIdentite : Chaine
• Reservation
  • dateReservation : Date
  • dateArrivee : Date
  • dateDepart : Date
  • canal : Chaine (téléphone, fax, mail, sur place)
  • etat : Chaine (maintenue, confirmée, annulée)
• Facture
  • numero : Entier
• Avance (Classe mère ou abstraite)
  • dateReception : Date
  • montant : Réel

AvanceCheque (Hérite de Avance)

• numCheque : Chaine
• banque : Chaine

AvanceVirement (Hérite de Avance)

• numCompte : Chaine
• banque : Chaine

AvanceEspece (Hérite de Avance)

Associations et Cardinalités :

1. Effectuer : Client "1" <---> "1..*" Reservation (Un client effectue au moins une réservation pour exister dans le système en tant que tel, une réservation appartient à un seul client).
2. Gérer : AgentReception "1" <---> "0..*" Reservation (Une réservation est gérée par un et un seul agent, un agent peut gérer plusieurs réservations).
3. Concerner : Reservation "0.." <---> "1.." Chambre (Une chambre peut être concernée par de multiples réservations à des dates différentes, une réservation concerne au moins une chambre).
4. Engendrer : Reservation "1" <---> "0..1" Facture (Une réservation confirmée donne lieu à une facture).
5. Garantir : Reservation "1" <---> "0..1" Avance (Une réservation peut être garantie par au maximum une avance financière).

Question 2 - Diagramme d'objets

Le diagramme d'objets capture une photographie du système à un instant T (ici, après que Salah ait payé son avance). Voici la description des instances (objets) et de leurs liens.

Objets (Instances) :

• ali : Client (nom="Ali", numPieceIdentite="...")
• salah : Client (nom="Salah", numPieceIdentite="...")
• mohamed : AgentReception (nom="Mohamed", posteTelephone="...")
• ch213 : Chambre (numero=213, type="single", vueSurMer=Vrai)
• ch419 : Chambre (numero=419, type="single", vueSurMer=Faux)
• resAli : Reservation (canal="téléphone", dateReservation=04/11/2013, dateArrivee=11/11/2013, dateDepart=16/11/2013, etat="confirmée")
• resSalah : Reservation (canal="sur place", dateReservation=05/11/2013, dateArrivee=11/11/2013, dateDepart=16/11/2013, etat="confirmée")
• fact1234 : Facture (numero=1234)
• fact1256 : Facture (numero=1256)
• avanceAli : AvanceVirement (montant=68.75, dateReception=05/11/2013) (Note : 25% de 5 nuitées à 55d)
• avanceSalah : AvanceEspece (montant=68.75, dateReception=05/11/2013)

Liens entre les instances :

• ali effectue resAli
• salah effectue resSalah
• mohamed gère resAli
• mohamed gère resSalah
• resAli concerne ch213
• resSalah concerne ch419
• resAli engendre fact1234
• resSalah engendre fact1256
• resAli garantie par avanceAli
• resSalah garantie par avanceSalah

Méthode

Pour aborder ce type d'épreuve de conception orientée objet (UML), la rigueur de lecture est votre meilleur atout :

1. Identifier les rôles (Cas d'utilisation) : Cherchez toujours "qui" déclenche l'action à l'extérieur du système pour trouver les acteurs principaux, et "à qui" le système fait appel pour trouver les acteurs secondaires.
2. Reconnaître les relations spécifiques : Les verbes comme "doit toujours inclure", "doit être précédée" pointent vers des relations <<include>>. Les termes "optionnellement", "peut" pointent vers des <<extend>>.
3. Extraction des classes : Surlignez les noms communs dans l'énoncé (ex: client, réservation, avance, facture). Ils deviennent vos classes.
4. Héritage ou attribut ? Si le texte mentionne que le comportement change selon le type, ou que certaines données sont exclusives à un type (comme le nom de la banque et le numéro de compte vs chèque), il faut privilégier l'héritage (polymorphisme), comme c'est le cas pour la classe Avance.
5. Vérification du diagramme d'objets : Un diagramme d'objets (ou d'instances) doit être strictement compatible avec votre diagramme de classes. Toutes les instances doivent obéir aux cardinalités définies à l'exercice précédent. N'inventez pas de nouveaux attributs à ce stade.