urbanisation-si.com

Comment faire pour signifier aux autres briques logicielles, que l'état d'une entité métier a changé  ? 

Classiquement, une adhésion à un contrat peut être fermée de manière rétroactive. Comment le communiquer au bloc applicatif prestation pour que celui-ci puisse clore le sinistre correspondant  ? 

La démarche d'urbanisation est une démarche fractale, on réapplique les concepts d'un niveau au niveau supérieur.

Par exemple, au niveau microscopique, les concepts objet fondamendaux comme l'encapsulation et la communication par messages se retrouvent au niveau macroscopique c'est à dire au niveau blocs fonctionnels ou applicatifs des cartographies correspondantes.

Appliquons ce principe au modèle de conception bien connu des concepteurs objet sous le nom de Design Pattern du GoF (Gang of Four, la bande des 4 génies, experts en concepts objet).

Un de ces modèles s'appelle l'Observateur. Avec un AGL comme Enterprise Architect on peut facilemet récupérer le squelette du diagramme de classe du pattern en faisant un glisser déposer à partir de la bibliothèque de patten du GoF, c'est ce qu'on a fait pour obtenir le diagramme de classe ci-dessus.

Encore un truc technique issu de "teckausses autistes" me direz-vous ?

Surtout pas de préjugés, les experts métiers auraient beaucoup à y gagner en s'inspirant de modéles de conception qu'ils pourraient adapter et appliquer à leurs problématiques métiers.

Mais alors en mots simples, de quoi s'agit-il ?

Les entités (ConcreteObserver sur le diagramme de classe) devant être informées d'éventuels changements d'une autre doivent avoir un comportement d'"Observateur" (Observer ou encore Listener). Elles s'abonnent aux entités à observer (ConcreteSubject) qui doivent avoir elles, un comportement de "Sujet" (Subject).

Le comportement "Sujet" (le terme technique est interface ou classe abstraite) doit pouvoir  ajouter et supprimer des entités de type "Observateur" de sa liste  d'abonnés (nommée "observers" sur la relation "Subject" vers "Observer"). De plus, il doit pouvoir notifier (notify) tous ses  abonnés en leur transmettant un évènement comprenant le sujet et ce qui a  changé dans son état. Pour se faire, le sujet envoie un message (update) à tous ses abonnés, dans lequel se trouve l'émetteur du message (le ConcreteSubject) et son nouvel état.

Un abonné (ConcreteObserver) reçoit l'évènement (le message), il sait quelle est l'entité émettrice, ce qui a changé dans son état et peut donc modifier son état en conséquence.

Cette gestion évènementielle peut se faire en temps réel ou bien en différé en rendant persistant l'évènement (par exemple en le stockant dans une base de données).

Revenons à notre problème de départ ou une adhésion est fermée de manière rétroactive ce qui doit modifier les prestations postérieures à cette date de fermeture. 

Avec cette solution, le gestionnaire sera averti dans son écran que l'adhésion a été fermée rétroactivement et que cela à impacter un certain nombre de prestations (qui ont été par exemple annulées et se retrouvent en régularisation si elles ont été payées).

De même, un batch de régularisation des prestations pourra récupérer tous les évèvement émis par l'adhésion pour ses abonnés de type Prestation  et aura toutes les informations nécessaires à la régularisation.

Notre vie serait peut être transformée, s'il existait des patterns de solutions à des problèmes types de notre existence ? Y-a-t'il seulement une personne qui y a réfléchi ?

"J'ai toujours rêvé d'un ordinateur qui soit aussi facile à utiliser qu'un téléphone. Mon rêve s'est réalisé : je ne sais plus comment utiliser mon téléphone."

Bjarne Stroustrup

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/