Aller au contenu. | Aller à la navigation

Outils personnels

Navigation

Vous êtes ici : Accueil / Articles / MACoP (Modeling and Analysis of Collaborative Portal): Le fond

MACoP (Modeling and Analysis of Collaborative Portal): Le fond

Par Amen Souissi publié 15/02/2010 21:55, Dernière modification 06/04/2010 18:10
Aujourd’hui, les entreprises doivent impérativement collaborer de façon précise et rapide afin d’intervenir dans un projet. Cette collaboration est devenue un avantage certain face à la concurrence, qu’elle soit locale ou non. D'un autre coté, les entreprises ont besoin d’une nouvelle génération de plateforme interactive permettant un rapprochement des utilisateurs et un partage efficace des ressources, des services et de la connaissance. Le portail collaboratif est la réponse à ce besoin et constitue la porte d’entrée unique, personnalisée, interactive et sécurisée d’une entreprise vers ses informations et ses applications.

I. Introduction

Aujourd’hui, les entreprises doivent impérativement collaborer de façon précise et rapide afin d’intervenir dans un projet. Cette collaboration est devenue un avantage certain face à la concurrence, qu’elle soit locale ou non.

D'un autre coté, les entreprises ont besoin d’une nouvelle génération des plateformes interactives permettant un rapprochement des utilisateurs et un partage efficace des ressources, des services et de la connaissance.

Le portail collaboratif est la réponse à ce besoin et constitue la porte d’entrée unique, personnalisée, interactive et sécurisée d’une entreprise vers ses informations et ses applications.

Le portail collaboratif regroupe 4 grands périmètres fonctionnels ; La gestion de la connaissance, Espace collaboratif métier, Plateforme communautaire et la Publication.

Je pense que les données associées à chaque périmètre existent dans l'entreprise et dans les besoins de l'entreprise et plus précisément dans son système d'information.

D'une manière abstraite, en connaissant le système d'information on veut générer la partie virtuelle du système informatique . Cela va permettre d'adapter le système informatique aux changements du système d'information . Avec cette vision, le système informatique devient dynamique.

Dans le cadre de mes travaux, cette vision est restreinte à la génération des portails collaboratifs qui font partie du système informatique, d'une entreprise ou d'une collaboration. Dans notre contexte un système d'information collaboratif est vu comme un système d'information permettant une collaboration interne ou externe.

A partir d'un modèle décrivant un portail collaboratif basé sur la modélisation des systèmes d'information on veut générer le portail collaboratif associé [*].

MACoP (Modeling and Analysis of Collaborative Portal) est un méta-modèle en cours de définition et qui va permettre de modéliser les portails collaboratifs en se basant sur la modélisation des systèmes d'informations des entreprises. Ce méta-modèle est composé de deux parties essentielles qui sont le fond qui décrit les objets de la collaboration, les acteurs avec leurs rôles sans oublier les processus métiers, et, la forme qui décrit la structure visuelle du portail collaboratif.

Dans ce document, je vais commencer par positionner mes travaux par rapport à ce qui existe dans la communauté de recherche dans le domaine du génie industriel. Pour le faire, je vais donner un petit aperçu sur la modélisation d'entreprise comme base pour la modélisation des systèmes d'informations , ensuite je vais détailler les concepts clef du méta-modèle MACoP .

 

II. Modélisation d'entreprise comme base pour la modélisation des systèmes d'information:

 

II.1 Modélisation des systèmes d'informations:

 

Il existe de nombreuses approches méthodologiques pour la modélisation des systèmes d'informations. Rolande Marcinak et Frantz Rowe [1] proposent 3 approches: les méthodes fonctionnelles fondées sur un principe de décomposition modulaire de système et des hiérarchies de représentation. Les méthodes systémiques: sont apparues dans les années 1975-1980. Ces méthodes appréhendent de manière plus globale la modélisation des Systèmes d’information et introduisent la multiplicité des points de vue, je cite par exemple MERISE.

Et enfin les méthodes objets datent de la même époque. Dans mes travaux je me suis intéressé à certains cadres de référence associés à ces méthodes pour les avantages qu'elles offrent et ces alignements par rapport à mes travaux de recherches. La modélisation et la méta-modélisation en font partie.

L’entreprise a, aujourd’hui, de fortes incitations à structurer son organisation autour de processus, définis aussi clairement que possible, mais surtout formalisés et autour desquels les différents métiers communiquent.

Il y a plusieurs courants de travaux scientifiques qui accompagnent cette forme de structuration et des langages de modélisation, souvent graphiques, sont proposés pour obtenir une représentation formelle. La modélisation d’entreprise est certainement l’une des formes les plus accomplies.

Dans mes travaux, la modélisation de l'entreprise est prise comme base pour la modélisation des systèmes d'information. En effet la modélisation de l'entreprise permet de concevoir le système d'information. On peut donc passer de l'espace des modèle des entreprise à l'espace des modèles des système d'information [11].

 

II.2 Modélisation des entreprises:

 

Un méta-modèle est un langage formel ou semi-formel permettant de modéliser des systèmes particuliers, à savoir des modèles . Le méta modèle est devenu un point d’entrée obligatoire pour la modélisation d’entreprise. En effet, il permet de dresser une liste, à un niveau générique, des éléments qui seront utilisés dans la représentation sous une forme plus instanciée (particularisée).

Dans la littérature on trouve plusieurs normes de modélisation d’entreprise. Un travail de recherche effectué par David Chen et François Vernadat [2] a été réalisé pour lister ces normes.

J'ai porté mon attention sur les travaux de synthèse relatifs à un langage pour la modélisation de l’entreprise avec la norme ENV 40003 [3] et précisément à la notion de vue de modélisation.

Un point de vue de modélisation, comme son nom l’indique, est une perception particulière de l’entreprise qui met en évidence certains aspects et rend transparents les autres. C’est donc une perspective particulière pour représenter, puis observer, une même entreprise au moyen du modèle.

La norme ENV 40003 reconnaît quatre points de vue :

    • la vue fonctionnelle qui fournit une représentation hiérarchisée des fonctions, des flux de l’entreprise grâce aux entrées et sorties de chaque fonction, ainsi que la logique d’enchaînement de celles-ci dans le temps ;

    • la vue informationnelle qui fournit une représentation structurée d’un ensemble d’entités de l’entreprise, qui sont définies par des informations et des relations de dépendance entre ces informations ;

    • la vue des ressources qui fournit une représentation de l’organisation des ressources de l’entreprise, c’est à dire de l’ensemble des moyens nécessaires pour mettre en œuvre les activités ;

    • la vue de l’organisation qui fournit une représentation de l’organisation structurelle de l’entreprise : les responsabilités des individus et les unités de service au sein de l’entreprise.

Parmi les cadres de modélisation d'entreprise qui adoptent ces vues, et qui ont porté mon attention, je site CIMOSA [4] stands for "Computer Integrated Manufacturing Open System Architecture", which aims to support the enterprise integration of machines, computers and people. UEML[5] qui est le fruit d’un programme de collaboration à l’échelle européenne qui a pour objectif de définir une interface standardisée entre les outils de la modélisation d’entreprise basés sur des modèles différents. Ce travail conduira in fine à un certain degré de compatibilité entre les outils.

La philosophie de MACoP consiste à métamodèliser les portails collaboratif en ce basant sur les notions du système d'information en couvrant le point de vue fonctionnel pour les processus métiers, le point de vue informationnel pour les objets de la collaboration et le point de vue de ressource pour les rôles des acteurs de la collaboration. Le point de vue organisationnel n'est pas couvert puisque il ne donne aucune information sur la conception du portail collaboratif. Sachant que le but principal de mes travaux n'est pas la modélisation de l'entreprise ou du système d'information. Je me suis inspiré de ce qui a été fait déjà dans le méta-modèle de CIMOSA et celui de UEML.

Dans ce qui suit je vais détailler les concepts de MACoP en détaillant chaque point de vue.

 

II. MACoP :

MACoP va permettre de modéliser les portails collaboratifs à un haut niveau d'abstraction. Cette modélisation est plus basé sur les concepts des systèmes d'information que sur les concepts du web, en effet je pense que les détails techniques et les concepts web peuvent être rajouté automatiquement au modèle initial en appliquant des transformations qui vont plus jouer le rôle d'expert que d'une simple transformation un à un. Ces transformations vont capter l'expertise et les connaissances de maître d'œuvre et des développeurs web.

Le modèle initial ne présente, donc, que les besoins de l'utilisateur et le cahier de charge de l'application.

 

II.1 Le fond:

Dans ce modèle l'utilisateur doit décrire ses besoins informationnels (les données à manipuler et les acteurs; «le quoi? » ),les ressources (les rôles qui vont agir sur les données de l'application; « le qui? »), les besoin fonctionnels (qui décrivent les processus métier; « le comment ? »).

Je pense que, répondre à ces trois questions (le quoi? Le qui? Et le comment?) suffit pour capter tous les besoins nécessaires pour le développement d'un portail collaboratif.

 

  II.1.1 Vue informationnelle:

Dans cette vue l'utilisateur est ramené à modéliser les informations et les données qui vont être manipulées sur le portail collaboratif. Il existe deux niveaux de modélisation; le premier niveau consiste à modéliser les types des objets et les relations entre eux. Le deuxième niveau consiste à modéliser les instances qui vont permettre de spécifier l'arborescence du portail et sa structure d'une manière générale.

  Les types:

ObjectOfCollaboration: Tout est objet de collaboration. Un objet de collaboration a des attributs qui le caractérisent, comme par exemple le nom de l'objet, la description … Des contraintes peuvent être posées sur ces attributs, comme par exemple ; le nom doit avoir au minimum 6 lettres...

Information: Une information est un objet de collaboration. Au niveau sémantique, une information peut contenir ou référencer d'autres objets de collaboration . Une Information peut être privée par rapport à la collaboration ou non ce qui permet d'avoir deux niveaux de privatisation. Le premier niveau est défini au niveau de l'information. Ce niveau permet de spécifier si l'objet rentre dans le cadre de la publication de la collaboration ou non . Le deuxième niveau est défini au niveau des processus métier. L'information devient publique pour ceux qui sont authentifiés seulement. En effet une Information peut être soit un objet qui ne peut pas être vu par le publique, comme une facture par exemple. Ou un objet qui peut être vu par le publique, comme un dossier ou un document de publication de produit.

Actor: Un Actor est un objet de collaboration, et il peut être une machine ou un humain. Un Actor est une présentation informatique d'un acteur physique dans la collaboration. Dans un autre point de vue l'Actor peut être considéré comme un profile.

Il existe des relations entre les ObjectOfCollaboration . Dans MACoP on a identifié deux types de relation:

Information-Information: C'est une relation de conteneur - contenue. Cette relation peut avoir des contraintes structurelles (référencement ou contenance, nombre des objets contenus).

Information-Actor : C'est une relation de référencement qui peut être attachée à un rôle ou non. Dans le cas où elle n'est pas attachée à un rôle cela signifie qu'il y a un simple référencement. Dans le deuxième cas, un nouveau rôle est ajouté à l'acteur référencé. Par exemple un document a des contributeurs, et seulement les contributeurs de ce document ont le droit de le modifier.

On peut avoir des contraintes sur cette relation aussi, comme par exemple; les contributeurs doivent avoir l'age supérieur à 18 ans...

Sur la figure suivante je présente un exemple de modélisation des types avec un acteur Humain.

 

 

Dans notre exemple l'application est composée de deux rubriques. Chaque rubrique est composée de dossiers et chaque dossier est composé de documents.

Le fait de spécifier qu'on a deux rubriques dans notre application oblige l'utilisateur d'instancier ces deux rubriques. Dans le cas contraire les rubriques sont spécifiées automatiquement. En plus de l'obligation de l'istanciation cette contrainte signifie que personne n'a le droit d'ajouter ou de supprimer des rubriques dans l'application. En effet la spécification de la multiplicité de la relation est une contrainte structurelle qui doit être respectée.

Sur cette exemple on trouve les deux types de relation entre les Objets de collaboration (Actor et Information).

  Les Instances:

InstanceSpecification: Est une instance d'un Objet de collaboration. On spécifie les instances pour définir une instance de l'application. Quand l'instance est nommée on parle d'une instance bien définie, dans le cas contraire l'instance se référence à n'importe quelle instance de même type.

Pour notre exemple, au niveau instance, on a créé une instance de notre application. On a créé les instances des deux rubriques, les rubriques Filmes et Musiques. On a spécifié une instance de Rubrique sans nom pour référencer tous les rubriques. Dans notre exemple toutes les rubriques de l'application possèdent un dossier nommé Événements. Et tous les dossiers de l'application possèdent un document appelé Charte, ce qui signifie qu'à chaque construction d'un dossier dans l'application on construit le document charte dans ce dossier.

On a donc une application composée de deux rubriques Filmes et Musique, dans chaque rubrique on a un dossier Événement et enfin dans chaque dossier on a un document Charte.

 


instances

 

On obtiens donc l'arborescence suivante:

 

tree

ActorInstance: ActorInstance est une instance d'un Actor qui peut avoir des rôles. ActorInstance présente une personne particulière ou un ensemble de personnes dans le cas où le nom de l'instance n'est pas spécifiée. On peut spécifier, par exemple, une ActorInstance pour une personne nommée Toto , on peut ensuite lui attribuer des rôles.

Le fait de spécifier les ActorInstance va permettre de générer des profiles avec leurs rôles d'une manière automatique .

  Les services :

Un service est une application sous forme d'IP. Comme par exemple un service Mail ou un moteur de recherche. En effet un service mail est une application qui peut être modélisé avec MACoP, mais selon l'utilisateur, la manipulation de mail peut être vue comme un service ou comme une application qui fait partie de son métier.

L'utilisateur peut donc modéliser son application puis générer le service associé à cette application pour le réutiliser dans une autre application.

II.1.2 Vue des ressources:

Une fois les données (Objet de collaboration et leurs instance) sont modélisées et l'arborescence est spécifiée, l'utilisateur est ramené à modéliser les rôles de la collaboration.

  Les Rôles:

C’est le concept clef concernant l’organisation des individus. A un Rôle est attaché un ensemble de tâches confiées à une personne dans le cadre d’une responsabilité, d’une délégation, d’une charge, en fonction d’une qualification ou de compétences. C’est la « fonction » professionnelle de cet individu. Chaque Rôle est rempli par un Acteur (une personne donnée). Plusieurs personnes peuvent tenir le même Rôle. Et une personne peut avoir plusieurs Rôles .

Un rôle peut hériter d'un autre rôle. Et il peut être abstrait pour permettre l'héritage d'un ensemble de tâches confiées.

  Les Groupes:

Dans certains cas une personne doit posséder plusieurs rôles pour pouvoir effectuer un ensemble de tâches. Le concept de Groupe va permettre de regrouper ces rôles.

Un groupe est lui même un rôle puisque on peut lui affecter un ensemble de tâches.

 

  II.1.3 Vue fonctionnelle :

Une foi les données et les rôles sont modélisées l'utilisateur est ramené à spécifier les processus métiers [13,15] qui vont permettre de dire comment les données sont manipulées par les acteurs. Vue l'approche basée sur la modélisation des systèmes d'informations qu'on a adopté, j'ai écarté l' utilisation du diagramme d'activité d'UML, vue qu'il n'est pas fait pour modéliser les processus métier. Pour modéliser ce coté de l'application, j'ai choisi d'utiliser le BPMN 2.0 [12,14] qui est standardisé par l'OMG. En effet plusieurs études montrent que BPMN a une présentation plus puissante et plus abstraite, pour les processus métier, que le diagramme d'activité d'UML. Parmi ces travaux je cite celui de Eloranta, Kallio, Terho [9], que je trouvent le plus concluent. Ce travail présente une étude comparative entre le diagramme d'activité d'UML et le BPMN 1.1. Je peux citer aussi les travaux de Ondrej Macek et Karel Richta [10] qui ont proposé une transformation de BPMN vers le diagramme d'activité d'UML et qui ont rencontrés des problèmes dus à la richesse de BPMN par rapport au diagramme d'activité d'UML .

Malgré la puissance de présentation du BPMN, il reste incomplet pour permettre la génération de code. On a donc ajouté d'autres notions au metamodel pour combler cette faille.

  Domaine et processus domaine:

D'une manière générale une entreprise a des domaines d'activité. Pour chaque domaine il y a des processus domaine et enfin pour chaque processus domaine il y a un ensemble de personnes qui effectuent des actions bien définies selon leurs rôles (voir figure suivante).

Roles

Dans MACoP un Pool présente un processus domaine et un Lane présente un rôle.

 


BPMN

 

  IP (Intellectual Property):

Une activité (action ou événement) peut être implémentée par un, ou plusieurs « IP (Intellectual Property)» (un composant!), qu'on peut trouver sur étagère pour permettre la réutilisabilité, connectées les un avec les autres et/ou connectées avec les données de l'application . On peut avoir des IP qui permetent d'ajouter un événement sur Google Agenda ou consulter une base de données.(Voire figure suivante)

Un paramètre d'IP (Un port) peut être soit connecté aux données de l'application (en lecture « Port en bleu » ou en écriture « Port en vert ») soit non (en lecture « Port en gris» ou en écriture « Port en noir »). Et dans ce dernier cas, le paramètre peut être un paramètre de configuration (c'est à dire qu'il faut spécifier sa valeur au niveau du modèle « Port en orange »).On trouve aussi des paramètres connectés les uns avec les autres (en lecture « Port en rouge» ou en écriture « Port en jaune »).

 

IP

 

 

Chaque processus domaine contient des données pertinentes et des données de contrôle [15]. Dans MACoP ces données sont des InstanceSpecification attachées directement à ces processus et des ActorInstance attachées au Lan, pour pouvoir récupérer les données associées aux acteurs du processus. Chaque action de ce processus peut récupérer ces données et les manipuler à travers ses IP. On va pouvoir, par exemple, connecter un port d'un IP à l'adresse mail d'une personne qui a joué un rôle bien défini dans un processus domaine. Ou on peut le connecter à un attribut d'une instance d'un document produit par ce processus ou autre.

   Contexte:

Une action (Task) dans un processus métier peut avoir plusieurs contextes de types différents. En effet il y a les données associées au processus et il y a le contexte de manipulation de ces données. Un contexte est l'ensemble des conditions, structurelles (à travers la spécification de l'information manipulée (ses états sa multiplicité...)), ou directes (à travers un langage de contrainte comme OCL[16]) sous lesquelles l'action est en train d'être activée. On pense que ces données peuvent être manipulées suivant trois contextes :

  1. Contexte d'action: Ce contexte permet de spécifier sur quoi l'action est effectuée. Dans ce contexte on référence une instance appartenant à un processus domaine, les attributs de cette instance qui sont manipulés directement par l'utilisateur (En effet il existe des données manipulées par les IP de l'action mais qui ne sont pas manipulées par l'acteur), les états de cette instance et, enfin, la multiplicité pour spécifier le nombre d'instances nécessaires pour cette action. Si l'instance est nommée alors le contexte référence une instance bien précise (produite par un processus bien précis ). Sinon le contexte référence n'importe quelle instance de même type.
  2. Contexte d'étude: Ce contexte permet de spécifier ce qu'il faut étudier avant d'effectuer l'action. En effet avant d'effectuer une action, un acteur est ramené à faire une étude sur des objets de la collaboration. Au contraire du contexte d'action, la multiplicité n'a aucun sens, dans ce contexte les autres aspects gardent la même signification.
  3. Contexte de production:  Ce contexte permet de spécifier ce que l'action produit.
 

II.2. La forme:

Cette partie va permettre à l'utilisateur de modéliser la structure visuelle de son portail d'une manière indépendante du fond. La forme présente l'interface entre le fond et l'utilisateur réel. Elle décrit ou et comment présenter un Objet de collaboration et son interface de manipulation.

Le metamodèle associé à la forme sera détaillé ultérieurement.

 

Conclusion:

Pour pouvoir modéliser des portails collaboratifs sans rentrer dans la complexité des aspects techniques et technologiques du web on a choisi de se baser sur la modélisation des systèmes d'informations centrée sur les processus métier tout en gardant les avantages de la méthode de modélisation d'UML pour la vue informationnelle et la vue des ressources. Cette approche nous à permis de répondre à trois questions qui sont « quoi? », « qui? » et « comment? ». La réponse au quoi? est présente dans MACoP comme une modélisation de tous qui peut être manipulé dans la collaboration (Vue informationnelle d'un système d'information). La réponse au qui? est présente dans MACoP comme une modélisation des rôles et leur hiérarchie dans la collaboration (Vue des ressources d'un système d'information). Et enfin La réponse au comment? est présente dans MACoP comme une modélisation des processus métiers permettant ainsi d'établir les relations entre les rôles et les données de l'application (Vue fonctionnelle d'un système d'information).

 

Bibliographie:

 

[1] Systèmes d’information, dynamique et organisation. PIQ. Economica.

[2] Standardisation on enterprise modelling and integration : Achievements, on-going works and future perspectives. In Proceeding of IFAC 10th Symposium on Information Control in Manufacturing, Vienna. INCOM.

[3] Enterprise Integration - Framework for Enterprise Modelling. CEN, Comité Européen de Normalisation.

[4] http://www.cimosa.de/

[5] The Unified Enterprise Modelling Language – Overview and Further Work : Victor Anaya, Giuseppe Berio, Mounira Harzallah, Patrick Heymans, Raimundas Matulevicius, Andreas L. Opdahl, Hervé Panetto, Maria Jose Verdecho.

[6] Proposition d’un cadre de référence pour la conception et l’exploitation d’un progiciel de gestion intégré . Franck Darras , PhD thesis.

[7] UML2 Pour l'analyse d'un système d'information, C.Morley, J.Hugues et B.Leblanc

[8] La méthode OSSAD Pour maîtriser les technologies de l’information .Tome 1 : Principes

[9] A Notation Evaluation of BPMN and UML Activity Diagrams : Eloranta, Kallio, Terho (2006)

[10] The BPM to UML activity diagram transformation using XSLT : Ondrej Mace and Karel Richta

[11] Jihed TOUZI. Aide à la conception de Système d'Information Collaboratif support de l'interopérabilité des entreprises , PhD thesis.

[12] Business Process Model and Notation (BPMN) FTF Beta 1 for Version 2.0: OMG

[13] Introduction au BPM: Stéphane PLANQUART

[14] Introduction to BPMN : Stephen A. White, IBM Corporation

[15] Les processus métiers concepts, modèles et systèmes: IC2 Traité informatique et système d'inforation Sous la direction de Claude Godart et Olivier Perrin.

[16] http://www.uml.org/ UML 2.0 Object Constraint Language (OCL) Object Management Group