架构师训练营第一周作业

1. 用例图

管理员：管理中心工作人员，此处为简化问题，不区分系统管理员和充值窗口服务员角色

服务员：餐厅档口员工，负责点餐和收费。

客户：由于客户不直接操作系统，因此不是系统相关角色

2. 部署图

系统分三地进行部署

数据中心：

数据中心服务器：由于目前用户规模，安全性，可用性等非功能约束尚不明确，暂时假定由一台服务器进行服务。待约束明确，再对部署关系进行细化。

食堂：

刷卡机：由会员卡服务商提供，假设为安卓系统，可安装第三方应用。

管理中心：

PC：普通台式机电脑即可，需安装打印机驱动和就餐卡读卡器驱动

读卡器：由会员卡服务商提供，用于读取卡片信息和写入持有人信息与卡片金额

3. 组件图

3.1 API 服务组件图

main：服务启动入口

web framework：任意现代 web 框架，一般包括 MVC，Request 解析，Response 发送，ActiveRecord，cache，logger，config 解析等常用功能的封装

HTTP 服务：监听 HTTP 端口，Request 解析，Response 发送。由 web framework 提供支持

控制器：通过框架的路由分发机制，处理对应的 http 请求。随业务迭代而扩展

service：承载高内聚低耦合的业务逻辑。随业务迭代而扩展

model：对单张数据库表的 CRUD 操作。随业务迭代而扩展

3.2 管理中心 PC 端

由于本人没有做过窗体应用开发的经验，所以这里假设编程模型为 MVVM

main：服务启动入口

窗体控制器：根据用户操作，展示合适的应用窗体视图

view：视图层，依赖系统控件，负责展示业务数据和控件。随业务迭代而扩展

view model：用于响应控件事件。随业务迭代而扩展

api manager：封装远程接口调用的代码。随业务迭代而扩展

PDF 库：在打印报表功能中调用

3.3 食堂刷卡机

main：服务启动入口

主控制器：由于该程序功能单一，只负责划卡消费，因此不考虑业务扩展性，此组件直接承载业务逻辑。

Event Manager: 读取键盘和读卡器的输入，生成对应事件，交由主控制器处理

4. 时序图

4.1 API Server 相应接口调用调用时序图

本图为 api server 处理请求的一般过程，后文中使用此图的简化逻辑

4.2 服务中心-客户充值时序图

4.3 服务中心-打印统计数据时序图

4.4 食堂-客户消费时序图

由于客户消费流程较长，涉及组件较多，所以分 4 个子过程展示

4.4.1 读取并展示卡片信息

4.4.2 输入消费金额

4.4.3 确认支付(1)

4.4.4 确认支付(2)