KEYWORDS: Use Cases, Software Engineering Methodologies, requirements analysis,

1 – OMT1 refers to the original introduction of OMT in 1991. This has since been revised and the revised version will be labelled OMT2 in this paper.

1. Introduction - The Development of Use Cases in Software Methodologies.

In 1991, the Object Modelling Technique [BUMBAUGH, 91] appeared on the software engineering methodology scene. Like most methodologies, it aimed to tackle the way in which object oriented programs are analysed, designed and implemented. OMT has progres sively become a widespread and heavily utilised methodology in OO circles and has been a foundation stone on which another methodology has been created, i.e. UML (Unified Modelling Language) [GRADY, BOOCH, RUMBAUGH, 94]. But the original release of OMT la cks the formal application of use cases in its methodology definition. In 1992, Ivar Jacobson devised a software methodology, namely OOSE (Object Oriented Software Engineering) [JACOBSON ET AL, 92]. This methodology is referred to as a ‘use case driven me thodology’, one in which use cases are involved at all stages of development. These include analysis, design, validation and testing. Upon realising the strength of formally defining use cases in a methodology, a revision of OMT occurred in 1994 which led to the addition of use cases to the formal methodology [RUMBAUGH, 94]. This added immensely to the OMT methodology as use cases are a very practical step to achieving good requirements analysis. The latest software engineering methodology to be introduce d is UML. This makes use of use cases in a formal manner, by extending the concept and providing a formal graphing technique to aid use case application.

In 1992, Ivar Jacobson referred to the interactions between a system and entities outside the system boundary as use cases. These interactions are taken into account when a scenario-driven approach is being applied in the analysis stage (as opposed to data-model driven and event driven approaches). In fact, each use case can be thought of as a sequence of scenarios of interactions between the system and the outside entities. A scenario depicts sequences of incidents which occur that cause an object to change state, for example, an object exchanging information with another object [DERR, 95]. Note that scenarios do not just refer to what the system can do but also refer to those interactions that the system must be able to identify as invalid . Examples of this are error conditions and exceptions.

The entities that lie outside the system boundary which interact with the system are called Actors. Examples of actors may be the end user, a database administrator, a computer operator, another computer system application, or another entity needin g to exchange information with the system [DERR, 95]. Actors carry out use cases. A single actor may perform many use cases, and conversely, a use case may have several actors performing on it [FOWLER, SCOTT, 97].

In summary, use cases are what happens when actors interact with the system. The requirements of a system may be built up gradually through observing the way the different actors use the system to reach distinct goals.

When developing the requirements analysis of an Object Oriented project, a relatively short problem statement document and a general requirements table must be specified. This requirements table shall contain many assertions referring to the different requirements, a priority for each assertion and also an allocation domain for each requirement. After this stage of analysis, use cases shall be identified. And finally, a system context diagram shall be derived, which graphically visualises th e system from a single bubble-type representation of the project.

A single stand-alone example of a use case scenario is as follows. "An engineer wishes to become a new lecturer in the university". The engineer is the actor in this example. Some of the possible interactions that the actor can have with the university (i.e. the system) are as follows:

(a) If the engineer has the correct qualification for the position and the post is empty, hire the engineer.

(b) If the engineer has the correct qualification for the position and there is no vacant post, have the engineer put on file and contact him when the post becomes available.

(c) If the engineer does not obtain the correct qualification, refuse his application for the position.

This example illustrates the role of the scenario (the requirement to be analysed), the system (the university) and the actor (the engineer). The actor can be perceived to be walking through the system

The next example shows use cases being determined for a software-implemented club database system. The use cases are determined through knowledge of what the end user requires. Some for the use cases are as follows:

1. adding a member
2. searching for a members record
3. deleting a member
4. editing a members record

At the analysis stage, the only concern is the exchange of information between objects. It is always prudent to develop normal and error condition scenarios at this stage.

Normal Scenario:

Error Condition Scenario:

Normal Scenario:

Error Condition Scenario:

Normal Scenario:

Error Condition Scenario:

Normal Scenario:

Error Condition Scenario:

It must be noted that only the simple interactions between the user (i.e. the actor) and the system (i.e. the club database program) are documented in these example scenarios. Detailed information about what is entered by the user about the member is not listed in this section as it would be outside the scope of detailing the interactions between the system and actor.

One may ask the question as to why use case scenarios are ever applied to requirements analysis, given that they weren’t formally specified by O.M.T. The answer is that, in many ways, analysis is the most important part of an object oriented develo pment lifecycle. As well as providing many of the analysis requirements, use cases are used to test that all assumptions made during other analysis stages are fully correct and that no analysis errors occur.. Analysis errors occur when either a user requi rement is missing, a user requirement is misunderstood or an unnecessary requirement is included. [AMBLER, 95]. If a major requirement is omitted at this stage, it will have major implications on the rest of the development lifecycle. The cost of detectin g errors at this stage rises almost exponentially as the development lifecycle continues towards testing. This can be seen in Figure 1 [AMBLER, 95]

If an error is made at the analysis stage, it is very cheap to correct. This is easily performed by changing the analysis. If an error is found at design time, it becomes a little more expensive to correct. This is achieved with a reasonable amount of effort by changing the design based on the incorrect analysis. If an analysis error is discovered at the programming stage, this will become more expensive to correct. Correction will involve going back to the analysis and design stages to try to fix the problem. Correction at this stage will likely involve code being erased. If an error is discovered at the testing stage, more code than before may have to be erased and invaluable time spent on analysis and design. Also, documentation will have to be altered. Finally, if an error is found after the product has been released, it becomes very expensive to correct. Upgrade disks will need to be sent out, analysis and design changed, code dumped and possibly new code written and the documentation would ha ve to be changed to reflect the change in the previous stages.

UML (Unified Modelling Language} has been introduced by Grady, Booch and Rumbaugh at Rational Software. UML is an OO Methodology which encompasses what they conceive to be a collection of the best engineering practices that have proven succe ssful in the modelling of large and complex systems [UML SUMMARY, 97]. These practices have been drawn mainly from the Booch, OMT and OOSE methodologies. Use case diagrams in UML are almost identical to use case diagrams as described by OOSE. In UML, the behavioural model is divided into 4 different packages: Common Behaviour, Collaborations, Use Cases, and State Machines. The use case package specifies behaviour using actors and use cases [UML SEMANTICS, 97].

1. Uses:

This is a relationship between use cases which when used, means that the behaviour defined in the former Use case includes the behaviour exerted by the latter use case.

2. Extends:

UML formally defines another term useful to help understand use cases. In every use case analysis, it is possible to perform use cases in many different ways. Therefore, it is said that a use case can have many realisations. In summary, use case di agrams help to visualise the interactions between the use case and actors, and depict graphically the relationships between them both.

When the Object Modelling Technique was introduced in 1991 [RUMBAUGH ET AL, 91], it did not formally specify the utilisation of use cases. The method consisted of 4 phases as seen in Figure 3:

This methodology is comprised of 4 stages that are iterative in large projects. The stages can be detailed as follows:

(a) Analysis:

This focuses on the initial requirements analysis of the specified problem and on the 3 O.M.T. models, the Object Model, the Dynamic Model and the Functional Model.

(b) System Design:

This focuses on the design of the systems architecture at a high level.

This focuses on the specific detailed design of the 3 Models mentioned above.

(d) Implementation:

This focuses on the coding of the system and object designs specified in section’s (b) and (c)

The Object model describes the system from a static and structural viewpoint. The Dynamic Model describes the system from a temporal and behavioural viewpoint. The Functional Model describes the data transformations that take place in the system.

Though the OMT1 methodology does not deal formally with use cases, it does apply the idea of scenarios in the Dynamic Model, which focuses on the control aspect of the system.

The Dynamic Model captures the time and sequence of operations, much like the use case capturing the interactions that take place in a system. When the use case approach is being applied, the analyst is generating a sequence of operations that occur be tween the actor and system and by default, specifies the time that they are going to occur relative to when the user interacts with the system. Included in the formal definition of the Dynamic Model is the concept of Event Trace diagrams. An Event is defi ned as being an individual stimulus from one object to another. These diagrams illustrate sender and receiver object by a straight line and illustrate single events by a horizontal line. This is the Dynamic Model’s way of informally acting out a scenario. The Dynamic Model employs the Harel Statechart, also known as State Diagrams, as a method of representing permissible event sequences. These diagrams are illustrated by nodes, which represent the states, and by arcs, which represent the transitions cause d by the occurrence of events. This is similar to use case scenarios in that, in the normal flow of the Harel Statecharts, each state can be said to represent each line of a normal scenario and each diversion from the main node-arc tree can represent each error condition scenario for the use case.

In 1994, a revision of OMT1 appeared [RUMBAUGH, 94] with the formal introduction of use cases into the methodology, i.e. OMT2. This states that the use case is permanently bound to the Analysis stage of the O.M.T. This requires an extension onto wh at is defined by OMT1 by adding 2 new models to the Analysis stage.

(a) The Domain Model:

This model is created by exploring the general domain and acquiring knowledge about the task to be performed.

(b) The Application Model:

This model is constructed over the domain model by examining the use cases for the system.

In this approach revision, use cases are a method of examining the system-actor interactions from a user-centred viewpoint. [ANDERSSON, BERGSTRAND, 95]

In 1992, Ivar Jacobson wrote about Object Oriented Software Engineering [JACOBSON ET AL, 92] which described an older methodology called Objectory, which he had devised previously, more formally. The central basis of this methodology is based on the us e of use cases [CARMICHAEL, 94]. All of the major stages of OO development lifecycle are driven through use cases, i.e. analysis, design and testing. The reason such a methodology has been introduced is to make the systems being produced more useable and more adaptive to changing utilisation. The analysis and design stages are performed around the user interaction with the

system and the use of scenarios as defined in typical use case employment. This methodology is inherently iterative as it divides the system development into activities. As the activities are explored, they form related models from which large systems can be built. The development lifecycle is shown in Figure 4.

The lifecycle consists of gathering the requirements of the system and analysing them. At this stage, use cases are employed to help develop models which give a greater understanding of the system. They define the way that the system will function. The se models focus on the end-application rather than on how the system will be implemented. At the construction stage, the models are further developed and the full system is designed and implemented. The testing phase integrates the full system together an d verifies that the correct system has been constructed. When integrating the system, use cases are integrated into the system one at a time.

It has become evident that use cases are becoming an integral and formal part of differing Object Oriented methodologies. They prove their worth at the analysis stage of development lifecycles as they help to identify the models that are need for the r est of the development in an easy to understand manner. Their benefit becomes obvious when the cost of finding errors in later stages of the cycle is considered. The cost of employing use cases far outweighs the cost of discovering errors later on. The fa ct that Dr. James Rumbaugh revised OMT to formally include the application of use cases into the first revision only serves to highlight this fact. Also, the fact that a distinct methodology can be driven by use cases shows their flexibility of employment into any stage of the development lifecycle. For these reasons, use cases are now an integral part of the UML, recognised by some to be the software OO methodology of the next 5 years.

The following is a list of references from which this document has evolved.

[RUMBAUGH ET AL, 91]

Rumbaugh J., Blaha, Premerlani, Eddy, Lorensen, "Object-Oriented Modelling and Design", Prentice Hall. 1991.

[GRADY, BOOCH, RUMBAUGH, 94] UML concieved at Rational Software,

[JACOBSON ET AL, 92]

Jacobson I., Christenson M., Jonson P., Overgaard G., "Object-Oriented Software Engineering". Addison-Wesley, 1992.

[ANDERSSON, BERGSTRAND, 95]

Andersson M., Bergstrand J., "Formalizing Use Cases with Message Sequence Charts", Masters Thesis, 1995

[RUMBAUGH, 94]

Rumbaugh J., "Getting started - Using Use Cases to Capture Requirements", Journal of Object Oriented Programming, September 1994.

[DERR, 95]

Derr K., "Applying OMT - A Practical Step-by-Step Guide to Using the Object Modelling Technique", Sigs Books, 1995

[FOWLER, SCOTT, 97]

Fowler M., Scott K., "UML Distilled - Applying the Standard Object Modelling Language", Addison-Wesley Longman Inc, 1997

[AMBLER, 95]

Ambler S., "The Object Primer - The Application Developer's Guide to Object-Orientation.", Sigs Books, 1995

[CARMICHAEL, 94]

Carmichael A., "Object Development Methods", Sigs Publishing, 1994

[UML SEMANTICS, 97]

Rational Software, UML Notation Guide version 1.1 - UML Semantics

[UML SUMMARY, 97]

Rational Software, UML Notation Guide version 1.1 - UML Summary

[UML NOTATION, 97]

Rational Software, UML Notation Guide version 1.1 - UML Notation