Le framework dseta pro fr

VECTALIS - 19, rue Reaumur - 75003 Paris / +33.175.000.520 / www.vectalis.comCopyright 2011

le framework DSETA

VECTALIS SHARING DATA Le framework DSETA

Le framework DSETA

LA CIBLE

VECTALIS SHARING DATA Le framework DSETA VECTALIS 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


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


Coding des Client & Server Add-ons


Cible 2, cas 2 : cas favorable

Applis serveur et clientes génériques



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




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


Vue d’ensemble

Besoins des utilisateurs

Système client-serveur

Architecte

Admin

‘N développeurs’


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#


Le framework DSETA

DESCRIPTION

Le framework DSETA


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


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


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#


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#


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


Un exemple de modélisation d’une structure de données :

Product


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


Un exemple des Chemins de découverte :

Product


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


Modifications-sortantes

Evénement-entrant :


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


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


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


Le framework DSETA

MISE EN OEUVRE

Le framework DSETA


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


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


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


Le framework DSETA

CONCLUSION

Le framework DSETA

VECTALIS SHARING DATA Le framework DSETA VECTALIS 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.

Le framework dseta pro fr

Technology

Transcript of Le framework dseta pro fr