[ http://jira.andromda.org/browse/UMLMETA-71?page=all ]
Cédric Vidal updated UMLMETA-71:
--------------------------------
Attachment: CollectionTypeResolver.java
> Association end getter setter declaration and implementation type resolving
> algorithm aware of templates, qualifiers and association classes
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: UMLMETA-71
> URL: http://jira.andromda.org/browse/UMLMETA-71
> Project: UML Metafacades
> Type: Improvement
> Versions: 3.0 RC2
> Reporter: Cédric Vidal
> Assignee: Wouter Zoons
> Attachments: AbstractTypeResolver.java, CollectionTypeResolver.java,
> EntityTypeResolver.java, MapTypeResolver.java, Name.java,
> QualifierTypeResolver.java, TypeResolver.java
>
> Today, the type resolving algorithm used in
> org.andromda.metafacades.uml14.AssociationEndFacadeLogicImpl#handleGetGetterSetterTypeName
> basically deals with cardinalities and ordering. That's fine since qualifiers
> and association classes weren't supported until recently (not yet actually
> for qualifiers), and their generation is not really complicated without
> templates, but when you need to deal with templates, qualifiers, association
> classes, cardinalities and ordering, you end up with too many combinations.
> Here follows a stack based algorithm that deals with all those cases.
> To illustrate this algorithm, here are a few simple examples that we need to
> deal with. First of all, if A is associated with many B with some qualifier
> attributes then, you need to generate a map whose keys' type is the qualifier
> Q and whose values' type is a collection of B: Map< Q, Collection<B> >.
> To achieve that, we need a resolving algorithm aware of the stacking of
> types. In our example, first you got a B, then a collection of B, then a Q
> then a map of Q to collection of B:
> Example 1:
> 1 - B
> 2 - java.util.Set<B>, uses the poped type in the stack
> 3 - Q, the qualifier doesn't use any poped type
> 4 - java.util.Map< Q, java.util.Set<B> >, uses two poped types, one for the
> key and the other one for the value
> Here is an other example, if you have B associated to many C using an
> association class A, you have the following stack:
> Example 2:
> 1 - C
> 2 - A
> 3 - java.util.Set<A>
> If you had simply B associated to many C, you would have the stack:
> Example 3:
> 1 - C
> 2 - java.util.Set<C>
> What's more, properties getterName and setterName also depend on that stack.
> Because, in our second example with the association class, the getterName
> would be "getAs" and not "getCs".
> Collections implementations also depend on that wiring, in our second
> example, the implementation type would be java.util.HashSet<A>. In example 1,
> it would be java.util.HashMap< Q, java.util.Set<B> >. The tricky thing about
> collections implementations, is that the implementation type depend on
> declaration types lower in the stack. So the actual resolving is cross cut
> between declaration and implementation types. So you have to stack
> declaration and implementation types together.
> To avoid running that algorithm for each property depending on it, the actual
> stacking must be done once, instead of stacking type names directly, you wire
> instances of TypeResolver whose interface is bellow:
> public interface TypeResolver {
> public String getImplementation();
> public String getDeclaration();
> public String getName();
> }
> You then have a custom TypeResolver for each situation that you wire together:
> - CollectionTypeResolver
> - MapTypeResolver
> - EntityTypeResolver
> - QualifierTypeResolver
> The wiring of TypeResolver is done in a method called getTypeResolver(). The
> TypeResolver is stored in the metafacade and calculated only the first time.
> Then a
> org.andromda.metafacades.uml14.AssociationEndFacadeLogicImpl#handleGetGetterSetterTypeName
> implementation might look like:
> protected String handleGetGetterSetterTypeName()
> TypeResolver resolver = this.getTypeResolver();
> String getterSetterTypeName = resolver.getDeclaration();
> return getterSetterTypeName;
> }
> You would do a similar implementation for each property depending on that
> wiring.
> Finally, the algorithm is compatible with andromda's metafacades
> specialization, in that case you simply override the getTypeResolver() method
> in metafacades subclasses. If additional properties are necessary in the
> specialized metafacades and depend on that wiring, they those metafacades can
> subclass each TypeResolver and use them in the getTypeResolver() method
> instead of the default ones.
> public interface CustomizedTypeResolver extends TypeResolver {
> public String getAdditionalProperty();
> }
> public CustomizedMapTypeResolver extends MapTypeResolver implements
> CustomizedTypeResolver {
> public String getAdditionalProperty() {
> // ...
> }
> }
> You'll find attached the files involved in that algorithm, I haven't supplied
> them as a patch since first of all, it won't work out of the box as some
> andromda cartridges might need to be modified in order to take advantage of
> that feature and secondly, the implementation depend on too many choices that
> I'm not 100% sure about:
> - in example 2, generate a java.util.Set<A> instead of java.util.Set<C>,
> that's the way I see it, do you agree ? That behavior might be specified in a
> namespace property though
> - regarding qualifiers, the way to support them in andromda is not yet known
> for sure and that algorithm depend on it, of course we could just ignore them
> in the mean time.
> I have used that algorithm successfully in a customized cartridge (the output
> is really nice) and I think that this algorithm would be best located in the
> core metafacades uml1, uml2 and emf-uml so as to be leveraged in all
> cartridges.
> Hoping that it will be usefull as is or be a source of inspiration for you
> guys in the final implementation.
> Regards,
> Cédric Vidal
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.andromda.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
