An Approach to the Classification of Domain Models in ... - CiteSeerX

An Approach to the Classification of Domain Models in Support of Analogical Reuse Chung-Horng Department

Email:

Lung and Joseph E. Urban

of Computer Science and Engineering Arizona State University Tempe, AZ 85287-5406 {clung I jurban} @asuvax.eas.asu. edu

Abstract

other reason is that domain analysis is a study of relevant information in a problem area rather than just one particular system. As a result of the study, commonalities and reusable information within a domain can be identified in the process. The analysis can then be reused to build new applications which are also in the same problem domain. Thus, domain analysis may support reuse to a large degree and has the potential to receive high payoff.

This paper presents an approach to classify domain models in order to facilitate reuse through analogy. Domain analysis plays a critical role for systematic reuse, but domain analysis is difficult to perform, especially for new application areas. Analogical approach to reuse can support the domain analysis process by providing software products in a different but analogous domain. In order to achieve this goal, domain models need to be classified. This paper proposes a classification method for domain models. The method is an integration of the The enumerative hierarchy and faceted scheme. classification approach can help the domain analyst to locate an analogous domain to perform the modeling and analysis process. Moreover, the approach is more flexible and more descriptive than conventional classification methods.

Although domain analysis has the potential to promote large-scale software reuse, it suffers some barriers due to the complexity and the effort required. Domain analysis is generally suited to well-understood domains. But domain analysis is difficult to start for poor-understood problems or new application areas. Analogical problem solving is another approach to software reusability. Analogical problem solving transfers knowledge from past problems to new target problems that share significant similarities with the past problems in order to construct solutions to the target problems. Analogy is a topic of interests in many research disciplines, such as psychology, cognitive science, artificial intelligence, While domain analysis education, and philosophy. identifies commonalities across applications in a specific domain, analogical reasoning often occurs between different domains. There are many analogous examples in sciences, e.g., the analogy between the solar system and the structure of an atom.

1. Introduction Software reuse is recognized as an important research topic in software engineering. Software reuse has the potential to increase productivity, improve quality, enhance reliability, and shorten time-to-market. The problem in the current software community is not a lack of reuse, but a lack of well-defined systematic reuse [Prieto-Diaz 93]. Different approaches to software reuse have been reported in the literature. Among the approaches, domain analysis is advocated as a necessary step for effective reuse.

Therefore, analogy is not based on syntactical similarities between different systems but the implicit knowledge structure of the problems. Two problems may be different in syntax, and yet share a common knowledge structure. The reuse of problem solving experience and knowledge from one domain to another makes analogy an interesting and attractive approach. Moreover, analogy may facilitate the analysis for a new domain or a poorly understood domain.

There are two main reasons for utilizing domain analysis. Firstly, domain analysis emphasizes the reusability of analysis and design instead of just program code, The Permission to copy without fee all or parl 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 specific permission. SSR ’95, Seattle, WA, USA G 1995 ACM 0-89791 -739- 1/95/0004 ...$3.50

In order to support software reuse across different but analogous domains, the results of domain analysis must

169

be classified, especially the high-level software artifacts, such as domain models. A domain model is a representation of a domain that depicts objects and relationships, functions, and behaviors. The model identifies generic requirements or commonalities and differences of the problems in a domain. Classification in one of the most fundamental methods adopted in various disciplines of science and engineering. Classification helps people compare and understand different systems or areas.

Nevertheless, these approaches share a common purpose, which is to manage the identification, capture, and evolution of domain knowledge and make the information reusable when creating new systems in the same application domain. Wartik and Prieto-Diaz [Wartik 92] proposed a set of classification criteria in order to compare different domain analysis approaches. The reusable information generally represents a set of features common to a collection of existing and future applications in a problem domain.

Recently, classification has also been studied for software, either for low-level components or high-level artifacts. There are two major categories to classify software: The enumerative enumerated and faceted schemes. hierarchy approach suffers the problem of inflexibility, whereas the faceted scheme alone cannot adequately This paper specify complex application domains. describes a classification approach for domain models. The purpose of the classification is to facilitate the domain analysis process for new or not well-understood target domains through the retrieval of existing analogous domains. The classification is a hybrid of hierarchical and faceted schemes. In other words, the classification consists of a hierarchy of facets.

Domain analysis has been advocated as a critical step to support systematic software reuse [Prieto-Diaz 93], Domain analysis is related to several other research areas. These areas include requirements engineering, objectoriented methods, knowledge engineering, software factories, and library science. Prieto-Diaz and Arango [Prieto-Diaz 91a] have addressed those issues in the tutorial and have collected a set of articles specifically on domain analysis. The kinds of software products that domain analysis may produce include source code, design, specifications, objects, text, architectures, and domain models. An architecture defines basic system components and their relationships and interfaces. Architectures are used as generic development frameworks for a set of similar problems, so that the developer does not need to build a high-level design for each application within a domain. A domain model defines the functions, objects, relationships, and behaviors in a domain. The model identifies generic requirements or commonalities and differences of the problems within a domain.

The paper follows the concept studies

of analogy

engineering. software

with

of domain

Section

2, which

analysis.

in various

Section

Section disciplines

4 discusses

is an overview

of

3 introduces

the

and in software

methods

and

to classify

postulates a classification approach Lastly, Section 5 summarizes models.

for

the discussion of the paper and presents some future research directions. domain

2. Domain

Domain analysis can be viewed as an expansion of the conventional requirements analysis. The main advantage that domain analysis provides is flexibility. However, domain analysis suffers some barriers due to the complexity and a large amount of time required for development. Domain analysis is suited for stable, muture, and well-understood domains [Biggerstaff 92, Arango 93]. For new domains, analysis may be difficult to start. Furthermore, commonalities of various levels also exist among different application domains. Therefore, domain analysis may suffer the same problem that requirements analysis has been suffering, i.e., lack of flexibility to support reuse for similar applications. Analogy analysis, presented in the next section to overcome the problem, broadens the scope of analysis for different but analogous application domains. Through analogy, reuse of various of levels of software is possible across domains.

Analysis

Greenspan, et al. [Greenspan 82], Borgida, et al. [Borgida 85], Curtis, et al. [Curtis 88], and Johnson, et al. [Johnson 92] addressed the importance of incorporating “real world knowledge” (domain knowledge) into the process of requirements analysis. However, they only focused on a particular system instead of a class of applications. Neighbors [Neighbors 84] was one of the first researchers to define domain analysis as being “the activity of identifying the objects and operations of a class of similar systems in a particular problem domain. ” Kang, et al. [Kang 90] defined domain analysis as “the process of identifying, collecting, organizing, and representing the relevant information in a domain based on the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory, and emerging technology within the domain. ” There

were

several

approaches

discussed in the literature, 87, Cleveland 88, Arango

e.g.,

to [McCain

domain

3. Analogy Analogical problem solving is a process of transferring knowledge from past problem solving experiences to a new problem that share significant similarities with the past problem. The transferred knowledge is then used to construct solutions for the new problem. Analogy is a powerful problem solving and learning mechanism that

analysis

85, Prieto-Diaz

89, Shlaer 89, Bailin 90, Kang 90, Campbell 91, Devanbu 91, Lubars 91, Simos 91]. These approaches have different perspectives on the process and the products on domain analysis.

170

has been

studied

science, Several

in the areas of psychology,

artificial articles

intelligence,

education,

[Kedar-Cabelli

88, Hall

cognitive

and philosophy. 89, Leishman

Bejar

91] have surveyed or discussed Analogy also plays a vital areas.

90,

analogy in those role in scientific

similarity

between

evolved

from

approaches

[Michalski

have

been

also

support This

the amount

classification

of water

John-Steiner

flowing

through

[John-Steiner

presented

a number

inferences

as a scientific

explaining

analogical

the concept

of analogy

systems

management

and

has been

software

applied

to

engineering

[Silverman 85a, Silverman 85b, Finkelstein 88, Miriyala 89, Maclean 91, Neal 90, Maiden 92, Lung 93, Maiden 93, Harandi aspects models, software

93, Lung

94].

These papers

discuss

various

and rules domains.

or

strategies

for

different

accepted

application

[Finkelstein

88]

presented

patient

monitor

Maiden

and Sutcliffe

the air traffic systems Similarities categories,

that there

domains.

system

the similarities

among

approach

with examples.

and the flexible

the

of Software

Maiden

[Maiden

are different, These

hierarchy.

The hierarchy

Two

syntactically

similar

meet the demands

may not

different

in syntax.

hierarchy

drawing

application

knowledge

analogy

structures

between

two

much

are the different

domains.

This paper does required to draw areas. The perspectives

not address how or what features are an analogy between different problem

papers just listed above presented on the issue. Instead, the paper

how to classify the application domains in support the analogy analysis and identification

for domain

the universe

in

of knowledge

more

complex

domain

than

of domain various domains.

In faceted

classification

since

software

may consist

distinguish application

expansion

models

and evolution

of flexibility

models,

is even more

domain parts.

of several

are a A

to represent

embedded

schemes

models Moreover,

sub-domains.

is adequate

features

in

[Prieto-Diaz

or

different

9 lb],

parts

or components are described by a set of standard terms or facets; each facet describes a key aspect of the software. These approaches are more descriptive and extensible than the enumerative methods. However, the faceted

different discusses order to process.

classification

approach

is mainly

determining

and selecting

approach

complexity

and uncertainty.

models.

designed

for

software

For software products in the early phase of the life the approach alone has a major problem of the appropriate Poulin

facets due to the

and Yglesias

[Poulin

93] also reported some empirical issues encountered in utilizing the faceted classification scheme. The authors advocated a combination of classification techniques to

4. Classification

support

Classification or clustering analysis is central to human reasoning and problem solving capabilities. Classification in “the construction of from featural information,

complex object

knowledge clusters, and

category structure” [Hanson 83]. Classification is used to group similar entities together to develop a set of clusters, so that the similarity

an aspect a classification

the track of enumerative The science.

of continuous

parts. cycle,

is useful structures

et al. [Mineau

the research in such as software Although these

library

divides

The identified analogous domains can then be reasoned to facilitate the domain analysis process for the new problem The next section addresses the classification area. for domain

Classification

is, however,

in

The consideration

important

key

Similar

of the

relationship.

of software.

complex

an

support

illustrates

The major problem with the approach is the inflexibility. For software, a flexible classification is required that can

be analogous. On the other hand, two domains may share similar knowledge structures even if the domains are to

method

hierarchical

manufacturing

domains

4.3

all generate

follows

schemes

an approach in

93], Mineau,

there

approaches

software

that

share some important commonalities. can be further distinguished into three namely, syntactical, semantic, and pragmatic

similarities.

models

Section

First,

of

4.2 presents

4.1 Overview Schemes

common.

to

into classes that include all possible compounded classes [Prieto-Diaz 87]. These classes are then organized in a

system.

92] also have showed

sub-sections.

domain

Finally,

and Sutcliffe

schemes

components

overview

Section of

analogy.

enumerative

Finkelstein

alarm

several an

software

approaches

the

between

and the burglar

[Maiden

controller

are similarities

For example,

of

schemes.

classification

software

has

conceptual

b].

provides

classification It is generally

Lately, for

analysis

to

94] and Bhansali [93] have pioneered classifying high-level software artifacts, architectures and domain models.

of analogy. The aspects include procedural role of analogy in the design of software, derivation from analogous applications, types of

knowledge required, selection of analogous

83].

classification

Clustering

methods

adopted

consists

4.1

to the

in science.

Recently,

section

Section

at a given [Biela91]

of examples method

a pipe

85] and Biela

is low.

reuse [Prieto-Diaz91

discovery or invention. One example is the analogy between electricity and water flow in a pipe. In this case, voltage is like the water pressure, and current is similar to time.

clusters numerical

within

a cluster

is high,

while

the

171

software

classification.

Facet

Description Broad

Application

problem

inventory

area

1

control,

library

Domain Layer

Examples

I

domain

Resource

reusable,

The type of key objects

Type

Domain

High

level description

Abstraction

domain

Function

Key system

consumable

scheduling,

of primary

allocation

characteristics J

Layer

Relation

2

functions

Classes of semantic

Class

check_out, I reserve relations

return,

class inclusion,

for key

ca&e-

purpose

objects

safety,

Purpose

Main

Trigger

The type of triggering

design goal

Complexity

The degree of complexity

p roductivity

automatic, neridic

mechanism

manual,

J application Layer

The expected

Size

3

medium,

low

size of the

high, medium,

low

of the generated

high, medium,

low

software

application

domain

Certification

The quality

rating

Level

domain

Figure

high,

of the

domain

models

1. Hierarchy

4.2 Integration of Enumerative and Faceted Scheme

of Domain

Model

Facets

Domain

Hierarchy

by

concept

Poulin

and

classification namely, above layers.

of the article Yglesias,

is similar to that proposed a combination of i.e.,

Two

methods.

enumerative

classification

hierarchy

and

facets,

of a set of facets.

Figure

The hierarchy

three layers.

facets.

Each layer

1 illustrates

also represents

different

consists levels

presented

layer

are used as classifiers.

to

model

adopted

by Maiden

and Sutcliffe

similar

requirements The concept

proposed

data models

by Maiden group

is similar

by Bhansali

presented

application and key facts

in [Mineau

in this paper is similar

and Sutcliffe,

to the

[Bhansali 94].

93] The

to the idea

i.e., classes of domain

are identified by the key domain facts or characteristics. Each class consists of several application domains which share similar high-level generic abstractions.

of of of

Currently, abstractions,

abstraction. Facets in the first

proposed used

of domains.

facet approach

described

the concept

currently

classes

and generic

methods,

are

based on high-level

problem-class

are integrated. The approach consists of various Each level in the hierarchy, in turn, is composed

hierarchical

93]

domains about

The main

abstractions

[Maiden

defined

The usage

some commonly encountered mainly in the general business

in the paper to demonstrate

1 shows those domain

of an application domain facet is to ensure that applications in the same domain are grouped together in the classification stage. In this way, applications in the

Obviously, continuously

abstractions

the set of generic

domain area, are

the feasibility. and their

domain

Table

descriptions.

abstractions

will

as more research and experiment in Some areas like data base this area is conducted. management systems, networks, programming languages, and software engineering environments are considered as supporting systems instead of domain abstractions. The facet of domain abstractions is primarily used to select some analogous domains to facilitate the domain analysis process of the target if there is no existing products of the same domain available in the library.

same domain are always retrieved first for the target during the analogy phase. Critical objects or resources are then categorized. Grosz [Grosz 92] defined different types of resources. The categories include consumable resources (for instance, the product in the inventory system) and reusable resources (for example, books in a library). Consumable types are further composed of perishable (fresh products in a grocery) and nonperishable (hardware). Reusable objects are distinguished as

Facets

renewable objects (books in a library or video tapes in a rental store) and repairable objects (cars or airplanes). An object can also be characterized by more than one feature.

in

evolve

layer

2 primarily

serve

to

bridge

the

gap

between the generic domain abstractions and features in specific application domains. These facets are actually abstractions of software products developed in the domain

172

Table Some Representative

-nnrn v...

Object

2; n

-...

.

A h~frnotinn -w ...,.. .“UU

Amount

Control

I

This abstraction reached.

supports

an object

Abstractions

This abstraction

an analogy

for domains

amount

will

level

be ordered

Flv.m”l.c -(.u,,.~.w.

warehouse

room temperature

or

control

supports

and leaving

an analogy records

for domains

as objects

personnel system,

an environment.

Scheduling

This abstraction

supports

administration,

an analogy

for domains

that deal with scheduling objects in order to get a maximum productivity or efficiency with limited resources. Object

that monitor

supports

the moving

ensure the correct Object

Allocation

This abstraction that allocate

Object

for domains in a space to

positions. supports

an object

manufacturing vehicle trucks)

systems,

(aircraft, buses, dispatching

ATC,

airspace

navigational

systems,

manufacturing

an analogy

to another objects

for domains

object

(usually

are returned

after

systems

library

systems,

rental,

reservation

systems

car

(hotel,

airline)

of time.

This abstraction

Distribution

an analogy of objects

an agent). The allocated a period

zoo

control

systems

This abstraction

Positions

information student

animals Object

stock control,

is

is signaled.

that keep track of objects entering

I

when a minimum

A predefine

added, or a warning Recording

Domain

Tbw-rintinn -Vuw. .yuu..

that resupply

Object

1

supports

an analogy

for domains

that collect mass objects in a central location then distribute the objects into prespecified

and

parcel

delivery

systems,

goods distribution applications

destinations. Periodic

Object

This abstraction

[nitiating

for domains

banking

systems,

that periodically report or verify the status of an object, or issues some operations to other objects.

supports

an analogy

vehicles

(aircraft,

trucks,

cars) maintenance, recording inventory

periodic report, salary

systems Object Coordination

This abstraction that monitor

supports

an object

an analogy

for domains

class (vehicle),

object Simulation

signal

systems,

synchronize and coordinate other objects (traffic lights) to increase the efficiency or safety of the 3bject

traffic

control

traffic

management

systems

class (vehicle).

This abstraction

supports

an analogy

that simulate real world problems resources and analyze results.

for domains

by controlled

discrete

simulation,

continuous simulation, computer systems simulation

3bject

This abstraction

Combination

that collect objects

modeling functions

phase.

A

in the domain.

function

supports

individual

for update,

facet

The relation

objects analysis,

represents class

an analogy

depicts

and combine

between

two

entities

[Herrmann

those

or control.

traffic

management

systems, (POS)

words,

key

analogy

point-of-sale

systems

may be processed

differently

for different

types of relations. Bejar, et al. [Bejar 91] derived a taxonomy to group semantic relations. Detailed discussion of the classification of semantic relations is beyond the scope of this paper. With the taxonomy, th relations can be decomposed into common aspects that the systems are sharing and aspects that the systems differ,

the

type of semantic relations for critical objects. Relations between objects have been recognized as basic in analogical problem solving. Empirical evidence supports that comparison and evaluation of relations is a commonly used and effective approach to judge similarities

for domains

Thereby, relations can be better understood reasoning can be facilitated.

86, Chaffin

881. Studies in cognitive science also indicate that different relations ma~ be processed differently. In other

173

and analogical

Specific

Facet type car rental

Application

Facet Descriptions

problem

Domain Resource Layer

vehicle:

Type

reusable,

user: customer,

1

staff

I

repairable

agent

agent

Domain Abstraction

object

allocation

Function

users can check outheturnlreserve

vehicles

staff can search/manage/ttpdate/verify Relation

Class

user: vehicle staff

Layer

services

The system

allows

The system

calculates

fleet

Object Recipient

user

The system provides

Purpose

vehicle

Instrument

vehicle—Agent: — Agent:

staff

2

— Agent:

to allow

users to rent vehicles.

staff to keep track of vehicle the rental

fleet.

cost for users.

~ Trigger

Figure2. Purposes

or

information 85,

system

transfer

Holyoak

prioritized

goals from

design

goals.

Facet Descriptions

heavily

influence

a base to a target

The

89].

will

Specific

purpose Two

in

different

forthe

the

2 lists

domains

for the

concept,

but different

“maintain [Garot

goals.

safe, orderly,

87].

In FMS,

For ATC,

and expeditious

may have

the major

concern

quality

difference and problem

of traffic”

is how to schedule

Triggering

describes

the main

emphasis

cause of system

triggering

in

domains

need different library problem

with

complexity

one

of

artifacts, the

no matter

major

is an

are produced.

factors

in what that

a domain

contains

To form,

must

be

a set of sub-domains,

the iterative

process

can be applied

to examine

appropriate

facets.

For

the ATC

example,

and select consists

of

Thus, the ATC may include A FMS also contains sub-

domains.

The major

control

planning, [Lee 93].

scheduling,

monitoring,

4.3 Illustration Domain Models This

plays in some applications.

different

software

the models

method

level

functions

for

the FMS

and real-time

are

control

dynamics.

levels

may

design approaches. For example, and the car rental system have similw

the key

section

of the

explains

Classification

the task to classify

a target

of

domain.

The first step is to fill out the top two layers of a hierarchy of facets, as demonstrated in Figure 1, Layer 3 is this

Facets in the third layer are general software attributes. These attributes reveal another aspect of the domain and are used to bridge the gap between the domain and a Two specific application or design alternatives. analogous

rigorous

design

Certification

machine interface [Hunt 87]. several domain abstractions.

periodic triggering is a special case of automatic it is explicitly listed because of the important

role that periodic

is

to a simpler

problem.

several major functional elements. Those elements are planning, controlling, system, data managing, and man-

Presently, a distinction is made among automatic, manual, and periodic triggering for main domain transitions. Although triggering,

of how

In cases where

the main goal is to

will lead to different solving.

developer

rental

considered.

and coordinate machine stations to gain a high productivity rate and machine utilization, and at the same time reduce throughput time [p. 174, Talavage 88]. The significant reasoning

car

reuse existing

system (FMS) object monitoring flow

the

indicator

similar static structures and dynamic characteristics, but different goals. For example, the air traffic controller (ATC) and the flexible manufacturing presented in [Maiden 92] have a similar

Problem

lead the software

[Kedar-Cabelli

layer

Car Rental

figure will be examined and filled out after phase. For the car rental problem, Figure

the analysis 2 illustrates

those facets for the top two layers. A

domain

abstraction,

may since

consist a domain

of

more may

than include

one

domain

smaller

sub-

domains. The car rental problem shown above is limited to a specific task: manage the system to rent vehicles to customers. The problem can be expanded to include vehicle maintenance tasks. In other words, the system will keep a maintenance record for each vehicle and periodically signal the need for specific inspection or

features like checkout, return, and search. General library problems usually need a more sophisticated data base management system than can rental systems due to the larger volume of books than cars. The difference may

174

maintenance

work

the

boundary

domain

domain

for the vehicles.

abstraction,

as listed

which

in Table

domain

will

is enlarged

yield

1.

In such a situation,

For

to

different

features

include

is the periodic

The

another

expansion

hierarchy

for the new domain

abstraction.

Up

in

another

the

library

object

initiating

structure.

Figure

of

problem

approach.

The

the

of facets

specifically

object

this

point

abstraction

domain

information

level

have been identified.

analysis

generic

must

to facilitate further artifacts. A bridge

between

the

domain Figure

facts

some specific

reuse of existing reusable needs to be established

domain

or features.

a

The generic

with

abstraction

The

concept

and

3 is a domain

to a class of analogous domain independent

domains. features

abstraction

in

will

features

Reservation

in

reserve

the

is then deemed

for this class, the domain

since

rental for

design

as a domain-specific

feature

scratch

is not included is totally

domains,

then those domains

and design for this particular for the new domain.

Reuse

some

an object.

and

But the

For

example,

The analysis be facilitated

then

solutions into

flexible

models of

process by

or and

domains.

domain

reasoning

Classification

models

because

the

analogous

for the new target

and specific

architectures,

supports

similar

comparing

to analogous

generic

and improving.

also

of

leads

to

the adaptability

is

leverage

than

and domain

current

approaches

in

analysis.

5. Conclusion Directions

in

and

Future

Research

new to the

is needed.

sharing

in the same group.

to

problem

already embedded in the hierarchy. Adaptation is an important but often neglected processing stage in analogy [Keane 94]. In addition, the approach gives the analyst or

The newly

This

designed software artifacts are hence stored in the library. If the fact has been previously identified for some classified

to all

is that of time.

If the fact horn

problem

domain

can

more

For example,

a period

this characteristic

abstraction.

reuse library,

car

a vehicle

specific

a domain.

retrieval

domains.

more

can

in

keep evolving

of

analogy

the

are

a user can renew

and

software

of

which

generic

The second level

models

designer

customers

features

in both the car rental

applications

dependent, one

key

of this

abstraction,

domain

domains

common

This level represents within the domain

independent.

the

illustration

a domain

library systems may adopt different renewal as demonstrated in Figure 4. The reuse library of

abstraction. Domain-specific features are identified during the analogy process. These features lead to a subset of domains sharing the features. This level is domain but is application

problem, modeling

different policies

existing of Figure

problem,

identification

3.

The top level

a simple

shows

features

Classification

specific

is illustrated

some

to different

in the future

applications.

rental

same feature is not allowed in the airline reservation problem. The next level reveals features that are specific

to

high

car

in the same category.

For instance,

the library

this

level

and

the

a generic/specific

4 represents first

classified

domains.

values

However,

are at too

be provided

guidelines software

generic

facet

knowledge

abstractions

for specific

abstraction

domain

to guide the designer

and design

domain

to bereused

a generic

and specific

alone is not sufficient

reuse more

domain

process,

has been generated

forthetarget

because

the

and

yield

allocation,

domains represents

to

problem

the same feature

are

of existing

analysis

fact is then highly

possible

paper

described

the potential

of software

analogy.

Software providing

analogy can facilitate domain analysis tasks by analogous application areas which has been

previously presented

well analyzed and designed. The paper an approach to classifying high-level software

products a hybrid

in support of software analogy. The approach is of enumerative hierarchy and faceted scheme

approaches. For instance,

the hotel

the fact of reservation. examine reservation problem

management

system

The fact will

guide the designer

existing features

application in common.

is grouped

together

domains As a result, with

the hotel

also features to

More

that have the car rental reservation

software

problem under the same characteristic of reservation. After the identification of domain-specific features, the next level depicts the differences between applications in the same domain. For instance, different rental companies may have different levels can further specific

features.

reservation policies. be decomposed into For

example,

tools

feature

may be divided into two groups: one for car rental and hotel applications, the other one for airline reservation systems. As more research is conducted and more practical domain analysis .is performed, the classification will be more rigorous and have more accurate information.

175

and empirical

studies

are needed

classify domain models. to facilitate the retrieval

artifacts.

and

support different

The bottom two several layers of

the reservation

research

to effectively are necessary

Also,

repositories

an environment are

the analogy process representations.

required

in order

Supporting tools and storage of with to

integrated

systematically

and transformation

between

domain independent

\

.--”

I

I

domain dependent, application independent

feature

Figure

3. Hierarchical

domain abstraction

1

feature

...

View

of Analogous

Domains

m

and Applications

user checks outheturns staff manages/rrpdates/verifies/searches

... domainspecific features

‘?

‘?

applicationspecific features

@5Ex!!El Q

timing restrictions

Figure

4, An Illustration

176

of Domain

Hierarchy

References

[Greenspan 82] S. J. Greenspan, J. Mylopoulos, and A. Borgida, “Capturing more world knowledge in the requirements specification, ” m “ Proc. of Int’1 Conf on Software Engineering, 1982, pp. 225-234.

[Arango 89] G. Arango, “Domain analysis from art to engineering discipline,” in Proc. of the 5th Int’1 Workshop on Soflware Spec@cation and Design, 1989, pp. 152-159.

[Grosz 92] G. Grosz, “Building information system requirements using generic structures, ” in Proc. of [he 16th Int’1 Computer Sof~are & Applications Conf (COMPSAC), 1992, pp. 200-205.

[Arango 93] G. Arango, E. Schoen, and R. Pattengill, “A process for consolidating and reusing domain knowledge,” in Proc. of the Int’1 Con on Software Engineering, 1993, pp. 231-142.

[Hall 89] R. P. Hall, “Computational approaches to analogical reasoning: a comparative analysis, ” Artificial Intelligence, VOI. 39, no. 11, pp. 39-120, May 1989.

[Bailin 90] S. C. Bailin, J. M. Moore, R. Bentz, and M. Bewtra, “KAPTUR: Knowledge acquisition for preservation of tradeoffs and underlying rationales,” in Proc. of the 5th Knowledge-Based Sofiware Assistant Conf, 1990.

[Hanson 83] S. J. Hanson, “Conceptual clustering and categorization,” in Machine Learning: An Art@icial Intelligence Approach, vol 3, Y. Kodratoff and R. Michalski, Eds., Morgan Kaufmann Publishers, pp. 235-268, 1983.

[Bejar 91 ] I. I. Bejar, R. Chaffin, and S. Embretson, Cognitive and Psychometric Analysis of Analogical Problem Solving, Springer-Verlag, 1991.

[Harandi 93] M. T. Harandi, “The role of analogy in software reuse, ” in Proc. of 1993 ACM/SIGAPP Symposium on Applied Computing, 1993, pp. 40-47.

[Biela 91] A. Biela, Analogy is Science: From a Psychological Perspective, Peter Lang, 1991.

[Herrmann 86] D. J. Herrmann and R. Chaffin, “Comprehension of semantic relations as a function of the definitions of relations, ” in Human Memory and Cognitive Capabilities: Mechanisms and Pe~ormances, F. Klix and H. Hagendorf. Eds., Elservier Science Publishers B. V., North-Holland, 1986, pp. 311-319.

[Bhansali 93] S. Bhansali, “Architecture-driven reuse of code in KASE,” in Proc. of the 5th Conf on Sof~are Eng. & Knowledge Eng., 1992, pp. 100-109. [Biggerstaff 92] T. J. Biggerstaff, “An assessment and analysis of software reuse,” in Advances in Computers, vol. 34, 1992, pp. 1-57.

[Holyoak 89] K. J. Holyoak and P. Thagard, “Analogical mapping by constraint satisfaction,” Cognitive Science, vol. 13, pp. 295-355, 1989.

[Borgida 85] A. Borgida, S. Greenspan, and J. Mylopoulos, “Knowledge representation as the basis for requirements specifications,” Computer, pp. 82-90, April 1985.

[Hunt 87] V. P. Hunt and A. Zellweger, “Strategies for future air traffic control systems,” Computer, vol. 20, no. 2, pp. 19-32, Feb. 1987.

[Campbell 91] G. Campbell, N. Burkhard, J. Facemire, and J. O’Connor, Synthesis Guidebook, Technical Report SPC-91122MC, Software Productivity Consortium, Hemdon, VA, 1991.

[Johnson 92] W. L. Johnson, K. M. Benner, and D. R. Harris, “Applying domain and design knowledge to requirements engineering,” ACM SIGOIS Bulletin, vol. 13, no. 2, pp. 48-57, /w& 1992.

[Chaffin 88] R. Chaffin and D. J. Herrmann, “The nature of semantic relations: a comparison of two approaches,” in Relational Models of the Lexicon: Representing Knowledge in Semantic Networks, M. W. Evens, Ed., Cambridge University Press, 1988, pp. 289-334. [Cleveland 88] J. C. Cleaveland, “Building generators,” IEEE SofMare, pp. 25-33, July 1988.

[John-Steiner 85] V. John-Steiner, Mind: Explorations of Thinking, University Press, 1985.

application

[Kang 90] K. C. Kang, et al. Feature-oriented domain analysis (FODA) feasibility study, Technical Report CMU/SEI-90-TR21, 1990.

[Curtis 88] B. Curtis, H. Krasner, and N. Iscoe, “A field study of the software design process,” Commun. of the ACM, vol. 31, no. 11, pp. 1268-1287, NOV. 1988.

[Keane 94] M. T. Keane, “Analogical asides on case-based reasoning,” in Lecture Notes in Artficial Intelligence, Topics in Case-Based Reasoning, vol. 837, Springer-Verlag, 1994.

[Devanbu91] P. Devanbu, R. Brachman, P. G. Selfridge, and B. W. Ballward, “LaSSIE: a knowledg-based software information system,” Commun. of the ACM, vol. 34, no. 5, pp. 34-49, May 1991. [Finkelstein requirements Sept. 1988.

Notes of the of New Mexico

[Kedar-Cabelli 85] S. Kedar-Cabelli, “Purpose-directed analogy,” in Proc. of Cognitive Science Society Conf, 1985, pp. 150-159.

88] A. Finkelstein, “Re-use of formatted specifications, ” Software Eng. J., pp. 186-197,

[Kedar-Cabelli 88] S. Kedar-Cabelli, “Analogy - from a unified perspective, ” in Analogical Reasoning, D. H. Helman, Ed., Kluwer Academic Publishers, 1988, pp. 65-104.

[Garot 87] J. M. Garot, D. Weathers, and T. Hawker, “Evaluating proposed architectures for the FAA’s advanced automation system,” Computer, vol. 20, no. 2, pp. 33-46, Feb 1987.

[Lee 93] Y. K. Lee and S. J. Park, “OPNets: an object-oriented high-level Petri net model for real-time system modeling,” J. of Systems Software, vol. 20, no. 1, pp. 69-86, Jan. 1993.

177

[Leishman 90] D. Leishman, “An annotated bibliography of works on analogy, ” Int’1 J. of Intelligent Systems, vol. 5, no. 1, pp. 43-82, March 1990.

[Prieto-Diaz 87] R, Prieto-Diaz, “Domain analysis for reusability, ” in Proc. of the Ilth Int’1 Computer Software & Applications Conf (COMPSAC), 1987, pp. 23-29.

[Lubars 91] M. D. Lubars, “Domain analysis and domain engineering in IDeA, ” in Domain Analysis and Software Systems Modeling, R. Prieto-Diaz and G. Arango, Eds., IEEE Computer Society Press, Los Alamitos, CA, 1991, pp. 163-178.

[Prieto-Diaz 91a] R. Prieto-Diaz and G. Arango, Eds., Domain Analysis and Software Systems Modeling, IEEE Computer Society Press, Los Alamitos, CA, 1991. [Prieto-Diaz 9 lb] R. Prieto-Diaz, “Implementing faceted classification for software reuse,” Commun. of the ACM, vol. 34, no. 5, pp. 89-97, May 1991.

[Lung 93] C. H. Lung and J. E. Urban, “Integration of domain analysis and analogical approach for software reuse, ” in Proc. of 1993 ACM/SIGAPP Symposium on Applied Computing, 1993, pp. 48-53.

[Prieto-Diaz reusability,”

[Lung 94] C. H. Lung, An analogy-based domain analysis methodology, Ph.D. Dissertation, Dept. of Comp. Sci. and Eng., Arizona State University, Tempe, AZ, 1994.

software

[Shlaer 89] S. Shlaer and S. J. MeHor, “An object-oriented approach to domain analysis, ” Sof2ware Enginering Notes, vol. 14, no. 5, July 1989, pp. 66-77.

[MacLean 91] A. MacLean, V. Bellotti, and R. Young, and T. Moran, “Reaching through analogy: a design rationale perspective on roles of analogy,” in Proc. of the Conf on Human Factors in Computing Systems, 1991, pp. 167-172.

[Silverman 85a] B. G. Silverman, “The use of analogs in the innovation process: a software engineering protocol analysis,” IEEE Trans. Systems, Man, and Cybernetics, vol. SMC- 15, no. 1, pp. 30-44, Jan./Feb. 1985.

[Maiden 92] N. A. M. Maiden and A. G. Sutcliffe, “Exploiting reusable specifications through analogy,” Commun. of the ACM, vol. 35, no. 4, pp. 55-64, April 1992.

[Silverman 85b] B. G. Silverman, “Software cost productivity improvements: an analogical view,” Computer, 18, no. 5, pp. 86-96, May 1985.

[Maiden 93] N. A. M. Maiden and A. G. Sutcliffe, “Requirements engineering by example: an empirical study,” in Proc. of IEEE Int’1 Symposium on Requirements Eng., 1993, pp. 104-111.

and vol.

[Simos 91] M. A. Simos, “The growing of an organon: a hybrid knowledge-based technology and methodology for software reuse,” in Domain Analysis and Soflware Systems Modeling, R. Prieto-Diaz and G. Arango, Eds., IEEE Computer Science Press, Los Alamitos, CA, 1991, pp. 204-221.

“Reusable software component [McCain 85] R. MaCain, of 5th AIAA/A CM/NASA/IEEE construction, ” in Proc. Computers in Areospace Conf, 1985, pp. 125-135. [Michalski 83] R. Michalski and observation: conceptual clustering, ” Artificial Intelligence Approach, vol Michalski, Eds., Morgan Kaufmanrr 1983.

93] R. Prieto-Diaz, “Status report: IEEE Sof~are, pp. 61-66, May 1993.

[Talavage 88] J. Talavage and R. G. Hannam, Flexible Manufacturing Systems in Practice: Applications, Design, and Simulation, Marcel Dekker, Inc., New York, NY, 1988.

R. Stepp, “Learning for in Machine Learning: An 3, Y. Kodratoff and R. Publishers, pp. 331-363,

[Wartik 92] S. Wartik and R. Prieto-Diaz, “Criteria for comparing reuse-oriented domain analysis approaches,” Int’1 J. of Soflware Eng. and Knowledge Eng., vol. 2, no. 3, pp. 403432, Sept. 1992.

[Mineau 94] G. W. Minuau and R. Godin, “Automatic sturcturing of knowledge bases by conceptual clustering, ” to appear in IEEE Trans. of Data and Knowledge Eng.. [Miriyala 89] K. Miriyala and M. T. Harandi, “Analogical approach to specification derivation, ” in Proc. of 5th Workshop on Sofmare Specification and Design, 1989, pp. 203-210. [Neal 90] L. Neal, “Support for software design, development, and reuse through an example-based environment, ” in Proc. of the 5th Conf on Knowledge-based SofWare Assistant, 1990, pp. 176-182. [Neighbors 84] J. M. Neighbors, “The Draco approach to constructing software from reusable components, ” lEEE Trans. on Soflware Engineering, vol. 10, no. 5, pp. 564-574, Sept. 1984. [Poulin 93] J. S. Poulin and K. P. Yglesias, “Experiences with a faceted classification scheme in a large reusable software library (RSL),” in Proc. of the 17th Int’1 Computer Software & Applicatfins Conf (COMPSAC), 1993, pp. 90-99.

178