Re: Dependencies and associations



Date view Thread view Subject view Author view

Joaquin Miller (miller@joaquin.net)
Fri, 22 Jun 2001 09:31:47 -0700


so, if we are to apply the concepts of the ISO standard General Relationship Model to the specification of the generic relationship type named dependence (or dependency), and if we are going to accept Daniel's concept of dependence (see below), then the invariant of the dependence generic relationship type (or, to be more specific, of the spec satisfaction dependence generic relationship type) is: aDSb failure of b to satisfy its spec will affect a's ability to satisfy its spec; DS is not transitive; ... or, if you prefer classes: AdsB failure of an object of B to satisfy its spec will affect the ability of some object of A to satisfy its spec; ds is not transitive; and we can specify the invariant of the generic relationship, code text dependence: AdtB A must be recompiled if B's text changes ... it does make life easier to specify what we mean, exactly. ------- [I'm not yet convinced that we can keep the same meaning of 'association' from conceptual analysis through programming, but we will be ok as long as we have a well specified invariant for every type of generic relationship. why? because it will be obvious from the invariants if the meaning is the same. (well, of course, Daniel does subtype binary association when he gets to code by adding the additional invariant that one of the objects (or classes, if you like) in an association has a field that contains a reference to the other object (or however you want to say that if you like class here).)] At 08:41 AM 6/22/2001, Daniel Jackson wrote: >3. some observations on what dependence means. > >-- like many notions in software analysis, it's really the converse that we're interested in. we want to infer that A does NOT depend on B, so that changes to B can be made in such a way that A remains unaffected. >-- defining dependence is really tricky. it's wrong to say that A depends on B if a change to the code of B will affect the behaviour of A: that would make almost everything dependent, and it would make the dependence relationship transitive (rendering it useless). >-- the criterion is more like this: that A depends on B if a failure of B alone to satisfy its spec will affect A's ability to satisfy its spec. then if A depends on B and B depends on C, a failure of C to satisfy its spec might adversely change the execution of B, but this will not induce a dependence of A on C, since A depends only on B meeting its spec, and this can be done even if C fails to. >-- having developed such a notion, determining what constitutes a dependence in a language such as Java is a separate (and non-trivial) question. exceptions, for example, have to be considered carefully. >-- there are simpler notions of dependence worth exploring too -- eg. A must be recompiled if B's text changes. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3


Date view Thread view Subject view Author view