Information Technology Reference
In-Depth Information
whatever object fills the HQ system role in the Detailed Phone Repair commu-
nity where the Branch Repair Provision community object fulfils the Branch
role. There will also be a refinement relation between the two role types.
Finally, a community can, as part of its behaviour, create another commu-
nity, possibly, but not necessarily, to fulfil one of its own roles. This is similar
to the familiar factory design pattern; for example, a headquarters commu-
nity can create a new Branch Repair Provision community when expanding its
territory.
2.6 Community Behaviour
So far, we have concentrated on the way objects are linked to community
behaviour by using the concept of a role. We now turn to the way in which
such behaviour is specified. But first, it should be noted that the behaviour
is not just concerned with actions performed by players of roles. Roles are
concerned with linking the behaviour into a broader picture, but, as we saw
previously when introducing the elements of a community, the community may
also introduce additional enterprise objects that are only of concern within its
specification, and so have a scope local to it.
For example, a particular realization of a branch might have internal proce-
dures involving some actor, such as a storekeeper, without this object actually
being exposed in the broader specification as a role. The fact that there is a
storekeeper is not visible to objects filling roles in the Phone Repair community,
and is a purely local matter for the branch concerned. People sometimes ask
whether such local objects should be seen as roles, but doing so complicates
the external view of the community without bringing any real benefit, so they
are better kept as having a local scope and can therefore be simple enterprise
objects.
Roles or local enterprise objects can be involved in behaviour in a num-
ber of different ways. Firstly, the enterprise language allows distinctions to
be made regarding the way enterprise objects participate in interactions. If
an object participates in performing the action, it is termed an actor with
respect to that action. For example, the object fulfilling the Branch staff role
is an actor who initiates the Inspect Phone action. If an object is essential for
the performance of an action, requiring allocation or possibly being used up,
it is termed a resource with respect to that action. For example, the Loan
Handset objects form a pool of resources; so do various spare parts. Further,
if an enterprise object is mentioned in an interaction, but is not an active
participant in it, then the object is termed an artefact with respect to that
action; one example is the User Handset enterprise object. All these qualifica-
tions are with respect to particular actions; an artefact in one action may be
an actor in another.
