home *** CD-ROM | disk | FTP | other *** search
/ Liren Large Software Subsidy 7 / 07.iso / c / c100 / 1.ddi / SNAV0111.ZIP / ARTICLE.PRN next >
Encoding:
Text File  |  1990-04-16  |  18.0 KB  |  288 lines
  1. <         the╔══╗╔══╗╔                      ╔
  2.             ║  ╙╢  ╙╢                      ║ █
  3.             ║   ║   ║ ╔═══╗ ╠═ ╔═══╗╔ ╔═══╗║ ╔ ╔═══╗╔ ╔═══╗╔ ╓─╖ ╔═══╗╔ ╔═╗╔═╗╔
  4.             ║   ║   ║ ║   ║ ║  ║   ╙╢ ║   ╙╢ ║ ║   ╙╢ ║   ╙╢ ║╓╜ ║   ╙╢ ║ ╙╢ ╙╢
  5.             ║   ║   ║┌╫───╜ ║ ┌╢    ║┌╢    ║ ║┌╢    ║┌╢    ║ ║║ ┌╢    ║ ║  ║  ║
  6.             ║   ║   ║│║   ╓─╢ │║   ╓╢│║   ╓╢ ║│║   ╓╢│║   ╓╢ ║║ │║   ╓╢ ║  ║  ║
  7.             ╜   ╨   ╙┘╚═══╝ ╚═╛╚═══╝╙┘╚═══╝╙─╨┘╚═══╝╙┘╚═══╝║┌╜╙─┘╚═══╝╙─╜  ╨  ║
  8.                                                       ╓────╫┘                 ║
  9.             ╓─────────────────────────────────────────╚════╝──────────────────╜
  10.             ╙─── architecture
  11.          
  12.             (software foundation)
  13.                                     SNAV - data model
  14.                                    - 16.4.90 page 1 -
  15.          
  16.                            ┌───────┐
  17.                  ─────────>│ AVNER │
  18.                  ─────────>│  BEN  │──────> Software Engineering Method
  19.                            └───────┘
  20.                  10 Dov-Hoz st. Tel-Aviv 63416 Israel tel. 972-3-221535
  21.          
  22.          
  23.          
  24.          
  25.          
  26.          
  27.          
  28.          
  29.          
  30.          
  31.          
  32.                    ┌─────────────────────────────────────────────────┐
  33.                    │             "The Screen NAVigator"              │
  34.                    │                                                 │
  35.                    │             DATA MODEL DESCRIPTION              │
  36.                    │                                                 │
  37.                    │            Version 1.00, April 1990.            │
  38.                    └─────────────────────────────────────────────────┘
  39.          
  40.                             Copyright (c) 1990 by Avner Ben.
  41.          
  42.          
  43.          
  44.          
  45.          
  46.          
  47.                                                   Written by  Avner Ben
  48.                                                               13 April 1990.
  49.                                     SNAV - data model
  50.                                    - 16.4.90 page 2 -
  51.          
  52.          ENOTATIONF
  53.          E───────────────────────────────────────────────────────────────────────F
  54.          
  55.          the following specification makes extensive use of Entity-Relationship
  56.          diagrams (ER).
  57.          
  58.          The   ER   notation   follows   the   one   used   by   IBM   in   the
  59.          Repository-Manager/MVS ER DDL.  My usage of this notation has  nothing
  60.          to do with that  specific software product.   I have simply found  the
  61.          particular   data   model   a   convenient   basis  for  the  type  of
  62.          transformation  suggested  by  OOD  in  general,  and  the logic of my
  63.          MetaDiagram  system  in  particular.    (See  IBM Corporation's RM/MVS
  64.          documentation for syntax specification).
  65.          
  66.          I have used the ER model described below as a "logical specification",
  67.          from  which  I  decomposed  the  working  data  model, using a private
  68.          notation  that  I  call  Object-Dependency  Diagram (ODD).  For syntax
  69.          specification, refer to  file "notation.prn".   The method I  used for
  70.          the decomposition is similar  to decomposing an hierarchical  database
  71.          model from a conventional ER.
  72.          
  73.          The following document  describes only the  abstract data model.   The
  74.          decomposition  is  reserved  for  a  more  thorough document.  For the
  75.          resulting operational model, refer  to file "snav.prn" and  the source
  76.          code.
  77.                                     SNAV - data model
  78.                                    - 16.4.90 page 3 -
  79.          
  80.          ETHE SNAV ABSTRACT DATA MODELF
  81.          E───────────────────────────────────────────────────────────────────────F
  82.          
  83.          The diagram below displays an overall view of the "entities" taking an
  84.          essential part in the SNAV system, and the important  "relationships",
  85.          in which  they play  a role.   This  is a  conceptual view.   The real
  86.          system (to be discussed later) is somewhat more detailed.
  87.          ┌─────────────────────────────────────────────────────────────────────┐
  88.          │                                                                     │
  89.          │                           ┌─────────┐                               │
  90.          │                           │DIRECTION│                               │
  91.          │                           │ value   │                               │
  92.          │                           │ name    │                               │
  93.          │                           └─────────┘                               │
  94.          │                               m^M                                   │
  95.          │                         set of │ (in)                               │
  96.          │                                │                                    │
  97.          │                               m│M                                   │
  98.          │ ┌─────────────────┐      ┌─────┴──────┐      divides      ┌──────┐  │
  99.          │ │COMPUTER_ALPHABET│      │INTERSECTION│1     space_on    1│AXIS  │  │
  100.          │ │ name            │      │ value      ├──────────────────>│ value│  │
  101.          │ │ num_chars       │      │ meaning    │M   (defined_by)   │ name │  │
  102.          │ └────────┬────────┘      └─────┬──────┘                   └──────┘  │
  103.          │         m│                    m│                                    │
  104.          │          │ (included           │                             │      │
  105.          │ includes │ in)             has │ (makes                      │      │
  106.          │          │                     │ visible)                    │      │
  107.          │          │1  is_semigraphic   1│1           distributed on   │      │
  108.          │          ├────────────────────>├─────────────────────────────┘      │
  109.          │          │                     │              (plots)               │
  110.          │         mVO                   mV                                    │
  111.          │     ┌─────────┐             ┌──────┐                                │
  112.          │     │CHARACTER│             │WEIGHT│                                │
  113.          │     │         │             │ width│                                │
  114.          │     │         │             │      │                                │
  115.          │     └─────────┘             └──────┘                                │
  116.          │                                                                     │
  117.          └─────────────────────────────────────────────────────────────────────┘
  118.                                     SNAV - data model
  119.          E                     THE SNAV ABSTRACT DATA MODELF
  120.                                    - 16.4.90 page 4 -
  121.          
  122.          The SNAV system is a character-oriented formatted-output driver, where
  123.          graphics is  restricted to  character-graphics.   The overall  package
  124.          supplies  two  kinds  of  services:    pattern  drawing  and   pattern
  125.          recognition.   Most of  this early  release is  dedicated to the first
  126.          service.  The  latter is currently  supplied in rudimentary  form. the
  127.          majority of the software, however, is dedicated to primitives, used by
  128.          both  services.    There  is  no  unique  projecting  logic and unique
  129.          scanning  logic.    Both  services  draw  their  power  from different
  130.          combinations of the same toolkit of primitives.
  131.          
  132.          Snav's graphics are essentially vector-graphics.  That is, shapes  are
  133.          generated by cursor in motion.   There is no such thing as  drawing an
  134.          oblong between four points.  What  Snav does is putting the cursor  at
  135.          some corner,  and then  moving in  some direction,  leaving a trail of
  136.          pixels,  changing  directions  at  each  corner.    That  means,  that
  137.          everything on the  output panel must  either be capable  of generating
  138.          motion - called "semigraphic" - or is ignored.  When the line visits a
  139.          cell which is already  in motion, "welding" of  lines will occur.   \e
  140.          This  complex  notion  has  been  implemented  as  a  database, in the
  141.          following general way:   some characters  of the alphabet  have a dual
  142.          meaning:  they are also serve as "semigraphic".  Such a character  may
  143.          also be considered  as a discrete  graphic element.   A semigraphic is
  144.          associated with an "intersection" - a set of one or more  "directions"
  145.          on  the  plain.    A  semigraphic  is also associated with a "weight".
  146.          Weight is distributed on the two axes (dimensions) of the plain  (SNAV
  147.          assumes weight to be uniform over  an axis!).  An axis may  be reduced
  148.          to a private case of intersection, simplifying the design somewhat.
  149.          
  150.          All in all, we can see  a division between two subsystems:   the right
  151.          half of the  diagram, dealing with  the abstract notion  of "character
  152.          geometry", and  the left  half, dealing  with the  application of  the
  153.          former to the concrete world of character drawing.  The first topic is
  154.          treated by  the code  in "snav0",  and the  second, by  "snav1".   The
  155.          entities  in  "snav2'  and  "snav3"  are  not represented in the model
  156.          above.
  157.          
  158.          following is an account of the entities involved:
  159.                                     SNAV - data model
  160.          E                     THE SNAV ABSTRACT DATA MODELF
  161.                                    - 16.4.90 page 5 -
  162.          
  163.          DIRECTION(-1dirval-0,dirname).
  164.          
  165.          Answers the question "which way are we going?".  A point on the output
  166.          panel is of interest  to Snav, only if  the group of pixels  currently
  167.          occupying it "connects" in (at least) some direction.  Such a  graphic
  168.          element has the potential to unite with the neighboring cell, if  that
  169.          connects  in  exactly  the  opposite  direction.    When  a  number of
  170.          semigraphic elements happen  to be adjacent,  and they connect  in the
  171.          proper directions, a semigraphic shape emerges to the eye.  Obviously,
  172.          the management of directions is a  key issue in Snav.  A  direction is
  173.          recognized by  integer value,  and has  a name.   The  domain of names
  174.          include exactly 5  values:  "Right",  "Up", "Down" and  "Left" and the
  175.          null direction  (added to  recognize nonsemigraphic  characters).  The
  176.          entity  is  addressed  by  enumerated  key  rather  than  by  name, to
  177.          facilitate efficient grouping by "intersection" (see below).  The  set
  178.          of  values  is  ordered,  not  only  for  the same reason, but also to
  179.          acknowledge what seems  to me like  a "natural" priority  for scanning
  180.          semigraphic shapes, based upon some experience with simple animation.
  181.          
  182.          INTERSECTIONS(-1intval-0,intmean).
  183.          
  184.          Intersection is simply an ordered  set of directions.  Its  purpose is
  185.          to  represent  the  motion  part  of  a  semigraphic.   "These are the
  186.          directions we can move in from here".  An intersection is addressed by
  187.          an  integer  value,  computed  by  bitwise  OR'ing  of  the directions
  188.          included.  This saves the  need to physically store the  directions in
  189.          the implementation of  intersection, and also  gives it a  unique key.
  190.          The 4 directions of the plain  make for 16 values of intersection,  to
  191.          which is added the null intersection.  These may be grouped  according
  192.          to  intersection  type,  or  "meaning":   "arrows" have one direction,
  193.          "corners"  and  "dashes"  have  two  directions,  "forks"  have  three
  194.          directions, and the "cross" has all the four directions.
  195.          
  196.          WEIGHTS(-1width-0).
  197.          
  198.          A weight  is an  integer value,  associated with  an intersection,  to
  199.          create a semigraphic.  Where the intersection determines the  symbol's
  200.          function, the weights (there may be a number of them) make it visible.
  201.          Each weight, associated with an intersection, must also be  associated
  202.          with an axis.  Since there at  most two of these on the plane,  then a
  203.          planar semigraphic may have at most two weights.  The values used  for
  204.          weight are 0-3. 1 and 2 mean exactly that (single and double line).  3
  205.          is   used   for   the   "full"   thickness   line.   0   is  used  for
  206.          "TypeWriter-Graphics" - course semigraphics, using simple characters.
  207.          
  208.          AXIS(-1intval-0,axval,axname).
  209.          
  210.          Character  weight  is  associated  with  the  two  axes  of the plane,
  211.          respectively.  The Axis may be reduced to private case of ("inherited"
  212.          from) intersection.   "Horizontal" (or "y")  is a special  case of the
  213.          intersection  {Right,Left},  and  "Vertical"  (or  "x")  is  a case of
  214.          {Up,Down}.  Note that  the relationship between intersection  and axis
  215.          does  not  necessarily  apply  to  same  occurrence  as the transitive
  216.          relationship between intersection and weight and (then) axis.
  217.                                     SNAV - data model
  218.          E                     THE SNAV ABSTRACT DATA MODELF
  219.                                    - 16.4.90 page 6 -
  220.          
  221.          COMPUTER_ALPHABET(-1name-0,numchars)
  222.          
  223.          A computer alphabet  consists of an  ordered set of  characters.  Some
  224.          characters in the  current alphabet may  become semigraphic, by  being
  225.          associated with some intersection and a set of weights (one axis at  a
  226.          time).    We  require  to  know  the  maximum  number of characters in
  227.          advance, and we do not expect it to change afterwards.
  228.          
  229.          CHARACTER(-1charname-0).
  230.          
  231.          The character, in Snav, is a decadent entity.  Actually, Snav does not
  232.          even store the character's name,  or any other qualities.   The reason
  233.          for  this  is  that  Snav  does  not actually generate characters.  It
  234.          counts on the  host device to  do that, supplied  with the character's
  235.          serial  number  within  the  current  alphabet  ("collating sequence",
  236.          "code-set").  It  is retained in  the design document,  for vendors of
  237.          pixel-oriented graphics to elaborate on.
  238.                                     SNAV - data model
  239.                                    - 16.4.90 page 7 -
  240.          
  241.          ETHE OPERATIONAL DATA MODELF
  242.          E───────────────────────────────────────────────────────────────────────F
  243.          
  244.          The working data  model, on ER  level, retains much  of the conceptual
  245.          model, with two minor extensions:  the transitive relationship between
  246.          intersection and  weight and  axis has  been replaced  with the  extra
  247.          entity  "weight_distribution".    "weight"  actually  stands  for  the
  248.          attributed relationship "axis/weight"  (and is implemented  that way).
  249.          The  dotted  line  between  alphabet  and the semigraphic relationship
  250.          stands for  an inverted  access path,  added to  the implementation of
  251.          alphabet.
  252.          
  253.          Other refinements:   Some  "many" roles  have been  changed to "1", to
  254.          reflect  the  fact  that  the   inverse  access  path  has  not   been
  255.          implemented.   The fact  is also  reflected by  removal of  all unused
  256.          inverse role names.
  257.          ┌─────────────────────────────────────────────────────────────────────┐
  258.          │                                                                     │
  259.          │                         ┌─────────┐                                 │
  260.          │                         │DIRECTION│                                 │
  261.          │                         │ value   │                                 │
  262.          │                         │ name    │                                 │
  263.          │                         └─────────┘                                 │
  264.          │                             1^M                                     │
  265.          │                       set of │                                      │
  266.          │                              │                                      │
  267.          │                             m│M                                     │
  268.          │ ┌─────────────────┐    ┌─────┴──────┐      divides      ┌──────┐    │
  269.          │ │COMPUTER_ALPHABET│    │INTERSECTION│1     space_on    1│AXIS  │    │
  270.          │ │ name            │    │ value      ├──────────────────>│ value│    │
  271.          │ │ num_chars       │∙∙  │ meaning    │M                  │ name │    │
  272.          │ └────────┬────────┘ ∙  └─────┬──────┘                   └──────┘    │
  273.          │         1│ includes ∙∙∙∙∙∙∙∙>│1                           1^M       │
  274.          │          │ semigraphic       │                             │        │
  275.          │ includes │               has │                             │        │
  276.          │          │                   │                             │        │
  277.          │          │1  is_semigraphic 1│1                distributed │        │
  278.          │          ├──────────────────>│                          on │        │
  279.          │          │                   │                             │        │
  280.          │         mVO                 mV                            1│        │
  281.          │     ┌─────────┐    ┌───────────────────┐                ┌──┴───┐    │
  282.          │     │CHARACTER│    │WEIGHT_DISTRIBUTION│1  divided_to  m│WEIGHT│    │
  283.          │     │         │    │ value             ├───────────────>│ width│    │
  284.          │     │         │    │                   │               M│      │    │
  285.          │     └─────────┘    └───────────────────┘                └──────┘    │
  286.          │                                                                     │
  287.          └─────────────────────────────────────────────────────────────────────┘
  288.