User Tools

Site Tools


bok:eng:mbse:quality

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
bok:eng:mbse:quality [2020/09/07 14:16]
anwlur [Design Metrics] updated metrics with descriptions
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 81: Line 81:
 Rationale for the below metrics is to measure the quality of detailed design and implementation Rationale for the below metrics is to measure the quality of detailed design and implementation
  
-    * **Degree of Polymorphism** - the extent to which a method of a class over-rides the class' inherited method from its parent class.+    * **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. ​     * **Degree of Information Hiding** - the extent that a class' variables and methods are encapsulated. A private element is fully hidden. ​
  
Line 99: Line 99:
     * 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 
bok/eng/mbse/quality.1599488186.txt.gz · Last modified: 2020/09/07 14:16 by anwlur