Discussion :

[Sancho]

Bonjour à tous,

Je dois réaliser un mémoire d'ingénieur, en m'appuyant sur mon expérience professionelle, autour du thème:

Comment la méthode peut s'appuyer ou interragir avec les framwork, pattern, outils, en particulier dans le domaine java/j2ee ( appli web )

J'imagine en terme de productivité et particulier sur la 2e partie du cycle de vie ( spec détaillées, realisation, maintenance )

je ne sais pas trop par où commencer ...

Merci d'avance pour vos conseil, je suis preneur de toutes remarque

[ego]

regardes ce qui est dit sur le 2TUP ou le RUP

[Sancho]

Merci pour ta reponse
j'ai regardé, mais cela reste trés abstrait.

juste pour remarque:

(1) les méthodes RUP, 2TUP ... par définition : sont structurantes

mais
(2) les framworks Struts Spring : sont structurants
(3) les pattern, outils : sont structurants

Modus Ponens -> 2 et 3 sont des méthodes

QUESTION : Comment les méthodes classiques (1) s'appuies
ou peuvent s'appuyer sur (2) et (3) et ne pas travailler en meta

[Yveke]

Hello,

A mon sens le RUP (1) définit un processus de cycle de vie complet d'un projet informatique et utilise 2 et 3 lors de ses disciplines.
En effet, le RUP définit un ensemble de disciplines (business modeling, requirements, Analysis and design, implementation, test) répétées au cours d'itérations successives, tu utilies des frameworks et des designs patterns lors de disciplines particulières comme dans l'analyse et le conception.

Donc pour moi on a plutot 2 et 3 (des méthodologies) qui reposent sur 1 (un processus complet). Le débat est ouvert....

Yves

[Sancho]

Je suis tout à fais d'accord,

mais j'ai l'impression que le rôle que jouent ces modèle pré-spécifiés
n'est pas correctement pris en compte dans les méthodes de gestion de
projet.
en particulier sur l'arhitecture technique et l'organisation de la conception. De tel sorte qu'il serait possibl e de commencer les spécifications
détaillées et le dev en même temps que la conception.

je ne sais pas si certaine méthode permettent cela ???

[ego]

je pense qu'il y a confusion des genres !!
une méthode ou processus, c'est pareil, on ne va pas se lancer dans des débats d'experts/puristes sur une éventuelle différence, cela ne sert à rien.

RUP et 2TUP, et plutôt RUP d'ailleurs, sont des méthodes. Dans le cadre d'une méthode, on fait des choses. Notamment, on utilise une architecture de référence (cf. RUP) ou on la construit. Cette architecture de référence peut utiliser des frameworks (tes 2 et 3). Ces frameworks s'inscrivent dans l'architecture à différents niveaux / couches. La méthode ne fait que situer l'usages des frameworks dans un processus de travail mais ne remplace pas la documentation des frameworks qui, elle, guide l'usager dans l'utilisation précise de chaque framework.

Donc ne mélangez pas tout, il y a d'un côté les méthodes qui doivent rester à un certain niveau et ne peuvent pas être précis comme la doc d'un framework (et heureusement !) et de l'autre côté des frameworks qui sont utilisés dans la méthode.
Mais sinon, regardez bien le RUP et vous verrez que beaucoup de choses sont dites sur l'architecture, les modèles en couches,...

[Médiat]

(1) les méthodes RUP, 2TUP ... par définition : sont structurantes
mais
(2) les framworks Struts Spring : sont structurants
(3) les pattern, outils : sont structurants
Modus Ponens -> 2 et 3 sont des méthodes

Tu ne dois avoir la bonne définition du modus ponens qui est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(A==>B, A ) entraine B

Ce que tu affirmes pourrait s'écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Méthodes inclus dans Structurants
Frameworks inclus dans Structurants
Patterns inclus dans Structurants
donc Frameworks union Patterns inclus dans Méthodes

tu n'as qu'à faire un diagramme de Vern (patates) le plus général possible pour te rendre compte que c'est faux.

[ego]

ouhai on peut dire que selon lui :

ma voiture est verte
l'herbe est verte
donc ma voiture est de l'herbe

ou un truc du genre....

y'a un os !? non ?

[Sancho]

Je sui s assez d'accord, le débat à ce niveau d'abstraction ne me passionne pas non plus. Surtout que le but est d' écrire mon mémoire, alors autant que cela m'interresse.

Je dois essayer de mettre en avant certaine recommandations valable pour les applications web en pariculier java/j2ee. Je ne peut pas me contenter de dire
utilise telle pattern , tel framwork ou tel outil , je dois pouvoir justifier ces choix et si possible expliquer les impacts sur la méthodes de conception.

Je ne sais pas comment cela ce passe sur vos projets mais actuelement sur le miens
, les livraison de l'équipe de conception ne détaille pas les use case de manière adapté. Du coup on ne peut pas correctement développer les premiers uc.
Alors si dans vos projets vous n'avez pas ce genre de problèmes, dite moi comment vous avez fait, sachant qu'une des contrainte est le temps de realisation du projet; implique de devoir commencer le dev en meme temps que la conception.

( parenthèse pour le modus ponens, qui aprés relecture est completement bidon,
tu fais bien de me le faire remarqué, ça m'apprendra à secher mes cours d'ia .. )

[Sancho]

ma voiture est verte
l'herbe est verte
donc ma voiture est de l'herbe

Je trouve cette affirmation tout à fait vraie*



*si tout ce qui est vert est de l'herbe

[ego]

donc...

sur "mes" projets, on fait du RUP et l'approche itérative permet de rapidemment passer au code.
Bien sûr que dire "utilisez tels outils" n'a rien à voir avec l'argumentaire nécessaire pour justifier de telle ou telle architecture.
L'usage des outils et frameworks doivent bien sûr être positionnés comme des réponses à une architecture définie.
Il te faut donc définir ton architecture de référence pour le projet et ensuite dire en quoi les frameworks répondrent à cette archi. Il est aussi fort probable que les frameworks eux-mêmes te mettent la puce à l'oreille pour définir ton architecture mais ce n'est pas grave car justement, les gens qui ont imaginé ces frameworks l'on fait en voulant apporter une réponse à certaines problématiques classiques d'architecture.
Il faut donc que tu définisses de "grands critères" auxquels doivent répondre ton archit : performance, modularité, évolutivité, testabilité,... tout ceci est classique mais cela te permettra de justifier l'usage de frameworks.
Ensuite, pour chaque élément de ton archi, tu repositionne les différents frameworks et surtout tu expliques comment tu veux que le projet en fasse l'usage. Car il y a souvent plusieurs manière d'utiliser le même framework (ne serait-ce qu'au niveau de règle de nommage des éléments que tu crées)
Regardes dans le RUP, il y a plein d'arguments classiques justifiant de tel ou tel choix architectural

[Sancho]

Merci pour la réponse, je vais chercher plus de précision sur RUP et puis faire un plan convenable, car honnetement je ne trouve pas grand chose à dire qui n'est deja été dit sur la pertinance d'utiliser des pattern, framework , modèles, plutot qu'autre chose.

[Yveke]

Si tu cherches des choses plus précises sur le développement itératif va également voir les articles de recherche de Barry bhoem, c'est le père du dévelopement en spirale (itératif) et ca peut être plus "sérieux" pour un mémoire. C'est quoi exactement le thème de ton mémoire ? T'es à quelle université ?

Yves