rtvb@icmc.sc.usp.br
Advisor: Professor Paulo Cesar Masiero
University of Sao Paulo - Brasil
Finantial Support from
FAPESP grant 98/13588-4
|
rtvb@icmc.sc.usp.br Advisor: Professor Paulo Cesar Masiero
|
University of Sao Paulo - Brasil
|
Introduction
I have developed a Pattern Language for Business Resource Management, which guides the development of applications in the business resource management domain. This includes applications for renting, trading or maintaining resources as, for example, videotape rental systems, libraries, hotels, retail stores, electric appliance repair shops, car repair shops, etc. You can download the pattern language here.
Based on this pattern language, I'm now building a framework to support the development of applications in this domain, called GREN framework. Cincom VisualWorks for Smalltalk is being used in its implementation. Objects are stored in a MySQL database.
The GREN Framework
GREN, a framework for Business Resource Management (Gerenciamento de Recursos de Negócios, in Portuguese), is designed to be used by developers of applications in the domain of business resource management. GREN intends to be a gray-box framework, because it is being designed to be used both by inheritance or by composition. For various of the framework hot-spots there will be pre-built classes that can be used by the application developer, but he or she will also have the possibility of making new classes, through inheritance, when necessary.
Figures 1 and 2 show class diagrams with part of GREN classes.
Figure 1 - Some GREN classes
Figure 2 - Some GREN classes
After having developed the framework to cover the functionality of the first three patterns of the pattern language, we have instantiated the framework for three different applications, in order to test alternative rental systems.
The first of them was for a Car Rental, where Car is the Resource being rented and fits the Single Resource sub-pattern of the Quantify the Resource pattern. In this application, a car may be rented for a period, and this is possible if the car is not rented to anybody else in any of the days comprised by the period.
The second instantiation was for a Videotape Rental, where Video Title is the Resource being rented and fits the Instantiable Resource sub-pattern of the Quantify the Resource pattern. In this application, a videotape may be rented for a period, and this is possible if the title requested by the customer has an available videotape for rental in the desired period.
The third instantiation was for a Product Rental, where Product is the Resource being rented and fits the Measurable sub-pattern of the Quantify the Resource pattern. In this application, the customer can rent a certain quantity of a product, for example chairs for a party, and this is possible if the quantity desired is less or equal than the quantity in stock of that product.
We can observe that the Rental depends on the resource quantification, so that the method for verifying the availability of the resource can vary depending on whether it is a Single, Instantiable or Measurable Resource.
The instantiation of the GREN framework for these three applications was done using inheritance to obtain the application classes, but the functionality regarding the three quantification alternatives is already present in the framework. So, knowing what kind of quantification to apply is enough for the developer to choose what framework class to inherit from. Following is part of the class hierarchy for the patterns implemented in GREN, corresponding to the persistence layer, application layer, and user interface layer. Numbered classes belong to GREN, while not numbered classes belong to Smalltalk.
Persistence Layer
Object
1-PersistentObject
2-OIDManager
3- ConnectionManager
Application Layer
Object
PersistentObject
1- BusinessResourceTransaction
2- BasicMaintenance
3- MaintenanceQuotation
4- ResourceMaintenance
5-BasicTrade
6-BasicPurchase
7-BasicSale
8-ResourceRental
9-ResourceReservation
10-Commission
11-FineRate
12-LocationZoneStCond
13-MaintenancePart
14-MaintenanceTask
15-Payment
16-ResourceInstance
17-ResourceLot
18-ResourceStCond
19-StaticObject
20-DestinationParty
21-LocationZone
22-MeasureUnity
23-QualifiableObject
24-ObjectType
25-PaymentType
26-Resource
27-StorableResource
28-Warehouse
29-SourceParty
30-StockPart
31-StorageCondition
32-StorageLocation
33-TransactionExecutor
34-TransactionItem
35-QualificationStrategy
36-NonTypedObject
37-TypedObject
38-QuantificationStrategy
39-InstantiableResource
40-MeasurableResource
41-LotableResource
42-SingleResource
43-TransactionQuantificationStrategy
44-InstantiableResTransaction
45-ItemQuantificationStrategy
46-InstResTransItem
47-MeasResTransItem
48-LotResTransItem
49-SingleResTransItem
50-MeasurableResTransaction
51-LotableResTransaction
52-SingleResTransaction
User Interface Layer
Object
Model
ApplicationModel
1-StaticObjectForm
2-DestinationPartyForm
3-LocationZoneForm
4-MeasureUnityForm
5-ObjectTypeForm
6-QualifiableObjectForm
7-ResourceForm
8-InstantiableResourceForm
9-MeasurableResourceForm
10-SingleResourceForm
11-WarehouseForm
12-SourcePartyForm
13-BranchForm
14-StockPartForm
15-StorageConditionForm
16-TransactionExecutorForm
17-MainMenu
18-MainWindow
19-GRENApplicationModel
20-BasicButtonsForm
21-BasicReturnButtonsForm
22-BasicNvgButtonsForm
23-BasicTotalsForm
24-BasicMaintenanceTotalsForm
25-BasicRentalTotalsForm
26-MaintenancePartForm
27-MaintenanceTaskForm
28-PaymentForm
29-QualificationForm1
30-QualificationForm2
31-TransactionItemsDataSetForm
32-BasicBusinessTransactionForm
33-MultiResourceTransactionForm
34-MultiResourceRentalForm
35-OneResourceTransactionForm
36-OneResourceBasicMaintenanceForm
37-OneResourceBasMaintNPNTForm
38-OneResourceBasMaintWPWTForm
39-OneResourceRentalForm
40-InstantiableResourceRentalForm
41-MeasurableResourceRentalForm
42-FineRateForm
SimpleDialog
43-TransactionItemForm
44-RentalItemForm ()
To instantiate GREN for a specific application, the pattern language is applied, resulting in a class diagram for the new application. Then, based on GREN documentation, the developer can decide which classes need to be subclassed in order to obtain the desired implementation. The table below shows part of this mapping.
Table 1 - Interface Forms Inheritance
| Parent Class | Interface Form to be inherited |
| ResourceType | ResourceTypeForm |
| InstantiableCategorizableResource | InstantiableCategorizableResourceForm |
| SingleCategorizableResource | SingleCategorizableResourceForm |
| MeasurableCategorizableResource | MeasurableCategorizableResourceForm |
The developer can also know, by examining GREN documentation, which methods need to be overrided in the new subclasses. The table below shows part of this documentation, to illustrate the instantiation process.
Table 2 - Methods to be overriden for subclasses of Resource, whenever the Rent the Resource pattern is applied.
| Mehtod name | Class/Instance | Explanation/Example |
| resourceRentalClass |
|
Links the Resource to the Resource Rental class, i.e., it links the resource being managed to the class that logs the management. For example, in a car rental, it must return the Car class. (^Car) |
GREN Instantiation Support Tool
We are also developing a tool, called GREN Wizard, to support GREN instantiation for specific applications. The application developer uses this wizard in parallel with the pattern language application, supplying information concerning the variable aspects of the framework. Then, the code of his application is automatically generated, together with a script for tables creation in the MySQL relational database.
The developer can adapt the resulting code for requirements not included
in the framework, and, to do that, he can use GREN documentation, which
consists of class diagrams, class hierarchies, description of hot-spots
and a cookbook for manual instantiation.
