Application Architecture Guide 2.0 (Chapter 7: Quality Attributes) Part 3

协作性

协作性是指一个系统的各个组件间或者不用系统间的成功交换信息的能力。一个协作性好的系统应该能很容易的与其内部或者外部进行信息的交互和复用。通信协议、接口、数据格式以及标准化的设计是决定系统协作性的关键因素。

关键问题

l 外部系统或遗留系统使用了不同的数据格式。

l 边界模糊,允许工件从逻辑层、物理层或系统迁移到其他层或系统中。

关键决策

l 如何处理外部系统或遗留系统数据格式不一致的问题。

l 被分离或替代后的系统如何保证协作性。

l 如何通过使用服务接口分离出系统。

l 如何通过使用映射层分离出系统。

关键技术

l 使用适配器连接外部系统或遗留系统,在系统间进行数据转换。

l 使用一个规范的数据模型来处理大量不同的数据格式。

l 基于XML或标准数据类型暴露服务接口,以支持与其他系统的协作性。

l 设计高内聚,松耦合的组件,最大程度提升系统的灵活性、可替换性、重用性。

可维护性

可维护性是指维护人员为修正软件系统出现的错误或者缺陷,以及为满足新的要求而添加、修改和完善软件系统功能的难易程度。提高可维护性是决定软件工程方法论所有步骤的关键目标,可以通过恢复故障或完成升级的时间来进行衡量。提高系统的可维护性,将提高系统的运行效率,降低运行时的缺陷。

关键问题

l 组件之间或层之间存在的过度依赖阻碍了系统的替换、升级与修改。

l 使用直接通讯方式,阻碍了组件或层的物理部署方式的变更。

l 使用了自定义的功能(如身份验证或授权),妨碍了系统的重用与维护。

l 混合了横切关注点的实现与特定应用组件的界限,使得系统维护与重用非常困难。

l 组件内聚性不高,导致了组件难于被替换,形成对子组件不必要的依赖。

关键决策

l 如何减少组件之间、层之间的依赖关系。

l 如何实现一个可插拔的架构,允许系统简单升级与维护并提升系统的测试能力。

l 如何将横切关注点与功能组件分离开来。

l 如何选择一个合适的通讯模型、格式与协议。

l 如何创建一个高内聚的组件。

关键技术

l 设计明确界定层或关注领域的系统,清楚的划分系统的UI、业务流程与数据访问功能。

l 设计高内聚、低耦合的模块,确保系统的灵活性、可替换性、重用性最大化。

l 设计允许插拔模块或适配器的接口,最大程度提升系统的灵活性、可扩展性。

l 提供良好的架构文档,说明应用系统的结构。

可管理性

通过为监控系统或缺陷性能调试暴露接口或基础设施,使得你的应用系统易于管理。

关键问题

l 缺乏诊断信息;

l 缺乏故障排除工具;

l 缺乏性能和规模的度量;

l 缺乏追踪能力;

l 缺乏健康监测。

关键决策

l 如何使系统具备根据来源于操作环境需求情况(如基础设施或部署方式)变化的特性;

l 如何使系统具有根据运行时系统负载情况变化的特性。例如,在系统可用时使用请求队列进行处理;

l 如何创建一个用于故障排除的系统状态快照;

l 如何监视系统的运作和健康问题;

l 如何创建自定义的监测工具并提供详细的工作报告;

l 如何获取发送到这个系统的请求的详细信息。

关键技术

l 考虑创建一个健康的模式,在模式中定义所有能够影响应用性能的变更状态,并利用这一模式来确定具体的管理监测需求;

l 实现监测功能,如事件与性能计数器,用来监测系统状态变化,并将这些变化通过标准的系统工具(如事件日志、追踪文件、WMI)记录下来;

l 捕获并报告有关错误和状态的变化的信息,以便准确监测,调试和管理;

l 考虑创建管理工具,管理员可以使用它们的监测环境管理应用程序;

l 考虑监控您的应用程序的健康状况或具体功能点,便于出现故障后的调试;

l 考虑记录和审计那些可用于维护与调试的信息,如请求的细节、模块的输出或调用其他系统和服务等细节。

原文地址:https://www.cnblogs.com/xinyan/p/1657113.html