Les rgles de drivation dumodle pragmatique - PowerPoint PPT Presentation

1 / 56
About This Presentation
Title:

Les rgles de drivation dumodle pragmatique

Description:

Praxime, initiative pour une m thode publique. Les r gles de ... Les services logiques appellent un ' service de r gles ' Ce dernier encapsule la solution ... – PowerPoint PPT presentation

Number of Views:95
Avg rating:3.0/5.0
Slides: 57
Provided by: ole58
Category:

less

Transcript and Presenter's Notes

Title: 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)
Write a Comment
User Comments (0)
About PowerShow.com