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
(No Transcript)
4
Dynamic Model Object and Action

• The behavior of a type is specified by the
  actions it participates in.
• Each action is specified by actions spec(s).
• An action spec defines 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 Provided 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
(No Transcript)
7
Dynamic Model Action

• An action-occurrence may abstract a whole series
  of interactions and smaller changes.
• Action type The set of action-occurrences that
  conform to a given action-spec. A particular
  action occurrence may belong to many
  action-types.
• Action spec A specification of an action type.
  An action spec characterizes the effects of the
  occurrences on the states of the participating
  objects (for example with a postcondition).

8
(No Transcript)
9
Object and Action

• Object anything that presents a definable
  encapsulated behavior to the world around it
• individual programming-language objects, software
  components, programs, networks, relations,
  records, hardware, people, and organizations
• Action specified by its effect on the state of
  the object and any information exchanged in the
  course of that action.
• 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.

10
(No Transcript)
11
Two Kind of Actions

• Localized Actions operations
• action TypeactionName (...) ...
• An operation is a one-sided specification of an
  action, focused entirely on a single object and
  how it responds to a request, without regard to
  the initiator of that request.
• Joint Actions use-cases
• action (party1 Type1, party2 Type2, ...)
  actionName (...)
• abstract multiple interactions and specific
  protocols for information exchange,
• describe the net effect on all participants and
  the summary of information exchanged.

12
Dynamic Model Action

• The postconditions and guarantee must hold for
  any action occurrence, provided its precondition
  and rely condition were met. The rely and
  guarantee conditions are less often utilized, and
  only for non-atomic actions with significant
  duration, which can happen concurrently with
  other actions.
• For example, an action specification of an order
• 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.

13
More-Precise Action Specification

• Using snapshots to guide postconditions informal
  --gt snapshots --gt formal
• the action postconditions what to trying to
  determine
• a snapshot illustrates only one case, a set of
  snapshots is needed, thinking tool.

action assign_mentor (subject Instructor,
watchdog
Instructor) post The watchdog is now the mentor
of the subject.
action assign_mentor (subject Instructor,
watchdog
Instructor) post -- the watchdog is now the
mentor of the subject
subject.mentor watchdog
14
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.
• action assign_mentor (subject Instructor,
• watchdog
  Instructor)
• -- watchdog is now subjects mentor, and if
  watchdog had a previous mentee, they now have
  none
• post subject.mentor watchdog and
• let ex_mentee watchdog.mentee_at_pre in
• ex_mentee ltgt null gt ex_mentee.mentor null

15
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
• Summary to avoid unnecessary details (limit the
  statement to the requirements we need) and
  simplify complexity by assuming a parameterized
  attribute whose values are available later

16
Two Java Implementations of a Calendar
The internal representation and interactions
differ widely between the implementations. Our
behavior specification must abstract these
irrelevant internal interactions and include
only interactions with objects that the client
should be aware of.
17
(No Transcript)
18
From Attributes to Operation Specification

• List the operations addEvent, isFree,
  removeEvent, and calendarFor.
• Write informal operation descriptions of each
  one.
• Identify the inputs and outputs
• Working from your initial type diagram, sketch a
  pair of snapshots before and after each operation
  (draw them on one diagram)
• Draw a static type diagram of the object being
  specified, generalizing all snapshots.

19
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. Make the operation specs more
  precise function is a side-effect free operation
• 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))

20
From Attributes to Operation Specification

• Create parameter models. describe any
  input/output parameter types and their attributes
  and opertions to the extent that the client and
  the implementor need to understand and agree on
  them
• 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.

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_d
ates (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 after
simplified action Schedulerchange_dates (s
Session, d Date) pres.start gt now
posts.start d
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
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

24
Context and Control of an Invariant

• Context The type in which an invariant is
  written.
• Any object to conform to the type
• the invariant should be always true.
• the invariant can be broken behind the interface,
  but it must be restored when the operation is
  complete.
• Behind that interface are components of the
  design that have their own nested contexts and
  invariants that govern them