Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » [Acceleo] Bug when accessing abstract UML metaclasses
[Acceleo] Bug when accessing abstract UML metaclasses [message #765194] Tue, 13 December 2011 15:39 Go to next message
Eclipse UserFriend
Hi all,

I guess I've found a bug in Acceleo or in OCL (i'm not really certain), when
using UML in combination with a static profile implementation.

Consider the following template

[template public utp2ttcn3(model : Model, simulateSUT : Boolean) ?
(model.viewpoint = 'testModel')]
[comment @main/]

[for (testContext : TestContext | q_allTestContexts(model))]
[file (model.name.concat('.xyz'), false, 'UTF-8')]
module [testContext.base_BehavioredClassifier.name/] { //throws an
IllegalArgumentError due to the base_BehavioredClassifier property
} //TTCN-3 end
[/file]
[/for]
[/template]

UML::BehavioredClassifier is an abstract metaclass of UML, TestContext a
stereotype of UTP. In my concrete model, <<TestContext>> is applied on
UML::Component, which is in turn a concrete subclass of
UML::BehavioredClassifier

Now, I changed the code at the respective location from

[testContext.base_BehavioredClassifier.name/]

to

[testContext.base_BehavioredClassifier.oclAsType(Component).name/]

and it works as expected. I'd be happy to file a bug once it is clear
whether this is related to Acceleo or OCL.

Here is the corresponding stack trace:

!ENTRY org.eclipse.ocl 4 10 2011-12-13 16:34:09.281
!MESSAGE Evaluation failed with an exception: (no message)
!STACK 0
java.lang.IllegalArgumentException
at
org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigateProperty(EcoreEvaluationEnvironment.java:258)
at
org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigateProperty(EcoreEvaluationEnvironment.java:1)
at
org.eclipse.ocl.EvaluationVisitorImpl.visitPropertyCallExp(EvaluationVisitorImpl.java:2088)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitPropertyCallExp(AcceleoEvaluationVisitor.java:1124)
at
org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(PropertyCallExpImpl.java:238)
at
org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(AbstractEvaluationVisitor.java:248)
at
org.eclipse.ocl.EvaluationVisitorDecorator.visitExpression(EvaluationVisitorDecorator.java:156)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1747)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1012)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoFileBlock(AcceleoEvaluationVisitor.java:409)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1708)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1012)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoForBlock(AcceleoEvaluationVisitor.java:522)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1698)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1012)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoTemplate(AcceleoEvaluationVisitor.java:880)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1682)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1012)
at
org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(QueryImpl.java:152)
at org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:62)
at
org.eclipse.acceleo.engine.generation.AcceleoEngine.doEvaluate(AcceleoEngine.java:360)
at
org.eclipse.acceleo.engine.generation.AcceleoEngine.evaluate(AcceleoEngine.java:141)
at
org.eclipse.acceleo.engine.service.AcceleoService.doGenerateTemplate(AcceleoService.java:869)
at
org.eclipse.acceleo.engine.service.AcceleoService.doGenerate(AcceleoService.java:585)
at
org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.generate(AbstractAcceleoGenerator.java:193)
at
org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.doGenerate(AbstractAcceleoGenerator.java:158)
at
de.fraunhofer.fokus.testing.fokusmbt.m2t.ttcn3.TTCN3pio.module.Utp2ttcn3.doGenerate(Utp2ttcn3.java:194)
at
de.fraunhofer.fokus.testing.m2t.acceleo.testing2ttcn3.serviceimpl.Testing2TTCN3ServiceImpl.transform(Testing2TTCN3ServiceImpl.java:128)
at
de.fraunhofer.fokus.testing.fokusmbt.m2t.ttcn3.ttcn3pio.testsuite.TTCN3pioTester.runMWO(TTCN3pioTester.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62)
at
org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)

Marc-Florian
Re: [Acceleo] Bug when accessing abstract UML metaclasses [message #765626 is a reply to message #765194] Wed, 14 December 2011 12:12 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
Hi Florian,

I must admit that I don't really see what's going on behind the scene here... If you have a simple reproductible sample (Using an already existing profile or a minimal one) that you can provide, that would be great. Please fill a bug against Acceleo, we'll reassign to OCL if it comes to it, this is most likely due to the evaluation engine though.

Laurent Goubet
Obeo
Re: [Acceleo] Bug when accessing abstract UML metaclasses [message #765670 is a reply to message #765626] Wed, 14 December 2011 13:43 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Florian

I suspect this may be a more fundamental lack of specification. One of
the UML spec guys was explaining to me yesterday that Sterotypes are not
types, so it may well be that testContext.base_BehavioredClassifier.name
is traversing a non-type. It is therefore a surprise to me that
testContext.base_BehavioredClassifier.oclAsType(Component).name works;
well done for finding a workaround.

There is no mention of profiles or stereotypes in the OCL specification,
so apart from an expectation that they should work, there are no clues
as to how. There is only a single example in UML Super 2.4 in 18.3.2
where self.base_Interface.ownedAttributes->size() = 0 suggests your
usage is sensible.

The IAE suggests that either testContext.base_BehavioredClassifier was
not an EObject (unlikely) or was an EObject that had no "name" property
or that the wrong "name" property was in use. You are using
org.eclipse.ocl.ecore.EcoreEvaluationEnvironment, so your UML model has
been converted to Ecore. The OCL Ecore binding has and needs no profile
support.

The compile-time analysis of testContext.base_BehavioredClassifier.name
appears to succeed. It is the run-time that needs the oclAsType() to
help it out. I therefore suspect that the Ecore code synthesized to
create the testContext.base_BehavioredClassifier object has created an
object with an inaccurate eClass(). This points to the UML2Ecore
conversion, since that is where the profiles are applied and the
profile-free Ecore representation is synthesized.

A small example showing the steps you take and the tool versions would
be helpful.

Regards

Ed Willink

On 14/12/2011 04:12, Laurent Goubet wrote:
> Hi Florian,
>
> I must admit that I don't really see what's going on behind the scene
> here... If you have a simple reproductible sample (Using an already
> existing profile or a minimal one) that you can provide, that would be
> great. Please fill a bug against Acceleo, we'll reassign to OCL if it
> comes to it, this is most likely due to the evaluation engine though.
>
> Laurent Goubet
> Obeo
Previous Topic:[Acceleo] How modular is the acceleo architecture?
Next Topic:[Xpand] import issue
Goto Forum:
  


Current Time: Tue Apr 16 09:22:56 GMT 2024

Powered by FUDForum. Page generated in 0.07677 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top