case study: class extraction

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

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

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.

Third Iteration of Initial Class Diagram

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


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


Figure 12.20

15


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


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


Figure 12.22

Osbert Application Class will contain operation that starts execution of whole software product

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


Initial statechart

24


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

25Figure 12.25

Initial Main Menu: Osbert Oglesby

Graphical user interface (GUI) “Point and click”

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

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

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

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

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


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


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


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


Scenario (one possible instance of the use case)

48


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


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


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


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


Sequence diagram equivalent to collaboration diagram

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


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

case study: class extraction

Documents