< theÉÍÍ»ÉÍÍ»É É º Ó¶ Ó¶ º Û º º º ÉÍÍÍ» ÌÍ ÉÍÍÍ»É ÉÍÍÍ»º É ÉÍÍÍ»É ÉÍÍÍ»É ÖÄ· ÉÍÍÍ»É ÉÍ»ÉÍ»É º º º º º º º Ó¶ º Ó¶ º º Ó¶ º Ó¶ ºÖ½ º Ó¶ º Ó¶ Ó¶ º º ºÚ×ÄÄĽ º Ú¶ ºÚ¶ º ºÚ¶ ºÚ¶ º ºº Ú¶ º º º º º º º³º ÖĶ ³º Ö¶³º Ö¶ º³º Ö¶³º Ö¶ ºº ³º Ö¶ º º º ½ Ð ÓÙÈÍÍͼ È;ÈÍÍͼÓÙÈÍÍͼÓÄÐÙÈÍÍͼÓÙÈÍÍͼºÚ½ÓÄÙÈÍÍͼÓĽ Ð º ÖÄÄÄÄ×Ù º ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÈÍÍÍͼÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄ architecture (kernel) SNAV - data model - 4.8.90 page 1 - ÚÄÄÄÄÄÄÄ¿ ÄÄÄÄÄÄÄÄÄ>³ AVNER ³ ÄÄÄÄÄÄÄÄÄ>³ BEN ³ÄÄÄÄÄÄ> Software Engineering Method ÀÄÄÄÄÄÄÄÙ 10 Dov-Hoz st. Tel-Aviv 63416 Israel tel. 972-3-221535 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ "The Screen NAVigator" ³ ³ ³ ³ DATA MODEL DESCRIPTION ³ ³ ³ ³ Version 1.20, Ausgust 1990. ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Copyright (c) 1990 by Avner Ben. Written by Avner Ben 13 April 1990. SNAV - data model - 4.8.90 page 2 - ENOTATIONF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF the following specification makes extensive use of Entity-Relationship diagrams (ER). The ER notation follows the one used by IBM in the Repository-Manager/MVS ER DDL. My usage of this notation has nothing to do with that specific software product. I have simply found the particular data model a convenient basis for the type of transformation suggested by OOD in general, and the logic of my MetaDiagram system in particular. (See IBM Corporation's RM/MVS documentation for syntax specification). I have used the ER model described below as a "logical specification", from which I decomposed the working data model, using a private notation that I call Object-Dependency Diagram (ODD). For syntax specification, refer to file "notation.prn". The method I used for the decomposition is similar to decomposing an hierarchical database model from a conventional ER. The following document describes only the abstract data model. The decomposition is reserved for a more thorough document. For the resulting operational model, refer to file "snav.prn" and the source code. SNAV - data model - 4.8.90 page 3 - ETHE SNAV ABSTRACT DATA MODELF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF The diagram below displays an overall view of the "entities" taking an essential part in the SNAV system, and the important "relationships", in which they play a role. This is a conceptual view. The real system (to be discussed later) is somewhat more detailed. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ÚÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³DIRECTION³ ³ ³ ³ value ³ ³ ³ ³ name ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ³ ³ m^M ³ ³ set of ³ (in) ³ ³ ³ ³ ³ m³M ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ divides ÚÄÄÄÄÄÄ¿ ³ ³ ³COMPUTER_ALPHABET³ ³INTERSECTION³1 space_on 1³AXIS ³ ³ ³ ³ name ³ ³ value ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ>³ value³ ³ ³ ³ num_chars ³ ³ meaning ³M (defined_by) ³ name ³ ³ ³ ÀÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÂÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÙ ³ ³ m³ m³ ³ ³ ³ (included ³ ³ ³ ³ includes ³ in) has ³ (makes ³ ³ ³ ³ ³ visible) ³ ³ ³ ³1 is_semigraphic 1³1 distributed on ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ>ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ³ (plots) ³ ³ mVO mV ³ ³ ÚÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄ¿ ³ ³ ³CHARACTER³ ³WEIGHT³ ³ ³ ³ ³ ³ width³ ³ ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÙ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ The SNAV system is a character-oriented formatted-output driver, where graphics is restricted to character-graphics. The overall package supplies two kinds of services: pattern drawing and pattern recognition. Most of this early release is dedicated to the first service. The latter is currently supplied in rudimentary form. the majority of the software, however, is dedicated to primitives, used by both services. There is no unique projecting logic and unique scanning logic. Both services draw their power from different combinations of the same toolkit of primitives. Snav's graphics are essentially vector-graphics. That is, shapes are generated by cursor in motion. There is no such thing as drawing an oblong between four points. What Snav does is putting the cursor at some corner, and then moving in some direction, leaving a trail of pixels, changing directions at each corner. That means, that everything on the output panel must either be capable of generating motion - called "semigraphic" - or is ignored. When the line visits a cell which is already in motion, "welding" of lines will occur. \e This complex notion has been implemented as a database, in the following general way: some characters of the alphabet have a dual SNAV - data model E THE SNAV ABSTRACT DATA MODELF - 4.8.90 page 4 - meaning: they are also serve as "semigraphic". Such a character may also be considered as a discrete graphic element. A semigraphic is associated with an "intersection" - a set of one or more "directions" on the plain. A semigraphic is also associated with a "weight". Weight is distributed on the two axes (dimensions) of the plain (SNAV assumes weight to be uniform over an axis!). An axis may be reduced to a private case of intersection, simplifying the design somewhat. All in all, we can see a division between two subsystems: the right half of the diagram, dealing with the abstract notion of "character geometry", and the left half, dealing with the application of the former to the concrete world of character drawing. The first topic is treated by the code in "snav0", and the second, by "snav1". The entities in "snav2' and "snav3" are not represented in the model above. following is an account of the entities involved: SNAV - data model E THE SNAV ABSTRACT DATA MODELF - 4.8.90 page 5 - DIRECTION(-1dirval-0,dirname). Answers the question "which way are we going?". A point on the output panel is of interest to Snav, only if the group of pixels currently occupying it "connects" in (at least) some direction. Such a graphic element has the potential to unite with the neighboring cell, if that connects in exactly the opposite direction. When a number of semigraphic elements happen to be adjacent, and they connect in the proper directions, a semigraphic shape emerges to the eye. Obviously, the management of directions is a key issue in Snav. A direction is recognized by integer value, and has a name. The domain of names include exactly 5 values: "Right", "Up", "Down" and "Left" and the null direction (added to recognize non-semigraphic characters). The entity is addressed by enumerated key rather than by name, to facilitate efficient grouping by "intersection" (see below). The set of values is ordered, not only for the same reason, but also to acknowledge what seems to me like a "natural" priority for scanning semigraphic shapes, based upon some experience with simple animation. INTERSECTIONS(-1intval-0,intmean). Intersection is simply an ordered set of directions. Its purpose is to represent the motion part of a semigraphic. "These are the directions we can move in from here". An intersection is addressed by an integer value, computed by bitwise OR'ing of the directions included. This saves the need to physically store the directions in the implementation of intersection, and also gives it a unique key. The 4 directions of the plain make for 16 values of intersection, to which is added the null intersection. These may be grouped according to intersection type, or "meaning": "arrows" have one direction, "corners" and "dashes" have two directions, "forks" have three directions, and the "cross" has all the four directions. WEIGHTS(-1width-0). A weight is an integer value, associated with an intersection, to create a semigraphic. Where the intersection determines the symbol's function, the weights (there may be a number of them) make it visible. Each weight, associated with an intersection, must also be associated with an axis. Since there at most two of these on the plane, then a planar semigraphic may have at most two weights. The values used for weight are 0-3. 1 and 2 mean exactly that (single and double line). 3 is used for the "full" thickness line. 0 is used for "TypeWriter-Graphics" - course semigraphics, using simple characters. AXIS(-1intval-0,axval,axname). Character weight is associated with the two axes of the plane, respectively. The Axis may be reduced to private case of ("inherited" from) intersection. "Horizontal" (or "y") is a special case of the intersection {Right,Left}, and "Vertical" (or "x") is a case of {Up,Down}. Note that the relationship between intersection and axis does not necessarily apply to same occurrence as the transitive relationship between intersection and weight and (then) axis. SNAV - data model E THE SNAV ABSTRACT DATA MODELF - 4.8.90 page 6 - COMPUTER_ALPHABET(-1name-0,numchars) A computer alphabet consists of an ordered set of characters. Some characters in the current alphabet may become semigraphic, by being associated with some intersection and a set of weights (one axis at a time). We require to know the maximum number of characters in advance, and we do not expect it to change afterwards. CHARACTER(-1charname-0). The character, in Snav, is a decadent entity. Actually, Snav does not even store the character's name, or any other qualities. The reason for this is that Snav does not actually generate characters. It counts on the host device to do that, supplied with the character's serial number within the current alphabet ("collating sequence", "code-set"). It is retained in the design document, for vendors of pixel-oriented graphics to elaborate on. SNAV - data model - 4.8.90 page 7 - ETHE OPERATIONAL DATA MODELF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF The working data model, on ER level, retains much of the conceptual model, with two minor extensions: the transitive relationship between intersection and weight and axis has been replaced with the extra entity "weight_distribution". "weight" actually stands for the attributed relationship "axis/weight" (and is implemented that way). The dotted line between alphabet and the semigraphic relationship stands for an inverted access path, added to the implementation of alphabet. Other refinements: Some "many" roles have been changed to "1", to reflect the fact that the inverse access path has not been implemented. The fact is also reflected by removal of all unused inverse role names. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ÚÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³DIRECTION³ ³ ³ ³ value ³ ³ ³ ³ name ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ³ ³ 1^M ³ ³ set of ³ ³ ³ ³ ³ ³ m³M ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ divides ÚÄÄÄÄÄÄ¿ ³ ³ ³COMPUTER_ALPHABET³ ³INTERSECTION³1 space_on 1³AXIS ³ ³ ³ ³ name ³ ³ value ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ>³ value³ ³ ³ ³ num_chars ³ùù ³ meaning ³M ³ name ³ ³ ³ ÀÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÙ ù ÀÄÄÄÄÄÂÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÙ ³ ³ 1³ includes ùùùùùùùù>³1 1^M ³ ³ ³ semigraphic ³ ³ ³ ³ includes ³ has ³ ³ ³ ³ ³ ³ ³ ³ ³ ³1 is_semigraphic 1³1 distributed ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ>³ on ³ ³ ³ ³ ³ ³ ³ ³ mVO mV 1³ ³ ³ ÚÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÁÄÄÄ¿ ³ ³ ³CHARACTER³ ³WEIGHT_DISTRIBUTION³1 divided_to m³WEIGHT³ ³ ³ ³ ³ ³ value ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ>³ width³ ³ ³ ³ ³ ³ ³ M³ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÙ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ