1

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

2

– 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

3

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

4

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

5

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 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

Stage 2: Identify the nouns in this paragraph o 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

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

6

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”

7

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

8

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

9

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

10

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

11

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

12

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

13

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)

14

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

15

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

16

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

17

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

18

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

19

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

20

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

21

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

22

The class diagram redrawn to show the prototypes

23

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

24

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

25

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

26

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

27

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

28

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

29

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

30

FIFTH ITERATION + REALIZATION CLASS DIAGRAM

3.9.1 MANAGE AN ASSET USE CASE USE CASE

31

DESCRIPTION OF USE CASE

CLASS DIAGRAM SHOWING THE CLASSES THAT REALIZE THE USE CASE

ONE SCENARIO OF THE USE CASE

32

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

33

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

34

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

35

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

36

Equivalent sequence diagram

3.9.3 Produce a Report Use Case

Use case

37

Description of use case

Class diagram

38

One scenario of the use case

Collaboration diagram Mortgages (but not investments) are involved

39

Sequence diagram

A second scenario (listing all investments) of the use case

40

Collaboration diagram for second scenario This time, investments (but not mortgages) are involved

Sequence diagram for second scenario

41

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

42

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

43

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.