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