为应用的体系结构建模

为了帮助确保软件系统或应用程序满足用户的需求,可以在 Visual Studio 中创建模型,作为软件系统或应用程序整体结构和行为的一部分。 使用模型,还可以描述在整个设计中使用的模式。 这些模型可帮助你了解现有体系结构、讨论更改并明确传达意图。

若要查看 Visual Studio 哪些版本支持此功能,请参阅 版本对体系结构和建模工具的支持

模型的目的是减少自然语言描述中出现的歧义,并帮助你和同事可视化设计并讨论替代设计。 模型应与其他文档或讨论一起使用。 本身,模型并不表示体系结构的完整规范。

注释

在整个主题中,“系统”是指正在开发的软件。 它可能是许多软件和硬件组件、单个应用程序或应用程序的一部分的大型集合。

系统的体系结构可以分为两个领域:

  • 高级设计。 这描述了主要组件以及它们如何相互交互以满足每个要求。 如果系统很大,则每个组件可能都有自己的高级设计,显示它如何由较小的组件组成。

  • 在整个组件设计中使用的设计模式和约定。 模式描述了实现编程目标的特定方法。 通过在设计过程中使用相同的模式,你的团队可以降低进行更改和开发新软件的成本。

高级设计

高级设计描述了系统的主要组件,以及它们如何相互交互以实现设计目标。 以下列表中的活动涉及开发高级设计,尽管不一定在特定序列中。

如果要更新现有代码,可以从描述主要组件开始。 请确保了解用户要求的任何更改,然后添加或修改组件之间的交互。 如果要开发新系统,请首先了解用户需求的主要功能。 然后,可以浏览主要用例的交互序列,然后将序列合并到组件设计中。

在每种情况下,并行开发不同的活动,并在早期阶段开发代码和测试会很有帮助。 在开始另一个方面之前,请避免尝试完成其中一个方面。 通常,在编写和测试代码时,要求和你对设计系统的最佳方法的理解都会发生变化。 因此,应首先了解和编码要求和设计的主要功能。 在项目的后续迭代中填写详细信息。

  • 了解要求。 任何设计的起点都是清楚地了解用户的需求。

  • 体系结构模式。 你对系统的核心技术和体系结构元素所做的选择。

  • 组件和接口的数据模型。 可以绘制类图来描述在组件之间传递和存储在组件内的信息。

了解要求

完整应用程序的高级别设计是与要求模型或其他用户需求说明一起开发的。 有关要求模型的详细信息,请参阅 模型用户要求

如果要开发的系统是较大系统中的组件,则部分或全部要求可能体现在编程接口中。

要求模型提供以下基本信息片段:

  • 提供的接口。 系统或组件提供的接口列出了必须向用户提供的服务或操作,无论用户是人类还是其他软件组件。

  • 所需的接口。 所需的接口列出了系统或组件可以使用的服务或作。 在某些情况下,你将能够将所有这些服务设计为你自己的系统的一部分。 在其他情况下,尤其是在设计可与许多配置中的其他组件组合的组件时,所需的接口将由外部注意事项设置。

  • 服务质量要求。 系统必须满足的性能、安全性、可靠性和其他目标和约束。

    要求模型是从系统用户的角度编写的,无论是人员还是其他软件组件。 他们对您的系统的内部运作一无所知。 相比之下,体系结构模型中的目标是描述内部工作,并展示它们如何满足用户的需求。

    将要求和体系结构模型分开非常有用,因为它可以更轻松地与用户讨论要求。 它还有助于重构设计,并考虑替代体系结构,同时保持要求不变。

    应放入要求或体系结构模型的详细信息量取决于项目的规模以及团队的大小和分布。 短期项目上的小型团队可能仅限于绘制业务概念和一些设计模式的类图;而分布在多个地区的大型项目则需要显著更详细的设计。

体系结构模式

在开发初期,必须选择设计所依赖的主要技术和元素。 必须在其中做出这些选择的区域包括:

  • 基本技术选择,例如数据库和文件系统之间的选择,以及网络应用程序与 Web 客户端之间的选择,等等。

  • 框架选项,例如 Windows Workflow Foundation 或 ADO.NET Entity Framework 之间的选择。

  • 集成方法的选择,例如企业服务总线或点对点通道。

    这些选择通常由服务质量要求(如规模和灵活性)确定,可以在了解详细要求之前进行。 在大型系统中,硬件和软件的配置密切相关。

    所做的选择会影响使用和解释体系结构模型的方式。 例如,在使用数据库的系统中,类图中的关联可能表示数据库中的关系或外键,而在基于 XML 文件的系统中,关联可能指示使用 XPath 的交叉引用。 在分布式系统中,序列图中的消息可以表示网络上的消息;在独立应用程序中,它们可以表示函数调用。

设计模式

设计模式概述了如何设计软件的特定方面,尤其是系统不同部分中递归的方面。 通过在整个项目中采用统一的方法,可以降低设计成本,确保用户界面中的一致性,并降低理解和更改代码的成本。

一些常规设计模式(如观察者)是众所周知的且广泛适用。 此外,还有一些模式仅适用于你的项目。 例如,在网络销售系统中,代码中将有多个操作涉及对客户订单的更改。 为了确保每个阶段准确显示订单的状态,所有这些作都必须遵循特定的协议来更新数据库。

软件体系结构工作的一部分是确定应在设计中采用哪些模式。 这通常是一项正在进行的任务,因为随着项目的进展,将发现对现有模式的新模式和改进。 组织开发计划很有帮助,以便你在早期阶段练习每个主要设计模式。

大多数设计模式可以部分体现在框架代码中。 可以将模式的一部分减少为要求开发人员使用特定类或组件,例如确保正确处理数据库的数据库访问层。

文档中描述了设计模式,通常包括以下部分:

  • 名称。

  • 它适用的上下文的说明。 哪些条件应该让开发人员考虑应用此模式?

  • 它解决的问题的简要说明。

  • 主要部分及其关系的模型。 这些可能是类或组件和接口,它们之间存在关联和依赖关系。 元素通常分为两类:

  • 命名约定。

  • 描述模式如何解决问题。

  • 说明开发人员可能采用的变体。