软件工程中的组件设计与组合：原理、挑战与应对策略

# 软件工程中的组件设计与组合：原理、挑战与应对策略 ## 1. 问题导向组件示例 在一个控制道路单向交通的小型系统中，道路维修路段两端设有交通灯，路面边界的传感器管可检测车辆通过，控制计算机连接灯组和传感器，并配备小键盘和简单字符显示器，供现场管理员不时指定交通阶段时长，以适应不同方向的交通密度，减少道路使用者的不便。 ### 1.1 系统需求与约束 系统要求交通控制器根据管理员最新的相位规范约束车辆，实现便捷安全的交通。车辆的约束基于驾驶员遵守信号灯的假设，而管理员的输入不可被约束，机器可拒绝或忽略不适当的键盘输入。连接问题域和机器的实线代表共享现象的接口。 ### 1.2 正常设计探索 开发者为降低开发风险，应寻找适用于整个系统的既定正常设计原则，虽不一定能找到直接可用的现成解决方案，但可识别此类系统的专业设计知识。若没有整体的既定正常设计，可通过识别一些正常设计组件并将其组合在一个全新的结构中来减轻全新设计的难度。 ### 1.3 候选组件分析 为便于讨论组件的性质，我们选取两个明显的候选组件： - **处理管理员相位规范输入的组件**：该输入过程需与根据先前完成的规范控制灯光的过程解耦，这通常需要引入数据结构。图 3 展示了支持相位规范编辑的子问题图，其中相位问题域是交通控制器机器的一部分，是一个词汇域，需开发者设计。 - **收集和解释传感器信息的组件**：该组件使交通控制器能检测车辆是否进入控制路段且未离开，从而判断反向通行是否安全。此功能也可与根据管理员指定的相位和车辆位置控制交通的功能解耦，解耦机制同样是词汇域。图 4 展示了构建车辆模型的子问题图，VModel 域作为车辆域的替代模型，其状态需与车辆域的状态对应，该模型也需开发者设计。 ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(Manager):::process -->|Input| B(Phasing Editor):::process B -->|Edit| C(Phasing):::process D(Vehicles):::process -->|Sensor Data| E(Vehicle Modeller):::process E -->|Model| F(VModel):::process C -->|Specification| G(Traffic Controller):::process F -->|Vehicle State| G G -->|Control| H(Lights):::process ``` ## 2. 正常设计的内容 编辑相位规范和构建车辆模型这两个子问题是系统组件的明显候选者，它们代表了系统功能的“自然”组件，比整个系统更简单，且属于软件密集型系统中常见的可识别问题类型。 ### 2.1 组件的相似与差异 从抽象层面看，这两个子问题具有相同结构，都有需机器创建或维护的词汇域、作为变化源的自主域、连接自主域和机器的部分，以及词汇域和自主域之间需满足的特定关系。但这种抽象和同化仅适用于工程分支的早期阶段，正常设计的核心在于细化、掌握和利用设备类、期望功能和问题世界的特定性。 ### 2.2 组件的正向需求差异 两个组件的正向需求本质不同： - **编辑组件**：目的是为人类提供工具，支持管理员捕获和表达交通相位的预期模式，结果需符合语法和语义约束，准确反映管理员意图。例如，可利用显示器支持交互式问答输入。 - **模型构建组件**：目的是维持车辆自主域和设计模型域之间的指定对应关系，模型需不断更新以反映车辆域的变化状态，此组件无类似编辑组件的交互式输入方式。 | 组件类型 | 正向需求 | 示例操作 | | ---- | ---- | ---- | | 编辑组件 | 提供人类使用工具，准确反映管理员意图 | 利用显示器支持交互式输入 | | 模型构建组件 | 维持车辆域和模型域对应关系，更新模型反映车辆状态 | 无类似交互式输入方式 | ## 3. 组件设计中的失败情况 ### 3.1 编辑组件的负向需求 编辑组件的设计需避免编辑活动的易用性和便利性方面的失败，这涉及人机交互领域。例如，早期航空工程中对飞机“飞行质量”的研究，识别并量化了决定飞行质量的关键特征。在编辑程序设计中，也需关注人类因素，避免误导用户，如 Therac - 25 放射治疗系统因软件设计问题导致操作员误解参数值，造成患者伤亡。 ### 3.2 模型构建组件的负向需求 模型构建组件的主要负向需求是避免无法充分满足正向需求，即降低 VModel 无法反映车辆及其位置现实情况的系统状态概率。由于实际车辆形状、大小和轴数多样，传感器激活原因复杂，车辆导致的传感器状态变化模式难以预测，因此需要在解释传感器变化时保证足够的可靠性，并了解其可靠性的局限性。 ### 3.3 软件分析模型的挑战 软件中分析模型的不足更易导致系统故障，因为程序机器的行为由应用软件决定，若分析模型不充分，机器无法弥补。而在物理结构设计中，可通过应用安全系数来补偿分析模型的不足。因此，采用足够好的分析模型以避免系统故障是正常设计的重要部分。 ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(Editing Component):::process -->|Avoid Ease & Convenience Failures| B(Human - Computer Interaction):::process A -->|Avoid Misleading User| C(Therac - 25 Example):::process D(Model - Building Component):::process -->|Avoid Failure to Reflect Reality| E(Reliability of Sensor Interpretation):::process D -->|Understand Reliability Limits| F(Design of Model Use):::process E -->|Adequate Analytical Model| G(Normal Design):::process F -->|Adequate Analytical Model| G ``` ## 4. 软件工程中的组合问题 在软件开发中，复杂性通常通过关注点分离来管理，但分离的关注点最终需要组合在一起形成完整的系统，这本身就是一个重大的设计挑战。 ### 4.1 组件连接与数据访问 以交通控制器为例，控制灯光的部分需要访问 VModel 域中捕获的车辆状态信息以及管理员指定的相位信息。访问共享数据结构是一种常见的组合方式，需要使用标准的软件机制来保证读写操作在适当的粒度上互斥，这是正常设计实践的一部分。 ### 4.2 相位信息的组合问题 将相位信息提供给交通控制器是一个更复杂的组合问题。使用单一共享数据结构即使有互斥访问也可能不令人满意，因为控制器在更改灯光设置时必须参考一个完全连贯的相位规范。互斥的最细粒度应该是一个完整的相位规范，编辑过程需要在与当前用于控制的实例不同的实例上操作。这就引出了一系列设计问题，如如何以及何时进行切换，需要多少个实例等。 ### 4.3 切换关注点 从一个相位实例切换到另一个相位实例的设计涉及到组合设计中的切换关注点。在交通控制问题中，交通灯的控制必须从一个指定的相位切换到另一个，设计时需要确保两个相位的连接不会违反某些全局要求，如一个方向允许通行后需要有足够时间清空路段，以及两个方向的交通流必须交替等。在金融系统中，将客户从正常规则转移到违约规则也是一个切换关注点。 | 组合问题 | 具体情况 | 设计挑战 | | ---- | ---- | ---- | | 数据访问 | 访问 VModel 域和相位信息 | 保证读写互斥 | | 相位信息组合 | 提供相位信息给控制器 | 确保连贯规范，确定切换方式和实例数量 | | 切换关注点 | 交通灯相位切换、金融系统客户规则转移 | 避免违反全局要求 | ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(Traffic Controller):::process -->|Access| B(VModel):::process A -->|Access| C(Phasing):::process D(Editing Process):::process -->|Edit| E(Phasing Instance 1):::process F(Control Process):::process -->|Use| G(Phasing Instance 2):::process E -->|Switch| G H(Global Requirements):::process -->|Constraint| G ``` ## 5. 为故障设计 在组合设计中，需要考虑组件可能的故障情况，并且要确保更关键组件的功能不会因不太关键组件的故障而受到影响。 ### 5.1 组件故障的影响 以质子治疗机的控制系统为例，该系统有多个组件，如设置剂量、轮廓和方向，控制质子束，移动患者支撑床，旋转机架，维护命令审计跟踪，响应紧急按钮等。这些组件的相对重要性需要仔细考虑，并且在实现设计中应是一个主要的决定因素。 ### 5.2 故障应对策略 在设计时，要根据组件的相对重要性来安排数据流和交互方式，以确保系统在组件故障时仍能保持一定的功能或安全状态。例如，在软件设计中，可以通过合理的数据流向和交互逻辑来减少故障的影响范围。 ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(Operator):::process -->|Input| B(Beam Control):::process A -->|Input| C(Gantry Rotation):::process A -->|Input| D(Dosage Setting):::process B -->|Control| E(Proton Beam):::process C -->|Position| F(Gantry):::process D -->|Set| G(Dosage):::process H(Emergency Button):::process -->|Stop| E I(Equipment Log):::process -->|Record| J(Commands):::process B -->|Log| J C -->|Log| J D -->|Log| J ``` ## 6. 总结 软件工程中的组件设计、组合以及故障应对是复杂且相互关联的过程。通过识别合适的组件、理解其正向和负向需求、解决组合问题以及为故障设计，可以提高软件系统的可靠性和可维护性。在实际应用中，开发者需要综合考虑各种因素，运用正常设计原则和方法，以应对不同的挑战。同时，要不断关注新技术和新方法的发展，以提升软件设计的质量和效率。 在组件设计方面，要注重组件的功能独立性和可复用性，同时考虑其与其他组件的交互和组合。在组合设计中，要解决好数据访问、信息一致性和切换等问题，确保系统的整体性能和稳定性。在故障应对方面，要根据组件的相对重要性进行合理设计，减少故障对系统的影响。通过这些策略的综合应用，可以构建出更加健壮和可靠的软件系统。