1.2 Genèse. 1.3 Version de Designer utilisée

Designer et l ingénierie du logiciel Notions élémentaires P.-A. Sunier, ISNet Neuchâtel avec le concours de C. Kohler et P. Ferrara 1 Propos liminaires... 1 1.1 Objectifs de publication... 1 1.2 Genèse... 2 1.3 Version de Designer utilisée... 2 2 Notions élémentaires... 3 2.1 Introduction... 3 2.2 Présentation succincte de Designer... 3 2.3 Nos choix de mise en œuvre de Designer... 4 2.3.1 Postulat de base... 4 2.3.2 Cadre méthodologique... 4 2.3.3 Cible de génération... 5 2.3.4 Démarche méthodologique... 5 2.4 Fonctionnalités de Designer par phase... 6 2.4.1 1 ère phase Définition d un projet... 6 2.4.2 2 ème phase Modélisation conceptuelle des données (MCD)... 6 2.4.3 3 ème phase - Transformation des objets de niveau conceptuel en objets de niveau logique... 7 2.4.4 4 ème phase Enrichissement du modèle logique de données (MLD)... 8 2.4.5 5 ème phase - Scripts SQL DDL... 10 2.4.6 6 ème phase APIs de tables... 11 2.4.7 7 ème phase Test de l intégrité de la structure de données... 12 2.4.8 8 ème phase Modélisation logique des traitements (MLT)... 13 2.4.9 9 ème phase Test de l application... 15 3 Liens utiles... 17 3.1 Plus d informations... 17 3.2 Mise en pratique... 17 3.3 Références... 17 1 Propos liminaires 1.1 Objectifs de publication Sous le titre général «Designer et le génie logiciel», nous publierons une série d articles inspirés de nos travaux de recherche appliquée menés au sein du centre de compétences «Systèmes d information et informatique de gestion», dénommé ISNet, de la Haute Ecole Spécialisée de Suisse occidentale, abrégée HES-SO. Nous n avons pas l ambition de nous substituer au constructeur Oracle et aux sociétés de conseils; nous ne traiterons pas les subtilités du produit, de son installation, de son paramétrage, des différences entre les versions mais nous nous concentrerons sur les aspects relevant de l ingénierie du logiciel tels que la méthodologie, la normalisation et la standardisation, la qualité des applications ou encore la réutilisation de tout ou partie de projets ou sous-projets. Article 1-1/17- Août 2005

1.2 Genèse Les bases de cette série d articles découlent de notre projet de recherche appliquée ISNet-14, «Atelier de génie logiciel et génération Web». Ce projet avait été initialisé en 1999 sur la base, entre autres, des considérations suivantes : Le besoin de production de systèmes d information aptes à répondre aux changements environnementaux dans des délais de plus en plus courts et à des coûts maîtrisés peut probablement être satisfait en mettant en place les concepts de l ingénierie Après la déconvenue des coûts cachés du poste client de l architecture Client/Serveur, de nombreuses organisations sont intéressées par la mise en place d architectures à 3 niveaux. Le troisième niveau, le serveur d application, est censé accueillir de manière unifiée l essentiel des ressources matérielles de traitement qui sont hébergées dans chaque poste client de l architecture Client/Serveur ; le poste client redeviendrait une ressource matérielle légère A partir des considérations émises, nous retenions les principes suivants : Nous voulons explorer les voies de l industrialisation et du déploiement d applications dans une architecture à multiples niveaux, composée de serveur(s) de données, serveur(s) d application et de clients universels sous forme de navigateurs Web. Pour satisfaire aux objectifs d industrialisation, nous nous appuierons sur le concept de référentiel. Le référentiel devra être partageable et pouvoir être alimenté par des outils graphiques de modélisation de données et de traitements. Le référentiel devra contenir, d une manière ou d une autre, l ensemble des règles de gestion du système d information à produire. Afin d éviter toute erreur d interprétation des spécifications lors de la production du logiciel des divers niveaux, et pour satisfaire au but d automatisation, nous nous servirons de générateurs de code. Les générateurs devront nous permettre de générer le logiciel de chacun des niveaux indépendamment l un de l autre mais, toujours à partir de la même base de spécification : le référentiel. A partir des principes émis, nous retenions le choix stratégique suivant : nous nous appuierons sur un atelier de génie logiciel (AGL) du marché. L AGL que nous retiendrons doit satisfaire aux exigences que nous avons énoncées de plus, il doit nous permettre de modéliser les données et les traitements sous forme de vues organisationnelles, conceptuelles, logiques ou physiques. Pour satisfaire aux objectifs d intégration que nous nous sommes fixés, l AGL choisi devra être homogène et inclure toutes les fonctionnalités attendues sans devoir faire appel à des services externes. Si l AGL est propriétaire, les résultats qu il fournira devront être exploitables selon les normes et standards existants. A partir de ce choix stratégique, nous avions retenu l AGL Designer de l éditeur Oracle sur la base des considérations suivantes : il nous permet de générer des scripts SQL de création de bases de données selon la norme ANSI, le standard ODBC ou une syntaxe propre aux acteurs principaux du marché : IBM-DB2, SQL Server, Sybase, Oracle il nous permet de générer les applications clientes dans le cadre d une architecture à 2 niveaux sous forme de code source C++ ou Visual Basic en plus de son format propriétaire Forms ; dans le cadre d une architecture à 3 niveaux, il nous permet de générer la logique du serveur d application sous forme de code Java, LiveHTML, Perl ou PL/SQL. Le serveur d application et les générateurs respectent les standards HTML, CORBA et EJB. 1.3 Version de Designer utilisée De manière générale, nous essayerons de nous attacher aux concepts ; de ce fait, la version de Designer n est pas essentielle. Une grande partie du contenu de nos articles s applique aux versions anciennes 2.1.2, 6, ou 6i. Nous utiliserons la version 9i de Designer, plus précisément 9.0.2, pour illustrer le début de cette série d articles. Si nous devions illustrer ou baser nos propos sur des éléments d anciennes versions de Designer nous le mentionnerons pour éviter toute confusion. Article 1-2/17- Août 2005

2 Notions élémentaires 2.1 Introduction Cet article initial est consacré à la présentation des notions élémentaires de Designer dans une vision d ingénierie. Par ingénierie nous entendons une démarche méthodologique susceptible de favoriser la maîtrise de la qualité, des délais et des coûts de production des logiciels. Designer est un atelier de génie logiciel couvrant un large spectre des activités liées à l informatisation des systèmes d information. Designer prend en charge les activités d analyse, de conception et de génération de code, tout en offrant des fonctionnalités de transformation entre niveaux d abstraction, de documentation et d analyse de dépendance ; cette liste de fonctionnalités n est pas exhaustive mais correspond, à notre sens, aux fondements de Designer. 2.2 Présentation succincte de Designer Dans une première approche simplifiée, nous pourrions définir Designer comme un couple formé d une base de données Oracle, nommée référentiel ou Repository, et d une application exécutable dans un environnement Windows ; l application exécutable est nommée : client Designer. Le référentiel contient les spécifications du système d information, sujet de notre analyse, conception et/ou génération. Le client Designer regroupe les outils de modélisations, les générateurs et, sous forme d utilitaires, les outils d édition de rapports, d analyse d impact ou encore de consultation du référentiel. Figure 1 - Le référentiel et les outils de Designer (Aide en ligne de Designer 2.1) La figure 1 montre le client Designer composé des outils de modélisation qui alimentent le référentiel et de générateurs qui créent le code exécutable ou la documentation à partir du contenu du référentiel. Article 1-3/17- Août 2005

La figure 2 montre le panneau de commande des fonctionnalités du client Designer 9i sous Windows. Le groupe Model System Requirements regroupe les outils de modélisation de niveau organisationnel ou conceptuel, dans le sens français du terme. Le groupe Transform Preliminary Designs regroupe les outils de transformation des modèles de données et de traitements conceptuels en modèles logiques. Le groupe Design and Generate contient l outil de modélisation logique ou de conception, dans le sens anglophone du terme ; l outil de modélisation, Design Editor, permet de concevoir les modèles logiques de données et de traitements, mais également les modèles physiques de données. Le groupe Repository Tools contient les utilitaires d édition de rapports, d analyse d impact, de consultation et d administration du référentiel. Figure 2 - Panneau de commande de Designer 9i 2.3 Nos choix de mise en œuvre de Designer 2.3.1 Postulat de base Nous nous sommes fixés comme contrainte de ne jamais retoucher le code généré par Designer, sauf dans le cas très rare, mais existant, de correction d un bug de générateur qui s avèrerait fatal. Nous reviendrons plus en détail, dans un prochain article, sur les solutions offertes par Designer pour personnaliser le code en tant que spécifications en amont de la génération. 2.3.2 Cadre méthodologique Dans un premier temps, nous limitons notre utilisation de Designer aux seules fonctionnalités qui nous permettront d atteindre, avec un maximum d efficience, l objectif de «génération de code dans un environnement n-tiers» que nous nous sommes fixé. Nous avons arrêté le choix suivant : Article 1-4/17- Août 2005

au niveau de la modélisation organisationnelle ou conceptuelle, Model System Requirements, nous ne retenons que l outil de modélisation conceptuelle des données Entity RelationShip Diagrammer. La modélisation des traitements ne débouchant pas ou peu sur des spécifications exploitables automatiquement dans la suite du processus de conception et génération de logiciels nous ne la retenons pas ; par contre, la modélisation des traitements fera l objet d un article futur. nous retenons Database Design Transformer pour la transformation des modèles conceptuels de données en modèles logiques ; naturellement, nous retenons Design Editor pour la modélisation logique des données et des traitements, ainsi que pour la génération des divers scripts exécutables, compilables ou interprétables. 2.3.3 Cible de génération Nous créerons notre structure de données de test en nous limitant volontairement aux seules bases de données Oracle. La génération des scripts SQL-DDL est paramétrable et permet de cibler les produits de différents constructeurs ; mais les APIs de tables qui enrichissent les définitions normalisées SQL sont propriétaires et ne s appliquent qu aux bases de données Oracle ou à d éventuelles bases qui seraient compatibles au niveau des paquetages PL/SQL et des triggers. Plusieurs voies sont possibles pour générer des applications exécutables dans un environnement n-tiers comme nous nous l étions imposé pour notre projet de recherche appliquée ISNet-14. Parmi les possibilités offertes, nous avons choisi la technologie Web PL/SQL d Oracle. 2.3.4 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 Au chapitre suivant, nous allons montrer les fonctionnalités de Designer utilisées lors de ces différentes phases et en donner une explication succincte. Dans nos prochains articles nous expliciterons ces fonctionnalités plus complètement. Article 1-5/17- Août 2005

2.4 Fonctionnalités de Designer par phase 2.4.1 1 ère phase Définition d un projet Le navigateur de contenu du référentiel, Repository Object Navigator ou RON, permet de créer des projets. Avec notre approche de Designer pour ce premier article, un projet correspond à une application à développer. Les projets, Application dans la terminologie Oracle, sont regroupés au sein d espaces de travail, Workarea. Les espaces de travail et projets permettent de partitionner le référentiel. La figure 3 montre le projet Ex_Garage dans l espace de travail Sunier. Figure 3 - Projets et espace de travail 2.4.2 2 ème phase Modélisation conceptuelle des données (MCD) 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. Les associations entre entités sont binaires ; les cardinalités sont représentées graphiquement. Figure 4 MCD / Eléments et notation Article 1-6/17- Août 2005

2.4.3 3 ème phase - Transformation des objets de niveau conceptuel en objets de niveau logique Database Design Transformer transforme nos objets conceptuels de modélisations des données en objets logiques. Dans l environnement de Designer, le modèle logique est de nature relationnelle, selon la définition donnée par Codd ; les entités deviennent des tables, les associations deviennent automatiquement des colonnes de clés étrangères, des contraintes de clés étrangères et des index Cette transformation est fortement paramétrable par le concepteur. Grâce aux possibilités de paramétrage offertes, le concepteur peut effectuer de nombreux aller et retour entre les niveaux conceptuels et logiques sans altérer le contenu des différents niveaux. Figure 5 - Paramétrage de la transformation La figure 5 montre les entités que l outil de transformation a trouvées dans le projet ; dans le cas particulier, nous pouvons observer que toutes les entités ont déjà donné lieu à une table. En respectant la méthodologie que nous préconisons, toute entité du modèle conceptuel de données est associée à une table du modèle logique de données. La figure 6 montre ce couplage, au niveau du référentiel, entre entité et table. Figure 6 - Couplage entre entité et table Article 1-7/17- Août 2005

2.4.4 4 ème phase Enrichissement du modèle logique de données (MLD) Design Editor nous permet d effectuer : la modélisation logique des données, sous forme de tables, colonnes, contraintes, etc la modélisation logique des traitements sous forme de modules, composants, etc. Par la suite, nous parlerons de conception pour définir l activité effectuée avec Design Editor, le terme de conception doit être compris comme la traduction littérale du terme anglais «design» ; il n y a donc pas de lien à faire entre cette activité de conception et les modèles conceptuels qui eux réfèrent à un niveau d abstraction. Figure 7 - MLD /Eléments et notation Conformément à la méthodologie que nous préconisons, nous ne créerons pas de tables comme nous le ferions dans une vision de développement RAD (Rapid Application Development). Nous enrichirons les tables obtenues par la phase précédente de transformation d entités en tables. L enrichissement portera sur des éléments comme la traçabilité des manipulations de données des utilisateurs, l automatisation de génération de clés primaires, la dénormalisation, etc. Si nous ne créons pas de tables au niveau logique, nous créons des objets, telles les séquences, qui n existent pas au niveau conceptuel. Le modèle logique de données supporté par Designer est nommé Server Model. De notre côté, nous utiliserons plutôt le terme de modèle relationnel. Article 1-8/17- Août 2005

La table GAR_CLIENTS de la figure 8 a été créée par l outil de transformation et enrichie avec Design Editor alors que la séquence GAR_CLI_SEQ a été créée directement par Design Editor. Figure 8 - Tables et séquences du modèle relationnel Article 1-9/17- Août 2005

2.4.5 5 ème phase - Scripts SQL-DDL Le générateur de script SQL-DDL, Server Generator, n est pas accessible depuis le panneau de commande de Designer, il est accessible en tant qu élément exécutable de l outil de conception Design Editor. Le générateur de script SQL-DDL utilise, en entrée, les spécifications contenues dans le modèle relationnel, Server model, et génère, en sortie, un script respectant la norme SQL et/ou les spécificités d un constructeur, respectivement d un produit. Figure 9 - Générateur de script SQL-DDL La figure 10 montre le script généré pour la table GAR_CLIENTS ; nous voyons les colonness d audit, préfixés CTRL, que nous avons ajoutées au moment de l enrichissement pour assurer une forme de traçabilité. Figure 10 - Script de création de table Article 1-10/17- Août 2005

2.4.6 6 ème phase APIs de tables Tout comme pour la génération des scripts SQL-DDL, le générateur d APIs de tables, Server API, utilise, en entrée, les spécifications contenues dans le modèle relationnel, Server model, et génère, en sortie, des scripts sous forme de procédures stockées PL/SQL et de triggers. Les APIs de tables sont une sur-couche propre à Oracle pour enrichir la sémantique mise en place par les scripts de définition de données SQL-DDL. Les APIs de tables interceptent les ordres de manipulation de données et lancent l exécution des procédures stockées qui enrichissent les règles et contraintes mises en places par les scripts SQL-DDL. Figure 11 Couplage entre ordres DML et APIs de tables Figure 12 - Procédure d'api de table La figure 12 montre la procédure up_autogen_columns générée pour la table GAR_CLIENTS ; dans l extrait de code, nous voyons le calcul de la valeur de clé primaire à partir de l interrogation de la séquence GAR_CLI_SEQ. Article 1-11/17- Août 2005

2.4.7 7 ème phase Test de l intégrité de la structure de données Le but de cette phase est de s assurer que les contraintes liées aux données soient effectivement validées par le serveur de données. Pour ce faire, il faut effectuer tous les tests de manipulations de données en passant par l intermédiaire de SQL*Plus ou d autres utilitaires de ce genre. Il est essentiel de procéder rigoureusement à ces tests, car lorsque nous mettons en place une contrainte avec Designer, nous pouvons définir l endroit, serveur de données ou application cliente, où la contrainte doit être vérifiée. Figure 13 - Validation des contraintes Dans le cadre d un développement «manuel» d une application nous implémentons les contraintes relatives aux données sur la base de données ou au niveau du client, voire au niveau du serveur d application. Souvent, nous mettons des contraintes au niveau de l application pour éviter tout trafic superflu sur le réseau. Toutefois, si nous voulons garantir l intégrité absolue des données, il est indispensable de réécrire ces contraintes au niveau du serveur de données pour éviter une violation dans le cas où les données ne sont pas manipulées par l application «usuelle». Tout concepteur rechigne à introduire cette redondance qui est contraire au principe d unicité du code. Avec Designer, nous résolvons élégamment cette problématique ; la contrainte n est définie qu une et une seule fois dans le référentiel, mais elle peut être générée au niveau du serveur et de l application. La génération au niveau de l application sous-entend naturellement que nous générons l application avec Designer. Article 1-12/17- Août 2005

2.4.8 8 ème phase Modélisation logique des traitements (MLT) Design Editor permet la conception «logique» des données sous forme de modèles relationnels mais aussi de traitements sous forme de modules et composants. Figure 14 - MLT / Eléments et notation Designer permet de créer des modèles conceptuels de traitements sous forme de diagrammes d analyse ou de diagrammes de flux de données «DFD, Dataflow Diagram» ; les fonctions ou processus sont transformés, par Application Design Transformer, en modules, tout comme les entités au niveau des données sont transformées, par Database Design Transformer, en tables. Ensuite, ces modules peuvent être enrichis par Design Editor selon un processus de conception proche de celui que nous avons décrit pour les données. Toutefois, comme nous n avons pas retenu cette possibilité dans notre choix méthodologique, nous créons les modules, modèles de traitement logiques, directement avec Design Editor. Les modules de Design Editor se partitionnent en composants. Un composant permet de «manipuler» une table dite de base ; manipuler, dans le sens d appliquer les opérations d ajout, de modification ou de suppression. Une table peut être associée à une ou plusieurs tables de références ; l association est proposée automatiquement à partir de la structure du modèle relationnel de données. Les composants peuvent être liés entre eux ; les liens sont proposés à partir des relations existantes entre les tables de bases des composants respectifs. Article 1-13/17- Août 2005

2.4.8.1 Génération des modules Web PL/SQL Lors de la conception d un module, nous indiquons la nature de la génération de code à produire par la propriété Language. A partir du choix du langage de génération, le concepteur disposera de propriétés spécifiques à la cible choisie ; par contre, le concepteur pourra toujours générer un module pour une cible différente. La figure 15 montre les différentes cibles possibles de génération de module. Figure 15 Choix des générateurs de modules Le concept des modules Web PL/SQL s apparente aux pages JSP et servlets ; il s agit de procédures aptes à fournir des pages HTML dont le contenu est adapté dynamiquement à l évolution des données manipulées. La particularité de Web PL/SQL concerne la manière de stocker et d exécuter les procédures ; les procédures sont stockées sous formes de paquetages dans la base de données, elles sont exécutées sous forme d invocation distante s apparentant à RMI. Le générateur Web PL/SQL s appuie sur plusieurs librairies ou paquetages installés dans la base de données cible de la génération : la librairie HTML pour le Web d Oracle, dénommée PL/SQL Web Toolkit ; pour l essentiel, cette librairie encapsule les balises HTML à l intérieur de fonctions ou procédures PL/SQL ; la librairie du générateur Web PL/SQL, paquetages préfixés WSG, à partir de laquelle le contenu dynamique des pages HTML est généré; les APIs des tables qui sont manipulées par les modules. Figure 16 - Générateur Web PL/SQL Article 1-14/17- Août 2005

2.4.9 9 ème phase Test de l application Les modules générés sont testés à partir d un navigateur. Pour que les modules puissent être exécutés via une adresse URL, il faut disposer d une passerelle qui convertisse l URL en une invocation de procédure PL/SQL se trouvant dans une base de données. Figure 17 - Formulaire Web PL/SQL Article 1-15/17- Août 2005

2.4.9.1 Passerelle PL/SQL La passerelle PL/SQL est installée comme service du serveur d application Oracle, ias. Cette passerelle doit être configurée par un DAD, Database Access Descriptor. Le DAD permet de définir la base de données qui doit être accédée pour exécuter la procédure PL/SQL qui retournera la page HTML. Le DAD peut contenir les éléments d identification - -utilisateur et mot de passe- et de connexion à la base de données pour offrir un service public dans une vision Internet ; sinon, les éléments d identification sont demandés à l utilisateurs et utilisés pour la connexion à la base de données pour offrir un service «contrôlé» dans une vision Intranet.. Figure 18 - Architecture n-tiers Article 1-16/17- Août 2005

3 Liens utiles 3.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 le cahier «01 Prise en main» traite des notion élémentaires présentées succinctement dans cet article. 3.2 Mise en pratique Les notions que nous avons présentées dans cet article peuvent être mise en œuvre en suivant la partie pratique du cahier «01 - Prise en main» de notre sous-site «Les bases» de la version 6i de Designer. 3.3 Références L auteur Pierre-André Sunier pierre-andre.sunier@he-arc.ch HES-SO Haute Ecole Spécialisée de Suisse occidentale www.hes-so.ch HEG-NE Haute Ecole de Gestion de Neuchâtel www.he-arc.ch ISNet Génie logiciel Site Designer Projet ISNet-14 Centre de compétences Systèmes d information et informatique de gestion Articles du laboratoire de génie logiciel sous la rubrique «Génie logiciel» Notre site de formation consacré à Designer et ses soussites Projet de recherche appliquée ISNet-14 Atelier de génie logiciel et génération Web http://www.is-net.ch/ http://lgl.isnetne.ch/ http://lgl.isnetne.ch/designer6i /index.htm http://lgl.isnetne.ch/isnet14/in dex.htm Article 1-17/17- Août 2005