< theÉÍÍ»ÉÍÍ»É É º Ó¶ Ó¶ º Û º º º ÉÍÍÍ» ÌÍ ÉÍÍÍ»É ÉÍÍÍ»º É ÉÍÍÍ»É ÉÍÍÍ»É ÖÄ· ÉÍÍÍ»É ÉÍ»ÉÍ»É º º º º º º º Ó¶ º Ó¶ º º Ó¶ º Ó¶ ºÖ½ º Ó¶ º Ó¶ Ó¶ º º ºÚ×ÄÄĽ º Ú¶ ºÚ¶ º ºÚ¶ ºÚ¶ º ºº Ú¶ º º º º º º º³º ÖĶ ³º Ö¶³º Ö¶ º³º Ö¶³º Ö¶ ºº ³º Ö¶ º º º ½ Ð ÓÙÈÍÍͼ È;ÈÍÍͼÓÙÈÍÍͼÓÄÐÙÈÍÍͼÓÙÈÍÍͼºÚ½ÓÄÙÈÍÍͼÓĽ Ð º ÖÄÄÄÄ×Ù º ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÈÍÍÍͼÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄ architecture (kernel) SNAV - ODD specification - 13.8.90 page 1 - ÚÄÄÄÄÄÄÄ¿ ÄÄÄÄÄÄÄÄÄ>³ AVNER ³ ÄÄÄÄÄÄÄÄÄ>³ BEN ³ÄÄÄÄÄÄ> Software Engineering Method ÀÄÄÄÄÄÄÄÙ 10 Dov-Hoz st. Tel-Aviv 63416 Israel tel. 972-3-221535 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ "The Screen NAVigator" ³ ³ ³ ³ OD model specification ³ ³ ³ ³ Version 1.20, August 1990. ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Copyright (c) 1990 by Avner Ben. Written by Avner Ben 13 August 1990. Original Written 13 April 1990. SNAV - ODD specification - 13.8.90 page 2 - EABSTRACTF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF The following document specifies a graphic formalism called "Object Dependency Diagram" (ODD). It is intended as a data-model specification tool in the C++ programming language environment. Assuming a three level project hierarchy, ODD addresses the middle - that is designer's - level. It facilitates the discussion of implementation dependant design decisions, prior to actual coding (or in iteration with it), yet at a level that maintains "eye contact" with the conceptual model. In the project life-cycle, ODD has a full downward compatibility, that is, 1:1 mapping to C++ syntax. Upwards, It may be decomposed from an ER conceptual model, though a formal method is yet to be proposed. ODD does not support explicit semantic hierarchies, and is not aimed, by default, for use in other OOP environments, but C++. Keywords: OOD, OBJECT-ORIENTED DESIGN, OOP, OBJECT-ORIENTED PROGRAMMING, C++, DATA-MODELLING, DATA-DRIVEN DESIGN. SNAV - ODD specification - 13.8.90 page 3 - ECONTENTSF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Abstract ..................................................2 Contents ..................................................3 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Preface ...................................................4 ODD specification .........................................6 Usage conventions ........................................12 Limitations of the model .................................13 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Examples .................................................14 Syntax definition ........................................21 Bibilography .............................................25 SNAV - ODD specification - 13.8.90 page 4 - EPREFACEF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF I originally developed the Object-Dependency model for documenting "SNAV", a reusable-object library in the C++ language, featuring a generic formatted-output driver for drawing semi-graphic shapes using sort of "turtle graphics", distributed as shareware. Further details of this software are irrelevant for the present purpose, and are to be found elsewhere [1]. The notation is also inspired by my work with "Sapiens", a mainframe trigger-based application generator and DBMS, featuring a unique concept of the hierarchical data model [2]. Though not a formal OO tool, it has been giving me invaluable insight as to the workings of an OO data structure. I have used the Object-Dependency model for both specification and documentation. It has a strong, quasi-formal mapping to both programming level (C++ code) and systems-analysis level (ER or a similar conceptual data model). SNAV - ODD specification - 13.8.90 page 5 - EOBJECT DEPENDENCY DIAGRAM - PURPOSEF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF The Object-Dependency model's purpose is to display the underlying data-model of a C++ application, where this implements entities as classes and groups them into structures. Principally, there are two methods for grouping classes: structure and inheritance. Current OO data-models either stress the semantic model (inheritance links), (refer to any good Smalltalk text, such as [3]), or use a disjoint presentation of the strutural and semantic models of the same application ([4]). Recently, we have been witnessing attempts to unify the rivaling data-models into a coherent one-page presentation scheme. Source [5] is a bold example. I believe this attempt, doubtless admirable for the intent, to miss the point, by producing charts that are hard to understand and work with. I find this malady to be typical of both network models in general, and the desire to couple ends that do not meet, in particular. In my opinion, combined models such as a chart pretending to display both semantic and structural dependencies pertaining to the same application, must stress one of them, allowing the other to enter through the servant's door. My model is unique (as far as I know) in stressing the structural aspect. This happans because OO application that I have built to date are of this nature. I percieve inheritance as a special case of 1:1 relationship ("isa" relationship [6] or "subtype" in traditional E/R terminology). This case is important enough to merit a special symbol in the structure presentation. However, because inheritance is viewed as a structural element, there is no facility for displaying a hierarchy of such (this is not a structural design). So applications based on a large scale semantic hierarchy (or network), owing little to 1:1, 1:m and m:n relationships between objects as a strong design consideration, will not benefit from this model. Simmilarly, the Object-Dependency model, being a data-model, is only partially eqippped for expressing dataflow between objects. A limited facility is provided to display dataflow that is used for implementing structure, but it is recommended not to overuse this feature. The proper, industry-standard tool for expressing dataflow is the DFD ([7]). What will benefit ftom the OD model are "data-driven" applications like Snav. Snav is a data-driven application, managing data-structures. Which happans to fit naturally with the programming language C++, where "class" is mere extension of the struct concept. Snav is a miniature in-memory database where iterator classes play as managers for data-aggregates, where the records are managed by lower-level classes. Message-passing is more concerned with managing data-integrity than with implementing events. Such an application calls for a data-oriented descriptive model, equipped to survive in an OO environment. I have done my best to produce one. SNAV - ODD specification - 13.8.90 page 6 - EOBJECT DEPENDENCY DIAGRAM - DEFINITIONF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF The Object-Dependency model's display is distributed over an indefinte number of one-page connected or disconnected graphs, called "Object-Dependency Diagram"s, or "OD frame"s. An OD frame may consist of (at most) the following symbols: "Class", "Hierarchical Link", "Inheritance Link". "Late Binding" and "Update Constraint". Some of these symbols have further detail, to be discussed below. -1The "Class" symbol:-0 ÚÄÄÄÄÄÄÄÄÄÄÄ¿ Represented by a name within an oblong. This symbol is ³ ³ normally used for a proper C++ class. It may also be ³ ÚÄÄÄÄÄ¿ ³ used for a "pseudoclass": a C++ variable or struct ³ ³class³ ³ were these are a "decadent" representation of a ³ ÀÄÄÄÄÄÙ ³ conceptual-level object that should map into a class. ³ ³ A class may be repeated in the ODD as many times as ÀÄÄÄÄÄÄÄÄÄÄÄÙ needed, depending on its hierarchical links, and the number of frames in which it happans to participate. -1The "Hierarchical Link" symbol:-0 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ Represented by a line beginning at the bottom ³ ³ end of one class and ending at the top end of ³ ³ ³ some class. The line need not be explicitly ³ d*³ ³ directed. It owes its direction to an explicit ³ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ³ top-down positioning of the classes. When a ³ ³parent_class³ ³ class initiates a number of hierarchical links, ³ ÀÄÄÄÄÄÂÄÄÄÄÄÄÙ ³ their exit points may be unified. There is no ³ ³ ³ importance to the horizontal ordering of ³ ³ ³ hierarchical links. ³ p40³ ³ ³ ÚÄÄÄÄÄÁÄÄÄÄÄ¿ ³ An hierarchical link has a type and a ³ ³child_class³ ³ cardinality. These are written near the entry ³ ÀÄÄÄÄÄÄÄÄÄÄÄÙ ³ point of the link, in the order type, ³ ³ cardinality, with no separating space. Type is ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ represented by a letter, cardinality by a number or asterisk. The default type is "d", and cardinality, "1". All root classes in the ODD (classes that have no explicit parent), are assumed to be linked to class "system". Class system has no attributes and is not rendered in the chart. However, the link to system is represented as a link coming from nowhere and entering the top of the class. It is referred to as its "entry point". Entry-points have type and cardinality like any other link. SNAV - ODD specification E OBJECT DEPENDENCY DIAGRAM - DEFINITIONF - 13.8.90 page 7 - -1Specifying hierarchical link type:-0 There are three hierarchical-link types: "d" (for declared), "p" (for pointed) and "c" (for computed). The type of an entry point represents its "normal" (but not necessarily the only) access method, when standing alone. -1"Declared link".-0 The object is physically included within the parent, and is (normally) invisible outside it. Its lifetime is limited to the scope of its parent. Represented by the letter d. This is the default type. Example: an "arc" (always) points in (exactly one) "direction". -1"Pointed link".-0 The object has been allocated elsewhere, and is referenced. Its lifetime is independent of its parent. The referencing method is implementation dependant (e.g. pointer to ram, key to file, etc.). Represented by the letter p. Example: a "shape" points to an (external) linked-list of "stroke"s. -1"Computed link".-0 The object is (virtually) pointed, but does not necessarily exist. The parent object stores a "foreign-key" variable, which may be used to physically allocate the object (e.g. nested within a C++ expression), if the need occurs. The lifetime (and mere existence) of the virtual object is implementation dependant. This feature is (not supported by other data-models I know), is essential for keeping consistency with a higher-level design specification, and for optimizing performance-oriented software. I just cannot undertand how a methodolgy may be used on design-level without such a feature (unless applied for the infamous purpose of producing shelf documentation). Example: since the implementation is not going to generate characters, we can do with keeping only the (imaginary) object's ascii-value. But we can invoke the desired occurance when needed. -1Specifying hierarchical-link cardinality:-0 Cardinality is specified by either a maximum number, or the "indefinite cardinality" symbol (*), adjacent to the link-type letter. The cardinality specifies the maximum number of occurrences (objects allocated) for the child class within its parent. The cardinality of an entry-point may determine either the maximum number of objects of this type in the whole of the system, or, where the class has a unique key, the the size of the datatype's "domain" of values. For example, there may be any number of "alphabet"s allocated at any time, but there are only 4 "direction"s in the plain (no matter however instances duplicated and used). This point is not closed in the present version. The following cardinalities have a special design significance: '0' (zero) cardinality practically says that such an object will never be allocated. Its only legitimate use is for an abstract class, defining a "genre" of classes, declared elsewhere (where used). Such a class is normally provided with a pointing link from system, and a derived class with a "late-binding" link back to it. Example: the "screen-driver" in general (paractice calls for a particular implementation). SNAV - ODD specification E OBJECT DEPENDENCY DIAGRAM - DEFINITIONF - 13.8.90 page 8 - '1' cardinality is the default case. It says that zero to one child objects may be allocated within each parent object. Cardinality of 1 in a declared link (the grand default) practically says that the child class is a declared part of the parent class's structure. In a pointed or computed link, it says that the child object's existence is optional. Example: a stroke may have a unique color ("p1"), but a screen cell always has a color ("d1"). Cardinality greater than 1 is implementation dependant. In a declared link it may suggest either an array implementation, or the existence of a number of distinct variables of this datatype (designer's decision). Remember that ODD, being a data-model, supplies no facilities for discerning between two objects by function; only by datatype! In a pointed link, it may suggest a linked list, unordered set or disk file implementation. The existence of a "pn" link usually determines some sort of "container class". Computed links are similar to declared links, in this respect. Indefinite cardinality ('*') may mean zero, one or any number of objects. It should be used when the link implements a pure generator or iterator class, and in general, whenever the actual domain is determined during run-time. (If the number of records in the file is known in advance, use the number!). Cardinality may not be specified by variable or by formula! Exceptionally, and while I personally refrain from that, I mention here that cardinalities may be also specified by range, (using a pair of numbers within brackets, divided by comma), and by approximation (using the symbols > < >= and <=). I recommend to keep this practice to the minimum. These represent run-time dependent and other procedural considerations, which should be kept away from the data-model! -1The "UnHierarchical Link" symbol:-0 An unhierarchical link is represented by a directed arc beginning anywhere within a class, and ending with the arrowhead pointing anywhere within another class, excepts for its top. There are two kinds of unhierarchical links: "inheritance" and "procedural constraint". SNAV - ODD specification E OBJECT DEPENDENCY DIAGRAM - DEFINITIONF - 13.8.90 page 9 - -1Unhierarchical links of the "Inheritance" type:-0 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ Inheritance is a directed 1:1 ³ ³ relationship, but, contrary ³ ³ ³ ³ with 1:1 hierarchies of the ³ d*³ ³d4 ³ declaration, pointing or ³ ÚÄÄÄÄÄÁÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÁÄÄÄÄÄÄ¿ ³ computing types, parent-child ³ ³super_class³ ÚÄ>³derived_class³ ³ roles are inverted. One ³ ÀÄÄÄÄÄÂÄÄÄÄÄÙ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ object of the parent class is ³ ³ ³ ³ included within the child ³ ÀÄÄÄÄÄÄÄÄÙ ³ class. The inclusion is ³ ³ implemented in a transparent ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ way. The parent's shell "melts", leaving its data and state variables and methods at the child's disposal (the child "inherits" them). The inheritance mechanism may be partially stopped, by methods being explicitly overridden by the child, and by both methods and data being explicitly hidden by the parent. The Inheritance link saves explicit inclusion, by declaration or pointing, and saves the need to prove the parent's existence, or to dereference its contents. Unhierarchical links of the "inheritance" type are represented by a solid arc. They differ from hierarchical links proper, by the position of their entry point. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ A special case of inheritance is ³ ³ "polymorphism", or inheritance from a ³ ³ ³ ³ generic class. it is defined by the ³ p*³<ùùùùùùùùùùùù³p* ³ following construct: the parent is ³ ÚÄÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÁ¿ ³ pointing in system, and the child ³ ³generic_class³ ÚÄ>³?³ ³ connects back to its parent, using ³ ÀÄÄÄÄÄÄÂÄÄÄÄÄÄÙ ³ ÀÄÙ ³ a "late binding" link (a dotted arrow ³ ³ ³ ³ connecting between the child's ³ ÀÄÄÄÄÄÄÄÄÄÙ ³ entry-point to the parent's ³ ³ entry-point. The child may be a ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ dummy, representing the whole derived genre, by having a question mark for name. Where the parent is of cardinality zero, it said to be an "abstract" class. Such class has no occurrences (objects allocated), and its sole purpose is to define the genre (in which case, it must have at least one late-binding link pointing to it, somewhere in the system). SNAV - ODD specification E OBJECT DEPENDENCY DIAGRAM - DEFINITIONF - 13.8.90 page 10 - -1Unhierarchical links of the "Procedural Constraint" type:-0 Also known as "triggered update", "update policy", "update logic", "derived update" and "existence constraint", in a number of commercially available database management systems and application generators. These tools have been invented to allow the database designer to supplement the inherent data model with links it does not support automatically. This kind of link is partly procedural, because it is usually implemented as some algorithm that draws upon timing or other unstructural ordering, and because its very existence is "triggered" by an event. But it is equally non-procedural, because its activation is beyond any programmed process's immediate control (though it may be "conditioned"). The non-procedurality of this programming technique becomes obvious when a chain of "derived updates" is created during run time. Even if this was carefully designed by a procedurally-minded programmer, another process can come and trigger it from the middle. the latter phenomenon has no parallel in the procedural world (and there, is likely to pass for a "bug"). Unhierarchical links which are used as dataflows implementing pieces of a grand algorithm are irrelevant for the data-model. But essential for the data-model are those derived accesses that implement structural constraints that, for some reason, may not be implemented with plain inclusion, reference and inheritance. For example, where part of the database must, at any time, duplicate another part (for example, inverted file structures), or where the existence of some object is a prerequisite for the allocation of another object (and it is not its child or inherited from it), or where some object "controls" the data within another object. The person maintaining the data-model must be notified of these constraints, or data integrity in the real database may be corrupted! SNAV - ODD specification E OBJECT DEPENDENCY DIAGRAM - DEFINITIONF - 13.8.90 page 11 - While implementing such constraints in a procedural environment is virtually impractical, in an Object-Oriented environment it is very natural, provided that strict data-hiding is practiced. Each derived access suggests a method, internal to the triggering object. Since all update is done through the class's front-end protocol, the correct method will be triggered by the constructor, destructor, or some front-end method invoked by the user. This topic summarizes ODD's contribution to the method design aspect of an objective software system. The rest of the protocol should be derived from a parallel procedural study (for example, DFD), or left for the coding level. Alternatively, special OD frames may be dedicated to document message flow involved with implementing a DFD "event" ([8]). ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ procedural constraint links ³ ³ may be of two types: ³ ³ ³ ³ "output", represented by the ³ p*³ p*³ ³ letter "o" along the arc, ³ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÄÄÁÄÄÄÄÄÄ¿ ³ (the default) and "input", ³ ùù³main_file³ ùù>³inverted_file³ ³ represented by the letter "i" ³ ù ÀÄÄÄÄÂÄÄÄÄÙ ù ÀÄÄÄÄÄÄÂÄÄÄÄÄÄÙ ³ along the arc. derived output ³ ù ³ ù ³ ³ means that any update ³ ù ³ ù ³ ³ (creation, modification or ³ ù p*³ ùùùùùù ³ ³ destruction) to the "source" ³ ù ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄ¿ ³ object may imply some update ³ ù ³main_data³ ùù>³primary_key³ ³ (creation, modification or ³ ù ÀÄÄÄÄÄÄÄÄÄÙ ù ÀÄÄÄÄÄÄÄÄÄÄÄÙ ³ destruction) to some object ³ ù ù ³ of the "target" class. ³ ùùùùùùùùùùùùùùùùù ³ Derived input represents a ³ ³ weaker link, to be kept to ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ the minimum. It means that when the source object is created, modified or destroyed, it may be influenced by the existence, inexistence or contents of some object of the target class. However, it has no way of knowing if the target will be modified or cease to exist later, resulting in poor data integrity. An OODBMS to support derived input integrity is yet to be invented. Unhierarchical links of the "procedural constraint" type are represented by a dotted arc. In case of "concatenated key", all source objects needed to locate the target must be identified, regardless of which of them owns the trigger. A stated elsewhere, this issue, as interseting as it may be), is an optional, partially supported aspect of the model. SNAV - ODD specification - 13.8.90 page 12 - EUSAGE CONVENTIONSF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF For presentation convenience, the OO database forest may be distributed among a number of "frames". The division and internal ordering have semantic meaning for the designer, but imply nothing about the structure of the database. One object may be references as many times as needed, in the overall presentation, again, implying nothing about database structure. Each tree in the frame maintains its own hierarchy, regardless of its indentation, if any, relative to the other trees. Roots are nodes that link to system, regardless of where placed. A OD frame consists of a forest of (one or more) class-trees. Each class-tree has one root and zero or more subtrees, etc.. The nodes of the trees, denoted by a square, represent datatypes, normally implemented as classes (on some rare occasions, what should be a class may decay into a simple datatype, e.g. integer). The hierarchy is top-down, with no importance to left-right order. OD classes need not (by definition) refer to hardware-supported datatypes. This practice may obscure the model's main puprpose as a design-level tool: helping the maintenance programmer locate the elements of the application's implementation, creating as little environmental harm as possible. over-documentation is methodologie's number one foe! Hierarchical links always point from the bottom of the parent class to the top of the child class. Any other link is unhierarchical. Each binary hierarchical link describes the fact that each object of the parent class is equipped to accommodate some objects of the lower class. The type of link of the entry to each tree denotes the normal way of referencing objects of these class. Inheritance is denoted by an unhierarchical link from superclass to child-class. Update constraints are denoted by dotted lines from source (triggering object) to target (object to be updated). Unhierarchical links to an object not within the current frame may end with a mention of its name. While a class may appear any number of times, its specification tree is expected to appear once, in what is perceived as the proper place (normally its root occurrence, but possible, as a subtree). Redundant specification interferes with maintenance! An OD frame should inlcude only major structural componenets, and avoid trivial conponents of "working storage" type. Such details, are part of the application on programming level, and indeed should be confined to that level. Object-Orientation does not usually call for programming level documnetation. SNAV - ODD specification - 13.8.90 page 13 - ELIMITATIONS OF THE MODELF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF ODD is a strongly data-driven model. It is poorly equipped to display dataflow and definitely not control-flow. Most OOP candidate applications are data driven. where the application has a strong procedural aspect, the designer must supplement it with a flow-oriented tool, such as DFD, flowchart, action-diagram or state-machine. The relationship between the views is essentially informal, as is the relationship between DFD and ER, for example, in the analysis stage. As usual with design-oriented tools, the OD model may force the programming-oriented designer to "invent" entities that do not seem to exist in his code, at least not in an immediate way. Pseudoclasses are a fine example. OD, like other true data-models, does not support multi-dimensional arrays. A matrix of objects must be broken to two arrays, with an pseudoclass invented in the middle. OD, like C++, does not support class-aggregation. In C++, one cannot use a generic parent-child aggregate to inherit a parallel parent-child aggregate, at least not in an explicit way. Some OO implementations (e.g. IBM's RM/MVS) support this. OD does not support all the structural constraints, implicit in the syntax of the programming language C++. For example, there are no facilities for presenting the subtleties suggestd by the following C++ keywords: "private", "protected", "public", "virtual", "friend", "const" and "volatile". OD is an experimental technique, based upon very limited experience with a limited kind of applications. I am awaiting user contributions to its syntax and usage. SNAV - ODD specification - 13.8.90 page 14 - ESNAV EXAMPLE #1F EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Objects of class "direction" are usually declared. The dataype's domain consists of 5 possible values. the domain of class "intersection" includes sixteen values. An object of class intersection is an ordered set of (at most) 5 directions. Since direction is uniquely identified by an integer key, the set is encoded into a single integer using bitwise arithmetic. From the user's standpoint, an object of class intersection virtually includes the (zero to four) direction objects (to be decoded by intersection's internal methods, during runtime). "Axis" is a special case of ("inherited" from) intersection, applying to two of its sixteen possible values. Class "weight_d(istribution)" has a domain of 16 values. Each weight_d object includes exactly two axis/wgt objects. Class "axis/wgt" inherits class axis. Objects of class axis/wgt are not normally referenced outside their weight_d context, so the class is not displayed at root level. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ³ ³ ³ ³ ³ ³ d5³ d16³ ³d2 ³d16 ³ ³ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÁÄÄÄ¿ ÚÄÄÄÁÄÄÄ¿ ÚÄÄÄÄÁÄÄÄ¿ ³ ³ ³direction³ ³inter- ³ ÚÄ>³ axis ³ ³weight_d³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ³section³ ³ ÀÄÄÄÂÄÄÄÙ ÀÄÄÄÄÂÄÄÄÙ ³ ³ ÀÄÄÄÂÄÄÄÙ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ÃÄÄÄÄÄÄÙ ³ ³ ³ ³ ³ ³ ³ ³ ³ c5³ ³ d2³ ³ ³ ÚÄÄÄÄÁÄÄÄÄ¿ ³ ÚÄÄÄÄÁÄÄÄ¿ ³ ³ ³direction³ ÀÄÄÄÄÄÄ>³ axis/ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ³ weight ³ ³ ³ ÀÄÄÄÄÄÄÄÄÙ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ SNAV - ODD specification E SNAV EXAMPLE #1F - 13.8.90 page 15 - Here is a possible (skeleton) implementation for example 1 (member functions reminded implement structure): ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ enum dirval { ³ ³ NO_DIR=0, RIGHT_DIR=1, UP_DIR=2, DOWN_DIR=4, LEFT_DIR=8 ³ ³ }; ³ ³ ³ ³ class direction { ³ ³ private: ³ ³ dirval where; ³ ³ ... ³ ³ } ³ ³ ³ ³ class intersection { ³ ³ private: ³ ³ int dirset; // bitwise managed direction-set ³ ³ public: ³ ³ direction get_first(void); ³ ³ direction get_next(direction ¤t); ³ ³ boolean append(direction &member); ³ ³ ... ³ ³ } ³ ³ ³ ³ class axis : public intersection { ³ ³ ... ³ ³ } ³ ³ ³ ³ class axis_wgt : public axis { ³ ³ private: ³ ³ int weight; ³ ³ ... ³ ³ } ³ ³ ³ ³ class weight_d { ³ ³ private: ³ ³ axis_wgt wgt[2]; ³ ³ ... ³ ³ } ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ SNAV - ODD specification - 13.8.90 page 16 - ESNAV EXAMPLE #2F EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Class "computer_alphabet" includes an array of "character"s, whose exact size is fixed during runtime. Each character is defined by an "intersection" and a "weight_d". Only the integer values of these objects are stored. It also manages an inverted file, consisting of an array of sixteen by sixteen integers, representing character collating-sequence values. The y-axis of the matrix is for encoded intersection value, and its x-axis is for encoded weight_d value. "Character" is implemented as plain integer. There is no character class at the moment. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ³ ³ ³ ³p* ³ ³ ÚÄÄÄÁÄÄÄÄ¿ ³ ³ ³computer³ ³ ³ ³alphabet³ ³ ³ ÀÄÄÄÂÄÄÄÄÙ ³ ³ ³ ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄ¿ ³ ³ d*³ c16³ ³ ³ ÚÄÁÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ³ ³ ùùùùùùùùùùùùùù³char³ ùùù>³intersection³ ³ ³ ù ÀÄÂÄÄÙ ù ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ù ùùùùùùùùùù³ùùùùùùùùùù ³ ³ ³ ù ù ÚÄÄÄÄÄÄÁÄÄÄÄÄ¿ ³ ³ ³ ù ù c³ c³ c16³ ³ ³ ù ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÁÄÄÄÄ¿ ³ ³ ù ³intersection³ ³weight_d³ùùù>³weight_d³ ³ ³ ù ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÙ ÀÄÄÄÂÄÄÄÄÙ ³ ³ ù ³ ³ ³ ù ³ ³ ³ ù ³ ³ ³ ù ÚÄÁÄÄ¿ ³ ³ ùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùù>³char³ ³ ³ ÀÄÄÄÄÙ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ SNAV - ODD specification E SNAV EXAMPLE #2F - 13.8.90 page 17 - Here is a possible (skeleton) implementation for example 2: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ class computer_alphabet { ³ ³ private: ³ ³ char *attribute_table; // dynamic 2-d array ³ ³ int cross_ref[16][16]; ³ ³ public: ³ ³ void allocate_table(int num_chars); ³ ³ intersection char_ints(int c); ³ ³ weight_d char_wgt(int c); ³ ³ char get_char(intersection &ints, weight_d &wgt); ³ ³ void put_char(int c, intersection &ints, ³ ³ weight_d &wgt); ³ ³ // updates both table and cross-ref ³ ³ ... ³ ³ } ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ SNAV - ODD specification - 13.8.90 page 18 - ESNAV EXAMPLE #3F EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF The abstract class "panel" includes one "point" object (cursor position), one "direction object" (cursor direction), two "color" objects (current and default pallets), and one "square_pos" object. An object of class "square_pos" determines window dimensions, by including two "point_pos" objects (top-left and bottom-right corners). As the number of occurrences indicates, "panel" is an abstract class, intended to be implemented by the user, suiting some specific device, using late binding. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ³ ³ ³ ³ p0³<ùùùùùùùùùùùùùùùùùùùùùù³p* ³ ³ ÚÄÄÁÄÄ¿ ÚÁ¿ ³ ³ ³panel³ ÚÄ>³?³ ³ ³ ÀÄÄÂÄÄÙ ³ ÀÄÙ ³ ³ ³ ³ ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÁÄÄÄÄÂÄÄÄÄÄÄÄÄÄÂÄÄÄÄÙ ³ ³ ³ ³ d2³ ³ ³ ³ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÁÄÄ¿ ÚÄÄÄÄÁÄÄÄÄÄ¿ ³ ³ ³point_pos³ ³direction³ ³color³ ³square_pos³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÙ ÀÄÄÄÄÂÄÄÄÄÄÙ ³ ³ ³ ³ ³ ³ ³ ³ d2³ ³ ³ ÚÄÄÄÄÁÄÄÄÄ¿ ³ ³ ³point_pos³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ SNAV - ODD specification E SNAV EXAMPLE #3F - 13.8.90 page 19 - Here is a possible (skeleton) implementation for example 3: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ class point_pos; ³ ³ class direction; ³ ³ class color; ³ ³ ³ ³ class square_pos { ³ ³ private: ³ ³ point_pos top_corner, bottom_corner; ³ ³ ... ³ ³ } ³ ³ ³ ³ class panel { ³ ³ private: ³ ³ point_pos cursor; ³ ³ direction cursor_direction; ³ ³ color default_color, current_color; ³ ³ square_pos window_dimensions; ³ ³ public: ³ ³ virtual void virtual_func(void)=0; ³ ³ ... ³ ³ } ³ ³ ³ ³ class my_panel : public panel { ³ ³ public: ³ ³ void virtual_func(void); ³ ³ ... ³ ³ } ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ SNAV - ODD specification - 13.8.90 page 20 - ESNAV EXAMPLE #4F EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Example for use of late-binding from within a structure. A "shape" may be used both as a proper object and as a generic one. it contains a linked-list of "strokes", where each points to exactly one object derived from abstract base class "shape_segment". ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ³ ³ ³ ³ p*³<ùùùùùùùùùù³p* ³ ³ ÚÄÄÁÄÄ¿ ÚÁ¿ ³ ³ ³shape³ ÚÄÄ>³?³ ³ ³ ÀÄÄÂÄÄÙ ³ ÀÄÙ ³ ³ ³ ³ ³ ³ ³ ÃÄÄÄÄÄÄÙ ³ ³ p0³<ùùùùùùùùùùùùù p*³ ³ ³ ÚÄÄÄÄÁÄÄÄÄ¿ ù ÚÄÄÄÁÄÄ¿ ³ ³ ³shape_seg³ ù ³stroke³ ³ ³ ÀÄÄÄÄÂÄÄÄÄÙ ù ÀÄÄÄÂÄÄÙ ³ ³ ³ ù ³ ³ ³ ÚÄÄÄÄÁÄÄÄÄÂÄÄÄÄÄ¿ ù ÚÄÄÄÁÄÄÄ¿ ³ ³ ³ p1³ ³ ù p1³ ³ ³ ³ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÁÄÄ¿ ³ ùùùÚÁ¿ ÚÄÄÄÄÁÄÄÄÄ¿ ³ ³ ³direction³ ³color³ ÀÄÄÄÄ>³?³ ³point_pos³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÙ ÀÄÙ ÀÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ SNAV - ODD specification - 13.8.90 page 21 - EOBJECT DEPENDENCY DIAGRAM - SYNTAX DEDINITIONF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF OD_MODEL ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ An Object-Dependency application model consists of one or more Object-Dependency diagrams. ÚÄÄÄ¿ ÄÂÄ>³ODDÃÄÄÂÄ> ³ ÀÄÄÄÙ ³ ³ ³ ÀÄÄÄÄ<ÄÄÄÄÙ ODD ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ An Object-Dependency Diagram is a (unified) collection of dependencies ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÄÂÄÂÄ>³HIERARCICAL DEPENDENCYÃÄÂÄÂÄ> ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ³ ³ ³ ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ÃÄÄÄÄÄÄ>³INHERITANCEÃÄÄÄÄÄÄÄ´ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ³ ³ ³ ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ÃÄÄÄÄÄÄ>³LATE BINDINGÃÄÄÄÄÄÄ´ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ³ ³ ³ ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ÀÄÄÄ>³UPDATE CONSTRAINTÃÄÄÄÄÙ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ<ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ HIERARCICAL_DEPENDENCY ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ A hierarchical dependency may involve either two or only one classes, and attributes. It is expressed by a non-directed arc, where parent is on top. ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÄÂÄ>³PARENT CLASSÃÄÂÄ>³CHILD CLASSÃÄ>³LINK_TYPEÃÄ>³LINK_CARDINALITYÃÄ> ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ÚÄÄÄÄÄÄ¿ ³ ÀÄÄÄÄ>³systemÃÄÄÄÄÙ ÀÄÄÄÄÄÄÙ SNAV - ODD specification E OBJECT DEPENDENCY DIAGRAM - SYNTAX DEDINITIONF - 13.8.90 page 22 - PARENT_CLASS ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÚÄÄÄÄÄ¿ Ä>³CLASSÃÄ> ÀÄÄÄÄÄÙ CHILD_CLASS ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÚÄÄÄÄÄ¿ Ä>³CLASSÃÄ> ÀÄÄÄÄÄÙ CLASS ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ A class may be either named or "anonymous" (expressed by '?'). ÚÄÄÄÄÄÄÄÄÄÄÄ¿ ÄÂÄÄÄ>³named_classÃÄÄÄÂÄ> ³ ÀÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ÀÄ>³anonimous_classÃÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ LINK_TYPE ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The link type is denoted by one of these letters: 'd' for declared, 'p' for pointed or 'c' for computed. The default is 'd'. ÚÄ¿ ÄÂÄ>³dÃÄÂÄ> ³ ÀÄÙ ³ ³ ³ ³ ÚÄ¿ ³ ÃÄ>³pÃÄ´ ³ ÀÄÙ ³ ³ ³ ³ ÚÄ¿ ³ ÀÄ>³cÃÄÙ ÀÄÙ SNAV - ODD specification E OBJECT DEPENDENCY DIAGRAM - SYNTAX DEDINITIONF - 13.8.90 page 23 - LINK_CARDINALITY ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The link cardinality is expressed by one of these digits, any number, or asterisk (for "indefinite"). 1 is the default. ÚÄ¿ ÄÂÄÄÄ>³0ÃÄÄÄÄÂÄ> ³ ÀÄÙ ³ ³ ³ ³ ÚÄ¿ ³ ÃÄÄÄ>³1ÃÄÄÄÄ´ ³ ÀÄÙ ³ ³ ³ ³ ÚÄÄÄÄÄÄ¿ ³ ÃÄ>³numberÃÄ´ ³ ÀÄÄÄÄÄÄÙ ³ ³ ³ ³ ÚÄ¿ ³ ÀÄÄÄ>³*ÃÄÄÄÄÙ ÀÄÙ INHERITANCE ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Inheritance involves one or more classes on the one side, and one class on the other. It is expressed by a directed arc. ÚÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÄÂÄ>³BASE CLASSÃÄÂÄ>³DERIVED CLASSÃÄ> ³ ÀÄÄÄÄÄÄÄÄÄÄÙ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ÀÄÄÄÄÄÄÄ<ÄÄÄÄÄÄÄÙ BASE_CLASS ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÚÄÄÄÄÄ¿ Ä>³CLASSÃÄ> ÀÄÄÄÄÄÙ DERIVED_CLASS ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÚÄÄÄÄÄ¿ Ä>³CLASSÃÄ> ÀÄÄÄÄÄÙ SNAV - ODD specification E OBJECT DEPENDENCY DIAGRAM - SYNTAX DEDINITIONF - 13.8.90 page 24 - LATE_BINDING ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Late binding involves two classes. It is expressed by a dotted directed arc. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄ¿ Ä>³DERIVED CLASSÃÄ>³BASE CLASSÃÄ> ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÙ UPDATE_CONSTRAINT ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Update constraint involve one or more source classes, one target class, and is adorned by type. ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÄÂÄ>³SOURCE CLASSÃÄÂÄ>³TARGET CLASSÃÄ>³CONSTRAINT TYPEÃÄ> ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ÀÄÄÄÄÄÄÄÄ<ÄÄÄÄÄÄÄÄÙ CONTRAINT_TYPE ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The update-constraint type is denoted by one of these letters: 'o' for output or 'i' for input. 'O' is the default. ÚÄ¿ ÄÂÄ>³oÃÄÂÄ> ³ ÀÄÙ ³ ³ ³ ³ ÚÄ¿ ³ ÀÄ>³iÃÄÙ ÀÄÙ SNAV - ODD specification - 13.8.90 page 25 - EBIBLIOGARPHYF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF 1. "Snav", currently version 1.21, is packed in a file called "SNAV12.ZIP" (the extension may vary), and is available on the following US Buletin Board Systems, at least: Compuserve, Bix, Exec-PC, GEnie. It may also be obtained from the author at "Avner Ben, 10 Dov-Hoz st., Tel-Aviv 63416, Israel", for $30. 2. "Sapiens - Concepts and Facilities", part of product documentation, obtained from "Software Craftsmen Inc.", New-York. 3. Timothy Budd, "A little Smalltalk", Addisson-Wessley 1987, chapter 1. 4. Dave Thomas, "What Is in an Object", Byte magazine, March 1989. 5. Peter Coad & Edward Yourdon, "Object Oriented Analysis", Yourdon Press & Prentice-Hall, 1990. 6. Henry Korth & Abraham Silbershatz, "Database System Concepts", McGraw-Hill, 1986, chapter 1. 7. Tom DeMarco, "Structured Analysis and System Specification", Yourdon Press & Prentice-Hall, 1978. 8. Edward Yourdon, "Modern Structured Analysis", Yourdon Press & Prentice-Hall, 1989. SNAV - ODD specification - 13.8.90 page 26 - version 1.01, 7.5.90. * added EBNF specification. version 1.20 3.8.90. * changed preface. version 1.21 13.8.90. * revised. * added source-code implementation examples. * added bibliography. * replaced EBNF with syntax diagrams.