## 8 Evaluation and Validation of HEAD Metamodel
### Evaluation and Validation
\begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt} p{142.3 pt}} \hline \hline
**Metamodel Features** & \multicolumn{2}{c}{**Access Control Metamodels**} \\ \cline{2-3}  & **HEAD Metamodel** & **Other Metamodels** \\ \hline \multirow{2}{*}{Unify components} & Unify all heterogeneous components of different AC models. & Some metamodels unify some heterogeneous components under the notion of ‘category’ which includes roles, groups, security levels, etc. \\ \hline \multirow{2}{*}{Generality} & Include all features and components of common AC models and allow deriving various instances of various models. & Hybrid structures to derive some AC models rather than generic metamodels \\ \hline \multirow{2}{*}{Dynamism} & Allows defining and adding any type of components and attributes for existing models and non-existing ones. & None of the existing metamodels support this feature, and they are not dynamic enough to define static and dynamic AC policies. \\ \hline \multirow{2}{*}{Extensibility} & New components can be defined and integrated with already-derived models to support new AC features in addition to the previous ones. & Some metamodels are extended but not extensible, and none of the existing metamodels support this feature. \\ \hline \multirow{2}{*}{Hierarchical} & Allows defining multi-levels of all components (e.g., role, context) to conform to hierarchical organizational structures. & Some metamodels support hierarchy for some components, but none of them consider context hierarchy which is crucial feature in complex and dynamic environments. \\ \hline \multirow{2}{*}{Flexibility} & Allows creating existing and non existing AC models (new models) and expressing various static and dynamic rules & Only derive some common models. They are limited to the features employed in their structures. \\ \hline \multirow{2}{*}{Unified framework} & Allows the creation of any model, in addition to any hybrid model with different policy classes (e.g., case study 2), and hybrid models with hybrid components (e.g., case study 1) & None of the existing metamodels support this feature. \\ \hline \multirow{2}{*}{Adaptability} & Can be adapted to different centralized and distributed environments, especially IoT. & Allows the creation of some models based on features employed in their hybrid structures. \\ \hline Novelty & A new development in the domain with advanced features. & They provide solutions for specific cases and scenarios. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison between HEAD Metamodel and the other AC metamodels. could be used, for example, to represent the needed models and then generate AC rules in as 'json' format. (4) For the formal verification of the generated AC policies, it is necessary to formally verify the accuracy and coherence of the concrete instance of the AC policy before policy enforcement. For example, using Cypher queries as NGAC inputs to represent the AC rules of a system in a graph, then verifying the objects, the relationships between them, and the subjects that interact with the system in a way that adheres to an organization's semantics. Likewise, the HEAD metamodel serves as a unifying framework and it is the only metamodel that provides to the literature all the design phases and steps starting from the conception [6; 15; 41; 42; 43] to policy enforcement which is addressed in this paper, through the implementation of two case studies, in addition to the new research opportunities this metamodel opens in the domain [20]. The effectiveness of HEAD metamodel is reflected in the proof of concept since we show that the metamodel idea with theoretical foundations can be implemented and applied using different tools. Additionally, if the above case studies are implemented using one of the proposed metamodels, the solution would not meet ITMI's AC requirements, as the existing metamodels only incorporate DAC, MAC, and RBAC features, so attributes cannot be defined nor new components added. Moreover, they are not flexible enough to define different PCs.