Patterns for Business-to-consumer E-Commerce Applications

P ATTERNS FOR B USINESS - TO -C ONSUMER E- C OMMERCE A PPLICATIONS Xiaohong Yuan 1 and Eduardo B. Fernandez 2 1 Department of Computer Science, No rth Carolina A&T State University Greensboro, NC, USA xhyuan@ncat.edu 2 Department of Computer Science and E ngineering, Florida A tlantic University Boca Raton, FL, USA ed@cse.fau.edu A BSTRACT E-commerce is one of the most imp ortant web appli cations. We pres ent here a set of pat terns that describe shopping carts, produ cts, catalogue, customer accoun ts, shipping, and invo ices. We combine them in the form o f composite patterns, wh ich in turn make up a domai n model for busi ness-to-cons umer e-commerce. We also i ndicate how to add securit y constraints t o this model. This domain model can be used as a compu tation-independ ent model from whic h specific app lications ca n be produced us ing a model-driven architecture approach. K EYWOR DS semantic analysis pattern, e-comm erce, model-driven architecture, comp utation-i ndependent model 1. I NTRODUCTION Model-Driven Architecture (MDA) is an approach to application modeli ng and code generation [1, 2]. It starts from a Computation-Independent Model (CIM) of a sy stem, which describes the domain and requirements. The CIM encapsulates th e semantics of the problem solved by the application and this semantics should be carried along the model transformations and reflected in the code. The CIM is also useful for building applications in a more conventional way. The use of patterns is a promising avenue to let inexperienced designers build conceptual models and as a tool for building dom ain models. An alysis patterns [3] are conceptual structures that capture the experience of analysts and c onstitute reusable elements of analysis models. Semantic Analysis Patterns (SAPs) [4 ] are an ex tension of analysis patterns to include more problem semantics. They emphasize basic functi onal aspects of the application model and serve as a starting point when translating requirements into a conceptual model. This type of pattern represents a minimum application (a s et of basic use cases) so that it can be applied to a variety of situations and it can be combined with ot her related patterns to describe m ore complex applications. It has been proposed to apply analysis pattern s through specialization wh en there are abstract patterns, or through analogy when there are pa tterns from another domain [4]. There was also the attempt to integrate analysis patterns into MDA [5]. Hamza and Fayad have proposed stable analysis patterns as a way of developing and utilizing analysis patterns in building software systems [6], [7 ]. Stable analysis patterns are designed to satisfy the criteria of traceability and generality. Bobkowska and Grabowski have exam ined the roles of analysis patterns and analyzed their strengths and weaknesses [8 ]. Th ey’ve also presented a cas e study of applying analysis patterns in system analysis. This paper demonstrates a method of creating CIMs by using SAPs. Individual SAPs related to e-commerce are identified and co mbined into a domain model for business-to-consumer e- commerce applications. We also illustrate how secu rity can be added to one of the patterns o f the domain model. The domain m odel includes such aspects as shopping carts, products, catalogs, customer accounts, shipment, invoices and inventories. The individual patterns have been published before [9, 10, 11, 1 2], but corrections and extensions have been made here. The component patterns of the individual SAPs are not presented here. The paper is structured as follows. Section 2 to 6 present the Catalog pattern, the Shopping Cart pattern, the Invoice pattern, the Order and Ship ment pattern, and the Stock Manager pattern respectively. Section 7 presents a domain model for business-to-consumer e-commerce. Section 8 discusses how to add security constraints in patterns of this type. Section 9 discusses related work to end with some conclusions in Section 10. 2. C ATALOG P ATTERN 2.1 Intent How can users find conveniently what products are available? 2.2 Context E-commerce sy stems where customers can buy products 2.3 Problem Web shops sell a variety of products, sometim es totally unrelated, e.g., books and food. An important problem is: How to organize product information, provide on-line guidance to the users, and improve the attraction of the web site so that users are willing to visit and return? 2.4 Forces The solution is affected by the following forces: • We need to classify and describe a varie ty of products so that cust omers can find easily what they want. • We should be able to provide more detailed information about products of inte rest to a customer. • We should be able to relate products so that we can recommend similar products to customers when they buy a product. • We should keep customers informed of new products or changes in product prices or availability. 2.5 Solution Figure 1 shows the class diagram for Catalog pattern. A Catalog is a collection of products. The Product class defines the type of product being so ld, it contains the basic attributes of each product. In particular, a status attribute indi cates special aspects, e.g., a new product. New products may be separated from the regular products and made known to the customers [13]. The ProductInfo class provides more detailed informati on about a product. It may also include comparison among different varieties of the same product, different brands , or provide the best price/performance ratio. Similar products ar e modeled as a self-association of class Product . Modifications to the products are notified to th e customers by email to let them know there is some new or interesting product. A class ProductObserver watches for changes and notifies customers. Note that these class es ar e a ty pe of Observer pattern. Class Notification keeps records of notifications sent to users. Figure 2 shows the collaborations triggered when products are modified. Figure 1. Class diagram for Catalog pattern Figure 2. Sequence diagram for updating a product 2.6 Consequences This pattern provides the following advantages: • This pattern provides the needed infrastru cture to describe products conveniently. Navigational classes can be added to show this information in attractive ways. << actor >> :WebClerk :Product :ProductObserver updateProduct modify << actor >> :Customer notify getState notify Customer ProductObserver init () modify() Catalog topic create () delete () getProduct () Product N otification p roductI d p rice status getStatus () insertProduct () deleteProduct() updateProduct () findTopic() ProductInfo advantage comparison setAdvantage () setComparison () getAdvantage () getComparison () 1 * * 1 * * Send View * * IsSimilarTo name customerID address • The catalogue can classify products according to different criteria to allow convenient search and selection. • The pattern provides a way to find mo re detailed infor ma tion about products. • Products can be related because they have a si milar topic or because we keep st atistics of products bought by people. • We can keep customers informed of any changes to the products. • This pattern is scalable. It is suitable for various kinds of web shops, from web malls to personal stores. • This pattern refers to product types. Some s ites sell individual products, e.g., a used-car site, an auction site. In this case the Product class becomes a set of individual products and we need an additional class to indicate the product type. The pattern also has the following liability: It is rather complex for small shops. 2.7 Known uses • On-line book stores, music stores, shoe stores, wine stores, etc. • Most Web Application servers, e.g., IBM’s WebSphere Commerce Suite, incorporate catalogs [14]. • Amazon.com 3. S HOPPING C ART P ATTERN 3.1 Intent This pattern describes web shopping using a shopping cart 3.2 Context E-Commerce sy stems where customers can buy products 3.3 Problem Customers can select and purchase different pr oducts for a web shop. The shopping process must have well defined steps. This is necess ary because we need to show the cus tomer where he is in the process. The problem is now: How to describe the shopping process in a precise way? 3.4 Forces The solution is affected by the following forces: • We should show clearly to the customer which items she has selected and their individual and total cost. • We should create an order and its corresponding invoice for the selected items. • We should keep information about the buying habits of the customers so we can offer them a better service. • We should re ward loyal customers with discounts and special offers. 3.5 Solution The most common metaphor for the shopping process is based on the concept of shopping cart, analogous to the carts used in supermarkets. Figur e 3 shows the class diagram for the Shopping Cart pattern. The ShoppingCart class collec ts information about all the produc ts a customer has selected. The CartItem object indicates the quantity and the product selected by a custom er. A customer can query the products in his cart and remove products from the cart. The Customer class indicates the custo mer responsible for a shoppi ng cart. When the shopping cart is checked out, an order and an invoice will be generated (the Order and Invoice classes). Figure 4 shows the p rocess of selecting and check ing out a product. ShoppingCart cartId numberOfItem s cartPrice showItem () addItem () removeItem () checkout calcTotalPrice () Order Invoice amount date specification status Customer CustomerId p asswd setProfile() getProfile () updateProfile () CustomerProfile name address p honeNumbe r e_mail creditInfo shippingInfo Member account setAccount () getAccount () CartItem quantity unitprice calcPrice () * 0..* *1 Owns Product p roductI d status p rice getStatus( ) getState () notify() getCatalog () * * Selections 11 Has () 1 Becomes 1 Figure 3. Class diagram for Shopping Cart pattern Figure 4. Sequence diagram for buying and checking out a pro duct << actor > > : Customer :Product :CartIte m select : Customer ShoppingCart :Invoice create calcPrice addItem checkout getProfile calcTotalPric e generate 3.6 Consequences • This pattern describes an abstract shopping process. It provides common elements for building shops in the Internet. It can be a pplied to various web shops from those selling shoes to those selling software. • The pattern should help reduce the complexi ty of the shopping pr ocess in the Internet. All or some of the process steps can be di splayed to the user for his guidance. • The pattern does not provide a mechanism to prevent errors, such as wrong credit card number, errors in billing address or shipping address. • We can show what items the customer has selected and their unit and total prices. • At the end of the process the contents of the shopping cart becomes an order to be shipped to the customer and the corresponding invoice is created. • We can keep detailed information about the shopping habits of our custom ers. • Loyal customers (members of our loyalty cl ub) can receive discounts of coupons to buy new items. 3.7 Known uses Amazon.com, Borders.com, barnesandnoble.com 4. I NVOICE P ATTERN 4.1 Intent The pattern describes events su ch as the creation and validation of an invoice, followed by the payment process. 4.2 Context Institutions or enterprises that require payment for products or services 4.3 Problem There are many systems where we need to co mbine the functions of creating and preparing an invoice, and paying that invoice, including the corresponding validations. How do we represent this process in a general and abstract manner? 4.4 Forces The solution is affected by the following forces: • The creation, preparation, and validation of an invoice requires specific actors, actions in specific sequences, and mu st follow specific rules. • Preparation and validation shoul d be done by different people (separation of duty). • There should be flexibility about who is responsible for a payment and how the payments will be made. • The system and the client need a convenie nt way of keeping track of the payments made. • Validation of every prepared invoice and every received payment has to be made t o ensure that the client’s information is correct and in accordance to the requirements and regulations of each system. • We need to keep track of who created an invoice, who validated it, and who validated a payment. 4.5 Solution Figure 5 is the class diagram for the Invoice pattern. Class InvoiceCreator defines an interface for creating an invoice. It also provides a way of preparing the invoice by adding or deleting items from it, specifying different properties, whic h are used to derive the final scope of the invoice. Class Invoice represents the document in which all the goods or services are incorporated together with the nature of each item. Class InvoiceValidator is used to ens ure that the invoice that resulted from the steps de scribed above is in a consistent form that complies with the trade usage. Classes BillingPolicy and ValidationRule include business policies that apply to the preparation and validation of invoices, and validation of payment.The Payment class represents the payment made by th e client for the products and/or services incorporated in the invoice. Class PaymentValidator is used to validate pay ments according to validation rules. Class Employee keeps track of who validated a payment, and class Customer represents the customer that makes paymen ts for the given invoice. Figure 6 shows the sequence diagram for creating, pr eparing and validating an invoice. Figure 7 shows the sequences diagram for payment of an in voice. Figure 8 shows the activity diagram of creating and paying for an invoice. Figure 5. Class diagram for Invoice pattern Figure 6. Sequence diagram for creating, preparing and validating an invoice :InvoiceCreator :Invoice :InvoiceValidator create() initialize addItem(item) [complete] validate loop -[more items]- calculateAmount :ValidationRule check Invoice isValidInvoice * * * 1 type * * 1 1 * isPaidBy isPaidBy Em p lo y ee name invoiceID date time itemsBought totalAmount discounts Payment <> InvoiceCreator Billin g Polic y <> InvoiceValidato r Validation Rule date create 1 * create * * validate validatedBy accountableFor * * validatedBy idPaymentMethod * * applies validate applies isValidPayment <> Pa y men t Validato r * * applies to 1 * * * * 1 customerId Custome r date Figure 7. Sequence diagram for invoice payment Figure 8. Activity diagram for invoice creation and payment 4.6 Consequences • This pattern describes an abstract invoice pr eparation process that can be tailored to different specific situations. • We can keep track of who prepared and who validated an invoice, as well as who validated payments. • We can apply different validation rules to an inv oice and a payment. Invoice Payment create validate payment create receive payment p repare validate send make payment :Client :Invoic :PaymentValidator getTotalSum makePayment validate validatePayment :ValidationRule check :Payment create return status 4.7 Known uses • A point-of-sale system in any department store that sells products, such as Macy’s. • An on-line shopping store, where people use the Internet to log ont o an on-line shop in order to buy different items, e.g. Amazon. • Monthly invoicing for telephone or inte rnet service, e.g. Comcast. • SAP has an Invoice m anagement product where they create and prepare invoices. 5. O RDER AND S HIPMENT P ATTERN 5.1 Intent This pattern describes the placement of an order for some product and its corresponding fulfillment. 5.2 Context E-Commerce sy stems where customers can buy products 5.3 Problem How to describe the process of placing an order for some product and fulfilling the order. 5.4 Forces The solution is affected by the following forces: • The institution needs to track order fulfilme nt to maintain customer satisfaction. • The model must include representations of real-life documents, e.g., Orders, Line Items, and Invoices. • Equivalent products m ay be s ubstituted for requested products. 5.5 Solution Figure 9 shows the class diagram for Order and Shipment pattern. The associ ation between class Shipment and class Order shows that each shipment has a corresponding order, but an order does not necessarily result in a shipment (e.g. the order could be cancelled). T he Invoice class describes the invoices created for each shipment. Th e diagram also shows that not all products ordered may be in the final shipm ent or that some of these products m ay be different from those ordered. Figure 10 and 11 show the sequence diagram and activity diagram for ordering and receiving a product. Shipment 0 ..1 date Figure 9. Class diagram for Order and Shipment pattern Figure 10. Sequence diagram for ordering and receiving a product aCu stom er anO rder: Or d e r aS hi pment: Sh i p me n t create cal c_co st proce s s recei ve create assem b l e recei ve_payment add_ custom er aC u sto m er: Cus tom e r anIn voi ce: Invo i ce shi p recei ve_shi p ment aPro du ct: Pr oduc t in c lu d e check_ o rd er check_shi pm ent Invoice date account N o sales sales Tax freight p ayment Type p ayment Status shipment N o shipment Type Status receive Customer name p hone N o address credit Info 0 ..* 1 Order date order N o status LineItem quantity Product_Type modelNo p rice description 1 0 ..* Places 0 ..* 1 0 ..1 Order for 1 create() calc _ cost() receive _ payment() create ) ( check _ o der() r receive_ shipment() close() assem le() b ship() add _ customer ) ( update _ addr() create() calc _ cost() cancel() add _ info() check _ credit() p rocess() close() check _ shipment change _ price() change _ price() * Corresponds to Included i n * Product Id p roduc t customerID * Order Shipment Invoice create process create assemble Figure 11. Activity diagram for order and shipm ent 5.6 Consequences • An “order” is always generated in the “system” based on the customer’s expressed need. • An order is always linked to a customer. • Some type of documentation is always gene rated, with a copy archived and a copy delivered to the customer along with the product. • The ordered product could be an individual unit, not a type. • The ordering or receiving customers could be another subsystem or system . • Each shipment can be related to its corresponding order. • The receiver may or may not be the same customer who placed the order. • The model also applies to services, with cl ass Shipment representing the delivery of the requested service. 5.7 Know uses • A retailer/service provider of some type of devices, e.g., pagers, orders a quantity of devices to be resold at retail. • A customer orders food from a restaurant. • A customer orders a product from an e-commerce co mpany, e.g. Amazon.com 6. S TOCK M ANAGER P ATTERN 6.1 Intent prepare send ship cancel receive p aymen t This pattern keeps track of quantity and locatio n of item s in stock, and updates these quantities according to the different stages of manufacturing or production. 6.2 Context Institutions or manufacturing system that use components to build products 6.3 Problem How can businesses, manufacturing shops, libraries, etc ., keep track of their stocks of items of different types and their locations? 6.4 Forces The solution is affected by the following forces: • In a company, items can be materials used for manufacturing or finished products. There is the possibility of losses or destructi on of this stock. The institution must be able to keep track of the actual number of item s in stock. • Other functional units may change the stock qua ntities; i.e., any transfer or use of items anywhere should update the corresponding inventory quantities. • The solution must describe a fundamental sema ntic unit. This means the solution must be simple enough to apply t o a variety of s ituations. This is the basis for reusability. • The solution must include representations of real-life documents. 6.5 Solution Figure 12 shows the class diagram for the Stock Manager pattern. Items are classified into two varieties: finished products and components (u sed in product manufacturing). Th ere exists many differences in the management of these two entities. Classes Stock and Component/Product are related by a composition association. The quan tities, described by the Inventory class, are a joint property of Stock and Component/Product that has different values for different links. This model permits a designer to define different types of stock as separate collections; e.g., stock of components, stock of products. Different types of inventories can be generalized into a class Inventory. Figure 12. Class diagram for the Stock Manager pattern Figure 13 shows the sequence diagram for moving items in or out of stock. When components or products are moved to or out of stock, their onHand values are increased or reduced by applying operation add_to_s tock or remove_from_stock. Operation add_to_stock determines the distribution of items into local stockroom s based on some predetermined criteria. When * * * * S t oc k a d d_e l e m en t () re mo ve_ el e me nt () P r o d uc t p rod u ct Id In v ent or y on H and t r an s fer (qt y ,fro m ,to ) a d d_ to _ s to c k ( q t y ) re m ove _fr om _s t oc k(qt y a dj_ di scre pa nc y() Lo ca t i on nu mb e r lo ca t io n si z e a dd_ S t o c kR oo m( ) de le t e _S toc kR oom () D i s t ri b uti on lo ca lo n Han d lo c a lRese r v e d cy c leC o u n t lo c a lAvai la b l e a dd_ t o _l o ca l St oc k( qt y) re m ove _fr om _ l o c a l S t o ck (qt y ) lo c a lRese r v e ( qt y ) lo c a lUnr e se r v e ( q ty ) ve ri f y_ co unt() a dj _di scr e p a nc y() s et _ cy cl e_ co u n t( ) C om p on en t it em N u m de s cript i o n C om po ne nt I nve ntor y P rod uc tIn ve nt o ry av ai la bl e re se rve d r ece iv ing on O r de r min Qt y ma xQt y re se rve () un re s erv e( ) re c ei ve () u n r e cei v e ( ) o rde r() un ord e r () c h e ck _ lo w e r L im it ( ) components and products are moved to or out of specific stockroom s operation add_to_localStock or remove_from_localStock increases or reduces the localonHand quantity. Components or products can be transferred from one stockroom to another. Figure 14 shows the process of this action. Figure 13. Sequence diagram for m oving items in or out of stock add_to_ localStock(qty i) add_to_ localStock(qty j) remove_from_stock( qty) remove_ from_ localStock(qty k) remove_ from_ localStock(qty l) add_to_st ock(qty) Figure 14. Sequence diagram for item transfer Figure 15 shows the complex changes to the inve ntory during manufacturing. We first assume that Customer Orders have already been processed into a form that indicates in detail what and how many components are needed in the manufac turing for a type of product; this is a Shop Order. When a Materials Employee cu ts the Shop Order, the values of reserved components are increased based on the quantity indicated by th is Shop Order. When components have been physically picked from the stockroom, the values of reserved and onHand for these components are reduced. When fabrication is finished, ProductInventory quantities are updated by increasing their onHand value. Usually, a Shop Order takes several days from cut to finish. The stages cut, pick and fab let people know what is the status of the Shop Order. :Materials : Invent ory : Distribution-i : D istribution-j Employee : Materials Dist ribution-i transfer(qty,from,to) add_to_ localStock (qty) remove_from_ localStock(qty) Employee : Inventory : Distribution-j Figure 15. Sequence diagram for manufacturing a Shop Order 6.6 Consequences The pattern can be used to keep track of quantiti es of interest for different types of stock and reserve (qty j) localReserve(qty m) localReserve(qty n) pick remove_from_stock(qty i) : remove_from_localStock(qty k) : remove_from_localStock(qty l ) remove_from_stock(qty j) remove_from_l ocalStock(qty m) remove_from_l ocalStock(qty n) unreserve(qty i) : localUnreserve(qty k) : localUnreserve(qty l) unreserve(qty j) localUnreserve(qty m) localUnreserve(qty n) fab add_to_stock(qt y p) their distributions. : localReserve(qty l) • The activities that affect the inventory may be different in different applications. • Although the pattern is described in manufacturing terms, it can be applied to represent the inventory of a library, a business, or similar places. • Documents such as Shop Orders and others ar e considered part of the external systems that interact with the inventory and are not represented in the pattern. 6.7 Known uses • The model presented here was applied in the development of an inventory prototype for the Information Technology Dept. of the Pager Products Div ision of Motorola in Boynton Beach, FL. • Hay’s inventory model [15], includes some aspects which we left out. However, his model doesn’t include d ynamic aspects, attr ibutes, or operations ; it doesn’t separate either stock from inventory. • Fowler dedicates a chapter (Chapter 6 in [3]), to Inventory and Accounting. cut (qty i) localReserve(qty k) :Materials reserve : : Shop : Component : Com ponent : Distribu - : Distri bu - : Product Employee Order Inventory-i Inventory-j ti on -k tion -1 Inventory 7. A D OMAIN M ODEL FOR E-C OMMERCE velop a domain model for e-commerce he domain model for e-commerce 8. S ECURE E-C OMM to each of the component patterns to produce a dom ain model nstrate here how to add security constraints by instantiating a The five component patterns can be combined to de applications. Each component pattern can corr espond to a subsystem. Figure 16 shows how the component patterns are combined into the domain model. Classes that are in several component patterns such as Customer, Invoice are only included in one subsystem. Subsystems dependencies are also shown in the diagram. The CartItem in Shopping Cart subsystem corresponds to the LineItem in Order and Shipme nt subsystem, so LineItem is rem oved from the Order and Shipment subsystem. Figure 16. T Product ProductInfo Catalog ProductObserver Customer ShoppingCart CartItem CustomerProfile Order Member Notification ProductType BillingPolicy InvoiceCreator Invoice Employee Payment InvoiceValidator PaymentValidator ValidationRule Inventory Product Inventory ComponentInventor Stock Component Distribution ComponentInventory Shopping Cart Invoice Shipment Order and Shipment Stock Manager Catalog ERCE Security constraints can be added for secure e-commerce. W e demo security pattern, that is, Role-Based Access Control (RBAC) pattern [16]. In the RBAC pattern, users are assigned to the roles according to their tasks or jobs and rights are assigned to the roles. In this way, a need-to-know policy can be app lied, where roles get only the rights they need to perform their tasks. Figure 17 shows how to add security constraints to the Shopping Cart pattern by applying six in stances of the RBAC pattern. cartId cartPrice numOfItems ShoppingCart addItem() removeItem() Product p roductID p rice * CartItem quantity unitPrice calcPrice() <. Manager Right viewShoppingCart Right <> Customer <> Employee updateProduct() viewShoppingCart addItem removeItem Righ t updateProduct Righ t viewProduct Right viewProduct Right viewShoppingCart Only for his own shopping cart Figure 17. Adding security constrai nt to Shopping Cart pattern 9. R ELATED W ORK Jazayeri and Podnar [17] presented a business and domain model for information commerce, which describes a virtual environment in which buyers and sellers of information may trade information products. The domain model was developed from scratch from use cases. The Customer, Product and Order classes in the domain model are also included in our domain model. The roles of Intermediary and Provide r, as well as Request, Offer, Document are not included in our model. A phase-structured model for e-commerce business m odels is presented in [18]. In this model, business processes are broken down into five phases: advert ising, negotiation, ordering, payment, and delivery. A 3-party model (custome r, intermediary, provider) is used to m odel interactions in e-commerce business models. The phase model is used to analyze the specific security requirements of e-commerce business mode ls, highlight potential threat scenarios and describe their solutions. Our domain model covers advertising (in the Catalog patter), ordering, payment and delivery phases. Our model does not include the intermediary party. Object-Oriented Hypermedia Design Method ( OOHDM) [19] is a web application design method that includes conceptual design, navi gational design, ab stract interface design and implementation. In [20], OOHDM was extended to allow developers clearly specify and design web applications that embody business processes. The extended OOHDM was used to model an online retail store. Our domain model includes similar objects o r cover similar aspects in their concep tual schema of the online retail store, for example, ShoppingCart, Order, Customer, Item, CD, ShippingAddre ss, PaymentOptions, DeliveryOptions. Lau [21] conducted domain analysis of e-commerce systems, and applied feature-based model template development process to develop and model a business-to-consumer e-commerce system. The feature model consists of over 200 features which were divided into tw o categories: store front and business management. The model template includes two class diagrams and seventeen activity diagrams. Our model and th eir model both have objects such as Catalog, Customer, Product, ShoppingCart, CartItem, Order, Payment, etc. Their model has features that we do not have, such as wishlist, customer regi stration, etc. Our model includes inventory and stock management, invoice creation and validati on which are not covered by their m odel. 10. C ONCLUS ION AND D ISCUSSION This paper presents a set o f patterns appropriate for business-to-consumer e-commerce. Thes e patterns are then combined into a domain model. This paper also shows how security constraints can be added to the domain model. The domain model can be used as a CIM from which specific applications (for example, an inventor y management system) can be produced using an MDA approach. A correct CIM is fundamental for any MDA process because it defines the semantics of the problem represented by the a pplication solution. If the details of one the component SAPs are not of interest we can replace the SAP by a Façade [22 ]. When we add security constraints in the CIM we c an enforce that all the applications derived from it follow the same constraint s along the MDA transformations [23]. Similarly, institution policies and legal regulations can be defined in the domain model. Varieties of the m odel can be produced for different environments requiring different regulations, for exam ple, HIPAA regulations can be used for medical applications. Our domain model includes the basic aspects of e-comme rce. It could be extended by adding an Intermediary role, a Wishlist, etc. Other aspects that can be added include personalization [24, 25] and usability-oriented patterns [13, 26, 27] . R EFERENCES [1] Alhir, S. S. (2003) “Und erstandin g the model driven architecture (MDA),” Models and Tools , available at: http:// www.methodsandt ools.com /archive/arc hive.php ?id=5 [2] Brown, A . W. (2004) “Model driv en architecture: principles and practice”, Softw. Syst. Model , vol. 3, pp 314- 327. [3] Fowler, M. (1997) Anal ysis Patterns – Reusable O bject Models , Addison-Wesley. [4] Fernandez, E. B. and Yuan, X. (2000) “Seman tic analysis patterns”, Procs. of 19th Int. Conf . on Conceptual Modeling ( ER2000) , pp 183-195. [5] Filkorn, R. and Návrat, (2005 ) P. “ An approach for in tegrating analysis patterns and feature diagrams into m odel driven architecture,” SOFSEM 2005: Theory and Practice of Computer Science, Lecture Notes in Computer Science , Springer Berl in. [6] Fayad M. and Wu, S. (2002) “Merging multiple conventional models in one stable model”, Comm. of the ACM , vol. 45, No 9, pp 102-106 . [7] Hamza, H. and Fayad, M. E.(2004), “A pplyin g analysis pattern s through analogy: prob lems and solutions”, Journal of Object Tech nology , vol. 3, No. 3, , http://www.jot.fm [8] Bobkowska, A. and Grabowski, J. (2009) “The role of analysis patterns in systems analysis,” Procs. of the 14 th European Conference on Pattern Languages of Programs (EuroPLoP 2009 ) , available at: http://hillside.n et/europlop/eu roplop2009/submissio n/schedule.cgi [9] Fernandez, E. B. (2000 ) “Stock Manager: An analysis pat tern for in ventories”, Pr ocs. of the 7th Conf. on P attern La nguages of Pr ograms (P LoP 2000) , http://jerry.cs.uiuc.edu/~plop /plop2k [10] Fernandez, E. , B., Yuan, X., and Brey, S. (2000) “ Analysis patte rns for the or der and shipm ent of a product”, Procs. of t he 7th Conf. on Patte rn Language s of Progra ms (PLoP 20 00) , http://jerry.cs.uiuc.edu /~plop/plop2k/pro ceedings/proceedings.h tml [11] Fernandez, E. B., Liu, Y. and Pan, R. Y. (2001) “Patterns for intern et shops “, Procs. of the 8th Conf. on P attern La nguages of Pr ograms (P LoP 2001) , http://jerry.cs.uiuc.edu/~plop/plop2001/accepted_subm issions/accepted-papers.html [12] Fernandez, E. B. and Yu an, X. (2009) "An analysis pattern for invoice processing", Procs. of t he 16th Conf. on Pattern Languages of Programs ( PLoP 200 9) , August 28 -30, Chicag o, Illinois, USA. [13] Lyardet, F. and Rossi, G. (1998) “Pat terns for dy namic websit es”, Procs. of the 5th Co nf. on Pattern Languag es of Programs (PLo P 1998) , http://jerry.cs.uiuc.edu/~p lop/ [14] IBM Corp., “P atterns for e-business”, http://www.ibm.com/developerwork s/patterns/ [15] Ha y, D. (1996) Data Model Pattern s-- Conventions of Thought , Dorset House Publications. [16] San dhu, R., Coyne, E . J., Feinstein, H. L. and Y ouman, C.E. (1996) “Role-base d access control models,” Com puter , vol. 29 , No2, 3 8-47. [17] Jazayeri, M. and Podnar, I., (2001) “A business and domain model for information comm erce,” Procs. of the 34 th Hawaii International Con f erence on System Sciences . [18] Hauswirth, M ., Jazayeri, M., Schneider, M. (2001) “A pha se model for E-Comm erce business models and its application to security assessment,” Procs. of the 34 th Hawaii Internationa l Conference on System Scie nces . [19] Schwabe, D. and Ro ssi, G. (1998) “An object or iented approach to web-based application s design,” Theory and Pr actice of Object Systems , vol. 4( 4), pp 207-2 25. [20] Schm id, H. A. and Rossi , G. (200 4) “Modeling and designing p rocesses in e-com merce applications,” IEEE Internet Computing , January -Februar y. [21] Lau, S. Q.(2006) D omain Analysis of E-C ommerce Systems Using F eature-Based Mo del Template . Masters Thesis, http:/ /gp.uwaterlo o.ca/files/2006 -lau-masc-thesis. pdf [22] Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (2994) Design Patterns –Ele ments of Reusable Object-Oriented Softwar e , Addison- Wesley. [23] Delessy, N and Fernandez , E. B. (200 8) “A pattern- driven securit y process for SOA applicat ions", Procs. of the 3rd Int. Conf. on Availa bility, Reliability, and S ecurity (ARES 2008) . Barcelona, Spain, pp 416-421. [24] Palmer, M. “A personalization design patter n for dynamic websites”, http://objectd esign.com [25] Rossi, G., Schwabe, D., Dancul ovic, J. and Miaton, L . (2001) “P atterns for pe rsonalized we b applications”, Procs. of the 6 th European Conference on Pattern Languages of Prog rams (EuroPLoP 20 01) , http://www.hillside.net/patterns/Euro PLoP/ [26] Lyardet, F., Rossi, G. an d Schwabe, D. (1999) “Patterns fo r adding search capabilities to web information systems”, Procs. of the 4 th European Conf erence on Pattern Languages of Programs (EuroPLoP 19 99) , http://www.argo.be/europlop/index.h tml [27] Rossi, G., Lyard et, F. and S chwabe, D. (2000) “Patterns for e-commerce applications”, Procs. of the 5 th Europe an Conference on Pattern L anguages of Program s (EuroPL oP 2000) , http://www.coldewey.co m/europlop2000/