Software Engineering, Autumn 1999
Use cases and object models
Four central objectives today
Shift from characterizing good requirements to a description of one approach for writing them down
Describe use cases as an approach to defining the behavioral aspects of requirements
Describe object models as an approach to defining the structural aspects of requirements
Remind everyone that there is no single best way to write requirements down
Very high-level recap of requirements issues
Determining the right requirements is extremely hard and extremely important
So difficult and important it has tons of names: requirements analysis, requirements discovery, requirements elicitation, requirements engineeering, etc.
It is hard for a lot of reasons, but chief among these is that there is an inherent gap between what is in peoples' minds and what can be written down; another key reason is the rapid rate of change in requirements that arises because of the strong feedback loop of users wanting more once they see what they have
Prototyping is one way to reduce the risk of getting requirements wrong; I view this as increasing the chance that there is a closed-loop feedback system, which reduces the risk of the system becoming unstable (this is, of course, precisely the same motivation for daily builds, although that focuses on instability in integration, not in requirements definition)
One reasonable way to structure your project requirements would be to use use cases
A use case is a description of an example behavior of the system as situated in the "real" world
There are other closely related technologies, including CRC (class responsbility collaborator) cards and eXtreme programming stories
Example: "Jane has a meeting at 10AM; when Jim tries to schedule another meeting for her at 10AM, he is notified about the conflict."
In groups of two or three people, in two minutes develop one or two use cases for TAG 2000.
To develop a requirements document
Build lots of use cases
Write them down and talk through them
This process will raise lots of questions at first, which will force you to think through and clarify some key issues
Later it will help in producing the requirements document
I'll give some fairly specific details about what use cases are
But there is no reason to follow the details precisely --- they are just guidelines
Indeed, you needn't even use use cases!
There are certainly classes of systems for which they are a poor approach to requirements engineering
Use cases and actors
Use cases represent specific flows of events in the system
Use cases are initiated by actors and describe the flow of events that these actors are involved in
An actor is anything that interacts with a use case; it could be a human, external hardware (like a timer), or another system
Use case description
How and when it begins and ends
The interactions between the use case and its actors, including when the interaction occurs and what is exchanged
How and when the use case will need data from or store data to the system
How and when concepts of the problem domain are handled
An aside: "problem domain" (very rough sketch)
The problem domain captures the part of the real world in which the system you are building is intended to take effect
For TAG 2000, the problem domain includes students, instructors, attributes for partitioning groups, etc.
The program (or implementation domain) describes how to achieve the desired behaviors in that problem domain
For TAG 2000, the program might have things like hash tables, linked list structures, modules, etc.
For computer-oriented problem domains (like operating systems), this distinction can seem pretty confusing, but is extremely worthwhile to make
Use case example from Jacobson: recycling
The course of events starts when the customer presses the "Start-Button" on the customer panel. The panel's built-in sensors are thereby activated.
The customer can now return deposit items via the customer panel. The sensors inform the system that an object has been inserted, they also measure the deposit item and return the result to the system
The system uses the measurement result to determine the type of deposit item: can, bottle or crate.
The day total for the received deposit item type is incremented as is the number of returned deposit items of the current type that this customer has returned...
Use cases vs. scenarios
Even though Jacobson invented use cases, I don't like this last example as a sample use case
The reason is that it's really pretty long
I think of this as more of a scenario, which strings together a set of use cases
But this is a fine point, not a really crucial one: describe how the system
respect to the users
An apparent aside
In the process of defining a bunch of use cases, you will enumerate a set of entities in your system
Some of these are parts of your system
Remember, we're still not talking about implementation, but about requirements
Collectively, these entities form something often called your data dictionary
Basically, a list of the entities with descriptions of what they are; example:
Account: a single account in a bank against which transactions can be applied. A customer can hold more than one account.
Customer: the holder of one or more accounts in a bank. A customer can consist of one or more persons or corporations. The same person holding an account at a different bank is considered a different customer.
Transaction: a single integral request for operations on the accounts of a single customer...
There are many objectives, but one is to reduce ambiguity, a huge problem in requirements
Very quick review
Use cases define instances of a system's behavior
The entities involved in these use cases are actors
The actors are defined in a data dictionary
How are the entities related?
The sample ATM definitions showed some relationships among the entities
Ex: "A customer can hold more than one account."
There are many such relationships among the entities in a system
These are often captured in a diagram usually called an object model
There are many languages and notations for defining object models
All object-oriented modeling techniques have such a language (OMT, UML, Booch, etc.)
Relational specification languages (like Z) also capture such relationships
But the heart of these is basically Chen's entity-relationship diagrams (ERDs): basically, boxes represent entities and connectors represent relationships
Each of the two entities has a single attribute
An attribute is similar to an instance variable
There is a relationship (or association) named Intersects between the entities
This reads "2 or more Lines intersect in 0 or more Points."
Different notations do this in different ways; Make up your own if you need!
Aggregation represents an is-part-of relationship
OMT and other notations indeed support the representation of the inheritance relationship (i.e., the "is-a" relationship)
However, it's quite unusual for a good requirements object model to include inheritance relationships
Ones' design documents might do so, however
Vibha's auction object model
Let's take a quick look at it
Then break up into groups (let's use the project groups) and write some use cases
Use use cases to define instances of the behavior of the system
Beware: it's very hard to show completeness of your large collection of use cases
Scenarios are useful because they represent larger actions that users might perform
A data dictionary captures the entities and actors in a system, quite precisely
An object model defines the relationships among those entities
Together, these three elements define the basic requirements of a system: what's there, what the stuff is, and how it gets used