RJLRef: $PH/06s524/bdeschemarevs060321.txt This is a new start on moving the revised data model for bde toward GENcpp and LCP. The aim is four-fold: 1. Generalize bde.sch by adding generic superclasses and method inheritance. 2. Augment bde.sch with LCP/SM tables to control *ops.cc method STD's. 3. Replace structs with classes to build bde with gencpp not chgen. 4. Replace bde's current graphobject hierarchy with bde.sch classes. The example discussed below is text rendering, for which shared code was already develeoped as part of an earlier 'bdesym' project. (Bdesym was an offshoot that was never merged back into the main branch of bde.) Exactly the same concept can be applied to the rendering of shape components for graphic node/caption borders and directed segmented links. Design Decision 1: Method or data inheritance? ----------------------------------------------- One design decision to be made is whether new superclass objects should be state-less singletons, or should contain data and/or control 'state' attributes that are specific to each object instance. For example, every HA, GX and HI object currently contains a text string. The textblock (XB) superclass might have extensive data state: bdesym superclass objects 'tokenized' their text strings into a child-set of token (TK) objects, which contained fkeys SYid that referenced unique 'words' in a SymbolDictionary SD container for symbols SY. The TK objects provide a cross-reference between SYmbols and their references on the displayed diagram context. For shape (border and link) objects, the superclass might be virtual and stateless, supporting only method, not data, inheritance. I expect multiple shape subclasses for HN and CG border shapes, and at least one polyline subclass for segmented internode links, athough future subclasses could be added for curve-fitted links. (Bezier and spline options were available in the initial GKS (pre-X11) version of bde). Design Decision 2: Data compatibility during refactoring? --------------------------------------------------------- Two levels of compatibility can be envisioned during refactoring, depending on whether old diagram files must be converted to a new schema format or not. Level L1: Changes that do NOT require upgrades to current bde.dat file tables. These preserve upward compatibility: Files in the old bde.dat format can be parsed by pr_util if the old schema is a proper subset of the new one. 'Proper subset' requires careful definition: old tables can not have any field changes, additions or deletions. THis precludes adding any fkeys (links to superclass or aggregate parents) to old tables retained in the revised data model. However, it does not prevent adding aggregate relations to new child-types or adding new subclasses to existing table types: any new fkeys only appear in new tables, and chgen [or gencpp?] takes care of adding embedded list structures and managing them for navigation purposes. Level L2: Changes to the schema that DO require converting old .dat file tables. These require old data file conversion from old to new data model format, because the new pr_util library will not be able to parse old data files. [However, dual old and new formats might be able to co-exist as subelasses in the schema, if GEN is extended to deal with them as alternate options, or possibly as co-existent 'ghost variable' pairs. This second design decision must decide if bde refactoring should preserve data compatibility at level L1 or forego it at level L2. For example, L1 requires creating new binary associations BELOW existing tables, to link them to the text superclass from which they inherit methods. Then old bde .dat files will not require any changes except new navigation paths for method invocation. In contrast, L2 requires conversion of existing bde .dat files which are not upward-compatible. The use of delegation is assumed at both L1 and L2. For example, text editing and display methods (currently in textops.cc) are now specialized for the HA, HI and GX children of current HN, HL and CG parent classes. Suppose an fkey to a new teXtBlock (XB) superclass (as introduced in bdesym) is added to these child classes (or new parallel ones). Then the methods in textops.cc can become generic shared methods of the superclass. With L1, this is not a direct superclass (e.g., of HN or HI), but the superclass of a 'delegate' child object with a HNid or HAid fkey to its parent HN or HA. With L2, it CAN be a direct superclass since HN or HA can have a new XBid fkey (its is_key meta-attribute value is 's', not '1') Although L1 requires introducing new redundant classes for these associations in parallel with, not merged into existing HA, HI and CG classes, such redundancy may be worth it, because: (1) Two-way conversion between existing and new views of the text may facilitate temporary use of the XB approach solely on the GUI side of bde's data model. (2) Persistent storage might retain the HN node's current aggregate of HA-children, and similarly for HL's HI-child-set and CG's GX-child-set. Especially for log/replay and Distributed BDE, two-way cross-updating is necessary. This would be a 'classic' use of the ghost-variable concept for replicated graphic database maintenance. At the cost of level L2 revisions, we can augment the current HA, HI and GX objects by adding an XBid fkey to the XB superclass. This breaks compatibility with current bde .dat files that have no such XBid fkey . L2 adds foreign keys to existing bde tables. This makes the new data model appear simpler and more traditional, but old and new tables are more tightly coupled, and current .dat files will not be upward compatibile after schema file changes. This problem can be avoided by The value of either method may depend on whether converters to translate old .dat files are auto-generatable, e.g. by applying Martin Ward's ghost-variables approach http://www.cs.uml.edu/~lechner/ghostvarsRev3 . 1. Add generic superclasses and method inheritance: ------------------------------------------------- This involves 2 parts: 1.1 Text management: ---------------------- The teXtBlock XB class (from the BDESYM project) is a superclass from which text-carrying components on block diagrams can inherit their input, editing and rendering methods. This could adapt BDESYM's existing symbol and token table enhancements; it might also replace bde's current text entry dialog boxes by alternate copy/paste methods that use conventional text editors. Exiting bde classes that should inherit from XB include HN node and CG caption. This requires adding an XBid fkey in current or new tables. The HI link identifier class could also inherit from XB, particularly for STDs which need label text [anchor refs?] on their links. ERD links only need multiplicity and role labels associated with link endpoints (and possibly relation name labels associated with an intermediate bendpt). Current HI labels are associated with the link HL, not the bendpt HP. This requires more complex changes to bde/src/*ops.cc. 1.2 Shape management: ----------------------- Alternate shape style attributes for HN and CG borders are currently controlled by a shape character field (field type C1). To permit varying the line width and pattern, shapecode should become a 4-byte char string similar to the hsegpattern field of bendpt HP. Fill attributes might also be added, such as color and shading. Bendpt restyling options: HP has a few alternate choices for next-line- segment pattern and width, and an 'Arrow style' (direction or multiplicity indicator) at the HP. There are also two unimplemented attributes: a curve-fitting style (alternates to straight-line drawing)A 4th byte is reserved for an optional color. The Bendpt Restyle menu choice has a popup menu for selecting one of these attributes, whose value cycles thru its possibilities. HP Arrow style rendering is by far the most complicated: There are currently 3 options: head, tail or none. Rendering is complicated by the orientation and tangential offset computations that depend on the start, intermediate, or end position of the HP on the link. These should also depend on a default diagram type or style, a TBD attribute of its parent diagram (HG object). Node and Caption 'Shape restyling' options: There is no reason why line width and pattern and coclor cannot be applied to HN and CG borders as well. A Shape superclass would permit this. The Arrow style option of HP could Shape style 2. Introduce LCP State Model Interpretation: The Hominid project used LCP architecture, to generate a logfile to replay in bde. Control state and event instance logging projects were 'done' and need to be integrated within bde. Some methods in bde/src/*ops.cc files have state diagram labels embedded in comments, and a non-OO state model architecure. State actions are inlined as case blocks within switch(state) and nested switch(button_event) statements. Mapping current bde code organization into an LCP-like state model control database for bde graphic editing transactions is relatively simple. The hardest part is to redefine switch case blocks as callable C++ action routines. This is complicated by the complexity of guard conditions that mediate between primitive button_event types and OO_menu abstractions. For example, a sequence of Node Move steps requires consistent and valid node object selection by an unpredictable user. The button_move event only supplies mouse position. Guard conditions must test if the proper drawing element contains , and state actions must convert mouse motion into functions that actually move (erase and redraw) a particular object's shape and text. 3. Replace chgen by gencpp: (TBD) 4. Replace the graphobject class hierarchy with gencpp classes: (TBD)