Chapter 2: Object Model

Prof. Hyoung-Joo Kim

(hjk@oopsla.snu.ac.kr)

OOPSLA Lab.Dept. of Computer Engineering

Seoul National Univ.

SNU OOPSLA Lab. 2

Contents

• 2.1 Introduction

• 2.2 Types: Specifications and Implementations

• 2.3 Objects

• 2.4 The Characteristics of a Type

• 2.5 Metadata

• 2.6 Locking and Concurrency Control

• 2.7 Transaction Model

• 2.8 Database Operations

SNU OOPSLA Lab. 3

2.1 Introduction

• The Object Model specifies the constructs that are supported by an ODBMS and used to construct the application’s object model

Object

Literal

Id

attributes

rela

tions

hips

oper

atio

ns

rela

tions

hips

attr

ibut

es

operations

Database

Set of types(= Schema)

Instances of type+

SNU OOPSLA Lab. 4

2.2 Types: Specifications and Implementations(1)

Type: Specification + Implementation(s)

Interface Class Literal

Abstract state(properties)

Abstract behavior(operations)

Representation + methods

Data structureof abstract state

Procedure bodiesof abstract behavior

class Employee { attribute string name; attribute unsigned salary; relationship Manager boss inverse Manage::subordinates; int totalsalary(in unsigned rate);};

class Employee { char name[SIZE]; unsigned salary; Manager mgr;

int totalsalary(unsigned rate) { return salary*(1+rate);} };

C++ binding

SNU OOPSLA Lab. 5

2.2 Types: Specifications and Implementations(2)

• A type has two aspects to its definition:– Specification

• External aspects such as properties, operations, and exceptions

• A type has only one specification

• 3 specification definitions:– interface defines only the abstract behavior of a object type

– class defines the abstract state and behavior of a object type

– literal defines only abstract state of a literal type

• Examplesinterface Employee {...};class Person {...};struct Complex {float re; float im;};

SNU OOPSLA Lab. 6

2.2 Types: Specifications and Implementations(3)

– Implementation of a object type• Internal aspects such as procedure bodies

• Implementation of the type’s operations and other internal details

• A type has one or more implementation

• Components:– representation: a data structure derived from the type’s abstract state by

a language binding

– methods: procedure bodies derived from the type’s abstract behavior by the language binding

– Implementation of a literal type• Each language binding defines an implementation mapping for literal

types

• e.g.) struct (of Complex in ODL) structure definition in C++

SNU OOPSLA Lab. 7

• Separation between specification and implementation– Is the way that the Object Model

reflects encapsulation

– Is for multilingual access to

objects of a single type and sharing

of objects accross heterogeneous

computing environments

2.2 Types: Specifications and Implementations(4)

Implementationby C++ binding

Implementationby Java binding

Implementationby Smalltalk binding

Specificationsof types

SNU OOPSLA Lab. 8

2.2 Types: Specifications and Implementations(5)

• Subtyping and inheritance of behavior– ISA relationship or generalization-specialization relationship

– The supertype is the more general type; the subtype is the more specialized

– Objects of subtype can be used wherever those of supertype can

– Polymorphic nature of object behavior: run-time invocation dependent on the actual of the instance

– Multiple inheritance of object behavior is possible• Name conflict by name overloading happens!

• The ODMG Object Model disallows name overloading

SNU OOPSLA Lab. 9

Employee

Professor

Associate-Professor

Type/subtype relationship

supertype/subtype

interface Employee {...};interface Professor: Employee {...};interface Associate_Professor: Professor {...};

2.2 Types: Specifications and Implementations(6)

• Example

SNU OOPSLA Lab. 10

2.2 Types: Specifications and Implementations(7)

• Instantiation and inheritance– Class type is instantiable by the programmer, but interface type ca

nnot

– Inheritance between types are limited since subtyping pertains to the inheritance of behavior only and due to the inefficiencies and ambiguities of multiple inheritance of state

interfaces

interface

interfaces

class

classes

class

classes

interface

SNU OOPSLA Lab. 11

2.2 Types: Specifications and Implementations(8)

• Inheritance of states– EXTENDS relationship is:

• For the inheritance of state (cf. ISA relationship)

• Applicable only to object types

• A single inheritance relationship between two classes

• Transitive

SNU OOPSLA Lab. 12

2.2 Types: Specifications and Implementations(9)

• Example

class Person { attribute string name; attribute Date birthdate;};

class ManagerPerson extends EmployPerson: Manager { relationship set<Employee> subordinates inverse Employee::boss;};

class EmplyeePerson extends Person: Employee { attribute Date hiredate; attribute Currency payrate; relationship Manager boss inverse Manager::subordinates;};

EXTEDS relationship

ISA relationship

SNU OOPSLA Lab. 13

2.2 Types: Specifications and Implementations(10)

• Extents– The extents of a type is the set of all instances of the type within a

particular database

– ISA relationship also applies to the extent

– Extent maintenance(i.e. insert and delete an instance) can be automatically done by the ODBMS

– An extent can be indexed for access speedup

• Keys– In some case(i.e. index an extent) the instances of a type can be uni

quely identified by the values of properties which are called keys (cf. candidate keys in relational model)

SNU OOPSLA Lab. 14

2.3 Objects

• Aspects of objects:– Creation

– Identifiers

– Names

– Lifetimes

– Structure

SNU OOPSLA Lab. 15

2.3 Objects(1): Creation

• Object creation is made by invoking creation operations on factory interfaces:

• All objects have the ODL interface, implicitly inherited by the definitions of all user-defined objects– Locking operations: lock(), try_lock()

– Identity comparison: same_as()

– Copy operation: copy()

– Delete operation: delete()

Interface ObjectFactory { Object New();};

SNU OOPSLA Lab. 16

2.3 Objects(2): Identifiers

• Object identifiers in database are unique and never change• The notion of object identifier differs from that of primary ke

y in the relational model– The value column(s) comprise the primary key in relational table, s

o the identity also changes if the values do

• Object is mutable (cf. literal is immutable)• Object identifier is generated by the ODBMS, not by applicati

on

SNU OOPSLA Lab. 17

2.3 Objects(3): Names

• The application can refer at its convenience to an object by name using mapping function

• The scope of uniqueness of names is a database

object namemapping function

unmapping function

e.g., in SOP OODBMS mapname(const RefAny& obj, const char* name) unmapname(const RefAny& obj)

1:1

SNU OOPSLA Lab. 18

2.3 Objects(4): Lifetimes

• Two lifetimes:– Transient objects

• Managed by the programming language run-time system

• Non-exist in persistent storage after the process terminates

– Persistent objects• Managed by the ODBMS run-time system

• Exist persistently in storage

• Object lifetimes are independent of types– Persistent & transient objects are manipulated by the same

operations(e.g., OOPL)

– In relation model, persistent data and transient data are manipulated respectively by SQL and PL

SNU OOPSLA Lab. 19

2.3 Objects(5): Structure

• Classification of object types– Atomic objects

• User-defined

• There is no built-in atomic object type in the ODMG Object Model

– Collection objects• Set<t>, Bag<t>, List<t>, Array<t>, Dictionary<t>

• Element type of collection can be atomic, another collection, or literal

• All elements must be of the same type

– Structured objects• Date, Interval, Time, Timestamp

SNU OOPSLA Lab. 20

2.3 Literals(1)

• Literals do not have object identifiers(vs. objects)• Four literal types:

– atomic literal

– collection literal

– structured literal

– null literal

SNU OOPSLA Lab. 21

2.3 Literals(2)

• Atomic literals– Programming language binding supports an analog of atomic litera

l types(e.g., long, float, boolean, char, enum, etc.)

• Collection literals– set<t>, bag<t>, list<t>, array<t>, dictionary<t>

• Structured literals– date, interval, time, timestamp

– User-defined structures can be defined as need using a built-in type generator struct

• Null literals

SNU OOPSLA Lab. 22

2.4 The Characteristics of a Type

Type

AttributesRelationship Operations

Modeling state Modeling behavior

How can we model state and behavior of a type?

SNU OOPSLA Lab. 23

2.4.1 Modeling State - Properties(1)

• A type defines a set of properties through which the state of instances of the type is accessible and manipulated

• Two kinds of properties:– attribute

– relationship: defined between two types whose instance must be referenceable by object identifiers

SNU OOPSLA Lab. 24

2.4.1 Modeling State - Properties(2): Attributes

• An attribute: the abstract state of a type– An attribute’s value is either a literal or an object identifier

– An attribute is not the same as a data structure, which is a physical representation

interface Person { attribute short age; attribute string name; attribute enum gender{male, female}; attribute Department dept;};

SNU OOPSLA Lab. 25

interface Professor { ... Relationship set<Course> teaches inverse Course::is_taught_by;};

interface Course { ... Relationship Professor is_taught_by inverse Professor::teaches;};

Travel paths

tp_1

Prof

tp_4

tp_3

tp_2

tp_1 Course1

Course2

Course3

Course4

set<Course>

2.4.1 Modeling State - Properties(3):Relationships

• The ODMG Object Model supports only binary relationships, i.e., relationships between two types

e.g., one-to-one, one-to-many, many-to-many

SNU OOPSLA Lab. 26

2.4.1 Modeling State - Properties(3):Relationships(con’t)

• The referential integrity of relationships• relationships vs. pointers• The implementation of relationships

e.g., cadinality “many” relationships

relationship set<Course> teaches inverse Professor::is_taught_by;

attribute set<Course> teaches;void form_teaches(in Course aCourse) raise(IntegrityErrror);void drop_teaches(in Course aCourse);void add_teaches(in Course aCourse) raise(IntegrityErrror);void remove_teaches(in Course aCourse);

SNU OOPSLA Lab. 27

2.4.2 Modeling Behavior - Operations(1)

• Behavior is specified as a set of operation signatures, each of which defines:– The name of an operations

– The name and type of each of arguments

– The types of value(s) returned

– The names of any exceptions(error conditions)

• Object Model specification for operations is identical to that of the OMG CORBA

SNU OOPSLA Lab. 28

2.4.2 Modeling Behavior - Operations(2)

• Characteristics of the operation– An operation is defined on only a single type

– An operation name need be unique only within a single type definition(not between types)

– Operation names can be overloaded• Operation selection problem happens

-> operation name resolution or operation dispatching

• Operation selection is based on the first argument, i.e., the most specific type of the object -> single-dispatch model

• The major reasons for single-dispatch model was:– Consistency with the C++ and Smalltalk programming languages

– To avoid incompatibilities with the OMG CORBA object model

SNU OOPSLA Lab. 29

2.5 Metadata(1)

• Metadata is– Descriptive information about database objects that defines the sch

ema of a database

– used by the ODBMS to define the structure of the database and at runtime to guide its access to the database

– Stored in an ODL Schema Repository

Instances of Person, Student,Professor type

Instances oftype Type(Person, Student,Professor type)

Person

Student

Professor

ModelingModeling

SNU OOPSLA Lab. 30

2.5 Metadata(2)

• e.g., Scope, MetaObject, Interface, Class, etc.

interface Class: Interface {

attribute list<string> extents; attribute list<string> keys; relationship Class extender inverse Class::extensions; relationship set<Class> extensions inverse Class::extender;

};

SNU OOPSLA Lab. 31

2.6 Locking and Concurrency Control

• Concurrency control in the ODMG Object Model– Lock-based and pessimistic concurrency control

– Lock type: read/write/upgrade lock

– Implicit/explicit locking: whether no specific operations need to obtain a specific lock

– Lock duration: two-phase locking algorithm

SNU OOPSLA Lab. 32

2.7 Transaction Model

• Transaction management in the ODMG– Any access, creation, modification, and deletion of persistent objects

must be done within a transaction

– A unit of logic which guarantees atomicity, consistency, isolation, durability

– Transaction operations: TransactionFactory/Transaction type

interface Transaction { void begin() raises(TransactionInProgress); void commit() raises(TransactionNotInProgress); void abort() raises(TransactionNotInProgress); void checkpoint() raises(TransactionNotInProgress); void join(); void leave(); void isOpen();};

SNU OOPSLA Lab. 33

2.8 Database Operations

• Database creation and manipulation– DatabaseFactory/Database type

interface Database {

void open(in string database_name); void close(); void bind(in any obj, in string name); Object unbind(in string name); Object lookup(in string obj_name); Module schema();

};

interface DatabaseFactory {

Database new(); };