一.團隊項目系統設計改進：

1.分析項目系統設計說明書初稿的不足，特別是軟件系統結構模型建模不完善內容

? ? ? ?在上一次的項目系統設計說明書中沒有很好的完成軟件系統結構模型的建模設計，只做了基本的系統項目原型模型，項目系統結構的整體設計不夠完善。本階段完成系統的大致設計并明確系統的數據結構與軟件結構。本概要設計說明書的目的就是進一步細化軟件設計階段得出的軟件概貌，把它加工成在程序細節上非常接近與源程序開發的軟件表示。

2.團隊項目Github倉庫《軟件系統設計說明書》鏈接：

https://github.com/teammzs/project9

?

二.團隊項目系統設計：

1.在OOD的軟件項目詳細設計階段，開發團隊將進一步細化分析系統設計模型，精化類的屬性和操作，詳細定義類中服務的參數和具體實現邏輯，依據軟件開發環境調整類的層次關系和關聯關系，定義軟件數據庫表結構等等。請采用適當的建模方法完成團隊項目的系統詳細設計。

UML(統一建模語言)是面向對象建模語言的標準，它可以對任何具有靜態結構和動態行為的系統進行建模，它的主要作用是幫助用戶進行面向的描述和建模，它可以描述軟件從需求分析到軟件實現和測試的全過程。

功能實現流程圖：

? ?

?

UML模型描述項目系統：

?

?

2.團隊項目Github倉庫《軟件系統詳細設計說明書》鏈接：

?https://github.com/teammzs/project8?

3.本次實驗實施過程：

? ? ? ? 在本次項目中，我們小組通過討論，調查，分析等方式和策略認真的完成了這次實驗；在項目中，我們大家一起動手，一起參與討論，最后匯總得到一個最佳的方案，得到了這次項目中的最優解，讓我們的項目趨于完善。通過這次項目我學到了很多知識，也學到了很多項目解決的方案方法。本次任務實驗是在團隊作業5系統概要設計的基礎上進一步詳細改進的過程，在設計好的模型下進行補充改進，對于項目系統設計中的不足點進行了討論分析，和技術上的難題小組成員間進行了交流和協商，擅長編程的組員對于軟件后臺內容進一步的添加，完善了其中的一些功能；嚴格按照系統說明書中提出的模型原理進行補充完善。

4.團隊成員分工表和任務量：

?

團隊成員	任務	所需時間	工作量比例
馬世芳	軟件系統設計說明書	36h	20%
馬仲山、馬紹輝	團隊項目的系統詳細設計	48h	30%
馬婧（13）、張俊逸	軟件系統詳細設計說明書	48h	30%
馬婧(12)	博客撰寫	24h	20%

?

5.總結與設計心得：

? ? ? ?本次實驗小組成員分工明確，小組成員完成的也很認真及時，所以實驗進行的很順利，?經過本次實驗，從一開始的想法構思，到后來一步一步的進行設計的分析和實踐，團隊里每位成員都起著至關重要的作用。積極的協調，默契的配合，團隊成員互相信任，共同認可，雖然也有意見不一致的時候，但這也是一個新想法出現的時刻，在綜合考慮之后能結合小組每個成員的意見得出一個最好的設計方法，共同學習共同進步，使得實驗的進程加快了步伐，同時也讓我們學到了更多。團隊精神就是新時期的一種集體主義的升華和集體主義內容的擴展，我們在工作的分工與合作離不開團隊精神的支撐，沒有團隊精神的支撐就很難有我們各項工作的順利開展，總之，團隊精神就是新時期團結力和凝聚力的所在。

6.回答以下六個問題:

（1）何謂軟件體系結構、軟件設計模式？

? ? ? ??軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件。處理構件負責對數據進行加工，數據構件是被加工的信息，連接構件把體系結構的不同部分組組合連接起來。這一定義注重區分處理構件、數據構件和連接構件，這一方法在其他的定義和方法中基本上得到保持。由于軟件系統具有的一些共通特性，這種模型可以在多個系統之間傳遞，特別是可以應用到具有相似質量屬性和功能需求的系統中，并能夠促進大規模軟件的系統級復用。

? ? ? 軟件設計模式就是Uml統一建模語言的技巧性概念。主要研究各個類模塊和接口之間的安排與搭配，也是為程序員提供交流的一個很好的平臺。

（2）什么是C/S與B/S結構？

? ? ? ? C/S?（Client/Server）結構，即客戶機和服務器結構。它是軟件系統體系結構，通過它可以充分利用兩端硬件環境的優勢，將任務合理分配到Client端和Server端來實現，降低了系統的通訊開銷。C/S結構可以看做是胖客戶端架構。客戶端實現絕大多數的業務邏輯處理和界面展示，作為客戶端的部分需要承受很大的壓力，從分利用客戶端的資源，對客戶機的要求較高。其實現可以是客戶端包含一個或多個在用戶的電腦上運行的程序，而服務器端有兩種，一種是數據庫服務器端，客戶端通過數據庫連接訪問服務器端的數據；另一種是Socket服務器端，服務器端的程序通過Socket與客戶端的程序通信。目前大多數應用軟件系統都是Client/Server形式的兩層結構，由于現在的軟件應用系統正在向分布式的Web應用發展，Web和Client/Server?應用都可以進行同樣的業務處理，應用不同的模塊共享邏輯組件；因此，內部的和外部的用戶都可以訪問新的和現有的應用系統，通過現有應用系統中的邏輯可以擴展出新的應用系統。這也就是目前應用系統的發展方向。傳統的C／S體系結構雖然采用的是開放模式，但這只是系統開發一級的開放性，在特定的應用中無論是Client端還是Server端都還需要特定的軟件支持。由于沒能提供用戶真正期望的開放環境，C/S結構的軟件需要針對不同的操作系統系統開發不同版本的軟件，加之產品的更新換代十分快，已經很難適應百臺電腦以上局域網用戶同時使用。而且代價高，?效率低。

? ? ? ?B/S（Browser/Server）結構即瀏覽器和服務器結構。它是隨著Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，用戶工作界面是通過WWW瀏覽器來實現，極少部分事務邏輯在前端（Browser）實現，但是主要事務邏輯在服務器端（Server）實現，形成所謂三層3-tier結構。這樣就大大簡化了客戶端電腦載荷，減輕了系統維護與升級的成本和工作量，降低了用戶的總體成本（TCO）。
B/S結構可以看作是瘦客戶端，只是把顯示的較少的邏輯交給了Web瀏覽器，事務邏輯數據處理在放在了Server端，這樣就避免了龐大的胖客戶端，減少了客戶端的壓力。B/S結構的系統無須特別安裝，只有Web瀏覽器即可。當然AJAX\Flex等等的普遍使用也有富客戶端的發展方向。

?

(3) ?什么是MVC設計模式？

?? ? ? ?MVC設計模式是應用程序中用于處理應用程序數據邏輯的部分。通常模型對象負責在數據庫中存取數據。

?MVC簡易框架圖如下所示;

??

?

（4）結合項目系統設計體驗，簡要說明（1）、（2）、（3）的內容與軟件系統設計的關系。

? ? ?? ?框架、設計模式這兩個概念總容易被混淆，其實它們之間還是有區別的。框架通常是代碼重用，而設計模式是設計重用，架構則介于兩者之間，部分代碼重用，部分設計重用，有時分析也可重用。在軟件生產中有三種級別的重用：內部重用，即在同一應用中能公共使用的抽象塊;代碼重用，即將通用模塊組合成庫或工具集，以便在多個應用和領域都能使用；應用框架的重用，即為專用領域提供通用的或現成的基礎結構，以獲得最高級別的重用性。框架與設計模式雖然相似，但卻有著根本的不同。設計模式是對在某種環境中反復出現的問題以及解決該問題的方案的描述，它比框架更抽象；框架可以用代碼表示，也能直接執行或復用，而對模式而言只有實例才能用代碼表示;設計模式是比框架更小的元素，一個框架中往往含有一個或多個設計模式，框架總是針對某一特定應用領域，但同一模式卻可適用于各種應用。可以說，框架是軟件，而設計模式是軟件的知識。

? ? ? ? 設計模式僅是一個單純的設計，這個設計可被不同語言以不用方式來實現；而框架則是設計和代碼的一個混合體，編程者可以用各種方式對框架進行擴展，進而形成完整的不同的應用。框架一旦設計成形，雖然還沒有構成完整的一個應用，但是以其為基礎進行應用的開發顯然要受制于框架的實現環境；而設計模式是與語言無關的，所以可以在更廣泛的異構環境中進行應用。

（5）詳細設計的常見工具有哪些？

?（1）程序流程圖。程序流程圖又稱為程序框圖，是使用最廣泛然而也是用得最混亂的一種描述程序邏輯結構的工具。它用方框表示一個處理步驟，菱形表示一個邏輯條件，箭頭表示控制流向。其優點是：結構清晰，易于理解，易于修改。缺點是：只能描述執行過程而不能描述有關的數。

（2）盒圖。盒圖是一種強制使用結構化構造的圖示工具，也稱為方框圖。其具有以下特點：功能域明確、不可能任意轉移控制、很容易確定局部和全局數據的作用域、很容易表示嵌套關系及模板的層次關系。
（3）PAD圖。PAD是一種改進的圖形描述方式，可以用來取代程序流程圖，比程序流程圖更直觀，結構更清晰。最大的優點是能夠反映和描述自頂向下的歷史和過程。PAD提供了5種基本控制結構的圖示，并允許遞歸使用。
PAD的特點有：使用PAD符號設計出的程序代碼是結構化程序代碼；PAD所描繪的程序結構十分清晰；用PAD圖表現程序的邏輯易讀、易懂和易記；容易將PAD圖轉換成高級語言源程序自動完成；即可以表示邏輯，也可用來描繪數據結構；支持自頂向下方法的使用。
（4）PDL。PDL也可稱為偽碼或結構化語言，它用于描述模塊內部的具體算法，以便開發人員之間比較精確地進行交流。語法是開放式的，其外層語法是確定的，而內層語法則不確定。外層語法描述控制結構，它用類似于一般編程語言控制結構的關鍵字表示，所以是確定的。內層語法描述具體操作，考慮到不同軟件系統的實際操作種類繁多，內層語法因而不確定，它可以按系統的具體情況和不同的設計層次靈活選用，實際上任意英語語句都可用來描述所需的具體操作。用它來描述詳細設計，工作量比畫圖小，又比較容易轉換為真正的代碼。
PDL的優點：可以作為注釋直接插在源程序中；可以使用普通的文本編輯工具或文字處理工具產生和管理；已經有自動處理程序存在，而且可以自動由PDL生成程序代碼。
PDL的不足：不如圖形工具形象直觀，描述復雜的條件組合與動作間對應關系時，不如判定樹清晰簡單。

（6）如何繪制符合規范的流程圖？

流程圖必須使用標準符號，便于閱讀和研討分析。

每一流程中的文字力求簡單、扼要，而且明確可行。

繪制方向應由上而下，自左到右。

流程線條避免太長或交叉，可多用連接符號。

轉載于:https://www.cnblogs.com/cnboke/p/9143451.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的《F4+2》—团队项目系统设计改进与详细设计的全部內容，希望文章能夠幫你解決所遇到的問題。

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