chapter 2: object model prof. hyoung-joo kim ([email protected]) oopsla lab. dept. of computer...
TRANSCRIPT
Chapter 2: Object Model
Prof. Hyoung-Joo Kim
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(); };