1

Open Reuse of Component Designs in OPM/Web

Iris Reinhartz-Berger1 Dov Dori1,2 and Shmuel Katz1 1 Technion, Israel Institute of Technology

Technion City, Haifa 32000, Israel 2 Massachusetts Institute of Technology

77 Massachusetts Avenue Cambridge, MA 02139, USA

Emails: {ieiris@tx, dori@ie, katz@cs}.technion.ac.il Abstract

As system structural and behavioral complexity has increased, so has the interest in reusing software

components in early development phases. While most current modeling methods support design of

generic parameterized frameworks or patterns and weaving them into specific models, they do not

support open reuse, i.e., the ability to develop partially specified components and refine them in the

target application. We introduce an open reuse formalism that is based on principles from aspect-

orientation and OPM/Web, an extension of Object-Process Methodology for distributed systems and

Web applications. Our open reuse is accomplished by a three-step process, consisting of designing

reusable models, creating basic woven models, and enhancing their specification. We model a reusable

component through partially specified environmental objects, processes, and links that are bound to

concrete counterparts when the component is integrated into the system under development. Rules for

modeling and combining components are defined and exemplified through cases from the domain of

Web applications.

Keywords: component-based software development; software architecture, framework, and design

patterns; distributed systems; Internet and Web-based systems; aspect-oriented programming; Object-

Process Methodology.

1. Introduction

The last few decades have witnessed increasing interest in software reuse, i.e., the use of existing

software artifacts or knowledge to create new software [FT96]. Software reuse aims at improving

software quality and productivity by integrating commercial off-the-shelf (COTS) products, which

reduce debugging and maintenance time. Early software reuse concerned the combination of reusable

source code components, including COTS ones, to produce application software [MMM95]. The

object-oriented paradigm highlighted the importance of reusability as part of the development process

by using classes, packages (modules), and the inheritance mechanism as primary linguistic vehicles

for reuse [BO94]. The current definition of software reuse encompasses all the resources used and

produced during the development process, including reuse of requirements, architecture, design,

implementation, and documentation.

2

We distinguish two reuse categories: closed reuse and open reuse. Closed reuse incorporates

existing complete, stand-alone modules or components, such as packages or classes, into new

applications via the components' interfaces [BGJ99]. Most software engineering methods support

closed reuse by parameterization and binding capabilities. In open reuse, we integrate partially

specified components into one combined model. Like closed reuse, open reuse encompasses the

design of reusable models and their complex integration with the system under construction. In

addition, open reuse enables enhancing and optimizing the integrated components during the analysis

and design phases. Such optimization is possible by specifying the open constituents within the

reusable components in a way that best suits the task at hand.

The platform we suggest for both the closed and open reuse formalism is OPM/Web [RDK02], an

extension to the Object-Process Methodology (OPM) for distributed systems and Web applications.

OPM [DO95, DO02] extends the object-oriented paradigm with a new entity, called process, which is

a pattern of transformation (consumption, generation, or change) that objects undergo. This provides

OPM with a straightforward way for specifying stand-alone processes. Such processes, which are not

owned by (or encapsulated in) a specific object and therefore cannot abide by the object-oriented

encapsulation principle, are prevalent in models of real-life systems. For example, manufacturing

cannot conceivably be owned by raw materials, machines, products, or models. Rather, it involves all

of them.

The paper is organized as follows. Section 2 reviews existing reuse specification techniques and

argues that they handle primarily closed reuse. Section 3 specifies rules for weaving components in

OPM/Web and discusses the semantics of the resulting models. Section 4 demonstrates the process of

weaving models on a Web-based example, while Section 5 summarizes the contributions of this work.

2. Reuse of Component Designs in Modeling Techniques

Current object-oriented approaches, notably UML [UML00, MLS98, LWB98] and OPEN [GHY97],

emphasize the importance of reuse during the development process and enable it through classes,

packages, and the inheritance mechanism. However, once the classes and packages have been

modeled, they are treated as closed, black boxes with interfaces, through which other parts of the

model or other models can communicate. This approach hinders reusing generic models in different

contexts, where they can be effectively woven into various locations throughout an application under

development. To respond to this challenge, aspect-oriented approaches [CES97, CA99] introduce the

concept of aspect, which modularizes the features for a particular concern and describes how these

features should be woven, i.e., incorporated and integrated, into the system model. Superimposition

language constructs [KA93, BF88, BK89] similarly extend the functionality of process-oriented

systems, again cutting across the software architecture of process hierarchy.

Recent attempts have been made to extend the aspect notion from programming to software design

[BE98, KM99, CBE99] and to software engineering [ASE01, GR00]. Most aspect-oriented modeling

3

techniques are based on UML and add stereotypes to model the new aspect-oriented concepts.

Catalysis [DW98] is an example of an OMG-compliant methodology for component and framework-

based development. Troll [EAN01] and Composition Patterns [CW01] suggest adding

parameterization and binding capabilities to UML packages. Mixin-based approaches [FKF98] apply a

calculus for defining generic subclasses, which are parameterized over superclasses. While these

methods handle closed reuse, they lack the ability to support the development of several components

into complete systems. Such support is often essential for optimizing and enhancing the design of an

entire model – a mission that goes beyond binding existing components together.

Object-Process Methodology (OPM) [DO95, DG96, PD99, DO01, DO02] has been found to be a

suitable candidate for serving as a basis for open reuse, since it integrates concepts from the object-

and process-oriented approaches within a single frame of reference. The elements of the OPM

ontology are things and links. A thing is a generalization of an object and a process – the two basic

building blocks of any system expressed in OPM. Analogously, links can be structural or procedural.

Structural links express structural relations between pairs of objects, such as aggregation and

generalization, in order to model the static view of a system, which is hardly changed over time.

Procedural links connect objects and processes to describe the behavior of a system – how processes

transform (generate, consume, or change) objects. OPM manages complex system models through two

refinement/abstraction mechanisms: unfolding/folding, which is used for detailing/abstracting the

structural parts of a thing, and in-zooming/out-zooming, which exposes/hides the inner details of a

thing within its frame. This way OPM enables specifying a system to any desired level of detail

without losing legibility and comprehension of the resulting model. Modeling the system’s structure

and dynamics in the single OPM model benefits from the ability to automatically generate

implementation artifacts. In other words, the code generated from an OPM model describes the system

dynamics, not just its skeleton, as is often the case with other modeling approaches. The main

limitation of OPM with respect to reusability is that it is not geared towards the integration of a

number of semi-specified component designs into one model of a complete application.

3. Weaving OPM/Web Models

OPM/Web [RDK02] extends OPM for the domains of distributed systems and Web applications.

These extensions include the ability to characterize links with specific features (objects and/or

processes), extending the refining mechanisms to increase modularity, separating between the

definition of a process class and process instances (occurrences) of that class to model code migration,

and adding global data integrity and control constraints to express dependence or temporal relations

among physically separate modules. In this work, we endow OPM/Web with open reuse capability.

The open reuse is achieved by a three-step process, consisting of (1) designing reusable components,

(2) integrating these components to create basic woven models, and (3) enhancing the basic woven

models into complete applications. While the first two steps could be partially carried out by applying

4

UML, the third step is not supported by object-oriented methods, since their resulting woven models

are structural in nature and closed through pre-defined parameters. This section explains the

semantics of each step of the weaving process and specifies the rules for checking and validating its

legality.

3.1 Designing Reusable Models

The specification and design of each reusable model is carried out using OPM/Web. A thing (object or

process) in an OPM/Web model, which needs further specification in the target system to which it

may be bound, is defined as environmental. In OPM, an environmental thing is completely external to

the system, as opposed to a systemic thing, which is internal to the system. In OPM/Web, an

environmental thing can have partly specified internal structure, which may contain both systemic and

environmental components. When components are woven into one model, each environmental thing in

the combined model is either bound to a specific thing or left as an unbound requirement. A

component may also include requirements related to things in the target system to which it is bound.

Such requirements are expressed by environmental (symbolized as dashed) links, which connect pairs

of environmental things. As explained in Section 3.2, an environmental link in a reusable component

requires the existence of a corresponding link in the target system model.

Figure 1. A reusable Timed Execution Model

Figure 1 shows an example of a reusable model for adding time recording capability to a process

execution. The model, called Timed Execution Model, attaches to each Data Item a timestamp, Time.

Data Item and Time characterize (are the attributes of) Node. Data Item is environmental since it needs

to be refined and adapted to the various contexts in which this model is reused. Time, on the other

hand, is systemic – it is internal to the model and will remain the same regardless of the context of

Data Item. Similarly, Process Executing should be adapted to a specific process in the target system

and is therefore denoted as an environmental process, while Time Recording is a systemic process. The

environmental effect link between Process Executing and Data Item means that a systemic effect link

must exist between the process bound to Process Executing and the object bound to Data Item. This

implies that the Timed Execution Model is to be reused only with processes that affect the data, i.e.,

LEGEND Systemic object

Environmental object

Systemic process

Environmental process

Characterization

Instrument link

Effect link

Environmental effect link

5

change its value. If Data Item and Process Executing were not related in the reusable model, Process

Executing could be bound to a process that is not necessarily connected to the object bound to Data

Item, or has arbitrary connection with it.

3.1.1 Intra-Model Weaving Rules

OPM/Web models are required to abide by intra-model weaving rules, which include the scaling and

the link attachment rules defined below. These rules state what can and cannot be done within a single

OPM/Web model.

The scaling rule: A systemic thing can only be refined (unfolded or in-zoomed) by other systemic

things, while an environmental thing can be refined by environmental or systemic things.

In Figure 1, Time-Stamped Executing is an environmental process, since it contains an

environmental process, Process Executing. Similarly, the object Node is environmental, since one of

its attributes, Data Item, is environmental.

The link attachment rule: Two things in a reusable component that are connected by an

environmental link must both be environmental, while systemic links can connect either systemic or

environmental things. Note that a systemic link can connect two environmental things, implying that

even if the things bound to the environmental things are not explicitly connected in the target model,

an implicit systemic link between them exists in the combination. For example, if the environmental

effect link between Data Item and Process Executing in Figure 1 was replaced by a systemic one, then

the things in the target model that are bound to Data Item and Process Executing would have been

connected by an effect link, even though this link might not be explicitly specified in their model.

3.2 Creating Basic Woven Models

Having created a set of OPM/Web components, the designer should decide which components are to

be woven into the target model and how to weave them such that the combined model meets the

required specifications. Each model, be it a reusable component or a target model, is contained in a

rectangular frame, called a model object. We thus consider integrating model objects. The relations

between the model objects can be bi-directional, although usually one model object is a generic

reusable component and the other model object is the target one and is specific. The resultant model,

i.e., the woven model, can be entirely concrete, or it may still contain environmental elements, which

imply that the weaving process is not yet complete.

Next, the designer can connect each environmental thing of an OPM/Web model object with an

environmental or systemic thing of another model object. Since each model object may contain things

that need to be bound at different levels of refinement, the designer can successively apply the

appropriate series of refining steps to get the needed design portion. The model in Figure 2, for

example, weaves the Timed Execution Model of Figure 1 into a specific DB Maintenance Model, such

that the combined specification contains two model objects – the Timed Execution Model and the DB

6

Maintenance Model. The Timed Execution Model shows Time-Stamped Executing in-zoomed, while the

DB Maintenance Model shows DB Handling in-zoomed.

Generalization-specialization relations are the primary means for binding between things in any two

different models. This relation gives rise to object-oriented inheritance by providing not only for

structural object inheritance, but also for process inheritance, which is behavioral in nature. Object

inheritance implies that the sub-object class exhibits at least the same set of attributes and methods as

the super-object class. Process inheritance means that the sub-process class has at least the same

interface (i.e., the set of procedural links) and behavior (i.e., sub-processes) as the super-process class.

The interface and behavior of the inheriting process class may be extended or restricted. This way,

things in OPM/Web can inherit not just complete classes, as in UML, but also partially specified

objects or processes. In both inheritance types, multiple inheritance and cases in which several sub-

classes inherit from the same super-class are allowed.

Figure 2. A legal OPM/Web woven model. The Timed Execution Model is woven into the

DB Maintenance Model.

Figure 2 shows three generalization-specialization relations: one object inheritance relation –

between Data Item and Record, and two process inheritance relations – one between Process Executing

and DB Updating and the other between Time-Stamped Executing and DB Handling. These relations

imply that in the combined model, DB Updating affects Record and uses Time as an instrument without

changing it.

LEGEND Systemic object

Environmental object

Systemic process

Environmental process

Characterization

Aggregation

Generalization

Instrument link

Effect link

Environmental effect link

Timed Execution Model – In zooming of Time Stamped Executing

DB Maintenance Model – In zooming of DB Handling

7

3.2.1 Inter-Model Weaving Rules

Each woven model is required to preserve the intra-model weaving rules, i.e., the scaling and link

attachment rules defined in Section 3.1.1. In addition, they should preserve three inter-model weaving

rules, which apply to an integration of several models. These rules, the minimal binding, hierarchy

congruence, and link precedence rules, are defined below.

The minimal binding rule: Each environmental thing in a model object must be bound to a

corresponding thing in another model object, either explicitly or implicitly. A generalization-

specialization relation achieves explicit binding, while implicit binding is applicable only to a

compound environmental thing. A compound thing is an object or a process that is further refined and

is therefore not at the lowest level of detail. For each compound environmental thing in the reusable

model that is not explicitly bound to a thing in the target model, a default systemic thing is considered

to be generated in the combined model. This default thing includes all the specific things bound to its

environmental constituents.

The woven model in Figure 2 explicitly binds three environmental things from the Timed Execution

Model: Data Item, Time-Stamped Executing, and Process Executing. For the fourth environmental thing

in that model, Node , a default systemic object is implicitly generated in the combined model, including

Record. The default object also inherits Time from Node. Likewise, if there was no process inheritance

relation between Time-Stamped Executing and DB Handling, then a default process would be implicitly

generated for Time-Stamped Executing, consisting of DB Updating and inheriting Time Recording from

Time-Stamped Executing. Since DB Handling is bound to Time-Stamped Executing, their combination

also includes Consistency Checking. Data Item and Process Executing must be explicitly bound to

things in the target model since they are lowest level things.

The hierarchy congruence rule: The hierarchy structure between environmental things in a

reusable model must be congruent with that of the things bound to them in the target model. Hence, if

there is a parent-child relation between two environmental things in a reusable component and these

things are explicitly bound to things in the target model, then there must be a parent-child relation

between the corresponding bound things.

As an example, DB Handling in Figure 2 is bound to Time-Stamped Executing, while Process

Executing is bound to DB Updating. The parent-child relation between Time-Stamped Executing and

Process Executing is maintained in the specif ic model by DB Handling and DB Updating. The hierarchy

congruence rule disallows binding Time-Stamped Executing with Consistency Checking and at the

same time Process Executing with DB Updating.

The link precedence rule: The binding of an environmental link is implicitly determined from the

bindings of its connected things. Moreover, environmental links can be bound to systemic links which

are at least as strong as the environmental according to the link precedence order. OPM’s link

8

precedence order determines that the consumption/result links are the most powerful. These links are

followed by effect links, then agent and instrument links, and finally condition and event links.

The environmental effect link between Data Item and Process Executing in Figure 2 is implicitly

bound to the systemic effect link between Record and DB Updating. The link precedence rule implies

that the link between any object and process that are bound to Data Item and Process Executing must

be at least as strong as an effect link. Thus, a legal binding can connect them with an object and a

process which are already connected by a consumption, result, or effect link.

3.2.2 Semantics of Basic Woven Models

The semantics of the generalization-specialization relation between model objects is similar to their

semantics within a single model. An object can inherit the features (attributes and operations) of a

partially specified (environmental) object. Similarly, a process can inherit the behavior (sub-processes)

and interface (procedural links) of a partially specified (environmental) process. In the woven model

of Figure 2, Node exhibits two attributes, Time and Record, where the latter inherits from Data Item. DB

Handling consists of three sub-processes: Time Recording, DB Updating, and Consistency Checking. DB

Updating inherits from Process Executing an instrument link to Time and adds an effect link to Record.

In other words, DB Updating uses Time as an extra input and changes Record.

If different types of links exist between two environmental things and their corresponding things in

a bound model, then the more powerful link (according to the link precedence order) prevails. If there

was a systemic instrument link between Data Item and Process Executing in the Timed Execution Model

of Figure 2, it would be subsumed by the effect link between Record and DB Updating in the

combination, because an effect link takes precedence over an instrument link.

Generalization-specialization relations between processes define also a partial execution order

between the sub-processes of an individual process. The time axis in an OPM/Web System Diagram

(SD) goes from the top of the diagram to its bottom within each in-zoomed process. Hence, two

independent or concurrent sub-processes are depicted at the same vertical level. The generalization-

specialization relations between models merge the partial orders from each model into one combined

partial order. In Figure 2, there is a total order in both the Time Execution Model (first Time Recording

and then Process Executing) and in the DB Handling Model (first DB Updating and then Consistency

Checking). The generalization-specialization relation between Process Executing and DB Updating

defines a complete execution order in the woven model: Time Recording, DB Updating, and

Consistency Checking. If DB Handling contained a sub-process before DB Updating, say DB Reporting,

then the generalization-specialization relation between Process Executing and DB Updating would

determine a partial order, in which Time Recording and DB Reporting are independently executed first,

followed by DB Updating, and finally Consistency Checking.

The single model constructed by applying the above semantics of environmental elements and

generalization-specialization relations is the fully expanded model. The woven models can be

9

maintained either as component models, or as fully expanded models, as will be demonstrated in

Section 4.2. Assuming a semantic definition of a single OPM/Web model, the equivalent fully

expanded model is the semantics of the basic woven models.

3.3 Enhancing Basic Woven Models

Having created the basic woven model, the system architect can continue specifying the combined

system in a separate layer without affecting the composing model objects. This layer includes the

generalization-specialization relations between the model objects and additional intra- and inter-

relations. This stage may include reusing aspects, integrating stand-alone modules, or modeling new

requirements following OPM/Web rules. As demonstrated in Section 4.3, this stage enables

optimization and minimization of the combined models as a complete application which offers

functionality that goes beyond that of each of the individual model objects.

4. Reusing OPM/Web Models: The Accelerated Search Web-Based Example

We use the Accelerated Search System to demonstrate the OPM/Web weaving process described in

Section 3. The Accelerated Search System implements an algorithm for improving the performance of

a search engine that uses very large databases requiring time-consuming search algorithms.

The design of the Accelerated Search System includes two model objects – a reusable one, called

the Acceleration Model, and a specific one, called the Multi-Search Model. The Acceleration Model

specifies a generic algorithm that reduces the execution time of an input-output part of a system by

trying first to retrieve the output, which is determined by the input, from a database. If the entry is not

already in the database, it activates a process that calculates the sought output and records it in the

database to accelerate future executions of the algorithm with the same input. The Multi-Search Model

implements a new search engine that benefits from existing search engines by combining their results

and ordering them according to a weighted score. We assume that the database in which the term is

searched is static and rarely changed, so the query results remain valid in consequent activations of the

query with the same input. Previous query results can therefore be stored to avoid executing the costly

calculation each time a query with that input is submitted.

4.1 The Acceleration and Multi-Search Models

Figure 3 specifies the Acceleration Model in OPM/Web. The algorithm consists of three main steps:

searching the DB for an input-output entry, retrieving the output if it was found in the database, and

activating the full process otherwise. The Acceleration Model contains two environmental objects, Input

and Output, and one simple lowest-level environmental process, Original Processing. The scaling rule

implies that Accelerating and Full Process Activating are also environmental processes, since they

contain an environmental process, Original Processing. All the other things, including the object DB,

10

the Boolean object Found, and the processes DB Searching and Output Retrieving, are systemic, as they

are internal to the generic model.

Figure 3. An OPM/Web specification of the Acceleration Model. (a) SD is the top-level

diagram. (b) SD1 zooms into Accelerating of SD. (c) SD1.1 zooms into Full Process

Activating of SD1.

Figure 4. An OPM/Web specification of the Multi-Search Model. (a) SD is the top-level

diagram. (b) SD1 zooms into Multi Searching of SD.

LEGEND Systemic object

Environmental object

Systemic process

Environmental process

Generalization

Instrument link

Result/consumption link

Effect link

Condition link

c

(a) SD

(b) SD1

(c) SD1.1

(b) SD1 (a) SD

11

Figure 4 contains an OPM/Web specification of the Multi-Search algorithm. Figure 4(a) is the top-

level diagram which specifies the inputs (Term and Query Result Msg) and outputs (Query Msg and

Search Result) of the algorithm. The diagram in Figure 4(b) shows that Start Searching uses Term to

create three queries, one for each search engine. Query Sending then sends the three queries to the

relevant search engines and Result Waiting waits until all three replies have arrived and then outputs

them. Finally Result Merging combines the results to get the Search Result.

Since the Multi-Searching process depends on the speed of each search engine, the network response

time, and the number of results each search engine supplies, the response time of Multi-Searching may

be slow. To improve this response time, we weave the Acceleration Model into the Multi-Search Model,

so the latest searched terms and their results are saved in a local database, which is searched before

invoking the entire Multi-Searching process.

4.2 The Basic Acceleration/Multi-Search Model

Figure 5 shows the generic Acceleration Model woven into the target Multi-Search Model to create the

basic woven model, called Acceleration/Multi Search Model, which consists of two model objects. The

Acceleration Model object shows Full Process Activating of Accelerating in-zoomed, while the Multi-

Search Model object shows the top-level diagram. Three generalization-specialization relations connect

the two model objects. Two of these relations are between object classes, specifying that Term is an

Input and that Search-Result is an Output. The third generalization-specialization relation is between

two process classes, specifying that Multi-Searching specializes Original-Processing. Full Process

Activating is implicitly bound to a default systemic process that includes just Multi-Searching. These

bindings are legal according to the minimal binding rule, since each one of them connects a simple

(lowest level) thing: Input, Output, and Original Processing.

Figure 5. An OPM/Web specification of the Acceleration/Multi-Search Model

Acceleration Model –

Full Process Activating of Accelerating

Multi-Search Model– Top Level

Acceleration/Multi-Search Model

LEGEND Systemic object

Environmental object

Systemic process

Environmental process

Generalization

Instrument link

Result/consumption link

Effect link

Condition link

c

12

To show the advantage of weaving a generic model over conventional modeling, Figure 6 shows an

OPM/Web specification of the fully expanded version of the Acceleration/Multi-Search Model achieved

by completely specifying the same system without weaving any reusable model. The resulting model

is specific to the problem and is more complex than the one obtained by weaving. In order to reuse the

acceleration part of this model in another system, such as a system that finds the shortest path between

two nodes in a network, the developer must remodel the acceleration functionality to fit the new

problem. The woven model in Figure 5 enjoys the benefits of generality, which makes it reusable for a

variety of functions having the same core architecture.

Figure 6. The expanded Acceleration/Multi-Search Model. (a) SD is the top-level diagram.

(b) SD1 zooms into Accelerating/Multi-Searching of SD. (c) SD1.1 zooms into Full Search

Activating of SD1. (d) SD1.1.1 zooms into Multi searching of SD1.1.

4.3 Enhancing the Basic Acceleration/Multi-Search Model

The equivalent semantics of the woven and expanded models, shown in Figures 5 and 6 respectively,

makes it possible to treat woven models as regular OPM/Web models. The designer can continue

specifying the combined system and integrate other reusable models into it. Below we show how the

Acceleration/Multi-Search Model can be extended to maintain a log file or to improve the Result

(d) SD1.1.1

(b) SD1

(c) SD1.1

(a) SD

13

Merging algorithm. Any combination of these refinements can be part of the system design, and they

may be incorporated into the system in any order.

Figure 7. Reusing of the Log Recording Model in the Acceleration/Multi-Search Model

Figure 8. An improvement of the Result Merging algorithm of the Acceleration/Multi-

Search Model

Acceleration/ Multi-Search Model

Multi-Search Model – Multi -Searching

Acceleration Model – Full Process Activating

of Accelerating

LEGEND Systemic object

Environmental object

Systemic process

Environmental process

Inheritance

Characterization

Aggregation

Instrument link

Result/consumption link

Effect link

Event link

Condition link

Invocation link c

e

Acceleration Model –

Full Process Activating of Accelerating

Multi-Search Model–

Top Level

Acceleration/Multi-Search Model

Log Recording Model - Top Level

e

14

Figure 7 shows an integration of a Log Recording Model into the Acceleration/Multi-Search Model.

The Log Recording Model includes a Log File along with its Log Records and a Recording operation.

The interface to the Log Recording Model consists of the recording Input. When weaving the model

into the Acceleration/Multi-Search Model, Term serves as an Input. In addition, the models are connected

with an event link and an invocation link to denote the recording triggers: Recording is activated

through a DB change event or a Multi-Searching process termination event, respectively.

As another example, consider improving the Result Merging process by adding the capability to

retrieve from the database related term-result pairs and use them to decide how to score the new search

results. To achieve this function, the Acceleration/Multi-Search Model is refined with an extra

instrument link from DB (of the Acceleration Model) to Result Merging (of the Multi-Search Model), as

shown in Figure 8. This means that DB is an additional input to Result Merging. In order to allow this

binding, the in-zoomed version of the Multi Searching process is shown in the Multi-Search Model

object. Further in-zooming of Result Merging would contain details of how the database added by the

Acceleration Model improves the merging of the query results.

5. Summary

OPM/Web supports open and closed reuse through several extensions to the basic OPM model. The

main extensions are the distinction between systemic and environmental elements (objects, processes,

and links), and the ability to construct a system model from several model objects. A set of rules

determines how to create reusable models and how to weave them into various target models to obtain

refined models. The weaving process of OPM/Web includes developing reusable models by using

environmental elements, binding models via structural and procedural links, and continuing the

specification process of the combined model. This approach advocates maintaining the reusable

models at a high level of abstraction and refining them in specific contexts. The use of a combination

of object- and process-oriented vocabulary through OPM/Web enables also modeling partially

specified processes and adapting them to specific target models. Potentially, the OPM/Web weaving

mechanism proposed in this work should allow automatic generation of the combined model

implementations – both code and database schemes. Further work is planned to establish a software

system development process that employs OPM/Web to weave generic models, and support version

control and configuration management of its models.

References

[ASE01] The Aspect-Oriented Software Engineering Web site. http://www.comp.lancs.

ac.uk/computing/aop/index.html

[BE98] Becker, U. D2AL – A design-based aspect language for distribution control. Proceedings of

the Europe Conference on Object-Oriented Programming (ECOOP), 1998.

15

[BF88] Bouge, L. and Francez, N. A Compositional Approach to Superimposition. Proceedings of

ACM POPL88 Symposium, 1998, pp. 240-249.

[BGJ99] Barber, K.S., Graser, T.J. and Jernigan, S. R. Increasing Opportunities for Reuse through

Tool and Methodology Support for Enterprise-wide Requirements Reuse and Evolution.

Proceedings of the 1st International Conference on Enterprise Information Systems, 1999, pp.

383-390.

[BK89] Back, R.J.R. and Kurki-Suonio, R. Decentralization of Process Nets with Centralized

Control. Distributed Computers, 3, 1989, Springer-Verlag, pp. 73-87.

[BO94] Booch, G. Object-Oriented Analysis and Design with Application. Benjamin/Cummings

Publishing Company, Inc., 1994.

[CA99] Cardone, R. On the Relationship of Aspect-Oriented Programming and GenVoca.

Proceedings of the 9th International Workshop on Software Reuse (WISR’99), 1999.

http://www.cs.utexas.edu/users/richcar/aopwisr.html

[CBE99] Constantinides, C. A., Bader, A., and Elrad, T. An Aspect-Oriented Design Framework

for Concurrent Systems. Proceedings of the Europe Conference on Object-Oriented

Programming (ECOOP), 1999, pp. 340-352.

[CES97] Czarnecki, K., Eisenecker, U. W. and Steyaert, P. Beyond Object: Generative

Programming. Proceeding of the Aspect-Oriented Programming Workshop at ECOOP’97, June

1997, pp. 1-8.

[CW01] Clarke, S. and Walker, R.J. Composition Patterns: An Approach to Designing Reusable

Aspects. Proceeding of the International Conference on Software Engineering, 2001.

[DG96] Dori, D. and Goodman M. From Object-Process Analysis to Object-Process Design. Annals

of Software Engineering, vol. 2, 1996, pp. 25-40.

[DO95] Dori, D. Object-Process Analysis: Maintaining the Balance between System Structure and

Behavior. Journal of Logic and Computation, vol. 5, no. 2, 1995, pp. 227-249.

[DO01] Dori, D. Object-Process Methodology Applied to Modeling Credit Card Transactions.

Journal of Database Management, vol. 12, no.1, pp. 2-12, 2001 (to appear).

http://iew3.technion.ac.il:8080/Home/Users/dori/JDM-Dori-OPM.pdf.

[DO02] Dori, D. Object-Process Methodology - A Holistic Systems Paradigm. Springer Verlag,

Heidelberg, NY, in press, 2002.

[DW98] D’Souza, D. and Wills, A.C. Objects, Frameworks and Components with UML – The

Catalysis Approach. Addison-Wesley, 1998.

[EAN01] Eckstein, S., Ahlbrecht, P. and Neumann, K. Increasing Reusability in Information

Systems Development by Applying Generic Methods. Proceeding of the 13th international

Conference CAiSE’01, LNCS 2068, June 2001, pp. 251-266.

[FKF98] Flatt, M., Krishnamurthi, S., and Felleisen, M. Classes and Mixins. Proceedings of ACM

Symposium on Principles of Programming Languages, 1998, pp. 171-184

16

[FT99] Frakes, W. and Terry, C. Software Reuse: Metrics and Models. ACM Computing Surveys,

Vol. 28, No. 2, June 1996, pp. 415-435.

[GHY97] Graham, I., Henderson-Sellers, B., and Younessi, H. The OPEN Process Specification,

Addison-Wesley, 1997, pp. 126-131.

[GR00] Grundy, J. Multi-Perspective Specification, Design and Implementation of Software

Components using Aspects. International Journal of Software Engineering and Knowledge

Engineering, vol. 10, no. 6, December 2000.

[KM99] Kersten, M. and Murphy, G. C. Atlas: A Case Study in Building a Web-Based Learning

Environment using Aspect-Oriented Programming. Conference on Object-Oriented

Programming, Systems, Languages and Applications (OOPSLA), 1999.

[KA93] Katz, S. A Superimposition Control Construct for Distributed Systems. ACM Transactions

on Programming Languages and Systems, vol. 15, No. 2, 1993, pp. 337-356.

[LWB98] Lester, N. G., Wilkie, F. G. and Bustard, D. W. Applying UML Extensions to Facilitate

Software Reuse. The Unified Modeling Language (UML'98) - Beyond the Notation. LNCS 1618,

June 1998, pp. 393-405.

[MLS98] Mens, T., Lucas, C. and Steyaert, P. Giving Precise Semantics to Reuse and Evolution in

UML. Proceedings PSMT'98 Workshop on Precise Semantics for Modeling Techniques, 1998.

[MMM95] Mili, H., Mili, F. and Mili, A. Reusing Software: Issues and Research Directions. IEEE

transactions on Software Engineering, Vol. 21, No. 5, June 1995, pp. 528-562.

[PD99] Peleg, M. and Dori, D. Extending the Object-Process Methodology to Handle Real-Time

Systems. Journal of Object-Oriented Programming, vol. 11, no. 8, 1999, pp. 53-58.

[RDK02] Reinhartz-Berger, I., Dori, D. and Katz, S. OPM/Web – Object-Process Methodology for

Developing Web Applications. Annals on Software Engineering – Special Issue on Object-

Oriented Web-based Software Engineering, , 2002 (to appear).

[UML00] Unified Modeling Language Specification – version 1.3,

http://www.rational.com/media/uml/resources/documentation/ad99-06-08-ps.zip.