Re: Is Apex dead as an environment for Ada & Java?

[reason67@my-deja.com]

In article <1761dd4a.3f28b0f0@usw-ex0101-008.remarq.com>,
  jim_snead <basswoodNObaSPAM@my-deja.com.invalid> wrote:


> These are way too big of chunks for subsystems.

It was an example, not an actual software architecture.

> I would
> say a hierarchy (i.e. individual subsystem) would be examples
> such as the Linux operating system, the source code to GNAT,
> or the Mozilla-Netscape source.  Why on earth would you want
> to apportion these into smaller subsystem chunks?

Loose coupling, division of labor, information hiding, etc. If you limit
these chunks with well defined interfaces (views have the ability to
only export certain specs in them), you can enforce a software
architecture and loose coupling.

> Apparently Apex does allow the mutual importation of subsystems.
> I don't understand, does Apex enforce this policy or doesn't it?
> I have my include paths as an example to rigidly enforce
> such a policy without requiring Apex.

Well, you do not import subsystems, you import views. Apex has a feature
called "mutually importing views." According to a tech rep I asked about
this in 1995, it was a feature added to make a sale to a big company
that wanted to transition legacy Ada 83 to Apex for Ada83. I have worked
in using Rational Apex in 5 companies now and have only once seen that
feature used. It was used to separate a subsystem that contained
hundreds of Ada packages but was tightly coupled into 5 subsystems where
all the views of a particular tower were mutually importing. It was a
bad design that led to this use and this was legacy code. I have never
seen a new design ever consider using mutually importing views.

> Here is the way to do it in CVS
>
> - CVSROOT
>     - history1
>          - subdir1
>          - subdir2
>     - history2
>          - subdir1
>          - subdir2
>
> - Integration "view"
>     - history1-subdir2
>     - history2-subdir1
>
> I doubt Apex does it any different. In which case this is
> very basic functionality. In my example, the CVSROOT
> enforces the CM responsibility.  I suppose
> you could have different CVSROOT paths which
> would be the equivalent of different subsystems.
> But I would only do this if I knew I was
> going to develop both Linux, GNAT, and Netscape
> at the same time. Which is very doubtful.

You misunderstand subsystems. Let me give a simple example:

I am building a controller that communicates over TCP/IP and uses X
windows to talk to the user. I separate the code into the following
subsystems:

low_level_components.ss
communications.ss
command_and_control.ss
user_interface.ss

In each view I have a release called: block1.rel and a working view
called block_2_working.wrk.

the heirarchy of the subsystems is:
                   low_level_components.ss
                       /          |         \
              user_interface.ss   |    communications.ss
                        \         |         /
                       command_and_control.ss

At the high level design level, the interface between the user_interface
and the command_and_control is defined, and the interface between the
communications and command_and_control. The Ada specs are put into place
and in the views. In low level design, common algorithms and types are
defined and placed in low_level_components. Coding then can progress on
user_interface, communications, and command_and_control without any
impact on one another, unless there is a change to the interface defined
earlier. The coupling between the views in the subsystems are minimized.

(So, I assume this would be more like your subdirectories in a given
history, where the histories would be more like the views or releases
(although not exactly the same thing)).

So, lets say I have finished with Block 1 and want to move to Block 2 of
my software. I can release the Block_1 tower and create new block 2
working views. these views can import the block 1 releases until the
block 2 interfaces are stable and then change the imports to the
stablized block 2 views. This it one reason for multiple views in a
subsystem.

Another is that Bob and I are working on communications. Bob and I make
out own views off of an integration view, work in our own views and then
import out tested changes back into the integration view when completed.
This is not rocket science or anything, I have never seen a CM system
where the equivolent was not possible, the key to the Apex IDE is that
it is integrated into the IDE, which I have not seen elsewhere.

> No I am only trying to figure out a path forward.  Rational
> has many products that seem to cannibalize each other
> such as Apex, ClearCase, and Summit.  Each one of these
> is claimed to be the way to go for large software systems
> development.

Brief history of Rational Software. In the beginning there was Rational,
they made Rational R1000's which were a hardware/software Ada 83
development system. They had subsystems and views. R1000's were dogs.
They were slow and ineffeciant and broke often, but besides that where
pretty good development platforms. Rational bought Verdix and became
Rational Software. Using the VADS compiler, they incorperated alot of
their R1000 environment into the compiler, thus decoupling it from the
Rational Hardware. Apex was born. Apex is an IDE, Summit is an add on to
that IDE. ClearCase is a CM product. It can be used with or without
Apex.  So "the way to go" depends on what you are looking for. If you
want an IDE, ClearCase, SoDA, or Rose are not the way to go :)

I hope this answers your original question:

> Why would anyone consider paying money for Apex when it does not pay
> any attention to common Java or Ada 95 deployment philosophies? Or am
> I missing something?
---
Jeffrey S. Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.