A platform independent model for the electronic marketplace domain

1 A Platform Independent Model for the Electronic Marketplace Domain Anna Queralt and Ernest Teniente Universitat Politècnica de Catalunya C/ Jordi Girona Salgado 1-3 08034 Barcelona, Catalonia, Spain [aqueralt | teniente]@lsi.upc.edu Abstract. An electronic marketplace supports interactions between multiple users for the exchange of information on products for sale or purchase. The significance of electronic marketplaces is apparent from the huge number of websites that currently provide services in almost any area one can think of. However, the absence of clear documentation on the similarities that these sites share restricts the reutilization of software for the development of new electronic marketplaces. To improve this situation, we propose a Platform Independent Model (PIM) for the e-marketplace domain that describes both the structural and behavioral properties of a generic electronic marketplace. Specific application PIMs aimed at generating different e-marketplaces can be obtained from our generic domain PIM by adapting it to each of the requirements of the application. In this way, reutilization of our domain PIM contributes to a reduction in the cost and time involved in the development of new electronic marketplaces. Keywords: Platform Independent Model, Model Driven Architecture, Unified Modeling Language, domain analysis, domain model, e-marketplaces. 1 Introduction Electronic commerce is used to share business information, maintain business relationships and conduct business transactions via a telecommunications network [3]. Electronic marketplaces provide information on products for sale or purchase and support the negotiations conducted to agree the price of the products being traded. In general, products are classified according to several categories that can be used to distinguish the particular market being addressed. Thus, a real-estate marketplace is associated with flats, apartments or offices; an automobile marketplace is associated with trucks, cars or motorbikes; etc. Moreover, negotiations are usually performed through different types of auctions that allow different business objectives to be achieved. Trading on the Internet allows a larger number of buyers and sellers to be reached than do more traditional modes of communication. Moreover, electronic business transactions may be settled at a much lower cost since they do not require human intermediaries or physical premises for the marketplace. This situation gives an idea of the current importance of electronic marketplaces and the size of the effort that is being devoted to their development. Hundreds of electronic marketplaces are currently found on the Internet (see www.internetauctionlist.com for a possible list). Among the most representative sites are eBay, OnSale and Amazon, 1 which allow items to be bought and sold in a broad range of categories and through the use of several types of auctions. The growing importance of electronic marketplaces has also been highlighted by other authors [1, 6, 15]. In general, electronic marketplaces differ in the geographical area that they serve, the kind of services they provide, the type of items they handle and the types of auctions considered. However, all of them share several features regarding both the information they deal with and the functions they provide. Unfortunately, the existing similarities between different electronic marketplaces have not been well documented. Consequently, we cannot take advantage of these similarities for the development of new electronic marketplaces. To improve this situation, we propose a Platform 1 http://www.ebay.com, http://www.onsale.com, http://www.amazon.com/auctions 2 Independent Model (PIM) for the electronic marketplace domain that describes both the structural and behavioral properties of a generic electronic marketplace. In the context of Model Driven Architecture (MDA), a PIM is a model used to describe a software system that supports a business and is independent of the final implementation platform [11, 22]. The PIM we propose is a conceptualisation of the electronic marketplace domain. As we will show, specific application PIMs, which will result in different e-marketplaces, can then be obtained from our generic domain PIM by adapting it to the requirements of each application. We will see that little effort is needed to obtain a specific PIM for each application. Accurate and precise conceptual modeling is an essential premise for the correct development of an information system and is particularly important in the context of MDA. Generic domain assets can facilitate this difficult and time-consuming task by increasing reusability (and therefore the quality of the resulting system) during software development. In this way, knowledge can be reused instead of software [4]. Our domain PIM is specified in Unified Modeling Language (UML) and Object Constraint Language (OCL), since the combination of the two allows for PIMs that are consistent, full of information and precise, and probably represents the best way to develop a high-quality and high-level PIM [11]. In order to obtain the domain knowledge needed to build our generic PIM, we reengineered several existing applications, abstracted their requirements and studied their commonalities and variabilities, as proposed by Mili et al. [16]. Thus, some well-known e-marketplaces and auction-sites were our main source of information. In particular, we considered eBay, OnSale and Amazon, as well as the job search site Monster. Our domain PIM covers the most important function of electronic marketplaces, which is to match buyers and sellers [1]. This function is traditionally separated into three main activities, namely determining product offerings, search and price discovery. As far as price discovery is concerned, our domain PIM admits a fixed-price policy as well as all possible types of auctions and their variations, as defined elsewhere [10, 12]. Hence, we show that our domain PIM is general enough to be used for the definition of an application PIM for a new electronic marketplace, simply by tailoring it to the particular needs of its users and owners. In short, this paper makes three main contributions: • First, we propose the use of domain PIMs at the initial stages of the MDA development process to capture common aspects of a certain kind of application. The importance of PIMs in the context of the MDA has already been stated elsewhere [11] and the use of domain PIMs helps to significantly increase both the productivity and the accuracy of the software systems developed. • Second, we define a domain PIM for electronic marketplaces that describes both the structural and behavioral properties that a generic marketplace should fulfill. Such domain PIM represents a step forward in the development of a repository of conceptual schemas for domains, which is currently an important area of research with many open questions [17, 20, 28, 30]. • Finally, we show how specific application PIMs can be built using our domain PIM as a starting point. In this way, and mainly because of the reutilization of an existing solution, our domain PIM contributes to reducing cost and time, while increasing the quality of the resulting system for the development of new electronic marketplaces. The next section discusses the role of domain and application PIMs in the MDA. Section 3 presents our domain PIM for the electronic marketplace domain. Section 4 shows how to obtain an application PIM from our domain PIM. Section 5 compares this work with previous studies of electronic marketplace development. Finally, in Section 6 we present our conclusions and discuss future work. 2 Domain PIMs and Application PIMs in the MDA The Model Driven Architecture (MDA) is based on the well-known idea of separating the specification of the operation of a system (i.e. the business and application logic) from the details of the way that system uses the capabilities of its platform (i.e. the underlying platform technology). Key 3 to the MDA is the importance of models in the software development process and the automatic transformations that may be performed among them. Software development in the MDA starts with a Platform Independent Model (PIM), which describes a software system that supports a business, with no knowledge of the final implementation technology [11]. This model is obtained from a higher level model that describes a business or a company, independently of the software systems used therein. This is also called a Computational Independent Model (CIM), a software independent model used to describe a business as a whole. Certain parts of a business may be supported by software systems and, for each of those parts, a Platform Independent software Model (i.e. a PIM) must be defined to describe them. Since the decision of what pieces of a CIM are to be supported by a software system is always human, automatic derivation of PIMs from a CIM is not possible. Once a PIM has been defined for a software system, the next step in the MDA is to transform that PIM into a Platform Specific Model (PSM). A PSM is a model of the same system specified by the PIM that also specifies how that system makes use of the chosen technological platform [22]. Several PSMs can be obtained from the same PIM by applying mappings that take into account both the PIM for the application and the target platform. A PIM describes a particular software system, such as a specific electronic marketplace like the one of eBay or Amazon. However, all software systems belonging to a certain domain share certain assets. For example, all electronic marketplaces deal with buyers, sellers and products, and offer certain functions such as search, buy and so on. We propose the development of a more generic PIM describing the common concepts and behavior of a certain kind of application, instead of describing a specific software system. This generic model is what we call a domain PIM. A domain PIMs is obtained as a result of domain analysis, which is the activity of identifying, capturing and organizing the objects and operations of a class of similar applications in a particular domain, with the purpose of making this information reusable when creating new systems [25]. A domain PIM results in several PIMs, from which different systems are developed by means of the MDA process. From now on, to avoid ambiguities we will use the term application PIM to refer to the PIM as defined in the MDA, i.e. the PIM that describes a specific software system, and domain PIM to refer to the generic model that describes a family of software systems belonging to a domain. As we have just seen, a PSM is the result of a transformation of an application PIM. Likewise, at a higher level of abstraction, an application PIM can be seen as the result of a transformation of a domain PIM, taking into account the specific requirements of the system to be built instead of a specific platform. Thus, building an application PIM for a certain software system from a domain PIM simply consists in adapting the domain PIM to the specific requirements of the system belonging to the domain. Figure 1 shows an example of several application PIMs being obtained from a single domain PIM, similar to the way in which several PSMs are obtained from a single application PIM. In this case, multiple application PIMs for specific e-marketplaces can be obtained from an e-marketplace domain PIM. Fig. 1. An example of domain and application PIMs in the MDA The MDA software development process starts at the application level. For example, it takes the eBay PIM or the Amazon PIM from Figure 1 as a starting point and obtains the PSMs for each desired 4 platform. Our proposal consists in adding a domain PIM above the application PIMs, in this case an emarketplace PIM, which serves as a starting point to obtain the PIMs for different e-marketplace applications. As suggested elsewhere, a domain model should contain not only those assets shared by all the applications in that domain but also those elements that are shared by many of them [16]. According to this, our domain PIM for the electronic marketplace domain specifies aspects that are essential to any e-marketplace and those that we have found to be desirable despite their not being included in all the applications in this domain. Since the application PIM in the MDA is the only model that must be created by hand, domain PIMs facilitate the task of building a software system even further. If a repository of PIMs is available that covers every domain, developing a software system will simply consist in adapting the corresponding domain PIM to the requirements of the application by adding or deleting elements from the model. As a result, both the productivity and the accuracy of software systems increase significantly, thanks to the combination of domain PIMs and the MDA. The idea underlying domain PIMs is quite similar to that of analyis patterns [7, 8]. Although both of them are aimed at documenting the similarities between different applications and reduce development costs by means of a generic solution, the ways they approach this issue are quite divergent. While a domain PIM provides the specification of generic knowledge in a certain domain, an analysis pattern is aimed at representing a specific structure of knowledge encountered in different domains. Some examples are part-of relationships, the roles an object can play in different situations or the representation of ranges or quantities, which can be found in a variety of domains. For this reason, domain PIMs can take advantage of the knowledge provided by analysis patterns by incorporating them in their definition. For instance, we have used Fowler's Party pattern [8] in the definition of our e-marketplace domain PIM. This pattern is an abstraction to define persons or organizations, which serves our purpose of generalizing the concept of user. As any other analysis model, a PIM must include both the knowledge about the concepts in the domain and the functions the system has to perform. According to this, an application PIM corresponds to the analysis model of a specific software system and a domain PIM can be regarded as the one of a generic application domain. Therefore, the definition of a domain PIM in UML should include all the UML models required to define an analysis model in this language. We will mainly follow the proposal of Larman [14], who states that a UML analysis model must contain a use case model, an analysis class diagram, a system behavior model and an analysis state model. Using a combination of UML and OCL allows high-quality PIMs to be built. These PIMs are consistent, full of information and precise, and allow for a much more complete generation of PSMs and code [11]. Thus, in the specification of our domain PIM, we use plain UML for the class, use case, and statechart diagrams, and OCL to formalize integrity constraints and the preconditions and postconditions of the system operations. The use of domain PIMs of this kind facilitates the obtention of precise and unambiguous application PIMs, so the MDA can be used to generate a substantial part of the implementation from them. Once a domain PIM has been defined, it must be adapted to the specific software system to be developed. The adaptation of a domain PIM to the requirements of a specific application consists in the obtention of an application PIM by adding, deleting or modifying the elements that constitute the domain PIM: - Use cases of the use case model - Entity and relationship types, attributes and integrity constraints of the analysis class diagram - Operation contracts of the system behavior model - Statechart diagrams of the analysis state model One of the important features of Larman’s proposal is the definition of the system behavior as a ‘black box’ before proceeding to a logical design of how a software application will work. This decision has a clear impact during analysis since operations required to specify the system response to the external events are not assigned to classes but recorded in an artificial type named System. In this way, responsibilities are not assigned to objects during analysis. Moreover, we consider that the UML models of our domain PIM are non-redundant [2]. Nonredundant models contribute to the desirable properties of an information system specification and at 5 the same time facilitate software design and implementation. A UML specification is redundant when a certain aspect of the software system is defined in more than one of the UML models for analysis. Therefore, in our e-marketplace domain PIM, each aspect will be specified in exactly one of the models that compose it. We also assume a strict interpretation of the operation contracts [26]. 3 Electronic Marketplace Domain PIM In this section we specify the different models that define our domain PIM: the use case model, the analysis class diagram, the system behavior model and the analysis state model. 3.1 The Use Case Model The use case model provides an overview of the functions that must be offered by an e-marketplace. Use cases can be informally considered as possible ways in which users can employ a system to meet their goals. The use case model consists mainly of the definition of use case diagrams, which identify the main ways a user can interact with the system. Electronic marketplaces have three main functions: matching buyers and sellers, facilitating transactions and providing an institutional infrastructure that specifies the rules governing the transactions of the electronic market [1]. To perform these functions, e-marketplaces offer some basic services, such as a directory of users, product catalogues, search tools for finding products, online purchase orders and auctions, etc. A generic e-marketplace supports interactions between different users to exchange information on products that they want to sell or that they are looking for. A user can publish an announcement either to sell or buy a product. In addition, users can indicate the kind of negotiation they want to use, which may be an advertisement by means of which contact is established with interested users, a fixed-price sale or an auction. The users interested in a published product can bid for it and the system determines the winner or winners depending on the kind of announcement. An e-marketplace must also include a subsystem responsible for the management of the fees that users must pay for publishing announcements and selling products, and a method to give users an idea of the reliability of the other users of the marketplace. To facilitate both the explanation and understanding of our domain PIM, we have grouped the properties of an e-marketplace into three different subsystems: 1. Users, products and categories shows how information related to users, products and categories is stored and managed. 2. Publishing announcements supports the setting up of an announcement to sell or find a product. 3. Bidding reveals how users show their interest in the products offered in the marketplace and the way the system decides which users can or must purchase the products. 4. Reputation and fees management shows the structure that allows users to evaluate the behaviour of others in the marketplace and thus gives other participants an idea of the ease of negotiating with each other. This section also includes information on the fees that must be paid by the users for announcing and selling products and how our PIM supports them. According to this organization, the functions offered by an e-marketplace can be divided into a set of packages, shown in Figure 2 together with the actors that interact with them. 6 Announcing products Bidding and announcement closing Reputation and fees management Visitor User Administrator Announcer Users, products and categories Fig. 2. Use case packages We can distinguish four kinds of actors in an e-marketplace: − Visitors are the people not registered in the e-marketplace. They can only perform queries to the system or register as users. − Users are the people who have registered to buy products. − Announcers are allowed to sell products as well as to do everything users can. − Administrators are responsible for maintenance tasks. The package Users, Products and Categories includes the use cases regarding the management of these three entities. The use case diagram is shown in Figure 3. We have chosen self-descriptive names for the use cases so that further explanations will not be necessary in most cases. When registering a product, the announcer will need to specify its set of features and the format and the beginning and end dates of the announcement he wants to publish about the product. This is done in the use case Publish announcement in the package Announcing products. Fig. 3. Use cases for Users, Products and Categories The package Announcing products includes the use cases needed to publish, modify and delete announcements of any kind. The use cases that it includes are shown in Figure 4. Fig. 4. Use cases for Announcing products Administrator Register user List categories Visitor Relate categories Update user data User Publish announcement (from Announcing products) Register product E-marketplace <<include>> Search announcements List announcements in category Visitor Publish announcement Modify announcement Announcer E-marketplace 7 Bidding and announcement closing contains the use cases related to the actions that can be performed when an announcement is open (Figure 5). Fig. 5. Use cases for Bidding and announcement closing Finally, we have the use cases belonging to Reputation and fees management (Figure 6). Fig. 6. Reputation and fees management use cases We hope the name of the use cases is clear enough to describe, at least intuitively, their intended function. We will provide a precise definition of the behavior of some of these use cases in Section 3.3 when we present the system behavior model. 3.2 The Analysis Class Diagram The analysis class diagram describes the structural properties of the concepts in the problem domain. It consists of a static structure diagram (i.e. a class diagram) in which no operations are defined. Our goal is to define a non-redundant domain PIM for e-marketplaces. Non-redundant analysis models are achieved by specifying as many aspects as possible in the class diagram rather than defining them in the other models [2]. Therefore, the analysis class diagram is the most important part of the e-marketplace domain PIM because it contains the definition of its main aspects. There are some conditions that the information base must satisfy but that cannot be graphically specified in the analysis class diagram. We will specify these integrity constraints along with the derived information we consider necessary in natural language. We will also specify the subsystems in OCL 2.0 [23], according to the methods proposed elsewhere [18, 19]. Confirm sale List bids for a product Visitor Bid for a product Clock User Close expired announcements Place purchase bid Cancel bid Cancel announcement Close announcement <<include>> <<include>> Announcer E-marketplace List received comments Visitor See user reputation User Answer a comment Administrator Set fees Make a comment E-marketplace 8 Users, Products and Categories The users of an e-marketplace are identified by a user identifier. They also have an e-mail address and a password, as well as some personal information (name, date of birth, phone number, country, etc.). They may be either individuals or organizations. When a user registers a product in the marketplace, he becomes an announcer and must provide a credit or debit card and account information. Marketplace products are classified according to several categories. Each of these categories is usually divided into subcategories. A category is basic when it is not divided into subcategories. Products are classified into categories, and as such, they belong to all categories that are above the one they are classified in. A category may also be related to several other categories. Users may register products in several basic categories. Products are identified by a product identifier and the e-marketplace also records the date when they are registered. Moreover, additional information on products can be specified according to the category in which they are classified. The analysis class diagram shown in Figure 7 describes the information related to users, categories and products in an e-marketplace. It is followed by the required textual constraints and the definition of the derived information. Organization sector : String ... Person surname : String birthDate : Date ... /Announcer account : String ProdCat1 att1 : Type1 ... ProdCatN attM : TypeM ... ... CompositeCat Category name : String description : String charact : Set(String) {disjoint, complete} 2..* 0..1 child 2..* parent 0..1 * * relatedCat * Is related to * Product pid : String date : Date 1* 1* Belongs to User userId : String email : String password : String name : String * 1* 1 Registers {incomplete} {disjoint, complete} BasicCatOffered 1 *1 * <<refines>> {incomplete} : Category {disjoint, complete} Fig. 7. Analysis class diagram for Users, products and categories Integrity constraints - Users are identified by userId context User::UniqueUserId():Boolean body: User.allInstances()->isUnique(userId) - Products are identified by pid context Product::UniquePid():Boolean body: Product.allInstances()->isUnique(pid) - Categories are identified by name context Category::UniqueName():Boolean body: Category.allInstances()->isUnique(name) - A category cannot be related to itself context Category::NotSelfRelated():Boolean body: self.relation->excludes(self) - A category cannot be (recursively) a child of itself context CompositeCat def: isDescendant(c1:Category, c2:Category):Boolean = c2.child-> includes(c|c=c1 or isDescendant(c1,c)) context CompositeCat::NotSelfDescendant():Boolean body: not isDescendant(self, self) - A user can not be under 18 context Person::AdultUser():Boolean body: today()-birthDate >= 18 Derivation rules - An announcer is a user who has registered at least one product 9 context Announcer::allInstances():Set(Announcer) body: User.allInstances()->select(u | u.product->notEmpty()) The classification of users into organizations and individuals corresponds to the party pattern [8]. We have used the term User instead of party since we believe it is more appropriate in our context. A user is considered to be an Announcer when it has registered at least one product. Clearly, the class Announcer is derived since its instances can be computed from other elements in the schema. Information relating to basic categories can be regarded as model as well as metamodel information since a different subclass ProdCatI will be available for each instance of Category. This can be specified in UML using a powertype [29], which is a metaclass (Category in our example) whose instances are subtypes of a given class (Product). Products are related to the category they are classified in and to the user who has registered them. Offered products, i.e. products that a user wants to sell, can only be related to basic categories since they are specific products owned by the announcer. Requested products, i.e. products that a user is looking for, are related to any kind of category (basic or not). For the sake of simplicity, we assume that a requested product will have the same attributes as an offered product in the same category. Announcing Products An announcement may be dealt with in two different ways according to the kind of product being announced: either as an offer or as a request. In the first case, the user publishes the announcement to try to sell a product, whereas in the second he simply publishes the announcement to find sellers of a product with the specified characteristics. In general, a product will be announced several times if it is not sold (bought) the first time it is published. Users can increase the visibility of their announcement by upgrading, which may involve using a bold font, highlighting the title, etc. When users want to offer a product, they can either publish an advertisement or a sale announcement. In the first case, they simply wait for interested users to make contact and then decide which of them to sell the product to, while in the second the decision of whether to sell the announced product or not is taken automatically by the e-marketplace. There are two different kinds of automatic treatment of sales: fixed-price sales and auctions. A product can be offered at a fixed price and auctioned at the same time. There are several types of auction, each one having its own rules regarding the evaluation of bids and the closing of the auction. Here we present the distinctive characteristics of each of them [12, 13]: − Open cry auctions. Each bid must be greater than the previous ones, which are available to the users of the marketplace at any time. The auction can either finish when the seller specifies or when new bids are not received for a certain period of time, or whichever happens first. The user who wins the auctioned product is the one who has placed the highest bid. − Sealed bid auctions. Before the auction begins, the seller specifies one or more deadlines at which he will broadcast the highest bid received so far. Meanwhile, bids are kept secret from the interested users, and when a deadline arrives, the seller decides whether to continue with the auction or close it. The winner is the highest bidder in the last round. − Multiple item auctions. Here, several items are auctioned. Each interested user specifies the number of items desired and indicates the price he is willing to pay per item. The auction can finish either at the time specified by the seller, when new bids are not received for a certain period, when there are no items remaining, or whichever happens first. The winners will be the highest bidders such that the sum of the quantities they demand is not greater than the quantity of items offered. It may happen that the lowest winning bid receives fewer items than the quantity requested, since only as many items as specified in the announcement are offered. − Dutch auctions. In this case, one or more items are on sale. Sellers specify a high initial price at which they expect no buyers and reduce it while there are no bids for the item or items. In this case, a bid is an acceptance of the current price offered by the seller. When there are several items on sale, users specify in their bids the number of items they want to purchase at the price 16 Reputation and fees management Since the products offered in e-marketplaces usually belong to anonymous users, the rest of users can have problems in relying in the sellers. The same happens to sellers, who can never be sure if they will be paid by the winner or winners of the item. For these reasons, most e-marketplaces include a system to manage the reputation of its users. Once an announcement is closed, both the announcer and the winner or winners can express their opinion about the others’ behaviour regarding the transaction and evaluate their degree of satisfaction. Each comment received can be responded by the alluded in order to apologise or defend himself in front of the accusation. These responses will not have an associated rating, so for a given transaction, a user will only be evaluated once by the same user. The sum of all the ratings received by a user will give the others an idea of the convenience of negotiating with him. An additional aspect that most marketplaces have in common is the fees charged to their announcers. There are three kinds of fees: the ones charged for publishing an announcement, the ones charged for the upgrades chosen and finally those charged to the announcer when his products are sold. The amount to pay for all these fees can depend on the category of the product, the kind of announcement and the price of the product. We can see the representation of all this information in Figure 10. As usual, the additional integrity constraints needed are specified below. Fig. 10. Reputation and fees management. Analysis class diagram. Integrity constraints - Users can only make comments about sale announcements context Comment::validAnnouncement():Boolean body: self.closed.oclIsTypeOf(Sale) - A comment can only be emitted by the announcer or by the winners of the product to which it refers context Comment::validEmitter():Boolean body: self.user = self.closed.product.user or self.closed.oclAsType(Sale).winners->includes(self.user) - If the author of a comment is the announcer, the receiver must be one of the winners context Comment::emitterAnnouncerReceiverWinner():Boolean body: (self.user = self.closed.product.user) implies (self.closed.oclAsType(Sale).winners-> includes(self.user)) - If the author of a comment is one of the winners, the receiver must be the announcer context Comment::emmitterWinnerReceiverAnnouncer():Boolean body: (self.closed.oclAsType(Sale).winners->includes(self.user)) implies (self.user = self.closed.product.user) - Answers to comments cannot have a rating Publication Upgrade name : UpgradeType Closing Time ... User ... * ** * Category ... Fee from : Money to : Money value : Real kindOfAnnounce : AnnounceType year : Natural 0..1 *0..1 * For Closed ... Comment text : String rating : Integer * 0..1 +response * RespondTo +responds 0..1 1 * +receiver 1 * DestinatedTo 1 *1 * About AnnounceTy pe Request Adv ertisement FixedPrice OpenCry SealedBid Multiple Dutch <<enumeration>> {disjoint, complete} 17 context Comment::responsesWithoutResponse():Boolean body: self.answer->notEmpty() implies self.comment->isEmpty() - A user can only rate a comment regarding to a certain announcement once. context Closed::oneRatingPerUser():Boolean body: self.comment->select(c| c.comment->isEmpty())-> isUnique(User) - There can not exist two publication fees referring to the same interval of prices, kind of announcement, category and year. context PublicationFee::uniquePublicationFee():Boolean body: PublicationFee.allInstances()->forall(f | f <> self implies f.from <> self.from or f.to <> self.to or f.kindOfAnnounce <> self.kindOfAnnounce or f.category <> self.category or f.year <> self.year ) - There can not exist two upgrade fees referring to the same upgrade, interval of prices, kind of announcement, category and year. context UpgradeFee::uniqueUpgradeFee():Boolean body: UpgradeFee.allInstances()->forall(f | f <> self implies f.name <> self.name or f.from <> self.from or f.to <> self.to or f.kindOfAnnounce <> self.kindOfAnnounce or f.category <> self.category or f.year <> self.year) - There can not exist two closing fees referring to the same interval of prices, kind of announcement, category and year. context ClosingFee::uniqueClosingFee():Boolean body: ClosingFee.allInstances()->forall(f | f <> self implies f.from <> self.from or f.to <> self.to or f.kindOfAnnounce <> self.kindOfAnnounce or f.category <> self.category or f.year <> self.year) - All publication fees define a complete interval of prices for a given year, kind of announcement and category context Publication::completeInterval():Boolean body: let fees: Sequence(Publication) = Publication.allInstances()-> select(f| f.year = self.year and f.kindOfAnnounce = self.kindOfAnnounce and f.category = self.category)-> sortedBy(from) in Sequence{1..fees->size()-1}->forall(i:Integer | fees-> at(i).to + 0.01 = fees-> at(i+1).from) Upgrade and closing fees have analogous constraints. As can be seen in the diagram, a comment (Comment) can only be made regarding to a closed announcement. Each comment consists of the opinion of the emitter (text) and the rating (rating) he gives to the receiver, and can be responded by the alluded or emphasized by the emitter several times. On the other hand, we have that several fees (Fee) can be applied to a closed announcement. As we already introduced, the amount of a fee can depend on the price of the product (from, to), the way in which the product is published (kindOfAnnounce), the category of the product and the current year (year). There are three kinds of fees: Publication, Upgrade and Closing, each of them corresponding to the explanation already given. The fees that must be applied to an announcement can be inferred from its characteristics. 3.3 The System Behavior Model A software system maintains a representation of the state of a domain in its information base. The state of a domain at some time point is the set of instances of the entity and relationship types defined in the class diagram. When the state of the domain changes, the information base must change accordingly. A domain cannot change in an arbitrary way, and the only acceptable changes are called domain events. A domain event consists of one or more elementary changes (creation, deletion, reclassification, etc.) in the population of the entity and relationship types in the model. 18 The domain events in our e-marketplace are obtained from the use case model in Section 3.1. In general, there may be several domain events for each use case. To abstract from the way users interact with the information system, we will specify each domain event as a single system operation [21]. Each operation is precisely specified by means of an operation contract. An operation contract includes a set of preconditions, which are conditions that the state of the information base must guarantee so that the operation can be executed, and a set of postconditions. The postconditions of an operation can be defined either imperatively or declaratively [32]. We will define declarative postconditions, which specify conditions that must hold after the execution of the operation. We also assume a strict interpretation of the operation contracts [26]. For the sake of brevity, we only show operation contracts for some of the most relevant use cases. The OCL specification of these operations can be found in the appendix. The use case Publish announcement will lead to seven different domain events. One for each of the leaf subclasses of the generalization rooted at Announcement. In particular, the following contract specifies the behavior related to the publication of an Open cry auction. We assume that the product to be announced has already been registered and we can therefore use its object identifier. Similarly, we also assume that the user has logged in and the system has returned the corresponding object identifier before any operation requiring user authentication. The parameters required by the operation open-cry are the announcer, the product, the information required for all kinds of announcements (beginning, end, title, descr, photos and upgrades) and the specific information for open cry auctions (reserveP, bidIncr, iniP, priceToPay, delay and finish). Operation new-open-cry-auction(ann: Announcer, prod: Product, beginning: Time, ending: Time, title: String, descr: String, photos: Sequence(String), upgrades: Sequence(UpgradeType), reserveP: Money, bidIncr: Sequence(TupleType(from: Money, to: Money, incr: Real)), iniP: Money, priceToPay: FinalPrice, delay: Natural, finish: OpenCryEnd) Semantics Create an announcement in open cry auction format for product prod with the indicated characteristics Preconditions The announcer ann is the owner of the product prod Postconditions - An open-cry auction A with the specified information is created - A is associated with the product prod Note that since our goal is to define a non-redundant domain PIM the operation contracts must not include checking and dealing with the conditions that are already guaranteed by the constraints that are specified in the analysis class diagram. There are also three different domain events for the use case Bid for a product: place auction bid, place ad bid and place purchase bid (i.e. one for each of the subclasses of Bid). The semantics of the domain event place auction bid is defined through the operation contract below. To place an auction bid, the system needs to know the user (usr), the product he wants to purchase (prod), the price he is willing to pay for it (amount), the number of items requested (items) and whether or not the user wants to use a proxy (useProxy). The system returns the e-mail of the bidder (e-mail), the product (pid) and the amount indicated, in order to send confirmation. Operation place-auction-bid(usr: User, prod: Auction, amount: Money, items: Natural, useProxy: Boolean): TupleType(email: String, pid: String, amount: Money, items: Natural, outbid: String) Semantics Place an auction bid for the announcement prod with the specified amount, items and the option useProxy. The user usr will receive a confirmation e-mail and the user outbid will be notified of the need to bid again in order to continue in the auction, because the new amount is greater than the amount of that user. Preconditions Postconditions - A new auction bid B is created with the current time and the specified information. - B is associated with the user usr and the auction prod. - If useProxy is true and amount is the highest so far, an automatic bid with the current time and the lowest winning value is created, if possible, and associated with B. 19 - If amount is not the highest and the winning bidder uses a proxy, an automatic bid is generated for the minimum winning value (amount plus the corresponding bid increment). - If the auction is Dutch or Multiple and its finishing condition is noItems or anyOfThem and there are no items remaining after bid B, or it is Dutch, the finishing condition is reservePrice or anyOfThem and B reaches the reserve price, the auction prod is specialized into Closed. - The operation returns the e-mail of the bidder, the identifier of the product, the amount bid, the number of items requested and the e-mail of the user who has been outbid. Note that in addition to placing the specified bid, this operation must generate automatic bids when necessary and also notify the users who have been outbid. These kinds of facilities are very important in the context of e-marketplaces, since they allow users to be informed of the changes in their bids. Another important domain event in an e-marketplace is Cancel bid, which allows a user to retract a bid and be notified of the cancelation, or an announcer to cancel a bid placed for his product. The following contract specifies the behavior of this domain event. Operation cancel-bid(usr: User, bid: Bid): TupleType(email: String, pid: String, amount: Money) Semantics Cancel the bid bid and notify by e-mail the user who placed it. The notification consists of the identifier of the product (pid) and the amount bid. Preconditions - The user who cancels the bid must be the user who placed it or the owner of the product - The announcement corresponding to the specified bid is open Postconditions - The attribute isCanceled of the bid bid is set to true. - The operation returns the e-mail of the user who placed the bid, the identifier of the product announced and the amount bid. Closing an announcement is the domain event corresponding to the use case Close announcement. It allows indicating that the announcement finishes before it was scheduled to but the announcer still wants to sell the product to the current winner or winners. When an announcement ends, its current winner or winners are notified that the sale has finished and that they are the highest bidders. Its behavior is specified by means of the following contract: Operation close-announcement(usr: User, ann: Announcement): TupleType(pid: String, ann-notif: TupleType(email: String, finalPrice: Money, itemsSold: Natural, winners: Set(String)), win-notif: Sequence(TupleType(email: String, price: Money, itemsWon: Natural, ann-email: String)), bid-notif: Set(String)) Semantics Close the announcement ann published by usr and notify the cancelation to the announcer, the winners and the other bidders. Preconditions The user usr must be the owner of the announced product. Postconditions - The attribute isCanceled of announcement ann is set to true. - If ann is an auction and the reserve price has been met, or it is a fixed price sale and there is a bid for it, then the sale is accepted. - The following information is returned: product identifier, notification to the announcer (final price and number of items sold), notification to the winners (final price and number of items won) and notification to all bidders. Another interesting domain event is the one required to Close expired announcements, whose behavior is specified by means of the following contract. Operation close-expired-announcement(): Set(TupleType(ann-notif: TupleType(email: String, pid: String, finalPrice: Money, itemsSold: Natural, winners: Set(String)), win-notif: Sequence(TupleType(email: String, pid: String, price: Money, itemsWon: Natural, ann-email: String)), bid-notif: TupleType(emails: Set(String), pid: String))) Semantics Close all the announcements that have reached their end time or have fulfilled the conditions specified by the announcer. 20 Preconditions Postconditions The operation close-announcement is invoked for each open announcement that satisfies: - Auctions of type OpenCry or Multiple that have reached their end time and the finishing condition was endingTime, or have not received bids for a period longer than specified in delay and the finishing condition was noBids, or either of the two if the finishing condition was anyOfThem. - Auctions of type SealedBid that have reached their end time. - Other announcements that have reached their end time. Note that, as stated in the use case model (see Figure 5), the domain event required to close expired announcements performs the execution of several domain events close-announcement . Finally, we specify the semantics of the domain event Confirm sale, which is required to explicitly confirm a sale when the product is offered in auction format and the highest bid does not reach the reserve price once the announcement is closed. Operation confirm-sale(usr: Announcer, ann: Auction, sell: Boolean) Semantics The sale of the product announced in ann is accepted or rejected as specified by sell. Preconditions - The user usr who confirms or rejects the sale must be the owner of the product announced in ann. - The auction ann is closed. - The current price of the auction ann is below its reserve price. Postconditions The value of the parameter sell is stored in attribute accepted of the closed auction ann. 3.4 The Analysis State Model The analysis state model consists of a set of statechart diagrams that show the events that lead to changes in object states and specify the system response to these events. The state model includes a statechart diagram for each object with an important dynamic behavior. At the PIM level, statechart diagrams can be defined using a protocol state machine [24]. The behavior of each operation appearing in a protocol state machine is defined by an associated contract, rather than through action expressions for transitions. This is why our statechart diagrams remain so simple and why we do not need to specify action expressions at the PIM level. In the e-marketplace, only bids and announcements have an important dynamic behavior that requires the definition of a state diagram for each of these classes. A Bid can only be in two states: canceled or not canceled. The operation cancel-bid is responsible for this transition, as shown in Figure 11. Bid CanceledBid purchase-bid / auction-bid cancel-bid Fig. 11. Statechart diagram for Bid Figure 12 shows the statechart diagram that specifies the dynamic behaviour of an Announcement. The system operations that cause the transitions between states were defined in Section 3.3. When an announcement is created it can be Pending or Open, depending on the specified start date. From any of these states, it can be canceled by means of the cancel-ann operation. The transition from Pending to Open is performed automatically through the derivation rules that define the values of the attributes isPending and isOpen in the class diagram (see Section 3.2). Once an announcement is Open, it can be closed either manually by the announcer or automatically by the system. Both cases are included in the operation close-ann. This operation automatically accepts the sale for fixed price and auction announcements whose reserve price has been reached. When the reserve price of an auction has not been reached, the announcer can accept or reject the sale of the product. For other formats (request announcement and advertisement), there is no acceptance, since they do not require a financial transaction through the marketplace. 21 Pending Open Canceled Closed Refused Accepted cancel-ann confirm-sale[sell=false] confirm-sale[sell=true] request / advertisement / fixed-price / open-cry / sealed-bid / multiple / dutch request / advertisement / fixed-price / open-cry / sealed-bid / multiple / dutch cancel-ann close-ann close-ann Fig. 12. Statechart diagram for Announcement 4 Obtaining an Application PIM In this section we show the applicability of our proposal to a real situation. It will be seen that, taking our domain PIM as a basis, little effort is needed to obtain an application PIM for a specific emarketplace, thus reducing the development cost and increasing the quality of the resulting system at the same time. In this sense, we build a specific application PIM using the domain PIM as a starting point, adding or removing elements from it, so that the resulting model satisfies the requirements of the application to be built. In particular, we obtain the application PIM for Yahoo! Auctions 3 (which was not one of the marketplaces we considered to define our domain PIM), by gathering its requirements from an external study. The resulting diagrams could have been rearranged, especially regarding hierarchies, but we have left them unchanged so that the similarities between them and the original domain PIM can be easily identified. Yahoo! Auctions is a peer-to-peer e-marketplace, in which one or more products are either auctioned (with an open-cry policy) or offered at a fixed price. Sellers can also offer several items in the same auction (multiple auction). 4.1 Users, Products and Categories Users at Yahoo! Auctions must register in order to sell and buy products. In order to do it, they must provide some information, which may be modified later. Once they are registered, users can submit items to sell. As for categories, they are organized in a hierarchy, and this is the only relationship between them (there are not "related categories"). Users can prevent other users to participate in their auctions. This is what is called blacklist. Then, the use case diagram for this subsystem is the same as the one in figure 3, excluding the use case Relate Categories, and adding a new use case called Blacklist User. The corresponding analysis class diagram is as follows. 3 http://auctions.yahoo.com 22 Fig. 13. Adaptation of the Users, products and categories analysis class diagram to Yahoo! Auctions This diagram has been obtained from the one in figure 7, eliminating class Organization and adding the necessary information in Person. Additionally, the specialization of Product in several subclasses corresponding to its categories also disappears, since in Yahoo! Auctions the information stored about products does not depend on their category. Moreover, since products can only be offered and not requested, the specialization of Product in Offered becomes complete, and the association between Product and Category is eliminated, as well as the association Is related to between categories, since they are not necessary in this specific application. On the other hand, a class Subscriptions has been added, and related to Person, meaning that a user can be subscribed to several notifications. Integrity constraints must be modified accordingly, eliminating the one dealing with related categories, and adding an additional one stating that subscriptions are identified by name. Blacklisting is represented as a reflexive relationship in Person. When placing a bid, it must be checked that the bidder is not in the seller's blacklist by means of an additional precondition in the corresponding operation contract. Additionally, it must also be checked that the bidder rating is above the one specified by the seller, stored in the attribute minimumRating. We will see it later, when dealing with the behavior of placing bids. 4.2 Announcing Products Since in Yahoo! Auctions there are only open cry and multiple auctions, the use case diagram of this subsystem is exactly as the one in figure 4. However, the use case Publish announcement will only lead to three different domain events, those corresponding to the leaf subclasses of Announcement, since there will not be events for Request, Advertisement, Sealed bid auction and Dutch auction. As for the analysis class diagram, there were some classes included in the domain PIM (see figure 8) that do not appear now in this specific application PIM. These classes are the ones corresponding to subclasses of announcement that are not fixed price sales, open cry or multiple auctions. In addition to the information specified in the domain PIM, announcements at Yahoo! Auctions have additional features, such as auto extension (the auction closing time is extended for 5 minutes if a bid is placed within the 5 last minutes of the auction), early close (allows the announcer to close the sale before the specified time), closing time (the hour when the auction finishes) and auto resubmit (re-open the auction automatically if it finishes without a winner). These features will affect the behavior specification. In Yahoo! Auctions all kinds of auctions finish when the ending time is reached, so attributes finishWhen and delay in OpenCry and Multiple are not needed in this application. Moreover, the price /Announcer account : String minimumRating : Integer Category name : String description : String CompositeCat 2..* 0..1 child 2..* parent 0..1 {incomplete} Product pid : String date : Date User userId : String email : String password : String * 1 * 1 Registers GenderType male female <<enumeration>> {complete} {disjoint, complete} Subscriptions name : String Person surname : String birthDate : Date gender : GenderType country : String securityQuestion : String answer : String zipCode : String alternateEmail [0..1] : String phone [0..1] : String mailAddress [0..1] : String * * * * Is subscribed to * * * Has in blackist * BasicCat Offered 1 * 1 * In {complete} blacklisted name : String rating: Integer 23 to be paid by the winner at the end of the auction is always the amount of the winning bid, so the attribute priceToBePaid of Auction also disappears. Fig. 14. Adaptation of the Announcing products analysis class diagram to Yahoo! Auctions Another modification that must be done in order to adapt the domain PIM to this specific application is to include additional upgrade types (feature and gift), as well as to eliminate highlight and homePage, which do not exist in Yahoo! Auctions. An additional feature of Yahoo! Auctions is the possibility to store the announcements in which a user is interested. This has been represented by means of the association Has in watchlist. Also, in this application, bid increments are the same for all auctions, so they cannot be chosen by each seller. This means we need additional constraints stating that bid increments are identified by their attributes from and to, and that there is no interval of prices with an undefined bid increment. Finally, the integrity constraints referring to unnecessary classes or attributes must be deleted in order to obtain the specific application PIM Operation contracts regarding this subsystem must also be modified accordingly. For instance, some parameters of the operation open cry are no longer necessary, such as bidIncr¸priceToPay, delay and finish. The parameter beginning must also be excluded, since auctions always begin when they are created. On the other hand, some additional parameters (the ones corresponding to the additional features of auctions mentioned above) must be added. The resulting contract is the following: Operation: new-open-cry-auction(ann: Announcer, prod: Product, ending: Time, title: String, descr: String, photos: Sequence(String), upgrades: Sequence(UpgradeType), reserveP: Money, iniP: Money, autoExt: Boolean, earlyClose: Boolean, closingT: Time, resubmit: Boolean) Semantics: Create an announcement in open cry auction format for product prod, with the indicated characteristics Preconditions: - The Announcer ann is the owner of the product prod Postconditions: - An open-cry auction A, with the specified information and starting in the current time, is created - A is associated to the product prod incr : Real Sale itemsOffered : Natural FixedPrice salePrice : Money OpenCry BidIncrement from : Money to : Money Auction initialPrice : Money Multiple {disjoint, complete} {complete} {complete} {overlapping, complete} Offer reservePrice : Money autoExtension : Boolean earlyClose : Boolean closingTime : Time autoResubmit : Boolean UpgradeType bold feature gift <<enumeration>> Product ... Announcement beginning : Time ending : Time title : String description : String photos[0..*] : String upgrades[0..*] : UpgradeType 1..* 1 1..* 1 Published in User ... * 1 * 1 Registers * * * * Has in watchlist 24 4.3 Bidding and Announcement Closing With regards to bidding and announcement closing, few changes need to be made to the domain PIM in order to adapt it to Yahoo! Auctions, apart from the elimination of the unnecessary kinds of bids. Here, an announcement can not be pending since the beginning date of a sale is the current date. The operation contracts for bidding remain almost the same as the ones of the domain PIM, since the particular behavior of Yahoo! Auctions does not differ notably from the one specified in the generic PIM. The only thing that must be done in order to adapt the marketplace PIM to the particular case of Yahoo! Auctions is adding creation time constraints in the class AuctionBid in order to prevent the creation of its instances when the bidder has been blacklisted by the seller, the seller has canceled a previous bid of the same user or the bidder's rating is below the minimum set by the seller, which are the policies established by Yahoo! Auctions. Additionally, the postcondition must be extended so that it includes the behavior corresponding to auto-extension. Another slight difference between the domain PIM and this specific application PIM is that in Yahoo! Auctions only the seller can cancel bids. Users cannot retrieve bids they have placed, so in the precondition of the operation cancel-bid must only be checked that the user who cancels the bid is the owner of the product (the contract remains the same as the one of the domain PIM except for the precondition, which is simplified). Fig. 15. Adaptation of the Bidding and announcement closing analysis class diagram to Yahoo! Auctions The specification of the subsystem dealing with reputation and fees can be reused without further modifications. 5 Related Work As far as we know, ours is the first domain PIM for the e-marketplace domain. Previous proposals related to e-marketplace development have been mainly concerned with the design of the information system rather than with its specification. For this reason, these proposals have addressed mainly value : Money FixedPrice ... OpenCry ... Auction ... Multiple ... { complete } {overlapping, complete} Announcement ... / isOpen : Boolean isCanceled : Boolean PurchaseBid {disjoint, complete} AutomaticBid instant : Time AuctionBid useProxy : Boolean * 1 * 1 Generates Bid amount : Money isCanceled : Boolean Closed accepted : Boolean {disjoint, complete} {complete} { incomplete } User ... Time instant : Time * * * * Offer ... * * Sale ... / currentPrice : Money SaleBid itemsWanted : Natural / priceToPay : Money / itemsWon : Natural 0..1 * 0..1 winner * /Wins {complete} 25 architectural and technological issues related to e-marketplace development, such as security or distribution. Among others, we could mention [5, 9, 31] together with the references therein. All technological issues addressed by those proposals, as well as standardization efforts such as RosettaNet or ebXML 4 , are important and should be taken into account during the implementation of any application drawn from our e-marketplace domain PIM. Note that all those issues refer to Platform Specific Models (PSMs) while our field of concern has been given to the definition of a Platform Independent Model (PIM). As we said in section 2, PSMs are obtained as a result of transformations applied to a PIM in the context of the MDA. This is the way these proposals relate to the work we have proposed here. As far as the specification of electronic marketplaces is concerned, the work closer to ours is [27], which defines a pattern language for online auctions management that gathers the functional aspects involved in an online auction system. This language defines the static (structural) properties of the system (in a similar way as we do in our analysis class diagram) and it incorporates several types of auctions and the possibility to bid for them. In addition to the different field of concern, our PIM extends this work by covering a bigger domain, addressing both the structural and behavioral part of the information system and assuming an automatic, more realistic, treatment of auctions. 6 Conclusions and Further Work We have proposed a domain PIM for e-marketplaces. According to the MDA, a PIM describes a software system that supports some business independently of the implementation technology. Domain PIMs, as defined in this paper, extend the traditional notion of PIMs in the MDA by capturing the common aspects of a certain kind of applications instead of describing a particular system. Our PIM has been drawn from an external study of some well-known electronic marketplaces (eBay, OnSale, Amazon and Monster) and it covers both the structural and the behavioral properties of the main functionalities provided by an e-marketplace: determining product offerings, searching for products and price discovery. Since our PIM is specified in UML and OCL much of its implementation can be obtained automatically by means of the MDA. Taking a domain PIM as a basis, little effort is required to obtain an application PIM for a particular software system. Hence, from our e-marketplace domain PIM, multiple application PIMs for specific e-marketplaces can be obtained. In this way, and mainly because of the reutilization of an existing solution, our domain PIM facilitates the task of developing new e-marketplaces. To illustrate these ideas, we have defined the application PIM of Yahoo! Auctions from our domain PIM. The domain PIM proposed in this paper represents a step forward to the development of a repository of domain models, which is an important field of open research [17, 20, 30]. As further work, our aim is to define a complete set of operations that help to obtain an application PIM from a domain PIM. Additionally, we would like to suggest design patterns and reliable solutions that fit our domain PIM and solve common problems we find during the design of e-marketplaces. Acknowledgements We would like to thank Jordi Cabot, Jordi Conesa, Dolors Costal, Cristina Gómez, Òscar Hernández, Antoni Olivé, Xavier de Palol, Ruth Raventós and Maria-Ribera Sancho for many useful comments to previous drafts of this paper. We are also indebted to the anonymous reviewers who provided us with excellent comments during the course of reviewing this work. This work has been partially supported by the Ministerio de Educación y Ciencia, under project TIN 2005-06053. 4 http://www.rosettanet.org, http://www.ebxml.org