Java Reference
In-Depth Information
These are steps almost every application takes in order to save a file. But most applica-
tions require only one item of input from the user to initiate these actions: selecting the Save
option from the File menu.
Imagine if an application required the user to select a Validate File menu item, followed
by a Calculate File Size option, followed by a Check Hard Drive Space option; to then enter the
calculated file size obtained from the previous step; and finally, after confirming that there is
enough hard drive space, to select a Write File to File System option. This application would
make saving a document more trouble than it is worth.
The previous example is extreme, but it still demonstrates the notion of abstracting the
operations of the system away from the user as much as possible. The system should be able
to complete many of the tasks listed previously without any input from the user. The only time
the user needs to be notified of the system's activities is if an error should occur. For instance,
if there is not enough space on the file system to save the file, the user should be prompted
and notified that the system can no longer complete this step on its own. Beyond these cir-
cumstances, the user should be allowed to simply select Save and have the system abstract
away all necessary substeps.
This is one of the primary focuses of interface design: reconciling system instructions
with the actions a user must take to actually interface with the system. This may seem like an
obvious and simple task, but quite frankly, it is not simple. It requires an individual to view a
system from the standpoint of the average person who has never used the application. Being
objective is challenging for many application designers and developers. Their intimate knowl-
edge of the entire system may make it difficult to judge what actions are necessary for the user
versus what actions are necessary for the system.
This is where the time taken to get a fresh reading of the requirements can be extremely
valuable. To detach yourself from the system design and approach the application from the
point of view of the user, step back and reread the requirements for the application and look
for certain interaction information:
•
Who are the primary users of the system?
•
What do users employ the system for? What tasks must it allow them to complete?
•
What actions are required by the system in order to complete these tasks?
Write down the answers to these questions. To give an example, if you were considering
creating software that allows the user to add footnotes to a document, you should get a list
that looks something like Table 8-1.
Table 8-1.
Sample Use Case Skeleton
User
Interactions with Footnote Facilities
Writer
Add a Footnote
Writer
View a footnote
Writer
Edit a footnote
Writer
Delete a footnote
Those who are experienced in project requirements by now have noticed that what we are
doing is creating a set of simple use cases.
Use cases
spell out items such as how all of the
