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

[Martin Dowie <martin@dowie-cs.demon.co.uk>]

jim_snead wrote:

> I have been studying the Rational Apex product
> as an Ada 95 and Java development environment.
> Apex has an unusual feature called "subsystems"
> which to me seems quite useless.
>
> Apparently the notion is that you can place related
> pieces of software into a subsystem, which is a
> directory structure with strict naming conventions
> (ends with a *.ss which nests other directories).
> Other developers can place their own software into
> another subsystem as a library.  The "subsystem"
> seems to be a legacy organizing feature from
> archaic software practices.

> For any practical development in Java or Ada 95,
> this notion seems particularly baroque and
> antiquated.  With Java, the package namespace is the
> organizing feature. Even though Rational sells an
> Apex for Java, it is beyond me how subsystems would
> even begin to work with Java. I guess that one
> could put all of an organization's Java source libraries
> into a single subsystem. But then what is the point
> of a subsystem? In the same way, I believe that Ada
> package hierarchies are sufficient to avoid the
> need for multiple subsystems.

>
> Why would anyone consider paying money for Apes
> when it does not pay any attention to common
> Java or Ada 95 deployment philosophies? Or am I
> missing something?  (I do not care at all about
> C or Ada 83).

(pedantic point - they place their code in as a 'view' not a library)

for small systems one subsystem would be enough but for the large embedded
systems i
work with subsystems are pretty useful. apart from adding a layer of
organization to the
views - you have to have somewhere to put the views. so, either the tool
dictates how to
name such repositories which everyone must follow (automatically), or you make
up your
own rules (and every engineer will have their own preference, or worse, every
engineer in
every project!) so that writing your own tools becomes just that little bit
harder. a
common approach is to have a subsystem per piece of hardware your software
monitors/controls (thread?/process?/task?), other subsystems to deal with
classes,
shared data stores and inter task (process/thread) communications plus a 'main'
subsystem to pull them all together in one executable.

the real point about the subsystem is that this is where the repository for all
the code is
(including a note of what histories are available) - the views do not
automatically go
looking for each other to see which view is using which compilation unit at
whatever issue
or history.

Apex describe them on their web site -
"Rational Apex provides a framework for defining architectural components, known
as Rational Subsystems�. These subsystems integrate with the Rational Apex
version control system and with Ada 95 package hierarchies. Rational Apex
prevents undesirable code references by controlling visibility among
architectural components. Attempts to improperly reference units results in
compile time error messages. In this way, subsystems enable users to
automatically express and enforce the large-scale structure, or architecture, of
their applications."