Soutenance mémoire
CONCEPTION DE L’ARCHITECTURE DU <COMPUTATION INDEPENDENT MODEL> (CIM)
Ingénierie dirigée par les modèles (IDM)
L’ingénierie dirigée par les modèles (IDM) est une approche de développement logiciel qui focalise sur la création et l’exploitation des modèles plutôt que sur le code source (Kent, 2002). L’IDM consiste à définir un ensemble de modèles dans différents niveaux d’abstraction ainsi qu’un ensemble de règles de transformation permettant le passage d’un modèle source à un modèle cible. Les règles de transformation sont responsables de préserver la cohérence entre les différents modèles.
Le défi de l’IDM
Dans les années 1990, la communauté du logiciel a été influencée principalement par trois approches de développement logiciel : la méthode CASE (Computer Aided Software Engineering), les langages de quatrième génération (4GLs) et l’approche orientée-objet.
La méthode CASE et les outils logiciels qui la supportent étaient dispendieux et les approches propriétaires ont fait face à la présence croissante des approches ouvertes et gratuites. L’approche orientée-objet n’a pas tenue ses promesses (Jorgensen et al., 2002; Scholtz et al., 1993) mais a quand même réussi à remplacer les anciennes générations des langages de programmation. De ce fait, les outils de modélisation orientée-objet, profitant de la notation du standard UML et du désintérêt des deux approches CASE et 4 GLs, ont retenu l’attention (Thomas Stahl et al., 2006).
Les outils logiciels supportant le langage UML comme Rational Rose, dans ses versions 1997 et 2000, ne permettaient pas de synchroniser complètement le code source avec les modèles mais représentaient une méthode efficace pour générer de la documentation. C’est dans cette perspective que l’IDM vient combler cette faiblesse en augmentant le niveau d’abstraction afin de mettre l’accent sur les modèles. Le développement logiciel, d’après cette approche, se réalise en modélisant le logiciel à différents niveaux d’abstraction. À partir de règles de transformation spécifiques, ces modèles, dont les langages respectifs ont été rigoureusement définis à partir d’un méta-métamodèle unique, peuvent être transformés successivement du plus haut au plus bas niveau d’abstraction dans le but de générer le code source automatiquement. En somme, les modèles deviennent exécutables.
Les avantages de l’IDM
L’avantage visé par l’IDM est l’augmentation de la vitesse du développement logiciel grâce à l’automatisation : le code source peut être généré à partir des modèles en utilisant une ou plusieurs étapes de transformation. Ceci permet de réaliser un logiciel beaucoup plus rapidement. La durée allouée au développement ainsi qu’à la validation du produit logiciel en est donc raccourcie (Chris Raistrick et al., 2004; Selic, 2003; THE MIDDLEWARE COMPANY, 2003). Le site web de l’OMG (Object Management Group, 2010) expose plusieurs cas de projets logiciels qui se sont basés sur une architecture dirigée par les modèles. L’entreprise ABB (Interactive Objects Software GmbH) est un cas réussi parmi d’autres qui, selon Andreas Blaszczyk, de chez ABB a résumé : “The code quality produced by the ArcStyler’s model-based generation is consistent and clean, reducing the number of programmers and test engineers required to develop and maintain the test environments by approx. 45% compared to a conventional development approach.”. Dans ce contexte, les travaux de Parastoo et al., (Mohagheghi, Dehlen et Neple, 2009; Parastoo Mohagheghi et Vegard Dehlen, 2008) résument les avantages de l’IDM en focalisant sur la qualité des modèles.
• Traçabilité et synchronisation entre les modèles et le code source : dans une approche traditionnelle de développement logiciel, les modèles sont réalisés en marge de leur implémentation et le code source est généré manuellement, ce qui est demandant en temps. Ceci pose un problème majeur lors des modifications dans le code. En effet, elles sont rarement accompagnées d’une mise à jour dans les modèles (Chris Raistrick et al., 2004). L’IDM dans ce sens améliore la traçabilité et la synchronisation entre les modèles.
• Meilleure réutilisation des modèles : une fois définie, l’architecture du logiciel et les modèles peuvent être réutilisés dans d’autres systèmes (Mellor Stephen J et al., 2004).
• Logiciel de qualité : le code source généré à partir des modèles est, en principe, sans erreur parce que les modèles ont été testés et validés (ex. architecture JEE, .NET. etc).
Par conséquent, la qualité du logiciel devient dépendante de l’implémentation des concepts du domaine d’affaires plutôt que des éléments de l’architecture logicielle (Selic, 2003).
• Séparation des préoccupations : la réutilisation des modèles offre l’avantage de focaliser davantage sur les concepts liés aux domaines d’affaires plutôt qu’aux concepts liés à leur implémentation (Chris Raistrick et al., 2004; Selic, 2003).
En résumé, l’IDM vise à accroître la productivité du développement logiciel.
En revanche, il est important de mentionner que l’IDM reste une approche complexe qui sera maitrisée que par des spécialistes en architecture de logiciel. De plus, la difficulté de maintenir la cohérence entre les différents modèles représente un défi majeur.
Architecture dirigée par les modèles
En 2001, l’OMG a lancé une nouvelle approche baptisée Model Driven Architecture (MDA) (Joaquin Miller et Jishnu Mukerji, 2003) qui est une variante particulière de l’IDM.
L’essence de MDA est la création d’architectures logicielles exécutables dirigées par les modèles plutôt que l’écriture manuelle du code source. Le principe clé de MDA consiste à s’appuyer sur les standards UML pour décrire séparément les modèles des différents niveaux du cycle de développement logiciel. Les objectifs majeurs de MDA sont la portabilité, l’interopérabilité, la réutilisation, la maintenance et l’augmentation de la productivité.
Plus précisément, MDA préconise l’élaboration des quatre modèles suivants (Joaquin Miller et Jishnu Mukerji, 2003) :
• CIM (Computation Independent Model) est un modèle où aucune considération informatique n’y apparaît. Il modélise le domaine d’affaires et les exigences du système, en général par l’utilisation de modèles distincts (ex. processus d’affaires, cas d’utilisation, etc.). Il montre le système dans l’environnement organisationnel dans lequel il sera exécuté. Son but est d’aider à la compréhension du problème d’affaires, mais aussi fixer un vocabulaire commun pour les analystes et les architectes d’affaires. Les exigences exprimées dans le CIM doivent être traçables dans le PIM et le PSM. Il est à noter que le modèle CIM n’a été défini et ajouté à l’approche MDA qu’en 2003. L’OMG vise, par l’introduction du CIM, à combler le fossé entre les analystes d’affaires et les architectes du logiciel.
• PIM (Platform Independent Model) est un modèle qui décrit les concepts d’affaires du système sans montrer les détails de son utilisation sur une plateforme technologique particulière. Le PIM doit être raffiné par les détails d’une ou plusieurs architectures particulières pour obtenir un PSM.
• PSM (Platform Specific Model) est le modèle produit par la transformation du PIM. Il est adapté pour spécifier l’implémentation du système dans une seule et unique plateforme technologique.
• Code est la phase finale du développement soit la transformation de chaque PSM en code source. Le code source est considéré comme un modèle dans l’approche MDA.
En somme, le MDA prône l’utilisation de ces quatre modèles dans l’ordre suivant :
• réaliser le modèle des exigences CIM qui spécifie et représente le système dans son environnement;
• réaliser le modèle d’analyse PIM à partir des éléments du CIM;
• enrichir le PIM par des détails techniques relatifs aux choix de la plateforme d’exécution, pour obtenir le PSM;
• raffiner le PSM jusqu’à l’obtention du code source.
Les standards de l’OMG
MOF (Meta Object Facility)
Le MOF (Meta Object Facility) est un standard de l’OMG spécifié dans MOF 2.0 Core specification (OMG, 2004). Il représente la couche supérieure dans la hiérarchie des métamodèles de l’OMG et est situé au niveau M3, Son but est de spécifier d’autres métamodèles, qui, à leur tour spécifient des modèles comme UML. Le MOF permet d’échanger et de sérialiser les modèles entre eux via le standard XMI (XML Metadata Interchange). La spécification de MOF fournit un ensemble d’objets génériques et abstraits et leurs associations ainsi qu’un ensemble de règles pour créer et manipuler des métamodèles.
MOF et UML
UML est une instance et une application de MOF (OMG, 2010a). La notation du MOF est une syntaxe concrète d’UML. UML existait avant le MOF et n’avait pas une définition formelle. Le MOF est arrivé plus tard pour définir formellement UML d’où les révisions majeures d’UML (OMG, 2010a; 2010b) basées sur le MOF.
Dans le contexte de développement logiciel, il n’est pas coutume de créer un nouveau langage pour modéliser un domaine particulier mais plutôt d’essayer d’étendre un langage existant pour le rendre suffisamment apte à modéliser les concepts de ce domaine. Dans ce sens, UML, en s’appuyant sur le MOF, offre deux alternatives : extension basée sur le métamodèle et extension à l’aide des profils UML2.
Le CIM selon l’OMG
Les énoncés suivants résument cette définition du CIM :
1. Il est indépendant de toute computation;
2. Il ne montre pas les détails de la structure du système;
3. Il est souvent appelé le modèle de domaine ou le modèle d’affaires et utilise un vocabulaire familier aux praticiens du CIM;
4. Il permet de combler le fossé entre les experts du domaine d’affaires et les experts techniques;
5. Il montre le système dans l’environnement auquel il sera installé;
6. Les exigences du système sont modélisées dans le CIM;
7. Ses éléments doivent être traçables aux éléments du PIM.
Cet ensemble d’énoncés constitue un aperçu de ce qu’est un CIM. Toutefois, il ne définit pas précisément la structure des éléments constituants ce niveau de MDA qui, conformément à l’énoncé 7, est nécessaire pour être transformé en PIM. Certains travaux ont été réalisés dans cette direction (par exemple (Osis Janis, Asnina Erika et Grave Andrejs, 2009)), mais le manque de précision empêche une définition consensuelle. Lors de la création du CIM, l’analyste est ainsi laissé à ses expériences et sa créativité.
Vers une méthodologie de construction du CIM
Le BMM est neutre à l’égard de toute méthodologie. L’OMG préconise son utilisation comme un plan d’affaires pouvant supporter une variété de méthodologies : sa mise en œuvre se traduirait par un référentiel dans lequel ses éléments pourraient être emmagasinés, connectés, et liés à d’autres informations de l’organisation. L’OMG a proposé (OMG, September 2007 ) un exemple de méthodologie à suivre que nous avons retenu et avons complété pour généraliser cette méthodologie afin de construire le CIM.
CONCEPTION DE L’ARCHITECTURE DU <PLATFORM INDEPENDENT MODEL> (PIM)
Afin de proposer une structure générique du PIM ainsi que le processus permettant la transformation du CIM au PIM, nous devons examiner de nouvelles méthodes et techniques.
Pour cela, nous allons d’abord explorer les patrons d’affaires et les patrons d’exigence. Ceuci font référence aux processus d’affaires et aux cas d’utilisation, deux modèles principaux et essentiels dans la conception du CIM. Ensuite, nous étudierons les patrons d’analyse qui font référence au modèle de classe d’analyse que nous considérons comme modèle principal dans la conception du PIM.
Technologies reliées à la conception du PIM
Rational Unified Process (RUP)
Le RUP (Kruchten Philippe, 2000) est un cadre de développement logiciel d’une manière itérative. Il se propose comme un guide d’utilisation efficace d’UML et préconise six bonnes pratiques de développement de logiciels. Il définit un ensemble de neuf disciplines regroupant les activités du cycle de développement logiciel. Nous nous intéressons aux trois premières qui concernent la modélisation, les exigences d’affaires ainsi que l’analyse et la conception de système. En effet, ces trois disciplines font partie intégrante des modèles CIM et PIM. Elles sont :
• La modélisation d’affaires (Business modelling)
Cette discipline consiste à capturer, modéliser et analyser les processus d’affaires ainsi que les rôles et les responsabilités de chaque intervenant dans le domaine de problème. Les principaux artefacts sont le modèle de processus d’affaires et le modèle d’objet d’affaires. Le premier se base sur les cas d’utilisation d’affaires (business use case), représentant les objets d’affaires (au niveau conceptuel et non au niveau système) et le deuxième détaille davantage les services, les parties prenantes et les objets utilisés.
• Les exigences (Requirements)
Cette discipline définit le document de vision du système et identifie successivement les besoins des utilisateurs, les fonctionnalités du système et les exigences logicielles. Le modèle des cas d’utilisation représente l’artefact principal de cette discipline. Les cas d’utilisation sont décrits en détails et les exigences non fonctionnelles sont décrites comme des spécifications supplémentaires.
• L’analyse et la conception (Analysis and Design)
L’objectif de cette discipline réside dans la traduction des exigences logicielles, telles qu’exprimées dans le modèle des processus d’affaires et le modèle des cas d’utilisation, dans une représentation du système destinée aux développeurs. Les principaux artefacts sont :
Le modèle de classe d’analyse qui représente les objets d’affaires du domaine de problème;
Le modèle de classe de conception qui ajoute au modèle de classe d’analyse des objets système ainsi que d’autres détails techniques selon la plateforme d’exécution et le langage de programmation utilisé.
RUP et MDA
Bien que la modélisation des processus d’affaires puisse se faire de manière indépendante ou dans le cadre de la réingénierie des processus, elle ne fait qu’ajouter de la valeur au cycle de développement logiciel. Plus précisément, selon le RUP, la modélisation d’affaires contribue à définir les exigences systèmes.
En fait, un modèle d’affaires basé sur UML peut être une entrée directe vers un modèle d’exigences. RUP (John, 2003) définit la manière de transformer un modèle de processus d’affaires en un modèle de classe d’analyse comme suit :
• Un processus d’affaires (cas d’utilisation d’affaires dans le jargon RUP) qui doit être automatisé sera représenté par un cas d’utilisation. Il deviendra un sous-système (une fonction du système);
• Chaque entité d’affaires (objet d’affaires) se transforme en une classe dans le modèle de classe d’analyse.
Cette transformation nous est utile car elle s’aligne avec notre objectif, celui de transformer le CIM en PIM. En effet, elle consolide la validité de notre proposition des modèles constituants le CIM et le PIM : le modèle des processus d’affaires et le modèle des cas d’utilisation font partie du CIM et, le modèle de classe d’analyse fait partie du PIM.
Patrons d’affaires et patrons d’analyse
Les patrons identifient des solutions réutilisables aux problèmes récurrents. Le Gang of Four design patterns (Erich Gamma et al., 1994) sont les patrons les plus utilisés : ils représentent un ensemble de 23 patrons déduits des bonnes pratiques de conception de logiciels. Ils constituent ainsi une référence dans de nombreux cas et ils ont été adaptés à plusieurs architectures logicielles modernes. Les patrons GRASP (General Responsibility Assignment Software Patterns) (Larman, 2004) sont aussi largement utilisés : ils décrivent des règles pour affecter les responsabilités aux classes de conception en liaison avec la méthode de conception Boundary Control Entity (BCE).
L’utilisation des patrons semble faciliter grandement la conception de logiciel et la communication entre les architectes. Ils sont essentiels à l’approche MDA dans l’étape de génération d’un PSM à partir d’un PIM mais n’aident pas à concevoir le modèle d’analyse et le modèle d’affaires (Eric Lefebvre, 2005).
En effet, il existe une initiative (Wil van der Aalst et Arthur ter Hofstede, 1999) appelée workflow patterns initiée en 1999 qui s’intéresse à fournir une base conceptuelle à la technologie des processus d’affaires à différents points de vue (flux de contrôle, données, ressources et la gestion des exceptions). Ces patrons servent à évaluer la pertinence, les forces, les faiblesses et la compatibilité d’un langage de modélisation des processus d’affaires pour la réalisation d’un projet particulier.
Les patrons pouvant s’appliquer aux disciplines de RUP, les exigences logicielles (cas d’utilisation) et la phase de l’analyse sont encore rares et leurs utilisations sont limitée.
La modélisation en couleur à l’aide des archétypes
Durant le processus de développement des applications logicielles de gestion, l’expérience a démontré, mis à part le domaine d’affaires, l’apparition des mêmes types de classes d’analyse (Peter Coad, Eric Lefebvre et Jeff De Luca, 1999) qui se retrouvent d’un projet à l’autre.
Coad en a identifié quatre en les qualifiant d’archétypes : “ An archetype is a form from which all classes of the same kind more or less follow – including attributes, links, methods, plug-in points, and interactions”. À titre d’exemple, nous citons deux types de ces quatre archétypes :
• des classes qui représentent des transactions d’affaires ou des interactions de différents types comme les réservations, les locations, les commandes, les livraisons, les soumissions, etc.;
• des classes qui représentent des parties prenantes, des choses et des endroits qui participent à ces classes de transactions d’affaires : 1) des parties prenantes comme les personnes et les organisations qui effectuent des commandes, des achats et des réservations, etc. 2) des choses comme les produits et services vendus ou achetés. 3) des endroits comme des magasins et des bureaux où se passent toutes ces affaires, etc. Toutefois, cette identification de ces types de classe ne se limite pas seulement aux applications logicielles de gestion mais peut s’étendre, bien au-delà, comme les applications logicielles industrielles. Nous citons, à titre d’exemple, des classes qui modélisent des événements (périodes de temps d’une mesure), des parties prenantes (opérateurs), des endroits (lignes de production), et des choses (appareils de mesure).
Domain Neutral Component (DNC)
Un modèle de classe d’analyse peut être construit à l’aide des quatre archétypes. Dans certains cas, autour d’un seul et unique Moment-Interval et dans d’autres cas, autour de plusieurs. Selon la règle de la correspondance de l’archétype Moment-Interval avec une des activités du modèle de processus d’affaires, les Moments-Intervals se suivent, les uns auprès des autres selon l’ordre des enchaînements des activités du modèle de processus d’affaires.
Ceci indique qu’il est possible de lier des portions du diagramme de classe d’analyse via les Moment-Intervals. Par exemple, un Moment-Interval modélisant une livraison serait naturellement lié à un autre Moment-Interval modélisant une vente.
Si nous retenons l’idée de l’enchaînement des Moment-Interval selon un certain ordre en associant Moment-Interval à PriorMI et NextMI et que nous divisons l’archétype PPT en trois archétypes distincts Party, Place et Thing, en plus d’identifier les archétypes Role et Description, nous obtiendrons en connectant les 4 archétypes entre eux, un modèle générique appelé (Peter Coad, Eric Lefebvre et Jeff De Luca, 1999) Domain Neutral Component (DNC) .
Le DNC s’utilise comme un modèle de classe générique qui aide à accélérer le développement des applications logicielles. En fait, il suffit d’identifier la classe MomentInterval et les autres classes archétypes qui y sont reliées. Ensuite, il nous faut remplacer les classes constituant le DNC par les classes identifiées. Quand nous n’avons pas besoin d’une classe du DNC, il suffit de la supprimer pour simplifier le modèle de classe.
Méthode de construction du PIM
Pour construire le PIM, nous proposons la méthode décrite ci-dessous, basée sur les EBP, les archétypes et le DNC. Cette méthode utilise la correspondance (illustrée par le signe ↔) entre les éléments suivants :
• Un EBP ↔ un composant d’affaires (un seul composant processus + des composants entités) ↔ un seul cas d’utilisation ↔ un diagramme de classe (à l’aide des archétypes).
En voici les étapes :
Suite à l’activité de la modélisation des processus d’affaires :
1) Identifier les EBP dans chaque modèle de processus d’affaires;
2) Identifier dans chaque EBP l’élément dynamique (activité) et les éléments statiques (les objets ressources, produits et services, l’acteur responsable de la réalisation de l’activité).
Suite à la phase des exigences :
3) Décrire chaque EBP candidat à être automatisé par un cas d’utilisation;
4) Compléter les exigences (détailler les cas d’utilisation).
Suite à la phase des exigences nous pouvons construire le modèle de classe d’analyse (PIM) en suivant les étapes suivantes :
5) Définir la(les) classe(s) archétype MI.
Habituellement, une classe MI est associée à l’activité ou l’événement principal d’un EBP.
S’il existe plus d’une classe MI, les relier selon leur ordre chronologique. Ensuite, identifier les MI précédentes et les MI suivantes.
6) Sélectionner l’entité d’affaires MI-Detail selon les réponses aux questions suivantes :
Pour chaque classe MI :
Est-elle reliée au MI-Detail ?
Y a-t-il une entité d’affaires Party (une ou plusieurs) ?
Y a-t-il une entité d’affaires Place (généralement une) ?
Y a-t-il une entité d’affaires Thing (une ou plusieurs) ?
Pour chaque entité d’affaires Party, Place et Thing (PPT) :
Est-elle reliée à la classe MI ou à la classe MI-detail ?
7) Personnaliser les entités d’affaires PPT selon les réponses aux questions ci-dessous :
Pour chaque entité d’affaires PPT :
Y a-t-il un archétype Role ?
Y a-t-il un archétype Description ?
8) Personnaliser les archétypes :
Pour chaque classe :
Sélectionner les attributs et les méthodes génériques pour chaque archétype;
Personnaliser le nom de chaque archétype;
Ajouter des attributs et des méthodes spécifiques selon les besoins.
9) Finaliser le modèle de classe :
Personnaliser le diagramme de classe.
Cette méthode pourrait être supportée par un outil logiciel qui automatiserait ces neuf étapes.
|
Table des matières
INTRODUCTION
CHAPITRE 1 L’INGÉNIERIE DIRIGÉE PAR LES MODÈLES : MISE EN CONTEXTE DU CIM ET DU PIM
1.1 Introduction
1.2 Qu’est-ce qu’un modèle ?
1.3 Taxonomie des modèles
1.4 Modèles et métamodèles
1.5 Ingénierie dirigée par les modèles (IDM)
1.5.1 Le défi de l’IDM
1.5.2 Les avantages de l’IDM
1.6 Architecture dirigée par les modèles
1.7 Les standards de l’OMG
1.7.1 MOF (Meta Object Facility)
1.7.2 MOF et UML
1.7.3 Extension basée sur le métamodèle
1.7.4 Extension à l’aide des profils UML
1.8 Transformation des modèles
1.8.1 Définition
1.8.2 Taxonomie de transformation de modèles
1.8.2.1 Transformation endogène versus transformation exogène
1.8.2.2 Transformation horizontale versus transformation verticale
1.8.3 Techniques et approches de transformation
1.8.3.1 Langage impératif versus langage déclaratif
1.8.3.2 Langages de transformation graphiques (Graph transformation)
1.8.3.3 Approche basée sur des templates
1.8.3.4 Langage visuel versus langage textuel
1.8.4 Langages de transformation de modèles
1.8.4.1 QVT (Queries, Views, Transformations)
1.8.4.2 ATL (Atlas Transformation Language)
1.9 Mécanisme de transformation des modèles
1.10 Computation Independent Model (CIM)
1.11 Platform Independent Model (PIM)
1.11.1 Caractéristiques d’un archétype
1.12 Problématiques non abordées dans la littérature
CHAPITRE 2 OBJECTIFS ET MÉTHODOLOGIE DE RECHERCHE
2.1 Objectifs de recherche
2.2 Méthodologie de recherche
CHAPITRE 3 CONCEPTION DE L’ARCHITECTURE DU <COMPUTATION INDEPENDENT MODEL> (CIM)
3.1 Introduction
3.2 Le CIM selon l’OMG
3.3 Définition du CIM : notre proposition
3.3.1 Business Motivation Model (BMM)
3.3.2 Business Process Model (BPM)
3.3.3 Requirement Model (RM)
3.4 Vers un modèle générique du CIM
3.5 Vers une méthodologie de construction du CIM
3.6 Discussion
CHAPITRE 4 CONCEPTION DE L’ARCHITECTURE DU <PLATFORM INDEPENDENT MODEL> (PIM)
4.1 Introduction
4.2 Conception du PIM
4.3 Technologies reliées à la conception du PIM
4.3.1 Rational Unified Process (RUP)
4.3.2 RUP et MDA
4.3.3 Patrons d’affaires et patrons d’analyse
4.3.3.1 Les patrons de la modélisation d’affaires
4.3.3.2 Les patrons des exigences
4.3.3.3 Les patrons d’analyse
4.4 La modélisation en couleur à l’aide des archétypes
4.4.1 L’archétype Moment-Interval
4.4.1.1 Relation entre les Moment-Intervals
4.4.1.2 MI-detail
4.4.1.3 Les responsabilités du Moment-Interval
4.4.2 L’archétype Role
4.4.3 L’archétype Party-Place-Thing
4.4.4 L’archétype Description
4.5 Domain Neutral Component (DNC)
4.6 Comment construire le PIM à l’aide des archétypes en se basant sur l’EBP?
4.7 Méthode de construction du PIM
4.8 Étude de cas : réservation d’une chambre d’hôtel
4.9 Discussion
CHAPITRE 5 CONCEPTION DU MODÈLE DE PROCESSUS D’AFFAIRES POUR LE CIM
5.1 Conception du Business Process Model
5.1.1 Anatomie du BPM
5.1.2 Le patron EBP
5.1.3 Règles de cohérence du patron EBP
5.1.4 Catégorisation des patrons EBP
5.1.5 Sélection des Activities
5.1.6 Conception du BPM et de son métamodèle
5.1.7 Éléments du modèle des processus d’affaires et contraintes de conception
5.1.8 Procédure de conception du BPM
5.2 Conclusion
CHAPITRE 6 TRANSFORMATION DU <BUSINESS PROCESS MODEL> (BPM) EN <BUSINESS PROCESS COMPONENT> (BCM)
6.1 Introduction
6.2 Construction des composants d’affaires
6.2.1 Définitions : Qu’est ce qu’un composant d’affaires ?
6.2.2 Identification des composants d’affaires
6.2.3 Catégorisation des composants d’affaires
6.2.3.1 Composant-processus (Process Component)
6.2.3.2 Composant-entité (Entity Component)
6.2.4 Patron du composant d’affaires
6.2.5 Assemblage du modèle de composants d’affaires (BCM)
6.3 Proposition d’un nouveau diagramme UML des composants d’affaires
6.4 Règles de cohérence intra-BCM
6.5 Transformation du BPM en BCM
6.6 Procédure de transformation du BPM au BCM au niveau modèle
6.7 Transformation du BPM au BCM au niveau des métamodèles selon les profils proposés
6.8 Synthèse
CHAPITRE 7 TRANSFORMATION DU MODÈLE DES PROCESSUS D’AFFAIRES AU MODÈLE DES CAS D’UTILISATION
7.1 Du BPM à l’UCM : Règles de transformation
7.2 Vers un nouveau format de présentation du modèle de cas d’utilisation
7.2.1 Deux catégories de cas d’utilisation
7.2.2 Vers un métamodèle du profil de l’UCM
7.3 Synthèse
CHAPITRE 8 DOCUMENTATION DES CAS D’UTILISATION
8.1 Introduction
8.2 Gabarit d’écriture de cas d’utilisation
8.3 Types d’interaction dans un cas d’utilisation
8.4 Patrons de communication
8.4.1 Types de patrons de communication
8.4.1.1 Actor communication pattern (ACP)
8.4.1.2 System communication pattern
8.4.1.3 Verbes d’action manipulant des données dans le SCP
8.4.1.4 Verbes d’action manipulant un objet dans le SCP
8.5 Les règles de restriction dans l’écriture d’un cas d’utilisation
8.6 Cas d’utilisation visuel
8.6.1 Profil du métamodèle de cas d’utilisation visuel
8.6.2 Types d’interactions dans le cas d’utilisation visuel
8.6.3 Règles de contrôle du diagramme de cas d’utilisation visuel
8.7 Règles de transformation du cas d’utilisation textuel en cas d’utilisation visuel
8.8 Synthèse
CHAPITRE 9 DU CAS D’UTILISATION VISUEL AU DIAGRAMME DE CLASSE D’ANALYSE
9.1 Procédure de transformation du cas d’utilisation visuel en Diagramme de classe d’analyse
9.1.1 Étape de transformation automatique
9.1.2 Étape de transformation manuelle guidée par des questions
9.1.3 Étape de fusion des portions de diagrammes de classe
CHAPITRE 10 CAS D’ÉTUDE ET VÉRIFICATION DE LA MÉTHODOLOGIE DE TRANSFORMATION DU CIM EN PIM
10.1 Conception du modèle de processus d’affaires
10.1.1 Conception du modèle de processus d’affaires du service à la clientèle
10.1.2 Conception du modèle de processus d’affaires du service maintenance
10.2 Transformation du BPM en BCM
10.2.1 Transformation du BPM « Service à la Clientèle » au BCM
10.2.1.1 Application des règles de transformations automatiques
10.2.1.2 Application de la règle de transformation manuelle
10.2.2 Transformation du BPM du service maintenance ‘’Maintain Car’’ au BCM
10.2.3 Discussion
10.3 Du modèle des processus d’affaires au modèle des cas d’utilisation
10.3.1 BPM Service à la clientèle
10.3.2 BPM service de maintenance (Maintain Car)
10.3.3 Application des règles de transformation (chapitre 7.1)
10.3.3.1 Application des règles de transformation R1 et R2
10.3.3.2 Application de la règle de transformation R3
10.3.3.3 Application de la règle de transformation R4
10.3.3.4 Application de la règle de transformation R5
10.3.4 La construction du diagramme de cas d’utilisation
10.3.5 Discussion
10.4 Du cas d’utilisation textuel au cas d’utilisation visuel
10.4.1 Procédure d’expérimentation
10.4.1.1 Cas d’utilisation Reserve
10.4.1.2 Cas d’utilisation Rent
10.4.1.3 Cas d’utilisation Return
10.4.1.4 Cas d’utilisation Inspect
10.4.1.5 Cas d’utilisation Pay
10.4.1.6 Cas d’utilisation Make Available
10.4.1.7 Cas d’utilisation Prepare Service Request
10.4.1.8 Cas d’utilisation Prepare Work Order
10.4.1.9 Cas d’utilisation Maintain Car
10.4.1.10 Cas d’utilisation Sell
10.4.2 Évaluation et discussion des résultats
10.4.2.1 Applicabilité des règles de transformation
10.4.2.2 Discussion des résultats
10.5 Du cas d’utilisation visuel au diagramme de classe d’analyse
10.5.1 Expérimentation de l’étape de transformation automatique
10.5.2 Expérimentation de l’étape procédurale
10.5.3 Expérimentation de l’étape 3
10.6 Discussion
CONCLUSION
Télécharger le rapport complet
