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.

howto/org/andromda/test/use-cases.gif

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