Par souci de simplicité:Comment visualiser au mieux une "matrice d'autorisation" dans un diagramme de classes UML?
Il y a un système d'autorisation en place avec différents types de niveaux d'utilisateurs et d'actions (pensez: autorisations du système de fichiers UNIX)
Quelle serait la meilleure façon de visualiser cela en UML?
J'ai généralement des classes qui représentent les utilisateurs, les rôles et les autorisations. Les utilisateurs appartiennent aux rôles et les rôles sont autorisés. Des autorisations sont requises pour accéder à d'autres objets. En UML, je suppose que vous modéliseriez Role en tant que classe de base abstraite et que vous auriez plusieurs implémentations différentes, une pour chaque rôle.
Typiquement, je modélise une permission en tant qu'objet contenant des ensembles de classes d'entités commerciales lisibles, inscriptibles et effaçables (pouvant contenir des exclusions de propriétés ou des inclusions). Chaque rôle, puis a une permission. Cette autorisation autorise ou refuse l'accès à une ou plusieurs autres classes. L'autorisation est refusée par défaut et l'accès n'est autorisé que si la classe est dans l'ensemble approprié pour l'action demandée.
J'aime à penser à un objet de système de fichiers ayant un certain nombre de méthodes standard, dont chacune a une permission associée.
Il existe 9 méthodes/permissions qui présentent généralement un intérêt: les combinaisons de (Utilisateur, Groupe, Autre) * (Lire, Écrire, Exécuter). De plus, il existe des options comme Sticky et SetUID.
Un objet de système de fichiers est associé à un utilisateur et à un groupe. Un utilisateur est associé à un nombre quelconque de groupes.
L'utilisateur actuel est associé à un nombre quelconque de groupes.
Ce qui précède est assez sympa. Les objets du système de fichiers, les utilisateurs, les groupes, les associations. Et les objets du système de fichiers ont une pile d'attributs et les 9 méthodes canoniques.
La contrainte sur ce qui est autorisé n'a pas de diagramme ordonné. C'est un ensemble d'expressions de règles. Le premier est l'autorisation à utiliser (utilisateur, groupe ou autre), puis l'autorisation dans l'ensemble (lecture, écriture ou exécution).
Vous pourriez, je suppose, définir une classe d'utilisateurs avec un ensemble d'objets concrets (Unix a utilisateur, groupe, autre), et une classe d'opérations avec un ensemble d'objets concrets (Unix a lu, écrit, exécuté). Vous pouvez ensuite définir des autorisations avec deux associations: une à la classe d'utilisateurs et une à la classe d'opération.
Je pense qu'il est plus facile de lister simplement les méthodes d'ensembles complets qui schématisent les combinaisons d'instances de classes d'utilisateurs et d'instances de classes d'opérations.