架构技术


迭代和增量方法

它是一种迭代和增量方法,由五个主要步骤组成,有助于生成候选解决方案。可以通过重复这些步骤进一步完善该候选解决方案,并最终创建最适合我们应用程序的架构设计。在该过程结束时,我们可以审查我们的架构并将其传达给所有感兴趣的各方。

这只是一种可能的方法。还有许多其他更正式的方法可以定义、审查和传达您的架构。

确定架构目标

确定形成架构和设计流程的架构目标。完美且明确的目标强调架构,解决设计中的正确问题,并有助于确定当前阶段何时完成,并准备好进入下一阶段。

此步骤包括以下活动 -

  • 从一开始就确定您的架构目标。
  • 确定我们架构的消费者。
  • 确定限制因素。

架构活动的示例包括构建原型以获取有关 Web 应用程序的订单处理 UI 的反馈、构建客户订单跟踪应用程序以及为应用程序设计身份验证和授权架构以执行安全审查。

关键场景

此步骤强调最重要的设计。场景是对用户与系统交互的广泛且全面的描述。

关键场景是那些被认为对应用程序成功最重要的场景。它有助于做出有关架构的决策。目标是在用户、业务和系统目标之间实现平衡。例如,用户身份验证是一个关键场景,因为它们是质量属性(安全性)与重要功能(用户如何登录系统)的交集。

应用概述

构建应用程序的概述,这使得架构更易于触摸,将其与现实世界的约束和决策联系起来。它包括以下活动 -

确定应用程序类型

确定应用程序类型,无论是移动应用程序、富客户端、富互联网应用程序、服务、Web 应用程序还是这些类型的某种组合。

确定部署限制

选择适当的部署拓扑并解决应用程序和目标基础架构之间的冲突。

确定重要的架构设计风格

识别重要的架构设计风格,例如客户端/服务器、分层、消息总线、域驱动设计等,以改进分区并通过为经常出现的问题提供解决方案来促进设计重用。应用程序通常会使用多种样式的组合。

确定相关技术

通过考虑我们正在开发的应用程序类型、我们对应用程序部署拓扑和架构风格的首选选项来确定相关技术。技术的选择也将受到组织政策、基础设施限制、资源技能等的指导。

关键问题或关键热点

在设计应用程序时,热点是最常犯错误的区域。根据质量属性和横切关注点确定关键问题。潜在问题包括新技术的出现和关键业务需求。

质量属性是影响运行时Behave、系统设计和用户体验的体系结构的整体特征。横切关注点是我们设计的特征,可以应用于所有层、组件和层。

这些也是最常犯高影响设计错误的领域。横切关注点的示例包括身份验证和授权、通信、配置管理、异常管理和验证等。

候选解决方案

定义关键热点后,构建初始基线架构或第一个高层设计,然后开始填写细节以生成候选架构。

候选架构包括应用程序类型、部署架构、架构风格、技术选择、质量属性和横切关注点。如果候选架构是一种改进,那么它可以成为创建和测试新候选架构的基线。

在迭代地遵循周期并改进设计之前,根据已定义的关键场景和要求验证候选解决方案设计。

我们可以使用架构尖峰来发现设计的特定领域或验证新概念。架构尖峰是一种设计原型,它确定特定设计路径的可行性、降低风险并快速确定不同方法的可行性。针对关键场景和热点测试架构峰值。

架构回顾

为了减少错误成本并尽早发现和修复架构问题,架构审查是最重要的任务。这是一种行之有效的、具有成本效益的降低项目成本和项目失败机会的方法。

  • 在主要项目里程碑时经常审查架构,并响应其他重大架构变更。

  • 架构审查的主要目标是确定基线和候选架构的可行性,从而正确验证架构。

  • 将功能要求和质量属性与提议的技术解决方案联系起来。它还有助于发现问题并识别需要改进的领域

基于场景的评估是审查架构设计的主要方法,它侧重于从业务角度来看最重要的场景,并且对架构影响最大。以下是常见的审查方法 -

软件架构分析方法(SAAM)

它最初是为评估可修改性而设计的,但后来被扩展用于审查架构的质量属性。

架构权衡分析方法(ATAM)

它是 SAAM 的完善和改进版本,它根据质量属性要求以及它们满足特定质量目标的程度来审查架构决策。

主动设计审查(ADR)

它最适合不完整或正在进行的架构,这些架构一次更关注一组问题或架构的各个部分,而不是执行一般性审查。

中间设计的积极审查(ARID)

它结合了审查正在进行的架构的 ADR 方面,重点关注一组问题,以及基于场景的审查的 ATAM 和 SAAM 方法,重点关注质量属性。

成本效益分析法(CBAM)

它侧重于分析架构决策的成本、收益和进度影响。

架构级可修改性分析 (ALMA)

它评估了商业信息系统(BIS)架构的可修改性。

家庭架构评估方法(FAAM)

它评估信息系统家族架构的互操作性和可扩展性。

沟通架构设计

完成架构设计后,我们必须将设计传达给其他利益相关者,包括开发团队、系统管理员、运营商、企业主和其他利益相关方。

有以下几种众所周知的方法可以向他人描述架构: -

4+1模式

此方法使用完整架构的五个视图。其中,四个视图(逻辑视图、过程视图、物理视图开发视图)从不同的角度描述了体系结构。第五个视图显示了软件的场景和用例。它允许利益相关者看到他们特别感兴趣的架构的功能。

架构描述语言 (ADL)

这种方法用于在系统实现之前描述软件架构。它解决了以下问题:Behave、协议和连接器。

ADL 的主要优点是我们可以在正式开始使用设计之前分析架构的完整性、一致性、模糊性和性能。

敏捷建模

这种方法遵循“内容比表现更重要”的概念。它确保创建的模型简单易懂、足够准确、详细且一致。

敏捷模型文档针对特定客户并完成该客户的工作努力。文档的简单性确保利益相关者积极参与工件的建模。

IEEE 1471

IEEE 1471 是正式名称为 ANSI/IEEE 1471-2000(“软件密集型系统架构描述的推荐实践”)标准的简称。IEEE 1471 增强了架构描述的内容,特别是为上下文、视图和观点赋予了特定含义。

统一建模语言 (UML)

这种方法代表了系统模型的三个视图。功能需求视图(从用户角度看系统的功能需求,包括用例);静态结构视图(对象、属性、关系和操作,包括类图);动态Behave视图(对象之间的协作以及对象内部状态的更改,包括序列图、活动图和状态图)。