To address these virtualization examples and network abstraction requirements described later, the concept of “ResourceFunctionSpecification” is introduced as a specialization of a LogicalResourceSpec which itself is a subclass of ResourceSpecification.<br/><i>The designer/conceiver in charge of inventing a new transformation behavior and documenting it must be able to do it without considering whether it will ultimately be of use as a resource or a service in the CSP context.</i><br/>ResourceFunctionSpec inherits the composition pattern from ResourceSpecification and it can model relationships between ResourceFunctionsSpec using ResourceSpecificationRelationship (RHS). It is rooted via Entity Specification (LHS).<br/>Introducing the concept of ResourceFunctionSpec permits the following:<br/>        • Separating the description of a function from its realization<br/>             • Definition from the existing SID 16.0 “Software” artefact: <br/>             • “A set of programs, procedures, functions and processes that are used by a Resource.”<br/>             • The proposed approach is to explicitly separate the concept of function from the concept of its software realization.<br/>             • This way, it will be possible to model a function as a behavior to transform inputs of any nature into outputs of any nature independently from the way it is realized. This realization may be achieved by different ways; examples: manually or automated by software or hardware implementing algorithms etc.… without any impact on the definition of the functions itself.<br/>             • Doing so, the notion of function is not anymore part of the definition of “Software” but appears as an explicit separate concept associated to “Software. This separation permits the life cycle of a function (Resource Function) to be different from the underlying resource. Thus, the realization for a given function can change without the function changing (This flexibility can apply to both specifications and Instances).<br/>        • Distinguishing Software as data packaged to be exchanged and for future deployment vs. Software as data actually installed on an executable machine.<br/>        • Another separation is to explicitly distinguish the software material as it is acquired by the consumer from the software vendor, from the software installed on a machine ready to be executed.<br/>        • Abstraction /Generalization<br/>             • As discussed in previous sections, the concept of function as a behavioral mechanism to transform input data into output data is not specific to the network business areas; it is very general, and it is applicable to many different business areas. <br/>             • The creation of a specific artefact to represent the concept of function supports the adoption of a more general approach with the principle of not restricting to network related functions but allowing for a representation of any kind of functions from any business areas.<br/>             • The result is a generalized model flexible/open enough to be specialized or extended with specific artefacts requested for more specific business areas.<br/>