DOMAIN MODELING WITH OBJECT-PROCESS

METHODOLOGY

Arnon Sturm

Department of Information Systems Engineering, Ben Gurion University of the Negev, Beer Sheva, 84105, Israel

Dov Dori

Faculty of Industrial Engineering and Management, Technion – Israel Institute of Technology, Haifa, 32000, Israel

Onn Shehory

IBM Haifa Research Lab, Haifa University Campus, Haifa, 31905, Israel

Keywords: Domain Engineering, Modeling, Methodology.

Abstract: Domain engineering can simplify the development of software systems in specific domains. During domain

analysis, the first step of domain engineering, the domain is modeled at an abstract level providing

guidelines for application modeling within that domain. Most domain analysis approaches suffer from low

accessibility and limited expressiveness. In this paper we utilize the application-based domain modelling

(ADOM) approach and apply it to the Object-Process Methodology (OPM) modelling language. We do that

by extending Object-Process Methodology (OPM) to support domain analysis. We also performed an

experiment to verify that the proposed extension improves the model quality compared to quality arrived at

without the extension. Our experimental results show that, when presented with a set of requirements,

subjects that used OPM with the domain analysis extension arrived at a system model which is ten percents

better than the system model arrived at by subjects that used OPM alone in terms of model correctness.

1 INTRODUCTION

Domain engineering is concerned with building

reusable software core assets and components in a

specific domain of human interest (Carnegie Mellon,

2002 and Cleaveland, 2002). Software reuse is

viewed as a way of reducing product cycle time,

thereby allowing industry to quickly deliver new

products to the market. Software reuse, of which

domain engineering is an important means, has

therefore become a major goal for many

organizations who seek to shorten time-to-market.

Domain engineering activities include domain

analysis, domain design, and domain

implementation. Domain analysis can be defined as

a process by which information used in developing

software systems in a specific domain is identified,

captured, and organized with the purpose of making

it reusable when creating new systems in that

domain. Domain analysis concerns the identification

of a domain (or a set of related domains) and

capturing the domain ontology and its variations

within the domain. Subsequent stages of domain

engineering, namely domain design and domain

implementation are concerned with mechanisms for

translating the requirements into systems that are

made up of components with the intent of reusing

these components to the highest extent possible. In a

more refined formulation, domain analysis is the

activity of identifying objects and operations of a

class of similar systems in a particular domain

(Valerio et al., 1997). Domain analysis should

"carefully bound the domain being considered,

consider commonalities and differences of the

systems in the domain, organize an understanding of

the relationships between the various elements in the

domain, and represent this understanding in a useful

way" (Carnegie Mellon, 2002). Domain analysis

may be followed by the construction of a generic,

144

Sturm A., Dori D. and Shehory O. (2006).

DOMAIN MODELING WITH OBJECT-PROCESS METHODOLOGY.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 144-151

DOI: 10.5220/0002494601440151

 SciTePress

reusable code and even a domain code generator (de

Champeaux,, 1993).

Several methods have been developed to support

domain analysis as reviewed by Czarnecki and

Eisenecker (2000) and by Sturm and Reinhartz-

Berger (2004), but these methods suffer from the

following weaknesses. (1) They lack formality,

rendering validation of a domain-specific application

against its domain model difficult to perform. (2)

They require the use of several views for both

domain specification and application specification,

resulting in limited accessibility. (3) They use

different notions and notations for the domain

models and for the application models, reducing the

collaboration between the various stakeholders

engaged in the development process. (4) They

address primarily the static characteristics and

constraints of the domain, but their treatment of the

domain's dynamic aspect is limited.

The Application-based Domain Modeling

(ADOM) approach (Sturm and Reinhartz-Berger,

2004 and Reinhartz-Berger and Sturm, 2004)

addresses the above mentioned problems. This

approach treats a domain as a reference application

that needs to be modeled before systems in that

domain are specified and designed. It also advocates

handling the domain as a regular application. That

is, it encourages the use of the same means for

specifying domains and applications. The domain

structure and behavior modeled serve to define and

enforce static and dynamic constraints on models of

application in that domain. The ADOM approach

consists of three-layers: (1) the language layer,

which handles modeling language ontologies and

their constraints, (2) the domain layer, which holds

the building elements of domains and the relations

among them, and (3) the application layer, which

consists of domain-specific system models. The

ADOM approach further defines dependency and

enforcement relations between these layers. While

ADOM builds on UML as the modeling language,

its developers note that it can be applied using other

modeling language as well.

In this paper, we validate the suitability of the

ADOM approach to Object-Process Methodology

(OPM) (Dori, 2002), which is an integrated

approach to the study and development of systems.

As a general-purpose system modeling method,

OPM has been used to model systems in various

domains, including pattern recognition in

mechanical engineering drawings (Dori, 1995),

computer integrated manufacturing documentation

and inspection (Dori, 1996), and web application

(Reinhartz-Berger et al., 2002). These systems were

modeled without first devising a domain-specific

ontology infrastructure. OPM was selected as the

alternative modeling technique due to its supremacy

over UML with respect to comprehension and

construction of system models. This has been shown

experimentally by Peleg and Dori (2000), Reinhartz-

Berger and Dori (2004), and Siau and Cao (2001).

The contribution of this paper is threefold. First,

we extend OPM with facilities to support domain

engineering principles for developing domain-

specific applications. These facilities make OPM

more accessible and efficient for modeling domain-

specific systems and products. Second, we validate

the suitability of the ADOM approach to modeling

languages other than UML. Third, we experiment

and provide an empirical proof of the advantage of

using the ADOM-OPM-based approach over using

the generic version of OPM.

The rest of this paper is organized as follows. In

Section 2 we introduce the ADOM-OPM extension

for domain analysis and demonstrate its use within

the domain of access control system. In Section 3 we

describe an experiment we performed in order to

establish the suitability of ADOM-OPM for

application modeling compared with OPM and

report the results. Section 4 concludes with summary

and future research.

2 ADOM-OPM

To implement the ADOM approach using OPM, we

had to extend it with only two new features: (1) A

role, which is a stereotype-like element emphasizing

additional semantic for an OPM thing. Roles will be

used within an application model. (2) A multiplicity

indicator, which constrains the number of OPM

things of some class that can be modeled in an

application. The multiplicity indicator will be used

within the domain model.

The rest of this section presents the domain and

application layers of ADOM-OPM. This is done for

the example domain of access control (AC) systems,

and specifically for the Drink Vending Machine

(DVM) application within the AC systems domain.

Applications in the AC domain are concerned with

the problem of accessing entities, objects and

resources using well-defined access policies and

procedures (Duffy, 2004). Application areas within

the AC domain include all kinds of product vending

machines, automated teller machines (ATM), all

kinds of systems that access databases using batch

and interactive interfaces, gambling machines, and

local (batch, interactive) and remote access to

DOMAIN MODELING WITH OBJECT-PROCESS METHODOLOGY

145

software and hardware objects in a computer

network.

The DVM application manages several machines

that belong to various companies. Each machine is

identified by its location and the company that owns

it. The system keeps the name and telephone number

of each company. Each machine works with several

coin types. The products sold in each machine are

identified by their name and producer. When a

customer buys a drink from the system, he or she

first needs to check whether the product is available

and, if needed, whether coins for change are

available. When the customer asks to buy a drink,

the system creates a transaction, updates the relevant

information and notifies the machine about the

product and coins it needs to deliver. A machine

operator can perform two operational activities:

drinks filling and coins loading.

2.1 The ADOM-OPM Domain

Layer

As noted, the domain in the ADOM approach should

be modeled as a regular application. OPM is thus the

modeling technique for both the domain model and

the application model, and each will be constructed

as an OPM model with its OPD set.

Figure 1, which depicts the system diagram (SD,

top level) of the AC domain, shows that it consists

of three external entities—Client, Machine, and

Maintenance Entity, two processes—Operate and

Maintain, and four system objects—Owner,

Company, Transaction, and Machine Info. The

symbols "m" and "+" at the right-bottom edge of

some OPM things (objects and processes) indicate

the multiplicity constraints of these things within the

application model. The symbol "m" indicates zero to

many and the symbol "+" indicates 1 to many. For

example, at least one object of type Client should

appear within the application model related to that

domain. In addition to defining OPM things that

serve as building blocks in an application in that

domain, links are defined too. For example, the

Operate process yields a Transaction. This

constraint should hold in any applications within the

AC domain.

Machine Info is unfolded in Figure 2. Machine

Info consists of many Item objects and many

Money Availability objects. Item exhibits Item

Identifier and at least one Item Attribute and refers

to many Transactions and to at least one Owner.

Money Availability exhibits Money Amount and

refers to Money Type, which exhibits Money Value

and at least one Identification Sign. Machine Info

exhibits at least one Machine Identifier and an

optional Balance. Machine Info refers to a

Company and to many Transactions. Company

exhibits Company Identifier. Transaction exhibits

Transaction Date and optionally refers to Owner

which exhibits at least one

Owner Details.

In Figure 3 the Operate process is elaborated

using the in-zooming scaling mechanism of OPM.

The order of the processes depicted in that figure is

the following:

1. An optional (as indicated by the multiplicity

indicator "m") Identification process, which

requires a Company object, an Owner Object,

and a Machine Info object and yields a Can

Operate object;

Figure 1: System Diagram of the AC domain.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

146

2. At least one (as indicated by the "+"

multiplicity indicator) Item Availability

Checking process, which requires an Item

object and yields a Can Operate object;

3. At least one Money Availability Checking

process, which requires a Money Amount

object and yields a Can Operate object;

4. A Transaction Creating process, which is

activated if the Can Operate object is true, in

which case it yields a Transaction object;

5. At least one Money & Machine Updating

process, which requires the Transaction

object and affects Balance, Money Amount,

and Machine; and

6. At least one Item Updating & Machine

Operating process, which requires

Transaction and affects Item Attribute and

Machine.

Figure 2: Machine Info Unfolded.

Figure 3: Operate process in-zoomed.

DOMAIN MODELING WITH OBJECT-PROCESS METHODOLOGY

147

2.2 The ADOM-OPM Application

Layer

In ADOM, the application layer uses the domain

layer as a validation template. In this section we

provide a specification of the Drink Vending

Machine (DVM) application which is classified by

Duffy (2004) as belonging to the domain of access

control systems. The requirements of the DVM

application were presented in the beginning of

Section 2.

Figure 4 presents the system diagram of the

DVM application. In the application layer model,

each thing (i.e., an object or a process) is associated

with a role. For example, the object Customer is

associated with a Client role, which is an object in

the domain layer model. The Drink Buying process

is associated with the Operate role, a process in the

domain layer model.

Note that objects that are classified as Owner and

Company, which were specified in the domain layer

model, do not appear in the application layer model

since they are not required at the lower level OPDs

of this application. This shows the ability of the

ADOM-OPM approach to capture variability within

a domain using the multiplicity constraints.

The system exhibits three top-level processes:

1. Drink Buying, which is triggered by a

Customer, yields a Buy Transaction, and

affects DVM and DVM Info. This process

stands for the constraints that were specified

with the Operate process in the domain layer

model in Figure 1.

2. Drink Updating, which is triggered by the

Operator and affects DVM and DVM Info.

3. Coin Updating, which is triggered by the

Operator and affects DVM and DVM Info.

Both

Drink Updating and Coin Updating conform

to the constraints associated with the Maintain

process in the domain level model.

Figure 5 shows an OPD in which DVM Info is

unfolded. This OPD relates to the domain OPD

depicted in Figure 2 as its validation template. The

roles specified within the domain model are mapped

to the application classes of both objects and

processes. For example, the Producer labeled with

the role Owner exhibits Producer Name and

Producer Address, which are labeled with the role

Owner Details. This relation also demonstrates how

the domain layer model serves as a guideline for

modeling the application.

The Drink Buying process, which is in-zoomed

in Figure 6, follows the constraints specified in the

domain layer, as described in Figure 3. Overall, the

sequence of application processes follows the

pattern specified in the domain layer model, yet an

Identification process is missing, as it was specified

as optional.

Figure 4: System diagram of the Drink Vending Machine.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

148

Figure 5: DVM Info Unfolded.

Figure 6: Drink Buying process in-zoomed.

3 EVALUATING ADOM-OPM

The ADOM-OPM approach has been applied in

several domains, including multi-agent systems,

discrete simulation event, resource allocation and

tracking, process control, and databases. We also

conducted an experiment to compare ADOM-OPM

with OPM. The goal of the experiment was to

determine whether modeling that is based on a

domain model improves the resulting application

model compared with an application model that is

developed without the support of a domain model. In

this section, we present the experiment and its

results.

3.1 Experiment Hypothesis

Our conjecture prior to carrying out the experiment

was that an application model constructed using

ADOM-OPM is more complete and more correct

than the model of the same system resulting from

using OPM alone. The reason for this conjecture was

that the domain model in ADOM-OPM provides a

framework that guides the modeler in creating the

application model within the domain of discourse.

DOMAIN MODELING WITH OBJECT-PROCESS METHODOLOGY

149

3.2 Experiment Settings

The subjects of the experiment were 120 third year

students in a four-year engineering B.Sc. program at

the Technion – Israel Institute of Technology, who

took the course “Specification and Analysis of

Information Systems” at the winter semester of the

2004-5 academic year. The students had no previous

knowledge or experience in system modeling and

specification. During the course, the students studied

various modeling techniques, including Data Flow

Diagram (DFD), UML, Statecharts, and OPM. The

last lecture was devoted to the ADOM approach and

its application in UML and OPM.

Table 1: Students' distribution by exam version and

domain (question).

Exam

Version

Domain

V1 V2 V3

Resource Allocation

and Tracking (RAT)

OPM (32)

ADOM-

OPM (40)

Process Control (PC)

ADOM-

OPM (38)

OPM (28)

Access Control (AC) ADOM-

OPM (41)

OPM (32)

The experiment took place during the final

examination of the course. The examination

consisted of three questions relating to different

domains. In each question the students were

provided with application requirements similar to

the requirements for the DVM application in Section

2. We had three different examination versions, such

that in each question (domain) about half of the

students were also provided with the OPM-based

domain layer model.

The students were divided arbitrarily into three

groups, labeled V1, V2, and V3, and each group

responded to a different examination version. Each

version included one question with a domain model

and one question without a domain model. The

distribution of students into the three groups and the

three domains (questions) is given in Table 1, where

the numbers of students who responded to each

question in each version appear in parenthesis.

3.3 Experiment Results

All the questions were graded by the course staff.

Each one of the graders checked a question in one

domain for all students according to a pre-defined

set of criteria. Each question could score up to 34

points. Table 2 summarizes the average scores

students achieved for each question in OPM and in

ADOM-OPM.

Table 2: Average scores.

Total AC PC RAT Domain

Method

25.6

25.06 27.07 23.06 OPM

27.55 28.19 30.64 25.00 ADOM-OPM

p<0.0

P<0.02 p<0.01 p<0.05 Significance

Table 2 clearly shows that using the ADOM-

OPM the students achieved better results than with

OPM alone, and these results are domain

independent. Performing a mean comparison

statistical analysis we found that the differences

between the two methods were significant. This

confirms our conjecture regarding the benefits of

modeling with ADOM-OPM compared with generic

OPM modeling. Examining the results in detail we

found out that the models done using ADOM-OPM

scored better than models done with OPM alone in

terms of correctness of objects, processes, and links

and in terms of model completeness.

4 SUMMARY

In this paper, we present our extension for the

Object-Process Methodology (OPM) to handle

application domain modeling (ADOM) approach.

The OPM extension includes roles, which are

stereotypes-like elements, and multiplicity

indicators. We demonstrated the use of the resulting

ADOM-OPM approach by applying it to the domain

of access control systems and a corresponding

application—the drink vending machine. Finally, we

examined the ADOM-OPM approach via a

controlled experiment and established that it helps

create better models than those obtained using OPM

alone.

In addition, analyzing the empirical results and

the theoretical aspects, we found that the ADOM-

OPM approach addresses the following problem:

1. The multiple view problem: OPM supports

system specification in a single, unifying view,

or diagram type. Since a domain is modeled just

like an application within a domain, domain

modeling benefits from all the advantages of

OPM, including its single view, the combination

of formality with intuition, and the bimodal

graphic-textual representation.

2. Relationships between the domain and

application models: The ADOM-OPM approach

utilizes the domain model while modeling the

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

150

application in the following ways: (1) labelling

of the application model entities with roles

defined in the domain model; and (2) validating

the relationships among the application model

elements (entities and links) according to the

thing roles and link constraints defined in the

domain model.

3. The models incompatibility problem: both the

domain and the application OPM models use

the same notations and semantics, so no mental

model transformation is needed.

Moving forward from domain analysis, domain

design in OPM is similar to domain analysis, as it

employs the same terminology while deepening the

level of details and shifting the focus from the

problem domain to the solution domain. The

transformation to domain implementation can be

done using the Generic Code Generator (GCG)

(Reinhartz-Berger and Dori, 2004) associated with

OPCAT (Dori et al, 2003). Utilizing the GCG and

roles within a domain can be a basis for developing

infrastructure components and using them to

generate application code.

The implementation of the ADOM-OPM

analysis approach is currently being integrated into

OPCAT. We plan to add negation constraints as well

as extending the application model so that it can be

based on more than one domain model. We also

intend to experimentally compare the ADOM-OPM

approach with ADOM-UML approach.

ACKNOWLEDGMENTS

The authors wish to thank Dr. Iris Reinhartz-Berger

for her insightful remarks and comments and for her

help in designing the experiment.

REFERENCES

Carnegie Mellon - Software Engineering Institute, 2002.

Domain Engineering: A Model-Based Approach,

http://www.sei.cmu.edu/domain-engineering/.

de Champeaux, D., Lea D., and Faure P., 1993. Object-

Oriented System Development, Addison Wesley.

Cleaveland, C., 2002. Domain Engineering,

http://craigc.com/cs/de.html.

Czarnecki, K. and Eisenecker, U. W., 2000. Generative

Programming - Methods, Tools, and Applications,

Addison-Wesley.

Dori, D., 2002. Object-Process Methodology - A Holistic

Systems Paradigm, Springer Verlag.

Dori, D., 1995. Representing Pattern Recognition-

Embedded Systems through Object-Process

Diagrams: the Case of Machine Drawing

Understanding System, Pattern Recognition Letters,

16(4), pp. 374-384.

Dori, D., 1996. Object-Process Analysis of Computer

Integrated Manufacturing Documentation and

Inspection, International Journal of Computer

Integrated Manufacturing, 9(5), pp. 339-353.

Dori, D., Reinhartz-Beger, I., and Sturm, A., 2003.

OPCAT – A Bimodal CASE Tool for Object-Process

Based System Development, The fifth International

Conference On Enterprise Information

Systems (ICEIS).

Duffy, D. J., 2004. Domain Architectures: Models and

Architectures for UML Applications, John Wiley &

Sons.

OMG-MOF, 2002. Meta-Object Facility (MOF™),

version 1.4.

OMG-UML, 2003. The Unified Modeling Language

(UML™), version 1.5.

Peleg, M. and Dori, D., 2000. The Model Multiplicity

Problem: Experimenting with Real-Time Specification

Methods, IEEE Transaction on Software Engineering,

26 (8), pp. 742-759.

Reinhartz-Berger, I., Katz, S., and Dori, D., 2002.

OPM/Web - Object-Process Methodology for

Developing Web Applications, Annals on Software

Engineering - Special Issue on OO Web-based

Software Engineering, pp. 141-161.

Reinhartz-Berger, I. and Dori, D., 2005. OPM vs. UML –

Experimenting Comprehension and Construction of

Web Application Models, Empirical Software

Engineering Journal, 10 (1), pp. 57-80.

Reinhartz-Berger, I. and Dori, D., 2004. Object-Process

Methodology (OPM) vs. UML: A Code Generation

Perspective, EMMSAD, 2004.

Reinhartz-Berger, I. and Sturm, A., 2004. Behavioral

Domain Analysis – The Application-based Domain

Modeling Approach, the 7th International Conference

on the Unified Modeling Language (UML'2004),

LNCS 3273, pp. 410-424.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and

Lorensen, W., 1991. Object-Oriented Modeling and

Design, Prentice-Hall International Inc.

Siau, K. and Cao, Q., 2001. Unified Modeling Language:

A Complexity Analysis, Journal of Database

Management, 12 (1), pp. 26-34.

Sturm, A.

and Reinhartz-Berger, I., 2004. Applying the

Application-based Domain Modeling Approach to

UML Structural Views, the 23

International

Conference on Conceptual Modeling (ER'2004),

LNCS 3288, pp. 766-779.

Valerio, A., Succi, G, and Fenaroli, M., 1997. Domain

analysis and framework-based software development,

ACM SIGAPP Applied Computing Review, 5 (2).

DOMAIN MODELING WITH OBJECT-PROCESS METHODOLOGY

151