Projet MVC-CD Les Domaines Créé par F. Camus, le 24 juin 2015 Modifié par F. Camus, le 2 juillet 2015 Page 1 sur 18
Table des matières 1 Préambule...3 2 Concepts retenus autour de la notion de domaine...3 2.1 Concept de domaine... 3 2.2 Restrictions de valeurs... 4 2.2.1 Mécanismes de restrictions de valeurs...4 2.2.2 Portée de la validité cohérence et exactitude...4 2.3 Typologies de domaines... 7 3 Concept de domaines dans les SGBD-R...8 3.1 Norme SQL... 8 3.2 Implémentation chez les constructeurs... 8 4 Les domaines dans Visual Paradigm...9 5 Domaines dans MVC-CD... 10 5.1 Objectifs... 10 5.2 Définition de domaines... 10 5.2.1 Domaines et types de données dans MVC-CD... 10 5.2.2 Domaines universels et normalisés proposés par MVC-CD... 11 5.2.3 Création d'un domaine personnalisé... 14 6 Possibilités de transformation au niveau physique pour Oracle... 17 7 Références... 18 7.1 Internes au projet... 18 7.2 Externes... 18 Page 2 sur 18
1 Préambule Le profil UML du plugin MVC-CD contient déjà un certain nombre de types de données de base et spécialisées. Or ces types peuvent s'avérer trop généralistes dans une volonté de cohérence des données d'un SI. Il est courant de vouloir définir une restriction sur les valeurs d'un attribut, en fonction d'un contexte métier particulier, afin de garantir la cohérence des données. Ces restrictions peuvent être de nature différente (énumération, plage de valeurs autorisées, etc ) et s'appliquent sur un type de donnée existant. Dans une démarche d'ingénierie du logiciel, les domaines répondent à ce besoin. 2 Concepts retenus autour de la notion de domaine 2.1 Concept de domaine Un domaine, en tant que concept du modèle relationnel, représente l'ensemble (fini ou non) des valeurs possibles que peut prendre un attribut. Exemples : L'ensemble des entiers est un domaine {rouge, bleu, jaune} est un domaine Un prénom a comme domaine l'ensemble des combinaisons de lettres (c'est-à-dire une chaine de caractères) Dans une démarche d'ingénierie du logiciel, un domaine s'appuie sur un type de donnée, porte un nom et défini un ensemble de valeurs autorisés pour un attribut. Selon cette définition, dans notre profil MCD, les types boolean et positiveinteger (pour ne citer qu'eux) sont donc déjà des domaines. Un domaine peut donc être vu comme une spécialisation d'un type de donnée dans le but de définir des valeurs valides (restriction sur les valeurs autorisées) sur un attribut. Un domaine créé devient donc formellement un nouveau type de données que peut prendre un attribut d'une entité. Page 3 sur 18
2.2 Restrictions de valeurs 2.2.1 Mécanismes de restrictions de valeurs Un domaine doit permettre de spécifier une règle de restriction de valeurs. Nous avons identifié plusieurs mécanismes possibles permettant de restreindre les valeurs autorisées : Enumération : liste finie de valeurs distinctes Expression booléenne : Expression dont la condition à évaluer retourne un résultat booléen Expression régulière Tous les types de restrictions ne s'appliquent naturellement pas sur tous les types de données de base. Bien que l'expression régulière puisse prendre en charge les énumérations, nous avons décidé de conserver le mécanisme d'énumération de part sa simplicité de compréhension et de mise en œuvre, mais aussi parce qu'il s'applique aisément à plusieurs types de données, tandis que l'expression régulière se limite aux chaines de caractères. 2.2.2 Portée de la validité cohérence et exactitude Toute contrainte sur les données (SII/SGBD-R) a pour but de garantir la cohérence de celles-ci. Mais la notion de cohérence n'englobe pas la notion d'exactitude. Pour illustrer ces deux notions, nous nous appuierons sur les adresses email : albert.levert@he-arc.ch est une adresse email syntaxiquement valide albert.levert@he-arc n'est pas une adresse email syntaxiquement valide albert.levert@he-arc.ch n'est pas une adresse mail exacte, car elle n'existe pas dans le domaine he-arc.ch. Si l'on envoie un email à cette adresse, l'expéditeur aura un message du serveur lui indiquant que cette adresse n'existe pas. Le concept de domaine ne doit pas faire exception à cela. Il serait très facile de vouloir déroger à cette règle, étant donné la capacité du domaine à définir n'importe quelle règle. Les mécanismes d'énumération et d'expressions booléennes vont se traduire par des contraintes techniques ensemblistes ou relationnelles, n'autorisant la valeur que si l'expression ensembliste ou relationnelle est validée. Il n'est pas possible de vouloir vérifier l'exactitude de la valeur. Le mécanisme d'expression régulière de part sa nature va permettre de vérifier que la construction syntaxique de la valeur est respectée selon un motif déterminé. Par contre, ce mécanisme ne peut prendre en charge la vérification de l'exactitude de la valeur. Page 4 sur 18
Cas 1 : adresse email La structure d'une adresse email est connue et normalisée (RFC-3696, errata 1690 1 ). Une adresse email est valide si la syntaxe est respectée. Le mécanisme d'expression régulière est approprié pour cela. Cas 2 : Code postal suisse En Suisse, le code postal est constitué de 4 caractères composés exclusivement de chiffres, dont le premier commence par 1. Le code postal 2000 est syntaxiquement correct. De plus c'est une donnée exacte, dans le sens où la valeur en tant que tel existe. Par contre, le code postal 2999, bien que syntaxiquement correct, n'existe pas en tant que code postal parmi la liste actuelle et officielle des codes postaux utilisés en Suisse. Ce n'est pas une valeur exacte, valide, dans le contexte métier. Là aussi, l'expression régulière va permettre de définir une validation syntaxique. Cas 3 : IBAN L'IBAN est la norme internationale (ISO 13616) pour l'identification des numéros de comptes bancaires. Un numéro de compte au format IBAN a la structure suivante : Il est composé de deux lettres représentant le pays (code ISO 3166-1 alpha-2), de 2 chiffres de contrôles (algorithmiquement vérifiable) et du BBAN (Basic Bank Account Number). Un IBAN peut contenir jusqu'à 34 caractères. Chaque pays défini la structure du BBAN, c'est-à-dire de quoi il est formé et sur combien de positions. Parmi les informations composantes le BBAN, il y a systématiquement le code de la banque, mais ni la présence de cette information ni la valeur ne sont normalisés. Format IBAN Suisse (repris de [WIK-01]) : CHkk BBBB BCCC CCCC CCCC C, où : CH est le code ISO 3166 pour la Suisse kk sont les chiffres de contrôles le BBAN est construit avec 5 positions représentant le code de la banque et 12 positions pour le numéro de compte. Format IBAN France (repris de [WIK-01] également) : FRkk BBBB BGGG GGCC CCCC CCCC CKK, où : FR est le code ISO 3166 pour la France kk sont les chiffres de contrôles le BBAN est construit avec 5 positions représentant le code de la banque, 5 positions pour le code du guichet, 11 positions pour le numéro de compte et 1 pour la clé RIB 2 1 [RFC-01] et [RFC-02] 2 Permet de vérifier la validité du numéro de compte par un algorithme ([WIK-02]) Page 5 sur 18
Dans les cas présentés, nous pouvons constater deux niveaux de validité : une validation syntaxique/structurelle, agissant sur le format de la valeur (structure de la valeur, nombre de positions, types numériques ou caractères) ainsi qu'une validation sur l'exactitude de la valeur. Cette dernière pourrait être réalisée mais cela impliquerait la nécessité d'accéder à des services techniques distants nous offrant les éléments nécessaires pour la réaliser (liste des codes ISO des pays, liste des offices de postaux, liste des codes bancaires, etc ). Nous considérons qu'un domaine doit se limiter à garantir la cohérence des données, comme tout mécanisme de contrainte existant dans un SGBD-R et donc ne saurait être capable de prendre en charge l'exactitude des données. Dans les cas présentés, la création d'un domaine email ou codepostalsuisse est tout à fait pertinente pour vérifier la validité syntaxique de la valeur. La création d'un domaine IBAN pourrait techniquement être réalisé, mais il devrait se limiter à vérifier que la valeur commence par deux lettres majuscules, suivi de deux chiffres, eux-mêmes suivi de maximum 30 caractères. On pourrait aller jusqu'à vérifier le nombre de positions selon le pays. Ces limitations de validation font qu'un domaine IBAN n'a pas vraiment d'intérêt. Page 6 sur 18
2.3 Typologies de domaines Nous avons identifié deux types de domaines Les domaines qui sont des spécialisations de types de données à portée universelle. Ces domaines sont réutilisables et les règles sur les valeurs autorisées sont connues et normalisées: o email (IETF, RFC 3696) o URI-URL (IETF, RFC 3986), IPv4 (IETF, RFC 791), IPV6 (IETF, RFC 2460) o devise (ISO 4217) o unité de masse, de longueur, d'espace et de temps, etc (ISO 80000-1:2009) o xml, pour tout document xml bien-formé (W3C) Les domaines personnalisés (répondant à un besoin métier spécifique) ou les domaines dont l'utilisation en informatique n'est pas formalisé/normalisé : o baremenote=[1.0..6.0], o notemodule={'a','b,'c','d','e','f','fx'} o sexe={'h','f'} 1 o code postal suisse : chaine de caractères composée de 4 chiffres, mais dont le premier ne peut pas être 0 (expression régulière [1-9] [0-9]{3}) 1 [WIK-03] : la notion de représentation du sexe chez l'homme a été normalisée (ISO 5218), mais avec un code numérique, dans le but de représenter de façon fiable cette information et aussi de favoriser l'échange de données entre systèmes d'information. Il serait dès lors envisageable de créer un domaine universel dans une vision d'échanges de données entre SI. Page 7 sur 18
3 Concept de domaines dans les SGBD-R 3.1 Norme SQL [SQL-01], page 53 : "A domain is a set of permissible values. A domain is defined in a schema and is identified by a <domain name>. The purpose of a domain is to constrain the set of valid values that can be stored in a column of a base table by various operations. A domain definition specifies a data type. It may also specify a <domain constraint> that further restricts the valid values of the domain and a <default clause> that specifies the value to be used in the absence of an explicitly specified value or column default". 3.2 Implémentation chez les constructeurs La notion de domaine est très peu mise en œuvre dans les SGBD-R. Pour ne citer que 3 exemples : Oracle ne prend pas en charge la notion de domaine telle que définie dans la norme SQL. Pour mettre en œuvre cette notion, nous devons utiliser une contrainte de type CHECK sur la colonne de table ALTER TABLE ResultatExamen ADD CONSTRAINT CHECK(noteObtenue =>1 AND noteobtenue <=6); PostgreSQL offre un objet Domain qui est conforme à la norme SQL [PG-01] : CREATE DOMAIN baremenote AS NUMERIC(3,2) CHECK (VALUE =>1 AND VALUE <=6); CREATE TABLE ResultatExamen (, noteobtenue baremenote, ); SQL Server ne supporte pas en tant que tel la notion de domaine mais permet de la simuler par une contrainte CHECK ou par une combinaison de règles et types utilisateur Page 8 sur 18
4 Les domaines dans Visual Paradigm Visual Paradigm dans sa version 11 propose de manière simpliste la notion de domaine dans le diagramme E-R. Un domaine peut s'appliquer sur une colonne de table (column domain) ou sur une table (entity domain). Un domaine VP est très limité par rapport à ce qu'on souhaite mettre en œuvre. Un domaine se base sur un type et permet de définir une contrainte CHECK, mais il faut lui indiquer l'expression complète, dont le nom de colonne, que l'on ne connait pas par définition! Page 9 sur 18
5 Domaines dans MVC-CD 5.1 Objectifs Notre plugin MVC-CD doit prendre en charge le concept de domaine dans MVC-CD pour permettre au concepteur : d'utiliser des domaines prédéfinis, couramment utilisés dans les SII de définir lui-même ses propres domaines, en fonction de besoins métiers spécifiques, exploitant un des mécanismes de restriction proposés au chapitre 2.2.1. Dans tous les cas, le plugin doit prendre en charge la transformation d'un domaine en code exécutable au niveau physique. 5.2 Définition de domaines L'objet Domain proposé par Visual Paradigm n'étant pas satisfaisant, nous représenterons la notion de domaine par une classe UML. 5.2.1 Domaines et types de données dans MVC-CD Les types de données proposés dans [RF-1] sont pour une bonne majorité fondamentalement des domaines, puisque ils sont caractérisés par des restrictions de valeurs (exemples avec positiveinteger ou boolean). Pour rappel (chapitre 2.3), nous avons défini deux catégories de domaines : les domaines universels et les domaines personnalisés. Les premiers seront proposés dans le profil UML au concepteur, tandis que les seconds sont les domaines que pourra créer le concepteur dans son projet. Nous allons donc considérer dans notre plugin MVC-CD, plus précisément dans le profil UML, que les notions de domaine et type de données sont confondus. Les domaines universels que nous proposons dans le profil UML sont donc créés avec le stéréotype <<type>> et feront partie intégrante des types de données. Les restrictions de valeurs des types de données du profil sont exprimées dans les spécifications ([RF- 1]) et sont prises en charge nativement par le plugin MVC-CD. Les restrictions de valeurs ne sont pas explicitées dans la classe UML représentant le type, sous forme de valeur taguée par exemple. Afin d'être cohérent, les domaines universels que nous proposons suivront cette même règle, c'est-à-dire que la règle de restriction sera spécifiée et prise en charge nativement par le plugin. Pour chaque domaine fourni nous ferons une proposition de mise en œuvre technique de la restriction. Toutefois cette proposition n'est que conceptuelle. La mise en œuvre technique de la restriction (niveau physique) peut différer selon les possibilités offertes par le SGBD-R cible. Les domaines personnalisés seront créés par le concepteur manuellement, dans le projet courant. Un domaine personnalisé sera une spécialisation d'un type existant (du profil UML). Quant à la règle de restriction de valeurs, il sera de la responsabilité du concepteur de la spécifier. Page 10 sur 18
5.2.2 Domaines universels et normalisés proposés par MVC-CD Plusieurs domaines universels et couramment utilisés sont fournis par MVC-CD au travers du profil MCD et peuvent donc être utilisés en tant que tel dans tout projet. 5.2.2.1 email Le domaine email permet de saisir et valider une adresse mail. La RFC 3696 ([RFC-01]) défini la validité syntaxique d'une adresse email. De nombreuses discussions ont eu lieu sur la réalisation d'une expression régulière pour satisfaire la RFC. Cette RFC se veut plus permissive et complexe qu'on ne le pense réellement. Par exemple, une adresse mail peut contenir dans la partie avant le signe '@' des caractères tels que le guillemet, l'apostrophe, etc Une tentative de création d'une expression régulière a été faite, mais sur la RFC 822 (Standard for ARPA Internet Text Messages), [REG-01]. L'expression régulière fait plusieurs dizaines de lignes et sa complexité n'est pas quantifiable! D'autres tentatives ont été réalisées sur la RFC2822 (Internet Message Format). Elle remplace la RFC 822. La RFC 3696 s'appuie sur les RFC 2821 et 2822 (elle-même remplacée par la RFC 5322!) pour compléter et affiner les diverses recommandations. La RFC 3696 a d'ailleurs des erreurs, qui sont corrigées sous forme de RFC errata ([RFC-02]). Au détour de nombreux témoignages sur les blogs et autres forums, les expressions régulières proposées sont toutes simplifiées et permettent de couvrir la plupart des cas. Il existe autant de propositions que de témoignages Le W3C, dans la norme HTML5, propose sa propre expression régulière, selon la définition suivante ([W3C-01]): A valid e-mail address is a string that matches the email production of the following ABNF, the character set for which is Unicode. This ABNF implements the extensions described in RFC 1123. [ABNF] [RFC5322] [RFC1034] [RFC1123] Note : This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here. Nous retenons la proposition d'implémentation du W3C dans notre plugin (syntaxe compatible JavaScript). /^[a-za-z0-9.!#$%&'*+/=?^_`{ }~-]+@[a-za-z0-9](?:[a-za-z0-9-]{0,61}[a-za- Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/ Page 11 sur 18
Au niveau de notre profil, le type email est une spécialisation du type token 5.2.2.2 httpurl La saisie d'un lien hypertexte dans un SII est monnaie courante (site web du client, du fournisseur, etc ). C'est tout naturellement que nous proposons le domaine httpurl, qui est le cas d'utilisation le plus fréquent des URI. La syntaxe d'une URI est définie dans la RFC 3986 (IETF) ([RFC-02]). Une URL est un sous-ensemble des URI. Tout comme pour une adresse email, plusieurs propositions d'expressions régulières sont disponibles sur internet. Parmi toutes, nous retenons celle qui a eu le meilleur score dans l'évaluation réalisée à [REG-02], dont l'auteur est identifié par @diegoperini. _^(?:(?:https?)://)(?:\s+(?::\s*)?@)?(?:(?!10(?:\.\d{1,3}){3})(?!127(?:\.\d {1,3}){3})(?!169\.254(?:\.\d{1,3}){2})(?!192\.168(?:\.\d{1,3}){2})(?!172\.(?:1[6-9] 2\d 3[0-1])(?:\.\d{1,3}){2})(?:[1-9]\d? 1\d\d 2[01]\d 22[0-3])(?:\.(?:1?\d{1,2} 2[0-4]\d 25[0-5])){2}(?:\.(?:[1-9]\d? 1\d\d 2[0-4]\d 25[0-4])) (?:(?:[a-z\x{00a1}-\x{ffff}0-9]+-?)*[a-z\x{00a1}-\x{ffff}0-9]+)(?:\.(?:[a-z\x{00a1}-\x{ffff}0-9]+-?)*[a-z\x{00a1}-\x{ffff}0-9]+)*(?:\.(?:[a-z\x{00a1}-\x{ffff}]{2,})))(?::\d{2,5})?(?:/[^\s]*)?$_ius Nota : nous avons adapté cette expression régulière pour être totalement en adéquation avec un domaine pour des URL de type Http (nous avons enlevé de la version original le protocole ftp 1 ). Au niveau de notre profil, le type httpurl est une spécialisation du type token 1 Il serait tout à fait envisageable de créer un domaine URL, avec comme sous-type HttpURL et ftpurl pour étendre les domaines disponibles. Page 12 sur 18
5.2.2.3 xml Le domaine xml permet de stocker une chaine de caractères représentant un document XML bienformé (W3C) Le mécanisme pour vérifier si le document est bien-formé ne peut être mis en œuvre que par un algorithme. Qui plus est, un SGBD-R comme Oracle propose un type de donnée nommé XMLType permettant de stocker un document bien-formé, d'y effectuer des requêtes XPath Au niveau conceptuel, nous ne fournissons délibérément pas d'algorithme de vérification. La mise en œuvre au niveau physique dépendra du SGBD-R cible. Au niveau de notre profil, le type xml est une spécialisation du type sequenceanystring Page 13 sur 18
5.2.3 Création d'un domaine personnalisé 5.2.3.1 stéréotype <<domaine>> Le profil MVC-CD contient un stéréotype <<domaine>>. Ce stéréotype permet au concepteur de créer ses propres domaines. mecanisme : énumération permettant d'indiquer la nature du mécanisme de restriction de valeurs. Il contient les valeurs suivantes : {enum,exprbool,regex} expression : contient comme valeur une chaine de caractère contenant l'expression à évaluer, qui peut être soit une expression booléenne, soit une expression régulière. Le concepteur doit donc créer son domaine en spécialisant un type de donnée prédéfini. La spécification des tailles (longueur de chaine, précision/échelle pour les numériques) doit se faire de la même manière que pour les types prédéfinis. 5.2.3.2 Enumération Un domaine dont le mécanisme est une énumération implique la création d'une classe stéréotypée <<domaine>> et d'une énumération (au sens UML), les deux étant mis en relation par une association unidirectionnelle L'énumération contient la liste des valeurs possibles. Le domaine utilise l'énumération créée comme source de valeurs. Règle de nommage : Le nom du domaine est au singulier tandis que le nom de l'énumération porte le même nom que le domaine mais au pluriel Page 14 sur 18
Le paramétrage des valeurs taguées dans ce cas de figure est le suivant Puisque le mécanisme appliqué est une énumération, la valeur tagguée expression n'est pas renseignée. 5.2.3.3 Expression booléenne L'expression booléenne est une chaine de caractère représentant une expression à évaluer et rendant un résultat de type booléen. L'expression doit non seulement respecter la syntaxe OCL, mais il faut encore y inclure le mot-clé self pour faire référence à l'attribut sur lequel de domaine s'applique. C'est au cours du processus de transformation que l'expression sera adaptée pour faire référence à la colonne de table sur laquelle s'applique la restriction. Page 15 sur 18
5.2.3.4 Expression régulière Une expression régulière est à saisir dans la valeur tagguée expression lorsque le mécanisme choisi est regex. 5.2.3.5 Typage d'un attribut Un domaine étant un type de données, donc une classe UML, le type d'un attribut se fait de manière tout à fait traditionnel Page 16 sur 18
6 Possibilités de transformation au niveau physique pour Oracle Puisque les domaines selon la norme SQL ne sont pas supportés par le SGBD-R Oracle, le choix se porte naturellement vers les possibilités de mises en œuvre suivantes : Type de donnés natif Contrainte déclarative CHECK Prise en charge par les APIs de tables Ci-dessous sont répertoriés tous les domaines (universels et personnalisés) répertoriés dans ce document. Pour chacun d'entre eux nous indiquons de quelle(s) manière(s) ils peuvent être pris en charge dans le SGBD-R Oracle Type natif Oracle CHECK APIs de table email httpurl xml (XMLType) notemodule baremenote codepostalch Remarque : XMLType est un type de données natif du SGBD-R Oracle permettant de stocker un document XML. Oracle vérifie automatiquement que le document XML soit bien formé lors de l'insertion/modification du document XML dans la colonne de table. HttpUriType est un type de données natif du SGBD-R Oracle permettant de stocker un URL utilisant le protocole http. Par contre Oracle ne vérifie pas si l'url est syntaxiquement correcte. Page 17 sur 18
7 Références 7.1 Internes au projet [RF-1] Profils UML2 et types de données http://lgl.isnetne.ch/sagex35793/profiluml/profilsuml.pdf 7.2 Externes [PG-01] CREATE DOMAIN, PostgreSQL 9.4 http://docs.postgresqlfr.org/9.4/sql-createdomain.html [SQL-01] [REG-01] Norme SQL 2008 en version draft, SQL20nn.zip, 7IWD2-01-Framework-2011-12 http://www.wiscorp.com/sqlstandards.html Mail::RFC822::Address: regexp-based address validation, P. Warren,17/09/2012 http://www.ex-parrot.com/~pdw/mail-rfc822-address.html [REG-02] In search of the perfect URL validation regex, Mathias Bynens https://mathiasbynens.be/demo/url-regex [RFC-01] RFC 3696, Application Techniques for Checking and Transformation of Names, IETF, février 2010 https://tools.ietf.org/html/rfc3696 [RFC-02] Errata 1690 pour la RFC 3696, IETF, avril 2010 http://www.rfc-editor.org/errata_search.php?rfc=3696&eid=1690 [RFC-02] RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, IETF, Janvier 2005 http://www.rfc-editor.org/errata_search.php?rfc=3696&eid=1690 [W3C-01] [WIK-01] [WIK-02] [WIK-03] HTML5, forms, input element, email state http://www.w3.org/tr/html5/forms.html#valid-e-mail-address IBAN, wikipedia https://fr.wikipedia.org/wiki/international_bank_account_number Clé RIB, wikipedia https://fr.wikipedia.org/wiki/cl%c3%a9_rib Norme ISO 5218, Représentation des sexes humains, wikipedia https://fr.wikipedia.org/wiki/iso_5218 Page 18 sur 18