IPDM Spring 2007T. Hildebrandt, adopted from slides (Version 5.0) by

L. Mathiassen, A. Munk-Madsen, P. A. Nielsen & J. Stage1

Problem-Domain Analysis Classes

Overview, Principles & Techniques, Classes

Part II & Chapter 3

1

IPDM Spring 2007

Overview

Last weeks: ! OOA&D method and development processes

! System definition (FACTOR) and rich pictures

This week:! Lecture 1: Analyzing the problem domain, identifying classes & events

! Lecture 2: Identifying structure and using UML as notation

Next week: Behavior (in problem domain and application domain)

2

IPDM Spring 2007

Activities in OOA&D

ClassStructureBehavior

3

IPDM Spring 2007

Problem domain: That part of a context that is administrated, monitored, or controlled by a system

Analysis of the problem domain

4

IPDM Spring 2007

Overview of ’Problem Domain’

Purpose To identify and model a problem domain

Concepts Problem domain: That part of a context that is administrated, monitored, or controlled by a system.

Model: A description of classes, objects, structures, and behavior in a problem domain.

Principles Model the real world as future users will see it.

Get an overview first, then supply details.

Results A coherent model of a problem domain.

5

IPDM Spring 2007

Results of the activity

Customer

Employee Day Schedule

Time Period

OtherFreeWork

Apprentice Assistant

1

1..!

0..!

1

1

1..!

1

0..!

Appointment

1

1

Customer

name

address

balance

Open

Amount withdrawn

(date, amount)

Account closed

(date)

Account opened

(date)

Amount deposited

(date, amount)

reserved cancel treated employed resigned grad. agreed

Customer " " "

Assistant " " " " "

Apprentice " " " "

Appointment " " "

Plan " "

event table

6

IPDM Spring 2007

Results of ’Classes’

Event table

Shows selected classes and events

reserved cancel treated employed resigned grad. agreed

Customer " " "

Assistant " " " " "

Apprentice " " " "

Appointment " " "

Plan " "

7

IPDM Spring 2007

Classify objects and events in the problem domain

AbstractionClassification

Customer

Bank clerk

Contract

…

Contract signed

Released

…

Contract

8

IPDM Spring 2007

Let us recall..what is an object?

Object:An entity with identity, state, and behavior, e.g. the lecturer Thomas Hildebrandt

Class: A description of a collection of objects sharing structure, behavioral pattern, and attributes, e.g. the collection of lecturers

9

IPDM Spring 2007

What is an event?

Event:An instantaneous incident involving one or more objects, e.g. assignment of a lecture to a lecturer

Atomic

May be common to several objects

Unique name

10

IPDM Spring 2007

users

similar it-systemsliterature

rich pictures

system definition

Activities

Find candidates for classes

Find candidates

for events

Evaluate and select

systematically

Event table

Systems definition

words may be used imprecisely or

differently by different people

(nouns) (verbs)

11

IPDM Spring 2007

Example: Candidates for classes

Plan +

Customer database -

Appointment book -

Cash register -

Appointment +

Treatment performed -

Desired vacation -

Work schedule -

Boss, assistant, receptionist + (Assistant)

Apprentice +

Customer +

Chair -

Salon -

captured by system definition?

relevant for problem domain model?

can objects be identified?

does the class contain

unique info?

does the class contain

several objects?Note: May use CRC cards to record more information

(responsibility and collaboration) and make class “physical”

principles for object designs. We settled on three dimensions which identify the role of an object in a design: class name, responsibilities, and collaborators.

The class name of an object creates a vocabulary for discussing a design. Indeed, many people have remarked that object design has more in common with language design than with procedural program design. We urge learners (and spend considerable time ourselves while designing) to find just the right set of words to describe our objects, a set that is internally consistent and evocative in the context of the larger design environment.

Responsibilities identify problems to be solved. The solutions will exist in many versions and

refinements. A responsibility serves as a handle for discussing potential solutions. The responsibilities of an object are expressed by a handful of short verb phrases, each containing an

active verb. The more that can be expressed by these phrases, the more powerful and concise the design. Again, searching for just the right words is a valuable use of time while designing.

One of the distinguishing features of object design is that no object is an island. All objects stand in relationship to others, on whom they rely for services and control. The last dimension we use in characterizing object designs is the collaborators of an object. We name as collaborators objects which will send or be sent messages in the course of satisfying responsibilities. Collaboration is not necessarily a symmetric relation. For example in Smalltalk- 80[*1, View and Controller operate as near equals (see example below) while Orderedcollection offers a service with little regard or even awareness of its client.

Throughout this paper we deliberately blur the distinction between classes and instances. This informality is not as confusing as it might seem

because the concreteness of our method

substitutes for naming of instances. This also makes our method for teaching independent of whether a class or prototype-based language is

used.

3. CRC Cards

The second author invented CRC cards in response to a need to document collaborative design decisions. The cards started as a HyperCard r31 stack which provided automatic indexing to collaborators, but were moved to

their current form to address problems of portability and system independence.

Like our earlier work in documenting the

collaboration of objects 141, CRC cards explicitly represent multiple objects simultaneously. However, rather than simply tracing the details of a collaboration in the form of message sending,

CRC cards place the designer’s focus on the motivation for collaboration by representing (potentially) many messages as a phrase of English text.

As we currently use them, all the information for an object is written on a 4” x 6” index card. These have the advantages that they are cheap, portable, readily available, and familiar. Figure 1 shows an idealized card. The class name appears underlined in the upper-left hand corner, a bullet-

ClassName

Responsibilities

Collaborators . . .

. . .

Figure 1. A Class-Responsibility-Collaborator (CRC) index card.

2 OOPSLA ‘89 Proceedings October 1-6, 1989 12

IPDM Spring 2007

Example: Candidates for events

reserved +

Cancelled +

Customer arrived -

Treated +

Payment received -

Employed +

Resigned +

Graduated +

Agreed +

Material used -

Item purchased -

Customer picked up -

Arrived workplace -

Leave workplace -

captured by system definition?

relevant for problem domain model?

instantaneous?

atomic?

identifiable?

13

IPDM Spring 2007

Systematic Evaluation

General evaluation criteria! Is the class or event within the

system definition?

! Is the class or event relevant for the problem-domain model?

Criteria for classes! Can you identify objects from the

class?

! Does the class contain unique information?

! Does the class encompass multiple objects?

! Does the class have a suitable and manageable number of events?

Criteria for events! Is the event instantaneous?

! Is the event atomic?

! Can the event be identified when it happens?

14

IPDM Spring 2007

Overview of ’Classes’ activity (Ch. 3)

Purpose To select the elements of a problem-domain model.

Concepts Object: An entity with identity, state, and behavior.

Class: A description of a collection of objects sharing structure, behavioral pattern, and attributes.

Event: An instantaneous incident involving one or more objects.

Principles Classify objects in the problem domain.

Characterize objects through their events.

Have an open mind, but select critically.

Results An event table with classes and related events.

15