Slide 4.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.

Slides:



Advertisements
Similar presentations
Systems Analysis and Design with UML Version 2.0, Second Edition
Advertisements

Use Cases  A use case depicts an interaction between the software program and the user (actors)  Example: Withdraw Money Customer Teller.
Copyright © 2003 by The McGraw-Hill Companies, Inc. All rights reserved. Business and Administrative Communication SIXTH EDITION.
Slide 11.1 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented and Classical Software Engineering Eighth Edition,
Use-case Modeling.
Slide 6C.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 1.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 6B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 7D.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 8B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Object Oriented Analysis Process
Slide 9.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Overview of a Simple Development Method. Background Before discussing some specific methods we will consider a simple method that doesn’t have a name.
Slide 18.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 7B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 5A.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 8A.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 7C.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 5D.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 7A.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 5C.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 6A.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 19.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 11B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Use Case Modeling. Kendall & Kendall© 2005 Pearson Prentice Hall18-2 Commonly Used UML Diagrams The most commonly used UML diagrams are: – Use case diagram,
Slide 17.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 5B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 7E.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Specification Report CSCI Requirements of Specification Report  Must be clear and intelligible to client  Must be complete and detailed to result.
Slide 12C.50 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005.
Case Study: Class Extraction.
Slide 10C.52 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
Slide 12E.121 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
IT Job Roles Task 20. Software Engineer Job Description Software engineers are responsible for creating and maintaining software of various different.
Objects What are Objects Observations
Use Cases Why use ‘em? How do they work? UC diagrams Using them later in the software development cycle.
Requirements Functional requirements  Use-cases
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 The requirements engineering process.
PRJ566 Project Planning and Management
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Slide 1.
Slide 10A.1 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005.
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
1 CMPT 275 Software Engineering Requirements Gathering Activity Janice Regan,
1 Analysis Extracting from Use Cases to Create Diagrams.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 4: Restaurant.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
UML-1 3. Capturing Requirements and Use Case Model.
An Introduction to Programming with C++ Sixth Edition Chapter 7 The Repetition Structure.
UML-1 8. Capturing Requirements and Use Case Model.
Ch 10: Requirements CSCI Requirements Workflow 1.Acquire basic understanding of the application domain (banking, automobile manufacturing) 2.Identify.
Slide 20.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 12A.1 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
Requirements Collection By Dr. Gabriel. Requirements A requirement is any function, constraint, or property that the system must provide, meet, or satisfy.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
Use Case Driven Analysis Requirements Use Case Use Case Description System Sequence Diagram Chapter 5.
Slide 1 Systems Analysis and Design with UML Version 2.0, Second Edition Alan Dennis, Barbara Wixom, and David Tegarden Chapter 6: Functional Modeling.
Slide 6D.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 12D.88 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
Slide © The McGraw-Hill Companies, 2007 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach.
Slide 10.1 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen.
Slide 12F.135 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2010 Stephen R. Schach
Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R
We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic.
Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach
An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach
Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach
Presentation transcript:

Slide 4.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach

Slide 4.2 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CHAPTER 4 THE REQUIREMENTS WORKFLOW I

Slide 4.3 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter Overview l Determining What the Client Needs l Overview of the Requirements Workflow l Understanding the Domain l Initial Understanding of the Domain: Osbert Oglesby Case Study l Business Model l Interviewing l Other techniques

Slide 4.4 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter Overview (contd) l Use Cases l Initial Business Model: Osbert Oglesby Case Study l Initial Requirements l Initial Requirements: Osbert Oglesby Case Study l Continuing the Requirements Workflow: Osbert Oglesby Case Study l It Ain’t Over Till it’s Over

Slide 4.5 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Determining the Client’s Needs l Consider the requirements workflow l The primary task of the systems analyst is to determine what the client needs –This may not be what the client says that he or she wants l Information systems are complex –Clients therefore often ask for the wrong information system

Slide 4.6 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Determining the Client’s Needs (contd) l It is hard for a systems analyst to visualize an information system and its functionality –The problem is far worse for the client l A skilled systems analyst is needed to elicit the appropriate information from the client l The client is the only source of this information

Slide 4.7 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Determining the Client’s Needs (contd) l The solution: –Obtain initial information from the client –Use this initial information as input to the Unified Process –Follow the steps of the Unified Process to determine the client’s real needs

Slide 4.8 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Overview of the Requirements Workflow l First, gain an understanding of the application domain (domain, for short) –(The specific business environment in which the information system is to operate) l Second, build a business model –Use UML to describe the client’s business processes l Third, use the business model to determine the client’s requirements l Then iterate (“repeat”) the above steps

Slide 4.9 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Flowchart of the Requirements Workflow

Slide 4.10 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Definitions l Discovering the client’s requirements –Requirements elicitation (or requirements capture) –Methods include interviews and surveys l Refining and extending the initial requirements –Requirements analysis

Slide 4.11 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Understanding the Domain l Every member of the development team must become fully familiar application domain –Correct terminology is essential l We must build a glossary –That is, a list of technical words used in the domain, and their meaning

Slide 4.12 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Initial Understanding: Osbert Oglesby Case Study l Osbert Oglesby, Art Dealer, needs an information system to assist him in buying and selling paintings l Obtaining domain knowledge is the first step l Osbert is interviewed to obtain the relevant information l This information is put into a glossary (see next slide)

Slide 4.13 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Glossary: Osbert Oglesby Case Study

Slide 4.14 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Business Model l A business model is a description of the business processes of an organization l The business model gives an understanding of the client’s business as a whole –This knowledge is essential for advising the client regarding computerization l The systems analyst needs to obtain a detailed understanding of the various business processes – Different techniques are used, primarily interviewing

Slide 4.15 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Interviewing l The requirements team meet with the client and users to extract all relevant information

Slide 4.16 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Interviewing (contd) l There are two types of questions –Close-ended questions requires a specific answer –Open-ended questions are asked to encourage the person being interviewed to speak out l There are two types of interviews –In a structured interview, specific preplanned questions are asked, frequently close-ended –In an unstructured interview, questions are posed in response to the answers received, frequently open-ended

Slide 4.17 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Interviewing (contd) l Interviewing is not easy –An interview that is too unstructured will not yield much relevant information –The interviewer must be fully familiar with the application domain –The interviewer must remain open-minded at all times l After the interview, the interviewer must prepare a written report –It is strongly advisable to give a copy of the report to the person who was interviewed

Slide 4.18 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Other Information Gathering Techniques l Interviewing is the primary technique l A questionnaire is useful when the opinions of hundreds of individuals need to be determined l Examination of business forms shows how the client currently does business

Slide 4.19 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Other Information Gathering Techniques (contd) l Direct observation of the employees while they perform their duties can be useful –Videotape cameras are modern version of this technique –But, it can take a long time to analyze the tapes –Employees may view the cameras as an unwarranted invasion of privacy

Slide 4.20 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Use Cases l A use case models an interaction between the information system itself and the users of that information system (actors) l Example:

Slide 4.21 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Use Cases (contd) l A use case shows the interaction between –The information system and –The environment in which the information system operates l Each use case models one type of interaction –There can be just a few use cases for an information system, or there can be hundreds l The rectangle in the use case represents the information system itself

Slide 4.22 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Use Cases (contd) l An actor is a member of the world outside the information system l It is usually easy to identify an actor –An actor is frequently a user of the information system l In general, an actor plays a role with regard to the information system. This role is –As a user; or –As an initiator; or –As someone who plays a critical part in the use case

Slide 4.23 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Use Cases (contd) l A user of the system can play more than one role l Example: A customer of the bank can be –A Borrower or –A Lender

Slide 4.24 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Use Cases (contd) l Conversely, one actor can be a participant in multiple use cases l Example: A Borrower may be an actor in –The Borrow Money use case; –The Pay Interest on Loan use case; and –The Repay Loan Principal use case l Also, the actor Borrower may stand for many thousands of bank customers

Slide 4.25 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Use Cases (contd) l An actor need not be a human being l Example: The Cardholder Clothing Company information system has to interact with the credit card company information system –The credit card company information system is an actor from the viewpoint of the Cardholder Clothing Company information system –The Cardholder Clothing Company information system is an actor from the viewpoint of the credit card company information system

Slide 4.26 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Use Cases (contd) l A potential problem when identifying actors –Overlapping actors l Example: Hospital Information System –One use case has actor Nurse –A different use case has actor Medical Staff –Better: »Actors: Physician and Nurse

Slide 4.27 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Use Cases (contd) l Alternatively: –Actor Medical Staff with two specializations: Physician and Nurse

Slide 4.28 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. 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 l 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

Slide 4.29 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. 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

Slide 4.30 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Init. Business Model: Osbert Oglesby Case Study l Osbert has three business activities: –He buys paintings –He sells paintings –He produces reports

Slide 4.31 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Init. Business Model: Osbert Oglesby Case Study l Buy a Painting use case

Slide 4.32 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Init. Business Model: Osbert Oglesby Case Study l Sell a Painting use case

Slide 4.33 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Init. Business Model: Osbert Oglesby Case Study l Produce a Report use case

Slide 4.34 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Init. Business Model: Osbert Oglesby Case Study l For conciseness, all three use cases are combined into a use-case diagram

Slide 4.35 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Init. 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 l 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

Slide 4.36 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Init. Business Model: Osbert Oglesby Case Study l Next, the use cases have to be annotated l Here are the initial use-case descriptions

Slide 4.37 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Init. Business Model: Osbert Oglesby Case Study l Buy a Painting use case

Slide 4.38 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Init. Business Model: Osbert Oglesby Case Study l Sell a Painting use case

Slide 4.39 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Init. Business Model: Osbert Oglesby Case Study l Produce a Report use case

Slide 4.40 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Initial Requirements l The initial requirements are based on the initial business model l Then they are refined The requirements are dynamic — there are frequent changes –Maintain a list of likely requirements, together with use cases of requirements approved by the client

Slide 4.41 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Initial Requirements (contd) l There are two categories of requirements l A functional requirement specifies an action that the information system must be able to perform –Often expressed in terms of inputs and outputs l A nonfunctional requirement specifies properties of the information system itself, such as –Platform constraints –Response times –Reliability

Slide 4.42 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Initial Requirements (contd) l Functional requirements are handled as part of the requirements and analysis workflows l Some nonfunctional requirements have to wait until the design workflow –The detailed information for some nonfunctional requirements is not available until the requirements and analysis workflows have been completed

Slide 4.43 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Initial Requirements: Osbert Oglesby Case Study l The initial business model (the three use cases) shows how Osbert currently does business l Decide which of these use cases are also requirements of the information system to be built –Clearly, all three are requirements l Refine the resulting initial requirements –The descriptions of the use cases have to be refined

Slide 4.44 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Initial Requirements: Osbert Oglesby l Buy a Painting use case

Slide 4.45 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Initial Requirements: Osbert Oglesby (contd) l Sell a Painting use case

Slide 4.46 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Initial Requirements: Osbert Oglesby (contd) l Produce a Report use case

Slide 4.47 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Initial Requirements: Osbert Oglesby (contd) l 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 l Basic principle: Defer all details to as late as possible –This will simplify the inevitable changes of the next iteration

Slide 4.48 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Requirements Workflow: Osbert Oglesby l More details of each use case are needed now l First consider use cases –Buy a Painting, and –Sell a Painting l To refine the descriptions, determine what attributes need to be input when a painting is bought and when a painting is sold

Slide 4.49 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Attributes: Osbert Oglesby Case Study l Attributes when buying a painting include: –Title of work, name of artist, date of painting, classification, medium, purchase price, name and address of seller –(The complete list of attributes appears in the textbook in Figure 4.15) l Attributes when selling a painting are: –Date of sale, name of buyer, address of buyer, actual selling price

Slide 4.50 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Requirements Workflow: Osbert Oglesby l Now the algorithm for computing the maximum purchase price is considered l Classify the painting as a –Masterpiece –Masterwork, or –Other painting

Slide 4.51 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maximum Price for a Masterpiece l Scan worldwide auction records over the past 25 years for the most similar work by the same artist l Use the auction purchase price of the most similar work as the base price l The maximum purchase price is found by adding 7.5 percent to the base price, compounded annually, for each year since that auction

Slide 4.52 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maximum Price for a Masterwork l Compute the maximum purchase price as if the painting were a masterpiece by the same artist l If the picture was painted in the 21st century, multiply this figure by 0.25 l Otherwise, multiply it by (21 – c) / (22 – c), where c is the century in which the work was painted (12 < c < 21)

Slide 4.53 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maximum Price for an Other Painting l Measure the dimensions of the canvas l 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 l If there is no fashionability coefficient for that artist, Osbert will not buy the painting

Slide 4.54 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Coefficient of Similarity: Osbert Oglesby l 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

Slide 4.55 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. 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

Slide 4.56 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Fashionability Coefficients: Osbert Oglesby l The information system must include a list of artists and their corresponding F values l The value of F can vary from month to month, depending on the current fashionability of an artist l 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

Slide 4.57 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Auction Data: Osbert Oglesby Case Study l The information system must utilize information on auction sales of masterpieces over the past 25 years worldwide l Each month Osbert receives a CD with updated worldwide auction prices; these prices are never modified by Osbert

Slide 4.58 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Updated Use Cases : Osbert Oglesby Case Study l The use-case descriptions must reflect this information l The resulting description of the Buy a Painting use case is in Figure 4.15

Slide 4.59 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Updated Use Cases : Osbert Oglesby Case Study l The description of the Sell a Painting use case:

Slide 4.60 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. 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):

Slide 4.61 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. 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

Slide 4.62 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. 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

Slide 4.63 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. 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, at least two of the artist’s works must have been sold by Osbert during that period

Slide 4.64 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Updated Use-Case Description: Produce a Report l The updated description of the Produce a Report use case, incorporating the details listed above, appears in Figure 4.20

Slide 4.65 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. 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

Slide 4.66 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Use-Case Modify a Fashionability Coefficient l Use-case description

Slide 4.67 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Second Iteration of Use-Case Diagram l Incorporate all four use cases

Slide 4.68 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Analysis of Req. Workflow: Osbert Oglesby l A fault was detected –There was a missing use case –The existing artifacts did not need to be changed l Two additional artifacts had to be added –A use case, and –Its description l The Unified Process is iterative and incremental –Systems analysts must always be aware that changes and extensions to the current version of the information system may have to made at any time