OOAOOD Modeling Tutorial

1
OOA/OODModeling Tutorial

• Mins208
• Fall 1999

2
Objectives

• In this tutorial, the use of Use Case Analysis,
  Scenario Definition, Sequence Diagrams, and Class
  Diagrams will be demonstrated. In this
  demonstration, we will see
• Use Case extraction from a problem statement.
• Creation of a Happy Day scenario for this use
  case.
• Creation of a sequence diagram from the scenario.
• Creation of a class diagram from the sequence
  diagram.

3
Objectives

• NOTE Use Case Diagrams, Sequence Diagrams, and
  Class Diagrams are separate diagram types. Just
  like DFDs and ERDs.

4
Problem Description

• The example which will be used in the tutorial is
  a small part of the customer interaction with a
  bookstore. The problem space encompasses a simple
  customer-inventory interaction.

5
Problem Statement

• A simple bookstore has shelves on which books are
  placed. A customer will enter the store and pick
  up a shopping basket. They will then look through
  the books on the shelves searching for titles in
  which they are interested in. As soon as a
  customer finds a title in which they are
  interested, they will place the book in their
  shopping basket.
• ...

6
Use CasesContext Level

• From the problem statement, we can derive the
  following context level use case diagram

7
Use CasesContext Level
This Diagram shows the customer interacting
through the context level use case Bookstore
Book Buying. If the context of the system being
modeled was more broad, the context level use
case would reflect a more broad topic. For
instance, if we were modeling the operations of
an entire bookstore, we would show the customer
interacting with the context level use case
Bookstore Interaction.
8
Use CasesContext Level

• Things to remember
• The context level use case reflects the scope of
  the problem being analyzed.
• The context level use case should represent all
  actors interacting with the system being
  analyzed.
• The context level use case is the most
  generalized view of system functional
  decomposition.

9
Use CasesDecomposition
From the context level of the use case, we can
further break down the system into some use cases
which decompose the general use case Bookstore
Book Buying. This will look like
10
Use CasesDecomposition

• Where did these use cases come from?
• Use Case Enter Store came from problem statement
  sentence A customer will enter the store
• Use Case Pick up Basket came from problem
  statement ...and pick up a shopping basket.
• Use Case Choose Book came from the problem
  statement ... They will then look through the
  books on the shelves searching for titles in
  which they are interested in. As soon as a
  customer finds a title in which they are
  interested, they will place the book in their
  shopping basket.

11
Use CasesDecomposition

• Use Case Enter Store - This use case most likely
  cannot be broken down any further.
• Use Case Pick up Basket - This use case most
  likely cannot be broken down further.
• Use Case Choose Book - It is possible that this
  use case could be broken down further. However,
  it turns out that this use case can also have a
  decent scenario defined for it, therefore does
  not need to be broken down further.

12
Use CasesDecomposition

• Use Case Enter Store - This use case most likely
  cannot be broken down any further.
• Use Case Pick up Basket - This use case most
  likely cannot be broken down further.
• Use Case Choose Book - It is possible that this
  use case could be broken down further. However,
  it turns out that this use case can also have a
  decent scenario defined for it, therefore does
  not need to be broken down further.

Rule of thumb A decent scenario will involve 5-9
atomic steps.
13
Use CasesUse Case to Scenarios

• Each Use Case is a case of what the Actor will do
  with the system.
• This interaction reflects a functional view of
  the system, related to the Actor.
• For each functional interaction, we should be
  able to construct a list of events which occur in
  the system related to the Actors interaction.
  This is called a Scenario.

14
Use CasesUse Case to Scenarios

• For the bookstore - Use Case Enter Store
• Assume Customer named Joe and a Bookstore named
  Corner Books.
• This is a typical scenario
• 1) Customer Joe opens the front door of Corner
  Books.
• 2) Customer Joe enters Corner Books.
• 3) Customer Joe closes the front door of Corner
  Books.

15
ScenariosUse Case to Scenarios

• How did we derive this scenario???
• Normally, the construction of a valid set of
  scenarios is where the problem domain experts
  come into the analysis picture.
• A problem domain expert is somebody who has
  expert knowledge of the problem which is being
  modeled.
• In our case, this would be somebody who is an
  expert on bookstores. This person would know
  exactly what happens in the daily operations of
  a bookstore. They would also know what Joe
  needs to do to enter the store.

16
ScenariosUse Case to Scenarios

• In a real-life system, the main scenario is
  called a Happy Day scenario.
• An analysts will typically come up with a Happy
  Day scenario and three to four alternate course
  scenarios for each use case .
• An alternate course use scenario is one which
  explores potential error conditions and alternate
  routes to the happy day

17
ScenariosUse Case to Scenarios

• Now, back to Joe
• At this point, we have
• 1) Defined a context level use case describing
  the scope of the problem.
• 2) Broken this down into three use cases which
  functionally decompose the initial context.
• 3) Defined a scenario for one of those use cases
  which describes a typical actor-system
  interaction.

18
Use CasesScenarios to Sequence Diagrams

• From the scenario we have created, we can create
  a sequence diagram which shows the sequence of
  events described in the scenario. This diagram
  will show the object interactions related to the
  scenario.

19
Use CasesScenarios to Sequence Diagrams

• Sequence Diagram for the Enter Store scenario.

20
Use CasesScenarios to Sequence Diagrams

• Now lets re-visit the scenario and map the
  scenario onto the sequence diagram
• 1) Customer Joe opens the front door of Corner
  Books.
• 2) Customer Joe enters Corner Books.
• 3) Customer Joe closes the front door of Corner
  Books.
• From the first step in the scenario, we
  immediately see the need for a door object and a
  bookstore object (see next slide).

21
Use CasesScenarios to Sequence Diagrams

• 1) Customer Joe opens the front door of Corner
  Books.

22
Use CasesScenarios to Sequence Diagrams

• 1) Customer Joe opens the front door of Corner
  Books.
• Also, from this statement, we see that Joe needs
  to Open the Front Door of the Bookstore.

23
Use CasesScenarios to Sequence Diagrams

• 1) Customer Joe opens the front door of Corner
  Books.
• Now, just to show that there is more than one way
  to solve a simple problem like this (theres that
  property of systems analysis again), an equally
  valid way to model scenario step 1 would look
  like

24
Use CasesScenarios to Sequence Diagrams

• Back to the original anaqlysis..
• Now lets take a look at the second step in the
  scenario
• 2) Customer Joe enters Corner Books.
• From this step, we can add the enter
  interaction from Joe to Corner Books.

25
Use CasesScenarios to Sequence Diagrams

• And finally, the third step
• 3) Customer Joe closes the front door of Corner
  Books.
• From the third step, the sequence diagram is
  finished out.

26
Use CasesScenarios to Sequence Diagrams

• Up to this point, we have
• 1) Defined a context level use case describing
  the scope of the problem.
• 2) Broken this down into three use cases which
  functionally decompose the initial context.
• 3) Defined a scenario for one of those use cases
  which describes a typical actor-system
  interaction.
• 4) Described the object interactions in the
  scenario through the use of a sequence diagram.

27
Class ModelsSequence Diagrams to Class Diagrams

• The next step which needs to be taken in creating
  a model for the system we are analyzing is to
  derive a Class Model from the sequence diagram.

28
Class ModelsSequence Diagrams to Class Diagrams

• From the sequence diagram, we have immediately
  defined two classes. These two classes are
• Bookstore - Required because of the Corner
  Books object.
• Door - Required because of the Front Door
  object.
• Note These two objects come directly out of the
  scenario definition.

29
Class ModelsSequence Diagrams to Class Diagrams

• Our initial class model will look like

The relationship between Bookstore and Door is
required because of the operations open and
close which class Bookstore needs to perform
on class Door.
30
Class ModelsClass Diagram Refinement

• At this point, the class model needs to be
  refined. This can be done by asking some
  questions about the classes which now exist in
  the model.
• 1) Can a door open if it is already open?
• 2) Can a bookstore exist without a door?
• 3) How many doors can a bookstore have?
• 4) When does a bookstore open for customers?
• etc.

31
Class Models Class Diagram Refinement

• Answers to these questions can provide important
  information.
• 1) Can a door open if it is already open?
• A No, it is redundant to open a door after it is
  already open.
• Ramification A door needs to keep track of
  open state.
• 2) Can a bookstore exist without a door?
• A Yes, many bookstores exist open air.
• Ramification A Bookstore and Door have an
  aggregate relationship.

32
Class Models Class Diagram Refinement

• 3) How many doors can a bookstore have?
• A 0 or more.
• Ramification A bookstore can have 0.. doors.
• 4) When does a bookstore open for customers?
• A It depends on what hours the bookstore has set
  as business hours.
• Ramification A bookstore must have an opening
  and closing time for business.

33
Class Models Class Diagram Refinement

• Given the answers to these questions, the class
  model can be further refined to look like

Notice the role name between a bookstore and a
door. A bookstore has a door as an entry.
34
Class Models Class Diagram Refinement

• The initial class diagram would be further
  augmented by performing a similar sequence of
  operations for the other two use cases. As each
  use case is broken down into scenarios, sequence
  diagrams, then class diagrams, the system takes
  on definition and detail.

35
Summary

• Class Diagrams are derived by
• Define and model use cases.
• Create scenarios for each use case.
• Model scenario sequences.
• Define classes a necessary.
• Produce sequence diagrams.
• From scenario sequences
• Derive class relationships.
• Create Class diagrams and refine them by asking
  questions about the relationships between the
  classes.
• Creation of Use Case/Class models is highly
  iterative.