Analyse et Conception Orientées Objets

Ce document présente une série d'exercices corrigés en Analyse et Conception Orientées Objets portant sur la modélisation dynamique avec UML, notamment les diagrammes de séquence et de classes d'analyse. Il évalue la capacité à représenter des interactions entre objets et à traduire des spécifications fonctionnelles en diagrammes UML pertinents.

Exercice 1 : Modélisation d'une création d'instance

Cet exercice illustre la création et la sauvegarde d'un objet via un diagramme de séquence lorsqu'un message est reçu d'un acteur extérieur.

Analyse des acteurs et objets

• Acteur extérieur : Entité déclenchant l'action.
• Gestionnaire : Objet recevant le message initial.
• Personne : Instance créable et manipulable.

Séquence des messages

1. L'acteur extérieur envoie le message addPersonne au gestionnaire.
2. Le gestionnaire crée une nouvelle instance de la classe Personne.
3. Le gestionnaire assigne le nom et le prénom à cette instance (via des accesseurs de type setNom et setPrenom).
4. Le gestionnaire appelle la méthode enregistrer() sur l'instance Personne.

Dans le diagramme de séquence, cela se traduit par :

• Une ligne de vie pour chaque élément : l'acteur extérieur, le gestionnaire et la personne.
• Un message synchrone addPersonne de l'acteur vers le gestionnaire.
• Un message de création (<<create>>) ciblant l'instance de Personne.
• Les messages d'assignation des attributs envoyés à l'instance.
• Le message enregistrer() exécuté sur l'objet Personne.

Exercice 2 : Système de contrôle de feux tricolores

Cet exercice porte sur la modélisation d'un carrefour à 4 feux tricolores synchronisés selon 4 phases de circulation distinctes, en initialisant le système à la phase 4.

Méthodes et objets impliqués

Le système s'articule autour de deux entités principales :

• Feu tricolore :
  • initialiseFeu(int etatInitial) : Initialise l'état du feu (1-rouge, 2-vert, 3-orange).
  • changeEtat() : Incrémente l'état du feu (1 → 2 → 3 → 1).

Système de contrôle :

• initialiseSystemeDeControle() : Initialise le système dans sa phase de départ (phase 4).
• initialiseFeux() : Appelle l'initialisation de chaque feu selon la phase active.
• changePhase() : Incrémente la phase active (1 → 2 → 3 → 4 → 1).

Séquence des opérations

1. Le système de contrôle exécute initialiseSystemeDeControle() pour se placer en phase 4.
2. Le système appelle initialiseFeux().
3. La méthode initialiseFeux() transmet un message initialiseFeu(etatInitial) à chacun des 4 feux avec l'état correspondant à la phase 4.
4. Lors du passage à la phase suivante, le système exécute changePhase().
5. Le système réinvoque initialiseFeux() ou appelle changeEtat() sur les feux concernés pour actualiser leur état.

Exercice 3 : Étude de cas RapidPizza

L'entreprise RapidPizza souhaite informatiser la gestion de ses commandes, de la préparation et des livraisons réparties sur plusieurs points de vente.

Question 1 : Diagramme de classes d'analyse

Le diagramme d'analyse structure les entités du domaine métier et leurs associations :

• Client : Identifié par numéroTéléphone. Contient également nom et adresse.
• Commande : Identifiée par numéroCommande et caractérisée par un état (en attente, en préparation, en cours de livraison, livrée).
• Plat : Défini par nom et prix (indépendant du point de vente).
• PointPizza : Représente un restaurant proposant un ensemble de plats.
• Collaborateur : Employé de l'entreprise. Possède des spécialisations : Gérant, Coordinateur, Livreur, Préparateur.
• Boîtier : Équipement électronique associé à un collaborateur pour transmettre les états de disponibilité et de livraison.

Associations principales :

• Un Client passe zéro ou plusieurs Commandes.
• Une Commande regroupe une ou plusieurs lignes de commande associant un Plat et une quantité.
• Un PointPizza met à disposition une sélection de Plats.
• Un Gérant affecte les Commandes aux différents PointPizza et répartit les Collaborateurs.

Question 2 : Diagrammes de séquence des cas d'utilisation

Case 1 : Passer une commande

1. Le Client transmet son numéro de téléphone à RapidPizza.
2. Si le client n'est pas enregistré, le système demande son nom et son adresse pour créer la fiche client.
3. Le client sélectionne les plats et les quantités souhaitées.
4. Le système vérifie si la combinaison de plats est réalisable par un même Point Pizza.
5. Si la commande est valide, RapidPizza génère un numéro unique et enregistre la commande ; sinon, la commande est refusée sans être mémorisée.

Case 2 : Notifier l'avancement d'une pizza

1. Le Coordinateur consulte sur RapidPizza la liste des commandes attribuées à son Point Pizza.
2. Lors du démarrage de la préparation d'un plat, il envoie un message de notification d'avancement au système.
3. Une fois le plat terminé, il envoie un nouveau message signalant la fin de la préparation.

Case 3 : Affecter une commande

1. Le Gérant consulte les commandes enregistrées sur RapidPizza.
2. Il sélectionne une commande en attente et choisit le Point Pizza adéquat.
3. RapidPizza met à jour l'affectation de la commande vers le Point Pizza désigné.

Méthode et conseils de modélisation

Pour réussir la modélisation dynamique et statique en UML :

• Identifiez clairement les frontières du système et distinguez les acteurs externes des objets internes.
• Assurez-vous de réutiliser exactement la signature des méthodes fournies dans les énoncés.
• Représentez précisément le cycle de vie des objets (création via <<create>>, destruction, appels réflexifs).
• Vérifiez la cohérence entre le diagramme de classes (structure) et les diagrammes de séquence (dynamique).