Objets de base
A la base de tous les objets décrits dans le modèle conceptuel, on trouve deux objets abstraits, c'est-à-dire qui ne peuvent pas être directement utilisés dans le logiciel pour créer et gérer des instances des entités, mais qui servent de socle commun pour appuyer le modèle d'autres entités concrètes.
Dans Maarch Digital Fow, les entités sont gérées dans des entrepôts selon leur type. Entités et entrepôts sont représentés par deux classes abstraites qui fournissent les propriétés et les comportements de base pour l'ensemble des objets du système.
| Diagramme des objets de base |
|---|
 |
Le modèle est composé de quatre classes de base et six opérations de base.
Classes
Classe SetAbstract - Jeu de données abstrait
La classe SetAbstract représente une abstraction de jeu de données géré au sein d'un entrepôt.
Elle est constituée d'une collection d'objets de même type
Ce modèle est applicable à toutes les sources de données, quelles soient structurées ou non, gérées par le système ou externes.
Certains jeux de données vont permettre des fonctions de listage, de lecture ou d'ajout d'entités en fonction des accès possibles
depuis l'application.
| Nom | Type | Description |
|---|---|---|
objectType |
token |
obligatoire. Indique le type des entités du jeu de données sous la forme d'une valeur normalisée de type. Tout objet géré possède une l'identification de son type, parmi les types implémentés décrits plus loin dans le présent document, tels que les entrées, les utilisateurs ou les contenus numériques. Chacun des types système possède des capacités offertes à l'utilisateur en fonction de l'implémentation réalisée. Le type est défini par l'utilisateur au moment de la création de l'objet dans le système, le plus souvent de manière implicite par le service utilisé pour la création (entry, user, role…). Il n'est pas modifiable après son attribution (immuable). Les types systèmes sont les entités du domaine citées en introduction et les entités de paramétrage et autres référentiels. Quelques exemples d'entités système: sont les dossiers, les documents numériquesn les utilisateurs, les politiques de gestion... |
Classe SystemSetAbstract : Jeu de données système
La classe SystemSetAbstract représente une abstraction de jeu de données géré par le système.
Elle dérive de la classe SetAbstract, en intégrant la capacité à découvrir,
contrôler l'existence et ajouter des objets dans l'entrepôt.
Classe ObjectAbstract : Entité abstraite
La classe ObjectAbstract représente une entité discrète accessible indépendamment de tout support.
C'est une notion abstraite qui sert de base pour l'ensemble des objets concrets du système.
Un objet est défini par un type, en lien avec l'ensemble auquel il appartient.
Il n'est pas possible de préciser son modèle, la présence de propriétés particulières ou son comportement.
Classe SystemObjectAbstract : Entité système abstraite
La classe SystemObjectAbstract représente une abstraction d'entité discrète appartenant à un jeu de données géré par le système.
Elle comport un identifiant système ainsi que des propriétés gérées par le système.
Elle autorise des opérations de lecture et de gestion telles que des modifications et suppressions.
L'objet système possède un type hérité de l'entité Object, auquel sont ajoutées les propriétés suivantes :
- un identifiant interne,
- un propriétaire,
- un jeu de propriétés gérées par le système telles que la date de création, l'agent créateur, la date de dernière modification, etc. Ces attributs sont gérés par le système, opaques à l'utilisateur qui n'y a accès qu'en lecture. Il n'existe donc pas de droit d'accès associé à ces propriétés, le choix de leur présentation à l'utilisateur dans les écrans et contrats de données dépendant des besoins et de l'implémentation.
| Nom | Type | Description |
|---|---|---|
objectId |
uuid |
obligatoire - Identifiant unique interne au système. L'identifiant système est utilisé pour faire référence à l'objet de manière univoque dans les opérations et dans le modèle lui-même. Par exemple dans des structures de données possédant des relations ou des contrats de données d'échange, dans les URI ou des représentations à l'utilisateur. Il est obligatoirement attribué par le système à tout objet au moment de sa création, c'est-à-dire son enregistrement par un agent dans l'application. Il devrait être un identifiant unique universel, par exemple 8f529f69-d36f-43fe-8c28-919e85b5521c. |
createdBy |
uuid |
obligatoire - Identifiant de l'utilisateur ou agent qui a procédé à la création dans le système. |
creationDateTime |
datetime |
obligatoire - Date et heure de création de l'objet dans le système. Elle est définie par le système lors de la création. Non modifiable après enregistrement. |
lastModifiedBy |
uuid |
Identifiant de l'utilisateur ou agent qui a procédé à la dernière modification des propriétés ou du contenu. Il est défini par le système lors de la mise à jour. |
lastModificationDateTime |
datetime |
Date et heure de la dernière modification des propriétés ou du contenu. Elle est définie par le système lors de la mise à jour. |
owner |
uuid |
obligatoire - Identifiant de l'agent propriétaire de l'objet. Tout objet géré par le système possède un propriétaire, qui est un agent interne susceptible d'accéder au système. Ce mécanisme permet de toujours disposer d'un agent qui possède les accès nécessaires aux opérations de base telles que la découverte, nécessaire pour connaître l'existence de l'objet, la lecture, nécessaire pour prendre connaissance de l'information, la modification, nécessaire pour gérer l'objet et notamment réaliser un transfert de propriété ou autoriser d'autres accès et la destruction. Il est défini par défaut avec l'agent qui réalise la création de l'objet, puis reste modifiable par les agents possédant les accès nécessaires. |
Comportement lié aux objets de base
Opération list : Lister les entités du jeu de données
Ce type d'opération permet à l'utilisateur de lister des objets en fonction de critères de filtrage qu'il peut définir ou qui lui sont imposés par le système, comme par exemple lors de l'application de restrictions d'accès. Il existe globalement deux grands modes de recherche : la recherche simple et la recherche multicritères. Dans le premier mode, l'utilisateur fournit du texte à rechercher, sans précision sur les données à prendre en compte ni le mode de comparaison à utiliser. Le système est chargé de "comprendre" la requête, de déterminer le mode de filtrage et d'identifier les objets à sélectionner pour constituer la liste de résultats.
Le plus souvent, ce mode utilise le texte intégral des objets, qui agrège les valeurs de texte des propriétés, des attributs personnalisés, et parfois des contenus numériques pour les entités qui en possèdent. Dans un usage avancé (expert), l'expression fournie par l'utilisateur peut répondre à une structure syntaxique particulière afin d'apporter des précisions sur les données à prendre en compte et le mode de comparaison, se rapprochant ainsi du second mode de recherche. Par exemple, la syntaxe id:val permet d'indiquer au système que la valeur "val" doit être recherchée dans la propriété "id". La syntaxe est en réalité ce qu'on appelle un DSL, pour "Domain Specific Language", un langage de requête propre à un domaine particulier.
Dans le second mode, le système propose à l'utilisateur de composer une structure logique de recherche sur critères multiples, chacun devant indiquer les données à utiliser, le mode de comparaison et la valeur à comparer. Classiquement, les données sont les propriétés ou attributs personnalisés des objets, les modes de comparaison sont des opérateurs d'égalité, de différence, de supériorité, etc, et les valeurs sont fournies dans le format attendu pour la comparaison: texte, nombre, date, indicateur vrai ou faux, etc. Le système peut recevoir une liste de valeurs à retourner, afin d'ajouter à l'identifiant des objets ayant été filtrés un jeu de données qui permettront à l'utilisateur de mieux interpréter les données reçues en réponse. De même, l'utilisateur peut préciser des restrictions sur la plage de valeurs à retourner, s'il ne souhaite pas obtenir une liste complète mais utiliser des fonctions de pagination par exemple. A réception de la requête, le système se charge d'interpréter la demande de l'utilisateur, d'identifier les objets correspondant dans les référentiels cibles, de lire les valeurs et de constituer la liste de réponse.
Opération exists : Vérifier l'existence d'un objet dans le jeu de données
boolean
Cette opération permet au système de contrôler l'appartenance d'un objet à un ensemble.
La demande fournit un identifiant d'objet et renvoie en retour un indicateur booléen de
l'existence de l'objet dans l'ensemble.
Opération create: Ajouter un objet dans le jeu de données
Object - L'opération fait entrer de l'information dans le système sous la forme d'un objet ajouté à un référentiel.
La création est toujours initiée par l'action d'un agent, avec la transmission de l'information pour la création d'un nouvel objet
ou la copie d'un objet existant vers un nouvel objet.
La création est réalisée à partir d'un ensemble auquel on souhaite ajouter un objet.
La demande comporte a minima le type d'objet à créer. Elle s'accompagne de l'information spécifique au type système
(et à un type personnalisé si la capacité est activée et que la demande en transmet un).
La création inclut une étape essentielle de validation de la demande, notamment pour contrôler l'état de l'objet et les droits de l'agent. Le type système de l'objet à créer doit correspondre à l'un de ceux présents dans la liste des types implémentés. Les propriétés de l'entité système qui sont définies comme obligatoires doivent être renseignées et leur valeur conforme au modèle.
Par exemple, le type système "User" rend obligatoire l'identifiant utilisateur, il n'est donc pas possible de créer un utilisateur sans identifiant. L'identifiant est une chaîne de caractères normalisée qui ne doit pas contenir de retours à la ligne ni tabulation. Le système procède à la mise à jour du référentiel des objets, et fournit a minima en retour l'identifiant unique de l'objet créé. L'implémentation de la fonction de création par le type système, et notamment l'usage de capacités, peut ajouter des règles de validation (modèle personnalisé en tête) ainsi que des opérations de mise à jour spécifiques au type système et personnalisées par l'utilisateur.
Opération read: Lire
Object - Cette opération récupère de l'information dans un référentiel pour en transmettre une copie à un agent.
Elle sert de base à de nombreuses opérations spécifiques à l'implémentation du type système, au périmètre d'information diffusé,
à l'agent demandeur et au mode de diffusion: la consultation est une diffusion au sein du système à un agent utilisateur,
l'export vers un système tiers en est une autre forme, la transmission par e-mail une troisième.
La demande comporte à minima l'identifiant de l'objet à lire.
La lecture inclut une étape essentielle de validation de la demande, notamment pour contrôler l'état de l'objet et les droits de l'agent.
Le système procède à la lecture depuis le référentiel des objets, et fournit une représentation de l'objet demandé.
L'implémentation de la fonction de lecture par le type système, et notamment l'usage de capacités, peut ajouter des règles de validation
ainsi que des opérations de lecture spécifiques au type système et personnalisées par l'utilisateur.
Opération update: Mettre à jour l'entité
mixed - Cette opération met à jour l'information d'un objet existant dans le référentiel.
Elle est réalisée en fournissant l'identifiant unique de l'objet et un jeu de données à modifier.
C'est un changement d'état qui se décline en de nombreuses opérations spécifiques à l'implémentation par un type système
et au périmètre d'information modifié: la publication, la mise à jour des ACL ou l'annotation sont toutes des opérations de modification.
La demande comporte à minima l'identifiant de l'objet à modifier. Elle s'accompagne de l'information à mettre à jour, spécifique au type système (et à un type personnalisé si la capacité est activée et que l'objet à modifier ne précise un).
La mise à jour inclut une étape essentielle de validation de la demande, notamment pour contrôler l'état de l'objet et les droits de l'agent. Les propriétés de l'entité système qui sont définies comme obligatoires ne doivent pas être supprimées et les nouvelles valeurs doivent être conformes au modèle. Les valeurs immuables ne doivent pas être transmises.
Le système procède à la mise à jour du référentiel des objets, et fournit a minima en retour le résultat de l'opération.
L'implémentation de la fonction de modification par le type système, et notamment l'usage de capacités, peut ajouter des règles de validation (modèle personnalisé en tête) ainsi que des opérations de mise à jour spécifiques au type système et personnalisées par l'utilisateur.
delete()
mixed - L'opération efface tout ou partie de l'information d'un objet dans le référentiel.
La demande comporte à minima l'identifiant de l'objet à lire. La destruction inclut une étape essentielle de validation de la demande, notamment pour contrôler l'état de l'objet et les droits de l'agent.
Le système procède à la destruction de l'information dans le référentiel des objets, à l'exception de l'information résiduelle à conserver. L'implémentation de la fonction de destruction par le type système, et notamment l'usage de capacités, peut ajouter des règles de validation, des opérations de destruction spécifiques au type système et personnalisées par l'utilisateur ainsi que l'élargissement de l'information résiduelle.