Information Technology Reference
In-Depth Information
«EV_Community»
Phone Repair
has role
«EV_Role»
Phone Repair
Provider
«EV_Role»
Bank
«EV_Role»
Customer
«EV_Role»
Logistics
Provider
«EV_Role»
Phone
Supplier
«EV_Role»
User
«EV_FulfilsRole»
«EV_FulfilsRole»
«EV_FulfilsRole»
«EV_Object»
PhoneMob
{singleton}
«EV_CommunityObject»
Green Transport
«EV_Object»
Phone User
«EV_RefinesAsCommunity»
«EV_FulfilsRole»
«EV_FulfilsRole»
«EV_Community»
Logistics Provision
«EV_FulfilsRole»
has role
«EV_Role»
Goods Source
«EV_Role»
Customer
«EV_Role»
Carrier
«EV_Role»
Manager
«EV_Role»
Goods Destination
FIGURE 2.5: Using role filling to link two communities.
sion community is no longer just any object, but becomes the object filling
the Phone Repair Provider role in the Phone Repair community, which is the
PhoneMob itself. Since the customer is, in this case, having their own goods
shipped, they also fill either the Goods Source or Goods Destination role, with
the corresponding destination or source being filled by the Phone Supplier or
User. In figure 2.5, the User role is the destination and the PhoneMob is the
source. As long as these constraints are satisfied, we can use any logistics
provider able to offer a community object whose type matches the role type
in our higher-level community.
Another way in which two or more communities can interact is by having
one or more roles from the different communities filled by a single shared
object. Since the behaviour of this object is constrained by each of the roles it
fills, there is then an indirect linkage of the various communities involved. This
can be used to merge constraints arising from different organizational units.
For example, the Phone Repair community in figure 2.2 distinguished two
roles relating to their clients: a Customer role concerned with the agreement
to use and pay for the service, and a User role concerned with using a phone
and requesting specific repairs. A simple community called the CustomerOrg
