abbott@aero.org (Russell J. Abbott) (03/12/91)
There has been some discussion recently about the relationship between Ada constructs and the MIL-STD 2167A categories Computer Software Components (CSC) and Computer Software Unit (CSU). Arguments range from claims that: (a) mapping Ada to CSCs and CSUs is overly burdensome and a waste of time and energy; to claims that: (b) CSCs and CSUs are important software organizational categories that should be used independently of the language in which a software system is coded. I would appreciate comments from anyone with an interest in this area. I am especially interested in focusing on (b). If CSCs and CSUs represent independently useful software organizational categories (and I think that they probably are): (1) how should those categories be defined, and (2) can those definitions be made compatible with OO approaches to software design? According to MIL-STD 2167A: A CSC is "A distinct part of a computer software configuration item (CSCI). CSCs may be further decomposed into other CSCs and Computer Software Units (CSUs)." [Nothing in this definition establishes properties that would qualify or disqualify something from being a CSC other than it be part of a CSCI and (implicitly and in practice but not explicitly) that it include CSUs.] A CSU is "An element specified in the design of a Computer Software Component (CSC) that is separately testable." [The key phrase here is "separately testable." The notion of "testability" is generally interpreted broadly. One form of testing is inspection in which one looks at something and draws conclusions about it. This leads to the argument that a package of type declarations or constants is separately testable. That pushes the idea of "testing" a little further than I would like.] A CSCI is "A configuration item for computer software." [I don't have the definition of "configuration item" handy, but essentially it is an item that is placed under configuration control, i.e., an item that is purchased and delivered and whose specification and design are written down and subject to approval by the purchasing agency.] An issue that strikes me as important (and that might help resolve the "testing" problem mentioned above) is whether CSCs and CSUs should be defined in terms of the expected operational product or in terms of the source code that defines it. The implication of the definitions given above is that CSCIs, CSCs, and CSUs are all to be understood in terms of the delivered product. I believe that that approach is appropriate. In some cases, though, that perspective may lead to a different result from the one one would get if they were defined in terms of software constructs. For example, imagine that the architecture of a software system includes two components X and Y with two distinct functions within the system. It is conceivable that those two components are generated as two instances of a single Ada task type or generic. Thus one chunk of software gives rise to what from the perspective of the intuitive software architecture would be considered two CSCs or two CSUs. In fact, if the software were developed differently, these two components could presumably be derived from two completely separate chunks of source code. Although this sounds like a confusing situation, I would argue that it is in fact desirable as software developers strive for increased abstraction and reuse. This points out, though, how important it is to understand independently the role that the categories CSC and CSU play in software development and (in my opinion) to decouple that role from unduly tight mappings to source code constructs. Thanks for your comments. -- Russ Abbott@uniblab.aero.org
pukite@vz.acs.umn.edu (J. PUKITE) (03/12/91)
In article <1991Mar11.164855.24098@aero.org>, abbott@aero.org (Russell J. Abbott) writes... >There has been some discussion recently about the relationship between >Ada constructs and the MIL-STD 2167A categories Computer Software >Components (CSC) and Computer Software Unit (CSU). > >Arguments range from claims that: > >(a) mapping Ada to CSCs and CSUs is overly burdensome and a waste of >time and energy; > >to claims that: > >(b) CSCs and CSUs are important software organizational categories that >should be used independently of the language in which a software system >is coded. > >I would appreciate comments from anyone with an interest in this area. > >I am especially interested in focusing on (b). If CSCs and CSUs >represent independently useful software organizational categories (and I >think that they probably are): (1) how should those categories be >defined, and (2) can those definitions be made compatible with OO >approaches to software design? Assuming that one follows 2167A software development process, then the following applies: CSCs and CSUs are defined prior to the start of actual coding. As such they are not dependent on a specific language, but actually describe the functional requirements in terms input, processing, and output (this could be a HIPO chart). The governing document is: Software Design Document (DID: DI-MCCR-80012A) DID - Data Item Description Official description from the corresponding DID Description and Purpose: 1. The Software Design Document (SDD) describes the complete design of a Computer Software Configuration Item (CSCI). It describes the CSCI as composed of Computer Software Components (CSCs) and Computer Software Units (CSUs). 2. The SDD describes the allocation of requirements from a CSCI to its CSCs and CSUs. Prior to Preliminary Design Review, the SDD is entered into the Developmental Configuration for the CSCI. Upon completion of Physical Configuration Audit (PCA), the SDD, as part of the Software Product Specification, is entered into the Product Baseline for the CSCI. 3. The SDD is used by the contractor for three primary purposes, namely: (1) present the preliminary design at the Preliminary Design Review(s), (2) present the detailed design at the Critical Design Review(s), and (3) use the design information as the basis for coding each CSU. 4. The SDD is used by the Government to assess the preliminary and detailed design of a CSCI. ------ end of quote ------ Thus, arguments (a) and (b) are not really applicable in a true 2167A if the recommended approach is used. It is always possible, that some people may want to start at the end and after writing the program attempt to determine what it does and what kind of structure it exhibits. I hope that this may clear up the situation! J. Pukite/DAINAe pukite@vz.acs.umn.edu
jls@rutabaga.Rational.COM (Jim Showalter) (03/13/91)
I have spent the last three years of my career helping customers
to do decent OO and Ada software engineering within the confines
of 2167A.
My basic position is that 2167A is essentially worthless, gets in
the way of anything approaching a reasonable modern methodology
(e.g. rapid prototyping, iterative development, interface definition,
abstraction, modularity, reuse, Ada, etc), generates reams and
reams of fundamentally pointless documentation, encourages a
functional decomposition despite claims to the contrary, constrains
developers to an essentially waterfall lifecycle model, etc etc etc.
In short, it is an abomination and should be shitcanned, or at least
heavily tailored.
I was always amazed that the DoD did something right for once when
it came out with Ada. I kept waiting for the other shoe to drop.
2167A is that shoe.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine.
-- "When I want your opinion, I'll beat it out of you."