chapter 11 - 1 object-module design classic object-orientation –group data and applicable...
Post on 21-Dec-2015
219 views
TRANSCRIPT
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
GuestNrExchangeAmount
Currency Exchange Rate
Cost
Last RateChange Date
Length AtCurrent Rate
RoomNr
• Table Implementation• Virtual Implementation• Interaction Implementation• No Implementation
Chapter 11 - 7
Table Implementation
Room
DepartureDate
TotalCost
NrDaysArrivalDate
Guest
GuestNrExchangeAmount
Currency Exchange Rate
Cost
Last RateChange Date
Length AtCurrent Rate
RoomNr Room
DepartureDate
TotalCost
NrDaysArrivalDate
Guest
GuestNrExchangeAmount
Currency Exchange Rate
Cost
Last RateChange Date
Length AtCurrent Rate
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
GuestNrExchangeAmount
Currency Exchange Rate
Cost
Last RateChange Date
Length AtCurrent Rate
RoomNr Room
DepartureDate
TotalCost
NrDaysArrivalDate
Guest
GuestNrExchangeAmount
Currency Exchange Rate
Cost
Last RateChange Date
Length AtCurrent Rate
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
Last RateChange Date
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
Last RateChange Date
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
Last RateChange Date
Cost
GuestRoom
NrDaysArrivalDate
GuestNr
RoomNr
Last RateChange Date
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
@ 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
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
@ update exchange rate
@ get exchange amount
compute exchange amount
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
@ update exchange rate
@ get exchange amount
compute exchange amount
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
cancel reservation
@ inquire about room availability
return information on room availability
Reservation Clerk
Exists
@ inquire about room availability
return information on room availability
@ cancel reservation
cancel reservation
Reservation Clerk
@ cancel reservation
cancel reservation
@ inquire about room availability
return information on room availability
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;