Page flows using UML

[dainty]

Does any UML diagram lend itself for representing navigation through the system and the messages for different conditions that are either triggered by the user or some busienss rules or errors?
In raw terms, can we use any of the UML diagrams to show which screen comes up when and with what appropriate message?
-Dainty

[KP]

Have a look at the User Interface toolbox and specifically the Screen and GUI Element items. You would probably want to put these on a Custom diagram.

[sargasso]

I note you use the term "page flows" in your header, then refer to "screen" in your text.

If you are talking about a http based application (aka "web app") then have a look in these forums and also generally on the internet for "modelling web applications using UML"  or the like.

I suggest you spend significant time exporing how this can be done and decide on a modelling profile suitable for your situation. Models of these types can become very confusing if you dont select a specific mechanism and stick to it rigidly!

bruce

[Paolo F Cantoni]

I suggest you spend significant time exploring how this can be done and decide on a modelling profile suitable for your situation. Models of these types can become very confusing if you don't select a specific mechanism and stick to it rigidly!
bruce

Echoing bruce's comments about sticking to it rigidly...  If you are consistent, you can evolve consistently.  That is to say, if you are disciplined in your approach and you find you are "consistently wrong" at a later stage, you can write some automation to evolve the model from your old understanding to your new one.  It's better to be consistently wrong than inconsistently wrong!

HTH,
Paolo

[dainty]

Thanks all for the responses!
I agree that being consistent is really important and that is why I am trying to come up with one standard way (which might not be a best practice for the industry!) for my organization which could be used without much changes for any future applications we build and not just for today.

We have a large no. of conditions that can change the options we provide to the customer , which are identified well enough in the use cases but definitely not how they menifest themselves into the navigation and the exact message to the customer. This is for a self-service kiosk application.

One of the ways we tried to do this is to use page flows and call the msg no. on the respective condition paths reaching a certain page. I was hoping to get some tips from the experts who might have encountered a similar issue.

Thanks!
Dainty

[thomaskilian]

I use robustness diagrams for that purpose. That gives a good overview how the "pages" are connected to each other.

[jeshaw2]

Have you considered Statecharts for this?  

Each state could be defined as a composite having a submachine representing the design of a window display with a particular configuration of widgets.

A .png image could then be used as the alternate image of the submachine.  Thus, the submachine would look like the window display.  User initiated events could then cause a transition to a new composite state with a component screen image only a click away.

The window image could easily be created using VB Forms and a screen capture saved in .png format.

Easy Peasy!

Jim

[sargasso]

A few 20c worth...

(I am using an activity diagram profile for this modelling - judging by the above comments there are n choices of particular style).

My need:
The application is a n (4) tier architecture, delivered to the end user as html pages.  My task is to specify the UAT.  My goal is to be able to specify the navigations through the various transactions supported by the application, producing a model that allows us to identify the significant end-points, exceptions and error conditions that need to be tested (and from that develop the test cases...)

It seems to me (   ) that

1) You can model the flows from either the system perspective or the user perspective.  In the former, the activities are what the system does, in the latter the activities are what the user does.  mixing the two has been a disaster for us - no-one can gell how we are looking at the System.
2) It is easier to build the initial model from the user activity pov (IMHO - YMMV).  I.e. the page in the browser is considered a black box (actually a control flow) that "just does stuff that results in a new page being displayed in the browser (or a popup, or a child page, or a dialog box, or an inline error message etc etc).  We model the various  user efforts (including generating invalid POST parameters etc etc) as an activity stereotyped as a <<useraction>>.  When the flow is complete, we can with some effort derive each of the possible nav flows through the transaction and set them up as test cases.
3)  What I have found that is easier, tho, is to transform the nodes and edges in the graph into a model of  the flows form the system pov.  The innards of these activities are not described in any meaningful way - but do become the repository of the "business rules" that apply at each .do invocation.  The test cases that emerge from this are simpler to detect and describe.

bruce

(p.s.  the profile and transforms represent a significant investment by my client, and so are not "available" I'm afraid.)

p.p.s.  Now I remember why I was going to write this.  We originally tried to build structural models of the system, i.e. modelling "pages" with "links".  This soon proved to be impossible and useless.  For example, the inital screen of the most often used transaction (no its not Log In!) has 12 action buttons (form submits), 5 local (jscript) actions, ~20-30 Menu actions (activated/inactivated by transaction state), 9 input ("non-hidden" POST param items) and up to 29 optional input "radio buttons" (selected from up to 9*9 sets, in 4 subsets, which are mutually exclusive - all handled by local validation thankfully).  What the heck is it?  Its a rail travel reservation sales system.  Obviously trying to model all these, or even the "signiificant" ones in a structural model would have been more difficault than building the damn thing in the first place.  Luckily, we fell back on modelling "what the System does" rather than "how it looks" very early.

[jeshaw2]

Sage advice Sargasso!  I had similar thoughts, but I, unfortunately, elected to stay directed at his specific question.  The web development team I used to manage was divided into three teams. Two of these represented the two major approaches: the scripting team and the OO programming team.  However, the third team supported the first two by taking on all the issues of the cognitive design (the way the UI looked and the way one navigated through it).  The first two teams used UML, the cognitive team used storyboarding instead.

[kcmason]

Use an activity diagram; reference the the screens and business rules in the actual activities.  Then draw the basic screens in the UI section.