GRAF–Les automates finis 1/2

Il est fréquent d’utiliser la notation BPMN pour modéliser un processus métier. Cette notation présente cependant deux inconvénients majeurs :

• Cette modélisation est complexe,
• L’implémentation d’un modèle BPMN est délicate sans l’aide d’un moteur de BPEL

Dans de nombreux cas, l’implémentation d’un processus métier ne requiert pas l’exécution de traitements en parallèle. Les automates finis représentent Une alternative simple à modéliser et à implémenter.

Un automate fini (on dit parfois, par une traduction littérale maladroite de l'anglais, machine à états finis, au lieu de machine avec un nombre fini d'états), finite-state automaton ou finite-state machine (FSA, FSM), est une machine abstraite constituée d'états et de transitions. Son comportement est dirigé par une succession d’événements en entrée : l'automate passe d'état en état, suivant les transitions, à la réception de chaque événement reçu.
 


Dans GRAF, un automate fini est associé à un composant ou un module, de préférence de type orchestration (couleur violette) afin de décrire de façon détaillée son comportement lorsqu’il reçoit différents flux
Pour intégrer la modélisation de l’automate avec les interactions du composant qui l’implémente et mieux préparer la réalisation, GRAF classifie les événements reçus en relation avec les types de flux de l’architecture logique :

• Invocation synchrone reçue,
• Message asynchrone reçu,
• Événement temporel

Les invocations synchrones se subdivisent en deux catégories :

• celles qui proviennent de l’IHM de l’application qui exécute l’automate
• celles qui proviennent d’un composant, éventuellement externe à l’application

Un événement (non temporel) reçu par un automate se représente par une petite flèche en couleur dirigée vers la gauche, collée à la transition qu’il déclenche. Un événement temporel se représente par une petite horloge :

Lorsque l’automate déclenche une transition pour passer d’un état à un autre, il peut déclencher certaines actions.
Pour intégrer la modélisation de l’automate avec les interactions du composant qui l’implémente et mieux préparer la réalisation, GRAF classifie les actions déclenchées en relation avec les flux et les composants de l’architecture logique :

• Invocation synchrone émise,
• Message asynchrone émis,
• Autre traitement

 

 

Enfin, pour compléter le modèle, l’automate fini peut, à la réception d’un événement ou après le déclenchement d’une action, tester une condition. Suivant la valeur de la condition il pourra déclencher une transition ou une autre.
 

GRAF–Outillage pour les nulls / générer la documentation

 

Pour générer le dossier d’architecture logique de notre mini système d’information il faut

• Finaliser le fichier de paramétrage “CalliGRAF.par” du répertoire “param” de l’arborescence
• Vérifier que le répertoire “doc” de l’arborescence contient le template du document. Dans notre exemple, il s’appelle “Template DAL Commandes.docm”
• Finaliser le fichier “plan.txt”
• Lancer CalliGRAF

 

Finaliser le fichier de paramétrage CalliGRAF

nom du système = COMMANDES--

§style -- définition des styles Word à utiliser dans le template
niveau 1 = Titre 1
niveau 2 = Titre 2
niveau 3 = Titre 3
niveau 4 = Titre 4
niveau 5 = Titre 5
puce     = Liste à puces
puce2 = Liste à puces 2
prose    = Normal
texte tableau=Corps de texte 3

§tri -- règles de tri des objets
syst=type

§codification système -- lettres de codification des systèmes
COMMANDES=C
 

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

--
Gestion des commandes= C
Portail = P

 

Finaliser le fichier plan.txt

prendre Template DAL Commandes.docm
créer DAL Commandes V1.0.docm

générer hiérarchie

terminer

 

Le dossier d’architecture logique est généré dans le répertoire “doc”. En voici un extrait :

1. / Architecture logique du système COMMANDES

Le système COMMANDES est le seul élément considéré dans cette description.

1.1 / Système COMMANDES

Le système COMMANDES est constitué à partir de 2 sous-systèmes :

· sous-système « Gestion des commandes »

· sous-système Portail

1.1.1 / Sous-système « Gestion des commandes »

Le sous-système fait partie du système COMMANDES

Le sous-système « Gestion des commandes » est constitué de 2 modules :

· silo de données Commandes

· module de paramétrage « Gérer les commandes »

1.1.1.1 / Silo de données Commandes

Le silo de données est un module du sous-système « Gestion des commandes »

Interface du silo de données Commandes :

1.1.1.2 / Module de paramétrage « Gérer les commandes »

Le module de paramétrage est un module du sous-système « Gestion des commandes »

Ce module contient le paramétrage de SAP pour la gestion des commandes.

Il contient des règles de gestions développées spécifiquement en ABAP.

Interfaces du module de paramétrage « Gérer les commandes » :

1.1.2 / Sous-système Portail

Le sous-système fait partie du système COMMANDES

Le sous-système Portail ne contient qu'un seul module :

· module canal « IHM intranet »

1.1.2.1 / Module canal « IHM intranet »

Le module canal est un module du sous-système Portail

Interfaces du module canal « IHM intranet » :

…

GRAF–Outillage pour les nuls / générer le commentaire des schémas

L’outil “GRAF_Workshop” permet de générer automatiquement le commentaire des schémas.
Afin que ce commentaire soit lisible plus facilement, il est préférable d’indexer les différents flux avec des numéros de séquence : A1, A2 et A3 sur notre petit schéma de test :

Dans l’arborescence de travail, nous lançons l’outil GRAF_Workshop, puis nous ouvrons l’onglet “param”. Dans cet onglet, nous allons choisir le fichier référentiel récemment généré en cliquant sur le bouton “choisir fichier flux” :

Sélectionnons le fichier généré le plus récent :

Ouvrons ensuite l’onglet “idFlux”. Nos trois flux apparaissent avec leur identité et le le nom court du schéma auxquels ils appartiennent. Dans le cas d’un référentiel complexe avec beaucoup de schémas, il sera possible de filtrer sur le nom du schéma et de les traiter un par un.

Le bouton “calculer différentiel” permet de construire l’écart entre le commentaire précédent du schéma, et le nouveau. Dans notre cas, le commentaire précédent est vide, le différentiel va donc construire l’intégralité des commentaires
Ouvrons à présent l’onglet “Séquences”.

Les premières colonnes de cet onglet rappellent les flux à commenter et affiche les noms des systèmes (resp modules et composants) source du flux ainsi que les noms des systèmes (resp modules et composants) cibles du flux

Ident Flux	SysS	ModS	SysC	ModC
c_CP_IntAveIhm	Commercial	0	COMMANDES	IHM intranet
CPCC_SaiMetJou	COMMANDES	IHM intranet	COMMANDES	Gérer les commandes
CCCC_Commandes	COMMANDES	Gérer les commandes	COMMANDES	Commandes

Le commentaire du schéma va être généré automatiquement par des règles qui permettent de déterminer un “template de commentaire” par défaut et un “verbe d’action cible” (i.e. un verbe précisant comment le flux agit sur la cible), en fonction du type des objets analysés.

Pour nos trois flux, on trouve :

TemplateDéfaut	RgV
Acteur -> IHM	14
Mod -synchrone-> Mod	1
Mod-ecrit-> base	4

On voit que le premier flux a détecté la règle applicable n° 14, qui propose une formulation associée à un flux entre un acteur et un IHM.
Remarque : si le numéro de la règle est égal à 0, GRAF_Workshop n’a pas trouvé de règle applicable. Il est possible alors de rajouter une règle, de forcer un template de commentaire, ou encore de construire une formulation manuellement. Nous verrons dans un billet ultérieur comment ajouter des règles et des templates, ou changer totalement le paramétrage de la formulation.
Pour appliquer les règles :

• sélectionner les règles dans la colonne “RgV” et faire <ctrl>+<Maj>+V
• sélectionner les templates par défaut dans la colonne “TemplateDéfaut” et faire <Ctrl>+<Maj>+D

Séquence	Phrase
A1	Le "Commercial" interagit avec le module canal "IHM intranet" pour interagir avec l'IHM
A2	Le module canal "IHM intranet" appelle le service "saisir et mettre à jour les commandes" fourni par le module de paramétrage "Gérer les commandes"
A3	Le module de paramétrage "Gérer les commandes" enregistre les commandes dans le silo de données "Commandes"

Le commentaire apparait dans la colonne “phrase”. Nous n’avons plus qu’à saisir le numéro de séquence dans la colonne séquence.

GRAF–Outillage pour les nuls / l’identité des objets

 

Reprenons le référentiel généré de notre petite application de test :

Les trois premières colonnes du référentiel contiennent des informations sur l’identité des objets :

• id GRAF : l’identité de l’objet telle qu’elle est gérée dans visio
• idP roposé : une identité proposée par le générateur conformément aux règles de nommage GRAF
• id Retenu : l’identité de l’objet telle qu’elle sera finalement retenue.

 

A quoi sert l’identité d’un objet ?

L’identité sert principalement à deux choses :

• Permettre de représenter un composant ou un flux plusieurs fois dans un diagramme ou dans plusieurs diagrammes sans que le générateur crée plusieurs objets dans le référentiel
• pouvoir référencer l’objet dans les différents outils de CalliGRAF, notamment GRAF_Workshop

 

Quelles sont les règles de nommage d’un objet ?

• Un système est identifié par une lettre (majuscule ou minuscule) ou un chiffre
• Un sous-système est identifié par la lettre ou le chiffre du système auquel il appartient, + “_” + une lettre (majuscule ou minuscule) ou un chiffre.
• Un module est identifié par les deux lettres du sous-système auquel il appartient, + “_” + 9 lettres (majuscule ou minuscule) ou chiffres.
• Un composant est identifié par les 12 lettres du module auquel il appartient, + “_” + 9 lettres (majuscule ou minuscule) ou chiffres.
• Un flux est identifié par 4 lettres (les deux lettres du sous-système source, les deux lettres du sous-système destination) + “_” + 9 lettres (majuscule ou minuscule) ou chiffres + éventuellement “_” + 3 lettres pour finir de caractériser le flux

 

Comment le générateur procède-t-il pour générer les identités ?

Le générateur s’appuie sur le paramétrage de la codification des systèmes et des sous-systèmes décrit dans le fichier CalliGRAF.par

Dans notre exemple, on a :

§codification système -- lettres de codification des systèmes
COMMANDES=C
 

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

--
Gestion des commandes= C
Portail = P

Il génère ensuite un identifiant en utilisant un algorithme qui s’appuie sur le nom de l’objet.

Le module :

du sous-système “Gestion des commandes” du système “Commandes” aura pour  identifiant généré :

CC_Commandes

Le flux représenté par la flèche bleue dans le schéma :

possède un nom en clair dans la propriété GRAF_dénomination : “saisir et mettre à jour les commandes”.

Le générateur construit alors l’identifiant :

CPCC_SaiMetJou

 

Comment s’assurer de l’unicité de l’identité ?

Dans le référentiel généré, la colonne “id U” contient un point d’interrogation en rouge lorsque plusieurs objets ont la même identité. Il est dans ce cas souhaitable de corriger manuellement l’identité (conformément aux règles de nommage de préférence).

GRAF–Outillage pour les nuls / générer le référentiel sous Excel

Créer  l’arborescence

Pour générer le référentiel, nous devons d’abord créer une arborescence de travail, qui contient les outils à la racine.

Une telle arborescence est fournie sur l’exemple de l’agence de voyage et est téléchargeable sur le site KM 2.0 de Capgemini. (Fichier Arborescence Cali_Voyage V3.2.zip)

Dans le répertoire “vsd” nous plaçons le fichier contenant notre schéma :

Commandes V1.0.vsd

Ce fichier contient l’onglet “Commandes” qui contient le schéma.

Paramétrer l’arborescence

Il faut ensuite paramétrer la liste des onglets analysés par l’outil. Pour cela on édite le fichier “schémas.csv” du répertoire “param”.

• des : numéro de dessin
• fichier : nom du fichier Visio
• onglet : nom de l’onglet
• nom : nom détaillé du schéma
• court : nom abrégé du schéma (permet de faire des filtres dans le référentiel généré)

Générer l’extraction brute

On lance ensuite le fichier visio GRAFEXTRACTOR qui est à la racine de l’arborescence

GRAFEXTRACTOR produit dans le répertoire “xgl” des fichiers d’analyse des schémas

• un fichier xx.xgl par schéma analysé
• un fichier elem.csv qui contient la description des systèmes, sous-systèmes, modules et composants
• un fichier flux.csv qui contient la description des flux

Mettre en forme le référentiel sous Excel

Pour mettre en forme les résultats, on lance alors le fichier Excel  GRAFlux qui est également à la racine de l’arborescence, puis on exécute la macro GRAFllux

GRAFlux génère alors un fichier Excel dans le répertoire “flux” qui contient les composants (onglet “elem”) et les flux (onglet “flux”)

Ci dessous un extrait de l’onglet “elem” contenant l’arborescence des composants

GRAF–Outillage pour les nuls / préparer la génération documentaire avec les propriétés

 

La génération du Dossier d’architecture logique construit un document qui contient :

• La hiérarchie des systèmes, sous-systèmes, modules et composants
• pour chaque composant, ses interfaces (flux entrants et sortants du composant)

Cette description peut être enrichi avec le contenu des propriétés des différents objets dans le schéma.

Prenons notre exemple de la gestion des commandes :

Objet 1 : les propriétés “commentaire” et “documentation” enrichissent la description du module

Objet 2 : la propriété “désignation” indique la nature du flux. Il s’agit ici d’une écriture en base de données. Une désignation doit être précédé d’un article (la, le) et d’une apostrophe si nécessaire pour générer une élision.

la propriété “objets” liste les objets métier véhiculés par le flux

la propriété “protocole” décrit le protocole de communication utilisé par le flux

 

 

 

 

 

 

 

Objet 3 : la propriété “retour” contient la valeur de retour de l’invocation synchrone

GRAF–Outillage pour les nuls / saisir une propriété

 

Lançons VISIO pour réaliser un premier schéma très simple.

Avant de dessiner le schéma, s’assurer que le dock de la configuration VISIO contient :

• Les icones de l’architecture logique
• Les icônes des flux logiques
• la fenêtre qui affiche les propriété des objets, dans laquelle les propriété GRAF pourront être renseignées

 

Ces fenêtres sont accessibles depuis le menu “Affichage” de visio

 

 

 

 

 

 

 

 

 

Réalisons un premier schéma d’un système qui permet à un commercial de prendre une commande en utilisant un ERP (SAP par exemple).

 

Première remarque : si les sous-systèmes et les modules ont un nom, les flux n’en ont pas, ce qui pourrait être gênant pour la génération documentaire

Ajouter les noms systématiquement sur le schéma peut par ailleurs l’alourdir.

On choisira dans ce cas de saisir le nom sur la propriété “GRAF_dénomination” des flux

En cliquant sur le flux, la fenêtre des données de forme est rafraîchie et on peut saisir le nom du flux

 

Ici, nous sélectionnons la deuxième flèche bleue et nous saisissons la propriété GRAF_dénomination

 

 

Il peut être intéressant pour la suite de nommer un flux synchrone par la raison qui motive ce flux, et un flux de données par les données qu’il transporte.Il y a d’autres solutions mais celle-ci est en accord avec notre stratégie de génération documentaire. Nous verrons pourquoi un peu plus tard.

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

Les performances dépendent pas seulement de la consommation en CPU. Elle sont également dûes au débit aux termes d’entrées-sorties. 

Ce débit peut également être mesurée avec l’utilitaires NMON puis être extrapolé avec le VAT de GRAF.

Lorsque l’on effectue la mesure d’un traitement, on comptabilise le nombre d’IO générées lors de l’exécution du traitement, que l’on divise ensuite par le nombre d’objet traités.

Dans le fichier NMON

1. On crée une variable M_IO  qui contient toutes les valeurs de la colonne  IO/sec de l’onglet DISK_SUM du fichier NMON.
2. On crée une variable M_Heure_IO qui contient toutes les dates de l’onglet DISK_SUMM.
3. On rajoute l’onglet « Mesure » qui contient les valeurs suivantes (On a dans cet exemple effectué 2 mesures sur un batch de facturation) :

Batch	Output	Unité O	Début	Durée	Fin	IO brut	IO	IO par output
Facturation	179	Postes	28/11/2014 13:15:52	43,157	28-11/2014 13:16:35	26368,6	25867,8673	144,5132252
Facturation	179	Postes	28/11/2014 13:28:52	62,79	28-11/2014 13:29:55	50046,2	49545,4673	276,7903201

Le nombre d’IO brut est fourni par la formule matricielle :

{SOMME(M_IO*SI(M_Heure_IO>=[Début];1;0)*SI(M_Heure_IO<=[Fin] ;1;0))}

Pour éliminer le « bruit » de fond, on calcule un nombre d’IO « net » :

[IO Brut] - MOYENNE(M_IO)

Puis on divise par le nombre d’objets métiers analysés au cours du traitement, soit dans l’exemple un nombre d’IO moyen par ligne de facture égal à 211.

Dans le VAT

Les plages, les serveurs, les composants et les macroflux ayant été renseignés comme dans l’article http://vincentlacroixgraf.blogspot.fr/2014/12/graf-anticiper-de-la-charge-dun-systeme.html, il nous reste à compléter l’onglet « traitements » en remplissant pour chaque traitement considéré, la colonne « SAN ». avec le nombre d'IO moyen par objet métier mesuré.

On actualise les données de l’onglet « X_SAN_t », puis on affiche le graphique de l’onglet « G_SAN_t ».

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

Afin de pouvoir simuler la charge d’un système d’information avec la méthode décrite dans l’article précédent (Cf  http://vincentlacroixgraf.blogspot.fr/2014/12/graf-anticiper-de-la-charge-dun-systeme.html), il faut être en mesure de mesurer la consommation CPU unitaire moyenne des différents traitements.

Pour cela il est nécessaire de :

1. Choisir les objets métiers représentatifs des flux à mesurer.
2. Préparer l’échantillon, en notant le nombre d’objets métier utilisés dans l’échantillon
3. Choisir l’outil de mesure.
4. Être capable de noter l’heure de début et la durée du traitement de l’échantillon.

Les objets métier représentatifs

Afin d’obtenir une mesure représentant  fidèlement la moyenne, il est préférable de choisir des objets « atomiques », pour lesquels la charge traitement varie peu d’un objet à l’autre. Par exemple, on choisira de préférence la « ligne de facture » plutôt que la facture elle-même, car cette dernière peut contenir un nombre de lignes très variable.

Il faut ensuite, dans l’étude de volumétrie, être en mesure de dénombrer le nombre d’objets métier qui devront être traités à la cible (Cf. l’article précédent sur l’utilisation du VAT).

Préparer l’échantillon

Comme dans les sondages d’opinion, plus la quantité d’objets métier est importante, plus la mesure de la moyenne est fiable. Le nombre minimal d’objets que l’échantillon doit contenir tourne autour de la cinquantaine.

Choisir l’outil de mesure

Suivant l’application considérée, on pourra utiliser :

un outil de monitoring système tel que NMON (LINUX) ou Perfmon (Windows)

un outil de monitoring applicatif comme Solution Manager de SAP (Transaction ST03)

Exemple

Dans notre exemple, nous allons utiliser NMON, qui mesure l’activité des CPU vue par le système d’exploitation. Il faut pour cela effectuer le test de mesure sur un environnement « silencieux », c'est-à-dire qui est dédié à la mesure au moment du test. Par exemple on réservera un environnement de recette ou de développement pendant la durée de la mesure.

NNOM construit un fichier Excel avec plusieurs onglets. l’onglet intéressant est l’onglet CPU_ALL, qui contient, pour chaque période de temps, le pourcentage moyen d’occupation des CPU.

NMON peut être paramétré de façon à ce qu’une période de temps ait une durée d’une seconde. 1% d’occupation est alors équivalent à une charge d’un centième de seconde sur le CPU.

Rappelons que dans la méthode d’utilisation du VAT présentée dans l’article précédent, on utilise la milliseconde comme unité de consommation CPU.

L’obtention, pour chaque seconde de temps de la charge consommée sur l’ensemble des CPU en milisecondes est fournie par :

%occupation_CPU * 10 * Nombre_CPU

Dans le fichier NMON :

1. On crée une variable M_CPU qui contient toutes les valeurs de la colonne CPU% de l’onglet CPU_ALL du fichier NMON.
2. On crée une variable M_Heure qui contient toutes les dates de l’onglet CPU_ALL.
3. On rajoute l’onglet « Mesure » qui contient les valeurs suivantes (On a dans cet exemple effectué 2 mesures sur un batch de facturation) :

Batch	Output	Unité O	Début	Durée	Fin	Pourcentage CPU	Consommation CPU
Facturation	179	Lignes facture	28/11/2014 13:15:52	43,157	28-11/2014 13:16:35	123	14734,41379
Facturation	179	Lignes facture	28/11/2014 13:28:52	62,79	28-11/2014 13:29:55	117	14014,41379

Le pourcentage d’occupation CPU est calculé par la formule matricielle :

={SOMME(M_CPU*SI(M_Heure>=[Début];1;0)*SI(M_Heure<=[Fin];1;0))}

La mesure unitaire de l’occupation CPU pour le traitement d’une ligne de facture est finalement fournie par la formule :

=[Pourcentage CPU]*10*Nombre_CPU/[Output]

On obtient 82 millisecondes de traitement pour une ligne de facture dans la première mesure, et 78 dans la seconde.