Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 1 - Ingénierie des Modèles Logiciels Cours #7 Les modèles de processus Jean Bézivin [email protected]

Ingénierie des systèmes logiciels

© 2003 ATLAS Nantes. - 1 -

Ingénierie des Modèles Ingénierie des Modèles LogicielsLogiciels

Cours #7Cours #7 Les modèles de processusLes modèles de processus

Jean Bé[email protected]

Equipe ATLAS (INRIA & IRIN), Nantes



Question centrale

• Peux t'on piloter un moteur de workflow avec un modèle MDA explicite de processus ?• (rappel: comment piloter un meta-case par un méta-

modèle ?)

Modèlede

processus

Moteur d'exécution

•Distribuer les tâches aux agents d'exécution (humains ou non)•Distribuer les produits d'entrée •Vérifier la bonne exécution de ces tâches •Gérer le bon stockage des produits de sortie



Plan du cours #7 : Les modèles de processus

• Introduction• Méthode unifiée?• Modèles de processus• Le SPEM• Modèles de processus vs modèles

exécutables• Conclusion

• NB: Ce cours s'appuie sur le travail de thèse de Erwan Breton disponible à l'URI suivante:

http://www.sciences.univ-nantes.fr/info/lrsg/Pages_perso/EB/Erwan.htm



Méthodes

• Définition :• Une méthode est une manière de dire, de faire, d'enseigner une

chose suivant certains principes et avec un certain ordre.

Petit Larousse• Merise est une méthode; OMT est une méthode.• Méthode = Notation + Démarche + Outils.• Initialement l'OMG désirait une méthode "unifiée".• De façon réaliste il n'a été possible de se mettre d'accord dans un

premier temps que sur une notation "unifiée" (UML).• L'une des raisons est qu'il n'existe pas une seule méthode, mais une

infinité de méthodes.• Après avoir standardisé la notation, l'OMG s'attaque maintenant au

problème de la standardisation des méthodes. • Tout comme pour UML, l'OMG s'appuie sur des méthodes industrielles

comme le RUP (Rational Unified Process) pour définir le noyau de méthode générique UPM (Unified Process Model).



Les grandes classes de méthodes en G.L.

• Les méthodes d'organisation stratégique.• Comment élaborer le schéma directeur ?

• Orientations à suivre.

• Moyens à mettre en œuvre.

• Les méthodes de développement.• Guider les développeurs de la phase d'analyse à la phase de

maintenance.

• Les méthodes de conduite de projet.• Aider le chef de projet informatique à planifier son projet, à

évaluer les charges et à en suivre l'avancement.

• Les méthodes d'assurance et de contrôle qualité.• Mettre en place des procédures pour améliorer la qualité des

produits développés.



Méthode de développement

• Elle doit permettre de :• Construire des systèmes opérationnels

• Organiser le travail

• Gérer le cycle de vie complet

• Gérer les risques

• Obtenir de manière répétitive des produits de qualité constante

• Définitions de l'IEEE :• Le cycle de développement prend en compte la partie

amont (pré-étude) et s'achève lorsque le logiciel est livré.

• Le cycle de vie débute avec la spécification et s'achève sur les phases d'exploitation et de maintenance.



Définitions

• Une notation peut permettre de représenter de façon uniforme l'ensemble des artefacts logiciels produits ou utilisés pendant le cycle de développement.

• Artefact = tout élément d'information utilisé ou généré pendant la totalité du cycle de développement d'un système logiciel.• Exemple: morceau de code, commentaire, spécification statique

d'une classe, spécification comportementale d'une classe, jeu de test, programme de test, interview d'un utilisateur potentiel du système, description du contexte d'installation matériel, diagramme d'une architecture globale, prototype, rapport de réalisation, modèle de dialogue, rapport de qualimétrie, manuel utilisateur, etc.

• Une méthode c'est un processus outillé avec un ensemble cohérent de notations.



Méthode Unifiée?

Méthode Unifiée?



Il n'existe pas une seule méthode

• Petit projet exploratoire d'un système informatique de gestion utilisant une technologie innovante pour l'interface utilisateur (estimé à 3hommesx6mois).

• Réécriture en langage Java d'un logiciel de gestion des prospects pour une entreprise commerciale. Le logiciel initial était écrit en Cobol et les dossiers d'analyse en SADT existent toujours (estimé à 6hx12mois).

• Ecriture de tout le logiciel de gestion client nécessaire à une nouvelle société de téléphonie mobile. Rien n'existe. Le service informatique de la société est assez réduit et il sera nécessaire de faire appel à la sous-traitance. Le cahier des charges est en cours de constitution (estimé à 150hx24mois).

• La méthode doit être générique.



Rappel : l'image globale (roadmap)

Procedural ADM

OOADMe.g. OMT

UML UPMSPEM

>2001

07/200111/1997

Network of models

+ profiles+ other MMs

+ specific processes(RUP, IBM SI, etc.)

Method = notation + process + tools

Modelweaving

Unified Method: impossible

1. Comment séparer les aspects ?2. Comment tisser les aspects ?

1985-1995



Les schémas de développement : une grande variété

?t0

Le schéma en tunnel

Maintenance

Conception

Codage

Analyse

Le schéma en cascade

•Schéma en cascade•Linéaire, flot descendant

•Retour limité à une phase en amont

•Validation des phases par des revues

•Enchaînement depuis le cahier des charges jusqu’à la réalisation

•Bien adapté lorsque les besoins sont clairement identifiés et stables



Les schémas de développement : une grande variété

Exploitation,Maintenance

Évolution

Codage

ConceptionPréliminaire

Conceptiondétaillée

AnalyseTests

fonctionnels

Testsd’intégration

Etude des besoins

vérif

vérif

vérif

vérif

Tests unitaires

Le schéma en V



Evolution vers le processus unifié de Rational (RUP)

Functional testingPerformance testingRequirements mgmtConf. and change mgmtBusiness engineeringData engineeringUI design

Rational Unified Process 5.01998

Rational Objectory Process 4.11996-1997

Objectory Process 1.0-3.81987-1995

Approche Ericcson

Approche Rational

UML



Améliorations du cycle de vie en cascade

• Risques élevés et non contrôlés• Identification tardive des problèmes

• Preuve tardive de bon fonctionnement

• Améliorations :• Distinction entre phases et activités

• Construction du système par incréments

• Chaque itération a pour but de maîtriser une partie des risques et apporte une preuve tangible de faisabilité ou d’adéquation

• Enrichissement d’une série de prototypes

• Les versions livrées correspondent à une étape de la chaîne des prototypes

• Processus itératif et incrémental• Un processus itératif implique la gestion d'une succession de versions

exécutables. Un processus incrémental signifie que l'architecture du système est constamment améliorée pour produire ces nouvelles versions, qui apportent toutes des améliorations incrémentales par rapport à la précédente. Un processus à la fois itératif et incrémental est centré sur les risques, c'est-à-dire que chaque nouvelle version se concentre sur la prise en charge et la réduction des risques les plus importants, qui pourraient menacer la réussite du projet.



Phases et itérations

• Des phases• Inception (étude d'opportunité)• Elaboration (architecture, planification)• Construction• Transition

• Des itérations• Chaque cycle donne une génération• Chaque cycle est décomposé en phases• Chaque phase comprend des itérations

• Des incréments• Le logiciel évolue par incrément• Une itération correspond à un incrément• Les itérations peuvent évoluer en parallèle



Phases et itérations

P re lim in a ry

Ite ra tio n (s )

ite r.

#1

ite r.

#2

ite r.

#n

ite r.

#n+1

ite r.

#n+ 2

ite r.

#m

ite r.

#m +1

Incep tion E labo ra tion C ons truc tion Transition

Ite ra tio n s

P hases

Requirements

Design

Implementation

Test

Analysis

Une itérationdans la phased'élaboration



Les cinq vues de Philippe Kruchten

• Ces cinq vues sont indépendantes les unes des autres, ce qui permet aux différents intervenants de se concentrer sur les problèmes de l'architecture du système qui les concernent le plus. Elles interagissent également entre elles— les nœuds de la vue de déploiement comprennent des composants de la vue d'implémentation, qui, à leur tour, correspondent à la réalisation physique de classes, d'interfaces, de collaborations et de classes actives dans les vues de conception et de processus. UML permet de représenter chacune de ces cinq vues ainsi que leurs interactions.



Importance croissante de la prise en compte des processus

+nameProcess

-name-duration

Activity

1

0..*

+following0..*

+preceding

0..*

Qui fait quoi, quand, comment et pourquoi ?



Qu'est ce qu'un processus ?

• Ce qui permet, pour atteindre un but donné, de définir comment procéder :• Qui le fait (le qui) ?

• Ce qu'il faut faire (le quoi) ?

• À quel moment le faire (le quand) ?

• Dans quelles conditions il faut le faire (le comment) ?

• Quelles sont les raisons, les décisionnaires, le contexte et les objectifs de l'action (le pourquoi)?



Qu'est ce qu'un processus ?

Processusde génie logiciel

Système nouveau

ou modifié

Spécifications nouvelles

ou modifiées

Comment définir ceci de façonprécise, automatisable et contrôlable?



UML n'est pas suffisant

Développementen équipe

Langage demodélisation

Processusunifié



Un repas à la Tour d'Argent ... ou ailleurs

Le procédé de fabrication

Le procédé de consommation

Le produit(le repas)



Un repas à la Tour d'Argent ... ou ailleurs



Modèles de processus

Modèlesde processus



Modèles de produits et modèles de processus

MOFMOF

UMLUMLUPMUPM

CobolCobol

EJBEJB

JavaJava

etc.etc.etc.etc.

Similaires aux structures de données Similaires aux structures de contrôle

WorkflowWorkflow

CorbaCorba

Artefacts Processus



Diagrammes de Gantt

• Les diagrammes de Gantt ont été créés par Henry Gantt dans les années 1920. Un diagramme de Gantt permet de décrire l’ensemble des activités d’un processus sous la forme de barres placées sur un calendrier. On a ainsi une vue graphique de l’ensemble des activités, de leurs durées et de leur ordonnancement.

• Le méta-modèle des diagrammes de Gantt définit un processus comme un ensemble d'activités, chaque activité étant dotée d’une date de début et d’une date de fin.

Activity 1

Activity 2

Activity 3

Activity 4

01/01 02/01 03/01 04/01 05/01 06/01 07/01

A c t i v i t y

n a m e : S t r i n g b e g i n D a t e : D a t e e n d D a t e : D a t e

P r o c e s s

n a m e : S t r i n g

1

0 . . *

1

0 . . *



Diagrammes de PERT

• Les PERT (Program Evaluation and Review Technique) ont tout d’abord été utilisés par le département américain de la défense. Un PERT est un graphe orienté qui montre les activités, leur durée ainsi que leur ordonnancement.

• Un processus vu comme un PERT est donc une suite d'activités, chaque activité ayant une durée et pouvant suivre ou précéder d’autres activités.

• Contrairement à une activité d'un diagramme de Gantt, une activité d'un PERT ne définit pas de date.

Activity 13 days

Activity 42 days

Activity 33 days

Activity 22 days

Process

name : String

Activity

name : Stringduration : Double

1

0..*

1

0..*

0..*

0..*

+preceeding 0..*

+following

0..*



PIF• PIF (Process Interchange Format) est issu

des besoins de diverses organisations (MIT, DEC, Stanford) de partager leurs modèles de processus. Les spécifications de PIF définissent à la fois un méta-modèle de processus et une syntaxe basée sur KIF.

• Le projet PIF a débuté en octobre 1993 et la notation a progressivement évolué au cours des années.

• une ontologie est un ensemble structuré de concepts permettant de donner un sens aux informations

• Aujourd’hui PSL et PIF sont en train de fusionner pour intégrer des concepts de processus tertiaires et industriels dans une seule et unique ontologie. Le noyau du méta-modèle de PIF définit un ensemble d’entités plus ou moins minimal. Cet ensemble de base peut être enrichi en utilisant le mécanisme d’extension appelé Partially Shared View (PSV). Un module PSV hérite du module racine (le noyau du méta-modèle) ou d’un autre module PSV. Ce nouveau module PSV définit de nouvelles entités en spécialisant des entités d’autres entités déjà définies dans des modules de plus haut niveau.



PIF

• PIF définit un processus comme un ensemble d’activités qui ont des relations entre elles ainsi qu’avec des objets à des moments dans le temps. Tous ces concepts héritent d’une entité commune nommée Entity .



PIF

Le concept d’Activity définit tout ce qui arrive dans le temps, que ce soit un processus, une tâche ou même un événement. Les Timepoints peuvent être soit des dates précises soit des instants indéfinis (par exemple l’instant auquel une tâche prend fin, ou un événement survient). Les Objects représentent toutes les autres entités impliquées dans un processus. Cette notion recouvre les artifacts, les données, les outils, ou même les acteurs humains ou mécaniques (Agent). Toutes ces entités sont reliées par des relations



PSL du NIST

•L’objectif de PSL (Process Specification Language) est de définir une ontologie et un format standards pour l’échange de processus industriels. •PSL définit un méta-modèle noyau basé sur des théories fondamentales qui définit les concepts et les relations de base. En plus de ce module de base, un certain nombre d’extensions ont été prédéfinies. Chacun de ces modules spécialise une des entités basiques (ainsi l’extension ProcessorAction spécialise le concept d’Activity tandis que l’extension ResourcePools raffine la notion d’Object).



PSL

• L’ontologie PSL définit un processus comme un ensemble d’activités (activity) dans lequelles sont impliquées des objets (object) à des instants donnés (timepoint). Dans PSL tout est activité, objet ou instant. PSL introduit également la notion d’occurrence d’activité (activity_occurrence). Cette base minimale est enrichie dans des modules d’extension qui définissent par exemple des activités non déterministe, des quantités sur les objets ou un ordonnancement temporel sur les instants.



CPR• CPR (Core Plan Representation)

est un projet du DARPA qui se concentre principalement sur la planification (spécification d’une liste d’actions ayant pour but de répondre à un ensemble d’objectifs) ainsi que sur la prévision (spécification des moments auxquels seront réalisés les activités et des quantités de ressources utilisées).

• CPR a pour but de modéliser un plan, c’est-à-dire un ensemble d’actions réalisées pour répondre à des objectifs. Les concepts de CPR sont les actions (Action), les acteurs (Actor), les objectifs (Objective) et les ressources (Resource). Une action est réalisée par un acteur pour accomplir des objectifs. Des ressources peuvent être consommées lors de la réalisation d’une action. L’acteur d’une action peut être la ressource d’une autre.



Aspects statiques et dynamiques du CPR

• Le méta-modèle présenté précédemment est prévisionnel et ne permet pas de mettre en relation un modèle de plan avec ses occurrences.

• C’est dans ce but qu’a été ajouté le concept de WorldModel qui permet de représenter des instances de plan.

• L’exécution d’un plan est structurée de la même manière que sa conception mais alors qu’une conception prévoit la façon dont doivent se dérouler les occurrences, l’exécution du plan représente ce qui s’est effectivement passé.



Workflow Management Coalition (WfMC)

• La Workflow Management Coalition (WfMC) est un consortium international d'éditeurs de worfklow, d'utilisateurs, d'analystes et de groupes de recherches donc l'objectif est de promouvoir l'utilisation du workflow. La WfMC propose un modèle de référence de processus qui définit le méta-modèle de processus ci-dessous :



Unified Process Model

UPM /SPEM• UPM (Unified Process Model) est une réponse à un RFP

de l’OMG sur la gestion du processus de développement logiciel, proposition conjointe d’entreprises telles IBM, Rational ou DMR.

• Ce méta-modèle est déjà utilisé pour définir le RUP (Rational Unified Process), un processus de développement logiciel outillé et distribué par Rational.



Le modèle conceptuel de base

Role

activity (artifact)activity (artifact)



Composant processus

• Un composant processus est un élément de modèle dont la structure interne est suffisamment consistante pour être réutilisée avec ou à l'intérieur d'un autre composant de processus.

• Ce mécanisme est possible dès lors que le composant de processus possède une certaine "autonomie" envers les contraintes et les autres éléments du modèle. On distingue deux types de composants de processus : les disciplines et les processus. • Les disciplines partitionnent les activités en les regroupant par thèmes de

l’ingénierie logicielle. Par exemple besoins, analyse, spécification, conception, implémentation…

• De ce fait, les activités sont incluses dans les disciplines selon qu’elles ont des guides de travail et des produits de travail (de sortie) du même thème. Les disciplines ont un rôle central dans la classification des activités liées aux métiers de l’entreprise. Une activité n’appartient qu’à une et une seule discipline.



Composants processus

A process component must be self-contained and all included elements must conform to meta-model constraints

Discipline ActivityKind(f rom Process Structure)

1 0..*1 0..*

Process

This partially redefines the includes association

ProcessComponent

ProcessLibrary

ProcessDefinitionElement(from Basic Elements)

0..*

0..*

0..*

0..*

Includes

1

0..*

1

0..*

IsOwnedBy



Chaque discipline est pilotée par un modèle



Définition de travail

Une Définition de Travail est une entité abstraite.C’est un élément de modèle (issu du paquetage ModelElement)qui décrit une unité de travail (pouvant être composée d’autres définition de travail).Elle précise les opérations à appliquer sur les produits de travaildans le cadre d’un rôle bien défini qui devra la réaliser. Une Définition de Travail est toujours accompagnée de Contraintes :les Buts et les Préconditions. Ces contraintes sont définiescomme des expressions booléennes sur les états des Produits De Travailassociés à la Définition de Travail.Elles marquent des conditions de début et de finpour l’exécution de la Définition de Travail.

Une Activité, la principale sous-classe de Définition de Travail,a un objectif clair, exprimé en terme d’états sur les Produits de Travail.



Différentes définitions de travail

• CycleDeVie : un CycleDeVie est composé d'une séquence de Phases, afin d'atteindre un but spécifique. Un CycleDeVie définit le comportement d'un processus : un processus est gouverné par un CycleDeVie.

• Phase : une Phase est une étape importante dans un processus. La précondition d'une Phase définit son critère d'entrée, et son but, son critère de sortie. Les Phases sont ordonnées dans le temps. Elles sont composées d'Itérations.

• Itération : Une Itération est une Définition de Travail moyennement importante (de niveau intermédiaire entre une Phase et une Activité). Elle est composée d'Activités.

• Activité : une Activité est composée d'étapes, qui sont elles-mêmes le plus bas niveau d'une Définition de Travail. Elle est composée d’Etapes, qui ne sont pas des Définitions de Travail, donc n'ont par conséquent pas de Produits de Travail d'entrée et de sortie.



Rôle, définition de travail, produit de travail, etc.

Activity Activité

ActivityParameter ParamètreDActivité

Goal But

Guidance Guide

GuidanceKind TypeDeGuide

InformationElement ElementDInformation

Iteration Itération

LifeCycle CycleDeVie

ModelElement ElementDeModele

Process Processus

ProcessComponentComposantDeProcessus

ProcessPerformerExécutantDeProcessus

ProcessRole Rôle

Step Etape

WorkDefinition DéfinitionDeTravail

WorkProduct ProduitDeTravail



Les guides

Les guides permettent d’apporter un supplément d’information à un élément de modèle. Ces informations servent de support et d’aide pour les développeurs. Ils servent à préciser le contexte de travail, les outils à utiliser ou des informations techniques. Par exemple les spécifications UML peuvent servir de Guide pour une activité de conception.



Le paquetage "Guidance"

Checklist UML Profile Guideline

Guidance(from Basic Elements)

TechniqueTemplate

+ link : URLToolMentor

ToolKind

0..*

1

0..*

1


Estimate

+ effort : int



Principaux types de guides

• Technique : Une technique y est détaillé, expliquant les démarches et procédures pour produire un produit de travail.

• Profil UML : Il définit des règles à appliquer, des éléments de modèle UML à prendre en compte…

• Liste de vérification : Un document précisant les éléments qui ne sont pas encore validés ou qui nécessitent des modifications.

• Mentor d’outil (ToolMentor) : Un guide expliquant comment utiliser un outil particulier pour réaliser une activité.

• Directive : Un ensemble de règles et de recommandations sur la façon de faire et les attentes pour des produits de travail, pour suivre des standards de fabrication par exemple.

• Calibre (Template) : ce type de guide définit un format standard au moyen d'un document prédéfini, afin de permettre le bon formatage d'un Produit de Travail (par exemple les spécifications UML dans le cas d'un diagramme de classe).

• Estimation : Il apporte des informations sur des efforts particuliers qui ont été réalisés sur un élément particulier, on pourrait imaginer par exemple un composant logiciel qui aurait été développé avec un objectif de fiabilité très élevé.



SPEM

• Le méta-modèle UPM comprend six paquetages :1. Names définit les

mécanismes de nommage2. Basic Elements définit les

éléments de base qui seront enrichis dans les paquetages de plus bas niveau

3. Process Structure définit les concepts majeurs, tels que les artefacts, les rôles ou les unités de travail

4. Process Lifecycle définit les règles d’exécution du processus

5. Guidance définit des moyens de documenter chacun des éléments du processus

6. Process Components définit les mécanismes de packaging



Hiérarchie des entités de SPEM

L’élément de plus haut niveau d’UPM est l’élément de définition de processus ou ProcessDefinitionElement qui est spécialisé à un degré ou un autre par tous les concepts définis dans le méta-modèle. Un élément peut être documenté par un mode d’emploi (Guidance), qui est un support pouvant prendre différentes formes (instructions, liste de contrôles, mode opératoire, etc). Des éléments peuvent être organisés en ensembles cohérents en utilisant des composants (ProcessComponent). Ces mécanismes permettent de définir aussi bien des processus complets que des bibliothèques d’éléments réutilisables.



Noyau du méta-modèle SPEM•Un processus est

principalement défini par trois concepts de base :

•L’activité (ActivityKind) qui est une parcelle de travail et qui peut avoir un objectif (Goal) et des pré-conditions (Precondition). Il n’y a pas de post-condition, l’objectif étant considéré couvrir cette notion.

•Le rôle (RoleKind) qui réalise ou assiste à la réalisation d’activités. Il peut être de surcroît responsable d’artefacts. Il pourra être affecté à une ou plusieurs personnes à l’exécution.

•L’artefact (ArtifactKind) représente tous les types d’information produite ou consommée durant le processus. Il peut être en entrée ou en sortie d’une activité. On peut associer à un artefact un ensemble d’état, permettant par la suite d’exprimer des conditions (Condition).



Les éléments de base

ArtifactKindRoleKind WorkItem

DependencyKind

NamedElement(from Names)

+ internalName : String

Guidance

Dependency

0..*

1

0..*

kind 1

VisibleName

+ externalName : Unicode11..* 11..*

ProcessDefinitionElement

1..*

0..*

1..*

0..*

1

0..*

to1

0..*

1 0..*from1 0..*

Language

1

0..*

1

0..*

TextualDescription

+ content : sequence<octet>+ format : enum{pdf, html, doc}

11..* 11..*

1

0..*

1

0..*



Le paquetage "Process Structure"

ArtifactKind(from Basic Elements)

+ isDeliverable : Boolean

WorkItem(from Basic Elements)

Step ActivityKind1

1..*

1

1..*

WorkDefinitionName(from Names)

ArtifactName(from Names)

RoleKind(from Basic Elements)

0..10..* performer0..10..*

0..* 0..*0..* assistant 0..*

WorkDefinition

0..*

1

0..*

1

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

0..*

0..1

0..*

0..1

IsResponsibleFor

ArtifactUsageName(from Names)

+ isInput : Boolean+ isOutput : Boolean+ hasWorkPerArtifact : Boolean

1

0..*

1

0..*

1

0..*

1

0..*IsOfKind



Paquetage "Process LifeCycle"

Iteration LifecyclePhase

10..* 10..* 11..* 11..*

Actual ly, these relationships are derived from the decomposition of WorkDefini tion, using WorkDefinitionName


ArtifactKind(from Basic Elements)

ArtifactStateSet

1..*

0..1

1..*

0..1

HasStates

WorkDefinition(from Process Structure)

Precondition1

0..1

1

0..1

ArtifactState

1

1..*

1

1..*

Goal10..1

10..1

ArtifactUsageName(from Names)

Process(from Process Components)

ArtifactInState

1

0..*

1

0..*

1

0..*

1

0..*

Condition

0..1

1..*

0..1

1..*



Propositions d'icônes

• RoleKind

• ActivityKind

• ArtifactKind,• Simple Artifact

• ArtifactKind,• Document

• ArtifactKind,• Model

• ArtifactKind,• Aggregate of Artifacts

• WorkDefinition

• ProcessComponent

• Process



Exemple de composant processus et de diag. d'activités

DesignModel

Designer

+IsResponsibleFor

+performer

Reviewer

+assistant

+performer

+performerArchitecting

DetailedDesign

Review

Initial DesignProcessComponent

ClassDesign

UseCaseDesign



Le processus SPEM doit être outillé

Décrire un Use Case

Use case package

Use case

responsable pour

Analyste

Artefact

Un élément d'information produit, modifié ou utilisé par un processus.

Rôle

Un rôle joué par un individu appartenant à une équipe

ActivitéUne unité de travail



Modèles exécutables

Modèles exécutables



Différentes sortes de modèles

Model

ask()

System

ask()

represents

Dynamic System

StaticSystem DynamicModel

StaticModel

S D

S o n

D o osy

stèm

e

modèleLa carte est un modèle statiqued'un système statique.

Autre exemple, un recensement.



Réseaux de Petri



Fin du cours

MerciQuestions ?Commentaires ?

Jean Bé[email protected] ATLAS, INRIA & IRIN, Nantes

Documents

Ingénierie des systèmes logiciels © 2003 ATLAS Nantes. - 1 - Ingénierie des Modèles Logiciels Cours #7 Les modèles de processus Jean Bézivin [email protected]