Discussion :

[le Daoud]

Bonjour,
dans le livre UML en action, je lis p257 que se trouve dans le "noyau applicatif" les éléments suivants :
1. la classe Vue (qui représente les fenêtres ihm)
2. la classe Document, qui réprésente les entités qu'un utilisateur manipule au travers d'une ou plusieurs vues.
3. la classe CommandeApp représente les processus de l'application.

Je ne comprends pourquoi la vue n'est pas dans le "noyau présentation"...?

cependant, p308 je lis :
"Dans la couche de présentation :
- la fenêtre ou la page transforme les événements de l'utilisateur en action
- le contrôleur centralise les actions déclenchées depuis l'ihm..."

J'en perds mon (peu d') UML
Merci
David

PS : <=> que met-on dans la couche présentation et que met-on dans la couche applicative ?

[alex00]

La vue est bien dans le noyau présentation.

cette discussion peut t'aider:
http://www.developpez.net/forums/vie...light=#1339834
on y fait la distinction entre MVC et BCE.

[le Daoud]

Merci beaucoup pour ta réponse.

Je n'arrive cependant pas bien à situer justement tous ces concepts et je ne trouve pas de ressources dessus... L'architecture logicielle est un véritable enfer pour un néophite qui zone sur le net et dans des livres (genre uml en action) qui ne sont pas clairs (à mon gout).

Pour moi, et selon ce que j'avais mémorisé du livre Uml, modéliser un site e-commerce, BCE et MVC c'était pareil !

peux-tu préciser :

Remarque :
BCE colle à la réalisation des cas d'utilisations (méthode de I. Jacobson)
MVC colle aux architectures java (J2EE, Struts, ...)

A+ et merci
David

edit : j'ai trouvé dans mon glanage cette étude de cas intéressante, simple mais claire http://dmi.ensica.fr/Cooj/downloads/CorrectionBiblio.pdf

[ego]

MVC est un design pattern permettant de décorréler la présentation des données présentée.
BCE n'est pas un design pattern. Les boundary, control et entity sont justes des stéréotypes de classe, des "types" de classes, te permettant de classer tes classes en 3 "grands" types. Ceci indépendamment de tout design pattern.
Ce que dit la classification BCE c'est que pour bien modéliser un système, il faut distinguer les classes d'interface (IHM ET classes faisant l'interface avec d'autres systèmes/applications informatiques), les classes plutôt orientées "traitements purs ou enchainement de traitement" (control) et les classes plutôt orientées "données" qui peuvent d'ailleurs comporter des traitements (entity).
Cette distinction est souvent utilisée en "analyse" pour distinguer des types de classes avant d'appliquer des design patterns plus précis en conception.

BCE pourrait être qualifié de pattern d'analyse si on veut...

[le Daoud]

Merci

Encore un chose :
Dis-je une bêtise si j'affirme ceci :

M est issu d'un E
V est issu d'un B
C est issu d'un C

?

David

[ego]

tu ne dis pas de bétise !!!

[le Daoud]

Merci pour tout

David

[djflex68]

Ce que dit la classification BCE c'est que pour bien modéliser un système, il faut distinguer les classes d'interface (IHM ET classes faisant l'interface avec d'autres systèmes/applications informatiques), les classes plutôt orientées "traitements purs ou enchainement de traitement" (control) et les classes plutôt orientées "données" qui peuvent d'ailleurs comporter des traitements (entity).

Ego, si tu as un article ou un tutorial sur le sujet ça m'intéresse assez. On a encore trop tendance dans notre boîte à mettre des traitements métier dans des objets qui auraient pu être réutilisable (ce qui les rend du coup non réutilisable)

[ego]

Tu peux lire ceci : http://ego.developpez.com/uml/tutori...esTraitements/

[djflex68]

lol je l'ai déjà lu

[ego]

Fais le lire autres personnes de ta boîté, si tu es convaincu, bien sûr

[djflex68]

ben j'en suis convaincu ! en fait ce que j'aurais aimé c'est un exemple pratique de la distinction d'une classe purement métier par rapport à une classe réutilisable lors des phases d'analyse, et lors de l'implémentation au moment du développement... Mais je suis pas sûr que qq chose d'aussi précis puisse se trouver .. en tout cas je ne manquerai pas de communiquer ton doc aux autres personne de la boîte..

[ego]

Pour ton exemple, saches que la réutilisation est qq chose de très contextuel aussi un exemple n'a pas beaucoup de sens car dans la pratique, tu auras un cas différent et tu devras décider si cela à du sens de dire que qq chose est réutilisable. D'ailleurs le mot réutilisable est parfois un peu pompeux; il suffit déjà de voir si dans ton appli, il y a des classes qui sont utilisées par plusieurs autres, c'est déjà cela la réutilisation (on peut dire aussi factorisation tout simplement)