Cours UML Diagramme d’activité

Cours UML Diagramme d’activité

Avec la croissance fulgurante que connaissent le monde des télécommunications et l’ouverture des Systèmes d’Information (SI), la spécification de ces SI ne peut plus se contenter de la seule modélisation fonctionnelle mais doit prendre en compte les besoins de sécurité. La définition des cas d’utilisation et des activités associées doit s’enrichir en intégrant le contrôle d’accès dans la description de ces processus. Adopté comme une norme ANSI / INCITS (ANSI, 2004), Role-Based Access Control (RBAC) (Ferraiolo et al., 2003) est le modèle de contrôle d’accès le plus répandu dans les systèmes informatiques. En RBAC, l’accès à un objet est accordé à un utilisateur en fonction du rôle qui lui est associé. Cependant, si RBAC est bien adapté à l’expres¬sion d’une politique de contrôle d’accès dans une vue statique comme le diagramme de classes, il est plus difficile de formaliser une politique de contrôle d’accès dans une vue dynamique du système (Basin et al., 2006). Ce travail s’intéresse à cette probléma-tique; nous proposons une nouvelle approche qui permet de représenter une politique de sécurité, basée sur le modèle RBAC, dans une vue dynamique en exprimant les règles de contrôle d’accès sur les “workflows” 1 d’un SI.

SecureUML est un profil UML qui permet de spécifier une politique de contrôle d’accès RBAC sur les diagrammes d’UML. Ce profil étend le modèle RBAC en ex¬primant des contraintes contextuelles : les contraintes d’autorisation. Ces contraintes portent sur l’état spécifié par le diagramme de classes et conditionnent l’évaluation des permissions. Nous proposons de compléter cette vue statique par des diagrammes d’activité d’UML 2 (UML2, 2011), qui sont l’un des modèles préconisés pour la mo¬délisation des workflows. Nous étendons ces diagrammes pour qu’ils représentent le déroulement d’un processus métier en tenant compte des différentes permissions et contraintes d’autorisation d’une spécification SecureUML.

Notre approche identifie les exigences de sécurité dès les premières étapes du cycle de vie de développement. Elle intégre trois vues de modélisation. La première vue est fonctionnelle; elle est représentée par le diagramme de cas d’utilisation qui montre des acteurs interagissant avec les grandes fonctions d’un système. La deuxième est statique ou structurelle et décrit les données d’un système sous forme de classes et d’associations, et les permissions qui leur sont associées. Elle est décrite en Secu¬reUML. La troisième est dynamique et permet d’établir un pont entre les deux pre¬mières visions. Pour construire ce pont, nous avons utilisé le diagramme d’activité à deux niveaux différents. Le premier est abstrait et permet de décrire les cas d’utilisation par une coordination d’actions de haut niveau exécutées par les acteurs du système. Le deuxième est concret et consiste à exprimer les actions abstraites par des actions de bas niveau qui représentent les opérations des classes. Ce diagramme concret tient compte des permissions et contraintes d’autorisation exprimées en Secu¬reUML qui seront associées comme pré-conditions aux actions concrètes concernées.

Le présent travail vise l’expression d’une politique de contrôle d’accès au niveau des activités d’un processus métier et poursuit les objectifs suivants :

– Propager une politique d’accès statique au niveau des activités. – Vérifier les permissions dans l’exécution des activités métiers. – Localiser les actions critiques.

– Définir une représentation facile à intégrer et à transformer dans des plateformes logicielles.

Dans la deuxième section, nous présentons les travaux qui traitent du contrôle d’ac¬cès au niveau des workflows. La troisième section présente SecureUML, le point de départ de notre approche ainsi que l’exemple de planification de réunions, qui illustre cet article. La section 4 discute l’expression des permissions et contraintes d’autorisa¬tion sous forme de préconditions sur les activités d’un processus métier. La section 5 définit le métamodèle qui permet d’étendre le diagramme d’activité pour le contrôle d’accès. Enfin, la dernière section conclut notre travail et présente quelques perspec¬tives.

2. Contrôle d’accès au niveau de Workflow

Dans (WFMC,1999), un workflow est défini comme étant “l’automatisation totale ou partielle d’un processus d’entreprise, au cours duquel on échange d’un participant à un autre, des documents, des informations ou des tâches pour action, et ce selon un ensemble de règles procédurales”. Ces règles sont nécessaires car elles conditionnent le bon fonctionnement du workflow. Dans le présent travail nous nous intéressons en particulier aux règles de sécurité issues de politiques de contrôle d’accès. Contrôler l’accès au niveau des workflows, selon (Kandala, Sandhu, 2002) consiste à assigner aux utilisateurs, conformément aux règles de l’organisation, des permissions pour ef¬fectuer certaines tâches au sein de l’organisation en fonction de leurs qualifications et responsabilités. Plusieurs travaux comme (Ahn et al., 2000), (Bertino et al., 1999) et (Wainer et al., 2003), ont proposé des solutions basées sur le modèle RBAC. Une partie de ces travaux ont étendu le modèle RBAC pour contrôler l’accès au niveau des workflows. Ces extensions incluent par exemple : la spécification des politiques d’autorisation dynamiques (Ma et al., 2011) et la délégation dynamique de tâches (Gaaloul, 2010) et (Wainer et al., 2007). Dans notre travail nous ne cherchons pas à étendre RBAC, mais plutôt à combiner des formalismes approuvés et bien connus tels que SecureUML pour la conception de politiques RBAC et les diagrammes d’activi¬tés d’UML. L’objectif en est de disposer d’un ensemble de modèles accessibles aux divers acteurs d’un développement de logiciels.

Trois langages graphiques sont largement utilisés pour la modélisation des work¬flows : BPMN (BPMN2, 2011), les Réseaux de Pétri (Murata, 1989) et le diagramme d’activité d’UML 2(UML2, 2011). (Geambasu, 2012) compare BPMN et le diagramme d’activité d’UML2 et conclut qu’ils sont équivalents pour représenter des processus de façon compréhensible et pour décrire des processus métiers. Notre choix dans cet article porte sur les diagrammes d’activité d’UML2 car ils incluent un support riche pour représenter les workflows : les actions, les flux de contrôle et de données ainsi que le choix, le parallélisme, les séquences et les événements. Parmi les travaux qui ont utilisé le diagramme d’activité d’UML 2 pour contrôler l’accès au niveau des workflows, (Jurjens, 2010) a proposé l’utilisation d’un package stéréotypé par « rbac » avec les trois tags protected, role, et right qui définissent respectivement l’ensemble des actions protégées d’un diagramme d’activité, les utilisateurs assignés aux rôles exécutant l’activité et l’affectation des actions protégées aux rôles qui peuvent les utiliser. (Strembeck, Mendling, 2011) ont défini un méta-modèle pour l’extension du diagramme d’activité vers le modèle RBAC.

3. SecureUML

UML est une notation graphique standard de l’OMG (Object Management Group) utilisée pour l’analyse des besoins et la conception d’un système. Elle présente l’avan¬tage de pouvoir se décliner sous forme de « profils » permettant l’extension de ces dia¬grammes pour spécifier un aspect particulier d’un système. Plusieurs travaux ont pro¬posé des profils utiles pour la spécification des politiques de contrôle d’accès basées sur le modèle RBAC. Parmi ces profils nous pouvons citer AuthUML (Alghathbar, 2012) qui propose des extensions du diagramme de cas d’utilisation et UMLsec (Jurjens, 2010) qui présente un profil pour étendre le diagramme d’activité.

Dans notre approche, nous utilisons le profil SecureUML (Basin et al., 2006) (Basin et al., 2009) qui permet de représenter une politique de sécurité basée sur le modèle RBAC dans une vue statique. Ce diagramme utilise des permissions, repré¬sentées par des classes associatives, pour exprimer les règles de contrôle d’accès. Une permission est liée à une classe stéréotypée par «Role » qui représente les utilisateurs affectés au rôle, et une autre classe stéréotypée par «Entity» qui représente la classe cible de la permission. La classe associative stéréotypée par «Permission» signifie que les utilisateurs assignés à «Role» sont autorisés, par la permission en relation, à accéder aux éléments de «Entity». E est possible de soumettre cette permission à des conditions contextuelles, appelées conditions d’autorisation. Une permission Se¬cureUML est définie par un ensemble d’attributs. Chaque attribut permet d’assigner une action à la permission et est défini par trois propriétés : des stéréotypes pour dé¬finir le type de la ressource à protéger, le nom de l’attribut qui détermine la ressource protégée, et le type de l’attribut pour spécifier l’action autorisée par la permission.

3.1. Exemple illustratif : organisation de réunions

Afin d’illustrer notre travail, nous allons utiliser l’exemple de l’organisation de réunions, proposé initialement par (Feather et al., 1997). Ce système s’adresse à deux types d’utilisateurs : les “initiateurs” planifient des réunions et les “participants” ré¬pondent aux invitations des initiateurs.

Dans un premier temps, nous représentons les différents besoins fonctionnels du système en utilisant le diagramme de cas d’utilisation de la figure 1. Ce dernier ex¬prime les différentes façons dont les acteurs peuvent utiliser le système. L’acteur Ini¬tiator peut créer des réunions, inviter des participants et suivre leurs réponses. L’acteur Participant répond aux invitations et suit les confirmations des réponses.

Figure 1. Le diagramme des cas d’utilisation du système d’organisation de réunions

Le système d’information permet d’enregistrer les données des personnes (partici¬pants et initiateurs), des invitations, des réunions et des propositions de changement, ainsi que les liens entre ces données. Afin d’assurer la confidentialité et l’intégrité des réunions, le système d’organisation des réunions applique une politique de contrôle d’accès qui définit une seule cible de sécurité: la classe Meeting. Elle se limite aux données les plus sensibles qui sont constituées par les données des réunions telles que la date, l’heure et le lieu.

La figure 2 présente la spécification SecureUML de la politique de sécurité, elle comprend le diagramme de classes et ajoute trois permissions. La première "Create¬Meeting" spécifie que seul un initiateur peut créer des réunions. La deuxième " Initia¬torMeeting " exprime qu’une réunion ne peut être lue ou modifiée que par un initiateur, pour autant qu’il soit le créateur de cette réunion. Cette restriction est exprimée par la contrainte d’autorisation associée à la permission. La dernière permission " Parti¬cipantMeeting " exprime que les participants peuvent également lire les informations des réunions, pour autant qu’ils fassent partie des personnes invitées à la réunion. Les deux permissions " InitiatorMeeting " et " ParticipantMeeting " sont attachées à une contrainte d’autorisation exprimée en OCL (OCL2, 2012). Nous utilisons le mot clé " Caller " du type String dans les expressions OCL pour faire référence au nom de l’uti-lisateur. Souvent ces contraintes font le lien entre les informations issues du modèle de sécurité (comme l’utilisateur et ses rôles) et l’état du modèle fonctionnel. réunions

3.2. Contrôle d’accès aux opérations

Les actions de type «EntityAction» représentent des opérations abstraites qui don¬nentlieu à des appels d’opérations concrètes réalisables sur des classes fonctionnelles. Dans le cadre de notre exemple, les actions autorisées au travers des permissions se traduisent comme suit:

– Modification de la classe Meeting (EntityAction Update) : permet d’appeler les setters d’attributs (DateM, PlaceM et TimeM), ainsi que les setters des extrémités d’associations : Creator, invitationM, et ChangeM ; et permet d’invoquer les opéra¬tions applyChange et delegateMeeting qui sont des opérations de modification.

– Creation de la classe Meeting (EntityAction Create) : permet l’appel au constructeur d’instances de la classe Meeting.

– Lecture de la classe Meeting (EntityAction Read) : permet l’appel à toutes les opérations de lecture d’attributs et d’extrémités d’association de la classe Meeting.

Nous considérons comme critique toute opération d’une classe protégée qui cor¬respond à une action d’une permission. La contrainte d’autorisation associée à la per¬mission exprime une condition nécessaire pour la réalisation des opérations critiques autorisées.

4. Contrôle d’accès aux activités

Cette section montre comment exprimer les permissions sous forme de précondi¬tions associées aux opérations critiques et comment les propager sur les activités d’un processus métier. Cela se fait en trois phases : la première consiste à décrire chaque cas d’utilisation par une activité abstraite, la deuxième permet de spécifier une acti¬vité abstraite par une activité concrète et la dernière complète ce diagramme d’activité pour contrôler l’accès à ses actions.

4.1. Activité abstraite

Le diagramme d’activité d’UML 2 (UML2, 2011) fournit un langage de modéli¬sation des workflows qui est utilisé pour décrire le déroulement d’un cas d’utilisation. Ce modèle est composé des nœuds d’activité, des nœuds d’action, des nœuds d’objet et des nœuds de contrôle. Ces nœuds sont reliés par deux types d’arcs pour représen¬ter les flux de contrôle et de données. L’élément principal d’un diagramme d’activité est l’activité. Son comportement est défini par une coordination d’actions. Plusieurs auteurs, comme (Roques, 2006), ont spécifié un cas d’utilisation par un ensemble de séquences d’actions qui représentent des tâches exécutées par des acteurs et qui pro¬duisent un résultat observable. Les tâches sont des opérations abstraites qui permettent d’une part de bien visualiser le comportement d’un cas d’utilisation et d’autre part de communiquer facilement et précisément avec les acteurs du SI. Une activité abstraite permet de représenter un cas d’utilisation par un ensemble de tâches en coordination, représentées par des nœuds d’action, qui seront exécutées par les acteurs du cas d’utili¬sation. Une activité abstraite peut montrer plusieurs scénarios d’exécution. La figure 3 montre un diagramme d’activité qui décrit les deux cas d’utilisation reply to invitation et follow answer de la figure 1 par deux activités abstraites. Les activités sont placées dans des partitions séparées qui précisent les acteurs responsables de ces tâches.

4.2. Activité concrète

Les activités concrètes sont construites à partir des activités abstraites. Les activités abstraites décrivent le système comme une boite noire sans détailler les objets qui le composent. Une fois qu’on dispose d’un diagramme de classes, ces diagrammes abstraits peuvent être raffinés en précisant les objets et les opérations qui les réalisent. Une activité concrète décrit une activité abstraite en spécifiant le comportement de ses différentes tâches par une coordination d’un ensemble d’actions concrètes qui font référence à des opérations sur les objets des classes. L’exécution de chaque tâche fait appel à une ou plusieurs opérations concrètes. Une opération peut être, par exemple, une affection de valeurs à des attributs, un accès à la valeur d’une propriété structurelle (attribut ou terminaison d’association), la création d’un nouvel objet ou lien, ... Dans la figure 4, chacune des tâches view answer et reply to change de l’activité abstraite follow answer (la partie gauche de la figure 3) est décomposée en une coordination d’actions concrètes. Les tâches confirai invitation et cancel participant font chacune appel à une seule action concrète.

Les actions concrètes appellent une opération d’une instance de la classe. Ces ins¬tances sont définies comme des paramètres de l’activité concrète. Ceux-ci fournissent des entrées nécessaires à l’exécution des actions. Les instances M, I, C des entités (Meeting, Invitation et ChangeMeeting), dans la figure 4, sont indispensables pour l’exécution de l’activité Follow answer. Une activité concrète regroupe une famille de scénarios qui seront exécutés par un utilisateur représentant l’acteur du cas d’utilisa¬tion décrit par l’activité.

4.3. Pré-condition de contrôle d’accès

La séparation des préoccupations encourage à spécifier indépendamment les as¬pects fonctionnels et sécuritaires d’un système d’information. Cependant, leur inter¬action doit être prise en considération au niveau des diagrammes d’activités concrètes. Cette section explique comment exprimer une politique de sécurité spécifiée par Secu¬reUML sur les activités concrètes fonctionnelles. Nous allons montrer comment dans la réalisation d’un processus métier, les permissions du diagramme SecureUML seront prises en compte.

Dans le diagramme d’activité de la figure 4, les permissions et leurs éventuelles contraintes d’autorisation sont exprimées par des préconditions. Ces préconditions sont soit associées à l’ensemble du diagramme, soit attachées à des actions concrètes.

La précondition associée à l’ensemble du diagramme, aussi appelée précondition d’activité, est stéréotypée par «PreCondition». Dans la figure 4, celle-ci impose que l’activité soit exécutée par un utilisateur associé au rôle “Initiator”. Elle s’exprime en OCL par Initiator.assignedUser -> includes (User). Cette précondition porte sur toutes les actions de l’activité. Ici, elle traduit le fait que le cas d’utilisation “follow answer” est exécuté par l’acteur “Initiator” dans le diagramme des cas d’utilisation  (figure 1). Nous considérons donc les acteurs associés aux cas d’utilisation comme des rôles.

La précondition d’activité exprime le fait que toutes les actions doivent être exé¬cutées par un utilisateur dans un rôle donné. Cependant, certaines actions impliquent des opérations critiques dont les permissions sont associées à des contraintes d’au¬torisation. Il faut tenir compte de ces contraintes d’autorisation dans la définition de l’activité. Pour ce faire, des conditions supplémentaires sont exprimées sous la forme de contraintes stéréotypées comme «localPreCondition» et reliées aux actions concrètes(UML2, 2011). Dans la figure 4, cette précondition locale est associée aux quatre actions M.getDateM, M.getPlaceM, M.getTimeM et M.applyChange. Elle ga-rantit que l’utilisateur qui exécute ces actions est le créateur de la réunion: Caller = M.Creator.NameP, ce qui correspond à la contrainte d’autorisation de la permission “InitiatorMeeting” dans la figure 2.

Les préconditions d’activité et les préconditions locales définissent dans quelles conditions les actions concrètes doivent être réalisées. On peut également les voir comme des gardes qui sont évaluées lors de l’exécution du diagramme et qui ga¬rantissent que la politique de contrôle d’accès est bien respectée. Pour la figure 4, on peut se contenter d’évaluer la précondition d’activité en entrée de l’activité, et la précondition locale avant l’exécution de M.getDateM si les conditions suivantes sont respectées:

1. L’utilisateur n’utilise pas d’autre rôle que celui ou ceux prescrits par la précon¬dition d’activité lors de l’exécution du processus.
2. L’utilisateur ne perd pas le droit d’utiliser ces rôles pendant l’exécution de l’ac¬tivité.
3. La précondition locale reste vraie pendant l’exécution des quatre opérations concernées. Ce qui signifie que les objets et associations concernées ne sont pas modi¬fiés par les actions du diagramme d’activité ou par des activités extérieures qui seraient menées en parallèles de ce diagramme.

Si ces conditions ne sont pas garanties, il est nécessaire de vérifier les gardes plus souvent et d’encapsuler tout ou partie du diagramme dans une ou plusieurs transac¬tions.

5. Extension du méta-modèle des diagrammes d’activité

Notre travail vise à intégrer les concepts de SecureUML au niveau des diagrammes d’activité. Pour ce faire, nous définissons la sémantique des liens entre ces modèles au moyen de leurs méta-modèles respectifs. L’explicitation de ces liens permet, outre la définition de leur sémantique, de définir les contraintes qui garantissent la cohérence entre ces modèles.

5.1. Liens entre méta-modèles

Le diagramme de la figure 5 représente les concepts de SecureUML en lien avec les notions d’activité abstraite et d’activité concrète utiles dans le présent travail. Les concepts de SecureUML sont: User, Role, Permission, Action, et AuthorizationCons¬traint. Les concepts inhérents aux activités sont : AbstractActivity, ConcreteActivity, Task, OperationAction et LocalPreCondition.

Une activité concrète est enclenchée par un ou plusieurs rôles et est nécessairement issue d’une activité abstraite. L’activité abstraite est réalisée par un ensemble de tâches (méta-classe Task) et l’activité concrète est réalisée par un ensemble d’actions (méta classe OperationAction) qui correspondent à des appels d’opérations fonctionnelles. Nous considérons que ces actions sont contenues dans les tâches réalisant l’activité abstraite. Ce lien de composition permet de garantir une certaine traçabilité entre les activités abstraites et concrètes tout en étant en relation avec les opérations fonction¬nelles.

Les actions d’une activité concrète (OperationAction) font appel à deux types d’opérations : les opérations critiques auxquelles une ou plusieurs permissions sont associées dans le modèle SecureUML, et les opérations non protégées (comme par exemple I.setConfirmationI et I.delete pour la classe Invitation). Aucune vérification n’est effectuée pour les opérations non protégées. En revanche, pour les opérations critiques, nous projetons les contraintes d’autorisation qui leur sont associées, sous forme de préconditions des actions OperationAction. De ce fait, l’appel d’une opération fonctionnelle dans une activité concrète devient préconditionné par la satisfaction de contraintes d’autorisation.

5.2. Règles de cohérence

Dans cette sous-section nous spécifions au moyen d’expressions OCL les règles de cohérence que les instances de notre méta-modèle doivent respecter. Pour ce faire, nous définissons d’abord deux requêtes OCL, isCritical() et criticalOps() qui permettent respectivement d’indiquer si une opération donnée est critique, et de ré¬cupérer pour une activité concrète l’ensemble de ses opérations critiques. Par exemple, les actions associées à des opérations critiques de l’activité Follow answer de la figure 4 sont : M.getDateM, M.getPlaceM, M.getTimeM et M.applyChange. Les autres ac¬tions sont en relation avec des opérations non protégées.

Context Operation:ÂsCritical():Boolean Body: self.isAssociated → notEmpty()

Context ConcreteActivity::criticalOps():Set(Operation)

Body: self.ActivOpAct.represents → select(o:Operation | o.isCritical())

5.2.1. Conformité des rôles

L’invariant RoleConformance ci-dessous permet de garantir que tous les rôles au¬torisés à enclencher une activité concrète disposent de permissions dans le modèle SecureUML leur donnant le droit de réaliser toutes les opérations critiques de l’acti¬vité.

Context ConcreteActivity inv RoleConformance :

self.role → (forAll(r : Role | r.hasPermission.accesses.criticalOperation

→ includesAll(self.criticalOps())))

Il faut noter que cet invariant impose que le plus faible rôle associé à l’activité ait les droits sur toutes les permissions. Dans la suite de nos travaux, nous étudierons d’une part la possibilité de relacher cette contrainte en s’assurant que l’utilisateur ait des droits pour chaque opération, mais en lui permettant d’utiliser des rôles différents et complémentaires. Il serait également intéressant d’exprimer explicitement le chan¬gement de rôle d’un utilisateur lors de l’exécution d’une activité concrète.

Dans notre démarche, les rôles associés à une activité concrète correspondent aux acteurs définis dans l’activité abstraite qu’elle spécifie. Nous établissons ainsi l’inva¬riant suivant pour garantir un usage de rôles adéquat durant le processus de specifica¬tion allant des activités abstraites aux activités concrètes.

Context ConcreteActivity inv RoleSpecification : self.concrActivAssignment = self.specify.actors

 5.2.2. Traçabilité des contraintes d’autorisation

Les contraintes d’autorisation définies au niveau des permissions sont projetées au niveau des activités concrètes sous forme de préconditions d’actions. Ces pré-conditions, ainsi issues des permissions SecureUML, permettent de contrôler l’exé¬cution des actions d’activité concrète. Elles peuvent soit autoriser le déclenchement des actions d’opération critiques si les contraintes d’autorisation sont vérifiées ou bien bloquer l’exécution de l’activité dans le cas contraire. Le lien entre les méta-classes Precondition et AuthorizationConstraint permet d’avoir une traçabilité entre ces deux notions.

6. Conclusion et perspectives

Le contrôle d’accès est devenu un souci majeur dans le développement des SI. Plu¬sieurs domaines de l’activité économique et sociale sont maintenant sujets à des lois et des normes très strictes au niveau de la sécurité des données (Milhau, 2011). Cet article propose une approche de spécification d’une politique d’autorisation RBAC au niveau du Workflow des activités d’un processus métier. Ceci est réalisé en utilisant des règles de contrôle d’accès, exprimées dans une vue statique via le profil Secu¬reUML, pour contrôler l’accès des utilisateurs aux actions des activités.

La séparation entre les préoccupations fonctionnelles et sécuritaires est au coeur de notre approche. Cette séparation des préoccupations vise à maîtriser la complexité du système, et peut également se montrer utile quand il s’agit de réaliser la sécuri¬sation d’un système d’information pré-existant. De plus, elle facilite l’évolution de la politique de contrôle d’accès. Dans notre approche, les aspects fonctionnels sont exprimés dans les cas d’utilisation, le diagramme de classes et les diagrammes d’ac¬tivité abstraits, et leur raffinement dans l’enchaînement des opérations concrètes. Les aspects sécuritaires sont exprimés statiquement, sous forme de permissions associées à des rôles, pour chaque classe protégée du diagramme de classes. A cet effet, nous nous basons sur le profil SecureUML. Les aspects sécuritaires sont ensuite exprimés dynamiquement par des préconditions associées localement ou globalement aux ac¬tivités concrètes. En outre, les contraintes d’autorisation permettent des interactions entre les aspects fonctionnels et sécuritaires. Elles peuvent être spécifiées dans la vue statique et prendre la forme de gardes dans la vue dynamique.