5.1 How to Model Procedures and Use Cases

Standard UML Use Case diagrams are not usually specific enough or tightly enough specified to generate pages directly, so we use a different technique to cover the same area. This is made up of page specifications, joined together by events and menus.

As well as standard pages and events, special variations of these called wizard pages and wizard events can be used to ensure that data is kept available from all pages throughout the wizard, and that back buttons are placed on pages so an application user can go back to the previous page. This sort of functionality can be modeled directly in pages and events if you choose.

In general, pages map to screens and optionally menu items. Events map to buttons. So to navigate the user has a choice of three ways:

1. Type in the URL
2. Select a Menu Item
3. Press a Button.

You have good control over the latter two and poor control over the former, so the start of a procedure should have an easy to find menu item and the subsequent ways of navigating the procedure should have buttons to take you through it. You don't want users to get in the habit of typing in the URL or even storing it as a favourite, apart from the home page of the application. Although storing other pages would probably work well enough if the link pointed to the beginning of a procedure, it might cause problems otherwise.

There is no reason not to have procedures linking into each other, in much the same way as use-cases do, and the same page can appear on different diagrams, if it all gets a bit too complicated.

The steps that occur when a basic page is used in J2EE at runtime are:

1. The page is created. This is an active process which may include security checks on what individual users are entitled to see.
2. The presentation layer server (http session) is checked to see whether information has been stored ready for the page. If so that information is loaded into the data items on the page as they are created.
3. The page is sent to the browser and is displayed.
4. The data may be edited by the user
5. The user may initiate an event by clicking on a button or a link
6. Typically, clicking on a button will send the data back to the server.
7. The server will process the data. What it does is very dependent on the style of the page and the style of the event initiated. It may validate the data. It may make calls on the service layer, which in turn may make calls on the database. It may prepare data for the next page.
8. If the modeler has provided a hook for the application programmer any code written by the application programmer will be run. This will allow the programmer to alter the data prepared for the next page or if there isn't any set some up, divert to a different page, and make calls to services.
9. The next page is called up.

If the page is entered from an event with a success forward action set, it may not display at all. It will process the action as an event on the page immediately. Similarly if the page has an entryEvent set, that will be processed or if it comes from a menu call and the menuEntryEvent is set on the page that will be processed. This way page pre-processing can be specified depending either on the particular event that lead to the page, all events that lead to the page or all menu calls that lead to the page.

1. Sometimes by generating a procedure and trying it out you will identify any problems and can go back to correct them, but this should not be your only technique. It's worth thinking about the requirements carefully. Modeling how people will use the application is key to its success.

• How to model a page
• How to validate page data
• How to model an event
• How to model a wizard
• How to model menus

Copyright © 2001-2006 New Technology / enterprise Ltd.