Programmer's ROM - The Computer Language Library

home *** CD-ROM | disk | FTP | other *** search

/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / pdl / gadtech.inf < prev next >

Wrap

Text File | 1988-05-03 | 183.4 KB | 3,953 lines

GGGGG RRRRRR AAAA PPPPPP HH HH IIIIII CCCCC GG RR RR AA AA PP PP HH HH II CC GG RRRR AAAAAA PPPPPP HHHHHH II CC GG GG RR RR AA AA PP HH HH II CC GGGG RR RR AA AA PP HH HH IIIIII CCCCC AAAA DDDDD AAAA * AA AA DD DD AA AA AAAAAA DD DD AAAAAA AA AA DD DD AA AA AA AA DD DD AA AA DDDDD EEEEEE SSSSS IIIIII GGGGG NN NN EEEEEE RRRRRR DD DD EE SS II GG NNN NN EE RR RR DD DD EEEE SSSS II GG NNNNNN EEEE RRRRR DD DD EE SS II GG GG NN NNN EE RR RR DDDDD EEEEEE SSSSS IIIIII GGGG NN NN EEEEEE RR RR T E C H N I C A L I N F O R M A T I O N R E P O R T FEBRUARY 1986 Prepared for Naval Ocean Systems Center, WIS Joint Program Office Prepared by Ada* Technology Group SYSCON Corportation 3990 Sherman Street San Diego, California 92110 (619) 296-0085 * Ada is a registered trademark of the United States Government - Ada Joint Program Office <FF> Table of Contents ----------------- 1. INTRODUCTION 1.1 Background 1.2 Project Overview 1.3 Summary of Technology 1.4 References 2. ALGORITHMS, DATA STRUCTURES, AND FUNCTIONAL REQUIREMENTS 2.1 Functional Requirements 2.2 Data Structures 2.3 Algorithms 2.3.1 Graph Creation 2.3.2 OODD Editing 2.3.3 Ada PDL Generation 3. SOFTWARE ARCHITECTURE 3.1 GAD 3.2 GRAPH_TREE_ACCESS 3.3 MMI 3.4 PDL_GENERATOR 3.5 GRAPHICS_DRIVER 3.6 GKS_PRIME 3.7 VIRTUAL_TERMINAL_INTERFACE 4. PROGRAM MAINTENANCE 4.1 Installation 4.1.1 Program Compilation 4.2 Parameter Controlled Features 4.3 System Rehosting 4.4 Graphics Terminal Retargeting 5. DEVELOPMENT AND TECHNICAL ISSUES 5.1 Lessons Learned 5.2 Development Approach 5.3 Ada Issues 5.3.1 Compiler Selection 5.3.2 Compiler Impact on Design and Implementation 5.3.3 Compiler Transition 5.4 Key Technology Assessment 5.4.1 Ada-based Intermediate Language with Graphics Attributes 5.4.2 Semantic Checking in Interactive Graphics Editing 5.4.3 GKS Utilization for Terminal Dependence Reduction 5.4.4 Implementation of a GKS Substitute 5.5 Productivity 5.6 Methodology Adaptation 6. TESTING 6.1 Approach 6.2 Requirements <FF> 1. INTRODUCTION SYSCON Corporation has developed the Graphic Ada Designer (GAD) to support the creation of semantically valid Ada-based Object Oriented Design Diagrams (OODDs) which depict the structure of Ada programs. The Graphic Ada Designer is an interactive graphics editor utilizing bit-mapped color graphics which can create and modify OODDs from which Ada Program Design Language (Ada PDL) code can be automatically generated. The OODDs are highly useful in providing system architecture overviews and summaries of key design entities and their interactions. The Graphic Ada Designer was designed to meet the requirements of NOSC solicitation N66002-84- R-0030 Item No. 013 under the terms of contract N66001-85-C-0037 Item No. 0001. 1.1 Background One of the purposes of the WWMCCS Upgrade program is to bring the WWMCCS capability into line with the current state-of-the-art by enchancing its functionality and expandability through integration of modern hardware and software. A key element of this program will be the utilization of Ada*, a programming language designed by the DOD to facilitate and standardize the development of embedded computer systems. Research into the use of Ada has emphasized the need for modern development methodologies in conjunction with a capable tool kit to achieve maximal cost savings; and for this reason substantial effort is being expended on the development and refinement of Ada based PDLs. As an evaluator of Ada language capabilities and Ada software development, and as a developer of Ada programming methodologies, SYSCON realized that Ada PDL did not effectively convey high level Ada structure information in a compact and easily reviewable form. This led to the development of a graphic convention for depicting Ada structures. An Ada Graphic Notation was created based on the Object Oriented Design work of G. Booch [BOOCH] and a structure diagramming technique presented by Dr. R. Buhr [BUHR]. Ada Graphic Notation has been successfully applied to several Ada projects, and is reflected in SYSCON's Ada software methodology (see Section 5.). As SYSCON refined its definition of a graphical representation of Ada structures, the concept of developing a tool to assist in graphics development quickly followed. The result was the funding of an internal research and development effort named 'SKETCHER' to prototype an Ada graphics tool. The GAD is an extension of SYSCON's prior and ongoing experience with Ada-based graphics. 1.2 Project Overview The purpose of the Graphic Ada Designer is to support the development of Ada software through interactive development of graphical representations of Ada programs. This will be accomplished by utilizing an Ada-based Intermediate Language with Graphics Attributes, which consists of a DIANA-like tree-based data structure with a direct correspondence to Ada constructs plus attributes for the associated graphics information. The GAD supports interactive development with a single integrated tool which uses the Intermediate Language to store and access the semantic and graphic information describing an Ada program. The GAD performs graphics editing which allows a user to interactively build graphs of Ada structures on the user's terminal (while simultaneously building a tree structured file of the OODD using the Intermediate Language), and produces Ada PDL which corresponds to the Ada program being designed. The development of the GAD involved the completion of the definition of the tool's user interfaces, the design of the software using SYSCON's Ada software development methodology, the writing and debugging of the code, the integration and test of the coded software and, finally, the installation of the software and delivery of the associated documentation. Several key technical issues were addressed in the design and development of the GAD software. These issues were identified based on prior work, and included: how to best perform on-line semantic checking of Ada graphs, how to perform graphic manipulations which alter the lexical and/or semantic structure of the corresponding Ada program, and how to link graphs to permit the development of complete and consistent Ada designs and PDLs. SYSCON had already discovered many potential solutions, and the design process dealt with the selection of the most effective solution. 1.3 Summary of Technology The Graphic Ada Designer provides the capability to interactively edit graphic representations of Ada programs in a manner which guarantees limited semantic correctness. This state-of-the-art software capability is provided by integrating a wide variety of software technologies in a synergistic fashion. The integrated technologies are: - The Graphical Kernel System. A generalized interface mechanism for use with color capable two-dimensional graphics display devices. See Sections 2.3.1, 3.6, and 5.4.3. - An Ada Intermediate Language with Graphics Attributes. GAD uses this DIANA-like, tree structured intermediate representation form to store and access the syntactical and semantic information of the Ada program being designed, as well as the graphical data required to generate and manipulate the graphical representations of the OODDs. See Sections 2.2, 3.2, and 5.4.1. - A PDL Generation approach based on the utilization of the Ada Intermediate Language. See Sections 2.3.3 and 3.4. In addition to incorporating and/or adapting these existing technologies, the GAD develops the capability to perform syntactically and semantically sensitive interactive editing. Similar in scope to syntax-directed source editors with user invocable semantics checking, GAD addresses the problem of "on-the-fly" semantics checking using an intermediate form. This is further described in Sections 2.3.2, 3.3, and 5.4.2. 1.4 References [AdaGKS] "Draft GKS Binding to ANSI Ada"; X3H3/83-95r2; 1985. [AdaLRM] "Reference Manual for the Ada Programming Language"; ANSI/ MIL-STD-1815A; United States Department of Defense; 1983. [BOOCH] "Software Engineering with Ada"; Grady Booch; Benjamin/ Cummings; 1983. [BUHR] "System Design with Ada"; R.J.A. Buhr; Prentice-Hall; 1984. [FOLEY] "Fundamentals of Interactive Computer Graphics"; J.D. Foley and A. Van Dam; Addison-Wesley; 1982. [GKS] "Information Processing Systems Computer Graphics Graphical Kernel System (ANS GKS)"; X3H3/83-25r3; 1984. [HOPGOOD] "Introduction to the Graphical Kernel System"; Hopgood, Duce, Gallop, and Sutcliffe; Academic Press; 1983. [USER] "Graphic Ada Designer User's Manual"; SYSCON Corporation; 1985. <FF> 2. ALGORITHMS, DATA STRUCTURES, AND FUNCTIONAL REQUIREMENTS The GAD is designed to use the capabilities of a color bit-mapped graphics terminal to build graphic representations of Ada program structures. This tool will make use of available advanced graphics hardware features, such as windowing, cursor control device input, internal memory and graphic segment manipulation capabilities, to provide an efficient interactive graphics environment. The GAD is hosted on a VAX*, using the VMS* operating system, and is written in Ada. The initial program development was performed using the TeleSoft Ada compiler (Version 1.5), and the program was transitioned to DEC* Ada approximately midway through the development phase. The program is written in machine and compiler independent Ada, and is only dependent on the graphics terminal and printer used, and these dependencies are localized within the code. The interaction of GAD with the user, host operating system, file system, graphics terminal and printer is illustrated in Figure 2-1. The design diagrams developed using GAD are stored in a tree-like representation form maintained by GAD and preserved in a file structure. GAD uses the CRT to provide a "window" onto the OODD with the capability of pan and zoom. At standard zoom (ie. no magnification) the user can view an entire design diagram. At maximum zoom, approximately 6% of the diagram will be displayed in the window. VAX/VMS HOST --------------------------------------------------- | GAD | | ----------------------------------- | | | Functional | Memory Resident | | | | Modules | Tree Based Forms | | | ----------------------------------- | | | Virtual_Terminal_ | GKS_ | | | | Interface | Prime | | | ----------------------------------- | | | Ada Runtime System & | | | | Predefined Packages | | | ----------------------------------- | --------------------------------------------------- (* Keyboard & ^ | | ^ Cursor Control Device) | | | | User Input * ------+ | | +---> Design File Graphics Output <------------+ +---------> PDL File | v Graphics Hardcopy Figure 2.1-1 GAD Interfaces * DEC, VAX, and VMS are trademarks of the Digital Equipment Corp. 2.1 Functional Requirements The basic functions of GAD fall into four (4) major categories. The Graphics Design functions which provide the capability to create, display and modify OODD diagrams on the graphics terminal; the PDL Production functions provide the capability to extract the necessary syntax and semantic information from the OODD Syntax Tree data structure and generate PDL text files; the Storage Management functions which provide for the automatic creation of, and access to GAD files; and the MMI functions provide the user interface through which the designer orchestrates all GAD operations. 2.1.1 Graphics Design Functions GAD provides a graphics design capability which consists of creating, deleting, and editing OODDs formed of entities representing Ada structures (e.g., packages, subprograms, tasks, or bodies), and connections which represent relationships between entities. Strict Ada (PDL) syntax and semantics to the appropriate level of detail will be enforced in the graphs at the completion of each operation. The graphics design capabilities will be in accordance with the Ada Graphic Notation conventions (described in detail in Section 3 of the GAD User's Manual [USER]). The minimum graphics information required for each entity is its size and position on the graph. This information, and all other required graphics information, is stored in the Graph_Tree data structure described in Section 2.2. The GAD approach is to use the terminal's hardware capabilities to simplify user selection, movement, and deletion operations. This requires the maintenance of the graphic segment identifiers corresponding to each entity in the design (see Section 2.3.1). 2.1.2 Ada PDL Production Functions GAD provides a command to generate the PDL corresponding to the current OODD. The program generates the PDL and places it in an ASCII text file of the name "<Session File Name>.<PDL File Extension>". The Ada PDL that is produced will be syntactically correct and compilable, if context and visibility clauses (with and use statements) are added for the SUPPORT_PACKAGE documented in the GAD User's Manual (this is a selectable option). For PDL generation, the general guideline will be to generate as much code as possible and permit the user to delete what is not needed. The code produced will be a mix of Ada and embedded English comment statements. Generation of the PDL requires information on each entity for which code is to be generated. This information includes 1) the name, 2) the enclosing scope, 3) the type of entity, 4) a list of what it encloses, 5) it's relationship with other entities including whether it is exported, and 6) miscellaneous entity specific information (e.g., generic status). The basic syntax information is provided in a tree-like arrangement of the structures described in Section 2.2. Walking the tree to detect all references to particular entity (node) can be excessively time consuming, and for this reason, the basic Syntax_Tree is enhanced to include back pointers for each possible relationship (including parent-child). 2.1.3 File Management Functions GAD provides mechanisms to save and restore graphs between invocations of the tool. The necessary graphics, syntax, and semantic information is saved in a file, one graph per file. There are no relationships maintained by GAD between files, although a user may create a series of graphs depicting the evolution of a design. The PDL text file is an output-only structure from the perspective of the GAD tool. There are no editing capabilities provided with which to alter this file. The file is created from the OODD data structures, and the PDL file is a standard text file (created via TEXT_IO) which can be accessed by source line editors or word processors, print utilities and Ada compiler(s) hosted on the system. 2.1.4 MMI Functions The GAD MMI provides an efficient means for designing Ada OODDs. The MMI approach is predicated on utilizing the full capabilities of the graphics terminal (including color bit-mapped graphics, and cursor control device ). The basic MMI goals are itemized below as: o Minimize keyboard interaction o Maximize use of cursor control device o Support pick and move operations at terminal o Implement drawing using cursor control device to mark graph points o Provide menu support for 'pickable' command icons o Provide quick response by using the terminal's internal memory and segment operation capabilities 2.2 Data Structures The problem posed to GAD was to formulate a major data structure design that: stores the graphic data needed to generate and manipulate the OODD graphic symbols; provides a correlation between the graphics data and the Ada language structure it represents; maintains the interrelationshps (e.g. scoping, call dependencies and data dependencies) between entities; and stores the required syntax and semantic information for each Ada language structure. The data structures utilized by GAD capture the Ada semantic and graphical information associated with the graph as they are created, edited and positioned within the design diagram. The data structures must support: o PDL Generation o Regeneration of graphs between sessions o Detection of severed connections (due to move or delete operations) o Syntax and semantic information verification To be able to perform the required functions, the data structure must support the ability to trace relations in multiple directions, such as parent-child and caller-callee. The design utilized specifies two different but related structures: Syntax_Tree and Graph_Tree structures. Figure 2.2-1 presents a structural overview of the major data structures. The Syntax_Tree is comprised of two substructures, Tree Node and List Node structures. The Tree Node structures contain basic information about the entity they represent, such as name, scope and generic attributes (if applicable). Each Tree Node contains a set of pointers to the various List Node structures which contain lists of information unique to the entity with which it is associated. The types of List Node structures that will be maintained are: o Contained_Lists o Callee_Lists o Data_Connect_Lists o Entry_Lists o Imported_Lists o Exported_Lists The Graph_Tree structures consist of nodes which contain the basic graphic information about an entity, such as location and size. The Syntax_Tree and Graph_Tree structures both contain different kinds of information about the objects being diagramed. It should be noted that the data structure figure is a simplified representation. In actuality, the various nodes and associated entity pointers are multi-threaded (for example, there exist forward and backward pointers between the nodes of the Syntax_Tree and Graph_Tree). The structure actually takes on a more n-dimensional characteristic which is not representable on two-dimensional media. <FF> SYNTAX_TREE GRAPH_TREE ------------------------------------------------ ----------- | Tree Nodes +------------------------------------>| Node 1 | | ---------- | List Nodes | | | | | Root | | ----------- | |---------| | +->| |--|------------>| | | +-->| Node 2 | | | ---------- | ----------- |--+ | | | | | | | +-------->| |-- | | | |---------| | | ---------- | | ----------- |--+ | | | | | | +--| Node 1 |--+ | | |-- | | | | | | | +->| |----+ ----------- | | | | | |---------| | | ---------- | |-- | | | | | | | | ^ | | | | | | | : | | | | ----------- | | | | | : | | | +----------------------------------+ | | | : | | | | | | | : | | | | | | | : | | | ---------- | | | | | | | | Node n |<--------------------------+ | | |---------| | +__| |--------------------------------|---+ | Node m | | ---------- | | | | | ----------- ------------------------------------------------ Figure 2.2-1. Major Data Structure Overview The primary data structure of the GAD is the Syntax Tree, whichs stores the syntactic and semantic information which describes the Ada program depicted in the OODD under construction. This data structure also contains all the necessary graphic information (through pointers to nodes of the Graph Tree) needed to manipulate and recreate the graphic representation of an OODD. The following extract from the TREE_DATA package illustrates the construction and function of this data structure. package TREE_DATA is ------------------------------------------------------------------------- -- -- This package provides the declarations and objects for the -- Graph Tree which holds all the graphical, syntax, and -- semantic information required by the program. The tree contains -- TREE, LIST and GRAPH nodes. The TREE nodes represent Ada -- entities (structures) and are connected in a hierarchal order (tree) -- indicating the scope of each entity. The LIST nodes are used to -- store relationships (e.g., context clauses) and annotations (e.g., -- exported type declarations). The GRAPH nodes contain the graphical -- data associated with each TREE node. -- ------------------------------------------------------------------------- ---------------------------------------------------------------------- -- All of the Ada entities, one for each type of TREE node. ---------------------------------------------------------------------- type ENTITY_TYPE is (UNUSED, ROOT, TYPE_VIRTUAL_PACKAGE, TYPE_PACKAGE, TYPE_PROCEDURE, TYPE_FUNCTION, TYPE_TASK, TYPE_ENTRY_POINT, TYPE_BODY, IMPORTED_VIRTUAL_PACKAGE, IMPORTED_PACKAGE, IMPORTED_PROCEDURE, IMPORTED_FUNCTION, EXPORTED_PROCEDURE, EXPORTED_FUNCTION, EXPORTED_ENTRY_POINT, EXPORTED_TYPE, EXPORTED_OBJECT, EXPORTED_EXCEPTION, CONNECTION_BY_CALL, CONNECTION_FOR_DATA); -- this was extracted from package GRAPHICS_DATA ---------------------------- -- Graphics data declaration ---------------------------- type GRAPHICS_DATA_TYPE is record WINDOW : WINDOW_TYPE := GRAPH_VIEW_PORT ; LABEL_SEG_ID : GKS_SPECIFICATION.SEGMENT_NAME := NULL_SEGMENT ; LABEL2_SEG_ID : GKS_SPECIFICATION.SEGMENT_NAME := NULL_SEGMENT ; SEGMENT_ID : GKS_SPECIFICATION.SEGMENT_NAME := NULL_SEGMENT ; LOCATION : POINT := NULL_POINT ; SIZE : POINT := NULL_POINT ; COLOR : COLOR_TYPE := BLACK ; end record ; ---------------------------------------------------------------------- -- The graphical data for each tree node, stored in the -- GRAPH_DATA_ARRAY. A null OWNING_TREE_NODE indicates that -- the node is unused. ---------------------------------------------------------------------- type GRAPH_NODE_TYPE is record OWNING_TREE_NODE : TREE_NODE_ACCESS_TYPE := NULL_POINTER; DATA : GRAPHICS_DATA.GRAPHICS_DATA_TYPE; end record; ---------------------------------------------------------------------- -- The LINE type is used to define connecting lines between -- graphic entities (Call, Export, and Ada 'Use' connections). -- A line is a series of points which define line segments -- comprising the connection line. ---------------------------------------------------------------------- ---------------------------------------------------------------------- -- The various LISTS occuring in the tree are declared below. -- The list format to be used to create specific kinds of lists. -- A doubly linked list is required for forward and back tracing. ---------------------------------------------------------------------- -- The lists contained in a Tree Node. The order of the Lists -- is the order of the List scan during a tree walk. type LIST_TYPE is (START, -- for starting node list scans CONTAINED_LIST, CALLEE_LIST, DATA_CONNECT_LIST, ENTRY_LIST, EXPORTED_LIST, IMPORTED_LIST, NULL_LIST); ---------------------------------------------------------------------- -- The definition of the MEMBERSHIP list. ---------------------------------------------------------------------- -- The MEMBERSHIP list exists to maintain a back pointer for -- relations established by other lists. The TREE_OPS package -- should be the only manipulator of this list. -- -- The access type for the MEMBERSHIP list is implemented as an -- index into LIST array. This is done to minimize the number -- of node types to be handled. ---------------------------------------------------------------------- -- The definition of the TREE node structure. This data structure -- is combined using the LIST data structure to form a DIANA like -- syntax tree which stores the syntactical and semantic information -- concerning the Ada program which is represented by the OODD under -- construction. A predefined Root Node is as the starting point -- of each Tree. ---------------------------------------------------------------------- type TREE_NODE_TYPE (NODE_TYPE: ENTITY_TYPE := UNUSED) is record NAME : NAME_TYPE := NULL_NAME; -- the name of this node PARENT : TREE_NODE_ACCESS_TYPE := NULL_POINTER; -- the parent GRAPH_DATA : GRAPH_NODE_ACCESS_TYPE := NULL_POINTER; ------------------------------------------------------------------- -- A list of all list nodes pointing to this node ------------------------------------------------------------------- MEMBERSHIP : MEMBERSHIP_LIST_TYPE := NULL_POINTER; ------------------------------------------------------------------- -- The Node Type specific data which includes lists pointing -- to connected, contained, or related nodes, and which includes -- semantic information concerning the current node (e.g., -- generic status of a subprogram). ------------------------------------------------------------------- case NODE_TYPE is when ROOT | TYPE_VIRTUAL_PACKAGE | TYPE_PACKAGE | TYPE_PROCEDURE | TYPE_FUNCTION | TYPE_TASK => CONTAINED_ENTITY_LIST : CONTAINED_ENTITY_LIST_TYPE := NULL_POINTER; case NODE_TYPE is when TYPE_VIRTUAL_PACKAGE | TYPE_PACKAGE | TYPE_PROCEDURE | TYPE_FUNCTION | TYPE_TASK => PROLOGUE_PTR : PROLOGUE_NODE_ACCESS_TYPE := NULL_POINTER; BODY_PTR : TREE_NODE_ACCESS_TYPE := NULL_POINTER; DATA_CONNECT_LIST : DATA_CONNECT_LIST_TYPE := NULL_POINTER; case NODE_TYPE is when TYPE_VIRTUAL_PACKAGE | TYPE_PACKAGE | TYPE_PROCEDURE | TYPE_FUNCTION => GENERIC_STATUS : GENERIC_STATUS_TYPE := NOT_GENERIC; CU_INSTANTIATED : NAME_TYPE := NULL_NAME; case NODE_TYPE is when TYPE_VIRTUAL_PACKAGE | TYPE_PACKAGE => EXPORTED_LIST : EXPORTED_LIST_TYPE := NULL_POINTER; IMPORTED_LIST : IMPORTED_LIST_TYPE := NULL_POINTER; when TYPE_FUNCTION | TYPE_PROCEDURE => HAS_PARAMETERS : BOOLEAN := FALSE; when others => null; end case; when TYPE_TASK => TASK_STATUS : TASK_STATUS_TYPE := NORMAL_TASK; ENTRY_LIST : ENTRY_LIST_TYPE := NULL_POINTER; when others => null; end case; when others => null ; end case ; when TYPE_ENTRY_POINT => IS_GUARDED : BOOLEAN := FALSE; -- for task entry points WITH_PARAMETERS : BOOLEAN := FALSE; when TYPE_BODY => CALLEE_LIST : CALLEE_LIST_TYPE := NULL_POINTER; when EXPORTED_PROCEDURE | EXPORTED_FUNCTION | EXPORTED_ENTRY_POINT | EXPORTED_TYPE | EXPORTED_OBJECT | EXPORTED_EXCEPTION | CONNECTION_BY_CALL | CONNECTION_FOR_DATA => CALL_VARIETY : CALL_CONNECTION_TYPE := NO_CONNECTION; CONNECTEE : TREE_NODE_ACCESS_TYPE := NULL_POINTER ; LINE : LINE_TYPE := NULL_LINE ; when others => null; end case; end record; ---------------------------------------------------------------------- -- The Primary array declarations ---------------------------------------------------------------------- GRAPH : GRAPH_ARRAY (1..MAX_GRAPH_NODES); LIST : LIST_ARRAY (1..MAX_LIST_NODES); TREE : TREE_ARRAY (1..MAX_TREE_NODES); PROLOGUE : PROLOGUE_ARRAY (1..MAX_PROLOGUE_NODES); ---------------------------------------------------------------------- -- The Root Node of the TREE ---------------------------------------------------------------------- ROOT_NODE : constant TREE_NODE_ACCESS_TYPE := TREE'first ; end TREE_DATA; 2.3 Algorithms 2.3.1 Graph Creation The GAD is an interactive graphics editor used in the design process to construct and modify graphic representations of Ada program structures. The tool makes use of terminal hardware features, such as segment attribute manipulation, to provide an efficient MMI. The utilization of these features to create graphs is described in the following paragraphs. Graphic operations performed by GAD are based on the concept of segments. A segment is a logically related collection of graphics objects stored in terminal memory, which the terminal, and the GAD, manipulate as a single object. The number of graphic objects which can be placed in a segment ranges from a single object to all the objects contained in the display. The operations which may be performed on a previously created segment are: - executing a segment transformation, which performs segment translation ( movement ), scaling, and rotation; - defining segment visibility, which determines whether or not a segment is currently displayed; - defining segment highlighting, which determines whether or not a segment is highlighted; - defining segment priority, which determines the display priority of a specified segment; and - setting segment detectability, which defines whether or not a segment can be selected by a pick input device. GAD creates and manipulates segments to support the MMI (e.g., menu icons), and to support the implementation of operator selected commands. The MMI virtual package determines which segment(s) must be created. The graphic entity contained in the segment may be (among others) a menu icon, a text label, or package icon. The request to create the graphic entity is passed to the GRAPHICS_DRIVER, which utilizes the subprograms contained in the GKS_PRIME virtual package to create a segment, to build the requested graphic entity in the segment, and to close the segment. During the process of segment creation the GKS_PRIME package utilizes the TERMINAL_ACCESS package to generate the terminal specific command sequences. The identifier associated with the created segment is returned to the MMI virtual package. If manipulations of the created entity are required then the operations are performed on the segment specified by the segment identifier. ------------------------ | MMI VIRTUAL PACKAGE | ------------------------ | ^ Create specified | | Segment graph entity | | Identifier | | v | ----------------------------------- | GRAPHICS_DRIVER VIRTUAL PACKAGE | ----------------------------------- | Open specified | segment | | Draw graph entity | | Close specified | segment | | v ------------------------------------ | GKS_PRIME PACKAGE | | ( in GKS_PRIME VIRTUAL PACKAGE ) | ------------------------------------ | Terminal Level | operations | | V ------------------------------------ | TERMINAL_ACCESS PACKAGE | | ( in GKS_PRIME VIRTUAL PACKAGE ) | ------------------------------------ | Terminal specific | command sequences | V --------------------- | Graphics Terminal | --------------------- <FF> 2.3.2 OODD Editing The principal goal of the GAD is to support the interactive editing of OODDs which describe the semantic architecture of an Ada program. To accomplish this task, the MMI of this program is required to perform a series of functions which 1) Obtain and validate the necessary information required to describe the syntax and semantics of an Ada program. This includes name, scope, and interrelationships. 2) Create and store the graphically related information needed to generate the graphical representation of the Ada program being designed. This includes location and segment (see the preceding Section 2.3.1) information. The implementation of these two functions is decidedly intertwined. The semantic information (e.g., scoping relationship) of Ada entities being created is derived from their location on the graphical representation. Conversely, the location information is stored in a tree form which parallels the semantic relationships of the entities. The interactive editing of OODDs consist of three primary types of operations. These operations are: 1) Creation of Entities and their relationships including Connections. 2) Modification of Entity attributes. 3) Deletion of Entities and Connections. Each of these operations involve common functions which include: interaction with the GAD User, modification of the primary GAD data structure (see Section 2.2), and utilization of the target graphics terminal which results in the alteration of the OODD displayed on it. The steps involved in creating a new entity on a OODD are shown in Table 2.3-1. <FF> Table 2.3-1. Steps in Creating a New Entity -------------------------------------------- - Obtain all parameter values using submenus. This includes information on generic, parameter, and entry point status. - Obtain the point(s) which describe the scope and location of the entity to be created. During multi-point processing, insure that both points have the same scope. Allow the user to quit the operation by selecting the ABORT icon. - Validate the scope of the points obtained. If an invalid scope was selected then notify the user and abort the operation. - Create the Tree Node to be used to store the data concerning the entity being created. Insert the Node in the tree to reflect its scope. - Create the Graph Node to be used to store the graphical data associated with the entity being created. Establish the linkage between the Graph Node and the Tree Node. Place the location information from the points previously obtained in the Node. - If a primary entity is being created (e.g., package or subprogram), then draw a figure representing the entity and store the segment number created in the Graph Node. - Obtain the name of the entity being created if one is required. Continue name processing until the user enters a name having a valid syntax for an Ada identifier. Add the name to the Tree Node. - Label the figure with the name, and store the segment number in the Graph Node. If the entity is an import or export, then the label constitutes the primary figure. - Obtain the prologue information for primary entities. Create a Prologue Node and place the information in it. Establish the linkage between the Prologue Node and the Tree Node. - Obtain any other required name information (e.g., name of generic unit being instantiated). Continue name processing until the user enters a name having a valid syntax for an Ada identifier. - Label the figure with any other name information, and store the segment numbers in the Graph Node. The steps involved in modification of Entities are similar to the steps in creation. Once an entity has been selected for modification, GAD prompts the user for new values for the non-location type user entered information shown in Table 2.3-1. During modification operations however, the new information replaces the old information in existing nodes and no new nodes are created. The steps involved in deletion of Entities and Connections are much simpler. Once an entity or connection has been identified for deletion by the user, GAD highlights what will be deleted and requests user confirmation of the delete operation. If the deletion is confirmed, the highlighted portion of the OODD is erased and the various nodes released. If the deletion is canceled the OODD is restored to its previous state. The complexity of a delete operation is in determining what must be deleted to maintain the semantic integrity of the graph, and in correctly removing the various nodes without leaving any dangling pointers. 2.3.3 Ada PDL Generation The package performing Ada PDL generation includes routines to generate PDL by walking the tree which contains the information describing the OODD currently being edited. A two pass PDL generation algorithm is implemented by using two subprograms, one to generate the specifications for the PDL and the other to generate the bodies for the PDL. Both subprograms use a recursive descent approach to generate the PDL, wherein each subprogram will perform the code generation by writing the PDL appropriate for the current node and using recursive invocations of itself to process its child nodes. The pseudo code (structure english language narrative) for the primary procedure used to generate the PDL follows. For the complete PDL see the file PDL_GEN_BODY.ADA. procedure GENERATE_PDL ( PDL_FILE_NAME : in TREE_IO.FILENAME_TYPE ) is -- -- This procedure walks the current Graph Tree and emits the -- corresponding Ada PDL in the file designated by the user. -- The procedure expects that PDL_FILE_NAME is the name of -- PDL file to be created. -- begin -- create the PDL output file with TEXT_IO calls declare use TEXT_IO ; begin TEXT_IO.CREATE ( PDL_FILE , OUT_FILE , TREE_IO.COMPLETE_FILE_NAME ( PDL_FILE_NAME , FILENAME_EXTENSION ) ) ; end ; -- If write to screen was requested then initialize the screen. if WRITE_PDL_TO_SCREEN then INITIALIZE_SCREEN_DISPLAY ; end if ; -- initialize the DECLARED array to show nothing yet declared -- initialize the Indentation level and line length to -- permit multiple invocations of GENERATE_PDL -- write the Support Package if that option was requested if INCLUDE_SUPPORT_PACKAGE then WRITE_SUPPORT_PACKAGE ; end if ; -- starting from the ROOT_NODE, generate the PDL for the -- specs of each contained entity PTR := TREE(ROOT_NODE).CONTAINED_ENTITY_LIST; while PTR /= NULL_POINTER loop EMIT_SPECS (LIST(PTR).ITEM); PTR := LIST(PTR).NEXT; end loop; -- output blank line between the SPEC and BODY NEW_LINE ; -- starting from the ROOT_NODE, generate the PDL for the -- bodies of each contained entity PTR := TREE(ROOT_NODE).CONTAINED_ENTITY_LIST; while PTR /= NULL_POINTER loop EMIT_BODIES (LIST(PTR).ITEM); PTR := LIST(PTR).NEXT; end loop; -- close the PDL file TEXT_IO.CLOSE (PDL_FILE); -- terminate the PDL display of the screen if WRITE_PDL_TO_SCREEN then TERMINATE_SCREEN_DISPLAY ; end if ; exception when others => if TEXT_IO.IS_OPEN (PDL_FILE) then -- write an error message indication unsuccessful completion WRITE_LINE (" PDL generation unsuccessfully completed "); -- close the PDL file TEXT_IO.CLOSE (PDL_FILE); else raise; end if; end GENERATE_PDL; The PDL for the procedures used to generate the PDL for the specifications and bodies is as follows: ------------------------------------------------------------------------ -- The procedure to emit the PDL for the specifications ------------------------------------------------------------------------ procedure EMIT_SPECS (NODE: in TREE_NODE_ACCESS_TYPE) is -- This procedure emits the PDL for the spec of the current -- Tree node, and recursively invokes itself for contained -- entities of the current node. begin -- Check if the current NODE is valid. -- Skip this Tree NODE if it has already been declared. case TREE(NODE).NODE_TYPE is when TYPE_VIRTUAL_PACKAGE | TYPE_PACKAGE => -- Scan the IMPORTED_LIST and write the 'with's. -- Write the support package if not nested and the -- the user has requested it. -- If this declaration is generic, write the generic statement. -- Write the 'start' of the (virtual) package. -- If this is a generic instantiation then -- complete the declaration. -- Write the prologue. else -- Write a non generic declaration. -- Write the prologue. -- Scan the EXPORTED_LIST for visible types, objects, -- and exceptions. -- Scan the EXPORTED_LIST for remaining items, that is -- packages, subprograms, and tasks. -- Write the 'end' of the package specification. end if; when TYPE_PROCEDURE => -- Write the support package if not nested and the -- the user has requested it. -- If this declaration is generic, write the generic statement. -- Write the subprogram declaration including the name. -- If this is a generic instantiation -- Complete the generic instantiation. -- Generic actual parameters currently not handled. else -- If the subprogram has calling parameters then -- write them. end if ; -- Write the end of the procedure declaration. -- Write the prologue. when TYPE_FUNCTION => -- Write the support package if not nested and the -- the user has requested it. -- If this declaration is generic, write the generic statement. -- Write the function declaration including the name. -- If this is a generic instantiation -- then complete the instantiation. -- Generic actual parameters currently not handled. else -- If the function has calling parameters then write them. -- Write the return part (not needed for generic inst.). end if ; -- Write the end of the function declaration. -- Write the prologue. when TYPE_TASK => -- Write the task declarative statement. -- Write the prologue. -- Scan the ENTRY_LIST for the entry points. -- Write an entry statement for each entry found. -- Write calling parameters if they exist. -- Mark the node as declared. -- Process the next imported item. end loop; -- Write the 'end' of the task declaration. when TYPE_BODY => -- No body code placed in the specs. null; when EXPORTED_PROCEDURE .. EXPORTED_EXCEPTION => -- If this Exported declaration is Connected to -- the exported item of a contained package, then -- all the exported items of that package -- must be made visible. -- If connected to another export then declare the -- Parent. else -- Write declaration using actual declaration. EMIT_SPECS (TREE_PTR); end if; else -- Process all non-connected exports. case TREE(NODE).NODE_TYPE is when EXPORTED_PROCEDURE => -- Write the procedure declaration. when EXPORTED_FUNCTION => -- Write the function declaration. when EXPORTED_TYPE => -- Write the type declaration. when EXPORTED_OBJECT => -- Write the object declaration. when EXPORTED_EXCEPTION => -- Write the exception declaration. when others => null; end case; -- Mark valid CONNECTEEs as declared. end if; end if; when others => -- Should not occur here! Send an error message to the -- user and attempt to continue. end case; -- Mark the current NODE as declared. -- Reset the nesting level. end if; end EMIT_SPECS; ------------------------------------------------------------------------ -- The procedure to emit the PDL for the bodies ------------------------------------------------------------------------ procedure EMIT_BODIES (NODE: in TREE_NODE_ACCESS_TYPE) is -- This procedure emits the PDL for the body of the current -- Tree node, and recursively invokes itself for contained -- entities of the current node. begin -- check if NODE is valid -- Increment the nesting level to show inside a body. case TREE(NODE).NODE_TYPE is when TYPE_VIRTUAL_PACKAGE | TYPE_PACKAGE => -- Skip this node if it is a Generic Instantiation. -- If the package is not already declared then declare it now. -- Write the 'WITH' statements of visible units. -- Write the 'start' of the package body. -- Scan the DATA_CONNECT_LIST and write the 'use's. -- Scan the CONTAINED_ENTITY_LIST for undeclared components, -- processing generic declarations in the first pass, and -- all others in the second pass. -- Loop and process the non-declared entities which are not -- generic declarations. -- Scan the EXPORTED_LIST for visible subprograms and -- packages which are not connected to other entities -- and hence should be declared as 'separate' -- Scan the CONTAINED_ENTITY_LIST and write the nested -- components. -- If a body exists then process for possible call connections. -- Write the 'end' of the package body. end if; when TYPE_PROCEDURE => -- Skip this node if it is a Generic Instantiation. -- Write the subprogram declaration. -- If the procedure has calling parameters then write them. -- Begin writing the declarative section. -- Write the prologue. -- Scan the DATA_CONNECT_LIST and write the 'use's. -- Scan the CONTAINED_ENTITY_LIST and write the nested components. -- End the declarative section. -- If a body exists then process for possible call connections. EMIT_BODIES (TREE(NODE).BODY_PTR); else -- Write the 'begin' followed by a null statement to permit -- compilation. end if; -- Write the 'end' statement. when TYPE_FUNCTION => -- Skip if this node is a Generic Instantiation. -- Write the function declaration. -- If the procedure has calling parameters then write them. -- Write the return portion of the declaration. -- Begin writing the declarative section. -- Write the prologue. -- Scan the DATA_CONNECT_LIST and write the 'use's. -- Scan the CONTAINED_ENTITY_LIST and write any nested components. -- End the declarative section. -- If a body exists then process for possible call connections. EMIT_BODIES (TREE(NODE).BODY_PTR); else -- Write the 'begin' statement. end if; -- Write the return statement to permit compilation. -- Write the 'end' statement. when TYPE_TASK => -- Write the task declarative statement. -- Begin writing the declarative section. -- Write the prologue. -- Scan the DATA_CONNECT_LIST and write the 'use's. -- Scan the CONTAINED_ENTITY_LIST and write any nested components. -- If a body exists then process for possible call connections. EMIT_BODIES (TREE(NODE).BODY_PTR); else -- Write the 'begin' statement. end if; -- Start writing the executable portion of the task body. -- Scan the ENTRY_LIST for the entry points and write -- the corresponding accept statements. -- Write a select structure if one or more entry points exists. -- Write a guard condition if the entry point is guarded. -- Write calling parameters if the entry point has them. else -- Write a null statement to permit compilation. WRITE_LINE ("null ;") ; end if; -- Write the 'end' of the task declaration. when TYPE_BODY => -- Output the start of the body -- Write the code for calls by traversing CALLEE_LIST. -- If no calls exist, then write a null body. -- If this call is for conditional or timed -- then write the first part of this call type. -- Callee List points to connections. -- If a connection is to an exported entity, check if it -- is connected to an inner level. -- For function calls write a variable for the return value. -- Write the name of the subprogram called. -- If this call is conditional or timed then -- write the closing part. -- Process next call in the list. end loop; end if ; when others => -- Should not occur here! Send an error message to the -- user an attempt to continue. end case; end EMIT_BODIES; <FF> 3. SOFTWARE ARCHITECTURE 3.1 GAD The Software Architecture of GAD will resemble that of the prototype version of the tool. Figure 3.1-1 illustrates the hierarchical organization of the functional modules. The following is a brief overview of the GAD functional components or modules: ------------------------------------------ ------- ------- | | | PDL_ | | A | | | | | | GENERATOR | ->| D | | V | | GAD | MMI |----------------| | A | | A | | | | GRAPH_ | | | | X | | | | TREE_ | | P | | / | | | | ACCESS | | R | | V | ------------------------------------------ | E | | M | | | D | ->| S | v | E | | | ------------------------------------------ | F | | O | | GRAPHICS_DRIVER | | I | | P | | | | N | | | ------------------------------------------ | E | | S | | | | D | | Y | v v | | | S | ------------------------------------------ | P | | T | | VIRTUAL_ | | | K | | E | | TERMINAL_ | GKS_PRIME | ->| G | | M | | INTERFACE | | | S | | | ------------------------------------------ ------- ------- Figure 3.1-1 GAD Architectural Diagram GAD: The MAIN procedure (Program Unit) of the tool. It controls the initialization, execution, and termination of GAD. GRAPH_TREE_ACCESS: This virtual package defines the data structure which holds the semantic and graphics data associated with the graph. It provides the necessary primitives to manipulate and access the tree. It provides I/O routines for the capture and preservation of design diagrams between editing sessions. MMI: This virtual package provides the MMI required to allow operator interaction with the tool. PDL_GENERATOR: This virtual package implements the subprograms which generate the Ada PDL from the Syntax Tree. GRAPHICS_DRIVER: This virtual package provides the routines to perform the graphics functions of GAD. GKS_PRIME: This virtual package provides a proper subset of the Graphical Kernel System (GKS). This module encapsulates all terminal specific characteristics of the system. VIRTUAL_TERMINAL_INTERFACE: This package provides a set of standard routines and data structures for ASCII Text I/O operations on a VT100 type terminals (actually ANSI X3.64). Figure 3.1-2 uses Ada Graphic Notation to illustrate the control flow relationships of the GAD components. ------------------------------------------------------------------------ | GRAPH_TREE_ACCESS | | ============== - - - - - - - | | | RUN_GAD | | | |============| | |->+-------------------->|DIRECT_IO | | | | ------- ^ | | | |->+--+->| | | | | | | | | ^ ------- | VIRTUAL_TERMINAL | | -------------- | | | | | - - - - - - | | | | - - - - - - - | | | | +--------------------+ | | | | | | ------- | | +-----------------------+---->| | | | | | PDL_GENERATOR | ------- | | | - - - - - - - | | |-+ | | | | | | - - - - - - | | | +------------------+ ------- | | | | | +---->| | | | | | | | | ------- | GKS_PRIME / | | | | | |--+ - - - - - v | | | | - - - - - - - | |-+->|TEXT_IO | | | MMI | GRAPHICS_DRIVER | | | - - - - - - | - - - - - - - | | | | | | ------- | | | | | | | | +--->| | | | | | | | ------- | | | ------- | ------- | | | | | +->| | |-+---->| | | | - - - - - | | ------- ------- ---+ | | | | | | | | - - - - - - - - - - - - - | ------------------------------------------------------------------------ Figure 3.1-2 GAD Control Flow Diagram 3.2 GRAPH_TREE_ACCESS The virtual package GRAPH_TREE_ACCESS contains the packages and subprograms which encapsulate the major data structure of the GAD. The virtual package provides three major facilities: the type declarations and objects which comprise the Syntax and Graph Trees, primitive routines for the manipulation of the Syntax Tree, and IO routines to preserve the data structures in a file between session. The compilations units are shown below, and the OODD of the GRAPH_TREE_ACCESS virtual package, which reflects its dependencies, is shown in Figure 3.2-1. TREE_DATA: The TREE_DATA package provides the declarations and objects for the Syntax and Graph Tree which holds all the graphical, syntax, and semantic information required by GAD. The tree is composed of TREE, LIST, GRAPH, and PROLOGUE nodes. See Section 2.2 for further details. TREE_OPS: The TREE_OPS package provides a set of operations on the Syntax Tree data structures declared in TREE_DATA. These operations include storage management for the nodes making up the tree (i.e., the allocation and release of the array elements which are the nodes), and operations which create, traverse, and delete subtrees utilizing the LIST nodes to store relations. The purpose of the TREE_OPS package is to centralize the structural manipulations of the Syntax Tree to avoid its accidental corruption. TREE_IO: The TREE_IO package provides all the necessary operations to read and write the Syntax Tree to/from files on the host file system. This package manipulates these data files which are Ada DIRECT_IO files composed of records containing the Node array elements used to store the Syntax and Graph Tree information, and a single record storing the symbol attributes utilized (thereby preserving changed attributes between sessions). <FF> GRAPH_TREE_ACCESS_VIRTUAL_PACKAGE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | ( TREE_DATA_TYPES ) ----------+ TREE_DATA : TREE_DATA_OBJECTS : ------+ | ------------------- | < TREE_OPS_EXCEPTS >-----+ | | | | ( TREE_IO_TYPES )--------+ | +---( DECLARATIONS ) | +-- < DIRECT_IO > : TREE_IO_OBJECTS :--+ | | | | +--<< GRAPHICS_DR >> < TREE_IO_EXCEPTS >---+ | +---- : DATA_OBJECTS : | | | | | | | | | | | ------------------- | | | | TREE_IO | | | | ------------------- | | | | | | | | | +-------( DECLARATIONS ) | | | | | | | |io_operations|---------------|io_operations| | | | | | |--+ | | | | | | ------------------- | | TREE_OPERATIONS | | -------------------------- | | | | | +-------( DECLARATIONS ) | | | | | | | |tree_ops|-----------------|tree_ops| | | | | | | | | -------------------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Figure 3.2-1 GRAPH_TREE_ACCESS Virtual Package Design Diagram 3.3 MMI The MMI virtual package provides the MMI functions of GAD. The operator interactively makes requests via the terminal input devices (keyboard and cursor control devices) to which the MMI routines respond in accordance with the requested function. Along with providing access to PDL generation and file management, all the design operations are processed within the MMI routines. The software architecture of the MMI is presented in Figure 3.3-1. The scope of the MMI is enclosed in the virtual package MMI. Within the scope of the virtual package are five packages which contain the MMI subprograms, variables, and declarations. The six packages are MMI, MMI_DESIGN, MMI_ATTRIBUTES, MMI_CONTROL_MENUS, MMI_PARAMETERS, and UTILITIES. Imported packages to the virtual package provide the lower level routines needed for the MMI operations. Those routines include such items as the terminal interface, graphic functions, and tree operations. Exports from the virtual package provide the access to the the MMI software. MMI: The package MMI contains the subprograms which are exported from the virtual package MMI. The three procedures (INITIALIZE, PANIC_EXIT, and PROCESS_COMMAND) provide the access to the MMI software. The INTIALIZE procedure is called during the start-up of the GAD to setup the menus and the terminal characteristics. PANIC_EXIT handles the saving of the current design file if the GAD program falls into a non-recoverable state. PROCESS_COMMAND is the main procedure for accepting user commands and then determining the path for program operation. MMI_DESIGN: MMI_DESIGN is the package in which most of the entity creation is performed. The processing of input during the creation of virtual packages, packages, subprograms, tasks, and executing bodies is within MMI_DESIGN, as are the modification routines. MMI_ATTRIBUTES: MMI_ATTRIBUTES exports two subprograms which provide access to the package routines. CONTROL_ANNOTATING_MENU contains the code for specifying import and export declarations and for creating connections. The MMI interactions that enable the user to alter the graphic color and line characteristics are within the function CONTROL_ATTRIBUTES_MENU. MMI_CONTROL_MENUS: MMI_CONTROL_MENUS handles the sub-menus of GAD. The sub-menus request the selection of the status of design structures. The prompts for call status, parameter status, and generic status are examples of items controlled in this package. The delete operations are within MMI_CONTROL_MENUS along with the MOVE_AND_RESIZE procedure. MMI_PARAMETERS: MMI_PARAMETERS contains the MMI variable and constant declarations. All of the items associated with the menu operations are defined within this package. The menu structure, commands, and icons are declared. UTILITIES: The virtual package UTILITIES contains the subprograms which implement repetitive functions performed at the MMI level. These functions access lower level packages such as TREE_OPS and GRAPHICS_DRIVER, often manipulating details which detract from normal MMI processing. This package contributes strongly to the maintainability and understandability of other MMI packages. <FF> MMI - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | MMI | --------------------- <SYSTEM > | | | <GKS_SPECIFICATION> ---- | | <GRAPHICS_DATA > | | | INITIALIZE | | <GRAPHIC_DRIVER > | |-->| PANIC_EXIT | | <PDL_GEN > | | | PROCESS_COMMAND | | <TREE_DATA > ---- | |---+ <TREE_OPS > | | | | <TREE_IO > --------------------- | <TEXT_IO > | | <VIRTUAL_TERMINAL_> | INTERFACE > | ----------------------------+ | / | | | | | | MMI_DESIGN | MMI_CONTROL_MENUS | | ------------------- | --------------------------- | | | | | | | | | | | V | | | +->| CONTROL_ | |--+->+->| =CONTROL_CALL_STATUS_ME | | | | DESIGN_MENU | | | | | =CONTROL_DELETE_MENU | | | | | | | | | =CONTROL_ENTRY_POINT_ST | | | | | | | | | =CONTROL_GENERIC_STATUS | | | | ------------------- | | | =CONTROL_PAN_AND_ZOOM_M | | | | | | | =CONTROL_PARAMETER_STAT | | | | ------------------------+ | | =CONTROL_PDL_STATUS_MEN | | | |/ | | DELETE | | | | | | DELETE_CONNECTION | | | | MMI_ATTRIBUTES | | MOVE_AND_RESIZE | | | | ------------------ | | |-+ | | | | | | | | | | | |------+ --------------------------- | | +->| CONTROL_ | | | | | | ANNOTATING_ | | | -------------------------------+ | | MENU | | |/ | | CONTROL_ | | | MMI_PARAMETERS | | ANNOTATING_ | | | --------------- | | MENU | | | | | | | | +->(DECLARATIONS) | | | | | | | | ------------------ | --------------- | | | | UTILITIES | | --------------- | | | | | +->(SUBPROGRAMS) | | | | | --------------- | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Figure 3.3-1 MMI Virtual Package Design Diagram 3.4 PDL_GENERATOR The virtual package PDL_GENERATOR contains the packages and subprograms which will generate the Ada PDL corresponding to the current OODD being developed. The compilation units are shown below, along with the OODD of the PDL_GENERATOR virtual package, which reflects its dependencies, is shown in Figure 3.4-1. PDL_GEN: This package contains the subprograms which perform the generation of the Ada PDL corresponding to the OODD described in the Syntax Tree. It exports parameters which control the PDL Generation, and a single procedure which implements the generation algorithm (See Section 2.3.3). The package also contains the numerous local subprograms required in PDL generation, which perform utility functions including specialized IO subprograms which perform the (optional) simultaneous writes to both a text file and the user's terminal. PDL_GENERATOR - - - - - - - - - - - - - - - - - - - - - - - - - - - - | PDL_GEN | --------------------------- < GRAPHICS_DATA > | | | | : PARAMETERS : --- : PARAMETERS : | +-< TEXT_IO > | | | +-<< GRAPH_TREE_ACCESS >> | | +-< VIRTUAL_TERMINAL_IN > | | | +-< UTILITIES > | | | | | ================= | | | |GENERATE_PDL|------>| |-->| GENERATE_PDL[]| | | | | |===============| | | | | | | | | | | | |------+ | | | | | | | ----------------- | | | | | --------------------------- | - - - - - - - - - - - - - - - - - - - - - - - - - - - - Figure 3.4-1 PDL_GENERATOR Virtual Package Design Diagram <FF> 3.5 GRAPHICS_DRIVER The virtual package GRAPHICS_DRIVER contains the packages and subprograms which provide the primitives required by GAD to communicate with the graphics features of the target terminal. The virtual package provides: the type declarations containing the graphic information for each entity in the graph, and the screen and graphic manipulation functions required to support GAD. The compilation units are shown below, and the OODD of the GRAPHICS_DRIVER virtual package, which reflects its dependencies, is shown in Figure 3.5-1. GRAPHICS_DATA: The GRAPHICS_DATA package provides the data types containing the graphic information (location and attributes) for each entity type in the graph, provides the type declarations which define the graphics world coordinate space utilized by GAD, defines the colors available to GAD, and provides the display attributes required to support GAD graphical primitives. GRAPHICS_DRIVER: The GRAPHICS_DRIVER package is designed to perform the low level graphics functions required by the GAD, and provides all the necessary screen and graphic manipulation functions needed to perform editing of GAD graphs. The target terminal is a VT-100 compatible bit-mapped graphics device; however, the package is independent of the bit-mapped oriented characteristics of the terminal. The requirements on the GRAPHICS_DRIVER package are as follows: - draw graphical entities, - erase graphical entities, - move graphical entities, - save and restore graphical entities, - initialize the graphics device, - restore the graphics device to VT-100 compatibility mode, and - provide a device and compiler independent interface. <FF> GRAPHIC_DRIVER - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | GRAPHICS_DATA | ---------------- < GRAPH_TREE_ACCESS > | | | < GKS_PRIME > ( GRAPHICS_DATA )<------( DECLARATIONS ) | < GKS_NON_STANDARD > ( TYPES ) | | < GKS_SPECIFICATION > ---------------- < VIRTUAL_TERMINAL_INTERFACE > | | GRAPHIC_DRIVER | -------------------------------- | ( GRAPHIC_DRIVER ) | | ( EXCEPTIONS )<---( DECLARATIONS ) | | | | | | |-------------->| CLEAR_MENU | | | | |-------------->| CLOSE_SEGMENT | | | |-------------->| DELETE_SEGMENT | | | | |-------------->| DISPLAY_MENU | | | |-------------->| DRAW_ABORT_ICON | | | | |-------------->| DRAW_BOX | | | |-------------->| DRAW_FIGURE | | | | |-------------->| DRAW_LINE | | | |-------------->| GET_GRAPHICS_CURSOR_POSITION | | | | |-------------->| GRAPHICS_SCREEN | | | |-------------->| HILITE_SEGMENT | | | | |-------------->| INITIALIZE_GRAPHICS_MODE | | | |-------------->| INIT_SCREEN | | | | |-------------->| LABEL | | | |-------------->| LOCATION_IN_GRAPHIC_VIEWPORT | | | | |-------------->| MOVE | | | |-------------->| OPEN_SEGMENT | | | | |-------------->| PAN | | | |-------------->| PAN_AND_ZOOM_DISPLAY | | | | |-------------->| PICK_SEGMENT | | | |-------------->| PLACE_CURSOR | | | | |-------------->| PRINT_SCREEN | | | |-------------->| REFRESH_SCREEN | | | | |-------------->| SELECT_WINDOW | | | |-------------->| SET_ABORT_CAPABILITY | | | | |-------------->| SET_CHARACTER_SIZE_ATTRIBUTES| | | |-------------->| SET_DRAWING_PRIORITY | | | | |-------------->| SET_SEGMENT_VISIBILITY | | | |-------------->| TERMINATE_GRAPHICS_MODE | | | | |-------------->| UPDATE_COLOR_ATTRIBUTE | | | |-------------->| UPDATE_LINE_ATTRIBUTE | | | | |-------------->| UPDATE_SHAPE_ATTRIBUTE | | | |-------------->| ZOOM | | | | | | -------------------------------- | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - GRAPHIC_DRIVER Virtual Package Design Diagram Figure 3.5-1 <FF> 3.6 GKS_PRIME The virtual package GKS_PRIME contains the packages and subprograms which implement a version of the Graphical Kernel System (GKS) developed by SYSCON Corporation for use with the GAD. This virtual package provides a proper subset of the GKS, and implements those operations required by the GAD. ( Refer to section 5.4.3 for further information regarding GKS_Prime. ) The virtual package provides: the type declarations and objects utilized by GKS_PRIME, and the functions defined by the GKS standard which are utilized by GAD. The compilation units are shown below, and the OODD of the GKS_PRIME virtual package, which reflects its dependencies, is shown in Figure 3.6-1. GKS_SPECIFICATION: The GKS_SPECIFICATION package provides the type declarations, objects, the various coordinate system spaces required to support GKS_PRIME and GKS_NON_STANDARD. The definitions which are contained in the GKS_SPECIFICATION package are those defined in the Draft GKS Binding to ANSI Ada [AdaGKS]. GKS_PRIME: The package GKS_PRIME provides the functions which implement a version of the Graphical Kernel System (GKS) developed by SYSCON Corporation. This package provides a proper subset of the GKS, and implements those operations required by the GAD. The subprogram calls which are contained in GKS_PRIME are those defined in the Draft GKS Binding to ANSI Ada [AdaGKS]. GKS_NON_STANDARD: The package GKS_NON_STANDARD provides the functions which require access to terminal hardware capabilities not addressed by standard GKS. The functions implemented in this package would be implemented via the ESCAPE and GDP functions defined in the standard. TERMINAL_ACCESS: The TERMINAL_ACCESS package provides a device independent set of subprograms which support graphic operations services. The primary function of this package is to support graphic operations in the graphic window. ( Refer to section 4.4 for a list of services provided by this package. ) <FF> GKS_PRIME - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | GKS_SPECIFICATION | ------------------ | | | | ( GKS_TYPES )<-------( DECLARATIONS ) | | | | | ------------------ | | GKS_PRIME | ----------------------------- TERMINAL_ACCESS | | | --------------- | | LEVEL_0A | | | | | ----------- | | | | | | | | ( DECLARATIONS ) | | | +---->| | |----->+ | | | | | ----------- | | | | | | | LEVEL_0B | +-->| .ALL | | | | | ----------- | | | |-+ | | | | | | | | | | | | | +->| | |----->+ --------------- | | | |-->| |---+ | ----------- |----->+ | | |-->| |------+ ----------- | | | | | |-->| |----+ LEVEL_1A | | | | |-->| |--+ | ----------- | | +->< SYSTEM > | | | | | | < TEXT_IO > | | | +--->| | |----->+ | | | ----------- | | | | LEVEL_1B | | | | | ----------- | | | | | | | | | | | +----->| | |----->+ | | ----------- | | | ----------------------------- | | | | GKS_NON_STANDARD | | ----------------------------- | | | LEVEL_0A | | | | ----------- | | | | | | | | |-->| |-------->| | |----->+ | | ----------- | | ----------------------------- | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - GKS_PRIME Virtual Package Design Diagram Figure 3.6-1. <FF> 3.7 VIRTUAL_TERMINAL_INTERFACE The virtual package VIRTUAL_TERMINAL_INTERFACE contains the subprograms which provide alphanumeric text services. The primary function of this virtual package is to support alphanumeric I/O to the alphanumeric window of the graphics terminal. The compilation units are shown below, and the OODD of the VIRTUAL_TERMINAL_ INTERFACE virtual package, which reflects its dependencies, is shown in Figure 3.7-1. VIRTUAL_TERMINAL_INTERFACE: The VIRTUAL_TERMINAL_INTERFACE package provides a set of device independent subprograms which support alphanumeric text services. The services provided by this package include cursor positioning, scrolling, string I/O, character I/O, integer I/O, real I/O, and screen erase features. The communcation codes generated by this package are targeted for a terminal which supports the ANSI X3.64 screen editing commands. VIRTUAL_TERMINAL - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | VIRTUAL_TERMINAL_INTERFACE | -------------------------------- | | | ( CRT_ROW ) | | | ( CRT_COL )<--( DECLARATIONS ) | < SYSTEM > ( FORMAT_FUNCTION ) | | < TEXT_IO > ( CURSOR_ADDRESS ) | | | | | | ------- ------------------------ | | |-------------->| VTI_INIT | | | | |-------------->| SCROLLING_REGION | | | |-------------->| MOVE_CURSOR_UP | | | | |-------------->| MOVE_CURSOR_DOWN | | | |-------------->| MOVE_CURSOR_RIGHT | | | | |-------------->| MOVE_CURSOR_LEFT | | | |-------------->| MOVE_CURSOR_TO | | | | |-------------->| LOW_LEVEL_OPERATIONS | | | |-------------->| STRINGIO | | | | |-------------->| CHARACTERIO | | | |-------------->| INTEGERIO | | | | |-------------->| REALIO | | | |-------------->| FORMAT_LINE | | | | |-------------->| KEY_PAD_IO | | ------- ------------------------ | | | | | -------------------------------- | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Virtual_Interface_VP Virtual Package Design Diagram Figure 3.7-1 <FF> 4. PROGRAM MAINTENANCE 4.1 Installation To install the Graphic Ada Designer onto a new host system, a system compatible Executable Image file must be created. GAD was delivered for the DEC VAX/VMS operating system version 4.2. If the new host system is running this exact version of the VMS operating system, all that will be required to install the program is to load the delivered Executable Image onto the system. To run the program simply enter the command: $ RUN device:[directory]GAD ! from other than the directory ! on which GAD is installed $ RUN GAD ! from the directory on which ! GAD is installed If the new host system is running a different version of VMS level 4, then the GAD Program Library must be loaded onto the system, and the program relinked to avoid Ada Run Time System incompatibility problems. The command to perform this is: $ SET DEF [directory containing the GAD program library] $ ACS SET LIBRARY [.ADALIB] $ ACS LINK GAD For all other host/operating system combinations, the GAD program will have to be rebuilt from the source. The compilation of the GAD is discussed in Section 4.1.1. Possible rehosting adaptations are discussed in Section 4.3. To make help available, the GAD Help File ("GADHELP.HLP") must be loaded onto the host system, and on VMS systems, the following assignment statement placed in user login files: $ ASSIGN device:[directory]GADHELP.HLP HELP_FILE 4.1.1 Program Compilation To compile the GAD, the source must first be loaded onto a single directory on the host system. The compilation units and the corresponding source file names (for the VMS system used to develop the program) are shown in Table 4.1-1. <FF> Table 4.1-1 Compilation Unit List Compilation Unit VMS Source File Name ---------------- ---------------------------- DIRECT_IO Predefined Generic Package GAD Procedure body Source file: GAD.ADA GKS_COORDINATE_SYSTEM Generic package declaration Source file: GKS_SPECIFICATION_SPEC.ADA GKS_NON_STANDARD Package specification Source file: GKS_NON_STANDARD_SPEC.ADA Package body Source file: GKS_NON_STANDARD_BODY.ADA GKS_PRIME Package specification Source file: GKS_PRIME_SPEC.ADA Package body Source file: GKS_PRIME_BODY.ADA GKS_SPECIFICATION Package specification Source file: GKS_SPECIFICATION_SPEC.ADA GRAPHICS_DATA Package specification Source file: GRAPHICS_DATA_SPEC.ADA GRAPHIC_DRIVER Package specification Source file: GRAPHIC_DRIVER_SPEC.ADA Package body Source file: GRAPHIC_DRIVER_BODY.ADA IO_EXCEPTIONS Predefined Package MATH_LIB Predefined Generic Package <FF> Table 4.1-1 Compilation Unit List continued Compilation Unit VMS Source File Name ---------------- ---------------------------- MMI Package specification Source file: MMI_SPEC.ADA Package body Source file: MMI_BODY.ADA MMI_ATTRIBUTES Package specification Source file: MMI_ATTRIBUTES_SPEC.ADA Package body Source file: MMI_ATTRIBUTES_BODY.ADA MMI_CONTROL_MENUS Package specification Source file: MMI_CONTROL_MENUS_SPEC.ADA Package body Source file: MMI_CONTROL_MENUS_BODY.ADA MMI_DESIGN Package specification Source file: MMI_DESIGN_SPEC.ADA Package body Source file: MMI_DESIGN_BODY.ADA MMI_PARAMETERS Package specification Source file: MMI_PARAMETERS_SPEC.ADA PDL_GEN Package specification Source file: PDL_GEN_SPEC.ADA Package body Source file: PDL_GEN_BODY.ADA SYSTEM Predefined Package TEKDRIVER Package specification Source file: TEKDRIVER_.ADA Package body Source file: TEKDRIVER.ADA TERMINAL_ACCESS Package specification Source file: TERMINAL_ACCESS_SPEC.ADA Package body Source file: TERMINAL_ACCESS_TEK_BODY.ADA <FF> Table 4.1-1 Compilation Unit List continued Compilation Unit VMS Source File Name ---------------- ---------------------------- TEXT_IO Predefined Package TRACE_PKG Package specification Source file: TRACE_PKG_SPEC.ADA Package body Source file: TRACE_PKG_BODY.ADA TREE_DATA Package specification Source file: TREE_DATA_SPEC.ADA Package body Source file: TREE_DATA_BODY.ADA TREE_IO Package specification Source file: TREE_IO_SPEC.ADA Package body Source file: TREE_IO_BODY.ADA TREE_OPS Package specification Source file: TREE_OPS_SPEC.ADA Package body Source file: TREE_OPS_BODY.ADA UTILITIES Package specification Source file: UTILITIES_SPEC.ADA Package body Source file: UTILITIES_BODY.ADA UTIL_FOR_TREE Package specification Source file: UTIL_FOR_TREE_SPEC.ADA Package body Source file: UTIL_FOR_TREE_BODY.ADA VIRTUAL_TERMINAL_INTERFACE Package specification Source file: VIRTUAL_TERMINAL_INTERFACE_SPEC.ADA Package body Source file: VIRTUAL_TERMINAL_INTERFACE_BODY.ADA To compile the program, a new program library must be created, and each of the compilation units entered into it. Using DEC Ada, the following commands would be required: $ ACS CREATE LIBRARY [.ADALIB] $ ADA source_file_name ! for each source unit. The compilation units should be entered into the program library in compilation order, and this order is shown in Table 4.1-2. The unit names given in this Table are the compilation units names (e.g., package names), and do not reflect the file names given for any particular host system. Once the program has been entered into the program library, then further compilations (e.g., after compile time parameter changes) can be performed with the command on $ ACS COMPILE GAD Table 4.1-2. Graphic Ada Designer Compilation Order ---------------------------------------------------- GKS_COORDINATE_SYSTEM_specification GKS_SPECIFICATION_specification GRAPHICS_DATA_specification TEKDRIVER_specification TEKDRIVER_body TRACE_PKG_specification TRACE_PKG_body TREE_DATA_specification TREE_DATA_body TERMINAL_ACCESS_specification TERMINAL_ACCESS_body VIRTUAL_TERMINAL_INTERFACE_specification VIRTUAL_TERMINAL_INTERFACE_body TREE_OPS_specification TREE_OPS_body TREE_IO_specification TREE_IO_body GKS_NON_STANDARD_specification GKS_NON_STANDARD_body GKS_PRIME_specification GKS_PRIME_body GRAPHIC_DRIVER_specification GRAPHIC_DRIVER_body MMI_PARAMETERS_specification <FF> Table 4.1-2. Graphic Ada Designer Compilation Order continued -------------------------------------------------------------- UTILITIES_specification UTILITIES_body PDL_GEN_specification PDL_GEN_body UTIL_FOR_TREE_specification UTIL_FOR_TREE_body MMI_CONTROL_MENUS_specification MMI_CONTROL_MENUS_body MMI_ATTRIBUTES_specification MMI_ATTRIBUTES_body MMI_DESIGN_specification MMI_DESIGN_body MMI_specification MMI_body GAD 4.2 Parameter Controlled Features Numerous compile-time parameters are located within the source code of the GAD program, that enable the maintainer to adapt the functionality of the GAD program to alternate user environments and methodologies. Table 4.2-1 presents a logical grouping of the parameter description. The implementer should be able to determine the parameters that need changing to suit a particular situation. Listed with the parameters is the package in which the parameter is declared. Table 4.2-2 lists the packages in alphabetical order, along with each of the parameters the package contains. The ordering of the parameters within each package follows the order presented in Table 4.2-1. A futher description of the parameter is provided along with instructions on modifying the value. Table 4.2-1. LOGICAL GROUPING OF PARAMETERS -------------------------------------------- SCREEN BACKROUND COLOR MMI (BODY) CHARACTER BACKROUND COLOR GRAPHICS_DATA (BODY) CHARACTER WIDTH GRAPHICS_DATA (SPEC) CHARACTER HEIGHT GRAPHICS_DATA (SPEC) CHARACTER WIDTH SPACING GRAPHICS_DATA (SPEC) CHARACTER HEIGHT SPACING GRAPHICS_DATA (SPEC) CHARACTER WIDTH OFFSET GRAPHICS_DATA (SPEC) CHARACTER HEIGHT OFFSET GRAPHICS_DATA (SPEC) <FF> Table 4.2-1. LOGICAL GROUPING OF PARAMETERS continued ------------------------------------------------------ INITIAL COLOR ATTRIBUTES GRAPHICS_DATA (SPEC) INITIAL LINE TYPE ATTRIBUTES GRAPHICS_DATA (SPEC) INITIAL VIEW WINDOW (PAN/ZOOM) GRAPHICS_DATA (BODY) SYMBOLS DEFINING IMPORTS AND EXPORTS GRAPHICS_DATA (SPEC) FUNCTION SYMBOL GRAPHICS_DATA (SPEC) TIMED CALL CONNECTION SYMBOL GRAPHICS_DATA (SPEC) CONDITIONAL CALL CONNECTION SYMBOL GRAPHICS_DATA (SPEC) GUARDED ENTRY POINT SYMBOL GRAPHICS_DATA (SPEC) GENERIC DECLARATION SYMBOL GRAPHICS_DATA (SPEC) GENERIC INSTANTIATION SYMBOL GRAPHICS_DATA (SPEC) VISIBILITY CLAUSE CONNECTION SYMBOL GRAPHICS_DATA (SPEC) REFERENCE MARKER ICON SYMBOL UTILITIES (BODY) MENU ICONS MMI_PARAMETERS (SPEC) MAXIMUM TREE NODES TREE_DATA (SPEC) MAXIMUM GRAPH NODES TREE_DATA (SPEC) MAXIMUM LIST NODES TREE_DATA (SPEC) MAXIMUM PROLOGUE NODES TREE_DATA (SPEC) NUMBER OF PROLOGUE LINES TREE_DATA (SPEC) MAXIMUM LINE SEGMENTS PER LINE TREE_DATA (SPEC) MAXIMUM ENTITY NAME LENGTH TREE_DATA (SPEC) FILE ID LENGTH TREE_IO (SPEC) STACK SIZE TREE_OPS (SPEC) MAXIMUM NESTING LEVEL GRAPHICS_DATA (SPEC) HELP FILE TEXT SYSTEM FILE: GADHELP.HLP ERROR MESSAGES throughout code PROMPTS throughout code <FF> Table 4.2-2. INFORMATION FOR MODIFICATION OF PARAMETERS -------------------------------------------------------- GRAPHICS_DATA (BODY) CHARACTER BACKROUND COLOR The backround color of the alphanumeric text. CURRENT_TEXT_BACKROUND_COLOR : GRAPHICS_DATA.COLOR_TYPE := GRAPHICS_DATA.YELLOW ; INITIAL VIEW WINDOW (PAN/ZOOM) The initial setting of the view window on the design page when GAD is executed. The range of values is 1 (full zoom in) to 16 (full zoom out). INITIAL_WINDOW_SIZE : constant INTEGER := 8 ; GRAPHICS_DATA (SPEC) CHARACTER HEIGHT, CHARACTER WIDTH, CHARACTER HEIGHT SPACING, CHARACTER WIDTH SPACING, CHARACTER HEIGHT OFFSET, CHARACTER WIDTH OFFSET Constants for character sizing. The offset values are used to position the labels on the graph. The user should be prepared to test several iterations when changing these variables because they can be difficult to "fine tune". The values are scaled on the world coordinates range of 0 .. 32767. DEFAULT_CHARACTER_HEIGHT : constant WC := 200 ; DEFAULT_CHARACTER_WIDTH : constant WC := 150 ; DEFAULT_CHARACTER_HEIGHT_SPACING : constant WC := 100 ; DEFAULT_CHARACTER_WIDTH_SPACING : constant WC := 75 ; CHARACTER_HEIGHT_OFFSET : constant WC := DEFAULT_CHARACTER_HEIGHT + DEFAULT_CHARACTER_HEIGHT_SPACING ; CHARACTER_WIDTH_OFFSET : constant WC := DEFAULT_CHARACTER_WIDTH + DEFAULT_CHARACTER_WIDTH_SPACING ; INITIAL COLOR ATTRIBUTES The colors to be used in drawing. Note that the defined values are (ORANGE, GREEN, YELLOW, VIOLET, RED, BLUE, BLACK, BROWN). ENTITY_COLOR : COLOR_ARRAY := ( VIRTUAL_PKG_FIGURE => COLOR_TYPE'( BLACK ), PACKAGE_FIGURE => COLOR_TYPE'( BLACK ), SUBPROGRAM_FIGURE => COLOR_TYPE'( BLACK ), TASK_FIGURE => COLOR_TYPE'( BLACK ), BODY_FIGURE => COLOR_TYPE'( BLACK ), CALL_CONNECT_LINE => COLOR_TYPE'( BLACK ), DATA_CONNECT_LINE => COLOR_TYPE'( BLACK ) , EXPORT_CONNECT_LINE => COLOR_TYPE'( BLACK ) ); <FF> Table 4.2-2. INFORMATION FOR MODIFICATION OF PARAMETERS continued ------------------------------------------------------------------ GRAPHICS_DATA (SPEC) (cont.) INITIAL LINE TYPE ATTRIBUTES The line types to be used in drawing lines. Note that the defined values are (SOLID, DASHED, DOTTED). ENTITY_LINE : LINE_ARRAY := ( VIRTUAL_PKG_FIGURE => LINE_TYPE'( DASHED ), PACKAGE_FIGURE => LINE_TYPE'( SOLID ), SUBPROGRAM_FIGURE => LINE_TYPE'( SOLID ), TASK_FIGURE => LINE_TYPE'( SOLID ), BODY_FIGURE => LINE_TYPE'( SOLID ), CALL_CONNECT_LINE => LINE_TYPE'( SOLID ), DATA_CONNECT_LINE => LINE_TYPE'( DOTTED ) , EXPORT_CONNECT_LINE => LINE_TYPE'( DOTTED ) ); SYMBOLS DEFINING IMPORTS AND EXPORTS The symbols defining the various kinds of imports and exports. Note that the declaration of the parent type is IMPORT_EXPORT_SYMBOL_TYPE is array (1..2) of STRING (1..1) ; PKG_DECL : IMPORT_EXPORT_SYMBOL_TYPE := ("#","#") ; VIRT_PKG_DECL : IMPORT_EXPORT_SYMBOL_TYPE := ("%","%") ; TYPE_DECL : IMPORT_EXPORT_SYMBOL_TYPE := ("(",")") ; OBJECT_DECL : IMPORT_EXPORT_SYMBOL_TYPE := (":",":") ; EXCEPTION_DECL : IMPORT_EXPORT_SYMBOL_TYPE := ("<",">") ; SUBPROG_DECL : IMPORT_EXPORT_SYMBOL_TYPE := ("|","|") ; PARAMS_DECL : IMPORT_EXPORT_SYMBOL_TYPE := ("[","]") ; TASK_ENTRY_DECL : IMPORT_EXPORT_SYMBOL_TYPE := ("/","/") ; FUNCTION SYMBOL, TIMED CALL CONNECTION SYMBOL, CONDITIONAL CALL CONNECTION SYMBOL, GUARDED ENTRY POINT SYMBOL, GENERIC DECLARATION SYMBOL, GENERIC INSTANTIATION SYMBOL, WITH&USE CLAUSE CONNECTION SYMBOL The graphical symbols defining the information parameters. Note that the length of the string should not be changed. FUNCTION_SYMBOL : INDICATOR_LENGTH_1 := "=" ; TIMED_CALL_SYMBOL : INDICATOR_LENGTH_1 := "T" ; CONDITIONAL_CALL_SYMBOL : INDICATOR_LENGTH_1 := "C" ; GUARDED_ENTRY_SYMBOL : INDICATOR_LENGTH_1 := "*" ; GENERIC_DECL_SYMBOL : INDICATOR_LENGTH_2 := "gd" ; GENERIC_INST_SYMBOL : INDICATOR_LENGTH_2 := "gi" ; DATA_ORIGIN_SYMBOL : INDICATOR_LENGTH_1 := "D" ; <FF> Table 4.2-2. INFORMATION FOR MODIFICATION OF PARAMETERS continued ------------------------------------------------------------------ GRAPHICS_DATA (SPEC) (cont.) MAXIMUM ENTITY NAME LENGTH The maximum length for entity names. MAXIMUM_NAME_LENGTH : constant POSITIVE := 80 ; MAXIMUM NESTING LEVEL The maximum nesting level for enclosing objects when creating graphs. MAX_NESTING_LEVEL : constant INTEGER := 6 ; MMI (BODY) SCREEN BACKROUND COLOR The backround color of the graphics screen. DEFAULT_SCREEN_COLOR : constant COLOR_TYPE := WHITE ; MMI_PARAMETERS (SPEC) MENU ICONS The text displayed within the menu icons can be modified by replacing the string initialization. These are just two examples of the many string values. Note that all the icons string lengths must be equal. ( MAIN_MENU => (1 => HELP_CMD , " HELP "), . . (5 => DESIGN_CMD, " DESIGN "), <FF> Table 4.2-2. INFORMATION FOR MODIFICATION OF PARAMETERS continued ------------------------------------------------------------------ TREE_DATA (SPEC) MAXIMUM TREE NODES, MAXIMUM GRAPH NODES, MAXIMUM LIST NODES, MAXIMUM PROLOGUE NODES The number of nodes within the tree structure. These variables limit the size of the GAD design files. Since the memory is statically allocated, the values should not be dramatically increased. Any alteration of these values will invalidate previously created GAD design files. MAX_TREE_NODES : constant TREE_NODE_ACCESS_TYPE := 99 ; MAX_GRAPH_NODES : constant GRAPH_NODE_ACCESS_TYPE := 199 ; MAX_LIST_NODES : constant LIST_NODE_ACCESS_TYPE := 199 ; MAX_PROLOGUE_NODES : constant PROLOGUE_NODE_ACCESS_TYPE := 99 ; NUMBER OF PROLOGUE LINES The number of lines available for prologues of graphical entities. Any alteration of this values will invalidate previously created GAD design files. If this value is increased, it is possible the record length of the GAD file will need to be increased (reference the Section 4.3 below). PROLOGUE_COUNT : constant NATURAL := 3 ; MAXIMUM LINE SEGMENTS PER LINE The number of line segments available when creating lines on the graph. MAXIMUM_NO_SEGEMENTS : constant INTEGER := 20 ; TREE_IO (SPEC) FILE ID LENGTH The number of characters available when creating file names within GAD. The value should be set to the system limit (before adding the extension). MAX_FILENAME_SIZE : constant INTEGER := 43 ; TREE_OPS (SPEC) STACK SIZE The maximum depth of the stack when executing a tree walk operation. This value should only be altered if the maximum nesting level for entities is increased. STACK_SIZE : constant NATURAL := 20 ; <FF> Table 4.2-2. INFORMATION FOR MODIFICATION OF PARAMETERS continued ------------------------------------------------------------------ UTILITIES (BODY) REFERENCE MARKER ICON SYMBOL The character that is displayed when a cursor control device reference point is marked on the graph. The character should be a designated GKS marker such as ".", "+", "*", "o", "x". MARKER_ICON : constant STRING(1..1) := "*" ; SYSTEM FILE: GADHELP.HLP HELP FILE TEXT The text of the help file can be altered using the system editor. The structure of the file should not be changed. A discussion on the help file is in Appendix A of the GAD User's Guide. throughout code ERROR MESSAGES, PROMPTS If the text of error messages and prompts needs to be altered, the implementer must locate the string(s) in question. A simple replacement of the string should be sufficient. Note that, if there is a corresponding assignment of the string to a variable, the length of the string should remain constant. 4.3 System Rehosting The Graphic Ada Designer initial host environment is a VAX, using the VMS operating system version 4.2. The VAX Ada compiler and program library manager (ACS) were used for the development of the GAD program. GAD is written in machine and compiler independent Ada, and GAD will only be dependent on the graphics terminal and printer used. The GAD Ada source code should rehost to a system with an Ada Programming Support Environment and standard ANSI communications (RS232). A recompilation of the source code, and the appropriate system link with the new host's Ada Run Time System (RTS), is all that should be necessary. Anyone considering rehosting the GAD should read this entire report, paying particular attention to Sections 2 through 4, and consulting Section 4.4 for information on Graphics Terminal Retargeting. Should the implementer encounter a problem when rehosting the GAD, it should be with an "implementation defined" feature of Ada. Presented below are the Ada features with implementation dependencies, which could present problems during rehosting. The IO operations of the VAX Ada Run Time System are performed by the Record Management System (RMS) of the VMS operating system. RMS does not allow true character IO operations, and is dependent on a carriage return for termination of an IO operation. Therefore, the GAD does not contain dependencies on true character IO operations. If it appears the GAD program is working with character data (e.g., character GETs and PUTs), it is still doing so within the framework of record based (line-at-a-time) IO operations. GAD utilizes an instantiation of DIRECT_IO to read and write the data files which store the Syntax Tree. The instantiation of DIRECT_IO, when working with the VMS operating system and Ada environment, is performed in the package body of TREE_IO. It is possible that the implementer's operating environment may require the handling of the instantiation differently. Essentially, the current GAD instantiates DIRECT_IO by: with DIRECT_IO ; package body TREE_IO is . . type DATA_RECORD_TYPE is ( NODE_RECORD, ATTRIBUTE_HEADER_REORD ) ; type IO_NODE_TYPE ( RECORD_TYPE : DATA_RECORD_TYPE ) is record . . end record ; package NODE_IO is new DIRECT_IO (IO_NODE_TYPE) ; use NODE_IO ; . . end TREE_IO ; RMS requires that DIRECT_IO files of variant records set the record length of the file during file creation. File creations are also performed in package body of TREE_IO, and the value, which is currently set to 512, is specified in bytes and must be big enough to hold a data record consisting of a GRAPH_NODE, LIST_NODE, PROLOGUE_NODE, and TREE_NODE. The declaration of the record length is part of a "CREATE" call, and utilizes the FORM parameter to pass a string with the record size to the RMS facilities of VMS. CREATE (FILE_HANDLE , OUT_FILE , FILE , FORM => "RECORD , SIZE 512 " ) ; Also, within the record structure of the GAD graphics file is a variant part. The tree node length varies depending on the graphic entity that it represents. Note that in VAX Ada, all array and record components are aligned on byte boundaries by default. Due to significant differences in storage allocation and alignment between RTS, it is highly unlikely that GAD data files will be interchangeable between GAD versions operating on different Ada RTSs. Another important IO characteristic of the GAD is the format of the data transmitted to the graphics terminal. The GAD currently operates with eight-bit, no parity data. Eight-bit bytes are a requirement because of the construction of the various escape sequences needed to communicate graphics data between the GAD program and the graphics terminal. All experimentation with alternate data formats (other than 8 bit) to date have resulted in failure. 4.4 Graphics Terminal Retargeting Communication with the graphics terminal is performed by two packages of the GAD program, the Virtual Terminal Interface package, and the GKS_Prime package (anyone considering rehosting the Graphic Ada Designer should read this entire report, paying particular attention to Sections 2 through 4, for more information of the items discussed in this section). Since the graphics terminal supported by these packages is the Tektronix 4107, any terminal which is under consideration as a new target terminal for the GAD should have hardware capabilities similar to the current target terminal. The hardware capabilities of the Tektronix 4107 which are utilized by the GAD are: - ANSI X3.64 screen editing commands, - bit-mapped colors, - selectable line types, - selectable marker types, - multiple views, - support for segment operations, including open/create, rename, close, delete, visibility, and highlighting - separate display surfaces for graphic operations and alphanumeric text, - graphics input ( cursor screen location ). The Virtual Terminal Interface package consists of a device independent set of subprograms which provide alphanumeric text services. The primary function of this package is to support alphanumeric I/O to the alphanumeric window. Services provided by this package include cursor positioning, scrolling, string I/O, character I/O, integer I/O, real I/O, and screen erase features. The communication codes generated by this package are targeted for a terminal which supports the ANSI X3.64 screen editing commands. The GKS_Prime virtual package is a set of packages which implement a version of the GKS developed by SYSCON Corporation for use with the GAD. This package provides a proper subset of the GKS, and implements those operations required by the GAD. ( Refer to Section 5.4.3 for further information regarding GKS_Prime. ) Another package of the GKS_Prime virtual package, the Terminal Access package, provides a level of abstraction between the GKS_Prime package and the graphics hardware, and all communication between the GKS_Prime package and the graphics features of the terminal hardware is performed through this package. The Terminal Access package is functionally embedded within the GKS_Prime virtual package. The Terminal Access package consists of a device independent set of subprograms which provides graphic operations services. The primary function of this package is to support graphic operations to the graphic window. Services provided by this package include: - terminal initialization and termination, - operations to support segment operations, including creation, manipulation, deletion, visibility, and highlighting, - window to viewport mapping, - world coordinate to terminal coordinate mapping - the generation of graphic entities, including polygons, polymarkers, and graphic text, - color selection, - marker selection, - line style selection, - and graphic input. If the GAD is transitioned to a different graphics terminal, the new terminal should have hardware capabilities similar to those found on the Tektronix 4107. If the new terminal supports the ANSI X3.64 screen editing commands, then no changes are required to the Virtual Terminal Interface package; if the terminal does not support this standard, then the Virtual Terminal Interface package must be updated to provide the alphanumeric text services currently supported by this package. Since all communication between the GKS_Prime package and the graphics hardware is performed through the Terminal Access package, this package will have to be be rewritten to provide the graphics operations services which the package currently supports. All terminal hardware characteristics are encapsulated in the Terminal Access package so no changes would be required to any other package of the GAD program, with the possible exception of the Virtual Terminal Interface package when the program is retargeted to a new graphics terminal. The amount of rewriting required to this package will be a function of how closely the new target terminal hardware capabilities parallel the capabilities of the Tektronix 4107. It is possible to transition the GAD to new graphics terminals which lack the hardware capabilities of the Tektronix 4107. However, the graphics services previously provided by the hardware must be implemented by software embedded in the Terminal Access package or GAD functionality will be impaired. The graphics services required by the GAD are multiple views, segment operations, separate display surfaces for graphics and alphanumeric text, and graphics input ( cursor screen location ). These capabilities must be provided by the the Terminal Access package. It is possible to implement some of these capabilities in software, but at a cost of degraded GAD performance. For example, implementing a package to support segment operations would require utilizing this package for nearly every terminal activity, since the GAD graphic operations are built on the concept of graphic segments. Other graphics services utilized by the GAD, but which are not essential for GAD performance, include selectable colors, line types, and marker types. These features are not required for correct GAD execution, but the lack of these features would have a detrimental impact on the MMI. For example, it is possible to transition the GAD to a graphics terminal which has no color capabilities. However, the ability to differentiate among graphic objects by their individual colors, and the ability to highlight segments by altering the display colors, would be lost. <FF> 5. DEVELOPMENT AND TECHNICAL ISSUES 5.1 Lessons Learned Numerous lessons were learned and/or re-enforced during the development of the Graphic Ada Designer. The results of many of these lessons are reflected in other Sections of this report. The items listed below summarize the lessons learned on this project and cross-reference others sections when appropriate. o Rapid Prototyping is an excellent approach to developing Ada software. This is particularly true for interactive tools where usage and functionality need to be investigated. The use of rapid prototyping provides feedback on the design's characteristics early in the project lifecycle, and permits feedback to be incorporated without requiring major design and documentation overhauls. See Section 5.2 for a discussion of the Development Approach used. o The successful use of rapid prototyping as a software development approach requires constant attention to architectural and maintenance issues as the software iterates to its final configuration. Care must be taken to avoid unnecessary duplication of code, and loss of abstraction as new details are added. During GAD development, identifying 'utility' functions, particularly in the MMI, was a continuous effort. o The addition of a Man-Machine Interface review between the Critical Design Review and Product Delivery Review contributed significantly to the quality of the tool, particularly in terms of its usability. Outside evaluation of the man-machine aspects of the tool provided extremely useful alternate views, and permited timely 'tweaking' of the interface which would not have been possible if it had occured at the Product Delivery Review. o During the development of portable device-dependent software, it is an excellent practice to isolate the device dependencies. This was done very effectively on the GAD, and a terminal retarget (on a separate project) has been performed to confirm the effectiveness of this approach. A strong point of the Ada language is its package feature, which provides an excellent information hiding mechanism. GAD incorporates GKS (see Section 5.4.3) as one layer of abstraction. o The use of the Graphical Kernel System on the GAD project had mixed results. The Ada binding had not been completely defined when the project began, so a substitute (GKS_PRIME) was developed. During the project, questions arose concerning the semantic interpretation of the GKS standard, and the semantic correctness of GKS_PRIME. The use of GKS provided an excellent starting point for creating software to isolate device dependencies. As the project proceeded, however, several occassions occurred where the limitations of GKS had to be circumvented (use of non-standard features), or assumptions made concerning device driver implementations, to prevent a reduction in the effectivenss of the tool. o During the project, the software was transitioned from one compiler to another. Overall this was done very easily, which is a testament to the inherent transportability of Ada and our design. Some problems were detected with the second Ada compiler, which slipped through the first, showing the importance of good error detection in the development compiler. Perhaps the most difficult task faced during the transition was debugging a large integrated piece of code with tools with which the staff was unfamilar. The most severe problems had to do with IO, and these are discussed in the next paragraph. o Our experience with Ada on this project shows that the area of IO continues to be one of the major obstacles to portability. Our problem occurred due to the difference in functionality of the character-read subprogram of package TEXT_IO. The first compiler used on this project supported true character IO, which is what is best suited to this application. The second compiler did not complete character reads until an end-of-record was detected. This is (was) a real problem, particularly when writing terminal driver software which must process escape code sequences from the terminal in a reasonable time frame. Although this problem was overcome for GAD, several other similar tools SYSCON has developed have required the use of non-portable system service calls. The use of system service calls to perform IO has been observed to be incompatible with standard IO calls on these same past projects. 5.2 Development Approach The development approach used by SYSCON in the development of the GAD is a multi-phased approach intended to optimize the quality of the interactive tool under development. The phases of the development are shown in Table 5.2-1. <FF> Table 5.2-1 GAD Development Phases ----------------------------------- Concept Formulation Establish Objectives and Requirements Define Functionality (User's Manual) Define Hardware Environment Design Prototyping of Key Features Macroscopic Design Microscopic Design Code and Debug \ \ Integration and Testing > Iterative / Evaluation / (including MMI Design Review) Several of the phases and sub-phases contributed significantly to the quality of the final product. Prototyping was used early in the design phase to obtain a thorough understanding of the operation of the terminal and optimal methods for interacting with it, and to develop a set of packages implementing and manipulating the central data structure of the GAD, the Syntax Tree (see Section 2.2). The iterative application of the final three phases (Code and Debug, Integration and Testing, and Evaluation) provided a mechanism for refining the functionality and performance of the GAD. Although the first development phase includes the definition of the Man-Machine Interface, SYSCON recognized that only experience with usage of the tool itself will provide adequate understanding of the interface (especially given the newness of the application). The iterative approach results in a significant strengthening of the MMI functionality and usability by incorporating feedback obtained during several evaluation cycles. The development approach also made extensive use several development techniques/methods to assist in optimal utilization of advanced software engineering practises and Ada in the development effort. The techniques and their benefits were: Usage of the Ada Graphic Notation Conventions to construct OODDs describing the intended architecture of the program. - provide a clear view of program architecture - evaluate interconnectivity of program modules - provide aid in managing development of the program Usage of prototyping to evaluate, validate and investigate critical aspects of the design such as hardware functionality, low level software interfaces and utilities, and MMIs. - avoid redesign due to misuse of hardware facilities - provide stable low-level software interfaces and utilities - provide a stable and realistic MMI Utilize compilable and executable Ada PDL to establish and enforce desirable design characteristics, and provide a testbed for integrating software as it is developed. - provide design consistency - provide correct usage of Ada language features - establish a uniform level of design detail - emphasize early data type definitions - provide software integration mechanism 5.3 Ada Issues Ada provides a powerful implementation language that is well suited to the writing of a rehostable and retargetable interactive graphics editor such as the GAD. Several significant issues relating to the use of Ada are relevent to the development and maintenance of the GAD software. These issues are 1) compiler selection, 2) the impact of utilizing an incomplete non-production quality Ada compiler during design, 3) the impact of transitioning the GAD to the DEC Ada compiler midway through the development effort, and 4) the possible methods of adapting the GAD packages to rehost and/or retarget the software. The last issue is discussed extensively in Sections 4.3 and 4.4. 5.3.1 Compiler Selection The design and development activities of the Graphic Ada Designer project were initially conducted using the Government supplied target compiler, which was the most recent release (at the time) of the TeleSoft Ada compiler. The TeleSoft compiler release utilized contained two Ada compiler versions: Version 2.1, which is a certified pre-release version of the TeleSoft Ada compiler awaiting validation, and Version 1.5, which is an incomplete Ada compiler with near-production quality performance in terms of compilation speed. The project was initiated using the Version 2.1 compiler in the hopes of utilizing full Ada, with its significant advantages for developing generalized code. Unfortunately, the performance and support facilities of the Version 2.1 compiler were too poor to continue using it beyond several early prototyping efforts. This necessitated a conversion of the project and the design to the TeleSoft Version 1.5 compiler. The following shortcomings were the principal factors leading to the decision to disgard the Version 2.1 compiler: - Extremely slow compilation speed. During algorithm and hardware prototyping activities, turnaround times normally exceeded one hour, and averaged over two hours during normal business hours. Extrapolating the turnaround time for the full implementation indicated that it was highly probable that two or fewer compilations of the GAD software would be possible per day. - The program library facility was extremely primitive. Each time a main program unit was to be recompiled, special TeleSoft utilities had to be invoked to reset the tables used to track compilation units in the library. The library reset facility was slow and subject to errors (i.e., it was easy to remove too many or too few units) which would necessitate the reinitialization of the library (including recompilation of all units). - The TeleSoft Ada development system lacked any interactive debugging and tracing facilities. Thus, debugging was usually reduced to an iterative process consisting of manually inserting trace statements in the code under development, followed by recompilation and additional testing. The primitive state of the debugging facilities in the TeleSoft compiler system made rapid and reliable compilation turnaround a necessity. This fact, in combination with the poor compilation speed and unreliable program library facilities, made the risk of continuing development with the TeleSoft Version 2.1 compiler too great. Part way through the project Digital Equipment Corporation announced the availability of a validated Ada compiler for use with its VAX/VMS operating system. Evaluation of the DEC Ada compiler by SYSCON and other DoD and Industry teams soon established its performance characteristics as far superior to those of the TeleSoft compiler in use. After a brief period of experimentation with an early copy of the TeleSoft Production Quality compiler, SYSCON elected to purchase and install a copy of the DEC Ada compiler on its VAX. Shortly thereafter, with the approval of the WIS/JPMO, the GAD project was transitioned to the DEC Ada compiler. 5.3.2 Compiler Impact on Design and Implementation The TeleSoft Version 1.5 compiler was used to perform the initial design and development of the packages comprising the GAD. This compiler lacked numerous Ada features, several of which had a significant impact on the design and implementation of the system. These features are: - generics - named associations for aggregates and calling parameters - dynamic record constructs - type attributes (incomplete) - universal expressions - derived types - support for 32-bit Integer arithmetic These missing features impacted the design by forcing a shift from full Ada to the subset effectively supported by the compiler. This shift altered the design in the following fashion: - prevented the use of dynamic calculations to define, initialize, and manipulate data structure components, which altered the top-level program architecture and program initialization code. - prevented the use of generics forcing the development of generalized and often replicated code in place of instantiations of utility subprograms. - prevented the use of derived types in segregating unrelated integer type data. - forced the splitting of packages (instead of the use of subunits) due to restrictions on the maximum size of compilation units. 5.3.3 Compiler Transition As initially discussed in Section 5.2, the GAD project transitioned during the Code and Debug development phase from the TeleSoft Version 1.5 compiler to the DEC Ada compiler. The utilization of this compiler enhanced the productivity of the staff and the quality of GAD software by providing the following facilities: - substantial increase in compilation rates. - complete Program Library Facilities including automatic minimal recompilation of programs and version control. - support for the full Ada language. - an interactive source level debugger. The transition effort required approximately two calendar weeks to complete, and resulted in the expected quality and productivity improvements. The major problem encountered in performing the transition was removing the errors previously tolerated by the TeleSoft compiler (e.g., contraints errors and improper type conversions). These errors were uniformly distributed throughout the software, and effectively required the debugging of the entire program at once (this certainly forced us to quickly learn how to use the interactive debugger). Some other interesting conversion activities which occured were: - The development of a routine to remove the leading space from the INTEGER'image function for use in generating escape sequences to the terminal. TeleSoft had not generated the space as required by the [AdaLRM]. - The insertion of a compiler specific "Form" parameter in the Create call for DIRECT_IO to establish the maximum record size. - Moderate rework of the IO packages due to the different handling of character IO by the DEC Run Time System (RTS). The DEC RTS only completes IO calls after an entire record (generally denoted by a <CR>) has been entered. This was by far the most persistent of the problems, and continues to hamper the achievement of the desired level of robustness. During the remaining portion of the development activities, most of the non-architectural shortcomings of the design forced by initial use of a subset compiler were removed. The initialization sections of the code were virtually completely redone, and numerous other changes were made which consolidated code fragments and resulted in significantly more maintainable code. Nevertheless, the early subset compiler influence can still be seen in the architectural decomposition of the program. 5.4 Key Technology Assessment 5.4.1 Ada-based Intermediate Language with Graphics Attributes The GAD utilizes an Ada-based Intermediate Language, whose Ada binding is the Syntax Tree data structure described in Section 2.2. The Intermediate Language is the corner stone of the GAD in that all graph editing functions which can be performed require the use of the Syntax Tree. These functions include: - entity and connection deletion - entity attribute modification - entity creation - scope search - semantic checking Each of these functions require access to the information stored in the nodes of the Syntax Tree and, more importantly, in the relationships which exist (or can exist) between the nodes. For example, in a scope search the Syntax Tree is walked by traversing the node relationships looking for the entity which most tightly encloses the selected point (by examining the location information associated with each entities node). The graphical implications of the Ada semantics (non-overlapping scopes) permits a tree-pruning approach to locating the entity, which is significantly more efficient than an exhaustive search. The existing and potential capabilities of the GAD are defined by the information which can be represented in the Intermediate Language. The addition and/or deletion of attribute information to the various node types is fairly straightforward, such as might be done in providing information on parameter modes, generic parameters, expanded prologues, and data and object types. Alteration of the structural binding of the nodes is not nearly so easy, and thus the inter-node relationships are the primary factor in defining the capabilities and restrictions on the functionality of the GAD. The nature of the currently defined relations (implemented largely as Lists) is one of Ada semantics, which tends to force the semantic correctness of any graph created as well as limiting the programs flexibility in terms of performing functions which produce graphs without proper Ada semantic equivalence. For this reason, the Syntax Tree was one of two critical areas prototyped during the design phase. The implementation of the Ada-based Intermediate Language in Ada has shown several significant advantages over other languages. Each node was described as a variant record which contained some or all of the previously defined inter-node relationships. Algorithms for manipulating nodes and lists could be very general because of the constraint checking performed by Ada language, i.e., Ada exception handling automatically caught invalid operations, thereby eliminating the extensive code otherwise required to perform the same checking. 5.4.2 Semantic Checking in Interactive Graphics Editing A unique feature of the GAD is the semantic checking which it performs during the editing of graphs. The program forces the user to create OODDs which are semantically correct from an architectural perspective. SYSCON observed and addressed a number of issues in implementing the GAD with this capability. The semantic checking implemented by the GAD is performed "on-the-fly", such that each successive state transition (and hence state) is semantically checked. This is in contrast to the other primary approach to semantic checking, wherein checking is performed "on-request". SYSCON elected to implement the GAD with "on-the-fly" checking due to several potential difficulties with implementing "on-request" semantic checking. These difficulties center around the problems of locating errors which have a graphical (positional) origin, particularly for the notational conventions which are supported. It is conceivable that a user could create an invalid graph whose corresponding graph could never be uncorrupted (i.e., reduced to an unambiguous semantic state). Another problem with using an "on-request" approach is the difficultly in providing automatic support for correctly completing a operation, since there is no notion of correctness in intermediate states. Using the "on-the-fly" approach to create semantically correct OODDs, the number of design options available to the designer have been intentionally limited to those which are correct. In some cases, a user of the GAD may wish to represent and/or consider a design which is not semantically correct Ada. This could occur on a mixed development language project, as an intermediate state during a reorganization of the design, or because the designer wishes to show abstractions in a way which is not valid Ada. In SYSCON's experience with the non-semantic checking predecessor of the GAD, a common phenomena was the expression of a valid Ada program with semantically invalid graphs which the human reader could easily and logically complete correctly. The non-valid graphs were esthetically more pleasing and felt to be as informative, even if not as semantically correct. The utilization of incorrect graphs is not permited by GAD, and experience with GAD has shown that many of this type of problem can be overcome with experience in using the tool. This introduces the issue of design detail or abstraction. The creation of semantically correct graphs tends to force the creation and manipulation of a large volume of details. For example, GAD does not allow a non-local subprogram to be called unless it has been exported to an appropriate visible level. This is despite the fact that it may be obvious to the designer/reviewer that a non-exported subprogram is (or should be) intuitively exported after a non-local call has been made to it. This exactly parallels what is required in the alteration of Ada programs at the source level (without the recompilation overhead). The GAD implements several features to assist the designer with detail manipulation, including a restriction on the level of detail permitted, and the ability to export stand-alone subprograms. The previous example illustrates another of the issues, which deals with the visibility of entities within a graph. SYSCON has chosen to implement visibility requirements in the strict Ada sense, in keeping with the general philosophy of semantic correctness. The strictest possible implementation of this would result in an extensive burden on the designer to establish visibility prior to utilization. This potential burden is ameliorated by the implementation of automatic visibility for each entity on all other entities at the same scoping level. This results in the automatic insertion of "with" statements for all top-level units which are referenced, and the declaration of all local entities such they would be visible to all other entities within the same inner scope. 5.4.3 GKS Utilization for Terminal Dependence Reduction The Graphical Kernel System ( GKS ) is a international ( ISO ) and national ( ANSI ) standard for an application level interface to computer graphics systems. GKS defines a set of language independent functions for a standard display-device independent interface to two-dimensional, color-capable graphics systems. The set of GKS functions, which support a wide range of capabilities, from output primitives to interactive graphics, is intended to be implementable in many programming languages. A language binding for a specific programming language defines the syntactical interface between GKS and graphics application programs written in that language. Language bindings to ANSI languages, including Ada, are included as part of the GKS standard. The motivation for use of GKS is to increase the portability of graphic application programs and graphics systems, and to facilitate application program development. Utilizing the GKS as the interface between a graphics application program and the graphics hardware minimizes device dependencies embedded in the program. A graphics application program which communicates with the graphics hardware through the GKS uses the standard GKS interfaces and, in general, does not require knowledge of graphic hardware features and characteristics. Transitioning the graphics program to different graphics hardware when the hardware is supported by a GKS implementation is simplified since device dependencies are limited to GKS. The use of GKS can have a positive effect on application code by reducing its terminal dependence, thereby promoting its portability and maintainability. SYSCON felt that the use of GKS on the GAD project had a positive effect, particularly as a means of providing an interface for isolating terminal dependencies from a more experienced perspective (particularly for hardware with which we were not familar). The usage of GKS had three primary drawbacks, which were: o The unavailability of an implementation of an Ada binding of GKS. The implementation of SYSCON's GKS substitute is discussed in the next section. o The level of feature support in GKS for advanced graphics features (which are becoming quite common) is low. This forces programs to use the extension mechanisms built into GKS which reduces portability. o The effects of certain graphics operations in GKS is not rigidly defined. For example, there are numerous ways of implementing highlighting. Interactive graphics tools, such as the GAD, require assumptions about the implementation of operations if they are to be used in place of extensions. The result is that tool retargeting will normally require at least some IO driver rewriting (as opposed to using off- the-shelf drivers). These drawbacks are not sufficient to warrant discontinuing the use of GKS. However, projects and/or programs contemplating the use of GKS should be aware that it is an aid to achieving improved portability, and not a panacea for all problems. 5.4.4 Implementation of a GKS Substitute No Ada language binding to GKS was available for the GAD project at the time of development, so SYSCON implemented a version of GKS for use with the GAD. The functions implemented comprise a subset of GKS, referenced by the name GKS_PRIME. Only the operations and functions required by the GAD were implemented, and operations and functions not used were not implemented. The type definitions and subprogram calls which are contained in GKS_PRIME are those defined in the Draft GKS Binding to ANSI Ada [AdaGKS]. The implementation of this package is close enough to the real GKS, that its utilization permits the Graphic Ada Designer to be easily converted to using a real version of GKS. Table 5.4-1 summarizes the differences between GKS_PRIME and GKS, and the following paragraphs elaborate on these differences. <FF> Table 5.4-1. GKS_PRIME Differences From GKS -------------------------------------------- o The precedence of calls that an implementation of GKS might require is ignored if not functionally required by GKS_PRIME. Specifically, workstation level calls (e.g., open and close) are not required or supported. o GKS_PRIME and its associated drivers implement color highlighting, which is needed by GAD but not required by the GKS standard. o All non-standard calls permitted by GKS (as ESCAPE and GDP [generalized drawing primitive] calls) are encapsulated in the package GKS_NON_STANDARD. o The values of unrequired input and output parameters are ignored. While the syntax of the implemented functions correspond to the draft language binding, in some cases the semantics do not; i.e., while the appropriate call parameters are input to and received from a GKS_PRIME subprogram, the parameter values may not be set properly if their use is not required by GKS_PRIME or by the GAD. The possibility also exists that functions which have been implemented in GKS_PRIME may operate differently when run on a true GKS implementation. As an example, a GKS implementation utilizing the Tektronix 4107 may use the hardware highlight capabilities, a segment blink, whereas GKS_PRIME utilizes a color highlight which provides a more conducive man-machine interface. All references to terminal graphic capabilities are performed through two packages, GKS_PRIME and GKS_NON_STANDARD. The GKS_NON_STANDARD package implements graphic functions which require access to terminal hardware capabilities which are not addressed by standard GKS (e.g., character background color). The rationale for having another graphics interface package is to distinctively separate the functions which are not addressed by the standard GKS. The ESCAPE and the GDP functions defined in the standard GKS provide a way of specifying non-standard activites in GKS, but the actual handling of these functions in Ada had not been defined at the time of our design of GKS_PRIME. The ESCAPE function allows an application program to control hardware capabilities not addressed by the standard GKS functions, while the GDP function allows an application program to specify non-standard output primitives. The GAD-required functions implemented in the GKS_NON_STANDARD package would be implemented via the ESCAPE and GDP functions defined in the standard. 5.5 Productivity The GAD was developed entirely in Ada utilizing a compilable Ada PDL to assist with the rapid prototyping of the tool (see Section 5.2). Tables 5.5-1 and 5.5-2 give the results of a Statement Analysis which was performed on the GAD software. Specifically, these tables show the constituent constructs of the software comprising the GAD. Table 5.5-3 gives the man hours by category used to the develop the software. In interpreting the data provided by these tables, care must be taken not to overlook the research aspects of the project. The rapid prototyping approach was utilized to provide a vehicle for gaining understanding of the issues and problems involved with the development of an interactive graphics design tool which performs semantic checking. <FF> Table 5.5-1. GAD Statement Analysis Breakdown -------------------------------------------------------------------------- | - COMPILATION UNIT | | | | | | | - | | | | | | | - | GAD |GRAPH_ |MMI |PDL |GRAPHICS_| | - | |TREE_ | |GENERATOR|DRIVER | | - | |ACCESS | | | | | - |PROGRAM |VIRTUAL |VIRTUAL |VIRTUAL |VIRTUAL | | - |UNIT |PACKAGE |PACKAGE |PACKAGE |PACKAGE | | - | | | | | | | STATEMENT TYPE - |SUBTOTAL|SUBTOTAL|SUBTOTAL|SUBTOTALS|SUBTOTALS| --------------------------|--------|--------|--------|---------|---------| |LEXICAL ELEMENTS | | | Comments | 39 1064 1668 336 854| | Pragmas | 0 0 0 0 0| |DECLARATIONS AND TYPES | | | Object Declarations | 2 199 337 41 160| | Number Declarations | 0 0 0 0 0| | Type Declarations | 0 22 6 2 25| | Subtype Declarations | 0 18 30 0 11| | Integer Types | 0 0 0 0 0| | Real Types | 0 0 0 0 0| | Floating Point | 0 0 0 0 0| | Fixed Point | 0 0 0 0 0| | Array Types | 0 8 0 0 6| | Record Types | 0 7 2 0 6| | Access Types | 0 0 0 0 0| |NAMES AND EXPRESSIONS | | | Attributes | 0 56 43 14 16| | Allocators | 0 0 0 0 0| |STATEMENTS | | | Assignment Statements | 6 310 468 90 225| | If Statements | 1 172 200 86 83| | Case Statements | 0 20 29 3 5| | Loop Statements | 0 59 56 26 10| | Block Statements | 1 11 36 4 2| | Exit Statements | 0 44 26 3 2| | Return Statements | 0 77 23 10 8| | Goto Statements | 0 0 0 0 0| | Label Statements | 0 0 0 0 0| |SUBPROGRAMS | | | Subprogram Declarations | 0 54 29 1 34| | Subprogram Bodies | 0 60 49 18 37| | Subprogram Calls | 12 181 749 214 141| -------------------------------------------------------------------------- <FF> Table 5.5-1. GAD Statement Analysis Breakdown continued -------------------------------------------------------------------------- | - COMPILATION UNIT | | | | | | | - | | | | | | | - | GAD |GRAPH_ |MMI |PDL |GRAPHICS_| | - | |TREE_ | |GENERATOR|DRIVER | | - | |ACCESS | | | | | - |PROGRAM |VIRTUAL |VIRTUAL |VIRTUAL |VIRTUAL | | - |UNIT |PACKAGE |PACKAGE |PACKAGE |PACKAGE | | - | | | | | | | STATEMENT TYPE - |SUBTOTAL|SUBTOTAL|SUBTOTAL|SUBTOTALS|SUBTOTALS| --------------------------|--------|--------|--------|---------|---------| |PACKAGES | | | Package Specifications | 0 4 6 2 2| | Package Bodies | 0 4 5 1 1| | Private Types | 0 1 0 0 0| | Limited Types | 0 0 0 0 0| |VISABILITY RULES | | | Use Clauses | 6 15 47 6 9| | Renaming Declarations | 0 5 2 0 6| |TASKS (Not Used) | | |PROGRAM STRUCTURE | | | With Clauses | 7 21 65 7 9| | Subunits (is separate) | 0 0 0 0 0| |EXCEPTIONS | | | Exception Declarations | 0 13 19 0 6| | Exception Handlers | 3 24 117 4 1| | Raise Statements | 2 43 124 1 5| |GENERIC UNITS | | | Generic Declarations | 0 0 0 0 0| | Generic Instantiations | 0 1 0 0 0| |REPRESENTATION CLAUSES | | | Length Clauses | 0 0 0 0 0| | Enumeration Rep Clauses | 0 0 0 0 0| | Record Rep Clauses | 0 0 0 0 0| | Address Clauses | 0 0 0 0 0| |GENERAL INFORMATION | | | Total Lines | 98 4073 6771 1221 2741| | Total Statements | 38 1490 2364 521 848| -------------------------------------------------------------------------- <FF> Table 5.5-2. GAD Statement Analysis Breakdown -------------------------------------------------------------------------- | - COMPILATION UNIT | | | | | | | - | | | | | | | - |GKS_ |VIRTUAL_ |TERMINAL_|OTHER |GAD | | - |PRIME |TERMINAL_| ACCESS | | | | - | |INTERFACE| | | | | - |VIRTUAL |VIRTUAL |VIRTUAL |COMP |SYSTEM| | - |PACKAGE |PACKAGE |PACKAGE |UNITS | | | - | | | | | | | STATEMENT TYPE - |SUBTOTALS|SUBTOTALS|SUBTOTALS|SUBTOTALS|TOTALS| --------------------------|---------|---------|---------|---------|------| |LEXICAL ELEMENTS | | | | Comments | 797 250 918 26| 5952| | Pragmas | 0 0 0 0| 0| |DECLARATIONS AND TYPES | | | | Object Declarations | 56 17 266 2| 1080| | Number Declarations | 0 0 0 0| 0| | Type Declarations | 7 4 38 0| 104| | Subtype Declarations | 2 4 35 0| 100| | Integer Types | 0 0 0 0| 0| | Real Types | 0 0 0 0| 0| | Floating Point | 0 0 0 0| 0| | Fixed Point | 0 0 0 0| 0| | Array Types | 1 0 0 0| 15| | Record Types | 6 0 6 0| 27| | Access Types | 0 0 0 0| 0| |NAMES AND EXPRESSIONS | | | | Attributes | 39 12 71 0| 251| | Allocators | 0 0 0 0| 0| |STATEMENTS | | | | Assignment Statements | 53 41 324 1| 1518| | If Statements | 44 30 83 2| 701| | Case Statements | 5 5 5 0| 72| | Loop Statements | 1 2 12 0| 166| | Block Statements | 0 0 2 0| 56| | Exit Statements | 0 0 0 0| 75| | Return Statements | 0 2 12 0| 132| | Goto Statements | 0 0 0 0| 0| | Label Statements | 0 0 0 0| 0| |SUBPROGRAMS | | | | Subprogram Declarations | 40 14 104 2| 278| | Subprogram Bodies | 40 18 116 2| 340| | Subprogram Calls | 88 67 360 4| 1816| -------------------------------------------------------------------------- <FF> Table 5.5-2. GAD Statement Analysis Breakdown continued -------------------------------------------------------------------------- | - COMPILATION UNIT | | | | | | | - | | | | | | | - |GKS_ |VIRTUAL_ |TERMINAL_|OTHER |GAD | | - |PRIME |TERMINAL_| ACCESS | | | | - | |INTERFACE| | | | | - |VIRTUAL |VIRTUAL |VIRTUAL |COMP |SYSTEM| | - |PACKAGE |PACKAGE |PACKAGE |UNITS | | | - | | | | | | | STATEMENT TYPE - |SUBTOTALS|SUBTOTALS|SUBTOTALS|SUBTOTALS|TOTALS| --------------------------|---------|---------|---------|---------|------| |PACKAGES | | | | Package Specifications | 8 1 2 1| 26| | Package Bodies | 7 1 2 1| 22| | Private Types | 0 0 0 0| 1| | Limited Types | 0 0 0 0| 0| |VISABILITY RULES | | | | Use Clauses | 7 4 6 1| 101| | Renaming Declarations | 2 0 1 0| 16| |TASKS (Not Used) | | | |PROGRAM STRUCTURE | | | | With Clauses | 7 3 7 1| 127| | Subunits (is separate) | 0 0 0 0| 0| |EXCEPTIONS | | | | Exception Declarations | 0 0 2 0| 40| | Exception Handlers | 5 1 32 1| 188| | Raise Statements | 5 0 32 0| 212| |GENERIC UNITS | | | | Generic Declarations | 1 0 0 0| 1| | Generic Instantiations | 0 2 1 0| 4| |REPRESENTATION CLAUSES | | | | Length Clauses | 0 0 0 0| 0| | Enumeration Rep Clauses | 0 0 0 0| 0| | Record Rep Clauses | 0 0 0 0| 0| | Address Clauses | 0 0 0 0| 0| |GENERAL INFORMATION | | | | Total Lines | 1761 725 4240 68| 21698| | Total Statements | 459 249 1574 17| 7560| -------------------------------------------------------------------------- <FF> Table 5.5-3. Project Man Power Utilization WORK BREAKDOWN STRUCTURE HOURS EXPENDED ELEMENTS TOTAL Task 1 - Define User Interface SPA HOURS 16 SSA HOURS 239 Task 2 - Design SPA HOURS 254 SSA HOURS 1,022 Task 3 - Code and Debug SPA HOURS 373 SSA HOURS 276 SA HOURS 526 Task 4 - Integrate and Test SPA HOURS 385 SSA HOURS 320 SA HOURS 257 Task 5 - Deliverable Preparation SPA HOURS 388 SSA HOURS 350 SA HOURS 250 Task 6 - Management PE HOURS 337 SPA HOURS 84 Summary by Labor Category PE 337 SPA 1,500 SSA 2,207 SA 1,033 Total Hours 5,077 5.6 Methodology Adaptation The GAD is a high-level design tool intended to support the design and development of the structures of an Ada program. The tool, as currently implemented, forces top-down structural decomposition utilizing a series of step-wise refinements. Other implementation strategies exist, and the GAD can be adapted to utilize some of the various ideas they embody including: Graphic Notations Conventions Top-Down Design Approach Virtual Package Concept Modularity Enforcement of Semantic Correctness The GAD is not suited to some design techniques. For example, the detailed representations contained in low-level flowcharts are not within the scope of the GAD. This section includes a brief discussion on the GAD's inherent design techniques and methodologies. Some of these items can be adapted to fit alternate implementation strategies. Note that the implementer should consult Section 4.2 for information on altering user adaptable compile-time parameters. Two popular design decomposition techniques, Bottom-Up and Data Flow, are addressed at the end of this section as possible candidates to which an implementer might adapt GAD. Ada Graphic Notations Conventions define the symbology of the GAD. These items can be altered if the implementer wants a different symbology. The shapes of the graphical representations of the Ada entities can be changed, but this is not recommended. Structured Top-Down Decomposition is implemented by the GAD. Placement of entities to be created are at the outermost scope or within a previously created entity. Annotations for entities are added after entity creation. Calls and connections are made after the connected entities have been created. For adaptation of the GAD from Top-Down to Bottom-Up designing, read the discussion on adapting to the Bottom-Up Approach (see below). The Virtual Package Concept is a design abstraction that allows the grouping of related Ada entities without requiring the creation/existence of a corresponding code structures in the implementation (e.g., subsystem grouping.) The virtual package embodies all the concepts of a package, except for allowing a generic declaration. The implementer could eliminate the virtual package from the GAD if, for example, it is not consistent with the implementer's methodology. The easiest way to accomplish this would be to eliminate the icons that represent references to virtual packages and imported virtual packages. Modularity is included as a by-product of working with an Ada-based tool. The GAD does have one feature which enforces a modular design. The nesting level for enclosing Ada entities is limited by GAD. By raising the allowable value, the implementer essentially eliminates the possibility of encountering a nesting limit. The value associated with the nesting level is an adaptable, compile-time parameter. The Enforcement of Semantic Correctness is an excellent feature of the GAD tool. Automatic detection of design errors during creation of an OODD prevents the loss of design time due to structure error. Errors discovered during creation include violations of scoping rules when placing entities and violations of visibility rules when calling subprograms and entry points. The implementer can remove the Enforcement of Semantic Correctness from the GAD with extensive editing of the MMI Software. Elimination of the error detections is not recommended. The Bottom-Up Approach to design builds higher-level abstractions from lower-level declarations and processing units. During the initial design of GAD, it was impossible to create an entity that enclosed a previously created entity. The new out-of-scope features added to the GAD program have made scope altering operations possible, thereby adapting GAD to use with Bottom-Up Approachs. This is particularly true for out-of-scope creation, which permits the encapsulation of existing entities as required by Bottom-Up Approachs. Data Flow Diagrams are used to show data flow between graphically represented modules (called bubbles or clouds). The diagrams are different from static structure diagrams that contain items such as nested program units or subprogram call connections. Since the GAD graphical entities can be applied to Ada data flow diagram representations, the basic creation and manipulation operations needed for diagram production are provided with GAD. Note that the use of the virtual package as a uncommitted bubble in the diagram would be appropriate. But, the adaptation of the GAD to support the creation of complete data flow diagrams would demand extensive additions and revisions. One addition would be the definition and representation of a data flow connector symbol. A label describing the action on the data should be associated with each occurrence of an individual connection. Also more detail must be added to the declaration of graphical representations. Current labeling should expand to include information on the manipulation of data within the scope of entities. Ada types, objects, and exceptions need explicit definitions, rather than relying on good name selections, to insure proper understanding when using these variables. Parameter declaration would need elaboration to include information on in/out status. In addition, the MMI software operations that are pertinent to structured graph production could be removed to enhance the operations. <FF> 6. TESTING 6.1 Approach The purpose of the testing of the Graphic Ada Designer is to establish if GAD meets its Functional Requirements, as described by the User's Manual (and approved at the Man-Machine Interface (MMI) Review). In assessing compliance with the Functional Requirements the testor needs to establish that GAD 1) provides all of the documented functions (e.g., the ability to create a graphic entity representing a package), and 2) that all of the functions are consistently and correctly implemented (e.g., the aforementioned operation produces the correct symbol, has the proper properties, and is represented correctly during PDL generation). Section 6.2, Test Requirements, details the Functional Requirements of GAD. Because both GAD and the test requirements are functionally oriented, testing is conducted by performing each of the functions described in the Section 6.2. This approach was/will be utilized to perform the Functional Testing of the GAD and to define the acceptance criteria at the Product Delivery Review. 6.2 Test Requirements This section documents the functional test requirements needed to test the software modules comprising the GAD. 6.2.1 Graphics Design Create entities and connections Functional test requirements: A) The specified entity name should not exceed the width of the created entity. B) Contained entities must be entirely inside the containing entity. C) Maximum level of nesting is six. D) The selected entity is created. E) The current graphic attributes ( color, line type, etc.) are used to draw an entity. F) The graphic attributes can be modified. G) Invalid Ada identifiers (e.g., trailing underscore) and excessively long identifiers cannot be used. Create Virtual Package Functional test requirements: A) Virtual package cannot be a generic. B) Virtual packages can be created as stand alone or nested entities. C) A prologue consisting of up to three lines of ASCII text is requested and stored. Create Package Functional test requirements: A) The generic status is requested and displayed. B) If this is a generic instantiation then a valid Ada identifier is requested and displayed as the name of instantiated unit. C) Packages can be created as stand alone or nested entities. D) A prologue consisting of up to three lines of ASCII text is requested and stored. E) No contained entities may be created inside of an instantiated package. Create Procedure Functional test requirements: A) The generic status is requested and displayed. B) If this is a generic instantiation then a valid Ada identifier is requested and displayed as the name of instantiated unit. C) If specified, the presence of parameters is displayed. D) Required parameters are indicated on generic declaration. E) Procedures can be created as stand alone or nested entities. F) A prologue consisting of up to three lines of ASCII text is requested and stored. G) No contained entities may be placed inside an instantiated procedure. Create Function Functional test requirements: A) The generic status is requested and displayed. B) If this is a generic instantiation then a valid Ada identifier is requested and displayed as the name of instantiated unit. C) If specified, the presence of parameters is displayed. D) Name of function is preceded by = on display. E) Required parameters are indicated on generic declaration. F) Functions can be created as stand alone or nested entities. G) No contained entities are allowed in an instantiation. H) A function name may overload Ada predefined operators such as "*" and "+". I) A prologue consisting of up to three lines of ASCII text is requested and stored. Create Task Functional test requirements: A) Tasks may only be nested entities, no stand-alone tasks may be created. B) Task types are not supported. C) A prologue consisting of up to three lines of ASCII text is requested and stored. Create Body Functional test requirements: A) Bodies may be created only as nested entities within - packages - virtual packages - procedures - functions - tasks. B) No contained entities may be created within executable bodies. C) Call connections can originate within executable bodies. Create Annotating Entities Functional test requirements: A) The annotating entities which may be created are: - Task Entry Point - Exported Type - Exported Object - Exported Exception - Exported Procedure - Exported Function - Exported Task Entry - Imported Virtual Package - Imported Package - Imported Procedure - Imported Function B) The Task Entry Point annotation is valid only on task entities. - If specified, guard conditions are displayed. - If specified, the presence of parameters is displayed. C) Exported and Imported annotating entities are valid only on package and virtual package entities. D) Exported entities are always shown on the left side of an entity. E) Imported entities are always shown on the right side of an entity. F) Where "name" denotes a valid Ada identifier, annotating entities have following formats: - ( name ) for type declaration - : name : for object declaration - < name > for exception declaration - | name | for subprogram - / name / for task entry - /* name / for guarderd task entry - # name # for packages - % name % for virtual packages <FF> Create Connections Functional test requirements: A) The allowed connections are: - Unconditional Call - Timed Call - Conditional Call - Visibility connection - Exports connection B) Generated control flow indicators are: ------- subprogram or unguarded entry call T------ timed call on entry C------ conditional call on entry or subprogram V...... Visibility connection C) Call connections originate from body of procedure, function task, package, or virtual package. D) Data dependencies for packages and virtual packages can originate anywhere within the entity symbol. E) Exports connections originate at right-hand side of export symbol. F) Calls terminate at - appropriate export symbol left-hand side - within subprogram boundaries F) Call connections must have correct visibility. The Unit containing the body originating the call must have the proper visibility on the subprogram at which the call terminates. G) The creation of call connections showing recursion are allowed. H) Export connections can only terminate at entities of the same type. I) An exported item may only be connected to one contained item inside the exporting entity. J) A warning message will be issued any time an export connections is created between two entities which do not have identical names (identifiers). K) Near vertical or horizontal connecting lines are automatically made vertical or horizontal. Delete entities and connections Functional test requirements: A) When an entity is deleted all severed connections must be deleted. B) Entities which may be deleted are - Virtual Package - Package - Procedure - Function - Task - Body - Task Entry Point - Exported Type - Exported Object - Exported Exception - Exported Procedure - Exported Function - Exported Task Entry - Imported Virtual Package - Imported Package - Imported Procedure - Imported Function - call connections - visibility connections - exports connections C) Operator has opportunity to confirm or cancel the operation. D) Deleted entities may be stand alone or nested. E) All contained entities are deleted and associated connections severed. Modify entities Functional test requirements: A) The names (Ada identifiers) of the following entities may be modified: - Virtual Package - Package - Procedure - Function - Task - Task Entry Point - Exported Type - Exported Object - Exported Exception - Exported Procedure - Exported Function - Exported Task Entry - Imported Virtual Package - Imported Package - Imported Procedure - Imported Function B) The parameter status of subprograms and entry points may be altered. C) The guard status of entry points may be altered. D) The Prologues of entities which can have them may be edited. E) The call status of call connections may be altered. Move and Resize entities Functional test requirements: A) The following entities may be specified for moving and/or resizing: - Virtual Package - Package - Procedure - Function - Task - Body B) The following entities may be specified for moving: - Task Entry Point - Exported Type - Exported Object - Exported Exception - Exported Procedure - Exported Function - Exported Task Entry - Imported Virtual Package - Imported Package - Imported Procedure - Imported Function C) When an entity is moved an identitical translation is performed on all contained entities and annotations. D) For all connections spanning the boundary of the outer most moved entity (and hence are severed), verify that the program: - remarks the endpoints of line segments composing the connection line - attempts to redraw the line and request operator confirmation of altered connection - upon cancelation, forces the operator to redraw the the connection E) Verify that the entities listed in (A) may be moved anywhere on the graph that is not already occupied. F) Verify that entities may not be moved too close to the graph boundaries such that a label/annotation will not fit on the graph. G) Verify that move and resize operations do not corrupt or alter the syntax tree (the semantic meaning of the graph). H) If the move is not allowed by GAD because of entity overlap or improper scoping, verify the display of an appropriate error (and information) message. 6.2.2 PDL Production Functional test requirements: A) PDL reflects generic status of packages, procedures and functions. B) PDL reflects required formal parameters for procedures, functions, and task entries. C) PDL reflects required task entry guard conditions. D) Exported entities are shown in specification of packages and virtual packages. E) The presence of imported entites generates 'with' clauses. F) Visibility connections between contained entity and imported entity result in 'use' clause in declarative section of contained entity. G) The PDL generated will be placed in a file with the current session file name and the PDL file extension. H) The PDL will be syntactically correct. The program generated PDL will be semantically correct if the support package is placed in the PDL file. The user input portion of the PDL may not be semantically correct (e.g., duplicate identifiers, or non-existent units in visibility clauses). I) The following should be verified for each entity: - the type of entity - enclosing scope of entity - what the entity encloses - the relationship with other entities in terms of exported and imported objects - entity specified information such as generic status J) The usage of TBD items will be such that removal of the SUPPORT_PACKAGE will result in compilation errors at the location of each usage. 6.2.3 File Management Functional test requirements: A) The program will automatically prompt the user for the name of a file to read in when the program initializes. If the file does not exist, a null design will be presented to the user. The filename specified will become the session file name, if a null name is entered then the default name is used. A) The graphics and syntax information representing the current design can be written to an operator specified file. B) A previously saved design can be restored from an operator specified file. The file read in will become the new session file. C) The operator may EXIT the program and save the current design automatically in a new version of the current session file. D) The operator may QUIT the program and not save the current design. 6.2.4 MMI Functions The following MMI functions are those which might not be exercised by tests designed to verify the functions in sections 6.2.1, 6.2.2, 6.2.3; i.e., MMI functions which will be exercised are not listed. Functional test requirements: A) Backup commands work in the menus where backup is available. B) Help is available for each menu and for each command in each menu. C) Main menu command works where the command is available. D) Pan and zoom are available to the operator. E) Device is restored to VT100 mode following termination. F) Scroll region is on bottom two lines of terminal (generally). G) Read in file or new file creation is performed on demand with confirmation of old file deletion. H) Write out file is performed on demand. I) Abort is available and operable whenever cursor is in graph viewport, and returns user to previous top level menu. J) The program correctly recovers from improper user input, for example, keyboard input when mouse input is expected. 6.2.5 Capacity Functional test requirements: A) The program gracefully recovers from exhausting the terminal display list. B) The program gracefully recovers from exhausting the available supply of TREE, GRAPH, LIST, and PROLOGUE nodes.