《hello--world團隊》第六次做業：團隊項目系統設計改進與詳細設計

項目	內容
這個做業屬於哪一個課程	2016級計算機科學與工程學院軟件工程（西北師範大學）
這個做業的要求在哪裏	實驗十 團隊做業6：團隊項目系統設計改進與詳細設計
團隊名稱	《hello--world團隊》
做業學習目標	（1）掌握面向對象軟件設計方法；（2）掌握面向對象詳細設計內容、設計原理和技術。

Part0.簡要目錄

• 團隊項目github倉庫地址連接
• 團隊項目系統設計改進總結
• 團隊項目詳細設計過程總結
• 問題解答

---

Part1.團隊項目github倉庫地址連接

倉庫地址連接：點擊此處查看更新的《軟件系統概要設計說明書》以及《軟件詳細設計說明書》

Part2.團隊項目系統設計改進總結

不足之處：在分析上次實驗編寫的系統設計時，發現有不少地方設計結構不夠合理，並且在使用面向對象方法時，使用的不夠準確，通過系統的學習面向對象設計方法以後，在項目的改進中加入了缺失的系統的類圖，在類圖中能夠清晰的瞭解到各個類之間的關係，在系統的整體用例圖中也進行了進一步優化。利用面向對象方法，詳細分析系統設計模型，而且學習了軟件體系結構、軟件設計模式以及C/S與B/S結構，MVC設計模式等內容。再每次實驗前，都會對上次的實驗結果作一個改進，目的是讓儘早的發現系統存在的問題，減小後期沒必要要的花費，這種對一個項目進行不斷迭代的過程，也是爲了讓項目在設計過程當中作的更完善。

Part3.團隊項目詳細設計過程總結

在此次的設計過程當中，咱們遇到了很多的難題。其中一些是由於缺乏編程經驗而出現的簡單錯誤。其中也有較爲複雜的，經過小組內成員的討論和鑽研獲得絕大部分的解決，這對咱們在編程方面有必定的幫助和積累經驗做用。
在這個過程當中，首先遇到的就是數據庫的創建問題。怎樣合理的建表，設定幾個字段名稱，數據類型以及其餘屬性須要根據運行功能不斷修改完善。第二個問題時因爲時間的倉促，不少信息的輸入沒有作好有效字符的限定設置，就顯得沒有那麼正規。其次，就是程序設計的模板化的問題，一個好的軟件，都將一些較爲經常使用的功能模塊化，使用於整個工程，很方便的實現調用，不但減小了代碼的重複性，還使程序簡潔易懂。這都是咱們程序中有待改善的地方。

---

團隊成員在系統設計的具體分工以及佔整個系統設計文檔任務的工做量比例
姓名	任務	比重
楊天超	分析項目系統設計的不足、修改系統設計說明書	25%
孫錦喆	團隊項目實施過程的心得總結，github的上傳工做	25%
王小倩	回答所給出的問題、實驗做業博客的撰寫	25%
杜娣	撰寫《軟件系統詳細設計說明書》	25%

Part4.問題解答

一：何謂軟件體系結構？

雖然軟件體系結構已經在軟件工程領域中有着普遍的應用，但迄今爲止尚未一個被你們所公認的定義，許多專家學者從不一樣角度和不一樣側面對軟件體系結構進行了刻畫，較爲典型的定義有：
（1）Mary Shaw和David Garlan認爲軟件體系結構是軟件設計過程當中的一個層次，這一層次超越計算過程當中的算法設計和數據結構設計。體系結構問題包括整體組織和全局控制、通信協議、同步、數據存取，給設計元素分配特定功能，設計元素的組織，規模和性能，在各設計方案間進行選擇等。軟件體系結構處理算法與數據結構之上關於總體系統結構設計和描述方面的一些問題，如全局組織和全局控制結構、關於通信、同步與數據存取的協議，設計構件功能定義，物理分佈與合成，設計方案的選擇、評估與實現等
（2）Kruchten指出，軟件體系結構有四個角度，它們從不一樣方面對系統進行描述：概念角度描述系統的主要構件及它們之間的關係；模塊角度包含功能分解與層次結構；運行角度描述了一個系統的動態結構；代碼角度描述了各類代碼和庫函數在開發環境中的組織。
（3）Hayes Roth則認爲軟件體系結構是一個抽象的系統規範，主要包括用其行爲來描述的功能構件和構件之間的相互鏈接、接口和關係。
（4）David Garlan和Dewne Perry於1995年在IEEE軟件工程學報上又採用以下的定義：軟件體系結構是一個程序/系統各構件的結構、它們之間的相互關係以及進行設計的原則和隨時間進化的指導方針。
（5）Barry Boehm和他的學生提出，一個軟件體系結構包括一個軟件和系統構件，互聯及約束的集合；一個系統需求說明的集合；一個基本原理用以說明這一構件，互聯和約束可以知足系統需求。
（6）1997年，Bass，Ctements和Kazman在《使用軟件體系結構》一書中給出以下的定義：一個程序或計算機系統的軟件體系結構包括一個或一組軟件構件、軟件構件的外部的可見特性及其相互關係。其中，"軟件外部的可見特性"是指軟件構件提供的服務、性能、特性、錯誤處理、共享資源使用等。

軟件體系結構雖脫胎於軟件工程，但其造成同時借鑑了計算機體系結構和網絡體系結構中不少寶貴的思想和方法，最近幾年軟件體系結構研究已徹底獨立於軟件工程的研究，成爲計算機科學的一個最新的研究方向和獨立學科分支。軟件體系結構研究的主要內容涉及軟件體系結構描述、軟件體系結構風格、軟件體系結構評價和軟件體系結構的形式化方法等。解決好軟件的重用、質量和維護問題，是研究軟件體系結構的根本目的。研究軟件體系結構的首要問題是如何表示軟件體系結構，即如何對軟件體系結構建模。根據建模的側重點的不一樣，能夠將軟件體系結構的模型分爲5種：結構模型、框架模型、動態模型、過程模型和功能模型。

==================================================================================================================================

二：何謂軟件設計模式？

設計模式是軟件開發人員在軟件開發過程當中面臨的通常問題的解決方案，這些解決方案是衆多軟件開發人員通過至關長的一段時間的試驗和錯誤總結出來的。是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的；設計模式使代碼編制真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結構同樣。項目中合理地運用設計模式能夠完美地解決不少問題，每種模式在現實中都有相應的原理來與之對應，每種模式都描述了一個在咱們周圍不斷重複發生的問題，以及該問題的核心解決方案

設計模式分爲四種類型：
1.建立型模式：單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式。
2.結構型模式：適配器模式、橋接模式、過濾器模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。
3.行爲型模式：模版方法模式、命令模式、 空對象模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式、狀態模式、策略模式、責任鏈模式、訪問者模式。
4.J2EE模式：MVC 模式、業務表明模式、組合實體模式、數據訪問對象模式、前端控制器模式、攔截過濾器模式、服務定位器模式、傳輸對象模式。

設計模式的六大原則
一、開閉原則（Open Close Principle）
開閉原則就是說對擴展開放，對修改關閉。在程序須要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。因此一句話歸納就是：爲了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，咱們須要使用接口和抽象類，後面的具體設計中咱們會提到這點。
二、里氏代換原則（Liskov Substitution Principle）
里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說，任何基類能夠出現的地方，子類必定能夠出現。 LSP是繼承複用的基石，只有當衍生類能夠替換掉基類，軟件單位的功能不受到影響時，基類才能真正被複用，而衍生類也可以在基類的基礎上增長新的行爲。里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，因此里氏代換原則是對實現抽象化的具體步驟的規範。—— From Baidu 百科
三、依賴倒轉原則（Dependence Inversion Principle）
這個是開閉原則的基礎，具體內容：真對接口編程，依賴於抽象而不依賴於具體。
四、接口隔離原則（Interface Segregation Principle）
這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。仍是一個下降類之間的耦合度的意思，從這兒咱們看出，其實設計模式就是一個軟件的設計思想，從大型軟件架構出發，爲了升級和維護方便。因此上文中屢次出現：下降依賴，下降耦合。
五、迪米特法則（最少知道原則）（Demeter Principle）
爲何叫最少知道原則，就是說：一個實體應當儘可能少的與其餘實體之間發生相互做用，使得系統功能模塊相對獨立。
六、合成複用原則（Composite Reuse Principle）
原則是儘可能使用合成/聚合的方式，而不是使用繼承。

==================================================================================================================================

三：什麼是C/S結構？

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

C/S結構優缺點：
　　C/S結構的優勢:
　　 <1>.C/S結構的界面和操做簡單豐富。
　　 <2>.C/S結構的管理信息系統具備較強的事務處理能力。
　　 <3>.C/S結構的安全性能能夠很容易保證，實現多層認證也不難。
　　 <4>.C/S結構的響應速度快。因爲客戶端實現與服務器的直接相連，沒有中間環節，只有一層交互，所以響應速度較快。
　　C/S結構的缺點:
　　 <1>.適用面窄，一般用於局域網中。
　　　　 隨着互聯網的飛速發展，移動辦公和分佈式辦公愈來愈普及，這須要咱們的系統具備擴展性。這種方式遠程訪問須要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
　　 <2>.客戶端須要安裝專用的客戶端軟件。
　　　　 因爲程序須要安裝纔可以使用，所以不適合面向一些不可知的用戶。涉及到安裝的工做量，其次任何一臺電腦出問題，如病毒、硬件損壞，都須要進行安裝或維護。特別是有不少分部或專賣店的狀況，不是工 做量的問題，而是路程的問題。
　　 <3>.維護升級成本高，進行一次維護升級，須要全部客戶端的程序進行從新安裝。
　　 <4>.對客戶端的操做系統通常也會有限制。
　　　　 可能適應於WinXP, 但不能用於WinVista或Win7。或者不適用於微軟新的操做系統等等，還有Linux、Unix等等操做系統。

四：什麼是B/S結構？

B/S（Browser/Server）結構即瀏覽器和服務器結構。它是隨着Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，用戶工做界面是經過WWW瀏覽器來實現，極少部分事務邏輯在前端（Browser）實現，可是主要事務邏輯在服務器端（Server）實現，造成所謂三層3-tier結構。這樣就大大簡化了客戶端電腦載荷，減輕了系統維護與升級的成本和工做量，下降了用戶的整體成本（TCO）。
B/S結構能夠看做是瘦客戶端，只是把顯示的較少的邏輯交給了Web瀏覽器，事務邏輯數據處理在放在了Server端，這樣就避免了龐大的胖客戶端，減小了客戶端的壓力。B/S結構的系統無須特別安裝，只有Web瀏覽器便可。固然AJAX\Flex等等的廣泛使用也有富客戶端的發展方向。
以目前的技術看，局域網創建B/S結構的網絡應用，並經過Internet/Intranet模式下數據庫應用，相對易於把握、成本也是較低的。它是一次性到位的開發，能實現不一樣的人員，從不一樣的地點，以不一樣的接入方式（好比LAN, WAN, Internet/Intranet等）訪問和操做共同的數據庫；它能有效地保護數據平臺和管理訪問權限，服務器數據庫也很安全 。特別是在JAVA這樣的跨平臺語言出現以後，B/S架構管理軟件更是方便、快捷、高效。

C/S和B/S結構優缺點
B/S結構優缺點：
　　 B/S結構的優勢:
　　 <1>.無需安裝，客戶端不須要安裝有瀏覽器便可。
　　 <2>.分佈性特色，能夠隨時隨地進行查詢、瀏覽等業務處理。
　　 <3>.業務擴展便捷，經過增長頁面便可增長服務器功能。
　　 <4>.升級維護便捷，無需升級多個客戶端，升級服務器便可，就能夠實現全部用戶的同步更新。
　 　<5>.共享性強特色，能夠直接放在廣域網上，經過必定的權限控制實現多客戶訪問的目的，交互性較強。
　　 B/S結構的缺點:
　　 <1>.在跨瀏覽器上，BS結構不盡如人意。
　　 <2>.在速度和安全性上須要花費不少設計成本，響應速度不及C/S，隨着AJAX技術的發展，相比傳統B/S結構軟件速度有很大提高。
　　 <3>.用戶體驗不是很理想，B/S須要單獨界面設計，各個瀏覽器廠商的對瀏覽器的解析的標準不一樣。
　　　　 客戶端服務器端的交互是請求-響應模式，一般須要刷新頁面，這並非客戶樂意看到的。（在Ajax風行後此問題獲得了必定程度的緩 解）

==================================================================================================================================

五：什麼是MVC設計模式？

MVC設計模式是模型-視圖-控制器的全稱，是一種很是經典的軟件架構模式，在UI框架和UI設計思路中扮演着很是重要的角色。從設計模式的角度來看，MVC模式是一種複合模式，它將多個設計模式在一種解決方案中結合起來，用來解決許多設計問題。MVC模式把用戶界面交互分拆到不一樣的三種角色中，使應用程序被分紅三個核心部件：Model（模型）、View（視圖）、Control（控制器）。它們各自處理本身的任務：

（1）模型：模型持有全部的數據、狀態和程序邏輯。模型獨立於視圖和控制器，只包含純應用程序數據，不包含描述如何將數據呈現給用戶的邏輯

（2）視圖：用來呈現模型。視圖一般直接從模型中取得它須要顯示的狀態與數據，對於相同的信息能夠有多個不一樣的顯示形式或視圖，視圖向用戶顯示模型的數據。視圖知道如何訪問模型的數據，但它不知道這些數據意味着什麼，也不知道用戶能夠作什麼來操做它。

（3）控制器：位於視圖和模型中間，負責接受用戶的輸入，將輸入進行解析並反饋給模型，一般一個視圖具備一個控制器。

MVC模式將它們分離以提升系統的靈活性和複用性，不使用MVC模式，用戶界面設計每每將這些對象混在一塊兒。mvc模式就是這樣，把本來雜亂無章的類，分爲三堆，嚴格監管，按規則行事。說到底一切都是爲了使類之間的耦合性更鬆散。好的代碼應該對擴展開放，對修改關閉。MVC模式實現了模型和視圖的分離，這帶來了幾個好處。

（1）一個模型提供不一樣的多個視圖表現形式，也可以爲一個模型建立新的視圖而無須重寫模型。一旦模型的數據發生變化，模型將通知有關的視圖，每一個視圖相應地刷新本身。

（2）模型可複用。由於模型是獨立於視圖的，因此能夠把一個模型獨立地移植到新的平臺工做。

（3）提升開發效率。在開發界面顯示部分時，你僅僅須要考慮的是如何佈局一個好的用戶界面；開發模型時，你僅僅要考慮的是業務邏輯和數據維護，這樣能使開發者專一於某一方面的開發，提升開發效率。