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

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

在上一次的項目系統設計說明書中沒有很好的完成軟件系統結構模型的建模設計，只做了基本的系統項目原型模型，項目系統結構的整體設計不夠完善。我們針對上一次的設計功能UML模型圖進行了改進，原本的UML模型圖描述了項目的功能作用，沒有展示出項目的設計流程和實現路線圖，改善後的流程圖加入了設計實現路線，對於系統功能進行了更為詳細的展示。

2.團隊項目Github倉庫《軟件系統詳細設計說明書》鏈接：https://github.com/yhy618/A

二.團隊項目系統設計：

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

功能實現流程圖：

UML模型描述項目系統：

2.團隊項目Github倉庫《軟件系統詳細設計說明書》鏈接：https://github.com/yhy618/A

3.本次實驗實施過程：

本次任務實驗是在團隊作業5系統概要設計的基礎上進一步詳細改進的過程，在設計好的模型下進行補充改進，對於項目系統設計中的不足點進行了討論分析，和技術上的難題小組成員間進行了交流和協商，擅長編程的組員對於軟件後臺內容進一步的添加，完善了其中的一些功能；嚴格按照系統說明書中提出的模型原理進行補充完善。其他小組成員對於界面進行美化，還有對於系統說明書的改進。最後各位小組成員的任務結果匯總起來就完成本次實驗項目。

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

5.總結與設計心得：

在本次的實驗任務中我們小組對於項目系統做了詳細的改進和設計，在老師發布實驗任務後我們小組內迅速的進行任務分工，對於以前設計的系統說明書重新進行了分析和研究，對於其中的不足之處進行了討論，小組內成員討論後交換了自己上次任務中存在的難題和瓶頸。大家討論完成後開始做自己的分工任務，大家互相幫助和交流，很認真的完成本次的實驗任務，完成了系統設計改進。大家一起合作完成一項任務的效率還是很高的，分工明確，互相協助，相互反饋就能夠很好的做好一個系統設計。

6.回答以下六個問題:

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

軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件。處理構件負責對數據進行加工，數據構件是被加工的信息,連接構件把體系結構的不同部分組合連接起來。這一定義註重區分處理構件、數據構件和連接構件，這一方法在其他的定義和方法中基本上得到保持。

軟件設計模式，又稱設計模式，是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。

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

C/S結構，即Client/Server(客戶機/服務器)結構，是大家熟知的軟件系統體系結構，通過將任務合理分配到Client端和Server端，降低了系統的通訊開銷，可以充分利用兩端硬件環境的優勢。早期的軟件系統多以此作為首選設計標準。

B/S結構，即Browser/Server(瀏覽器/服務器)結構，是隨著Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，用戶界面完全通過WWW瀏覽器實現,一部分事務邏輯在前端實現，但是主要事務邏輯在服務器端實現，形成所謂3-tier結構。B/S結構，主要是利用了不斷成熟的WWW瀏覽器技術，結合瀏覽器的多種Script語言(VBScript、JavaScript…)和ActiveX技術，用通用瀏覽器就實現了原來需要復雜專用軟件才能實現的強大功能，並節約了開發成本，是一種全新的軟件系統構造技術。隨Windows98/Windows2000將瀏覽器技術植入操作系統內部，這種結構更成為當今應用軟件的首選體系結構。

(3) 什麽是MVC設計模式？

MVC全名是Model View Controller，是模型(model)-視圖(view)-控制器(controller)的縮寫，一種軟件設計典範，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件裏面，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。

MVC簡易框架圖如下所示;

在上圖中 MVC模式框架圖中（Model-View-Controller）是軟件工程中的一種軟件架構模式，把軟件系統分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）

• 控制器Controller- 負責轉發請求，對請求進行處理。
• 視圖View - 界面設計人員進行圖形界面設計。
• 模型Model - 程序員編寫程序應有的功能（實現算法等等）、數據庫專家進行數據管理和數據庫設計(可以實現具體的功能)。

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

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

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

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

1> PDL描述的總體結構和一般的程序很相似，包括數據說明部分和過程部分，也可以帶有註釋等成分。但它是一種非形式的語言，對於控制結構的描述是確定的,而控制結構內部的描述語法不確定，可以根據不同的應用領域和不同的設計層次 靈活選用描述方式，也可以用自然語言。用它來描述詳細設計，工作量比畫圖小，又比較容易轉換為真正的代碼。

2>PAD圖所描述的程序結構十分清晰。圖中最左邊的豎線是程序的主線，即第一層控制結構。隨著程序層次的增加，PAD圖逐漸向右延伸，每增加一個層次，圖形向右擴展一條豎線。PAD圖中豎線的總條數就是程序的層次數;結構唯一、易於編制、易於檢查和易於修改的詳細設計表現方法。用PAD可以消除軟件開發過程中設計與制作的分離，也可消除制作過程中的"屬人性"。雖然目前仍需要由人來編制程序，一旦開發的PAD編程自動化系統實現的話，計算機就能從PAD自動編程，到那時程序邏輯就是軟件開發過程中人工制作的最終產品。顯然在開發時間上大大節省，開發質量上將會大大提高。

3>盒圖(boxplot):擺弄數據離散度的一種圖形。它對於顯示數據的離散的分布情況效果不錯，在軟件工程中，Nassi和Shneiderman 提出了一種符合結構化程序設計原則的圖形描述工具叫做盒圖,也叫做N_S圖。PAD所描繪的程序結構十分清晰；用PAD圖表現程序的邏輯易讀、易懂和易記；容易將PAD圖轉換成高級語言源程序自動完成；即可以表示邏輯，也可用來描繪數據結構；支持自頂向下方法的使用。

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

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

規範一:字體、字色、格式、底色等保持一致；

規範二:盡量表達出流程的六大要素；

規範三:操作及語言描述要簡潔清晰，一目了然；

規範四:動作環節要用準確的動詞來描述；

規範五:流程銜接處應該著重描述；

其他細節規範：https://wenku.baidu.com/view/a785d0f1e2bd960591c67743.html

《A_Pancers》團隊作業6—團隊項目系統設計改進與詳細設計