Discussion :

[ktechlab]

Bonjour,

Très souvent nous sommes emmenés à faire le projet UML de l'application que nous developpons.

Bien que la maîtrise des concepts UML ne pose pas problème du fait de nombreuses publications dessus notamment sur developpez.com, eh bien nous remarquons qu'en général lorsqu'il faut commencer son projet UML, on se pose les questions suivantes:

-par quoi vais-je commencer ?
-comment structurer mon projet UML ?
-je ne vois pas comment faire le projet UML d'une application de type webapp, ou de type t quelconque.....
-comment m'organiser ?

Stéphanie YOUNA, Armel CHETAH et Salomon MAYENGUE de la société Koossery Technology vous proposent dans l'article ci-dessous un framework (cadre organisationnel de travail) pour modéliser vos applications en langage UML.


Framework pour la modélisation d'un projet en langage UML


Merci de vos réactions sur ce fil.

[Vlade]

L'article est au début pas mal et ensuite on rentre dans le détail sans vraiment répondre aux questions.
On fini par ne pas savoir pas quoi commencer
Cette article décrit une approche waterfall et une modélisation/création de la base de donnée physique directement en phase de conception.

Je pense qu'au début d'un projet on doit d'abord se poser des questions comme:

1. Doit-on avoir une approche de modélisation dite Waterfall ou en itérations succésives ?
2. La cible est-elle java/jee ou autres ?
3. A-t-on des compétences en interne ? si oui il faut d'abord privilégié ces technologies ?

Il faut noter aujourd'hui que les itérations sont uniquement possible avec Java car le metamodel UML 2.2 à un mécanisme objet comme Java. Ceci n'est pas vraiment possible avec les autres languages.
Désolé pour dotnet qui à mon avis devant ce constat technique a préférer faire du DSL plutôt que de ce prendre la bafe en pleine figure avec l'approche de metamodélisation UML 2.2

[ktechlab]

L'article est au début pas mal et ensuite on rentre dans le détail sans vraiment répondre aux questions.
On fini par ne pas savoir pas quoi commencer

Dans cet article nous commençons par décrire les principales parties d'un projet UML en s'attardant plus sur les parties Use Case View et Analysis View. Il en ressort que lorsqu'il faut modéliser un projet en langage UML, on doit dans l'ordre:

1/ faire le Use Case View: les principaux éléments sont décrits
2/ensuite apporter la reponse technique aux Use Case View au niveau de l'Analysis View: les principaux éléments de l'Analysis view sont décrits

Dans un dernière partie, nous présentons un cas pratique de modélsiation en langage UML d'un projet server et d'un projet front-end. Dans ce cas pratique on applique simplement ce qui a été présenté dans les chapitres précédents cad pour chaque projet, Use Case View puis Analysis View

Cette article décrit une approche waterfall et une modélisation/création de la base de donnée physique directement en phase de conception.

Dans cet article on ne part pas d'une modélisation/création de la base de donnée directement en phase de conception.

Maintenant pour ce qui est des projets server, il est vrai que le Data Model dans le modèle d'analye va servir lors de l'implémentation à créer sa base de donnée physique. Remarquons que on ne tocke pas forcément les données dans une base de données sgbdr:cela peut aussi être un fichier, ou un repository content model JSR 170 (Alfresco, Jaccrabit, etc...) par exemple !

Il est à noter que le data model existe aussi pour le projet uml du front-end (en particulier dans le cas d'une webapp ou d'une winapp) bien qu'il ne serve pas par la suite à créer une base de donnée.

Disons au risque de nous repeter que le cheminement qu'on présente ici est :
d'abord le Use Case view puis ensuite l'Analysys View

Sachant que dans l'Analysis view on suit aussi un cheminement clair: modélisation des composants services , modélisation des composants métiers et ensuite les médiations.

C'est dans la modélisation des composants métiers qu'intervient le Data Model.

Je pense qu'au début d'un projet on doit d'abord se poser des questions comme:

1. Doit-on avoir une approche de modélisation dite Waterfall ou en itérations succésives ?
2. La cible est-elle java/jee ou autres ?
3. A-t-on des compétences en interne ? si oui il faut d'abord privilégié ces technologies ?

vous parlez des langages cibles: java ou .NET
Nous pensons qu'un projet UML doit être déconnecté de l'implémentaion: nulle part dans l'article on a parlé du langage cible

Pour ce qui concerne les itérations, nous supposons que vous voulez parler des moteurs MDA de génération de code qui prennent en entrée le projet UML et qui en sortie génèrent dans un langage cible donné et sur la
base d'un framework donné , une bonne partie du code : tel est par exemple le cas des outils comme EclipseUML (avec en particulier le plugin Omondo) qui permet de faire son projet UML dans eclipse et de générer du code directement Eclipse.

Dans le même régistre, chez Koossery Technology nous utilisons le moteur MDA Optimadev qui fera si nos équipes de dev ont du temps, l'objet d'une publication sur notre retour d'expérience dessus.
Mais déjà nous pouvons dire que dans le cadre des itérations un des gros soucis est le rountrip qui est mal supporté par la plupart des outils mda

Afin de ne pas s'écarter du sujet nous proposons qu'on revienne sur les outils MDA dans une autre discussion à l'occasion d'articles dessus.

Cordialement,

Baké Jc. BAKENEGHE
Centre de Service Devpt Projets Forfaits JavaJ2ee & .NET
Koossery Technology

[Vlade]

Le début est bien et faire des Cas d'utilisation est une bonne idée. Ce qui me semble léger est la réponse technique aux Cas d'utilisation.
A ce moment l'utilisateur doit décider s'il veut partir d'une méthodologie waterfall ou en itération.

L'itération que je décrit est un model qui donne un code et ensuite ce code est complété par le developpeur afin d'avoir un exécutable. Ensuite le client regarde et complète graphiquement et au niveau modèle afin de redonner aux developpeur des informations précises sur ce qu'il veut changer. A ce moment on refait une autre itération et cela recommence en boucle. Le model ne doit pas générer de code avec une transformation mais doit être incrémentale avec natif Java et natif UML, sinon on perd la logique entre le modèle et le code une fois que le code est factorisé par le développeur. On arrive aux limites du MDA traditionnel.
A ce moment on doit aussi réjouter les règles métiers, voir les contraintes et requirements. Je veux dire qu'a chaque itération on doit rajouter ou changer requirements, contraintes et règle métiers. Ceci n'est possible que si on prend une approche meta modeling et non MDD. C'est à ce moment que la seul façon de faire du MDA et de l'agile ou approche en itération est l'utilisation de la meta modélisation.

Je sais qu'en UML tradionnel on parle de CIM (requirement) ensuite de PIM (modélisation indépendante de la cible) ensuite de PSM (e.g. platform specific model) et enfin du passage au code. Mais là c'est hors sujet si l'utilisateur décide de partir d'une apporche en itération.
Tout doit être mélanger et travailler en itération. Aussi bien le modèle que le code que les requirements, que les règles métiers.

Le data model c'est pas de l'UML donc hors sujet !!
En conclusion votre sujet est trop léger dés qu'on passe d'un UML théorique à un UML en action

Vlad Varnica
Omondo

[ktechlab]

Dans l'article que nous présentons il s'agit d'une méthode (framework, cadre de travail) pour modéliser un projet en langage UML.
Maintenant au delà de la modélisation UML, nos équipes de devpt afin d'augmenter la productivité utilisent les outils MDA qui prennent en entrée le projet UML et génèrent du code: comme nous l'avons signalé, chez Koossery Technology nous utilisons principalement l'outil MDA Optimadev. De façon expérimentale notre cellule Architectures & Outillages examine d'autres outils MDA (plugin Omondo eclipseUML, Sculpture pour les projets .NET etc...)

Pour ce qui est de nos retours d'expérience sur le MDA, cela fera l'objet d'un autre article dès que nous aurons du temps.
Mais à présent, notre article traite de UML uniquement, pas de MDA.

Cela étant nous partageons ce que vous dites concernant les stratégies de MDA: effectivement nous aussi on opère par vague.....Et comme on disait, il y'a de gros soucis sur le roundtrip qui est mal pris en compte par ces outils MDA.

Cdt

Baké Jc. BAKENEGHE
Centre de Service Devpt Projets Forfaits JavaJ2ee & .NET
Koossery Technology

[Vlade]

Baké,

Je pense que votre initiative de faire un tutorial UML afin d'aider les utilisateurs à commencer des projets UML est une bonne initiative

Attention à votre message en terme de communication car il semble que vous soyez favorable aux approches itératives dans un contexte de réalisation de projet mais que sur vos commentaires on pourrai croire que vous rester figé sur une approche dite "Waterfall".