Chapter 11 - 1 Object-Module Design Classic object-orientation –Group data and applicable operations together. –Encapsulate identity, data, and behavior

Chapter 11 - 1

Object-Module Design

• Classic object-orientation– Group data and applicable operations together.– Encapsulate identity, data, and behavior details under an

interface of exported services.– Establish inheritance hierarchies among encapsulated units.

• Classic database-system services– Decide how to manage concurrency.– Add transaction processing.– Specify views and their update and authorization characteristics.

Chapter 11 - 2

Object Module ~ Generalized ADT

• N is the name• D is a data description

– intent (set of possible elements)– extent (set of current instances)– constraints

• B is a behavior description– events and conditions to which the behavior responds– states or circumstances under which the response happens– a description of the responses– services = the responses associated with events and conditions

• uniform service availability• nonuniform service availability

An object module is a named pair N = (D, B).

Chapter 11 - 3

Object Modules – Examples

• A single object set (lexical or nonlexical)• A “built-in” object set (e.g., Integer)• A passive high-level object set with included lexical

object sets (a typical database record, flat or nested)• An object set with a given state net• An object set that includes both passive object and

relationship sets and a state net.

Chapter 11 - 4

Special Types of Object Modules• Class (typical)

– an implicit intent and (possibly) an explicit extent– uniformly available two-way interactions

• Type– intent (extent implicit and same as intent)– uniformly available two-way interactions (operations)

• Variable– extent with at most one value– query, add, remove, and modify– usually declared as a specialization of a type

• Value– extent with one value– query

Chapter 11 - 5

Encapsulation

• Object Integrity– immutable identity (be careful with lexicalized objects)– obeys its behavior specification (e.g., no arbitrary state change)

• Interface Specification– implicit or explicit declaration of services– tradeoffs for query processing

• Implementation Independence– separates specification from implementation– view one way, but implement in another (more efficient) way– overriding and late binding for polymorphic variations

We should observe these principles even if not language supported.

Chapter 11 - 6

ORM Computations

Room

DepartureDate

TotalCost

NrDaysArrivalDate

Guest

GuestNrExchangeAmount

Currency Exchange Rate

Cost

Last RateChange Date

Length AtCurrent Rate

RoomNr Room

DepartureDate

TotalCost

NrDaysArrivalDate

Guest



Cost



RoomNr

• Table Implementation• Virtual Implementation• Interaction Implementation• No Implementation

Chapter 11 - 7

Table Implementation

Room

DepartureDate

TotalCost

NrDaysArrivalDate

Guest



Cost



RoomNr Room

DepartureDate

TotalCost

NrDaysArrivalDate

Guest



Cost



RoomNr

• Advantage: faithful to the ORM diagram.• Disadvantage: must store computable information.• Note: for some applications, the computation might be

expensive, needed often including inverse computations, and the data may be relatively static.

Chapter 11 - 8

Virtual Implementation

Room

DepartureDate

TotalCost

NrDaysArrivalDate

Guest



Cost



RoomNr Room

DepartureDate

TotalCost

NrDaysArrivalDate

Guest



Cost



RoomNr

• Advantage: faithful without storing computable data

• Disadvantage: must also provide all inverse computations.

• Scheme generation: data not stored cannot be redundant.– Room(Room, RoomNr, Cost, Last Rate Change Date, Length At Current

Rate)– Currency Exchange(Currency, Cost, Exchange Rate, Exchange Amount)

Chapter 11 - 9

Interaction Implementation

Guest


Cost

Room

NrDaysArrivalDate

GuestNr

RoomNr

get Total Cost (GuestNr) -> (Total)

get Amount(Exchange Rate) -> (Exchange Amount)

get Length(Date) -> (Length At Current Rate)

get Departure Date -> (Date)

Guest


Cost

Room

NrDaysArrivalDate

GuestNr

RoomNr

get Total Cost (GuestNr) -> (Total)

get Amount(Exchange Rate) -> (Exchange Amount)

get Length(Date) -> (Length At Current Rate)

get Departure Date -> (Date)

• Advantage: need not store computable data.• Disadvantage: not faithful to the ORM diagram.• Note:

– These interactions become methods.

– Often, the inverse transformations are never needed.

Chapter 11 - 10

No Implementation


Cost

GuestRoom

NrDaysArrivalDate

GuestNr

RoomNr


Cost

GuestRoom

NrDaysArrivalDate

GuestNr

RoomNr

• Advantage: no service to provide.• Disadvantage: the client process must do any needed computation.

– The client process can retrieve needed information and execute the computation.

– If no client needs the service, everyone wins.

Chapter 11 - 11

Simple Enumeration

Room Name

Room Room Name: {"Kennedy", "Nixon", "Carter", "Blue", "Green"}

Room

"Kennedy" "Nixon" "Carter" "Green"

1has

1

1has

1

"Blue"

Room Name

Room Room Name: {"Kennedy", "Nixon", "Carter", "Blue", "Green"}

Room

"Kennedy" "Nixon" "Carter" "Green"

1has

1

1has

1

"Blue"

Chapter 11 - 12

Partitioned Category Specialization

Room Category: {"Single", "Double", "Suite"}

Room

Single SuiteDouble

1has

0:* Room Category: {"Single", "Double", "Suite"}

Room

Single SuiteDouble

1has

0:*

Chapter 11 - 13

Unconstrained Category Specialization

Guest Category: {"Past", "Current", "Future"}

Guest

Past FutureCurrent

has0:*0:*

Guest Category: {"Past", "Current", "Future"}

Guest

Past FutureCurrent

has0:*0:*

Chapter 11 - 14

Generated Value-Set Types

{"TV", "Hot Tub", "Bar", "Ice Box"}Facility

Type

Regular: {"Single", "Double"}

Suite: {"Honeymoon", "Business"}

View: {"Sea", "Forest"}Description

Room

1

has

1:*

1

1:*1

1:*

1

1:*

seq

seq of

multiset of

0:*0:*{"TV", "Hot Tub", "Bar", "Ice Box"}Facility

Type

Regular: {"Single", "Double"}

Suite: {"Honeymoon", "Business"}

View: {"Sea", "Forest"}Description

Room

1

has

1:*

1

1:*1

1:*

1

1:*

seq

seq of

multiset of

0:*0:*

Description ::= Type View FacilityType ::= Regular | SuiteRegular ::= “Single” | “Double”Suite ::= “Honeymoon” | “Business”View ::= “Sea” | “Forest”Facility ::= (“TV” | “Hot Tub” | “Bar” | “Ice Box”)*

Note: We allow duplicates in facilities to illustrate the correspondence to regular expressions.

Chapter 11 - 15

Data Structures

Exchange-Rate Table

Currency Exchange Rate1

has

1:*

create

destroy

retrieve (Currency) -> (Exchange Rate)

store (Currency, Exchange Rate)

Array [Currency] of Exchange Rate

Exchange-Rate Table

Currency Exchange Rate1

has

1:*

create

destroy

retrieve (Currency) -> (Exchange Rate)

store (Currency, Exchange Rate)

Array [Currency] of Exchange Rate

Chapter 11 - 16

Concurrency in OSM

• Ontological point of view– Objects naturally behave independently and thus concurrently

(inter-object concurrency).– Objects may perform multiple tasks simultaneously (intra-object

concurrency).

• Managing concurrency (highly complex)– Fortunately, databases provide transaction processing.– Distributed database systems manage transaction processing in

a multiprocessing environment.

• State-net patterns can lead to efficient implementations

Chapter 11 - 17

ADT State Net

• Set of objects (represented by an ORM diagram)• Set of uniformly available services

– single transitions, with event triggers

– no states (zero-state state net)

• At most one thread of control.

Object Manager

Trigger

Action

Trigger

Action

Object

0:1

...

operation 1

operation n

Object Manager

Trigger

Action

Trigger

Action

Object

0:1

...

operation 1

operation n

Chapter 11 - 18

ADT State-Net Example

Reservation Clerk

Room

NrDaysArrivalDate

Guest

Address

Name

GuestNrRoomNr

0:1

0:*

Guest hasreservationfor Room onArrivalDatefor NrDays

0:*

1has

1

1has

1

1

has

1:*

1

has 1:*1:* 1:*

@ make reservation(n: Name, a: Address, d: ArrivalDate, y: NrDays, r: RoomNr)

record Guest information and the reservation

@ cancel reservation(g: GuestNr, r: RoomNr, a: ArrivalDate)

remove reservation and Guest

Reservation Clerk

Room

NrDaysArrivalDate

Guest

Address

Name

GuestNrRoomNr

0:1

0:*

Guest hasreservationfor Room onArrivalDatefor NrDays

0:*

1has

1

1has

1

1

has

1:*

1

has 1:*1:* 1:*

@ make reservation(n: Name, a: Address, d: ArrivalDate, y: NrDays, r: RoomNr)

record Guest information and the reservation

@ cancel reservation(g: GuestNr, r: RoomNr, a: ArrivalDate)

remove reservation and Guest

Chapter 11 - 19

Patterns Easily Transformed to an ADT State Net (Zero-State State Net)

StateTrigger

ActionState

Trigger

Action

interaction

. . . StateTrigger

ActionState

Trigger

Action

interaction

. . .

• An interaction initiates the pattern.• There is a single thread of control.• A transition terminates the pattern (and the thread of control).

Chapter 11 - 20

Single-State State Net(Transformable to ADT State Net)

Assume: We need to process only one request at a time.

Currency

@ update exchange rate

Exists

@ get exchange amount

compute exchange amount

Exchange Rate

Name1

has

1

1

has

1:*

add(Name, Rate)

get exchange amount(Amount) -> (ExAmount)

update exchange rate(Rate)

remove(Name)

TO: Currency x

TO: Currency x

Currency


Exists



Exchange Rate

Name1

has

1

1

has

1:*

add(Name, Rate)

get exchange amount(Amount) -> (ExAmount)

update exchange rate(Rate)

remove(Name)

TO: Currency x

TO: Currency x

Chapter 11 - 21

Single-State State NetTransformed to ADT State Net

Currency Clerk

@ remove

remove currency

@ add

add new currency with its exchange rate

Name (of Currency) Exchange Rate




get exchange amount(Name, Amount) -> (ExAmount)

update exchange rate(Name, Rate)

0:1

1 has1:*

add (Name, Rate)

remove(Name)

Currency Clerk

@ remove

remove currency

@ add

add new currency with its exchange rate

Name (of Currency) Exchange Rate




get exchange amount(Name, Amount) -> (ExAmount)

update exchange rate(Name, Rate)

0:1

1 has1:*

add (Name, Rate)

remove(Name)

Chapter 11 - 22

Patterns Easily Transformed to a Single-State State Net

Exists

Trigger

Action

Trigger

ActionStateState

interaction

. . .

Exists

Trigger

Action

Trigger

ActionStateState

interaction

. . .

• An interaction initiates the pattern based on an object being in an initial state (e.g., Exists).

• There is a single thread of control.• The thread of control starts and ends with the same state (e.g.,

Exists).

Chapter 11 - 23

Nonuniform Service Availability(Transformable to Single-State Sate Net)

Reservation Clerk

@ new reservation

request filled-in form

@ form filled

make reservation

Ready

Waitingfor Form

form filled

new reservation

Reservation Clerk

@ new reservation

request filled-in form

@ form filled

make reservation

Ready

Waitingfor Form

form filled

new reservation

Chapter 11 - 24

Nonuniform Service AvailabilityTransformed to Single-State Sate Net

As before, if we need to process only one request at a time,we can translate this to an ADT state net (zero-state state net).

Reservation Clerk

Exists

State: {Ready, Waiting for Form}

@ form filled(rc: Reservation Clerk) and exists Reservation Clerk(self) is in State(Waiting for Form)

remove Reservation Clerk(rc) is in State(Waiting for Form);make reservation;add Reservation Clerk(self) is in State(Ready)

@ new reservation and exists Reservation Clerk(self) is in State(Ready)

remove Reservation Clerk(self) is in State(Ready);request filled-in form(self);add Reservation Clerk(self) is in State(Waiting for Form);

@ add

add Reservation Clerk(self) is in State(Ready);

0:1

is in

0:*

Reservation Clerk

Exists

State: {Ready, Waiting for Form}

@ form filled(rc: Reservation Clerk) and exists Reservation Clerk(self) is in State(Waiting for Form)

remove Reservation Clerk(rc) is in State(Waiting for Form);make reservation;add Reservation Clerk(self) is in State(Ready)

@ new reservation and exists Reservation Clerk(self) is in State(Ready)

remove Reservation Clerk(self) is in State(Ready);request filled-in form(self);add Reservation Clerk(self) is in State(Waiting for Form);

@ add

add Reservation Clerk(self) is in State(Ready);

0:1

is in

0:*

Chapter 11 - 25

Queued Concurrent Requests• Suppose we have several concurrent requests for services.• Suppose also that we can buffer these requests in a queue and

service them sequentially.• Then, we can simulate some concurrent state-net patterns.

– Single-state state nets with multiple objects (inter-object concurrency)

– Single-state state nets with multiple threads (intra-object concurrency)

Reservation Clerk

Exists

@ inquire about room availability

return information on room availability

@ cancel reservation

cancel reservation

Reservation Clerk


cancel reservation



Reservation Clerk

Exists




cancel reservation

Reservation Clerk


cancel reservation



Chapter 11 - 26

Using Transaction Processing to Simulate Concurrency in State Nets

• Transactions preserve atomicity and integrity.• Services are often exactly the units we should protect in

transactions.• OSM-L provides start, commit, and abort.

@ cancel reservation (nr: GuestNr)

start;GuestNr(nr).Guest := { };commit;

@ cancel reservation (nr: GuestNr)

start;GuestNr(nr).Guest := { };commit;

Chapter 11 - 27

Intra-Object Concurrency with Nonuniform Service Availability

(Transformable to Single-State State Net)

. . .Object

S1

S2

S3

trigger 1

action 1

trigger 2

action 2

. . .

. . .

. . .Object

S1

S2

S3

trigger 1

action 1

trigger 2

action 2

. . .

. . .

Chapter 11 - 28

Intra-Object Concurrency with Nonuniform Service Availability

Transformed to Single-State State NetObject

Exists

Thread: Positive Integer

State: {S1, S2, S3}

trigger 2 and exists Thread() of Object(self) is in State(S2) and Thread() of Object(self) is in State(S3)

start;t: Thread;t := one of(Thread(x) where Thread(x) of Object(self) is in State(S2); remove Thread(t);t := one of(Thread(x) where Thread(x) of Object(self) is in State(S3); remove Thread(t);action 2;if not exists Thread() of Object(self) is in State(S1) then t := min(Positive Integer - Object(self).Thread); add Thread(t) of Object(self) is in State(S1); end;commit;

trigger 1 and exists Thread() of Object(self) is in State(S1)

start;action 1;t: Thread;t := min(Positive Integer - Thread); add Thread(t) of Object(self) is in State(S2);t := min(Positive Integer - Thread);add Thread(t) of Object(self) is in State(S3);commit;

0:*

Thread of Objectis in State

1:*

1

. . .

. . .

Object

Exists

Thread: Positive Integer

State: {S1, S2, S3}

trigger 2 and exists Thread() of Object(self) is in State(S2) and Thread() of Object(self) is in State(S3)

start;t: Thread;t := one of(Thread(x) where Thread(x) of Object(self) is in State(S2); remove Thread(t);t := one of(Thread(x) where Thread(x) of Object(self) is in State(S3); remove Thread(t);action 2;if not exists Thread() of Object(self) is in State(S1) then t := min(Positive Integer - Object(self).Thread); add Thread(t) of Object(self) is in State(S1); end;commit;

trigger 1 and exists Thread() of Object(self) is in State(S1)

start;action 1;t: Thread;t := min(Positive Integer - Thread); add Thread(t) of Object(self) is in State(S2);t := min(Positive Integer - Thread);add Thread(t) of Object(self) is in State(S3);commit;

0:*

Thread of Objectis in State

1:*

1

. . .

. . .

Chapter 11 - 29

Multiprocessing(Actual Concurrency)

• Multiple processors in a distributed processing system– highly complex– fine-tuning such a system (beyond scope)

• Maximizing concurrency– allows multiprocessing system to assign threads of control to

different processors– two ways to increase concurrency

• increase the number of objects (e.g., remove 0:1 participation constraints)

• increase the number of threads (e.g., spawn more threads of control or redesign state net with forks and joins)

– do not arbitrarily maximize concurrency; look for large benefits

Chapter 11 - 30

Visibility

• Public– services (interactions)

– implicit database operations (exposed ORM components)

• Read Only– implicit database operations

– only query operations

• Hidden– ORM, OBM, OIM components

– explicit and implicit operations not available

Public

Hidden

Read Only

Public

Hidden

Read Only

Chapter 11 - 31

Visibility Exampleobject module Reservation Clerk includes

@ new reservation; @ form filled; @ cancel reservation;

read only

Guest [1:*] has reservation for Room [0:*] on ArrivalDate [1:*] for NrDays [1:*];

hidden

Guest [1] has Name [1:*]; … @ new reservation then … ...

end;

Chapter 11 - 32

Object Module Views

• Different clients (of an object module) may have different visibility requirements.– A proprietor may wish to view all available data.– But guests should only be able to see their own information and

general information about which rooms are reserved.

• Views can accommodate multiple visibility requirements.• Views can provide:

– authorization– derived data

• Views have one or more base object modules.

Chapter 11 - 33

Authorization• An authorization clause in an object module lets us specify who

may use the view.• An authorization clause designates an object set that includes the

identity of clients authorized to use the view.– An object set in the application.

• Example: “Proprietor” limits the visible services and and data of the object module to proprietors.

• We can introduce an object set for this purpose.

– Variable specialization of an object set in the application.• Example: “x:Guest” limits the use of the object module to the subset of guests in

x—likely only one guest.

• In this case, the view itself may depend on x (e.g., we may have the constraint “GuestNr(y).Guest = x” where y is the guest number of the client currently using the view).

Chapter 11 - 34

Derived Data

• We derive the data for a view by a query (e.g., an OSM-QL query).

• Querying derived data presents no problem.• Updating derived data may present an inherently

unsolvable problem.

Chapter 11 - 35

The View-Update Problem

• Q is the query that defines view V based on database D.

• D is the updated database.• V is the updated view.• U is the update specification.• T is the translator for U, i.e.,

the actual update applied to D.

The problem is: there may be more than onetranslator T for a given update specification U.

D D

VV

Q Q

T

U

Chapter 11 - 36

View-Update Problem – Example

r = Guest Room s = Room View G1 R1 R1 Sea

R2 City

q = r s = Guest View G1 Sea

View Update: Guest(G1).View := City

Two Translations (ambiguous):Guest(G1).Room := R2Room(R1).View := City

BaseSchemes:

View:

Chapter 11 - 37

View-Update Resolution – Example(Designer Resolves Ambiguities)

object module view Guest View based on Guest Room, Room View includes

@ change view(Guest, View);

read only

Guest has View;

hidden

Guest(x) has View(y) :- Guest(x) has Room(z), Room(z) has View(y);

@ change view(g: Guest, v: View) then << find an unoccupied room with view v >> << if such a room r exists, then g.Room := r >>

end;

Chapter 11 - 38

Inheritance

• Incremental Specification• Possible increments:

– add data or behavior– subtract data or behavior– redefine behavior

• Conceptual-modeling (ontological) view of inheritance:– inherit only in ISA hierarchies– ISA should mean “is a”

• Consequence: this restricts possible increments to:– only add data or behavior (no subtraction)– no redefinition that changes the meaning (can only optimize

specifications, e.g., areas for polygons vs. for rectangles)

Chapter 11 - 39

Inheritance – Example

object module Guest includes

Guest [1] has Name [1:*]; Guest [1] has Address [1:*];

end;

object module Current Guest inherits from Guest includes

Current Guest [0:*] incurs additional Expense [1:*] for Service [1:*];

@ get total additional expense(Current Guest) -> (Amount);

end;

Documents

Chapter 11 - 1 Object-Module Design Classic object-orientation –Group data and applicable operations together. –Encapsulate identity, data, and behavior