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
Xref: utzoo comp.software-eng:5014 comp.lang.ada:4947 comp.object:2704
Path: utzoo!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!usc!aero-c!abbott
From: abbott@aero.org (Russell J. Abbott)
Newsgroups: comp.software-eng,comp.lang.ada,comp.object
Subject: CSCs and CSUs
Message-ID: <1991Mar11.164855.24098@aero.org>
Date: 11 Mar 91 16:48:55 GMT
Sender: news@aero.org
Organization: The Aerospace Corporation, El Segundo, CA
List-Id: <comp.lang.ada>

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