Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

C Header Files Generated from Functional Specification

IP.com Disclosure Number: IPCOM000105180D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 133K

Publishing Venue

IBM

Related People

Stucka, SE: AUTHOR

Abstract

This article discloses a method of automatically generating C language header files from functional specifications. Application Programming Interfaces (APIs) and their associated data type definitions are described in detail in a functional specification, but they must also be defined as subroutine prototypes and data type definitions in C header files. Typically, this information is either entered twice, or the functional specification is manually copied and edited to obtain the header file. However, if the functional specification is written using a consistent documentation style to describe the APIs, a program can generate the C language header files for these APIs.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 39% of the total text.

C Header Files Generated from Functional Specification

      This article discloses a method of automatically generating C
language header files from functional specifications.  Application
Programming Interfaces (APIs) and their associated data type
definitions are described in detail in a functional specification,
but they must also be defined as subroutine prototypes and data type
definitions in C header files.  Typically, this information is either
entered twice, or the functional specification is manually copied and
edited to obtain the header file.  However, if the functional
specification is written using a consistent documentation style to
describe the APIs, a program can generate the C language header files
for these APIs.

      Programming groups have a wide latitude in defining the
documentation style for their functional specifications.  Larger
software project typically enforce stricter documentation standards.
Usually, these standards focus on readability, consistency, and
completeness.  By including a couple of additional items in their
style guidelines, they can use their documentation to generate
program code.

      One style has a functional component's documentation split into
several files.  The <xxx>-API the API information needed for the
functional component.  (The symbols <xxx> are the mnemonic for the
functional component.)  Each file also has a defined section order to
maintain consistency among components.

      The final style requirement has the writers surround the code
fragments in the specification by formatting tags.  These tags are
used to identify sections of the specification that are to be printed
with a different font so that they appear significantly different
than the rest of the document.  However, these tags could also be
used to identify which sections are to be treated as code.  In the
IBM BookMaster program product, the example tags (:xmp.  and :exmp.)
would be used for this purpose.

      With only these documentation style requirements, the HEADER
Program was written to automatically generate C header files from the
functional specification for a large software development project.
Although it uses IBM program products, it is only one implementation;
there are many other possible implementations using other techniques
or programs.  It uses the IBM program products REXX, XEDIT, and
BookMaster to:

* Locate formatting tags in the functional specification,
* Copy sections of the function specification to working file,
* Convert text into block comments,
* Format the working file into a C header.

The HEADER Program uses a series of REXX commands written as XEDIT
macros.  The XEDIT editor was used primarily because it was designed
for the searching, extracting, and changing tasks that would be used
extensively.  The header is generated through the following steps:

1.  HEXTRACT XEDIT Macro

   This macro locates the needed text in the input documentation file
  ...