Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

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

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

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

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

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,

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

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

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

5

Un exemple de spécification formelle : Lego Mindstorm®

• Le code assemblé comme des pièces de Lego®

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

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• …?

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

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"

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

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!

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

9

Pragmatisme en l’état de l’art

Application d’UML dans une démarche de tracé des spécifications selon Praxeme

Exemple Objecteering

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

10

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

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

11

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

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

12

Avatar UML d’une interprétation ontologique

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

13

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

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

14

Métamodèle Objecteering pour le dictionnaire

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

15

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

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

16

Métamodèle Objecteering pour les exigences

• Les règles métiers et les objectifs sont deux sous classes d’exigences

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

17

Métamodèle Objecteering pour les exigences (suite)

• Structuration d’ensembles d’exigences

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

18

Ensemble de propriétés

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

19

Valeurs de propriétés

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

20

Typage des propriétés

• Liste fermée : texte, booléen, entier, réel, date

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

21

Type énumération

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

22

Exigences

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

23

Structure des éléments de l’atelier Objecteering

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

24

Création d’un projet dans Objecteering

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

25

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

26

Le projet créé

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

27

Déploiement de profils UML ScopeManager et ScopeAdmin

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

28

Incorporation des profils SOA et BPMN, (même méthode)

Drag&drop

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

29

Choisir le répertoire scope

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

30

Charger ScopeManager avant ScopeAdmin

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

31

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

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

32

L’environnement créé

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

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.

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

34

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

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

35

Renseignement en langage naturel d’une exigence

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

36

Diagramme de présentation graphique d’exigences

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

37

Collecte des objectifs stratégiques

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

38

Collecte de règles métier

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

39

Collecte d’une terminologie (selon Softeam)

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

40

Praxeme : modèle sémantiqueSémantique

Pragmatique

Géographique

Logique

Logiciel

Technique

Matériel

Physique

Se réfère à

Situe

formalise

applique

contraint

implémente

utilise

déploie

héberge

exploite

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

41

Praxeme : Modèle d’organisation d’entreprise

Sémantique

Pragmatique

Géographique

Logique

Logiciel

Technique

Matériel

Physique

Se réfère à

Situe

formalise

applique

contraint

implémente

utilise

déploie

héberge

exploite

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

42

Praxème : Modèle géographiqueSémantique

Pragmatique

Géographique

Logique

Logiciel

Technique

Matériel

Physique

Se réfère à

Situe

formalise

applique

contraint

implémente

utilise

déploie

héberge

exploite

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

43

Praxeme : Architecture logique Sémantique

Pragmatique

Géographique

Logique

Logiciel

Technique

Matériel

Physique

Se réfère à

Situe

formalise

applique

contraint

implémente

utilise

déploie

héberge

exploite

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

44

Praxeme : Diagramme d’habilitationSémantique

Pragmatique

Géographique

Logique

Logiciel

Technique

Matériel

Physique

Se réfère à

Situe

formalise

applique

contraint

implémente

utilise

déploie

héberge

exploite

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

45

Cartographie applicative

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

46

Organisation en couches

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

47

Bonne pratique de composants (source Softeam)

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

48

Diagramme de déploiement (source Softeam)

Cours MIAGE « Architectures Orientées Services »Henry Boccon-Gibod

49

Fin du module