这个版本的类图是直接从4.2节中用例图的描述得来的，这个视图中的类覆盖了系统所有的功能。我们用电梯类和电梯控制器类（ElevatorControl）移动或停止电梯；用门类开门或关门；用指示器类让乘客知道电梯的位置和方向；乘客用按钮类来完成呼叫电梯或选择楼层；我们用安全装置类来满足系统紧急制动的要求。所有的类和中心控制器类都有接口，而中心控制器类的任务是控制所有类的动作。这个类图帮助我们从对象划分和系统功能的的角度理解系统的基本设计。
当我们试图深入我们电梯控制系统的设计，找到我们自己的详细设计方法，从这个类图开始得到我们系统的好的实现时，问题就出现了。在本文中，用已有的架构设计系统和完成UML 文档的顺序是颠倒的。我们从老师那里"继承"一个设计好的电梯系统，不是首先用UML 进行系统设计，而且在用UML 之前，手中已经有了软件的部分设计。正是由于上述的原因，在遇到真正的难题之前，我们就知道这个类图不是一个完美的最终设计。
但在其他情况下，设计者迟早会在以后发现这个设计对开发阶段不适合，这几乎是肯定的。基于前面的讨论，每一个组件（软件/硬件）是由一个处理器来控制的，假如我们的系统是一个普通的中央控制的系统，则我们现在类图的方案可能不会导致将来的设计缺陷。但是分布嵌入系统的特征决定了电梯系统的类图仅仅从对象的角度来设计是不够的。
分析手中已有的类图，我们未来软件的潜在缺陷如下。如果不能找到更好的方案，软件的设计会失败。
·控制对象负担过重：从前面的分析我们可以发现作为控制中心，电梯控制器对象（ElevatorControl）必须和其他所有的对象交互。所有的计算和控制任务必须由这个对象完成。
·其它一些对象的空闲：电梯控制器（ElevatorControl）不停的工作，其它的一些对象，如按钮和指示器象系统的界面一样，更糟的是象门和电梯等对象竟然是系统的一部分-如"硬件"。从软件控制的角度来看，他们在系统的范围之外。
·计算资源的争夺：当超过一个对象想同时得到中央控制对象的控制时，这些对象竞争控制器有限的计算资源是不可避免的，一些对象不能及时得到维持正常运行的控制消息，而这在实时系统中会导致致命的缺陷。
·整个系统的低效率：即使控制器的计算资源足够快/多，能处理每一个控制请求并及时做出反应，中央控制对实时系统（如电梯）仍然不是一个有效的方案。
4.3.2 类图-软件架构视图
前面的分析和教学项目的软件架构类图被模拟证明非常适合电梯控制系统，并从从这个角度得到类图。
类图提供怎样设计和实现控制系统的方法。真实电梯控制系统的软件架构精确的反映在这个图表中。除了Dispatcher，所有其它的控制对象都是从超类电梯控制器继承而来。这些控制对象共享电梯控制器的一些属性，而且有用于其控制对象的自己属性和方法。被控制对象所控制的对象被定以为环境对象。虽然这些环境对象存在于电梯系统，但不属于软件控制系统。下一节我们将从系统架构的角度详细讨论这些不能控制的对象。
·门控制器（DoorControl）控制门马达的动作，一个电梯的两个门马达都是由一个门控制对象控制的。门马达能够发出打开门，关门或门反向运动的命令。
·驱动控制器（DriveControl）控制电梯驱动，它将电梯上下移动在需要时停下，是主要的马达。
·指示灯控制器（LanternControl）有两个，每一个控制一个电梯灯，标示电梯的当前运动方向。
·楼道按键控制器（HallButtonControl）每一层有两个，一个控制上升一个控制下降。楼道按钮控制器处理楼道按键的按下及给楼道呼叫灯反馈。
·电梯按钮控制器（CarButtonControl）用于每一层都在电梯里。电梯按钮控制器接受电梯呼叫按钮
（CarCallButton）的呼叫，而且控制相应的电梯呼叫灯的开关。
·电梯位置指示器（CarPositionIndicator）赋值给电梯位置指示器，乘客可以知道电梯当前的位置。
图3：类图------软件架构图
在系统中有两个非控制对象：