Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cca!g-rh
From: g-rh@cca.CCA.COM (Richard Harter)
Newsgroups: comp.software-eng
Subject: Re: Question Re: Configuration Management
Keywords: configuration management, software design
Message-ID: <24502@cca.CCA.COM>
Date: 14 Feb 88 04:48:18 GMT
References: <497@aimt.UUCP>
Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge, MA
Lines: 72

In article <497@aimt.UUCP> breck@aimt.UUCP (Robert Breckinridge Beatie) writes:
>
>Basically the argument is over one question: "Is it acceptable to have
>more than one 'call interface' per source file or not?"  For our purposes
>a 'call interface' is defined as a non-static function in a C source file.
>My boss' position is that having more than one 'call interface' per source
>file causes so many "configuration management" problems that it outweighs any
>benefits.
>
>So how about it?  What horrible CM problems does having more than one
>'call interface' per source file cause?  Has anyone had any such problems?
>I'd appreciate any horror stories, anecdotes, or opinion.


	There are a number of issues involved here.  The following may be
what your boss has in mind.  If every file has exactly one entry point
and that entry point has the same name as the file (with the extension
stripped off) then life becomes simpler in a number of respects.  When you
see function foo in some source code you know that it can be found in file
foo.c [more or less -- it may be a macro or in a system library or ...].
Similarly, if the linker comes up with "foo not found", you know that
you need to include foo.o to the list of files loaded.  [Again, foo
may be a data global -- most linkers are reticent about such details.]

	The classical way to describe a hardware configuration is use an
indented tree listing, e.g.

	System
	  Sub system 1.
	    Component 1.1
	    Component 1.2
	  Sub system 2.
	    Component 2.1
	    ...

When we talk about software, the question is, "are the compenents procedures
or files".  If we are talking about program structure, the answer is
"procedures".  However the components managed are usually files.  If we
follow the one procedure, one file rule there is no problem.  Suppose,
however, that we have packaged several procedures into one file, e.g.
components 1.1 and 2.1 are contained in the same file.  Then the single
file is shared by several subsystems.  This makes for complications.

	Actually, of course, the problem is there even if we follow the
one file, one procedure rule.  To see why, let me take an example from
hardware.  The B-999 bomber has a hydraulic subsystem and a wing attitude
control subsystem.  The wing attitude control subsystem uses a hydraulic
lifter.  This component is functionally part of two different subsystems.
A good CM system (hardware or software) must be able to deal with 
multiple interlocking subsystems.

	Version control is an important part of CM.  Since terminology
is often confused in this area, let me distinguish between file version
control, and configuration version control.  Tools such as SCCS and RCS
are file version control tools.  If you build a CM version control system
on top of file version control tools you run into problems if the elements
of your configuration are procedures.  These problems can be addressed,
but things can get sticky if they aren't.

	As to best practice, my rule is that the one file/one procedure
rule should be followed _except_ when you have a group of procedures which
forms an atomic package.  In that case, the file should bear the name of
one of the procedures in the package.  There are a number of principles
that one should follow in setting up such packages, but that is another
issue.

	I hope this is some help.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.