Blog Objet Direct

Cet article traite d’une question récurrente lorsque l’on modélise un cas d’utilisation dont la particularité est son lancement automatique et périodique. En support des explications apportées, j’ai utilisé comme exemple la mise à jour quotidienne des données clients en prenant en compte les transactions effectuées depuis la dernière mise à jour, objectif du cas d’utilisation Mettre à jour les encours clients.

Pour modéliser ce cas de figure, il est courant d’utiliser l’horloge du système (timer) comme acteur primaire, celui-ci représentant le déclencheur du cas d’utilisation. Est-ce la meilleure méthode pour modéliser un cas d’utilisation déclenché périodiquement? C’est ce que cet article va tenter de clarifier par la présentation de trois approches différentes :

Approche 1 : le cadenceur est un acteur primaire

Une tache périodique étant effectuée en interne par le système, elle ne porte pas de comportement visible d’un point de vue analyse boite noire. Comme cette tache porte une fonctionnalité du système, elle fait partie du périmètre étudié.

Dans cette approche de modélisation, le cadenceur est une fonction interne que l’on sort du système (d’un point vue boite noire), et que l’on identifie comme acteur primaire basé sur le raisonnement suivant : le cadenceur déclenche le cas d’utilisation de façon périodique. Le cadenceur ne porte pas la définition d’un acteur primaire car il n’a pas d’objectif dans l’exécution du cas d’utilisation. En effet, d’un point de vue UML, un acteur primaire est un utilisateur du cas d’utilisation ayant un but visible dans son exécution. Néanmoins dans le cas où aucun évènement déclencheur (trigger) n’est défini, la première action de l’acteur primaire peut être vue comme l’évènement déclencheur (ou trigger) du cas d’utilisation, d’où la modélisation du cadenceur comme acteur primaire.

Cette approche, couramment pratiquée en UML, permet d’indiquer sans équivoque que chacun des cas d’utilisations associés à un Cadenceur décrivent une fonctionnalité déclenchée de façon cyclique par le système. Le choix du terme « cadenceur » permet de rester au niveau de l’analyse n’indiquant pas la solution pour le réaliser. Lors de la conception, il sera alors possible de répondre à la spécification fonctionnelle par exemple en utilisant une horloge système.

Approche 2 : l’acteur primaire doit avoir un objectif dans l’exécution du cas d’utilisation

Cette approche alternative consiste à utiliser un acteur primaire ayant un but visible dans l’exécution du cas d’utilisation.

Dans l’exemple de mise à jour des encours clients, l’acteur primaire est le Comptable car celui-ci a un objectif dans l’exécution du cas d’utilisation ‘Mettre à jour les encours clients’ : obtenir un état à jour des encours de chacun des comptes clients.

La particularité porte sur le fait qu’il n’y a pas d’interaction entre l’acteur primaire et le système étudié. L’évènement déclencheur (trigger) du cas d’utilisation est représenté par l’acteur secondaire « Cadenceur  » dans le souci de présenter visuellement le fonctionnement cyclique de ce cas d’utilisation – cela est optionnel mais il est recommandé de conserver le Cadenceur sur ce diagramme permettant d’indiquer cette particularité au lecteur.

Si l’on ne souhaite pas représenter l’acteur secondaire Cadenceur, il est également possible de définir un évènement déclencheur (trigger) dans le cas d’utilisation, par ex : « Le cadenceur du système déclenche ce cas d’utilisation ».

Approche 3 : aucun acteur

La dernière approche proposée consiste à n’associer aucun acteur à ce cas d’utilisation. D’un point de vue UML, cela est tout à fait correct car l’on représente un cas d’utilisation ne comportant pas d’interaction avec un acteur externe. Il est alors possible de spécifier comment le cas d’utilisation est déclenché par son trigger.

Un cas d’utilisation sans acteur risque de susciter des difficultés de compréhension et des questions.

Conclusion

J’ai personnellement toujours appliqué la première approche pour différents projets en modélisant le Cadenceur (ou utilisant une variante de ce terme selon le contexte) comme acteur primaire. J’ai trouvé l’exercice d’identification et d’évaluation des approches alternatives utile pour mieux comprendre comment l’approche retenue parait la plus appropriée.

Commit Monitor : outil de notification et de surveillance de dépôts SVN, dans le cadre d’une utilisation avec l’outil de modélisation UML Enterprise Architect

Commit Monitor est un outil gratuit (licence GPL) très simple d’utilisation. Il permet de surveiller des dépôts SubVersion pour être notifié de nouvelles modifications.
Cet outil réside dans la barre de tâches et utilise très peu de ressources du système.
Commit Monitor consulte les logs du serveur SVN pour détecter de nouvelles versions et en afficher les détails.

Cet outil peut être très utile lorsqu’un projet de modélisation UML Enterprise Architect, dont les modèles sont gérés par un serveur SVN, est utilisé en mode collaboratif par plusieurs utilisateurs.

Après installation, l’icône de Commit Monitor apparaît dans la barre de tâches :

Commit Monitor permet de rajouter chacun des projets SVN à surveiller par la saisie des informations suivantes :

• Username / password : l’identifiant et le mot de passe du compte SVN
• Check every xxx minutes : par défaut Commit Monitor va interroger le serveur SVN toutes les 90 minutes ; cette valeur peut être modifiée dans ce champ
• Project : nom du projet surveiller, par exemple Projet1 EA
• URL : url du dépôt SVN, par exemple https://11.22.33.44/svn/Projet1/

Commit Monitor notifie l’existence de nouvelles versions lorsque son icône animé apparait :

A l’ouverture de Commit Monitor, les projets surveillés sont affichés en gras – par exemple Projet1 EA (4) dans la capture d’écran ci-dessous – lorsque de nouvelles versions restent marquées en non lues (chacune des lignes correspond à une nouvelle version) :

Le tableau affiché comprend les colonnes et informations suivantes :

• Numéro de révision
• Date et heure
• Auteur (compte utilisateur SVN)
• Contenu du message saisi dans le log

En cliquant sur une ligne, la version correspondante est marquée comme « lue » et automatiquement cette ligne n’apparaît plus en gras. Il est aussi possible dans cette fenêtre ou via l’icône de la barre des taches de marquer toutes les nouvelles lignes en lues (« Mark all as read »).

Commit Monitor permet d’appliquer un filtre, par exemple pour restreindre les logs à un terme donné comme « Ajout Modèle” en saisissant ce texte libre dans le champ Filter :

A noter que cet outil peut être également utilisé pour surveiller les projets de développement, de la même façon que les fichiers XMI d’un projet UML EA utilisé en mode collaboratif et présenté dans ce post.

Commit Monitor est disponible en téléchargement depuis le lien suivant : http://code.google.com/p/commitmonitor/downloads/list

Suite à la formation donnée il y a quelques mois sur « UML2 et SysML pour modéliser des systèmes complexes », j’ai posté un article sur le Wiki d’Objet Direct pour présenter le langage de modélisation SysML (Systems Modeling Language), dérivé de l’UML.
SysML est destiné aux domaines d’activité industrielle, par exemple les systèmes embarqués impliquant la réalisation de solutions logicielles et matérielles.
Ainsi il propose un vocabulaire plus adapté à l’Ingénierie Système, à savoir la modélisation de blocs plutôt que de classes. SysML adapte et ne réutilise qu’une partie des diagrammes UML2, évitant ainsi d’être trop vaste.

Ce langage, maintenu par l’OMG, est en constante évolution (adopté en 2006, la version 1.2 est sortie en Juin 2010). Il  est aussi supporté par la plupart des outils UML via un plugin (ex: Enterprise Architect version Ultimate ou avec le plugin SysML).

Article Wiki « Présentation du langage SysML »

Objet Direct co-organise la 4e édition du MD Day, la journée consacrée aux approches « Model Driven ».

La conférence MD DAY propose un état des lieux du secteur logiciel inspiré de cette approche. Des experts reconnus y exposeront les concepts fondateurs, les avantages qui en découlent et les perspectives business escomptées : mise en oeuvre sur des projets complexes, complémentarité avec SOA, niches de marché, … Les principaux acteurs français du domaine y présenteront leur offre sous un angle pragmatique en mettant l’accent sur des projets concrets qu’ils décriront avec leurs clients finaux au travers de réalisations concrètes et opérationnelles.

Nouveauté cette année : l’agilité sera au coeur des conférences.

Principaux temps forts : intervention de Steve Cook, Membre de l’OMG ; table ronde avec des acteurs incontournables de l’agilité.

Outre l’agilité, bon nombre d’autres thèmes seront abordés : modélisation fonctionnelle, génération de code, modernisation du SI, orchestration de processus métier, exécution des modèles, DDD Domain Driven Design, choix entre UML et DSL, …

Grégory Weinbach (Responsable du Pôle MDA d’Objet Direct) et Jérémie Grodziski (fondateur d’Adixe) animeront une conférence sur le thème « Modélisation et agilité sont-ils compatibles ? La piste du Domain Driven Design », avec le témoignage de l’Administration du Canton de Vaud.

Ce MD Day 2010 se tiendra le 25 novembre à Paris, au centre des congrès de Microsoft, l’un des co-organisateurs.

Programme complet et inscriptions : www.mdday.fr (événement gratuit, sur réservations fermes).

Intégrer Enterprise Architect dans une approche agile, outiller toute la démarche projet, promouvoir la modélisation UML, formaliser le contrat entre MOA et MOE, centraliser et partager l’information métier et technique, assurer la traçabilité entre les exigences et les processus métier, générer une documentation de qualité, formaliser et capitaliser le métier, …

Objet Direct a détaillé tous ces contextes d’utilisation à l’occasion des 3 événements organisés à Paris, Lyon et Grenoble ces jours-ci, sur le thème « Enterprise Architect, outil stratégique du dialogue entre le métier, l’IT et les applications », en s’appuyant sur les retours d’expérience projets menés chez Boiron, EDF, PSA, au Conseil d’Etat et au CHU de Grenoble.

Vous pouvez télécharger la présentation : ici

This post is available in english on my personal blog.

Je rentre juste de trois jours aux QCon de Londres. C’est comme toujours un grand moment permettant une véritable prise de recul. Je peux respirer, ouvrir les yeux sur ce que font les autres et comment ils travaillent, sentir quelles sont les tendances et surtout, tenter d’appréhender ce que sera mon job dans un an, voire, plus loin.

Promis, je vous ferai, dans les jours qui viennent, une compilation des meilleurs moments de la conférence et des points les plus marquants. Mais avant tout, je voulais vous faire une réaction à chaud sur quelque chose qui me semble important.

Je reviens aujourd’hui avec un goût désagréable dans la bouche (non ce n’était pas la bière qui était, comme toujours, excellente). Un goût amer et un peu de colère aussi.

En deux mots : la modélisation n’est plus simplement absente (comme c’était pratiquement le cas lors des deux dernières éditions), c’est devenu un gros mot.

Que le code soit à l’honneur, c’est bien naturel dans une conférence consacrée au développement. Que l’on fustige les erreurs commises par le passé (en particulier la “sur modélisation” symptomatique d’un déficit de confiance dans les processus de développement) me semble aussi plutôt sain.

Mais que l’on entende des sentences définitives du genre “comme chacun le sait, les modèles ne servent absolument à rien” dans la bouche de stars comme Robert C. Martin, alias Uncle Bob (qui a pourtant écrit en 2003 un remarqué “UML for Java Programmers” !), qu’un Dan North (par ailleurs excellent, je vous en reparlerai) considère l’usage d’un modeleur comme une inutile “complification”, relève de l’hypocrisie, de la démagogie ou de l’intégrisme (voire de la simple bêtise, indissociable du dernier).

La seule conférence à laquelle j’ai assisté qui faisait encore la part belle aux modèles était celle d’Eric Evans qui parlait de conception agile. Encore avait-il rayé le mot Modèle du titre, pour celui de Design plus consensuel. C’est lui qui a, d’ailleurs, eu le mot juste : en abandonnant la modélisation, la communauté du développement a, un peu trop rapidement “jeté le bébé avec l’eau du bain” (sic).

En fait, j’ai eu l’impression d’être dans le domaine du religieux et d’assister à des professions de foi.

Il y a, d’un côté, les fondamentalistes du code, pure monothéistes, nostalgiques d’un âge d’or mythique où le développeur était le seul maître de sa production, en relation directe avec Dieu (le Product Owner), dépositaires d’un savoir millénaire (le Software Craftsmanship) qui se transmet de bouche de gourou à oreille de disciple.

Et il y a la secte des UMListes, vus comme de dangereux illuminés schismatiques, dont les délires auraient corrompus le monde parfait des précédents et qu’il faut exterminer par tous les moyens. J’ai eu l’impression d’être soumis à une fatwa.

Comme toujours lorsqu’il y a des problèmes, il faut trouver des boucs émissaires. Les modèles (et ceux qui les font) semblent jouer ce rôle aujourd’hui : symboles du “Big Upfront Design”, c’est eux qui portent la responsabilité des échecs des grands projets. Les modèles sont vus comme des artefacts de pure documentation : modéliser serait une activité chronophage et inutile (voire perverse), en particulier dans un monde agile.

Dans un tel environnement, impossible de sortir ma carte de visite : sous mon nom, il y a marqué “MDA business line manager”. Comme une maladie honteuse.

Pourtant, il me semble que modéliser, au contraire de développer, permet :

• d’analyser un problème,
• de compresser sa complexité,
• d’appréhender sa globalité,
• de s’abstraire de contingences techniques,
• de communiquer.

Mon cerveau n’est pas suffisant pour faire tout ça sans assistance. J’ai besoin d’UML (ou de tout autre formalisme), à la fois comme d’une béquille, d’un tableau blanc, d’une extension de mémoire et d’un formulaire de maths.

Modéliser n’est pas antagoniste de développer (sans parler de MDA qui combine les deux activités) : modéliser permet simplement de mieux développer.

Et d’ailleurs, le code EST un modèle (“système d’abstractions qui décrit des aspects sélectionnés d’un domaine”), au même titre qu’un diagramme UML. Juste un peu plus verbeux (et un peu plus facilement exécutable).

Pour conclure, il me semble que ce hiatus est, avant tout, très représentatif de modes de pensées différents : une pensée analytique “à la française” (après tout, Descartes et Merise sont des créations bien de chez nous) face à une pensée pragmatique anglo-saxonne.

J’aime à penser qu’il y a du bon dans les deux mondes et que les deux se complètent agréablement. C’est même ce qui, à mon avis, constitue l’intérêt principal de notre métier : analyser des problèmes pour informatiser leur résolution. C’est ce qui quotidiennement renouvelle ma motivation : comment faire rentrer dans un (bon) programme la complexité du monde réel.

3 nouveaux événements techniques organisés et animés par Objet Direct, en avril : « Enterprise Architect, outil stratégique du dialogue entre le métier, l’IT et les applications »
… Pour des modèles UML utiles, à jour et partagés.

Quels sont les scénarios qui favorisent une utilisation pragmatique des modèles au sein des projets, petits, grands, agiles ou en cascade ? Quels sont les atouts d’Enterprise Architect ?
Réponses et démos lors de ces séminaires Objet Direct, avec les retours d’expérience projets menés chez PSA, EDF, au Conseil d’Etat et au CHU de Grenoble.

=> le 7 avril à Lyon, le 8 avril à Grenoble, le 14 avril à Paris, 9h-11h (accueil petit déjeuner)
Evénements gratuits, sur réservation ferme.
En savoir plus et s’inscrire en ligne sur le site d’Objet Direct.

J’ai pu assister, avant-hier, à une des deux sessions de présentation à destination des partenaires de Sparx, des nouvelles fonctionnalités de la version 8.0 d’Enterprise Architect qui devrait sortir d’ici quelques semaines.

Il ne s’agit pas d’une révolution mais plutôt d’une version apportant des améliorations ponctuelles mais importantes.

Je ne vous ferai pas une présentation exhaustive mais plutôt un survol de quelques points marquants selon moi.

Saisie structurée des scénarios

La nouveauté la plus importante pour les utilisateurs de l’outil dans les phases de recueil de besoin : les scénarios associés à un Use Case sont maintenant structurés (auparavant, ils étaient saisis sous forme de texte libre) et peuvent être associés à des diagrammes. Mieux, ces diagrammes (séquence, communication ou activité) peuvent être générés à partir du contenu textuel structuré.

Chaque étape d’un scénario apparait dans une ligne, une icône en en-tête caractérisant l’étape courante (sollicitation par l’acteur ou réponse du système). La numérotation des étapes est automatique et est maintenue dans les scénarios alternatifs qui y font référence.

Le descriptif de l’étape est textuel mais intègre éventuellement des renvois (sous forme de lien hypertexte) vers les termes définis dans le glossaire.

Cette fonctionnalité est d’ailleurs aussi disponible dans le texte des Notes :

Workflow de projet

On peut créer un Workflow décrivant un enchainement de tâches à réaliser par les utilisateurs de EA en fonction de leur rôle (défini par la notion de “groupe” d’utilisateurs). Une tâche peut-être associée à un script (une requête). Cela permet, par exemple, d’affecter au “Project Manager” une tâche de validation des « exigences approuvées » ou de contrôle des « classes non implémentées ».

La présentation (très rapide !) de cette fonctionnalité n’a pas permis de comprendre toutes les conséquences de ces nouvelles fonctionnalités mais il semble qu’il s’agisse d’un premier pas vers la possibilité d’instrumenter une démarche projet.

Environnement de travail

Les “Visual Layouts” personnalisés (sauvegardes de l’environnement de travail avec position des fenêtres, toolbars customisées…) sont maintenant nommés et en nombre illimité.

Duplication de package

Il est maintenant très simple de dupliquer un package entier. Les fonctions “Copy package / Paste package” sont maintenant disponibles. Le résultat est le même que lorsqu’on fait un export XMI suivi d’un réimport.

La 3ème édition du MD Day a été un succès, avec plus de 230 participants venus assister aux 12 conférences et cas clients consacrés aux approches Model Driven.

Toutes les présentations sont disponibles au téléchargement sur le site http://www.mdday.fr/, en particulier celle d’Objet Direct et de son client le CIG Petite Couronne : Grégory Weinbach (OD) et Yannick Chazeau (CIG) ont raconté le succès du projet de modernisation du SI du CIG, grâce à une approche innovante basée sur le MDA (Model Driven Architecture) => l’équipe projet a mené à bien en 1000 jours/hommes la refonte globale d’un parc applicatif client/serveur qui avait nécessité 4800 j/h (22 années/hommes) de développement.  Les applications cibles Web Java/Seam/JSF, ont été développées en Scrum.

Disponibles également les présentations des autres partenaires et des keynote speakers Jean Bézivin et Andrew Watson, VP et Directeur Technique de l’OMG.

Petit rappel : Objet Direct et 9 partenaires éditeurs spécialistes du MD co-organisent le 3ème MD Day, la journée consacrée aux approches « Model Driven ».

Quelques nouvelles infos sur ce MD DAY 2009, en complément de mon billet du 4 septembre : 

Cette rencontre à destination des DSI et des architectes IT reprend la formule qui a fait le succès des 2 éditions précédentes : conférences animées par des experts, retours d’expérience clients, démonstrations d’outils. Cette année les keynotes speakers seront Jean Bézivin, chercheur en informatique, et Andrew Watson, Vice President et Directeur Technique de l’OMG.

Grégory Weinbach, Responsable du Pôle MDA d’Objet Direct, animera une session sur le thème : « Du Client / Serveur au Web, moderniser son SI grâce au MDA », avec le témoignage du DSI du CIG Petite Couronne.

Ce MD Day 2009 se tiendra le 26 novembre à Paris, au centre des congrès de Microsoft, l’un des co-organisateurs.

Programme complet et inscriptions : www.mdday.fr (événement gratuit, sur réservations fermes).