Version du 30 09 2013
Une
solution de type cadriciel
Le
chargeur de composants réglementaires
Les composants réglementaires s’inscrivent dans le processus de mise en œuvre des traitements.
Les objectifs visés induisent des principes de réalisation basés sur :
· une architecture des processus fonctionnels, de type cadriciel capable de déterminer le corps des règles à appliquer (à une date donnée),
· la mise à disposition d’un système de configuration dynamique des composants nécessaires à la réalisation des objectifs réglementaires.
· la définition d’un certain nombre de standards de programmation,
· le privilège accordé à la structure des traitements (l’ordre dans lequel les traitements doivent être exécutés) par rapport à leurs modalités de résolution,
· la séparation des aspects techniques et des aspects réglementaires,
· l’isolation des traitements réglementaires par type de prestation et par règlements applicables,
· la séparation des données (contextes locaux), et des traitements (composants dispositifs),
· l’externalisation des constantes et des énumérations dans les implémentations des dispositifs réglementaires,
Les considérations qui suivent
· tirent parti des notions de base et de la démarche d’analyse,
· concernent essentiellement les processus fonctionnels d’attribution du droit, de constitution du droit et de consommation du droit.
Le document présente :
· les principes d’architecture liés à la solution de type cadriciel,
· les caractéristiques des composants réglementaires au regard de l’architecture retenue,
· le chargeur de composant, boîte noire dont le rôle est la mise à disposition dynamique des composants
· l’organisation des données
Une nomenclature des éléments réglementaires participants aux applications est fournie.
On retient une solution de type cadriciel afin
· de minimiser les risques présentés par les changements de réglementation,
· d’optimiser le taux de réutilisation,
· d’améliorer la maintenabilité,
· d’externaliser, dans le cadre d’un système déclaratif, le plus grand nombre d’éléments,
Un cadriciel (framework) est une structure conceptuelle de base, un squelette d’application, un cadre structurel à partir duquel on peut construire une application.
Un cadriciel définit un cadre de développement ; il facilite la conception des applications par l'utilisation de bibliothèques de classes ou de générateurs de programmes.
Dans un cadriciel, les points de variation (ou d’extension) représentent des situations prédéfinies de la structure d’accueil en vue de la personnalisation et l’adaptation des traitements au contexte d’appel.
L’organisation d’un cadriciel associé à un processus fonctionnel distingue :
· la structure d’accueil ; elle est insensible aux réglementations : elle concerne les aspects techniques et définit l’ordre de prise en compte des points de variation,
· les points de variation ; ils sont associés aux seuls objectifs réglementaires ; ils concernent la mise à disposition des dispositifs réglementaires nécessaires à la date d’application demandée.
Le caractère invariant du nom des objectifs réglementaires et des dispositifs réglementaires garantit la stabilité et la pérennité de la structure d’accueil.
Pour assurer le niveau de stabilité maximal de la structure d’accueil, il est nécessaire qu’elle puisse proposer un système dynamique de mise à disposition des composants réglementaires (le chargeur de composants réglementaires).
Une nouvelle réglementation, dans un type de prestation donné, reconduit la majorité des dispositifs réglementaires :
· tout est identique à la précédente réglementation,
· sauf pour quelques dispositifs réglementaires.
Cette même architecture se retrouve, pour une convention d’Assurance chômage, entre le règlement général, et un règlement annexé.
Dans ces deux situations, on constate en effet :
· une grande stabilité des structures de résolution des objectifs et des dispositifs réglementaires,
· que deux implémentations d’un même dispositif réglementaire, devant être mis en œuvre dans deux réglementations successives, peuvent être considérées comme identiques si elles ne diffèrent que par la valeur de leurs paramètres (externalisation des constantes et des énumérations).
La caractéristique des traitements à prendre en compte est qu’ils ne sont applicables que pour une période donnée ; cette caractéristique induit, pour le cadriciel, un système de mise à disposition dynamique des traitements et des paramètres demandés.
Ce système s’appuie sur :
· le contexte réglementaire,
· la date d’application demandée.
Le contexte règlementaire est récupéré à partir du contexte global.
Le contexte d’appel tient compte :
· du Régime de prescription,
· du type de prestation,
· du règlement applicable, complété, éventuellement par l’identification d’une population particulière,
· de l’état du droit (significatif seulement pour le processus de consommation du droit),
La date d’application impose la version du composant ; elle correspond à :
· la date du fait générateur de la demande pour le processus d’attribution du droit,
· la date d’attribution du droit, pour le processus de constitution du droit,
· le jour à traiter pour le processus de consommation du droit,
Un traitement réglementaire n’est applicable que pour une période donnée ; cette caractéristique induit, pour le cadriciel, un système de mise à disposition dynamique des traitements applicables à une date donnée.
Ce système s’appuie sur :
· le contexte réglementaire,
· la date d’application demandée.
Le contexte d’un composant réglementaire définit sa portée ; il correspond :
· au Régime de prescription,
· au type de prestation,
· au règlement applicable, complété, éventuellement par l’identification d’une population particulière,
· à l’état du droit (significatif seulement pour le processus de consommation du droit),
Ces informations sont récupérées du contexte global du processus fonctionnel.
La date d’application permet la recherche du composant applicable ; la période d’application du composant retenu doit inclure la date d’application.
La date d’application correspond à :
· la date du fait générateur de la demande pour le processus d’attribution du droit,
· la date d’attribution du droit, pour le processus de constitution du droit,
· le jour à traiter pour le processus de consommation du droit,
Les composants réglementaires sont regroupés par contexte réglementaire ; on distingue :
· les composants « objectifs » déclarent :
· les noms des dispositifs réglementaires de « premier niveau » dans l’ordre de leur exécution,
· le nom du composant contexte local (variables susceptibles d’être partagées entre les différents dispositifs réglementaires) associé,
· le nom du composant paramètre (constantes et énumérations) associé,
· les composants « dispositifs », correspondent à des composants logiciels exécutables. Un composant dispositif peut lui-même faire appel à d’autres composants dispositifs,
Un composant réglementaire a un comportement stable pour une période d’application. Pendant cette période, le composant a « un comportement constant ». Deux composants réglementaires sont identiques s’ils obéissent aux mêmes modalités de résolution, aux constantes et aux énumérations près ; leurs périodes d’application, si elles sont jointives, peuvent alors être réunies.
La période d’application peut, alors, correspondre à la durée de vie d’une réglementation particulière, couvrir plusieurs réglementations successives ou couvrir seulement une partie de la vie d’une réglementation (en cas de changement de comportement d’un dispositif réglementaire).
La version d’un composant réglementaire correspond à la période pendant laquelle il a un comportement stable.
Par construction, un composant réglementaire est exécuté dans la version en cours à la date d’application demandée.
On distingue :
· le nom générique, celui qui apparaît dans les analyses réglementaires ; c’est le nom sous lequel la structure d’accueil fait appel à lui ; il contient, dans leur ordre d’exécution, les noms contextuels de ses versions successives.
· le nom contextuel, nom générique postfixé par une chaine de caractères reflétant le contexte réglementaire du composant,
· le nom versionné, nom contextuel postfixé par un numéro de version ; c’est le nom du composant soumis à la compilation ; il est associé à la période d’application (à sa version) du composant.
Le nom générique d’un composant objectif est celui qui apparaît dans les analyses réglementaires ; c’est le nom sous lequel la structure d’accueil fait appel à lui.
Une version d’un composant objectif contient, dans leur ordre d’exécution, les noms versionnés des composants dispositifs qui le composent. Les composants dispositifs peuvent indifféremment relever :
· du même contexte réglementaire (cas général),
· d’un autre contexte réglementaire (cas de la réutilisation d’un autre dispositif),
· d’un traitement généralisé.
La demande d’exécution d’un composant objectif se fait par son nom générique accompagné de la date d’application.
Les éléments du contexte réglementaire, permettant la production du nom contextuel de l’objectif réglementaire, sont récupérés à partir du contexte global du processus fonctionnel.
La date d’application permet la détermination du nom versionné du composant objectif.
Une nouvelle version du composant objectif apparaît seulement si la composition (ou l’ordre d’exécution) des composants dispositifs est modifiée.
On associe à un composant réglementaire :
· le composant paramètre,
· le composant contexte local.
Le composant paramètre permet l’accès à tous les paramètres nécessaires à la réalisation des composants dispositifs contenus dans le composant objectif.
Le composant contexte local permet l’accès à toutes les informations nécessaires à la réalisation du composant objectif.
Ces deux composants sont versionnés ; leur durée de vie est découplée de celle du composant objectif.
Le nom générique d’un composant dispositif est celui qui apparaît dans les analyses ; c’est le nom sous lequel les composants réglementaires font appel à lui.
Par construction, un composant dispositif est réputé stable tant qu’aucune modification n’intervient dans son comportement (au constantes et aux énumérations près).
La période d’application peut :
· ne couvrir qu’une partie de la vie d’une réglementation, si un changement de modalité de résolution intervient en cours de réglementation,
· chevaucher plusieurs réglementations, si deux dispositifs réglementaires obéissent aux mêmes modalités de résolution, aux constantes et aux énumérations près.
Une nouvelle version d’un composant dispositif apparaît seulement si son comportement a été modifié, aux paramètres près (constantes et/ou énumérations).
Un composant dispositif est l’unité d’exécution correspondante à la version à appliquer du dispositif réglementaire.
Un composant dispositif obéit à des contraintes d’architecture; il peut :
· être appelé dans le cadre de la réalisation d’un objectif réglementaire,
· être appelé à partir d’un composant dispositif englobant,
· ou être déclenché par un événement du processus de consommation du droit,
· il implémente l’interface Commande,
· il contient ses conditions d’activation,
· il peut utiliser et renseigner les données appartenant au contexte local du composant objectif,
· il retourne en séquence, à la fin de son exécution,
· il appelle, par leur nom contextuel et la date d’application souhaitée, les composants dispositifs qu’il sollicite.
L’objectif est de produire une boîte noire dont le rôle est de mettre à disposition de la structure d’accueil du processus fonctionnel, pour un contexte réglementaire spécifique et pour une date donnée, l’ensemble des composants réglementaires nécessaires à la réalisation de chacun de ses objectifs réglementaires.
Trois types de requêtes peuvent solliciter le chargeur :
· l’exécution d’un objectif réglementaire,
· l’exécution d’un dispositif réglementaire, appelé par un dispositif réglementaire,
· l’exécution d’un dispositif réglementaire associé au déclenchement d’un événement.
Le chargeur de composants doit gérer aussi des fonctions techniques de type :
· mécanisme de libération sélective, en situation de prévision de dépassement de capacité, de la place des composants
· suivi statistique des composants sollicités.
La mise en œuvre s’apparente à la gestion d’une mémoire cache ; elle s’organise autour des éléments suivants :
· la gestion dynamique des composants activés,
· la connaissance des versions (et de leurs période d’application) des composants associés à la réalisation de l’objectif réglementaire.
Le registre des composants objectifs activés contient les noms contextuels des composants objectifs sollicités et chargés.
Une entrée du registre contient :
· le nom générique de l’objectif,
· le régime de prescription,
· le nom de la prestation,
· le règlement applicable,
· le règlement applicable effectif (en cas de réutilisation d’un composant),
· facultativement, le nom d’une population particulière du règlement applicable,
· pour le processus de consommation du droit, le nom d’un état,
Le registre des composants dispositifs de premier niveau contient, par version du composant objectif activé, les noms versionnés des composants nécessaires à la réalisation de l’objectif.
Une entrée du registre contient, pour une version du composant objectif :
· la liste (dans l’ordre où ils doivent être pris en charge) des noms versionnés des composants dispositifs,
· le nom versionné du composant contexte local associé à l’objectif,
· le nom versionné du composant paramètre associé à l’objectif,
· pour les composants dispositifs, le rang d’exécution.
Le registre des « autres » composants dispositifs activés contient, par objectif activé, les noms génériques des composants dispositifs activés.
Le registre des versions des composants objectifs contient, par composant objectif :
· le nom versionné composant objectif,
· la période d’application
Le registre des versions des composants dispositifs contient, par version du composant objectif :
· le nom versionné du composant dispositif,
· la période d’application.
Ce registre contient aussi les informations concernant le composant contexte local et le composant paramètre.
exécuterObjectif(
string nomGénériqueDeLObjectif,
Damj dateDApplication)
Produire le nom contextuel de l’objectif
-- à partir du contexte global du processus fonctionnel
Activer le composant objectif
Précondition
Le nom du composant objectif n’a pas été activé
-- absent du registre des composants objectifs
Action
Activer le nom du composant objectif
-- ajout du nom au registre des composants objectifs activés
Activer la version du composant objectif
Précondition
La version du composant objectif n’a pas été activée
-- absente du registre des versions des composants objectifs
Action
Déterminer la version du composant objectif
-- version dont la période d’application contient la date d’application
Récupérer la liste des dispositifs réglementaires
-- à partir du registre des composants dispositifs
Charger les composants dispositifs de premier niveau
Pour chaque composant dispositif non activé
Charger le composant dispositif
Exécuter les composants dispositifs de premier niveau
Pour chaque élément de la liste
Exécuter l’élément
Retourner
-- un dispositif réglementaire de deuxième niveau est un dispositif réglementaire appelé par un dispositif amont
exécuterDispositif(
string nomGénériqueDuDispositif
Damj dateDApplication)
Produire le nom versionné du dispositif
-- à partir du contexte global du processus fonctionnel et de la date d’application
Activer le composant dispositif
Précondition
le nom du dispositif n’a pas été activé
-- absent du registre des composants dispositifs activés
Action
Activer le composant dispositif
-- ajout du nom au registre des composants dispositifs activés
Exécuter le composant dispositif
Retourner
Les événements implémentent l’interface Déclenchable, dont le rôle est :
· d’assurer la communication avec le chargeur, si le traitement à déclencher est susceptible d’évoluer avec le temps,
· d’effectuer le transfert, vers le contexte local associé, de l’information contenue dans l’événement.
cas : événement de changement de réglementation ou
événement d’examen du droit
{exécuterDispositif(nomGénériqueDeLEvénement, dateDApplication)}
cas : événement d’examen du droit
cas : événement de changement d’état
{exécuterDispositif(nomGénériqueDeLEvénement, dateDApplication, état)}
-- le dispositif appelé met à disposition les composants associés au nouvel état
cas : événements du calendrier d’indemnisation ou du plan d’indemnisation
{récupérer la référence du contexte local associé à l’objectif concerné et en cours à la date d’application demandée
transférer l’information spécifique contenue dans l’événement vers le contexte local}
cas : événement de suivi
{exécuterDispositif(nomGénériqueDeLEvénément, dateDApplication) }
Alors que le point de vue des objectifs réglementaires et des dispositifs réglementaires reflète les traitements, le point de vue des données est concrétisé par les notions :
· de contexte local, ensemble des données nécessaires à la réalisation d’un dispositif réglementaire,
· de contexte global. ensemble des éléments assurant la communication avec les autres processus fonctionnels (amont et aval).
Un contexte local a pour vocation :
· le regroupement et l’isolation de l’ensemble des données nécessaires, à une date donnée, au traitement du dispositif réglementaire auquel il est associé,
· le découplage entre la gestion des données (mise à disposition des données, conditions d’activation, par exemple) et l’exécution du traitement,
· l’intégration et l’unification du traitement des sous populations et des cas particuliers définis au sein d’un même dispositif réglementaire,
· l’isolation des traitements des dispositifs réglementaires,
· la restauration des informations de l’état précédent du droit suite à une interruption temporaire du processus de consommation du droit,
· l’optimisation des procédures de reconstitution ou de reconduction de l’état d’un processus fonctionnel tributaire d’éléments susceptibles de se modifier avec le temps :
· niveaux de consommation de données évoluant avec les retours de l’actualisation,
· étapes d’une procédure administrative (saisines de la Commission paritaire, par exemple).
Un contexte local peut contenir les données nécessaires à un ou à plusieurs dispositifs réglementaires.
Un contexte local est associé à une version d’un objectif réglementaire.
Les contextes locaux sont sauvegardés en fonction de leurs possibilités de reconstitution à une date donnée :
· les contextes locaux des processus de liquidation ne sont pas persistants, s’ils ne contiennent que des informations issues d’objets-métier,
· les contextes locaux contenant des éléments évolutifs, doivent être sauvegardés, les sauvegardes peuvent alors de faire :
· à fréquence régulière (la fin de mois civile, par exemple) pour des contextes locaux contenant des éléments évoluant avec les retours de l’actualisation (contexte local « Droit » du processus de consommation du droit, par exemple). Dans ce cas, les situations intermédiaires ne sont pas prises en compte (sauvegarde à une date),
· à la prise d’effet de chaque nouvelle occurrence du contexte local, pour des contextes locaux contenant des éléments dont le rythme de modification est peu fréquent (contexte local « Allocation » du processus de consommation du droit. ou contexte local contenant des informations reflétant l’état d’une procédure administrative). Dans ce cas, la situation au moment de la prise d’effet est reconduite jusqu’à le veille de prise d’effet de la sauvegarde suivante (sauvegarde pour une période)
Un historique des états successifs d’un contexte local doit être géré dès lors qu’une remise en cause des résultats du processus fonctionnel est envisageable.
La date d’effet de la remise en cause est le lendemain de la plus récente sauvegarde précédant ou égale à la date d’effet de la modification.
La restauration réinstalle les contextes locaux actifs à la date d’effet déterminée pour la remise en cause.
Un contexte associé au processus fonctionnel, le contexte global, est détenteur d’informations et de références susceptibles d’être partagées et d’assurer la communication entre tous les objectifs réglementaires et tous les dispositifs réglementaires ; il contient en particulier, à une date d’application donnée :
· le nom du processus fonctionnel,
· le nom du régime de prescription,
· le nom du règlement applicable,
· la liste des objectifs activés,
· pour chaque objectif activé :
· la référence de son contexte local
· la référence de son composant paramètre,
· l’état du droit (pour le processus de consommation du droit),