《BUG創造隊》第六次做業：團隊項目系統設計改進與詳細設計

項目	內容
這個做業屬於哪一個課程	2016級軟件工程
這個做業的要求在哪裏	實驗十 團隊做業6：團隊項目系統設計改進與詳細設計
團隊名稱	BUG創造隊
做業學習目標	1.編寫完整《軟件系統設計說明書》；2.完成團隊項目《軟件系統詳細設計說明書》；3.掌握面向對象軟件設計方法，深刻學習UML圖的繪製

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

1.更新Github倉庫《軟件系統設計說明書》

        分析《社區物業管理系統項目軟件系統設計說明書》初稿不足,已修改並上傳。

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

首先，咱們根據老師上節課對咱們UML圖的評價，對UML圖進行了改進，改進結果以下：

1.類圖

2.E-R圖

3.用例圖

4.活動圖

        經過本次系統設計改進，咱們小組成員對UML圖的繪製有了更深刻的理解，糾正了咱們以前對UML圖的錯誤理解，並從新繪製了UML圖。而且對項目設計的數據邏輯模塊進行了詳細的設計。最後，進行了更深刻的需求調查，利用週末的時間去學校周圍的小區進行調研，使咱們的需求更加真實。

任務2：團隊項目系統詳細設計

1.Github倉庫上傳《軟件系統詳細設計說明書》

        已將《社區物業管理系統項目軟件系統詳細設計說明書》上傳GitHub。

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

        咱們小組在面向對象設計階段，經過UML圖進一步細化分析系統設計模型，例如對項目的每一個模塊畫出了詳細的活動圖；而且精化了類的屬性和操做，詳細定義類中服務參數和具體實現邏輯，對系統中各個模塊的類進行了更加細緻的區分；依據軟件開發環境調整類的層次關係和關聯關係，使項目的層次關係更加清晰；最後定義了軟件數據庫表結構，爲實現社區物業管理系統進行鋪墊。在本次團隊項目系統詳細設計的過程當中，咱們每一個人都有參與討論，而且提出了本身的看法，最後由仇素龍同窗根據你們討論的內容編寫完成了《軟件系統詳細設計說明書》。

任務三：團隊分工

1. 團隊成員估計完成本次博客的任務分工

姓名	分工	完成的百分比
閆雪	博客的撰寫，活動圖的改進	30%
李蓉	博客的完善，用例圖的改進	20%
後新莉	改進《軟件系統設計說明書》，E-R圖的改進	20%
仇素龍	編寫《軟件系統詳細設計說明書》，類圖的改進	30%

2. 團隊成員估計完成本次博客各自任務所需時間

姓名	預計完成時間（min）	實際所用時間（min）
閆雪	80	100
李蓉	70	85
後新莉	70	75
仇素龍	90	95

本次心得：

        在本次的做業完成的過程當中，咱們團隊的四我的各自明確了本身的任務，根據老師上課的點評，改進了咱們的UML圖；而且在週末到學校周圍的小區進行了需求分析的實地調查。以後由後新莉同窗將《軟件系統設計說明書》的不足從新編寫。其次，咱們小組對軟件系統的設計進行了更加詳細的討論，並由仇素龍同窗完成《軟件系統詳細設計說明書》的編寫。最後，由我和李蓉同窗共同編寫博客。在本次任務中，咱們對UML圖有了更加深刻的理解，而且在你們各自分工明確的狀況下共同完成了此次做業。

任務四：問題解答

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

      a.軟件體系結構：
        雖然軟件體系結構已經在軟件工程領域中有着普遍的應用，但迄今爲止尚未一個被你們所公認的定義。許多專家學者從不一樣角度和不一樣側面對軟件體系結構進行了刻畫，較爲典型的定義有：
（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在《使用軟件體系結構》一書中給出以下的定義：一個程序或計算機系統的軟件體系結構包括一個或一組軟件構件、軟件構件的外部的可見特性及其相互關係。其中，"軟件外部的可見特性"是指軟件構件提供的服務、性能、特性、錯誤處理、共享資源使用等。
     b.軟件設計模式：
       軟件設計模式（Design pattern），又稱設計模式，是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。
常見23種模式概述：
1） 抽象工廠模式（Abstract Factory）：提供一個建立一系列相關或相互依賴對象的接口，而無需指定它們具體的類。
2） 適配器模式（Adapter）：將一個類的接口轉換成客戶但願的另一個接口。適配器模式使得本來因爲接口不兼容而不能一塊兒工做的類能夠一塊兒工做。
3） 橋樑模式（Bridge）：將抽象部分與它的實現部分分離，使它們均可以獨立地變化。
4） 建造模式（Builder）：將一個複雜對象的構建與它的表示分離，使一樣的構建過程能夠建立不一樣的表示。
5） 責任鏈模式（Chain of Responsibility）：爲解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它。
6） 命令模式（Command）：將一個請求封裝爲一個對象，從而可用不一樣的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支持可取消的操做。
7） 合成模式（Composite）：將對象組合成樹形結構以表示「部分－總體」的層次結構。它使得客戶對單個對象和複合對象的使用具備一致性。
8） 裝飾模式（Decorator）：動態地給一個對象添加一些額外的職責。就擴展功能而言，它能生成子類的方式更爲靈活。
9） 門面模式（Facade）：爲子系統中的一組接口提供一個一致的界面，門面模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
10） 工廠方法（Factory Method）：定義一個用於建立對象的接口，讓子類決定將哪個類實例化。Factory Method 使一個類的實例化延遲到其子類。
11） 享元模式（Flyweight）：運用共享技術以有效地支持大量細粒度的對象。
12） 解釋器模式（Interpreter）：給定一個語言，定義它的語法的一種表示，並定義一個解釋器，該解釋器使用該表示解釋語言中的句子。
13） 迭代子模式（Iterator）：提供一種方法順序訪問一個聚合對象中的各個元素，而又不需暴露該對象的內部表示。
14） 調停者模式（Mediator）：用一箇中介對象來封裝一系列的對象交互。中介者使各對象不須要顯式的內部表示。
15） 備忘錄模式（Memento）：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態。這樣之後就可將該對象恢復到保存的狀態。
16） 觀察者模式（Observer）：定義對象間的一種一對多的依賴關係，以便當一個對象的狀態發生改變時，全部依賴於它的對象都獲得通知並自動刷新。
17） 原始模型模式（Prototype）：用原型實例指定建立對象的種類，而且經過拷貝這個原型建立新的對象。
18） 代理模式（Proxy）：爲其餘對象提供一個代理以控制對這個對象的訪問。
19） 單例模式（Singleton）：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
20） 狀態模式（State）：容許一個對象在其內部狀態改變時改變它的行爲。對象看起來彷佛修改了它所屬的類。
21） 策略模式（Strategy）：定義一系列的算法，把它們一個個封裝起來，而且使它們可相互替換。本模式使得算法的變化可獨立於使用它的客戶。
22） 模板模式（Template Method）：定義一個操做中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟。
23） 訪問者模式（Visitor）：表示一個做用於某對象結構中的各元素的操做。該模式能夠實如今不改變各元素的類的前提下定義做用於這些元素的新操做。

2.什麼是C/S與B/S結構？

       B/S（Browser/Server）：又稱瀏覽器/服務器模式。是WEB興起後的一種網絡結構模式，WEB瀏覽器是客戶端最主要的應用軟件。這種模式統一了客戶端，將系統功能實現的核心部分集中到服務器上，簡化了系統的開發、維護和使用。客戶機上只要安裝一個瀏覽器，如Internet Explorer，服務器安裝SQL Server、Oracle、MYSQL等數據庫。瀏覽器經過Web Server 同數據庫進行數據交互。
       C/S(Client/Server)：：稱客戶/服務器模式。服務器一般採用高性能的PC、工做站或小型機，並採用大型數據庫系統，如Oracle、Sql Server等。客戶端須要安裝專用的客戶端軟件。
       C/S 與 B/S 區別:Client/Server是創建在局域網的基礎上的.Browser/Server是創建在廣域網的基礎上的,但並非說B/S結構不能在局域網上使用,如智贏IPOWER,在單機,侷限網,廣域網均能使用。
1．硬件環境不一樣:
C/S 通常創建在專用的網絡上, 小範圍裏的網絡環境, 局域網之間再經過專門服務器提供鏈接和數據交換服務.
B/S 創建在廣域網之上的, 沒必要是專門的網絡硬件環境,例與電話上網, 租用設備. 信息本身管理. 有比C/S更強的適應範圍, 通常只要有操做系統和瀏覽器就行
2．對安全要求不一樣
C/S 對服務端、客戶端都安全都要考慮。
B/S 因沒有客戶端，因此只注重服務端安全便可。
3．對程序架構不一樣
C/S 程序能夠更加註重流程, 能夠對權限多層次校驗, 對系統運行速度能夠較少考慮.
B/S 對安全以及訪問速度的多重的考慮, 創建在須要更加優化的基礎之上. 比C/S有更高的要求 B/S結構的程序架構是發展的趨勢, 從MS的.Net系列的BizTalk 2000 Exchange 2000
等, 全面支持網絡的構件搭建的系統. SUN 和IBM推的JavaBean 構件技術等,使 B/S更加成熟. 例如智贏IPOWER，採用AJAX和數據存儲優化技術，相比通常B/S架構軟件速度提升
30%至99%。
4．軟件重用不一樣
C/S 程序能夠不可避免的總體性考慮, 構件的重用性不如在B/S要求下的構件的重用性好.
B/S 對的多重結構,要求構件相對獨立的功能. 可以相對較好的重用.就入買來的餐桌能夠再利用,而不是作在牆上的石頭桌子
5．系統維護不一樣
系統維護是軟件生存週期中,開銷大, -------重要
C/S 程序因爲總體性, 必須總體考察, 處理出現的問題以及系統升級. 升級難. 多是再作一個全新的系統
B/S 構件組成,方面構件個別的更換,實現系統的無縫升級. 系統維護開銷減到最小.用戶從網上本身下載安裝就能夠實現升級.
6．處理問題不一樣
C/S 程序能夠處理用戶面固定, 而且在相同區域, 安全要求高需求, 與操做系統相關. 應該都是相同的系統
B/S 創建在廣域網上, 面向不一樣的用戶羣, 分散地域, 這是C/S沒法做到的. 與操做系統平臺關係最小.
7．用戶接口不一樣
C/S 可能是創建的Window平臺上,表現方法有限,對程序員廣泛要求較高
B/S 創建在瀏覽器上, 經過WEB服務或其餘公共可識別描述語言可跨平臺，使用更靈活。不只可應用在Window平臺上，還可應用於unix/Linux等平臺。
8．信息流不一樣
C/S 程序通常是典型的中央集權的機械式處理, 交互性相對低
B/S 信息流向可變化, B-B B-C B-G等信息、流向的變化, 更象交易中心。

3.什麼是MVC設計模式？

       MVC設計模式:MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典範，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯彙集到一個部件裏面，在改進和個性化定製界面及用戶交互的同時，不須要從新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。MVC模式做爲軟件工程中的一種軟件架構模式，把軟件系統分爲三個模塊：模型（Model）、視圖（View）和控制器（Controller）。        模型（Model）：我更願意將這個模塊叫作數據模塊，其中存儲的是軟件中的數據。用戶能夠經過操做視圖進行輸入，來間接地更改模型中的值。模型中的值也會間接地呈如今視圖上。 Model 中數據的變化通常會經過一種刷新機制被公佈。爲了實現這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 能夠了解在數據 Model 上發生的改變。（好比：觀察者模式（軟件設計模式））        視圖（View）：與用戶交互的界面，經過視圖，用戶可以進行輸入並得到輸出反饋        控制器（Controller）：連接模型與視圖的橋樑，在此定義函數或算法以實現對不一樣用戶輸入所執行的不一樣操做。