Phase de conception

Choix des données et Identification des acteurs

Déterminer les données de l'annuaire

Après la phase de cadrage, la première étape de la phase de conception consiste à énumérer les données présentes dans l'annuaire. Il s'agit d'énumérer de manière exhaustive d'une part toutes les classes d'objets amenées à peupler l'annuaire, et d'autres parts, pour chaque classe, quelles sont ses propriétés gérés par l'annuaire.

Pour chaque type de données, en procédant par classes d'objets puis par propriétés si nécessaire, il faut alors déterminer les informations suivantes:

  • Quelles sont les personnes ou les applications manipulant cette donnée? On se contentera dans un premier temps d'une réponse sommaire, sachant qu'une réponse plus complète - par type d'action - sera donnée par la suite.

  • Quelle est la ou les sources actuelles de cette donnée? Est-elle déjà sous forme numérique ou pas encore? Est-ce une donnée statique ou dynamique? Est-elle calculée?

  • Quelle est le type de cette donnée (chaîne de caractères, entier, data, etc)?

    Quelle est son format: la chaînes est-elle encodée en utf8 ou unicode? Quel format de date est utilisé?

    Sa taille?

  • Quelle est la pérénité de la donnée? Sa fréquence de mise à jour? Cette mise à jour est-elle automatique ou manuelle?

Cas d'utilisation

Une fois les données de l'annuaire bien définies, il faut détailler leur utilisation. Pour y parvenir de façon convenable il est utile d'employer la même méthode que lorsqu'on décrit des cas d'utilisation, en eXtrem Programming et en modélisation UML.

Bien que les cas d'utilisation soient centrés sur les utilisateurs, il faudra, dans notre travail, énumérer aussi les actions des applications externes à l'annuaire mais qui l'utilisent.

Pour chaque donnée contenue dans l'annuaire il faut donc noter qui effectue les actions suivantes:

  • Recherche.  Une recherche s'effectue sur certains attributs. Pour chaque objet, dans chaque cas d'utilisation, il faudra donc noter les attributs sur lesquels la recherche s'effectue.

  • Lecture.  Là encore il faut tenir compte des attributs. Les cas d'utilisation devront contenir l'information «de quel attribut a besoin de lire telle personne sur tel objet.»

  • Création.  Lors du processus de création des objets dans l'annuaire, il faudra valider que la personne, ou l'application, qui créée un objet, a bien connaissance de toute l'information nécessaire. Il peut arriver que cela ne soit pas le cas.

    Par exemple, une personne du département ressources humaine ne pourra pas d'elle même assigner un login à un utilisateur dans l'annuaire. Il faut prévoir un mécanisme, en dehors de l'annuaire, qui lui fournisse cette information qui se peut se révéler nécessaire dans certains cas.

  • Modification. Dans l'écriture des cas d'utilisation comprenant des modifications, il est nécessaire de noter quels attributs sont modifiés, et de quel type de modifications il s'agit: ajout d'une valeur, retrait d'une valeur, modification de toutes les valeurs, etc.

  • Suppression. 

    Avertissement

    LDAP ne contient pas l'équivalent de clé étrangère pour contrôler la cohérence des données de l'annuaire.

Les cas d'utilisation peuvent dans un premier temps être effectués sur les classes, sur les catégories d'objets présents dans l'annuaire. Il sera parfois nécessaire de descendre à un niveau de précision inférieure et d'écrire les cas d'utilisation par attribut, ou par groupes d'attributs.

Il sera aussi utile noter la fréquence de chaque cas d'utilisation.

Élaboration du schéma

Cette étape s'appuie essentiellement sur l'étape précédente du choix des données contenues dans l'annuaire. Elle consiste à écrire un schéma qui modélise ces données.

Écrire un schéma c'est essentiellement définir

  • les attributs
  • les classes
  • la hiérarchie entre ces classes

des objets qui constitueront l'annuaire.

De la liste des données, il faut extraire les informations élémentaires, sous la forme d'une liste d'attributs, et d'une liste de classes, celles-ci étant définies en regroupant les attributs. Notre méthode consistera à définir et modéliser les attributs, indépendamment des classes, les attributs étant partagés entre classes; puis à constituer les classes d'objet en agrégeant les attributs adéquats.

Entre la définition des classes et celle des attributs, il peut y avoir une démarche itérative. Ainsi certaines informations élémentaires changeront de statut au cours de la modélisation. Par exemple la catégorie d'une personne pourra être une classe, plutôt qu'un attribut, parce que l'appartenance d'une personne à une catégorie implique la présence obligatoire d'autres attributs.

Lors de la définition des attributs comme celles des classes, il faut penser à utiliser la relation d'héritage, lorsque des caractéristiques sont partagées et qu'il existe des liens de spécialisations, entre attributs ou entre classes.

En reprenant ce qui a été écrit précédemment, définir un attribut consiste à définir:

  • son nom;
  • s'il est standard, issu d'une RFC, public, déjà créé et publié, ou encore spécifique, spécialement créé;
  • son attribut père, s'il dérive d'un autre attribut
  • sa syntaxe: est-ce une chaîne de caractères? un pointeur vers une autre entrée de l'annuaire? etc.
  • s'il est mono ou multivalué;
  • par quelle(s) classe(s) il est utilisée;
  • sa fréquence d'utilisation.

Une erreur classique

Il peut arriver que l'on ait distingué des attributs contenant exactement le même type d'information parce qu'ils étaient attributs de classes différentes. Cette différenciation n'a pas lieu d'être. Au contraire, il est plus logique d'avoir un même attribut utilisé par plusieurs classe.

De façon similaire, la définition des classes d'objets consiste à préciser:

  • son nom;
  • si elle est standard, issue d'une RFC, publique, ou spécifique;
  • sa classe mère, si elle dérive d'une autre classe;
  • la liste des attributs obligatoires;
  • la liste des attributs facultatifs;