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.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8fba9f5c34fa11d3 X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: Rational Apex Date: 1998/08/27 Message-ID: <35E58AD0.B5A03972@hso.link.com>#1/1 X-Deja-AN: 385325540 Content-Transfer-Encoding: 7bit References: <6ri10m$shc$1@beauty.mda.ca> Content-Type: text/plain; charset=us-ascii Organization: Raytheon Training Inc. Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-08-27T00:00:00+00:00 List-Id: 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!"