交流伺服系統設計指南

軟件設計至關重要。 它是應用程序的基礎。 就像藍圖一樣，它為所有背景的聚會提供了一個通用平臺。 它有助于理解，協作和發展。

設計不應僅視為開發的要素。 它不應該僅僅存在于開發人員的腦海中，否則團隊將發現它幾乎無法增長，因為知識很難獲得。 而且，當員工離職時，公司會損失更多的價值。

應用程序代碼應通過將領域模型有效地轉換為清晰的抽象來描述設計。 這些應該經過良好的編碼，良好的命名和良好的定義。 但這還不夠。

設計不僅應存在于代碼中。 盡管使用該層來表達設計對于開發團隊來說可能已經足夠，但是拒絕了其他對應用程序設計感興趣的人。 他們要么無法物理檢索代碼，要么沒有軟件開發背景，要么就沒有時間自己弄清楚設計。

有時，在編寫大量代碼之前，需要在多團隊組織中討論和完善高級設計。 在這種情況下，很明顯，即使代碼表達了設計，也不應僅將其包含在代碼中。 為此，設計建模已成為一個單獨的過程。

表達系統設計

設計不僅涉及類以及它們之間的關系。 這也與合作和行為有關。 關于用例，狀態和活動。

交流設計的主要形式如下。 由于UML的普及性， UML被用作參考，但是沒有人會受其符號或術語的約束，因為重點應該放在有效的溝通上。

結構體

概述圖

使用一組描述部署策略，程序包，模塊和組件的圖來描述系統結構概述。

最高級別的概述之一是部署，按照應用程序使用的基礎結構實體進行描述。 UML描述了實現該目的的部署圖 ，該部署圖由節點組成，例如Web服務器，應用程序服務器，數據庫服務器和客戶端。

系統中部署的組件具有外部依賴性。 這些應記錄在案。 UML為此目的規定了程序包圖 ，它描述了程序包合并和導入關系。

詳細圖表

在較低的層次上，通過展示類及其之間的關系來描述系統的結構。

類圖

類圖描述了系統的類，包括它們的屬性，操作（或方法）以及它們之間的關系。

關系可以具有多種類型，例如，依賴性，關聯性，組成，繼承。 應該清楚地表達它們，以便開發人員團隊可以手動設計系統，也可以使用根據類圖生成類的工具來設計系統。

在UML中 ，類成員可以具有以下類型的可見性：

• 公開 ：+
• 私人的 ：–
• 受保護的 ：＃
• 派生 ：/，該屬性是根據另一個元素的屬性計算得出的
• 包裝方式 ：?

在UML中 ，定義了以下關系：

• 關聯 ：表示一系列鏈接，可以是單向或雙向的； 關聯可以被命名；
• 繼承/泛化 ：一類是另一類的專門形式
• 實現/實現 ：一個類實現一個接口
• 依賴性 ：兩個元素之間的單向關系，當對一個元素的更改導致需要更改另一個元素時發生
• 集合 ：“具有”關聯，只能是雙向的； 在聚合關系中，聚合組件可以存在于容器外部
• 組成 ：更強大的聚集關系，其中聚集的組件不能“存在”于容器外部，例如汽車的引擎

類結構圖

這種類型的圖顯示了類的內部結構。 它們可以包括其協作者如何與之交互以及如何與之交互。

在UML中 ， 復合結構圖包括內部零件，端口和連接器。 端口促進了班級內部以及與外界的交流。 連接器位于零件和端口之間。

斐波那契系統的復合結構圖如下所示：

互動互動

一個系統內發生的交互與其結構一樣重要，甚至更多。 實際上，行為是用戶所體驗的，因此對其進行精確描述和早期建模可以使參與該項目的每個人都省去很多麻煩。

用例

用戶與系統進行交互以滿足目標。 實現目標所需的一組交互作用形成一個用例 。

與一組用戶故事相反，表示這些交互對于以緊湊形式可視化需求非常重要。 UML定義了用例圖 ，其中涉及不同的參與者和系統。

互動概述

在更高的層次上，可以用模塊之間的交互來描述系統，通常是為了建模控制流。 就此而言， UML定義了交互概述圖和活動圖 。 交互概述圖可以描述由多個交互組成的控制流，而活動圖的詳細程度較低，描述了實際條件，邏輯和動作。

詳細互動

消息序列圖捕獲了協作類之間的操作順序。 在UML中 ，它們稱為序列圖。 這些類型的圖不僅描述了類如何交互，而且還包括時間元素，建立了交互的順序或順序：

水平箭頭顯示兩個協作者之間交換的消息。 垂直線（也稱為生命線）捕獲了兩個類之間可能發生的所有通信。

州

在具有復雜約束和條件的環境中，系統狀態可能難以可視化。 最直觀地講，該系統可以表示為狀態機，其節點數量與狀態一樣多，并且條件會在附加到標記過渡的箭頭的狀態之間進行切換。 為了提高可讀性，應抽象出復雜的條件并以簡潔的方式表達。

在UML中 ，狀態圖使用標準化表示法表示狀態。 實心圓表示初始狀態。 空心圓代表最終狀態。 圓角矩形表示給定的命名狀態。 箭頭表示與事件相關的過渡。 還提供了事件名稱：

建模技術

可以使用文本和圖形兩種基本方法來描述設計。 通常，人們傾向于對圖像更感興趣，但文本模型傾向于更具描述性。 存在混合功能，可以同時進行高級概述和可視化詳細信息的功能。

執行文本建模，以形式化語言表達需求。 這些模型傾向于以犧牲總體概觀為代價提供更多細節。 在某些方面，創建速度被認為比圖形方法要高，因為在圖形方法中，設計人員需要在鼠標和鍵盤之間進行切換。 格式化趨向于更快，更高質量。 同樣，鑒于基于文本的格式，版本控制的使用變得更加自然。

但是，對于文本建模，理解模塊往往是一項更具挑戰性的任務。 更現代的工具提供了顯示基于樹的結構或狀態機的方法來克服此問題，但這并不總是足夠的。 無法解決的一個特定問題仍然是動畫和仿真，如果需要，應將其視為轉向圖形方法的基礎。

使用圖形建模，用戶無需使用建模工具即可學習任何東西。 設計往往不太像編程，因為用戶可以將更多的內容與他們要建模的概念聯系起來。 學習系統時，從高級到低級再回到高級很容易。

結論

交流設計與設計同等重要。 必須避免將設計鎖定在開發人員的思想和/或代碼中。 相反，應該有效地進行溝通，以便項目中的每個人都可以訪問它。

翻譯自: https://www.javacodegeeks.com/2016/08/communicating-design.html

交流伺服系統設計指南

總結

以上是生活随笔為你收集整理的交流伺服系统设计指南_交流设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。