ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr6/proceedings/ascii/mayobre.ascii

Text File | 1993-10-19 | 22KB | 435 lines

Maximizing  Reuse  with  an  Evolution  Oriented  Domain  Engineering



                                                  Guillermo Mayobre



                                                    Hewlett Packard

                                            Grenoble Networks Division

                                              5, Ave Raymond Chanas

                                             38053 Grenoble CEDEX 9

                                                          France

                                     Email: [e-mail]



                                                         Abstract


           Software development on the context of domain of application (domain fo cussed software
       development) may be seen as evolutionary development weresoftware representing core domain
       concepts are extended/adapted to meet new product requirements.  On such a context, man-
       aging 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 GrenobleNetworks Division.


       Keywords:  Domain, variant, invariant, impact analysis, evolutiveness, adaptive, cohesiveness
       with respect to variability, model predictability, mo del coverage, taxonomy of variability, spe-
       cialization attribute, factors of variability.



                                                        Mayobre- 1


1      Background



Domain oriented product development is today one of the prevalent ways of developing products.
Corporations, companies, must of the organizations are almost organizedaround 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 problemspace.  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 describ ed here, they are based on the common metho dological framework
that underlies current methods).



2      Position



2.1     Classifying Functionality



Functionality involved in the development of new systems may be classified in two categories.:  In-
variant and Variant. [1 ] 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 cus-
tomization 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 variantfunctionality, increasing the overall costs of development of
new systems.



                                                        Mayobre- 2


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  metho ds, 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.



2.2     The Evolution Oriented Domain Engineering



It consist basically on three main activities:



    1. Evolution specification,

    2. Evolution control,

    3. Instance implementation.



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 andvariances across the systems, together with a
classification of them. [2].


The result of the architectural design activity isthe 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 identifica-
tion/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 special-
ization 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 attributeslike:  manage-
ment protocol, buffer management subsystem, line throughput performance,...) Then, a vector of
values is assigned to the identified specialization attributes characterizing the instance to be im-
plemented.  (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,  mo dels (domain  specification  and  domain  architectural)  and
taxonomy of variability areup dated toinclude un-predicted, partially predicted or predicted and
partially  implemented  variances.  Note  that  this  last op eration is  done  only  if  the  evaluation  of
benefits induced by the modifications appears to be greater than the costs of updating.



                                                        Mayobre- 3


The instance implementation activity, is resp onsible for the implementation of the specific appli-
cation 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:



    fflreuse already implemented large frames of software, corresponding to the invariant function-
       ality, involved in the implementation of this specific instance,

    ffldevelop reusable software corresponding to the not yet implemented core functionality (typ-
       ically by using a classical engineering for reuse approach, supported by the existing domain
       models), and

    fflimplement 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.



2.3     Identifying/Predicting and Characterizing Variability



The identification/prediction and characterizationof 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:



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, p erformances ...).
       Market  analysis  and  customer  characterization  (of  representative  customers)  are  valuable
       mechanisms to predict changes/evolutions in functionality.

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.

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 b e 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 mayb e articulated.



The taxonomy of variabilityresults from the classification of variations identified during the evalu-
ation of factors of variability.  To each of the elements of the taxonomy,a factor of risk is associated,


                                                        Mayobre- 4


that evaluates its probability of occurrence. During the characterization, each of the elements of
the taxonomy of variabilityis mapp ed 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  at-
tribute is obtained. The level of variability of a specialization attribute is the numb erof 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  variabil-
ity  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 vari-
ability provides useful information to:



    fflIsolate  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.

    fflGroup specialization attributes with low level of variability,  what tendsto increase the in-
       variants 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 soft-
       ware between applications. The risk of occurrence of an instance of a specialization attribute
       provides information to establish a strategy of implementation:


           -  the higher the level of confidenceasso ciatedto a prediction of variability, the lower the
              level of abstraction in the specification ofthe corresponding software.
           -  the lower the level of confidence associated to a prediction of variability, the higher the
              level of abstraction in the specification ofthe corresponding software.

    fflPrediction of occurence of variability in the time provides complementaryinformation for the
       implementation schedule.



3      Comparison



3.1     Modeling and Representing Domain Concepts



It is extremely recommended to adopt an object oriented approach to build domain models.  Essen-
tially 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. [3 ]



3.2     Qualifying Domain Models



The  rules  of  construction  of  the  models  described  above, leads  naturally  to  define  the  following
metrics, to qualify domain models:



                                                        Mayobre- 5


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.

Model predictability            : Is the capability to predict/anticipate variance, measured by the cohe-
       siveness (ability to locate variability on isolated areas of the model) and the costs of devel-
       opment anticipated by the strategy of implementation.



The already defined metrics involves lower level metrics such as software development pro ductivity
and component and system costs of reusable software  [4 , 5 , 6 ]. 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. [7 ]



3.3     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 componentsnot 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  b etter  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 theun-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:



    fflenhance  the  mechanisms  of  identification/prediction  and  characterization  of variability  to-
       gether with their formalization,

    fflenhance the traceability of variability to increase the accuracy of impact analysis and record
       the evolution knowledge,


                                                        Mayobre- 6


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

    fflextension/tuning of the reuse economical costs models, used as decisions tools by the intensive
       computation of object oriented productivity metrics involved on them.



Further research activitieswill b e 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  opera-
tional 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.



References



[1]  Barness and Bollinger, "Making Reuse Cost Effective," IEEE Software, January 1991.


[2]  R.  P.  Diaz  and  G.  Arango,  "Domain  Analysis  and  Software  Modelling,"  in  IEEE Computer
     Society Press Tutorial, IEEE Computer Society Press, 1991.


[3]  J. Ramb ough and All, Object Oriented Modelling and Design. Prentice-Hall, 1991.


[4]  D. Balda and D. A. Gustafson, "Cost Estimation Models for the Reuse and Prototype Software
     Development Life Cycle," ACM Sigsoft Software Engineering Notes, vol. 15, p. 42, July 1990.


[5]  G.  Mayobre,  "Using  Code  Reusability  Analysis  to Identify  Reusable  Components  from  SW
     Related  to  an  Application  Domain,"  in  WISR  1991 Proceedings,  Department  of  Computer
     Science, University of Maine, 1991.


[6]  Caldeira and Basili, "Identifying and Qualifying Reusable Software Components," IEEE Com-
     puter, February 1991.


[7]  B.  Boehm, "A  Spiral  Model  of  Software  Development  and  Improvment," IEEE  Computer,
     vol.21, May 1988.



                                                        Mayobre- 7