Elevator Design

modelling-an-elevator-using-object-oriented-analysis-and-design

Ans1:

首先有一个电梯类，存储方向(up,down,stand,maintenance),一个当前floor，在那个方向存储的一系列floor requests，它接受这个电梯的请求。
会有一个中央管理库bank，包含电梯，从楼层接收请求。请求被发送到所有的活跃电梯中。
调度会如下：
- 如果当前楼层有电梯，则pick一个在当前楼层电梯
- 选择一个移动至当前楼层电梯
- 选择一个standing 电梯从其它楼层
- 选择最小加载的电梯
每个电梯有一系列状态
- maintenance：维护中，不接受请求
- stand：固定在某个楼层。它接受请求，如果在当前楼层，打开门。如果在其它楼层，移到那个楼层。
- Up:电梯向上移动。每次达到一个楼层，检查是否需要停留，如果是，停打开门。等待一段时间，关闭门。如果被需要打开门，则打开门。把这个楼层从请求列表移除，检查是否有其它请求。如果是继续移动，否则停止。
- Down：和Up类似。
额外的信号量：
- alarm：电梯停止。如果在某个楼层，电梯打开，请求列表清除，请求返回给bank。
- door open
- dooor close.

Ans2:是否需要一个中心化的尝试让这个系统智能且有效，有load balance(让更多空闲电梯到底层)。

从UML如何在实时分布式系统使用的不同观点出发，三组UML图标给出。这些图表区别主在它们的类图，着眼于object architecture，software architectur, 和system architecture.

UML简化了软件设计的复杂过程，做了构建的一个蓝本，现在是软件体系的标准概念。

Use Case diagram：显示了use cases 和actors（一个特殊的类）和他们的关系。Use case图成熟了一个系统的静态的use case。这些图表对于组织和建模一个系统的行为至关重要。
class diagram:一系列类，接口，合作和他们的关系。类图是最常见图在建模面向对象系统红。类图描述了一个系统的静态设计视图。
Sequence diagram
State chart diagram

用UML设计实时嵌入式系统存在以下挑战：

主要内容包括：

唯一的actor是乘客。乘客和电梯系统交互通过呼叫电梯。乘客决定是否进入电梯通过观察电梯的移动方向。因此use case图显示acotr和系统的四个case有关系。

静态视图主要提供一个系统的功能性要求——系统需要提供给用户的服务。
一个类图显示了一系列类，接口，合作和它们的关系。类图包含了全局系统描述，比如系统体系，和细节方面比如属性和操作在一个类中。类图最常见的内容有：

三组类图被提出和仔细分析：

Class Diagram- the object construction view 这个设计注定失败：
- 中心物体负担过重。所有计算和控制任务都必须和ElevatorController打交道。
- 一些其它物体的空闲。
- 竞争计算资源。
- 整个系统的低效性。
Class Diagram-the software architecture view 有两个不是控制物体在系统中：
- Dispatcher，只要功能是计算目标移动方向和移动位置对于电梯，维持门的打开时间。
- Safety。
乘客也被建模为环境物体。乘客和hall buttons,car buttons交互，让门移动，观察电梯的方向等。这个设计解决了中心控制问题，由于控制任务分配给几个控制物体，每个控制一个或多个环境物体，没有负担过重或者空闲的。没有必要竞争计算资源。仍旧有以下问题：
- 控制物体如何控制环境物体
- 一个物体入伙从其它物体获取必要信息
- 如何建模网络
Class Diagram- the system Architecture View 类图包含了更多细节，由于网络，传感器，制动器加入建模真实的系统体系。可以被分为八个种类.