Agenda

59
1 Object Modeling Crash Course Object Analysis Classification Identifying Object Relationships, Attributes, and Methods Class Diagrams Agenda

description

Agenda. Object Modeling Crash Course Object Analysis Classification Identifying Object Relationships, Attributes, and Methods Class Diagrams. Object Modeling Crash Course. Basic Object Concepts. Attributes and Methods Objects vs. Classes Encapsulation, Inheritance, Polymorphism - PowerPoint PPT Presentation

Transcript of Agenda

Page 1: Agenda

1

Object Modeling Crash Course

Object Analysis– Classification– Identifying Object Relationships, Attributes, and Methods

Class Diagrams

Agenda

Page 2: Agenda

Object Modeling Crash Course

Page 3: Agenda

3

Basic Object Concepts Attributes and Methods Objects vs. Classes Encapsulation, Inheritance, Polymorphism Relationships

Page 4: Agenda

4

What is an object? The term object was first formally utilized in the Simula

language to simulate some aspect of reality. An object is an entity.

– It knows things (has attributes)– It does things (provides services or has methods)

Page 5: Agenda

5

Attributes Objects know things

I am an Employee. I know my name, social security number and my address.

I am a Car.I know my color, manufacturer, cost, owner and model.

I am a Fish. I know my date of arrival andexpiration.

Page 6: Agenda

6

Methods Objects do things

I know how to computemy payroll.

I know how to stop.

I know how to cook myself.

Page 7: Agenda

7

What is an object? Attributes or properties describe object’s state (data) and

methods define its behavior. Object is whatever the information system wants to talk

about.– For example, Parts and assemblies might be objects of bill of

material application. – Stocks and bonds might be objects of financial investment

applications.

In an object-oriented system, everything is an object: numbers, arrays, records, fields, files, forms, an invoice, etc.

Page 8: Agenda

8

Two Basic Questions of OO Analysis and Design When developing an OO information system, two basic

questions always arise.– What objects does the application need?– What functionality should those objects have?

Object Analysis

Page 9: Agenda

9

Objects and Classes The role of a class is to define the attributes and methods

(the state and behavior) of its instances. The class car, for example, defines the property color. Each individual car (object) will have a value for this property,

such as "maroon," "yellow" or "white."

Page 10: Agenda

10

A Class is an Object Template, or an Object Factory.

Boeing Factory(Boeing Class)

Boeing Airplane Objects(Boeing Instances)

Page 11: Agenda

11

Class Hierarchy An object-oriented system organizes classes into subclass-

super hierarchy. At the top of the hierarchy are the most general classes and

at the bottom are the most specific

Page 12: Agenda

12

Class Hierarchy (Cont’d) A subclass inherits all of the properties and methods

(procedures) defined in its superclass.

Motor Vehicle

Truck CarBus

Page 13: Agenda

13

Inheritance Inheritance is a relationship between classes where one

class is the parent class of another (derived) class. Inheritance allows classes to share and reuse behaviors and

attributes. The real advantage of inheritance is that we can build upon

what we already have and, reuse what we already have.

Page 14: Agenda

14

Inheritance (Cont’d)

Ford

Vehicle

Car

Mustang Taurus Thunderbird

stop (myMustang)

I don’t know how to stop

I know how to stopstop method is reusable

Page 15: Agenda

15

Multiple Inheritance OO systems permit a class to inherit from more than one

superclass. This kind of inheritance is referred to as multiple inheritance.

Page 16: Agenda

16

Multiple Inheritance (Cont’d) For example utility vehicle inherits from Car and Truck

classes.

MotorVehicle

Truck Car Bus

UtilityVehicle

Page 17: Agenda

17

Encapsulation and Information Hiding Information hiding is a principle of hiding internal data and

procedures of an object.– Reveal as little as possible about its inner workings.– Encapsulation protects the data from corruption.

Public Protocol

Messages

Data

Permissible operations

Private Protocol

Page 18: Agenda

18

Polymorphism Polymorphism means that the same operation may behave

differently on different classes. Example: computePayroll

Page 19: Agenda

19

Polymorphism – computePayroll1. Managers: Receive a regular salary

2. Office Workers: Receive an hourly wage and are eligible for overtime after 40 hours

3. Production Workers: Are paid according to a piece rate

Employee

OfficeWorker Manager ProductionWorker

nameaddresssalarySS#

dataEntryComputePayrollprintReport

dataEntryComputePayrollprintReport

dataEntryComputePayrollprintReport

Page 20: Agenda

20

Associations

The concept of association represents relationships between objects and classes.

For example a pilot can fly planes.

Pilot Planescan fly flown by

Page 21: Agenda

21

Clients and Servers A special form of association is a client-server relationship. This relationship can be viewed as one-way interaction: one

object (client) requests the service of another object (server).

PrintServer ItemRequest for printing

Page 22: Agenda

Object Analysis

Page 23: Agenda

23

Object Analysis = Classification / Generalization Classification and Generalization is Difficult

– God is Love– Love is blind– Ray Charles is blind– ergo...

Page 24: Agenda

24

Identifying Classes1. Noun phrase approach.

2. Common class patterns approach.

3. Use Case driven approach.

4. Class Responsibilities Collaboration (CRC) approach.

Page 25: Agenda

25

1. Noun Phrase Approach Using this method, read through the Use cases, interviews,

and requirements specification carefully, looking for noun phrases.

It is safe to scrap the Irrelevant Classes. Formulate a statement of purpose for each candidate class; if

it’s not possible, simply eliminate it.

Page 26: Agenda

26

Guidelines For Identifying Classes Look for nouns and noun phrases in the problem statement. Some classes are implicit or taken from general knowledge. All classes must make sense in the application domain. Avoid computer implementation classes, defer it to the

design stage. Carefully choose and define class names.

Page 27: Agenda

27

Guidelines For Refining Classes Redundant Classes:

– Do not keep two classes that express the same information. – If more than one word is being used to describe the same idea,

select the one that is the most meaningful in the context of the system.

Adjective Classes: – Does the object represented by the noun behave differently

when the adjective is applied to it?– If the use of the adjective signals that the behavior of the object

is different, then make a new class.– For example, If Adult Membership and Youth Membership

behave differently, than they should be classified as different classes.

Page 28: Agenda

28

Guidelines For Refining Classes (Cont’d) Attribute Classes:

– Tentative objects which are used only as values should be defined or restated as attributes and not as a class.

– For example the demographics of Membership are not classes but attributes of the Membership class.

Irrelevant Classes: – Each class must have a purpose and every class should be

clearly defined and necessary. – If you cannot come up with a statement of purpose, simply

eliminate the candidate class.

Page 29: Agenda

29

2. Common Class Patterns Approach This approach is based on the knowledge-base of the

common classes that have been proposed by various researchers.

Page 30: Agenda

30

Candidate Classes Events

– These are points in time that must be recorded and remembered. – Things happen, usually to something else, at a given date and

time, or as a step in an ordered sequence. – For example order which is an event that must be remembered.

Organization– The organizational units that people belong to. – For example, accounting department might be considered as a

potential class.

Page 31: Agenda

31

Candidate Classes (II) People and Person (Roles and Roles Played)

– The different roles users play in interacting with the application.– Two Types of People (Coad and Yourdon):

– Users of the system– E.g., Operator, Clerk

– Those who do not use the system but about whom information is kept.

– E.g., Client, Employee

Places– Physical locations, such as buildings, stores, sites or offices

that the system must keep information about.

Page 32: Agenda

32

Candidate Classes (III) Tangible Things and Devices

– Physical objects, or group of objects, that are tangible, and devices with which the application interacts.

– E.g., Cars, ATM Concepts

– Concepts are principles or ideas not tangible but used to organize or keep track of business activities and/or communications.

– E.g., Order, LineItem

Page 33: Agenda

33

3. Use Case Driven Approach Once the system has been described in terms of its

scenarios, examine the textual description or steps of each scenario to determine what objects are needed for the scenario to occur.

To identify objects of a system and their behaviors, the lowest level of executable use cases is further analyzed with a sequence and collaboration diagram pair.

By walking through the steps, you can determine what objects are necessary for the scenario to take place.

Page 34: Agenda

34

Sequence Diagram – ExampleClient ATMMachine BankClient

Bad PIN Number

Bad PIN NumberMessage

Eject ATM card

Request take card

Take card

Display main screen

Verify PIN Number

Request PIN number

Request PIN

Insert ATM card

Page 35: Agenda

35

ATM Machine:Definition

Checking Account

Account Bank Client

5: Process Transaction

8: Transaction succeed

4: Enter Amount13: Terminate

1: Request Kind

2: Enter Kind

3: Request Amount9: Dispense Cash

10: Request Take Cash11: Take Cash

12: Request Continuation14: Print Receipt

7: Withdraw Successful 6: Withdraw Checking Account

Collaboration Diagram – Example

Page 36: Agenda

36

3. CRC Cards Approach CRC stands for Class, Responsibilities and Collaborators

developed by Cunningham, Wilkerson and Beck. CRC can be used for identifying classes and their

responsibilities. Process of the CRC Technique

IdentifyClasses

Responsibility

AssignResponsibility

IdentifyCollaboration

Iterate

Page 37: Agenda

37

Collaborations An object can accomplish either a certain responsibility itself,

or it may require the assistance of other objects. If it requires an assistance of other objects, it must

collaborate with those objects to fulfill its responsibility. CRC Cards:

– CRC cards are 4" x 6" index cards. All the information for an object is written on a card.

ClassNameResponsibilities Collaborators

Page 38: Agenda

38

CRC Cards – Example

OrderCheck if items in stock OrderLine

Determine Price OrderLine

Check for valid payment Customer

Dispatch to delivery address

Page 39: Agenda

39

CRC Cards Process (Cont’d) CRC starts with only one or two obvious cards. If the situation calls for a responsibility not already covered

by one of the objects: – Add, or– Create a new object to address that responsibility.

Page 40: Agenda

40

Object Modeling Issues – Naming Classes Guidelines

– The class should describe a single object, so it should be the singular form of noun.

– Use names that the users are comfortable with. – The name of a class should reflect its intrinsic nature.– By the convention, the class name must begin with an upper

case letter. – For compound words, capitalize the first letter of each word

– E.g., LoanWindow.

Page 41: Agenda

41

Object Modeling – Summary Finding classes is not easy. The more practice you have, the better you get at identifying

classes. There is no such thing as the “right set of classes.” Finding classes is an incremental and iterative process. Unless you are starting with a lot of domain knowledge, you

are probably missing more classes than you will eliminate. Naming a class is also an important activity.

Page 42: Agenda

Class Diagram

Page 43: Agenda

43

Different Perspectives Class diagrams can be used in a number of ways:

– Conceptual – You draw a class diagram of elements under study– Specification – You develop an programming interface– Implementation – You give guidance to an programmer

Page 44: Agenda

44

The Class

MyClass

Attribute1Attribute2

Method1Method2(Integer)Method3():String

Class Name

Attributes

Operations

ParameterReturn Value

Page 45: Agenda

45

Associations

Order

Order Line

*

1

{if customer.creditRating=0 then isPrepaid must = true}

Line items

Multiplicity: many valued

Multiplicity: required Multiplicity: optional

Customer* 0..1

Role Name

Association

Constraint

Navigability

Page 46: Agenda

46

Associations Conceptual perspective

– Conceptual relationships between classes Specification perspective

– Class responsibilities– Interfaces

Implementation perspective– Pointers

Page 47: Agenda

47

Associations Each Association:

– Involves two classes– Has two roles– Has two multiplicities (one for each role)

– 0..1, 0..*, 1, 1..*, *– Can have zero, one, or two navigability indicators – indicates

one-way dependency

Page 48: Agenda

48

Attributes Attributes describe a possible state of a class Similar to Associations

– But, – One way navigability (from Class to Attribute)– Usually for single valued simple classes (e.g., strings, dates,

integer, double) Syntax:

– visibility name: type = defaultValue

Page 49: Agenda

49

Operations Operations describe possible methods in a class Syntax:

– visibility name (parameter-list): return-type-expression {property-

string}

Query vs. Modifier operations– Get Methods– Set Methods

Page 50: Agenda

50

Associations: Generalization

Customer

PersonalCustomer

CorporateCustomer

Generalization

Inheritance is also called generalization

Passes the “is a” test

Page 51: Agenda

51

Constraint Rules Syntax:

– Not formal– {constraint-statement}

Assertions– Pre-condition– Post-condition– Invariants

Page 52: Agenda

Class DiagramAdvanced Concepts

Page 53: Agenda

53

Stereotypes Stereotypes are a high-level classification of an object. Not an ancestor, but rather a set of attributes that many

objects share. Indicated using the following convention: <<stereotype>>

Page 54: Agenda

54

Multiple and Dynamic Classification Multiple classification --

multiple subtypes Dynamic classification --

allows change

Person{abstract}

Male Female Employee

Sex{complete}

Job

Male Female

Programmer

Sex{complete}

Job <<dynamic>>

Manager

Person{abstract}Abstract Class

Page 55: Agenda

55

Aggregation and Composition Aggregation -- when the

purpose of a class is to collect instances of other classes.

Composition -- Aggregation with dependency on the whole -- 2 alternative drawings:

Polygon

Point

StylecolorisFilled

Circleradius

3..*

{ordered}

1

11

* *

Composition

Aggregation

Page 56: Agenda

56

Composition Alternative Notation

StylecolorisFilled

Circle

radius 1

Point

Polygon

radius{ordered} 3..*

Point

* *

1 1

Page 57: Agenda

57

Derived Associations and Attributes Derived associations and attributes are not explicit but rather

derived Noted by using a “/”

Sale

/tax:Currency

Salesperson

/seller

Seller role is derived using seller.territory

Derived Role

Derived Attribute

Note

Page 58: Agenda

58

Qualified Associations Constraints on the association

ProductOrderOrderLine

amount:Number

0..1

LineItem

OrderOrderLine

amount:Number

0..*

LineItem

Page 59: Agenda

59

Association Classes Just as with associative tables in databases, associative

classes resolve many-to-many relationships

Person Department

Employmentperiod:dateRange

* *

Association Indicator