Flux - The Smart Struts Config Generator
Flux supports the model-driven design of a Struts web application. So using Flux naturally requires you to model your application before (and while) you code it.
For each Struts module of your web application you iteratively create, update and maintain a UML state/activity model that comprises one or more activity diagrams. These diagrams depict the page and control flow of your application from which Flux can generate the struts-config-<module>.xml (Struts 1.1) files.
The following sections describe the elements of those diagrams, how they must be organized and what they mean to Flux when it translates them to Struts.
Model each page of your web application as a uniquely named UML state. Always refine the meaning of these states with the stereotype <<Page>>.
As an optional feature you can subsume a set of closely related logical pages into one logical page by attributing the one subsumed logical page with a reference to a page mode variable. This may come in handy if the set of pages need not really be distinguished for workflow but only for presentation logic reasons.Recommended:
Although not strictly required by Flux, you are recommended to abide by the following naming conventions for page states:
Page state names ...
Model each Struts action mapping of your web application as a uniquely named UML activity. Always refine the meaning of these activities with the stereotype <<Action>>.
Recommended:
Although not strictly required by Flux, you are recommended to abide by the following naming conventions for action activities:
Action activity names ...
If the Struts module you are modelling forwards into other modules model each module referenced as a uniquely named UML activity. Always refine the meaning of these activities with the stereotype <<Module>>.
Except for the case and an optional '.<something>' extension module activity names must be the names of the Struts modules.
Each module activity must incorporate a single inner do-action. The action expression of the do-action must be 'Page.<Name>.display' or 'Action.<Name>' where <Name> is to be substituted by the name part of the action mapping path to be addressed on entering the referenced module.
Recommended:
Although not strictly required by Flux, you are recommended to abide by the following naming conventions for module activities:
Module activity names ...
If the Struts module you are modelling may reach a final state where standard finalization processing is required (e. g. in order to return to another module that previously forwarded into this module) model the final state with the UML final state.
Each module may only have at most one final state.
If you want to use an enumeration variable to abstract several closely related logical pages into a single logical page with a mode variable create a UML class with stereotype 'Variable' and name '<Name of variable>'.
For each value the variable can have add one attribute to the class with name '<Name of value>'.Recommended:
Although not strictly required by Flux, you are recommended to abide by the following naming conventions for variable classes:
Variable names ...
Variable value names ...
Page states, final states, action activities and module activities have to be interconnected by transitions. A transition defines the control flow from a page to any node, from an action to any node or from a module to any node (where a node can be a page, a final state, an action or a module). Transitions are always labelled with an event name or with a guard condition but never with both. Unlabelled transitions are disallowed. Event names may only label transitions emerging from a page state. Guard conditions may only label transitions emerging from actions or modules.
As an optional feature you can set the value of a page mode variable on firing a transition. To do so add the expression '<Name of variable>=<Name of variable value>' as transition action to the transition. Of course, the variable must be defined and the value must be one of the defined values of it.Recommended:
Although not strictly required by Flux, you are recommended to abide by the following naming conventions for event names and guard conditions:
Event names ...
Guard conditions ...
For each action event the user can generate by clicking a request submitting element on the page being displayed in the browser there must be a transition pointing from the page to the action to be executed. This transition must be labelled with the event name (and not with a guard condition).
If a page event directly triggers the display of another page the transition points from the page state to the target page state. This transition must be labelled with the event name (and not with a guard condition).
If a page event directly triggers an action in another module the transition points from the page state to the module activity. This transition must be labelled with the event name (and not with a guard condition).
If a page event directly triggers the finalization of the current module the transition points from the page state to the final state. This transition must be labelled with the event name (and not with a guard condition). The event becomes the result code of the module.
The execution of an action must always unambiguously end with exactly one out of n possible guard conditions. If a page is to be displayed on the satisfaction of a certain guard condition a transition labelled with the condition points from the action to the page.
If another action is to be executed on the satisfaction of a certain guard condition a transition labelled with the condition points from the action to the next action.
If another action in another module is to be executed on the satisfaction of a certain guard condition a transition labelled with the condition points from the action to the module activity that incorporates the inner action to be executed next.
If the module finalization is to be executed on the satisfaction of a certain guard condition a transition labelled with the condition points from the action to the final state. The guard condition becomes the result code of the module.
If the module called returns because it reached a final state, a transition may point from the exiting module to the action to be executed next. Each such transition must be labelled with one out of the n possible exit guard conditions the returning module can end with.
If the module called returns because it reached a final state, a transition may point from the exiting module to the page to be displayed next. Each such transition must be labelled with one out of the n possible exit guard conditions the returning module can end with.
If the module called returns because it reached a final state, a transition may point from the exiting module to the module to be entered next. Each such transition must be labelled with one out of the n possible exit guard conditions the returning module can end with.
If the module called returns because it itself reached its final state, a transition may point from the exiting module to the final state of the module it returns to. Each such transition must be labelled with one out of the n possible exit guard conditions the returning module can end with. The guard condition also becomes the result code of the enclosing module.
The following concepts should not be expressed in the UML model processed by Flux: