Bob Connell [rconnell]
Bob Costello [rcostell]
May 21, 1996
BDESYM is the project that incorporates the text facilities of SYMTXT into BDE. The 96 Spring BDESYM project integrates the extensions initially made by the 94 Spring and 94 Fall BDESYM teams into the current BDE software baseline. The 96 Spring BDESYM project introduces changes that optimize the polymorphic pr_get_str and pr_set_str macros proposed by the 94 Fall BDESYM team. Additionally, the 96 Spring project implements changes to support the reduction of the memory and external storage required to for TK table rows by encoding repeating string information in the SY foreign key row number component.
The BDE [Block Diagram Editor] program is an interactive tool for drawing and editing diagrams and structure charts. The persistent network database used by BDE to represent drawing elements, links and text is supported by the CHGEN code generation tool [Wang].
SYMTXT is a document management and compression utility that was built to provide cross-reference facilities for ASCII documents [Molloy]. SYMTXT processes ASCII input documents into a symbol/token table representation. Word tokens are stored in a dictionary structure [SY table]. The ASCII text is represented as a series of TK table row entries that reference word tokens stored in a dictionary table [SY table] via foreign keys.
The 94 Spring BDESYM team incorporated the SYMTXT project into BDE [Tong]. Symbol reference [YR Table] and text block [XB Table] tables were added to the BDE schema to support linkage to the SYMTXT symbol/token table representation for BDE
text fields. Macros were added [pr_get_sym, pr_set_sym, pr_get_tokset and pr_set_tokset] to replace pr_get_str and pr_set_str to support retrieval and update of symbol reference and text block data.
The 94 Fall BDESYM team proposed the use of pr_get_str and pr_set_str macros that utilized CHGEN's table attribute data [TA table] at execution time to hide the requirement for specialized SYMTXT symbol and token access functions from the BDE applications programmer [Mkayed]. The pr_get_str and pr_set_str macros proposed by the 94 Fall BDESYM team determined whether the use of specialized access functions were required [pr_get_sym, pr_set_sym, pr_get_tokset and pr_set_tokset functions] to support string fields by inspecting field attributes in the table attribute table [TA table] at execution time.
The efforts of the 94 Spring and 94 Fall BDESYM teams were never integrated into the BDE software baseline. Improvements and maintenance changes made to the BDE software baseline over the past year have not been incorporated into the BDESYM code base. As a result, attempts to re-make the 94 Spring and 94 Fall BDESYM versions have failed due to X11 library changes and other environmental changes introduced over the past several years[e-mail from Dr. Lechner 3/9/96].
The 96 Spring BDESYM team planned to integrate the
software and schema changes made by the 94 Spring and 94 Fall
BDESYM efforts into the current BDE software baseline. Additionally,
the following improvements to BDESYM were planned.
The 96 Spring BDESYM project plans to segment the effort into three build and test cycles. The first build and test phase will integrate the work of the 94 Spring BDESYM team into the current BDE software baseline. The second build and test phase will incorporate the work of the 94 Fall BDESYM team. The final build and test cycle will incorporate the 96 Spring team improvements. The scope of each build and test cycle is detailed below.
The 94 Spring BDESYM team changes that will be integrated
into the current BDE base are outlined below.
The 94sbde_schema.sch file referenced by Dr. Lechner's e-mail will be used as a base for the planned schema changes.
Module SLOC Impact
The 94 Fall BDESYM Team revised the CHGEN program
to support the use of additional "is_key" values to
identify text data that has been stored as symbol reference [YR
Table] or text block [XB Table] foreign key references.
This version of CHGEN was labeled CHGEN 9.5 by the
94 Fall BDESYM group. The changes made by the team to support
additional "is_key" values were not integrated into
the CHGEN 10 software baseline. The 96 Spring BDESYM project will
integrate the CHGEN 9.5 changes into the current CHGEN 10 software
baseline.
The pr_get_str and pr_set_str macros generated by
CHGEN would be replaced by the polymorphic macros proposed by
the 94 Fall team. The specialized access macros would utilize
the TT and TA tables at execution time to determine the "is_key"
value for the fields requested. Depending on the "is_key"
value found in the TA table row for the requested field, the macro
would resolve the request via invocation of a symbol or token
access routine [pr_get_sym, pr_set_sym, pr_get_tokset and pr_set_tokset]
or directly via a C language [pointer->field] reference.
The polymorphic pr_*_str macros proposed by the 94
Fall BDESYM team searched the TT and TA Tables for each request.
The clustering of pr_*_str requests for the same table and field
during BDE operation is not unexpected. The loading and dumping
of the virtual memory network database from and to external storage
[~.dat file] are examples of where pr_*_str request clustering
can be expected. The 96 Spring BDESYM team will revise the pr_*_str
macros proposed by the 94 Fall team to inspect the current row
position in the TT and TA tables prior to initiating a table search.
Alterations to remove the direct pr_get_sym, pr_set_sym,
pr_get_tokset, and pr_set_tokset calls introduced by the 94 Spring
BDESYM revisions will also be required. This revision is estimated
to require changes to 32 SLOC across all BDESYM modules.
SV Table New Table
TT Table New Table [Table definitions for the entire schema]
TA Table New Table [Attribute field definitions for
tables]
No changes were required for the 1994 Fall Integration
Module SLOC Impact
Module SLOC Impact
The 96 Spring team BDE modifications introduce optimizations
to BDESYM text handling functions to reduce memory and storage
requirements. The planned changes focus on reducing the storage
requirements for TK row entries by replacing the tktyp field in
the TK table with a one character prefix space count and encoding
information that was stored in the tktyp field into the TK table's
SY foreign key field. The technical design for the encoding mechanism
for SY foreign keys is detailed in the appendix to this document
[SY Foreign Key Encoding Approaches document].
In the current BDESYM architecture, the SY foreign
key in the TK table is used for three purposes:
The 96 Spring BDESYM project will implement code
improvements in the following areas.
In addition to the schema change, elimination of the tktyp field will impact 27 SLOC in the SYMTXT project code. The impact to the pr_load and pr_dump routines will be corrected by regeneration of the schema. The remaining impact will be in the sy_tk_mgr routine [text decomposition] and sy_pj_mgr [text regeneration] routines.
The changes required to alter the encoding approach
for repeated character strings and short symbols is fairly well
isolated to the SYMTXT routines that support the encoding and
decoding of character strings. It does not appear that changes
to the lex grammar used by SYMTXT will be required to implement
these changes.
The approach for supporting the encoding of repeated
character string information in the TK table SY foreign key field
is detailed in the SY Foreign Key Encoding Approaches document.
To support this encoding approach, the row number components of
hcg_key type fields will utilize hexadecimal character external
representation. The impact of this change will be isolated to
the pr_load row_encode and row_decode key component manipulation
routines.
Additionally changes will be required to SYMTXT and
BDESYM code that is sensitive to the "SY000000" SY foreign
key value in the TK row will require alteration. This key value
had been used to indicate that the TK row represented either a
inline token or repeated string, rather than a true SY Table foreign
key. This will impact 8 SLOC in both the BDESYM and SYMTXT projects.
At present, the BDESYM design requires that a TK
table row be created to represent the single space character between
text words.
To support the prefix space count, a new field will
be added to the TK Table schema. The prefix space count field
will contain a count of the number of space characters that are
to precede the symbol on output. This design approach will support
a maximum of 255 space characters between symbols in text.
This change will be isolated to the SYMTXT routines
responsible for string encoding and decoding. It does not appear
that changes to the lex grammar used by SYMTXT will be required
to implement this change.
/* ====================================================================
pr_get_str macro.
Preconditions.
o A properly initialized database environment must exist. The pr_get_str macro uses the TT and TA metadata tables to determine the characteristics of the requested field at execution time
o A pointer to hcg_key type [created by pr_create()] for the table containing the requested field should be supplied as the first parameter to the macro. The specified table must exist in the database schema.
o The table field name must be supplied as the second macro parameter. The specified field must exist in specified table.
o The specified field must be defined in the database schema as a character or text field.
o The table's schema "is_key" fields for text fields stored as XB or YR references must be coded with the values 'x' or 'y' as described in the 94 Fall BDESYM Project Report.
o The parameters supplied to the macro must be the names of null delimited character strings.
o When pr_get_str is used as the source of a C language
assignment statement, the target field should be defined as
a C character string. The defined length of the target field should
be .ge. the length of the source field in the database schema.
Postconditions.
o The requested value of the requested character field is returned.
o In the event that an invalid or non-existent table identifier is supplied as the first macro parameter, the program will halt on an assertion.
o In the event that an invalid or non-existent field
name is supplied as the second macro parameter, the program will halt
on an assertion.
Alters.
o The value of TTcurr and TAcurr may be altered.
Programmer Notes.
o The required CHGEN generated header file and the C library header files string.h and assert.h must be included in the compilation unit.
o The signal processing routine generated by CHGEN
will catch an abort signal generated by an assertion. A bdeabort.dat
file will be created by the signal processing routine prior
to exit.
Implementation Notes
o To implement the pr_get_str macro requirements, the function chk_if_string was developed to perform the run time analysis of the TT and TA table structures toward determining whether the requested field has been stored as a token or symbol reference. The chk_if_string routine returns TRUE if the field is stored as a string and FALSE if the string is encoded as a token or symbol reference. The result from this function call is used by an arithmetic if that determines whether the string access request will be resolved by returning pkval->fld or calling pr_get_tokset or pr_get_sym.
=====================================================================
*/
#define pr_get_str(pkval,fld) !(chk_if_string(pkval,#fld)) ? \
( (TAcurr->is_key[0] == 'x') ?\
pr_get_tokset(pkval,#fld) : pr_get_sym(pkval,#fld) ) \
: pkval->fld
3.1.3 pr_get_str macro: chk_if_string
Function Component
int chk_if_string(void* pkval, char* fld) {
/* ***********************************************BDESYM
Function: chk_if_string
Author: rcostell 96S523 BDESYM
Created: 5/96
Revisions:
Description: This routine is invoked from the 96S523 BDESYM
pr_get_str and pr_set_str macros. The routine searches the
TT and TA metadata tables to determine from the is_key
value whether the requested field has been stored as a
token or symbol reference.
The preconditions, postconditions and alters for the
routine are documented with the pr_get_str and pr_set_str
macro routines used for 96S523 BDESYM.
Programmer Notes.
If this routine fails on an assertion, insure that the
schema being utilized has the TT and TA tables defined
and that the ~.msdat file has been read in by the
application [via pr_load] to initialize the in memory
TT and TA data structures.
*************************************************BDESYM
*/
char decoded_tbl_abbr[ARR_SIZE+1];
get_abbr(pkval,decoded_tbl_abbr);
assert(decoded_tbl_abbr[0] != '\0');
if ((TTcurr == NULL) ||
(strcmp(TTcurr->TTabbr,decoded_tbl_abbr) != 0))
table_loop("NewYear",TT)
{
if (strcmp(TTcurr->TTabbr,decoded_tbl_abbr) == 0)
break;
}
assert(strcmp(TTcurr->TTabbr,decoded_tbl_abbr)
== 0);
if ((TAcurr == NULL) ||
(strcmp(TAcurr->TAname,fld) != 0))
child_loop(TT,TA,TAid,TTid)
{
/* strncmp is needed here since TAname is padded */
/* with spaces to its schema length */
if (strncmp(TAcurr->TAname,fld,strlen(fld)) == 0)
break ;
}
assert(strncmp(TAcurr->TAname,fld,strlen(fld))
== 0);
if ((TAcurr->is_key[0] == 'x') || (TAcurr->is_key[0] == 'y'))
return(FALSE) ;
else
return(TRUE) ;
}
/*=====================================================================
pr_set_str macro.
Preconditions.
o A properly initialized database environment must exist. The
pr_set_str macro uses the TT and TA metadata tables to determine
the characteristics of the requested field at execution time.
o A pointer to hcg_key type [created by pr_create()] for the table
containing the requested field should be supplied as the first
parameter to the macro. The specified table must exist in the
database schema.
o The table field name must be supplied as the second macro parameter.
The specified field must exist in specified table.
o The specified field must be defined in the database schema as a
character or text field.
o The table's schema "is_key" fields for text fields stored as
XB or YR references must be coded with the values 'x' or 'y'
as described in the 94 Fall BDESYM Project Report.
o The parameters supplied to the macro must be the names of null
delimited character strings.
o When pr_set_str is used as the source of a C language assignment
statement, the target field should be defined as a C character
string. The defined length of the target field should be .ge.
the length of the source field in the database schema.
Postconditions.
o The field in the requested table is set to the supplied value.
o In the event that an invalid or non-existent table identifier is
supplied as the first macro parameter, the program will halt on
an assertion.
o In the event that an invalid or non-existent field name is supplied
as the second macro parameter, the program will halt on an
assertion.
o If the size of the value field exceeds the size specified in the
database schema, a warning message is issued to STDERR and the
field is truncated.
Alters.
o The value of TTcurr and TAcurr may be altered.
Programmer Notes.
o The required CHGEN generated header file and the C library header
files string.h and assert.h must be included in the compilation
unit.
o The signal processing routine generated by CHGEN will catch an
abort signal generated by an assertion. A bdeabort.dat file will
be created by the signal processing routine prior to exit.
====================================================================
*/
< H2>3.2.2 pr_set_str macro: Macro Component
#define pr_set_str(pkval,fld,value)\
if(chk_if_string(pkval,#fld)) \
{ \
if ( strlen(value) >= sizeof((pkval)->fld)) \
fprintf(stderr,"Warning: field %s is too long-truncated\n",\
#fld); \
strncpy((pkval)->fld, (value), sizeof((pkval)->fld)-1);\
} \
else if (TAcurr->is_key[0] == 'x') \
pr_set_tokset(pkval,#fld,value); \
else pr_set_sym(pkval,#fld,value);
The chk_if_string function is utilized by both the
pr_get_str and pr_set_str macro implementations.
Four additional CHGEN generated string manipulation
macros were identified with that require alteration to support
string fields stored as symbol or token references. The macros
[find_str_loop_all, find_str_loop, var_find_str_loop_all and var_find_str_loop]
were identified during the analysis phase of the project and the
solutions described below were proposed in the project's Critical
Design Review (CDR) document. Time constraints prevented the team
from testing and implementing the changes to these macros.
/*
find_str_loop_all -- revised to use polymorphic pr_get_str
*/
#define find_str_loop_all(tbl,field,value) \
for (tbl##curr = tbl; tbl##curr != NULL; \
tbl##curr=tbl##curr->next_ptr) \
if (strcmp(pr_get_str(tbl##curr,field),value) == 0)
/*
find_str_loop -- revised to use polymorphic pr_get_str
*/
#define find_str_loop(viewname,tbl,field,value) \
if (find_view_idx(viewname)) \
for (tbl##curr = tbl; tbl##curr != NULL; \
tbl##curr=tbl##curr->next_ptr) \
if ((meets_view(tbl##_idx,hcg_view_idx,tbl##curr->tbl##id)) && \
(strcmp(pr_get_str(tbl##curr,field),value) == 0))
/*
var_find_str_loop_all -- revised to use polymorphic pr_set_str
*/
#define var_find_str_loop_all(tbl,tblvar,field,value) \
for (tblvar = tbl; tblvar != NULL; tblvar=tblvar->next_ptr) \
if (strcmp(pr_get_str(tblvar,field),value) == 0)
/*
var_find_str_loop -- revised to use polymorphic pr_get_str
*/
#define var_find_str_loop(viewname,tbl,tblvar,field,value) \
if (find_view_idx(viewname)) \
for (tblvar = tbl; tblvar != NULL; tblvar=tblvar->next_ptr) \
if ((meets_view(tbl##_idx,hcg_view_idx,tblvar->tbl##id)) && \
(strcmp(pr_get_str(tblvar,field),value) == 0))
The key encoding approach outlined in the 96 Spring
BDESYM PDR requires that key values be externally represented
as hexadecimal character strings. To support this requirement,
two pr_load routines [row_decode and row_encode] were revised
to support hexadecimal encoding of key values. The changes to
the impacted routines are detailed below.
/*******************************************************************
int row_decode(const hcg_key* input_key,
char* decoded_row)
Description:
Decode the row portion of the passed hcd_key type field and return
decoded row as a hexadecimal character string.
Called By:
row_decode is called by the decode function in the pr_load.c routine
generated by CHGEN
Revisions.
96 Spring BDESYM rcostell Revised routine to return row value as a
hexadecimal character string, renamed formal parameters, revised
sprintf format specification to support hexadecimal strings, altered
indenting
Preconditions.
o A pointer to a valid hcg_key type field should be passed as the
first argument to the row_decode function.
o A pointer to a character type field should be passed as the second
argument to the row_decode function. The size of the field should be
sufficent to support the decoded row field. If the database schema is
defined with eight character keys, the decoded row field is four
characters [OLD_ROW_LEN]. If the database schema is defined with
twelve character keys, the decoded row field is a five characters
[NEW_ROW_LEN]. The key_len global static variable is used to determine
the key size chosen at schema generation time. The rwshift and rwmask
global variables are used to isolate the row portion of the hcg_key
type field passed as the first argument.
Postconditions.
o The row number of the hcg_key type field passed to the routine is
returned in character format at the location passed as the second
argument to the routine. Successful decoding is indicated by a return
value of 1.
o With the 96 Spring BDESYM project changes, the row number is
returned as a character format hexadecimal string.
o If the key_len global static variable contains a value unknown to
row_decode, the routine returns -1 and does not alter the character
type field passed as the second argument.
Alters.
o None
*******************************************************************/
int row_decode( input_key,
decoded_row )
hcg_key* input_key; /* input const hcg_key* */
char* decoded_row; /* output char* */
{
int rwi;
rwi = (int) ((*(unsigned long*)input_key >> rwshift) & rwmask);
if( key_len == OLD_KEY_LEN )
{
sprintf(decoded_row, "%04X", rwi);
}
else if( key_len == NEW_KEY_LEN )
{
sprintf(decoded_row, "%05X", rwi);
}
else
{
return -1;
}
return 1;
}
/*******************************************************************
int row_encode( hcg_key* output_key,
const char* input_row)
Description:
Encode the row_number provided into the passed hcg_key type field.
Validate the row_number passed using the global constant
max_row.
Called By.
row_encode is called by the encode function in the pr_load.c routine
generated by chgen
Revisions.
96 Spring BDESYM rcostell Revised routine to accept row value as a
hexadecimal character string, renamed formal parameters, revised sprintf
format specification to support hexadecimal strings, altered indenting
Preconditions.
o A pointer to a valid hcg_key type field should be passed as the first
argument to the row_encode function.
o A pointer to a null delimited C character string should be passed
as the second argument to the row_decode function. The character
string should be a hexadecimally encoded table row number.
[NEW_ROW_LEN].
o The max_row global static variable is used in determining the validity of the row number passed to the routine. The rwmask global variable is used in building the row portion of the hcg_key type field passed as the first argument.
Postconditions.
o The row number portion of the hcg_key type field passed to the routine as the first argument is populated with an encoding of the row_number passed as the second argument to the routine. Successful encoding is indicated by a return value of 1.
o If the row number passed as the second argument
can not be successfully encoded, the routine returns -1 and does
not alter the hcg_key* type field passed as the first argument.
In this event, a diagnostic message is written to stdout.
Alters.
o None
*******************************************************************/
int row_encode( output_key,
input_row )
hcg_key* output_key; /* output hcg_key* */
char* input_row; /* input const char* */
{
unsigned long rw;
char* unconv_suff = NULL;
if( (rw = strtoul(input_row, &unconv_suff, 16)) > max_row )
{
printf("ERROR: failure to encode row value:");
printf(" %s; MAX allowed row: %d\n", input_row, max_row);
return -1;
}
else
{
*(unsigned long*)output_key |= (rw & rwmask);
return 1;
}
}
The CHGEN generated pr_create macro invokes the function
pr_gen_create to obtain and initialize storage [to binary zeroes]
for a table row. Field manipulation requests utilizing the polymorphic
pr_get_str and pr_set_str macros utilize the table identifier
component of the row's hcg_key field.
To support the use of pr_*_str macros before a table
row has been pr_add'ed, the pr_create macro was altered to pass
the table abbreviation [in addition to the storage requirements]
to the pr_gen_create routine. The pr_gen_create routine was altered
to utilize the set_abbr key component manipulation function to
initialize the table identifier component of the hcg_key field
at the time that storage for the row is obtained.
/* replacement pr_create macro. invokes pr_gen_create with */
/* table abbreviation as well as structure length to allocate */
#define pr_create(tbl_abbr) \
(struct tbl_abbr *) pr_gen_create( sizeof( struct tbl_abbr),\
#tbl_abbr)
/*********************************************************************
* This routine is used to create a table element and initialize it.
*********************************************************************/
/* BDESYM change to pass.ttabbrev to enable setting of */
/* abbr in hcg_ptr at create time */
hcg_ptr pr_gen_create ( size, tbl_abbr)
int size;
char* tbl_abbr;
{
hcg_ptr ptr = (hcg_ptr) malloc(size);
bzero(ptr, size); /* or memset(ptr, 0, size); */
/* This should also set all the keys to null_key()
* but doesn't right now -- MM
*/
set_abbr((hcg_key *) ptr, tbl_abbr);
return ptr;
}
Eight new tables were added to the original BDE schema.
These tables include : TT, TA, SV, SD, SY, TK, XB, and YR.
There are also changes to the HG, HN, HI, and HA
tables. These changes involve placing the foreign key values of
the YRid and XBid into the various tables. These changes to the
table were originally completed by the 1994 Spring BDESYM team.
As documented in the PDR short tokens (3 characters
or less) are now captured in the symbol table(SY) and repeated
literal character strings will be encoded in the SY foreign key
(SYid). Therefore there is no longer a need for the tktyp
field in the TK table. Many of the functions that previously used
the tktyp field has been improved.
Secondly, a space character is typically a default
character which used to be represented by a row in the TK Table
using the tktyp field. Part of the improvement is to remove the
requirement of placing a separate row in the TK table for a space
and making it the default. In the case of a multiple space before
a symbol the field space has been added to the TK table. The field
space is of type integer and is added to define how many spaces
to place before the token is printed.
Added by 1996 Spring BDESYM Team.
tableattribs TA /* TA: - attribute (field) definitions for tables */
{
TAid tableattrid c8 1 /* Unique id of tattribs table entry. */
TTid tabletypeid c8 1 /* Unique id of table containing
this attribute */
TAname attr_name c20 0 /* short name for field unique in
table */
TAbasetype basetype c20 0 /* generic class of type fields */
TAdbtype database_type c5 0 /* Ingris database format
descriptor */
is_key is_key c1 0 /* symbol or token reference */
TAdescr comment c60 0 /* description of attribute */
}
Added by the 1996 Spring BDESYM Team.
tabletypes TT /* TT - Table definitions for entire schema */
{
TTid tabletypeid c8 1 /* Unique id for this entry in
ttypes table of schema */
SVid projectid c8 1 /* Project */
TTabbr typetag c2 0 /* 2 letter type tag */
TTname symbolname c16 0 /* full name of table */
TTattrcnt attributecount i2 0 /* num of attributes of table */
TTownercnt indegree_of_table i2 0 /* number of incoming links */
TTdescr table_description c60 0 /* text describing table and
contents */
}
Added by 1996 Spring BDESYM Team
project SV /* SV - Project */
{
SVid projectid c8 1 /* Project */
}
horzgraph HG /* DFD: a single dataflow diagram with multiple internal
nodes (added 91/3/12-RJL) */
/* A HG is the expansion of a single parent node on the
next upper level of DFDs */
/* FSid is redundantly contained in the corresponding HN
node of the parent flow diagram */
{
HGid dfdid c8 1 /* unique internal id for this table row */
YRid personname c8 1 /* should match the PP table
entry of this diagram */
FSid funcspecid c8 0 /* fkey of function spec associated with this diagram */
HNid horznnodeid c8 0 /* optional HNid of node which expands into this diagram */
HGauthor personname c12 0 /* the username of the editor of this diagram */
HGcreated datetime c12 0 /* date-time when first
created */
HGlastmod datetime c12 0 /* date-time when last
modified */
XBid title c8 s /* caption for this diagram */
HGtitle title t60 0 /* title for this diagram */
}
horznode HN /* HN - node label and geometry for Data Flow Diagram */
{
HNid horznodeid c8 1 /* unique internally generated
ID */
HGid dfdid c8 1 /* unique fkey of horzgraph
container of this node*/
FSid funcspecid c8 0 /* unique fkey of function
spec corresp to this node */
/* NOTE: FS<-->HN relation is not necessarily 1 to 1) */
/* NOTE: FSId is also in the child HG or AT table entry (iff */
/* this node has a DFD or an ALG text block) */
YRid funcspecid c8 1 /* unique fkey of function
spec corresponding to this
node */
shape nodeshape c1 0 /* C = circle, R = rectangle,
O = rounded rectangle */
centerx coordinate f4 0 /* x coord of node center */
centery coordinate f4 0 /* y coord of node center */
width nodewidth f4 0 /* width of rect circle */
height nodeheight f4 0 /* height of rect circle */
/* change txtfont size from 50 to 25 - phsia */
txtfont fontname c25 0 /* label text font selector
(when available) */
txtoffsetx xoffset f4 0 /* where text begins
relative to HN */
txtoffsety yoffset f4 0 /* where text begins relative
to HN center */
txtwidth txtwidth i2 0 /* text x-extent */
txtheight txtheight i2 0 /* text y-extent */
XBid nodetext c8 s /* multi-line text (verb + I object) label within DFD node */
nodename nodetext t20 0 /* multi-line text (verb +
object) label within DFD node */
}
horzattribute HA /* HA - Node attribute (e.g., field names in DSD
table type */
{
HAid hattribid c8 1 /* unique internally generated
ID of link label */
HNid node_id c8 1 /* unique ID of link to which
label is attached */
DAid dataitemid c8 0 /* Unique ID of named data
item flowing on this link */
/* The x, y offset in first entry of HA table are rel. to coordinate
* of nodename in HN */
txtoffsetx xoffset f4 0 /* x-offset of label text rel.
to previous text */
txtoffsety yoffset f4 0 /* y-offset of label text rel.
to previous text */
HAorigin reldistance f4 0 /* HA's offset to the last */
txtwidth xwidth i2 0 /* x-extent of label text */
txtheight yheight i2 0 /* y-extent of label text */
/*change txtfont from 50 to 25 and hlabel from 20 to 40 - phsia */
txtfont fontname c25 0 /* text font name (inc size)*/
XBid symbol_name c8 s /* name of node attribute
(text string)*/
hlabel symbol_name t40 0 /* name of node attribute (
(text string) */
}
horzident HI /* HI - horiz. link ident. label for Data Flow Diagram
link */
{
HIid horzidentid c8 1 /* unique internally generated
ID of link label */
HLid uniontype c8 1 /* unique ID of link to
which label is attached */
/* HLid might become a TU (HPorHLid) if labels are attached to specific
segment */
DIid dataitemid c8 0 /* Unique ID of named data
item flowing on this link */
/* a HN pair can have two (oppositely directed) links for 2-way
* flows; SCs have one-way calls only */
/* VI table entries have a flow direction attribute; HI table
* entries do not */
HIorigin reldistance f4 0 /* fractional distance along
HL to HI origin */
tbeginx yoffset f4 0 /* x-offset of label text rel.
to HI origin */
tbeginy voffset f4 0 /* y-offset of label text rel.
to HI origin */
txtwidth xwidth i2 0 /* x-extent of label text */
txtheight yheight i2 0 /* y-extent of label text */
/*change txtfont from 50 to 25 and hlabel from 20 to 40 - phsia*/
txtfont fontname c25 0 /* text font name(inl size) */
YRid symbol_name c8 1 /* name of dataflow item (link
label text string) */
hlabel symbol_name t40 0 /* name of dataflow item (link
label text string) */
}
Created by the 1994 Spring BDESYM Team. Integrated
into the 1995 Fall BDE Schema by the 1996 Spring BDESYM Team.
symboldictionary SD /* symbol dictionary descriptor */
{
SDid symdictionaryid c8 1 /* pkey of symbol diction */
stvers sytblversion i4 0 /* Number of references to
symnam */
sydate creationdate c26 0 /* dictionary creation date */
stname dictionaryname c25 0 /* symbol dictionary name */
}
Created by the 1994 Spring BDESYM Team. Integrated
into the 1995 Fall BDE Schema by the 1996 Spring BDESYM Team.
symbol SY /* symbol descriptor */
{
SYid symbolid c8 1 /* pkey of the symbol */
SDid symdictionaryid c8 1 /* pkey of symbol diction */
symrcnt symrefcount i4 0 /* no. of reference to a
symbol */
symnam symbolname c72 0 /* name of a symbol */
}
Created by the 1994 Spring BDESYM Team. Integrated
into the 1995 Fall BDE Schema by the 1996 Spring BDESYM Team.
Additional changes to the TK table (described above) included.
token TK /* token descriptor */
{
TKid tokenid c8 1 /* pkey of the token */
XBid textblockdesid c8 1 /* fkey of text block des. */
SYid symbolid c8 1 /* fkey of symbol */
space prefixspace i4 0 /* spacing before token */
}
Created by the 1994 Spring BDESYM Team. Integrated
into the 1995 Fall BDE Schema by the 1996 Spring BDESYM Team.
sYmbolReference YR /* symbol reference descriptor */
{
YRid symbolrefid c8 1 /* pkey of the reference */
SYid symbolid c8 1 /* fkey of the referenced
symbol */
}
Created by the 1994 Spring BDESYM Team. Integrated
into the 1995 Fall BDE Schema by the 1996 Spring BDESYM Team.
teXtBlock XB /* text block descriptor */
{
XBid textblockid c8 1 /* pkey of the textblock */
}
/*
** FUNCTION NAME: TK_parse_text()
**
** FUNCTIONAL DESCRIPTION: This function parses a string specified by
** the user into tokens. The net effect is
** also to generate a new XB structure within
** the current document to
** represent this string.
**
** RETURN VALUE: None.
**
** SIDE EFFECTS: None.
**
** Pre-Conditions:
**
** Post-Conditions:
**
** Alters:
*/
int TK_parse_text(pd_buffer_ptr, xb_pkey)
char *pd_buffer_ptr;
hcg_key xb_pkey;
{
/*
** DECLARATIONS
*/
struct XB *XB_elt;
hcg_key xb_key;
/*
** Call the lexical analyzer to parse the string. It is assumed that
** The macro SYMTXT_INPUT has been correctly define so the lexical
** analyzer will process the string instead of a file stream.
*/
/*
XB_elt = pr_create( XB );
pr_add("94sbdeview", XB, XB_elt);
XB_pkey = pr_get_key(XB_elt, XBid);
*/
/*
** Set all token variables to an initial state when processing
** a new document.
*/
previous_lexical[0] = '\0';
lexical_cnt = 0;
pd_string = pd_buffer_ptr;
yylex(xb_pkey);
TK_save_previous_literals(xb_pkey);
}
Modification of the TK table in the schema results
in several required changes to the SYMTXT code located in the
/text directory. Included in these source changes include
the way spaces are handled and encoding of the repeat literal
string in the SY foreign key.
Each module which requires a change is presented
below. Included in this review is a description of the change,
the function header description(s) and the proposed code changes.
The module sym_pj_mgr.c contains the function XB_restore_text().
The main purpose of this function is to obtain the text that is
contained in within the TK table for the XB key passed in. This
function XB_restore_text() needs to be modified to reflect
the changes that were made in the TK table. All references to
the tktyp field of the TK table shall be removed. This
function also checks to see if a repeated literal string is encoded
in the SY foreign key (SYid) by checking to see if the 5th
character is set to "F". If the 5th character
is encoded with an "F" then this function attempts to
extract the literal token stored in character positions 7 &
8. Once the token is decoded the repeat count is obtained from
the 6th character position and the character is placed
into the buffer that many times. The prefix spacing has been added
to this function. The number of spaces added is determined by
the space field in the TK table.
/*
** FUNCTION NAME: XB_restore_text()
**
** FUNCTIONAL DESCRIPTION: This function restores the text specified ** by the XBid,
**
** RETURN VALUE: pointer to a character array (*text).
**
** Preconditions:
** o The value of xb_pkey is of type hcg_key for a row in the XB
** table and is passed in as the first parameter
**
** Postconditions:
** o The token encoded in the SY foreign key or located in the symbol
** table and is returned as a character pointer.
**
** Alters:
** o If xb_pkey is NULL a warning message is printed out and NULL is
** returned.
*/
char *XB_restore_text(hcg_key xb_pkey) /* hcg_key value for a row
* in XB table.
*/
{
int i; /* Scratch... loop variable */
int j;
char literal_value; /* Character value of the decoded literal */
char word [ SYMBOL_NAME_SIZE + 1]; /* word string copied from the schema structure */
hcg_key xbkey;/* key of a DS structure */
char *buffer; /* Buffer where extracted items are placed */
int spacing; /* Used to help count spaces of each TK token
* extracted
*/
char syid_string[13];/* A decoded SYid into a character
string */
buffer = (char *)malloc(128* sizeof(char));
pr_find(XB,XBid, xb_pkey);
if ( XBcurr == NULL )
{
printf("\n\nSYMTXT-E-INVDS, invalid or non-existent XBid\n\n\n");
return NULL;
}
child_loop(XB,TK,TKid,XBid)
{
:
/* Add the prefix spaces to the buffer
* prior to getting the token.
*/
spacing = TKcurr->space;
while(spacing > 0)
{
strcat(buffer, " ");
spacing--;
}
/* Decode the SY foreign key id into a character string in
* order for processing
*/
sy_key = pr_get_key(TKcurr, SYid);
decode(syid_string, &sy_key);
/*
* If the 5th field in the SY foreign key field is not set
* to "F" then attempt to
* retrieve the symbol from the symbol table SY,
* otherwise decode the
* literal value from the SY foreign key.
*/
if (syid_string[4] != 'F')
{
pr_find(SY,SYid,TKcurr->SYid);
strcpy((char *) &word[ 0 ],(char *) &SYcurr->symnam[0] );
i = 0;
while( word[ i ] != ' ' )
i++;
word[ i ] = '\0';
strcat(buffer, &word[0]);
}
else
{
/*
** The syid_string has been encoded with a literal ** token. This sections extracts the literal token out of the 7th
** and 8th field of the SYid.
*/
if (syid_string [ 6 ] >= 'a' )
{
literal_value = (syid_string [6] - 'a' + 10 ) * 16;
if (syid_string [ 7 ] >= 'a' )
literal_value += syid_string [ 7] - 'a' + 10;
else
literal_value += syid_string [ 7 ] - '0';
}
else {
literal_value = (syid_string [ 6 ] - '0' ) * 16;
if (syid_string [ 7 ] >= 'a' )
literal_value += syid_string [ 7 ] - 'a' + 10;
else
literal_value += syid_string [ 7 ] - '0';
}
switch (syid_string[5]){
case 'A': case 'B': case 'D': case 'E': case 'F':
loopvalue = 55;
break;
default:
loopvalue = 48;
break;
}
/*
** Extract the repeat count from the 6th field and go
** through the for loop printing the individual literal
** value.
*/
for ( i = 1; i <= (syid_string[ 5 ] - 33 ); i++ ) {
word[0] = literal_value;
word[1] = '\0';
strcat(buffer, &word[0]);
}
break;
}
} /* end child_loop */
return (buffer);
}
This module contains three functions which require change due to the TK table changes in the schema. There are also two functions within this module that are duplicated in symtxt.c and have be removed.
The function TK_generator() is called to process
a token when a token is matched according to the pattern specified
by the lex rules. This function needs to be updated first to remove
the references to the tktyp field of the TK table. The
section of code which encodes a short word in the tktyp
field of the TK table is removed. The section which places "0000"
and "XXXX" in the tktyp table is removed also.
/*
** FUNCTION NAME: TK_generator()
**
** FUNCTIONAL DESCRIPTION: This function is responsible for
** processing of the tokens initially
** received from the lexical analyzer.
** It then builds a TK structure based
** on the sym_schema and updates the SYid
** keys.
**
** RETURN VALUE: None.
**
** CALLING SEQUENCE: TK_generator(unsigned int, char *, int, hcg_key )
**
** Preconditions:
** o The curr_view_name parameter is defined with the current view
** o The lex_token_type variable contains an unsigned integer
** describing the type of token processed by the lexical analyzer
** o The lex_symbol variable contains a valid character pointer to
** the symbol name
** o The lex_symbol name variable contains the string length of the
** symbol name
** o The previous_lexical variable is either set to "\0" or some
** other literal value
**
** Postconditions:
** For LITERALS :
** o If the previous_lexical[0] variable is the same as the lex
** symbol passed in then the lexical_cnt variable is incremented
** by 1.
** o The previous_lexical[0] variable contains the value of lex
** symbol passed in.
** o The lexical_cnt variable is set to one if the lex_symbol being
** processed is not the same as the previous lex symbol.
** For WORDS :
** o The lexical symbol length is a valid integer from 1-MAXLEN and
** is the sting length of the symbol
**
** Alters:
**
*/
int TK_generator(unsigned int lex_token_type,
/* an unsigned integer describing the type of token
* processed by the lexical analyzer.
*/
unsigned char *lex_symbol,/* a char pointer of the symbol name */
int lex_symbol_len, /* string length of the symbol name */
hcg_key xb_pkey)
{
/*
** DECLARATIONS
*/
char *encoded_token; /* Encoded value of literal or word token */
char syid_string[ 13 ]; /* A decoded SYid into a char string */
char word_str[ SYMBOL_NAME_SIZE + 1 ]; /* Max size of word token allowed by schema */
hcg_key tmp_key; /* temp SY key used for updating tktyp */
struct TK *TK_elt; /* chgen TK structure taken from
sym_schema.h */
word_str[ 0 ] = '\0';
switch( lex_token_type )
{
case LITERAL_TOKEN :
/*
** Match the current literal with the previous one. If they are
** the same, determine if the literals are '\n' characters. If so,
** and the lexical_cnt is a multiple of 2, create a XB row in the
** network database. If the previous literal is not a '\n' and the
** previous literal is equal to the current one, just increment
** the lexical cnt. When the previous literal is different from
** the current one, encode it along with the repeat count
** "lexical_cnt" in the network database.
*/
switch( previous_lexical[ 0 ] )
{
case '\0' :
if(strcmp(lex_symbol," ") == 0)
{
printf("Item is a space\n");
space_cnt++;
}
else {
previous_lexical[ 0 ] = *lex_symbol;
lexical_cnt = 1;
}
break;
default :
if ( previous_lexical[ 0 ] == *lex_symbol )
{
lexical_cnt++;
if(( previous_lexical[ 0 ] == '\n' ) && ( lexical_cnt % 2 == 0 ))
{
/************* start ********** added by 94ssym BDESYM Group **********/
/*
XB_elt = pr_create( XB );
pr_add(curr_view_name, XB, XB_elt);
*/
/************ end ************* added by 94ssym BDESYM Group
********/
}
break;
}
else { TK_save_previous_literals(xb_pkey);
previous_lexical[ 0 ] = *lex_symbol;
lexical_cnt = 1;
break;
}
}
break;
case WORD_TOKEN :
/*
** Process the word token received from the lexical
** analyzer. First,
** save any previous literals that were not saved.
*/
TK_save_previous_literals(xb_pkey);
/*
** Update the TK database with the regular word.
**
** Update the word normally,
** unless the size of the
** is greater then SYMBOL_NAME_SIZE, which
** corresponds to the symbolname
** size. If that's the case, break up the
** word into chunks not to
** exceed SYMBOL_NAME_SIZE in size, and update
** them in the database
*/
TK_elt = pr_create(TK);
pr_set_key(TK_elt, XBid, xb_pkey);
if ( lex_symbol_len > SYMBOL_NAME_SIZE )
{
strncpy((char *) &word_str[ 0 ], lex_symbol,
SYMBOL_NAME_SIZE );
word_str[ SYMBOL_NAME_SIZE + 1 ] = '\0';
} else {
strcpy((char *) &word_str[ 0 ], lex_symbol);
word_str[ lex_symbol_len + 1 ] = '\0';
}
sy_key = SY_manager( (char *) &word_str[ 0 ] );
pr_set_key(TK_elt, SYid, sy_key );
/* Set the prefix space if greater 0 */
if (space_cnt > 0)
{
pr_set_int(TK_elt, space, space_cnt);
space_cnt = 0;
}
pr_add(curr_view_name, TK, TK_elt);
decode(syid_string, &sy_key);
if ( syid_string[ 4 ] > 'E' )
{
printf("SYMTXT-W-TKCNT, exceeded SYid count\n");
} else
lex_symbol_len = 0;
}
break;
}
return;
}
The function TK_encode_token() will be modified
to prepare the literal token to be encoded in the SY foreign key
(SYid). This function is not called for regular words (including
short words). Regular words are encoded in the SY table when the
function SY_manager() is called. When given a literal token
this function will encode the literal into the SY foreign key
(SYid) and return a pointer to the string. The hexadecimal value
for the literal passed in is computed and encoded into the 7th
and 8th character fields. This was previously encoded
in the 3rd and 4th field of the tktyp
field (e.g. SY00F221 - which represents 3 instances of !). Existing
code segments used to encode a short word in the tktyp
field of the TK table will be removed.
Another change includes the removal of two function
arguments. The encoding_type argument use to specify whether
the token passed in was a WORD type or a LITERAL type. Since short
words are no longer encoded in the TK table and all other non-literal
words are encoded in the SY table there is no need to have this
encoded in any row of the TK table. Only LITERAL token types are
encoded into the TK table. The token_length argument will
be removed since it is currently not used in the function. The
only calling function that will need to be adjusted to these arguments
changes is TK_save_previous_literals().
Code for encoding a word type in the tktyp
field will be removed from this function. The code for encoding
a repeated literal string in the tktyp field is modified
slightly.
/*
** FUNCTION NAME: TK_encode_token().
**
** FUNCTIONAL DESCRIPTION: This functions encodes a given
** literal
** into the SY
** foreign key
**
** RETURN VALUE: coded_str - pointer to the encoded character string.
**
** CALLING SEQUENCE: TK_encode_token().
**
** IMPLICIT INPUT PARAMETERS: None
**
** IMPLICIT OUTPUT PARAMETERS: None
**
** Preconditions:
** o The token field contains a valid 1 character literal returned ** by the lex analyzer
** o The repeat count variable is a valid integer from 1 to 16
**
** Postconditions:
** o The token is encoded in a 8 character string. A pointer to is ** returned to the calling function
**
** Alters:
** o The function will encode the value no matter if it is of type
** literal or not.
**
*/
char *TK_encode_token(
char *token, /* char ptr to the token string */
unsigned int repeat_count) /* repeat count for the literal
* character
*/
{
/*
** DECLARATIONS
*/
static char coded_string[ TOKENTYPE_LEN ]; /* The encoded value
* returned by this
* function.
*/
unsigned char tmp_char; /* Scratch character used for manipulations
*/
/*
** Encode a single literal character that is repeated
** many times. e.g. white
spaces, '...', '!!!', or
** other literal types.
**
** This encoding is done as follows:
** -- place LITERAL_TYPE (i.e. SY00F) in character
** position 0-3 to indicate the type of token
**
** -- Convert the repeat count to a printable character,
** i.e. ASCII codes (33 through 126), by adding
** 48 if repeat count less than 9 or by adding
** 55 if repeat count 10 or geater.
** Copy this repeat character to position 5
**
** -- Lastly convert the ASCII value of the literal to
** a string, with char position [6] having the half
** byte hex value, and char position [7] having the low
** half byte hex value.
** The result indicates the ASCII hex value of
** the literal, in string format from positions 6
** and 7.
*/
strcpy(coded_string,"SY00F");
if (repeat_count <=9)
coded_string[ 5 ] = ( char ) ( repeat_count + 48 );
else
coded_string[ 5 ] = ( char ) ( repeat_count + 55 );
tmp_char = (*token & 0xf0) >> 4;
if ( tmp_char >= 10 )
tmp_char = tmp_char - 10 + 'a';
else
tmp_char = tmp_char + '0';
coded_string[ 6 ] = tmp_char;
tmp_char = *token & 0x0f;
if ( tmp_char >= 10 )
tmp_char = tmp_char - 10 + 'a';
else
tmp_char = tmp_char + '0';
coded_string[ 7 ] = tmp_char;
coded_string[ 8 ] = '\0';
return &coded_string[ 0 ];
break;
}
Changes to this function include the re-adjusting
the function call to TK_encode_token() to account for its
change in parameters. The first parameter to be removed is the
global LITERAL_TYPE which is simply states that the token passed
in is a literal. This is no longer needed since the only tokens
that TK_encode_token() processes now is literals. The second
paramter passed is "1" and this is the default.
The second change, involves changing the repeat count
value of a repeated literal string from 93 to 16. The define statement
#define REPCOUNT 16 will be created in order to allow for easier
code changes in the future.
Sections that previously placed the encoded token
in the tktyp field has been reworked to encode it in the
SY foreign key (SYid) field.
/*
** FUNCTION NAME: TK_save_previous_literals()
**
** FUNCTIONAL DESCRIPTION:
**
** This functions saves any literal that was
** not previously saved. It's called before a new token is processed.
** This is necessary, when a single literal is repeated many times,
** followed by a normal non literal token.
**
** RETURN VALUE: None
**
** CALLING SEQUENCE: TK_save_previous_literals().
**
** PRECONDITONS:
** o A valid xb_pkey is passed in.
** o The lexical_cnt value is a valid integer value of 0-16
**
** Postconditions:
** o The lexical_cnt value is returned with the value 0.
** o The previous_lexical variable is set to "\0".
** o The encoded token is encoded in the SY foreign key (SYid)
** o New row(s) are added to the TK table with the current XB pointer
** with a maximum repeat count of 16.
**
** Alters:
** o Results are un-predictable if the lexical_cnt is not within the
** 0-16 value.
*/
int TK_save_previous_literals(xb_pkey)
hcg_key xb_pkey;
{
/*
** DECLARATIONS
*/
unsigned int temp_cnt; /* A counter of the number of
* processed literal tokens
*/
char *encoded_token; /* Encoded value of literal or word
* token
*/
struct TK *TK_elt; /* chgen TK structure taken from
*/
/*
** Check to make sure that previous literal exist. If they don't, just
** return. There is no need to perform additional checking.
*/
if ( lexical_cnt != 0 )
{
/*
* Save any literals which occurred which were not processed.
* 16 is the magic number because if the repeat cnt exceeds * 16, then it enters the realm of non printable characters and * cannot be viewed directly. If the repeat count is greater than * 16, create a new TK_elt which represents a literal that is
* repeated 16 of fewer times. Continue this until the
* literal and its repeat count is fully represented via TKid's.
*/
if( lexical_cnt <= REPCOUNT )
{
encoded_token = TK_encode_token(
&previous_lexical[ 0 ],
lexical_cnt );
TK_elt = pr_create(TK);
encode(encode_token, &sy_hcg_key);
pr_set_key(TK_elt, XBid, xb_pkey);
pr_set_key(TK_elt, SYid, sy_hcg_key);
if(space_cnt > 0)
{
pr_set_int(TK_elt, space, space_cnt);
space_cnt = 0;
}
pr_add(curr_view_name, TK, TK_elt);
previous_lexical[ 0 ] = '\0';
lexical_cnt = 0;
} else {
temp_cnt = REPCOUNT;
while( lexical_cnt != 0 )
{
encoded_token = TK_encode_token(,
&previous_lexical[0],
temp_cnt );
TK_elt = pr_create(TK);
encode(encode_token, &sy_hcg_key);
pr_set_key(TK_elt, XBid, xb_pkey);
pr_set_key(TK_elt, SYid, sy_hcg_key);
if(space_cnt > 0)
{
pr_set_int(TK_elt, space, space_cnt);
space_cnt = 0;
}
pr_add(curr_view_name, TK, TK_elt);
lexical_cnt = lexical_cnt - temp_cnt;
if ( lexical_cnt > REPCOUNT )
temp_cnt = REPCOUNT;
else temp_cnt = lexical_cnt;
}
}
previous_lexical[ 0 ] = '\0';
}
}
The function get_tokset() is repeated in symtxt.c
and has been removed from this module.
This function get_sym() is repeated in symtxt.c
and has been removed from this module.
Removal of the tktyp field in the TK table
does not affect this module.
This module contains the functions get_sym()
and get_tokset(). Code changes added during BDESYM development
are describe below.
The function get_tokset() was not originally going
to be changed but during code inspection during development it
was discovered that table indexes where hardcoded into this function.
Each table during creation is assigned a number. Adding new tables
to the front of the schema as required by the 1996 BDESYM team
change the index numbers for the HG, HN, and HA table. With the
numbers previously hard-coded in this function, the probability
of failure is high when a new table is added to or deleted from
the schema. We have updated the functions so that they do not
depend on a tables position in the schema but more on what the
name of the table.
/*
* FUNCTION: get_sym()
*
* FUNCTION DESCRIPTION: Used to retrieve the text value for
* field of type "symref"
*
* RETURN VALUE: char pointer of the symbol id
*
* Preconditions:
* o The table index passed in is a valid integer and valid index
* for the HG, HN, or HI table.
*
* Postconditions:
* o A character pointer to a symbol id is returned
*
* Alters:
* o If the table index is invalid the program will halt on the
* assert message.
*
*/
char *get_sym(int tbl_idx)
{
if (strcmp(hcg_table_seq_list[tbl_idx].ttabbrev, "HG") == 0)
return(HGcurr->YRid_pp->SYid_pp->symnam);
else
if (strcmp(hcg_table_seq_list[tbl_idx].ttabbrev, "HN") == 0)
return(HNcurr->YRid_pp->SYid_pp->symnam);
else
if (strcmp(hcg_table_seq_list[tbl_idx].ttabbrev, "HI") == 0)
return(HIcurr->YRid_pp->SYid_pp->symnam);
else
{
printf("Invalid ttabbrev\n");
assert(1);
}
}
Similar to the function get_sym(), the function get_tokset()
was not originally going to be changed but during code inspection
during development it was discovered that table indexes where
hardcoded into this function. Each table during creation is assigned
a number. Adding new tables to the front of the schema as required
by the 1996 BDESYM team change the index numbers for the HG, HN,
and HA table. With the numbers previously hard-coded in this function,
the probability of failure is high when a new table is added to
or deleted from the schema. We have updated the functions so that
they do not depend on a tables position in the schema but more
on what the name of the table.
/*
* FUNCTION: get_tokset()
*
* FUNCTION DESCRIPTION: Reconstructs a multi-word text from all
* the tokens that belongs to a particular
* XBid, which belongs to a particular table.
*
* RETURN VALUE: Character string from the XB table
*
* Preconditions:
* o The table index passed in is a valid integer and valid index
* for the HG, HN, or the HA table.
*
* Postconditions:
* o A pointer to an array of characters from the XB table
* is returned
*
* Alters:
* o Results are unpredictable if the tbl_idx is not between 1-3.
*/
char *get_tokset(int tbl_idx)
{
char *text;
if (strcmp(hcg_table_seq_list[tbl_idx].ttabbrev, "HG") == 0)
pr_find(XB, XBid, HGcurr->XBid);
else if (strcmp(hcg_table_seq_list[tbl_idx].ttabbrev, "HN") == 0)
pr_find(XB, XBid, HNcurr->XBid);
else if (strcmp(hcg_table_seq_list[tbl_idx].ttabbrev, "HA") == 0)
pr_find(XB, XBid, HAcurr->XBid);
else
{
printf("Invalid ttabbrev\n");
assert(1);
}
text = XB_restore_text(pr_get_key(XBcurr, XBid));
return text;
}
The function prototype for many of the BDESYM functions
located in the /text directory was changed from non-ANSI C standard
style to the more ANSI C standard.
Example:
The following prototype from sym_tk_mgr.c was changed
from
char *TK_encode_token( encoding_type, token, token_length, repeat_count )
unsigned int encoding_type;
char *token;
int token_length;
unsigned int repeat_count;
to
char *TK_encode_token(unsigned int encoding_type, /* comment */
char *token, /* comment */
int token_length, /* comment */
unsigned int repeat_count) /* comment */
The following function found in the /text
directory under specified unit (described below) is no longer
used. This function was recommended for removal from the module
or at least provided with comments to describe that it is not
part of BDESYM functions.
| Function | Unit |
| sy_add_symbol_name() | sym_sy_mgr.c |
| Function | Unit |
| sy_manager() | sym_sy_mgr.c |
| sy_get_sym_ptr() | sym_sy_mgr.c |
Most of the changes to the BDE source code will be due to the 1994 Spring and Fall BDESYM baseline integration. However there are some changes that are needed due to the fact that the BDE source code has been modified. This section attempts to document all areas that have been modified.
All references in the code to "SY000000"
should be removed. These SY foreign key (SYid) was set to this
to signal the code that either a short word is stored in the tktyp
field or that a literal token is stored in the tktyp field.
Since the tktyp field will be removed it is necessary to remove
and correct all references to this special key.
The files edit.cc and textops.cc reference the SY
foreign key "SY000000" which in the old design represented
that either an in-line token was encoded in the tktyp field or
that a repeated character string was encoded in the tktyp field.
This will need to be corrected.
In the function text_delete the XB row is being removed
when text is being deleted from a node. This however removes the
XBid foreign key from the node and causes a core dump when the
user tries to enter new text into the node. In order to overcome
this problem quickly we have set the nodes text with a blank field,
the pr_set_tokset(HNcurr, XBid, "") function is called.
This may not be the correct way to handle this and we leave this
as a design area to look into by future BDESYM teams.
Similar to what was completed in textops.cc the pr_set_tokset(HN_elt, XBid, "") macro was called in the function void Ggroup::addnode (float x, float y). Like above this was done to prevent BDE from core dumping when validating what was in the XBid field. This may not be the correct way to handle this and we leave this as a design area to look into by future BDESYM teams.
The 96 Spring BDESYM project has delivered several documents at this point. Several of these documents are provided as on-line Web pages (HTML Format) which have been converted by the Microsoft Word Internet Assistant tool.
This document outlines the 96 Spring BDESYM project requirements. The project deliverables will be detailed in the document. A project plan includes a timeline for project tasks was also included in the document.
This document outlines the design considerations
and describes the approach chosen for encoding information in
the TK table SY foreign key field. It is provided as an appendix
to the Project Requirements Document.
This document will detail the approach used toward
encoding field attributes [YR Table reference or XB table reference]
in the schema comment field [reference section 2.2 of this document].
Alterations made to the CHGEN gen_defines.cc module
to support revision of the pr_get/set_str macros required by the
BDESYM project will be described in this document [reference section
2.2 of this document].
*** Also bug fixes from ~rcostell/91523/note
Hints and tips regarding BDESYM maintenance has been detailed in this on-line HTML document. The main concentration of this document is the procedures required by the maintenance programmer for building and testing BDESYM.
After each of the three planned builds, test cases
were planned to be executed to insure correct operation of the
BDESYM revisions. The test case coverage concentrated on BDE text
related functions [add and delete] of text in tables HG [author
and title fields], HN [nodename], HI [label] and HA [label]. Diagrams
built during testing was saved and re-loaded to insure correct
proper operation of the pr_util routines supporting the persistent
database. Additionally, the internal format of the saved tables
was inspected to insure that the external representation of the
diagrams meets specifications. A diagram of the test graph used
for creation and modification can be found in Appendix A.
The following describes the test results of the successful
Builds that were completed.
All .dat files mentioned below are located in /usr/proj3/case/96s523/bdesym/base/test
directory. Some of the .dat files mentioned within the cases are
included in Appendix B.
Build 1 consisted of integrating the 1994 Spring
Baseline with the current 1995 Fall version of BDE. This integration
included adding the SY, TK, YR, and XB tables to the schema. A
link to SYMTXT source from the /text directory was added
to the makefile so that it would get linked in. Also included
in this build was the addition of the TT, TA, and SV tables to
the schema. The module pr_load.c was modified to include
new row_encode() and row_decode() macros which generate
hexadecimal key values vs. integer key values.
The following describes the test results according
to the test plan presented in section 6.0 of the CDR. Presented
below are three test parts. The first part involves the graph
creation, additions, saving, and successful exit from BDE. The
second part involves modification of the graph previously created
in Part 1. The third part involves inspection of the contents
of the .dat files.
Test .dat file : bdesym.test_1.dat
Test Date : 5/10/96
| P/F | Test Condition |
| PASS | A completely new graph shall be created using the BDESYM functions. |
| PASS | The graph presented in Figure 3 shall be created and given a name |
| PASS | The graph header shall contain two literal tokens and extra spaces between the tokens |
| PASS | Three nodes shall be created |
| PASS | Each of the nodes shall be assigned a name of node <number> |
| PASS | Links between nodes shall be created |
| PASS | Each of the links shall be assigned a name of link <number>. |
| FAIL | After the modifications have been completed the graph shall be printed |
| PASS | After the graph has been created the graph shall be saved in a bdesym.dat file |
| PASS | Exit from BDE shall be successful with the graph saved |
Test .dat file : bdesym.test_2.dat -
Test date : 5/10/96
This second test part shall prove that the graph
previously created in test case shall be able to be successfully
modified by BDESYM functions.
The .dat created in Part 1 was renamed to bdesym2.dat
| P/F | Test Condition |
| PASS | The graph in the previous test part shall be selected, opened, and displayed to according what was created in Part 1 |
| PASS | The text string within node 1 shall be modified from "node one" to "node uno". |
| PASS | The text string attached to link 2 shall be modified from "link two" to "link #2". |
| PASS | A graph caption with text shall be added. |
| PASS | After the modifications have been completed the graph shall be saved. |
| FAIL | After the modifications have been completed the graph shall be printed |
| PASS | Exit from BDE shall be successful with the graph saved |
| PASS | The text block (XB) for node 2, node 3, and link 1 and 3 shall be the same as in the previous bdesym.dat file |
| PASS | The text block (XB) for node 1 shall be changed |
| N/A | A new symbol entry should be placed in the SY table for the string "uno". |
| N/A | A new symbol entry should be present in the SY table for the string "2". |
| N/A | This row should have a prefix-space count of 0 since there are no spaces between # and 2. |
| N/A | The literal "#" should be encoded into the SY foreign key. This row should also have prefix space count of 4. |
The majority of test conditions in this first two
parts were marked with PASS because the test condition was met
during execution of BDE. The item marked with FAIL was the print
function. A core dump occurred during the attempt to print the
graph created.
Many of the inspections of the .dat file in Part
3 were marked with N/A since these requirements are not be seen
until Build 3.
The testing of this build completes the requirements noted in the PDR of sections 2.1, 2.1.1, 2.1.2, and 2.1.3.
Build 2 also consists of the additions of the new
polymorphic pr_set/get_str macros. This includes cut and paste
changes to the pr_load.c file and the 94sbde_schema.h file. This
also required some changes to the BDE source code (same source
modules that were integrated in the first build).
Test .dat file : TBD
Test Date : TBD
| P/F | Test Condition |
| A completely new graph shall be created using the BDESYM functions. | |
| The graph in Figure 3 shall be created and given a name | |
| The graph header shall contain two literal tokens and extra spaces between the tokens | |
| Three nodes shall be created | |
| Each of the nodes shall be assigned a name of node <number> | |
| Links between nodes shall be created | |
| Each of the links shall be assigned a name of link <number>. | |
| After the modifications have been completed the graph shall be printed | |
| After the graph has been created the graph shall be saved in a bdesym.dat file | |
| Exit from BDE shall be successful with the graph saved |
Test .dat file : TBD
Test date : TBD
Notes :
This second test part shall prove that the graph
previously created in test case shall be able to be successfully
modified by BDESYM functions.
| P/F | Test Condition |
| The graph in the previous test part shall be selected, opened, and displayed to according what was created in Part 1 | |
| The text string within node 1 shall be modified from "node one" to "node uno". | |
| The text string attached to link 2 shall be modified from "link two" to "link #2". | |
| A graph caption with text shall be added. | |
| After the modifications have been completed the graph shall be saved. | |
| After the modifications have been completed the graph shall be printed | |
| Exit from BDE shall be successful with the graph saved |
| P/F | Test Condition |
| The text block (XB) for node 1 shall be changed | |
| A new symbol entry should be placed in the SY table for the string "uno". | |
| A new symbol entry should be present in the SY table for the string "2". | |
| This row should have a prefix-space count of 0 since there are no spaces between # and 2. | |
| The literal "#" should be encoded into the SY foreign key. This row should also have prefix space count of 4. |
Due to compile time errors Build 2 has not been completed
yet.
The testing of this build will complete the requirements
noted in the PDR of sections 2.2.
Requirement 3.4 will not be met by the 1996 Spring
BDESYM team.
Build 3 consisted of adding the new 1996 Spring BDESYM
Project Improvements (encoding the SY foreign key, removal of
the tktyp in the schema, and the addition of the prefix space
flag field) onto the baseline created in Builds 1 and 2. Since
Build 2 was not successful this build only contains improvements
noted in Build 1.
The following describes the test results according
to the test plan presented in section 6.0 of the Critical Design
Review (CDR) Document. Presented below are three test parts. The
first part involves the graph creation, additions, saving, and
successful exit from BDE. The second part involves modification
of the graph previously created in Part 1. The third part which
is the most important part in this Build since it involves inspection
of the contents of the .dat files.
Test .dat files : bdesym.test_3.dat and bdesym.test_4.dat
Test Date : 5/14/96
| P/F | Test Condition |
| PASS | A completely new graph shall be created using the BDESYM functions. |
| PASS | The graph presented in Figure 3 shall be created and given a name |
| PASS | The graph header shall contain two literal tokens and extra spaces between the tokens |
| PASS | Three nodes shall be created |
| PASS | Each of the nodes shall be assigned a name of node <number> |
| PASS | Links between nodes shall be created |
| PASS | Each of the links shall be assigned a name of link <number>. |
| FAIL | After the modifications have been completed the graph shall be printed |
| PASS | After the graph has been created the graph shall be saved in a bdesym.dat file |
| PASS | Exit from BDE shall be successful with the graph saved |
Test .dat file : bdesym.test_4.dat
Test date : 5/16/96
This second test part shall prove that the graph
previously created in test case shall be able to be successfully
modified by BDESYM functions.
The .dat created in Part 1 was renamed to bdesym2.dat
| P/F | Test Condition |
| PASS | The graph in the previous test part shall be selected, opened, and displayed to according what was created in Part 1 |
| PASS | The text string within node 1 shall be modified from "node one" to "node uno". |
| PASS | The text string attached to link 2 shall be modified from "link two" to "link #2". |
| PASS | A graph caption with text shall be added. |
| PASS | After the modifications have been completed the graph shall be saved. |
| PASS | After the modifications have been completed the graph shall be printed |
| PASS | Exit from BDE shall be successful with the graph saved |
| PASS | The text block (XB) for node 2, node 3, and link 1 and 3 shall be the same as in the previous bdesym.dat file |
| PASS | The text block (XB) for node 1 shall be changed |
| PASS | A new symbol entry should be placed in the SY table for the string "uno". |
| FAIL | A new symbol entry should be present in the SY table for the string "2". |
| FAIL | This row should have a prefix-space count of 0 since there are no spaces between # and 2. |
| FAIL | The literal "#" should be encoded into the SY foreign key. This row should also have prefix space count of 4. |
The majority of test conditions in this first section
were marked with PASS because the test condition was met during
execution of BDE. A core dump occurred during the attempt to print
the graph created.
Many of the inspections of the .dat file in Part
3 were marked with N/A since these requirements will not be seen
until Build 2.
The testing of this build will complete the requirements noted in the PDR of sections 2.3, 3.0, 3.1, 3.2, and 3.3.
The following are some some design improvements :
Update CHGEN so that the replacement routines are automatically generated by CHGEN.
Fix the BDESYM bugs that are noted as failures in the test results.
Caption Text is not currently stored in the symbol and token type tables (SY and TK). Update the BDE source code so that caption text is placed in these tables.
Text processing for links is not correct for example "link #2" is being processed as 1 symbol instead of 2 symbols and 1 literal.
The following are some improvements that build :
Update the makefile so that when the SYMTXT code is modified in the /text directory the BDE executable is re-made.
Update the makefile so that the 94sbde_schema.h is placed in the /include directory and not need to be kept in two places.
The following are locations where the latest source code, documentation, and other data is being kept for the 1996 Spring BDESYM project is kept.
The 1996 Spring BDESYM team source code changes included
fixes to CHGEN as well as modifications to the BDE source code
located in the /src directory.
/usr/proj3/case/96s523/bdesym/base/chgen10/src
/usr/proj3/case/96s523/bdesym/base/src
/usr/proj3/case/96s523/bdesym/base/schema
/usr/proj3/case/96s523/bdesym/base/text
/usr/proj3/case/96s523/bdesym/base/macro_changes
The following documentation has been completed for
the 1996 S BDESYM project.
/usr/proj3/case/96s523/bdesym/base/doc/
/usr/proj3/case/96s523/bdesym/base/doc/text_only
/usr/proj3/case/96s523/bdesym/base/doc/idraw
/usr/proj3/case/96s523/bdesym/lechner
/usr/proj3/case/96s523/bdesym/base/test
[Molloy] Molloy, John and Husssainee, Kehkashan, SYMTXT-Final Report, 1/18/94, remus:/usr/u/factmp/lechner/93f523/93fsym/base/doc/symtxt_doc.txt.
[Mkayed] Mkayed, Rim and Das, Sanat, Final Report Software Engineering 94f523 BDESYM & CHGEN Team, 2/28/96 [sic], /usr/proj3/case/94f523/94fbde/rmkayed/report/94fbdesym.ps.
[Tong] Tong, Duc, Islam, Sahibul and Chiou, Shao-Fong, Final Report Software Engineering 94s523 BDESYM Team, 5/19/94, remus:/usr/u/factmp/lechner/94s523/94ssym/base/doc/94ssymFinalReport.ps.gz.
[Wang] Wang, Chien-Yuan, Ko, Ching-Chih, Chen, Ke-Chiang
and Wu, Chih-Yung. CHGEN User's Manual Version 10, 5/15/95,
/usr/proj3/case/95s523/genv10/base/doc/gen10_manual.ps.