应用体系结构建模

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

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

模型的目的是减少自然语言说明中的歧义,并帮助你和同事对设计进行可视化以及讨论备选设计。 模型应与其他文档或讨论一起使用。 就其本身而言,模型不表示该体系结构的完整规范。

注意

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

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

  • 高级设计。 它描述了主要组件以及这些组件彼此之间如何交互以满足每项需求。 如果系统很大,每个组件可能有其自己的高级设计,该设计演示它是如何由较小的组件组成的。

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

高级设计

高级设计描述你的系统的主要组件以及这些组件彼此之间如何交互以实现设计目标。 以下列表中的活动将参与开发高级设计,尽管并不一定按特定顺序参与。

如果要更新现有代码,可以通过介绍主要组件开始。 请确保你了解对用户需求所做的任何更改,然后添加或修改组件之间的交互。 如果你正在开发新系统,请通过了解用户需求的主要功能开始。 然后可以探索主要用例的交互序列,然后将序列合并到组件设计中。

在所有情况下,它有助于并行开发不同的活动以及在初期阶段开发代码和测试。 不要试图在开始另一个之前完成这些方面中的一个。 通常情况下,在编写和测试代码时,要求以及你对设计系统的最佳方式的理解都会改变。 因此,你应该通过了解需求的主要功能以及你的设计,然后对此进行编码着手。 在项目的后续迭代中填写详细信息。

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

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

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

了解要求

开发完整应用程序的高级设计时结合需求模型或用户需求的其他说明最为高效。 有关需求模型的详细信息,请参阅用户需求建模

如果你正在开发的系统是一个更大系统中的组件,则你的部分或全部需求可能会体现在编程接口中。

需求模型提供了这些必要的信息:

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

  • 需要的接口。 需要的接口列出了系统或组件可以使用的服务或操作。 在某些情况下,你将能够将所有这些服务设计为你自己系统的一部分。 在其他情况下,尤其是如果你设计的组件可在许多配置方面与其他组件结合,则需要的接口将根据外部考虑事项设置。

  • 服务质量要求。 性能、安全性、稳定性以及系统必须满足的其他目标和约束条件。

    将从系统用户的角度编写需求模型,无论这些用户是人还是其他软件组件。 他们不知道关于你的系统的内部工作原理的任何事情。 与此相反,你在体系结构模型中的目标是描述内部工作原理并演示其如何满足用户的需求。

    将要求和体系结构模型分开是很有用的,因为这样使得与用户讨论要求更容易。 它还帮助你重构设计并考虑备选体系结构,同时保持要求不变。

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

体系结构模式

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

  • 基础技术选择,例如在数据库与文件系统之间选择、在联网的应用程序与 Web 客户端之间选择等等。

  • 框架选择,例如在 Windows Workflow Foundation 或 ADO.NET 实体框架之间进行选择。

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

    这些选择经常由服务质量要求(如规模和灵活性)决定,并且在知道详细的要求之前可做出选择。 在大型系统中,硬件和软件的配置是密切相关的。

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

设计模式

设计模式是如何设计软件的某个特定方面的大纲,尤其是在系统的不同部件中重复出现的那个方面。 通过在项目之间采用一种统一的方法,可以降低设计成本、确保用户界面中的一致性,并降低理解和更改代码的成本。

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

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

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

设计模式在文档中说明,并且通常包含以下几部分:

  • 名称:

  • 它所适用的上下文的说明。 何种标准应使开发人员考虑应用这种模式?

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

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

  • 命名约定。

  • 该模式如何解决问题的说明。

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