7.3 可修改性设计检查表

表7.2是支持可修改性设计和分析过程的清单。

表7.2 支持可修改性设计和分析过程的清单

分类	检查表
职责分配	通过考虑技术，法律，社会，业务和客户方面的变化来确定可能发生哪些变化或变化的类别。 对于每个潜在的更改或更改类别： 确定进行更改需要添加，修改或删除的职责。 确定更改会影响哪些职责。< br> 确定对模块的职责分配，这些模块将将要更改（或受更改影响）的职责尽可能地放置在同一模块中，并将要在不同时间更改的职责分别放置 模块。
协调模型	确定哪些功能或质量属性可以在运行时更改，以及这如何影响协调； 例如，正在传达的信息会在运行时更改，还是会在运行时更改通讯协议？ 如果是这样，请确保此类更改影响少量模块。 确定用于协调的设备，协议和通信路径可能会更改。 对于那些设备，协议和通信路径，请确保将更改的影响限制在一小部分模块中。 对于那些涉及可修改性的元素，请使用减少耦合的协调模型，例如发布，订阅， 延迟诸如企业服务总线之类的绑定，或限制诸如广播之类的依赖性。
数据模型	确定可能发生数据抽象，其操作或其属性的哪些更改（或更改类别）。还确定对这些数据抽象的哪些更改或更改类别将涉及它们的创建，初始化，持久性，操作，转换或破坏。 对于每个更改或更改类别，确定更改是否由最终用户进行，系统管理员或开发人员。对于最终用户或系统管理员要进行的那些更改，请确保该用户可以看到必要的属性，并确保该用户具有修改数据，其操作或其属性的正确特权。 对于每种可能更改或更改类别： 确定需要添加，修改或删除哪些数据抽象以进行更改。 确定创建，初始化，这些数据抽象的持久性，操纵，转换或破坏。 确定哪些其他数据抽象会受到更改的影响。对于这些其他数据抽象，请确定是否会对操作，它们的属性，它们的创建，初始化，持久性，操纵，转换或破坏产生影响。 设计数据模型，以使分配给数据模型每个元素的项目可能一起改变。
架构元素之间的映射	确定是否需要在运行时，编译时，设计时或构建时更改将功能映射到计算元素（例如，进程，线程，处理器）的方式。 确定为适应需要而进行的修改的程度 功能或质量属性的添加，删除或修改。 这可能涉及确定以下内容，例如： 执行依赖项 将数据分配给atabases 将运行时元素分配给进程，线程或处理器 确保使用利用映射决策的延迟绑定的机制执行此类更改。
资源管理	确定责任或质量属性的添加，删除或修改将如何影响资源使用。 例如，这涉及： 确定哪些更改可能会引入新资源或删除旧资源或影响现有资源使用情况 确定哪些资源限制将发生变化，以及如何确保资源在更改后 修改足以满足系统要求。 封装所有资源管理器，并确保将由那些资源管理器实施的策略本身进行封装，并尽可能地推迟绑定。
绑定时间	对于每个更改或更改类别： 确定需要进行更改的最晚时间。 选择延迟绑定机制（请参见7.2节），以提供适当的功能 确定引入该机制的成本和使用选定机制进行更改的成本。 使用第118页上的方程式评估您对机制的选择。 不要引入太多的绑定选择，因为选择之间的依赖关系是复杂且未知的，因此更改受到阻碍。
技术选择	确定根据您的技术选择使修改变得更容易或更难。 您的技术选择将有助于进行，测试和部署修改吗？ 修改技术选择有多容易（ 如果其中某些技术发生更改或变得过时）？ 选择您的技术以支持最可能的修改。 例如，企业服务总线可以更轻松地更改元素的连接方式，但可能会导致供应商锁定。