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".

[ulrichnansi]

Bonjour,
je n'ai pas encore lu l'article, mais quand je le lirai, je vous ferai part de mes remarques et suggestions.
Déjà je trouve l'initiative louable pour nous les développeurs.

[ElbeDD]

Bonjour,

La "structuration" d'un projet UML est justement ce que je recherche actuellement (informations/bonnes pratiques), ainsi que les générateurs de code automatique d'application JEE à partir d'UML (enfin dans un 1er temps, quelles extensions UML pour les notions JSP/servlet/... ce qui me renvoie sur MDA).

La "Structuration" des digrammes UML (nommage en premier lieu) me semble une évidence, et pourtant, c'est le premier article que je trouve sur le sujet.
A titre personnel, je préfixe aussi mes diagrammes "Use case" par "UC"(...). Les propositions que vous faites sont elles celles de votre entreprise (je m'en doute :enrichies avec les expériences, nouveaux collaborateurs,...) où bien reposent-elles aussi sur d'autres normalisations/échanges ? Si c'est le cas, pouvez vous nous citer vos sources (je ne les ai pas vu sur le pdf). Par ailleurs, j'aimerai avoir plus d'argumentation sur les choix. (Peut etre 2 versions du document: 1 pense bete pour agir-et découvrir-, 1 document argumentaire pour ne pas remettre en cause les choix à chaque instant)

En effet:
-"numéro d'ordre de l'UC de format 0xy"==> Pourquoi 3 chiffres dont le 1er à 0 (Même si 0 à 99 me semble largement suffisant, sinon il faudrait rajouter une profondeur dans les uses cases)
-Par scenario nominal, pas plus de 9 cas exceptionnels ? (même si a titre personnel, je n'ai pas encore eu le cas)
- Pourquoi mettre "Nominal",... en toutes lettres ?

Sinon, je vais poursuivre ce document et regarder d'un peu plus près votre "organisation d'un Use Case Model" qui me semble interressante.


Par ailleurs, est-ce qu'une recherche sur MDA peut faire évoluer cette reflexion ? (Y'a t'il des prérequis sur lequels se basent les outils et qu'il faut donc prendre en compte dès le départ)

Merci.

Cordialement,

[ktechlab]

La "structuration" d'un projet UML est justement ce que je recherche actuellement (informations/bonnes pratiques), ainsi que les générateurs de code automatique d'application JEE à partir d'UML (enfin dans un 1er temps, quelles extensions UML pour les notions JSP/servlet/... ce qui me renvoie sur MDA).

Sur la base de la structuration du projet UML tel que présentée dans l'article nous générons une grande partie du code de nos projets (C# ou Java J2ee) en nous appuyant sur un outil MDA (Optimadev, dont un article interviendra très vite afin de partager les retours d'expériences).

L'outil mda Optimadev nous permet de générer les parties:

• front-end(webapp ou winapp)
• back-end(orientée service et comprenant les couches services et dao)
• middleware .

NOTES IMPORTANTES :

• pour la génération de la partie front-end web, nous nous appuyons sur les framework Struts2 ou JSF pour Java
• pour la génération de la winapp, nous nous appuyons côté .NET sur le framework open source mvc koosseryMVCwin qui est hébergé sur Codeplex (http://koosserymvcwin.codeplex.com/) et dont une publi
  introductive est ici Framework mvc pour les winform .NET
• pour la génération de la partie server, nous nous appuyons sur un framework orienté SCA (Service Component Architecture)
• pour la partie middleware, nous nous appuyons sur le framework Spring essentiellement

Pour ce qui concerne la génération des vues (pages .jsp par exemple), l'outil Optimadev est entrain d'être travaillé de sorte que celles-ci soient générées sur la base de templates.

....
Les propositions que vous faites sont elles celles de votre entreprise (je m'en doute :enrichies avec les expériences, nouveaux collaborateurs,...) où bien reposent-elles aussi sur d'autres normalisations/échanges ?
....

nous nous sommes basés sur les stéréotypages classiques qu'on trouve partout sur les projets UML.
Puis au fur et à mésure des projets, nous avons systématiquement essayé de voir comment mettre en place un cadre de travail pour nos projet UML.
Le but ultime est d'optimiser la chaîne:
"projet uml--> mda Optimadev -->génération de code"

....
-"numéro d'ordre de l'UC de format 0xy"==> Pourquoi 3 chiffres dont le 1er à 0 (Même si 0 à 99 me semble largement suffisant, sinon il faudrait rajouter une profondeur dans les uses cases)
....

en effet comme vous le soulignez, nous n'avons pas encore vu de projet où un module fonctionnel contient plus de 99 UC !
Cela étant si cette plage venait à ne plus suffire, une adaptation va s'imposer afin de contenir tous les UC du module fonctionnel concerné: par exemple on pourrait décider que le 1er chiffre varie aussi au lieu d'être fixé à 0, ce qui nous donnerait potentiellement 999 UC...

....
-Par scenario nominal, pas plus de 9 cas exceptionnels ? (même si a titre personnel, je n'ai pas encore eu le cas)
....

en effet, pour un UC donné, nous n'avons pas encore vu plus de 3 ou 4 cas exceptionnels pour un nominal
Maintenant cela peut arriver d'avoir plus de 9 cas exceptionnels...dans ce cas une adaptation s'impose afin de convenir d'une nouvelle convention avec l'équipe du projet.

....
- Pourquoi mettre "Nominal",... en toutes lettres ?
....

votre remarque est pertinente dans la mesure où du moment où le numéro du SC est x0 alors le SC est censé être nominal.
Maintenant, en plus des numéros, nous aimons bien qu'à la simple vue du nom du SC on sache qu'il s'agit d'un cas nominal sans avoir à fouiller ce que la convention dit...

....
Par ailleurs, est-ce qu'une recherche sur MDA peut faire évoluer cette reflexion ? (Y'a t'il des prérequis sur lequels se basent les outils et qu'il faut donc prendre en compte dès le départ)
....

nous avons eu besoin de structurer nos projet UML car on utilise par la suite le moteur MDA Optimadev pour la génération du code du projet
Le moteur MDA fera l'objet d'une publication très rapidement afin de pousser la réflexion comme vous dites...

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