Model Driven Executable
31 January 10 12:22 PM | Nico | avec no comments
Importance des Modèles

Le développement logiciel est complexe. Il mêle plusieurs domaines d'expertise, fonctionnels et techniques, et implique la cohabitation des experts "métiers" et "techniques" sur le projet. Ce ne sont rarement les mêmes, et ils doivent communiquer, échanger, et valider que les informations perçues par les autres sont cohérentes avec leur vision du système. Schématiquement, la MOA définit le besoin à la MOE qui réalise:
 
 
Le recours à des modèles permet l'abstraction d'un certain nombre de concepts, et favorise la communication entre ces différents acteurs. Il est plus facile de se mettre d'accord et de s'assurer que la vision est commune, avec un modèle. Le modèle ne doit ni être trop technique, au risque de ne pas impliquer l'expert métier, ni trop métier, au risque que l'expert technique ne puisse pas le comprendre pour l'implémenter facilement.

En unifiant une vision commune des différentes fonctionnalités et en proposant un langage commun, le modèle permet le rapprochement entre les équipes de développements et les équipes fonctionnelles.
 

Jusque là, tout le monde est d'accord, le modèle est le produit de la phase de conception, indispensable à la mise en oeuvre du Système d'Informations. Finalement, tout le monde fait plus ou moins un modèle avant de commencer à développer.

Le Model-Driven-Architecture

En dématérialisant une partie de la logique de l'application, la tentation est grande de diminuer la rupture de charge entre l'homme et la machine. Moins il y a d'intermédiaire humain entre le concepteur et celui qui réalise, plus il y a de chances que l'application donne satisfaction à l'arrivée. C'est là qu'intervient la génération de code.


Le modèle devient source pour un générateur de code, car l'implémentation du modèle ne présente pas de difficultés, en apparence; reposant essentiellement sur du code technique, sans complexité métier, cette approche présente plusieurs avantages:
  • un alignement meilleur, parce qu'il existe une partie commune entre les machines de la MOA et la MOE.
  • un gain de temps sur le développement, parce que les allers et retours entre une demande de l'utilisateur et sa mise en production sont plus rapide.
  • une meilleure qualité, parce que moins de code écrit par des êtres humains, et donc autant moins de bugs écrits par le développeur

Regardons maintenant d'un peu plus près comment est utilisé le code généré par le modèle dans le développement. Il est clair que le modèle ne suffit pas, le besoin métier atteint un niveau de spécificité tel, qu'il est nécessaire de compléter avec du code dédié à l'application, écrit par le développeur. Ne serait-ce que pour des raisons d'IHM, par exemple, qui est toujours spécifique, le modèle ne peut pas être exhaustif (c'est pourtant le but affiché par quelques initiatives comme Oslo, qui n'a pas abouti à ce jour).

Le générateur de code produit un ensemble de classes et de fonctions, qui sont intégrées dans le projet de développement. Le développeur complète ensuite le développement, avec des compléments sur les classes générées (les classes partielles ont été en grande partie faites pour cela), et du code qui va appeler les fonctions générées. Du code est nécessaire pour réaliser l'interface entre le code métier, le code généré, et le code technique (constitué la plupart du temps par un Framework).


Le problème est que cette approche vieillit très mal. Les frontières entre le code généré et le code écrit sont floues, fluctuantes avec le temps, et la maintenance est difficile. Il y a un risque fort que les 2 mondes ne cohabitent plus dans une version N+1. Une fois que le code a été généré, le lien avec le modèle est rompu. Et une fois que le lien avec le modèle est rompu, le risque que celui-ci ne soit pas mis à jour est élevé, et le bénéfice du modèle est perdu sur le long terme. Il n'est pas rare qu'un modèle soit utilisé pour les premiers cycles de développement et abandonné par la suite, parce que la maintenance du modèle avec le code écrit est devenu trop complexe.

Une autre solution : le Model Driven Executable

Le modèle exécutable constitue une autre approche, qui ne repose pas sur un générateur de code et permet d'allier le meilleur des 2 mondes:
  • Capitaliser sur le modèle pour abstraire et structurer l'essentiel de la conception.
  • Garantir la maintenance du lien entre le modèle et l'application, puisque...
Le modèle est l'application, l'application est le modèle

Microsoft a ouvert la voie avec le DSL, qui est une avancée considérable pour unifier le modèle le code exécuté dans l'environnement de développement. En s'appuyant sur une séparation complète du code technique et du code métier, l'approche Aspectize permet d'étendre le modèle à bien plus de concepts que prévus initialement dans le MDA.
 
Que trouve-t-on dans le modèle ?

  • La logique des données, avec un modèle Entité-Relation, qui va bien au-delà du stockage: règles de validation, champs calculés, données et relations temporaires, le Modèle permet de décrire l'essentiel de la logique de l'application.
  • La configuration de l'application et des services: sécurité, log, trace, gestion d'erreurs, tous les services techniques de l'application sont configurables de façon déclarative.
  • Les liens entre l'IHM, le modèle Entité-Relation et les services configurés: avec un modèle de DataBinding et de CommandBinding, l'ensemble de la cinématique de l'application est décrite et non plus codée.

Que reste-t-il en dehors du modèle ?

  • Le code métier, principalement des règles de validation et des règles de calcul. Il s'agit de service stateless, qui peuvent être appelés sur le client ou sur le serveur. Ce code est dépourvu d'appels à des éléments techniques, il s'agit de code pure.
  • L'IHM, ou plutôt la description visuelle de l'IHM, puisqu'il s'agit, pour une Application Web, de fichier HTML et CSS, purement descriptif, ou de contrôles WinForm, dépourvus de la moindre ligne de code.
Comment interagissent le modèle et le code ?

Le modèle est rendu avec le serveur d'applications, qui contient le code technique, générique qui évolue peu. En s'appuyant sur le princide de Hollywood (qui mérite un post à part entière) on inverse la dépendance entre le code technique et le code métier; ce n'est plus le code métier qui appelle le code technique, mais c'est le code technique, celui du serveur d'applications, qui appelle le code métier et interprète le modèle.
 
 
 
On est ainsi affranchi de tout risque de décalage entre, ce qui serait le code généré dans une solution Model Driven standard (mais qui n'en est pas avec le modèle exécutable), et du code spécifique métier écrit par le développeur. La frontière n'est pas définie dans le code métier, mais elle faite une fois pour toute, dans le code technique. Non seulement, cela permet de garantir l'évolution du Système, avec une meilleure réponse aux changements, car le code métier pourra évoluer plus facilement, mais cela élimine tous les appels techniques qui polluent habituellement le code métier, et celui-ci est beaucoup plus lisible et maintenable.

Unifier le modèle pour la conception, le développement et la documentation

En maintenant le Modèle au niveau du RunTime, cela permet d'avoir une vision commune de l'application tout au long de sa durée de vie. Cela facilite sa maintenance, parce que la cohérence entre le modèle et l'application est constamment garantie. Une évolution du Modèle est immédiatement visible sur l'Application, il n'y a pas de rupture pour réconcilier le modèle avec l'application. Cela permet également de faire vivre l'application avec un modèle incomplet, dès le premier jour du projet.

Cela permet également de modifier des paramètres applicatifs à chaud, en agissant directement sur le modèle. Le modèle est non seulement utile pour la conception et le développement, mais également pour l'administration de l'application en production.

Enfin, parce que la documentation applicative est directement issue du modèle, elle peut être générée à partir du RunTime et reflète exactement le fonctionnel de l'application. En permanence, l'information indispensable contenue dans les modèles est accessible. Cela favorise le turn-over inévitable qui arrive tôt ou tard dans les équipes de développement.
 
Le Model Driven Executable est le chaînon manquant qui fait défaut au Model Driven Architecture. En unifiant modèle de conception et implémentation, il offre de nouvelles perspectives d'agilité et de souplesse. A la place de la génération de code, qui a déjà trouvé ses limites, l'élimination de code est une voie à privilégier pour améliorer considérablement le développement logiciel.
Classé sous : , ,
Comment la solution Aspectize vous permet-elle de réduire les couts et maitriser les budgets de vos projets .Net ?
08 December 09 02:35 AM | Nico | 1 comment(s)

(Cet article est disponible en téléchargement, sous forme d'un livre blanc, ici)

Qu'est-ce qu'une bonne architecture ?

C'est une architecture en plusieurs couches indépendantes.

La nécessité de bâtir des architectures en couches n'est plus à démontrer. Plus qu'un standard, la séparation des 3 couches bien connues que sont Présentation, Traitements et Données est aujourd'*** une évidence pour qui veut bâtir un Système d'Information pérenne et maintenable. Toute la littérature sur le sujet converge donc vers cette bonne pratique, et Microsoft ne fait pas défaut en illustrant ainsi les Best Practise d'architecture :


On y trouve tous les éléments classiques mis en œuvre par les architectes dans les projets. Leur principale difficulté va être de reproduire ce schéma-là dans tous les contextes métiers des projets. Pourquoi ? Parce que la mise en œuvre de cette architecture n'est pas indépendante du métier. Les UI Components et les Business Entities vont fortement lier le métier et l'implémentation.

Ce couplage est doublement dommageable pour les Systèmes d'Information. Premièrement, si l'architecture était vraiment indépendante du métier, elle serait faite une bonne fois pour toutes, et nul n'aurait besoin de la refaire dans chaque projet. Deuxièmement, puisqu'elle n'est pas indépendante, elle nécessite de connaître d'avance beaucoup trop de détails métier pour la mettre en œuvre correctement. Des choix structurants sont fait trop tôt, les projets sont livrés trop tard, et il suffit que le besoin utilisateur évolue un tout petit peu pour que l'impact vis-à-vis de l'existant se paie au prix fort. Les projets sont souvent en retard et plus cher que prévu parce que le besoin évolue.

Arrêtons-nous un instant sur les raisons qui font que l'architecture est difficilement indépendante du métier avec les approches actuelles.

La case Business Entities, qui porte bien son nom, indique l'endroit du modèle objet de l'Application. Par Modèle Objet, on entend un typage fort du contexte métier.

Si l'application gère une librairie, il y a de fortes chances pour qu'on y trouve un objet Livre et un objet Auteur. Le design de ces objets doit se faire très tôt, car c'est toute la logique métier qui est présente dans ce design. Il est quasiment impossible à un développeur d'imaginer sa couche logique sans des objets métiers spécifiques. Là où les difficultés arrivent, c'est que cette approche vieillit très mal car elle est rigide. En effet, il y a de fortes chances pour que l'objet Livre contienne une référence vers l'objet Auteur, et que l'objet Auteur contienne une liste de Livres. Ce lien étant représenté par du code, il va être exploité partout où l'Application en aura besoin. Si on imagine que la couche IHM veut tirer profit de ce lien entre Auteur et Livre (représenter la liste des Livres écrits par un Auteur), le lien va être présent dans les contrôles de l'IHM. Le typage fort du modèle métier est donc intrinsèquement lié aux contrôles de la couche de présentation. 

Imaginons un instant que le modèle évolue et qu'un Livre puisse avoir plusieurs Auteurs, les impacts seront nombreux, non seulement au niveau du stockage, mais également dans l'implémentation de la couche de présentation, alors qu'il suffirait logiquement de changer un label en une liste. Malgré toutes les précautions prises pour séparer les briques, l'indépendance des couches est rompue, le couplage est fort car les liens sont régis par du code et sont donc impératifs. C'est le principal défaut de l'Approche Objet.

Aspectize propose une nouvelle approche

Fondée sur une approche descriptive, elle réussit à séparer totalement le métier et la technique. Là où les liens sont traditionnellement impératifs, Aspectize propose une implémentation descriptive, qui permet rapidité, souplesse et totale indépendance entre les couches.

Respectant rigoureusement les paradigmes d'une architecture n-tiers, elle reprend logiquement les différentes couches d'une Application :


Regardons d'un peu plus près comment les différentes briques sont constituées et articulées les unes par rapport aux autres. Plusieurs éléments sont fondateurs dans la mise en œuvre de l'approche.

Le schéma relationnel, contexte métier central de l'application

Le Schéma est le lieu de définition du modèle logique métier. En représentant un modèle Entité/Relation, il permet de centraliser la définition de toutes les données manipulées par l'application.

La relation est au cœur du Schéma : si nous reprenons notre exemple précédent, nous avons vu que l'approche classique du modèle objet tendait à lier l'objet Livre et l'objet Auteur, en implémentant cette relation sur les objets eux-mêmes, avec des références croisées. L'approche d'Aspectize est de ne jamais lier deux entités directement, mais de considérer la relation comme étant un lien logique à part entière entre les différentes entités.


Nous avons une entité Livre, une entité Auteur et une relation Ecrit entre les 2 qui renseigne le fait qu'un Auteur Ecrit un Livre. Cette différence est fondamentale, puisqu'elle permet aux entités d'être réellement et constamment indépendantes entre elles et de considérer les relations comme des éléments du modèle à part entière. La structure de l'entité Auteur n'est pas impactée par l'entité Livre. Le Schéma peut évoluer beaucoup plus facilement : on peut imaginer qu'un Auteur écrive plusieurs Livres, et donc qu'un Auteur sera en relation avec plusieurs Livres. On peut imaginer une évolution avec une relation supplémentaire entre Auteur et Livre, telle que Recommande. La compatibilité du modèle est assurée car cette évolution n'impacte aucune modification d'Entités. Cette nouvelle relation sera chargée, ou peut-être pas, dans tous les contextes d'usage de l'entité Métier. L'indépendance des Entités permet de prendre cette décision de façon contextuelle ce qui contribue à la souplesse du modèle.

Précisons que ce modèle représente le contexte métier de l'Application, et non pas un modèle physique de stockage. Certes, on pourra stocker les méta-données physiques dans ce modèle, s'il s'agit d'une base relationnelle, mais le Schéma va bien au-delà et permet de stocker beaucoup plus d'informations complémentaires, utilisées dans l'Application : 

  • La validation des données, qui permet de définir les règles à appeler dans le cas d'une validation de données liée à un Contrôle ou à l'appel d'une Commande.
  • Les événements logiques liés à la création, modification ou suppression d'entités, qui permettent de configurer les appels de Commandes sur ces événements.
  • Le caractère Temporel d'une propriété, qui permet d'ajouter une dépendance avec le temps, de façon déclarative.
  • Des expressions calculées qui permettent de définir des agrégations et des propriétés calculées de façon déclarative.

L'implémentation de ce modèle, n'est pas un modèle objet, mais est réalisée avec le DataSet standard de .Net, conteneur idéal qui permet de stocker tout type de données relationnelles. Bien qu'il soit loin de faire l'unanimité au sein de la communauté des développeurs - sa manipulation est assez verbeuse, il n'y a pas d'intellisense, cela reste un objet technique qui nécessite une bonne connaissance pour être utilisé correctement - le DataSet a l'avantage d'être un conteneur générique de données bindable, serialisable, triable, filtrable, clonable, avec une gestion de l'état des données et une logique événementielle extrêmement puissante. Son usage dans l'infrastructure Aspectize est totalement transparent, et les principaux aspects négatifs ont été gommés ; l'IntelliSense est disponible, et la navigation dans les données est facile et intuitive. La souplesse et le dynamisme du DataSet en font un conteneur de données métier idéal, bien plus efficace qu'un modèle objet spécifique.

Cela permet de garder une approche générique pour beaucoup de fonctionnalités, et notamment le DataBinding.

DataBinding Relationnel et validation de données

Le DataBinding est une bonne pratique qui permet de s'affranchir d'écrire du code pour faire interagir, de façon bi-directionnelle, les données et les contrôles de l'IHM. Cette opération est réalisée de façon déclarative, et beaucoup de code fastidieux n'est plus à écrire. 

Pourtant, la technique de DataBinding proposée par Microsoft a quelques limites : 

  • elle fonctionne bien pour une grille ou uncontrôlesimple, mais elle ne fonctionne pas pour de nombreux autres contrôles, comme par exemple l'arbre.
  • elle nécessite d'écrire du code technique, que finalement peu de développeursmaîtrisent.
  • elle concerne essentiellement une Table simple, et ne permet pas de naviguer facilement dans les données relationnelles.

Avec Aspectize, le DataBinding est considérablement enrichi :

  • il est étendu à tous les contrôles standards du Framework .Net 2.0, y compris les arbres et les TabControl.
  • il est étendu au Web et aux applications Ajax, ce qui est une innovation unique (aucune implémentation de DataBinding en JavaScript n'existe par ailleurs).
  • il prend en compte l'aspect relationnel du modèle, et permet de tirer parti des relations entre entités, pour réaliser une navigation relationnelle sans écrire de code.
  • il permet d'associer automatiquement une validation de données, et permet d'exploiter une règle métier sans écrire du code.
  • il est complètement déclaratif, se gère via une interface graphique et intuitive, sans écrire la moindre ligne de code.

Le DataBinding Relationnel d'Aspectize permet ainsi de gérer de façon déclarative, l'intégralité des données dans l'IHM. En quelques clics de souris, et sans la moindre ligne de code, il est possible d'associer toute donnée du Schéma à un contrôle de l'Application.


 

Il suffit de choisir graphiquement l'Entité à afficher dans un contrôle, en tenant compte du chemin de navigation relationnelle des données. Ainsi, la structure d'un arbre va logiquement suivre la structure relationnelle des données, qui correspond le plus souvent à la logique d'affichage des données. Que l'interface soit Windows ou Web, la logique est exactement la même ; un contrôle affiche des données relationnelles, par une association logique entre ses propriétés et les Entités du Schéma.

La validation des données, qui reste une bonne raison pour écrire du code métier spécifique, est complètement intégrée au DataBinding. Chaque définition d'un DataBinding entre un contrôle et une donnée peut faire l'objet d'un contrôle de validation. Que la validation soit simple (non-nullité, limite supérieure ou inférieure, expression régulière), ou qu'elle fasse appel à une règle métier, écrite en .Net standard et de façon complètement indépendante de l'IHM, elle est complètement déclarative et ne nécessite aucun code. Il n'y a aucun code d'appel à écrire, aucun événement de contrôle à gérer, le câblage avec l'IHM a déjà été fait une fois pour toutes, ce qui constitue un gain de temps considérable et un gain de qualité évident, car quantités de sources de bugs sont ainsi évitées.

Architecture SOA et Command Binding

Le serveur d'Applications Aspectize est nativement et naturellement une plate-forme SOA. Le code métier écrit est automatiquement accessible comme un Service de l'Application, qui est l'élément fédérateur qui répond à une problématique métier. Il n'y a rien de particulier à écrire comme code ou à configurer pour créer un nouveau Service. Il suffit d'écrire le code métier en .Net standard, et le service sera rendu disponible par le serveur d'Applications. Et cela fonctionne, parce que le contexte métier n'est pas implémenté avec un modèle objet rigide.

La grande innovation du Serveur d'Applications Aspectize réside dans l'interception des appels : tous les appels à un service seront interceptés par le Serveur d'Applications. Le service métier bénéficie ainsi de tous les services techniques transverses implémentés et disponibles : conversion de données, gestion d'erreurs, sécurité, trace, log, bouchons, Load Balancing, Fail Over, sont automatiquement disponibles. Il n'est plus nécessaire d'écrire de code pour implémenter ces fonctionnalités, il suffit de configurer le service pour qu'il en bénéficie. Activer la sécurité d'une Application se fait en cochant une case, et de façon complètement indépendante du code métier. Un autre exemple emblématique est que toutes les exceptions sont automatiquement attrapées et loguées : il n'est plus possible d'avoir une exception non attrapée par le système. La robustesse des Applications est naturellement accrue sans efforts particuliers.

Configurer les intercepteurs est beaucoup plus simple et rapide que d'écrire du code et cela peut se faire tardivement, sans remettre en cause le code existant. Une Application non distribuée peut ainsi le devenir, même si cela n'a pas été prévu au départ. La mise en place d'une trace ou d'un bouchon peut se faire sans toucher à l'implémentation. L'Architecture applicative se décide au fur et à mesure des développements métiers, et n'a plus aucun impact sur la démarche projet. Ce n'est plus un pré-requis indispensable avant de commencer les développements. On peut ainsi développer des briques indépendantes et les assembler au fur et à mesure des besoins métiers. L'agilité est enfin possible.

De la même manière que le DataBinding Relationnel permet l'association déclarative d'un contrôle et de données, le CommandBinding permet l'association déclarative d'un événement IHM et d'un appel de service. Cette association qui donne lieu traditionnellement à l'écriture de code, et qui lie fortement les contrôles de l'IHM aux composants métiers, se fait maintenant de façon déclarative. Au lieu de faire un appel explicite et impératif dans l'événement OnClick d'un bouton, l'association entre le bouton et la Commande est fait tardivement et par simple configuration. Cela permet de disposer d'une IHM totalement indépendante des autres composants, ce qui n'était pas possible auparavant. La qualité des applications s'en trouve grandement améliorée, et la réutilisation des différents composants devient possible. Cette configuration est réalisée avec Binding Studio, qui permet de sélectionner de façon graphique et intuitive les éléments à associer. En quelques minutes, l'IHM est prête pour interagir avec les services métier du Serveur. Le Serveur d'Applications s'occupe de toutes les conversions de données à l'aller et au retour.

Avec l'infrastructure Aspectize, il n'y a plus de raisons pour écrire du code dans les IHM. On atteint le "Zero Line of Code" : c'est beaucoup de temps gagné et beaucoup de sources de bugs qui sont ainsi évitées. 

Vers un Système d'Information piloté par le métier

Baisse des risques, gain de temps, souplesse accrue du système, les applications gagnent en qualité. Il est beaucoup plus facile de construire des applications robustes. La plupart des problèmes techniques sont éliminés, et les développements sont concentrés sur le métier, dès le premier jour. Plus besoin d'investir massivement dans une conception d'architecture, qui aura beaucoup de mal à évoluer avec le temps pour concilier montée en charge et évolution des besoins.

Les traitements de la couche logique métier sont écrits en .Net tout à fait standard. Aucune intrusivité, pas d'usage d'API, le code standard permet d'exprimer le métier, avec des services indépendants, dans l'esprit des architectures SOA. Plus facile à écrire et donc à lire, le code métier est débarrassé de toute pollution technique : le lien avec le fonctionnel est beaucoup plus fort. La détection des erreurs est bien plus rapide, et les gains en maintenance sont immédiats. Le système peut enfin être piloté par le métier.

Les aspects techniques n'étant plus gérés par du code lié au développement métier, vous avez la garantie que cette gestion sera faite de la même façon dans toutes vos applications. Cela unifie l'ensemble de vos développements dans une implémentation conforme aux règles de l'art. Le temps où l'uniformité était liée à la responsabilité de chaque développeur est terminé. 

Là où les Framework traditionnels vous invitent à apprendre leurs API et à écrire du code, l'infrastructure Aspectize permet de disposer d'une architecture clé en main, par simple configuration, sans écrire une seule ligne de code. C'est une innovation majeure, en particulier pour les Applications Web full-Ajax, pour lesquelles il n'existe aucun environnement pour les réaliser sans écrire de code. La courbe d'apprentissage est rapide, il n'y a pas d'API à apprendre, vous travaillez avec votre environnement favori qui est Visual Studio et votre langage standard .Net. Il n'y a aucune fermeture : vous pouvez ajouter du code spécifique à tout endroit, l'infrastructure est totalement interopérable avec tout type d'environnement applicatif, ou composant tiers.

Les applications sont nativement capables de monter en charge, elles sont sécurisées, déployables en quelques opérations simples, dès le premier jour. L'approche permet de concilier l'agilité des Approches RAD avec la robustesse d'une infrastructure logicielle professionnelle.

Si les coûts de développement sont très nettement diminués, les coûts de maintenance sont encore plus fortement impactés. D'une part, il est beaucoup plus facile de faire intervenir des ressources différentes et nouvelles sur les projets, le coût de maintenance de la connaissance d'un projet est quasiment nul. D'autre part, l'impact d'un ajout ou d'une modification sur l'existant est très faible, voir inexistant. Le gain généré est permanent tout au long du cycle de vie de l'application, depuis son premier jour jusqu'à sa fin de vie.

Et demain, lorsqu'il s'agira de porter le SI sur le Cloud, cela pourra se faire sans le moindre changement dans l'implémentation. La plate-forme est portée sur Azure, la migration d'une Application d'un monde OnPremise à Azure est quasiment gratuit.

Les Garanties de l'approche Aspectize

L'approche Aspectize répond à toutes les problématiques d'Application Business, pour gérer des données relationnelles. Quel que soit le domaine, l'approche Aspectize garantit un résultat visible et opérationnel dès le premier jour du projet.

Si la baisse des charges de développement peut légitimement être divisée par 3 (estimation réalisée pour une application Web standard de gestion, type CRM), la baisse des coûts de maintenance est encore plus significative. Avec un impact proche de zero, vu qu'il n'y a pratiquement pas de code existant à impacter, l'ajout de fonctionnalité ou la modification d'éléments existants se fait sans aucun effort supplémentaire, lié à l'existant. Là où les approches traditionnelles rendent extrêmement couteux les modifications, du fait de la non-régression de l'existant, qui sera nécessairement impacté parce qu'il est implémenté par du code impératif.

L'intégration de la solution dans la suite Visual Studio permet l'acquisition et la maitrise de la solution extrêmement rapidement. Peu d'API à apprendre, peu d'éléments techniques à connaître, le niveau d'expertise technique requis pour construire un système d'information professionnel est logiquement tiré vers le bas. Il devient plus facile d'échanger les ressources, la montée en connaissance d'une application et la reprise d'existant se fait rapidement ; l'implémentation nécessite peu de documentation, les éléments constituant l'application (Schéma relationnel, DataBinding et CommandBinding) sont auto-documentés.

Enfin, et cela constitue peut être l'élément le plus novateur, l'approche Aspectize permet une maîtrise totale du budget d'une application. Quel que soit le domaine, le fait de disposer d'une application fonctionnelle chaque jour, permet de stopper un projet à tout moment sans perdre l'investissement initial. Cela ouvre des perspectives de nouveaux business model sur le métier du développement.

Classé sous : , ,
Soutien Oséo
08 October 09 12:47 PM | Nico | 1 comment(s)
OSEO soutient le projet d'innovation d'Aspectize.

Concrètement, nous obtenons un financement substantiel, sous forme d'avance remboursable, qui nous permet d'accélérer notre développement.

Le projet concerne essentiellement l'intégration des technologies suivantes:

  • Azure
  • SilverLight
  • Visual Studio 2010

C'est un projet ambitieux, qui va nous permettre de nous positionner sur des sujets au coeur de l'actualité MS. Et nous avons plein d'idées pour apporter notre valeur ajoutée autour de ces technologies. Nous aurons l'occasion d'y revenir au fur et à mesure de notre avancement.

Ce soutien nous fait du bien; au delà de l'aspect purement financier, c'est un nouveau tiers de confiance, et une nouvelle étape dans notre développement.

Classé sous : ,
Compte-rendu de la conférence de David Chappell sur Azure
08 October 09 12:07 PM | Nico | 5 comment(s)

David Chappell est un grand speaker. Je le savais déjà et je viens d'en avoir la démonstration lors de son passage à Paris, ce matin même. Il est invité par Microsoft à faire le tour du monde pour évangéliser la plate-forme Azure. Sa présentation est limpide, concise, il n'hésite pas à faire des pronostics sur l'avenir du Cloud, et il est tout simplement passionnant.

Il se défend d'abord de parler d'Azure au nom de Microsoft, il rappelle qu'il ne fait pas partie de MS, et qu'il donne son avis personnel. Il a par ailleurs publié un excellent white paper sur Azure, disponible ici.

David Chappell positionne rapidement le Cloud dans l'histoire de l'informatique: c'est la 6ème plate-forme à apparaitre en moins de 50 ans (après les Mainframe, les Mini, le PC Desktop, le PC Server et le Mobile), c'est un enjeu formidable et une chance inouïe de vivre actuellement une rupture de cette nature. D'ici 5 ans, pratiquement tous les ISV de la planète (cette conférence s'adressait spécifiquement aux éditeurs de logiciels) feront du Saas et auront une partie de leur offre dans le Cloud. Construire soit même sa plate-forme pour faire du Saas n'a pas plus de sens que d'écrire un système d'exploitation !

Si vous souhaitez tourner votre entreprise vers l'avenir, c'est dans cette direction qu'il faut regarder.

Vue d'ensemble de la plate-forme Azure 

Windows Azure se divise en 3 parties:

Windows Azure n'est pas exactement Windows dans les nuages, mais pas loin.

On disingue les Traitements et le Stockage, le tout étant géré par Fabric, le service d'infrastructure de la plate-forme.

Les Traitements

Le traitement comporte plusieurs instances de role (role Web ou Worker), qui sont loadbalancées automatiquement. Chaque "role" tourne dans sa machine virtuelle qui lui est propre. La configuration des différents rôles est définie dans un fichier XML au moment du déploiement, et la Fabric se charge de créer et configurer les différentes VM.

De la même façon que vous n'aurez pas accès à la VM comme un administrateur voudrait le faire, n'espérer pas disposer de Windows Azure (en tant qu'OS) chez vous. Il est peu probable que Microsoft change d'avis sur le sujet.

En tant que développeur, vous aurez juste une instance d'une Fabric locale, pour simuler votre application sur votre machine, avant de la déployer dans Windows Azure. A noter, qu'il n'est pas possible pour l'instant de débuguer une application Azure, une fois déployée; cela changera peut être avec les prochaines versions, mais pour l'instant, la seule source d'infos sur une application déployée est un service de logging (mutualisé, qui permet à tous les rôles de centraliser leur log).

Le Stockage

On distingue le stockage Azure et SQL Azure.

Le stockage Azure est accessible par http uniquement.

Il y a 3 formes de stockage dans Azure; les Blobs, les Tables et les Queues.

Les Blobs permettent de stocker des gros fichiers, comme des vidéos ou des images

Les Tables, qui portent très mal leur nom, car ce ne sont pas des Tables au sens d'une base de données; mais David Chappell qui avait l'habitude d'être très critique vis à vis du nommage des différents services par Microsoft, s'interdit désormais de le faire, depuis qu'il a été engagé sur le sujet, et il reconnait que c'est extrêmement difficile de bien nommer les choses, bref, une Table contient des données de type clé-valeur, il n'y a pas de schéma et pas de colonnes. L'avantage, est que cela Scale très bien, et qu'il est possible d'avoir des milliards d'éléments dans une Table Azure.

Les Queues qui permettent l'échange de messages, notamment entre les différents rôles, pour répartir des traitements par exemple.

SQL Azure est le stockage relationnel (anciennement SQL Data Services), qui correspond à une base SQL server en ligne, avec quelques fonctionnalités mineures en moins. C'est une très bonne idée que de l'avoir ajouter, car ce n'était pas prévu dans la version initiale. Une base de données comme SQL Server sait faire du Scale Up, est accessible par ADO.Net et offre beaucoup d'autres services (Reporting et OLAP). Mais on aura besoin que les données Scale Out, c'est à dire qu'elles soient distribuées. Il pense d'ailleurs que la limite de 10Gb sera revue à la hausse dans le futur (n'oublions pas qu'il s'agit d'une V1).

Il y a également les .Net Services. Il n'en a pas beaucoup parlé, juste mentionné le scénario avec les données à l'intérieur de l'entreprise qui fait intervenir le Service Bus qui est là pour ça (je n'ai pas tout compris, mais cela permet d'avoir une connexion tcp avec l'extérieur).

La migration d'une application .Net existante est en tout cas très facile:

  • à condition d'être stateLess
  • à condition de ne pas avoir besoin de privilèges particuliers, ce que Windows Azure interdit formellement (du coup, une application Win32 ou COM sera impossible à migrer).

Une application existante pourra être complétée par des services purement Cloud par la suite (comme l'usage de parallélisation massive ou du stockage massif).

Business Model

David Chappell a rappelé les tarifs de Azure en insistant sur l'extrême faible cout de stockage, surtout qu'il n'y a pas besoin d'un administrateur devant le serveur. Les tarifs sont clairs, il y a encore quelques questions sur la bande passante, mais pas de mauvaise surprise ; ils sont tout à fait concurrentiels.

Quels sont les scénarios de déploiement sur le Cloud ?

  • Application scalable; cela concerne peu de monde, tout le monde n'écrit pas FaceBook ou Twitter, mais il y en a tout de même quelques unes.
  • Application à charge fluctuante; par exemple un site de vente de billets de concert aura une charge brutale lors de la mise en vente des billets pour le prochaine concert de ColdPlay (c'est lui même qui a prit cet exemple)
  • Application temporaire destinée à être détruite; pour faire un prototype par exemple, ou pour un studio de cinéma qui a besoin d'une application dédiée sur un tournage et de la détruire ensuite.
  • Application qui a besoin d'être testée à un moindre coût avant d'être industrialisée. Le cas de la direction métier qui ne s'entend pas avec son IT est monnaie courante, et un très bon exemple de besoin du Cloud.
  • Application qui nécessite un fort volume de données; une application qui héberge des vidéos aura tout intérêt à être sur le Cloud (au moins pour les données).
  • Application qui nécessite une disponibilité permanente; évidemment, en premier lieu, les éditeurs en mode Saas. L'intérêt du modèle Saas n'est plus à démontrer et le Cloud est justement là pour ça.
  • Application qui nécessite de fortes charges de calcul; les applications qui font du Grid Computing, sont idéales pour tourner dans le Cloud, sans nécessité une infrastructure délirante, qui seraient peu rentable.
  • Application qui fait intervenir plusieurs partenaires, et dont aucun ne voudrait s'approprier l'hébergement et le stockage.

Et enfin, la baisse des coûts va être un formidable vecteur d'adoption des applications sur le Cloud; pas seulement pour les éditeurs, mais pour les grandes entreprises. Elles ne vont pas migrer toutes leurs applications du jour au lendemain, cela se fera progressivement, et en fonction des différents scénarios d'applications. Les scénarios hybrides (données ou traitement ou les deux sur le Cloud) est en tout cas très attractif.

Quelles sont les offres concurrentes ?

  • Le Hosting dédié. Non, Azure ne va pas tuer les hébergeurs et le métier du Hosting. D'abord, ce marché est beaucoup trop important pour Microsoft ! Ensuite il y a de réelles différences; plus de contrôles sur les machines, mais moins de charge d'administration dans Azure. Et là ou un hébergeur mettra plusieurs jours à vous fournir des ressources supplémentaires, c'est instantané sur le Cloud.
  • Amazon: le premier acteur du Cloud, historiquement un vendeur de livres ! L'offre d'Amazon permet à l'utilisateur d'avoir la main complète sur sa VM. C'est à l'utilisateur d'installer sa Base de données pour les données relationnelles.
  • Google AppEngine: très similaire, en terme de services à Azure. Vous ne voyez pas les VM, vous avez accès à des ressources. Sauf que l'intégration se fait en Python; il a fait un sondage pour savoir qui connaissait Python, 3 mains timides se sont levées. Dans la Silicon Valley, toute la salle aurait levé la main, nous a-t-il dit. L'offre de Google est donc clairement tournée vers les Startup et particulièrement la Silicon Valley. De plus, AppEngine ne permet que de faire des Applications Web, et pas du tout des applications serveurs au sens de Windows.
  • SalesForce: c'est un peu le Access du Cloud, qui permet de construire des applications clé-en-main facilement. Par contre, une fois chez SalesForce, vous aurez du mal à migrer votre application vers un autre environnement. Il rappelle au passage que SalesForce a été fondé par un ancien d'Oracle, qui sait très bien se lier à ses clients.

En résumé, il n'y a pas de meilleures plates-formes de Cloud qui sort du lot; elles sont toutes différentes, même si elles ont des zones de recoupement, et tout dépend de ce que vous voulez faire.

Quel niveau de confiance la plate-forme Azure va t elle recueillir lors de son lancement ?

Difficile à dire, mais à la vue des enjeux, de la baisse des coûts que cela représente, Microsoft et ses partenaires trouveront les éléments pour obtenir la confiance de leurs premiers clients. SalesForce a bien réussit à obtenir la confiance pour héberger les données stratégiques des entreprises dans le Cloud, ce qui n'était pas du tout gagné au départ.

Enfin, même s'il y a un certain nombre de règlementations qui contraignent les entreprises, notamment Sarbanes-Oxley, les éditeurs de plate-forme de Cloud en tiendront compte pour adapter leurs offres en conséquence. Azure a une plate-forme à Dublin, et en proposera surement d'autres en Europe.

En conclusion, David Chappell invite tout le monde à faire des essais, à partir de la CTP.

Voilà, une conférence d'une remarquable qualité, sur un sujet nouveau et très prometteur. Il n'y aura pas de vidéo de la conférence, et pour ceux qui ne le connaissent pas, une petite idée du personnage, ici.

Classé sous : , ,
La quadrature du cercle
02 September 09 07:11 AM | Nico | avec no comments
La quadrature du cercle est un problème classique de géométrie, qui consiste à construire un carré de même aire qu'un cercle donné à l'aide d'une règle et d'un compas. Il remonte à l'invention de la géométrie et a occupé de nombreux mathématiciens au cours des siècles. Grégoire de Saint-Vincent était passionné par le problème : estimant — à tort — l'avoir résolu, il exposa ses solutions dans un ouvrage de 1 000 pages. C'est en 1837 que Pierre-Laurent Wantzel démontre un théorème qui permet d'exhiber la forme des équations dont sont solutions les nombres constructibles à la règle et au compas. Puis en 1844, Joseph Liouville met en évidence l'existence des nombres transcendants. Mais il faudra attendre jusqu'en 1882 pour que le mathématicien allemand Ferdinand von Lindemann démontre la transcendance de π pour appliquer le théorème de Wantzel au problème de la quadrature du cercle et ainsi démontrer qu'elle est impossible à réaliser. L'Académie des sciences, qui avait déjà pressenti ce résultat un siècle auparavant, n'acceptait plus de « preuve » de cette quadrature depuis 1752.
La quadrature du cercle nécessite en effet la construction à la règle et au compas de la racine carrée de π, ce qui est impossible en raison de la transcendance de π : les nombres constructibles sont les rationnels et les racines de certains polynômes de degré 2n à coefficients entiers, ce sont des nombres algébriques ce qui n'est pas le cas de π. (source wikipedia).

L'ORM est un problème classique de l'industrie logicielle, qui consiste à faire cohabiter un modèle relationnel et un modèle objet. Il est issu de l'omniprésence des bases de données relationnelles, et de l'approche orientée objet, communément pratiquée dans le monde du développement. Pourtant ces 2 mondes reposent sur des approches différentes. Le modèle relationnel est fondé sur la théorie des ensembles, l'algèbre relationnelle, et la logique formelle. Il permet d'appliquer des processus de normalisation qui garantissent la non-redondance des données. Le modèle objet est fondé essentiellement sur les concepts d'Identité, d'Etat, de Comportement et d'Encapsulation.

Les principales zones de frottement sont notamment les suivantes:
  • inadéquation de la relation d'association: dans une base de données, une relation est bidirectionnelle et s'implémente par une Foreign Key, une colonne qui pointe vers une l'identifiant d'une autre Entité; dans un modèle objet, elle n'est pas nécessairement bi-directionnelle et s'implémente par un pointeur vers une autre structure fortement typée. 
  • inadéquation de l'héritage avec la logique relationnelle.
  • inadéquation entre l'identité de l'objet et l'identité en base.

L'objectif des 2 modèles est pourtant bien le même: représenter les informations du monde réel, l'un pour le stockage, l'autre pour les traitements et l'affichage. Mais leur différence d'approche fait que la friction entre les 2 modèles ne peut se faire sans heurts: de la même manière que la transcendance de π démontre l'impossibilité d'une solution pour le problème de la quadrature du cercle, "l'Impedence Mismatch" rend impossible la cohabitation. L'usage d'un ORM sera aussi compliqué qu'approximatif; il suffit de lire Ted Neward et de regarder les nombreuses tentatives vaines de Microsoft sur le sujet (Object Spaces, Active Recordsets, LINQ to SQL et Entity Framework) pour s'en convaincre. Et tous les spécialistes d'NHibernate vous le diront, "c'est une affaire de spécialistes !" et on ne peut pas mettre cet outil entre toutes les mains.

Alors que faire ? Il n'y a pas moultes solutions, il faut faire des sacrifices d'un côté ou de l'autre.

Solution 1: utiliser une base de données orientées objet, afin de rendre compatible l'approche utilisée par le développement et l'approche utilisée par le stockage. Mais l'histoire a montré que les bases de données orientées objet présentaient une complexité d'usage que n'ont pas les SGBDR, tandis que ceux-ci offraient au même moment une facilité de compréhension des concepts et des performances bien meilleures.

Solution 2: abandonner les concepts de l'approche objet qui sont en conflit avec l'approche relationnelle et garder dans son développement la logique relationnelle. On va bien sur utiliser des objets fortement typés dans leur déclaration pour faciliter la programmation, le langage et l'outil de développement sont bien adaptés pour le faire, mais on va préférer 
  • une approche Entiés/Relations où les Entités sont indépendantes les unes des autres, et la relation qui joue le rôle de lien entre les Entités. Le frottement n'en sera que moins douloureux. Une Entité en mémoire ne connait pas la structure des Entités avec lesquelles elle est reliée. C'est la relation qui lui permet d'accéder a ses entités reliées, et qui garantit le caractère bi-directionnel de l'association entre les entités. Cela permet également d'avoir une implémentation invariante de la cardinalité et de faciliter la gestion du cycle de vie des entités, avec un contrôle total sur le LazyLoading.
  • abandonner purement et simplement l'Héritage (et indépendamment du sujet ORM, vous ne vous en porterez que mieux pour maintenir votre système !) Une approche de la conception par composition sera bien plus efficace à long terme.
  • ne pas mettre de comportement dans les Entités, et préférer une approche Service StateLess; la notion d'identité de l'instance perd alors son importance.
  • avoir des identifiants uniques sur les Entités, de type Guid. C'est l'identifiant technique qui jouera le rôle de clé primaire dans la base. Et ne surtout pas prendre des Int autoincrémenté, qui mettent une dépendance forte entre le stockége physique et l'allocation d'un nouvel identifiant.

Bien entendu, cette deuxième approche n'est pas immédiate, et elle remet en cause beaucoup de choses que les architectes/développeurs ont l'habitude de pratiquer. C'est néanmoins les choix que nous avons faits pour notre couche d'accès aux données. En prenant cette approche, nous avons résolu et facilité un bon nombre de problèmes posés par l'incompatibilité des 2 mondes et nous disposons d'un ORM facile à utiliser et puissant.
 
Nous y reviendrons dans les prochains jours, quand la bête sera disponible...
Classé sous : , ,
Aspectize rejoint Paris Innovation
21 August 09 03:01 AM | Nico | 2 comment(s)
 
Devant faire face à la recherche de locaux, notre hébergeur actuel rejoignant lui-même sa maison-mère prochainement, nous avons postulé chez l'incubateur de la ville de Paris, Paris Innovation.

Après la diffusion du Business Plan et un entretien avec les responsables, nous avons passé l'oral final devant une commission qui comprenait un panel de personnes diverses (dans le désordre, OSEO, Paris Innovation, Scientipole Initiative, et Seeft Venture)

Et nous avons eu la bonne nouvelle que notre candidature était acceptée.

Au-delà des locaux, nous intégrons une véritable structure d'incubation qui va nous apporter une aide précieuse dans des domaines comme la protection juridique, le marketing, ou le financement. C'est également un réseau que nous intégrons, relais de confiance extrêmement important pour nous.

Contrairement à d'autres incubateurs, comme Agoranov par exemple, qui se concentrent plus sur la recherche et la conception d'un produit, Paris Innovation incube les sociétés dont les concepts sont déjà démontrés, et qui sont en phase d'aborder le marché. Exactement, le point où nous en sommes, puisque nous commençons à contractualiser nos premiers clients.

Notre déménagement est prévu le 31 aout prochain et nous nous réjouissons d'intégrer cette nouvelle structure. Accessoirement, nous ne serons pas dépaysés, en allant de la rue Gaillon à la rue d'Uzes.
Classé sous : ,
Valeur d'Usage de notre solution
22 July 09 05:08 AM | Nico | avec no comments
Les réflexions sur le Business Model conduisent naturellement à s'interroger sur la question de la valeur apportée par notre solution.

Pour bien comprendre cette notion, il est essentiel de considérer :
  • que cette valeur est toujours relative à une solution concurrente: notre solution de développement adresse un marché mature, où il existe pléthores de solutions concurrentes et où du développement spécifique est toujours possible. Il est donc important de bien savoir avec quelles solutions concurrentes la comparaison de valeurs est réalisée. 
  • que cette valeur doit s'estimer du point de vue du client: elle s'exprime par les bénéfices moins les sacrifices perçus par l'usage de la solution. Ces sacrifices ne sont jamais nuls, il est important de les intégrer dans la comparaison.
  • que cette valeur est une valeur d'usage, qui doit intégrer un usage sur le long terme. Nous adressons des Systèmes d'Informations qui sont prévus pour durer, la valeur d'usage doit être projetée sur un axe temps. La mise en situation est essentielle pour permettre cette projection qui n'est pas évidente. Le vieillissement d'un SI est toujours très difficile à anticiper. 2 questions peuvent aider pour faciliter la projection dans le futur:
    • Comment pourrais-je faire évoluer mon SI face à n'importe quel changement demandé par les utilisateurs ?
    • Que vais-je pouvoir réutiliser dans des applications futures et Quels sont les éléments sur lesquels je vais pouvoir capitaliser ?
  • que cette valeur se mesure essentiellement en comparant et en chiffrant:
    • le coût du développement, qui se mesure essentiellement avec du temps passé, mais pas seulement; d'autres éléments interviennent, car notre approche a aussi des impacts sur l'organisation et la réduction des spécifications notamment.
    • la qualité du développement réalisé car une ligne de code écrite est toujours source potentielle de bug, et ce point est important lorsque l'on compare avec du développement spécifique.
    • le coût de la maintenance, car le code écrit ou généré est toujours plus difficile à faire évoluer que quand il n'y a pas de code du tout. Ce coût est évidemment plus important pour du développement interne que par rapport à l'achat de produit, qui sera mutualisé par plusieurs clients.
Depuis le début de notre développement, notre ambition et objectif se résume assez simplement à écrire le code "bête" une fois pour toute et à laisser le code "intelligent" à écrire pour l'application. Par code "bête", on désigne le code "technique", qui est connu d'avance, quasiment toujours la même chose, qui évoluera peu avec le temps, et par code "intelligent", on désigne le code "métier", qui est flou et peu connu d'avance, et qui évoluera fortement avec le temps. Notre valeur d'usage s'évalue donc par la quantité de code éliminé par notre solution, ce qui n'est pas immédiat, parce que notre approche est nouvelle, et on a souvent l'impression, à tort, que le code est la solution alors qu'il est souvent le problème. 

Les solutions de références sont très diverses, il peut s'agir de développements spécifiques ou de produits, qui seront principalement des Frameworks ou des générateurs de code. Beaucoup de nos fonctionnalités n'ont pas d'équivalent dans des produits packagés et la solution de référence sera du développement spécifique. La plupart - on pourrait presque dire la totalité - des solutions de références ont pour paradigme une approche OO, ce qui est notre principal facteur différenciant et ce qui nous permet d'atteindre une séparation beaucoup plus nette entre code "technique" et code "métier". Nous pouvons aller beaucoup plus loin dans l'élimination du code technique, et évitons des taches fastidieuse et répétitives de développement. En ce sens, nous apportons de la valeur, puisque nous éliminons une charge de travail couteuse, et source de risques pour la qualité du projet.

Les différents compartiments de l'Application sur lesquels nous avons une proposition de valeur, sont logiquement découpés en fonction des différentes briques de notre solution. Nous aurons l'occasion d'y revenir en détail, les fonctionnalités à estimer peuvent être listées comme suivant. Bien entendu, chaque fonctionnalité doit être pondérée en fonction de la valeur qu'elle a pour le projet, et chiffrer pour chacune des solutions envisagées: 
  • Accès aux données (ou couche DAL)
    •     Designer de Schema Logique
    •     Import/Export vers le Schéma physique
    •     Données Multiples et Temporelles
    •     Expressions simples et complexes
    •     Champs non persistants
    •     Validateurs simples et complexes
    •     Lecture de données; détailler les différents types de requêtes (profondeur, lazy loading, filtre, tri), appels typés ou non typés.
    •     Ecriture des données (lock optimiste ou pessimiste, triggers)
    •     Gestion du TrackChanges
    •     API Manipulation des données (création, modification, suppression)
    •     Gestion de MétaDonnées (Qui, Quoi, Quand)
  • Serveur d'Applications
    •     Appels de services typés ou non typés
    •     Sérialisation
    •     Scalabilité
    •     Sécurité
    •     Gestion du Profile utilisateur
    •     Gestion d'Exceptions
    •     Bouchons
    •     Services transverses (Log, trace, cache, ...)
    •     LoadBalancing
    •     FailOver
  • DataBinding Relationnel & CommandBinding dans les IHM
    •     DataBinding bidirectionnel vers les données
    •     ControlBinding bidirectionnel entre les contrôles
    •     Contrôles supportés
    •     Gestion du Layout
    •     Validateurs
    •     Navigation Parent/Child
    •     CommandBinding (synchrone et asynchrone)
    •     UIService (création, suppression, association)
Nous pouvons ajouter également les sujets transverses suivants:
  • Organisation: notre approche permet un découpage plus facile du projet. En rendant les pièces indépendantes, il est plus facile de découper le projet en autant de sous-projets que nécessaire. On diminue ainsi l'entropie du Système; même si cela est très difficile à chiffrer, il est important de le prendre en considération.
  • Cycle de développement: notre approche permet d'atteindre une agilité réelle qui permet d'avoir des cycles de développement extrêmement courts, de l'ordre de quelques heures. Nous favorisons ainsi l'adoption d'une approche agile sans les contraintes imposées par les méthodes agiles actuellement en vogue. 
  • Architecture: notre solution est une architecture "out-of-the-box" qui propose une architecture prête à l'emploi dès le premier jour. Elle permet de s'affranchir de nombreux points à mettre en oeuvre pour mettre en place une Architecture multi-tiers. Peu de solution de références offre cette fonctionnalité, la mise en place d'une Architecture est souvent une tâche dédiée sur un projet, qui est rarement capitalisée d'un projet à l'autre avec des composants prêts à l'emploi, et plus souvent issue de l'expérience des participants du projet.
  • Evolutivité: la réduction de code technique et la non-adhérence à des choix techniques permet d'envisager une évolution future vers d'autres environnement. Ainsi, une application WinForm pourra être portée facilement en WPF, une application Web pourra être portée plus facilement en SilverLight; par "facilement" nous signifions que la logique de l'Application n'est pas remise en cause, car la logique a été complètement isolée de la technique et donc de la technologie utilisée dans l'IHM. Ce point n'est pas souvent pris en considération car peu de personnes envisagent que cette évolution est possible.
  • Intégration: la cohabitation d'une Application avec le reste du SI peut être un point clé du choix des solutions, et il est nécessaire de vérifier que l'intégration avec des applications tierces est possible dans les deux sens. En ce qui nous concerne, nos applications sont nativement .Net, elles peuvent intégrer du code spécifique à tout endroit de l'application (la récupération des contrôles, données et traitements se fait facilement), et l'appel de n'importe quel traitement client ou serveur, est toujours possible.
Parmi les sacrifices identifiés, on distingue principalement les coûts de transferts vers une nouvelle approche et une nouvelle solution, qui peuvent se détailler ainsi:
  • L'apprentissage, qui sera capitalisé sur le long terme
  • L'abandon de ce que l'on possède déjà, qui est souvent survalorisé par ce que ce qui est possédé est la résultante d'une décision passée, et qui se traduit par une impression de perte de contrôle. Cette impression doit être temporaire et vite comblée par l'apprentissage rapide de la solution.
  • Les changements dans l'organisation et la méthode de développement; même s'ils sont bénéfiques à terme, un changement est souvent perçu comme un sacrifice, on préfère continuer à maîtriser ses échecs que de prendre le risque de réussir.
  • Le risque perçu par le choix d'une Start-up: "Personne ne s'est fait virer en choisissant IBM ou Oracle !", à nous d'identifier les Early Adopter qui sont prêts à travailler avec une Start-up.
Plusieurs études montrent que l'on se focalise plus volontiers sur les sacrifices que sur les gains. Ceci est légitime, car le risque de ce que l'on ne connait pas est naturellement une source d'inquiétude toujours plus forte. Il y a une asymétrie de l'information, entre ce que l'on connait et ce que l'on ne connait pas, et donc un déficit presque naturel des sacrifices perçus. Combler cette asymétrie d'information et se mettre dans une position de connaissance équivalente des différentes solutions demandent un effort, lui-même assimilé à un sacrifice. C'est à nous de combler ce déficit et d'accompagner nos prospects pour leur permettre d'évaluer la valeur apportée par notre solution avec le maximum d'informations. Ne perdons pas de vue non plus tous les problèmes actuels de dépassement que connaissent la grande majorité des projets de développement. Les "Pain Point" que nous adressons sont bien des surcoûts que nous éliminons.  

Finalement, la décision d'acquérir une solution innovante de développement se mesure par une mise en situation et la réalisation d'un projet pilote, qui permettront la mesure des différents gains et sacrifices des différentes solutions pour calculer la Valeur d'Usage de notre solution, et montrer qu'elle est supérieure aux solutions concurrentes.
Classé sous : , , ,
Pas de DataSet dans SilverLight 3
01 June 09 06:07 AM | Nico | 1 comment(s)

Cela faisait déjà un petit moment que l'on se posait la question. Le DataSet allait il être porté en SilverLight ou non ? Microsoft avait plusieurs fois tourné autour du pot et quelques voix timides et éparses (dont la nôtre) avaient manifesté son intérêt pour le portage, lors de la wish list de SilverLight v2.

En vain, l'équipe d'ADO.NET vient d'annoncer il y a quelques jours que le DataSet ne serait pas porté en SilverLight. Pour rassurer les adeptes du DataSet, forcément déçus, ils proposent 3 alternatives pour construire ce qu'ils appellent des "data-centric applications" (un jour, il faudra qu'on m'explique quelles applications ne sont pas data-centric ?):

  • ADO.Net Services

ADO.Net Services n'a malheureusement que très peu de rapport avec ce qu'on peut faire avec un DataSet. Disposer des opérations CRUD d'une Table avec une URL, est certainement un progrès et on peut s'en réjouir, mais ca ne suffit pas, car on a perdu beaucoup d'informations en route. Le besoin de travailler avec plusieurs tables et des relations n'est pas couvert. Or qui d'autre que le DataSet manie à la perfection ces considérations ?

  • RIA Services

RIA Services, n'est pas encore officiellement annoncé, et on ne sait pas si SilverLight 3 comportera cette brique. Mais de quoi s'agit-il exactement ? Je retranscris ici la définition fournie par MS:

Microsoft .NET RIA Services simplifies the traditional n-tier application pattern by bringing together the ASP.NET and Silverlight platforms. The RIA Services provides a pattern to write application logic that runs on the mid-tier and controls access to data for queries, changes and custom operations. It also provides end-to-end support for common tasks such as data validation, authentication and roles by integrating with Silverlight components on the client and ASP.NET on the mid-tier 

Ce qui signifie plus ou moins, en tout cas, ce que j'en comprends : on va pouvoir appeler du code serveur facilement, comme s'il s'agissait d'une application ASP.NET, et partager code client et serveur de façon plus ou moins transparente. Si on peut comprendre l'intérêt pour une validation de données, je ne vois absolument aucun rapport avec le DataSet.

  • Web Services

Web Services. Donc on en revient, à développer à la main, toutes les opérations de changement. Je ne suis pas certain qu'on ait beaucoup gagné au change.

Bref, c'est encore l'Orienté Objet qui domine, et qui va inviter le développeur à écrire plus de code rigide et compliqué pour faire des choses simples. Dommage que Microsoft n'ait pas imaginé que le DataSet restait un choix de développement. Le portage dans SilverLight ne devait pas être si compliqué pour eux et c'est vraiment une occasion ratée, surtout en proposant des alternatives qui n'ont pas grand chose à voir.

De notre côté, plus nous avançons et plus l'évidence nous saute aux yeux. Le DataSet est une pièce incontournable d'une bonne architecture 3 tiers, qui offre tout un tas de services indispensables dont nous avons déjà parlé à de nombreuses reprises (serialisation, track changes, typage faible, filtre, tri, binding, relations, copie de données, ...). Ne pas en bénéficier et c'est autant de choses qu'il faudra refaire à la main. Le DataSet offre plus d'avantages qu'il n'a d'inconvénients.

Cela nous demandera donc un peu plus de travail pour atteindre SilverLight (si MS avait porté le DataSet, cela nous aurait fait gagner du temps), mais, comme on l'a déjà fait plus ou moins en javascipt, on devrait être capable de le refaire en C# pour SilverLight, sans trop de difficultés. Et de montrer que le DataSet est un puissant outil, à la fois pour l'accès aux données et pour le DataBinding côté client, et qu'il peut être utilisé sans trop de difficultés.

Classé sous : ,
Projet pilote, les premiers tests
28 May 09 03:15 AM | Nico | avec no comments

Nous démarrons depuis le début de la semaine, un projet pilote Web. Cette démarche est nécessaire pour nous à plusieurs titres:

  • une logique de test grandeur nature, pour mettre notre serveur applicatif à l'épreuve; passer partout dans notre code, et multiplier les Use Case est évidemment fondamental pour notre produit. Nous avons à ce sujet 2 règles d'or:
    • en phase de développement, toujours passer en mode pas à pas dans toutes les lignes de code écrit.
    • corriger un bug tout de suite, dès qu'il est détecté. Cela peut conduire à se disperser, surtout au début, quand un scénario révèle plusieurs bugs qui n'ont rien à voir du tout d'un seul coup, mais c'est vital pour être efficace.
  • une validation de l'approche, en montrant qu'on atteint une application d'un niveau professionnelle, sans aucune restriction de customisation. L'essentiel de l'effort est porté sur la conception métier, on a une logique permanente d'état fini, et le résultat est visible tout de suite sans aucun effort.
  • la mise en avant de best-practise qui accompagne notre produit; il y a toujours mille et une façons de développer une application. Notre logique de Binding ouvre des possibilités infinies, et il est essentiel d'être clair sur les "How to" fondamentaux. Cela permet de bien délimiter aussi la frontière entre l'inside et l'outside de la solution; qu'est ce que doit connaitre le développeur pour être efficace avec notre produit ?
  • la priorisation des futures features à développer; notre Road Map est bien fournie, il est important de bien ordonner les développements à venir, pour accroitre la valeur du produit. Faire la distinction entre les nice-to-have, et le must-have.
  • la réalisation d'une application interne qui va directement nous servir, puisqu'il s'agit d'un outil de CRM, dont nous avons besoin.

A ce jour, les premiers résultats sont plus qu'encourageant et enthousiasmant:

  • la rapidité de mise en oeuvre est bluffante ! Bien sur, nous connaissons parfaitement notre produit, donc nous allons d'autant plus vite pour configurer le Binding, mais le coup de main s'apprend facilement, et cet effort est vite récompensé par des effets visibles. L'enchainement des écrans, la dynamique du binding, permettent une mise en oeuvre d'un Use Case en quelques minutes. Le confort d'une application full Ajax sans effort est vraiment très satisfaisant.
  • l'essentiel de l'effort est bien porté sur la conception métier; comment organiser les données ? au niveau des schémas Entité/Relations, et aussi au niveau des différents DataSet dans le client. Comment organiser les Vues, avec quel niveau de détail pour le layout ? Comment nommer correctement les choses ? Ce qui est certain, et qui reste un de nos principaux objectifs, c'est qu'aucun choix n'est structurant. Il est facile de modéliser un premier jet, de le tester, puis de le modifier, pour arriver à l'application qui correspond à ce que l'on veut. Ces allers et retours sont constants, le cycle devient vite naturel. On commence à travailler avec un stockage XML, qui évite la rigidité du modèle physique de la base de données. C'est très souple, on ajoute, on enlève, on modifie, et ca marche ! Nous passerons à une base physique dès qu'une partie du modèle sera stable, et la migration sera totalement transparente et gratuite. Le code logique d'accès aux données est en effet complètement indépendant de son stockage physique, et ce sera également le cas pour le Cloud Computing.
  • le peu de code à écrire s'écrit très facilement; pour l'instant, seul le chargement des données et quelques validateurs ont nécessité d'écrire quelques lignes de code. Ce code est simple, séquentiel, purement métier, et totalement indépendant du reste du monde. Une vingtaine de lignes ont été écrites et j'ai déjà un scénario qui fonctionne avec de la sécurité, et 5 formulaires qui me permettent d'éditer mes données.

Le seul bémol, et sur le quel nous ne pouvons pas grand chose, est l'habillage graphique, qui nécessitera un vrai travail ultérieur au niveau de la CSS.

Classé sous : , , ,
Startup Academy
18 May 09 04:13 AM | Nico | avec no comments

Aspectize est inscrit à la Startup Academy.

Cela fait partie des opportunités saisies pour "sortir du bois".

Le descriptif de notre candidature est ici, la liste de tous les participants est là.

Classé sous : ,
Première démo web en images
13 May 09 03:42 AM | Nico | avec no comments
Cela fait maintenant plus de 2 ans que nous développons notre produit, et 1 an que nous travaillons sur la partie Web.

Si la version Windows avait suscitée de la curiosité, il était rare de recueillir un réel enthousiasme de la part des développeurs à qui nous montrons nos démos. Cela impressionnait, il y avait beaucoup de questions pour savoir comment on avait fait, mais pas d'extase pour autant. 
 
Depuis quelques semaines, et avec une démo Web, on sent que l'enthousiasme est nettement plus significatif. Plusieurs personnes ont lachées des "Oh !" et des "Whaou !", et cela fait très plaisir. On sent que la valeur de notre solution a bien plus de portée avec les applications Web. Peut être parce que le Web est plus au centre de leur préoccupation, peut être aussi parce que c'est plus difficile, peut être aussi parce que la rupture est bien plus grande.

Il faut bien comprendre que si notre innovation était déjà conséquente pour les applications Windows, elle constitue une petite révolution pour le développeur Web et en particulier pour le développeur ASP.Net:
  • Contrôle total sur le HTML, puisqu'aucun HTML n'est généré côté serveur. Cela est extrêmement facile, il n'y aura plus de mauvaise surprise par des balises générées, et tout est habillable facilement en CSS.
  • Assemblage logique et dynamique de contrôles HTML; il n'y a plus de notion de pages, tout le layout est complètement dynamique et se configure en quelques clics de souris.
  • Contrôle total sur les allers/retours entre client et serveur; les seuls échanges sont des échanges de données, pilotés par le Command Binding déclaratif.
  • Comportement Ajax natif sans la moindre écriture de code; la synchronisation des données est bluffante, et il n'est pas nécessaire de connaître javascript.
J'en ai profité pour tester Camtasia et j'ai réalisé une petite vidéo de démo:



Ainsi, en quelques minutes et avec quelques clics de souris, on dispose d'une application Web, qui aurait pris plusieurs heures à développer avec ASP.NET.
 
Nous verrons dans les jours prochains, étape par étape, comment mettre tout cela en oeuvre et aller beaucoup plus loin.
Classé sous : , , ,
Les Applications Web en quelques clics
30 April 09 12:08 PM | Nico | avec no comments
Nous sommes sur le point d'aboutir à la version Web de notre serveur d'Applications.

Et c'est une grande première, car là où notre approche était déjà innovante pour les applications WinForms, elle est totalement révolutionnaire pour les applications Web. Nous nous démarquons en effet, assez fortement du modèle ASP.NET;
- Tout le HTML est géré côté client. Il n'y aucune génération de HTML sur le serveur.
- Tous les échanges entre le Serveur et le Navigateur sont des échanges de Données. Les données sont transférées au format JSON.
- Le Navigateur appele des Commandes locales (écrites en JavaScript) ou des Commandes Serveur, en fonction du Binding.

Nous sommes complètement intégré à IIS (version 6 ou 7), et un HTTPHandler permet le routage des requêtes vers notre serveur d'applications, qui est nativement intégré à IIS, à l'aide d'une configuration simple dans IIS (il suffit de créer une Application qui pointe vers le répertoire Host Aspectize). La sécurité (authentification et gestion des rôles) est nativement prise en charge et totalement configurable.

Pour le DataBinding et le CommandBinding, nous restons fidèle à nos principes que nous avons mis en oeuvre pour les Applications WinForms, puisqu'il n'y a aucun code client à écrire pour les IHM, et tout le Binding est fait par notre moteur JavaScript dans le navigateur.

Le Schéma contient la logique de l'Application. Il est inchangé par rapport aux Applications WinForms. Les Commandes de validation peuvent être écrites en JavaScript pour s'éxécuter dans le Navigateur, sans avoir besoin de faire des allers et retours avec le serveur.

Dans le projet Web, nous créons des contrôles HTML. Ce sont juste des DIV qui contiennent le HTML standard des formulaires de l'Application. Le Layout, le DataBinding et le CommandBinding sont fait par configuration.
 
C'est une innovation totalement unique, il n'y a aucun équivalent sur le marché.

J'aurais l'occasion dans les jours prochains d'expliquer et de montrer comment on construit simplement des Applications Full Ajax en quelques minutes !
Classé sous : , ,
Schema et accès aux données
25 March 09 04:32 AM | Nico | avec no comments

Cet article a pour objectif de décrire notre approche à propos de l'accès aux données.

En préambule, un petit aparté sur Entity framework, qui s'inscrit dans la continuité de l'histoire douloureuse des ORM de Microsoft.

Microsoft a sorti en 2008 la V1 d'Entity Framework. Elle a suscité de nombreuses réactions, plutôt négative de la communauté. Trop intrusif, trop de code à écrire, trop compliqué à utiliser, trop d'inconvénients pour peu de bénéfices. Microsoft a écouté, et a décidé de construire la V2, en transparence, et en communiquant au fur et à mesure de son évolution. Ca se passe ici, sur le blog de l'équipe d'EF, et la Wish list (77 pages de Forums !) s'est arrêtée au 15 janvier.

Malgré cela, l'approbation de la communauté n'est pas encore gagné.

Un article évoque la gestion du ChangeTracking, fonctionnalité inhérente à tout ORM qui se respecte. Ils ont plus ou moins décidé qu'ils allaient fournir des API pour que les développeurs implémentent eux-mêmes leur gestion du ChangeTracking: que de choses à connaître, et que de code à écrire.

Autre exemple, la gestion des Foreign Keys. Apparemment, certains voudraient voir les FK dans leurs entités, et d'autres non, car ils considèrent que l'entité est polluée par une FK. D'où une gestion de FK hybride, les Independant Associations apportées par .Net 4.0; encore quelque chose de compliqué et d'artificiel qui nécessitera apprentissage.

Alors que l'usage du DataSet simplifierait les problèmes, ils évitent soigneusement de l'utiliser, avec des arguments discutables.

Sami Jabber a parfaitement raison quand il écrit à propos d'Entity FrameWork: "Un modèle conceptuel de données qui permet d'abstraire du XML, du relationnel, de l'objet et des DataServices (pour Astoria) a un nom, cela s'appelle de la magie noire".

Notre vision est nettement plus simple, pragmatique, compréhensible tant pour sa lecture, que pour son utilisation, souple, dynamique, peu intrusif, et requiert l'écriture d'un minimum de code.

Des données relationnelles sont persistées quelque part (un fichier, une base de données ? peu importe !), et il serait pratique d'y avoir accès "facilement". Inversement, des données relationnelles sont en mémoire, et on souhaite les persister quelque part (un fichier, une base de données ? peu importe !), sans trop d'efforts. J'insiste sur le caractère relationnel des données, car c'est le coeur du problème, ou plutot le coeur de la solution.

Plus précisément, on souhaite écrire le moins de code possible (évitons le SQL) et ne pas être intrusif vis-à-vis des Entités que l'on manipule.

Et s'il n'y a pas de solution magique, je maintiens qu'il y a plus à gagner à utiliser le DataSet qu'à ne pas le faire. Et pas seulement pour le ChangeTracking, mais pour beaucoup d'autres; serialisation, dynamisme, filtre, tri, Merge, gestion événementielle.

Et s'il y a quelques défauts, essayons de les gommer, plutôt que de jeter le bébé avec l'eau du bain.

  • Intellisense: toujours difficile à concilier avec le dynamisme, nous apportons une solution. C'est du typage fort pour le code, côté serveur, et du typage dynamique pour le transport et le Binding, le mariage idéal des 2 mondes.
  • Validation: les ExtendedProperties permettent de stocker des attributs complémentaires et manquants. Des validateurs standards (Min, Max, Regex), mais aussi Custom avec des Commandes de Validation. 
  • Navigation: quelques fonctions génériques de navigation, en fonction du typage fort, mais aussi du typage souple, permettent de naviguer de façon extrêmement conviviale et évite la manipulation verbeuse du DataSet qui fait souvent peur au développeur.

Aspectize Entity Designer est l'Outil de Design du modèle conceptuel des données, c'est à dire les Entités et les Relations. De ForeignKey, il n'est point question; nous insistons sur ce point, la Relation existe à part entière, c'est fondamental pour l'approche. Sa cardinalité est définie, mais elle n'a pas d'implication sur le modèle. Cela permet de garantir l'indépendance des Entités. Peu importe si ma Category est liée à un Product ou à autre Chose, cela n'influe pas la nature de mon Entité Category.

Nous pouvons ajouter de nombreux attributs :
- MustPersist: permet de dire si certaines Entités ou Champs ne sont pas sauvegardés. Pratique, quand certaines entités ne servent qu'au calcul ou a l'IHM. A noter que les Relations peuvent également être non persistence.
- Validators: permet de définir un Validateur, écrit en .Net, qui sera toujours appelé lors d'un CommandBinding configuré sur cette commande.
- Triggers: permettent de définir des commandes qui seront automatiquement appelées lorsque l'on impactera une Entité, en fonction du State (Add, Delete, Update).

Un des attributs les plus intéressant est sans doute le Temporel, qui permet de définir automatiquement la dépendance au temps d'une donnée: dans mon exemple, le prix du produit est historisé, et est donc stocké dans une autre table. L'intérêt de l'attribut Temporel est que cela est complètement transparent d'un point de vue logique: j'ajoute même un autre champ qui me permet d'avoir le prix courant, sans être obligé d'interroger systématiquement l'historique des prix.

EntityManager est notre composant d'accès aux données. Il permet, via une API extrêmement simple de faire tout ce qu'on veut pour récupérer des données et les sauvegarder.

IDataManager dm = EntityManager.FromDataBaseService("MyDataService");

Pour récupérer une Category à partir de son Id: 

Category category = dm.GetEntity<Category>(id);

ou tous les Product associés à une Category, selon la relation CategoryProduct (on pourrait imaginer avoir plusieurs relations entre les mêmes entités):

dm.GetAssociated<Product, CategoryProduct>(id);

Accessoirement, c'est la même API pour naviguer dans les données en mémoire, à partir du DataSet (ce qui évite la manipulation verbeuse):

List<Product> products = category.GetAssociatedInstances<CategoryProduct>();

Et pour la sauvegarde, c'est encore plus simple. La seule méthode Save, sauvegarde toutes les lignes du DataSet en fonction des changements:

dm.Save();

L'énorme avantage est de tirer parti à la fois du typage fort proposé par Entity Designer, et du typage dynamique géré par le DataSet.

Ainsi, le chargement d'une Category peut s'écrire également:

dm.LoadData("ADWData.Category[Id = id]");

ou avec les Product associés:

dm.LoadData("ADWData.Category[Id = id].CategoryProduct.Product");

mais aussi ajouter un nouveau Product à une Category:

uiService.AddRow("ADWData.Category.CategoryProduct.Product");

Il est du coup, extrêmement facile d'écrire des services d'accès aux données; nous verrons plus tard que nous n'avons même pas à écrire ces services d'accès aux données, car ils peuvent se déduire du DataBinding. L'Application charge toute seule les données qu'elle affiche, en fonction des DataBinding configurés sur les contrôles.

Difficile de faire plus simple; aucune intrusivité, tous les scénarios d'accès aux données Lazy ou non sont couverts, de façon extrêmement limpide et le DataBinding se charge du reste !

Classé sous : , ,
Nouvelle vidéo
04 March 09 03:25 PM | admin | avec no comments

A l'occasion des Techdays, Microsoft et Brainsonic m'ont proposé de réaliser une présentation en images. Après la vidéo de démonstration l'année dernière, je me suis plutôt concentré sur l'approche, avec quelques slides de support pour illustrer le propos.

 


 

Classé sous : , , , ,
Approche
01 March 09 07:22 AM | Nico | avec no comments

Suite à notre soirée Alt.Net, qui a suscité quelques échos dans la blogosphère (ici, ici et là), et qui était un exercice très intéressant pour nous, voici quelques explications écrites qui complètent nos slides, et résument notre approche.

 

Il est difficile de prévoir. Cela peut être plus facile quand on construit un pont ou une route, car ce sont des éléments mécaniques qui sont régis par des contraintes qui sont connues d'avance. Mais cela est beaucoup plus difficile quand on construit un Système d'Informations, parce qu'il répond à un besoin issu de l'imagination des utilisateurs, qui ne cesse d'évoluer avec le temps et en fonction des usages de l'existant.

L'agilité permet de réduire la portée des prévisions, qui sont d'autant plus floues qu'elles sont lointaines. Avec une meilleure tolérance aux changements, il est plus facile de travailler en cycles courts afin d'augmenter la qualité de l'application, qui est, par définition, proportionnel au recoupement entre ce qui est attendu et ce qui est réalisé. On rentre alors dans un cercle vertueux, qui consiste à limiter les évolutions en cycles extrêmement courts, ce qui va augmenter les chances de coïncider avec les besoins attendus, et éviter les dérives.

 

 

Pour cela, on a besoin de faire une séparation beaucoup plus nette entre le technique et le métier. Aujourd'***, il y a trop de complexité dans le SI, il y a trop de code, parce que cette séparation est mal faite. Beaucoup trop de code technique est ré-écrit dans chaque projet, alors qu'une séparation plus nette permettrait de n'écrire certaines briques techniques qu'une seule fois. C'est le rôle de l'Architecture de proposer ces briques techniques réutilisables. Et réutilisable, de préférence sans écrire de code. En tant qu'adepte de l'approche DRY, isoler ce qui peut être défini tôt (le technique) de ce qui doit être défini tard (le métier) est un exercice primordial.

En partant du besoin métier couvert par le SI, et en essayant de rester le plus générique possible, essayons d'isoler quelques invariants techniques du SI, sans savoir si on va traiter de voiture, de contrat d'assurance ou des ventes de livres. C'est un peu comme si vous faisiez l'inventaire de votre cuisine, sans vous poser la question de savoir si vous allez faire le mois prochain de la soupe au pistou, des poissons en papillote ou une mousse au chocolat; vous avez besoin dans tous les cas d'ustensiles réutilisables, comme un four, des plats, des casseroles, et un bon presse-ail. Et vous n'allez pas les fabriquer à chaque fois que vous faites une nouvelle recette !

Pour revenir à nos octets, les besoins métiers peuvent se résumer simplement à:
  • Des Données Relationnelles
  • Des IHM, pour afficher et modifier par les input clavier et souris (et rien d'autre !) 
  • Des Traitements, essentiellement manipulation de ces données: calculs et validations. Et ils sont rares (en proportion du code écrit actuellement). On peut également ajouter les processus, qui sont des traitements, avec des états et des transitions.
Les Données Relationnelles correspondent à un schéma de pensée assez simple: des "choses" sont en relation avec d'autres "choses". Ces choses ne sont pas connues d'avance, elles sont spécifiques au métier, mais on sait qu'elles sont nommées et qu'elles ont des propriétés nommées et typées. Il y a également des méta-données techniques, mais au contraire des méta-données métiers (qui touchent à la nature des "choses"), les méta-données techniques sont connues d'avance: tout ce qui peut être technique peut être orthogonal et écrit une bonne fois pour toute (persistance, conversion, cardinalité, temporalité, multiplicité, validation), et complètement indépendamment de la nature de la donnée. On sait juste que l'on aura à faire avec des chaines de caractères, des dates, des identifiants (Guid), des boolean et des numériques.
 
Les IHM sont des contrôles configurés pour afficher les données nommées, et lancer des commandes en réponse à des événements des contrôles. Le contrôle, en tant que "contrôle", n'a pas à connaître le service qu'il appelle, c'est indépendant de sa nature; il pourra être WinForm, Html, WPF ou Silverlight (du moins en restant dans le monde Microsoft, qui offre déjà une palette assez large de possibilités) la définition de la commande associée - elle aussi justement nommée - ne relève pas de son design. De même, la donnée qu'il représente lui est inconnue, il ne connaît pas son format d'affichage ni sa validation.

Les Traitements sont des Services Stateless qui manipulent les données relationnelles. Le StateLess est un pré-requis indispensable à la montée en charge, et permet d'éviter beaucoup de problèmes de concurrence et de synchronisation. Si un Service a besoin de gérer un état, il le sauve dans une base de données (qui elle, sait très bien gérer la concurrence) et si une commande a besoin d'une donnée, elle la demande. A partir du moment où la donnée est nommée, il est facile de l'obtenir; ne pas se soucier de là où elle se trouve, ce n'est pas le rôle du service. Celui-ci sera configuré plus tard, pour s'exécuter au plus près des données dont il a besoin, pour assurer la performance attendue. C'est là tout le rôle et la valeur ajoutée de l'architecte. Définir les services et leur configuration en fonction du métier, est de loin la chose la plus difficile qui existe dans ce métier, ne la compliquons pas avec des considérations techniques.

Pour mettre en oeuvre tout cela, et faire cohabiter ce joli monde, on a besoin d'un certain nombre de ruses et astuces:
  • Proxy Dynamic pour pouvoir faire un appel dynamique de n'importe quelle commande, parce qu'elles ne sont pas connues d'avance. C'est donner de l'indirection, qui permet une séparation complète avec le physique. On ne sait pas où elle est la commande, peu importe. Une fonction ExecuteCommand pourra appeler n'importe quelle commande en fonction de son nom.
  • DataBinding pour permettre le transfert bi-directionnel des données entre la mémoire et l'IHM. Ce databinding est dynamique, car, là encore, les données ne sont pas connues toujours d'avance (elles le sont au moment où le développeur drag'n'drop sont TextBox dans son contrôle, mais cette situation peut arriver à tout moment, et bien au delà la mise en marche de l'application). Il doit également tenir compte du caractère relationnel des données, la navigation Parent-Child dans les données, est une fonctionnalité de base, mais il y en a bien d'autres comme le format ou la validation.
  • AOP: la technique des attributs est utilisée pour permettre une orthogonalité dans la nature des choses, ce qui permet de gérer des méta-données techniques. A la différence de l'AOP (les puristes vous diront qu'on ne fait pas de l'AOP, et ils auront raison tant qu'ils ne changeront pas d'avis :-), celui que nous utilisons est dynamique. 
  • Chargement dynamique, pour permettre l'ajout ou la modification de n'importe quel élément (contrôles, données ou traitements) à tout moment de la chaîne de développement. Ne pas confier la gestion du chargement à .Net, qui imposera des liens impératifs, ce que nous voulons justement éviter.
  • DataSet: la gestion des données relationnelles en mémoire, dynamique (on ne les connait pas d'avance), mais néanmoins typées, sérialisable, avec des fonctionnalités de Change Tracking, Filtre, tri, rien que ça. A l'aide d'une fonction GetData qui saura récupérer des données par leur nom relationnel, nous sommes capable d'adresser tout ce que l'on veut, sans les connaître d'avance.

Évidemment, la plate-forme .Net offre tout un tas de choses que nous avons considérablement enrichi et simplifié, pour qu'elles soient facilement utilisables, et nous ne pouvons pas résumer ici tous nos secrets de fabrication (le Hollywood Principle en fait partie). Et nous avons packagé toutes ces techniques pour qu'elles soient disponible pour ceux qui vont faire le reste.

Et le reste, c'est du métier. Et c'est là où le développeur commence son travail. A lui de définir l'organisation des données, les entités et leurs propriétés, les relations et les écrans. Il ne fait pas cela dans un but physique, mais purement logique. Les attributs techniques viendront plus tard. 

Il ne va pas commencer par écrire une couche d'accès aux données, ni faire un modèle objet, et encore moins s'occuper de la sécurité; il va s'intéresser au fonctionnel, c'est à dire à la nature des choses et leurs relations, au design des écrans et aux règles métiers, qui sont d'autant plus facile à écrire qu'elles sont peu nombreuses, répétons le. Et dès le premier jour, il aura un résultat visible et qui fonctionne.
 
Avec l'intelligence et la connaissance des outils, Visual Studio & Binding Studio (qui devraient n'être qu'un, mais Binding Studio n'aurait jamais vu le jour s'ils l'avaient été - wait and see ? - car Binding Studio a la particularité d'être fait avec Binding Studio, mais je m'égarre, ceci est une autre histoire):
  • Microsoft Visual Studio pour:
    • faire le design des entités et des relations, à l'aide de notre DSL
    • faire le design des écrans en WinForms ou en HTML (pour l'instant, WPF et Silverlight viendront plus tard).
    • écrire le code métier que sont les calculs et les validations
  • Aspectize Binding Studio pour:
    • configurer le DataBinding et le CommandBinding entre les IHM, les Données et les Traitements
    • configurer les services et tout ce qui a attrait au technique (log, trace, bouchons, ConnectionString, FileName, Error tracking, ...); à noter que cette partie est complètement dynamique, au sens où elle peut être modifiée à chaud par un administrateur.

Voilà, en quelques lignes, l'esprit de notre démarche.

Nous allons essayer d'être démonstratif dans les prochaines semaines, en illustrant comment on utilise concrètement nos outils pour la mise en oeuvre.
Classé sous : ,
Plus de Messages Page suivante »