Unified Modeling Language (UML)

“ a language for specifying, visualizing, and constructing the artifacts of software systems, as well as for business modeling”

• unification of Booch, Jackobson and Rumbaugh modeling approaches

• graphical depiction of O-O analysis and design models– Use cases: functional reqts. (what)– Class diagrams: static structure of objects, their data and

operations– State diagrams: dynamic models of objects change their

state in response to events– Sequence diagrams: dynamic models of interaction

between objects

Benefits of O-O modeling• Increased consistency among models developed for analysis,

design and programming

• Improved communication among users, analysts, designers, programmers

• Explicit representation of commonality among system components

• Reusability of analysis, design and programming results

• Robustness of systems

• Ability to tackle more challenging problem domains

StudentnamedateOfBirthyearaddressphone

calc_age()

calc_gpa()

register(course)

Course

codedepttitlecreditHours

enrollment()

prereqs()

:Course

code=IDS405dept=IDStitle=blah_blahcreditHours=3

J.Daniels:Student

name=Jack DanielsdateOfBirth=01/01/99year=senior

Anatomy of a class

Encapsulation:All information is packaged under one name, and can be reused as one specification or program component

Information hidingAttributes of a class can be accessed only through the class operations/methods/services (external interface for a class)

• Reduced impact of side effects of changes• More cohesive methods• Class is de-coupled from other parts of system

Attributes

Operations/methods

State of an object:

values for attributes, and links to other objects

Object identity

Operations

(service provided by an object to its client)

• Constructor: creates a new instance of an object-class

• Query: does not change state of object, no side-effects. -no need to explicitly show operation like get_name() -target object is always an implicit argument

• Update: alters the state of an object

Customer

Order Product

Product Line

Places

Requests

Includes

1

** 1..*

1..*

1

Class Diagram (ORD) : object-class associations

Object Diagram: instance diagram - graph of instances that is compatible with a given class diagram.

:Customer A

:Customer A:Customer A

:Order 1:Order 1 :Order 1

:Product A2 :Product A6

:Product P2

:Product P5 :Product X6

:Product Line A :Product Line P :Product Line X

Object (Instance)diagram

Student Coursetutor

pupilTutors

**

beginDatenumHours

termgrade

Registration

CheckEligibility()

acctNumpasswordserverSpace

AccountIssues

* *

* 0..1

Software

Student Course

Log

beginDateexpirydatehoursLogged

estimateUsage()

tool

user forum

*

*

*

Student

NamessndateOfBirth/age

Course Offeringtermsection

Course

/participants

registrants

Registers-for

* *

Scheduled-for

* 1..*

**

CodetitlecrdHours

{age = currentDate - dateOfBirth}

Derived attribute, association

Student {abstract}

NamessndateOfBirth

Course Offeringtermsection

Course

registrants

Registers-for

* *

Scheduled-for

* 1..*

CodetitlecrdHours

register-for(class)calc_tuition()

Grad-Student

ugMajorgreScoretuition=300

Calc_tuition()

UG-Student

satScoreactScoretuition=250

Calc_tuition()

• Abstract class• Concrete class• Abstract operation polymorphism

enrollment() enrollment()

University

Admn.Unit School

Department

Building

Room

1

1..* 1..*

1

*

1 1

1

20..*

Aggregation

Composition

Composition: part belongs to only a single whole, and dies with the whole

Object Communication Through Message Passing:

Message: request sent by an object for the services/assistance of a second object. Receiving object responds by choosing appropriate method, executing it and returning control to caller.

E.g.: Customer wants to check status of an order

CustomerOrder

O#ODate

O-Status...

AddOrder()ModifyOrder()

DisplayStatus()...

Message request

Display Statusof order#1267

POLYMORPHISM:

Same named behavior may be completed differently for different object classes

Bank Account

PassbookAccount

Saving InvstAccount

Saving Account

CheckingAccount

Customer

Withdraw()

Withdraw()

Withdraw()

Withdraw()

Withdraw()

Bank Acct XX: Withdraw()

1*

Rental Order Line

Due-Date

Rental Category

Rental Tape

TapeName

Rental Order

RO#

Object Behavior design

•Assign methods to classes

•Method Determine DueDate ----- Which Class ?

Assigning Methods to Classes :– try to assign method to class that knows the

required attributes– assign method to class that is logically expected t

perform the method

Object Behavior Analysis: some guidelines

• Methods should be distributed fairly evenly among classes, so that you avoid having a few “control” objects and many “data” objects

• When possible, assign method to class that knows the attributes needed to perform the method– when no single class knows all the attributes needed,

assign method to the class that would be logically expected to perform the method

Guidelines [contd]

• Methods used to create and break relationships should be assigned to the class that controls the relationship

• Method that changes the state of an object should be assigned to the class.

• When in doubt, act it out!

Rental Customer

Authorized User

Rental customer can exist without be associated with Authorized User, but not vice-versa.So, method AddAuthorizedUser() should be assigned to Rental Customer (the controlling class)

Two classes: Account and Payment. A method reportStatus(..) returns values “overdue” or “paid”. Which class should contain this method?

Example

Example

Example

A method calcExtendedPrice(..) multiplies the quantity of a line item by the price of the line item. Quantity is an attribute of LINE-ITEM and price is an attribute PRODUCT. Should this method be assigned to LINE-ITEM or PRODUCT?

Example

Method addAccount() creates a relationship between a Customer instance and an Account instance. Each customer can be related to zero or many Accounts objects, but each Account object must be related to exactly one Customer object.Which class should this method be assigned to?

Evaluating Object-behavior design

• Present functionality vs. future adaptability (reusability)• Coupling:

– should not have to pass a lot of data between objects - no message should need more than three parameters

– No messages should be sent from sub-classes to access data in a super-class - taken care of by inheritance.

– Coupling is a natural side-effect of specialization and composition relationships - however, collaboration relationships should not be so strong that Class-A and useless without Class-B.

• Cohesiveness– single functionality per methodEg. completeOrderFooter(..) that also prints the order

- two separate methods better

– overriding of attributes and methods defined in a super-class should not be too frequent.

• Clarity

• Complexity vs. reusability– neither too deep, nor too wide

Evaluating Object-behavior design [contd.]

Evaluating Object-behavior design [contd.]

• Simplicity– should not have too many methods in a class

• 5 or 6; number of attributes less than twice number of methods

– too many methods signify an application specific definition of a class, which will be difficult to reuse.

• “Act-ability”– high quality OO design can be acted out be humans playing

the role of objects

– can be verified by a structured walk-through

– mappings between real-world objects and system objects should be transparent.