Analyse et Conception Orientées Objets

Cet examen d'Analyse et Conception Orientées Objets évalue la maîtrise de la modélisation UML, la compréhension des principes de la programmation orientée objet et la conception de systèmes logiciels à travers des cas pratiques.

Exercice 1 : Questions de réflexion

L'encapsulation et la modélisation dynamique constituent des piliers fondamentaux de la conception orientée objet.

1. Définition et mise en œuvre de l'encapsulation

L'encapsulation regroupe les données (attributs) et les traitements (méthodes) au sein d'une même classe tout en masquant la structure interne de l'objet.

Dans une classe, ce principe se traduit par :

• La déclaration des attributs en visibilité privée (private) ou protégée (protected) pour empêcher l'accès direct depuis l'extérieur.
• La mise à disposition de méthodes publiques (dites getters et setters) pour contrôler la lecture et la modification des données.
• La garantie de la cohérence de l'état interne de l'objet, modifiable uniquement via des règles métiers définies dans ses propres méthodes.

2. Utilité des diagrammes d'objets

Les diagrammes d'objets représentent une vue instantanée et concrète des instances de classes à un moment précis de l'exécution du système.

Ils permettent de :

• Visualiser la structure dynamique du système à un instant t.
• Illustrer des exemples de données réelles pour valider les cardinalités et relations définies dans le diagramme de classes.
• Comprendre les liens concrets entre objets lors de l'exécution d'un scénario spécifique.

3. Analyse de scénarios UML

Les diagrammes associés à cette question ne sont pas lisibles dans le document source extrait.

Exercice 2 : Cas d’utilisation et diagramme d’activités

La modélisation des besoins d'un logiciel de gestion des réparations automobiles nécessite la structuration des rôles et des processus métiers.

1. Structuration des cas d'utilisation et acteurs

L'identification des acteurs et des fonctionnalités permet de délimiter le périmètre du système de gestion des réparations.

Acteurs du système :

• Chef d’atelier (Acteur principal) : sollicite directement le logiciel pour créer, suivre et fermer les fiches de réparation.
• Magasinier (Acteur secondaire) : interagit avec le système pour enregistrer l'attribution ou la commande de pièces de rechange.
• Mécaniciens et employés (Acteurs secondaires) : interviennent dans le processus métier en retirant les pièces au magasin.
• Logiciel de gestion des commandes (Acteur secondaire - Système externe) : reçoit les demandes de commande émises lorsque les pièces sont indisponibles.
• Logiciel comptable (Acteur secondaire - Système externe) : importe les fiches de réparation fermées pour générer la facturation.

Cas d'utilisation principaux :

• Créer une fiche de réparation (inclut la recherche de véhicule et la saisie de la demande).
• Saisir un nouveau véhicule (extension en cas d'absence du véhicule dans la base).
• Gérer l'affectation et la commande des pièces de rechange (saisie des pièces fournies ou commandées).
• Fermer une fiche de réparation (validation après essai du véhicule).
• Transférer la fiche pour facturation (export vers le logiciel comptable).

2. Dynamique du cas d'utilisation « Créer une fiche de réparation »

Le diagramme d'activités modélise l'enchaînement logique des opérations effectuées par le chef d'atelier lors de la prise en charge d'un véhicule.

1. Saisie des critères de recherche du véhicule par le chef d'atelier.
2. Consultation des résultats affichés par le logiciel.
3. Sélection de la voiture si elle existe, ou saisie de la fiche du nouveau véhicule dans le cas contraire.
4. Saisie de la date de demande de réparation si le véhicule est sous garantie.
5. Enregistrement obligatoire des dates de réception et de restitution prévues.
6. Sélection de la compagnie d'assurance si les dommages sont pris en charge.
7. Enregistrement final de la fiche de réparation par le système.

Exercice 3 : Conception orientée objet d'un système de location

La conception détaillée d'une agence de location de véhicules combine structures de données, cycle de vie des contrats et interactions entre objets.

1. Analyse du diagramme de classes et contraintes de gestion

L'implémentation efficace des associations exige de définir leur navigabilité et leurs contraintes de structure.

Navigabilité des associations :

Pour restreindre le couplage entre classes, la navigation est rendue unidirectionnelle là où l'accès bilatéral n'est pas requis (par exemple : Contrat vers Client, et Contrat vers Voiture).

Contraintes UML ({ordered}, {addOnly}, {frozen}, {notUnique}) :

• {ordered} (O) : spécifie un ordre strict sur les éléments d'une collection (ex. historique des locations d'un client).
• {addOnly} (A) : autorise uniquement l'ajout de nouvelles associations sans suppression des liens existants.
• {frozen} (F) : interdit toute modification du lien une fois l'association initialisée (ex. le véhicule ou le client associé à un contrat signé).
• {notUnique} (N) : permet à une même instance d'apparaître plusieurs fois dans la collection.

Impact sur le code et choix des structures de données :

• Les contraintes {frozen} suppriment la génération des méthodes de modification (setters) après l'instanciation.
• Une contrainte {ordered} impose l'utilisation d'une structure ordonnée de type List (ex. ArrayList).
• Une association multiple standard sans doublon privilégiera l'usage d'un ensemble de type Set (ex. HashSet).

Déclaration de la méthode de location :

Dans la classe Location_de_vehicule, la méthode se définit par la signature suivante :

louer_voiture(client: Client, modele: Modele, dateDebut: Date, duree: int): Contrat

L'ordre de navigation consiste à interroger le modèle pour identifier une voiture disponible sur la période, instancier l'objet Contrat, puis rattacher ce contrat au client et à la voiture sélectionnée.

2. Cycle de vie de la classe Contrat

Le diagramme d'états-transitions décrit les changements d'état successifs d'un contrat de location au fil des événements métiers.

• Projet : état initial lors de la génération automatique de la proposition de contrat au format PDF.
• Préaccord : atteint lorsque le client valide les conditions initiales. Le contrat peut retourner à l'état Projet en cas de modification.
• Annulé : état final atteint si le contrat est annulé avant la signature.
• Signé : formalisation de l'accord à l'agence entre le client et la direction.
• Applicable : le jour de la location, lors de la remise des clés et de l'enregistrement du kilométrage initial.
• Terminé : état final clôturant le contrat au retour du véhicule, déclenchant le calcul du prix selon la formule : (prixKilometre * kilometres_parcourus) + (prixJournalier * duree_reelle).

3. Diagramme de séquences d'un scénario de location

Le scénario nominal décrit les échanges de messages synchrones entre les composants lors d'une location complète.

Objets impliqués :

• :SiteWeb
• :Client
• :Contrat
• :Voiture
• :Directeur
• :AgentAccueil
• :AgentComptable

Enchaînement des messages et méthodes requises :

1. Le client émet une demande via demanderLocation() sur le composant SiteWeb.
2. Le système vérifie la disponibilité et exécute creerProjet() pour instancier le Contrat.
3. Le client confirme via accepterContrat(), faisant passer l'état à Préaccord.
4. Le Directeur valide la transaction via signerContrat().
5. Le jour du départ, l'AgentAccueil appelle enregistrerDepart(kmInitial, date) sur le contrat.
6. Au retour du véhicule, l'AgentAccueil appelle enregistrerRetour(kmFinal).
7. L'AgentComptable clôture l'opération en exécutant gournerFacture() pour calculer le montant dû.

Méthode

La réussite d'une épreuve de conception orientée objet repose sur une méthodologie rigoureuse de modélisation UML.

• Identifier clairement les frontières du système pour séparer les acteurs internes des systèmes externes.
• Vérifier la cohérence entre le diagramme de classes (statique) et le diagramme d'états-transitions (dynamique).
• Adapter la visibilité et la navigabilité des associations pour respecter le principe d'encapsulation et limiter le couplage.
• Assurer que chaque message représenté dans un diagramme de séquences correspond à une méthode explicitement déclarée dans la classe destinataire.