"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

Output

See It 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.