6894 workshop in software design lecture 3 september 16, 1998 object modelling

1
6894 workshop in software designlecture 3
september 16, 1998 object modelling
2
component models aspect models

• component model
• describes system as composition of components
• procedures, abstract data types, classes, etc
• each component described by its interface
• interface observable behaviour
• aspect model
• describes system as composition of aspects
• each aspect is a partial description of the
  behaviour of the entire system
• an analogy
• in designing a house, can construct separate
  blueprintsfor plumbing, electricity, heating,
  etc
• well look at 2 kinds of aspect model
• object model
• describes abstract state of system
• sets of objects and their connections
• entity life histories
• describes event orderings
• for each kind of object, alphabet of events and
  set of expected sequences

3
why aspect modelling?

• component models arent analyzable
• with interfaces alone, cant reason about how
  components fit together
• would need to express how components are used
• we dont know how to do this without exposing
  implementation
• characterize a components underside too?
• component models are expensive to construct
• a full spec of a component is often no simpler
  than its code
• partial descriptions dont seem to be very useful
  in design
• content before locus
• aspect models describe the content of the
  computation
• can postpone allocation of computation until
  later
• better staging of design
• more freedom to invent better allocation schemes
• clearer description of content
• not cluttered by implementation details
• well discuss component models later
• declarative specification

4
object model of macintosh finder

• invariants
• names within folders are unique
• all f FOLDER, n NAME sole o OBJ o.inside
  f o.name n
• no alias linked to itself, directly or indirectly
• all a ALIAS a not in a.linked_to

name
!
!
OBJ
NAME


inside
?
TRASH
FILE
FOLDER
DRIVE
linked_to
ALIAS
OPEN
DESKTOP

5
snapshots

• meaning of object model
• set of snapshots
• each snapshot is a graph
• nodes represent objects, labelled with sets they
  belong to
• arcs represent relations, labelled with names of
  relations
• example
• oops!

o3DESKTOP OPEN
o1TRASH
o2DRIVE
o5FOLDER
o4ALIAS
insidelinked_toname
n1NAME
6
whats (intentionally) missing

• allocation of state
• objects have no internal structure or state
• all state is in the sets and relations
• kinds of objects
• no distinction between attributes and entities
• primitive values treated as objects (if relevant)
• navigation
• direction of relation is semantic
• says nothing about whether it can be navigated
• no namespace accessibility claims
• programming language notions
• no classes
• no methods
• no references or pointers
• no fields or instance variables

7
notational elements (1)

• sets
• boxes represent sets of objects
• objects are just atomic, structureless things
• singletons
• ovals represent singletons sets that contain at
  most one element
• subsets
• big arrow from A to B means A is a subset of B
• every A is a B
• subsets that share an arrowhead are mutually
  disjoint
• otherwise subsets may overlap
• filled arrowhead means that subsets exhaust
  superset
• ie, subsets form a partition

8
notational elements (2)

• relations
• arcs represent relations
• an arc from A to B labelled r denotes a
• relation that maps elements of A to elements of B
• each A object may be associated with zero or more
  Bs, and vv
• indexed relations
• arc labelled rX from A to B denotes a
• collection of relations from A to B
• one for each element e in the set X
• example of indexed relation
• might incorporate naming invariant by replacing
  inside relation by
• inside NAME OBJ? -gt FOLDER?

9
typing

• domains
• some sets have no parents
• eg, OBJ, NAME
• these are called domains
• type of set
• if S is a subset of domain D, S has type D (a set
  of elements from D)
• if S is a subset of set T, S has same type as T
• ie, each set box is given a type corresponding to
  its domain
• type of relation
• a relation from A to B has type D -gt E
• where D is the type of A
• and E is the type of B
• overloading
• no overloading is allowed only one set or
  relation with given name
• but two relations may have the same name if their
  source types differ
• very convenient, eg state in observer model (see
  lecture 1)

10
multiplicity

• multiplicity markings
• means zero or more
• ? means zero or one
• ! means exactly one
• means one or more
• omitted markings
• no marking means zero or more
• but not the same as
• suggests incomplete model
• idioms
• f A -gt B? a partial function
• f A -gt B! a total function
• h A! -gt B! a one-to-one mapping
• note
• depends on exact definition of set need a
  dictionary
• what is multiplicity on HOST here? depends on
  what IP means
• ip-address HOST -gt IP?

11
mutability

• hatch means immutable
• hatch at target of arc labelled r from A to B
  means
• set of Bs associated with a given A cannot
  change in its lifetime
• write this in text as
• r A -gt sticky B
• similarly at source of arc
• examples
• social-security-number sticky PERSON! -gt SSN?
• ticker-symbol sticky COMPANY -gt SYMBOL
• mother PERSON -gt sticky PERSON!
• transponder_id AIRCRAFT? -gt ID?
• model AIRCRAFT -gt sticky MODEL!
• location AIRPORT? -gt sticky COORD!
• note
• depends on exact definitions again what is
  lifetime?
• eg, are dead mothers still mothers?

12
static dynamic classification

• two kinds of set membership
• classify objects for their entire lifetimes
• eg, FOLDER once a folder, always a folder
• classify objects in a time-varying fashion
• eg, OPEN folder may be opened and closed
• bar means static
• bar down side of box labelled A means
• membership in A is a constant property of an
  object
• if created in A, remains in A
• if created outside A, remains outside A
• A is static or sticky
• domains
• are static by definition

13
fixed components

• facts
• are properties that never change
• represent as fixed components
• notation
• fixed set bar on both sides
• fixed relation double hatch
• examples
• fixed north-of LATITUDE -gt LATITUDE
• fixed partition north, east, south, west
  DIRECTION !

14
constraints (1)

• why constraints?
• graphical notation not expressive enough
• want to express extra invariants
• simple constraint language
• expressions denote sets of objects
• scalars treated as sets containing one element
• expressions
• sets from sets
• s1 s2 union
• s1 - s2 difference
• s1 s2 intersection
• sets from sets and relations
• s.r image of s under r
• s.r image of s under transpose of r
• s.r image of s under closure of r
• sets from formulas
• v f set comprehension

15
constraints (2)

• formulas
• elementary formulas
• e1 e2 equality
• e1 in e2 subset or membership
• formulas
• f1 f2 conjunction
• f1 f2 disjunction
• f1 -gt f2 implication
• quantified formulas
• all v f universal quantification
• some v f existential quantification
• no v f same as (not some v f)
• sole v f at most one value of v such that f
• one v f same as ((sole v f) and (some v
  f))
• quantifier shorthands
• some e short for (some v v in e)
• no e short for (no v v in e)

16
sample constraints

• no FILE FOLDER
• no object is both a file and a folder implicit
  in diagram
• no DRIVE.inside
• no object that the drive is inside
• TRASH.name ! DRIVE.name
• trash and drive have different names
• TRASH.linked_to
• the set of aliases pointing to the trash
• all o OBJ TRASH in o.inside DRIVE in
  o.inside o in (TRASH DRIVE)
• every object is reachable from the trash or drive
• no o OBJ o in o.inside
• no cycles in the folder hierarchy
• DESKTOP in OPEN
• desktop is always open

17
derived components

• redundancy
• sometimes useful to add derived component
• makes it easier to express constraints
• redundant its value can be computed from rest of
  state
• notation
• derived components are placed in parens
• an arc labelled p(q) defines, in addition to the
  relation p
• a second relation q that is derived
• q is the transpose of p
• examples
• inside (contains) OBJ -gt FOLDER
• all d, o OBJ d in o.inside lt-gt o in d.contains
• (trashed) OBJ
• trashed TRASH.contains

18
idioms lifting

• problem
• two relations or subsets play a similar role but
  act on different sets
• solution
• introduce a new superset, and replace relations
  or subsets by one
• analogous to introducing common superclass in
  code
• examples
• without OBJ, would need separate relations
• inside FILE -gt FOLDER
• inside FOLDER -gt FOLDER

19
idioms lowering

• problem
• different objects ina set have different
  properties
• multiplicity constraints are too weak
• solution
• introduce a new subset
• analogous to introducing new subclass so that all
  fields are non-null
• examples
• without ALIAS, linked_to would be declared as
• linked_to FILE -gt OBJ?
• rather than
• linked_to ALIAS -gt OBJ!

20
idioms classification

• problem
• functions to small, fixed sets make invariants
  hard to express
• solution
• replace function by classification
• often needed for lowering
• example 1
• without OPEN, would need
• status FOLDER -gt STATUSfixed disjoint OPEN,
  CLOSED STATUS
• example 2
• separate cache entries into clean, dirty
• makes it easier to express invariants
• all e CLEAN e.val a.addr.val

21
idioms tuple objects

• problem
• want to express relation between 3 or more
  objects
• solution
• introduce an object representing a tuple
• example
• if employees can work for gt1 company,salary is
  property of employee and company
• so introduce JOB object

salary
SALARY
JOB
person
company
PERSON
COMPANY
22
idioms set objects

• problem
• want to express relation between sets of objects
• solution
• introduce an object representing a set of objects
• example
• course prerequisites in disjunctive normal
  form(6001 and 6045) or (6821 and 6840)

23
UML co

• UML
• Unified Modeling Language
• Rational Inc, with support of large consortium
  (see www.rational.com/uml )
• OMG adopted technology since Nov 1997 (see
  uml.systemhouse.mci.com)
• recent methods
• Catalysis UML-based method by DSouza and Wills,
  AW 1998 (www.iconcomp.com)
• Fusion Coleman et al, PH 1994 (www.hpl.hp.com)
• Syntropy Cook Daniels, PH 1994
  (www.objectdesigners.co.uk)
• why I like Catalysis
• more careful about meaning of notations
• nice explanation of role of object models
• judicious use of formalism
• object models are abstract sets may be dynamic
• considers views, frameworks etc?

24
Alloy

• Alloy
• a new object modelling language
• design not complete
• all examples in this lecture are in Alloy
• analysis tool for Alloy models under construction
• motivation
• tool support -gt formal semantics
• well-defined notation
• more natural constraint language than OCL
• complications of OCL avoided in Alloy
• null references
• downcasting and typecasing instead of set ops
• lack of closure results in recursive constraints
  (well founded?)
• forced nesting of quantifiers

25
comparison of OCL and Alloy (from UML docs)

• in OCL
• ClassifierallFeatures Set(Feature)allFeatures
  self.feature-gtunion(self.supertype.oclAsType(Cl
  assifier).allFeatures)
• Interfaceself.allFeatures-gtforall (f
  f.oclIsKindOf(Operation))
• in Alloy
• all i Interface i.feature in Operation

26
center airspace structure
WAYPOINT
CENTER
center
supervisor
FIX
AREA
SUPERVISOR
supervisor
area
tracon
FAF
OMA
GATE
SECTOR
TRACON
gates
feedsGate
controller
tracon
CONTROLLER
feedsRunway
RUNWAY
AIRPORT
airport
27
problems

• multiplicities and mutability
• annotate the model appropriately
• dynamic sector allocation
• when the airport gets less busy, might group
  sectors together
• so one controllers sector is now what were
  previously several sectors
• alter the object model to express this
• naming rules
• fixes have unique names, and runways have unique
  names for a given airport
• add this notion of naming to the model
• runway configurations
• each runway may be configured for landing or
  takeoff
• but some configurations are illegal cant land
  one end take off other end of a runway
• express these constraints in the model
• blocked intervals
• meter gates, runways, airports may be blocked
  (not to be used) for certain time periods
• add this notion to the model

28
dictionary

• a dictionary is
• a list of all components (sets and relations)
• for each, an informal but careful description of
  what it means
• why does it matter?
• without it, model is meaningless!
• cant answer even multiplicity questions
• for substantial discussion, see designations in
  Jac95
• examples
• does every ticker SYMBOL have an associated
  COMPANY?
• depends on whether TICKER denotes all strings
  that can be parsed as ticker symbols,or just the
  actual symbols of a stock exchange
• can two runways share a BLOCKED-INTERVAL?
• must decide whether a BLOCKED-INTERVAL is just a
  time period, or is essential a reservation for
  some reason then would expect both runways to be
  unblocked when reason no longer holds
• (thanks to J. Chapin for this example)