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 • we’ll 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 aren’t analyzable • with interfaces alone, can’t reason about how components fit together • would need to express how components are used • we don’t know how to do this without exposing implementation • characterize a component’s underside too? • component models are expensive to construct • a full spec of a component is often no simpler than its code • partial descriptions don’t 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 • we’ll 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! o3:DESKTOP& OPEN o1:TRASH o2:DRIVE o4:ALIAS o5:FOLDER insidelinked_toname n1:NAME

6. what’s (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 B’s, and vv • indexed relations • arc labelled r[X] 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? -> 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 -> 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 -> B? a partial function • f : A -> B! a total function • h : A! -> 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 -> IP?

11. mutability • hatch means immutable • hatch at target of arc labelled r from A to B means • set of B’s associated with a given A cannot change in its lifetime • write this in text as • r : A -> sticky B • similarly at source of arc • examples • social-security-number : sticky PERSON! -> SSN? • ticker-symbol : sticky COMPANY -> SYMBOL • mother : PERSON -> sticky PERSON! • transponder_id : AIRCRAFT? -> ID? • model : AIRCRAFT -> sticky MODEL! • location: AIRPORT? -> 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. north_of LATITUDE DIRECTION … NORTH EAST 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 -> 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 -> 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 -> FOLDER • all d, o: OBJ | d in o.inside <-> o in d.contains • (trashed) : OBJ • trashed = TRASH.contains*

18. ! ! ID MEMBER id contains LOCKED GROUP ELEMENT STUDENT FACULTY LINE POLYGON part_of 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 -> FOLDER • inside : FOLDER -> FOLDER

19. PHONE ! ! CALLER CALLEE calling 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 -> OBJ? • rather than • linked_to : ALIAS -> OBJ!

20. CELL val VALUE addr ENTRY val CLEAN DIRTY 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 -> 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 >1 company,salary is property of employee and company • so introduce JOB object salary SALARY JOB person company PERSON COMPANY

22. COURSE requires_one_of consists_of REQ discharges 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 D’Souza 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 -> 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. ModelElement Classifier Feature ! feature * Interface Operation comparison of OCL and Alloy (from UML docs) • in OCL • Classifier:allFeatures: Set(Feature);allFeatures = self.feature->union(self.supertype.oclAsType(Classifier).allFeatures) • Interface:self.allFeatures->forall (f | f.oclIsKindOf(Operation)) • in Alloy • all i: Interface | i.feature* in Operation

26. center airspace structure WAYPOINT CENTER center supervisor FIX AREA SUPERVISOR area supervisor tracon FAF OMA GATE SECTOR TRACON gates feedsGate controller tracon feedsRunway CONTROLLER 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 controller’s 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: can’t 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! • can’t 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)