交流伺服系統(tǒng)設計指南

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

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

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

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

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

表達系統(tǒng)設計

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

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

結構體

概述圖

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

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

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

詳細圖表

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

類圖

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

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

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

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

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

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

類結構圖

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

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

斐波那契系統(tǒng)的復合結構圖如下所示：

互動互動

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

用例

用戶與系統(tǒng)進行交互以滿足目標。 實現(xiàn)目標所需的一組交互作用形成一個用例 。

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

互動概述

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

詳細互動

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

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

州

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

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

建模技術

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

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

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

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

結論

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

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

交流伺服系統(tǒng)設計指南

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。