Information Technology Reference
In-Depth Information
logistics organization. Note, however, that a community may define several
roles of a specific role type, each with the same behavioural constraints, allow-
ing for multiple objects to share responsibilities in a community. This can be
specified by associating an appropriate cardinality constraint with the role, as
is the case with the Branch staff role in the Detailed Phone Repair community.
In general, one object can play several roles in the same community. For
example, in the PhoneMob scenario, an individual can play both the User
role and the Customer role in the Phone Repair community, although, for
organizational customers, these will usually be filled by separate objects (see
the following section).
Finally, the community specification may include additional constraints
on the filling of roles. The most familiar example of this is the requirement
for dynamic separation of duties, in which there is a requirement that two or
more roles must be filled by different objects; for example, where a financial
transaction cannot be both proposed and approved by the same individual.
2.5 More than One Community
Any problem of significant complexity will generally require the use of
flexible structuring techniques, and this is particularly true of enterprise spec-
ifications. If communities are to be kept suciently simple to be understood,
they need to be combined, and this can be done in a number of ways.
The way communities are combined will be chosen to support the mod-
elling of complex organizational structures, closely reflecting the real-world
environments within which ODP systems are positioned. These structures
can be expressed in terms of relationships between communities and of the
policies that govern their establishment and change.
A community as a whole can be seen as an enterprise object, and so can
itself fill a role in some higher-level community. Thus, in a top-down design
approach we can start with a general view and then refine it by using sub-
communities to fill the top-level roles. The object resulting from considering
a community as a whole is called a community object .
For example, we can capture the behaviour of a logistics provider, perhaps
to express details of their collection and delivery procedures, by introduc-
ing a Logistics Provision community; the community object representing this
can then fill the Logistics Provider role in the Phone Repair community (see
figure 2.5). Note, however, that there are some additional constraints that
need to be stated in making this linkage. Consider the Green Transport ob-
ject, which is the community object that is going to be refined when defining
the Logistics Provision community. This fills the Logistics Provider role in the
Phone Repair community, and the way that some of its own roles are filled
is already determined as a result. The Customer role in the Logistics Provi-
