Bug 180744

Comment 1 Rafael Chaves 2007-04-04 15:51:41 EDT

Ideally, on the expanded form, there would be a way of telling apart things that were defined in the element itself from those coming from a template binding expansion.

Comment 2 Christian Damus 2013-10-25 20:35:21 EDT

I have pushed a new branch bugs/180744 with a proposed implementation of a TemplateExpander in commit fc30e59.

This TemplateExpander is analogous to, and indeed a subclass of, the PackageMerger.  It is likewise a nested class in the UMLUtil and is exposed primarily through a facade API UMLUtil::expand(TemplateableElement, ...).

A single template expansion option is implemented so far for reporting (or not) missing template parameter substitutions.  The package merge options are also all supported, with the exception of the capabilities annotation, because

  (a) the implementation (and specification) of template expansion is very
       like package merge, and
       
  (b) for packages with multiple template bindings, the expansion is actually
       specified (and implemented) as a merge of intermediate expansion results
       
The editor action that invokes template expansion exposes, so far, only the one TemplateExpander-specific option in the options dialog, not the PackageMerger options.  It doesn't seem (to me) useful to configure these at anything other than OPTION__REPORT because package merge, as such, is only actually used to combine the results of expansion of multiple template bindings on a single package.  It seems to me that in such cases, a lot of the metamodeling concerns of invalid subsets and association specializations etc. won't be interesting.  I could be wrong.

JUnit tests cover expansion of classifier and package templates with single and multiple bindings, and also substitution of parts of name-expressions to generate distinct names of things in multiple-binding scenarios.

The implementation follows the specification of template bindings in UML 2.5 Section 7.3 and related subsections in the specification of classifiers, packages, operations, etc.

The implementation *does not* handle:

  * nested templates:  where a element substituting for a template parameter
     is itself a template binding that needs to be recursively expanded
     
  * template inheritance:  where a classifier template specializes another
     template with a RedefinableTemplateSignature or a package template
     merges another package template
     
If these complex use cases should be addressed, I might suggest that additional follow-up enhancements be raised.

Comment 3 Kenn Hussey 2013-11-29 14:47:06 EST

Thanks, Christian. I've updated the branch based on the latest master and the code looks pretty good. Here is my feedback:

- I wonder whether it does in fact make sense to support "capabilities", as a means of addressing Rafael's request in comment #1. It seems to me that the constructs you're expanding into templateable elements really are "capabilities" in a sense (e.g., each template signature could be considered a "capability"); could you please reconsider exposing that as an option?

- For cases like BagListOfFooBars, should we consider generating warnings/markers to indicate that there's a potential conflict? Does the specification not provide guidance around (not) having multiple bindings to the same template?

- What about multiple bindings to different templates? Does your implementation handle, for example, properties/operations coming from different signatures where there is perhaps an overlap (the same/similar property/operation defined in both templates)?

Comment 4 Christian Damus 2013-12-02 09:54:29 EST

Thanks, Kenn!

(In reply to Kenn Hussey from comment #3)
> Thanks, Christian. I've updated the branch based on the latest master and
> the code looks pretty good. Here is my feedback:
> 
> - I wonder whether it does in fact make sense to support "capabilities", as
> a means of addressing Rafael's request in comment #1. It seems to me that
> the constructs you're expanding into templateable elements really are
> "capabilities" in a sense (e.g., each template signature could be considered
> a "capability"); could you please reconsider exposing that as an option?

Yes, that's a good point.  I'll do that.


> - For cases like BagListOfFooBars, should we consider generating
> warnings/markers to indicate that there's a potential conflict? Does the
> specification not provide guidance around (not) having multiple bindings to
> the same template?

The example in the test case is, unfortunately, rather contrived for edge cases.  However, the UML spec does specifically address the case of multiple bindings of the same template as a feature of the template metamodel's design.  Indeed, there are programming languages such as that encourage such template structures:  the Eiffel libraries have several instances of classes binding the same template multiple times, with explicit renaming to disambiguate features repeated by diamond inheritance.

So, I don't think that a warning is really in order here.  Where there are clashes, I think we should already (from the package merge implementation) have problems reported?  And there's post hoc validation to cover other issues.  I'll have another look to make sure we're covered.


> - What about multiple bindings to different templates? Does your
> implementation handle, for example, properties/operations coming from
> different signatures where there is perhaps an overlap (the same/similar
> property/operation defined in both templates)?

I think that should simply be a more general case of multiple bindings to the same template.  The UML's prescribed semantics for multiple bindings of a classifier is discrete general classifiers expanding each individual binding.  That puts name clashes on par with the usual inheritance conflicts, which model validation should be able to handle (if it doesn't, then that's a separate issues).  For package templates, merge similarly takes care of these issues (or should; again not our problem).  Unfortunately, the UML spec has nothing to say on the semantics of multiple bindings of operation templates and string-expression templates.

Comment 5 Christian Damus 2013-12-04 15:41:07 EST

I have pushed a new commit 19da415 to branch bugs/180744 that adds the traceability annotations for capabilities, with a refactoring of the PackageMerger's processing of the existing option.  This includes new JUnit tests.

Comment 6 Kenn Hussey 2013-12-04 18:04:48 EST

Thanks, Christian. I made a couple of minor formatting tweaks.

Could you please update the options dialog so that processing of capabilities is an option instead of being hardcoded to just report? You might also want to expose the option for handling redundant generalizations, since it's not strictly specific to package merge either (it's not even mentioned in the UML specification).

Comment 7 Christian Damus 2013-12-04 20:56:06 EST

I have pushed a new commit bb7f2b8 to complete the UI (missed a file the first time) and also to fix an issue with missing capability annotations in classifiers that bind multiple templates (or the same one multiple times), for which a new JUnit test case is added.

Good point about the redundant generalizations.  I hadn't realized that wasn't spec.

The formatting changes appear to be mostly insertion of blank lines.  I am using the UML2FormatterProfile from the wiki.  Is it out-of-date?  It seems there is often a need to reformat these bug branches ...

Comment 8 Kenn Hussey 2013-12-05 09:38:59 EST

(In reply to comment #7)
> I have pushed a new commit bb7f2b8 to complete the UI (missed a file the first
> time) and also to fix an issue with missing capability annotations in
> classifiers that bind multiple templates (or the same one multiple times), for
> which a new JUnit test case is added.

Thanks, looks great.

> The formatting changes appear to be mostly insertion of blank lines.  I am using
> the UML2FormatterProfile from the wiki.  Is it out-of-date?  It seems there is
> often a need to reformat these bug branches ...

Sorry, I have a habit of inserting blanks line when I'm reviewing code when it helps me to parse it. Unfortunately, I don't think there's a rule in the formatter that can be set to apply the same criteria.

The changes have been committed/pushed to the 'master' branch in git.

Comment 9 Christian Damus 2013-12-05 10:39:27 EST

There was one further problem with capabilities annotations for multiple template bindings in a package:  all traces were being collected in a single annotation without a source.  I have pushed commit 0f98966 to master to fix that, so that now there is an annotation for each template that properly identifies it by name.  JUnit test case included.

Comment 10 Kenn Hussey 2013-12-07 15:33:55 EST

An integration build containing the changes is now available.