ClassMaker Software Requirement Specification - Le Gomage

Software Requirements Specification

ClassMaker


Le Gomage

LeGomage

ClassMaker Software Requirement Specification Table of Contents Section Heading Page 1 INTRODUCTION 1 1.1 Purpose............................................................................................................................ 1 1.2 Scope............................................................................................................................... 1 1.3 Definitions and Acronyms .............................................................................................. 2 1.4 Overview of the Contents of Document ......................................................................... 3 2 GENERAL DESCRIPTION 4 2.1 The Need......................................................................................................................... 4 2.2 Product Perspective......................................................................................................... 4 2.3 Compiling and Running the Software............................................................................. 5 2.3.1 Unix Systems .......................................................................................................... 5 2.3.2 Other Systems ......................................................................................................... 5 2.4 General Constraints......................................................................................................... 5 2.5 Assumptions and Dependencies ..................................................................................... 5 3 CODING CONVENTIONS 6 3.1.1 Coding Conventions Style ...................................................................................... 6 3.1.2 Variable Naming Conventions................................................................................ 6 3.1.3 Header File Conventions......................................................................................... 8 3.2 Function Conventions ................................................................................................... 12 3.3 Class Conventions......................................................................................................... 14 3.4 NUAN principle............................................................................................................ 16 3.5 Superiority of the Whittalian Structure......................................................................... 16 3.5.1 Effective Multiple Inheritance .............................................................................. 17 3.5.2 Forward Compatibility.......................................................................................... 20 3.5.3 Reliable Maintenance............................................................................................ 24 4 SPECIFIC REQUIREMENTS 26 4.1 Functional Specifications.............................................................................................. 26 4.1.1 AsString ................................................................................................................ 27 4.1.2 Binary IO .............................................................................................................. 27 4.1.3 Encrypter............................................................................................................... 27 4.1.4 OaMotFayc ........................................................................................................... 27 4.1.5 XML IO ................................................................................................................ 27 4.1.6 mysql IO................................................................................................................ 28 4.1.7 SqlList ................................................................................................................... 28 4.1.8 Comparator ........................................................................................................... 28 Software Requirements Specification

Le Gomage

4.1.9 Tester..................................................................................................................... 28 4.1.10 Clone ..................................................................................................................... 28 4.1.11 Commander........................................................................................................... 29 4.1.12 Data Return ........................................................................................................... 29 4.1.13 Objectified............................................................................................................. 29 4.1.14 Text CRUD ........................................................................................................... 29 4.1.15 GUI CRUD ........................................................................................................... 29 4.1.16 Web CRUD........................................................................................................... 30 4.2 Design Constraints ........................................................................................................ 30 4.2.1 Current Progress.................................................................................................... 30 4.2.2 Hardware Limitations ........................................................................................... 30 4.3 Quality Attributes.......................................................................................................... 31 4.3.1 Language............................................................................................................... 31 4.3.2 Operational Quality Attributes.............................................................................. 31 Appendix A 1


Le Gomage

1

INTRODUCTION

This is the Software Requirements Specification document for the ClassMaker project. This document is intended to be read by software developers interested in expanding the software and doubles as a résumé. This document contains information current as of Friday, May 18, 2007 as to the progress of the software.

1.1 Purpose The purpose of this document is to define the requirements needed for the proposed system along with the assumptions, constraints and dependencies for the design. Each requirement has been broken down into steps to aid in defining exactly what each requirement must do. The Software Requirements Specifications will be used by the designers and implementers, to provide a better understanding of how Le Gomage is planning to handle each requirement and what assumptions, constraints and dependencies are expected during the design.

The Software Requirements

Specification also serves as a baseline for designing and testing the proposed software once it has been completed. This document is essentially a checklist to verify that each requirement has been met. 1.2 Scope This document is not intended to describe the details of how the software will be implemented. Rather, this document is intended to specify the essential requirements of the software and its external interfaces. The Software Requirements Specification begins by providing a general description of the users and the features that the product will provide. The detailed specifications of each requirement are also provided. This document contains all the technical information and data needed to design the software.


Le Gomage 1

1.3

Definitions and Acronyms

Following are the definitions of acronyms, abbreviations and other terms or words that are used in this document. Definitions Bass Class Extension Class

The class which the ClassMaker application creates. A class that inherits from the Bass Class


Le Gomage 2

Acronyms SRS XML GUI CRUD NUAN OaMotFayc IO

Software Requirement Specification (This document) Extended Markup Language Graphical User Interface Create, Review, Update, Delete Never Use A Number Open As Much Of The File As You Can Input / Output

1.4 Overview of the Contents of Document Section 2 General Description: This section defines how the proposed system will be designed to be incorporated into the sponsor’s current environment and the interfaces required with the existing system. Section 2 will also contain use case diagrams that will depict user and external systems interaction with the proposed software. Assumptions, constraints and dependencies will also be listed and described in this section.

Section 3 Coding Conventions: This section contains a description of the Whittalian Coding Conventions in which Le Gomage code should be written. Section 4 Specific Requirements: This section will contain detailed information about each of the requirements that the software must fulfill.

Appendix A Data Dictionary: Appendix A includes the specifications for the database that will be used for this proposed software.


Le Gomage 3

2

GENERAL DESCRIPTION

This section contains a general overview of the requirements of the proposed system. Included in this section are use case diagrams that depict user and external systems interaction with the proposed software. Assumptions, constraints and dependencies are listed and described in this section. 2.1

The Need

The largest amount of money spent on code is spent on maintaining it. The whole ObjectOriented structure was designed to make code more maintainable. The other problem that code has is that it goes out of date. Languages change, header files are modified, and old code stops compiling. Testing code is also time-consuming and expensive, especially when code written today causes code written in the past stop working.

2.2

Product Perspective

The purpose of this ClassMaker software is to write pre-tested code. The software inputs a standard C++ header file and automatically generates the code to save, load, create, review, update, and delete, along with interfacing with mysql databases, XML file formats, and binary formats, as well as providing a text interface, a GUI, and a web interface. The code that is created needs not be tested, will not become old so long as the C++ header files remain the same, and won't stop working because of code not yet written.


Le Gomage 4

2.3

Compiling and Running the Software

This section contains installation instructions. 2.3.1

Unix Systems

If on a Unix system, execute the makefile. 2.3.2 •

Other Systems If not on a Unix system, compile the ClassMaker.cpp and ClassMaker.h files. When you run the executable, it will look for a file named “input.txt” and generate the corresponding files in the directory named “output.” This file and directory must have the same path as the executable.

•

Inside the “output” directory, compile all the files generated by the executable. This currently will run the TextCRUD application.

2.4 General Constraints Following, are a list of constraints that limit Le Gomage’s options in designing ClassMaker: •

ClassMaker must work on Unix, Macintosh and Windows platforms.

•

ClassMaker must not use any copyrighted libraries or copyrighted source code

2.5 Assumptions and Dependencies All assumptions and dependencies that Le Gomage expects are listed below. If any one item from the list were not available, the SRS document would have to be changed. Assumptions: •

For the GUI, that the newer versions of the respective operating systems will be backwards compatible

Dependencies: •

C++ header files do not change.


Le Gomage 5

3 CODING CONVENTIONS ClassMaker follows the Whittalian Coding Conventions. These conventions cover style, principles, and function and inheritance conventions. 3.1.1 Coding Conventions Style We expect the reader to already have a firm understanding of the C++ notions of variables, functions, classes, inheritance, multiple inheritance, polymorphism, object-oriented goals, and the keywords const, virtual, and friend. 3.1.2

Variable Naming Conventions

Whittalian Code uses Camel Case The first letter of every word is capitalized. The first letter of the first word is capitalized. example: theInformationReceievedFromTheWindow Variables begin with a wart which is always a lowercase letter Member variables begin with a lowercase 'm' (standing for member) example: class BAnimatedGif { long mNumberOfFrames; Function input variables begin with a lowercase 'in' example: void SetValue(long inValue); Function output variables begin with a lowercase 'out' example: void DoPutClassDataInThisString(std::string &outString); Function input/output variables begin with a lowercase 'io' example: void DoMakeThisStringAllCapitals(std::string &ioString);

local variables begin with a lowercase 'the' example: theInformationReceievedFromTheWindow void SetThisStringToCapitals(std::string &ioString) Software Requirements Specification

Le Gomage 6

{ long theNumberOfLetters;

global variables begin with a 'g' (standing for global) example: TApplicationState gApplicationState;

typedefs begin with an uppercase 'T' (standing for Typedef) Variable types begin with uppercase letters example: typedef TVoidPtr void *

Classes / Structs begin with an uppercase B, I, or L (standing for Block, Interface, or Linked, respectively) example: class BAnimatedGif { ... class IAnimatedGif { ... class LAnimatedGif {

Functions begin with an uppercase letter example: void DoBeginMainLoop();

Functions that cause errors should begin with a lowercase 'e' example: Software Requirements Specification

Le Gomage 7

long eAttemptToChangeResolution(long inX, long inY);

Other #define's are all caps. If it needs to have more than one word, use an underscore example: #define SCREEN theApplication->mResManager->mWindow #define SCREEN_SIZE atoi(*((std::string *)(thePointer)))

constants and enums begin with a lowercase 'k' (standing for [k]onstant) example: theInformationReceievedFromTheWindow

boolean variables should contain a true/false statement example: bool mWeCanFitAnotherObject

3.1.3

Header File Conventions

Items in Header Files should appear in this order:

1) File Header and Footer: A #ifndef headerDefine as the top line. A #define headerDefine as the second line. A #endif //headerDefine as the last line. The headerDefine should be the Header File Name with the text "HeaderFile" tacked on the end. example: In the file "BlockSprites.h" the code would be #ifndef BlockSpritesHeaderFile Software Requirements Specification

Le Gomage 8

#define BlockSpritesHeaderFile ... #endif //BlockSpritesHeaderFile

2)

#includes come next.

Include system includes first. Separate them with a blank line. example: #include #include

#include "MyMultiSprite.h" #include "ClassMaker.h"

3)

globals should not be used.

They are usually not thread safe, they introduce poor cohesion, and they allow easily for the code which uses the global variables to crash because of code to be written in the future. But, if you must, include them here. example: int gError;

3)

#defines should be kept to a minimum.

#defines have no typechecking and so should not be used as a replacement for numbers. This is the function of consts. They should only be used to make the code more readable.

4)

consts should begin with a lowercase k

5)

typedefs should begin with an uppercase 'T' with the exception of defining an interface.

(see below) Software Requirements Specification

Le Gomage 9

6)

enums should also begin with a lowercase k and be given a name when applicable. An

enum name should begin with an uppercase T. It is preferred to have the name of the enum appended to the end of the enumerated types. example: enum TApplicationState { kInitializingApplicationState = 0, kMainLoopApplicationState, kExitingApplicationState, kMaxApplicationStates }

7)

classes / structs should begin with an uppercase B (standing for Block), an uppercase

'Definition', with a typedefed 'Definition *' to an I (standing for Interface), or and uppercase L (standing for Linked). Block classes are classes with no virtual functions. These are important to single out because they are easily optimized. If you need to use virtual functions, these functions should be declared in a separate virtual Interface class. Then they should be linked to the Blocked class in a third class known as the Linked class. The order of appearance of elements in the class is as follows: private member variables, protected member variables, public member variables, private functions, protected funtions, public functions, inner classes. The variables and functions should be separated by a blank line. example: class BMenuItem { private: long mIndex; protected: long mCommandKey; public: Software Requirements Specification

Le Gomage 10

std::string mName;

private: void DoSelect(); protected: void GetCommandStatus(TStatus &outStatus); public: void SetName(std::string inName); }; class DefinitionMenuItem { virtual void SetName(std::string inName) = 0; }; typedef IMenuItem DefinitionMenuItem*; class LMenuItem: public DefinitionMenuItem { BMenuItem *mMenuItem; void SetName(std::string inName) {mMenuItem->SetName(inName)}; void SetClass(BMenuItem &inClass) {mMenuItem = &inClass}; } The reason why the virtual functions are separated off of the Block class is twofold. First, Blocked classes can then easily be optimized. Second, if a class has four virtual functions, and we have a collection of 10,000 of these items, we have 10,000 items * 4 virtual functions per item * 4 bytes per virtual function = 160,000 wasted bytes. This eats up RAM and slows down the application because of increased paging. The solution is to store a collection of optimized Block objects, then, when needing to use a virtual function, create one instance of the interface and attach it to each element in the collection. example: This code sets every menu item's name to "default" BMenuITem theMenuItems[10000]; Software Requirements Specification

Le Gomage 11

LMenuItem theMenuItemInterface; for (int i = 0; i < 10000; i++) { theMenuItemInterface.SetClass(theMenuItems[i]); theMenuItemInterface->SetName("default"); }

8)

Non-class function prototypes should come next. These also are poorly cohesive and

should be minimized.

3.2

Function Conventions Functions should begin either with a 'Do', a 'GO', a 'Set' or a 'Get'. 'Do' functions should

perform one simple task. 'Go' functions should execute a list of 'Do' and 'Go' functions. 'Set' functions should do a simple mutation. 'Get' functions should perform as accessors which do not modify the class data. 'Do' and 'Go' functions ideally should take no inputs. Ideally, 'Get' functions should return data inline if possible, but always via a reference. example: void DoSendErrorToCout() { std::cout Grow();

//Send the Modern object back to the old code CalculateAndStore(theModern);

In the Whittalian code, the programmer can effectively call the new ‘Grow’ function on the instance of a old ‘Ancient’ object, right where it is in memory.

Of course, one could always argue that the best solution is to modify the ‘Ancient’ class and add the ‘Grow’ function and needed member variables to that class. However, this idea of modifying an old class to extend new functionality turns into a maintenance nightmare. A better way of maintaining old code is discussed in the upcoming section.


Le Gomage 23

3.5.3

Reliable Maintenance.

There is good code, and there is bad code. How does one know if their code is good?

1

Good code has been tested with bad inputs.

All code works when the inputs are good. Bad code crashes when the inputs are wrong. Yes, this means the majority of the C style functions in stdlib.h are bad code.

2

Good code has been tested with functionality checks.

Given a set of inputs, does the code reliably generate the correct output? This should seem obvious. It is. Code should do what it was intended to do.

3

Good code has been tested in different environments.

A typical saying of a writer of bad code is this: “Well, it worked on my machine.” Good code does not just work on one machine.

4

Good code has been tested for readability, optimizations, documentation, execution speed,

redundancy and code size.

These are just a few of the goals of some companies. To the degree which the manager desires them, good code reflects the desires of the manager.

5

Good code has been tested for maintainability.

This one is becoming increasingly more important. Testing code for maintainability is rather difficult. A test for maintainability is in essence a testing of the code against code which is not yet written. The heart of the matter is here: It is not possible for someone to write bad code which crashes good code.


Le Gomage 24

Take this example. Lets say in a program, the programmer has created a global variable holding a pointer to all the important data. Every function written uses that pointer and never checks if it is still valid. Then, another programmer, while writing a function, inadvertently sets that pointer to null. What happens? The program crashes. Why? Because the program was not written in a good, maintainable fashion from the start.

What then, does Whittalian code do which makes maintainability reliable? Those who study computer theory will tell you that the more modular code is, the more maintainable it is. This means the less files in the list of #includes, the better. Why? Because if one of those files in that list of #includes changes, the code which contains that list has to be recompiled, and the possibility of an unwanted side effects increases.

When constructing a Whittalian class, the block class never needs to include another block class. Extended block classes do. But not block classes. Nor do they include link classes. Block classes do include interfaces. Also, interfaces only include other interfaces. There is a wealth of information in that last paragraph. Note that the only thing that ever gets included in the majority of the source code are interfaces. What is so important about that? Interfaces have no code, so they are very unlikely to change. And if an interface does need to be changed, perhaps extended, writing a new interface is a far better solution than changing the old one, especially given the simplicity of writing an interface. So if the code you include rarely changes, the code is modular. Which means it is maintainable. Which means it is good.


Le Gomage 25

4 SPECIFIC REQUIREMENTS This section will contain detailed information about the implementation of the system described in section 2. Any design constraints that are foreseen and the quality attributes that are part of the non-functional requirements are also included. 4.1 Functional Specifications The following is the list of extension classes that ClassMaker generates. AsString, Binary IO, Encryption, OaMotFayc, XML IO, mysql IO, SqlList, Comparator, Tester, Clone, Commander, Data Return, Objectified, TextCRUD, GUI CRUD, Web CRUD


Le Gomage 26

4.1.1

AsString

The AsString Extension Class is designed to return a std::string which contains a textual representation of the data inside the class being created. The reason for such a class is to allow the programmer to easily display the inner data of the class (ie. on cout) for debugging purposes. 4.1.2

Binary IO

The BinaryIO Extension Class is designed to transfer the class in a binary manner to streams. The reason for such a class is to allow the programmer to easily save and load the class to and from binary files. 4.1.3

Encrypter

The Encrypter Extension Class is designed to create a custom, random encrypter for just this class. The reason for such a class is to protect the data from being tampered with as it sits as a file on the hard drive or is transmitted over the internet. The custom, random encrypter ensures the security of the encryption. 4.1.4

OaMotFayc

OamOtFayc stands for "Open as much of the file as you can." The OamOtFayc Extension Class is designed to save files in a format that one can open as much of these files as possible, even if they have been corrupted by data loss. The reason for such a class is to protect the user from the following scenario. The user creates a file, spends countless hours filling it with data, and one day, there is a write error, and although 99% of the file is good, because one thing went bad, the file is corrupt and unopenable. Allowing the users the option to open as much of the file as they can saves hours of time when problems like that occur. 4.1.5

XML IO

The XMLIO Extension Class is designed to save and load the class to and from XML files. The purpose of this class is to allow the class to be displayed by XML parsers and to interface with other applications which understand the XML format. Software Requirements Specification

Le Gomage 27

4.1.6

mysql IO

The mysqlIO Extension Class is designed to save and load the class to a mysql database. The purpose of this class is to allow the class to be stored in web-based databases. 4.1.7

SqlList

The SqlList Extention Class is designed to allow the user to perform standard database functions on a collection of objects of the class. These functions include create, review, update, delete, find, select, sort, and divide. The purpose of this class is to promote client-side processing. For example, if one hundred computers were connected to one server, and the server had to do all the processing, the client computers would have to wait for the server to do its job. But, if the clients did the processing, then there is less of a bottleneck and things can run faster. 4.1.8

Comparator

The Comparator Extension Class is designed to compare one object to another. The Comparator class allows the programmer to choose on which variable to compare. The purpose of this class is to allow the programmer to compare two objects to see which one is greater. It is essential for sorting. 4.1.9

Tester

The Tester Extension Class is designed to test to see if the object is a valid pointer. The reason for such a class is because invalid non null pointers cannot be identified at initialization time. The error shows up during runtime. Errors are easier to identify and fix at initialization time. 4.1.10 Clone The Clone Extension Class is designed to return a copy of the object. The reason for this class is to allow the programmer to make a copy of the object without knowing the type of class that it is. This is useful when the programmer has a list of interfaces and needs to make a copy of one of the objects to which the programmer has an interface, but doesn't know the type of class that it is. Software Requirements Specification

Le Gomage 28

4.1.11 Commander The Commander Extension Class is designed to allow the programmer to give the object a list of commands in the form of programmable memory. The reason for such a class is to allow user programmable actions. Similar to Photoshop that allows the user to record a list of commonly repeated actions in order to speed up the process, the Commander class contains the necessary code to implement this type of strategy. 4.1.12 Data Return The DataReturn Extension Class is designed to return its inner data via a command in the form of programmable memory. The reason for this class is to assist the Commander Extension Class in performing its job. 4.1.13 Objectified The Objectified Extension Class is designed to conform the class to Whittalian Functional Coding Standards. The reason for this class is mostly for dealing with user interfaces. Imagine filling out a form and clicking the OK button If the OK button had to have the code for all the fields, parse them, and gather all the data, the OK button would fail its job should the interface change. However, if each field knew to set the appropriate variable in the class, the OK button would only have to send the data, and thus the form could be changed without the code that has already been tested needing modification. That is the key. Don't modify tested code that works. 4.1.14 Text CRUD The TextCRUD Class is designed to allow the user to Create, Review, Update and Delete from a list of the specified class using a text, command-line interface. 4.1.15 GUI CRUD The TextCRUD Class is designed to allow the user to Create, Review, Update and Delete from a list of the specified class using a GUI interface.


Le Gomage 29

4.1.16 Web CRUD The TextCRUD Class is designed to allow the user to Create, Review, Update and Delete from a list of the specified class using a web interface.

4.2

Design Constraints

Details of the design constraints are determined by the current standards and hardware limitations.

4.2.1 Current Progress The following is the progress that ClassMaker has made. AsString

completed

Binary IO

completed

Encryption

not begun

OaMotFayc

not begun

XML IO

in progress, 10%

mysql IO

in progress 10%

SqlList

in progress 60%

Comparator

completed

Tester

completed

Clone

in progress 30%

Commander

in progress 50%

Data Return

completed

Objectified

not begun

TextCRUD

in progress, 40% waiting for the above to become completed

GUI CRUD

not begun

Web CRUD

not begun

4.2.2

Hardware Limitations

Le Gomage has not received any unordinary hardware limitations. Any computer that can run compile c++ should be able to compile all the code and execute the TextCRUD. A GUI is Software Requirements Specification

Le Gomage 30

needed to run the GUI CRUD application. A web browser is needed to run the Web CRUD. The software should, however, follow reasonable hardware standards, such as:

the entire

finished product should fit on no more than one CD, ands the program should not require more than 64 MB RAM to run.

4.3

Quality Attributes

This subsection contains the non-functional requirements. These are requirements that apply to the software system being developed and not just to a single function or use. 4.3.1 Language The entire project will be in English only. 4.3.2

Operational Quality Attributes

•

Text CRUD will follow standard Unix conventions.

•

GUI and Web screen layouts will follow Macintosh's User Interface Guidelines.

•

There will be a simple help system available.

•

The GUI and Web screen layouts will be easily readable and very easy to use.


Le Gomage 31

Appendix A Data Dictionary


Le Gomage A-1

Class

Description

mVariableType; mVariableName; mHasAccessor; mHasMutator; mFunctionReturnType; mFunctionName; mFunctionParameters; mIsConst; mEnumName; mEnumValues;

8

Record Size (bytes) 40

8

60

4

56

mFileToOpenForInput; *mInStream; *mOutStream; mCommand;

1

186

Initialization

BVariable

Describes a variable to be created

BClassMaker

BFunction

Describes a function to be created

BClassMaker

BEnum

Describes an BClassMaker Enumerated Type to be created BClassMaker Describes the class to main() be created

Fields

Estimated Records

mClassName; mInheritedClasses; mIncludes; mVariables; mEnums; mFunctions; mHasAList;

Table 1: Data Entities Defined


Le Gomage A-2

BVariable Field Name mVariableType mVariableName mHasAccessor mHasMutator BFunction Field Name mFunctionReturnType

Description The type of the variable (eg. “int”, “long”) The name of the variable, not including any warts Whether this variable should have an accessor function Whether this variable should have a mutator function

Type

Validations

std::string

not null

std::string

not null

bool bool Type std::string

Validations not null

std::string

not null

mIsConst

Description The return type of the function The name of the function, including warts A list of the parameters of the function Whether or not the function in this class is const

BEnum Field Name mEnumName mEnumValues

Description The name of the Enum The values of the Enum

Type std::string std::list

Validations Primary key none

Description The name of the file to parse The file object The file object for the output files The name of the class to be created A list of the classes to be inherited from A list of the header files to include A list of the member variables of the class A list of the Enumerated Types used by the class A list of the member functions of the class A variable indicating whether the class has a member variable which is a collection (i.e. list, map, array)

Type std::string std::ifstream std::ofstream

Validations not null

std::string

not null

mFunctionName mFunctionParameters

BClassMaker Field Name mFileToOpenForInput mInStream mOutStream mClassName mInheritedClasses mIncludes mVariables mEnums mFunctions

mHasAList

std::list bool

std::list std::list std::list std::list std::list

bool

Table 2: Makeup of the Entities


Le Gomage A-3

Data Flow Function

Called by

GoRunClassMaker

main()

GoGenerateOutputFiles

GoRunClassMaker()

Calls

GoGenerateExtensionFile GoGenerateOutputFiles()

DoOpenInputFile(); GoParseInputFile(); GoGenerateOutputFiles(); DoOpenSqlListFile(); GoGenerateSqlListOutputFiles(); GoGenerateBHeaderFile(); GoGenerateBSourceFile(); GoGenerateExtensionFile(); DoCreateExtensionHeaderFile(); DoGenerateExtensionHeaderFileIncludes(); GoGenerateBinaryFileIOHeaderFile(); GoGenerateAsStringHeaderFile(); GoGenerateAsciiFileIOHeaderFile(); GoGenerateSqlFileIOHeaderFile(); GoGenerateXMLFileIOHeaderFile(); GoGenerateComparatorHeaderFile(); GoGenerateTesterHeaderFile(); GoGenerateCloneHeaderFile(); GoGenerateCommanderHeaderFile(); GoGenerateDataReturnHeaderFile(); DoCreateSqlListHeaderFile(); GoGenerateSqlListHeaderFile(); DoCreateExtensionSourceFile(); DoGenerateExtensionSourceFileIncludes(); GoGenerateBinaryFileIOSourceFile(); GoGenerateAsStringSourceFile(); GoGenerateAsciiFileIOSourceFile(); GoGenerateSqlFileIOSourceFile(); GoGenerateXMLFileIOSourceFile(); GoGenerateComparatorSourceFile(); GoGenerateTesterSourceFile(); GoGenerateCloneSourceFile(); GoGenerateDataReturnSourceFile(); GoGenerateCommanderSourceFile(); DoCreateSqlListSourceFile(); GoGenerateSqlListSourceFile(); GoGenerateTextCRUD(); GoGenerateGUICRUD(); GoGenerateWebCRUD();


Le Gomage A-4

GoGenerateTextCRUD

GoGenerateExtensionFile() GoGenerateTextCRUDH_IncludesAndDefines(); GoGenerateTextCRUDH_Classes(); GoGenerateTextCRUDH_Closing(); GoGenerateTextCRUDIncludesAndDefines(); GoGenerateTextCRUDClassFunctions(); GoGenerateTextCRUDH_ListVaraibles(); GoGenerateMainIncludesAndDefines(); GoGenerateTextCRUDGoCRUD(); GoGenerateMainFunction(); GoGenerateTextCRUDCreationCode(); GoGenerateTextCRUDReviewCode(); GoGenerateTextCRUDEditCode(); GoGenerateTextCRUDVariableEditListCode(); GoGenerateTextCRUDUseCode(); GoGenerateTextCRUDUseCodeForThisList(const BVariable &inVaraible); GoGenerateTextCRUDDeleteCode(); GoGenerateTextCRUDSaveCode(); GoGenerateTextCRUDOpenCode(); GoGenerateTextCRUDFindCode(); GoGenerateTextCRUDHelpCode(); GoGenerateTextCRUDVariableCreationCode (BVariable &inVariable); GoGenerateTextCRUDConstructors(); GoGenerateTextCRUDExtraCode(); GoGenerateTextCRUDVariableEditCode (BVariable &inVariable, long inIndex); GoGenerateTextCRUDVariableEditCodeForLists (BVariable &inVariable, long inIndex); GoGenerateTextCRUDVariableDeleteListCode(); GoGenerateCodeToGetTheCurrentList();

Table 3: Data Flow


Le Gomage A-5