La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel La Modélisation des Données Hiver 2002 Petko Valtchev.

Présentations similaires


Présentation au sujet: "© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel La Modélisation des Données Hiver 2002 Petko Valtchev."— Transcription de la présentation:

1 © Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel La Modélisation des Données Hiver 2002 Petko Valtchev

2 © Petko ValtchevUniversité de Montréal Janvier Modélisation Sommaire l Lactivité de modélisation l Le début de la modélisation l La méthode danalyse structurée

3 © Petko ValtchevUniversité de Montréal Janvier Modélisation Éléments du Modèle dAS Modèle entité-association Diagramme de flot de données Diagramme état-transition Description des données Spécification des processus (PSPEC) Spécification du contrôle (CSPEC) Dictionnaire des données

4 © Petko ValtchevUniversité de Montréal Janvier Modélisation Sommaire l Lactivité de modélisation l Le début de la modélisation l La méthode danalyse structurée l Le modèle entité-association (E-A) l Les diagrammes de flot de données (DFD) l Les diagrammes détat-transition (E-T)

5 © Petko ValtchevUniversité de Montréal Janvier Modélisation Entité : client attributs: nom nom NAS NAS adresse adresse employeur employeur revenu mensuel revenu mensuel Valeurs dattribut: « À la différence des entités, elles nont pas une existence indépendante (pas didentité) dans le monde modélisé. » La détermination des entités et des attributs dun 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. Attributs et Identification PROBLÈME ? Entités Attributs 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 ), Guerre et Paix (avec son ISBN # ).

6 © Petko ValtchevUniversité de Montréal Janvier Modélisation Clés et Identification [Nom, NAS] constitue une clé admissible de lensemble dentités Client. [Nom] ne serait pas suffisant pour former une clé. [NAS] constitue une clef primaire de Client. Clé : « Un ensemble dun ou plusieurs attributs qui permettent didentifier une entité de façon unique parmi un ensemble dentités. Une clef composée dun minimum dattributs est appelée clé primaire. » L identification des entités est réalisée grâce à leurs attributs. 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 dentités faible. Ensemble dentités faible : « Un ensemble nayant pas assez dattributs pour constituer une clé primaire. » Ex.

7 © Petko ValtchevUniversité de Montréal Janvier Modélisation Définition dune clé primaire pour un ensemble dentités faible: 1. on prend la clef primaire dun ensemble dentités fort dont il dépend. 2. on y ajoute une partie discriminante, cest-à-dire un ensemble dattributs qui permettent didentifier les entités esclaves à lintérieur du sous-ensemble correspondant à une entité-maître unique. Ex. l Transaction est un ensemble dentités faible qui dépend de lensemble dentités Compte qui est un ensemble dentités fort. l La clef primaire de Compte est le [no. du compte]. l Lattribut no de transaction de Transaction servira de partie discriminante. l Donc une clef primaire pour lensemble dentités Transaction sera : [no de compte, no de transaction] Compte Transaction enregistre 0..n 1 Esclave Maître No compte, nom,… No trans.,date, etc Clés (suite)

8 © Petko ValtchevUniversité de Montréal Janvier Modélisation Une association est caractérisée, de manière implicite, par les attributs des ensembles dentités qui participent à lassociation. Lassociation peut aussi bien avoir ses propres attributs descriptifs. Une clé pour lassociation est constituée par ladjonction des clés des ensembles dentités. Au cas où linformation ainsi composée nest pas suffisante pour distinguer les instances de lassociation, une partie des attributs descriptifs peut être rajoutée afin de constituer une clé valide. Client -Nom -Adresse -NAS -Tel Possède NAS No compte Date dernier accès 1..n Clés des Associations - No. Compte - Solde Compte bancaire

9 © Petko ValtchevUniversité de Montréal Janvier Modélisation On peut exprimer graphiquement le modèle entité-association à laide dun diagramme dont les composants sont: des rectangles, représentant les ensembles dentités, des losanges, représentant les associations, des ellipses, représentant les attributs (optionnel), des lignes, reliant les attributs aux ensembles dentités et les ensembles dentités aux associations. des annotations pour indiquer les cardinalités des associations et les bornes inférieures. Diagrammes E-A, Notations

10 © Petko ValtchevUniversité de Montréal Janvier Modélisation Diagrammes (exemple) Solde Client Transaction Compte bancaire possède Nom Adresse NAS Tél. No compte No transaction Montant Date 1..n 0..n 1 enregistre

11 © Petko ValtchevUniversité de Montréal Janvier Modélisation - Les losanges sont parfois omis. - On utilise parfois des symboles pour exprimer les cardinalités et les bornes inférieures. - Certains permettent dajouter 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 Quelques variantes Diagrammes E-A

12 © Petko ValtchevUniversité de Montréal Janvier Modélisation maison femme possède Couple Agrégation: l Principe dabstraction qui permet aux associations dêtre manipulées comme si elles étaient des entités (de niveau supérieur). Agrégation 11 homme conjoint

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

14 © Petko ValtchevUniversité de Montréal Janvier Modélisation Sommaire l Lactivité de modélisation l Le début de la modélisation l La méthode danalyse structurée l Le modèle entité-association (E-A) l Les diagrammes de flot de données (DFD) l Les diagrammes détat-transition (E-T)

15 © Petko ValtchevUniversité de Montréal Janvier Modélisation systèmelogiciel entrée sortie « Un système informatisé effectue avant tout une transformation dinformations. » Fonctionnalité essentielle !!! Modéliser le Traitement

16 © Petko ValtchevUniversité de Montréal Janvier Modélisation Diagr. de Flot de 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 dentrée, valeurs de sortie, dépôts de données. Autres noms: data flow graph, bubble chart. N.B. Les DFD nincluent pas de flot de contrôle en général! DFD : « Représentation graphique du flot des données qui circulent dans le système et des transformations appliquées à ces données. »

17 © Petko ValtchevUniversité de Montréal Janvier Modélisation entité externe processus flot de données magasin de données Modèle de Flot, Notation

18 © Petko ValtchevUniversité de Montréal Janvier Modélisation producteur/consommateur de données Ex. personne, périphérique, capteur, système informatisé Les données doivent toujours avoir de source et de destination. transformateur de données (entrées vers sorties) Ex. affectation dimpô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. DFD, Nœuds

19 © Petko ValtchevUniversité de Montréal Janvier Modélisation Les données flottent à traves le système, depuis leur entrée jusquà ce quelles soient tranformées en sorite. calcul aire du trianglebasehaut. aire recherchedonnéescapteur capteur # rapport demandé capteur #, type, localisation données capteur no. capteur type,localisation Les données sont souvent stockées pour être utilisées ultérieurieurement DFD, Flots et Magasins donnée transformée

20 © Petko ValtchevUniversité de Montréal Janvier Modélisation 1. revoir le DE-A afin disoler 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 1. revoir le DE-A afin disoler 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 Construire un DFD

21 © Petko ValtchevUniversité de Montréal Janvier Modélisation Diagramme de Contexte Diagramme de contexte du système: l Diagramme DFD (niveau 0) qui met en évidence les frontières du système. l Vue abstraite du système qui montre: l les entités externes du système, l les flots de données entrant et sortant du système, l un seul processus. l Les dépôts de données ne sont pas représentés. usagerusager sourcevideosourcevideo écranécran demande traitement signal video NTSC digitalvideoprocessor signal video demandé

22 © Petko ValtchevUniversité de Montréal Janvier Modélisation Découpage dun Processus P a b xy p1 p2 p3 p4 5 a b c d e f g niveau 0 niveau 1

23 © Petko ValtchevUniversité de Montréal Janvier Modélisation Partition et Hiérarchie Niveau 1 Niveau 2 Niveau 0 Lanalyse 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 dun 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.

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

25 © Petko ValtchevUniversité de Montréal Janvier Modélisation Exemple, DFD - N. 0 système dalarme « SafeHome » « SafeHome » Panneau de contrôle Panneau de contrôle Capteurs Écran daffichage du panneau Écran daffichage du panneau Alarme Ligne téléphonique Ligne téléphonique

26 © Petko ValtchevUniversité de Montréal Janvier Modélisation Exemple, DFD - N. 1 Contrôle des capteurs Traitement mot de passe Interagir avec lusager Configurer le système Activer/ désactiver le système Afficher message et état

27 © Petko ValtchevUniversité de Montréal Janvier Modélisation Exemple, DFD - N. 2 État du capteur Id du capteur, type Données configuration Id du capteur, type, localisation Données dalarme Numéro de téléphone Information à propos du capteur Type dalarme Tonalités du numéro de téléphone Infos configuration Formatage pour laffichage Formatage pour laffichage Produire signal dalarme Produire signal dalarme Composer le numéro de téléphone Composer le numéro de téléphone Examiner le capteur Examiner le capteur Capteurs Écran daffichage du panneau Écran daffichage du panneau Alarme Ligne téléphonique Ligne téléphonique Évaluation vis à vis des paramètres initiaux Évaluation vis à vis des paramètres initiaux

28 © Petko ValtchevUniversité de Montréal Janvier Modélisation Procédure de Modélisation 1. 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. 2. Identifier les principales activités du système. Répartir les différents processus, entités et données par activité. 3. 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). 4. Organiser la hiérarchie des diagrammes DFDs qui offriront une vue de plus en plus détaillée des processus. 5. Construire le diagramme de contexte (DFD niveau 0).

29 © Petko ValtchevUniversité de Montréal Janvier Modélisation Procédure (suite) 6. 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). 7. 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. 8. Ajuster le diagramme de contexte. 9. Compléter ou modifier les diagrammes DFDs. Vérifier la cohérence et la complétude de la modélisation.

30 © Petko ValtchevUniversité de Montréal Janvier Modélisation Règles de Construction Les Processus: l Identifier avec soin tous les processus du système. l Étiqueter tous les processus par un verbe daction et les données impliquées. l 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. l 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 dindications de transfert de contrôle. Penser aux chemins, aux processus et aux dépôts empruntés par les données. l Visualiser lessentiel des traitements. Ne pas sattarder aux cas exceptionnels et problématiques.

31 © Petko ValtchevUniversité de Montréal Janvier Modélisation Règles (suite) Les Entités Externes l Identifier toutes les entités externes dans le diagramme de contexte (faire appel à son jugement). l Numéroter chaque occurrence dune même entité qui se répète dans le diagramme (pour en faciliter la lecture). Les Flots de Données: l Identifier toutes les entrées et sorties de données pour chaque processus et étiqueter les flèches. l Ne pas ajouter dannotations 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.

32 © Petko ValtchevUniversité de Montréal Janvier Modélisation 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 dun 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).

33 © Petko ValtchevUniversité de Montréal Janvier Modélisation Mise en Perspective Modèle danalyse Modèle de conception Projection


Télécharger ppt "© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel La Modélisation des Données Hiver 2002 Petko Valtchev."

Présentations similaires


Annonces Google