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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.lang.ada Subject: Re: What's a CSU in Ada? Keywords: CSC, CSU Message-ID: <1991May9.075713.5663@netcom.COM> Date: 9 May 91 07:57:13 GMT References: <1991May8.000741.11255@mprgate.mpr.ca> Sender: netnews@netcom.COM (USENET Administration) Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Originator: jls@netcom.netcom.com List-Id: >What Ada language constructs >meet the requirements of a CSU (per DOD-STD-2167A), and which ones are >CSCs? For two years or so, I supported Rational's Design Facility, which maps Ada units to 2167A design components (and produces the documentation). During that time, I would guess your question came up in the above or similar form about twice a week, and the answer I gave was always the same: "What would you LIKE the mapping to be?". 2167A is intended to be tailorable, and as such is open to widely varying interpretations: I've seen different interpretations used from company to company, site to site within the same company, and even project to project within the same site. Some customers have opted for a "weak" mapping, where the 2167A design components and design hierarchy are pure abstractions, with the resulting code residing only at the leaves, as CSUs (in some cases even the CSUs were treated as abstractions that served to group the actual comp units in some logical manner). Other customers have tried (usually with much less success) a "strong" mapping, in which there is a standard pre-defined Ada "meaning" to terms like "CSC". Still other customers, seeking a more Ada- and OO-compatible standard, have so radically tailored the baseline standard as to be virtually unrec- ognizable. For what it's worth, my personal preference would be to tailor as much as practicable WHEN A CLEAR ADVANTAGE TO DOING SO CAN BE PROVEN (tailorings that muck around with purely aesthetic issues, such as the font used on bulleted lists, are a complete waste of time). The objective is to adopt the standard to support a quality methodology, not to distort your methodology to force-fit it into the standard (this key point seems to be lost on a lot of people, which is kind of surprising since that's essentially what the first paragraph on the first page of the standard SAYS). I also prefer a weak mapping, since it provides a great deal more flexibility when allocating requirements, assigning responsibility, etc. You and the others involved in your project need to agree on what strategy to use, and get your customer signed off on it. To a large extent, which mapping you decide on is of less importance than deciding on SOMETHING: it is very easy to get bogged down in endless religious arguments about the alleged merits of one mapping over another. I recently read a good collection of papers on this very issue entitled something like "Implementing the DoD-2167A Design Hierarchy in Ada", or some such (sorry, don't have it with me at home). I think it was put out by SIGAda or a similar SIG group. Hopefully someone else on the net can do better at providing the precise reference.