describes products present either on the shelves or in the stockroom.
Employee represents the employee sitting at the counter, who requires a
password to access the system. Customer represents a customer, who has no
password because it has no direct access to the system. Transaction repre-
sents a set of acquisitions performed by a customer, at a certain time with a
given employee at the counter.
The transaction and acquisition entities can be used to compute statistics
on customer data (e.g. the best selling products or the preferred products of
particular customers) in order to improve sales. This data makes it possible
to conduct market analyses through data mining techniques.
The main issue in this prototype is to achieve a modular design that can be
easily extended. For this purpose this prototype is structured into four pack-
ages as shown in Figure 14.10. The packages correspond to and implement
the homonymous components of the architecture (see Figure 14.4).
How to keep the packages loosely coupled?
Since the dependencies between packages form a chain, low coupling is
achieved by ensuring that any interaction takes places through a limited
set of interfaces. Because the interactions are quite simple we define an
interface for each package.
There are three interfaces that regulate the interactions between the
packages. The package CounterUI communicates with the package Counter
through its interface MarketProxy . The interface Market mediates the inter-
actions between the package Counter and the package Market . Finally the
Figure 14.10 Package structure