Designer - Portail du laboratoire de génie logiciel

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
2
3
Introduction..................................................................................................................................................... 1
Rappel de la démarche méthodologique ......................................................................................................... 2
Entités et associations ..................................................................................................................................... 3
3.1
Concepts.................................................................................................................................................. 3
3.2
Associations ............................................................................................................................................ 4
3.2.1
Modèle conceptuel de données (MCD)........................................................................................... 4
3.2.2
Modèle logique de données (MLD) ................................................................................................ 5
3.2.3
Modèle logique de traitement (MLT).............................................................................................. 6
3.3
Associations non transférables et identifiantes........................................................................................ 8
3.3.1
Modèle conceptuel de données (MCD)).......................................................................................... 8
3.3.2
Modèle logique de données (MLD) ................................................................................................ 9
3.3.3
Modèle logique de traitement (MLT)............................................................................................ 10
3.4
Entités associatives................................................................................................................................ 11
3.4.1
Modèle conceptuel de données (MCD)......................................................................................... 11
3.4.2
Modèle logique de données (MLD) .............................................................................................. 12
3.4.3
Modèle logique de traitement (MLT)............................................................................................ 13
4 Liens utiles .................................................................................................................................................... 15
4.1
Plus d’informations ............................................................................................................................... 15
4.2
Mise en pratique.................................................................................................................................... 15
4.3
Références............................................................................................................................................. 15
1 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 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
8ème phase
Test de l’intégrité de la structure de données
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 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
3.2
Associations
3.2.1 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
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
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.
3.2.3.1 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
3.2.3.2 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
3.3
Associations non transférables et identifiantes
3.3.1 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
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
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
3.4
Entités associatives
3.4.1 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
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
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.
3.4.3.1 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
3.4.3.2 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
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
[email protected]
HES-SO
Haute Ecole Spécialisée de Suisse occidentale
www.hes-so.ch
HEG-NE
Haute Ecole de Gestion de Neuchâtel
www.hegne.ch
ISNet
Centre de compétences
http://www.is-net.ch/
Systèmes d’information et informatique de
gestion
Génie logiciel
Centres d’intérêt du laboratoire de génie logiciel
sous la rubrique « Génie logiciel »
http://doc.esnig.ch/
Site Designer
Notre site de formation consacré à Designer et
ses sous-sites
http://zuse.esnig.cifom.ch/analyse/inde
x_designer.htm
Projet ISNet-14
Projet de recherche appliquée ISNet-14
http://zuse.esnig.cifom.ch/analyse/isnet
Atelier de génie logiciel et génération Web 14/index.htm
1er article (*)
Notions élémentaires
http://www.soug.ch/objects/pdf/Design
er_2_2003.pdf
http://zuse.esnig.cifom.ch/analyse/publi
cations/soug/designer/Article001.pdf
(*) Les anciens articles sont accessibles en Intranet sur le site du SOUG, www.soug.ch, ou en Internet sur le site
de la HEG-NE, http://zuse.esnig.cifom.ch/analyse/publications/index.htm
Article 2
- 15/15-
Août 2005