An Architectural Pattern for Developing Renting Systems Haitham S. Hamza1, Mohamed E. Fayad2 1
Computer Science & Eng. Dept.– University of Nebraska-Lincoln Lincoln, NE 68588-0115- USA 2
Computer Engineering Dept.- San José, CA 95192-0180 San José, CA 95192-0180–USA
[email protected],
[email protected]
Abstract. Despite the fact that renting is, to some extent, an application dependent activity, it is still possible that we 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 models renting systems. The abstraction level of the proposed pattern enables the use of the pattern in several applications and across domains. We demonstrate, through the means of examples, the usage of the pattern under different renting scenarios in different applications.
1. 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.
2. 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 adapt to any kind of participants. A renting is usually conducted upon a negotiation and then an agreement. However, these two factors depend greatly on the application nature. The pattern should include these two factors; while at the same time maintain an appropriate abstraction level. Renting systems usually involve some sort of payment policy. Again, this policy might vary considerably 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 at 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 application, do vary from one application to another, and sometimes they change within the same application over time.
3. Solution: Pattern Structure and Participants In the following, we first discuss the approach we use to develop the pattern proposed in this paper, and then, we present and describe the pattern. 3.1. Solution Approach Besides the aforementioned forces, there is another kind of force that makes the development of the Renting pattern a challenge. We refer to this kind of force as a “developmental force”. Developmental forces reflect the conflicting issues that we encounter while trying to capture and present the common aspects of different renting systems. The developmental forces share most of the common problems that appear in the domain engineering realm, where commonalties and variabilities analysis play a crucial role in developing domain models. In the context of this paper, we can consider Renting as the domain that we want to analyze. We confront the developmental forces by using the concepts of software stability [Fayad and Altman 2001], and stable analysis patterns [Hamza 2002] [Hamza and Fayad 2002]. Since the pattern proposed in this paper is based on these concepts, we review the relevant issues of these concepts. The idea behind stable analysis patterns is to analyze the problem under consideration in terms of software stability concepts. Software stability is a generic approach for modeling and developing software systems. In the stability approach, the classes of the system are classified into three layers: the Enduring Business Themes (EBTs) layer, which 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, which contains classes that map the EBTs of the system into more concrete objects. BOs are tangible and internally stable, but they are externally adaptable; and the Industrial Objects (IOs) layer, which contains classes that map the BOs of the system into physical objects. For example, a shipment business system XYZ (e.g. FedEx), will have “Transportation” as an EBT, which presents one of the core aspects of the shipment process. This EBT would be realized by a BO “Transport” which regulates the workflow of the transportation process. If XYZ Company decides to use only trucks for shipping, then “Trucks” would become an IO in this system. Later on, XYZ Company may use planes besides/or instead of the trucks to deliver goods, and hence a new IO “Plane” comes to the play. This upgrade should not cause XYZ a tremendous change in the infrastructure of the business. The EBT “Transportation” does not change, the BO “Transport” will be adapted to include the new regulations and requirements of the new shipping strategy, and finally, the IOs are unstable and are planned to come and go as the system evolves.
Figures 1 and 2 depict the three layers of software stability model and their relationships. The detailed characteristics of EBTs, BOs, and IOs and useful heuristics and examples of identifying these concepts can be found in [Fayad 2002].
Unstable Leafs- IOs Layer
Concrete Objects- BOs Layer
Stable Base
System Core Knowledge- EBTs Layer
Figure 1. Software stability concepts layout
0..* 0..*
EnduringBusinessTheme s
0..* 0..*
0..*
BusinessObjects 0..*
0..*
0..*
IndustrialObjects
Figure 2. The relation between SSM elements
3.2. Solution Structure As a solution to the problem discussed in the problem Section, and to resolve the aforementioned forces, we propose a stable architectural pattern [Buschmann, et. al. 1996] that captures the core knowledge of the renting problem. Figure3 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 noting 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 [Dai and Fernandez 2002] (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.
desires
Renting
1..*
AnyParty
2..*
2..*
Negotiation
signs
1..*
initiates
results in
AnyAgreement 1..*
1
opens
specifies
1
1..*
AnyAccount
LineItem
has
1 1..*
AnyEntry 1..*
AnyLog
1..*
has
1..*
Receipt
Figure 3. Renting Pattern Object Model Diagram
The model shown in Figure 3 presents the first abstraction level of the pattern. One way to view the model in Figure 3 is to think of it as a generic model that captures the core requirements of renting applications. We differentiate between two main participants in the pattern model, classes and patterns. Classes are defined as in any traditional ObjectOriented class diagram. Patterns present a second level of abstraction to the model, where each pattern is by itself another model that contains classes and, in some cases, other patterns. The reader might refer to the appendix to see how the Negotiation pattern is expressed as a second abstraction level. As shown in Figure 3, besides the tags that indicate whether the element in the object model presents a class or another pattern, we also use the prefix ‘any’ for patterns. For instance, AnyParty is a stand-alone stable
pattern that models the party notion and, hence, can be used to model any party in any application. The detailed structure of this pattern is out of the scope of this paper. Each object, except the renting object, forms a sub-pattern that has its own description and structure. The second abstraction level contains the detailed structure of each of the objects presented in the first abstraction level. The details of this structure form the second abstraction level of the Renting pattern. Other sub-patterns detailed structure can be found in [Fayad and Hamza] unless otherwise specified. We shall show in the next section of this paper the different abstraction levels and some comments on how this abstraction level links to the first abstraction level. 3.3. Participants The Renting pattern has two kinds of participants: Classes and Patterns. Patterns participants encapsulate other classes and patterns and are thought of as higher abstraction layers of the Renting pattern (See Section 3.5) 3.3.1 Classes: • Renting. This class encapsulates the renting process itself. The class contains the behaviors and attributes that regulate the actual renting process. 3.3.2 Patterns: • 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 [Hamza and Fayad 2004]. • 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 [Fayad and Hamza]. The structure of AnyParty is shown in Figure A.2 in the Appendix. • 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 vice versa); however, in this case we expect that the agreement should provide this result by any other mechanism. So one can view the agreement object as the result of the negotiation, which is not necessarily a successful result. • AnyAccount. Represents the opened renting account for the AnyParty that wishes to rent it [Fayad and Hamza 2003]. • AnyEntry. Represents the object that specifies the tracking criteria and entry format in the renting system [Fayad and Hamza]. • 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 proofs the payment information for the renting process [Fayad, Rajagopalan and Arun. 2003].
3.5. Abstraction Levels of the Renting Pattern Architectural patterns are usually more complex than simple design and analysis patterns. This is because an architectural pattern may embody several sub-patterns (components and sub-patterns are used interchangeably to refer to different parts of the Renting pattern) to solve a given problem. To better understand architectural patterns, we use different abstraction levels, where each abstraction level provides more details about the pattern structure. So far, we have only shown the first abstraction level of the Renting pattern (Figure 3). This “compacted” view of the pattern provides the big picture of the pattern structure. Once the overall idea is understood, we can delve into the detailed structure of the pattern by viewing the other abstraction levels. Abstraction levels in the context of stable patterns are obtained through a step-wise decomposition process. For instance, in the Renting pattern, the EBT called “Negotiation” is presented as a sub-pattern in the first abstraction level; however, in the second abstraction level, this black box should be replaced by its detailed structure (See Figure A.1 in the Appendix). In every abstraction level we decompose all the sub-patterns only once. For example, when we perform the first decomposition process on the Renting pattern, we will replace the sub-patterns Negotiation, AnyParty, AnyAgreement, AnyAccount, AnyEntry, AnyLog, and LineItem by their detailed structures. However; if we look at the detailed structure of the Negotiation Sub-pattern, we notice that there is a subpattern called AnyMedia, which does not exist in the first abstraction level of the Renting pattern. In the current decomposition step, we do not replace the AnyMedia sub-pattern with its details, but rather, we perform another decomposition step (second decomposition process in this example) to replace this sub-pattern (and others if any). In summary, to avoid the complication of expressing the overall pattern structure at once, we proceed step by step while replacing sub-patterns of the original pattern. The decomposition process continues until we express the pattern in classes, and hence, we end up with a conventional class diagram with no sub-patterns. The objective of the step-wise decomposition process above is not just to ease the pattern understanding but there is another important reason behind the step-wise approach. This reason is to detect and deal with overlapping of different classes and sub-patterns. Stable patterns may contain some classes and sub-patterns that overlap in their roles. For example, consider the very common case of the pattern AnyParty (See Figure A.2 in Appendix for the detailed structure of this pattern) that exists in many patterns. However, the AnyParty pattern should be presented only once in the detailed structure of the main pattern. Consider again the Renting pattern in Figure 3, one of the sub-patterns is AnyParty, now when we perform the first decomposition step we replace the “Negotiation” sub-pattern by its detailed structure, which contains the AnyParty as sub-pattern. In this case, the two AnyParty sub-patterns should be unified and represented only once in the abstraction level. The same argument applies for the AnyAgreement sub-pattern. This step-wise refinement simplifies the detection. Nonetheless, to unify overlapping classes while moving through different abstraction levels is not always obvious. A careful examination of the role of each class and subpattern must be done. One source of complication in detecting overlapping is when two or more classes or sub-patterns have similar roles but they have different names. In such
cases, both components should be unified to avoid redundancy and confusion. In addition, changes to the pattern structure may occur, for instance, new associations that were hidden within the components in the main pattern view may appear in different abstraction levels. These and other issues that are related to pattern integration are covered in great detail in [Fayad and Hamza]. Consider the Renting pattern of Figure 3, one sub-pattern in the Renting pattern is “Negotiation”. By looking at the structure of the Negotiation pattern (Figure A.1 in Appendix); we see that some of the participants are already presented in the first abstraction level of the Renting pattern. For example, the AnyParty pattern exists in both patterns. From the context of the two patterns (Renting and Negotiation), it appears that these two AnyParty sub-patterns have the same roles, and therefore, they must be unified in the detailed view of the Renting pattern. The same situation applies for the AnyAgreement pattern. Another type of overlapping that we should consider, is the semantic overlap of classes/patterns with different names. For example, the EBT Renting in the Renting pattern is semantically equivalent to the pattern AnyContext in the Negotiation pattern. Note that the AnyMedia pattern will be added when we view the details of the Renting pattern; this pattern has not been considered in the Renting pattern itself.
4. Illustrative Examples To illustrate the use 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 only the part of the system that is related to the use of the Renting pattern. Based on the stability structure shown in Figures 1 and 2, the use of the Renting pattern is basically through the addition of the IOs and the adaptation of the external hooks of the BOs. 4.1. Example 1: Modeling Renting in Car Rental Business Figure 4 depicts the stable model of the renting car application. In this example, the AnyParty that are involved in the renting process would be representative of the renting company and the customer. Both objects are represented as IOs in the car rental model. The BO “Receipt” is realized in the model by the IO “Payment”, and this payment can take any form as cash, credit card, etc. Changing the payment option should not affect the core aspect of the business itself. The concept of Receipt exists whether you pay with credit card or cash. However, the Payment procedure for both paying options differs, in the credit card payment an ID card may be required which is not the case when the cash option is used. In addition, we can notice that the LineItem BO is instantiated with the IO Car. Different types of cars can be plugged into the model in the form of inheritance from the Car IO, without affecting the core of the model. 4.2. Example 2: Modeling Renting in Furniture Business In Figure 5 we show how the Renting pattern is applied in another business context; renting furniture. As can be seen from the figure, all the changes are in the IO layer, where new IOs that are relevant to the problem are added. Note that, the Receipt BO is
still there and is relevant to the new application. This BO has been adapted to the nature of the furniture business (a receipt of renting a car is completely different from that of renting a bed); however, the Receipt BO should contain the core common aspects of the receipt concept leaving the application-specific details to be implemented by the developer of the application.
EBTs
BOs
IOs Organization Representative
1..* desires
1..*
Renting
AnyParty Renter
signs
initiates results in
Negotiation
AnyAgreement 1..* opens
1..* 1..*
specifies
1
LineItem
pays
Car
AnyAccount 1
receives
has 1..*
AnyEntry 1..*
AnyLog
1..* has
1..*
Receipt
Payment
Check
Cash
Credit Card
Figure 4. Part of the stable model for renting car example
The point that we want to stress here is the fact that even though changes are needed to the BO Receipt based on the context of the application, this BO does exist in any renting system, which is why we considered Receipt a BO. If the furniture business decides to stop renting rooms or add more flexibility to the payment options (include cash, for example), these modifications can be easily accommodated in the model without affecting the core of the business, which is represented by the EBTs and BOs. Note that we do not decompose the Renting pattern to its detailed structure. Rather, we use the highest abstraction level of the pattern. Thus, the models depicted in Figures 4 and 5 are not complete. For instance, the Negotiation pattern has a sub-pattern called “AnyMedia” (See Figure A.1 in Appendix). If we had expressed the Renting pattern in more details, the “AnyMedia” sub-pattern (not shown in this paper) will appear and hence new IOs would appear as a consequence. For instance, in the car renting example, IOs such as mail, telephone, email might appear as a representation of the media over
which the renting would talk place. The AnyMedia sub-pattern provides a good flexibility in expressing the kind of media that “AnyParty” may use to rent the car.
EBTs
BOs
IOs Organization Representative
1..* desires
2..*
Renting
AnyParty
initiates
Renter
signs results in
Negotiation
AnyAgreement 1..*
1..*
specifies
Couch
1..*
receives
opens
LineItem
1
pays
Room
AnyAccount 1 has
1..*
DiningRoom
AnyEntry
BedRoom
1..*
AnyLog
1..*
1..*
Receipt
Payment
has
Credit Card
Figure 5. Part of the stable Model for renting furniture example
5. Related Patterns and Concluding Remarks In [Vaccare Braga et al. 1998], 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 [Hamza 2002a] [Hamza and Fayad 2002]. 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 independently 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.
Acknowledgement The authors would like to thank Rosana Teresinha Vaccare Braga, our shepherd, for her faithful help and valuable discussions and comments that have improved this paper considerably.
References Fayad, M.E. and Altman, A. (2001) “An Introduction to Software Stability” Communications of the ACM, Vo. 44, No. 9, September 2001, pp 95-98. Fayad. M.E. (2002) “How to Deal with Software Stability,” Communications of the ACM, Vol. 45, No. 4, April 2002 Dai, F. and Fernandez, E.B. (2002) "A Pattern for the Request and Allocation of Limited Resources", Proceedings of European Pattern Language of Programs’ 2003 (EuroPLoP’03).
Hamza, H. (2002) “A Foundation For Building Stable Analysis Patterns”, Master Thesis. University of Nebraska-Lincoln, 2002 Hamza. H. and Fayad, M.E. (2002) “Model-based Software Reuse Using Stable Analysis Patterns” ECOOP 2002, Workshop on Model-based Software Reuse, June 2002, Malaga, Spain. Fayad M.E. and Hamza H.S. Stable Software Patterns: Analysis, Design, and Applications. (Book in progress) Fayad, M.E., Rajagopalan, J. and Arun. A.(2003) “The AnyLog Design Pattern”, The 2003 IEEE International Conference on Information Reuse and Integration, Las Vages, NV, October 2003. Hamza, H.S. and Fayad, M.E. (2004) “The Negotiation Analysis Pattern”, 11th Conference on Pattern Language of Programs (PLoP 04), Illinois, USA, September 2004. Buschmann, F., Meunier, R., Rohnert, H., Sommerland, P., and Stal, M. Pattern-Oriented Software Architectures. Wiley, 1996. Fayad, M.E. and Hamza, H. (2003), “The AnyAccount Pattern,” Proceedings of Pattern Language of Programs’ 2003 (PLoP’03), Monticello- Illinois, USA, Sept. 2003. Vaccare Braga, R.T. et al. (1998) “A Confederation of Patterns for Business resource Management”, Proceedings of Pattern Language of Programs’ 98 (PLoP’98), September 1998.
Appendix: Brief Description of the Negotiation and the AnyParty Patterns A.1 The Negotiation pattern [Hamza and Fayad 2004]:
AnyContext 1..* negotiates AnyMedia
1..* uses
EBT
handels
1..*
AnyParty
Negotiation
1..*
1..* generates
contains
1..*
enforces
AnyAgreement
FigureA.1. Negotiation pattern stable object model
As shown in Figure A.1, the Negotiation pattern consists of the following participants: Classes: • Negotiation: Represents the negotiation process itself. This class contains the behaviors and attributes that regulate the actual negotiation process. Patterns: • AnyAgreement: Represents the result of the negotiation. The ultimate goal of any negotiation is to reach an agreement. Thus, this object presents a core element in any negotiation. 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. • AnyParty: Represents the negotiation handlers. It models all the parties that are involved in the negotiation process. Party can be a person, organization, or a group with specific orientation. The pattern diagram and detailed pattern description is provided in [Fayad 2002]. • AnyMedia: Represents the media through which the negotiation will take place. For instance, one can negotiate the price of a good over the phone. Others might use an email or a mail to negotiate specific issues in their business. The pattern diagram and detailed pattern description is provided in [Fayad 2002].
•
AnyContext: Represents the matters to be negotiated. If we are buying a home, many issues could be negotiated. For instance, the price of the home, the payment procedure, etc. Defining negotiation issues is an essential element of any negotiation process; otherwise, negotiation would have no meaning. The pattern diagram and detailed pattern description is provided in [Fayad and Hamza].
A.2 AnyParty Pattern Problem
How to build a model that can be used to present any party in any application? Context
The pattern can be used in any application that involves the interaction of AnyParty of any kind and structure. Solution and Participants
Figure A.2 shows the object diagram of the AnyParty pattern.
Orientation
1..*
defines
0..*
Role_1
AnyParty
Role_2
Role_3
Figure A.2. AnyParty pattern object diagram Participants
The participants of the AnyParty pattern are: • AnyParty. Defines the different possible roles within a specific party. • Orientation. Describes the common motive by which party’s member are grouped.
