Accueil Nouveautés Sommaire

Les composants réglementaires

La démarche Notions de base Composants de base Analyses Le glossaire

Remonter

 

Version du 30 09  2013

Présentation. 1

Une solution de type cadriciel 1

Les composants réglementaires. 1

Les composants objectifs. 1

Les composants dispositifs. 1

Le chargeur de composants réglementaires. 1

L’organisation des données. 1

 


Présentation

Objectifs

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.

 

Résumé

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.

 

 

Une solution de type cadriciel

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,

 

Présentation

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.

 

Les points de variation

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.

 

Les éléments du cadriciel associés à un processus fonctionnel

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).

 

Le contexte de mise en œuvre

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).

 

 

Les principes de réalisation

Une mise à disposition adaptée aux traitements réglementaires

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 d’un composant (objectif, dispositif ou paramètre)

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

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,


Les composants réglementaires

Contexte d’utilisation

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 réglementaire d’un composant

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

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,

 

Caractéristiques générales des composants réglementaires

Présentation

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,

 

Période d’application d’un composant réglementaire

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).

 

Version d’un composant réglementaire

La version d’un composant réglementaire correspond à la période pendant laquelle il a un comportement stable.

 

Nom générique, nom contextuel et nom versionné d’un composant

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.

 

Les relations entre composants objectifs et composants dispositifs ainsi que leurs différentes versions relèvent du système déclaratif de l’application.

 

 

Les composants objectifs

Présentation

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.

 

Versions d’un 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.

 

Éléments complémentaires

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.

 


Les composants dispositifs

Présentation

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.

 

Le nom contextuel d’un composant dispositif est son nom générique suffixé par le numéro de version correspondant à sa période d’application. Un composant dispositif est compilé sous son nom versionné.

 

Période d’application d’un composant dispositif

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.

 

Versions d’un composant dispositif

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).

 

Organisation des composants dispositifs

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.

 


Le chargeur de composants réglementaires

Présentation

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.

 

Les éléments de la mise en œuvre

Présentation

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 suivi des composants activés

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.

 

Les versions des composants

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écuter un composant objectif

Conditions d’appel

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

 

 

Exécuter un composant dispositif de deuxième niveau

-- 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

 

Exécuter le composant dispositif associé à un événement

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) }

 

L’organisation des données

Présentation

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).

 

Contextes locaux

Rôles des contextes locaux

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.

 


Persistance des contextes locaux

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)

 

Historique des contextes locaux sauvegardés

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.

 

Contexte global

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),