Unit-3
OBJECT ORIENTED ANALYSIS
SYLLABUS:
Extracting entity classes –Initial dynamic model-Extracting control classes-refining use cases Incrementing the class diagram-Initial dynamic model-MSG Foundation case study revising the
entity classes-Extracting-USE case realization-MSG Foundation case study incrementing the
class diagram- more on use cases- risk
INTRODUCTION
 To obtain a deeper understanding of the requirements
 To describe the requirements in a way that is
o Easy to maintain, and
o Provides insights into the structure of the target information system
 Classes
 The three class types in the Unified Process are
o Entity classes
o Boundary classes
o Control classes
UML notation
Entity Classes
 An entity class models information that is long lived
 Examples:
o Account Class in a banking information system
o Painting Class in the Osbert Oglesby information system
o Mortgage Class and Investment Class in the MSG Foundation information
system
 Instances of all these classes remain in the information system for years
Boundary Classes
 A boundary class models the interaction between the information system and its actors
 Boundary classes are generally associated with input and output
 Examples:
– Purchases Report Class and Sales Report Class in the Osbert Oglesby
information system
1
–
Mortgage Listing Class and Investment Listing Class in the MSG Foundation
information system
Control Classes
 A control class models complex computations and algorithms
 Examples:
o Compute Masterpiece Price Class,
o Compute Masterwork Price Class, and
o Compute Other Painting Price Class in the Osbert Oglesby information system
3.1 EXTRACTING ENTITY CLASSES
 Entity class extraction consists of three steps that are carried out iteratively and
incrementally:
o Functional modeling
 Present scenarios of all the use cases (a scenario is an instance of a use
case)
o Class modeling
 Determine the entity classes and their attributes
 Determine the interrelationships and interactions between the entity
classes
 Present this information in the form of a class diagram
o Dynamic modeling
 Determine the operations performed by or to each entity class
 Present this information in the form of a statechart
 Flowchart for Extracting Entity Classes
2
3.1.1 Initial Functional Model: Osbert Oglesby
 Recall the Osbert Oglesby use-case diagram:
 Use Case and Scenario
 A use case depicts all possible interactions of a specific kind
 A scenario is an instance of a use case
o (Just as an object is an instance of a class)
Scenario of Use Case Buy a Painting
 This is a normal scenario
 There are six paragraphs in the scenario
o Only four of them are numbered
o 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”
have nothing to do with the interaction between Osbert and the information system
o These unnumbered paragraphs are essentially comments
3
Second Scenario of Use Case Buy a Painting
 This is an exception scenario
o It models an interaction that is not “normal”
Third Scenario of Use Case Buy a Painting
 This is another exception scenario
Normal and Exception Scenarios
 Normal and exception scenarios can be combined into an extended scenario
4
 The systems analysis team investigates as many normal and exception scenarios of each
use case as time permits
o To get the deepest possible understanding of
 The domain
 The business model, and
 The use cases
3.1.2 Initial Class Diagram : Osbert Oglesby Case Study
 The second step in extracting the entity classes is class modeling
o The aim of this step is to extract the entity classes, determine their
interrelationships, and find their attributes
 Usually, the best way to begin this step is to use the two-stage noun extraction method
o Stage 1: Describe the information system in a single paragraph
o Stage 2: Identify the nouns in this paragraph, then select the entity classes from
those nouns
Noun Extraction: Osbert Oglesby Case Study
 Stage 1: Describe the information system in one paragraph:
o Reports are to be generated in order to improve the effectiveness of the decisionmaking process for buying works of art. The reports contain buying and selling
information about paintings, which are classified as masterpieces, masterworks,
and other paintings
 Stage 2: Identify the nouns in this paragraph
o Reports are to be generated in order to improve the effectiveness of the decisionmaking process for buying works of art. The reports contain buying and selling
information about paintings, which are classified as masterpieces, masterworks,
and other paintings
 The nouns are report, effectiveness, process, buying, work of art, selling, information,
painting, masterpiece, and masterwork
 effectiveness, process and information are abstract nouns and are therefore unlikely to
be entity classes
o Abstract nouns identify things that have no physical existence
 Nouns buying and selling are derived from the verbs “buy” and “sell”
o They will probably be operations of some class
 Noun report is unlikely to be an entity class, because a report is not long lived
o A report is much more likely to be a boundary class
 Noun work of art is just a synonym for painting
First Iteration of the Initial Class Diagram
 This leaves four candidate entity classes:
o Painting Class, Masterpiece Class, Masterwork Class, and Other Painting Class
5
Second Iteration of the Initial Class Diagram
 Consider the interrelationships between the entity classes
 A masterpiece is a specific type of painting, and so is a masterwork and an “other
painting”
o Painting Class is therefore the base class
o Masterpiece Class, Masterwork Class, and Other Painting Class are subclasses of
that base class
Third Iteration of the Initial Class Diagram
 The class diagram does not reflect aspects of the pricing algorithm
 When dealing with a masterwork
o “The information system first computes the maximum purchase price as if it were
a masterpiece by the same artist”
 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
Fourth Iteration of the Initial Class Diagram
 Another aspect of the pricing algorithm that is not reflected in the current class diagram is
o “The information system computes the coefficient of similarity between each
painting for which there is an auction record and the painting under consideration
for purchase”
6
 Auctioned Painting Class is needed to make these comparisons
o An auctioned painting must be a subclass of Painting Class
o 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
 An instance of Painting Class is either
o A painting that Osbert has bought (an instance of Gallery Painting Class), or
o A painting sold at some auction (an instance of Auctioned Painting Class)
Fifth Iteration of the Initial Class Diagram
 A third aspect of the maximum price algorithm that has not yet been modeled is
fashionability
o “The information system computes the maximum purchase price from the formula
F  A , where F is a constant for that artist (fashionability coefficient) …”
 Fashionability Class is needed
o 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
7
 Finally, we add the attributes of each class to the class diagram
o For the Osbert Oglesby case study, the result is shown on the next slide
 The empty rectangle at the bottom of each box will later be filled with the operations of
that class
 Osbert Oglesby Application Class will contain the operation that starts execution of the
whole software product
 the fifth iteration of the initial class diagram, without the attributes, but explicitly
reflecting the stereotypes
o All eight classes in that figure are entity classes
 This is also a class diagram
o A class diagram depicts classes and their interrelationships; attributes and
operations are optional
8
3.2 INITIAL DYNAMIC MODEL
 Dynamic modeling is the third step in extracting the entity classes
 A statechart is constructed that reflects all the operations performed by or to the software
product
 The operations are determined from the scenarios
Initial state-chart
 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
 In state Osbert Oglesby Event Loop, one of five events can occur:
o buy painting selected
o sell painting selected
o print report selected
o update fissionability selected
o quit selected
9
Initial Main Menu: Osbert Oglesby
 Graphical user interface (GUI)
o “Point and click”
 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
o However, objects in this software product never move from one class to another
class
 Accordingly, a dynamic model for the software product as a whole is appropriate
3.3 EXTRACTING CONTROL CLASSES
 It is also usually easy to extract control classes
o Each nontrivial computation is generally modeled by a control class
 In the case study there are four computations
o Determining the maximum price that Osbert should offer for a
 Masterpiece
 Masterwork, or
 Other painting
o Determining if there is a new trend in art purchases
Initial Control Classes: Osbert Oglesby
 There are therefore four initial control classes
10
3.4 REFINING USE CASES
 The pricing algorithm treats the three types of paintings differently
 Use case Buy a Painting must therefore be refined into three separate use cases
o Buy a Masterpiece
o Buy a Masterwork
o Buy Other Painting
 Use case Produce a Report also needs to be refined
o The purchases report and the sales report use simple data extraction — the future
trends report involves computation
o All three reports use their own boundary classes
 For both these reasons, the Produce a Report use case must be refined into three use cases
o Produce a Purchases Report
o Produce a Sales Report
o Produce a Future Trends Report
Third Iteration of the Use-Case Diagram
 Implications for the remaining UML diagrams include:
o The description of the new Buy a Painting use case (see over) must be split into
three separate descriptions
o The description of the Produce a Report use case must be split into three separate
descriptions
Use Case Buy a Masterpiece
11
Description of Use Case Buy a Masterpiece
 The verb “The process of extending and refining use cases is called use-case
realization”
 “realize” is used at least 3 different ways:
o Understand (“Harvey slowly began to realize that he was in the wrong
classroom”);
o Receive (“Ingrid will realize a profit of $45,000 on the stock transaction”); and
o Accomplish (“Janet hopes to realize her dream of starting a computer company”)
 In the phrase “realize a use case,” the word “realize” is used in this last sense
 The realization of a specific scenario of a use case is depicted using an interaction
diagram
o Either a sequence diagram or collaboration diagram
 Consider use case Buy a Masterpiece
 We have previously seen
o The use case
o The description of the use case
12
Buy a Masterpiece Use Case
The Four Classes That Enter into This Use Case
 User Interface Class
o This class models the user interface
 Compute Masterpiece Price Class
o This class models the computation of the price Osbert should offer
 Masterpiece Class
o The computation involves comparing the masterpiece being considered with the
masterpieces that have been previously auctioned
 Auctioned Painting Class
o These masterpieces are all instances of Auctioned Painting Class
Buy a Masterpiece Use Case
 The Seller does not interact directly with the software product
o Instead, the Seller provides data that Osbert enters into the software product
 This is indicated in the note (the rectangle with the top right-hand corner turned over)
o There is a dashed line from the note to the item to which it refers, the Seller in this
case
Scenario (one possible instance of the use case)
13
 An executing software product uses objects, not classes
 Example:
o 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
 A class diagram shows the classes in the use case and their relationships
o It does not show the objects nor the sequence of messages as they are sent from
object to object
 Something more is needed
 A collaboration diagram (of the realization of the scenario of the use case)
 Osbert will not approve the specification document unless he understands it
 Accordingly, a written description of the collaboration diagram is needed
o The flow of events
 The flow of events of the collaboration diagram of the realization of the scenario of the
use case
 Osbert will not approve the specification document unless he understands it
 Accordingly, a written description of the collaboration diagram is needed
o The flow of events
 UML supports two different types of interaction diagram
 Collaboration diagram
 Sequence diagram
 Both contain exactly the same information, but displayed in different ways
14
 Sequence diagram equivalent to the collaboration diagram (of the realization of the
scenario of the use case)
 The narrow rectangle on a lifeline (dashed vertical line) shows when the relevant object
is active
 In the collaboration diagram, the [new] is inside the : Masterpiece Class object
o In the sequence diagram, the object is shifted down so that its lifeline starts
where the object is created
 The sequence diagram shows that every message of the scenario involves either
o The instance of the user interface class : User Interface Class or
o The instance of the control class : Compute Masterpiece Price Class
 It also shows that every transfer of information from object A to object B is eventually
followed by a transfer in the reverse direction
 These two facts are also true in the fully equivalent collaboration diagram, but are not as
obvious in that format
 It also shows that every transfer of information from object A to object B is eventually
followed by a transfer in the reverse direction
 These two facts are also true in the fully equivalent collaboration diagram, but are not as
obvious in that format
Interaction Diagrams
 Software engineers can choose whether to use
o A sequence diagram, or
o A collaboration diagram, or
o Both
for each scenario
 The strength of a sequence diagram is that it shows the flow of messages and their order
unambiguously
 When transfer of information is the focus of attention, a sequence diagram is
superior to a collaboration diagram
15
 A collaboration diagram is similar to a class diagram
 When the developers are concentrating on the classes, a collaboration diagram is
more useful than the equivalent sequence diagram
 The seven previous figures depict different aspects of the use case Buy a Masterpiece
 They use different notations and provide different levels of detail of the 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
 The maximum price of a masterwork is computed by first treating the painting as if it
were a masterpiece, and then adjusting the result
The Five Classes That Enter into This Use Case
 User Interface Class
 Compute Masterwork Price Class
 This class models the computation of the price Osbert should offer
 It creates a masterwork object and passes it to Compute Masterpiece Price Class
as if it were a masterpiece
 Compute Masterpiece Price Class
 Masterpiece Class
 Auctioned Painting Class
Class diagram (classes that enter into the use case)
One possible scenario of the use case
16
Buy Other Painting Use Case
 Modifying the Main Menu. The main menu must reflect buying the three different types
of painting explicitly
 Buy a Painting must be replaced by
o Buy a Masterpiece,
o Buy a Masterwork, and
o Buy Other Painting
 The revised screen is generated by : User Interface Class
SELL A PAINTING USE CASE – CLASS DIAGRAM
17
PRODUCE A PURCHASES REPORT USE CASE- CLASS DIAGRAM
PRODUCE A SALES REPORT USE CASE
PRODUCE A FUTURE TRENDS REPORT USE CASE
MODIFY A FASHIONABILITY COEFFICIENT USE CASE
18
3.5 INCREMENTING THE CLASS DIAGRAM
 In the course of realizing the various use cases
o Interrelationships between classes become apparent
 Accordingly, we now combine the realization class diagrams
Combining the Realization Class Diagrams
 Sixth Iteration of the Class Diagrams
19
3.6 INITIAL DYNAMIC MODEL - MSG
 Dynamic modeling is the third step in extracting the entity classes
 A statechart is constructed that reflects all the operations performed by or to the software
product
 The operations are determined from the scenarios
 The statechart reflects the operations of the complete MSG Foundation information
system
o The solid circle on the top left represents the initial state, the starting point of the
statechart
o The white circle containing the small black circle on the top right represents the
final state
o States other than the initial and final states are represented by rectangles with
rounded corners
o The arrows represent possible transitions from state to state
 In state MSG Foundation Information System Loop, one of five events can occur
 An MSG staff member can issue one of five commands:
o estimate funds for the week
o manage an asset
o update estimated annual operating expenses
o produce a report, or
o quit
 These possibilities are indicated by the five events
o estimate funds for the week selected
o manage an asset selected
o update estimated annual operating expenses selected
o produce a report selected, and
o quit selected
 An event causes a transition between states
 An MSG staff member selects an option by clicking on the menu
20
 This graphical user interface (GUI) requires special software
 Equivalent textual user interface that can run on any computer
3.7 MSG FOUNDATION CASE STUDY REVISING THE ENTITY CLASSES
 The initial functional model, the initial class diagram, and the initial dynamic model are
completed
o Checking them reveals a fault
 In the initial statechart, consider state Update Estimated Annual Operating Expenses with
operation Update the estimated annual operating expenses
o This operation has to be performed on the current value of the estimated annual
operating expense
 But where is the value of the estimated annual operating expenses to be found?
 Currently there is only one class (Asset Class) and its two subclasses
o Neither is appropriate for storing the estimated annual operating expenses
 The only way a value can be stored on a long-term basis is as an attribute of an instance
of that class or its subclasses
 Another entity class is needed for storing the estimated annual operating expenses
o MSG Application Class
Third Iteration of the Initial Class Diagram: MSG Foundation
 MSG Application Class has other attributes as well
o Attributes that do not appertain to the assets
21
 The class diagram redrawn to show the prototypes
22
Extracting the Boundary Classes: MSG Foundation
 It is usually easy to extract boundary classes
o Each input screen, output screen, and printed report is generally modeled by a
boundary class
o One screen should be adequate for all four MSG Foundation use cases
 Estimate Funds Available for Week
 Manage an Asset
 Update Estimated Annual Operating Expenses
 Produce a Report
o Accordingly there is one initial boundary class
o User Interface Class
 Three reports have to be printed
o The estimated funds for the week report
o The listing of all mortgages
o The listing of all investments
 Each of these has to be modeled by a separate boundary class
o Estimated Funds Report Class
o Mortgages Report Class
o Investments Report Class
 Here are the four initial boundary classes
 There are three reports:
o The purchases report
o The sales report
o The future trends report
 The content of each report is different
o Each report therefore has to be modeled by a separate boundary class
3.8 USE CASE REALIZATION : THE MSG FOUNDATION CASE STUDY
 The process of extending and refining use cases is called use-case realization
 The verb “realize” is used at least 3 different ways:
o Understand (“Harvey slowly began to realize that he was in the wrong
classroom”);
o Receive (“Ingrid will realize a profit of $45,000 on the stock transaction”); and
o Accomplish (“Janet hopes to realize her dream of starting a computer company”)
 In the phrase “realize a use case,” the word “realize” is used in this last sense
 The realization of a specific scenario of a use case is depicted using an interaction
diagram
o Either a sequence diagram or collaboration diagram
 Consider use case Estimate Funds Available for Week
23
 We have previously seen
o The use case
o The description of the use case
3.8.1 Estimate Funds Available for Week Use Case
 Use-case diagram
 Description of use case
24
 Class diagram (classes that enter into the use case)
 The six classes that enter into this use case are:
o User Interface Class
 This class models the user interface
o Estimate Funds for Week Class
 This control class models the computation of the estimate of the funds that
are available to fund mortgages during that week
o Mortgage Class
 This class models the estimated grants and payments for the week
o Investment Class
 This class models the estimated return on investments for the week
o MSG Application Class
 This class models the estimated return on investments for the week
o Estimated Funds Report Class
 This class models the printing of the report
25
 Scenario (one possible instance of the use case)
 A working information system uses objects, not classes
o Example: A specific mortgage cannot be represented by Mortgage Class but
rather by an object, a specific instance of Mortgage Class
 Such an object is denoted by : Mortgage Class
 A class diagram shows the classes in the use case and their relationships
o It does not show the objects nor the sequence of messages as they are sent from
object to object
26
 Collaboration diagram (of the realization of the scenario of the use case)
 The collaboration diagram shows the objects as well as the messages, numbered in the
order in which they are sent in the specific scenario
 Item 1:
o The staff member wants to compute the funds available for the week
o In the collaboration diagram, this is modeled by message
 1: Request estimate of funds available for week
 from MSG Staff Member to : User Interface Class, an instance of User Interface Class
 Item 2
o This request is passed on to : Estimate Funds for Week Class, an instance of the
control class that actually performs the calculation
o This is modeled by message
 2: Transfer request
 Four separate financial estimates are now determined by : Estimate Funds for Week Class
27
 Item 3
o In Step 1 of the scenario, the estimated annual return on investments is summed
for each investment and the result divided by 52
o This extraction of the estimated weekly return is modeled by message
 3: Request estimated return on investments for week
from : Estimate Funds for Week Class to : Investment Class followed by message
 4: Return estimated weekly return on investments in the other direction
 Item 4
o In Step 2 of the scenario, the weekly operating expenses are estimated by taking
the estimated annual operating expenses and dividing by 52
o This extraction of the weekly expenses is modeled by message
 5: Request estimated operating expenses for week
from : Estimate Funds for Week Class to : MSG Application Class followed by message
 6: Return estimated operating expenses for week
in the other direction
 Item 5
o In Steps 3, 4, and 5 of the scenario, two estimates are determined
 the estimated grants for the week, and
 the estimated payments for the week
o This is modeled by message
 7: Request estimated grants and payments for week
from : Estimate Funds for Week Class to : Mortgage Class, and by message
 8: Return estimated grants and payments for week
in the other direction
 Item 6
o Now the arithmetic computation of Step 6 of the scenario is performed
o This is modeled by message
 9: Compute estimated amount available for week
o This is a self call
o : Estimate Funds for Week Class tells itself to perform the calculation
o The result of the computation is stored in : MSG Application Class by message
 10: Transfer estimated amount available for week
 Item 7
o The result is printed in Step 7 of the scenario
o This is modeled by message
 11: Print estimated amount available
o from : MSG Application Class to : Estimated Funds Report Class
 Item 8
o Finally, an acknowledgment is sent to the MSG staff member that the task has
been successfully completed
o This is modeled by messages
 12: Send successful completion message
 13: Send successful completion message
 14: Transfer successful completion message, and
 15: Display successful completion message
 No client will approve the specification document without understanding it
28
 Accordingly, a written description of the collaboration diagram is needed, the flow of
events
 The flow of events of the collaboration diagram of the realization of the scenario of the
use case
 Sequence diagram equivalent to the collaboration diagram (of the realization of the
scenario of the use case)
3.9 MSG FOUNDATION CASE STUDY INCREMENTING THE CLASS DIAGRAM
 In the course of realizing the various use cases
o Interrelationships between classes become apparent
 Accordingly, we now combine the realization class diagrams
COMBINING THE REALIZATION CLASS DIAGRAMS
29
FIFTH ITERATION + REALIZATION CLASS DIAGRAM
3.9.1
MANAGE AN ASSET USE CASE
 USE CASE
30
DESCRIPTION OF USE CASE
CLASS DIAGRAM SHOWING THE CLASSES THAT REALIZE THE USE
CASE
ONE SCENARIO OF THE USE CASE
31
COLLABORATION DIAGRAM OF THE REALIZATION OF THE SCENARIO
OF THE USE CASE
 Object : Investment Class does not play an active role in this collaboration diagram
o This scenario does not involve an investment, only a mortgage
 Actor Borrowers does not play a role in this use case, either
32
SEQUENCE DIAGRAM EQUIVALENT TO THE COLLABORATION
DIAGRAM (OF THE REALIZATION OF THE SCENARIO OF THE USE CASE)
A DIFFERENT SCENARIO OF THE USE CASE
 At the request of the borrowers, the MSG staff member updates the weekly income of a
couple
 The scenario is initiated by the Borrowers
 Their data are entered into the software product by the MSG Staff Member
o This is stated in the note in the collaboration diagram
33
SEQUENCE DIAGRAM EQUIVALENT TO THE COLLABORATION
DIAGRAM (OF THE REALIZATION OF THE SCENARIO OF THE USE CASE)
 Two different scenarios of the same use case have been presented
 The use case is the same
o The class diagram is therefore the same
 However, the collaboration (and sequence) diagrams reflect the differences between the
two scenarios
 Boundary class User Interface Class appears in all the realizations
o The same screen will be used for all commands of the information system
 Revised menu
34
Corresponding textual interface
3.9.2 UPDATE ANNUAL OPERATING EXPENSES USE CASE
Class diagram
Collaboration diagram of a realization of a scenario of the use case
35
Equivalent sequence diagram
3.9.3 Produce a Report Use Case
Use case
36
Description of use case
Class diagram
37
One scenario of the use case
Collaboration diagram
 Mortgages (but not investments) are involved
38
Sequence diagram
A second scenario (listing all investments) of the use case
39
 Collaboration diagram for second scenario
 This time, investments (but not mortgages) are involved
Sequence diagram for second scenario
40
3.10 MORE ON USE CASES
 In the Unified Process
o The term worker is used to denote a role played by an individual
o In the Unified Process, Applicants and Borrowers are two different workers
 In common parlance
o The word “worker” usually refers to an employee
 Within a business context, finding the roles is easy
o They are displayed within the use-case business model
 To find the actors
o Find the subset of the use-case business model that corresponds to the use-case
model of the requirements
 To find the actors (in more detail):
o Construct the use-case business model
o Consider only those parts of the business model that correspond to the proposed
software product
o The actors in this subset are the actors we seek
 Within a business context, finding use cases is easy
 For each role, there will be one or more use cases
3.11 RISK
 A major risk in developing a new information system is that the delivered information
system does not meet the client’s needs.
 In the traditional paradigm, this risk was met by constructing rapid prototype, a hurriedly
thrown together working program that displays the key functionality of the target
information.
 This type of information is not needed in the unified process, because the use cases and
their scenarios take the place of the rapid prototype.
3.11.1 Rapid prototyping
 Many approaches have been put forward for ensuring that the client’s needs are truly met
by the specification document.
 They all reduce to the systems analysts sitting down with the client, going through the
specification document line by line and asking, “Are you really, really, really sure that
this is what you want the proposed information system to do?” none of these methods are
foolproof.
 1st situation concerns Joe and Jane Johnson, who decide to build a house. They consult
with an architect. Instead of showing them sketches, plans, perhaps a model, the architect
gives them a 20 page, single-spaced document, describing the house in highly technical
41
terms. Despite the fact that both Joe and Jane have no previous architectural experience
and hardly understand any of the documents, they enthusiastically sign it and say, “Go
right ahead; build the house!”
 2nd situation concerns Mark Marberry, who buys his suits by mail order. Instead of
mailing him pictures of their suits and samples of available cloths, the company sends
Mark a catalog containing written description of the cut and the cloth of their products.
Mark then order a suit solely based on the written description.
 The client use the information system for a few minutes, then turns to the system analysts
and says “I know that this is the information system I asked for, but it is not what I
wanted”.
 A rapid prototype is a working program that exhibits the key behavior of that
information system. For example, if the target information system is to handle accounts
payable, accounts receivable and warehousing, then the rapid prototype may consist of an
information system that performs the screen handling for data capture and prints the
reports, but does no database updating or error handling (hidden aspects).
 The client and users then experiment with the prototype to determine whether it indeed
meets their needs. The rapid prototype can be changed until the client and users are
satisfied that it encapsulates the functionality they desire.
Key points:
 It must be “rapid”. That is it must be thrown together as quickly as possible. The use is to
make sure, when the complete information system is delivered to the client a year or so
later, the functionality of the system will be precisely what the client needs. One way of
doing this is for the client to experiment with a computer program that behaves the same
way the target information system will behave.
 After the rapid prototype has been approved by the client, it must be thrown away
without any sort of specification or design document. Making changes when there is no
documentation of any kind is both expensive and foolhardy.
3.11.2 Scenarios and the Client’s needs
 Instead of constructing a rapid prototype, the use cases or more precisely, interaction
diagrams reflecting the classes that realize the scenarios of the use cases as shown to the
client. The client can understand how the target information system will behave just as
42
well from the interaction diagrams and their written flow of events as from a rapid
prototype.
 There is a need to construct specimen screens and reports, preferably with the aid of
screen generators, report generators and CASE tools that make it easy to produce the
code for screens and reports.
43