Information and Software Technology 46 (2004) 219–227 www.elsevier.com/locate/infsof
M-UML: an extension to UML for the modeling of mobile agent-based software systems Kassem Saleh*, Christo El-Morr Department of Computer Science, American University of Sharjah, P.O. Box 26666, Sharjah, United Arab Emirates Received 30 December 2002; revised 29 June 2003; accepted 22 July 2003
Abstract The Unified Modeling Language (UML) is a language for the specification, visualization, and documentation of object-oriented software systems [The Unified Modeling Language User Guide, 1998]. However, UML cannot describe in an explicit manner the mobility requirements needed for modeling mobile agent-based software systems. In this paper, we present M-UML, our proposed extension to UML covering all aspects of mobility at the various views and diagrams of UML. The use of M-UML is illustrated using a simple mobile voting system example. q 2003 Elsevier B.V. All rights reserved. Keywords: Language extension; Mobile agents; Mobility requirements; Unified Modeling Language
1. Introduction The agent mobility paradigm became feasible due to the advances in process migration, remote evaluation, distributed object computing and mobility [2]. Mobile agents are mobile objects or programs that carry executable code and data within themselves. They have several features that help them achieving their goals or business functions such as negotiating, and ordering. Intelligent agents deal with new situations for automatic problem solving and learn from past experience. They present several advantages since they are persistent and continuously running. They also reduce traffic on the network significantly since computation, encoded in the mobile agent, is brought to data rather than data to computation. In fact, there are very clear and obvious benefits of mobile agents such as offloading the network communications links, freeing local computing resources, and achieving fault-tolerance by migrating to different network nodes. However, to achieve mobility, there were many important problems to address, such as, among other things, trusting agent software, trusting remote software and * Corresponding author. Tel.: þ 971-6585555; fax: þ 971-65858581. E-mail address:
[email protected] (K. Saleh). 0950-5849/$ - see front matter q 2003 Elsevier B.V. All rights reserved. doi:10.1016/j.infsof.2003.07.004
environment, the degree of autonomy we give them, faulttolerance vis-a`-vis node failures, agent failures or communication failures. In electronic business, the use of modeling tools to describe business processes has a decisive impact on the success of the business implementation. Furthermore, mobile agents are very useful for performing electronic business functionalities [3] making the need for mobile agents modeling tool, like UML, crucial and highly beneficial. Studies on the use of UML in the modeling of mobile agents are rare and limited in extent. Klein et al. [4] proposed an extension to UML for mobile agents. However, their approach is limited to a specific agent platform and to specific class of mobile agent applications. Moreover, they do not provide mobility description for all views and aspects of systems, hence not covering all UML diagrams. Bauer et al. [5] introduce Agent UML for specifying multiagent interactions. In Agent UML, a new diagram type called protocol interaction diagram is developed. However, this agent-based extension did not include aspects of mobility. Also, Baumeister et al. [6] introduce an extension to the Activity Diagram (ACD) to model mobile systems. Their extension includes the introduction of two variants of ACDs for modeling mobility: a responsibility-centered variant that focuses on the actor performing the action, and a locationcentered variant that focuses on the topology of locations at
220
K. Saleh, C. El-Morr / Information and Software Technology 46 (2004) 219–227
which actions are taking place. In this paper, we present a complete extension of UML 1.4 standard (M-UML) to deal with all UML diagrams: Use Case, Class, Object, Statechart, Sequence, Collaboration, Activity, Component, and Deployment diagrams. We also use this model to specify a mobile electronic voting system as an example. In this work, we do not describe a methodology for using our proposed extension, however, we only provide a simple example for illustrative purposes. The development of such methodology is the subject of our future research. The rest of the paper is organized as follows. Section 2 provides some preliminary background on the Unified Modeling Language (UML), and on mobile software agents and their applications. In Section 3, we introduce the Modified UML and we illustrate its use to model a simple mobile agent application. In Section 4, we conclude and outline our future work.
2. Background In this section, we provide some background information on the Unified Modeling Language (UML 1.4) standardized by the Object Management Group (OMG), and mobile software agents and their applications in various domains. 2.1. UML in brief The UML is a de facto software industry standard modeling language for visualizing, specifying, constructing, and documenting the elements of systems in general, and software systems in particular [1]. UML has a well-defined syntax and semantics. It provides a rich set of graphical artifacts to help in the elicitation and top – down refinement of object-oriented software systems from requirements capture to the deployment of software components. In UML, systems can be modeled by considering three aspects, namely, the behavioral, structural and architectural aspects. Each aspect is concerned with both the static and dynamic views of the system. The static view represents a projection onto the static structures of the complete system description. However, the dynamic view represents a projection onto the dynamical behavior of the system. Finally, views are communicated using a number of diagrams containing information emphasizing a particular aspect of the system. In the following, we describe the various aspects, views and diagrams, and their relationships. 2.1.1. Aspects Three aspects of systems can be recognized, namely, the behavioral, structural and architectural aspects. The behavioral aspects involve the functionalities provided by the system (static behavioral aspects) and their associated interactions, their timings and their orderings (dynamic behavioral aspects). The structural aspects involve the class structures of the object-oriented software and their
interrelationships (static structural aspects), and the algorithmic details of objects life cycles and their interactions (dynamic structural aspects). Finally, the architectural aspects are related to the deployment and distribution of software and hardware across the various distributed system components. 2.1.2. Views Aspects of systems are covered by various static and/or dynamic views, namely, the use case, design, process, implementation and deployment views. The Use Case view focuses on the behavioral aspects of a system. Primarily, it reflects the user’s concerns and requirements. This view considers the system as a blackbox. Usually, users, testers and requirements analysts are interested in this view. The Design and Process Views are the concern of the development team including the analysts, designers and implementors. They describe both the static and dynamic structural aspects of the system. The Design View is concerned with objects, classes and collaborations, while the Process View is concerned with software architecture issues such as concurrency, multithreading, synchronization, performance and scalability issues. The Implementation View describes the files and components needed to assemble and release the system. Finally, the Deployment View describes the ways to distribute, deliver and install the system components and files across the distributed nodes of the system. 2.1.3. Diagrams A diagram contains model elements such as classes, objects, nodes, components, and relationships, described by graphical symbols. Moreover, a diagram can be used to describe certain system aspects at different levels of abstraction. For example, a state diagram can describe system-level input/output interactions, and can also be used to show state changes of a particular system object across multiple use cases. The nine diagrams in the UML are briefly described below. (1) Use Case Diagram (UCD): This diagram describes the functions of a system and its users. It shows a number of external actors and their connection to the use cases representing the services provided by the system. Use cases can be inherited by another use case, allowing reusability of use cases. Also, use cases can be associated using ‘use’ relationship, allowing the modularization of use cases. Similarly, use cases can be associated with the ‘extend’ relationship to deal with certain exceptional or abnormal conditions or situations. This diagram is used to model the static behavioral aspects of the use case view of the system to model. (2) Class Diagram (CLD): This diagram shows the static structure of classes and their possible relationships (i.e. association, inheritance, aggregation and dependency) in
K. Saleh, C. El-Morr / Information and Software Technology 46 (2004) 219–227
the system. This diagram is used to model the static structural aspects of the Design and Process Views of the system to model. (3) Object Diagram (OBD): This diagram is a variant of a CLD and uses almost identical notation. An OBD can be an example of a CLD that shows possible instantiations of classes during system execution. This diagram is used to model the static structural aspects of the Design and Process Views of the system to model. (4) Statechart Diagram (STD): This diagram describes the possible behavior of an object using state changes. It can also be used as a system level diagram showing system state changes during the operation of the system. Therefore, this diagram can be used to model both the dynamic behavioral aspects of the use case view, and the dynamic structural aspects of the Design and Process Views of the system to model. (5) Sequence Diagram (SQD): This diagram shows the interactions between number of objects and their time ordering. In other words, this diagram describes a scenario involving various interacting objects. This diagram can be used to model the dynamic behavioral aspects of the use case view if the interacting objects are interface objects or actors. However, if the interacting objects are internal ones, this diagram would be then used to model the dynamic structural aspects of the design view of the system to model. (6) Collaboration Diagram (COD): This diagram shows the objects and the messages they exchange. Messages are numbered to provide a time ordering of the message. Similar to SQDs, a COD can be used to model both the dynamic behavioral aspect of the use case view, in addition to the dynamic structural aspect of the process view of the system to model. It is worthwhile to mention here that one can easily produce a SQD from the COD and vice versa. Both sequence and CODs are also referred to as interaction diagrams. (7) Activity Diagram (ACD): This diagram shows a sequential or concurrent flow from activity to another activity. An ACD consists of action states, activity states and transitions between them, and usually spans more than one use case (or functionality). This diagram uses symbols from petri nets, flowcharts and finite state machines. Similar to interaction diagrams, an ACD can be used to model both the dynamic behavioral aspect of the use case view, in addition to the dynamic structural aspect of the design view of the system to model. (8) Component Diagram (CPD): This diagram shows the physical structure of the code in terms of code component. A component can be a source code, a binary, or executable component. A component contains information about the logical class or classes it implements, thus creating a mapping from the Design View to the Component View. A component diagram is used to model the static architectural aspects of the implementation view of the system to model. (9) Deployment Diagram (DPD): This diagram shows the physical architecture and distribution of the hardware
221
Table 1 Aspects, views and supporting diagrams in UML Aspects/views
Static view
Dynamic view
Behavioral (functional) aspects: Use Case View
Use Case Diagrams
Structural (design) aspects: Design and Process Views
Class Diagrams, Object Diagrams
Sequence Diagrams, Collaboration Diagrams, Statechart Diagrams, Activity Diagrams Sequence Diagrams, Collaboration Diagrams, Statechart Diagrams, Activity Diagrams
Architectural aspects: Implementation View, Deployment View
Component Diagrams, Deployment Diagrams
and software components in the system. A DPD is used to model the static architectural aspects of the deployment view of the system to model. Table 1 summarizes the aspects, views and their supporting diagrams in UML. For a complete tutorial on UML the reader can refer to Refs. [1,7]. 2.2. Mobile software agents Software agents and their use in various application areas such as electronic commerce have been studied extensively in the literature [8 – 10]. These agents are personalized, continuously running and semi-autonomous programs to which people or other programs may delegate a task automating part of a business process of varying complexities and application domains. Mobile agents possess many characteristics, for example they are autonomous since they can chart their working plans and decide when to leave a given computer and where to go next. They are also persistent or temporarily continuous since their lifetime may extend beyond that of their creator. Intelligent agents are adaptive and able to learn from their past experiences, i.e. from the user demands, choices and tastes. In addition they are flexible, as the user can personalize them to meet his/her own criteria and preferences, therefore their working plans (behaviors and actions) are not scripted (i.e. hardcoded). Also, agents are reactive, in fact they respond in a timely fashion to new conditions, incoming requests or changes in their environment. In addition to being reactive, they are active/proactive; they have a mission to accomplish and are taskoriented. Finally they are mobile; they are able to move from one node to another on a network until they fulfill their prescribed mission. Such agents are used in electronic commerce where they play different functions; for instance shopping agents do price comparison between shopping portals, while other agents learn examines consumer behavior and deliver personalized services accordingly, some auction sites use intelligent agents, and some other agents were proposed to
222
K. Saleh, C. El-Morr / Information and Software Technology 46 (2004) 219–227
assist in bartering [11]. In fact, intelligent agents help in the different purchasing decisions in electronic commerce [3,9]: need identification, product brokering, merchant brokering, negotiation, purchase and delivery, and product/service evaluation. In addition, mobile agents are used in network management, load balancing, among other distributed systems applications. The growing use of mobile agents necessitated the introduction of tools for modeling and developing mobile agent applications. Mobility is considered one of the important and advanced elements of the object model, such as the one existing in the Java programming language [12,13].
Table 2 Summary of M-UML Diagrams (a)
3. Mobile UML by example In this section, we describe the extensions made in each of the UML diagrams to allow the explicit representation of the mobility aspect. We first introduce informally our mobile system we want to model. Then we introduce our modifications to the UML. 3.1. Example: a mobile voting system A mobile voting system (MVS) consists of three interacting agents, the Vote Collector (VC), the Vote Manager (VM) and the Voters. The VC is a mobile agent mandated by a stationary VM agent to collect votes from stationary voting agents (VOs). The system can be expanded to have more VMs and more VCs dealing with one VM. First, VOs have to register themselves with their assigned VM and should instantiate their stationary agent with their voting choice after receiving the list of candidates from the VM. On election time, the VCs will contact their respective VMs to get a list of voters. Each VC will then log this list with a stationary logger agent and then visit the VOs on their list to get their votes. Once done, the VCs will return back to their base station reporting to the VM the results of the vote. For simplicity, we are not dealing here with reliability and security issues. For a reference on issues of security in mobile agent systems, the reader can refer to Ref. [10]. Parts of the MVS is specified in the following section to illustrate the use of M-UML. 3.2. M-UML In this section, we describe M-UML by going through each of the UML diagrams and explaining the modifications and extensions needed to describe the mobility aspects of the example voting system to model; Table 2 summarizes mobility extensions proposed in this section. 3.2.1. Use Case Diagram A UCD encapsulates actors and use cases. Actors are external entities interacting with the system to model
(b)
K. Saleh, C. El-Morr / Information and Software Technology 46 (2004) 219–227
223
3.2.2. Statechart Diagram
Fig. 1. Use Case Diagram.
through use cases. An actor can be a software agent interacting with the system. A mobile actor is a mobile software agent that may interact with the system while at a platform away from the one at which the agent was created (i.e. the base platform). The functionality of a system or subsystem to model is described by a group of use cases. A Use Case represents a functional requirement that may involve one or more interacting actors. A mobile Use Case represents a functional requirement that involves one or more mobile actors. Therefore, at least one mobile actor is involved in a mobile use case. A mobile agent-based software system contains both mobile and non-mobile use cases. Fig. 1 shows a UCD of the MVS containing one mobile actor and three mobile use cases. In this figure, we have a mobile actor Vote Collector and a non-mobile actor Voting Manager both interacting through the mobile use case GetVotersList. Similarly, the VC is interacting with the VO through the mobile use case GetVote. Also, the VC is interacting with the Logger through the mobile use case LogList.
An STD is a UML diagram that consists of states and transitions linking pairs of states. Normally, an STD describes the behavior of an actor in terms of state change. An actor or object can be in a particular state at a given time. A mobile state is a state reachable while the actor or object is away from its base platform. A mobile state carries a box (M). A unidirectional link emanating from one state, the source state, and reaching another state, the sink state, is called a transition. A mobile transition is a transition linking two states that are reachable by an agent while at two different platforms. Therefore, we may have a non-mobile transition linking two mobile states, a mobile transition linking a mobile state to a non-mobile state or vice versa, and a mobile transition linking two mobile states. Mobile transitions carry a box (M). However, if an agent can reach a state while it is either at its base or away, that state will carry a dashed box (M). Similarly, if a mobile agent reaches a state while interacting remotely with another agent, the transition will carry box (R). Finally, a transition is labeled with the stereotype p agentreturn q if it corresponds to the return of the agent to its base while changing its state. Fig. 2 shows a STD containing both types of states and transitions in different combinations. The figure shows a part of the state behavior of the VC mobile agent/actor. At its base platform, the agent receives the message StartVotingProcess and moves from the state ReadyToMove (RTM) to the state VotingManagerReached (VMR), at which the agent is already at a different platform. At VMR, the agent sends a remote Log message to the Logger and then sends a GetVotersList message to the VM and moves to the WaitForList (WFL) state. Both VMR and WFM states are mobile states, and the transition from RTM to VMR states is a mobile transition. At WFL, the VC receives from VM the message VotersList and moves to the platform of the first
Fig. 2. Statechart Diagram of the VC.
224
K. Saleh, C. El-Morr / Information and Software Technology 46 (2004) 219–227
VO on the voters list while, changing its state to WaitForVote (WFV). 3.2.3. Sequence Diagram An SQD is one kind of interaction diagrams that shows the interactions among agents while time progresses. Time is represented by a vertical timeline for each agent. An interaction is represented by an arrow starting from the initiating agent directed to the receiving agent. If the initiating agent is interacting while not at its base platform, the timeline from the time this interaction occurs to the time the agent returns to its platform will be filled with ‘M’. An interaction emanating from that agent’s timeline is called a mobile interaction. A mobile interaction that implies two agents located on the same platform is labeled with the stereotype p localized q . However, a mobile interaction that implies a mobile agent and the two interacting agents are not located on the same platform will hold a box (R) at the intersection between the timeline of the initiating agent’s platform and the interaction. A dashed line on the SQD is used to trace the source platform of a mobile agent initiating either a localized or remote interaction. This means that mobile interactions need not be co-located (i.e. labeled with p localized q ). For example, a mobile agent may move to a remote platform and starts to interact with other remote agents. Finally, the return of the agent to its base is represented by a directed arrow stereotyped with p agentreturn q . Fig. 3 shows a SQD involving mobile and both p localized q and remote interactions. The VC sends a local message GetVotersList to the VM. Once VC received the voters list, it sends a remote log message to a remote logger agent. Then the VC moves from the VM platform to a Voter (VO) agent platform on its voters list. The mobile VC sends a local message GetVote and moves on to the next voter after receiving the vote. Finally, after getting the vote from the last VO agent, VC returns to its base platform.
Fig. 4. Collaboration Diagram.
3.2.4. Collaboration Diagram A COD is one kind of interaction diagrams that shows the behavior of interacting objects using a sequence of
exchanged messages. The static relationship among objects is well defined. Therefore, a COD shows both structural and behavioral properties of inter-object interactions. A COD contains objects (or class instances) and lines connecting pairs of interacting objects or agents. Each interaction is labeled by the message sequence number, the message identifier, and an arrow indicating the direction of the message. Functionally, both collaboration and SQDs are equivalent. Consequently, given a SQD, we can derive the equivalent COD and vice versa. If a mobile object participates in the interaction, a box (M) will be added to the object. If the interaction is occurring at the same platform, the interaction line will carry the stereotype p localized q . However, if the interaction involves two remote agents while one or both are away from their base platform, the interaction line will carry the box (R). A self-loop interaction line carrying the stereotype p agentreturn q at a mobile object represents the return of the mobile object to its originating platform in the particular order given by the sequence number attached also to the interaction. Fig. 4 shows a COD involving mobile agents, both in remote and localized interactions. The first and second interactions are localized interactions. The third interaction in the diagram shows that at VM’s platform, the VC, a mobile object, is remotely interacting with the logger. This COD is equivalent to the SQD in Fig. 3. The fourth interaction shows the VC moving to VO’s platform to interact locally with a voter VO. Finally, the fifth interaction shows the VC returning to its originating platform.
Fig. 3. Sequence Diagram.
3.2.5. Activity Diagram An ACD shows the control flow between actions or complex actions called activities. It is basically a blend of finite state machines/statecharts and petri nets syntax and semantics. However, unlike a statechart, the states representing the activities in an ACD may normally span more than one object/agent. An ACD is able to model both the sequential and parallel flow among actions and activities involved in the modeling of a use case. Moreover, an action is a basic atomic computational step, unlike an activity which can be further described by another ACD hence creating a hierarchy of ACDs. Swimlanes can also be used to show the agent involved in performing the action or
K. Saleh, C. El-Morr / Information and Software Technology 46 (2004) 219–227
activity. A mobile action or activity involves at least one mobile agent executing at a different platform than its originating platform. A mobile use case involves one or more mobile actions or activities. If the action/activity is executed by an agent outside its originating platform, then this mobile action/activity is represented by an oval with a box (M) attached to its top left corner. Also, if the action is triggered (requested) by a mobile agent, this mobile action will carry a dashed box (M). However, if this mobile action/activity interacts with a remote agent, it will carry the box (R) instead. The return of an agent to its originating platform is represented by a mobile action stereotyped with p agentreturn q . Finally, to explicitly specify the location at which a mobile or remote action performed by a mobile agent is occurring, the action is stereotyped with p location ¼ agent q . For example, both the remote action RequestLogList and the mobile action RequestList carry the stereotype p location ¼ Manager q . In summary, the diagram will show, in addition to the sequencing of actions/activities, the relative placement of the agents while performing those actions/activities. This extension to the ACD blends both the location-centered and the responsibility-centered extensions proposed in Ref. [6]. Fig. 5 shows the ACD involving mobile actions/activities that are partially or completely performed by mobile agents. For example, The RequestList activity is occurring at VM’s platform and is mobile since it involves one mobile agent (the VC). Similarly, the activity CollectVotes occurring at VO’s platform is also a mobile activity. The LogListRequest activity is a remote activity since it is occurring at the VM’s platform after the VM processes VC’s request. Finally, the activity ProvideVotersList is also a mobile activity since it involves the mobile VC agent who is receiving the voters list and will carry a dashed (M).
225
3.2.6. Class Diagram A CLD shows the static structure of the system’s software classes and describes all relationships among those classes, including the association, aggregation and generalization relationships. A mobile class is a class from which mobile objects/agents are created. A class inheriting from a mobile class inherits its mobility feature. Classes that are part of another mobile class (in aggregation relationship) are not necessarily mobile classes. Similarly, classes associated with a mobile class are not necessarily mobile classes themselves. Classes from which mobile objects are instantiated are shown with a box (M) at the top left. However, other classes that contain behavior (methods) that is affected (communicating with) by mobile objects are shown with a dashed box (M). Moreover, a class containing behavior affected by a remote mobile agent is shown with a dashed box (R). Therefore, methods invoked by a mobile agent are labeled with either (M) or (R), depending on the location of the calling mobile agent. If a class contains methods of both types, it will carry both dashed boxes (M) and (R). Fig. 6 shows a CLD involving mobile and non-mobile classes. In this figure, class VM includes the method GetVotersListðÞ which is invoked by the mobile agent of class VC, and an object instantiated from VM is not a mobile object. This is also the same for the VO, which instances are not mobile. The class hierarchy shows the association relationships between VO, VC and the VM objects. Finally, the Logger class is associated with the VC class and carries a dashed box (R) since it contains the method logListðÞ invoked remotely by a mobile object of class VC. This occurs by default when displaying the complete class hierarchy, showing non-mobile classes associated with mobile classes. 3.2.7. Object Diagram An OBD shows objects and links among them. An OBD is derived from a CLD and is based on the static structure of the model, but also shows multiple instances of some objects as illustrations or scenarios of the association relationships Objects made from a mobile class are mobile objects. Those mobile objects a considered the mobile
Fig. 5. Activity Diagram.
Fig. 6. Class Diagram.
226
K. Saleh, C. El-Morr / Information and Software Technology 46 (2004) 219–227
Fig. 7. Object Diagram.
and an executable component containing an agent that interacts with a mobile agent at the same platform, and not mobile itself, carries a dashed box (M). However, an executable component containing an agent that remotely interacts with a mobile agent, and not mobile itself, carries a dashed box (R). Similarly, any other component related to mobile agents in the system will carry the box (M). Finally, similar to a class, a component may carry more than one type of boxes. Fig. 8 shows the various components involved in the MVS example.
Fig. 8. Component Diagram.
agents in the system. Fig. 7 shows an OBD involving mobile objects. 3.2.8. Component Diagram A Component Diagram (CPD) contains components, interfaces and various types of relationships like dependency, generalization, and association relationships. Components can be executable code, web pages, documentations and library components. An executable component or a package containing mobile agent code carries a box (M),
3.2.9. Deployment diagram A DPD is useful for modeling distributed and client/server systems. The diagram shows the distribution of physical processing units or nodes and components residing on them. A mobile system includes one or more platforms or nodes at which mobile agents are created and dispatched. Such nodes will carry a box (M) at its top left corner. A node that receives a mobile agent will carry a dashed box (M) at its top left corner. Finally, a node that interacts remotely with a mobile agent will carry the dashed box (R) at its top left corner. A node may carry any combination of boxes, for example, a node may have dispatched a mobile agent (M), and can still receive other mobile agents (dashed (M)), or interact with a mobile agent at another node (dashed (R)). Fig. 9 shows the nodes involved in the MVS example.
4. Summary and future work
Fig. 9. Deployment Diagram.
In this paper, we presented M-UML, an extension to UML covering all aspects of mobility at the various views and diagrams of UML. The use of M-UML was illustrated using a simple mobile voting system example. Currently, we are in the process of developing a novel mobile agent-based bartering business model using M-UML. This process will describe the different phases inherent in the new business model. The use of M-UML will document in a precisemanner this novel model. Preliminary results were published in Ref. [15]. Moreover, we have used M-UML to describe a mobile electronic voting system [14] and a mobile agent-based game application [16]. Our plan is to continue experimenting with modeling software systems
K. Saleh, C. El-Morr / Information and Software Technology 46 (2004) 219–227
using M-UML to ensure that our current extensions are generic enough to cover a wide range of possible mobile agents application domains. Finally, we plan to develop a methodology for using M-UML in an agent-based software development process.
[6]
[7] [8]
Acknowledgements [9]
The authors would like to acknowledge the support of this research by a research grant from the American University of Sharjah.
[10] [11]
References [12] [1] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, Reading, MA, 1998. [2] D. Lange, M. Oshima, Seven good reasons for mobile agents, Communications of the ACM 42 (3) (1999) 88–99. [3] C. Wagner, E. Turban, Are intelligent e-commerce agents partners or predators, Communications of the ACM 45 (5) (2002) 84–90. [4] C. Klein, A. Rausch, M. Sihling, Z. Wen, Extension of the unified modeling language for mobile agents, in: K. Siau, T. Halpin (Eds.), Unified Modeling Language: Systems Analysis, Design and Development Issues, Idea Group Publishing, 2001, pp. 116–128, (Chapter VIII). [5] B. Bauer, J. Muller, J. Odell, Agent UML: a formalism for specifying multiagent interaction, 22nd International Conference on Software
[13] [14]
[15]
[16]
227
Engineering (ICSE), Agent-Oriented Software Engineering, Springer, Berlin, 2001, pp. 91–103. H. Baumeister, N. Koch, P. Kosiuczenko, M. Wirsing, Extending activity diagrams to model mobile systems, NetObjectDays, NODe, Erfurt, Germany, October, 2002. M. Fowler, K. Scott, UML Distilled, Addison-Wesley, Reading, MA, 1999. H. Nwana, et al., Agent-mediated electronic commerce: issues challenges and some viewpoints, Proceedings of The Workshop on Agent Mediated Electronic Trading (AMET’98), Minnesota, USA. P. Maes, R. Guttman, A. Moukas, Agents that buy and sell: transforming commerce as we know it, Communications of the ACM 42 (3) (1999). G. Vigna (Eds.), Mobile agents and security, Lecture Notes in Computer Science LNCS 1419, 1999. K. Saleh, C. E1-Morr, Specification and architecture of a mobile agent-based bartering business model, International Conference on Electronic Commerce (ICEC 2001), Austria, November (2001). K. Saleh, Java object model: elements and applications, Journal of Information and Software Technology 41 (4) (1999) 235–241. D. Wong, N. Paciorek, D. Moore, Java-based mobile agents, Communications of the ACM 42 (3) (1999) 92– 102. K. Saleh, C. El-Morr, A. Mourtada, Y. Morad, Specifications of a mobile electronic voting system and a mobile agent platform, IADIS e-Society 2003, Lisbon, Portugal, June 3–6, 2003. C. El-Morr, K. Saleh, MABASO: a mobile agent-based bartering software system, Second Proceeding of the ACS/IEEE International Conference on Computer Systems and Applications, Tunis, 2003. K. Saleh, A. Mourtada, Y. Morad, A prototype for a mobile-agent platform and a game application, Second International Conference on the Application and Development of Computer Games (ADCOG 2003), Hong Kong, China, January (2003).
