for personalized or customized software [Koch 02, Kappel 01]. These approaches emphasize a clear separation of concerns among the application objects, the.
Customization Policies need more than Rule Objects Juan Cappi, Gustavo Rossi, Andres Fortier LIFIA-Facultad de Informatica-UNLP Calle 50 y 115, La Plata (1900) Buenos Aires, Argentina Tel/Fax: 54 221 4236585 {jcappi,gustavo,andres}@lifia.info.unlp.edu.ar
Abstract. In this paper we analyze the process of mapping business policies into object-oriented software structures. We stress that separation of concerns is a key strategy for obtaining high quality and evolvable implementations. In particular, we show that a naive mapping of business policies into object rules may result in a bad design compromising the overall software stability. We first present our work in the context of customizable of e-commerce applications, and briefly explain why customization functionality should be dealt by separating concerns. We next present our approach for combining object rules with other object-oriented design structures; we show that these modular software constructs allow seamless evolution and maintenance.
1-Introduction and Related Work Customization has become a very important issue in e-commerce applications. Adapting this kind of applications may mean building different interfaces, (customized to a particular appliance) providing personalized navigation paths, offering different pricing policies, customized checkout procedures, etc. Not only we need to design an application model, but also to design and apply different business policies, manage information about the user and his profile, etc. Furthermore, as we must also cope with constant changes of these policies, the design should be modular enough to make evolution seamless. So far, little attention has been paid to the modeling and design process of this kind of software. Only recently, some authors have proposed reference design architectures for personalized or customized software [Koch 02, Kappel 01]. These approaches emphasize a clear separation of concerns among the application objects, the customization rules and the user profile. They follow a widely used strategy for modeling business rules as first-class objects, thus decoupling them from the application-specific code [CommonRules 02, RuleML 02]. The user profile is also represented as a set of objects addressing different user preferences (language, location, etc). User profiles are often described as aggregations of objects whose attributes contain plain information such as “English”, “Los Angeles” and the like. Customization and other business rules use this information by checking these attributes and performing corresponding actions. The main thesis in this paper is that existing approaches fail to provide a good and modular platform for implementing customization policies.
While the rules paradigm works fine with some kinds of business policies, it may end with a large and flat set of similar rules thus complicating maintenance. Moreover, treating information in the user profile as low-level objects (such as strings or numbers) neglect polymorphism and, as a consequence, makes this kind of software evolution a nightmare. We present an original approach for complementing customization rules with more general customizer objects for building maintainable software. The structure of the rest of this paper is as follows: We first discuss existing architectural constructs for decoupling concerns in customizable software and introduce an example to illustrate our ideas; we next show that a wise application of objects polymorphism allows us to build composite customizer objects combining different customization policies. Though this paper is based on our previous experience with the (OOHDM) Method [Schwabe 98], the underlying ideas can be used in a straightforward way with other object-oriented approaches.
2-Customization in Business Applications While building customizable object-oriented software, it is useful to understand what aspects of an application can be customized. For some years we have mined recurrent patterns in e-commerce applications, focusing on one of the most usual customization types: personalization [Rossi 01]. These (coarse grained) patterns allow us to focus on what can be customized before addressing which concerns are involved in the customization design process. Summarizing we can customize: · the algorithms and processes described in the application model (e.g. different recommendation strategies, pricing policies or check-out processes for different users, etc) · the contents and structure of object’s interfaces and the link topology in the resulting interface (e.g., building customized home pages such as in my.yahoo.com) · the look and feel of the interface and the interaction styles (for example according to the interface artifact, e.g. a cellular phone, a PDA, etc). Most approaches for mapping business rules into object structures have focused on the first kind of customization, i.e. emphasizing on process customization according to different object’s values that reflect business states [CommonRules 02]. The main rationale for separating rules from application code is to achieve a better degree of concern separation, thus eliminating spurious if clauses inside object’s methods. However when we need to implement customization policies that deal with a user profile, rules are not always the best solution
3-Reference Architectures for Customizable Software Existing approaches for building customizable software clearly separate the most important design concerns related with customization, namely the application model, the customization rules and the user profile.
Each module can be considered itself a simple micro-architectural component; the interaction between these components should follow well known patterns in order to keep the software manageable. In order to make this discussion concrete, we introduce a simple example here. Suppose an electronic store that sells products to customers. When he decides to buy, the check-out process generates an order containing products, paying mechanism, shipping address and price and delivering options. Each customer has an account containing his buying history. While variations in the domain model such as adding new products or paying mechanisms can be solved by sub-classing and composing objects, if we want to introduce some personalization capabilities, we face a new problem: mixing customization code with application logic. Following the previous idea we will have at least two other software modules for dealing with personalization: · The user profile: that contains information about the customer’s interests; it will need to interact with some application’s objects such as the Customer and Account objects (by the way one may argue that it is debatable whether these classes should be part of the user profile). When software adaptation involves other aspects (such as date or time) a separated context model is also necessary. · The rule model: that encapsulates different kinds of rules, for example for calculating a personalized price, etc; when dealing with event/condition/action rules, separated event objects will be used. However, existing approaches fail to address two key aspects for building this kind of software: how to seamlessly connect application code with customization components and the process of rules engineering and design. We have shown an approach for solving the first problem in [Cappi 01] by associating customizer objects to each customizable behavior. When an application object receives a message whose answer must be customized, a customizer object is in fact activated; it interacts with the original object, the user profile and the context to generate the correct answer. We will not elaborate the activation of customizer objects in this paper but will focus instead on the engineering of customization policies, which is described in the following section.
4-Mapping Customization Policies into object designs Customization policies express different ways of adapting information and processes to the current context, e.g. the user, date, network connection, etc. It is relatively straightforward to describe policies using a rule-based language, for example eventcondition-action (ECA) rules. However it is not so easy to map those “conceptual” structures into good software structures. For example, how should we design a policy such as: “Information should be presented in the user language”? The naive solution would be to map it into a set of rule objects checking the user profile for the user language and acting in consequence. In the same way, we can customize the information the user perceives to the type of interface appliance he is using, by writing a set of rules that according to the artifact (PDA, internet browser, cellular phone) invokes a different method for generating the corresponding information.
In both cases, we end with a flat set of rules checking the type of an object that we have hidden in a string variable. We are thus neglecting polymorphic behaviors. Meanwhile, it is clear that a policy such as: “Discount a 10% of the regular price to frequent buyers” is easily mapped into a rule object (once we precisely define the meaning of “frequent”) in which the corresponding condition checks the user account and the action object calculates the new price. Here, rule objects help us to get rid of malicious if then else clauses. To make matters worse, it is easy to find applications in which the same aspect of an object (e.g. the product’s price) is affected by “hybrid” policies combining the style of the two previously shown examples, e.g. “Customers that live in x should receive an additional y% discount”. We claim that if we want to achieve stable and modular implementations, we must careful study the nature of each part of the policy (i.e. condition, action) to decide how we map the policy into a good software structure. As said before, we ignore the nature of events (that in fact trigger the customization code) and focus on the pair condition/action. 4.1 Customizer Objects to the Rescue Even though rule objects represent a good solution for decoupling customization code from base application behaviors, their use should be cautiously evaluated to avoid large sets of flat rules. Treating user profiles or execution contexts (e.g. type of network connection) as data objects with string-based attributes, results in rules that basically query those attributes for specific values in order to decide corresponding actions (See for example [Kappel 01]). Our approach is based on the fundamental idea that rules should replace if clauses but not polymorphic behaviors. Therefore, when the condition of a customization policy deals with the possible types of an object, we must replace rules with operations that delegate to an object belonging to a class hierarchy of polymorphic classes, each of them providing the corresponding implementation of the policy action. In other words, when a policy condition checks if T=Ti to apply an action Ai , we must build a class hierarchy for different Ti in which each class implements the corresponding Ai behavior. This hierarchy will be usually part of the current profile (describing the user and its context). In most real applications we have found very easy to identify these situations; for the sake of conciseness we only give some examples related with the previously mentioned e-store. Suppose that we want to customize the checkout process according to some user attribute such as his address. For example, we may have a policy such as: “if the customer lives in north-America he does not pay for the shipping, if he lives in Europe he pays a reduced shipping price and if he lives in the rest of the world he pays a regular price”. A naive solution is to have some string attribute in the user profile such as continent allowing us to write a condition on this attribute to trigger the corresponding action. A better solution is obtained by:
· Creating a hierarchy of Continent classes (that may later evolve into a hierarchy of countries if needed). Each class has a behavior for returning the actual discount with respect to the regular price. · Redefining the user profile by associating a continent object to each user. · Associating a customizer object to the shipping price behavior (in Class Order); when the order (or the corresponding shipping object) has to inform the shipping price, the customizer object for this behavior is activated. It next delegates into the corresponding continent object in the user profile, which returns the discount. Notice that the user profile now contains more “intelligence” than in the former solution: it knows which objects it has to invoke to perform the checkout. We have in fact replaced the set of rules that check the continent by a polymorphic behavior activated from the customizer object. From the point of view of design complexity this solution may seem a bit more complex (in fact rules are easy to engineer) though it may require creating less classes than the rule-based schema, where we need sub-classes for actions and conditions. This resulting approach is easier to maintain. 4.2 Composite Customizers It usually happens that we need to implement different customization policies for the same application aspect (e.g. the price of products). Some of them may be mapped into rule objects and others into customizers, e.g. the discount policy depends on the customer address and on the number of products he bought before. Even if we implement all of them as rule objects, we need to provide a way to solve conflicts (for example two different discount policies that should not be applied together). In the most general case we may want to combine different kind of customization policies, independently of the design structure we chose to implement them. Our approach for solving this problem is treating customizer objects as recursive composites [Gamma 95]; the leaves of the composite may delegate to a rule object (rules may be also composites), to some user (or context) profile object, or may just provide the customization behavior. In each composition level there may be a conflict solver (the composed object whose parts may have conflicts). Then, for each customizable aspect in our application we have a customizer object; this object may just initiate the execution of a set of rule objects, may delegate to some “intelligent” profile object (that itself may even delegate in some application object) or may just recursively delegate to other customizers. 4.3 User Profiles and Contexts As mentioned in section 4.2 our approach requires a significant change in the way in which user profiles and usage contexts are designed. Frequently, existing approaches for modeling the user and the environment (network connection, interface appliance, etc) treat these objects as passive data repositories in which information is described with atomic values such as strings or numbers.
We claim that a better approach is needed; it is necessary to carefully engineer these descriptions with a pure object-oriented view; in particular, possible values of profile or context attributes (such as the user’s address, the sports he practices, the kind of connection, etc) should be designed as instances of a class in a hierarchy offering polymorphic behaviors. In this way we simplify evolution and maintenance, as changes related with customization are located in these classes. Moreover, we get a better balance of customization related behaviors, as we don’t need to locate all of them in action rule classes (such as action classes in [Kappel 01]).
5-Conclusions and Further Work In this paper we have outlined an integrated approach for mapping customization policies into object structures. This approach complements existing work by showing when policies should be implemented as rules, when using polymorphic objects or combination of both types of design solutions. Our approach is non-intrusive because it provides architectural mechanisms for adding extra functionality (e.g. customization) without re-coding the base business logic. We are now exploring some complementary research directions. First, we are studying how to use UML stereotypes for simplifying class diagrams that involve customizers and rules. We are also working on visual tools for simplifying the personalization process by allowing the designer to plug personalizers to base objects easily.
6-References [Cappi 01]
J. Cappi, G. Rossi, A. Fortier, D. Schwabe: “Seamless Personalization of ECommerce applications” in Proceedings of e-Como 01 (Workshop on Conceptual Modeling in E-Commerce), (ER2001), Japan, December 2001. [CommonRules 02] http://www.research.ibm.com/rules/commonrules-overview.html [Gamma 95] E. Gamma, R. Helm. R. Johnson, J. Vlissides: “Design Patterns. Elements of reusable object-oriented software”, Addison Wesley 1995. [Kappel 01] G. Kappel, W. Retschitzegger and W. Schwinger. “Modeling Ubiquitous Web Applications: The WUML approach”. International Workshop on Data Semantics in Web Information Systems (DASWIS-2001), (ER2001), Yokohama, Japan, November 27-30, 2001 [Koch 02] N. Koch, M. Wirsing: “The Munich Reference Model for Adaptive Hypermedia Applications”, to be presented at 2nd International Conference on Adaptive Hypermedia and Adaptive Web Based Systems [Rossi 01] G. Rossi, D. Schwabe, J. Danculovic, L. Miaton: “Patterns for Personalized Web Applications”, Proceedings of EuroPLoP 01, Germany, July 2001. [RuleML 02] The Rule Mark-up Language, in http://www.dfki.uni-kl.de/ruleml/ [Schwabe 98] D. Schwabe, G. Rossi: “An object-oriented approach to web-based application design”. Theory and Practice of Object Systems (TAPOS), Special Issue on the Internet, v. 4#4, pp.207-225, October 1998. [Schwabe 02] D. Schwabe, G. Rossi, R. Guimaraes: “Cohesive design of personalized Web applications”, IEEE Internet Computing, March 2002.
