【软件系统架构设计师-案例-1】架构风格

1. 请用200字以内说明系统可靠性的定义及包含的4个子特性，并简要指出提高系统可靠性一般采用哪些技术？

（1）可靠性定义：系统在规定的时间或环境条件下，完成规定功能的能力，就是系统无故障运行的概率。
（2）包含的4个子特性：成熟性、容错性、易恢复性、可靠性。
（3）提高可靠性的4类技术：冗余技术、软件容错技术、双机容错技术、集群技术。

2. 围绕“软件架构风格”，简要说明你参与的系统开发工作。

（1）在企业家电商平台项目中，我采用了分层架构的架构风格，将软件系统分为不同的层次，每个层次都有明确的职责和功能，层与层之间通过接口通信。这个架构风格有助于提高软件的可维护性、可拓展性和可测试性。
（2）表示层：负责与用户做交互，展示商品信息、订单状态等。接受用户的输入，如点击、添加、提交等操作，并将这些操作传递给业务逻辑层。我们使用了前端技术框架。React.js来提供流畅的用户界面和交互。
业务逻辑层：处理核心的业务逻辑，如商品管理、订单处理、用户授权等，是整个系统的核心，负责协调各个模块之间的关系，确保业务规则的正确执行。
数据访问层：负责与数据库做交互，执行数据的存储、查询、更新等操作。将业务逻辑层的请求转化为对数据库的操作，如SQL查询语句，然后从数据库获取的数据返回给业务逻辑层。我们使用了数据库抽象层框架，如MyBatis，可以根据不同的数据库类型生成相应的SQL语句。
（3）主要做的工作内容，做架构风格的选型分析，收集和整理项目资料，技术选型，设计模式的选取。根据需求文档，设计和实现业务逻辑层的关键模块，比如订单处理模块的开发，编写单元测试框架对业务代码进行测试。参与定义表示层到业务逻辑层、业务逻辑层到数据访问层之间的接口，明确各个接口的输入输出参数、功能职责，确保层与层之间的通信清晰、高效。对层间接口进行优化，当新的业务功能需要在多个层次之间传递更多信息时，我们及时调整接口的参数结构，确保接口的稳定性，尽量减少对其他层代码的影响。

3. 质量属性

（1）性能：
例1：在正常负载情况下，系统应在0.3秒内对用户的界面操作请求进行响应。
例2：在正常负载情况下，用户支付商品费用后在3秒内确认订单支付信息。
例3：在查询过程中，涉及到车辆实时视频传输必须保证20帧/秒的速率，且画面有660x480的分辨率。
例4：系统应支持大于100个工业设备的进行检测。
（2）安全性：
例1：用户的信用卡支付必须保证99.999%的安全性。
例2：用户信息数据库授权必须保证99.999%的可用性。
例3：用户停滞时间超过时限需要验证。
（3）可用性：
例1：系统应该7X24小时工作。
例2：能够运行的时间不少于360小时，意外退出后能够在10S内自动重启。
（4）可修改性
例1：修改接口，需要3人/天完成。
例2：集成开发环境拥有丰富的插件库。
例3：支持用户通过配置界面根据自己的喜好修改界面风格，配置后无需修改环境。
（5）易用性（讨论是客户的习惯问题）
例1：系统进行文件保存操作时，应该与window系统的操作方式保持一致。
（6）可测试性
例1：系统应该提供一个开放的API接口，支持远程对系统的行为进行控制和调试。
例2：集成开发环境具有模块化结构，支持以模块为单位进行调试、测试和发布。
（7）可靠性
例1：系统具有故障自行诊断和快速恢复能力。
例2：系统能识别供应商异常的报价并防止干扰评选。
（8）互操作性
例1：用户界面支持用户的个性化定制。
例2：系统需要支持当前的主流的标准和服务，特别是通信协议和平台接口。

4. 从集成开发环境与用户的交互方式、集成开发环境的拓展性、集成开发环境的数据管理三个方面说明为什么选择数据存储风格而不使用管道过滤器风格？

（1）采用以数据存储的风格很好地支持交互式数据处理，而管道过滤器则对用户的交互式数据支持有限。
（2）以数据存储的风格以数据格式解耦各个功能之间的依赖关系，可以灵活定义功能之间的逻辑顺序，扩展性好，而管道过滤器灵活定义方面较差。
（3）数据管理方面，中心存储器能表示多种数据格式，并能够提供各种支持，管道过滤器只能支持有限的数据格式。

（1）语法结构树
（2）编辑器
（3）适配器
（4）应用模拟器工具

5. 面向对象风格与虚拟机风格：

可修改性：面向对象风格通过编写新的规则代码，通过应用重启或热加载添加规则，可修改性差；解释器风格通过编写新的规则文件，通过导入资源文件或外部配置添加规则，可修改性好。
灵活性：面向对象风格通过策略模式定义规则对象，规则以程序逻辑实现，灵活性较差；解释器可灵活定义规则计算表达式，灵活性更好。
性能：面向对象风格以编译后代码运算规则，性能好；而虚拟机风格需要加载规则、解析规则、规则运算，再得出结果，性能较差。
面向对象风格：效率高质量高易维护，可扩展性与性能较好，可修改性与灵活性较差。
解释器风格（虚拟机风格）：可修改性高，个性化和灵活性强，性能较差。
【面向对象设计模式中的策略模式和虚拟机中的基于规则的架构风格是动态规则场景中两种常用的解决方案，基于规则的虚拟机风格在灵活性和可扩展性两个方面均具备较大优势，而从性能方面会比面向对象处理速度差一些】

6. 管道-过滤器、隐式调用、解释器风格三种架构风格在灵活性和可扩展性的分析与对比：

管道过滤器风格：每个构件都有一组输入输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。管道是连接件，过滤器是构件。
隐式调用风格：构件不直接调用一个过程，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。
解释器风格：构建一个运行环境，在这个环境上，能解析和运行定义的一些语言增加架构的灵活性。适用于“自定义规则的场合”。

灵活性：管道-过滤器架构风格具有良好的灵活性。通过将系统分解为一系列独立的过滤器组件，可以灵活地组合和配置这些组件以满足不同的需求。解释器风格可以通过灵活的自定义规则来实现规则的重组，灵活性强。隐式调用架构风格相对较为简单，灵活性较低。在这种架构中，系统的组件之间通过隐式的调用来实现通信和协作。这种紧耦合的方式限制了组件之间的独立性和灵活性。
可扩展性：管道-过滤器架构风格具有较好的可扩展性。由于过滤器之间通过管道进行松耦合的通信，可以方便地添加、删除或替换过滤器组件，以实现系统的功能扩展。解释器架构风格的可扩展性相对较强。由于解释器本身可以解释和执行各种语言或规则，因此可以通过添加新的解释器来扩展系统的功能。隐式调用架构风格的可扩展性较差。由于组件之间的紧耦合和依赖关系，添加新的组件或修改现有的组件可能会导致较大的影响范围和修改工作量。这会增加系统的复杂性，并降低可扩展性。

7. 集成开发环境需要一组可视化的编程界面，用户通过对界面元素的拖拽和代码填充的方式就可以完成功能插件核心业务流程。用什么架构风格？

应该采用解释器架构风格。首先需要，1.为可视化编程元素以及其拖拽关系定义某种语言，并描述其语法和语义。2. 编写解释器对该语言解释。 3. 生成对应的脚本语言程序。

8. 集成开发环境需要实现在脚本语言编辑界面中的代码自动定位功能，编辑界面需要响应调试断点命中事件，并自动跳转到当前断点处对应的代码。用什么架构风格？

应采用事件驱动（隐式调用）架构风格，首先需要定义“断点在调试过程中命中”这一事件，并实现当断点命中后的屏幕定位函数。集成开发环境维护事件注册表结构，将该事件与屏幕定位函数关联起来形成注册表的记录项。在调试过程中，集成开发环境负责监听各种事件，当“断点在调试过程中命中”这一事件发生时，集成开发环境查找事件注册表，找到并调用屏幕定位函数，从而实现脚本语言编辑界面与调式代码的自动定位。