Case Study:
Class Extraction
1
The Osbert Oglesby Case Study

To get Initial Class Diagram :

The aim of entity modeling step is to :




extract entity classes,
determine their interrelationships,
and find their attributes
Simple (yet good) way to begin this step is to
use the two-stage noun extraction method
2
Noun Extraction: Osbert
Oglesby Case Study

Stage 1: Describe product in one paragraph:

Reports are to be generated in order to improve
the effectiveness of the decision-making
process for buying works of art. The reports
contain buying and selling information about
paintings, which are classified as masterpieces,
masterworks, and other paintings
3
Noun Extraction: Osbert Oglesby

Stage 2: Identify nouns in this paragraph :

Reports are to be generated in order to improve
the effectiveness of the decision-making
process for buying works of art. The reports
contain buying and selling information about
paintings, which are classified as masterpieces,
masterworks, and other paintings
4
Noun Extraction: Osbert Oglesby

The nouns are :


report, effectiveness, process, buying, work of art, selling,
information, painting, masterpiece, masterwork
Next let’s remove some candidates :

effectiveness, process and information are abstract nouns and are
therefore unlikely to be entity classes

Nouns buying and selling are derived from the verbs “buy” and
“sell”; so probably will be operations of some class
5
Noun Extraction: Osbert
Oglesby (contd)

The nouns are :

Report , effectiveness, process, buying, work of
art, selling, information, painting, masterpiece,
masterwork

Noun report is more likely to be a boundary
class than an entity class
Noun work of art is just a synonym for

This leaves four candidate entity classes:

painting; so remove one of them.

Painting Class, Masterpiece Class,
Masterwork Class, and Other Painting Class
6
Second Iteration of Initial
Class Diagram


Consider interrelationships between entity classes
A masterpiece is a specific type of painting, and so
is a masterwork and an “other painting” :


Painting Class is therefore the base class
Masterpiece Class, Masterwork Class, and Other
Painting Class are subclasses of that base class
8
Second Iteration of Initial
Class Diagram
Figure 12.18
9
Third Iteration of Initial Class
Diagram


Class diagram may not reflect aspects of pricing
algorithm well ?
When dealing with a masterwork :


“The software product first computes the maximum
purchase price as if it were a masterpiece by the
same artist”
Conclude : masterwork should have all
attributes of a masterpiece (so that its
maximum purchase price can be computed as if
it were a masterpiece) and, in addition, it may
have attributes of its own.
10
Third Iteration of the Initial
Class Diagram (contd)
Figure 12.19
11
Fourth Iteration of Initial Class Diagram

Another aspect of pricing algorithm not
reflected in the current class diagram :


“The software product computes the coefficient
of similarity between each painting for which
there is an auction record and the painting
under consideration for purchase”
What if anything should we change ?
12
Fourth Iteration of Initial Class Diagram

Need Auctioned Painting Class to make
these comparisons


Maybe, an auctioned painting must be a subclass of
Painting Class ?
But a painting previously been sold at an
auction somewhere else has nothing to do with
paintings currently on display for sale in
Osbert’s gallery
13
Fourth Iteration of Initial Class Diagram
Figure 12.20
14
Fourth Iteration of Initial Class Diagram

So now we have that an instance of Painting
Class is either :


A painting that Osbert has bought (an instance of
Gallery Painting Class), or
A painting sold at some auction (an instance of
Auctioned Painting Class)
15
Fifth Iteration of Initial Class Diagram

Third aspect of maximum price algorithm not
yet modeled is fashionability :


“compute maximum purchase price from formula F 
A , where F is a constant for that artist
(fashionability coefficient) …”
Fashionability or Artist Class is needed :

For a painting of Other Painting Class, we then
can then use the artist instance of Fashionability
Class to compute maximum price that Osbert
should offer to pay
16
Fifth Iteration of Initial Class Diagram
17
Initial Class Diagrams ?

Why was the first iteration of class
diagram so inadequate?



One-paragraph description correctly did not
incorporate the pricing algorithm
But algorithmic details turned out to affect
class diagram
Repeated iteration and incrementation
will lead to a reasonable class diagram
18
Initial Class Diagram


Next, let’s add attributes to the
class diagram
Later, we’ll be extending classes
with operations of that class
19
Fifth Iteration of Initial Class Diagram
Osbert
Application
Class will
contain operation
that starts
execution of
whole software
product
Figure 12.22
20
The Initial Dynamic Model:
The Osbert Oglesby Case Study



Dynamic modeling is third step in
extracting entity classes
A statechart is constructed that
reflects all operations performed
by or to the software product
The operations are determined
from the scenarios
21
The Initial Dynamic Model:
The Osbert Oglesby Case Study

Initial statechart
22
The Initial Dynamic Model:
The Osbert Oglesby Case Study

In state Osbert Oglesby Event
Loop, one of five events can occur:





buy painting selected
sell painting selected
print report selected
update fashionability selected
quit selected
24
Initial Main Menu:
Osbert Oglesby

Graphical user interface (GUI)

“Point and click”
Figure 12.25
25
26
Dynamic Modeling

In object-oriented paradigm, there is
a dynamic model for each class,
rather than for the system as a
whole :


However, objects in this product never
move from one class to another class
Accordingly, a dynamic model for
software product as a whole is
appropriate
27
Extracting the Boundary Classes:
The Osbert Oglesby Case Study

It is easy to extract boundary classes



Each input screen, output screen, and
printed report is generally modeled by a
boundary class
One screen should be adequate for all
four use cases
Thus one initial boundary class

User Interface Class
28
Initial Boundary Classes

There are three reports:




Content of each report is different


The purchases report
The sales report
The future trends report
Each report modeled by separate boundary class
So four initial boundary classes :
30
Extracting Control Classes:
Osbert Oglesby Case Study

Extract control classes


In case study, there are four computations :





Each nontrivial computation modeled by a control class
Determine
Determine
Determine
Determine
maximum price for Masterpiece
maximum price for Masterwork
maximum price for Painting
if there is a new trend in art purchases
There are therefore four initial control classes
31
33
Refining the Use Cases

Refine our use cases based on
class extraction as well as analysis
of problem thus far
34
Refining the Use Cases:
Osbert Oglesby


Pricing algorithm treats three types of
paintings differently
Use case Buy a Painting therefore
refined into three separate use cases :



Buy a Masterpiece
Buy a Masterwork
Buy Other Painting
35
Refining the Use Cases:
Osbert Oglesby

Use case Produce a Report also needs to be
refined




Purchases and sales report both use simple data
extraction
Future trends report involves computation
All three reports use their own boundary classes
Thus Produce a Report use case refined into three
use cases :



Produce a Purchases Report
Produce a Sales Report
Produce a Future Trends Report
36
Third Iteration of Use-Case
Diagram
37
Refining the Use Cases:
Osbert Oglesby

Implications for remaining UML diagrams :


Buy a Painting use case must be split into three
separate descriptions
Produce a Report use case must be split into three
separate descriptions
38
Use Case Buy a
Masterpiece
39
Description of Use Case
Buy a Masterpiece
40
Use-Case Realization


The process of extending and refining use
cases is called use-case realization
That is, we aim to flesh them out in more
detail and to make them “real”
41
Use-Case Realization

The realization of a specific scenario of a use case
is depicted using some interaction diagram :


either a sequence diagram
or a collaboration diagram
42
Use-Case Realization

Consider use case




Buy a Masterpiece
Thus far, we have only English description of use
cases
Now, let’s make it concrete.
First, consider what classes involved in use case
43
Buy a Masterpiece Use
Case

Class diagram (classes that enter into use case)
44
Four Classes Germane to the Use Case

User Interface Class


Compute Masterpiece Price Class


models computation of price Osbert should offer
Masterpiece Class


models user interface
The computation involves comparing the masterpiece being
considered with masterpieces that have been previously
auctioned
Auctioned Painting Class

These masterpieces are all instances of Auctioned Painting
Class
45
Buy a Masterpiece
Use Case

Seller does not interact directly with
software


Instead, Seller provides data that
Osbert enters into the software product
This is indicated in the note (rectangle
with top right-hand corner turned over)
46
Buy a Masterpiece Use
Case

Scenario (one possible instance of the use case)
47
Buy a Masterpiece Use
Case


An executing software product uses
objects, not classes
Example:


A specific masterpiece is not represented by
Masterpiece Class but rather by an object,
a specific instance of Masterpiece Class
Such an object is denoted in UML by
: Masterpiece Class
48
Buy a Masterpiece Use
Case

A class diagram shows the classes in the use case
and their relationships



It does not show the objects
Nor the sequence of messages as they are sent from
object to object
Something more is needed .. .
49
Collaboration Diagram:
Buy a Masterpiece

A collaboration diagram (of the realization of
the scenario of the use case)
50
Buy a Masterpiece Use
Case


Osbert will not approve the specification
document unless he understands it
Accordingly, a written description of the
collaboration diagram is needed

The flow of events
51
Buy a Masterpiece Use
Case

Express in words the flow of events of the
collaboration diagram (of the realization of
scenario of the use case )
52
2 Types of Interaction Diagrams

UML supports two different types of interaction
diagrams :



Collaboration diagram
Sequence diagram
Both contain the same information (events
passed among objects or sequences over
time), but displayed in different ways
53
Buy a Masterpiece Use
Case

Sequence diagram equivalent to collaboration diagram
54
Notice: Buy a Masterpiece Use Case

Sequence diagram shows that every
message of scenario involves either :



instance of user interface class : User
Interface Class or
instance of control class : Compute
Masterpiece Price Class
Every transfer of information from object A
to object B is eventually followed by a
transfer in the reverse direction
56
2 Types of Interaction Diagrams

Software engineers (you) can choose
whether to use :



A sequence diagram, or
A collaboration diagram, or
Both
for each scenario
57
Interaction Diagrams : pros
and cons ?

Sequence versus collaboration diagram ?

sequence diagram :



shows flow of messages and their order unambiguously
Superior when transfer of information is focus of attention
collaboration diagram :


similar to a class diagram
more useful when developers concentrate on classes
58
Buy a Masterpiece Use
Case

The seven previous figures depict different
aspects of the use case Buy a Masterpiece :



They use different notations
Provide different levels of detail of same activity
Why do we construct so many related artifacts?

We examine this one activity from a variety of
different perspectives to learn enough about it to
ensure that the analysis workflow will be correct
59
Summary : Refining Use Cases

Refine use cases using
interaction diagrams

From the abstract to the
implementable
60