Figure LR.32 - Example Instance Implementation of a CompoundResource

Header Image
Project:
Figure LR.32 - Example Instance Implementation of a CompoundResource : Class diagram
Created: 3/28/2022 3:51:09 PM
Modified: 10/3/2023 6:17:30 AM
Project:
Advanced:
The following Figure shows a Router modeled as a type of ResourceElement.  The PhysicalResource entities and LogicalResource entities are identified in different colors on the Figure to help show their different instances. <br/>A Router is a shorthand notation for a set of PhysicalResources, LogicalResources, and optionally CompoundResources that collectively represent the physical and logical aspects of the Router. The concept of a CompoundResource helps simplify representing complex devices and ensures that commands and policies that affect the physical and logical aspects of a device are sent to both the physical and logical components of the device.<br/>CompoundResource has two subclasses, called ResourceElement and ResourceCollection. Both of these subclasses represent managed entities that may have physical and logical aspects.<br/>It should be noted that this is, in reality, another use of the composite pattern.<br/>A ResourceElement is an entity that is individually manageable. For example, a Router can be modeled as a ResourceElement. Different PhysicalResource objects can model the physical aspects of the Router in detail, and different LogicalResource objects can model the logical aspects of the Router in detail. If the Router was a modular Router that was made up of different PhysicalDevices having different logical capabilities, then each of these “sub-devices” could be represented as a CompoundResource. ResourceElement aggregates an appropriate set of PhysicalResource, LogicalResource, and CompoundResource objects, enabling a high-level view of all of the aspects of the Resource to be provided.<br/>A ResourceCollection is an entity that is also individually manageable. If we “look inside” a ResourceCollection object, we find an aggregate entity consisting of at least one ResourceElement and zero or more ResourceCollection entities. This is represented by the HasCompoundResources aggregation. For example, a Network can be modeled as a subclass of ResourceCollection. A Network can be made up of other Networks and/or SubNetworks. Each Network or SubNetwork can, be made up of physical and logical components. Each node in the network can be represented by a ResourceElement. Thus, the ResourceCollection enables a single entity to represent a set of ResourceElements. This is very convenient for many different types of applications. One important example is topology applications that support the ‘drill-down' of elements. That is, imagine a network appearing as a single icon in a topology map. This would be a ResourceCollection. Now, imagine the user double-clicks on that icon, bringing up the next level of detail. This would show the different components of the Network, such as SubNetworks and individual network devices. These would be examples of ResourceElements. The process can continue for as many levels as desired because the HasCompoundResources cardinality on the component side is 1..*.<br/>