Objectives: 1. Classes and Objects

2. Attributes

3. Services

4. Subjects

Object-Oriented Analysis –

Finding Class-&-Obects

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.

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.

Finding Class-&-Objects

The investigative process consists of:

First-hand observation

Listening actively to the experts

Reviewing any previous OOA results

Finding Class-&-Objects

Checking other systems

Reading carefully all documentation from the client

Building a prototype

Summarizing

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

Requirements

Product DescriptionBusiness Solution Description

Goal: Concrete Description understandable to the user

Domain AnalysisProblem Analysis

Applied only to new, difficult, or unsolved problems

Goal: Complete understanding of the solution and constraints on business solutions

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

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

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)

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

Suggested Approach for Finding Objects - Step 1

Identify Objects

Singular proper nounsJim, he, she, employee number 5, my

workstation, my home

Nouns of direct referenceThe sixth player, the one-millionth

purchase

Suggested Approach for Finding Objects - Step 1

Identify classes

Plural nounsPeople, customers, vendors, users,

employees

Common nounsEveryone, a player, a customer, an

employee, a workstation

Suggested Approach for Finding Objects - Step 1

Identify Operations

VerbsPay, collect, read, request

Predicate phrasesAre all paid, have simultaneously changed

Identify Attributes

Nouns related to the class nounsName, height, weight

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

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

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

“Things to be Modeled”

Coad and Yourden

Categories Explanation

Structure “Kind-of” & “Part-of”Other Systems External SystemsDevicesEvents Remembered A historical eventRoles Played Roles user playLocationOrganization Units Groups to which the user

belongs

“Things to be Modeled”

Shlaer and Mellor

Categories Explanation

Tangibles Cars, telemetry data, sensorsRoles Mother, teacher, programmerIncidents Landing, interrupt, collisionInteractions Loan, meeting, marriageSpecification Product spec, standards

“Things to be Modeled”

Ross

Categories Explanation

People Humans who perform somefunction

Places Areas set aside for people orthings

Things Physical ObjectsOrganizations Collections of people having

a defined missionConcepts Non tangible ideasEvents Things that happen

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?