Objectives:1. Classes and Objects

1
Object-Oriented Analysis Finding Class--Obects

• Objectives 1. Classes and Objects
• 2. Attributes
• 3. Services
• 4. Subjects

2
Finding Class--Objects

• Object
• An abstraction of an entity in the problem
  domain.
• Class
• A description of one or more Objects with a
  uniform set of Attributes and Services
• Class--Object
• A Class and the Objects that make up the Class.

3
Finding Class--Objects

• Bring the technical representation of a system as
  close as possible to the real world situation you
  are working with.
• Create a stable foundation for analysis and
  specifications now and in the future.
• Provides stability when moving from systems
  analysis to design.

4
Finding Class--Objects

• The investigative process consists of
• First-hand observation
• Listening actively to the experts
• Reviewing any previous OOA results

5
Finding Class--Objects

• Checking other systems
• Reading carefully all documentation from the
  client
• Building a prototype
• Summarizing

6
Classes vs. Objects

• Object is an instance of some class
• Classes have zero or more instances
• Classes are static
• Objects are created and destroyed
• Air Traffic Control System
• Abstractions (Classes) Objects
• planes New runways
• flight plans New flight plans
• runways New planes enter
• air spaces an airspace

7
Requirements

• Product Description
• Business Solution Description
• Goal Concrete Description understandable to the
  user
• Domain Analysis
• Problem Analysis
• Applied only to new, difficult, or unsolved
  problems
• Goal Complete understanding of the solution and
  constraints on business solutions

8
Problem Analysis

• Developers acquire knowledge of the system
• Identify possible constraints on business
  solution
• Interview business domain experts
• Issues to be addressed
• find a way to trade off constraints
• find ways to organize the information

9
Business Solution Description

• Describe the external behavior of the product to
  be built
• Issues to be addressed
• ideals are organized
• conflicting views are resolved
• inconsistencies and ambiguities are eliminated

10
Business Solution Description Problem Analysis
should produce a model that

• Organizes the data into objects and classes, and
  gives the data a structure via relationships of
  inheritance, aggregation, and association.
• Specifies local functional behaviors and defines
  their external interfaces (service prototypes)
• Captures control or global behavior
• Captures constraints (limits and rules)

11
Suggested Approach for Finding Objects - Step 1

• Use Nouns
• Pioneered by Abbott and popularized by Booch
• Obtain an informal requirements document
• Use nouns, pronouns, and noun phrases to
  identify objects and classes

12
Suggested Approach for Finding Objects - Step 1

• Identify Objects
• Singular proper nouns
• Jim, he, she, employee number 5, my workstation,
  my home
• Nouns of direct reference
• The sixth player, the one-millionth purchase

13
Suggested Approach for Finding Objects - Step 1

• Identify classes
• Plural nouns
• People, customers, vendors, users, employees
• Common nouns
• Everyone, a player, a customer, an employee, a
  workstation

14
Suggested Approach for Finding Objects - Step 1

• Identify Operations
• Verbs
• Pay, collect, read, request
• Predicate phrases
• Are all paid, have simultaneously changed
• Identify Attributes
• Nouns related to the class nouns
• Name, height, weight

15
Suggested Approach for Finding Objects - Step 1

• Indirect approach to finding objects and classes
• Nouns are not always classes or objects in the
  problem domain
• Used to find potential objects and will not find
  all the objects

16
Suggested Approach for Finding Objects - Step 2

• Interactive dialog with the domain expert
• Domain experts commonly make mental models and
  work with abstractions to deal with complexity of
  their respective business
• See dialog on p. 40-41 of Teach Yourself UML
• Identify all the objects that the domain experts
  identify

17
Suggested Approach for Finding Objects - Step 3

• Identify the Things to be Modeled in the
  Application domain
• Persons, roles, organizations, locations, logs,
  reports, forms, concepts, events
• This helps to trigger our recognition of
  potential objects

18
Things to be Modeled
Coad and Yourden
Categories
Explanation
Structure Kind-of Part-of Other
Systems External Systems Devices Events
Remembered A historical event Roles Played
Roles user play Location Organization Units
Groups to which the user belongs
19
Things to be Modeled
Shlaer and Mellor
Categories
Explanation
Tangibles Cars, telemetry data,
sensors Roles Mother, teacher,
programmer Incidents
Landing, interrupt, collision Interactions
Loan, meeting, marriage Specificatio
n Product spec, standards
20
Things to be Modeled
Ross
Categories
Explanation
People Humans who perform
some function Places Areas set aside
for people or things Things Physical
Objects Organizations
Collections of people having a defined
mission Concepts Non tangible
ideas Events Things that happen
21
Suggested Approach for Finding Objects - Step 4

• Eliminate false problem domain objects
• Is it a real world entity?
• Is it important to the discussion of the
  requirements?
• Does it have a crisply defined boundary?