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 / METAD.PRN < prev next >

Wrap

Text File | 1990-04-16 | 31.1 KB | 514 lines

< the╔══╗╔══╗╔ ╔ ║ ╙╢ ╙╢ ║ █ ║ ║ ║ ╔═══╗ ╠═ ╔═══╗╔ ╔═══╗║ ╔ ╔═══╗╔ ╔═══╗╔ ╓─╖ ╔═══╗╔ ╔═╗╔═╗╔ ║ ║ ║ ║ ║ ║ ║ ╙╢ ║ ╙╢ ║ ║ ╙╢ ║ ╙╢ ║╓╜ ║ ╙╢ ║ ╙╢ ╙╢ ║ ║ ║┌╫───╜ ║ ┌╢ ║┌╢ ║ ║┌╢ ║┌╢ ║ ║║ ┌╢ ║ ║ ║ ║ ║ ║ ║│║ ╓─╢ │║ ╓╢│║ ╓╢ ║│║ ╓╢│║ ╓╢ ║║ │║ ╓╢ ║ ║ ║ ╜ ╨ ╙┘╚═══╝ ╚═╛╚═══╝╙┘╚═══╝╙─╨┘╚═══╝╙┘╚═══╝║┌╜╙─┘╚═══╝╙─╜ ╨ ║ ╓────╫┘ ║ ╓─────────────────────────────────────────╚════╝──────────────────╜ ╙─── architecture (software foundation) metadiagram progress report #4 - 16.4.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 #4 │ │ │ └─────────────────────────────────────────────────┘ Copyright (c) 1990 by Avner Ben Written by Avner Ben 10 Dov-Hoz st., Tel-Aviv 63416, Israel, 16 April 1990. Original written 28.10.88. metadiagram progress report #4 - 16.4.90 page 2 - 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 #4 - 16.4.90 page 3 - 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 #4 - 16.4.90 page 4 - EBUSINESS PLANF E───────────────────────────────────────────────────────────────────────F This is the "big plan" behind the metadiagram project. This is the kind of system that I shall have, when the project is over. I have approached in two phases. 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, this will be replaced by a dedicated programming language. The whole system of the previous phase 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, as well. 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 specification documents may be produced to a high degree of presentation quality and analytic value, 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 redesigned, after disassembling the preceding commercial prototypes and analysing their logic. 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, and fitting different budgets. Obviously, the development period is to be measured in man-years, and calls for the help of more than one person, that is, myself. Entrepreneurs or organizations interested in investing in the project, are welcomed to contact at the address in page 1. metadiagram progress report #4 - 16.4.90 page 5 - 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 #4 - 16.4.90 page 6 - 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 #4 E OBJECT-ORIENTED ARCHITECTUREF - 16.4.90 page 7 - 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 #4 E OBJECT-ORIENTED ARCHITECTUREF - 16.4.90 page 8 - 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 │ a>=b ├──────┼─────┤ │ └─a<c───>c │ │ │ │ a<c │ c │ com──┤ ┌─┴──┐ ┌─┴──┐ ├──────┼──────┼─────┤ pare │ ┌─b>=c──>b │ │ │ │ │ │ b>=c │ b │ └─a<b──┤ a>=c a<c b>=c b<c │ a<b ├──────┼─────┤ └─b<c───>c │ │ │ │ │ │ b<c │ c │ V V V V └──────┴──────┴─────┘ -1max-0: a c b c Here is a scenario for a "walk-through" on the shape above: ┌─────────────────────────────────────────────────────────────────────┐ │ How do we find the biggest of three numbers? Let us call the │ │ first "a", the second "b" and the third "c". First, we compare a │ │ with b. There are two possibilities: either a is ge b, or the │ │ contrary (a lt b). Let us take the first branch (a ge b). There │ │ are two possibilities, each leading to a unique solution: when a │ │ is ge b, a is the biggest. When a is lt c, c is the biggest. So │ │ far for the first branch. Now, let us take the other branch. │ │ There are two possibilities in here too. When b is ge c, b is │ │ biggest. But when b is lt c, c is biggest. │ └─────────────────────────────────────────────────────────────────────┘ metadiagram progress report #4 E OBJECT-ORIENTED ARCHITECTUREF - 16.4.90 page 9 - Here is an example source code for a shape of Decision_Tree: ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ -\: │ │ a>=b\: │ │ a>=c \!a │ │ a<c \!c │ │ \. │ │ a<b\: │ │ b>=c \!b │ │ b<c \!c │ │ \. │ │ \. │ │ \" │ │ \" │ │ \" │ │ \"max │ │ │ └─────────────────────────────────────────────────────────────────────┘ Semigraphic listing produced for the above: ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ max │ │ │ │ ┌─a>=c──>a │ │ ┌─a>=b─┤ │ │ │ └─a<c───>c │ │ ─┤ │ │ │ ┌─b>=c──>b │ │ └─a<b──┤ │ │ └─b<c───>c │ │ │ └─────────────────────────────────────────────────────────────────────┘ metadiagram progress report #4 E OBJECT-ORIENTED ARCHITECTUREF - 16.4.90 page 10 - 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 │ │ │ │ │ │ │ └─a<c──>c │ │ ─┤ │ │ │ ┌─b>c──>b │ │ │ │ │ │ └─a<b──┼─b=c──>b │ │ │ │ │ └─b<c──>c │ │ │ └─────────────────────────────────────────────────────────────────────┘ Source text unparsed from the edited tree. ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ -\: │ │ a>=b\: │ │ a>c \!a │ │ a=c \!a │ │ a<c \!c │ │ \. │ │ a<b\: │ │ b>c \!b │ │ b=c \!b │ │ b<c \!c │ │ \. │ │ \. │ │ \" │ │ \" │ │ \" │ │ \"max │ │ │ └─────────────────────────────────────────────────────────────────────┘ metadiagram progress report #4 - 16.4.90 page 11 - EPROCEDURAL ARCHITECTUREF E───────────────────────────────────────────────────────────────────────F The first generation metadiagram product will include: * System shell, including stream i/o, parsing and full-screen editing facility. * Textual listing facility. * Textual WYSIWYG editor. * Textual ("ANSI animation) walk-through facility. * A standard shape library allowing to use it the for CASE application, complying with my Method. The "Textual" medium assumed by the first generation metadiagram product is character oriented graphics (non-proprtionally spaced), using the 255 characters of the IBM PC extended ASCII character set. This character set is to be adopted by the user to the appropriate machine's "newcode", where available. Only three visual attributes are used: boldface, underline and (console only) low-video. It will be implemented using the various software package primitives, such as "SNAV", written by me in the C++ programming language. metadiagram will be written in C++, to ensure both portability on all C and UNIX speaking machines, and the utilization of full-scale object-oriented programming, without loosing efficiency of execution. metadiagram progress report #4 - 16.4.90 page 12 - ETHE METADIAGRAM ARCHITECTURE - OVERALL VIEWF E───────────────────────────────────────────────────────────────────────F In the heart of metadiagram are so many shape objects. Each shape has a formal language for specification, supported by a parser for input, and unparser for output. The parser reads a sequential file and adds elements to the shape data structure. The Unparser reads elements from the data structure and adds the appropriate clauses to a sequential file. Any shape has one or more listers. the lister reads elements from the data structure and outputs a stream of text. This is intercepted by the lister of the primitive shape "text". It produces a sequential file, and supplies raw text-editting services, such as translating "TypeWriter Graphics" to semigraphics, and highlighting. The textual editor facility reads the shape's listing and displays the relevant "page". cursor is placed on the current element, telling its position from the address left there by the lister. The editor then receives commands from the user and translates them to shape operations, sent to the appropriate shape method. At the end of the editing session, the unparser may be called to save the shape on disk. ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ [SHAPE] SOURCE TEXT │ │ ───────────────────── │ │ │ ^ │ │ clause │ │ clause │ │ ┌──── 1 ────┐ read │ │ written ┌──── 2 ────┐ │ │ │ [shape] │<───────────┘ └────────────│ [shape] │ │ │ │ Parser │ │ Unparser │ │ │ │ │────┐ clause element ┌───>│ │ │ │ └───────────┘ │ added unparsed │ └───────────┘ │ │ V │ │ │ ************************ │ │ THE [SHAPE] OBJECT │ │ ************************ │ │ │ ^ │ ^ │ │ ┌──── 3 ────┐ │ element │ │ │ oper- ┌──── 5 ────┐ User │ │ │ Generic │ │ to │ │ │ ation │ Generic │<───Cmd │ │ │ [shape] │<───┘ list │ │ └───────│ 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. <EOF>