Object Oriented Analysis and Design Using the UML

Basic Concepts of Object Orientation Object Class Attribute Operation Interface (Polymorphism) Component Package Subsystem Relationships

What is an Object? Informally, an object represents an entity,

either physical, conceptual, or software Physical entity

Conceptual entity

Software entity

Truck

Chemical Process

Linked List

A More Formal Definition

An object is a concept or thing with sharp boundaries and meaning for an application

An object is something that has: State Behavior Identity

Professor :Professor LAL

Class Name Only Object Name Only

Representing Objects

An object is represented as rectangles with underlined names

OO Principle: Abstraction

What is a Class?

A class is a description of a group of objects with same properties (attributes), behavior (operations), relationships, and semantics An object is an instance of a class

a + b = 10

ClassCourse

PropertiesName

LocationDays offeredCredit hours

Start timeEnd time

BehaviorAdd a student

Delete a studentGet course roster

Determine if it is full

Sample Class

Professor

Professor Simran

a + b = 10

Representing Classes

A class is represented using a compartmented rectangle

ProfessornameempID

create( )save( )delete( )change( )

Class Name

Attributes

Operations

Class Compartments A class is comprised of three sections

The first section contains the class name The second section shows the structure

(attributes) The third section shows the behavior (operations)

:CourseOffering

number = 101startTime = 900endTime = 1100

:CourseOffering

number = 104startTime = 1300endTime = 1500

CourseOffering

numberstartTime endTime

Class

Attribute

Object

Attribute Value

What is an Attribute?

CourseOffering

addStudent deleteStudentgetStartTimegetEndTime

Class

Operation

What is an Operation?

Package NameOO Principle:

Modularity

What is a Package? A package is a general purpose mechanism for

organizing elements into groups A model element which can contain other model

elements

Package is rendered as a tabbed folder including name and sometimes, its contents.

Basic Concepts of Object Orientation Object Class Attribute Operation Interface (Polymorphism) Component Package Subsystem Relationships

Relationships Association

Aggregation Composition

Dependency Generalization

Professor UniversityWorks for

Class

Association

Association Name

Professor University

EmployerEmployee

Role Names

Relationships: Association Models a semantic connection among

classes

16

Association

Association represents binary relationship between classes

Student Course

Faculty

advisee

adviser

* enroll

teach

* *

1 1

*

Student Schedule

Whole

Aggregation

Part

Relationships: Aggregation A special form of association that models a

whole-part relationship between an aggregate (the whole) and its parts

18

Aggregation and Compositon

Aggregation is a special form of association Has-a or part-whole relationship

Composition is a stronger form of aggregation

Student Schedule

Whole

Aggregation

Part

A form of aggregation with strong ownership and coincident lifetimes The parts cannot survive the whole/aggregate

Association: Multiplicity and Navigation Multiplicity defines how many objects participate in a

relationships The number of instances of one class related to ONE

instance of the other class Specified for each end of the association

Associations and aggregations are bi-directional by default, but it is often desirable to restrict navigation to one direction If navigation is restricted, an arrowhead is added to indicate

the direction of the navigation

Association: Multiplicity

2..4

0..1

1..*

0..*

1

Unspecified Exactly one Zero or more (many, unlimited) One or more Zero or one Specified range Multiple, disjoint ranges

2, 4..6

Student Schedule1 0..*

Multiplicity

Navigation

Example: Multiplicity and Navigation

23

Example

University Department

Faculty

Chairman-of Member-of

* *College Student*11 1

11

1 1..*

Client Supplier

Package

ClientPackage SupplierPackage

Client Supplier

Class

Dependency relationship

Dependency relationship

Component

Relationships: Dependency A relationship between two model elements where a

change in one may cause a change in the other.

25

Dependency is a relationship between entities such that the proper operation of one entity depends on the presence of the other entity, and changes in one entity would affect the other entity.

Relationships: Generalization

A relationship between superclass and subclass.

Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses. Single inheritance Multiple inheritance

Generalization is an “is-a-kind of” relationship

Accountbalancenamenumber

Withdraw()CreateStatement()

Checking

Withdraw()

Savings

GetInterest()Withdraw()

Superclass (parent)

Subclasses

Generalization Relationship

Ancestor

Descendents

Example: Single Inheritance One class inherits from another

Airplane Helicopter Wolf Horse

FlyingThing Animal

Bird

multipleinheritance

Use multiple inheritance only when needed, and always with caution !

Example: Multiple Inheritance A class can inherit from several other classes

Truck

tonnage

GroundVehicle

weight

licenseNumber

Car

owner

register( )

getTax( )

Person

0..*

Trailer

1Superclass

(parent)

Subclass

generalization

size

Example: What Gets Inherited

30

UMLUnified Modeling Language

31

What is UML?

UML is a language for Visualizing Specifying Constructing Documenting

32

Building Blocks of UML

Things -- abstraction Relations -- tie things together Diagrams -- group interesting collections of

things

33

To view the static parts of a system using one of four following diagrams:

Class diagrams To represent classes and interfaces

Object diagrams To represent Objects

Component diagrams To represent different components

Deployment diagrams To represent different nodes of the system

34

To view the dynamic parts of a system using one of five following diagrams:

Use Case Diagrams Organizes the behavior of the system

Sequence Diagrams Focused on the time ordering of messages

Collaboration Diagrams Focused on the structural organization of objects that

send and receive messages State Chart Diagrams

Focused on the changing state of the system driven by events

Activity Diagrams Focused on the flow of control from activity to activity

35

Use Case Diagrams

It models dynamic aspects of system. Shows set of use cases ,actors and their

relationships.

Contents Use cases Actors relationships

37

Use Case Diagrams

Use Case diagrams show the various activities the users can perform on the system.

They model the dynamic aspects of the system.

38

Use Case Diagrams

A set of ACTORS : roles users can play in interacting with the system. An actor is used to represent something that users our

system. A set of USE CASES: each describes a possible

kind of interaction between an actor and the system. Uses cases are actions that a user takes on a system

A number of RELATIONSHIPS between these entities (Actors and Use Cases). Relationships are simply illustrated with a line

connecting actors to use cases.

39

Use Case Diagrams - Actors

An actor is a user of the system playing a particular role.

Actor is shown with a stick figure.

employee clientemployer

40

Use Case Diagrams – Use Cases Use case is a particular activity a user can do

on the system. Is represented by an ellipse. Following are two use cases for a library

system.

ReserveBorrow

41

Use Case Diagram for Student Assessment Management System

Teacher

Student

Printing administrator

Grade system

Record grades

View grades

DistributeReport cards

Create report cards

42

University Record System (URS) A University record system should keep information

about its students and academic staff. Records for all university members are to include their id

number, surname, given name, email, address, date of birth, and telephone number. Students and academic staff each have their own unique ID

number: studN (students), acadN (academic employee), where N is an integer (N>0).

In addition to the attributes mentioned above: Students will also have a list of subjects they are enrolled in. A

student cannot be enrolled in any more than 10 subjects. Academic employees will have a salary, and a list of subjects

they teach. An academic can teach no more than 3 subjects.

43

Some Actions Supported by URS The system should be able to handle the

following commands. Add and remove university members (students,

and academic staff) Add and Delete subjects Assign and Un-assign subjects to students Assign and Un-assign subjects to academic

staff.

44

Use Case Diagram - URS System

systemuser academic

student

URS

del member

add member

add subject

del subject

assg subject

unass subject

enrol subject

unenrol subject