CS 4448 - Fall 1998
Object-Oriented Programming and Design
Talk 5.1
by
Enrique M. Meneses

In his article Building an Object Process Around Use Cases Tom Rowlett argues that a successful software process must be consistent, verifiable, manageable, traceable, testable, and incremental. He then goes on to say that use cases fulfill all these requirements.

Let's first describe use cases, before presenting how use cases can serve all these roles to create a software engineering process. Use cases are used in the requirements phase of a project to fully define the functionality of a system. During this process, the developer with the help of the customer tries to define the system boundaries by specifying the use cases, actors (the "users" of the system), and their relationships.

Before continuing let's also define what Mr. Rowlett means by consistent, verifiable, manageable, traceable, testable, and incremental.

• A process is consistent if results of one step can be used as the input to the next phase of the project.
• It's verifiable if it can be shown that the input to a new deliverable is correct.
• It is manageable if it can be demonstrated that all the deliverables for a given step have been produced.
• It is traceable if the design or code segments can be identified with requirements.
• It is testable if each requirement can be shown to have executed correctly.
• And finally it is incremental if the requirements can be divided in such a way that a minimum amount of analysis, design, coding and testing is required to produce a functional piece of the final product.

During the requirements and analysis phase use cases are used to specify the functionality of the system and describe how the system will be used. At this point the use cases can also serve to validate the completeness of the specification; the use cases can be presented to the customer to ask them "are all use cases and associated outcomes identified, and do their behaviors correctly describe the required system?" (Rowlett) Because of their completeness, use cases contain all the information that is necessary to create other models, system architecture, coding and documentation.

For example, the use cases can be used by the system architect to create a collaboration diagram that transforms the use cases into classes, the operations on these classes, and the relationships between the classes. These can serve to further create other static and/or dynamic models (ex. object diagrams, sequence diagrams, state diagrams) that might be necessary to define the system architecture for the product being developed. This transformation is called the realization of the use cases.

Once the architecture and design are completed, the use cases can be used to validate once again the correctness of the system. At this point it must be verified that every object in the object model appears in the use case and vice versa, every attribute in the object model is used and changed in the use case, and that every behavioral requirement is described in the use cases.

The use cases can then be used by the developers to understand what the system should do, before they take the other models to come up with an actual implementation of the product.

Because a use case represents a particular functionality, then it is possible to choose a subset of the use cases to create an iterative and incremental development process. For example, a project manager might want to target the high risk aspects of the project to be implemented in a first iteration. As time goes on, other subsets of the functionality can be chosen and implemented in further iterations; thereby allowing the development team to start delivering functionality earlier. This would allow the development team to get early input from the customer, and testing and integration teams.

Use cases can also be used by the testing teams to make sure that the software performs the functionality requested by the customer. Since the use cases represent the complete functionality of the system, then testing the system is a matter of "walking the use case." In this technique the testers take on the different roles in the use cases model and verify weather a particular scenario conforms with the use cases.

This summary documents how use cases can be used to build an Object Process. It is an extremely useful model to define the system requirements and it shows how the model leads to a consistent process in which the use cases is used to design the system, then used by a development team to understand the requirements, and finally by the testing team to determine weather the system performs the requested functionality. The use cases can be used to determine weather all deliverables have been produced; for example by walking the use case (it leads to a manageable process). They can be traced to the objects and their implementations that resulted from the realization of the use cases and vice versa. Use cases can also be used by the testing teams as well to decide weather the system does what is supposed to do, and finally, they can be used to break up development into iterations that produce a functional subset of the system earlier. Therefore the process is verifiable, manageable, traceable, testable, and incremental as Rowlett defined them.

• Use cases
  A use case is a description of a functionality (a specific usage of the system) that the system provides. (from UML Distilled, pg. 16) The set of all the use cases represent the complete functionality of the system.
• Actor
  An actor is someone or something that interacts with the system. An actor represents a role, not a particular instance of an object that uses the system. The actor always gets some value through its interaction with the system.

A Rational Approach to Software Development Using Rational Rose 4.0