An Open Call for DERs

When certification documentation for actual deployable
airborne software becomes available, the assistance of a DER would
be very welcome. The idea would be for the documentation to be
pre-inspected,
so that 8110 forms could be signed on demand later for a fixed
fee.
Imagine your name here:

Do178Builder Developer Information

There are plenty of things that could be achieved by additional
software
developers
for Do178Builder. Write
me an email, and I'll make some suggestions. Speaking for myself,
Do178Builder works well
enough, so in spite of having a fairly large wish-list I don't
feel very inclined to spend a lot more effort on it. But if you
want to email
me bug reports, suggestions, or code patches, I would certainly be
grateful for them.

On the off-chance that somebody wants to wade through the
Do178Builder
code, here is a brief explanation of how it works. Fortunately,
it's
pretty simple.

I've grown tired of non-portable software, so I insist that
Do178Builder
work under both *NIX or MS-Windows. (When I wrote the previous
line, I personally was using
SuSE Linux on an iMac, which was then based on the PowerPC
processor. I
read an editorial in EETimes a couple of days after writing the line,
which made it clear that
nobody does this kind of thing. Then I felt shame.) To
accomplish
this level of portability, the wxWindows
graphical toolkit is used to
create
the user interface. Other than the GUI, portability is achieved
by
using the GNU gcc compiler,
which is available on a large
number
of computer platforms.

The wxWindows
toolkit itself
is available not only for MS-Windows and for *NIX (with either GTK+ or
Motif), but also for Mac OS. (Since this was written, "wxWindows"
has changed its name to "wxWidgets". But I'm not going to waste
time rewriting my website for that.) Unfortunately, the Mac OS
version
requires
the non-free (and non-cheap, relative to my interest in it) Metrowerks
Code Warrior compiler rather than gcc,
and hence I have not as
yet
produced a Mac OS version of Do178Builder.
If/when wxWindows
works
with gccon Mac OS, or
when it can be compiled with inexpensive
versions of Code Warrior, perhaps I will create a Mac OS version.
If someone would like to do this and send
it to me, I'll be glad to post it here.

Disclaimer

I guess I should admit that this is the
first
non-trivial GUI project for which I've tried to use wxWindows, and it
definitely
has some rough edges to it. The main problem is that new major
versions of wxWindows tend to
break compatibility with earlier versions, so people complain to me
that my program doesn't compile. But my other (non-portable) GUI
projects
with Borland C++Builder weren't that great either. Perhaps GUI
isn't my cup of
tea. But, that's life. Do178Builder
is free. It's
a learning experience. What can I say? If Do178Builder
turns
out to be useful for you, learn to look past the rough edges.

All other things being equal, I would prefer to use only free
tools for this project. However, for the sake of expedience, I've
used the non-free (though inexpensive) wxDesigner
tools for building the user interface. The wxDesigner data is
stored
in the file Do178Builder.wdr. But unless changes to the user
interface
are contemplated, it's not necessary to have either wxDesigner or
Do178Builder.wdr,
because wxDesigner generates
C++ code which can later be compiled with
gcc
and linked to wxWindows,
whether or not wxDesigner
itself is available. Important
update: With some Do178Builder
versions from 2005-06-21 and later, it was
necessary to manually add code to one of the files that was
originally auto-generated by wxDesigner;
therefore, it wasn't possible to use wxDesigner,
because its automatic
code-generation would overwrite these changes. Fortunately, I
seem to have fixed this problem somehow, and thus using wxDesigner is no longer a problem.

The result is a pretty run-of-the-mill event-driven program, much as
one would see in Delphi, C++Builder, or with the GTK+ toolkit.
Interacting
with the user interface -- for example, clicking buttons with the mouse
-- causes "events" which activate callback functions. Thus, after
designing the user interface with wxDesigner,
it's necessary merely to
provide the proper callback functions to respond to events.

Source files

wxDesigner
completely generates all C++
source
code relevant to the GUI dialogs as the files Do178Builder_wdr.h and
Do178Builder_wdr.cpp.
These files should never be manually changed, since any changes will be
overwritten if wxDesigner is
used later to regenerate GUI code from the
RAD environment. wxDesigner
also partly creates the source files
Do178Builder.h and Do178Builder.cpp, in the sense that it creates
prototypes
and stubs for new GUI objects in these files. However, the stub
functions
are then manually edited to create the callback functions for the
user-interface
events. Thus, quite a lot of user-interface code appears in
Do178Builder.cpp.
wxDesigner does not
later overwrite this manually-created code.

The rationale for creating GUI dialogs with wxWindows generally
results
in creation of a C++ class for each type of dialog. To simplify
the
appearance of the code somewhat, I've separated code for some of the
more-complex
dialog classes from Do178Builder.cpp (where initially placed by
wxDesigner)
into their own source files. Thus, we have the files
XmlEditorDialogClass.cpp
and SearchBoxClass.cpp. The former is the main editing screen;
the
latter is for initiating text searches.

Finally, LoadXmlFile.cpp contains basically all of the non-GUI
related
code. Specifically, it contains the code for loading and saving
the
development data XML project files, and for writing DocBook SGML files

Concerning XML

While Do178Builder
definitely stores
its
project data in XML files, I freely admit to being an XML
neophyte, and to have very little interest in advancing beyond that
point.
Even the little experience I've gained makes me realize that anyone
with
actual XML knowledge will look with disdain on my XML. Too bad;
it
works; it's too much trouble to change. Here are some basic
points
that will make it somewhat easier to understand:

I've discovered somewhat belatedly (over 6 years after I started
the project), that the Do178Builder
XML project databases are not actually legal XML, although many
XML-enabled editors are insensitive to the problems and so you don't
really have to confront them unless using a standards-compliant XML
processor such as libxml.
There are at least two problems with the "XML":

Do178Builder sometimes
embeds character entities such as "&#44;" in the names of
tags. However, legal tag names cannot contain the characters
'&', '#', or ';'.

Do178Builder allows tag
names to begin with a digit, which is not legal.

When I need to convert a Do178Builder
XML database to a legal XML file, what I do is to replace all strings
"&#NN;" (where NN is a decimal number) by "_rNNr_", and all strings
"<N" or "</N" by "_N_" or "/_N_". This can be done with the
sed program, which is
always available in *NIX systems, or can be installed for Windows
systems. A command for accomplishing the conversion is:

This conversion is completely reversable, except in the
unlikely case that your file really contains strings like "_rNNr_",
"<_N_", or "</_N_", using similar types of sed commands.

There's no DTD. There is a file (hidden, if you're using
*NIX)
called
".template.xml" that is a fully-fleshed out project file except that
there's
no non-trivial data in it. It serves the purpose of a DTD.

Each project XML file is completely self-contained, except for
graphic
images. In other words, it contains all of the information from
.template.xml
(except that which has been deliberately deleted by the user), and
hence
does not require the presence of .template.xml (or consistency with
.template.xml)
to be read at a later time.

In fact, .template.xml is really needed merely for determining
the
validity
of insertion or deletion of items to the database.

For DO-254 projects, the file .template254.xml is used in place
of .template.xml.

The project data is arranged in hierarchical outline format, in
which
item
has a parent and (possibly) children, which may themselves have
children,
and so forth. Obviously, this is precisely suitable for
XML.
I use the titles of the outline items as XML tags for them, with all
spaces
replaced by underlines, and non-alphanumeric characters replaced by
suitable
escape sequences. These titles are editable by the user, and so
each
tag has a TYPE attribute that cannot be edited, but which to which the
titles default. In hindsight, this is a foolish scheme, and the
roles
of the tags and TYPE attributes should have been reversed. Too
bad.

Additional attributes for the tags are the HINT, the applicable
DO-178B
documents (PSAC, SAS, etc., all defaulting to "NO"), and the control
categories
BA, BB, BC, BD, and BE. As with the tags, all whitespace in these
is replaced by underlines, and escape sequences replace various
characters
(such as '<'). There is no necessity for eliminating the
whitespace
in this way, but it made parsing the XML file a little easier.

At this writing, the DTD is still being tuned. (I speak of the
"DTD"
figuratively, of course, since there isn't one.) The easiest way
to edit the DTD is to load .template.xml itself as a project file into
Do178Builder. Under the Do178Builder main menu, the
Options/ModifyFramework
function should be chosen. Now when the dataset (.template.xml)
is
edited, it is possible to edit the variout attributes as well as the
XML
tags and data. Specifically, the hint, the applicable documents,
and the control categories become editable. Furthermore, new
outline
items and sub-items can be added at will.

All of this, of course, can render the new .template.xml
incompatible
with existing project data. This is not really a problem until
one
wishes to insert new data items into a project dataset, because the
incompatibilities
that have been introduced may make this impossible. The most
insidious
incompatibility that can be introduced is modification of the TYPE
attribute.
As mentioned above, each data item has an title (the XML tag name) and
a TYPE attribute; these are initially the same, until the user edits
the
data-item's title. The TYPE attribute, however, is not similarly
changed, and can therefore continues to correspond to what appears in
.template.xml
even though the title (tag name) does not.

But that's only if the Options/ModifyFramework function
isn't
being used. If Options/ModifyFramework is used, then Do178Builder
can change the TYPE attribute of an item when the item's title is
changed.
In fact, Do178Builder prompts
to see if this should be done.
Generally,
to achieve what you're trying to achieve in editing the framework, the
TYPE attribute should be changed when the title is
changed.
But one needs to be aware that this modification of the TYPE attribute
is the primary mechanism by which new DTDs become incompatible with old
datasets.

This page was last modified by Ron Burkey on
2008-03-16..
Contact birds
.