Propriétés du diagramme d’hyperclasse
6. L ES HYPERCLASSES DANS L ’ INGÉNIERIE DES SI S
6.2.3. Exemples de recouvrement d’hyperclasses
Dans M@TIS, chacune des cinq catégories d'acteurs de la formation (étudiant,
enseignant, responsable de module, coordinateur et technicien) dispose d’un espace
informationnel qui décrit l’espace informationnel qui leur est attribué dans le cadre de leurs interactions avec le système. Ces espaces informationnels sont représentés par un ensemble d’hyperclasses (voir Annexe F) qui ont en commun plusieurs classes du diagramme de classes et mettent ainsi en évidence plusieurs situations de recouvrement entre les compétences des différents acteurs de la formation.
Voici deux exemples de situations de recouvrement dans M@TIS.
Les modules
La classe Module est partagée par plusieurs hyperclasses associées au coordinateur, aux
étudiants, aux enseignants et aux responsables de module.
Le coordinateur est le seul acteur habilité à introduire de nouveaux modules dans
M@TIS, mais aussi de les supprimer. Il a aussi la possibilité de mettre à jour les informations
relatives aux modules. Dans hcl_planning82, le coordinateur a les privilèges suivants : 1. Accès à tous les objets de la classe Module ;
2. Création, suppression et mise-à-jour d’objets dans Module ;
3. Accès à tous les attributs de Module.
Un responsable de module est entre autre responsable de la description de son module. Dans hcl_gestion_module83, il a les privilèges suivants :
1. Accès en consultation à tous les objets de la classe Module, même ceux dont il n’est pas responsable ;
82
Hyperclasse construite sur les classes Module, Enseignement, Séance, Examen, Salle, Institution, Enseignant,
ResponsableModule, Document et Personne.
83
Hyperclasse définie sur les classes Module, Enseignement, Séance, Examen, Salle, Institution, Enseignant,
2. Suppression et mise-à-jour des objets dans Module dont il est responsable : ce sont les
objets de Module, atteints dans hcl_gestion_module en partant de l’objet de
ResponsableModule correspondant au responsable de module concerné ;
3. Accès à tous les attributs de Module.
Un enseignant ou un étudiant dans ses hyperclasses a les privilèges suivant sur Module :
1. Accès en consultation à tous les objets de la classe Module, même ceux auxquels il ne participe pas ;
2. Accès à tous les attributs de Module.
Les résultats des étudiants
Les résultats obtenus par un étudiant sont représentés par l’occurrence d’attribut Inscription.noteModule ; la classe Inscription est commune à plusieurs hyperclasses associées au coordinateur, aux étudiants, aux enseignants et aux responsables de module.
Chaque responsable de module est responsable de l’attribution des notes des étudiants de
son module ; il a les privilèges suivants dans ses hyperclasses sur Inscription :
1. Accès en consultation à tous les objets de la classe Inscription, même ceux reliés à un module dont il n’est pas responsable ;
2. Mise-à-jour d’Inscription.noteModule dans les objets d’Inscription reliés à son module.
Chaque étudiant est responsable de son inscription à un module. Dans ses hyperclasses, il
a donc les privilèges suivant sur Inscription :
1. Création d’objets d’Inscription liés à l’objet d’Étudiant qui lui correspond ;
2. Accès en consultation aux attributs Inscription.idModule et Inscription.idÉtudiant dans tous
les objets de la classe Inscription ;
3. Accès en consultation à l’attribut Inscription.noteModule uniquement dans les objets liés à
l’objet d’Étudiant qui lui correspond.
Un coordinateur ou un enseignant a les privilèges suivants sur Inscription :
4. Accès en consultation à tous les objets de la classe Inscription.
CONCLUSION
Dans ce chapitre, nous avons introduit les concepts d’hyperclasse, d’hyperobjet, d’hyperattribut et d’hyperméthode. Ces concepts ouvrent de nouvelles possibilités pour l’ingénierie des SI, tant pendant les phases de conception que de développement ou d’exploitation ou de manutention :
1) le concept d’hyperclasse introduit une forme de modularité dans la gestion de modélisation
de SI ;
2) le concept d’hyperattribut réduit la connaissance nécessaire des détails de la modélisation autant pour des utilisateurs que pour des concepteurs, développeurs, etc. du SI ;
3) le concept d’hyperméthode constitue un avantage pour les concepteurs de SI ; ils n’ont pas à choisir à quelle classe particulière de l’hyperclasse associer une méthode ;
4) les espaces informationnels dans un SI ne peuvent plus disposer des informations de manière
privée. L’étude du partage des responsabilités autour de la gestion des informations contenues dans un SI repose sur trois notions essentielles :
a)le concept d’hyperclasse, représentation de l’espace informationnel d’une zone de
responsabilité autour du SI ;
b)la notion de recouvrement pour présenter des situations de partage de l’information entre
les différentes hyperclasses d’un SI ;
c)la notion de protocole de recouvrement, pour exprimer la coordination des activités des personnes autour du SI. Les concepts proposés dans ce chapitre offrent un ensemble de moyens pour définir ces protocoles de recouvrement et pour gérer de manière fine l’interopérabilité d’hyperclasses.
Le concept d’hyperclasse est une généralisation du concept de classe. Sa mise en place n'exige pas beaucoup d’opérations supplémentaires mais sophistique seulement davantage les opérations existantes qui ont été développées pour supporter le concept de classe. Dans le chapitre suivant, nous définissons les opérations d’évolution et de manipulation de diagrammes de classes avec des hyperclasses.
CHAPITRE III
O
PÉRATIONS SUR LES
INTRODUCTION
Ce chapitre est consacré aux opérations sur les hyperclasses. Ces opérations sont organisées en trois ensembles : (i) évolution, (ii) extraction et (iii) intégration d’hyperclasses. Elles constituent une base embryonnaire pour une ingénierie des SI basée sur les hyperclasses et plus tard sur les composants de SI.
1. Évolution d’hyperclasse
L’espace informationnel que représente une hyperclasse dans un diagramme de classes est évolutif : il peut être amené à être restructuré, réduit, ou étendu en intégrant de nouveaux concepts ou d’autres espaces informationnels. Pour maintenir et préserver l'adéquation entre une hyperclasse et un espace informationnel en cas d’évolution, nous proposons un ensemble complet d’opérations de manipulation et de restructuration des hyperclasses.
2. Extraction d’hyperclasse
Il s’agit d’extraire à partir de diagrammes de classes des hyperclasses représentant des situations remarquables ou récurrentes pour constituer des bibliothèques de solutions génériques. Grâce aux opérations d’évolution, des variantes de ces hyperclasses peuvent être construites et intégrer dans d’autres modèles de SI.
3. Intégration d’hyperclasse
Traditionnellement, l'intégration de modèles consiste à prendre en compte deux modèles de SI et de proposer un modèle global et unifié. Dans le cas des hyperclasses, nous nous intéressons à l’intégration d’une hyperclasse dans un modèle existant de SI, et à l’intégration d’une hyperclasse dans une autre hyperclasse du même modèle.