Model of Knowledge by Fitzgerald Systems

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Model Quality ======

Metrics improve development process, understanding of complexity, discovering/predicting faults and estimation of efforts. Often the choice of metrics exceed what is required and therefore it is advised to define what is the purpose of measurement..

===== Framework for Deciding Metrics =====

==== Goal-Question-Metric Framework ====

A useful framework to derive useful metrics is the Goal-Question-Metric (GQM) paradigm developed by Basili ((V.R. Basili, G. Caldiera, and H.D. Rombach, "The Goal Question Metric Paradigm", In Encyclopedia of Software Engineering, volume 2, John Wiley and Sons, 1994, pp. 528-532.)). The GQM process is as follows:
  - Define goals of measurement (for "UML As Sketch" type models then goal is mainly focusing on communication.)
  - Define questions to which the answers allow the observer to determine whether the goal has been met
  - Each question is evaluated to determine what metrics are required to support the question's answer.

==== Krogstie's framework ====

{{ :bok:eng:mbse:quality:model-quality1.png?400 |}}

Krogstie's framework((P. Mohagheghi and J. Aagedal, [[https://www.omg.org/ocsmp/MiSE2007-QualityMDE.pdf|"Evaluating Quality in Model-Driven Engineering"]] Access on Jul. 2nd, 2020)) is a framework which lays out that quality goals are defined as relations between blocks.

  * Syntatic quality - goal that all statements in the model are according to the syntax of the modeling language
  * Empirical quality - comprises comprehensibility matters such as layout and readability
  * Organizational quality - model fulfills the goal of modeling
  * Social quality - agreement between stakeholder's intepretations

No known empirical evaluation of this framework on models.
===== Quality Goals =====

Mohagheghi((P. Mohagheghi et al, [[https://www.omg.org/ocsmp/ICSE2009_WoSQ_3415_mohagheghi_parastoo.pdf|"Existing Model Metrics and Relations to Model Quality"]] Accessed on Jul. 4th, 2020)) show that there are 6 classes of quality goals for models:
  * Comprehensibility (emphasis for model sketches)
  * Confinement (emphasis for model sketches)
  * Correctness (emphasis for model design)
  * Completeness (emphasis for model design)
  * Consistency (emphasis for model design)
  * Changeability (emphasis for model design)

{{ bok:eng:mbse:quality:mbse_intro1.png?400 |}}

  * **Comprehensibility** - Model is understandable to its intended audience.
  * **Confinement** - Model is in agreement with its purpose
  * **Correctness** - Model includes correct elements & relationships. Does not violate rules and conventions
  * **Completeness** - All necessary information is included at the necessary degree of fidelity
  * **Consistency** - Model is without contradictions. //Horizontal consistency// is consistency between diagrams and views that belong same level of abstraction. //Vertical consistency// is consistency between models or diagrams at different levels of fidelity. Consistency also refers to semantics, i.e. same element does not have multiple interpretations
  * **Changeability** - Model supports continuous and rapid improvement and evolution

MIT xPRO propose the following "Qualities of Great Models"
  * Linked to Decision Making.
  * Model Credibility - it is believable
  * Clear Scope
  * Verification and Validation of Model - Model should show why it is the preferred option to do verification and validation of the system
  * Traceable and Analyzable
  * Understandable and Well Organized
  * Data extrapolation - where is the model valid
  * Complete relative to Scope
  * Internally consistent
  * Verifiable
  * Validatable
  * Elegant
  * Appropriate level of Fidelity
  * Allows Optimization - does it includes gradients or convexity
  * Avoid optimization on a black box
  * Reuse
  * Availability of Interfaces

===== Model Metrics =====

==== Model Size ====

  * Rationale includes:
    * Comparison of models (before and after, model A and model B on same system)
    * Measure of progress
    * Prediction of work effort
  * Examples((C.F.J. Lange, [[http://www.win.tue.nl/~clange/papers/Lange_ModelSizeMatters.pdf|"Model Size Matters"]], Proc. Model Size Metrics Workshop, 2006)):
    * Absolute size (e.g. number of elements)
    * Relative size (e.g. ratio between sequence diagrams and use cases)
    * Complexity (...)
    * Functionality (e.g. number of use cases)
    * Re-use (e.g. applicable if a profile is used, then the metric may be % of profile usage)

==== Design Metrics ====

Rationale for the below metrics is to measure the quality of detailed design and implementation

    * **Degree of Polymorphism((A.F. Abreu, and W. Melo, “Evaluating the Impact of Object-Oriented Design on Software Quality”, Proc. 3rd International Metric Symposium, 1996, pp. 90-99.))** - the extent to which a method of a class over-rides the class' inherited method from its parent class.
    * **Degree of Information Hiding** - the extent that a class' variables and methods are encapsulated. A private element is fully hidden. 

=== Complexity Metrics ===

  * **Weighted Methods Per Class** (from Chidamber & Kemerer((S.R. Chidamber, and C.F. Kemerer, “A Metrics Suite for Object-Oriented Design”, IEEE Trans. on Software Engineering 20(6), 1994, pp. 476–493)) OO metrics suite) - Number of Methods defined in class. //High is Complex//
  * **Depth of Inheritance Tree** (a CK metric) - Maximum inheritance path from the class to the root class. Deeper a class the more it is likely to inherit, therefore increasing complexity. //High is Complex//
  * **Number of Children** (a CK metric) - Number of immediate sub-classes of a class. //Low is Complex//
  * **Coupling between Object Classes** (a CK metric) - A coupling is present when method declared in one class use methods in another class. //High is Complex//
  * **Response for a Class** (a CK metric) - A response set of method that can potentially be executed in response to a message received by an object of that class. //High is Complex//
  * **Lack of Cohesion** (a CK metric) - Lack of cohesion between methods. Identifies classes that attempt to achieve many objectives. //High is Complex//

====  Comprehensibility Metrics ====

    * Number of elements on diagram
    * Number of crossing lines on diagram
    * Number of entry and exit points on diagram
Model of Knowledge by Fitzgerald Systems

User Tools

Site Tools

Page Tools
