Etape 1 : Construction du modèle générique de connaissance

connaissance qui sera le résultat des deux premières actions menées dans ASCI à savoir l’analyse et la spécification. Celui-ci pourra dès lors être instancié sur tout système du domaine.

4.2.1.1 L’analyse fonctionnelle et structurelle

Le but de cette première action est de formaliser le domaine sous une forme graphique ou syntaxique. Ici les différents experts du domaine et de la modélisation travaillent de concert pour comprendre le domaine et identifier les différentes entités qui le composent, leurs fonctions ainsi que leurs associations. De plus, c’est à ce niveau que les objectifs de l’étude et les contraintes à respecter sont énoncés. Cette « analyse » donne donc une vue « statique » du domaine, celle-ci pouvant être issue, si nécessaire, de la décomposition du système en trois sous-systèmes

ANALYSE, SPECIFICATION, CONCEPTION ET IMPLEMENTATION 111

interdépendants permettant dès lors de faciliter la formalisation de la connaissance. Ces trois sous- systèmes seront présentés en partie 4.2.1.3.

4.2.1.2 La Spécification des entités et de leur fonctionnement

Cette seconde action consiste à exprimer le fonctionnement des systèmes du domaine, des flux présents dans le domaine et ainsi venir à les structurer. Il sera notamment fait cas du système de pilotage, ce dernier devant être décrit de manière précise afin de structurer et prendre en compte de nombreux éléments tels que les règles de gestion tout particulièrement mais aussi les règles de fonctionnement. C’est aussi ici que le format des données d’entrée devra être spécifié, toutes ces différentes tâches devant permettre aux experts (du domaine et en modélisation) de s’accorder sur le fonctionnement (réel ou désiré) du domaine.

4.2.1.3 Décomposition systémique des systèmes du domaine

Afin de pouvoir appréhender de manière plus aisée le domaine dans des cas où la formalisation se révélera délicate, il est utilisé une décomposition systémique dans ASCI. Comme déjà énoncé précédemment, celle-ci se caractérise par la création et l’utilisation de trois sous- systèmes interdépendants qui sont un sous-système logique, un physique et un dernier décisionnel.

[RODIER 10] énonce parfaitement les interdépendances (Figure 4.4) entre ces trois entités que nous allons présenter un peu plus en détails :

 Sous-système logique : aussi noté SSL, ce premier sous-système est constitué des nombreuses entités que le système doit traiter, de l’ensemble des opérations (élémentaires) concernant les flux, ainsi que des entrées dans le système qui s’y rapportent ;

 Sous-système physique : ou SSP, celui-ci est composé de l’ensemble des moyens, des entités physiques (actives ou passives) nécessaires à la réalisation des services élémentaires. Il contient de plus leur répartition géographique ainsi que les interconnexions existantes entre eux ;

 Sous-système décisionnel : Ce dernier aussi appelé sous-système de gestion est structuré en centre de gestion. Il recense donc l’ensemble des règles de gestion, d’allocation des ressources. De surcroît il permet de spécifier l’ensemble des règles de fonctionnement du système et les lois régissant le pilotage du système. Il est identifié sous le nom de SSD. Ce sous-système tient un rôle central, étant donné qu’il gère les interactions entre les 2 autres sous-systèmes. Il a pour rôle entre autres de :

 Réceptionner les informations du SSP et SSL ;  Régir les comportements du SSL ;

 Régir les actions du SSP.

Bien que la structure interne des sous-systèmes soit généralement hiérarchique, le SSD peut quant à lui posséder d’autres types de structures, telles que centralisée, décentralisée ou encore coopérative (et même des combinaisons de celles-ci). Ce cas particulier s’explique par le fait que le SSD est souvent le représentant de la complexité du système étudié.

112 Chapitre 4 : ASCI & BPMN

Sur la Figure 4.4, il est bien mis en évidence que c’est le SSD qui assure le regroupement des informations, et définit donc les actions du SSP et SSL. Ces deux derniers communiquant principalement entre eux à travers l’activité, composante du SSL qui mobilise les ressources du SSP.

Figure 4.4 : Interactions entre les sous-systèmes d’ASCI

A noter qu’une telle décomposition a bien sûr été utilisée dans les références citées en début de chapitre. A ces deux-là, il est possible de rajouter [COMBES 94] (orienté hôpital) et [GOUJON 97] (orienté système industriel).

A travers les différents travaux réalisés, l’analyse et la spécification ont été menées avec divers langages ou méthodes. Pour l’analyse, on pourra citer les diagrammes entités/relations, le diagramme des classes d’UML, quant à la spécification, il a été utilisé SADT, les RdP, mais encore le diagramme d’activité d’UML.

Maintenant que les deux premières actions menées dans ASCI ont été présentées, penchons- nous sur le résultat de celle-ci, à savoir le modèle de connaissance.

4.2.1.4 Le modèle générique de connaissance

Devant rester cohérent avec le domaine, quelles que soit les modifications et évolutions que celui-ci subira, le modèle générique de connaissance décrit la structure et le fonctionnement du domaine dans un langage naturel, formel ou graphique. La construction de ce modèle consiste en la récolte et la formalisation de la connaissance du domaine étudié, en se servant d’outils et de méthodes adaptés à cette démarche et aux experts du domaine.

A noter qu’un modèle de connaissance instancié (appliqué à un système du domaine) ne comportera pas nécessairement le même type d’informations suivant que celui-ci est la représentation d’un système existant (modèle a posteriori) ou la représentation d’un système en devenir (modèle a priori). En effet dans le premier cas, le modèle contiendra la connaissance acquise

ANALYSE, SPECIFICATION, CONCEPTION ET IMPLEMENTATION 113

après l’observation du système tandis que dans le second il contiendra les spécifications du futur système.

Le modèle générique de connaissance obtenu, son instanciation sur un système du domaine, permet d’en obtenir un modèle de connaissance, et il est alors possible de passer à l’étape 2 du processus de modélisation.