Informatique de Gestion

Bases de modélisation du système
d’information de l’entreprise
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 d’information de l’entreprise? ............................................ 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.2.1 Introduction ........................................................................................................ 37
8.3 Phase de développement et de test ............................................................................ 38
Bases de modélisation du système 2/44 P-A. Sunier

8.4 Phase d'exploitation ................................................................................................... 38
9 Tests ................................................................................................................................. 39
9.3 Finalisation des transactions ...................................................................................... 42
10 Liens Internet.................................................................................................................... 43
11 Bibliographie .................................................................................................................... 44

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 UML1 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 client-
serveur, 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.

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.

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.

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 ci-

contre, 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.

2.3 Qu’est-ce que le système d’information de l’entreprise?
Le système d’information de l’entreprise, 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.

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.

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.

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.

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.

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 ci-

contre 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

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.

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 d’information de l’entreprise?].
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.

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
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
plus, ils structurent le référentiel.
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).

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.

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.

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.

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 +.

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.

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.

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.

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).

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.

GenrePizzas Les clés sont un mécanisme essentiel du
modèle de données relationnel; elles servent
«PK» Numero «UID» Nom à mettre en place le concept relationnel qui
Tuple 1 1 Végétarienne consiste à voir les données sous une forme
matricielle, à l'image d'un tableur; en
Tuple 2 2 Viande colonne de la relation nous trouvons,
Tuple 3 3 Poisson justement, les colonnes de la table et en
ligne les tuples représentants les occurrences
Tuple 4 4 Mélange d'objets enregistrés dans la table ou
relation 16.
Tuple 5 10 Dessert
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» «FK» «UID»
Numero GPizz_Numero 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.

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

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 multi-
tiers, 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.

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.

La connexion que nous venons d'établir
matérialise le double flux de données de
SI notre représentation symbolique du SII de
l'entreprise [Chapitre 5-Modèle
SII 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.

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 ci-
contre, 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.

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.
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
l'identifiant naturel de la table de référence.
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.

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.

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.
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.

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 ci-
dessus car les APIs de tables
doivent pouvoir s'appuyer sur
des tables préalablement créées
pour être compilées 25.
Pour pouvoir exécuter les deux

familles de scripts, le
développeur doit depuis son
poste de travail se connecter à la
base de données cible.
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.

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.

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

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.

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.
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.
Le principe du travail de test des données est illustré par le schéma ci-dessus.
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].

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.

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.

Le volume des objets informatiques que nous avons conçus étant réduit au seul formulaire ci-
dessous, les tests ne vont concerner que la manipulation 29 de pizzas comme illustré ci-
dessous. Néanmoins, vous pouvez déjà observer, l'auto-incrémentation de la clé primaire,
cachée aux utilisateurs, tout comme l'alimentation de la clé étrangères du genre de pizzas.
9.3 Finalisation des transactions
Dans le modèle client-

serveur, lorsque le client
crée une connexion, il
ouvre une session.
Dès que le client envoie

une requête de
modification des données,
il initialise implicitement
une transaction. Le serveur
ne sait pas si cette requête
va être suivie d'autres ou
pas. Il appartient au client
de clore ou pas la
transaction; pour ce faire,
le langage SQL propose
deux instructions à utiliser
comme requêtes: COMMIT et ROLLBACK.
COMMIT valide l'ensemble des transactions en cours et ROLLBACK les annule. Tant qu'une
transaction n'est pas validée, les données mises à jour ne sont visible que par la session qui a
initié la transaction.
Lorsque vous vous connectez au SGBD-R Oracle avec SQL Developper ou avec MS-Access
vous ouvrez une session.
29
La manipulation des données implique la lecture, l'ajout, la modification et la suppression.

Lorsque vous faites votre première manipulation avec SQL Developper, vous initiez
une première transaction que vous pourrez valider ou annuler avec les boutons qui
correspondent à COMMIT ou ROLLBACK.
Lorsque vous quittez SQL Developper, celui-ci va, par défaut, faire un COMMIT et rendre
valide les transactions qui seraient pendantes; naturellement, si une erreur survient, toutes les
transactions pendantes sont annulées.
Avec MS-Access, le principe est quelque peu différent. Pour l'utilisation que nous en faisons
dans ce cours, chaque manipulation de tuple fait l'objet d'une transaction autonome 30.
10 Liens Internet
[COMP] La complexité
http://complexite.epikurieu.com/
[DICOFR] www.dicofr.com
[VOLLE] http://www.volle.com/ulb/031122/informatisation.htm
[I-1] Wikipedia – Chronologie de l’informatique
http://fr.wikipedia.org/wiki/Chronologie_de_l'informatique
[I-2] Wikipedia – Systémique
http://fr.wikipedia.org/wiki/Systémique
[I-3] Wikipedia – Système d’information
http://fr.wikipedia.org/wiki/Syst%C3%A8me_d'information
[I-4] Wikipedia – Architecture informatique
http://fr.wikipedia.org/wiki/Architecture_informatique
[I-5] Wikipedia – Architecture orientée services
http://fr.wikipedia.org/wiki/Architecture_orient%C3%A9e_services
[I-6] Wikipedia – Urbanisation (informatique)
http://fr.wikipedia.org/wiki/Urbanisation_(informatique)
[I-7] Wikipedia – Enterprise Service Bus
http://fr.wikipedia.org/wiki/Enterprise_Service_Bus
[I-8] Wikipedia – Cloud computing
http://fr.wikipedia.org/wiki/Cloud_computing
30
Envoi systématique d'un COMMIT après chaque manipulation.

11 Bibliographie
[1] Dictionnaire de la micro-informatique, Microsoft Press, 1999

[2] L’ingénierie des systèmes d’information évolutifs, S. Bouchy, Eyrolles, 1994
[SJB-02] Analyse et conception de systèmes d’information, J Satzinger, R Jackson et D.
Burd, Ed Reynald Goulet,2003
[PAS-1] HEG-Arc - Qu’est-ce que l’informatique de gestion
P.-A. Sunier, 2003
http://lgl.isnetne.ch/publications/sees/Article001Complet.pdf
[PAS-2] HEG-Arc – La nécessité d’évolution de l’entreprise
P.-A. Sunier, 2009
http://lgl.isnetne.ch/methodologie-2005HES/chapitre_025/evolution.pdf
[PAS-3] HEG-Arc – Le rôle de l’informaticien de gestion HES au sein des entreprises
P.-A. Sunier, 2007
http://lgl.isnetne.ch/publications/agefi/Article005InitialBilan.pdf
[PAS-4] HEG-Arc – La maîtrise des informations, un enjeu pour les entreprises

P.-A. Sunier, 2003 http://lgl.isnetne.ch/publications/agefi/Article001Complet.pdf
[PAS-5] HEG-Arc – Le cahier des charges de logiciels de gestion
P.-A. Sunier, 2004
http://lgl.isnetne.ch/publications/agefi/Article002.pdf
[PAS-6] HEG-Arc – Durabilité des logiciels de gestion
P.-A. Sunier, 2004
http://lgl.isnetne.ch/publications/DurabiliteLogiciel_2009/DurabiliteLogicielsComplet.pdf
[PR] Petit Robert, 1985
[HM-05] Des managers des vrais! Pas des MBA
Henry Mintzberg, 2005, Editions d'Organisation


Langue

Informatique de Gestion

Transféré par

Informations du document

Description :

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Informatique de Gestion

Titre original :

Transféré par

Description :

Droits d'auteur :

Formats disponibles

Bases de modélisation du système

Eléments théoriques en complément du cas pratique ArcPizzas

1 Propos liminaire ................................................................................................................. 4

Bases de modélisation du système 2/44 P-A. Sunier

Bases de modélisation du système 3/44 P-A. Sunier

Il n'est en aucun cas un cours de méthode, de modélisation, de conduite de projet ou encore

La problématique d'une entreprise de livraisons de pizzas à domicile est volontairement très

Bases de modélisation du système 4/44 P-A. Sunier

2.1 Qu'est-ce que la modélisation?

La modélisation est une démarche qui tend à représenter sous une

Un modèle, résultat de la démarche de modélisation, n'est pas la réalité

Un modèle n'est pas neutre; le message que transmet le

Bases de modélisation du système 5/44 P-A. Sunier

L'emploi d'outils tels

En utilisant un outil informatique de

Dans le cliché ci-contre, nous voyons les

Bases de modélisation du système 6/44 P-A. Sunier

La modélisation de l'entreprise et de son

Dans le navigateur du référentiel ci-

Les diagrammes sont la forme usuelle

Dans le navigateur de diagrammes ci-contre,

Bases de modélisation du système 7/44 P-A. Sunier

• le sous-système opérant (SO) qui active les

• le sous-système de pilotage (SP) qui

• [2] le sous-système d’information (SI) qui

Le sous-système d’information (SI) participe à la pérennité et à la stabilité de l’entreprise en

3 Modèle des cas d'utilisation métier

En plus de faciliter la compréhension du métier de

Bases de modélisation du système 8/44 P-A. Sunier

3.1 Description des cas d'utilisation métier

La seule représentation graphique des cas

Pour faciliter la recherche de nos diagrammes

Bases de modélisation du système 9/44 P-A. Sunier

Bases de modélisation du système 10/44 P-A. Sunier

Dans ce deuxième diagramme d'activités, représentation partielle du cas d'utilisation métier

Bases de modélisation du système 11/44 P-A. Sunier

Pour la description du système opérant de l'entreprise, la communauté informatique parle

Sans que cela puisse être érigé en tant que règle:

Bases de modélisation du système 12/44 P-A. Sunier

4.1 Description des cas d'utilisation du système d'information

Nous pourrions décrire nos cas

Nous limiterons notre description

Le diagramme de séquence ci-

Nous voyons les messages

Bases de modélisation du système 13/44 P-A. Sunier

Bases de modélisation du système 14/44 P-A. Sunier

De manière très schématique, le

Ces trois éléments de modélisation sont:

Interfaces, des formulaires ou des matériels physiques qui permettent

Bases de modélisation du système 15/44 P-A. Sunier

Entités métier, des entités de données qui assurent la persistance 6 des

5.1 Diagramme de communication

La mise en place de diagrammes de

Le diagramme de communication privilégie l'aspect spatial et organisationnel des différents

Bases de modélisation du système 16/44 P-A. Sunier

Bases de modélisation du système 17/44 P-A. Sunier

Le modèle conceptuel de données va nous permettre de définir les entités de données

Bases de modélisation du système 18/44 P-A. Sunier