Exploiting
Domain
Architectures
in Software
Reuse
Cristina Gacek Center for Software Engineering University
of Southern
California
Los Angeles, CA, 90089-0781
[email protected]
needed. Consequently, difficult to plan for.
Abstract This paper provides motivation ~owards the use of domain specific repositories and DSSA ‘s. It shows many of the positive side-effects this usage brings about.
population
is random
and very
Since the matching probability becomes much slimmer, the perspective reuser may feel not motivated to try his/her luck on that repository.
An extension to the faceted approach to components classi~cation [Prieto-Diaz and Freeman 1987] is introduced. Our extension suggests a natural way of further benefiting from the use of domain specific repositories.
1.
repository
2.
Introduction
Software reuse is the process of creating software systems from existing software rather than building software systems from scratch. Some of the requirements for software reuse techniques are [Krueger 1992]:
Domain S ecific Software Architectures and their R epositories
(DSSA)
“A DSSA is a process and infrastzwcture that support the develop ment of a Domain Model, Reference Requirements, and Reference Architecture for a family of applications within a particular problem domain. The expressed goal of a DSSA is to support the gener ation of applications within a particular domain (also known as a product-line).” [Tracz 1994] In this section we will describe the overall DSSA approach and its reuse characteristics, show a DSSA example, and then discuss the selection of reusable components within a DSSA infi-astnrctore.
●For a software reuse technique to be effective, it must reduce the cognitive distance between the initial concept of a system and its final executable implementation. ●For a software reuse technique to be effective, it must be easier to reuse the artifacts than it is to develop the software from scratch.
2.1
●To select an artifact for reuse, you must know what it does. ●To reuse a software artifact effectively, you must be able to “find it” faster than you could “build it”. As simple as these requirements might seem, they are not easily achievable. By using large general purpose repositories, we increase greatly the effort that is involved in locating reusable artifacts. This is caused by the large spectrum of components that might be included. Having to support this large spectrum of components allows the repository to grow exponentially; increases the difficulty involved in describing artifacts; provides no guidance towards what might actually lead to an optimal repository population; as well as reduces search matching probabilities. Descriptions here must both delimit the domain of each of the srtifacts, and specify their function within their domain. Thus, Wifacts descriptions become intrinsically complex, not only making it had
The DSSA Approach
While analyzing the overall DSSA approach, see Figure 1, it is important to understand the aspects involved on generating m underlying DSSA support mechanism for a specific family of application systems (domain engineering), aswell as on using this mechanism to generate new application systems (application engineering). Based on the domain requirements the domain engineering process, generates the domain model, which describes the elements in the domain and the relationships between them. The domain model is then used to generate the domain reference architecture -- the base software architecture for the family of application systems contained in the domain. During application engineering the application system specification. and constraints are used to refine snd/or extend the reference architecture in order to generate the appropriate architectural instantiation to be used. Based on this architectural instantiation, the system is developed and maintained.
to describe new artifacts, but also to match theml.
2.2
Because the repository is general purpose, it becomes extremely hard to determine which sort of artifacts might be more critically
From the description above and Figure 1, it is fairly easy to identify the major DSSA reuse characteristics. We list some here, but s. comparison between this approach and other kinds of reuse is left to the interested reader.
1. Instead of function within domain we could use signatures [Zaremski and Wing 1993], but still we would have to include both domain and signature for each of the artifacts.
Overall
DSSA Reuse Characteristics
●A thorough domain understanding is needed in order to determine components of all granularity levels that would constitute the optimal reusable components set. This domain understanding is captured by the domain model.
Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association of Computing Machinery.To copy otherwise, or to republish, requires a fee and/or soecific t)ermission. SSR ’95, Sea file, WA, USA 0 1995 ACM 0-89791 -739-1 /95/0004 ...$3.50
“The domain model and reference architecture clearly define what is considered common in the domain, thus inducing an optimal population of the repository, as well as utilization of the reuse process and its repository. By being very
229
1990], and several discussions with Dr. John Reeves from the Aerospace Corporation.
Unsatisfied Const@nts,
Domain Requirements
After having done that, we started concentrating on a specific instantiation of it. We started working towards the development of a satellite ground station that supporta a satellite dedicated to forest
[ Chsngedl Unsatisfied Requirements, Errors, Adaptations
fire detection [Larson 1993], see Figure 31. For this instantiation of the reference architecture, we not only dropped some parts of the reference architecture, such as “Encrypter/Decrypter”, but also added something specific to this application which is the “Mapper”, that is responsible for mapping the fire points detected into a US map.
Reusable Domain Design .
.
‘p#&y
T
Things like “Telemetry History”, “Telemetry Limits”, and “Eventa” that existed in the reference architecture were kept in this irtstantiation.
ments {
If we had a domain specific repository available, based on the reference architecture and on the fire SGS requirements we would be able to locate and reuse some domain specific reusable components. L
2.4
-
We know that the selection of reusable components within a DSSA is baaed on the elements of the reference architecture that are preserved. Baaed on this criteria, more than one option may exist to be used for a specific need. How one chooses the component to be used at that point heavily depends on the existent need and the actual information available in the repository for each of the components.
Executable Prototype/ Simunu;ytr
L
K2!Domain Engineering uApplicatiotr
DSSA Selection of Reusable Components
El@Ieering UPart
For example, our SGS repository could have two components that apparently equally fulfilled our current Fire SGS needs for the “External Network”. A more detailed examination of these components would show that while component 1 is faater, the component2 haa some special security considerations. In this case, as we are dealing with forest fire detection, security is not an issue, thus making the choice of component 1 more appropriate.
of Et
Figure 1. The DSSA Lifecycle [Balzer et al. 1993] specific about the domain, and using a reference architecture, the potential for reuse is extremely high. Whe reuse of the reference architecture drives reuse of common domain design. Based on the current common domain design, one is able to reuse existing components, as well as generate new ones.
We argue here, that this kind of consideration should be taken into account while classifying the components in the repository.
3.
~~oaceted
Approach
to Components
Classifi-
●B y having the reference architectme provide an integrating general framework for the reusable components, we avoid all problems involved on the actual composition problem uattally seen when trying to integrate reusable lower levels of artifacts.
Software artifacts are classified according to various facets. That is, several characteristics of the artifacts must be considered in order to facilitate the comparison between different artifacts, thus facilitating an optimal selection. This approach to components classification was first suggested by Prieto-Diaz and Freeman [Prieto-Diaz and Freeman 1987].
●Since without the domain model and reference architecture defined one cannot start populating the repository, it becomes clear that domain engineering costs must come very early in the DSSA life-cycle. This causes a very large up front investment, which will require some time to be paid off.
Prieto-Diaz and Freeman suggested the use of functionality and environment. Functionality should be described in terms of function (operation performed), object (type of data object on which the operation ia performed) and medium (larger data structure in which the data object is located). While environment is composed of system type (type of subsystem for which the component was designed), functional area (application dependent activities) and setting (application domain).
●Domaitt model, reference architecture and repository are continuously evolving baaed on the domain evolution observed through the requirements evolution of applications in the domain. Whe existence of a domain specific repository reduces some asset management problems, such as allowing for assets descriptions to be more succinct.
2.3
Their work also includes an algorithm for matching available reusable components against user requests, see Figure 4.
DSSA Example
Their algorithm
Figure 2 shows a reference architecture for a Satellite Ground Station (SGS) that was developed by Ahmed Abd-Allah, Bradford Clark, and myself, in the course of our software architecture research. It was based on a study done by SPC [SPC], some literature furnished to us by the Aerospace Corporation [DMSP 1981-
230
can take into account different
facets, however it
1 For both the SGS reference architecture, and the Fire SGS architecture we used UNAS/SALE, a TRW/Rational architecting CASE tool.
——
:/
!_
Circuit
I
----
Processing ----
1
Figure 2. SGS Reference Architecture
rI
7ATta- - ~ Acquisidon -——— —_.
~ ,
r - ZJa%z- ‘I f Routing , L—————
I
[ :
I
--xiii ---/ Processing --—
----
~
Figure 3. Fire Satellite GS Architecture required and available values for all the facets, with no prioritize tion. Further, as with more recent reuse approached [Mili et al. 1994], full reliance. is placed on computer selection of the preferred component rather than enabling the-user to exercise judgement in the final selection.
sea=ch tihe library if identical match is found then use it else make a set of similar components for each component in the set compute degree of match rank the set based on the degree of match select the best match from the ranked set modify the selected component and use it Figure 4. Matching
Algorithm
mieto-Diaz
4.
and Freeman 1987]
does not deal with the fact that different users and/or situations may impose differirtg priorities to the various supported facets. Consequently, in cases when more than one identical match is found then there is no extra guidance for the user as to which one would best suit hislher needs. Additionally, when there is no perfect match, the degree of match is computed based on the distance between
231
OurExtensiontotheFacetedApproach
We suggest the inclusion of some few other facets of artifacts like execution time, memory spats usage, and level of certification [Gacek and Boehm 1993]. The relevance of each of these facets ori a particular selection is totally domain dependent. For example, when dealing with astmdent registration by phone system, execution time is certainly not a great concern, while dealing with sensor data processing this can be critical. Baaed on the idea of varying user rind/or environment priorities uponthevmious facets supported, wemadesnextension toPrieto Diaz and Freeman’s original algorithm, see Figure 5. Our matching
algorithm considers the different facets involved, as well as the user’spriorities on those. Thus, matches medonebased onthepnorities imposed on each of the facets. search the library if identical matches were found then make a set of the identical matches else make a set of similar components request the user to prioritize the various facets for each component in the set compute degree of match based on facets priorities rank the set based on the degree of match present the ranking results of the strongest candidates to the user based on user judgement, select the preferred candidate modify the selected component (if needed) and use it Figure5.Extended
6. Bibliography 1.[Balzeret. al. 1993]
R. Balzer, C. Braun, F. Belz, L. Cogfianese, L. Erman, K. Harbison, R. Might, R. Platek, and S. Vestal, “DSSA Process Summary,” copies available from Chris Braun (
[email protected]), 1993. 2. [Boehm and Scherlis 1992] B. W. Boehm and W. L. Scherlis, “Megaprogramming,’’P roceedings of the DARPA Software Technology Conference, April 1992. (available via USC Center for Software Engineering, Los Angeles, CA, 90089-078 1). 3. ~MSP 1981-1990] Defense Meteorologics-l SateHite Ro~w, Block SD-2 System Analysis Report, vol. 1-10, 1981-1990. 4. [Gacekand Boehm 1993] C. Gacekand B. W. Boehm,
