Figure Res.13 - Resource Function Spec inheritance (OLD RS.03) : Class diagram
Created: |
3/28/2022 3:51:09 PM |
Modified: |
5/30/2022 3:47:14 AM |
Project: |
|
Author: |
Giu Platania |
Version: |
22.0 |
Advanced: |
|
ID: |
{BB814069-46F3-440f-BF68-3F7800BF3500} |
The ResourceFunction / ResourceFunctionSpec concept is very broad and can be applied to many different domains:<br/> • NetworkFunction / NetworkFunctionSpec would correspond to the description of the behavior of a function running in the network domain.<br/>Instances of such artefacts can be specific function for a given layer (RouterFunction, SwichingFunction, GatewayFunction…).<br/> • OfficeFunction / OfficeFunctionSpec and GameFunction / GameFunctionSpec would be respective specialization in the Office domain and Game domain.<br/> • Another example could be MeteoFunction / MeteoFunctionSpec in the Meteo domain, consisting of describing how meteo data (pressure, temperature, wind) would be transformed to create meteo reports.<br/>Instances of such MeteoFunction / MeteoFunctionSpec artefacts would be specifically created for different kinds of meteo reports: national, regional, local, mountain, see, storm, etc.…).<br/><i>The 16.0 model represented explicitly VNFSpecification as inheriting from SoftwareSpecification. After discussions it was considered being confusing. In the ETSI-NFV sense, a VNF is an “implementation of a NetworkFunction”; while the software that is used to realize this function is necessary, it is not the function in itself. </i><br/><i>The 16.0 model represented explicitly PNFSpecification as an explicit class inheriting from CompoundSpecification. After discussions it was considered that from a general perspective what matters is the fact that a PhysicalResource may be associated with an EmbeddedSoftware.</i><br/><i>The general model need to be extended if more specialized classes to represent NVF concepts are requested, such as NF, VNF, PNF.</i><br/><i>It can be done either by creating new derived classes, or also by documenting “touch points” to external models from other SDOs (ex from ETSI-NFV or from OASIS-TOSCA).</i><br/><i>The explicit separation of function from its various possible realizations (as pure software – SoftwareSpecification -, pure hardware – PhysicalBlackBoxSpecification – or software embedded in a box – SoftBlackBoxSpecification -) helps organizing specialized artefacts supporting virtualization.</i><br/>