Designer et l`ingénierie du logiciel

Designer et l’ingénierie du logiciel
Notions élémentaires
P.-A. Sunier, ISNet Neuchâtel avec le concours de C. Kohler et P. Ferrara
1
Propos liminaires............................................................................................................................................. 1
1.1
Objectifs de publication .......................................................................................................................... 1
1.2
Genèse..................................................................................................................................................... 2
1.3
Version de Designer utilisée ................................................................................................................... 2
2 Notions élémentaires....................................................................................................................................... 3
2.1
Introduction............................................................................................................................................. 3
2.2
Présentation succincte de Designer ......................................................................................................... 3
2.3
Nos choix de mise en œuvre de Designer ............................................................................................... 4
2.3.1
Postulat de base ............................................................................................................................... 4
2.3.2
Cadre méthodologique .................................................................................................................... 4
2.3.3
Cible de génération.......................................................................................................................... 5
2.3.4
Démarche méthodologique.............................................................................................................. 5
2.4
Fonctionnalités de Designer par phase.................................................................................................... 6
2.4.1
1ère phase – Définition d’un projet................................................................................................... 6
2.4.2
2ème phase – Modélisation conceptuelle des données (MCD) ......................................................... 6
2.4.3
3ème phase - Transformation des objets de niveau conceptuel en objets de niveau logique............ 7
2.4.4
4ème phase – Enrichissement du modèle logique de données (MLD) .............................................. 8
2.4.5
5ème phase - Scripts SQL DDL ..................................................................................................... 10
2.4.6
6ème phase – APIs de tables ........................................................................................................... 11
2.4.7
7ème phase – Test de l’intégrité de la structure de données............................................................ 12
2.4.8
8ème phase – Modélisation logique des traitements (MLT)............................................................ 13
2.4.9
9ème phase – Test de l’application.................................................................................................. 15
3 Liens utiles .................................................................................................................................................... 17
3.1
Plus d’informations ............................................................................................................................... 17
3.2
Mise en pratique.................................................................................................................................... 17
3.3
Références............................................................................................................................................. 17
1 Propos liminaires
1.1
Objectifs de publication
Sous le titre général « Designer et le génie logiciel », nous publierons une série d’articles inspirés de nos travaux
de recherche appliquée menés au sein du centre de compétences « Systèmes d’information et informatique de
gestion » , dénommé ISNet, de la Haute Ecole Spécialisée de Suisse occidentale, abrégée HES-SO.
Nous n’avons pas l’ambition de nous substituer au constructeur Oracle et aux sociétés de conseils; nous ne
traiterons pas les subtilités du produit, de son installation, de son paramétrage, des différences entre les versions
mais nous nous concentrerons sur les aspects relevant de l’ingénierie du logiciel tels que la méthodologie, la
normalisation et la standardisation, la qualité des applications ou encore la réutilisation de tout ou partie de
projets ou sous-projets.
Article 1
- 1/17-
Août 2005
1.2
Genèse
Les bases de cette série d’articles découlent de notre projet de recherche appliquée ISNet-14 , « Atelier de génie
logiciel et génération Web ». Ce projet avait été initialisé en 1999 sur la base, entre autres, des considérations
suivantes :
• Le besoin de production de systèmes d’information aptes à répondre aux changements environnementaux
dans des délais de plus en plus courts et à des coûts maîtrisés peut probablement être satisfait en mettant en
place les concepts de l’ingénierie…
• Après la déconvenue des coûts cachés du poste client de l’architecture Client/Serveur, de nombreuses
organisations sont intéressées par la mise en place d’architectures à 3 niveaux. Le troisième niveau , le
serveur d’application, est censé accueillir de manière unifiée l’essentiel des ressources matérielles de
traitement qui sont hébergées dans chaque poste client de l’architecture Client/Serveur ; le poste client
redeviendrait une ressource matérielle légère…
A partir des considérations émises, nous retenions les principes suivants :
• Nous voulons explorer les voies de l’industrialisation et du déploiement d’applications dans une
architecture à multiples niveaux, composée de serveur(s) de données, serveur(s) d’application et de clients
universels sous forme de navigateurs Web.
• Pour satisfaire aux objectifs d’industrialisation, nous nous appuierons sur le concept de référentiel. Le
référentiel devra être partageable et pouvoir être alimenté par des outils graphiques de modélisation de
données et de traitements. Le référentiel devra contenir, d’une manière ou d’une autre, l’ensemble des
règles de gestion du système d’information à produire.
• Afin d’éviter toute erreur d’interprétation des spécifications lors de la production du logiciel des divers
niveaux, et pour satisfaire au but d’automatisation, nous nous servirons de générateurs de code. Les
générateurs devront nous permettre de générer le logiciel de chacun des niveaux indépendamment l’un de
l’autre mais, toujours à partir de la même base de spécification : le référentiel.
A partir des principes émis, nous retenions le choix stratégique suivant :
• nous nous appuierons sur un atelier de génie logiciel (AGL) du marché. L’AGL que nous retiendrons doit
satisfaire aux exigences que nous avons énoncées… de plus, il doit nous permettre de modéliser les données
et les traitements sous forme de vues organisationnelles, conceptuelles, logiques ou physiques. Pour
satisfaire aux objectifs d’intégration que nous nous sommes fixés, l’AGL choisi devra être homogène et
inclure toutes les fonctionnalités attendues sans devoir faire appel à des services externes. Si l’AGL est
propriétaire, les résultats qu’il fournira devront être exploitables selon les normes et standards existants.
A partir de ce choix stratégique, nous avions retenu l’AGL Designer de l’éditeur Oracle sur la base des
considérations suivantes :
• il nous permet de générer des scripts SQL de création de bases de données selon la norme ANSI, le standard
ODBC ou une syntaxe propre aux acteurs principaux du marché : IBM-DB2, SQL Server, Sybase, Oracle…
• il nous permet de générer les applications clientes dans le cadre d’une architecture à 2 niveaux sous forme
de code source C++ ou Visual Basic en plus de son format propriétaire Forms ;
• dans le cadre d’une architecture à 3 niveaux, il nous permet de générer la logique du serveur d’application
sous forme de code Java, LiveHTML, Perl ou PL/SQL. Le serveur d’application et les générateurs
respectent les standards HTML, CORBA et EJB.
1.3
Version de Designer utilisée
De manière générale, nous essayerons de nous attacher aux concepts ; de ce fait, la version de Designer n’est
pas essentielle. Une grande partie du contenu de nos articles s’applique aux versions anciennes 2.1.2, 6, ou 6i.
Nous utiliserons la version 9i de Designer, plus précisément 9.0.2, pour illustrer le début de cette série
d’articles. Si nous devions illustrer ou baser nos propos sur des éléments d’anciennes versions de Designer nous
le mentionnerons pour éviter toute confusion.
Article 1
- 2/17-
Août 2005
2 Notions élémentaires
2.1
Introduction
Cet article initial est consacré à la présentation des notions élémentaires de Designer dans une vision
d’ingénierie. Par ingénierie nous entendons une démarche méthodologique susceptible de favoriser la maîtrise de
la qualité, des délais et des coûts de production des logiciels.
Designer est un atelier de génie logiciel couvrant un large spectre des activités liées à l’informatisation des
systèmes d’information. Designer prend en charge les activités d’analyse, de conception et de génération de
code, tout en offrant des fonctionnalités de transformation entre niveaux d’abstraction, de documentation et
d’analyse de dépendance ; cette liste de fonctionnalités n’est pas exhaustive mais correspond, à notre sens, aux
fondements de Designer.
2.2
Présentation succincte de Designer
Dans une première approche simplifiée, nous pourrions définir Designer comme un couple formé d’une base de
données Oracle, nommée référentiel ou Repository, et d’une application exécutable dans un environnement
Windows ; l’application exécutable est nommée : client Designer.
• Le référentiel contient les spécifications du système d’information, sujet de notre analyse, conception et/ou
génération.
• Le client Designer regroupe les outils de modélisations, les générateurs et, sous forme d’utilitaires, les outils
d’édition de rapports, d’analyse d’impact ou encore de consultation du référentiel.
Figure 1 - Le référentiel et les outils de Designer (Aide en ligne de Designer 2.1)
La figure 1 montre le client Designer composé des outils de modélisation qui alimentent le référentiel et de
générateurs qui créent le code exécutable ou la documentation à partir du contenu du référentiel.
Article 1
- 3/17-
Août 2005
La figure 2 montre le panneau de commande des fonctionnalités du client Designer 9i sous Windows.
• Le groupe Model System Requirements regroupe les outils de modélisation de niveau organisationnel ou
conceptuel, dans le sens français du terme.
• Le groupe Transform Preliminary Designs regroupe les outils de transformation des modèles de données et
de traitements conceptuels en modèles logiques.
• Le groupe Design and Generate contient l’outil de modélisation logique ou de conception, dans le sens
anglophone du terme ; l’outil de modélisation, Design Editor, permet de concevoir les modèles logiques de
données et de traitements, mais également les modèles physiques de données.
• Le groupe Repository Tools contient les utilitaires d’édition de rapports, d’analyse d’impact, de consultation
et d’administration du référentiel.
Figure 2 - Panneau de commande de Designer 9i
2.3
Nos choix de mise en œuvre de Designer
2.3.1 Postulat de base
Nous nous sommes fixés comme contrainte de ne jamais retoucher le code généré par Designer, sauf dans le cas
très rare, mais existant, de correction d’un bug de générateur qui s’avèrerait fatal. Nous reviendrons plus en
détail, dans un prochain article, sur les solutions offertes par Designer pour personnaliser le code en tant que
spécifications en amont de la génération.
2.3.2 Cadre méthodologique
Dans un premier temps, nous limitons notre utilisation de Designer aux seules fonctionnalités qui nous
permettront d’atteindre, avec un maximum d’efficience, l’objectif de « génération de code dans un
environnement n-tiers » que nous nous sommes fixé . Nous avons arrêté le choix suivant :
Article 1
- 4/17-
Août 2005
•
•
•
au niveau de la modélisation organisationnelle ou conceptuelle, Model System Requirements, nous ne
retenons que l’outil de modélisation conceptuelle des données Entity RelationShip Diagrammer. La
modélisation des traitements ne débouchant pas ou peu sur des spécifications exploitables automatiquement
dans la suite du processus de conception et génération de logiciels nous ne la retenons pas ; par contre, la
modélisation des traitements fera l’objet d’un article futur.
nous retenons Database Design Transformer pour la transformation des modèles conceptuels de données en
modèles logiques ;
naturellement, nous retenons Design Editor pour la modélisation logique des données et des traitements,
ainsi que pour la génération des divers scripts exécutables, compilables ou interprétables.
2.3.3 Cible de génération
Nous créerons notre structure de données de test en nous limitant volontairement aux seules bases de données
Oracle. La génération des scripts SQL-DDL est paramétrable et permet de cibler les produits de différents
constructeurs ; mais les APIs de tables qui enrichissent les définitions normalisées SQL sont propriétaires et ne
s’appliquent qu’aux bases de données Oracle ou à d’éventuelles bases qui seraient compatibles au niveau des
paquetages PL/SQL et des triggers.
Plusieurs voies sont possibles pour générer des applications exécutables dans un environnement n-tiers comme
nous nous l’étions imposé pour notre projet de recherche appliquée ISNet-14. Parmi les possibilités offertes,
nous avons choisi la technologie Web PL/SQL d’Oracle.
2.3.4 Démarche méthodologique
Sur la base du cadre méthodologique retenu, nous avons défini une démarche méthodologique basée sur une
approche top/down. Nous proposons une méthodologie basée sur les différents niveaux d’abstraction de
modélisation des données; elle intègre les fonctionnalités de Designer à mettre en œuvre. Notre démarche
méthodologique est découpée en 9 phases.
1ère phase
2
ème
phase
Définition d’un projet
Modélisation conceptuelle des données (MCD)
3ème phase
Transformation des objets de niveau conceptuel en objets de niveau
logique
4ème phase
Enrichissement du modèle logique de données (MLD)
5
ème
phase
Génération et exécution des scripts SQL-DDL
6
ème
phase
Génération et exécution des scripts de création des APIs de tables
7ème phase
8
ème
phase
Test de l’intégrité de la structure de données
Modélisation logique des traitements (MLT)
Génération et exécution des scripts de création de modules
9ème phase
Test de l’application
Au chapitre suivant, nous allons montrer les fonctionnalités de Designer utilisées lors de ces différentes phases et
en donner une explication succincte. Dans nos prochains articles nous expliciterons ces fonctionnalités plus
complètement.
Article 1
- 5/17-
Août 2005
2.4
Fonctionnalités de Designer par phase
2.4.1 1ère phase – Définition d’un projet
Le navigateur de contenu du référentiel, Repository Object Navigator ou RON, permet de créer des
projets. Avec notre approche de Designer pour ce premier article, un projet correspond à une
application à développer.
Les projets, Application dans la terminologie Oracle, sont regroupés au sein d’espaces de travail, Workarea. Les
espaces de travail et projets permettent de partitionner le référentiel.
La figure 3 montre le projet
Ex_Garage dans l’espace de travail
Sunier.
Figure 3 - Projets et espace de travail
2.4.2 2ème phase – Modélisation conceptuelle des données (MCD)
Entity Relationship Diagrammer nous permet de créer nos modèles conceptuels de données. Les
modèles sont conçus selon un formalisme propriétaire. Les associations entre entités sont binaires ; les
cardinalités sont représentées graphiquement.
Figure 4 – MCD / Eléments et notation
Article 1
- 6/17-
Août 2005
2.4.3 3ème phase - Transformation des objets de niveau conceptuel en objets de
niveau logique
Database Design Transformer transforme nos objets conceptuels de modélisations des données en
objets logiques. Dans l’environnement de Designer, le modèle logique est de nature relationnelle,
selon la définition donnée par Codd ; les entités deviennent des tables, les associations deviennent
automatiquement des colonnes de clés étrangères, des contraintes de clés étrangères et des index …
Cette transformation est fortement paramétrable par le concepteur. Grâce aux possibilités de paramétrage
offertes, le concepteur peut effectuer de nombreux aller et retour entre les niveaux conceptuels et logiques sans
altérer le contenu des différents niveaux.
Figure 5 - Paramétrage de la transformation
La figure 5 montre les entités que l’outil de transformation a trouvées dans le projet ; dans le cas particulier, nous
pouvons observer que toutes les entités ont déjà donné lieu à une table.
En respectant la méthodologie que nous
préconisons, toute entité du modèle
conceptuel de données est associée à
une table du modèle logique de
données.
La figure 6 montre ce couplage, au
niveau du référentiel, entre entité et
table.
Figure 6 - Couplage entre entité et
table
Article 1
- 7/17-
Août 2005
2.4.4 4ème phase – Enrichissement du modèle logique de données (MLD)
Design Editor nous permet d’effectuer :
• la modélisation logique des données, sous forme de tables, colonnes, contraintes, etc
• la modélisation logique des traitements sous forme de modules, composants, etc.
Par la suite, nous parlerons de conception pour définir l’activité effectuée avec Design Editor, le terme de
conception doit être compris comme la traduction littérale du terme anglais « design » ; il n’y a donc pas de lien
à faire entre cette activité de conception et les modèles conceptuels qui eux réfèrent à un niveau d’abstraction.
Figure 7 - MLD /Eléments et notation
Conformément à la méthodologie que nous préconisons, nous ne créerons pas de tables comme nous le ferions
dans une vision de développement RAD (Rapid Application Development). Nous enrichirons les tables obtenues
par la phase précédente de transformation d’entités en tables. L’enrichissement portera sur des éléments comme
la traçabilité des manipulations de données des utilisateurs, l’automatisation de génération de clés primaires, la
dénormalisation, etc.
Si nous ne créons pas de tables au niveau logique, nous créons des objets, telles les séquences, qui n’existent pas
au niveau conceptuel.
Le modèle logique de données supporté par Designer est nommé Server Model. De notre côté, nous utiliserons
plutôt le terme de modèle relationnel.
Article 1
- 8/17-
Août 2005
La table GAR_CLIENTS de la figure 8 a
été créée par l’outil de transformation et
enrichie avec Design Editor alors que la
séquence GAR_CLI_SEQ a été créée
directement par Design Editor.
Figure 8 - Tables et séquences du modèle
relationnel
Article 1
- 9/17-
Août 2005
2.4.5 5ème phase - Scripts SQL-DDL
Le générateur de script SQL-DDL, Server Generator, n’est pas accessible depuis le panneau de
commande de Designer, il est accessible en tant qu’élément exécutable de l’outil de conception Design
Editor. Le générateur de script SQL-DDL utilise, en entrée, les spécifications contenues dans le modèle
relationnel, Server model, et génère, en sortie, un script respectant la norme SQL et/ou les spécificités d’un
constructeur, respectivement d’un produit.
Figure 9 - Générateur de script SQL-DDL
La figure 10 montre le script
généré pour la table
GAR_CLIENTS ; nous voyons
les colonness d’audit, préfixés
CTRL, que nous avons ajoutées
au moment de l’enrichissement
pour assurer une forme de
traçabilité.
Figure 10 - Script de création de
table
Article 1
- 10/17-
Août 2005
2.4.6 6ème phase – APIs de tables
Tout comme pour la génération des scripts SQL-DDL, le générateur d’APIs de tables, Server API,
utilise, en entrée, les spécifications contenues dans le modèle relationnel, Server model, et génère, en
sortie, des scripts sous forme de procédures stockées PL/SQL et de triggers. Les APIs de tables sont
une sur-couche propre à Oracle pour enrichir la sémantique mise en place par les scripts de définition de données
SQL-DDL. Les APIs de tables interceptent les ordres de manipulation de données et lancent l’exécution des
procédures stockées qui enrichissent les règles et contraintes mises en places par les scripts SQL-DDL.
Figure 11 – Couplage entre
ordres DML et APIs de
tables
Figure 12 - Procédure d'API de table
La figure 12 montre la procédure up_autogen_columns générée pour la table GAR_CLIENTS ; dans
l’extrait de code, nous voyons le calcul de la valeur de clé primaire à partir de l’interrogation de la séquence
GAR_CLI_SEQ.
Article 1
- 11/17-
Août 2005
2.4.7 7ème phase – Test de l’intégrité de la structure de données
Le but de cette phase est de s’assurer que les contraintes liées aux données soient effectivement
validées par le serveur de données. Pour ce faire, il faut effectuer tous les tests de manipulations de
données en passant par l’intermédiaire de SQL*Plus ou d’autres utilitaires de ce genre.
Il est essentiel de procéder rigoureusement à ces tests, car lorsque nous mettons en place une contrainte avec
Designer, nous pouvons définir l’endroit, serveur de données ou application cliente, où la contrainte doit être
vérifiée.
Figure 13 - Validation des contraintes
Dans le cadre d’un développement « manuel » d’une application nous implémentons les contraintes relatives aux
données sur la base de données ou au niveau du client, voire au niveau du serveur d’application. Souvent, nous
mettons des contraintes au niveau de l’application pour éviter tout trafic superflu sur le réseau. Toutefois, si nous
voulons garantir l’intégrité absolue des données, il est indispensable de réécrire ces contraintes au niveau du
serveur de données pour éviter une violation dans le cas où les données ne sont pas manipulées par l’application
« usuelle ». Tout concepteur rechigne à introduire cette redondance qui est contraire au principe d’unicité du
code. Avec Designer, nous résolvons élégamment cette problématique ; la contrainte n’est définie qu’une et une
seule fois dans le référentiel, mais elle peut être générée au niveau du serveur et de l’application. La génération
au niveau de l’application sous-entend naturellement que nous générons l’application avec Designer.
Article 1
- 12/17-
Août 2005
2.4.8 8ème phase – Modélisation logique des traitements (MLT)
Design Editor permet la conception « logique » des données sous forme de modèles relationnels mais
aussi de traitements sous forme de modules et composants.
Figure 14 - MLT / Eléments et notation
Designer permet de créer des modèles conceptuels de traitements sous forme de diagrammes d’analyse ou de
diagrammes de flux de données « DFD, Dataflow Diagram » ; les fonctions ou processus sont transformés, par
Application Design Transformer, en modules, tout comme les entités au niveau des données sont transformées,
par Database Design Transformer, en tables. Ensuite, ces modules peuvent être enrichis par Design Editor selon
un processus de conception proche de celui que nous avons décrit pour les données.
Toutefois, comme nous n’avons pas retenu cette possibilité dans notre choix méthodologique, nous créons les
modules, modèles de traitement logiques, directement avec Design Editor.
Les modules de Design Editor se partitionnent en composants. Un composant permet de « manipuler » une table
dite de base ; manipuler, dans le sens d’appliquer les opérations d’ajout, de modification ou de suppression. Une
table peut être associée à une ou plusieurs tables de références ; l’association est proposée automatiquement à
partir de la structure du modèle relationnel de données. Les composants peuvent être liés entre eux ; les liens
sont proposés à partir des relations existantes entre les tables de bases des composants respectifs.
Article 1
- 13/17-
Août 2005
2.4.8.1 Génération des modules Web PL/SQL
Lors de la conception d’un module, nous indiquons la
nature de la génération de code à produire par la
propriété Language. A partir du choix du langage de
génération, le concepteur disposera de propriétés
spécifiques à la cible choisie ; par contre, le concepteur
pourra toujours générer un module pour une cible
différente.
La figure 15 montre les différentes cibles possibles de
génération de module.
Figure 15 – Choix des générateurs de modules
Le concept des modules Web PL/SQL s’apparente aux pages JSP et servlets ; il s’agit de procédures aptes à
fournir des pages HTML dont le contenu est adapté dynamiquement à l’évolution des données manipulées. La
particularité de Web PL/SQL concerne la manière de stocker et d’exécuter les procédures ; les procédures sont
stockées sous formes de paquetages dans la base de données, elles sont exécutées sous forme d’invocation
distante s’apparentant à RMI.
Le générateur Web PL/SQL s’appuie sur plusieurs librairies ou paquetages installés dans la base de données cible
de la génération :
• la librairie HTML pour le Web d’Oracle, dénommée PL/SQL Web Toolkit ; pour l’essentiel, cette librairie
encapsule les balises HTML à l’intérieur de fonctions ou procédures PL/SQL ;
• la librairie du générateur Web PL/SQL, paquetages préfixés WSG, à partir de laquelle le contenu dynamique
des pages HTML est généré;
• les APIs des tables qui sont manipulées par les modules .
Figure 16 - Générateur Web PL/SQL
Article 1
- 14/17-
Août 2005
2.4.9 9ème phase – Test de l’application
Les modules générés sont testés à partir d’un
navigateur. Pour que les modules puissent
être exécutés via une adresse URL, il faut
disposer d’une passerelle qui convertisse
l’URL en une invocation de procédure
PL/SQL se trouvant dans une base de
données.
Figure 17 - Formulaire Web PL/SQL
Article 1
- 15/17-
Août 2005
2.4.9.1 Passerelle PL/SQL
La passerelle PL/SQL est
installée comme service du
serveur d’application Oracle ,
iAS. Cette passerelle doit être
configurée par un DAD,
Database Access Descriptor. Le
DAD permet de définir la base
de données qui doit être accédée
pour exécuter la procédure
PL/SQL qui retournera la page
HTML. Le DAD peut contenir
les éléments d’identification -utilisateur et mot de passe- et
de connexion à la base de
données pour offrir un service
public dans une vision Internet ;
sinon, les éléments
d’identification sont demandés à
l’utilisateurs et utilisés pour la
connexion à la base de données
pour offrir un service
« contrôlé » dans une vision
Intranet..
Figure 18 - Architecture n-tiers
Article 1
- 16/17-
Août 2005
3 Liens utiles
3.1
Plus d’informations
Si vous souhaitez plus d’informations, notre site consacré à Designer est à votre disposition. Le site Designer
contient plusieurs entrées ; nous n’avons pas encore publié de documents spécifiques à la version 9i, nos
documents les plus récents sont consacrés à la version 6i.
Le sous-site « Les bases » de la version 6i de Designer , et plus particulièrement le cahier « 01 – Prise en main »
traite des notion élémentaires présentées succinctement dans cet article.
3.2
Mise en pratique
Les notions que nous avons présentées dans cet article peuvent être mise en œuvre en suivant la partie pratique
du cahier « 01 - Prise en main » de notre sous-site « Les bases » de la version 6i de Designer.
3.3
Références
L’auteur
Pierre-André Sunier
[email protected]
HES-SO
Haute Ecole Spécialisée de Suisse occidentale
www.hes-so.ch
HEG-NE
Haute Ecole de Gestion de Neuchâtel
www.he-arc.ch
ISNet
Centre de compétences
Systèmes d’information et informatique de gestion
http://www.is-net.ch/
Génie logiciel
Articles du laboratoire de génie logiciel sous la rubrique
« Génie logiciel »
http://lgl.isnetne.ch/
Site Designer
Notre site de formation consacré à Designer et ses soussites
Projet de recherche appliquée ISNet-14
Atelier de génie logiciel et génération Web
http://lgl.isnetne.ch/designer6i
/index.htm
http://lgl.isnetne.ch/isnet14/in
dex.htm
Projet ISNet-14
Article 1
- 17/17-
Août 2005