hello everybody Matthias, I have taken a look at your (very well documented) UML model. It is indeed more comprehensive and seems to take more UML features into account. But some questions remain:
1. You seem to have use State diagrams rather than Activity diagrams, why is that ? personally I feel more comfortable with activity diagrams since they tend to be less technical and more business oriented than state diagrams (my feeling). For example, I prefer a Pseudostate of kind 'choice' over a transition with a guard. Can you shed some light ? Is there something you can do (or ought to do) with state diagrams that cannot be done in activity diagrams ? 2. in your model it is possible to have many presentation classes (Forms) associated with a controller class (Action), this sounds fine to me. However, in Struts you have only one Form per Action declaration in struts-config.xml. The same goes for DispatchActions of course (such as in my sample). I modeled each use case with a single DispatchAction (the ControllerClass), in order not to have any conflicts with your requirement I will have to repeat the same <action-mapping> for each associated form (of course, with a different 'name' attribute value), is this desired ? Personally I would not mind reusing the same form for all action states in a use-case. The UML model would show different classes, but the actual generated code would merge all of their properties. Do you have any objections ? 3. I want my output filenames to be a function of the names as they appear in the model elements, how can I do this without touching the kernel ? (I am now overriding getName() and getPackageName() in UMLStaticHelper) that's it for now... cheers Wouter. "Matthias Bohlen" <[EMAIL PROTECTED]> wrote: >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. ... > > > -- ----------------------------- http://jeteam.sourceforge.net ----------------------------- __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 ------------------------------------------------------- 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
