一、 实验内容
使用面向对象设计方法对保温系统与电梯系统进行架构设计。
二、实验目的
学会如何分析一个系统的架构并进行设计，学会用面向对象方法实现架构设计。
三、实验过程
问题C.保温系统
（一）案例背景
如果主开关置于“加热”状态，保温系统的控制器负责开关锅炉，监视锅炉系统的燃油流量和燃烧状态，进而调节进入房间的热量流。当室内温度降至(Tr-2)℃以下，控制器启动锅炉。这里Tr是用户设定的理想室温。
- 锅炉启动过程如下:
（1）控制器向锅炉的马达发信号。
（2）控制器监视马达速度。马达达到正常操作速度时，启动点火并打开油阀。
（3）控制器监视水温，一旦水温达到预定值，发信号打开水流循环阀。热水开始在室内循环。
（4）如果发生异常情况，燃油流量指示器和光感器向控制器发信号。此时控制器发信号关闭系统。
（5）一旦室内温度达到（Tr+2）℃，控制器首先关闭油阀，延迟5秒后关闭锅炉马达。
2. 系统须满足以下限制:
（1）锅炉停机后重启必须延迟5分钟。
（2）在主开关关闭或油阀关闭5秒内应指示锅炉停机。
（二）架构设计
- 划分子系统
图1.保温系统的子系统图
根据题目描述可以大致将保温系统划分为状态、控制器和锅炉三个子系统。
（1）状态子系统
问题域：主开关的状态，控制器监视马达速度、水温、锅炉内的燃油流量状态以及燃烧状态。
交互：与控制器子系统进行交互，控制器监视系统状态并改变状态；与锅炉子系统交互，当获得控制器发送的信号时，锅炉将启动马达，改变马达速度，并对油阀进行操作，从而改变自身的燃油、燃烧状态。
数据：主开关、锅炉状态。
（2）控制器子系统
问题域：控制器发送信号给锅炉进行相应的操作，并监视锅炉的状态以及水温的状态，锅炉停机后重启必须延迟5分钟，当主开关、油阀关闭需在5秒内指示锅炉关闭。
交互：与状态、锅炉子系统进行交互，接受其状态的变化，并控制锅炉进行相应的操作。
数据：记录系统状态的变化。
（3）锅炉子系统
问题域：锅炉接受控制器发送的信号，并启动点火，打开关闭油阀等。
交互：与控制器、状态子系统进行交互，接受控制器发送的信号，并完成相应的操作从而改变状态。
数据：记录燃油流量、燃烧状态、水温状态、水流循环量。
- 逻辑视图
（1）控制器的状态图
图2.控制器的状态图
（2）锅炉启动的顺序图
图3.锅炉启动的顺序图
- 用例视图
通过分析并划分子系统，可以发现系统参与者有控制器、锅炉、燃油指示器、感应器以及定时器等，控制器参与者是整个系统的核心，它接受来自其他设备参与者发送的外部信号并控制着系统的运行，外部信号可来自于光感器和检测水温的温度计等外部设备。锅炉的状态也有控制器控制，燃油指示器、感应器是根据系统的状态发送相应的信号，而定时器可以限制锅炉的启动等时间，如下是保温系统的用例图。
图4.保温系统的用例图
- 运行视图
根据分析可知像感应器等外部设备是发送相关信号给控制器，而控制器则控制着锅炉的状态，可以大致得出保温系统的运行架构如下。
图5.保温系统的运行架构图
- 开发视图
通过使用迭代式方法对保温系统的逻辑视图和物理视图以及它的用例视图和运行视图进行分析，已经深入了解了此系统的基本框架和架构，接下来便开始分析它的开发视图。分别分析每一层所需要使用的组件以及框架等，开发架构图如下。
图6.保温系统的开发架构图
- 分层架构与物理视图（迭代1）
6.1 分层架构
通过划分子系统以及对用例视图的分析的过程，且由用户可以设置保温系统的最高温度值，并且可以打开主开关，因此应该还有用户交互层，逻辑架构图，如图3。
图7.保温系统的分层架构图
6.2物理视图
控制器接受信号的来源是主开关的变化、感应器和温度计等其他外部设备，而整个系统的中心是控制器，控制器的输出信息是则是锅炉的输入信息，因此可大致得出以下物理架构图，如图4。
图8.保温系统的物理架构图
- 分层架构与物理视图（迭代2）
7.1 分层架构
有了初步的逻辑分层后，现在再继续深入考虑逻辑分层中的每一层应该有那些模块。
图9.保温系统的分层架构图
7.2 物理视图
图10.保温系统的物理架构图
问题D.电梯问题
（一）案例背景
在M层的建筑物内安装N个电梯。电梯问题是指这些电梯的逻辑控制问题:
（1）每个电梯有一些按钮，每个按钮对应一个楼层。当按下按钮后，按钮灯亮，并指出电梯开往相应的楼层。当电梯到达该楼层后，按钮灯熄灭。
（2）除底层和顶层只有一个按钮外，每个楼层有两个按钮，分别指示上楼和下楼请求。当按下按钮后，按钮灯亮。如果电梯已到达该楼层，或者电梯正沿所着请求的方向运动，或者遇到有冲突的请求时，按钮灯灭。在遇到有冲突请求的情况下，如果两楼层同时发出请求，则只能取消其中一个请求。决定服务优先次序的算法应尽量减少两个请求的等待时间。
（3）当没有服务请求时，电梯保持在最后一个目的楼层，电梯门关闭。
（4）系统以事件驱动方式响应楼层对电梯的请求。所有楼层的优先级是相同的。
（5）系统以事件驱动方式响应电梯内部对到达楼层的要求，并按照电梯运动方向依次完成这些要求。
（6）每个电梯都有一个紧急按钮，按下后向管理人员发出报警信号，然后电梯被置为"不可用"状态。
每个电梯都有取消“不可用”状态的机制。
（二）架构设计
- 划分子系统
图11.电梯系统的子系统图
根据以上对电梯控制系统的各视图的分析，现在将此系统划分一下子系统。考虑到电梯控制的分布、实时和并发特性，以及上述分析中得出的系统运行流程大致是乘客发出请求，请求进入控制器，控制器完成业务功能并返回状态，因此，可以将电梯系统划分为请、运行控制、状态三个子系统，这三个子系统对应着三个并发的进程，彼此之间相互独立工作但又相互联系。
（1）请求子系统
问题域：请求子系统接受来自楼层或电梯内的请求，同时支持多个请求，按队列请求的优先级去完成，接受请求后亮灯，完成请求后熄灯。
交互：与运行控制子系统进行交互，向运行控制发送请求信息；与状态子系统交互，当获得或完成请求时，电梯按钮的灯的状态。
数据：按优先级排序的请求队列，当完成请求时，删除相应的请求。
（2）运行控制子系统
问题域：接受请求子系统发送的请求信息并向电梯发送相应指令，控制电梯的运行方向。接受控制室的编辑与修改当前的调度计划和策略。
交互：与请求子系统进行交互，接受其发送的请求信息，并按照相应的调度计划控制电梯的运行方向。与状态子系统交互，运行控制电梯的运行方向，并显示相应的状态信息。
数据：记录请求和状态、调度计划和策略。
（3）状态子系统
问题域：状态子系统接受电梯的运行状态信息并显示相应的运行方向和到达楼层信息。
交互：与运行控制进行交互，接受电梯的运行方向信息和到达楼层指令并显示出相应的信息，通知请求队列删除已完成的请求。
数据：电梯运行状态
- 逻辑视图
分析需求可得出电梯系统的顺序图如下。
图12.电梯系统的顺序图
- 用例视图
图13.电梯系统的用例图
- 运行视图
图14.电梯系统的运行架构图
- 开发视图
深入了解会发现其实传感器、按钮等设备都属于电梯控制系统的输入或输出源，可以将它们看作电梯控制系统的外部设备，而按钮是发送请求的根源，此时请求将会进入请求队列，因此，在开发视图中应该要考虑到使用消息队列。而控制器是整个系统的中心点，所有的输入信号都将进入控制器去完成一系列的业务操作，最后返回电梯的各种状态，开发架构图如下。
图15.电梯系统的开发架构图
- 分层架构与物理视图（迭代1）
6.1 分层架构
通过划分子系统的过程，可以发现除了包含相应状态的表现层、业务逻辑层和数据访问层外，还包含了子系统之间的交互层，根据主要的结论画出了分层的逻辑架构图，如图4。
图16.电梯系统的分层架构图
6.2 物理视图
电梯的所有控制逻辑都集中在PLC控制器里，其他外部信息或设备都属于控制器的延申，而控制室的机器则为PLC控制器制定相应的规则和策略。根据以上分析，还可以得出电梯系统的物理架构图，如图5。
图17.电梯系统的物理架构图
- 分层架构物理视图（迭代2）
7.1 分层架构
有了初步的逻辑分层后，现在再继续深入考虑逻辑分层中的每一层应该有那些模块。
图18.电梯系统的分层架构图
7.2 物理视图
图19.电梯系统的物理架构图
四、遇到的问题与实验心得
通过对保温系统与电梯系统进行架构分析与设计，让我更加深入了解了如何从5个视图去分析与设计，每一个视图应该关注什么，二不需要关注什么，如物理架构则关注系统的安装和部署需求，并学会如何使用UML将架构进行可视化。另外，让我对架构有了更深的了解，架构相当于软件系统的骨架和结构，架构的关注点是系统的整个框架而不是代码的实现，包括组件、模块和技术等方面。
标签：架构设计,控制器,系统,视图,架构图,电梯,保温,子系统 From： https://www.cnblogs.com/lxpblogs/p/16602772.html