IFT 2251 Génie Logiciel La Modélisation des Données Hiver 2002 Petko Valtchev

Sommaire L’activité de modélisation Le début de la modélisation La méthode d’analyse structurée

Éléments du Modèle d’AS entité-association Diagramme de flot de données Diagramme état-transition Description des données Spécification des processus (PSPEC) du contrôle (CSPEC) Dictionnaire

Sommaire L’activité de modélisation Le début de la modélisation La méthode d’analyse structurée Le modèle entité-association (E-A) Les diagrammes de flot de données (DFD) Les diagrammes d’état-transition (E-T)

Attributs et Identification PROBLÈME Entité : client attributs: nom NAS adresse employeur revenu mensuel La détermination des entités et des attributs d’un modèle dépend essentiellement de la perspective sur le monde réel et de la protée du modèle. Souvent, il est difficile de départager les deux options. Entités ? Attributs Valeurs d’attribut: « À la différence des entités, elles n’ont pas une existence indépendante (pas d’identité) dans le monde modélisé. » Chaque entité sera identifiée de manière unique grâce à un ou plusieurs attributs : Ensemble - Client, Livre (le concept abstrait de), Entité - M. Personne (NAS 999 999 999), Guerre et Paix (avec son ISBN # ).

Clés et Identification L’ identification des entités est réalisée grâce à leurs attributs. Clé : «  Un ensemble d’un ou plusieurs attributs qui permettent d’identifier une entité de façon unique parmi un ensemble d’entités. Une clef composée d’un minimum d’attributs est appelée clé primaire. » [Nom, NAS] constitue une clé admissible de l’ensemble d’entités Client. [Nom] ne serait pas suffisant pour former une clé. [NAS] constitue une clef primaire de Client. Ex. Ensemble d’entités faible : «  Un ensemble n’ayant pas assez d’attributs pour constituer une clé primaire. » Ex. Transaction a trois attributs: no. de transaction, date et montant, qui ne permettent pas toujours de distinguer deux transactions sur comptes différents. Ces attributs n’étant pas suffisants pour composer une clé primaire, Transaction est un ensemble d’entités faible.

Clés (suite) Définition d’une clé primaire pour un ensemble d’entités faible: on prend la clef primaire d’un ensemble d’entités fort dont il dépend. on y ajoute une partie discriminante, c’est-à-dire un ensemble d’attributs qui permettent d’identifier les entités esclaves à l’intérieur du sous-ensemble correspondant à une entité-maître unique. Ex. Transaction est un ensemble d’entités faible qui dépend de l’ensemble d’entités Compte qui est un ensemble d’entités fort. La clef primaire de Compte est le [no. du compte]. L’attribut no de transaction de Transaction servira de partie discriminante. Donc une clef primaire pour l’ensemble d’entités Transaction sera : [no de compte, no de transaction] enregistre Maître Esclave Compte Transaction 0..n 1 No compte, nom,… No trans.,date, etc

Clés des Associations Possède Une association est caractérisée, de manière implicite, par les attributs des ensembles d’entités qui participent à l’association. L’association peut aussi bien avoir ses propres attributs descriptifs. Une clé pour l’association est constituée par l’adjonction des clés des ensembles d’entités. Au cas où l’information ainsi composée n’est pas suffisante pour distinguer les instances de l’association, une partie des attributs descriptifs peut être rajoutée afin de constituer une clé valide. Client Nom Adresse NAS Tel - No. Compte - Solde Compte bancaire 1..n Possède NAS No compte Date dernier accès 1..n

Diagrammes E-A, Notations On peut exprimer graphiquement le modèle entité-association à l’aide d’un diagramme dont les composants sont: des rectangles, représentant les ensembles d’entités, des losanges, représentant les associations, des ellipses, représentant les attributs (optionnel), des lignes, reliant les attributs aux ensembles d’entités et les ensembles d’entités aux associations. des annotations pour indiquer les cardinalités des associations et les bornes inférieures.

Diagrammes (exemple) Compte bancaire possède Client 1..n 1..n 0..n Nom NAS No compte Adresse Compte bancaire possède Client 1..n 1..n Solde Tél. 0..n No transaction enregistre Transaction Date 1 Montant

Diagrammes E-A O Quelques variantes Les losanges sont parfois omis. On utilise parfois des symboles pour exprimer les cardinalités et les bornes inférieures. Certains permettent d’ajouter au diagramme des détails et des contraintes supplémentaires: attributs composites, sous-classes/super-classes, généralisation/spécialisation, spécification des rôles par des annotations sur les liens, etc. Compte Transaction O

Agrégation Couple Agrégation: Principe d’abstraction qui permet aux associations d’être manipulées comme si elles étaient des entités (de niveau supérieur). Couple conjoint homme femme 1 1 possède maison

Généralisation Les attributs des entités des niveaux supérieurs Principe qui permet de mettre en évidence les similarités entre les ensembles d’entités. Permet de classifier hiérarchiquement les ensembles d’entités en créant des relations de spécialisation entre eux. no compte solde Les attributs des entités des niveaux supérieurs sont hérités par les entités des niveaux inférieurs. Compte bancaire Intérêt Nb opér. forfait is_a Compte d’épargne Compte chèque

Sommaire L’activité de modélisation Le début de la modélisation La méthode d’analyse structurée Le modèle entité-association (E-A) Les diagrammes de flot de données (DFD) Les diagrammes d’état-transition (E-T)

Modéliser le Traitement Fonctionnalité essentielle !!! « Un système informatisé effectue avant tout une transformation d’informations. » système logiciel entrée sortie

Diagr. de Flot de Données DFD : «  Représentation graphique du flot des données qui circulent dans le système et des transformations appliquées à ces données. » Un DFD décrit la circulation des données depuis leur entité-source, à travers les processus qui les transforme, jusqu’à leur entité-destination. Il montre les relations fonctionnelles entre les données manipulées par le système: valeurs d’entrée, valeurs de sortie, dépôts de données. Autres noms: data flow graph, bubble chart. N.B. Les DFD n’incluent pas de flot de contrôle en général!

Modèle de Flot, Notation entité externe processus flot de données magasin de données

DFD, Nœuds Ex. Ex. producteur/consommateur de données personne, périphérique, capteur, système informatisé Les données doivent toujours avoir de source et de destination. Ex. transformateur de données (entrées vers sorties) affectation d’impôts, calcul périphérique, visualisation graphe Les données doivent toujours être traitées afin de réaliser les fonctionnalités du système. Ex.

DFD, Flots et Magasins donnée transformée calcul aire du triangle base haut. aire Les données flottent à traves le système, depuis leur entrée jusqu’à ce qu’elles soient tranformées en sorite. recherche données capteur capteur # rapport demandé capteur #, type, localisation données capteur no. capteur type, Les données sont souvent stockées pour être utilisées ultérieurieurement

Construire un DFD 1. revoir le DE-A afin d’isoler les objets et parcourir les doc. pour déterminer les opérations 2. déterminer les entités externes 3. créer le DFD à niveau 0 4. écrire un descriptif pour chaque transformateur 5. parcourir pour déterminer les transformateurs du niveau suivant 6. équilibrer le flot pour maintenir la continuité 7. développer le DFD à niveau 1 all icons must be labeled with meaningful names the DFD evolves through a number of levels of detail always begin with a context level diagram (also called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic

Diagramme de Contexte Diagramme de contexte du système: Diagramme DFD (niveau 0) qui met en évidence les frontières du système. Vue abstraite du système qui montre: les entités externes du système, les flots de données entrant et sortant du système, un seul processus. Les dépôts de données ne sont pas représentés. usager source video écran demande traitement signal video NTSC digital processor signal demandé

Découpage d’un Processus b x P y niveau 0 c p2 a f p1 b p4 d 5 g p3 e niveau 1

Partition et Hiérarchie L’analyse structurée est une méthode descendante par raffinements successifs des traitements (processus): - A chaque niveau de décomposition, la notation graphique utilisée est celle des diagrammes de flots de données. Le niveau le plus haut représente l'ensemble du problème: le diagramme de contexte. Un diagramme de niveau inférieur représente la décomposition d’un processus défini au niveau juste au-dessus en plusieurs processus, en respectant les flots de données entrants et sortants. - Les processus du dernier niveau sont de primitives fonctionnelles. Niveau 0 Niveau 1 Niveau 2

Spécification de Processus Pour chaque primitive fonctionnelle! processus donner une spécification de processus (PSPEC) expliquant les détails du traitement: entrées/sorties, algorithmes, etc. PSPEC énoncé textuel pseudocode (PDL) équations Mini-spéc tables diagrammes

Exemple, DFD - N. 0 système d’alarme « SafeHome » Écran d’affichage du panneau Panneau de contrôle système d’alarme « SafeHome » Alarme Capteurs Ligne téléphonique

Exemple, DFD - N. 1 Configurer le système Interagir avec l’usager Activer/ désactiver le système Traitement mot de passe Afficher message et état Contrôle des capteurs

Exemple, DFD - N. 2 Information à propos du capteur Formatage pour l’affichage Écran d’affichage du panneau Infos configuration Id du capteur, type, localisation Alarme Produire signal d’alarme Données configuration Évaluation vis à vis des paramètres initiaux Type d’alarme Données d’alarme Examiner le capteur Ligne téléphonique Id du capteur, type Numéro de téléphone Composer le numéro de téléphone Tonalités du numéro de téléphone État du capteur Capteurs

Procédure de Modélisation Décoder la spécification informelle. Identifier les entités, les processus, le mouvement des données, les dépôts de données, les contraintes, les noms utilisés et les informations manquantes. Identifier les principales activités du système. Répartir les différents processus, entités et données par activité. Modéliser par un premier DFD chacune des activités du système (identifier les entrées, les sorties et la séquence de flots de données). Organiser la hiérarchie des diagrammes DFDs qui offriront une vue de plus en plus détaillée des processus. Construire le diagramme de contexte (DFD niveau 0).

Procédure (suite) Décomposition structurée en DFD (niveau 0-n). Décomposer le diagramme de contexte en sous-diagrammes. Chaque « processus-parent » est décomposé en un ensemble de « processus-enfants ». Les processus qui ne peuvent être décomposés davantage sont appelés « primitives fonctionnelles ». Chaque primitive fonctionnelle doit être décrit par une spécification de processus (PSPEC). Ajustement des différents diagrammes (0-n) couvrant la modélisation sur n niveaux. Vérifier les duplications des noms. Inclure les entités sources/puits des diagrammes parents dans les diagrammes enfants. Ajuster le diagramme de contexte. Compléter ou modifier les diagrammes DFDs. Vérifier la cohérence et la complétude de la modélisation.

Règles de Construction Les Processus: Identifier avec soin tous les processus du système. Étiqueter tous les processus par un verbe d’action et les données impliquées. Un processus est nécessaire pour tout transfert ou transformation de données. Il ne peut donc pas y avoir de flèche entre deux dépôts de données ou entre un dépôt de données et une entité externe. Penser à représenter le flot des données et non la séquence des opérations. Il ne devrait pas y avoir de boucles ou d’indications de transfert de contrôle. Penser aux chemins, aux processus et aux dépôts empruntés par les données. Visualiser l’essentiel des traitements. Ne pas s’attarder aux cas exceptionnels et problématiques.

Règles (suite) Les Flots de Données: Les Entités Externes Identifier toutes les entrées et sorties de données pour chaque processus et étiqueter les flèches. Ne pas ajouter d’annotations concernant la logique des procédures (conditions, boucles, etc.). Les flèches indiquent seulement le mouvement des données, pas le flot du contrôle. Les Entités Externes Identifier toutes les entités externes dans le diagramme de contexte (faire appel à son jugement). Numéroter chaque occurrence d’une même entité qui se répète dans le diagramme (pour en faciliter la lecture).

DFD, Règles Générales Bien comprendre les objectifs de modélisation du DFD. Ceci permet de déterminer le niveau de détail à inclure dans le diagramme. Une modélisation comporte généralement 5 à 7 niveaux. Organiser un DFD de façon à ce que la séquence principale des actions se lise de gauche à droite. Toujours commencer par la définition du diagramme de contexte (diagramme niveau 0). Toutes les icônes d’un DFD doivent être étiquetées de façon pertinente et significative. Construire des diagrammes simples et éviter de les surcharger. Reporter les détails dans le dictionnaire des données ou dans la spécification de processus (PSPEC).

Mise en Perspective Projection Modèle d’analyse Modèle de conception