From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,39e272d357c68416 X-Google-Attributes: gid103376,public From: reason67@my-deja.com Subject: Re: Is Apex dead as an environment for Ada & Java? Date: 1999/11/30 Message-ID: <820p6p$hb9$1@nnrp1.deja.com> X-Deja-AN: 554827473 References: <11f733ec.57d88b68@usw-ex0107-042.remarq.com> <384127A5.61431A14@dowie-cs.demon.co.uk> <0a0133f8.3baf10c0@usw-ex0101-001.remarq.com> <81s370$7am$1@nnrp1.deja.com> <0a0133f8.7900d89e@usw-ex0102-015.remarq.com> <81u6sh$l7k$1@nnrp1.deja.com> <1761dd4a.3f28b0f0@usw-ex0101-008.remarq.com> X-Http-Proxy: NetCache@www-blv-proxy3.boeing.com: Version NetApp Release 3.4D6: Mon Aug 23 16:40:19 PDT 1999-Solaris, 1.0 x33.deja.com:80 (Squid/1.1.22) for client 12.13.226.13 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Tue Nov 30 15:07:09 1999 GMT X-MyDeja-Info: XMYDJUIDreason67 Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.05 [en]C-Boeing Kit (Win95; I) Date: 1999-11-30T00:00:00+00:00 List-Id: In article <1761dd4a.3f28b0f0@usw-ex0101-008.remarq.com>, jim_snead 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.