本周的技术文章又上新啦!上一篇为大家分享了有关制作车载软件建模指南的知识,不知道对您有没有帮助呢?今天向大家分享的这篇文章是《利用Model Inspector测量模型度量》,主要涉及到我们的模型级检测工具Model Inspector,还想了解代码级别及模型级别检测工具更多信息的请积极留言告诉我们哦!
1.何为模型度量?
模型度量就是指能够分析模型,评价模型复杂度、大小、可读性、可测试性及是否遵守标准的模型品质指标。可通过测量的度量针对模型制作质量标准,并可灵活利用多种度量实现高水平管理。但目前并没有标准文书明确规定必须使用度量。(ISO 26262标准中仅是建议使用度量测量)
实际上,度量中很重要的一点并不是度量的测定值本身,而是与质量相关的度量的范围。例如圈复杂度 (Cyclomatic Complexity)是典型的复杂度度量,测定值越大就代表代码越复杂,越难以理解,且发生缺陷的可能性越高。此时应设置圈复杂度范围,若超过此范围即可认定模型具有过高的复杂度。
像这样仅通过测量度量,无法准确地掌握模型质量。若以个人/组/部门为单位,确定各度量的范围,并制定其范围的质量标准,将有助于提高产品质量。
2.设置Model Inspector度量范围
利用Model Inspector测量度量后,以各度量为单位设定范围,可导出想要的值。
<图1> 被测度量概要及详情视图
可通过Model Inspector的度量环境设置编辑度量。在度量编辑窗口中可通过不定式功能来设置测量范围。
如下图所示,通过此设置可确认局部复杂度(子系统的复杂度)大于3的子系统。
<图2> 通过度量编辑窗口设置度量范围
可确认局部复杂度大于3的子系统模型内有几个分区。
<图3> 通过设置的范围测量的局部复杂度度量
另外,通过下面<图4>的度量详细信息视图,可以确认每个子系统局部复杂度的数值。
<图4> 关于局部复杂度的度量详情视图
3. Model Inspector支持的度量
(1)复杂度(Complexity)
测定模型复杂度的方式有两种,一种是应用编码复杂度测量方法的Cyclomatic,另一种是Halstead。本工具采用Cyclomatic方法进行测量。
名称 | 说明 |
Cyclomatic Complexity | Complexity = P + 1 P : Decision block (if-else, switch, while, for iterator block) |
Model Inspector中的复杂度是以Subsystem和Chart为单位,基于Decision Block,Stateflow的State数,具有条件的Transition数进行复杂度计算。
DO-331、IEC 61508、IEC 62304、ISO 26262及EN 50128标准中建议遵守模型和代码的大小、复杂性及可读性等相关质量指标。
(2)内聚度(Cohesion)
在模型中子系统依据功能上有关联的block的聚合而相连接的块组数量来计算内聚度。例如,若一个子系统内的所有BLOCK都依靠信号相互连接,则可称为高内聚。未连接的块组可分离至其他子系统,即内聚度低意味着子系统构成的功能关联性小。
(3)耦合度(Coupling) / Fan-In, Fan-Out
在模型中,子系统通过输入(Input)和输出信号(Output Signal)连接,建立相互依存关系,因此以此为标准计算耦合度。除去与基本块(Basic Block)的连接外,与相同的子系统的连接计算为1个。耦合度要分别计算扇入和扇出。即耦合度高意味着子系统的依赖性低。
(4) 模型及Chart大小
模型大小和Chart大小是影响可读性和复杂性的因素,例如影响维护的程序大小,因此需要适当的管理。为此,必须测量各种类型的尺寸系数。
种类 | 说明 |
Block数 | 计算模型内的Block 数量(链接库内的Block除外) |
Subsystem数 | 计算模型内的Subsystem数 |
Linked library数 | 计算模型内的链接库数(测定链接库数而不是库数) |
Chart数 | 模型内的Chart数 |
Subsystem深度 | 计算模型内Subsystem深度(模型系统的深度初始值为0) |
State数 | 计算Chart内的State数 |
Transition数 | 计算Chart内的Transition数(包含default Transition) |
这些是与模型大小及Chart大小的DO-331、IEC 61508、IEC 62304、ISO 26262和EN 50128标准建议遵守的模型和代码的大小以、复杂性和可读性的要求中与模型大小有关的质量指标。
<图5> Model Inspector metric perspective 画面
参考资料
- “Complexity Analysis of Simulink Models to improve the Quality of Outsourcing in an Automative Company”, Jeevan Prabhu, August 2010
- Mathworks
- “Simulink Models Are Also Software Modularity Assessment”, Yanja Dajsuren, Mark G. J. van den Brand, Alexander Serebrenik, Serguei Roubtsov , Eindhoven University of Technology
- MISRA: MISRA Report 5, Software Metrics