A subject-based empirical evaluation of SSUCD’s performance in reducing inconsistencies in use case models

Abstract

The problem of inconsistencies in Use Case models has plagued practitioners over the years and has been a topic of interest for many researchers. In Use Case driven approaches, the damaging effects of inconsistencies escalate as inconsistencies have a detrimental influence on every aspect of the development process. The repercussions of inconsistencies have been well documented, but little progress has been made towards reducing and remedying their effects. This paper presents a controlled experiment, which evaluates the reduction of inconsistencies resulting from deploying a new structure called (Simple Structured Use Case Descriptions) SSUCD, which is used to assist with the development of Use Case descriptions. This experiment also investigates the impact of improving consistency amongst Use Case models on other key Use Case modeling quality attributes. The results of this experiment demonstrate that using SSUCD leads to an improvement in consistency between use case models and their associated descriptions.

Appendices

Appendix A: SSUCD – Syntax Rules (E-BNF)

Appendix B: Requirements Documents

2.1 Airline Ticketing System

The system allows the Clerk to order tickets and to look for a suitable flight. In order to look up a ticket, the Clerk needs to enter the name of the traveler, the chosen flight, and finally booking the airline tickets. When looking up a flight, the system provides a list of available flights between two airports at a given date. The system must allow the ability to look up a flight without having to order a ticket. When the order information to buy a ticket is entered, this information is automatically used to look up the flight.

A third service (the help service) is available for the clerk while ordering a ticket to provide a help page specific to ordering tickets. The help service can be invoked independently by the Clerk, which will provide the Clerk with a “main” help page.

2.2 Banking System

The bank has several automated teller machines (ATMs), which are geographically distributed and connected via a wide area network to a central server. Each, ATM machine has a card reader, a cash dispenser, a keyboard/display and a receipt printer. By using the ATM machine, a customer can withdraw cash from either a checking or savings accounts; query the balance of an account; or transfer funds from one account to another. A transaction is initiated when a customer inserts an ATM card into the card reader. Encoded on the magnetic strip on the back of the ATM card is the card number, and start and expiration dates. Assuming the card is recognized, the system validates the ATM card to determine that the expiration date has not passed; that the user-entered PIN matches the PIN maintained by the system; and that the card is not lost or stolen. The customer is allowed three attempts to enter a correct PIN. The card is confiscated if the third attempt fails. Cards that have been reported lost or stolen are also confiscated.

If the PIN is validated satisfactorily, the customer is prompted to choose a withdrawal, query, or transfer transaction. Before a withdrawal transaction can be approved, the system determines that sufficient funds exist in the chosen account; the maximum daily will not be exceeded; and that there are sufficient funds at the local cash dispenser. If the transaction is approved, the requested amount of cash is dispended, a receipt is printed containing information about the transaction, and the card is ejected. Before a transfer transaction can be approved, the system determines that the customer has at least two accounts and that there are sufficient funds in the account to be debited. For approved transactions, a receipt is printed and the card is ejected. A customer may cancel a transaction at any time; the transaction is terminated and the card is ejected. Customer records, account records, and debit card records are all maintained at the server.

Appendix C: Scoring UCs Developed in the Experiment

3.1 C.1. Scoring UCs from the Banking System developed in UNL

3.1.1 UC Diagram

Fig. 13

Example banking system UC diagram developed by a subject

Use Case Name: Perform Transaction

Preconditions: The customer must have an ATM card.

Basic Flow: The customer inserts their ATM card into the card reader and enters the correct PIN. The customer is given a selection of performing a withdrawal, query, or transfer. Once the customer chooses an option, the use case for the selected transaction type takes place. Once the child use case has completed, a receipt is printed and the card is ejected.

3.1.2 Alternative Flows:

• ▪ If the PIN is entered incorrectly three times or the card is lost or stolen, the Confiscate Card use case is carried out.

• ▪ If the customer cancels the transaction, the Cancelled Transaction use case takes place.

• ▪ If the transaction to be carried out by the child use case is not approved, the Approval Failed use case is carried out.

Use Case Name: Perform Withdrawal

Preconditions: Sufficient funds must be available in the account that is to have the money debited, the amount to be removed must not exceed the remaining daily limit, and there must be sufficient funds in the local cash dispenser.

Basic Flow: The customer specifies that amount of money to withdraw and the account to withdraw it from. The transaction is then approved and the requested amount of cash dispensed, and then control returns to the Perform Transaction use case.

Use Case Name: Approval Failed

Basic Flow: The customer is informed of the reason that the transaction was not approved, and any pending transactions are cancelled.

3.1.3 Scoring:

• 1. The “Perform Transaction” is depicted as an abstract UC in the diagram but this characteristic was not stated in the description. (1 defect)

• 2. The “Perform Transaction” is depicted to have two extension points both of which were not stated in the description. (3 defects)

• 3. The “Approval Failed” UC is depicted to extend the “Perform Transaction” but this fact was not stated in the “Approval Failed” UC. As an extension UC, it is the “Approval Failed” UC that is responsible for indicating when and under what clause will the exceptional it describes will be performed. Meanwhile, in an alternative flow contained in the “Perform Transaction” UC, it is mentioned that the “Approval Failed” UC is called upon to perform the required, which is a description of an include relationship between the UCs that was not depicted. These inconsistencies are a result of the same mistake and hence are scored as one defect. (1 defect)

• 4. The “Perform Withdrawal” UC states at the end of the Basic Flow that “control returns to the Perform Transaction use case” which is a description of a include relationship rather than an implementation relationship. (1 defect)

Inconsistency defects total = 6

3.2 C.2. Scoring UCs from the Airline Ticketing System developed in SSUCD

3.2.1 UC Diagram

Fig. 14

Example airline ticketing system UC diagram developed by a subject

Use Case Name: Order Tickets

Associated Actors: Clerk

3.2.2 Description

Basic Flow: Clerk enters the name of the traveler then enters the flight name which is INCLUDE <Find Flight> by the system based on the entered order information, and the books the tickets.

Sub Flows: Find Flight

Postconditions: The tickets have been ordered

Extension Points: need help

Use Case Name: Use Help Page

Associated Actors: Clerk

3.2.3 Description

Basic Flow: The clerk invokes the help service and the order flight page is brought up.

Alternative Flows: If the Clerk invokes the help service outside of ordering tickets the main page is brought up.

Alternative Flows: If the Clerk invokes the help service outside of ordering tickets the main page is brought up.

3.2.4 Extended Use Cases

Base UC Name: Order Tickets

Extension Point: need help

IF the clerk needs help while ordering a ticket

3.2.5 Scoring

• 1. For the “Order Tickets” UC:

• ▪ The depicted include relationship with the “Find Flight” UC was correctly stated in the description.

• ▪ The depicted extension point “need help” was correctly stated in the description.

• ▪ The depicted association with the “Clerk” actor was correctly stated in the description.

• ▪ A Sub-flow was stated which indicates that “Find Flight” is a sub routine described within the UC, which is incorrect since this behavior is described in the inclusion UC “Find Flight”. This results in a inconsistency within the UC description since the inclusion relationship was already stated. (1 defect)

• 2. For the “Use Help Page” UC:

• ▪ The depicted association with the “Clerk” actor was correctly stated in the description.

• ▪ The depicted extend relationship with the “Order Tickets” UC is correctly stated in the description.

• ▪ The depicted clause is correctly stated in the description.

• ▪ The description states the extension point (“need help”) at the “Order Tickets” UC where the additional behavior is inserted. This information should be depicted on the extend arrow but was not. (1 defect)

Inconsistency defects total = 2