Liren Large Software Subsidy 7

home *** CD-ROM | disk | FTP | other *** search

/ Liren Large Software Subsidy 7 / 07.iso / c / c100 / 1.ddi / SNAV0111.ZIP / NOTATION.PRN < prev next >

Wrap

Text File | 1990-04-16 | 41.3 KB | 650 lines

< the╔══╗╔══╗╔ ╔ ║ ╙╢ ╙╢ ║ █ ║ ║ ║ ╔═══╗ ╠═ ╔═══╗╔ ╔═══╗║ ╔ ╔═══╗╔ ╔═══╗╔ ╓─╖ ╔═══╗╔ ╔═╗╔═╗╔ ║ ║ ║ ║ ║ ║ ║ ╙╢ ║ ╙╢ ║ ║ ╙╢ ║ ╙╢ ║╓╜ ║ ╙╢ ║ ╙╢ ╙╢ ║ ║ ║┌╫───╜ ║ ┌╢ ║┌╢ ║ ║┌╢ ║┌╢ ║ ║║ ┌╢ ║ ║ ║ ║ ║ ║ ║│║ ╓─╢ │║ ╓╢│║ ╓╢ ║│║ ╓╢│║ ╓╢ ║║ │║ ╓╢ ║ ║ ║ ╜ ╨ ╙┘╚═══╝ ╚═╛╚═══╝╙┘╚═══╝╙─╨┘╚═══╝╙┘╚═══╝║┌╜╙─┘╚═══╝╙─╜ ╨ ║ ╓────╫┘ ║ ╓─────────────────────────────────────────╚════╝──────────────────╜ ╙─── architecture (software foundation) SNAV - ODD specification - 17.4.90 page 1 - ┌───────┐ ─────────>│ AVNER │ ─────────>│ BEN │──────> Software Engineering Method └───────┘ 10 Dov-Hoz st. Tel-Aviv 63416 Israel tel. 972-3-221535 ┌─────────────────────────────────────────────────┐ │ "The Screen NAVigator" │ │ │ │ ODD notation specification │ │ │ │ Version 1.00, April 1990. │ └─────────────────────────────────────────────────┘ Copyright (c) 1990 by Avner Ben. Written by Avner Ben 13 April 1990. SNAV - ODD specification - 17.4.90 page 2 - EABSTRACTF E───────────────────────────────────────────────────────────────────────F The following document specifies a graphic notation 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 - 17.4.90 page 3 - ECONTENTSF E───────────────────────────────────────────────────────────────────────F Abstract ..................................................2 Contents ..................................................3 ────────────────────────────────────────────────────────────── Preface ...................................................4 ODD and the structured life-cycle .........................5 ODD specification .........................................6 Usage conventions ........................................12 Limitations of the model .................................13 Examples .................................................14 SNAV - ODD specification - 17.4.90 page 4 - EPREFACEF E───────────────────────────────────────────────────────────────────────F I have developed this notation In conjunction with my "SNAV" C++ character-output driver. It is also inspired by my work in conjunction with the "Sapiens" application generator in particular, the hierarchical database model in general, and recently, the C++ programming language data-model. I have used it as a both specification and documentation tool. ODD 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 - 17.4.90 page 5 - EODD AND THE STRUCTURED LIFE-CYCLEF E───────────────────────────────────────────────────────────────────────F Software design tools like ODD facilitate what I perceive to be a "pragmatic" development life-cycle. The work consists of many rapid phases of "top-down" design (that is, "implementing" analysis into code), and "bottom-up" design ("re-engineering" analysis documents from code). This resembles "prototyping" more than conventional DP life-cycle. It fits better the nature of Object-Oriented programming, where both the complexity of the applications and the flexibility of the tools, make thorough preliminary analysis and structured design an impractical solution. Yet, we should not rush from here to the irresponsible conclusion, of proceeding without any method whatsoever. Of the traditional "life-cycle" phases, specified in many software-engineering texts, the professional software designer may find three to be of interest: system-analysis (user-requirements level), software design (operational specification level), and software implementation (writing code). Enterprenuring and maintenance, I find uninteresting. The ordering (analysis, design, implementation) represents timing, importance and degree of detail. There is supposed to be a unidirectional mapping, representing at each "level", a binary policy-to-implementation link. The time-ordering implies flatly that design may not start before analysis has come to a full-stop, and once implementation begins, the design team may go away. I suggest to accept the functional partitioning, with the exception of the time-ordering. In the end, the project library should have complete editions of each of the three needed documents. It is not useful to predetermine, from which publication one should start, or that once it has reached a complete form, it is never to be opened again. The three books serve different populations, and give complementary perspectives on the same reality, that is, the software design database. No mater where one starts, the three views must be up-to-date simultaneously. In analogy to software, any update made to the software-design database from one terminal, must have an instantaneous reflection in the images presented on the other two terminals, (if it has a mapping, and if it passes the resolution). In this timeless life-cycle hierarchy, the middle stage - design - becomes the most important. The whole effort depends on its ability to bridge between the two extreme models, yet without being too complex to manage. ODD is aimed as a middle tool in such design architecture, with ER on the one end and C++ header files on the other end. This applies, of course, to strongly data-driven applications, since it stresses the data model. Most important structural changes to the code may be easily reflected in the ODD, and most changes to the ODD may be easily reflected in the ER, and vice-versa. So the designer may always assess the strength of the design, on all three levels. SNAV - ODD specification - 17.4.90 page 6 - EOBJECT DEPENDENCY DIAGRAM - DEFINITIONF E───────────────────────────────────────────────────────────────────────F The ODD medium is useful for displaying all the important classes unique to a C++ application, where they are used, and the static links between them (inclusion, inheritance, etc.). It may also be used, to a lesser extent, to display dataflow between them, where that is used as a way for implementing structure. An ODD consists of the following symbols: -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 to which it is divided. -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. 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 - 17.4.90 page 7 - -1Specifying hierarchical link type:-0 There are three hierarchical-link types: "d" (for declared), "p" (for pointed) and "c" (for computed). A relationship of any other kind may not be specified as hierarchical. 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. The default type. -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, foreign key to an FMS, etc.). Represented by the letter p. -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, if the need occurs. The lifetime (and mere existence) of the virtual object is implementation dependant. Useful for keeping consistency with a higher-level design specification, and for optimizing performance-oriented software. -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 determines the maximum number of objects of this type in the whole of the system. Where the class has a unique key, the cardinality determines the size of the datatype's "domain" of values. 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. Such a class must also have a pointing link from system, and a derived class with an unhierarchical "polymorphic" link back to it. SNAV - ODD specification E OBJECT DEPENDENCY DIAGRAM - DEFINITIONF - 17.4.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. A cardinality greater than 1 is essentially implementation dependant. In a declared link it may suggest an array implementation. It may also represent the fact that there are some distinct variables of this datatype. The designer has to decide, in this case, wether to unify their representation. However, 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 sequential file implementation. We may expect the parent to act as an "iterator class" or "generator class". But it may also serve as a dynamic array implementation. Computed links are similar to declared links, in this respect. An indefinite cardinality may mean zero, one or any number of objects. It should be used when the link implements a generator or iterator class. In general, it should be used whenever the actual number is determined during run-time. (If the number of records in the file is known in advance, use it!). Note that cardinality may not be specified by variable or by formula! Optionally, cardinalities may be specified by range, (using a pair of numbers within brackets, divided by comma), and by approximation (using the symbols > < >= and <=). It is recommended 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 - 17.4.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. ┌────────────────────────────┐ 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, the child is │ │generic_class│ ┌─>│?│ │ pointing in system, and the child has │ └──────┬──────┘ │ └─┘ │ a special type of procedural │ │ │ │ constraint, pointing from 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. 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. SNAV - ODD specification E OBJECT DEPENDENCY DIAGRAM - DEFINITIONF - 17.4.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 is not built to support. 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 - 17.4.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. ┌─────────────────────────────────────┐ 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. An exceptional usage of the procedural constraint symbol, is to express polymorphic inheritance. SNAV - ODD specification - 17.4.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. The same object may repeated 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 ODD 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. 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 denoted by a letter 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 subtree is expected to appear once, in what is perceived as the proper place (normally its root occurrence). Redundant specifications may interfere with maintenance. SNAV - ODD specification - 17.4.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. However, if 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. Like any design-oriented tools, ODD 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. ODD, like other true data-models, does not support multi-dimensional arrays. A matrix of objects must be broken to two arrays, with an interim pseudoclass invented in the middle. ODD, 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. ODD 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 - 17.4.90 page 14 - EA GENERAL EXAMPLEF E───────────────────────────────────────────────────────────────────────F Objects of class A are usually declared by the user. There may be any number of them in the system. An object of class A physically includes one object of class A_CHILD_1. It has an integer equalling the internal value of an object-occurrence of class FOREIGN, which may be invoked when needed. B is an abstract class (zero occurrences), to be accessed by pointer. An object of this generic class points to a linked-list of B_CHILD objects. Class B_CHILD derives from class A. An update to class B_CHILD may imply a derived update to the A_CHILD_1 in its superclass. The anonymous class is some working case of the generic class B, declared by a pointer to the superclass. ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ │ d*│ p0│<∙∙∙∙∙∙∙∙│ │ │ ┌─┴─┐ ┌─┴─┐ ┌┴┐ │ │ │ a │ │ b │ ┌──>│?│ │ │ └─┬─┘ └─┬─┘ │ └─┘ │ │ │ │ │ │ │ ┌────┴─────┬────────┐ ├────┘ │ │ │ c│ │ p│ │ │ ┌────┴────┐ ┌───┴───┐ │ ┌───┴───┐ │ │ │a_child_1│ │foreign│ └────>│b_child│ │ │ └─────────┘ └───────┘ └───────┘ │ │ ^ ∙ │ │ ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ │ │ │ └─────────────────────────────────────────────────────────────────────┘ SNAV - ODD specification - 17.4.90 page 15 - ESNAV EXAMPLE #1F E───────────────────────────────────────────────────────────────────────F Objects of class "direction" may be safely declared. The domain includes four values. the domain of class "intersection" includes sixteen values. An object of class intersection is an ordered set of (at most) four 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 one axis/wgt object. 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. ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ │ │ d4│ d16│ │d2 │d16 │ │ ┌────┴────┐ ┌───┴───┐ ┌───┴───┐ ┌────┴───┐ │ │ │direction│ │inter- │ ┌─>│ axis │ │weight_d│ │ │ └─────────┘ │section│ │ └───┬───┘ └────┬───┘ │ │ └───┬───┘ │ │ │ │ │ │ │ │ │ │ │ ├──────┘ └──┐ │ │ │ │ │ │ │ │ c4│ │ │ │ │ ┌────┴────┐ │ ┌────┴───┐ │ │ │direction│ └───>│ axis/ │ │ │ └─────────┘ │ weight │ │ │ └────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘ SNAV - ODD specification - 17.4.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. ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │p* │ │ ┌───┴────┐ │ │ │computer│ │ │ │alphabet│ │ │ └───┬────┘ │ │ │ │ │ ┌──────────┴────────┐ │ │ d*│ c16│ │ │ ┌─┴──┐ ┌─────┴──────┐ │ │ ∙∙∙∙∙∙∙∙∙∙∙∙∙∙│char│ ∙∙∙>│intersection│ │ │ ∙ └─┬──┘ ∙ └────────────┘ │ │ ∙ ∙∙∙∙∙∙∙∙∙∙│∙∙∙∙∙∙∙∙∙∙ │ │ │ ∙ ∙ ┌──────┴─────┐ │ │ │ ∙ ∙ c│ c│ c16│ │ │ ∙ ┌─────┴──────┐ ┌───┴────┐ ┌───┴────┐ │ │ ∙ │intersection│ │weight_d│∙∙∙>│weight_d│ │ │ ∙ └────────────┘ └────────┘ └───┬────┘ │ │ ∙ │ │ │ ∙ │ │ │ ∙ │ │ │ ∙ ┌─┴──┐ │ │ ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙>│char│ │ │ └────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘ SNAV - ODD specification - 17.4.90 page 17 - 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 polymorphic inheritance. ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ p0│<∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙│p* │ │ ┌──┴──┐ ┌┴┐ │ │ │panel│ ┌─>│?│ │ │ └──┬──┘ │ └─┘ │ │ │ │ │ │ ┌───────────┬────┴────┬─────────┬────┘ │ │ │ │ d2│ │ │ │ ┌────┴────┐ ┌────┴────┐ ┌──┴──┐ ┌────┴─────┐ │ │ │point_pos│ │direction│ │color│ │square_pos│ │ │ └─────────┘ └─────────┘ └─────┘ └────┬─────┘ │ │ │ │ │ │ │ │ d2│ │ │ ┌────┴────┐ │ │ │point_pos│ │ │ └─────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘