建模理论与实践/软件工程和业务分析中的模型
这是一个大型象棋程序示例，说明它如何被建模为一个分析信息系统，即没有任何技术设计。我们从一个微小的示例开始，并逐步扩展它。
该程序的长期目标是管理象棋游戏（即显示、存储、回放等），以及计算自己的走棋。前者对应于一个典型的以数据库为中心的业务应用程序，后者是一个复杂算法问题，即“仅仅”是一个非常高复杂度的单个函数（通常通过人工智能方法来解决）。
我们的初始版本应该只完成接收走棋和显示棋盘当前位置的基本工作。由于我们专注于功能的建模而不是用户交互，因此假设我们的应用程序具有一个与某个用户界面单元的接口，用于接收走棋和显示棋盘，如上下文图所示。走棋以方格对的形式给出，如下一节所述。
从信息系统的角度来看，应用程序的核心价值是保持棋盘状态的持久信息，并根据输入的走棋进行更改。但是，棋盘的变化不仅仅是象棋走棋。例如，可以设置位置，或者可以执行像“变后”这样的特殊走棋，其中一个兵变为后。因此，为了能够表示这一点，我们选择了一种非常灵活的方法：我们实现了一个名为“put”的函数，该函数简单地将给定的棋子放到给定的方格中。这包括将空置放在方格中，并且使应用程序非常灵活。当然，缺点是每次走棋都需要两次函数调用，一次清除“从方格”中的棋子，一次设置“到方格”中的棋子。这是一个典型的软件权衡。
- 论述（软件工程）
- 另一种方法是实现一个“move”函数，将棋子从方格 a 移动到方格 b。这排除了像“变后”、“王车易位”和“过路兵”这样的特殊走棋。我们还需要考虑如何设置初始位置。为了测试目的，我们可以通过一个测试脚本在初始状态下填充数据库。当然，这样我们的版本就不是一个可运行的应用程序。这与 ??? 示例： ??? 最小可运行产品：必要功能与性能/可扩展功能 - 必要功能是运行的关键，可扩展功能是销售的关键的范式相矛盾。
put( s:Square, p:PieceType )
更新方格
显示：方格
select * from Board join Square
从上面的考虑中，我们获得了带有方格、棋子和方格与棋子映射的“棋盘”实体。映射通过将棋子类型（如黑骑士）附加到方格来建模。
- 论述（建模）
- 另一种建模选择是将方格附加到棋子，以便“棋子”实体类型正好引用一个方格。那么，哪种选择更好呢？
- 将棋子附加到方格， ??? 方格具有一个身份，由它们的键（列、行）定义，例如 a1 或 f3。而棋子本身的身份并不重要，重要的是它的类型。
数据类型：棋盘 方格 x:[a-h] y:[1-8] 棋子 [bw] [KQRBNP_] 约束：棋盘是唯一的，棋盘的完整性由基数 64 和值范围 a-h 和 1-8 确保。
注意，我们系统的状态是棋子在棋盘上的所有可能放置。由于这些位置中没有 强调 的位置（例如起始位置），因此我们系统的状态机看起来像图中所示。
到目前为止，我们已经描述了数据流，但没有控制流。对于这个版本，我们简单地假设我们完全从外部进行控制，即每个“put”和“display”都由 UI 单元触发。这使我们只剩下两个用例。
- 放置棋子：put、display
- 移动棋子：put、put、display
主题谁来控制流程？
