73
Travail de diplôme d’informaticienne de gestion HES Evaluation du couplage entre Designer & JDeveloper d’Oracle Cahier pratique Etudiante Astrid von Wyl Directeur du travail Pierre-André Sunier Date de restitution Février 2005 Cycle d’études Plein temps 2003-2005

Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

  • Upload
    lexuyen

  • View
    218

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Travail de diplôme d’informaticienne de gestion HES

Evaluation du couplage entre Designer & JDeveloper d’Oracle

Cahier pratique

Etudiante Astrid von Wyl Directeur du travail Pierre-André Sunier Date de restitution Février 2005 Cycle d’études Plein temps 2003-2005

Page 2: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Table des matières 1. Introduction.....................................................................................................................4 2. Outil .................................................................................................................................6

2.1. Espace de travail ......................................................................................................6 2.2. Créer un projet..........................................................................................................7 2.3. Connexion ................................................................................................................7 2.4. Diagramme ...............................................................................................................9 2.5. Propriétés d’une entité............................................................................................11

2.5.1. Name ..............................................................................................................11 2.5.2. Attributs...........................................................................................................11 2.5.2.1. Contraintes..................................................................................................15

2.5.2.2. Séquences ..............................................................................................16 2.5.3. Autres nœuds de la fenêtre des propriétés d’une entité.................................17

2.6. Associations ...........................................................................................................17 2.7. Vues .......................................................................................................................19 2.8. Composants modules .............................................................................................22

3. Couche modèle.............................................................................................................25 3.1. Génération d’applications à partir de nos propres spécifications ...........................25 3.2. Importation d’un module depuis Oracle Designer...................................................25

3.2.1. Perte /conservation d’information lors de l’importation ...................................28 3.3. Génération d’applications à partir de modules Designer avec scripts d’ APIS et SQL-DDL............................................................................................................................28

3.3.1. Module avec table de référence .....................................................................28 3.3.2. Module avec LOV ...........................................................................................31 3.3.3. Module maître-détail avec entité associative..................................................33 3.3.4. Module avec champs calculés........................................................................35 3.3.5. Lien réflexif .....................................................................................................35

3.4. Synthèse de l’importation .......................................................................................37 3.4.1. Clé primaire ....................................................................................................38 3.4.2. Champs d’audit et domaines ..........................................................................39 3.4.3. Validation ........................................................................................................39 3.4.4. Vues et modules .............................................................................................39 3.4.5. Navigation.......................................................................................................39 3.4.6. Enrichissement du module et synchronisation ...............................................40

4. Couche view/controller ................................................................................................41 4.1. ADF UIX .................................................................................................................42

4.1.1. LOV.................................................................................................................45 4.1.2. Types ..............................................................................................................46

4.2. JSP .........................................................................................................................46 4.2.1. LOV.................................................................................................................48 4.2.2. Types ..............................................................................................................49

4.3. Java Client..............................................................................................................49 4.3.1. LOV.................................................................................................................50

23.03.2005 2 sur 73 Astrid von Wyl

Page 3: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

4.4. JHeadstart ..............................................................................................................51 4.4.1. LOV.................................................................................................................53 4.4.2. JSP .................................................................................................................54

4.4.2.1. JSP avec LOV.........................................................................................55 4.4.3. Types ..............................................................................................................55 4.4.4. Personnalisation des applications ..................................................................55

4.5. Remarques .............................................................................................................55 4.6. Affichage d’un module avec table de référence......................................................56

4.6.1. Web Client ......................................................................................................56 4.6.2. Java Client ......................................................................................................56

5. Application garage .......................................................................................................57 5.1. Importation..............................................................................................................60 5.2. Affichage, couche vue ............................................................................................61

5.2.1. Champs calculés ............................................................................................61 5.2.2. ADFUIX...........................................................................................................62

5.2.2.1. Erreur ......................................................................................................63 5.2.3. JSP .................................................................................................................63 5.2.4. Java Client ......................................................................................................65 5.2.5. JHeadstart ......................................................................................................66

6. Evaluation du couplage ...............................................................................................68 7. Conclusion....................................................................................................................69 8. Annexes.........................................................................................................................70

8.1. Figures....................................................................................................................70 8.2. Options du fichiers ApplicationStructure.xml ..........................................................71

9. Remerciements.............................................................................................................72

23.03.2005 3 sur 73 Astrid von Wyl

Page 4: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

1. Introduction

Le but de cette partie pratique est de montrer une partie des possibilités d’utilisations de JDeveloper. L’outil est d’abord utilisé seul, puis en couplage avec Designer. Les tests se font autant pour la couche modèle que pour la couche vue des applications. Dans tout le travail, je pars du principe qu’Oracle Designer est connu du lecteur.

Ma démarche est la suivante, tout d’abord, j’ai commencé par me familiariser avec l’outil en suivant les cahiers 1 à 3 du cours d’AGL1. Ces cahiers traitent des points suivants :

de la structure du référentiel, de la modélisation conceptuelle de données, du passage du niveau conceptuel au niveau logique, de la modélisation logique de données, de la génération des scripts SQL-DDL, de la génération des APIs de table, du modèle de traitement, de la génération des procédures PL/SQL de création de pages HTML dynamiques, de l’utilisation des modules de traitement via IAS, des mécanismes de notification, des types de données, des clés secondaire, des associations, des champs d’audit, des journaux de table, du mécanisme de consolidation de bases de données, des propriétés d’affichage, des tables de références, des listes de valeurs de référence, des cardinalités des associations, des attributs des associations 1 :1 et 1 :N, des contraintes, des formulaires maître-détails, des associations non transférables, des associations identifiantes, des contraintes d’intégrité référentielles, des contraintes d’unicité d’association, des champs calculés

Dans le chapitre outil, j’étudie ces notions au fur et à mesure de ma progression dans la compréhension de l’outil.

JDeveloper repose sur le modèle MVC (modèle-vue-contrôleur). C’est pourquoi la suite du cahier est décomposé en deux parties : vue et modèle. Le deuxième chapitre est consacré à la couche modèle d’une application. Pour travailler dans cette couche, je réalise deux connexions, la première à une base de données et la seconde à une instance de l’AGL Designer. J’utilise JDeveloper pour spécifier les entités d’une application, puis je génère le modèle de base de données associé. Je fais ensuite des essais avec Designer. J’importe un module Clients-Representants depuis Designer pour étudier la manière dont JDeveloper traite ces informations. Les « applications » de cette couche sont ensuite testées.

Le troisième chapitre est consacré à la couche vue du modèle MVC. Pour tester cette couche, je reprends trois modules de Designer : un module Clients, un module Clients-Représentants (table de référence), un module Clients-représentants (avec LOV). 1 Voir le site http://zuse.esnig.cifom.ch/analyse/designer6i/index.htm

23.03.2005 4 sur 73 Astrid von Wyl

Page 5: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Pour chacun de ces modules, je vais expérimenter les trois manières de procéder possibles. La couche vue peut être soit un client java, soit un client web. Ce dernier peut être réalisé à l’aide de deux technologies : ADF UIX et JSP. Suite à mes recherches, je réalise également une application complète avec JHeadstart.

La quatrième chapitre est consacré à une application développée avec Designer. Il s’agit d’une application de gestion des réparations dans un garage. Le but du quatrième chapitre est de générer l’application avec les trois possibilités de la couche vue et JHeadstart qui est une extension de JDeveloper.

J’ai choisi ce sujet, car j’estime qu’il contient un bon équilibre entre théorie et pratique. De plus j’ai l’impression que la partie théorique peut être vérifiée par la pratique. J’ai une préférences pour les sujets qui touchent un domaine inconnu.

23.03.2005 5 sur 73 Astrid von Wyl

Page 6: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

2. Outil

Pour pouvoir utiliser l’outil JDeveloper, il faut définir un espace de travail, un projet et une connexion à une base de données.

2.1. Espace de travail Pour créer l’espace de travail, il faut choisir dans le navigateur l’onglet Applications(Figure 1) et avec un click-droit sur la racine de l’arborescence Applications dérouler le menu (Figure 2)

. Figure 1

Figure 2

Sélectionner New Application Workspace. L’assistant de création d’espace de travail est déployé (Figure 3).

Figure 3

Pour pouvoir profiter d’ADF BC, les modèles d’application à utiliser sont :

Java Application [Default] : Génère un projet ADFJclient et un projet ADF BC. Web Application [Default] : Génère un projet pour la couche vue + contrôleur et un

autre pour la couche modèle. Web Application [Default, no controller] : Génère un projet pour la couche vue et un

autre pour la couche modèle, pas de contrôleur.

23.03.2005 6 sur 73 Astrid von Wyl

Page 7: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

2.2. Créer un projet Dans l’arborescence du navigateur de l’onglet Application, dérouler le menu sur l’application choisie et cliquer sur >New. Ensuite, sélectionner le type de projet que l’on souhaite créer (Figure 4).

Figure 4

Pour chaque projet il est possible d’éditer des propriétés. A cet effet, choisir le menu Tools> Project properties. Parmi les propriétés, il y a la définition d’une connexion à une base de données, le choix des technologies qu’il est possible d’utiliser dans le projet, p.ex. EJB, Struts, UML. D’autres propriétés définissent les classes java qui seront créées, les chemins etc..

La définition du projet est contenue dans un fichier à l’extension .jpx (Figure 5). Ce fichier est visible depuis l’onglet system. <?XML version='1.0' encoding='windows-1252' ?> <!DOCTYPE JboProject SYSTEM "jbo_03_01.dtd"> <JboProject Name="Project" SeparateXMLFiles="true" PackageName="" > <DesignTime> <Attr Name="_version" Value="9.0.5.16.0" /> <Attr Name="_jprName" Value="../Project.jpr" /> <Attr Name="_ejbPackage" Value="false" /> <Attr Name="_NamedConnection" Value="ConnexionG04" /> </DesignTime> <Containee Name="mypackage" FullName="mypackage.mypackage" ObjectType="JboPackage" > </Containee> </JboProject>

Figure 5

2.3. Connexion Pour établir la connexion à une base de données avec Oracle JDeveloper 10g, dans le navigateur, choisir l’onglet connections (Figure 6) et développer dans l’arborescence le nœud Database (Figure 7).

Figure 6

23.03.2005 7 sur 73 Astrid von Wyl

Page 8: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 7

Dérouler le menu avec click-droit sur le type de connexion voulu > New Database connection. L’assistant de création de connexion apparaît, il faut alors saisir les paramètres JDBC suivants : Connection Name : ConnectionG02 Connection type : Oracle(JDBC) |JDBC-ODBC Bridge | Oracle Lite | Third Party JDBC Drive Username: DIPL04AVW_G02 Password:******* Role: - Driver: thin Host Name: leto.cpln.ch JDBC Port: 1521 SID: es28

Figure 8

La dernière étape de l’assistant offre la possibilité de tester la connexion et de corriger d’éventuelles erreurs.

L’arborescence du nœud Database (Figure 7) s’agrandit, un nœud pour chaque type d’objet de la base de donnée est crée (Figure 9).

Figure 9

Les objets contenus dans la base de données peuvent être visualisés en déroulant le nœud correspondant dans l’arborescence. La connexion est visible dans la fenêtre de structure (Figure 10).

Figure 10

Les données liées à la connexion se trouvent dans le fichier bc4j.xcfg. Il contient notamment les paramètres JDBC, le nom des modules, leur portée. Ce fichier est visible depuis l’onglet system.

23.03.2005 8 sur 73 Astrid von Wyl

Page 9: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

<?XML version = '1.0' encoding = 'UTF-8'?> <BC4JConfig> <AppModuleConfigBag> <AppModuleConfig name="ClientsAppModuleLocal"> <AppModuleJndiName>ClientsPackage.ClientsAppModule</AppModuleJndiName> <DeployPlatform>LOCAL</DeployPlatform> <JDBCName>ConnexionG04</JDBCName> <ApplicationName>ClientsPackage.ClientsAppModule</ApplicationName> <jbo.project>Clients</jbo.project> </AppModuleConfig> </AppModuleConfigBag> <ConnectionDefinition name="ConnexionG04"> <ENTRY name="JDBC_PORT" value="1521"/> <ENTRY name="ConnectionType" value="JDBC"/> <ENTRY name="HOSTNAME" value="leto.cpln.ch"/> <ENTRY name="user" value="dipl04avw_G04"/> <ENTRY name="ConnectionName" value="ConnexionG04"/> <ENTRY name="SID" value="es28"/> <ENTRY name="JdbcDriver" value="oracle.jdbc.driver.OracleDriver"/> <ENTRY name="password"> <![CDATA[{904}0516E666252DCC0C13E894B6904A2696C]]> </ENTRY> <ENTRY name="ORACLE_JDBC_TYPE" value="thin"/> <ENTRY name="DeployPassword" value="true"/> </ConnectionDefinition> </BC4JConfig>

Figure 11

2.4. Diagramme Dans Oracle JDeveloper 10g, à l’aide du business components diagram, il est possible de spécifier ou de représenter des entités. Pour créer ce diagramme, cliquer sur le projet NEW> General >Diagrams (Figure 12).

Figure 12

Les objets que l’on peut mettre dans ce diagramme sont proposés par la palette des composants (Figure 13).

23.03.2005 9 sur 73 Astrid von Wyl

Page 10: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 13

Une entité spécifiée avec ce diagramme se présente de telle façon (Figure 14):

Figure 14

Figure 15

La fenêtre de structure (Figure 15) montre la structure de l’entité.

A partir du diagramme, il est possible de procéder à deux générations :

23.03.2005 10 sur 73 Astrid von Wyl

Page 11: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Default Data Model Components : Génère le composant module correspondant aux spécifications des entités ainsi que des vues et les liens vues.

Database objects : Génère la table correspondant aux spécifications dans un schéma de base de données.

2.5. Propriétés d’une entité Pour une entité, on peut définir des attributs. Ces attributs ont un type en tant qu’attribut d’une entité et en tant que colonne dans une table. Il y a neuf nœuds dans la fenêtre des propriétés d’un attribut : Name, Attributes, Tuning, Java, Validation, Publish, Suscribe, Authorization, Custom properties. Je les décris un à un ci-dessous.

2.5.1. Name Si l’entité est la définition d’une table déjà existante, choisir la connexion à un schéma et la table à laquelle l’entité est liée :

Figure 16

2.5.2. Attributs Les colonnes qui existent dans la table mais qui ne se trouvent pas sous forme d’attribut dans l’entité sont générées après que l’on ait lié l’entité à une table (Figure 16). Selon les besoins, des attributs sont définis dans l’entité mais de manière non persistante. Ils n’existent pas sous forme de colonne de la table. Pour chaque attribut créé, des propriétés sont définies :

23.03.2005 11 sur 73 Astrid von Wyl

Page 12: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 17

Persistent : Persistance ou non d’un attribut Mandatory : Attribut obligatoire ou non. Si la case est cochée, une contrainte not null

est générée. Discriminator : La case est cochée si cet attribut permet de distinguer une entité

polymorphe d’une autre. En effet, JDeveloper regroupe les objets polymorphes dans une seule classe.

Change indicator 2: Il faut cocher cette case si la colonne est un indicateur de changement, par exemple un timestamp. La plate-forme ADFBC utilise cet indicateur pour déterminer si un tuple a déjà été modifié dans une autre transaction ou peut être verrouillée. S’il n’y pas de colonne spécifiée comme indicateur de changement, une comparaison colonne par colonne est effectuée.

Selected in query : L’attribut apparaît dans la requête SQL de la vue. Primary key : Attribut de clé primaire. Si la case est cochée , une contrainte de clé

primaire est générée. Unique: Définit si l’attribut est unique ou non. Si la case est cochée, une contrainte

d’unicité est générée. Queriable: Attribut qui apparaît dans les formulaires de recherches. History column: Champ d’audit. (created on | modified on | created by | modified by|

version number). Ne fonctionne pas si l’attribut a les propriété suivantes: clé primaire, obligatoire ou discriminant,

Updateable : L’attribut peut-il être mis à jour ? While new s’utilise pour les clés primaires par exemple. Always pour un numéro de téléphone par exemple et Never pour un attribut d’une table de lookup.

Refresh after : Si un trigger existe, cocher la case correspondante au type de trigger. Database column : Définit le nom de la colonne dans la table ainsi que son type.

Le fichier Impl.java (Figure 18) dépend directement des ces propriétés. Par exemple Updateable never a pour conséquence qu’aucune méthode set () n’est écrite pour l’attribut.

2 Traduit de l’aide en ligne

23.03.2005 12 sur 73 Astrid von Wyl

Page 13: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 18

L’onglet Attribute properties (Figure 19) contient des attributs qui se trouvent dans les méta données. Ces propriétés se trouvent dans le fichier XML associé à l’entité. Ci-dessous, les propriétés sont extraites automatiquement lors d’une importation d’un module depuis Designer.

Figure 19

Par défaut, on peut choisir entre quatre noms Description | File name | XML element | XML Explicit null. Un autre nom de propriété peut être défini, par exemple prompt (Figure 19))

Il n’y a pas de lien entre ces propriétés et celles définies dans les autres onglets, par exemple display et la propriété display de l’onglet décrit ci-dessous. Ces propriétés sont utilisées selon le besoin lors de l’exécution.

Les propriétés des entités sont liées au fichier XML correspondant à l’entité. Celui-ci contient les propriétés décrites ci-dessus. En voici un extrait :

23.03.2005 13 sur 73 Astrid von Wyl

Page 14: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

<Attribute Name="Nom" IsNotNull="true" Precision="255" ColumnName="NOM" Type="java.lang.String" ColumnType="VARCHAR2" SQLType="VARCHAR" TableName="MON_CLIENT" > <Data> <Property Name ="ID" Value ="901fd421-0101-1000-7::mypackage1.EntityObject1::EntityObjectAttribute" /> <Property Name ="CHANGEABILITY" Value ="CHANGEABLE" /> <Property Name ="OWNER_SCOPE" Value ="INSTANCE" /> <Property Name ="MULTIPLICITY" Value ="1" /> <Property Name ="VISIBILITY" Value ="PACKAGE" /> </Data> </Attribute>

Figure 20

L’onglet control hints permet de définir des paramètres d’affichage pour l’attribut :

Figure 21

Display hint : Display | hide affiche ou non l’attribut. Label text : Etiquette qui correspond à l’attribut. Tooltip text : Texte qui sera contenu dans l’information relative à l’attribut. Format type : Par exemple Date. Format : Selon le type de l’attribut, différents formats sont proposés, par exemple

(yyyy-mm-dd) si Format type = Date. Control type : Date | Edit | Default . Date affiche un calendrier, edit rend le contrôle de

champ éditable et default le client choisit le plus approprié. Display width : Largeur du champ. Display height: Hauteur du champ. Form Type : Détermine le type d’affichage: Detail | summary. Le type detail aligne

tous les attributs dans une colonne Summary les affiche sous forme de grille. Cette propriété n’est valable que pour les couches vues de types Jclient.

Lorsque l’on saisit des valeurs dans l’onglet control hints, un fichier ImplMsgBundle.java est créé pour l’entité (Figure 22). Ce fichier correspond au contenu de l’onglet control hints.

23.03.2005 14 sur 73 Astrid von Wyl

Page 15: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

package mypackage1.common; import oracle.jbo.common.JboResourceBundle; public class MonClientImplMsgBundle extends JboResourceBundle { public MonClientImplMsgBundle() { } public Object[][] getContents() { return super.getMergedArray(sMessageStrings, super.getContents()); } static final Object[][] sMessageStrings = { {"Nom_LABEL", "Nom du client"}, {"Nom_DISPLAYWIDTH", "50"}}; }

Figure 22

2.5.2.1. Contraintes Les contraintes sont générées à partir des propriétés définies pour les attributs. Elles sont définies dans le fichier XML correspondant à l’entité (Figure 23). <Key Name="MonClientNumeroCheck" > <AttrArray Name="Attributes"> <Item Value="mypackage1.MonClient.Numero" /> </AttrArray> <DesignTime> <Attr Name="_DBObjectName" Value="MON_CLIENT_NUMERO_CHECK" /> <Attr Name="_checkCondition" Value="&#34;NUMERO&#34; IS NOT NULL" /> <Attr Name="_isNotNull" Value="true" /> <Attr Name="_isCheck" Value="true" /> </DesignTime> </Key> <Key Name="MonclientPrimaryKey" > <AttrArray Name="Attributes"> <Item Value="mypackage1.MonClient.Numero" /> </AttrArray> <DesignTime> <Attr Name="_DBObjectName" Value="MONCLIENT_PRIMARY_KEY" /> <Attr Name="_isPrimary" Value="true" /> </DesignTime> </Key>

Figure 23

Contrainte not null : Il faut cocher la case mandatory dans les propriétés de l’attribut. Cette contrainte permet d’éviter que Oracle JDeveloper 10g interroge la Base de données mais vérifie lui-même la validité d’un champ.

Contrainte de clé primaire : La case à cocher primary key dans les propriétés de l’attribut permet de spécifier la clé primaire. Si une table n’a pas de clé primaire qui est spécifiée, Oracle JDeveloper 10g crée une clé primaire basée sur la pseudo-colonne ROWID.

Contrainte d’unicité : La case à cocher unique génère une contrainte d’unicité.

Contrainte de check : Définir une nouvelle contrainte (Figure 24). Par défaut JDeveloper crée des contraintes de type check pour les contraintes not null.

Une contrainte peut être créée à partir d’une entité ou par click-droit sur l’entité <New Entity Constraint .

23.03.2005 15 sur 73 Astrid von Wyl

Page 16: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 24

Mandatory : La colonne est obligatoire. Deferrable validation : La vérification de la contrainte peut être effectuée à la fin de la

transaction. Disable validation : Désactive la contrainte, efface les indexes et interdit toute

modification de la colonne concernée par la contrainte. Toute nouvelle colonne ou colonne modifiée peut violer la contrainte.

Enable validation, validate existing data : La contrainte est vérifiée et doit être respectée pour toutes les nouvelles données et pour les données existantes.

Enable validation : Les anciennes valeurs ne sont pas vérifiées, seules les nouvelles insertions sont contrôlées.

Les contraintes sont visibles dans la fenêtre de structure (Figure 25).

Figure 25

Remarque : La clé secondaire que l’on trouve dans Designer doit être spécifiée comme une contrainte d’unicité.

2.5.2.2. Séquences

Il existe un type DBSequence pour définir la clé primaire dans les propriétés de l’entité. Le fait de choisir DBSequence comme type met automatiquement updateable à while new, met en grisé refresh after insert, coche la case queriable et ajoute un onglet sequence à côté de database column. L’onglet séquence permet de définir un nom pour la séquence dans le schéma de base de données (Figure 26).

Figure 26

23.03.2005 16 sur 73 Astrid von Wyl

Page 17: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

2.5.3. Autres nœuds de la fenêtre des propriétés d’une entité Tuning: Permet de définir le nombre d’enregistrements modifiés qui seront envoyés

en même temps à la base de données. Ne fonctionne pas si refresh on update or insert est coché.

Java: Définition des classes java qui seront générées pour l’entité. Validation : Le nœud validation permet de définir des règles des validation, par

exemple, la valeur d’un attribut doit être plus grande que 10 ou comprise entre 60 et 900. Un message d’erreur personnalisé peut être rédigé afin de savoir quelle règle a été violée. Ces règles de validation permettent de réaliser la validation dans l’application et évitent ainsi un trafic réseau inutile.

Publish: Crée un événement lié à l’entité. Suscribe: Choix des événements auxquels l’entité va réagir. Authorization: Gestion des droits d’accès à l’entité ou à un ou plusieurs de ses

attributs. Custom properties: Permet d’ajouter des descriptions dans les méta données.

2.6. Associations Une association entre deux entités peut être dessinée sur le diagramme de type business components diagram. Elle y est représentée par : ou l’une des variantes de multiplicité. Une autre façon de définir une association est de cliquer sur New>Association sur l’entité ou le package. Les propriétés de l’association sont : (Figure 27)

Figure 27

Sur la Figure 27, on définit la source et la destination de l’association.

Les associations sont orientées par défaut dans les deux sens. C’est à dire que pour les deux extrémités de l’association une instance de l’entité source peut accéder à une instance de l’entité destination. Pour enlever cette orientation, il faut enlever les accesseurs. On accède aux définitions des accesseurs par le nœud association properties (Figure 28).

23.03.2005 17 sur 73 Astrid von Wyl

Page 18: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 28

Expose Accessor : Autorise l’accès à l’entité source via cet accesseur Use Database Key Constraints: Création de contraintes de niveau entité. La

contrainte de clé étrangère va être créée afin de représenter l’association. Le fait de décocher cette case n’efface pas les contraintes déjà générées.

Composition Association: Créer une composition. Dans une composition la destination fait logiquement partie de la source.

Optimize for Database Cascade Delete: Empêche la base de données de générer du code DML qui efface chaque tuple de destination.

Implement cascade DELETE : Implémente DELETE cascade dans le middle-tier Cascade Update Key Attributes: Les attributs de la destination changent si la source

change. Lock Top-level Container: Verrouille la source lorsque la destination est verrouillée. Update Top-Level History Columns: Met à jour les champs d’audit de la source

lorsque la destination est modifiée.

Si un accesseur existe seulement dans la source, l’association est unidirectionnelle et ne peut être traversée que de la source à la destination. Dans notre cas, si l’accesseur existe sur Representants uniquement, cela signifie que des enregistrements de la destination, en l’occurrence Clients sont retournés.

Figure 29

Le fichier XML correspondant à l’association contient la propriété suivante pour la destination de l’association, en l’occurrence Clients. ExposedAccessor="false"

Aucun accesseur n’est disponible pour une instance de l’entité Clients. Par contre une instance de l’entité représentants accède à des instances de l’entité Clients. Le sens de la flèche montre cette situation.

23.03.2005 18 sur 73 Astrid von Wyl

Page 19: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 30

La manière de spécifier les associations influence la navigation dans les composants modules.

2.7. Vues Une vue est une représentation d’une table ou vue de la base de données. Mais elle possède des informations supplémentaires à celles contenues dans la base de données, par exemple des champs calculés. La vue contient la requête de type SELECT qui est exécutée sur le schéma de base de données. Une vue peut se référer à plusieurs entités.

Les vues n’ont pas les mêmes propriétés que les entités. Les attributs d’une vue se composent des nœud suivants (Figure 31 ):

Figure 31

Entity objects : Ce nœud permet de définir quelles entités composent la vue. Attributes : Montre les attributs disponibles et ceux qui sont sélectionnés. Les

attributs sélectionnés feront partie de la requête. Dès lors, les champs d’audit sont de trop. Ils n’ont pas besoin d’apparaître dans le formulaire de test de module. Les attributs numero qui font partie d’une relation sont obligatoires.

Query : La requête représentée est un select des attributs sélectionnés dans la vue. Il est possible de personnaliser la requête en cochant la case expert mode. Mais dès lors « un retour en arrière implique la perte d’informations ».3 La requête peut contenir une clause where et définir un order by.

3 Extrait de l’ Aide en ligne

23.03.2005 19 sur 73 Astrid von Wyl

Page 20: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

SELECT LReprEntityUsage.NOM, LReprEntityUsage.PRENOM, LReprEntityUsage.MNEMO, ClientsEntityUsage.NUMERO, ClientsEntityUsage.REPR_NUMERO, ClientsEntityUsage.NOM AS NOM1, ClientsEntityUsage.PRENOM AS PRENOM1, ClientsEntityUsage.RUENO, ClientsEntityUsage.CODEPOSTAL, ClientsEntityUsage.LOCALITE, LReprEntityUsage.NUMERO AS NUMERO1 FROM CLIENTS ClientsEntityUsage, REPRESENTANTS LReprEntityUsage WHERE (ClientsEntityUsage.REPR_NUMERO = LReprEntityUsage.NUMERO)

Figure 32

Attribute mapping (Figure 33) : On établit le lien entre les colonnes de la table de la base de données et les attributs de la vue. Pour pouvoir éditer ces propriétés, il faut cocher la case expert mode dans le nœud query. A partir de là, on peut personnaliser en cas de besoin, la relation entre les colonnes des tables et les attributs des vues. Une colonne de la table (si elle n’est pas obligatoire) peut n’être liée à aucun attribut.

Figure 33

Tuning (Figure 34): Offre la possibilité de définir la façon dont les données sont extraites de la base de données.

Figure 34

« 1. As Needed: Le resultset demeure ouvert et les tuples sont retrouvés au fur et à

mesure que l’utilisateur navigue. Lorsque la fin du resultset est atteinte, celui-ci est fermé.

2. All at Once: Tous les tuples sont retrouvés même si l’utilisateur ne navigue pas. Une fois que tous les tuples ont été retrouvés le resultset est fermé. Utile si le nombre de tuples est faible.

3. Page-by-Page Iteration Mode: Si on souhaite éviter la répétition des données Allow Partial Last Page, sinon (Keep Last Page Full )la dernière page est remplie avec des risques de doublons.

23.03.2005 20 sur 73 Astrid von Wyl

Page 21: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

4. Fetch Size : Indique le nombre de tuples que l’on souhaite capturer à la fois lorsque As needed est sélectionné.

5. Maximum Fetch Size : Définit le nombre maximal de tuples à capturer. 6. Query Hint : Permet d’optimiser ou non une requête. 7. Enable Passivation: Si la case est décochée, les modifications sur des attributs

persistants ou dérivés seront enregistrées mais le cache de la vue sera vide et la requête devra être exécutée à nouveau si on veut voir les nouvelles données.

8. For all Transient Attibutes: Les modifications des attributs transients sont écrit en cache. »4

Java (Figure 35): Définition des classes java générées. Par défaut seule une classe est générée pour la vue, mais une classe peut aussi être générée pour les tuples. Si la case est cochée pour les tuples, un fichier .java supplémentaire est crée. Celui-ci contiendra les accesseurs des attributs qui se trouvaient auparavant dans la classe correspondant à la vue.

Figure 35

Client interface : Les méthodes que nous avons écrites peuvent être choisies. Ces méthodes implémentent l’interface serializable. L’interface serializable indique qu’une classe peut être sérialisée, c’est-à-dire qu’un objet peut devenir persistant. L’interface permet d’envoyer ou de recevoir des objets au travers d’inputstream et outpustream

Client Row Interface : Contient des méthodes si dans le nœud java generate Java file de view row class est coché.

Les vues sont décrites, comme les entités, dans un fichier XML et un ou deux fichiers java (cela dépend du fait que des propriétés d’affichage aient été définies).

Les liens vues reposent également sur un fichier XML. Les nœuds des propriétés de la fenêtre d’édition des liens vues sont :

Figure 36

View Objects : On définit la source et la destination du lien vue. Il s’agit d’attributs d’objet vue ou d’une association.

4 Traduit de l’aide en ligne

23.03.2005 21 sur 73 Astrid von Wyl

Page 22: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 37

View link SQL : Requête correspondante au lien vue.

Figure 38

View link properties : Définition d’accesseurs pour le lien vue.

Figure 39

Les propriétés des attributs d’une entité se transmettent normalement aux objets vues qui leur correspondent.

2.8. Composants modules Un composant module est composé d’instances d’objets vues. Dans le référentiel Oracle Designer, le module produit se présente ainsi :

23.03.2005 22 sur 73 Astrid von Wyl

Page 23: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 40

Dans Oracle JDeveloper 10g, ce même module, une fois importé, a l’apparence suivante :

Figure 41

Voici l’exemple de deux vues :

Figure 42

Le contenu du composant module sera utilisé lors de l’affichage de l’application. Les propriétés du composant module sont :

Data model : On choisit parmi les objets vues du projets ceux qui vont faire partie du composant. Chaque instance d’objet vue a un nom différent qui est défini ici.

23.03.2005 23 sur 73 Astrid von Wyl

Page 24: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 43

Application module : Référence à un autre composant module qui se trouve dans le même projet.

Java : Définition des fichiers java qui seront générés. Remote : Lorsque le déploiement de l’application ne se fait pas en local, on peut

choisir entre deux configurations : EJB session bean et J2EE web services.

Figure 44

Client Interface : Choix des méthodes qui pourront être appelées par le client.

Custom properties : Ajout de données dans les méta données.

Lorsque je teste un module, le contenu du champ numero est incrémenté automatiquement mais le nombre est négatif et décrémenté au fur et à mesure des insertions. Selon le livre [DKF10g] , la valeur affichée n’a aucun rapport avec la valeur en cache. C‘est effectivement le cas. Dans la table, malgré que –4 ait été affiché, la valeur

insérée est la valeur de la séquence. Il faut veiller à cliquer sur si on ne veut plus

ajouter de nouvel enregistrement, sinon si on clique sur ajouter un nouvel enregistrement vide est créé et les contraintes not null provoquent des erreurs.

23.03.2005 24 sur 73 Astrid von Wyl

Page 25: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

3. Couche modèle

3.1. Génération d’applications à partir de nos propres spécifications Tout d’abord, je crée les entités et je les représente dans un diagramme. A partir de celui-ci je génère les vues, liens vues et le module avec GENERATE Default Data Model Components.

Figure 45

Je génère les tables qui correspondent aux entités à partir du diagramme par GENERATE Data Objects for Diagram ou depuis le nœud du package en cliquant CREATE DATABASE OBJECTS. Après la génération, JDeveloper montre un résumé de ce qui a été généré et propose de voir le code :

Figure 46

Si les tables existent déjà dans le schéma de base de données, indiquer à quelle table est liée chaque entité. Ceci se fait dans les propriétés de l’attribut, onglet Name. Le composant module généré peut être testé.

3.2. Importation d’un module depuis Oracle Designer Pour tester les possibilités d’importations des objets du référentiel depuis Oracle Designer, je crée un nouvel espace de travail de type web application. Dans l’onglet connexion sur le nœud Designer Workarea je définis une connexion au référentiel Designer désiré > New Designer Workarea Connection. Il faut à nouveau saisir les paramètres JDBC (Figure 8). L’étape suivante consiste à choisir l’espace de travail, puis, à nommer la connexion.

Si je déroule le nœud de cette nouvelle connexion, les projets qui se trouvent dans le référentiel apparaissent, pour chaque projet je peux voir les modules qui y sont définis (Figure 47).

23.03.2005 25 sur 73 Astrid von Wyl

Page 26: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 47

Pour importer un module, par exemple CLIEDI, faire un click-droit (Figure 47) sur le module, GENERATE ADF Business Components. Je définis (Figure 48) dans quel espace de travail et dans quel projet de JDeveloper importer ce module. S’ils n’existent pas, il est possible de les créer avec les boutons new.

Figure 48

Il faut donner le nom de la connexion (Figure 49) qui contient les tables utilisées par le module. Cette connexion est une connexion de type Database. Si elle n’est pas définie elle peut l’être avec le bouton new.

Figure 49

Je spécifie le nom du package qui contiendra le composant module, les vues et les entités.

Figure 50

Une fenêtre récapitulative (Figure 51) indique ce qui sera généré et où.

23.03.2005 26 sur 73 Astrid von Wyl

Page 27: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 51

Une fois l’importation terminée, on trouve dans l’espace de travail et dans le projet indiqué sous le nœud Application sources : un module, une vue et une entité qui correspondent au module Designer.

Figure 52

Le fichier extracted.xml (Figure 53) contient toutes les informations liées à l’importation . Ce fichier contient les contraintes, les attributs, les champs calculés, les listes de valeurs etc… <?XML version = '1.0' encoding = 'UTF-8'?> <ModuleContainer> <TableDefinition ID="105" Name="CLIENTS" Alias="CLI" TableType="TABLE"> <ColumnDefinition ID="105" Name="PRENOM" Datatype="VARCHAR2" DecimalPlaces="" DefaultValue="" DefaultValueType="LITERAL" MaximumLength="20" NullIndicator="NOT NULL" DomainReference="" ValidationFailureMessage="" AutoGenerated="" DisplayHeight="" DisplayLength="20" DisplayFlag="Y" Prompt="Prenom" OracleTypeReference="" ObjectTypeInclusion="" OrderSequence="" SortingOrder="" ServerDerivedFlag="N" ServerDefaultedFlag="N" DescriptorColumn="" UpperCase="N" FormatModifier=""/> <ConstraintDefinition ID="105" Name="CLI_PK" ConstraintType="PRIMARY" DeferStatus="NOT DEFERRED" MandatoryFlag=""> <KeyComponent ID="105" Name="CLI_PK20" ConstraintType="PRIMARY" ColumnReference="106" ForeignColumnReference=""/> </ConstraintDefinition> </TableDefinition> <Domain ID="1056410" Name="CTRLUSER"/> <ApplicationModule ID="105" Name="CLIENTS" ImplementationName="" ModuleType="DEFAULT" LanguageName="Web PL/SQL" ShortName="CLI" BottomTitle="" ShortTitle="" TopTitle=""> <ModuleComponent ID="105" Name="CLI" InsertFlag="Y" SelectFlag="Y" DeleteFlag="Y" UpdateFlag="Y" RowsDisplayed="" DisplayTitle="Composant de gestion de clients" DataSourceType="QUERY" DataTargetType="PLSQL PROCEDURE" ImplementationItem="" ReqOverflow="" ModuleUnitSubType="SMC"> <TableUsage ID="105" Name="CLI" TableReference="105069019" NameInDatabase="" UsageType="BASE" SelectDistinctFlag="N" LookupOn="" LookupConstraint="" NotExistsFlag="N" OuterJoinFlag="D"> <DataBoundItem ID="105" Name="PRENOM" ContextFlag="Y" Datatype="" ColumnReference="105" DefaultValue="" DefaultValueType="LITERAL" DisplayFlag="Y" DisplayType="TEXT" InsertFlag="Y" SelectFlag="N" DeleteFlag="Y" NullifyFlag="N" UpdateFlag="Y" UsageSequence="30" DisplayHeight="" DisplayWidth="20" HintText="" Prompt="Pr�nom" OrderSequence="" SortingOrder="" DisplayFormat="" ItemGroupReference="" ImplementationItem="" Justification="" ShowMeaning=""/> </TableUsage> </ModuleComponent> <ModuleComponentInclusion ID="105" ModuleComponentReference="14" SubcomponentReference="" ReqPlacement="" RightOfMcnReference="" WindowReference=" " UsageSequence="10"/> <Window ID="108" Name="WINDOW" Title="" ImplementationItem=""/> </ApplicationModule>

Figure 53

23.03.2005 27 sur 73 Astrid von Wyl

Page 28: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

3.2.1. Perte /conservation d’information lors de l’importation Lors de l’importation de la définition d’un module de Oracle Designer vers Oracle JDeveloper 10g les points suivants sont conservés ou non :

Le nom des attributs reste le même. Les champs d’audit sont identifiés comme tel, la case à cocher history column est automatiquement cochée. Les jeux de valeurs, par exemple H, F, sont conservés :

Figure 54

Les LOV sont conservées. Les contraintes demeurent. Les propriétés d’affichage sont également conservées.

Les scripts de génération de table peuvent aussi être visualisés et conservés pour une utilisation ultérieure.

La date et son format ne sont pas repris. Il faut redéfinir le format dans les propriétés de l’attribut onglet control hints. L’un des format proposé est YYYY-MM-DD.

Les séquences ne sont pas exportées. Il faut redéfinir les clés primaires de type DBSequence. Le type pk_numérique, défini sous Oracle Designer n’est pas repris dans Oracle JDeveloper 10g.

La journalisation, la mise en majuscule etc… qui sont gérés par les APIs ne sont bien sûr pas supportés.

3.3. Génération d’applications à partir de modules Designer avec scripts d’ APIS et SQL-DDL

Pour réaliser ces tests je vais utiliser une base de données sur laquelle j’ai exécuté les scripts SQL-DDL et les scripts d’APIs à partir de Designer. Je vais importer un module avec une table de référence, un module avec une LOV et un module maître-détail.

3.3.1. Module avec table de référence Voici le module CLIREPR (Figure 55). Il se compose d’une table de base Clients et d’une table de lookup Representants.

Figure 55

Après importation, les composants business correspondants sont générés. Le package (Figure 56) contient une entité Clients, une entité Représentants, une vue, une association et un module.

23.03.2005 28 sur 73 Astrid von Wyl

Page 29: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 56

Pour l’entité Clients, j’indique que la clé primaire est de type DBSequence et j’indique le nom de la séquence correspondante dans le schéma de base de données.

La table de base Clients a les propriétés suivantes dans la définition de Oracle Designer : Query Insert Update NUMERO YES NOM YES ▲ ▲ PRENOM ▲ ▲ REPR_NUMERO RUENO ▲ ▲ CODEPOSTAL ▲ ▲ LOCALITE ▲ ▲

Tableau 1

Dans Oracle JDeveloper les propriétés de l’entité Clients sont :

Persistent

Mandatory

Change

indicator

Selected in

query

Discrim

inator P

rimary key

Key attribute

Unique

Queriable

History

column

Alw

ays

While N

ew

Never

Numero ▲ ▲ ▲ ▲ Nom ▲ ▲ ▲ ▲ Prenom ▲ ▲ ▲ ▲ Repr-numero ▲ ▲ ▲ Rueno ▲ ▲ ▲ Codepostal ▲ ▲ ▲ Localite ▲ ▲ ▲

Tableau 2

Dans Oracle JDeveloper 10g, les propriétés de la vue sont :

Selected in query

Discriminator Key attribute Queriable Always While New Never

Numero ▲ ▲ ▲ ▲ ▲Nom ▲ ▲ ▲ ▲ Prenom ▲ ▲ ▲ Repr-numero ▲ ▲ Rueno ▲ ▲ Codepostal ▲ ▲ Localite ▲ ▲ Numero1 ▲ ▲ ▲ ▲LReprMnemo ▲ ▲ ▲ ▲ LReprNom ▲ ▲LReprPrenom ▲ ▲

Tableau 3

Query dans Designer et queriable dans JDeveloper ont la même finalité : définir les contrôles de champ qui apparaîtront dans le formulaire de recherche/filtre.

Dans la vue (Tableau 3) la propriété updateable de numero est à never. Ainsi, le champ qui correspondra à cet attribut ne pourra pas être saisi. Il n’a pas à être saisi dans le formulaire car il est alimenté par une séquence. Par contre, pour l’entité, (Tableau 2) le champ numero

23.03.2005 29 sur 73 Astrid von Wyl

Page 30: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

est à updateable while new. Il devrait être à updateable never, car ce champ ne doit pouvoir être saisi. Normalement les propriétés des entités se transmettent aux objets vues.

Il n’est pas possible d’attribuer de représentant à un client avec ces propriétés, il faut que REPRNUMERO puisse être saisi, c’est pourquoi il doit avoir la propriété updateable while new au moins dans la vue.

La table de lookup a les propriétés suivantes : Query Insert Update L_REPR_MNEMO YES ▲ ▲ L_REPR_NOM L_REPR_PRENOM

Tableau 4

Dans Oracle JDeveloper 10g la définition est la suivante pour l’entité Représentants :

Persistent

Mandatory

Change

indicator

Selected in

query

Discrim

inator

Prim

ary key

Key attribute

Unique

Queriable

History

column

Alw

ays

While N

ew

Never

Numero ▲ ▲ ▲ ▲ ▲ Mnemo ▲ ▲ ▲ ▲ ▲ Nom ▲ ▲ ▲ ▲ Prenom ▲ ▲ ▲ Marie ▲ ▲ ▲ Sexe ▲ ▲ ▲ ▲ Salaire ▲ ▲ ▲ Email ▲ ▲ ▲

Tableau 5

La vue définit les attributs de l’entité Représentants comme updateable à never. Cela a pour effet que les propriétés updateable à always de l’entité ne sont pas prises en compte.

La Figure 57 montre la représentation du composant module.

Figure 57

Je teste le composant module. (click-droit test sur le composant module) :

23.03.2005 30 sur 73 Astrid von Wyl

Page 31: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 58

Ce test sur le composant module sert à tester la cohérence des données. Sans modification supplémentaire, le composant module fonctionne correctement, des saisies et mises à jour sont possibles.

3.3.2. Module avec LOV Le module ci-dessous va être utilisé pour la comparaison. Ce module se compose d’une table de base Clients, d’une table de lookup Representants, un composant REPR_LOV et un contrôle de champ.

Figure 59

Après importation, les objets suivants se trouvent dans notre projet dans JDeveloper :

23.03.2005 31 sur 73 Astrid von Wyl

Page 32: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 60

La liste de valeurs est représentée par une vue CLIREPRLOVReprLOVLOVViewObject. Les attributs de cette vue ont comme propriété never updateable. Les propriétés des attributs de l’entité Clients sont les mêmes qu’au point précédent, idem pour l’entité Representants. Toutefois, l’attribut repr-numero a la propriété updateable never dans la vue 1 (Tableau 7). Pour pouvoir attribuer un représentant à un client, il faut au moins avoir la propriété while new. La vue 2 correspond à la liste de valeurs, elle a comme propriétés :

Selected in query

Discriminator Key attribute Queriable Always While New Never

Numero ▲ ▲ ▲ Mnemo ▲ ▲ ▲ Nom ▲ ▲ ▲ Prenom ▲ ▲ DateNaiss ▲ ▲ ▲

Tableau 6

La vue 1 a comme propriétés :

Selected in query

Discriminator Key attribute Queriable Always While New Never

Numero ▲ ▲ ▲ ▲ ▲ Nom ▲ ▲ ▲ ▲ Prenom ▲ ▲ Repr-numero ▲ ◄ Rueno ▲ ▲ Codepostal ▲ ▲ Localite ▲ ▲ Numero1 ▲ ▲ ▲ ▲ LMnemo ▲ ▲ ▲ LNom ▲ ▲ LPrenom ▲ ▲

Tableau 7

La Figure 61 montre la représentation du composant module :

Figure 61

Le test du composant module réussit sans modification supplémentaire.

23.03.2005 32 sur 73 Astrid von Wyl

Page 33: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 62

3.3.3. Module maître-détail avec entité associative Pour tester un module maître-détail, nous importons le module suivant :

Figure 63

Dans JDeveloper, les objets suivants sont générés :

Figure 64

Trois entités sont générées : une pour les fournisseurs, une pour les catégories et une pour distribuent (entité associative). Trois associations sont générées, les deux associations visibles sur la représentation du module ainsi qu’une association réflexive sur Catégories. Le lien vue correspond à l’association entre le maître et le détail. La vue 1 représente distribuent et catégories, la vue 2 correspond à l’entité fournisseurs seule.

L’entité associative que représente l’entité distribuent nécessite quelques modifications. En effet, elle se compose de deux clés primaires qui sont gérées par les APIs. Les deux clés

23.03.2005 33 sur 73 Astrid von Wyl

Page 34: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

primaires cat_numero et four_numero doivent avoir les propriétés suivantes : persistent, primary key, updateable while new et refresh after insert et update.

La vue 1 se compose d’une instance d’entité catégories et d’une instance d’entité distribuent. Ses propriétés sont :

Selected in query

Discriminator Key attribute Queriable Always While New Never

Numero ▲ ▲ ▲ ▲CatCode ▲ ▲ ▲ CatLibelle ▲ ▲ ▲ CatNumero ▲ ▲ ▲FourNumero ▲ ▲ ▲ ▲

Tableau 8

La vue 2 se compose d’une instance d’entité fournisseurs. Ses propriétés sont :

Selected in query

Discriminator Key attribute Queriable Always While New Never

Numero ▲ ▲ ▲RS ▲ ▲ ▲ CodePostal ▲ ▲ ▲ Localite ▲ ▲ ▲

Tableau 9

La représentation du module est la suivante :

Figure 65

Le test du module ne réussit pas. Pour qu’il puisse fonctionner, il faut modifier la propriété de catnumero dans la vue 1 : updateable à while new. Sinon, il n’est pas possible de saisir une catégorie. La Figure 66 montre le test du composant module.

Figure 66

23.03.2005 34 sur 73 Astrid von Wyl

Page 35: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

3.3.4. Module avec champs calculés J’importe un module avec un champ calculé.

Figure 67

Le champ calculé apparaît dans la vue mais pas dans l’entité. Cet attribut n’a pas de colonne correspondante dans la table, donc il n’a pas sa place dans l’entité.

3.3.5. Lien réflexif Pour tester un module Designer qui comporte un lien réflexif comme dans Catégories, le module suivant(Figure 68) est importé dans JDeveloper :

Figure 68

Les composants suivants (Figure 69) sont générés dans JDeveloper, à savoir une entité pour la table de base catégories, deux vues et une association.

23.03.2005 35 sur 73 Astrid von Wyl

Page 36: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 69

L’entité catégorie est représentée de la manière suivante :

Figure 70

Les propriétés des vues sont les suivantes, pour la vue 1 :

Selected in query

Discriminator Key attribute Queriable Always While New Never

Niveau ▲ ▲ ▲ ▲ Code ▲ ▲ ▲Libelle ▲ ▲Numero ▲ ▲ ▲ ▲

Tableau 10

Pour la vue 2 :

Selected in query

Discriminator Key attribute Queriable Always While New Never

Niveau ▲ ▲ ▲ Cat1Code ▲ ▲ ▲ Cat1Libelle ▲ ▲ Numero ▲ ▲ ▲ ▲ Code ▲ ▲ ▲ Libelle ▲ ▲ ▲ ▲ CatNumero ▲ ▲ Numero1 ▲ ▲ ▲ ▲

Tableau 11

Pour la vue 2 , je modifie la valeur display hint à display de l’attribut cat_numero.

Lorsque le composant module est testé, il ne fonctionne pas. Le message d’erreur indique que la clause CONNECT BY est manquante. Dans la vue 1, je modifie la requête en ajoutant la clause CONNECT BY et START WITH (Requête 1). Pour pouvoir modifier la requête dans la vue 1, il faut cocher la case expert mode (Figure 71).

23.03.2005 36 sur 73 Astrid von Wyl

Page 37: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

SELECT LPAD(' ',LEVEL,'_')||CODE AS NIVEAU, CatEntityUsage.CODE, CatEntityUsage.LIBELLE, CatEntityUsage.NUMERO FROM CATEGORIES CatEntityUsage CONNECT BY Prior CatEntityUsage.NUMERO = CatEntityUsage.CAT_NUMERO START WITH CatEntityUsage.CAT_NUMERO IS NULL

Requête 1

Figure 71

La Figure 72 montre le composant module :

Figure 72

La Figure 73 montre le test du composant module.

Figure 73

3.4. Synthèse de l’importation Pour importer un module depuis Designer, je crée un workspace et un projet. Ensuite, je spécifie une connexion à un référentiel Designer, c’est une connexion de type Designer

23.03.2005 37 sur 73 Astrid von Wyl

Page 38: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

workarea. Dans cette connexion, on voit les modules qui existent. Avec click-droit sur le module voulu, je choisis GENERATE ADF Business Components.

Après avoir suivi les instructions de l’assistant d’importation, le module se trouve dans le workspace. JDeveloper transforme le module en un composant module, des vues, des liens vues et des entités.

Ensuite, on se connecte au référentiel, et on exécute les scripts SQL-DDL et les scripts d’APIs dans le schéma voulu si cela n’a pas déjà été fait.

Figure 74

Le module généré dans JDeveloper n’est pas fonctionnel tel quel. Il doit être modifié. Chaque entité peut être liée à une table de la base de données. Si la table a plus de colonnes que l’entité n’a d’attributs, des attributs supplémentaires sont générés lorsque l’on effectue la synchronisation avec la base de données.

Tous les objets du référentiel de JDeveloper sont stockés sous forme de fichiers XML et Java.

3.4.1. Clé primaire Tout d’abord, corriger la clé primaire des entités qui sont des tables de base. Dans les propriétés de l’entité définir comme type pour la clé primaire : DBSequence. Sur l’onglet séquence qui apparaît alors, indiquer le nom de la séquence existante dans le schéma et prévue pour gérer la clé primaire. La condition start with est mise à 1. Même si la valeur courante de la séquence est par exemple 4, et que l’on indique start with 1, la prochaine valeur sera 5. Ce mécanisme de séquence asynchrone n’est pas propre à JDeveloper.

Pour les tables de lookup, ne rien changer en ce qui concerne la clé primaire. En effet, aucun enregistrement n’est ajouté dans ces tables pour les modules dans lesquels elles se trouvent en lookup.

Pour les entités qui réfèrent à une association identifiante, le numerodep est géré par les APIs. Pour que cela soit possible, il faut que dans l’entité et dans la vue la propriété updateable soit à while new et que la case mandatory soit décochée. En effet, la case mandatory rend le champ obligatoire. Comme le champ est alimenté par les APIs il n’est rempli que lorsque l’on valide l’enregistrement. Il faut vérifier que les cases refresh after insert et update soient cochées. Ces propriétés permettent aux APIs de fonctionner. Pour les entités associatives, la clé primaire est composée de deux clés étrangères. Les propriétés que doivent avoir les deux clés étrangères dans l’entité sont : persistent, primary key, queriable, updateable while new et refresh after insert et update cochés.

23.03.2005 38 sur 73 Astrid von Wyl

Page 39: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

3.4.2. Champs d’audit et domaines Les champs d’audit sont reconnus par JDeveloper, il n’y a rien à modifier. Ils seront pris en charge par les APIs. Les domaines définis avec Designer n’existent pas dans JDeveloper. Le type pk_numerique n’est pas du tout repris. Pour Yes/No, par exemple, une contrainte de check est générée afin de vérifier la saisie.

3.4.3. Validation Les validations de type valeur plus grande que 10 ou valeur en majuscule sont gérées par les APIS. Il ne faut rien faire de particulier pour que ces règles fonctionnent.

3.4.4. Vues et modules Pour les tables de lookup, aucune vue n’est générée. La relation entre la table de base et la table de lookup n’est pas générée non plus sous forme de lien vue.

Dans les vues indiquer les attributs qui apparaîtront dans les formulaires. Par exemple, indiquer que les champs d’audit ne seront pas visibles. Ne pas mettre les champs d’audit dans la fenêtre selected mais les laisser/déplacer dans la fenêtre available des propriétés des vues. Les attributs numero qui sont source ou destination d’une relation doivent être dans la fenêtre selected.

Les vues générées à partir des modules Designer gardent les définitions de Designer, quant à la visibilité ou non dans un formulaire.

Une bonne définition des vues permet de gagner du temps lorsque l’on crée la partie graphique à l’aide de vue/contrôleur.

3.4.5. Navigation La navigation se fait dans le sens table de référence, table de base.

Voici l’exemple (Figure 75) d’un module qui comporte une relation maître-détail et deux LOV :

Figure 75

La navigation devrait commencer par une commande que l’on attribue à un client. Puis, pour la commande on crée une ligne de commande à laquelle on assigne un produit.

Le module généré avec JDeveloper ne permet pas cette navigation. Trois entrées sont possibles : commandes, Clients et produits. La Figure 76 montre les points d’entrée : les listes de valeurs Clients et produits, que l’on peut uniquement consulter, et l’en-tête de la

23.03.2005 39 sur 73 Astrid von Wyl

Page 40: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

commande. Dans l’en-tête, on se positionne sur un client, puis pour ce client on indique que l’on veut ajouter une ligne de commande. On attribue un produit à cette ligne de commande.

Figure 76

3.4.6. Enrichissement du module et synchronisation Une fois que le module est opérationnel dans JDeveloper, on peut le compléter par l’ajout de champs calculés par exemple. Si on ajoute des attributs persistants ou des nouvelles règles de validations, il faut exécuter une synchronisation avec la base de données. Il faut que la base de données reste cohérente si l’accès ne se fait pas par JDeveloper mais par SQL plus par exemple.

23.03.2005 40 sur 73 Astrid von Wyl

Page 41: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

4. Couche view/controller

Pour étudier la couche vue du modèle MVC d’une application, je considère trois façons différentes de procéder : Java client, Web Client JSP et Web Client ADF UIX.

Pour la première phase de tests, je reprends le module Clients (Figure 77) de Designer et je l’importe dans JDeveloper.

Figure 77

Dans la seconde phase, je reprends le module Clients-Representants (Figure 78) de Designer avec une liste de valeurs :

Figure 78

Pour étudier les champs qui se rapportent à un domaine, comme par exemple HOMME-FEMME ou SEXE, je fais des tests sur le module Representants qui ne contient que la table représentant.

J’importe ces trois modules depuis Designer vers des projets distincts dans JDeveloper. Pour toutes les entités Clients qui sont générées, j’indique que l’attribut numero est de type DBSequence et qu’il est alimenté par la séquence CLI_SEQ.

Quelques notions doivent être rappelées en préambule :

Fichier web.xml : contient les paramètres qu’un serveur doit connaître pour exécuter l’application.

Fichier struts-config.xml : contient les méta données du contrôleur. Pour éditer graphiquement le contrôleur ouvrir ce fichier.

23.03.2005 41 sur 73 Astrid von Wyl

Page 42: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

4.1. ADF UIX Le projet ne comporte que la couche modèle. Pour ajouter la couche vue, dans les technologies du projet, je mets ADF UIX et Struts (Figure 139 ). Le fait de sélectionner ces technologies crée un nouveau nœud dans l’arborescence du projet : le nœud web content. Celui-ci contient deux fichiers XML struts-config.xml et web.xml :

Figure 79

Pour pouvoir éditer graphiquement le contrôleur, ouvrir le fichier struts-config.xml. (Figure 140) Je souhaite créer une page d’affichage des données de la table Clients. Pour cela, je sélectionne dans la component palette et je la place dans le struts flow diagram.

Figure 80

Je précise que ce sera une page de type uix. (l’autre choix est JSP). Un double-click sur la page l’ouvre en édition. L’accès à la page se fait par l’onglet qui porte son nom :

Figure 81

Lorsque l’on se trouve sur la page, la fenêtre data control palette (Figure 82) est affichée en haut à droite. Elle comporte la/les vues correspondantes au projet dans lequel on se trouve.

Figure 82

Le nœud de la vue se compose de trois parties, un première pour les attributs, une deuxième pour des opérations sur la vue (CREATE, FIRST, NEXT etc…) et une troisième pour les opérations COMMIT et ROLLBACK.

23.03.2005 42 sur 73 Astrid von Wyl

Page 43: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Sous la fenêtre data control palette se trouve la liste déroulante drag and drop as. Lorsque l’on choisit les éléments qui seront affichés et qu’on les tire sur la page, on choisit leur type. Il est possible de prendre toute la vue avec les types ci-dessous :

Read-only table Read only form Input form Input form (with navigation) Search form Master Detail (Self)

Selon l’élément que l’on souhaite mettre sur la page les types proposés ne sont pas les mêmes. Un attribut par exemple peut être de type list ou checkbox.

Je prend toute la vue de type read-only form. Elle s’affiche sur la page avec par défaut les boutons de navigation (Figure 83).

Figure 83

A gauche se trouve l’étiquette et à droite la référence au champ. Chaque champ et chaque étiquette se rapportent à un lien (binding) qui réfère à la couche modèle du projet. Pour modifier par exemple le nom d’une étiquette, je fais la modification dans la vue correspondante de la couche modèle. Le changement est répercuté automatiquement sur la page, formulaire. Par contre si on rend un champ visible alors qu’il ne l’était pas, il faut rafraîchir data control palette et ajouter l’attribut manquant dans les formulaires/pages.

Les liens sont édités/visualisés dans la fenêtre de structure (Figure 140). Pour chaque action, la vue touchée par cette action est définie ainsi que le type d’action. Par exemple pour CREATE :

Figure 84

Pour voir le formulaire que l’on vient de créer >run. Le contenu de la table Clients est affiché dans une nouvelle page du navigateur.

23.03.2005 43 sur 73 Astrid von Wyl

Page 44: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 85

La navigation entre les enregistrements se fait avec les boutons First, Previous, Next, Last.

Pour éditer la table Clients, je crée une nouvelle page. Dans cette page, tirer la vue (de type input form). Faire un drag and drop de l’opération COMMIT (afin de pouvoir valider les nouveaux enregistrements). J’efface le bouton submit (celui-ci ne fonctionne pas, aucune action n’est définie pour ce bouton).

Sur la page d’affichage j’ajoute une opération CREATE. Ce nouveau bouton permet la création d’un nouvel enregistrement vide.

Pour mettre des valeurs dans cet enregistrement, il faut qu’il y ait un lien entre la page d’affichage et la page d’édition (page dans laquelle il est possible de saisir les données). Sur la page struts-config.xml, j’ ajoute un lien de type forward entre la page d’affichage et la page d’édition. Je le nomme insère.

Figure 86

Pour provoquer l’événement qui passe le contrôle d’une page à une autre, je rajoute un bouton de type submit dans la page d’affichage. Je clique sur set event handler (afin de définir l’événement) dans la fenêtre property inspector (Figure 139 ). Sur event dans la fenêtre de structure par un click droit (Figure 87) insert inside event> UIX servlet >go. Donner le nom du lien forward (dans ce cas : insère voir Figure 88).

Figure 87

Figure 88

L’ajout d’un nouvel enregistrement, se déroule en deux temps. Tout d’abord on ajoute un enregistrement vide avec CREATE puis on appelle le formulaire d’édition en cliquant sur le bouton qui permet de passer le contrôle à la page d’édition. Les informations du nouvel enregistrement sont saisies puis validées avec commit. Pour modifier un enregistrement, se placer sur l’enregistrement, puis insert. Le bouton insert ouvre la page d’insertion/mise à jour.

Pour pouvoir effacer un enregistrement, dans la page d’édition j’ajoute l’opération DELETE. Un bouton DELETE est créé. Pour effacer un enregistrement, on se place sur cet enregistrement dans la page de visualisation, on clique sur le bouton qui exécute le lien

23.03.2005 44 sur 73 Astrid von Wyl

Page 45: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

forward entre les formulaires. Sur le formulaire de mise à jour on clique sur DELETE. L’enregistrement disparaît, le suivant est affiché. L’enregistrement n’est effacé de la base de données qu’une fois la transaction validée avec COMMIT. Le package qui contient les composants métiers est enrichi de fichiers XML correspondant à ces pages. Pour chaque page un fichier nomPageUIModel.xml est généré. Ce fichier contient les liens entre la couche modèle et la couche vue.

Bug : Pour activer les boutons mettre disabled à false. Pour pouvoir mettre disabled à false, il faut d’abord le mettre à true car si on le met tout de suite à false, cette valeur n’est pas gardée.

4.1.1. LOV Bug : Les clés secondaires sont mal importées depuis Oracle Designer. Pour créer des listes, il faut utiliser la clé primaire et la clé étrangère.

Je procède de la même façon que pour le module Clients simple, cette fois je reprends le module clients-representants avec LOV. Pour mettre en place la liste de valeurs, j’efface le champ MNEMO de la page d’édition. Je replace l’attribut REPRNUMERO par un drag and drop de type messageList (select one). La fenêtre qui permet de gérer les liens entre cette liste et des attributs s’ouvre (Figure 89).

Figure 89

Définir le/les attributs qui seront affichés dans la liste à partir de l’onglet LOV Display Attributes. On peut choisir dans la liste de choix en fonction du MNEMO par exemple, ou plus judicieux afficher le MNEMO, le nom et le prénom dans la liste. Ci-dessous (Figure 90) la liste avec comme attributs le MNEMO, le nom et le prénom:

Figure 90

Si le nombre d’enregistrements devient trop important, cette solution n’est pas envisageable. Une autre façon de faire est la création d’une page à part pour la liste de valeurs. A cet effet, on fait un drag and drop de l’attribut REPRNUMERO de type MessageLOVInput. Une nouvelle page LovWindow.uix est générée (Figure 91). Cette page correspond à la liste de

23.03.2005 45 sur 73 Astrid von Wyl

Page 46: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

valeurs. J’édite le contenu de cette page, en y plaçant la vue (type LOV table) existante qui correspond à la LOV.

Maintenant, dans le formulaire d’insertion, le champ numero est suivi d’une lampe de poche :

. Lorsque l’on clique sur celle-ci la page correspondant à la LOV s’ouvre et il est possible de sélectionner un enregistrement de cette table.

Figure 91

La page (Figure 91) représente un drag and drop de type LOV table. Je place l’attribut qui sera mis dans le champ qui appelle la LOV. Si la clé secondaire était reconnue, l’attribut MNEMO suffirait. Dans ce cas, l’attribut à partir duquel la LOV est créé est numero, la destination de la LOV est REPRNUMERO.

Le champ numero du client qui est alimenté par une clé primaire ne doit pas être affiché. Il doit par contre se trouver dans la vue.

Le défaut de cette façon de procéder est que le numero du représentant s’affiche à l’utilisateur dans le formulaire d’insertion et de mise à jour.

4.1.2. Types Pour mettre en œuvre le type HOMME-FEMME, comme le domaine créé à cet effet dans Designer n’est pas repris, on replace le champ sexe de type choice. On définit les valeurs qui pourront être saisies. On peut aussi représenter ce choix par deux boutons radio (RadioSet). La valeur affichée est celle qui sera insérée dans la table. Pour remédier à ce problème créer un domaine.

Pour les types date, un calendrier est placé automatiquement à côté du champ.

4.2. JSP Je vais créer l’affichage du composant modules avec des pages JSP. Sur le projet cliquer sur New> New Gallery > JSP page et new gallery> Web tier struts . Je donne un nom à la page. Le fait de définir une page de type JSP ajoute un dossier au projet (Figure 92): Web Content et crée deux fichier XML struts-config.xml et web.xml.

Figure 92

23.03.2005 46 sur 73 Astrid von Wyl

Page 47: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Dans la fenêtre d’édition de la page JSP, les types de drag and drop de data control palette qui existent pour une vue sont :

Read-only table et Read-only dynamic table affichent dans un tableau tous les enregistrements.

Navigation boutons ajoute les boutons de navigation : first, previous, next et last Graph insère une balise <graph> qui permet d’insérer une image. Input form est un formulaire qui permet des mises à jour. Read only form affiche un formulaire en lecture seule. Select row link ajoute un lien. Navigation list représente les champs de la vue sous forme de liste déroulante.

Pour le formulaire d’affichage, prendre le type read-only form pour la vue. Ajouter des boutons de navigation par un drag and drop des opérations correspondantes. Si on a crée une page de type page, celle-ci est transformée en type data page car il y a interrogation d’une source de données. Une fenêtre de message demande une confirmation pour cette transformation.

Je rajoute sur la page par un drag and drop un bouton de type submit que je renomme update (Figure 93).

Figure 93

Pour créer des actions, les pages sont séparées en compartiments (trait-tillés sur la copie écran ci-dessus). Chaque compartiment a des propriétés dont une qui est nommée action *. Dans le property inspector (Figure 139 ), il est possible de sélectionner le nom d’une autre page JSP pour cette action au travers d’une liste déroulante. Cette action sera valable pour tous les boutons se trouvant dans le compartiment.

Pour que les boutons next/previous et update fonctionnent correctement, je les met dans des compartiments séparés. Update a comme action le passage du contrôle à une autre page, mais ce n’est pas le cas de next et previous qui naviguent entre les enregistrements .

Je crée la page de mise à jour : click-droit sur le dossier WEB-INF>New>New Gallery> JavaServer Page> JSP Page. Je la nomme edition (Figure 94). Par un drag and drop je tire la vue de type input form sur cette page. Sur celle-ci, je mets une opération CREATE et une opération COMMIT.

Figure 94

23.03.2005 47 sur 73 Astrid von Wyl

Page 48: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Dans la page principale, pour le bouton EXECUTE, je spécifie l’action edition.do. Ceci correspond au nom de la deuxième page que j’ai crée.

Pour exécuter cette application, dans l’arborescence sur le fichier struts-config.xml, web content ou WEB-INF sélectionner run. Pour ajouter un tuple, depuis la page principale, on clique sur EXECUTE. On est redirigé vers la page d’édition. Dans cette page, on clique sur CREATE, on saisit les nouvelles données et puis on valide avec COMMIT.

Pour offrir la possibilité d’effacer des enregistrements, je rajoute un bouton DELETE dans la page d’édition. Je complète la page avec des boutons de navigation. Pour la mise à jour, il suffit de modifier l’enregistrement et de valider avec COMMIT.

Pour retourner sur la page principale depuis la page d’édition, par un drag and drop créer un bouton de type EXECUTE dans un nouveau compartiment (Figure 95). On définit comme action de ce compartiment d’aller à la page principale.

Figure 95

Le problème est que si on se positionne sur un enregistrement dans la page principale, celui-ci n’est pas conservé et on se retrouve sur le premier enregistrement dans la page d’édition.

4.2.1. LOV J’efface le champ LreprMnemo, je replace l’attribut REPRNUMERO de type Single select list. Double-cliquer sur le champ, pour ouvrir les propriétés (Figure 96) et mémoriser l’attribut property.

Figure 96

Dans la fenêtre de structure double-cliquer sur le champ qui a la valeur de l’attribut property (En l’occurrence REPRNUMERO1). Le list binding editor s’ouvre (vu avec ADF UIX).

Le contenu de la table Représentants s’affiche sous forme de liste qui contient les attributs spécifiés dans le list binding editor.

23.03.2005 48 sur 73 Astrid von Wyl

Page 49: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Cette façon de faire pose des problèmes dès que le nombre d’enregistrements devient trop important. Il faudrait alors créer une action sur un bouton qui ouvre une page contenant la liste des enregistrements. Après avoir effectué le choix, le contrôle repasse à la page de mise à jour. L’enregistrement sélectionné serait gardé en cache.

Rien ne semble prévu pour faciliter la mise en place de LOVs. Pour contourner le problème, il est possible de profiter des composants de ADF UIX dans les pages JSP. Pour cela, il faut préciser dans les propriétés du projet l’ajout d’une nouvelle technologie legacy UIX JSP tag library. L’utilisation des composants UIX semble assez compliquée, je n’ai pas creusé ce point.

4.2.2. Types J’utilise à nouveau single select list pour afficher un liste de choix. Je ne choisis pas le mode LOV mais le mode enumeration dans le binding editor. J’indique les valeurs parmi lesquelles choisir. La valeur affichée est celle qui sera mise dans la table. Il faudrait utiliser des domaines pour résoudre ce problème.

4.3. Java Client Les applications java client sont des applications indépendantes qui tournent sur une JVM sur le tier client. Je crée une application de type java [default] pour accueillir le module Designer. Pour créer une nouvelle page : sur le nœud view New>New Gallery>Swing/Jclient for ADF> Empty form.

Figure 97

L’arborescence du projet comporte de nouveaux éléments :

Figure 98

FormClients.java : Code java correspondant à la page créé. FormClientUIModel.xml : Définit les itérateurs utilisés dans dataBinding.cpx. DataBindings.cpx : Etablit le lien entre le composant module de la couche modèle

et la couche vue.

Le fichier FormClients.java contient une interface graphique vide (JFrame) :

23.03.2005 49 sur 73 Astrid von Wyl

Page 50: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 99

Pour peupler cette fenêtre, faire un drag and drop de la vue depuis la palette des composants. Les types possibles de drag and drop sont :

Table : Table Combo box : Liste déroulante List : Liste Tree : Arborescence Graph : Graphique NavigationBar : Boutons de navigation

Le type table affiche un tableau vide. Seule la structure est visible. Exécuter le fichier formClients.java pour voir le contenu :

Figure 100

Pour ajouter un nouvel enregistrement, on clique sur le « + vert », un nouveau tuple est créé. Saisir les données directement dans cette ligne vide. Valider ou non le nouveau tuple :

Ces deux flèches représentent le COMMIT et le ROLLBACK.

Pour effacer un enregistrement, se placer sur l’enregistrement et cliquer sur le + rouge. Pour modifier un enregistrement, effectuer la modification directement dans le champ concerné puis valider.

4.3.1. LOV On efface le champ REPRNUMERO. On le remet de type Radio Button Group. Dans la fenêtre de structure définir dans le binding editor les liens. Le représentant peut être choisi dans la liste. Si le nombre d’enregistrements est trop important, cela devient problématique.

23.03.2005 50 sur 73 Astrid von Wyl

Page 51: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 101

Une autre façon de procéder, est d’utiliser un bouton pour accéder aux enregistrements. Le bouton s’utilise de la même façon que le messageLOVInput. Je dois aussi définir les liens à partir de la fenêtre de structure entre la source et la cible de la liste. Le bouton créé ouvre une fenêtre qui contient la liste des représentants(Figure 102).

Figure 102

4.4. JHeadstart Pour pouvoir utiliser JHeadstart, on crée un workspace de type No template [all technologies]. On sélectionne JHeadstart project puis sur le nouveau projet, >JHeadstart Designer generator. On importe les domaines et les tables du module Clients.

La couche modèle est prête, pour avoir la couche vue, sur le fichier CliApplicationStructure.xml sélectionner >run JHeadstart application generator. Lors de la génération ne pas préciser que l’on veut choisir les tables et les domaines soi-même. La couche vue est générée.

En ce qui concerne la navigation, il n’est pas possible d’afficher une page pour voir à quoi elle ressemble, il faut commencer par exécuter la page nommée start pour accéder à l’application. Par un click droit sur le ficher struts-config-xml sur run (Figure 103) il est « possible de choisir la page à exécuter ». Mais en fait, seule la page start peut l’être.

Figure 103

La couche vue possède les dossiers suivants :

23.03.2005 51 sur 73 Astrid von Wyl

Page 52: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 104

cle-provider.xml contient les fournisseurs de connexion (servlet..) Le fichier dateformat.properties définit le format date. DataObject.properties contient la relation entre l’entité et la vue. Les deux pages CLICLIENTSPage.uix et FindCLICLIENTSPage.uix peuvent être

visualisées, mais uniquement le code XML et le preview. L’onglet design ne contient rien. Le fichier XML peut être édité. L’onglet design contient le message d’erreur suivant :

The document is not in a valid state. Please edit this file in the code editor to resolve syntax problems and then return to the visual editor.

CLITabBar.uit : contient la gestion des onglets. Web.XML : contient la définition des servlets, selon la technologie utilisée. Uix-config.xml : contient les paramètres de style. Orion-web.xml : contient la configuration de l’application web. Index.html et NewJhsProjectInstructions.html sont des fichiers d’aide. CliApplicationsStructure.xml : contient la structure de l’application, sur quelle vue

elle repose. Build.properties : contient les propriétés de déploiement et les dossiers dans

lesquels déployer. Build.xml : Code correspondant à build.properties CliDomains.xml : contient la définition des domaines repris depuis Oracle Designer.

Le fichier ApplicationStructure.xml est le centre de l’application. Ce fichier définit la structure de l’application. Pour faire tourner l’application sur le fichier struts-config.xml > run> CliStart.

Figure 105

Si les critères de recherche sont laissés vides, la navigation dans les enregistrements se fait page par page. A cet effet sous l’onglet composant de gestion des Clients, les boutons sont prévus :

23.03.2005 52 sur 73 Astrid von Wyl

Page 53: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 106

Les propriétés de l’application peuvent être éditées en modifiant le fichier ApplicationStructure.xml. La Figure 107 représente la barre d’outil du fichier.

Figure 107

Lorsque l’on fait une modification dans un fichier uit, pas besoin de faire un rebuild car, ces fichiers sont en référence.

4.4.1. LOV Toute l’application peut être définie à partir du fichier ApplicationStructure.xml. Il est possible de définir, par exemple, une condition uppercase pour un attribut. La structure du fichier ApplicationStructure.xml se trouve en annexe de ce document. Dans ce fichier, chaque module devient un groupe. Un sous-groupe d’un nœud est généré pour une LOV.

Lorsque l’on exécute l’application générée à partir du fichier struts-config.xml, la page de recherche est exécutée.

Si on clique sur find sans spécifier de critère, on arrive sur le premier enregistrement.

Figure 108

La lampe de poche sert à accéder à la liste de valeurs. Pour ne pas avoir la page de recherche, comme première page, dans le fichier ApplicationStructure.xml mettre find page à false. Pour que le changement soit reconnu, faire >run JHeadstart application generator.

Pour changer l’affichage de la page d’édition, dans le fichier ApplicationStructure.xml, la balise layout style propose quatre types : form, table, table-form, select form.

Voici le layout table (Figure 109), au bas de la table, il y a une ligne vide dans laquelle on peut définir un nouvel enregistrement.

Figure 109

Le layout table-form (Figure 110) offre la possibilité de sélectionner l’enregistrement grâce à un bouton.

23.03.2005 53 sur 73 Astrid von Wyl

Page 54: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 110

Le layout select-form est une liste déroulante.

Une liste de valeur peut être affichée de deux façons : LOV (lampe de poche) ou choice. Choice présente peut-être un bug, mais cette option ne permet pas du tout de sélectionner un enregistrement, les champs correspondants sont read-only.

Bugs :

Si l’erreur ..bundle chemin spécifié introuvable apparaît, changer le champs NLS resource bundle et lui donner un autre nom. Reconstruire le projet et générer l’application à partir du fichier ApplicationStructure.xml.

Pour modifier une page .uix, générée avec JHeadstart, il y une sorte de « bug XML ». Il faut valider le fichier uix et ensuite il est possible d’éditer graphiquement la page.

4.4.2. JSP Si on souhaite générer la même application en JSP, il faut modifier le fichier ApplicationStructure.xml en conséquence. Dans les propriétés générales mettre view type à JSP. Lors de la génération depuis Designer, il est déjà possible de spécifier la propriété view type. Les fichiers générés sont les mêmes qu’avec ADF UIX, seuls ceux qui étaient propre à ADF UIX sont devenus JSP.

Le composant de gestion des Clients ressemble à ceci (Figure 111) en JSP :

Figure 111

La page d’édition se présente ainsi :

Figure 112

Si on ouvre en édition un page JSP générée, seuls deux onglets sont présents design et source, preview n’existe pas. Le contenu de l’onglet design se présente de telle façon :

23.03.2005 54 sur 73 Astrid von Wyl

Page 55: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 113

L’ajout de boutons et autres serait théoriquement possible. Selon ce que l’on souhaite faire, il vaut mieux regarder si le fichier ApplicationStructure.xml ne le permettrait pas.

4.4.2.1. JSP avec LOV

Comment JHeadstart va-t-il faire pour implémenter une liste de valeurs sur des pages JSP ? Lors de l’importation, un warning concernant la LOV peut apparaître. Suite à ce warning, il faut indiquer quel attribut est référencé dans la LOV et lequel doit être affiché. Dans le fichier ApplicationStructure.xml, dans les propriétés de la LOV, remplir les champs LookupValueAttribute et lookupDisplayAttribute.

La liste de valeur est accessible également par une lampe de poche.

4.4.3. Types Les domaines sont repris depuis Designer et se trouvent dans le fichier Domaines.xml. Ce fichier contient pour chaque domaine la valeur affichée et la valeur correspondante qui sera enregistrée dans la table. <Domain name="ExampleDomain"> <AllowableValue value="M" meaning="Male"/> <AllowableValue value="F" meaning="Female"/> </Domain>

Avec JHeadstart, les listes de choix sont créés automatiquement. Les champs de type dates sont alimentés grâce à un calendrier.

4.4.4. Personnalisation des applications Pour modifier l’application, le mieux est de modifier le fichier ApplicationStructure.xml. Dans ce fichier, il est possible d’accéder aux entités et vues et de les modifier avant de générer une nouvelle version de l’application. Je ne vois pas quel serait l’intérêt de rajouter une page. Toutes les pages nécessaires me semblent générées.

4.5. Remarques Une LOV est un formulaire qui permet de référencer un enregistrement d’une table de lookup. C’est une interface particulière d’alimentation de la clé étrangère. La table client contient une colonne REPRNUMERO qui est la colonne de clé étrangère. Comme les numéros ne sont normalement pas affichés à l ‘utilisateur car ils ne sont pas parlants, le MNEMO est affiché à l’utilisateur. Dans la table Clients, il n’y a que le numero du représentant qui est stocké.

Dans la vue correspondante aux Clients l’attribut REPRNUMERO est caché. Il n’est pas obligatoire.

En choisissant un MNEMO on alimente la colonne REPRNUMERO. Il faut que la colonne de clé primaire et la colonne de clé étrangère qui font partie de la contrainte de clé étrangère soient affichées. Au cas où cela ne serait pas le cas, modifier les vues/entités correspondantes.

23.03.2005 55 sur 73 Astrid von Wyl

Page 56: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

4.6. Affichage d’un module avec table de référence Pour tester l’affichage selon les trois technologies d’un module avec une table de référence, je reprends le module client-representant de Designer :

Figure 114

Pour que cet affichage fonctionne il faut impérativement une clé secondaire. L’importation depuis Designer dans JDeveloper omet les clés secondaires. Il faut synchroniser les entités fraîchement générées avec le contenu de la base de données pour que la clé secondaire devienne une contrainte sur l’entité.

Malgré la présence de la clé secondaire, JDeveloper a besoin des attributs clé primaire et clé étrangère pour pouvoir faire l’association. La clé secondaire n’est pas reconnue.Une fois que la clé secondaire es dans le formulaire d’édition.

Il n’est pas possible de créer une liste d’enregistrements qui référence la même vue comme source et destination.Une solution qui exige de modifier ce qui a été généré par Designer est de créer une vue pour la table de référence. Avec cette vue, la création d’une liste est possible.

4.6.1. Web Client L’affichage des enregistrements référencés se fait sans problème. Je tire la vue sur une page JSP ou ADF UIX de type read-only.

Par contre, si l’on souhaite créer une page de mise à jour, les ennuis commencent. Même JHeadstart ne parvient pas à offrir la possibilité de choisir un Representant lors de la saisie d’un nouveau client.

En effet, l’entité représentant ne fait pas partie du composant module et ne peut être référencée. Les seuls attributs que nous ayons à disposition sont ceux de l’entité Client et les références de l’entité Representants. (outer join) .

Une solution qui m’oblige à retoucher les objets générés depuis Designer (peu souhaité) est de créer une vue supplémentaire qui porte sur la table de lookup. On place ensuite cette vue dans le composant module puis il est possible de l’utiliser. JHeadstart procède de la sorte mais sans succès.

Si on crée une LOV, les seuls représentants que l’on peut choisir sont ceux qui sont déjà référencés.

4.6.2. Java Client Pour java client, les problèmes sont identiques à web client.

23.03.2005 56 sur 73 Astrid von Wyl

Page 57: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

5. Application garage

L’application garage est un exercice du cours d’AGL suivi pendant l’année. ( Les données de l’exercice se trouvent sur http://zuse.esnig.cifom.ch/analyse/designer6i/index.htm ). Cette application est définie avec Oracle Designer. Elle permet la gestion des réparations de véhicules, qui comprend les pièces, la main d’œuvre, le client et la voiture. La Figure 115 montre le modèle conceptuel de l’application.

Une réparation est relative à un seul véhicule. Un ou plusieurs employé(s) travaillent sur une réparation et peuvent utiliser des pièces de rechange. Chaque employé a une qualification (mécanicien, chef …).

Le client est soit le client, soit l’assurance à qui il faut envoyer la facture. Si la voiture est sous garantie, aucune facture n’est envoyée.

Figure 115

Qualification (Code), Employe (MNEMO), Vehicule (Num_chassis), Piece (ID) et Reparation (Date_rep et Veh_num) ont des clés secondaires. Les clés primaires sont toutes gérées par des séquences. Ci-dessous le modèle logique :

23.03.2005 57 sur 73 Astrid von Wyl

Page 58: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 116

Le module crée avec Designer se trouve à la Figure 117.

Le composant 1 est gar_reparations

Le composant 2 est gar_utilisations (utilisation des pièces)

Le composant 3 est gar_travail (travail réalisé)

La table de lookup A est gar _pieces

La table de lookup B est gar_vehicules

La table de lookup C est gar_clients

La table de lookup D est gar_employes

La table de lookup E est gar_qualifications (grade de l’employé, influence le prix/heure)

Gar_reparation est un composant maître, gar_utilisations et gar_travail sont des composant détail.

Toutes les tables de lookup possèdent une LOV (voir Figure 118).

23.03.2005 58 sur 73 Astrid von Wyl

Page 59: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 117

Figure 118

Un schéma (dipl04avw_g05) sur prod10g contient les tables ainsi que les APIs de table, tout est généré à partir des spécifications contenues dans Designer.

L’objectif est d’importer cette application dans JDeveloper et de la déployer selon les trois possibilités Web client ADF UIX, Web client JSP, Java Client et ensuite de faire de même en utilisant JHeadstart.

23.03.2005 59 sur 73 Astrid von Wyl

Page 60: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Maître Détails

Figure 119 : Application garage

L’application ne prévoit pas la saisie des clients et des qualifications, des pièces et des employés et des véhicules mais uniquement de les référencer.

5.1. Importation Pour pouvoir importer le module ci-dessus, je définis une nouvelle connexion à Designer dans JDeveloper. La Figure 120 montre le résultat de l’importation. Chaque table du module se retrouve sous forme d’entité. Les trois LOV sont devenues des objets vues, les deux liens vues correspondent au lien entre le composant maître et les composants détails. Chaque composant a aussi son objet vue qui lui correspond (GarRepEnteteViewObject composant entete qui contient la table gar_reparations).

Figure 120

23.03.2005 60 sur 73 Astrid von Wyl

Page 61: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Pour l’entité GarReparations, je spécifie que l’attribut clé primaire est de type DbSequence et je lui associe la séquence existante dans la base de données.

Les entités GarTravail et GarUtilisation sont des entités associative, leur clé primaire est composée de deux attributs. Pour les deux attributs de chaque entité je m’assure que les cases suivantes soient cochées : persistent, primary key, updateable while new, refresh after insert et refresh after update.

Bug ? : Les seules contraintes qui sont importées sont les clés primaires. Aucune trace des clés secondaires. Le fichier qui contient les données extraites depuis Designer est correct, il contient toutes les contraintes, mais ensuite, il y a une erreur dans la génération des entités. Pour qu’elles s’affichent dans l’arborescence de JDeveloper, il faut synchroniser la base de données avec les entités.

Une autre possibilité moins farfelue et risquée que la synchronisation avec la base de données est de cocher la case unique dans les propriétés de l’attribut. A partir de là les contraintes apparaissent !!

Remarque : Le module contient trois champs calculés qui se trouvent dans un package dans la base de données. Comment réagir face à ces champs calculés ? Faut-il reprendre les packages de la base de données ou définir les champs calculés dans l’application JDeveloper ?

5.2. Affichage, couche vue L’affichage devra comporter 3 pages, une pour les réparations, une pour le travail et une pour l’utilisation des pièces. La page principale est la page des réparations. A partir de celle-ci, on doit pouvoir accéder indépendamment aux deux autres pages.

5.2.1. Champs calculés L’application garage comporte plusieurs champs calculés. Ces champs sont calculés par des procédures qui se trouvent dans un package. Ce package se trouve dans la base de données, il est accessible depuis JDeveloper.

Les champs calculés n’ apparaissent qu’au niveau des objets vues. Or ces objets vues se réfèrent parfois à plusieurs objets vues, les noms peuvent être ambigus. J’ai du corriger la requête des vues, car il y avait trois attributs ayant le même nom. Pour modifier la requête (voir: Requête 2) de la vue, il suffit de cocher la case expert mode. Attention, il n’est plus possible de revenir en mode normal une fois cette case cochée. SELECT CliEntityUsage.NOM, CliEntityUsage.PRENOM, VehEntityUsage.DATE_ACHAT, RepEntityUsage.DATE_REP, VehEntityUsage.IMMATRICULATION, VehEntityUsage.MARQUE, RepEntityUsage.VEH_NUMERO, VehEntityUsage.NUM_CHASSIS, PACKREP.CALCULMONTANTTRAVAIL(RepEntityUsage.NUMERO)AS MONTANTTRAVAIL, PACKREP.CALCULMONTANTPR(RepEntityUsage.NUMERO) AS MONTANTPR, PACKREP.CALCULMONTANTTRAVAIL(RepEntityUsage.NUMERO)+PACKREP.CALCULMONTANTPR(RepEntityUsage.NUMERO) AS MONTANTTOTAL, RepEntityUsage.NUMERO AS NUMERO1, VehEntityUsage.NUMERO AS NUMERO2, CliEntityUsage.NUMERO AS NUMERO3 FROM GAR_REPARATIONS RepEntityUsage, GAR_VEHICULES VehEntityUsage, GAR_CLIENT CliEntityUsage WHERE /** JC */(RepEntityUsage.VEH_NUMERO = VehEntityUsage.NUMERO) AND (VehEntityUsage.CLI_NUMERO = CliEntityUsage.NUMERO)/* JC **/

Requête 2

23.03.2005 61 sur 73 Astrid von Wyl

Page 62: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

5.2.2. ADFUIX Je crée la page principale reparations.uix, et deux autres pages travail.uix et utilisation.uix. Je crée une première fois ces pages en lecture seule et une seconde fois en mise à jour. Je crée plusieurs liens de forward (voir Figure 121) dans le ficher struts-config.xml.

Figure 121

Reparations : Page (Figure 122) qui contient la liste des réparations. (type read-only table) Cette page contient un bouton CREATE qui crée un enregistrement vide et un bouton UPDATE qui permet d’ouvrir le formulaire de mise à jour. Une étoile précède le nom car j’ai définit cette page comme étant la page à exécuter par défaut.

Figure 122

ReparationsEdition: Page (Figure 123) qui contient la mise à jour des réparations. Cette page contient également deux LOV qui permettent de choisir le client et le véhicule.

Figure 123

PiecesDeRechange : Page (Figure 124) qui contient la liste de pièces de rechange, un bouton CREATE et un bouton Update.

Figure 124

Travail : Page qui contient la liste des employés qui travaillent sur la voiture. La page contient un bouton CREATE et UPDATE.

23.03.2005 62 sur 73 Astrid von Wyl

Page 63: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

PiecesDeRechangeEdition : Ajout de pièces de rechange.

TravailEdition : Ajout d’employés et du nombre d’heures qu’ils ont effectués.

Figure 125

Les pages nommées par défaut Lovwindow correspondent aux fenêtre de LOV créés dans les pages.

LovWindow0 : Correspond à la liste des véhicules.

LovWindow1 : Correspond à la liste des pièces.

LovWindow2 (Figure 126) : Correspond à la liste des employés.

Figure 126

Remarque : Il existe de nombreuses possibilités pour la mise en page, les représentations ci-dessus ne sont qu’une variante.

5.2.2.1. Erreur

Figure 127

Lorsque cette erreur survient, je l’ignore car l’insert se fait quand même lorsque je clique sur COMMIT.

5.2.3. JSP Après avoir ajouté le fichier struts-config.xml au projet, je crée des pages JSP sur le même modèle que pour ADF UIX. Je crée les mêmes pages que précédemment, dans le fichier struts-config.xml.

23.03.2005 63 sur 73 Astrid von Wyl

Page 64: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 128

Voici quelques exemples des pages créées :

Reparations.JSP : De type read-only table. Sur cette page (Figure 129) j’ ajoute des boutons de navigation précédent et suivant. L’étoile à gauche de la table signale l’enregistrement sur lequel on se trouve.

Figure 129

On procède de la façon suivante, on crée une ligne, puis avec le bouton mise à jour on appelle le formulaire d’édition.

Les boutons pièces de rechange et travail permettent d’accéder aux pages correspondantes.

ReparationsEDI.JSP : De type input form. Contient les boutons COMMIT, ROLLBACK et DELETE. Je déplore l’absence d’un calendrier pour la saisie de la date.

Figure 130

23.03.2005 64 sur 73 Astrid von Wyl

Page 65: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Travail.JSP :

Figure 131

Améliorations: Je n’ai pas réussi à mettre en place des LOVs. Dans l’application garage, j’utilise des listes déroulantes à défaut de mieux.

Les champs dates devraient aussi comporter une fenêtre de pop-up qui contient un calendrier.

Hypothèse : Ces problèmes sont-ils dû au fait que JSP n’utilise pas les librairies swing et awt ? Les LOV ne semblent pas exister.

5.2.4. Java Client Après l’importation, la correction des clés primaires et de la requête (voir Requête 2) je crée une nouvelle page (voir 49). Je me décide pour une représentation avec des onglets. L’ accès au détail du travail des pièces se fera par un onglet spécifique. J’efface dans la fenêtre de structure le menu dataPanel afin de laisser la place à un nouveau conteneur. Dans cette nouvelle page je mets un conteneur de type JTabbedPane. Dans ce conteneur je mets trois Jpanel . Je les renomme Réparations, Travail et Pièces.

Figure 132

Au préalable, je dois rendre visible dans les vues, les clés primaires et étrangères correspondantes aux associations. Pour chaque Jpanel, je mets la propriété layout à null. Sinon la mise en page par défaut met les champs au centre. Les champs qui ne doivent pas être mis à jour peuvent être grisés grâce à editable false.

Onglet Réparations : J’affiche le numéro du véhicule dans la vue correspondant à l’en-tête ainsi que le numero de la vue Véhicule. Je crée un lien (bindings) entre les deux en précisant que les valeurs affichées seront le numéro du châssis et l’immatriculation de la voiture. Je précise pour la date de réparation que le format date est yyyy-mm-dd. Pour la date, il faudrait un calendrier. Je place le numéro de voiture de type LOVButton.

Figure 133

23.03.2005 65 sur 73 Astrid von Wyl

Page 66: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Le bouton choix véhicule ouvre une page qui contient la liste de véhicules (Figure 134). On choisit le véhicule en se plaçant sur la ligne correspondante et en confirmant le choix par ok.

Figure 134

Onglet Travail :

Figure 135

Pièces :

Figure 136

Il faut ajouter les opérations PREVIOUS et NEXT afin de ne faire défiler que les enregistrements correspondant à la réparation.

Amélioration : Pour les champs de type DATE l’idéal serait d’avoir un calendrier sous forme de fenêtre pop-up. Il existe de nombreux exemples de code java pour réaliser ceci, mais l’objectif n’est pas d’écrire du code mais d’utiliser l’outil JDeveloper.

5.2.5. JHeadstart La génération de l’application avec JHeadstart nécessite deux modifications :

Attribuer les clés primaires aux entités GarReparations, GarUtilisations et GarTravail.

Préciser l’attribut de la LOV et l’attribut affiché dans la LOV dans le fichier ApplicationStructure.xml. Un warning signale cette opération à faire.

23.03.2005 66 sur 73 Astrid von Wyl

Page 67: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

L’application générée permet d’accéder aux deux composants détails par des liens (Figure 137) dans l’en-tête.

Figure 137

Il est à noter toutefois que les champs calculés sont absents ! Avec JHeadstart, un objet vue a été recréé pour chaque entité. Je suppose que ces objets vues sont faits par rapport aux entités, ce qui expliquerait la perte des champs calculés.

Lors de l’utilisation du JHeadstart Designer Generator, il y a une case à cocher Create Default view Object for new entity objects (Figure 138).

Figure 138

Même en décochant cette case à cocher, les champs calculés ne sont pas repris. Il faut définir à nouveau les champs calculés dans chaque vue.

Je ne refais pas l’application garage avec JSP, car la démarche est identique à ADF UIX et n’a à mon avis aucun intérêt.

23.03.2005 67 sur 73 Astrid von Wyl

Page 68: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

6. Evaluation du couplage

Le terme couplage signifie « La possibilité d’association entre deux éléments ». Dans ce travail, les deux éléments sont Oracle JDeveloper et Oracle Designer.

Suite aux tests, à mes analyses et à mes lectures, plusieurs points ressortent. Tout d’abord, il faut commencer à la base, il faut considérer qu’il est possible de se connecter à une instance de l’AGL Designer et de visualiser les modules que cette instance contient. Ensuite, l’importation se fait assez simplement grâce à l’assistant.

Les objets qui sont générés dans JDeveloper correspondent bien aux spécifications du module dans Designer. Néanmoins, il serait bien de pouvoir importer des entités en particulier ou des domaines. JHeadstart offre cette possibilité dans une certaine mesure.

Quelques modifications doivent être réalisées pour que les composants modules dans JDeveloper soient fonctionnels. L’attribution du type DBSequence et d’une séquence à la clé primaire n’est pas surprenante, car dans Designer on crée une séquence puis on l’attribue à une colonne.

Pour pouvoir utiliser au mieux toutes les spécifications dans Designer, je recommande de générer les APIs depuis Designer. Sinon, certaines possibilités ne seront pas disponibles. Par exemple pour une association identifiante, le numéro qui dépend du parent est géré par les APIs.

J’ai noté un problème majeur lié à Oracle Designer. En ce qui concerne les LOVs, la manière dont Designer (module web pl/sql) les implémente n’est pas « comprise » par JDeveloper, En effet, dans les LOVs, l’attribut qui est affiché ne correspond pas forcément à la valeur insérée dans la base de données. Designer semble « cacher » ces deux informations et JDeveloper n’est pas en mesure de les reconnaître. Les attributs clé primaire et clé étrangère de l’association sont cachés, puisque celle-ci se réalise par la clé secondaire. Pour pouvoir utiliser une LOV, il faut retoucher les objets générés depuis Designer.

La partie graphique nécessite une reconstruction presque complète. Si on utilise JHeadstart, ceci n’est plus vrai.

23.03.2005 68 sur 73 Astrid von Wyl

Page 69: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

7. Conclusion

Selon le plan détaillé annexé à la demande de ratification, les objectifs semblent réalisés. Ce travail peut encore être affiné. Les possibilités inexplorées par mon travail de JDeveloper sont encore nombreuses. Par rapport à mon plan détaillé de ratification, j’ai toutefois effectué un changement. La dernière partie de mon travail aurait du être réalisée avec une application de gestion des bugs existante. En accord avec mon directeur de travail, nous avons décidé de ne pas utiliser cette application mais de prendre une application des exercices du cours d’AGL Designer. En effet, ,je n’avais pas assez de temps pour me familiariser de manière satisfaisante avec cette application. J’ai donc refait l’exercice garage au complet afin d’avoir à disposition une application à utiliser.

J’ai énormément apprécié ce sujet grâce à sa diversité et à sa nouveauté par rapport à mes connaissances. J’ai beaucoup appris sur les possibilités de déploiement des applications, j’ai découvert l’existence des struts et aussi du modèle MVC.

La version que j’ai utilisée contient des bugs. Il n’a pas toujours été aisé de faire la part des choses entre les bugs et le fait de ne pas procéder de la bonne manière. J’ai parfois perdu du temps, alors qu’il était impossible de mettre en œuvre ce que je voulais faire.

L’une des sources d’information parmi les plus utilisées fut le forum de JDeveloper. En effet de nombreux utilisateurs rencontraient les mêmes problèmes que moi. J’ai été surprise de constater que bon nombre d’utilisateurs de JDeveloper se fatiguaient à écrire du code java, alors que l’outil génère presque tout lui-même. Je m’étais fixé comme objectif de n’écrire aucune ligne de code dans ce travail, partant du principe que je devais pour tous les cas de figure pouvoir indiquer à JDeveloper ce que souhaitais faire et le laisser générer le code. De plus, il est dangereux de retoucher du code généré et je ne suis pas convaincue qu’une version mi-générée, mi-écrite soit optimale.

Je me suis également souvent référé à l’aide en ligne. Celle-ci est à mon avis très bien faite et très complète à condition de maîtriser déjà quelque peu l’outil.

Chaque partie modèle / vue avait ses côtés intéressants et ceux qui l’étaient moins. La partie vue était la partie sur laquelle la documentation était la plus pauvre. J’ai du faire plus de tests et d’expériences dans cette partie que dans les autres, ce qui lui a donné un côté plus ludique. Heureusement, JDeveloper a un fonctionnement assez intuitif. La partie modèle est plus proche de ce que j’avais vu avec Designer. A trop vouloir reproduire Designer de la même façon dans JDeveloper, des erreurs peuvent survenir.

De la documentation a été publiée sur la couche vue en janvier 2005. Celle-ci est arrivée trop tard pour que je m’en serve. J’ai pu la consulter pour confirmer ce que j’avais fait.

Pour achever ce travail, il faudrait tester l’importation depuis un module généré en Oracle Forms par exemple, ou en visual basic, pour pouvoir analyser le comportement correct de la clé secondaire. Il faudrait aussi résoudre le problème des LOVs avec JSP. Des améliorations de mise en page des formulaires peuvent aussi être faits.

23.03.2005 69 sur 73 Astrid von Wyl

Page 70: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

8. Annexes

8.1. Figures Pour un projet aller dans tools>project properties > technology scope pour afficher cette fenêtre :

Figure 139

CI-dessous, l’apparence de JDeveloper lorsque l’on travaille dans la partie view.

1. Struts flow diagram

2. Component palette

3. Property inspector

4. Fenêtre de messages

5. Fenêtre de structure

6. Arborescence de JDeveloper

23.03.2005 70 sur 73 Astrid von Wyl

Page 71: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Figure 140

8.2. Options du fichiers ApplicationStructure.xml Identification *Name Nom du projet Description Ajout d’un commentaire Generate Flavours *Controller Type Struts | MVC framework *View type UIX | JSP File locations Struts config localisation fichier struts-

config.cml *UI Pages Virtual Directory Localisation pages *Source Directory Localisation répertoire src JSP/UIX Common Virtual Directory /common/ Stylesheet Relative Url Fichier .css contenant les

styles Java Model implementation base Nom du fichier .bc4j Model base Application module Nom du composant module Handler super class oracle.jheadstart.model.

bc4j.handler. DataObjectHandlerImpl

Supporting files *Domain file Fichier contenant la definition

des domains

5 4

3

2 1

6

23.03.2005 71 sur 73 Astrid von Wyl

Page 72: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

Template library file Fichier .uit Group include file Etapes avant l’exécution de

l’application. P.ex. sécurité. UI settings Show hint text? False | true *Date format * Date time format Hide unauthorized group tabs False | true Internationalization *NLS resource bundle Override NLS resource bundle entries False | true Generate NLS-enabled prompts and tabs

False | true

*Generator language code Generator country code Generation switches Generate controller XML files False | true Generate TabBar False | true Generate providers file False | true Generate deployment file False | true Generate dataobject file False | true Generate date format file False | true Generate NLS resource bundle False | true Save before generating False | true Show generator warnings False | true JDG protected False | true

Pour la vue les balises suivantes sont définies : Identification *Name *DataObject Description Query settings *View object *View object usage Query type Query type arguments Group layout *Layout style Form |table |table-form| select

form

Find page False | true Breadcrumbs (UIX only) False | true Si true des liens retours sont

générés Labels Tabname Display title Descriptor attribute Operations Insert allowed False | true Update allowed False | true Delete allowed False | true Maximum number of query hints Form layout Form width *Columns Table layout Table width New rows Nombre de lignes vides. Si la

23.03.2005 72 sur 73 Astrid von Wyl

Page 73: Evaluation du couplage entre Designer & JDeveloper …read.pudn.com/downloads166/ebook/760748/Rapportjdevloper.pdf · Evaluation du couplage entre Designer et JDeveloper Pour chacun

Evaluation du couplage entre Designer et JDeveloper

valeur est nulle pas possible de faire des insert.

Sortable False | true Tri dans les colonnes Use table range False | true Table range size Detail disclosure (UIX only) Cacher les détails Templates (UIX only) FormTemplateLocalName TableTemplateLocalName SelectTemplateLocalName FindTemplateLocalName

SupportingFiles

GroupIncludeFile Generation switches Generate view (UIXor JSP) False | true Generate level 2 TabBar (Global headers)

False | true

Generate controller group False | true JDG protected False | true

9. Remerciements

Je remercie mon directeur de travail, Monsieur Pierre-André Sunier, pour son soutien tout au long du travail. Je remercie également quelques diplômant : Yann Doerfliger qui a relu mon travail avec un œil très critique, Raphaël Eggenschwiler qui m’a donné de précieux conseils pour XML.

23.03.2005 73 sur 73 Astrid von Wyl