abbott@aero.org (Russell J. Abbott) (03/15/91)
[I apologize if this is a repeat. This article never showed up on my comp.software-eng or comp.object. So I am sending it again.] ======================================================================== 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