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
Assigned to: Wouter Zoons
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
