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

[reason67@my-deja.com]

In article <0a0133f8.7900d89e@usw-ex0102-015.remarq.com>,
  jim_snead <basswoodNObaSPAM@my-deja.com.invalid> wrote:
> In article <81s370$7am$1@nnrp1.deja.com>, mike_zebrowski@my-deja.com
> wrote:
>
> This approach is simple and enforceable. I don't
> like the fact that Apex has features as complicated
> as subsystems to accomplish this simple effect.
> The tool effectively locks you into a specific approach
> and you become a captive Apex customer because
> of some outrageous marketing features.


The reason for subsystems is to encapsulate components withing a
software hierarchy. For instance, if I was working on a simple Fighter
simulation, I might want a subsystem for universals_types,
low_level_utilities, then build subtrees based on common radar
functionalities, common flight functionalities, weather, etc. Then, for
example in the flight, I could break i down further into flight_common,
cockpit_displays, aerodynamics, etc. etc.

What I gain is the ability to enforce a design onto 50 - 100 developers.
This would prevent a flight developer from using a subprogram developed
by a weather developer. This enforces loose coupling between unrelated
features. If the weather developer needs to eliminate or modify his
subprograms, he is guarenteed not to effect the other in unrelated areas
of the simulation.

Can I do this other ways in Ada95? Sure. But I can only do it in Ada95
by enforcing a coding requirement on the developers, and not just a
design requirement. (your package heirarchy example).

Subsystems serve another purpose as well, as someone else pointed out,
Apex code exists in views. The code is shared in a subsystem and
implemented in views. The Subsystems enforce the CM.

None of this makes Apex a requirement for Ada95 obviously and you may
consider the overhead to be too great or the cost prohibitive, but it
certainly does not mean that Apex subsystems serve no purpose or are
antequated. I have always found them to be quite useful on large
projects.
---
Jeffrey S. Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.