[Andromda-devel] Elaborate sample model for the new struts cartridge

[Matthias Bohlen]

Title: Nachricht

Hi Wouter, hi Tony and the others,

 

Wouter, thanks for your new struts cartridge for AndroMDA 3.0. As a first hit, it was already quite good but I thought, you could improve it a lot by taking a much more rigid and systematic approach, leveraging UML transitions with their names, triggers, guards and effects.

 

See my old email message below and compare it to the sample Poseidon model (attached to this message) where I have used all the concepts described below. Wouter, this should be the answer to almost all of your questions that you posted during the last few days. If your cartridge is able to generate code from my model, you're done! :-)

 

I am well aware that this will cause quite a bit of refactoring on your side (sorry for this!) but will improve the cartridge greatly. You should already have most of the necessary building blocks in hand.

 

Feel free to get back with questions! And: keep up the good work, I am fascinated using the dynamic part of a UML model (like Tony is).

 

Cheers...

Matthias

 

P.S.: Do you think the cartridge might be usable by September 12? If so, I could already use it in my tutorial that I give in Cologne on Sept. 15 (see http://www.openmda.de ). 

-----Original Message-----
From: Matthias Bohlen [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 03, 2003 6:44 AM
To: 'Wouter Zoons'; 'Anthony Mowers'
Cc: '[EMAIL PROTECTED]'
Subject: RE: [Andromda-user] accessing Activity Diagrams

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 = " failure ";
   }
   // 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. ... 

carrental-one-usecase.zargo
Description: Binary data