< theÉÍÍ»ÉÍÍ»É É º Ó¶ Ó¶ º Û º º º ÉÍÍÍ» ÌÍ ÉÍÍÍ»É ÉÍÍÍ»º É ÉÍÍÍ»É ÉÍÍÍ»É ÖÄ· ÉÍÍÍ»É ÉÍ»ÉÍ»É º º º º º º º Ó¶ º Ó¶ º º Ó¶ º Ó¶ ºÖ½ º Ó¶ º Ó¶ Ó¶ º º ºÚ×ÄÄĽ º Ú¶ ºÚ¶ º ºÚ¶ ºÚ¶ º ºº Ú¶ º º º º º º º³º ÖĶ ³º Ö¶³º Ö¶ º³º Ö¶³º Ö¶ ºº ³º Ö¶ º º º ½ Ð ÓÙÈÍÍͼ È;ÈÍÍͼÓÙÈÍÍͼÓÄÐÙÈÍÍͼÓÙÈÍÍͼºÚ½ÓÄÙÈÍÍͼÓĽ Ð º ÖÄÄÄÄ×Ù º ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÈÍÍÍͼÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄ architecture metadiagram progress report #5 - 13.8.90 page 1 - ÚÄÄÄÄÄÄÄ¿ ÄÄÄÄÄÄÄÄÄ>³ AVNER ³ ÄÄÄÄÄÄÄÄÄ>³ BEN ³ÄÄÄÄÄÄ> Software Engineering Method ÀÄÄÄÄÄÄÄÙ 10 Dov-Hoz st. Tel-Aviv 63416 Israel tel. 972-3-221535 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ METADIAGRAM ³ ³ (formerly SHAPES) ³ ³ Specification Document Management System ³ ³ ³ ³ progress report #5 ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Copyright (c) 1990 by Avner Ben Written by Avner Ben 10 Dov-Hoz st., Tel-Aviv 63416, Israel, 11 August 1990. Original written 28.10.88. metadiagram progress report #5 - 13.8.90 page 2 - EABSTRACTF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF "The Metadiagram Architecture" is a library of reusable C++ classes supporting the development of interactive semi-graphic data-entry an presentation applications. It is useful for designs that stress th data-model behind the diagram (hence the "meta" before the "diagram") are expresses whatever procedure is involved with it as a set o referential constraints and "triggers", and is capable of specifyin one or more unique traversal paths through it. The exact way th structure is going to be presented in, is of less importance (though w do not dismiss the point altogether). The underlying encapsulation o data-structure and triggered services ("object") should deliver all o its services to the user, regardless of the method of presentation. Although Metadiagram is primarily a developer's toolbox, some of its ke items will be available to non-proffessional users as so man stand-alone drawing tools, each demonstrating the usefulness of som model, such as tree-diagrams, syntax-diagrams, various network scheme etc. The metadiagram architecture consists of three levels. 1: the kernel library of primitive services. 2: various stand-alone models serving two purposes: stand-alone drawing/design tools, and building bricks for the next level. And 3: integrated environment level for software engineering. The partitioning is absolutely object-oriented and modular: It is possible to remain in a lower level, without acquiring the next one. My final goal is to replace all these facilities by a Metadiagram "language". For the time being, I am developing the grand-prototype in C++. Which in itself is no small task. metadiagram progress report #5 - 13.8.90 page 3 - EPREFACEF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF I have given the name "The metadiagram Architecture" to a software platform I have been developing for the last 7 years or so, in conjunction with a number of stand-alone documentation and CASE tools, mostly, for use in projects in which I have been involved. The current prototype (number 3) is written in C++. I believe I have gained enough experience with this sort of application, and have made a thorough enough analysis and design job, to offer a broad platform, for use by other programmers, who wish to develop their own specialized software specification environment. Currently, I have released only one module, "Snav", which is one of about 6 primitives needed as "software foundation". Snav is aimed at a very low-performance market - character graphics. While the idea of practicing CASE with character graphics may seem repulsive to sophisticated heavyweight users, the fact is that 99% of current software specification are completely textual, and incorporate character graphic charts of some sort. And then, I have gained enough experience with low-cost personal-computer based documentation, to persuade me that the real scope of character graphics is very large indeed, if one is aware of the limitations of the medium, and does not push it to what it can't do. But most important, the use of character graphics as the first output driver, has allowed me to concentrate on the main issues - analysing the data structures and processes involved with documenting and specifying software in general. Anyone with some experience in graphic drivers should be familiar with their tendency to take over the design process. When I am through with learning the problem, I will disconnect the simplistic driver used for the construction job, and replace it with a shining pixel-graphics or DTP driver, or whatever is in vogue with the hardware community at that time. I am doing all attempts to make ny design generic enough, to stand up to it. Besides, I would like these products to be inexpensive, and run on any hardware available. metadiagram progress report #5 - 13.8.90 page 4 - ETHE METADIAGRAM CONCEPTF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Let us assume that the purpose of software development methodology is to publish and maintain the library of books, involved with the software project. It should schedule these documents, censor their contents, regulate their format, correct their syntax, and so on. For further information, refer to my complete Method (available from a BBS near you, or on diskette. current version is entitled Bmethd13). ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ the essence of ÚÄÄÄÄÄÄÄÄÄ¿ ³ ³ the application ÄÄÄÄÄÄÄÄÄÄ>³ The Art ³ ³ ³ ³ of Prog-³ÄÄÄÄÄÄÄÄÄ> paper ³ ³ recycled paper ÄÄÄÄÄÄÄÄÄÄ>³ ramming ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Obviously, metadiagram belongs with those programming environments that are based on a single concept. In metadiagram, everything is document, and every document is a diagram. Let us call this diagram/document entity - a "Graphic-Model, (or simply "Shape"). metadiagram manages shapes. It enables their definition (metadiagrams), creating and modifying object occurrences of them, (diagrams) and packaging the combined result (document). All levels are "shapes", all following the very same logic, syntax and esthetics, and all managed by the same (recursive) software mechanism, on-line real-time, and regardless of the display medium. metadiagram progress report #5 - 13.8.90 page 5 - EBUSINESS PLANF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Metadiagram will be developed in two stages. In the first phase, will be marketed a specialized system with a predefined set of graphic models, addressing the CASE application, more or less, supporting the my Method, (a superstructure which complies with such industry standards as DFD and ER). This restricted model will have the full user interface and support environment, but will lack the "metadiagram" facility proper, that is, a facility for user-define graphic-models. This phase will be written in C++, marketed as C++ source code (that is, intended for professional programmers), with the "application programs" supplied as demo. In the second phase, it will be replaced by a dedicated programming language. The whole system will be rewritten in this language and marketed in source-code form, as a specialized application. This bottom-up policy ensures a pragmatic, goal-driven course of development, and enables the marketing of some useful product within a short term. The development effort should be covered by revenues from the first prototype product, after a relatively small initial investment. This policy also ensures that the design effort will be directed to the metadiagram goal, and will not be misled to packaging considerations, such as sophisticated graphics or hardware technology. The first phase will be gradual too. The first commercial prototype will be limited to plain text, with character graphics. I have made exhaustive exercises with this medium, on real-life projects, and have demonstrated that documents may be produced to an acceptable degree of presentation quality , with this medium, using the technology that I developed, namely Snav and the other primitives to come. Only when all principal problems concerning the metadiagram engine are solved, using this generic medium, will the more sophisticated (and common) interfaces be studied: pixel-graphics (either stand-alone or within an accepted environment), DTP, sound, etc. Finally, when all visual interface problems are understood, fixed and integrated into the metadiagram engine, will the whole system be re-engineered. This will be an entirely new product which will probably be slower and more expensive than its predecessors, and will not out-date them - the whole three generation product lines may be marketed in parallel, appealing to different markets. Entrepreneurs or organizations interested in investing in the project, may contact me at the address in page 1. Other possible services are modifying the standard models for integration in user applications (including commercial CASE, CAD or primarily non-graphic packages), where the user does not wish to bother with modifying the code personally. metadiagram progress report #5 - 13.8.90 page 6 - ESYNTACTICAL CONCEPTF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF metadiagram manages graphic-models, which may be either of the following: * "Documents", pointing to other shapes, each taking a page or more. E.g. a software subsystem procedural implementation specification document. * "Shapes" proper. Normally restricted to one printed page. E.g. ODD, ER, decision tree, DFD, structured English, EBNF. * "Primitive" shapes, used as building blocks for page-bound shapes. E.g. indented paragraph, box, arc. Metadiagram is not naturally fit for printing continuous text which does not suggest page boundaries. It is intended for use with formal, logically rigorous, precisely segmented documents, such as typically used by certain professionals, with software specification documents being the canonical example. It is definitely not a word processor (though it may be used as such, if you can produce a rigorous syntactic definition of the graphic-model "text", as you use it). Each shape is an autonomous unit, obeying its own internal logic and explicit syntax rules. metadiagram does not supply any means for cross-reference between distinct shapes. However, some shapes may manage indices to other page-delimited shapes, and some shapes, such as an index proper, contain nothing else. However, it is the user's responsibility to select the level to work with. Zooming, backtracking and continuation follow from metadiagram's recursive implementation. But it must be stressed that these may be practiced only within the syntax of predefined shapes! metadiagram progress report #5 - 13.8.90 page 7 - EOBJECT-ORIENTED ARCHITECTUREF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF metadiagram is a restricted form of "Object-Oriented design", as reflected by the following definition: A "graphic-model" is an object, made of all the following elements: * A fixed-format internal representation. We assume this to be implemented in the computer by a "dynamic data structure. For each internal representation occurrence there must be exactly one major scanning path, fixed by a predetermined algorithm. * A finite "editing protocol". Methods for creating, modifying and deleting the shape in whole or part, and navigating within it. E.g. add node to tree, locate next node, paste subtree. * A formal-language for specification. This consists of a syntax (top-down single-pass), expressed by the pair of methods "parser" and "unparser". Any internal representation occurrence, however complex, and no matter how conceived, is capable of being unparsed and then parsed, retaining the same shape occurrence. * A set of aesthetic conventions for listing, given a specific medium. Expressed by at least one "lister" method. There is no way of considering a shape occurrence as a whole, without invoking some lister, however trivial. E.g. the shape "decision tree" may have both a vertical and an horizontal lister. * A facility for "walk-through" over the above-mentioned "listing". A collection of paths for traversing the internal representation, as manifested with the listing, adding speculations on the content of nodes passed. E.g. DFD walk-through. * Zero or more "generators" which, given an internal representation occurrence, produce either an occurrence of another shape, or plain text. E.g. decision-tree to EBNF, pseudocode to Pascal, DND to program tree. metadiagram progress report #5 E OBJECT-ORIENTED ARCHITECTUREF - 13.8.90 page 8 - For example, let us assume a simple shape called "military notation". It may consist of: * An internal representation, consisting of a recursive dynamic data structure, where each element points at: * A paragraph of text (possibly, in itself, defined as a shape). * The next paragraph in the current level. * The first paragraph in a level to be indented under the current. * A parser, reading a text with embedded directives for: * Identifying the beginning and end of paragraphs. * Begin-level symbol. * End-level symbol. * Telling the paragraph's header from the rest of the text. * A lister, scanning the data structure, producing a text, which: * Is block-justified to a predefined line width. * Has levels indented appropriately. * Has level headers highlighted using a predefined printer attribute, and preceded by the level number. metadiagram progress report #5 E OBJECT-ORIENTED ARCHITECTUREF - 13.8.90 page 9 - Following are three textual listings made for one occurrence of the shape "decision tree". 1. horizontal 2. "vertical" 3. table compare ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄ¿ -1combination-0 -1max-0 ³ ³ combination ³ max ³ ÚÄÄÄÄÁÄÄÄÄÄ¿ ÃÄÄÄÄÄÄÂÄÄÄÄÄÄÅÄÄÄÄÄ´ ÚÄa>=cÄÄ>a ³ ³ ³ ³ a>=c ³ a ³ ÚÄa>=bÄ´ a>=b a=b ÃÄÄÄÄÄÄÅÄÄÄÄÄ´ ³ ÀÄac ³ ³ ³ ³ a=cÄÄ>b ³ ³ ³ ³ ³ ³ b>=c ³ b ³ ÀÄa=c a=c bc ³ ³ ³ ³ ³ ³ b=b\: ³ ³ a>=c \!a ³ ³ a=c \!b ³ ³ b=cÄÄ>a ³ ³ ÚÄa>=bÄ´ ³ ³ ³ ÀÄac ³ ³ Ä´ ³ ³ ³ ÚÄb>=cÄÄ>b ³ ³ ÀÄac ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ metadiagram progress report #5 E OBJECT-ORIENTED ARCHITECTUREF - 13.8.90 page 11 - The tree above, after the following tree editor commands: root goto next goto next rename a>c insert down a=c insert next a down 2 rename b>c insert down b=c insert next b ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ max ³ ³ ³ ³ ÚÄa>cÄÄ>a ³ ³ ³ ³ ³ ÚÄa>=bÄÅÄa=cÄÄ>a ³ ³ ³ ³ ³ ³ ³ ÀÄac ³ ³ Ä´ ³ ³ ³ ÚÄb>cÄÄ>b ³ ³ ³ ³ ³ ³ ÀÄab ³ ³ ³ ³ ³ ÀÄbc ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Source text unparsed from the edited tree. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ -\: ³ ³ a>=b\: ³ ³ a>c \!a ³ ³ a=c \!a ³ ³ ac \!b ³ ³ b=c \!b ³ ³ b³ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÙ ³ added unparsed ³ ÀÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ V ³ ³ ³ ************************ ³ ³ THE [SHAPE] OBJECT ³ ³ ************************ ³ ³ ³ ^ ³ ^ ³ ³ ÚÄÄÄÄ 3 ÄÄÄÄ¿ ³ element ³ ³ ³ oper- ÚÄÄÄÄ 5 ÄÄÄÄ¿ User ³ ³ ³ Generic ³ ³ to ³ ³ ³ ation ³ Generic ³<ÄÄÄCmd ³ ³ ³ [shape] ³<ÄÄÄÙ list ³ ³ ÀÄÄÄÄÄÄij Editor & ³ ³ ³ ³ Lister ³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄ>³ Walkthru ³ÄÄÄ>list ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÙ pos listed pos cursor ÀÄÄÄÄÄÄÄÄÄÄÄÙ page ³ ³ ³ ³ ^ ³ ³ ³ ³ ³ ³ ³ ³ ³ disp.line ÚÄÄÄÄ 4 ÄÄÄÄ¿ disp. ³ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄ>³ Generic ³ line ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ ³ ³ text directive ³ Text ³ÄÄÄÄÄÄ> [SHAPE] PRINTOUT ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ>³ Lister ³ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ An ANSI animation walk-through for the above DFD is available in the file "lecture.bat", in the Method pack.