La composition exprime une association forte qui fait en sorte que lorsque l'élément conteneur est détruit ses éléments composites sont également détruits.

Il implique toujours une multiplicité de 1 ou 0..1, car un seul objet conteneur peut avoir la responsabilité d'un autre objet composite.

Représente le modèle logique du système d’information.

• Cercle ou rectangle aux coins arrondis représente le traitement/processus
• Flèche représente le flux de données
• Rectangle ouvert à droite représente un dépôt de données
• Rectangle complet représente la source, destination ou les deux, ou un agent externe

1. Un traitement reçoit toujours au moins un flux entrant et produit toujours au moins un flux sortant.
2. Chaque flux passe par un traitement.
3. Un flux de données doit être identifié par un nom unique.

Une entité externe est une personne, groupe ou organisation qui fournit ou reçoit de l’information.

On distingue plusieurs niveaux de diagramme de flux de données (DFD).

1. Diagramme de contexte :
   • Contient un seul traitement
   • Identifie toutes les sources et destinations.
   • Identifie tous les flux de données entrant et sortant des sources et destinations.
   • Normalement sans dépôt de données.
2. DFD de niveau 1 :
   • C’est une explosion du diagramme de contexte : on décompose les traitement du diagramme de contexte pour décrire les détails de ce traitement.
   • Tous les flux de données qu’un traitement reçoit ou produit doivent être présents au niveau inférieur lors de la décomposition.
   • Les traitement de ce niveau sont numérotés 1, 2, 3, …
   • Les symboles d’une source, destination ou dépôt de données peuvent être dupliqués.
3. DFD de niveau 2 :
   • On décompose les traitements du DFD de niveau 1 qui ne sont pas suffisamment détaillés. On y inclut les contrôles et les exceptions (cas particulier). Il n’est pas nécessaire d’indiquer les sources et destinations mais il faut indiquer les flux qui y entrent et sortent.

1. Il est simple parce qu’il ne comporte que quatre symboles;
2. Il offre la possibilité de présenter des activités parallèles;
3. Il est indépendant du matériel utilisé pour traiter les données;
4. Il permet d’impliquer les utilisateurs qui en examinant les diagrammes peuvent détecter rapidement des problèmes et exprimer leurs besoins;
5. Avec l’approche « Top-down » ou descendante, il permet d’isoler certains domaines de l’entreprise et de les étudier plus en détail.

1. Identifiez les entités externes concernées, les inputs et les outputs; Les flux de données sont créés lorsqu’il se passe un événement à l’extérieur. Par exemple, un client achète un article, un étudiant demande de s’inscrire à un cours, un camion livre la marchandise, un fournisseur envoie une facture à payer, la direction demande un rapport des ventes.
2. Identifiez les différentes étapes qui sont nécessaires à l’exécution de l’activité; Pour déterminer les étapes, suivez le cheminement d’une activité et demandez : « Que se passera-t-il après pour cette étape de l’activité? ». Au fur et à mesure que la liste augmente, essayez de trouver les tâches qui concernent uniquement les procédures de traitement d’erreurs et d’exceptions.
3. Identifiez, pour chacune de ces étapes, les données nécessaires et les informations produites, c’est-à-dire les flux de données qui entrent et ceux qui sortent;
4. Prenez une grande feuille de papier et dessinez à main levée le premier brouillon; Commencez par dessiner le cadre en laissant de l’espace de chaque côté pour les entités externes. Donnez un nom à cette application comme GÉRER LES COMPTES-CLIENTS. À l’extérieur du cadre, sur le côté gauche, dessinez l’entité externe (par exemple CLIENTS). Dessinez les différentes étapes de l’application, les flux de données et les stockages de données nécessaires. Essayez de faire apparaître tout, sauf les erreurs, les exceptions et les décisions. Celles-ci apparaissent dans les processus de niveau inférieur
5. Faites-vous à l’idée que vous devrez dessiner au moins trois (3) brouillons du diagramme de flux de données de niveau supérieur; Ne vous tracassez pas si le premier brouillon est un fouillis désespérant. On peut en tirer quelque chose.
6. Vérifiez votre premier brouillon de DFD avec vos listes d’entrées et de sorties pour vous assurer que vous avez tout représenté sauf bien entendu les cas d’erreurs ou d’exceptions; N’oubliez pas qu’il faut mettre à jour tous les dépôts de données.
7. Maintenant élaborez un second brouillon plus clair avec le minimum d’intersections de traits de flux de données;
8. Validez le cheminement de votre second brouillon avec un utilisateur du système d’information et notez tout changement qui résulte de cet examen;
9. À partir de cette troisième version du DFD, éclatez en processus de niveau inférieur chaque activité de traitement qui nécessite un éclatement;
10. Lorsque votre modèle sera conforme au système d’information de l’organisation, cette dernière version sera prête à être saisie à l’ordinateur par un logiciel spécialisé dans la conception des diagrammes.

Ce document pourra être agrandi et sera une aide précieuse pour la présentation à toute personne qui est concernée par le système d’information (Opération, conception, entretien, administration).

1. Travaillez de haut en bas, c’est-à-dire du niveau supérieur au niveau inférieur;
2. Pour les processus, mettez des verbes d’action à l’infinitif;
3. Un traitement est toujours numéroté. Cette numérotation ne correspond pas nécessairement à l’ordre dans lequel les tâches sont effectuées, mais sert à identifier chaque étape du traitement;
4. Ne mettez pas plus que huit (8) processus sur un même diagramme;
5. N’ajoutez des contrôles que sur les diagrammes de niveau inférieur;
6. Tous les traitements d’un DFD doivent être de même niveau;
7. La vigilance s’impose en ce qui a trait aux noms des flux d’un niveau à l’autre. Le même flux de données, quel que soit le DFD où il se situe, doit avoir la même étiquette;
8. Tous les flux entrants d’un processus de niveau supérieur doivent aussi être des flux entrants de ce processus éclaté. De la même façon, tous les flux sortants d’un processus de niveau supérieur doivent aussi être des flux sortants de ce processus éclaté; Il faut maintenir une certaine unité et cohérence entre les différents niveaux d’un DFD.
9. Le nom du flux en sortie doit être différent du nom du flux en entrée, puisqu’un traitement doit obligatoirement effectuer une transformation aux données;
10. Un flux de données provient soit d’une entité externe, soit d’un dépôt, soit d’un traitement et se dirige vers l’une de ces trois destinations. Cependant un traitement est toujours impliqué soit comme source soit comme destination d’un flux de données;
11. Les entités et les dépôts peuvent être répétés plus d’une fois sur un même diagramme;
12. Chaque flux de données doit recevoir un nom sans exception;
13. Deux flux de données qui ont une structure de données différentes ne peuvent avoir le même nom;
14. A chaque traitement que l’on n’a pas fait exploser doit correspondre une fiche logique de traitement dans le dictionnaire de système.

Un dictionnaire de données (aussi appelé dictionnaire de système) doit contenir les définitions de toutes les composantes constituant les modèles d’un système d’information. Les deux modèles de l’approche classique sont le diagramme de flux de données (DFD) et le diagramme entité-relation (DER). D’autres modèles peuvent aussi être utilisés, mais le DFD et le DER sont les plus utilisés.

Dans un dictionnaire de données, chaque processus de niveau inférieur doit être décrit en détail. En outre, l’analyste doit définir chaque flux et chaque dépôt de données reliés à ces processus, en termes de structures et d’éléments de données. Enfin, l’analyste doit aussi décrire chacun de ces éléments de données.

Construire un dictionnaire de données consiste à identifier chaque composante, lui donner un nom significatif, la définir et l’organiser pour pouvoir facilement y accéder.

Les diagrammes de flux de données ne décrivent pas complètement le sujet étudié. C’est pourquoi il est primordial de fournir des informations supplémentaires sur le système. Le dictionnaire de données fournit ces informations supplémentaires.

L’intérêt d’un dictionnaire de données comme outil de développement dépend de l’utilisation que les autres outils de développement peuvent faire des définitions qui y sont emmagasinées. Si le dictionnaire est bien conçu et régulièrement mis à jour, les définitions qui y sont emmagasinées sont directement utilisées par le système d’information lors de son exploitation. Le dictionnaire devient alors dynamique.

Enfin, il aide l’analyste à déterminer les besoins du système. Il sert également à la conception du système. Par exemple, si l’analyste veut connaître le nombre de caractères d’une donnée ou encore quels sont les différents noms d’une donnée et où elle est utilisée, il devrait trouver la réponse dans un bon dictionnaire de données.

Dans un DFD, nous avons donné des noms à des flux et à des dépôts de données. Mais que signifie réellement ces noms? Par exemple, que voulons nous dire par commande? Dans un dictionnaire, on pourrait expliquer le flux de données commande par la structure de données suivante :

COMMANDE :
    Détails commande
        Numéro de la commande
        Date de la commande
    Détails client
        Nom de l’organisme
        Personne responsable
            Prénom
            Nom
        Téléphone
            Indicatif régional
            Numéro
            Poste
        Adresse d’expédition
            Rue
            Ville
            Province
            Code postal
        Adresse de facturation
            Rue
            Ville
            Province
            Code postal
    Détails livre
        Nom de l’auteur
        Titre
        ISBN
        Nom de l’éditeur

Linsting ci-haut → Définition d’un flux de données COMMANDE dans un dictionnaire de données.

• Structures de données → Les structures de données sont composées d’éléments de données ou d’autres structures de données ou d’un mélange des deux.
• Élément de données → Un élément de données est la plus petite unité qui ne se décompose plus.
• Les flux de données sont des chemins le long desquels les structures de données voyagent. Ce sont des structures en mouvement.
• Les dépôts de données sont des endroits où les structures de données sont conservées jusqu’à leur utilisation. Ce sont des structures de données au repos.

1. Les processus
2. Les flux de données
3. Les dépôts de données
4. Les structures de données
5. Les éléments de données
6. Les entités externes (sources et destinations, ou agents externes)
7. Un glossaire

Chaque définition est présentée sous la forme d’une fiche descriptive. Examinons ces composantes pour voir ce que nous désirerions enregistrer sur chacune d’elles. Cela nous donnera des éléments de base pour évaluer n’importe quel dictionnaire de données ou pour organiser le nôtre.

Non seulement les flux et les dépôts de données doivent être définis, mais aussi la logique des processus qui transforment ces données. Chaque processus de niveau inférieur doit être décrit en détail. Par exemple, que voulons-nous dire par Vérifier le montant de la facture du processus 2.4? Les méthodes utilisées pour décrire cette logique est :

• Le langage courant structuré (l’algorithme indépendant de tout langage de programmation);
• La table de décision;
• L’arbre de décision.

Voici quelques exemples de description de la logique d’un processus.

Exemple 1 : Vérifier la solvabilité du client

Retrouver historique des paiements.
Si nouveau client
    Envoyer demande de paiement d’avance
Si client régulier (2 cmdes par mois en moyenne)
    Expédier, sauf si dette de plus de deux mois
Pour les clients connus qui ne sont pas réguliers
    Expédier, sauf s’ils doivent quelque chose

Exemple 2 : Enregistrer les informations du client

Demander si le client possède un compte (ou a déjà placé une commande)
Si le client possède un compte, alors
    Demander les informations d’identification
    Interroger la base de données avec les informations d’identification
    Copier les données de la réponse à l’interrogation dans Commande
Sinon
    Créer un enregistrement vide de client dans la base de données
    Demander au client les attributs du client
    Remplir l’enregistrement vides de client avec les attributs du client
Fin Si
Demander au client les informations sur la commande pour le premier article
Tant que sont exécutés d’autres articles pour la commande
    Ajouter les informations sur la commande dans Commande
Fin Tant que

Une vidéo empruntée est nécessairement une vidéo de l’inventaire

context Succursale
inv: self.videos->includesAll(self.clients.videos)

Deux clients distincts ne peuvent avoir des vidéos en commun.

context Succursale
inv: self.clients->forAll(c1, c2 | c1.videos->intersect(c2.videos) implies c1 = c2)

class Person
  attributes
    firstname: String
    lastname: String
    email: Set(String)
  operations
    fullname(prefix:String) : String =
      prefix.concat(' ').concat(firstname).concat(' ').concat(lastname)
end
prefix= 'Mr' ou 'Dr' ou 'Mad.' etc.

context Typename::operationName(param1 : Type1, ...): ReturnType
  pre precondname1 : ...param1... ...self...
  pre precondname2 : ...param1... ...self...
  ...
  post postcondname1 : ...result... ...param1... ...self...
  post postcondname2 : ...result... ...param1... ...self...

class Cours
  attributes
    titre: String
    sigle: String
  operations
    addPreRequis(c : Cours)
end

class Etudiant < Personne
  operations
    abandonCours(c : Cours)
    nouveauCode(n : String)
end

context Etudiant::abandonCours(c: Cours)
  pre Estinscrit: self.cours->includes(c)
  post Plusinscrit: self.cours = cours@pre->excluding(c)

La partie self.cours = cours@pre->excluding(c) est préférable à self.cours->excludes(c) car il peut arriver qu'après l'opération l'ensemble soit vide par erreur, donc qu'il exclus effectivement c, mais qu'en réalité, l'ensemble ne devait pas être vide et exclure c. @pre permet de faire référence à l'état de cours avant l'opération et de pouvoir comparer les deux états avant et après.

context A::sort(s : Sequence(Integer)) : Sequence(Integer)
  post MemeTaille:result->size = s->size
  post MemesElements: result->forAll(i | result->count(i) = s->count(i))
  post EstTriee: Sequence{1..( result->size-1)}->forAll(i | result.at(i) <= result.at(i+1))

Notez l’utilisation d’une séquence ici pour imiter une boucle de 1 à result->size-1.

• Dresden OCL toolkit
• EmPowerTec - Vérification de la syntaxe et de la sémantique de base
• KeY Project - Vérification formelle, OCL et JML
• USE - The UML-based Specification Environment.
• Neptune (académique) et Topcased (industriel).
• OCLE 2.0 - Object Constraint Language Environment (pas de développement depuis 2005).

• S. Benette, J. Skelton, K. Lunn, 2004. Schaum's Outlines of UML, McGraw Hill.