实时系统规范描述专题第一部分.pptVIP

资料 05—01— 实时系统设计与分析的规格说明 Part 1 提纲 实时系统的分析与设计 v.s. 形式化方法 案例讨论 UML及其扩展 实时嵌入式系统的开发工具环境 体系结构的分析与设计理念 基于模型的工程/体系结构驱动 的概念 规格说明语言——AADL（体系结构分析与设计） 标准 基本语法 支持工具 形式化方法 形式化（formal method）方法： “ 用于开发计算机系统的形式化方法是基于数学的用于描述系统性质的技术；这样的形式化方法提供了一个框架，人们可以在该框架中以系统的方式刻画、开发和验证系统。” 广义——有精确数学语义的系统工程方法； 狭义—— 形式化规格（specification）方法； 形式化验证（verification）方法。 形式化规格方法（续） 操作类 基于状态和转移，通过可执行的模型描述系统，模型本身能够采用静态分析和模型执行得到验证 描述类 基于数学公理和概念，通过代数或逻辑给出系统的状态空间，具有高度抽象的特点，通过自动工具进行验证； 分为两类：代数描述、（时态）逻辑描述； 形式化规格方法（续） 双重类 例如： “形式语言与自动机” min-plus algebra + TEG CTL+ + TA —— UPPAAL? LTI – SPIN LTI – BOOST …… 形式化验证方法 基于（形式化）模型的开发过程 基于模型的规格说明?基于规格化模型的验证 请参见下一次专题 形式化方法的适用性 由 实时系统的本质特征 对形式化规格说明方法的要求 案例1：没有形式化方法支持的OOAD过程的局限性； 案例2：形式化方法与开发工具在航空电子开发环境中的应用 没有形式化方法支持的OOAD UML语言 – Unified Modeling Language 用例、类、对象、顺序、活动、合作、配置 “半形式化”的图形化建模描述语言 所谓的“半形式化”严格意义上就是没有形式化； UML主要是为了解决设计团队成员之间的“共同语言”的问题 UML语言的局限性 UML语言被用来描述软件体系结构，虽然可以定义domain-specific的范型；但是如果不认真地将它与形式化工具合理地结合起来，它在实时系统开发中的应用仍存在应用的局限性；——笔者 根据参考文献，笔者认为其局限性体现于： 1. 缺乏对并发组件及其行为的精细定义 实时嵌入式系统中并发的组件和组件并发的行为必须被细致地定义，并加以控制； 而组件之间的信息计算的模型（MoC）也必须被合理地定义； UML不能精细地定义并发的组件，带有RT-QoS保证性能约束的MoC也没有现成的“design pattern”可循。 UML语言的局限性（续） 笔者认为UML语言的局限性在于： （续） 2. 不能完整地支持系统范围的组件交互操作建模； 尽管UML确实以合作图等形式表达组件交互（interaction），但不能充分表达完整的系统范围中的组件交互； 原因在于：UML只支持有限的交互原语（primitive）——程序（procedure）调用和消息传递； 尽管所有交互可以映射为这两种原语——原语的构造； 但对于含有上千组件的系统，有很多构造的原语， 超出了开发者能够驾驭的规模。 3. 不支持精细的组件和系统的配置； 4. 不支持对故障管理的建模； 5. 无法分析系统的可调度性、活性（死锁）、安全性。 6. 不支持完整的系统综合与配置。 UML语言的实时扩展 扩展机制 构造型（stereotype） ：扩展UML的词汇； 标记值（tagged value）：扩展元素的特性； 约束（constraint） ：增加或修改规则。 从体系结构入手的扩展 UML语言的实时扩展（续） OMG提供两种轮廓框架(profile)作为标准UML的补充，以便适合于实时系统的建模： “可调度性、性能和时间说明规范” “建模服务质量和容错的特征及机制” UML语言的实时扩展（续） RT-UML的应用 限于形式化的能力，仍达不到形式化规格说明和形式化证明的水平 加入了对时间参数的语义表达 实时系统的描述与开发过程比较呆板 顺序图?泳道化?类图（对象图）?状态图 系统描述的规模较小 缺乏方法来指定UML模型的动态行为的约束 “设计模式” 设计模式只能抽象数据接口，不能支配动态行为 UML在实时系统开发中的职能 笔者认为： 与其将纯UML作形式化扩展，不如仅用它描述系统中不需要形式化表达的部分，起到开发人员的“共同语言”的作用； 将 非形式化、形式化、科学计算、可编程硬件开发工具集成起来，并用知识表达和过程管理工具相串联，使它们各司其职，有机地构成开发环境。 UML在实时系统开发中的职能（续） 对象的封装性与过程的动态性 虽然状态（成员变量）和方法是封装的，