%%%%%% TEMPLATE.TEX for WISR'93, version 1.2.1, 10/3/93 %%%%%%
%%%%%% Updated by Jeffrey S. Poulin,  May 1993          %%%%%%
%%%%%% Updated by Larry J. Latour     and               %%%%%% 
%%%%%%            Steve L. Philbrick, October 1993      %%%%%%
%%%%%%
\markboth{Mayobre}{Mayobre}
\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{Mayobre}{Mayobre}
\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{Maximizing Reuse with an Evolution Oriented Domain Engineering}

\author{Guillermo Mayobre\\
\\
Hewlett Packard\\
Grenoble Networks Division\\
5, Ave Raymond Chanas\\
38053 Grenoble CEDEX 9\\
France\\
Email: gm@hpgntol1.grenoble.hp.com\\
}
\date{}
\maketitle
\begin{abstract}

Software development on the context of domain of application (domain focussed 
software development) may be seen as evolutionary development were software 
representing core domain concepts are extended/adapted to meet new product 
requirements.  On such a context, managing the evolution of existing software 
is key to keep development costs under control.  An evolution oriented domain 
engineering including a domain analysis phase with special focus on the 
identification/prediction and characterization of the variability, provides a 
framework to successfully master the evolution of software.

This paper summarizes some of the results carried out on the context of the 
European Research project PROTEUS (ESPRIT project 6086), together with some 
practical results from the software reuse program at the Hewlett Packard 
Grenoble Networks Division.
 
\vspace{0.2in}
\noindent
{\bf Keywords:} Domain, variant, invariant, impact analysis, evolutiveness, 
adaptive, cohesiveness with respect to variability, model predictability, model
coverage, taxonomy of variability, specialization attribute, factors of 
variability.
 
%\vspace{0.2in} \noindent {\bf Workshop Goals:} 
%\vspace{0.2in} \noindent {\bf Working Groups:} 
\end{abstract}
 

\newpage
\section{Background}
 
Domain oriented product development is today one of the prevalent ways of 
developing products. Corporations, companies, must of the organizations are 
almost organized around product lines or domains of applications. Simply 
because this is the most natural way of centralizing, capitalizing and 
maximizing the reuse of knowledge. Naturally the solution space corresponding 
to this domain oriented organization of the problem space is also domain 
oriented.

Applications of the domain represents specific solutions to the problem space. 
They are usually built on an incremental manner, evolving from the existing 
software. A part of their software represents core functionality of the domain,
usually shared between several applications, and another part represents 
specific functionality.  

What is important, is to abstract, from those specific solutions, generic 
specifications to derivate reusable, generic, highly evolutive, solutions to be
 able to implement new requirements/functionality within the domain at the 
lowest possible cost.

Up to now, most of the existing domain analysis approaches aim at preparing 
reuse by focussing on the identification of the common, invariant parts of the 
systems in the domain. The approach presented in this paper puts a strong 
emphasis on the identification/prediction and characterization of the 
variability, essential to master evolution. (Mechanisms dedicated to the 
identification of the invariant part are not described here, they are based on 
the common methodological framework that underlies current methods).

 
\section{Position}
\subsection{Classifying Functionality}

Functionality involved in the development of new systems may be classified in 
two categories.: Invariant and Variant.~\cite{BB91} Invariant functionality is 
the set of components or components fragments that are used without changes. It 
provides the kernel of functionality around which new systems are built. By 
definition invariant functionality cannot create new systems since it lacks the
 customization needed to meet new requirements.  Variant functionality is the 
set new functionality that must be added/changed to customize invariant 
components. It provides novel functionality to address new needs.  On domain 
focussed software development, invariant functionality usually represents 
domain commonalities, core functionality of the domain, that are reproduced 
from one application to another. Variant functionality is usually added or 
replaced in an incremental manner and represents a small percentage of the 
total implemented functionality of the system. This way of development is 
usually called an incremental evolutionary software development process.

An adaptive software development strategy is extremely well adapted to be used 
in this context. Such a strategy uses large frame structures as invariants 
(supporting the invariant functionality) and restricts variability to low level
isolated locations within the overall structure. As it attempts to keep most 
of the overall structure invariant, adaptive strategy helps to keep development
costs under control when reusing or leveraging invariant functionality from one
existing system to the new one. However, because it also tend to be application
specific and relatively inflexible, it may burden the cost of addition of 
variant functionality, increasing the overall costs of development of new 
systems.

To avoid this situation and minimize the costs of addition of variant 
functionality we need to add flexibility to those selected locations within the
overall structure where variant functionality is to be plugged.  In other 
words, the key point to master evolutionary software development is the 
creation of an evolution infrastructure (set of methods, tools and operating 
practices) that minimizes both, the cost of reusing/leveraging invariant 
functionality and the cost of addition of variant functionality.  Methods and 
tools are those involved in the domain engineering activity. By operating 
practices we understood the set of well known rules and mechanisms that allow 
to obtain results on a systematic and repeatable way.

\subsection{The Evolution Oriented Domain Engineering}

It consist basically on three main activities:
\begin{enumerate}\itemsep -3pt
  \item Evolution specification,
  \item Evolution control,
  \item Instance implementation.
\end{enumerate}

The evolution specification activity consists on the domain analysis, the 
domain modeling and the domain architectural design processes.  We made the 
distinction between the domain analysis process referring to the activities of 
collecting and classifying data, and the domain modelling process as referring 
to the design of a formal structure for the descriptions. The combined results 
of those activities are the domain specifications model, and the taxonomy of 
domain variability. By domain specifications model we understood the definition
of entities, operations, relationships and events that abstracts domain 
commonalities and variances across the systems, together with a classification 
of them.~\cite{PA91}.

The result of the architectural design activity is the domain architectural 
model that represents the generic architecture (or set of architectures) of the
domain from where specific instances are derived.  The contribution of our 
approach is that a particular emphasis is put on the identification/prediction 
and characterization of variability, as we consider it is crucial to specify 
evolution. The taxonomy of domain variability is used to encode variance on the
model through the specialization attributes. Each variance is represented by a 
set of different values of the specialization attributes. An instance (specific
application of the domain) may be obtained by assigning a vector of values to 
the specialization attributes.

The evolution control activity characterizes the evolution induced by a new 
requirement according to a taxonomy of variability.  In that activity, the new 
requirement is first translated into a set of specialization attributes. (i.e. 
on the network management domain of application, extending the management to 
support a new type of device, may impact specialization attributes like: 
management protocol, buffer management subsystem, line throughput 
performance,...) Then, a vector of values is assigned to the identified 
specialization attributes characterizing the instance to be implemented. 
(i.e. associates values to the already identified specialization attributes: 
management protocol = CMIP, buffer management subsystem = class 4, line 
throughput performance = 800 Mbit/sec, ... ) Finally, if needed, models (domain
specification and domain architectural) and taxonomy of variability are updated
to include un-predicted, partially predicted or predicted and partially 
implemented variances. Note that this last operation is done only if the 
evaluation of benefits induced by the modifications appears to be greater than 
the costs of updating.
 
The instance implementation activity, is responsible for the implementation of 
the specific application to meet the new requirement.  It extracts from the 
domain architectural model the specific architecture of the application to be 
implemented, identified in the previous step by the set of values assigned to 
the specialization attributes, and gets the corresponding specific design. This
specific design is generally incomplete. It is composed of an implemented part 
representing the already implemented core functionality of the domain, and a 
not implemented part representing the not yet implemented core functionality of
the domain and the not yet implemented variant functionality corresponding to 
the variability induced by the new requirement.

According to this situation, an implementation strategy is defined that may be 
summarized as follows:
\begin{itemize}\itemsep -3pt
  \item reuse already implemented large frames of software, corresponding to 
  the invariant functionality, involved in the implementation of this specific 
  instance,

  \item develop reusable software corresponding to the not yet implemented core
  functionality (typically by using a classical engineering for reuse approach,
  supported by the existing domain models), and

  \item implement specific variability maximizing the external reuse level. At 
  this stage, a classical Design With Reuse approach should be used. Components
  to be reused may come for the software associated to the domain of 
  application, from others domains or from general purpose libraries.
\end{itemize}

\subsection{Identifying/Predicting and Characterizing Variability}

The identification/prediction and characterization of variability are key 
mechanisms of the evolution oriented domain engineering process.
 
Identification/Prediction deals with evaluating factors of variability that 
influences variations in requirements within the domain of application. Among 
the most important are:
\begin{description}\itemsep -3pt
  \item [Market characterization]: evolution and potential for expansion.  
  Variations in functionality are mainly induced by market trends and market 
  opportunities on mature domains, and by customer requirements on immature or 
  new domains. Market expansion may also be a factor inducing changes in 
  requirements: a growing market may result on a more competitive environment 
  were the reduction of implementation costs of already existing functionality 
  may conduct to changes on requirements (changes in hardware platforms, 
  performances ...). Market analysis and customer characterization (of 
  representative customers) are valuable mechanisms to predict 
  changes/evolutions in functionality.

  \item [Technology evolution]: Provides information on the number of instances
  that may be reused without any technology change and/or the level of 
  abstraction required by the descriptions on the domain models to be 
  technology independent.

  \item [Level of standardization]: Is at the inverse of the two precedent a 
  factor of stability. The highest the level the lower the variability. It may 
  be used to isolate areas of the domain were the evolution will be none, a few
  or at least easily predicted. Those areas represents kernels of stable 
  functionality around which variability may be articulated.
\end{description}

The taxonomy of variability results from the classification of variations 
identified during the evaluation of factors of variability. To each of the 
elements of the taxonomy, a factor of risk is associated, that evaluates its 
probability of occurrence.  During the characterization, each of the elements 
of the taxonomy of variability is mapped to the set of corresponding 
specification attributes in the domain models. As a result, an internal 
variability map associating a level of variability to each specialization 
attribute and risk of occurrence to each of the instances of the specialization
attribute is obtained. The level of variability of a specialization attribute 
is the number of different instances (represented by different values) 
associated to it. The risk of occurrence of an instance of the specialization 
attribute is the level of confidence associated to the prediction of 
occurrence of that instance.

What is extremely important is to build/modify the models, according to the 
internal variability map, to isolate specialization attributes with a high 
level of variability, group specialization attributes with low level of 
variability and define a strategy of implementation.  The level of variability 
provides useful information to:
\begin{itemize}\itemsep -3pt
  \item Isolate specialization attributes with high level of variability into 
  separate locations, what tends to minimize the cost of implementation of 
  variability. The property of restricting high level of variability to 
  isolated locations within the overall structure is what we call the model 
  cohesiveness against variability.

  \item Group specialization attributes with low level of variability, what 
  tends to increase the invariants areas of the model, defined when identifying
  common/stables parts of the systems in the domain, and by the way, 
  contributes to maximize the reuse of large frames of software between 
  applications.  The risk of occurrence of an instance of a specialization 
  attribute provides information to establish a strategy of implementation:
  \begin{itemize}\itemsep -3pt
    \item the higher the level of confidence associated to a prediction of 
    variability, the lower the level of abstraction in the specification of the
    corresponding software.

    \item the lower the level of confidence associated to a prediction of 
    variability, the higher the level of abstraction in the specification of 
    the corresponding software.
  \end{itemize}

  \item Prediction of occurence of variability in the time provides 
  complementary information for the implementation schedule.
\end{itemize}


\section{Comparison}
\subsection{Modeling and Representing Domain Concepts}

It is extremely recommended to adopt an object oriented approach to build 
domain models. Essentially because the concepts of abstraction/specialization 
(to capture commonalities and encapsulate variances), aggregation/decomposition
(to master the complexity) and differentiation, critical to represent domain 
knowledge, are inherent to the OO representation.~\cite{JR91}

\subsection{Qualifying Domain Models}

The rules of construction of the models described above, leads naturally to 
define the following metrics, to qualify domain models:
\newpage
\begin{description}\itemsep -3pt
  \item [Model coverage]: Is the ability to provide reusable software measured 
  by the amount of core functionality to be implemented by new applications 
  that may be reused from the invariant part of the model.

  \item [Model predictability]: Is the capability to predict/anticipate 
  variance, measured by the cohesiveness (ability to locate variability on 
  isolated areas of the model) and the costs of development anticipated by the 
  strategy of implementation.
\end{description}

The already defined metrics involves lower level metrics such as software 
development productivity and component and system costs of reusable software
~\cite{BG90,GM91,CB91}.  Note that the model coverage and model 
predictability, inderectly measures , the cost benefits of reusing invariants 
and the cost of implementing variant, both key costs of the evolutionary 
software development.

A natural question rises here: what if for a new un-predicted variant, models 
show a poor coverage and a bad predictability? The first point to verify, is if
the variant is outside of the predefined domain boundaries. If it is not the 
case and the variant is not an isolated example, but rather than that, it 
predicts a set of variabilities of the same type to arrive, domain models 
should be re-considered and a new step of domain engineering will probably be 
necessary.~\cite{Boh88}

\subsection{Conclusion and Further Investigation Directions}

Up to now at Hewlett Packard Grenoble Networks Division we mostly experienced 
two approaches of reuse, the a-posteriori (or reverse engineering) and the 
a-priori (or domain reuse). They are essentially different on the process and 
results.

The a-posteriori approach is simpler, provides immediate return on investment 
and requires a lower level of reuse culture on the organization. As a drawback,
the return on investment is burden by the adaptation costs induced by the 
re-engineering of components not initially designed to be reusable.  The 
a-priori approach is more difficult and risky and requires a higher level of 
reuse culture of the organization. But it presents the advantage of providing 
high return on investment.  

A natural way to introduce reuse in an organization is to start with the 
a-posteriori approach to build confidence and create success stories and to 
migrate incrementally to the a-priori as the culture on reuse increase and the 
change is accepted.  We are now using both approaches and by comparison the 
a-priori approach is about three times better in terms of ROI than the 
a-posteriori.  However, even in the best cases using an a-priori approach we 
were able to establish that the most limitative factor of the ROI are the 
un-predicted domain variances, that invalidates domain models by inducing 
important costs of addition of variant functionality. And obviously, the longer
the domain life cycle the higher the risk.  We believe, as confirmed by several
first results, that an evolutionary software development approach, supported 
by an evolution oriented domain engineering, with a special focus on the 
identification/prediction and characterization of variability, really 
contributes to maximize reuse return on investments on the context of domain 
focussed software development.
 
Among the further directions of the research are:
\begin{itemize}\itemsep -3pt
  \item enhance the mechanisms of identification/prediction and 
  characterization of variability together with their formalization, 

  \item enhance the traceability of variability to increase the accuracy of 
  impact analysis and record the evolution knowledge,

  \item provide appropriate tools to support the traceability of variability 
  (research on the area of hypertext based tools),

  \item extension/tuning of the reuse economical costs models, used as 
  decisions tools by the intensive computation of object oriented productivity 
  metrics involved on them.
\end{itemize}

Further research activities will be done on the context of the European 
Research ESPRIT project PROTEUS, and in close collaboration with Hewlett 
Packard Corporate Engineering and Hewlett Packard Laboratories.  The areas of 
technology transfer are essentially Hewlett Packard operational divisions and 
some European companies member of the PROTEUS consortium.  Domain of 
applications were this evolutionary approach is being applied today are 
Telecommunication and Datatcommunication Networks, and Aerospace applications.

\bibliography{mayobre}

%\section{Biography}
 
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
