系统架构-基于卫星的导航

2024-03-27 12:25:10

系统架构-基于卫星的导航

系统架构关注的是裂解系统需求，并利用这些只是来划分较大的系统。但是，我们必须记住这个层次的关注点通常十分抽象、宏观、影响巨大，且不涉及实现或技术细节。在设计架构时，如果我们理解这一点并采取正确的步骤，将更有坑能创建一个寿命很长的系统--更加可操作、可维护和可扩展。

本章将展示如何在逻辑上对所需功能进行划分，来开发假象的卫星导航系统的系统架构。为了让这个问题可管理，我们从简化的视角开发第一和第二层次的架构，分别定义组成部分和子雄。我们将展示一个有代表性的过程步骤和开发工件子集，而不是所欲步骤和工件。如果要从一个完整的视角展示这些部分及其子系统的规格说明，很容易划伤一整本书的篇幅。但是，我们展示的方法可以扩月一个架构层次，贯穿卫星导航系统架构的多个层次，完整地应用。

初始

开发系统架构首先要进行的步骤实际上是系统工程步骤，而不是软件工程步骤。

我们此时关注的焦点是确定必须为顾客建造什么，即定义问题的边界，确定任务用例，然后通过分析任务用例之一来确定一个系统用例子集。在这个过程中，我们从功能需求中形成用例，并用文档记录下肺功能需求和约束。但在进入需求分析之前，请先阅读一下补充资料“全球定位系统介绍”

卫星导航系统需求

建造系统来帮助解决顾客问题，这个过程从决定我们必须建造什么开始。第一步是阅读顾客提供给我们的所有成熟问题或需求的文档。对于系统来说，我们已经得到了一份有关高层次需求和约束的愿景陈述。

愿景：

为顾客提供高效的、买得起的卫星导航系统服务。

功能需求：

提供SNS服务；
操作SNS;
维护SNS。

非功能需求:

保证充分服务的可靠性级别；
提供足够精度以支持当前和未来的用户需要；
提供关键系统能力的功能冗余；
广泛的自动化，使操作成本最小化；
容易维护，使维护成本最小化；
可扩展，支持系统功能的升级；
服务生命期长，特别是太空部分的元件。

约束：

兼容国际标准;
充分利用商用现货（COTS）硬件和软件。

定义问题的边界

虽然只是最少的需求和约束，但它们确实允许我们迈出设计卫星导航系统架构的重要第一步--定义它的上下文，如图所示。上下文图可让我们清晰地理解SNS在环境中必须提供的功能。执行者代表和系统交互的外部实体，包括人、提供服务的其他系统和现实环境。依赖箭头展示了是外部实体依赖于SNS，还是SNS依赖于它。

執行者Atmosphere/Space(大气、空间），坑能开起来相当奇怪,知道我们把它看做卫星导航系统的地面部分和太空部分资产之间的通信的传输介质。因此，它是一个服务提供者。它的状态当然影响这些通信的质量。

上下文图的一个关键点是系统的确切边界，即什么在系统里面，什么不在里面。

在审查愿景和需求之后，我们架构团队认识到，提供给我们的功能需求实际上是众多任务级用例的容器，这些用例定义卫星导航系统必须提供的功能。这些任务用例包为我们提供了SNS高层次功能的上下文，如图。这些包中包含了一些任务用例，展示了SNS的用户、操作员和维护人员如何与系统进行交互，以完成其任务

确定用户用例

系统的愿景陈述的相当开放：“为顾客提供高效的、买得起的卫星导航系统服务”。异形词架构师需要明智地精简问题空间，使问题可以解决。

在分析时，我们只关注任务用例的成功场景，而把周多的备选场景留到以后。

现在，回到手上的任务，开发OperateSNS任务用例包中的任务用例。基于对SNS总体操作的分析，我们确定了四个相应的任务用例：

Initialize Operations(初始化操作)
Provide Normal Operations(提供正常操作)
Provide Special Operations(提供特别操作)
Terminate Operations(终止操作)

这些任务用例的规格说明主要依赖于开发团队的领域专家经验。出了过去的经验之外，模拟和原型通常是这个分析过程中有价值的工具。但是我们的分析通常会用活动图来建模，在开发下一小节的系统用例时，我们正是这样做的

确定系统用例

正如之前所说的，我们为Initalize Operations任务用例的功能绘制了一张后动图，以确定这个封装的系统用例。在绘制这张活动图时，我们没有视图利用SNS的组成部分的概念。这样做有一个理由：我们不希望预设手上问题可能的架构解决方案，约束我们对SNS曹组的分析。我们聚焦于SNS，把它当作一个黑盒，我们不能看到里面，因此只能看到它提供什么服务，而看不懂它如何提供服务。在分析系统的工程执行行为时，我们对操作员和卫星导航系统之间的跨越边界的控制流感兴趣。