Information Technology Reference
In-Depth Information
The user provides
at least the core
infrastructure
facilities and
support for their
chosen options.
The supplier needs
the core infrastructure
facilities and at
least one option.
core infrastructure
FIGURE 12.1: The infrastructure services a product needs and the services
its user makes available.
However, there will be constraints on the choices of environment to ensure
that the choices made by the user result in consistent operation. For example,
the supplier may state that the necessary communications can be supplied in
a number of different ways, corresponding to a variety of common fixed and
mobile technologies the user may want to exploit. Figure 12.1 shows, in a
schematic form, that a product needs some core infrastructure and at least
one of three possible technology options.
The user will also have an infrastructure model, this time indicating the
supporting services that they actually make available when deploying the
product. This model will be more restrictive than the supplier's infrastructure
model, since it only covers the specific choices of technology the user has made,
but, within these limits, it will be more general because it describes the full ca-
pabilities of the technologies chosen, which will generally be broader than the
specific requirements of the product. This is what is shown by the provision
contour in figure 12.1, which shows that the user can support the core facilities
and option 1, and more besides. For example, the supplier model may require
only point to point communication, while the actual infrastructure provides
both this service and some form of group communication or multicast.
The second model the supplier has is one describing what the product can
do for the user. This is a classical component model, indicating the widest
range of things the product can do in its least constraining environment; that
is to say, it describes the union of all the possible styles of use envisaged by
the supplier. The supplier may also provide as part of their documentation
a number of use case models, suggesting productive ways of exploiting the
product, but these are likely to be illustrative, rather than definitive, and
give no guidance as to why the user actually bought the product. There may
also be a basic core of mandatory user behaviour, such as initialization and
registration of security credentials, which must be engaged in if the product
is to function correctly. In our Venn diagram, this can be reorganized into a
separate region, separating behaviour the user must initiate from that the user
may initiate when it requires specific services. In figure 12.2, the inner contour
