Project Life Cycle  «Prev  Next»
Lesson 2The use case model
ObjectiveDefine the Purpose and Scope of the Use Case Model.


The purpose of the use case model is to define how the users need to interact with the system. This definition includes two key elements: actors and use cases.


Actors reflect the roles that users play in relation to the system. Users may be people, other systems, or even devices. Anything or anyone that will eventually interact with the system is considered a user.
One user may play many roles, and many users may play the same role, that is, perform the same duties. For example, many people on a project play the role of programmer. But the same people in relation to the payroll system play the role of employee.
Do not automatically equate actors (roles) to job titles. Job descriptions change like the weather, and for reasons other than good system design.
In fact, careful attention to good actor definition provides strong justification for redefining job descriptions to improve cohesion and coupling in the work environment as well as in the systems.

Use cases

A use case is a goal that the system must achieve to be considered successful. For example, an automated teller system must validate access, deposit funds, and withdraw funds. A use case can usually be expressed as a noun and a verb; for example, deposit (verb) funds (noun). The kinds of funds and how the deposit is implemented will be taken care of later.
Be careful not to equate goals with processes. There are many possible processes to achieve a goal. Processes tend to describe implementation alternatives instead of the goal that the processes must achieve.
Use Case Model Scope
Watch the scope of your use case models! How detailed should the use cases be? Should you include (for example) saving data, error handling, screens, and forms?
The answer is in the concept of encapsulation. The use case model describes an encapsulated view of the system; that is, it describes only the purpose and the interfaces of the system. The internal design should be completely hidden.
Encapsulation hides the implementations of input/output (I/O) mechanisms. So when you define input and output, focus purely on content and ignore the form completely. The same I/O can be supported through a number of equally valid implementations.