1. Case Study:
Class Extraction

2. 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

3. 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

4. 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

5. 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

6. 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 painting; so remove one of them.
This leaves four candidate entity classes:
Painting Class, Masterpiece Class, Masterwork Class, and Other Painting Class

7. First Iteration of the Initial Class Diagram
Four candidate entity classes:
Painting, Masterpiece, Masterwork, and Other

8. 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

9. Second Iteration of Initial Class Diagram
Figure 12.18

10. 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.

11. Third Iteration of the Initial Class Diagram (contd)
Figure 12.19

12. 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 ?

13. 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

14. Fourth Iteration of Initial Class Diagram
Figure 12.20

15. 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)

16. 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

17. Fifth Iteration of Initial Class Diagram

18. 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

19. Initial Class Diagram Next, let’s add attributes to the class diagram
Later, we’ll be extending classes with operations of that class

20. Fifth Iteration of Initial Class Diagram
Osbert Application Class will contain operation that starts execution of whole software product
Figure 12.22

21. 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

22. The Initial Dynamic Model: The Osbert Oglesby Case Study
Initial statechart

23. The Initial Dynamic Model: The Osbert Oglesby Case Study
The solid circle (top left) represents the initial state
The white circle with the small black circle inside (top right) represents the final state
States other than the initial and final states are represented by rectangles with rounded corners
The arrows represent transitions from state to state

24. 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

25. Initial Main Menu: Osbert Oglesby
Graphical user interface (GUI)
“Point and click”
Figure 12.25

27. 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

28. 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

29. Initial Main Menu: Osbert Oglesby
A GUI needs special software
However, a textual interface runs on all computers

30. Initial Boundary Classes
There are three reports:
The purchases report
The sales report
The future trends report
Content of each report is different
Each report modeled by separate boundary class
So four initial boundary classes :

31. Extracting Control Classes: Osbert Oglesby Case Study
Extract control classes
Each nontrivial computation modeled by a control class
In case study, there are four computations :
Determine maximum price for Masterpiece
Determine maximum price for Masterwork
Determine maximum price for Painting
Determine if there is a new trend in art purchases
There are therefore four initial control classes

32. Initial Control Classes: Osbert Oglesby
There are therefore four initial control classes

34. Refining the Use Cases
Refine our use cases based on class extraction as well as analysis of problem thus far

35. 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

36. 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

37. Third Iteration of Use-Case Diagram

38. 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

39. Use Case Buy a Masterpiece

40. Description of Use Case Buy a Masterpiece

41. 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”

42. 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

43. 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

44. Buy a Masterpiece Use Case
Class diagram (classes that enter into use case)

45. Four Classes Germane to the Use Case
User Interface Class
models user interface
Compute Masterpiece Price Class
models computation of price Osbert should offer
Masterpiece Class
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

46. 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)

47. Buy a Masterpiece Use Case
Scenario (one possible instance of the use case)

48. 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

49. 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 .. .

50. Collaboration Diagram: Buy a Masterpiece
A collaboration diagram (of the realization of the scenario of the use case)

51. 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

52. 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 )

53. 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

54. Buy a Masterpiece Use Case
Sequence diagram equivalent to collaboration diagram

55. Buy a Masterpiece Use Case
Narrow rectangle on a lifeline (dashed vertical line) shows when the relevant object is active

56. 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

57. 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

58. 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

59. 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

60. Summary : Refining Use Cases
Refine use cases using interaction diagrams
From the abstract to the implementable