Systems Analysis and Design in a Changing World, Fourth Edition -Solutions 07

Systems Analysis and Design in a Changing World, Fourth Edition

7-1

Chapter 7 – The Object-Oriented Approach to Requirements Solutions to End-of-Chapter Material Review Questions 1.

What is the OMG? The OMG is the Object Management Group. It is a consortium of over 800 organizations consisting of software vendors, developers and other organizations. The objective of the consortium is to set standards and establish uniformity in object-oriented development, including standard specifications across environments.

2.

What is UML? What type of modeling is it used for? UML stands for Unified Modeling Language. It is the standard object-oriented modeling language that has been accepted by the OMG. It is used for requirements specification and architectural design of object-oriented systems.

3.

What are the two basic parts of a use case model? What is its purpose or objective? The two parts (icons) of a use case model are the use case identifier (an oval) and the use case actor (a stick figure). The objective of the use case model is to identify all of the ways the users will use the system. A use case identifies a specific way, such as completing a business transaction, that the system is used and must support.

4.

What is the difference between a use case description and an activity diagram? A use case description identifies several characteristics of the use case. It also includes a textual description of the steps included in the workflow of the use case. An activity diagram is a graphical model that shows the steps in the workflow of the use case.

5.

What is meant by a scenario? What is another term used to describe a scenario? Another term for a scenario is a use case instance. A scenario is a specific workflow that represents the use case. In other words, a use case might be identified as a general business process. However, there may be several different ways that the business process can be done, depending on the actor, preconditions, and so forth. Each flow through the steps of the use case can be a different instance or scenario.

Systems Analysis and Design in a Changing World, Fourth Edition

6.

7-2

Why do actors have “hands”? Actors have hands to indicate that they actually touch or have contact with the system. The hands on an actor emphasize the fact that actors interface with the boundary of the automated system. This is in contrast to a context diagram source, which may be the source of information, but may not have direct contact with the automated system.

7.

What is the «includes» relationship used for? The «includes» relationship is used to connect two use cases when one use cases invokes the other use case. The “included” use case is like a common subroutine that can be used by other processes or use cases.

8.

What is the difference in the focus on the boundary condition of a use case diagram and an event table? The identification of events for the event table requires a source and a trigger. The source and trigger are those items that initiate an event in the entire system, including the manual system and the automated system. In a use case diagram, the boundary is an automation boundary—that is, it denotes the interface between the environment, where the actors reside, and the internal components of the computer system. The source and the actor are not always the same. The source is where the data comes from.

9.

With regard to a use case, what is an activity diagram used for? An activity diagram documents the workflow in the use case. It shows the external actor in one swimlane, and the system responses in another swimlane. Usually one activity diagram can show the flow of activities for a single use case or scenario.

10.

What is a precondition? What is a postcondition? Why are they important in use case development? A precondition describes the state of the system before the use case begins. It identifies objects and relationships and their states at the beginning of the use case. The postcondition describes the state of the system at the conclusion of the use case. It identifies the objects and relationships and their states at the end of the execution. The preconditions and postconditions determine what needs to be accomplished by the system during the execution of the use case. They provide an additional check to ensure that the use case completes all the necessary internal processes.

Systems Analysis and Design in a Changing World, Fourth Edition

11.

7-3

What is the purpose of a system sequence diagram? What symbols are used in a system sequence diagram? A system sequence diagram (SSD) identifies the input and output messages to the automated system for a use case. The input and output messages describe the inputs and outputs to the system. The symbols are actors and objects. Actors are depicted by stick figures. Objects are depicted as rectangles with the inside label underlined. Lifelines are attached to actors and objects. Lifelines are depicted by vertical dashed lines beneath the actors and objects. The input and output messages are depicted as arrows between the lifelines.

12.

What are the steps required to develop a system sequence diagram? There are four steps. In most cases the SSD can be developed from an activity diagram or a flow of events on the use case description. 1. Identify the input messages. This usually occurs on an activity diagram when an arrow crosses the swimlanes from the actor to the system. 2. Describe the input message with name, parameters, and other descriptors. 3. Identify other special conditions for the message, such as repetition or true/false conditions. 4. Add the output return messages.

13.

What is meant by CRUD analysis? How is it done? CRUD stands for create, read (report), update, and delete. A CRUD analysis can be done by comparing the set of all use cases against the classes on the class diagram to make sure that every class has use cases that create, read, update and delete objects in those classes. In some instances, it may not be required to have all four functions, but an evaluation is required to make sure that nothing is left out inadvertently.

14.

What is the purpose of a state machine diagram? During analysis, state machine diagrams are used to describe the behavior of complex business objects. The primary focus of a state machine diagram is to identify the various states of a business object and to describe the ways in which the object moves from state to state.

15.

List the primary steps for developing a state machine diagram. 1. 2. 3. 4.

Pretend you are the object itself. Identify and model the states and transitions. Make sure you review the state machine diagram and make necessary changes. Make sure you haven’t left out any exception conditions. Review the class diagram, and select the classes that will require a state machine diagram.

Systems Analysis and Design in a Changing World, Fourth Edition

7-4

5. For each selected class in the group, make a list of all the status conditions you can identify. 6. Begin building state machine diagram fragments by identifying the transitions that cause an object to leave the identified state. 7. Sequence these state-transition combinations in the correct order. 8. Review the paths and look for independent, concurrent paths. 9. Look for additional transitions. 10. Expand each transition with the appropriate message event, guard-condition, and action-expression. 11. Review and test each state machine diagram. 16.

List the elements that make up a transition description. Which elements are optional? The elements are transition-name, guard-condition, and action-expression. All of these elements are optional. If a transition has none of these elements, it “fires” automatically when the object has finished any activity with the origin state.

17.

What is a composite state? What is it used for? A composite state is a state containing multiple states and transitions. It represents a higher level of abstraction and can contain nested states and transition paths.

18.

What is meant by the term path? A path is a sequential set of connected states and transitions.

19.

What is the purpose of a guard-condition? A guard-condition indicates the condition that must be true before a transition can occur

20.

Identify the models explained in this chapter and their relationship to each other. A use case diagram identifies all of the use cases of the system. A class diagram identifies the domain classes for the system. A CRUD analysis ensures that these two diagrams are consistent with each other. Each use case is described either with a use case description (with various levels of detail) or an activity diagram. The use case description and activity diagram describe the internal flow of activities of the use case. A system sequence diagram shows the inputs and outputs of each use case. The state machine diagram identifies the states or status conditions an object can be in. It shows possible steps in a use case or identifies the need for a use case.

Systems Analysis and Design in a Changing World, Fourth Edition

7-5

Thinking Critically 1.

To review your skills in developing a class diagram, develop a domain class diagram, including associations and multiplicities, based on the following narrative. This case is a simplified (initial draft) of a new system for the University Library. Of course, the library system must keep track of books. Information is maintained about both book titles and the individual book copies. Book titles maintain information about title, author, publisher, and catalog number. Individual copies maintain copy number, edition, publication year, ISBN, book status (whether it is on the shelf or loaned out), and date due back in. The library also keeps track of patrons to the library. Because it is a university library, there are several types of patrons, each with different privileges. There are faculty patrons, graduate student patrons, and undergraduate student patrons. Basic information about all patrons is name, address, and telephone number. For faculty patrons, additional information is office address and telephone number. For graduate students, information such as graduate program and advisor information is maintained. For undergraduate students, program and total credit hours are maintained. The library also keeps information about library loans. A library loan is a somewhat abstract object. A loan occurs when a patron approaches the circulation desk with a stack of books to check out. Over time a patron can have many loans. A loan can have many physical books associated with it. (And a physical book can be on many loans over a period of time. Information about past loans is kept in the database.) So, in this case, an association class should be created for loaned books. If a book is checked out that a patron wants, he/she can put that title on reserve. This is another class that does not represent a concrete object. Each reservation is for only one title and one patron. Information such as date reserved, priority, and date fulfilled is maintained. When it is fulfilled, the system associates it with the loan on which it was checked out.

Systems Analysis and Design in a Changing World, Fourth Edition

2.

7-6

Develop a use case diagram for the university library system.   Part a. Based on the following descriptions, build a preliminary use case diagram.   Patrons have access to the library information to search for book titles and to see  whether a book is available. A patron can also reserve a title if all copies are  checked out. When patrons bring books to the circulation desk, a clerk checks out  the books on a loan. Clerks also check books in. When books are dropped in the  return slot, they check in the books. Stocking clerks keep track of the arrival of new  books.   The managers in the library have their own activities. They will print out reports of  book titles by category. They also like to see (online) all overdue books. When books  get damaged or destroyed, they will delete information about book copies.   Managers also like to see what books are on reserve.  

Systems Analysis and Design in a Changing World, Fourth Edition

7-7

Search for book title Print book title Patron Researve a book

Delete book copy information

Check out books

View overdue books Clerk

Manager

Check in books

View book reservations Enter new book information

Stocking Clerk

Part b.  Given the class diagram you developed in question 1, do a CRUD analysis  and list any new use cases you discover. Or, if you change the name of any use cases,  indicate that also. In this case, patron information can be accessed and downloaded  from another university database.  Use Case

Book Title

Book Copy

Search for book title Reserve book Check out books Check in book Enter new book information Print book title report Delete book copy information View overdue books View reservations

R

R U

C R

Loan

C U

Book Copy On Loan C U

Patron

Reservation

C U

C D R R

Systems Analysis and Design in a Changing World, Fourth Edition

NEW USE CASES Update book information Update patron information Correct reservation Print loaned book reports View patron information Remove book from library END OF PERIOD CLEANUP Remove old loan information Remove old reservation information 3.

U

7-8

U U U R

R R

D

D D

D D

To review your skills in developing a class diagram, develop a class diagram,  including associations and multiplicities, based on the following narrative. A clinic  with three dentists and several dental hygienists needed a system to help administer  patient records. This system does not keep any medical records. It only processes  patient administration.  Each patient has a record with his/her name, date of birth, gender, date of first visit, and date of last visit. Patient records are grouped together under a household. A  household has attributes such as name of head of household, address, and telephone  number. Each household is also associated with an insurance carrier record. The  insurance carrier record contains name of insurance company, address, billing  contact person, and telephone number.  In the clinic, each dental staff person also has a record that tracks who works with a patient (dentist, dental hygienist, x­ray technician). Because the system focuses on  patient administration records, only minimal information is kept about each dental  staff person, such as name, address, and telephone number. Information is  maintained about each office visit, such as date, insurance copay amount (amount  paid by the patient), paid code, and amount actually paid. Each visit is for a single  patient, but, of course, a patient will have many office visits in the system. During  each visit, more than one dental staff person may be involved in the visit by doing a  procedure. For example, the x­ray technician, dentist, and dental hygienist may all  be involved in a single visit. In fact, some dentists are specialists in such things as  crown work, and even multiple dentists may be involved with a patient. For each  staff person does procedure in a visit combination (many­to­many), detailed  information is kept about the procedure. This information includes type of  procedure, description, tooth involved, the copay amount, the total charge, the  amount paid, and the amount insurance denied. 

Systems Analysis and Design in a Changing World, Fourth Edition

7-9

Finally, the system also keeps track of invoices. There are two types of invoices:  invoices to insurance companies and invoices to heads of household. Both types of  invoices are fairly similar, listing each visit, the procedures involved, the patient  copay amount, and the total due. Obviously, the totals for the insurance company  are different from the patient amounts owed. Even though an invoice is a report  (printed out), it also maintains some information such as date sent, total amount,  amount already paid, amount due and also the total received, date received, and  total denied. (Insurance companies do not always pay all they are billed.) 

Systems Analysis and Design in a Changing World, Fourth Edition

4.  

7-10

Develop a use case diagram for the dental clinic. Part a.  Develop a use case diagram based on the following narrative. The  receptionist keeps track of patient and head of household information. He/she will  enter information about the patients and head of household. He/she will also keep  track of office visits by the patients. Patient information is also entered and  maintained by the office business manager. In addition, the business manager  maintains the information about the dental staff persons.   The business manager also prints the invoices. Patient invoices are printed monthly  and sent to the head of household. Insurance invoices are printed weekly. When the  invoices are printed, the business manager double­checks a few invoices against  information in the system to make sure it is being aggregated correctly. She also  enters the payment information when it is received.   Each dental staff person is responsible for entering information about the dental  procedures that he/she performs.   The business manager also prints an overdue invoice report showing heads of  household who are behind on their payments. Sometimes dentists like to see a list of  the procedures they performed during a week or month, and they can request that  report.  

Systems Analysis and Design in a Changing World, Fourth Edition

7-11

Record office visit information

Receptionist

Record dental procedure

Dental Staff

Print invoices

Maintain patient information

Enter payment

View procedure information Office Manager

Print procedures report Print overdue accounts

Part b. Expand the use case diagram you have developed based on a CRUD analysis of the class diagram you developed in the previous problem.  Use Case Record office visit information Maintain patient information Print invoices Enter payment View procedure information Print overdue accounts Record dental procedure Print procedure report

House hold

Patient Visit C, U

C, U

C, U C, R U

U R R C R

NEW USE CASES Maintain dental staff Update procedure Maintain insurance company END OF PERIOD CLEANUP Remove old patient information

Medical Medical Insurance Invoice Staff Staff on Company Visit

C, U, D U C, U D

D

D

D

D

Systems Analysis and Design in a Changing World, Fourth Edition

Remove old invoices

7-12

D

Systems Analysis and Design in a Changing World, Fourth Edition

5.  

7-13

Interpret and explain the use case diagram in Figure 7­29. Explain the various roles  of those using the system and what functions each role requires. Explain the  relationships and how the use cases are related to each other. 

Figure 7­29.  A use case diagram for the inventory system. Three actors invoke use cases: a purchasing clerk, a receiving dock clerk, and a shipping  clerk.  Note that these three actors represent roles, all of which could be done by the same physical person.  The purchasing clerk uses the system to Enter new inventory items.   The shipping clerk only uses the system to Ship items. However, the Ship items use case  also includes the Update quantity on hand use case. This means that the Ship items use  case will invoke the Update quantity on hand use case to carry out its function.  The receiving dock clerk uses the system to do three things: Enter receipt of inventory,  Update quantity on hand, and Enter a return. Both the Enter receipt of inventory and  Enter a return use cases also include the Update quantity on hand use case. Thus, the  Update quantity on hand use case can be invoked directly by the receiving dock clerk or  by the three other use cases. 

Systems Analysis and Design in a Changing World, Fourth Edition

6.

7-14

Given the following narrative, do the following:  a. Develop an activity diagram for each scenario, and b. Complete a fully developed use case description for each scenario Quality Building Supply has two kinds of customers: contractors and the general  public. Sales to each are slightly different.  When a contractor buys materials, he/she takes them to the contractor checkout  desk. The clerk enters the contractor name into the system. The system displays the  contractor information, including his/her current credit standing.   The clerk then opens up a new ticket (sale) for the contractor. Next, the clerk scans  in each item to be purchased. The system finds the price of the item and adds the  item to the ticket. At the end of the purchase, the clerk indicates the end of the sale.  The system compares the total amount against the contractor’s current credit limit,  and if it is acceptable, finalizes the sale. The system creates an electronic ticket for  the items, and the contractor’s credit limit is reduced by the amount of the sale.  Some contractors like to keep a record of their purchases, so they request that the  ticket details be printed out. Others aren’t interested in a printout.  A sale to the general public is simply entered into the cash register, and a paper  ticket is printed as the items are identified. Payment can be by cash, check, or credit card. The clerk must enter the type of payment to ensure that the cash register  balances at the end of the shift. For credit card payments, the system prints out a  credit card voucher that the customer must sign. 

Systems Analysis and Design in a Changing World, Fourth Edition

7-15

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions: Postconditions: Flow of Activities:

Exception Conditions:

7-16

Create a new sale Create new sale to a contractor (on account sale) Contractor wants to purchase items. A contractor wants to purchase items. The clerk rings up the items and then adds them to the contractor’s account. Sales clerk Sales clerk Accounting department Sales department Customer account must exist. Inventory items must exist. New sale is created. Sales line items are created and connected to the sale. Customer (contractor) account is updated. Actor System 1. Clerk enters contractor ID. 1.1 System validates contractor account. 2. Clerk enters each item. 2.1 System finds item in inventory, finds price, adds to 3. Clerk indicates the end of the sale. total. 3.1 System calculates total and 4. If contractor wants receipt, requests adds to contractor account. receipt. 4.1 System prints receipt. 1.1 If contractor account is out of balance, treat this sale as a cash sale, or stop process and send contractor to accounting clerk. 2.1 If system has information missing, sales clerk calls manager and manually enters information. 3.1 If contractor account balance is over the limit, treat as cash sale, cancel, or send contractor to accounting clerk.

Systems Analysis and Design in a Changing World, Fourth Edition

7-17

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions: Postconditions: Flow of Activities:

Create a new sale A new cash sale Cash customer wants to purchase items. A cash customer wants to purchase items. The clerk enters the item ID, and the system creates a sales ticket. Customer pays with cash, check or credit card. Sales clerk Sales clerk Accounting department Sales department Inventory items must exist. New sale is created. Sales line items are created and connected to the sale. Payment transaction is created. Actor System 1. Clerk starts new cash sale. 2. Clerk enters each item.

Exception Conditions:

7-18

3. Clerk indicates the end of the sale.

2.1 System finds item in inventory, finds price, displays information, adds to total. 3.1 System calculates total.

4. Clerk indicates type of payment and enters information.

4.1 System processes payment and creates payment transaction.

2.1 If system has information missing, sales clerk calls manager and manually enters information. 4.1 If customer credit card fails approval, require cash or cancel sale.

Systems Analysis and Design in a Changing World, Fourth Edition

7.

7-19

Given the following narrative, develop an activity diagram for a use case of Add a new vehicle to an existing policy in a car insurance system. A customer calls an insurance clerk at the insurance company and gives his/her policy number. The clerk enters this information, and the system displays the basic insurance policy. The clerk then checks the information to make sure the premiums are current and the policy is in force. The customer gives the make, model, year, and vehicle identification number (VIN) of the car to be added. The clerk enters this information, and the system ensures that the given data is valid. Next, the customer selects the types of coverage desired and the amount of each. The clerk enters the information, and the system records each and validates the requested amount against the policy limits. After all of the coverages have been entered, the system validates the total coverage against all other ranges, including other cars on the policy. Finally, the customer must identify all drivers and the percent of time they drive the car. If a new driver is to be added, another use case, Add new driver, is invoked. At the end of the process, the system updates the policy, calculates a new premium amount, and prints the updated policy statement to be mailed out to the policy owner.

Systems Analysis and Design in a Changing World, Fourth Edition

7-20

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions: Postconditions:

Flow of Activities:

Exception Conditions:

7-21

Add a new vehicle to an existing policy Telephone instance with customer and clerk Customer buys a new vehicle. Customer provides car information, requests coverage with amounts, identifies drivers of the new car. System updates the policy. Customer service clerk Customer Customer service department Customer policy must exist and be up to date. StandardVehicle control tables for this vehicle type and year must exist. StandardCoverage tables exist. New vehicle object created and connected to policy. Also connected to StandardVehicle. New coverage objects created and connected to vehicle. Also connected to StandardCoverage. New driver (InsuredPerson) (if necessary) created and added to policy. Existing drivers and percentages updated. Policy updated with new premiums. Actor System 1. Clerk enters customer information. 1.1 System finds policy and 2. Clerk verifies policy is current. displays details. 3. Clerk enters car identification 3.1 System validates that car has information. known standard. 4. Clerk enters each type of coverage 4.1 System validates coverage customer requests, including requests. deductibles and coverage amount. 5. Clerk indicates all coverages have 5.1 System does combination been entered. validation on policy. 6. Clerk invokes Add new person use case if necessary. 7. Clerk changes driver percentages on 7.1 System updates driver this car and other cars. information. 8. Clerk indicates everything is 8.1 System updates policy, complete. calculates new premium, prints new statement. 2.1 If policy is not current, clerk requests payment or collects necessary information. 3.1 If car type is not in system, clerk refers customer to underwriting to handle this situation. 4.1 If coverage requests are out of range, clerk asks customer for changed amount. 5.1 If some combination is invalid, return to step 4.

Systems Analysis and Design in a Changing World, Fourth Edition

8.

7-22

Given the following list of classes and relationships for the previous car insurance  system, list the preconditions and the postconditions for the Add a new vehicle to an  existing policy use case.   Classes in the system:  Policy  InsuredPerson  InsuredVehicle  Coverage   StandardCoverage (list standard insurance coverages with prices by rating  category)  StandardVehicle (lists all types of vehicles ever made) Relationships in the system:  Policy has InsuredPersons (one to many)  Policy has InsuredVehicles (one to many)  Vehicle has Coverages (one to many)   Coverage is a type of StandardCoverage  Vehicle is a StandardVehicle

Preconditions: Postconditions:

Customer policy must exist and be up to date. StandardVehicle control tables for this vehicle type and year must exist. StandardCoverage tables exist. New vehicle object created and connected to policy. Also connected to StandardVehicle. New coverage objects created and connected to vehicle. Also connected to StandardCoverage. New driver (InsuredPerson) (if necessary) created and added to policy. Existing drivers and percentages updated. Policy updated with new premiums.

Systems Analysis and Design in a Changing World, Fourth Edition

9.  

Develop a system sequence diagram based on the narrative and your activity  diagram for problem number 6.  

7-23

Systems Analysis and Design in a Changing World, Fourth Edition

7-24

Systems Analysis and Design in a Changing World, Fourth Edition

10.  

Develop a system sequence diagram based on the narrative and your activity  diagram for problem number 7. 

7-25

Systems Analysis and Design in a Changing World, Fourth Edition

11.  

7-26

Review the cellular telephone state machine diagram in Figure 7-30, and then answer the following questions. (Note that this telephone has unique characteristics that are not found in ordinary telephones. Base your answers only on the state machine diagram.) a.

What event turns on the telephone? You have to switch it on.

b.

What states does the telephone go into when it is turned on? It goes into the Quiet state for one path. It can also go into Charged, Low Warning, or Discharged.

c.

What are the three ways that the telephone can be turned off? Identify what must be true for each case. SwitchOff, Quiet and Low Warning, or Discharged. The telephone must be turned on.

d.

Can the telephone turn off in the middle of the Active (Talking) state. Yes, if it is discharged, it leaves the Discharged nested state and the On composite state.

e.

How can the telephone get to the Active (Talking) state? Through the origin state of connecting or by answering from the origin state of ringing.

f.

Can the telephone be plugged in while someone is talking? No. The state chart says it can only be plugged in from the Quiet state.

g.

Can the telephone change battery states while someone is talking? Explain which movement is allowed, and which is not allowed. It can go from Charged to Low Warning and from Low Warning to Discharged. However, because it cannot be plugged in while someone is talking, it cannot move back up from Discharged to Low Warning or Charged.

h.

What states are concurrent with what other states? Make a two-column table showing the concurrent states. Concurrent States Quiet, Dialing, Connecting, Ringing, Charged, Low Warning, Discharged Active, and Plugged In

Systems Analysis and Design in a Changing World, Fourth Edition

12.

7-27

Given the following description of a shipment by Union Parcel Shipments, first identify all of the states and exit transitions, and then develop a state machine diagram. A shipment is first recognized after it has been picked up from a customer. After it is in the system, it is considered to be active and in transit. Every time is goes through a checkpoint, such as arrival at an intermediate destination, it is scanned, and a record is created indicating the time and place of the checkpoint scan. The status changes when it is placed on the delivery truck. It is still active, but not it is also considered to have a status of delivery pending. Of course, after it is delivered, the status changes again. From time to time, a shipment has a destination that is outside the area served by Union. In those cases, Union has working relationships with other courier services. After a package is handed off to another courier, it is noted as being handed over. In those instances, a tracking number for the new courier is recorded (if it is provided). Union also asks the new courier to provide a status change notice after the package has been delivered. Unfortunately, from time to time a package gets lost. In that case, it remains in an active state for two weeks but is also marked as misplaced. If after two weeks the package has not been found, it is considered lost. At that point, the customer can initiate lost procedures to recover any damages.

Systems Analysis and Design in a Changing World, Fourth Edition

7-28

Experiential Exercises 1.

The functionality required by Rocky Mountain Outfitters’ customer support system is also found in several real-world companies. Based on your experience with online shopping and shopping carts, build a use case diagram of functions that can be done by a Web customer (similar to Figure 7-4). Web sites that you might refer to include L.L. Bean (http://www. llbean.com/), Lands’ End (http://www.landsend.com/), Amazon.com (http://www.amazon.com/), and Barnes and Noble Booksellers (http://www.barnesandnoble.com/). Answers will vary. The use case diagram should be similar to the RMO diagram.

2.

Develop fully developed use case descriptions for each of the use cases you defined in exercise 1. Answers will vary. Cross-reference the use case descriptions with the use case diagram developed in exercise 1.

3.

Based on the flow of activities you developed in exercise 2, develop system sequence diagrams for those same use cases and scenarios. Add preconditions and postconditions to each use case.

Systems Analysis and Design in a Changing World, Fourth Edition

7-29

Answers will vary. Cross-reference the system sequence diagram with the use case diagram developed in exercise 1.

Analyze the information requirements of the Web site from exercise 1. Doing a reverse CRUD analysis (going from the use case diagram to the domain model class diagram) will help you identify classes. Develop a domain model class diagram.

4.

Answers will vary. Cross-reference the domain class diagram with the use case diagram developed in exercise 1.

Locate a company in your area that does software development. A company that is either a consulting company or has a large staff of information systems professionals will tend to be more rigorous in its approach to software development. Set up an interview. Determine the development approaches that they use. Many companies still use traditional structured techniques combined with some object-oriented development. In other companies, some projects are structured, while other projects are object-oriented. Find out what kinds of modeling the company does for requirements specification. Compare your findings with the techniques taught in this chapter.

5.

Answers will vary. Make sure that the company selected is rigorous in its approach of software development.

6.

IBM Rational is a company that is a wholly own subsidiary of IBM. The authors of UML have also been executives in Rational Rose. Consequently, IBM Rational was an early leader in developing CASE tools to support UML and object-oriented modeling. You can download an evaluation copy of IBM Rational’s UML CASE (IBM Rational XDE Modeler) tool and use the tool to draw the RMO diagrams. This will give you experience with a widely used industry tool. Alternatively, your college or university can enroll in the Seed program and provide copies of the tools in its laboratories. The URL is http://www-306.ibm.com/software/rational. No questions are asked.

Systems Analysis and Design in a Changing World, Fourth Edition

7-30

Case Studies Case Study: The Real Estate Multiple Listing Service System Refer to the description of the Real Estate Multiple Listing Service System in the Chapter 5 case studies. Using the event list and ERD for that system as a starting point, develop the following object-oriented models: 1.

Convert your ERD to a domain class diagram.

Systems Analysis and Design in a Changing World, Fourth Edition

2.

7-31

Develop a use case diagram.

Add a listing

Requst listing information

Print listing book

MLS Clerk

Maintain real estate office information

Maintain agent information

Agent

Change listing information

3.

Develop a fully developed use case description or an activity diagram for each use case. Solutions below develop both in pairs.

Systems Analysis and Design in a Changing World, Fourth Edition

7-32

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions: Postconditions: Flow of Activities:

Add a listing Add a single listing Agent wants to add a listing to the database. Clerk in the MLS office MLS clerk Agent RE office clerk Real estate agent must exist. New listing object must exist. Actor 1. Enters agent information. 2. Enters new listing information.

Exception Conditions:

1.1 Agent is not found in the database.

Use Case Name: Scenario: Triggering Event: Brief Description: Actors:

Request listing information Agent requests listing information Agent wants listing information.

Stakeholders: Preconditions: Postconditions: Flow of Activities:

Exception Conditions:

7-33

RE agent MLS clerk Agent Agent must exist. Listing must exist. None Actor 1. Enters agent information. 2. Requests listing based on search criteria, such as location, price range, listing agent, and so on. 1.1 Agent is not found. 2.1 No listing matches are found.

System 1.1 Verifies agent and finds and display status. 2.1 Creates new listing and displays information.

System 1.1Verifies requesting agent and displays agent information. 2.1 Finds and displays listing information.

Systems Analysis and Design in a Changing World, Fourth Edition

7-34

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions: Postconditions: Flow of Activities: Exception Conditions: Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions: Postconditions: Flow of Activities:

Print listing book Simple printing of book It is time to print listing book. MLS clerk Agents Offices Listing data must exist. None Actor 1. Enters listing print request. Enters any special selection criteria. None

System 1.1 Queries the database. Prints the listings.

Change listing information Update existing listing information Agent needs to change listing information. Real estate agent MLS clerk Agent Office Agent Listing is changed. Actor 1. Enters agent ID. 2. Enters listing number. 2a. Invokes RequestListing use case. 2b. Chooses listing to update. 3. Enters listing updates.

Exception Conditions:

7-35

System 1.1 Verifies and displays agent information. 2a.1 Gets listing information. Validates agent has rights to change listing. Displays data. 3.1 Updates and displays listing information.

1.1 Agent is not found. 2.1 Listing is not found. 3.1 Agent is not authorized to change listing.

Systems Analysis and Design in a Changing World, Fourth Edition

7-36

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions: Postconditions: Flow of Activities:

Exception Conditions:

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions: Postconditions: Flow of Activities:

Add/update real estate office information Add a new real estate office A new real estate office has joined the organization. MLS clerk Office manager Clerk None Real estate office exists. Actor 1. Requests blank form. 2. Enters real estate office information. 3. Checks information for accuracy. 2.1 Duplicate of existing RE office.

System 1.1 Displays blank form. 2.1 Assigns new key. Creates a new RE office record. Displays information.

Add/update agent information Add/update agent information Agent information needs to be updated. MLS clerk Agent Clerk Real estate office exists. Real estate agent exists. Actor 1. Enters RE office ID. 2. If new agent, enters new agent information. 3. If existing agent, selects from current list. 3a. Enters agent updates.

Exception Conditions:

7-37

System 1.1 Finds and displays real estate office information. Displays current list of agents. 2.1 Creates agent record. 3.1 Displays current agent information. 3a.1 Updates agent information.

Systems Analysis and Design in a Changing World, Fourth Edition

4.

Develop a system sequence diagram for each use case.

7-38

Systems Analysis and Design in a Changing World, Fourth Edition

7-39

Case Study: State Patrol Ticket Processing System Refer to the description of the State Patrol Ticket Processing System in the Chapter 5 case studies. Using the event list and ERD for that system as a starting point, develop the following object-oriented models:  Convert your ERD to a class diagram.  Develop a use case diagram.  Develop fully developed use case descriptions for two of the primary use cases.  Develop a system sequence diagram for those same use cases.  Develop a state machine diagram for a ticket.

Ticket Driver licenseNumber licenseClass name address expirationDate dateOfBirth Restiction

1

0..*

ticketNumber dateOfTicket timeOfTicket violationType fineAmount datePaid plea trialDate verdict

0..* 1

Court courtNumber name address

Officer

0..*

1

badgeNumber name rank primaryAssignment mailingAddress

Systems Analysis and Design in a Changing World, Fourth Edition

7-40

Record traffic ticket

Enter payment information

Enter plea

Enter trial verdict Motor Vehicles Clerk

Request warrant

Use Case Name: Scenario: Triggering Event: Brief Description:

Actors: Stakeholders: Preconditions: Postconditions: Flow of Events:

Exception Conditions:

Record traffic ticket Record traffic ticket Officer sends in new ticket The officer gives the traffic ticket to the clerk. Using the information on the traffic ticket, the clerk first verifies the officer by entering the badge number. Then, the clerk verifies the driver information by entering the driver’s license number. Finally, the clerk enters the ticket information. Clerk Manager Officer The officer must exist. The driver must exist. The ticket must exist and be associated with the driver, the officer, and a court. Actor System 1. Clerk enters officer badge number. 1.1 System reads officer information and displays the name. 2. Clerk enters driver’s license 2.1 System reads the driver number. information and displays the driver name and address. 3. Clerk enters ticket information. 3.1 System displays ticket and driver information. 1.1 Officer is not found. 2.1 Driver is not found.

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions: Postconditions: Flow of Events:

Exception Conditions:

7-41

Enter plea Enter not guilt plea Driver requests trial. The clerk reviews the letter from the driver. If the driver requests a court date (pleads not guilty), the clerk enters that information. The system produces a formatted return letter to the driver. Clerk Manager The driver must exist. The ticket information must exist. The court must exist. The ticket information is updated. Actor System 1. The clerk enters the not guilty plea 1.1 The system finds the driver requesting a court date. and ticket and updates the ticket information. 1.1 Driver or ticket cannot be found in the system.

Systems Analysis and Design in a Changing World, Fourth Edition

7-42

Systems Analysis and Design in a Changing World, Fourth Edition

7-43

Case Study: DownTown Video Rental System DownTown Videos is a chain of 11 video stores scattered throughout a major metropolitan area in the Midwest. The chain started with a single store several years ago and has grown to its present size. Paul Lowes, the owner of the chain, knows that to compete with the national chains will require a state-of-the-art movie rental system. You have been asked to develop the system requirements for the new system. Each store has a stock of movies and video games for rent. It is important to keep track of each movie title to know and to identify its category (classical, drama, comedy, and so on), its rental type (new release, standard), movie rating, and other general information such as movie producer, release date, cost, and so forth. In addition to tracking each title, the business must track each individual copy to note its purchase date, its condition, and its rental status. User functions must be provided to maintain this inventory information. Customers, the lifeblood of the business, are also tracked. DownTown considers each family to be a customer, so special mailings and promotions are offered to each household. For any given customer, several people may be authorized to rent videos and games. The primary contact for each customer can also establish rental parameters for other members of the household. For example, if a parent wants to limit a child’s rental authorization to only PG and PG-13 movies, the system will track that. Each time a movie is rented, the system must keep track of which copies of which movies and games are rented; the rental date and time and the return date and time; and the household and person renting the movie. Each rental is considered to be open until all of the movies and games have been returned. Customers pay for rentals when checking out videos at the store. For this case, develop the following diagrams: 1. 2. 3. 4. 5.

A domain model class diagram. A use case diagram. Analyze user functions. Also do a CRUD analysis based on the class diagram. An activity diagram for each of the use cases having to do with renting and checking in movies and for the use cases to maintain customer and family member information. A system sequence diagram for each of the use cases from problem 3. A state machine diagram identifying the possible states (status conditions) for a physical copy of a movie, based on the use case descriptions provided earlier in the chapter and your knowledge of how a video store might work.

Systems Analysis and Design in a Changing World, Fourth Edition

7-44

Systems Analysis and Design in a Changing World, Fourth Edition

7-45

Maintain customer information

Enter new movies

Rent movies

Return movies Movie Clerk

Defined Customer Use Cases Maintain CUD customer information Enter new movies Rent movies Return a movie Additional Use Cases Customer R report Update movies Print movie list Update rentals Print outstanding rentals

Family Member CUD

Conceptual Movie

Movie

C

C

Rental

Rental Item

C C

R UD

UD

R

R UD

UD

R

R

Systems Analysis and Design in a Changing World, Fourth Edition

7-46

Systems Analysis and Design in a Changing World, Fourth Edition

7-47

Systems Analysis and Design in a Changing World, Fourth Edition

7-48

Systems Analysis and Design in a Changing World, Fourth Edition

7-49

Systems Analysis and Design in a Changing World, Fourth Edition

7-50

Systems Analysis and Design in a Changing World, Fourth Edition

7-51

Systems Analysis and Design in a Changing World, Fourth Edition

7-52

Case Study: TheEyesHaveIt.Com Book Exchange TheEyesHaveIt.com Book Exchange is a type of e-business exchange that does business entirely on the Internet. The company acts as a clearing exchange for both buyers and sellers of used books. For a person to offer books for sale, he/she must register with EyesHaveIt. The person must provide a current physical address and telephone number as well as a current e-mail address. The system will then maintain an open account for this person. Access to the system as a seller is through a secure, authenticated portal. A seller can list books on the system through a special Internet form. Information required includes all of the pertinent information about the book, its category, its general condition, and the asking price. A seller may list as many books as desired. The system maintains an index of all books in the system so that buyers can use the search engine to search for books. The search engine allows searches by title, author, category, and keyword. People wanting to buy books come to the site and search for the books they want. When they decide to buy, they must open an account with a credit card to pay for the books. The system maintains all of this information on secure servers. When a request to purchase is made, along with the payment, TheEyesHaveIt.com sends an e-mail notice to the seller of the book that was chosen. It also marks the book as sold. The system maintains this as an open order until it receives notice that the books have been shipped. After the seller receives notice that a listed book has been sold, he/she must notify the buyer via e-mail within 48 hours that the purchase is noted. Shipment of the order must be made within 24 hours after the seller sends the notification e-mail. The seller sends a notification to both the buyer and TheEyesHaveIt.com when the shipment is made. After receiving notice of shipment, TheEyesHaveIt.com maintains the order in a shipped status. At the end of each month, a check is mailed to each seller for the book orders that have been in a shipped status for 30 days. The 30-day waiting period is to allow the buyer to notify TheEyesHaveIt.com if the shipment does not arrive for some reason, or if the book is not in the same condition as advertised. The buyers can, if they want, enter a service code for the seller. The service code is an indication of how well the seller is servicing book purchases. Some sellers are very active and use TheEyesHaveIt.com as a major outlet for selling books. So, a service code is an important indicator to potential buyers. For this case, develop the following diagrams: 1. 2.

A domain model class diagram. A use case diagram.

Systems Analysis and Design in a Changing World, Fourth Edition

3. 4.

7-53

A fully developed description of the use cases for two use cases such as Add a Seller  and Record a book order. A system sequence diagram for each of the two use cases in problem 3. 

Systems Analysis and Design in a Changing World, Fourth Edition

7-54

Register

List a book Seller

Notify shipment made

Search for book

Notify seller about purchase -

Open account -

Send check to seller

Buyer

EyesHaveIt Employee Purchase a book

Enter problem with purchase Enter satisfaction code

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors:

7-55

Register Register/add a new seller A new seller wants to sell books. Seller decides he/she would like to list a book(s). Seller registers and receives a confirmation e-mail. Seller E-mail server

Stakeholders: Preconditions:

Seller must not exist in the system. Seller must have all information necessary to register. Postconditions: Seller has an account to list books. Flow of Activities: Actor System 1. Seller connects to EyesHaveIt.com and fills out registration form. 2. Seller submits registration form.

Exception Conditions:

2.1 System notifies seller a confirmation e-mail will be sent. 2.2 System e-mails confirmation of registration to seller. 1.1 If the seller already exists in the system, the system sends prior login and password to e-mail address. 2.1 If the seller was removed from the system for bad transactions/credit, the system sends the seller an e-mail notifying the seller of the situation and no account is created.

Use Case Name: Scenario: Triggering Event: Brief Description:

Actors: Stakeholders: Preconditions: Postconditions:

Purchase a book Purchase a book A buyer decides to purchase a book from EyesHaveIt.com. Customer searches for a book(s) on EyesHaveIt.com. Customer selects from search results and adds a book(s) to the shopping cart. Customer then proceeds to checkout. If an account exists, the customer confirms purchase, and the system sends a confirmation e-mail to the customer. If an account doesn’t exist, an account is created, the purchase is confirmed, and the confirmation e-mail is sent. Buyer E-mail server Seller Books and book information must exist in the system. Customer account must exist. Order must be placed. E-mail must be sent to seller.

Systems Analysis and Design in a Changing World, Fourth Edition

Flow of Activities:

7-56

Actor 1. Buyer searches EyesHaveIt.com for a book(s).

System 1.1 Searches for all matches related to buyer’s search criteria.

2. Buyer selects a book(s) to purchase from search results.

2.1 Creates shopping cart. Adds selected item(s) to the shopping cart.

3. Repeat steps 1 and 2 until all desired books are added to shopping cart. 4. Customer proceeds to checkout by selecting the Checkout button.

4.1 Displays list of shopping cart items for verification.

4a. If customer wishes to remove an item, he/she selects the item to be removed and then selects the Delete button.

4a.1 Displays list of shopping cart items with deleted items removed.

4b. If buyer wishes to add an item, he/she selects the Continue Shopping button and proceeds to steps 1 and 2. 5. Buyer verifies displayed information.

5. Displays buyer information.

6. If information is incorrect or buyer account does not exist, buyer updates displayed information or enters new information into the registration form.

6.1 Updates new buyer information for existing account. 6.2 Creates account for new buyer and sends confirmation.

7. Buyer confirms purchase. Exception Conditions:

7.1 Records order. 7.2 Sends e-mail to seller. 1.1 If book is sold out, buyer cannot add book to shopping cart. 2.1 If buyer account does not exist, a new account must be created. If buyer is rejected for new account based on credit, system sends buyer notification. 3.1 If payment is rejected, system notifies buyer and seller.

Systems Analysis and Design in a Changing World, Fourth Edition

7-57

Systems Analysis and Design in a Changing World, Fourth Edition

7-58

Case Study: Rethinking Rocky Mountain Outfitters The event table for RMO is shown in Figure 5-16. Based on this event table, the use case diagram in Figure 7-5 was developed. The chapter illustrates detailed models (activity and system sequence diagrams) for Create new order. Using the information provided in the RMO case descriptions and the figures in the book (Figure 5-16 and 7-5), develop a fully developed use case description and system sequence diagram for each of the following Customer actor use cases: (1) Update order and (2) Create order return. Now do the same for both of the Shipping actor use cases.

Systems Analysis and Design in a Changing World, Fourth Edition

7-59

Systems Analysis and Design in a Changing World, Fourth Edition

7-60

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description:

7-61

Update order Update order when customer calls Customer changes or cancels an order. Customer calls in; the clerk and system verify the customer; the customer makes changes; the order is changed or canceled. Actors: Customer Order clerk Stakeholders: Shipping Preconditions: Customer must exist. Order must exist. Catalog, products, and inventory items must exist for requested changes. Postconditions: Order must be updated/canceled. Payment must be updated. Changes in inventory must be updated. Flow of Activities: Actor System 1. Customer calls to update order. 2. Order clerk verifies customer information. 3. Clerk retrieves order to be updated. 4. Clerk enters requested changes. 4.1 Updates changes. 5. Clerk verifies the item to be 5.1 Displays item information. updated. 6. Clerk adds/removes item from 6.1 Adds/removes item. order. 7. Repeat steps 4, 5, and 6 as needed. 8. Customer notifies clerk of all 8.1 Completes order/updates updates needed to be made. payment. 9. Customer makes additional 9.1 Verifies payment or is reimbursed. payment/reimbursement. 9.2 Changes order transaction. 9.3 Finalizes order. Exception Conditions:

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description:

7-62

Create order return Create order return when customer calls in Customer wants to return an item. Customer calls in; the order clerk and system verify the customer information; the customer wants to return the order; an order return is created. Actors: Customer Order clerk Stakeholders: Warehouse manager Preconditions: Customer must exist. Order must exist. Postconditions: Return must be created and connected to the order. Payment must be reimbursed. Changes in inventory must be updated. Flow of Activities: Actor System 1. Customer calls in to return item/order. 2. Order clerk verifies customer information. 3. Clerk retrieves order with item to be returned. 4. Clerk enters return request. 4.1 Creates order return. 5. Clerk gives customer return 5.1 Completes order return. confirmation. Exception Conditions:

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description:

7-63

Record backorder

Order item is out of stock and must be placed on backorder. Customer places an order, but the item is out of stock. Shipping gets the order, but they cannot place the order so they put it on backorder. Actors: Shipping clerk Stakeholders: Customer Preconditions: Order must exist. Items must be out of stock. Postconditions: Order is placed in backorder status. Flow of Activities: Actor System 1. Receives order, but items are out of stock. 2. Verifies order information. 2.1 Gathers order information. 3. Marks order status as backorder. 3.1 Records backorder. Exception 1.1 If the customer requests the order to be sent without the backordered Conditions: item, the shipping actor needs to split the order, send the unfinished order, and create a new backorder with the out-of-stock item. 1.1 If the item is permanently out of stock, the shipping actor needs to mark the item as unavailable so it is not ordered in the future. The shipping actor also needs to notify the customer that the item cannot be ordered and refund the customer for the permanently out-of-stock item.

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions:

7-64

Record order fulfillment Shipping sends out shipment for order Shipping receives and order. Shipping places all items in a box for shipping. Shipping prints a label to place on the box. Item status is changed to Pending Pick-Up after the item is labeled and ready for shipment. Shipping clerk

Customer must exist. Order must exist for that customer. Order items must be in stock. Postconditions: Order must be on the dock pending pick-up. Flow of Activities: Actor System 1. Receives order and retrieves order items. 2. Records items as they are placed in 2.1 Updates order item. the box. 3. Records items not available 3.1 Updates order items out of stock. Sends out-of-stock message to inventory system. 4. Requests shipping label. 4.1 Prints shipping label. Creates Shipment object. Exception Conditions:

1.1 If order item is out of stock, follow backorder procedures. 1.1 If order item is damaged, get new item and updated item quantity. 2.1 If item barcode is not scanning, shipping must enter barcode manually. 2.1 If item does not exist in system, notify manager to fix error. 2.1 If item quantity is not automatically updated by system, shipping must manually update item quantity. 4.1 If printing label is not printing correctly, generic label must be printed and information must be updated in the system manually. The label must be addressed manually. 5.1 If label scans incorrectly, shipping must correct information manually in the system or print a new label.

Systems Analysis and Design in a Changing World, Fourth Edition

7-65

Case Study: Focusing on Reliable Pharmaceutical Service Based on your previous work, the cases from prior chapters, and the description here, do the following: 1.

Refine and extend your domain model class diagram developed in Chapter 5 as necessary.

Systems Analysis and Design in a Changing World, Fourth Edition

7-66

Systems Analysis and Design in a Changing World, Fourth Edition

2.

7-67

Develop a use case diagram. Base it directly on the event table you created for Chapter 5. Be sure to include a CRUD analysis with your class diagram from question 1 and discuss what additional use cases might be needed based on your CRUD analysis.

Enter new order

Change order information

Enter new perscription

Update existing perscription

Create case manifest Record order fulfillment Pharmacist or Assistant Add new patient information

Maintain patient information

Staff

Print patient case label

Print org unit case label

Create purchase order for drug

Maintain payer information Add new drug

Maintain employee information Update drug information Add new health organization

Record receipt of drup information

Update health organization information

Manager

Systems Analysis and Design in a Changing World, Fourth Edition

Health Care Organization Enter new order Change order Enter new prescription Change prescription Record fulfillment Order case manifest Create new patient Update or delete patient Add new drug Update drug information Receive new drug Create PO for drug Maintain payer Add new health org Maintain health org Print patient case label Print org unit label

Health Care Unit

Empl

Patient

Order

Order Item

C

C

UD

UD

7-68

Prescript Drug

Drug Item

Drug Item in Package

C

C

C

U

U

U

U

U

U

U

Payer

C UD U

U

R

R

C UD

CUD C UD R R

Other use cases that may be needed include:       

Add/Maintain Employee Information Health Organization Reports Patient Reports Prescription Reports Drug Reports Inventory Reports Payer Reports

You may also need to add a new class for Purchase Orders to maintain information about outstanding POs. 3.

Develop an activity diagram for each use case related to entering new orders, creating case manifests, and fulfilling orders. You should have at least three activity diagrams. Write a fully developed use case description for each of these use cases.

Systems Analysis and Design in a Changing World, Fourth Edition

7-70

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions:

Postconditions:

Flow of Activities:

Enter new order Enter new order Health care organization calls with new patient order. HC clerk Staff Manager HC organization must exist. HC unit must exist. Drug must exist. Drug item must exist. Drug item package may possibly exist. Prescription may possibly exist. Patient may possibly exist. Order exists. Order item exists. Prescription exists. Patient exists. Staff Member 1. Begins new order (for secure log in, enters employee ID). 2. Enters HCOrg name and unit name. 3. For each patient: 3a. Enters patient name.

4. For each order item (prescription order item): 4a. Enters prescription identifier. 4c. Enters order item details for this prescription. 5. Ends order. Exception Conditions:

7-71

1.1 Employee ID is invalid.

System 1.1 Finds and verifies employee. Creates a new order 2.1 Finds HCOrg and unit. Displays information. 3a.1 Finds patient. Displays information. 3b.1 If not found, displays new patient screen (Enter New Patient use case). 4a.1 Finds and displays prescription information. 4b.1 If not found, displays new prescription screen (Enter New Prescription use case). 4c.1 Creates order item. 5.1 Finalizes order for HC unit.

Systems Analysis and Design in a Changing World, Fourth Edition

7-72

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions:

Postconditions: Flow of Activities:

Create case manifest Create case manifest Staff is ready to create a case manifest to fulfill orders. This use case prints a case manifest for an existing HC unit for all orders that were selected during this time period. Invoke the use case for each HC organization or for all organizations. Employee Employee Manager Order must exist. Order items must exist. HC organization must exist. HC unit must exist. Order is updated. Staff System 1. Enters HCOrganization identifier. 1.1 Finds and displays HC organization. Displays all HC units. 2. For each HC unit: 2.1 Displays selected unit 2a. Selects an HC unit. information. Displays all open orders for this time period. 3. Selects orders, or selects all.

Exception Conditions:

7-73

1.1 HCOrganization is not found. 2.1 No open orders for an HC unit.

3.1 Prints case manifests for selected orders.

Systems Analysis and Design in a Changing World, Fourth Edition

7-74

Systems Analysis and Design in a Changing World, Fourth Edition

Use Case Name: Scenario: Triggering Event: Brief Description: Actors: Stakeholders: Preconditions: Postconditions: Flow of Activities:

Exception Conditions:

7-75

Record order fulfillment Record order fulfillment Pharmacist fulfills order. Pharmacist or assistant Pharmacist Manager All objects must exist, including COrganization, HCUnit, Patient, Order, OrderItem, Prescription, Drug, DrugItem, Pharmacist (Employee). OrderItem is updated. Pharmacist (or assistant) 1. Enters employee identifier. 2. For each completed order: 2a. Enters order number (from case manifest).

System 1.1 Finds pharmacist. Displays information. Displays order fulfillment screen. 2.1 Finds and displays HCOrg, HCUnit, order information, and order items.

3. For each order item fulfilled: 3a. Selects order item.

3a.1 Displays order item, prescription, and patient details.

3b. Enters fulfillment information.

3b.1 Updates order item with fulfillment information.

4. Ends the order.

4.1 Updates order.

1.1 Employee is not found.

Systems Analysis and Design in a Changing World, Fourth Edition

4.

7-76

Develop a system sequence diagram for each use case you developed in question 3.

Systems Analysis and Design in a Changing World, Fourth Edition

7-77

Systems Analysis and Design in a Changing World, Fourth Edition

5.

7-78

Develop a state machine diagram for an order. addOrderItems ()

H

createOrder ()

Open

printCaseManifest ()

readyToFulfill ()

enterFulfillmentInfo ()

Ready for fulfillment

fulfillmentComplete ()

Fulfilled

archive()

H