OpenGOOP Inheritance Requirements Model

[Jim K. <ji...@ji...>]

Hello All,
=20
I am working hard to get OpenGOOP Inheritance ready for an alpha =
release.
The class template and some prototype class generator/linker tools are
almost finished.  As such, this is a good time to ping the rest of the =
OpenG
developers, since you will probably be the first users of OpenGOOP
Inheritance.  I want to get some feedback from you all on the high-level
requirements for OpenGOOP Inheritance.  Basically, I want to know what =
you
all want out of a "Wizard" -- the tools for automated class generation,
development, maintenance, documentation, etc.  There are two main goals =
that
I am shooting for: (1) programmatic interface to the wizard and (2) make =
the
design modular by utilizing a plug-in framework based on OpenGOOP
Inheritance abstract classes.  Goal #2 won't be realized until later, =
once
the OpenGOOP Inheritance design stabilizes.  Goal #1 is the short-term
focus.  But, before the programmatic interface can be developed, we need =
to
define the features that you all want.  So, take a look at this list an
please feel free to comment.
=20
Regards,
=20
-Jim
=20
=20
OpenGOOP Inheritance Requirements Model
=20
-=3D Constraints =3D-
=20
FR_010 - Utilize OpenGOOP for Classes=20
OpenGOOP Inheritance should use LV2 Globals Called by Reference, as the
individual class data stores.  An inheritance hierarchy is created by
aggregating the instances of the individual classes in the inheritance
hierarchy.  Children will access the data of thier parents through =
special
"core" VIs provided by the parents.
=20
FR_011 - The "core" of the class may be easily upgraded by class =
developers.

The Core of the class are those parts that are not customized by class
developers.  The core does not contain (but may depend upon) VIs or =
TypeDefs
that defines the structure of the class.  The Core is the "glue" that =
holds
the class together.  Replacing the Core of the class (e.g with a newer
version) should be transparent to the class developer.  Also, there may =
be
many types of Cores that are optimized for certain type of performance =
(e.g.
instanciation speed, access speed, data size, etc).
=20
FR_012 - The "Common Core" should be as small as possible, initially.=20
The "Common Core" is the portion of the core that all OpenGOOP =
Inheritance
classes depend upon.  Initially, this should be kept as small as =
possible,
since all classes depend upon it.  Initially Common Core components will =
be
stored in each Class's "Core" folder (and be linked within the classes =
own
namespace).
=20
FR_013 - Wizard should provide plug-in interfaces that are implemented =
by
OpenGOOP Inheritance subclasses.=20
This provides two benefits.  First, it allows us to eat our own dog =
food.
Second, it allows users to create new plug-ins and features of the =
Wizard --
this is of huge importance to the project.  These interfaces should be =
well
documented and templates should be made available.
=20
-=3D Features =3D-
=20
Class Creation:
=20
FR_001 - Classes can be created from other classes (as a copy).
=20
FR_013 - Classes can be created from class meta information.
Classes can be created from class meta information such as class name, =
data
members, methods, etc.; perhaps in an XML file or similar.
=20

Class Deployment:
=20
FR_002 - Classes can be "built" into Apps=20
Classes should be able to be built.  This means that the source may be
consolidated into a single folder (or LLB).
=20
FR_003 - Classes can be "name mangled"=20
Classes can be name mangled with a suffix such that the name appears =
like
*__opengtool.vi

Class Documentation:
=20
FR_006 - Class meta information (documentation) may be exported to file. =


Class Management:
=20
FR_004 - Classes may be renamed=20
Renaming should also take into consideration whether dependant classes =
are
to be relinked to the renamed class.
=20
FR_005 - Classes may be relinked to a new parent class=20

FR_009 - Class "icon banners" may be updated automatically.=20
A VI "icon banner" is often used accross the top of all VIs within a =
class.
This "icon banner" is just a string that represents the class name.

Class Visualization:
=20
FR_007 - Class inheritance hierarchy may be visualized
There should be a way to visualize the relationships between classes in =
an
inheritance hierarchy
=20
FR_008 - Class structure may be visualized.=20
There should be a way to visualize a class's structure.  This should =
show
the various members (public, protected, and private data) and methods.  =
The
visualization tool should group by type (modifier): e.g. public, =
virtual,
etc).