Vous êtes sur la page 1sur 13

Logiciel pour valider la saisie des

applications Web en utilisant XML et Java

Génie logiciel Eleonor Georgieva – 211316014


L'Université technique de Sofia
Contenu

1. XML
2. JAVA
3. Vérification versus Validation
Devriez-vous convertir toutes vos données en XML, puis valider ce XML par rapport à votre schéma?
 Votre schéma XML devrait-il être converti en Java et les objets utilisés pour valider vos données?
Learning objectives
 Quelle est la bonne chose à faire ici? Est-ce un mélange des deux?
4. La validation des données
5. Java vers XML
6. XML à Java
7. Analyser le shema
XML

Le XML ou eXtensible Markup Language est un langage


informatique de balisage générique.

•Le XML a été créé pour faciliter les échanges de données entre les machines et les logiciels.
•Le XML est un langage qui s'écrit à l'aide de balises.
•Le XML est une recommandation du W3C, il s'agit donc d'une technologie avec des règles strictes à
respecter.
•Le XML se veut compréhensible par tous : les hommes comme les machines.
•Le XML nous permet de créer notre propre vocabulaire grâce à un ensemble de règles et de balises
personnalisables.
10
Java min

Java est un langage de programmation inspiré du langage C++, avec un modèle de


programmation orienté objet.
Java permet de créer des applications complètes. Il peut également servir à créer un petit
module d'application, dit applet, à intégrer dans une page Web.

Click on the model to interact


Vérification versus Validation 15
min

Vérification: Le processus de V&V doit être appliqué à chaque étape du développement.


Ses objectifs:
● « Avons-nous construit le produit bien? »
● Montrer que le système n'a pas de défauts. – Principalement pour les systèmes critiques de
● i.e., le logiciel doit être conforme à sa spécification
niveau .
● Découvrir des défauts dans le système. – Ceci ne veut pas dire TOUS les défauts mais plutôt
augmenter la confiance dans ce système.
Validation: ● S'assurer que le système construit est utile et utilisable en pratique.
● « Avons-nous construit le bon produit? »
Types de V&V
● i.e., le logiciel doit faire ce que l'utilisateur a besoin
 Statique = inspection/analyse statique (i.e., sans exécution) du système pour découvrir des
problèmes ou prouver sa correction.
Sans exécution, peut être manuelle ou automatique
 Dynamique = expérimenter et observer le comportement à l'exécution du système.
Le système est exécuté sur des données de test et son exécution est observée
(manuellement ou automatiquement).
La validation des données
Ce code n'est ni proprement séparé ni réutilisable.
Le paramètre spécifique,, shoeSizea probablement
été obtenu à partir d'un formulaire HTML soumis.
Le paramètre est converti en une valeur
 La validation à granularité grossière est le processus visant à garantir que les données numérique (espérons-le!), Puis comparé aux
répondent aux critères de typage pour de nouvelles actions. Ici, "critères de saisie" valeurs maximales et minimales acceptables. Cet
exemple ne vérifie même pas les demi-tailles.
signifie des contraintes de données de base telles que le type de données, la plage et
les valeurs autorisées. Ces contraintes sont indépendantes des autres données et ne
nécessitent pas d'accès à la logique métier. Un exemple de validation à grain grossier
consiste à s'assurer que les pointures sont des nombres positifs, inférieurs à 20 et des
nombres entiers ou des demi-pointures.
 La validation fine est le processus d'application de la logique métier aux valeurs. Il se
produit généralement après une validation à granularité grossière et constitue la
dernière étape de la préparation, avant que l'un ne renvoie les résultats à l'utilisateur
ou ne transmette les valeurs dérivées aux autres composants de l'application. Un
exemple de validation à grain fin consiste à s'assurer que la taille demandée (déjà dans
le format correct en raison de la validation à grain grossier) est valide pour la marque
demandée. Les patins à roues alignées V-Form ne sont disponibles qu'en tailles
entières, donc une demande de taille 10 1/2 devrait provoquer une erreur. Parce que
cela nécessite une interaction avec une certaine forme de stockage de données et de
logique métier, il s'agit d'une validation à granularité fine.
 Le processus de validation à grain fin est toujours spécifique à l'application et n'est pas
un composant réutilisable, il dépasse donc le cadre de cette série. Cependant, la
validation à granularité grossière peut être utilisée dans toutes les applications et
implique l'application de règles simples (typage des données, vérification des plages,
etc.) aux valeurs. Dans cette série, j'examinerai la validation à grain grossier et fournirai
une solution basée sur Java / XML pour la gérer.
Java vers XML

La première option, la conversion de données Java en XML, est en fait assez simple. Avec la popularité croissante de la liaison de données XML, plusieurs cadres sont disponibles
pour convertir, ou marshaler, un objet Java en document XML. Un de ceux, que j'ai écrit (oui, c'est un plug sans vergogne!), Est discuté en détail dans "Objets, objets partout"  Un
package de travail complet est fourni pour la conversion entre Java et XML. L'API est simple, légère et intuitive - toutes les qualités souhaitables pour votre solution de validation.
Cependant, la liaison de données n'est pas aussi parfaite qu'elle peut paraître lorsque vous regardez un peu plus en profondeur. Tout d'abord, vos données Java peuvent souvent être
divisées en quatre, cinq ou même plus. Imaginez un formulaire qui reçoit 15 champs de saisie, tous en tant qu'objets Java distincts ( Strings, dans ce cas). Chacun devrait être assemblé en un
seul objet, marshalé en XML, puis validé par rapport au schéma XML. Votre code doit donc inclure une logique pour convertir plusieurs objets en un seul objet adapté à la
conversion en XML. Votre solution, autrefois simple, est donc déjà compliquée.
De plus, cette option ne permet aucune optimisation. Vous ne pouvez pas stocker le schéma XML en mémoire dans votre JVM, et le seul véritable avantage que vous pourriez
introduire est la mise en cache du document de schéma XML réel (en tant que DOM ou JDOM Documentobjet, peut-être). En d'autres termes, il n'y a aucun gain de performances sur plusieurs
appels de validation. Bien que cela puisse sembler une cerise sur le gâteau, considérez que la validation, en particulier des données de formulaire, se produit des centaines voire des
milliers de fois par page, par jour (ou heure ou minute!). La mise en cache, ou une sorte de gain de performances, devrait vraiment être attendue sur plusieurs invocations de la
validation. En outre, l'analyse XML est une opération coûteuse et même si le document de schéma XML est mis en cache, l'objet Java rassemblé, résultant en un document XML,
doit être analysé à chaque appel de validation. Ainsi, la conversion de Java en XML ne semble pas être une si bonne idée.
20
XML à Java min

Étant donné que la conversion de Java en XML ne semble pas être une bonne idée, examinons le revers: la conversion de XML en Java. Dans ce cas, vos données Java resteront telles quelles et
n'auront pas besoin d'être marshalées en XML. Vous auriez plutôt besoin de convertir vos contraintes de schéma XML en objets Java. Ces objets peuvent ensuite prendre des données et renvoyer un
résultat, indiquant si les données étaient valides pour les contraintes représentées par l'objet et le schéma XML sous-jacent. C'est aussi un cas beaucoup plus naturel pour les développeurs Java, car
cela leur permet de rester dans un environnement Java.
Un autre avantage de cette technique est qu'elle isole efficacement le schéma XML de l'équation. L'utilisation de schémas devient alors une décision liée uniquement à la conversion de XML à Java, et
non à l'utilisation des objets Java résultants. En d'autres termes, si l'implémentation de ces classes de validation était modifiée pour convertir un document XML (pas un schéma) en objet de
validation, le développeur verrait toujours la même interface pour la validation; aucun code d'application n'aurait besoin de changer. Pourquoi est-ce si important? Eh bien, il y a deux
raisons. Premièrement, le schéma XML est toujours en cours de finalisation et des modifications mineures peuvent se produire. L'utilisation de cette conception garantit que vous pouvez coder pour
les classes de validation couvertes dans cette série et, même si la spécification du schéma XML change et l'implémentation des classes change, votre code d'application reste le même.  Seconde, il
existe encore une certaine inquiétude généralisée quant à l'acceptation des schémas XML. S'ils ne répondaient pas à vos besoins, ou s'ils étaient peut-être trop compliqués pour votre application, vous
pourriez passer à un mécanisme plus simple (comme des documents XML simples ou Relax) et continuer à faire fonctionner les mêmes routines de code.
Pour revenir à certaines préoccupations d'origine, cela signifie également que votre document de schéma XML ne doit être analysé qu'une seule fois. Le schéma est converti en objets Java,
représentant des contraintes, puis stocké en mémoire. Les données peuvent être validées par rapport aux objets à plusieurs reprises sans analyse supplémentaire jamais effectuée. Cela résout certains
des problèmes de performances dont j'ai discuté dans la section sur la conversion de Java en XML. Cela est encore plus critique lorsque le schéma XML peut se trouver sur un réseau, nécessitant un
temps de transfert réseau pour chaque analyse.
Il semble donc clair que la conversion de XML à Java est la bonne voie à suivre. De plus, vous voulez plus qu'un simple objet en Java (comme celui qui pourrait être produit en démêlant un document
de schéma XML à Java, comme dans la liaison de données); il doit prendre un morceau de données, puis retourner si les données sont valides pour les contraintes fournies dans le schéma XML.
En commençant par une conception de base, j'ai montré les cdont vous avez besoin pour coder:

La Constraintclasse, qui représente les contraintes pour un seul type, comme le shoeSizetype
La Validatorclasse, qui fournit une interface permettant aux développeurs de transmettre des données et de savoir si les données sont
valides.

La schemaParserclasse, qui analyse un schéma XML et crée les Constraintobjets à utiliser par la Validatorclasse.
La DataConverterclasse d'assistance, qui convertira les types de données du schéma XML en types de données Java et effectuera
d'autres conversions de types de données pour vous.
Analyser le schéma
La majeure partie du travail que vous devez faire est en schemaParserclasse. Cette classe a une seule tâche: analyser un
schéma XML. Pendant qu'il analyse, il doit prendre chaque attribut de schéma XML et en créer une Constraintinstance.
Pour rafraîchir votre mémoire, voici un exemple de schéma XML. Cela est toujours basé sur le magasin de chaussures qui a
été discuté dans les articles précédents, mais présente des contraintes supplémentaires

Par exemple, le schemaParseranalyserait l'attribut de la contrainte nommée "shoeSize" et créerait une nouvelle instance
de la Constraintclasse. Cette classe aurait un type de données "int". Notez qu'il n'a pas "entier" car il s'agit d'un type de
données de schéma XML. Au lieu de cela, la Constraintclasse convertit ce type de donnes (à l'aide de la
DataConverterclasse) en équivalent Java. Il aura alors une valeur de 0 pour la valeur minimale (exclusive) et une valeur de
20 pour la valeur maximale (inclusive). Dans cette contrainte, les valeurs minimum (inclus), maximum (exclusif) et
autorisées ne seront pas toutes utilisées, car elles ne sont pas spécifiées; une autre contrainte peut spécifier des valeurs
autorisées mais aucune plage du tout. Donc, avec cela à l'esprit, je vais commencer par regarder le squelette de la classe.
La clé de toute la classe est d'être capable (sans surprise ici) d'analyser un schéma XML. De nombreux analyseurs
XML, comme Apache Xerces, offrent actuellement des options pour la validation de schéma; toutefois, vous ne
souhaitez pas utiliser ces fonctionnalités. En fait, vous ne voulez pas du tout que le schéma XML soit traité comme
un schéma. En effet, tous les analyseurs, au moins dans leurs versions actuelles, utilisent des structures spécifiques
au fournisseur pour gérer les schémas XML. Le résultat est un code non portable, l'ennemi de tout programmeur
Java

Au lieu de cela, la schemaParserclasse peut s'appuyer sur le fait qu'un document de schéma XML est également un
document XML. Il est conforme aux règles de bonne forme de XML et peut donc être traité comme tout autre document
XML. Par conséquent, l'analyseur de schéma peut lire le schéma XML en tant que document XML et l'utiliser comme il le
ferait pour tout autre document avec lequel il fonctionne. C'est exactement ce que fait la parseschema()méthode.

À l'aide de JDOM, que vous pouvez obtenir dans les ressources , la parseschema()méthode utilise d'abord SAX pour lire l'URL de
schéma fournie et créer un Documentobjet JDOM . Et c'est maintenant que cette schemaNamespacevariable entre en jeu
(rappelez-vous que je l'ai dit?). La attributeconstruction du schéma XML représente toutes les contraintes, donc une fois que le
document est lu en mémoire, ces contraintes sont situées dans le document en recherchant simplement tous les éléments
nommés attribut (je sais, c'est un peu déroutant, n'est-ce pas? Tout l'attribut éléments ...) dans l'espace de noms XML Schema.
Ensuite, chacun des objets résultant (représenté par un JDOM Element) sont transmis à un procédé d'utilité, handleAttribute().
Le code montré ici met cela en action: