Examen Principal du 1er Semestre

Questions de réflexion

Question 1 - Définition de l'encapsulation et sa mise en évidence

L'encapsulation est le mécanisme de conception qui consiste à regrouper les données (attributs) et les comportements (méthodes) qui les manipulent au sein d'une même entité logique : la classe. Son but principal est de masquer les détails d'implémentation internes de l'objet à l'extérieur de celui-ci, afin de garantir l'intégrité des données et de réduire le couplage.

Dans le cas d'une classe, ce principe est mis en évidence par l'utilisation des niveaux de visibilité (ou modificateurs d'accès) :

• Les données membres (attributs) sont déclarées avec une visibilité privée (notée - en UML), ce qui interdit toute lecture ou modification directe depuis une autre classe.
• L'accès et la modification de ces attributs sont contrôlés via des méthodes déclarées avec une visibilité publique (notée + en UML), telles que les accesseurs (getters) et les mutateurs (setters). Ces méthodes peuvent inclure des règles de validation avant de modifier l'état interne de l'objet.

Question 2 - Vue statique et vue dynamique en UML

La différence fondamentale réside dans la prise en compte du temps et de l'exécution :

• La vue statique modélise la structure du système à un instant T, de manière figée. Elle décrit les éléments qui composent le système et les relations qui les lient, indépendamment de toute notion de temporalité. Exemple : Le diagramme de classes est une vue statique car il montre la structure du code (classes, attributs, méthodes, associations, héritage) qui reste la même quelle que soit l'exécution. Le diagramme d'objets en est un autre exemple.
• La vue dynamique modélise le comportement du système au cours du temps. Elle décrit l'évolution du système, les interactions entre les objets et les changements d'état lors de l'exécution. Exemple : Le diagramme de séquence est une vue dynamique car il représente l'ordre chronologique (ligne de vie temporelle) des messages échangés entre les objets pour réaliser une fonctionnalité. Le diagramme d'états-transitions est un autre exemple dynamique.

Question 3 - Équivalence des diagrammes de séquence

Cette question ne peut pas être traitée car les deux diagrammes de séquence mentionnés par l'énoncé sont absents du document source fourni. Il est donc impossible de les analyser pour justifier de leur équivalence.

Problème - Logiciel Publication_dans_revue

Travail à faire - Analyse et conception

Le document source indique que le développeur a proposé un « diagramme de classes conceptuel (analyse) UML incomplet » et demande de répondre aux questions posées sur les « feuilles de réponses ». Or, ni le diagramme incomplet ni les questions n'ont été extraits dans la source fournie. Il est par conséquent impossible de fournir les réponses formelles attendues.

Toutefois, en guise de commentaire pédagogique pour la préparation, voici l'extraction des concepts clés du texte qui structureraient nécessairement le diagramme de classes et le diagramme d'états :

1. Entités et acteurs identifiés (Classes potentielles) :

• Chercheur (Classe mère)
• Auteur, Editeur, Evaluateur (Sous-classes ou rôles de Chercheur). L'auteur ayant un booléen ou un rôle spécifique de Correspondant.
• Article (Classe centrale)
• Institution (Liée au Chercheur)
• Revue
• MotCle
• Evaluation ou Avis (Classe d'association entre Evaluateur et Article).

2. Attributs et règles de gestion (Multiplicités et contraintes) :

• Article : titre, résumé (contrainte : ≤ 150 mots), tailleMots, contenu, dateSoumission, dateRevision.
• Contrainte de multiplicité : Si tailleMots < 4000 (Article court) → 3 évaluateurs. Sinon (Article long) → 4 évaluateurs.
• Contraintes d'intégrité (OCL ou notes) : L'évaluateur d'un article a ne doit pas être auteur de a, ne doit pas être l'éditeur gérant a, et son Institution doit être différente des institutions de tous les auteurs de a.

3. Cycle de vie de l'Article (États) :

• En cours de soumission (modifications possibles, annulation possible)
• Soumis (aucune suppression possible)
• En évaluation (affecté aux évaluateurs)
• A réviser (mineure ou majeure) → boucle vers En évaluation lors du dépôt de la nouvelle version.
• Accepté (définitif, conservé)
• Refusé / Abandonné (définitif, supprimé).

Méthode

Pour réussir l'analyse d'un cahier des charges textuel lors d'un examen de conception UML :

1. Traque des substantifs et des verbes : Dès la première lecture, soulignez les noms communs (qui feront d'excellentes classes ou attributs) et entourez les verbes d'action (qui définissent les cas d'utilisation ou les méthodes des classes).
2. Modélisation des contraintes métier : Portez une attention particulière aux conditions (ex: "si l'article est court", "ne peut pas être évalué par"). Tout ce qui ne peut pas être modélisé par une simple multiplicité (comme 1..*) sur un diagramme de classes doit être formalisé sous forme de contrainte textuelle ou en langage OCL.
3. Extraction du cycle de vie : Quand un texte regorge de vocabulaire temporel ("tant que", "à partir de cette phase", "définitif"), il décrit implicitement un diagramme d'états-transitions. Dressez la liste des états possibles au brouillon avant même de tracer le diagramme de classes, car ces états dicteront souvent des attributs ou des associations requises.
4. Gestion de l'incomplet : Dans un examen de conception, il est fréquent qu'un énoncé soit volontairement simplificateur (comme mentionné ici avec l'authentification ignorée ou l'existence d'une seule revue). Ne modélisez strictement que ce qui est demandé ou décrit, sans sur-concevoir avec des fonctionnalités que vous jugeriez "logiques" dans la vie réelle mais qui ne figurent pas dans le texte.