MibML: A Conceptual Modeling Grammar for Integrative...

50
1 MibML: A Conceptual Modeling Grammar for Integrative Business Information Systems Using the Agent Metaphor α RAJIV KISHORE βφ Department of Management Science and Systems School of Management The State University of New York at Buffalo Buffalo, NY 14260-4000 Tel: (716) 645-3507 Fax: (716) 645-6117 [email protected] RAJ SHARMAN Department of Management Science and Systems School of Management The State University of New York at Buffalo Buffalo, NY 14260-4000 Tel: (716) 645-3507 Fax: (716) 645-6117 [email protected] HONG ZHANG Computer Information Systems Glass Hall 373 Southwest Missouri State University 901 South National Avenue Springfield, Missouri 65804 Tel: (417)836-4121 Fax: (417)836-6907 Email: [email protected] R. RAMESH Department of Management Science and Systems School of Management The State University of New York at Buffalo Buffalo, NY 14260-4000 Tel: (716) 645-3258 Fax: (716) 645-6117 [email protected] UB School of Management Working Paper #801 March 2004 © Kishore, Sharman, Zhang, and Ramesh, 2004 α The authors are grateful to Vijayan Sugumaran, participants at the SOM-Informatics Working Group seminar at SUNY Buffalo, and anonymous reviewers and attendees at the AMCIS 2003 and HICSS 2004 conferences for providing invaluable suggestions during the course of development of this paper. We are also grateful to Sukhamay Kundu for his critical evaluation of the MibML formal grammar included in the paper. β Corresponding author. φ The first three authors have contributed equally to this paper and their names are listed in the alphabetical order.

Transcript of MibML: A Conceptual Modeling Grammar for Integrative...

Page 1: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

1

MibML: A Conceptual Modeling Grammar for Integrative Business Information Systems Using the Agent Metaphorα

RAJIV KISHOREβφ

Department of Management Science and Systems School of Management

The State University of New York at Buffalo Buffalo, NY 14260-4000

Tel: (716) 645-3507 Fax: (716) 645-6117 [email protected]

RAJ SHARMAN

Department of Management Science and Systems School of Management

The State University of New York at Buffalo Buffalo, NY 14260-4000

Tel: (716) 645-3507 Fax: (716) 645-6117 [email protected]

HONG ZHANG

Computer Information Systems Glass Hall 373

Southwest Missouri State University 901 South National Avenue Springfield, Missouri 65804

Tel: (417)836-4121 Fax: (417)836-6907

Email: [email protected]

R. RAMESH

Department of Management Science and Systems School of Management

The State University of New York at Buffalo Buffalo, NY 14260-4000

Tel: (716) 645-3258 Fax: (716) 645-6117

[email protected]

UB School of Management Working Paper #801 March 2004

© Kishore, Sharman, Zhang, and Ramesh, 2004

α The authors are grateful to Vijayan Sugumaran, participants at the SOM-Informatics Working Group

seminar at SUNY Buffalo, and anonymous reviewers and attendees at the AMCIS 2003 and HICSS 2004 conferences for providing invaluable suggestions during the course of development of this paper. We are also grateful to Sukhamay Kundu for his critical evaluation of the MibML formal grammar included in the paper.

β Corresponding author. φ The first three authors have contributed equally to this paper and their names are listed in the

alphabetical order.

Page 2: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

2

MibML: A Conceptual Modeling Grammar for Integrative Business Information Systems Using the Agent Metaphor

Abstract

In this paper we introduce the concept of multiagent-based integrative business information systems (MIBIS). MIBIS is derived from an integration of two analogous modeling metaphors: Agents and IS Work Systems. Our conceptualization is based on three basic attributes of the two metaphors – autonomous behavior, goal orientation and role-centricity. We develop a theoretically-grounded conceptual modeling grammar termed MibML (Multiagent-based Integrative Business Modeling Language) for modeling the MIBIS universe. The need for the special-purpose grammar for MIBIS is motivated by the inadequacy of existing software engineering and multiagent modeling formalisms such as ER, DFD, PetriNets, AUML, etc. to capture the specific characteristics and semantic requirements of the MIBIS universe. The MibML grammar is presented as a formal model using BNF and first order logic. An illustrative example of the application of MibML grammar is presented as a proof-of-concept and is included as supplemental material to this paper. ACM Taxonomy Keywords: D.2.1.a Analysis; D.2.1.g Specification; D.2.10.b Design notations and documentation; D.2.10.c Representation. Paper Keywords: conceptual modeling grammar, systems modeling, requirements specifications, role-based modeling, multiagent systems modeling, integrative business information systems modeling.

1 INTRODUCTION

The fundamental unit of conceptualization in Multiagent Systems (MAS) is the Agent.

An agent is basically a computational entity with specific goals that operates in coordination

with other such entities in a given environment. Similarly, a fundamental unit of

conceptualization in an Integrative Business Information System (IBIS) is the IS Work

System [2]. An IS work system is essentially an encapsulated Information System (IS)

component with a fully defined interface that performs specific tasks in coordination with

other such systems in an IBIS. Although the two concepts originate from different domains,

their functionality and architectures have much in common. Consequently, using the Agent

metaphor in IBIS design or the IS Work System metaphor in MAS design can be considered

analogous. This equivalence has some significant implications. First, a common conceptual

grammar could support the development of both types of systems. Second, the common

conceptual basis would lead to an integration of the two, leading to the notion of Multiagent-

based IBIS (MIBIS). In this research, we introduce the MIBIS concept and develop a

Page 3: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

3

theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

Integrative Business Modeling Language) for modeling the MIBIS universe. MibML is a

demonstration of the equal applicability of the two metaphors in both the design contexts.

The Agent metaphor has been extensively used in various IBIS contexts [2],

including e-commerce, business process management, supply chain management,

enterprise integration, manufacturing, etc. While considerable research exists in the areas

of distributed and cooperative multiagent architectures that implicitly employ the work

system concept in the form of agents [10, 26, 30, 40], to our knowledge there is no effort

towards defining a unified and coherent conceptual semantic and structural modeling

grammar [54] for the MIBIS context. Currently, the situation remains one of craftsmanship

where system developers create multiagent architectures or IBIS solutions either from

scratch or by reusing existing components as required in a given context. The lack of a

unified conceptual modeling approach for MIBIS design has resulted in a proliferation of

several such independently developed architectures; this has led to the well-recognized

problems of interoperability, integration and scalability challenges in system design, to

name a few.

This paper essentially addresses these lacunae in both the literature and practice.

The distinguishing feature of the proposed developmental framework is its unique focus on

conceptual modeling of MIBIS universes. The area of conceptual modeling has grown

enormously over the years from simple representations of concepts and their relationships

to modeling complex and dynamic behaviors of entities and systems. Further, conceptual

models have been used very effectively in the design processes in several software

engineering domains; they have also served as effective means of communication and co-

ordination among development teams, besides providing common bases for the

development of encapsulated component systems. A MIBIS universe typically possesses the

attributes of a complex dynamic environment; the universe can be viewed as a collection of

interactive autonomous agents or analogously as a network of autonomous work systems.

Page 4: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

4

These components together perform a set of tasks to accomplish their system goals. A

MIBIS at a minimum can be configured with component goals, their role and task

definitions, coordination and communication mechanisms, system states and data

management, and resource sharing protocols. Consequently, conceptual modeling is

extremely important in MIBIS design.

The proposed modeling language MibML consists of a set of simple fundamental

concepts required in modeling a MIBIS universe, their structural and semantic associations,

and a coherent framework for a systematic development, verification and validation of

MIBIS designs. The grammar includes axiomatic specifications of the concepts, their

relationships and rules of application in the design framework, and is formally described

using BNF and predicate logic. An illustrative example provided in the supplemental set

demonstrates the use of MibML in MIBIS design, including the underlying design principles.

MibML has been developed from an integration of the Agent and Work System metaphors

along with their properties derived from extant multiagent systems and IBIS literatures.

Similar approaches in other domains include the Smart Object Model for complex operations

management [48], the SEAM model for workflow systems [4], the knowledge-based

approach for reusable business information systems [46, 53], and the GBMS/SM model for

structured optimization [11]. The MibML grammar provides a representation vocabulary,

which other existing modeling approaches for the MIBIS universe do not provide.

The paper is organized as follows. In section 2, we develop the basic framework of

the MIBIS universe. In section 3, we justify the need for a formal conceptual-modeling

grammar for the MIBIS universe by showing that existing software engineering and

multiagent modeling formalisms such as ER, DFD, PetriNets, AUML, etc. are inadequate to

capture the specific characteristics and semantic requirements of the MIBIS universe. In

section 4, we discuss and formally define the MibML grammar. Finally, we conclude with

some future research directions in section 5. An illustrative proof-of-concept example of the

application of MibML grammar is included as supplemental material to this paper.

Page 5: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

5

2 THE MIBIS FRAMEWORK

The proposed MIBIS framework is derived by adapting the Agent metaphor in

Multiagent Systems (MAS) to an IBIS context. Equivalently, employing the IS work system

metaphor of IBIS in a MAS context would provide another view of MIBIS. Without loss of

generality, we focus on the former view throughout the paper. In the following discussion,

we first introduce the notion of IBIS and then develop a conceptual framework for MIBIS by

adapting the Agent metaphor.

2.1 IBIS: A COMPONENT VIEW

Alter [2] defines a work system as the highest-level conceptual system abstraction

within an organization. An information system is only a particular type of work system that

supports other organizational work systems. Using this definition, we conceptualize a work

system in the current context as “a system comprised of man-machine components

performing a specific business process; the process could entail data, man-machine tasks,

coordination, communication and resource sharing among the man-machine components.”

As a result, we can view a work system as an encapsulated business component with

complete definitions of its internal logic, resources and external interfaces. A business

organization typically contains a number of work systems (such as materials procurement,

sourcing processes etc.) that interface, interact, coordinate and share resources among

each other in order to achieve specific organizational objectives. Business integration

essentially involves the integration of multiple work systems within a business organization.

An Information System (IS), as a particular type of work system, supports other

business process work systems within organizations [2]. We refer to an information system

as an Integrative Business Information System (IBIS) when it comprises of a set of IS work

systems that together support a set of business process work systems. We conceptualize an

IBIS as an integration of several autonomous, goal-oriented and role-centric component

work systems within its own framework. Some of the well known IS solutions that can be

Page 6: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

6

generally characterized as traditional IBIS would include ERP systems [29], Enterprise

Application Integration (EAI) frameworks [31], and work flow systems [16], to name a few.

In general, an IBIS environment deals with the integration of cross-functional processes,

integration of IS components (legacy or new) within an organization-wide federated

schema, tight/loose coupling of IS components across organizations, and more

fundamentally, automation of processes wherever possible.

The emerging next-generation IBIS architectures have several distinguishing

attributes compared to their traditional counterparts. In general, the business process

contexts of the emerging IBIS tend to be more functionally specialized within a wide array

of inter-dependent processes. As a result, several IS work systems may need to be

integrated to accomplish the support requirements of a single business process. Coupled

with the interfacing requirements across business processes, an IBIS could entail a network

of IS work systems interacting through their interfaces to support a set of related business

processes. Each IS work system can be viewed as a fully self-contained component with

appropriate interfaces. This encapsulation also implies autonomous behavior and a

capability scope for each component. Hence, system integration is a far greater challenging

task when faced with an array of components where each component could be defined with

a set of goals, role-centric task capabilities and internal/external resources with other

components and a capability of autonomous behavior. Consequently, a primary focus of the

next-generation IBIS will be on coordination of autonomous work systems and their

communication protocols [32]. The emerging IBIS paradigm leads logically to a

conceptualization of IBIS work systems as autonomous agents with coordination

mechanisms among them. Using this idea, we develop the concept of MIBIS in the following

discussion.

2.2 MIBIS: INTEGRATING THE AGENT METAPHOR

IBIS can be conceptualized and possibly even implemented using multiagent system

Page 7: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

7

architectures. A multiagent system (MAS) is defined as a loosely coupled network of

problem solving agents; the agents interact with one another to solve problems that are

beyond the individual capabilities of each problem solver [15, 57, p. 3]. Recently

researchers have brought out the similarities between integrative business systems and

“communities” of autonomous problem solving agents [e.g., 23, 24, 39, 45]. The network of

work system components in an IBIS can therefore be modeled as a community of

autonomous agents with both agent-specific and shared objectives. The agent paradigm

provides suitable abstractions that minimize the semantic gap between the conceptual

specification and the corresponding system realization of IBIS work system components

[22]. Furthermore, multiagent systems, for the most part, are concerned with coordinating

intelligent behavior among autonomous agents [8, 15, 21, 37], which is also a central

concern in IBIS.

The Agent metaphor in MAS is analogous to an IS Work System in an IBIS or a

Human Actor in a business process context within IBIS. Clearly, they all have goals, assume

relative roles, perform tasks, possess and employ resources, communicate and coordinate

with each other – in their respective contexts. The MIBIS framework shown in Figure 1

reflects this conceptualization. A number of agents (shown as small yellow circles)

representing human actors or IS work systems are contained within the MIBIS (shown as a

green oval). The MIBIS operates within an external environment (shown as the external red

rectangle), which is similar to the notion of organizational environment and corresponds to

that of multiple agents in the MAS context. The MIBIS is designed with a set of overall

system goals (shown within the blue arrow); the goals are derived from an analysis of user

requirements and incorporated within the conceptual and physical schema of the MIBIS

architecture. The system goals could be specified at different levels of granularity and

ordered into hierarchies. However for the sake of simplicity and without loss of generality,

we assume a simple partitioning scheme where the system goal set is partitioned into a

collection of mutually exclusive and collectively exhaustive subgoals. Each subgoal is

Page 8: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

8

associated with an agent, which could be a work system or a human actor as the case may

be. Since each work system is modeled as a fully encapsulated component, autonomous

behavior of work systems is logically implied in this design. Autonomous behavior also

implies a peer-to-peer role relationship, which is assumed throughout the paper for

simplicity in exposition. Extension of the proposed grammar to non-autonomous behaviors

is beyond our current scope and is a significant are for future research. The capabilities of

individual agents can be organized into declarative and procedural knowledge with direct

implications to the associated subgoals. Finally, agents interact with each other and with

other entities within the environment, and the information resources for the agents are

assumed to be distributed within the environment.

The MIBIS framework presents two fundamentally dual views: a view of an IBIS as a

MAS, and a view of a MAS as an IBIS. We term the two views as “Agent view of IBIS” and

“Work system view of MAS”, respectively. The equivalence between the agent and work

system metaphors yields a common framework for designing either a MAS or an IBIS.

Consequently, the conceptual grammar developed for the MIBIS framework is equally

applicable in the two views. In summary, based on the above conceptualization, we adopt

the following conventions in specifying a MIBIS using the Agent metaphor: 1) the MIBIS

system as a whole has an agreed and shared business goal; 2) the MIBIS system is

composed of a collection of agents, each with their individual goals; 3) there is no global

control over the agents within a MIBIS entity; 4) interactions serve as coordination

mechanisms among agents and between agents within a MIBIS system and the

environment; and 5) agents within a MIBIS system react to stimuli and changes from other

agents and the environmental and adapt their behaviors as needed.

Page 9: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

9

3 NEED FOR A CONCEPTUAL-MODELING GRAMMAR FOR THE MIBIS UNIVERSE

A conceptual-modeling grammar provides a set of constructs and semantic rules for

modeling real-world domains [54]. Conceptual-modeling grammars are classified into

general-purpose and special-purpose grammars [25]. A general-purpose grammar is

applicable generally in any domain but lacks domain-specific semantics, whereas a special-

purpose grammar provides a representation vocabulary and appropriate domain semantics

for the specific domain [42, p. 322]. For example, UML and ER modeling grammars are in

the general-purpose category; the Smart Object Model [48] and the SEAM Model [4] are

cases of special-purpose modeling grammars.

Currently, there is a lack of a special-purpose modeling grammar for the MIBIS

universe. Traditionally, general-purpose modeling grammars such as data-oriented

techniques (e.g. ER-Diagrams), process models (e.g. Petri-nets), and more recently UML,

MIBIS Environment

MIBIS(Multiagent-based Integrative Business Information System)

Entity

Software Agent

Interaction betweenagents

Information Flow to/from an agent with anenvironmental entity / information resource

Information resource

Non-MIBIS EntityMIBIS EntityUser

SystemGoals

Legend:

Figure 1: The MIBIS Universe and its Architecture

Page 10: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

10

have been used to represent business information systems. While these general-purpose

grammars provide a rich vocabulary and strong syntax for aiding the analysis and design of

systems, they lack domain-specific semantics, creating the need for special-purpose

modeling grammars for various domains. For instance, it has been shown that most

enterprise and workflow models lack the essential semantics to concisely represent specific

business processes, goals, tasks and organization structures of particular business

domains[43, 55]. This is quite true for the MIBIS universe as well, because domain-specific

semantics derived from the Agent metaphor such as autonomy, reactivity, distributed

control, interactions, etc., are not supported adequately by general-purpose modeling

grammars. For example, behavioral modeling is crucial to the Agent metaphor and the ER

grammar provides very limited support for this; while data flow diagrams (DFD) provide

partial semantics for modeling the problem-solving processes of agents, they overlook the

modeling requirements of agent intelligence. Similarly, Petri nets are primarily oriented

towards analysis of timing and conflict resolution, rather than towards agent interactions

and coordination. Object-oriented methodologies may be useful in defining MIBIS

specifications by identifying objects that correspond to actors and the dependencies

between these objects. However, as has been discussed in the literature [e.g., 18, 38, 57],

object orientation provides no explicit support for agent concepts such as autonomy,

reactivity, and sociability, and therefore, it is difficult to model agent knowledge and

interactions within MIBIS using OO modeling formalisms. Without a well-defined special-

purpose conceptual-modeling grammar, common terms used in the MIBIS universe such as

role, resource, knowledge, interactions, etc. will have to be force-fitted with constructs

available in general-purpose modeling grammars, and this will result in arbitrariness and

confusion while modeling MIBIS systems.

Based on the characteristics of the MIBIS universe discussed earlier, a conceptual

grammar for MIBIS modeling should provide adequate and distinct representation of

informational, functional, knowledge, and organizational characteristics of the Agent

Page 11: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

11

metaphor and its implementation as a work system within an IBIS environment. The

informational requirement focuses on the information entities involved in the system, their

structures and interrelationships. The functional requirement focuses on the tasks that are

to be performed and the information entities involved. The knowledge requirement deals

with representing knowledge as a unique component associated with agents constituting a

MIBIS. This representation should have a problem solving focus and be defined in

conjunction with the other requirements. The organizational requirement focuses on

structuring all the MIBIS components and linking their goals with functions, coordination

mechanisms and communication protocols. The existing general-purpose and multiagent

systems modeling grammars and the IBIS modeling approaches do not possess adequate

expressive semantics to adequately represent all these requirements. This is summarized in

the analysis provided in Table 1. In this table, H indicates that the feature being discussed is

fully supported, M indicates that the feature is partially supported, and L indicates that the

feature is not supported by the modeling grammar being discussed. In the next section we

turn our attention to the MibML grammar with a specific focus on the MIBIS modeling

requirements discussed above.

Page 12: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

12

Table 1. A Summary of Various Modeling Grammars and their Support for the MIBIS Universe

IS Grammar Supported Feature

General-purpose IS grammar MAS methodology IBIS modeling grammar

ERD DFD Petri-Net [41]

UML [9]

Gaia [59]

MaSE [13]

AUML [6]

TOVE [17]

SEAM [4]

SF1 [46]

DND [47]

AWS2 [35]

XRL [49]

Agent modeling L L L L H H H H L L L L L

Organizational modeling

Goal-oriented L L L L L H L H L H L L L

Role modeling M L L M H H M H L L H M L

Data modeling

Data entity H L L H L L L L H H L L L

Date flow L H H H H H H L L H H H H

Knowledge modeling

Declarative L L L L L L L H H L L L L

Procedural L L L L H H H H M L L L H

Coordination mechanism3

Communication L H H H H H H H L H H H H

Conversation L L L L H H H H L L L H L

Task modeling L M H H H H H H M L L L H

Legend: H – High; M – Medium; L – Low.

1 Knowledge reuse framework of Sugumaran et al. 2 Action Workflow System 3 Coordination occurs at the communication and conversation levels. Communication supports message-content passing. Conversation

supports speech acts to specify actor’s intentions.

Page 13: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

13

4 THE MIBML GRAMMAR

The MibML grammar extracts core concepts from both IBIS and MAS literatures and

presents a framework for the conceptual specification of MIBIS architecture. Using the

Agent metaphor, MibML defines seven key concepts that are central to MIBIS: Goal, Role,

Interaction, Task, Information, Knowledge, and Agent. Each agent (or equivalently an IS

work system) in MIBIS can be specified using this grammar, and a collection of

specifications for a set of agents in an environment with their interrelationships would

together describe a MIBIS architecture. The grammar is descriptive as well as prescriptive;

it is descriptive in defining an architecture using orthogonal conceptual elements of MIBIS;

it is prescriptive in providing a set of modeling tools and an approach to the analysis and

design of a MIBIS. The MibML specifications describe a system at two levels: MIBIS

environment and MIBIS internals. We first develop a framework for MibML and subsequently

present a formal specification of the grammar in the following discussion.

4.1 THE MIBML FRAMEWORK

At the environmental level, a MIBIS is regarded as an integrated system, interacting

with other entities in the surrounding business environment as shown in Figure 1. A

description of the MIBIS environment provides a set of requirements for configuring its

internals in terms of agents. This description follows well-known systems analysis principles

and would broadly include specifications of the environment in terms of (a) functional

requirements, (b) data requirements, (c) interface requirements, and (d) coordination

requirements on a MIBIS with respect to the environment in which it operates. Traditional

conceptual modeling techniques such as ER, UML Use Case etc. could be used for this

purpose. These requirements will be translated into component agent level specifications in

describing the internals of a MIBIS. Since MIBIS is conceptualized as a set of autonomous,

goal-oriented and role-centric agents, the environmental specifications would naturally

translate into component agent architectures comprising of these attributes along with their

Page 14: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

14

internal and external coordination mechanisms and communication protocols. In a

description of the environment, we differentiate between user and other objects that exist

outside the perimeter of a MIBIS. A reason for this is that the user objects not only transact

input/output with a MIBIS, but also specify business goals for the system. We choose goal

as a construct to capture requirements of user objects because goal-based system

development is more stable than those based on functions, processes or information

structures that often change with time [13, 60].

The internal level specifications describe the components of a MIBIS. A MIBIS in this

paper is regarded as an organization of software agents, which play different roles in the

system. Similar to a human organization, role is a key concept in MIBIS analysis. The role

construct in the grammar is essentially an abstraction for: (a) the tasks that are performed

by a component agent, (b) the interactions that need to occur with other roles to achieve

individual agent goals, (c) the information that needs to be accessed or will be generated

during the course of performance of those tasks/interactions, and (d) the knowledge that is

needed for the achievement of the agent’s goals. Just as in an organizational context where

an abstract role is assigned to one or more physical human agents (e.g., the abstract role of

Role

[1, 1]

[2, 2]

[1, 1]

[1, m]

[1, m]

[1, 1]

Performs / Is_performed_by

Is_required_for / Requires

Information

Is_involved_in /Includes

Has_privileges_to_access /Is_accessed_by

Plays /Is_played_by

Possesses / Is_possessed_by

Includes_procedural_knowledge_about /Is_constrained_by[1, 1]

[1, m]

[1, m]

Is_constrained_by /Includes_procedural_knowledge_about

[1, m]

[1, m]Agent

Goal[1, 1]

Interaction[1, m] [1, m]

Task

[1, m] [1, m]

[1, m]

[1, m]

[1, m]

Knowledge

Is_assigned_to /Is_assigned

Figure 2: The MibML Constructs and their Inter-relationships

Page 15: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

15

an “inventory manager” may be assigned to a physical human agent named “John Q.

Batman”), an abstract role in the MIBIS universe is assigned to and implemented by

physical component agents. Therefore, a role in MibML provides a template that can be

instantiated by agents. Figure 2 presents a conceptual meta-model of the MibML constructs

and shows the relationships among the Goal, Role, Interaction, Task, Information,

Knowledge, and Agent constructs that are formally discussed and developed in the following

section.

4.2 FORMAL SPECIFICATION OF MIBML

In this section, we define the MibML constructs as a set of schemas using BNF syntax

[34]. The relationships, axioms, and constraints which govern the usage of the MibML

constructs are defined in first order predicate logic. Table 2 presents the conventions

adopted for the notations and symbols used in specifying the MibML grammar. These

conventions apply to all the symbols used to explicate the various ontological categories

that arise during the specification, namely: instance, collections, types, and collection of

types. Table 3 provides an explanation of the symbols used in specifying the MibML

grammar. Table 4 unambiguously defines the key MibML constructs in BNF and Table 5

provides a list of predicates that are used in specifying the MibML grammar. In the rest of

this section, we provide a more detailed explanation of the fundamental MibML constructs

along with their constraints and relationships based on theories in both the IBIS and MAS

literatures. During our discussion, we have attempted to avoid trivial axioms and constraints

that can be easily reasoned.

Table 2: Convention of Notations used in MibML Specifications

Individual Collection Type Bolded Lower Case letter(s) Bolded Upper Case letter/(s) Instances Lower Case letter(s) Upper Case letter/(s)

Page 16: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

16

Table 3: Symbols used in MibML Specifications

Notation Description Notation Description General

Ψ Collection of MibML constructs

nii ,...,1: ==Ψ ψ

ψ MibML Construct

∆ Collection of relationships

δ Relationships

Τ Collection of constraints τ constraints

attributesC Common Attributes

ta Activity (a task or an interaction)

Goal g Goal

G Collection of goals;

,..,1: nigG i ==

status Goal Status c Completed

xe Executing

w Waiting s Suspended Role

generalr Generic roles

r Normal roles

rcoordinator Special role to maintain

goal status

d Duties of a role p Privilege

Interaction i Interactions msg Communication from initiator role

to responder role resp Response to a message

speech Communicative act

Actspeech Action verb for

communication Example: Assertion, Query, etc. content Actual message Task t Tasks

φ Property / Logic / Subcomponent.

Knowledge

k Knowledge

dk Declarative knowledge

pk Procedural knowledge

pw Workflow patterns

f Facts

drule Deduction rule

structurex Execution structure

orderx Execution order

intconstrax Execution constraint

ev Event

externalev External event

temporalev Temporal event

stateev State event

Information

/i Information

fi / Information flow

ei / Information entity

e Information entity instance e Information entity type

infoe Internal entity information

ocontrolflowi inf/

−− Metadata for information flow

c control

sourceflowi −/

Source from which an

information flow emanates

sinkflowi −/

Entity receiving the

information flows

datai / Actual data with flow

externalflowi −'

External source/sink for

information flow

frequencyflowi −/

Information flow frequency

Agent

ga Agent

Page 17: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

17

Table 4: The MibML Conceptual Modeling Grammar in BNF

MibML Grammar ( ) Τ∆Ψ=Ω ,,

where

nii ..1=∀=Ψ ψ in which iψ is a MibML construct,

nii ..1=∀=∆ δ in which iδ is a relationship between concepts, and

nii ..1=∀=Τ τ in which iτ is a constraint.

]||||||[:: / AKITIRG=ψ

ndescriptionameidCattributes ,,::=

Goal:

>><=<>< statusCg attributes::

...]||||[:: swecstatus x=><

>< →>< rg mappingBijective

Role:

[ ]><><=>< rcoordinatoGeneral rrr |::

>><><=<>< dkCr attributes::

>><<>=<>< adad |::

]|[:: ><><=>< ita

>><=<>< specialattributesrcoordinato dCr ::

:: statusgoalUpdated special =><

Interaction:

>><=<>< SpeechCi attributes::

][|:: ><><>=<>< RespSpeechMsgSpeech

/* Comments : The symbol >< Message is used to express both >< Msg and >< spRe as they have the

same format. >=<><>< MessagespMsg ::Re|[ */

>><><><=<>< contentspeechresponderinitiatorMessage Act::

><→><>< − rresponderinitiator ais]|[

...]||||Re||[:: DenialCommitmentPerformquestQueryAssertionspeechAct =><

ninteractio during edcommunicat messagecontent ::=><

Task:

][|:: ><><>=<>< aAaA

]|[ ><><>→< ita

>><><><=<>< methodoutputinputCt attributes::

/* Comments: The symbol >< oi / is used to express both >< input and >< output as they have the same

Page 18: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

18

format >=<><>< oioutputinput /::]|[ */

]|[/|]|[::/ // ><><><><><=>< fdfd ikoiikoi

>Φ=<>< ::Method

>><Φ<>=<>Φ< φφ |::

...|||...||:: 2121 propertypropertyMethodMethod=><φ

Information:

]|[ //_/ ><>< →>< eeais iii

>><><=<>< eeCi oAttributese inf/ ::

:: entity the about ninformatio structraland syntacticSemantic,einfo =><

instanceentity an withassociated datae ::=><

>><><><=<>< dataodataflowol_infoflow_contrAttributesf iiiCi /inf__

/// ::

>><><><=<>< −−−− timeresponseflowfrequencyflowsinkflowsourceflowol_infoflow_contr iiiii _///// ::

]||[|]||[:: ////// ><><><><><><><=>< −−−− externalflowesourceflowexternalflowesourceflow iiriiiri

]||[|]||[:: ////// ><><><><><><><=>< −−−− externalflowesinkflowexternalflowesinkflow iiriiiri

entity] MIBIS-Non|entity MIBIS| UserEnd[::/ =>< −externalflowi

|[|...]| |[:: // ormationformat_InftureData_Struciormationformat_InftureData_Struci infoflow_data_infoflow_data_ ><=><

atainstance_di data =>< ::/

||_||::/ eibute_valutance_attrEntity_insattributeEntitytanceEntity_insEntityi chunk =><|intPr||||[Re|...]|intPr||||[Re:: GrantViewWriteadPGrantViewWriteadP ><=><

Knowledge:

]|[|]|[:: ><><><><><=>< pdpd kkkkkk

]|[|]|[:: ><><><><><>=<>< dddAttributesd RULEFkRULEFCk

>><<>=<>< fFfF |::

...]|3|2|1[:: AssertionAssertionAssertionf =><

>><<>=<>< dddd ruleRULEruleRULE |::

...]|2__|1__[:: RuleDedcutionruleDedectionruled =><

>><<>><=<>< pppAttributesp wkwCk |::

]|[:: ><><=>< sconstraintstructurep xxw

...]|_|_|[:: choiceexclusivesplitparallelsequencexstrucuture =><

...]||||[:: resourcestatetemporalexternalconstraint evevevevx =><

Agent:

>< →>< ar mappingBijective

Page 19: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

19

Table 5: List of Predicates Used to Specify the MibML Grammar.

PREDICATE MEANING

),( /chunkiraccesses Role r accesses the information chunki /

),( rgaccomplish Goal g is accomplished by role r

)( gaagent ga is an agent

),,( /chunkirpassign Privilege p is assigned to role r for chunki /

),( grassigned Role r is assigned to goal g

),,(_ statusgrstatgoalchange rcoordinato− Role rcoordinator changes the state of goal g to

status

( )21, tt aaconcurrent Activity at1 is in parallel with activity at2

execute(r, at) Role r performs activity at

),( nafrequency t Activity ta must be performed with frequency n

)(ggoal g is a goal

),(_ gagoalhas g Agent ga has a goal g

),(_ riinitiatorhas Role r is the initiator of an interaction

),,(_ /chunkiprpermissionhas Role r has permission p to access chunki /

),(_ Φitpropertieshas Task it has a collection of Properties / Methods Φ

),(_ riresponderhas Role r is the responder of the interaction

),(_ statusgstatehas Goal g has state status

)( /ininformatio /i is either an information entity or flow

),,( Φji ttinherits Task it inherits from task jt collection of Properties

/Methods Φ

)(ininteractio i is an interaction

),(_ ji tttypeofisa Task it is of type jt

)(kknowledge k is a knowledge nugget

)(_ ffactnew f is a new fact

),(_ Fruleonoperate d Deduction rule has to operate on facts

)( taoptional Activity ta is optional

),,( 21 φφitoverrides Task it overrides property 1φ with property 2φ

),( ji ttpartOf Task it is a sub-task of part of task jt

),( raplays g Agent ga plays role r

( )21 , tt aaprecedes Activity at1 is executed before activity at2

),,( /chunkirprevoke Privilege p is assigned to role r for chunki /

)(rrole r is a role

),( ji rresubordinat Role ir is subordinate to role jr

)(ttask t is a task

trigger(ev, at) Activity at is triggered by event ev

Page 20: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

20

4.2.1 Goal

In systems development, goal has been identified as an essential concept for

capturing user requirements. It is capable of aiding in the elicitation and elaboration of

requirements, relating system requirements to organizational and business contexts,

clarifying requirements, and dealing with conflicts [60]. Accordingly, systems developed

based on goals are more stable than those based on functions, processes or information

structures that often change with time [13].

As discussed earlier, the goal construct in MibML provides a bridge between the

environmental-level and the internal-level specifications of a MIBIS. The overall goals of a

MIBIS identified at the environmental level are organized into a goal tree to represent user

requirements at different levels of details. In the goal tree, a goal is decomposed iteratively

until it reaches a collection of individual goals ( )ig at the leaf goal level. For ease of

discussion, we refer to the collection of all individual goals ( )ig as a goal-set ( )G . It is

important to note that a goal is decomposed only to the point where the level of granularity

corresponds to a role (details are discussed in the role section).

The individual goals ( )ig are mutually exclusive and collectively exhaustive of the

MIBIS system goals. As a result, the goal-set ( )G forms a whole-part relationship in which

an individual goal ( )ig is a component of the goal-set ( )G . The implication is that all the

individual goals ( )ig have to be accomplished in order to satisfy the overall goals of the

system. This constraint is expressed in Axiom 1.

Axiom 1: System goals are accomplished if and only if all individual goals are accomplished.

( )),(_...),(_)(),(_ 11 cgstatehascgstatehasgcgstatehas ∧∨>− ………….. C 1

In order to ensure the enforcement of Axiom 1 in the process of system

development, we include an attribute called status in the goal schema (as shown in Table 4)

in addition to the common attributes that are common to all MibML constructs. The attribute

Page 21: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

21

is used to maintain the state of a goal. An individual goal can be in one of the following

states: completed (c), executing (e), waiting (w), or suspended (s). Although the attribute

status is a design consideration, we include it in the goal schema to facilitate the transition

from conceptual models to design models in system development.

4.2.2 Role

Role is a powerful concept that introduces the organizational view into intelligent

information systems. Traditionally, role has been used to decouple business process

definitions from concrete resources such as physical individual actors [5, 27, 28, 50]. In

system development, role provides “a new abstraction that can unify diverse aspects of a

system” [59]. Usage of the role construct for MIBIS modeling will provide the advantages of

design focus, reusability, and flexibility.

A role has been classically defined as “a collection of duties and rights” [7]. In the

MibML grammar, duties of a role are modeled as tasks and interactions that roles are

obligated to perform for achieving a goal. Rights of a role are modeled as permissions to

utilize information entities. Knowledge within a role provides the intelligence to coherently

perform tasks and interactions to achieve an assigned goal. Tasks are activities that can be

performed by a role alone. On the other hand, interactions are activities that involve at least

two roles. Permissions about global access to information entities (i.e., information entities

contained within the MIBIS) define the rights a role possesses to access and manipulate

them (e.g., create, read, update, and delete information entities). Roles contain declarative

and procedural knowledge components. The functions of roles are directly linked to the

underlying goals associated with them. In essence, the role construct is an abstraction that

provides complete contextual relationship of an agent with all other entities within a MIBIS.

These relationships are shown in Figure 2 and the BNF formalism is presented in Table 4.

In the MibML grammar, roles are responsible for accomplishing system goals. The

relationship between the goal and role concepts is bijective, and is explained as follows.

Page 22: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

22

MibML employs a one-to-one mapping between goal and role. This implies that an individual

goal can be assigned to only one role, and a role is responsible for only one leaf goal of the

larger system goal tree. This is done to provide a rigorous and conceptually simple

distinction between goals and tasks, i.e., the distinction between “what” and “how.” This

distinction, while conceptually intuitive, is often difficult to implement in practice, because it

is hard to draw the boundary between “what” needs to be accomplished versus “how” it will

be accomplished. For example, consider the statement “check credit”. It is difficult to

exactly specify whether this statement is a goal (what) or a task (how), and further,

whether its decomposition will lead to further sub-goals or tasks. The proposed bijective

relationship solves this classical systems analysis problem. MibML requires that a goal

should not be further decomposed when it is assigned to a role. Consequently, such a goal

is a leaf in the goal tree. The bijective mapping also implies that the number of leaf goals

and the number of roles in the system are the same; if there is a difference, then either the

goal tree needs to be folded back (due to over decomposition) or more roles need to be

created (due to role inadequacy). In many design situations, this requirement can easily be

incorporated using any feasible combination of the two strategies. The bijective relationship

between individual goals ( )ig and individual roles ( )ir are expressed in Axiom 2.

Axiom 2: Each individual goal is assigned to a unique role, and each role is responsible for a unique individual goal. ( )( ) ( )( ) ( )( ) ( )( )iiiiiiii grassignedGgRrgrassignedRrGg ,, ∈∃∈∀∧∈∃∈∀ ……………. C 2

( ) ∧≠∧¬→∈∀ )()),(),()(( jiji rrgrassignedgrassignedGg

( ) ( ) ( )( ) ( )( )2121 ,, ggrgassignedrgassignedRr ≠∧¬→∈∀ ……….. C 3

In order to perform tasks, roles need existing information as inputs. In addition,

roles generate new information, which need to be stored in the system. Therefore, roles in

MibML possess one or more privileges that allow them to access and use information entities

and information flows. The granularity at which permissions are granted is determined by

business rules enforced in the system. MibML defines privileges at different levels of

Page 23: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

23

granularity ( /chunki ), as described in Axiom 3.

Axiom 3: Each role possesses permissions to access certain information. ),(),,(_)()( ///

chunkchunkchunk iraccessesiprpermissionhasininformatiorrole →∧∧ ….. C 4

Roles within MibML do not have any hierarchical relationships. Existence of a role

hierarchy would imply Mater-Slave relationships. In the current conceptualization, a MIBIS

system is viewed as a composition of distributed autonomous agents without any central

control. Incorporation of role hierarchies in MibML is beyond our current scope and is a

significant area for future research. Therefore, all agents within the system are

conceptualized to be in peer-to-peer relationships. Consequently, supervisory roles do not

exist as reflected in Axiom 4.

Axiom 4: No role can control other roles in a MIBIS system. ),())(),(( jijiji rresubordinatrrRrr ¬→≠∧∈∀ ………………….. C 5

Finally, in order to ensure the accomplishment of the overall systems goals in a peer-

to-peer environment, MibML provides one special role termed coordinator to track goal

accomplishment status of other roles. The task of the coordinator role ( )rcoordinator is to

update the status of all the goals in the system and ensure that every goal in the overall

system goal tree is accomplished. Therefore, we have the following axiom:

Axiom 5: There exists a coordinator role that possesses the necessary permission to change the status of goals in the MIBIS system. ),,(_ statusgrstatgoalchange rcoordinato− ……………………………… C 6

where swecstatus ,,,= is as defined in Table 3.

4.2.3 Interaction

Interaction is the mechanism by which interdependencies among roles are

coordinated. These interdependencies arise due to functional dependencies among the tasks

performed by different roles, simultaneity constraints, task/subtask relationships, and

Page 24: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

24

shared resources [32]. MibML employs speech act theory to model the communication and

coordination requirements in role interactions. An interaction is defined as a coordinated

sequence of speech acts or communicative acts aimed at defining and reaching a goal [14,

56]. Speech Acts (SA) are utterances that contain information needed to assert and perform

actions and serve as building blocks of communication protocols. They define what people

do while communicating [3, 19, 44]. Speech act verbs are used in speech act utterances, to

perform actions such as booking, complaining, forgiving, etc. [51, 52].

An interaction includes the following four attributes: initiator, responder, speech act,

and message as defined in Table 4. Because isolated roles do not exist in a MIBIS system,

all roles interact with other roles, as indicated in Axiom 6.

Axiom 6: Each role involves in at least one interaction. (∀ r)(∃ ≥1i)(has_initiator(i, r) ∨ has_responder(i, r)) …………………….. C 7

Obviously, every interaction must involve at least two distinct roles. This is captured

in Axiom 7. The role that initiates the interaction is called the initiator and the role receiving

the communication is called the responder. The initiator starts an interaction by sending a

message using a speech act. However, the message may or may not evoke a response.

Likewise, the response from the responder may or may not evoke a new message from the

initiator. The procedural knowledge of roles dictates issues relating to precedence, timing,

frequency, etc. of interactions. A more detailed conceptualization on this subject is included

as part of the knowledge construct discussed subsequently.

Axiom 7: Every interaction involves an initiator role and a responder role. ))(),(_),(_)(()()(( 11

jiiiji rrriresponderhasriinitiatorhasrri ≠∧→∃∃∀ == ………… C 8

4.2.4 Task

A task is also an activity performed to achieve a goal, but is different from an

interaction in that it can be performed by a single role alone. It can be as simple as a single

activity or as complex as a business process workflow. MibML specifies tasks along two

Page 25: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

25

dimensions: task structure and task behavior. The structural specification defines the

composition of task units using a hierarchical structure. A task may be decomposed into

sub-tasks, and a recursive decomposition would lead to a task hierarchy. The task behaviors

specify how the tasks in a hierarchy should be performed (sequence of the tasks, task

interdependencies, the number of times a task is required, optional versus required tasks,

etc). The task behaviors are specified in the activity execution structure and constraints of

the knowledge construct.

MibML supports tasks to be decomposed recursively not only into its constituent

subtasks, but also into different subtypes. For example, a parent task “increase sales” can

be decomposed into the constituent subtask “reduce price”, “change display layout”, etc; it

can also be decomposed into subtypes “increase toy sales”, “increase furniture sales”, etc.

While the former is a decomposition of a task into AND/OR subtask components, the latter

represents an IS-A hierarchy. MibML supports both types task structures. Similar

conceptualization is also employed in Malone et al. [33].

In order to support the task structures, MibML provides two predicates: (a)

),( ji ttpartOf - task it is considered a subpart of task jt ; and (b) ),(_ ji tttypeofisa - task it

is considered to be of type task jt . Axiom 8 describes the transitive closure (C 9 and C 10)

and non-reflexivity properties (C11 and C12) of task decomposition. These properties are

important because they ensure task structure to be represented as a Directed Acyclic Graph

(DAG).

Axiom 8: A task and its sub-level tasks are transitive and non-reflexive. ),(),(),( kikjji ttpartOfttpartOfttpartOf →∧ …………………… C 9

),(_),(_),(_ kikjji tttypeofisatttypeofisatttypeofisa →∧ ……….. C 10

),(),( ijji ttpartOfttpartOf ¬→ ………………………………………….. C 11

),(_),(_ ijji tttypeofisatttypeofisa ¬→ ………………………………. C 12

Page 26: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

26

Partitioning along the dimension of subtypes (isa_typeof relationships) allows for

inheritance from a more generalized type to a more specialized type, in a manner that is

similar to the type hierarchy considered in most object-oriented approaches. In order for a

subtype to inherit a property Φ , the generalized task must have the property and the

generalized type must have an ancestral relationship with the subtype as described in

Axiom 9. Similar to the object-oriented approach, MibML allows for subtypes to override

inherited properties as described in Axiom 10.

Axiom 9: A subtype is able to inherit the properties from its parent. ),,(),(_),(_ Φ→Φ∧ jijji ttinheritstpropertieshastttypeofisa …………. C 13

Axiom 10: A subtype is able to override the properties inherited from its parent. ),(_),,(),,( 2211 Φ→∧Φ iiji tpropertieshastoverridesttinherits φφ ………… C 14

The task construct has been conceptualized to include three attributes: Input, Output

and Method as defined in Table 4. Typically, the Inputs include declarative knowledge and

other data flows; Outputs are task generated and could be classified under either

information or declarative knowledge; the Method metaphor embodies the procedural

knowledge used. While the Inputs are needed for task execution, outputs could result in

updates or may even cause information flows within the MIBIS application or to external

users. A method specifies the detailed logic for execution of the task. A method can be

described using different mechanisms, including structured English and pseudo code.

4.2.5 Information

Information refers to data resources available within a MIBIS application and may

pertain to both the functional (business-aware) and the non-functional (business-unaware;

IT system-specific) aspects of the MIBIS application. The information construct of MibML

consists of information entities and information flows. Information entities refer to internal

data within the system that are part of data stores. They represent regular business objects

(such as PRODUCT, CUSTOMER, etc.) and other materialized views of data. The schema of

Page 27: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

27

information entities includes the structure of tables, the relationships, entity integrity

constraints, referential integrity constraints, cardinality constraints, etc. Information entities

may be implemented using relational databases and the schema corresponds to items

typically stored in database repositories. Information flows represent data that are in

transit; for example, data moving between external users and roles, between information

entities and roles, or between other external systems and roles. Information flows are

different from information entities in their time orientation [12]. Information flows are

temporal. They cease to exist once they are acted upon by an agent or stored in a data

store or provided to an entity external to the MIBIS system. The specifications of both

information entities and information flows are detailed in Table 4.

All data resources and information available within the MIBIS application are

protected and access is based on privileges roles possess. Privileges reflect authority of

roles to view, manipulate, create, or take other alternative actions on information. Privilege

to access information entities and flows are granted at various levels of granularity as

determined by business rules. A role has to be granted the privilege at the intended level of

granularity if it has to be able to access information. Therefore, we have the following

axiom.

Axiom 11: A role is granted privilege to access necessary information. ),,(_),,()( //

chunkchunk iprpermissionhasirpassignrrole →∧ ………….. C 15

4.2.6 Knowledge

Knowledge is modeled as justified true belief that increases an entity’s capacity for

effective action [20, 36]. It resides in the user and not in the collection of information. It is

information possessed in the mind of individuals [1]. Similarly, knowledge in MibML is

conceptualized to exist within individual roles and is therefore private to the roles.

Accordingly, a role must posses the needed knowledge in order to use it. This constraint is

represented in Axiom 12.

Page 28: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

28

Axiom 12: A role can only use its own knowledge. ∀ k(uses_knowledge(r, k) ∃ r(role(r) ∧ knowledge(k) ∧ has_knowledge(r, k)) ………………….. C 16

Individual and organizational knowledge are very broad constructs consisting of both

explicit and tacit knowledge [1]. However, the knowledge construct in MibML is viewed from

a somewhat narrower perspective, in that it captures and represents only computational

knowledge that is explicitly defined4 . Individual and organizational knowledge includes

declarative (know-that) or procedural (know-how). Correspondingly, explicit computational

knowledge in MibML consists of both declarative knowledge ( )kd and procedural

knowledge ( )kp . Declarative knowledge is defined as a collection of facts and deduction

rules. Facts are beliefs that a role keeps about itself, about other roles in the system, and

about the environment it resides in. Deduction rules empower roles to engage in deductive

reasoning with the constraint that at least two existing facts are needed to deduce a new

fact. This is further elaborated in Axiom 13.

Axiom 13: A new fact can only be deducted from at least two existing facts. )(_)),(_))((( 2

newnewdd ffactnewfFruleonoperatesfrule ∧→∃∃ ≥ … C 17

Procedural knowledge is conceptualized to consist of activity execution structure and

activity execution constraints. Activity execution structure relates to knowing the order in

which activities need to occur. An activity is defined here either as a task or as an

interaction. Activity execution structure also includes information regarding how frequently

activities have to be performed and whether certain activities are optional. The predicates

( ( )21 , tt aaprecedes , ( )21, tt aaconcurrent , ),( nafrequency and )(aoptional ) are used to

express activity execution structure, as shown in Table 5.

Activity execution constraints determine the events that trigger activities. In MibML,

4 If tacit knowledge can be converted into explicit knowledge, it can be represented using the

knowledge component of the MibML grammar.

Page 29: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

29

an activity is always triggered by an event. The event can be an external event ( externalev ), a

temporal event ( temporalev ), or a state event ( stateev ). External events emanate either from

the environment including other roles or from end-users (such as a customer placing an

order). External events generated by another role in the system correspond to inter-role-

task dependencies. For example, a role r1 may start executing a task t1 only when another

role r2 completes a task t2. In order to preserve the autonomy of roles and hence the agents

playing the roles, MibML does not permit modeling such constraints as part of the task

execution structure of the role r1. However, such constraints can be modeled as an external

event for role r1. Temporal events are constraints placed on the execution of tasks or

interactions based on some time consideration such as the elapse of some time period. A

state event is an event that occurs inside a role, and changes the state of the role, and

accordingly triggers a task or a set of tasks. The requirements of activity execution

constraints are expressed in Axiom 14.

Axiom 14: Activities in the MIBIS universe must be triggered by an event. (∀ at)(execute(r, at) ∃ ev(trigger(ev, at)) ………………………. C 18

4.2.7 Agent

In an organizational context, a role is assigned to one or more physical human actors

to accomplish organizational goals. In a similar manner, an abstract role in the MIBIS

universe is instantiated by autonomous component agents as shown in Figure 2. The

component agent is modeled as a system entity that is capable of sensing its environment

and acting autonomously to meet its design objectives [58]. Axioms 15 and 16 describe the

conceptualization of the relationship between a role and an agent.

Axiom 15: Every agent in MIBIS must play a role and every role must be played by at least one agent. ( )( ) ( )( ) ( )( ) ( )( )igiGgiiigiiGgi raplaysAaRrraplaysRrAa ,, 1 ∈∃∈∀∧∈∃∈∀ ≥ ………. C 19

Page 30: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

30

Axiom 16: A goal of a role is accomplished by an agent playing the role. ( )( ) ( ) ( )( )( )raroleplaysgrgoalassignedgrgaaccomplish gg ,_),(_),( ∧∃∃→ … C 20

5 CONCLUSION

The concept of Agent is a powerful modeling metaphor for the conceptual

specification of Integrative Business Information Systems. While a typical IBIS can be

conceptualized using the notion of an IS work system, the lack of a global agreement on

what constitutes such a metaphor has led to a proliferation of IBIS architectures and the

ensuing problems of interoperability, integration and scalability, to name a few. On the

other hand, the notion of autonomous agent is well understood in both the MAS literature

and practice. Drawing upon the analogy between the two metaphors, we exploit the well-

understood architectures and behaviors of agents and use it as a metaphor in modeling

IBIS. Using the Agent concept as a fundamental building block of IBIS architectures, we

develop the concept of MIBIS in this work. As a result, a common modeling grammar has

evolved from this research. This grammar can be used to model IBIS architectures in terms

of Agents or MAS architectures in terms of IS work systems. The concept of MIBIS basically

embodies these two and also requires a special-purpose conceptual-modeling grammar to

facilitate its analysis and design. In response, we have developed the MibML grammar for

the conceptual modeling of MIBIS systems. The MibML constructs are extracted from both

MAS and IBIS literatures, and are specified formally in BNF and first order predicate logic. A

proof-of-concept model has also been developed for an e-commerce application to illustrate

the application of MibML grammar and is available as a supplement to this paper.

The MibML grammar provides a starting point for ontology-driven MIBIS

development. There are several future research directions to further this study. First, in

order to enhance the reuse of MIBIS domain specific knowledge, lower-level ontological

categories for the MibML foundation constructs need to be developed (e.g., an ontology of

MIBIS roles, an ontology of MIBIS goals, etc.). These initiatives could also imply a degree of

Page 31: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

31

domain-specificity in MibML definitions and axioms. Second, extensions of the role construct

to incorporate hierarchical role structures that would capture non-autonomous behaviors

present significant areas for further research. Third, interactions in the current study are

limited to direct interactions between a pair of roles. In future work, interactions will be

extended to include those between more than two roles. Finally, knowledge in this study is

limited to deductive reasoning and it is possible to extend MibML to include other types of

knowledge and reasoning mechanisms, such as abductive, inductive, and case-based, etc.

Page 32: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

32

6 REFERENCES

[1] M. Alavi and D. E. Leidner, "Knowledge management and knowledge management

systems: conceptual foundations and research issues," MIS Quarterly, vol. 25, no. 1, pp. 107-136, 2001.

[2] S. Alter, "A general, yet useful theory of information systems," Communications of the Association for Information Systems, vol. 1, no. 13, pp. 1-70, 1999.

[3] J. L. Austin, How to Do Things with Words. Oxford, UK: Clarendon, 1962. [4] A. Bajaj and S. Ram, "SEAM: a state-entity-activity-model for a well-defined

workflow development methodology," IEEE Transactions on Knowledge and Data Engineering, vol. 14, no. 2, pp. 415-431, March/April 2002.

[5] A. Basu and A. Kumar, "Research commentary: workflow management issues in e-business," Information Systems Research, vol. 13, no. 1, pp. 1-14, March 2002.

[6] B. Bauer, J. P. Muller, and J. Odell, "Agent UML: A formalism for specifying multiagent software systems," presented at the First International Workshop (AOSE-2000), Berlin, Germany, 2000.

[7] B. J. Biddle and E. J. Thomas, Role Theory: Concepts and Research: John Wiley & Son, Inc, 1966.

[8] A. H. Bond and L. Gasser, Readings in Distributed Artificial Intelligence. San Mateo, CA: Morgan Kaufmann, 1988.

[9] G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Language User Guide: Addison-Wesley, 1999.

[10] F. M. T. Brazier, C. M. Jonker, and J. Treur, "Compositional design and reuse of a generic agent model," Applied Artificial Intelligence Journal, vol. 14, no. 5, pp. 491-538, 2000.

[11] K. Chari and T. K. Sen, "An implementation of a graph-based modeling system for structured modeling (GBMS/SM)," Decision Support Systems, vol. 22, no. 2, pp. 103-120, February 1998.

[12] S. Conger, The New Software Engineering. California: Wadsworth Publishing Company, 1994.

[13] S. A. Deloach, M. F. Wood, and C. H. Sparkman, "Multiagent systems engineering," International Journal on Software Engineering and Knowledge Engineering, vol. 11, no. 3, pp. 231-258, 2001.

[14] J. L. G. Dietz, "DEMO: towards a discipline of organisation engineering," European Journal of Operational Research, vol. 128, no. 2, pp. 351-363, 2001.

[15] E. H. Durfee and V. R. Lesser, "Negotiating task decomposition and allocation using partial global planning," in Distributed Artificial Intelligence, vol. 2, L. Gasser and M. Huhns, Eds. San Francisco, CA: Morgan Kaufmann, 1989, pp. 229-244.

[16] L. Fischer, "The Workflow Handbook 2001," Association with the Workflow Management Coalition (WfMC), 2000.

[17] M. S. Fox, M. Barbuceanu, M. Gruninger, and J. Lin, "An organization ontology for enterprise modeling," in Simulating Organizations: Computational Models of Institutions and Groups, M. Prietula, K. Carley, and L. Gasser, Eds. Menlo Park CA: AAAI/MIT Press, 1998, pp. 131-152.

[18] S. Franklin and A. Graesser, "Is it an agent, or just a program?: a taxonomy for autonomous agents," presented at Third International Workshop on Agent Theories, Architectures, and Languages, 1996.

[19] J. Habermas, The Theory of Communicative Action, vol. I. Boston: Beacon Press, 1984.

[20] G. Huber, "Organizational learning: the contributing processes and the literatures," Organization Science, vol. 2, no. 1, pp. 88-115, 1991.

Page 33: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

33

[21] N. R. Jennings, "Coordination techniques for distributed artificial intelligence," in Foundations of Distributed Artificial Intelligence, G. M. P. O'Hare and N. R. Jennings, Eds. London: Wiley, 1996, pp. 187-210.

[22] N. R. Jennings, "An agent-based approach for building complex software systems," Communications of the ACM, vol. 44, no. 4, pp. 35-41, 2001.

[23] N. R. Jennings, P. Faratin, M. J. Johnson, T. J. Norman, P. O'Brien, and M. E. Wiegand, "Agent-based business process management," International Journal of Cooperative Information Systems, vol. 2 & 3, pp. 105-130, 1996.

[24] N. R. Jennings, T. J. Norman, P. Faratin, P. O'Brien, and B. Odgers, "Autonomous agents for business process management," Journal of Applied Artificial Intelligence, vol. 14, no. 2, pp. 145--189, 2000.

[25] R. Kishore, H. Zhang, and R. Ramesh, "Ontologies, frameworks, and systems: a helix-spindle model for ontological engineering," Communications of the ACM, 2004.

[26] M. Knapik and J. Johnson, Developing Intelligent Agents for Distributed Systems : Exploring Architecture, Technologies, and Applications. New York: McGraw-Hill, 1998.

[27] A. Kumar, "Dynamic routing and operational controls in workflow management," Management Science, vol. 45, no. 2, pp. 253-272, 1999.

[28] A. Kumar, W. M. P. van der Aalst, and E. M. W. Verbeek, "Dynamic work distribution in workflow management systems: how to balance quality and performance," Journal of Management Information Systems, vol. 18, no. 3, pp. 157-193, Winter 2001-2002 2002.

[29] J. Lee, K. Siau, and S. Hong, "Enterprise integration with ERP and EAI," Communications of the ACM, vol. 46, no. 2, pp. 54-60, 2003.

[30] M. Lejter and T. Dean, "A framework for the development of multi-agent architectures," IEEE Expert, vol. 11, no. 6, pp. 47-59, 1996.

[31] D. S. Linthicum, Enterprise Application Integration. Boston, MA: Addison-Wesley, 1999.

[32] T. W. Malone and K. Crowston, "The interdisciplinary study of coordination," ACM Computing Surveys, vol. 26, no. 1, pp. 87-119, 1994.

[33] T. W. Malone, K. Crowston, J. Lee, B. Pentland, C. Dellarocas, G. Wyner, J. Quimby, C. S. Osborn, A. Bernstein, G. Herman, and M. Klein, "Tools for inventing organizations: Toward a handbook or organizational processes," Management Science, vol. 45, no. 3, pp. 425-443, 1999.

[34] M. Marcotty and H. Ledgrad, "The World of programming Languages." Berlin: Springer-Verlag, 1986, pp. 41-47.

[35] R. Medina-Mora, T. Winograd, and P. Flores, "Action workflow as the enterprise integration technology," Bulletin of the Technical Committee on Data Engineering, vol. 16, no. 2, pp. 49-52, 1993.

[36] I. Nonaka, "A dynamic theory of organizational knowledge creation," Organization Science, vol. 5, no. 1, pp. 14-37, February 1994 1994.

[37] H. Nwana, L. Lee, and N. Jennings, "Coordination in software agent systems," BT Technology Journal, vol. 14, no. 4, pp. 79-88, 1996.

[38] J. Odell, "Objects and agents compared," Journal of Object Technology, vol. 1, no. 1, pp. 41-53, 2002.

[39] J. Y. C. Pan and J. M. Tenenbaum, "An intelligent agent framework for enterprise integration," IEEE Transactions on Systems, man, and cybernetics, vol. 21, no. 6, pp. 1391-1991, 1991.

[40] M. P. Papazoglou and W.-J. v. d. Heuvel, "From business processes to cooperative information systems: an information agents perspective," in Intelligent Information Agents, M. Klusch, Ed.: Springer, 1999.

[41] J. L. Peterson, Petri Net Theory and the Modeling of Systems. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1981.

Page 34: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

34

[42] S. Russell and P.-. Norvig, Artificial Intelligence: A Modern Approach, Second Edition ed. Upper Saddle River, NJ: Prentice Hall, 2003.

[43] A.-W. Scheer, ARIS-Business Process Modeling. Berlin: Springer, 1999. [44] J. R. Searle, Speech Acts: An Essay in the Philosophy of Language: Cambridge

University Press, 1969. [45] R. Sikora and M. J. Shaw, "A multi-agent framework for the coordination and

integration of information systems," Management Science, vol. 44, no. 11, pp. 65 - 78, November 1998.

[46] V. Sugumaran, M. Tanniru, and V. C. Storey, "Supporting reuse in systems analysis," Communications of the ACM, vol. 43, no. 11es, pp. 312-322, November 2000 2000.

[47] J. Tillquist, J. L. King, and C. Woo, "A representational scheme for analyzing information technology and organizational dependency," MIS Quarterly, vol. 26, no. 2, pp. 91-118, June 2002 2002.

[48] V. K. Vaishnavi, G. C. Buchanan, and W. L. K. Jr, "A data/knowledge paradigm for the modeling and design of operations support systems," IEEE Transactions on Knowledge and Data Engineering, vol. 9, no. 2, pp. 275-291, March-Aprial 1997.

[49] W. M. P. van der Aalst and K. Akhil, "XML-based schema definition for support of interorganizational workflow," Information Systems Research, vol. 14, no. 1, pp. 23-46, 2003.

[50] W. M. P. van der Aalst and A. Kumar, "A reference model for team-enabled workflow management systems," Data & Knowledge Engineering, vol. 38, no. 3, pp. 335-363, 2001.

[51] J. Verschueren, The analysis of speech act verbs: theoretical preliminaries. Bloomington, Indiana: Indiana University Linguistic Club, 1977.

[52] J. Verschueren, On speech act verbs. Amsterdam: John Benjamins, 1980. [53] P. Vitharana, F. M. Zahedi, and H. Jain, "Knowledge-based repository scheme for

storing and retrieving business components: a theoretical design and an empirical analysis," IEEE Transactions on Software Engineering, vol. 29, no. 7, pp. 649-664, July 2003.

[54] Y. Wand and R. Weber, "Research commentary: information systems and conceptual modeling - a research agenda," Information Systems Research, vol. 13, no. 4, pp. 363-376, 2002.

[55] H. Weigand and W.-J. v. d. Heuvel, "Cross-organizational workflow integration using contracts," Decision Support Systems, vol. 33, pp. 247-265, 2002.

[56] T. Winograd, "A language/action perspective on the design of cooperative work," Journal Of Human-Computer Interaction, vol. 3, no. 1, pp. 3-30, 1987-88.

[57] M. Wooldridge, An Introduction to Multiagent Systems. West Sussex, England: John Wiley & Sons, Ltd, 2002.

[58] M. Wooldridge and N. R. Jennings, "Intelligent agents: theory and practice," Knowledge Engineering Review, vol. 10, no. 2, pp. 115-152, 1995.

[59] M. Wooldridge, N. R. Jennings, and D. Kinny, "The Gaia methodology for agent-oriented analysis and design," Autonomous Agents and Multi-Agent Systems, vol. 3, no. 3, pp. 285 - 312, 2000.

[60] E. Yu and J. Mylopoulos, "Why goal-oriented requirements engineering," presented at 4th International Workshop on Requirements Engineering: Foundations of Software Quality, Pisa, Italy, 1998.

Page 35: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

35

7 SUPPLEMENTAL MATERIAL: PROOF-OF-CONCEPT ILLUSTRATION

This supplemental material provides a simple but comprehensive example to

illustrate the application of the MibML grammar in modeling a MIBIS application. In the

example, we consider a fictitious online retailer that sells computer products, software, and

electronics to consumers. The goal of the particular MIBIS application is to support sales of

made-to-order personal computers. We model the key features of this scenario using MibML

so that the essential concepts of the MibML modeling grammar can be illustrated without

getting bogged down with trivial details about the business scenario and the application. We

simplify the business processes of made-to-order PC sales and put our focus on describing

how the MibML constructs are applied to model this MIBIS application.

The business processes involves actors in the following areas: the customer service

area deals with customers, the PC assembly planning area plans the assembly of PCs

according to customers’ requirements, and the delivery area is responsible for delivering

assembled PCs to customers. These three areas work independently but coordinate with

each other to provide services to customers. The scenario begins with a customer trying to

buy a new PC with his/her own hardware and software options. After the customer finalizes

a computer configuration, the customer service area generates a price quote for the

customer. If the customer decides to place an order, the customer service collects customer

information and sets up an account for him/her if this is his/her first order. Based on

customer’s credit, the customer service area decides whether to reject the order or to

approve the order and propose financing options. If an order is approved, the PC assembly

planning area checks inventory for necessary parts to assemble the PC. If some required

parts are not available, the PC assembly area contacts suppliers and decides where to

order5. The PC assembly planning area also estimates the time needed to assemble the PC

5 Generally inventory planning and procurement from suppliers is done based on demand forecasts

but we are not modeling this function in this simple illustration.

Page 36: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

36

and updates the PC assembly status. After the PC is assembled, the delivery area schedules

the shipment. The responsibilities of the delivery area include determining the method of

delivery, packaging the assembled PC, estimating the delivery date, scheduling the pick-up

of the assembled PC by a shipping company, and updating the shipment status. We only

consider some of the delivery area responsibilities in this example as we wish to keep the

illustration comprehensive yet simple. Further, while a real application will have to handle

several more functions and exception conditions, selecting an appropriate supplier,

additional information requested for credit processing, etc., we do not include them in the

example discussed below as they will be modeled in a similar manner as other situations

and conditions will be modeled, and we wish to keep the illustration to a manageable

length.

In order to model the above application, we first need to identify user requirements.

In the MibML grammar, the user requirements are captured as goals which are organized in

a tree structure. The goal tree for this particular application is very simple and is

constructed as in Figure 3. We have an overall goal G1 to provide made-to-order PC service.

G1 is decomposed into sub-level goals: G1.1 to manage customers and their orders, G1.2 to

plan PC assembly, and G1.3 to schedule PC delivery. These sub-level goals are mutually

exclusive and collectively exhaustive. Therefore, G1 is accomplished only when G1.1, G1.2,

and G1.3 are all accomplished.

Page 37: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

37

Figure 3: The goal tree for the online PC made-to-order system

In Figure 3, we have three individual goals, which form a goal set G1.1, G1.2,

G1.3. In MibML, each individual goal is assigned to a unique role and each individual role is

associated with a unique goal. Therefore, these individual goals are assigned to 3 distinct

roles – customer service representative, assembly planner, and delivery manager. In

addition, a special coordinator role is required in MibML to ensure the accomplishment of all

individual goals. Because the coordinator role does not affect business process modeling, we

do not discuss the coordinator role in this example. The bijective mapping between goals

and roles are described in Table 6.

Table 6: The bijective mapping between goals and roles

Goal Role

G1.1 to manage customers and their orders R1 Customer service representative

G1.2 to plan PC assembly R2 Assembly planner G1.3 to schedule PC delivery R3 Delivery manager

Role is the central construct in MibML for modeling the MIBIS universe. A MIBIS

conceptual model provides definitions of roles and defines how roles interact. Figure 4

presents the conceptual model developed in MibML for the made-to-order PC service

application. As indicated in Figure 4, a role is an abstraction of goal, activities (tasks and

Page 38: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

38

interactions), knowledge, and information privileges. Role R1 Customer Service

Representative is responsible for interacting with customers. Therefore, there are

information flows between role R1 and customers. Customers need to pass their selected PC

configuration and order request to role R1, and role R1 returns price quote, order

processing results, financing options, or order status. The tasks of role R1 include

generating price quote for customers’ request, managing account, checking credits, and

processing order. These tasks require information and knowledge as inputs and generate

outputs. For example, in order to generate price quote, role R1 must be able to read

information entity Inventory to get cost information. Therefore, there are information flows

between role R1 and information entities Customer, Order, and Inventory6.

Correspondingly, role R1 has information privileges to fully control (create, read, update,

and delete) information entity Customer and Order, and to read information entity

Inventory. In addition, role R1 must have knowledge on pricing policy, financing options,

and decision policies to reject or approve an order. Further, when a customer places an

order, role R1 interacts with role R2 Assembly Planner to notify that an order has been

received for assembly and delivery of a PC. Role R2 Assembly Planner is responsible for

planning PC assembly after receiving order notification from role R1 Customer Service

Representative. Its tasks include scheduling assembly, checking if the necessary parts are

available, and placing orders with suppliers if the parts are out of stock. In order to perform

these tasks, role R2 needs to access information entity Inventory and Order. This is

represented as information flows between role R2 and information entities. Role R2 is

assigned information privileges as required by its tasks. It has full control on Inventory, and

read privilege on Order and update privilege on the order assembly status. In order to

perform its tasks, role R2 also need to possess knowledge about part suppliers and

knowledge on estimating assembling time. Knowledge about part suppliers can also be 6 Once again to keep the example to a manageable length, we model essential information about PC

parts and quantities available in a single information entity Inventory. In real-life applications, these may be modeled as two or more separate information entities.

Page 39: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

39

modeled as an information entity in this example. However, we choose to model knowledge

about parts suppliers as knowledge and not as an information entity because this

information is private to the role, i.e., it is not required by other roles, and hence there is

not need to model it is a shared information entity7. When PC assembly is complete, role R2

sends a notification to role R3 Delivery Manager. This is represented as an interaction

between role R2 and R3. When receiving the PC ready notification, role R3 Delivery Manager

schedules PC delivery. Information required for performing this task is Order, and it is

represented as information flow between role R3 and information entity Order.

Correspondingly, role R3 is able to read information entity Order and to update the order

shipment status. In addition, role R3 possesses knowledge to determine whether PC

delivery should be batch delivery or individual delivery.

Figure 4 provides a high-level conceptual model for describing the made-to-order PC

service application. In the rest of the paper, we discuss individual MibML constructs involved

in the model.

7 While the MibML grammar does not provide explicit guidelines for modeling something as knowledge

versus information entity or vice versa, knowledge is private to a role whereas information entities are repositories of shared information. Therefore, unique pieces of information that are only used by a particular can be modeled as declarative knowledge by way of facts and rules.

Page 40: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

40

Figure 4: The conceptual model of the made-to-order PC service application

A task is an internal activity performed by a role. In MibML, a high-level task can be

refined by decomposition and specialization. Figure 5 shows an example of task

Page 41: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

41

decomposition and specialization. Figure 3(a) depicts that a high-level task of Assembly

Planner T2 Order Inventory consists of two parts: T2.2 Check Inventory and T2.3 Order

Parts. T2.2 and T2.3 are mutually exclusive and collectively exhaustive, and T2 is

accomplished only when both T2.2 and T2.3 are accomplished. Figure 3(b) depicts that a

task of Delivery Manager T3.1 Schedule Delivery has two subtypes: T3.1.1 Schedule Batch

Delivery and T3.1.2 Schedule Individual Delivery. Both T3.1.1 and T3.1.2 inherit properties

from T3.1, but they may override inherited properties.

Figure 5: Task decomposition and specialization

Task in MibML is specified by input, output, and method in addition to the common

attributes for all MibML constructs. Due to space limitations, we only include task

specifications for role R1 Customer Service Representative. The detail specifications are

presented in Table 7 - Table 10.

Page 42: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

42

Table 7: Specification of task “Generate quote”

Task

Identifier T1.1

Name Generate quote

Description Generate the price quote for the pc configuration selected by customer Input INF12 Inventory (component cost)

KF1.1 PC base price KF1.2 Discount threshold

Output KF1.3 PC final price INF3 price quote

Method Do for each customer Generate price based on component cost and pricing policy Enddo

Table 8: Specification of task “Manage account”

Task

Identifier T1.2

Name Manage account Description Set up an account for new customer and update customer information

Input INF1 customer information

Output INF8 customer Method If new customer

set up a new account Endif If existing customer authenticate customer Endif If customer changes information update customer information Endif

Table 9: Specification of task “Manage account”

Task

Identifier T1.3 Name Check credit

Description Check customer’s credit

Input INF10 Customer INF11 Credit

Output INF8 Customer INF9 Credit

Method Check internal credit records of customer If no internal credit records exist Check customer’s credit with credit card company Endif

Page 43: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

43

Table 10: Specification of task “Process order”

Task

Identifier T1.4

Name Process order Description Decide whether to accept or reject order, create order for customer, propose

financing options, and update order status

Input INF3 Order request INF11 Credit KF1.4 Credit ranking score KD1.2 Order rejection/approval policy KD1.3 Financing rule

Output INF5 Order rejection / approval INF6 Financing options INF14 Order INF7 Order status

Method Approve or reject order If order approved Create order Propose financing options Endif If order rejected Notify customer of the rejection Endif

An interaction is an activity that occurs between two roles. Figure 4 shows two

interactions existing in the application. Interaction I1_2 is an interaction initiated by

Customer Service Representative to notify Assembly Planner that an order is ready to be

assembled; I2_3 an interaction initiated by Assembly Planner to notify Delivery Manager

that a PC ordered by customer has been assembled and is ready to be shipped. In MibML,

an interaction is specified by initiator, responder, speech acts, and message content in

addition to common attributes defined for all MibML constructs. Table 11 provides the detail

specifications of interaction I1_2 Order Notification. Table 12 provides the detail

specifications of interaction I2_3 Assembly Completion Notification.

Page 44: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

44

Table 11: Specification of the interaction “Order notification”

Interaction

Identifier I1_2 Name Order notification

Description Customer Service Representative notifies Assembly Planner that an order is ready to be assembled

Initiator role R1 Customer service representative

Responder role R2 Assembly planner

Initiator speech act Assertion Initiator message A specific order is ready to be assembled

Responder speech act Acceptance

Responder message Notification is confirmed

Table 12: Specification of the interaction “Assembly complete notification”

Interaction

Identifier I2_3

Name Assembly completion notification

Description Assembly Planner notifies Delivery Manager that a PC ordered by a customer is ready to be shipped

Initiator role Assembly planner

Responder role Delivery manager Initiator speech act Assertion

Initiator message The PC in a specific order is ready to be shipped

Responder speech act Acceptance Responder message Notification is confirmed

Information in MibML includes information entities and information flows. Information

entities represent stable data in the system. Figure 4 indicates that our application includes

3 information entities: INE1 Customer, INE2 Order and INE3 Inventory. The specifications of

information entities in MibML are not different from those in traditional data model.

Attributes are used to keep data that system analysts are interested in. Table 13 provides a

detail specification of information entity inventory.

Page 45: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

45

Table 13: Specification of information entity “Customer”

Information entity

Identifier INF1

Name Customer

Description Customer information and his/her credit status Attributes Customer number, Name, address, phone, internal credit ranking

Table 14: Specification of information entity “Order”

Information entity

Identifier INF2 Name Order

Description Order information

Attributes Order number, order date, PC configuration, order status, price

Table 15: Specification of information entity “Inventory”

Information entity

Identifier INF3

Name Inventory Description Inventory information of pc components

Attributes Part name, model, serial number, cost, quantity available, suppliers

Information flows are temporary data transmitted between external entities and

roles within the systems or between roles and information entities within the MIBIS system.

In MibML, it is specified by flow source, flow sink, flow frequency, flow response time, and

flow data. Figure 4 indicates there are 20 information flows involved in the application. We

do not intend to specify all of them due to space limitation. Table 16 is the specification of

information flow Customer Information, which is an example of information flows between

an external entity and a role. Table 17 is the specification of information flow Credit, which

is an example of information flows between a role and an information entity.

Table 16: Specification of information flow INF1 Customer Information

Information Flow

Identifier INF1

Name Customer information

Description Basic customer information to set up an account Flow source External entity Customer

Page 46: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

46

Flow sink R1 Customer service representative

Flow frequency When a customer account is set up for the first time or when there are changes to existing customer information

Flow response time

Synchronous

Flow data Name, address, phone

Table 17: Specification of information INF9 Credit

Information Flow

Identifier INF9 Name Credit

Description Update customer’s credit information

Flow source R1 Customer service representative Flow sink INE1 Customer

Flow frequency When there are changes to customer’s credit information

Flow response time

Synchronous

Flow data Customer’s credit ranking

Knowledge in MibML is private to a role. It includes declarative knowledge and

procedural knowledge. Declarative knowledge is a role’s beliefs about the environment and

other roles. Declarative knowledge is specified in MibML using facts and deduction rules.

Declarative knowledge, like information, is used as inputs or generated as outputs of tasks.

Procedural knowledge describes the constraints on performing activities (tasks and

interactions). It is specified as activity execution structure and activity execution

constraints. Activity execution structure is represented a sequence of tasks inside a role.

Activity execution constraints are defined as a set of events that are used to coordinate

tasks among different roles. Table 18 provides specifications of knowledge for Customer

Service Representative. Table 18 indicates that Customer Service Representative possesses

3 facts (KF1.1, KF1.2, and KF1.3) and 3 deduction rules (KD1.4, KD1.5, and KD1.6). In

MibML, a deduction rule uses at least two existing facts or information flows to generate a

new fact or information flow. For example, deduction rule KD1.1 uses an existing KF1.1 fact

and an existing KF1.2 fact to generate a new KF1.3 fact; and deduction rule KD1.2 uses an

existing information flow of INF11 and an existing K1.3 fact to generate a new information

Page 47: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

47

flow of INF5. Table 18 also specifies procedural knowledge (KT1.1 and KX1.1) for Customer

Service Representative. Activity execution structure KT1.1 specifies the order to execute the

internal tasks (T1.1, T1.2, T1.3, and T1.4) and the interactions (I1_2). Activity execution

constraint KX1.1 specifies task-triggering events that are used to coordinate Customer

Service Representative with other roles. Similarly, Table 19 and Table 20 specify the

knowledge of Assembly Planner and Delivery Manager.

Table 18: Specification of knowledge of “Customer Service Representative”

Knowledge

Identifier K1 Name Customer Service Representative Knowledge

Description Knowledge on pricing, credit ranking, financing, order rejection/approval policy, and constraints on performing tasks

Declarative Knowledge

Facts KF1.1 PC base price PC base price = Cost x (1+10%) KF1.2 Discount threshold KF1.3 PC final price PC final price = PC base price x (1-discount percentage) KF1.4 Credit ranking score High ranking score and low ranking score

Deduction rules KD1.1 Discount policy If the base price of an order (KF1.1) is more than the discount threshold (KF1.2), the customer gets 5% discount (K1.3). KD1.2 Order rejection/approval policy If customer has credit ranking (INF11) less than the low ranking score (K1.3), reject the order (INF5). Otherwise, accept the order (INF5). KD1.3 Financing rule If customer has credit ranking (INF11) greater than the high Ranking score (K1.4), propose financing options (INF6).

Procedural Knowledge

Execution structure KT1.1 Activity execution structure • T1.1 generate quote and T1.2 manage account precede T1.3

check credit. • T1.3 check credit precedes T1.4 process order. • T1.4 process order precedes I1_2 order notification.

Execution constraints KX1.1 Activity execution constraints • T1.1 generate quote is triggered by receiving customer’s quote

request. • T1.2 management account is triggered by receiving customer’s

order request.

Page 48: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

48

Table 19: Specification of knowledge of Assembly Planner

Knowledge

Identifier K2

Name Assembly Planner Knowledge

Description Knowledge on suppliers, assembly time, and constraints on performing tasks

Declarative Knowledge

Facts KF2.1 suppliers • Supplier A provides high quality parts. • Supplier B is less expensive.

KF2.2 Supplier selection KF2.3 Assembly time

Deduction rules KD2.1 Supplier selection If high quality components are needed (INF18 and KF2.1), select Supplier A (KF2.2); otherwise, select Supplier B (K2.2). KD2.2 Assembly time estimation If all parts are available (INF16 and INF 18), it takes average 1 week to assemble PC (KF2.2). Otherwise, it takes average 2 weeks (KF2.2).

Procedural Knowledge

Execution structure KT2.1 Activity execution structure • T2.2 check inventory precedes T2.3 order parts • T2.2 check inventory precedes T2.1 schedule assembly • T2.1 schedule assembly precedes I2_3 assembly completion

notification

Execution constraints KX2.1 Activity execution constraints • T2.2 check inventory is triggered by I1_2 order notification

Table 20: Specification of knowledge of Delivery Manager

Knowledge

Identifier K3

Name Delivery Manager Knowledge

Description Knowledge on delivery as well as constraints on performing tasks.

Declarative Knowledge

Facts KF3.1 Delivery time KF3.2 Delivery types Local delivery and long distance delivery KF3.3 Delivery methods Individual delivery and batch delivery

Deduction rules KD3.1 Delivery policy If an order (INF19) is a local delivery (KF3.2), it delivered individually (INF20). Otherwise, it is delivered in batches (INF20). KD3.2 Delivery time estimation If an order (INF19) is a local delivery (KF3.2), it takes 2-3 days (KF3.1); otherwise, it takes average 7 days (KF3.1).

Procedural Knowledge Execution structure None

Execution constraints KX3.3 Activity execution constraints • T3.1 schedule delivery is triggered by I2_3 assembly completion

notification

Page 49: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

49

A role is an integration of goal, tasks, interaction, knowledge, and information

privilege. With the above constructs defined, it is easy to specify roles in the system. Table

21 - Table 23 provides specifications for role Customer Service Representative, Assembly

Planner, and Delivery Manager respectively.

Table 21: Specification of role Customer Service Representative

Role

Identifier R1

Name Customer service representative

Description A customer service representative interacts with customer, and is responsible for generating price quote, manage customer account, and process order.

Goal G1.1 To manage customers and their orders Interactions I2_3 Order notification

Tasks T1.1 generate quote T1.2 manage account T1.3 check credit T1.4 process order

Information permissions • Full control on INE1 Customer • Full control on INE2 Order • Read INE3 Inventory

Knowledge Declarative Knowledge KF1.1 PC base price KF1.2 Discount threshold KF1.3 PC final price KF1.4 Credit ranking score KD1.1 Discount policy KD1.2 Order rejection/approval policy KD1.3 Financing rule Procedural Knowledge KT1.1 Activity execution structure KX1.1 Activity execution constraints

Table 22: Specification of role Assembly Planner

Role

Identifier R2

Name Assembly planner

Description Plan PC assembly Goal G1.2 To plan PC assembly

Interactions • I1_2 Order notification • I2_3 Assembly completion notification

Tasks T2.1 schedule assembly T2.2 check inventory T2.3 order parts

Information permissions • Full control on INE3 Inventory • Read INE2 Order

Page 50: MibML: A Conceptual Modeling Grammar for Integrative …misrc.umn.edu/workshops/2004/spring/rajiv.pdf3 theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based

50

• Update INE2 Order – assembly status

Knowledge Declarative Knowledge KF2.1 suppliers KF2.2 Supplier selection KF2.3 Assembly time KD2.1 Supplier selection KD2.2 Assembly time estimation Procedural Knowledge KT2.1 Activity execution structure KX2.1 Activity execution constraints

Table 23: Specification of role Delivery Manager

Role

Identifier R3

Name Delivery manager Description Manage inventory and schedule delivery

Goal G1.3 To manage delivery

Interactions • I2_3 Assembly completion notification Tasks T3.1 schedule delivery

Information permissions • Read INE2 Order • Update INE2 Order – shipment status

Knowledge Declarative Knowledge KF3.1 Delivery time KF3.2 Delivery types KF3.3 Delivery methods KD3.1 Delivery policy KD3.2 Delivery time estimation Procedural Knowledge KX3.1 Activity execution constraints

Agents in MibML are instantiation of roles. There is one-to-one mapping between

roles and agent types. Table 24 provides mapping between roles and agents in our

application.

Table 24: Mapping between roles and agents

Role Agent

R1 Customer service representative A1 Customer service representative agent R2 Assembly planner A2 Assembly planner agent

R3 Delivery manager A3 Delivery manager agent