Vous êtes sur la page 1sur 45

Plan

Modélisation et systèmes d’information


• Systèmes d’information
• Modélisation de processus
• Processus et typologie des processus
• Démarche de modélisation de processus
• Modèle et métamodèle
• Notion de processus bien structuré
Langages de modélisation de processus
• Réseau de Petri
• SADT
• MERISE
• UML
• BPMN

Langage et plateforme ARIS


1
Langages de modélisation de processus
7 fonctions
o Modéliser o Piloter
 langages, syntaxe…  suivre l’activité, les performances
o Publier o Évaluer
 statique, dynamique…  mesurer les performances, la
o Simuler consommation de ressources, le temps
 calculer, dimensionner… prévus/réels…
o Exécuter o Intégrer
 orchestrer des services  orchestrer les échanges

Langages de modélisation de processus


o Réseau de Petri (RDP)
o Merise
o UML
o SADT
o BPMN
o Aris
o … 2
Réseau de Petri (RdP)

Réseau de Petri (RdP): Langage de modélisation représenté sous forme d’un graphe biparti orienté
(places et transitions).
 Les places sont représentées par des cercles (les états).
 les transitions sont représentées par des traits (les évènements).
 Chaque place contient un nombre entier de marques (ou jetons) pour modéliser la
dynamique du système.
 Une place est active lorsqu’elle a au moins 1 marque.

P0
Place
Transition
Correct
Marque (ou Jeton) P1 P2
Arc
Condition fausse Incorrect
P3
Condition vraie

3
Réseau de Petri (RdP)

 Une transition est franchissable = Toutes les places amonts sont actives.
 Franchissement:
o enlever les marques en amont et introduire les marques en aval
o 1 franchissement par pas du système

P0 P0

P1 P1

(a) Transition franchissable (b) Transition non franchissable

P0 P0
P3 P3
P1 P1
Places Amonts Places Avales

(c) Franchissement d’une transition


4
Réseau de Petri (RdP)

 Etat = vecteur du nombre de marques


o (P0, P1, P2, P3, P4): soit (1, 1, 0, 0, 0) puis (0, 0, 1, 1, 1)

P2 P2
P0 P0
P3 P3
P1 P1
P4 P4

5
Réseau de Petri (Exercice)

 Atelier de coupe de bois sur commande


o L’atelier comprend une seule machine de coupe
o Les commandes sont livrées dès la découpe
 Conditions (Places)
o La machine de coupe est au repos (atelier inactif)
o Une commande est en attente
o La commande est en cours de découpe
o La commande est terminée
 Les événements qui constituent un « changement d’état » (Transitions)
o Une commande arrive
o La machine débute la commande
o La machine termine la commande
o La commande est envoyée pour la livraison

2013 Cours Modélisation 3IF. Pierre-Alain MILLET 6


Réseau de Petri (Exemple)

Atelier de coupe de bois

Stock de
bois ?
Priorités?

7
Réseau de Petri et Processus

 Un seul modèle avec deux éléments: places et transitions.

 Pas de représentation évidente.

 Usage principal: étudier les états possibles d’un système et le dimensionner


pour une certaine caractéristique du flux (simulations).
 Utilisé comme formalisme par l’outil de modélisation DEM.

8
Structured Analysis and Design Technic (SADT)

 SADT est une méthode graphique particulièrement bien adaptée pour une description
fonctionnelle du SI.
 Actigramme et datagrammes n’ont pas le même niveau de granularité (le datagramme
est plus détaillés).

Actigramme Datagramme

Données de contrôle Contraintes


(comment?)

Données d’entrée Activité Données de sortie Activité d’entrée Activité de sortie


Donnée
(sur quoi?) (Que faire?) (pourquoi) (génératrice) (utilisatrice)

Mécanismes de support Mécanismes de


(Avec quoi?) support

(Henry Baccon, Urbanisation des Système d’information)

9
Structured Analysis and Design Technic (SADT)

Hiérarchie de diagrammes: diagrammes père-fils (3 à 6 boites maxi par diagramme)


 La description d'un système s'effectue sous la forme d'une suite cohérente de diagrammes

 Le diagramme de plus haut niveau représente la finalité du système (A-0) (fonction globale).

10
Structured Analysis and Design Technic (SADT)

Actigramme et datagramme (exemple)


Actigramme

Ordre d’impression Boite: verbe d’action


Flèches: nom

Papier blanc Imprimer un PDF imprimé


PDF

Imprimante

Datagramme
Boite: nom
Suivre les instructions Flèches: verbe d’action

Fournir du Imprimer
papier blanc Papier blanc PDF

Fournisseur
11
Structured Analysis and Design Technic (SADT)
Atelier de coupe de bois (Actigramme)

Commande
reçue Enregistrer
Commande
Atelier Dispo
Commande enregistrée
Lancer Bon de découpe
Commande

Découper Pièce
Bois
Commande

Découpe
Livrer Livraison
Commande

A0 Atelier de découpe
12
SADT et Processus

 Analyse et compréhension des systèmes complexes

 Outil de communication pour:

 Équipe (analystes)
 Clients (expression des besoins)
 Hiérarchie (direction et suivi du projet)
 Points de vues

 Données et activités
 Pas de vue organisationnelle
 Usage principal

 Analyse de système

13
MERISE
MERISE : Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise

 Niveau Conceptuel Données Traitements


 Quoi ? Conceptuel MCD MCT
 Ce que fait l’entreprise
Logique/ MLD MLT
 Niveau Organisationnel / Logique
Organisationnel (MOT
 Qui? organisationnel)
 Niveau Physique / opérationnel
 Comment ? Avec quoi? Physique/ MPD MOT
 Les moyens techniques, matériels Opérationnel (MOT opérationnel)
et logiciels

 Modèle conceptuel des traitements = MCT


 Un processus est une vue du MCT correspondant à un enchaînement pertinent
d'opérations du point de vue de l'analyse.
 Modèle logique (organisationnel) des traitements = MLT (MOT)
 décrit avec précision l’organisation à mettre en place pour réaliser
14
MERISE

Diagramme de flux: représentation graphique des acteurs et des flux


Exemple : Gestion des sinistres dans une société d’assurance

15
MERISE

Le modèle conceptuel de données (MCD):


 Représentation statique du système d’information

 Représentation des données facilement compréhensible: « entité-association »

 Entités (avec attribut et clé primaire)


 Relations entre entités (binaires, ternaires…)
 Cardinalités (min, max)

Personne Voiture
possède
ID-Personne 0:n 1:1 ID-Voiture
Nom marque
Prénom date couleur
Date-de-naissance acquisition

16
MERISE
Modèle conceptuel de traitements (MCT)

Enchaînement d’opérations déclenchées par des événements contributifs, et produisant d’autres


événements résultats.  Evénement :
o Collection de faits, susceptibles
de déclencher une opération
dans les conditions précisées par
la synchronisation.
o L'intervention du temps (date /
heure) est un événement
extérieur.

 Synchronisation :
o Proposition logique (ET, OU).

 Les acteurs sont facultatifs


17
MERISE
Modèle conceptuel de traitements (MCT)
Exemple : Gestion des sinistres dans une société d’assurance

18
MERISE
Modèle Organisationnel de Traitements (MOT)

 Découpage des opérations du MCT en procédures fonctionnelles : succession de


traitements
 Prise en compte de l’organisation de l’entreprise
 Chaque procédure est affectée à un poste de travail
 Indications supplémentaires
o Ressources utilisées
o Tâche manuels ou automatiques
o Temps réel ou temps différé (cas automatique)
o Durée
o Lieu
 Tableau des procédures fonctionnelles
Temps Poste de travail
Procédure Début Durée Lieu Ressource Responsable

19
MERISE
Modèle Organisationnel de Traitements (MOT)

 MCT + ... = MOT


 Ressources
 Acteurs
R1
R2  Numéro de procédure fonctionnelle
dans l’opération
N°  Type T:
T
o Automatique temps réel (TR)
o différé (TD)
o manuelle (MA)

20
MERISE
Modèle Organisationnel de Traitements (MOT): Exemple

1
TR

2
MA

21
MERISE et Processus

 Processus Métier
o Pas de modélisation explicite des objectifs, des décisions autrement que
comme information
 Points de vues
o Données et traitements
o Pas de vues ressources (uniquement citées dans le MOT)

 Usage principal
o Conception de S.I. de gestion

22
Unified Modeling Language (UML)
 UML : convergence d’efforts en conception de logiciel orientée objet
o Langage semi-formel
o Standardisé par l’OMG
o Pas une méthode, une notation indépendante de tout langage…
 Niveaux de modélisation
o Système: dans son environnement et interactions avec les utilisateurs
o Sous-systèmes: décomposition structurelle hiérarchique du système
o Entité: modélisation détaillée au niveau des objets
 Modes d’utilisation
o « spécification »: (analyse de besoins, comprendre les fonctionnalités du
système…)
o « Esquisse »: (pour générer un squelette…)
o « développement »: générer du code à partir des modèles
 Tout est objet
o Processus, acteurs, informations -> diagramme de classes
o Décrire fondamentalement les informations associées aux objets et constitue
donc une « vue informationnelle » des objets.
23
Unified Modeling Language (UML)

 14 diagrammes permettent de visualiser et de manipuler les éléments de la modélisation.

 3 axes de modélisation:

 L’axe fonctionnel décrit ce que fait le système. Fonctionnel


Diagramme de cas d’utilisation
 L'axe statique décrit la structure du système.
 L'axe dynamique qui est relatif à la construction
des fonctionnalités du système.

Dynamique
Diagramme d’état
Diagramme d’activité
Statique Diagramme de séquence
Diagramme de classes
Diagramme d’objets
Diagramme de déploiement

24
Unified Modeling Language (UML)

L’approche processus avec UML


 Diagrammes de cas d’utilisation
o Situation d’interaction entre système et acteurs
o Scénarios fonctionnels
o Référence dans le cycle de développement (du besoin aux tests)
o Diagramme de cas (vue globale des interactions).

 Diagrammes d’interaction
o Scénarios de cas (interactions entre objets)
o Diagramme de séquence (interaction temporelle)

 Diagrammes d’activités
o Diagramme état-transition simplifié (flot entre activités)
o Équivalent au MOT de MERISE

25
Unified Modeling Language (UML)

Diagramme des cas d’utilisation


 Définitions
o Séquence d’activités ou d’actions
en réponse à une sollicitation
d’un acteur
 Pourquoi?
o Recueillir, analyser et organiser
les besoins des utilisateurs
o Recenser les grandes
fonctionnalités du système
o Définir:
o les besoins fonctionnels
o le périmètre fonctionnel

 Inclusion : X « includes » Y  X implique Y


 Extension : X « extends » Y  X peut être provoqué par Y

26
Unified Modeling Language (UML)
Diagramme des cas d’utilisation (exemple)

Gestion des commande du magasin X

S’authentifier

« includes » Envoyer
Commande
« includes » « includes »
Commander Vendeur
Préparer
Client « extends » « includes » Commande

Ajouter un
produit Payer

27
Unified Modeling Language (UML)

Diagramme de collaboration

 Définitions
o Diagramme d’objets et d’acteurs 1: message
avec envoi de messages Objet 1 Objet 2
o Ordre d’interaction (flèches
numérotées)
2: message
 Pourquoi?
o Décrire les interactions et les liens
entre les objets composant le
système. Objet 3

28
Unified Modeling Language (UML)

Diagramme de collaboration (exemple)

1: Déposer cv
Cabinet
recrutement
Personne en
recherche 3: Proposer Candidat
d’emploi

5: Passer l’entretient
2: Proposer Poste
4: Convoquer

Entreprise

29
Unified Modeling Language (UML)

Diagramme de séquence

 Représentation chronologique des


échanges de messages entre les
différents objets du système. Système
 Décrire la séquence d’interactions entre
Acteur 1 Acteur 2
le système et ses acteurs.
Message1()
 Les objets sont des colonnes du Message2()
diagramme.
Message3()
 Flèche entre deux objets: message.
 Bandes rectangulaires: périodes Message4()
d’activité des objets.
 Chronologie des interactions: du haut
vers le bas.

30
Unified Modeling Language (UML)
Diagramme de séquence
Système compagnie
Banque
aérienne
Client
Saisir destination (départ, arrivée, date)

Liste des vols possibles

Choisir vol aller

Choisir vol retour

Afficher prix total

Saisir client (identité, n° passeport)


Saisir carte bleu (n°, validité, code)

Demande débit carte

Confirmation débit

Réservation confirmée
Afficher billet d’avion

31
Unified Modeling Language (UML)
Diagramme d’activités
 Modéliser les processus complexes en exposant l’enchaînement d’activités
séquentielles et/ou parallèles à l’aide de sa notation très riche.

Représentation graphique Description


Début des activités d'un processus

Action
Une action illustre une tâche à exécuter
pendant le déroulement du processus
Action A Action B Enchaînement entre deux actions A et B
Fin des activités du processus

Point de décision (OU exclusif) Point de jointure (Join) Point d’éclatement (Fork)

Action A Action A Action B Action A

Condition 1
Action B
Condition 2
Action C Action B Action C
Action C
32
Unified Modeling Language (UML)
Diagramme d’activités
(exemple)

33
Unified Modeling Language (UML)
Insérer carte

Diagramme d’activités (exemple)


Saisir code
Code invalide

Diagramme d'activités modélisant le fonctionnement Annulation

Code valide
d'une borne bancaire: Choisir opération

 Insérer carte…
Saisir montant
 Saisir montant
Choisir compte
 …
Demande
autorisation retrait

non autorisé

autorisé

Distribuer billets

Restituer
carte

34
Unified Modeling Language (UML)
Diagramme d’états-transitions

 Décrire les aspects dynamiques des objets d'un système (comportement des
objets).

Evènement 1 Evènement 2
Etat 1 Etat 2

Etat
Etat initial Etat final
intermédiaire

35
Unified Modeling Language (UML)
Diagramme d’états-transitions

 Décrire les aspects dynamiques des objets d'un système (comportement des
objets).

36
UML et Processus

 La dimension métier du processus

 Pas de séparation métier/technique (Système / sous-système ?)


 Cas d’utilisation: scénario
 Diagramme d’activité
 Points de vues

 Tout est objet


 Pas de vue organisationnelle, ressources..

37
BPMN: un standard orienté processus

 Langage standard pour modéliser graphiquement tout type de processus.


 Initiative de BPMI (Business Process Management Initiative) puis soutenu par
l’OMG (Object Management Group).
 Une notation standard facilement compréhensible par les utilisateurs:
 Analystes métiers qui créent et raffinent les processus.
 Développeurs qui implémentent les processus.
 Directeurs qui suivent et gèrent les processus
 Intervenants externes, etc.

Flux de séquence
Activité
Flux de séquence
Evènement Evènement
de début de fin

38
BPMN: Représentation graphique

 Objets de flux
 Tâche, branchement, évènement

 Objets de connexion
 enchaînements d’activité, les messages et les associations

 Groupement (pool) et lignes (swimlanes)


 Les groupements définissent un périmètre de processus et peuvent être divisés
en « lignes » (acteurs, limites organisationnelles)
 un enchaînement d’activité ne peut pas se faire entre 2 groupements
 un message ne peut être qu’entre 2 groupements.
 Orchestration = enchaînements internes à un groupement (processus)
 Chorégraphie = communications entre processus

 Artefacts
 objets de données, groupes, annotations.
BPMN: Représentation graphique

Représentation graphique Description


Séquence (ordre des activités)
Message (entre deux processus)
Association (flux de données…)
Gateway (branchement)

Activité

Sous-processus
+
BPMN: Exemple

41
BPMN: Exemple

42
BPMN: Exercice

 Le demandeur désirant obtenir une carte bleue doit en faire la demande auprès de la
banque. La carte bleue n’est pas acceptée si le demandeur n’est pas un client de la
banque. Chaque jour, la banque transmet les demandes carte bleue de ses clients au
Centre de Gestion des cartes bleues. Dés que la banque a reçu la carte bleue en
provenance du Centre de gestion des cartes bleues, elle adresse au client un avis de
prélèvement de cotisation annuelle. Si au bout de deux mois la carte bleue n’a pas été
retirée, elle est détruite.

Travail à faire: Représentez par un diagramme BPMN ce cas d'utilisation

43
BPMN et processus

 La dimension métier du processus


 Un modèle mixte métier/technique

 Points de vues
 Processus/fonctions

 Avantages de la norme BPMN


 Notation visuelle et claire
 Format commun automatisable
 Formalisme compréhensible même pour les intervenants externes
 Notation de référence

44
Merci pour votre
attention !

45

Vous aimerez peut-être aussi