實驗十軟件系統詳細設計與概要設計的改進

時間 2019-12-14

標籤實驗軟件系統詳細設計概要改進简体版

原文原文鏈接

1、團隊項目系統設計改進：java

面向對象設計（Object-Oriented Design，OOD）方法是OO方法中一箇中間過渡環節。其主要做用是對OOA分析的結果做進一步的規範化整理，以便可以被OOP直接接受。
OOD的主要工做有：
1. 問題域部分的設計：
問題域部分的設計是任何OOD方法都必須完成的工做,它主要是對OOA結果進行改進和精化,並將其由問題域轉化到解域,具體來講,有如下幾個方面:
• 屬性:有些屬性在分析階段有助於問題的理解,而到了設計階段則能夠由其餘屬性導出或根本不必保留。所以,應將它們去掉。相反地,爲了實現服務算法還須要增長相應的一些屬性。
• 服務:OOA只給出了服務的接口,其具體實現算法要在OOD階段完成。
• 類及對象:在OOA階段有助於問題理解的一些類在OOD階段成爲冗餘,須要刪除,而爲了優化調整繼承關係還要增長一些類。全部的類都肯定之後還要明確哪些類的對象會引起哪些類建立新對象。
• 結構:對類間結構進行優化調整。
• 對象行爲:明確對象間消息傳遞的實現算法,依據動態模型肯定對象間消息發送的前後順序,並設計相應算法,協調對象的行爲。
2. 人機交互與應用控制部分的設計：
有些設計方法並無提到交互界面的設計,一方面是由於這些系統中交互界面不十分重要;另外一方面是由於這部分的設計頗有規律,設計方法也比較成熟,但爲完整起見,仍將其列出。主要工做包括:
（1）交互界面子系統的設計:與界面有關的類及類間結構的設計,以及有關算法的設計。
（2）交互界面子系統和應用之間接口的設計
（3）應用控制部分的設計:這部分對象主要完成應用的驅動工做。這部分對象不一樣於從現實世界中抽象出來的對象,在現實世界和問題域中沒有原型,它們同界面子系統中的對象及問題對象發生做用,控制系統的運行。

OOA與OOD的區別
因爲OOA和OOD的劃分沒有公認的標準,有些工做是在OOA階段完成仍是在OOD階段完成還存在着爭議。有人認爲OOA和OOD能夠交叉進行;有人認爲OOD是對OOA結果的改進和細化,因此只提OOA;有人則更強調OOD。儘管OOA和OOD存在着某些交叉和聯繫,但它們之間仍有許多差異,如:
1. OOA將現實世界中的實體抽象爲問題對象,並構造問題域中的系統需求模型;OOD將問題對象轉化爲解域中的類並在解域中構造出問題的解。
2. OOA側重於用戶需求的分析和對問題域的理解,分析人員關心的是系統結構及對象間的關係;OOD則側重於系統的實現,設計人員關心的是對象的行爲及其實現。
3. OOA標識了一組對象,並經過其相互做用來刻劃系統,該階段的工做與程序設計語言無關;OOD定義了一組類,並設計出系統的實現藍圖,概要設計與程序設計語言無關,但詳細設計則與之有比較密切的聯繫。
4. OOA識別的對象是對客觀世界實體的抽象,標識對象的準則是:該對象的引入是否有助於對問題域的理解;OOD中構造類的準則是:該類的構造是否可行,是否有效地實現了抽象數據類型,是否有助於系統的實現和提升軟件質量。
5. 兩個階段都沒有說起系統對象,但緣由不一樣。在OOA階段,分析與實現無關,分析所涉及的範圍與解域無關,系統對象天然不用考慮。OOD創建的對象模型自己就是要設計的軟件系統,對系統對象的考慮是隱含的。
6. 組裝結構和分類結構在兩個階段所起的做用不一樣。在OOA階段,它們的引入主要是爲了理解問題;而在OOD階段,它們的引入則主要是針對軟件的構造和實現。分類結構經過繼承機制來實現,於是代碼獲得了有效地複用;組裝結構則將一些類組合在一塊兒構成較大的軟件構件。
7. OOA並無考慮對象的產生問題,當其對應的實體在現實世界中出現時,它也就在問題域中產生了。OOA也不考慮對象屬性的取值和服務算法的實現。而在OOD階段這些問題都必須詳細考慮。
8. OOD涉及到重載問題;而OOA沒有考慮,由於考慮過多的實現細節對理解問題和分析用戶需求沒有多大幫助。

本次實驗中，咱們團隊基於對OOA與OOD的區別對《軟件系統概要說明書》中的系統設計模型進行了完善，包括E-R圖和狀態圖，並加入了系統流程圖。在上一次的《軟件系統概要說明書》中軟件系統結構模型的建模設計作的不夠完善，項目系統結構的總體設計不夠全面。咱們對上一次的系統設計模型圖進行了改進與完善，加入了系統流程圖。本來的系統設計模型圖描述了項目的功能做用，沒有展現出項目的設計流程和實現路線圖，改善後的流程圖加入了設計實現路線，對於系統功能進行了更爲詳細的展現。咱們也對文檔中存在的錯誤以及文字描述不許確的地方進行了修改。並將改進後《軟件系統概要說明書》發佈在團隊Github倉庫中。
改進的《軟件系統設計說明書》在Github倉庫中的連接：https://github.com/FBGfbg/xuqiu

2、團隊項目系統詳細設計的建模：

系統整體設計圖：

系統流程圖：

3、撰寫《軟件系統詳細設計說明書》

參考國標GB8567——88中《軟件系統詳細設計說明書》格式，撰寫團隊項目軟件系統詳細設計說明書，文檔要求使用一致的圖形符號和文字描述內容，將該文檔上傳到團隊項目Github倉庫。

《軟件系統詳細設計說明書》在Github倉庫中的連接：https://github.com/FBGfbg/xuqiu

4、六個問題

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

軟件體系結構是具備必定形式的結構化元素，即構件的集合，包括處理構件、數據構件和鏈接構件。處理構件負責對數據進行加工，數據構件是被加工的信息，鏈接構件把體系結構的不一樣部分組合鏈接起來。這必定義注重區分處理構件、數據構件和鏈接構件，這一方法在其餘的定義和方法中基本上獲得保持。

軟件設計模式（Design pattern），又稱設計模式，是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。毫無疑問，設計模式於己於他人於系統都是多贏的；設計模式使代碼編制真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結構同樣。設計模式主要分三個類型:建立型、結構型和行爲型。

建立型模式：單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式。
結構型模式：適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。
行爲型模式：模版方法模式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式（Interpreter模式）、狀態模式、策略模式、職責鏈模式(責任鏈模式)、訪問者模式。

二、什麼是C/S與B/S結構？git

C/S結構(Client/Server結構)是你們熟知的客戶機和服務器結構。它是軟件系統體系結構，經過它能夠充分利用兩端硬件環境的優點，將任務合理分配到Client端和Server端來實現，下降了系統的通信開銷。目前大多數應用軟件系統都是Client/Server形式的兩層結構，因爲如今的軟件應用系統正在向分佈式的Web應用發展，Web和Client/Server 應用均可以進行一樣的業務處理，應用不一樣的模塊共享邏輯組件；所以，內部的和外部的用戶均可以訪問新的和現有的應用系統，經過現有應用系統中的邏輯能夠擴展出新的應用系統。這也就是目前應用系統的發展方向。github

B/S結構（Browser/Server，瀏覽器/服務器模式），是WEB興起後的一種網絡結構模式，WEB瀏覽器是客戶端最主要的應用軟件。這種模式統一了客戶端，將系統功能實現的核心部分集中到服務器上，簡化了系統的開發、維護和使用。客戶機上只要安裝一個瀏覽器（Browser英 ['braʊzə]美 ['braʊzɚ]），如Netscape Navigator或Internet Explorer，服務器安裝SQL Server、Oracle、MYSQL等數據庫。瀏覽器經過Web Server 同數據庫進行數據交互。算法

B/S（瀏覽器/服務器模式)是隨着Internet的興起，對C/S結構的一種改進。在這種結構下，軟件應用的業務邏輯徹底在應用服務器端實現，用戶表現徹底在Web服務器實現，客戶端只須要瀏覽器便可進行業務處理，是一種全新的軟件系統構造技術。這種結構更成爲當應用軟件的首選體系結構。數據庫

三、什麼是MVC設計模式？編程

MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典範，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯彙集到一個部件裏面，在改進和個性化定製界面及用戶交互的同時，不須要從新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。MVC指MVC模式的某種框架，它強制性的使應用程序的輸入、處理和輸入分開。使用MVC應用程序被分紅三個核心部件：模型、視圖、控制器。它們各自處理本身的任務。最典型的MVC就是JSP +servlet+javabean的模式。設計模式

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

模型：模型持有全部的數據、狀態和程序邏輯。模型獨立於視圖和控制器。服務器

視圖：用來呈現模型。視圖一般直接從模型中取得它須要顯示的狀態與數據。對於相同的信息能夠有多個不一樣的顯示形式或視圖。網絡

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

MVC模式將它們分離以提升系統的靈活性和複用性，不使用MVC模式，MVC模式實現了模型和視圖的分離，用戶界面設計每每將這些對象混在一塊兒。

四、結合項目系統設計體驗，簡要說明一、二、3的內容與軟件系統設計的關係。

（1）軟件體系結構貫穿於軟件研發的整個生命週期內，具備重要的影響。對軟件體系結構風格的研究和實踐促進了對設計的複用，一些通過實踐證明的解決方案也能夠可靠地用於解決新的問題。體系結構風格的不變部分使不一樣的系統能夠共享同一個實現代碼。只要系統是使用經常使用的、規範的方法來組織，就可以使別的設計者很容易地理解系統的體系結構。例如，若是某人把系統描述爲"客戶/服務器"模式，則沒必要給出設計細節，咱們馬上就會明白系統是如何組織和工做的。

（2）軟件設計模式使代碼編制真正工程化；設計模式是軟件系統設計的基石脈絡，如同大廈的結構同樣。設計模式令人們能夠更加簡單方便地複用成功的設計和體系結構。將已證明的技術表述成設計模式也會使新系統開發者更加容易理解其設計思路。

（3）C/S結構，B/S結構是一種的軟件系統構造技術。

（4）MVC設計模式有利軟件工程化管理。因爲不一樣的層各司其職，每一層不一樣的應用具備某些相同的特徵，有利於經過工程化、工具化管理程序代碼。控制器也提供了一個好處，就是可使用控制器來聯接不一樣的模型和視圖去完成用戶的需求，這樣控制器能夠爲構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器能夠根據用戶的需求選擇模型進行處理，而後選擇視圖將處理結果顯示給用戶。

（5）MVC設計模式增長系統結構和實現的複雜性。對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增長結構的複雜性，並可能產生過多的更新操做，下降運行效率。

五、詳細設計的常見工具備哪些？

（1）程序流程圖。程序流程圖又稱爲程序框圖，是使用最普遍然而也是用得最混亂的一種描述程序邏輯結構的工具。它用方框表示一個處理步驟，菱形表示一個邏輯條件，箭頭表示控制流向。其優勢是：結構清晰，易於理解，易於修改。缺點是：只能描述執行過程而不能描述有關的數據。
（2）盒圖。盒圖是一種強制使用結構化構造的圖示工具，也稱爲方框圖。其具備如下特色：功能域明確、不可能任意轉移控制、很容易肯定局部和全局數據的做用域、很容易表示嵌套關係及模板的層次關係。
（3）PAD圖。。PAD是一種改進的圖形描述方式，能夠用來取代程序流程圖，比程序流程圖更直觀，結構更清晰。最大的優勢是可以反映和描述自頂向下的歷史和過程。PAD提供了5種基本控制結構的圖示，並容許遞歸使用。PAD的特色有：使用PAD符號設計出的程序代碼是結構化程序代碼；PAD所描繪的程序結構十分清晰；用PAD圖表現程序的邏輯易讀、易懂和易記；容易將PAD圖轉換成高級語言源程序自動完成；便可以表示邏輯，也可用來描繪數據結構；支持自頂向下方法的使用。
（4）PDL。PDL也可稱爲僞碼或結構化語言，它用於描述模塊內部的具體算法，以便開發人員之間比較精確地進行交流。語法是開放式的，其外層語法是肯定的，而內層語法則不肯定。外層語法描述控制結構，它用相似於通常編程語言控制結構的關鍵字表示，因此是肯定的。內層語法描述具體操做，考慮到不一樣軟件系統的實際操做種類繁多，內層語法於是不肯定，它能夠按系統的具體狀況和不一樣的設計層次靈活選用，實際上任意英語語句均可用來描述所需的具體操做。用它來描述詳細設計，工做量比畫圖小，又比較容易轉換爲真正的代碼。PDL的優勢：能夠做爲註釋直接插在源程序中；可使用普通的文本編輯工具或文字處理工具產生和管理；已經有自動處理程序存在，並且能夠自動由PDL生成程序代碼。PDL的不足：不如圖形工具形象直觀，描述複雜的條件組合與動做間對應關係時，不如斷定樹清晰簡單。
六、如何繪製符合規範的流程圖？

流程圖是揭示和掌握封閉系統運動情況的有效方式。做爲診斷工具，它可以輔助決策制定，讓管理者清楚地知道，問題可能出在什麼地方，從而肯定出可供選擇的行動方案。繪製流程圖的習慣作法是：事實描述用橢圓形表示行動方案用矩形表示問題用菱形表示箭頭表明流動方向。使用流程圖須要考慮不少問題，如：過程當中是否存在某些環節，刪掉它們後可以下降成本或減小時間？還有其餘更有效的方式構造該流程嗎？整個過程是否由於過期而須要從新設計？應當將其徹底廢棄嗎？

詳細狀況請看連接：https://github.com/FBGfbg/xuqiu

團隊成員分工：

姓名	分工	比例	時間
馬美玲	撰寫博客內容、查找、編寫6個問題、任務二、編寫登錄註冊、課本選擇界面代碼	45%	一週
馬玉婷	撰寫《軟件系統詳細設計說明書》、博客內容、編寫年紀選擇、課程選擇界面代碼	45%	一週
益西卓嘎	改善項目系統設計說明書初稿的不足	10%	兩天