《F4+2》—團隊項目系統設計改進與詳細設計

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

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）如何繪製符合規範的流程圖？

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

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

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

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