BehaviorConsistent Specialization of Object Life Cycles

1
Behavior-Consistent Specialization of Object Life
Cycles

• Michael Schrefl and Markus Stumptner
• ACM Transactions on Software Engineering and
  Methodology,2002
• 2002.9.18
• Presented by Lee Sunae

2
Contents

• Introduction
• Background
• Behavior diagram
• Consistent Extension
• Three different consistencies
• Rules for checking consistencies
• Conclusion

3
Introduction (1/2)

• Object-oriented designs are better to use and to
  maintain if a subtype does not override the
  behavior of its supertype arbitrarily.
• The behavior of the subtype should specialize the
  behavior of its supertype according to some
  clearly defined consistency criteria.

4
Introduction (2/2)

• Main focuses are below
• The definition of three different kinds of
  consistency between
• behavior diagram of a supertype
• behavior diagram of a subtype that extends the
  behavior of the supertype.
• The identification of necessary and sufficient
  rules for checking behavior consistency for each
  of these cases.

5
Background(1/4)

• What is a Type?
• System evolution (object-oriented) view
• A software engineering tool for managing
  software development and evolution
• The primary purposes of typing
• Specifying the structure of expressions for type
  checking
• Specifying the behavior of classes for program
  development, enhancement, and execution
• Subtypes are defined by additional predicates
  that constrain the structure of expressions.

(By OOPS MESSENGER)
6
Background(2/4)

• Types and Classes

Instance creation semantics
Type checking semantics
TYPES (PREDICATES)
CLASSES (TEMPLATES)
Type Checking interface
System Evolution interface
Template modification
Predicate constraint
SUBCLASSES
SUBTYPES
(By OOPS MESSENGER)
7
Background(3/4)

• Object life cycle
• An overall description on how instances of an
  object type evolve over time
• Subtypes may specialize the behavior diagram of
  supertypes in two ways
• Extension Adding new features
• Refinement Considering an inherited feature in
  more detail

8
Background(4/4)

• Three kinds of consistency
• Observation consistency
• What a user observes
• Invocation consistency
• Which operations a user may invoke on an object
• Weak Invocation consistency
• Captures the idea that instances of a subtype can
  be used the same way as instances of the
  supertype.
• Strong Invocation consistency
• Guarantees that one can continue to use instances
  of a subtype the same way as instances of a
  supertype.

9
Behavior Diagram(1/5)
10
Behavior Diagram(2/5)

• Behavior Diagram(Def.1)
• Life Cycle State(Def.2)

Bo (So, To, Fo) //object type O Set of states
S?Ø Set of activities T ?Ø TnS Ø A set
of arcs F ? (S T)?(T S)
A life cycle state (LCS) s is subset of
S?T Denote the initial LCS a by A
11
Behavior Diagram(3/5)

• Life Cycle Occurrence (Def. 4)

(LCO) ? is a sequence of life cycle states s1,,
s n, ( s1 A, and for i1,..,n-1 either s i
s i1 or t ? T such that either t can be started
on s i and the start of t yields s i1 or s i
contains t and the completion of t yields s i1
.) Any subsequence of ? is called partial
LCO. An LCO ? is called compete, if s n ? O (
final states)
12
use
r
issue
request
RESERVT.
r
RESERVT.
RESERVT.
r
r
r
r
requested
r
issued
void
r
r
cancel
r
RESERVT.
sendSorryLetter
sorrySent
Example of Def.4(Life Cycle Occurrence) request
,requested,issue,issued,cancel,void
13
Behavior Diagram(4/5)

• Reachable Life Cycle States (Def.5)

The set of life cycle states reachable from LCS
s,R(s) Every LCS s of O that can be reached
from s by starting or completing any sequence of
activities in T.
14
use
r
issue
request
RESERVT.
r
RESERVT.
RESERVT.
r
r
r
r
requested
r
issued
void
r
r
cancel
r
RESERVT.
sendSorryLetter
sorrySent
Example of Def.5(Reachable Life Cycle States)
R(issued) cancel,use,void
15
Behavior Diagram(5/5)

• Activation Sequence (Def. 6)

An activation sequence µ of object type O is A
sequence of statements t1,, t n (n 0) , where
t i start(t) or t i completion(t) for some t
? T.
µ is valid on some LCS s1 ? R(A) If there is
some partial LCO ? s1,, s n1 of O , Where for
i ? 1,n s n1 results from performing t i
on s i and we say µ yields the trace ?.
16
use
r
issue
request
RESERVT.
r
RESERVT.
RESERVT.
r
r
r
r
requested
r
issued
void
r
r
cancel
r
RESERVT.
sendSorryLetter
sorrySent
Example of Def.6(Activation sequence)
s(request), c(request), s(issue), c(issue),
s(cancel), c(cancel)
17
use
r
issue
request
RESERVT.
r
RESERVT.
RESERVT.
r
r
r
r
requested
r
issued
void
r
r
cancel
r
RESERVT.
sendSorryLetter
sorrySent
Fig.1. (Labeled) Behavior diagram of object type
RESERVATION
18
Consistent Extension(1/7)

• Observation Consistency
• Restriction of a Life Cycle Occurrence (Def. 8)
• Observation Consistent Extension (Def. 9)

s/o s n (So?To) (RLCO) ?/O s1,, s n,
where i 1,,ns is i/o
Bo B (S,T,F) is an observation
consistent extension of a Bo B (S,T,F), iff
for every ? of object type O, ?/O is a LCO of B
19
LCO of RESERVATION_PLUS ,issue,issued,
toBeBilled,.. RLCO of this to object type
RESERVATION..issue,issued
20
LCO of this Behavior diagram request,requeste
d,offerAlternative RLCO of this to object
type RESERVATIONrequest,requested,
21
Consistent Extension(2/7)

• Weak Invocation Consistency

Bo B (S,T,F) is a weak invocation
consistent extension of a Bo B (S,T,F), If
every activation sequence µ valid on A in B is
also valid on A in B and, for their respective
traces ? and ?, ? ?/o holds.
22
s(request), c(request), s(issue), c(issue),
s(use) is valid for RESERVATION But, not for
RESERVATION_WITH_PAYMENT
23
Consistent Extension(3/7)

• Strong Invocation Consistency

Bo B (S,T,F) is a strong invocation
consistent extension of a Bo B (S,T,F) if
(1) every activation sequence ? valid on A in B
is valid on A in B (2) every ? valid in B on
s/o (s? R(A)) is valid in B on every life
cycle state s(that results from performing any
activation sequence ? of activities in T\T on
s), and for the traces ? and ? (generated by
performing ? in B on s/o and by performing ? in
B on s) it holds that ? ?/o . (? and ? may
be empty).
24
(No Transcript)
25
Consistent Extension(4/7)

• Checking Observation Consistency
• Partial inheritance (E1.)
• Immediate definition of prestates and
  poststates(E2.)

• a a
• t ? T ? t ? T ? (s, t) ? F ? (s,t) ? F
• t ? T ? t ? T ? (t, s) ? F ? (t,s) ? F

• (s, t) ? F ? s ? S ? t ? T ? (s, t) ? F
• (t, s) ? F ? s ? S ? t ? T ? (t, s) ? F

26
Consistent Extension(5/7)

• Checking Observation Consistency(cont.)
• Parallel extension(E3.)
• B is an observation consistent extension of B if
  and only if rules E1,E2, and E3 are obeyed.

• (s, t) ? F ? t ? T ? t ? T ? s ? S
• (t, s) ? F ? t ? T ? t ? T ? s ? S

27
Consistent Extension(6/7)

• Checking Weak Invocation Consistency
• Full inheritance (E4.)
• Alternative extension(E5.)
• B is a weak invocation consistent extension of B
  if rules E1,E2,E4, and E5 are obeyed.

T? T
(s, t) ? F ? s ? S ? s ? S ? t ? T
28
Consistent Extension(7/7)

• Checking Strong Invocation Consistency
• B is a strong invocation-consistent extension of
  B if rules E1 to E5 are obeyed.
• If B is a strong invocation-consistent extension
  of B, then B is an observation-consistent
  extension of B and B is a weak
  invocation-consistent extension of B.

29
Conclusion

• Three different consistency are defined in the
  realm of Object Behavior Diagrams.
• Observation consistency
• Weak invocation consistency
• Strong invocation consistency
• The rules introduced can assist the designer to
  recognize and identify situations that violate a
  particular kind of consistency.

30
Contribution of this paper

• Necessary and sufficient rules for checking
  behavior consistency between object life cycles
  of object types in specialization hierarchies
  with multiple inheritance.