Rational Apex

Rational Apex

[Glenn]

Hello...

Does anyone have any experiences using Rational Apex with an existing
"legacy" project?  We are looking into transitioning from VADS to Apex (VADS
support will be discontinued for the platform we are using) and I am
concerned that our current processes (CM, etc.) will not work with Apex'
highly integrated environment.

Any info would be appreciated...thanks.

Re: Rational Apex

[David Weller]

In article <6q8ab6$3dg$1@newnews.startext.net>,
Glenn <gdiehl@startext.net.nospam> wrote:
>Any info would be appreciated...thanks.
>
Nothing really forces you to use Apex.  You can still use the compiler
from the command line and (I think) library management can be done
from the command line.  If you have a well-established development
process, you should NEVER change it if it is working for you.  Even if
you current compiler vendor says you have to.  Tell them that choice
is unacceptable.  You would probably find it MUCH cheaper to switch to
GNAT if your platform is supported.

-- 
  DVD vs. DIVX: The Truth Is Out There => http://www.riva.com/dvd_divx.html
---------------------Read about "Reformed English"----------------------------
   "Linguistically ingenious, politically incorrect" http://www.riva.com/re

Re: Rational Apex

[Christopher Green]

In article <6q9qi3$98n@universe.digex.net>,
David  Weller <dweller@universe.digex.net> wrote:
>In article <6q8ab6$3dg$1@newnews.startext.net>,
>Glenn <gdiehl@startext.net.nospam> wrote:
>>Any info would be appreciated...thanks.
>>
>Nothing really forces you to use Apex.  You can still use the compiler
>from the command line and (I think) library management can be done
>from the command line.  If you have a well-established development
>process, you should NEVER change it if it is working for you.  Even if
>you current compiler vendor says you have to.  Tell them that choice
>is unacceptable.  You would probably find it MUCH cheaper to switch to
>GNAT if your platform is supported.

Apex is not just a compiler; it's a way of life.

Apex has its own highly structured way of doing things.  It is insistent
about using its own directory structure and file naming conventions, at
a minimum.  It will reformat your code according to its defaults, unless
you force it not to.  It has its own CM subsystem (Summit) built in.

Apex can be run from the command line, but this does not reduce the need
to organize your code into Apex subsystems and views, and at least to
observe Apex file naming conventions.

Basically, Apex is a heavyweight solution to many of the problems that
arise in developing software on a very large scale.  But you need to use
Apex the way Rational designed it; if you try to impose your own way of
doing things on Apex, you will spend all your time fighting it rather
than getting work done.

-- 
Chris Green                                  Email cgreen@atc.com
Advanced Technology Center                   Phone (949) 583-9119
22982 Mill Creek Drive                                   ext. 220
Laguna Hills, CA 92653                       Fax   (949) 583-9213

Re: Rational Apex

[Roy Grimm]

Christopher Green wrote:
> 
> Apex is not just a compiler; it's a way of life.

So true.

> Apex has its own highly structured way of doing things.  It is insistent
> about using its own directory structure and file naming conventions, at
> a minimum.  It will reformat your code according to its defaults, unless
> you force it not to.  It has its own CM subsystem (Summit) built in.

I'm assuming you mean Change Management instead of Configuration
Management.  Summit is available as one of the many layered products. 
However, you don't have to use it to track changes  You're free to use
your old tools.  In many of our legacy projects, we still use our old
Change Reporting tools instead of Summit.

> Apex can be run from the command line, but this does not reduce the need
> to organize your code into Apex subsystems and views, and at least to
> observe Apex file naming conventions.

But this isn't necessarily a bad thing.  Getting used to their structure
of subsystem/views with multiple history CMVC takes a while, but adds a
layer of organization that makes managing large projects significantly
easier.  Our department makes a reusable bootstrap loader and software
loader that is compiled to several different processors.  With Apex, we
assign different version history trees to critical configuration files,
make the rest of the code reference those specific packages.  When we
make a change to one high level package, it's a few mouse clicks and
we've updated every other platform we want to.  Very slick, very easy. 
I'll never miss the old Unix/SCCS days, or that brief stint with
WindozeNT and Micro$oft Visiual Source Save...  *shudder*

> Basically, Apex is a heavyweight solution to many of the problems that
> arise in developing software on a very large scale.  But you need to use
> Apex the way Rational designed it; if you try to impose your own way of
> doing things on Apex, you will spend all your time fighting it rather
> than getting work done.

That's half true.  Apex has it's way of doing things.  One of those ways
is providing the flexibility to manage your project with their tools or
someone else's.  The basic file and directory structure is provided for
you.  Everything else is configurable.  Don't want to use Rational Rose
for documentation?  Don't.  Want to use another compiler?  The Apex IDE
has the Remote Compilation Interface that lets you run any third party
compiler you want.  Hell, I've worked on Apex running on a Sun
workstation that remotely compiles on a VAX/VMS workstation.  A little
set up for the 'rsh' and NFS interface and you're good to go.  It's all
automatic from within the IDE.  Just hit "link" and away it goes.

If you've got just one line of products on one target architecture, Apex
might be overkill.  If you've got dozens of projects with several
different projects and requirements to support legacy compilers and what
not, Apex is the way to go.

-- 
Roy A. Grimm             |  Tel:   (319)295-8099
Rockwell Collins, Inc.   |  Fax:   (319)295-8940
Cedar Rapids, Iowa       |  email: ragrimm@collins.rockwell.com

When you think how well basic appliances work, it's
hard to believe anyone ever gets on an airplane.     --Calvin

My opinions don't necessarily match those of my employer.

Re: Rational Apex

[Matthew Heaney]

cgreen@yosemite.atc.com (Christopher Green) writes:

> Apex is not just a compiler; it's a way of life.

I think the same thing about emacs.

[snip]

> Basically, Apex is a heavyweight solution to many of the problems that
> arise in developing software on a very large scale.  But you need to use
> Apex the way Rational designed it; if you try to impose your own way of
> doing things on Apex, you will spend all your time fighting it rather
> than getting work done.

Funny, this is what I often say to programmers about Ada.

Re: Rational Apex

[Lowe Anthony A]

Roy is totally right.   For the standard everyday user I equate Apex as
driving a circus train to get to work.   There can be a ton of overhead just
to get the first file put in and compiled.  When it comes to the build
manager, QA, CCB members, Apex is their best friend.  It has quite a few very
useful tools and utilities available, but if you are used to a MS interface,
it can be quite annoying.

As for suggestions/ recommendations:
    * Learn as much about the Apex tools and how the components function (i.e.
subsystem versus view versus history).  If you architect correctly, it can be
years of easy sailing.   If you just throw something together, you will spend
more time fighting the tool than building with it.  (Another fact true of
Ada).

    * Provide the correct training to the specific job functions.  The
standard developer needs to have a basic understanding of how Apex does stuff,
but does not need gory details about the underbelly of the program.   Spend
the money however to get the development environment people up to speed on how
to manage Apex.  This will save much time, dollars, and frustration in the
long run.

    * The RCI capability Roy spoke of is beautiful for replacing 'obsolete'
environments with a nice push button GUI.  We have quite extensively used a
RCI to replace a VAX command line environment and it is immensely helpful.
If you choose to use a GUI compiler (GNAT, ObjectAda) the utility of the RCI
dramatically drops, since the GUI environments provided by the other compiler
are most often easier to use than Apex.

    * Overall, like Roy said, Apex is a great tool if you need strong
Configuration Management, Change Management, and have a very diverse or
changing product.   I find it quite cumbersome to use as just a coding
environment (especially if you have PC's in front of the developers and they
have to XWindow over to a server to use it!).   If you have a simple product,
I would think hard about a smaller product.

Good Luck!

--
Tony Lowe                   Rockwell Collins
1431 Opus Place   -  Downers Grove, IL 60515
(630)-960-8603          Fax : (630)-960-8207

Re: Rational Apex

[Chris Warwick]

In article <6q8ab6$3dg$1@newnews.startext.net>, "Glenn" <gdiehl@startext.net.nospam> wrote:
>Hello...
>
>Does anyone have any experiences using Rational Apex with an existing
>"legacy" project?  We are looking into transitioning from VADS to Apex (VADS
>support will be discontinued for the platform we are using) and I am
>concerned that our current processes (CM, etc.) will not work with Apex'
>highly integrated environment.

I find the concept of VADS support being discontinued, and Apex being the 
replacement. The VADS compiler is at the root of the Apex environment... I ran 
into this on the Sun where our upgrade after Rational bought VADS starting the 
Sun code under Apex acting like the VADS code under SCO (this was a good 
thing as we try to do as much work as possible on the Sun before going to 
SCO, and the differences were causing a few gotchas).

Apex is a small horde of 'C' shell scripts with a GUI on top, so you should 
have no problem customizing the enviroment to your current procedures. 
The things that take getting used to are the directory structure required by 
Apex, and the CM system. The CM system is odd because they copy files rather 
than creating links so your developers have the impression that they have a 
local copy of all the files, whereas Apex thinks you only have instances of 
the files...

Re: Rational Apex

[Corey Ashford]

Chris Warwick wrote in message <6qlci2$da7@priv-sys04-le0.telusplanet.net>...
>In article <6q8ab6$3dg$1@newnews.startext.net>, "Glenn" <gdiehl@startext.net.nospam> wrote:
>>Hello...
>>
>>Does anyone have any experiences using Rational Apex with an existing
>>"legacy" project?  We are looking into transitioning from VADS to Apex (VADS
>>support will be discontinued for the platform we are using) and I am
>>concerned that our current processes (CM, etc.) will not work with Apex'
>>highly integrated environment.
>
>I find the concept of VADS support being discontinued, and Apex being the
>replacement. The VADS compiler is at the root of the Apex environment... I ran
>into this on the Sun where our upgrade after Rational bought VADS starting the
>Sun code under Apex acting like the VADS code under SCO (this was a good
>thing as we try to do as much work as possible on the Sun before going to
>SCO, and the differences were causing a few gotchas).

This isn't true, exactly.
The original VADS Ada front-end went away, replaced by the Apex
Ada front-end.  IMHO, the best feature of the Apex Ada front-end
is the fast-path recompilation.  It's very cool, and saves an incredible
amount of time particularly when altering package specs which are on
the transitive 'with' closure of many packages.

What is retained from VADS is the optimizer, code generator, and much of
the runtime system.  The runtime system has undergone
many changes since VADS because of the need for Ada95 support.

>
>Apex is a small horde of 'C' shell scripts with a GUI on top, so you should
>have no problem customizing the enviroment to your current procedures.

Many of the scripts are "Apex_Shell" scripts.  This is a scripting
language that is similar to C shell, but much more powerful, and has
many convenient and useful hooks into Apex.

>The things that take getting used to are the directory structure required by
>Apex, and the CM system. The CM system is odd because they copy files rather
>than creating links so your developers have the impression that they have a
>local copy of all the files, whereas Apex thinks you only have instances of
>the files...

This is true, but Apex makes it look as if the files are not simply
copies.  To alter a file, you must check it out (if it was controlled,
which is not required).

There are two possible CM systems that can be used in the latest
release of Apex...  the original Apex Summit CMVC system, and the
newer ClearCase CM (which was originally a product of PureAtria,
before the two companies merged).

- Corey

Re: Rational Apex

[Gene Ouye]

!!!!!!!!!!! WARNING !!!!!!!!!!!
	!!! SHAMELESS PLUG INCLUDED !!!
	!!!!!!!!!!! WARNING !!!!!!!!!!!

I agree with most of the things that Tony said below especially his
first three "suggestions/recommendations", but I do have to comment on
some of his post (I must warn you that I work for Rational and am
directly associated with the product discussed in the next few
paragraphs, so you should consider my opinions biased, even if they are
true :-)

First, I've missed most of the start of this thread, so I apologize in
advance for any duplication or wasted bandwidth...

I can understand the metaphor comparing Apex for the "everyday user"
with every day commuting in a rather large, cumbersome, vehicle, but
"circus train" wouldn't be my first choice!  ;-)  One could argue
whether that metaphor is appropriate, but I would rather discuss another
option that isn't mentioned: Apex Ada for Windows NT.

If you have a bunch of PC's sitting on your desktops, and they are
capable of running NT4.0, then you can run Apex Ada natively on the PCs
instead of using them as X-servers connected to UNIX boxes.  You can get
it without all the "cumbersome" :-( features like Configuration
Management and Change Management if you like.  Most people who use it
comment favorably on how un-"cumbersome" it really is.  There's no need
to use an X-server to UNIX, it's a Windows application, and in fact it
comes with a demo version of CLAW and the CLAW GUI builder.  If you want
to work in conjunction with existing UNIX Apex developers, you can
easily plug Apex NT into the UNIX CMVC repository.

There are some things you will not get away from.  The subsystem/view
paradigm is still there in Apex NT even if you choose not to use CMVC
(in fact, it maps nicely to DLLs).  And the whole notion of imports and
exports between Rational subsystems is an extremely powerful paradigm
for architecting an application.  Also, Apex NT (like UNIX Apex and like
GNAT) requires one compilation unit per file, and the filename is
directly related to the unit name (although not in the same way as
GNAT).  And yes, there is a straightforward way (incorporated into the
GUI) to parse the compilation units out of other source files :-)

I do a lot of simple Ada things these days (I'm in a marketing job now,
need I say more?) and I find it quite easy to do them with Apex.  Just
as Ada doesn't force you to create a new integer type for every number
in your application (you can make them all Standard.Integer if you want)
and Ada doesn't force you to put every tagged type into a different
package (you can put your entire application in one procedure if you
like), Apex doesn't force you to partition your application into lots of
subsystems and views.  I keep a "play area" subsystem with a view
containing several directories that imports all the base libraries. 
Whenever I want to throw something together quickly (like when I want to
see if someone's sample code really does produce the errors they post),
I just go there and try things out.  I find the syntactic and semantic
completion make writing the simple applications go much faster...

BTW, I haven't updated the external Rational web pages with the latest
information on Apex NT (didn't want to be pushing vaporware), so don't
go rushing over there yet for more details.  If you check it over the
next few weeks you'll see some pages specifically dedicated to Apex NT.

Gene Ouye <g.e.n.e.o.@.r.a.t.i.o.n.a.l...c.o.m>
    (make the obvious fix to send me mail)

Apex Ada NT Product Manager


Lowe Anthony A wrote:
> 
> Roy is totally right.   For the standard everyday user I equate Apex as
> driving a circus train to get to work.   There can be a ton of overhead just
> to get the first file put in and compiled.  When it comes to the build
> manager, QA, CCB members, Apex is their best friend.  It has quite a few very
> useful tools and utilities available, but if you are used to a MS interface,
> it can be quite annoying.
> 
> As for suggestions/ recommendations:
>     * Learn as much about the Apex tools and how the components function (i.e.
> subsystem versus view versus history).  If you architect correctly, it can be
> years of easy sailing.   If you just throw something together, you will spend
> more time fighting the tool than building with it.  (Another fact true of
> Ada).
> 
>     * Provide the correct training to the specific job functions.  The
> standard developer needs to have a basic understanding of how Apex does stuff,
> but does not need gory details about the underbelly of the program.   Spend
> the money however to get the development environment people up to speed on how
> to manage Apex.  This will save much time, dollars, and frustration in the
> long run.
> 
>     * The RCI capability Roy spoke of is beautiful for replacing 'obsolete'
> environments with a nice push button GUI.  We have quite extensively used a
> RCI to replace a VAX command line environment and it is immensely helpful.
> If you choose to use a GUI compiler (GNAT, ObjectAda) the utility of the RCI
> dramatically drops, since the GUI environments provided by the other compiler
> are most often easier to use than Apex.
> 
>     * Overall, like Roy said, Apex is a great tool if you need strong
> Configuration Management, Change Management, and have a very diverse or
> changing product.   I find it quite cumbersome to use as just a coding
> environment (especially if you have PC's in front of the developers and they
> have to XWindow over to a server to use it!).   If you have a simple product,
> I would think hard about a smaller product.
> 
> Good Luck!
> 
> --
> Tony Lowe                   Rockwell Collins
> 1431 Opus Place   -  Downers Grove, IL 60515
> (630)-960-8603          Fax : (630)-960-8207

Re: Rational Apex

[Samuel T. Harris]

David Weller wrote:
> 
> In article <6q8ab6$3dg$1@newnews.startext.net>,
> Glenn <gdiehl@startext.net.nospam> wrote:
> >Any info would be appreciated...thanks.
> >
> Nothing really forces you to use Apex.  You can still use the compiler
> from the command line and (I think) library management can be done
> from the command line.  If you have a well-established development
> process, you should NEVER change it if it is working for you.  Even if
> you current compiler vendor says you have to.  Tell them that choice
> is unacceptable.  You would probably find it MUCH cheaper to switch to
> GNAT if your platform is supported.
> 
> --

I've just returned from vacation and missed the original post
so please forgive any assumptions I may make below.

As an old Apex (and Rational R1000) hack _and_ an avid GNAT user
I'd like to add that all library, compilation, and configuration
management operations in Apex can indeed be performed in a batch/
command-line mode. Not knowning the original situation, I'll just say
that _if_ one is using Apex exclusively in this way, then one is
paying WAY too much money supporting the tool. The language sensitive
editor and high degree of integration of the GUI elements IS the
productivity leverage which justifies the cost of the tool. Other
combinations of other tools (such as GNAT + CVS + EMACS) come close
and are much cheaper to buy (but require somewhat more sweat to
keep running).

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

Rational Apex

[James Amendolagine]

     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

Re: Rational Apex

[Samuel T. Harris]

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!"