GRAF - Anticiper de la charge d'un système d'information

le VAT (Volumetrics Analysis Tool) de GRAF permet de simuler la charge d’un système d’information dès la phase de la réalisation, et ce, sans qu’il soit besoin d’installer un environnement de performances.

Il suffit pour cela au cours de la réalisation de mesurer la consommation unitaire des différents traitements et de modéliser la volumétrie des différents flux, puis d’utiliser le VAT pour obtenir les différentes consommations de ressource sur les différents serveurs de l’environnement de production.

Il y a pour cela deux environnements à considérer :

• L’environnement sur lequel la mesure unitaire peut être effectuée (par exemple, l’environnement de développement ou l’environnement de recette)
• L’environnement de production sur lequel le système doit tourner à la cible

Prenons le cas le plus simple (mais souvent vérifié dans la pratique), dans lequel le serveur sur lequel s’effectuent les mesures a le même modèle de processeur que le serveur cible. Notons au passages que ces processeurs peuvent être logiques ou physiques.

L’unité de mesure de puissance (GVPU - GRAF Virtual Power Unit) la plus simple à considérer est la milliseconde d’occupation du processeur, que l’on pourra utiliser dans les deux environnements.

Il suffit pour cela d’utiliser comme unité dans GRAF la transaction étalon (te), et de déclarer que chacun des processeurs de l’environnement cible a une puissance de 1000 te :

Exemple, dans un environnement SAP on pourra déclarer dans l’onglet « serveur » :

nom	description	Gvp	Gvpu
ECC_AS_SD	Serveurs ECC AS et SD	1000	te/s
CP1PROLASx	Serveur AS CRM	1000	te/s

Tentons à présent de simuler à la cible la consommation de ressources d’un batch de facturation. Nous supposerons pour cela que le batch s’exécute dans une plage d’activité nocturne de 22 h00 à 7h00

On déclare donc dans l’onglet « plage »  son profil d’activité : « Prof_NuitA_22_7 » :

Il nous faut connaitre, maintenant la volumétrie du flux de facturation. Pour cela, on choisit le type d’objets métier que l’on va dénombrer dans la mesure. En l’occurrence nous avons choisi le « poste », c'est-à-dire la ligne de facture. L’analyse fonctionnelle doit nous permettre d’évaluer le nombre d’objets traités par jour.

On décrit alors  dans l’onglet « macroflux » le macroflux de facturation :

nom	description	plage	vol/j
			/j
MF_Facturation	Génération des factures	Prof_NuitA_22_7	10 725 000

Il faut ensuite décrire dans l’onglet « hébergement » un composant (virtuel dans l’exemple) qui héberge le traitement de ce macroflux sur le serveur (ou le groupe de serveurs) considéré :

composant	description	serveur
C_COM_967_Facturation_AS_SD	Génération des factures dans sur les serveurs ECC (Aplication serveur et serveur de données)	ECC_AS_SD

Notons au passage que pour simplifier la modélisation et la mesure, nous avons dans cet exemple simulé l’ensemble des serveurs de SAP ECC comme un seul serveur. Il est bien sûr possible d’être plus fin dans la modélisation et de séparer AS et SD.

Nous sommes prêts à présent à décrire le traitement dans l’onglet « traitement » et à reporter la mesure unitaire que nous avons réalisée dans l’environnement de mesure :

nom	description	composant	serveur	macroflux	plage	vol/j	prop%	trt/j	c cpu
						/j	%	/j	Gvcu
T_C_COM_967_Facturation_AS_SD	Génération des factures dans sur les serveurs ECC (Aplication serveur et serveur de données)	C_COM_967_Facturation_AS_SD	ECC_AS_SD	MF_Facturation	Prof_NuitA_22_7	10725000	100%	10725000	183,582

Nota : nous verrons dans un prochain article comment on peut effectuer cette mesure unitaire.

Le VAT fournit alors la consommation de ressources en terme de CPU à la cible :

GRAF - BPMN ET PROCESSUS MÉTIER Suite

Nous avons vu dans l'article précédent comment mixer GRAF et BPMN pour illustrer la conception logique d'un processus métier. Le schéma obtenu est très parlant. A ce stade néanmoins il reste assez abstrait et il manque une quantité importante de détails pour être capable d'organiser l'implémentation du système.

Pour préparer l'implémentation nous ajouterons donc un certain nombre de composants :

1. Tout d'abord, le swinlane BPMN peut être implémenté par un orchestrateur BPM
2. Les demandes client sont stockées dans une base de données. 
3. Une fois les demandes affectées aux vendeur, elle sont transformées en tâches qui sont  stockées dans une base de données contenant les différentes corbeilles de tâches des différents vendeurs
4. Un composant alimente périodiquement l'orchestrateur avec les demandes déposées par les clients
5. Un composant assure l'interface entre le portail du vendeur et l'orchestrateur.

Le schéma GRAF peut alors être représentée de la manière suivante :

3 GRAF - BPMN ET PROCESSUS MÉTIER

GFAF permet de mixer des modèles de représentation de façon à s’assurer de la cohérence complète du système d’information.

Par exemple, l’association entre GRAF « logique » et la notation BPMN permet de représenter le fonctionnement « organique » d’un processus métier. Cette représentation illustre directement l’interaction entre les activités (notamment les activités humaines) et les composants du système d'information.

Reprenons encore une fois l’exemple de l’agence de voyage et illustrons par un  Diagramme GRAF+BPMN le processus  de gestion des réservations qui permet la constitution d’un dossier voyage.

Le processus de gestion des réservations peut être activé par la réception de l’un ou l’autre de ces deux événements :

• A1 : Le client dépose une demande sur le portail client.
• A’1 : Le vendeur ouvre la fonction de réservation

Dans le premier cas, une première activité du processus consiste à affecter la demande à un vendeur qui va la traiter. Cette activité consiste à déclencher le composant « Affectation demande » (A2), qui va pousser la demande dans la corbeille de tâches d’un vendeur.

• B0, B1 Un vendeur ouvre une demande de sa corbeille des tâches

Il doit effectuer deux activités (peu importe l’ordre) :

• Réserver un hôtel
• Réserver un avion

Ce sont des activités qui nécessitent une interaction avec l’utilisateur, d’où la présence de l’icône représentant un personnage.

Au cours de ces deux activités :

• C0 : Il y a un échange (en général téléphonique) entre le client et le vendeur
• C1, C2 Cet échange entraîne l’envoi d’un ordre de réservation :

1.     C3 : à un hôtel, via l’usage du connecteur « Résa hotel »
2.     C’3 : à une compagnie aérienne, via l’usage du connecteur « Résa avion »

• D1, D2 : puis aboutit à l’enregistrement du dossier

GRAF - Génération automatique de la préparation des ateliers

Cette fonctionnalité est disponible à partir de la version 2.3.1 de GRAF

GRAF permet d’accélérer la préparation des ateliers collaboratifs de définition de l’architecture.

Pour préparer un atelier rapidement et efficacement, l’idéal est que tous les participant disposent :

• d’un ou plusieurs schémas GRAF de la portion d’architecture à examiner
• d’une explication des différents éléments du schéma, qui explique notamment la cinématique des flux.

CalliGRAF propose un outil très simple permettant de pré-générer un texte décrivant les différents flux.

Ce texte pourra bien sûr être adapté manuellement de façon à apporter des précisions qui améliorent la lisibilité de la représentation. Toutefois, l’usage des propriétés GRAF sur les objets visio permet d’avoir déjà un niveau de lisibilité élevé dans le texte généré.

Le texte généré est élaboré de façon à ce qu'on puisse facilement y insérer les n° de séquence (manuellement) avant de re -trier le tout (manuellement toujours, en utilisant le mode « plan » de word) de façon à ce que les séquences arrivent en ordre.

Remarque : certaines explicitations de flux devront également être dupliquée manuellement  lorsque plusieurs séquences utilise le même flux.

Chacun des flux génère un texte conforme à la grammaire suivante :

[SEQ]: < GRAF_désignation (composant source)><GRAF_dénomination (composant source)>

envoie 

< GRAF_désignation (flux)><GRAF_dénomination (flux)>[<GRAF_documentation(flux)>]

vers

< GRAF_désignation (composant cible)><GRAF_dénomination (composant cible)>

Exemple :

Supposons que pour notre agence de voyage nous ayons préparé un atelier « Décisionnel » à l’aide du schéma suivant :

Renseignons quelques propritétés GRAF. Par exemple sur flux qui porte la séquence A2 :

GRAF_désignation : « le’ordre d’insertion »

GRAF_dénomination : « Données métier »

GRAF_documentation : « dans la base en étoile »

Remarquons au passage que dans GRAF, une désignation, qui sert à clarifier le type de l’objet GRAF considéré doit avoir la syntaxe :

<article porteur du genre>[<apostrophe si élision>]<syntagme nominal de la désignation>

d’où la formulation « le’ordre » plutôt que « l’ordre » pour aider CalliGRAF à connaitre le genre du nom qui suit.

Il suffit, une fois que le diagramme et éventuellement les propriétés ont été élaborées, d’ajouter la directive « générer atelier » dans le fichier de paramétrage « plan.txt » de l’arborescence CalliGRAF.

Le texte généré est alors :

·         [SEQ] : le silo de données transactionnelles « Réservations client » envoie le résultat de l'extraction de données « Données métier [lues via des requêtes informatica] » vers le module de paramétrage « Alimentation reporting »

·         [SEQ] : le silo de données transactionnelles Factures envoie le résultat de l'extraction de données « Données métier [lues via des requêtes informatica] » vers le module de paramétrage « Alimentation reporting »

·         [SEQ] : le module de paramétrage « Alimentation reporting » envoie l'ordre d'insertion des « Données métier [dans la base en étoile] » vers le silo de données décisionnelle « Décisionnel voyage »

·         [SEQ] : le silo de données décisionnelle « Décisionnel voyage » envoie le résultat des requêtes « Données métier [depuis la base  en étoile] » vers le module d'accès à la base décisionnelle « Requêtes reporting voyages prédéfinies »

·         [SEQ] : la page écran « IHM reporting voyage » envoie l'invocation de service « Exécuter rapport » vers le module d'accès à la base décisionnelle « Requêtes reporting voyages prédéfinies »

·         [SEQ] : l'agent interne « Responsable Marketing » envoie l'ordre « Demander rapports » vers la page écran « IHM reporting voyage »

 

GRAF - Génération automatique de la documentation fonctionnelle

On peut, avec la version 2.3 de GRAF,  utiliser CalliGRAF pour générer une documentation et un référentiel fonctionnel. Il suffit pour cela de créer une arborescence CalliGRAF , dans laquelle nous placeront  des diagrammes fonctionnels.

Reprenons le diagramme fonctionnel du BLOG précédent concernant l'agence de voyage

Ce diagramme est dans l’onglet \Voyage Fonc/ du fichier visio : Cali_Voyages V0.3

On aura donc deux fichiers à positionner dans notre arborescence CalliGRAF

Voyage
    |____vsd
                    |____ Cali_Voyages V0.3.vsd
    |____param
                    |____schémas.csv
                    |____...

Le fichier schéma.csv a la structure suivante :

des	fichier	onglet	nom	court
1	Cali_Voyages V0.3.vsd	Voyage Fonc	Voyage - schéma fonctionnel	VOY_FONC

Lancement de GRAFEXTRACTOR V2.12

Lancement de CalliGRAF V4.7

Extrait du document généré :

1.1.1 /           Quartier Facturation

Le quartier Facturation appartient à la zone « Facturation comptabilité »

Il apparaît dans le schéma GRAF suivant :

·       Voyage - schéma fonctionnel

Prochainement ici, l'inclusion du document descriptions\ssys Facturation.doc*...

Prochainement ici, votre commentaire issu de la propriété GRAF_commentaire...

Prochainement ici, votre explication issue de la propriété GRAF_documentation...

Interfaces du quartier Facturation :

Cette liste est limitée aux interfaces non associées à un module précis du sous-système.

source vsd : 1 VOY_FONC Cali_Voyages V0.3.vsd \_Voyage Fonc_/

·       destination du flux métier « Valider facture » venant de l'agent interne Gestionnaire

source vsd : 1 VOY_FONC Cali_Voyages V0.3.vsd \_Voyage Fonc_/

·       origine du flux métier « Envoyer Facture » allant vers l'agent externe Client

GRAF - Architecture fonctionelle vs architecture logique - 2

GRAF permet de représenter une architecture fonctionnelle à un haut niveau en utilisant les symboles suivants :

• Zone, Quartier, Îlot, Bloc : organisation hiérarchisée des groupes de fonction
• Données référentielles : données dont l’évolution est relativement lente. Par exemple, utilisateurs, points de vente, etc.
• Données transactionnelles : données produites en masse par le système d'information : commandes, relèves, factures, etc.

Il est bien sûr possible d’utiliser les autres symboles de GRAF pour compléter le schéma ; groupes ET et OU, séquences numérotées, etc.

Un point important concerne les flux. la différence principale entre un flux logique et un flux métier, est qu’un flux métier est simplement un transfert d’information entre un bloc fonctionnel et un autre bloc fonctionnel, sans préjuger de la modalité de ce transfert, ni même du fait que ce transfert soit informatisé.

Si l’on est absolument certain ce flux est informatisé, il n’est pas interdit de le remplacer par le flux logique adéquat.

De même, un silo de donnée métier est différent d’un silo de données logique dans la mesure où son identification n’est pas liée au découpage en sous-système, module, composant, et peut être plus global.

Mapping entre architecture fonctionnelle et architecture logique

Sur des projets de grande taille, l’architecture fonctionnelle et l’architecture logique ne sont en général pas traitées par les mêmes équipes. Il est donc souhaitable d’élaborer un mapping entre les blocs fonctionnels et les composants qui les implémentent.

Ce mapping peut être complexe à représenter car de nombreux composants on des rôles transversaux (sécurité, échanges, portails, etc.)

GRAF propose d’étiqueter le bloc fonctionnel par un symbole miniaturisé du sous-système, du module ou du composant qui l’implémente.

Architecture fonctionnelle du SI "Agence de voyage"

Reprenons encore une fois notre agence de voyage dont nous avons élaboré dans d'autres articles l'architecture logique. Son architecture fonctionnelle aurait pu être (préalablement) modélisée comme suit :

Les zones et les quartiers possède des étiquettes permettant de faciliter le mapping avec l'architecture logique. Rappelons en la codification :

codification système -- lettres de codification des systèmes
GRAFVOYAGE=Y
Résa Hotels=H
Résa Avions=A
Resp. Marketing= M
Client=  C
Vendeur=V

codification sous-système -- lettres de codification des sous-systèmes


Marketing= M
Gestion demandes client =G
Facturation comptabilité=   F
Préparation DV=             P
Echanges=                   E

GRAF - Architecture fonctionelle vs architecture logique

Il est courant dans l’analyse des systèmes d'information de distinguer la modélisation du « quoi construire », de celle du « comment construire », ou autrement dit de séparer l’analyse des besoins de celle des solutions.

Lors du travail quotidien des architectes informatiques, cette distinction est néanmoins chargée d'ambiguïté. En effet, une spécification fonctionnelle entre-t-elle dans la catégorie des besoins ou dans celle des solutions ? la réponse dépend des interlocuteurs considérés.

• Pour les utilisateurs métier, une spécification fonctionnelle est une solution à réaliser qui répond à leur besoin métier
• Pour les responsables de la réalisation du système, une spécification fonctionnelle est un besoin décrit sous la forme de fonctionnement attendu du système, auquel il faut apporter une solution en termes d’implémentation

Pour lever cette ambiguïté, clarifions les définitions :

• Architecture fonctionnelle d’un système d'information : organisation hiérarchique des caractéristiques et du comportement d’un système d'information tels que perçus par les utilisateurs ou les systèmes externes à ce système d'information. Les niveaux de cette hiérarchie sont classiquement : Zone, Quartier, Îlot, Bloc.
• Architecture logique d’un système d’information : organisation hiérarchique des composants d’un système d’information qui doivent être réalisés, assemblés puis déployés pour ce système d'information puisse fonctionner. Les niveaux de cette hiérarchie sont dans GRAF : Système, Sous-système, Module, Composant.
• Architecture physique d’un système d'information : infrastructure logicielle et matérielle qui héberge l’implémentation des composants du système d'information.

Exemple : Prenons le système d'information d’une agence de voyage. L’architecture fonctionnelle comprendra différentes zones. Par exemple :

Vente,

Facturation,

Marketing,

Habilitation

On peut imaginer une relation simple  entre les zones et les sous-système dans les trois premiers cas :

•  La zone « Vente » est par exemple implémentée par trois sous-systèmes : « Gestion demandes client » pour la partie front-office, « Préparation DV » pour le back office, et « Echanges » pour la communication avec les systèmes de réservation d’hôtels et d’avion.
•  La zone « Facturation » est implémentée par le sous-système « Facturation comptabilité »
• La zone Marketing est implémentée par le sous-système Marketing

Le cas de la zone habilitation est plus complexe, car si l’on doit prévoir un sous-système « Habilitations » qui serait en charge de la gestion des droits utilisateurs, tous les autres sous-systèmes doivent prévoir des composants qui participent au contrôle de ces droits.

Le schéma logique est le suivant :

GRAF - Volumetrics Analysis Tools - 7 - La génération d'une combinatoire de scénarios possibles

Reprenons l’analyse de la consommation CPU de notre application « Voyage » sur le serveur de données SAP, et évaluons ce qui se passe la dernière année du déploiement :

Il est tentant évidemment d’étaler la plage de facturation sur une durée plus longue afin de réduire les besoins en ressources machine. Toutefois, nous supposerons que pour des raisons métier liées à la gestion de l’agence, le DSI considère cet étalement simplement comme un scénario possible, et souhaite avoir une analyse qui présente les deux scénarios.

La démarche GRAF à suivre est la suivante :

Etape 1 :  Créer une variable Excel qui contient la décision d’appliquer ou non le scénario. Ici une variable booléenne suffira. Nous l’appellera « Etalement_Fac » qui prendra la valeur « VRAI » si le choix d’étaler dans le temps la facturation est validé, FAUX dans le cas contraire

Insérer cette variable dans l’onglet « Parm » (Paramètres)

paramètre	valeur
année	an 4
col_an	6
Etalement_Fac	FAUX
onglet_volu	VOYAGE
complément	pour l'année an 4
path	C:\Users\surcouf\Dropbox\GRAF V2.0\Blog\Juin 2014\[Volumétrie Agence voyage V0.2.xlsm]X_cpu
VAT	Volumétrie Agence voyage V0.2.xlsm
date	16/06/2014

Etape 2 : créer dans l’onglet "plage", la plage d’activité alternative avec la facture étalée

nom	description	%	c0	c1	c2	c3	c4	c5	c6
			qq	qq	qq	qq	qq	qq	qq
Pla_Web_Voy	Interactions sur le site public		10	10	10	10	10	10	10
Pla_Com_Voy	Interactions des agents internes		0	0	0	0	0	0	0
Pla_Bat_Fac	Facturation		0	20	40	40	0	0	0
Pla_Bat_Fac_Et	Facturation étalée		0	10	20	20	20	20	10

Etape 3 : Dans l’onglet « macroflux », pour  le macroflux de facturation, remplacer le nom de la plage de facturation initiale, par une formule qui choisi la plage en fonction du scénario :

 Le raccourci <Contrôle> <Shift> C permet de visualiser le Graphique résultat dans G_Plage chaque fois qu’on change la valeur du scénario dans  l’onglet « Parm ». Ce raccourci facilite de test de notre paramétrage du VAT.

Etape 4 : Pour préparer la génération du rapport, nous incluons ce scénario pour l’an 1 et pour l’an 4. On utilise pour cela une deuxième colonne de  paramètre en indiquant que le nom du deuxième paramètre est « Etalement_Fac ».

onglet_pub	onglet_sce	clef_sce	parm_1	parm_2
			année	Etalement_Fac
CPU_P-MVO-W-1_an 1	G_cpu	P-MVO-W-1	an 1	FAUX
CPU_P-MVO-T_an 1	G_cpu	P-MVO-T	an 1	FAUX
CPU_P-ECH -T_an 1	G_cpu	P-ECH -T	an 1	FAUX
CPU_P-MVO-D_an 1	G_cpu	P-MVO-D	an 1	FAUX
CPU_P-FAC-T-1_an 1	G_cpu	P-FAC-T-1	an 1	FAUX
CPU_P-FAC-D_an 1	G_cpu	P-FAC-D	an 1	FAUX
CPU_P-FAC-D_an 1_Et	G_cpu	P-FAC-D	an 1	VRAI
CPU_P-MVO-W-1_an 4	G_cpu	P-MVO-W-1	an 4	FAUX
CPU_P-MVO-T_an 4	G_cpu	P-MVO-T	an 4	FAUX
CPU_P-ECH -T_an 4	G_cpu	P-ECH -T	an 4	FAUX
CPU_P-MVO-D_an 4	G_cpu	P-MVO-D	an 4	FAUX
CPU_P-FAC-T-1_an 4	G_cpu	P-FAC-T-1	an 4	FAUX
CPU_P-FAC-D_an 4	G_cpu	P-FAC-D	an 4	FAUX
CPU_P-FAC-D_an 4_Et	G_cpu	P-FAC-D	an 4	VRAI

La macro de génération construit ensuite tous les onglets du rapport conformément à la combinatoire demandée.