Hi Wouter and the others,
now, back from the openMDA 2003 conference in Cologne, I find that
AndroMDA continues to rock! :-) Thanks for the continuing development of
this cartridge. I'll comment on the list, as soon as possible.
About the validation: Since May this year, I am thinking about
decorators for the metamodel JMI classes generated by MDR. These
decorators can be generic as well as cartridge-specific and can include
model validation.
Example:
public abstract class ModelElementDecorator {
private UMLModelElement(?) decoratedElement;
...
public abstract void validate() throws ValidationException;
}
public class EntityDecorator
extends AndroMDAModelElementDecorator {
public void validate() throws...
{
AttributeDecoratorCollection myAttributes
= decoratedElement.getAttributes();
if (!myAttributes.containsStereotyped("PrimaryKey"))
throw ValidationException("Entity needs primary key.");
}
}
(This does not compile - just a sample to give you the idea!)
EntityDecorator decorates a UMLClass object that has the stereotype
<<Entity>>. A factory constructs the decorator automatically, based on
the stereotype. The cartridge descriptor declares the cartridge-specific
decorator classes and associates them with a stereotype. The key
difficulty is: When will dependent decorators be constructed? Example:
decorators for UMLAttributes should be constructed when an access to the
attributes collection of a UMLClass occurs. And: Decorators should
implement the same JMI interface as the metaclass. All methods in the
interface should delegate to the metaclass, except those that handle
collections.
This is very tedious and repetitive to code! (Hey, this is what code
generators are made for!)
Bold idea: Let us generate metamodel decorators from a UML model that
describes a UML profile! This would be done by an AndroMDA cartridge
that generates AndroMDA cartridges! :-)
More to come...
Matthias
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 19, 2003 10:41 AM
> To: [EMAIL PROTECTED]; "Matthias Bohlen"
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Andromda-devel] RE: Review of the new
> bpm4struts cartridge
>
>
> hello,
>
> just to give an update, considering the point from last week
> I have updated the code to reflect following changes (not yet in CVS)
>
> 1. using triggers and guards, not relying anymore simply on
> transition names
> 2. micro/macro scope of application flow: workflows can
> describe other workflow-flows (!) or directly the use-cases,
> this way you can model the dynamic part hierarchically and
> that's more scalable.
> 3. added verbose comments in the VTL
> 4. strutshelper is now delegating to the static/dynamic
> helpers instead of extending them
> 5. implementing a validator for the cartridge, it will check
> if you have correctly applied the model constraints (such as
> no duplicate names for use-cases, 1 initial state per graph
> etc...) before generating the code, it can give warnings and/or errors
>
> I will try to get something ready soon, another priority is
> to check-in a buildable release in CVS
>
> cheers
> Wouter.
>
> ps: Tony, concerning bullet item 5, I understand you did
> something similar in your work on the XSDs .. do you have
> interfaces for validation or something ? or nothing
> concretely yet ? it's interesting to have something generic
> to be used (optionally) by all cartridges
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Andromda-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/andromda-devel
