TOWARDS A MULTIVIEWS
COMPONENT BASED MODEL DRIVEN
APPROACH
MUSTAPHA HAIN1, ABDESSAMAD BELANGOUR2, ABDELAZIZ MARZAK3
TIM Laboratory, IGSI Team, Department of Mathematics and Computer Sciences.
Ben M’sik College of sciences, PB 7955, Casablanca, Morocco
1
[email protected] 2[email protected] 3[email protected]
Abstract:
A Multiviews Component is an extension of a UML2.0 component [El Asri (2005a)], that offers a richer behavior by adopting the concept of views. The problem of its representation has been tackled by VUML [Nassar (2004)] [El Asri (2005b)], which is a UML extension (UML profile). In this paper, we propose an approach to implement Multiviews Components under the MDA (Model Driven Architecture) initiative [Soley (2000)]. This process follows two sequential steps: The first step is a PIM-to-PIM transformation. It transforms and converts a Multiviews Component (which is a Platform Independent Model) into a conventional UML component by applying a proprietary design pattern [Hain (2006)] [Hain (2007)]. The second step transforms the resulting PIM into a PSM (Platform Specific Model) that targets Java / EJB platform.
Our approach offers two major advantages. The first advantage reduces the complexity related to VUML Multiviews Component handling by making it UML based. The second step implements these components into a specific development platform, which can be taken as an example for other target platforms.
Keywords: Multiviews Component ; UML profile ; views ; UML Component ; MDA ; EJB. 1. Introduction
Component-based software engineering has become the dominant tendency to meeting new demands of information technology [Meyer (2000)] [Szyperski (2002)]. This tendency has several advantages. Indeed, it allows dynamic components integration, which makes it easy for applications to be maintained and upgraded. In addition, it offers a high degree of component reuse while promoting an industry-based software lifecycle vision. Component-based applications are created by assembling pre-manufactured, pre-tested and reusable components. In this area, VUML which is a views-based extension of UML, provides the means for defining and handling Multiviews Component [Nassar (2004)] [El Asri (2005a)]. A Multiviews Component is conceptually richer than a standard component. Nevertheless, its wide adoption is slowed down by two factors. The first factor is the lack of approaches implementing Multiviews Components which generally are modeled using non-widely known UML extensions. The second factor is the lack of supporting tools that enable Multiviews Components handling. These two factors are key obstacles of the Multiviews Component adoption.
In this context, we worked on finding a reliable way that involves MDA initiative to concretely exploit Multiviews Components at industrial level and increases their reusability. Thus, we have identified a two-steps implementation approach that is based on MDA [OMG (2001)] initiative. The first step is a PIM-to-PIM transformation which shows how to transform a VUML representation of a Multiviews Component to a simple UML component that still offers views. The second transformation is a PIM-to-PSM transformation, which implements this component into a component-oriented platform such as Java / Enterprise JavaBeans (EJB) [SUN (2005)], CCM (CORBA Component Model) [OMG (2002)] or Dot.Net [Richter (2002)]. The example herein selected is Java/EJB.
2. Multiviews Components in MDA
In this section, we focus on presenting Multiviews Component in MDA context. Our goal is to target multiple platforms from a single Multiviews Components business model using standard transformations.
2.1. Multiviews Component concept
OMG defines a UML2 component, as a modular unit with well-defined interfaces, that is replaceable within its environment, and that has one or more provided, and/or required interfaces potentially exposed via ports [OMG (2003a)] [OMG (2003b)] [OMG (2005)]. Each component is characterized by interfaces, which are defined by its methods signatures. While the required interfaces characterize its outgoing communications, the provided interfaces characterize incoming communications. Component’s internal content is only visible or accessible through its interfaces. Figure 1 presents an overview with a colored meta-model of UML2.0 component.
A Multiviews Component is an extension of UML 2.0 component [Nassar (2004)] [El Asri (2005a)], that integrates the concept of actor’s viewpoints which promotes flexibility and reuse. Figure 1 shows the colored meta-model Multiviews Component fragment (extensions are colored in grey).
Fig. 1. Meta-model defining the concept of UML 2.0 component and Multiviews Component
A Multiviews Component has an internal structure and a set of interfaces. Its specificity is to provide interfaces, whose definition changes dynamically according to an active view. Moreover, a Multiviews Component has a mechanism for managing consistency among its views. Figure 2 shows a Multiviews Components diagram with a simplified example of “Training inside a School System”.
Fig. 2. A diagram of Multiviews Components
class meta_model_cmv
Classifier
- name: String
Component
MultiView sComponent MultiView sInterface
Feature
- name: String - Visibility: VisibilityKind
Interface BaseInterface View Interface View Extension Operation Attribute RelationshipEnd
- agrégation: boolean - composition: boolean - Lower: int - Upper: int
Relationship
- name: String
+view * 1 +viewExtension 1 1 * 1 1 +provided * 1 1 1 +end 0..2 +base 1 1 1 +required * 1 +requiredMV * 1 +providedMV *
cmp Component M odel cmv
This figure contains three Multiviews Components (stereotyped “MVC”): Training, Documentation and Enrollment. A Multiviews Component exposes its methods in interfaces that have a «baseInterface» stereotype. Each base is shared by different viewpoints and a specification is dedicated for a specific viewpoint stereotyped «viewInterface». We schematize the “MVITraining” Multiviews Interface in the next figure.
Fig. 3. A representation of MVITraining provided Multiviews Interface
Behavior of display() method changes according to the active view. For example, the display() method of StudentTraining provides more information than that of base (display of fees related to specific Training). This example is intended to give a brief idea on Multiviews Components through a practical case before we explain how we are going to take benefit of the MDA approach in the next section.
2.2. MDA and Multiviews Components
MDA is a development approach proposed by the OMG (Object Management Group) [OMG (2001)], which allows an industry to independently describe its implementation business functionality. Thus, business information is described using platform independent models or PIMs that can be later projected on several specific platforms (Java/EJB, C #/.Net, etc.). The process of generating a PSM from a PIM is called transformation.
In our approach we are trying to show a process of transforming a Multiviews Component to a Java/EJB component. MVC-PIM is the name we gave for the PIM representing our Multiviews Component. We are trying to transform this PIM (represented using VUML formalism) into a standard UML component which still offers views and is still a PIM (we named it C-PIM). Consequently, this operation is a PIM-to-PIM transformation. The second stage of our approach consists of transforming the resulting PIM into a PSM that is specific to java/EJB platform (we labeled it EJB-PSM). Figure 4 presents our MDA-based approach.
Fig. 4. Multiviews Components transformation process using MDA
The Multiviews Components transformation process occurs through three steps which are:
Step 1: The software Architect uses the VUML profile to build a Multiviews Components model. The obtained model is a MVC-PIM (Multiviews Components PIM).
Conform to
Conform to Conformto
VUML Meta-model
C-PIM
UML Meta-model
MVC-PIM
MVCpim2Cpim.a
Transform into
EJB-PSM
EJB Meta-model
Cpim2EJBpsm.atl
Transform into
Meta-model level
Model level
Step 1 Step 2 Step 3
class interface_cmv
«baseInterface» ITraining + display() : voi d
«ViewInterface» StudentTraining + askQts() + display() : void «ViewInterface»
TeacherTraining + addExe() + display() : void
«ViewInterface» ResponsableTraining + addT eacher() + display() : void + Enrollstudent() «ViewExtension»
Step 2: It consists of transforming Multiviews Components PIM (MVC-PIM) described using VUML into a conventional UML2 component model (C-PIM) [Hain, 2006] [Hain (2007)].
Step 3: The goal of this step is to transform the resulting UML2 component model (C-PIM) into java/EJB based model, which leads to an EJB component model (EJB-PSM). The EJB model is generic and independent from any specific application server.
In the next section we are going to shed some light on the EJB platform.
3. The EJB specific platform
Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications. We chose this platform to illustrate our two-steps process of transforming a Multiviews Component into a specific platform component.
The EJB technology is a cornerstone in JEE technologies. It provides a standard for developing reusable enterprise Java components. The main elements in EJB architecture are Enterprise Beans and containers: Enterprise Beans are components that are created and managed by containers and that provide non-functional services such as transactions and persistence. Figure 5 illustrates a structural overview of EJB component meta-model [JCP (2005)].
Fig. 5. A meta-model defining the concept of EJB
An EJB Bean is composed of an interface and an abstract class. There are three types of EJB:
EJB Session performs tasks for the client;
EJB Entity manages the persistence at the server;
EJB Message-Driven allows the processing of asynchronous messages.
For more detail about EJB platform please refer to EJB official documentation [JCP (2005)].
4. PIM-to-PIM and PIM-to-PSM Transformations
4.1. PIM-to-PIM Transformation
In order to implement a Multiviews Component, we first need to transform it into a conventional UML2 component. For this reason, we rely on a generic pattern proposed in an earlier work [Nassar (2004b)][Hain (2006)][Hain (2006)] (see Figure 6). Because of possible representation of a Multiviews Component as a composite component, delegation and polymorphism are used to manage various views access rights, and to ensure views implementation in different operations published in the Multiviews interface.
class meta_ej b
EJB Jar
- name: String
EnterpriseBean
- name: String
EJBEntityBean EJBMessage-Driv en EJBSessionBean
Jav aClass
- name: String
EJBField
- name: String
EJBMethod
- name: String
Jav aParameter
- name: String
EJBAssociationEnd
- agrégation: boolean
- composition: boolean
- Lower: int
- Upper: int
EJBAssociation
- name: String
1 +end 2
2 0..*
+parameter * 1 +ownemethod*
1
+ownedfield
* 1
*
re
m
o
te
In
te
rf
a
c
e
*
ej
b
C
las
s
Fig. 6. Static structure of the generic pattern
From the above figure we notice the following constituents:
Component_name: it represents the composite component embodying the notion of the Multiviews Component. It is essentially a black box equipped with interfaces, allowing communication with external environment.
IAdmin: it is an interface that manages views and internal structure of Multiviews Components. It is endowed with two operations: SetView() that allows to enable/or disable a view, and Getview() that provides the active view.
ProvidedInterfaceMV: it is an interface that exposes a set of methods used by the Multiviews Component to communicate with outside.
Component_name_MVC: it is a partial component within the composite component that functions as a facade that receives calls and directs them towards the concerned part according to the active view.
Base_MVC: it is a part that contains shared or common operations among all the actors.
View_Extention: it keeps trace of calls to Component_name_MVC through a referential aggregation called CurrentView_ExtentionMVC.
View_K_MVC: it provides the specific viewpoint of each actor. In addition, K represents an index of a given actor.
4.2. PIM-to-PSM Transformation
The first idea that comes to mind when trying to transform a UML2 component into an EJB one is trying to identify a one-to-one correspondence between their respective elements. On one hand, a component-based model is independent from platforms. It describes, in detail, provided and required services in an interface format. On the other hand, an EJB-based model is a specific platform model which does not provide multiple business interfaces or required interfaces. Consequently, it is obvious that there is no direct correspondence between the two concepts. Nevertheless, we can take benefit of the below generic pattern with some adaptation [BLANC (2004)]:
Each UML component providing a single interface is considered as an equivalent to an EJB component.
Each UML component providing more than one interface will have its interfaces merged into a single EJB interface.
class patron_ej b
«EJBImplementaion» Component_MV «EJBImplementaion»
Base
«EJBImplementaion» View Extension
«EJBImplementaion» View 1
«EJBImplementaion» View 2
«EJBImplementaion» View K
«EJBInterface» I_Component_MV
«EJBImplementaion» View k Current
Fig. 7. Static structure of generic pattern EJB model
The above figure displays the following components:
Component_MV: represents a composite bean that encapsulates the concept of Multiviews Component. It contains a reference to all attributes and methods. Thus, it publishes these methods in a business interface called I_Component_MV, and functions as a facade that receives, and switches calls to the active view. The composite Bean contains two different methods: SetView() for enabling or disabling a given view and GetView() for providing the active view.
I_ Component_MV: composite Bean Component_MV uses this interface, which exposes various methods to communicate with external environment.
Base: It’s a partial Bean that contains common methods to all actors. It is the default response when all views are passive.
View_Extention: keeps trace of calls to component_MVC through a referential aggregation called CurrentView_ExtentionMVC.
ViewK: produces the specific viewpoint of each actor. K represents an index of a given actor.
A composite component has various management methods interfaces, which allow an administrator to manage his own Multiviews Components, by enabling or disabling any view. A client, who intends to use a Multiviews Component, has first to connect with Multiviews interfaces I_ Component_MV, which sends the incoming request to an internal part component Component_MV. Afterwards, Component_MV identifies the source of the request. If the view of the actor is active, Component_MV forwards the request to the concerned view, otherwise it will be sent to Base interface which makes information sharing easy.
5. Implementing the transformation
The transformation, which converts a MVC-PIM into an EJB-PSM, is composed of a set of rules. In order to express these rules, the ATL language is used [Bézivin (2004)] [ATL], which better suites model transformations. It is important to recall that ATL is an official proposal which implements OMG QVT standard [OMG (2003c)] [OMG (2008)].
Fig. 8. An overview of the km3 Multiviews Components code.
The syntax that defines a transformation rule can be presented as follows: Rule MVC-PIM2EJB-PSM {
From MVC: MVC-PIM! MVComp (Cond) To C: EJB-PSM! Comp
(
--Ex : MVC.allinstances->exists
(comp_MVC :MVC|comp_MVC .name= component_name) ;) } With,
MVC-PIM: name of the meta-model of the entry model. MVComp: name of a meta-model element.
MVC: local name of MVComp. Cond: condition of filtering.
EJB-PSM: name of the target meta-model. Comp: name of the meta-model element instance. C: local name of the created element.
We rely on generic patterns to identify mappings between the three meta-models and then we define transformation rules. According to generic patterns, each element described using the target meta-model, can be obtained by transforming one or more elements of the source meta-model.
Model PIMMVC element Model PIMC element Model PSMEJB element Multiviews Component UML2.0 composite Component EJB composite Component
Interface stereotyped « ViewInterface» actor_K
Sub component View_actor_K EJB Sub-component View_actor_K
Interface stereotyped « BaseInterface»
Sub component “BaseMVC” EJB Sub-component “BaseMVC”
method interface stereotyped «ViewInterface» actor_K.
method Sub-component “View” actor_K.
method EJB Sub component “View” actor_K.
Attribute references interface stereotyped «BaseInterface»
Attribute Sub-component “BaseMVC”
Attribut EJB Sub component “BaseMVC”
method interface stereotyped «BaseInterface»
method Sub-component “BaseMVC”
method EJB Sub component “BaseMVC”
All methods of interfaces stereotyped «ViewInterface» or «BaseInterface»
IMVC interface including all operations of interfaces stereotyped «ViewInterface» or «BaseInterface»
EJB interface including all operations of interfaces
stereotyped «ViewInterface» and «BaseInterface» called I_ Component_MV
Fig. 9 Summary of transformation rules
The letter “K” represents the index of a given actor.
6. Conclusion
In this paper, we proposed an approach to implement Multiviews Components. The milestone of this approach is the transformation of the Multiviews Component to a conventional UML component which reduces the well known complexity of using and maintaining such components. This complexity is, in addition to the notion of multiviews, related to the use of non standard UML-extension to model Multiviews Components. We then took a target platform to demonstrate how we can implement a Multiviews Component.
As based on the MDA initiative, the first step of our approach is PIM-to-PIM transformation which is based on a design pattern we proposed in a previous paper while the second step is PIM-to-PSM transformation that targets the EJB specific platform.
We are currently, exploring other specific component based platforms to automate the whole process. The expected results would certainly contribute to the wide acceptance and use of Multiviews Components and therefore the benefit of their conceptual power.
7. Bibliography
[1] ATL (2009), ATL specification. http://www.sciences.univ-nantes.fr/lina/atl/
[2] Bézivin, J, Jouault, F, Rosenthal, P, and Valduriez, P, (2004). The AMMA platform support for modeling in the large and modeling in the small. Research Report LINA, (04.09).
[3] BLANC X., CARON O., GEORGIN A., MULLER A., (2004). Model transformation: from an abstract model to the EJB and CCM model. French Journal “L' Objet” Languages and object models. Conference 10, Lille, 15/03/2004 FRANCE.
[4] El Asri B., Nassar M., Kriouile A., Coulette B., (2005a) Multiviews Component for development , Proceedings of 7th International Conference on Enterprise Information Systems ICEIS’05, Miami-USA pp 124-28, May 2005a.
[5] EL ASRIR, (2005b). Un modèle de composants multivues pour VUM". doctorate thesis, Mohammed V University, Rabat.
[6] Hain M., Marzak A., Ouahmane T., Lakhouili A., (2006). Vers un Patron Générique Pour la Réutilisation de Composants Multivues, Proceedings of MIPS 7-9 May 2006. Agadir Morocco.
[8] JCP, Enterprise JavaBeans3.0. (2005). full specification, 2005, http://jcp.org/en/jsr/detail?id=19 [9] KM3, (2006) KM3 specification, http://wiki.eclipse.org/index.php/KM3
[10]Meyer B., (2000) What to compose. Software Development. march 2000. Online: Software development columns: http://www.sdmagazine.com/articles/2000/0003
[11] Nassar M., (2004a). VUML : une extension UML orientée point de vue. PhD doctorate thesis, Mohammed V University, Rabat, 2004.
[12]Nassar M., Coulette B., Kriouile A., (2004b). Génération de code dans VUML. Morocco Journal of Automation, Computer and Signal Processing, COPSTIC'03. 2004.
[13]OMG (2001). Object Management Group, Jishnu Mukerji, Joaquin Miller. MDA Guide Version 1.0.1, 2001. http://www.omg.org/cgi-bin/doc?omg/03-06-01.pdf
[14]OMG, (2002a). CORBA Components, version 3.0 full specification. OMG document formal/02-06-65. June 2002. http://www.omg.org/cgi-bin/doc?formal/02-06-65
[15]OMG (2002b). OMG/MOF Meta Object Facility (MOF) 1.4. Final Adopted Specification Document. formal/02-04-03 [16]OMG (2003a). UML 2.0 Infrastructure Specification. Object Management Group, document ptc/03-09-15,2003 [17]OMG, (2003b) .UML 2.0 OCL 2nd revised submission. Object Management Group, document ad/03-01-07, January
2003.
[18]OMG, (2003c). XML Metadata Interchange (XMI), v2.0. www.omg.org/cgi-bin/doc?formal/2003-05-02
[19] OMG, (2005). UML 2.0 superstructure final adopted specification. Object Management Group, document ptc/05-07-04, August 2005.
[20]OMG, (2008). Object Management Group, Inc. Meta Object Facility (MOF) 2.0 Query/ View/Transformation (QVT) Specification, version 1.0, April 2008.
[21]Soley R and the OMG Staff (2000). Model-driven architecture. White paper, OMG Document, November 2000. [22]Steinberg D. (2008)., Eclipse Modeling Framework, by Addison-Wesley Professional. 2nd Edition December, 2008. [23]SUN (2005)., Enterprise JavaBeans full specification, 2005. http://java.sun.com/products/ejb/
[24]Szyperski C, (2002). Component Software – Beyond Object-Oriented Programming. Addison- Wesley, 2 edition, November 2002.
