Current approaches to the visualization of component-based applications mostly use only associations and dependencies between components and provide limited supplementary information. In this paper, we introduce a data layer that is able to store and later present more information about component elements which are bound together, and through this knowledge provide more understanding about the component itself. These information could be presented in di erent ways to provide di erent views for component software developers, designers, and architects. This data layer is general and is able to visualize component based applications of any component model. It is presented here together with its structure, implementation and tooling. We share experiences obtained in the process of designing and implementing this layer. Special care is given to the implementation details which were solved in the process and relevant tools like MOF and EMF are presented. Results from the test application are also part of this paper.
Fig. 1. Address Component in UML. ponent as shown in Example 1 and we would like to display it in diagram. In UML this component would look like in Figure 1.
Example 1. component AddressComponent f // a t t r i b u t e s r e a d o n l y a t t r i b u t e s t r i n g d e s c r i p t i o n ; r e a d o n l y a t t r i b u t e N e t w o r k S t a t e s t a t e ; // f a c e t s p r o v i d e s AddressBook book ; p r o v i d e s A d d r e s s S e a r c h s e a r c h ;
di erent component environments. Component mod- // e v e n t s
els like EJB [
The diversity of component models or even ap- UML only supports displaying attributes and
inproaches to components [
It would be bene cial if there was a way to know If we would like to capture such additional informore about the elements that make up the bindings mation in the visualization of component based applibetween components. Based on the diversity of compo- cations, appropriate speci c meta information would nent models we can say these elements should bear the need to be available for its concrete component model. information relevant in the concrete component model. That would lead to as many representations as there This means that general visualization approaches like are component models, leading to signi cant fragmenUML can't represent this extra information. tation of visual notations. A better solution is to have
This problem is best presented on a short example a generic meta-model which can be instantiated for
of a CORBA component. Let us presume there is com- individual component models. This means a new data
layer implementing this meta-meta level has to be
designed. The representation of this problem based on
MOF (Meta Object Facility) layers [
On the M3 level there is a data structure able to hold information about both component models and component based application. On the M2 level there is a de nition of a component model (de ned manually for each component model to provide meaningful representation) which explains the information stored on the M1 level. The M1 level should support automated walking through component-based applications.
In [
In this paper we focus on the design and implementation of a data layer meeting the above requirements on storing and using of these additional information for visualization of component-based applications. The layer implements the ENT meta-model as a MOF structure, using Eclipse Modeling Framework as the underlying technology. Besides describing the data layer itself, we also want share the experiences gained in the process of designing its implementation.
In the next section we brie y review the related standards and research works in the areas of (component) meta-modeling and visual representation. An overview of ENT meta-model is provided in Section 3 to understand the rest of the paper, including the extensions introduced for the description of component models and component based applications.
speci cation, a MOF model [
For its good t with the data layer needs, the Eclipse Modelling Framework (EMF) was chosen as a model generator. More information about EMF, the generated model and editor can be found in Section 5.
As a proof that the MOF model of ENT metamodel was designed correctly, we implemented representations of several component models. The list of these component models and a case study can be found in Section 6. 2
The diversity of component models or even approaches
to components [
The domain of meta-models is best represented
by the Meta-Object Facility (MOF) standard [
UML [
approach [
ned in this model are classi ed. On the Application For other information that are important for the level the previous de nitions are used and the inter- component model and cannot be described usface elements belonging to individual components are ing traits, tags are used. Tags can expand information identi ed. To support additional information, tags are about component types or about elements in traits, provided which can be added to components or single for instance to keep track about version, accessibility, component elements. The faceted view is used to rep- range and other additional parameters. Tag de nitions resent components in way better readable to humans. are de ned on the component model level in order to
For complete ENT meta-model speci cation, be available on the application level.
please refer to [
The ENT classi cation system has eight facets called \dimensions". These dimensions have prede ned val- Components, from which an application is built from, ues and each dimension represents a di erent point of are represented on this level. The component model view on a component. Some facets can have more then has to be already de ned on the component model one value, for instance Role which says if an element level because the application level references its eleis provided or required { in some cases an element can ments. By creating these references on higher level, exhibit both provided and required roles, as e.g. the the meaning is given to the application elements. SOFA behaviour protocol [18]. It means a concrete component is assigned a corresponding component type and based on that, a set { Nature = fsyntax, semantics, nonfunctionalg of its traits is gained. Traits alone do not say any{ Kind = foperational, datag thing about the particular component, but elements { Role = fprovided, required, neutralg that belong to the given trait do. Each trait has its { Granularity = fitem, structure, compoundg own element set { the interfaces, classes, events, etc. { Construct = fconstant, instance, typeg found on the component's surface. The component is { Presence = fmandatory, permanent, optionalg thus described by several sets of elements grouped to{ Arity = fsingle, multipleg gether by their characteristic traits. The trait has only { Lifecycle = fdevelopment, assembly, deployment, grouping purpose and through the reference to its trait setup, runtimeg de nition gives meaning to all elements contained in it. Concrete values of tags can be set on the component 3.2 Component model level sacnrdipittisoenl.ements, thus providing their more precise deFor example, the \facets" trait of the component from Example 1 is a set f (book,AddressBook), (search, AddressSearch) g and the (description,string) element has a tag set f (access,readonly) g.
model are identi ed on this level of understanding.
Identi cation of di erent component types is the rst step, because the component model consists of one or more component types. As an example, there is only one component type in OSGi (called Bundle); 3.4 Category sets in EJB on the other hand several di erent component types can be identi ed because EJB applications The level of traits and elements could contain a lot can be built from SessionBeans, EntityBeans or Mes- of unwanted information for some sorts of users. For sageDrivenBeans. example software architects are interested in other in
Every component type has its traits de nitions formation than programmers of component-based apthat de ne the kinds of elements (features) the con- plications. By using such data layer there could be crete component can have on its surface. Traits thus a danger of confusion when representing big and comhelps to fully characterize component of such a type. plex applications.
After representing a component-based application The ENT meta-model already contained lists of all
according to the Application level, the received infor- elements that can be bound, as element sets contained
mation can therefore be organized using category sets. in traits. This modi cation only allows to add
inforThese sets are de ned by selector operators on the mation which elements are actually bound to other
trait classi cation, and can be supplemented by any elements and does not create any new element.
user of the ENT meta-model if another point of view The list of components which constitute a
hieraris needed. In [
Category sets say how to group and display traits. cal components. This kind of components can add its The E-N-T category has three groups. In the rst own elements and export/import only some of the elgroup are elements that are contained in traits with di- ements that are contained by components it is built mension frole = providedg, this means those elements from. These inner components are restricted in that which the component exports. Required elements are they can only bind with each other within the boundsimilarly grouped as needs and elements that can be aries of their parent hierarchical component. In every both provided and required are called ties. other respect they are normal components. 4
E-N-T (Exports-Needs-Ties) f E = C:(C:role = fprovidedg) f N = C:(C:role = frequiredg) f T = C:(C:role = fprovided; requiredg)
a concrete implementation of the ENT meta-model, to be used in visualization of component-based applications. The explanations in this section use the descripFig. 3. ENT category set. tion of the process of creating this design and implementation, as it provides a way to share experiences that other projects can draw from.
For example, the attributes and facets of the COR- The MOF is a Domain Speci c Language used to
BA component in Example 1 belong to the \E" cat- de ne meta-models. The core of MOF is shared with
egory set, while the stateNotify event belongs to the UML and its meta-models can be de ned using UML
\N" set (because it signals the component requires an class diagram. This means the ENT meta-model can
event sink to which it needs to be connected). be de ned using MOF and the product of this de
nition will be UML class diagram which can later be
3.5 Extensions of the ENT meta-model processed. Entities de ned in this section can be
implemented in speci c programming language and used
The original ENT meta-model [
A new meta-model entity Binding=(Element local, We will present the ENT model thus created in Element alien, direction 2 fprovided, requiredg) was three separate parts. The Classi cation system is modcreated to represent bindings between components. eled as a simple class ENTClassification with atBindings are realized through concrete elements that tributes corresponding to classi cation facets. These are physically linked to each other, with additional facets are modeled as enumerations, which is appropriinformation about the binding direction { provided ate given their needs. The facet attributes were idenmeans \from local to alien", required means oppo- ti ed as mandatory, with \single" multiplicity except site. Every component has its own list of bindings, for Life-cycle and Role which have \multiple" multithis list contains all bindings involving the elements plicity. of the component. This means a Binding between ele- The component model level is represented by four ments of components A and B is in the lists of both elements. ComponentModel entity is the main one and these components. This method has the advantage of is designed to keep all instances together on one place. ensuring that the binding list is complete in any com- ComponentTypes and TraitDe nitions will be acponent's representation. cessed via references gained from arrays stored in
formal description. The \note" attribute was added to all these elements, to provide for descriptive information about the implemented component model in this data structure.
The application level is represented by ve elements
and it is the most changed part of the ENT
metamodel compared to its formal description in [
implementation manually, but EMF (Eclipse Modeling Framework) was chosen instead. EMF is used for Model Driven Development and o ers additional services such as generating the model classes from UML, and editors for the model in the form of an plugin for the Eclipse integrated development environment. This section describes the advantages brought by the use of EMF.
EMF was used to generate a Java implementation of the data layer from the MOF model of the ENT meta-model. This implementation is called ENTMM as an abbreviation for ENT meta-model. ENTMM consists of interfaces and classes corresponding directly to the model entities presented in the previous section. This implementation thus forms a run-time ENT representation of any given component model and its applications and will be used in every project that uses the ENT meta-model; for some such future projects see Section 7.
An editor of ENTMM data was created to provide GUI for component model de nition described in Section 3.2; it is very similar to editor displayed in Figure 6. This editor is implemented as Eclipse plugin and can't be used without the Eclipse IDE.
EMF however o ers more than just the advanced code generator and Eclipse plug-ins to support modeling. One of its features is advanced work with the XML format. Editors automatically save all model data in an XML le which can be easily accessed using EMFgenerated resource classes. This brought us very usable form of automated storing and loading representations of various component models. This EMF ability goes both ways so in the future there is the possibility of using EMF buit-in features to save current application models in XML.
Eclipse Modeling Framework is able to set many features of the generated model in its editor and it is strongly recommended to use this opportunity instead of manual changes to generated code. EMF transforms the UML diagram into its internal format of \ECORE" le, where all information and settings related to the model are stored. Similarly there is a \GENMODEL" le which is used to store settings for the editors of the generated model and for the generating process itself.
The base model created automatically had several limitations mainly from practical point of view. Fortunately, EMF is able to set many features for the component model representation created in its editor. After an automated transformation of UML into the EMF basic ECORE format, a few additional changes had to be performed.
the ECORE editor so that entity references are used (instead of instances) for many model class attributes. This prevented the undesired e ect that the same trait de nition could not be shared by several component representations. 6
model. SOFA [19] is a research component model from Charles University, Prague. A SOFA component is interacting with other components only via designated provided and required interfaces. A component can be viewed as both a black-box and gray-box entity.
De nition of SOFA component model in ENT is
provided in [
De nition of SOFA component model in ENT:
The ENTMM editor for Eclipse was used to create the SOFA component framework de nes one kind of
comrepresentation of several component models, namely ponents, with no component-level and element-level
OSGi, EJB, CORBA, and SOFA (which have been al- tags and with four traits.
ready de ned) and the CoSi [20] and MVE [
By adding these plugins, a new le type appears fstructureg, finstanceg, fpermanentg, fmultipleg, in Eclipse while creating new le, named \ENTMM Lifecycle), Model". To start de ning the representation, the user requires - required interfaces has to choose this le type and select \Component metatype = interface, Model" as an \Model Object" when asked. ENTMM classi er = (fsyntaxg, foperationalg, frequiredg, editor like the one in Figure 6 will appear and by using fstructureg, finstanceg, fpermanentg, fmultipleg, its simple interface, the user is able to de ne a new Lifecycle), component model easily. properties - provided interfaces metatype = property, classi er = (fsyntaxg, fdatag, fprovidedg, fitemg, finstanceg, fpermanentg, fmultipleg, fdevelopment, assembly, runtimeg), protocol - provided interfaces metatype = protocol, and classi er = (fsemanticsg, foperationalg, fprovided, requiredg, fitemg, ftypeg, fpermanentg, fnag, fdevelopment, assembly, runtimeg).
was created in ENTMM editor and the nal view of this implementation can be seen in Figure 6. As mentioned in Section 5, EMF stores data in XML format. XML version of the SOFA component model representation is given in Example 2. This representation can be recreated by intuitive use of editor and lling data from the formal de nition to the prepared data structure.
The generated XML structure does not follow all rules of good XML data but EMF does not support XML customization. This disadvantage is the only tax to pay for automated storing and loading of component models.
Fig. 6. ENTMM editor in Eclipse IDE. 6.1
As a case study, the representation of the SOFA com- Example 2. ponent model is presented below to show how sim- <?xml v e r s i o n ="1.0" e n c o d i n g="UTF 8"?> ple it is to create a de nition of a new component <ENTMM: ComponentModel xmi : v e r s i o n ="2.0" xmlns : xmi="http : / /www. omg . org /XMI" xmlns :ENTMM="http : / / /ENTMM. e c o r e " name="SOFA"> < t r a i t S e t name="p r o v i d e s "
metatype=" i n t e r f a c e "> < t r a i t C l a s s i f i e r g r a n u l a r i t y= " s t r u c t u r e " a r i t y =" m u l t i p l e " c o n s t r u c t =" i n s t a n c e " p r e s e n c e="permanent"> <r o l e >provided </ r o l e > < l i f e c y c l e >development </ l i f e c y c l e > < l i f e c y c l e >assembly </ l i f e c y c l e > < l i f e c y c l e >deployment </ l i f e c y c l e > < l i f e c y c l e >setup </ l i f e c y c l e > < l i f e c y c l e >runtime </ l i f e c y c l e > </ t r a i t C l a s s i f i e r > </ t r a i t S e t > < t r a i t S e t name=" r e q u i r e s "
metatype=" i n t e r f a c e "> < t r a i t C l a s s i f i e r . . . > </ t r a i t C l a s s i f i e r > </ t r a i t S e t > < t r a i t S e t name=" p r o p e r t i e s "
metatype="p r o p e r t y"> < t r a i t C l a s s i f i e r . . . > </ t r a i t C l a s s i f i e r > </ t r a i t S e t > < t r a i t S e t name=" p r o t o c o l "
metatype=" p r o t o c o l "> < t r a i t C l a s s i f i e r . . . > </ t r a i t C l a s s i f i e r > </ t r a i t S e t > </ENTMM: ComponentModel> provide component application visualization for many component models and with multiple views based on ENT philosophy.
All these e orts should result in advanced visualizer of component based applications ful lling these points:
Fig. 7. AddressComponent visualized in ENT style. 8
7 Future work This paper presented an extended ENT meta-model with the support for inter-component dependencies.
Having created the ENTMM implementation, work is The process of creating the MOF-based representacurrently under way on the implementation of compo- tion of this model was described to share as much nent application loaders for the OSGi and CoSi frame- experience as possible, including relevant class diaworks. These loaders should analyze component ap- grams. Based on these diagrams a EMF-generated tool plication based on the used component model and was presented which is used to create representations load information we are interested in. This informa- of concrete component models, with a discussion of tion will be stored in the implemented ENT meta- its advantages and several interesting points we met model data structures. In future we will extend the in the process of generating the implementation Java supported component models to include EJB, SOFA, code from the class diagrams. etc. based on actual needs. Finally we presented component models that were
We concurrently work on Component model visu- implemented using the generated Eclipse IDE plugin. alizer based on ENT faceted views and of course on the Brief description how to use this plugin is also proENT meta model EMF implementation. This applica- vided and supplemented with a case study of the reption will support multiple ENT views and automated resentation of the SOFA component model. Both the application loading using implemented component ap- XML format and the graphic view of the nal product plication loaders. This should give us a tool able to were presented.
The key contribution of this paper is the descrip- 14. C. Esco er and R.S. Hall: Dynamically adaptable aption of a MOF-based data layer able to hold and inter- plications with iPOJO service components. Proceedpret rich information about various component mod- ings of 6th International Symposium on Software Comels and their concrete components. This layer can be position, Braga, Portugal, 2007. used in many scenarios, including representing visually 15. I. Poernomo: A type theoretic framework for formal complex component-based applications. metamodelling. In: Architecting Systems with Trustworthy Components, Lecture Notes in Computer Sci
This paper can also be used to learn experiences we ence 3938/2006, Springer-Verlag 2006. gained in the process of the transformation from for- 16. R. Monge, C. Alves, C. and A. Vallecillo: A graphical mal model de nitions to this implementation. These representation of COTS-based software architectures. experiences can be used as a whole, providing tuto- Proceedings of IDEAS, April 2002. rial how to transform meta-model from paper to real 17. Ch. Luer, and D.S. Rosenblum: UML component dilife application, or separately when the reader is inter- agrams and software architecture { experiences from ested only in some parts like creating a MOF model the WREN project. 1st ICSE Workshop on Describing or using the EMF tool. Software Architecture with UML, 2002. 18. F. Plasil, and S. Visnovsky: Behavior protocols for software components. IEEE Transactions on Software EnReferences gineering, 28 (10), 2002. 19. T. Bures, P. Hnetynka and F. Plasil: SOFA 2.0: Balancing advanced features in a hierarchical component model. Proceedings of SERA 2006, IEEE CS, 2006. 20. P. Brada: The CoSi component model: reviving the black-box nature of components. Proceedings of the 11th International Symposium on Component Based Software Engineering, October 2008, Springer Verlag, LNCS 5282.