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 Modèles Logiciels Cours #7

Présentations similaires


Présentation au sujet: "Ingénierie des Modèles Logiciels Cours #7"— Transcription de la présentation:

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

2 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 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 Moteur d'exécution

3 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 Méthodes Définition : Petit Larousse
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 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 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 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 Coopération Client/Fournisseur
Spécifications Fournisseur Développeur Client Système opérationnel spécifications produit état #1 produit état #2 produit état #i Pb: collaboration client-développeur Pendant le développement. système opérationnel

9 Méthode Unifiée? Méthode Unifiée?

10 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 Rappel : l'image globale (roadmap)
Procedural ADM Method = notation + process + tools Unified Method: impossible OOADM e.g. OMT 11/1997 07/2001 UML + profiles + other MMs Model weaving UPM SPEM + specific processes (RUP, IBM SI, etc.) >2001 Network of models 1. Comment séparer les aspects ? 2. Comment tisser les aspects ?

12 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

13 Les schémas de développement : une grande variété
Le schéma en V Exploitation, Maintenance Évolution Codage Conception Préliminaire détaillée Analyse Tests fonctionnels d’intégration Etude des besoins vérif Tests unitaires

14 Evolution vers le processus unifié de Rational (RUP)
Rational Unified Process 5.0 Functional testing Performance testing Requirements mgmt Conf. and change mgmt Business engineering Data engineering UI design 1998 Rational Objectory Process 4.1 UML Objectory Process Approche Rational Approche Ericcson

15 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.

16 Approche itérative et incrémentale
L’ordonnancement des itérations est basée sur les priorités entre cas d’utilisation 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 L’enchaînement des prototypes est décrit dans le plan des prototypes Les priorités et l’ordonnancement de construction des prototypes peuvent changer avec le déroulement du plan IHM Système Tranche P1 P3 P2

17 Phases et itérations Des phases Des itérations Des incréments
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 Phases et itérations P h a s e Une itération dans la phase
c e p t i o E l a b o r t i n C o n s t r u c i T r a n s i t o Requirements Une itération dans la phase d'élaboration Analysis Design Implementation Test P r e l i m n a y I t o ( s ) i t e r . # 1 i t e r . # 2 i t e r . # n i t e r . # n + 1 i t e r . # n + 2 i t e r . # m i t e r . # m + 1 I t e r a i o n s

19 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 Importance croissante de la prise en compte des processus
Qui fait quoi, quand, comment et pourquoi ?

21 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 Qu'est ce qu'un processus ?
Comment définir ceci de façon précise, automatisable et contrôlable? Spécifications nouvelles ou modifiées Système nouveau ou modifié Processus de génie logiciel

23 Développement en équipe
UML n'est pas suffisant Développement en équipe Langage de modélisation Processus unifié

24 Un repas à la Tour d'Argent ... ou ailleurs
Le procédé de fabrication Le produit (le repas) Le procédé de consommation

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

26 Modèles de processus Modèles de processus

27 Modèles de produits et modèles de processus
MOF Processus Artefacts Similaires aux structures de contrôle Similaires aux structures de données UML UPM Workflow Cobol Java Corba EJB etc. etc.

28 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 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.

29 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. Ces deux exemples simples montrent deux choses. D’une part les problématiques de représentation des processus sont relativement anciennes. D’autre part, même si un méta-modèle processus est toujours constitué plus ou moins des mêmes entités (activité, temps), certaines options peuvent être prises qui permettent de se focaliser sur tel ou tel aspect et qui vont à terme générer des capacités différentes. Ainsi le diagramme de Gantt permet de connaître la date du jour auquel doit débuter et finir chacune des activités du processus, alors que le PERT offre la possibilité de calculer le chemin critique.

30 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.

31 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 .

32 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

33 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).

34 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.

35 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.

36 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é.

37 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 : Le Workflow Process Definition représente le processus complet. Il est divisé en plusieurs activités (Workflow Process Activity) qui peuvent être atomiques (tâches élémentaires) ou être des appels vers des sous-processus. Ces activités sont ordonnancées grâce aux informations de transition (Transition Information) qui peuvent porter sur les données pertinentes pour le workflow (Workflow Relevant Data). Elles sont réalisées par quelqu'un (ou quelque chose) défini comme un participant (Workflow Participant Specification) et elles peuvent invoquer des applications externes via des déclarations d'application (Workflow Application Declaration). A noter que le concept de donnée pertinentes pour le workflow ne recouvre pas l'ensemble des données manipulées pendant un processus, mais la sous-partie de ces données qui est utilisée dans les conditions de transition, dans les règles d'affectation d'une tâche à un participant ou dans l'invocation d'une application externe.

38 UPM /SPEM Unified Process Model
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.

39 Le modèle conceptuel de base

40 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.

41 Composants processus

42 Chaque discipline est pilotée par un modèle

43 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 travail dans 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é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 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.

44 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.

45 Rôle, définition de travail, produit de travail, etc.
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 ProcessComponent ComposantDeProcessus ProcessPerformer ExécutantDeProcessus ProcessRole Rôle Step Etape WorkDefinition DéfinitionDeTravail WorkProduct ProduitDeTravail

46 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.

47 Le paquetage "Guidance"

48 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é.

49 SPEM Le méta-modèle UPM comprend six paquetages :
Names définit les mécanismes de nommage Basic Elements définit les éléments de base qui seront enrichis dans les paquetages de plus bas niveau Process Structure définit les concepts majeurs, tels que les artefacts, les rôles ou les unités de travail Process Lifecycle définit les règles d’exécution du processus Guidance définit des moyens de documenter chacun des éléments du processus Process Components définit les mécanismes de packaging

50 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.

51 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).

52 Les éléments de base

53 Le paquetage "Process Structure"

54 Le paquetage "Names"

55 Paquetage "Process LifeCycle"

56 Enactment

57 Propositions d'icônes ArtifactKind, RoleKind ActivityKind
Model Aggregate of Artifacts WorkDefinition ProcessComponent Process RoleKind ActivityKind ArtifactKind, Simple Artifact Document

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

59 Un diagramme de dépendance d'artefacts dans la méthode SI d'IBM

60 Le processus SPEM doit être outillé
Un rôle joué par un individu appartenant à une équipe Activité Une unité de travail Rôle Décrire un Use Case Analyste responsable pour Artefact Use case package Use case Un élément d'information produit, modifié ou utilisé par un processus.

61 Modèles exécutables Modèles exécutables

62 Différentes sortes de modèles
La carte est un modèle statique d'un système statique. Autre exemple, un recensement. système

63 Réseaux de Petri

64 Fin du cours Merci Questions ? Commentaires ? Jean Bézivin
Equipe ATLAS, INRIA & IRIN, Nantes


Télécharger ppt "Ingénierie des Modèles Logiciels Cours #7"

Présentations similaires


Annonces Google