Engineering Agent-Based E-Commerce Systems Using ... - CiteSeerX

Engineering Agent-Based E-Commerce Systems Using The Semiotic Approach And The DEMO Transaction Concept

Joseph Barjis Department of Information Systems & Software Engineering, Delft University of Technology The Netherlands; e-mail: [email protected]; http://is.twi.tudelft.nl/~Barjis

Samuel Chong School of Computing, Staffordshire University, Stafford, Beaconside, ST18 0AB, England, UK e-mail: [email protected]; http://www.soc.staffs.ac.uk/~cmrycc

Jan L.G. Dietz Department of Information Systems & Software Engineering, Delft University of Technology The Netherlands; e-mail: [email protected]

Kecheng Liu School of Computing, Staffordshire University, Stafford, Beaconside, ST18 0AB, England, UK e-mail: [email protected]; http://www.soc.staffs.ac.uk/~cmtkl

ABSTRACT As software agents get more sophisticated, it becomes difficult to understand and model such systems. In this paper, we contend that all developers bring to the task of development some implicit or explicit assumptions of the agent communication pattern. This issue is not readily addressed in current literature and represents a gap in knowledge. For this purpose a generic pattern of inter-agent communication is introduced and discussed in this paper. For better understanding and modelling of agent-based e-commerce systems, the semiotic approach and the DEMO transaction concept are briefly introduced. It is shown that the semiotic approach offers a unifying framework for identifying the roles of agents, the responsible human agents and the right/constraints associated with each role. The DEMO transaction concept is applied to model the communicative interaction between agents.

Keywords: Software agent and agents’ communication, Semiotics, DEMO methodology

1.

Introduction

Electronic commerce is emerging as one of the most exciting research areas in our era. E-commerce systems are dynamic networks of interrelated transaction processes between two or more trading agents. Agent-based technology is emerging as a powerful paradigm for developing e-commerce systems. In recent years, software agents have been introduced to e-commerce. Software agents in e-commerce systems have some autonomy and the ability to sense and react to their environment, as well as socially communicate

and cooperate with other software agents in order to accomplish their duties which are delegated from the human agents. Software agents can potentially help the human agents to perform some delegated tasks, such as searching for some products of interest, negotiate with the supplier and even make payment on behalf of the human agents. By looking at the business processes of agent-based e-commerce systems we observe the following features. First of all, it is a process between two agents, supplier and customer (or customer and supplier, depending on who is the initiator of the current deal). Secondly we observe that communication for a deal in e-commerce involves the exchange of electronic transactions between these agents. As the capabilities in software agents become more complex, it becomes more difficult to model and design agent-based e-commerce systems. While the technologies for developing agents are maturing and advancing at an increasing rate, there is a lack of methods that is based on sound and theoretically principle for modelling such systems. In order to build a successful and effective agent-based e-commerce system, one needs a proper study of the way in which agents communicate to each other. Thus, the inter-agents communication perspective becomes an important issue in the study of agent-based e-commerce systems. Although numerous papers [Wooldridge et al. (2000), Chong and Liu (1999, 2000)] are dedicated to this issue, it is still a poorly understood one. For instance, existing design methods such as the Agent Oriented Relationship modelling method [Taveter & Wagner (2000)], Gaia Methodology for Agent Oriented Analysis and Design [Wooldridge et al. (2000)], Agent Modelling Technique (AMT) [Kinny et al. (1996)], Multiagent System Engineering (MaSE) method [DeLoach (2000)] and the Agent Oriented Methodology (AOM) [Elammari & Lalonde (1999)] only excel in generating low-level design diagrams and offer little guidance in helping the designers to study the inter-agent communication. Therefore an efficient, adequate and easily understandable technique is needed to model agent-based e-commerce in order to improve the design of the system. This paper investigates e-commerce systems from the communication perspective based on the semiotic approach and the DEMO (Dynamic Essential Modelling of Organization) modelling technique. DEMO is a modelling methodology mainly considering a business system from the communication perspective [Dietz (1999)]. It emphasizes a uniform communication pattern between agents, involved in a business deal. A social model of the business domain is obtained through the analysis of how meanings and intentions can be conveyed by language (signs) and what aspects of language need to be captured so that through the representation of data, the agent-based e-commerce system can function as an effective substitute for human communication. Through this model, the roles of agents and their potential behaviour (e.g. buys, subscribes) can be identified. For this purpose, the authors consider that the DEMO business transaction concept and the semiotic approach can more properly and adequately represent and model an agent-based e-commerce system.

2.

Generic communication pattern for agents in e-commerce

In order to study the complexities of the communication of agents so that an effective agent-based ecommerce system can be developed, we first need to understand the generic communication pattern of the human agents. By doing this, we can ensure that agents engage in the same communication pattern as their human agents so that the rights of the human agents will not be infringed. Therefore we consider the DEMO transaction concept that was originally conceived to understand human communication within an organization [Dietz (1999)] can also be easily adapted for understanding inter-agent communication involved in agent-based e-commerce systems. Hence, we refer the inter-agent communication as electronic transaction. A generic pattern of such electronic transaction is presented in figure 1a. An electronic transaction is carried through by two agents/parties (human or software agents), mostly on an online basis. The one who starts the transaction and eventually accepts the results, is called the customer or initiator, the other one, who actually performs the objective action, is called the supplier or executor. In order to perform the objective action, the human agent may employ the help of a software agent. In this respect, the software

agent is also considered to be an executor on behalf of the human agent at the IT layer. This interrelation is depicted in figure 1a as two-layered presentation - social layer and IT layer. The same rule applies to the initiator, who may also employ the help of a software agent to initiate a request on his behalf, in which case, the software agent is considered the initiator at the IT layer. A transaction according to DEMO consists of three phases: the order phase or O-phase, the execution phase or E-phase, and the result phase or R-phase (represented as three discs in figure 1b). The order phase (O) is an interaction between the initiator and the executor that starts with the request of the initiator and ends with the promise by the executor. The execution phase (E) starts with the promise and ends with the statement by the executor that the objective action, leading to the agreed upon result, is executed. The result phase (R) starts with the statement and ends with the acceptance by the initiator of the result. The arrows between the social and IT layers represent the delegation of duties and authorities to the software agents. The double-headed bold arrow shows the use of signs between the agents (human or software) to perform a business deal . Analysing the DEMO transaction concept mentioned above, one can conclude that this transaction in ecommerce will have the following interpretation. As for O-phase, it is an interaction between human agent and software agent representing the delegation of duties to the software agent, thus making the software agent an initiator on behalf of the human agent. As for E-phase, generally speaking, it takes place in the IT layer and is performed solely by software agent on behalf of the initiator human agent. Initiator (customer)

I

Social layer (human agents)

signs

E

Executor (supplier)

Inter-layer interface depicting 'obligations' and 'expectations'

IT layer (software agents)

DEMO request Transaction

..

..

Begin Read If true Do Else Wait End

Begin Read If true Do Else Wait End

signs

promise

O

state

E

accept

R

Figure 1. a) The two layered inter-agents communication structure; b) the DEMO transaction pattern

3.

Semiotic analysis for identifying communicating roles

This phase starts with the Semantic Analysis method [Barjis & Filipe (2000), Chong & Liu (2000), Stamper et al. (2000)]. It is important to note that the signs used for communication by the human agents can be broken down into a structure, which consists of the recipient of a message, the sender of the message, the meaning of the message and the intention of the message (see figure 3). As shown in figure 1, the software agents generate electronic signs that carry meaning or intentions in order to change the social world of their human agents. In order to understand how software agents use signs to communicate meanings and intentions, we first need to understand how the human agents use signs in the same situation to get the same task done. Figure 2 shows a contextual diagram of the business domain of QuickQuote. A more detailed description of the business operation of QuickQuote can be found at http://www.quickquote.com/.

Figure 2. Context diagram of QuickQuote Sign Recipient

Sender

Meaning

Intention

Figure 3. Structure of a sign policies

payer

insurance company

pays

@

licenser

#Policy_numbe r #Policy_type #Effective_date #Effective_time pays @

register

lice

address insurance agent

person

e

nse

lives

commission commission

payee

subscriber

searches @

buys subscribes

r

e buy

owns

Society

custo

credit card

mer enquires

credit card company

ee

pay

website

e-mail address

QQ

Figure 4. Ontological chart of QuickQuote. As a result of identifying the human agents and specifying the social world that is created by their use of signs during semantic analysis, an ontological chart is conceived (see figure 4). Readers can consult [Chong & Liu (1999)] and [Liu (2000)] for more details regarding the steps in constructing the ontological chart.

Looking at the case study and its ontological chart, the roles, potential actions of software agents and the responsible human agents can be identified. It should be noted that the above ontological chart has to be read from the left to the right. Entities that are on the right are dependent on the existence of the entities on their left to exist. Any entity whose existence is dependent on the existence of other entities is known as the dependant, while the parent entity of the dependant is known as the antecedent. In this model, the entities in circles are usually the companies or human agents that are responsible for the actions of their agent. The roles of the software agents that are required in the business domain can be identified from the semi-circles. Nodes that represent verbs reflect the potential actions that the software agents can perform on behalf of its human agent. It is to be noted that the action may evolve into a business transaction that involves two parties and creates a new fact in the object world. The action "buys" leads to the existence of the action "pays" if the action "buys" is satisfactorily completed. Therefore, a dotted line with an “@” sign is used to indicate that the completion of the action "buys" activates the action "pays". Some features of the ontological chart are worth noting. Firstly, one of the contribution of the ontological chart is that it provides an understanding of which human agents are responsible for the actions of the software agents. This understanding provides the basis to specify the social obligations that are incurred on the responsible human agents as a result of the actions of the software agents. This is important in a business deal especially, since it is important for the company to fulfil any obligation incurred on them by the software agents. Customers will definitely take their business elsewhere if obligations or promises are not kept. For example, the insurance company is obliged to sell an insurance policy at a price which the software agents have quoted to the customer. Secondly, one has to realize that the existence of an action must be within the existence of its antecedent. Once its antecedent ceases to exist, the lifetime of the dependant will also come to an end. For example, no behaviour ‘buys’ should be performed by any other software agents when there are no customer. This understanding can be translated into implementation to ensure that only the software agents that represent the appropriate human agents have the proper authority to perform some sensitive tasks. The ontological chart and its relation to DEMO concept can be explained in the following manner. All possible transactions can be identified by analysing the potential actions in the figure (buy, pay, search, etc.). However, the action can only be treated as a transaction if it creates a new fact in the object world, e.g. 'buy', which causes the issue of a new insurance policy. In other words, a new insurance policy is created. Each potential transaction has a set of underlying rights and constraints that are associated with the successful completion of the transaction. The transaction "buys" for example is a complex action that includes a set of underlying rights and constraints which we refer to as behavioural norms. Although the ontological chart offers an understanding of what potential transactions are available, the detailed rights and constraints associated with the realizations of each transaction are not covered. For example, one of the constraints of the transaction ‘buys’ may be that the software agent is allowed to make payment only if the price of the policy is less than $100. These complex actions which is built upon the rights and constraints can be depicted in the form of behavioural norms of the human agents [Chong & Liu (1999), Stamper et al. (2000)]. The concept of behavioural norms is not new in information systems development. A prominent approach that employs the use of norms for identifying the actions of the object system is the MEASUR research program [Stamper (1994)]. In [Liu & Dix (1997)] authors also give an account of how behavioural norms can help in the modelling and development of information systems. Behavioural norms can be captured from the human agents by studying the regularities of their actions. These norms can later be programmed and incorporated into software agents for two purposes: Ø To govern the actions of the software agents, which will ensure that the software agents do not violate the rights of the human agents by behaving reasonably and correctly. Ø The norms can also act as trigger for the software agents to perform automatic actions, such as replying to an enquiry. Another type of trigger is reminder messages that prompt some actions from the human agents (i.e. their social obligation).

In general, behavioural norms have the following structure: IF obliged/permitted/forbidden> to perform

There are three fundamental aspects of behavioural norms and they are expressed in the form of “a software agent is obliged, permitted or forbidden to behave in certain way". In this process, the responsible human users (identified from the ontological chart) are consulted. A permitted action or speech act is one which is normative and can thus be performed legally by a software agent, an obligatory action or speech act is one which must eventually be performed by a software agent and a forbidden action or speech act is one which is non-normative and thus cannot be preformed by a software agent. For the sake of simplicity and clarity we only show some of the behavioural norms underlying the action "buys" and "pays" in figure 5.

Figure 5 Behavioural norms of the actions "buys" and "pays". We acknowledge that one of the weaknesses of the representation of behavioural norms in figure 5 is that they are subjected to misinterpretation as they are expressed in natural language, that is, English.

4.

Interface requirement analysis

Software agent is a software entity that is constructed and controlled by means of signs. A sign in this respect stands for something to somebody in some respect [Andersen (1997)]. The interface component of software agent is one good example of a computer-based sign. Recently, semiotics has been identified by a variety of writers as a useful way of understanding the computer interface because of the computer's nature as a very special kind of communication medium [De Souza (1993), Andersen (1997), Tim & Vile (1999)].

Other writers such as [Blakenberger & Hahn (1991), Familant & Detweiler (1993), Reisner (1993)] have also contributed to semiotics in interface design (either explicitly or implicitly). Authors in [Tim & Vile (1999)] identified three phases based on semiotics which offer an analytical framework to any would be interface developer: Ø Ø Ø

Contextual HCI semiotics analysis Web interface semiotics analysis Semiotic metaphor analysis

The Contextual HCI semiotics is concerned with how meanings are interpreted by the human agents with respect to the social and business context in which they work in. Once the analysts are clear of the meanings of the signs in the specific business context, the analysis enters into the web interface semiotics phase. This phase is concerned with the most effective use of the means of communication including the use of icons and indexes to reflect the meaning of the signs in that specific business context. At the semiotic metaphor analysis, we question the consistency and the cohesiveness between the relationship of the metaphor used to represent the sign types and the object it represents. These three phases are illustrated in figure 6. Building upon Tim & Vile’s work, we established the link between the semantic model and interface design.

Figure 6. Three phases of interface requirements analysis

4.1 Contextual HCI semiotics analysis From a semiotic perspective, an interface is a sign system that is repeatedly interpreted by a group of human agents. The human agents are actively seeking to interpret the object represented by the sign. In order

to help the human agents interpret signs successfully, the social context in which the signs obtain their meanings needs to be taken into consideration. The human agents' culture and context will influence the way in which they interpret signs from the interface. For example, for a computer scientist, a class stands for an object differing from an entity in relational databases. A class can be instantiated and will inherit the attributes of its superclass. However, to a teacher, a class is a collection of students that he or she teaches. In QQ case study for example, the term “insurance agent” can mean an entity which can receive commission from the QQ, entity which can subscribes to QQ’s services and so on. The developers should not invent their own classification scheme of the meaning of the term without involving the human agents and understanding the business context under which the human agents work in. The semantic model in figure 4 can complement this by offering a framework in which the semiotic properties of a term and the situational context can be identified and compared. From a computing perspective, the semantic model is useful because it provides a framework that reconciles the perspective of the system held by both the designer and the user. The human agent uses signs including verbal or day to day speech. This includes the terms that are already identified in the semantic model, such as policies, subscribes. These terms are interpreted by the human agents within their specific business context in order to perform their tasks. However, these meanings are sometimes difficult to capture on documents, as many of them are tacit, learned, used and passed on at an unconscious level of thought. The concept of norms can help us in establishing the correct meaning of each term in a given business context. Underlying each term, we can identify a set of perceptual or evaluative norms, which when elicited from the human agent, reveal the meaning of that term in that business context. Perceptual and evaluative norms have a structure different to that of behaviour norms. In general, they have the following structure: IF THEN Adopts Towards < some consequences or proposition>

The relationship between the term “products” and its underlying norm is illustrated in figure 7. insur anc agen e t

subscribes QQ

Perceptual norm: e.g. IF insurance agent subscribes to QQ, THEN insurance agent will recognise that there will be a US$100 subscription fees

Figure 7. Meanings of terms that can be identified from perceptual norms. The elicitation of the perceptual or evaluative norms provides a mechanism in which the meaning of the specialised terminology used by the human agent can be captured. These could include jargons for day-today communication. For instance, in order to build an effective interface, the analysts must ensure that the sign “products” must be interpreted, as perceived by human agent (customers), as comprising of a product description and price per quantity. 4.2 Web interface semiotic analysis In order to achieve their business purposes, agent-based e-commerce systems must be understandable to the human agents. In this phase, the analysts are primarily concerned with how to represent the meaning of a term on a computer in the most effective way. In order to understand the representation of term using signs,

we are interested the means of communication and all types of signs and signification including languages, symbols, icons, pictures etc. According to [Tim & Vile (1999)], any semiotic element (sign, text or picture) has at least two planes, an expression in the so-called “semiosic” plane and a content in the “mimetic” plane. At the semiosic plane, we are interested in the different sign types used for representing the meanings of the terms. A simple example is use to illustrate this point: the messaging service of our mobile phones usually identifies who the senders of the messages are. The senders are represented as the mobile phone numbers or the WWW addresses that were used to send the message. Although mobile phone numbers are unique, they do not provide us with sufficient information to identify who the senders really are, considering the wide circle of friends and relatives that constitute our social life. The messaging service may instead provide a mechanism in which the names instead of the mobile phone numbers of the sender are sent to the recipient. The names may not be unique, but they do provide sufficient information to let us know who the senders really are. In other words, the sign chosen by the messaging service to represent the senders (i.e. by mobile phone numbers) fail because they do not relate to our daily sign system. Therefore it is important to consider this issue when choosing the appropriate signs (texts or pictures) for representing the meanings that were identified in the previous phase. Signs at the semiosic plane can be classified into three main categories: Icon, Symbol and Index. Authors [Familant & Detweiler (1993)] attempt to give a precise definition of icons and the relation between an icon and the thing it represents. They first distinguish icons from other signs such as indexes (signs left by other signs), and symbols whose expression only conforms to the signified object accidentally. Firstly, an icon usually displays some characteristics of the signified. For example, the “Inbox” icon shown in figure 8a displays an explicit relationship between the signifier and the signified, i.e. an inbox that contains some incoming mail. A symbol on the other hand, means the signifier and the signified have an arbitrary logical entailment and connection. The connection is fixed wholly by cultural and social convention. For example, if we want to set up our modem, we will click on the “control panel” symbol as shown in figure 8b. However, there are no forces that guarantee the relationship between the signifier and the signified. Under the “control panel” symbol, there are other signs involved apart from modem, such as accessibility options and keyboard. It just happened that the relationship between “control panel” and “modem” is linked by chance without being planned and is guaranteed only by a conventional rule. In other words, the “control panel” symbol can stand for something else apart from modem. Conventional rules are socially constructed, which means that every conventional rule is clearly understood by the human agents involved. Another good example will be the name “John” which appears on your incoming e-mail. John is not unique and can stand for anyone else. It could be your colleagues, ex-classmates etc. But John happens to refer to your best friend who had replied to your queries from your e-mail two days ago.

Symbol

a)

Index b)

c)

Figure 8. Example of an icon (a), symbol (b) and an index (c). In an index, the signifier and the signified are bounded in a cause-effect relationship. A thermometer for example is an example of an index. The sign on the thermometer represents the effect of the temperature of

the room. Indexes exist due to the results of some effects, such as the effect of leaving a footprint on the beach, which bears the sign that someone was there. In the World Wide Web, indexes are commonly used to refer to other sites, through the effects of being guided where to navigate in the global network, as shown in figure 8c. Indexes, like icons, lead the human agent to some specific object that they represent, but they differ in that the navigational paths of indexes are clearly defined. At this phase, the analysts may find it useful by asking themselves the following questions. Ø Are the conventional rules well understood? For example, it is not a good idea to have a “car” sign to stand for engine parts such as valves, carburettor, and alternator if the human agents are not experts in cars. Ø Are there multiple relationships or any potential concepts that may be populated with the current concept? For example, when representing cars, there may potentially be other signs to represent, such as steering wheel, safety belts etc. Ø Is navigation to other points or specific sites an essential part of the interface? In general, icons and indexes should be used liberally, but the excessive use of symbols is discouraged. Icons should be used when an illustration of ideas is necessary, use indexes (e.g. hyperlink) to point to a specific page or point, and symbols only when the conventional rules are socially understood, since symbols are vague in nature [Tim & Vile (1999)]. The choice of using different sign types depends on the users' cultural and social context, and one way of understanding this is by examining the semantic model. This process can play a substantive role in furnishing the analysts with a more detailed understanding of which categories of signs should be used to represent the meaning. As a rule of thumb (see table 1), a potential behaviour (shown as nodes in the semantic model) of the software agent can be represented as an index (especially when a behaviour activates another set of behaviour), for example as “buys” activates “pays”. The behaviour “buys” for example, can be an index that will lead the customer/buyer to some site where the behaviour “pays” can be performed (i.e. sending their credit card details). Icons on the other hand, can be liberally used to represent determiners, since they usually bear an explicit and straightforward relationship to the object they represent, such as “Policy_type”. Though symbol should be used sparingly, the semantic model reveals some terms that have a clearly understood conventional rule. The term ‘policies’ for example, may stand for strategies, guidelines, documents, certificates and so on. However in the specific context of QQ, policies is linked to some shared meaning through some conventional rule. A symbol that can effectively represent this conventional rule can be used. Concept in semantic model Potential behaviour Determiners Terms with conventional rule

Sign type Index Icon Symbol

Table 1. Rules for choosing sign types. At the mimetic plane, we are interested in the meaning of the content of the web page and the messages they communicate to the interpreter. Since we are interested in the meaning of the content, we are particularly concerned about the types of message that are transmitted from the web page to the human agent. For example, what kind of images of the organisation are we portraying to the customers as a result of using signs or texts on the web interface? Are we able to create a sense of trust and establish a good relationship with the customers through the interfaces? Unless customers trust the site and have confidence in the organisation, they will definitely take their business elsewhere [Tim & Vile (1999)]. It may be useful for the analysts to ask themselves the following questions at this stage: Ø Ø Ø

Is the interface engendering trust and portraying a good image of the company? Are the texts or signs that are used clear? Do the texts contain any jargons?

Ø Ø Ø Ø Ø Ø

Are the signs or texts structured in a way that accounts for sight and hearing impaired users? Is the placement of the company logos too large? Is the interface giving a message of authoritarianism? That is, does the use of icons excludes certain groups, for example, by being religiously or culturally biased? Is the interface up-to-date? Are the navigation methods consistent? Is there any escape route provided? For example, are there any quit buttons?

4.3 Semiotic metaphor analysis The designers should have by now identified the contextual issues that govern the use of signs. The most effective way of representing the signs (i.e. using icon, symbol or index) would have already been analysed and studied. In this phase, the analysts are interested in choosing a right metaphor for representing the sign, whether the sign is to be shown as icon, symbol or index. This is an important activity, because it forces the designers to question the validity and consistency of the interface metaphors. For example, it is not a good idea to use a “piggy bank” metaphor to represent the concept of the “save” action of your word processor. A “diskette” metaphor may be a more appropriate one. Semiotic metaphor analysis consists of four phases as shown in figure 9. Due to the scope of this paper, we will provide only a brief discussion on this phase. A more detailed discussion is left for a future paper. Candidate object generation

Develop mismatch strategies

Candidate metaphor generation

Metaphor match/ mismatch analysis

Figure 9. Four phases of semiotic metaphor analysis. 4.3.1

Candidate object generation

In this phase, the potential objects to be represented are singled out, e.g., a list of verb, nouns, prepositions etc. is produced. It is important to note that it is impossible to list every single object in the semantic model and represent them as icons. A more feasible way is to list the objects classified by categories and represent them as symbols using metaphors. Potential objects are identified from the semantic model. 4.3.2

Candidate metaphors generation

This phase is concerned with detailing the appropriate metaphor to represent the object. A list of candidate metaphors that are chosen to represent the candidate objects is generated in this phase. 4.3.3

Metaphor match/mismatch analysis

This is an important phase in the analysis. Its main purpose is to identify some of the mismatches that are likely to occur. Typically when this occurs, the human will have difficulties understanding what the object represented by the metaphors if the mismatches are not dealt with in the interface. It is in this phase that the analyst, who already possesses an understanding of the sign and the signified, forms an understanding of the relationship between them. This understanding is in the mind of the analyst and is referred to as the

interpretant in the semiosis process. An important step to aid the understanding between the object and the metaphors is to identify the match or mismatch between them. 4.3.4

Develop mismatch strategies

The final phase addresses the problems with metaphor mismatches and the course of actions to be taken in order to help the human agents to deal with the mismatches. Developing the right strategies help the human agents to understand what is and what is not depicted in the metaphors. Authors [Carroll et al. (1988)] went to the extent of making the claim that metaphor mismatches, if designed properly, can actually help the human agents to gain a greater understanding of the object. Such strategies can typically be handled by providing an index that links the metaphors to some additional notes about their actual characteristics that are not shown in the metaphors.

5.

Interaction model of QuickQuote

DEMO methodology comprises five types of models that together allow complete understanding of organization and business processes within an organization. The first model that is constructed in the DEMO analysis of an organization is the Interaction Model. The Interaction Model is a “timeless” representation of the transactional structure of an organization, that is, the Interaction Model does not show the order in which the business transactions in an organization take place. The focus of the Interaction Model is on the specification of (1) the types of business transactions that take place between the organization under investigation and its environment as well as in the organization, and (2) the initiating and executing actors of these identified transaction types. This specification of the transactional structure is, of course, performed parallel to the determination of the system boundary. 5.1 The interaction diagram The interaction diagram is the graphical representation that is used for representing the DEMO Interaction Model. It provides symbols for all the aspects of the system that are identified in the model. This means that transaction types, initiating and executing actors as well as the system boundary are included in the model. Looking at the description of the QuickQuote case study, introduced in the section 3, one can easily identify all essential transaction that take place when performing the mission of the organization. However, a plain description is still not enough to identify the transaction exactly and easily. Therefore the use of semantic analysis helps analysts to do this better. In this sense, the most helpful part of the semantic analysis is the ontological chart (see figure 4). Ontological chart helps to identify all roles, agents (actors) and actions. Usually actions in the ontological chart are represented by verbs (e.g. buy, pay). These verbs are the key to the identification of potential transactions. Once these transactions are identified, the related initiators and executors can be identified in a straightforward way. E.g., the verb "buy" in figure 4 indicates an action that creates a new fact (a new policy is issued). Now, when we look at the chart it is obvious that the initiator of this transaction is an external actor "customer" and the executor is internal actor "insurance company". From this description and figure 4 it is understood that a customer, in order to buy a policy, begins his search with the QQ that offers an appropriate policy/company (this is first transaction in the process T1). After finding an appropriate company matching customer's requirements and wishes, the customer applies to buy a policy (T2). In order for the insurance company to issue a new policy, the customer has to pay for it (T3). Otherwise said, for completion of T2 one needs result of T3 and therefore T3 has to be completed during execution of T2. Once a policy is paid and issued, according to arrangements between the insurance

company and the QQ, the insurance company has to pay commissions for each issued policy arranged through the QQ (T4). Actually, this is the last transaction in the process. All identified business transactions are represented in table 1. This table also contains information about the software agents involved. Transaction type (see figure 12 )

Result Fact Type

Software agents (see figure 4)

T1 policy_offering

F1 policy P is offered

buyer

T2 policy_buying

F2 policy P is bought

buyer

T3 policy_payment

F3 policy P is paid

buyer

T4 commission_payment

F4 the commission for policy P is paid

payer, payee

Table 1. Transaction types The next step in DEMO methodology is to identify the relevant actors and to determine their roles as initiator and executor of the transaction types. Once this is done, all interaction relationships are determined. These are drawn as exhibited in figure 10. Transaction types are represented by a symbol consisting of a disk with a diamond behind it. The disk represents the “intersubject world part” of the transaction, the diamond represents the “object world part”. Therefore, the disk can also be considered as a bank that contains the intersubject world states, and a diamond can be considered as a bank that contains the object world facts that are created as the result of successfully completed transactions. Boxes represent actors. A white box represents an elementary actor, i.e. an actor that is executor of precisely one transaction type, and a grey box represents a composite actor, also called system kernel. A transaction type is connected to its initiator by a plain line and to its executor by a line with an “open” arrow point. The system boundary is represented by a grey roundangle. The diagram exhibits e.g. that actor A1 is the executor of transaction type T1 and that (an elementary actor in) the system kernel S1 is its initiator. S1

A1 T1 T1

A1 QQ

Customer T4 T4

T5 T2

A2 Insurance Company

T3 T3

Figure 10. Interaction model of the QQ case

6.

Process model of QuickQuote

The diagram of figure 10 does not show how the identified transaction types are put together to form the business process(es). To this end, another kind of diagram is developed, as shown in figure 11. It contains only the “intersubject world part” of the transaction types, which are mostly split up into the three phases O, E and R, interconnected by plain lines. Small disks represent the initiation points of transactions. They are connected by plain lines with arrowhead to the initiated transaction types. These arrows thus represent the

causal links between transaction types. For example, figure 11 exhibits the structure of the business process, which consists of transaction types T1, T2, T3 and T4. T1, T2 and T3 are initiated externally (represented by the single small disk). T3 is initiated during the execution phase of T2. To represent this, the disk of phase E of T2 is stretched out in order to contain the initiation disk for T3. The dotted lines with arrowheads represent conditional links. For example, the dotted arrow from T3 to T2/E indicates that T3 has to be completed before T2/E can be completed. This reflects the fact that one receives insurance policy after having paid the policy fee. T1

T2/O

T2/R

T2/E T3

T4

Figure 11. Process model of the QQ case

7.

Comparison with other methods

Existing methods have difficulties capturing the profound social relationship and context between the software agents and the human agents. This paper therefore took a fundamental different approach in supporting the analysts to design ABEC systems than that from existing methods. This section evaluates the proposed method from the perspective of the functions that are not offered by existing methods. The Agent-Oriented-Relationship (AOR) method [Taveter & Wagner (2000)] provides minimal support to the analysis of the proposed system at the conceptual level. No useful techniques or guidelines are given. It begins by modelling the proposed system as a collection of entities, objects, events, actions etc. It is arguable that as a result, one has to be preoccupied with substantial implementation details at a very early stage. For instance, the analyst has to specify the one-to-one or one-to-many relationship between the entities. The DEON method supports the analysis right from the problem statement and gradually working out the necessary requirements for the system. The Gaia method [Wooldridge et al. (2000)] is divided into an analysis and a design stage. The method, however, do not facilitate the social obligations of the human agents to be expressed. Substantial extension is required to incorporate this function in order to provide a more realistic view of the business domain, where the human agents play a central and essential role. The AMT method [Wooldridge et al. (2000)] captures the architectural aspects of the entire agent-based system (external level) and the specific software agent design (internal level). It makes one important assumption, that is, the types and roles of software agents are known beforehand. Unlike the proposed method in this paper, it is not clear on which basis these software agents are derived. The MaSE method [Kinny et al. (1996)] has one similarity with the our method, namely, it has a design phase that aims to capture the basic types of software agents. However, the design phase is contentious, since no guidelines are given to support the aim of the identification of the types of software agents. In contrast, the our method handles this by offering a systematic and progressive way of analysing and identifying the types of software agents.

Like the DEON method, the AOM method [DeLoach (2000)] provides a technique to identify the potential software agents and their behaviour patterns. Also, it places no implementation assumptions or constraints on the analysts. Nevertheless, for the AOM to be widely accepted for designing ABEC systems, major overhaul is needed in order to incorporate the functionality of capturing the social obligations of the human agents.

8.

Conclusion

The semiotic method introduced in the paper is developed based on a sound theoretical underpinnings and is an established method that have been applied successfully in many real life case studies and applications. It provides a set of formal and prescribed steps in carrying out an investigation of the business problems at hand, which include identifying the responsible human agents, software agents and their potential actions, and the behavioural norms which brings about the realization of the potential actions. These features make it a valuable asset in understanding the design requirements of the agent-based e-commerce system. The DEMO provides a sound and well-tested modelling technique for understanding and describing business systems for the purpose of optimising business processes and designing information systems. It will prove to be a very useful tool to understand e-commerce systems within its powerful framework. Using the DEMO transaction concept allows analysts and designers of e-commerce system to better understand the nature of communication in e-commerce system. DEMO transaction concept distinguishes between intersubject and object world. As a result, it helps to model two-layered communication in ecommerce systems. These two layers are referred to as the social and IT layers.

9.

References

Andersen, P. B. (1997). A Theory of Computer Semiotics. Cambridge University Press, USA. Barjis, J.; Filipe, J. (2000). Simulation of Organizational Processes Combining Semantic Analysis and Petri Nets. In the proceedings of the SCSC'2000, July 16 - 20, 2000, Vancouver, B.C. Canada. Blakenberger, S. & Hahn, K. (1991). Effects of Icon Design on Human-Computer Interaction. International Journal of Man-Machine Studies, 35, pp. 363 - 377. Caroll, J. M., Mack, R.L. & Kellogg, W.A. (1988). Interface Metaphors and the Users Interface Design, in Handbook of Human-Computer Interaction, Helander, M. (Ed.), Elsevier, Amsterdam, pp. 67 – 85. Chong, S. & Liu, K. (1999). A Semiotic Approach To The Design of Agent-Mediated E-Commerce Systems. Proceedings of IFIP WG 8.1 International Working Conference ISCO-4. Chong, S. & Liu, K. (2000). A Semiotic Approach for Modelling and Designing Agent-Based Information Systems based on Roles and Norms. Proceedings of the International Bi-Conference workshop on Agent-Oriented Information Systems 00’ (AOIS00), Stockholm (Sweden), Texas (USA). DeLoach, S. A. (1999). Multiagent Systems Engineering: A Methodology and Language for Designing Agent Systems. Proceedings of the International Workshop on Agent-Oriented Information Systems (AOIS ’99), Heidelberg, Germany, 14 –15 June. De Souza, C. S. (1993). The Semiotic Engineering of User Interface Languages. International Journal of Man-Machine Studies, 39, 753-773. Dietz J.L.G. (1999). Understanding Business Processes on the basis of Habermas’ Theory of Communicative Action, in: Proceedings of the AMCIS Conference, Milwaukee USA, august. Elammari, M. & Lalonde, W. (1999). An Agent-Oriented Methodology: High-Level and Intermediate Models. Proceedings of the International Workshop on Agent-Oriented Information Systems (AOIS ’99), Heidelberg, Germany, 14 –15 June. Familant, M. E. & Detweiler, M. C. (1993). Iconic Reference: Evolving Perspective and an Organising Framework. International Journal of Man-Machine Studies, 39, 705 - 728.

Kinny, D., Georgeff, M. & Rao, A. (1996) A Methodology and Modelling Technique for Systems of BDI Agents, in Agents Breaking Away: Proceedings of the Seventh European Workshop on Modelling Autonomous Agents in a Multi-Agent World (MAAMAW ’96), Lecture Notes on Artificial Intelligence 1038, van der Velde, W. & Perram, J. (eds.), Springer-Verlag: Heidelberg, Germany. Liu, K. & Dix, A. (1997). Norm Governed Agents in CSCW. Proceedings of the 1 st International Workshop on Computational Semiotics, De Vinche University, Paris. Liu, K. (2000). Semiotics in Information Systems Development. Cambridge University Press, UK. Reisner, P. (1993). APT: A Description of User Interface Inconsistency. International Journal of ManMachine Studies, 39, pp. 215 - 236. Stamper, R. (1994). Social Norms in Requirements Analysis- and Out of MEASUR. In Requirements Engineering: Technical and Social Aspects, Jirotka, M. & Goguen, J. (Eds.), Academic Press. Stamper, R., Liu, K., Hafkamp, M. & Ades, Y. (2000). Understanding the Roles of Signs and Norms in Organizations - A Semiotic Approach to Information Design. Journal of Behaviour and Information Technology. Taveter, K. & Wagner, G. (2000). Combining AOR Diagrams and Ross Rusiness Rules’ Diagram for Enterprise Modelling. Proceedings of the International Bi-Conference workshop on Agent-Oriented Information Systems 00’ (AOIS00), Stockholm (Sweden), Texas (USA). Tim, F. & Vile, A. (1999). Semiotics for E-Commerce: Shared Meanings and Generative Futures. Proceedings of the BIT'99 Conference, Manchester Metropolitan University, UK, 3rd & 4th November. Wooldridge, M., Jennings, N. R. & Kinny, D. (2000). The Gaia Methodology for Agent-Oriented Analysis and Design. Journal of Autonomous Agents and Multi-Agent Systems, 3 (3), pp. 285 – 312.