User Tools
bok:eng:mbse:quality
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
bok:eng:mbse:quality [2020/07/06 13:18] anwlur created |
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 ===== | ||
| - | A useful framework to derive useful metrics is the Goal-Question-Metric (GQM) paradigm developed by Basili [2]. The GQM process is as follows: | + | ==== 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 goals of measurement (for "UML As Sketch" type models then goal is mainly focusing on communication.) | ||
| - | - Define questions that have answer that 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 |
| - Each question is evaluated to determine what metrics are required to support the question's answer. | - 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 ===== | ===== 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 20: | Line 34: | ||
| * Changeability (emphasis for model design) | * Changeability (emphasis for model design) | ||
| - | {{ :bok:eng:mbse:intro:mbse_intro1.png?400 |}} | + | {{ bok:eng:mbse:quality:mbse_intro1.png?400 |}} |
| * **Comprehensibility** - Model is understandable to its intended audience. | * **Comprehensibility** - Model is understandable to its intended audience. | ||
| Line 26: | Line 40: | ||
| * **Correctness** - Model includes correct elements & relationships. Does not violate rules and conventions | * **Correctness** - Model includes correct elements & relationships. Does not violate rules and conventions | ||
| * **Completeness** - All necessary information is included at the necessary degree of fidelity | * **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 consistency. Consistency also refers to semantics, i.e. same element does not have multiple interpretations | + | * **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 | * **Changeability** - Model supports continuous and rapid improvement and evolution | ||
| Line 50: | Line 64: | ||
| ===== Model Metrics ===== | ===== Model Metrics ===== | ||
| - | * **Model Size** - number of elements[3]. Allows for | + | ==== Model Size ==== |
| + | |||
| + | * Rationale includes: | ||
| * Comparison of models (before and after, model A and model B on same system) | * Comparison of models (before and after, model A and model B on same system) | ||
| * Measure of progress | * Measure of progress | ||
| * Prediction of work effort | * Prediction of work effort | ||
| - | * **Design Metrics** | + | * Examples((C.F.J. Lange, [[http://www.win.tue.nl/~clange/papers/Lange_ModelSizeMatters.pdf|"Model Size Matters"]], Proc. Model Size Metrics Workshop, 2006)): |
| - | * Degree of coupling between classes (e.g. number of interactions within a class) | + | * Absolute size (e.g. number of elements) |
| - | * Degree of inheritance (e.g. depth of inheritance) | + | * Relative size (e.g. ratio between sequence diagrams and use cases) |
| - | * Degree of cohesion | + | * Complexity (...) |
| - | * Degree of polymorphism | + | * Functionality (e.g. number of use cases) |
| - | * Degree of information hiding | + | * Re-use (e.g. applicable if a profile is used, then the metric may be % of profile usage) |
| - | * Degree of complexity | + | |
| - | * **Comprehensibility Metrics** | + | ==== 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 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. | ||
bok/eng/mbse/quality.1594041505.txt.gz · Last modified: 2020/07/06 13:18 by anwlur
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
