Designer et l ingénierie du logiciel Couplage entre structure de données et modules de traitements

Transcription

1 Designer et l ingénierie du logiciel Couplage entre structure de données et modules de traitements P.-A. Sunier, ISNet Neuchâtel avec le concours de C. Kohler et P. Ferrara 1 Introduction Rappel de la démarche méthodologique Entités et associations Concepts Associations Modèle conceptuel de données (MCD) Modèle logique de données (MLD) Modèle logique de traitement (MLT) Associations non transférables et identifiantes Modèle conceptuel de données (MCD)) Modèle logique de données (MLD) Modèle logique de traitement (MLT) Entités associatives Modèle conceptuel de données (MCD) Modèle logique de données (MLD) Modèle logique de traitement (MLT) Liens utiles Plus d informations Mise en pratique Références Introduction Dans le premier article consacré à Designer, Newsletter 2/2003 d avril 2003, sous le titre Notions élémentaires, nous avons présenté les concepts de Designer sur la base d une approche d ingénierie du logiciel alliant méthodologie, normalisation et standardisation, qualité et réutilisation. Dans cet article, nous traiterons de la modélisation conceptuelle des données et de l incidence de la structure de données sur la conception des modules de traitements. Pour pouvoir démontrer succinctement cette incidence, nous ne décrirons pas l entier de la démarche d ingénierie qui a fait l objet de notre premier article ; nous nous limiterons à relater les phases qui nous semblent les plus significatives du thème traité. Nous avons mis en évidence ces phases significatives dans un rappel de notre choix. Dans cet article nous abordons les concepts suivants que nous traiterons dans de futurs articles : Associations récursives, arcs. Règles d application des contraintes d intégrité référentielle. LOV, List of values Formulaires de valeurs de référence. Composant spécifique de création de valeurs inexistante dans une LOV. Auto-incrémentation des attributs de clés primaires des entités par les APIs de tables. Article 2-1/15- Août 2005

2 2 Rappel de la démarche méthodologique Sur la base du cadre méthodologique retenu, nous avons défini une démarche méthodologique basée sur une approche top/down. Nous proposons une méthodologie basée sur les différents niveaux d abstraction de modélisation des données; elle intègre les fonctionnalités de Designer à mettre en œuvre. Notre démarche méthodologique est découpée en 9 phases. 1 ère phase Définition d un projet 2 ème phase Modélisation conceptuelle des données (MCD) 3 ème phase Transformation des objets de niveau conceptuel en objets de niveau logique 4 ème phase Enrichissement du modèle logique de données (MLD) 5 ème phase Génération et exécution des scripts SQL-DDL 6 ème phase Génération et exécution des scripts de création des APIs de tables 7 ème phase Test de l intégrité de la structure de données 8 ème phase Modélisation logique des traitements (MLT) Génération et exécution des scripts de création de modules 9 ème phase Test de l application Comme déjà indiqué en introduction, les 3 phases mises en évidence sont celles qui sont traitées pour démontrer le couplage existant entre structure de données et modules de traitements. Pour plus de détails relatifs à notre choix méthodologique, le lecteur se référera à notre premier article : Notions élémentaires. Article 2-2/15- Août 2005

3 3 Entités et associations 3.1 Concepts Entity Relationship Diagrammer nous permet de créer nos modèles conceptuels de données. Les modèles sont conçus selon un formalisme propriétaire sur la base du concept d entités qui représentent les «types ou classes d objets» du système à modéliser et d associations qui représentent les «types ou classes de liens» pouvant exister entre les entités. Les entités peuvent être spécialisées ou généralisées sous forme de Sub-Type et Super-Type. Les associations entre entités sont binaires ; les cardinalités sont représentées graphiquement. Une association peut être définie comme non transférable ; la non transférabilité est représentée par un losange sur l association. Une association peut être définie comme identifiante ; une association identifiante permet de définir une entité dépendante. Une occurrence d entité dépendante ne peut avoir d existence que comme enfant de l entité parent de l association. L identification est représentée par un trait perpendiculaire à l association. En conception, une association identifiante est toujours non-transférable. MCD /Eléments de notation Oracle utilise la notion d arc pour modéliser une restriction d associations ; l arc est paramétrable et permet, entre autres, de représenter une exclusion mutuelle ou une contrainte de Ou-exclusif. Les liens entre occurrences d entité identique ou de même nature sont modélisables par une association récursive. Les associations ne sont pas nommées en tant que telles, et n existent pas comme objets du référentiel ; elles existent en tant que propriété des entités qui participent à l association et sont identifiées par le nom donné à chacun des rôles de l association. Article 2-3/15- Août 2005

4 3.2 Associations Modèle conceptuel de données (MCD) L exemple ci-dessus montre l association existant entre un produit et la catégorie à laquelle il appartient ; nous pouvons observer : les rôles joués par les 2 entités participant à l association ; la cardinalité minimale de 0, représentée par un trait tillé, pour le rôle ComposeeDe de l entité CATEGORIE ; la cardinalité maximale de n, représentée par une patte d oie sur le rôle opposé, pour le rôle ComposeeDe de l entité CATEGORIE ; la cardinalité minimale de 1, représentée par un trait plein, pour le rôle AppartientA de l entité PRODUIT ; la cardinalité maximale de 1, représentée par une absence de patte d oie sur le rôle opposé, pour le rôle AppartientA de l entité PRODUIT. Les cardinalités nous indiquent que : une catégorie peut exister sans être dotée de produits ; pour exister un produit doit impérativement être associé à une catégorie mais une seule. Article 2-4/15- Août 2005

5 3.2.2 Modèle logique de données (MLD) Lors de la transformation de notre modèle conceptuel de données en objets de niveau logique, Database Design Transformer a créé les 2 tables CATEGORIES et PRODUITS ; l association a été transformée en attribut et contraintes sur la table PRODUITS: une clé étrangère CAT_NUMERO ; une contrainte de clé étrangère PROD_CAT_FK un index PROD_CAT_FK_I Après inclusion de nos tables et de notre «association ou relation» dans un diagramme, Design Editor nous montre la contrainte de clé étrangère sous forme d un lien entre les 2 tables. Ce lien est montré sous forme d un trait plein lorsqu une valeur de clé étrangère est obligatoire et sous forme d un trait tillé lorsqu une valeur n est pas obligatoirement requise ; cette propriété de la clé étrangère est déterminée par la cardinalité minimale du modèle conceptuel créé précédemment. Remarque Contrairement à la représentation conceptuelle avec Entity Relationship Diagrammer : le trait perpendiculaire ne signifie pas un lien identifiant mais une application stricte de l intégrité référentielle; la patte d oie ne signifie pas plusieurs liens mais indique le côté enfant de la relation entre les 2 tables. Article 2-5/15- Août 2005

6 3.2.3 Modèle logique de traitement (MLT) Sur la base d une relation entre 2 tables, il est possible de concevoir des modules de traitements de nature différente ; dans ce chapitre, nous en présenterons deux qui nous semblent significatifs de la multitude de modules de traitements concevables à partir d une structure de données initiale Table de référence Le module ci-contre est constitué d un composant qui permet de manipuler la table PRODUITS, dite, table de base; par manipulation, nous entendons lui appliquer les opérations : Insert, Update, et Delete. La connaissance de la valeur de la clé primaire de la catégorie n étant pas accessible à l utilisateur final, le composant doit lui permettre de référer une catégorie à associer à un produit par l intermédiaire d une liste des catégories existantes ; pour ce faire, nous rajoutons la table CATEGORIES dans le Module avec table de référence composant en tant que table de référence. Naturellement, la table de référence ne peut pas être manipulée par le composant ; elle ne peut être que lue ou consultée. Remarque Le lien PROD_CAT_FK entre la table de base PRODUITS et la table de référence CATEGORIES n est pas créé en modélisation des traitements mais, et c est essentiel, il est repris, à partir de la contrainte de clé étrangère, du modèle logique de données. Le formulaire ci-contre correspond à notre module, constitué d un composant qui permet, à l utilisateur, de manipuler un produit et de référencer la catégorie à laquelle il appartient. Ce formulaire permet à l utilisateur de changer la catégorie à laquelle appartient un produit ce qui n est pas possible avec le formulaire maître et détails que nous présenterons plus loin. Le lien hypertexte LOV, en regard du code de la catégorie, correspond à l appel d un formulaire spécifique listant les catégories disponibles. LOV est l acronyme de List of values. Formulaire avec table de référence Article 2-6/15- Août 2005

7 Maître et détails Le module ci-contre est constitué de deux composants. Le composant maître placé en haut du module permet de manipuler la table de base CATEGORIES. Le composant de détails placé en bas du module permet de manipuler la table de base PRODUITS. Les deux composants sont reliés par l intermédiaire du lien PROD_CAT_FK existant entre leurs tables de base. Contrairement au module précédent utilisant la table CATEGORIES en tant que table de référence, ce module permet de manipuler autant la table CATEGORIES dans le composant maître que la table PRODUITS dans le composant de détails. Remarque Le lien PROD_CAT_FK entre les deux tables de base PRODUITS et CATEGORIES n est pas créé en modélisation des traitements mais, et c est essentiel, il est repris du modèle logique de données. Module maître et détails L extrait de formulaire ci-contre correspond à notre module, constitué d un composant maître et d un composant de détails. Lorsque l utilisateur a sélectionné une catégorie, la liste des produits qui lui sont associés est affichée et l utilisateur peut manipuler les produits dépendants de la catégorie sélectionnée. L ajout d un nouveau produit se fait toujours pour la catégorie sélectionnée. Ce formulaire permet à l utilisateur un parcours aisé des catégories et de leurs produits. Formulaire maître et détails Article 2-7/15- Août 2005

8 3.3 Associations non transférables et identifiantes Modèle conceptuel de données (MCD)) L exemple ci-dessus illustre les concepts de non transférabilités d association et d association identifiante ; nous pouvons observer : la non transférabilité de l association entre CLIENT et COMMANDE, représentée par un losange; cette non transférabilité spécifie que lorsqu une commande est créée et attribuée à un client, elle ne peut plus être attribuée ou transférée à un autre client. Ceci implique que si un utilisateur se trompe de client lors de l établissement d une commande, il devra détruire la commande erronée et en récréer une nouvelle en lui attribuant le client correct. l association identifiante entre COMMANDE et LIGNECOMMANDE, représentée par un trait perpendiculaire à l association ; l association identifiante spécifie que les lignes de commandes seront identifiées par l identifiant de la commande et par un identifiant de ligne tout comme un enfant est identifié par le nom de famille des parents et son prénom. Remarques Lorsqu une association est identifiante, nous imposons de la rendre non transférable pour respecter la règle de stabilité de clé primaire. Nous avons choisi de nommer NUMERO l attribut qui servira de clé primaire des entités indépendantes, entités qui ont une existence propre, et NUMERODEP l attribut qui servira de complément de clé primaire des entités dépendantes ; les occurrences d entités dépendantes n existent que sous forme d enfants de l occurrence de l entité parent. Nous avons mis une cardinalité minimale de 0, trait tillé, sur le rôle ComposéeDe de l entité Commande. Idéalement, nous devrions mettre une cardinalité minimale de 1, trait plein ; en effet, une commande n a de sens que si elle est composée d au moins une ligne référant un produit ; nous ne pouvons le faire, car nous devrions gérer une transaction insérant simultanément une commande et une ligne de commande ce que l environnement Oracle ne permet pas de mettre en œuvre. Article 2-8/15- Août 2005

9 3.3.2 Modèle logique de données (MLD) Par rapport au modèle logique de données (MLD) décrit au chapitre Associations, nous pouvons observer l enrichissement suivant : les contraintes de non transférabilité sont représentées graphiquement, comme pour le modèle conceptuel de données, par un losange sur la relation ou contrainte de clé étrangère ; la clé primaire de la table LIGNESCOMMANDES est bien construite à partir de la concaténation de la clé étrangère CDE_NUMERO, clé primaire de la table parent COMMANDES, et de l attribut NUMERODEP, auto-séquencé pour chaque commande. Remarques Les attributs de clés primaires de tables sont mis en évidence graphiquement avec le symbole #. Comme déjà indiqué précédemment, et contrairement à la représentation conceptuelle avec Entity Relationship Diagrammer le trait perpendiculaire ne signifie pas un lien identifiant mais une application stricte de l intégrité référentielle; Article 2-9/15- Août 2005

10 3.3.3 Modèle logique de traitement (MLT) Le module ci-dessus, combine les concepts de tables de référence et de maître et détails décrits au chapitre Associations et conforte la notion de multitude de modules de traitement concevables à partir d une structure de données initiale. Remarque Les associations non transférables et identifiantes n ont pas d incidence directe sur la conception des modules de traitement. L extrait de formulaire ci-contre correspond à notre module ; dans la partie supérieure, composant maître, nous voyons la commande et la référence au client, dans la partie inférieure, composant de détails, nous voyons les lignes de commandes avec la référence des produits et la quantité commandée. Remarque Lors de la conception du module, la contrainte de non transférabilité de la commande et des lignes de commandes sera prise en charge par Design Editor. Ci-contre, nous pouvons observer que la référence du client ne peut plus être éditée en modification. Article 2-10/15- Août 2005

11 3.4 Entités associatives Modèle conceptuel de données (MCD) En modélisation conceptuelle des données, Entity relationship Diagrammer permet de créer des associations de degré n:n ; toutefois, nous bannissons ces associations car il n est pas possible de les doter d attributs ou de les faire participer à d autres associations. Pour remplacer les associations de degré n:n, nous utilisons des entités associatives ; les entités associatives sont des entités dépendantes, identifiées par deux parents ou plus. Une entité associative peut être dotée d attributs et être, à son tour, associée à toute autre entité. Dans l exemple ci-dessus, l entité associative DISTRIBUE représente le lien n:n qui existe entre un fournisseur qui peut distribuer plusieurs catégories de produits et une catégorie qui peut être distribuée par plusieurs fournisseurs. Par souci de concision, nous n avons pas mis d attributs à l entité associative et ne l avons non plus associée à une autre entité. Article 2-11/15- Août 2005

12 3.4.2 Modèle logique de données (MLD) Par rapport aux modèles logiques de données décrits aux chapitres précédents, nous pouvons observer la clé primaire de la table associative DISTRIBUENT formée par la concaténation des clés étrangères des deux tables parents CATEGORIES et FOURNISSEURS. Remarque Si nous avions modélisé notre entité associative sous forme d une association n:n, l outil de transformation Database Design Transformer nous aurait créé une table associative comme ci-dessus, identifiée par les clés étrangères des tables parents. Article 2-12/15- Août 2005

13 3.4.3 Modèle logique de traitement (MLT) Tout comme une relation entre 2 tables peut déboucher sur la conception de modules de nature différente, une table associée peut déboucher sur une multitude de modules de traitement; par analogie aux chapitres précédents, nous présenterons un module sous forme de maître et détails et un module utilisant uniquement le concept de table de référence Maître et détails Le module ci-contre utilise la table FOURNISSEURS pour le composant maître et la table CATEGORIES comme table de référence du composant de détails qui manipule la table associative DISTRIBUENT. Mais, les rôles entre les FOURNISSEURS et CATEGORIES peuvent être inversés selon les besoins des utilisateurs. Module table associative «maître et détails» Article 2-13/15- Août 2005

14 Double tables de référence Contrairement au module précédent, le module ci-contre ne comporte qu un seul composant. Ce composant manipule la table associative DISTRIBUENT et réfère aux deux tables parents FOURNISSEURS et CATEGORIES. Module table associative "Double référence" Article 2-14/15- Août 2005

15 4 Liens utiles 4.1 Plus d informations Si vous souhaitez plus d informations, notre site consacré à Designer est à votre disposition. Le site Designer contient plusieurs entrées ; nous n avons pas encore publié de documents spécifiques à la version 9i, nos documents les plus récents sont consacrés à la version 6i. Le sous-site «Les bases» de la version 6i de Designer, et plus particulièrement les cahiers «02 Enrichissement» et «03 Approfondissement des associations» traite des notion élémentaires présentées succinctement dans cet article. 4.2 Mise en pratique Les notions que nous avons présentées dans cet article peuvent être mises en œuvre en suivant la partie pratique des cahier «02 Enrichissement» et «03 Approfondissement des associations» de notre sous-site «Les bases» de la version 6i de Designer. 4.3 Références L auteur Pierre-André Sunier pierre-andre.sunier@cpln.ch HES-SO Haute Ecole Spécialisée de Suisse occidentale HEG-NE Haute Ecole de Gestion de Neuchâtel ISNet Génie logiciel Site Designer Projet ISNet-14 Centre de compétences Systèmes d information et informatique de gestion Centres d intérêt du laboratoire de génie logiciel sous la rubrique «Génie logiciel» Notre site de formation consacré à Designer et ses sous-sites Projet de recherche appliquée ISNet-14 Atelier de génie logiciel et génération Web x_designer.htm 14/index.htm 1 er article (*) Notions élémentaires er_2_2003.pdf cations/soug/designer/article001.pdf (*) Les anciens articles sont accessibles en Intranet sur le site du SOUG, ou en Internet sur le site de la HEG-NE, Article 2-15/15- Août 2005