Hi Wouter, thanks for this long response to my long email. :-) Sorry for the long delay (10 days) but the openMDA conference took my whole attention these days.
It is a little difficult for the reader to follow here because of the limitations of ASCII formatting, but I'll try to do my best, see below. Cheers Matthias > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 11, 2003 9:32 PM > To: "Matthias Bohlen" > Cc: [EMAIL PROTECTED] > Subject: RE: Review of the new bpm4struts cartridge > > > Hi Matthias, and others, > > thanks a lot for your response, I have put comments to some of the > issues you point out. A lengthy email asks for a lengthy reply ;-) > > First of all, it seems a small bug sneaked its way in my new > templates, some of the java code is not property generated, > it concerns the parts where you go from an ActionState to an > ObjectFlowState, my bad..I should have double-checked. It's > small thing tough. I did not notice that - at the moment, the code is a little too magic for me! :-) ObjectFlowStates, well, I have some problems with them. In the UML model, they are good as a general documentation of what happens to an object inside an activity. However, for code generation, they go against my intuition - their semantics is fuzzy and it seems as if we force a certain kind of artificially precise semantics into them. I think, we can do without them, entirely. Do you agree? > There are several points in your email that I'm immediately > going to take into account, but for the others I would like > to make sure you fully understand what the cartridge is doing. > > For the impatient: > - gone with the tagged-values in the final states > + use-case interconnectivity problem solved by Matthias > + switching to guards and triggers OK, thanks. It is good that we agree on this. Now, I'll continue to comment only where we disagree... :-) > - methods in presentation classes ? > - JSPs generated from presentation classes ? I'll comment these two in detail below. > ... snip ... > > * The mapping to action implementations is complicated. An > action gets > > filled up with a lot of tiny functions, each one named after an > > activity name. > > Just to make sure, let me explain how it works, because IMO > these 'tiny functions' are unavoidable since the represent a > distinct part of the business process. ............... snip ................ > For each ActionState you have a method in only the parent > class, since the > class extends from 'DispatchAction' this method can behave like the > 'execute(...)' method in 'Action' (also configured in > struts-config.xml) > Note: Each 'tiny' function is in fact an Action.execute() OK, got that. I did understand that several states are now processed by the same controller class (one thing where the bpm cartridge differs from the old struts cartridge!) but I did not realize that this is the price I have to pay for it. ;-) ............... snip ................ > This method will be called from a specific JSP page, > depending on the > value of the 'transition' request parameter (in case there > is more than one) > this method will delegate the call to another, see below > > I think these methods belong in the controller class, not > in the presentation > class, do you agree ? Yes, sure, the methods belong in the controller class, I agree. However, the events that cause the methods to be called should NOT be generated from the transitions between action states. Instead, the presentation class fires those events, independently of how it is used in an activity graph. This is separation of concerns: the presentation class fires the event, the activity controller catches it and takes the proper transition. Thus, the same presentation class can be used in several contexts (activity graphs). This is why I introduced the methods in the presentation classes. They represent the events that can be fired by the presentation class (here: the buttons in the JSP page). > This is the code for: enter-user-name-and-details.jsp > > =START > CODE=========================================================== > > <html:form > action="/CreateUserController?target=enterUserNameAndDetails"> > <html:submit property="transition" value="CANCEL"/> > <html:submit property="transition" value="OK"/> > </html:form> > > =END > CODE============================================================== > > This is the code for: CreateUserControllerAbstract.java ............... snip ................ > > this means that having selected 'OK' on that specific page, > will call this > action method with the transition field set to 'OK', it > will then delegate > to the following method (also in this DispatchAction), see below > ............... snip ................ OK, so the transition property should be generated from the methods in the presentation class. The rest works fine, then. > The implementation is done in the concrete child class, in this case > named 'CreateUserController' > > So you only write what it means to create a new User instance. > This is the minimum, the rest is taken care of by the > abstract parent > class that the user does never need to touch. Good! > The method 'setUserCreated' has been generated from an > ObjectFlowState > which has an incoming transition from the ActionState we just talked > about. Mmmmm... these object flow states ... can we do without them? > The forward 'user-succesfully-created' denotes a > FinalState, typically > the associated JSP will auto-forward to the next use-case. One can > argue: why not skip this JSP page and forward to the next use-case > immediately, my response: "It is better to decouple a > little more for > the sake of consistency and code maintainability/readability than to > tightly couple use-cases in the hope for some magic > performance increase > (if that would be the motivation)." Furthermore, it might be desired > to actually use that JSP page for some purpose. This is too complicated for me. Again, a JSP should correspond to a presentation class, not to a state in the actrivity graph. A JSP contains input fields. These input fields correspond to the attributes in the presentation class. > > * The cartridge's UML profile is somewhat > counter-intuitive. The user > > would not expect a JSP page to be created from a final state of an > > activity diagram. She would rather expect it to be generated from a > > presentation class. > > I thought is was intuitive to generate a JSP from an action > state :-) > > In struts you use JSP/forms to get the data to the actions, this > translates into a JSP file and an action method per 'action state' > > I like to think of the presentation classes to have little as > possible logic, more like value objects. Well, for form classes, I agree with you. For JSPs, I don't. Maybe, it is not appropriate to model the same for the JSP and the form. We should introduce two classes: one <<PresentationView>> class for the JSP, one <<PresentationData>> class for the form. Several <<PresentationView>> classes could interact with the same <<PresentationData>> class - for example, if the number of input attributes is too large for one screen. However, in most cases, the attributes of the <<PresentationView>> class will correspond one-to-one to those of the <<PresentationData>> class. In that typical case, the modeler should draw a dependency from the <<PresentationView>> to the <<PresentationData>> class. This dependency could be tagged with a stereotype, indicating that the attributes will be copied. As an idea, we could use <<CopiesAttributes>> (if you have a better name, please suggest it!). > I think I have a feeling about how you were thinking this cartridge > would work. I did it in a totally different way ;-) Yes, but I think, we're approaching each other, aren't we? ............... very long snip ................ > > * I have modeled methods in the controller classes. These methods > > serve as guard conditions for the transitions. They should be > > implemented in the ActionImpl classes. > > This is what I always wanted to avoid, explicitely writing > Java code > in the model. But I see your point, I guess it is more in line with > the conventional way of doing UML. > > But what if you want to use a non-java language ? You will need > extra logic to translate the syntax in the UMLClasses to > your specific > language of choice Yes, but fortunately, a single boolean method call (e.g. "isFoo()") looks very much the same in most 3GL languages. :-) I agree, this is only an excuse for the fact that there is no such thing as language independent action syntax. But, I think it is the best thing that we can do at the moment. ............... snip ................ > > * I have put methods into the presentation classes. These serve as > > triggers for the transitions. They also generate buttons > for the JSP > > pages. The action classes should branch on the current state and on > > these triggers. The user should only have to implement the > guards, the > > state transition table per action can be 100% generated. > > (*) The presentation class's method can be generated from > the guard's > and trigger's names, why the need to write them again in > the UMLClass ? I have explained that above. > > * I have defined a stereotype FrontEndSelectionBox. This > can mark an > > attribute of a FrontEndPresentation class to be able to generate a > > select control on the web page. > > Okay, but make it 'FrontEndSelection' (truncate the 'Box') > as some front-ends might prefer a list instead of a combobox. Agreed. No problem. > Now we're on the subject, the company that I work for (Thales) is > highly involved in MDA as they work together with OMG. Recently I > have had a lot of talks and one of the things that came up was that > it seems that in other MDA frameworks they use UMLProfiles instead > of stereotypes to tag aspects to model elements, any ideas > on this ? This sounds like "they use fruit instead of apples." :-) A UML profile is a UML model that describes a set of stereotypes and tagged values. Sterotypes are drawn as classes that extend a UML metaclass. For example: FinderMethod would be drawn as a class that extends UMLOperation. Stereotype classes can have attributes. These attributes become the tagged values of that class that will be tagged by the stereotype. For example, the FinderMethod class could have an attribute called "@andromda.ejb.query: String". You get the point? Using UML profiles, you get a very good documentation of the modeling rules. UML profiles teach you how to use stereotypes and tagged values correctly. So, there is no alternative between UML profiles and stereotypes just as there is no alternative between fruit and apples. :-) > > Could you have a look at all this and try to change your > cartridge so > > that it generates code from this model? Afterwards, we should merge > > the JSP code generation template from the old struts cartridge into > > the new bpm4struts cartridge, together with the > FormFieldMapper class > > from the old cartridge, too. This will allow simple > boilerplate JSPs > > to be generated from the model. The user can then modify these > > boilerplate JSPs to make them multilingual and make them look > > appealing. > > > Changing the cartridge to comply with these constraints > will be a lot of > work, I am willing to do so, but can you reply to my > comments first ? I did in this email. Did I go into sufficient detail? ... snip ... > > I think, all this is very exciting. In the end, we'll get a > real good > > cartridge, I'm pretty sure! > > Sure we will ;-)) !! > > > Thanks, Wouter for donating your time... > > Matthias > > no prob > > best regards > > Wouter. > Keep up the good work - I am eagerly awaiting your changes in CVS! Cheers, Matthias ------------------------------------------------------- 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
