The Eclipse Modeling Framework (EMF) and its meta-meta model Ecore support uni-directional and bi-directional references. It is quite common that references are defined uni-directionally only because of saving storage space or separating meta models, which is problematic when implementing Object Constraint Language (OCL) constraints that require navigation against the direction of uni-directional references. This is essential for certain approaches, e.g., incremental evaluation of OCL constraints on models shown by Altenhofen et al. that is used in SAP's Modeling Infrastructure (MOIN). In this paper, we present an approach that overcomes the aforementioned issue by providing navigation across non-navigable Ecore references via OCL. We further discuss different alternative solutions and briefly describe the realization that was outcome of a project in cooperation with the SAP AG

Berger, Philipp

Giese, Holger

Hanysz, Martin

Hildebrandt, Stephan

Hoppe, Tobias

Seibel, Andreas

Uhl, Axel

English

Electronic Communications of the EASST (European Association of Software Science and Technology)

Electronic Communications of the EASSTVolume 36 (2010)Proceedings of theWorkshop on OCL and Textual Modelling(OCL 2010)Navigating Across Non-Navigable Ecore References via OCLMartin Hanysz, Tobias Hoppe, Axel Uhl, Andreas Seibel, Holger Giese, Philipp Berger andStephan Hildebrandt6 pagesGuest Editors: Jordi Cabot, Tony Clark, Manuel Clavel, Martin GogollaManaging Editors: Tiziana Margaria, Julia Padberg, Gabriele TaentzerECEASST Home Page: http://www.easst.org/eceasst/ ISSN 1863-2122ECEASSTNavigating Across Non-Navigable Ecore References via OCLMartin Hanysz1, Tobias Hoppe1, Axel Uhl2, Andreas Seibel1, Holger Giese1,Philipp Berger1 and Stephan Hildebrandt11 holger.giese@hpi.uni-potsdam.de, http://www.hpi.uni-potsdam.de/giese/Hasso Plattner Institute at the University of PotsdamProf.-Dr.-Helmert-Str. 2-3, 14482 Potsdam, Germany2 axel.uhl@sap.comSAP AG, Office of the CTODietmar-Hopp-Allee 16, 69190 Walldorf, GermanyAbstract: The Eclipse Modeling Framework (EMF) and its meta-meta model Ecoresupport uni-directional and bi-directional references. It is quite common that refer-ences are defined uni-directionally only because of saving storage space or sepa-rating meta models, which is problematic when implementing Object ConstraintLanguage (OCL) constraints that require navigation against the direction of uni-directional references. This is essential for certain approaches, e.g., incrementalevaluation of OCL constraints on models shown by Altenhofen et al. that is used inSAP’s Modeling Infrastructure (MOIN). In this paper, we present an approach thatovercomes the aforementioned issue by providing navigation across non-navigableEcore references via OCL. We further discuss different alternative solutions andbriefly describe the realization that was outcome of a project in cooperation with theSAP AG.Keywords: OCL, Ecore, EMF, Navigation1 IntroductionThe Object Constraint Language (OCL) [Obj06b] was originally designed as a formal lan-guage to describe invariants and queries on Unified Modeling Language (UML) [Obj04] models.Nowadays, the application of OCL is more extensive, e.g., it is applied in Meta Object Facil-ity (MOF) [Obj06a] compliant tools or the Eclipse Modeling Framework (EMF) [SBPM08] toconstrain EMF models that are conform to the meta-meta model Ecore. However, in contrast toComplete MOF (CMOF) [Obj06a, pp. 45], Ecore, which is conceptually equal to Essential MOF(EMOF)[Obj06a, pp. 31], uses the restricted reference concept of EMOF. In CMOF references(associations) always have association ends, which implies that there is always the possibility toaddress the opposite of a reference, even if the reference is defined as uni-directional.In Ecore references are always uni-directional. A bi-directional reference is realized by ex-plicitly modeling two references as being the opposite of each other. Additionally, Ecore doesnot support the concept of association ends. Thus, if defining a reference as uni-directional, theopposite of the Ecore reference cannot be addressed. Defining bi-directional references betweenelements of different meta models is not supported by EMF, because it would result in cyclic1 / 6 Volume 36 (2010)dependencies between these meta models. This is problematic because legacy EMF meta mod-els do not always provide bi-directional references (cf. UML2 tools1) to save storage space andmeta models may be separated in several meta models (separation of concerns). In both cases,OCL constraints cannot be expressed against navigation direction. This is essential for certainapproaches, e.g., incremental evaluation of OCL constraints on models shown by Altenhofen etal. in [AHK07] that is implemented in SAP’s Modeling Infrastructure (MOIN). Furthermore,OCL constraints can be optimized by restructuring navigation, which is restricted when refer-ences are uni-directional. Thus, navigating across non-navigable references via OCL is requiredto overcome this issue in such cases.In this paper, we present an approach that overcomes this issue with minimal impact to existingapplications. It supports navigation across non-navigable references via OCL within and betweenEMF meta models without adding cyclic dependencies. The approach was implemented as a partof a project (see [Ber10, Hop10, Han10, Sch10]) in cooperation with the SAP AG2. Therefore,we first introduce our requirements and design decisions in Section 2. In Section 3 we give abrief explanation of our approach and finally conclude this paper in Section 4.2 Design ConsiderationsTo support the acceptance of our approach by the EMF community, the following requirementshave to be satisfied:1. Avoid invalidation of existing technologies2. Avoid impact on current usage of technologies3. Avoid high integration effortsThere are several alternatives to provide navigation across non-navigable references in Ecore.A straightforward approach is to only use bi-directional references in EMF models instead of uni-directional ones. Consequently, partitioning of EMF models would be restricted due to cyclicdependencies and the partition in two meta models as shown in Figure 1 would not be possible.This clearly violates requirement two, because it restricts how EMF models can be partitioned.Another approach that avoids the dependency cycles a bi-directional reference creates, is toallow the opposite reference to be contained by the original reference. This circumvents thelimitations of the aforementioned approach, but yields severals other problems. For examplethe validation of multiplicity or ordering constraints for the opposite reference becomes a veryexpensive operation, due to the fact that the list of referenced instances is not stored explicitly.Apart from that, the original architecture assumes that a reference is always contained by anelement. Since this assumption does not hold anymore, existing technologies relying on it mightbe invalidated.To circumvent those requirement violations, another alternative that avoids to change Ecorehas been taken into account. It relies on annotations, which are added to uni-directional refer-ences in EMF models, as shown in Figure 1. The example shows a simple situation with two1 http://www.eclipse.org/uml2/2 http://www.sap.comProc. OCL 2010 2 / 6ECEASSTFigure 1: An example that visualizes the problem of uni-directional referencesmeta models defining two concerns of a company. The annotations contain opposite role namesof the references. This solution does not impact the usage of existing technologies, because itcan be seamlessly integrated into existing EMF models. It also does not impact requirementthree since these annotations can be automatically generated. To navigate across non-navigablereferences using these annotations, we extend the OCL meta model as well as the OCL tool-ing of EMF. Our extension of OCL does not invalidate requirement two because it is downwardcompatible.3 ContributionIn this section, we explain how we exploit the annotation concept of Ecore and the extensionswe have made to the OCL tooling in EMF.3.1 Adding Annotations to EMF ModelsAnnotations in Ecore are defined by the EAnnotation element, which can be added to any ele-ment. EAnnotation may have a details entry, that maps key to value attributes. In our approach,every uni-directional reference that should be navigated in its opposite direction, represented byan EReference element, is associated with an EAnnotation element holding a details entry thathas a key attribute “Property.oppositeRoleName”. The value attribute contains the name of theopposite role. EMF models that should benefit from bi-directional navigability can be modifiedmanually or automatically.3.2 Extending OCLOur approach does not come without extending EMF’s OCL, but we are using the dot notationfor navigation across references to be compatible to legacy OCL constraints. Thus, there is noneed to introduce an extra notation to make the missing navigability explicit. For example, theexpression in Figure 2 refers to the annotated opposite role name of the EReference intern. Thisconstraint expresses, that each Student must have at least one Employee as his advisor.The extensions we have made are in the background and extend OCL’s abstract syntax (metamodel), as well as its parser, validator, and evaluator.3 / 6 Volume 36 (2010)con t ex t S t u d e n t inv :s e l f . a d v i s o r . s i z e ( ) > 0Figure 2: An example OCL expression using reverse navigation3.2.1 Abstract Syntax of OCLAlthough we did not change the concrete syntax of OCL, we have extended the abstract syntaxof OCL to reflect the navigation across non-navigable references. Therefore, we extended theNavigationCallExp with an OppositePropertyCallExp as shown in Figure 3. An OppositeProper-tyCallExp describes the navigation of a reference between two elements that are not explicitlyconnected via an EReference pointing from the source element to the target elements, whichavoids cyclic dependencies if elements are defined in different meta models. Instead, this asso-ciation is built by an EReference from the target that defines the opposite navigation direction.The OppositePropertyCallExp inherits a navigation source property, which is the element fromwhere the navigation is started. It is also related to a referred opposite property, which containsthe opposite role name that is defined in the EAnnotation of an EReference pointing to the navi-gation source element.Figure 3: Extended OCL meta model3.2.2 OCL ParserOCL constraints are handled by means of their abstract syntax. Thus, OCL constraints definedin the concrete syntax have to be parsed into the abstract syntax first. The parsing of OCLconstraints in EMF is performed by an OCL analyzer. We extended the parsing functionality tocreate OppositePropertyCallExp instances when necessary.When the OCL analyzer comes across the dot notation, it tries to resolve the token next toit to a type name, a variable name, a property name, an opposite property name, an associationclass name, and finally to an undefined name. The resolving of an opposite property name isProc. OCL 2010 4 / 6ECEASSTencapsulated in the OppositeEndFinder to allow different implementations of it3. The example inFigure 2 contains an opposite property after the first dot, since advisor is the annotated oppositerole name of the EReference intern. Hence, an OppositePropertyCallExp is created.3.2.3 OCL ValidatorAfter parsing the OCL expression into an abstract syntax, it needs to be validated. Through-out the whole OCL tooling of EMF, several visitors are used. To make these visitors aware ofopposite properties, the common Visitor interface has been extended with a visitOppositeProper-tyCallExp() method and the AbstractVisitor has been adapted to properly call this method whencoming across an OppositePropertyCallExp. The Visitor used to validate OCL expressions is theValidationVisitor and has been modified to implement this method to check if the correctness ofthe OppositePropertyCallExp is given.3.2.4 OCL EvaluatorThe OCL evaluator actually executes the evaluation of the parsed and validated OCL expres-sion. For this task, the EvaluationVisitor is used. It has also been modified to implement thevisitOppositePropertyCallExp() method and use a modified, opposite property aware version ofthe EvaluationEnvironment to perform the navigation.Navigating an OppositePropertyCallExp results in the set of instances, that reference one ofthe expression’s source instances via an EReference that is annotated with the given oppositerole name. Therefore, the evaluation of the expression in Figure 2 leads from self to all instancesof Employee that reference that one instance of Student. Our approach uses EMF’s reflectionmechanism for resolving the requires instances to avoid cyclic dependencies between meta mod-els. To find all instances pointing to an EObject via an EReference, EMF provides a utility calledECrossReferenceAdapter. The cross-referencer iterates through the content tree rooted at theinitially passed EObject, Resource, or ResourceSet and checks for each retrieved reference ofall objects if it points to the wanted object or not. In case of a positive match, the object is addedto the result [SBPM08, pp. 523].Because the cross-referencer is a simple implementation, we may get scalability issues whendealing with large models. Thus, we have implemented a modular interface to integrate alter-native technologies for resolving OppositePropertyCallExps, e.g, Model Query 2 (MQ2)4. MQ2provides an efficient interpreter for resolving queries, which comes with an index structure. Inthis alternative, MQ2 queries are formulated and interpreted to return all objects referencing thesource via an EReference with a specific EAnnotation.4 Conclusions & Future WorkThroughout this paper, we presented a solution that overcomes a restriction of Ecore. This re-striction prohibits navigability through EMF models via OCL constraints, because uni-directional3 currently Model Query 2 is used to find the properly annotated references4 http://www.eclipse.org/modeling/emf/?project=query25 / 6 Volume 36 (2010)references cannot be navigated in reverse. This is problematic, when working with EMF modelsthat provide many uni-directional references (cf. UML2 tools). Our approach can be seam-lessly integrated into existing technologies. It uses the EAnnotation concepts of Ecore. Theseannotations are used by an extension of EMF’s OCL that we have implemented.As future work we plan to evaluate the scalability of our approach by using EMF’s cross-referencer, MQ2, and other indexing technologies like EMF Index5. Furthermore, multiplicitiescannot be expressed via the annotations currently.Bibliography[AHK07] M. Altenhofen, T. Hettel, S. Kusterer. OCL Support in an Industrial Environment.In Proc. of the Workshops and Symposia at MoDELS 2006, Genoa, Italy. LNCS,pp. 169–178. Springer, 2007.[Ber10] P. Berger. Central Event Manager for the Eclipse Modeling Framework. 2010.http://www.hpi.uni-potsdam.de/giese/gforge/bibadmin/uploads/pdf/Ber10 PhilippBerger Bachelorarbeit.pdf.[Han10] M. Hanysz. Instance-Based Context Calculation of OCL Expressions. 2010.http://www.hpi.uni-potsdam.de/giese/gforge/bibadmin/uploads/pdf/Han10 MartinHanysz Bachelorarbeit.pdf.[Hop10] T. Hoppe. Synthesis of Event Filter determining the reevalu-ation of affected OCL expressions. 2010. http://www.hpi.uni-potsdam.de/giese/gforge/bibadmin/uploads/pdf/Hop10 TobiasHoppe Bachelorarbeit.pdf.[Obj04] Object Management Group. UML 2.0 Superstructure Specification. October 2004.Document: ptc/04-10-02 (convenience document).[Obj06a] Object Management Group. Meta Object Facility. 2.0 edition, January 2006.[Obj06b] Object Management Group. Object Constraint Language. 2.0 edition, May 2006.[SBPM08] D. Steinberg, F. Budinsky, M. Paternostro, E. Merks. Eclipse Modeling Framework2.0. Addison Wesley, 2 edition, December 2008.[Sch10] T. Schro¨ter. Effiziente Navigation bei der OCL-Auswertung. 2010.http://www.hpi.uni-potsdam.de/giese/gforge/bibadmin/uploads/pdf/Schroeter10 TheaSchroeter Bachelorarbeit.pdf.5 www.eclipse.org/proposals/emf-index/Proc. OCL 2010 6 / 6

Navigating Across Non-Navigable Ecore References via OCL

https://journal.ub.tu-berlin.de/eceasst/article/download/440/428

Navigating Across Non-Navigable Ecore References via OCL

Abstract

Similar works

Full text

Available Versions

Electronic Communications of the EASST (European Association of Software Science and Technology)