Implementation of a data layer for the visualization of component-based applications Jaroslav Šnajberk and Přemek Brada Department of Computer Science and Engineering, Faculty of Applied Sciences University of West Bohemia, Pilsen, Czech Republic {snajberk,brada}@kiv.zcu.cz Abstract. Current approaches to the visualization of component-based applications mostly use only associ- ations and dependencies between components and provide limited supplementary information. In this paper, we in- troduce a data layer that is able to store and later present more information about component elements which Fig. 1. Address Component in UML. are bound together, and through this knowledge provide more understanding about the component itself. These in- formation could be presented in different ways to provide ponent as shown in Example 1 and we would like to different views for component software developers, design- ers, and architects. This data layer is general and is able display it in diagram. In UML this component would to visualize component based applications of any component look like in Figure 1. model. It is presented here together with its structure, im- plementation and tooling. We share experiences obtained Example 1. in the process of designing and implementing this layer. component AddressComponent 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 // a t t r i b u t e s also part of this paper. readonly at t r i b ut 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 NetworkState s t a t e ; // f a c e t s 1 Introduction p r o v i d e s AddressBook book ; provides AddressSearch search ; Many component based applications are developed in different component environments. Component mod- // e v e n t s els like EJB [8], CORBA [6], OSGi [9] and more can be p u b l i s h e s ChangeState s t a t e N o t i f y ; found in commercial applications and even more com- } ponent models – for example SOFA [19] or CoSi [20] – are the subject of research. The diversity of component models or even ap- UML only supports displaying attributes and in- proaches to components [1] poses problem when one terfaces the component provides. The CORBA-specific needs to visually represent a component or compo- flag “readonly” assigned to the attributes is missing nent-based application. UML 2.0 [5] component dia- on this diagram and could only be added using stereo- gram is often used for the visualization of component types, which would make the diagram clumsy. Events dependencies. The problem is that dependencies alone which the component publishes bring difficulties for do not provide much information about the component the UML component diagram, because it provides no itself. simple way how to represent them. It would be beneficial if there was a way to know If we would like to capture such additional infor- more about the elements that make up the bindings mation in the visualization of component based appli- between components. Based on the diversity of compo- cations, appropriate specific 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 significant fragmen- UML 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 56 Jaroslav Šnajberk, Přemek Brada To build a data container according to the ENT specification, a MOF model [4] was created in which key features of the meta-model were identified and model elements were designed. Implementation char- acteristics were considered in this phase and the meta- model was slightly modified. The structure of the MOF model and the description of design steps can be found in Section 4. For its good fit 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 meta- model was designed correctly, we implemented rep- resentations of several component models. The list of Fig. 2. ENT data container. these component models and a case study can be found in Section 6. layer implementing this meta-meta level has to be de- signed. The representation of this problem based on 2 Component meta-modeling MOF (Meta Object Facility) layers [4] is in Figure 2. The diversity of component models or even approaches On the M3 level there is a data structure able to to components [1] has been mentioned in several stud- hold information about both component models and ies, e.g. [12, 13]. There are differences in terms of the component based application. On the M2 level there is target use of the component model (desktop GUI, en- a definition of a component model (defined manually terprise applications, embedded or real-time systems), for each component model to provide meaningful rep- the richness of the interface contract type (from a sin- resentation) which explains the information stored on gle interface through a set similar to CORBA com- the M1 level. The M1 level should support automated ponents, to an extensible model as represented by the walking through component-based applications. iPOJO [14] research framework) as well as between flat In [2] we introduced the ENT meta-model which models like OSGi and hierarchical ones like SOFA. brought understandable component representation for The domain of meta-models is best represented both automated software agents and humans. It con- by the Meta-Object Facility (MOF) standard [4]. As tains support for a classification applicable to compo- described in the Introduction, it uses a layered ap- nent models, description of components and several proach to create progressively more specific structures views to represent this data based on user’s point of defining the terms of a particular domain, their at- interest. tributes and relationships. MOF itself has been a sub- ject of rich research. An interesting contribution is 1.1 Goal and structure of this paper Poernonomo’s work [15] on providing type-theoretical foundation for the meta-models. In this paper we focus on the design and implemen- UML [5] component diagram is often used to vi- tation of a data layer meeting the above requirements sualize component based applications and since ver- on storing and using of these additional information sion 2.0 of the notation it doesn’t suffer from problems for visualization of component-based applications. The presented in [17] – mainly the inability to clearly dis- layer implements the ENT meta-model as a MOF tinguish provided and required interfaces. The UML structure, using Eclipse Modeling Framework as the component diagram is nowadays a common tool for underlying technology. Besides describing the data the visualization of component dependencies. An layer itself, we also want share the experiences gained alternative visualization of component-based applica- in the process of designing its implementation. tions is presented in [16], this approach supports EFP In the next section we briefly review the related (extra functional properties) on top of a classical com- standards and research works in the areas of (com- ponent diagram. ponent) meta-modeling and visual representation. An overview of ENT meta-model is provided in Section 3 3 Overview of the ENT meta-model to understand the rest of the paper, including the ex- tensions introduced for the description of component The ENT meta-model is a MOF M3 model whose main models and component based applications. characteristic is the use of faceted classification Data layer for visualization 57 approach [3] to classify characteristic traits of compo- Each trait definition is classified using ENT classifi- nent models. The ENT meta-model is structured into cation giving different meaning to these trait defini- two levels. On the Component model level the main tions. For example, CORBA components (cf. Exam- characteristic features of a given component model are ple 1) have traits facets (provided interfaces), recepta- defined and the characteristic traits of components de- cles (required interfaces), event sinks, etc. fined in this model are classified. On the Application For other information that are important for the level the previous definitions are used and the inter- component model and cannot be described us- face elements belonging to individual components are ing traits, tags are used. Tags can expand information identified. 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 definitions resent components in way better readable to humans. are defined on the component model level in order to For complete ENT meta-model specification, be available on the application level. please refer to [2]. Compared to this base specification When the component model level is designed, set of the meta-model was extended in this work to support data structures for its component-based applications relations and dependencies between components, see is prepared. These data structures can fully describe Section 3.5. all applications implemented in the given component model. 3.1 Classification system 3.3 Application level The ENT classification system has eight facets called “dimensions”. These dimensions have predefined val- Components, from which an application is built from, ues and each dimension represents a different point of are represented on this level. The component model view on a component. Some facets can have more then has to be already defined on the component model one value, for instance Role which says if an element level because the application level references its ele- is 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 cor- responding component type and based on that, a set – Nature = {syntax, semantics, nonfunctional} of its traits is gained. Traits alone do not say any- – Kind = {operational, data} thing about the particular component, but elements – Role = {provided, required, neutral} that belong to the given trait do. Each trait has its – Granularity = {item, structure, compound} own element set – the interfaces, classes, events, etc. – Construct = {constant, instance, type} found on the component’s surface. The component is – Presence = {mandatory, permanent, optional} thus described by several sets of elements grouped to- – Arity = {single, multiple} gether by their characteristic traits. The trait has only – Lifecycle = {development, assembly, deployment, grouping purpose and through the reference to its trait setup, runtime} definition gives meaning to all elements contained in it. Concrete values of tags can be set on the component and its elements, thus providing their more precise de- 3.2 Component model level scription. Complete characteristic features of a given component For example, the “facets” trait of the component model are identified on this level of understanding. from Example 1 is a set { (book,AddressBook), (search, Identification of different component types is the AddressSearch) } and the (description,string) element first step, because the component model consists of has a tag set { (access,readonly) }. 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 different compo- nent types can be identified 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 definitions formation than programmers of component-based ap- that define 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 com- helps to fully characterize component of such a type. plex applications. 58 Jaroslav Šnajberk, Přemek Brada 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 modification only allows to add infor- These sets are defined by selector operators on the mation which elements are actually bound to other trait classification, 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 hierar- is needed. In [2] five category sets are presented, from chical component was added as an attribute to the par- which we introduce here only the first one (E-N-T) ent component structure. This modification together that gave name to the ENT meta-model. with element bindings allows to represent hierarchi- 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 first own elements and export/import only some of the el- group are elements that are contained in traits with di- ements that are contained by components it is built mension {role = provided}, 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 bound- similarly 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. E-N-T (Exports-Needs-Ties) 4 ENT model in MOF f E = λC.(C.role = {provided}) f N = λC.(C.role = {required}) This section introduces the data structures which form f T = λC.(C.role = {provided, required}) a concrete implementation of the ENT meta-model, to be used in visualization of component-based applica- tions. The explanations in this section use the descrip- Fig. 3. ENT category set. tion of the process of creating this design and imple- mentation, 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 Specific Language used to BA component in Example 1 belong to the “E” cat- define 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 defined 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 defined using MOF and the product of this defi- nition will be UML class diagram which can later be 3.5 Extensions of the ENT meta-model processed. Entities defined in this section can be im- plemented in specific programming language and used The original ENT meta-model [2] was concerned only as data layer in any other project. with the representation of standalone components. We The creation of a MOF model is most easily started wanted the ENT meta-model to be able to visualize from a formal definition of the corresponding domain whole component based applications with dependen- abstractions. We have to keep in mind that there can cies between components and we further wanted to be changes introduced by this MOF model because add support for hierarchical components. The exten- the formal description doesn’t consider implementa- sions of ENT meta-model are presented in this section. tion limitations and details like references on objects. A new meta-model entity Binding=(Element local, We will present the ENT model thus created in Element alien, direction ∈ {provided, required}) was three separate parts. The Classification system is mod- created to represent bindings between components. eled as a simple class ENTClassification with at- Bindings are realized through concrete elements that tributes corresponding to classification facets. These are physically linked to each other, with additional facets are modeled as enumerations, which is appropri- information about the binding direction – provided ate given their needs. The facet attributes were iden- means “from local to alien”, required means oppo- tified as mandatory, with “single” multiplicity except site. Every component has its own list of bindings, for Life-cycle and Role which have “multiple” multi- this 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 TraitDefinitions will be ac- ponent’s representation. cessed via references gained from arrays stored in Data layer for visualization 59 5 EMF implementation The MOF model could be converted to a concrete implementation manually, but EMF (Eclipse Model- ing Framework) was chosen instead. EMF is used for Model Driven Development and offers additional ser- vices 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 Fig. 4. Component model level in MOF. consists of interfaces and classes corresponding di- rectly to the model entities presented in the previous section. This implementation thus forms a run-time ENT representation of any given component model ComponentModel. This level quite corresponds to its and its applications and will be used in every project formal description. The “note” attribute was added to that uses the ENT meta-model; for some such future all these elements, to provide for descriptive informa- projects see Section 7. tion about the implemented component model in this An editor of ENTMM data was created to pro- data structure. vide GUI for component model definition described in The application level is represented by five elements Section 3.2; it is very similar to editor displayed in and it is the most changed part of the ENT meta- Figure 6. This editor is implemented as Eclipse plugin model compared to its formal description in [2]. The and can’t be used without the Eclipse IDE. changes were due to the extensions described in Sec- EMF however offers more than just the advanced tion 3.5. Component, Trait and Tag entities contain code generator and Eclipse plug-ins to support model- references to their descriptors at the component model ing. One of its features is advanced work with the XML level. Binding and Element entities are component mo- format. Editors automatically save all model data in del independent. an XML file which can be easily accessed using EMF- generated 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” file, where all information and settings re- lated to the model are stored. Similarly there is a “GENMODEL” file which is used to store set- tings 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. For- tunately, EMF is able to set many features for the Fig. 5. Application level in MOF. 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. 60 Jaroslav Šnajberk, Přemek Brada The most important one was to configure model. SOFA [19] is a research component model from the ECORE editor so that entity references are used Charles University, Prague. A SOFA component is in- (instead of instances) for many model class attributes. teracting with other components only via designated This prevented the undesired effect that the same trait provided and required interfaces. A component can be definition could not be shared by several component viewed as both a black-box and gray-box entity. representations. Definition of SOFA component model in ENT is provided in [2], and repeated below for understanding 6 Creating component model of this case study. representations Definition of SOFA component model in ENT: The ENTMM editor for Eclipse was used to create the SOFA component framework defines one kind of com- representation 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 defined) and the CoSi [20] and MVE [11] models (their definitions were newly created). In this process, provides - provided interfaces the plugins created by EMF and described in Section 5 metatype = interface, were used. classifier = ({syntax}, {operational}, {provided}, By adding these plugins, a new file type appears {structure}, {instance}, {permanent}, {multiple}, in Eclipse while creating new file, named “ENTMM Lifecycle), Model”. To start defining the representation, the user requires - required interfaces has to choose this file type and select “Component metatype = interface, Model” as an “Model Object” when asked. ENTMM classifier = ({syntax}, {operational}, {required}, editor like the one in Figure 6 will appear and by using {structure}, {instance}, {permanent}, {multiple}, its simple interface, the user is able to define a new Lifecycle), component model easily. properties - provided interfaces metatype = property, classifier = ({syntax}, {data}, {provided}, {item}, {instance}, {permanent}, {multiple}, {development, assembly, runtime}), protocol - provided interfaces metatype = protocol, and classifier = ({semantics}, {operational}, {provided, required}, {item}, {type}, {permanent}, {na}, {development, assembly, runtime}). The representation of the SOFA component model was created in ENTMM editor and the final view of this implementation can be seen in Figure 6. As men- tioned in Section 5, EMF stores data in XML format. XML version of the SOFA component model repre- sentation is given in Example 2. This representation can be recreated by intuitive use of editor and filling data from the formal definition to the prepared data structure. The generated XML structure does not follow all Fig. 6. ENTMM editor in Eclipse IDE. 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 compo- nent models. 6.1 Case study of SOFA As a case study, the representation of the SOFA com- Example 2. ponent model is presented below to show how sim- ple it is to create a definition of a new component ENT philosophy. All these efforts should result in advanced visual- 1. Dynamic loading of any component based appli- < 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 ”> cation no matter which component model is used. < 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= 2. Component displayed with additional information. ” s t r u c t u r e ” a r i t y =” m u l t i p l e ” 3. Support of different views, based on user needs. 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”> The visualized component should look similar to component visualized in Figure 7. This kind of visu- p r o v i d e d alization will meet all requirements discussed in this < l i f e c y c l e >development paper. < l i f e c y c l e >assembly < l i f e c y c l e >deployment < l i f e c y c l e >setup < l i f e c y c l e >runtime < 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 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 S e t name=” p r o t o c o l ” Fig. 7. AddressComponent visualized in ENT style. metatype=” p r o t o c o l ”> 8 Conclusion 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 representa- currently 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 dia- works. 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 pro- ENT meta model EMF implementation. This applica- vided and supplemented with a case study of the rep- tion 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 final product plication loaders. This should give us a tool able to were presented. 62 Jaroslav Šnajberk, Přemek Brada The key contribution of this paper is the descrip- 14. C. Escoffier and R.S. Hall: Dynamically adaptable ap- tion of a MOF-based data layer able to hold and inter- plications with iPOJO service components. Proceed- pret rich information about various component mod- ings of 6th International Symposium on Software Com- els 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 metamodelling. In: Architecting Systems with Trust- complex component-based applications. worthy 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 definitions 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. Lüer, and D.S. Rosenblum: UML component di- life 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. Plášil, and S. Višnovský: Behavior protocols for soft- ware components. IEEE Transactions on Software En- References gineering, 28 (10), 2002. 19. T. Bures, P. Hnetynka and F. Plasil: SOFA 2.0: Bal- ancing advanced features in a hierarchical component 1. C. Szyperski: Component software: beyond object- model. Proceedings of SERA 2006, IEEE CS, 2006. oriented programming, 2nd edition. Addison-Wesley 20. P. Brada: The CoSi component model: reviving the Professional, 2002. black-box nature of components. Proceedings of the 2. P. Brada: The ENT Meta-Model of Component In- 11th International Symposium on Component Based terface, version 2. Technical report DCSE/TR-2004- Software Engineering, October 2008, Springer Verlag, 14, Department of Computer Science and Engineering, LNCS 5282. University of West Bohemia, 2004. 3. R. Prieto-Diaz, P. Freeman: Classifying software for reusability. IEEE Software 18 (1), 1987. 4. Object Management Group: Meta Object Facility (MOF) Core Specification, Version 2.0. OMG speci- fication formal/06-01-01 5. Object Management Group: UML Superstruc- ture Specification, Version 2.2. OMG specification formal/2009-02-02. 6. Object management Group: CORBA Components, Version 3.2. OMG Specification formal/02-12-06 7. D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks: Eclipse modelling framework, Second Edi- tion. Addison Wesley, 2009. 8. Sun Microsystems, Inc.: Enterprise JavaBeans(TM) Specification, Version 2.0. Sun Microsystems, Inc. 2001. 9. OSGi Alliance: OSGi Servise Platform Core Specifica- tion. OSGi Alliance, 2009. 10. F. Plǎšil, D. Bǎlek, and R. Janeček: SOFA/DCUP: ar- chitecture for component trading and dynamic updat- ing. Proceedings of ICCDS’98, Annapolis, Maryland, USA, 1998. IEEE CS Press. 11. M. Roušal and V. Skala: Modular visualization envi- ronment - MVE. Proceedings of International Confer- ence ECI 2000, Herlany, Slovakia. 12. N. Medvidovic and R.N. Taylor: A classification and comparison framework for software architecture de- scription languages. In: IEEE Transactions on Soft- ware Engineering 26 (1) 2000, 70–93. 13. I. Crknovic, M. Chaudron, S. Sentilles, and A. Vulgar- akis: A classification framework for component models. Proceedings of the 7th Conference on Software Engi- neering and Practice in Sweden, 2007.