Eléments théoriques en complément du cas pratique ArcPizzas P.-A. Sunier 10 octobre 2012 / 24 juillet 2015 http://lgl.isnetne.ch
Table des matières 1 Propos liminaire... 4 2 Notions de base... 5 2.1 Qu'est-ce que la modélisation?... 5 2.2 Qu'est-ce que Visual Paradigm?... 6 2.2.1 Référentiel... 6 2.2.2 Modèles... 7 2.2.3 Diagrammes... 7 2.3 Qu est-ce que le système?... 8 3 Modèle des cas d'utilisation métier... 8 3.1 Description des cas d'utilisation métier... 9 4 Modèle des cas d'utilisation du système d'information... 12 4.1 Description des cas d'utilisation du système d'information... 13 5 Modèle d'analyse... 15 5.1 Diagramme de communication... 16 5.2 Modèle conceptuel de données... 18 6 Maquettes de validation... 20 6.1 Validation du diagramme de communication... 20 6.2 Validation des besoins implicites découlant du MCD... 21 7 Conception... 22 7.1 Partie statique les données... 22 7.1.1 Transformation MCD MLD... 22 7.1.2 Le MLD relationnel... 25 7.1.3 Enrichissement du MLD... 25 7.2 Partie dynamique les traitements... 28 7.2.1 Préambule... 28 7.2.2 Modèle client-serveur... 28 7.2.3 Couplage MS-Access & Oracle... 29 7.2.4 Travaux préparatoires... 31 7.2.5 Conception des interfaces utilisateurs... 32 7.2.6 Conception des contrôleurs... 33 8 Implémentation... 34 8.1 Partie statique les données... 34 8.2 Partie dynamique les traitements... 37 8.2.1 Introduction... 37 8.3 Phase de développement et de test... 38 2/44 P-A. Sunier
8.4 Phase d'exploitation... 38 9 Tests... 39 9.1 Partie statique les données... 39 9.2 Partie dynamique les traitements... 42 9.3 Finalisation des transactions... 42 10 Liens Internet... 43 11 Bibliographie... 44 3/44 P-A. Sunier
1 Propos liminaire Ce document présente les choix que nous avons retenus pour réaliser le cas pratique ArcPizzas d'illustration introduisant aux bases de la modélisation du système d'information de l'entreprise. Il n'est en aucun cas un cours de méthode, de modélisation, de conduite de projet ou encore d'utilisation d'un outil de modélisation comme Visual Paradigm. La problématique d'une entreprise de livraisons de pizzas à domicile est volontairement très simplifiée pour permettre de nous concentrer sur la problématique générale sans être submergé par tous les cas particuliers qu'il faudrait prendre en compte dans une situation réelle. Le but de l'exercice ArcPizzas est de faire une démarche, basée sur la modélisation, allant de la compréhension du métier d'une entreprise à la réalisation d'un logiciel de gestion supportant tout ou parties de ses activités métiers. Conformément à ce but, nous devrons avoir une vision assez large du métier de l'entreprise mais, plus nous avancerons dans le processus de modélisation, plus nous restreindrons le périmètre de chacun des modèles. En effet, il n'est pas envisageable de réaliser un logiciel de gestion conséquent dans ce cours d'initiation à la modélisation. Toutefois, pour bien confirmer l'intérêt de la démarche, nous finirons par réaliser le formulaire qui permettra à ArcPizzas de gérer informatiquement son offre de pizza; nous reproduisons ce formulaire ci-après. Pour poser les bases de la modélisation, nous allons nous appuyer pour l'essentiel sur le langage de modélisation UML 1 et sur la méthode UP 2 en retirant ce qui nous semble superflu pour l'exercice et en ajoutant des éléments qui nous semblent pertinents comme les maquettes. Pour la partie réalisation, nous nous appuierons sur une plateforme d'exécution de type clientserveur, en l'occurrence, avec Oracle comme serveur de base de données et MS-Access pour la partie client lourd. Le site Web permettant aux clients de passer des commandes par Internet, nécessitera une extension de la plate-forme d exécution. 1 UML Unified Modeling Language, langage unifié de modélisation proposé par Booch, Rumbaugh et Jacobson au milieu des années 1990. 2 UP Unified Process, processus (méthode) unifié de développement de logiciels de gestion proposé par Booch, Rumbaugh et Jacobson à la fin des années 1990. 4/44 P-A. Sunier
2 Notions de base 2.1 Qu'est-ce que la modélisation? La modélisation est une démarche qui tend à représenter sous une forme compréhensible un objet ou une situation existante ou à venir. Un modèle, résultat de la démarche de modélisation, n'est pas la réalité mais une simplification de celle-ci privilégiant un point de vue. Un modèle n'est pas neutre; le message que transmet le concepteur 3 au travers du modèle peut être fortement déformé par l'interprétation du récepteur. 3 En tant qu émetteur d un message. 5/44 P-A. Sunier
2.2 Qu'est-ce que Visual Paradigm? Visual Paradigm est un outil de modélisation de l'entreprise et de son système d'information; il a la capacité de transformer des modèles et de générer du code applicatif à partir des modèles. L'emploi d'outils tels que Visual Paradigm devrait permettre d'être plus efficient durant le cycle de vie de logiciels de gestion depuis la compréhension du métier de l'entreprise jusqu'à l'exploitation des logiciels constitutifs de son système d'information informatisé. 2.2.1 Référentiel En utilisant un outil informatique de modélisation comme Visual Paradigm, l'ensemble des descriptions supportées par les modèles est enregistré et conservé au sein d'une structure de données nommée usuellement référentiel. Dans le cliché ci-contre, nous voyons les différents éléments du référentiel qui ont été créés au sein du modèle Métier. Cette zone s'appelle le navigateur du référentiel ou explorateur de modèles. 6/44 P-A. Sunier
2.2.2 Modèles La modélisation de l'entreprise et de son système d'information nécessitent de nombreux points de vue ou regards tout comme pour la construction d'une maison. Pour la construction d'une maison l'architecte doit faire des plans de maçonnerie, d'électricité, de charpente, d'aménagement extérieur. Dans le navigateur du référentiel cicontre, nous voyons différents modèles: Analyse, ExigencesSI, Métier; ces modèles expriment des points de vue différents. 2.2.3 Diagrammes Les diagrammes sont la forme usuelle d'écriture et de lecture du contenu du référentiel; en effet, il est plus aisé pour un humain de travailler avec une représentation graphique qu'avec le contenu brut d'une structure de données (le référentiel). Dans le navigateur de diagrammes ci-contre, Metier et SI sont deux diagrammes. 7/44 P-A. Sunier
2.3 Qu est-ce que le système? Le système, abrégé par la suite SI, est un des sous-systèmes constitutifs de l entreprise selon l approche relevant de la systémique. L approche systémique nous propose de considérer l entreprise, en tant que système, formé de trois sous-systèmes essentiels: le sous-système opérant (SO) qui active les processus métier pour créer la valeur ajoutée; le sous-système de pilotage (SP) qui coordonne l ensemble de l activité en fonction des objectifs; [2] le sous-système d information (SI) qui décrit, mémorise et capte l ensemble des événements caractéristiques à la fois du sous-système de pilotage et du sous-système opérant. Le sous-système d information (SI) participe à la pérennité et à la stabilité de l entreprise en captant, mémorisant, traitant et restituant les informations et données émises ou reçues par les sous-systèmes opérants et de pilotage. De plus il participe à l ouverture sur l environnement en émettant de l information vers l extérieur ou en captant de l information externe. 3 Modèle des cas d'utilisation métier Le modèle des cas d'utilisation métier est le premier modèle que préconise de réaliser la méthode UP. Ce modèle a comme objectif d'expliciter le métier de l'entreprise c'est-à-dire, les services (cas d'utilisations métier) qu'il offre à ses clients (acteurs métier) ou à son environnement; en fait, le modèle de cas d'utilisation se focalise sur le sous-système opérant de l'entreprise. En plus de faciliter la compréhension du métier de l'entreprise, ce modèle permet souvent d'esquisser les besoins les plus évidents en traitements de l'information; ces besoins évidents relèvent souvent du support organisationnel offert par le système d'information de l'entreprise. 8/44 P-A. Sunier
Très succinctement, le diagramme ci-dessus représente l'entreprise ArcPizzas qui propose à ses clients un catalogue de pizzas à livrer à domicile et un service de commandes et livraisons. Les entreprises peuvent aussi bénéficier des services d'arcpizzas toutefois, pour elles, le paiement ne se fait pas à la livraison mais sur facture. 3.1 Description des cas d'utilisation métier La seule représentation graphique des cas d'utilisation métier et de leur utilisation par des acteurs métiers ne suffit de loin pas à expliciter les services offerts par l'entreprise à ses clients ou à son environnement; il y a lieu de décrire ces cas d'utilisation métier. Plusieurs manières de faire sont possibles concurremment ou conjointement; un texte peut décrire un cas d'utilisation métier mais, une des manières qui nous semble intéressante, en termes de synthèse et de rigueur de la description est de passer par un diagramme d'activité. Pour faciliter la recherche de nos diagrammes et de leur contenu, nous utiliserons la capacité de structuration du référentiel en créant systématiquement nos diagrammes et objets de modélisation en tant que partie de l'élément qu'ils décrivent. Dans le cas présent, notre diagramme d'activité Commander Pizza Métier qui va décrire le cas d'utilisation métier Commander Pizza est créé en tant que partie ou enfant de ce cas d'utilisation. Dans le diagramme d'activité ci-après, nous avons représenté les activités ou actions que mènent le système d'information et les collaborateurs d'arcpizzas pour réaliser le service attendu par le client, en l'occurrence, la fabrication et la livraison de la commande de pizzas. Dans un souci de simplification, nous n'avons pas montré le cas où le client prend possession de sa ou ses pizzas au guichet. 9/44 P-A. Sunier
Dans le diagramme ci-dessus (modèle d'activités), nous voyons l'activité métier du pizzaiolo Confectionner une pizza. Cette activité est essentielle, elle est au cœur du métier de l'entreprise ou de son sous-système opérant. Toutefois, ce que nous ne savons ou ne voyons pas par ce diagramme, c'est comment le pizzaiolo est informé de l'arrivée d'une commande passée par le client. 10/44 P-A. Sunier
Pour éclaircir ce point et d'autres, nous allons réaliser un deuxième diagramme d'activités qui nous conduira à faire une réflexion d'organisation; nous définirons les modalités d'information du pizzaiolo de l'arrivée d'une nouvelle commande. Ce deuxième diagramme, nous le nommerons Commander Pizza Organisation pour bien marquer notre intention de fixer les règles d'organisation que supportera le système d'information. Dans ce deuxième diagramme d'activités, représentation partielle du cas d'utilisation métier Commander pizza, nous avons fixé une règle d'organisation relative à l'information au pizzaiolo de l'arrivée d'une nouvelle commande; le système d'information, fournira, sous des modalités qu'il reste à déterminer, un ticket pour chaque nouvelle commande de pizza. Dès lors, sur la base du ticket de fabrication et des ingrédients, le pizzaiolo confectionnera sa pizza et, lorsqu'il aura terminé, il délivrera, selon des modalités à définir, la ou les pizzas et le ticket de fabrication qui a déclenché la confection. 11/44 P-A. Sunier
4 Modèle des cas d'utilisation du système d'information La description du métier étant réalisée, il nous faut maintenant décrire plus précisément les services attendus du système d'information et dont les bénéficiaires seront les collaborateurs de l'entreprise mais aussi les clients au travers du site Internet de commande des pizzas. Le modèle des cas d'utilisation du système d'information a comme objectif de préciser les besoins de ses utilisateurs; ce que l'on nomme les exigences vis-à-vis du système d'information. Pour la description du système opérant de l'entreprise, la communauté informatique parle relativement uniformément de cas d'utilisation métier. Pour la description du système d'information, nous trouverons selon les auteurs ou écoles les termes de: cas d'utilisation; cas d'utilisation système; cas d'utilisation système d'information. Sans que cela puisse être érigé en tant que règle: les responsabilités des diagrammes d'activité métier deviennent des acteurs; les activités de traitement de l'information ou comportant un traitement de l'information deviennent des cas d'utilisation. Selon les règles empiriques énoncées ci-dessus et en nous basant sur le diagramme d'activité métier Commander Pizza Organisation, nous avons réalisé le diagramme de cas d'utilisation ci-dessous. 12/44 P-A. Sunier
Nous voyons pour chaque acteur ou rôle (Client, Caissier ) les services que doit offrir le système d'information. Il est à noter que le système d'information est lui-même acteur/déclencheur du cas d'utilisation Dispatcher commande qui devra produire les tickets de fabrication lors de la réception d'une commande qu'elle soit passée par Internet, par téléphone ou donnée sur place directement au guichet. Ce diagramme est placé dans le modèle ExigencesSI du référentiel. [Voir chapitre 2.2.2 Modèles] 4.1 Description des cas d'utilisation du système d'information Nous pourrions décrire nos cas d'utilisation système d'information à l'aide de diagrammes d'activité; toutefois, dans le cas particulier, UML nous propose une troisième sorte de diagramme, le diagramme de séquence, particulièrement approprié pour décrire les interactions entre un acteur, un utilisateur du système 4, et le service offert par ledit système au travers un cas d'utilisation. Nous limiterons notre description des cas d'utilisation système au seul Commander par Internet. Le diagramme de séquence cicontre décrit l'interaction entre le client et le système d'information pour que ledit client puisse passer une commande. Nous voyons les messages échangés entre le client et le système: le premier est le fait du client qui demande la page web de commande de pizzas; le deuxième est la page de commande fournie par le système en réponse à la sollicitation initiale du client; le troisième est la saisie d'une sorte de pizzas avec indication de la quantité et ceci pouvant être répété pour d'autres sortes de pizzas;. 4 UML et UP utilisent le terme de système pour parler de système d'information qui serait plus juste sémantiquement mais plus contraignant en termes d'écriture et de nommage 13/44 P-A. Sunier
Comme précédemment, ce diagramme est créé comme partie ou enfant de l élément qu il décrit, à savoir le cas d'utilisation système Commander par Internet. 14/44 P-A. Sunier
5 Modèle d'analyse La réalisation du modèle d'analyse est essentiellement une démarche tendant à fixer les choix architecturaux essentiels du futur logiciel. Le modèle d'analyse va faire la transition entre les besoins vis-à-vis du système d'information et la réalisation de logiciels de gestion qui devront satisfaire ces besoins; naturellement, en situation réelle d'entreprise, il faudra au préalable nous assurer que le gain espéré de cette informatisation justifie le coût de réalisation du logiciel. Avant de faire cette transition, il nous faut expliciter quelque peu le système d'information et plus particulièrement sa partie informatisée (SII 5 ) que nous avons considéré comme une boîte noire que des acteurs sollicitent pour obtenir des services [Chapitre 2.3 Qu est-ce que le système?]. De manière très schématique, le système d'information informatisé ou tout logiciel de gestion est constitué de 2 parties: la partie dynamique (traitements) qui acquiert, diffuse, traite (calcule) et assure le lien avec la mémorisation des données; la partie statique (données) qui comporte les conteneurs de données et les données elles-mêmes. La méthode UP nous propose trois éléments de modélisation qui vont nous permettre de faire le lien entre les concepts évoqués ci-dessus et la réalisation du futur système d'information informatisé. Ces trois éléments de modélisation sont: Interfaces, des formulaires ou des matériels physiques qui permettent l interaction entre les acteurs et le système d information informatisé. Les interfaces font partie de l'aspect dynamique du SII et assurent la communication avec l'extérieur. 5 SII ou Système d'information informatisé: la partie du système d'information qui sera automatisée à l'aide d'un ou plusieurs logiciels de gestion pour faire simple. 15/44 P-A. Sunier
Contrôleurs, des briques logicielles qui garantissent le respect des règles de fonctionnement interne des traitements informatisés. Les contrôleurs sont les calculs (compute) effectués au sein de la partie dynamique du SII Entités métier, des entités de données qui assurent la persistance 6 des données utiles au système d information informatisé. Les entités métier représentent l'aspect statique du SII A notre sens, deux diagrammes ou sous-modèles sont essentiels pour produire correctement le modèle d'analyse; ce sont le modèle ou diagramme de communication pour l'aspect dynamique du SII et le modèle conceptuel de données ou modèle du domaine pour l'aspect statique du SII. 5.1 Diagramme de communication plus, ils structurent le référentiel. La mise en place de diagrammes de communication pour fixer les choix architecturaux de réalisation de cas d'utilisation système se fait en utilisant des objets de modélisation Réalisation de cas d'utilisation. Ces Réalisation de cas d'utilisation servent à faire le lien entre les descriptions des cas d'utilisation et leur transcription sous forme d'éléments informatiques du futur système; de Nous nommerons notre Réalisation de cas d'utilisation et notre diagramme Commander par Internet puisque c'est le cas d'utilisation système Commander par Internet que nous allons spécifier sous forme d'éléments informatiques: des interfaces, des contrôleurs et des entités de données. En plus des éléments informatiques constitutifs du futur système, nous montrons dans notre diagramme les acteurs qui utilisent le système ou reçoivent des messages de celui-ci et les messages échangés entre éléments informatiques et aussi entre acteurs et interfaces; naturellement, les acteurs n'interagissent avec le système qu'au travers des interfaces. Le diagramme de communication privilégie l'aspect spatial et organisationnel des différents éléments informatiques. Cette vision spatiale est intéressante pour "voir" le poids ou l'importance de chacun des éléments informatiques. 6 Le stockage en vue d'une restitution en tout temps indépendamment des aléas de vie des différents processus de traitements (contrôleurs et interfaces). 16/44 P-A. Sunier
Par contre, la vision chronologique des interactions n'est pas aisée car il faut lire et interpréter les numéros des messages. Pour mettre en évidence cette dimension chronologique, la plupart des outils de modélisation UML dont Visual Paradigm permettent de transformer un modèle de communication en modèle de séquence et vice-versa. 17/44 P-A. Sunier
5.2 Modèle conceptuel de données Le modèle conceptuel de données va nous permettre de définir les entités de données nécessaires à satisfaire les besoins exprimés et les associations entre ces entités. Le modèle conceptuel de données est indépendant de tout choix technologique de réalisation qui, nous le verrons plus tard, peut être, par exemple, une base de données relationnelles, une base de données objet, une base de données XML ou encore de simples fichiers. Le modèle conceptuel de données peut être réalisé déjà à partir des entités métiers du diagramme de communication dans un diagramme ou modèle proposé par UP sous le nom de Modèle du domaine. De notre côté pour bien dissocier les problèmes de lecture et écriture de données par la partie dynamique, traitements, du SII de ceux de la persistance desdites données par la partie statique du SII, nous réservons les entités métiers et le modèle du domaine pour la partie traitements et le modèle conceptuel de données pour la partie statique. Selon la plate-forme d'exécution du logiciel, cette séparation entre modèle du domaine, pour les traitements, et modèle conceptuel de données ne se justifie pas et alors seul le modèle conceptuel de données est utilisé. En plus des entités, marquées du stéréotype 7 «MCD 8» et des associations entre entités, nous trouvons dans notre modèle les multiplicités ou cardinalités qui qualifient les rôles de chaque entité participant à une association. 7 Un stéréotype est un classificateur qui permet à tout utilisateur d'uml de spécialiser ou classifier les objets du référentiel. 18/44 P-A. Sunier
Le concept de cardinalité est illustré par la représentation sagittale ci-dessous. Ce diagramme sagittal a été réalisé à partir des deux règles ci-dessous: 1. Une pizza peut être définie par un genre mais pas obligatoirement. 2. Plusieurs pizzas peuvent être du même genre de pizzas; un genre de pizza peut être créé sans qu'aucune pizza de ce genre n'existe. Ci-contre, le fragment de MCD relatif aux pizzas et genre de pizza; les règles énoncées précédemment sont indiquées par valeurs minimale et valeur maximale des cardinalités en regard des entités opposées. 0..1 côté GenrePizza, signifie: o 0, cardinalité minimale - une pizza peut exister sans être définie par un genre; o 1, cardinalité maximale une pizza ne peut être que d'un seul genre. 0..* côté Pizza, signifie: o 0, cardinalité minimale un genre de pizza peut exister sans être référencé par une pizza; o *, cardinalité maximale un genre de pizza peut être référé par plusieurs pizzas (le symbole * peut être remplacé par la lettre n). Les attributs des entités, comme Prix de Pizza, permettent de décrire les occurrences d entités ; un attribut est une donnée élémentaire caractérisée par un type ou un domaine, positivemoney pour l attribut Prix. Le stéréotype «UID-1» dans les 2 entités signifie que l'attribut qui en est porteur, Nom, est l'identifiant naturel à partir duquel tout utilisateur du futur système va accéder aux données (pizzas ou genre de pizzas). 8 Nous utilisons le stéréotype «MCD» pour qualifier les classes d'entités du modèle conceptuel de données. 19/44 P-A. Sunier
6 Maquettes de validation Après avoir fait notre modèle d'analyse, il nous faudra valider notre perception du logiciel à réaliser; pour ce faire nous réaliserons des maquettes qui nous servirons à présenter aux futurs utilisateurs et organisateurs notre proposition de réponse à leurs besoins. Ces maquettes serviront aussi d'éléments de spécification pour le travail de conception et d'implémentation du logiciel à réaliser. 6.1 Validation du diagramme de communication Notre diagramme de communication Commander par Internet comporte une interface Page Web de commande; cette page sera créée par le contrôleur Site Web ArcPizzas qui accédera à l'entité métier Pizza pour créer la liste des pizzas offertes [Voir le diagramme de séquence du chapitre 5.1]. Nous allons maintenant nous appuyer sur notre diagramme de séquence Commander par Internet de description du cas d'utilisation système Commander par Internet [Voir chapitre 4.1 Description des cas d'utilisation du système d'information] pour élaborer la maquette de représentation de l'interface Page Web de commande. Nous pouvons voir dans notre maquette ci-contre la réalisation de la boucle, loop, de choix de pizzas à l'aide du bouton de commande +. 20/44 P-A. Sunier
6.2 Validation des besoins implicites découlant du MCD Lorsque l'on réalise le MCD d'un système ou d'un logiciel, il arrive que l'on ajoute des entités et/ou des associations qui n'apparaissent pas explicitement dans l'expression des besoins. Les raisons peuvent en être multiples mais très souvent, il s'agit de créer des entités qui serviront de références, comme le genre de pizzas; ces entités permettront de normaliser 9 les données et/ou amener de la souplesse dans la structure 10. Pour notre cas pratique, nous avons choisi, d'introduire cette notion de genre de pizzas qui n'est pas demandée et qui pourrait avoir un intérêt pour le client. Dans notre démarche pédagogique, cette entité GenrePizza nous permettra de créer un premier formulaire de saisie de données relativement simple 11 et en tous les cas plus simple que celui qui consisterait à la saisie des commandes par Internet [Maquette réalisé au chapitre 6.1]. La maquette ci-dessous montre simplement ce que devrait être la réalisation de l'écran qui permettra de faire la saisie de données relative aux entités Pizza et GenrePizza présentées et discutées en chapitre 5.2. Nous voyons que chaque pizza est définie par un nom, un descriptif et un prix qui sont les attributs de l'entité Pizza. L'attribut Nom de l'entité GenrePizza apparait, sous forme de liste déroulante, pour établir le lien entre la pizza et son genre. 9 La normalisation consiste à s'assurer de l'absence de redondance au sein d'une base de données relationnelles et ainsi de pouvoir faire des requêtes exemptes de résultats ambigus ou parasites (du bruit). 10 La souplesse dans la structure permettra au système ou au logiciel d'évoluer dans les limites de ladite souplesse. 11 Une structure table de base et table de référence avec Pizzas comme table de base et GenrePizzas comme table de référence. 21/44 P-A. Sunier
7 Conception L'analyse étant réalisée, nous pouvons aller plus en détail dans l'élaboration des spécifications. A ce stade, il nous faut tenir compte du modèle de la plate-forme d'exécution ou de l'implémentation proprement dite; nous voulons dire par là, qu'au niveau données, par exemple, nous pourrions avoir une structure de données relationnelle, sans tenir compte d'une solution commerciale particulière, ou une base de données relationnelle Oracle qui est une implémentation du modèle relationnel mais comportant des spécificités propres à Oracle. Pour passer de l'analyse à la conception, la démarche est drastiquement différente entre la partie des traitements (dynamique du système) et la partie des données (statique du système). Pour la partie statique, le passage d'un modèle conceptuel, très abstrait, à un modèle logique relatif à une technologie et donc plus proche de la concrétisation est très souvent automatisable. C'est particulièrement le cas, pour la transformation d'un MCD en un modèle relationnel. Pour la partie dynamique, la transformation des interfaces et des contrôleurs du modèle d'analyse en éléments de conception relève d'une démarche intellectuelle malheureusement encore très peu formalisée. 7.1 Partie statique les données 7.1.1 Transformation MCD MLD Conformément au choix initial [Voir chapitre 1] de nous appuyer sur le modèle relationnel pour la structure de la base de données et plus particulièrement sur le SGBD 12 Oracle, nous allons appliquer les règles reconnues de transformation d'un modèle conceptuel de données en un modèle logique relationnel. Les règles essentielles de transformation d'un MCD en un MLD relationnel sont: 1. Les entités deviennent des tables; une contrainte de clé primaire est créée pour chaque table. 2. Les associations de degré 1:1 ou 1:n deviennent des contraintes de clés étrangères. 3. Les associations de degrés n:n deviennent des tables associatives. Pour appliquer ces règles, nul besoin de mobiliser les ressources de collaborateurs qualifiés, un automate peut faire le travail. Visual Paradigm effectue cette transformation; toutefois la 3 ème règle n'est pas rigoureusement appliquée; comme notre école met un poids important sur la qualité des données, de leur structure et de leur modélisation, nous ne pouvions nous satisfaire de la solution proposée. Nous avons développé un plugin 13 pour VisualParadigm qui effectue cette transformation en respectant scrupuleusement les modalités des trois règles en plus d'autres qui nous sont propres. 12 SGBD: Système de gestion de base de données 13 Le plugin porte le nom de MVC-CD. 22/44 P-A. Sunier
Préalablement à l'exécution du plugin, nous mettons à profit le concept de valeur marquée 14 d'uml, onglet Tagged Values ci-dessous, pour définir le nom de la table qui sera issue de la transformation de l'entité (règle N 1 ) et un nom court de table qui sera utilisé pour le nommage des contraintes de tables et plus particulièrement les contraintes de clé primaire et de étrangère (règles N 1 & 2). 14 Un couple marqueur et valeur comme en XML <nom>sunier</nom> où dans l'exemple ci-contre, nom est le marqueur et Sunier la valeur. 23/44 P-A. Sunier
En plus des valeurs marquées, il nous faut définir la base de données cible. Après exécution du plugin de transformation, nous obtenons le MLD relationnel suivant: Nous pouvons observer la table GenrePizzas au pluriel (valeur marquée tablename) issue de la transformation de l'entité GenrePizza au singulier. Dans la table Pizzas, nous pouvons observer : - La colonne de clé primaire Numero. - La colonne de clé étrangère référant à la table GenrePizzas et préfixée GPizz (valeur marquée shortname). 24/44 P-A. Sunier
7.1.2 Le MLD relationnel Le modèle logique de données (MLD) relationnel (MLD-R) a de nombreux points de ressemblance avec le modèle conceptuel (MCD); la représentation sous forme de diagramme pourrait se faire avec la notation UML toutefois, Visual Paradigm a choisi une autre voie. Visual Paradigm a choisi une notation s'inspirant des travaux anglo-saxons 15 relatifs à la modélisation conceptuelle des données; les traits les plus notoires de cette notation propre à Visual Paradigm sont: Les liens entre tables dessinés en traits pleins pour les liens identifiants et en traits tillés pour les liens non identifiants. Les symboles graphiques {o, } pour les cardinalités minimales et {-, < } pour les cardinalités maximales. Les symboles graphiques de représentation des colonnes de clés primaires et de clés étrangères. 7.1.3 Enrichissement du MLD Le MLD étant créé, nous pouvons maintenant affiner les spécifications et mettre en place des détails qui n'auraient pas eu de sens en analyse et au sein du MCD. Le principe est le même que lorsque nous nous déplaçons; pour aller dans une ville, il nous faut une carte de géographie afin de la situer mais, lorsque nous sommes aux portes de la ville, il nous faut un plan de ville qui détaille les rues et quartiers; ces détails n'auraient pas de sens au niveau de la carte géographique. Au niveau cartographique ou en utilisant un système de navigation incluant une base de données cartographique, ce niveau de détail ou de synthèse s'appelle l'échelle; au niveau de la modélisation des systèmes d'information, nous parlons de niveau d'abstraction. Pour cette initiation à la modélisation, nous n'allons pas apporter de nombreux enrichissements au niveau de notre modèle logique; nous nous contenterons de mettre en place un mécanisme de calcul automatique des valeurs de clés primaires pour les tables qui en ont besoin. Afin de pouvoir nous concentrer sur la démarche et ne pas avoir trop de travaux d'enrichissement à effectuer, nous nous limiterons pour la suite aux seules tables Pizzas et GenrePizzas. 15 Bachman, Chen et autres au milieu des années 1970. 25/44 P-A. Sunier
GenrePizzas «PK» Numero «UID» Nom Tuple 1 1 Végétarienne Tuple 2 2 Viande Tuple 3 3 Poisson Tuple 4 4 Mélange Tuple 5 10 Dessert Les clés sont un mécanisme essentiel du modèle de données relationnel; elles servent à mettre en place le concept relationnel qui consiste à voir les données sous une forme matricielle, à l'image d'un tableur; en colonne de la relation nous trouvons, justement, les colonnes de la table et en ligne les tuples représentants les occurrences d'objets enregistrés dans la table ou relation 16. Les clés primaires «PK» garantissent l'identification technique de chacun des tuples. Dans la table GenrePizzas, la valeur 10 de la clé primaire Numero permet d'atteindre sans ambigüité le tuple 5. Les identifiants naturels «UID» garantissent eux aussi l'identification de chacun des tuples mais, à partir de données naturelles, c'est-à-dire significatives pour l'utilisateur. Pizzas «PK» Numero «FK» GPizz_Numero «UID» Nom Description Prix Tuple 1 1 2 Parma Jambon de Parme 22 Tuple 2 4 2 Indienne Poulet au curry 19 Tuple 3 5 1 Ratatouille Poivrons, aubergines 17 Les clés primaires sont indispensables pour établir des liens fiables entre tables ou relations des bases de données relationnelles, les clés primaires se retrouvent comme clés étrangères dans les tables sources des liens. Dans la table Pizzas, la valeur 2 de la clé étrangère GPizz_Numero permet d'atteindre sans ambiguité le tuple de référence de GenrePizzas; la pizza "Indienne" est de genre "Viande". Remarques: Les liens entre tables se font avec les clés primaires «PK» et non avec les identifiants naturels «UID» car ceux-ci peuvent changer de valeur au cours de leur vie ce qui obligerait à modifier tous les tuples des tables qui font référence à cette valeur. A l'opposé des identifiants naturels, les clés primaires ne changent jamais de valeur pour justement garantir la stabilité des liens entre tables. Les prémices des clés étantt posées, nous pouvons maintenant mettre en place le calcul automatique ou auto incrémentation des clés primaires pour nos deux tables Pizzas et GenrePizzas. 16 Au sens originel du modèle relationnel et des travaux de Codd, nous devrions parler de relation et non de table comme nous le faisons usuellement. 26/44 P-A. Sunier
L'auto-incrémentation des clés primaires n'est pas gérée uniformément par les différents constructeurs de SGBD-R 17. La manière que nous décrivons s'applique aux bases de données Oracle; dès lors notre MLD va perdre de sa portabilité et devenir orienté Oracle ou similaire. Lors de la transformation [Chapitre 7.1.1], le plugin MVC-CD crée deux objets Sequence; les séquences, sous Oracle, sont des objets autonomes indépendants de toute transaction. De ce fait, quels que soit le nombre de connexions concurrentes, toute interrogation de la séquence va rendre une valeur unique indépendamment de toute transaction aboutie ou non; jamais deux utilisateurs n'obtiendrons une même valeur. Ci-dessus, nous voyons les séquences associées à chacune des deux tables. 17 SGBD-R: Système de gestion de base de données relationnelle 27/44 P-A. Sunier
7.2 Partie dynamique les traitements 7.2.1 Préambule Conformément au modèle architectural et à la plate-forme d'exécution retenus [Voir chapitre 1-Propos liminaire], nous pouvons maintenant réaliser la conception de la partie dynamique du logiciel soit les interfaces et contrôleurs que nous avons spécifiés en analyse et validés par le travail de maquettage. Avec de nombreux modèles de développement, il est nécessaire de réaliser la conception des données avant de pouvoir concevoir les traitements (contrôleurs et interfaces); l'on parle, alors, de modèle de développement "dirigé par les données". C'est le cas de notre choix du modèle client-serveur (de données); mais, de plus, avec MS-ACCES comme client pour les traitements, il nous faut en plus créer (implémenter) les tables au sein de notre SGBD-R Oracle pour pouvoir concevoir 18 nos traitements. Le lecteur voudra donc bien lire le chapitre d'implémentation des données [8.1], voire le chapitre de test [9.1] avant de poursuivre ce chapitre. Cette lecture vous permettra de faire le lien avec les tables du SGBD-R qui sont traitées ci-après. 7.2.2 Modèle client-serveur Le modèle client-serveur consiste en un serveur de données accessible via un réseau interne et un ou des terminaux intelligents qui vont héberger l'application. Ces terminaux passeront par le réseau pour soumettre des requêtes de lectures et écritures de données au serveur. L'intelligence des terminaux ou la capacité informatique des terminaux doit réaliser les éléments informatiques (interfaces et contrôleurs) que nous avons identifiés lors de l'analyse. Cette nécessité de capacité informatique des terminaux du modèle client-serveur nous amène à parler de clients lourds par opposition au modèle multitiers, en vogue, où le terminal ne fait que de présenter les écrans aux utilisateurs et les traitements de création de formulaire et de contrôle sont effectué par un serveur dit 18 Il serait possible de contourner cette contrainte en créant au sein de MS-ACCESS notre modèle logique de données; toutefois cette démarche serait excessivement fastidieuse pour ce cours d'introduction. 28/44 P-A. Sunier
d'applications; les clients du modèle multi-tiers sont dits clients légers. Naturellement, un mixte entre les deux est possible essentiellement, pour diminuer le trafic entre client et serveur d'applications. 7.2.3 Couplage MS-Access & Oracle Notre plate-forme prédéfinie MS-Access & Oracle est de type client/serveur avec MS- ACCESS comme client lourd et Oracle comme SGBD-R tel qu illustré ci-dessous. La communication entre ces deux nœuds d'exécution 19 de constructeurs différents s'appuie sur une interface de communication de bas niveau (cachée à l'utilisateur). Cette interface nommée ODBC permet la connexion entre clients et SGBD-R sans que l'une des deux parties ne doive tenir compte des spécificités de l'autre. La communication entre les deux nœuds d'exécution s'établit depuis MS-Access, d'où la notion de client. Nous allons indiquer, dans une fenêtre de paramétrage de MS-Access, qu'il doit utiliser notre SGBD-R Oracle comme source de données. 19 UML introduit la notion de nœud d'exécution pour parler de matériels chargés de l'exécution de processus informatiques. 29/44 P-A. Sunier
SI SII La connexion que nous venons d'établir matérialise le double flux de données de notre représentation symbolique du SII de l'entreprise [Chapitre 5-Modèle d'analyse]. Traitements Données MS-Access et d'autres constructeurs parlent pour cette définition de "tables attachées" comme illustré par la copie d'écran ci-après. Naturellement, le SGBD-R doit assurer la sécurité des données et pouvoir exécuter le processus d'attache de tables, une authentification vous est demandée. Après que nous nous soyons identifié et grâce au pilote ODBC, nous voyons les tables de notre SGBD-R Oracle et pouvons sélectionner les tables que nous souhaitons utiliser au sein de notre application MS- Access. Remarque: En plus des tables de notre schéma/compte, nous voyons les tables d'autres schémas. Nous voyons ces tables d'autres schémas car leurs prioritaires ont donné des droits de lecture à tout utilisateur connecté au SGBD. 30/44 P-A. Sunier
7.2.4 Travaux préparatoires Maintenant que nos tables sont liées, nous pouvons utiliser les services standards de MS- ACCES pour lire et/ou manipuler nos données sachant quelles ont étés créées [Chapitre 8.1] et peuplées [9.1]. S'agissant de la manipulation de la table GenrePizzas, voir ci-contre, nous n'avons rien de particulier à signaler. S'agissant de la manipulation de la table Pizzas, voir cicontre, nous sommes dans la même situation que celle qui prévalait lorsqu'il s'était agi de la peupler en chapitre 9.1. Nous devons connaître la valeur de clé primaire, non significative pour l'utilisateur, pour référencer le genre de pizza. Pour solutionner ce problème de référencement d'enregistrement d'une autre table, MS-ACCES offre un mécanisme de définition, au niveau des tables, très intéressant. La structure de la table est définie au niveau du SGBD-R et celle-ci ne saurait être modifiée par le client MS- Access; toutefois, MS-Access permet d'enrichir cette définition de spécifications qui n'auront de portée que pour les éléments qui lui sont propres, à savoir: les interfaces et les contrôleurs. Ci-contre, nous voyons la manière dont MS-Access nous permet de faire le lien (mapping) entre la clé étrangère Gpizz_Numero de la table Pizzas et l'identifiant naturel (UID) de la table de référence GenrePizzas. 31/44 P-A. Sunier
De manière très simplifiée, les éléments de définition du lien sont: associer une liste à choix, déroulante ou autre, à la colonne de clé étrangère; créer une requête qui va retourner la colonne de clé primaire, Numero, et la colonne d'identifiant naturel, Nom, de la table de référence; associer la colonne Numero (position 1) de la requête à la colonne de clé étrangère Gpizz_Numero; indiquer de ne pas afficher (Largeur colonne = 0) la clé primaire de la table de référence car elle n'a pas de signification pour un utilisateur. l'identifiant naturel de la table de référence. Après avoir fait ce lien, nous pouvons manipuler les données de notre table, comme si nous étions un utilisateur final, c'est-à-dire en nous appuyant sur La technologie et plus particulièrement, le couple clé étrangère de la table source et clé primaire de la table de référence ou cible, peuvent être occultés dès à présent. 7.2.5 Conception des interfaces utilisateurs Comme indiqué en préambule, les tables étant créées au sein du SGBD-R Oracle [Chapitre 8.1], nous pouvons nous appuyer sur la capacité de MS-Access à créer automatiquement des interfaces utilisateurs ou formulaires. Les automates ou assistants de MS-Access vont s'appuyer sur la structure de nos tables liées pour nous proposer des choix de conception des formulaires comme l'illustre la copie d'écran ci-contre. Nous ajusterons les paramètres de conception de l'assistant en fonction des choix que nous avons faits pour notre maquette [Chapitre 6.2-Validation des besoins implicites découlant du MCD] et qu'en situation réelle nous aurions validés auprès de notre donneur d'ordre. Par ce mécanisme d'assistant de création de formulaires, l'activité de conception devient du simple paramétrage. 32/44 P-A. Sunier
Après validation de nos choix de paramétrage, l'assistant MS-Access réalise, sous un formalisme graphique qui lui est propre, le modèle conceptuel de notre formulaire de gestion du catalogue des pizzas. La conception d'interfaces est possible avec les assistants de MS-Access seulement si les contraintes de réalisation sont supportées par lesdits assistants. Lorsque la structure de données se complique, lorsque l'interface utilisateur est spécifique ou encore lorsque les règle de gestion impactent la logique de saisie de données, il faut réaliser les modèles graphiques de conception "à la main". Il est aussi possible de s'appuyer sur les assistants pour produire un modèle graphique initial et ensuite l'enrichir "à la main". 7.2.6 Conception des contrôleurs Les contrôleurs ne nous semblent pas exister en tant qu'objets de conception avec MS-Access. Pour rappel, les contrôleurs se chargent d'appliquer les règles définissant et accompagnant les processus de l'entreprise. Avec MS-Access du code que l'on rajoute aux formulaires respectivement, le développement de modules en langage Visual Basic permettent de réaliser des contrôleurs au niveau de l'implémentation. Toutefois, dans notre souci de nous focaliser sur l essentiel, nous n aborderons pas la problématique de l'implémentation des contrôleurs. 33/44 P-A. Sunier
8 Implémentation La conception étant terminée, nous pouvons traduire nos modèles de conception en code d'implémentation. Nous commençons impérativement par les données vu la préséance de celles-ci dans un développement selon le modèle client-serveur. 8.1 Partie statique les données Au niveau des données, la transformation du modèle logique de données 20 en modèle implémentable dans une base de données relationnelle est automatisable. Dans la perspective de SGBD-R, le modèle d'implémentation est constitué de scripts SQL 21 ; ces scripts obéissent à une norme 22 et sont relativement semblables d'un SGBD-R à un autre. Visual Paradigm est capable de générer ces scripts pour de nombreux SGBD-R. Toutefois, le langage SQL à la norme SQL-92 est relativement pauvre et les règles d'intégrité des données tant soit peu sophistiquées, par exemple l'auto-incrémentation de notre clé primaire pour Oracle, ne peuvent pas être prises en charge. Pour combler ce manque quelques éditeurs de logiciels proposent des APIs 23 (de tables) qui se chargent d'assurer la mise en place de règles d'intégrité des données complémentaires au code SQL. Les APIs de tables ne sont réalisables qu'au sein de SGBD-R qui disposent d'un langage de programmation 24 ; naturellement, les APIs de tables étant écrites pour un langage spécifique à un SGBD-R, elles ne sont à priori pas portables hormis au sein de SGBD-R qui partageraient un même langage interne de programmation. Visual Paradigm ne propose pas d'automate pour créer ces APIs de tables; comme les APIs de tables nous semblent une brique logicielle essentielle, nous avons créé un deuxième Plugin pour Visual Paradigm qui effectue cette tâche. 20 Modèle de conception de la partie statique du SI à automatiser 21 SQL: Structured Query Language, langage structuré pour la création, la manipulation et le contrôle de SGBD- R 22 Couramment, la norme ANI SQL-92 appelée aussi SQL2. 23 API: Application Programming Interface, une bibliothèque logicielle offrant un service. 24 Très couramment l'on parle de procédures stockées à l'image des données que l'on stocke dans une base de données. 34/44 P-A. Sunier
Nous allons donc générer deux familles de scripts pour réaliser les modèles d'implémentation: les scripts SQL-DDL; scripts SQL de définition de tables, séquences et autres; les scripts d'apis de tables. Les scripts doivent être exécutés au sein de la base de données cible dans l'ordre cidessus car les APIs de tables doivent pouvoir s'appuyer sur des tables préalablement créées pour être compilées 25. base de données cible. Pour pouvoir exécuter les deux familles de scripts, le développeur doit depuis son poste de travail se connecter à la La connexion se fait depuis Visual Paradigm en indiquant la base de données cible et les paramètres de compte respectivement d'identification. 25 La compilation consiste très succinctement à convertir du code compréhensible par l'humain en code exécutable par un ordinateur. 35/44 P-A. Sunier
Ci-contre, nous reproduisons une vue du script SQL de création des tables, séquences et autres contraintes pour les tables Pizzas et GenrePizzas. 36/44 P-A. Sunier
8.2 Partie dynamique les traitements 8.2.1 Introduction L'activité d'implémentation est particulière avec MS-Access. Très schématiquement, tous nos objets de conception 26, sont stockés dans un fichier et MS-Access est capable de passer de la conception (Mode Création selon MS-Access) à l'exécution (Mode Formulaire selon MS- Access) sans devoir passer par une implémentation au sens strict. Cette possibilité de passer du mode conception directement à l'exécution et vice-versa est un mécanisme qui permet aux développeurs de mettre en œuvre élégamment les nécessités d'agilité (rapidité des changements) et d'implication des utilisateurs (adéquation aux besoins). Ci-dessus notre formulaire de gestion du catalogue des pizzas en mode conception; après passage en mode exécution, nous disposons directement, ci-dessous, de notre formulaire pour effectuer des tests. 26 Interfaces et contrôleurs 37/44 P-A. Sunier
8.3 Phase de développement et de test En phase de test de notre de logiciel de gestion pour ArcPizzas, nous nous appuierons sur l'opportunité offerte par MS-Access de changement de mode conception à exécution pour effectuer les tests unitaires directement au sein de l'environnement de conception; les tests unitaires sont les tests que font les développeurs sur chaque élément informatique produit. [Voir le chapitre 9.2Partie dynamique les traitements]. Pour les tests d'intégration 27 et les tests de recette 28, il peut être risqué de fournir un fichier au sein duquel la conception est visible et modifiable [Voir le chapitre précédent]. Afin de réduire le risque évoqué, il est possible de créer une copie du fichier MS-Access au sein duquel les actions de conception sont inaccessibles. La production d'un tel fichier s'apparente à une activité d'implémentation; effectivement, à la fin de notre processus de copie de fichier, nous obtenons un fichier contenant des éléments informatiques exécutables et seulement exécutables. 8.4 Phase d'exploitation En phase d'exploitation, nous fournirons à ArcPizza, l'implémentation de nos traitements, interfaces et contrôleurs, sous forme d'un fichier d'éléments informatiques exécutables et seulement exécutables [Voir le chapitre précédent]. 27 Il s'agit de tester les éléments informatiques dans leur contexte global et non plus isolément comme les tests unitaires. 28 Il s'agit de l'évaluation du logiciel par les utilisateurs finaux. 38/44 P-A. Sunier
9 Tests L'implémentation étant réalisée, nous pouvons tester notre application. Nous commençons impérativement par les données vu la préséance de celles-ci dans un développement selon le modèle client-serveur. 9.1 Partie statique les données Le principe du travail de test des données est illustré par le schéma ci-dessus. Pour tester les données au sein de notre SGBD-R Oracle, nous allons utiliser un logiciel qui fait office de client générique, en attendant notre application MS-Access, du modèle client-serveur; en l'occurrence, nous utiliserons SQL Developper d'oracle. SQL-Developer nous permettra de tester nos données mais aussi d'observer les objets qui ont été créés au sein de notre schéma. Dans l'image ci-contre, nous pouvons voir nos tables et séquences résultant de l'exécution des scripts SQL-DDL [Chapitre 8.1]. 39/44 P-A. Sunier
En plus des tables et séquences, nous pouvons observer les paquetages, ensemble de procédures stockées, qui ont été créés par les scripts d'apis de tables. Les APIS de tables devront être exécutées automatiquement lors de toute modification de données; toute modification de données est susceptible de violer une contrainte d'intégrité. Les ordres d'exécution des APIs sont pris en charge par des déclencheurs créés par les scripts d'apis de tables en même temps que les paquetages. Maintenant que nous nous sommes assurés de la réalisation correcte de la structure de notre base de données, nous pouvons saisir des données de test dans les deux tables Pizzas et GenrePizzas. Nous commençons par saisir des données dans la table de référence GenrePizzas. 40/44 P-A. Sunier
Maintenant que nous avons des données dans la table de référence GenrePizzas, nous pouvons saisir des données dans la table Pizzas et référer les tuples de la table de référence. Le simple fait d'ajouter des enregistrements nous a permis de tester le bon fonctionnement de nos APIs de tables et l'auto-incrémentation des clés primaires. Le but des tests est de vérifier l'entier des contraintes d'intégrité des données et ceci en toutes situations: ajout, modification ou suppression de données. A titre d'illustration, nous reproduisons ci-dessous, la situation et le message d'erreur du SGBD-R relatif à la saisie dans la table Pizzas d'une référence à GenrePizzas qui n'existe pas (GPizz_Numero = 46). Remarque: En situation réelle, nous ne saisissons pas les données de tests mais, nous passons par des scripts de tests qui peuvent être exécutés à chaque changement de structure. 41/44 P-A. Sunier