"Hospital" Demonstration Application

So what might a somewhat more complex application look like?  Back in the days of JeeWiz 3.0 and 3.5, this was the standard demonstration application. Originally written to show how a hospital survey might be modelled, it was enhanced to show many of the earlier JeeWiz! features. Note the use of explicit stereotyping, which you can still add if you want to and if you think it makes things clearer.

Input

Main entity class diagram	Page navigation diagram	Basic wizard diagram
Maintenance pattern diagram	Survey wizard diagram

Model

hospital.mdl    Rational Rose file

Output

hospital.zip    99.8% generated.

See It Running

Application running

Description

The 'Main entity' class diagram models the standing data for a survey of Hospital operations. The structure is similar to what we have seen in Ordering. The stereotypes for entities and relations are shown explicitly, although these would default if not specified. The maintenance screens that build from here are placed in slightly different menus than might be expected. This is because an extra meta-model level has been added on top of the standard stack, that just overrides how the menus are generated, tailoring them for this particular application. The configuration files point to the "hospital-demo" user interface model as the top level of the stack, rather than the standard demo. This effects the way the web pages interface are built.

The next diagram to look at is Page Navigation Example. This shows page flow. Each class stereotyped as a page generates a page, with whatever backing is necessary for the architecture. Directed associations between pages form events off the page, which usually render as buttons on the page they go from. On pressing the button the user will move to the page the association points to.

The Red Button and Blue Button show how two events can be linked to a single button, the decision where to navigate to being handled by code. The code that decides which way to go on the Blue Button event works against a boolean screen value. Fields for a page are modelled by "backing" the page with a data aggregation object, a dataview. If it is inconvenient to draw the dependency on the screen, there is a tag value on the JeeWiz page tab, which can be used instead (or in this case as well).

Now look at the Simple Wizard. This shows that data can be automatically kept between pages by styling them as wizard-pages. This will also give a "back" button on the pages, conferring the ability to backtrack. At the end of the wizard, the Save event links to programmer code, which takes information entered on all three pages and stores it in the database. It's worth noting the session object. This holds a single method, also linking to programmer code, which checks to see if the user name is duplicated. This and the password ("sesame") are entered on the first page of the wizard.

It's possible to model flow that incorporates standard maintenance page types. The Maintenance Pattern Illustration shows how the standard maintenance pages could be modelled if you wanted to model it from scratch. It's worth noting that the default generation has been switched off, a dataview has been modelled which links to the entity, a session object has been created which fronts the dataview, and pages have been modelled which call the session methods. This is just supposed to be an illustration of how the maintenance pages fit together. You never would need to model this directly, but some of the techniques for accessing standard functionality are used in the final class diagram, the Survey Wizard.

This collects the survey information on a page by page basis, first finding and selecting the hospital, recording the wards that were included in the survey, the number of operations of various types that were performed and finally stores the information in several database tables in a single transaction.