Discussion :

[autran]

Bonjour,

Je vous propose un tutoriel pour illustrer une méthode de conception d'application WEB avec UML..

Ce tutoriel est disponible à l'adresse suivante :
http://marcautran.developpez.com/tut...onception-uml/

Merci de laisser vos commentaires.

Marc,

[MichaelREMY]

un tutotriel digne d'être un cours magistral !

Vous avez écrit "niveau confirmé", mais je trouve que c'est pour les débutants aussi. Où tu moins ceux qui connaissent une méthode de modélisation alternative (et oui, car l'UML n'est pas la seule ,loin de là).

On m'avait appris l'UML en 2ème année de BTS informatique (bac+2), c'est surtout pour cela que je ne considère pas votre tuto pour les "confirmés".
Ah je me souviens de cette année d'étude où le prof d'analyse Meurisse venait taquiner le prof qui nous enseignait l'UML en disant "tu pers ton temps, Meurisse est plus productif et accessible". Le prof d'UML rétorquait "va-t-en toi ,t'es juste un prof b+2, mois je suis agrégé et quasi ingénieur...". Le belle époque.
On me m'avait encore réappris l'UML en Miage (bac+3...) si je me souviens bien.

Il manque un point à votre texte : indiquer quel métier est responsable de faire ces schémas et analyse. Allez, je pose une colle : MOA ou MOE ..... cdp, ingé.,analyste...?
D'expérience, je sais que ce genre de cours est assez verbeux si il n'est pas rapidement (ou en allant) accompagné d'un TP de programmation associé à l'exemple (même si je sais que ceux qui font cette analyse seronr rarement (normalement jamais même) ceux qui feront la partie de code....

UML nous permet de spécifier les éléments de conception dans un langage qui est compréhensible par le client et par le développeur, ce qui sonne comme un gage de réussite pour le projet.

Il est bon de rappeler que le client ne sera pas forcément (loin de là) l'utilisateur final (celui sur le clavier)
Par contre, ça ne sonne pas un gage de réussite, mais un gage de responsabilité et de résolution de recettage en cas de problèmes....

ca changera la vie de certains ingénieurs d'étude comme moi

Vous êtes ingénieur d'étude et n'avez pas été formé à cette méthode lors de vos études ? Incroyable que vous découvriez cela ici !

ps : pour ceux qui trouvent ces schémas pas très pratique à réaliser, sachez qu'il existe une multitude d'outils comme PowerDesigner voire Visio qui permettent de les faire en qq clics.

[Aurelien Plazzotta]

Oui, c'est toujours une bataille d'égo entre enseignants qui défendent leur pré carré...

J'ai appris (comprendre survoler de loin) Merise puis 3-4 diagrammes UML 1 à l'AFPA en session Concepteur-Développeur. Merise est une méthodologie, et donc soumise à moult interprétations, tandis que UML est un language, et donc normé, qui en plus de la conception permet aussi de faire de l'analyse logicielle et architecturale.

Pour être clair, j'ai abandonné Merise aussitôt. C'est bien mignon mais dans la vraie vie, on utilise UML. C'est mesquin énoncé tel quel, Merise reste une fierté francophone, et demeure inconnu à l'étranger.

Enfin, j'ai appris sérieusement l'UML 2.0 en lisant et pratiquant avec le livre écrit par les 3 créateurs du language, Booch, Rumbaugh and Jacobson :
http://www.amazon.com/Unified-Modeli...age+user+guide

Vous pouvez aussi pousser le bouchon un peu plus et parfaire vos connaissances avec le manuel de référence : http://www.amazon.com/Modeling-Langu...sap_bc?ie=UTF8

Mais alors attention, c'est aussi indigeste que lire les spécifications du compilateur Java aux éditions Addison-Wesley (même si cela reste génial à découvrir !).

Pour environ 100 $ les deux ouvrages, ça offre un accélérateur de carrière pour ceux et celles qui s'orientent vers un rôle d'architecte technique (logiciel ou réseaux).

[MichaelREMY]

Pour être clair, j'ai abandonné Merise aussitôt. C'est bien mignon mais dans la vraie vie, on utilise UML. C'est mesquin énoncé tel quel, Merise reste une fierté francophone, et demeure inconnu à l'étranger.

ouch le troll lancé, malheureux...
Je vais l'arrêter de suite :
Merise est extrêmement adapté aux applications métiers orientées gestion, mini-ERP ou module procédural (avec beaucoup d'écran à formulaire à gérer, de reporting à faire...etc), surtout avec une grosse base de données derrière.
L'uml est très bien adapté au reste des applications et même aux applications de gestion aussi (mais bon...)

[autran]

Vous êtes ingénieur d'étude et n'avez pas été formé à cette méthode lors de vos études ? Incroyable que vous découvriez cela ici !

Je ne souhaite pas lancer un troll, mais un ingénieur d'étude dans ma boite, ca peut être un développeur full stack autonome qui a un bon contact avec le client. Donc il n'aura pas forcement vu UML dans son parcours scolaire.
C'était mon cas, quand mon chef du pole delivery a remarqué que ma maitrise du HTML/AJAX + PHP me permettait de faire rapidement des écrans puis des livrables il m'a bombardé ingénieur d'étude. Alors que mon cursus de développeur en BTS ne m'avais pas fait croiser la route d'UML.
Bon par la suite j'ai senti le besoin d'approfondir au CNAM vers un Bac + 3 et j'ai appris UML.

[GeoffreyOnRails]

J'ai trouvé l'article intéressant, mais ma principale question est un peu en dehors du sujet : d'après ce que je lis, vous avez fait cette analyse dans le cadre d'un véritable projet. Pourquoi ne pas avoir réutilisé des briques existantes?
Autant la place de marché, je peux comprendre que ça soit un peu particulier, mais sur la CRM et la SCM, qu'est ce qui justifiait le choix d'un développement spécifique?

Sinon bon article, c'était intéressant

[autran]

J'ai trouvé l'article intéressant, mais ma principale question est un peu en dehors du sujet : d'après ce que je lis, vous avez fait cette analyse dans le cadre d'un véritable projet. Pourquoi ne pas avoir réutilisé des briques existantes?
Autant la place de marché, je peux comprendre que ça soit un peu particulier, mais sur la CRM et la SCM, qu'est ce qui justifiait le choix d'un développement spécifique?
Sinon bon article, c'était intéressant

C'est toute la question de savoir si on veut un ERP ou du spécifique. Je n'ai pas fait ce choix, c'était une décision du DSI, moi je n'ai pris que la maitrise d’œuvre du projet.
Néanmoins je partage le sentiment de mon DSI de ne recourir à un ERP que lorsque l'on organise tout le process autour de l'ERP comme c'est la cas dans certaines entreprises.
Et je reste convaincu que cela n'est pas valable pour des processus légers d'une durée de vie inférieurs à 5 ans

[dix77]

Bonjour,
Tout d'abord, merci pour ce tuto très bien fait et qui permet d'y voir plus clair dans la conception d'application WEB.
A la fin du tuto, il y a un schéma de la base de données et une question me vient à l'esprit:
Comment fais-tu pour savoir si le prix d'un produit a changé entre le moment où le client l'a mis dans son panier et le moment où il effectue le paiement ?
Merci d'avance,
dix77

[autran]

Bonjour dix77,

Juridiquement, le prix au moment de la commande est contractuel. Donc si le prix change, il paiera le prix initial.
C'est pour cela que dans la table LigneCommande on a rajouté le prix unitaire au moment de la commande (PrixUni).

En espérant avoir répondu à ta question.

[alicc]

Bonjour,
Article très intéressant.

QU :
Type de diagramme : avez vous choisi des diagramme d'états-transitions (ou simplement leur graphisme) pour représenter la cinématique ? (O/N?)
Stéréotypes utilisés : est-ce à cette étape que vous décidez de définir les futures "pages" (je veux dire nulle part avant/ailleurs) ?

QU : Gérer le panier
Je présume que CtrPanier va se charger de demander au Panier de lui calculer le Total, Panier demandant à son tour à chaque LignePanierCommande
de calculer les Sous-totaux des Lignes puis de les sommer et ensuite de 'passer' le Total à la Vue.
(Tout cela est peut-être implicite dans votre méthode Commander()?)

Merci d'avance

[autran]

Bonjour alicc et merci pour ces questions.

Je confirme que les diagrammes états transitions sont principalement utilisés pour représenter la cinématique.

Le stéréotype "page" apparait à cette étape car cela correspondait à un besoin dans un atelier de spécification. En effet j'ai dû introduire la "page" (web) pour permettre au groupe des utilisateurs d'accoucher du besoin à travers des notions qui leurs parlaient.

Pour le CtrPanier, il s'agit bien à ce stade pour la vue d'appeler un service afin de manipuler des données du modèle. Attention, on ne connait pas encore les solutions d'implémentation à ce stade puisque les langages et frameworks ne sont pas encore choisis. Cet article ne décrit que le PIM (Platform Independant Model), donc une analyse indépendante de la technologie choisie.

Quant au paradigme panier en lui même et ses satellites (ligne panier, vue pour le représenter...), je dirais qu'il en existe des abstractions et des implémentations à la pelle. J'en ai écrit quelques uns dans une série de tutos sous JS et Node que je vous invite à consulter

Cordialement,

Marc

[alicc]

J'avais presqu'oublié que j'avais posé cette question... Merci d'y avoir répondu ;-)

Dès lors, je reprends mes esprits pour en remettre une couche...

= = =

Dans vos cas d'utilisation, perso, je trouve l'utilisation des stéréotypes <<extend>> entre préparation-livraison - facturation - production statistiques ainsi qu'entre livrer-produit et gérer-stock un peu abusive. Un <<extend>> ne devrait représenter que des spécialisations des cas d'utilisation auxquels ils s'attachent, l'exemple bateau étant Paiement avec les <<extend>> cash, VISA, chèques...

Par contre, je les trouve très pratiques sur votre diagramme. J'aurais probablement mis de simples lignes à la place des <<extend>> mentionnés plus haut.

Ou alors, partant de votre exemple, j'ai admis pour mes étudiants l'utilisation des <<extend>> pour représenter une forme rudimentaire de séquence entre les cas et sous-cas. Comme vous le rappelez, ce diagramme est à partager avec les utilisateurs... Donc, autant qu'ils comprennent...

= = =

Dans le diagramme de séquence du CRM, (et maintenant en général dans tous les diagrammes de séquences de mes étudiants, je les invite (euphémisme...) à commencer à gauche au-dessus non par 'client' ou similaire, mais carrément par CONTROLLER suivi du nom du cas d'utilisation (divisé eventuellement en plus par acteur).
Cela fait "plein de contrôleurs" mais le programmeur en fera ce qu'il voudra (je veux dire les regrouper).
Par contre, j'y vois beaucoup d'avantages :
- cela clarifie et fluidifie le lien entre cas d'utilisation, diagramme de classes et diagrammes de séquence.
- cela permet de retrouver des cas d'utilisation oubliés / classes oubliées ... càd de rendre au total l'analyse plus cohérente
- cela leur rappelle le design pattern CONTROLLER qui est une CREATION PURE (ou classe logicielle hors domaine)
- et les oblige à re-réfléchir sur les patterns FORTE COHESION, FAIBLE COUPLAGE, ..., EXPERT... et OBSERVATEUR qui deviennent plus concrets à ce moment-là...

= = =

Si vous avez un avis... Welcome... :-)