Les codes couleur des composants
L'objectif d'un jeu de codes couleur est de permettre aux
acteurs participant à un atelier ou au relecteurs des dossiers d'architecture
de saisir rapidement et de manière globale les grands axes directeurs de l’architecture
modélisé.
On a potentiellement une infinité de codes couleurs pour
répondre à une infinité de besoins. Or, pour la clarté du modèle, ces derniers
doivent être en nombre réduit, et être facilement perceptibles sur tous les
supports (vidéoprojecteur notamment).
Dans GRAF, les codes couleurs des composants suivent la
stratégie suivante :
1. Un code couleur
pour chacun des 2 premiers niveau hiérarchiques : Système,
Sous-système », et systèmes extérieurs à l’étude, afin de mettre en
évidence la « macro urbanisation » du système d'information
2. Un jeu de codes
couleurs identiques pour les 2 niveaux suivant (module et composant). En
effet :
a. le modèle suit une
logique identique que l’on décrive le système globalement ou que l’on descende
un peu plus dans le détail,
b. Lorsqu’on identifie un composant nécessaire à
l’architecture, on ne sait pas toujours au départ s’il ne faudra pas, dans la
suite de l’étude, le
« promouvoir » en module, et vice-versa.
3. Pour le niveau module et composant, 1 (ou 2) code couleur
pour chaque « couche » de traitement, les couches étant
classiquement :
a. Canal (accès de l’utilisateur au système d'information, qui
matérialisent en général des composants IHM)
b. Orchestration (BPM par exemple, mais aussi composant d’ordonnancement
pour les batch)
c. Traitement
d. Données
e. Echanges (traitements de transformation de la donnée lors
des échanges de système à système)
Pour la couche traitement on sépare dans GRAF :
Les composants (modules) qui
font l’objet d’un développement spécifique
Les composants (modules) qui matérialisent le paramétrage
d’un progiciel.
