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

(1)

Chapter 11 – The Object-Oriented Approach to Design: Use

Case Realization

Solutions to End-of-Chapter Material

Review Questions

1. Which three models are most used to do object-oriented design?

Design class diagrams, interaction diagrams, and package diagrams are the three models that are used to capture design specifications.

2. Why do we say that design is “use-case driven?”

Design is done on a use case-by-use case basis. Each use case is considered and designed independently of the other use cases.

3. Four icons, or shortcuts, can be used to depict different types of classes. List the four icons, describe what each means, and show the symbol for each.

An entity class is the design identifier for a problem domain class. Its icon is a circle on a flat plate.

A boundary class is a class that is specifically designed to live on the system’s automation boundary. Its icon is a circle with a T attached to the side.

A control class is a class that mediates between the boundary classes and the entity classes. Its icon is a circle with an attached arrow.

A data access class is a class that is used to retrieve data from and send data to a database. Its icon is a circle with two extended arms.

(2)

4. List the elements included in a method signature. Give an example of a method signature with all elements listed correctly.

A method signature shows all of the information needed to invoke (or call) the method. It shows the format of the message that must be sent, which consists of the following:

method visibility, method name, type-expression, and method parameter list (incoming arguments). Example: +calculateAmount : float (startDate, endDate)

5. What is the notation used to indicate a stereotype? Show an example of a stereotyped class.

The notation for a stereotype is the name of the stereotype surrounded by guillemets.

6. What is meant by navigation visibility? How is it shown in UML? How is it implemented in programming code?

Navigation visibility is the ability for one object to view and interact with another object. With navigation visibility, a class can access the methods of another class. In UML, navigation visibility is shown with an arrow connecting the two classes. In programming code, navigation visibility is usually implemented with a reference attribute—that is, a variable that references the visible object.

7. What does coupling mean? Why is too much coupling considered bad?

Coupling is a qualitative measure of the amount of “connectedness” between classes. It is usually measured by the number of navigation visibility arrows between classes in a DCD. High coupling means that the classes are too interrelated, which can make maintaining the system very difficult. High coupling can also make it more difficult to test a system

because there are so many connections that must be verified.

8. What are some of the problems that occur from classes with low cohesion?

A class with low cohesion is one that does too many unrelated functions. Low cohesion often causes high coupling. Classes with low cohesion are challenging to maintain because they are difficult to test, and they are not reusable.

9. What is meant by object responsibility? Why is it such an important concept in design?

(3)

Object responsibility refers to the set of functions or responsibilities that a single object has. It is related to the idea of separation of responsibility, which means that different activities should be allocated to different classes (which increases cohesion of classes). Examples of good object responsibility include the concepts of information expert and creator. These examples are types of responsibilities.

10. What is the objective of a use case controller class? What design principles does it typify?

A use case controller class is a completely artificial class that is used to provide a link between the view layer and the domain layer. A controller helps reduce the coupling between the view and domain layers in that the view layer does not need to know about all the classes in the domain layer. It only needs to know about the controller.

11. What is a design pattern? How do system developers use design patterns?

A design pattern is a standard solution template to a design requirement that facilitates the use of good design principles. When the developer must resolve a design problem, he or she searches for known design patterns. Because a design pattern follows good design principles, other team members will understand the solution approach.

12. What is three-layer design? What are the most common layers found in three-layer design?

Three-layer design is a way to divide up the classes in a system into three different layers. One common approach to three-layer design is to have a view layer that includes the user interface classes, a business logic layer that includes the domain classes, and a data layer that includes the data access classes.

13. Why is three-layer design a good principle?

Three-layer design applies the principle of separation of responsibilities so that the system can be easily maintained. For example, the view layer does not have business logic. Therefore, if a company wants to change their image, they can do so without impacting the business logic or the database. Three-layer design also promotes reuse.

14. What is the recommended way to carry out three-layer design? In other words, in what order are the layers designed?

The text recommends that, first, a micro-level iteration should be done with the business layer or domain layer classes. Then, the data access layers should be added. Finally, the view layers should be added. Oftentimes, however, the view layer and the data access layer are designed by two different teams in parallel or in a different order than is described in the text.

15. To develop the first-cut sequence diagram, you should follow three steps. Briefly describe each of those three steps.

(4)

1. Identify the objects that must be included on the sequence or communication diagram.

2. Identify and add the input messages from the SSD for this use case.

3. Expand each input message to all of the subsequent internal messages needed to

carry out the use case.

16. Briefly describe the major differences between a sequence diagram and a communication diagram.

Both include basically the same information. The primary emphasis of a sequence diagram is on the messages and the sequence of the messages. Each message is uniquely positioned on the diagram to indicate its order in the sequence.

The primary emphasis of a communication diagram is on the classes that collaborate together to carry out the use case. The messages are noted, but their sequence is indicated by a numbering scheme that is usually not as intuitive as a physical location on a graphic.

17. Describe the message notation used on a communication diagram.

[true/false condition] sequence-number: return-value : = message-name (parameter-list)

 The true/false condition controls whether the message is sent or not.

 The sequence number indicates the order of the messages.

 The return-value is what is returned to the originating object.

 The message name describes the service requested from the destination object.

(5)

18. What is the purpose of a package diagram? What notation is used? Show an example.

A package diagram divides the classes into subsystems or groupings. Packages can be defined in several ways to denote grouping of classes. The notation is a tabbed box.

19. How is dependency indicated on a package diagram? What does it mean?

Dependency is indicated by a dashed line arrow. It means that the classes and class definitions are dependent on the class properties in another package. If a class definition changes in the independent package, the classes in the dependent package will likely also change.

20. List the primary responsibilities of classes in the view layer. Now do the same for the domain layer and the data access layer.

The view layer is the user interface layer. Its responsibilities include accepting data from the user and returning data to the user. It also provides an organization to the application that is useful to the user.

The domain layer contains the business logic and the business rules. These classes carry out the functions of the system.

The data access layer classes contain all of the SQL statements (assuming a relational database) and the processing of the result sets.

21. What is the difference between an Internet-based system and a network-based system?

An Internet-based system has a very complex view layer that usually consists of HTML pages presented in a Web browser. The view layer also includes that part of the server that formats and sends the HTML pages to the client. Dynamic creation of these pages can make the user interface complex.

A network-based system is like a desktop system, only the screens are available on the entire network. The input forms (screens) are simply Windows (or Unix) classes such as AWT classes. They are presented directly to the user without requiring a browser.

(6)

Thinking Critically

Note: Exercises 1, 2, 3, and 4 are based on the solutions you developed in Chapter 7 for “Thinking Critically” exercises 1 and 2 based on the university library system.

Alternatively, your teacher may provide you with a use case diagram and a class diagram. 1. Figure 11-31 is a system sequence diagram for the use case Check out books in the

university library system. Do the following:

a. Develop a first-cut sequence diagram, which only includes the actor and problem domain classes.

(7)

LibraryEmployee _{:CheckoutHandler}

verifyPatronForLoan (ID)

name, addr, tele, type, status

*checkOutBook (bookID)

title, author, copy#, dueDate

closeLoan ( ) aP:Patron aP := getParon (ID) aL:Loan createLoan (aP) checkOutBook (bookID) aLI:LoanItem createLoanItem (aBT,bookID) :BookCopy

title, author, copy#, dueDate title, author, copy#, dueDate

closeLoan ( )

aBT:BookTitle

ReservationCatalog aR:findReservatio (aP,title)

[exists] updateRes ( )

Check Out Books — Domain classes only

PatronLIst

LoanItemList

Design depends on contents of bookID, assume it includes cat#, copy#

aBT:=getBook (bookID)

getInfo ( )

title, author

updateStatus (copy#, checkedout)

aR:Reservation BookTItleLilst

(8)

b. Add the view layer classes and the data access classes to your diagram from part a.

LibraryEmployee _{:CheckoutHandler}

verifyPatronForLoan (ID)

name, addr, tele, type, status

*checkOutBook (bookID) closeLoan ( ) PatronDA aL:Loan createLoan (aP) checkOutBook (bookID) aLI:LoanItem createLoanItem (aL, bookID)

BookCopyDA

title, author, copy#, dueDate title, author, copy#, dueDate

closeLoan ( )

BookTitleDA

Check Out Books

aBT:=getBk (bookID)

updateStatus (copy#, checkedout) createBC (info) aP := getPatron (ID) aP:Patron createPatron (info) aBT:BookTitle createBT (info)

aBC := getBC (bookID)

aBC:BookCopy saveBC (aBC) LaonItemDA save (aLI) LoanDA save (aL)

Two ways to use the DA classes

1. Create an empty object, which goes to DA to fill in the attributes.

2. Go directly to DA, which creates the object.

<<View>> CheckOutForm

(9)

c. Develop a design class diagram based on the domain class diagram and the results of parts a and b.

+createBookTitle ( … ) -title: string -author: string -publisher:string -catalogNumber:string BookTitle +verifyPatronForLoan (ID) +checkoutBook (bookID) +closeLoan ( ) CheckoutHandler -dateReserved -priority -dateFulfilled Reservation -dueDate -returnedDate LoanItem +updateStatus (“onLoan”) +createBookCopy (… ) -copyNumber:int -edition:string -pubYear:string -ISBN:string -status:string -dueBack:date BookCopy +createLoan (info) +checkoutBook (bookID) +closeLoan () loanID dateOfLoan status Loan +createPatron (info) name address telephone LibraryPatron

(10)

d. Develop a package diagram showing a three-layer solution with view layer, domain layer, and data access layer packages.

View Domain Data Access CheckoutForm CheckoutHandler Patron Loan BookTitle LoanItem BookCopy PatronDA LoanDA LoanItemDA BookTitleDA BookCopyDA NewBookController AddBookForm

(11)

2. Figure 11-32 is an activity diagram for the use case Return books for the university library system. Do the following:

LibraryClerk

CheckoutHandler

*returnBook (bookID)

succesMsg, title, status beginBookReturn ( ) endBookReturn ( ) aBT:BookTitle BookCopy Loan returnBook (copy# ) title, status

Library — Return Books use case First cut — Domain Model only

Catalog aBT:=getBookTitle (bookID) updateStatus ( ) LoanItem updateLoan (bookID) status := updateLoanItem( ) status status

I assumed visibility between BookCopy and Loan I use bookID to get a reference to the actual

book (aBT), so I know which object to send the returnBook message to.

I left off the multiobjects because it was getting so cluttered. Multi-objects are needed at least for

(12)

LibraryClerk

CheckoutHandler

succesMsg, title, status beginBookReturn ( )

endBookReturn ( )

aBT:BookTitle

BookCopy

title, status

Library — Return Books use case

updateStatus ( )

aLI:LoanItem

status := updateLoanItem( )

status *returnBook (bookID)

aBT := getBT (bookID) BookTitleDA

aBC := getBC (bookID) BookCopyDA

createBC(info)

createLI (info) LoanItemDA

aLI := getLI (bookID)

createL (info) getLoan (LoanID) updateStatus ( ) save (aL) save (aLI) save (aBC) create ( info) returnBook (copy# ) <<view>> ReturnBookForm Loan LoanDA

(13)

+createBT (info) +returnBook (copy#) -title: string -author: string -publisher:string -catalogNumber:string BookTitle +beginBookReturn () +returnBook (bookID) +endBookReturn () CheckoutHandler -dateReserved -priority -dateFulfilled Reservation +createLoanItem (info) +updateStatus (“returned”) -dueDate -returnedDate LoanItem +createBC (info) +updateStatus (“returned”) -copyNumber:int -edition:string -pubYear:string -ISBN:string -status:string -dueBack:date BookCopy +createLoan (info) +updateStatus ( ) loanID dateOfLoan status Loan name address telephone LibraryPatron

(14)

(15)

3. Figure 11-33 is a fully developed use case description for the use case Receive new book for the university library system. Do the following:

Actor

BookTitle

result1 := checkForExisting (title)

Receive new books

[new title & result2 is null] createBookTitle (bookInfo)

[result 1 not null] checkBookCopy (catalog#)

*createBookCopy (bookCopyInfo) [result1 null] result2 := checkForExisting (catalog#)

aBC:BookCopy

*getBookCopyInfo ( )

bcList

aBC := createBookCopy (bookCopyInfo)

BCList

NewBookController

(16)

Actor

aBT:BookTitle result1 := checkForExisting (title)

Receive new books

[not newtitle] checkBookCopy (catalog#)

aBC:BookCopy

bcList := checkBookCopy (catalog#) createList ( )

bcListwithCopyInfo

aBC1:BookCopy aBC1 := createBookCopy (bookCopyInfo)

addBC (aBC1) BCList NewBookController Catalog object ListBookTitles CopyInfo := getCopyInfo ( ) object :BookCopies addToList (aBT)

New Class. Identified during deisgn. This is one solution. Similar to a multiobject.

(17)

Actor

aBT:BookTitle result1 := checkForExisting (title)

Receive new books

[not newtitle] checkBookCopy (catalog#)

aBC:BookCopy

bcList := checkBookCopy (catalog#)

bcListwithCopyInfo

aBC1:BookCopy aBC1 := createBookCopy (bookCopyInfo)

save (aBC1) BCList NewBookController BookTitieDA * CopyInfo := getCopyInfo ( ) <<Veiw>> AddBookForm save (aBT) BookCopyDA createBC (info)

(18)

+createBT (info) +checkBookCopy (catalog#) +createBookCopy (info) -title: string -author: string -publisher:string -catalogNumber:string BookTitle +createBookTitle ( … ) +checkBookCopy ( …) +createBookCopy (…) NewBookController -dateReserved -priority -dateFulfilled Reservation -dueDate -returnedDate LoanItem +createBookCopy (info) +getCopyInfo ( ) -copyNumber:int -edition:string -pubYear:string -ISBN:string -status:string -dueBack:date BookCopy loanID dateOfLoan status Loan name address telephone LibraryPatron

(19)

(20)

4. Integrate your design class diagram solutions that you developed for exercises 1, 2, and 3 into a single design class diagram.

+createBookTitle ( … ) +checkBookCopy ( …) +createBookCopy (…) +returnBook (copy# ) +getInfo (…) +updateStatus (…) -title: string -author: string -publisher:string -catalogNumber:string BookTitle +createBookTitle ( … ) +checkBookCopy ( …) +createBookCopy (…) NewBookController +createReservation(info) +updateReservation (…) -dateReserved -priority -dateFulfilled Reservation +createLoanItem (info) +updateLoanItem (returned) -dueDate -returnedDate LoanItem +getCopyInfo (…) +createBookCopy (… ) +updateStatus(...) -copyNumber:int -edition:string -pubYear:string -ISBN:string -status:string -dueBack:date BookCopy +createLoan(info) +updateLoan ( bookID) +checkOutBook (… ) +closeLoan loanID dateOfLoan status Loan +createPatron (info) +getPatronInfo (…) name address telephone LibraryPatron +verifyPatron (…) +checkOutBook (…) +closeLoan (…) +beginBookReturn (…) +returnBook (… ) +endBookReturn (…) CheckOutBookHandler

(21)

Note: Exercises 5, 6, 7, and 8 are based on the solutions you developed for “Thinking Critically” exercises 3 and 4 in Chapter 7 on the dental clinic system. Alternatively, your teacher may provide you with a use case diagram and class diagram.

5. Figure 11-34 is a system sequence diagram for the use case Record dental procedure in the dental clinic system. Do the following:

DentalAide

DentProcControl

findPatient (name, tele#)

patientID, name, visitRecord

*enterDescription (dentistID, hygienistID, description)

updateVerificationMessage

closePatientFile

aP:Patient aP := findPatient (name, tele#)

enterDescription (dentistID, hygienisID, description)

aV:Visit

aP:Procedure [status OK] createProcedure ( dentistID, higienistID description)

*status := verifyMS (staffID)

successMsg object PatientList object VisitList object MedicalStaffList aV := findCurrentVisit (aP)

(22)

DentalAide

DentProcControl

findPatient (name, tele#)

patientID, name, telephone

*enterDescription (dentistID, hygienistID, description)

updateVerificationMessage

closePatientFile ()

PatientDA

aP := findPatient (name, tele#)

enterDescription (dentistID, hygienistID, description) VisitDA

aV:=findCurrentVisit (patientID)

aP:Procedure createProcedure (dentistID, hygienistID, description)

aP:Patient aV:Visit ProcedureDA <<View>> ProcudureUI createPatient () createVisit () writePatient (aP) writeVisit (aV) medicalStaffDA

status := verifyMS (staffID)

successMsg _{writeProc (aP)}

There are two ways to use the DA objects and business objects together.

1. As shown here, the first message goes to the DA object, which reads the db and creates a new object.

2. As shown in the next use case (Enter new patient), the first message goes to the object, which creates an empty object. The object then sends a message to the DA object to fill in all lthe attributes.

(23)

1 1..* 1 1..* copayAmtDue copayPaid HHInvoice insuredAmtDue insuredPaid InsuranceInvoice invoiceID dateSent total amtPreviouslyPaid datePaid amtRefused Invoice HHID headName address telephone {key} visitCopay Household +createPatient (info) patientID {key} name birthdate gender firstVisitDate lastVisitDate Patient +enterDesicription (dentistID, hygienistID, desc) visitID {key} date copayAmt copayPaid copayCode OfficeVisit +verifyMS (staffID) staffID {key} name address telephone title-position MedicalStaff +createProcedure (staffID, desc)

procedureDescription totalAmt copayAmt insurancePaid insuranceDenied descriptionOfTeet Procedue (StaffAndVisit) companyName address contactName contactTelephone InsuranceCo

(24)

View Layer

Business Layer

Data Access Layer

PrintInvoiceScreen EnterPatWindow EnterProcedureForm

Household Patient Invoice HHInvoice InsuranceInvoice InsuranceCo OfficeVisit Medical Staff Procedure ProcedureType HouseholdDA PatientDA InvoiceDA HHInvoiceDA InsuranceInvoiceDA InsuranceCoDA OfficeVisitDA Medical StaffDA ProcedureDA ProcedureTypeDA

(25)

6. Figure 11-35 is an activity diagram for the use case Enter new patient information for the dental clinic system. Do the following:

Actor

NewPatControl

findHH (tele#)

HHInfo

[HHInfo Null] create HH (HHInfo)

HHInfo

createPatientInfo (patientInfo)

patientInfo endNewPatient ( )

aH:Household aI:InsuranceCo aP:Patient

findHH (tele#) createHH (HHInfo) findInsuranceCo (companyName) aH, aI createPatient (patientnfo) createPatient (patientInfo)

(26)

b. Add the view layer classes and the data access classes to your diagram from part a. Actor NewPatControl findHH (tele#) HHInfo

[HHInfo Null] create HH (HHInfo)

HHInfo createPatientInfo (patientInfo) patientInfo endNewPatient ( ) aH:Household aP:Patient aI:InsuranceCo findHH (tele#) createHH (HHInfo) findInsuranceCo (companyName) aH, aI createPatient (patientnfo) createPatient (patientInfo) <<view>> NewPatWindow HouseholdDA InsuranceCoDA PatentDA readHH (aH) readInsurance (aI endNewPatient ( ) endNewPatient ( ) writePat (aP) writeHH (aH)

There are two ways to use the DA objects and business objects together.

1. As shown in here, the first message goes to the object, which creates an empty object. The object then sends a message to the DA object to fill in all lthe attributes.

2. As shown in the previous use case (Record dental procedure), the first message goes to the DA object, which reads the db and creates a new object.

(27)

1 1..* 1 1..* copayAmtDue copayPaid HHInvoice insuredAmtDue insuredPaid InsuranceInvoice invoiceID dateSent total amtPreviouslyPaid datePaid amtRefused Invoice +findHH (tele#) +createHH (HHInfo) +createPatient (patInfo) endNewPatient ( ) HHID headName address telephone {key} visitCopay Household +createPatient (patInfo) +endNewPatient ( ) patientID {key} name birthdate gender firstVisitDate lastVisitDate Patient visitID {key} date copayAmt copayPaid copayCode OfficeVisit staffID {key} name address telephone title-position MedicalStaff procedureDescription totalAmt copayAmt insurancePaid insuranceDenied descriptionOfTeet Procedue (StaffAndVisit) +findInsuranceCo (companyName) companyName address contactName contactTelephone InsuranceCo

(28)

View Layer

Business Layer

Data Access Layer

(29)

7. Figure 11-36 is a fully developed use case description for the use case Print invoices for the dental clinic system. Do the following:

(30)

Actor

Print Patient Invoices

PaymentController

*showPataientProcedure (name, tel#, month)

patientInfo, visitInfo, procedureInfo

*showPayments (tel#, dates)

HHbalance, payments

printInvoice (month)

aHH:Household aPat:Patient aV:Visit aPro:Procedure

*showProcedure (name, tel#, month)

*showProcbyVisit (month)

*findProcs (visitID)

patID, visitList, procList

Payment

showPayments (dates)

paymentList

*printInvoice(month)

findProcs (visitID)

patID, visitList, procList, payList patID, visitList, procList, payList

printInvoice (parID, visitList, procList, payList)

showProcedure (name, tel#, month)

*showProcbyVisit (month)

*findPayments (tel#, month)

For a given household there may be multiple patients with multiple visits with multiple procedures.

(31)

Actor

Print Patient Invoices

PaymentController

*showPataientProcedure (name, tel#, month)

patientInfo, visitInfo, procedureInfo *showPayments (tel#, month)

HHbalance, paymentList printInvoice (month)

aHH:Household aPat:Patient aV:Visit aPro:Procedure

showPatProc (month)

*showProcbyVisit ( )

*findProcs (visitID) procedureList

PaymentDA

showPayments (tel#, month)

*printInvoice(month)

findProcs (visitID) prodList

visitList, procList

printInvoice (patID, visitList, procList, payList)

showProcedure (name, tel#, month)

*showProcbyVisit (month) <<View>>

PrintInvoiceScreen

HouseholdDA PatientDA VisitDA

aHH:=findHH (name, tel#) createHH (info) showProcForHH (month)

*getPatient(aHH) createPat (info)

*getVisit (aPat, month) creatVis (info)

ProcedureDA

creaetProc (into)

visitList, procedureList

Payment

createPay (info)

(32)

1 1..* 1 1..* copayAmtDue copayPaid HHInvoice insuredAmtDue insuredPaid InsuranceInvoice invoiceID dateSent total amtPreviouslyPaid datePaid amtRefused Invoice

+showPataientProcedure (name, tel#, month) +showPayments (tel#, dates)

+printInvoice(month) HHID headName address telephone {key} visitCopay Household

+showProcedure (name, tel#, month) +getPatientInfo (mnth) patientID {key} name birthdate gender firstVisitDate lastVisitDate Patient +showProcbyVisit (month) visitID {key} date copayAmt copayPaid copayCode

OfficeVisit staffID {key}_name address telephone title-position MedicalStaff +findProcs (visitID) procedureDescription totalAmt copayAmt insurancePaid insuranceDenied descriptionOfTeet Procedue (StaffAndVisit) companyName address contactName contactTelephone InsuranceCo +showPayments (dates) paymentID date amount Payment

(33)

View Layer

Business Layer

Data Access Layer

(34)

8. Integrate your design class diagram solutions that you developed for exercises 5, 6, and 7 into a single design class diagram.

1 1..* 1 1..* copayAmtDue copayPaid HHInvoice insuredAmtDue insuredPaid InsuranceInvoice invoiceID dateSent total amtPreviouslyPaid datePaid amtRefused Invoice

+showPataientProcedure (name, tel#, month) +showPayments (tel#, dates)

+printInvoice(month) +findHH (tele#) +createHH (HHInfo) +createPatient (patInfo) +endNewPatient ( ) HHID headName address telephone {key} visitCopay Household

+showProcedure (name, tel#, month) +getPatientInfo (mnth) +createPatient (patInfo) +endNewPatient ( ) patientID {key} name birthdate gender firstVisitDate lastVisitDate Patient +showProcbyVisit (month)

+enterDesicription (dentistID, hygienistID, desc) visitID {key} date copayAmt copayPaid copayCode OfficeVisit +verifyMS (staffID) staffID {key} name address telephone title-position MedicalStaff +findProcs (visitID)

+createProcedure (staffID, desc) procedureDescription totalAmt copayAmt insurancePaid insuranceDenied descriptionOfTeet Procedue (StaffAndVisit) +findInsuranceCo (companyName) companyName address contactName contactTelephone InsuranceCo +showPayments (dates) paymentID date amount Payment

(35)

9. In Chapter 7 “Thinking Critically” exercise 6 you developed an activity diagram for each of two scenarios for purchases at Quality Building Supply. In exercise 9, you developed a system sequence diagram. Based on either your activity diagram or your system sequence diagram and the following list of classes from the domain class diagram develop a detailed communication diagram. Include only problem domain classes.

(36)

10. In Chapter 7 “Thinking Critically” exercises 7, 8, and 10, you developed a system sequence diagram for the Add a new vehicle to an existing policy. You were also provided a list of classes. Based on the SSD you developed, develop a detailed communication diagram. Include only problem domain classes.

Clerk :PolicyHandler :Policy :InsuredPerson :InsuredVehicle :Coverage :StandardCoverage :StandardVehicle

1. policy details: validatePolicy (policy#)

2. expanded vehicle info: addVehicle (VIN, vehicle info)

3. addCoverage (type,amount,deductible) 4. [new driver] invoke Add New Driver 5. assignDrivers (driver, percent) 6. premium: completeChange ( )

3.1 addCoverage (type,amount,deductible) 5.1 assignDrivers (driver, percent)

1.1 policy details: validatePolicy (policy#)

2.1 expanded vehicle info: addVehicle (VIN, vehicle info)

2.2 expanded vehicle info: addVehicle (VIN, vehicle info) 6.1 premium: completeChange ( )

(37)

Experiential Exercises

1. Find a local company that is using UML and object-oriented development. Set up an interview with a member of the IS staff. Find out how the company uses UML. Ask about using domain models to do analysis. Find out if the staff members use sequence diagrams and how they actually carry out the design of new systems. Also, ask about the SDLC that they use. Do they use a predictive approach or an adaptive approach?

Answers will vary. The interview will be more successful if the company has used UML and object-oriented development for a few years.

2. Find a system that was developed using Java. If possible, find one that has both an Internet user interface and a network-based user interface. Is it multilayer—three layer or two layer? Can you identify the view layer classes, the domain layer classes, and the data access layer classes?

Answers will vary. Most solutions should include the three-layer architecture.

3. Find a system that was developed using Visual Studio .NET (or Visual Basic). If possible, find one that has both an Internet user interface and a network-based user interface. Is it multilayer? Where is the business logic? Can you identify the view layer classes, the domain layer classes, and the data access layer classes?

Answers will vary. Most solutions should include the three-layer architecture.

4. Pick an object-oriented programming language with which you are familiar. Find a programming integrated development environment (IDE) tool that supports that language. Test out its reverse-engineering capabilities to generate UML class diagrams from existing code. Evaluate how well it does and how easy the models are to use. Does it have any capability to input UML diagrams and generate skeletal class definitions? Write a report on how it works and what UML models it can generate.

(38)

Case Studies

Case Study: The Real Estate Multiple Listing Service System

In Chapter 7, you developed a use case diagram, a class diagram, and a system sequence diagram for the real estate company’s use cases. Based on those solutions or others provided by your teacher, develop a first-cut sequence diagram for the problem domain classes. Next, add view layer and data access layer objects to the sequence diagram.

Convert the domain class diagram to a design class diagram by typing in the attributes and adding method signatures.

(39)

(40)

(41)

(42)

(43)

Case Study: The State Patrol Ticket Processing System

In Chapter 7, you developed a use case diagram, a class diagram, and a system sequence diagram for the use cases Recording a traffic ticket and Scheduling a court date. Based on those solutions or others provided by your teacher, develop a first-cut sequence diagram for the problem domain classes. Next, add view layer and data access layer objects to the sequence diagram. Convert the domain class diagram to a design class diagram by typing in the attributes and adding method signatures.

(44)

(45)

(46)

(47)

Case Study: The DownTown Videos Rental System

In Chapter 7, you developed a use case diagram, a class diagram, and a system sequence diagram for the use cases Rent movies and Return movies. Based on those solutions or others provided by your teacher, develop a first-cut communication diagram for the problem domain classes. Next, add view layer and data access layer objects to the

communication diagram. Convert the domain class diagram to a design class diagram by typing in the attributes and adding method signatures.

(48)

(49)

(50)

(51)

(52)

(53)

(54)

Case Study: TheEyesHaveIt.com Book Exchange

In Chapter 7, you developed a use case diagram, a class diagram, and a system sequence diagram for the use cases Add a seller and Record a book order. Based on those solutions or others provided by your teacher, develop a first-cut communication diagram for the

problem domain classes. Next, add view layer and data access layer objects to the

communication diagram. Convert the domain class diagram to a design class diagram by typing in the attributes and adding method signatures.

(55)

(56)

(57)

(58)

(59)

(60)

Case Study: Rethinking Rocky Mountain Outfitters

This chapter presented the solutions for two use cases for RMO—Look up item availability and Maintain product information. Design three-layer solutions for two more use cases,

Create order return and Record order fulfillment. Update the design class diagram for the

problem domain classes with method signatures from these use case designs. Often, the sequence diagram to produce a report can be quite interesting. Do a three-layer design for the use case Produce order fulfillment report. Because you do not have detailed user requirements for this use case, you will need to first lay out a sample fulfillment report.

(61)

(62)

(63)

(64)

(65)

Case Study: Focusing on Reliable Pharmaceutical Service

In Chapter 7, you developed a use case diagram, a domain model class diagram, and detailed documentation for three use cases. In your detailed documentation, you generated a fully developed specification and a system sequence diagram. Based on that information and the guidelines in this chapter, design a three-layer architecture for each of those three use cases. Update the design class diagram with attribute type information and method signatures derived from the sequence diagrams.

(66)

(67)

(68)

(69)

(70)