Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!cpp
From: cpp@sei.cmu.edu (Charles Plinta)
Newsgroups: comp.object
Subject: Re: Overused metaphors - Software ICs, etc.
Message-ID: <8190@fy.sei.cmu.edu>
Date: 9 Aug 90 18:56:27 GMT
References: <23915@nigel.udel.EDU> <2088@esunix.UUCP> <5436@stpstn.UUCP> <4078@kim>
Organization: Carnegie-Mellon University (Software Engineering Institute), Pgh, PA
Lines: 153

In article <5427@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: 
 >Although I don't quibble with your analysis, I quail everytime I hear
 >that the software community has revved up another language standardization
 >hoo ha. We have *got* to be the only group in the universe that
 >standardizes our *processes* (languages, methodologies) but never
 >gets around to standardizing the *products* of those processes 
 >(Stacks, Queues, etc). Its as if the hardware community standardized
 >their wave solder machines expecting to avoid the need for standard 
 >bus structures.

I agree.  I'm not exactly sure why focus seems to be on standardization of
process instead of product.  It might have something to do with the
"products" being software, which, in and of itself, can be "easily"
modified.  This is quite different from products produced by other
disciplines (engines, chips and circuit boards, bridges, etc.).  But none
the less, it is no excuse.  I realize this is Comp.object, and I risk
getting shot at by making the following statements, but here goes anyway:

   
    The current craft of developing software-dependent systems will begin 
    to move towards an engineering discipline only when the craftsmen and 
    craftswomen begin to capture and quantify their products.  

    Only when their products are quantified will the steps of defining the
    process, monitoring the process, and refining the process make sense.
    Processes are based on producing products to me it doesn't make sense 
    to define a process until I know what my product will look like.

    Quantifying products will also allow companies to develop systems 
    more effectively within the context of their "product line".
    
    Also, then tools can be made to help automate the production process.  
    Look at some of the CAE tools.  They help the engineer layout a board 
    design based on the components available and the manner in which they 
    can be connected.

Also, products such as nuts and bolts (stacks and queues) are not 
the products I'm talking about.  Engineers designing a car, a bridge, 
or the next generation fighter, do not start with nuts and bolts.  They 
have higher level concepts/components available to them.  These concepts 
are present in the "standard" architecture, and this tends to be their 
starting point.  For example, cars are not designed from scratch each year.
A basic architecture is chosen, and some aspects of the car are enhanced
or changed.  

Even something as different looking as the B-2 is a variation of the standard
bomber architecture.  It still has a hydraulic system, electrical system,
etc., but they modified the design to optimize it based on the 
characteristics of the aircraft desired by the customer.
  1. minimal cross section (radar)
  2. minimal IR signature
These factors affected airframe (wings and fuselage) of the final product,
and thus the unconventional look.  These are probably just a few the
optimizations made to the design which characterize the B-2, and they are
the most obvious.

In article <4078@kim>, kim@spock (Kim Letkeman) writes:
 >In article <5436@stpstn.UUCP>, cox@stpstn.UUCP (Brad Cox) writes:
 >| In article <2088@esunix.UUCP: rtrosper@esunix.UUCP (Robert Trosper)writes:
 >| :
 >| :Well - not to beat a dying horse. Let the Software IC myth go quietly
 >| :into it's own good night. Useless things all go there anyway.
 >| :
 >| :				Robert Trosper
 >| 
 >| My crystal ball is no better than anyone else's. But just bear in mind 
 >| that it was the cottage industry gunsmiths, and not interchangeable parts,
 >| that were discovered to be useless during the industrial revolution.
 >
 >Hmmm ... I would suggest that during the industrial revolution the
 >cottage industry gunsmiths were merely replaced by more advanced and
 >efficient methods, not by a plethora of interchangeable parts. 

But the key here is that a product existed around which the process for
producing them could be defined.  I wonder if the "baseline" product
produced by the craftsmen was optimized to allow mass production and to
allow it to easily be fixed in the field (interchangeable parts).  Were these
the major design considerations for optimizing the baseline product design.
I also wonder which came first, product design or process definition.


In article <4078@kim>, kim@spock (Kim Letkeman) writes:
 >In many of these "paradigm shift" or "software IC" or "product versus
 >process" arguments, the basis is a flawed analogy. One simply cannot
 >compare the extremely complex software creation process with anything
 >that is manufactured in the more traditional sense.

I'm not totally aware of all these arguments, but I do not agree with the
statement that the software creation process or products are inherently
complex.  Using current "roll your own" or "nut and bolt" techniques, the
creation process and products are obviously going to be complex.  Can you
imagine a bridge architect, not knowing about suspension bridges, or post
and beam styles, etc., being given a pile of nuts, bolts, beams, cables, etc
and being given a set of requirements to span a valley for vehicle movement
purposes with a set of parameters describing peak and average loading, wind
factors, etc.  I can imagine the product and process used to build it would
seem complex to the "untrained" eye (i.e., anyone who had not seen such a
structure, or seen such a structure built before).  This is my approximation
of where software-dependent systems development currently stands, and it will
not get better as long as the focus is on process, managing complexity, and
"small" products.

To advance, we need to reduce complexity.  I have seen instances where 
complexity has been reduced by focusing on the patterns of entities and
activities that exist in the environment in which a system must exist.
In this manner, the system architecture can be expressed with a minimum 
number of architectural elements.  For example:
  * a house has doors, windows, rooms, roof, etc.  A specific house has a 
    specific configuration of these architectural elements.  

  * a C3 (command, control, and communications) system has 
    message translator and validators, journalors, report generators, 
    message analyzers, database managers, graphic generators, table 
    generators, etc.
      [This is based on our work examining C3 system requirements]
    A specific C3 system has a specific configuration of these 
    architectural elements based on the messages that need to be processed, 
    the specific processing (algorithms) that needs to occur to support the 
    mission, the graphic that need to be displayed to allow the user to 
    carry out the mission, etc.

To advance, we need to strive for standard products. I have seen instances
where general, customizable products have been produced that are "larger"
than stacks and queues.  For the C3 system architecture mentioned above, we
have created a model solution for the message translator and validator
architectural element, so when this architectural element appears in the
design, there is at least one implementation that can be used.  We have
experimented with other model solutions for the architectural elements
listed above, to the point that we are convinced that model solutions for
all architectural elements are feasible, and that these model solutions are
scalable or customizable for a specific C3 system.  By scalable or
customizable, I mean in the sense that a bolt is a bolt, it is a fastener,
whether it is a 1/4-20 (1/4 inch diameter and 20 threads per inch) or
5/16-32, whether it has a #1 phillips, #2 phillips, slotted, or hexagonal
head, and whether it is made of steel, aluminum, or some alloy.  
All these variations on the bolt are merely optimizations and tradeoffs made 
for strength, cost, weight, etc.
In a lager sense, a suspension bridge is a scalable model also and these
have been quantified to the point that the driving characteristics of a
suspension bridge have been isolated, the equations captured, and computer
programs written to accept the characteristics (span, avg/peak weight, wind,
etc.) and produce the design and parts lists.

Finally, only after a product architecture (C3 architecture) is quantified
can we begin to define processes for producing the product, refining the
product, and define and develop tools for automating the process.


Chuck Plinta

  [ as an aside, a picture is worth a thousand words, and I have a few that ]
  [ would make my arguments above clearer and more understandable.          ]
  [ So, when will we be able to post text and graphics?                     ]