Umu logo Umeå University
Faculty of Science and Technology
Department of Computing Science


From Use Cases to a Hypertext Based Object Model

Jürgen Börstler
Department of Computing Science
Umeå University
S-901 87 Umeå, Sweden

e-mail: jubo@cs.umu.se
phone: +46 (90) 16-67 35
fax: +49 (90) 16-61 26
URL: http://www.cs.umu.se/~jubo/

Extended Abstract

Use cases and similar notions (like task scripts) are well-suited to describe a system from the user's point of view. In this paper we'll show how use case based tools can support requirements capturing, the derivation of an object model, and the traceability between requirements and design.

In RECORD (REquirements COllection, Reuse, and Documentation, [Bör96]) we tried to follow an user-oriented approach. According to [Car+94] do people appear to understand the world in terms of specific situations. Since use cases are well-suited to describe such situations they are a natural way to describe a system in terms of specific uses. To make the RECORD system usable by end-users we provide a form-based user interface to support structured input of requirements.

The forms are analyzed according to the heuristics described in [SHE89] to identify objects, their properties, behaviors, and interrelationships. This information is used to generate an initial object model. This object model is documented in HTML and interlinked with HTML versions of the use cases. Goal of the whole process is to produce a hypertext based requirements model, supporting the traceability between external and internal views of the system.

Every use case form contains a list of fields. Users are not forced to complete a form in one step, the only thing required by our system are unique names for all use cases. This makes it very easy to switch back and forth between forms.

REGISTER_NEW_CARD describes a typical use case in an access control system (for more details see [BoSi96]). Simultaneously to the use case construction a dictionary is constructed to resolve misunderstandings.

name:		Register_new_card
actor:		System administrator
summary:	The system administrator registers a new card. The
		user of the card then registers a code for the card by
		herself. 
rationale:	Users can only access the controlled area with a
		registered card. A card must have a registered code.
preconditions:	The system is idle.
description:	1. {Enter_supervisor_mode}
		2. The {system administrator} {enters} a new {card}
		   into the {cardreader}.
		3. The {system} {validates} the {card} with the
		   {cardreader}.
		4. The {system} {registers} the {card} in the
		   {database}.
		5. {Enter_new_code}
postcondition:	The system is idle.
exceptions:	3. Card invalid.
Exceptions are described as simplified use cases in separate forms. The system marks known terms with curly brackets. Known terms may be entries in the dictionary or other use cases, as for example ENTER_NEW_CODE in the use case above. A known term is classified as a simple word, an actor, an abstract use case, or a concrete use case.

Unlike [Jac+92] and [Reg+95] we do not succsessively refine and formalize use cases manually to derive an object model. In our approach use cases are semi-automatically transformed into object models. This has the advantage of a very short analysis/design cycle and can be seen as a kind of design prototyping. We therefore do a simple textual analysis to identify subject, predicate, and object of each sentence. We then use the heuristics described in [SHE89] to determine objects, attributes, and methods.

From our example use case we get the objects system administrator, cardreader, system, and database from the subject and object of the actions. From the predicates of the actions we get the verb phrases enters_card, validates_card, and registers_card, which are transformed into methods in the object class CARDREADER. The nouns in the compound method names are transformed into instance variables.

In a last step a set of interlinked HTML documents is produced. We generate HTML documents for actors, use cases, the dictionary, and the object model. The object model is structured according to the classes identified during use case analysis. The outcome of this last "phase" is a fully traceable documentation of the functional requirements of the system.

References

[Bör96]
J. Börstler: User-Centered Requirements Engineering in RECORD - An Overview, Proceedings NWPER'96, the Nordic Workshop on Programming Environment Research, Aalborg, Denmark, May 1996, 149-156.
[BoSi96]
T. Boman, K. Sigerud: Requirements Elicitation and Documentation using T-red, Master's Thesis, Umeå University, May 1996.
[Car+94]
J.M. Carrol et al: Binding objects to scenarios of use, Int. Journal of Human-Computer Studies 41, 1994, 243-276.
[Jac+92]
I. Jacobson et al: Object-Oriented Software Engineering, A Use Case Driven Approach, Addison-Wesley, 1992.
[Reg+95]
B. Regnell et al: Improving the Use Case driven Approach to Requirements Engineering, 2nd Int. Symposium on Requirements Engineering, York, England, Mar 1995, 40-47.
[SHE89]
M. Saeki, H. Horai, H. Enomoto: Software Development Process from Natural Language Specification, 11th Int. Conference on Software Engineering, Pittsburgh, PE, USA, Mar 1989, 64-73.
Please refer to the list of selected references for more information.

Back to

o Umeå University
o Department of Computing Science
o jubo's homepage

http://www.cs.umu.se/~jubo/OOPSLA.html
Last modified: Wed Sep 25 16:01:07 MET DST 1996 by jubo.