| 无双 回复于：2003-08-03 13:01:01
|
3 实时分布嵌入式系统总览
在讨论用UML 设计我们的电梯系统的细节问题之前，必须先对实时分布式嵌入系统的定义做一个界定。简述
用UML 进行完全面向对象的设计和分析时，它和一般的软件不同。接下来，本文将对在实时分布式嵌入系统的设
计中使用UML 的优缺点作大量的讨论。
Kopetz 说过实时计算机系统行为的正确性不仅和计算的逻辑结果而且和结果产生的物理及时性有关[1]。谚
云:“过时的正确结果是无效的”。在实时系统中性能要求和功能要求同样重要，我们不仅要完成正确的功能，还
要有必须完成这些功能的清晰系统边界。嵌入式计算机系统用一台计算机作为组件，但是它的主要功能不是一台
计算机。
作为一种面向对象技术，UML 用于实时系统的开发基本上是适合的。UML 中的方法自然地适合于描述和设计
实时系统。用例图描述的是人及外部设备和系统的相互作用。对象的顺序图描述的是包含时间的用例、引起相互
作用的事件和系统回应的细节。
类图帮助我们将系统的组件相互分开并定义它们之间的接口。这些技术足够用于捕获处理场景和识别可靠的
时间问题。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 32
X-Programmer
非程序员
18
现在我们来回答用UML 设计电梯系统的实践中遇到的问题：“UML 是一种适合于实时系统的建模语言吗?”我
们发现基于上段提到的特征，UML 是适合的但有不足。用UML 设计实时系统有以下问题：
.特定硬件及它们特征的定义。
.在对象、任务和硬件层次描述时间约束。
.网络建模。
在接下来的章节，我们将指出如何较好地用UML 描述电梯系统。下面的实践建议可能是标准UML 有益的补充。
|
| 无双 回复于：2003-08-03 13:01:17
|
4 系统静态建模
4.1 电梯控制系统快照
作为我们的教学项目，电梯系统的设计与“真实”的系统相比省去了很多技术上的细节。我们的电梯系统有
所有的电梯系统都有的基本功能，如上升和下降、开门和关门当然还有载客。电梯假设被用在一幢大楼的第一层
到第MaxFloor 层，第一层是大厅。电梯里有每一层对应的呼叫按钮。除了第一层和顶层，每一层都有两个按钮，
乘客可以呼叫上楼或下楼。顶楼只有一个下楼按钮，而大厅只有一个上楼按钮。当电梯停在某一层，电梯开门，
电梯指示灯亮标明当前运行的方向，这样乘客就知道了当前电梯运行的方向。电梯在两个楼层之间快速移动，但
它应该能提前减速停在目的层。为了保证电梯系统的安全，在任何不安全的情况下，紧急制动就会被促发，电梯
被强制停止。
4.2 用例图
所有系统和人或为了某种目的使用系统的自动化角色交互。人和角色都希望系统的行为是可预知的。在UML
中，一个用例对一个系统行为或系统的一部分建模，是对一组行为序列的描述，系统对一个角色产生的可见的结
果[2]。
用例图对系统的动态设计视图建模。它是一个系统行为、一个子系统或一个类建模的中心。用例图描述一组
用例、角色和它们的关系。用例图的主要内容是：
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 33
X-Programmer
非程序员
18
·用例
·角色
·依赖、泛化和关联关系
按照我们课程的需求文档，电梯系统的用例图如图1 所示：
图1：电梯系统的用例图
共有七个用例基于我们课程的需求文档，如图1 所示：
· 处理电梯呼叫：这个用例包括几个场景，本文接下来的部分兼作详细描述。这些场景有电梯接受乘客的呼
叫、电梯呼叫按钮的亮灭、系统控制部分电梯呼叫按钮信息的更新等等。
·处理楼层呼叫：和处理电梯呼叫类似，这个用例包括电梯接受乘客的楼层选择、楼层按钮的亮灭和系统控
制部分楼层按钮信息的更新等等。
·电梯的动/停：这是一台电梯的主要功能，详细的动作包括驱动速度的改变，停止的判定，电梯的运动方
向驱动。
·标识运行方向：电梯应该有这种机制，即让乘客知道电梯目前的运动方向，决定是否进电梯。
·标识电梯位置：类似的，电梯应该让乘客知道他/她的目的层是否到达，决定是否离开电梯。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 34
X-Programmer
非程序员
18
·开/关门：乘客进出电梯，电梯应该开关门。这个用例应该包括当电梯正关闭时乘客想进入，乘客可以使电
梯门反转。
·触发紧急制动器：电梯有安全机制确定一个不安全的状态不是瞬时产生的。
电梯系统的唯一角色就是乘客，乘客和系统交互完成任务。乘客通过呼叫电梯和楼层与电梯系统交互。
乘客通过观察电梯移动方向和电梯位置指示器决定是否进/出电梯。因此用例图表明角色和处理电梯呼叫、处
理楼层呼叫、标识运行方向和标识电梯位置四个用例有关。
|
| 无双 回复于：2003-08-03 13:02:27
|
图都传不上来
想看的话还是到UMLCHINA找好了 这是比较可惜的地方
4.3 类图
类图是面向对象系统中应用最广的图，它对系统进行静态建模。静态图主要描述系统的功能需求-系统给最终
用户提供的服务。从我们过去的实践经验来看，当用类图完成系统建模后会得到许多乐趣。系统类图的不同视图
将在本文后面的章节重点讨论。
类图描述一组类、接口和协作，及它们的关系。类图包括整个系统的描述，如系统的结构和细节，还有类的
属性和操作等细节。一个类图的基本内容有：
·类
·接口
·协作
·依赖、泛化和关联关系
·节点和约束
接下来的小节，将详细描述和分析三组类图。
在4.4 节中介绍每一张类图对应的顺序图。
4.3.1 类图-对象构造视图
从4.2 节的电梯系统用例和系统需求，我们直观地得到了如图2 所示的类图。
从图2 中类的描述我们可得出系统组成的一些概念。我们不深入细化类成分，如每个类属性和操作，这超出
了我们当前视图的范围。基于此，我们从系统对象组成的角度，建立了类图。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 35
X-Programmer
非程序员
18
·电梯控制器：电梯系统的核心控制对象。和系统中所有其他对象通信并控制它们。
·门：系统中有两扇门，“上帝”对象-电梯控制器-命令门打开和关闭，这和用例中的描述相对应。
图2：类图-对象构造视图
·电梯：电梯在控制下上升和下降（用不同的速度），需要时可以停下。
·按钮：电梯控制器类（ElevatorControl）也控制按钮类，按钮类生成两个子类电梯呼叫按钮类和楼层呼叫按
钮类（CarCallButton and HallCallButton）。控制对象和按钮对象通信，得到按钮是否被按下，反过来控制按钮灯的
发光。
· 指示器： 系统有两类指示器， 电梯位置指示器（ CarPositionIndicator ） 和电梯方向指示器
（CarDirectionIndicator）（例如：电梯灯）。指示器提供电梯的当前位置和移动方向。
·安全装置：依照需求文档中紧急制动器的定义，任何紧急情况时，电梯控制器触发安全装置。
这个版本的类图是直接从4.2节中用例图的描述得来的，这个视图中的类覆盖了系统所有的功能。我们用电梯
类和电梯控制器类（ElevatorControl）移动或停止电梯；用门类开门或关门；用指示器类让乘客知道电梯的位置和
方向；乘客用按钮类来完成呼叫电梯或选择楼层；我们用安全装置类来满足系统紧急制动的要求。所有的类和中
心控制器类都有接口，而中心控制器类的任务是控制所有类的动作。这个类图帮助我们从对象划分和系统功能的
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 36
X-Programmer
非程序员
18
的角度理解系统的基本设计。
当我们试图深入我们电梯控制系统的设计，找到我们自己的详细设计方法，从这个类图开始得到我们系统的
好的实现时，问题就出现了。在本文中，用已有的架构设计系统和完成UML 文档的顺序是颠倒的。我们从老师那
里“继承”一个设计好的电梯系统，不是首先用UML 进行系统设计，而且在用UML 之前，手中已经有了软件的部
分设计。正是由于上述的原因，在遇到真正的难题之前，我们就知道这个类图不是一个完美的最终设计。
但在其他情况下，设计者迟早会在以后发现这个设计对开发阶段不适合，这几乎是肯定的。基于前面的讨论，
每一个组件（软件/硬件）是由一个处理器来控制的，假如我们的系统是一个普通的中央控制的系统，则我们现在
类图的方案可能不会导致将来的设计缺陷。但是分布嵌入系统的特征决定了电梯系统的类图仅仅从对象的角度来
设计是不够的。
分析手中已有的类图，我们未来软件的潜在缺陷如下。如果不能找到更好的方案，软件的设计会失败。
·控制对象负担过重：从前面的分析我们可以发现作为控制中心，电梯控制器对象（ElevatorControl）必须
和其他所有的对象交互。所有的计算和控制任务必须由这个对象完成。
·其它一些对象的空闲：电梯控制器（ElevatorControl）不停的工作，其它的一些对象，如按钮和指示器象
系统的界面一样，更糟的是象门和电梯等对象竟然是系统的一部分-如“硬件“。从软件控制的角度来看，他们在
系统的范围之外。
·计算资源的争夺：当超过一个对象想同时得到中央控制对象的控制时，这些对象竞争控制器有限的计算资
源是不可避免的，一些对象不能及时得到维持正常运行的控制消息，而这在实时系统中会导致致命的缺陷。
·整个系统的低效率：即使控制器的计算资源足够快/多，能处理每一个控制请求并及时做出反应，中央控制
对实时系统（如电梯）仍然不是一个有效的方案。
4.3.2 类图-软件架构视图
前面的分析和教学项目的软件架构类图被模拟证明非常适合电梯控制系统，并从从这个角度得到类图。
类图提供怎样设计和实现控制系统的方法。真实电梯控制系统的软件架构精确的反映在这个图表中。除了
Dispatcher，所有其它的控制对象都是从超类电梯控制器继承而来。这些控制对象共享电梯控制器的一些属性，
而且有用于其控制对象的自己属性和方法。被控制对象所控制的对象被定以为环境对象。虽然这些环境对象存在
于电梯系统，但不属于软件控制系统。下一节我们将从系统架构的角度详细讨论这些不能控制的对象。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 37
X-Programmer
非程序员
18
·门控制器（DoorControl）控制门马达的动作，一个电梯的两个门马达都是由一个门控制对象控制的。门马
达能够发出打开门，关门或门反向运动的命令。
·驱动控制器（DriveControl）控制电梯驱动，它将电梯上下移动在需要时停下，是主要的马达。
·指示灯控制器（LanternControl）有两个，每一个控制一个电梯灯，标示电梯的当前运动方向。
·楼道按键控制器（HallButtonControl）每一层有两个，一个控制上升一个控制下降。楼道按钮控制器处理
楼道按键的按下及给楼道呼叫灯反馈。
·电梯按钮控制器（CarButtonControl）用于每一层都在电梯里。电梯按钮控制器接受电梯呼叫按钮
（CarCallButton）的呼叫，而且控制相应的电梯呼叫灯的开关。
·电梯位置指示器（CarPositionIndicator）赋值给电梯位置指示器，乘客可以知道电梯当前的位置。
图3：类图——软件架构图
在系统中有两个非控制对象：
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 38
X-Programmer
非程序员
18
·Dispatcher 不控制实际的电梯组件，但它在软件系统中是重要的。每一个电梯有一个Dispatcher，主要
功能是计算电梯的移动方向、移动目的地以及保持门的打开时间。它和系统中除灯控制器以外的几乎所有控制对
象交互。
·安全装置也是一个环境对象，它不属于控制软件，但是系统的重要部分。在真实世界中，如果一台电梯的
紧急制动被触发，则安全装置动作变化。但在我们的模拟系统中，只显示一些信息。
在我们的系统中，乘客也作为一个环境对象来建模。乘客和楼层呼叫按钮、电梯呼叫按钮交互，使门反转，
观察电梯的方向和位置等。为了简单，乘客对象没有在图3 中列出（不像其他的环境对象）。
软件的类图解决了前一节提出的大多数问题。控制任务被分配到几个控制对象中，每个控制一个或两个环境
对象，都没有负担过重或空闲。不需要竞争中心控制器的计算资源，因为由控制器控制其受控对象。
但是从这个类图引发的，关于我们系统实现细节问题如下：
·控制对象如何控制环境对象？
·一个对象如何从其他的对象得到必需的信息？
·如何对网络建模
从系统架构的角度，这些问题必须回答。
4.3.3 类图——系统架构图
为了回答上一节提出的问题，类图要加入网络、传感器/传动装置进行细化，以对真实系统的架构进行建模。
从这一点来看，系统的类图和普通UML 图的类图不完全一样。但类图是描述系统静态结构的一种有效的途径，为
什么不用它来帮助更好的表达系统架构？
类图中的各个部分如图4，被分成如下8 类：
控制类
·前一节我们对系统中的控制对象作了大量的陈述。从系统架构来看控制对象包括电梯位置控制、电梯按钮
控制、灯控制、门控制、驱动控制、楼层按钮控制和Dispatcher（CarPositionControl，CarButtonControl，
LanternControl，DoorControl，DriveControl，HallButtonControl and Dispatcher.）。
·所有的控制对象连接到网络，从网络得到输入并发送输出消息到网络给其他的对象。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 39
X-Programmer
非程序员
18
·控制对象控制一个和传感器及传动装置相连的系统实体（如门和按钮），从传感器得到信息，并发送反馈
到传动装置执行控制功能。
网络
·所有的控制对象和通信网络连接，在图的中间用网络类来建模。网络是（编注：此处缺1 页，抱歉）
图4：类图——软件架构图
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 40
X-Programmer
非程序员
18
系统传感器
·系统值是用于控制系统的。在类图中系统传感器用一个箭头和系统控制对象连接。
·类图中的系统传感器包括AtFloor、电梯呼叫器、关门、开门、门反转、楼层呼叫器和驱动（AtFloor，CarCall，
DoorClosed，DoorOpen，DoorReversal，HallCall，and DriveSpeed.）。
·除了AtFloor，所有系统传感器通过物理网络接口和他们的控制对象相连，控制对象从传感器得到消息，
通过网络发出正确的控制消息。
仅环境传感器
·系统中有两个仅环境传感器：，门的位置和电梯的位置（DoorPosition and CarPosition）。他们用虚线
和系统控制对象相连。
·仅环境传感器是“伪随机传感器”，不能被控制系统访问，但可用于模拟。
系统制动器
·在类图中，系统制动器用从控制对象出发的箭头和控制对象相连。
·类图中的系统制动器包括门马达、电梯灯、电梯位置指示器、楼层灯和驱动（DoorMotor，CarLantern，
CarLight，CarPositionIndicator，HallLight，and Drive）。
仅环境制动器
·类图中紧急制动是仅环境制动器，使用虚线和安全装置对象相连。
环境对象
·在类图中用阴影列出的安全装置、驱动和门马达是环境对象。
·环境对象通过操作激励者间接访问控制系统。
对象组
·对象组包括电梯、门、Dispatcher、驱动、层，和安全装置，每一个由一个虚方框包围。
·系统架构中对象组的关系如图5。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 41
X-Programmer
非程序员
18
·看一看前面段落，可以对图5 和图2 做出比较。
我们发现图5 中的对象结构向更加分布作了改进。与图2 中的实现不同（，图2 中，以一个中心控制对象处
理系统中的所有控制任务），每一个(组)对象有自己的功能范围，和系统中的其他对象协作。我们加入环境类“乘
客”得到的图5 中的类图的进化版。
图5：类图-修正的对象构造图
|
| 无双 回复于：2003-08-03 13:03:04
|
4.4 静态结构小结
4.3 节中，三个不同的类图以进化的方式给出了电梯系统的不同视图。每个视图描述系统的一个方面，给出
了系统集成时系统设计的全局理解。
从对象构件的角度，类图描述了对象结构问题的解决方案。通过描述一组对象的通信和协作实现一个功能。
对象通过发送消息和别的对象通信。相同功能的对象归为一个类。
类图通过捕获系统的主要功能而得到，给出了系统的框架。从软件架构的角度，捕获了更多设计和实现的细
节。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 42
X-Programmer
非程序员
18
从这个类中得到的类图，构划出了软件的大部分设计。
系统结构视图提供软件和整个系统结构最复杂的也是最优雅的描述。和通常的软件系统相比，在分布式嵌入
系统中了解系统组件如何协同工作是非常重要的。毕竟，每个类图仅仅是一个系统的静态设计视图的一个图型表
示。
单个类图不能捕获一个系统设计视图的全部内容。
一个系统的类图结合起来描述系统的全部静态设计，分开只是描述一个方面。
5 系统动态建模
UML 提供顺序图和协作图对系统动态建模。在本文中，只给出了电梯系统的顺序图，协作图能由顺序图很容
易得到。
基于这学期课程项目的设计，电梯系统的状态图也在这部分给出。从我们的设计练习，给出了一些关于如何
从需求到设计的经验方法。
5.1 顺序图
顺序图是一种交互图，描述一组对象的交互和它们的关系。(另一种交互图是协作图)。顺序图的目的是在一
个有时间关系的视图中描述对象之间的消息序列。对于单个(部分)用例，典型的顺序图范围包括所有的消息相互
作用。每个用例可以有多个顺序图，而每个用例场景有一个顺序图。
状态图通常包括:
· 对象
· 联结
· 消息
· 响应时间( 在实时系统中尤其有用)
垂直的"生命线" 表明对象间的联结。消息在对象生命线之间流动。UML 支持在顺序图中标明响应时间，描
述一个实时系统的性能需求。时间流从上到下。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 43
X-Programmer
非程序员
18
在以下的章节的顺序图中，对象从软件结构角度的类图得来。那样做的原因是我们不想停在对象构造视图上，
因为对象构造视图中对象的功能是模糊和不充分的； 也不想停在系统结构视图中，因为许多技术上的细节阻碍了
对对象的相互作用的快速理解。
因为乘客发出一些消息，在一些顺序图中乘客似乎是系统的一个对象。
5.1.1 用例1 –处理门厅呼叫
在这个用例中有二个场景:
当乘客按门厅呼叫按钮请求一个门厅呼叫服务时，一个场景是电梯向与乘客的目的地相同的方向移动，另一
个是反向移动。
这二个场景共享一个顺序图，唯一的不同是乘客进入之前的推进的时间，也就是(x sec) 在图中反映电梯的
运行时间。
场景1.1 门厅呼叫服务–电梯的移动方向和乘客的目的地相同。
场景1.2 门厅呼叫服务–电梯向乘客的目的地的反方向移动。
图6: 场景1.1&1.2- 门厅呼叫服务
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 44
X-Programmer
非程序员
18
5.1.2 用例2 –处理电梯呼叫
这个用例有二个场景:乘客进入电梯和按电梯呼叫按钮。乘客可能想要去楼上或楼下，与电梯当前的移动方向
有关。当电梯经过乘客或当在附近的楼层徘徊时，乘客可以到达目的层。这二个场景可以共享同一个用例。
场景2.1 电梯呼叫服务–电梯向乘客的目的相同的方向移动。
场景2.2 电梯呼叫服务–电梯向乘客的目的地的反方向移动。
图7: 场景2.1&2.2- 电梯呼叫服务
5.1.3 用例3 –移动/ 停止电梯
这个用例有二个场景:
场景3.1&3.2 移动电梯–命令停止状态的电梯开始移动。移动方向和电梯的目的层由调度器给出。电梯的移
动从慢速到快速。场景3.1 向上移动而场景3.2 向下移动。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 45
X-Programmer
非程序员
18
图8:场景3.1&3.2-电梯由停止到慢速移动到快速移动
场景3.3&3.4 停止电梯–当电梯快要到达目的的层时，它应该被命令减速，最后停在目的层。
图9: 场景3.3&3.4-电梯由停止到慢速移动到快速移动
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 46
X-Programmer
非程序员
18
5.1.4 用例4 –指示电梯位置
这个用例有二个场景，分享一个顺序图:
场景4.1 指示电梯位置–每当电梯的门打开，命令CarPositionIndicator 亮标识当前的电梯位置。
场景4.2 完成指示电梯位置–当门关闭的时候，命令CarPositionIndicator 亮标识目的层。
图10:场景4.1&4.2-标识电梯位置
5.1.5 用例5 –标示移动方向
这个用例有二个场景，分享一个顺序图：场景5.1 指示移动方向(向上的) –电梯的门打开及电梯的目的方
向是向上的，向上的CarLantern 亮。门关闭时，CarLantern 熄灭。
场景5.2 指示移动方向(下) –当电梯的门打开及电梯的目的方向向下，下CarLantern 亮。当门关闭，
CarLantern 熄灭。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 47
X-Programmer
非程序员
18
图11: 场景5.1&5.2- 指示移动方向
5.1.6 用例6 –开/关门
这个用例有三个场景:
场景6.1 开门–当电梯停在楼层，门应该开启一段时间(DesiredDwell)，乘客才能进入电梯。
场景6.2 关门- 在一特定的时段(Desiredperiod)–门应该关闭，以便电梯能移动到下个目的地。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 48
征 稿
http://www.umlchina.com/xprogrammer/xprogrammer.htm
X-Programmer
非程序员
18
图12:场景6.1&6.2-开关门
场景6.3 门逆向–当门正在关但不完全关闭，如果有乘客
想要进入电梯，门应该再打开一段时间，然后再关闭。
UMLChina 培训
UML/.NET--N 层架构开发
通过讲述一个案例从业务建模到实现的开发过程，结合工具，使
学员自然领会OOAD/UML 的思想和技术。
11 月9 日北京公开课，详情请见>>
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 49
X-Programmer
非程序员
18
图13: 场景6.3- 门逆向
5.1.7 用例7 –触发紧急制动
这个用例有五个场景: 场景7.1 紧急制动1 –如果电梯停止但是它没有停止在目的层，紧急制动被触发。
图14: 场景7.1- 紧急制动- 电梯在目的层不停止
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 50
X-Programmer
非程序员
18
场景7.2 紧急制动2 –如果电梯被命令移动但是它没有动，则紧急制动被触发。
图15: 场景7.2- 紧急制动- 电梯不动
场景7.3 紧急制动3 –当电梯停止在某一楼层时，如果命令门打开，但是门不开，则紧急制动将触发。
图16: 场景7.3- 紧急制动- 门将不开启当电梯停止在目的层
场景7.4 紧急制动4 –如果电梯移动时门打开，紧急制动将触发。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 51
X-Programmer
非程序员
18
图17: 场景7.4- 紧急制动-当电梯门是打开的时候移动
场景7.5 紧急制动5 –如果到达升高界限时电梯继续上升，紧急制动将触发。
图18:场景7.5- 紧急制动-到达升高界限时电梯继续上升
5.2 状态图
一张状态图表明一种状态机。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 52
X-Programmer
非程序员
18
通常状态图中状态机针对对象行为建模。对象的行为通过响应它的上下文之外分发来的事件最好地表征。对
象有一个清楚的生命期，它的过去影响了当前的行为。状态图对通过正向工程和逆向工程构造可运行的系统很重
要。这是承认在从需求到状态图的设计过程存在一个鸿沟，在从需求画状态图没有足够的方法可用。在本节中，
介绍我们设计电梯系统状态图一些实际的方法。这些方法可能不是如何从需求文档画出状态图严格的规则或指令，
但是在练习中他们是有帮助的。
5.2.1 DoorControl 的状态图
图19: DoorControl 的状态图
5.2.2 DriveControl 的状态图
图20: DriveControl 的状态图
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 53
X-Programmer
非程序员
18
5.2.3 LanternControl 的状态图
图21: LanternControl 的状态图
5.2.4 HallButtonControl 的状态图
图22: HallButtonControl 的状态图
5.2.5 CarButtonControl 的状态图
图23: CarButtonControl 的状态图
5.2.6 CarPositionControl 的状态图
图24: CarPositionControl 的状态图
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 54
X-Programmer
非程序员
18
|
| 无双 回复于：2003-08-03 13:03:31
|
5.2.7 Dispatcher 的状态图
图25: Dispatcher 的状态图
5.3 填补从需求到状态图鸿沟的实用方法
状态图能对类的行为，一个用例，或系统整体建模。在本文中，状态图被用于每个对象的行为建模。在系统
后面的阶段，如实施阶段和测试阶段，每个对象的状态机都将用到。
UML 中没有提供详细的方法，即该如何从需求文档或UML 图表如类图画出状态图。我尝试在这里从课程上的
项目经验总结一些从需求文档画出状态图实用的方法，如下:
第1 步:
如果你想画出每个对象的状态图，应该完成对象结构和系统架构的分析。在我们的课程项目中，这部份工作
在我们开始自己的项目之前由老师完成了。
第2 步:
仔细读系统中每一个类或对象的需求。
状态图的大部分需要的信息都可以通过这个方法找到，提供好的充足的需求文档就可以了。我不确定需求文
档有没有任何格式标准。
举一个我们课堂中的例子来说用，我们的电梯系统需求文档中有一些方面应给于不同的关注。
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 55
X-Programmer
非程序员
18
· 回答: 这个部份简述主要功能和特殊对象的存在条件。画状态图的时候这个部份用处不大，但是当状态图
完成时可以用来检查功能实现了没有。
·初始化:初始状态由给出的信息决定。以HallButtonControl 为例，初始状态是" 所有的HallCalls 初值
是false " 和" 所有的HallLights 初值是关"。从这些描述中我们至少能得出结论：初始状态是"门厅呼叫是
False " 或" 门厅Light is off 灯是False "，但这还不完全，让我们继续。
· 输入介面: 这个对象将会从其他的对象中取得的输入信息。
输入变量将触发状态变化，例如状态图中的过渡。
在HallButtonControl 例子中，DesiredFloor 和HallCall 的数值变化，建立一组事件，触发我们未来状
态图中所有的状态变化。
· 输出介面:这些信息帮助建立状态图中的状态。在我们的例子中，
HallLight 是这个对象的处理的单一输出。我们可以想象一下HallLight 可以处于多少个状态。凭直觉门厅
灯能打开和关闭，因此它在状态图中可能有两个状态:
开和关。
让我们看看还有没有别的东西需要加入。
· 状态: 这里的状态和状态图无关，在这些项中一些记号用来速记描述行为。
· 约束和行为:都将用来检查这个对象的状态机是否实现了系统的功能需求而不打破约束。我们从行为描述
知道状态机的变化如何被触发，这很重要。
第3 步:
现在我们有来自需求的一些想法。现在可以产生最初的状态机。
对于HallButtonControl，我们有二个状态:
"门厅灯开" 和" 门厅灯关"。
从给出的初始信息，初始的状态应该是"门厅灯关"。行为定义： " 当HallCall[f，d]是真，则指令
HallLight[f，d] 为On "，这是第一个状态变化从on 到off；同样地，"如果DesiredFloor.d 是Stop，则命令
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 56
X-Programmer
非程序员
18
两个HallLight 切换到off"，改变状态从on 到off。在此，状态机停下来等一个新的门厅呼叫。
第4 步:
我们决定增加每个状态机的前置条件、后置条件、行动、入口码和退出码，这些状态机是从约束和行为相关
的需求文档得到。
第5 步:
检查事件的组合是否覆盖所有状态。
第6 步:
检查是否有死状态，没有( 组合) 事件可以使状态机从该状态变换到其他状态。
第7 步:
一项项地按照行为运行状态机，确定所有的需求条件被覆盖，而且状态机改变状态，采取行动，正确地修改
变量。确定没有遗漏和冗余。
第8 步:
正确地画出每一个对象的状态图、标示状态、守卫条件、进出码和过渡，记录用于跟踪的相应需求。
6 结论
在这份报告中，给出了一个模拟电梯控制系统详细的UML 文档。这个文档中用到的UML 图包括用例图、类
图表、顺序图和状态图。在课程项目设计过程中，实时系统中如何使用UML 图得到了大量的关注，我们项目的成
功对这个问题给出了一个很好的答案。由于当前UML 版本的流行和广泛的符号化，OO 技术可以在实时系统开发中
得到适度的发展。
目前面向对象分析和设计方法重心只是在系统的软件。对于实时系统不是完全合适，实时系统需要对系统开
发作出整体苛刻的要求而不仅仅是软件。
实时系统的一些方面：
·硬件元件的定义和他们的特性
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 57
X-Programmer
非程序员
18
·任务的定义和任务的通信
·时间限制
·网络的建模。
如果适当地注意系统的实时特征和不同点的组合，对实时系统的设计和分析有很大的帮助。
为了描述硬件元素和对网络建模，我们用三种不同的视图对系统结构建模。对象构造和软件结构都将重点放
在系统的软件结构上，而从系统结构角度给出了一个系统硬件的略图和系统组件间的通信方法。为了描述时间约
束给出了顺序图和协作图，通过消息和对象的名称标识时间约束标识系统的实时特征。每个图表仅仅是系统的一
些方面的一个图形表示。没有单个图表可以覆盖一个系统设计的所有东西。图表结合起来表达实时系统的完全描
述。系统类图的三个不同的视图有助于了解系统的结构。
本文给出的一些我的项目经验实用方法，可能有助于填补需求和设计之间的间隙。当建立系统的图表的时，
已经存在一些组件，如系统结构和状态图。不清楚上面总结的方法在一般系统的分析和设计过程中是否仍会有效。
举例来说，系统架构-类图是以Phil Koopman的电梯架构为基础的(这个报告的附件)，它使用非标准的UML语言。
这里的问题是:UML语言有没有好到，在没有架构图时仍然可以设计系统架构？
本文中电梯系统的功能描述仍然限制在课程项目。而在真实世界中更可能需要一些其他特征，例如一个火警
按钮、或一个风扇锁。然而，给出了系统的框架，这些附加的功能可以被毫不费力的增加到系统的静态和动态的
描述中。
7 参考文献
[1] Hermann Kopetz. Real- ， Time Systems Design Principles for Distributed Embedded Applications.
， [2] Grady Booch James Rumbaugh and Ivar Jacobson. The Unified Modeling Language User Guide.
[3] Perdita Stevens and Rob Pooley. ， Using UML Software Engineering with Objects and Components.
[4] Martin Fowler and Kendall Scott. ， UML Distilled A Brief Guide to the Standard Object Modeling Language.
[5] Bruce Powel Douglass. Doing Hard Time: Developing Real- ， ， ， time Ssystems with UML Objects Frameworks and Patterns.
[6] Desmond F. D’Souza and Ala n Cameron Wills. ， ， Objects Components and Frameworks with UML.
[7] Alan Moore and Niall Cooling. Developing Real- ， Time Systems using Object Technology A white paper from Artisan Software Tools.
[方法]
电梯系统的UML 文档
软件以用为本http://www.umlchina.com 58
|
