Re: Rational Apex

["Samuel T. Harris" <sam_harris@hso.link.com>]

James Amendolagine wrote:
> 
>      I am trying to learn how to use the rational apex
> environment and am having problems with imports. I am
> trying to import two views from one subsystem into a
> view from another. Apex is complaining and rejecting
> the import of more than wone view. Is there a way to
> import more than one view?
> 
>      Jamie

Each Apex view serve dual roles as a configuration management
collective and Ada compilation library mechanism. An Apex
subsystem is intended to contain related code upon which some
level of component testing can be performed. Configuration
management information is contained within the Apex subsystem.
An Apex view is a "slice" of the subsystem's configuration
management database, selecting at most one version of each
controlled object in the subsystem. A subsystem usually
contains several views. These views usually include different
versions of each controlled object. From this perspective,
a view provides the "configuration" in configuration management.

A view is also an Apex Ada library. In order to compile units
in a view which require (or with) units from another view, some
relationship between the two views must be defined. This is
view imports. From a compilation perspective, an Apex view
is an Ada library.

Putting the two perspectives together, it is natural to limit
view imports to at most one view from each Apex subsystem.
Remember, from the configuration management viewpoint, two
views from the same subsystem are two distinct sets of versions
of common controlled objects. If you are trying to import
two views from the same subsystem which contain the same
objects (albeit with different versions) then you have
a real problem with usage since this makes no sense from
a configuration management perspective.

In my experience, it is a common mistake for Apex neophites
to ignore the configuration management aspects and simply
start off using Apex for the nice language sensitive editor.
In such circumstances, is seems obvious to simply define
an Apex subsystem for each programmer and define a view
for each system component each programmer works on. While
this provides all the Apex Ada libraries you need, mixing
multiple component views in the same subsystem is violating
the underlying princple of Apex subsystems and make this
usage vulnerable to configuration management problems when
it comes time to integrate components together. When this
occurs, multiple views from a single subsystem need to be
imported (because each view has a different component) which
is not allowed by Apex. After this event, substantial Apex
subsystem reorganization occurs resulting in an Apex subsystem
for each component each containing a view for each programmer
working on the component.

If you fall into this category then you will need to reorganize
your subsystems so each contains a single set of code _or_
include all code in all views of a subsystem into each view
of that subsystem (this is not my first choice).

Just as analysis preceeds design which preceeds coding, so
should some thought to configuration management be given
before laying down tools and libraries.

-- 
Samuel T. Harris, Principal Engineer
Raytheon Training Incorporated
"If you can make it, We can fake it!"