Figure PR.29 - Overview of Party and PartyRole : Class diagram
Created:
3/28/2022 3:51:09 PM
Modified:
10/3/2023 6:55:54 AM
Project:
Author:
Giu Platania
Version:
1.0.0
Advanced:
ID:
{7F364C5B-E93F-45f0-A453-61EC99FC01A9}
This section will outline some of the business entities that interact with business entities defined in the PhysicalResource model. <br/>This has already been referenced briefly above. To recap, Party and PartyRole are needed for a number of important reasons, including:<br/> • Identification of an owner of the Device or Hardware<br/> • Identification of the manufacturer of the Device and possibly the manufacturer of some or all of its components<br/> • Identification of who is responsible to administer the Device or Hardware<br/> • Identification of who installed the device<br/> • Identification of what management domain the Device or Hardware is in<br/> • Identification of who in a particular management domain can administer the Resource<br/> • Identification of who last changed the device<br/>The above are exemplary, and identify some of the links between these classes and the physical resource model. The above is not meant to imply that these are the only links between these models.<br/>It is important to realize that the owner of a Device or Hardware is not the same as the person or group that is responsible for administering the Device or Hardware.<br/>While the eTOM talks about the need to administer different types of managed objects, it doesn’t identify the concepts of owner and administrator. These are needed to support the inventory and other use cases we introduced at the start of this document. Every effort will be made to take this data and feed it back to the eTOM team.<br/>Referring to the SID Party model (in Common guide book), there is an 0..n to 0..n association (implemented as an association class) with a PartyInvolvement attribute that define what responsibility the PartyRole (e.g., customer, provider, employee, management domain) plays. Example responsibilities are owner, lessee, lessor, and administrator. Note that this involvement does not have to be established via an Interaction; there can be a direct relationship that defines this involvement. It is important that the SID not dictate this, so that applications are free to implement the precise semantics of this relationship according to their own needs.<br/>Given this background, we can define additional relationships needed to represent administration and ownership of PhysicalResources.<br/><br/>