From: hawkinsg@saifr00.cfsat.honeywell.com (Glenn Hawkins)
Subject: Controlling Type Definition - Is it useful/necessary?
Organization: Honeywell Air Transport Systems Division
Distribution: comp.ada
Date: Thu, 10 Sep 92 16:25:50 GMT

Howdy!

I am a software engineer working on the Boeing 777 avionics suite at
Honeywell in Phoenix, and I have a question about an aspect of the design
process with Ada that I've been wondering about for some time now.  It's quite
possible that I'm missing a basic concept that would make this
question completely unnecessary.  If so, please feel free to set me straight.
Otherwise, any help would be greatly appreciated on the following subject:

We have completed our OORA and are now in the early stages of preliminary 
design (class to package/type transformation, final selector/constructor
definition, etc.) and are trying to figure out a process to rigorously control
the definition and placement of types throughout the system.  I know on my old 
program (pre-Honeywell) that engineers, once they got below the specification 
level, were allowed to define types and subtypes willy nilly, with the result 
that during system integration an incredible number of type incompatibility 
problems such as lost accuracy, constraint errors, and the like occurred.  It
was also pretty difficult to maintain.  We always swore to ourselves, that, if
we had it to do over again, we would establish rigorous controls over the 
definition of types in a system to avoid people stepping on each other 
(or on themselves, in many cases). 

I might interject here that many of you may have already decided that 
we did not properly encapsulate our abstractions in the past if we could "step
all over each other" - i.e. we did not do a "good" Ada design.  This is entirely
possible.  However, in our current design (using OOA/OOD methods) I feel that
we have a very good system architecture, and yet I can see the possibility
of sloppy type definitions (and the resulting side effects) severely impacting
our integration effort if we are not careful.  The big, "important" types are
defined and in a sense controlled by the interface contracts (Ada specs) we 
have developed as part of our requirements analysis.  Pre and post conditions,
visibility issues, dependencies, etc. have all been worked out in the OORA.
I'm talking about the local types down in the bodies that are defined on the
fly at 3:00 am by the designer who just wants to get SOMETHING to compile for
the inspection package due the next day.  NOT the right way to code, I know, 
but it happens!

So, all you Ada gurus out there - How do you control the proliferation of 
type definitions in a large (>10,000 Ada SLOC) system?  Do you even need to?  
Does a "good" Ada design avoid all these problems for you?  What guidelines 
exist for the definition and placement of "non-major" (not externally visible?)
Ada types in a well-designed system?

Specifically, are there any efficient process steps that you can take 
that are cheap (in terms of overhead) and easy (so the designers won't mind
doing them) in order to evaluate ALL types/subtypes in the system in terms of:

	a) Is it really needed?
	b) Does anyone else need it (is this the right place for it)?
	c) Does it cause problems "up the ladder" (i.e. violate an 
		abstraction/encapsulation)?
	d) Has it already been defined?

I'd be happy to post a summary of all responses received through E-mail.

                   N.B. - ALL flames will be cheerfully ignored.

with STANDARD_DISCLAIMER; 

Glenn Hawkins
Senior Project Engineer
Honeywell, Inc.
Air Transport Systems Division
Phoenix, AZ

"You can put lipstick on a hog and call it Monique and it's STILL a pig".
--Ann Richards, Governor of Texas

"hawkinsg@saifr00.cfsat.honeywell.com"
Newsgroups: comp.lang.ada