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.
6. 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.
11. 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. Pretend you are the object itself. Identify and model the states and transitions. 2. Make sure you review the state machine diagram and make necessary changes. 3. Make sure you haven’t left out any exception conditions.
4. Review the class diagram, and select the classes that will require a state machine diagram.
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.
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.
2. 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.
Patron
Clerk
Stocking Clerk
Manager Print book title
Researve a book
Search for book title
Delete book copy information
View book reservations Enter new book
information Check in books Check out books
View overdue books
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 Loan Book Copy On Loan Patron Reservation
Search for book title R R
Reserve book C
Check out books U C C U
Check in book U U
Enter new book information C C
Print book title report R
Delete book copy information D
View overdue books R
NEW USE CASES
Update book information U U
Update patron information U
Correct reservation U
Print loaned book reports R R
View patron information R
Remove book from library D D
END OF PERIOD CLEANUP
Remove old loan information D D
Remove old reservation information D
3. 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, xray 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 xray 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 (manytomany), 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.
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.)
4. 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 doublechecks 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.
Receptionist
Dental Staff Office Manager
Maintain patient information Record office visit information Enter payment Print procedures report Record dental procedure View procedure information Print invoices 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 House
hold
Patient Visit Medical
Staff Medical Staff on Visit Insurance Company Invoice
Record office visit information C, U
Maintain patient information C, U C, U
Print invoices C, R
Enter payment U U
View procedure information R
Print overdue accounts R
Record dental procedure C
Print procedure report R
NEW USE CASES
Maintain dental staff C, U, D
Update procedure U
Maintain insurance company C, U
END OF PERIOD CLEANUP
5. Interpret and explain the use case diagram in Figure 729. 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 729. 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.
6. 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.
Use Case Name: Create a new sale
Scenario: Create new sale to a contractor (on account sale)
Triggering Event: Contractor wants to purchase items.
Brief Description: A contractor wants to purchase items. The clerk rings up the items and then adds them to the contractor’s account.
Actors: Sales clerk
Stakeholders: Sales clerk
Accounting department Sales department
Preconditions: Customer account must exist.
Inventory items must exist. Postconditions: New sale is created.
Sales line items are created and connected to the sale. Customer (contractor) account is updated.
Flow of Activities: Actor System
1. Clerk enters contractor ID. 2. Clerk enters each item.
3. Clerk indicates the end of the sale. 4. If contractor wants receipt, requests receipt.
1.1 System validates contractor account.
2.1 System finds item in inventory, finds price, adds to total.
3.1 System calculates total and adds to contractor account. 4.1 System prints receipt. Exception
Conditions:
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.
Use Case Name: Create a new sale
Scenario: A new cash sale
Triggering Event: Cash customer wants to purchase items.
Brief Description: 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.
Actors: Sales clerk
Stakeholders: Sales clerk
Accounting department Sales department
Preconditions: Inventory items must exist. Postconditions: New sale is created.
Sales line items are created and connected to the sale. Payment transaction is created.
Flow of Activities: Actor System
1. Clerk starts new cash sale. 2. Clerk enters each item.
3. Clerk indicates the end of the sale. 4. Clerk indicates type of payment and enters information.
2.1 System finds item in inventory, finds price, displays information, adds to total. 3.1 System calculates total. 4.1 System processes payment and creates payment transaction. Exception
Conditions:
2.1 If system has information missing, sales clerk calls manager and manually enters information.
7. 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.
Use Case Name: Add a new vehicle to an existing policy
Scenario: Telephone instance with customer and clerk
Triggering Event: Customer buys a new vehicle.
Brief Description: Customer provides car information, requests coverage with amounts, identifies drivers of the new car. System updates the policy.
Actors: Customer service clerk
Stakeholders: Customer
Customer service department
Preconditions: Customer policy must exist and be up to date.
StandardVehicle control tables for this vehicle type and year must exist. StandardCoverage tables exist.
Postconditions: 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.
Flow of Activities: Actor System
1. Clerk enters customer information. 2. Clerk verifies policy is current. 3. Clerk enters car identification information.
4. Clerk enters each type of coverage customer requests, including
deductibles and coverage amount. 5. Clerk indicates all coverages have been entered.
6. Clerk invokes Add new person use case if necessary.
7. Clerk changes driver percentages on this car and other cars.
8. Clerk indicates everything is complete.
1.1 System finds policy and displays details.
3.1 System validates that car has known standard.
4.1 System validates coverage requests.
5.1 System does combination validation on policy.
7.1 System updates driver information.
8.1 System updates policy, calculates new premium, prints new statement.
Exception Conditions:
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.
8. 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: Customer policy must exist and be up to date.
StandardVehicle control tables for this vehicle type and year must exist. StandardCoverage tables exist.
Postconditions: 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.
9. Develop a system sequence diagram based on the narrative and your activity diagram for problem number 6.
10. Develop a system sequence diagram based on the narrative and your activity diagram for problem number 7.
11. 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, Active, and Plugged In
12. 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.
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
Answers will vary. Cross-reference the system sequence diagram with the use case diagram developed in exercise 1.
4. 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.
Answers will vary. Cross-reference the domain class diagram with the use case diagram developed in exercise 1.
5. 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.
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.
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:
2. Develop a use case diagram. MLS Clerk Agent Requst listing information Add a listing Change listing information Print listing book
Maintain real estate office information
Maintain agent information
3. Develop a fully developed use case description or an activity diagram for each use case.
Use Case Name: Add a listing
Scenario: Add a single listing
Triggering Event: Agent wants to add a listing to the database. Brief Description:
Actors: Clerk in the MLS office
Stakeholders: MLS clerk
Agent
RE office clerk
Preconditions: Real estate agent must exist. Postconditions: New listing object must exist.
Actor System
Flow of Activities:
1. Enters agent information. 2. Enters new listing information.
1.1 Verifies agent and finds and display status.
2.1 Creates new listing and displays information. Exception
Conditions: 1.1 Agent is not found in the database. Use Case Name: Request listing information
Scenario: Agent requests listing information
Triggering Event: Agent wants listing information. Brief Description:
Actors: RE agent
MLS clerk
Stakeholders: Agent
Preconditions: Agent must exist. Listing must exist.
Postconditions: None
Actor System
Flow of Activities:
1. Enters agent information. 2. Requests listing based on search criteria, such as location, price range, listing agent, and so on.
1.1Verifies requesting agent and displays agent information. 2.1 Finds and displays listing information.
Exception
Use Case Name: Print listing book
Scenario: Simple printing of book
Triggering Event: It is time to print listing book. Brief Description:
Actors: MLS clerk
Stakeholders: Agents
Offices
Preconditions: Listing data must exist.
Postconditions: None
Actor System
Flow of Activities:
1. Enters listing print request. Enters any special selection criteria.
1.1 Queries the database. Prints the listings.
Exception
Conditions: None
Use Case Name: Change listing information
Scenario: Update existing listing information
Triggering Event: Agent needs to change listing information. Brief Description:
Actors: Real estate agent
MLS clerk
Stakeholders: Agent
Office
Preconditions: Agent
Postconditions: Listing is changed.
Actor System
Flow of Activities:
1. Enters agent ID. 2. Enters listing number.
2a. Invokes RequestListing use case. 2b. Chooses listing to update.
3. Enters listing updates.
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.
Exception
Conditions: 1.1 Agent is not found. 2.1 Listing is not found.
Use Case Name: Add/update real estate office information
Scenario: Add a new real estate office
Triggering Event: A new real estate office has joined the organization. Brief Description:
Actors: MLS clerk
Stakeholders: Office manager
Clerk
Preconditions: None
Postconditions: Real estate office exists.
Actor System
Flow of Activities:
1. Requests blank form. 2. Enters real estate office information.
3. Checks information for accuracy.
1.1 Displays blank form. 2.1 Assigns new key. Creates a new RE office record. Displays information.
Exception Conditions:
2.1 Duplicate of existing RE office.
Use Case Name: Add/update agent information
Scenario: Add/update agent information
Triggering Event: Agent information needs to be updated. Brief Description:
Actors: MLS clerk
Stakeholders: Agent
Clerk
Preconditions: Real estate office exists. Postconditions: Real estate agent exists.
Actor System
Flow of Activities:
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.
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. Exception
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.
licenseNumber licenseClass name address expirationDate dateOfBirth Restiction Driver ticketNumber dateOfTicket timeOfTicket violationType fineAmount datePaid plea trialDate verdict Ticket 1 0..* badgeNumber name rank primaryAssignment mailingAddress Officer 0..* 1 courtNumber name address Court 0..* 1
Motor Vehicles Clerk Enter payment information Record traffic ticket Enter plea
Enter trial verdict
Request warrant
Use Case Name: Record traffic ticket
Scenario: Record traffic ticket
Triggering Event: Officer sends in new ticket
Brief Description: 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.
Actors: Clerk
Stakeholders: Manager
Officer
Preconditions: The officer must exist. The driver must exist.
Postconditions: The ticket must exist and be associated with the driver, the officer, and a court.
Flow of Events: Actor System
1. Clerk enters officer badge number. 2. Clerk enters driver’s license number.
3. Clerk enters ticket information.
1.1 System reads officer information and displays the name.
2.1 System reads the driver information and displays the driver name and address. 3.1 System displays ticket and driver information.
Exception Conditions:
1.1 Officer is not found. 2.1 Driver is not found.
Use Case Name: Enter plea
Scenario: Enter not guilt plea
Triggering Event: Driver requests trial.
Brief Description: 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.
Actors: Clerk
Stakeholders: Manager
Preconditions: The driver must exist.
The ticket information must exist. The court must exist.
Postconditions: The ticket information is updated.
Flow of Events: Actor System
1. The clerk enters the not guilty plea
requesting a court date. 1.1 The system finds the driver and ticket and updates the ticket information.
Exception
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. A domain model class diagram.
2. A use case diagram. Analyze user functions. Also do a CRUD analysis based on the class diagram.
3. 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.
4. A system sequence diagram for each of the use cases from problem 3.
5. 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.
Movie Clerk
Enter new movies Maintain customer information Rent movies Return movies Defined Use Cases Customer Family Member Conceptual Movie
Movie Rental Rental
Item Maintain customer information CUD CUD Enter new movies C C Rent movies C Return a movie C Additional Use Cases Customer report R R Update movies UD UD Print movie list R R Update rentals UD UD Print outstanding rentals R R
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. A domain model class diagram.
3. A fully developed description of the use cases for two use cases such as Add a Seller and Record a book order.
Seller
Buyer EyesHaveIt Employee
List a book Register
Send check to seller Open account
Search for book
Enter problem with purchase Notify seller about purchase Enter satisfaction code Notify shipment made Purchase a book -<<includes>> -<<includes>>
Use Case Name: Register
Scenario: Register/add a new seller
Triggering Event: A new seller wants to sell books.
Brief Description: Seller decides he/she would like to list a book(s). Seller registers and
receives a confirmation e-mail.
Actors: 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. 2.1 System notifies seller a confirmation e-mail will be sent. 2.2 System e-mails confirmation of registration to seller.
Exception Conditions:
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: Purchase a book
Scenario: Purchase a book
Triggering Event: A buyer decides to purchase a book from EyesHaveIt.com.
Brief Description: 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.
Actors: Buyer
E-mail server Seller
Stakeholders:
Preconditions: Books and book information must exist in the system.
Postconditions: Customer account must exist. Order must be placed.
Flow of Activities: Actor System 1. Buyer searches EyesHaveIt.com for
a book(s).
2. Buyer selects a book(s) to purchase from search results.
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.
4a. If customer wishes to remove an item, he/she selects the item to be removed and then selects the Delete button.
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.
6. If information is incorrect or buyer account does not exist, buyer updates displayed information or enters new information into the registration form. 7. Buyer confirms purchase.
1.1 Searches for all matches related to buyer’s search criteria. 2.1 Creates shopping cart. Adds selected item(s) to the shopping cart.
4.1 Displays list of shopping cart items for verification.
4a.1 Displays list of shopping cart items with deleted items removed.
5. Displays buyer information. 6.1 Updates new buyer
information for existing account. 6.2 Creates account for new buyer and sends confirmation.
7.1 Records order. 7.2 Sends e-mail to seller.
Exception Conditions:
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.
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
Use Case Name: Update order
Scenario: Update order when customer calls
Triggering Event: Customer changes or cancels an order.
Brief Description: 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. 5. Clerk verifies the item to be updated.
6. Clerk adds/removes item from order.
7. Repeat steps 4, 5, and 6 as needed. 8. Customer notifies clerk of all updates needed to be made. 9. Customer makes additional payment or is reimbursed.
4.1 Updates changes.
5.1 Displays item information. 6.1 Adds/removes item. 8.1 Completes order/updates payment.
9.1 Verifies
payment/reimbursement. 9.2 Changes order transaction. 9.3 Finalizes order.
Exception Conditions:
Use Case Name: Create order return
Scenario: Create order return when customer calls in
Triggering Event: Customer wants to return an item.
Brief Description: 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. 5. Clerk gives customer return confirmation.
4.1 Creates order return. 5.1 Completes order return.
Exception Conditions:
Use Case Name: Record backorder
Scenario:
Triggering Event: Order item is out of stock and must be placed on backorder.
Brief Description: 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. 3. Marks order status as backorder.
2.1 Gathers order information. 3.1 Records backorder.
Exception Conditions:
1.1 If the customer requests the order to be sent without the backordered 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.
Use Case Name: Record order fulfillment
Scenario:
Triggering Event: Shipping sends out shipment for order
Brief Description: 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.
Actors: Shipping clerk
Stakeholders:
Preconditions: 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 the box.
3. Records items not available 4. Requests shipping label.
2.1 Updates order item.
3.1 Updates order items out of stock. Sends out-of-stock message to inventory system.
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.
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.
2. 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. Pharmacist or Assistant Manager Create case manifest Update existing perscription Enter new perscription
Print patient case label
Create purchase order for drug Maintain patient
information Add new patient
information Record order
fulfillment
Print org unit case label Change order
information Enter new order
Maintain payer information
Maintain employee information
Add new health organization
Update health organization information Add new drug
Update drug information
Record receipt of drup information
Health Care Organization
Health Care Unit
Empl Patient Order Order Item
Prescript Drug Drug Item Drug Item in Package Payer Enter new order C C Change order UD UD Enter new prescription C Change prescription UD Record fulfillment U U Order case manifest R R Create new patient C Update or delete patient UD Add new drug C C C Update drug information U U U Receive new drug U U Create PO for drug U U Maintain payer CUD Add new health org C Maintain health org UD Print patient case label R Print org unit
label
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.
Use Case Name: Enter new order
Scenario: Enter new order
Triggering Event: Health care organization calls with new patient order. Brief Description:
Actors: HC clerk
Stakeholders: Staff
Manager
Preconditions: 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. Postconditions: Order exists.
Order item exists. Prescription exists. Patient exists.
Staff Member System
Flow of Activities:
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.
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. Exception
Use Case Name: Create case manifest
Scenario: Create case manifest
Triggering Event: Staff is ready to create a case manifest to fulfill orders.
Brief Description: 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.
Actors: Employee
Stakeholders: Employee
Manager
Preconditions: Order must exist. Order items must exist. HC organization must exist. HC unit must exist.
Postconditions: Order is updated.
Staff System
Flow of Activities:
1. Enters HCOrganization identifier. 2. For each HC unit:
2a. Selects an HC unit.
3. Selects orders, or selects all.
1.1 Finds and displays HC organization. Displays all HC units.
2.1 Displays selected unit information. Displays all open orders for this time period. 3.1 Prints case manifests for selected orders.
Exception Conditions:
1.1 HCOrganization is not found. 2.1 No open orders for an HC unit.
Use Case Name: Record order fulfillment
Scenario: Record order fulfillment
Triggering Event: Pharmacist fulfills order. Brief Description:
Actors: Pharmacist or assistant
Stakeholders: Pharmacist
Manager
Preconditions: All objects must exist, including COrganization, HCUnit, Patient, Order, OrderItem, Prescription, Drug, DrugItem, Pharmacist (Employee). Postconditions: OrderItem is updated.
Pharmacist (or assistant) System
Flow of Activities:
1. Enters employee identifier. 2. For each completed order: 2a. Enters order number (from case manifest).
3. For each order item fulfilled: 3a. Selects order item.
3b. Enters fulfillment information. 4. Ends the order.
1.1 Finds pharmacist. Displays information. Displays order fulfillment screen.
2.1 Finds and displays HCOrg, HCUnit, order information, and order items.
3a.1 Displays order item,
prescription, and patient details. 3b.1 Updates order item with fulfillment information. 4.1 Updates order. Exception
5. Develop a state machine diagram for an order. Open addOrderItems () H createOrder () Ready for fulfillment printCaseManifest () Fulfilled enterFulfillmentInfo () readyToFulfill () fulfillmentComplete () H archive()