计算机毕业论文155319Word文档格式.docx
《计算机毕业论文155319Word文档格式.docx》由会员分享，可在线阅读，更多相关《计算机毕业论文155319Word文档格式.docx（27页珍藏版）》请在冰豆网上搜索。
在系统对象间双向发送消息及事件。
关键字：
用例、事件、场景
目录
1.1概述4
1.1.1用例4
1.1.2事件4
1.1.3场景、协议和状态机4
1.2用例5
1.2.1用例间的关系7
1.3外部事件8
1.4指定外部消息10
1.4.1外部事件列表10
1.4.2响应时间10
1.5用例行为详述11
1.5.1非形式文本描述12
1.5.2场景12
1.5.3顺序图13
1.5.5用状态图定义用例行为15
1.6用例实例分析15
1.7使用用例18
1.8制作好的需求分析图的启发方式19
1.8.1用例图的启发式方法19
1.8.2用例的启发式方法19
1.8.3用例顺序图的启发式方法20
结论21
参考文献22
1.1概述
1.1.1用例
用例是一个函数，该函数返回一个对参与者而言可观测的值，但并不揭示函数的设计结构。
粗略地看上去，用例很像是功能点，功能点是外部可见的一个紧凑的系统功能块，用例是功能分解的一种形式。
用例不是类，试图将用例映射到特定的类将会导致对用例的不恰当选择或者构造出一个糟糕的对象模型。
用例必须最终通过对象的协作来实现用例的功能，而这些对象也常常协作以实现许多不同用例。
用例与参与者相关联，这意味着用例可以与参与者之间进行消息的发送和接收。
参与者是存在于系统范围之外的对象。
参与者可以是物理设备或系统进行交互的用户。
具体情况取决于相应的构成物理接口的设备是否被系系统本身所包含。
1.1.2事件
事件可以触发消息的发送。
事情会在对系统有一定意义的某个时空中发生。
外部环境中发生的事件可以表现为系统要对其作出响应的消息。
UML定义了四种事件构造型：
信号事件、调用事件、变更事件和时间事件。
信号与异步的信号事件相关联。
信号是请求的子类型；
请求反过来与UML元模型中的MessageInstance相关联。
CallEvents是操作调用或服务请求的结果所引发的事件。
CallEvents与OperationCalls相关联；
而OperationCall也是request的一个子类型。
在值得注意的数值发生变化时会引发change事件。
Time事件既可以在指定的时间段逝后发生，也可以在系统到达某绝对时间点的时候发生。
所以这些事件类型都与用例分析相关，但最常见的是Signals.
1.1.3场景、协议和状态机
用例是对系统的一个内聚的功能块的定义。
用例的实例是执行该行为的一条特定路径，这样的路径称作场景。
场景由一个对象集合（这里，有些对象是“系统”对象。
另外一些则来自参与者集合）和在对象间交换的一个有序的消息列表组成。
场景中有一些分支点，在这些分支点上，对参与者或系统的响应或动作可能有多个。
具有一组独立分支点集合的执行路径就构成了一个单独的场景，这样就需要多个场景才能完整地细化一个用例。
场景中既包含主要分支点，也包含里外分支点。
通常，至少要为每一个分支点的一个场景进行建模。
如果几个场景仅在例外分支点方面有所不同，就可以被忽略掉。
场景之间存在很大的不同，因为系统在这些场景中的行为都各不一样。
并不是所有的场景差异都是我们所要关心的。
比如这样一个场景，领空中所出现的其他飞机的航线与新航线偏差很大，就确定新航线而言，系统的行为无需改变。
给所有场景建模是不可能的，这是因为场景的全集是无穷大的，或者接近于无穷大，场景间差异已经无关紧要。
尽管如此，我们还是要对所有值得注意的场景，也就是能够使系统的行为产生本质改变的场景建模，这一点是很重要的。
值得引起注意的场景的集合是有限的（尽管可能很大），要全部定义出来。
这些用例和场景图为讨论系统行为提供了公共的语义和符号。
然而，场景最多也能称得上半构造性的（semi-constructive）。
因为根据定义，所有场景都省略了系统的大部分行为，我们必须对所有场景的总体作仔细的检查，以保证这些场景已正确地记录了需求信息。
另一种记述用例行为的方法是通过状态图。
UML编程过程是在状态图中定义的，由于状态图的表达性和可伸缩性都很好，UML用它们作为正式的FSM（有限状态机）表示，有限状态机是由已存在的条件（称为“状态”）的有限集定义的机器，同样也是状态间因事物触发的状态转移有限集。
状态图的优点是更为形式化和更为严格它是完全构造性的（fully-constructive），一个状态图就表示了用例的全部行为。
在可以使用状态图的场合，通常都使用状态图和场景一起来为用例的行为建模。
1.2用例
用例图主要用来表示系统和外部对象相互作用的一般情况，用例图依赖于底层否认事件和消息流，这些事件流和消息流在上下文中都有所表示。
图1-1是一个典型的用例图。
（可选的）矩形框系统的边界，人形图标代表参与者，椭圆形表示用例。
参与者和用例之间的连线表示关联，借助关联可以交换信息。
用例可能同其他用例间存在关系，图中所显示的从一个用例泛化为另一个用例既体现了这种关系。
但是，用例不定义甚至不暗指任何特定的内部系统结构。
用例通过对象间的协作来实现。
这些协作由一组一起工作的对象组成，用来完成用例对应的功能。
图1-1用例图
顶层用例图是系统环境的一个视图。
这个用例图给出了系统的概貌，不是类和对象的信息，而是与功能点相关的信息。
功能点是对系统功能的一种泛指，与用例的形态相同。
注意，参与者可能参与一些用例，但与其他用例无关。
用例是可能牵涉很多参与者、很多消息的一般性事务。
用例之所以非常重要，是因为它们记述系统需求提供了一种很有价值的工具。
在UML中，用例是元类classifier的元子类型（metasubtype）。
Classifier可以拥有属性、操作和状态图。
有一点必须记住，即便用例中可能包含结构元素，也不对对象的或者实现结构进行定义。
属性、操作和状态图必须由对象实现（objectimplementation）以某种方法实现（realized），但通常不存在直接映射关系。
用例的属性通常被用来说明用例的（对外可见的）状态。
这一点很重要，尤其是在用例参与到一个相关参与者间的复杂交互时。
属性也可以用于存储用例行为描述的取值。
需要再次强调的是，用例给出这些属性并不意味着这些属性会出现在现实中。
一个用例可以具体有操作。
用例的操作是一些功能块，用例可以使用功能块的划分对指定用例的行为规格说明进行分解。
用例的操作不能在用例外部直接访问，只是作为一种对用例进行划分和详细定义的方法。
行为可以用状态图、文本描述、活动图或形式化语言声明来定义。
用例的行为描述应该不仅包括主要行为，还要包括常见的变化情况和异常状态。
用例几乎无一例外地被用来来描述黑盒形式的系统功能。
用例通过与参与者相交互完成这项工作。
参与者是类元的用户，处于类元之外。
因为用例大多是应用在整个系统上，所以几乎所有的参与者都是系统环境的一部分。
尽管如此，用例也可用来描述系统内部的较低抽象层次的部分（或类元）。
这时，使用该用例的“系统”可以是其他类元，如一个类。
使用该用例的类的对等类构成了该抽象层次上的参与者。
1.2.1用例间的关系
1．用例的泛化关系
这种关系声明了一个用例（称为基本用例，baseusecase）是另外一个用例（称为导出用例，derivedusecase）的更一般的形式。
就像类的泛化一样，更特殊化的用例继承了基本用例的所有属性、操作和状态图。
导出用例可以对基本用例进行扩展和特化。
2.用例的扩展关系
<
extends>
>
关系是两个用例间依赖关系的一种构造型。
被扩展的用例称为基本用例（baseusecase）；
扩展后的用例称为客户用例（clientusecase）。
所体现的思想是，基本用例在其行为描述中给出许多特定的扩展点。
这些扩展点位于基本用例中，客户用例可在这些扩展点上插入额外的行为。
基本用例可以有许多扩展点。
客户用例为基本用例中的扩展点定义扩展序列。
依赖的箭头指向基本用例。
3.用例的包含关系
includes>
关系也是依赖关系的一种构造型。
包含关系定义了一种行为片断，该行为片段将被包含在基本用例中。
引入行为片断的用例被称为客户用例（clientusecase）;
提供被包含行为的用例则称为提供者（supplierusecase）.当若干用例使用同一个行为单元时，这种关系常有用。
不需要在每个用例中重复相同的行为，把这个行为单元提供取出来，作为一个提供用例就可以了。
依赖的箭头指向提供者用例。
图1-2形象地表示了各个对象和用例之间的关系。
driver（司机）启动是否进行ATP的操作，一旦启动ATP超速防护系统，ATPdevice（ATP车载设备）就处于超速允许防护状态，接受目标速度和实时运行速度，进行比较；
如果司机允许速度操纵列车，速度监督设备不干预司机的正常操作。
当司机违章操作或列车运行超过允许速度时，ATP车载设备将自动实施制动。
其中，车载设备主要实现以下几个功能：
initialtrain（自动并初始化车载设备），acquireactalspeed（获得实际速度），acquireactualspeed（获得列车实际运行的实时速度），acquirelimitedspeed（获得允许速度，即入口段的列车速度），acquiregoalspeed（获得出口区段的目标速度），protectspeed（对列车运行速度防护及监督），announceemergency（超速警告），braketrain（当发现列车超过允许速度，强行制动列车）司机要实现的功能是：
brakebyhuman（人工制动）以及activitateATP（模式开关的选择和司控开关状态的采集）
图1-2用例关系
1.3外部事件
系统上下文（systemcontext）是对需引起系统重视的外部世界的刻画。
我们将用术语系统（system）来描述概念上的整体，这个整体由所要开发的软件、电子硬件和机械硬件组成。
用例图将系统显示为一个现实世界中其他对象包围的实体，描述它们之间所传递的重要消息。
上下文级消息
UML将消息（message）定义为对象通信的基本单位。
决定消息的实现方法，如对象行为的有向调用、RTOS消息或通信总线上的消息。
在开发过程目前所处的位置，记述系统和与之交互的参与者之间交换的消息的基本属性更为重要。
后续的设计将定义每一个消息的实现。
消息属性
事情的发生对系统很重要。
事情与类相似，可以包含数据。
事情在系统中通常以对像间或者参与者与系统间的消息传递来显现。
例如，一个控制旋钮被旋转时可以发送一个事件。
一种方法是每次点击按钮发送一个事件；
另一种方法则限制事件以某种频率发送，这时，点击次数被作为事件消息的参数传递。
事件消息因此不但传递了事件发生这个事实，还传递了点击次数信息。
因为事件通常被作为事件消息（状态机中的消息除外）来操纵，所以我们在这里将不区分术语事件（event）和消息（message）.
消息到达模式描述了消息实例集的时序行为。
UML没有直接对此进行描述，但是到达模式的特征刻画对可调度性分析和期限分析是至关重要的。
尽早定义消息到达模式是非常重要的，这是因为对成本敏感的产品而言，其可行性通常取决于组件和开发成本。
通过对消息和事件特征的了解，可以早一点完成关于不同类型处理器架构的性能分析，以便作出较好的业务决策，及产品是否能够在一个可接受的成本范围内提交。
消息的到达可能是偶尔发性（episodic）的或周期性（periodic）的。
偶尔性到达模式比周期性模式从本质上讲更难预测，但是我们仍有很多方法对它进行限定（bound）。
很明显，如果消息到达时间完全是未知的，而系统必须对这些消息作出响应，系统的可调度性分析就无从谈起。
要进行可调度性分析，就需要刻画偶发性事件到达时间的特征。
偶发性消息可以用如下特性进行描述：
●界定时间，比如最小（最大）两次到达时间间隔（minimummaximuminter-arrivaltime），定义了两次消息到达之间的最小（最大）间隔时间。
●集中趋势和离散统计，如平均到达速率（averagearrivalrate）及相应的标准偏差（standarddeviation）和标准误差（standarderror）。
●各个消息到达间的自相关依赖关系。
即使不知道背后的概率密度函数，对到达时间间隔进行界定或者沙箱（sandboxing）也使得我们能够完成最坏情况分析。
通常，平均到达率是已知的，与之相关的离散统计量也是已知的。
如果这些消息可用，我们就可以进行更详细的分析，对软实时系统可调度性的分析尤为有用。
大多数简单的分析都假定事件到达是相互无关的。
比如，一对消息之间的时间不会影响消息序列中下一个消息的到达时间。
不过，消息到达时间并不总是相互无关的。
有时，某些消息之间可能具有时间相关性。
一个消息的出现很可能意味着另一个消息将很快到达，这被称作消息到达时间之间的自相关性依赖。
比如，一些消息到达时间趋于成批到达，这样的消息通常作为突发（bursty）。
周期性消息具有一定的周期（period）特性，消息按一定的周期到达，并可以有一定的抖动（jitter）。
抖动是指消息实际到达时间与周期点间的偏离。
抖动在建模的过程中通常被视为一个均匀随机过程，但其值总是在指定的时间间隔内。
UML标准明确地为同步模式提供支持，尽管在某种程度上UML对此的描述能力不是很强。
两个对象间交换消息时会出现汇合点，同步既定义了汇合点的特征。
UML明确定义的同步模式有调用、异步和等待模式。
调用和等待同步模式相似，二者都要求发送者被阻塞，直到目标完成消息处理后才能继续。
调用同步机制（callsynchronizationpattern）模拟同一控制线程发生函数或方法调用时控制权的转让情况。
等待同步模式（waitingsynchronizationpattern）则模拟了直到消息处理
结束后才将控制交给另一线程的情况。
远程过程调用（RPC）通常正是使用这种同步模式实现的。
异步同步模式（asynchronoussynchronizationpattern）从本质上就是多线程的方式，模拟了把消息传递到另一个对象但不转让控制权的过程。
限定还定义了阻行和超时同步模式，都是UML核心模式的扩充。
阻行同步模式（balkingsynchronizationpattern）模拟了一个对象在另一个对象没有立刻做出合法响应时放弃消息传递的情形。
超时模式（timeoutpattern）与阻行模式类似，只是为接受对象接受消息定义了固定的等待时间。
Ada编程语言的任务结构能够为阻行和超时同步机制提供明确的支持。
1.4指定外部消息
在实时系统中，外部消息（包括事件）在约束和定义系统行为方面扮演着重要的角色。
比如，一个空中交通控制系统必须响应和处理来自多个传感器的消息，如雷达的“Ping”消息给出方位（辐射）角和距离，异频信号给出飞机的标识和建议位置，此外还有控制中心的命令，用来管理显示内容（包括设置缩放级别、禁止声音警告等等）。
系统和参与者之间的关联提供了相当丰富的实际事件集合，这个集合可以分解事件层次图。
事件本身提供的消息对系统开发来说是不够的。
系统对每个事件的预期响应必须从系统需要完成的动作及对该响应的时间约束等方面进行说明。
此外，我们通常还会需要一个复杂的协议，用以描述事件的所有可能的合法序列和消息交换的序列。
单独每个事件的特征通常可在外部事件列表中记述。
事件和消息交换的协议最好用与该用例相关的顺序图和状态图集合来描述。
1.4.1外部事件列表
外部事件列表是系统所关注的、外部环境中发生的事件和消息的详细列表。
外部事件列表不仅定义了事件，还定义了预期的系统响应、事件的到达模式和事件来源。
表1-1是我们这个空中交通控制系统的外部事件列表。
表1-1ACME空中交通控制系统外部事件列表
事件描述方向到达模式响应性能
1主雷达脉冲周期性命令，传递主雷达脉冲到主雷达周期性以20ms为周期
2主雷达返回来自飞机或者周围物体的表面反射到系统偶发性<
10ms的响应
3辅助雷达脉冲周期性命令，传递辅助雷达脉冲到辅助雷达周期性以20ms为周期
4辅助雷达返回转发器对请求的响应到系统偶发性<
5雷达控制同步脉冲发送给系统的脉冲，用于确认雷达到系统周期性以2s为周期
发射机位置
6用户光标移动用户通过定点设备移动光标到系统偶发性<
5ms的响应
7用户屏幕命令用户通过按钮或者点击事件选择菜单到显示设备偶发性<
100ms的响应
或者菜单项
8气象因素标识外界气象系统更新气象元素地图到显示设备周期性<
50ms的响应
9相隔距离冲突检测冲突必须显示在屏幕上到显示设备偶发性<
10领空活动日志所有飞机和气象状况等领空信息必须到日志设备周期性周期100ms,
定期记入日志误差10ms内
1.4.2响应时间
在实时系统的领域中，定义外部时需求对理解问题是相当关键的。
一个即便正确的结果的提交时间如果过了期限，对于一个硬实时环境而言也属于系统失效。
问题的关键是要扩展外部事件列表，使之包含反应式时序信息。
要指定实时系统的定时需求，需要很多参数。
当然，被接受的消息的定时特性必须被刻画出来。
如果消息是周期性的，则它们的周期和抖动范围必须定义。
如果消息是偶尔发性的，则它们的随机属性必须定义，系统响应时间需根据时间要求（最有代表性的就是期限）来定义。
如果响应要求有硬期限，则错过期限就意味着系统失效。
在软期限的系统中，必须规定其他的守时性衡量方法，如可接受的平均延迟时间。
越复杂的时序为需要越复杂的建模过程。
在某些情况下，使用标量（如期限）就足以规定行为响应的时序特性。
但是这种方法只是在使用传统的、硬期限的时序模型时才是合法的建模技术。
实际上在大多数系统中，使用硬期限虽然简单，但不能保证所有的期限都能满足，这时，使用效用函数更为合适。
效用函数将动作的有用性（“效用”）建模为时间的函数。
起点是触发行为的事件发生或动作自身的启动，硬期限是一种简单的模型，如果在期限前完成对事件的响应，则效用函数返回值为1，否则为0（如果行为绝对不可完成时，值为付无穷）。
也就是说，硬期限假定事件响应效用值是一个二元函数，在一个特定点（期限）上是不连续的。
更细致的效用函数也是可以实现的，包括：
1.可缩放二元函数，可以对不同事件响应的相对效用进行比较（如，比较4和18）。
2.平滑效用函数，平滑效用函数没有断点，将事件响应值建模为具有一定值域的函数，即便响应很慢也不被视为没有价值。
3.可变效用函数，可变效用函数允许效用函数的形式随时间变化（“累积效用”）。
很多动作的执行需要持续一段很长的时间，过程中间的响应（即便是部分响应）可能是非常重要的，例如，通过将控制棒插入核心，可以实现核反应堆的紧急关闭，这个操作可能被某个事件所触发，如冷却液泄漏或核反应温度变高或压力增大。
插入的过程需要一段时间，为了避免可能发生的“事故”，最好的方法就是尽快插入控制棒的前90%，即便插入剩下的10%需要更长的时间。
再如控制环系统。
快速的响应（即便不完整）能够保证PIC控制环处于稳定状态，即便系统响应在很晚之后才开始收敛。
这些问题是领域和系统所特有的。
在很多情况下，我们只关心服务时间和延时。
在某些特殊应用中，对50%或80%的响应时间进行建模可能是很重要的。
在另外一些应用中，可能只需要激励响应曲线中的几个点，就足够刻画性能需求特征。
在大多数实时系统中，时间响应需求都是非常重要的，因为这类需求为系统行为定义了性能预算。
随着对象和类被定义出来，这项性能预算会沿着分析和设计阶段传播下来。
最后，性能需求在执行线程对时间作出响应时，体现为各个操作和函数调用的性能预算。
所有（子）预计之和必须满足这里所给出的整个系统的性能需求。
例如，一个消息和他的响应的完成共需要500ms。
整个响应是通过6个一连串的操作实现的。
则每个操作必须分担整个性能预算的一部分。
1.5用例行为详述
用例是一个命名的内聚性功能块。
好的用例名称是很重要的，因为这有利于理解对外部可见行为的功能划分。
尽管如此，名字本身无法详细定义说明用例所暗含的行为，以构建一个正确的系统。
因此，UML允许用户对用例的行为作更详细的规格说明，尽管UML没有规定具体的形式。
最常见的规格说明方法有：
1．非形势文本描述。
2．正式文本描述（例如，用编程语言或约束语言表达）。
3．场景。
4．状态图。
1.5.1非形式文本描述
考虑“监测飞机安全间隔距离违例”这个用例。
可以使用的算法有很多。
假定领域专家给了我们这样一个算法，用如下的文本形式描述：
系统将使用α-β追踪系统：
新位置=α×
预测的位置＋β×
测量的位置
测量的位置由目标回复的倾斜范围（使用光速以及两倍的距离，因为反射的原因，我们使用信号到达的时间，也就是说需要一个计时器从传输信号发出时开始计时）和方位角确定。
我们需要计算多次应答的方位角的平均值作为“返回的”方位角。
我们现在已经得到了倾斜范围和方位角。
为了得到与地面平行的距离。
我们需要知道海拔高度。
如果能从主雷达（没有ID信息）和辅助雷达确定轨迹，就可以通过辅助雷达知道海拔高度。
主雷达和辅助雷达可以位于一起，但是一般不是这样。
当它们没有在一起，必须执行一次几何变换以保证它们使用相同的参照空间原点。
现在你已经得到测量位置。
你所需要只是原来的位置和预测的位置，后继位置可通过外推法得到。
在轨迹起点，没有原来位置和预测位置信息可用。
所以，最开始的位置通过测量得到。
然后进行第二次扫描时，你可以通过距离差值速率（没有多普勒雷达）。
开始时，你不能使用加速度进行外推，不过经过几次度量后，即可使用有限差作为一阶导数的估计值。
从而可以得到飞机的位置、速度和加速度。
间隔距离是位置的差值，预计的间隔距离是也预计位置之间的差值。
此外，每次飞机计划提交后，系统将查找已知的飞行计划集合，以查找计划中可能存在的位置冲突。
这是在接受飞行计划之前做的。
在审核飞行计划过程中，到达时间首先被确定下来，这样就不存在飞机跑道承载能力超过要求的问题（飞机跑道是有限的资源）。
因为飞机按一个标准到达路线STAR）接近飞机跑道，所以按照STAR的路径，根据飞机在这个阶段（到达时间差已知，且速率已知，所以距离间隔就可知了）的常规速率，就可以计算距离。
包括建筑在内的地形图是通过以下参数得到的：
飞机间距计算、飞机的位置和预计位置。
如果轨迹中的某个位置的可信性较低，就需要更大的间隔。
1.5.2场景
场景是用例的特定实例。
对象之间通过协作来产生系统行为，场景能够对对象间交换的与顺序相关的消息序列建模。
给定用例中的多个场景显示
升级会员 