- 21.06.2016
D'un point de vue syntaxique:
- moyenne: 10,24/20, min 2,5; max 15; stdev 3,39
- Quartiles:
- 1er quartile: 15 <= x <= 13,25
- 2nd quartile: 13,25 <= x <= 10,5
- 3ème quartile: 10,25 <= x <= 7,75
- 4ème quartile: 7,50 <= x <= 2,5
Sur le contenu des copies :
- Orthographe / grammaire : faites attention dans vos copies, a ne pas oublier de mots ("L'avantage d'avoir une spéciale pour les WS" couche?), et a ne pas confondre "ait", "er" et "é", considérant que mettre une phrase au conditionnel au lieu du présent change quand même pas mal le sens de celle-ci ...
- Lisez la question!! Et ne répondez pas a coté.
- Minimisez votre rapport signal/bruit. Cela ne sert a rien de noyer la partie interessante de votre réponse dans de grandes tirades. Par exemple :
- "Après l'exposition des différents avantages des Web services du point de vue architectural, nous ne pouvons pas conclure sans analyser les inconvénients intrinsèques d'une telle technologie lorsqu'elle est appliquée à la conception d'une architecture logicielle" (je cite)
- Peut très avantageusement se résumer en un "Inconvénients :" en début de phrase.
- Faites attention a votre langage écrit. Il y a des manières plus propre d'exprimer "comment c'est trop le bordel dans ce type d'appli", que "c'est devenu quelque peu bordélique", ... (je cite des réponse de la question #2).
- moyenne: 1,50/3 (9,70/20); min 0; max 3; stdev 0,76
Vous avez du mal a synthétiser vos propos et a les restituer de manière cohérente. La plupart des copies manquent de3 recul et s'arrêtent à des considérations technologiques. Quelques points importants vis à vos de vos réponses :
- Attention a bien lire la question. Le thème était "apports d'une couche WS", pas "apports d'une architecture en couche".
- Peu on mis en avant l'indépendance technologique associée à l'exposition de services.
- Web service n'implique pas forcément SOAP. Ni REST. Les 2 existent.
- La standardisation des échanges est importante, même si elle se fait a des niveaux différents : protocolaire pour REST / SOAP, plus données pour SOAP.
- La notion de stateless et de passage à l'échelle est trop peu discutée dans vos copies.
- Attention à bien différencier l'exposition de fonctions métiers (SOAP / RPC) ou de ressources (REST)
- Attention, vous semblez découvrir la notion d'interface / API a travers les services ... on peut faire des APIs sans faire de service, les service sont une certaine classe d'API, avec des propriétés supplémentaires.
- Trop peu ont exploité le fait qu'un service n'était pas uniquement l'exposition du métier selon un standard (bijection service - composants métier), mais pouvait servir à donner des points de vues ≠ sur celui-ci.
- moyenne: 1,69/4 (8,44/20); min 0; max 3,5; stdev 1,11
Le texte de Fowler est un extrait de la 3ème page du livre de référence sur lequel s'appuie le début du cours (Patterns of Enterprise Application Architecture). Et cité en bibliographie. Et présent à la BU. Et trouvable sur le web. Et indiqué plusieurs fois en tant que tel lors des cours. Pourtant en lisant vos copies vous semblez tomber des nues en le découvrant. C'est (vraiment) dommage, cette question était censée être facile puisque basée sur un des textes fondateur du module.
L'extrait se décline autour de 3 axes principaux, mis en gras dans le texte pour vous aider. Trop peu l'ont vu, et beaucoup ont alignés des arguments sur les architectures 3-tiers, ce qui n'était pas le but de l'exercice, mais bel et bien d'analyser le texte en fonction de votre point de vue, et de votre experience sur le développement d'applications 3-tiers.
Le premier paragraphe portait sur l'hétérogénéité (cf partie 1), du point de vue de l'intégration. Par rapport à Isola 3000, cela faisait écho à l'intégration de services tiers définis en .Net pour la station de ski. Pour l'instant vous avez intégré en point à point, la limite immédiate de cette approche est que cela tend vers le plat de spaghetti, ce que certains ont relevés.
Le second portait sur le coté illogique de la logique métier. Pensez a la grille tarifaire du projet Isola300, et a son incroyable complexité métier. Le rôle de l'archi est d'arriver a prendre en compte cette absence de logique (au sens informatique/mathématique du terme), faite de plus de cas particuliers que de généralités. Et pourtant, pour arriver a la maintenir, il n'est pas possible de se contenter des cas particuliers.
Le dernier paragraph portait sur la taille des applications, et sur le fait que même les petites applications ont besoin d'une vraie architecture. Vous pouviez parler d'Isola 3000 dans sa globalité, qui reste une "petite application" au sens métier du terme.
- moyenne: 7,05/13 (10,85/20); min 1,5; max 10,75; stdev 2,53
La plupart du temps vous ne justifiez pas votre mapping objet-relationnel (sur 1 point), et vous ne décrivez pas vos interfaces (sur 2 points). L'étude de cas est donc globalement évaluée sur 10 et pas sur 13.
Question 1: Objets métiers et mapping objet-relationnel. Vos objets métiers sont censé être des structures de données pure, sans comportement. Les détails d'implémentations (get/set, adder dans des listes) ne doivent pas faire partie de votre modèles. Pourquoi introduisez vous de l'héritage, tout le temps? Modéliser ne veut pas dire hériter. Particulièrement quand vos classes filles ne contiennent rient d'autre que les classes mères. Coté mapping, décrire un ORM ne veut pas dire "optimiser", simplement expliquer quelle stratégie vous utilisez pour traduire vos objets métiers en structure relationnelles. Décrire un mapping ne veut pas non plus dire "fracasser le modèle relationnel", par exemple "stocker dans un champ les IDs des salles, séparés par des virgules" (je cite), c'est une abomination. Certains ont proposé de ne pas générer d'identifiant pour les utilisateurs du systèmes et de reposer sur le numéro de sécurité sociale. C'est intéressant, mais illégal. Votre niveau global en UML "simple" est a pleurer. Je ne parle pas de détails complexes de la super-structure UML (748 pages de spécifications), simplement de mettre les flèches d'héritage dans le bon sens, et d'utiliser des compositions et des références de manière appropriées. Comme tout langage (le L de UML veut dire langage), il vient avec une syntaxe définie, et une sémantique associée. Donc ne pas respecter ça revient a décrire des choses particulièrement incohérente ("toutes les salles de cours sont des salles de biologie" par exemple).
Question 2: Composants & Interfaces. Peu ont discuté la différence entre utiliser des clés et utiliser des objets dans les signatures des méthodes. J'ai trouvé beaucoup de composants Dieux centraux. Et beaucoup trop souvent des XXXmanager, ou des composants nommés par des noms communs. La plupart du temps vous ne traitez pas de gestion d'erreurs. Je n'ai vu d'utilisation d'intercepteurs que sur une copie (et d'ailleurs c'était une bonne idée pour le point en question).
Question 3: Choix de conceptions. Vous ne discutez quasiment jamais vos choix de manière pertinente. Pourquoi avoir implémenté un service de mailing en .Net ? Pour faire comme dans le projet fil rouge ? J'ai vu une copie ou tout était statefull "parce que sinon on ne peut pas stocker les données dans les maps de la base de données".
Question 4: Implantation J2E. Pas grand chose a dire. Attention, j'ai lu plusieurs fois que RMI était utilisé pour communiquer entre composants. C'est vrai, uniquement avec des composants @Remote, en local, vous restez dans la même JVM donc c'est uniquement de l'envoi de messages aux objets, classique.