| Summary: | How to process OCL Abstract Syntax Trees | ||
|---|---|---|---|
| Product: | Community | Reporter: | Miguel Garcia <mgarcia512> |
| Component: | Articles | Assignee: | Wayne Beaton <wayne.beaton> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | elena.tibrea, give.a.damus, roman.porotnikov |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://www.sts.tu-harburg.de/~mi.garcia/ | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Miguel Garcia
Created attachment 55464 [details]
article in Eclipse Tech Article format, jared plugin, source code
ASTs can be serialized as XMI (still part of OCL Interpreter) http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.ocl.doc/references/examples/oclInterpreterExample.html Why not use a viewer of the XMI file? How does it look like (compared to the example you bring)? Created attachment 55757 [details]
Comparison with XMI tree visualization of a serialized OCL AST
(In reply to comment #2) Yes, I should have mentioned that in the article too. The side-by-side comparison can be found in the PDF at https://bugs.eclipse.org/bugs/attachment.cgi?id=55757 The xmi serialization of an OCL AST so far allows storing only one expression. Has this been a problem for you? By patching a few XPath expressions several OCL ASTs can be made to co-exist in the same .xmi , hearing about a general solution for this would be great. Miguel Garcia That OCLASTView also looks like the foundation of a very handy "logical view" provider for OCLExpresisons in the JDT Debugger. :-) On the subject of storing multiple expressions in one document: note that the OCL console example is just that: an example. There is nothing about the AST model that prevents multiple expressions being stored in one XMI document. Another practical example might read in a textual OCL document (with multiple constraints in potentially multiple package/classifier/operation contexts) and store the parsed constraints as XMI. Of course, that would use internal APIs until bug 144210 is fixed ... Hi, Miguel,
Good article! This really showcases an important component of the EMFT OCL implementation that is often overlooked: the abstract syntax model. Parsing and evaluating expressions is great, but this article makes OCL look fun!
I have a few specific comments, and really not much to criticize.
S.1 "Building blocks"
- P.1. should read "OCLCST.ecore" (missing T). Note that the concrete syntax
model is "internal", not API
- I don't think the parser has a concrete-syntax-validating visitor, but only
an abstract-syntax validator. I suppose the parser's AST builder
(OCLParser class; OCLLPGParser is the CST builder) is, effectively, a CST
validator
- P.2, regarding context: might be better to consistently use UML terminology
for properties: "property" or "attribute"; "reference" is an EMFism
S.2 "Visitors are our friends"
- for those rare people who may not be familiar with the Visitor pattern, it
is probably a good idea to reference GoF95 here
- P.2. Good idea to call out the AbstractVisitor, here.
S.3.1 "What to do in the handler for a leaf node"
- P.2. I do not understand what is meant by "does not own a reference but
instead has an association to an element in the underlying class model".
The example cited (VariableExp) does not reference anything in the class
model except its type; the main purpose is to reference a Variable from the
OCL model.
- P.5. To answer your TODO question: The name of the invalid literal is
"OclInvalid" and the void literal is "null". Previous interim versions
of the OCL 2.0 specification used the symbol "OclUndefined", but this is
renamed as "null".
S.3.3 "What sets CallExp apart"
- I don't see why you "called out" (forgive the pun) CallExps as having
interesting contained sub-expressions. The same could be said for the
initializers of variables and the arguments of operation calls
- P.1. Would it be worth mentioning that in programming-language parlance,
OCL's "source" is usually called "target"? Even more confusing is that,
in MessageExps, the target is actually named "target". :-)
S.3.4 "Things we swept under the carpet"
- P.2 Actually, TupleLiteralPart is defined in the OCL specification's
metamodel. It is shown in Figure 8.7 (p. 48) and is indirectly mentioned
in the description on p. 50 of the TupleLiteralExp::part assocation. The
problem is, that it is incorrectly indicated as an association to the
Variable metaclass, which does not have a reference to UML::Property.
The description of TupleLiteralExp is missing, but it is in the
Rose model. This should be raised with OMG if it hasn't been, already
- P.2 Yes, the AbstractVisitor in the OCL implementation should
probably have separate visitation of the CollectionItem and CollectionRange.
This is forthcoming in MDT OCL 1.1 :-)
- P.2, regarding Variable. Variables are visited in the context of an AST
construct that defines them. Such is the case for the LetExp and
IteratorExp, for example (I see that this is explained, later). Also,
version 1.1 of the OCL implementation will introduce the ExpressionInOcl
metaclass (described in Chapter 12 of the OCL spec). This expression is
visitable and provides the context in which the context variables ("self",
operation parameters, etc.) are visited
S.3.4 "Variables and environments"
- glad to see the exposition of implicit variables and collect expressions
- P.2: to answer the TODO question: the FeatureCallExp metaclass defines the
isMarkedPre property. Unfortunately, Section 8.3.2 "FeatureCall Expressions"
omits the description of the FeatureCallExp metaclass. More importantly,
a VariableExp cannot be marked with @pre because variables (such as operation
parameters or Let variables) don't exist before the invocation of the
operation
S.5 "Second visitor"
- P.5. Good tip about stateful visitors.
S.6 "How many visitor schemes"
- P.2. You may be interested to know that, in the adoption of EMF2.3 in the
1.1 version of the OCL implementation, the first thing I did was to
parameterize the Visitor interface with a result type ;-)
S.7 "Third Visitor"
- I like this Walker pattern. Care to contribute it for MDT OCL 1.1?
- P.1 The OCLASTWalker<T> link links to the XMLForOCLWithWalker.java
OCLASTWalker.java:
- I see a number of cascade "if" statements checking instanceof. This is
a good case for the EMF-generated Switch class, ExpressionsSwitch.
Christian, Thanks a lot for the careful review. I'll work your comments into an updated version. Just give me a few days :) Miguel Created attachment 57434 [details]
update adopting Christian W. Damus' comments
Same structure as before: zip with article in Eclipse Tech Article format, jared plugin, source code.
Hi, Christian,
> I like this Walker pattern. Care to contribute it for MDT OCL 1.1?
Yes, feel free to include it in MDT OCL.
Miguel
Created attachment 57455 [details]
last corrections from my side
Some TODOs had slipped into the uploaded version. I've corrected that. I also took the opportunity to add as an appendix the comparison with the XMI Tree Visualization (discussed in attachement 55757) as readers may also come up with that question.
Miguel
I am going to update the source code to work against the hot-off-the-press, generified, UML-aware API. (I haven't even looked at it so I don't know what I'm getting into, but if Christian says it's better then I'll trust him ;-) Regards, Miguel Yes, I think that's a good idea for your article, esp. as it focuses so closely on the Abstract Syntax model. The latest integration build for M5 rationalizes the abstract syntax to catch up to some of the changes in the final OCL 2.0 spec, including:
- introduction of the UnlimitedNaturalLiteralExp
- elimination of the specializations of PrimitiveType
(e.g., PrimitiveBoolean, PrimitiveInteger)
Also of note (I think your article remarks on the subject) is that the OCL Standard Library is now delivered as an Ecore model in the /models folder of the org.eclipse.ocl.ecore plug-in (likewise as a UML model for the UML binding).
I'll need to work up a revision of bug 143580, too ...
Created attachment 60058 [details]
updated for Generics, UML2, and the visitor walker pattern of MDT OCL 1.1
The article now provides in addition to the Ecore-based example an UML2-based one, showing how to use OCLASTView in conjunction with tooling (graphical or not).
The last section on the walker pattern has been dropped, as a variation of that suggestion is now present in MDT OCL 1.1.
All visitors in the article (the XML visualizer, the OCL cloner, the arithmetic simplifier) are now based on the MDT OCL 1.1 generic walker pattern, thus working for both Ecore and UML.
Perhaps there's a better coding practice for setting the context of an OCL expression (in the code snippet placed between Figures 13 and 14) but I haven't found such example in the Javadoc. Suggestions are welcome.
Regards,
Miguel
1.Select post_upgradePointsEarned_1(...) in Service class for both RandL.uml and RandL.ecore 2.Take a look at the AST view for both models (you have the same type of org.eclipse.ocl.SemanticException for other OCL expressions in the uml model too) Regards (In reply to comment #14) I've created starting from scratch a minimal .uml example to isolate the problem, that model contains just one "Owned Type Class" owning one "Operation". The operation has the same name (calcPoints) but this time is marked isQuery. Another difference is for uml::Integer to be the argument and return type instead of EIntegerObject (the latter resulting from the Ecore2UML conversion with default options). In this case, the same OCL expression that MDT OCL can parse over an .ecore model cannot be parsed on the (automatically converted) .uml counterpart. Perhaps someone more skilled with Ecore2UML conversions can provide a general solution (to be included as Tip in the article). Failing that, I'll manually patch RandL.uml along the lines above. Miguel Created attachment 61195 [details]
sample models updated to correct minor typos
The examples (RandL.ecore and RandL.uml) have been updated to remove those disturbing parsing errors, whose origin was varied:
a) some were typos (wrong case in identifiers),
b) the already mentioned EIntegerObject instead of uml::Integer,
c) OCL post-conditions being parsed as OCL body (and thus the unrecognized variable 'result'),
d) an OCL expression referring to a static (class-scoped) operation in the Ecore-based model.
Christian, I've tested the OCLASTView plugin for the latest integration build (I200704251854) of MDT OCL and everything works ok. Please let me know if additional info from my side is required, in order to get the article finally published :) Miguel Hi, Miguel,
I'm glad I haven't broken your code. ;-)
Your updates for OCL 1.1 are excellent. Thanks for the positive attitude to the application of Java generics; much of the reaction so far has been shock followed by gradual acceptance. :-)
Other specific comments:
- the New and Noteworthy reference should be to OCL 1.1, not 1.0 in
the first section
- good exposition of the generic design of the Environment and
related APIs
- I really like the expanded discussion of the AST View and its usage
with the Ecore and UML editors. I'm using it myself, and it's a
superb debugging aid
- Figure 18 (R&L class model) doesn't show
- periods in bulleted lists sometimes appear on separate lines, esp.
near the top and bottom of the document
I reiterate my vote for this article!
Created attachment 65394 [details]
go OCL go
Christian,
I've corrected the typos you discovered (thanks). However, I'm puzzled by Figure 18, which *does* show up on my PC (tested with two browsers, both Windows-based, and the .png in question contains no transparency). Perhaps a final check about this could be made by Wayne, as part of publishing the article?
All in all, I would say: just publish it :)
Regards,
Miguel
I'm taking ownership for final review and publishing. Review is in progress. In the meantime, the article is available online. http://www.eclipse.org/articles/article.php?file=Article-HowToProcessOCLAbstractSyntaxTrees/index.html I'll add it to the articles page when the review is complete. Wayne, I realized why Figures 2 and 18 don't show. The .html mentions them with an uppercase extension (OCLMM.PNG and RandL.PNG) while the files themselves (in the images/myPNG folder) are named with a lowercase .png. On my Windows PC that was no problem. I'm checking in detail the rest of the article. Miguel Created attachment 65575 [details] no more broken links Two links in the Conclusion section were broken (they must have changed recently). I've updated them in the attached article.html, deleted another reference that is nowhere online anymore (the master thesis by Mitrik, a pity), as well as the lowercase/uppercase issue (.png vs .PNG) When clicking to download the plugin jar itself I get an Access Forbidden error, for the URL http://www.eclipse.org/articles/Article-HowToProcessOCLAbstractSyntaxTrees/install/ but I guess read, list permissions will be granted to that directory. Miguel > When clicking to download the plugin jar itself I get an Access Forbidden error, for the URL
> http://www.eclipse.org/articles/Article-HowToProcessOCLAbstractSyntaxTrees/install/
> but I guess read, list permissions will be granted to that directory.
Actually... no. We don't. I've replaced the directory link with a direct link to the file (in three places).
I believe I've rolled in your updates, along with a few other problems I found. I'm still in progress.
I've finally finished my review (sorry for the delay). The article has been published. http://www.eclipse.org/articles/article.php?file=Article-HowToProcessOCLAbstractSyntaxTrees/index.html Miguel, please email me your coordinates (mailing address and phone number) and I'll send you some nice swag in appreciation. Wayne, Yes, after two months waiting I was starting to get worried :) I'm never on the phone (is that bad? ;-) but the swag will be most welcome at: Miguel Garcia AB 4-02 Tech Univ Hamburg-Harburg Harburger Schlossstr. 20 21073 Hamburg GERMANY Regards, Miguel |