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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,39e272d357c68416 X-Google-Attributes: gid103376,public From: Martin Dowie Subject: Re: Is Apex dead as an environment for Ada & Java? Date: 1999/11/28 Message-ID: <384127A5.61431A14@dowie-cs.demon.co.uk>#1/1 X-Deja-AN: 554039569 Content-Transfer-Encoding: 8bit X-NNTP-Posting-Host: dowie-cs.demon.co.uk:193.237.34.207 References: <11f733ec.57d88b68@usw-ex0107-042.remarq.com> X-Accept-Language: en Content-Type: text/plain; charset=iso-8859-1 X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 943794089 nnrp-03:17992 NO-IDENT dowie-cs.demon.co.uk:193.237.34.207 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-11-28T00:00:00+00:00 List-Id: 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."