basic dbms

8/13/2019 basic dbms

1/42

CS540 Software Design 2Lecture 13

Object-Oriented Programming

Objects can be used effectively to represent real-world entities

For instance, an object might represent aparticular employee in a company

Each employee object handles the processingand data management related to that employee


2/42

3

Objects

An object has:

state - descriptive characteristics

behaviors - what it can do (or what can be done to it)

The state of a bank account includes its account number and itscurrent balance

The behaviors associated with a bank account include the ability

to make deposits and withdrawals

Note that the behavior of an object might change its state


3/42


Classes An object is defined by a class

A class is the blueprint of an object

Multiple objects can be created from the same class


4/42


Objects and Classes

Bank

Account

A classthe concept)

Johns Bank Account

Balance: $5,257

An objectthe realization)

Bills Bank AccountBalance: $1,245,069

Marys Bank AccountBalance: $16,833

Multiple objectsfrom the same class


5/42


Attributes

Contain current state of an object.

Attributes can be classified as simple or complex.

Simple attribute can be a primitive type such as integer,

string, etc., which takes on literal values. Complex attribute can contain collections and/or

references.

Reference attribute represents relationship.

complex object:contains one or more complexattributes


6/42


Methods and messages

Method: Defines behavior of an object, as a set of encapsulated functions

Message: Request from one object to another asking second object toexecute one of its methods.

(a)

(b)

(a) Object showing attributes and methods(b) Example of a method


7/42CS540 Software Design 8Lecture 13

Classes

Class: Blueprint for defining a set of similar objects.

Objects in a class are called instances.


8/42


Inheritance One class can be used to derive another via inheritance

Classes can be organized into hierarchies

BankAccount

Account

ChargeAccount

SavingsAccount

CheckingAccount


9/42


Inheritance (contd)

Inheritance allows one class of objects to be defined as a special case of a more generalclass.

Special cases are subclassesand more general cases are superclasses.

Generalization: process of forming a superclass

Specialization: forming a subclass

Subclass inherits all properties of its superclass andcan define its own uniqueproperties.

Subclass can redefine inherited methods.

All instances of subclass are instances of superclass.Principle of substitutability: instance of subclass can be used whenever method/constructexpects instance of superclass.

A KIND OF (AKO): Name for relationship between subclass and superclass


10/42


Types of inheritance

(a)

(b)

(c)

(a) Single(b) Multiple(c) Repeated

(b)


11/42


Inheritance (contd) Define humanBeingto be a class

A humanBeinghas attributes, such as age, height,gender

Assign values to attributes when describing object

Define Parent to be a subclassof HumanBeing

A Parent has all attributes of a HumanBeing, plusattributes of his/her own (name of oldest child,number of children)

AParentinherits all attributes of humanBeing The property of inheritance is an essential feature of

object-oriented languages such as Smalltalk, C++, Ada95, Java (but not C, FORTRAN)


12/42


Inheritance (contd)

UML notation

Inheritance is represented by a large open triangle


13/42


Java implementation


14/42


Overriding and OverloadingOverriding: Process of redefining a property within a subclass.

Overloading:Allows name of a method to be reused with a class or acrossclasses.

Overriding Example:

Might define method in Staff class to increment salary based on commissionmethod void giveCommission(float branchProfit) {

salary = salary + 0.02 * branchProfit; }

May wish to perform different calculation for commission in Manager subclass:

method void giveCommission(float branchProfit) {

salary = salary + 0.05 * branchProfit; }


15/42


Aggregation

UML Notation


16/42


Association

UML Notation


17/42


Equivalence of Data and Action

Classical paradigm record_1.field_2

Object-oriented paradigm thisObject.attributeB

thisObject.methodC()


18/42


ExampleChapter 7 Schach (2002)

Design of an operating system for a large mainframecomputer. It has been decided that batch jobs submittedto the computer will be classified as high priority,medium priority, or low priority. There must be three

queues for incoming batch jobs, one for each job type.When a job is submitted by a user, the job is added tothe appropriate queue, and when the operating systemdecides that a job is ready to be run, it is removed from

its queue and memory is allocated to it Design 1 (Next slide)

Low cohesionoperations on job queues are spread all overproduct


19/42


Data EncapsulationDesign 1


20/42


Data EncapsulationDesign 2


21/42


Data Encapsulation

m_encapsulationhas informational cohesion

m_encapsulation is an implementation of dataencapsulation

Data structure (job_queue) together with operationsperformed on that data structure

Advantages

Development

Maintenance


22/42


Data Encapsulation and

Development Data encapsulation is an example of abstraction Job queue example

Data structure job_queue

Three new functions initialize_job_queue add_job_to_queue delete_job_from_queue

Abstraction Conceptualize problem at higher level

job queues and operations on job queues

not lower level records or arrays


23/42


Stepwise Refinement

Step 1: Design in terms of high level conceptsIt is irrelevant how job queues are implemented

Step 2: Design low level components

Totally ignore what use will be made of them

In 1st step, assume existence of lower level Concern is the behavior of the data structure

job_queue

In 2nd step, ignore existence of high level

Concern is the implementation of that behavior

In a larger product, there will be many levels of abstraction


24/42



Maintenance

Identify aspects of product likely to change

Design product so as to minimize the effectsof change

Data structures are unlikely to change

Implementation may change

Data encapsulation provides a way to copewith change

I l i f Cl J bQ


25/42


Implementation of ClassJobQueue

C++


26/42


Implementation of queueHandler

C++ Java


27/42



Maintenance (contd)

What happens if queue is now implemented as a two-way linkedlist ofJobRecord?

Module that usesJobRecordneed not be changed at all,merely recompiled

C++

Java


28/42


Abstract Data Types

Problem with both implementations

Only one queue

Need

We need:

Data type+ operations performed on instantiationsof that data type

Abstract data type

T d


29/42


Abstract Data Type (contd)

(Problems caused bypublicattributes solved later)


30/42


Information Hiding

Data abstraction

Designer thinks at level of an ADT

Procedural abstraction

Define a procedureextend the language

Instances of a more general design concept, information hiding

Design the modules in way that items likely to change arehidden

Future change is localized

Changes cannot affect other modules

I f ti Hidi ( td)


31/42


Information Hiding (contd)

C++ abstract

data typeimplementationwith information

hiding


32/42


Information Hiding (contd)

Effect of information hiding viaprivateattributes


33/42


Polymorphism and Dynamic

Binding

Classical paradigm Must explicitly invoke correct version

Polymorphism and Dynamic Binding


34/42


Polymorphism and Dynamic Binding(contd)

Object-oriented paradigm


35/42



Binding (contd)All that is needed is myFile.open()

Correct method invoked at run-time (dynamically)

Method opencan be applied to objects ofdifferent classes

Polymorphic


36/42


Polymorphism and dynamic binding

(contd)

MethodcheckOrder (b : Base)can be applied to objects of any subclass

ofBase


37/42



Binding (contd)

Can have a negative impact on maintenance Code is hard to understand if there are multiple

possibilities for a specific method

Polymorphism and dynamic binding Strength and weakness of the object-oriented paradigm



38/42



(contd)

Polymorphism: Means many forms.

Dynamic Binding:Runtime process of selecting appropriate method based onan objects type.

Example:With list consisting of an arbitrary no. of objects from the Staff hierarchy,we can write: list[i]. print

and runtime system will determine which print() method to invoke depending onthe objects (sub)type.


39/42


Cohesion and Coupling of Objects

No such thing! Object-oriented cohesion and coupling always reduces to

classical cohesion

The only feature unique to the object-oriented paradigm is

inheritance Cohesion has nothing to do with inheritance

Two objects with the same functionality have the samecohesion

It does not matter if this functionality is inherited or not Similarly, so-called object-oriented coupling always reduces to

classical coupling


40/42


Object-Oriented Metrics (contd)

Two types of so-called object-oriented metric Not related to inheritance

Reduces to a classical metric

Inheritance-related May reduce to a classical metric

No problem Classical metrics work just fine

But dont mislead others by calling them object-oriented


41/42


Advantages of Objects

Same as as advantages of abstract data types

Information hiding

Data abstraction

Procedural abstraction

Inheritance provides further data abstraction

Easier and less error-prone productdevelopment

Easier maintenance

Objects are more reusable than modules withfunctional cohesion


42/42

Summary

basic dbms

Documents

Transcript of basic dbms