系统建模复习

CPS系统 ​

什么是CPS系统？​

CPS全称Cyber-Physical Systems，即信息物理融合系统​

CPS系统的特征​

由新需求和应用驱动的信息物理耦合每个物理组件中的信息能力​

大规模有线/无线网络​

网络在多个极端尺度上建立系统之系统​

个人理解为建立一个系统，这个系统包含的第一公民是更小的系统新的时空限制​

多样的时空复杂度​

动态地再组织，再配置非常规计算与物理基础​

通信/计算/控制之间的新型交互​

高度自动化，在所有维度上的控制回路必须是闭环的控制回路中，存在大量不熟悉技术的用户​

无处不在的安全与隐私要求​

在一些情况下，操作必须是可靠的，可验证的​

CPS不是什么？不是桌面计算，传统的事后嵌入式/实时系统和传感器网络。CPS研究计划的目标:​

一门面向未来工程和监控/控制物理系统的新科学（以10-20年的视角展望）物理和信息技术（计算、通信、控制）设计深度融合​

× CPS应用领域( 不在review.ppt上)​

医疗健康 (医疗用具，健康管理系统)​

防御系统​

远程物理操作 (远程医疗)​

交通运输 (汽车电子，航空与空域管理，铁路系统)​

过程控制 (大规模基建，物理基础设施的监控与控制，发电与配电)​

MDA与模型驱动开发 ​

What is MDA?(非review.ppt内容)​

Model Driven Architecture® (MDA®) is an approach to software design, development and implementation spearheaded by the OMG. MDA provides guidelines for structuring software specifications that are expressed as models. MDA separates business and application logic from underlying platform technology​

模型驱动架构®（MDA®）是由OMG牵头的软件设计、开发和实施方法。MDA提供了构建以模型表示的软件规范的指南。MDA将业务和应用程序逻辑与底层平台技术分离​

总结：模型驱动架构(MDA)是软件开发流程的方法​

[from ​​www.omg.org​​]​

何为模型？​

它是某些系统的简化/抽象表示，从给定的角度突出感兴趣的属性。​

这个观点(即上文提及的给定的角度)定义了模型的关注点和关注范围。​

系统层次图:​

MDA的三种模型​

计算独立模型（CIM ,Coputation-Independent Model）​

描述系统的需求和将在其中使用系统的业务上下文。此模型通常描述系统将用于做什么，而不描述如何实现系统。CIM 通常用业务语言或领域特定语言来表示​

平台独立模型 （PIM,Platform-Idenpendent Model）​

描述如何构造系统，而不涉及到用于实现模型的技术。此模型不描述用于为特定平台构建解决方案的机制。PIM 在由特定平台实现时可能是适当的，或者可能适合于多种平台上的实现。​

平台特定模型 （PSM,Platform-Specific Model）​

从特定平台的角度描述解决方案。其中包括如何实现 CIM 和如何在特定平台上完成该实现的细节。​

这个图描述了开发时，CIM,PIM,PSM三者之间在时间上关系​

这个图描述了开发时，CIM,PIM,PSM具体做什么，他们之间的层次结构是怎么样的​

这个图进一步具体化描述了三者之间的层次关系​

安全攸关系统与实时系统 ​

实时系统定义​

在实时系统中，系统的正确性不仅取决于计算的逻辑结果，而且还取决于结果产生的时间。​

一些实时系统相关定义​

1. 时间约束（Timing constraint）：对执行时间行为的约束（包括硬实时和软实时）​
2. 发布时间（Release Time）：作业变成为可执行的时间。如果所有的工作在系统开始执行时被发布，那么就认为没有发布时间​
3. 截止期（Deadline）：工作被要求执行完成的时间。如果截止期是无限的，那么工作就没有截止期。绝对截止期等于发布时间加上相对截止期​
4. 响应时间（Response time）：作业从发布到执行完成的时间长度​

三种类型的系统​

事件驱动系统（Event-Driven System）​

其行为主要是对外部事件的特定反应来驱动而不是自发产生的。时间驱动系统（Time-Driven Systems）​

其行为主要由时间推移或时间的到来驱动。​

下图主要为事件驱动和时间驱动的区别​

及时性​

(时效性？我不知道怎么翻译，反正是这个意思，你懂就好)​

行动的及时性与满足时间限制的动作有关，如截止期时间。截止期可能是硬的，也可能是软的。错过一个硬截止期会构成某种系统故障，因此必须非常小心地确保所有此类操作都能及时执行。及时性的重要建模关注点是对执行时间、截止期、到达模式、同步模式和时间源进行建模。​

并发性​

并发是同时执行多个连续的操作链。这些操作链可以在一个处理器（伪并发）或多个处理器（真并发）上执行。围绕并发系统执行，必须处理一下问题：​

并发线程的调度特性进入事件的到达模式​

当进程必须同步时使用的复制模式控制共享资源访问的方法​

正确性与鲁棒性​

当一个系统在任何时候都做对的事情时，它就是正确的。这样一个系统在新的（计划外）情况下做对的事情时是健壮，即使在系统的某些部分出现计划外故障的情况下也是如此。必须警惕死锁、竞争条件和其他特殊情况。​

死锁​

产生死锁的四个条件​

1. 互斥,任务要求独占共享资源​
2. 占有且等待，当等待其他资源被释放时，任务保留资源​
3. 不可剥夺性，任务的资源无法被剥夺​
4. 循环等待，存在循环等待条件​

处理死锁的方法​

死锁预防：破坏死锁的必要条件​

死锁避免：允许前三个必要条件，但采取措施避免形成循环等待（如，银行家算法）​

死锁检查和死锁解除：系统检查是否存在死锁，若存在，则通过撤销部分进程等方法回收资源，解除死锁​

否定条件4的方法：​

信号量机制（如，哲学家进餐问题）使用定时会合（timed rendezvous）​

时间自动机 ​

时间自动机是实时系统建模与验证的理论。时间自动机本质上是一个用实值变量（时间系统）进行扩展的有限自动机（包含一组有限节点和一组有限带有标记的边的图）​

UPPAAL分为三部分：编辑器，模拟器，验证器​

其中编辑器用于设计模型，模拟器用于模拟时间自动机的进行，验证器用于验证模型是否符合特定的性质​

时间自动机的定义与元素构成​

变量（variables）对系统中的逻辑时钟进行建模，在系统启动时用零初始化，然后以相同的速率同步增加​

时钟约束（clock constraints），即边上用于限制自动机行为的约束（Guard）​

当时钟值满足在边上标记约束（Guard）时，边表示的转换（transition）就可以发生。 当进行转换时，时钟可能被重置为零。​

使用UPPAAL描述时间自动机​

模拟器与编辑器​

编辑器-声明的语法：​

验证器-性质验证的语法：todo​

时间自动机的形式化表达​

（并不想翻译这个，数学什么的最烦了啦）​

几个时间自动机的例子​

实时系统 ​

实时系统的调度算法：​

(后边会讲这两个算法)​

固定优先级算法, 如RM（Rate Monotonic，单调速率）​

动态优先级算法，如EDF，（Earliest Deadline First，最早截止期优先）​

实时操作系统的特性​

实时操作系统内核的实时性能定量指标包括​

任务上下文切换时间：中断延迟，响应，恢复时间，任务响应时间最大中断禁止时间：反映内核对外界停止中断响应的最长时间​

任务上下文切换时间：系统中最频繁发生的动作，影响整个系统性能​

包括：保存当前任务上下文、选择新任务，及恢复新任务上下文三个阶段​

一些实时系统的概念​

这里的Job,Work,Task含义是不同的​

Job( 我翻译成作业)，工作（work）的单位比方说计算，文件读取，消息传输​

属性​

执行所需的资源时间参数​

任务(Task)：它从读取输入数据及其内部状态开始，以生成结果和更新内部状态结束。​

(stateless)无状态任务：调用点上没有内部状态​

(statefull)有状态任务：有内部状态​

Task就是一系列类似的jobs​

定期任务是这样定义的: Periodic task(p,e)​

(Period)这个工作每p单位时间内都要执行​

(Execution time)e是在p时间段内，这个任务的最大执行时间(Utilization)利用率U= e/p​

截止期(Deadline)：软实时与硬实时​

硬截止期(Hard deadline,硬实时)​

超时则会发生灾难性和非常严重的后果 (记住它)​

验证是至关重要的：即使是在最坏的情况下，所有的最后期限都能得到满足吗？确定性的保证​

软截止期(Soft deadline,软实时)​

理想情况下，截止期前发挥最大性能。超时则性能下降。​

尽可能地通过各类方法和统计去保证​

可调度性​

指示实时系统（一组实时任务）是否能在截止期前完成任务的属性。​

实时调度​

决定实时任务的执行序列静态优先级调度​

动态优先级调度​

RM (Rate Monotonic)调度算法​

中文名：单调速率调度算法​

最佳静态优先级调度算法​

根据周期(Period)分配优先级周期越短，优先级越高​

每次执行最段周期的任务​

该算法的几个限制：第三句自己理解​

The original Rate Monotonic approach had several restrictions:​

1. all tasks are independent of each other(e.g. they do not interact)​
2. alltasksareperiodic

no task can block waiting for an external event.​

1. all tasks share a common release time(caled the critical instant)​
2. all tasks have a deadline equal to their period.​

最初的速率单调法有几个限制：​

1. 所有任务相互独立（例如，它们不相互作用）​
2. 所有任务都是周期性的

任何任务都不能阻止等待外部事件。​

1. 所有任务共享一个共同的发布时间（按关键时刻计算）​
2. 所有任务的截止期都与任务周期相等。

1. SignalEvent:信号事件​信号异步通信的规范，信号不知道什么时候来，当信号来的时候，将会作出某个动作。（相当于软件层面上的中断）​
2. CallEvent:调用事件​调用是同步通信的规范​
3. TimeEvent:定时事件​
4. ChangeEvent:变化事件​

响应时间​

这里不知道是所有任务执行完的时间还是任务3的响应时间，猜测应该是单个任务的​

RM算法的利用率绑定(Utilization Bound)​

借由该性质，可以判断一系列实时任务是否具有可调度性​

EDF(Earliest Deadline First)调度算法​

中文名：最早截止期优先​

截止期越短，优先级越高​

每次选择最早截止期的任务进行调度​

这句话应该是说EDF可以调度的任务集合​

实时操作系统特点​

提高内核实时性的方法: 任务互斥、同步​

资源有限等待​

任务没能获得需要的资源会被阻塞。如果资源不是任务继续运行必备的，任务可选择有限等待该资源。​

优先级反转​

什么是优先级反转呢？​

解决方法：​

优先级继承协议（课程只教了这个）低优先级任务继承高优先级的优先级​

多任务内核应允许动态改变任务的优先级以避免发生优先级反转现象 。为防止发生优先级反转,内核能自动变换任务的优先级,这叫做优先级继承(Priority inheritance)​

(不在复习范围内)优先权极限​

任务进入临界区时，提升其优先级至最高，退出临界区后，优先权恢复。使得任务可以尽快退出临界区。​

ROPES ​

前言说明​

注意，本节基本上是翻译其他ppt的内容​

其主要介绍ROPES的开发流程，以及每个流程中具体的步骤​

每个流程主要分这几部分讲述：是什么，元模型实体，Artifact，活动​

“是什么”主要讲述这部分主要干什么​

”元模型实体“主要讲述了它用的元模型内容是啥，其实就是构成这部分流程的用到的模型是什么Arrifact我不知道怎么翻译，它是指每个流程中，会用到的东西，比方说，需求，用例场景，类图等等​

活动主要讲这部分流程中，要做什么​

流程主要是分析-设计-实现-测试这四个部分​

元模型​

参考链接：​​http://blog.sina.com.cn/s/blog_8077b6d901012iyf.html​​ 1 什么是元模型​

首先我们知道，软件系统的开发过程中有很多种模型，这些模型往往有相似的地方，比方说活动图和状态图。​

元模型定义了描述某一类模型的规范，具体来说就是组成模型的元素和元素之间的关系。​

ROPES: Rapid Object-Oriented Process Embedded System​

快速面向对象过程嵌入式系统​

开发过程的步骤​

分析(Analysis)->设计(Design)->转化(Translation)->测试(Testing)每个阶段都允许关注同一系统的不同方面。​

分析阶段进一步划分为:需求分析，系统分析，对象分析。设计阶段进一步划分为：架构设计，机制设计，详细设计​

×需求分析-活动（指如何进行需求分析）​

PS：下面讨论会用到用例图和序列图，请注意，用例和用例图不是一个概念用例包含了用例图，状态图，外部事件列表，上下文图等​

需求分析步骤​

确定用例与相关的参与者用以下关系分解用例​

泛化（generalization）​

使用（包含）（uses (or includes) ）拓展（extends）​

识别并描述影响系统的外部事件​

定义可捕获系统动态行为的行为场景确定所需的约束​

与其他系统进行交互所需要的接口性能约束​

大多数系统由三种类型的用例构成：​

主要用例：系统外部可见且明显的功能​

辅助用例（次要用例）：不太常见，但仍可以识别出重要的功能​

安全相关用例：这些用例存在于除了正常功能外，系统还充当另一个系统的安全监视器或启用器时。​

一旦用例被定义了，则场景（Senarios）可以被更加详细地进行检查。场景是用例的实例化。​

PS：下面是讨论的其实是序列图​

在需求分析期间，还可以识别与系统及其属性相关的事件。此分析包括参与者发送到系统的消息和事件，以及系统对这些消息的响应。在此级层次上的每个消息的性能属性包括以下内容：​

参与者：​

消息发送者​

做出反应的接收者​

到达模式（周期性或突发性）：周期性就是周期地来，突发性就是不知道什么时候来​

消息的到达时间​

周期消息的周期和抖动​

突发消息的最小到达间隔或突发长度消息响应特性​

为硬截止期消息设定的截止期​

为软截止期消息设定的平均响应时间消息状态信息​

该消息的先决条件不变量通信协议​

消息数据​

响应的后条件不变量​

×需求分析-所用的元模型实体​

需求分析中，用到两种不同的元素：上下文元素和行为元素上下文元素定义了以下内容​

参与者（存在于系统范围之外的对象）​

系统对象用例​

用例关系​

外部消息（包括事件）危险​

行为元素包含了以下内容约束​

性能要求错容时间​

状态图​

状态​

转移边（transition，直接翻译是“转移”，其实就是状态之间的有向边）场景（scenario）​

交互协议（在参与者和系统交互时用到）​

× 需求分析-Artifacts​

工件（Artifact）:​

其定义是这样的：​

An artifact is one of many kinds of tangible by-products produced during the development of software. Some artifacts (e.g., use cases, class diagrams, and other Unified Modeling Language (UML) models, requirements and design documents) help describe the function, architecture, and design of software. Other artifacts are concerned with the process of development itself—such as project plans, business cases, and risk assessments.​

下面是各类工件的介绍​

×系统分析​

系统分析是什么？​

系统分析是大型复杂实时系统的一个重要阶段，如航空航天和汽车应用的系统。系统分析通常会详细阐述关键算法，并将需求划分为电子、机械和软件组件。通常，行为建模工具，如状态图，被用来构建可执行模型和探索系统动力学。​

×系统分析-活动（指如何进行系统分析）​

主要流程：​

识别划分出复杂系统的大规模组织单元为组织单元构建和分析复杂的行为规范​

将系统级的功能划分为三个工程学科: 软件,电子,机械（我翻译成机械，mechanics）用可执行模型测试行为（behavior）​

×系统分析-活动所用的元模型实体​

这图的“Artifact”与前边需求分析的Artifact差不多一个意思，只不过具体指代的东西有所区别​

× 系统分析-对象分析-活动​

主要流程：​

应用对象识别策略来发现系统的基本对象抽象对象得到类​

显化类和对象之间的关系，关联是怎么样的​

构建满足用例行为需求的对象协作机制（就是说根据这个用例，对象之间要怎么样进行通信，产生对应的行为）​

定义可反应对象的基本行为（可反应对象应该就是说你可以通过某种方法触发这个对象的行为）确定对象的基本操作和属性​

用场景测试已识别的机制（就是你发现的对象之间的协作机制）​

将端到端性能约束分解为类操作的性能约束（就是要把两个端的，比方说两台机器的，性能约束具体到每个类的操作上，这样才能满足实时性的要求。举例，A和B进行通信，RTT需要小于10ms，则具体到类的操作上，可以是send不超过5ms,receive不超过5ms）​

× 系统分析-对象分析-Artifacts​

× 设计​

当分析确定系统的逻辑或基本模型时，设计定义了一个在某种意义上是“最优”的单一特定解决方案。例如，设计将识别以下的东西：​

哪些对象是活动的（并发模型）应用程序任务调度策略​

可部署组件内的类和对象的组织处理器间通信介质和协议​

把软件组件分配到节点（特别是，当跳过了系统分析步骤)​

关系实现策略(关联应该如何实现？指针？引用？TCP/IP套接字？)状态机的实现模式；​

多值角色的管理（举例，1-*关联）错误处理策略​

内存管理策略​

× 架构设计-活动​

ROPES确定了架构的五个重要视图：子系统和组件、并发性和资源、分配、安全性和可靠性、部署。架构设计的主要活动是​

线程的识别和表征软件组件及其分发​

架构设计模式的应用：​

全局错误处理安全处理​

容错​

× 架构设计-所用的元模型实体​

由于设计模型是对分析模型的一种详细阐述，因此它由相同的一组元素组成。基本元素是协作、类、对象及它们之间的关系。​

在体系结构设计中，特别关注的是节点、组件和活动类。节点和组件捕获了物理部署体系结构。​

活动对象是作为线程的起源的对象。它们构成了UML并发模型的基础。​

× 架构设计-Artifacts​

× 机制设计-活动​

在机制设计中，通过添加其他对象来细化对象协作的细节。​

例如，如果一个控制器必须管理许多未决的消息，则可以应用容器-迭代器模式。​

这将导致插入一个容器（例如一个FIFO用来保存消息的队列）和允许操作该容器的迭代器。容器类和迭代器类充当“粘合剂”，以促进协作的执行。​

× 机制设计-Artifacts​

× 详细设计​

详细设计是设计的最低水平。它涉及到单个类的内部结构和行为的定义。​

（其实就是打代码）​

× 详细设计-活动​

一个典型系统中的大多数类都非常简单，不需要太多详细的设计。然而，即使在此时，也必须定义关联、聚合和组合的实现。​

此外，还必须指定操作的前条件不变量和后条件不变量、类的异常处理模型以及属性的精确类型和有效范围。​

对于一些小的类集，必须澄清复杂的算法。​

× 详细设计-活动-Artifacts​

× 转化（Translation）:todo​

转化阶段将UML模型转换为源代码，并通过编译器转换为可执行系统，如图所示。​

× 转化（Translation）-活动​

在一个不完整的转化微周期中，转化多少有一部分是自动化的。​

在详细说明的方法中，开发人员必须将UML模型元素映射到编程语言元素。​

如果使用了一种面向对象的语言，这个过程是相当机械的，因为所有重要的决策都已经在分析和设计过程中做出了。​

如果使用了一种非面向对象的语言，那么编程工作就会更具“创造性”。在这种情况下，通常要编写一个转化风格指南。本指南定义了程序员用目标语言实现UML模型的转化规则，无论是C语言、Pascal还是汇编语言。​

ROPES过程还包括本阶段的单元测试。单元测试是一组白盒测试，以确保被测试的单元实际上是内部正确的，并符合设计的要求。​

这通常由单元测试计划和单元测试程序文件组成，并最终形成一个单元测试结果文件。单元测试计划通常围绕类的基本单元进行组织。文档通常是在包或组件级别编写。​

× 转化（Translation）-Artifacts​

× 测试​

ROPES过程中的测试阶段包括集成测试和有效测试。​

测试将一组测试向量应用于具有可观察结果的应用程序。测试向量主要基于在需求和对象分析阶段中确定的场景。​

生成的工件（artifacts）是一个经过测试的应用程序及其显示的缺陷（比方说bug）。​

× 测试-活动​

所有的测试都应根据测试计划来执行，并严格按照测试程序文件来执行。​

在集成测试中，该系统是通过每次添加一个组件来构建的。在添加新组件的每个点上，都将测试通过添加该组件而创建的接口。​

有效测试由测试团队定义，并表示早期完成的需求和系统分析集。​

有效测试基本上是黑盒子。唯一的例外是对安全方面的测试。这些测试是白盒，因为通常需要进入系统内部并打破（break）一些东西，以确保安全操作被正确执行。​

× 测试-Artifacts​

× ROPES总结​

在ROPES模型中确定的阶段被组织成一个迭代的生命周期。每个原型通常实现一个或多个用例，按风险进行组织（风险更大的优先）。这允许对风险进行早期探索，并最小化由于这些风险而必须修改的模型方面的数量。​

为了探索这些风险，必须开发可执行的原型，因为只能测试可执行的东西。因此，使这一过程快速和高效的关键启用技术是将模型自动转换为可执行代码。这将完成迭代所需的时间从几周或几个月减少到几小时或几天。​

ROPES支持精细(elaborative)和转化（translative）的发展微周期，但倾向于后者(即转化)。​

UML建模（强烈建议直接看第三个ppt，复习PPT讲得有点拐弯抹角的，断断续续的） ​

将会讨论到的符号与概念​

以下是手动翻译​

英文名​	中文名​
AdvantagesofObjects​	对象的优点​
StructuredClasses​	结构化类​
Packages​	包​
InterfacesandPorts​	接口与端口​
Stereotypes​	模板​
Components​	组件​
Architecture​	架构​
ClassesandObjects​	类与对象​
Constraints​	约束​
Subsystems​	子系统​
Relations​	关系​
Tags​	标签​

对象，类与接口​

属性（数据）Attributes​

行为（操作或方法）Behavior状态（内存）State​

身份 Identity​

责任（就是该干啥） Responsibility​

举例：​

概览图：​

详细举例​

属性​

操作与方法​

概览：动态行为的建模​

行为的类型状态图​

活动图序列图​

行为和UML​

QOS约束：非功能性约束​

QOS约束通常使用一种约束语言进行建模。(OCL)​

行为与单一的对象​

UML的主要特征是他支持有限状态自动机(FSM)​

状态图的两个基本概念：状态与转移（是有向边附带了一些动作和其他属性，类似于下边的箭头）​

一个状态是一个不同于其他条件的实例的存在的条件。​

不相交的状态被称为 或-状态（or-states） ，因为对象必须处于其中状态之一。​

状态图​

这两个图主要说明了状态图是怎么样的，以及状态图进行状态转移时有进入状态和退出状态等动作。​

事件​

UML一共包含4种事件​

到达规定时间就会触发，但是规定时间之内离开了这个状态，就不会触发​

与属性的值更改关联的事件。它很少用于软件应用程序；但是，当一个状态属性被内存映射到一个硬件上时，它可以用来指示改变了值的内存地址。​

Transitions（转换）​

转移(Transition)是从起始状态开始到在目标状态结束的定向弧。转移通常可以指定事件触发器，然后选择在执行转移时执行的操作（即可执行语句或操作）。转移的事件签名的形式为：​

guard-expression指的是某个布尔表达式，比方说x==0，在判断约束表达式时，约束表达式里面的任何变量，比方说x，此时都是只供该约束的转移使用的，即实现了临界区互斥。​

事件可以指定正式的参数列表，这意味着事件可以携带实际的参数。​

行为的执行顺序很重要。最基本的规则是 exit-transition-entry，exit动作(从某个状态退出执行的动作)-转移(转移边上的动作)-entry(进入某个状态执行的动作)。​

参阅 ​​https://www.cnblogs.com/yxx123/p/5227267.html​​​

要会看懂这个图​

活动图​

UML1.x中的活动图在语义上等同于状态图，并共享一个共同的元模型。在UML2.0中，活动图的语义基础独立于状态图。在UML2.0中，有多个层次的活动图：基本、中间、完整，等等​

交互​

在UML中有三种主要的图解形式，用于描述交互场景​

通信图序列图时序图​

序列图（Sqeuence Diagram）​

序列图-部分顺序​

序列图-替代、分支、选项与循环​

时间图​

UML预定义包​

UML预定义包是一种用于使用补充信息来扩充UML模型的工具。这种机制可以用两种方式来使用：​

1. 它可以用于扩展UML语言。例如，UML不提供显式的信号量概念，但是可以通过重载现有的UML概念来添加它，例如Class。其结果是一种特殊的类，除了标准的类语义外，还包含了语量语义。​
2. 它可用于附加附加信息到辅助目的所需的模型，如模型分析或代码生成。例如，这样的注释可以用于指定类的某个操作的最坏情况执行时间，这可能需要用于分析应用程序的定时特性。​

实验 ​

实验一：学会使用Rhapsody创建新工程​

主要内容：​

在默认组件（Default Component）下创建了一个类，名为Display，然后右击类，选择显示所有属性和操作（即函数）。​

接下来为类新增一个Constructor(构造函数)，并在构造函数里面写入输出语句，这样这个类被实例化的时候即可输出信息。​

右击Diskplay，选择属性，在Propetires->ImpIndudes中填入<iostream>，相当于指示包含进去这个文件，以供输出​

更改DefaultComponent的名称为Test​

将配置（Configurations）下的默认配置信息（DefaultConfig）改名Release点击Release并在初始化中选择初始化Display的一个实例​

再次点击Release配置，选择设置，指定好Cygwin作为本项目的编译器​

此时点击生成并运行，则可以生成程序并看到输出（注意一开始，可能目录内并无所需的库，会开始编译这些库，此时需要比较长的时间）​

你也可以右击Display类，在Display类中编辑代码​

设置自建选项​

选择Tools->Customize->helper点击新建一个命令​

这样你就可以在Tools选择Explore，直接打开当前代码的文件夹​

实验二：时序图和状态图​

将实验一创建好的项目，点击另存，并新建一个文件夹进行保存，命名为CountDown然后打开这个项目​

接下来点击DisPlay这个类，执行以下操作（基本就是点点点吧，也没啥好说的，当然也可以右击​

DisPlay然后选择编辑代码）​

新增属性：int count;此时会自动增加操作：setCount和getCount​

新增两个重载的函数print,一个参数为int,一个参数为const char *，代码实现分别输出参数的内容将构造函数的语句改为​

实现函数isDone其内容为​

(写不下去了，感觉不如直接看指导书，后边直接说重点了)​

在类中新建一个状态图，记住，这个状态图是静态的，后边会说到运行时会有动态的状态图​

tm是延时函数​

C是伪状态之一的条件连接符然后run一下​

看到下图​

复制原有的Release配置，改名Debug，把里面改为动画​

接下来运行的时候，你就能“像调试一样”一步一步地运行程序，然后会有DisPlay的实例生成，这个时候你可以右击实例看他的动态状态图​

这时你可以看到实例处于哪个状态上​

接下来创建时序图，并增加两条边界系统边界和Display的边界​

这样就可以显示系统和Display之间和他们自身的时间序列行为​

同样，这个时序图也是静态的​

然后再次点击运行，系统会在你打开静态时序图时，自动地为你创建一个动态时序图​

最后你可以自己增加一个状态​

实验三：UPPAAL增加状态和写性质验证​

主要内容就是找出人-ATM-银行能否顺畅运行，会不会产生问题，会的话修改​

从上到下分别检查三个性质第一个是总钱数恒为一个数第二个是不会出现死锁​

第三个是ATM永远大于0（其实应该大于等于0）​

实验四：UPPAAL写同步机制与互斥机制​

性质一表示不可能有两个系统同时进入临界区性质二表示不可能死锁​