RSI - A Structured Approach Use Cases and HCI Design

The RSI Approach To HCI Design / Use Case Analysis Page 38 of 42
5. Onwards to development
A full understanding of the RSI approach (and the benefits of the structural decomposition
RSI gives) requires a brief discussion of the development process which follows RSI.
5.1. Use case realisation
Both interface and service use cases provide a good starting point for software design.
Interface use cases will generally be initiated on the application menu, and are generally
realised as specialisations of GUI classes (e.g. the customer and reservation management
dialog may be implemented as a subclass of a GUI class library's dialog box class). Such
classes are akin to Jacobson's boundary classes [1].
Service use cases are realised as classes or methods on classes on the façade of the
components (as in component based development) that make up the system. For example
'make reservation' may well form a method on the façade of a reservation component
interface. In a transaction oriented database system, 'make reservation' may well end up of a
sub-class of a use case class that encapsulates the (database) transaction begin and commit
commands. In general, service use case provide a good starting point for a component based
decomposition of a system.
From an architectural perspective, RSI typically leads to the following application structure:
::problem domain
5.2. Interface sequence diagrams
Customer component
W5a - RSI LONG PAPER [42 PAGES].doc( Rev: 5) - 03/09/00
::interface component
CreateCustomerTransaction
ReservationDialog
CreateCustomerDialog
Dependency Dependency
::Infrastructure components
Reservation component
CreateReservationTransaction
Dependency Dependency
Interface
realisations
Service
realisations