In article , Simon Wright wrote: > Martin Dowie writes: > > 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 Ad > > 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 > > automatically express and enforce the large-scale structure, or > > architecture, of their applications." > Subsystems may be good for a lot of things, but this particular one > has always struck me as odd; especially in an environment where > code is designed before it's implemented, and inspected afterwards. For an OO design we may have a sea of classes created through an OO drawing tool. I wonder what leverage Apex adds here. I sense that they are unsure where the architectural enforcement should come in to play. 1. Design (OO model) - Enforce the architecture via a tool like Rose 2. Implementation - Transcription of design, no enforcement necessary 3. Inspection - Check that transcription was correct Rose can do the enforcement and Apex can do the enforcement, but how can Apex enforce something that was not in the original OO model (such as the notion of visibility control)? And if these were in the original model, then they would clearly map into things like Ada 95 private packages. In which case you would not need the Apex subsystems to enforce anything! I do agree with you that it is odd and very confusing when you consider the early design. Thanks for the insight. * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!