Vers un PIM à base de composants multivues

SETIT 2007
4rth International Conference: Sciences of Electronic,
Technologies of Information and Telecommunications
March 25-29, 2007 – TUNISIA
Vers un PIM à base de composants multivues
M.Hain1, A.Marak2, T.Ouahmane3
Laboratoire TIM, Equipe IGSI, Département de Mathématiques et Informatique.
Faculté des Sciences Ben M’sik, PB 7955 Casablanca Maroc
1
[email protected]
2
[email protected]
3
[email protected]
Résumé : VUML [1] est une méthode d'analyse /conception basée sur les vues des acteurs. Le principal ajout à UML
dans le domaine de composants est la notion de composant multivues [2] qui permet d’encapsuler les caractéristiques
métiers selon différents points de vue, chacun correspondant à un acteur donné.
Une bonne réutilisation des composants passe par une représentation indépendante d’une plateforme donnée. Cette
représentation peut cibler, par la suite, différentes technologies spécifiques. En effet, la réutilisation d’un modèle à haut
niveau d’abstraction (indépendant d’une plate forme) est préférable que la réutilisation au niveau de code. Un
modèle abstrait peut être transformé dans plusieurs technologies et adapté selon les différentes exigences survenues.
Dans le présent article nous proposons une traduction simplifiée permettant de passer d’une représentation de modèle
à base des composants multivues vers une représentation de modèle à base des composants UML 2.0. La démarche
adoptée pour cet objectif s’inscrit dans le cadre général de MDA.
Mots clés: Profile UML, Vue, point de vue, Composant, Composant multivues, MDA.
Introduction
Après la vague de la conception orientée objet, et
la demande accrue des solutions logicielles qui
sollicitent plusieurs domaines, le développeur donc se
trouve dans un monde de complexité accentuée, et
devant des contraintes, à la fois de la nature des
applications, la taille des logiciels, des environnements
distribués et l’hétérogénéité. La nouvelle tendance de
développement à base de composants permet de
concevoir des systèmes logiciels complexes qui
requièrent l’intervention de plusieurs compétences par
assemblage, dans une vision qui s’inspire de
l’industrielle.
Un composant [3] [4] [5] est une pièce fondamentale
vue et manipulée par plusieurs acteurs (acteur comme
terme générale qui réunie l’homme, machine ou un
programme tiers). La modélisation orienté Acteur nous
permet d’encapsuler les caractéristiques métiers dans
une boite noir, et fournir les services attendus de ce
composant selon le point de vue acteur actif, pour
promouvoir la culture de la réutilisation [6].
VUML est une méthode d'analyse /conception basée
sur les vues des acteurs [7] [8]. Le principal ajout à
UML dans le domaine de composant est le composant
multivues, c’est une pièce très riche par rapport le
composant standard, mais difficile à instancier et à
déployer via les relations ajoutées.
Nous pensons que l’évolution d’un composant
multivues est de trouver une représentation adéquate
dans
le monde orienté
composant standard
conformément à la norme UML 2.0[9].
Cette représentation peut cibler les différentes
technologies spécifiques, dans le but d’augmenter la
réutilisabilité du composants multivues. Car
la
réutilisation d’un modèle à haut niveau d’abstraction
(indépendant d’une plate forme) est préférable qu’au
niveau de code. Un modèle abstrait peut être
transformé en plusieurs modèles.
L’article est présenté selon les sections suivantes :
La deuxième section présente un aperçu sur le
composant multivues et la démarche MDA, et
propose en particulier un processus de transformation
des composants multivues dans le contexte MDA.
Dans la troisième et quatrième section nous
présentons notre patron générique de transformation
d’un modèle abstrait à base de composants
Multivues, et nous proposons un algorithme de
transformation dans la cinquième
section, une
conclusion est donnée à la fin.
SETIT2007
1. Les composants multivues dans MDA
Dans cette section, nous nous intéressons à présenter
les composants multivues dans le contexte MDA[10]
[11]. L’objectif est de pouvoir cibler plusieurs platesformes à partir d’un même modèle et ceci grâce à des
projections standardisées.
1.1. Notion de composant multivues
UML2.0 [9] [12] [13] spécifie un composant comme
étant une unité décomposable, réutilisable, qui interagit
avec son environnement par l'intermédiaire de points
d'interactions appelés ports. Les ports sont caractères
par les interfaces : Ces interfaces sont caractérisées par
les signatures des méthodes qu’elles définissent et par
un sens de communication. Les interfaces fournies
caractérisent les communications entrantes d’un
composant, alors que les interfaces requises
caractérisent ses communications sortantes. Le contenu
interne du composant ne doit être ni visible, ni
accessible autrement que par ses ports. L’assemblage
des composants se fait au moyen de connecteurs.
Deux types de connecteurs existent : le connecteur de
délégation et le connecteur d'assemblage.
La figure 1 présente le métamodéle du composant
UML2.0 est coloré en blanc :
Class
Interface
Component
*
*
+/provi
+/requir
MultiVie *
MultiViewsCompone
w
+/provi
nt
*
Interface
+abstract
0.
Realization
Fig. 2 : exemple des composants multivues
client accède à un composant selon un point de vue
donné. Le client peut activer/désactiver des vues durant
l’exécution.
La figure 2 illustre un diagramme de composants
multivues à travers l'exemple simplifié d'une formation
dans un système d'enseignement à distance.
Ce diagramme comporte trois composants multivues :
Formation, Documentation et Inscription.
*
+realizatio
1
Classifier
+/requir
fig. 1 : Métaclasse définissant le concept de composant
en UML 2.0 et de composant multivues
D’après [8] Un composant multivues est une extension
du composant UML 2.0, il combine le critère de la
réutilisation via le concept de composant et celui de la
flexibilité via la notion de point de vue. Un composant
multivues a une structure interne et un ensemble de ports
qui structurent des points d’interaction avec
l’environnement extérieur et intérieur. La spécificité
d’un composant multivues est d'offrir des interfaces dont
la définition change dynamiquement selon la vue active.
De plus, un composant multivues est doté d’un
mécanisme de gestion de la cohérence entre ses vues qui
peuvent, éventuellement, être dépendantes. Ainsi, un
Un composant multivues publie ses attributs et ses
méthodes dans des interfaces portant le stéréotype
« base », partagées par les déférents points de vues, et
une spécification de point de vue acteur qui définie la
spécificité de chaque acteur stéréotypé « view ». Donc
l’interface multivues MVIFormation est schématisée
comme ci-dessous :
SETIT2007
Fig. 4 : le processus de développement des
systèmes à base de composants multivues
Fig.3 : Représentation explicite d’interface
multivues fournie MVIFormation
Par exemple Le comportement de la méthode
afficher () change selon la vue active. En effet pour
l’étudiant, cette fonction permet d’afficher, en plus
des informations de base, le prix, bien que
l’enseignent ait surtout concerné par autre point de
vue, il s'occupe de la préparation des exercices et
des questions posées.
1.2. MDA et les composants multivues :
MDA est une démarche de développement proposée
par l’OMG. Qui permet à une industrie de décrire ses
fonctions indépendamment des implémentations, et de
pouvoir projeter la même solution sur une ou
plusieurs plates-formes.
MDA définit une architecture de spécifications
structurée en 2 modèles :
¾ Les modèles indépendants des plateformes
(PIM).
¾ Les modèles dépendants des plateformes
(PSM).
Comme MDA est une approche basée entièrement
sur les modèles, nous considérons un modèle de
composants multivues abstrait comme un PIM de
départ, et spécifions le processus de transformation et
d’ affinement, qui consiste à ajouter d’autres
informations dans un modèle pour qu’il devienne plus
complet et plus détaillé. Par exemple, un composant
« abstrait » peut être raffiné en un ensemble d’autres
composants de granularité plus fines et plus spécifique.
Pour immerger le concept par point de vue dans le
paradigme de composant, nous allons le considérer
comme une information métier indépendante de la
plate forme.
La figure 4 illustre le processus de développement des
systèmes à base de composants multivues au sien de
MDA :
Il s’agit donc de définir les différents modèles PIM
et PSM ainsi que les transformations nécessaires.
Nous proposons alors, dans un premier temps, un
modèle PIM à base de composants multivues
(PIMVMC). Dans un second temps, nous donnons les
transformations PIMVMC en un PIM à base de
composants standard UML 2.0, afin d’avoir un
modèle standard et conforme avec la notion de
composant. Le modèle résultant est un modèle
compatible avec la norme de l’OMG. Ceci facilite la
projection de notre modèle vers les modèles
technologiques de composants : CCM (OMG) 1,
EJB 2, DCOM 3.
Pour répondre au besoin d’un langage de
transformation de modèles, l’OMG a publié un
appel à propositions (RFP, Request For Proposal)
intitulé MOF 2.0 Query/Views/Transformations (QVT)
[14]. Toutefois, à ce jour seul quelques soumissions ont
été reçues.
Les caractéristiques communes des ces langages sont :
l’algorithme et le
langage de transformation.
L’algorithme est la base de toutes transformations,
c’est une solution métier au niveau de la phase de
transformation. Une fois trouvée, on peut l’exécuter
avec les instructions
d’un langage transformation
spécifique.
Dans la section suivante, nous étudions le patron
générique qui vise la traduction d’un composant
multivues en un composant UML 2.0 standard.
1 CORBA Component Model
2
Enterprise Java Beans
3 Microsoft Distributed Component Object Model
SETIT2007
2. Définitions préliminaires
Selon le métamodéle de composant présenté dans la
figure 1 et la spécification de l’OMG [9] [12] [13], la
métaclasse composante définie dans le package
Component est une spécification de métaclasse : Classe
définie dans le package StructuredClasses. Cet héritage
entre les deux métaclasses nous permet de tirer les
définitions suivantes :
1. Chaque composant est caractérisé par ses
propres attributs, et un ensemble des méthodes
qui implémentent les services fournis par le
composant. La figure 5 illustre le format
explicite d’un seul composant, Formation,
doté d’un seul attribut code_f et une seule
opération affiche().
ViewDependancy, la base multivues…).
La solution envisagée est un compostant composite
conforme au standard du UML2.0 et enveloppe la
solution métier du composant multivues[15] [16]..
3.2. Motivations et Objectifs visés
•
•
•
•
Fig. 5 : La représentation explicite d’un composant.
2.
3.
4.
Un composant est une spécification d’une
classe, enrichi par d’autre type des relations.
Toutes les relations autorisées entre les classes
(héritage, agrégation…) sont valides pour les
composants. Si un composant « A » hérite d’un
composant « B » alors « A » est une
spécification de « B ». Cette spécificité en
terme des interfaces réalisées par le composant
parent ou d’une structure interne plus détaillée.
Une instance de métaclasse composant peut
contenir des instances descendantes de
métaclasses
PackageableElement.
PackageableElement est la métaclasse de base
pour les différentes métaclasses des éléments
de UML 2.0. Donc un composant peut contenir
d’autres composants, classes ou interfaces
comme sous composants.
Si on exige plus de détails sur la structure
interne, un composant se compose des parts et
des connecteurs. Les parts sont reliés par des
relations ordinaires entre les classes et délègue
le composant conteneur pour toutes les
communications
avec
l’environnement
extérieur. Sachant que les relations entre les
parts gardent la multiplicité et la référence.
3. Présentation de notre patron
générique:
3.1. Problème
On veut une représentation du composant multivues
selon la norme standard du UML2.0, car le composant
multivues contient des types des relations différentes et
non typées pour l’implémentation (ViewExtention,
On veut rendre la solution à base des
composants multivues tangible et compatible
avec le standard du UML2.0, donc une
représentation standard sert à convertir un
composant multivues vers le composant du
UML2.0.
Une solution qui s’adapte avec les solutions
marchés dans le domine orienté composant :
CCM (OMG), EJB, DCOM.
On ne veut par inventer un langage dédié pour
l’approche du composant multivues, et ne pas
pénaliser le développeur orienté composant
standard.
On veut cacher les interactions et les
interdépendances entre les acteurs et le
composant métier afin d’augmenter la gestion
et l a flexibilité des applications on gardant la
trace de point de vue d’acteur.
3.3. Solution proposée
Dans cette section nous proposons une modélisation de
notre patron générique selon deux volets : le premier est
la structure statique représentant notre patron à base de
composant standard UML2.0 ; le deuxième est la
spécification dynamique montant la collaboration
entre le client et les objets physique du patron.
3.3.1. Structure statique
Tenant compte
l’idée de composant composite
(définition N°3) et la structure interne d’un composant
complexe pour dire : un composant multivues est un
composant composite d’un ensemble des parts reliées
entre eux. On utilise la délégation et le polymorphisme
pour gérer les droits d’accès aux différentes vues, afin
assure l’aiguillage d’implémentation pour les différents
opérations publiées dans l’interface multivues.
La figure 6 illustre la structure statique de ce patron :
SETIT2007
Fig.6 : La structure du patron générique de transformation de composants multivues
Nous relevons à titre d’exemple à partir de la figure
ci-dessus les constituants suivants :
Compoent_name : représente le composant composite,
qui enveloppe la notion du composant multivues. Une
vue externe,
Compoent_name : est une boite noire doté d’un
ensemble des
interfaces, qui leur permet de
communique avec l’environnement externe.
IAdministration : est une interface pour gérer les vues et
la structure interne de composant
multivue. porte deux opérations : SetView() permet
d’activer/désactiver une vue et Getview() est celle qui
fournit la vue et la propagation de la vue active.
IMVC : Le composant multivues communique avec
l’extérieur au moins via une seule interface, qui expose
les différents attributs et opérations, porte le nom de
l’interface multivues « IMVC »,
CMV : est un composant part dans le composant
composite. Il fonctionne comme une façade de réception
et aiguille les appels vers les parts concernées selon la
vue active.
BaseCMV : est un composant part contient les attribues
et les opérations communes entre tout
les acteurs,
autrement dite c’est la réponse par défaut quand toutes
les vues sont passives. View_Extention : garde la trace
des appelles du composant CMV aux parts des acteurs
par
une
agrégation
référentielle
par
CurrentView_ExtentionCMV .
ViewKCMV : représente le point de vue spécifique de
chaque acteur. Il contient les attributs et
les opérations redéfinies déferrement de la base où
exclusive pour un acteur. K représente un indice d’un
acteur donné.
3.3.2. Spécification dynamique
Les constituants schématisés dans la structure statique
seront les participants de spécification dynamique. En
effet le client qui traite le système à base des composants
multivues, il se connecte d’abord au composant
composite(Component_name), qui délègue le traitement
de la requête reçue au composant part interne CMV,
celui traite la requête mais après l’identification de
l’acteur émetteur de cette requête, si la vue de l’acteur
est existe plus active, il aiguille le traitement au
composant part de la vue concernée, si non il l’aiguille
vers la part intitulée Base, qui encapsule les informations
partagée par tout le monde. De plus le composant
composite est doté par une variété des interfaces métiers,
plus les interfaces de gestion de composant qui permet
d’administrer davantage les vue au sien du composant
multivues.
L’administration
qui
permet
d’activer/désactive où lister les vues actives.
SETIT2007
Client
Component_name
CMV
BaseCMV
View1CMV
View2CMV
Invoquer
Déléguer
Notification
si vue 1 active
si vue 2 active
si non
Fig.6 : Le diagramme de séquence du patron générique de composant multivues.
4. La transformation de composant multivues
La procédure de transformation traduit le processus
d’évolution d'un modèle à un autre modèle de même
système dans un langage de transformation. Durant
l’opération de transformation on cherche la coïncidence
entre les éléments de modèle source et de destination.
Le modèle source est un PIM à base de composants
multivues « PIMMVC », le modèle destination est un
PIM à base de composant standard « PIMC ».
4.1. Choix de langage de transformation :
La transformation qui convertit un PIMMVC en un
PIMC consiste en un ensemble de règles, nous utilisons
l’outil gratuit et libre d’ATL [17], elle est rapidement
imposée à nous comme l’outil répondant le mieux à la
problématique de transformation. Rappelons qu’ATL est
une soumission de proposition en réponse à l’appel RFP
émis par OMG. ATL est un langage de transformation
hybride, semi-impératif et semi-déclaratif. Comme
différents autres langages de l'espace MDA, ATL est
basé sur le langage OCL pour l'écriture des expressions.
OCL est le langage de contraintes associé à UML 2.0. Il
fait partie de la collection des standards MDA.
Rule MVComp2Comp {
From MVC: PIMMVC! MVComp (Cond)
To
C : PIMC ! Comp
(-- séquence d’attribution de valeurs et déclaration des
variables.
-- l’élément créé
--Ex :
MVC.allinstances->exists
(comp_CVM :MVC|comp_CVM .name=
component_name) ;)
}
Avec:
MVComp2Comp: nom de la règle.
PIMMVC : nom du métamodèle du modèle d’entrée.
MVComp : nom d’un élément du métamodèle. Les
instances de cet élément subiront l’application de la
règle MVComp2Comp, à tour de rôle.
MVC: nom local de l’instance de MVComp (en cours de
traitement par la règle MVComp2Comp) rencontrée
dans le modèle d’entrée.
Cond : condition de filtrage sur les instances d’entrée à
la règle MVComp2Comp.
PIMC : nom du métamodèle du modèle de sortie.
Comp: nom de l’élément du métamodèle à instancier
dans le modèle de sortie, chaque fois qu’une instance
d’entrée est rencontrée.
C: nom local de l’instance créée en sortie de la règle.
4.2. Les règles de transformation
La syntaxe de la définition d’une
transformation est de la forme suivante:
règle
de
Les règles sont brièvement expliquées dans le
tableau ci-dessous en langage naturel, puis formulées en
utilisant la syntaxe ATL précédemment introduite.
SETIT2007
Bibliographie
Elément UML du modèle
PIMMVC
Eléments UML créés après
transformation dans le
modèle PIMC
Composant multivues
Composant composite UML
2.0
Sous
composant
View_acteur_K
Sous
Composant
BaseMVC
Attribut de sous composant
« View » acteur_K.
Interface
stéréotypée
« View » acteur_K
Interface
stéréotypée
« Base »
Attribut de l’interface
stéréotypée
« View »
acteur_K.
Opération de l’interface
stéréotypée
« View »
acteur_K.
Attribut de l’interface
stéréotypée « Base »
Opération de l’interface
stéréotypée « Base»
Les opérations GetView()
et SetView()
Opération
de
sous
composant View_acteur_K.
Attribut de Sous Composant
BaseMVC
Opération
de
Sous
Composant BaseMVC
Interface
Iadministration
avec
les
opérations
GetView() et SetView()
Toutes les opérations des Interface IMVC regroupe
interfaces
stéréotypées toutes les opérations des
« View » ou « Base »
interfaces
stéréotypées
« View » ou « Base »
N.B : K est un indice pour les acteurs.
Fig. 7 Tableau récapitulatif des règles de
transformation
5. Conclusion
Afin de garder la notion de point de vue acteur dans le
processus de conception, nous l’avons traité comme
une information
métier indépendamment de la
technologie « Un modèle indépendant de la plate
forme à base de composants multivues « PIMCMV».
Notre vision est d’intégrer les composants multivues
dans la démarche MDA. Les clés de réussite sont : la
compatibilité de la plate forme ciblée avec la solution
générée et la transformation, dans cette article nous
avons proposé un PIM intermédiaire qui fournir une
traduction simplifiée
d’un modèle à base de
composants multivues en un modèle conforme au
composant UML 2.0 standard dans le contexte de
MDA. Nous travaillons actuellement sur un prototype
de déploiement pour les composants multivues, afin de
générer un PSM à partir d’un PIM à base de
composants multivues.
[1]. Nassar, M., "VUML: a Viewpoint oriented UML
Extension", Proceedings of the 18th IEEE Montreal, Canada,
October 6-10, 2003.
[2]. El Asri et al., "Multiviews Component for development ",
Proceedings of 7th International Conference on Enterprise
Information Systems ICEIS’05, Miami-USA, 124-28 May
2005.
[3]. Clemens Szyperski: Component Software - Beyond
Object-Oriented Programming. Addison- Wesley, 2
édition, novembre 2002
[4]. Philippe Kruchten : “Modeling Component Systems with
the Unified Modeling Language”, Rational Software Corp,
1999.
[5]. Bertrand Meyer : What to compose. Software
Development, mars 2000. Online: Software development
columns:http://www.sdmagazine.com/articles/2000/0003
[6]. Kriouile A., "VBOOM, une méthode orientée objet
d’analyse et de conception par points de vue",
thèse d’Etat de l’université Mohammed V de Rabat, 1995.
[7]. Nassar M., "VUML : une extension UML orientée point de
vue". Doctorat en Sciences appliquées de l’université
Mohammed V Souissi Rabat. Numéro d’ordre 03/2004.
[8]. EL ASRIR, " Un modèle de composants multivues pour
VUML ". Doctorat en Sciences appliquées de l’université
Mohammed V Souissi Rabat. Numéro d’ordre 10/2005.
[9].UML 2.0 superstructure final adopted specification. Object
Management Group, document ptc/05-07-04, août 2005.
[10]. R. Soley and the OMG Staff. Model-driven architecture.
white paper, OMG Document, Nov 2000.
[11]. Blanc X., Caron O., Georgin A., Muller A., «
Transformations de modèles : d’un modèle abstrait aux
modèles EJB et CCM », Actes de la conférence Langages,
Modèles et Objets.
[12]. UML 2.0 Infrastructure Specification.
Management Group, document ptc/03-09-15,2003
Object
[13].UML 2.0 OCL 2nd revised submission. Object
Management Group, document ad/03-01-07, janvier 2003.
[14].OMG TC; “MOF 2.0 Query/Views/Transformations RFP”,
2002.
[15]. Gamma E. et al., Design Patterns, Elements of reusable
Object-oriented Software, Addison- Wesley, 1995.
[16]. Nassar M., Coulette B. et Kriouile A., "Génération de
code dans VUML". Journal Marocain d'Automatique,
d'Informatique et de Traitement du Signal, COPSTIC'03. 2004.
[17].ATL:http://www.sciences.univ-nantes.fr/lina/atl/