| 項目 |
內容 |
| 這個做業屬於哪一個課程 |
老師連接 |
| 這個做業的要求在哪裏 |
做業連接地址 |
| 團隊名稱 |
always run |
| 做業學習目標 |
掌握面向對象軟件設計方法；（2）完善系統設計說明書，掌握面向對象詳細設計內容、設計原理和技術。 |
3.團隊項目系統設計改進總結
不足:在以前的設計書中沒有按照ooD設計準則，通過對面向對象設計方法的學習，改進了系統設計說明書,對上次的項目系統設計說明不足之處進行補充並加以改進，而且更新了《軟件系統設計說明書》，講其上傳到GitHub倉庫中，而後瞭解了軟件體系結構、軟件設計模式以及C/S與B/S結構，並蒐集了關於MVC設計模式的相關內容，深刻了解了其優缺點，利用面向對象方法，詳細分析系統設計模型，總結了以前UML的相關內容，找出不足之處在小組內討論，最後你們分工合做，完成各自分配到的任務，將其整理到本次博文當中。
四、團隊成員估計各自任務所需時間
|
|
任務 |
時間 |
|
|
任務三 |
一週 |
|
|
任務二 |
一週 |
|
|
任務二 |
一週 |
|
|
任務一 |
一週 |
三：問題回答git
（1）何謂軟件體系結構、軟件設計模式？程序員
（1）軟件體系結構是具備必定形式的結構化元素，即構件的集合，包括處理構件、數據構件和鏈接構件。處理構件負責對數據進行加工，數據構件是被加工的信息，鏈接構件把體系結構的不一樣部分組組合鏈接起來。這必定義注重區分處理構件、數據構件和鏈接構件，這一方法在其餘的定義和方法中基本上獲得保持。因爲軟件系統具備的一些共通特性，這種模型能夠在多個系統之間傳遞，特別是能夠應用到具備類似質量屬性和功能需求的系統中，並可以促進大規模軟件的系統級複用。
雖然軟件體系結構已經在軟件工程領域中有着普遍的應用，但迄今爲止尚未一個被你們所公認的定義。許多專家學者從不一樣角度和不一樣側面對軟件體系結構進行了刻畫，較爲典型的定義有：1.Dewayne Perry和A1ex Wo1f認爲軟件體系結構是具備必定形式的結構化元素，即構件的集合；2.Mary Shaw和David Garlan認爲軟件體系結構是軟件設計過程當中的一個層次，這一層次超越計算過程當中的算法設計和數據結構設計；3.Kruchten指出，軟件體系結構有四個角度：概念角度、模塊角度、運行角度、代碼角度；4.Hayes Roth則認爲軟件體系結構是一個抽象的系統規範，主要包括用其行爲來描述的功能構件和構件之間的相互鏈接、接口和關係。
（2）軟件設計模式就是Uml統一建模語言的技巧性概念。主要研究各個類模塊和接口之間的安排與搭配，也是爲程序員提供交流的一個很好的平臺。利用軟件設計模式您能夠作出質量更高，代碼更少，擴充更容易的軟件。設計模式主要分三個類型:建立型、結構型和行爲型。其中，建立型有單例模式、抽象工廠、工廠方法、建造模式、原型模式；行爲型有迭代器模式、觀察者模式、模板方法、命令模式、狀態模式、策略模式、職責鏈模式、中介者模式、訪問者模式、解釋器模式、備忘錄模式；結構型有組合模式、外觀模式、代理模式、適配器模式、裝飾模式、橋模式、享元模式。
（2）什麼是C/S與B/S結構？
1.B/S結構:B是英文單詞「Browser」的首字母，即瀏覽器的意思；S是英文單詞「Server」的首字母，即服務器的意思。B/S就是「Browser/Server」的縮寫，即「瀏覽器/服務器」模式。
B/S結構是隨着互聯網的發展，web出現後興起的一種網絡結構模式。這種模式統一了客戶端，讓核心的業務處理在服務端完成。你只須要在本身電腦或手機上安裝一個瀏覽器，就能夠經過web Server與數據庫進行數據交互。
2.C/S結構:C是英文單詞「Client」的首字母，即客戶端的意思，C/S就是「Client/Server」的縮寫，即「客戶端/服務器」模式。
C/S結構是一種軟件系統體系結構，也是生活中很常見的。這種結構是將須要處理的業務合理地分配到客戶端和服務器端，這樣能夠大大下降通訊成本，可是升級維護相對困難。好比咱們手機中安裝的微信、qq、王者榮耀等應用程序就是C/S結構。
2.C/S結構:
（3）什麼是MVC設計模式？
MVC是一種目前普遍流行的軟件設計模式,近來，隨着J2EE的成熟，它正在成爲在J2EE平臺上推薦的一種設計模型，也是廣大Java開發者很是感興趣的設計模型。MVC模式也逐漸在PHP和ColdFusion開發者中運用，並有增加趨勢。隨着網絡應用的快速增長,MVC模式對於Web應用的開發無疑是一種很是先進的設計思想，不管你選擇哪一種語言，不管應用多複雜,它都能爲你理解分析應用模型時提供最基本的分析方法，爲你構造產品提供清晰的設計框架，爲你的軟件工程提供規範的依據。
（一）MVC英文即Model-View-Controller，即把一個應用的輸入、處理、輸出流程按照Model、View、Controller的方式進行分離，這樣一個應用被分紅三個層――模型層、視圖層、控制層。
（1）視圖(View)表明用戶交互界面，對於Web應用來講，能夠歸納爲HTML界面，隨着應用的複雜性和規模性，界面的處理也變得具備挑戰性。一個應用可能有不少不一樣的視圖，MVC設計模式對於視圖的處理僅限於視圖上數據的採集和處理，以及用戶的請求，而不包括在視圖上的業務流程的處理。
（2）模型(Model)：就是業務流程/狀態的處理以及業務規則的制定。業務流程的處理過程對其它層來講是黑箱操做，模型接受視圖請求的數據，並返回最終的處理結果。MVC並無提供模型的設計方法，而只告訴你應該組織管理這些模型，以便於模型的重構和提升重用性。業務模型還有一個很重要的模型那就是數據模型。數據模型主要指實體對象的數據保存（持續化）。咱們能夠將這個模型單獨列出，全部有關數據庫的操做只限制在該模型中。
（3）控制(Controller)能夠理解爲從用戶接收請求, 將模型與視圖匹配在一塊兒，共同完成用戶的請求。劃分控制層的做用也很明顯，它清楚地告訴你，它就是一個分發器，選擇什麼樣的模型，選擇什麼樣的視圖，能夠完成什麼樣的用戶請求。控制層並不作任何的數據處理。例如，用戶點擊一個鏈接，控制層接受請求後, 並不處理業務信息，它只把用戶的信息傳遞給模型，告訴模型作什麼，選擇符合要求的視圖返回給用戶。所以，一個模型可能對應多個視圖，一個視圖可能對應多個模型。
（二）MVC的優缺點以下：
（1）MVC的優勢大部分用過程語言好比ASP、PHP開發出來的Web應用，初始的開發模板就是混合層的數據編程。MVC要求對應用分層，雖然要花費額外的工做，但產品的結構清晰，產品的應用經過模型能夠獲得更好地體現。
首先，最重要的是應該有多個視圖對應一個模型的能力。在目前用戶需求的快速變化下，可能有多種方式訪問應用的要求。例如，訂單模型可能有本系統的訂單，也有網上訂單，或者其餘系統的訂單，但對於訂單的處理都是同樣，也就是說訂單的處理是一致的。按MVC設計模式，一個訂單模型以及多個視圖便可解決問題。這樣減小了代碼的複製，也易於維護。
其次，因爲模型返回的數據不帶任何顯示格式，於是這些模型也可直接應用於接口的使用。
再次，因爲一個應用被分離爲三層，所以有時改變其中的一層就能知足應用的改變。一個應用的業務流程或者業務規則的改變只需改動MVC的模型層。所以，控制層能夠說是包含了用戶請求權限的概念。
最後，它還有利於軟件工程化管理。因爲不一樣的層各司其職，每一層不一樣的應用具備某些相同的特徵，有利於經過工程化、工具化產生管理程序代碼。
（2）MVC的缺點MVC的設計實現並不十分容易, 理解起來比較容易，但對開發人員的要求比較高。MVC只是一種基本的設計思想，還須要詳細的設計規劃。模型和視圖的嚴格分離可能使得調試困難一些，但比較容易發現錯誤。
綜合上述，MVC是構築軟件很是好的基本模式，至少將業務處理與顯示分離，強迫將應用分爲模型、視圖以及控制層, 使得你會認真考慮應用的額外複雜性，把這些想法融進到架構中，增長了應用的可拓展性。github