La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "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"— Transcription de la présentation:

1 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Ingénierie des Modèles Logiciels Cours #7 Les modèles de processus Jean Bézivin Equipe ATLAS (INRIA & IRIN), Nantes

2 Ingénierie des systèmes logiciels © 2003 ATLAS 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èle de 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

3 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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:

4 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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).

5 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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.

6 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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.

7 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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.

8 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Coopération Client/Fournisseur Client Fournisseur Développeur Spécifications Système opérationnel spécifications produit état #1 produit état #2 produit état #i système opérationnel Pb: collaboration client-développeur Pendant le développement.

9 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Méthode Unifiée?

10 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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.

11 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Rappel : l'image globale (roadmap) Procedural ADM OOADM e.g. OMT UML UPM SPEM > / /1997 Network of models + profiles + other MMs + specific processes (RUP, IBM SI, etc.) Method = notation + process + tools Model weaving Unified Method: impossible 1. Comment séparer les aspects ? 2. Comment tisser les aspects ?

12 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Les schémas de développement : une grande variété ? t0t0 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

13 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Les schémas de développement : une grande variété Exploitation, Maintenance Évolution Codage Conception Préliminaire Conception détaillée Analyse Tests fonctionnels Tests dintégration Etude des besoins vérif Tests unitaires Le schéma en V

14 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Evolution vers le processus unifié de Rational (RUP) Functional testing Performance testing Requirements mgmt Conf. and change mgmt Business engineering Data engineering UI design Rational Unified Process Rational Objectory Process Objectory Process Approche Ericcson Approche Rational UML

15 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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 dadéquation Enrichissement dune 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.

16 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Approche itérative et incrémentale Lordonnancement des itérations est basée sur les priorités entre cas dutilisation et sur létude du risque Chaque prototype réduit une part du risque Un prototype est un programme exécutable qui peut sévaluer quantitativement Un prototype donné est construit avec des buts précis et clairement exprimés Lévaluation du prototype est effectuée par rapports à ces buts Lenchaînement des prototypes est décrit dans le plan des prototypes Les priorités et lordonnancement de construction des prototypes peuvent changer avec le déroulement du plan IHM Système Tranche P1P3 P2

17 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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

18 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Phases et itérations Preliminary Iteration(s) iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1 InceptionElaborationConstructionTransition Iterations Phases Requirements Design Implementation Test Analysis Une itération dans la phase d'élaboration

19 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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.

20 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Importance croissante de la prise en compte des processus Qui fait quoi, quand, comment et pourquoi ?

21 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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)?

22 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Qu'est ce qu'un processus ? Processus de génie logiciel Système nouveau ou modifié Spécifications nouvelles ou modifiées Comment définir ceci de façon précise, automatisable et contrôlable?

23 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes UML n'est pas suffisant Développement en équipe Langage de modélisation Processus unifié

24 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Un repas à la Tour d'Argent... ou ailleurs Le procédé de fabricationLe procédé de consommation Le produit (le repas)

25 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Un repas à la Tour d'Argent... ou ailleurs

26 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Modèles de processus Modèles de processus

27 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Modèles de produits et modèles de processus MOF UML UPM Cobol EJB Java etc. Similaires aux structures de données Similaires aux structures de contrôle Workflow Corba Artefacts Processus

28 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Diagrammes de Gantt Les diagrammes de Gantt ont été créés par Henry Gantt dans les années Un diagramme de Gantt permet de décrire lensemble des activités dun processus sous la forme de barres placées sur un calendrier. On a ainsi une vue graphique de lensemble 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 dune date de début et dune date de fin.

29 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Diagrammes de PERT Les PERT (Program Evaluation and Review Technique) ont tout dabord é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 dautres activités. Contrairement à une activité d'un diagramme de Gantt, une activité d'un PERT ne définit pas de date.

30 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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 Aujourdhui 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 dentités plus ou moins minimal. Cet ensemble de base peut être enrichi en utilisant le mécanisme dextension appelé Partially Shared View (PSV). Un module PSV hérite du module racine (le noyau du méta-modèle) ou dun autre module PSV. Ce nouveau module PSV définit de nouvelles entités en spécialisant des entités dautres entités déjà définies dans des modules de plus haut niveau.

31 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes PIF PIF définit un processus comme un ensemble dactivités qui ont des relations entre elles ainsi quavec des objets à des moments dans le temps. Tous ces concepts héritent dune entité commune nommée Entity.

32 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes PIF Le concept dActivity 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 linstant 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

33 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes PSL du NIST Lobjectif 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 dextensions ont été prédéfinies. Chacun de ces modules spécialise une des entités basiques (ainsi lextension ProcessorAction spécialise le concept dActivity tandis que lextension ResourcePools raffine la notion dObject).

34 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes PSL Lontologie PSL définit un processus comme un ensemble dactivité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 doccurrence dactivité (activity_occurrence). Cette base minimale est enrichie dans des modules dextension qui définissent par exemple des activités non déterministe, des quantités sur les objets ou un ordonnancement temporel sur les instants.

35 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes CPR CPR (Core Plan Representation) est un projet du DARPA qui se concentre principalement sur la planification (spécification dune liste dactions ayant pour but de répondre à un ensemble dobjectifs) 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, cest-à-dire un ensemble dactions 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 dune action. Lacteur dune action peut être la ressource dune autre.

36 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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. Cest dans ce but qua été ajouté le concept de WorldModel qui permet de représenter des instances de plan. Lexécution dun plan est structurée de la même manière que sa conception mais alors quune conception prévoit la façon dont doivent se dérouler les occurrences, lexécution du plan représente ce qui sest effectivement passé.

37 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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 :

38 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Unified Process Model UPM/SPEM UPM (Unified Process Model) est une réponse à un RFP de lOMG sur la gestion du processus de développement logiciel, proposition conjointe dentreprises 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.

39 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Le modèle conceptuel de base

40 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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 lingénierie logicielle. Par exemple besoins, analyse, spécification, conception, implémentation… De ce fait, les activités sont incluses dans les disciplines selon quelles 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 lentreprise. Une activité nappartient quà une et une seule discipline.

41 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Composants processus

42 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Chaque discipline est pilotée par un modèle

43 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Définition de travail Une Définition de Travail est une entité abstraite. Cest un élément de modèle (issu du paquetage ModelElement) qui décrit une unité de travail (pouvant être composée dautres définition de travail). Elle précise les opérations à appliquer sur les produits de travail dans le cadre dun 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éfinies comme des expressions booléennes sur les états des Produits De Travail associés à la Définition de Travail. Elles marquent des conditions de début et de fin pour lexé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.

44 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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 dEtapes, 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.

45 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Rôle, définition de travail, produit de travail, etc. ActivityActivité ActivityParameterParamètreDActivité GoalBut GuidanceGuide GuidanceKindTypeDeGuide InformationElementElementDInformation IterationItération LifeCycleCycleDeVie ModelElementElementDeModele ProcessProcessus ProcessComponentComposantDeProcessus ProcessPerformerExécutantDeProcessus ProcessRoleRôle StepEtape WorkDefinitionDéfinitionDeTravail WorkProductProduitDeTravail

46 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Les guides Les guides permettent dapporter un supplément dinformation à un élément de modèle. Ces informations servent de support et daide 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.

47 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Le paquetage "Guidance"

48 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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 doutil (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é.

49 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes SPEM Le méta-modèle UPM comprend six paquetages : 1. Names définit les mécanismes de nommage 2. 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 dexé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

50 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Hiérarchie des entités de SPEM Lélément de plus haut niveau dUPM 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 demploi (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.

51 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Noyau du méta-modèle SPEM Un processus est principalement défini par trois concepts de base : Lactivité (ActivityKind) qui est une parcelle de travail et qui peut avoir un objectif (Goal) et des pré- conditions (Precondition). Il ny a pas de post-condition, lobjectif étant considéré couvrir cette notion. Le rôle (RoleKind) qui réalise ou assiste à la réalisation dactivités. Il peut être de surcroît responsable dartefacts. Il pourra être affecté à une ou plusieurs personnes à lexécution. Lartefact (ArtifactKind) représente tous les types dinformation produite ou consommée durant le processus. Il peut être en entrée ou en sortie dune activité. On peut associer à un artefact un ensemble détat, permettant par la suite dexprimer des conditions (Condition).

52 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Les éléments de base

53 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Le paquetage "Process Structure"

54 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Le paquetage "Names"

55 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Paquetage "Process LifeCycle"

56 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Enactment

57 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Propositions d'icônes RoleKind ActivityKind ArtifactKind, Simple Artifact ArtifactKind, Document ArtifactKind, Model ArtifactKind, Aggregate of Artifacts WorkDefinition ProcessComponent Process

58 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Exemple de composant processus et de diag. d'activités

59 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Un diagramme de dépendance d'artefacts dans la méthode SI d'IBM

60 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes 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

61 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Modèles exécutables

62 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Différentes sortes de modèles SD Son Doo système modèle La carte est un modèle statique d'un système statique. Autre exemple, un recensement.

63 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Réseaux de Petri

64 Ingénierie des systèmes logiciels © 2003 ATLAS Nantes Fin du cours Merci Questions ? Commentaires ? Jean Bézivin Equipe ATLAS, INRIA & IRIN, Nantes


Télécharger ppt "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"

Présentations similaires


Annonces Google