Le Processus Unifi de Rational

1
Le Processus Unifié de Rational

• Laurent Henocque
• http//laurent.henocque.free.fr/
• Enseignant Chercheur ESIL/INFO France
• http//laurent.henocque.perso.esil.univmed.fr/
• mis à jour en Novembre 2006

2
Licence Creative Commons

• Cette création est mise à disposition selon le
  Contrat Paternité-Partage des Conditions
  Initiales à l'Identique 2.0 France disponible en
  ligne
• http//creativecommons.org/licenses/by-sa/2.0/fr/
  
• ou par courrier postal à Creative Commons, 559
  Nathan Abbott Way, Stanford, California 94305,
  USA.

3
Références

• Le site Wikipedia
• http//en.wikipedia.org/wiki/Rational_Unified_Proc
  ess
• et les références associées

4
Objectif de ce document présenter le Processus
Unifié de Rational

• Définir ce quest un processus de développement
  logiciel
• Décrire le processus unifié de Rational
• Expliquer les 4 phases du processus unifié de
  Rational et leurs jalons associés
• Définir les itérations et leurs relations
• Expliquer les relations entre
• Les modèles et les enchaînements dactivités
• Les phases, itérations, et enchaînements
  dactivités
• Définir artéfacts, rôles, activités
• Evaluer limportance des outils logiciels

5
A quoi sert un processus logiciel ?

• Un processus logiciel fournit une approche pour
  assigner des tâches et des responsabilités à
  lintérieur dune organisation.
• Un processus permet la production dun logiciel
  de haute qualité avec un temps et un budget
  limité.

6
Dans la construction dun système, un langage ne
suffit pas.
Équipe de développement
Langage de Modélisation
Processus unifié
UML nest pas un standard pour les processus de
développement logiciel.
7
Quest ce que UML ?

• Le Langage unifié de Modélisation (UML) est un
  langage pour
• Spécifier
• Visualiser
• Construire
• Documenter
• Le choix dun modèle a une profonde influence sur
  la façon dont un problème est traité et dont la
  solution est conçue.

8
Histoire d UML
1994 OMT, Booch 1995 Unified Method 0.8 (Dr.
Ivar Jacobson) 1996 UML 0.9 (Use-Case) 1997
UML 1.0 (Microsoft, Oracle, IBM, HP) 1997 UML
1.1 2004 UML 2.0
9
Histoire dUML

• UML est aujourdhui le langage standard
  industriel de modélisation. Son développement à
  été lancé par trois leaders dans lindustrie de
  lapproche objet
• Grady Booch
• Ivar Jacobson
• Jim Rumbaugh.
• UML est en développement depuis 1990.

10
Les contributions à UML
Booch
Rumbaugh
Jacobson
11
Les contributions à UML
Le développement dUML à été fait par un large
échantillon de lindustrie HP, ICON Computing,
IBM, I-Logix, Intellicorp, MCI Systemhouse,
Microsoft, ObjectTime, Oracle, Platnium,
Technology, Ptech, Reich Technologies, Softeam,
Sterling Software, Taskon, et Unisys.
12
UML fournit des diagrammes standardisés
13
Représentation sous différents angles de vue dun
système

• Les diagrammes de cas dutilisation pour
  illustrer les interactions des utilisateurs avec
  le système
• Les diagrammes de classes pour illustrer la
  structure logique
• Les diagrammes dobjets pour illustrer les objets
  et les liens
• Les diagrammes détats pour illustrer leur
  déroulement
• Les diagrammes de composant pour illustrer les
  structures physiques du logiciel
• Les diagrammes de déploiement pour montrer la
  répartition du logiciel pour les configurations
  hardware
• Les diagrammes dinteractions (i.e., les
  diagrammes de collaboration et de séquence) pour
  illustrer leur comportement
• Les diagrammes dactivité pour illustrer le
  déroulement des activités dans un cas
  d'utilisation.

14
Un diagramme représentatif dUML Cas
dutilisation
Un système denregistrement aux cours dans une
université
15
Diagrammes de cas dutilisation

• Les diagrammes dutilisation sont utilisés pour
  montrer lexistence de cas dutilisation.
• Un acteur est une entité extérieure au système
  qui à une interface avec le système, tel qu'un
  utilisateur.
• Un cas dutilisation modélise un dialogue entre
  les acteurs et le système. Il est initialisé par
  un acteur.

16
Un diagramme de classes
Un système denregistrement aux cours dans une
université
ltltboundarygtgt
ltltboundarygtgt
Ecran Gestion Edt
Ecran
0..1
1
1
// gérerUnEmploiDuTemps()
// ouvrir()
// choisir 4 cours obligatoires et 2 facultatifs
1
1
ltltcontrolgtgt
1
0..
ControlleurEnregistrement
ajout de cours() lire la liste des cours()
0..1
1
ltltentitégtgt
Planning
créer un cours()
17
Les diagrammes sont les artefacts clés
Diagramme de cas dutilisation
Diagramme de classe
Diagramme détat transition
Use-Case 1
Acteur A
Acteur B
Use-Case 2
Diagramme de déploiement
Use-Case 3
Classe
Diagramme de paquetage
Définition dune interface utilisateur
Forward Engineering(Code Generation) and
Reverse Engineering
Diagramme de Collaboration
Diagramme de composant
Codage, compilation, debugage, édition de lien
Diagramme de séquence
Programme exécutable
18
Les diagrammes sont les artefacts clés

• UML fournit un langage unique et commun de
  modélisation utilisable à travers plusieurs
  méthodes,
• Il définit le lien entre les coûts, les exigences
  et lanalyse, le design, limplémentation, et les
  tests.
• UML facilite la communication entre tous les
  membres de léquipe de développement.

19
Quest ce quun processus ?
Un processus définit qui fait quoi, quand et
comment pour atteindre un objectif donné.
Le Processus Unifié de Rational est un processus
générique qui utilise UML comme langage de
modélisation.
Exigences nouvelles ou améliorées
Système nouveau ou amélioré
Processus dingénierie logicielle
20
Un Processus Efficace
Lobjectif dun processus est de produire un
logiciel de haute qualité en respectant des
contraintes de délai, de coûts et de performance

• Fournit les lignes directrices pour un
  développement efficace dun logiciel de qualité
• Réduit les risques et améliore les prévisions
• Décrit les meilleures méthodes de travail pour
• apprendre des expériences précédentes
• lamélioration du support de formation
• Établit une vision et une culture commune

21
Un Processus Efficace

• Facilité de mise en uvre grâce aux six
  meilleures pratiques de Rational, le processus
  est facile à mettre en oeuvre.
• Il dicte au développeur comment implémenter en
  utilisant les outils standards de développement.

22
Le Processus Unifié de Rational permet les
Meilleures Pratiques (Best Practices)

• Le processus Unifié Rational décrit comment
  appliquer les six directives de lingénierie
  logicielle

(Ré)Utiliser ComposantsArchitectures
Analyser les Besoins
Contrôler la Qualité
Modeler Visuellement (UML)
Contrôler le Changement
23
Le Processus Unifié de Rational permet les
Meilleures Pratiques (Best Practices)

• Les six meilleures pratiques fournissent les
  bases pour le Processus Unifié de Rational.
• Cependant, cette application nécessite des
  instructions étapes par étapes.
• Ces instructions sont fournies dans le Processus
  Unifié de Rational, qui comprend toutes les
  activités devant être appliquées pour construire
  un logiciel

24
Processus Unifié Rational

• Un processus centré sur l'architecture et la vue
  41

25
Processus Unifié de Rational dans un cas
dutilisation
Un acteur est une entité hors du système qui
interagit avec le système Un Cas dutilisation
est une séquence dactions que le système exécute
qui retourne un résultat à un certain acteur
Cas dutilisation pour une caisse
26
Processus Unifié de Rational dans un cas
dutilisation

• Le processus Unifié de Rational gère les besoins
  via les diagrammes de Cas dutilisation.
• Ils sont utilisés à travers le cycle de
  développement pour beaucoup dactivités, et
  fournissent de linformation à travers plusieurs
  modèles.
• Un acteur peut-être un être humain ou un autre
  système ou un appareil tout ce qui est extérieur
  au système et interagissant avec lui.
• Les cas dutilisation représentent toutes les
  façons possibles dutiliser le système.

27
Les Cas dutilisation incluent les Flots
dévènements

• Exemple flot dévènements dans le cas dun
  retrait dargent
• 1. Le cas dutilisation commence quand le
  client insère sa carte de payement. Le système
  lit et valide les informations sur la carte.
• 2. Le système lit le code PIN. Le système valide
  le code PIN.
• 3. Le système demande au client quelle opération
  il veut exécuter. Le client choisi Retrait
  dargent
• 4. Le système demande le montant. Le client entre
  le montant.
• 5. Le système demande le type de compte. Le
  client choisi vérifier et enregistrer.
• 6. Le système communique avec le réseau ATM . . .

28
Les apports des Cas dutilisation

• Les Cas dutilisation sont concis, simples, et
  compréhensibles par une large gamme de
  participants
• Utilisateurs finaux, développeurs et acquéreur
  comprennent les exigences fonctionnelles du
  système
• Les Cas dutilisation permettent bon nombre
  dactivités dans le processus
• La création et la validation de la conception du
  modèle
• La définition de cas de test et de procédures du
  modèle de test
• Le planning des itérations
• La création de documentation utilisateur
• Le déploiement du système
• Les Cas dutilisation permettent de
  synchroniser le contenu de plusieurs modèles

29
Le processus Unifié de Rational est
Architecture-Centré

• L'architecture est le point traité pendant les
  premières itérations
• Construire, valider, et fonder larchitecture
  constituent le premier objectif de lélaboration
• Le Prototype Architectural valide larchitecture
  et sert de base pour le reste du développement
• Le document de larchitecture logicielle est le
  premier artefact qui décrit larchitecture
  choisie
• Dautres artéfacts dérivent de larchitecture
• Documents de conception qui comprennent
  lutilisation de patterns et didiomes
• La structure du produit
• La structure de l'équipe

30
Le processus Unifié de Rational est
Architecture-Centré

• Larchitecture est utilisée dans le Processus
  Unifié de Rational comme un artefact primaire
  pour conceptualiser, construire, gérer, et
  élaborer le système en développement.
• Le Processus Unifié de Rational considère le
  développement et la validation dune architecture
  logicielle comme le concept primordial.
• Il définit 2 artefacts primaires
• la description de larchitecture logicielle qui
  décrit larchitecture du projet
• le prototype de larchitecture.

31
Représentation de larchitecture Le Modèle 41
Vue logique
Vue dimplémentation
Analystes/Concepteurs
Fonctionnalités
Programmeurs Génie logiciel
pour lutilisateur final
Cas dutilisation
Structure
Vue du processus
Vue de déploiement
System Engineering
Topologie du système Livraison,
installation communication
32
Représentation de larchitecture Le Modèle 41

• Une vue de larchitecture est la description dun
  système dun point de vue particulier, couvrant
  certains points et en omettant certains autres.
• Le Processus Unifié de Rational identifie 4 vues
  1
• La vue logique concerne les exigences
  fonctionnelles du système. Elle identifie la
  plupart des paquetages, sous-systèmes et classes.
• La vue dimplémentation décrit lorganisation des
  modules du logiciel.

33
Représentation de larchitecture Le Modèle 41

• La vue du processus concerne les aspects
  concurrents du système à lexécution taches,
  threads ou processus, et leur interaction.
• La vue de déploiement montre comment les
  différents exécutables sont structurés dans la
  plate-forme ou les différents nuds.
• La vue des cas dutilisation contient les
  scénarios principaux qui sont utilisés pour faire
  fonctionner larchitecture et pour la valider.

34
Les bénéfices dun processus Architecture-Centré

• Gagner et conserver un contrôle intellectuel sur
  le projet, contrôler sa complexité, et maintenir
  lintégrité du système.
• Fournir une méthode pour une réutilisation à
  grande échelle
• Fournir des bases pour la gestion de projet
• Faciliter le développement par composant
• Un composant remplit une fonction définie dans le
  contexte dune architecture bien définie
• Un composant fournit la réalisation physique
  dune série dinterfaces
• Les composants existent dans une architecture
  donnée

35
Processus Unifié Rational

• Le processus dans le temps

36
Architecture du Processus Les Cycles de vie
Démarrage
Élaboration
Construction
Transition

• Le Processus Unifié de Rational comprend 4 phases
  
• Démarrage - Définit le champ daction du projet
• Élaboration Le plan du projet, il spécifie les
  exigences, les bases de larchitecture
• Construction Réalise le produit
• Transition - Transfère le produit vers les
  utilisateurs finaux

37
Architecture du Processus Les Cycles de vie

• Durant létude dopportunité (démarrage), nous
  définissons lobjectif du projet.
• en identifiant tous les acteurs et les cas
  dutilisation, et en dessinant les cas
  dutilisation essentiels (20 du modèle).
• Un plan de gestion de projet est fait pour
  déterminer les ressources nécessaires pour le
  projet.
• Durant lélaboration, on se concentre sur deux
  choses
• avoir une bonne connaissance des besoins (90) et
  
• établir une base de larchitecture.
• Ainsi, on peut éliminer beaucoup de risques,
  avoir une bonne idée de ce qui doit être fait, et
  une bonne estimation des ressources et des coûts.

38
Architecture du Processus Les Cycles de vie

• Durant la Construction, on développe le produit
  en plusieurs itérations pour une version bêta.
• Durant la Transition, on prépare le produit pour
  lutilisateur final et la formation,
  linstallation, le support.
• Pour un projet très complexe lélaboration peut
  inclure jusquà 3-5 itérations.

39
Le Processus Unifié De Rational Vision
temporelle
40
RUP et Vision Temporelle phase de démarrage

• Première analyse des fonctionnalités (diagramme
  dutilisation)
• Évaluer les risques (coût, concurrence)
• Critères dévaluation
• Concurrence
• Première validation des besoins
• Évaluation des coûts, priorités, risques, du
  processus de développement, des frais réels par
  rapport aux frais prédits.

41
RUP et Vision Temporelle phase délaboration

• Planifier les activités nécessaires et les
  ressources requises.
• Définir précisément les fonctionnalités de
  lapplication.
• Concevoir larchitecture.
• Critères dévaluation
• Stabilité du produit et de la conception.
• Résolution des problèmes critiques.
• Évaluation des coûts, du planning.
• Validation du produit.

42
RUP et Vision Temporelle Phase de Construction

• Construire le produit comme une série
  ditérations incrémentales.
• Critères dévaluation
• Stabilité et maturité des réalisations (en vue du
  déploiement)
• Capacité de mettre en uvre la transition.
• Coûts acceptables.

43
RUP et Vision Temporelle Phase de Transition

• Fournir le produit aux utilisateurs
• Fabrication
• Livraison
• Formation
• Critères dévaluation
• Validation des besoins (Recette)

44
RUP et Vision Temporelle Jalons dÉvaluation

• Après chacune des quatre phases on évalue les
  activités grâce à des critères spécifiques
• Évaluation Coût/risque réaliste.
• Validation du produit.
• Architecture valide et réalisable.

45
RUP Et Vision TemporelleSous Jalons
Dévaluation et Itérations

• Chaque phase peut elle-même comporter des
  (0..N) jalons. Entre deux jalons, on parle
  ditérations.
• Une itération est est une séquence dactivités
  planifiées et pouvant être vérifiées grâce à un
  critère dévaluation.
• But vérifier les activités au fur et à mesure.
• Deux types
• Internes au sein de léquipe de développement.
• Externes avec le client et idéalement les
  utilisateurs finaux

46
Processus Unifié Rational

• Rôles et Activités

47
RUP et vision par activités

• La modélisation métier possibilités du système
  et besoins des utilisateurs.
• La modélisation des besoins vision du système
  et besoins détaillés des utilisateurs.
• Lanalyse et la conception manière dont sera
  réalisé le projet au cours de la phase 4.
• Limplémentation production et acquisition des
  composants du système et des exécutables.
• Les tests vérification du système dans son
  ensemble.
• Le déploiement livraison du système et
  formation des utilisateurs.

48
Les 2 Visions Rassemblées Le Modèle Itératif
Flux (workflow) du processus
Démarrage
Élaboration
Construction
Transition
Flux de gestion
Iter.n1
Iter.n2
Iter.m
Iter.m1
Iter.1
Iter.2
Iter.n
49
RUP Définitions et Notations(1/2)

• Artéfact Élément dinformation, produit ou
  utilisé lors dune activité de développement
  logiciel (modèle, source...)
• Activité Opération exécutée au sein dun état.
  Une activité peut être interrompue.
• Rôle Comportement et responsabilités dun
  ensemble de personnes.

50
RUP Définitions Et Notations(2/2)
51
Les Rôles Dans La Planification Des Ressources
Ressource Paul Marie Joseph Sylvia Stefanie
Rôle Concepteur Rédacteur. D.Utilisation
Analyste Système Développeur. Architecte
Activités Définir Opérations Détailler le D.
Utilisation Trouver Acteurs et Cas Util. Réaliser
les tests des unités. Concevoir.
Chaque individu est associé à un ou plusieurs
rôles.
52
Modélisation Métier

• Pour comprendre la dynamique et la structure de
  lorganisation.
• Pour vérifier que les clients, les utilisateurs
  finaux, et léquipe ont une vision commune exacte
  de lorganisation.
• Pour vérifier la concordance entre les besoins et
  lorganisation.

53
La modélisation métier
Trouver les acteurs et les cas dutilisation
Analyste de la modélisation métier
Lister le vocabulaire commun
Finaliser les
Vérificateur Modèle métier
cas dutilisation
Détailler les cas dutilisation
Revoir les modèles métier des cas dutilisation
Détailler les acteurs métier
Concepteur métier
Trouver les entités et les acteurs métier
Revoir les modèles métier des objets
Détailler les entités métier
54
Modélisation Des Besoins

• Valider les fonctionnalités du système avec le
  client et les utilisateurs.
• Donner à léquipe de développement une idée des
  besoins auxquels le système doit répondre.
• Définir les limites du système.
• Définir une base pour planifier les activités
  associées à chaque itération.
• Définir une IHM du système.

55
Modélisation Des Besoins
Développer Vision
Définir les besoins pour les jalons
Trouver les acteurs et cas dutilisation
Structurer le modèle cas dutilisation
Coordonner les dépendances
Lister le vocabulaire commun
Détailler les cas dutilisation
Vérifier les besoins
Définir IHM
Prototyper IHM
Hiérarchiser les cas dutilisation
56
Modélisation Des Besoins Artefacts

• Un document de vision.
• Un document listant les besoins de chaque jalon.
• Un document sur les cas dutilisation
• Un document de spécification supplémentaire ce
  que va faire précisément le système.
• Glossaire
• Story-board des cas dutilisation.
• Une charte graphique

57
Analyse et Conception

• Passer des besoins à une architecture concrète.
• Concevoir une architecture robuste pour le
  système
• Permettre que le système soit adapté à son
  environnement.

58
Analyse et Conception
Analyser larchitecture
Définir le déploiement
Concevoir larchitecture
Définir la concurrence
Responsable vérification architecture
Planifier la vérification architecture
Concevoir les sous systèmes
Analyser les cas dutilisation
Concevoir les cas dutilisation
Responsable vérification conception
Planifier la vérification conception
Concevoir les classes
Concevoir la base de données
Concepteur Base de données
59
Analyse et Conception artéfacts

• Le modèle de conception
• Les descriptions de cas dutilisation
• Les descriptions de classes
• Lorganisation en sous système
• Les documents sur larchitecture logicielle
• Le modèle de données

60
Implémentation

• Définir lorganisation des modules et des sous
  systèmes implémentés.
• Implémenter les composants (classes et objets).
• Tester les composants un par un.
• Utiliser les composants produits par différentes
  personnes pour construire le système.

61
Implémentation
Structurer le Modèle dimplémentation
Architecte
Responsable intégration système
Intégrer
Planifier lintégration du système
Système
Intégrer les sous systèmes
Planifier Lintégration des Sous-systèmes
Implémenter
les Classes
Développeur
Tester les unités
Fixer les solutions
Responsable vérification Code
Vérifier le Code
62
Implémentation Artéfacts

• Le modèle dimplémentation qui définit les
  composants.
• Les composants.
• Le plan dintégration des composants.

63
Tests

• Vérifier les interactions entre les composants.
• Vérifier lintégration des composants logiciels.
• Vérifier que tous les besoins ont été
  correctement implémentés.
• Identifier les défauts et les signaler au
  déploiement.

64
Tests
Tester implémentation
Planifier Tests
Concevoir Tests
Concepteur des tests
Evaluer
Test
Tests d'Intégration
Testeur de lintégration
Tests Système
Testeur système
Testeur performances
Tests de Performance
Concevoir les classes de Test
et Packages
Concepteur
Implémenter le sous système de tests
développeur
65
Tests Artéfacts

• Modèle de test définition et procédures.
• Planification des tests.
• Revue de défauts.
• Tests des paquetages, classes, sous systèmes, et
  composants.

66
Gestion de projet

• Définir un environnement de travail pour la
  gestion de projet.
• Fournir des documents à propos de la
  planification, de la répartition des tâches, de
  lexécution et de la vérification des projets.
• Définir un environnement de travail pour la
  gestion des risques.

67
Gestion de projet
Exécuter litération
Mener une étude de cas métier
Identifier
Vérifier litération
Les Risques
Planifier litération
Développer plan de gestion de projet
Réunir Équipe
Chef de projet
Réviser la liste des risques
68
Gestion De Projet artéfacts

• La procédure de développement logiciel (Liste des
  risques, plan de projet et procédure dactions)
• Les cas dutilisation métier
• La planification des itérations
• Lestimation des itérations
• Lestimation des statuts

69
Déploiement

• Permet de faire évoluer correctement (Erreurs,
  spécifications) les systèmes logiciels au cours
  de leurs différentes versions.
• Lister les différentes versions des composants
  utilisés au cours des différentes versions du
  logiciel.

70
Déploiement
Chef de projet
Architecte
Responsable gestion du changement
Documenter le défaut
Tout membre de léquipe
Intégrateur
71
Déploiement avantages

• Encourager les bonnes méthodes de développement.
• Maintenir lintégrité du produit.
• Sassurer de la complétude et de la correction du
  produit déployé.
• Fournir un environnement de développement stable.
• Limiter les changements des artéfacts dus aux
  règles internes (policy) du projet.
• Permettre de suivre les changements des artéfacts.

72
Processus Unifié Rational

• Points de vue extérieurs

73
Point de vue sur le Workflow

• Déployer les processus.
• Améliorer les processus.
• Sélectionner les bons outils et les maîtriser.
• Développer des outils.
• Aider le développement.
• Sentraîner.

74
Règles, Tutoriaux et Modèles

• Les règles sont les obligations, recommandations,
  les heuristiques qui aident lexécution des
  activités.
• ex règles de codage
• Les tutoriels aident à lapprentissage des outils
  utilisés lors des activités.
• ex Tutoriels de Rationnal Rose ou Poseidon
• Les modèles (formulaires) sont des artéfacts
  prédéfinis.
• Ex Un document ayant déjà une structure à
  remplir.
• Leur but est de rendre lexécution des activités
  plus facile et que les processus soient
  correctement menés à bien.

75
Liste d'Outils Daide Au Développement.
Activités de base
Modèle métier Besoins Analyse et
conception Implémentation Test Déploiement Confi
g. Changement Gestion de projet Environnement
Requisite Pro, Rose, SoDA
Requisite Pro, Rose, SoDA
Rose, SoDA, Apex
Rose, Apex, SoDA, Purify, ...
SQA TeamTest, Quantify, PerformanceStudio,...
SoDA, ClearCase, ...
Activités de support
ClearCase, ClearQuest
Unified Process, Microsoft Project, ...
Unified Process, Rational Tools
76
Suivre Un Processus

• Il faut adapter et exécuter le processus.
• Adapter suivant les besoins et les contraintes de
  lorganisation. Cela fournit un document avec le
  contexte, les limites, une évaluation de la
  proportion des changements par rapport au
  processus initial
• Exécuter en faisant les changements nécessaires
  dans le processus.

77
RUP Résumé(1/3)

• UML est un langage de spécification,
  visualisation, construction, et documentation des
  artéfacts dun système à composante logicielle.
• Un processus de développement logiciel répond aux
  questions qui, quoi quand et comment.

78
RUP Résumé(2/3)

• Le RUP a quatre phases démarrage, élaboration,
  construction et transition.
• Chaque fin de phase est ponctuée par un jalon
  principal et la fin dune ou plusieurs
  itérations.
• Une itération est une suite de diverses activités
  qui ont été planifiées, ayant des critères
  dévaluation, et pouvant être exécutées.

79
RUP Résumé(3/3)

• Chaque enchaînement dactivité dure une itération
  et sinscrit dans un modèle incrémental.
• Artéfact Élément dinformation, produit ou
  utilisé lors dune activité de développement
  logiciel(modèle)
• Activité Opération exécutée au sein dun état.
  Une activité peut être interrompue.
• Rôle Comportement et responsabilités dun
  ensemble de personnes