CSE403 Software Engineering, Autumn 1999

David Notkin

Lecture #5 Notes
Use cases and object models


  1. Four central objectives today

    1. Shift from characterizing good requirements to a description of one approach for writing them down

    2. Describe use cases as an approach to defining the behavioral aspects of requirements

    3. Describe object models as an approach to defining the structural aspects of requirements

    4. Remind everyone that there is no single best way to write requirements down

  2. Very high-level recap of requirements issues

    1. Determining the right requirements is extremely hard and extremely important

    2. So difficult and important it has tons of names: requirements analysis, requirements discovery, requirements elicitation, requirements engineeering, etc.

    3. 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

    4. 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)

  3. One reasonable way to structure your project requirements would be to use use cases

    1.   A use case is a description of an example behavior of the system as situated in the "real" world

      1. There are other closely related technologies, including CRC (class responsbility collaborator) cards and eXtreme programming stories

      2.   Example: "Jane has a meeting at 10AM; when Jim tries to schedule another meeting for her at 10AM, he is notified about the conflict."

    2. In groups of two or three people, in two minutes develop one or two use cases for TAG 2000.

    3. To develop a requirements document

      1. Build lots of use cases

      2. Write them down and talk through them

      3. This process will raise lots of questions at first, which will force you to think through and clarify some key issues

      4.   Later it will help in producing the requirements document

  4. Important reminder

    1. I'll give some fairly specific details about what use cases are

    2. But there is no reason to follow the details precisely --- they are just guidelines

    3. Indeed, you needn't even use use cases!

    4. There are certainly classes of systems for which they are a poor approach to requirements engineering

  5. Use cases and actors

    1. Use cases represent specific flows of events in the system

    2. Use cases are initiated by actors and describe the flow of events that these actors are involved in

    3. An actor is anything that interacts with a use case; it could be a human, external hardware (like a timer), or another system

  6. Use case description

    1. How and when it begins and ends

    2. The interactions between the use case and its actors, including when the interaction occurs and what is exchanged

    3. How and when the use case will need data from or store data to the system

    4. How and when concepts of the problem domain are handled

  7. An aside: "problem domain" (very rough sketch)

    1. The problem domain captures the part of the real world in which the system you are building is intended to take effect

    2. For TAG 2000, the problem domain includes students, instructors, attributes for partitioning groups, etc.

    3. The program (or implementation domain) describes how to achieve the desired behaviors in that problem domain

    4. For TAG 2000, the program might have things like hash tables, linked list structures, modules, etc.

    5. For computer-oriented problem domains (like operating systems), this distinction can seem pretty confusing, but is extremely worthwhile to make

  8. Use case example from Jacobson: recycling

  1.   Use cases vs. scenarios

    1. Even though Jacobson invented use cases, I don't like this last example as a sample use case

    2. The reason is that it's really pretty long

    3. I think of this as more of a scenario, which strings together a set of use cases

    4. But this is a fine point, not a really crucial one: describe how the system behaves with respect to the users

  2. An apparent aside

    1.  In the process of defining a bunch of use cases, you will enumerate a set of entities in your system

    2. Some of these are parts of your system

    3. Remember, we're still not talking about implementation, but about requirements

    4. Collectively, these entities form something often called your data dictionary

    5. 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...

    6. There are many objectives, but one is to reduce ambiguity, a huge problem in requirements

  3. Very quick review

    1. Use cases define instances of a system's behavior

    2. The entities involved in these use cases are actors

    3. The actors are defined in a data dictionary

  4. How are the entities related?

    1. The sample ATM definitions showed some relationships among the entities

    2. Ex: "A customer can hold more than one account."

    3.   There are many such relationships among the entities in a system

    4. These are often captured in a diagram usually called an object model

  5.  Object models

    1.  There are many languages and notations for defining object models

    2. All object-oriented modeling techniques have such a language (OMT, UML, Booch, etc.)

    3. Relational specification languages (like Z) also capture such relationships

    4. But the heart of these is basically Chen's entity-relationship diagrams (ERDs): basically, boxes represent entities and connectors represent relationships

  6. Trivial example

    1. Each of the two entities has a single attribute

    2. An attribute is similar to an instance variable

    3. There is a relationship (or association) named Intersects between the entities

    4. This reads "2 or more Lines intersect in 0 or more Points."

    5. Different notations do this in different ways; Make up your own if you need!

  7. Aggregation represents an is-part-of relationship 

  8. Whence inheritance?

    1. OMT and other notations indeed support the representation of the inheritance relationship (i.e., the "is-a" relationship)

    2. However, it's quite unusual for a good requirements object model to include inheritance relationships

    3. Ones' design documents might do so, however

  9. Example

    1. Vibha's auction object model

    2. Let's take a quick look at it

    3. Then break up into groups (let's use the project groups) and write some use cases

  10.  Recap

    1. Use use cases to define instances of the behavior of the system

    2. Beware: it's very hard to show completeness of your large collection of use cases

    3. Scenarios are useful because they represent larger actions that users might perform

    4.  A data dictionary captures the entities and actors in a system, quite precisely

    5. An object model defines the relationships among those entities

    6. Together, these three elements define the basic requirements of a system: what's there, what the stuff is, and how it gets used