RE: [Andromda-devel] accessing Activity Diagrams, ao

[Matthias Bohlen]

Title: Nachricht

Hi Wouter,

 

please expect SimpleOOHelper and proxies to continue to exist for some time. I won't have the time to refactor them away before September (approx.).

 

And: do not try to find diagrams in the model - they don't exist. Only the graph of model elements exists - diagrams are only views into this graph.

 

Tag the actions, states and controller classes (see below) with stereotypes of your choice. Then, AndroMDA will call your cartridge automatically in the processModelElement() method - you can access them in your templateas as "$class" (misleading name!) .

 

And: yes, write a new script helper class and configure it in your cartridge descriptor.

 

In a future version, maybe we'll have metamodel decorators that will take over the methods of your script helper.

 

Cheers...

Matthias

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wouter Zoons
Sent: Saturday, August 09, 2003 4:31 PM
To: Matthias Bohlen
Cc: 'Anthony Mowers'; [EMAIL PROTECTED]
Subject: [Andromda-devel] accessing Activity Diagrams, ao

hi all,

I am having troubles writing the required code in order to have access to the activity diagrams in which to model the application flow, the VTL scripting should be no problem... the Java part seems trickier

the thing is that I am a little confused on how to proceed, I see some comments saying the SimpleOOHelper will be deprecated at some time, also I notice there are some dynamic proxies that bridge the gap between UML2EJB and AndroMDA (uml1.4) compatibility...

suppose I want to add new functionality such as this:

• getting a list of all activity diagrams from the UML model
• getting all action/pseudo states for such a activity diagram model

where would I add the code ? do I write a new Helper class, or add methods to an existing one ?

it's just that there are too much possibilities to explore, could somebody put me on track ?

thanks in advance


cheers
Wouter.


Matthias Bohlen wrote:

Hi Wouter, Tony, and the others,

 

here a little info on this subject:

 

I was on the JAX2003 conference (JAX = Java, Apache, XML) in Frankfurt, it was in May this year. There, Martin Schepe and Wolfgang Neuhaus showed how to generate a complete struts-based web application from activity graphs (remember: MDA is about models, not about diagrams!) and supporting class diagrams.

 

Their idea was to design the app at two distinct levels of complexity:

 

1. Describe the overall workflow of the application as a graph of use cases:

1.a) Use an activity diagram to show how the use cases are interconnected.

1.b) Model each use case as an activity.

1.c) Associate each activity with a controller class. Do this by attaching a tagged value "ControllerClass=com.acme.SomeController" to the activity.

1.d) Model the controller class in a separate class diagram. Give it some methods, each returning a boolean, to serve as branching criteria for the state diagrams (see below).

1.e) Associate each controller class with one or more presentation classes. Model these in the same class diagram as the controller class and draw an association from the controller class to each presentation class associated with it. Give the presentation classes attributes for each element that they show on the presentation layer.

 

2. Describe the fine grain state handling for each coarse grain activity in a separate state diagram:

2.a) Define a number of discrete states that the controller may be in. Draw a state symbol for each such state.

2.b) Define the transitions between such states as invocations of the boolean methods of the controller class.

 

Finally:

 

3. Define mappings from the abstractions I mentioned above to technology-specific items:

3.a) each controller class maps to a Struts action (boolean methods in the controller class map to boolean methods in the action class, of course)

3.b) each presentation class maps to a Struts form, its attributes map to HTML input fields, its methods map to HTML buttons

3.c) each controller state "stateX" maps to

3.c.a) a string value associated with each request and each response ("stateX", the name of the state, is simply returned to the client with each response; the client sends the current state name with each request)

3.c.b) a generated method in the controller class "String performStateX()" that returns the name of the Struts ActionForward. It invokes the hand-written boolean methods to evaluate the criteria for transitions into other states

3.c.c) a call to the "perform..." methods inside the body of the controller (Action) class.

 

The code looks like this:

 

public final class SomeActivityController extends Action {

 

public ActionForward perform(ActionMapping mapping, ActionForm form, ...) throws ... {
   String controllerstate = request.getParameter("ControllerState");
   String forward = null;
   if(controllerstate.equals("stateX")) {
      forward= performStateX();
   }
   return mapping.findForward(forward);
   }

 

public String performStateX() throws ... {
   String forward = null;
   if (booleanMethod()) {  // only this method is hand-written!
      forward = "Ok";
   } else {
      forward = "Fehler";
   }
   // more code if more state transitions are in the model
   return forward;
}

 

And: that's it! They were able to generate all of the "plumbing" code and hand-coded only the methods on the controller classes. In the model, the labels on the state transitions were used to generate calls to those controller methods.

 

Maybe, you can use these ideas as a strating point for the design of your new Struts cartridge.

 

Cheers...

Matthias

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Wouter Zoons
Sent: Saturday, August 02, 2003 11:49 PM
To: Anthony Mowers
Cc: [EMAIL PROTECTED]
Subject: Re: [Andromda-user] accessing Activity Diagrams

hi Tony,

thanks for the quick reply, I'm gonna take a look at these links right away...

I had some ideas on how I would generate the Struts code for my pages, it might be interesting to get some feedback on it from this mailing list. I know you have been playing around with this yourself (or so Matthias once said) so feel free to correct me wherever you think it's needed, since I did not write an implementation yet I am probably overlooking some issues. ...