An Architectural Pattern for Developing Renting

Transcription

1 An Architectural Pattern for Developing Renting Systems Haitham Hamza 1 and Mohamed E. Fayad 2 1 Computer Science and Engineering Dept., University of Nebraska-Lincoln Lincoln, NE 68588, USA Ph: hhamza@cse.unl.edu 2 Computer Engineering Dept., College of Engineering, San José State University One Washington Square, San José, CA Ph: , Fax: m.fayad@sjsu.edu ABSTRACT Despite the fact that renting is, to some extend, an application dependent activity, it is still possible to extract many fundamental common aspects that if captured in an appropriate conceptual level, a stable renting model can be developed and reused to build a wide range of renting systems. In this paper we propose an architectural pattern that model the renting problem. This pattern aims to provide a model that captures the core aspects of the renting problem independent of any specific application or domain. We demonstrate, through illustrated examples, the usage of the proposed pattern under different renting scenarios in different applications. 1. SOFTWARE STABILITY AND STABLE ANALYSIS PATTERNS: BRIEF BACKGROUND The pattern proposed in this paper is based on the concept of Stable analysis patterns introduced in [2,3,4]. The idea behind stable analysis patterns is to analyze the problem under consideration in terms of software stability concepts [7]. Software stability stratifies the classes of the system into three layers: the Enduring Business Themes (EBTs) layer (contains classes that present the enduring and basic knowledge of the underlying industry or business, and hence, they are extremely stable), the Business Objects (BOs) layer (contains classes that map the EBTs of the system into more concrete objects. BOs are tangible and externally stable, but they are internally adaptable), and the Industrial Objects (IOs) layer (contains classes that map the BOs of the system into physical objects.). Figure 1 depicts the three layers of software stability model. The detailed characteristics of EBTs, BOs, and IOs and useful heuristics and examples of identifying these concepts in real applications can be found in [5,8,9]

2 Unstable Leafs- IOs Layer Stable Base Concrete Objects- BOs Layer System Core Knowledge- EBTs Layer Figure1. Software stability concepts layout 2. PATTERN DOCUMENTATION Problem Given the fact that renting applications have different natures, which reflect on their development, and given the fact that many fundamental common aspects do exist between these heterogeneous applications, the problem we focus on in this paper is to develop a renting architectural pattern with the appropriate abstraction level that can capture the common aspects across different renting systems, and hence, can be reused to build a wide range of renting systems. Forces The following are the main forces that the proposed pattern should resolve: Renting is an activity that can be conducted by a variety of participants. For instance, an organization can rent a property from a person and vise versa. Also, renting can take place between two persons or more, two companies, or a person and a company etc. The model should provide a systematic and easy way to be adapted to any kind of participants. A renting usually conducted upon a negotiation then an agreement. However, these two factors depend greatly on the application nature. The pattern should include these two factor while at the same time maintain an appropriate abstraction level. Renting systems usually involve some sort of payment policy. Again, this policy might considerably vary according to the application nature. The pattern should include this requirement in an appropriate way to provide flexibility in implementing such policy according to the application in hand. Along with the payment requirements comes the issue of opening accounts, printing recipes, etc. These kinds of activities while presented in almost every renting

3 application they however do vary from one application to another, and sometimes they change within the same application over time. Pattern structure and Participants As a solution to the problem discussed in the problem section before, and to resolve the aforementioned forces, we propose a stable architectural pattern that model the renting problem. Figure2 shows the object diagram of the Renting pattern. The model has two EBTs: Renting and Negotiation. Objects AnyEntry, AnyAccount, Receipt, AnyParty, AnyLog, AnyAgreement, and LineItem are each externally stable and internally adaptable; they are the system s BOs. Each BO is mapped to a real life object using the appropriate IO. For instance, the BO LineItem is physically represented with the IO Car in this system. It is worth to note that when modeling a renting system or any system that might involve activities that need to access or allocate resources, it is common to think of Availability as possible class in the system [1] (in software stability approach this would be an EBT); however, we do not consider it so because it does not involve a process; it is simply a state or yes/no flag, so it doesn t have enough substance to warrant being modeled as an EBT. Renting desiers AnyParty initiates Negotiation signs AnyAgreement opens AnyAccount specifies LineItem has AnyEntry AnyLog has Receipt Figure 2. Renting Pattern Object Model Diagram

4 The model shown in Figure 2 presents the first abstraction level of the pattern. Each object except the renting object, form a sub-pattern that has its own description and structure. The second abstraction level contains the detailed structure of each of objects presented in the first abstraction level. For instance, Negotiation object has it is own structure. The details of this structure form the second abstraction level of the Renting pattern and can be found in [6]. Other sub-patterns detailed structure can be found in [10] unless otherwise specified. The participants of the Renting pattern are: Renting. Represents the renting process itself. This class contains the behaviors and attributes that regulate the actual renting process. Negotiation. Represents the negotiation process. This class contains the behaviors and attributes that regulate the actual negotiation process. The pattern diagram and detailed pattern description is provided in [6] AnyParty. Represents the renting handlers. It models all the parties that are involved in the renting process. Party can be a person, organization, or a group with specific orientation. AnyAgreement. Represents the result of the negotiation, which will define some of the aspects of the renting process (for instance, price, time period). It is important to note that in many cases negotiation ends with no agreement and thus it is considered to be failed (the seller of the car did not agree on the price proposed by the buyer and vise versa), however, in this case we expect that the agreement should provide this result by whatever mechanism. So one can view the agreement object as the result of the negotiation, which is not necessary a successful result. AnyAccount. Represents the opened renting account for the AnyParty that wish to rent the entity. AnyEntry. Represents the object that specifies the tracking criteria and entry format in the renting system. AnyLog. Defines the information that will be presented in the customer account. Receipt. Represents proof of rent that will be handed to the customer. It also proof the payment information for the renting process. Applicability To further illustrate the reusability of the Renting pattern, the pattern is used to model the renting of different applications: renting a car, and renting furniture. For simplicity, we provide the part of the system that is related to the use of the Renting pattern. Figure 3 depicts the object model of the renting car application. In this application we assume that the renter can accept the payment in any format (cash, credit card, etc). Figure 4 shows the object model of using the Renting pattern in the furniture system. We assumed in this case hat the renter provides different kinds of rooms (dining rooms, and bed rooms), and couches. The renter policy is to accept only a credit card payment.

5 EBTs BOs IOs Organization Representative Renting desiers AnyParty initiates Renter Negotiation signs AnyAgreement specifies opens LineItem Car pays AnyAccount has AnyEntry receives AnyLog has Receipt Payment Check Cash Credit Card Figure 3. Stable Object Model for Renting Car Related Patterns and Concluded Remarks In [11] a related pattern that deals with the resource rental problem was proposed. The pattern aimed to be general and abstract to capture a wide variety of rental applications; however, it is not flexible to accommodate some specific requirements in some applications [2,4]. In this paper we have proposed a stable architectural pattern for renting systems. The pattern captures the core aspects of renting, while at the same time, it maintains an appropriate abstraction level that makes it easy to be adapted to any application. The EBTs, BOs, and their relationships in this system are valid for any rental system independent of what is rented. Consequently the pattern can be reused as a base for modeling the rental of any entity. The developed pattern has been used to model two problems with different natures. We found that the proposed pattern is flexible enough to be easily incorporated into the two developed applications.

6 EBTs BOs IOs Organization Representative Renting desiers AnyParty initiates Renter Negotiation signs AnyAgreement opens AnyAccount specifies LineItem Couch Room receives pays has AnyEntry DiningRoom BedRoom AnyLog has Receipt Payment Credit Card Figure 4. Renting Pattern Object Model References [1] F.Dai and E.B.Fernandez, "A Pattern for the Request and Allocation of Limited Resources", Procs. of EuroPLoP [2] H. Hamza A Foundation For Building Stable Analysis Patterns. Master thesis. University of Nebraska-Lincoln, August [3] H. Hamza. Building Stable Analysis Patterns Using Software Stability. 4 th European GCSE Young Researchers Workshop 2002 (GCSE/NoDE YRW 2002), October 2002, Erfurt, Germany. [4] H. Hamza and M.E. Fayad. Model-based Software Reuse Using Stable Analysis Patterns ECOOP 2002, Workshop on Model-based Software Reuse, June 2002, Malaga, Spain.

7 [5] H. Hamza and M.E. Fayad. "A Pattern Language for Building Stable Analysis Patterns, 9 th Conference on Pattern Language of Programs (PLoP 02), Illinois, USA, September [6] H.Hamza and M.E. Fayad, The Negotiation Analysis Pattern, Eighth European Conference on Pattern Languages of Programs (EurPLoP 03), Irsee, Germany, June 2003 [7] M.E. Fayad, and A. Altman. Introduction to Software Stability. Communications of the ACM, Vol. 44, No. 9, September [8] M.E Fayad. Accomplishing Software Stability. Communications of the ACM, Vol. 45, No. 1, January 2002, [9] M.E. Fayad. How to Deal with Software Stability. Communications of the ACM, Vol. 45, No. 4, April 2002 [10] M.E. Fayad, H. Hamza, and M. Cline. Stable Software Patterns: Analysis, Design, and Applications. (Book in progress) [11] R.T. Vaccare Braga et al. A Confederation of Patterns for Business resource Management. Proceedings of Pattern Language of Programs 98 (PLOP 98), September 1998.