Use-Cases

Before you start modeling your application front-end you will want to think about how to split the application in different use-cases. Each use-case should define a unique set of processing logic operations that are specific to your application. Typical use-cases are: 'Login', 'Place order', 'Add new user'. No two use-cases should have the same name.

For the sake of simplicity our application will consist of only a single use-case. Adding other use-cases is very straightforward and should not present any problems.

Let's call our use-case Purchase Items. As you can see it is not a problem to have spaces in the name. We will put it in a suitable package, and label it with the <<FrontEndUseCase>> stereotype.

It is mandatory to inform the cartridge which use-cases will be considered to be the application's entry point, this use-case must be labeled with the <<FrontEndApplication>> stereotype. One and only one use-case must be labeled this way.

Nice to know

Use-cases split up the application in distinct parts, the generated code will reflect this by emitting files related to a specific use-case in a single package.

struts-config.xml

Per use-case the generated struts-config.xml will contain a global-forward, like this: 

<
global-forwards
>
    ...
    <
forward

        name=
"purchase.items"

        path=
"/PurchaseItems/PurchaseItems.do"

        redirect=
"false"
 /
>
    ...
<
/global-forwards
>

Next

The next step is to specify in detail how our application's presentation layer is going to behave, this is done by means of an activity graph