CS551 Modelling with Objects (Chap. 3 of UML)

1
CS551 Modelling with Objects (Chap. 3 of UML)

• Yugi Lee
• STB 555
• [phone]
• yugi_at_cstp.umkc.edu
• www.cstp.umkc.edu/yugi

2
Object Modelling

• Static model the state of an object at any given
  moment (object attributes, relationships,
  constraints between objects)
• Dynamic model the changes that happen to the
  state as event occur (actions affect objects,
  using the changes of objects and attributes in
  the object state)
• Interactive model interactions between objects
  (the responsibility for achieving goal is divided
  among collaborating objects)

3
Dynamic Model Action

• Action specified by its effect on the state of
  the object and any information exchanged in the
  course of that action.
• E.g. individual programming-language messages,
  procedure calls, complete dialogs between objects
  of all kinds.
• the effects of an action even without knowing
  exactly who initiates it or how it works in
  detail.
• Action Specification behavior of a type

4
Dynamic Model Action Spec

• The effects of that action in terms of the
  attributes of the objects involved, and the
  conditions under which those effects hold, using
• preconditions what is expected to be true at the
  start of the action
• rely conditions what is expected to be
  maintained true during the action
• postconditions what is correspondingly ensured
  to become true at the end of the action
• guarantee conditions what is ensured to remain
  true during the action

5
Action and Pre/Post Conditions
action schedule_course (reqCourse Course,
reqStart Date) pre there is an instructor
qualified for this course who is
free on this date, for the length of the course.
postA new confirmed session has been created,
with course reqCourse,
startDate reqStart, and
endDate startDate reqCourse.length.
6
Action and Rely/Guarantee Conditions

• less often utilized, and only for non-atomic
  actions with significant duration (concurrently
  with other actions).
• Order fulfill
• pre the order must be in the pending state
• rely while the order is being fulfilled the
  product specifications had better not change
• post the fulfilled order has been shipped to the
  customer based on the product specifications, and
  the order has been inserted into the billing
  queue
• guarantee true i.e. not particular rule
  maintained during an order's fulfillment.

7
(No Transcript)
8
(No Transcript)
9
Dynamic Model Action

• Action-occurrence abstract a whole series of
  interactions and smaller changes.
• Action type The set of action-occurrences that
  conform to a given action-spec.
• Action spec A specification of an action type.
• An action spec characterizes the effects of the
  occurrences on the states of the participating
  objects

10
(No Transcript)
11
(No Transcript)
12
Two Kind of Actions

• Localized Actions operations
• a one-sided specification of an action, focused
  entirely on a single object and how it responds
  to a request.
• Joint Actions use-cases
• abstract multiple interactions and specific
  protocols for information exchange,
• the net effect on all participants and the
  summary of information exchanged.

13
(No Transcript)
14
More-Precise Action Specification

• Using snapshots to guide postconditions
• informal --gt snapshots --gt formal

action assign_mentor (subject Instructor,
watchdog
Instructor) post -- the watchdog is now the
mentor of the subject
subject.mentor watchdog
15
From Attributes to Operation Specification

• List the operations addEvent, isFree,
  removeEvent, etc.
• Write informal operation descriptions of each one
  with identified inputs and outputs
• Working from your initial type diagram, sketch a
  pair of snapshots before and after each operation
  
• Draw a static type diagram of the object being
  specified, generalizing all snapshots.

16
From Attributes to Operation Specification

• Describe any input/output parameter types and
  their attributes and opertions
• action Eventdelete ()
• pre true
• post -- the same effect as removing the event
  from the calendar
• calendar.removeEvent (self)
• Write a dictionary of terms and improve your
  informal specifications.
• instructor the person assigned to a scheduled
  event
• schedule the set of events instructor is
  currently scheduled for
• free if an instructor is free on a date, no event
  on his schedule overlaps with that date
• Improve the model or design by some factoring.

17
From Attributes to Operation Specification

• Document the invariants that the model should
  satisfy.
• inv Event start lt end
• inv Instructor free(d Date) (
  self.schedule overlaps(d) -gtisEmpty)
• inv Event overlaps(d Date) (start lt
  d end gt d)
• Specify operations.
• action CalendaraddEvent (d1 Date, d2 Date, i
  Instructor, o Object) Event
• pre d1 lt d2 d1..d2-gtforAll (d
  i.free (d))
• post result Event.new info o
  start d1 end d2 instructor i
• 
  calendar self
• function CalendarisFree (i
  Instructor, d1 Date, d2 Date) Boolean
• pre d1 lt d2
• post result d1..d2-gtforAll (d
  i.free (d))

18
More-Precise Action Specification

• Comparing before and after
• a postcondition makes an assertion about the
  states immediately before and after the action
  has happened.
• For every object there are two snapshots and two
  complete sets of attribute values to refer to.

19
Interpreting an Action Specification
20
More-Precise Action Specification

• Newly created objects new
• action schedule_course (reqCourse
  Course, reqStart Date)
• post let ns Session.new course
  reqCourse and startDate reqStart
• 
  and endDate startDate reqCourse.length
  
• in ns.instructor.available
  _at_pre(startDate, endDate)
• Collections set union () and set differnce (-)
• action reassign_course (session
  Session, new_inst Instructor)
• post let ex_instructor
  session.instructor_at_pre
• in ex_instructor.schedule
  ex_instructor.schedule_at_pre session
• and
  new_inst.schedule new_inst.schedule session

21
Action with Invariants
inv Instructor qualifiedFor -gt includesAll
(sessions.course) sessions -gtforAll (s1, s2 s
ltgt s1 implies not s1.overlaps(s2)) inv Session
confirmed gt instructor ltgt null and end
start course.duration action
Schedulerchange_dates (s Session, d Date)
pres.start gt now and s.course ltgt nil and
s.course.duration Days posts.start d and
s.end d course.duration
22
Action with Invariants

• Static Invariants hold before and after the
  actions in its range, required to be true of all
  the actions in its rage.
• Dynamic (effect) invariants an effect that is
  invariant across all actions in its rage and is
  implicitly added to the postconditions of those
  actions.

23
Dynamic Invariants

• inv effect Calendarcount_invocations post
  count 1
• action CalendarremoveEvent (e Event)
• pre -- provided the event is on this calendar
• schedule-gtincludes (e)
• post -- that event has been removed from the
  calendar and instructor schedules
• not schedule-gtincludes (e) and
• not e.instructor_at_pre.schedule-gtincludes (e)
• -- and the effect invariant is implicitly applied
• and count 1

24
Rules Actions Static Dynamic Invariants
New session created, confirmed if qualified
instructor available
Action Spec guarantees and assumptions of action
schedule
Company
deliver
Instructor qualified
Students
Admin
skills
pay
fee-due funds
Session date, topic cost
assigned
Any change in session must propagate to
scheduler
Dynamic Invariant A state change rule that
applies to all actions
Assigned instructor is qualified for topic
Static invariant Attribute constraint in all
states

• Captures important rules accurately without
  getting into implementation details
• Enable the Business User to raise and resolve
  critical issues early

25
An Action Spec Is Not an Implementation

• Action Spec
• a Boolean expression, a relation between the
  inputs, initial state, final state, and outputs.
• Implementation
• a particular algorithmic sequence of steps,
• select a data representation or specific internal
  access functions,
• work through iterations, branches, and many
  intermediate states before achieving the final
  state.