GE.02-30194 (F) 280202 280202 Distr. GÉNÉRALE CES/SEM.47

Distr.
GÉNÉRALE
CES/SEM.47/18 (Summary)
17 janvier 2002
FRANÇAIS
Original: ANGLAIS
COMMISSION DE STATISTIQUE et
COMMISSION ÉCONOMIQUE
POUR L’EUROPE
COMMISSION DES COMMUNAUTÉS
EUROPÉENNES
CONFÉRENCE DES STATISTICIENS
EUROPÉENS
EUROSTAT
Séminaire commun CEE-Eurostat sur les systèmes
intégrés d’information statistique et les questions
connexes (ISIS 2002)
(Genève, Suisse, 17-19 avril 2002)
Thème III: Technologies orientées objet et architectures à composants
LES ORIENTATIONS ADOPTÉES EN MATIÈRE D’ARCHITECTURE
À STATISTICS NETHERLANDS
Communication sollicitée
de Statistics Netherlands1
Résumé
1.
L’accent placé récemment sur les processus a incité Statistics Netherlands à mettre au point
des applications moins nombreuses mais plus amples. Les moyens et la responsabilité en matière
de conception de ces applications sont principalement entre les mains des divisions de
statistique. La division centrale de technologie intervient dans le cas de projets spéciaux ou
lorsqu’il faut remédier à un manque de capacités.
2.
Statistics Netherlands a choisi un environnement logiciel Microsoft avec Visual Studio et
COM+ mais sans Transactionserver. L’importation ou l’achat privés de logiciels ne sont pas
autorisés car il en résulterait des problèmes de continuité. L’utilisation de bases de données
(serveur SQL) est encouragée, tout comme l’emploi du moteur OLAP.
1
Élaborée par Marton Vucsan ([email protected]).
GE.02-30194 (F) 280202 280202
CES/SEM.47/18
page 2
3.
L’architecture logicielle est influencée non seulement par l’environnement de
développement dans lequel elle s’inscrit, mais aussi par le logiciel normalisé créé à Statistics
Netherlands. Ce logiciel est de plus en plus souvent disponible sous forme de d’ensembles de
composants. Parallèlement à cette évolution, on notera la mise au point d’un nouveau type de
logiciel intermédiaire, Cristal, composant d’arbre de classes offrant une E/S normalisée dans une
structure de mémoire statistique avec des composants de chargement/déchargement standard.
4.
Les directives principales en matière d’architecture logicielle sont l’utilisation d’une
architecture multiniveau et de composants, qu’ils soient normalisés ou non. La réutilisation du
code, en particulier sous forme de composant, est encouragée.
5.
La gestion des composants, en particulier lorsqu’elle est centralisée, s’avère difficile. Il est
peu aisé d’assurer la maintenance et la continuité nécessaires sans mettre en place un projet de
maintenance, etc., ce qui décourage le déploiement central de petits composants. En raison de la
liaison dynamique d’exécution de COM+, on ne peut éviter «l’enfer des DLL» («DLL Hell»)
qu’en attribuant de nouveaux identificateurs aux composants modifiés ou corrigés.
6.
L’utilisation de composants est de plus en plus courante, car ceux-ci sont davantage axés
sur l’exécution de fonctions statistiques complexes. Les expériences antérieures de partage de
code se sont avérées décevantes car les composants ou les morceaux de code réutilisés étaient
pour la plupart petits et très techniques. En général, les responsables de projet créent eux-mêmes
ces petits éléments de logiciels eux-mêmes.
7.
On peut recenser trois sources de composants. Premièrement, à l’échelle locale, deux
applications ou plus peuvent partager le même code, qui est alors transformé en composant.
Deuxièmement, un logiciel normalisé peut comprendre des éléments qui méritent d’être
disponibles séparément. Enfin, un nouveau processus ou une nouvelle théorie méthodologique
peuvent déboucher sur la création d’un composant.
-----