\markboth{Dunn}{Dunn}
%%%%%% TEMPLATE.TEX for WISR'93, version 1.2, 4/22/93 %%%%%%
%%%%%% Updated by Jeffrey S. Poulin, May 1993         %%%%%%

\documentstyle[11pt]{article}

% Standard Spacing for WISR - do not change!!
%
% Page dimensions.
%
\oddsidemargin  0.26in % Leave enough for binding margin
\evensidemargin 0.26in %
\topmargin      -1.00in % (adjusted for printer bias)
\headheight      .00in  % (no headers)
\headsep         .75in  % (top margin + headers + skip)
\footheight     12.0pt  % ??? (seems to work ok)
\footskip       25.0pt  % ??? ( "   "  )
\textheight     9.425in % (instructions: 9 1/8" min, 9 7/16" max)
\textwidth      6.5in   %

\markboth{Dunn}{Dunn}
\pagestyle{myheadings}
%
% Paragraph changes.
%
\parindent=0pt
\parskip=10pt
%
% can make the title box even smaller
%
\def\@maketitle{\vbox to 2.6in{\hsize\textwidth
    \linewidth\hsize \vfil \centering
    {\large \@title \par}
    \vskip 2em
    {\normalsize
    \begin{tabular}[t]{c}\@author
    \end{tabular}\par}
    \vfil}
}

\begin{document}

\bibliographystyle{ieeetr}

\title{Creating And Using An Industrial Domain Model \footnote{We thank
Motorola, Inc. for their generous financial and technical support for
this research.}}

\author{Michael F. Dunn\\
\\
Industrial Software Technology\\
Earlysville, VA  22936\\
Tel: (804) 978-7475\\
Email: mfd3k@virginia.edu\\
\and
John C. Knight\\
\\
University of Virginia\\
Charlottesville, VA  22903\\
Tel: (804) 982-2216\\
Email: knight@virginia.edu\\
}

\date{}

\maketitle

\begin{abstract}
A successful reuse process requires a set of well-understood domain models.
Creating these models, however, can be an extremely difficult task, requiring
a great deal of information-gathering and formatting. In this paper, we
discuss two aspects of a method we have been developing to cope with these
complexities. First, we discuss our work in devising a method
by which unstructured domain information can be gathered. Second, we discuss
the format
in which we capture domain knowledge, and how this knowledge can then be
used. The challenges we have encountered while using this method in an
industrial environment are also discussed.

\vspace{0.2in}
\noindent
{\bf Keywords:} Reuse, domain analysis, domain modeling, practice.

\vspace{0.2in}
\noindent
{\bf Workshop Goals:} Learning; networking; sharing domain modeling experience.


\vspace{0.2in}
\noindent
{\bf Working Groups:} Domain analysis/engineering, Reusable component
certification, Tools and environments.

\end{abstract}

\newpage

\section{Background}

Domain analysis and modeling are generally agreed to be crucial first steps
to developing an organized software reuse process. The abstract nature of
these two
processes, however, has been a major source of difficulty for organizations
considering introducing reuse.

The authors' involvement in domain analysis and modeling stems not only from
an interest
in facilitating component-based reuse processes, but also from a desire to
create
a framework by which components can be certified. Once a cohesive model is
created
for a family of systems built by an organization, the quality criteria to
which each family
member must adhere can be identified.

\section{Position}

\subsection{Introduction}

Performing a domain analysis can
require an arduous amount of work; it usually requires sifting through
often-incomplete
system documentation, examining large sections of application code, and
interviewing
busy technical experts. This diverse, unstructured information must then be
tied
together into a cohesive model.
A complicating factor is the issue of who should
perform the analysis. If the analysis is performed by one who is unfamiliar
with the
domain, then it is often difficult for that person to distinguish what
domain information is important from a reuse standpoint. Consequently, the
analyst
is often required to become a domain expert in his own right in order to do an
adequate job. However, a similar situation can exist when a domain expert
performs the analysis. The expert can have such detailed knowledge of the
domain
that he might have a tendency to add too much information to the analysis,
clouding the resulting model. Also, the expert will often have a tendency to
carry a great deal of conceptual baggage from previous system implementations,
constraining the analysis to information on how systems have been built in the
past, rather than on how they should be built under a reuse-based process.

Creating a domain model based on the information gathered during the domain
analysis
is also a major hurdle. The first problem is a carry-over from the domain
analysis:
namely, determining what domain knowledge is important enough to include in
the model, and
what information should be discarded. The second issue is that of structuring
the
model for maximum usefulness. A domain model which includes
useful information but which is not formatted carefully will be difficult to
use and
end up on the engineer's shelf.

The authors have recently been involved with a domain modeling project with a
large industrial organization, where these issues came to the forefront. A
major
part of this project was to devise a "domain modeling cookbook", that is, a
generic process for performing a domain analysis, and capturing that
information
in a standardized format. The goal was for this process to be flexible enough
to be used by any industrial organization, but rigorous enough that it was
clear
what information is important, and how that information should be organized.
The next several sections describe the results of this work, and the insights
gained.

\subsection{Performing A Domain Analysis}

The organization with which we collaborated was responsible for developing
test harnesses
for the software that drives telephone switches manufactured by the company.
The
organization is staffed by about twenty-five software engineers, and is
responsible
for about ten large test tools.

Much of the up-front analysis work was based on the results of a questionnaire
completed
by the organzation's technical staff. This questionnaire was intended to
introduce the
analysts to the organization's mission, product line, current development
process, current
tools and methods to support their process, and current status of their reuse
activities. The
questionnaire was a necessary first step in large part because of the physical
distance
separating the analysts and the programmer community. The two groups were
several
hundred miles away from each other, making it necessary to coordinate the
initial
analysis effort by telephone, email, and occasional site visits.

The answers provided to the questionnaire laid the foundation for the work
performed during
the on-site visits. During these visits, meetings were held with members of
the technical
staff, management, process control, and quality assurance areas. This gave a
balanced
view of the overall sofware production environment. Although the
organization's customers
were not included in the discussions,
it also would have
been useful to get insights into the customer's current needs, how these needs
are
likely to change over time, and how these needs would impact the set of
reusable
assets the organization should have available.

Nevertheless, the content of the meetings with the technical staff was most
revealing.
The discussions
focused on the following areas:

\begin{itemize}
\item The technical requirements of the product line.
\item The decomposition of the domain into its subdomains.
\item Common terminology used within the subdomains.
\item The generic requirements of systems used within the subdomains.
\item The set of components required to support systems built within these
subdomains.
\end{itemize}

As a result of these discussions, a number of issues came to light:

\begin{description}
\item[{\bf Terminology:}] Members of the technical community often disagree on
the meaning of common
terms used within a particular domain, even those used on a daily basis. The
term "test case", for example, a central concept in this domain, changes its
meaning
depending on the level and type of testing being performed. Thus, two
engineers are
likely to have a completely different notion of what constitutes a test case
depending on
the types of systems with which they are familiar.
This highlights the importance of establishing working definitions for basic
domain
concepts before attempting to gather detailed domain knowledge.

\item[{\bf Focus:}] Different participants often have a different perspective
on what is important to
the domain. Their perspectives are
dictated, in large part, by the projects in which they have participated most
recently.
 Thus, information-gathering sessions can easily turn into debates over
technical
side-issues unless the moderator maintains a clear focus. However, if the
moderator is not familiar with the domain in question, it can be hard for him
to realize
when the discussion is going astray.

\item[{\bf Cohesive Viewpoint:}] This issue is closely affiliated with the
previous issue. While
staff members have typically worked with several different system
implementations, they
often will not have a cohesive view of the similarities and differences
between these
systems, and the major functional aspects of these systems. This makes it
difficult
to identify broad categories of useful components. This tendency to get lost
in the details makes a case for using an analyst who is not a domain expert,
since he will only have a high level view, free of extraneous details.

\end{description}

In addition to questionnaires and interviews, strategic planning documents,
system user guides, and a limited amount of source code analysis also proved
useful in providing a picture of the domain's structure.

\subsection{Purposes of a Domain Model}

The main purpose of a domain model is not simply to determine the set of
reusable parts
needed to support a model, it is also to create a conceptual framework in
which these
components can be used. This means creating a generic model that captures the
salient features of systems developed within the domain. An example of such a
generic
model is the one often used to explain the five phases of program compilation:
lexing,
parsing, semantic analysis, code generation, and optimization. Most compilers
are not
literally implemented with these phases in sequence, but the conceptual model
gives
implementers an idea of the basic features that need to be included in any
compiler.

Other purposes of a domain model include:

\begin{itemize}
\item To serve as a basis from which component certification criteria can be
derived.
\item To help the organization determine which aspects of the domain are best
served by
using software components, by using domain-specific languages, or by using
application generators.
\item To help the organization determine which aspects of its development
process are
best served by reuse, and which are best served by other tools and process
improvements.
\item To highlight to the organization the specific factors that will
influence the set of parts
needed for future development. This can include changes to the product line,
changes
in available technology, and changes in the organization's mission.
\end{itemize}

\subsection{Structure And Use Of The Domain Model Document}

We structured the domain model document so that the organizational factors,
process and tool
factors, and domain-specific factors of the domain were made explicit.
The goal was to provide not only a model of the systems supported and
developed by the organization, but also to provide insight into how they could
be
developed using components, and what cost savings could be expected.
Consequently,
the document includes the following main sections:

\begin{description}

\item[{\bf Terminology:}] This section defines the basic words and phrases
used within
the domain.

\item[{\bf Mission and Strategy:}] This section describes the customer goals
which the
software organization is commissioned to fulfill. It also highlights the
potential changes
in the customer community that might affect these needs. A change in product
line,
for example, would necessitate changes in software, which would necessitate the
development of new software components.
For each specified goal,
either a  set of reusable assets is listed that can satisfy the goal, or a set
of process
improvements is listed that can better serve the goal.

\item[{\bf Process:}] This section describes the development process the
organization
can use to facilitate creating its target systems. The description includes
the stages
to be used in the development process, and the roles of the participants in
the process.

\item[{\bf Technological Infrastructure:}] This section describes the set of
tools needed
to support the development process, and maps tools to desired lifecycle work
products.

\item[{\bf Domain Model:}] This section,
which is the central part of the document, describes the generic models of
systems
developed within the domain. Each model is broken into subdomains, such as
user interface or report generation. Each subdomain is then broken into
different
implementation models. For example, the subdomain of "user interfaces"  would
include such implementation models as graphical user interfaces and
command-line
interfaces. Each implementation model is then broken into a description of the
model, the trade-offs of using the model within this domain, the possible
failures
that can occur as a result of using this model, systems that have already been
implemented by the organization that use this model, and a list of potential
components that have been or can be developed to support this model.

\item[{\bf Certification Criteria:}] Identifies the criteria to be used in
certifying the
components identified for the implementation models. The format used here is
described
by Dunn and Knight \cite{dk92}.

\item[{\bf Financial Justification:}] Identifies the financial costs and
benefits that
can accrue from the development of the identified reusable assets, and includes
a schedule for implementing the assets prioritized according to immediacy of
need
and highest financial benefit.

\end{description}

\section{Comparison}

Our method currently relies heavily on manual effort and discussions with
experts.
By contrast, Iscoe describes a process developed by EDS that relies
heavily on automated information gathering techniques \cite{iscoe93}.
This process takes as input
source code, formal models, and other development assets, and produces sets of
"specification models". Human expertise is used only to resolve ambiguity.

Tracz provides a comparison of a number of different approaches to domain
analysis
and modeling \cite{tracz92}. Our experience bears out most of the observations
noted about the similarities between these different approaches. Specifically,
\begin{itemize}
\item One of
our end results was a design model for the domain,
\item We assumed the existence of
previously developed systems within the domain,
\item The resulting model did imply the
existence of a layered underlying implementation architecture,
\item The process
we used was highly iterative.
\end{itemize}

A significant part of the Software Productivity Consortium's (SPC) Synthesis
process involves
specifying tailorable requirements documentation, and creating specific source
code
components to fit those requirements \cite{spc90}.
The SPC's domain analysis process has three parts - development of  a
conceptual framework for the domain, development of a reuse
architecture, and development of product composition mappings. In spite of the
differences between these phases and the ones described in this paper,
the desired end products of the two processes are quite similar -
identification of
specific software assets, and development of generic system models and
specifications.

\bibliography{dunn}

\section{Biography}

{\bf Michael F. Dunn} is an independent consultant specializing in software
reuse, especially domain analysis and asset certification issues. He has
worked as both a practitioner and researcher in reuse-related topics
for the past several years, and has been associated with companies as
diverse as IBM, Sperry-Marine, and Motorola.
He
received his B.S. in Computer Science in 1985 from Duke University, and
his M.S. in Computer Science in 1990 from the University of Virginia.

{\bf John C. Knight} is a professor of Computer Science at
the University of Virginia.
He joined the University of Virginia in 1981 and prior to that
was with NASA's Langley Research Center.
>From 1987 to 1989 he was on leave at the Software Productivity
Consortium.
His research interests are in dependable computing and software reuse.

\end{document}

%%%%%% TEMPLATE.BIB for WISR'92, version 1.0, 6/26/92 %%%%%%

@techReport(lubars90,
AUTHOR="M.D. Lubars",
INSTITUTION="Microelectronics and Computer Technology Corporation",
KEY="Lubars",
TITLE="{The ROSE-2 Strategies for Supporting High-Level Software Design Reuse}"
,
YEAR="1990",
Number="STP-303-90")

@techReport(basili91,
Key="Basili",
Author="V.R. Basili and H.D. Rombach",
Title="{Support for Comprehensive Reuse}",
Number="UMIACS-TR-91-23",
Year="1991",  Month="February", Address="College Park, Md.",
Institution="University of Maryland")

@article(frakes90,
Key="Frakes",
Author="W.B. Frakes and P.B. Gandel",
Title="{Representing Reusable Software}",
Year="1990", Month="December",
Volume="32", Number="10",
PAges="653-664",
Journal="Information and Software Technology")

@TechReport(tracz92a,
Key="Tracz",
Author="W. Tracz and L. Coglianese",
Title="{Domain Engineering Process Guidelines}",
Year="1992", Month="March",
Institution="IBM Federal Sector Division",
Number="ADAGE-IBM-92-02")

@TechReport(prieto-diaz91d,
Key="PrietoDiaz",
Author="R. Prieto-Diaz",
Title="{Reuse Library Process Model}",
Year="1991", Month="July",
Institution="STARS",
Number="AD-B157091, IBM CDRL 03041-002")

@TechReport(kang90,
Key="Kang",
Author="K.C. Kang and S.G. Cohen and J.A. Hess and W.E. Novak and A.S. Peterson
",
Title="{Feature-Oriented Domain Analysis (FODA) Feasibility Study}",
Year="1990", Month="November",
Institution="Software Engineering Institute",
Number="CMU/SEI-90-TR-21")

@Article(kaneko86a,
Key="Kaneko",
Pages="11-14",
Author="S. Kaneko",
Volume="42", Number="8",
Title="Technology for Development and Reuse of Software Parts",
Year="1986", Note="in Japanese",
Journal="Toshiba Review")

@Inproceedings(goguen89f,
Key="Goguen",
Author="J.A. Goguen",
Title="{Principles of Parameterized Programming}",
BookTitle="{Software Reusability Volume I, Concepts and Models}",
Year="1989",
Editors="T. Biggerstaff and A. Perlis",
Publisher="Addison-Wesley Publishing Company")

@Inproceedings(mcilroy69,
Key="McIlroy",
Author="M.D. McIlroy",
Title="{Mass Produced Software Components}",
Year="1969",  Pages="88-98",
editors="P. Naur and B. Randell and J.N. Buxton",
Publisher="Petrocelli/Charter",Address="New York",
BookTitle="{Proceedings of NATO Conference on Software Engineering}")

@Article(johnson88,
Key="Johnson",
Author="R.E. Johnson and B. Foot",
Title="{Designing Reusable Classes}",
PAges="22-35",
Year="1988",
Month="June/July",
Number="1",Volume="2",
Journal="Journal of Object-Oriented Programming")

@Inproceedings(arango89,
key="Arango",
title="{Domain Analysis: From Art to Engineering Discipline}",
Year="1989",
pages="152-159",
Author="G. Arango",
Month="May 19-20",
BookTitle="{Proceedings Fifth International Workshop on Software Specification
and Design}")

@Article(biggerstaff84,
Title="{Forward: Special Issue on Software Reusability}",
Key="Biggerstaff", PAges="474-476",
Author="T.J. Biggerstaff and A.J. Perlis", Number="5", Volume="SE-10",
Year="1984", Month="September",
Journal="IEEE Transactions on Software Engineering")

@Incollection(matsumoto87,
Key="Matsumoto",
Author="Y. Matsumoto",
Title="{A Software Factory: An Overall Approach to Software Production}",
Year="1987",
Publisher="IEEE Computer Society Press",
Editor="Peter Freeman",
Pages="155-178",
BookTitle="{Tutorial: Software Reusability}")

@Inproceedings(tracz87b,
Key="Tracz",
Author="W. Tracz",
Title="{Software Reuse: Motivators and Inhibitors}",
Year="1987", Month="February",
BookTitle="{Proceedings of COMPCON87}")

@Article(prieto-diaz87,
Key="Prieto", PAges="6-16",
Author="R. Prieto-Diaz and P. Freeman", Volume="4", Number="1",
Title="{Classifying Software for Reusability}",
Year="1987",  Month="January",
Journal="IEEE Software")

@Article(biggerstaff87b,
Key="Biggerstaff", PAges="41-49",
Author="T. Biggerstaff and C. Richter", Volume="4", Number="2",
Title="{Reusability Framework, Assessment and Directions}",
Year="1987",  Month="March",
Journal="IEEE Software")

@Inproceedings(bailin88,
Key="Bailin",
Author="Bailin, S.C.",
Title="{An Environment for Reusing Software Life-Cycle Products}",
Year="1988", Month="April 13-14",
Address="Washington, D.C.",
Publisher="National Institute of Software Quality and Productivity",
BookTitle="{Proceedings, National Conference on Software Reuseability}")

@techReport(batory91,
AUTHOR="D.S. Batory and S.W. O'Malley",
INSTITUTION="University of Texas",
KEY="Batory",
TITLE="{The Design and Implementation of Hierarchical Software Systems}",
YEAR="1991",
Number="TR-91-22")

@Article(tracz88e,
Key="Tracz",
Author="W. Tracz",
Volume="13", Number="4",
Title="{Software Reuse Maxims}",
Year="1988",  Month="October", PAges="28-31",
Journal="ACM Software Engineering Notices")

@Article(tracz91,
Key="Tracz",
Author="W. Tracz",
Volume="16", Number="3",
Title="{A Conceptual Model for Megaprogramming}",
Year="1991",  Month="July", Pages="36-45",
Journal="ACM Software Engineering Notices")

@article(honiden86,
AUTHOR="S. Honiden and N. Sueda and A. Hoshi and N. Uchihira and K. Mikame",
JOURNAL="Journal of Information Processing (JAPAN)",
KEY="Honiden",
TITLE="{Software Prototyping with Reusable Components}",
YEAR="1986",
Number="3",
Pages="123-129",
Volume="9")

@techReport(biggerstaff86c,
AUTHOR="Biggerstaff, T.J.",
INSTITUTION="Microelectronics and Computer Technology Corporation",
KEY="Biggerstaff",
TITLE="{Research Problems in Automating the Reuse of Designs}",
YEAR="1986",
Month="June",
Number="STP-197-86")

@techReport(biggerstaff86d,
AUTHOR="Biggerstaff, T.J.",
INSTITUTION="Microelectronics and Computer Technology Corporation",
KEY="Biggerstaff",
TITLE="{Reusability Overview}",
YEAR="1986",
Month="May",
Number="STP-168-86")

@InProceedings(yamaoto86,
AUTHOR="Yamamoto, S., and Isoda, S.",
BOOKTITLE="{Proceedings of 10th Anniversary COMSAC '86}",
KEY="Yamamoto",
ORGANIZATION="IEEE Computer Society Press",
TITLE="{SoftDA: A Reuse Oriented Design System}",
YEAR="1986",
Pages="284-290")

@InProceedings(matsumoto86c,
AUTHOR="Matsumoto, Y.",
BOOKTITLE="Proceedings of 1986 National Computer Conference",
KEY="Matsumoto",
ORGANIZATION="AFIPS Press",
TITLE="{Experiences in Software Manufacturing}",
YEAR="1986",
Pages="93-94")

@InProceedings(prieto-diaz87a,
AUTHOR="Prieto-Diaz, R.",
BOOKTITLE="Proceedings of COMPSAC 87",
KEY="Prieto-Diaz",
TITLE="{Domain Analysis for Reusability}",
YEAR="1987")

@article(cardelli85,
AUTHOR="Cardelli, L., and Wegner, P.",
JOURNAL="Computing Surveys",
KEY="Cardelli",
TITLE="{On Understanding Types, Data Abstractions, and Polymorphism}",
YEAR="1985",
Number="4",
Pages="471-522",
Volume="17")

@Article(parnas76,
Title="{On the Design and Development of Software Families}",
Key="Parnas", PAges="1-9",
Author="D.L. Parnas", Number="1", Volume="SE-2",
Year="1976", Month="January",
Journal="IEEE Trans. Software Engineering")

@book(cusumano91,
Title="{Japan's Software Factories}",
Key="Cusumano",
Author="M.A. Cusumano",
Year="1991",
Publisher="Oxford University Press")

@Article(jones84,
Title="{Reusability in Programming: A Survey of the State of the Art}",
Key="Jones", PAges="488-493",
Author="T.C. Jones", Number="5", Volume="SE-10",
Year="1984", Month="September",
Journal="IEEE Transactions on Software Engineering")

@Article(lanergan84,
Title="{Software Engineering with Reusable Design and Code}",
Key="Lanergan", PAges="498-501",
Author="R.G. Lanergan and C.A. Grasso", Number="5", Volume="SE-10",
Year="1984", Month="September",
Journal="IEEE Transactions on Software Engineering")

@Inproceedings(breuer89,
Key="Breuer",
Author="P.T. Breuer and K. Lano",
Title="{REDO at Oxford}",
Year="1989",  Pages="39-49",
Month="November",
editors="L. Dusink and P.A. Hall",
Publisher="Springer-Verlag",
BookTitle="{Proceedings of the Software Re-use Workshop}")

@Inproceedings(cramer89,
Key="Cramer",
Author="J. Cramer and H. Hunnekens and W. Schafer and S. Wolf",
Title="{The MERLIN Approach to the Re-use of Software Components}",
Year="1989",  Pages="57-75",
Month="November",
editors="L. Dusink and P.A. Hall",
Publisher="Springer-Verlag",
BookTitle="{Proceedings of the Software Re-use Workshop}")
