A SPECTS DYNAMIQUES DANS UN S

Les modèles dynamiques ont pour objectif de décrire les règles d’évolution des objets au cours du temps. Ils représentent les types d’évènements qui surviennent dans le SI et les changements d’états résultant du traitement de ces événements. L’état d’un objet d’une classe évolue suite à l’exécution d’opérations (création, suppression, mise-à-jour) ou de méthodes de classes.

« Dans les méthodes objets, la dynamique des objets est décrite soit à l’aide de diagrammes d’états/transitions (dérivés des machines d’états finis), soit à l’aide de spécifications formelles utilisant des langages de règles ou d’autres langages abstraits » (Bouzeghoub & al. 1997)89. Les formalismes les plus utilisés pour les modèles dynamiques restent les diagrammes d’état-transition d’UML (Annexe H) ou les réseaux de Petri (Annexe I). Dans notre travail, nous avons adopté le formalisme des graphes de Gavroche. Ce formalisme a

été introduit dans (Léonard, 1999)90 pour décrire les propriétés dynamiques d’un SI.

1.2.1. Formalisme des graphes de Gavroche

Un graphe de Gavroche est un graphe biparti ; c’est un réseau de nœuds et d’étoiles où les nœuds correspondent un à un à des classes et les étoiles à des transactions.

La notion de transaction utilisée dans les graphes de Gavroche est inspirée des concepts de « transaction commerciale » et de « transaction bancaire » et est associée à une activité productrice ou consommatrice d'informations dans un processus de prise de décision.

Une transaction tr dans un graphe de Gavroche a une ou plusieurs classes (nœuds) de base (°tr) et une ou plusieurs classes de rajout (tr°). La transaction tr se base sur les informations contenues dans les objets des classes de °tr et produit des objets des classes tr°.

Au niveau d’une transaction, les classes de base et les classes de rajout représentent les ressources informationnelles respectivement nécessaires et produites. Ces éléments sont primordiaux, car sans les bonnes ressources aucune décision justifiée ne peut être prise. L’exploitation d’une information de base (°tr) pour produire une nouvelle information (tr°) constitue la valeur ajoutée au niveau d’une transaction.

°tr = ensemble des classes de base de tr tr° = ensemble des classes de rajout de tr

Les ressources informationnelles nécessaires sont des « données et informations qui fournissent une base pour créer plusieurs alternatives dans un contexte de prise de décision ».

89

(Bouzeghoub & al. 1997) Bouzeghoub M., Gardarin G., Valduriez P., Les objets. Paris : Eyrolles, 1997. ISBN 2212089570.

90

(Léonard, 1999) Léonard M., M7 : approche évolutive des systèmes d’information. Proc. Inforsid’99. La Garde, France, mai 1999.

Ces ressources doivent être « consistantes et cohérentes afin de permettre une prise de décision … et aussi pour minimiser le temps nécessaire pour choisir l’alternative optimale dans un contexte donné » (Daft, 2000). Par la prise de décision ou par le choix d’une alternative au niveau d’une transaction, les informations de base sont transformées et réarrangées : ce traitement produit de nouvelles informations au niveau des classes de rajout.

Une transaction (étoile dans un réseau biparti) a au moins une classe de base et au moins une classe de rajout. Les ensembles de classes de base et de classes de rajout sont disjoints.

°tr≠Ø et tr°≠Ø °tr ∩∩∩∩ tr°= Ø

1.2.1.1. Domaine d’une transaction

Le domaine d’une transaction tr est l’union de ses classes de base et ses classes de rajout. Domaine(tr)=°tr ∪∪∪∪ tr°

Il représente l’espace informationnel nécessaire pour la conclusion de la transaction et couvre « les relations entre les informations qui sont éditées, travaillées et manipulées dans un processus de prise de décision » (Ott & Natansky, 1997)91.

Classe de rajout idTransaction, idClasse // Classe de Base idTransaction, idClasse // Transaction idTransaction // nomTransaction préCondition postCondition idDiagramme traitementTransaction HyperméthodeDansTransaction idTransaction, idHyperméthode // Hyperclasse idHyperclasse // nomHyperclasse idDiagramme Hyperméthode idHypermethode// signatureHypermethode codeHypermethode etatHypermethode idHyperclasse Ressource idTransaction, idClasse // Diagramme idDiagramme // nomDiagramme descriptifDiagramme Classe idClasse // nomClasse idDiagramme

La Figure 89 présente le modèle des transactions. En plus de ses classes de base et de rajout, une transaction est définie par (i) un traitement, (ii) une pré-condition et (iii) une post- condition.

1.2.1.2. Traitement

Dans les graphes de Gavroche, le traitement associé à une transaction est une séquence d’opérations, traitées comme une unité, qui exploite les objets de classes de base pour produire des objets dans les classes de rajout de la transaction. Ces opérations utilisent les hyperméthodes définies sur le diagramme de classes, en particulier les méthodes des classes de base et de rajout de la transaction, notamment les primitives prédéfinies de mise à jour ou de création ou de suppression d’objets des classes.

Une transaction produit nécessairement des objets dans ses classes de rajout ; seules les transactions génératrices (créatrices, productrices) d’objets sont considérées dans les graphes de

Gavroche (Pham, 2003)92.

1.2.1.3. Pré-condition et post-condition à une transaction

Une pré-condition à une transaction est une condition au déclenchement de la transaction. Elle concerne les objets des classes de base.

Une post-condition à une transaction est une condition à la création d’objets dans les classes de rajout et donc à la terminaison de la transaction.

Les pré et post-conditions à une transaction prennent la forme d’expressions booléennes pouvant être complexes et portant sur les objets respectivement des classes de base et de rajout de la transaction.

1.2.1.4. Exemples de transaction

Pour l’inscription des étudiants aux modules de la formation MATIS, nous définissons une transaction que nous appelons InscriptionAuModule (Figure 90).

91

(Ott & Natansky, 1997) Ott M., Nastansky L., Groupware Based Organization – Design for dynamic Workflow Management and Office Systems. Workgroup Computing Competence Center Paderborn, Universität-GH Paderborn. 1997.

92

(Pham, 2003) Pham T., Intégration des aspects statiques et dynamiques des Systèmes d'Information, Mémoire préliminaire, Université de Genève, 2003.

Module Étudiant

Inscription

Transaction_{: InscriptionAuModule(etudiant, module)} PréCond_{= (etudiant.etat=Actif ) ET (Module.etat=Valide)} PostCond=∃!inscription(etudiant, module)

Traitement_{: inscription.new(student, course)}

Figure 90 : La transaction InscriptionAuModule

La transaction InscriptionAuModule admet Étudiant et Module comme classes de bases et Inscription comme classe de rajout.

Pour un objet étudiant et un objet de module respectant la pré-condition [(étudiant.état=Actif ) ET (Module.état=Valide)] le traitement associé à la transaction (créer un nouvel objet d’Inscription associant étudiant à module) est exécuté, à condition de ne pas enfreindre la post-condition (il n’existe pas déjà d’objet d’Inscription reliant les objets étudiant et module).

La Figure 91 représente deux autres transactions de M@TIS intégrées avec son diagramme de classes.

AncienEtudiant Utilisateur EtudiantDiplomé Laborat oire Examen Correspondance Rôle Expéditeur Destinataire RôlePer sonne Personne SupervisionProjet RattachementInstitutionnel Projet Evaluation Institution Etudiant Response Question Salle ResponsableModule Inscription Compos it ionQuestionnaire Dépêc he Enseignant Séance Module Enseignement Document 1 2 / Résultat

Figure 91 : Exemples de transactions dans M@TIS

La transaction « 1 » concerne l’analyse des résultats des étudiants en fin de formation : il s’agit de décider pour un étudiant donné, au vu de ses résultats aux modules auxquels il est inscrit ainsi que sa note de projet de recherche, si l’étudiant vérifie les conditions pour obtenir son diplôme et devenir un étudiant diplômé.

La transaction « 2 » permet à partit d’un module, un enseignant et une salle de définir une séance et un objet d’enseignement.

1.2.2. Opérations sur les graphes de Gavroche

Nous définissons un ensemble d’opérations pour la manipulation et l’évolution des graphes de Gavroche. Cet ensemble, complet, a été obtenu par l’application des trois opérateurs génériques (i) créer, (ii) supprimer et (iii) mettre à jour à chacun des éléments du modèle. Ces opérations n’ont pas d’impact sur les objets existants du SI.

Pour prendre en compte l’extension du méta-modèle binex avec les concepts des graphes de Gavroche, nous définissons également les actions supplémentaires à exécuter lors de la suppression d’objets des classes Hyperméthode, Hyperclasse et Diagramme.

1.2.2.1. Transaction