This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
bok:eng:mbse:quality [2020/09/06 14:01] anwlur [Model Metrics] added some points to model size metrics |
bok:eng:mbse:quality [2021/05/11 14:21] (current) 101.88.111.77 [Model Quality] |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Model Quality ====== | ====== 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. | + | 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 ===== | ===== Framework for Deciding Metrics ===== | ||
Line 7: | Line 7: | ||
==== Goal-Question-Metric Framework ==== | ==== Goal-Question-Metric Framework ==== | ||
- | A useful framework to derive useful metrics is the Goal-Question-Metric (GQM) paradigm developed by Basili [2]. The GQM process is as follows: | + | 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 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 | - Define questions to which the answers allow the observer to determine whether the goal has been met | ||
Line 16: | Line 16: | ||
{{ :bok:eng:mbse:quality:model-quality1.png?400 |}} | {{ :bok:eng:mbse:quality:model-quality1.png?400 |}} | ||
- | Krogstie et al (referenced in [4]) is a framework which lays out that quality goals are defined as relations between blocks. | + | 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 | * Syntatic quality - goal that all statements in the model are according to the syntax of the modeling language | ||
Line 26: | Line 26: | ||
===== Quality Goals ===== | ===== Quality Goals ===== | ||
- | Mohagheghi [1] show that there are 6 classes of quality goals for models: | + | 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) | * Comprehensibility (emphasis for model sketches) | ||
* Confinement (emphasis for model sketches) | * Confinement (emphasis for model sketches) | ||
Line 70: | Line 70: | ||
* Measure of progress | * Measure of progress | ||
* Prediction of work effort | * Prediction of work effort | ||
- | * Examples: | + | * 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) | * Absolute size (e.g. number of elements) | ||
* Relative size (e.g. ratio between sequence diagrams and use cases) | * Relative size (e.g. ratio between sequence diagrams and use cases) | ||
Line 78: | Line 78: | ||
==== Design Metrics ==== | ==== Design Metrics ==== | ||
- | * Degree of polymorphism | + | |
- | * Degree of information hiding | + | Rationale for the below metrics is to measure the quality of detailed design and implementation |
- | * Degree of complexity | + | |
- | * Dynamicity / Coupling - complexity of a class internal behavior based on message calls and state transitions | + | * **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. |
- | * Depth of Inheritance Tree (DIT) | + | * **Degree of Information Hiding** - the extent that a class' variables and methods are encapsulated. A private element is fully hidden. |
- | * Cohesion - which part of class is needed to perform a single task | + | |
- | * Number of Use Cases - number of use cases per class | + | === Complexity Metrics === |
- | * **Comprehensibility 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 elements on diagram | ||
* Number of crossing lines on diagram | * Number of crossing lines on diagram | ||
* Number of entry and exit points on diagram | * Number of entry and exit points on diagram | ||
- | ===== References ===== | ||
- | |||
- | * [1] 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 | ||
- | * [2] 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. | ||
- | * [3] C.F.J. Lange, [[http://www.win.tue.nl/~clange/papers/Lange_ModelSizeMatters.pdf|"Model Size Matters"]], Proc. Model Size Metrics Workshop, 2006. | ||
- | * [4] P. Mohagheghi and J. Aagedal, [[https://www.omg.org/ocsmp/MiSE2007-QualityMDE.pdf|"Evaluating Quality in Model-Driven Engineering"]] Access on Jul. 2nd, 2020 |