Discussion :

[moldavi]

Bonjour.

Je suis en train de faire le tour des Webcasts Microsoft, et je suis tombé sur Workflow Foundation. Juste par curiosité, j'ai visionné la vidéo d'apprentissage.

Je ne vois pas de différence entre coder une application classique et utiliser les outils de Workflow.

La seule chose que je retiens c'est que l'on a un designer graphique de la logique de son workflow (avec les if/else/code, etc...). Pour le reste on écrit quand même du code.

D'où ma question, à quoi ça sert, par rapport à du code pur ?

PS : excusez ma naîveté, je découvre cette technologie.

[Mickael_Istria]

Hello,

A chaud, voila les 3 principaux arguments que je vois:
1. Tu gagnes en productivité: Dessiner un process/workflow est plus rapide et plus simple que d'écrire du code
2. Tu es plus proche du fonctionnel et t'affranchis d'une part de technique qui est du coup fournie dans le moteur de workflow. Un gars qui n'a jamais codé est capable de dessiner un workflow, et si l'outil est bon, de l'exécuter
3. Tu peux faire évoluer ton systeme en faisant évoluer juste certains workflows, et ce sans douleur.

[moldavi]

Bonjour et merci pour cette réponse.

1. Tu gagnes en productivité: Dessiner un process/workflow est plus rapide et plus simple que d'écrire du code

A vue de nez, j'avais plutôt l'impression du contraire. Le développement .net est quand même très productif. En mode design, on a un travail supplémentaire je trouve.

Tu es plus proche du fonctionnel et t'affranchis d'une part de technique qui est du coup fournie dans le moteur de workflow. Un gars qui n'a jamais codé est capable de dessiner un workflow, et si l'outil est bon, de l'exécuter

C'est que je pensais au premier abord. Sauf que l'on doit quand même écrire son code. Donc la personne n'est pas vraiment novice.

Après effectivement on a un graphique des spécifications fonctionnelles (plutôt sympa). Ne serait-ce pas là tout son intérêt ?

Tu peux faire évoluer ton systeme en faisant évoluer juste certains workflows, et ce sans douleur

Ok pour ça.

Peut-être que de savoir qui utilise ce genre de techno m'aidera à comprendre.
Tes réponses me suggèrent que pour une entreprise qui souhaitent des graphiques des spécifications, c'est tout adapté, et effectivement, un novice en la matière pourrait commenter et donner son avis sur de tels graphiques.

[The_badger_man]

Il s'agit d'un model qui permet une séparation entre ce qu'il faut faire et quand il faut le faire. Cela permet de changer le quand sans affecter le quoi.

Les frameworks de workflow sont très utiles pour gérer des problématiques d'interaction avec les humains au sein d'un processus métier.

Fait gaffe aux webcast à 2 centimes qui te montrent comment créer une calculette avec un wordflow. A part te montrer comment utiliser Visual Studio, ça n'apporte pas grand chose sur l'utilisation d'un workflow.

[Mickael_Istria]

A vue de nez, j'avais plutôt l'impression du contraire. Le développement .net est quand même très productif. En mode design, on a un travail supplémentaire je trouve.

Avec du BPM / Workflow, tu attaques direct des applications haut-niveau (ECommerce, réapprovisionnement, pilotage de chaine de production...) tres vite. Tu es directement plusieurs niveau au-dessus de ce que tu peux faire avec du code. Du coup le gain est vraiment énorme sur ce genre d'appl.
Par contre si c'est pour coder un quick-sort, c'est clairement moins utile, car c'est pas fait pour.

C'est que je pensais au premier abord. Sauf que l'on doit quand même écrire son code. Donc la personne n'est pas vraiment novice.

Les bonnes solutions de BPM découplent le code technique du design métier. Les bouts de code peuvent etre externalisés a des purs devs et mis a disposition des gens plus fonctionnels, qui n'auront qu'a jouer au lego avec.

Après effectivement on a un graphique des spécifications fonctionnelles (plutôt sympa). Ne serait-ce pas là tout son intérêt ?

C'est en effet de la que tout est parti je pense. Créer un langage spécifié (genre BPMN) qui est utilisable par des fonctionnels pour spécifier graphiquement leurs attentes, et faire en sorte qu'on puisse aller du dessin en boites et fleches a une véritable application le plus vite (== le moins cher) possible.

Peut-être que de savoir qui utilise ce genre de techno m'aidera à comprendre.

Tu peux par exemple voir des exemples de boites qui utilisent du BPM ici: http://www.bonitasoft.com/products/discover.php. Les gens qui mettent en oeuvre dans les grosses boites sont des équipes projet, avec des gens plutot fonctionnels, des développeurs, des intégrateurs... Mais ca peut tres bien etre utlisé dans des petites boites pour générer des petites applis de gestion sans avoir de grosses compétences de développeurs.

Tes réponses me suggèrent que pour une entreprise qui souhaitent des graphiques des spécifications, c'est tout adapté, et effectivement, un novice en la matière pourrait commenter et donner son avis sur de tels graphiques.

Je suis a peu pres d'accord. L'objectif est, comme beaucoup de technos, de combler le fossé entre spécification fonctionnel et développement logiciel.

[moldavi]

Merci, les choses commencent à s'éclaircir.

Fait gaffe aux webcast à 2 centimes qui te montrent comment créer une calculette avec un wordflow. A part te montrer comment utiliser Visual Studio, ça n'apporte pas grand chose sur l'utilisation d'un workflow.

Je n'irai pas jusqu'à dire qu'il y a des webcasts à 2 centimes , mais j'avoue que parfois certains sont soit superficiels par rapport au sujet, soit c'est du pur marketing (mais c'est le jeu)...

Pour celui qui concerne le workflow que j'ai visionné, effectivement c'était une présentation basique, mais honnêtement, pour quelqu'un qui se lancerait c'est un bon départ. En tout les cas, c'est mieux que d'être seul face à visual et se dire, bon comment qu'on fait...

Après effectivement, je n'ai peut-être pas visionné le bon webcast.