La hiérarchie

L’héritage est un mécanisme qui permet de maîtriser la complexité. La règle : "a"v"c (Permission(ST1, r1, a, v, c) Æ Permission(ST1, r2, a, v, c) exprime l’héritage des permissions dans ST1 entre un rôle r1 (par exemple médecin) et un rôle r2 (par exemple chirurgien). Une autre manière de faire consiste à ajouter le prédicat “Sous-Rôle(Organisation, Rôle, Rôle)”, ainsi pour spécifier que r₁ hérite des permissions de r₂, il suffit d’ajouter l’instance Sous-rôle(ST₁, r₁, r₂) à cette règle.

Précisons toutefois que dans notre modèle il est possible de spécifier que l’héritage entre deux rôles donnés ne s’applique qu’à certaines organisations. Nous pouvons par exemple spécifier qu’à l’hôpital Purpan, le rôle directeur hérite des permissions du rôle médecin :

"a"v"c (Permission(Purpan, médecin, a, v, c) Æ Permission(Purpan, directeur, a, v, c)).

Bien évidemment, l’héritage est spécifié au sein d’une organisation donnée, et nous n’aurions pas cette règle si, au lieu de considérer l’hôpital Purpan, nous considérions un autre établissement au sein duquel le directeur n’est pas un médecin. Il est également possible d’exprimer dans notre modèle l’héritage, entre rôles, d’interdictions, d’obligations et de recommandations.

Par ailleurs, de la même manière que nous avons spécifié la hiérarchie de rôles, nous pouvons modéliser la récursivité des vues, des activités et des organisations à travers lesnouveaux prédicats : “Sous-Vue(Organisation, Vue, Vue)”, “Sous-Activité(Organisation, Activité, Activité)”, “Sous-Organisation(Organisation, Organisation)”. Par exemple, les vues dossier_administratif, dossier_médical et dossier_chirurgical sont des sous-vues de la vue dossier_patient. Ainsi, un rôle qui a la permission de réaliser une activité sur la vue dossier_patient a également la permission de réaliser la même activité sur les sous-vues précédemment citées. Ceci s’exprime dans notre langage par la règle suivante : "r"a"c (Permission(Purpan, r, a, dossier_patient, c) Æ Permission(Purpan, r, a, dossier_administratif, c)). Il en est de même pour les vues dossier_médical et dossier _chirurgical.

Dans le domaine social, la spécification des accès (en amont) à Net-entreprises distingue deux rôles “de base” joués par les utilisateurs dans les organisations (section 3.2.2.1, page 69) : - Personne inscrite,

- Personne non-inscrite.

Rien n’empêche qu’une personne inscrite puisse jouer le rôle de personne non-inscrite.

Inversement, pour qu’une personne non-inscrite devienne inscrite, elle doit remplir certaines conditions (inscription).

Les rôles : dirigeant, mandataire social, administrateur et personne autorisée, sont des sous-rôles du rôle personne inscrite, ils héritent donc de ses propriétés (par exemple, l’appartenance à un établissement adhérent) et de ses privilèges (par exemple, le droit de modification de ses propres informations). Une relation d’héritage existe également entre le rôle mandataire social et le rôle dirigeant. Il est possible de faire appel au polymorphisme pour spécifier que le mandataire social est le dirigeant du siège de l’entreprise. Dans Or-BAC, cette hiérarchie de rôles peut être modélisée par les règles suivantes :

- Sous-Rôle(Org, Mandataire, Dirigeant),

- Sous-Rôle(Org, Dirigeant, Personne-inscrite), - Sous-Rôle(Org, Administrateur, Personne-inscrite), - Sous-Rôle(Org, Personne-autorisée, Personne-inscrite).

Si différentes personnes autorisées accèdent à différents services, le rôle “personne autorisée”

est décomposé en plusieurs sous-rôles. Autrement dit, si dans une certaine organisation, les personnes qui préparent les déclarations, différent de celles qui les envoient (les modifient, ou les payent), il est nécessaire de considérer autant de sous rôles que de sous tâches distinctes des personnes autorisées. Nous pouvons ainsi déduire les règles de hiérarchie de rôles suivantes : - Sous-Rôle(Org, Personne-autorisée-Préparer-Déclaration, Personne-inscrite),

- Sous-Rôle(Org, Personne-autorisée-Valider-Déclaration, Personne-inscrite), - Sous-Rôle(Org, Personne-autorisée-Visualiser-Déclaration, Personne-inscrite), - Sous-Rôle(Org, Personne-autorisée-Préparer-Paiement, Personne-inscrite), - Sous-Rôle(Org, Personne-autorisée-Valider- Paiement, Personne-inscrite), - Sous-Rôle(Org, Personne-autorisée-Visualiser- Paiement, Personne-inscrite).

5.4.1.5 Le contexte

Le contexte peut être exprimé par des règles de fonctionnement. En l’occurrence, l’exclusion mutuelle entre les rôles médecin de nuit et médecin de salle s’exprime par RdO(u, Médecin, Org)Æ[RdO(u, Médecin-nuit, org)´¬RdO(u, médecin-salle, org)].

Le contexte “équipe traitant” entre un certain patient o, un sujet s et une organisation org peut être définie de la manière suivante : "s "o "a CdO(org, s, o, a^, Equipe-traitante) ´$r RdO(org, s, r) Ÿ N o m(o) Œ Patient(s)). Cette formule peut être interprétée ainsi : dans l’organisation org, le contexte “équipe traitante” est vrai entre le sujet s et l’objet o si et seulement si s joue un rôle dans org et si o est un dossier correspondant à un des patients traité par org.

De la même manière, le contexte “équipe traitante” est défini dans une certaine organisation ST₁ par :

- "s"o"a (Définit(ST₁, s, a^, o, équipe_traitante) ´ $r (RdO(ST₁, s, r) Ÿ Nom(o) Œ Patient(ST₁)), c’est-à-dire, dans ST₁, le contexte “équipe traitante” est vrai entre le sujet s, l’action a et l’objet o si et seulement si s joue un rôle dans ST₁ et si o est un dossier correspondant à un des patients traité par l’organisation ST₁.

Le contexte peut éventuellement dépendre de contraintes temporelles. Le contexte “nuit” par exemple, peut être spécifié par la règle suivante : “"s"o"a (Définit(org, s, a, o, nuit) ´ Après(20:00) & Avant(08:00)”. L’opérateur “&” désigne la conjonction de contextes ; “Après”

et “Avant” sont deux fonctions qui s’appliquent à des éléments du “temps” et qui retournent des contextes temporels. Elles peuvent être définies comme suit :

- “"org "s "o"a "tŒTemps, Définit(org, s, a^{, o, après(t))} ´ temps(Horloge) ≥ t”.

“Horloge” est une entité capable d’évaluer et de retourner le temps courant.

Le contexte “avant” peut être défini d’une façon similaire par :

- “"org "s "o"a "tŒTemps, Définit(org, s, a, o, après(t)) ´ temps(Horloge) ≥ t”.

L’expression du lieu comme attribut contextuel peut être fait ainsi : “"org "s "o"a

"tŒTemps, Définit(org, s, a, o, Accès-Local) ´ @IP(s) Œ IP-Local(org)”. Cette règle signifie que le contexte “Accès Local” est vrai dans l’organisation org entre le sujet s l’action a ^et l’objet o, si et seulement si l’adresse IP du sujet appartient à un intervalle d’adresses IP internes à org. Nous considérons que les sujets ont l’attribut “@IP”qui donne l’adresse IP du terminal

utilisé par le sujet et que les organisations ont l’attribut “IP-Local”qui retourne l’ensemble des adresses IP internes à cette organisation.

Pour offrir plus de flexibilité, nous avons défini l’objectif d’utilisation comme un contexte particulier revendiqué par des utilisateurs souhaitant intervenir dans des situations qui sortent des processus de soins habituels. Un objectif d’utilisation est caractérisé par des conditions a priori et des conditions a posteriori. À titre d’exemple, détaillons le contexte Contexte_UNH :

“Urgence Non Habituelle (UNH)”. Nous proposons de l’exprimer de la manière suivante :

"s"o"a (Définit(ST1, s, a, o, ContexteUNH) ´ Déclarer-Objectif Ÿ Condition-a-priori Ÿ Condition-a-posteriori, avec :

- Déclarer-Objectif ≡ (créer, s, o’) Ÿ VdO(org, o’, Vue_UNH) Ÿ Patient-traité(o’)=Nom(o). Dans cette expression, nous considérons la vue “Vue_UNH” ayant un attribut “Patient-traité”. Le sujet déclare l’objectif d’utilisation “urgence non habituelle” s’il insère l’objet o’ dans la vue VueUNH, et si o correspond bien au patient figurant dans l’objectif déclaré.

- Condition-a-priori ≡ RdO(org, s, Personnel-Soignant). Cette expression signifie que tout personnel soignant (dans une organisation) peut déclarer l’objectif d’utilisation “urgence non habituelle” (dans cette organisation).

Condition-a-posteriori ≡ Obligation(o r g, S y s t è m e, E n r e g i s t r e r, VueDonnées-Audit, ContexteObjectif), c’est-à-dire que le système (rôle) doit enregistrer les données d’urgence.

Les types de contextes existants dans la sphère sociale ne diffèrent pas de ceux énumérés précédemment, nous nous contentons ainsi de modéliser quelques exemples dans Or-BAC.

Nous commençons par exprimer le contexte temporel “déclaration-à-échéance”. Pour cela, nous avons tout d’abord besoin de définir la fonction “date” qui s’applique à une action et un objet, et retourne la date d’exécution de l’action sur l’objet, par exemple “date(envoi, d1.txt)”

désigne la date d’envoi de la déclaration d₁.txt à Net-entreprises. Nous définissons par la suite la fonction “avant-date” qui s’applique à des triplets (d : date, a : action, o : objet), pour retourner un contexte temporel défini comme suit : "s"o"a CdO(Org, s, a^{, o,} avant-date(d, a, o) ´ date(a, o)£d, c’est-à-dire, l’action a est exécuté sur l’objet o avant la date d. Nous avons également besoin de l’attribut “Nbre-salariés” d’une entité “organisation” pour désigner le nombre de salariés de cette organisation et de l’attribut “mois” d’une entité date, pour désigner le mois de cette date. Enfin, le contexte “déclaration-à-échéance” peut être défini par la règle :

"s"o"a (CdO(Org, s, envoi, o, déclaration-à-échéance) ´

[Nbre-salariés(Org) £ 9 Ÿ avant-date(15 [(mois(date) modulo 3) = 1], a^{, o)]} ⁄ [10 £ Nbre-salariés(Org) £ 50 Ÿ avant-date(15 mois(date)+1, a^{, o)]} ⁄ [Nbre-salariés(Org) > 50 Ÿ avant-date(5 février, a^{, o)].}

En effet, une déclaration est considérée à échéance si elle appartient à l’un des trois cas suivants :

Si le nombre de salariés de l’entreprise ne dépasse pas neuf, la déclaration est trimestrielle et doit être faite avant le 15 du mois qui suit (c’est-à-dire avant le 15 des mois de janvier, avril, juillet et octobre) ; sinon, si le nombre de salariés est compris entre dix et cinquante, les déclarations sont mensuelles et doivent être faites avant le quinze du mois qui suit ; sinon (nombre de salariés supérieur à cinquante), les déclarations sont mensuelles et doivent être faites avant le cinq du mois qui suit.

Par ailleurs, puisque les autres contextes²⁹ identifiés dans les accès à Net-entreprises sont similaires à ceux présentés dans le scénario médical de la section précédente, il n’est pas nécessaire de les décrire à nouveau.

Une autre représentation du contexte associé à Or-BAC dans un langage logique du premier ordre a été effectuée par Cuppens et Miège [Cuppens & Miège 2003b]. Certaines différences existent toutefois entre leur vision et la nôtre. En particulier, ils catégorisent différemment le contexte et ne considèrent pas le contexte d’utilisation.