The Osbert Oglesby Case Study
From Object-Oriented and Classical
Software Engineering
By Stephen R. Schach
©2005 The McGraw-Hill Companies
Initial Understanding of the Domain
• Osbert Oglesby, Art Dealer, needs a software
product to assist him in buying and selling
paintings
• Obtaining domain knowledge is the first step
• Osbert is interviewed to obtain the relevant
information
• This information is put into a glossary
Glossary
Figure 6.3
Initial Business Model
• Osbert wants an software product, running on his
laptop computer, that will
– Determine the maximum price he should pay for a
painting
– Detect new trends in the art market as soon as possible
• To do this, the software product needs to keep a
record of all purchases and all sales
Initial Business Model (contd)
• Currently, Osbert produces reports of annual
sales and purchases by hand
– At only a small additional cost, the software product can
also print these two reports on demand
• Osbert has three business activities:
– He buys paintings
– He sells paintings
– He produces reports
• These are the initial use cases
Initial Business Model: Use Cases
Buy a Painting use case
Figure 6.4
Initial Business Model: Use Cases (contd)
Sell a Painting use case
Figure 6.5
Initial Business Model: Use Cases (contd)
Produce a Report use case
Figure 6.6
Initial Business Model: Use Cases (contd)
• For conciseness, all three use cases are
combined into a use-case diagram
Figure 6.7
Initial Business Model: Use Cases (contd)
• The only person who uses the current (manual)
software product is Osbert
– Osbert is therefore an actor in all three use cases
• The customer may initiate the Buy a Painting or the
Sell a Painting use case
• The customer plays a critical part in both use
cases by providing data entered into the software
product by Osbert
– The customer is therefore an actor in both these use
cases
Initial Business Model: Use Cases (contd)
• Next, the use cases have to be annotated – what
actually happens there
• Initially we just write a brief description
• Later we will add a full step-by-step description
Initial Business Model: Use Cases (contd)
• Buy a Painting use case
Figure 6.8
Initial Business Model: Use Cases (contd)
• Sell a Painting use case
Figure 6.9
Initial Business Model: Use Cases (contd)
• Produce a Report use case
Figure 6.10
Initial Requirements
• The initial business model (the three use cases)
shows how Osbert currently does business
• Decide which of these use cases are also
requirements of the software product to be built
– Clearly, all three are requirements
• Refine the resulting initial requirements
– The descriptions of the use cases have to be refined
Initial Requirements (contd)
Buy a Painting use case
Figure 6.11
Initial Requirements (contd)
Sell a Painting use case
Figure 6.12
Initial Requirements (contd)
Produce a Report use case
Figure 6.13
Initial Requirements (contd)
• All three descriptions are still vague
– A consequence of the iterative nature of the Unified
Process
– For example, the algorithm details are irrelevant at this
time
• Basic principle: Defer all details to as late as
possible
– This will simplify the inevitable changes of the next
iteration
Continuing the Requirements Workflow
• More details of each use case are needed now
• First consider use cases
– Buy a Painting, and
– Sell a Painting
• To refine the descriptions, determine what
attributes need to be input when a painting is
bought and when a painting is sold
Attributes
• Attributes when buying a painting include:
– Title of work, name of artist, date of painting,
classification, medium, purchase price, name and
address of seller
• Attributes when selling a painting are:
– Date of sale, name of buyer, address of buyer, actual
selling price
Continuing the Requirements Workflow
• Now the algorithm for computing the maximum
purchase price is considered
• Classify the painting as a
– Masterpiece
– Masterwork, or
– Other painting
Maximum Price for a Masterpiece
• Scan worldwide auction records over the past 25
years for the most similar work by the same artist
• Use the auction purchase price of the most similar
work as the base price
• The maximum purchase price is found by adding
8.5 percent to the base price, compounded
annually, for each year since that auction
Maximum Price for a Masterwork
• Compute the maximum purchase price as if the
painting were a masterpiece by the same artist
• If the picture was painted in the 21st century,
multiply this figure by 0.25
• Otherwise, multiply it by (21 – c)/(22 – c), where c
is the century in which the work was painted
(12 < c < 21)
Maximum Price for an Other Painting
• Measure the dimensions of the canvas
• The maximum purchase price is then given by the
formula F A, where
– F is a constant for that artist (fashionability coefficient),
and
– A is the area of the canvas in square centimeters
• If there is no fashionability coefficient for that artist,
Osbert will not buy the painting
Coefficient of Similarity
• For a masterpiece or masterwork, the coefficient of similarity between two paintings is computed as follows: – Score 1 for a match on medium, otherwise 0
– Score 1 for a match on subject, otherwise 0
– Add these two numbers, multiply by the area of the smaller painting, and divide by the area of the larger
– The resulting number is the coefficient of similarity
• If the coefficient of similarity between the painting under consideration and all the paintings in the file of auction data is zero, then Osbert will not buy that masterwork or masterpiece
Fashionability Coefficients
• The software product must include a list of artists
and their corresponding F values
• The value of F can vary from month to month,
depending on the current fashionability of an artist
• Osbert determines the value of F on the basis of
his knowledge and experience
– He changes the value if prices for work by an artist
increase or decrease
Auction Data
• The software product must utilize information on
worldwide auction sales of masterpieces over the
past 25 years
• Each month Osbert receives a CD with updated
worldwide auction prices; these prices are never
modified by Osbert
Updated Use Cases
• The use-case descriptions must reflect all this
new information
Updated Use Cases
• The description of the Sell a Painting use case:
Figure 6.15
Updated Use Cases
Figure 6.14
• The description of the
Buy a Painting use case:
Reports
• Now consider the Produce a Report use case
• There are three reports:
– Purchases during the past year
– Sales during the past year
– Detection of new trends
• Sample reports show Osbert’s needs are as
follows (question marks in the first or last name of
artist, or in the title or date of the work are to be
included in all reports):
Report of Purchases during the Past Year
• A report is needed to display all the paintings
purchased during the past year
– The average ratio of the purchase price to the suggested
maximum price is required at the end of the report
Figure 6.16
Report of Sales during the Past Year
• A report is needed to display all the paintings sold
during the past year
– The average ratio of the actual selling price to the
target selling price is required at the end of the report
Figure 10.17
Report of Trends during the Past Year
• A report showing artists whose works Osbert has
sold at a price that has exceeded the target
selling price in every instance during the past year
– To appear in this report, at least two of the artist’s
works must have been sold by Osbert during that
period
Figure 6.18
Updated Use Cases:
Figure 6.19
• Again, need to update
the use case
• The description of the
Produce a Report use
case:
The Test Workflow
• There is a serious omission
– The use case for updating a fashionability coefficient
has been overlooked
• Missing use case Update a Fashionability Coefficient
Figure 6.20
The Test Workflow
• The description of the use case Update a
Fashionability Coefficient
Figure 6.21
Second Iteration of the Use-Case Diagram
• Incorporate all four use cases
Figure 6.22
The Test Workflow
• A fault was detected
– There was a missing use case
– The existing artifacts did not need to be changed
• Two additional artifacts had to be added
– A use case, and
– Its description
Extended Scenario of Use Case Buy a Masterpiece
• Normal and exception scenarios can be combined
into an extended scenario
Figure 12.16
Stereotypes
• In the «extend» relationship, one use case is a
variation of the standard use case
– Example: A separate use case to model the situation
of the potential seller of a painting turning down
Osbert’s offer
– The open-headed arrow goes in the other direction
Figure 16.13
The Analysis Workflow
• There are three types of classes:
• Entity classes
• Boundary classes
• Control classes
UML Notation for These Three Class Types
• Stereotypes (extensions of UML)
Figure 12.1
The Analysis Workflow
• Entity class
– Models long-lived information
• Examples:
– Account Class
– Painting Class
The Analysis Workflow (contd)
• Boundary class
– Models the interaction between the product and the
environment
– A boundary class is generally associated with input or
output
• Examples:
– Purchases Report Class
– Sales Report Class
The Analysis Workflow (contd)
• Control class
– Models complex computations and algorithms
• Examples:
– Compute Masterpiece Price Class
– Compute Masterwork Price Class
– Compute Other Painting Price Class
Identifying Entity Classes: Noun Extraction
• Stage 1: Describe the software product in one paragraph
• Stage 2: Identify the 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
• Remove those that are general, derived from verbs, etc.
• This leaves four candidate entity classes: – Painting Class, Masterpiece Class, Masterwork
Class, and Other Painting Class
Second Iteration of the Initial Class Diagram
• Consider the interrelationships between the 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
Second Iteration of Initial Class Diagram (contd)
Figure 7.18
• The class diagram does not reflect aspects of the
pricing algorithm
• When dealing with a masterwork
– “The software product first computes the maximum
purchase price as if it were a masterpiece by the same
artist”
Third Iteration of the Initial Class Diagram
• That is, a masterwork has to have all the
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
Third Iteration of the Initial Class Diagram (contd)
Third Iteration of the Initial Class Diagram (contd)
Figure 7.19
Fourth Iteration of the Initial Class Diagram
• Another aspect of the pricing algorithm that is not
reflected in the current class diagram is
– “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”
Fourth Iteration of Initial Class Diagram (contd)
• Auctioned Painting Class is needed to make
these comparisons
– An auctioned painting must be a subclass of Painting
Class
– But a painting previously been sold at an auction
somewhere in the world has nothing to do with
paintings currently on display for sale in Osbert’s
gallery
• So 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)
Fourth Iteration of Initial Class Diagram (contd)
Figure 7.20
Fifth Iteration of the Initial Class Diagram
• A third aspect of the maximum price algorithm
that has not yet been modeled is fashionability
– “The software product computes the maximum
purchase price from the formula F A , where F is a
constant for that artist (fashionability coefficient) …”
• Fashionability Class is needed
– A painting of Other Painting Class can then use the
instance of Fashionability Class for that artist to
compute the maximum price that Osbert should offer to
pay
Fifth Iteration of the Initial Class Diagram (contd)
Figure 7.21
Initial Class Diagram (contd)
• Finally, we add the attributes of each class to the
class diagram
– For the Osbert Oglesby case study, the result is shown
on the next slide
• The empty rectangle at the bottom of each box
will later be filled with the operations of that class
Fifth Iteration of the Initial Class Diagram (contd)
Figure 7.22
Fifth Iteration of the Initial Class Diagram (contd)
• Osbert Oglesby Application Class will contain
the operation that starts execution of the whole
software product
• The next slide shows the fifth iteration of the initial
class diagram, without the attributes, but explicitly
reflecting the stereotypes
– All eight classes in that figure are entity classes
• This is also a class diagram
– A class diagram depicts classes and their
interrelationships; attributes and operations are optional
Fifth Iteration of the Initial Class Diagram (contd)
Figure 7.23
The Initial Dynamic Model
• Dynamic modeling is the third step in extracting
the entity classes
• A statechart is constructed that reflects all the
operations performed by or to the software
product
• The operations are determined from the scenarios
Initial Dynamic Model
• Initial statechart
Figure 7.24
Extracting the Boundary Classes
• It is usually 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 Osbert
Oglesby use cases
• Thus there is one initial boundary class
– User Interface Class
Figure 7.25
Initial Main Menu
• Graphical user interface (GUI)
– “Point and click”
Initial Boundary Classes
• There are three reports:
– The purchases report
– The sales report
– The future trends report
• The content of each report is different
– Each report therefore has to be modeled by a separate
boundary class
• There are therefore four initial boundary classes
in total
Extracting the Control Classes
• It is also usually easy to extract control classes – Each nontrivial computation is generally modeled by a
control class
• In the case study there are four computations – Determining the maximum price that Osbert should
offer for a • Masterpiece
• Masterwork, or
• Other painting
– Determining if there is a new trend in art purchases
• There are therefore four initial control classes
Refining the Use Cases
• The pricing algorithm treats the three types of
paintings differently
• Use case Buy a Painting must therefore be refined
into three separate use cases
– Buy a Masterpiece
– Buy a Masterwork
– Buy Other Painting
• Use case Produce a Report also needs to be refined – The purchases report and the sales report use simple
data extraction — the future trends report involves computation
– All three reports use their own boundary classes
• For both these reasons, the Produce a Report use case must be refined into three use cases – Produce a Purchases Report
– Produce a Sales Report
– Produce a Future Trends Report
Refining the Use Cases
Third Iteration of the Use-Case Diagram
Figure 7.29
• Implications for the remaining UML diagrams
include:
– The description of the Buy a Painting use case must be
split into three separate descriptions
– The description of the Produce a Report use case must
be split into three separate descriptions
Refining the Use Cases
Use Case Buy a Masterpiece
Figure 7.30
Description of Use Case Buy a Masterpiece
Figure 7.31
Realization of Buy a Masterpiece Use Case
• Class diagram (classes that enter into the use case)
Figure 7.32
The Four Classes That Enter into This Use Case
• User Interface Class
– This class models the user interface
• Compute Masterpiece Price Class
– This class models the computation of the price Osbert
should offer
• Masterpiece Class
– The computation involves comparing the masterpiece
being considered with the masterpieces that have been
previously auctioned
• Auctioned Painting Class
– These masterpieces are all instances of Auctioned
Painting Class
Buy a Masterpiece Use Case (contd)
• The Seller does not interact directly with the
software product
– Instead, the Seller provides data that Osbert enters into
the software product
• This is indicated in the note (the rectangle with the
top right-hand corner turned over)
– There is a dashed line from the note to the item to
which it refers, the Seller in this case
Buy a Masterpiece Use Case (contd)
• A collaboration diagram (of the realization of the
scenario of the use case)
Figure 12.34
Buy a Masterpiece Use Case (contd)
• The flow of events of the collaboration diagram of
the realization of the scenario of the use case
Figure 12.35
Buy a Masterpiece Use Case (contd)
• Sequence diagram equivalent to the collaboration
diagram (of the realization of the scenario of the
use case)
Figure 12.36
Buy a Masterpiece Use Case (contd)
• The sequence diagram shows that every
message of the scenario involves either
– The instance of the user interface class : User
Interface Class or
– The instance of the control class : Compute
Masterpiece Price Class
Buy a Masterpiece Use Case (contd)
• It also shows that every transfer of information
from object A to object B is eventually followed by
a transfer in the reverse direction
• These two facts are also true in the fully
equivalent collaboration diagram, but are not as
obvious in that format
Alternative Sequence Diagram
• There are
variants of
the use case,
e.g. seller
rejects offer
• Example:
– Dynamic
creation
followed by
destruction
of an object
Figure 16.14
Buy a Masterwork Use Case (contd)
• Class diagram (classes that enter into the use case)
Figure 12.37
12.15.3 Buy Other Painting Use Case
• Class diagram
Figure 12.39
Modifying the Main Menu
• The main menu must reflect buying the three
different types of painting explicitly
• Buy a Painting must be replaced by
– Buy a Masterpiece,
– Buy a Masterwork, and
– Buy Other Painting
Modifying the Main Menu (contd)
• The revised screen is generated by
: User Interface Class
Figure 12.40
• Class diagram
Sell a Painting Use Case
Figure 12.42
Produce a Purchases Report Use Case
• Class diagram
Figure 12.43
Produce a Sales Report Use Case
• Class diagram
Figure 12.44
• Class diagram
Produce a Future Trends Report Use Case
Figure 12.45
• Class diagram
Modify a Fashionability Coefficient Use Case
Figure 12.46
Incrementing the Class Diagram
• In the course of realizing the various use cases
– Interrelationships between classes become apparent
• Accordingly, we now combine the realization class
diagrams
Combining the Realization Class Diagrams
Figure 7.47
• Fifth iteration + realization class diagram
Sixth Iteration of the Class Diagrams
Figure 7.48
Class Diagram with Attributes
Figure 13.14
Assigning Methods to Classes
• Example: setTitle, getTitle
– From the inheritance tree (two slides back), these
methods should be assigned to Painting Class
– So that they can be inherited by all the subclasses of
Painting Class
• Assigning the other methods is equally
straightforward
Black-Box Test Cases
• Test cases
derived from
equivalence
classes and
boundary value
analysis
Figure 9.13a
Black-Box Test Cases
(contd)
• Test cases
derived from
equivalence
classes and
boundary value
analysis (contd)
Figure 9.13b
Black-Box Test Cases (contd)
Functional
testing test
cases
Figure 9.14