The WebShop E-Commerce

Framework
Wolfgang Pree Bernhard Rumpe
Marcus Fontoura
Professor of Computer Software and Systems
IBM Almaden Research
Science Engineering
Center
Software Research Lab Munich University of
650 Harry Road, San Jose,
University of Constance, D- Technology, D-80290
CA 95120, U.S.A.
78457 Constance, Germany Munich, Germany
e-mail:
e-mail: [email protected] e-mail: [email protected]
[email protected]

Abstract - This paper presents an e-commerce • Promotions: promotions usually depend

framework called WebShop, which was developed on parameters such as the overall
by the authors for the purpose of demonstrating the shopping volume of a customer or the
use of UML and the UML-F in the domain of Web
frequency a customer comes along. For
applications. Thus, the WebShop is not regarded as
a full-fledged system out of which real Web stores
example, a bookstore site might send a gift
can be derived. For example, the framework in the at the end of the year if the sales volume
presented version does not encounter security of a customer has surpassed a certain
features. However, it presents the most important limit. Another example would be to freely
variation points related to online catalogs. The upgrade to a faster delivery, if a customer
UML-F Web site http://www.UML-F.net provides buys goods for a greater value amount.
the Java source files and some sample adaptations WebShop should be easily extended in
of WebShop. that regard.
• Reports: every organization requires
Keywords: e-commerce, UML, UML-F, object-
different kinds of management
oriented frameworks.
information. Examples include rankings of
the best customers, sales figures on
1. WebShop overview various single products and product
WebShop basically allows the creation of groups, and information regarding the
online stores from a description of the preferred payment methods. Once again,
products that should be offered and sold on a WebShop should be open for any
Web site (see Figure 1). extension of the reporting subsystem.
Web-site with Figure 2 sketches the configuration
Product information product catalog
& store configuration
WebShop and shopping options of WebShop. Typical WebShop
facilities adaptations can choose among predefined
Figure 1 The goal of the WebShop framework. payment options so that this aspect allows a
black-box configuration. The promotion and
As specific Web stores differ in various report generation will quite likely be adapted
aspects, the WebShop framework defines the to the specific requirements of each
following variation points: application.
• Payment options: companies accept Figure 3 represents the navigational
various payment options, such as credit structure of a typical WebShop application.
cards, electronic money, and so on. Each single rectangle represents a web page
Moreover, completely new electronic and the arrows represent the actions that cause
payment methods may arise and the movement between the pages.
framework should be able to incorporate The Shopping page is the application entry
them. point. It displays the list of available products,
allowing clients to add products to their
individual shopping cart and to change the
quantities of each selected product. When the
client wants to checkout he or she only has to
select payment method and to provide the
required payment information. The system
then verifies the information and either
processes the transaction or reports an error.
Figure 4 shows a typical Shopping page.

Web-site with
Product information product catalog
WebShop and shopping
& store configuration
facilities
Payment
Promotions options
Administrative
reports

WebShop’s variation points

Figure 2. Variation points of WebShop.

Transaction
concluded Figure 4. Typical Shopping page for WebShop.
Shopping
page Report1
Process @
transaction
@ Transaction @
Report
- Add product to error list
Select report
shopping cart
- Alter product
quantities
- Payment method
@ @ Report K
selection & information - Report selection &
Figure 3. Navigational structure of a typical information

WebShop application. @
Figure 5. Report listing on a separate site.
WebShop allows the creation of a
complementary site for displaying the 2.1. Shopping Cart
administrative reports. Typically, the structure
of the administrative is set up as a simple list The core entity of the WebShop framework is
of reports. The end user can select from an the shopping cart. For each client access to a
overview list any of the reports available (see Web store a new shopping cart object is
Figure 5). created. This shopping cart takes care of the
connection and is responsible for controlling
the user selection of products and the checkout
2. WebShop components operation. Figure 6 shows an UML-F diagram
The following sections present the core demonstrating what a shopping cart contains -
aspects of WebShop by means of UML-F [1] the exact number of products and one
diagrams. UML-F is an UML [4] extension for transaction log.
documenting object-oriented frameworks and Methods addProduct(),
design patterns. This presentation forms the removeProduct(), and changeQuantity() in
basis for identifying patterns that are useful in class ShoppingCart modify the products
the context of e-commerce frameworks. already chosen accordingly. Method
checkout() processes the payment transaction.
It is also responsible for updating the system transactions in Figure 8(a), and the electronic
transaction log by invoking method addLog() money transactions in Figure 8(b).
in class TransLog. The transaction log may be
used for various customer relationship
management activities such as promotions. «Sep-T» «interface»
ShoppingCart payment 1 «Sep-H»
Thus, it forms the basis of various reports. Payment
...
+processPayment() «Sep-h»
Product +checkout() «Sep-t»

ShoppingCart products * ... «adapt-dyn»

+getName()
... CreditCard EMoney
+addProduct() +getValue()
+processPayment() +processPayment()
+removeProduct()
transLog 1
Figure 7. The Payment interface.
+changeQuantity() TransLog
...
+checkout()
+addLog() :ShoppingCart

Figure 6. UML-F class diagram of ShoppingCart checkout(“CreditCard”, ...)

and two of its associated classes.
«create» :CreditCard

2.2. Payment options

Each application created by the framework processPayment(...)

will incorporate a number of payment options.

In particular, the cart’s checkout() method
requires the information on available payment
(a)
choices. To keep payment methods flexible,
WebShop applies the Separation construction
principle [3] (see Figure 7). As all the :ShoppingCart

Payment objects interacting with a shopping checkout(“EMoney”, ...)

cart have to be able to process a payment, the
«create»
interface Payment defines the :EMoney

processPayment() method. Therefore, all

specific classes used for payment have to processPayment(...)
implement the Payment interface, as illustrated
in Figure 7.
Figure 7 uses UML-F tags to identify
explicitly the template and hook methods and (b)

classes. The method checkout() is the template Figure 8. Creating the appropriate payment object
method («Sep-t»), since it is responsible for (a) for credit cards and (b) for electronic money.
invoking processPayment() («Sep-h»), which
is a hook method that varies for different Note that the parameter specifying the
classes that implement the Payment interface. payment option is a string that represents the
The «adapt-dyn» tag indicates that the classes class name of the specific payment class. The
are dynamically loaded into the system when checkout() method uses dynamic class loading
needed. to instantiate the appropriate class based on its
From the client’s perspective, a Web name. Example C.1 illustrates the code for the
form should present the payment options checkout(). A more elaborate (and flexible)
available. The client selection is then design would have a table mapping the string
proceeded to the store that has to instantiate parameters to the actual class names.
the appropriate payment object and plug it into
public boolean checkout(
the shopping cart. The sequence diagram in String paymentClassName,
Figure 8 illustrates this scenario. It shows the String paymentInfo) {
creation of an object to process credit card
boolean paymentOK = false;
 Payment payment = null; The COR pattern allows each
promotion object to check if the current
try { // tries to instantiate a Payment object
Class c = Class.forName(paymentClassName); transaction follows the conditions required by
payment = (Payment) c.newInstance(); it. The object then forwards the request to the
} next promotion object, if any. The object
catch(Exception e) { diagram in Figure 10 exemplifies a
// error, throws framework exception
}
combination of two such promotion objects to
// The method total() calculates the total value which a ShoppingCart object refers to.
// of goods in the shopping cart. This method is a
//private method in class ShoppingCart. :ShoppingCart

if (payment.verifyPayment(payInfo, total())) { checkout(“CreditCard”, ...)

// Add transaction to log «create» :CreditCard
paymentOK = true;
}
return paymentOK; processPayment(...)
parseInput()
}
process()
Example 1. Source code fragments of method
checkout() in class ShoppingCart.

The various implementations of the Figure 9. The general behavior of concrete

processPayment() hook method require implementations of processPayment().
different arguments. As the client supplies
these arguments through a Web form, :ShoppingCart

WebShop assumes that they are provided in a

:Over1000
single string that is formatted according to
simple conventions, that is, as “number =
:BaseDiscount
’5534453567144532’; expdate = ’10/2002’;
name = ‘John V. Lee’”. (Another equivalent Figure 10. Composing promotion objects.
solution would is to use XML for formatting
this input string). Each implementation of The ShoppingCart object is responsible for
invoking the definePromo() method as the first
processPayment() parses and processes this
in the chain of promotion objects. These
input string. The attributes in the string are
promotion objects are further responsible for
defined by the particular payment classes. The
sequence diagram in Figure 9 illustrates this forwarding the request in the chain. In the
sample chain shown in Figure C.10, the object
behavior for the CreditCard object.
of class Over1000, which gives discounts for
transactions over $ 1000.00, treats the request
2.3. Defining promotions in
and forwards it to the next promotion object,
WebShop which gives a 10% discount for all
In order to deal with promotions, the transactions. Figure 11 annotates the
checkout() method invokes a method promotions variation point with the COR tags.
definePromo(). This method defines a Of course, the solution based on COR
promotion that depends, for example, on the is simple and doesn’t take in account some
overall value of purchased goods. important issues, such as the fact that some
As the WebShop framework should be implementations of definePromo() should
able to support several promotions at the same have access to the payment and user
time, WebShop applies the Chain-of- information and to the transaction log in order
Responsibility (COR) pattern [2]. For to support promotions based on the user
example, when a frequent shopper buys goods history, such as promotions for frequent
for more than $ 1000.00 he or she should shoppers. However, COR provides the main
receive an extra discount.
structure of this variation point to which new instance, is a specialization of Web Request
extensions can be added. that treats payment processing requests. Figure
1 15 models the administrative reports variation
«COR-Handler» point together with the Web Request tags (the
promo 1
ShoppingCart
...
Promotion successor same can be done to payment).
+definePromo() «COR-handleRequest»
:Report

«COR-ConcreteHandler» «COR-ConcreteHandler»
report(“ListLog”)
Over1000 BaseDiscount
+definePromo() +definePromo()
«create» : ListLog
«COR-handleRequest» «COR-handleRequest»

Figure 12. Annotation of the promotions variation

point with the COR tags. generateReport()

2.4. Reports
Figure 14. Creating the appropriate report object
The report generation in WebShop relies on
the Separation construction principle (see «WebR-L» «interface»
request 1
Figure 13). Analogous to the Payment Report «WebR-H»
ReportImp
...
subclasses, a string is used to uniquely specify +report() «WebR-load»
+generateReport() «WebR-handle»

which class implementing Report should be

loaded the system, as illustrated in Figure 14. «WebR-CH»

The report() method is responsible for ListLog

+generateReport() «WebR-handle»
the dynamic loading of the appropriate
Figure 15. Using the Web Request tags to model
ReportImp class and for the invocation of the the report generation variation point.
generateReport() method, which returns a
string containing the report written/generated Web Request keeps the execution of a request
in HTML. For example, class ListLog lists the flexible and applies the Separation
entire log while class ByProduct might lists construction principle [2] for this purpose. The
the transactions related to a given product. «WebR–load» method is responsible for
dynamic loading of the appropriate «WebR–
«Sep-T»
reportImp 1
«interface»
ConcreteHandler» class based on its input
Report «Sep-H»
ReportImp arguments
...
+generateReport() «Sep-h»
+report() «Sep-t»
«adapt-dyn» 3. Conclusions
ListLog ByProduct
The paper presented the core components of
+ generateReport() + generateReport()
the WebShop framework, which focus
Figure 13. Annotating the report variation point
assisting the development of online stores. The
through the Separation construction principle tags UML extensions, namely the UML-F profile
[1] used to describe WebShop proved very
2.5. The Web Request pattern effective to provide an application developer
an intuitive and easy overview of the
As the design used for the Report variation framework. The UML-F profile mainly
point is analogous to the one used for provides a set of tags together with
Payment, and as it is quite useful to have a mechanisms to introduce new tags and to
dynamically created object to treat end-user describe their meaning and intention in an
requests, we define a domain-specific pattern informal yet systematic way.
called Web Request. The payment and
administrative reports variation points both
use the Web Request structure. Payment, for
4. References
[1] M. Fontoura, W. Pree, and B. Rumpe, The
UML Profile for Framework Architectures,
Addison-Wesley, 2001.

[2] E. Gamma, R. Johnson, R. Helm, and J.

Vlissides, Design Patterns: Elements of
Reusable Object-Oriented Software, Addison-
Wesley, Reading, MA, 1995.

[3] W. Pree, Design Patterns for Object-

Oriented Software Development, Addison-
Wesley, ACM Press, 1995.

[4] J. Rumbaugh, I. Jacobson, and G. Booch,

The Unified Modeling Language Reference
Manual, Addison-Wesley, 1998.