解决方案设计

定义功能需求使我们能够提炼出需要在应用案例中实现的组件。这有助于我们理解需要交付什么以满足这些需求，并为评估实施选项提供较小的部分。

从功能需求中提取组件

解决方案设计过程的下一步是将我们的功能需求映射到可以在Foundry中实现的组件，然后权衡其配置选项。此步骤可能在各个应用案例中有所不同，但以下组件在广泛情况下都很有用：

• Object模型： Object模型的草图，识别核心、派生和应用案例Object类型及其链接类型。
• 生命周期图： 用户修改Objects时所采取操作的状态机图。
• 丰富数据： 告知决策输入所需的数据丰富列表。
• 界面期望： 不同界面及其意图的分解。

我们可以从功能需求中提取这些组件。例如：

路线运营分析师（用户类型）查看其负责路线的警报收件箱（界面），并基于优先级、航班和路线详情以及组织影响（决策输入）对警报进行分类（决策），以重新指派、解决或提升（操作）每个警报。

• 警报收件箱 - 我们需要一个独立的界面来查看新警报
• 他们负责的路线 - 我们需要在数据中反映路线、用户及其关系的概念
• 分类警报 - 我们需要一个能够经历不同状态并反映当前指派人的Object。我们还需要以某种方式生成警报。
• 优先级、航班和路线详情以及组织影响 - 我们需要与航班、航空公司、飞机等相关的附加数据。我们需要反映警报优先级和组织影响概念的丰富数据。
• 重新指派、解决或提升 - 我们需要定义警报Object类型完整状态机的操作

对其他功能需求重复此过程可产生以下组件：

• Object模型
• 生命周期图
• 丰富数据
• 界面期望

Object模型

此图表示包含我们功能需求中嵌入概念的Object模型。圆圈表示Object类型，圆圈之间的线条是链接类型。根据详细程度，考虑为每个Object类型标识主键属性，以及为每个链接类型标识基数（1:1、1:N或N:N）。

颜色有助于识别哪些Object类型是其Ontology的核心 - 它们直接映射到来自真实来源的数据粒度 - 哪些是派生的并需要创建为丰富数据。颜色还标识通过应用案例中的操作工作流主动编辑的应用案例Object类型。

在我们的例子中，回溯到源系统，我们可以识别有关航班、飞机、航空公司和机场的数据记录系统。我们的管道可以生成反映这些概念的核心Ontology。

然而，我们没有一个包含"路线"数据的源系统。在我们的变换段中，我们将派生一个每个路线一行的数据集，以在我们的Ontology中反映路线的概念。

对于我们应用案例的操作方面，我们需要一个反映我们组织的数据模型 - 因此有团队和员工Object类型。我们还需要标准构建块Object类型，如警报的“票”Object类型，以及用于捕获评论和上传文件的相关Object类型。

生命周期图

此简化图跟踪警报票Object的可能状态以及将其在状态之间转换的操作。随着应用案例的进展，跟踪可以进一步细化，以包括在每个操作中捕获的元数据以及定义何时可用给定操作和哪些用户可以执行它的验证。

丰富数据

通过功能需求和Object建模练习，我们可以识别Object级别和属性级别的丰富数据。Object级别的丰富数据是我们源数据中没有内在反映的新派生概念。这些可以匹配外部概念，如我们的路线Object类型，或者它们可以是操作或应用案例特定概念，如警报票。

属性级别的丰富数据通过应用组织规则、聚合低粒度数据或运行模型来增强现有Object类型的数据。在我们的例子中，我们需要为每个警报票反映优先级以及对组织影响的估计。

界面期望和意图

通过我们的功能需求，我们可以识别用户将拥有的不同意图和相应的交互期望。识别意图和期望会生成实际实现和相应工具的列表。

在我们的例子中，我们有以下内容：

• 一个操作用户期望一个引导的、独立的体验，以查看仅必要的警报，并立即获得所有必要的上下文。意图是直接采取行动。
• 我们的分析师期望有一个快速查看所有指派和调查中警报的地方，同时轻松进入临时数据探索和分析，并撰写调查的叙述。意图是分析和记录。
• 我们的执行用户期望有一个仪表盘视图，展示操作流程的有效性，并突出显示事物如何随时间变化。意图是理解。

实施选项

在记录了应用案例的组件后，接下来的决策是实现每个部分。上图可以帮助匹配常用组件的默认选项。

例如，上述的界面期望可以这样分解：

一个独立的收件箱应用是一个Workshop项目。由于许多交互涉及单个票据，Object视图对于给定票据应该提供统一视图，包括相关的决策上下文和易于访问的适当操作。一个执行仪表盘可能从一个Quiver模板开始。随着审查和监督流程的细化，模板可能演变为另一个Workshop模块和一组附加的应用案例Object类型，以定期跟踪和批准。在大多数情况下，一个Carbon工作区将相关Object类型子集与自定义界面结合在一起，提供一个精致、统一且可访问的体验，适用于所有潜在用户类型。

关于这些选项中的考量，有更多详细信息在Pipeline、Ontology和应用构建文档中。以下将重点放在这些部分之间实现决策的桥接领域。

最重要的例子是在哪里实现识别出的丰富数据。

实施丰富数据

考虑我们路线Object类型丰富数据的例子，以及我们可能想知道的关于每条路线的一组指标：平均飞行时间、到达延误超过30分钟的次数和飞行时间的变异性度量。

一种方法是在我们的应用程序中派生这些数据。例如，我们可以制作一个按起始和目的地机场分组的航班Object类型的数据透视表，并计算平均飞行时间。如果我们首先筛选到一组延误超过30分钟的航班，我们可以类似地绘制一个数据透视表来显示延误航班数量的路线。

这种方法有一些缺点。由于指标是在特定界面内计算的，因此无法重用。它们还需要在页面加载时进行评估，这可能导致相对较慢的性能。而且由于指标是临时的，它们不能作为进一步筛选或分析的一部分。此方法的好处是，由于计算是动态进行的，它们将立即更新以反映来自操作的新增值或更新值的任何变化。

一个过于简化的启发式可能是：如果丰富数据不依赖于用户通过操作可以更改的数据，则在数据层创建丰富数据。