Osbert Oglesby Case Study

l

Osbert Oglesby, Art Dealer, needs an information system 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 (see next slide)

l

l

l

Glossary: Osbert Oglesby Case Study

1

Init. Business Model: Osbert Oglesby Case Study
l

Osbert wants an information system, 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

l

To do this, the information system needs to keep a record of all purchases and all sales Currently, Osbert produces reports of annual sales and purchases by hand
– At only a small additional cost, the information system can also print these two reports on demand

l

Init. Business Model: Osbert Oglesby Case Study
l

Osbert wants an information system that can
– Compute the highest price he should pay for a painting; and – Detect new art trends

l

Osbert needs an information system that can also
– Provide reports on purchases and sales

l

It is vital to determine the client’s needs up front, and not after the information system has been delivered

2

Init. Business Model: Osbert Oglesby Case Study
l

Osbert has three business activities:
– He buys paintings – He sells paintings – He produces reports

Init. Business Model: Osbert Oglesby Case Study
l

Buy a Painting use case

3

Init. Business Model: Osbert Oglesby Case Study
l

Sell a Painting use case

Init. Business Model: Osbert Oglesby Case Study
l

Produce a Report use case

4

Business Model: Osbert Oglesby Case Study l The only person who uses the current (manual) information system is Osbert – Osbert is therefore an actor in all three use cases l 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 information system by Osbert – The customer is therefore an actor in both these use cases l 5 .Init. Business Model: Osbert Oglesby Case Study l For conciseness. all three use cases are combined into a use-case diagram Init.

Business Model: Osbert Oglesby Case Study l Buy a Painting use case 6 .Init. the use cases have to be annotated Here are the initial use-case descriptions l Init. Business Model: Osbert Oglesby Case Study l Next.

Business Model: Osbert Oglesby Case Study l Sell a Painting use case Init.Init. Business Model: Osbert Oglesby Case Study l Produce a Report use case 7 .

Initial Requirements: Osbert Oglesby Case Study l 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 information system to be built – Clearly. all three are requirements l l Refine the resulting initial requirements – The descriptions of the use cases have to be refined Initial Requirements: Osbert Oglesby l Buy a Painting use case 8 .

Initial Requirements: Osbert Oglesby (contd) l Sell a Painting use case Initial Requirements: Osbert Oglesby (contd) l Produce a Report use case 9 .

Initial Requirements: Osbert Oglesby (contd) l All three descriptions are still unclear – A consequence of the iterative nature of the Unified Process – For example. and – Sell a Painting l l To refine the descriptions. determine what attributes need to be input when a painting is bought and when a painting is sold 10 . the algorithm details are irrelevant at this time l Basic principle: Defer all details to as late as possible – This will simplify the inevitable changes of the next iteration Requirements Workflow: Osbert Oglesby l More details of each use case are needed now First consider use cases – Buy a Painting.

classification. address of buyer.Attributes: Osbert Oglesby Case Study l Attributes when buying a painting include: – Title of work. actual selling price Requirements Workflow: Osbert Oglesby l Now the algorithm for computing the maximum purchase price is considered Classify the painting as a – Masterpiece – Masterwork. date of painting. or – Other painting l 11 . name of buyer. name and address of seller l Attributes when selling a painting are: – Date of sale. purchase price. medium. name of artist.

and divide by the area of the larger – The resulting number is the coefficient of similarity 12 . the coefficient of similarity between two paintings is computed as follows: – Score 1 for a match on medium. where – F is a constant for that artist (fashionability coefficient). Osbert will not buy the painting Coefficient of Similarity: Osbert Oglesby l For a masterpiece or masterwork.Maximum Price for an Other Painting l Measure the dimensions of the canvas The maximum purchase price is then given by the formula F × A. multiply by the area of the smaller painting. otherwise 0 – Score 1 for a match on subject. and – A is the area of the canvas in square centimeters l l If there is no fashionability coefficient for that artist. otherwise 0 – Add these two numbers.

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 l l 13 .Coefficient of Similarity: Osbert Oglesby (contd) l 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: Osbert Oglesby l The information system must include a list of artists and their corresponding F values The value of F can vary from month to month.

these prices are never modified by Osbert l Updated Use Cases : Osbert Oglesby Case Study l The use-case descriptions must reflect this information 14 .Auction Data: Osbert Oglesby Case Study l The information system must utilize information on auction sales of masterpieces over the past 25 years worldwide Each month Osbert receives a CD with updated worldwide auction prices.

Updated Use Cases : Osbert Oglesby Case Study l The description of the Sell a Painting use case: Reports for the Osbert Oglesby Case Study l There are three reports: – Purchases during the past year – Sales during the past year – Detection of new trends l 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): 15 .

Report of Purchases during the Past Year l 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 Report of Sales during the Past Year l 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 16 .

Report of Trends during the Past Year l 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. incorporating the details listed above 17 . at least two of the artist’s works must have been sold by Osbert during that period Updated Use-Case Description: Produce a Report l The update the description of the Produce a Report use case.

It Ain’t Over Till it’s Over l There is a serious omission – The use case for updating a fashionability coefficient has been overlooked l Missing use case Modify a Fashionability Coefficient Use-Case Modify a Fashionability Coefficient l Use-case description 18 .

Second Iteration of Use-Case Diagram l Incorporate all four use cases Initial Functional Model: Osbert Oglesby 19 .

Scenario of Use Case Buy a Painting Scenario of Use Case Buy a Painting (contd) l This is a normal scenario There are six paragraphs in the scenario – Only four of them are numbered – The two unnumbered sentences » “Osbert wishes to buy a masterpiece” and » “Osbert makes an offer below the maximum purchase price—the offer is accepted by the seller” l have nothing to do with the interaction between Osbert and the information system – These unnumbered paragraphs are essentially comments 20 .

Second Scenario of Use Case Buy a Painting l This is an exception scenario – It models an interaction that is not “normal” Third Scenario of Use Case Buy a Painting l This is another exception scenario 21 .

and » The use cases 22 .Normal and Exception Scenarios l Normal and exception scenarios can be combined into an extended scenario Initial Functional Model (contd) l The systems analysis team investigates as many normal and exception scenarios of each use case as time permits – To get the deepest possible understanding of » The domain » The business model.

Fifth Iteration of the Initial Class Diagram (contd) Initial Dynamic Model: Osbert Oglesby l Initial statechart 23 .

update a fashionability coefficient. sell a painting. one of five events can occur: – Osbert can choose one of five options: buy a painting. or quit l These possibilities are indicated by the five events: – – – – – buy painting selected sell painting selected print report selected update fashionability selected quit selected 24 . print a report.Initial Dynamic Model: Osbert Oglesby (contd) l 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 – Example: The arrow from the initial state to the state labeled Osbert Oglesby Information System Loop l l l Initial Dynamic Model: Osbert Oglesby (contd) l In state Osbert Oglesby Information System Loop.

Initial Dynamic Model: Osbert Oglesby l The initial main menu in the target Osbert Oglesby information system Initial Dynamic Model: Osbert Oglesby (contd) l Suppose that Osbert clicks on Buy a painting in the menu – The event buy painting selected has now occurred – The system moves from its current state. or other painting 25 . to the state Buying a Painting l In Buying a Painting state. Osbert Oglesby Information System Loop. Osbert can – Buy a masterpiece. masterwork.

Osbert performs one of the operations supported by that state l This continues until Osbert clicks on option Quit while the system is in state Oglesby Information System Loop – At this time the information system enters the final state (represented by the white circle containing the small black circle) – This terminates execution of the statechart Dynamic Modeling (contd) l Traditionally there is a dynamic model for each class. as in this case study – However. objects in information systems rarely move from one class to another class l Accordingly.Initial Dynamic Model: Osbert Oglesby (contd) l The Osbert Oglesby information system moves from state to state when an event occurs – In each state. rather than for the system as a whole. a dynamic model for the information system as a whole is appropriate 26 .

Initial Boundary Classes: Osbert Oglesby l One screen should be adequate for all four Osbert Oglesby use cases: – – – – Buy a Painting Sell a Painting Print a Report Modify a Fashionability Coefficient l Thus there is one initial boundary class – User Interface Class Initial Boundary Classes: Osbert Oglesby (contd) l Consider again the first iteration of the main menu of the user-interface screen l The five commands correspond precisely to the five events in the statechart 27 .

Initial Boundary Classes: Osbert Oglesby (contd) l This is a graphical interface. a textual interface runs on all computers 28 . which needs special software Initial Boundary Classes: Osbert Oglesby (contd) l However.

Initial Boundary Classes: Osbert Oglesby (contd) l There are three reports: – The purchases report – The sales report – The future trends report l Each of these has to be modeled by a separate boundary class because the content of each report is different Initial Boundary Classes: Osbert Oglesby (contd) l There are thus three report boundary classes – Purchases Report Class – Sales Report Class – Future Trends Report Class 29 .

Initial Boundary Classes: Osbert Oglesby (contd) l There are therefore four boundary classes Extracting Control Classes l It is also usually easy to extract control classes – Each nontrivial computation is generally modeled by a control class 30 .

Initial Control Classes: Osbert Oglesby l 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 Initial Control Classes: Osbert Oglesby l There are thus four initial control classes: – – – – Compute Masterpiece Price Class Compute Masterwork Price Class Compute Other Painting Price Class Compute Future Trends Class 31 .

the description of the Buy a Painting use case must be split into three separate descriptions 32 . use case Buy a Painting needs to be refined into three separate use cases – Buy a Masterpiece – Buy a Masterwork – Buy Other Painting l l Therefore.Initial Control Classes: Osbert Oglesby (contd) l Here are the initial control classes Refining the Use Cases: Osbert Oglesby l The class diagram reflects that the pricing algorithm treats the three types of paintings differently Accordingly.

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 l The description of the use case must be split into three separate descriptions 33 .Refining the Use Cases: Osbert Oglesby (contd) l The Produce a Report use case 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 Refining the Use Cases: Osbert Oglesby (contd) l For both these reasons.

Third Iteration of the Use-Case Diagram Class Extraction (contd) l The description of class extraction is complete We now therefore return to the Unified Process l 34 .

Use-Case Realization l The process of extending and refining use cases is called use-case realization Use-Case Realization (contd) l The realization of a specific scenario of a use case is depicted using an interaction diagram – Either a sequence diagram or collaboration diagram l Various versions of the use case Buy a Masterpiece appear in the following slides 35 .

Buy a Masterpiece Use Case l Use case diagram Buy a Masterpiece Use Case (contd) l Description of the use case 36 .

Buy a Masterpiece Use Case (contd) l Class diagram (classes that enter into the use case) Buy a Masterpiece Use Case (contd) l The four classes that enter into this use case are: – 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 37 .

not classes – Example: A specific masterpiece is not represented by Masterpiece Class but rather by an object. a specific instance of Masterpiece Class l Such an object is denoted by : Masterpiece Class 38 .Buy a Masterpiece Use Case (contd) l Scenario (one possible instance of the use case) Buy a Masterpiece Use Case (contd) l A working information system uses objects.

Buy a Masterpiece Use Case (contd) l 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 l Something more is needed Buy a Masterpiece Use Case (contd) l Collaboration diagram (of the realization of the scenario of the use case) 39 .

Produce a Purchases Report Use Case l Class diagram – The realization is straightforward Produce a Sales Report Use Case l Class diagram – The realization is equally straightforward 40 .

Produce a Future Trends Report Use Case l Class diagram – The realization is also straightforward Modify a Fashionability Coefficient Use Case l Class diagram – The realization is just as straightforward 41 .

Combining the Realization Class Diagrams l Class diagram Sixth Iteration of the Class Diagrams l Fifth iteration + realization class diagram 42 .

both diagrammatic and textual – These UML diagrams convey to the client more information more accurately than the traditional specification document – The set of UML diagrams can also play the same role as the traditional specification document Formats of the Attributes (contd) l The formats could be determined during the analysis workflow However.Where’s the Specification Document? l The Unified Process is use-case driven – The use cases and the artifacts derived from them replace the traditional textual specification document l The client must be shown each use case and associated artifacts. the object-oriented paradigm is iterative – Information is added to models as late as possible l l Adding an item too early will make the next iteration unnecessarily burdensome – Formats are therefore added during the design workflow 43 .

Formats of Attributes of Osbert Oglesby l Class diagram with the formats of attributes added Allocation of Operations: Osbert Oglesby l Fifth iteration of the initial class diagram 44 .

Responsibility-Driven Design: Osbert Oglesby l Consider operation getAuctionPrice Irrespective of the source of the message requesting an auction price – Operation getAuctionPrice must be allocated to Auctioned Painting Class l Responsibility-Driven Design: Osbert Oglesby l Allocation of getAuctionPrice 45 .

Inheritance: Osbert Oglesby Case Study l Consider operations – setTitle and – getTitle Inheritance: Osbert Oglesby Case Study (contd) l Example: Osbert prints a list of all his paintings – Each object in the information system in turn is examined – A message is sent to operation getTitle to obtain the title of the painting represented by that object l To which class must operations – setTitle – getTitle and be allocated? 46 .

Inheritance: Osbert Oglesby Case Study (contd) l First consider operation setTitle In the traditional paradigm. there would have to be three different versions of setTitle. consider the Painting Class inheritance hierarchy Painting Class has attribute title – This attribute is inherited by instances of its 5 subclasses » » » » » Gallery Painting Class Auctioned Painting Class Masterpiece Class Masterwork Class Other Painting Class l 47 . one for each type of painting – set_masterpiece_title – set_masterwork_title – set_other_painting_title l l That is because the traditional paradigm does not support inheritance Inheritance: Osbert Oglesby Case Study (contd) l In the object-oriented paradigm.

Inheritance: Osbert Oglesby Case Study (contd) l Thus. including getTitle l Inheritance: Osbert Oglesby Case Study (contd) l Allocation of operations setTitle and getTitle 48 . operation setTitle must be allocated to Painting Class so that it can be inherited (and used) by instances of all five subclasses This applies to all operations.