05.12.2012 Views

RSI - A Structured Approach Use Cases and HCI Design

RSI - A Structured Approach Use Cases and HCI Design

RSI - A Structured Approach Use Cases and HCI Design

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

The <strong>RSI</strong> <strong>Approach</strong> To <strong>HCI</strong> <strong>Design</strong> / <strong>Use</strong> Case Analysis Page 32 of 42<br />

firstName<br />

surname<br />

address1<br />

address2<br />

address3<br />

::Customer<br />

* customers 1<br />

::Account<br />

* items<br />

::AccountItem<br />

value<br />

description<br />

date<br />

1 account<br />

1 reservedby<br />

* reservations<br />

::Reservation<br />

start-date<br />

end-date<br />

checked-in<br />

W5a - <strong>RSI</strong> LONG PAPER [42 PAGES].doc( Rev: 5) - 03/09/00<br />

1<br />

1<br />

<br />

::Room<br />

1<br />

reserved * rooms<br />

*<br />

reservations<br />

*1<br />

1<br />

::Hotel smoking-rule<br />

reservations<br />

Invariant:<br />

The is no overlap in Reservation dates for all the<br />

Reservations associated with any particular<br />

Customer<br />

values:<br />

smoking,non-smoking<br />

invarant:<br />

start-date < end-date<br />

Invariant:<br />

Room reservations<br />

do not overlap.<br />

Invariant:<br />

All Reservations must have an<br />

associated<br />

Customer in Hotel.customers.<br />

All Reservations must have an<br />

associated<br />

Room in Hotel.rooms.<br />

The model shown contains a number of invariants (business rules) which must be adhered to<br />

at all times (e.g. "Room reservations do not overlap"). Using invariants reduces the<br />

complexity <strong>and</strong> removes redundancy in pre- <strong>and</strong> post-condition descriptions (which are,<br />

conceptually at least, implicitly '<strong>and</strong>'-ed with them at the beginning <strong>and</strong> end of each use case).<br />

Note that the core specification model must contain at least one 'anchor point' (Hotel in this<br />

example). Pre- <strong>and</strong> post-conditions are always described in a manner that is relative to some<br />

known point within the model (e.g. a post-condition stating that 'aCustomer.reservations is<br />

empty' is relative to aCustomer). Without a well known anchor point, it would not be possible<br />

to find a way into the model!<br />

Two example service use case specifications are shown below. A full description of the<br />

service use case model for this system can be found in the companion document to this paper<br />

on www.ratio.co.uk/rsi-info.htm.<br />

in:- [what information is passed from the actor to the system]<br />

start-date, end-date, aRoom, aCustomer;<br />

out:- [what information does the system pass back to the actor]<br />

status [shorth<strong>and</strong> for ok/fail]<br />

pre:-conditions:- [what must be true before this service can be invoked]<br />

start-date

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!