Yearly Archives: 2005

DNG 2005: Q&A avec Bill Gates

Intervenant  : La rédaction des auteurs DNG & Bill Gates

J’ai donc vu l’homme le plus riche du monde… bon et après. Ça devait être le clou du spectacle ce fut la session la moins intéressante. Mais après tout il fallait s’y attendre, un homme comme Bill Gates n’est pas libre de ces paroles: la moindre déclaration un peu en dehors du discours habituel peut prendre des proportions énormes. Donc ce fut une session sans surprise, à chaque question il déroulait à partir d’un ou deux mot clé un discours marketing bien rodé.
A la question de Didier: “je suis un développeur java qu’est ce que vous pouvez me dire pour me convaincre de me mettre à dot net” il n’a pas du tout répondu mais a enchaîné sur l’interropérabilité dot net java.
A si un truc quand même qui nous a bien fait rire (ou fait peur) dans le prochain windows le système de fichier sera entièrement transactionnel et le moteur transactionnel sera sql serveur!!

Bon malgré tout s’était quand même quelque chose que Bilou soit présent au symposium. Ça va être dur de faire mieux l’an prochain. Je ne vois qu’une seule solution: Inviter Linus !!

DNG 2005: Mise en oeuvre de DSL – Domain Specific Language

Intervenant: Jean-Marc Prieur

Tout d’abord un grand bravo à Jean-Marc Prieur à qui revient sans conteste la palme de la meilleure présentation et ce n’est pas rien car le niveau était très relevé et le sujet loin d’être évident.
Après cette présentation je pense qu’il faut mettre les DSL en perspective avec la démarche MDA.
En schématisant beaucoup
MDA: modélisation UML => plateform independant model => plateform specific model => code generation
DSL: modélisation avec des outils très proche de l’UML => diagramme de classe => diagramme objet => code generation

Je vois les DSL comme proche de la démarche MDA mais en plus pragmatique plus efficace.

Un point sur lequel Jean Marc a bien insister les DSL prennent tout leur sens si vous vous appuyer sur un framework: le framework fourni les services techniques et les DSL s’occupent des 5% de code métier de Sami.

Le travail des développeurs c’est comme le gaz

Entendu à un coin de table à midi:

“Le travail des développeurs c’est comme le gaz: ça prend toute la place qu’on lui donne”

Je trouve l’image très bonne. En fonction de la pression les propriétés d’un gaz change. C’est la même chose pour un développeur: peu ou pas de pression il n’avancera pas très vite, un peu de pression il est productif, trop de pression il fait du mauvais boulot avant de finir par exploser !
Tous les gaz ne réagissent pas de la même manière à la pression, certain gaz rares ont des propriétés particulières il en est de même des développeurs.

Cette image illustre bien l’un des rôles du chef de projet: un régulateur de pression. Il doit trouver le bon niveau de pression à appliquer à chacun de ses gaz, enfin développeurs.

Livre blanc: SOA et urbanisme

Trouvé dans les commentaires du blog Architecture Logicielle. Un excelent livre blanc:

“SOA et urbanisme – Le rôle des Architectures Orientées Services dans l’alignement métier des Systèmes d’Information”

Une idée forte qui revient tout au long de ce livre blanc est la nécessité d’un référentiel centralisé des données et services de l’entreprise. La création et la maintenance de ce référentiel ne peuvent se faire sans des outils adaptés. Etant actuellement impliqué dans un projet SOA avec un embrion de référentiel d’entreprise et sans outil je peut vous dire que c’est bigrement vrai.
Et on en remet une couche avec la Synthèse des Meilleures Pratiques SOA et Web Service par Orchestra network. Encore une bonne lecture avant de se lancer dans un projet “SOA”

UML n’est pas une méthodologie

Je profite de ce billet de Bruce Eckel: UML vs OO design pour rappeler qu’UML n’est pas une méthodologie. Ce n’est sans doute pas inutile de le rappeler car énormément de cv associe Uml et méthodologie. Uml est tout juste un outil, un simple language, une collection de diagrammes qui facilitent la communication entre les différents acteurs d’un projet informatique. Bref UML est un outil très utile mais loin d’être suffisant pour garantir de bien modéliser un problème donné.

La preuve qu’Uml n’est pas une méthodologie on peut l’utiliser de différentes manières comme l’indique Martin Fowler:
Uml en tant que croquis:
On modélise rapidement une partie d’un problème pour en discuter avec d’autres personnes et avancer dans la compréhension du système. Dans ce mode l’outil essentiel reste la feuille de papier et le crayon de papier avec une bonne gomme. Si vous été fortuné un paperBoard et un marqueur seront les bienvenus 😉
Uml en tant que plan:
Le concepteur va modéliser le système à l’aide de diagrammes uml (principalement des diagrammes de classe et de séquence). Le développeur s’appuie sur ces diagrammes (des plans) pour implémenter le système. Dans ce mode un bon logiciel de modélisation est indispensable.
Uml en tan que plan peut aussi servir à faire du reverse engineering (omondo est particulièrement fort à ce petit jeu).
Uml en tant que language:
MDD.. Model driven développement. L’ensemble du système est décrit en uml. On appuie sur un bouton et l’implémentation qui va bien est généré automatiquement (c’est un peu plus compliqué que ça mais c’est l’idée). L’un des buts d’UML 2.0 est de mieux supporter MDD et MDA (model driven architecture)

On peut aussi se servir d’Uml pour la capture des besoins (c’est proche d’uml en tan que croquis): les diagrammes de cas utilisation. Mais attention l’important dans un cas d’utilisation ce n’est pas le dessin avec les petits bonhommes mais la description qui va avec. Les diagrammes de classes et/ou d’objets sont aussi de bons supports si les fonctionnels ne les rejettent pas. Modéliser un problème avec un diagramme de classe Uml force à la rigueur en laissant peu de place pour les incertitudes (à moins de tracer des relation n,n dans tous les sens).

Et vous, vous en servez comment d’uml?