Java Reference
In-Depth Information
There are two options: the first consists of creating new classes inside the
negotiation framework, the second consists of building on top of the nego-
tiation framework. The advantage of the first solution is a simpler approach
that can access the internal classes of the framework and allows ad hoc
solutions. The second solution is more generic; it leaves the negotiation
framework unmodified and insulates the problem of managing limited
resources that can be addressed from several perspectives depending on the
We adopt the second solution and define a new package that contains the
classes that extend the framework in order to handle limited resources. The
structure of the booking package is described by the class diagram of
Figure 20.7. The resources are managed by a ResourceAllocator that con-
forms to the problem specification expressed by the Specification class of the
Negotiation framework. The resources and their availability are represented
by class Resource .
Decision point
How do we handle inter-attribute constraints?
Since the class PreferenceMap is too simple to handle the inter-attribute
constraints and we do not want to modify the negotiation framework, the
only solution is to create a new preference class: ResourcePreference . This
class extends PreferenceMap and redefines the methods ( decrease() and
bestProposal() ) that can potentially create proposals that are not valid for the
current resource availability status. To verify the validity of the proposals,
Figure 20.7 Class diagram of the booking package
Search WWH ::

Custom Search