Slide 12C.50 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005

Slide 12C.51 © The McGraw-Hill Companies, 2005 CHAPTER 12 — Unit C OBJECT-ORIENTED ANALYSIS

Slide 12C.52 © The McGraw-Hill Companies, 2005 Continued from Unit 12B

Slide 12C.53 © The McGraw-Hill Companies, The Initial Class Diagram: The Osbert Oglesby Case Study l The aim of entity modeling step is to extract the entity classes, determine their interrelationships, and find their attributes l Usually, the best way to begin this step is to use the two-stage noun extraction method

Slide 12C.54 © The McGraw-Hill Companies, 2005 Noun Extraction: Osbert Oglesby Case Study l Stage 1: Describe the software 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

Slide 12C.55 © The McGraw-Hill Companies, 2005 Noun Extraction: Osbert Oglesby (contd) l 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

Slide 12C.56 © The McGraw-Hill Companies, 2005 Noun Extraction: Osbert Oglesby (contd) l The nouns are report, effectiveness, process, buying, work of art, selling, information, painting, masterpiece, and masterwork l effectiveness, process and information are abstract nouns and are therefore unlikely to be entity classes l Nouns buying and selling are derived from the verbs “buy” and “sell”  They will probably be operations of some class

Slide 12C.57 © The McGraw-Hill Companies, 2005 Noun Extraction: Osbert Oglesby (contd) l Noun report is much more likely to be a boundary class than an entity class l Noun work of art is just a synonym for painting

Slide 12C.58 © The McGraw-Hill Companies, 2005 First Iteration of the Initial Class Diagram l This leaves four candidate entity classes:  Painting Class, Masterpiece Class, Masterwork Class, and Other Painting Class Figure 12.17

Slide 12C.59 © The McGraw-Hill Companies, 2005 Second Iteration of the Initial Class Diagram l Consider the interrelationships between the entity classes l 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

Slide 12C.60 © The McGraw-Hill Companies, 2005 Second Iteration of Initial Class Diagram (contd) Figure 12.18

Slide 12C.61 © The McGraw-Hill Companies, 2005 l The class diagram does not reflect aspects of the pricing algorithm l 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

Slide 12C.62 © The McGraw-Hill Companies, 2005 l 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  This is modeled in the next slide Third Iteration of the Initial Class Diagram (contd)

Slide 12C.63 © The McGraw-Hill Companies, 2005 Third Iteration of the Initial Class Diagram (contd) Figure 12.19

Slide 12C.64 © The McGraw-Hill Companies, 2005 Fourth Iteration of the Initial Class Diagram l 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 (by the same artist) for which there is an auction record and the painting under consideration for purchase”

Slide 12C.65 © The McGraw-Hill Companies, 2005 Fourth Iteration of Initial Class Diagram (contd) l 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

Slide 12C.66 © The McGraw-Hill Companies, 2005 Fourth Iteration of Initial Class Diagram (contd) Figure 12.20

Slide 12C.67 © The McGraw-Hill Companies, 2005 Fourth Iteration of Initial Class Diagram (contd) l 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)

Slide 12C.68 © The McGraw-Hill Companies, 2005 Fifth Iteration of the Initial Class Diagram l 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) …” l 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

Slide 12C.69 © The McGraw-Hill Companies, 2005 Fifth Iteration of the Initial Class Diagram (contd) Figure 12.21

Slide 12C.70 © The McGraw-Hill Companies, 2005 Initial Class Diagram:Osbert Oglesby (contd) l Why was the first iteration of the class diagram so inadequate?  The Osbert Oglesby case study appears to be a straightforward data-processing application  The one-paragraph description correctly did not incorporate the pricing algorithm l Unfortunately, the algorithmic details turned out to be critical to the class diagram

Slide 12C.71 © The McGraw-Hill Companies, 2005 Initial Class Diagram:Osbert Oglesby (contd) l The first iteration of the class diagram was no good  However, repeated iteration and incrementation led to a reasonable class diagram l This demonstrates the power of the iterative and incremental approach

Slide 12C.72 © The McGraw-Hill Companies, 2005 Initial Class Diagram:Osbert Oglesby (contd) l 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 l The empty rectangle at the bottom of each box will later be filled with the operations of that class

Slide 12C.73 © The McGraw-Hill Companies, 2005 Fifth Iteration of the Initial Class Diagram (contd) Figure 12.22

Slide 12C.74 © The McGraw-Hill Companies, 2005 Fifth Iteration of the Initial Class Diagram (contd) l Osbert Oglesby Application Class will contain the operation that starts execution of the whole software product

Slide 12C.75 © The McGraw-Hill Companies, 2005 Fifth Iteration of the Initial Class Diagram (contd) l 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 l This is also a class diagram  A class diagram depicts classes and their interrelationships; attributes and operations are optional

Slide 12C.76 © The McGraw-Hill Companies, 2005 Fifth Iteration of the Initial Class Diagram (contd) Figure 12.23

Slide 12C.77 © The McGraw-Hill Companies, The Initial Dynamic Model: The Osbert Oglesby Case Study l Dynamic modeling is the third step in extracting the entity classes l A statechart is constructed that reflects all the operations performed by or to the software product (rather than by or to each class; justification is given later) l The operations are determined from the scenarios

Slide 12C.78 © The McGraw-Hill Companies, 2005 Initial Dynamic Model: Osbert Oglesby (contd) l Initial statechart Figure 12.24

Slide 12C.79 © The McGraw-Hill Companies, 2005 Initial Dynamic Model: Osbert Oglesby (contd) l The solid circle (top left) represents the initial state l The white circle with the small black circle inside (top right) represents the final state l States other than the initial and final states are represented by rectangles with rounded corners l The arrows represent transitions from state to state

Slide 12C.80 © The McGraw-Hill Companies, 2005 Initial Dynamic Model: Osbert Oglesby (contd) l 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

Slide 12C.81 © The McGraw-Hill Companies, 2005 Figure Initial Main Menu: Osbert Oglesby l Graphical user interface (GUI)  “Point and click”

Slide 12C.82 © The McGraw-Hill Companies, 2005 Dynamic Modeling (contd) l In the object-oriented paradigm, there is a dynamic model for each class, rather than for the system as a whole, as in this case study  + In this case study, objects in this software product never move from one class to another class l Accordingly, a dynamic model for the software product as a whole is appropriate

Slide 12C.83 © The McGraw-Hill Companies, Extracting the Boundary Classes: The Osbert Oglesby Case Study l It is usually easy to extract boundary classes  Each input screen, output screen, and printed report is generally modeled by a boundary class l One screen should be adequate for all four Osbert Oglesby use cases l Thus there is one initial boundary class  User Interface Class

Slide 12C.84 © The McGraw-Hill Companies, 2005 Initial Main Menu: Osbert Oglesby (contd) l A GUI needs special software  However, a textual interface runs on all computers Figure 12.26

Slide 12C.85 © The McGraw-Hill Companies, 2005 Initial Boundary Classes: Osbert Oglesby (contd) l There are three reports:  The purchases report  The sales report  The future trends report l The content of each report is different  Each report therefore has to be modeled by a separate boundary class

Slide 12C.86 © The McGraw-Hill Companies, 2005 Initial Boundary Classes: Osbert Oglesby (contd) l There are therefore four initial boundary classes Figure 12.27

Slide 12C.87 © The McGraw-Hill Companies, 2005 Continued in Unit 12D