The Osbert Oglesby Case Study

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


Produce a Report use case

Figure 6.6


• For conciseness, all three use cases are

combined into a use-case diagram

Figure 6.7


• 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


• 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


• 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


• Buy a Painting use case

Figure 6.8


• Sell a Painting use case

Figure 6.9


• 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



Figure 6.12


Produce a Report use case

Figure 6.13


• 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


Figure 7.22


• 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


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


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


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


• A collaboration diagram (of the realization of the

scenario of the use case)

Figure 12.34


• The flow of events of the collaboration diagram of

the realization of the scenario of the use case

Figure 12.35


• Sequence diagram equivalent to the collaboration

diagram (of the realization of the scenario of the

use case)

Figure 12.36


• 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


• 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

Documents

The Osbert Oglesby Case Study