chapter.4 version
DESCRIPTION
Chapter.4 Version. Seoul National University Department of Computer Engineering OOPSLA Lab. Table of Contents. Basic Concepts The Orion Model Proposed Models. Basic Concepts. Design object Version Derivation and History Workspace Configurations Revisions. Design Object. - PowerPoint PPT PresentationTRANSCRIPT
1
E.Bertino, L.MatinoObject-Oriented Database Systems
Chapter.4 Version
Seoul National University
Department of Computer Engineering
OOPSLA Lab.
2OOPSLA Lab
Table of Contents
Basic Concepts The Orion Model Proposed Models
3OOPSLA Lab
Basic Concepts
Design object Version Derivation and History Workspace Configurations Revisions
4OOPSLA Lab
Design Object
In database for design application Aggregation of design data as a coherent unit
usually a complex object consists of many component objects
• primitive
• complex object
Design database
5OOPSLA Lab
Version, Derivation, and History
Semantically, a snapshot of a design object In OODB engineering
different implementations of the same object revisions of an object
Derivation a version of a given object is derived from the previous
one by modification to the latter
History of version an outline of derivations starting with initial version
6OOPSLA Lab
History of Version
O[1]
O[0]
O[2] O[3]
Latest VersionCreated
(default version)
O[1.1] O[2.1] O[2.2]
O[1.1.1]Current Version
Alternatives
7OOPSLA Lab
Configuration
A link between a version of a complex object and a version of each of its component object
Static configuration Dynamic configuration
generic reference current version default version
8OOPSLA Lab
Example of Configuration
D[0]
D[1]
D[k]
L[0]
L[1]
L[j]
RT[0]
RT[1]
RT[i]
RPS[W]
RPS
Composed of
Derived from
StaticConfiguration
9OOPSLA Lab
Workspace
Workspace is named repository which constitutes work area that is shared by users access control unit
private workspace public workspace
read & append mode by check-in/check-out protocol
semi-public workspace an incomplete object combining the work of several
designers read & append mode by check-in/check-out protocol.
10OOPSLA Lab
Revision on Version
New version of an object can invalidate some of the objects which reference the given object notifying changes propagating changes
Problems in change propagation scope of change propagation in history path for change propagation in configuration
11OOPSLA Lab
RT[0]
RT[1]
RT[2]
RT[i]
D[0]
D[1]
D[2]
D[k]
L[0]
L[1]
L[2]
L[j]
RPS1[j]
RPS1
RPS[w]
RPS
Ambiguous Propagation of a Change
12OOPSLA Lab
Ways of Managing Ambiguities
Prevent any change propagation if there is a DAG Propagate the change to all the branches
the resulting version as alternatives of the root version
Propagate the change, interrupting it when ambiguity arises.
Provide operational mechanism whereby user can make their intention unambiguous
13OOPSLA Lab
Schema Version
Versions can be applied to classes and schema keep track of the objects created under each schema
version define rules both for updating and for deleting versions
of a class
Schema evolution in Chapter 5
14OOPSLA Lab
The ORION Model
Types of Version Transient Version Working Version Released Version
Generic Object Version Descriptor Notification of Changes Schema Versions
15OOPSLA Lab
Transient Version
In the private workspace Only the creator can update or delete it Can be created
from scratch by check-out a released version from a public database.
Can be derived from another transient version then the source is
promoted to a working version from a working version in a private database
16OOPSLA Lab
Working Version
In the private workspace Considered to be stable, thus can’t be updated
only deletion by the creator
Can be derived from transient version by implicit or explicit promoting the latter
17OOPSLA Lab
Released Version
In a public database Cannot be updated or deleted Can be created
by promoting the working version from the check-in of the working version
18OOPSLA Lab
CHECK-OUT
Promotes orCHECK-IN
PublicWorkspace
PrivateWorkspace
Createdfrom scratch
Promotes(implicit or explicit)
Release Version
Working Version
Transient Version
Types of Versions in ORION
19OOPSLA Lab
Generic Object
Distinction between versionable object and non-versionable object.
Generic (= versionable) object is an instance of a versionable class version-counter next-version-number default-version-number default-switch derivation-tree (a tree of version descriptors)
20OOPSLA Lab
An Example of Generic Object
OID O[0]
O[1]
O[2]
OID[0]
OID[1]
OID[2]
VersionInstances
Generic Object
default version
Generic Reference(Dynamic)
Specific Reference(Static)
A
B
21OOPSLA Lab
Version Descriptor
A version descriptor for each version instance Oi the version-number of Oi
the OID of Oi
a list of the references to version descriptors for all version instances which are derived directly from Oi
System attributes in each version instance version-number type-of-version OID of its generic object
22OOPSLA Lab
Messages for Creating Versionable Class and its Instances (define-class Classname :versionable TrueOrNil) Create message to a versionable class, then
creates a generic object and the first version instance Oi
Oi is a transient version and becomes the root of the derivation hierarchy for the generic object
(derive-version VersionedObject) if VersionedObject is a transient version
• promotes it to a working version
• makes a copy of it which becomes a new transient version
if VersionedObject is a generic object• the message is redirected to the default version.
23OOPSLA Lab
Messages Related to Version (1)
( promote VersionedObject ) promote a transient version to a working version no action on a working version
( demote VersionedObject ) demote a working version to a transient version no action on a transient version and a working version from
which other versions have been derived
( change-default-version VersionedObject [NewdefaultVersionNumber] ) by default, version number of the most recent version
24OOPSLA Lab
Messages Related to Version (2)
( delete-object [GenericObject | VersionInstance]) in case of a generic object, the whole derivation
hierarchy is removed in case that the version instance is the only instance of
the generic object, the latter is also removed. in case of a working version from which other versions
have been derived, the descriptor of it is not removed message parent-version message child-version message generic-object message default-version
25OOPSLA Lab
Version and Query
Version-number can be used in predicate Queries related with version
to find all of the version instances of a versionable class to find the user-defined default version to find the most recent version instance
Generic object should be accessed in some queries implementation and performance problem unsupported in ORION
26OOPSLA Lab
Notification of Changes
Two main approaches immediate notification by messages deferred notification using flags
Flag-based change notification in ORION change-notification-timestamp (CN) change-approval-timestamp (CA) set of events which generate a notification of change
27OOPSLA Lab
Concepts related to Notification of Changes
Notification sensitive attributes the attributes referencing the changed object
Reference consistent object, V if V.CA >= CN of all the referenced objects by V reference inconsistent system keeps CA and CN for all version instances user has the responsibility for making the instance
reference-consistent
28OOPSLA Lab
Schema Versions
Approaches to modeling schema versions schema versions class versions dynamic views of the schema
Not yet implemented, but model identifies operations which can result in new schema versions types with only transient and working version
Problems in schema versions keeping track of objects created under a schema version controlling access of applications to those objects
29OOPSLA Lab
Creator Schema Version
In a given object O, identifies the schema version(SV) in which O was created the access scope of SV the direct access scope of SV
• identifies the set of objects created from SV
Schema Version
Access Scope
Direct Access Scope
30OOPSLA Lab
Proposed Models
Time-oriented Data Model Dittrich and Lorie Klahold, Schlageter and Wilkes Landis Batory and Kim Ketabachi and Berzins Beech and Mahbod Vines, Vines and King SUN NSE Apollo DSEE
31OOPSLA Lab
Time-oriented data model
Data includes additional properties creation time of a certain object time at which an object is replaced by a new instance
Operations such as temporal series analysis ex) rate of sales increase as a function of time
No consideration of operational aspects such as inheritance, propagation of changes, workspaces, etc
32OOPSLA Lab
Version Model by Dittrich and Lorie
Design object set of versions with a specific current version reference other objects hierarchical aggregation direct reference & generic reference
Generic references resolved by environment mechanism which is a link
• between design objects and their specific versions• between design objects and another environment
Clusters of logic versions User can further structure versions such as grouping
33OOPSLA Lab
Model by Klahold, Schlageter and Wilkes
Version graph similar to the concept of history
partitions groups together a set of versions a level of consistencey
Views of subsets of a version’s graph
34OOPSLA Lab
Model by Landis
Non-linear history consists of several derivation branches the current version and the default branch.
Version references supports dynamic configuration
Change propagation a new version creation, schema change, value change
Additional mechanism to control changes delta sets which are similar to the log pended version creation is similar to checking-in in semi-
public workspace
35OOPSLA Lab
Model by Batory and Kim
Extension of the E-R model by inheritance Molecular objects
to define complex objects all versions are the instances of a molecular object
Type-version generalization to model the version history of a molecular object
Parameterized versions to use any version of a component object as the a component
of a molecular object provide support for the dynamic configuration
36OOPSLA Lab
Model by Ketabachi and Berzins Refinements for different descriptions of a object.
template refinement to describe aspects of an object explosion refinement to list the versions of the component
objects instance refinement to describe the revisions and alternatives of a
given object Incremental refinements
to describe the evolution of an object Graphs to represent the history of a version
refinement graph to derivation relationship IRG(incremental refinement graph) to stores differences between
a version and the father version.
37OOPSLA Lab
Model by Beech and Mahbod
IRIS project Version instances are organized into version sets
associated to a single generic instance Version graph
functions - first, last, next version, preceding version Messages to create new versions
mutation or propagation References can be generic or specific
generic references are resolved by contexts mechanism which consists of a trigger and a user-defined rule
38OOPSLA Lab
Model by Vines, Vines and King
Change control and versions model of GAIA Versions are identified with timestamps Version is related to the event which generated it
version sensitive relations change sensitive relations
Specific objects for managing changes change request object change notification object configuration object
39OOPSLA Lab
SUN NSU Model
System for software development environment Types of object
FILE, TARGET, COMPONENT, LINKDB
Versions are stored in the form of interleaved deltas inside an object
Access paradigm is based on acquire, modify and reconcile operations
Change notification support
40OOPSLA Lab
Apollo DSEE Model
System for software development environment Components
history manager - reserve and replace operation
configuration manager to define module composition • configuration thread and bound configuration thread(BCT)
task manager monitor manager advice manager
Versions of program modules are stored by using interleaved deltas
Release = a software system + BCT + a keyword.