slide 8b.1 copyright © 2004 by the mcgraw-hill companies, inc. all rights reserved. an introduction...

B.1

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

An Introduction toObject-Oriented

Systems Analysis and Design with UML and

the Unified Process

McGraw-Hill, 2004

Stephen R. Schach

[email protected]

B.2


CHAPTER 8 — Unit B

THE OBJECT-ORIENTED DESIGN WORKFLOW

B.3


Continued from Unit 8A

B.4


Responsibility-Driven Design: Osbert Oglesby

Consider operation getAuctionPrice

Irrespective of the source of the message requesting an auction price– Operation getAuctionPrice must be allocated to Auctioned

Painting Class

B.5


Responsibility-Driven Design: Osbert Oglesby

Allocation of getAuctionPrice

B.6


Inheritance: Osbert Oglesby Case Study

Consider operations – setTitle and– getTitle

B.7


Inheritance: Osbert Oglesby Case Study (contd)

Example: Osbert prints a list of all his paintings– Each object in the information system in turn is examined– A message is sent to operation getTitle to obtain the title of

the painting represented by that object

To which class must operations – setTitle and – getTitle

be allocated?

B.8



First consider operation setTitle

In the traditional paradigm, there would have to be three different versions of setTitle, one for each type of painting– set_masterpiece_title– set_masterwork_title– set_other_painting_title

That is because the traditional paradigm does not support inheritance

B.9



In the object-oriented paradigm, consider the Painting Class inheritance hierarchy

Painting Class has attribute title– This attribute is inherited by instances of its 5 subclasses

» Gallery Painting Class» Auctioned Painting Class» Masterpiece Class» Masterwork Class» Other Painting Class

B.10



Thus, operation setTitle must be allocated to Painting Class so that it can be inherited (and used) by instances of all five subclasses

This applies to all operations, including getTitle

B.11



Allocation of operations setTitle and getTitle

B.12


CRC Cards

Since 1990, class-responsibility-collaboration (CRC) cards have been utilized for object-oriented analysis and design

For each class, fill in a card showing– The name of the class;– The functionality of that class (its responsibility); and – The other classes it invokes to achieve that functionality

(its collaboration)

B.13


CRC Cards (contd)

CRC cards were originally introduced for performing requirements elicitation and analysis

They are excellent for this purpose– Provided the team members are familiar with the domain

For professionals who have no domain expertise – CRC cards are an extremely effective way of testing

object-oriented analysis and design artifacts

B.14


CRC Cards (contd)

Example:

B.15


CRC Cards (contd)

The data for the CRC card are obtained from the realizations of all the use cases

B.16


CRC Cards (contd)

Consider the MSG collaboration diagram

B.17


CRC Cards (contd)

The message – 7: Request estimated grants and payments for week

is passed from : Estimate Funds for Week Class to : Mortgage Class, followed by the message– 8: Return estimated grants and payments for week

in the reverse direction

B.18


CRC Cards (contd)

Mortgage Class therefore has a responsibility to– Compute estimated grants and payments for week

In order to do this, it must collaborate with Estimate Funds for Week Class– This is shown in the first entry in the CRC card

B.19


CRC Cards (contd)


B.20


CRC Cards (contd)

The message – 3: Update tax and date

is passed from : Manage an Asset Class to : Mortgage Class

Then, the message – 4: Send successful completion message

is passed back

B.21


CRC Cards (contd)

Third iteration of the MSG initial class diagram

B.22


CRC Cards (contd)

Mortgage Class has eight attributes (including annual real-estate tax), that might need to be changed by : Manage an Asset Class– All the attributes are initialized by : Manage an Asset

Class

A complete set of scenarios includes all 16 set and get operations

B.23


CRC Cards (contd)

Each of the 16 scenarios in turn requires an interaction diagram of its realization– In addition, managing a mortgage includes adding a new

mortgage and deleting an existing mortgage

For brevity, combine all these responsibilities into responsibility – Initialize, update, and delete mortgages

with collaborator– Manage an Asset Class

This is the second entry in the CRC card

B.24


CRC Cards (contd)


B.25


CRC Cards (contd)

The message – 3: Update income and date

is passed from : Manage an Asset Class to : Mortgage Class

The message – 4: Send successful completion message

is then passed back

B.26


CRC Cards (contd)

Attribute combinedWeeklyIncome is one of the eight attributes of Mortgage Class that might need to be changed by : Manage an Asset Class– This responsibility is already included in responsibility

Initialize, update, and delete mortgages

B.27


CRC Cards (contd)


B.28


CRC Cards (contd)

The message – 2: Transfer request [for list of mortgages]

is passed from : User Interface Class to : Mortgage Class

Thus, Mortgage Class has the responsibility– Generate list of mortgages

with collaborator User Interface Class

This is the third entry in the CRC card

B.29


CRC Cards (contd)

Also, the message – 3: Print list of mortgages

is passed from : Mortgage Class to : Mortgages Report Class

Mortgage Class thus also has the responsibility– Print list of mortgages

with collaborator Mortgages Report Class

This is the fourth entry in the CRC card

B.30


CRC Cards (contd)

As a check, consider the fourth iteration of the MSG class diagram

B.31


CRC Cards (contd)

In the class diagram there five classes with which Mortgage Class has a relationship– User Interface Class– Estimate Funds for Week Class– Mortgages Report Class– Asset Class– Manage an Asset Class

From the realizations it is clear that Mortgage Class no responsibility with Asset Class

B.32


CRC Cards (contd)

All four of the remaining classes are listed in the COLLABORATION column of the CRC card

This does not necessarily mean that every responsibility of every collaboration class has been included – However, it is likely that all the collaboration classes have

been included

B.33


CRC Cards (contd)

CRC cards have been extended

A CRC card nowadays often contains the attributes and operations of a class, not its “responsibility”– The CRC card then contains the information of the

complete class diagram

B.34


CRC Cards (contd)

The technology has changed– Instead of using cards, some organizations move Post-it

notes around on a white board and draw lines between them to denote collaboration

Nowadays the whole process can be automated– Some CASE tools include modules for creating and

updating CRC “cards” on the screen

B.35


CRC Cards (contd)

When used by a team, CRC cards can highlight missing or incorrect attributes or operations

Having the members of the team act out the responsibilities of each CRC card is an effective means of verifying that the classes are correct

Example: – One team member acting out the responsibilities of a class

may cause another member to realize that a needed responsibility has been omitted

slide 8b.1 copyright © 2004 by the mcgraw-hill companies, inc. all rights reserved. an introduction...

Documents

inheritance slide

painting class slide

gettitle slide

mcgrawhill companies

unit b

type of painting

operation settitle

operation gettitle