Forgiveness breaks the chain of causality, because
he who "forgives" you -- out of love -- takes upon
himself the consequence of what you have done.
Forgiveness, therefore, always entails a sacrifice.
				DAG HAMMARSKJOLD

Object Modeling and Use Cases

1. Goals of Object Modeling
   communicates our understanding of the system requirements to future users

   communicates the requirements of the software application to the software development team

   serves as a 'schematic diagram' to supporting and maintaining teams after the application has been in operation

2. Modeling Methodology

   Webster:

   A set of procedures used by a discipline to achieve a particular desired outcome

   modeling methodology = Process + Notation + Tool

   A process: the 'how to' steps for gathering the requirements and determining the abstraction to be modeled.

   A notation: a graphical 'language' for communicating the model.

   A tool: an automated way of rendering the notation, typically in 'drag and drop' fashion.

   CASE tools -- Computer Aided Software Engineering tools

   UML -- Unified Modeling Language

   See also Object-Oriented Analysis and Design with UML Test

   Overview of Object-Oriented Analysis and Design:

   1. Planning, that is, analysis and design
   • analysis -- Identify the problem to be solved. What are the requirements of the software system? What objects (classes) are required? What are their responsibilities? How should they interact with each other? Identify appropriate uses of inheritance.

   • design -- Refine the classes identified in the analysis phase. Identify implementation classes. Identify appropriate uses of existing classes (like the Java API). Specify the attributes and methods of each class. Decide on specific data structures and algorithms to use.

   2. Build

   • Code
   • Debug
   • Unit test

   3. Release

   • Integration test
   • Learn
   • Maintain

3. Object-oriented analysis
   1. Object discovery
   • What are the objects?
   • Look for nouns and verbs in the problem description. Nouns --> objects. Verbs --> methods.
   • Look at roles played by people who will interact with the system.
   • Look at events that must be recorded and remembered by the system.

   2. Evaluate candidate objects

   • Identify use of inheritance or composition. Use the "is-a", "has-a" test.
   • Can classes be combined? Smaller is usually better.
   • An object must do something to justify its existence; that is, it should have some methods.
   • An object usually has some instance variables, but not always. Consider, for example the Expression Manager of the Calculator program.
   • All attributes and methods should apply to all members of the class. If this is not the case, it may indicate a place to use subclassing.

   3. Discover object attributes

   • An object asks "What state information do I need to keep over time (i.e., between calls) in order to carry out my responsibilities?"

   4. Discover object operations

   • An object asks "What services must I provide to other objects to fulfill my responsibilities?"

4. What are Use Cases

   Also known as scenarios, behavior signatures, etc ..

   A use case is a sequences of steps representing interactions between actors (users) and the system.

   represents a logical 'thread', or a series of cause and events

   begins with system's contact with actors, which are

   • human users,
   • other computer systems
   • initiating use cases

   ends with the actor's achievement

   emphasizes what the system can do ( functional requirements )

   relationship between actors and use cases is potentially many-to-many:

   • we do not identify an actor who has no use to the system in the fianl analysis

   • we do not specify a use case that nobody cares about

   Example: Consider a software system to be developed for a library. One use case is the borrowing of a book by a borrower. One scenario for this use case would consist of the following steps:

      1. Borrower list the books.
      2. Borrower borrows a book.
      3. Librarian lends the book to the patron.
     ...............
     

   A single use case may be associated with several scenarios. In this example, we might have different scenarios if the book is a reference book which may not be checked out, or if the librarian discovers that the patron already has several overdue books checked out.

   Use cases may be used iteratively, adding levels of detail at each stage. The first stage might be to name the use cases, then outline a typical scenario for it. Later, additional or more detailed scenarios may be added. The objective is to identify actors, objects, and interactions between them.

   UML defines a graphical representation for use cases. A use case diagram shows the actors and the use cases:

   Actors are represented with stick figures.
   Use cases are represented with ovals.
   An actor is connected to a use case if the actor is involved in the use case.
   Relationships between use cases are indicated by arrows. Two types of relationship exist between use cases:

   • The uses relationship occurs when there is some common behavior that exists in multiple use cases that can be factored out into a separate use case (e.g., logging in to a terminal).
   • The extends relationship is used when one use case is similar to another but adds some additional steps.

   

   Variations to normal cases are handled by extending the case