Object Orientation and Design: Methodology & Conceptualization

You might also like

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 51

Object Orientation and Design

Methodology & Conceptualization


Basic Principles of
Object Orientation
Object Orientation

Encapsulation
Abstraction

Modularity

Hierarchy
What is Abstraction?
• Abstraction is one of the very important concepts
of object oriented systems.

• Abstraction focuses on the essential, inherent


aspects of an object of the system.

• Most of the modern languages provide data


abstraction

Manages Complexity
What is Encapsulation?
 Encapsulation, or information hiding, is the
feature of separating the external aspects of an
object, from the internal implementation details of
that object.
It helps in hiding the actual implementation of
characteristics of objects.
Encapsulation enables you to combine data
structure and behaviour in a single entity.
Encapsulation helps in system enhancement.
Improves Resiliency
What is Modularity?
The breaking up of something complex into manageable
pieces.
“It is a property of a system that has been decomposed
into cohesive and loosely coupled modules”
Cohesion and coupling gives two goals for defining
modules.
Module cohesive (shared data structures, similar classes)
with an interface that allows for minimal inter-module
coupling.

Manages Complexity
What is Hierarchy ? Asset
Increasing
abstraction

Bank Account Security Real Estate

Savings Current Stock Bond

Decreasing Elements at the same level of the hierarchy


abstraction should be at the same level of abstraction
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 Truck

◦ Software entity
Chemical Process
What is an Object ?
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
Representing Objects
An object is represented as rectangles with underlined names

: Professor
a + b = 10

ProfessorClark
Class Name Only
Professor Clark
ProfessorClark :
Professor Object Name Only

Class and Object Name


(stay tuned for classes)
What is a Class?
A class is a description of a group of objects
with common properties (attributes),
behavior (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
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)

Class Name Professor


name
Attributes empID
Operations create( )
save( )
delete( )
change( )
What is an Attribute?
Class
Object
Attribute Attribute Value
:CourseOffering
number = 101
startTime = 900
CourseOffering endTime = 1100
number
startTime
endTime :CourseOffering
number = 104
startTime = 1300
endTime = 1500
What is an Operation?
CourseOffering
Class
addStudent ( )
deleteStudent ( )
getStartTime ( )
Operation getEndTime ( )
What is Polymorphism?
Derived from Greek word which means - Many
Form
The ability to hide many different
implementations behind a single interface.
Super class and sub-class relationship model
What is an Interface?
Interfaces formalize polymorphism
Interfaces support “plug-and-play” architectures
Tube
<<interface>>
Shape
Pyramid
Draw
Move
Scale
Rotate Cube

Realization relationship (stay tuned for realization relationships)


Interface Representations Tube

Pyramid
Elided/Iconic
Representation
Shape Cube

Tube
<<interface>>
Canonical
Shape
Pyramid
(Class/Stereotype) Draw
Representation Move
Scale
Rotate Cube

(stay tuned for realization relationships)


What is a Component?
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
OO Principle:
◦ An executable component
Encapsulation

Source File <<EXE>> <<DLL>>


Name Executable Component
Name Component Name
Interface
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 Name
Uses
◦ Organize the model under development
◦ A unit of configuration management
What is a Subsystem?
A combination of a package (can contain other model elements) and a
class (has behavior)
Realizes one or more interfaces which define its behavior

Realization
Subsystem
<<subsystem>>
Interface Subsystem Name
Interface

OO Principles: Encapsulation and Modularity


(stay tuned for realization relationship)
Subsystems and Components
Components are the physical realization of an abstraction in the design
Subsystems can be used to represent the component in the design

Design Model Implementation Model

<<subsystem>> Component
Component Name Name
Component Component
Interface Interface

OO Principles: Encapsulation and Modularity


Relationships
Association
◦ Aggregation
◦ Composition

Dependency
Generalization
Realization
Relationships: Association
Models a semantic connection among classes
Association Name

Professor Works for University

Association
Role Names

Class University
Professor
Employee Employer
Relationships: Aggregation
A special form of association that models a whole-part
relationship between an aggregate (the whole) and its parts

Whole Part

Student Schedule

Aggregation
Relationships: Composition
A form of aggregation with strong ownership and
coincident lifetimes Part
◦ The parts cannot survive the whole/aggregate
Whole

Student Schedule

Aggregation
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
Unspecified 1

Exactly one 0..*

Zero or more (many, unlimited) *

One or more 1..*

Zero or one 0..1

Specified range 2..4

Multiple, disjoint ranges 2, 4..6


Example: Multiplicity and
Navigation
Multiplicity

Student 1 0..* Schedule

Navigation
Relationships: Dependency
A relationship between two model elements where a
change in one may cause a change in the other

Client Supplier Component


Class

Package Client Supplier


Dependency
relationship

ClientPackage SupplierPackage
Dependency
relationship
Relationships: Generalization
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 super-classes
◦ Single inheritance
◦ Multiple inheritance
Generalization is an “is-a-kind of” relationship
Example: Single Inheritance
Ancestor
One class inherits from another
Account
balance
name
Superclass number
(parent) Withdraw()
CreateStatement()
Generalization
Relationship

Checking Savings

Subclasses Withdraw() GetInterest()


Withdraw()
Descendents
Example: Multiple Inheritance
A class can inherit from several other classes
FlyingThing Animal

multiple
inheritance

Airplane Helicopter Bird Wolf Horse

Use multiple inheritance only when needed, and


always with caution !
What Gets Inherited?
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
Example: What Gets Inherited
GroundVehicle
owner Person
Superclass weight
(parent) licenseNumber 0..* 1

register( )
generalization

Car Truck Trailer


Subclass size tonnage
getTax( )
Relationships: Realization
A realization from a source element (called the realization
element) to a target element (called the specification
element) indicates that the source element supports at
least all the operations of the target element without
necessarily having to support any attributes of the target
element.
Class Diagram for the Sales
Example
Sale

seller buyer item sold shipping mechanism


Salesperson Customer Product Vehicle

Corporate Individual Truck Train


Effect of Requirements Change
Sale

seller buyer item sold shipping mechanism


Salesperson Customer Product Vehicle

Corporate Individual Truck Train Airplane

Change involves adding a new subclass


Stereotypes
Classify and extend the UML notational elements
Define a new model element in terms of modeling
May be applied to all modeling elements
Represented with name in guillemets or as a different icon

<<boundary>>
MyBoundaryClass

MyBoundaryClass
Example: Stereotypes
<<boundary>>

<<boundary>>
Sample boundary class (stereotype)
<<trace>> Stereotype of ‘dependency relation’
DesignClass Stereotype of <<Processor>>

These create new symbols using


accustomed graphics.

<<Processor>>
Processor #1 Processor #1
Notes
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

There can be up to one


MaintainScheduleForm per
MaintainScheduleForm user session.
Tagged Values
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

PersistentClass
{persistence} anObject : ClassA
{location=server}
Constraints
Supports the addition of new rules or modification of existing rules

Member 1
Professor Department
1..*
Department Head {subset}
1 1
Object Modeling Technique (OMT)
Rumbaugh’s Object Modeling Technique (OMT)
-A method for analysis,design and implementation by
an object oriented technique.
-fast and intuitive approach for identifying and
modeling all objects that build-up a system.
-Class attributes, methods, inheritance and association can
be expressed easily.
-Dynamic behavior of objects can be described using
the OMT dynamic model.
-Detailed specification of state transitions and their
-descriptions within a system
Why modeling
Blue print
Clarity
Familiarity
Maintenance
Simplification
Four phases of OMT
(can be performed iteratively)
Analysis: objects,dynamic and functional models
System Design: Basic architecture of the system.
Object Design: static, dynamic and functional
models of objects.
Implementation: reusable, extendible and robust
code.
Three different parts of OMT modeling
An object model - object diagram & data dictionary
A dynamic model - state diagrams & event flow diagrams
A functional model - data flow & constraints
Object Model
structure of objects in a system.
Identity, relationships to other objects, attributes and operations.
Object diagram
Object Diagram
Classes interconnected by association lines
Classes- a set of individual objects
Association lines- relationship among classes (i.e., objects of one class
to objects of another class)
OMT Dynamic Model
States, transitions, events and actions
OMT state transition diagram-network of states and events
OMT Functional Model
DFD- (Data Flow Diagram)

Shows flow of data between different processes in


a business.
Simple and intuitive method for describing
business processes without focusing on the details
of computer systems.

You might also like