Semaine 8.1 Flashcards
Qu’est-ce qu’un processus?
Un ensemble d’activités corrélées qui reçoit une entrée et produit une sortie, et ce pour une certaine finalité
Qu’est-ce qu’un processus métier?
Événement déclencheur
Des activités qui s’exécutent et se conforment à des règles qui conditionnent le passage d’une activité à une autre
Pour chaque activité, il y a un acteur (ou groupe d’acteurs) qui doit exécuter l’activité
Comment modéliser un processus métier?
L’ensemble des activités visant des valeurs ajoutées au sein d’un entreprise peut être spécifié en des processus métier => Importance de spécification de processus métiers
Spécification en modèles selon les langages de modélisation standardisé:
- BPMN : Business Process Modeling Notation et BPEL
- Autres : CEP (Complex Event Processing), ACM (Adaptive Case Management)
BPMN, BPEL, CEP et ACM permettent chacun d’exécuter leurs modèles (outillage)
Quel est le lien entre système informatique et processus métier?
Un système informatique (SI) d’une entreprise vise généralement à automatiser/informatiser partiellement ou complétement les processus métiers de l’entreprise => importance des processus métier pour le développement du SI
Une interaction entre une entreprise et son écosystème n’est autre qu’un processus qu’on qualifie de “e-business”
Modélisation de processus : On va se concentrer sur BPMN vu sa notoriété et son applicabilité non limitée à un type particulier de processus
Qu’est-ce que BPMN (Business Process Modeling Notation)?
BPMN est standardisé par OMG : un formalisme graphique normalisé complet, facile d’approche
- Formalisme : tout modèle BPMN correspond à une spécification textuelle formelle XML (normalisée et traitable par les machines)
Certains outils permettent la transformation automatique de tout modèle BPMN en modèle BPEL servant de définition d’orchestration de services d’une application composite dans le cadre SOA
Quelles sont les étapes de modélisation du processus métier?
Étape 1 : Identifier et modéliser les processus à partir des besoins des parties prenantes
Étape 2 : Analyse du processus pour
- Regrouper les activités => services fonctionnels
- Identifier les exceptions nécessitant intervention humaine
Étape 3 : La conception d’un modèle de processus exécutable
Quels sont les principes de modélisation de processus métier?
- Tout processus repose sur l’orchestration de services métiers dont la granularité ne doit pas être trop fine
- Un processus sans exception n’existe pas : le modélisateur doit, pour chaque activité du processus, se poser la question des exceptions possibles
- Un processus entièrement automatisé n’existe pas : la gestion des exceptions implique en général de “mettre l’homme dans la boucle”
- Un processus métier peut en cacher un autre (par exemple, un processus de recyclage des exceptions)
- Si un processus fait appel à un service externe à la solution métier dont ce processus fait partie, le fournisseur de ce service doit s’engager formellement sur la qualité de service (performances notamment)
- Si un processus risque de durer longtemps (à l’échelle humaine), il peut être nécessaire de (1) pouvoir assurer une mise à jour de l’état du processus après chaque activité effectuée et (2) permettre au client d’interroger l’état du processus via une application composite complémentaire
Qu’est-ce que le modèle MVC?
MVC : Modèle - Vue - Contrôleur
Le contrôleur : ce composant reçoit les demandes en provenance de l’utilisateur final et contrôle le comportement de l’application interactive pour répondre à ces demandes
Le modèle métier : ce composant contient la logique et les informations métiers nécessaires pour répondre aux demandes de l’utilisateur
La vue : ce composant affiche les informations attendues par l’utilisateur final
Quelles sont les 6 étapes d’évolution d’une application interactive selon MVC?
Étape 1 : via un moyen d’interaction quelconque (clavier, souris, écran tactile, …), le composant “contrôleur” reçoit un événement émis par l’utilisateur de l’application
Étape 2 : Le contrôleur reçoit cet événement, l’interprète et en déduit l’action à demander au modèle métier. L’action est exécutée et le modèle métier est mis à jour
Étape 3 : Le contrôleur sélectionne la vue qui doit afficher le résultat de l’action
Étape 4 : Le composant “vue” est abonné au modèle au sens du pattern Observateur (l’abonnement est mis en place lors du développement des composants logiciels). Quand le modèle est modifié suite à la demande du contrôleur, un événement est envoyé à la vue pour l’activer
Étape 5 : Une fois activée, la vue interroge le modèle pour récupérer les informations qui lui sont nécessaires
Étape 6 : La vue élabore enfin l’objet graphique à afficher (page HTML, écran ou boîte de dialogue Windows, animation Flash, …) à partir des informations métiers, puis envoie cet objet vers le moteur graphique (navigateur web, Windows, interpréteur Flash, etc.) en charge du rendu graphique
Comment le pattern MVC est revisité pour convenir à SOA?
Particularités de la SOA :
- (Contexte local = éléments de session) d’un ou de plusieurs utilisateurs avec verrouillage d’objets en cours de modification
- Service applicatif
- Transaction longue
Résultat : proposition d’un MVC-SOA revisité
Étapes du MVC-SOA revisité :
Étape 1 : La vue réagit à l’événement utilisateur en sélectionnant l’action appropriée
Étape 2 : L’action devient un véritable composant à part entière. Elle peut dans certains cas appeler directement des services métiers, par exemple les services gérant la sécurité ou le verrouillange des objets métiers
Étape 3 : L’action est transmise au contexte, c’est-à-dire au cache local d’objets métiers qui tient lieu de modèle métier au sens MVC. Le modèle métier, en fonction de ce qui lui est demandé et du contenu du cache, peut :
- Ne rien faire : les informations sont déjà présentes
- Effectuer un chargement plus complet que nécessaire : si l’action se situe en début de session de travail, le modèle peut décider de lancer une requête visant à anticiper sur les demandes futures
- Compléter le chargement l’objets métiers en se limitant à ce qui est nécessaire. Si l’action vise à charger le client et la liste des interventions et que les informations du client sont déjà en cache, le contexte ne demandera que la liste des interventions
Étape 4 (optionnelle) : le modèle dialogue avec son service applicatif pour exécuter l’action demandée, si c’est nécessaire
Étape 5 : le modèle une fois mis à jour réveille le gestionnaire d’état. À partir de l’état courant et des modifications dans le modèle, le gestionnaire d’état produit un nouvel état de l’IHM
Étape 6 : Ce nouvel état produit une nouvelle vue, qui est alors affichée