THE NEGOTIATION ANALYSIS PATTERNS _______________________________ Copyright © 2003, Hamza, and Fayad. Permission is granted to copy for the EuroPLoP 2003 conference. All other rights reserved. E9-1 THE NEGOTIATION ANALYSIS PATTERN Haitham Hamza1, and Mohamed E. Fayad2 1Computer Science and Engineering Dept., University of Nebraska-Lincoln Lincoln, NE 68588, USA Ph: +1 402 4729492 [email protected] 2Computer Engineering Dept., College of Engineering, San José State University One Washington Square, San José, CA 95192-0180 Ph: +1 408 924-7364, Fax: +1 408 924-4153 [email protected] ABSTRACT Negotiation is a general concept that has wide range of applications that span various contexts. This paper introduces the Negotiation analysis pattern. This pattern aims to provide a model that analyzes the core concept of the negotiation independent of any application. In order to achieve this goal, Negotiation pattern is built based on the concepts of Stable Analysis Patterns we have introduced before in [2, 3,4]. The paper provides detailed documentation of the proposed pattern. In addition, it demonstrates the usage of the pattern through two examples. SOFTWARE STABILITY AND STABLE ANALYSIS PATTERNS Software stability [6] stratifies the classes of the system into three layers: the Enduring Business Themes (EBTs) layer, the Business Objects (BOs) layer, and the Industrial Objects (IOs) layer. Each class in the system model is classified into one of these three layers according to its nature. Figure 1 depicts the three layers of software stability model. EBTs are the classes that present the enduring and basic knowledge of the underlying industry or business. Therefore, they are extremely stable and form the nucleus of the SSM. BOs are the classes that map the EBTs of the system into more concrete objects. BOs are tangible and externally stable, but they are internally adaptable. IOs are the classes that map the BOs of the system into physical objects. For instance, the BO “Agreement” can be mapped in real life as a physical “Contract”, which is an IO. The detailed characteristics of EBTs, BOs, and IOs and useful heuristics and examples of identifying these concepts in real applications can be found in [5,7,8]. By applying stability concepts to the notion of analysis patterns we introduced the concept of Stable Analysis Patterns [2,3,4]. The idea behind stable analysis patterns is tanalyze the problem under consideration in terms of its EBTs and the BOs with the goal of increased stability and broader reuse. By analyzing the problem in terms of its EBTs and the BOs, the resultant pattern models the core knowledge of the problem. The goal ofTHE NEGOTIATION ANALYSIS PATTERNS _______________________________ Copyright © 2003, Hamza, and Fayad. Permission is granted to copy for the EuroPLoP 2003 conference. All other rights reserved. E9-2 this concept is stability. As a result, these stable patterns can be used to model the same problem whenever it appears. Figure1. Software stability concepts layout CONTEXT In our every day life, there are various situations where negotiation usually can place. For instance, buying or selling usually involves some sort of negotiation (e.g. buying or selling a home or a car). In software systems, negotiation appears frequently in the development of different applications. For instance, developing software for online auctions and shopping might involve the negotiation of the price and/or the negotiation of different product aspects. More technically, negotiation is an essential part in the development of next generation Web-based devices and appliances. Today, devices that need to access the Web diverge greatly in their capabilities, making it highly desirable for the same resource to be available in several different representations (different languages for example). Negotiation algorithms play a fundamental role in aiding servers to decide which representation of a document a device should be given. In this case, the browser (or the client agent) will indicate its preferences by including a header in the request. PROBLEM The fact that negotiation concept does span a wide range of spectrum of heterogeneous applications, along with the fact that the negotiation concept itself does not change whenever it appears, both makes the development of a model that captures the core knowledge of the negotiation concept both desired and challenging. Developing such generic and accurate model is not easy and this leads to the main question: How can we build a negotiation model that can be used to model the negotiation problem in any application? Forces Negotiation pattern should resolve the following forces: • Negotiation spans many applications that are completely different in their natures. • The Negotiation process can take place between two or more persons, between persons and organizations, or between two non-human entities; in each case, the Stable Base Unstable Leafs- IOs Layer System Core Knowledge- EBTs Layer Concrete Objects- BOs LayerTHE NEGOTIATION ANALYSIS PATTERNS _______________________________ Copyright © 2003, Hamza, and Fayad. Permission is granted to copy for the EuroPLoP 2003 conference. All other rights reserved. E9-3 negotiator structure is completely different. How can we handle these different structures using a single model? • The Negotiation entity can be an organization consisting of many persons, each having a role in the negotiation process. For instance, there can be one individual who is responsible for negotiating financial issues, another who is responsible for negotiating issues related to management, and so on. Therefore, our pattern should be flexible enough to handle different negotiator structures. • Negotiation can be conducted through one or more media either simultaneously or consecutively; thus, the pattern should handle the use of multiple media. • Negotiation can be performed on one or more affairs at the same time. For instance, negotiation that takes place in the buying and selling context usually involves more than one subject to be negotiated. For example, in buying a car, one can negotiate the price, the warranty, and so on. Therefore, the pattern should be flexible enough to handle such situations. • The ultimate goal of any negotiation is to reach an agreement between the negotiators. However, the nature of this agreement varies tremendously from one application to