From: eberard@bse.com (Edward V. Berard)
Newsgroups: comp.object
Subject: Re: Domain Analysis references
Date: Mon, 11 Jan 93 07:43:24 EDT
Organization: Berard Software Engineering, Inc.
Reply-To: eberard@bse.com (Edward V. Berard)
Distribution: world
Keywords: object-oriented domain analysis
Summary: reusability
X-Mailer: uAccess - Macintosh Release: 1.6v1


In article <C0HLCu.JxM@world.std.com> (comp.object), ematz@world.std.com (Ed Matz) writes:
> 
> Not sure if this is the appropriate newsgroup to post this query,
> but I encountered the term while doing some reading on the subject
> of OOA/OOD.   Can anyone out there provide me with some references
> to Domain Analysis so I can find out what it is?   Just about all
> I know about it is its name, but it sounds intrigueing . . .
> 

Years ago I posted the following article to comp.object. An updated version
of the article appears as chapter 10 in my book, "Essays on Object-Oriented
Software Engineering, Volume 1," published by Prentice Hall (ISBN 0-13-288895-5).

I hope this helps.

				-- Ed

----------------------------------------


			       PROLOGUE

If you were to ask a good number of people why they were using, or
were seriously thinking about using, an object-oriented approach to
software engineering, you would get responses such as:

	- enhanced interoperability,

	- software solutions which are easily modified and extended,

	- simpler, more straightforward solutions, and 

	- better suitability for real-time systems.

However, probably the most common answer would be: enhanced reusability.

Like object-orientation, software reusability is very much
misunderstood. Many people think that the pinnacle of software reuse
is a "library of math functions." What most software professionals do
not realize is that software reusability, like object-orientation,
impacts everything, from management practices to software development
standards, and much more.

			 SOFTWARE REUSABILITY

	"Software components (routines), to be widely acceptable to
	different machines and users, should be available in families
	arranged according to precision, robustness, generality and
	time-space performance. Existing sources of components --
	manufacturers, software houses, users' groups and algorithm
	collections -- lack the breadth of interest or coherence of
	purpose to assemble more than one or two members of such
	families, yet software production in the large would be
	enormously helped by the availability of spectra of high
	quality routines, quite as mechanical design is abetted by the
	existence of families of structural shapes, screws, or
	resistors."

	-- Doug McIlroy (in [Naur and Randell, 1969])

	"Specialists in every part of software have a curious vision
	of the world: All parts of software but his are simple and
	easily parameterized; his is totally variable."

	-- A. J. Perlis (in [Naur and Randell, 1969])

	"In talking about the implementation of software components,
	the whole concept of how one designs software is ignored. Yet
	this is the key thing."

	-- K. Kolence (in [Naur and Randell, 1969])

	"A comparison with our hardware colleagues is relevant."

	-- Peter Naur (in [Naur and Randell, 1969])

	"Reusable code is taken seriously in Japan and should be here
	too. ... To me this is the most important branching point. In
	the long run, it will determine which companies will stay in
	business and which ones won't."

	-- Capers Jones (_ComputerWorld_, November 24, 1986, page 19)

	"The results of a California study proved that software
	systems are highly redundant, with 75% of the application
	code, 50% of the systems programs and 70% of
	telecommunications programs sharing identical code or
	functions."

	-- News item from _ComputerWorld_, November 24, 1986, page 19

One of my primary areas of interest is software reusability. I have
conducted research on, taught courses about, and developed products
using, software reusability technology. Here are some of the things I
found:

	- Software practitioners often incorrectly limit their
	  definition of "software" to source code and object code. In
	  truth, software includes such things as:

		- code fragments

		- modules, i.e.:

			- subprograms, e.g., procedures, functions,
			  subroutines, paragraphs

			- larger collections, e.g., Smalltalk's
			  classes, Modula's modules, and Ada's
			  packages

		- large object-oriented entities, e.g., subsystems
		  ([Levy and Ripken, 1987] and [Rational, 1986])

		- scaffolding code (and documentation)

		- test data

		- plans, policies, standards, and procedures

		- products of analysis, design, and software quality
		  assurance efforts

	- Management and technical staff alike often avoid thinking
	  about software reuse until too late, i.e., the "coding
	  phase." They fail to realize that reusability impacts
	  everything including management, contracting and legal
	  issues, in-house development standards, and relationships
	  with subcontractors. (See, e.g., [Berard, 1987].)

	- Fortunately, delaying consideration of reusability issues
	  until the coding phase is far less disastrous than delaying
	  object-oriented considerations until the design and/or
	  coding phase.

	- Although many people pitch software reusability on the
	  grounds that it will "save money," both management and
	  technical staffers are seldom swayed by this argument --
	  even when presented with hard data to back up the argument.

	- Software reusability can have a very positive impact on
	  software reliability, software efficiency, and "time to
	  market."

	- Training is essential. Simply purchasing libraries of
	  reusable components (e.g., [Dusink and van Katwijk, 1987],
	  [Russell, 1987] and [Margono and Berard, 1987]) and/or
	  software reusability systems (e.g., [Burton et al, 1987])
	  does not guarantee their (proper) use.

	- The concepts of software reusability and object-oriented
	  technology are so intertwined that it is often difficult to
	  talk about one without mentioning the other, e.g., see
	  [Frankowski, 1986], [Johnson and Foote, 1988], [Meyer,
	  1987], [Schmucker, 1986], [St. Dennis et al, 1986], [Devanbu
	  and Bachman, 1989], and the panel ("Experiences With
	  Reusability") at the 1988 OOPSLA.

	- The major obstacles to software reusability are _not_
	  technical, they are primarily cultural. (See, e.g.,
	  [Carstensen, 1987] and [Tracz, 1987].)

		     DOMAIN ANALYSIS: DEFINITIONS

If you study software reusability for a little while, you will
probably encounter some discussion of "domain analysis." Here are two
alternative definitions of domain analysis:
		
	"An investigation of a specific application area that seeks to
	identify the operations, objects, and structures that commonly
	occur in software systems within this area."
		
	-- Dan McNicholl (in [Booch, 1987])

	"Systems analysis states what is done for a specific problem
	in a domain while domain analysis states what can be done in a
	range of problems in a domain. ... A domain analysis is only
	useful if many similar systems are to be built so that the
	cost of the domain analysis can be amortized over the cost of
	all the systems.
		
	"The key to reusable software is captured in domain analysis
	in that it stresses the reusability of analysis and design,
	not code."
		
	-- Jim Neighbors (in [Neighbors, 1980])

[Note Neighbors's emphasis on the importance of non-code software.
(See, also [Arango, 1989].)]

In essence, "domain" in domain analysis refers to "application
domain," e.g., graphical user interfaces, embedded missile
applications, and decision support systems. The reason you are
conducting an "analysis" is that you hope to identify reusable items
within the domain, i.e., items which may be reused to build new
applications which also fall within the same domain.

Grady Booch ([Booch, 1987]) offers the following definitions of
horizontal and vertical domain analysis:

	"A horizontal domain analysis studies a number of different
	systems across a variety of applications."

	"A vertical domain analysis studies a number of systems
	intended for the same class of applications."

There are different types of domain analysis beyond simple vertical
and horizontal approaches. In general, each type of domain analysis is
distinguished by the types of reusable items which are being sought,
e.g.:

	- "Functional domain analysis" seeks to identify reusable
	  items localized around functions, e.g., functions,
	  subroutines, procedures, and programs.

	- "Object-oriented domain analysis" seeks to identify reusable
	  items localized around objects e.g., classes, instances,
	  systems of objects, and subsystems.

			HISTORICAL BACKGROUND

Although the concept of domain analysis (like the concept of software
reusability) has been around for decades, probably the first work of
any significance in the area is documented in the doctoral thesis of
Jim Neighbors ([Neighbors, 1980]). It was not, however, until 1985
that the term "domain analysis" began showing up with any regularity
in the literature, e.g., [Adelson and Soloway, 1985].

By 1988-89, there were quite a few articles on domain analysis, e.g.,
[Iscoe, 1988], [Prieto-Diaz, 1988], and [Simos, 1988]. The way we
think about domain analysis has also changed. For example, by 1987
there was a recognized need for a formal approach to domain analysis
(e.g., [RMISE, 1987]), and by 1989, proposed "formal" approaches did
begin to appear (e.g., [Arango, 1989]).

In 1989, we began to see articles on object-oriented domain analysis.
The first of these articles is [Shlaer and Mellor, 1989].

In this article, I will present a very brief introduction to
object-oriented domain analysis. However, please note that, as with
object-oriented requirements analysis (OORA) and object-oriented
design (OOD), there is more than one school of thought on the process.

	     DOMAIN ANALYSIS IS NOT A LIFE-CYCLE ACTIVITY

One of the first items one encounters in the study of domain analysis,
is that it is _not_ a life-cycle activity. Specifically, an overall
domain analysis effort goes on _in_ _parallel_ with the software
life-cycles for the products which an organization produces and
maintains. As we will see shortly, there is a synergistic relationship
between the overall domain analysis effort and individual software
projects.

Christine Youngblut (in [Booch, 1987]) details some of the reasons for
keeping domain analysis separate from any specific project:

	- "When a component is developed in the context of some
	  system, it is difficult to abstract from the concerns of
	  that system to produce a truly flexible, unbiased
	  component."

	- "The additional requirements of a reusable component
	  (increased quality assurance, testing, flexibility, etc.)
	  mean that it is more expensive to produce than other
	  components, and this may not have been allowed for in the
	  project budgets and schedules."

	- "It may be difficult to recognize that a particular part is
	  highly reusable, and so many potentially useful components
	  may be ignored."

The relationship between the domain analysis effort and a given
project is fairly simple:

	- the project may use components identified, created,
	  documented, tested, and quality assured by the domain
	  analysis effort. (These components, along with any necessary
	  supporting documentation, are placed in the organization's
	  component library.)

	- the domain analysis effort interacts with specific projects
	  to identify potentially reusable items which have been
	  produced as a result of development or modification efforts.
		
		       WHAT IS A DOMAIN ANALYST

One of the rarest species of software professional is the domain
analyst. The reason for their rarity is that they must
_simultaneously_ possess all of the following characteristics:

	- They must be familiar with the specific application domain.
	  (This is a fairly easy requirement.)

	- They must be familiar with the concepts, ideas, or objects
	  which are to be considered for reuse. (If the domain analyst
	  is familiar with the application domain but does not have a
	  fundamental understanding of object-oriented concepts, he or
	  she will not be able to easily recognize an object when he
	  or she sees one.)

	- They must have excellent abstraction skills. (Any analyst
	  must be able to distinguish the general from the specific,
	  and between concepts and implementations.)

	- They must be versed in software reusability technology.
	  (Software reusability technology is _not_ trivial. For
	  example, can the analyst examine an object in isolation and
	  systematically determine if the object possesses a complete
	  set of operations, constants, and exceptions?)

			    STEPS IN OODA

Oversimplifying, the steps in an OODA effort are:

	- Define the domain

	- Define the types of objects which are to be considered for
	  reuse within the defined domain

	- Collect a representative sample of applications found in the
	  defined domain

	- Analyze the representative applications to identify reusable
	  components

	- Define reusability guidelines regarding the reusable components

	- Demonstrate reuse using the reusable components and the guidelines

	- Make recommendations

[Truth in advertising: True domain analysis is a never-ending process.
Specifically, as long as an organization continues to develop and/or
maintain software applications, the domain analysis effort will remain
active. We will describe the steps here as if they were indeed
sequential, however, in practice, each of these steps is more like an
on-going activity.]

In the following discussions, "object" can be taken to mean one, or
more, of the following: class, instance, metaclass, metaobject,
subsystem, and system of objects.

			 DEFINING THE DOMAIN

It is useful to define each domain as narrowly and as quantitatively
as possible, because:

	- Identification of candidate applications which fall (or will
	  fall) within the domain will be easier.

	- Separation of domain-specific reusable objects from
	  non-domain-specific reusable objects will be easier.

	- In general, analysis of the domain, and the resulting
	  conclusions will be more meaningful.

	      DEFINING THE OBJECTS WHICH WILL BE REUSED

To perform an adequate analysis, you must know the characteristics of
the objects which you are trying to identify. The object-oriented
domain analyst will have to deal with the following:

	- Original identification of the objects (For example, this
	  may require some object decoupling.)

	- Nomenclature (Once you find it, what are you going to call
	  it?)

	- Identification of hierarchies, sets, or other
	  organizations, (e.g., subclass-superclass relationships,
	  partial types, and subsystems.)

	- Configuration management (How will the reusable objects,
	  and information relating to the reusable objects, be
	  tracked?)

	  COLLECTING A REPRESENTATIVE SAMPLE OF APPLICATIONS

This is a continually on-going effort and requires a careful analysis.
The following must be considered:

	- Are the applications in the sample truly representative of
	  the applications in the domain, e.g., types, sizes, and
	  languages?

	- What is the likelihood that the applications in the sample
	  contain a representative collection of reusable objects?

	- Is there a high probability that future applications within
	  the domain will have the same characteristics?

[Note: When an organization first begins to use object-oriented
technology, it is quite likely that any previously-existing
applications were _not_ created in an object-oriented manner. Hence,
the analysis of existing applications will require that the
object-oriented domain analyst identify the _conceptual_ (as opposed
to _physical_) objects in each application.]

			ANALYSIS OF THE SAMPLE

During the analysis of the representative sample of applications, the
domain analyst must:

	- identify candidate reusable objects.

	- state why the objects are considered potentially reusable

	- identify variations on the objects which will also be
	  reusable

	- determine the percentage of a typical application which
	  might be constructed from the reusable objects

	- name, catalog, and otherwise apply configuration management
	  to the reusable objects

	- predict the relative usefulness of each object in terms of
	  future applications.

[Note: The most desirable form of reuse is reuse with _no_ changes.
Until they are properly trained, project software engineers will
probably _not_ be designing objects with reuse in mind. (Even after
they are properly trained, project management may not allow them the
resources (e.g., time) to correctly implement reusable objects.)
Therefore, the domain analysts should not expect to find "complete"
objects.More specifically, object-oriented domain analysts will often
be expected to ensure that each object represents a complete
abstraction. Further, the object-oriented domain analysts must make
sure that each reusable object receives the proper amount of testing
and quality assurance.]

		   DEFINING REUSABILITY GUIDELINES

The domain analyst must provide software engineers with a set of
meaningful guidelines for the reuse of the objects within the domain.
For example the analyst should identify the criteria used to select an
object for use in an application, and the trade-offs to be considered.

	  DEMONSTRATIONS OF REUSE USING THE REUSABLE OBJECTS

At least one representative example of an application constructed
using the reusable objects must be developed. (In truth, an on-going
series of sample applications will have to be constructed.) In
addition to the application itself, a report describing the the
experiences of the developers, and the characteristics of reuse within
the application must also be produced.

			MAKING RECOMMENDATIONS

Based on the guidelines, and on the results of the demonstration, the
domain analyst must provide recommendations for incorporating the
reusable objects into current and future projects. The recommendations
may also include recommendations for changes in life-cycle approaches,
policies, standards, and tools.

	      DOMAIN ANALYSIS AND LIFE-CYCLE ACTIVITIES

Software reusability is a key consideration during the object-oriented
life-cycle. The analyst must both reuse existing objects, _and_ create
new ones in such a way that they can be easily reused. Some of the
previously existing objects may very well have been created, not for
any specific project, but as a normal product of domain analysis.
		
Object-oriented requirements analysis (OORA) and object-oriented
design (OOD) are specific to a particular application within a domain.
These processes, however, benefit from domain analysis in a number of
ways:

	- Since domain analysis has already identified a number of
	  reusable objects within the domain, the analysts and the
	  designers can use this information to help guide the
	  analysis and design.

	- If done well, domain analysis will contribute significantly
	  to understanding how to design complete, robust objects.
		
	- If done well, domain analysis will have identified those
	  variations on an object that appear to be most useful within
	  the domain, e.g., concurrent forms.

	- Many of the same techniques used by the domain analyst can
	  be used by the analysts and designers to help identify the
	  objects within a specific application -- as well as helping
	  to understand the interactions of these objects.

As new applications are developed, new objects will be constantly
uncovered. New relationships among new, and existing, objects will
also be discovered. These new relationships will often suggest
different and useful variations on the existing library of objects. In
effect, the development and maintenance processes will be one of the
most effective "feedback" mechanisms for domain analysis.

As usual, my message runneth over. Please forgive the length. Thank
you for listening.

			     BIBLIOGRAPHY

[Adelson and Soloway, 1985]. B. Adelson and E. Soloway, "The Role of
Domain Experience in Software Design," IEEE Transactions on Software
Engineering, Vol. SE-11, No. 11, November 1985, pp. 1351 - 1360.

[Arango, 1989]. G. Arango, "Domain Analysis: From Art to Engineering
Discipline," Proceedings of the Fifth International Workshop On
Software Specification and Design, May 19-20, 1989, Pittsburgh,
Pennsylvania, IEEE Computer Society Press, Washington, D.C., May 1989,
pp. 152 - 159.

[Berard, 1987]. E.V. Berard, "Software Reusability Cannot Be
Considered in a Vacuum," Digest of Papers COMPCON, Spring 1987, IEEE
Catalog Number 87CH2409-1, Computer Society Order Number 764, Computer
Society Press of the IEEE, Washington, D.C., pp. 390 - 393.

[Booch, 1987]. G. Booch, Software Components With Ada,
Benjamin/Cummings, Menlo Park, California, 1987.

[Brown and Quanrud, 1988]. G.R. Brown and R.B. Quanrud, "The Generic
Architecture Approach to Reusable Software," Proceedings of the Sixth
National Conference on Ada Technology, March 14-18, 1988, U.S. Army
Communications-Electronics Command, Fort Monmouth, New Jersey, pp. 390
- 394.

[Burton et al, 1987]. B.A. Burton, R.W. Aragon, S.A. Bailey, K.D.
Koehler, and L. A. Mayes, "The Reusable Software Library," IEEE
Software, Vol. 4, No. 4, July 1987, pp. 25 - 33.

[Carstensen, 1987]. H.B. Carstensen, "A Real Example of Reusing Ada
Software," Proceedings of the Second National Conference on Software
Reusability and Maintainability, National Institute for Software
Quality and Productivity, Washington, D.C., March 1987, pp.  B-1 to
B-19.

[Chan, 1987]. Y.K. Chan, "Lessons in Software Reusability in Large
Complex Software Systems," Proceedings of the Conference on Software
Reusability and Portability, National Institute for Software Quality
and Productivity, Washington, D.C., September 16-17 1987, pp. B-1 to
B-7.

[Devanbu and Bachman, 1989]. P. Devanbu and R. Bachman, "OOPSLA
Workshop on Domain Modeling in Software Engineering," New Orleans,
Louisiana, 1989.

[Dusink and van Katwijk, 1987]. E.M. Dusink and J. van Katwijk,
"Reflections on Reusable Software and Software Components," Ada
Components: Libraries and Tools -- Proceedings of the Ada-Europe
International Conference, Stockholm 26-28 May 1987, Edited by S.
Tafvelin, Cambridge University Press, Cambridge, U.K., pp. 113 - 126.

[Fischer, 1987]. G. Fischer, "Cognitive View of Reuse and Redesign,"
IEEE Software, Vol. 4, No. 4, July 1987, pp. 60 - 72.

[Frankowski, 1986]. E. N. Frankowski. "Why Programs Built from
Reusable Software Should be Single Paradigm," Proceedings of the STARS
Reusability Workshop, March 24-27, 1986.

[Iscoe, 1988]. N. Iscoe, "Domain-Specific Reuse: An Object-Oriented
and Knowledge-Based Approach," in IEEE Tutorial: Software Reuse --
Emerging Technology, Edited by W. Tracz, IEEE Computer Society Press,
Washington, D.C., 1988.

[Johnson and Foote, 1988]. R. E. Johnson and B. Foote, "Designing
Reusable Classes," Journal of Object-Oriented Programming, Vol. 1, No.
2, June/July 1988, pp. 22 - 35.

[Kaiser and Garlan, 1987]. G.E. Kaiser and D. Garlan, "Melding
Software Systems from Reusable Building Blocks," IEEE Software, Vol.
4, No. 4, July 1987, pp. 17 - 24.

[Levy and Ripken, 1987]. P. Levy and K. Ripken, "Experience in
Constructing Ada Programs from Non-Trivial Reusable Modules," Ada
Components: Libraries and Tools -- Proceedings of the Ada-Europe
International Conference, Stockholm 26-28 May 1987, Edited by S.
Tafvelin, Cambridge University Press, Cambridge, U.K., pp. 100 - 112.

[Margono and Berard, 1987]. J. Margono and E.V. Berard, "A Modified
Booch's Taxonomy for Ada Generic Data-Structure Components and Their
Implementation," Ada Components: Libraries and Tools - Proceedings of
the Ada-Europe International Conference, Stockholm 26-28 May 1987,
Edited by S. Tafvelin, Cambridge University Press, Cambridge, U.K.,
pp. 61 - 74.

[Matsumoto, 1984]. Y. Matsumoto. "Some Experiences in Promoting
Reusable Software: Presentation in Higher Abstract Levels," IEEE
Transaction on Software Engineering, Vol. SE-10, No. 5, September
1984, pp. 502 - 513.

[Meyer, 1987]. B. Meyer, "Reusability: The Case for Object-Oriented
Design," IEEE Software, Vol. 4, No. 2, March 1987, pp. 50 - 64.

[Naur and Randell, 1969].  P. Naur and B. Randell, Editors, Software
Engineering: Report on a Conference Sponsored by the NATO Science
Committee, Garmisch, Germany, October 7-11, 1968.

[Neighbors, 1980]. J.M. Neighbors, "Software Construction Using
Components," Technical Report 160, Department of Information and
Computer Sciences, University of California, Irvine, 1980.

[Neighbors, 1984]. J.M. Neighbors, "The DRACO Approach to Constructing
Software From Reusable Components," IEEE Transactions on Software
Engineering, Vol. SE-10, No. 5, September 1984, pp. 564 - 574.

[Prieto-Diaz, 1988]. P. Prieto-Diaz, "Domain Analysis for
Reusability," in IEEE Tutorial: Software Reuse -- Emerging Technology,
Edited by W. Tracz, IEEE Computer Society Press, Washington, D.C.,
1988.

[RMISE, 1987]. Rocky Mountain Institute of Software Engineering,
Workshop on Software Reuse -- Participant Proceedings, October 1987.

[Rational, 1986]. Rational, Inc., Large-System Development and
Rational Subsystems, Document Control Number 6004, Rational, Inc.,
Mountain View, California, November, 1986.

[Reilly, 1987]. A. Reilly, "Roots of Reuse," IEEE Software, Vol. 4,
No. 1, January 1987, page 4.

[Russell, 1987]. G.E. Russell, "Experiences Implementing a Reusable
Data Structure Component Taxonomy," Proceedings of the Joint Ada
Conference, Fifth National Conference on Ada Technology and Washington
Ada Symposium, U.S. Army Communications-Electronics Command, Fort
Monmouth, New Jersey, pp. 8 - 18.

[Schmucker, 1986]. K.J. Schmucker, "Object Orientation," MacWorld,
Vol. 3, No. 11, November 1986, pp. 119 - 123.

[Shlaer and Mellor, 1989]. S. Shlaer and S.J. Mellor, "An
Object-Oriented Approach to Domain Analysis," Software Engineering
Notes, Vol. 14, No. 5, July 1989, pp. 66 - 77.

[Simos, 1988]. M.A. Simos, "The Domain-Oriented Software Life-Cycle:
Towards and Extended Process Model for Reusability," in IEEE Tutorial:
Software Reuse -- Emerging Technology, Edited by W. Tracz, IEEE
Computer Society Press, Washington, D.C., 1988.

[St. Dennis et al, 1986]. R. St. Dennis, P. Stachour, E. Frankowski,
and E. Onuegbe, "Measurable Characteristics of Reusable Ada
Software,"Ada Letters, Vol. VI, No. 2, March-April 1986, pp. 41 - 50.

[Standish, 1984]. T. A. Standish. "An Essay on Software Reuse," IEEE
Transaction on Software Engineering, Vol. SE-10, No. 5, September
1984, pp. 494-497.

[Tracz, 1987]. W. Tracz, "Software Reuse: Motivators and Inhibitors,"
Digest of Papers COMPCON, Spring 1987, IEEE Catalog Number 87CH2409-1,
Computer Society Order Number 764, Computer Society Press of the IEEE,
Washington, D.C., 1987.

[Woodfield et al, 1987]. S.N. Woodfield, D.W. Embley, and D.T. Scott,
"Can Programmers Reuse Software?," IEEE Software, Vol. 4, No. 4, July
1987, pp. 52 - 59.

----------------------------------------------------------------------------
Edward V. Berard                                | Phone: (301) 417-9884
Berard Software Engineering, Inc.               | FAX:   (301) 417-0021
101 Lake Forest Blvd., Suite 360                | E-Mail: eberard@bse.com
Gaithersburg, Maryland 20877                    | 
----------------------------------------------------------------------------
Newsgroups: comp.object