mibml: a conceptual modeling grammar for integrative...
TRANSCRIPT
1
MibML: A Conceptual Modeling Grammar for Integrative Business Information Systems Using the Agent Metaphorα
RAJIV KISHOREβφ
Department of Management Science and Systems School of Management
The State University of New York at Buffalo Buffalo, NY 14260-4000
Tel: (716) 645-3507 Fax: (716) 645-6117 [email protected]
RAJ SHARMAN
Department of Management Science and Systems School of Management
The State University of New York at Buffalo Buffalo, NY 14260-4000
Tel: (716) 645-3507 Fax: (716) 645-6117 [email protected]
HONG ZHANG
Computer Information Systems Glass Hall 373
Southwest Missouri State University 901 South National Avenue Springfield, Missouri 65804
Tel: (417)836-4121 Fax: (417)836-6907
Email: [email protected]
R. RAMESH
Department of Management Science and Systems School of Management
The State University of New York at Buffalo Buffalo, NY 14260-4000
Tel: (716) 645-3258 Fax: (716) 645-6117
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.
2
MibML: A Conceptual Modeling Grammar for Integrative Business Information Systems Using the Agent Metaphor
Abstract
In this paper we introduce the concept of multiagent-based integrative business information systems (MIBIS). MIBIS is derived from an integration of two analogous modeling metaphors: Agents and IS Work Systems. Our conceptualization is based on three basic attributes of the two metaphors – autonomous behavior, goal orientation and role-centricity. We develop a theoretically-grounded conceptual modeling grammar termed MibML (Multiagent-based Integrative Business Modeling Language) for modeling the MIBIS universe. The need for the special-purpose grammar for MIBIS is motivated by the inadequacy of existing software engineering and multiagent modeling formalisms such as ER, DFD, PetriNets, AUML, etc. to capture the specific characteristics and semantic requirements of the MIBIS universe. The MibML grammar is presented as a formal model using BNF and first order logic. An illustrative example of the application of MibML grammar is presented as a proof-of-concept and is included as supplemental material to this paper. ACM Taxonomy Keywords: D.2.1.a Analysis; D.2.1.g Specification; D.2.10.b Design notations and documentation; D.2.10.c Representation. Paper Keywords: conceptual modeling grammar, systems modeling, requirements specifications, role-based modeling, multiagent systems modeling, integrative business information systems modeling.
1 INTRODUCTION
The fundamental unit of conceptualization in Multiagent Systems (MAS) is the Agent.
An agent is basically a computational entity with specific goals that operates in coordination
with other such entities in a given environment. Similarly, a fundamental unit of
conceptualization in an Integrative Business Information System (IBIS) is the IS Work
System [2]. An IS work system is essentially an encapsulated Information System (IS)
component with a fully defined interface that performs specific tasks in coordination with
other such systems in an IBIS. Although the two concepts originate from different domains,
their functionality and architectures have much in common. Consequently, using the Agent
metaphor in IBIS design or the IS Work System metaphor in MAS design can be considered
analogous. This equivalence has some significant implications. First, a common conceptual
grammar could support the development of both types of systems. Second, the common
conceptual basis would lead to an integration of the two, leading to the notion of Multiagent-
based IBIS (MIBIS). In this research, we introduce the MIBIS concept and develop a
3
theoretically-grounded conceptual-modeling grammar termed MibML (Multiagent-based
Integrative Business Modeling Language) for modeling the MIBIS universe. MibML is a
demonstration of the equal applicability of the two metaphors in both the design contexts.
The Agent metaphor has been extensively used in various IBIS contexts [2],
including e-commerce, business process management, supply chain management,
enterprise integration, manufacturing, etc. While considerable research exists in the areas
of distributed and cooperative multiagent architectures that implicitly employ the work
system concept in the form of agents [10, 26, 30, 40], to our knowledge there is no effort
towards defining a unified and coherent conceptual semantic and structural modeling
grammar [54] for the MIBIS context. Currently, the situation remains one of craftsmanship
where system developers create multiagent architectures or IBIS solutions either from
scratch or by reusing existing components as required in a given context. The lack of a
unified conceptual modeling approach for MIBIS design has resulted in a proliferation of
several such independently developed architectures; this has led to the well-recognized
problems of interoperability, integration and scalability challenges in system design, to
name a few.
This paper essentially addresses these lacunae in both the literature and practice.
The distinguishing feature of the proposed developmental framework is its unique focus on
conceptual modeling of MIBIS universes. The area of conceptual modeling has grown
enormously over the years from simple representations of concepts and their relationships
to modeling complex and dynamic behaviors of entities and systems. Further, conceptual
models have been used very effectively in the design processes in several software
engineering domains; they have also served as effective means of communication and co-
ordination among development teams, besides providing common bases for the
development of encapsulated component systems. A MIBIS universe typically possesses the
attributes of a complex dynamic environment; the universe can be viewed as a collection of
interactive autonomous agents or analogously as a network of autonomous work systems.
4
These components together perform a set of tasks to accomplish their system goals. A
MIBIS at a minimum can be configured with component goals, their role and task
definitions, coordination and communication mechanisms, system states and data
management, and resource sharing protocols. Consequently, conceptual modeling is
extremely important in MIBIS design.
The proposed modeling language MibML consists of a set of simple fundamental
concepts required in modeling a MIBIS universe, their structural and semantic associations,
and a coherent framework for a systematic development, verification and validation of
MIBIS designs. The grammar includes axiomatic specifications of the concepts, their
relationships and rules of application in the design framework, and is formally described
using BNF and predicate logic. An illustrative example provided in the supplemental set
demonstrates the use of MibML in MIBIS design, including the underlying design principles.
MibML has been developed from an integration of the Agent and Work System metaphors
along with their properties derived from extant multiagent systems and IBIS literatures.
Similar approaches in other domains include the Smart Object Model for complex operations
management [48], the SEAM model for workflow systems [4], the knowledge-based
approach for reusable business information systems [46, 53], and the GBMS/SM model for
structured optimization [11]. The MibML grammar provides a representation vocabulary,
which other existing modeling approaches for the MIBIS universe do not provide.
The paper is organized as follows. In section 2, we develop the basic framework of
the MIBIS universe. In section 3, we justify the need for a formal conceptual-modeling
grammar for the MIBIS universe by showing that existing software engineering and
multiagent modeling formalisms such as ER, DFD, PetriNets, AUML, etc. are inadequate to
capture the specific characteristics and semantic requirements of the MIBIS universe. In
section 4, we discuss and formally define the MibML grammar. Finally, we conclude with
some future research directions in section 5. An illustrative proof-of-concept example of the
application of MibML grammar is included as supplemental material to this paper.
5
2 THE MIBIS FRAMEWORK
The proposed MIBIS framework is derived by adapting the Agent metaphor in
Multiagent Systems (MAS) to an IBIS context. Equivalently, employing the IS work system
metaphor of IBIS in a MAS context would provide another view of MIBIS. Without loss of
generality, we focus on the former view throughout the paper. In the following discussion,
we first introduce the notion of IBIS and then develop a conceptual framework for MIBIS by
adapting the Agent metaphor.
2.1 IBIS: A COMPONENT VIEW
Alter [2] defines a work system as the highest-level conceptual system abstraction
within an organization. An information system is only a particular type of work system that
supports other organizational work systems. Using this definition, we conceptualize a work
system in the current context as “a system comprised of man-machine components
performing a specific business process; the process could entail data, man-machine tasks,
coordination, communication and resource sharing among the man-machine components.”
As a result, we can view a work system as an encapsulated business component with
complete definitions of its internal logic, resources and external interfaces. A business
organization typically contains a number of work systems (such as materials procurement,
sourcing processes etc.) that interface, interact, coordinate and share resources among
each other in order to achieve specific organizational objectives. Business integration
essentially involves the integration of multiple work systems within a business organization.
An Information System (IS), as a particular type of work system, supports other
business process work systems within organizations [2]. We refer to an information system
as an Integrative Business Information System (IBIS) when it comprises of a set of IS work
systems that together support a set of business process work systems. We conceptualize an
IBIS as an integration of several autonomous, goal-oriented and role-centric component
work systems within its own framework. Some of the well known IS solutions that can be
6
generally characterized as traditional IBIS would include ERP systems [29], Enterprise
Application Integration (EAI) frameworks [31], and work flow systems [16], to name a few.
In general, an IBIS environment deals with the integration of cross-functional processes,
integration of IS components (legacy or new) within an organization-wide federated
schema, tight/loose coupling of IS components across organizations, and more
fundamentally, automation of processes wherever possible.
The emerging next-generation IBIS architectures have several distinguishing
attributes compared to their traditional counterparts. In general, the business process
contexts of the emerging IBIS tend to be more functionally specialized within a wide array
of inter-dependent processes. As a result, several IS work systems may need to be
integrated to accomplish the support requirements of a single business process. Coupled
with the interfacing requirements across business processes, an IBIS could entail a network
of IS work systems interacting through their interfaces to support a set of related business
processes. Each IS work system can be viewed as a fully self-contained component with
appropriate interfaces. This encapsulation also implies autonomous behavior and a
capability scope for each component. Hence, system integration is a far greater challenging
task when faced with an array of components where each component could be defined with
a set of goals, role-centric task capabilities and internal/external resources with other
components and a capability of autonomous behavior. Consequently, a primary focus of the
next-generation IBIS will be on coordination of autonomous work systems and their
communication protocols [32]. The emerging IBIS paradigm leads logically to a
conceptualization of IBIS work systems as autonomous agents with coordination
mechanisms among them. Using this idea, we develop the concept of MIBIS in the following
discussion.
2.2 MIBIS: INTEGRATING THE AGENT METAPHOR
IBIS can be conceptualized and possibly even implemented using multiagent system
7
architectures. A multiagent system (MAS) is defined as a loosely coupled network of
problem solving agents; the agents interact with one another to solve problems that are
beyond the individual capabilities of each problem solver [15, 57, p. 3]. Recently
researchers have brought out the similarities between integrative business systems and
“communities” of autonomous problem solving agents [e.g., 23, 24, 39, 45]. The network of
work system components in an IBIS can therefore be modeled as a community of
autonomous agents with both agent-specific and shared objectives. The agent paradigm
provides suitable abstractions that minimize the semantic gap between the conceptual
specification and the corresponding system realization of IBIS work system components
[22]. Furthermore, multiagent systems, for the most part, are concerned with coordinating
intelligent behavior among autonomous agents [8, 15, 21, 37], which is also a central
concern in IBIS.
The Agent metaphor in MAS is analogous to an IS Work System in an IBIS or a
Human Actor in a business process context within IBIS. Clearly, they all have goals, assume
relative roles, perform tasks, possess and employ resources, communicate and coordinate
with each other – in their respective contexts. The MIBIS framework shown in Figure 1
reflects this conceptualization. A number of agents (shown as small yellow circles)
representing human actors or IS work systems are contained within the MIBIS (shown as a
green oval). The MIBIS operates within an external environment (shown as the external red
rectangle), which is similar to the notion of organizational environment and corresponds to
that of multiple agents in the MAS context. The MIBIS is designed with a set of overall
system goals (shown within the blue arrow); the goals are derived from an analysis of user
requirements and incorporated within the conceptual and physical schema of the MIBIS
architecture. The system goals could be specified at different levels of granularity and
ordered into hierarchies. However for the sake of simplicity and without loss of generality,
we assume a simple partitioning scheme where the system goal set is partitioned into a
collection of mutually exclusive and collectively exhaustive subgoals. Each subgoal is
8
associated with an agent, which could be a work system or a human actor as the case may
be. Since each work system is modeled as a fully encapsulated component, autonomous
behavior of work systems is logically implied in this design. Autonomous behavior also
implies a peer-to-peer role relationship, which is assumed throughout the paper for
simplicity in exposition. Extension of the proposed grammar to non-autonomous behaviors
is beyond our current scope and is a significant are for future research. The capabilities of
individual agents can be organized into declarative and procedural knowledge with direct
implications to the associated subgoals. Finally, agents interact with each other and with
other entities within the environment, and the information resources for the agents are
assumed to be distributed within the environment.
The MIBIS framework presents two fundamentally dual views: a view of an IBIS as a
MAS, and a view of a MAS as an IBIS. We term the two views as “Agent view of IBIS” and
“Work system view of MAS”, respectively. The equivalence between the agent and work
system metaphors yields a common framework for designing either a MAS or an IBIS.
Consequently, the conceptual grammar developed for the MIBIS framework is equally
applicable in the two views. In summary, based on the above conceptualization, we adopt
the following conventions in specifying a MIBIS using the Agent metaphor: 1) the MIBIS
system as a whole has an agreed and shared business goal; 2) the MIBIS system is
composed of a collection of agents, each with their individual goals; 3) there is no global
control over the agents within a MIBIS entity; 4) interactions serve as coordination
mechanisms among agents and between agents within a MIBIS system and the
environment; and 5) agents within a MIBIS system react to stimuli and changes from other
agents and the environmental and adapt their behaviors as needed.
9
3 NEED FOR A CONCEPTUAL-MODELING GRAMMAR FOR THE MIBIS UNIVERSE
A conceptual-modeling grammar provides a set of constructs and semantic rules for
modeling real-world domains [54]. Conceptual-modeling grammars are classified into
general-purpose and special-purpose grammars [25]. A general-purpose grammar is
applicable generally in any domain but lacks domain-specific semantics, whereas a special-
purpose grammar provides a representation vocabulary and appropriate domain semantics
for the specific domain [42, p. 322]. For example, UML and ER modeling grammars are in
the general-purpose category; the Smart Object Model [48] and the SEAM Model [4] are
cases of special-purpose modeling grammars.
Currently, there is a lack of a special-purpose modeling grammar for the MIBIS
universe. Traditionally, general-purpose modeling grammars such as data-oriented
techniques (e.g. ER-Diagrams), process models (e.g. Petri-nets), and more recently UML,
MIBIS Environment
MIBIS(Multiagent-based Integrative Business Information System)
Entity
Software Agent
Interaction betweenagents
Information Flow to/from an agent with anenvironmental entity / information resource
Information resource
Non-MIBIS EntityMIBIS EntityUser
SystemGoals
Legend:
Figure 1: The MIBIS Universe and its Architecture
10
have been used to represent business information systems. While these general-purpose
grammars provide a rich vocabulary and strong syntax for aiding the analysis and design of
systems, they lack domain-specific semantics, creating the need for special-purpose
modeling grammars for various domains. For instance, it has been shown that most
enterprise and workflow models lack the essential semantics to concisely represent specific
business processes, goals, tasks and organization structures of particular business
domains[43, 55]. This is quite true for the MIBIS universe as well, because domain-specific
semantics derived from the Agent metaphor such as autonomy, reactivity, distributed
control, interactions, etc., are not supported adequately by general-purpose modeling
grammars. For example, behavioral modeling is crucial to the Agent metaphor and the ER
grammar provides very limited support for this; while data flow diagrams (DFD) provide
partial semantics for modeling the problem-solving processes of agents, they overlook the
modeling requirements of agent intelligence. Similarly, Petri nets are primarily oriented
towards analysis of timing and conflict resolution, rather than towards agent interactions
and coordination. Object-oriented methodologies may be useful in defining MIBIS
specifications by identifying objects that correspond to actors and the dependencies
between these objects. However, as has been discussed in the literature [e.g., 18, 38, 57],
object orientation provides no explicit support for agent concepts such as autonomy,
reactivity, and sociability, and therefore, it is difficult to model agent knowledge and
interactions within MIBIS using OO modeling formalisms. Without a well-defined special-
purpose conceptual-modeling grammar, common terms used in the MIBIS universe such as
role, resource, knowledge, interactions, etc. will have to be force-fitted with constructs
available in general-purpose modeling grammars, and this will result in arbitrariness and
confusion while modeling MIBIS systems.
Based on the characteristics of the MIBIS universe discussed earlier, a conceptual
grammar for MIBIS modeling should provide adequate and distinct representation of
informational, functional, knowledge, and organizational characteristics of the Agent
11
metaphor and its implementation as a work system within an IBIS environment. The
informational requirement focuses on the information entities involved in the system, their
structures and interrelationships. The functional requirement focuses on the tasks that are
to be performed and the information entities involved. The knowledge requirement deals
with representing knowledge as a unique component associated with agents constituting a
MIBIS. This representation should have a problem solving focus and be defined in
conjunction with the other requirements. The organizational requirement focuses on
structuring all the MIBIS components and linking their goals with functions, coordination
mechanisms and communication protocols. The existing general-purpose and multiagent
systems modeling grammars and the IBIS modeling approaches do not possess adequate
expressive semantics to adequately represent all these requirements. This is summarized in
the analysis provided in Table 1. In this table, H indicates that the feature being discussed is
fully supported, M indicates that the feature is partially supported, and L indicates that the
feature is not supported by the modeling grammar being discussed. In the next section we
turn our attention to the MibML grammar with a specific focus on the MIBIS modeling
requirements discussed above.
12
Table 1. A Summary of Various Modeling Grammars and their Support for the MIBIS Universe
IS Grammar Supported Feature
General-purpose IS grammar MAS methodology IBIS modeling grammar
ERD DFD Petri-Net [41]
UML [9]
Gaia [59]
MaSE [13]
AUML [6]
TOVE [17]
SEAM [4]
SF1 [46]
DND [47]
AWS2 [35]
XRL [49]
Agent modeling L L L L H H H H L L L L L
Organizational modeling
Goal-oriented L L L L L H L H L H L L L
Role modeling M L L M H H M H L L H M L
Data modeling
Data entity H L L H L L L L H H L L L
Date flow L H H H H H H L L H H H H
Knowledge modeling
Declarative L L L L L L L H H L L L L
Procedural L L L L H H H H M L L L H
Coordination mechanism3
Communication L H H H H H H H L H H H H
Conversation L L L L H H H H L L L H L
Task modeling L M H H H H H H M L L L H
Legend: H – High; M – Medium; L – Low.
1 Knowledge reuse framework of Sugumaran et al. 2 Action Workflow System 3 Coordination occurs at the communication and conversation levels. Communication supports message-content passing. Conversation
supports speech acts to specify actor’s intentions.
13
4 THE MIBML GRAMMAR
The MibML grammar extracts core concepts from both IBIS and MAS literatures and
presents a framework for the conceptual specification of MIBIS architecture. Using the
Agent metaphor, MibML defines seven key concepts that are central to MIBIS: Goal, Role,
Interaction, Task, Information, Knowledge, and Agent. Each agent (or equivalently an IS
work system) in MIBIS can be specified using this grammar, and a collection of
specifications for a set of agents in an environment with their interrelationships would
together describe a MIBIS architecture. The grammar is descriptive as well as prescriptive;
it is descriptive in defining an architecture using orthogonal conceptual elements of MIBIS;
it is prescriptive in providing a set of modeling tools and an approach to the analysis and
design of a MIBIS. The MibML specifications describe a system at two levels: MIBIS
environment and MIBIS internals. We first develop a framework for MibML and subsequently
present a formal specification of the grammar in the following discussion.
4.1 THE MIBML FRAMEWORK
At the environmental level, a MIBIS is regarded as an integrated system, interacting
with other entities in the surrounding business environment as shown in Figure 1. A
description of the MIBIS environment provides a set of requirements for configuring its
internals in terms of agents. This description follows well-known systems analysis principles
and would broadly include specifications of the environment in terms of (a) functional
requirements, (b) data requirements, (c) interface requirements, and (d) coordination
requirements on a MIBIS with respect to the environment in which it operates. Traditional
conceptual modeling techniques such as ER, UML Use Case etc. could be used for this
purpose. These requirements will be translated into component agent level specifications in
describing the internals of a MIBIS. Since MIBIS is conceptualized as a set of autonomous,
goal-oriented and role-centric agents, the environmental specifications would naturally
translate into component agent architectures comprising of these attributes along with their
14
internal and external coordination mechanisms and communication protocols. In a
description of the environment, we differentiate between user and other objects that exist
outside the perimeter of a MIBIS. A reason for this is that the user objects not only transact
input/output with a MIBIS, but also specify business goals for the system. We choose goal
as a construct to capture requirements of user objects because goal-based system
development is more stable than those based on functions, processes or information
structures that often change with time [13, 60].
The internal level specifications describe the components of a MIBIS. A MIBIS in this
paper is regarded as an organization of software agents, which play different roles in the
system. Similar to a human organization, role is a key concept in MIBIS analysis. The role
construct in the grammar is essentially an abstraction for: (a) the tasks that are performed
by a component agent, (b) the interactions that need to occur with other roles to achieve
individual agent goals, (c) the information that needs to be accessed or will be generated
during the course of performance of those tasks/interactions, and (d) the knowledge that is
needed for the achievement of the agent’s goals. Just as in an organizational context where
an abstract role is assigned to one or more physical human agents (e.g., the abstract role of
Role
[1, 1]
[2, 2]
[1, 1]
[1, m]
[1, m]
[1, 1]
Performs / Is_performed_by
Is_required_for / Requires
Information
Is_involved_in /Includes
Has_privileges_to_access /Is_accessed_by
Plays /Is_played_by
Possesses / Is_possessed_by
Includes_procedural_knowledge_about /Is_constrained_by[1, 1]
[1, m]
[1, m]
Is_constrained_by /Includes_procedural_knowledge_about
[1, m]
[1, m]Agent
Goal[1, 1]
Interaction[1, m] [1, m]
Task
[1, m] [1, m]
[1, m]
[1, m]
[1, m]
Knowledge
Is_assigned_to /Is_assigned
Figure 2: The MibML Constructs and their Inter-relationships
15
an “inventory manager” may be assigned to a physical human agent named “John Q.
Batman”), an abstract role in the MIBIS universe is assigned to and implemented by
physical component agents. Therefore, a role in MibML provides a template that can be
instantiated by agents. Figure 2 presents a conceptual meta-model of the MibML constructs
and shows the relationships among the Goal, Role, Interaction, Task, Information,
Knowledge, and Agent constructs that are formally discussed and developed in the following
section.
4.2 FORMAL SPECIFICATION OF MIBML
In this section, we define the MibML constructs as a set of schemas using BNF syntax
[34]. The relationships, axioms, and constraints which govern the usage of the MibML
constructs are defined in first order predicate logic. Table 2 presents the conventions
adopted for the notations and symbols used in specifying the MibML grammar. These
conventions apply to all the symbols used to explicate the various ontological categories
that arise during the specification, namely: instance, collections, types, and collection of
types. Table 3 provides an explanation of the symbols used in specifying the MibML
grammar. Table 4 unambiguously defines the key MibML constructs in BNF and Table 5
provides a list of predicates that are used in specifying the MibML grammar. In the rest of
this section, we provide a more detailed explanation of the fundamental MibML constructs
along with their constraints and relationships based on theories in both the IBIS and MAS
literatures. During our discussion, we have attempted to avoid trivial axioms and constraints
that can be easily reasoned.
Table 2: Convention of Notations used in MibML Specifications
Individual Collection Type Bolded Lower Case letter(s) Bolded Upper Case letter/(s) Instances Lower Case letter(s) Upper Case letter/(s)
16
Table 3: Symbols used in MibML Specifications
Notation Description Notation Description General
Ψ Collection of MibML constructs
nii ,...,1: ==Ψ ψ
ψ MibML Construct
∆ Collection of relationships
δ Relationships
Τ Collection of constraints τ constraints
attributesC Common Attributes
ta Activity (a task or an interaction)
Goal g Goal
G Collection of goals;
,..,1: nigG i ==
status Goal Status c Completed
xe Executing
w Waiting s Suspended Role
generalr Generic roles
r Normal roles
rcoordinator Special role to maintain
goal status
d Duties of a role p Privilege
Interaction i Interactions msg Communication from initiator role
to responder role resp Response to a message
speech Communicative act
Actspeech Action verb for
communication Example: Assertion, Query, etc. content Actual message Task t Tasks
φ Property / Logic / Subcomponent.
Knowledge
k Knowledge
dk Declarative knowledge
pk Procedural knowledge
pw Workflow patterns
f Facts
drule Deduction rule
structurex Execution structure
orderx Execution order
intconstrax Execution constraint
ev Event
externalev External event
temporalev Temporal event
stateev State event
Information
/i Information
fi / Information flow
ei / Information entity
e Information entity instance e Information entity type
infoe Internal entity information
ocontrolflowi inf/
−− Metadata for information flow
c control
sourceflowi −/
Source from which an
information flow emanates
sinkflowi −/
Entity receiving the
information flows
datai / Actual data with flow
externalflowi −'
External source/sink for
information flow
frequencyflowi −/
Information flow frequency
Agent
ga Agent
17
Table 4: The MibML Conceptual Modeling Grammar in BNF
MibML Grammar ( ) Τ∆Ψ=Ω ,,
where
nii ..1=∀=Ψ ψ in which iψ is a MibML construct,
nii ..1=∀=∆ δ in which iδ is a relationship between concepts, and
nii ..1=∀=Τ τ in which iτ is a constraint.
]||||||[:: / AKITIRG=ψ
ndescriptionameidCattributes ,,::=
Goal:
>><=<>< statusCg attributes::
...]||||[:: swecstatus x=><
>< →>< rg mappingBijective
Role:
[ ]><><=>< rcoordinatoGeneral rrr |::
>><><=<>< dkCr attributes::
>><<>=<>< adad |::
]|[:: ><><=>< ita
>><=<>< specialattributesrcoordinato dCr ::
:: statusgoalUpdated special =><
Interaction:
>><=<>< SpeechCi attributes::
][|:: ><><>=<>< RespSpeechMsgSpeech
/* Comments : The symbol >< Message is used to express both >< Msg and >< spRe as they have the
same format. >=<><>< MessagespMsg ::Re|[ */
>><><><=<>< contentspeechresponderinitiatorMessage Act::
><→><>< − rresponderinitiator ais]|[
...]||||Re||[:: DenialCommitmentPerformquestQueryAssertionspeechAct =><
ninteractio during edcommunicat messagecontent ::=><
Task:
][|:: ><><>=<>< aAaA
]|[ ><><>→< ita
>><><><=<>< methodoutputinputCt attributes::
/* Comments: The symbol >< oi / is used to express both >< input and >< output as they have the same
18
format >=<><>< oioutputinput /::]|[ */
]|[/|]|[::/ // ><><><><><=>< fdfd ikoiikoi
>Φ=<>< ::Method
>><Φ<>=<>Φ< φφ |::
...|||...||:: 2121 propertypropertyMethodMethod=><φ
Information:
]|[ //_/ ><>< →>< eeais iii
>><><=<>< eeCi oAttributese inf/ ::
:: entity the about ninformatio structraland syntacticSemantic,einfo =><
instanceentity an withassociated datae ::=><
>><><><=<>< dataodataflowol_infoflow_contrAttributesf iiiCi /inf__
/// ::
>><><><=<>< −−−− timeresponseflowfrequencyflowsinkflowsourceflowol_infoflow_contr iiiii _///// ::
]||[|]||[:: ////// ><><><><><><><=>< −−−− externalflowesourceflowexternalflowesourceflow iiriiiri
]||[|]||[:: ////// ><><><><><><><=>< −−−− externalflowesinkflowexternalflowesinkflow iiriiiri
entity] MIBIS-Non|entity MIBIS| UserEnd[::/ =>< −externalflowi
|[|...]| |[:: // ormationformat_InftureData_Struciormationformat_InftureData_Struci infoflow_data_infoflow_data_ ><=><
atainstance_di data =>< ::/
||_||::/ eibute_valutance_attrEntity_insattributeEntitytanceEntity_insEntityi chunk =><|intPr||||[Re|...]|intPr||||[Re:: GrantViewWriteadPGrantViewWriteadP ><=><
Knowledge:
]|[|]|[:: ><><><><><=>< pdpd kkkkkk
]|[|]|[:: ><><><><><>=<>< dddAttributesd RULEFkRULEFCk
>><<>=<>< fFfF |::
...]|3|2|1[:: AssertionAssertionAssertionf =><
>><<>=<>< dddd ruleRULEruleRULE |::
...]|2__|1__[:: RuleDedcutionruleDedectionruled =><
>><<>><=<>< pppAttributesp wkwCk |::
]|[:: ><><=>< sconstraintstructurep xxw
...]|_|_|[:: choiceexclusivesplitparallelsequencexstrucuture =><
...]||||[:: resourcestatetemporalexternalconstraint evevevevx =><
Agent:
>< →>< ar mappingBijective
19
Table 5: List of Predicates Used to Specify the MibML Grammar.
PREDICATE MEANING
),( /chunkiraccesses Role r accesses the information chunki /
),( rgaccomplish Goal g is accomplished by role r
)( gaagent ga is an agent
),,( /chunkirpassign Privilege p is assigned to role r for chunki /
),( grassigned Role r is assigned to goal g
),,(_ statusgrstatgoalchange rcoordinato− Role rcoordinator changes the state of goal g to
status
( )21, tt aaconcurrent Activity at1 is in parallel with activity at2
execute(r, at) Role r performs activity at
),( nafrequency t Activity ta must be performed with frequency n
)(ggoal g is a goal
),(_ gagoalhas g Agent ga has a goal g
),(_ riinitiatorhas Role r is the initiator of an interaction
),,(_ /chunkiprpermissionhas Role r has permission p to access chunki /
),(_ Φitpropertieshas Task it has a collection of Properties / Methods Φ
),(_ riresponderhas Role r is the responder of the interaction
),(_ statusgstatehas Goal g has state status
)( /ininformatio /i is either an information entity or flow
),,( Φji ttinherits Task it inherits from task jt collection of Properties
/Methods Φ
)(ininteractio i is an interaction
),(_ ji tttypeofisa Task it is of type jt
)(kknowledge k is a knowledge nugget
)(_ ffactnew f is a new fact
),(_ Fruleonoperate d Deduction rule has to operate on facts
)( taoptional Activity ta is optional
),,( 21 φφitoverrides Task it overrides property 1φ with property 2φ
),( ji ttpartOf Task it is a sub-task of part of task jt
),( raplays g Agent ga plays role r
( )21 , tt aaprecedes Activity at1 is executed before activity at2
),,( /chunkirprevoke Privilege p is assigned to role r for chunki /
)(rrole r is a role
),( ji rresubordinat Role ir is subordinate to role jr
)(ttask t is a task
trigger(ev, at) Activity at is triggered by event ev
20
4.2.1 Goal
In systems development, goal has been identified as an essential concept for
capturing user requirements. It is capable of aiding in the elicitation and elaboration of
requirements, relating system requirements to organizational and business contexts,
clarifying requirements, and dealing with conflicts [60]. Accordingly, systems developed
based on goals are more stable than those based on functions, processes or information
structures that often change with time [13].
As discussed earlier, the goal construct in MibML provides a bridge between the
environmental-level and the internal-level specifications of a MIBIS. The overall goals of a
MIBIS identified at the environmental level are organized into a goal tree to represent user
requirements at different levels of details. In the goal tree, a goal is decomposed iteratively
until it reaches a collection of individual goals ( )ig at the leaf goal level. For ease of
discussion, we refer to the collection of all individual goals ( )ig as a goal-set ( )G . It is
important to note that a goal is decomposed only to the point where the level of granularity
corresponds to a role (details are discussed in the role section).
The individual goals ( )ig are mutually exclusive and collectively exhaustive of the
MIBIS system goals. As a result, the goal-set ( )G forms a whole-part relationship in which
an individual goal ( )ig is a component of the goal-set ( )G . The implication is that all the
individual goals ( )ig have to be accomplished in order to satisfy the overall goals of the
system. This constraint is expressed in Axiom 1.
Axiom 1: System goals are accomplished if and only if all individual goals are accomplished.
( )),(_...),(_)(),(_ 11 cgstatehascgstatehasgcgstatehas ∧∨>− ………….. C 1
In order to ensure the enforcement of Axiom 1 in the process of system
development, we include an attribute called status in the goal schema (as shown in Table 4)
in addition to the common attributes that are common to all MibML constructs. The attribute
21
is used to maintain the state of a goal. An individual goal can be in one of the following
states: completed (c), executing (e), waiting (w), or suspended (s). Although the attribute
status is a design consideration, we include it in the goal schema to facilitate the transition
from conceptual models to design models in system development.
4.2.2 Role
Role is a powerful concept that introduces the organizational view into intelligent
information systems. Traditionally, role has been used to decouple business process
definitions from concrete resources such as physical individual actors [5, 27, 28, 50]. In
system development, role provides “a new abstraction that can unify diverse aspects of a
system” [59]. Usage of the role construct for MIBIS modeling will provide the advantages of
design focus, reusability, and flexibility.
A role has been classically defined as “a collection of duties and rights” [7]. In the
MibML grammar, duties of a role are modeled as tasks and interactions that roles are
obligated to perform for achieving a goal. Rights of a role are modeled as permissions to
utilize information entities. Knowledge within a role provides the intelligence to coherently
perform tasks and interactions to achieve an assigned goal. Tasks are activities that can be
performed by a role alone. On the other hand, interactions are activities that involve at least
two roles. Permissions about global access to information entities (i.e., information entities
contained within the MIBIS) define the rights a role possesses to access and manipulate
them (e.g., create, read, update, and delete information entities). Roles contain declarative
and procedural knowledge components. The functions of roles are directly linked to the
underlying goals associated with them. In essence, the role construct is an abstraction that
provides complete contextual relationship of an agent with all other entities within a MIBIS.
These relationships are shown in Figure 2 and the BNF formalism is presented in Table 4.
In the MibML grammar, roles are responsible for accomplishing system goals. The
relationship between the goal and role concepts is bijective, and is explained as follows.
22
MibML employs a one-to-one mapping between goal and role. This implies that an individual
goal can be assigned to only one role, and a role is responsible for only one leaf goal of the
larger system goal tree. This is done to provide a rigorous and conceptually simple
distinction between goals and tasks, i.e., the distinction between “what” and “how.” This
distinction, while conceptually intuitive, is often difficult to implement in practice, because it
is hard to draw the boundary between “what” needs to be accomplished versus “how” it will
be accomplished. For example, consider the statement “check credit”. It is difficult to
exactly specify whether this statement is a goal (what) or a task (how), and further,
whether its decomposition will lead to further sub-goals or tasks. The proposed bijective
relationship solves this classical systems analysis problem. MibML requires that a goal
should not be further decomposed when it is assigned to a role. Consequently, such a goal
is a leaf in the goal tree. The bijective mapping also implies that the number of leaf goals
and the number of roles in the system are the same; if there is a difference, then either the
goal tree needs to be folded back (due to over decomposition) or more roles need to be
created (due to role inadequacy). In many design situations, this requirement can easily be
incorporated using any feasible combination of the two strategies. The bijective relationship
between individual goals ( )ig and individual roles ( )ir are expressed in Axiom 2.
Axiom 2: Each individual goal is assigned to a unique role, and each role is responsible for a unique individual goal. ( )( ) ( )( ) ( )( ) ( )( )iiiiiiii grassignedGgRrgrassignedRrGg ,, ∈∃∈∀∧∈∃∈∀ ……………. C 2
( ) ∧≠∧¬→∈∀ )()),(),()(( jiji rrgrassignedgrassignedGg
( ) ( ) ( )( ) ( )( )2121 ,, ggrgassignedrgassignedRr ≠∧¬→∈∀ ……….. C 3
In order to perform tasks, roles need existing information as inputs. In addition,
roles generate new information, which need to be stored in the system. Therefore, roles in
MibML possess one or more privileges that allow them to access and use information entities
and information flows. The granularity at which permissions are granted is determined by
business rules enforced in the system. MibML defines privileges at different levels of
23
granularity ( /chunki ), as described in Axiom 3.
Axiom 3: Each role possesses permissions to access certain information. ),(),,(_)()( ///
chunkchunkchunk iraccessesiprpermissionhasininformatiorrole →∧∧ ….. C 4
Roles within MibML do not have any hierarchical relationships. Existence of a role
hierarchy would imply Mater-Slave relationships. In the current conceptualization, a MIBIS
system is viewed as a composition of distributed autonomous agents without any central
control. Incorporation of role hierarchies in MibML is beyond our current scope and is a
significant area for future research. Therefore, all agents within the system are
conceptualized to be in peer-to-peer relationships. Consequently, supervisory roles do not
exist as reflected in Axiom 4.
Axiom 4: No role can control other roles in a MIBIS system. ),())(),(( jijiji rresubordinatrrRrr ¬→≠∧∈∀ ………………….. C 5
Finally, in order to ensure the accomplishment of the overall systems goals in a peer-
to-peer environment, MibML provides one special role termed coordinator to track goal
accomplishment status of other roles. The task of the coordinator role ( )rcoordinator is to
update the status of all the goals in the system and ensure that every goal in the overall
system goal tree is accomplished. Therefore, we have the following axiom:
Axiom 5: There exists a coordinator role that possesses the necessary permission to change the status of goals in the MIBIS system. ),,(_ statusgrstatgoalchange rcoordinato− ……………………………… C 6
where swecstatus ,,,= is as defined in Table 3.
4.2.3 Interaction
Interaction is the mechanism by which interdependencies among roles are
coordinated. These interdependencies arise due to functional dependencies among the tasks
performed by different roles, simultaneity constraints, task/subtask relationships, and
24
shared resources [32]. MibML employs speech act theory to model the communication and
coordination requirements in role interactions. An interaction is defined as a coordinated
sequence of speech acts or communicative acts aimed at defining and reaching a goal [14,
56]. Speech Acts (SA) are utterances that contain information needed to assert and perform
actions and serve as building blocks of communication protocols. They define what people
do while communicating [3, 19, 44]. Speech act verbs are used in speech act utterances, to
perform actions such as booking, complaining, forgiving, etc. [51, 52].
An interaction includes the following four attributes: initiator, responder, speech act,
and message as defined in Table 4. Because isolated roles do not exist in a MIBIS system,
all roles interact with other roles, as indicated in Axiom 6.
Axiom 6: Each role involves in at least one interaction. (∀ r)(∃ ≥1i)(has_initiator(i, r) ∨ has_responder(i, r)) …………………….. C 7
Obviously, every interaction must involve at least two distinct roles. This is captured
in Axiom 7. The role that initiates the interaction is called the initiator and the role receiving
the communication is called the responder. The initiator starts an interaction by sending a
message using a speech act. However, the message may or may not evoke a response.
Likewise, the response from the responder may or may not evoke a new message from the
initiator. The procedural knowledge of roles dictates issues relating to precedence, timing,
frequency, etc. of interactions. A more detailed conceptualization on this subject is included
as part of the knowledge construct discussed subsequently.
Axiom 7: Every interaction involves an initiator role and a responder role. ))(),(_),(_)(()()(( 11
jiiiji rrriresponderhasriinitiatorhasrri ≠∧→∃∃∀ == ………… C 8
4.2.4 Task
A task is also an activity performed to achieve a goal, but is different from an
interaction in that it can be performed by a single role alone. It can be as simple as a single
activity or as complex as a business process workflow. MibML specifies tasks along two
25
dimensions: task structure and task behavior. The structural specification defines the
composition of task units using a hierarchical structure. A task may be decomposed into
sub-tasks, and a recursive decomposition would lead to a task hierarchy. The task behaviors
specify how the tasks in a hierarchy should be performed (sequence of the tasks, task
interdependencies, the number of times a task is required, optional versus required tasks,
etc). The task behaviors are specified in the activity execution structure and constraints of
the knowledge construct.
MibML supports tasks to be decomposed recursively not only into its constituent
subtasks, but also into different subtypes. For example, a parent task “increase sales” can
be decomposed into the constituent subtask “reduce price”, “change display layout”, etc; it
can also be decomposed into subtypes “increase toy sales”, “increase furniture sales”, etc.
While the former is a decomposition of a task into AND/OR subtask components, the latter
represents an IS-A hierarchy. MibML supports both types task structures. Similar
conceptualization is also employed in Malone et al. [33].
In order to support the task structures, MibML provides two predicates: (a)
),( ji ttpartOf - task it is considered a subpart of task jt ; and (b) ),(_ ji tttypeofisa - task it
is considered to be of type task jt . Axiom 8 describes the transitive closure (C 9 and C 10)
and non-reflexivity properties (C11 and C12) of task decomposition. These properties are
important because they ensure task structure to be represented as a Directed Acyclic Graph
(DAG).
Axiom 8: A task and its sub-level tasks are transitive and non-reflexive. ),(),(),( kikjji ttpartOfttpartOfttpartOf →∧ …………………… C 9
),(_),(_),(_ kikjji tttypeofisatttypeofisatttypeofisa →∧ ……….. C 10
),(),( ijji ttpartOfttpartOf ¬→ ………………………………………….. C 11
),(_),(_ ijji tttypeofisatttypeofisa ¬→ ………………………………. C 12
26
Partitioning along the dimension of subtypes (isa_typeof relationships) allows for
inheritance from a more generalized type to a more specialized type, in a manner that is
similar to the type hierarchy considered in most object-oriented approaches. In order for a
subtype to inherit a property Φ , the generalized task must have the property and the
generalized type must have an ancestral relationship with the subtype as described in
Axiom 9. Similar to the object-oriented approach, MibML allows for subtypes to override
inherited properties as described in Axiom 10.
Axiom 9: A subtype is able to inherit the properties from its parent. ),,(),(_),(_ Φ→Φ∧ jijji ttinheritstpropertieshastttypeofisa …………. C 13
Axiom 10: A subtype is able to override the properties inherited from its parent. ),(_),,(),,( 2211 Φ→∧Φ iiji tpropertieshastoverridesttinherits φφ ………… C 14
The task construct has been conceptualized to include three attributes: Input, Output
and Method as defined in Table 4. Typically, the Inputs include declarative knowledge and
other data flows; Outputs are task generated and could be classified under either
information or declarative knowledge; the Method metaphor embodies the procedural
knowledge used. While the Inputs are needed for task execution, outputs could result in
updates or may even cause information flows within the MIBIS application or to external
users. A method specifies the detailed logic for execution of the task. A method can be
described using different mechanisms, including structured English and pseudo code.
4.2.5 Information
Information refers to data resources available within a MIBIS application and may
pertain to both the functional (business-aware) and the non-functional (business-unaware;
IT system-specific) aspects of the MIBIS application. The information construct of MibML
consists of information entities and information flows. Information entities refer to internal
data within the system that are part of data stores. They represent regular business objects
(such as PRODUCT, CUSTOMER, etc.) and other materialized views of data. The schema of
27
information entities includes the structure of tables, the relationships, entity integrity
constraints, referential integrity constraints, cardinality constraints, etc. Information entities
may be implemented using relational databases and the schema corresponds to items
typically stored in database repositories. Information flows represent data that are in
transit; for example, data moving between external users and roles, between information
entities and roles, or between other external systems and roles. Information flows are
different from information entities in their time orientation [12]. Information flows are
temporal. They cease to exist once they are acted upon by an agent or stored in a data
store or provided to an entity external to the MIBIS system. The specifications of both
information entities and information flows are detailed in Table 4.
All data resources and information available within the MIBIS application are
protected and access is based on privileges roles possess. Privileges reflect authority of
roles to view, manipulate, create, or take other alternative actions on information. Privilege
to access information entities and flows are granted at various levels of granularity as
determined by business rules. A role has to be granted the privilege at the intended level of
granularity if it has to be able to access information. Therefore, we have the following
axiom.
Axiom 11: A role is granted privilege to access necessary information. ),,(_),,()( //
chunkchunk iprpermissionhasirpassignrrole →∧ ………….. C 15
4.2.6 Knowledge
Knowledge is modeled as justified true belief that increases an entity’s capacity for
effective action [20, 36]. It resides in the user and not in the collection of information. It is
information possessed in the mind of individuals [1]. Similarly, knowledge in MibML is
conceptualized to exist within individual roles and is therefore private to the roles.
Accordingly, a role must posses the needed knowledge in order to use it. This constraint is
represented in Axiom 12.
28
Axiom 12: A role can only use its own knowledge. ∀ k(uses_knowledge(r, k) ∃ r(role(r) ∧ knowledge(k) ∧ has_knowledge(r, k)) ………………….. C 16
Individual and organizational knowledge are very broad constructs consisting of both
explicit and tacit knowledge [1]. However, the knowledge construct in MibML is viewed from
a somewhat narrower perspective, in that it captures and represents only computational
knowledge that is explicitly defined4 . Individual and organizational knowledge includes
declarative (know-that) or procedural (know-how). Correspondingly, explicit computational
knowledge in MibML consists of both declarative knowledge ( )kd and procedural
knowledge ( )kp . Declarative knowledge is defined as a collection of facts and deduction
rules. Facts are beliefs that a role keeps about itself, about other roles in the system, and
about the environment it resides in. Deduction rules empower roles to engage in deductive
reasoning with the constraint that at least two existing facts are needed to deduce a new
fact. This is further elaborated in Axiom 13.
Axiom 13: A new fact can only be deducted from at least two existing facts. )(_)),(_))((( 2
newnewdd ffactnewfFruleonoperatesfrule ∧→∃∃ ≥ … C 17
Procedural knowledge is conceptualized to consist of activity execution structure and
activity execution constraints. Activity execution structure relates to knowing the order in
which activities need to occur. An activity is defined here either as a task or as an
interaction. Activity execution structure also includes information regarding how frequently
activities have to be performed and whether certain activities are optional. The predicates
( ( )21 , tt aaprecedes , ( )21, tt aaconcurrent , ),( nafrequency and )(aoptional ) are used to
express activity execution structure, as shown in Table 5.
Activity execution constraints determine the events that trigger activities. In MibML,
4 If tacit knowledge can be converted into explicit knowledge, it can be represented using the
knowledge component of the MibML grammar.
29
an activity is always triggered by an event. The event can be an external event ( externalev ), a
temporal event ( temporalev ), or a state event ( stateev ). External events emanate either from
the environment including other roles or from end-users (such as a customer placing an
order). External events generated by another role in the system correspond to inter-role-
task dependencies. For example, a role r1 may start executing a task t1 only when another
role r2 completes a task t2. In order to preserve the autonomy of roles and hence the agents
playing the roles, MibML does not permit modeling such constraints as part of the task
execution structure of the role r1. However, such constraints can be modeled as an external
event for role r1. Temporal events are constraints placed on the execution of tasks or
interactions based on some time consideration such as the elapse of some time period. A
state event is an event that occurs inside a role, and changes the state of the role, and
accordingly triggers a task or a set of tasks. The requirements of activity execution
constraints are expressed in Axiom 14.
Axiom 14: Activities in the MIBIS universe must be triggered by an event. (∀ at)(execute(r, at) ∃ ev(trigger(ev, at)) ………………………. C 18
4.2.7 Agent
In an organizational context, a role is assigned to one or more physical human actors
to accomplish organizational goals. In a similar manner, an abstract role in the MIBIS
universe is instantiated by autonomous component agents as shown in Figure 2. The
component agent is modeled as a system entity that is capable of sensing its environment
and acting autonomously to meet its design objectives [58]. Axioms 15 and 16 describe the
conceptualization of the relationship between a role and an agent.
Axiom 15: Every agent in MIBIS must play a role and every role must be played by at least one agent. ( )( ) ( )( ) ( )( ) ( )( )igiGgiiigiiGgi raplaysAaRrraplaysRrAa ,, 1 ∈∃∈∀∧∈∃∈∀ ≥ ………. C 19
30
Axiom 16: A goal of a role is accomplished by an agent playing the role. ( )( ) ( ) ( )( )( )raroleplaysgrgoalassignedgrgaaccomplish gg ,_),(_),( ∧∃∃→ … C 20
5 CONCLUSION
The concept of Agent is a powerful modeling metaphor for the conceptual
specification of Integrative Business Information Systems. While a typical IBIS can be
conceptualized using the notion of an IS work system, the lack of a global agreement on
what constitutes such a metaphor has led to a proliferation of IBIS architectures and the
ensuing problems of interoperability, integration and scalability, to name a few. On the
other hand, the notion of autonomous agent is well understood in both the MAS literature
and practice. Drawing upon the analogy between the two metaphors, we exploit the well-
understood architectures and behaviors of agents and use it as a metaphor in modeling
IBIS. Using the Agent concept as a fundamental building block of IBIS architectures, we
develop the concept of MIBIS in this work. As a result, a common modeling grammar has
evolved from this research. This grammar can be used to model IBIS architectures in terms
of Agents or MAS architectures in terms of IS work systems. The concept of MIBIS basically
embodies these two and also requires a special-purpose conceptual-modeling grammar to
facilitate its analysis and design. In response, we have developed the MibML grammar for
the conceptual modeling of MIBIS systems. The MibML constructs are extracted from both
MAS and IBIS literatures, and are specified formally in BNF and first order predicate logic. A
proof-of-concept model has also been developed for an e-commerce application to illustrate
the application of MibML grammar and is available as a supplement to this paper.
The MibML grammar provides a starting point for ontology-driven MIBIS
development. There are several future research directions to further this study. First, in
order to enhance the reuse of MIBIS domain specific knowledge, lower-level ontological
categories for the MibML foundation constructs need to be developed (e.g., an ontology of
MIBIS roles, an ontology of MIBIS goals, etc.). These initiatives could also imply a degree of
31
domain-specificity in MibML definitions and axioms. Second, extensions of the role construct
to incorporate hierarchical role structures that would capture non-autonomous behaviors
present significant areas for further research. Third, interactions in the current study are
limited to direct interactions between a pair of roles. In future work, interactions will be
extended to include those between more than two roles. Finally, knowledge in this study is
limited to deductive reasoning and it is possible to extend MibML to include other types of
knowledge and reasoning mechanisms, such as abductive, inductive, and case-based, etc.
32
6 REFERENCES
[1] M. Alavi and D. E. Leidner, "Knowledge management and knowledge management
systems: conceptual foundations and research issues," MIS Quarterly, vol. 25, no. 1, pp. 107-136, 2001.
[2] S. Alter, "A general, yet useful theory of information systems," Communications of the Association for Information Systems, vol. 1, no. 13, pp. 1-70, 1999.
[3] J. L. Austin, How to Do Things with Words. Oxford, UK: Clarendon, 1962. [4] A. Bajaj and S. Ram, "SEAM: a state-entity-activity-model for a well-defined
workflow development methodology," IEEE Transactions on Knowledge and Data Engineering, vol. 14, no. 2, pp. 415-431, March/April 2002.
[5] A. Basu and A. Kumar, "Research commentary: workflow management issues in e-business," Information Systems Research, vol. 13, no. 1, pp. 1-14, March 2002.
[6] B. Bauer, J. P. Muller, and J. Odell, "Agent UML: A formalism for specifying multiagent software systems," presented at the First International Workshop (AOSE-2000), Berlin, Germany, 2000.
[7] B. J. Biddle and E. J. Thomas, Role Theory: Concepts and Research: John Wiley & Son, Inc, 1966.
[8] A. H. Bond and L. Gasser, Readings in Distributed Artificial Intelligence. San Mateo, CA: Morgan Kaufmann, 1988.
[9] G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Language User Guide: Addison-Wesley, 1999.
[10] F. M. T. Brazier, C. M. Jonker, and J. Treur, "Compositional design and reuse of a generic agent model," Applied Artificial Intelligence Journal, vol. 14, no. 5, pp. 491-538, 2000.
[11] K. Chari and T. K. Sen, "An implementation of a graph-based modeling system for structured modeling (GBMS/SM)," Decision Support Systems, vol. 22, no. 2, pp. 103-120, February 1998.
[12] S. Conger, The New Software Engineering. California: Wadsworth Publishing Company, 1994.
[13] S. A. Deloach, M. F. Wood, and C. H. Sparkman, "Multiagent systems engineering," International Journal on Software Engineering and Knowledge Engineering, vol. 11, no. 3, pp. 231-258, 2001.
[14] J. L. G. Dietz, "DEMO: towards a discipline of organisation engineering," European Journal of Operational Research, vol. 128, no. 2, pp. 351-363, 2001.
[15] E. H. Durfee and V. R. Lesser, "Negotiating task decomposition and allocation using partial global planning," in Distributed Artificial Intelligence, vol. 2, L. Gasser and M. Huhns, Eds. San Francisco, CA: Morgan Kaufmann, 1989, pp. 229-244.
[16] L. Fischer, "The Workflow Handbook 2001," Association with the Workflow Management Coalition (WfMC), 2000.
[17] M. S. Fox, M. Barbuceanu, M. Gruninger, and J. Lin, "An organization ontology for enterprise modeling," in Simulating Organizations: Computational Models of Institutions and Groups, M. Prietula, K. Carley, and L. Gasser, Eds. Menlo Park CA: AAAI/MIT Press, 1998, pp. 131-152.
[18] S. Franklin and A. Graesser, "Is it an agent, or just a program?: a taxonomy for autonomous agents," presented at Third International Workshop on Agent Theories, Architectures, and Languages, 1996.
[19] J. Habermas, The Theory of Communicative Action, vol. I. Boston: Beacon Press, 1984.
[20] G. Huber, "Organizational learning: the contributing processes and the literatures," Organization Science, vol. 2, no. 1, pp. 88-115, 1991.
33
[21] N. R. Jennings, "Coordination techniques for distributed artificial intelligence," in Foundations of Distributed Artificial Intelligence, G. M. P. O'Hare and N. R. Jennings, Eds. London: Wiley, 1996, pp. 187-210.
[22] N. R. Jennings, "An agent-based approach for building complex software systems," Communications of the ACM, vol. 44, no. 4, pp. 35-41, 2001.
[23] N. R. Jennings, P. Faratin, M. J. Johnson, T. J. Norman, P. O'Brien, and M. E. Wiegand, "Agent-based business process management," International Journal of Cooperative Information Systems, vol. 2 & 3, pp. 105-130, 1996.
[24] N. R. Jennings, T. J. Norman, P. Faratin, P. O'Brien, and B. Odgers, "Autonomous agents for business process management," Journal of Applied Artificial Intelligence, vol. 14, no. 2, pp. 145--189, 2000.
[25] R. Kishore, H. Zhang, and R. Ramesh, "Ontologies, frameworks, and systems: a helix-spindle model for ontological engineering," Communications of the ACM, 2004.
[26] M. Knapik and J. Johnson, Developing Intelligent Agents for Distributed Systems : Exploring Architecture, Technologies, and Applications. New York: McGraw-Hill, 1998.
[27] A. Kumar, "Dynamic routing and operational controls in workflow management," Management Science, vol. 45, no. 2, pp. 253-272, 1999.
[28] A. Kumar, W. M. P. van der Aalst, and E. M. W. Verbeek, "Dynamic work distribution in workflow management systems: how to balance quality and performance," Journal of Management Information Systems, vol. 18, no. 3, pp. 157-193, Winter 2001-2002 2002.
[29] J. Lee, K. Siau, and S. Hong, "Enterprise integration with ERP and EAI," Communications of the ACM, vol. 46, no. 2, pp. 54-60, 2003.
[30] M. Lejter and T. Dean, "A framework for the development of multi-agent architectures," IEEE Expert, vol. 11, no. 6, pp. 47-59, 1996.
[31] D. S. Linthicum, Enterprise Application Integration. Boston, MA: Addison-Wesley, 1999.
[32] T. W. Malone and K. Crowston, "The interdisciplinary study of coordination," ACM Computing Surveys, vol. 26, no. 1, pp. 87-119, 1994.
[33] T. W. Malone, K. Crowston, J. Lee, B. Pentland, C. Dellarocas, G. Wyner, J. Quimby, C. S. Osborn, A. Bernstein, G. Herman, and M. Klein, "Tools for inventing organizations: Toward a handbook or organizational processes," Management Science, vol. 45, no. 3, pp. 425-443, 1999.
[34] M. Marcotty and H. Ledgrad, "The World of programming Languages." Berlin: Springer-Verlag, 1986, pp. 41-47.
[35] R. Medina-Mora, T. Winograd, and P. Flores, "Action workflow as the enterprise integration technology," Bulletin of the Technical Committee on Data Engineering, vol. 16, no. 2, pp. 49-52, 1993.
[36] I. Nonaka, "A dynamic theory of organizational knowledge creation," Organization Science, vol. 5, no. 1, pp. 14-37, February 1994 1994.
[37] H. Nwana, L. Lee, and N. Jennings, "Coordination in software agent systems," BT Technology Journal, vol. 14, no. 4, pp. 79-88, 1996.
[38] J. Odell, "Objects and agents compared," Journal of Object Technology, vol. 1, no. 1, pp. 41-53, 2002.
[39] J. Y. C. Pan and J. M. Tenenbaum, "An intelligent agent framework for enterprise integration," IEEE Transactions on Systems, man, and cybernetics, vol. 21, no. 6, pp. 1391-1991, 1991.
[40] M. P. Papazoglou and W.-J. v. d. Heuvel, "From business processes to cooperative information systems: an information agents perspective," in Intelligent Information Agents, M. Klusch, Ed.: Springer, 1999.
[41] J. L. Peterson, Petri Net Theory and the Modeling of Systems. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1981.
34
[42] S. Russell and P.-. Norvig, Artificial Intelligence: A Modern Approach, Second Edition ed. Upper Saddle River, NJ: Prentice Hall, 2003.
[43] A.-W. Scheer, ARIS-Business Process Modeling. Berlin: Springer, 1999. [44] J. R. Searle, Speech Acts: An Essay in the Philosophy of Language: Cambridge
University Press, 1969. [45] R. Sikora and M. J. Shaw, "A multi-agent framework for the coordination and
integration of information systems," Management Science, vol. 44, no. 11, pp. 65 - 78, November 1998.
[46] V. Sugumaran, M. Tanniru, and V. C. Storey, "Supporting reuse in systems analysis," Communications of the ACM, vol. 43, no. 11es, pp. 312-322, November 2000 2000.
[47] J. Tillquist, J. L. King, and C. Woo, "A representational scheme for analyzing information technology and organizational dependency," MIS Quarterly, vol. 26, no. 2, pp. 91-118, June 2002 2002.
[48] V. K. Vaishnavi, G. C. Buchanan, and W. L. K. Jr, "A data/knowledge paradigm for the modeling and design of operations support systems," IEEE Transactions on Knowledge and Data Engineering, vol. 9, no. 2, pp. 275-291, March-Aprial 1997.
[49] W. M. P. van der Aalst and K. Akhil, "XML-based schema definition for support of interorganizational workflow," Information Systems Research, vol. 14, no. 1, pp. 23-46, 2003.
[50] W. M. P. van der Aalst and A. Kumar, "A reference model for team-enabled workflow management systems," Data & Knowledge Engineering, vol. 38, no. 3, pp. 335-363, 2001.
[51] J. Verschueren, The analysis of speech act verbs: theoretical preliminaries. Bloomington, Indiana: Indiana University Linguistic Club, 1977.
[52] J. Verschueren, On speech act verbs. Amsterdam: John Benjamins, 1980. [53] P. Vitharana, F. M. Zahedi, and H. Jain, "Knowledge-based repository scheme for
storing and retrieving business components: a theoretical design and an empirical analysis," IEEE Transactions on Software Engineering, vol. 29, no. 7, pp. 649-664, July 2003.
[54] Y. Wand and R. Weber, "Research commentary: information systems and conceptual modeling - a research agenda," Information Systems Research, vol. 13, no. 4, pp. 363-376, 2002.
[55] H. Weigand and W.-J. v. d. Heuvel, "Cross-organizational workflow integration using contracts," Decision Support Systems, vol. 33, pp. 247-265, 2002.
[56] T. Winograd, "A language/action perspective on the design of cooperative work," Journal Of Human-Computer Interaction, vol. 3, no. 1, pp. 3-30, 1987-88.
[57] M. Wooldridge, An Introduction to Multiagent Systems. West Sussex, England: John Wiley & Sons, Ltd, 2002.
[58] M. Wooldridge and N. R. Jennings, "Intelligent agents: theory and practice," Knowledge Engineering Review, vol. 10, no. 2, pp. 115-152, 1995.
[59] M. Wooldridge, N. R. Jennings, and D. Kinny, "The Gaia methodology for agent-oriented analysis and design," Autonomous Agents and Multi-Agent Systems, vol. 3, no. 3, pp. 285 - 312, 2000.
[60] E. Yu and J. Mylopoulos, "Why goal-oriented requirements engineering," presented at 4th International Workshop on Requirements Engineering: Foundations of Software Quality, Pisa, Italy, 1998.
35
7 SUPPLEMENTAL MATERIAL: PROOF-OF-CONCEPT ILLUSTRATION
This supplemental material provides a simple but comprehensive example to
illustrate the application of the MibML grammar in modeling a MIBIS application. In the
example, we consider a fictitious online retailer that sells computer products, software, and
electronics to consumers. The goal of the particular MIBIS application is to support sales of
made-to-order personal computers. We model the key features of this scenario using MibML
so that the essential concepts of the MibML modeling grammar can be illustrated without
getting bogged down with trivial details about the business scenario and the application. We
simplify the business processes of made-to-order PC sales and put our focus on describing
how the MibML constructs are applied to model this MIBIS application.
The business processes involves actors in the following areas: the customer service
area deals with customers, the PC assembly planning area plans the assembly of PCs
according to customers’ requirements, and the delivery area is responsible for delivering
assembled PCs to customers. These three areas work independently but coordinate with
each other to provide services to customers. The scenario begins with a customer trying to
buy a new PC with his/her own hardware and software options. After the customer finalizes
a computer configuration, the customer service area generates a price quote for the
customer. If the customer decides to place an order, the customer service collects customer
information and sets up an account for him/her if this is his/her first order. Based on
customer’s credit, the customer service area decides whether to reject the order or to
approve the order and propose financing options. If an order is approved, the PC assembly
planning area checks inventory for necessary parts to assemble the PC. If some required
parts are not available, the PC assembly area contacts suppliers and decides where to
order5. The PC assembly planning area also estimates the time needed to assemble the PC
5 Generally inventory planning and procurement from suppliers is done based on demand forecasts
but we are not modeling this function in this simple illustration.
36
and updates the PC assembly status. After the PC is assembled, the delivery area schedules
the shipment. The responsibilities of the delivery area include determining the method of
delivery, packaging the assembled PC, estimating the delivery date, scheduling the pick-up
of the assembled PC by a shipping company, and updating the shipment status. We only
consider some of the delivery area responsibilities in this example as we wish to keep the
illustration comprehensive yet simple. Further, while a real application will have to handle
several more functions and exception conditions, selecting an appropriate supplier,
additional information requested for credit processing, etc., we do not include them in the
example discussed below as they will be modeled in a similar manner as other situations
and conditions will be modeled, and we wish to keep the illustration to a manageable
length.
In order to model the above application, we first need to identify user requirements.
In the MibML grammar, the user requirements are captured as goals which are organized in
a tree structure. The goal tree for this particular application is very simple and is
constructed as in Figure 3. We have an overall goal G1 to provide made-to-order PC service.
G1 is decomposed into sub-level goals: G1.1 to manage customers and their orders, G1.2 to
plan PC assembly, and G1.3 to schedule PC delivery. These sub-level goals are mutually
exclusive and collectively exhaustive. Therefore, G1 is accomplished only when G1.1, G1.2,
and G1.3 are all accomplished.
37
Figure 3: The goal tree for the online PC made-to-order system
In Figure 3, we have three individual goals, which form a goal set G1.1, G1.2,
G1.3. In MibML, each individual goal is assigned to a unique role and each individual role is
associated with a unique goal. Therefore, these individual goals are assigned to 3 distinct
roles – customer service representative, assembly planner, and delivery manager. In
addition, a special coordinator role is required in MibML to ensure the accomplishment of all
individual goals. Because the coordinator role does not affect business process modeling, we
do not discuss the coordinator role in this example. The bijective mapping between goals
and roles are described in Table 6.
Table 6: The bijective mapping between goals and roles
Goal Role
G1.1 to manage customers and their orders R1 Customer service representative
G1.2 to plan PC assembly R2 Assembly planner G1.3 to schedule PC delivery R3 Delivery manager
Role is the central construct in MibML for modeling the MIBIS universe. A MIBIS
conceptual model provides definitions of roles and defines how roles interact. Figure 4
presents the conceptual model developed in MibML for the made-to-order PC service
application. As indicated in Figure 4, a role is an abstraction of goal, activities (tasks and
38
interactions), knowledge, and information privileges. Role R1 Customer Service
Representative is responsible for interacting with customers. Therefore, there are
information flows between role R1 and customers. Customers need to pass their selected PC
configuration and order request to role R1, and role R1 returns price quote, order
processing results, financing options, or order status. The tasks of role R1 include
generating price quote for customers’ request, managing account, checking credits, and
processing order. These tasks require information and knowledge as inputs and generate
outputs. For example, in order to generate price quote, role R1 must be able to read
information entity Inventory to get cost information. Therefore, there are information flows
between role R1 and information entities Customer, Order, and Inventory6.
Correspondingly, role R1 has information privileges to fully control (create, read, update,
and delete) information entity Customer and Order, and to read information entity
Inventory. In addition, role R1 must have knowledge on pricing policy, financing options,
and decision policies to reject or approve an order. Further, when a customer places an
order, role R1 interacts with role R2 Assembly Planner to notify that an order has been
received for assembly and delivery of a PC. Role R2 Assembly Planner is responsible for
planning PC assembly after receiving order notification from role R1 Customer Service
Representative. Its tasks include scheduling assembly, checking if the necessary parts are
available, and placing orders with suppliers if the parts are out of stock. In order to perform
these tasks, role R2 needs to access information entity Inventory and Order. This is
represented as information flows between role R2 and information entities. Role R2 is
assigned information privileges as required by its tasks. It has full control on Inventory, and
read privilege on Order and update privilege on the order assembly status. In order to
perform its tasks, role R2 also need to possess knowledge about part suppliers and
knowledge on estimating assembling time. Knowledge about part suppliers can also be 6 Once again to keep the example to a manageable length, we model essential information about PC
parts and quantities available in a single information entity Inventory. In real-life applications, these may be modeled as two or more separate information entities.
39
modeled as an information entity in this example. However, we choose to model knowledge
about parts suppliers as knowledge and not as an information entity because this
information is private to the role, i.e., it is not required by other roles, and hence there is
not need to model it is a shared information entity7. When PC assembly is complete, role R2
sends a notification to role R3 Delivery Manager. This is represented as an interaction
between role R2 and R3. When receiving the PC ready notification, role R3 Delivery Manager
schedules PC delivery. Information required for performing this task is Order, and it is
represented as information flow between role R3 and information entity Order.
Correspondingly, role R3 is able to read information entity Order and to update the order
shipment status. In addition, role R3 possesses knowledge to determine whether PC
delivery should be batch delivery or individual delivery.
Figure 4 provides a high-level conceptual model for describing the made-to-order PC
service application. In the rest of the paper, we discuss individual MibML constructs involved
in the model.
7 While the MibML grammar does not provide explicit guidelines for modeling something as knowledge
versus information entity or vice versa, knowledge is private to a role whereas information entities are repositories of shared information. Therefore, unique pieces of information that are only used by a particular can be modeled as declarative knowledge by way of facts and rules.
40
Figure 4: The conceptual model of the made-to-order PC service application
A task is an internal activity performed by a role. In MibML, a high-level task can be
refined by decomposition and specialization. Figure 5 shows an example of task
41
decomposition and specialization. Figure 3(a) depicts that a high-level task of Assembly
Planner T2 Order Inventory consists of two parts: T2.2 Check Inventory and T2.3 Order
Parts. T2.2 and T2.3 are mutually exclusive and collectively exhaustive, and T2 is
accomplished only when both T2.2 and T2.3 are accomplished. Figure 3(b) depicts that a
task of Delivery Manager T3.1 Schedule Delivery has two subtypes: T3.1.1 Schedule Batch
Delivery and T3.1.2 Schedule Individual Delivery. Both T3.1.1 and T3.1.2 inherit properties
from T3.1, but they may override inherited properties.
Figure 5: Task decomposition and specialization
Task in MibML is specified by input, output, and method in addition to the common
attributes for all MibML constructs. Due to space limitations, we only include task
specifications for role R1 Customer Service Representative. The detail specifications are
presented in Table 7 - Table 10.
42
Table 7: Specification of task “Generate quote”
Task
Identifier T1.1
Name Generate quote
Description Generate the price quote for the pc configuration selected by customer Input INF12 Inventory (component cost)
KF1.1 PC base price KF1.2 Discount threshold
Output KF1.3 PC final price INF3 price quote
Method Do for each customer Generate price based on component cost and pricing policy Enddo
Table 8: Specification of task “Manage account”
Task
Identifier T1.2
Name Manage account Description Set up an account for new customer and update customer information
Input INF1 customer information
Output INF8 customer Method If new customer
set up a new account Endif If existing customer authenticate customer Endif If customer changes information update customer information Endif
Table 9: Specification of task “Manage account”
Task
Identifier T1.3 Name Check credit
Description Check customer’s credit
Input INF10 Customer INF11 Credit
Output INF8 Customer INF9 Credit
Method Check internal credit records of customer If no internal credit records exist Check customer’s credit with credit card company Endif
43
Table 10: Specification of task “Process order”
Task
Identifier T1.4
Name Process order Description Decide whether to accept or reject order, create order for customer, propose
financing options, and update order status
Input INF3 Order request INF11 Credit KF1.4 Credit ranking score KD1.2 Order rejection/approval policy KD1.3 Financing rule
Output INF5 Order rejection / approval INF6 Financing options INF14 Order INF7 Order status
Method Approve or reject order If order approved Create order Propose financing options Endif If order rejected Notify customer of the rejection Endif
An interaction is an activity that occurs between two roles. Figure 4 shows two
interactions existing in the application. Interaction I1_2 is an interaction initiated by
Customer Service Representative to notify Assembly Planner that an order is ready to be
assembled; I2_3 an interaction initiated by Assembly Planner to notify Delivery Manager
that a PC ordered by customer has been assembled and is ready to be shipped. In MibML,
an interaction is specified by initiator, responder, speech acts, and message content in
addition to common attributes defined for all MibML constructs. Table 11 provides the detail
specifications of interaction I1_2 Order Notification. Table 12 provides the detail
specifications of interaction I2_3 Assembly Completion Notification.
44
Table 11: Specification of the interaction “Order notification”
Interaction
Identifier I1_2 Name Order notification
Description Customer Service Representative notifies Assembly Planner that an order is ready to be assembled
Initiator role R1 Customer service representative
Responder role R2 Assembly planner
Initiator speech act Assertion Initiator message A specific order is ready to be assembled
Responder speech act Acceptance
Responder message Notification is confirmed
Table 12: Specification of the interaction “Assembly complete notification”
Interaction
Identifier I2_3
Name Assembly completion notification
Description Assembly Planner notifies Delivery Manager that a PC ordered by a customer is ready to be shipped
Initiator role Assembly planner
Responder role Delivery manager Initiator speech act Assertion
Initiator message The PC in a specific order is ready to be shipped
Responder speech act Acceptance Responder message Notification is confirmed
Information in MibML includes information entities and information flows. Information
entities represent stable data in the system. Figure 4 indicates that our application includes
3 information entities: INE1 Customer, INE2 Order and INE3 Inventory. The specifications of
information entities in MibML are not different from those in traditional data model.
Attributes are used to keep data that system analysts are interested in. Table 13 provides a
detail specification of information entity inventory.
45
Table 13: Specification of information entity “Customer”
Information entity
Identifier INF1
Name Customer
Description Customer information and his/her credit status Attributes Customer number, Name, address, phone, internal credit ranking
Table 14: Specification of information entity “Order”
Information entity
Identifier INF2 Name Order
Description Order information
Attributes Order number, order date, PC configuration, order status, price
Table 15: Specification of information entity “Inventory”
Information entity
Identifier INF3
Name Inventory Description Inventory information of pc components
Attributes Part name, model, serial number, cost, quantity available, suppliers
Information flows are temporary data transmitted between external entities and
roles within the systems or between roles and information entities within the MIBIS system.
In MibML, it is specified by flow source, flow sink, flow frequency, flow response time, and
flow data. Figure 4 indicates there are 20 information flows involved in the application. We
do not intend to specify all of them due to space limitation. Table 16 is the specification of
information flow Customer Information, which is an example of information flows between
an external entity and a role. Table 17 is the specification of information flow Credit, which
is an example of information flows between a role and an information entity.
Table 16: Specification of information flow INF1 Customer Information
Information Flow
Identifier INF1
Name Customer information
Description Basic customer information to set up an account Flow source External entity Customer
46
Flow sink R1 Customer service representative
Flow frequency When a customer account is set up for the first time or when there are changes to existing customer information
Flow response time
Synchronous
Flow data Name, address, phone
Table 17: Specification of information INF9 Credit
Information Flow
Identifier INF9 Name Credit
Description Update customer’s credit information
Flow source R1 Customer service representative Flow sink INE1 Customer
Flow frequency When there are changes to customer’s credit information
Flow response time
Synchronous
Flow data Customer’s credit ranking
Knowledge in MibML is private to a role. It includes declarative knowledge and
procedural knowledge. Declarative knowledge is a role’s beliefs about the environment and
other roles. Declarative knowledge is specified in MibML using facts and deduction rules.
Declarative knowledge, like information, is used as inputs or generated as outputs of tasks.
Procedural knowledge describes the constraints on performing activities (tasks and
interactions). It is specified as activity execution structure and activity execution
constraints. Activity execution structure is represented a sequence of tasks inside a role.
Activity execution constraints are defined as a set of events that are used to coordinate
tasks among different roles. Table 18 provides specifications of knowledge for Customer
Service Representative. Table 18 indicates that Customer Service Representative possesses
3 facts (KF1.1, KF1.2, and KF1.3) and 3 deduction rules (KD1.4, KD1.5, and KD1.6). In
MibML, a deduction rule uses at least two existing facts or information flows to generate a
new fact or information flow. For example, deduction rule KD1.1 uses an existing KF1.1 fact
and an existing KF1.2 fact to generate a new KF1.3 fact; and deduction rule KD1.2 uses an
existing information flow of INF11 and an existing K1.3 fact to generate a new information
47
flow of INF5. Table 18 also specifies procedural knowledge (KT1.1 and KX1.1) for Customer
Service Representative. Activity execution structure KT1.1 specifies the order to execute the
internal tasks (T1.1, T1.2, T1.3, and T1.4) and the interactions (I1_2). Activity execution
constraint KX1.1 specifies task-triggering events that are used to coordinate Customer
Service Representative with other roles. Similarly, Table 19 and Table 20 specify the
knowledge of Assembly Planner and Delivery Manager.
Table 18: Specification of knowledge of “Customer Service Representative”
Knowledge
Identifier K1 Name Customer Service Representative Knowledge
Description Knowledge on pricing, credit ranking, financing, order rejection/approval policy, and constraints on performing tasks
Declarative Knowledge
Facts KF1.1 PC base price PC base price = Cost x (1+10%) KF1.2 Discount threshold KF1.3 PC final price PC final price = PC base price x (1-discount percentage) KF1.4 Credit ranking score High ranking score and low ranking score
Deduction rules KD1.1 Discount policy If the base price of an order (KF1.1) is more than the discount threshold (KF1.2), the customer gets 5% discount (K1.3). KD1.2 Order rejection/approval policy If customer has credit ranking (INF11) less than the low ranking score (K1.3), reject the order (INF5). Otherwise, accept the order (INF5). KD1.3 Financing rule If customer has credit ranking (INF11) greater than the high Ranking score (K1.4), propose financing options (INF6).
Procedural Knowledge
Execution structure KT1.1 Activity execution structure • T1.1 generate quote and T1.2 manage account precede T1.3
check credit. • T1.3 check credit precedes T1.4 process order. • T1.4 process order precedes I1_2 order notification.
Execution constraints KX1.1 Activity execution constraints • T1.1 generate quote is triggered by receiving customer’s quote
request. • T1.2 management account is triggered by receiving customer’s
order request.
48
Table 19: Specification of knowledge of Assembly Planner
Knowledge
Identifier K2
Name Assembly Planner Knowledge
Description Knowledge on suppliers, assembly time, and constraints on performing tasks
Declarative Knowledge
Facts KF2.1 suppliers • Supplier A provides high quality parts. • Supplier B is less expensive.
KF2.2 Supplier selection KF2.3 Assembly time
Deduction rules KD2.1 Supplier selection If high quality components are needed (INF18 and KF2.1), select Supplier A (KF2.2); otherwise, select Supplier B (K2.2). KD2.2 Assembly time estimation If all parts are available (INF16 and INF 18), it takes average 1 week to assemble PC (KF2.2). Otherwise, it takes average 2 weeks (KF2.2).
Procedural Knowledge
Execution structure KT2.1 Activity execution structure • T2.2 check inventory precedes T2.3 order parts • T2.2 check inventory precedes T2.1 schedule assembly • T2.1 schedule assembly precedes I2_3 assembly completion
notification
Execution constraints KX2.1 Activity execution constraints • T2.2 check inventory is triggered by I1_2 order notification
Table 20: Specification of knowledge of Delivery Manager
Knowledge
Identifier K3
Name Delivery Manager Knowledge
Description Knowledge on delivery as well as constraints on performing tasks.
Declarative Knowledge
Facts KF3.1 Delivery time KF3.2 Delivery types Local delivery and long distance delivery KF3.3 Delivery methods Individual delivery and batch delivery
Deduction rules KD3.1 Delivery policy If an order (INF19) is a local delivery (KF3.2), it delivered individually (INF20). Otherwise, it is delivered in batches (INF20). KD3.2 Delivery time estimation If an order (INF19) is a local delivery (KF3.2), it takes 2-3 days (KF3.1); otherwise, it takes average 7 days (KF3.1).
Procedural Knowledge Execution structure None
Execution constraints KX3.3 Activity execution constraints • T3.1 schedule delivery is triggered by I2_3 assembly completion
notification
49
A role is an integration of goal, tasks, interaction, knowledge, and information
privilege. With the above constructs defined, it is easy to specify roles in the system. Table
21 - Table 23 provides specifications for role Customer Service Representative, Assembly
Planner, and Delivery Manager respectively.
Table 21: Specification of role Customer Service Representative
Role
Identifier R1
Name Customer service representative
Description A customer service representative interacts with customer, and is responsible for generating price quote, manage customer account, and process order.
Goal G1.1 To manage customers and their orders Interactions I2_3 Order notification
Tasks T1.1 generate quote T1.2 manage account T1.3 check credit T1.4 process order
Information permissions • Full control on INE1 Customer • Full control on INE2 Order • Read INE3 Inventory
Knowledge Declarative Knowledge KF1.1 PC base price KF1.2 Discount threshold KF1.3 PC final price KF1.4 Credit ranking score KD1.1 Discount policy KD1.2 Order rejection/approval policy KD1.3 Financing rule Procedural Knowledge KT1.1 Activity execution structure KX1.1 Activity execution constraints
Table 22: Specification of role Assembly Planner
Role
Identifier R2
Name Assembly planner
Description Plan PC assembly Goal G1.2 To plan PC assembly
Interactions • I1_2 Order notification • I2_3 Assembly completion notification
Tasks T2.1 schedule assembly T2.2 check inventory T2.3 order parts
Information permissions • Full control on INE3 Inventory • Read INE2 Order
50
• Update INE2 Order – assembly status
Knowledge Declarative Knowledge KF2.1 suppliers KF2.2 Supplier selection KF2.3 Assembly time KD2.1 Supplier selection KD2.2 Assembly time estimation Procedural Knowledge KT2.1 Activity execution structure KX2.1 Activity execution constraints
Table 23: Specification of role Delivery Manager
Role
Identifier R3
Name Delivery manager Description Manage inventory and schedule delivery
Goal G1.3 To manage delivery
Interactions • I2_3 Assembly completion notification Tasks T3.1 schedule delivery
Information permissions • Read INE2 Order • Update INE2 Order – shipment status
Knowledge Declarative Knowledge KF3.1 Delivery time KF3.2 Delivery types KF3.3 Delivery methods KD3.1 Delivery policy KD3.2 Delivery time estimation Procedural Knowledge KX3.1 Activity execution constraints
Agents in MibML are instantiation of roles. There is one-to-one mapping between
roles and agent types. Table 24 provides mapping between roles and agents in our
application.
Table 24: Mapping between roles and agents
Role Agent
R1 Customer service representative A1 Customer service representative agent R2 Assembly planner A2 Assembly planner agent
R3 Delivery manager A3 Delivery manager agent