UML n'est sans aucun doute pas la réponse à tout. Par contre l'intérêt d'un modèle auprès duquel tous les intervenants d'une équipe peuvent se référer ne fait aucun doute, il centralise la conception choisie et représente une abstraction dy système développé.
La génération de code rationnal rose par exemple est totalement à l'opposée de celle que l'on prône, typiquement avec rational la maintenance du modèle va être fastidieuse si l'on s'en sert pour générer car ce dernier va autant définir des éléments techniques que des éléments fonctionnels.
Ici le module de génération n'est pas une couche en plus mais bien un "assistant" pour aider à la maitrise de toutes ces couches (architectures n-tiers...) le modèle ne tient pas compte de ces choix qui sont techniques et reste centré sur les aspects fonctionnels, les objets métiers, les composants logiques...
Le module s'occupe d'orchestrer les choix techniques, si la façon dont il les orchestre ne convient pas alors il est facile de re-définir uniquement la partie qui nous intéresse pour répondre à une problématique particulière.
Quand à l'imprecision d'UML je suis tout à fait d'accord, UML est un standard basé sur le consensus "a maxima", autrement dit on peut exprimer beaucoup de choses de différentes façon voir même des choses fausses!
Il n'empèche que ça reste un formalisme bien connu des informaticiens et que c'est un excellent support pour échanger lors de la conception.
Par contre pour beaucoup de problématiques plus spécifiques la définition de son propre formalisme va être pertinente et c'est là que les méta-modèles spécifiques interviennent. Ils permettent d'avoir une modélisation plus précise, plus simple car plus proche des besoins fonctionnels et moins sujette à erreurs.
Le méta-modèle formalisant les concepts métiers d'une entreprise facilite largement les échanges MOA/MOE et du fait de sa précision est plus facilement valorisé dans une génération de code.
Nous mettons en oeuvre des approches comme celle ci régulièrement avec nos client et les résultats sont toujours intéressants, on adresse ainsi les problèmes de complexite et de précision par un langage dédié exploité par un "chef d'orchestre" qui va le traduire en architecture technique.
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 2.
La génération de code rationnal rose par exemple est totalement à l'opposée de celle que l'on prône, typiquement avec rational la maintenance du modèle va être fastidieuse si l'on s'en sert pour générer car ce dernier va autant définir des éléments techniques que des éléments fonctionnels.
Ici le module de génération n'est pas une couche en plus mais bien un "assistant" pour aider à la maitrise de toutes ces couches (architectures n-tiers...) le modèle ne tient pas compte de ces choix qui sont techniques et reste centré sur les aspects fonctionnels, les objets métiers, les composants logiques...
Le module s'occupe d'orchestrer les choix techniques, si la façon dont il les orchestre ne convient pas alors il est facile de re-définir uniquement la partie qui nous intéresse pour répondre à une problématique particulière.
Quand à l'imprecision d'UML je suis tout à fait d'accord, UML est un standard basé sur le consensus "a maxima", autrement dit on peut exprimer beaucoup de choses de différentes façon voir même des choses fausses!
Il n'empèche que ça reste un formalisme bien connu des informaticiens et que c'est un excellent support pour échanger lors de la conception.
Par contre pour beaucoup de problématiques plus spécifiques la définition de son propre formalisme va être pertinente et c'est là que les méta-modèles spécifiques interviennent. Ils permettent d'avoir une modélisation plus précise, plus simple car plus proche des besoins fonctionnels et moins sujette à erreurs.
Le méta-modèle formalisant les concepts métiers d'une entreprise facilite largement les échanges MOA/MOE et du fait de sa précision est plus facilement valorisé dans une génération de code.
Nous mettons en oeuvre des approches comme celle ci régulièrement avec nos client et les résultats sont toujours intéressants, on adresse ainsi les problèmes de complexite et de précision par un langage dédié exploité par un "chef d'orchestre" qui va le traduire en architecture technique.