RJLRef: //www.../~lechner/02sBDCProject.htm RJL 020119,

Dell C:\ MyDoc's\02s522-592BDCProject.{txt,htm} - RJL 020117 Rev.020124

1. Block Diagram Converter (BDC) Project Goal for 02s523/592:

The proposed goal is to implement a menu-based non-graphic application called BDC (Block Diagram converter) that includes the following features:

(1) extracts all non-X11-dependent FILE/SAVE_AS code from bde/src, starting with fprint.cc and then conversion to .gif format for web display (this option uses from bde/extern_code program files).

(2) adds other existing but separate converter programs: bde2sch or bde2ttta, bde2std or bde2SM, bde2htm or bde2gif.

(3) adds new options such as bde2xml, and bde2pdf (which calls utility ps2pdf).

(4) provides both X11 and WinTel GUI with a FILE/SAVE_AS menu for non-graphic bde conversion options.

(5) All input is from existing bde output files (*.dat, to be renamed *.bde).

(6) 99% of BDC reuses existing code from bde, bde2vcpp and/or bde2java; the rest integrates it within one application.

(7) BDE could later be re-merged into BDC (by restoring graphic method calls and OO-Menus to BDC), after BDC shows us how to encapsulate BDE's X11-dependence.

(8) BDE's current FILE/SAVE_AS option list could be extended to include these converters. However, this should be done in a completely portable way:

(8A) We could rewrite existing converters in Java, using existing bde2java versions of pr_parse and pr_load. Java wrappers could also call the existing C-based converters. Since this gives up web accessibility, I prefer (8B) below which re-uses bde/sc/*.cc code and bde/pr_util support from genv11.

(8B) We could reuse bde/src/*.cc code, moving its X11-dependent modules to one set of subclass wrappers and add bde2vcpp/src/*.cpp code in another set of subclass wrappers to implement the same menu options for MSWindows.

In (8B), current bde/src/*.cc files for menu setup and dialog could become one set of subclasses, and the bde2vcpp menu files provide an alternate set, with conditional compilation of one or the other. Two platform versions must be built and tested one at a time. The double maintenance problem still exists but is contained within one set of source code files.

[(Added 020124): To clarify the challenge after #8 below): It is even more important if you consider what it will take to bring BACK all the X11-dependent graphic code, into the new non-grpahic BDC version. Basically I envision WRAPPING all theX11-dependent declarations inside of a X11.h interface file, which is conditionally [#ifdef XWIN) #included ONLY in the new WRAPPER file; GUI.h; the latter should declare Xwindows-independent. interfaces. ALL OTHER BDE code modules will invoke with arguments that do NOT depend on X or MS GUI specializations.]

The challenge in (8B) is to segregate the X11-dependent graphic and menu code, so it can be hidden in subclasses. Current bde/src/*.cc and bde/include/*.h code has many isolated X11-dependencies that need to be moved between call-graph layers to segregate it.

2. Examples of BDE Dependence on X11 menu and graphic support:

Examples of X11-dependence in BDE were encountered in 01f522 projects bde2 and bde3. In 01f522, project bde2 refactored smselect.cc to bdeState.cc for state-event-based flow-of-control and trace logging; project bde3 added an X11-event table to the bde schema. By copying mouse event instance data to this table, state model behavior could be logged using bde/pr_util/pr_log.c from genv11. The X11-dependent services were few in number and could be moved to another location where X11 service calls were clustered.

Examples of BDE's graphic dependence include use of the graphic display list as the source of data which fprint.cc converts to PostScript output. Bde converts one selected diagram to this display list format to render it on the canvas drawing window. This conversion process involves coordinate conversion WCDC (and LCWC for bendpoints only), where WC, DC and LC are world, device and link coordinates respectively. The X11-dependent draw() methods are called while traversing the converted display list. Fprint.cc traverses the same list. The advantage is code reuse since device coordinates (integer pixels) are the proper ones for converting to PostScript.

3. Relevant chapters of Eliens: POOSD (02s592 text):

Eliens presents a more abstract way to apply OOP languages than the COOL framework does. COOL (so far) is a self-contained single-user system; BDE inherits only its (X11-based) GUI methods. However, BDE uses COOL/GEN for database code generation, and state models to document transaction behavior; these are not part of Eliens' examples. Eliens builds on his 'hush' Tcl/Tk class library which provides graphic support and on his 'crush' method wrappers to interface CORBA support libraries for distributed applications.

The first three chapters of Eliens provide his unique perspective on OO SW Engineering, which are background for his case studies in Chapters 4 and 6. These examples provide an alternate perspective on our COOL framework by reusing his Tcl/Tk hush framework alone in Ch.4 then with CORBA wrappers for distributed multi-user application in Ch.6.

Eliens Chapter 4 provides a (toy) case study 'drawtool' application that uses TCL/TK scripting language to draw boxes, circles and arrows Note: drawtool has no text capture, size or shape editing, node-link attachment and connectivity preservation, no generic code generation support and no persistent RDB, so it is not suitable for COOL framework use. [Refs: For hush's framework basis, see Eliens: Hush - A C++ API for Tcl/Tk, The X Resource 14 April 1995 (111-155); for Tcl/Tk, see Osterhout: Tcl and Tk Toolkit, A-W 1994].

Eliens Chapter 6 discusses distributed systems using components, and his 'crush' example uses CORBA/IDL interfaces and wrappers to extend hush to remote distributed users (as in COOL/Distributed BDE). His Chapter 11.4 Visualization Support is also relevant to DBDE. His Chapter 12 Web Applications discusses his DejaVu project for 'jamming on the web' (distributed collaborative jazz performance). Although this could not be done synchronously in real time due to bandwidth constraints, DBDE has much smaller bandwidth requirements.

Eliens' Chapter 5.5 (Meta-level Architectures) is related to the self-describing or reflective features of chgen's SV-->TT-->TA table description hierarchy. His Chapter 10 (Behavioral Refinement), especially Section 10.5 on specifying behavioral composition, surveys alternate approaches including 'joint action systems' which seems closest to the COOL/LCP state model database and event-dispatching interpreter.

Jezequel et al: Design Patterns and Contracts, A-W 2000: Chapter 6 describes his Mercure project, which uses subclassing to achieve platform-independent software configuration management (SCM). This includes alternate Windows GUI's. Platform-specific subclass choices are made at compile time. It is based on his 1998 ICSE paper.