Méthodologie

Analyse

Lorsqu'un concepteur de base de donnée se lance dans la création d'un schéma de données, il va faire une réflexion sur les informations et leur place "logique" avant de faire une "mise en contexte technique". Pour créer des modèles Scenari, il est important de se représenter la structure globale du modèle avant de passer à la conception dans SCENARIbuilder. Mais étant donnée que la conception de modèles de documents est un domaine assez nouveau et que Scenari offre un champ de possibilités très ouvert, nous n'avons pas encore de méthode miracle, de règles de modélisations que nous pourrions vous "imposer". Cette partie d'analyse est donc plutôt à voir comme un ensemble non exhaustif de pistes ou d'idées.

Etude du domaine

Documentez vous sur le thème de votre modèle. Vous devez devenir un "expert" des planètes et de tout ce qui se trouve dans l'univers pour pouvoir être à l'aise avec les choix de modélisation de ces données. Soyez attentif aux informations de ces documents à modéliser : y a-t-il souvent des parties de textes qui ont le même type de contenu pour toutes les planètes ? devant une masse très volumineuse d'information, lesquels doivent être présent sur vos documents et lesquels ne vous intéressent pas ? Partir de documents existants est une source d'inspiration très précieuse.

Identifiez les données

A partir de votre étude, identifiez les "objets" à utiliser, la structure générale de vos données. Soyez raisonnable et n'hésitez pas à simplifier quand vous le pouvez. Dans notre cas par exemple, nous avons différents types de corps célestes mais avons-nous besoin de les distinguer par 2 types d'objet différents ? Lors de la rédaction, l'auteur a-t'il besoin d'avoir des types de parties très différentes dans le cas d'une étoile ou dans le cas d'une planète ? doit-on créer un type d'item spécifique pour les "planètes naines" ? Nous allons choisir la solution la plus simple : le même type d'item est utilisé par l'auteur pour les étoiles, les planètes et les planètes naines : la structure sera la même mais à l'intérieur du contenu, rien ne nous empêche de prévoir un moyen pour l'auteur de spécifier le type de l'astre. Il n'y a pas de bonne réponse ou de mauvaise, c'est vraiment fonction des besoins.

Autre question à se poser : doit-on créer des objets comme les galaxies ou les systèmes ? Raisonnablement, nos auteurs n'ont pas trop de connaissances à capitaliser pour des planètes en dehors du système solaire, donc nous allons nous limiter à celui-ci dans un premier temps et nous n'avons pas besoin de représenter ces éléments. Si nous avions à placer d'autres étoiles, il serait intéressant de séparer les astres du système solaire des autres, donc d'adopter une structure en galaxie / systèmes.

Par contre, nous décrivons plusieurs planètes et il leur faut impérativement un conteneur, nous allons les placer dans une racine "univers".

Quelques exemples de structures possibles, nous choisissons la première qui offrira largement assez de complexité à cet exemple.

A l'intérieur de Scenari, vous serez peut-être amené à découper ces "objets" en plusieurs .model SCENARIbuilder mais vous avez déjà préparé cela par l'étape "abstraite" du travail.

Le contenu des objets

L'univers contient des planètes, nous ne lui associerons pas d'autres données.

Chaque astre est associé à une série d'informations précises :

nom
photo
nature
la liste de ses satellites et leur distance orbitale
diamètre
masse
période de rotation
période sidérale

Ensuite, nous allons ajouter du contenu textuel sous forme de paragraphe pour décrire les planètes. Question à se poser sur les paragraphes : peut-on les pré-définir (forcer un titre ? un ordre ?) ou est-ce à l'auteur de les écrire librement. Les choix suivants s'offrent a nous :

Liberté total de l'auteur sur les paragraphes : on laisse choisir à l'auteur le rôle de chaque paragraphe et leur nombre sans lui proposer des parties spécifiques.
Sans ordre précis, parties libres et éventuellement parties prédéfinies : l'auteur crée des parties comme bon lui semble, mais il peut utiliser certaines parties avec un rôle prédéfini.
Parties prédéfinies en ordre fixe + parties libres : on spécifie d'avance les rôles de 4 paragraphes et l'auteur peux en ajouter librement a la fin.
Restriction total des parties : nous créons et choisissons d'avance les rôles de 4 paragraphes (avec un titre par défaut ou même un titre fixe).

Essayant d'identifier les besoins de nos auteurs, nous allons identifier 4 parties qui reviennent couramment : introduction, atmosphère, surface, noyau. Mais chaque planète à des particularités que l'auteur peut souhaiter décrire dans des paragraphes qu'il crée lui même et dont on ne peut pas forcément anticiper le rôle. Nous retenons donc la 3ème solution.

Schéma du modèle

Nous allons au fil de ce tutoriel construire un réseau de fichiers .model respectant ce schéma (en plus des autres items ici masqués par soucis de simplifications). Nous avons vu que l'on pouvait décomposer notre domaine en objets, mais aussi identifier des types de parties répétés à l'intérieur d'un modèle ou les re-décomposer, ce qui explique ce niveau de supplémentaire en dessous de astreobj.model.

Remarques

Ne pas commencer par trop compliqué

Lorsque vous faites un document, déterminez les concepts qui peuvent être mis en commun : par exemple, pour nos 4 parties "introduction, atmosphère..." , leur structure est identique. Il ne faut donc pas faire 4 .model différents pour représenter chacun, mais un .model global qui va couvrir les 4 cas d'usages.

Les autres notions

Il vous faudra découvrir quelques autres notions de modélisation mais cette analyse peu se poursuivre. L'objectif étant d'anticiper le plus possible les difficultés, si vous maîtrisez bien SCENARIbuilder et que vous savez ce que vous voulez, vous pouvez vous en sortir en continuant les essais dans SCENARIbuilder. Mais si vous concevez un modèle en fonction des besoins d'un tiers sur un sujet que vous connaissez mal, il vous faudra être bien plus spécifique dans les questions que vous allez lui poser, et obtenir des indications comme les types de donnée, le format des ressources, leur hiérarchie...

Il y a ensuite plein de choix facilement modifiables par la suite, comme autoriser ou interdire l'internalisation, modifier un nom de champ, donc même si c'est plus simple de faire bien du premier coup, ne soyez pas trop angoissé par des détails.

Méthodes de schématisation

Les schémas fournis dans ce guide ont un rôle de démonstration, il est aussi possible de faire des diagrammes "type UML" Scenari pour représenter le modèle avec plus d'informations. Il n'existe pas encore d'outil pour les générer automatiquement à partir d'un modèle SCENARIbuilder (et encore moins de générer un modèle SCENARIbuilder à partir d'un schema !). Notez qu'il est tout de même possible d'exporter la DTD du modèle sous forme de schéma RelaxNG (créer un item -> wspRelaxNg). Pour l'instant il n'y a pas de méthode de représentation de modèle qui nous satisfait totalement, mais pas non plus une sensation de besoin pour les modélisateurs déjà formés à passer systématiquement par ce type d'outils.