Discussion :

[Anonymouse]

Bonjour

Je souhaite, dans le cas ci-dessous, modéliser en Merise le fait que si il existe une occurence dans l'association AVOIR alors il est nécessaire d'avoir une occurence dans l'association POSSEDER et AUTORISER vers la même APPLICATION.

Plus concrètement une application possède plusieurs actions et plusieurs rôles. Le rôle d'une apllication ne peut donc contenir que des actions de cette même application.

Comment pourrais-je modéliser cette contrainte avec merise 2?

[ottoayoub]

Ici tu trouve comment faire le passage

[JPhi33]

Bonjour Anonymouse,

Je n'ai pas trouvé de modélisation de contrainte immédiate ni simple. J'ai bien une solution à base de contraintes d'inclusion mais celle-ci passe par l'ajout d'une CIF. Ceci m'amène à penser qu'il y a peut-être un problème de modélisation plus profond.

Voici les questions que je me pose.

• Les rôles et actions sont-il vraiment spécifiques à chaque application ?
• Les entités ROLE et ACTION sont-elles correctement identifiées ?
• En particulier, l'identification relative a-t-elle été envisagée pour ces deux entités ?

JPhi33

[Anonymouse]

Bonsoir,

Je fais un petit résumé de la partie de la situation à modéliser.

Mon maître de stage veut créer un système de gestion des droits commun à toutes les applications qui seront développées. Il est néanmoins nécessaire que celui-ci ne contraigne point trop le développeur dans son codage.

Pour cela, après divers autres solutions, il a été décidé de laisser chaque développeur créer ses rôles. Cela paraît assez logique puisque lorsqu'un dev crée une appli il va gérer N scénarios possibles et créer autant de rôles.

Par ailleurs mon maître de stage souhaite que dans une optique de facilité pour le développeur les actions associés au rôles soient stockées dans la base de données. Avant d'afficher tel ou tel option le développeur n'aura qu'a vérifier si le rôle associé à l'utilisateur possède l'action désirée.

Donc pour répondre: à ta:

question 1:
Les rôles et les actions sont spécifiques à chaque application

question 2:
Je pense, jusqu'à ce que j'ai tord , que les entités ROLE et ACTION sont bien identifiées, en revanche pour les DF je n'en mettrai pas ma main à couper.

question 3:
Je ne comprend pas la question en particulier le concept de identification relative

Néanmoins, d'un point de vue sémantique il ne semble pas idiot qu'une action puisse être utilisée par plusieurs applis. Par exemple la gestion de clients dans le LDAP par deux applis différentes pourrait utiliser la même action: "Ajouter employés".

Cette solution pose les problèmes suivants:
-Forcer le développeur à consulter la liste des actions disponibles pour les réutiliser: il serait alors idiot d'avoir sous deux nom différent deux mêmes actions.
-Que sous chaque action se cache bien le même concept.

Pour résumer je ne sais pas trop comment faire. pour le moment j'ai créé une règle de gestion pensant l'implémenter avec des triggers .

Merci de ton aide

[JPhi33]

Bonsoir,

question 3:
Je ne comprend pas la question en particulier le concept de identification relative

L'identification relative est un concept dans lequel une entité dite "faible" est identifiée par rapport (ou relativement) à une autre entité dite "forte". L'identifiant de l'entité faible est composé de son propre identifiant et de celui de l'entité forte.

Le cas typique, que j'utilise systématiquement pour expliquer ce concept est celui des entités PARENT (forte) et ENFANT (faible). L'identifiant de PARENT est absolu ; par exemple n_parent, un numéro unique dans le S.I. L'identification relative de ENFANT par rapport à PARENT consiste à attribuer un numéro d'enfant n_enfant par rapport à son PARENT :
- le parent 1 a les enfants 1 et 2
- le parent 2 a l'enfant 1
- le parent 3 a les enfants 1, 2 et 3
etc.
L'identifiant absolu de ENFANT est constitué par la "concaténation" (ou assemblage, ou composition) des identifiants fort et faible : (n_parent, n_enfant). Donc, en réalité :
- les enfants du parent 1 sont identifiés (1, 1) et (1, 2)
- l'enfant du parent 2 est identifié (2, 1)
- les enfants du parent 3 sont identifiés (3, 1), (3, 2) et (3, 3)


Ma question était donc : ROLE et ACTION doivent-elles être identifiées par rapport à APPLICATION. Vu tes explications, ce pourrait être le cas mais ça ne résoudrait pas ton problème.

Il faut noter aussi que la modélisation d'une contrainte sémantique (inclusion, totalité, couverture, etc.) de manière graphique n'est qu'une notation. Une règle textuelle est équivalente et peut tout à fait convenir pour exprimer la contrainte ; elle est simplement moins immédiate à la lecture du MCD et, évidemment, non visuelle.
Enfin, l'une comme l'autre, n'affranchissent pas de devoir être implémentées, par exemple à l'aide de triggers comme tu l'as fait.


Pour conclure, voici la solution que j'ai envisagée.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
    +--------->[ APPLICATION ]<----------+
    |                 ^                  |
    |                 |                  |
    |                1,n                 |
    |                 |                  |
    |                 |                  |
(POSSEDER)<---(I)---(CIF)----(I)--->(AUTORISER)
    |                 |                  |
    |                 |                  |
    |                1,1                 |
    |                 |                  |
 [ ROLE ]--1,n----( AVOIR )----1,n--[ ACTION ]

Tout couple Rôle, Action (association AVOIR) ne peut exister que si le Rôle et l'Action appartiennent à la même Application, d'où l'introduction de la CIF entre AVOIR et APPLICATION. Celle-ci permet de modéliser 2 contraintes d'inclusion (en rouge) stipulant que le triplet {Rôle, Action, Application} doit faire partie :
- de la liste des couples {Rôle, Application} "légitimes", d'une part
- de la liste des couples {Action, Application} "légitimes", d'autre part.


Je conviens que cette solution est un peu "alambiquée" mais je n'en vois pas d'autre...

[Anonymouse]

Bonjour,

Il existe bien une identification relative entre d'une part les entités ROLE ET APPLICATION et d'autre part entre ACTION et APPLICATION. . Je l'ai donc ajoutée dans le MCD.

La solution proposée me semble parfaitement convenir à la représentation graphique voulue.

Je te remercie de l'aide apportée.