Archive

Articles taggués ‘modélisation’

Processus métiers en entreprise : pourquoi, comment (première partie)

Petite mise au point

Le précédent article nous a permis d’avoir une image plus claire du processus métier par rapport à la nébuleuse de définitions que l’on peut rencontrer sur les différents types de supports  à disposition (livres, web, cours, …).

Dans cet article, nous allons tenter d’éclaircir un peu plus l’aspect ‘pourquoi’ (utilité, utilisation) du processus métier, sachant que nous resterons concentrés sur les processus métier eux-mêmes, et non leur modélisation (outil de représentation), pour le moment, en nous limitant aux métiers de l’IT.

 Quelques questions intéressantes

Voici des questions qui reviennent dès que le thème des processus métier est abordé :

  • Pourquoi étudier ou modéliser un processus métier (ou à quels processus faut-il s’intéresser) ?
  • Quels processus modéliser en priorité ?
  • Selon quel niveau de détail (profondeur et transversalité) ?
  • Modéliser l’existant ou la cible ?

Les réponses à ces questions nécessiteraient des volumes entiers, et encore, uniquement pour défendre différentes visions inspirées par des contextes particuliers. Nous allons juste apporter, ci-dessous, quelques éléments de réponse.

Lire la suite…

Processus métiers en entreprise : introduction et notions

Cet article est le premier d’une série destinée à vous familiariser avec les processus métiers et leur rôle fondamental dans la réalisation de systèmes informatiques répondant aux objectifs du métier.

Dans cette série d’articles, nous utiliserons et comparerons deux notations standards (UML et BPMN) à travers des exemples concrets. Nous tenterons de voir dans quel cas chaque notation est la mieux adaptée.

Processus métiers en entreprise

Définition (agrégation de différentes sources)

C’est un enchaînement d’étapes à réaliser pour répondre à un objectif métier identifié. Ces étapes sont des actions réalisées par différents acteurs et synchronisées par des échanges. Le processus métier crée de la valeur au sein d’une organisation.

Quelques représentations d’un processus

Représentation selon une notation spécifique (UML – Eriksson-Penker)

Lire la suite…

SysML 1.3 disponible

La version 1.3 du langage de modélisation SysML est officiellement disponible. Les spécifications sont accessibles depuis le site de l’OMG.
SysML 1.3 apporte principalement des changements sur la définition des ports : les full ports et proxy ports remplacent les flow ports et ports standards.
Pour plus d’informations sur les changements avec SysML 1.3, voir mon post sur SysML 1.3 bêta.

SysML 1.3 bêta

SysML, le langage de modélisation OMG basé sur UML et adapté à l’ingénierie système, est actuellement en version 1.3 bêta. Cette version devrait être officielle au mois de Juin.

SysML 1.3 apporte de nombreux changements à la définition des ports, points d’interactions sur les Blocs. Pour rappel, SysML 1.2 intègre les ports standards pour exposer des interfaces, et les ports de flux (flow ports) pour représenter ce qui peut circuler en entrée et/ou en sortie d’un bloc, que ce soit des données, de la matière ou de l’énergie.

Les “flow port” et les “port specifications” de SysML 1.2 ont été abandonnés dans la version 1.3, mais leurs concepts ont été conservés. Les changements apportés dans la version 1.3 portent sur la définition et l’implémentation de ces concepts, qui se résume de manière non-exhaustive par les points suivants :

  • Ports complets (full ports)
    • permet de représenter une partie intégrante du bloc sur la frontière du bloc principal (main block boundary)
    • un port complet est typé par un bloc; il peut ainsi combiner les flux d’éléments en entrée/sortie et l’exécution d’opérations, remplaçant respectivement les flow ports et les ports standards de SysML 1.2
    • les interfaces ne sont alors plus exposées sur le port, supprimant l’utilisation de la notation lollipop
    • les ports complets peuvent être « conjugés » comme dans les flow ports de SysML 1.2 ayant pour effet d’inverser la direction des éléments ; cela a le même effet sur les opérations i.e. les opérations fournies par le bloc sont alors des opérations requises

OMG SysML 1.3 Full Port - port complet

  • Ports proxy
    • sert de proxy aux fonctions du bloc principal ou de ses parties intégrantes
    • un port proxy ne porte pas de comportement, ni ne constitue une partie du bloc principal
    • les flux d’éléments ou l’exécution d’opérations sur le port proxy sont transmis directement vers le bloc principal ou une partie intégrante
    • un port proxy est typé par un bloc d’interface (block interface) pour spécifier les fonctions disponibles (éléments, opérations), alors que les ports complets comme indiqué précédemment sont typés par des blocs

OMG SysML 1.3 Port Proxy

  • Ports et flux imbriqués (nested ports & flows) : SysML permet de définir des ports imbriqués ; pour cela le bloc utilisé comme type du port possède lui-même des ports

OMG SysML Ports imbriqués (nested ports)

  • Blocs d’association : ces blocs permettent de définir la compatibilité entre ports de blocs différents

En conclusion
SysML 1.3 propose une implémentation et une approche plus complète que la version 1.2 actuelle pour gérer la notion de ports, flux et connecteurs sur les Blocs. Il évite par exemple la duplication de ports si l’on a besoin de définir un port pour transmettre des éléments et fournir des opérations.
Ce changement pourrait avoir un impact non négligeable dans l’organisation du modèle comme l’on ne va plus exposer les interfaces sur un port. Par exemple, il semble que ce sera le bloc, utilisé comme type du full port, qui va réaliser les interfaces du modèle (dans le cas où un référentiel d’interfaces existe). Si un bloc doit appeler des opérations d’un autre bloc, on remplacera donc le lien entre deux interfaces required/provided de SysML 1.2, par le lien entre un full port et son inverse (full port du même type mais conjugué).

La seconde édition du livre “A Practical Guide to SysML” de Sanford Friedenthal (consultant MBSE et membre de l’OMG),  Alan Moore, et Rick Steiner est déjà disponible et intègre SysML 1.3 (cf. chapitre 7.6) ; ce livre fournit ainsi des exemples concrets sur l’utilisation de full ports, proxy ports, interface blocks, etc.
Lorsque le langage SysML 1.3 sera officiel, il sera intéressant de voir si les éditeurs d’outils de modélisation SysML tel que Sparx Systems (Enterprise Architect) auront intégrés ces nouveaux principes par une utilisation simple (par exemple pouvoir changer facilement une partie intégrante en ‘full port’ par le choix de la porter sur la frontière du bloc).

Nouvelle version 9.3 d’Enterprise Architect

Sparx Systems vient de sortir la version 9.3 de son outil de modélisation Enterprise Architect avec les améliorations suivantes :
– Affichage simultané des diagrammes

ergonomie diagrammes simultanés sous EA 9.3

– Customisation complète de la barre de menus sous EA
– Simulation :
* support BPMN 2.0
* utilisation de tableaux pour simuler l’exécution d’un diagramme d’état parmi les choix suivants : Etat-Etat Suivant | Etat-Evènement déclencheur (trigger) | Evènement déclencheur (trigger)- Etat

– Module ‘Execution Analyzer’ : affichage des interactions entre instances multiples d’une même classe dans un diagramme de séquence
– Gestion des Testpoints pour définir des conditions de test (invariants multiples par classes, pre-conditions et post-conditions multiples par opération)

– Support Archimate 2.0

Remarque : les patterns GoF accessibles depuis l’onglet ‘Resources’ ne sont plus installés par défaut. Il faut désormais les télécharger depuis le site de Sparx

Quel acteur pour un cas d’utilisation déclenché périodiquement?

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 pour SVN/EA

logo commit monitorCommit 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

Modélisation de systèmes avec SysML

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 »

MD DAY 2010 : le 25 novembre à Paris

Logo MD DAYObjet 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).

Enterprise Architect : présentation Objet Direct et cas clients

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