Partie 6: Décrire l’information

Partie 6: Décrire l’information


Aperçu de l’article

Notions clés

L’architecture d’information représente la définition des différents types et métadonnées présents dans un système. Elle est essentielle à tout système !
SharePoint propose plusieurs moyens pour mettre en place cette architecture. Cependant, des techniques comme l’UML ou Merise peuvent vous aider à occulter l’aspect technique et réaliser des architectures d’informations cohérentes et solides.

Type de contenu
Colonne de site
Taxonomie d’entreprise

 


Quels sont les types d’informations présents dans le besoin?

Il est ensuite question de définir la nature des données qui seront manipulées à travers la fonctionnalité que vous êtes en train de traiter. Dans le cas présent, il s’agit d’identifier les types d’informations qui seront manipulés à travers l’histoire utilisateur (l’élément du carnet de produit) sur laquelle vous travaillez (ici « Rechercher un projet »).

La question ici est de savoir quelles informations serons-nous appelés à manipuler dans le cadre de notre histoire et si celles-ci sont statiques ou dynamiques. En résumé, les informations qui nous intéressent sont le type, les regroupements et les métadonnées que l’on peut lui associer.

Information statique vs dynamique

Vous vous demandez peut-être la différence  entre une information statique et dynamique et la nécessité de les distinguer à ce niveau de la réflexion? En réalité, tout tourne autour de la RÉUTILISABILITÉ de l’information. Si une information présente sur une page n’est pas possiblement réutilisable ailleurs dans l’application (par ex. : un texte statique), alors c’est une information statique informelle qui n’a pas besoin d’être typée.

À l’inverse, si le même genre d’information est possiblement réutilisable dans le reste de l’application, il s’agit alors d’une information dynamique qui doit être identifiée de manière formelle dans l’application, et donc typée.

Identification des types

Le type de l’information ne correspond pas au type de fichier associé, mais doit plutôt être tiré du contexte d’affaire.

De même, dans la plupart des projets SharePoint, une erreur fréquemment commise est de considérer trop tôt l’emplacement de stockage (sites, bibliothèques ou listes). Cela peut biaiser votre réflexion. Il n’est pas important à ce stade de savoir où ces données seront stockées.

Gardez toujours à l’esprit que plus une information est typée et décrite, plus il sera aisé de la retrouver parmi les autres.

Un type d’information doit le plus possible représenter une référence au contexte d’affaires. En d’autres termes, il ne faut pas se limiter aux types par défaut dans SharePoint, qui ne représentent que des types de base.

A noter que la définition d’un type s’écrit toujours au SINGULIER.

Si nous prenons la maquette qui a été produite à l’étape précédente et que nous essayons d’identifier les types présents, voici ce que nous obtenons :

Identification visuelle des types d'informations

Pour le besoin de « Rechercher un projet », les types d’informations concernés seraient :

  • Des projets
  • Des documents de projets
  • Des membres de projet

Types d'information

Notez que je n’ai identifié ici que des types généraux liés à mon scénario. Il se peut que des types plus spécifiques soient présents. En effet, il y a des types que l’on peut deviner rien que par la maquette du besoin et d’autre uniquement en discutant avec le demandeur.

 C’est ici que peut intervenir la notion d’héritage entre types.

Hiérarchie des types

La hiérarchie de types permet de préciser un type général et d’en faire découler un type  plus détaillé. En effet, il se peut que des types puissent se « raffiner ».

Identifier une hiérarchie de types

C’est uniquement en dialoguant avec le demandeur que je pourrai récupérer cette information. Je ne schématise pas cette information pour le moment car nous verrons par la suite qu’une règle s’applique lorsque l’on rencontre ce cas de figure.

Identification des métadonnées

Les métadonnées permettent de décrire une information. Elles peuvent prendre différentes formes sous SharePoint. Pour le moment, nous ne nous soucions pas de l’implémentation ni de la portée de ces métadonnées (notion de réutilisabilité).

Si vous disposez d’une interface utilisateur pour le besoin sur lequel vous êtes en train de travailler, isolez ces métadonnées pour chaque type identifié. En d’autres termes, identifiez toutes les informations visibles à l’écran et associez-les à un des types déterminés précédemment.

Distinction entre type et métadonnée

Dans l’exemple précédent, nous pouvons remarquer les points  suivants :

  • Le demandeur nous a indiqué qu’il existait plusieurs types de projets.
  • La notion de « Type » est présente pour les documents de projets, elle peut prendre au moins deux valeurs : « Administratif » ou « Budget ».

La principale interrogation dans ces cas de figure est de savoir à quel moment créer une entité type en particulier plutôt qu’utiliser une métadonnée pour dissocier l’information.

Prenons l’exemple des documents de projet :

Héritage versus variable discriminante

 

  • Première solution : Distinguer deux types distincts pour les documents de projet. C’est le principe d’héritage vu plus haut.
  • Deuxième solution : Créer une métadonnée discriminante « Type » servant à distinguer le type du document de projet.

Pour déterminer la solution, j’utilise généralement la règle suivante. Je vous conseille de lire cette phrase bout par bout en vous appuyant sur le schéma ci-dessus :

 Règle:

Si l’information à détailler n’est pas susceptible de contenir d’autres métadonnées ET que c’est également le cas pour les informations qui sont issues du même type parent (« Document de budget », « Administratif » ou autre), alors on ajoute un champ discriminant dans l’entité parente (champ « Type » avec la valeur du type voulu « Administratif » ou « Budget »).

Sinon, on crée un nouveau type à part entière, même sans aucune métadonnée.

Je dirais même qu’en règle générale, il est préférable de créer de nouveaux types même si ceux-ci ne comprennent aucune métadonnée et ceci, pour des raisons d’évolutivité. Si, par exemple, vous décidez d’ajouter la métadonnée « Montant du budget » au type « Document de budget »,  vous ne pourrez pas le modéliser avec une approche par métadonnée discriminante.

Voici le schéma d’information de notre exemple après les étapes suivantes :

  1. Identification des types
  2. Définition de la hiérarchie des types
  3. Identification des métadonnées par type

Modèle relationnel après la définition de hiérarchie de types

Gestion des types dans SharePoint

Ces étapes réalisées, nous pouvons maintenant les traduire en SharePoint. Les notions clés à ce stade-ci de la méthodologie sont les types de contenu et les colonnes. C’est par ceux-ci que vous modélisez vos types d’informations dans SharePoint.

Tout élément stocké dans SharePoint possède un type racine de type « Document » ou « Élément ». Le premier représente un document physique, le deuxième, une information formelle.

 Il n’est donc pas possible d’appliquer des métadonnées générales à tous les éléments d’une application SharePoint à moins de les dupliquer dans les types racines.

Si maintenant nous devions traduire le schéma précédent en SharePoint (peu importe la version), nous obtiendrons le résultat suivant :

Héritage des types pour "Rechercher un projet"

Notez que si je voulais appliquer une métadonnée commune à tous les types présents dans le besoin, il me faudrait créer un type générique pour chacune des branches « Élément » ou « Document » imposée par SharePoint.


+ There are no comments

Add yours