Architectures Orientées Services Méthodologies de spécification

Transcription

1 Architectures Orientées Services Méthodologies de spécification Module 8 Mise en œuvre de méthodologies MDA/SOA Praxeme avec l atelier de génie logiciel Objecteering 1

2 Plan du module Rappel sur les grandes notions de spécification informelle semi formelles formelle Le métamodèle de Softeam pour l application de la méthodologie Praxeme Les profils de gestion des exigences implémentés dans Objecteering 2

3 Notions de spécifications formelles, semi formelles, informelles Spécification formelle Description d un objet et son fonctionnement de façon complète et sans ambiguïté Spécifications «semi formelles» Description des aspects d un objet, sans prétention de complétude Réponse à une nécessité cognitive d un intermédiaire entre les spécifications informelles et les spécifications formelles Spécifications informelles Description d un objet au travers un discours en langage naturel Compréhensible par un humain, mais difficilement par une machine Redondant, ambigu, incomplet, contradictoire, 3

4 Notions de spécifications formelles, semi formelles, informelles Un document PowerPoint est un support informel Où l incomplétude, la redondance et la contradiction est possible UML est un langage semi formel de spécification UML est un support de descriptions partielles, Sans contraintes d intégrité Non prouvable UML est pragmatique Le MOF est formel Ce qui a été nécessaire pour la construction d ateliers de génie logiciel MDA OCL langage formel de contraintes vise à pallier les insuffisances de UML Seuls des «profils» UML peuvent réaliser des spécifications formelles Ils ont l inconvénient de leur complexité Les méthodes B, Z, LOTOS, ELOTOS, sont des méthodes formelles exploitées pour des systèmes automatiques industriels OWL est formel OWL est ouvert à toutes les représentations graphiques de tout aspect décrit 4

5 Un exemple de spécification formelle : Lego Mindstorm Le code assemblé comme des pièces de Lego 5

6 Théorie et pragmatisme des spécifications L industrie du logiciel utilise encore pour l essentiel des spécifications informelles D'après Gartner, en 2002 moins de 15 % des projets de développement (toutes tailles confondues) sont conduits avec un outil UML. A tel point que selon Jacques Mercey, " le premier outil employé pour faire de l'uml est le traitement de texte Word ". Même constat pour David Duquenne, d'improve, qui précise : " Word présente l'avantage d'être lisible par tout le monde, y compris des clients, et cela apporte une certaine souplesse" (source 01net) 15% des projets utiliseraient des méthodes semi formelles (UML) Combien de projets utilisent des méthodes formelles? Privilégiant ADA, ou B, à l exclusion de C, C++, Java, Python, PhP? quelques projets de systèmes à grands enjeux de sécurité Contrôle commande en industrie aérospatiale Conduite de réseaux de chemin de fer? 6

7 Citations (issues de 01Net) Pour Jacques Mercey, (vice président de la R&D de l'éditeur Mega) " UML n'est pas conçu pour faire du BPM. Il est bâti pour modéliser les applications. Si on l'optimise pour faire du BPM, cela devient contre productif car on créé une ambiguïté en mélangeant ce dernier et la modélisation d'application." selon David Duquenne (directeur technique projets et méthodes de la société Improve) " Il n'y a pas d'outil UML de type presse bouton, explique t il. Les raisons : le code généré n'est pas forcément adapté au modèle de développement en vigueur et les générateurs, tel celui intégré dans Rose de Rational, ajoutent des lignes de code qui polluent la lecture et perturbent les développeurs" 7

8 CACM, Dobing and Parsons report (2006) In asking the question, reasons for not using some UML components, some findings are intriguing: a. 50% said that Class Diagrams were not well understood by analysts, 48% said that Activity Diagrams were not well understood by analysts. b. 42% said that Statechart Diagrams were not useful for most projects. c. 42% said that Use Case Diagrams have insufficient value to justify cost and that were not useful with programmers. d. 49% said that Collaboration Diagrams would capture redundant information. The median typical UML project had a budget of around $1, 000,000 and 6.5 person years and required 50,000 lines Of respondents previous projects, 27 (average), only 6, 2 (23%) used UML! 8

9 Pragmatisme en l état de l art Application d UML dans une démarche de tracé des spécifications selon Praxeme Exemple Objecteering 9

10 Métamodèle Objecteering pour l application de Praxeme 10

11 Métamodèle transposé en OWL dans Protégé 11

12 Avatar UML d une interprétation ontologique 12

13 Métamodèle Objecteering pour l intégration de la terminologie 13

14 Métamodèle Objecteering pour le dictionnaire 14

15 Métamodèle Objecteering pour la définition de propriétés 15

16 Métamodèle Objecteering pour les exigences Les règles métiers et les objectifs sont deux sous classes d exigences 16

17 Métamodèle Objecteering pour les exigences (suite) Structuration d ensembles d exigences 17

18 Ensemble de propriétés 18

19 Valeurs de propriétés 19

20 Typage des propriétés Liste fermée : texte, booléen, entier, réel, date 20

21 Type énumération 21

22 Exigences 22

23 Structure des éléments de l atelier Objecteering 23

24 Création d un projet dans Objecteering 24

25 25

26 Le projet créé 26

27 Déploiement de profils UML ScopeManager et ScopeAdmin 27

28 Incorporation des profils SOA et BPMN, (même méthode) Drag&drop 28

29 Choisir le répertoire scope 29

30 Charger ScopeManager avant ScopeAdmin 30

31 Déploiement de profils UML Scope et Admin (suite) 31

32 L environnement créé 32

33 Glossaire des termes de l interface de Scope Manager Business rule: A statement that defines or constrains some aspect of the business that is intended to assert business structure or influence business behavior. Business rule container: A group of business rules used in a project. Dictionary: A set of terms used in a project. Goal: A high level objective of the business, organization or system, providing a framework for the desired system. Goal container: A group of goals defined for a project. Property: A characteristic of a Scope element (for example, its priority level). Property set: A group of properties used in a project. Requirement: A function which must be included in the software or system developed, in order to satisfy a contract, specification, standard or other formally defined constraint. Requirement container: The physical grouping of a set of requirements. Scope element: A general term referring to requirements, terms, goals and business rules. Scope structuring element: A general term referring to requirement containers, dictionaries, goal containers and business rule containers. Term: An item of vocabulary identified by a name, which has a clear definition in the context of the system which is to be developed. Traceability: A kind of correspondence between different elements represented. Typically, traceability links are used to express which UML model elements represent which requirements or terms. 33

34 Création d un ensemble (conteneur) d exigences 34

35 Renseignement en langage naturel d une exigence 35

36 Diagramme de présentation graphique d exigences 36

37 Collecte des objectifs stratégiques 37

38 Collecte de règles métier 38

39 Collecte d une terminologie (selon Softeam) 39

40 Sémantique Praxeme : modèle sémantique Se réfère à Pragmatique Situe Géographique applique Logique implémente Logiciel formalise Technique déploie utili se Physique contraint héberge Matériel exploite 40

41 Praxeme : Modèle d organisation d entreprise Sémantique Se réfère à Pragmatique Situe Géographique applique Logique implémente Logiciel formalise Technique déploie utili se Physique contraint héberge Matériel exploite 41

42 Praxème : Modèle géographique Sémantique Se réfère à Pragmatique Situe Géographique applique Logique implémente Logiciel formalise Technique déploie utili se Physique contraint héberge Matériel exploite 42

43 Praxeme : Architecture logique Sémantique Se réfère à Pragmatique Situe Géographique applique Logique implémente Logiciel formalise Technique déploie utili se Physique contraint héberge Matériel exploite 43

44 Praxeme : Diagramme d habilitation Sémantique Se réfère à Pragmatique Situe Géographique applique Logique implémente Logiciel formalise Technique déploie utili se Physique contraint héberge Matériel exploite 44

45 Cartographie applicative 45

46 Organisation en couches 46

47 Bonne pratique de composants (source Softeam) 47

48 Diagramme de déploiement (source Softeam) 48

49 Fin du module 49