VECTALIS - 19, rue Reaumur - 75003 Paris / +33.175.000.520 / www.vectalis.comCopyright 2011
le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 2
Le framework DSETA
LA CIBLE
VECTALIS SHARING DATA Le framework DSETA Page 3VECTALIS SHARING DATA Page 3
Cible 1 : le prototypage
Besoins
Architecte
Prototype
Utilisateurs
Le framework DSETA permet à un architecte de systèmes client-serveur de réaliser des prototypes fonctionnels successifs du système complexe qu’il doit concevoir.
La rédaction du cahier des charges est réduite à un minimum ; dans certains cas favorables, elle devient même inutile.
Y a-t-il de meilleures approches que la réalisation de prototypes pour valider les besoins des utilisateurs ?
Aucune programmation n’est requise et la réalisation de ces prototypes fonctionnels est très rapide.
Comment se rendre compte des enjeux que représente le nouveau système pour un coût qui serait inférieur au développement d’un prototype fonctionnel issu de la technologie DSETA ?
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 4
Applis serveur & clientes génériques
VECTALIS SHARING DATA Page 4
Cible 2, cas 1 : cas très favorable
Système Client-Serveur
Prototype fonctionnel
Utilisateurs
Admin
Dans le cas très favorable où :
1) les performances des applications clientes et serveur génériques fournies au sein du framework Dseta sont suffisantes,
2) l’Architecte a réussi à mettre en œuvre toutes les fonctionnalités requises grâce au framework DSETA.
3) les utilisateurs finaux peuvent se contenter d’utiliser les applications clientes génériques,
le prototype final peut être mis facilement en production par un administrateur-système et donc utilisé immédiatement par les utilisateurs.
Ces développements type « commando » peuvent s’avérer particulièrement intéressants pour des grosses structures où les processus décisionnels sont forcément complexes.
Dans un tel cas, il est surement très difficile d’obtenir un tel système client-serveur pour un coût moindre et un temps de développement plus court.
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 5
Coding des Client & Server Add-ons
VECTALIS SHARING DATA Page 5
Cible 2, cas 2 : cas favorable
Applis serveur et clientes génériques
Système Client-Serveur
Prototype fonctionnel
Utilisateurs
Adminn informaticiens C# peu expérimentés
Dans le cas favorable où :
1) les performances des applications clientes et serveur génériques fournies au sein du framework Dseta sont toujours suffisantes,
2) mais, contrairement au cas précédent, le système nécessite impérativement :
a. des GUIs spécifiques pour les utilisateurs,b. des traitements complexes au niveau des
données ,c. ou bien une intégration informatique
particulière dans l’environnement
une petite équipe d’informaticiens C# (peu expérimentés) peut finaliser le système par l’ajout de ‘Client Add-ons’ (sur l’application cliente générique) et de ‘Serveur Add-ons’ (sur l’application serveur générique).
Les ‘Client Add-ons’ servent notamment à construire des GUIs spécifiques de façon conventionnelle à base de composants graphiques du commerce.
Les ‘Server Add-ons’ sont facilement programmables par abonnement aux événements exposés par le ‘TypedNodeset’ généré grâce au framework DSETA.
C#
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 6
Système Client-Serveur
VECTALIS SHARING DATA Page 6
Cible 2, cas 2 : cas défavorable
Utilisateurs
Prototype fonctionnelDans le cas défavorable où les performances des applications cliente et serveur génériques fournies au sein du framework Dseta sont insuffisantes :
1) plus de 50 modifications par secondes, 2) plus de quelques centaines d’utilisateurs
connectés,
le système client-serveur doit être entièrement développé selon une méthodologie traditionnelle par une importante équipe d’informaticiens très expérimentés.
Le framework DSETA
AdminN informaticienstrès expérimentés
VECTALIS SHARING DATA Le framework DSETA Page 7VECTALIS SHARING DATA Page 7
Vue d’ensemble
Besoins des utilisateurs
Système client-serveur
Architecte
Admin
‘N développeurs’
Prototype fonctionnel
Applis serveur & clientes génériques
Système client-serveur
Applis serveur et clientes génériques Système client-serveur
Client & Server Add-ons
?‘n développeurs C#’
Utilisateurs
avec n << N
C#
VECTALIS SHARING DATA Le framework DSETA Page 8VECTALIS SHARING DATA Page 8
Le framework DSETA
DESCRIPTION
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 9VECTALIS SHARING DATA Page 9
Applis génériques + Règles
Le framework DSETA est fondé sur l’utilisation de deux logiciels Client et Serveur préexistants et génériques qui travaillent de concert.
Ces deux logiciels se configurent grâce à des Règles de fonctionnement lors de leur démarrage.
Ces Règles de fonctionnement sont éditées par l’architecte du système.
Elles sont stockées en mode fichier pendant le développement et en base de données lorsque la production est lancée.
Lors de leur première connexion, les applications-clientes génériques reçoivent les règles définissant le système du serveur auquel elles se connectent.
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 10VECTALIS SHARING DATA Page 10
Appli-cliente générique (GUI)
L’appli-cliente générique apparait à l’utilisateur avec:- sur la partie gauche, un ‘Arbre’ qui lui permet
d’explorer des données auxquelles il a le droit d’accéder, et
- sur la partie droite :1. soit une ’Grille de données’ si plusieurs
données ont été choisies dans l’Arbre, 2. soit une ‘Vue des propriétés’ si une seule
donnée a été choisie sur la partie gauche.
L’architecte a tout loisir de décider du contenu et de la forme de l’Arbre, type d’utilisateurs par type d’utilisateurs. Les grilles de données et les vues des propriétés sont très largement personnalisables.
Interface utilisateur génériqueExplorateur de données
Grille de données
Vue des propriétés
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 11VECTALIS SHARING DATA Page 11
Appli-cliente générique (fonctions)
Mode « Fichier » => Factory
Envoi des modifications
Réception automatique des modifications en provenance du serveur.
Communication avec le Serveur
Client Add-onsInterfaces-utilisateurs graphiques dédiées
Traitements spécifiques au niveau du client
En plus de sa fonction d’interface-utilisateur générique décrite à la slide précédente, l’application-cliente générique assure également les fonctions suivantes :
1. La communication des données avec le serveur en émission et en réception. Cette communication est automatique.
2. l’application-cliente générique devient la Factory (l’outil de développement du framework DSETA) lorsque l’architecte l’utilise en mode ‘Fichier’ (au lieu du mode ‘Connecté au serveur’) pour y saisir les règles de fonctionnement du système.
3. l’application-cliente générique peut être améliorée par le rajout de Client-Add-ons, notamment pour proposer des interfaces graphiques spéciales ou des traitements sur les données en local sur le poste des clients.
Le framework DSETA
C#
VECTALIS SHARING DATA Le framework DSETA Page 12VECTALIS SHARING DATA Page 12
L’application-serveur générique
Expose les Web Services génériques (logins + modifs de données).
Vérifie que l’utilisateur a le droit de faire sa modification (Authorisation).
Serveur Add-ons Traitements spécifiques sur le Serveur
Authentifie l’utilisateur voulant modifier une donnée.
Diffuse la modification à tous les utilisateurs (Broadcast).
Vérifie que l’utilisateur a bien accès à la donnée modifiée (Scoping).
Exécute les traitement sur les données (Business Logic),
Assure la rémanence des données dans la base de données SQL.
Envoie ses données à un client se connectant (Login full ou delta).
Le framework DSETA
C#
VECTALIS SHARING DATA Le framework DSETA Page 13VECTALIS SHARING DATA Page 13
Les Règles de fonctionnement
Les Règles de fonctionnement sont éditées par l’architecte. Elles définissent le fonctionnement des applications génériques clientes & serveur pour les aspects suivants :
1. la structure des données,
2. les droits d’accès des utilisateurs,
3. les traitements applicatifs sans programmation,
4. l’esthétique des GUIs génériques.
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 14
Un exemple de modélisation d’une structure de données :
Product
VECTALIS SHARING DATA Page 14
Structure de données
ByAir
Supplier
Customer
Shipment
ByBoat
Proposal
Discovery
Trade
User
Role
Les Tables sont « typées » selon leur hiérarchie de nommage :
Les Tables en 1-N sont jaunes.Les Tables en 1-1 sont oranges.Les Tables en N-M sont bleus.Les Tables en N-1 sont vertes.
Les Relations sont « typées » en rouge pour les relations participant au nommage hiérarchiques et en bleu pour les relations n’y participant pas.
DSETA permet de faire de l’héritage multi-dimensionnel ; les Relations peuvent être contraintes par l’héritage en commun entre la Table-parente et de la Table-enfant.
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 15
Un exemple des Chemins de découverte :
Product
VECTALIS SHARING DATA Page 15
Accès aux données par les utilisateurs
ByAir
Supplier
Customer
User
Shipment
ByBoat
Proposal
Discovery
Trade
Role
Chaque type d’utilisateurs (appelé ‘Rôle’) découvre les données qui lui sont accessibles en suivant ses ‘Chemins de découvertes’ qui sont définis par l’architecte (flèches violettes).
Les Chemins de découverte doivent impérativement suivre les Relations définies au niveau de la structure des données.
Pour chaque Table découverte, l’architecte doit définir si ce type d’utilisateur peut faire ou non : Insert, Update et Delete.
Les Chemins de découverte sont utilisés par le serveur pour calculer le Login, le Scope et la Broadcast.
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 16
Modifications-sortantes
Evénement-entrant :
VECTALIS SHARING DATA Page 16
Business Logic
Table source Colonnes source
INSERT DELETE UPDATE
Abonnement à l’événement-entrant
Modifications-sortantes Table-cible
Modification-sortante (DELETE)
Modification-sortante (UPDATE)
Modifications-sortante n° 1
Modification-sortante (INSERT)
Expression donnant les Records à supprimer.
Expression donnant les Records à modifier.
Expressions donnant les Records-parents pour le nommage ainsi que les valeurs des Keys. Expressions donnant les Records-parents
qualifiants ainsi que les valeurs des colonnes qualifiants.
Des traitements sur les données peuvent être définis par l’architecte sans programmation (Business Logic).
L’architecte peut définir sur chaque modification de type : Insert, Update, ou Delete sur une donnée-source (ou bien le clic sur un bouton) le déclenchement d’une modification de type : Insert, Update, Delete sur une autre donnée-cible.
Cette «programmation symbolique » utilise des Expressions en syntaxe-Objet.
Abonnement à l’événement
La Business Logic est réentrante : le déclenchement d’une modification d’une donnée-cible peut lui-même déclencher d’autres modifications, ce qui permet de définir des traitements complexes et structurés.
condition d’exécution (Expression)
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 17VECTALIS SHARING DATA Page 17
Esthétique des applis-clientes génériques
Définition de styles pour la représentation des valeurs des Colonnes.
Définition de styles pour les labels des nœuds de l’Arbre.
Définition d’icônes pour représenter les nœuds de l’Arbre.
Styles conditionnels pour les valeurs des Colonnes.
Styles conditionnels pour les labels des nœuds de l’Arbre.
Icônes conditionnelles pour les nœuds de l’Arbre.
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 18VECTALIS SHARING DATA Page 18
Le TypedNodeSet
Application-serveur générique
Server Add-ons
Applis-clientes génériques
Client Add-ons
A chaque version de structure de données, l’architecte peut lancer la génération d’un système de Classes fortement typées représentant l’ensemble des Tables du système ainsi que les Relations qui les relient. Ce système de Classes se nomme le TypedNodeSet.
Au niveau de l’application-cliente générique, il est possible d’utiliser le TypedNodeSet pour, par exemple, rajouter des interfaces graphiques à la demande.
Au niveau de l’application-serveur générique, il est possible d’utiliser le TypedNodeSet pour programmer des traitements sur les données très complexes en s’abonnant aux événements exposés par les objets typés.
Accès à toutes les bibliothèques Microsoft .NET.
Le framework DSETA
C# C#
TypedNodeSet TypedNodeSet
VECTALIS SHARING DATA Le framework DSETA Page 19VECTALIS SHARING DATA Page 19
Le framework DSETA
MISE EN OEUVRE
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 20VECTALIS SHARING DATA Page 20
Le service autour de DSETA
Si le client le sollicite, Vectalis peut détacher un de ses architectes pour l’aider à créer le prototype de son système client-serveur (2000 €/jour).
Vectalis peut également détacher des informaticiens C# pour développer des Client et/ou Server Add-ons (1500 € / jours environ).
Lorsque l’Architecte est satisfait du rendu applicatif qu’il a obtenu en local dans sa Factory, VECTALIS lui offre la possibilité de rentrer immédiatement et gratuitement en test de pré-production en installant ses Règles sur un de ses serveurs de test prévus à cet effet.
Grâce à cette option, l’Architecte va pouvoir faire la démonstration de son système dans des conditions réelles d’utilisation à travers Internet, soit à ses décideurs, soit à ses utilisateurs finaux.
Vectalis Vectalis
Vectalis peut également aider ses clients pour l’installation de leur Serveur (1500 € / jours environ).
Architecte Développeurs C#
Vectalis
Administrateur
Le framework DSETA
Vectalis
www.the-framework-dseta.com
VECTALIS SHARING DATA Le framework DSETA Page 21VECTALIS SHARING DATA Page 21
Exemple de prototypage : B2S
B2S (pour ‘Bank Sell-Side’) est un système informatique interne à une banque émettrice de produits structurés financiers. Cet outil permet à son département du Front-Office de gagner en productivité pour tout ce qui concerne les étapes de la vie des produits structurés financiers émis.
Les caractéristiques de ce projet sont :
- 1 Architecte pendant 4 mois. - 7 types d'utilisateurs. - 190 Tables-maîtres (1-N, N-M). - 230 Tables-extensions (1-1, N-1). - 1200 Colonnes. - 420 Formes. - 1300 modifications-sortantes (BL).
Le coût de licence DSETA pour un système de la complexité de B2S serait d’environ 3000€ par mois pour 25 utilisateurs.
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 22VECTALIS SHARING DATA Page 22
Exemple de système : SPm
Le service SPm est un service Internet privatif dédié aux Produits Structurés entre, d’une part, les banques émettrices (le Sell-side) et, de l’autre, les entités financières qui négocient et gèrent ces Produits Structurés pour le compte des investisseurs finaux (le Buy-side).
Pour le système SPm, ont été développés :- des interfaces graphiques dédiées
s’adaptant parfaitement aux besoins des 3 types d’utilisateur,
- un traitement spécial au niveau du serveur pour la recherche de produits.
Ce développement a nécessité, pendant 9 mois, 1 architecte et 3 développeurs C#, sachant que la complexité de ce projet est équivalente à celle du projet B2S.
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 23VECTALIS SHARING DATA Page 23
Le framework DSETA
CONCLUSION
Le framework DSETA
VECTALIS SHARING DATA Le framework DSETA Page 24VECTALIS SHARING DATA Le framework DSETA Page 24
Positionnement stratégique
Avantages :
- Développement fondé sur un prototypage successif. - Les solutions produites sont facilement évolutives. - Rapidité de mise en œuvre. - Équipe réduite à un architecte (voire quelques informaticiens). - Consistance liée à l’utilisation de programmes génériques. - Coût faible et gradué.
Limitations :
- Intérêt restreint à une certaine typologie de systèmes : - client lourd fondé sur Microsoft .NET, - broadcast temps-réel, etc. - Architecture non-scalable.- Limité à quelques centaines d’utilisateurs connectés max. - Performance limitée à 50 modifications par seconde environ.