Les rgles de drivation dumodle pragmatique

1
Les règles de dérivation du modèle pragmatique
 La théorie sans la pratique est inutile la
pratique sans la théorie est aveugle.  Immanuel
Kant
2
Objectif de la séquence

• Compétence visée
• Pré-requis
• Être capable de bien interpréter le notation UML
  pour les cas dutilisation
• Particulièrement, les différentes relations entre
  les cas dutilisation
• Avoir la vue densemble de la méthodologie
  Praxeme
• Formation Principes directeurs
• Posséder la terminologie de la modélisation
  logique

Être capable de dériver le modèle pragmatique
pour peupler la strate  Organisation 
Durée de la séquence 1 h
3
Contenu de la séquence

• La constitution de la strate  Organisation 
• Les règles de dérivation
• Les décisions complémentaires

4
La constitution de la strate  Organisation
1

• La dérivation du modèle pragmatique
• Pour construire la partie du modèle logique
  correspondant à la gestion lorganisation
  de lentreprise
• Cest le peuplement de la strate Organisation

5
Le principe de stratification
Un noyau stable, suffisamment universel pour être
partageable
Les choix dorganisation repoussés à la
périphérie, pour permettre ladaptation
6
La strate  Organisation 

• La strate Organisation isole les choix
  dorganisation
• Aspect plus changeant, indépendamment du cur
  de métier
• Lorganisation doit pouvoir évoluer facilement
• Sans obliger à de grands changements dans
  linformatique
• Cette strate a pour fonction
• Orchestrer les services  métier 
• En les ordonnant selon les pratiques
• Habitudes de travail, distribution du travail,
  mode de responsabilisation
• En vérifiant les règles dorganisation
• Droits, mode de contrôle
• Elle sert de tampon entre les interfaces et le
  noyau

7
La structure de la strate Organisation

• La strate  Organisation  contient des fabriques
  logiques
• La fabrique logique  Organisation  (FLO)
  correspond à lorganisme
• SMABTP ou un des acteurs du réseau dentreprises
• Autant de FLO que dentreprises dans le SIIO
• Système dinformation inter-organisationnel
• Cette façon de faire préserve la liberté
  dadaptation
• Les organismes inscrivent dans les MLO leurs
  modes opératoires spécifiques
• Tout en partageant le noyau
• Les machines des FLO peuvent être conçues pour
  contrôler laccès de tout type dacteur

8
Le travail du concepteur logique

• Comme pour la strate  Métier , larchitecte
  logique fixe les agrégats logiques et leurs
  relations
• Fabriques et ateliers
• Le concepteur logique part du modèle pragmatique
• Exactement la Vue de lutilisation
• Elle contient la spécification détaillée des cas
  dutilisation
• Il applique les règles de dérivation
• Voir chapitre suivant
• Il formule rigoureusement les services de cette
  strate
• Orchestration des services  métier  dans une
  logique dactivité
• Voir séquence sur la spécification et la
  conception des services logiques

9
Les règles de dérivation
2
Des correspondances simples

• La dérivation des domaines fonctionnels
• La dérivation des cas dutilisation
• La dérivation des relations
• La dérivation des règles dorganisation
• La dérivation des automates à états
• La dérivation des objets de lorganisation

10
Vue densemble des règles de dérivation
11
La dérivation du modèle pragmatique
Cas dutilisation
Opérations
(Activités élémentaires)
Graphe dactivité
 Services externe 
Scénarios
12
La dérivation des domaines fonctionnels
2.1

• Les domaines fonctionnels sont dérivés en
  ateliers logiques
• Les domaines fonctionnels sont donc repris
  dans larchitecture logique
• Mais uniquement à la périphérie du système
• Un travail de structuration a été mené sur les
  domaines fonctionnels
• Pour factoriser des actions communes

1 domaine fonctionnel ? 1 atelier logique
 Organisation 
13
Les domaines fonctionnels exemple (1)

• Illustration partielle
• Les domaines fonctionnels sont représentés
  par des paquetages, dans le modèle pragmatique
• Sous la forme dun diagramme de paquetages

14
Les domaines fonctionnels exemple (2)

• Illustration partielle (suite)
• Ou sous la forme dun diagramme de cas
  dutilisation

15
Les ateliers logiques  Organisation 

• Larchitecture résultant de la dérivation
  des domaines fonctionnels
• Un stéréotype particulier

16
La dérivation des cas dutilisation
2.2

• Chaque cas dutilisation est dérivé en
• Une machine logique  Organisation 
• Dite  MLO 
• Stéréotype particulier
• Un service logique  transactionnel 
• Service logique marqué dune annotation
   transactionnel 
• Tagged value
• Cette indication est exploitée par le framework
  JAMOS
• La fonction de ce service est dassurer la
  validation du cas dutilisation
• Il est appelé à la fin du dialogue

17
Les règles de nommage

• Pour la machine logique  Organisation 
• La MLO porte le nom du cas dutilisation
• Préfixé par  Mo 
• La référence pour les convention de nommage est
  le document référencé  OLQ-02x , associé au
  Dossier darchitecture de services
• Pour le service logique transactionnel
• Il reprend le verbe de lintitulé du cas
  dutilisation
• Suffixé par  Valid 

18
Illustration le point de départ

• Le diagramme des cas dutilisation
• Pour le domaine fonctionnel  Gestion des
  sinistres 
• Extrait

19
Illustration le résultat

• Le diagramme de contenu de latelier logique
• Le contenu de latelier  aoGestionSinistres 
• Par un diagramme de classes
• Les MLO sont stéréotypées

20
Les conditions de dérivation
La dérivation suppose que la Vue de
lutilisationa été correctement structurée

• Il est absolument nécessaire de disposer dune
  Vue de lutilisation en version de conception
• Sans redondance entre les cas dutilisation
• Sinon cette redondance est reportée dans
  larchitecture du système
• Rappel sur la structuration des cas dutilisation
• Décomposés en activités élémentaires
• Attribution unique de lactivité à un cas
  dutilisation
• Cf. stage  Modélisation amont , sur le modèle
  pragmatique

21
Récapitulatif

• Les règles de dérivation des cas dutilisation

• 1 cas dutilisation  Verbe Nom  ?
• 1 MLO (  MoVerbe )
• 1 service logique transactionnel ( verbeValid )

22
La dérivation des relations
2.3

• Les cas dutilisation entretiennent des relations
• Linclusion
• La généralisation
• Lextension
• Cf. stage  Modélisation amont 

23
La dérivation de linclusion

• La MLO correspondant au cas de base appelle
  des services de la MLO correspondant au cas
  subordonné
• Doù une relation de dépendance

Cas subordonné
Cas de base
24
La dérivation de la généralisation (1/2)

• Deux solutions (à négocier avec larchitecte
  technique)
• Lhéritage entre machine
• La MLO du cas enrichi hérite de la MLO de départ
• De cette façon, lIHM interagit avec une seule
  machine, sur laquelle elle trouve tous les
  services nécessaires au dialogue
• La dépendance
• De la MLO du cas enrichi vers la MLO de départ
• Le service transactionnel de la première appelle
  celui de la seconde
• LIHM doit combiner les services des deux
  machines
• Les automates des deux machines doivent
  communiquer

25
La dérivation de la généralisation (2/2)
Option 2
Option 1
26
La dérivation de lextension (1/2)

• Deux solutions
• La solution idéale un dispositif central de
  régulation
• Pour déclencher le cas subordonné
• Quand le point dextension est atteint
• La solution de base une dépendance entre les
  MLO
• Mais inversée par rapport à la dépendance
  entre les cas dutilisation

27
La dérivation de lextension (2/2)
Option 2
Option 1
28
Récapitulatif

• La dérivation des relations entre les cas
  dutilisation

• Inclusion ? dépendance
• Généralisation ? héritage ou dépendance
• Extension ? dépendance inversée (ou dispositif
  de coordination)

29
La dérivation des règles dorganisation
2.4

• Les règles dorganisation sont des contraintes
  qui pèsent sur lactivité de lorganisme
• Sur les rôles (ou types dacteurs)
• Sur les activités
• Sur les objets de nature administrative
• Distincts des objets  Métier 
• Par exemple, formulaire, autorisation, signature
• Elles sexpriment sous la forme dexigences
• Gestion des exigences en pré-modélisation
• Elles peuvent être reprises par le modèle
  pragmatique
• Cas des règles dhabilitation
• Elles se lisent sur le diagramme des cas
  dutilisation

30
Illustration

• Extrait de la Vue de lutilisation
• Pour un système ouvert sur le public
• NB sur la généralisation
• Les droits sont  hérités 

 communication link  droit dusage
31
Les règles dorganisation

• Les règles sont plus volatiles que les règles de
  gestion
• Variation dun organisme à lautre
• Habitudes de travail
• Qualité de service, style
• Facteur discriminant entre concurrents
• Orientation client, qualité, etc.
• Variation dans le temps
• Re-conception des processus
• Reconfiguration organisationnelle
• Nouvelle définition des postes

32
La dérivation des règles

• Dans larchitecture de la SMABTP
• Les règles dorganisation sont traitées dans le
  moteur de règles
• Les services logiques appellent un  service de
  règles 
• Ce dernier encapsule la solution technique
• JRules
• Voir le Dossier darchitecture technique
• Il peut exister des règles liées au dialogue plus
  quà lorganisation
• Elles sont traitées
• Soit par lautomate à états
• Voir plus loin
• Soit comme pour les machines logique  Métier 
• Soit au niveau de linterface
• Si ce sont des règles de présentation, uniquement

33
Le travail du concepteur logique

• Les règles sont exprimées en amont
• Le concepteur logique vérifie leur expression
• Les règles sont-elles exprimées de façon
  suffisamment rigoureuse ?
• Le développeur ne doit pas avoir de question à se
  poser sur le contenu fonctionnel
• Lexpression des règles est-elle compatible avec
  le modèle logique ?
• Les données sont-elles disponibles pour vérifier
  la règle, au moment où le moteur de règles sera
  sollicité ?
• Ceci renvoie au rôle dorchestrateur des machines
  logiques  Organisation 

34
La dérivation des automates à états
2.5

• Un automate à états peut avoir été associé au cas
  dutilisation
• Cest une possibilité dUML
• La dérivation de lautomate à états
• Détail dans la séquence FML-12

Quand un automate à états existesur un cas
dutilisation,il est repris et attaché à la MLO
35
La dérivation des objets de lorganisation
2.6

• Le modèle pragmatique peut contenir aussi des
  classes
• Pas seulement des cas dutilisation, des rôles
  et des processus
• Les objets de lorganisation
• Cas 1 la description des notions de
  lorganisation
• Cas 2 la description dobjets de nature
  administrative
• Comment traiter ces objets ?
• Représentés par des modèles de classes inclus
  au modèle pragmatique

Les objets de nature organisationnelleou
administrative sont logésdans la strate
 Organisation 
36
Les objets de lorganisation

• Cas 1 la description des notions de
  lorganisation
• Des objets génériques qui permettent de décrire
  les éléments dune organisation et les activités
• Exemples acteurs, structures, droits, postes
• Cas 2 la description dobjets de nature
  administrative
• Des objets particuliers nécessaires à un
  processus ou un domaine fonctionnel
• Dossiers, traces de lactivité, formulaires,
  signatures, traces des échanges, courriers,
  paramètres, contexte
• Exemple données pour le suivi de larchivage
• Ces objets ne sont pas aussi fondamentaux que les
  objets  métier 
• Ils ont de bonnes chances de varier dune
  organisation à lautre

37
La dérivation des objets génériques

• Le cas 1 les objets génériques de nature
  organisationnelle
• Même comportement que les ateliers de la strate
   Métier 
• Ils sont fermés
• On nobtient des services quà travers leurs
  interfaces

Ces modèles de classes sont dérivés
comme un modèle sémantique ? Ateliers logiques
opaques
38
Illustration le contenu de la fabrique

• Dans la fabrique logique  fSMABTP 
• Deux ateliers logiques chargés des ces notions
• Stéréotype  Atelier 

39
Le rôle des objets organisationnels

• Toute machine logique  Organisation  utilise
  les services de ces ateliers
• Ces ateliers sont génériques
• Ils peuvent incorporer des solutions du marché

40
La dérivation des objets administratifs

• Ces modèles de classes, très réduits, sont
  dérivés comme des modèles sémantiques
• Les machines résultantes sont sous le contrôle
  des MLO du domaine fonctionnel
• Exemple
• Deux solutions
• Atelier incorporé
• Exemple ?
• Classe imbriquée

41
Conséquence les ateliers de la strate
 Organisation 

• Des ateliers de même type que dans la strate
   Métier 
• Stéréotype  Atelier 
• Ateliers fermés, opaques
• Communication par linterface uniquement
• Des ateliers propres à la strate  Organisation 
• Stéréotype  Atelier Organisation 
• Ateliers ouverts, transparents
• Accès direct au contenu des ateliers
• MLO et types
• À partir de la strate  Présentation 

42
Décisions complémentaires
3

• Connexion des strates métier et organisation
• Transactions
• Automates de MLO
• Structures de données
• Signaux

43
Connexion des strates  Métier  et
 Organisation 

• Modèles sémantique et pragmatique sont décrits
  parallèlement
• Le point de rencontre se situe au niveau logique
• Analyse des activités élémentaires, dérivées en
  services externes
• Services externes services logiques des MLO
• Détection des services internes nécessaires
• Services internes services logiques des MLM
• Besoin des MLO vers les MLM
• Les MLO nappellent que les services dinterface
  des MLM
• Les connexions vers le modèle logique sont
  inscrites sous la forme de relations
  dutilisation entre ateliers

44
Utilisation des services  Métier  par la MLO
 moRepartirCharges 
45
Les transactions trois points de vue

• Le point de vue de lacteur correspondance
  Acte de gestion
• Ensemble cohérent dactions
• Un scénario dun cas dutilisation
• La sauvegarde dune partie du travail est
  confortable pour lutilisateur
• Le point de vue logique validation de la
  cohérence
• Notion de service transactionnel
• Réalise les transformations et les achemine au
  cur du système, après validation par
  lutilisateur
• Lance des contrôles métiers et gère leur résultat
• Le point de vue technique commit SGBD
• Mécanisme des SGBD
• Assurer la cohérence entre tables
• Dépend de larchitecture des données
• Pris en charge par le framework JAMOS

46
La conception des transactions

• La définition du service transactionnel
• Le service transactionnel est un SL externe
  assurant la mise à jour du système en respectant
  sa cohérence
• Éléments de conception
• Origine et  nommage 
• Chaque cas dutilisation donne lieu à un service
  transactionnel (sauf consultation unique)
• Évoque le cas dutilisation

47
Létat de la MLO

• Létat interne est géré directement par la MLO
• Dépend de létat davancement du cas
  dutilisation
• Facette côté Présentation interaction avec
  lutilisateur
• Facette côté Métier état des données métier
• Le bon fonctionnement dune MLO nécessite
• Le contexte dutilisation
• Organisme ou contexte de gestion, pays, langue
• Identifiants de session
• Le contexte informationnel
• Informations assemblées par lexécution du cas
  dutilisation
• Nouvelles informations saisies et informations
  obtenues des services internes

48
Le fonctionnement

• Récapitulatif
• Au cours de lexécution dun cas dutilisation
• Le système accumule linformation apportée par
  lutilisateur au fil des échanges
• Les services sont élémentaires
• Le dialogue
• Lordonnancement des actions obéit à une logique
  procédurale
• Le concepteur ajoute des transitions permettant
  daccueillir toute perturbation éventuelle
• Fin du cas dutilisation
• Le service de transaction reporte définitivement
  les modifications dans le système

49
Récapitulatif des acquis

• Rappel de la compétence visée
• Notions clefs
• Les règles de dérivation
• Le fonctionnement de la transaction

Être capable de dériver le modèle pragmatique
pour peupler la strate  Organisation 
Compétence Performance
50
Exercices (a)

• Quelle strate est concernée par la dérivation du
  modèle pragmatique ?
• Quelle est la granularité de la FLO ?
• Que devient un cas dutilisation après dérivation
  ?
• Que devient un domaine fonctionnel après
  dérivation ?
• Quel atelier comporte les éléments relatifs aux
  habilitations ?

51
Exercices (b)

• Que deviennent les activités élémentaires après
  dérivation ?
• Quel élément de modélisation est utilisé pour
  représenter la logique procédurale dun cas
  dutilisation ?
• Y a-t-il possibilité de propagation de service
  externe de MLO ?
• Des MLO et MLM, qui appelle lautre ?

52
Exercices (c)

• Où sont traitées les règles dorganisation ?
• Quest-ce quune transaction au sens dAMOS ?
• Qui gère létat de la MLO ?

53
Gamme opératoire

• Tâches du concepteur
• Étudier les cas dutilisation et les SFD
• Construire les ateliers logiques
• Appliquer les règles de dérivation relatives aux
  vues de lutilisation et de lorganisation
• Connecter les strates Métier et
   Organisation

Compétence Performance
54
Le travail du concepteur logique

• Récapitulatif sur la dérivation des cas
  dutilisation
• Le concepteur exploite les cas dutilisation et
  les SFD
• Il détecte ainsi les besoins dinterrogation ou
  de daction sur le système
• Il identifie et définit la couverture de ces
  besoins par des services
• Il crée une MLO par cas dutilisation
• Celle-ci regroupe les services conçus
• Correspondant aux activités élémentaires

55
Synthèse des règles de dérivation (a)

• Le modèle pragmatique comporte deux volets
• La vue de lutilisation vision locale formulée
  en cas dutilisation
• La vue de lorganisation vision globale,
  décrivant les processus organisationnels

56
Synthèse des règles de dérivation (b)