建模理論與實踐/軟體工程和業務分析中的模型
這是一個大型象棋程式示例，說明它如何被建模為一個分析資訊系統，即沒有任何技術設計。我們從一個微小的示例開始，並逐步擴充套件它。
該程式的長期目標是管理象棋遊戲（即顯示、儲存、回放等），以及計算自己的走棋。前者對應於一個典型的以資料庫為中心的業務應用程式，後者是一個複雜演算法問題，即“僅僅”是一個非常高複雜度的單個函式（通常透過人工智慧方法來解決）。
我們的初始版本應該只完成接收走棋和顯示棋盤當前位置的基本工作。由於我們專注於功能的建模而不是使用者互動，因此假設我們的應用程式具有一個與某個使用者介面單元的介面，用於接收走棋和顯示棋盤，如上下文圖所示。走棋以方格對的形式給出，如下一節所述。
從資訊系統的角度來看，應用程式的核心價值是保持棋盤狀態的持久資訊，並根據輸入的走棋進行更改。但是，棋盤的變化不僅僅是象棋走棋。例如，可以設定位置，或者可以執行像“變後”這樣的特殊走棋，其中一個兵變為後。因此，為了能夠表示這一點，我們選擇了一種非常靈活的方法：我們實現了一個名為“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
主題誰來控制流程？
