Feuilles de réponses -Examen- Analyse et Conception Orientées Objet

Ce document présente un examen d’Analyse et Conception Orientées Objet, visant à évaluer les compétences en modélisation des besoins, analyse et conception d’un système de gestion de publication dans une revue scientifique. Les questions portent sur la construction de diagrammes UML, la description de scénarios, ainsi que la réflexion sur les règles de gestion et l’implémentation des associations.

Exercice 1 : Modélisation des besoins

Il s'agit de compléter un diagramme de cas d’utilisation pour l’application « Publication_dans_revue » en ajoutant six cas d’utilisation pertinents, en identifiant les acteurs, et en reliant les cas par des liens « include » ou « extend » si nécessaire.

Étape 1 : Identifier les cas d’utilisation à ajouter parmi la liste proposée :

• Déclarer l’intention de soumettre
• Modifier un article
• Choisir trois évaluateurs
• Retirer un article
• Déposer une révision
• Enregistrer la décision des auteurs
• Prendre une décision
• Prendre une décision transmise au correspondant
• Demander une nouvelle évaluation aux évaluateurs
• Enregistrer la date de début de l’évaluation

Choix possible des six cas d’utilisation les plus pertinents :

• Déclarer l’intention de soumettre
• Modifier un article
• Choisir trois évaluateurs
• Déposer une révision
• Prendre une décision
• Demander une nouvelle évaluation aux évaluateurs

Étape 2 : Identifier les acteurs :

• Auteur (soumet un article, déclare l’intention, modifie un article, dépose une révision)
• Évaluateur (évalue un article, reçoit une demande d’évaluation, peut être choisi)
• Éditeur (prend une décision, choisit les évaluateurs, demande une nouvelle évaluation)
• Auteur correspondant (reçoit la décision transmise)

Étape 3 : Relier les acteurs aux cas d’utilisation :

• L’auteur est lié à « Soumettre un article », « Déclarer l’intention de soumettre », « Modifier un article », « Déposer une révision »
• L’évaluateur est lié à « Évaluer un article » (cas implicite), « Demander une nouvelle évaluation »
• L’éditeur est lié à « Affecter un article à un évaluateur », « Choisir trois évaluateurs », « Prendre une décision », « Demander une nouvelle évaluation »
• L’auteur correspondant est lié à « Prendre une décision transmise au correspondant »

Étape 4 : Relier les cas d’utilisation entre eux :

• « Soumettre un article » inclut « Déclarer l’intention de soumettre »
• « Affecter un article à un évaluateur » inclut « Choisir trois évaluateurs »
• « Prendre une décision » peut être étendu par « Prendre une décision transmise au correspondant »
• « Demander une nouvelle évaluation aux évaluateurs » peut être un cas étendu de « Prendre une décision »

Réponse finale : Le diagramme complété comporte les six cas d’utilisation choisis, les acteurs identifiés, et les liens « include » et « extend » précisés comme ci-dessus.

Exercice 2 : Scénarios pour « Affecter un article à un évaluateur »

Il s'agit de décrire trois variantes de scénarios (nominal, alternatif, exceptionnel) pour le cas d’utilisation « Affecter un article à un évaluateur » en langage naturel.

Scénario nominal :

L’éditeur sélectionne un article soumis, choisit un évaluateur qui n’est ni auteur ni affilié à la même institution que les auteurs, et lui assigne l’article pour évaluation. L’évaluateur accepte la mission et commence l’évaluation.

Scénario alternatif :

L’éditeur choisit un évaluateur initial, mais celui-ci décline la mission. L’éditeur sélectionne alors un autre évaluateur disponible et lui assigne l’article.

Scénario exceptionnel :

Aucun évaluateur disponible ne peut être assigné car tous sont soit auteurs, soit affiliés à la même institution, ou indisponibles. L’éditeur doit alors demander une nouvelle évaluation ou reporter la décision.

Réponse finale : Les trois scénarios sont décrits comme ci-dessus, illustrant les cas normal, alternatif et exceptionnel.

Exercice 3 : Diagramme d’activités pour « Soumettre un papier »

Il s'agit de proposer un diagramme d’activités illustrant la dynamique du cas d’utilisation « Soumettre un papier ».

Étapes principales du diagramme d’activités :

• Début
• Déclarer l’intention de soumettre
• Rédiger ou modifier l’article
• Soumettre l’article
• Recevoir confirmation de soumission
• Fin

Transitions :

• De « Début » à « Déclarer l’intention de soumettre »
• De « Déclarer l’intention de soumettre » à « Rédiger ou modifier l’article »
• De « Rédiger ou modifier l’article » à « Soumettre l’article »
• De « Soumettre l’article » à « Recevoir confirmation de soumission »
• De « Recevoir confirmation de soumission » à « Fin »

Des décisions peuvent être ajoutées pour gérer des cas où la soumission est refusée ou nécessite une modification.

Réponse finale : Le diagramme d’activités suit les étapes ci-dessus, illustrant clairement la séquence des actions pour soumettre un papier.

Exercice 4 : Analyse du diagramme de classes

Il s'agit de compléter un diagramme de classes incomplet en précisant les cardinalités manquantes et en identifiant les associations pouvant être des compositions ou agrégations.

Étape 1 : Cardinalités à préciser :

• Par exemple, un article peut avoir plusieurs auteurs (cardinalité 1..*), un auteur peut soumettre plusieurs articles (0..*)
• Un article est associé à un éditeur (1..1)
• Un article peut être évalué par plusieurs évaluateurs (0..*)

Étape 2 : Composition ou agrégation :

• La relation entre un article et ses auteurs est une agrégation car les auteurs existent indépendamment de l’article.
• La relation entre la revue et l’éditeur peut être une composition si l’éditeur est spécifique à la revue.
• La relation entre article et mots-clés peut être une agrégation.

Réponse finale : Le diagramme de classes est complété avec les cardinalités et les associations annotées comme composition ou agrégation selon la nature des relations.

Exercice 5 : Représentation des informations spécifiques dans le diagramme de classes

Il s'agit de représenter dans le diagramme de classes les informations suivantes :

• a) L’auteur qui gère la soumission pour ses coauteurs est appelé le correspondant.
• b) Les évaluateurs sont des chercheurs reconnus, auteurs d’articles et livres de référence.
• c) Les mots clés sont choisis parmi une liste définie par l’éditeur et sauvegardée dans le système.

Étape 1 : Représentation de l’auteur correspondant :

• Ajouter un rôle « correspondant » à la classe Auteur, avec une association indiquant qu’un article a un auteur correspondant unique.

Étape 2 : Représentation des évaluateurs :

• La classe Évaluateur hérite de la classe Chercheur, qui elle-même peut hériter de Auteur, indiquant que les évaluateurs sont des chercheurs reconnus.

Étape 3 : Représentation des mots clés :

• Créer une classe MotClé avec une association vers Editeur, indiquant que les mots clés sont définis et sauvegardés par l’éditeur.
• Associer MotClé à Article par une relation multiple.

Réponse finale : Le diagramme de classes est enrichi avec un rôle correspondant pour Auteur, une hiérarchie pour Évaluateur/Chercheur/Auteur, et une association entre MotClé et Editeur.

Exercice 6 : Diagramme d’objets illustrant une situation donnée

Il s'agit de construire un diagramme d’objets illustrant la situation suivante :

Un groupe de trois auteurs « B. Ali », « S. Mohamed » et « N. Ben Saleh » ont soumis leur article long intitulé « contribution au monitoring des systèmes » (B. Ali est l’auteur correspondant) à la revue « revue_informatique » ayant comme éditeur « M. E » le 31/02/2012. Cet article a été accepté pour publication le 16/10/2012.

Étape 1 : Créer les objets :

• Auteur1 : B. Ali (rôle : auteur correspondant)
• Auteur2 : S. Mohamed
• Auteur3 : N. Ben Saleh
• Article : contribution au monitoring des systèmes
• Revue : revue_informatique
• Éditeur : M. E

Étape 2 : Associer les objets :

• Les trois auteurs sont liés à l’article (avec B. Ali comme correspondant)
• L’article est lié à la revue
• La revue est liée à l’éditeur
• L’article a une date de soumission : 31/02/2012
• L’article a une date d’acceptation : 16/10/2012

Réponse finale : Le diagramme d’objets montre les instances et leurs liens comme décrit, illustrant la situation donnée.

Exercice 7 : Sens de navigation dans le diagramme de classes

Il s'agit de préciser le sens de navigation sur le diagramme de classes de la question 2.1 afin de limiter la navigation au maximum.

Étape 1 : Identifier les navigations nécessaires :

• De Article vers Auteur (pour connaître les auteurs d’un article)
• De Auteur vers Article (pour connaître les articles soumis par un auteur)
• De Article vers Évaluateur (pour connaître les évaluateurs assignés)
• De Évaluateur vers Article (utile pour l’évaluateur)
• De Article vers Revue et de Revue vers Éditeur

Étape 2 : Limiter la navigation :

• Navigation bidirectionnelle entre Article et Auteur
• Navigation unidirectionnelle de Article vers Évaluateur (l’évaluateur n’a pas besoin de connaître tous les articles)
• Navigation unidirectionnelle de Article vers Revue
• Navigation unidirectionnelle de Revue vers Éditeur

Réponse finale : Le sens de navigation est limité pour réduire la complexité, en privilégiant la navigation nécessaire pour les cas d’utilisation.

Exercice 8 : Décoration des associations par contraintes de gestion

Il s'agit d’annoter les associations du diagramme de classes avec les contraintes {ordered}, {addOnly}, {frozen}, {notUnique} représentées par les symboles O, A, F, N sur le bout navigable.

Exemples d’annotations :

• Association Article–Auteur : {ordered} (O) car l’ordre des auteurs peut être important
• Association Article–Évaluateur : {addOnly} (A) car on ajoute des évaluateurs mais ne les retire pas
• Association Article–MotsClés : {frozen} (F) si les mots clés ne changent plus après soumission
• Association Revue–Éditeur : {notUnique} (N) si un éditeur peut gérer plusieurs revues

Réponse finale : Chaque association est annotée avec les contraintes appropriées selon la gestion des liens dans le système.

Exercice 9 : Structures de données pour les associations multiples

Il s'agit de choisir une structure de données pour implémenter les associations multiples et justifier ces choix.

Exemples :

• Pour Article–Auteur (cardinalité multiple, ordonnée) : utiliser une liste (List) pour conserver l’ordre des auteurs.
• Pour Article–Évaluateur (cardinalité multiple, addOnly) : utiliser un ensemble (Set) pour éviter les doublons.
• Pour Article–MotsClés : utiliser un ensemble (Set) car les mots clés sont uniques et non ordonnés.

Réponse finale : Les structures List et Set sont choisies selon les contraintes d’ordonnancement et d’unicité des associations.

Exercice 10 : Représentation des règles métier pour l’évaluation

a) Il s'agit de représenter dans le diagramme de classes la règle que l’article ne peut pas être évalué par un auteur, un chercheur de la même institution ou l’éditeur.

Solution :

• Ajouter une association entre Auteur et Institution
• Ajouter une association entre Évaluateur et Institution
• Ajouter une contrainte ou une méthode dans la classe Évaluateur ou Article pour vérifier que l’évaluateur n’est pas auteur ni de la même institution
• Représenter l’éditeur comme une entité distincte liée à la revue et exclure l’éditeur de la liste des évaluateurs

Réponse finale : La règle est modélisée par des associations Institution et une contrainte métier dans le diagramme de classes.

b) Déduire l’ensemble des objets nécessaires au scénario nominal « Affecter un article à un évaluateur ».

Objets nécessaires :

• Article à évaluer
• Auteur(s) de l’article
• Évaluateur(s) potentiels
• Institution(s) des auteurs et évaluateurs
• Éditeur

Réponse finale : Ces objets sont indispensables pour appliquer les règles et réaliser l’affectation.

c) Donner le diagramme de séquence du scénario nominal avec les objets déduits et préciser les méthodes ajoutées.

Méthodes possibles :

• Article.getAuteurs()
• Évaluateur.estDisponible()
• Évaluateur.appartientInstitution(Institution)
• Éditeur.choisirEvaluateur(Article)
• Article.affecterEvaluateur(Évaluateur)

Diagramme de séquence :

• L’éditeur demande à l’article la liste des auteurs
• L’éditeur sélectionne un évaluateur disponible ne partageant pas d’institution avec les auteurs
• L’éditeur appelle Article.affecterEvaluateur pour assigner l’évaluateur
• L’évaluateur est notifié de la mission

Réponse finale : Le diagramme de séquence illustre ces interactions avec les méthodes précisées.

Exercice 11 : Diagramme d’états-transitions de la classe « Article »

Il s'agit de déduire le diagramme d’états-transitions illustrant l’évolution d’un article.

États possibles :

• Déclaré (intention de soumettre)
• Soumis
• En évaluation
• Révision demandée
• Accepté
• Rejeté
• Publié

Transitions :

• Déclaré → Soumis : soumission effective
• Soumis → En évaluation : assignation aux évaluateurs
• En évaluation → Révision demandée : décision de demander une révision
• Révision demandée → Soumis : dépôt de la révision
• En évaluation → Accepté ou Rejeté : décision finale
• Accepté → Publié : publication effective

Réponse finale : Le diagramme d’états-transitions suit cette séquence, illustrant clairement l’évolution de l’article.

Exercice 12 : Gestion de plusieurs revues et éditeurs

Il s'agit de déterminer si le diagramme de classes doit être révisé pour gérer plusieurs revues avec plusieurs éditeurs, et de préciser les modifications éventuelles.

Analyse :

• Si le diagramme actuel lie une revue à un seul éditeur, il faut modifier la cardinalité pour permettre plusieurs éditeurs par revue ou plusieurs revues par éditeur.
• Il faut modéliser une association plusieurs-à-plusieurs entre Revue et Éditeur si nécessaire.
• Ajouter une classe ou une association pour gérer cette relation si elle est complexe.

Réponse finale : Oui, le diagramme doit être révisé pour refléter la multiplicité des éditeurs et revues, en ajustant les cardinalités et associations.

Méthode : Techniques récompensées et erreurs pénalisées

Ce type d’examen valorise :

• La rigueur dans la modélisation UML, notamment la précision des cardinalités et la distinction claire entre composition et agrégation.
• La capacité à identifier et représenter correctement les acteurs, cas d’utilisation, et leurs relations.
• La clarté dans la description des scénarios, en distinguant bien les scénarios nominal, alternatif et exceptionnel.
• L’utilisation appropriée des contraintes de gestion sur les associations ({ordered}, {addOnly}, etc.) et la justification des choix de structures de données.
• La cohérence entre les différents diagrammes (cas d’utilisation, classes, objets, séquence, états-transitions).
• L’application correcte des règles métier dans la modélisation, notamment les contraintes sur l’affectation des évaluateurs.

Les erreurs les plus pénalisées sont :

• L’omission des cardinalités ou leur mauvaise interprétation.
• Confusion entre composition et agrégation.
• Scénarios incomplets ou mal différenciés.
• Absence de justification des choix techniques.
• Incohérences entre les différents diagrammes.

En résumé, une démarche méthodique, justifiée et claire est essentielle pour réussir cet examen d’analyse et conception orientées objet.