Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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