Domain Modeling (with Objects)

Motivation• Programming classes teach– What an object is– How to create objects

• What is missing– Finding/determining which objects should you create?

“Indeed given a set of requirements for an application and a development system like Smalltalk, ‘finding the objects’ is easily the most difficult task an experienced OO developer has to face.

—Simon Lewis, The Art and Science of Smalltalk

How Hard Could this Be?

• You work for Otis• Build a general purpose elevator system to

control the movement of elevators in a building

Discussion – Elevator System

Without a Domain Model

• You start writing code without figuring out what needs to be expressed

• You would not understand the solution space clearly enough

• Would not understand the problem space clearly enough

The Process• Software Development is an iterative activity– Start with Object-Oriented Analysis and Design– Move on to OO Programming– Return to OOA/OOD when necessary

• When creating new functionality• To solve problems with the code

• OO Analysis is just another perspective– Good designers (in any field) shift perspective frequently

to create a better design– The boundary between OOA and OOD is fuzzy.

Analysis vs. Design• Analysis is mostly concerned with

the DOMAIN MODEL. • What are the objects in the

domain and how do they collaborate.

• I want the iPod to play music (MusicPlayer class)

• In design, we need to integrate an APPLICATION MODEL

• What objects do I need to add to get this thing to run on a computer and to be realized in some programming language?

• The iPod should have a play button, rewind/ffwd done with the wheel (MusicPlayer needs to interact with PlayButton and Wheel classes)

Understanding Objects

What are Objects?

• What we came up with just now– Building– Elevator– Floor– Control Panel– …

• Things!• Entities in the system• Abstraction of a concept in the solution space

Objects have State

• Elevator– Direction of movement– Current Floor– Moving or at Rest?– Floors to visit

Objects have Behavior

Objects Collaborate

Key Ideas

Abstraction

Encapsulation

Composition

Inheritance

Modeling Technique – CRC Cards

Class-Responsibility-Collaboration• Help understand the Domain as

Objects– Language Independent– Force Developers to “think” in objects

• Steps1. Brainstorm Candidate Classes2. Create Initial CRC Cards3. Come up with scenarios of use in the

domain4. Use scenarios to refine CRC Cards

Sample CRC Card

Class Name (Base-class):

Purpose:

Responsibilities Collaborators

Sample CRC Card

Class: DocumentPurpose: Acts as a container for graphics and textResponsibilities Collaborators

Knows contentKnows Storage location

Insert and Remove Text, Graphics and other Elements

Library Automation

Step 1 - Candidate Classes• Write down all the objects that relate– Domain Analysis– Focus on the nouns (objects are nouns)– Good objects will have attributes and services

• Now, filter and refine the candidates– Deal with the interface later (if it helps create a GUI class

that is user interface)– Are some candidates attributes of others?– Are some subclasses of others?– Are some instances of others?

Candidate Class• Has clear unambiguous name (from the domain)• Has responsibilities (what NOT how)• Remembers (knowledge)• Is needed (collaborates)• Actively participates

Tips

• Don’t forget the user• All ideas are potentially good• Analyze – make connections• Think fast – ponder later

Exercise – Come up with Candidate Classes

Filter Candidate Classes

• Core Classes– Pretty sure these are in domain model

• Undecided Classes– Probably not classes – may be attributes

• Eliminated Classes– Outside scope of system– Application model classes like UI components tied

to implementation

Exercise – Filter Classes

Step 1 - Result

• Candidate Classes

• Filtered Classes

Step 2 – Responsibilities and Collaborators

Class Name (Base-class):

Purpose:

Responsibilities Collaborators

• Things that the class has knowledge about• Things that the class can do with the knowledge

it has• Tips– Verb extractions in the problem or use case– What does the class know?– What is the class expected to do? – What information must be stored about the class to

make it unique?

Responsibilities

• To fulfill a responsibility, a class may need to collaborate with another class

• This happens when the class needs– information that it does not have, or – to modify information that it does not have

• Tips– What does the class not know and need to know?– Who can provide that?

Collaborators

Sample CRC CardClass: DocumentPurpose: Acts as a container for graphics and textResponsibilities Collaborators

Knows contentKnows Storage location

Insert and Remove Text, Graphics and other Elements

Exercise – Come up with CRC Cards

Step 3 - Scenarios• Invent Scenarios– What should these objects do?– What if…?

• Play the Cards– Assign Roles– Go Through Scenario– Write down new responsibility– Add collaborator objects to help with that responsibility

Scenario Guidelines

• Concrete:– Bob tries to Login to the system with an incorrect

password.– Sally creates a new Sorceress character and

chooses auto-configuration.• Focus on “must do” items first• Start easy and move to complex

Exercise – Come up with Scenarios

What have we got

Major Questions

• Shouldn't there be collaborations in the opposite direction? – Collaborations in CRC cards are one-way

relationships from the client to the server• Who should do the checking out of the Book? – Librarian or Book itself?

• Who should tell Borrower to update its knowledge about outstanding Book?– Librarian or Book?

• Do we need a collaboration between Book and Borrower for the know set of books responsibility? – Collaborations are not usually needed for

responsibilities that simply hold information.– Collaboration is needed only for situations where an

object actually sends a message to a Collaborator.– Borrower does not need Book's help to put a Book

in a set

More Questions

When to Stop

• Stable Model• No new class discovery• No C / R being added

Modeling Workshop