Archives mensuelles : août 2012

Représenter la complexité ou complexifier la représentation ?

Une représentation sous forme de graphique est parfois la meilleure façon de représenter la complexité d’un système d’information ou d’une application.

Par exemple, à l’échelle d’une application, un diagramme de classe est souvent plus clair qu’une grande description écrite. En effet, le graphique symbolisant des classes par des boites et des relations par des flèches est on ne peut plus adapté.

À l’échelle du SI, les représentations d’architecture normalisées sont moins convaincantes. Mais au delà de ce manque de formalisme dans les représentations, c’est surtout la réalisation et la maintenance de ces représentations qui sont coûteuses et fastidueuses. Les outils sont souvent peu productifs, qu’ils s’agissent d’outils bureautiques ou d’outils de modélisation. Si les données à représenter existent déjà sous une forme structurée, il est possible de réaliser une large partie de ces représentations avec une certaine forme d’automatisation, ce qui pourtant reste très peu présent dans les outils courants.

L’objectif de cet article est de proposer une approche simple pour automatiser la représentation graphique de données structurées. Cette approche a été validée par une première implémentation.

Les types de problèmes à traiter

La première question à se poser porte sur le sens que donne une
représentation. En effet, une position relative, un alignement, ou encore un
style de flèches ou une couleur peuvent avoir une sémantique particulière dans
le graphique : des boites de la même forme sont du même type, un alignement de
plusieurs étapes représente un flux, etc.

De plus, selon le type de graphique, un même élément peut avoir plusieurs
types de représentations ou encore plusieurs dispositions différentes. Dans
notre exemple du diagramme de classe, la représentation de la classe est faite
sous forme de boite rectangulaire contenant les attributs et les méthodes, alors
que dans le cas d’un diagramme de séquence, cette même classe sera au sommet
d’une ligne vertical depuis et vers laquelle les méthodes appelées seront
reliées.

Dans l’optique d’une représentation graphique, il y a donc plusieurs aspects
que nous allons considérer : les styles, le placement et enfin le routage. Il
est donc primordial d’avoir un paramétrage commun qui permette à la fois de
définir tous ces aspects mais aussi de sélectionner les éléments sur lesquels ce
paramétrage doit s’appliquer. L’approche retenue sera un paramètrage déclaratif
sous forme de règles. En effet celui-ci permet de de pouvoir facilement se
rattacher à un type d’objets, à un attribut, etc., tout en donnant une syntaxe
claire.

Style

Tout d’abord, le style des éléments pourra être personnalisé. Couleur, forme,
transparence, etc. pourront ainsi être renseignés dans les règles. Mais le point
clé est que ces styles peuvent avoir une signification dans le graphique : des
éléments d’une couleur de plus en plus foncé en fonction du nombre de leur
liens, une flèche en pointillés pour des liens d’une certain nature par
exemple. Le style est donc déterminé par des attributs qui caractérisent un
objet, son type (application, classe, ligne de vie d’un objet) et d’autres
attributs qui le définissent, comme par exemple la distinction synchrone,
asynchrone pour les fleches dans un diagramme de séquence.

De plus, ces aspects graphiques peuvent avoir eux aussi une incidence sur le
placement des éléments. Par exemple, on peut vouloir contraindre un objet à être
d’une certaine taille ou forme, et alors les autres éléments autour de celui-ci
devront prendre en considération cet aspect de style.

Placement

De la même façon qu’un style peut avoir une signification, un placement aussi
peut porter une sémantique particulière. Le cas le plus parlant est sans doute
celui de l’arbre, dans lequel les éléments d’un même niveau hiérarchique seront
sur un même niveau visuel. De même, pour reprendre l’exemple du diagramme de
classe, on peut se placer dans une logique où les attributs sont traités de la
même manière que les objets. Alors le nom de la classe doit être au dessus
dans une case séparée, suivie de deux autres cases pour respectivement les
attributs et les méthodes, chacune sous forme de liste.

Ces placements peuvent correspondre à une norme ou à une simple
standardisation adoptée pour un type de graphique. Le placement est donc porteur
de sens et à ce titre constitue une contrainte à satisfaire. Cela peut-être un
alignement, un positionnement relatif, un chevauchement ou encore un groupement
logique. Ces groupements logiques sont par exemple le plus souvent représentés
par une inclusion visuelle d’un ou plusieurs éléments dans un autre. Alors
l’élément englobant devra prendre en compte les caractéristiques ( taille, marges) de ses éléments fils pour sa propre
disposition.

Pour chaque regroupement d’objets, des dispositions spécifiques pourront être
adoptées. Les trois dispositions de base qui ont été implémentées sont :

  • en grille (celle-ci permettant également de réaliser une ligne
    horizontale ou verticale selon le nombre de lignes et de colonnes) ;
  • en cercles, avec des éléments fils sur un cercle centré sur le père ;
  • en arbre.

Au delà de ces contraintes de placement, une optimisation du placement est
souvent bénéfique. En effet, même sous une ou plusieurs contraintes, un certain
degré de liberté peut perdurer pour les objets, et alors un algorithme peut être
utilisé pour optimiser le positionnement. C’est notamment cette phase qui permet de
rendre la représentation plus visuelle et naturelle en éloignant les blocs qui
ne sont pas reliés entre-eux, et en rapprochant ceux qui sont reliés comme s’ils
étaient joints par des ressorts. Cette optimisation peut être atteinte avec un
algorithme de type

Force-directed
.

Routage

Même si les entités supportent souvent la majeure partie des règles de
positionnement, les relations sont toutefois aussi à prendre en compte. Et
de la même manière qu’on parle de disposition pour les éléments, on parle de
routage pour un lien. Ainsi plusieurs aspects sont importants à considérer :

  • le ou les libellés du lien (par exemple un libellé au centre du trait et des libellés aux extrémités) ;
  • le choix des points d’ancrage en fonction du sens de la relation, du placement relatif des objets, du nombre de relations qu’ont les objets et de la sémantique qui est donnée aux différents ports ;
  • et pour finir le routage en lui-même, qui est composé de deux choses : la
    stratégie, qui peut consister à minimiser la longueur, le nombre
    d’intersections, etc., et le type de ligne, comme une courbe de Bézier ou des
    liens orthogonaux.

Cas d’usage

Le cas le plus simple à envisager est l’inclusion d’un élément dans un autre
c’est le cas d’une boite qui en contiendrait plusieurs autres, par exemple
pour affiché les traitements exécutés par une application à l’intérieur de
celle-ci. Cette boite père devrait de par sa nature avoir une taille qui
s’adapte à la taille de ses fils et à leur disposition. Dans la même idée,
l’algorithme doit pouvoir être appliqué tout en respectant les contraintes,
comme l’illustre la figure ci-dessous.

Blog_graphslide17

Mais cela devient encore plus délicat quand ces contraintes se composent. Un
exemple de cette composition de contraintes est illustré ci-dessous à gauche.
Dans celui-ci, on contraint les rectangles arrondis à être alignés
verticalement, et les formes bleues à être alignées horizontalement. Dans cette
configuration un rectangle arrondi bleu doit se trouver au croisement de ces
deux regroupements, si bien que les deux systèmes de contraintes
(un pour les rectangles, l’autre pour les formes bleues), se
retrouvent liés. Ainsi, le premier système s’articule initialement autour de
deux inconnus, de même pour le second, mais la composition des deux n’aura
globalement que deux inconnus. En effet, la composition induit une relation
entre les inconnus du premier système et ceux du second.

Blog_graphslide19

Le dernier cas, illustré dans la figure ci-dessus à droite, est encore plus
complexe. Dans ce cas on exige un alignement vertical des formes bleues, et les
rectangles arrondis sont eux disposés en grille. Alors on remarque que
l’organisation interne de la grille est dépendante d’une contrainte externe.

Proposition de résolution de ce problème

Le modèle général

Le modèle général envisagé fonctionne par composition de règles, de telle
manière que chaque élément peut être contraint par rapport à n’importe quel
autre élément.

Le déroulement se fait en trois étapes :

  • assembler les contraintes : déclarer pour chaque élément les relations
    qu’il dispose par rapport aux autres ;
  • résoudre le système de contraintes pour identifier les degrés de liberté
    restant à optimiser ;
  • appliquer l’algorithme de résolution par rapport aux degrés de liberté
    précédemment identifié.

Le modèle adopté en première approche

Malheureusement le précédent modèle, bien que non restrictif, s’avère d’une
complexité importante. Pour faire une première implémentation, nous nous sommes
donc restreint. En effet, un
premier modèle de contraintes hiérarchiques permet de réaliser une grande
partie des besoins, et on ne veut pas complexifier les cas simples au nom de
quelques cas compliqués, les 20% de cas restants à supporter pouvant induire 80%
de complexité supplémentaires…

Hiérarchique, c’est à dire qu’un élément n’est contraint que par rapport à
son père. Ainsi, les éléments sont tous disposés selon un arbre. Les avantages
sont multiples : déjà, le parcours des éléments est grandement simplifié, et
ensuite il n’y aura plus besoin de résoudre les contraintes dans le sens où il
ne pourra plus y avoir plusieurs contraintes sur un même élément. À l’inverse,
ce modèle induit des limitations, notamment dues au fait de se restreindre à une
architecture en arbre. Un élément ne pouvant être contraint que par rapport à un
seul autre élément, on empêche certains cas d’usage tels que la structure en
croix précédemment illustrée.

Le moteur de mise en forme fonctionne donc de façon récursive en parcourant
l’arbre des éléments. À chaque niveau, le moteur demande donc à ses enfants de
se mettre en forme, et chacun d’eux lui renvoie une boite rectangulaire dont les
dimensions sont calculées pour contenir l’enfant et ses petits enfants dans une
configuration donnée.

L’algorithme du moteur de mise en forme comporte 2 étapes principales :

  • une première passe qui depuis la racine du graphique entraîne par
    récursion la mise en forme des enfants. Cette mise en forme consiste à
    positionner les éléments fils relativement au père et à définir la taille
    du container nécessaire pour contenir tous les fils. Ce container n’est pas
    forcément représenté graphiquement, ce sont uniquement ses dimensions qui sont
    utilisées pour ensuite mettre en forme les éléments du niveau supérieur.
  • Une seconde passe, à nouveau récursive depuis la racine, pour calculer à
    partir des positions relatives des éléments leur position absolue sur le
    graphique. Chaque élément, dont la position a été calculée relativement à son
    père, peut simplement calculer sa propre position puis continuer la récursion en
    demandant la même opération à ses fils.

La descente dans l’arbre peut suivre deux types de relations : des relations portées par des données (liens entre objets) qui se retrouvent directement entre les objets graphiques et des relations d’inclusion qui sont matérialisée par des objets que nous avons appelés « ports d’inclusion ». Ce
sont des espaces de forme rectangulaire qui vont pouvoir réceptionner des
éléments selon une configuration établie. Ces ports sont vus comme des enfants
de l’élément, et à ce titre ils s’insèrent de façon identique dans la récursion
et leur fonction de mise en forme renvoie elle aussi une boite aux dimensions
calculées par son contenu.

Cette homogénéité de la méthode permet toute combinaison de mise en forme :
on peut insérer une grille dans un arbre, lui-même dans une autre grille,
etc.

Implémentation

Une implémentation de cette approche a été réalisée. Elle s’appuie sur
un moteur de règles et une implémentation en Javascript, HTML5 et Canvas.

Voici quelques exemples de représentations obtenues automatiquement à partir
d’un jeu de règles et de données d’entrée structurées. Le modèle de données utilisé ici est le modèle enioka des flux entre applications. En particulier, les objets représentés sont des flux contenant des étapes qui ont des stocks de données en entrée et en sortie, ces stocks appartenant à des applications.

Blog_graphenioka

Voici ci-dessus un exemple de ce qui a été obtenu à l’issu de la première
implémentation. Il s’agit d’un diagramme de flux représentant les
différentes étapes du flux alignées, ainsi que les applications en dessous,
en grille de même hauteur de ligne, classées (et non optimisées pour le moment)
pour minimiser le croisement des liens, et contenant des stocks de données,
dont les liens avec les étapes du flux représentent des accès en lecture et
en écriture selon le sens de la flêche. Tout ceci est généré de manière
automatique depuis un ensemble de données structurées.

Conclusion

Il s’agit d’une première étape dans l’automatisation des représentations
automatiques de modèles. Tous les modèles ne se prêtent pas à ce type de
représentation automatisée par des règles. Une évolution pourrait être de
combiner génération automatique et disposition manuelle. Le moteur étant en
charge de générer les formes, les styles, le placement initial et d’assister
les modifications manuelles pour vérifier que certaines règles sont toujours
respectées.

Concevoir des interfaces inter-applicatives : les formats pivots

Suite au précédent billet sur les interfaces, nous allons ici approfondir les intérêts ainsi que les risques que peuvent présenter la mise en place de formats pivots.

La thèse initiale

La promesse faite par les partisans des formats pivots est que leur utilisation permet de réduire les coûts d’intégration : il est plus intéressant que chacune des applications ayant besoin de s’intégrer fasse la moitié du chemin.

Ainsi, une approche directe (sans format intermédiaire) consiste à ce qu’une application conserve son format et ses contraintes et que les applications avec qui elle doit communiquer s’y adaptent. À l’opposé, la mise en place d’un format pivot consiste à définir un format intermédiaire permettant de tenir compte des différents cas d’usages, puis de développer des traitements d’intégration pour que chacune des applications puissent interagir avec ce format.

Qu’est-ce qu’un format

Lors de la mise en place d’un format pivot ou dans la spécification d’une interface entre deux applications, un format représente le contrat sur les données échangées. Nous parlons ici de contrat car la définition de formats pivots prend toute sa dimension dans une approche service des interfaces entre applications, ce qui fera l’objet d’un prochain billet sur le blog.

Que sa description soit formelle ou implicite, le format porte donc :

  • Le type des données échangées : les entités métier qui transitent dans l’interface
  • Le format technique utilisé dans l’interface, ce qui matérialise le format structurel (arborescence, tabulaire, relationnelle), le format du conteneur technique (XML, CSV, tables) et la manière d’encoder chacun des attributs (encoding des chaînes de caractères, format des dates…)
  • Les codifications ou référentiels associés à chacun des attributs
  • La définition des critères d’unicité des entités : les contraintes d’unicité des entités et les multiplicités des relations des données transitant dans l’interface peuvent être différentes de celles des applications impliquées (par exemple la relation entre un client et un dossier client qui peut faire que les entités sont confondues dans certains systèmes (relations 1-1) et pas dans d’autres)
  • La définition de l’ensemble des objets transitant dans l’interface : le sous-ensemble des entités qui sont concernées par l’interface (par exemple, une application de gestion des ressources humaines qui travaille sur l’ensemble du personnel et une application de gestion des contrats avec les entreprises d’intérim qui ne travaille que sur le personnel intérimaire).

La définition de ces formats est une base de la mise en place d’une démarche d’urbanisme des interfaces d’une DSI. Elle permet en effet de distinguer les éléments communs qui doivent être partagés entre les applications de ceux qui peuvent être spécifiques à une application ou une interface. Pour chacune des caractéristiques du format (type de données, formats technique (structurel, conteneur et encodage des attributs), référentiels et codifications), il faut donc se poser la question de l’intérêt d’une homogénéisation ou d’une spécialisation.

Les intérêts des formats pivots

Le premier gain qui peut être attendu lors de la mise en place d’un format pivot est la diminution du coût de mise en place des interfaces.

La description de formats pivot, et des services associés, place les applications dans une relation client-fournisseur. Cette contractualisation permet de définir de manière nette les frontières de responsabilité entre applications et leurs dépendances. Ce n’est pas un hasard si les formats pivots dont l’usage est le plus généralisé (SWIFT et les formats EDI par exemple) se retrouvent dans les interfaces inter-SI : elles se sont placées sur des interfaces qui étaient déjà des relations clients-fournisseur contractualisées.

La généralisation de formats pivots peut également être l’occasion pour une DSI de spécifier une méthodologie de définition de ses formats, une grammaire commune à toutes les applications pour définir les données qui transitent dans les interfaces. Cette grammaire peut s’exprimer en termes d’entités, de relations et d’attributs, dans un vocabulaire de modélisation objet ou dans tout langage de description de données. Cette démarche peut mener jusqu’à une industrialisation des développements des traitements d’intégration (export et import des données des interfaces par les applications) dans les projets.

Spécifier des formats pivots nécessite d’identifier les différentes entités qui circulent entre les applications. Cette spécification est donc également l’occasion de formaliser le dictionnaire de l’entreprise et de définir un langage commun aux utilisateurs des différents métiers et à la DSI. Ceci facilite la communication dans l’entreprise, entre autre lors des projets informatiques.

Enfin, la mise en place de formats pivots autour d’une application facilite son rôle de fournisseur. Durant un projet, cela permet de limiter la quantité de spécificités des clients à prendre en compte à ce qui a été identifié comme suffisamment commun et donc mis dans le pivot et le service rendu par le fournisseur.

De manière générale, dans une interface, la mise en place d’un format pivot profite à l’application qui est du côté où il est seul (souvent le fournisseur). La limite de sa responsabilité est définie et il sera ainsi souvent plus facile de faire bouger un nouveau tiers pour qu’il se conforme à la règle qui est déjà définie et partagée. Il faut aussi garder à l’esprit que le nombre de clients qui utilisent effectivement un format pivot est en général moins grand que ce qui est espéré lors de sa conception initiale pour deux principales raisons : la partie commune peut se révéler trop faible et la complexité de mise en œuvre trop élevée.

Les coûts de la généralisation

La généralisation nécessaire à la mise en place de formats pivots a un coût, qui doit être rentabilisé par la réduction du coût marginal d’une intégration supplémentaire utilisant ce nouveau pivot. Ceci est généralement démenti lors de la mise en place des interfaces jusqu’au format pivot : elles sont souvent aussi coûteuses à mettre en œuvre que des interfaces directes. Mais la principale difficulté réside dans la généralisation nécessaire à la mise en œuvre d’un format pivot.

La mise en place d’un format pivot demande de prendre en compte les spécificités de toutes les interfaces qui vont l’utiliser, ce qui demande un travail de conception beaucoup plus complexe et risqué que de spécifier les formats unitairement. En effet, la construction d’un format pivot par juxtaposition des besoins des différentes applications ne va faire que concentrer la complexité de toutes les interfaces dans un seul format qui sera de plus rigidifié par le nombre de contraintes qu’il porte.

Un pivot est également supposé être utilisé plus longtemps qu’un format pour une interface point à point, ce qui demande de concevoir dès le premier jour son évolutivité. La construction d’un format pivot pose la question de sa responsabilité et de sa propriété. Il faut en effet à la fois un sponsor qui finance cet effort initial dont les gains à court terme ne sont pas évidents et un responsable qui portera l’effort au-delà de la première mise en place. Ces deux rôles sont complémentaires car ils ont des intérêts différents : l’un voudra que le coût initial soit le plus raisonnable tandis que l’autre cherchera à ce que le pivot soit le plus général possible pour pouvoir le diffuser largement dans le SI.

La tentation d’un urbaniste lors de la définition d’un pivot peut être d’essayer d’englober la totalité des notions qui ressemblent à l’objet visé sous prétexte qu’elles portent le même nom ou partagent une structure commune (par exemple facture client et facture fournisseur ou client et prospect). Plus le format prendra en compte de spécificités, plus il sera compliqué de s’accorder sur son contenu et plus il sera complexe à mettre en œuvre. Il est alors important de se concentrer sur les éléments qui sont réellement communs, ce qui peut rendre le format sans intérêt (par exemple lorsque seuls les identifiants et les libellés sont partagés) ou décevant intellectuellement.

Le rythme de mise en œuvre des évolutions à coordonner entre les différentes applications (client(s) et fournisseur(s)) représente une difficulté supplémentaire, à la fois à la conception (réussir à collecter les besoins de tout le monde pour réaliser une version initiale) et dans le maintien de l’interface et des différents environnements dans lesquels elle peut être exécutée. Ce problème de coordination peut résulter dans une situation ou une application principale impose son format au nom de ses contraintes de planning.

La mise en place de formats pivots permet de maîtriser (ou au moins d’identifier) les points de dépendance avec un tiers (fournisseur) ou une application (par exemple un progiciel). Cependant, la mise en place d’un pivot dans le seul but de se rendre indépendant peut conduire à la superposition de couches d’isolation n’apportant aucune valeur (par exemple en imposant un format technique sous prétexte qu’il est technologiquement neutre). D’autre part, à l’échelle d’un SI, vouloir isoler absolument les applications d’un ERP central qui est mis en place pour rester 5 à 10 ans apporte beaucoup de contraintes et bien peu de gains.  Il n’est pas absurde de conserver des parties du format du fournisseur, mais cela doit relever d’un choix et non être subit. Il peut également être tentant de se réfugier derrière un produit (ETL, EAI, ou ESB) ou une technologie (XML) promettant l’isolation. Or, la valeur et la durabilité du format pivot résident dans le modèle et les codifications, pas dans son format technique.

Faut-il mettre en place des formats pivots ?

S’il peut être bénéfique de mettre en place des formats pivots dans les interfaces de service de son SI, à quelles fins ?

Nous pouvons identifier deux cas d’usage où les formats pivots peuvent apporter de réels gains :

  • La diffusion de données de référentiels
  • Le transport de données opérationnelles fortement partagées qui traversent le SI (stock, ventes…)

Dans ces deux cas, il s’agit de données qui sont déjà largement partagées dans le SI. Il est donc ici possible d’espérer tirer les avantages de la mise en place d’un format pivot :

  • Le partage de la définition des données, ce qui en facilite l’interprétation et la cohérence
  • La réduction des coûts d’intégration des applications (développements et données mieux maîtrisés)
  • Dans certains cas, la réduction du nombre de développements d’intégration

Au contraire, certains objets peuvent se révéler être de mauvais candidats pour l’utilisation d’un format pivot. On peut prendre pour exemple l’entité « client ». C’est une notion dont la définition peut varier très largement entre les différentes utilisations qui en sont faites (de la prospection commerciale à la facturation). Non seulement les attributs nécessaires aux différentes étapes du cycle de vie de l’objet ont peu en commun, mais l’identité même de l’objet peut être différente : il faut parfois faire la distinction entre les filiales et les agences d’une même entreprise (au moment de la livraison par exemple) alors qu’elles peuvent être considérées comme une seule entité pour la facturation ou l’évaluation de la solidité financière. C’est un objet dont une représentation unique servant tous les usages du SI est une illusion, ce qui n’empêche pas d’avoir un pivot plus spécifique pour certains usages clairement définis.

Il faut garder à l’esprit lors de la conception d’un format que sa complétude est moins importante que sa souplesse (capacité à y décrire des données de natures différentes et complexes), sa facilité de mise en œuvre (en tenant compte de l’outillage disponible sur le marché et l’intégration aux méthodes et outils de la DSI) et son évolutivité (capacité à évoluer sans rompre la compatibilité avec les utilisateurs déjà en place).

Au-delà des caractéristiques générales que nous pouvons proposer, la conception de formats pivots demande une grande maturité de la fonction urbanisme dans une DSI au point d’avoir une vision de l’évolution du métier de l’entreprise et du SI qui le sert, pour comprendre quels sont les points d’adhérence justifiés et les éléments qui peuvent être mis en commun entre les applications. Surestimer cette maturité est une erreur fréquente des architectes et des urbanistes.

Conclusion

Nous avons vu ici que la mise en place d’un format pivot représente rarement une réduction des coûts de développement. Elle peut cependant permettre un transfert de coût de l’application fournisseur aux applications clientes et un lissage des dépenses dans le temps.

Sur le plan méthodologique, la mise en place de formats pivots et la définition des niveaux de partage (définition des entités, formats techniques, référentiels), permet de matérialiser la démarche d’urbanisme et de faciliter l’industrialisation de l’intégration des applications.

Ce partage et les normalisations associées imposent des rigidités et des difficultés supplémentaires. Celles-ci doivent donc être équilibrées par les gains apportés par la mutualisation.

Nous avons ici évoqué le contrat passé entre les applications sur les données. Or, cette démarche de contractualisation est bien plus vaste et doit prendre en compte les traitements faits sur les données, les cinématiques de plusieurs interfaces, les volumes de données, les capacités d’annulation ou de réémission d’une interface, l’outillage mis à disposition pour le développement et la disponibilité. En résumé, tout ce qui constitue un service, qui sera détaillé dans un prochain billet.