A Family of Patterns for Business Resource Management

Transcription

1 Abstract A Family of Patterns for Business Resource Management Rosana T. Vaccare Braga ICMCUniversidade de S o Paulo/ Universidade de Franca C. P. 668, S o Carlos SP Brazil Phone Number: / [email protected] Fern S. R. Germano ICMCUniversidade de S o Paulo [email protected] Paulo Cesar Masiero ICMCUniversidade de S o Paulo [email protected] A family of patterns that covers a great number of applications in business systems is presented. Business Resource Management is the term used to d efine these a pplications. It i ncludes patterns for Resource Rental, Resource Trade a nd Resource Maintenance. They are a pplied to examples as medical attendance, video rental, real estate rental, library service, show box office, fertilizer retail store, car repair shop and electronic appliance repair shop. The work is based on professional practice, and results from the combination of recurring patterns, already covered in other PLoPs. The practice used mostly procedural languages, but through object oriented reverse engineering of real systems it was possible to explicit the presented object oriented patterns. Introduction We present a family of patterns for designing systems for business resource management. Most business have some assets that they use to make money. Sometimes they buy and sell them. Sometimes they rent them out and sometimes these assets deteriorate and have to be repaired. This family results from more than ten years of practice of systems development for medium and small business. Most of this practice has been done using procedural languages, but after getting acquainted with the concept of software patterns it was possible to recognize patterns as the basis of the reuse that has been done in the construction of more than twenty systems. They cover electric and mechanical car repair shops, television and video cassette repair shops, fertilizer r etail stores, motorcycle dealers, electronic a ppliance repair shops, perfume retail stores, videorental stores, odontological attendance, publicity agencies, etc. In all these systems, some objects can be easily identified, as well as the methods they involve, their relationships and attributes. For example, customer or party is a common object, with its usual attributes like code, name, address, etc. Another object that appears repeatedly is resource, with transactions to relate it to the parties. If we try to use recurring patterns to each of these situations, we can observe that many patterns are similarly applied. The family of patterns here presented, called Business Resource Management, includes three patterns that are formed by recurring patterns originally proposed by Coad [Coad 92], Fowler [Fowler 97], Johnson [Johnson 98] and Boyd [Boyd 98]. Their combination for the applications mentioned above have common points that are covered in the presented family of patterns. The similarities among these systems make it worth to think about how to establish a pattern that could come to the mind o f designers when they are developing a system in the domain. Financial support from CNPq and FAPESP

2 Business Resource Management is broken down to Resource Rental Pattern, Resource Trade Pattern and Resource Maintenance Pattern. These, however, are not mutually exclusive. Resource Rental focus mainly on the satisfaction of a certain temporary need of a good, like the use of a physician time for an attendance or the use of a videotape for seeing a motion picture. Resource Trade focus on the transference of property of a good. For instance, real estate purchase or sale would be an instance of Resource Trade while real estate rental would be an instance of Resource Rental. Resource Maintenance focus on the maintenance of a certain good, using labor and products to perform it, as in an electric appliance repair shop. The following sections describe in detail the three patterns that compose the family of patterns presented. The notation u sed to express the patterns is UML (Unified Modeling Language) [Eriksson 98, Fowler 98]. 2 Resource Rental Pattern 2. Context Books in a library, doctor time in medical attendance, video tapes in video rental, properties in real estate rental and places in shows are examples of resources available for rental. Even sharing many points in common, not all these resource rental systems are e qual. Each one has its own peculiarities. They do, however, have similarities that are to be considered if we want to maximize the reuse of analysis, design and code. Borrowing a book in a library is not the same as renting a video in a rental shop. For the book you don t pay a daily rate, but you do pay a fine for delayed return. 2.2 Problem Many business systems deal with the rental of business resources for a certain period of time after which they are returned to their owners. 2.3 Forces Resource rental refers to a ce rtain g ood that has to have a unique identification, as well as a description of its characteristics. Sometimes the customer does not know precisely the identification of the good he/she is willing to rent. For example, in a video rental application, the customer may know the director or actress of a movie but not remember its title. Both financial and administrative departments of an organization need to have data about each rental, as for example, its duration, payment or fine for delay in return, etc. For most organizations, it is important to control each instance of the good that is rented. Some controls, however, refer to the good itself. The purchase department may have to know what type of good is more demanded for rental, when acquiring new goods. Customers may want to be sure to have a certain good available for rental at a certain time. 2.4 Solution In Figure we present the Resource Rental Pattern. A customer can rent a resource for a certain period of time. Usually, the resource to be rented has several copies or instances that have to be distinguished by the system. If this is not the case, the Resource Rental class is linked to the Resource class, instead of being linked to Resource Instance class. The resource has attributes such as code, description and qty of available instances, the first to identify it, the second to describe it and the third to show its present quantity of available instances. The customer has attributes code and name, the first also to identify it and the second containing his/her name. The resource instance has the attribute number that usually is a sequential number assigned to each instance of the resource; the attribute location that contains the place where the resource instance is kept; and the attribute status to show if it is or is not currently available. The classes Resource, Resource Instance and Customer have accessor methods and, to assign or retrieve values to its attributes, respectively. The rental l asts for some time, which is measured from minutes to years, 2

3 depending on the application. A booking transaction may refer to several resources. A rental transaction, on its part, may refer to several resource instances. These group transactions allow collective or individual treatment, according to the customer convenience. The organization or a customer may wish to have a list of rentals made by a specific customer. Also, it is important to have the possibility of listing all rentals made of a particular resource, for example, to control its usage. Some attributes of a resource rental are the start date, the expiring date and the rental rate to be charged for the rental. Methods to rent the resource, which register a new rental, and to check out the resource, which return the resource to the available condition, are necessary. An optional method, Calculate earnings, may be used to totalize the profits provided by the rentals made in a certain period of time. The customer can do the rental directly, or can book it previously, that is, if the resource is available when the customer wants it, then he/she rents it immediately. But if the resource is not available a t the moment, or if the user wants to guarantee that it will be available when he/she needs it, then a booking is necessary. Usually, the booking is made to the resource itself, while the rental is associated with a particular instance of the resource. A booking fee can be collected too. When a resource is rented after a previous booking, the booking is automatically quitted. A resource booking can be cancelled if the customer gives up to rent the resource. The rental usually results in some kind o f payment, that can be split in installments. If so, each installment has a due date, so that if this date is in the past, the installment is overdue or paid and if it is in the future it represents a coming installment. The attribute situation takes care of acquitting an installment when the customer pays it. While a resource instance is rented to a customer, it cannot be rented to any other customer, but the resource itself can be booked for future rental. A resource can often be grouped into types of resource, to provide the user some summaries by type. The core part of the Resource Rental Pattern is composed of the classes Customer, Resource and Resource Rental. The c lasses Resource Instance, Type of resource, Resource Booking and Payment are optional and their utilization has to b e e valuated in each particular application. For example, if payment recording is not important for the system being developed, the Payment class could be simply discarded, and an attribute might be placed in the Resource Rental class to contain a summary of payment options. The Resource Rental Pattern embeds other r ecurring patterns, as will be shown in the related patterns section. Customer bookings by customer rentals by customer Resource Booking Booking Date Period Booking Fee Book Cancel booking Resource Qty of instances available bookings by resource Resource Rental Starting Date Expiring Date Rental Rate Rent resource Check out resource Calculate earnings Type of resource.. Resource Instance Number Location Status rentals by inst. Payment Payments done Figure Resource Rental Pattern 3

4 A variant of this pattern could be created to cope with the situation in which the customer wants to book a particular resource instance. For example, the reader may want a book of a certain edition. In this case, another class named Resource Version can be created associated with the Resource class and the Resource Instance class. The Resource Booking class, in this case, can be linked to the Resource Version class instead of the Resource class. One resource may have several resource versions, and each resource version may have several instances. 2.5 Examples 2.5. Library Service Figure 2 shows the instantiation of the Resource Rental Pattern for a library service system. The reader can reserve a book before it is actually borrowed. The possible types of books are technical, scientific, fiction, literature, etc. The payment for the lending is substituted by the fine for delayed return of the book borrowed. Probably the fine is paid in cash, so there is no need to have attributes such as due date, installment number and situation. Another solution would b e to d iscard the c lass Fine a nd to add its attributes and methods to the class Book Lending, although it would waste space as only a few customers usually delay the return. Some other peculiarities have to b e noticed as, for example, that a certain book can have several copies. Booking is made for the book but what is actually borrowed is the copy. Reader reservations by reader lendings by reader Book Reservation Reservation Date Reserve Cancel reservation Book ISBN Title Author Qty of available copies reservations by book Book Lending Lending Date Returning Date Rent book Return book Type of book.. Book Copy Number Rack Position Status lending by copy Fine Fines done Figure 2 Instantiation of Resource Rental Pattern for a library service Medical Attendance Figure 3 shows the instantiation of the Resource Rental Pattern for a medical attendance system. If the medical attendance is done in a large hospital, for example, the booking is made for a certain specialty, without knowing which doctor will actually do the attendance. For small doctor s offices, however, the class Resource Instance may disappear, as the doctor leading each specialty is only one. In the a ttendance, instead of the starting date and the expiring date of the resource rental there is only the attendance date and hour. So, the method to check out the resource is not necessary. Some specialties may be grouped in medical areas; for example, pediatrics is an area where there are surgeon experts, neurologist experts, neonatologist experts, etc. The payment can be made in installments and the date in which they are due is object of control. The Resource attribute Qty of available instances is not applicable here, as the resource occupancy is short and this kind of control would not make sense. 4

5 2.5.3 Video Rental Figure 4 shows the instantiation of the Resource Rental Pattern for a video rental shop. This is the most obvious application of this pattern. Here, also, there can be more than one tape for a certain video. Payment includes rental and, in certain cases, a fine for delayed return. This can be solved by adding an attribute payment type in the Payment class and assign to it the appropriate value. The possible types of videos are romance, drama, comedy, etc. You can book a video for the weekend, for example, or you can borrow a videotape directly, without a previous booking. The rental is usually paid in only one installment, but the customer has the choice to pay it in advance or when he/she returns the videotape. So the attribute installment number can be discarded. Patient bookings by patient attendance by patient Specialty bookings by specialty 0.. Medical Area.. Doctor Number attend by doctor Booking Booking Date Hour Book Cancel booking Medical Attendance Date Hour Attendance Rate Attend patient Calculate earnings Payment Payments done Customer bookings by customer rentals by customer Figure 3 Instantiation of Resource Rental Pattern for a medical attendance system Video Booking Reservation Date Desired Period Book Cancel booking Video Title Director Qty of available tapes bookings by video Figure 4 Instantiation of Resource Rental Pattern for a video rental 0.. Videotape Rental Rental Date Devolution Date Rental Rate Rent videotape Return videotape Calculate earnings Type of video.. Videotape Number Location Status rentals by tape Payment Payments done 5

6 2.5 4 Real Estate Rental Figure 5 shows the instance of Resource Rental Pattern for a real estate rental system. The resource booking here varies according to the nature of the property being rented. The booking of an apartment, for example, only makes sense while a candidate is being checked for acceptance, but the booking of a store in a shopping mall usually forms a queue that can take years to advance. Similar realestate properties to rent may exist in the same building so that you can book either of them, but what is actually rented is one real estate property. The possible types of properties are houses, apartments, stores, grounds, etc. This application is the one that better explores the features of the class Payment. Here, a rigorous control of the installments due dates is needed as well as the planning of coming installments. Customer bookings by customer rentals by customer Property Booking Booking Date Booking Fee Book Cancel booking Property Address Qty of available instances bookings by property Property Rental Contract Date Renovation Date Rental Fee Rent property Return property Calculate earnings Type of property.... Property Instance Number Floor Status rentals by inst. Payment Payments done Figure 5 Instantiation of Resource Rental Pattern for a real estate rental Show Box Office Figure 6 shows the instantiation of the Resource Rental Pattern for a Show Box Office. Peculiarities here refer mainly to place booking and payment. Actually, the booking is only good if the customer goes to the ticket shop in a certain period of time and the payment can be reduced to an attribute of the ticket sale. The possible types of shows are play, opera, concert, motion picture, etc. 2.6 Known Uses Besides the cases exemplified, this pattern has been used in other systems developed by our group, as for example, in the odontological attendance system. To be able to present these object oriented software patterns, we had to convert our thinking process of developing systems, from procedure oriented to object oriented. For this, we have done reverse engineering in a mechanical car repair shop system with more than twenty thousand lines of Clipper code [Penteado 98], using Fusion/RE, an overall process to do o bject oriented reverse engineering [Penteado 96]. This experiment, else than being educative, made possible deeper understanding of similar experiences [Gall 96]. In parallel, many of the instantiated patterns have been implemented in Delphi, some in the course of a modernization effort of the existing systems. The systems functionality has been preserved but the user interface has been updated for Windows use as many of the applications have been originally developed under DOS. 6

7 Customer bookings by customer admission by customer Place Booking Booking Date Session number Booking Fee Book Cancel booking Show Date/Hour Qty of available seats bookings by show Show Admission Date Hour Ticket Register admission Calculate earnings Type of show.. Show Seat Seat Number Row Status admis. by show Payment Payments done Figure 6 Instantiation of Resource Rental Pattern for Show Box Office 2.7 Related Patterns Focusing only on the objects Customer, Resource and Resource Booking of Figure 2, we can see an application of the TimeAssociation Pattern [Coad 92]. It is also an application of the Association Object Pattern [Boyd 98 ], shown in Figure 7. Resource Booking is the a ssociation between the static objects Customer and Resource. The attributes of the static objects suffer variations but their methods are the same. The attributes and the behavior of the association object can be identified easily within the Resource Booking attributes and methods. Focusing now only on the objects Customer, Resource Instance and Resource Rental we can see again an application of the Association Object Pattern. Considering now only the objects Resource and Resource Instance we can see that they constitute an application of Coad s Itemdescription Pattern [Coad 92], shown in Figure 8. They can also be seen as a Johnson s TypeObject [Johnson 98] or Fowler s Accountability Type [Fowler 97]. Fowler [ Fowler 97] presents a pattern for Resource Allocation in the c hapter dedicated to Planning Patterns. His pattern has another focus, mainly the allocation of an asset or consumable with the purpose of planning. STATIC STATIC 2 n n ASSOCIATION Begin Date End Date Cost Allocate costs Create current from plan Attributes Behavior Figure 7 Association Object Pattern [Boyd 98] 7

8 Item n Item 3 Resource Trade Pattern 3. Context Figure 8 Item Pattern [Coad 92] A customer who buys a product in a supermarket or shop, a customer that requests a special book, a supplier that sells products after receiving a request and a customer that sells his/her house through a real estate dealer are examples of resources traded by two parties. Of course there are some differences among them, but the use of a pattern would simplify system analysis, maintenance and reuse. 3.2 Problem A common situation in many business systems is the transference of property of a resource. This involves sales and purchases where a resource trade is done and someone has to pay for it. 3.3 Forces Resource trade refers to a ce rtain g ood that has to have a unique identification, as well as a description of its characteristics. Sometimes the customer does not know precisely the identification of the good he/she is willing to buy. For example, in a book store application the customer may know the author and subject of the book but not remember its title. The organizations need to keep track of the sale and purchase of resources, as well as to control the inventory and financial aspects involved in them. Purchase department may h ave to k now w hat type of good is more demanded for sale, when acquiring new goods. Sometimes the resource is not available in stock and consequently cannot be traded directly. In these cases, a resource request is necessary before the actual trade. It is important for the organization to keep track of the requests, being aware of which of them are being attended with too much delay. 3.4 Solution In Figure 9 we present the Resource Trade Pattern. Parties can trade a ce rtain quantity of a resource. We use the term party here in the same sense as Fowler [Fowler 97], meaning both individual persons and organizations. The SourceParty represents the organization branch or department that owned the resource and made the trade, while the DestinyParty represents the final owner of the resource. In small organizations, designers usually do not represent the SourceParty, as it i s always the organization itself. However, in a big company, with a lot of departments, it is necessary to keep track of the SourceParty involved in the trade. The trade can be done directly or with a previous request. A resource request can be cancelled, and in this case it will not have a corresponding trade transaction. Each trade transaction results in some kind of payment to be done by the DestinyParty. In the same Resource Request several items can be requested, each of which related to a certain quantity of a different resource. Similarly, in the same Trade Transaction several items can be traded. The resource has the attribute Stock to show its actual quantity in stock. As in the Resource Rental Pattern, the resource can often be grouped in Types of Resource, to provide the user some summaries by type. There are some common classes between this pattern and the Resource Rental Pattern, namely Resource, Type of Resource and Payment. Refer to section 2.4 for a more detailed explanation about these classes. The core part of a Resource Trade is composed o f the classes DestinyParty, Trade Transaction, Resource Traded, Resource a nd Payment. The other classes, namely SourceParty, Resource Request, 8

9 Resource Requested and Type of Resource are alternatives to be considered in each particular application. This means that the pattern may be applied to systems as simple as the ones we obtain combining the core classes, or as complex as the ones we obtain through the application of all alternatives classes. An application that illustrates the use of SourceParty and DestinyParty is a real estate organization system. In this case, the organization does not suffer transference of property. It acts between a present owner and a candidate owner. In the case of the next examples, the organization branch has the role of Source or Destiny party. SourceParty Resource Request Request Date Vendor Make Request Cancel Request nonattended requests DestinyParty transactions by party requests by party Trade Transaction Date Vendor Include transaction Cancel transaction transaction by vendor.. Payment Payment done.. Resource Requested Estimated.. Resource Traded Resource in stock 0.. Type of Resource Figure 9 Resource Trade Pattern 3.5 Examples 3.5. Fertilizer Retail Shop Sale Subsystem Figure 0 shows the instantiation of the Resource Trade Pattern included in an inventory control system, for example for a fertilizer retail shop. In fact, it is a valid solution for a great variety of systems where the customer can buy a product i n stock or make a previous request for it. The quantity sold is subtracted from the quantity in stock of the product. The possible types of product in a fertilizer retail shop are insecticides, antkillers, acaruskillers, bacteriumkillers, etc. In systems where there is no possibility of placing orders, as in retail supermarkets, for example, the classes Product Request and Product Requested are omitted and the customer buys the product directly. 9

10 3.5.2 Fertilizer Retail Shop Purchase Subsystem Another subsystem of the inventory control system that uses the Resource Trade Pattern is the product purchase. In this case, the Customer class is substituted by the Supplier class and the Sale Transaction class by the Purchase Transaction class. The main difference, here, is that the quantity purchased is added to the quantity in stock of the product and the payments are accounts payable, instead of accounts receivable. Figure shows this instantiation of Resource Trade Pattern. Branch Product Request Request Date Vendor Make Request Cancel Request nonattended requests Customer sales by customer requ. by customer Sale Transaction Date Vendor Register the sale Cancel the sale sales by vendor.. Accounts Receivable Payment done.. Product Requested Estimated.. Product sold Product in stock 0.. Type of Product Figure 0 Instantiation of Resource Trade Pattern for a Fertilizer Retail Shop Sale subsystem 3.6 Known Uses This pattern is applied to many information systems developed by our group. It is present in three subsystems of the car repair shop system mentioned in section 2.6 and appears two times in each of the following systems mentioned in the introduction: fertilizer retail shop, perfume retail store and motorcycle dealer. 3.7 Related Patterns Focusing only on the objects Resource Request and Resource Requested of Figure 9, we can see that they can be considered as an application of the State across a collection pattern [Coad 92]. The same occurs with the objects Trade Transaction and Resource Traded. Other patterns occur that were already cited in 0

11 section 2.7, as the TimeAssociation Pattern [Coad 92], the Association Object Pattern [Boyd 98], the Item Pattern [Coad 92], the TypeObject [Johnson 98], and the Accountability Type [Fowler 97]. Fowler [Fowler 97] presents a Trading Pattern in his book that focus mainly at the buying and selling of goods and at the value of these goods with respect to changing market conditions. Although having the same purpose of our pattern, his pattern serves a different domain: financial systems. Branch Product Request Request Date Vendor Make Request Cancel Request nonattended requests Supplier purchases by supplier requ. by supplier Purchase Transaction Date Vendor Register the sale Cancel the sale purchases by vendor.. Accounts Payable Payment done.. Product Requested Estimated.. Product purchased Product in stock 0.. Type of Product Figure Instantiation of Resource Trade Pattern for a Fertilizer Retail Shop Purchase Subsystem 4 Resource Maintenance Pattern 4. Context Cars, televisions, electronic appliances and computers are e xamples of resources that have to b e repaired when their owners perceive a fault. This repair may include both labor service and changed parts. The similarities among them make worth the definition of a pattern that could be applied when developing such systems. 4.2 Problem The repair or maintenance of resources is the goal of many business systems. The resource can have a problem or defect that needs repairing.

12 4.3 Forces Resource maintenance refers to a certain good that has to have a unique identification, as well as a description of its characteristics. The organization needs to categorize the resources to facilitate labor admission, for example. The organization needs to keep track of the maintenance done in resources, as well as to control the financial aspects involved in them. The maintenance can be done through several tasks, each of which made by a certain executor and demanding parts to be executed. The organization needs to control the time used by the workers to perform certain tasks, for example to pay for their work. The purchase department may need to know what parts are more demanded for maintenance, when acquiring new parts. 4.4 Solution In Figure 2 we present the Resource Maintenance Pattern. A customer can have many resources, which can be repaired when they have problems. The resources may be grouped according to their type. The resource maintenance involves tasks to be done in the resource, mainly labor tasks. Each task may need parts to b e substituted in order to make the resource good again. The c ustomer has to p ay for the resource maintenance. To execute the labor tasks we have the maintenance executor that may be an individual person or a team. They have a commission for their work that has to be treated by the system. The classes Resource, Type of Resource and Payment were already described in the Resource Rental Pattern. See section 2.4 for extra information about them. The core part of the Resource Maintenance Pattern is composed of the classes Customer, Resource, Resource Maintenance, Maintenance Task, Part used in maintenance, Part and Payment. The classes Type of Resource and Maintenance Executor are optionally used, depending on the particular application. Customer Part List Part used in maintenance Cost Resource Resource Maintenance Entry Date Exit Date Faults presented Open Maintenance Release maintenance Maintenance Task Problem to solve Labor description Wasted hours Cost Figure 2 Resource Maintenance Pattern 0.. Type of resource Payment Payment done Maintenance Executor Specialty List tasks by executor 2

13 4.5 Examples 4.5. Car Repair Shop Figure 3 shows the instantiation of the Resource Maintenance Pattern to an electric and mechanical car repair shop. A customer has one or more cars that need to be repaired when they have a fault. The car repair shop has employees to do the labor service and has also many parts in stock, which are necessary to repair a car. Customer Part List Part used in repair Cost Car License Number Color List by model Car repair Entry Date Exit Date Faults presented Open Customer Order Release car Repair made Problem to solve Labor description Wasted hours Cost Car model Accounts Receivable Payment done Employee Specialty List tasks by employee Figure 3 Instantiation of Resource Maintenance Pattern for a Car Repair Shop Electronic Appliance Repair Shop Figure 4 shows the instantiation of the Resource Maintenance Pattern to an electronic appliance repair shop. Television sets, videocassette recorder/players, microwave ovens, videogame sets, stereosystems, cdplayers are examples of repairable appliances. To be repaired, labor service is needed, as well as parts that may h ave to b e replaced. The c ustomer usually pays for the repair, unless the resource has a standing warranty. 4.6 Known Uses The Resource Maintenance Pattern occurs in three systems developed by our group: the car repair shop, the television and videocassette repair shop and the electric appliance repair shop. Some considerations have to be made about this pattern. Resource Maintenance can be considered as a combination of the Resource Rental Pattern and the Resource Trade Pattern. We can think of maintenance as a rental of a certain type of resource, labor in this case, and a trade of another resource, in this case the products used for executing the maintenance. This enforces the idea that the family of patterns may offer more than one solution to a problem, leaving to the analyst the choice of which of them to use. 3

14 Customer Part List Part used in repair Cost Appliance Number Model List by model Repair Entry Date Exit Date Faults presented Open Customer Order Release appliance Repair made Problem to solve Labor description Wasted hours Cost Manufacturer Accounts Receivable Payment done Employee Specialty List tasks by employee Figure 4 Instantiation of Resource Maintenance Pattern for an Electronic Appliance Repair Shop 4.7 Related Patterns Focusing only on the objects Customer, Resource and Resource Maintenance of Figure, we can see that they can be considered as an application of the Association Object Pattern [Boyd 98], shown in Figure 7. Other patterns occur that were already cited in section 2.7. Boyd s instantiation of her 3Level Order Pattern [Boyd 98 ] for a work service order has some things in common with the Resource Maintenance Pattern. The main differences are that she distinguishes the Work Order Task and the Work Assignment. The first defines the work to be done in different rooms at a point in time and the second defines planned or completed work by an employee on a specific Work Order Task. 5 Conclusions and Future Work The patterns presented may suffer some variations. Consider, for example, the Resource Rental Pattern. We could apply it to an Airline Service, considering that a seat is a resource that can be rented to a customer during the flight. The customer can also make a place booking. But there are some problems here. First, a flight usually has intermediate stops, so during the whole flight, several people may occupy the same seat. Second, some flights are seat free, so you do not know which seat is actually rented to the customer. Third, some people would prefer to think about a place sale instead of a seat rental. Consider now the Resource Trade Pattern. It could be refined to deal with nonstock resources. The customer could request a product and buy it without the intervention of inventory control. The same could occur with the Resource Maintenance Pattern. The repair could use parts specially acquired for this purpose, or the labor service c ould b e ordered to a subcontractor. These a nd o ther variations would lead to an improvement in our Family of Patterns so that it could apply to a wider domain and po ssibly become a pattern language. 4

15 An example of integration with recurring patterns proposed by other authors to the same application domain would be the addition of the Accounting aspects of the transactions covered in the patterns. Fowler has a full chapter Inventory and Accounting dedicated to p atterns for these a spects [Fowler 97]. Boyd exemplifies the use of the Association Pattern, in which our presented family of patterns bears, in managing details of order attendance like shipment features, room assignment in maintenance work, etc. [Boyd 98]. Aspects like plans to do the repair and estimate of cost for the customer, as well as dynamic features of the system also would contribute to a more comprehensive family of patterns. All these suggestions follow the evolution track suggested by Schmidt when discussing aspects of patterns that will receive considerable attention from the software community [Schmidt 96]. He specifically mentions the Integration of design patterns to form pattern languages as one of these aspects, and that Developing comprehensive pattern languages is challenging and time c onsuming, but will provide the greatest payoff f or patternbased software development during the next few years. This contribution represents work in progress that we expect to cast as a pattern language [Kerth 97] in the near future. Acknowledgments We would like to express our gratitude to Norm Kerth. Acting as shepherd of our original submission to PloP 98: A Pattern Language for Resource Management, he c onvinced us that we were still at t he beginning of a long road to achieve a pattern language, but that we already had useful patterns that should be workshopped. The group Mosaic of subcultures that discussed A Confederation of Patterns for Resource Management a lso d eserves our gratitude, because their work h as been extremely constructive for us to improve our paper to the present form. [Boyd 98] [Coad 92] [Eriksson 98] References Boyd, Lorraine Business Patterns of Association Objects. In Martin, Robert C. (ed.); Riehle, Dirk (ed.) and Buschmann, Frank (ed.) Pattern Languages of Program Design 3, AddisonWesley, pp , 998. Coad, Peter ObjectOriented Patterns. Communications of the ACM, V. 35, nº9, pp. 5259, September 992. Eriksson, HansErik and Penker, Magnus UML Toolkit, Wiley Computer Publishing, 998. [Fowler 97] Fowler, Martin Analysis Patterns. AddisonWesley, 997. [Fowler 98] Fowler, Martin; Scott, Kendall UML Distilled Applying the standard o bject modeling language. AddisonWesley, 998. [Gall 96] Gall, Harald C., Kl sh, Ren R.; Mittermeir, Roland T. Application Patterns in Re Engineering: Identifying and Using Reusable Concepts. In Proceedings of 6th International Conference on Information Processing and Management of Uncertainty in KnowledgeBased Systems, V.III, pp.09906, July 996. [Johnson 98] Johnson, Ralph and Woolf, Bobby Type Object. In Martin, Robert C. (ed.); Riehle, Dirk (ed.) and Buschmann, Frank (ed.) Pattern Languages of Program Design 3, AddisonWesley, pp. 4765, 998. [Kerth 97] Kerth, Norman L. and Cunningham, Ward Using Patterns to Improve Our [Penteado 96] [Penteado 98] Architectural Vision, IEEE Software, pp. 5359, January, 997. Penteado, R.D.; Germano, F. and Masiero, P.C. An Overall Process Based on Fusion to Reverse Engineer Legacy. In Procedings of the III Working Conference on Reverse Engineering IEEE. Monterey California, pp. 7988, 996. Penteado, R.D.; Masiero, P.C.; Prado, A.F. and Braga, R.T.V. Reengineering of Legacy Systems Based o n Transformation Using the Object Oriented Paradigm, In Proceedings of V Working Conference on Reverse Engineering IEEE. Honolulu Hawai, October, 998, to appear. [Schmidt 96] Schmidt, Douglas C.; Fayad, Mohamed and Johnson, Ralph E. (guest editors) Software Patterns. Communications of the ACM, V. 39, nº0, pp. 3639, October