Des outils (meilleures pratiques?) Pour un développement basé sur un modèle?

Question

Développement de logiciels piloté par les modèles.

Si j'ai bien compris, cela augmente le niveau d'abstraction de la conception afin de mieux refléter le domaine dans lequel le logiciel tentera de s'exécuter. C'est beaucoup dire en une phrase.

La communication entre les experts du domaine (client) et les développeurs est cruciale pour que cette méthodologie fonctionne. Ce que je veux savoir, c’est s’il existe une suite d’outils ou un ensemble de meilleures pratiques qui facilitera la poussée initiale de MDSD? Une fois que le domaine est développé, qu’en est-il de la correspondance de ce modèle avec un ORM (ou autre)?

Je suis en train de plonger dans le domaine de MDSD et DSL afin que toutes les idées ou commentaires constructifs soient appréciés.

Answer 1

Si vous développez sur des plates-formes Microsoft, vous pouvez également consulter Oslo. Il y a un bon aperçu ici: http: // www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx

Voici une tonne de liens de Chris Sells: http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic= 2197

Je ne suis pas encore prêt à assimiler la conception pilotée par le domaine au développement de lecteur de modèle.

Vous voudrez peut-être également consulter l’architecture dirigée par les modèles (OMG MDA) pour une perspective bien que probablement pas beaucoup pour rouler la vôtre.

Un gros problème dans Model-driven - tout est lié à la provenance de l’expertise qui dérive des implémentations des modèles et au niveau de maintenance (et de débogage). Mon test des livres disponibles serait de savoir comment ils rendent le pipeline compréhensible et dans quelle mesure on peut comprendre le chemin parcouru depuis la modélisation jusqu'au déploiement, puis vice-versa.

Answer 2

si vous programmez en .net, vous devez lire "Application de modèles et de conceptions basés sur le domaine". par Jimmy Nielsson. Il a également une section sur ORM (NHibernate), SOA et injection de dépendance.

Dans tous les cas, vous devez consulter la rubrique "Conception pilotée par le domaine". par Eric Evans. C’est un classique où vous pouvez trouver des informations précieuses sur les modèles et les meilleures pratiques pour la conception dirigée par domaine

Answer 3

Avertissement: Je suis un développeur d’applications d’entreprise. Le point de vue suivant est certainement façonné par mes expériences dans les tranchées de l'informatique d'entreprise. Je suis conscient qu'il existe d'autres domaines de développement logiciel. En particulier dans le développement de systèmes industriels et / ou embarqués, le monde pourrait être différent.

Je pense que MDSD est encore trop lié à la génération de code.

La génération de code n’est utile que lorsque votre code contient beaucoup de bruit et / ou est très répétitif. En d’autres termes, lorsque votre code ne peut pas se concentrer principalement sur la complexité essentielle, il est pollué par une complexité accidentelle.

À mon avis, la tendance actuelle des plates-formes et des frameworks est précisément de supprimer la complexité accidentelle et de laisser le code de l'application se concentrer sur la complexité essentielle.

Ainsi, ces nouvelles plates-formes / structures réduisent considérablement les effets du mouvement MDSD.

Les DSL (texte) sont une autre tendance qui essaie de permettre de se concentrer uniquement sur la complexité essentielle. Les DSL peuvent être utilisés comme source pour la génération de code, mais ils ne sont pas principalement liés à la génération de code. Les DSL (en particulier les DSL internes) laissent généralement le fichier ouvert pour être interprété / exécuté au moment de l'exécution. [la génération de code d'exécution se situe quelque part entre].

Donc, même si les DSL sont souvent mentionnés avec MDSD, je pense qu’ils sont vraiment une alternative au MDSD. Et étant donné le battage médiatique actuel, ils tirent également l’élan du mouvement MDSD.

Si vous avez pour objectif ultime de supprimer la complexité accidentelle de votre code (je sais que cela est fictif), vous êtes alors parvenu à un modèle textuel de votre problème commercial. Cela ne peut pas être simplifié davantage!

Les jolis encadrés et schémas n'offrent pas une autre simplification ni une élévation du niveau d'abstraction! Ils peuvent être bons pour la visualisation, mais même cela est discutable. Une image n’est pas toujours la meilleure représentation pour saisir la complexité!

De plus, l'état actuel de l'outillage impliqué dans MDSD ajoute un autre niveau de complexité accidentelle (pensez: synchronisation, diffing / fusion, refactoring ...) qui annule fondamentalement l'objectif ultime de simplification!

Regardez le modèle ActiveRecord suivant pour illustrer ma théorie:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

Je ne pense pas que cela puisse être simplifié davantage. De même, toute représentation graphique avec des cases et des lignes ne constituerait pas une simplification et n'offrirait plus de commodité (pensez à la mise en page, au refactoring, à la recherche, à la différence ...).

Answer 4

MDD peut être très complexe ou relativement simple.

Si vous souhaitez automatiser la transformation de vos différents modèles (en UML, par exemple) en code et en ingénierie aller-retour, vous pouvez vous procurer des outils sophistiqués.

Ou

Vous pouvez dessiner les modèles et construire le code plus ou moins manuellement, en utilisant une transformation unidirectionnelle (modèle en code).

L’idée de créer un modèle est d’abord une pratique exemplaire bien établie. On l'appelle souvent "design". Les problèmes se posent lorsque les gens associent conception et spécification. Le modèle de ce qui sera construit n'est pas une spécification de programmation. C'est une abstraction qui peut être utilisée pour évaluer la correction, définir des cas de test, rédiger des spécifications, etc.

Vous n'avez pas à tout modeler. Vous pouvez démarrer MDD en ayant un modèle de données, indépendant de toute implémentation spécifique.

1. Vous dessinez votre modèle en utilisant UML.

2. Vous transformez le langage UML en définitions de classe.

3. Vous utilisez une couche ORM (ou ODBMS) pour mapper vos modèles sur un type de stockage.

Vous n'avez pas besoin de plus que cela. Ce que vous devez faire est de vous concentrer sur l’élaboration du modèle avant de vous attaquer à trop d’autres problèmes.

Les problèmes proviennent généralement de toutes sortes d’optimisations prématurées intervenant lors du développement de logiciels. Premiers sauts dans la conception physique des SGBDR. Premiers sauts dans la conception de pages Web et leur utilisation pour piloter le modèle de données. Premiers pas dans la définition de l’architecture de serveur et l’allocation de stockage.

Answer 5

Vous devriez lire cet excellent article sur les meilleures pratiques MDSD, rédigé par Markus Voelter: http: //www.jot.fm/issues/issue_2009_09/column6.pdf

En ce qui concerne l'option MDSD / DSL, l'écosystème EMF ( https://www.eclipse.org / modelling / emf / ) fournit de nombreux éléments de construction utiles:

• implémenter des métamodèles et des éditeurs de modèles (EMF)
• implémente les éditeurs de modèles (EMF, Sirius, Xtext ...)
• gérer la collaboration et l'évolutivité (EMF-Transaction, CDO)
• implémenter des règles de validation de modèle (validation EMF)
• implémenter des générateurs de code (Acceleo, Xtend / Xpand, Mwe ...)
• implémenter des générateurs de documents (pxDoc, m2doc ...)

Une option intéressante pour réduire les investissements en outillage peut également consister à utiliser un modélisateur UML extensible et à définir vos propres profils UML et vos outils personnalisés au-dessus du modélisateur réutilisé (la liste précédente est toujours adéquate si votre modélisateur UML est basé). sur l’implémentation UML2 / EMF).