The use case model includes the actors, the system, and the use cases themselves. The set of functionality of a given system is determined through the study of the functional requirements of each actor, expressed in the use cases in the form of 'families' of interactions . Actors are represented by little stick people who trigger the use cases, which are represented as ellipses contained within the system.
An actor represents a role played by a person or a thing that interacts with a system. Actors are determined by observing the direct users of a system — those who are responsible for its use or its maintenance — as well as the other systems that interact with the one under study. The same physical person may play the role of several actors (vendor, client). Additionally, several people may all play the same role and therefore act as the same actor (all the customers). The name of the actor describes the role played by the user.
In the following example, Mr Schmoldu, a garage worker, spends most of his time acting as a mechanic, but may sometimes act as a salesman. On Sundays, he plays the role of customer and services his own car.
The same physical person may play the roles of several actors
Candidate actors are recruited from users, customers, partners, suppliers, salespeople, and other systems; in summary, the people and things that are outside a system and interact with it by exchanging information. Determining the actors facilitates the specification of the system's limits in an incremental way: while fuzzy in the beginning, they become more precise as the various use cases are implemented. This delineating activity is very important, as it serves as the contractual basis by which everything that must be done is specified — what is part of the system to be developed and what is not. It also specifies the inviolable elements that the team of developers may not modify.
There exist four main categories of actors:
Once identified, actors must be described clearly and precisely, in three or four lines at most. When there are many actors within a system, it is advisable to group them in categories to facilitate navigation within the use case model.
Use cases are determined by observing and specifying, actor by actor, the interaction sequences (scenarios) from the user's standpoint. They are described in terms of the information exchanged and the way the system is used. A use case groups a family of usage scenarios according to a functional criterion. Use cases are abstractions of dialog between the actors and the system: they describe potential interactions without going into the details of each scenario.
Use cases must be seen as classes whose instances are the scenarios. Each time an actor interacts with the system, the use case instantiates a scenario. This scenario corresponds to the message flows exchanged by objects during the particular interaction that corresponds to the scenario. Analysis of requirements by use cases is very well complemented by an iterative and incremental approach.
The scope of use cases goes far beyond solely defining of the requirements of the system. Indeed, use cases come into play throughout the lifecycle, from the specification stage to system testing, through the analysis, design, implementation, and documentation stages. From that standpoint, it is possible to navigate first towards the classes and objects that collaborate to satisfy a requirement, then towards the tests that verify the system performs its duties correctly.
