conception et modélisation d'un système d'information

Conception et modélisation d'un système d'information

Formateur : Imad-Eddine GHAIBI

Conception et modélisation d'un système

d'information

1- Comprendre l’apport d’une méthode d’analyse dans un projet

informatique

a- Intérêt d’une méthode d’analyse

La méthode "Merise" est une démarche, pour la modélisation de systèmes d'information. Merise

sort du domaine de la technique informatique pour s'intéresser à la gestion de l'organisation

concernée.

Contexte: grands projets en informatique de gestion:

Conception et mise en œuvre de bases de données;

Conception et réalisation de programmes informatiques.

b- Définition d’une méthode

La conception d'un système d'information n'est pas évidente car il faut réfléchir à l'ensemble de

l'organisation que l'on doit mettre en place. La phase de conception nécessite des méthodes

s’appuyant sur un formalisme commun. La modélisation consiste à créer une représentation

virtuelle d'une réalité de telle façon à faire ressortir les points auxquels on s'intéresse. La

méthode Merise apporte en cela une réflexion systémique.

L’utilisation d’une méthode de conception permet de disposer d’un référentiel commun pour

représenter les objets du système d’information étudié. Cela facilite grandement les échanges, la

communication et l’approfondissement du questionnement.

c- Différentes méthodes d'analyse

L’utilisation d’une méthode permet d’éviter les faiblesses du langage nature: interprétation

spécifique de chacun, ambiguïté des propos, etc.

Toute méthode informatique doit répondre aux objectifs principaux:

Définir ce que l'utilisateur final veut informatiser (quitte à lui faire comprendre ce qu'il

veut), et sa faisabilité: vérifier la cohérence de sa demande;

Structurer les données à informatiser: primordial en informatique de gestion;

Rester simple: elle doit rester un outil d'aide à la conception ou à la réalisation.

Merise sert de langage de référence entre les différents acteurs, informaticiens et utilisateurs.

Elle représente, sous forme de représentations graphiques appelées modèles, les différents

concepts manipulés. Merise possède des modèles spécifiques.

d- Approche systémique

L’approche systémique propose d’envisager l’entreprise comme un système en interaction avec

d’autres systèmes. L’entreprise en interne pouvant encore être décomposée en sous-systèmes en

interaction.



Un système est un ensemble d’éléments en interaction dynamique, organisé en fonction d’un but.

Un système peut être défini comme un tout organisé de composants en interaction, nous avons :

Le monde des objets (composants);

Le monde des relations (interactions);

Le monde de la totalité.

2- Définition des notions fondamentales de la systémique:

Entreprise comme système

L’entreprise peut être représentée comme un ensemble de systèmes:

Système de pilotage;

Système d’information;

Système opérant.

Le système d’information permet de gérer les interactions entre les autres systèmes de

l'entreprise, et gérer les interactions de l’entreprise avec son environnement.

3- Identification des différents systèmes de l’entreprise

Le système de pilotage doit être décliné sur plusieurs niveaux depuis le plus stratégique jusqu’au

niveau opérationnel. Les systèmes opérant et pilotage s’appuient sur le système d’information qui

agit comme "middleware" entre ces deux systèmes. On peut considérer comme exemple:

ObjetObjet

RelationRelation

TotalitéTotalité

EnvironnementEnvironnement

SO

SP

SI

SO

SP

SI

ObjectifsObjectifs RapportsRapports

InformationsInformations

Flux

financiers

Flux

financiers

Matière premièreMatière première ProduitProduit



Un système information décisionnel qui produit des indications à destination du système

opérant pour le lancement de fabrication par exemple;

Le système opérant produit les pièces demandées et informe le système de pilotage des

conditions de réalisation (coût et les délais de fabrication);

Le système de pilotage recueille ces données sous forme synthétique et induit des

modifications au niveau du besoin suivant.

4- Intérêt d’un cahier de charges

a- Définition d’un cahier de charges

Le cahier des charges est un document qui doit être respecté lors de la réalisation d'un projet.

Il sert à formaliser les besoins et à les expliquer aux différents acteurs pour s’assurer que tout

le monde soit d’accord. Il permet notamment de cadrer les missions des acteurs impliqués, dont

celles du directeur de projet (côté maîtrise d’ouvrage) et/ou du chef de projet (côté maîtrise

d’œuvre). Il sert ensuite à sélectionner le prestataire ou soumissionnaire (dans le cas d'un appel

d'offres), et à organiser la relation tout au long du projet. Il est considéré comme un référentiel

partagé par le prestataire et l’équipe interne, et décliné dans les documents contractuels. Vers

l’externe, c'est en outre un outil fondamental de communication du directeur de projet et/ou du

chef de projet.

b- Structure d’un cahier de charges

Il n’y a pas de plan type pour rédiger un cahier des charges. Structure, précision et longueur

dépendent de l’importance, de l’objet et du contexte du projet. Néanmoins, même si la

présentation et l’ordre peuvent varier, plusieurs éléments doivent nécessairement y figurer:

Etude de l’existant: présentation générale de l’établissement et étude de l’environnement;

Analyse des besoins: description des besoins de l’établissement et définition de l’objectif

du projet;

Description de la solution: caractéristiques fonctionnelles et réponse opérationnelle

souhaitée (le prestataire peut avoir la liberté de proposer toute solution technique à partir

du moment où les contraintes informatiques de l'établissement sont respectées, s’il y en a);

Définition de la procédure: découpage en lots ou phases et description des conditions

commerciales.

c- Intérêt d’un cahier de charges

Le projet informatique fait partie de la vie d’un service de documentation. Qu’il s’agisse de la

mise en place de son système de gestion documentaire ou de son remplacement, de la création

d’un site Web ou d’un portail, de l’intégration des ressources numériques, d’un projet d’édition ou

de numérisation, le professionnel de l’information doit savoir préparer une telle démarche,

choisir le prestataire, vérifier le résultat. Pour réussir, tout projet doit suivre une logique dans

laquelle le cahier des charges tient un rôle particulier:

Définir les objectifs que doit atteindre la solution;

Indiquer les contraintes à respecter impérativement;

Etre un outil de dialogue entre les différents acteurs;

Diminuer les risques d’erreur lors de la réalisation ou l’installation.



A- Analyse du cahier des charges

1- Exemple de cahier des charges à partir d’une étude de cas

Soit un service d’achat d’un magasin spécialisé dans la vente de matériel informatique. Le service

achète des articles à un prix défini par les fournisseurs. Le contact des fournisseurs se fait soit

par appel téléphonique soit par leurs adresses. Chaque commande faite sur les articles est

enregistrée avec un numéro et une date. Une commande peut avoir plusieurs types d’articles. Les

conditions de paiement et les conditions de livraison des commandes dépendent de plusieurs

facteurs qui correspondent à la nature des articles inclus dans les commandes, et déterminent le

taux TVA à accorder afin de calculer le prix de la commande. Chaque article a une référence, une

désignation, un prix unitaire et le nombre d’unités en stock.

5- Intérêt du dictionnaire des données et des règles de gestion

a- Définition des règles de gestion à partir des éléments techniques

décrits dans le cahier des charges

Avant de se lancer dans la conception, il faut recueillir les besoins des futurs utilisateurs de

l’application. Et à partir de ces besoins, il faut être en mesure d'établir les règles de gestion des

données à conserver. Pour l’étude de cas précédente les règles de gestion fixées sont:

Pour chaque fournisseur on doit conserver le numéro de téléphone et l’adresse.

Pour chaque commande on doit l’identifier par un numéro de commande et conserver sa

date de commande.

Une commande peut avoir un ou plusieurs articles.

Pour chaque article on doit l’identifier par sa référence, et conserver sa désignation, son

prix unitaire et sa quantité en stock.

Ces règles sont parfois données mais le concepteur peut être amené à les établir lui-même dans

deux cas:

Le concepteur est à la fois maîtrise d'œuvre et maîtrise d'ouvrage, et il développe une

application pour son compte et/ou selon ses propres directives.

Ce qui arrive le plus souvent: les futurs utilisateurs du projet n'ont pas été en mesure de

fournir ces règles avec suffisamment de précision; c'est pourquoi il faut les interroger

afin d'établir ces règles. En tant que développeur, on a un devoir d'assistance à maîtrise

d'ouvrage si cela s'avère nécessaire.

b- Définition du dictionnaire de données

Cette étape consiste à référencer toutes les données du domaine. Pour le service d’achat, on

peut recenser un certain nombre d’éléments:

Nom du fournisseur

Date de la commande

Numéro de la commande

Référence de l’article

Prix unitaire de l’article

Désignation de l’article

Quantité commandée



Condition de paiement

Condition de livraison

Téléphone du fournisseur

Adresse du fournisseur

Unité de l’article

Taux de TVA

Prix de la commande

Lors de l’établissement du dictionnaire, il peut s’y glisser des termes qui ne qualifient pas

nécessairement des données. Il peut s’agir de traitements de données ou des flux d’information.

Certaines expressions peuvent être polysémiques: elles recouvrent plusieurs sens, comme ici les

conditions de paiement. D’autres expressions peuvent être synonymes. Ces problèmes peuvent

être réglés dans les étapes suivantes de création du Modèle Conceptuel de Données (MCD).

6- Formalisme de la méthode d'analyse pour les Données

Le Modèle Conceptuel de Données ou MCD est le plus connu et le plus utilisé des éléments de la

méthode Merise. Il permet une représentation claire des données et des liens entre les données

du domaine étudié. Un MCD a plusieurs buts:

C’est un outil de communication: communication avec le donneur d’ordre, à l’intérieur d’une

équipe de développement, avec les utilisateurs, … ;

C’est un outil de normalisation : passage de règles implicites et orales à des règles de

gestion écrites.

La réalisation d’un MCD peut se dérouler en trois étapes. On va aborder ces étapes au travers

d’une étude de cas simple. Le domaine étudié est un service d’achat.

a- Propriété

Chaque terme du dictionnaire des données est appelé "propriété". L’étape suivant consiste à

regrouper les propriétés dans des "entités".

b- Entité

Dans notre cas, trois entités semblent se dégager:

L’entité Fournisseur

L’entité Article

L’entité Commande

Une fois ces entités définies, on leur associe les propriétés du dictionnaire des données.

F Nom du fournisseur

C Date de la commande

C Numéro de la commande

A Référence de l’article

A Prix unitaire de l’article

A Désignation de l’article

Quantité commandée

Condition de paiement

Condition de livraison

F Téléphone du fournisseur



F Adresse du fournisseur

A Unité de l’article

Taux de TVA

Prix de la commande

Fournisseur

NomAdresse

Téléphone

Article

RéférencePrixDésignationUnité

Commande

DateNuméro

Une propriété ne peut être dans plusieurs entités. Par exemple, le prix d’un article est une

propriété de l’entité Article. Mais dans la mesure où ce prix est négocié en fonction de la

commande, il sera nécessaire de disposer de deux propriétés prix: une propriété Prix Article

dans l’entité Article et une propriété Prix Commande dans l’entité Commande.

On se rend compte que certain éléments du dictionnaire de données ne figurent pas dans les

entités. Ceci peut être dû à plusieurs causes:

Certains éléments ne sont pas des données. C’est le cas des conditions de paiement. En

effet, ces conditions peuvent être le résultat d’un calcul dépendant de la quantité

commandée, du délai de livraison, …

Certains éléments ne sont pas dans le domaine étudié.

Certains éléments peuvent être calculés à partir de données existantes. Par exemple: le

prix de la commande peut être calculé à partir de la somme des prix unitaires des articles

commandés multipliés par leurs quantités commandées.

Certains éléments peuvent être des propriétés d’entités que l’on n’a pas encore créées ou

ils qualifient une relation entre entités. Par exemple la quantité commandée ne peut être

une propriété de l’entité Commande que si une commande ne fait l’objet que d’un seul

article, ce qui est un cas particulier. Généralement une commande comporte plusieurs

articles et il faudrait créer les propriétés Quantité 1, Quantité 2, Quantité 3, … mais

notre commande serait toujours limitée à un nombre N (ici 3) d'articles.

Commande

DateNuméroQuantité 1Quantité 2Quantité 3

Commande

DateNuméro

Quantité

c- Identifiant

La prochaine phase est précisément la création de relation entre les entités. Pour terminer la

création des entités, il faut que chaque entité ait un identifiant. Un identifiant permet de

discriminer chaque occurrence d’une entité. Tout identifiant aura donc une valeur unique. Par

exemple, pour l’entité Article, l’identifiant est la Référence d’un article car deux articles

différents ne peuvent avoir la même référence.

Référence Prix Désignation Unité

01A12 3590.00 Ordinateur 2

01R11 345.00 Imprimante 5

Une occurrence de l’entité Article est comme: 01A12, 3590.00, Ordinateur, 2.



Pour distinguer les identifiants des autres propriétés, on a l’habitude de souligner la propriété

constituant l’identifiant de l’entité.

Fournisseur

NomAdresse

Téléphone

Article


Commande

DateNuméro

d- Relation

Une relation est un lien entre différentes entités. Ces liens se réalisent en se posant la question:

quelle entité interagit sur cette ou ces entités.

Par exemple, un fournisseur fournit un article et un article est fourni par un fournisseur. Il y a

interaction entre les entités Fournisseur et Article que l’on traduit par l’action de Fournir.

Fournisseur

NomAdresse

Téléphone

Article


Fournir

De même, une commande comporte des articles et les articles appartiennent à une commande. La

relation entre les entités Commande et Article est l’action de Commander.

Fournisseur

NomAdresse

Téléphone Article


Fournir

Commande

DateNuméro

Commander

Une relation peut avoir des propriétés. C’est le cas ici de la propriété Quantité qui est une

propriété de la relation Commander. De même la possibilité pour les relations d’avoir des

propriétés va nous permettre de créer de nouvelles données pour lever l’ambiguïté de la

propriété Prix.

Remarque: Une relation peut être réflexive, binaire, ternaire…



e- Cardinalité

Les valeurs (0,n) ou (1,n) sont des cardinalités. Les cardinalités expriment le nombre minimum et

maximum de fois qu’une entité est concernée par la relation.

Par exemple la cardinalité (1,n) de l’entité Fournisseur pour la relation Fournir signifie qu’un

fournisseur peut fournir au moins un article et au plus n articles. De même la cardinalité (1,n) de

l’entité Article pour la relation Fournir signifie qu’un article est fourni par au moins un

fournisseur et au plus N fournisseurs.

Plus intéressant est de constater que la relation Commander résout le problème évoqué lors de la

création des entités et du rattachement de la donnée Quantité à l’entité Commande. La

cardinalité (1,n) de l’entité Commande pour la relation Commander signifie qu’une commande peut

avoir au moins un article et au plus N.

Si nous reprenons notre dictionnaire de données nous avons:

F Nom du fournisseur

C Date de la commande

C Numéro de la commande

A Référence de l’article

A Prix unitaire de l’article

A Désignation de l’article

CA Quantité commandée, propriété de la relation entre Commande et Article

(Condition de paiement: traitement)

Personne Livre

posséder

acheter

Lire

Magasin

épouser

binaire

3-aire

réflexive



(Condition de livraison : traitement)

F Téléphone du fournisseur

F Adresse du fournisseur

A Unité de l’article

CA Taux de TVA, propriété de la relation entre Commande et Article

(Prix de la commande: traitement)

B- Modéliser les données

Un MCD ne peut être unique et varie nécessairement en fonction de règles de gestion et de

choix du concepteur.

C- Normaliser les données

La normalisation des modèles de données permettra donc de s’assurer de la robustesse de la

conception de la base pour améliorer la modélisation (et donc obtenir une meilleure

représentation) et optimiser la mémorisation des données en évitant la redondance et les

problèmes sous-jacents de mise à jour ou de cohérence.

1- Première forme normale (1FN)

Respecte la première forme normale, la relation dont tous les attributs:

Contiennent une valeur atomique (les valeurs ne peuvent pas être divisées en plusieurs

sous-valeurs dépendant également individuellement de la clé primaire). Ainsi, le nom et le

prénom d’une personne doivent être dans des propriétés distinctes.

Contiennent des valeurs non répétitives (le cas contraire consiste à mettre une liste dans

un seul attribut). On pourrait citer pour exemple une catégorie d’articles qui doit être

définie dans une entité spécifique et non répétée dans l’entité article

Sont constants dans le temps (utiliser par exemple la date de naissance plutôt que l'âge).

Le non respect de deux premières conditions de la 1FN rend la recherche parmi les données plus

lente parce qu'il faut analyser le contenu des champs. La troisième condition quant à elle évite

qu'on doive régulièrement mettre à jour les données.

2- Deuxième forme normale (2FN)



Respecte la seconde forme normale, la relation respectant la première forme normale et dont

tous les attributs non-clés ne dépendent pas d'une partie de la clé primaire mais bien de la

totalité de la clé primaire.

Le non respect de la 2FN entraine une redondance des données qui encombrent alors inutilement

la mémoire et l'espace disque.

3- Troisième forme normale (3FN)

Respecte la troisième forme normale, la relation respectant la seconde forme normale et dont

tous les attributs n'appartenant pas à la clé ne dépendent pas d'un attribut non-clé. En d'autre

terme, la dépendance fonctionnelle est directe.

4- Règles de vérification

Règle 1: Construction du dictionnaire des données.

Lister les attributs par entité et par relation;

Faire la chasse aux synonymes (Code Client et Numéro Client) et aux polysémies (termes

qui causent une ambiguïté).

Règle 2: Un attribut n’appartient qu’à une seule entité ou une seule association.

Règle 3: Sur une entité ou une relation, il ne peut y avoir qu’une valeur prise par tout attribut

(faire la chasse aux entités cachets).

Règle 4: Toutes les propriétés d’une entité ou d’une relation doivent avoir un sens pour toutes

les occurrences de l’entité ou de la relation. Il ne faut confondre ce cas avec celui où la valeur

d’une propriété n’est pas connue à un instant donné.



Règle 5: Tout attribut doit dépendre uniquement et totalement de l’identifiant.

Règle 6: Il faut s’assurer que tous les attributs portés par une association ont besoin de toutes

les pattes pour être définies.

5- Règles de passage du MCD au MLD (Modèle Logique de

Données) Normalisé

Toute entité devient une table. Ses propriétés deviennent des attributs de la table (colonne).

L’identifiant devient la clé primaire unique de la table.

a- Transformation d’une relation binaire (*,*)-(1,1)

On duplique la clé issue de l’identifiant de l’individu porteur de la cardinalité (0,1), (0,n) ou (1,n)

dans la table issue de l’individu à cardinalité (1,1). Celle-ci devient alors une clé étrangère.

Table

Clé_Primaire

Attribut1

…



b- Transformation d’une relation binaire (*,n)-(0,1)

Deux solutions:

Création d’une table avec comme clé primaire l’identifiant de l’individu porteur de la

cardinalité (0,1) et comme clé étrangère l’identifiant de l’individu porteur de la cardinalité

(*,n).

Duplication de l’identifiant de l’individu porteur de la cardinalité (*,n) dans la table issue de

l’individu porteur de la cardinalité (0,1) qui devient alors une clé étrangère (Attention : La

clé étrangère pourra avoir des valeurs nulles !).

Entité1

Identifiant_Entité1

Propriété1_Entité1

…

*,*

1,1

Relation

Entité2



…

Table1

Clé_Primaire_Table1

Attribut1_Table1

…

Table2


Attribut1_Table2

…

Clé_Etrangère_Table1

Entité1



…

*,*

0,1

Relation

Entité2



…

Table1


Attribut1_Table1

…

Relation



Table2


Attribut1_Table2

…

Table1


Attribut1_Table1

…

Table2


Attribut1_Table2

…




c- Transformation d’une relation binaire (0,1)-(0,1)

Deux solutions :

Créer une table avec comme attributs les identifiants des individus en relation et comme

clé primaire l’un des identifiants d’une des deux tables. Les deux attributs sont des clés

étrangères.

Duplication de la clé d’une des deux tables issues des entités types dans l’autre table.

d- Transformation d’une relation quelconque (*,n)-(*,n)

La solution consiste à créer une table dont la clé sera une clé composée des identifiants des

entités en relation. Les propriétés éventuelles de la relation seront des attributs de la table.

Entité1



…

*,*

0,1

Relation

Entité2



…

Table1


Attribut1_Table1

…

Table_Relation



Table2


Attribut1_Table2

…

Table1


Attribut1_Table1

…

Table_Relation



Table2


Attribut1_Table2

…

Table1


Attribut1_Table1

…

Table2


Attribut1_Table2

…


Table1


Attribut1_Table1

…


Table2


Attribut1_Table2

…



Exercice 1: Système de facturation.

Une entreprise de vente par correspondance désire ajouter à son site un système de facturation

visible en ligne pour ses clients. Chaque client, après authentification, pourra accéder à toutes

les factures le concernant, qu'elles soient anciennes ou en cours de traitement indifféremment.

Un client obtient une facture qui contient des articles en certaine quantité. Un client est

caractérisé par son Nom, son Prénom, son Adresse, son Code Postal et sa Localité. Afin de

pouvoir s'authentifier, il est aussi caractérisé par un Login et un mot de passe. Une facture est

caractérisée par son Numéro, et sa Date d'émission. Un article est caractérisé par son Numéro,

son libellé, et son Prix Unitaire. Le prix total, de par son Prix Unitaire et sa quantité, peut être

recalculé: ce n'est donc pas une caractéristique de l'article.

Exercice 2: Gestion des Dossiers Comptables d’un Centre de Gestion.

On se situe dans un centre de gestion comprenant plusieurs agences délocalisées. Dans chaque

agence travaillent plusieurs comptables, chacun gérant plusieurs exploitations. Un comptable ne

travaille que dans une seule agence et une exploitation ne peut être gérée que par un seul

comptable. On souhaite connaître la liste des exploitations gérées par chacun des comptables et

chacune des agences. Les informations retenues sont :

Le nom de l’exploitation et la commune où se situe l’exploitation,

Le nom du comptable,

Le directeur de l’agence, la commune de l’agence et le nom de l’agence,

Entité1



…

*,n

*,n

Relation

Propriété1_Relation

...

Entité2



…

Entité3



…

Table_Relation




Propriété1_Relation

...

Table1


Attribut1_Table1

…

Table2


Attribut1_Table2

…

Table3


Attribut1_Table3

…

*,n



L’âge du comptable et son numéro de téléphone.

Exercice 3: Gestion des abonnements.

Un abonné est inscrit à une ou plusieurs rubriques. Chaque rubrique envoie une Newsletter

chaque semaine aux abonnés de la rubrique correspondante. Un abonné a une motivation

d’inscription parmi plusieurs possibles. Un Abonné est caractérisé par son nom, son prénom, son

âge, sa profession, sa rue, son code postal, sa ville, son pays, son téléphone et son email.

Une Newsletter est caractérisée par son sujet, sa date d’envoi et son contenu. Une Motivation

est caractérisée par son intitulé. Une Rubrique est caractérisée par son nom.

Exercice 4: Catalogue de produits.

Un garagiste expose sur le Web ses modèles, afin de présenter ses nouveautés et surtout son

stock en temps réel (disponibilité de ses modèles). Il utilise ce que l'on appelle un catalogue, avec

navigation par catégorie/sous-catégorie, affichage de la fiche-produit de la voiture, et

possibilité de recherche par marque de véhicule. Il limite sa fiche produit au nom, au prix, et à la

disponibilité de la voiture. Ce qui donne : Un Produit possède 1 ou plusieurs Créateurs (marques ou

fabricants). Un Créateur fabrique 0 ou plusieurs Produits. Ces Produits appartiennent chacun à

une et une seule Catégorie. Chaque Catégorie contient 0 ou plusieurs Produits. Enfin, une

Catégorie peut avoir 0 ou plusieurs sous-Catégories, chaque Catégorie ayant 0 ou une Catégorie

parente.

Exercice 5: Gestion des Logements dans une Agence Immobilière.

Une agence de location de maisons et d’appartements désire gérer sa liste de logements. Elle

voudrait en effet connaître l’implantation de chaque logement (nom de la commune et du quartier)

ainsi que les personnes qui les occupent (les signataires uniquement). Le loyer dépend d’un

logement, mais en fonction de son type (maison, appartement, bureau, ...). L’agence facturera

toujours en plus du loyer la même somme forfaitaire à ses clients (par exemple, le prix d’un

studio sera toujours égal au prix du loyer + 300 Dh de charges forfaitaires par mois). Pour

chaque logement, on veut disposer également de l’adresse, de la superficie ainsi que du loyer.

Quant aux individus qui occupent les logements (les signataires du contrat uniquement), on se

contentera de leurs noms, prénoms, date de naissance et numéro de téléphone. Pour chaque

commune, on désire connaître le nombre d’habitants ainsi que la distance séparant la commune de

l’agence. On ne gérera pas l’historique de l’occupation des logements par les individus. On

considèrera de plus qu’un individu ne peut être signataire que d’un seul contrat.

conception et modélisation d'un système d'information

Documents