Embed Size (px)
Citation preview
Raison sociale : SBCI Cartonnage
PDG : Mme Christine-Noëlle BAUDIN
Responsable de stage : M. Stéphane LASALLE
Formation : Licence 3 Informatique
Stagiaire : M. David CUGNEZ
Durée du stage : trois mois
Université de Franche-Comté
UFR Sciences & Techniques
Tuteur de stage : Mme Françoise GREFFIER
Année universitaire : 2007-2008
1
2
REMERCIEMENTS
Avant tout, je tiens à adresser toute ma gratitude à Mme BAUDIN ainsi qu’à
toute l’équipe pour m’avoir accueilli au département informatique de l’entreprise SBCI.
Je remercie aussi tout particulièrement mon tuteur de stage, M. LASALLE pour avoir su
guider mes travaux et m’éclairer sur les points difficiles. En effet, ce projet m’est
apparu quelque peu complexe à aborder compte tenu des nombreux choix
technologiques à réaliser. Ce travail résulte d'une étroite collaboration avec mon tuteur
qui m’a permis de fixer des objectifs planifiés et parfois de recadrer le travail pour
atteindre le résultat final.
1
SOMMAIRE
INTRODUCTION .................................................................................................................................................6
I/ La société SBCI ..................................................................................................................................................7
1) Historique ............................................................................................................................................7
2) Le cartonnage ...................................................................................................................................... 7
a) Qu’est-ce que le cartonnage ?.......................................................................................................... 7
b) Phases de production d’un produit .................................................................................................. 7
3) Politique de l’entreprise....................................................................................................................... 8
a) Place de l’informatique.................................................................................................................... 8
b) Place du devisage ............................................................................................................................ 8
II/ Etude de l’existant ............................................................................................................................................9
1) Situation du devis parmi les différentes activités ................................................................................ 9
2) Définition du logiciel........................................................................................................................... 9
2) Définition du logiciel......................................................................................................................... 10
3) Problèmes et lacunes actuels ............................................................................................................. 10
a) Performances ................................................................................................................................. 10
b) Principe de saisie ........................................................................................................................... 11
c) Problématique de la saisie.............................................................................................................. 12
d) Etude d’un exemple ....................................................................................................................... 12
III/ Calendrier ......................................................................................................................................................15
1) Calendrier prévisionnel...................................................................................................................... 15
2) Calendrier effectif.............................................................................................................................. 15
IV/ Choix technologiques et conceptuels............................................................................................................16
1) Discussion de l’architecture fonctionnelle......................................................................................... 16
a) Avantages et inconvénients de l’architecture 2-tiers ..................................................................... 16
b) Avantages et inconvénients de l’architecture 3-tiers ..................................................................... 16
2) Système de gestion de base de données............................................................................................. 17
3) Serveur web ....................................................................................................................................... 19
4) Langage de programmation ............................................................................................................... 19
5) Logiciel de développement................................................................................................................ 21
V/ Etude de la solution de devisage ....................................................................................................................23
1) Modélisation...................................................................................................................................... 23
a) Diagramme des cas d’utilisation.................................................................................................... 23
b) Diagramme de classes ................................................................................................................... 24
2
2) Objectifs ............................................................................................................................................ 25
3) Présentation graphique ...................................................................................................................... 25
4) Concepts ............................................................................................................................................ 27
5) Choix et difficultés rencontrés........................................................................................................... 27
VI/ Bilan................................................................................................................................................................30
1) Rétrospective des étapes effectives de l’étude................................................................................... 30
a) Etapes de la phase de choix ........................................................................................................... 30
b) Etapes du développement .............................................................................................................. 31
2) Etapes restantes ................................................................................................................................. 32
VII/ Conclusion technique...................................................................................................................................33
VIII/ Conclusion générale ...................................................................................................................................34
BIBLIOGRAPHIE...............................................................................................................................................35
WEBOGRAPHIE ................................................................................................................................................36
GLOSSAIRE........................................................................................................................................................38
RÉSUMÉ ..............................................................................................................................................................47
ABSTRACT..........................................................................................................................................................47
ANNEXE TECHNIQUE .....................................................................................................................................48
A1 / Phases de production des produits .............................................................................................................49
A2/ Organigramme des étapes de la mise en production .................................................................................50
A3/ Formulaires généraux de saisie du type d’élément ....................................................................................51
A4/ Formulaires de saisie du type d’élément par quantité ...............................................................................52
A5/ Diagramme des cas d’utilisation général ....................................................................................................53
A6/ Diagramme des cas d’utilisation du logiciel................................................................................................54
A7/ Diagramme de Séquence du logiciel ............................................................................................................55
A8/ Etude d’un cas concret avec la nouvelle application..................................................................................56
APPENDICE DES ILLUSTRATIONS..............................................................................................................59
6
INTRODUCTION
Dans l’univers industriel, sélectionner un fournisseur fiable, compétitif et
dynamique se révèle capital à la survie d’une entreprise. Comment identifier ces notions
chez un fournisseur ? Certes, les labels et certifications font montre de sérieux et de
stabilité. Cependant, la conjoncture pousse les entreprises vers une course effrénée
d’une quête du moindre coût, parfois en détriment d’autres critères essentiels. C’est
pourquoi le prix se révèle être un critère de sélection souvent privilégié.
L’homéostasie de tout système holistique tel qu’une entreprise ne peut se
résumer à réduire les coûts de ses produits aveuglément. Tandis que des prix trop faibles
conduisent à une atrophie des fonds de roulement de l’entreprise, des prix trop forts
induisent un appauvrissement de la clientèle. Il ressort que seule une estimation au plus
juste des prix demeure le meilleur garant d’une bonne santé de l’entreprise. Par voie de
conséquence, des prix rigoureux signifient des services et des prestations de qualité. De
l’étendue de la gamme de l’offre, dépend la complexité de la tâche de « devisage ». En
dépit des apparences, le cartonnage propose des produits hétéroclites dont les circuits de
fabrication sont le résultat de multiples combinaisons de procédés.
Mon travail s’inscrit dans le cadre de l’amélioration et du renouvellement des
outils logiciels internes de SBCI. L’entreprise dispose à cet effet d’un département
informatique. Afin de retracer au mieux les étapes de mon travail, nous aborderons le
logiciel de devisage existant, afin de mettre en évidence les lacunes actuelles. Nous
nous intéresserons ensuite aux choix des moyens techniques les plus appropriés à
l’élaboration du logiciel. Enfin, nous développerons la solution logicielle sur les plans
fonctionnels et organisationnels, avant de traiter certains aspects plus techniques.
Notons que les termes techniques en italique sont explicités dans le glossaire, à la fin de
ce document.
7
Fig. I.2.b : De gauche à droite : Objets, PLV, blister cart et skin pack
I/ La société SBCI
La société SBCI est une entreprise de taille moyenne dont la fonction est la
production de produits cartonnés. L’élaboration des produits, de la conception à la livraison
est entièrement réalisé par SBCI.
1) Historique
Cette société familiale a été crée en 1958 par M. Pierre BAUDIN. Mme Baudin
est l’actuelle PDG de SBCI. L’entreprise dispose de deux sites, le premier à Baume-les-
Dames et le second à Morteau.
2) Le cartonnage
a) Qu’est-ce que le cartonnage ?
Le cartonnage consiste à réaliser une large gamme de
produits dont la matière première est la feuille de carton. La variété des
produits comprend les boîtes et étuis (composés d’éléments standards), les boîtes
spéciales, les présentoirs publicitaires (PLV), les objets cartonnés, les skins et les blister
carts (supports cartonnés).
b) Phases de production d’un produit
Le cycle de production comprend la commercialisation, l’étude du modèle, la pré-
presse, l’impression et la production proprement dite et enfin la logistique. Afin de mieux
situer le devis dans son ensemble, observons dans quel contexte il s’inscrit. Le client prend
contact avec le commercial afin de spécifier ses besoins. Le produit fait l’objet d’une étude
de faisabilité dont le résultat est une pré-maquette, ébauche du futur produit. Après une
première approbation du client, l’étude est transmise au deviseur dont le but est d’établir un
devis calculé au plus près des contraintes budgétaires. Si le prix et la prestation sont à la
convenance du client, la phase d’étude se poursuit. Lorsque l’étude finale est validée par le
client, la pré-presse ainsi que la gestion de la production se mettent en place. Le
Fig. I.2.a : De gauche à droite :
Etui et boîtage spécial
8
responsable technique, chargé de l’ordonnancement organise la réalisation des différentes
tâches, et s’assure de la disponibilité des ressources humaines et matérielles requises. En
paralléle, le responsable du graphisme prépare l’impression. Dès que les conditions sont
réunies, un planning est alors établi et la mise en production commence. Enfin, les articles
sont conditionnés puis acheminés vers le client. Voir les détails en annexes A1 et A2.
3) Politique de l’entreprise
a) Place de l’informatique
A l’instar des grandes sociétés, SBCI fonde sa logique de production autour de
l’outil informatique. Cependant, contrairement à ces dernières qui recourent souvent à
des solutions globales, fastidieuses et coûteuses comme l’ERP ou le MES, SBCI a choisi
une approche plus raisonnée. SBCI met tous ses efforts dans le développement
d’applications entièrement personnalisées et adaptées à ses besoins, afin d’obtenir une
meilleure synergie entre l’information et la production. La société dispose d’un outil
intégré en adéquation avec l’outil de production lui permettant de garder un meilleur
contrôle de ses moyens technologiques. A cet effet, SBCI dispose d’un département
informatique dédié à la maintenance du parc informatique ainsi qu’au développement
d’applications et à leur amélioration.
b) Place du devisage
Le deviseur de l’entreprise, personne chargée de réaliser les devis, participe
également aux l’activités d’ordonnancement, de planning et de lancement. Forte de son
succès, SBCI tend à augmenter ses effectifs afin de répondre au nombre grandissant de
commandes. Précisons que la moyenne quotidienne des devis avoisine la vingtaine. On
enregistre des pics pouvant atteindre cent vingt devis par jour. Pour faire face à cette
situation, deux alternatives s’offrent à la société quant à la gestion du devisage. La
première consisterait à spécialiser une personne à plein temps sur l’activité de devisage.
La seconde s’orienterait, au contraire, vers une vulgarisation du devisage en vue d’en
permettre l’accès au plus grand nombre. SBCI a choisi cette dernière solution, compte
tenu du caractère rébarbatif de cette activité.
9
Fig. II. : Page d’accueil de l’application actuelle de devisage
Fig. II.1 : Diagramme de Séquence général
II/ Etude de l’existant
Comme nous l’avons cité plus haut, le logiciel de devisage est aujourd’hui
victime du succès de la société. Dès
sa mise en place, le logiciel de devis
a constitué une réelle panacée pour
le deviseur qui s’est vu déchargé
d’une part importante de cette tâche
fastidieuse. Aujourd’hui encore,
l’algorithmique complexe sous-
jacente n’est pas à remettre en
question. En revanche, la structure
intrinsèque du logiciel s’avère sclérosée et ne saurait faire face à une utilisation toujours
plus soutenue (voir les causes humaines chapitre I.3.b).
1) Situation du devis parmi les différentes activités
Comme le montre le diagramme ci-dessous, l’activité de devisage joue un rôle
clef dans le cycle de production (voir diagramme des cas d’utilisation en annexe A6
ainsi que le diagramme de séquence de la saisie, en annexe A7).
10
Base de
données
Logiciel de
devisage
Serveur
Client lourd
Fig. II.2 : application client-serveur 2-tiers
2) Définition du logiciel
L’application actuelle est une application client-
serveur avec un client dit « client lourd ». Un client lourd
désigne une application cliente exécutée par le système
d’exploitation de l’utilisateur. Alors que pour le client léger, l’application accède au
serveur via une interface web. L’ensemble des traitements s’effectuant côté serveur. On
parle également d’architecture « 2-tiers » pour « client lourd », par opposition à
l’architecture « 3-tiers ». L’application peut se résumer en une suite de formulaires
permettant de spécifier les spécificités du produit. A la fin de cette saisie très
séquentielle, fait suite un algorithme mathématique générant les prix du produit.
3) Problèmes et lacunes actuels
a) Performances
Le nombre croissant d’utilisateurs implique à cette application muli-postes une
bonne optimisation de l’accès aux données. Il s’avère que l’application actuelle est une
application Access et répond de moins en moins aux besoins de l’entreprise.
Le serveur dispose de données de type Access auxquelles les clients lourds
accèdent. Un client lourd est composé d’un PC sur lequel un logiciel Access (runtime
Access) permet le fonctionnement de l’application Access de devisage.
D’une part, le couple « runtime-application de devisage » se distinguent
malheureusement d’une application exécutable en terme de performances.
D’autre part, bien qu’Access soit un outil relativement puissant, son moteur SGBDR ne
saurait être comparé à celui de MySQL, SQL Server, Oracle ou d’autres. Access n’est
pas conçu pour supporter de très grandes bases de données sur de grands réseaux. En
théorie Access pourrait supporter des configurations de deux cent cinquante six postes.
En pratique, il se limiterait à une vingtaine d’utilisateurs simultanés. Chez SBCI, ce
quota est en passe d’être dépassé, notamment en terme de connexions. Pour fixer les
idées, le serveur doit satisfaire une moyenne de vingt connexions quotidiennes. Notons
que les échanges réseaux avec Access sont une vingtaine de fois plus « gourmands » en
bande passante que ceux de SQL Server.
11
b) Principe de saisie
Quelques notions préalables sont nécessaires au bon entendement de la suite du
document. Un produit résulte d’un assemblage d’éléments. Plutôt que de renseigner
plusieurs éléments identiques, il est judicieux de ne renseigner que le type auquel ils
appartiennent. Il suffira ainsi de préciser la quantité du type concerné.
Produire une ou un millier de pièces n’induit pas les mêmes coûts unitaires.
Similairement, un cartonnier n’utilisera pas le même format de matière première pour une
pièce que pour un millier. Ceci signifie qu’il conviendra de réaliser des « sous-devis », par
quantité spécifiée par le client (voir Fig. II.2.b).
Soit un produit A composé de six éléments appartenant à trois types différents.
Par exemple deux de type Ta, deux de type Tb et deux de type Tc. Sachant que le client
hésite sur les quantités les plus rentables, il veut connaître le prix de cent produits et dix
mille produits.
L’utilisateur devra d’abord renseigner trois séries de formulaires relatifs aux trois types
d’éléments. Chaque série de formulaires inclura deux sous-séries de formulaires relatifs
cette fois aux quantités à produire. Pour mieux se représenter la problématique de la
saisie, vous pouvez consulter le paragraphe d) de ce chapitre.
Fig. II.3.b : modélisation du parcours de saisie des informations
Produit A
- Elements E1, E2,
E3, E4, E5, E6.
=>Types Ta, Tb, Tc
=> Quantités :
-Q1 = 100
-Q2 = 10 000
Type n°x : écrans généraux Type n°x écrans Quantité n°y
Bouclage Quantités
y=y+1
Bouclage Type d’élement : x=x+1
Fin Type n°x Fin
12
Fig. II.c : Ecran de sélection de l’étude
Fig. II.3.d.1 : Ecran de sélection ECMA et nombre d’éléments
Liste des
quantités
à deviser
c) Problématique de la saisie
L’utilisation du logiciel actuel présente une gêne majeure en terme d’ergonomie
de travail. En raison de son outil de développement, l’application présente un
interfaçage rigide. En effet, la suite des formulaires à renseigner ne peut s’effectuer que
séquentiellement, sans retour possible (voir Fig. III.3.b). Toute erreur de saisie conduit
inévitablement à devoir réitérer le devisage.
Une gêne moindre se présente également au novice, en terme de positionnement
dans le devis. En dépit d’indications concernant le type d’élément concerné, la quantité
concernée et d’autres informations générales, se situer dans l’application reste malaisé.
d) Etude d’un exemple
- Saisie des données générales du produit :
Pour fixer les idées, prenons un cas concret. La première étape consiste à sélectionner une
étude (effectuée au préalable par le
commercial, voir annexe A1). Les
informations relatives à l’étude
s’affichent alors.
Le bouton permet l’accès à
l’écran ci-contre. Il s’agit alors de
sélectionner le type de produit parmi la
gamme des standards disponibles. Un
produit final peut résulter de l’assemblage
de plusieurs types de constituants. Dans cet
exemple considérons que le produit final
soit composé de trois types d’éléments.
13
Fig. II.3.d.2 : Ecran 1 de saisie de l’élément 1
L’utilisateur devra donc renseigner trois séries de formulaires. Il s’agira d’un premier
bouclage sur les types d’éléments.
Sur la droite de l’écran, une liste de quantités s’affiche. Dans le domaine de la
production industrielle, produire une ou un millier de pièces n’induit pas les mêmes coûts
unitaires. Similairement, un cartonnier n’utilisera pas le même format de matière première
pour une pièce ou un millier. A cela il faut ajouter les coûts de lancement, tels que les
réglages, la perte de l’encre non consommée par lancement. Ceci signifie qu’il conviendra
de réaliser des « sous-devis », par quantité spécifiée pour facturer ces coûts. Il s’agira d’un
bouclage sur les quantités, imbriqué dans le premier bouclage sur les éléments (voir Fig.
III.3.b).
- Saisie des données intrinsèque au type d’élément :
Ici commence la saisie d’un type d’élément. L’annexe A3, permet de visualiser
l’ensemble des écrans de définition propres à un type d’élément. Par souci de clarté, nous
n’étudierons que les deux principaux.
Ici encore, il s’agit de
spécifier un code produit ainsi
que le nombre des éléments dans
le type concerné.
Ensuite, se succèdent une suite de
formulaires permettant la saisie
d’autres informations également
propres au type d’élément. Ces
informations sont : La gamme de
fabrication, les matières
premières, les dimensions de la matière première et les frais d’établissement.
14
Fig. II.3.d.3 : Ecran 5 de saisie de l’élément 1
- Saisie des données propres au type d’élément par quantité
Nous distinguons deux types d’informations. Les informations intrinsèques au type
d’élément d’une part (Fig. III.2.d.2) et les informations propres aux quantités (Fig. ci-
contre), d’autre part.
Les formulaires faisant partie de
cette dernière famille
d’informations font l’objet du
deuxième bouclage dont nous
faisions allusion plus haut. C’est-à-
dire que ces informations seront à
saisir pour toutes les quantités
mentionnées (voir Fig. III.3.d.1)
dans le deuxième formulaire de
l’application.
15
III/ Calendrier
1) Calendrier prévisionnel
- 10 mars : Début du stage.
- Fin mars : Etude de l’existant et choix technologiques.
- Début avril : Développement de la partie graphique.
- Fin avril : Développement du code relatif aux objets à générer.
- Début mai : Développement des fonctionnalités de sauvegarde, d’édition et
d’impression.
- Fin mai : Intégration de la partie algorithmique. Rédaction du rapport et préparation de
la soutenance.
- Fin mai et début juin : Mise en service sur le serveur et débogage.
2) Calendrier effectif
- 10 mars : Début du stage.
- Fin mars : Analyse de l’existant et essais des diverses possibilités logicielles.
- Début avril : Suite des choix logiciels au travers d’essais.
- Fin avril : Développement de la partie graphique. Choix d’un Système de Gestion de la
Base de Données (SGBD).
- Début mai : Développement du code relatif aux objets à générer. Poursuite du
développement de la partie graphique.
- Fin mai : Résolution des problèmes et bogues. Rédaction du présent rapport et
préparation de la soutenance.
- Fin mai et début juin : Développement des fonctionnalités de sauvegarde, d’édition et
d’impression.
16
Fig. III.1.a : Modèle d’architecture technique de l’architecture 3-tiers
Fig. III.1.a : Modèle d’architecture fonctionnelle de l’architecture 2-tiers
IV/ Choix technologiques et conceptuels
1) Discussion de l’architecture fonctionnelle
a) Avantages et inconvénients de l’architecture 2-tiers
D’une manière
générale, l’architecture
« 2-tiers » présente les
avantages de la
robustesse et de la rapidité de développement. L’interface graphique est plus riche et
facile à développer, notamment à l’aide d’outils dits RAD (Rapid Application
Development). La distinction entre le fond et la forme permet une programmation aisée,
dans le cas où on utilise des outils RAD.
Cependant, ce type d’application consomme beaucoup de bande. Or comme
nous avons pu l’observer, la surcharge réseau constitue un réel problème pour
l’entreprise. De plus, les mises à jour se révèlent laborieuses pour l’administrateur du
parc informatique relativement conséquent. En effet, il incombe à l’administrateur
d’installer, configurer et mettre à jour le logiciel sur chaque machine.
b) Avantages et inconvénients de l’architecture 3-tiers
Un des avantages
majeurs du client léger
est que la logique réside
sur le serveur. Le client
léger reste toujours à jour
par rapport au serveur,
car c’est le serveur qui délivre l’interfaçage. Les requêtes client vers serveur, basées sur
le langage SQL, sont d’une grande flexibilité. D’un point de vue du développement, la
séparation client, serveur et SGBD, permet une spécialisation sur chaque tiers de
17
l’architecture. De surcroît, la flexibilité dans l’allocation des ressources, la portabilité
du tiers permet d’envisager une allocation et ou modification dynamique au grés des
besoins.
L’expertise de développement dans cette architecture demeure plus longue que
dans le cas d’une architecture 2-tiers. Corollaire du point précédent, développer une
application 3-tiers revient plus cher que de développer un client lourd. En dépit de ce
dernier point, cette solution reste la plus appropriée à notre problème.
2) Système de gestion de base de données
L’architecture 3-tiers que nous avons choisi implique l’emploi d’un système de
gestion de base de donnée (SGBD ou DBMS). Le choix d’un SGBD en adéquation avec
l’application est capital pour un fonctionnement optimal de l’application future. En
raison de sa popularité en informatique, nous nous orienterons d’emblée sur une base de
données relationnelle. Le SGBDR doit pouvoir répondre aux besoins : L’application
doit bien entendu être multiutilisateurs, performante, pérenne et facilement maintenable.
Parmi les bases de données, il se dégage deux catégories, les bases libres et les
bases propriétaires. Nous retiendrons MySQL et PostgreSQL, pour les bases libres. SQL
Server et Oracle, pour les bases propriétaires. Cependant, Oracle restant relativement
onéreux, nous l’écarterons d’emblée.
Les critères de choix d’une base de données sont le mécanisme de stockage,
l’ intégrité des données, l’annulation de transaction, la gestion des interblocages, les
types supportés, la réplication, la portabilité, les interfaçages, les utilitaires associés au
SGBD, les utilitaires de migration, le support technique et enfin les fonctions avancées.
La caractéristique vitale pour une base de données est l’intégrité des données. Le
gage de ce critère est la conformité « ACID » (Atomic Consistent Isolated Durable).
ACID signifie essentiellement que toute transaction exécutée est soit réussie, avec mise
18
à jour de la base, soit nulle, avec aucune modification de la base. PostgreSQL, MySQL
et SQL Server sont toutes conforme à « ACID ».
Elles supportent également l’annulation partielle de transactions (rollback) et
elles savent gérer les interblocages (deadlocks).
Quant au types de données supportés, les SGBD gèrent les types standards, le
type objet et GIS (Geographic Information System). Cependant PostgreSQL se
démarque en supportant des types définis par l’utilisateur.
Elles supportent également très bien la fonctionnalité de réplication. Rappelons
que cette dernière consiste à dupliquer des données qui resterons synchrones par rapport
à la base source.
En matière de portabilité, tandis que PostgreSQL et MySQL sont
multiplateformes, le SGBDR de Microsoft, SQL Server se cantonne à Windows.
En plus des méthodes d’interfaçage natifs, ils supportent tous ODBC et JDBC.
Malheureusement, en ce qui concerne les sauvegardes, les systèmes libres
profilent des solutions limitées.
Quant aux outils de gestion de la base, tous offrent des utilitaires dont
l’utilisation est aisée.
Un point important est la migration des données. PostgreSQL et MySQL
disposent d’utilitaires de migration complets. Nul besoin de préciser que Access permet
aisément de migrer vers SQL Server.
Le support technique constitue un service parfois vital pour une entreprise.
Contrairement aux idées reçues, les SGDBR libres disposent d’un support technique
appréciable ainsi que des formations complètes.
Les fonctions avancées telles que les déclencheurs (triggers), les vues (views),
les séquences, les procédures stockées et les indexes sont supportées par l’ensemble des
SGBD sélectionnés. Les indexages permettent l’optimisation de l’accès aux données
d’une table. Ces SGBDR supportent d’ailleurs les indexes simple colonne, multiple
colonne, clef unique et clef primaire.
19
Enfin, SBCI recherche un logiciel pérenne. Ce critère dépend essentiellement de
sa notoriété, de la popularité de l’outil logiciel et de la stabilité de l’éditeur concerné.
MySQL, SQL Server et PostgreSQL sont toutes trois largement utilisées dans le milieu
industriel. Les données dont nous disposons à ce niveau ne permettent pas de préciser
nos choix plus précisément. La base de données que l’on choisira dépendra à présent
des choix du langage et de l’outil de programmation.
3) Serveur web
Une base de donnée fonctionne de pair avec un serveur de données. Le choix du
serveur dépend de la base pour laquelle il est compatible. SQL Server fonctionne avec
IIS (Internet Information Server). MySQL et PostgreSQL sont compatibles avec divers
serveurs tels que Apache et GlassFish, par exemple.
4) Langage de programmation
Les critères de choix du langage de programmation sont : Permettre la
génération de pages web dynamiques, haut niveau de programmation, popularité,
pérennité et facilité de mise en œuvre.
Le langage de programmation à définir est destiné à permettre une
programmation de haut niveau. Le niveau de programmation correspond à la position
du langage par rapport au système. Un haut niveau signifie une haute abstraction par
rapport aux détails inhérents au support technologique et matériel. Notre application
consiste à réaliser des calculs à partir de données saisies dans des formulaires. Il se
révèlerait inadapté et laborieux de programmer une telle application dans un langage de
bas niveau tel que l’assembleur. Les langages de haut niveau les plus communs sont
C++ , C#, Visual Basic, Java, PHP, Java et ASP. Ce dernier autorise l’implémentation
de trois langages, qui sont C++ , C# et Visual Basic. Alors qu’une solution éphémère
pourrait se contenter d’un langage peu structuré, une solution pérenne, se doit de
recourir au paradigme objet. Nous retiendrons donc Java et ASP.NET.
20
Java permet de travailler à un niveau plus haut que C++ . Par exemple, il
dispense de la gestion de la mémoire par le programmeur. Il permet de gérer des
structures de données et sa programmation est relativement accessible. Certains
environnements de développement (IDE) tels que Eclipse ou NetBeans permettent une
bonne intégration de ce langage pour programmer des applications serveur de type
servlet et Java Server Page (JSP). Suite à divers essais dans ce langage, il apparaît
évident que la distinction entre le fond et la forme de JSP constitue une avancée non
négligeable en terme de programmation web. Nous écarterons donc la solution des
servlets Java au profit des JSP. De plus, l’outil NetBeans permet une programmation
« visuelle » des pages web en présentant une programmation proche de la
programmation des applications fenêtres (Windows Applications). Ainsi, la
maintenabilité devient plus facile car le code est plus clair. Ajoutons encore que des
IDE tels que Eclipse ou NetBeans intègrent une gestion de la base données et du serveur
ainsi qu’une programmation facilitée des pages. Quant à la pérennité et la popularité de
ce langage, le langage est open-source et demeure la propriété de Sun Microsystems. Ce
langage est largement utilisé dans le milieu industriel. De surcroît, ce langage fait
l’objet d’évolutions permanentes. Corolaire de ce dernier point, cependant, le
programme et l’outil de développement sont difficile à garder à jour. A ce titre, j’ai pu
constater, lors de mes essais, que les modules de développement internes à l’IDE de
NetBeans étaient en perpétuelle mutation. En dépit d’une bonne documentation, le
dédale des évolutions plonge le développeur dans la hantise d’utiliser un outil mal
configuré ou désuet. De plus, pour conserver un programme cohérent par rapport aux
évolutions, il convient de se replonger régulièrement dans le code afin de le maintenir à
jour.
ASP.NET, propose trois langages. De ces trois langages, nous retiendrons C#
pour les mêmes avantages que ceux constatés pour Java, sans présenter l’inconvénient
des mises à jour permanentes. Ce dernier présente les avantages de Java en terme de
niveau de programmation ainsi que quelques améliorations par rapport à Java. Il intègre
également différentes notions du langage C++ . Il est relativement simple à programmer
21
et satisfait bien entendu au paradigme de programmation objet. Comme son homologue
Java avec sa machine virtuelle, C# repose sur l’environnement gratuit « .NET »,
développé par Microsoft. A l’instar de Java, il présente aussi l’avantage de la pré
compilation autorisant une exécution plus rapide que les langages interprétés tels que
PHP. Ce langage profile un futur au moins aussi certain que celui de Java, du fait de
son caractère libre. Au travers de différents essais, j’ai pu constater d’une part les
mêmes avantages que ceux de JSP, quant à la séparation de code (code-behind) et de la
facilité de développement. D’un point de vue professionnel, C# s’avère largement
utilisé, du fait notamment, de sa stabilité et sa robustesse. Enfin, C# peut être développé
à l’aide d’IDE libres ou propriétaires. Pour cet ensemble d’avantages, ce langage de
programmation répond au mieux aux attentes de SBCI.
5) Logiciel de développement
Suite à ce choix capital que constitue le langage de programmation, reste à
définir l’environnement de développement que nous utiliserons. Pour développer en C#,
il est possible d’utiliser Mono, un IDE gratuit multiplateformes. Dans le domaine des
IDE propriétaires, nous retiendrons CodeGear, pour Embarcadero Technologies (ex-
Borland) et Visual Studio 2008, pour Microsoft.
Certes, Mono offre de larges possibilités de développement, mais la difficulté à
utiliser cet IDE réside dans la singularité de ses tutoriaux, forums et documentations. En
revanche, cet IDE reste une solution de repli dans le cas où ses « concurrents »
propriétaires viendraient à durcir leurs conditions commerciales.
Globalement, CodeGear présente les même inconvénients que Mono. De plus,
nous pouvons noter une lourdeur notable de l’IDE lors de l’installation ainsi que lors du
lancement. Enfin, cet IDE dispose d’une gratuité limitée à seulement trente jours et son
prix reste élevé. A cela s’ajoute le rachat de Borland par Embarcadero Technologies,
synonyme d’instabilité.
22
Visual Studio, quant à lui, dispose d’une version totalement gratuite permettant
de répondre aux besoins de SBCI. L’installation comme le lancement de cet outil ne
présente pas de lenteur majeure. En outre, SQL Server Express, également gratuit
permet de fournir une solution intégrée au développement du logiciel de devis. Notons
que les limitations induites par cette gratuité ne pénalisent pas l’utilisation outre mesure
de l’IDE. De surcroît, les limitations de SQL Server 2005 Express sont facilement
compensables par l’utilisation d’un matériel adapté. De plus, on observe une quantité
non négligeable de forums, tutoriaux et documentations traitant d’ASP.NET avec l’outil
Visual Studio. Au niveau industriel, ASP.NET est largement mis en œuvre avec l’IDE
Visual Studio. Enfin, les dernières évolutions de Visual Studio 2008 en font un outil de
développement relativement bien adapté au développement web. De même que ses
concurents, ASP sous Visual Studio autorise l’utilisation de programmes côté client tels
que Ajax, javascript et vbscript. L’ensemble de ces raisons nous on orienté à opter pour
cet IDE.
23
Fig. V.1.a : Diagramme des cas d’utilisation
V/ Etude de la solution de devisage
Les choix stratégiques réalisés plus haut constituent les moyens nécessaires à
l’élaboration du logiciel de devisage. Avant de procéder à une quelconque
implémentation, procéder à une formalisation du futur logiciel peut limiter les écueils.
1) Modélisation
a) Diagramme des cas d’utilisation
Un utilisateur doit pouvoir réaliser les différentes étapes de l’élaboration d’un
devis. Ces étapes sont, le choix de l’étude, le renseignement des différents formulaires,
le calcul des prix pour l’ensemble des quantités, l’édition et impression du devis (voir
annexe A7). Le devisage implique l’utilisation de la base de données.
24
Fig. V.1.b : Diagramme de classes du logiciel
b) Diagramme de classes
La réalisation des différentes classes de l’application de devis passe
nécessairement par une modélisation objet. Cette dernière nous permettra de prendre le
recul nécessaire au développement d’un programme intelligible.
Ce diagramme met en évidence que la construction d’un devis passe
nécessairement par une étude préalable. De même, il met en lumière la notion de
données intrinsèques à un élément et les données de l’élément relatives à une quantité.
Ces classes seront implémentées en C#, dans un dossier spécifique à la définition de
classes. L’ensemble des classes de ce dossier sera compilé dés l’exécution de
l’application.
25
Fig. V.3.1 : Page Etude
2) Objectifs
L’objectif premier du projet consiste à réaliser une interface conviviale et
limitant au maximum les risques d’erreur de saisie en les traitant à la source. La seconde
consiste à régler les problèmes techniques liés à la possibilité de pouvoir modifier la
saisie dans des pages amont sans préjudice sur les saisies aval. La troisième partie
consiste à offrir la possibilité d’enregistrer la saisie d’un devis afin de pouvoir la
restaurer ultérieurement. Puis, il reste à gérer les fonctionnalités d’édition et
d’impression. L’avant-dernière partie se résume à intégrer la partie algorithmique du
devis. Enfin, il restera à mettre en place l’application au niveau du serveur afin de
réaliser la phase de tests en réseau.
3) Présentation graphique
la partie graphique
mise en place utilise au
mieux les possibilités
offertes par une application
web. Au niveau de la gestion
de l’enchaînement des pages,
ASP.NET offre la possibilité
d’avoir recours à une page
maître. Cette dernière se
comporte comme un
conteneur dans lequel se loge le contenu des autres pages. Dans cette page sont disposés
les principaux boutons et menus. Des tabulations ainsi qu’une barre de navigation
permet un accès intuitif aux différentes pages de saisie. Afin d’informer l’utilisateur de
là où il se trouve, le chemin de la page en cours (breadscrumb) s’affiche en
permanence, en haut à droite. Pour plus de détails sur l’allure générale de l’application,
voir Annexe 8.
26
Dans l’application existante, la succession de pages peut être déconcertante pour
l’utilisateur débutant. La solution consisterait à réussir à synthétiser toutes ces pages de
saisie propre aux éléments en une seule page web. Le défi serait de rendre à la fois cette
page synthétique sans pénaliser le détail pour autant. Au premier abord, cela peut
sembler incompatible. Cependant, l’utilisation de langages côté client, tel qu’Ajax, peut
rendre ce souhait réalisable. Effectivement, il est possible de réduire et d’agrandir toute
une partie d’une page web. Ce moyen n’est cependant pas une solution à part entière
sans la présence d’un contrôle ASP.NET permettant de générer du code HTML à
volonté. Ce contrôle est un « répéteur » et sa source de donnée peut être un objet. Notre
application consiste en réalité à créer un objet « Devis » que l’on renseigne au fur et à
mesure que l’on rempli les formulaires. Ajoutons à cela qu’un répéteur est lui-même
capable de générer des contrôles tels que des boutons dont les méthodes peuvent être
attribuées à l’ensemble auquel ils appartiennent. Ainsi, chaque contrôle peut réaliser
une action qui lui est propre. L’impression d’écran ci-dessous illustre une page mettant
en œuvre ce principe (voir annexe 8).
Fig. V.3.2 : Page des Eléments
Cette zone a été
agrandie par simple
clic, afin de laisser
transparaître la zone
d’édition des
gammes
27
4) Concepts
Comme nous l’avons énoncé plus haut, cette application est basée sur la notion
d’objets. Les différentes classes sont conformes au diagramme de classes présenté dans
ce chapitre. Ce principe permet une meilleure gestion de la mémoire, donc des accès
parcimonieux à la base de données. De plus, en réponse à une des attentes de ce logiciel,
la sérialisation offre la possibilité de sauvegarder l’instance de l’objet en vue de le
restaurer ultérieurement. Notons que l’application web, par nature, à condition de réunir
le serveur et l’application sur une même machine, limitera l’utilisation de la bande
passante.
5) Choix et difficultés rencontrés
Suite à l’élection des choix stratégiques que son le choix de l’outil de
développement, du langage et de la structure 3-tiers, la première difficulté a été
l’utilisation des variables globales. Alors que dans une « application fenêtre », une
variable globale est définie pour toute l’application, dans une application web, il est
nécessaire de définir des variables de session. L’utilisation de ces dernières consiste à
restaurer la variable avant de l’utiliser. En cas de modification de cette variable, il
convient de la sauvegarder avant de quitter la partie de code considéré.
La seconde difficulté résida dans l’utilisation correcte de contrôles ASP.NET tels
que les listes déroulantes. En effet, après sélection d’une valeur de la liste déroulante, le
fait de quitter la page puis de revenir à cette page cause la perte de la sélection. Une
propriété de la liste permet de présélectionner la valeur à afficher conformément à la
valeur d’une propriété de l’objet.
Ensuite, ASP.NET propose diverses façons de manipuler les données ainsi que
plusieurs niveaux de gestion des données. La technologie évoluant rapidement par
rapport à la documentation disponible, il est aisé de se perdre dans des considérations
caduques. Après m’être orienté sur une solution où la gestion des données sont
28
nettement distinctes du code, je me suis finalement orienté vers une gestion plus mixte
des données et du code. Il s’agit en réalité du langage LINQ, langage relativement
proche du langage SQL. LINQ permet de réunir les requêtes et la partie programmation,
à l’image d’un des avantages de PHP.
Mes efforts se sont ensuite portés sur la recherche du contrôle le plus adapté à
l’affichage de données de type objet. ASP.NET propose divers contrôles, cependant ils
sont majoritairement destinés à la représentation de données issues de table de la base.
Or, rappelons le, notre application se doit de limiter l’accès à la base et donc de recourir
aux instances des objets. De cette quête, il est ressorti un contrôle nommé « répéteur ».
En dépit d’un intérêt patent de ce contrôle, j’ai pu noter une réelle pauvreté de la
documentation à ce sujet. Bien entendu, il est facile de trouver des exemples basiques à
ce propos, mais en matière de programmation objet, la documentation brille par son
aspect lacunaire.
A cette difficulté suivi la gestion de contrôles tels que les listes déroulantes et
les boutons placés à l’intérieur d’un répéteur. D’abord, comment récupérer l’événement
généré par l’appui sur un bouton sachant que le nombre de boutons dépend d’instances
d’objets ? Ensuite, comment identifier l’événement sachant qu’il reste impossible de
nommer un bouton lors de la programmation ?
Le logiciel de devis doit permettre, pour chaque élément, d’éditer une liste de matières
premières de l’élément. Il doit aussi permettre d’éditer une gamme de fabrication à
éditer avant de l’associer à l’élément concerné. Pour ce faire, il est impératif de pouvoir
gérer les contrôles de type bouton à l’intérieur d’un répéteur. Ne disposant pas
d’information en la matière, j’ai entrevu la possibilité d’avoir recouru à un contrôle
inadéquat, ne pouvant gérer ce type de contrôle. Heureusement, il est ressorti de mes
essais que les répéteurs savent gérer des boutons. L’ensemble de ces soucis on eu pour
issue de bon moyens d’identification des contrôles. De plus, il est apparu que
l’identification devait se faire lors de la phase de génération du code HTML.
29
Une autre difficulté relative au répéteur, est le besoin d’imbriquer un répéteur
dans le répéteur existant. Est-ce possible et si oui, comment gérer l’accès aux contrôles
tels que les boutons ou les listes déroulantes dans un tel contexte ?
Chaque élément se compose à la fois de données intrinsèques, renseignées dans le
premier répéteur et de données relatives à une quantité. Pour renseigner ces données par
quantité, un bouclage par quantité s’ajoute au bouclage par élément. Cette fois, la
littérature s’est montrée plus riche. La seule difficulté résiduelle a été l’exploitation des
données saisies que différents essais ont pu solutionner.
Toutes ces étapes se sont concentrées sur la génération de code HTML. Or,
conformément à la présentation graphique vue plus haut dans ce chapitre, le logiciel
doit offrir une présentation synthétique. Comment « zoomer » sur certaines zones et
comment réduire le reste ?
L’issue à cette question trouve son salut dans la programmation côté client. Visual
Studio permet l’intégration de modules externes tels que des programmes Ajax.
L’utilisation du contrôle appelé « accordéon » utilisé dans le logiciel de devisage
permet d’afficher une zone d’affichage supplémentaire par simple clic sur un texte. Un
doute sur la compatibilité entre le contrôle Ajax avec le répéteur s’est alors posé. Bien
entendu, la documentation ne traite pas de ce sujet. Heureusement, les essais ont été
probant, évitant ainsi toute remise en question de la structure de la programmation.
De même, d’autres contrôles Ajax permettent de vérifier la syntaxe d’une saisie
utilisateur avant tout envoi de requête au serveur. Ceci présente l’avantage de libérer la
bande passante et d’éviter à l’utilisateur de perdre un temps précieux.
30
VI/ Bilan
1) Rétrospective des étapes effectives de l’étude
a) Etapes de la phase de choix
- Analyse du programme Microsoft Access existant
⇒ Edition d’un fichier d’analyse du programme existant
- Définition du langage de programmation
• Etude des possibilités de Java (JSP, Servlet).
• Etude des possibilités de C#.
- Définition du logiciel de programmation
• Essais de Java avec NetBeans (JSP, Servlet).
• Essais de C# avec Visual Studio 2008.
- Définition de la base de données et export de la base Access existante
• Etude des Systèmes de Gestion de Base de Données (SGBD) du marché.
• Essais de Apache et GlassFish.
• Essais de MySQL.
• Essais de Microsoft SQL Server.
- Définition du type de l’application : Application Web ou Application Fenêtre
⇒ Choix de la solution Visual Studio 2008 avec SQL Server. Programmation en
ASP.NET avec C# et structure de l’application web 3-tiers.
31
b) Etapes du développement
- Développement de l’application web :
• Stratégie de développement
♦ Basée au maximum sur la notion d’objet :
- Afin de solliciter la base de données au minimum.
- Afin de pouvoir facilement faire de modifications en amont avec un
minimum de saisies à refaire.
• Utilisation de la programmation Ajax.
• Développement de la Page Maître.
♦ Création des tabulations (css), chemin de navigation, liste de navigation
(sitemap), contenu.
• Développement des pages de contenu
♦ Choix du langage et du support de liaison à la base de données :
- Essai d’ensembles de données (DataSets avec SQL).
- Essais de LINQ.
⇒ Choix de LINQ car plus adapté à la notion d’objets.
• Page par défaut :
♦ Création de l’objet « devis » par défaut.
• Page de choix de l’étude (devis basé sur une étude du commercial) :
♦ Gestion de listes de choix (DropDownList) alimentées par une requête LINQ.
• Page de paramétrage de la variante :
♦ Gestion de listes.
• Page de paramétrage des éléments :
♦ Choix des contrôles parmi : Répéteurs, DataView, DataGrid, …
♦ Gestion des Répéteurs et des Accordéons (Applications Ajax).
♦ Elaboration d’une solution afin d’ajouter une matière première à l’élément.
♦ Elaboration d’une solution afin d’ajouter une gamme à éditer au préalable.
• Correction de problèmes liés à la modification des pages dans les pages amont :
♦ Elaboration d’une solution permettant de conserver toutes les données saisies
dans d’autres pages non concernées par la modification.
32
2) Etapes restantes
Bien qu’étant relativement bien avancée, l’application de saisie et de calcul des
devis demeure inachevée, à ce jour. Avant la fin du stage, mes objectifs sont les
suivants :
● Gestion de la session (Connexion / Déconnection) / cookies.
● Sauvegarde de la session.
● Sauvegarde de l’objet en cours de création à l’aide de la sérialisation.
● Sauvegarde de l’objet sauvegardé par sérialisation.
● Intégration de la partie de calcul du devis.
● Gestion de l’impression du devis.
● Installation de SQL Server sur le serveur et création de la base de données.
● Installation de l’application sur le serveur et essais.
● Gestion de la sécurité.
33
VII/ Conclusion technique
De nombreux outils de développement informatiques spécialisés ont été
développé dans des langages dont la technicité n'a cessé d'augmenter. L’objectif étant
de soustraire les tâches fastidieuses et répétitives au programmeur. Paradoxalement, ce
dédale de solutions logicielles peut parfois perturber. Au cours de ce projet, j’ai tenté de
choisir les outils les plus adaptés à mes besoins. Ces choix on pu induire certains retards
visibles, mais le gain de temps effectif est bien réel. En effet, l'efficacité et la précision
étant des enjeux majeurs dans le développement informatique, il est impératif de savoir
opter pour des choix technologiques judicieux. Faire preuve d’une veille technologique,
peut permettre de gagner un temps devenu si cher.
Il n'aurait pas été envisageable de réaliser rapidement un logiciel de devisage
sans un outil performant. Inversement, il s'avère parfois nécessaire d'avoir recours à des
langages du type Javascript ou Ajax pour développer des applications côté client. En
effet, ce type d'application requiert une économie maximale de la bande. Cependant,
l’ensemble de ces choix passe nécessairement par des concessions car il s’agit en réalité
d’un compromis dont le résultat global tend à répondre au mieux à un besoin. Au vu du
temps imparti, des objectifs et de l’avancement, il ressort qu’une application web reste
relativement plus longue à implémenter qu’une application locale à fenêtre. Pourtant,
dans notre cas, le point d’honneur a été placé sur le gain de temps à l’utilisation, clef de
la réussite quotidienne de l’entreprise.
Conscients des impératifs d’efficacité et de précision, clefs de la réussite, les
informaticiens doivent apprendre à adapter les outils qu'ils utilisent, en fonction des
besoins. Désormais, une vision synthétique est requise pour mener à bien un projet.
34
VIII/ Conclusion générale
Au cours de ce travail, j’ai pu apprécier l’importance de la prise de recul
nécessaire à l’édification d’une structure de programmation claire. En dépit de l’avancée
actuelle du projet, le temps mort initial généralement constaté dans tout projet a
largement été écourté grâce à des outils performants et des moyens d'abstraction
adaptés.
Dans le développement de cette application, j’ai parfois eu besoin d'exprimer
certains principes à l'aide de la modélisation. L'opportunité de ce travail m’a permis de
mettre en lumière l'importance de certains concepts à priori illusoires, mais parfois
utiles à l'usage.
En dépit d’un temps alloué relativement adapté au projet, il ressort que j’ai
rencontré certaines difficultés initiales qui ont grevé mon temps de développement.
Cependant, notons que l’allure de développement n’a cessé d’augmenter du fait d’une
meilleure connaissance de l’outil de développement et du langage de programmation.
35
BIBLIOGRAPHIE
ASP, C# :
- Pro ASP.NET 2.0 in C#2005, Matthew MacDonald and Mario Szpuszta, 2005.
- Pro .NET 2.0 Code and Design Standards in C#, Mark Horner, Apress, 2006.
- Pro C# 2008 and the .NET 3.5 Platform, Andrew Troelsen, Apress, 2007.
- C# 2.0 Practical Guide for Programmers, Michel de Champlain and Brian
G.Patrick, Morgan Kaufmann Publishers, 2005.
- Advanced C# Programming, Paul Kimmel, Osborne, 2002.
36
WEBOGRAPHIE
UML:
� http://www.visual-paradigm.com
� http://uml.developpez.com
Java :
� http://www.java-tips.org/java-tutorials/tutorials/introduction-to-java-servlets-with-netbeans-
3.html
� http://www.netbeans.org/kb/55/tutorial-webapps.html
� http://java.sun.com/javaee/downloads/index.jsp
CSS :
� http://css.alsacreations.com/Construction-de-menus-en-CSS/Un-menu-deroulant-en-CSS-et-
XHTML-vertical-et-horizontal
� http://www.w3schools.com/css/css_examples.asp
Migration de base de données depuis Access :
� http://www.commentcamarche.net/forum/affich-1272846-migrer-bdd-access-vers-mysql
� http://www.mysql.com/products/tools/migration-
toolkit/tutorials/AccessMigrationTutorial.html
� http://support.microsoft.com/kb/325017/fr
Choix de base de données :
� http://www.mssqlcity.com/Articles/Compare/sql_server_vs_mysql.htm
ASP, C#, .NET, LINQ :
� http://morpheus.developpez.com/
� http://programmerworld.net/dotnet/books.htm
� http://www.vijaymukhi.com/
� http://webproject.scottgu.com/Csharp/HelloWorld/HelloWorld.aspx
� http://msdn.microsoft.com/en-us/library/aa581778.aspx
37
� http://www.codeproject.com/KB/webforms/
� http://weblogs.asp.net/scottgu/archive/2006/01/17/435765.aspx
� http://searchwindevelopment.techtarget.com/tip/0,289483,sid8_gci1278180,00.html
� http://msdn.microsoft.com/fr-fr/library/ms178093.aspx
� http://msdn.microsoft.com/en-us/library/ms972429.aspx
� http://www.syncfusion.com/FAQ/aspnet/WEB_c24c.aspx
� http://quickstarts.asp.net/QuickStartv20/aspnet/Default.aspx
� http://www.dotnetspider.com/tutorials/
� http://www.codersource.net/codersource_dot_net.html
38
GLOSSAIRE
.NET : Le framework .NET est un composant de Windows et constitue un équivalent de
la machine virtuelle.
2-tiers : L’architecture 2-tiers est composée de deux couches : Le client lourd
comprenant l’interface et le traitement et le serveur de données.
3-tiers : L’architecture 3-tiers est composée de trois couches : Le frontal (navigateur
internet), le serveur d’application (HTTP) et le serveur de données.
Access : SGBDR propriétaire développé par Microsoft. Dispose d’un runtime gratuit
permettant l’exécution d’applications Access.
Accordéons : Contrôle permettant de « zoomer » sur une zone. Par défaut les éléments
d’un accordéon sont tous réduit.
ACID : Atomic Consistent Isolated Durable. Ensemble de propriétés garantissant que
des transactions sur une base de données sont fiables.
Ajax : Asynchronous Javascript and XML. Solution de développement libre pour le
développement d’applications web. Permet d’envoyer des requêtes au serveur pour
récupérer que les données nécessaires en utilisant la requête http XMLHttpRequest. Le
langage JavaScript côté client est utilisé pour interpréter la réponse et faire les
traitements en conséquence. Permet une meilleure réactivité des applications du fait de
la quantité réduite des échanges optimisés.
Algorithme : Suite d’opérations logicielles permettant de résoudre un problème.
Algorithmique : Lié à un algorithme.
Apache : Serveur de base de données open-source.
Applet : Application côté client s’exécutant sur le navigateur web. Utilise le langage
Java dont le code est inclus dans le code html. Langage précompilable.
ASP : Langage de programmation objet de haut niveau. Développé par Microsoft.
Destiné au développement web dynamique. La nouvelle version d’ASP, ASP.NET
intègre la plateforme .NET.
ASP.NET : Langage de programmation objet de haut niveau développé par Microsoft.
Destiné au développement web dynamique. Utilise le framework .NET.
39
Bande passante : Abus de langage. Désigne un débit d’informations.
Barre de navigation : voir Breadscrumb.
bas niveau : Un langage de bas niveau impose au programmeur de se soucier de
concepts proches de la machine. Permet une gestion précise des détails, mais augmente
le niveau de difficulté lors d’élaboration d’applications conséquentes.
Base de données relationnelle : Base de données structurée satisfaisant aux principes
de l’algèbre relationnelle. Les données apparaissent comme stockées dans des tables
qu’on peut mettre en relation.
blister cart : Support cartonné sur lequel une forme plastifiée et collée maintient un
article de vente.
Bogue : voir Bug.
Boîtes spéciales : boîtes sortant du standard ECMA.
Boîtes : boîtes standards dont chaque élément est référençable à l’aide du code ECMA.
Borland : Editeur de logiciels.
Breadscrumb : Dans une application web, élément de navigation permettant à
l’utilisateur de savoir sur quelle page il est actuellement.
Bug : Erreur au niveau d’un logiciel.
C# : Langage objet de haut niveau. Développé par Microsoft. Langage compilé.
C++ : Langage objet de haut niveau. Langage compilé.
Cartonnier : Entreprise fabriquant et vendant du carton.
Classes : Une classe déclare des propriétés communes à un ensemble d’objets.
Client léger : En anglais, « thin client ». Désigne une application accessible via une
interface web consultable à l’aide d’un navigateur web. La totalité de la logique est
traitée côté serveur.
Client lourd : « fat client » ou « heavy client », en anglais. Par opposition au client
léger, désigne une application cliente graphique exécutée sur le système d’exploitation
de l’utilisateur. Un client lourd possède généralement des capacités de traitement
évoluées et peut possèder une interface graphique sophistiquée.
Client : Application ou système qui accède à des données situées sur un serveur.
code-behind : Permet la séparation du fond et de la forme en matière de pages web
dynamiques. Le code-behind constitue la partie dynamique.
40
CodeGear : IDE RAD développé par Borland et récement racheté par Embarcadero
Technologies.
Contrôles : Objet logiciel permettant de remplir un ensemble de fonctionnalités.
DataSets : Ensemble de données permettant de travailler en mode déconnecté.
DataView : Structure d’affichage de données. Contrôle web permettant de générer un
affichage personnalisé des données à partir de tables de la base de données.
DBMS : Ensemble de programmes permettant la gestion et l’accès à une base de
données. Les fonctions d’un SGBD sont : ajout de données, mise à jour des données,
recherche de données.
DeadLocks : Processus se produisant lorsque deux processus légers s’attendent
mutuellement. La seule solution à l’interblocage est de se prévenir de ce risque.
Débogage : voir Debug.
Debug : To debug. Supprimer des erreurs logicielles.
Déclencheurs : voir Trigger.
Devisage : Action de réaliser un devis.
Deviseur : Personne chargée du devisage.
Diagramme de classes : Schéma utilisé en génie logiciel pour représenter des classes et
interfaces d’un système ainsi que les relations entre celles-ci.
DropDownList : Contrôle utilisé dans les fenêtres d’application. Liste déroulante.
Eclipse : IDE multiplateformes. Permet de développement sous de nombreux langages
tels que C, C++, Java, Ruby, Perl et d’autres.
ECMA : Code de standardisation permettant de classifier des cartons en fonction de
leur formes et pliages.
Elément : Un élément est un composant constituant tout ou partie d’un produit. Type
d’élément : Un type d’élément correspond à un ensemble d’éléments ayant des
caractéristiques identiques.
Embarcadero Technologies : Editeur de logiciel.
Etuis : synonyme de boîtes standards.
Evénement : Une action réalisée par l’utilisateur sur un contrôle peut générer un objet
événement capable d’exécuter une méthode.
41
frais d’établissement : Frais divers et périphériques induits par la production d’un
produit.
Framework : Espace de travail modulaire. Ensemble de bibliothèques et d’outils
permettant le développement et l’exécution d’applications .NET.
Gamme : Liste des phases successives de la fabrication d’un produit.
GIS : Geographic Information System. Synonyme de Geomatics. Représente des objets
du monde réel tels que routes, utilisation de terres.
GlassFish : Serveur de base de données open-source développé par Sun Microsystems.
GridView : Grille d’affichage de données. Contrôle web permettant de générer des
grilles de données à partir de tables de la base de données.
haut niveau : Un haut niveau de programmation permet au programmeur de s’abstraire
de détails inhérents au fonctionnement de la machine. Permet de manipuler des concepts
plus élaborés, mais empêche la gestion de certains détails.
HTML : HyperText Markup Language. Format de données conçu pour représenter les
pages web.
IDE : Intergrated Development Environment. Environnement de développement
logiciel.
IIS Internet Information Server : Serveur de base données développé par Microsoft.
Serveur gratuit.
Indexages : Fait d’utiliser des indexes.
Indexes : Un index de base de données est une structure de données améliorant la
vitesse des opérations sur une table.
Instance : Une instance d’une classe d’un objet est une occurrence de l’objet considéré.
Intégrité des données : Cohérence des données d’une base de données.
Interblocages : voir DeadLocks.
Java : Langage objet de haut niveau. Développé par Sun Microsystems. Langage
précompilé.
Java Server Page : voir JSP.
JavaScript : Langage de programmation de scripts orienté objet à prototype. Langage
côté client utilisé en programmation web.
42
JDBC : Java DataBase Connectivity. Interface permettant la communication entre des
clients de bases de données et des SGBD du marché.
JSP : Java Server Page. Langage objet de haut niveau. Destiné au développement web
dynamique. Met en jeu le langage Java. Développé par Sun Microsystems. Langage
précompilable.
Langage compilé : Langage dans lequel le code d’un programme est traduit en langage
binaire directement compréhensible par le processeur.
Langage de bas niveau : Langage de programmation proche du langage machine. En
dépit du fait que ce langage est un langage peu élaboré et donc moins évident à mettre
en oeuvre, il permet d'être plus précis notamment en ce qui concerne les opérations
relatives au matériel.
Langage de haut niveau : Langage de programmation proche du raisonnement humain.
Ce langage libère le programmeur de l'implémentation des structures conditionnelles.
Un langage de haut niveau est plus facilement implémentable.
Langage de programmation : Un langage de programmation répond à une syntaxe
donnée et à des commandes données. Les langages de programmation se déclinent en
différents niveaux.
Langage interprété : Langage de programmation non compilé, nécessitant une
compilation au moment de l’exécution. Par conséquent, ce langage est moins
performant qu’un langage compilable et même pré-compilable.
Langage semi-interprété : Pour exécuter un langage semi-interprété, un interpréteur
doit fonctionner sur la machine d’exécution. Le code intermédiaire s’appelle pseudo-
code. Langages semi-interprétés : Java, ASP.NET.
Langages interprétés : S’oppose au langage compilé. Un programme écrit en langage
interprété est converti en instructions directement exécutables par la machine au
moment de son exécution. Langages interprétés : PHP, Ruby, Perl, JavaScript.
Libre : Se dit d’un logiciel dont la licence est dite libre. Permet à chacun d’utiliser,
modifier, dupliquer, étudier, vendre un logiciel libre.
LINQ : Langage permettant de réaliser des requêtes sur une base de données.
Développé par Microsoft.
Listes déroulantes : voir DropDownList.
43
Listes : Structure de données permettant le stockage de données.
Logiciel exécutable : Correspond à un programme indépendant qui peut se lancer sans
l’aide d’un autre logiciel.
Machine virtuelle : Environnement d’exécution émulé sur une système d’exploitation
ne pouvant exécuter un programme nativement.
Maintenabilité : Capacité à pouvoir maintenir une application de manière cohérente et
à moindre coût.
Matière première : Constituant de base nécessaire à la fabrication d’un produit.
Méthodes : Fonction faisant partie de l’interface d’un objet.
Migration : Action de migrer.
Migrer : Passer d’un état existant d’un système d’information ou d’une application vers
une cible définie dans un projet ou un programme.
Modèle : Dessins du produit cartonné et de l’image à imprimer sur ledit carton.
Mono : IDE RAD basé sur la mise en œuvre de la machine virtuelle .NET.
Multiplateformes : Logiciel conçu pour fonctionner sur différents systèmes
d’exploitation.
MySQL : SGBDR développé par Sun Microsystems. Dispose d’une version libre.
NetBeans : IDE multiplateformes. Permet de développement sous de nombreux
langages tels que C, C++, Java, Ruby, Perl et d’autres. Offre une interface visuelle
avancée, notamment pour les JSP et les fenêtres Java.
Objet : Représente un concept, idée ou toute entité réelle, comme une voiture, par
exemple.
Objets cartonnés : Objets réalisés en carton. Résultent généralement d’un pliage et
collage.
Octet : Groupement de 8 bits. Exemple : 11010110. Ceci équivaut à la valeur 214, en
notation décimale (notation usuelle).
ODBC : Open DataBase Connectivity. Interface permettant la communication entre des
clients de bases de données et des SGBD du marché.
Open-source : S’applique aux logiciels dont la licence respecte les critères de Open
Source Initiative, c’est-à-dire, permettant l’accès au code source et la libre
redistribution. Distinct de Freeware.
44
Opération arithmétique : C’est une opération mathématique du type addition ou
soustraction ou multiplication ou division.
Oracle : SGBDR propriétaire développé par Oracle.
Page Maître : Page maître. Apporte une approche différente de construction des pages
web, tant sur le plan graphique que sur le plan de l’ergonomie. Défini une structure
commune et offre des éléments d’interface pour le site.
Pages web dynamiques : Pages web dont le contenu peut évoluer en fonction des
actions de l’utilisateur.
Paradigme objet : Style fondamental de programmation informatique. Fournit la vue
qu’a le développeur de son programme.
PHP : Langage web dynamique de haut niveau. La programmation dans ce langage ne
permet pas de distinguer le fond de la forme. Langage précompilable.
PLV : Publicité sur le Lieu de Vente. Matériel publicitaire souvent imprimé en
sérigraphie.
Portabilité : Capacité d’un logiciel de fonctionner sur différents environnements
d’exécution.
pré-maquette : Dessins du produit cartonné pour validation client.
Présentoirs publicitaires : voir PLV.
Pré-presse : Phase de préparation de l’impression offset d’une image.
Procédures stockées : Sous-routine mise à disposition des applications accédant à un
SGBDR.
Processeur : Constitue la partie « intelligente » d’un ordinateur ou tout autre appareil
programmable.
Programmation objet : Consiste en l’assemblage de briques logicielles appelées objet.
Programme tiers : Nous désignons par ces termes, tout programme écrit en langage
assembleur que l'utilisateur souhaite déboguer avec le débogueur que nous avons
développé.
Quantité : En ce qui concerne un devis, un devis répond à un nombre donné d’articles.
Un devis peut correspondre à une liste de quantité à lui tout seul.
RAD : Rapid Application Development. Se dit d’un IDE incluant une variété de
techniques destinées à permettre un développement rapide des applications.
45
Repeater : Répéteur. Contrôle web permettant de générer du code HTLM à l’aide d’une
source de données telle qu’une base de données ou l’instance d’un objet.
Répéteur : voir Repeater.
Réplication : Création et maintenance de diverses copies d’une même base de données.
L’ensemble des bases est gardé à jour par rapport à la base initiale.
Requêtes : Demande de traitement adressée soit à une base de données, soit à un
serveur.
Rollback : Opération consistant à remettre la base de données dans son état precedent.
Runtime : Moteur d’exécution permettant l’exécution d’un autre programme.
Séquences : Objet de base de données, au même titre qu’une table, vue, … Objet
contenant une suite d’entiers permettant de gérer des clef uniques dans des tables, avoir
un compteur à titre informatif, …
Sérialisation : Processus visant à encoder l’état d’une information qui est en mémoire
sous la forme d’une suite d’informations plus petites. Cette suite peut être utilisée pour
le transport et la sauvegarde.
Serveur : Application ou système qui fourni des données à des clients et répond à des
requêtes HTTP fournies par les clients.
Servlet : Association de serveur et de applet. Applications Java côté serveur. Langage
précompilable. Permet de générer dynamiquement des données à un navigateur web
client.
Session : Session de communication est un échange semi-permanent et interactif
d’information entre deux machines.
SGBD : voir DBMS.
SGBDR : Désigne un SGBD Relationnel, c’est-à-dire, dont la base de données est de
type relationnelle.
Sitemap : Fichier de configuration des ressources proposées sur un site web.
Skins : Support cartonné sur lequel un film plastifié thermocollé maintient un article de
vente.
SQL Server : SGBDR propriétaire développé par Microsoft. Dispose d’une version
libre, SQL Server Express 2005.
SQL Server 2005 Express : Version gratuite du SGBDR développé par Microsoft.
46
SQL Server Express : SGBDR développé par Microsoft.
SQL : Langage permettant de réaliser des requêtes sur une base de données. Langage
libre.
SUN Microsystems : Constructeur d’ordinateurs et éditeur de logiciels.
Tabulations : Onglet d’une application informatique.
Transactions : Unité d’action réalisée sur une base de données.
Trigger : Code procédural exécuté automatiquement en réponse à certains événements
sur une table donnée d’une base de données.
VbScript : Langage de programmation de scripts orienté objet à prototype. Langage
côté client utilisé en programmation web.
View : Table virtuelle ou logique résultant d’une requête sur une base de données.
Visual Basic : Langage objet de haut niveau. Développé par Microsoft. Langage
compilable.
Visual Studio 2008 : IDE RAD développé par Microsoft permettant de développer en
divers langages tels que C, C++, C#, ASP, Visual Basic, ASP.NET, Visual Basic.NET,
… Dispose d’une version gratuite, Visual Studio 2008 Express.
Vues : voir View.
Windows Application : Application fenêtre. Relatif à une architecture 2-tiers ou client
lourd.
47
RÉSUMÉ
Une application client-serveur, à la différence d’une application indépendante induit
des difficultés supplémentaires. L’assemblage de technologies hétéroclites de par leur
nature et leur niveau d’action implique une bonne coordination ainsi qu’une
interopérabilité optimale. La symbiose de cet ensemble résulte d’une étude dont la clef
de voûte est une analyse conceptuelle précise. Le développement informatique consiste
respectivement à utiliser au mieux les solutions « standard » garantes de la pérennité de
la solution et des délais, et à développer des applications spécifiques en usant au mieux
des normes, langages et interfaces standards du marché. La réussite d’un projet résulte
par conséquent de nombreux facteurs dont un judicieux compromis est de rigueur.
Analyse conceptuelle, interopérabilité, compromis, standards,
spécificités, pérennité.
ABSTRACT
Structural architecture choices constitute the heart of any software. While a
heavy client application is more convenient for interfacing, a thin client software best
suits a multi-user usage. A client-server application implies more complexity than a
standalone application. On these initial choices will depend future issues. The
combination of heterogeneous technologies from different functional levels should
never result from a hasty decision. A global view and a sharp conceptual approach is the
key to optimized solutions and effectiveness. There are two complementary approaches
to development. Using turnkey solutions, which assumes the lasting quality of the
solution and effectiveness, and developing specific applications using more standards as
possible.
heterogeneous technologies, client-server, effectiveness,
standards, specificity.
MOTS CLÉFS
KEYWORDS
48
ANNEXE TECHNIQUE
49
Fig. A1 : Organigramme de production
A1 / Phases de production des produits
50
A2/ Organigramme des étapes de la mise en production
Demande de prix du client
Analyse des besoins et
création d’une étude
Etablissement d’une
pré-maquette par le
Etablissement d’un Bon A Découper (BAD)
propre au volume du cartonnage
Etablissement d’un Bon A Tirer (BAT)
propre au graphisme du cartonnage
Validation client ?
Devisage
Carton standard ?
Lancement des approvisionnements en
matière première (feuilles de carton)
Validation du cromalin ?
Production du
cartonnage,
impression offset et
logistique
Suite
Suite Début
Fin
Fig. A2 : Organigramme de mise en production
Validation client ?
Validation client ?
OUI
OUI
OUI
OUI
OUI
NON
NON
NON
NON
Lancement de la prépresse (étude du cadrage image avec le
volume cartonné, définition des méthodes pantone ou
quadrichromie, sous-traitance des films)
51
A3/ Formulaires généraux de saisie du type d’élément
Les formulaires ci-dessous constituent les formulaires permettant de renseigner
les informations intrinsèques des types d’éléments.
Fig. A3 : Ecrans de saisie traitement,
surface et gamme
52
A4/ Formulaires de saisie du type d’élément par quantité
Les formulaires ci-dessous constituent les formulaires permettant de renseigner
les informations relatives à la quantité d’éléments à produire.
Fig. A4 : Ecrans de saisie
disposition et frais
53
A5/ Diagramme des cas d’utilisation général
Fig. A5 : Diagramme des cas d’utilisation général
54
A6/ Diagramme des cas d’utilisation du logiciel
Fig. A6 : Diagramme des cas d’utilisation du logiciel nouveau et existant
55
Fig. A7 : Diagramme de Séquence du logiciel
A7/ Diagramme de Séquence du logiciel
56
Fig. A8.1 : Page d’accueil
Fig. A8.2 : Page Etude
A8/ Etude d’un cas concret avec la nouvelle application
Le lancement de l’application
ouvre la page d’accueil à partir de
laquelle, l’utilisateur a accès à
différentes pages de configuration. Il
peut aussi choisir de restaurer un
devisage archivé, imprimer, modifier,
…
Généralement, le deviseur choisit de faire un nouveau devis. Il choisit le numéro
d’étude (liste de
choix, voir flèche)
et valide à l’aide
du bouton
« Valider ».
S’affichent alors la
désignation et
description
(voir flèche).
57
Fig. A8.3 : Page Variante
A présent, l’utilisateur se voit questionné sur le nombre d’éléments, le code
standard de la boîte, les quantités à deviser. Comme le montre la figure, il est possible
de d’ajouter et de supprimer des quantités à deviser.
58
Fig. A8.4 : Page
éléments,
dimensions
Fig. A8.5 : Page éléments, Gammes
La valdation de la page de la variante, permet de sélectionner la page des éléments. Où
l’utilisateur peut saisir les informations qu’il souhaite dans l’ordre désiré. Il bénéficie
d’une vision globale des éléments tout en pouvant parfaitement accéder au détails.
L’illustration ci-dessous montre que les accordéons offrent des possibilités avancées
telles que
l’édition de
gammes (ou
matières
premières).
59
APPENDICE DES ILLUSTRATIONS
Fig. I.2.a : De gauche à droite : Etui et boîtage spécial ……………….. 7
Fig. I.2.b : De gauche à droite : Objets, PLV, blister cart et skin pack … 7
Fig. II. : Page d’accueil de l’application actuelle de devisage …………. 9
Fig. II.1 : Diagramme de Séquence général ……………………………. 9
Fig. II.2 : application client-serveur 2-tiers ……………………………. 10
Fig. II.3.b : modélisation du parcours de saisie des informations ……… 11
Fig. II.3.d.1 : Ecran de sélection ECMA et nombre …………………… 12
Fig. II.3.d.2 : Ecran 1 de saisie de l’élément 1 …………………………. 13
Fig. II.3.d.3 : Ecran 5 de saisie de l’élément 1 ………………………….. 13
Fig. II.1.a : Modèle d’architecture fonctionnelle de l’architecture 2-tiers 16
Fig. II.1.a.1 : Modèle d’architecture technique de l’architecture 3-tiers … 16
Fig. V.1.a.2 : Diagramme des cas d’utilisation …………………………… 23
Fig. V.1.b : Diagramme de classes du logiciel ……………………………. 24
Fig. V.3.1 : Page Etude …………………………………………………… 25
Fig. V.3.2 : Page des Eléments …………………………………………… 26
Fig. A1 : Organigramme de production ……………………………….. … 49
Fig. A2 : Organigramme de mise en production ……………………….… 50
Fig. A3 : Ecrans de saisie traitement, surface et gamme ………………. 51
Fig. A4 : Ecrans de saisie disposition et frais …………………………... 52
Fig. A5 : Diagramme des cas d’utilisation général …………………….. 53
Fig. A6 : Diagramme des cas d’utilisation du logiciel nouveau et existant 54
Fig. A7 : Diagramme de Séquence du logiciel ………………………… 55
Fig. A8.1 : Page d’accueil …………………………………………..…… 56
Fig. A8.2 : Page Etude……………………………………..………..…… 56
Fig. A8.3 : Page Variante……………………………………………..…… 57
Fig. A8.4 : Page éléments, dimensions………………………………..…… 58
Fig. A8.5 : Page éléments, Gammes……………………………………..…… 58
60
RÉSUMÉ
Une application client-serveur, à la différence d’une application indépendante induit
des difficultés supplémentaires. L’assemblage de technologies hétéroclites de par leur
nature et leur niveau d’action implique une bonne coordination ainsi qu’une
interopérabilité optimale. La symbiose de cet ensemble résulte d’une étude dont la clef
de voûte est une analyse conceptuelle précise. Le développement informatique consiste
respectivement à utiliser au mieux les solutions « standard » garantes de la pérennité de
la solution et des délais, et à développer des applications spécifiques en usant au mieux
des normes, langages et interfaces standards du marché. La réussite d’un projet résulte
par conséquent de nombreux facteurs dont un judicieux compromis est de rigueur.
Analyse conceptuelle, interopérabilité, compromis, standards,
spécificités, pérennité.
ABSTRACT
Structural architecture choices constitute the heart of any software. While a
heavy client application is more convenient for interfacing, a thin client software best
suits a multi-user usage. A client-server application implies more complexity than a
standalone application. On these initial choices will depend future issues. The
combination of heterogeneous technologies from different functional levels should
never result from a hasty decision. A global view and a sharp conceptual approach is the
key to optimized solutions and effectiveness. There are two complementary approaches
to development. Using turnkey solutions, which assumes the lasting quality of the
solution and effectiveness, and developing specific applications using more standards as
possible.
heterogeneous technologies, client-server, effectiveness,
standards, specificity.
MOTS CLÉFS
KEYWORDS
61
