Ingénierie des Modèles Logiciels Cours #7 Les modèles de processus

1. Ingénierie des Modèles LogicielsCours #7 Les modèles de processus Jean BézivinJean.Bezivin@irin.univ-nantes.fr 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: http://www.sciences.univ-nantes.fr/info/lrsg/Pages_perso/EB/Erwan.htm

4. 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. 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. Méthode Unifiée? Méthode Unifiée?

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

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

11. Le schéma en tunnel Analyse t0 Conception ? Codage Maintenance Le schéma en cascade Les schémas de développement : une grande variété • 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

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

13. 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 1996-1997 UML Objectory Process 1.0-3.8 Approche Rational 1987-1995 Approche Ericcson

14. 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. Unprocessus 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.

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

16. P h a s e s I n c e p t i o n E l a b o r a t i o n C o n s t r u c t i o n T r a n s i t i o n P r e l i m i n a r y i t e r . i t e r . i t e r . i t e r . i t e r . i t e r . i t e r . I t e r a t i o n ( s ) # 1 # 2 # n # n + 1 # n + 2 # m # m + 1 I t e r a t i o n s Phases et itérations Requirements Une itération dans la phase d'élaboration Analysis Design Implementation Test

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

18. Importance croissante de la prise en compte des processus Qui fait quoi, quand, comment et pourquoi ?

19. 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)?

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

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

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

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

24. Modèles de processus Modèles de processus

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

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

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

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

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

30. PIF Le concept d’Activitydé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

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

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

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

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

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

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

37. Le modèle conceptuel de base

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

39. Composants processus

40. Chaque discipline est pilotée par un modèle

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

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

43. 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 Rôle, définition de travail, produit de travail, etc.

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

45. Le paquetage "Guidance"

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

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

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

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

50. Les éléments de base