Td corrigé Partiel GL pdf

Partiel GL

Le sujet se présente sous la forme de 3 dossiers indépendants. ... Annexe 4 : Tableau de la répartition actuelle des tâches de gestion commerciale relatives au ..... Olonzac. MAU. Maubec. SAS. Saint André de Sangonis. SMA. Saint Maximin.




part of the document



M1 : Ingénierie du Logiciel
Université Pierre & Marie Curie (Paris VI)
Examen de décembre 2006 (2 heures avec documents)
Questions de cours [5 Pts]
Q1.1 : Quelles sont les différences entre les dépendances structurelles et les dépendances fonctionnelles ?
Les dépendances fonctionnelles apparaissent entre composants, lorsqu’un composant fait appel à une opération offerte par un autre composant. Il dépend alors des fonctions fournies par l’autre composant. Il n’a pas besoin par contre de connaître la structure interne de ce composant.
Les dépendances structurelles apparaissent lorsqu’un lorsqu’une classe d’un composant dépend de la structure d’une classe (héritage, association, typage des attributs ou des paramètres) d’un autre composant. Le composant a donc besoin de connaître la structure interne de l’autre composant (c’est interdit en IL).

Barème :
+40% par explication
+20% si précision que les dépendances fonctionnelles sont autorisées entre les composants et pas les dépendances structurelles.
0% sinon
Q1.2 : Peut-on dire qu’une bonne conception est une conception qui défini une solution répondant aux besoins spécifiés lors de l’analyse (ni plus, ni moins) ?
Non, il faut aussi qu’elle soit flexible, performante, robuste, efficace … La complétude et la justesse ne sont pas les seuls critères.

Barème :
100% si tout
0% sinon
0% si conception = uniquement la solution d’un problème (cela n’est alors pas une BONNE conception)
Q1.3 : En conception, est-il possible de résoudre plus de besoins que ceux spécifiés en analyse ?
Oui, il est par exemple possible de réutiliser un composant qui fait bien plus que nécessaire. Dans un des TD par exemple, un des composants utilisait une mémoire cache afin d’aller plus vite. La mémoire cache n’est pas nécessaire et pourtant elle améliore la conception.
Barème :
100% si tout
0% si autre explication peu convaincante.

Q1.4 : Le diagramme de cas d’utilisation suivant représente certaines fonctionnalités d’un outil UML. En considérant que la vérification du modèle vérifie que le modèle est bien un modèle UML, discutez des relations d’include. 
Ces relations d’inclusion sont tout à fait possible car il est fort à parier qu’une vérification soit faite avant toute génération de code et de documentation. De plus, il est tout à fait envisageable de faire en sorte que l’utilisateur bénéficie de cette fonctionnalité.

Barème :
100 % si tout
50 % si explication correcte sur la non nécessité des includes (ceux-ci ne sont en effet pas obligatoire, on peut s’en sortir avec des pré-condition).
50 % si explication de ce que veut dire le diagramme sans réelle discussion.
0 % si explication douteuse sur les include (genre, non c’est interdit parce que on a dit en cours que c’était interdit).

Q1.5 : Quel est l’intérêt de la phase de conception par rapport à la phase de réalisation ? En d’autres mots, est-il possible de passer directement de l’analyse à la réalisation ?
La phase de conception permet d’être indépendant d’une plate-forme. Si l’indépendance n’est pas un objectif, on peut s’en passer.

Barème :
100 % si tout.
50% si justification assez précise sur l’intérêt d’une découpe en composant (dépendance entre composant et vue abstraite)
0 % sinon.
Problème: Conception et Réalisation de eB6 [15 Pts]
Après leur partiel de IL, des étudiants de master ont décidé de réaliser la phase de conception du logiciel eB6. Ils ont décidé de ne pas refaire une analyse et de ne se baser que sur les diagrammes suivants.
Description des cas d’utilisation :
S’inscrire comme acheteur : un utilisateur peut s’inscrire comme acheteur.
S’inscrire comme vendeur : un utilisateur peut s’inscrire comme vendeur.
Regarder les objets mis en vente : un utilisateur ou un acheteur peuvent regarder tous les objets mis en vente.
Poser une enchère sur un objet mis en vente aux enchères : un acheteur peut poser une enchère sur un objet qui a déjà été mis en vente et qui n’est pas encore vendu.
Acheter directement un objet mis en vente directement : un acheteur peut acheter directement un objet si celui-ci a été mis en vente directement. Le premier acheteur a acheter directement l’objet peut alors traiter avec le vendeur.
Mettre un objet en vente : un vendeur peut mettre un objet en vente soit aux enchères soit en vente directement.
Diagramme de cas d’utilisation d’analyse et diagrammes de classes d’analyse (ne représentant que les classes métiers):



Les étudiants proposent la découpe en composants suivantes :
Un composant GestionUtilisateur responsable des inscriptions des utilisateurs (en tant qu’acheteur et vendeur) et responsable de l’authentification des utilisateurs.
Un composant GestionObjet responsable de la gestion des objets mis en vente par les vendeurs. Ce composant est aussi responsable de la recherche des objets en fonction catégories ou de mots clé.
Un composant GestionEnchère responsable de la gestion des enchères. Ce composant enregistre les enchères et sélectionne la meilleure enchère lors de l’échéance de la vente.
Un composant IHM qui représente l’interface homme machine de l’application.
Le diagramme suivant ne représente que les interfaces offertes des composants.

Question 2.1 : Spécifiez les opérations des interfaces IObjet et IEnchère.

Dans IObject, il faut voir apparaître une opération pour ajouter un objet et deux opérations pour rechercher les objets (par mots clés et par catégories). Il faut voir les paramètres de ces opérations (pas de dépendance structurelle !)
Dans IEnchère, il faut une opération permettant l’ajout d’une nouvelle enchère et une opération permettant d’obtenir la meilleure enchère pour un objet mis en vente. Il faut voir les paramètres de ces opérations (pas de dépendance structurelle !).

Barème :
50% par interface
25% pour les opérations
25% pour les paramètres sans dépendance structurelle

Question 2.2 : Réalisez un diagramme de séquence de conception pour la mise en vente par enchère d’un objet par un vendeur ainsi que l’achat par deux acheteurs. Il est demandé de ne montrer que les interactions entre composants.
Il faut voir apparaître au moins une instance pour les composants (GestionEnchère,GestionObjet et IHM). 10%
Si l’authentification est traitée il faut voir apparaître une instance de GestionUtilisateur. 10%
Il faut voir apparaître 3 acteurs (un vendeur et deux acheteurs) 10%
Les acteurs ne doivent communiquer qu’avec l’instance de IHM 10%.
Il faut voir apparaître l’ajout d’une nouvelle enchère : communication du vendeur vers l’instance IHM puis communication de l’instance IHM vers l’instance de GestionObject 20%
Il faut voir apparaître les 2 dépôts d’une enchère : communication du vendeur vers l’instance IHM (pour récupérer l’identification de l’objet puis pour déposer une enchère) communication de l’instance IHM vers l’instance GestionEnchère (pour le dépôt effectif de l’enchère) 20%

Les paramètres doivent être précis 20%
Si l’authentification est pleinement modélisée 20%
Toute faute (responsabilité, paramètre, nom d’instance, oubli de message, message superflu, …) -10%


Question 2.3 : Définissez les interfaces requises des composants et précisez leurs dépendances (justifier vos choix).
Idéalement il faut que IHM dépende des autres composants et c’est tout.
Néanmoins, il faut aussi et surtout que les dépendances soit cohérentes avec le diagramme de séquence de la question précédente.

Barème :
100% si que des dépendances de IHM vers les autres et cohérence avec le diagramme de séquence
50% si les dépendances sont cohérentes avec le diagramme de séquence (sans réelle reflexion)
0% sinon, ou si rajout de dépendance structurelle.

Question 2.4 : On considère que le composant GestionEnchère contient une classe représentant les enchères (Enchere) et que le composant GestionUtilisateur contient une classe représentant les acheteurs (Acheteur). Pour gérer la résolution des enchères, c'est-à-dire l’élection de l’enchère la plus haute, les étudiants proposent la conception suivante :

La classe Juge est la classe qui contient l’algorithme d’élection des enchères (dans l’opération jugerEnchèresCourantes). Cette classe référence un unique chronomètre qui lui permet de connaître le temps écoulé et ainsi d’élire les enchères dont la date limite de la vente est arrivée à échéance. Une enchère est ouverte tant que la date limite de la vente n’est pas arrivée à échéance, après cela le juge ferme l’enchère (grâce à l’opération fermer). Ensuite, le juge élit uniquement l’enchère la plus haute (grâce à l’opération elir).
Afin de notifier l’acheteur que son enchère a été élue, les étudiants proposent d’appliquer le pattern Observer. L’enchère est ainsi considérée comme un sujet alors que l’acheteur est considéré comme un observeur.
Expliquez pourquoi cette conception ne suit pas les principes de conception énoncés en cours puis corrigez-la.
L’utilisation de ce pattern est complètement fausse. En effet, il y a ici une confusion entre la classe Acheteur l’acteur Acheteur. Le réel besoin est de notifier l’acteur Acheteur (et non pas la classe Acheteur).
De plus, ce pattern met en place des dépendances structurelles entre les classes des différents composants (Acheteur et Enchere) !
La meilleure chose à faire est de faire supprimer ce pattern (il ne sert à rien).
Une autre possibilité est de modifier ce pattern pour faire disparaître les dépendances structurelles (il est possible d’utiliser des identifiants pour lier les sujets des observateurs (cela laisse néanmoins une double dépendance fonctionnelle entre les composants).

Barème :
100 % si le pattern est supprimé
50 % si les dépendances structurelles sont modifiées en dépendances fonctionnelles.
50 % si identification du problème comme étant une mauvaise application du pattern observer (sans résolution)
25 % si identification du problème comme étant une dépendance structurelle (sans résolution)

Question 2.5 : Les étudiants souhaitent maintenant effectuer la réalisation de la classe Juge sur la plate-forme Java (vous pouvez faire cette question que vous ayez corrigé ou pas la conception lors de la question 2.4). Etant donné que l’élection des enchères doit s’effectuer tout le temps, les étudiants souhaitent utiliser la classe Java Thread. La classe Thread permet de construire un nouveau processus et de lui affecter un traitement (dans l’opération run() de la classe Thread). Les étudiants souhaitent que le juge construise un nouveau Thread (dès l’instanciation du juge) et que ce Thread réalise en continu l’opération jugerEnchèresCourantes(). De plus, les étudiants souhaitent utiliser la classe Java Calendar qui permet d’obtenir, grâce à l’opération int getTime(), la date précise du moment (en milliseconde). Proposez un diagramme de classe illustrant la réalisation de la classe Juge (en ajoutant le code Java des méthodes que vous jugerez utiles de préciser).

Juge doit être associé avec une classe (EnchereEngine) qui hérite de Thread (30%)
La méthode run de cette classe doit faire appel à l’opération jugerEnchèresCourantes() 20%
Cette classe doit être reliée à la classe Calendar (c’est elle qui a besoin du temps pour savoir quelles enchères calculer). 20%
Cette classe doit pouvoir atteindre les enchères gérée par le Juge (association myLord) (30%)

Il y a bien sûr d’autres conceptions qui tiennent la route.
Par contre, une conception qui ne fait que lier Juge à Thread et Calendar mérite 0% (il ne suffit pas de recopier l’énoncé).

Question 2.6 : Etant donné qu’une enchère passe par plusieurs états, définissez la machine à état de la classe Enchère puis identifiez une faute et réalisez un diagramme de séquence de test visant à révéler cette faute.
Les états d’une enchères sont : ouverte (avec un montant), fermé, élu
La machine à état devrait être celle-ci :


A partir de là, il n’est pas très difficile d’identifier des fautes. Par exemple, pouvoir pouvoir élir une enchère alors qu’elle n’est pas fermée.
Barème :
40% pour la machine à état
40% pour la faute
20 % pour le cas de test sous forme d’un diagramme de séquence.









Maîtrise d’Informatique - Module Ingénierie du Logiciel Exam : 21 décembre 2006

Page  PAGE 3


 :