Examen Principal du 1er Semestre

Questions de réflexion

Question 1 - Ordre d'invocation des services dans un diagramme de cas d'utilisation

Non, il n'est pas possible d'exprimer l'ordre d'invocation des services dans un diagramme de cas d'utilisation. Justification : Le diagramme de cas d'utilisation a pour but de modéliser le "quoi" (les fonctionnalités offertes par le système aux acteurs) et non le "comment" ou le "quand". Il ne possède pas de sémantique temporelle ou de contrôle de flux. Pour exprimer l'ordre chronologique ou l'enchaînement des invocations, il faut utiliser des diagrammes comportementaux dynamiques tels que le diagramme de séquence, le diagramme de communication ou le diagramme d'activités.

Question 2 - Conformité des diagrammes d'objets

Cette question est impossible à traiter. Le document source indique "Soit le diagramme de classes et les trois diagrammes d’objets (1), (2) et (3) suivants :" mais les figures correspondantes sont absentes du texte extrait. Les données d'entrée étant manquantes, il est impossible de vérifier la conformité des instances vis-à-vis du modèle.

Exercice 1 - Diagramme de cas d’utilisation

Question 1 - Identification des acteurs

L'analyse de l'énoncé permet d'identifier les acteurs suivants, qui interagissent directement avec le système :

1. Le Client
   • Type : Acteur principal.
   • Justification : C'est lui qui initie le processus métier central de la machine (retourner des articles pour obtenir un reçu). Le système est conçu en premier lieu pour répondre à son besoin.
2. L'Opérateur
   • Type : Acteur principal (sur ses cas d'utilisation spécifiques).
   • Justification : Il interagit directement avec le système pour déclencher des fonctionnalités qui lui sont propres : la configuration de la machine, le retrait physique des articles et l'impression du reçu global en fin de journée (via le bouton "Init").

(Note : La caisse est mentionnée dans l'énoncé, mais elle n'interagit pas avec le système de récupération modélisé ici. Le reçu est un document papier remis physiquement à la caisse. La caisse n'est donc pas un acteur du système informatique).

Question 2 - Diagramme de cas d'utilisation et descriptions

Puisqu'un rendu graphique n'est pas possible, voici la représentation structurée du diagramme et des relations :

Cas d'utilisation et relations :

• Retourner des articles (Acteur : Client)
  • Contient une relation <<include>> vers Mesurer et identifier l'article.
  • Contient une relation <<include>> vers Imprimer un reçu.
• Clôturer la journée (Acteur : Opérateur)
  • Contient une relation <<include>> vers Imprimer un reçu (il est précisé que le reçu a la même forme).

Configurer les paramètres des articles (Acteur : Opérateur)

Description sommaire des scénarios (en langage naturel) :

• Cas "Retourner des articles" : Le client dépose successivement ses articles acceptés par la machine, puis demande la fin de l'opération pour obtenir le reçu de son dépôt.
• Cas "Mesurer et identifier l'article" : La machine analyse l'article déposé et l'accepte s'il correspond aux dimensions enregistrées, sinon elle le met en lumière jusqu'à ce qu'il soit retiré.
• Cas "Imprimer un reçu" : Le système génère et imprime un ticket récapitulant les types d'articles, quantités, montants unitaires et le total global.
• Cas "Clôturer la journée" : L'opérateur retire les conteneurs pleins et appuie sur le bouton "Init" pour obtenir le récapitulatif total des dépôts de la journée.
• Cas "Configurer les paramètres des articles" : L'opérateur saisit ou modifie les largeurs et hauteurs de référence caractérisant les canettes et les bouteilles acceptables.

Question 3 - Modélisation du cas "Retourner un article"

Choix de la meilleure solution : À ce stade de modélisation (description détaillée d'un cas), le diagramme d'activités est la meilleure solution (bien qu'une description textuelle structurée soit aussi valide). Explication : Le processus "Retourner un article" comporte des boucles explicites (déposer "un par un") et des embranchements conditionnels (Si l'article est accepté / Si l'article n'est pas reconnu). Le diagramme d'activités est un outil visuel parfaitement adapté pour représenter ces flux de contrôle complexes, la synchronisation et les itérations, ce qui est lourd à formuler de manière non ambiguë en langage naturel pur.

Détail du cas d'utilisation avec un formalisme d'activités (transcription textuelle des nœuds et flux) :

1. Nœud initial : Début du retour d'articles.
2. Action : Le client dépose un article.
3. Action (Include) : Le système mesure l'article.
4. Décision : L'article est-il reconnu ?
   • Branche [Oui] :
     • Action : Le système incrémente le total pour ce type.
     • Action : Le système absorbe l'article.
     • Aller à l'étape 5.
   • Branche [Non] :
     • Action : Le système met l'article en lumière.
     • Action : Le client retire l'article non reconnu.
     • Aller à l'étape 5.
5. Décision : Le client a-t-il terminé ?
   • Branche [Non] : Retourner à l'étape 2 (Boucle).
   • Branche [Oui] (Appui sur le bouton "Reçu") : Aller à l'étape 6.
6. Action (Include) : Le système imprime le reçu détaillé et le total global.
7. Nœud final : Fin du cas d'utilisation.

Exercice 2 - Diagramme de séquence

L'énoncé exige de n'utiliser que des échanges synchrones. Dans un diagramme de séquence synchrone, l'émetteur est bloqué en attente de la réponse (ou de la fin de l'exécution de la méthode) par le récepteur.

Voici la représentation séquentielle des messages échangés entre les différentes lignes de vie (objets et acteurs) :

• Lignes de vie (Instances participantes) : :Client, :Vendeur, :OuvrierFleuriste, bf:BonFabrication, c:Composition, f:Facture.

Chronologie des messages synchrones :

1. :Client invoque demanderRenseignements() sur :Vendeur.
2. :Vendeur invoque fournirInformations() sur :Client. (Ou retourne les informations).
3. :Client invoque commanderComposition(choix) sur :Vendeur.
4. :Vendeur invoque create(choix) sur la classe BonFabrication (Message de création, instancie bf:BonFabrication).
5. :Vendeur invoque transmettreBon(bf) sur :OuvrierFleuriste.
   • (Pendant l'exécution de cette méthode par l'ouvrier) :
   • 6. :OuvrierFleuriste invoque getInformations() sur bf:BonFabrication.

7. :OuvrierFleuriste invoque create(infos) sur la classe Composition (Message de création, instancie c:Composition).

8. :OuvrierFleuriste invoque archiverEtDetruire() sur bf:BonFabrication (Aboutit à la destruction de l'objet, symbolisée par une croix X en UML).

9. :OuvrierFleuriste invoque remettreComposition(c) sur :Vendeur.

:Vendeur invoque create(c) sur la classe Facture (Message de création, instancie f:Facture).

:Vendeur invoque remettreFacture(f) sur :Client.

:Client invoque reglerFacture(f) sur :Vendeur.

:Vendeur invoque remettreComposition(c) sur :Client.

:Client quitte le magasin (fin du scénario).

Exercice 3 - Diagramme de classes et diagramme d’états-transitions

Question 1 - Diagramme de classes de conception

Les classes identifiées dans le texte sont Tamagutchi, Horloge, Bip, et implicitement Bouton. Voici la structure du diagramme de classes.

Classes et Méthodes :

Classe	Méthodes déduites de l'énoncé
Tamagutchi	recevoirMiseATable(), recevoirSortieDeTable(), recevoirTempoEcoulee(), pleurer(), mourir()
Horloge	lancerTempo(duree: entier)
Bip	declencherPleurs(), arreterPleurs()
Bouton	appuyer()

Associations (Structure) :

• Tamagutchi - Horloge : Association orientée (ou composition) du Tamagutchi vers l'Horloge. Un Tamagutchi "possède" 1 Horloge. (Multiplicité 1..1)
• Tamagutchi - Bip : Association orientée (ou composition) du Tamagutchi vers le Bip. Un Tamagutchi "possède" 1 Bip. (Multiplicité 1..1)
• Tamagutchi - Bouton : Association orientée. Un Tamagutchi est relié à 2 Boutons (un bouton "a table", un bouton "sortie de table"). (Multiplicité 1..2)

Question 2 - Diagramme d’états-transitions

L'automate possède exactement les 5 états demandés. Conformément à l'énoncé :

• Les événements déclencheurs (Triggers) sur les transitions sont : tempo écoulée, être mis à table, sortir de table.
• Les actions / événements émis (Outputs) déclenchés par les transitions sont : avoir faim, ne plus avoir faim, mourir, ainsi que les appels de méthodes aux composants matériels (lancerTempo, declencherPleurs, arreterPleurs).

Voici la liste exhaustive des transitions modélisant le comportement :

1. Transition de l'état normal vers la faim

• État source : pas faim pleure pas
• Événement déclencheur : tempo écoulée (temps d'autonomie)
• Actions déclenchées : / envoyer vers utilisateur("avoir faim"), bip.declencherPleurs(), horloge.lancerTempo(5 min)
• État cible : faim pleure

Transition de la faim vers la mort (si non nourri à temps)

• État source : faim pleure
• Événement déclencheur : tempo écoulée (5 minutes)
• Actions déclenchées : / envoyer vers utilisateur("mourir"), bip.arreterPleurs()
• État cible : mort (État final)

Transition de la faim vers la restauration

• État source : faim pleure
• Événement déclencheur : être mis à table
• Actions déclenchées : / bip.arreterPleurs(), horloge.lancerTempo(temps de restauration)
• État cible : à table pleure pas

Transition de la restauration vers la satiété (il a fini de manger mais reste à table)

• État source : à table pleure pas
• Événement déclencheur : tempo écoulée (temps de restauration)
• Actions déclenchées : / bip.declencherPleurs(), horloge.lancerTempo(5 min)
• État cible : à table pleure

Transition du mécontentement à table vers la mort (si oublié à table)

• État source : à table pleure
• Événement déclencheur : tempo écoulée (5 minutes)
• Actions déclenchées : / envoyer vers utilisateur("mourir"), bip.arreterPleurs()
• État cible : mort (État final)

Transition du retour à la normale

• État source : à table pleure
• Événement déclencheur : sortir de table
• Actions déclenchées : / envoyer vers utilisateur("ne plus avoir faim"), bip.arreterPleurs(), horloge.lancerTempo(temps d'autonomie)
• État cible : pas faim pleure pas

(Note : L'énoncé indique clairement "Il pleure jusqu'à ce que l'utilisateur le sorte de table". Cela signifie que l'action "sortir de table" intervient lorsque l'animal est dans l'état "à table pleure". Si l'utilisateur tentait de le sortir pendant qu'il mange ("à table pleure pas"), cela constituerait un scénario d'erreur non couvert par la description nominale demandée ici).

Méthode

Pour réussir ce type d'épreuve axée sur UML :

1. Lisez chaque mot de l'énoncé : Les exercices UML en examen fournissent généralement un lexique strict. Lorsque l'exercice 3 liste explicitement les méthodes et les événements à utiliser, tout terme inventé (même pertinent) sera sanctionné.
2. Différenciez le Système de son Environnement : Dans l'exercice 1, la "machine" n'est pas un acteur, c'est le système lui-même. La caisse fait partie de l'environnement physique, mais n'interagit pas informatiquement avec le système de récupération.
3. Tracez les cycles de vie des objets : Dans un diagramme de séquence (Exercice 2), suivez chaque donnée du début à la fin. Un objet créé (BonFabrication) doit agir ou être interrogé avant d'être archivé/détruit.
4. Vérifiez la cohérence temporelle de vos automates : Dans un diagramme d'états-transitions, chaque état temporaire (où l'objet attend ou effectue une action chronométrée) doit posséder une transition sortante déclenchée par l'événement d'horloge. Dans le cas du Tamagutchi, chaque état incluant "pleure" arme un minuteur fatal de 5 minutes qui doit systématiquement mener à l'état "mort".