Examen - Analyse et Conception Orientées Objet

Partie 1 : Expression des besoins

Question 1.1 - Identification des acteurs

L'objectif de cette question est de distinguer les entités externes (qui interagissent avec le système) des concepts internes au système (qui seront modélisés sous forme de classes).

Noms	Type	Justifications
a. Patient	Acteur (Principal)	Interagit indirectement ou directement avec le système (ex: pour prendre un rendez-vous, payer).
b. Administrateur	Acteur (Principal)	Utilisateur gérant le paramétrage et les accès du système.
c. Horaire	Non retenu	Concept temporel ou donnée. Ce n'est pas une entité active qui interagit avec le système.
d. Réceptionniste	Acteur (Principal)	Utilisateur clé qui interagit avec le système pour l'accueil et l'inscription des patients.
e. Dossier administratif	Non retenu	C'est une donnée du système (une classe d'objets), pas un utilisateur externe.
f. Dossier médical	Non retenu	Idem, c'est une information gérée par le système (classe), pas un acteur.
g. Personnel médical	Acteur (Principal)	Utilisateur du système (médecins, infirmiers) pour consulter ou mettre à jour les dossiers.
h. Le médecin traitant	Non retenu (ou Acteur)	Généralement, c'est un rôle spécifique du "Personnel médical". Il peut être considéré comme acteur si ses privilèges sont très distincts, mais il fait doublon avec "Personnel médical".
i. Le médecin attribué	Non retenu	C'est une instance ou un lien logique entre un patient et un médecin, pas une classe d'acteur externe indépendante.
j. Le comptable	Acteur (Principal)	Utilisateur manipulant le système pour l'édition et le paiement des factures.
k. Assureur	Acteur (Secondaire)	Entité externe (système tiers ou organisme) sollicitée par notre système pour les prises en charge ou vérifications.

Question 1.2 - Diagramme de cas d'utilisation

Note de correction : Le sujet original demande de compléter un diagramme sur la feuille. Voici la description textuelle des éléments attendus dans un tel diagramme UML.

a) Choix de 5 cas d'utilisation pertinents :

1. S'inscrire (ou Inscrire administrativement le patient)
2. Attribuer un médecin pour un patient
3. Consulter le dossier médical
4. Créer facture
5. Payer facture

b) Acteurs et relations avec les cas :

• Réceptionniste est relié à : "Recevoir des patients", "Inscrire administrativement le patient", "Attribuer un médecin pour un patient".
• Personnel médical est relié à : "Consulter le dossier médical".
• Comptable est relié à : "Éditer des factures", "Créer facture", "Payer facture".
• Assureur (Acteur secondaire) est relié à : "Éditer des factures" ou "Payer facture" (pour la part prise en charge).

c) Relations entre les cas d'utilisation (include / extend) :

• Le cas "Recevoir des patients" possède une relation <<include>> vers "Inscrire administrativement le patient" (si chaque réception nécessite une inscription ou vérification) ou <<extend>> si l'inscription n'est faite que pour les nouveaux patients.
• Le cas "Éditer des factures" possède une relation <<include>> vers "Créer facture".
• Le cas "Payer facture" possède une relation <<extend>> vers "Éditer des factures" (le paiement est une extension possible suite à l'édition).

Question 1.3 - Scénarios du cas "recevoir des patients"

• Nominal : Le patient se présente à la réception. Le réceptionniste l'identifie dans le système SISP. Le système affiche le dossier du patient. Le réceptionniste confirme la présence et lui attribue une salle d'attente ou un médecin disponible. Le système enregistre l'arrivée.
• Alternatif : Le patient se présente mais n'a pas de dossier dans le système (nouveau patient). Le réceptionniste crée un nouveau dossier administratif (déclenchement de l'inscription). Une fois le dossier créé, le scénario nominal reprend à l'étape d'attribution du médecin.
• Exceptionnel : Le patient se présente, mais le système signale que la carte d'identité est invalide ou que le patient est suspendu pour défaut de paiement. Le réceptionniste ne peut pas valider la réception, le processus s'interrompt et le patient est invité à régulariser sa situation.

Question 1.4 - Diagramme d'activités pour "éditer des factures"

Note de correction : En l'absence de rendu graphique, voici la structure séquentielle attendue pour ce diagramme d'activités.

1. Nœud initial (point noir).
2. Activité : "Rechercher le dossier du patient".
3. Activité : "Récupérer la liste des interventions médicales non facturées".
4. Activité : "Calculer le montant total".
5. Décision (Losange) : Le patient a-t-il un assureur ?
   • Branche [Oui] -> Activité : "Calculer la part de l'assureur et la part patient".
   • Branche [Non] -> Activité : "Affecter le montant total à la charge du patient".
6. Fusion (Losange) : Regroupement des deux branches.
7. Activité : "Générer le document de facturation".
8. Activité : "Enregistrer la facture avec le statut 'En attente'".
9. Nœud final (point noir encerclé).

Partie 2 : Analyse

Question 2.1 et 2.2 - Complétion du diagramme de classes

Note de correction : Le document source ne contient pas l'image du diagramme de classes incomplet ("le diagramme de classes suivant"). Par conséquent, il est impossible de fournir les cardinalités, attributs et méthodes exacts attendus pour ce schéma spécifique. Voici cependant la logique qui devrait être appliquée lors de l'examen :

• Pour les cardinalités (2.1) : Vous devez identifier les règles métier. Par exemple, entre Patient et DossierMedical, la cardinalité est généralement 1..1 des deux côtés (un patient a exactement un dossier). Entre Facture et Intervention, une facture contient 1..* (une ou plusieurs) interventions, et une intervention figure sur 0..1 ou 1..1 facture.
• Pour les attributs et méthodes (2.2) :
  • Classe Patient : Attributs (nom, prenom, dateNaissance, adresse), Méthodes (mettreAJourInfos()).
  • Classe Facture : Attributs (numeroFacture, dateEmission, montantTotal, statut), Méthodes (calculerMontant(), editer()).
  • Classe DossierMedical : Attributs (numeroDossier, antecedents), Méthodes (ajouterIntervention()).

Question 2.3 - Diagramme d'états-transitions pour une facture

Les états attendus pour une instance de la classe Facture sont les suivants :

1. État initial -> Transition : création -> État : En cours de création (ou Brouillon).
2. État : En cours de création -> Transition : validation -> État : À payer (ou Émise).
3. État : À payer -> Transition : paiement partiel reçu -> État : Partiellement payée.
4. État : À payer (ou Partiellement payée) -> Transition : paiement total reçu -> État : Payée.
5. État : À payer -> Transition : annulation -> État : Annulée.
6. État : Payée / État : Annulée -> État final.

Partie 3 : Conception

Question 3.1 - Sens de navigation

Note de correction : Comme pour la question 2.1, la portion de diagramme est absente du sujet numérisé. Le principe d'une navigation limitée est de restreindre la visibilité entre les objets pour réduire le couplage.

• Exemple attendu : Entre Facture et Intervention, la navigation va logiquement de Facture vers Intervention (la facture connaît les interventions qu'elle facture, mais l'intervention n'a pas nécessairement besoin de connaître la facture, ou alors de façon dérivée). On dessinerait une flèche ouverte vers Intervention.

Question 3.2 - Contraintes de gestion sur les associations

a. Signification des contraintes :

• Ordered : Les éléments de la collection côté multiple de l'association sont ordonnés (ex: triés par date ou selon un critère spécifique d'insertion).
• AddOnly : Une fois la collection initialisée, on peut y ajouter de nouveaux objets, mais on ne peut ni les retirer ni les modifier.
• Frozen : L'association (le lien) est figée dès sa création. Une fois qu'un objet est lié à un autre, ce lien ne peut plus être modifié, ajouté ou supprimé durant toute la durée de vie de l'objet.
• NotUnique : Utilisé pour indiquer qu'un même élément peut apparaître plusieurs fois dans la collection (comportement d'un "Bag" ou "Multi-ensemble" plutôt que d'un "Set").

b. Décoration du diagramme : Faute de diagramme visuel, voici une application justifiée hypothétique :

• Association Facture -> Intervention :
  • Contrainte : (F)rozen ou (A)ddOnly.
  • Justification : Une fois la facture validée et émise, on ne doit plus pouvoir retirer ou modifier les interventions facturées pour des raisons légales et comptables. L'ordre peut aussi avoir du sens : (O)rdered par date d'intervention.

Question 3.3 - Choix d'une collection pour "Facture-Intervention"

Choix proposé : Tableau dynamique (ex: ArrayList en Java). Justification : Le nombre d'interventions par facture n'est pas connu à l'avance (ce qui exclut un tableau statique). Les accès aux éléments d'une facture pour calculer le total se font de manière séquentielle, et on a rarement besoin de supprimer des éléments au milieu de la liste (surtout si la règle métier est AddOnly/Frozen). Le tableau dynamique offre d'excellentes performances d'itération et une occupation mémoire optimisée comparée aux listes chaînées.

Question 3.4 - Impact des contraintes sur les méthodes

Si la relation Facture -> Intervention est contrainte par {frozen} ou {addOnly} :

• La classe Facture possédera une méthode getInterventions() pour la lecture.
• Elle possédera une méthode addIntervention(i : Intervention) (si {addOnly}) ou exigera que les interventions soient passées au constructeur (si {frozen}).
• Elle ne possédera pas de méthode removeIntervention(i : Intervention) ni de méthode setInterventions(liste). Cela garantit l'intégrité de la conception orientée objet vis-à-vis des règles métier.

Question 3.5 - Diagramme de séquence pour l'émission de la facture

Description textuelle des messages synchrones échangés :

1. Comptable envoie editerFacture(patientX) à l'objet Systeme (ou ControleurFacturation).
2. Systeme envoie getDossierAdministratif() à l'objet PatientX (de classe Patient).
3. PatientX retourne le dossier.
4. Systeme envoie une requête getInterventionsNonFacturees() au dossier (ou au gestionnaire d'interventions).
5. Le système crée une nouvelle instance : Systeme envoie new(patientX, interventions) à la classe Facture.
6. Facture calcule son montant en envoyant une boucle getPrix() à chaque objet Intervention.
7. Facture se retourne (retour de création).
8. Systeme envoie payerTotalite() à la Facture créée.
9. Facture met à jour son statut (devient 'Payée').
10. Systeme affiche la facture au Comptable.

Méthodes à ajouter au diagramme de classes (si non présentes) :

• Patient::getDossierAdministratif()
• Dossier::getInterventionsNonFacturees()
• Facture::calculerTotal()
• Facture::payerTotalite()
• Intervention::getPrix()

Question 3.6 - Révision du diagramme pour des questions de confidentialité

Le développeur a-t-il raison ? Oui. Justification : Si le diagramme actuel regroupe toutes les informations (administratives et médicales) dans une seule et même classe Patient ou n'isole pas les dossiers, il est impossible, au niveau de la conception structurelle, de définir des droits d'accès distincts (principe de responsabilité unique et d'encapsulation bafoué). Modifications à apporter : Il faut décomposer les informations du patient. La classe Patient (ou un acteur) devrait être liée à deux classes distinctes :

1. Une classe DossierAdministratif (accessible au package/classes du personnel administratif).
2. Une classe DossierMedical (accessible uniquement au package/classes du personnel médical). Cette ségrégation des données en classes séparées permet de contrôler l'accès via les modificateurs de visibilité, l'architecture en packages, ou le Pattern Proxy pour le contrôle d'accès.

Méthode

Pour réussir ce type d'examen d'Analyse et Conception Orientées Objet (ACOO) :

1. Lecture croisée : Lisez toujours l'intégralité du sujet avant de commencer. Les questions de conception (Partie 3) donnent souvent des indices majeurs sur les diagrammes incomplets de la phase d'analyse (Partie 2).
2. Définition stricte des Acteurs : Un acteur n'est jamais le système lui-même, ni un composant interne, ni une donnée (comme un Dossier). C'est une entité externe (humain, autre logiciel, matériel externe) qui initie ou reçoit une action.
3. Absence de support visuel : Face à une question faisant référence à un diagramme manquant (erreur d'impression courante ou sujet partiel), écrivez explicitement vos hypothèses et expliquez la règle théorique. Le correcteur évaluera votre compréhension du concept.
4. Cohérence : Les méthodes que vous invoquez dans le diagramme de séquence (Question 3.5) doivent impérativement exister dans votre diagramme de classes de la phase d'analyse. C'est l'erreur la plus sanctionnée : imaginer des opérations dynamiques qui n'ont aucun support structurel.