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
rkishore@buffalo.edu
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
rkishore@buffalo.edu
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: hoz565f@smsu.edu
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
rramesh@acsu.buffalo.edu
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.
1
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 rolecentricity. 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 Multiagentbased IBIS (MIBIS). In this research, we introduce the MIBIS concept and develop a
2
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 coordination
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.
3
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.
4
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
5
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
conceptualization
of
IBIS
[32].
work
The emerging IBIS
systems
as
paradigm
autonomous
leads
agents
logically
with
to
a
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
6
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
7
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.
8
MIBIS Environment
MIBIS
(Multiagent-based Integrative Business Information System)
Entity
System
Goals
Legend:
MIBIS Entity
Non-MIBIS Entity
Software Agent
Information resource
Interaction between
agents
Information Flow to/from an agent with an
environmental entity / information resource
User
Figure 1: The MIBIS Universe and its Architecture
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 specialpurpose 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,
9
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 specialpurpose 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
10
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.
11
Table 1. A Summary of Various Modeling Grammars and their Support for the MIBIS Universe
IS Grammar
Supported Feature
Agent modeling
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]
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 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
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
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
L
M
H
H
H
H
H
H
M
L
L
L
H
Data modeling
Knowledge modeling
Coordination mechanism3
Task modeling
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.
12
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
13
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
[1, m]
Is_involved_in /
Includes
[1, m]
Agent
[1, m]
Interaction
Is_constrained_by /
Includes_procedural_knowledge_about
Plays /
Is_played_by
[1, m]
[1, 1]
[2, 2]
[1, 1]
Role
Knowledge
Possesses / Is_possessed_by
[1, m]
[1, m]
Goal
[1, 1]
[1, m]
[1, 1]
[1, m]
[1, 1]
[1, m]
Has_privileges_to_access /
Is_accessed_by
Is_assigned_to /
Is_assigned
Information
[1, m]
[1, m]
Is_required_for / Requires
Performs / Is_performed_by
Figure 2: The MibML Constructs and their Inter-relationships
14
Includes_procedural_knowledge_about /
Is_constrained_by
[1, m]
Task
[1, m]
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
Type
Instances
Individual
Bolded Lower Case letter(s)
Lower Case letter(s)
15
Collection
Bolded Upper Case letter/(s)
Upper Case letter/(s)
Table 3: Symbols used in MibML Specifications
Notation
General
Description
Ψ
Collection of MibML constructs
ψ
MibML Construct
∆
Collection of relationships
Notation
Description
Knowledge
Knowledge
k
Ψ = {ψ i : i = 1,..., n}
Relationships
δ
Τ
Collection of constraints
τ
constraints
C attributes
Common Attributes
at
Activity (a task or an interaction)
Goal
g
G
Goal
Goal Status
Completed
Executing
goal status
Duties of a role
Privilege
Interaction
Interactions
i
msg Communication from initiator role
External event
evexternal
evtemporal
Temporal event
ev state
State event
Information
Information flow
e
e
Information entity
Information entity instance
Information entity type
einfo
Internal entity information
i / flow−control −inf o
Metadata for information flow
c
control
i
/
i
/
flow− source
Source from which an
information flow emanates
flow− sink
Entity receiving the
information flows
to responder role
Response to a message
/
i data
i ' flow−external
Communicative act
Actual data with flow
External source/sink for
information flow
Action verb for
i
communication
Example: Assertion, Query,
etc.
Actual message
content
/
flow− frequency
Agent
ag
Task
φ
Event
i/
i/ f
i/e
rgeneral Generic roles
r
Normal roles
rcoordinator
Special role to maintain
t
Workflow patterns
Procedural knowledge
Information
Waiting
Suspended
resp
speech
speech Act
wp
ev
Collection of goals;
Role
d
p
Declarative knowledge
f
Facts
rule d Deduction rule
x structure
Execution structure
xorder Execution order
x constra int
Execution constraint
G = {g i : i = 1,.., n}
status
c
ex
w
s
kd
kp
Tasks
Property / Logic / Subcomponent.
16
Agent
Information flow frequency
Table 4: The MibML Conceptual Modeling Grammar in BNF
MibML Grammar
(Ω ) = {Ψ , ∆, Τ}
where
Ψ = {ψ i ∀i = 1..n} in which ψ i is a MibML construct,
∆ = {δ i ∀i = 1..n} in which δ i is a relationship between concepts, and
Τ = {τ i ∀i = 1..n} in which τ i is a constraint.
ψ ::= [ G | R | I | T | I / | K | A ]
C attributes ::= id , name, description
Goal:
< g >::=< C attributes >< status >
< status >::= [c | e x | w | s | ...]
Bijective
mapping
< g >  
→ < r >
Role:
< rGeneral >::= [< r >|< rcoordinator >]
< r >::=< C attributes >< k >< d >
< d >::=< a >|< d >< a >
< a >::= [< t >|< i >]
< rcoordinator >::=< C attributes >< d special >
< d special >::= {Update goal status}
Interaction:
< i >::=< Cattributes >< Speech >
< Speech >::=< Msg >|< Speech > [< Resp >]
/* Comments :
The symbol < Message
> is used to express both < Msg > and < Re sp >
same format. [< Msg >|< Re sp >::=< Message > */
< Message >::=< initiator >< responder >< speech Act >< content >
as they have the
−a
[< initiator >|< responder >] is→

<r>
< speech Act >::= [ Assertion | Query | Re quest | Perform | Commitment | Denial | ...]
< content >::= {message communicated during interaction}
Task:
< A >::=< a >|< A > [< a >]
< a >→ [< t >|< i >]
< t >::=< C attributes >< input >< output >< method >
/* Comments:
The symbol < i / o
>
is used to express both
< input >
17
and
< output >
as they have the same
[< input >|< output >] ::=< i / o > */
< i / o >::= [< k d >|< i / f >] |< i / o > [< k d >|< i / f >]
< Method >::=< Φ >
< Φ >::=< φ >|< Φ >< φ >
< φ >::= Method1 | Method 2 | ... | property1 | property 2 | ...
format
Information:
_a
< i / > is

→[< i / e >|< i / e >]
< i / e >::=< C Attributes >< einf o >< e >
< einfo >::= {Semantic, syntactic and structral information about the entity}
< e >::= {data associated with an entity instance}
< i / f >::=< C Attributes >< i / flow_control_info >< i / flow _ data _ inf o >< i / data >
< i / flow_control_info >::=< i / flow − source >< i / flow − sink >< i / flow− frequency >< i / flow −response _ time >
< i / flow − source >::= [< r >|< i / e >|< i / flow −external >] |< i / flow− source > [< r >|< i / e >|< i / flow −external >]
< i / flow − sink >::= [< r >|< i / e >|< i / flow− external >] |< i / flow− sink > [< r >|< i / e >|< i / flow−external >]
< i / flow−external >::= [End User | MIBIS entity | Non - MIBIS entity]
< i / flow_data_info >::= [ Data_Structure | format_Information | ...] |< i / flow_data_info > [ Data_Structure | format_Information
< i / data >::= instance_data
< i / chunk >::= Entity | Entity_instance | Entity _ attribute | Entity_instance_attribute_value |
< P >::= [Re ad | Write | View | Grant | Pr int | ...] |< P > [Re ad | Write | View | Grant | Pr int |
Knowledge:
< k >::= [< k d >|< k p >] |< k > [< k d >|< k p >]
< k d >::=< C Attributes > [< F >|< RULE d >] |< k d > [< F >|< RULEd >]
< F >::=< f >|< F >< f >
< f >::= [ Assertion1 | Assertion 2 | Assertion 3 | ...]
< RULEd >::=< rule d >|< RULEd >< rule d >
< rule d >::= [ Dedection _ rule _ 1 | Dedcution _ Rule _ 2 | ...]
< k p >::=< C Attributes >< w p >|< k p >< w p >
< w p >::= [< x structure >|< x constraints > ]
< x strucuture >::= [sequence | parallel _ split | exclusive _ choice | ...]
< x constraint >::= [ev external | ev temporal | ev state | ev resource | ...]
Agent:
Bijective
< r > mapping

→ < a >
18
Table 5: List of Predicates Used to Specify the MibML Grammar.
PREDICATE
MEANING
/
accesses (r , i chunk )
accomplish( g , r )
agent ( a g )
Role
Goal
r accesses the information i / chunk
g is accomplished by role r
is an agent
ag
/
assign( p, r , ichunk
)
assigned (r , g )
change _ goal − stat (rcoordinator , g , status )
Role
concurrent (at1 , at 2 )
Activity at1 is in parallel with activity at2
Privilege
p is assigned to role r
r is assigned to goal g
Role
rcoordinator
status
for
i / chunk
changes the state of goal
g to
execute(r, at)
Role r performs activity at
frequency(at , n)
goal ( g )
has _ goal ( a g , g )
Activity at must be performed with frequency n
Agent
has _ initiator (i, r )
Role
r
has _ permission (r , p, i / chunk )
has _ properties (ti , Φ)
has _ responder (i, r )
has _ state( g , status )
Role
r has permission p to access i / chunk
ti has a collection of Properties / Methods Φ
r is the responder of the interaction
g has state status
/
information(i )
inherits (ti , t j , Φ)
interaction(i )
isa _ typeof (ti , t j )
knowledge (k )
new _ fact ( f )
operate _ on(rule d , F )
g
is a goal
Task
Role
Goal
i/
has a goal
ag
g
is the initiator of an interaction
is either an information entity or flow
Task t i inherits from task
tj
collection of Properties
/Methods Φ
i is an interaction
Task t i is of type
k
f
tj
is a knowledge nugget
is a new fact
Deduction rule has to operate on facts
optional (at )
Activity
overrides (ti , φ1 , φ2 )
Task t i overrides property
partOf (t i , t j )
Task t i is a sub-task of part of task
plays ( a g , r )
Agent
precedes(at1 , at 2 )
at is optional
plays role
ag
φ1
with property
tj
r
Activity at1 is executed before activity at2
/
revoke( p, r , ichunk
)
role(r )
subordinat e( ri , r j )
Role
task (t )
t
trigger(ev, at)
Activity at is triggered by event ev
Privilege
r
p is assigned to role r
for
is a role
ri
is subordinate to role
rj
is a task
19
i / chunk
φ2
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 ( g i ) at the leaf goal level. For ease of
discussion, we refer to the collection of all individual goals ( g i ) 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 ( g i ) 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 ( g i ) is a component of the goal-set (G ) . The implication is that all the
individual goals ( g i ) 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.
has _ state( g , c )− > (∨ g )(has _ state ( g1 , c ) ∧ ...has _ state( g 1 , c ) )
………….. 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
20
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.
21
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 ( g i ) and individual roles (ri ) 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.
((∀g i ∈ G )(∃ri ∈ R )assigned (ri , g i )) ∧ ((∀ri ∈ R )(∃g i ∈ G )assigned (ri , g i ))
((∀g ∈ G )(assigned (r , g ) → ¬assigned (r , g )) ∧ (r
i
j
i
……………. C 2
≠ rj )) ∧
((∀r ∈ R )(assigned (g1 , r ) → ¬assigned (g 2 , r )) ∧ (g1 ≠ g 2 )) ……….. 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
22
granularity ( ichunk ), as described in Axiom 3.
/
Axiom 3: Each role possesses permissions to access certain information.
/
/
/
role( r ) ∧ information(ichunk
) ∧ has _ permission ( r , p, ichunk
) → accesses ( r , ichunk
) …..
C4
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.
((∀ri , r j ∈ R ) ∧ ( ri ≠ r j )) → ¬subordinate( ri , r j )
…………………..
C5
Finally, in order to ensure the accomplishment of the overall systems goals in a peerto-peer environment, MibML provides one special role termed coordinator to track goal
accomplishment status of other roles. The task of the coordinator role
(rcoordinato r )
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.
change _ goal − stat (rcoordinator , g , status )
………………………………
C6
where status = {c, e, w, s} 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
23
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))
……………………..
C7
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.
(∀i )(∃=1ri )(∃=1r j )((has _ initiator (i, ri ) → has _ responder (i, ri ) ∧ ( ri ≠ rj )) ………… 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
24
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)
partOf (t i , t j ) - task ti is considered a subpart of task t j ; and (b) isa _ typeof (ti , t j ) - task ti
is considered to be of type task t j . 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.
partOf (t i , t j ) ∧ partOf (t j , t k ) → partOf (t i , t k )
……………………
isa _ typeof (ti , t j ) ∧ isa _ typeof (t j , t k ) → isa _ typeof (ti , t k )
partOf (t i , t j ) → ¬partOf (t j , t i )
……….. C 10
………………………………………….. C 11
isa _ typeof (t i , t j ) → ¬isa _ typeof (t j , t i )
25
C9
………………………………. C 12
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.
isa _ typeof (ti , t j ) ∧ has _ properties (t j , Φ ) → inherits (ti , t j , Φ ) …………. C 13
Axiom 10: A subtype is able to override the properties inherited from its parent.
inherits (ti , t j ,Φ1 ) ∧ overrides (ti , φ1 , φ2 ) → has _ properties (ti , Φ 2 ) ………… 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
26
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.
/
role( r ) ∧ assign ( p, r , ichunk
) → has _ permission ( r , p, i / chunk )
………….. 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.
27
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 defined 4 . Individual and organizational knowledge includes
declarative (know-that) or procedural (know-how). Correspondingly, explicit computational
knowledge
in
MibML
consists
of
both
declarative
knowledge
(d k )
and
procedural
knowledge ( pk ) . 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.
((∃ruled )(∃≥2 f )operates _ on( ruled , F ) → f new ) ∧ new _ fact ( f new ) … 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
( precedes(at1 , at 2 ) , concurrent (at1 , at 2 ) ,
frequency(a, n) and optional (a ) ) 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.
28
an activity is always triggered by an event. The event can be an external event ( evexternal ), a
temporal event ( evtemporal ), or a state event ( ev state ). 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-roletask 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.
((∀a
gi
(
(
)
)
∈ AG )(∃ri ∈ R ) plays (a gi , ri )) ∧ (∀ri ∈ R ) ∃≥1a gi ∈ AG plays (a gi , ri )
29
………. C 19
Axiom 16: A goal of a role is accomplished by an agent playing the role.
accomplish( a g , g ) → (∃r )(∃g )((assigned _ goal ( r , g ) ) ∧ ( plays _ role (a g , r ))) … 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 wellunderstood 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
30
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.
31
6
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
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.
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.
J. L. Austin, How to Do Things with Words. Oxford, UK: Clarendon, 1962.
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.
A. Basu and A. Kumar, "Research commentary: workflow management issues in ebusiness," Information Systems Research, vol. 13, no. 1, pp. 1-14, March 2002.
B. Bauer, J. P. Muller, and J. Odell, "Agent UML: A formalism for specifying
multiagent software systems," presented at the First International Workshop (AOSE2000), Berlin, Germany, 2000.
B. J. Biddle and E. J. Thomas, Role Theory: Concepts and Research: John Wiley &
Son, Inc, 1966.
A. H. Bond and L. Gasser, Readings in Distributed Artificial Intelligence. San Mateo,
CA: Morgan Kaufmann, 1988.
G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Language User
Guide: Addison-Wesley, 1999.
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. 491538, 2000.
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.
S. Conger, The New Software Engineering. California: Wadsworth Publishing
Company, 1994.
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.
J. L. G. Dietz, "DEMO: towards a discipline of organisation engineering," European
Journal of Operational Research, vol. 128, no. 2, pp. 351-363, 2001.
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.
L. Fischer, "The Workflow Handbook 2001," Association with the Workflow
Management Coalition (WfMC), 2000.
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.
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.
J. Habermas, The Theory of Communicative Action, vol. I. Boston: Beacon Press,
1984.
G. Huber, "Organizational learning: the contributing processes and the literatures,"
Organization Science, vol. 2, no. 1, pp. 88-115, 1991.
32
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
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.
N. R. Jennings, "An agent-based approach for building complex software systems,"
Communications of the ACM, vol. 44, no. 4, pp. 35-41, 2001.
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.
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.
R. Kishore, H. Zhang, and R. Ramesh, "Ontologies, frameworks, and systems: a
helix-spindle model for ontological engineering," Communications of the ACM, 2004.
M. Knapik and J. Johnson, Developing Intelligent Agents for Distributed Systems :
Exploring Architecture, Technologies, and Applications. New York: McGraw-Hill,
1998.
A. Kumar, "Dynamic routing and operational controls in workflow management,"
Management Science, vol. 45, no. 2, pp. 253-272, 1999.
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.
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.
M. Lejter and T. Dean, "A framework for the development of multi-agent
architectures," IEEE Expert, vol. 11, no. 6, pp. 47-59, 1996.
D. S. Linthicum, Enterprise Application Integration. Boston, MA: Addison-Wesley,
1999.
T. W. Malone and K. Crowston, "The interdisciplinary study of coordination," ACM
Computing Surveys, vol. 26, no. 1, pp. 87-119, 1994.
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.
M. Marcotty and H. Ledgrad, "The World of programming Languages." Berlin:
Springer-Verlag, 1986, pp. 41-47.
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.
I. Nonaka, "A dynamic theory of organizational knowledge creation," Organization
Science, vol. 5, no. 1, pp. 14-37, February 1994 1994.
H. Nwana, L. Lee, and N. Jennings, "Coordination in software agent systems," BT
Technology Journal, vol. 14, no. 4, pp. 79-88, 1996.
J. Odell, "Objects and agents compared," Journal of Object Technology, vol. 1, no. 1,
pp. 41-53, 2002.
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.
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.
J. L. Peterson, Petri Net Theory and the Modeling of Systems. Englewood Cliffs, NJ:
Prentice-Hall, Inc., 1981.
33
[42]
[43]
[44]
[45]
[46]
[47]
[48]
[49]
[50]
[51]
[52]
[53]
[54]
[55]
[56]
[57]
[58]
[59]
[60]
S. Russell and P.-. Norvig, Artificial Intelligence: A Modern Approach, Second Edition
ed. Upper Saddle River, NJ: Prentice Hall, 2003.
A.-W. Scheer, ARIS-Business Process Modeling. Berlin: Springer, 1999.
J. R. Searle, Speech Acts: An Essay in the Philosophy of Language: Cambridge
University Press, 1969.
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.
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.
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.
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.
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. 2346, 2003.
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.
J. Verschueren, The analysis of speech act verbs: theoretical preliminaries.
Bloomington, Indiana: Indiana University Linguistic Club, 1977.
J. Verschueren, On speech act verbs. Amsterdam: John Benjamins, 1980.
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.
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.
H. Weigand and W.-J. v. d. Heuvel, "Cross-organizational workflow integration using
contracts," Decision Support Systems, vol. 33, pp. 247-265, 2002.
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.
M. Wooldridge, An Introduction to Multiagent Systems. West Sussex, England: John
Wiley & Sons, Ltd, 2002.
M. Wooldridge and N. R. Jennings, "Intelligent agents: theory and practice,"
Knowledge Engineering Review, vol. 10, no. 2, pp. 115-152, 1995.
M. Wooldridge, N. R. Jennings, and D. Kinny, "The Gaia methodology for agentoriented analysis and design," Autonomous Agents and Multi-Agent Systems, vol. 3,
no. 3, pp. 285 - 312, 2000.
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.
34
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.
35
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.
36
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
G1.3 to schedule PC delivery
R2 Assembly planner
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
37
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.
38
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.
39
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
40
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.
41
Table 7: Specification of task “Generate quote”
Task
Identifier
T1.1
Name
Generate quote
Description
Input
Generate the price quote for the pc configuration selected by customer
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
Description
Manage account
Set up an account for new customer and update customer information
Input
INF1 customer information
Output
Method
INF8 customer
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
42
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.
43
Table 11: Specification of the interaction “Order notification”
Interaction
Identifier
Name
I1_2
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
Initiator message
Assertion
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
Initiator speech act
Delivery manager
Assertion
Initiator message
The PC in a specific order is ready to be shipped
Responder speech act
Responder message
Acceptance
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.
44
Table 13: Specification of information entity “Customer”
Information entity
Identifier
INF1
Name
Customer
Description
Attributes
Customer information and his/her credit status
Customer number, Name, address, phone, internal credit ranking
Table 14: Specification of information entity “Order”
Information entity
Identifier
Name
INF2
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
Description
Inventory
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
45
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
Flow sink
R1 Customer service representative
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
46
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
Name
K1
Customer Service Representative Knowledge
Description
Knowledge on pricing, credit ranking, financing, order rejection/approval
policy, and constraints on performing tasks
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).
Declarative Knowledge
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.
47
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.
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).
Declarative Knowledge
Procedural Knowledge
Execution structure
None
Execution constraints
KX3.3 Activity execution constraints
•
T3.1 schedule delivery is triggered by I2_3 assembly completion
notification
48
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
Interactions
G1.1 To manage customers and their orders
I2_3 Order notification
Tasks
T1.1
T1.2
T1.3
T1.4
Information permissions
•
•
•
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
generate quote
manage account
check credit
process order
Full control on INE1 Customer
Full control on INE2 Order
Read INE3 Inventory
Table 22: Specification of role Assembly Planner
Role
Identifier
R2
Name
Assembly planner
Description
Goal
Plan PC assembly
G1.2 To plan PC assembly
• I1_2 Order notification
• I2_3 Assembly completion notification
Interactions
Tasks
T2.1 schedule assembly
T2.2 check inventory
T2.3 order parts
Information permissions
•
•
Full control on INE3 Inventory
Read INE2 Order
49
•
Knowledge
Update INE2 Order – assembly status
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
Description
Delivery manager
Manage inventory and schedule delivery
Goal
G1.3 To manage delivery
Interactions
Tasks
• I2_3 Assembly completion notification
T3.1 schedule delivery
Information permissions
•
•
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
Read INE2 Order
Update INE2 Order – shipment status
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
R2 Assembly planner
A1 Customer service representative agent
A2 Assembly planner agent
R3 Delivery manager
A3 Delivery manager agent
50