| 專案 | 內容 |
|---|---|
| 課程班級部落格連結 | 班級部落格連結 |
| 這個作業要求連結 | 作業要求連結 |
| 團隊名稱 | TheSuperego |
| 團隊成員分工描述 | 公 * 瑜：團隊專案軟體系統設計說明書，系統資料庫邏輯結構 陳 * 弟：完善WBS，軟體系統總體結構設計 楊 * 霞：撰寫整體部落格，專案互評，任務三 張 * 盼：專案系統需求規格說明書，任務二 |
| 團隊的課程學習目標 | 1.學習使用UML建模工具Visio 2.掌握物件導向需求分析建模技術 3.理解和掌握物件導向軟體系統設計原理、設計過程和技術 |
| 這個作業在哪些方面幫助團隊實現學習目標 | 1.學會熟練使用Visio常用UML圖形繪製工具 2.選擇適當的UML模型,建立問題域物件模型 3.應用物件導向分析方法,完善軟體需求設計說明書 4.完善需求建模與系統設計說明書 |
| 團隊部落格連結 | 團隊部落格 |
| 團隊專案Github倉庫地址連結 | Github倉庫地址連結 |
任務1：按團隊專案互評名單，對互評方《實驗七 專案需求分析建模與系統設計（1）》的專案成果進行評價
對結對方部落格整體的內容閱讀後，互評方作業成績為98分
任務2：使用Visio，應用物件導向分析方法（OOA），完善團隊專案的《軟體需求規格說明書》,並將該文件上傳到團隊專案Github倉庫
（1）採用用例圖表示專案功能需求，模型使用規範一致的圖形符號和文字描述內容；
（2）參考《構建之法—現代軟體工程》8.5節功能的定位和優先順序，給出功能分析的四個象限；
（3）選擇適當的UML模型，建立問題域物件模型；
（4）採用OOA技術編制《XXX軟體需求規格說明書1.2》上傳到團隊專案Github倉庫截圖
（5）文件有關於團隊軟體專案的需求陳述文字截圖
（6）完善專案的WBS，估計各項任務所需時間
任務3：查閱資料，回答以下問題：
（1）什麼是C/S結構？
- C/S結構：Client/Server，是一種軟體系統體系結構，即客戶機和伺服器結構。C/S結構通常採取兩層結構。伺服器負責資料的管理，客戶機負責完成與使用者的互動任務。在C/S結構中，應用程式分為兩部分:伺服器部分和客戶機部分。伺服器部分是多個使用者共享的資訊與功能，執行後臺服務，如控制共享資料庫的操作等;客戶機部分為使用者所專有，負責執行前臺功能，在出錯提示、線上幫助等方面都有強大的功能，並且可以在子程式間自由切換。
- C/S結構可以看做是胖客戶端架構。客戶端實現絕大多數的業務邏輯處理和介面展示，作為客戶端的部分需要承受很大的壓力，從分利用客戶端的資源，對客戶機的要求較高。
（2）什麼是B/S結構?
- B/S結構:即瀏覽器和伺服器結構,Browser/Server。它是隨著Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，使用者工作介面是通過WWW瀏覽器來實現，極少部分事務邏輯在前（Browser）實現，但是主要事務邏輯在伺服器端（Server）實現，形成所謂三層3-tier結構。這樣就大大簡化了客戶端電腦載荷，減輕了系統維護與升級的成本和工作量，降低了使用者的總體成本。
- B/S結構可以看作是瘦客戶端，只是把顯示的較少的邏輯交給了Web瀏覽器，事務邏輯資料處理在放在了Server端，這樣就避免了龐大的胖客戶端，減少了客戶端的壓力。B/S結構的系統無須特別安裝，只有Web瀏覽器即可。當然AJAXFlex等等的普遍使用也有富客戶端的發展方向。
（3）什麼是MVC設計模式？
-
MVC是Model View Controller，是模型(model)－檢視(view)－控制器(controller)的縮寫，一種軟體設計典範，用一種業務邏輯、資料、介面顯示分離的方法組織程式碼，將業務邏輯聚集到一個部件裡面，在改進和個性化定製介面及使用者互動的同時，不需要重新編寫業務邏輯。使用MVC應用程式被分成三個核心部件：模型、檢視、控制器。它們各自處理自己的任務。
- Model（模型），是程式的主體部分，主要包含業務資料和業務邏輯。在模型層，還會涉及到使用者釋出的服務，在服務中會根據不同的業務需求，更新業務模型中的資料。
- View(檢視），是程式呈現給使用者的部分，是使用者和程式互動的介面，使用者會根據具體的業務需求，在View檢視層輸入自己特定的業務資料，並通過介面的事件互動，將對應的輸入引數提交給後臺控制器進行處理。
- Controller（控制器），Controller是用來處理使用者輸入資料，已經更新業務模型的部分。控制器中接收了使用者與介面互動時傳遞過來的資料，並根據資料業務邏輯來執行服務的呼叫和更新業務模型的資料和狀態。MVC模式將它們分離以提高系統的靈活性和複用性，不使用MVC模式，使用者介面設計往往將這些物件混在一起。MVC模式實現了模型和檢視的分離。
任務4：以任務2的成果為基礎，使用Visio，應用物件導向設計（OOD）方法，撰寫團隊專案軟體系統設計說明書，以回答：軟體是如何實現使用者需求的？
（1）採用適合的軟體設計模式設計軟體系統總體結構；
（2）設計軟體系統資料庫邏輯結構；
（3）說明軟體重用方案；
（4）設計關鍵類的重點服務。
（5）採用OOD技術編制《XXX軟體設計說明書1.2》上傳到團隊專案Github倉庫的截圖
完成各項任務所花費的時間：
| 任務型別 | 預計花費時間(h) | 實際花費時間(4) |
|---|---|---|
| 任務一 | 0.3 | 0.5 |
| 任務二 | 4 | 6 |
| 任務三 | 0.25 | 0.3 |
| 任務四 | 6 | 8 |
| 任務五 | 3 | 3.5 |
對比陳述結構化軟體分析與設計、物件導向分析與設計兩類軟體開發技術的異同
-
相同點：
- 結構化開發方法和麵向物件的方法都是軟體系統的開發方法。
- 結構化開發方法和麵向物件的方法在運用分解和抽象原則上的要求是完全一致的。分解即化整為零，將問題剝繭抽絲，層層消化﹔抽象則是通過分解體現﹐在逐層分解時，上層是下層的抽象，下層是上層的具體解釋和體現，運用抽象可以不用一次考慮太多細節,而逐漸的有計劃有層次的瞭解更多細節。
- 區域性化和重用性設計上的一致。區域性化是軟體開發中的一個重要原則，即不希望軟體一部分過多地涉及或影響軟體的其它部分。而物件導向方法則採用資料﹑程式碼的封裝，即將資料﹑程式碼和操作方法封裝成一個類似“黑箱”的整體物件，提高了程式的可靠性和安全性，同時增強了系統的可維護性。也就是說物件導向方法比結構化方法的運用更加深入更徹底。
-
不同點：
- 結構化方法是一種面向資料流的開發方法，物件導向方法是一種物件導向的開發方法。
- 處理問題時的出發點不同。結構化方法是強調過程抽象化和模組化，以過程為中心構造或處理客觀世界問題的，它是一種程式導向的開發方法﹔物件導向方法強調把問題域的要領直接影射到物件及物件之間的介面上，是用符合人們通常的思維方式來處理客觀世界的問題。
- 處理問題的基本單位和層次邏輯關係不同。結構化方法把客觀世界的問題抽象成計算機可以處理的過程,處理問題的基本單位是能清晰表達過程的模組，用模組的層次結構概括模組或模組間的關係和功能﹔物件導向方法是用計算機邏輯來模擬客觀世界中的物理存在，以物件的集合類作為處理問題的基本單位，儘可能使計算機世界向客觀世界靠攏，以使問題的處理更直截了當，物件導向方法是用類的層次結構來體現類之間的繼承和發展。
實驗總結：
- 楊麗霞：本次團隊作業，首先是要學會Visio建模工具學習，然後用此工具設計系統軟體並且用物件導向設計方法對系統進行設計，由於初次接觸建模圖過程比較繁瑣，只能慢慢一步一步探索著學習，最後基本學會使用Visio繪圖軟體，發現它很方便也很使用也容易上手。從專案需求分析建模以及軟體系統設計後把畢業設計選題系統清晰明瞭地展現了出來，但這次不同的是應用物件導向設計方法，雖然在設計的過程中方存在很多的問題，但是經過和組員探討修改，初步完成了本次的模型設計。在我們組員同伴的分工明確和大家積極配合的情況下，我們順利完成了本次實驗，經歷了幾次團隊作業，慢慢地大家有了默契，任務完成也比較積極。
- 公海瑜：
- 張興盼：
- 陳來弟：