Quality improvement of requirements specification via automatically created object oriented models

Daniel Popescu
Georgia Institute of Technology

Case Study

An elevator specification is used as a case study to demonstrate our approach [8]. However, before the tool could create the object oriented analysis model, the specification had to be transformed to meet the controlled grammar constrains.
The original specification looked like the following:


An n elevator system is to be installed in a building with m floors. The elevators and the control mechanism are supplied by a manufacturer The internal mechanisms of these are assumed (given) in this problem. Design the logic to move elevators between floors in the building according to the following rules:
  1. Each elevator has a set of buttons, one button for each floor. These illuminate when pressed and cause the elevator to visit the corresponding floor. The illumination is canceled when the corresponding floor is visited (i.e., stopped at) by the elevator.
  2. Each floor has two buttons (except ground and top), one to request an up-elevator and one to request a down-elevator. These buttons illuminate when pressed. The buttons are canceled when an elevator visits the floor and is either traveling the desired direction, or visiting a floor with no requests outstanding. In the latter case, if both floor request buttons are illuminated, only one should be canceled. The algorithm used to decide which to serve first should minimize the waiting time for both requests.
  3. When an elevator has no requests to service, it should remain at its final destination with its doors closed and await further requests (or model a "holding" floor).
  4. All requests for elevators from floors must be serviced eventually, with all floors given equal priority.
  5. All requests for floors within elevators must be serviced eventually, with floors being serviced sequentially in the direction of travel.


After the specification is transformed into the controlled grammar, it looks like the following.

An elevator system is to be installed in a building with floors.
  1. Each elevator has buttons. Each elevator has one button for each floor. When a user presses a button, the button becomes illuminated and the elevator visits the corresponding floor. When the elevator visits a floor, the elevator cancels the corresponding illumination.
  2. Each floor has two buttons. (except ground and top). If the user presses the up-button, an up-elevator is requested. If the user presses the down-button, a down-elevator is requested. If the user presses a button, this button becomes illuminated. When the elevator visits a floor, the elevator cancels the corresponding illumination of the button in the desired direction. The system minimizes the waiting time.
  3. When an elevator has not to service any requests, the elevator remains at its final destination and the doors of the elevator are closed. The elevator awaits further requests.
  4. The elevators service all requests from floors eventually with equal priority.
  5. If a user presses a button within the elevator, the elevator services this request eventually in the direction of travel.

The implemented tool creates the diagram Figure 2 out of the second specification.
Figure 2: The automatically created analysis model from the elevator example.
lift.png

Interpretation

After the object oriented analysis model is created, a human analyst can check it for ambiguities. The following list give some ideas that a human analyst can use.
  • The associations are a hint for possible ambiguities. For example, if two different class send a message to the same class. It should be guaranteed that they actually communicate with the same class. If a motion sensor activates one type of display and a smoke detector actives another type of display, then the class diagram should reflect that with two different display classes.
  • Each class should reflect one concept. For example, it should be checked if book and textbook are really two different classes, when the system did not create a generalization between these two classes.
  • If a class has an attribute, but the attribute is not a primitive type like a string or a number, a definition of the attribute might be missing in the original text. After the definition is added, the attribute should be reflected by an own class.
  • If a class has no association, it could indicate that no relations or interactions between this class and other classes were specified. This could be an underspecification.
After applying the above mentioned guidelines, the diagram reveals four defects in the natural language specification.
  1. The diagram shows a class for an up-elevator and a down-elevator. Both classes have no connection to any other class, nor do they have any association to the class elevator. Furthermore, the up-elevator has an attribute requested, while the elevator serves a request, which indicates that the up-elevator and down-elevator are a specialization of the elevator. All this indicates that the concepts up-elevator and down-elevator are not defined enough.
  2. The class doors in the diagram contains the attribute closed. However, the class has no methods, which would allow to manipulate this state. If closing and opening the door is within the scope of the system, it indicates that the concept door is not defined enough.
  3. Both, the floor and the elevator, have buttons. Therefore, the class elevator and the class floor have an aggregated class button. However, the diagram indicates that they have the same type of button. Since they have different behavior, it is unlikely that the same class describes both. Talking only about button could lead to different interpretations. Therefore, defining a concept elevator button and floor button would enhance lucidity in the specification.
  4. The class up-button and the class down-button are only connected to the class user. Since the user is an actor in the system, the diagram does not clarify where the buttons belong to. It can be derived from the natural language specification, because they are mentioned in the same paragraph as the floor. However, it is not necessary to assume this. Therefore, both concepts can be clarified to reduce the ambiguities in the specification.

Bibliography

1
Russel J. Abbott.
Program design by informal English descriptions.
Communication of the ACM, 26(11):882-894, 1983.

2
D. Barker and K. Biskri.
Object-oriented analysis: Getting help from robust computational linguistic tools.

3
Daniel Berry.
Natural language and requirements engineering - nu?
In www.ifi.unizh.ch /groups/req/IWRE/papers&presentations/Berry.pdf, accessed on 2.12.2005.

4
N. Fuchs and R. Schwitter.
Attempto controlled english (ACE), 1996.

5
Norbert E. Fuchs, Uta Schwertel, and Rolf Schwitter.
Attempto controlled english (ACE) language manual, version 3.0.
Technical Report 99.03, Department of Computer Science, University of Zurich, August 1999.

6
Vincenzo Gervasi and Bashar Nuseibeh.
Lightweight validation of natural language requirements.
Softw., Pract. Exper., 32(2):113-133, 2002.

7
H. M. Harmain and Robert J. Gaizauskas.
CM-builder: A natural language-based CASE tool for object-oriented analysis.
Autom. Softw. Eng., 10(2):157-181, 2003.

8
Mats Heimdahl.
An example: The lift (elevator) problem.
http://www-users.cs.umn.edu/ heimdahl/formal-models/elevator.htm, accessed on 14.12.2005.

9
Natalia Juristo, Ana Maria Moreno, and Marta López.
How to use linguistic instruments for object-oriented analysis.
IEEE Softw., 17(3):80-89, 2000.

10
Leonid Kof.
Natural Language Procesing for Requirements Engineering: Applicability to Large Requirements Documents.
In Alessandra Russo, Artur Garcez, and Tim Menzies, editors, Automated Software Engineering, Proceedings of the Workshops, Linz, Austria, September 21 2004.

11
Luisa Mich and Roberto Garigliano.
Nl-oops: A requirements analysis tool based on natural language processing.
In Proceedings of Third International Conference on Data Mining Methods and Databases for Engineering, Bologna, Italy, 2002.

12
Diego Mollá, Rolf Schwitter, Fabio Rinaldi, James Dowdall, and Michael Hess.
Nlp for answer extraction in technical domains.
In 11th EACL 2003, Proceedings of the Conference, 2003.

13
Sastry Nanduri and Spencer Rugaber.
Requirements validation via automated natural language parsing.
Journal of Management Information Systems, 12(3):9-19, Winter 1995-96.
Journal version of hicss.ps.

14
J. Rumbaugh.
Object-Oriented Modeling and Design.
Prentice Hall, 1991.

15
D. D. Sleator and D. Temperley.
Parsing English with a link grammar.
In Third International Workshop on Parsing Technologies, 1993.

16
Richard Sutcliffe and Annette McElligott.
Using the link parser of sleator and temperley to analyse a software manual corpus, 1995.

About this document ...

Quality improvement of requirements specification via automatically created object oriented models

This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.49)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html paper.tex -split 0 -dir biblio -no_navigation

The translation was initiated by Daniel Michael Popescu on 2005-12-15


Daniel Michael Popescu 2005-12-15