mercredi 29 janvier 2014

GRAF - Templates et core models

Rappelons qu’en GRAF, un système, un sous-système, un module ou un composant est une unité de réalisation précise, confiée à une équipe en charge de la réaliser.

Cependant, concevoir l’architecture d’un système d'information nous amène également à définir des principes de fonctionnements généraux, qui pourront s’appliquer à un ensemble de systèmes, de sous-systèmes, de modules ou de composants.

Ces principes de fonctionnements suivent des « gabarits » (templates en anglais) et peuvent aboutir à la construction d’un « modèle commun » (core model) en anglais.

On représente les modèles communs comme des portions de diagramme GRAF classiques, à ceci près que les composants de type « Gabarit » sont représentés sous une forme hachurée, pour les distinguer des composants « instanciés ».


Reprenons l’exemple d’un système d’information qui gère la gestion des habilitations de façon analogue dans chacun des sous-systèmes. On aura par exemple une représentation comme suit :
La partie gauche du diagramme contient des objets de type « gabarit » qui s’incarnent de façon analogue (mais non identique) dans les différents sous-systèmes impliqués.

La partie droite du diagramme contient un sous-système réel : le sous-système  « habilitation » qui fournit aux différents autres sous-systèmes un accès à des données contenant les droits des utilisateurs.

vendredi 24 janvier 2014

GRAF - Conteneurs et sous-systèmes

Dans GRAF - Logique, l’organisation des composants en système, sous-système, module et composants doit être strictement hiérarchique car elle reflète ce qui va être construit, et comment ou pourrait déléguer cette construction à une organisation.

Une question se pose : comment modéliser des composants « communs », utilisés à l’exécution par plusieurs systèmes ?

Le terme « système » vu sous l’angle de l’exécution est identifié dans la notion de « conteneur ». A la différence d’un système (resp, sous-système, module, composant) qui est une unité de réalisation, un conteneur, lui,  est une unité de déploiement.

Prenons l’exemple d’un système d'information constitué d’un sous-système « Front office » et d’un sous-système « Back office ». Supposons que ces deux sous-systèmes utilisent un module de cryptage/décryptage, qui est développé une seule fois mais déployé deux fois : une fois dans le front-office et une fois dans le back-office.

On distinguera alors le sous-système « front-office » du conteneur « front-office ».
Le conteneur « Front office » contient le module de cryptage, mais ce dernier étant réalisé « à l’extérieur », ne fait pas partie du sous-système « front-office ».

idem pour le back office.


Complexifions encore le problème et supposons que l’IHM du back office soit doté d’un client riche. Comment distinguer dans le modèle les composants (AJAX par exemple) qui sont conçu pour s’exécuter dans le navigateur, des composants qui s’exécutent sur le serveur ? là encore, l’identification des conteneurs va permettre de préciser le modèle.


lundi 20 janvier 2014

GRAF et la représentation des données

Dans GRAF - Logique, on représente des silos de données qui n’ont pas encore à ce stade de l’analyse, une matérialisation physique précise : ce ne sont ni des bases, ni des schémas, ni des tables.
GRAF distingue principalement
- Les données persistantes (données référentielles ou transactionnelles)
- Les paramètres (qui sont persistants en général)
- Les données mémoire

On associe les données de façon très globales en représentant :
- ensembles et sous-ensembles
- liens (1, N, N :N, 1 :1, etc.)


Ces concepts sont tous illustrés dans le schéma suivant qui modélise la gestion des habilitations dans une application :


A la connexion :
- A1 : Récupération des droits de l’utilisateur dans le silo de données des habilitations. Ce silo est constitué de 3 sous-silos liés entre eux : Utilisateurs, Rôles, Profils,
- A2 : Sauvegarde de ces droits dans la session de l’utilisateur qui est un silo de données en mémoire.

Au cours de la navigation :

- B1 : l’utilisateur navigue vers une page,
- B2 : le composant qui gère la page récupère les rôles de l’utilisateur dans la session,
- B3 : le composant qui gère la page récupère également la liste des fonctions autorisées (boutons, items de menu, etc.) pour chacun de ces rôles,
- B4 : le composant qui gère la page valide ensuite les fonctions si elles sont autorisées, les invalide sinon.

jeudi 16 janvier 2014

GRAF : Les opérateurs logiques "ET" et "OU"

Les groupes « ET » et « OU » permettent de schématiser un grand nombre de flux avec une importante économie de moyens.


Dans le diagramme suivant :


-       - Séquence A : l’entrepôt de données est alimenté par un composant qui puise ses informations dans trois silos de données : Source 1 ET Source 2 ET Source 3
-      -  Séquence B : le requêtage sur l’entrepôt de données est effectué par l’un des deux composants : « Requêtage ad’hoc » OU requêtage prédéfini

3 flèches au lieu de 6 permettent de modéliser ce fragment d’architecture.

dimanche 12 janvier 2014

GRAF et les séquences

La description des séquences a deux rôles majeurs.
·       Donner un sens de lecture au diagramme
·       Permettre de suivre le déroulement d’un processus.

Prenons l’exemple d’un processus (très simplifié) d’un déploiement de certificats sur un ensemble d’équipements. Le processus se déroule en deux étapes :
·       A : Demande de certificat par l’équipement (lors de son installation par exemple)

·       B : Connexion de l’équipement  aux serveurs.

Les séquences sont les suivantes :

·       A0 : L’équipement génère une bi-clef (SEQU, PEQU)
·       A1 : L’équipement envoie une demande de certification (CSR ) à l’autorité d’enregistrement en lui fournissant la clef publique PEQU, cryptée par la clef privée temporaire SEQU-TMP
·       A2 : L’autorité d’enregistrement contrôle PEQU en décryptant le message à l’aide de la clef publique temporaire PEQU-TMP
·       A3 : L’autorité d’enregistrement transmet la CSR à l’autorité de certification
·       A4,A5 : L’autorité de certification renvoie le certificat à l’autorité de certification qui la retransmet à l’équipement
·       A6 : l’équipement stocke son certificat.


·       B1 : L’équipement est en mesure de communiquer avec le serveur en SSL avec authentification mutuelle en lui présentant son certificat. Les deux certificats sont chiffrés avec la clef privée de l’autorité de certification

mardi 7 janvier 2014

GRAF et la granularité de la représentation

La représentation des composants et des flux dépend du niveau de détail du modèle choisi.
Prenons un exemple simple de consultation d’une base de données par un utilisateur à partir d’un ensemble de requêtes pré définies encapsulées dans des services d’accès.

On pourrait avoir la représentation suivante :


Dans le cadre de la modélisation d’un système d’information  complet, C’est une représentation trop détaillée.
Pour se construire un modèle plus synthétique, nous allons regrouper les composants en 2 modules « logiques » :
·         un module de « haut niveau » qui contient les composants IHM et les services d’accès
·         un module de « bas niveau » qui contient les accesseurs à la base de données.

Ce qui peut se représenter de façon détaillée comme ceci :


Mais dans une vision globale, nous nous contenterons de cette représentation là :


Remarquons que dans cette dernière représentation, le flux utilisé est un « flux banalisé » (car imprécis), et que le protocole ne peut pas être précisément indiqué.

lundi 6 janvier 2014

La représentation des flux (2)

Bien, sûr, pour prendre en compte la complexité des échantges, et suivant le niveau de détail désiré, GRAF permet d'ajouter de nombreux "décorateurs" sur les flux.

Exemple :


vendredi 3 janvier 2014

La représentation des flux (1)

Rappelons que dans la démarche GRAF :
·         les composants représentent des « unités de réalisation » qui doivent être fabriquées et livrées à l’assemblage
·         les flux représentent les échanges d’information lors de l’exécution des composants.
Représenter les flux sur un schéma  requiert de choisir parmi un nombre important d’informations à coder graphiquement (initiateur du flux, cible, paramètres transportés, valeur retournée, protocole utilisé, utilisation d’un pivot, etc.)
Dans le cadre de l’architecture logique, GRAF a choisi 4 modes de représentations graphiques qui caractérisent les modalités de communications fondamentales :
·         appels synchrones
·         appels asynchrones
·         liens entre canaux et plus particulièrement entre IHM (hyperliens, redirection, porlets, etc)
·         Echanges de données « banalisé », utilisé par exemple quand on ne connaît pas (encore) la modalité de l’échange
Un flux est représenté par une flèche. Notons que les 3 premiers types de flux la flèche va de l’initiateur du flux vers celui qui le subit. Pour le dernier type de flux, la flèche va de la source de donnée principale (par exemple, une base de donnée, un fichier) vers celui qui la consomme.