跟蹤設計 - 屏幕數據庫可追溯性

Question

這隱約涉及：

Should I design the application or model (database) first?

Design from the database first through to UI or t’other way round?

但我的問題更多的是造型和文物，少約做設計的正確方法。我試圖弄清楚什麼樣的設計工件最能說明功能（用例），屏幕和數據庫元素（特別是表格和列）之間的聯繫。 UML非常以代碼爲中心。數據庫模型非常以數據庫爲中心。屏幕設計以用戶界面爲中心！

這是交易......我的團隊正在開發產品的第一個版本。我們使用了用例，然後做了屏幕設計，數據庫設計與這兩者有點隔離。缺陷的一個關鍵領域是用例及其伴隨的屏幕和數據庫之間缺乏可追溯性。在我們的產品中，用例和數據庫元素之間存在很高程度的重疊。許多用例涉及75％以上的數據庫基礎設施。因此，我們對數據庫設計領域的爭議很高，而且小數據庫更改很容易破壞較低級別的業務邏輯。

對於我們的下一個版本，我希望開發人員和DBA能夠清楚地瞭解每個功能部件所涉及的數據庫部分。用例/屏幕設計方法運行良好，所以我們保持它......訣竅是將每個用例和屏幕鏈接到數據庫模型，因此這些關係非常明顯，很難被忽略。

對於較小的項目（我們只有10人，但我經常參加3人或更少的團隊），我創建了自己的自定義圖表來展示這部分設計。在Visio中完成的屏幕，UML和數據庫表的融合，沒有鏈接到實際的代碼或SQL。我不確定它會爲更大的團隊工作，因爲它的手冊非常強大，可以隨時更新，而且它不會像我們的數據庫建模工具那樣自動生成代碼。

有什麼建議嗎？有沒有一個普遍接受的機制？

僅供參考 - 我們漂亮的瀑布，這是不會很快改變。我們確實喜歡文物......說「轉向敏捷」對於我們的團隊來說不是一個可行的解決方案。

Answer 1

您的用例是一個很好的起點。

• 將您的使用案例轉換爲 可執行測試代碼。此測試代碼 需要驗證結果 返回值是否符合您的用例的 要求。

• 的你 可以識別的工作和試驗的部分越小，越 健壯，你將能夠建立 您的應用程序。

• 這意味着 您的使用情況有很大一部分你的數據庫和GUI的 ，相互作用將 是容易理解。

很難鎖定複雜項目中的體系結構或業務邏輯相互影響，並完全預先設計不同的圖層。只有在實現它們的時候，你才能真正瞭解什麼能夠促進你的需求。

作爲一名開發人員，發現幫你做的最好的方式作業的技術，工具和流程。不要根據它們的來源來判斷這些。評估他們的價值，讓你成爲最好的開發者。

敏捷世界的一些項目肯定做了一個很大的區別，以我的工作的質量和效率。這並不需要扔掉蘋果車，並把經驗豐富的瀑布隊放入混亂。

Answer 2

數據庫應該模擬您的問題域。它應該完全建模，以便從中提取解決方案 - 真相。糟糕的設計本質上是對數據庫「撒謊」（允許無效數據或關係的可能性），當你對數據庫「撒謊」時，當你提出問題時它會「騙你」。

簡單的例子正在建模許多一對多關係，其中的關係只能是一個一對多，或假定值不能爲空，或治療外鍵作爲一個屬性。許多這些可以通過適當的規範化來避免，這要求您明確地找出什麼是關鍵，什麼不是。通過在模型中「使非法狀態不可表示」，您避免必須編寫「防禦性」代碼來檢查不可能或驗證關係是否可能，因爲不可能的事情由於表結構或聲明而不可表示檢查約束。

這降低了編寫代碼，你可以集中精力在大多數情況下，什麼需要做的，而不是防範不可能的成本。

Answer 3

從你的問題我不能告訴你的用例有多詳細。我得到的印象是，他們可能是高層次的使用情況下，不會分解成詳細的使用情況下（也許是通過包括或延長關係。

在任何情況下，我更喜歡下手的要求，並跟蹤當我編寫用例和用例圖時，我也創建了一個領域模型（一個高級的類圖），這主要是爲了給我一些與利益相關者討論的東西（「did 「）

當用例和領域模型完成時，如果屏幕之間存在複雜的交互作用，就有可能開始在屏幕設計上工作，也可能開始在活動模型上工作。應該把屏幕看作是帶UI的類 - 屏幕可能有FirstName屬性，我會注意到它與我的域模型中的Person實體的FirstName屬性相關。然而，FirstName屬性可能會在該屏幕上顯示爲文本框。

與此同時，物理數據庫設計可能會發生。這將產生一個類或ER圖，追溯到領域模型。最終，您可能會發現某些屏幕屬性或活動建模引用了物理數據庫模型中不存在於域模型中的內容。可以將屏幕「PersonalName」屬性與People模式中Person表中計算出的PersonalName列相關聯。

我用這樣的事情的工具是Sparx Enterprise Architect。這是一個很棒的工具，即使在專業版中也可以做到這一切，甚至更多。

我也不得不說真相的緣故，我主要是在我自己的模型 - 我還沒有處理過一個模型，代碼和數據庫正由獨立的人開發的項目。如果有人告訴我，上述方法在「現實生活」中無效，我可能會被迫相信它們。

Answer 4

我不知道我理解你的問題清楚了，但我會嘗試基於一些合理的假設，以迴應...

本質上來說，我的建議是一樣什麼約翰·桑德斯已經建議：以考慮使用UML和一個好的UML工具。但是我想補充一些在您的具體情況中可能很重要的觀點。

首先，我不認爲UML是「過於以代碼爲中心的」。相反，它幾乎可以在任何抽象層次上用於模擬軟件系統的幾乎任何方面。通過使用一個好的工具（如Sparx EA），UML的美妙之處在於，您實際上在引擎蓋下獲得了定義良好的模型（而不僅僅是一組未連接的圖/圖）。因此，即使這個工具本身並沒有給你一個你正在尋找的功能（就像從DB到用例的可追溯性）......至少你可以選擇自動化（或者至少半自動化）例如，您可以將您的UML模型導出爲XMI（標準！），然後從此處獲取所需的任何跟蹤相關信息（例如，使用XSL或任何支持XML的庫作爲您最喜歡的編程/腳本語言） 。我並不是說要做到這一點很容易（特別是如果你想在個別數據庫列8-級別上追溯），但它是可能的，並且如果它必須沿着該項目。

順便說一下，談到Sparx EA ...我不知道它的所有功能，但它有很多，我不會被驚異，如果它允許你選擇一個類（或甚至一個屬性類）並向您展示以某種方式依賴於它的其他模型元素。你可能想檢查一下。

說了這麼多，我也知道，您可能必須至少以下有關UML兩個重要關注點：

1. 它可能會出現需要太多的造型細節到位，以得到你想要的。作爲任何「通用工具」，它可能遠遠不如您已經使用過的專業建模工具。

關於問題＃1：再次，使用良好的UML工具，您可以根據需要執行儘可能多的快捷方式。例如，您不必爲用例構建非常詳細和準確的活動模型，而只需關注用例中涉及的類（僅足以使跟蹤類回到用例）。當然，這同樣適用於用戶界面。

關於問題＃2：我不知道您現在使用什麼確切的工具來建模用例，UI和數據庫模式。因此，從理論上講，它們可能都優於UML，因此您不希望爲了更易於追溯而交換任何一個。但是，有些東西告訴我，您的數據庫建模工具（具有代碼生成功能）可能是唯一真正不可或缺的工具。如果是這樣的話，那麼我仍然會建議考慮使用UML：你只是不建模到數據庫模式級別，並在域模型級別「停止」（即使你沒有在你的應用程序中）。此時，UML工具將爲您提供從域模型元素（實體，它們的屬性及其關係）到用例和UI元素的可追溯性，並且您的域模型和數據庫模式之間的映射可以「空中」因爲在絕大多數情況下，它們應該足夠簡單，無需繪製任何東西即可進行跟蹤。這可能不會給你100％的想要的，但它可以給你80％，足以減輕你的大部分問題。底線：如果您使用三種不同的工具/技術爲您的系統的三個不同方面建模......而且很明顯，這三個方面之間的任何可追溯性都受到這三種工具的支配：您可以自動化只有那些工具允許的數量（這可能意味着你將被困於大量繁瑣的手動任務）。到目前爲止，UML似乎是唯一明確定義和廣泛支持的「通用語言」，可以幫助您連接模型，並可實現大部分分析活動的自動化。只要確保你從真正的UML建模工具（如Sparx EA和其他一些工具）中區分出UML「簡單繪圖工具」（如大多數Visio附加軟件和模板）即可。