55

Basic Principles of Object Orientation Basic Concepts of Object Orientation …€¦ ·  · 2013-08-14Association Aggregation Composition ... Generalization is an “is-a-kind of”

  • Upload
    buinhi

  • View
    228

  • Download
    1

Embed Size (px)

Citation preview

Basic Principles of Object Orientation

Basic Concepts of Object Orientation

Strengths of Object Orientation

General UML Modeling Mechanisms

Object Orientation

En

cap

sula

tio

n

Ab

stra

ctio

n

Hie

rarc

hy

Mo

du

lari

ty

Salesperson

Not saying

Which

salesperson

– just a

salesperson

in general!!!

CustomerProduct

Manages Complexity

Improves Resiliency

Hide implementation from clients Clients depend on interface

How does an object encapsulate?

What does it encapsulate?

Order Processing

System

Billing

Order

Entry

Order

Fulfillment

Manages Complexity

The breaking up of something complex into manageable pieces

Decreasing

abstraction

Increasing

abstraction

Asset

RealEstate

Savings

BankAccount

Checking Stock

Security

Bond

Elements at the same level of the hierarchy should be at the same level of abstraction

Levels of abstraction

Basic Principles of Object Orientation

Basic Concepts of Object Orientation

Strengths of Object Orientation

General UML Modeling Mechanisms

Object

Class

Property

Method

Interface (Polymorphism)

Component

Package

Subsystem

Relationships

Object

Class

Property

Method

Interface (Polymorphism)

Component

Package

Subsystem

Relationships

Truck

Chemical Process

Linked List

Informally, an object represents an entity, either physical, conceptual, or software Physical entity

Conceptual entity

Software entity

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

An object is something that has: State

Behavior

Identity

An object is represented as rectangles with underlined names

: Professor

Professor Clark

a + b = 10

ProfessorClark :

Professor

ProfessorClark

Class Name Only

Object Name Only

Class and Object Name(stay tuned for classes)

Object

Class

Property

Method

Interface (Polymorphism)

Component

Package

Subsystem

Relationships

OO Principle: Abstraction

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

A class is an abstraction in that it: Emphasizes relevant characteristics

Suppresses other characteristics

a + b = 10

Class

Course

Properties

Name

Location

Days offered

Credit hours

Start time

End time

Behavior

Add a student

Delete a student

Get course roster

Determine if it is full

Professor

Professor Clark

a + b = 10

A class is represented using a compartmented rectangle

A class is comprised of three sections The first section contains the class name

The second section shows the structure (properties)

The third section shows the behavior (methods)

ProfessornameempID

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

Class Name

Properties

Methods

How many classes do you see?

Objects Class

Professor Smith

Professor Jones

Professor Mellon

Professor

A class is an abstract definition of an object It defines the structure and behavior of each object in

the class

It serves as a template for creating objects

Objects are grouped into classes

Object

Class

Property

Method

Interface (Polymorphism)

Component

Package

Subsystem

Relationships

:CourseOffering

number = 101

startTime = 900

endTime = 1100

:CourseOffering

number = 104

startTime = 1300

endTime = 1500

CourseOffering

number

startTime

endTime

Class

Properties

Object

Property Value

Object

Class

Property

Method

Interface (Polymorphism)

Component

Package

Subsystem

Relationships

CourseOffering

addStudent

deleteStudent

getStartTime

getEndTime

Class

Method

Object

Class

Property

Method

Interface (Polymorphism)

Component

Package

Subsystem

Relationships

Manufacturer AManufacturer B

Manufacturer C

OO Principle:

Encapsulation

The ability to hide many different implementations behind a single interface

Tube

Pyramid

Cube

Shape

Draw

Move

Scale

Rotate

<<interface>>

Realization relationship(stay tuned for realization relationships)

Interfaces formalize polymorphism

Interfaces support “plug-and-play” architectures

Tube

Pyramid

Cube

Shape

Draw

Move

Scale

Rotate

<<interface>>

Tube

Pyramid

CubeShape

Elided/Iconic

Representation

(“lollipop”)

Canonical

(Class/Stereotype)

Representation

(stay tuned for realization relationships)

Object

Class

Property

Method

Interface (Polymorphism)

Component

Package

Subsystem

Relationships

Source File

Name

<<EXE>>

Executable

Name

OO Principle:

Encapsulation

A non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture

A component may be A source code component

A run time components or

An executable component

<<DLL>>

Component

NameComponent

Interface

Object

Class

Property

Method

Interface (Polymorphism)

Component

Package

Subsystem

Relationships

Package NameOO Principle:

Modularity

A package is a general purpose mechanism for organizing elements into groups

A model element which can contain other model elements

Uses Organize the model under development A unit of configuration management

Object

Class

Property

Method

Interface (Polymorphism)

Component

Package

Subsystem

Relationships

OO Principles: Encapsulation and Modularity

<<subsystem>>

Subsystem Name

InterfaceInterface

RealizationSubsystem

(stay tuned for realization relationship)

A combination of a package (can contain other model elements) and a class (has behavior)

Realizes one or more interfaces which define its behavior

Component

Name

Design Model Implementation Model

<<subsystem>>

Component Name

Component

Interface

Component

Interface

OO Principles: Encapsulation and Modularity

Components are the physical realization of an abstraction in the design

Subsystems can be used to represent the component in the design

Object

Class

Property

Method

Interface (Polymorphism)

Component

Package

Subsystem

Relationships

Association Aggregation

Composition

Dependency

Generalization

Realization

Professor UniversityWorks for

Class

Association

Association Name

Professor University

EmployerEmployee

Role Names

Models a semantic connection among classes

Student Schedule

Whole

Aggregation

Part

A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts

Student Schedule

Whole

Aggregation

Part

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

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

Unspecified

Exactly one

Zero or more (many, unlimited)

One or more

Zero or one

Specified range

Multiple, disjoint ranges 2..4

0..1

1..*

0..*

1

*

2, 4..6

Student Schedule1 0..*

Multiplicity

Navigation

Client Supplier

Package

ClientPackage SupplierPackage

Client Supplier

Class

Dependency

relationship

Dependency

relationship

Component

A relationship between two model elements where a change in one may cause a change in the other

Non-structural, “using” relationship

A relationship among classes where one class shares the structure and/or behavior of one or more classes

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

Account

balancenamenumber

Withdraw()CreateStatement()

Checking

Withdraw()

Savings

GetInterest()Withdraw()

Superclass

(parent)

Subclasses

Generalization

Relationship

Ancestor

Descendents

One class inherits from another

Inheritance leverages the similarities among classes

A subclass inherits its parent’s attributes, operations, and relationships

A subclass may: Add additional attributes, operations, relationships

Redefine inherited operations (use caution!)

Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy

Truck

tonnage

GroundVehicle

weight

licenseNumber

Car

owner

register( )

getTax( )

Person

0..*

Trailer

1Superclass

(parent)

Subclass

generalization

size

Component

Interface

Use Case Use-Case Realization

Elided form

Class

InterfaceSubsystem

Interface

Canonical form

One classifier serves as the contract that the other classifier agrees to carry out

Found between: Interfaces and the classifiers that realize them

Use cases and the collaborations that realize them

Salesperson Product

Sale

Corporate

Customer

Individual Truck

Vehicle

Train

seller buyer item sold shipping mechanism

Suppose you need a new type of shipping vehicle ...

Salesperson Product

Sale

Corporate

Customer

Individual Truck

Vehicle

Train

seller buyer item sold shipping mechanism

Change involves adding a new subclass

Airplane

Basic Principles of Object Orientation

Basic Concepts of Object Orientation

Strengths of Object Orientation

General UML Modeling Mechanisms

There can be up to one

MaintainScheduleForm per

user session.MaintainScheduleForm

A note can be added to any UML element

Notes may be added to add more information to the diagram

It is a ‘dog eared’ rectangle

The note may be anchored to an element with a dashed line

PersistentClass

{persistence} anObject : ClassA

{location=server}

Extensions of the properties, or specific attributes, of a UML element

Some properties are defined by UML Persistence

Location (e.g., client, server)

Properties can be created by UML modelers for any purpose

Professor DepartmentMember

Department Head{subset}

1..*

1

1

1

Supports the addition of new rules or modification of existing rules

This notation is used to capture two relationships between Professor-type objects

and Department-type objects; where one relationship is a subset of another….

Shows how UML can be tailored to correctly modeling exact relationships….