电梯系统的UML文档04
这个版本的类图是直接从4.2节中用例图的形貌得来的，这个视图中的类覆盖了系统所有的功能。我们用电梯类和电梯控制器类（ElevatorControl）移动或停止电梯；用门类开门或关门；用指示器类让乘客知道电梯的位置和方向；乘客用按钮类来完成呼唤电梯或选择楼层；我们用安全装置类来满意系统紧急制动的要求。所有的类和中心控制器类都有接口，而中心控制器类的任务是控制所有类的动作。这个类图资助我们从对象划分和系统功能的的角度明白系统的根本计划。当我们试图深入我们电梯控制系统的计划，找到我们自己的详细计划方法，从这个类图开始得到我们系统的好的实现时，题目就出现了。在本文中，用已有的架构计划系统和完成UML 文档的顺序是颠倒的。我们从老师那边“继承”一个计划好的电梯系统，不是首先用UML 进行系统计划，而且在用UML 之前，手中已经有了软件的部分计划。正是由于上述的原因，在碰到真正的困难之前，我们就知道这个类图不是一个完善的终极计划。
但在其他情况下，计划者迟早会在以后发现这个计划对开发阶段不得当，这几乎是肯定的。基于前面的讨论，每一个组件（软件/硬件）是由一个处理器来控制的，如果我们的系统是一个平凡的中心控制的系统，则我们现在类图的方案可能不会导致未来的计划缺陷。但是分布嵌入系统的特征决定了电梯系统的类图仅仅从对象的角度来计划是不够的。
分析手中已有的类图，我们未来软件的潜伏缺陷如下。如果不能找到更好的方案，软件的计划会失败。
·控制对象负担过重：从前面的分析我们可以发现作为控制中心，电梯控制器对象（ElevatorControl）必须和其他所有的对象交互。所有的计算和控制任务必须由这个对象完成。
·其它一些对象的空闲：电梯控制器（ElevatorControl）不绝的工作，其它的一些对象，如按钮和指示器象系统的界面一样，更糟的是象门和电梯等对象竟然是系统的一部分-如“硬件“。从软件控制的角度来看，他们在系统的范围之外。
·计算资源的夺取：当凌驾一个对象想同时得到中心控制对象的控制时，这些对象竞争控制器有限的计算资源是不可避免的，一些对象不能实时得到维持正常运行的控制消息，而这在实时系统中会导致致命的缺陷。
·整个系统的低效率：纵然控制器的计算资源足够快/多，能处理每一个控制哀求并实时做出反应，中心控制对实时系统（如电梯）仍然不是一个有用的方案。
4.3.2 类图-软件架构视图
前面的分析和教学项目的软件架构类图被模拟证明非常得当电梯控制系统，并从从这个角度得到类图。
类图提供怎样计划和实现控制系统的方法。真实电梯控制系统的软件架构正确的反映在这个图表中。除了Dispatcher，所有其它的控制对象都是从超类电梯控制器继承而来。这些控制对象共享电梯控制器的一些属性，而且有用于其控制对象的自己属性和方法。被控制对象所控制的对象被定以为环境对象。固然这些环境对象存在于电梯系统，但不属于软件控制系统。下一节我们将从系统架构的角度详细讨论这些不能控制的对象。
·门控制器（DoorControl）控制门马达的动作，一个电梯的两个门马达都是由一个门控制对象控制的。门马达能够发出打开门，关门或门反向运动的命令。
·驱动控制器（DriveControl）控制电梯驱动，它将电梯上下移动在需要时停下，是主要的马达。
·指示灯控制器（LanternControl）有两个，每一个控制一个电梯灯，标示电梯的当前运动方向。
·楼道按键控制器（HallButtonControl）每一层有两个，一个控制上升一个控制降落。楼道按钮控制器处理楼道按键的按下及给楼道呼唤灯反馈。
·电梯按钮控制器（CarButtonControl）用于每一层都在电梯里。电梯按钮控制器接受电梯呼唤按钮
（CarCallButton）的呼唤，而且控制相应的电梯呼唤灯的开关。
·电梯位置指示器（CarPositionIndicator）赋值给电梯位置指示器，乘客可以知道电梯当前的位置。
https://i-blog.csdnimg.cn/direct/6de2157518f44db1ba89fe57cc20a68c.png
图3：类图——软件架构图
在系统中有两个非控制对象：
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]