《软体设计整》PPT课件.ppt

1,第10章 軟體設計,2,本章大綱,10.1何謂軟體設計？,10.2軟體架構,10.3軟體設計的基本法則,10.4系統設計的方法,10.5設計時應注意事項,10.6 結語,3,學習目標,瞭解何謂軟體設計,瞭解何謂軟體架構,瞭解軟體設計的法則,瞭解軟體設計的法則,4,軟體設計是軟體工程技術的核心。設計是管理系統複雜度的活動；將複雜的事物，用一套清楚的架構加以統御，使之不致於失控。良好的設計可將系統化繁為簡，減少系統開發的成本，提高系統的可靠度。且具有簡單、容易維護、易於擴充及變更等屬性。不當的設計隨著時間的演化，系統會變得複雜而瑣碎，不只維護成本增加，系統的穩定性也隨之降低。且會導致不穩定的系統、不易測試及不易維護等問題。,何謂軟體設計？(1/4),軟體設計的意義,5,何謂軟體設計？(2/4),軟體工程是顧客或用戶提出需求，而工程師設法找出問題的解答。過程分為五個步驟：定義及描述問題（需求定義）。分析問題（需求分析）。尋找適當之解答（系統分析）。發展最佳的解決方案（系統設計）。實施解決方案（撰寫程式）。,軟體設計所處的階段,6,何謂軟體設計？(3/4),架構與風格：軟體有各種不同的架構類型，如資料流、貯藏庫、事件驅動、物件導向等，如何選擇牽涉到工程師的認知與信念，見仁見智，屬於價值觀或哲學的範疇。高階系統設計：包含發散與收斂兩個交互運用的過程，產出系統的概念架構。此時注重的是工程設計原則的運用與設計方法的實踐。在發散階段，思考所有可能的解決方案；而在收斂階段，比較方案的好壞、成本與限制，找出可優先選擇的方案。低階細部設計：即演算法的展開。,軟體設計的層次,7,何謂軟體設計？(4/4),資料模型：資料設計是要建立資訊系統背後的資料模型，以存放從應用領域裡所產生的資料。系統結構：結構設計主要任務是決定系統需要哪些構成元件，並定義出它們的角色與彼此間的連結關係。用戶介面：介面設計主要的任務，是安排系統的操作畫面與人機互動的方式。軟體元件：元件設計將系統結構中的元件，轉換成以程式語言描述的執行步驟。,軟體系統的概念性描述：,8,圖10.2 SWEBOK與軟體設計有關的議題,9,軟體架構(1/9),軟體架構：系統的基本組織，具體地表現在元件、元件對彼此與對環境間的關係，以及設計與演化的原則。軟體架構包含：一組用來執行系統功能的軟體元件。一組用來提供元件間溝通、協調與合作的連結器。一組描述元件間如何組成系統的限制。能夠讓設計者瞭解整個系統特性的語意模型。,10,軟體架構(2/9),結構：由多個元件所組織成的架構，元件被安排或組織起來的方式。框架：增加設計抽象化的層級，從相似的軟體中找出可重複使用的設計樣版，以提高設計的抽象層次。動態：著重在行為層面的程式架構，描述架構的動態行為。流程：著重在系統必須與企業的流程相互配合，描述系統的商業或技術流程。功能：表現系統功能面的階層關係，系統的功能階層組織。,軟體架構的描述的模型：,11,軟體架構(3/9),資料流（又稱為連接管與過濾器）：系統是由過濾器（元件）與連接管（連結器）所構成，在一個定義好的資料流上運作，過濾器負責資料的轉換並獨立運作；連接管則以串接的方式負責在過濾器間傳遞資料。,常見的軟體架構型態,12,圖10.3 連接管與過濾器示意圖,13,軟體架構(4/9),呼叫與回覆：呼叫與回覆架構的特色是控制流程隨著呼叫而轉移，中間包含資料（或參數）的傳遞，而被呼叫者執行完成後，控制權重新回到呼叫者。交互作用程序（又稱為間接呼叫）：透過事件與作業系統，間接地連結呼叫者與被呼叫者；而兩個交互作用的程序或物件雙方，不必知道對方的存在。本架構最大的好處，是元件再用與系統演化。缺點則是，宣告者元件無法知道誰會受到事件的影響、運算的順序、何時結束及資料交換問題。,14,軟體架構(5/9),系統架構會依功能或服務的不同，設計成多層系統，由外向內包覆（或由內向外擴充），每一層負責特定的功能，提供服務給它的上一層，同時扮演下一層的顧客。其優點是：符合軟體工程的原則、易於擴充與演化及非常適合設計再用。缺點則為：不是所有系統都可以用階層的方式設計、為了效能的考量，必須將邏輯上的高階函數與低階實作綁在一起，以及不容易找出適當的抽象階層。階層式系統的另一種類型是虛擬機架構。,階層式（又成多層式系統）：,15,軟體架構(6/9),架構特點是有一個共同分享的資料中心，與一組相互獨立的元件。包含兩種模式：儲藏庫：負責保存系統的狀態與資料，被動地等待元件對它的存取和運算。具永久儲存資料的特性。看板：發號施令的中心，各個元件會解讀看板的指示訊息，然後進行相關運算。通常應用在人工智慧系統。,資料導向倉庫（又稱資料中心架構）,16,圖10.5 儲存庫架構示意圖,17,軟體架構(7/9),每一種架構皆有其適用性，在開發系統前，設計者必須先瞭解系統的特性，才能依照需要挑選適當的架構進行系統開發。挑選的考量：共享相依：元件之間共用相同的資源。流程相依：類似生產者與消費者之間的相依性。限制性相依：代表一系列的活動中彼此之間的限制關係。,架構的選擇,18,軟體架構(8/9),架構設計範例：“Key Word In Context”以資料流、主副程式、物件導向及間接呼叫等四種不同風格設計的架構圖為例，如圖10.6(a)、10.6(b)、10.6(c)及10.6(d)所示。,19,圖10.6(a)資料流架構示意圖,20,圖10.6(b)主副程式架構示意圖,21,圖10.6(c)物件導向架構示意圖,22,圖10.6(d)間接呼叫架構示意圖,23,軟體架構(9/9),資料流架構的複雜度最低，而其它三者大同小異。以演算法的彈性來說，間接呼叫最佳，資料流其次，其餘二者較差。對於資料結構的彈性，物件導向最好、間接呼叫其次，其餘二者較差。至於系統效能，主副程式與物件導向最佳，其餘二者較差。對於功能的擴充性，主副程式與間接呼叫最佳，資料流其次，而物件導向較差。元件再用則是間接呼叫與資料流較好、物件導向其次，而主副程式最差。,綜合而言：,24,軟體設計的基本法則(1/9),分解與征服是一項傳統的解題智慧，將不易處理的問題，經過分解之後，簡化成更簡單的問題，然後再各個破解。抽象化將一個實體或活動模型化，只表達其中重要的事物與屬性，排除或隱藏與目的無關的細節，簡化事情的複雜度。讓人專注在一般性概念的層次上，而無須費心於不相關的細節，以便問題的全貌得以呈現，避免見樹不見林的缺點。,軟體設計的基本法則,25,軟體設計的基本法則(2/9),模組化將系統模組化，意味著將系統分解成由簡單、相對獨立的組件所構成的集合。良好的模組化好處：降低系統複雜度、易於組裝、維護與再利用、減少溝通負荷、便於團隊合作、具有彈性，以及容易瞭解。模組化誤用的弊端，將不該分割的部位，強加分割，反而會升高而非降低系統的複雜度，不只無法獲取好處反而製造了問題。模組化的目的：將複雜的系統簡單化。,26,軟體設計的基本法則(3/9),檢驗模組化的好壞，其標準是模組的功能獨立性；決定模組功能獨立性的兩項指標為：內聚力：衡量模組執行唯一單項功能的程度，愈高愈能適應未來的變動與演化。耦合度：衡量模組之間相依的程度，耦合力愈低，表示模組變動的自由度愈高。,27,軟體設計的基本法則(4/9),內聚力由低到高分為：巧合：模組內的零件只是碰巧在一起。邏輯相關：相似功能的元件聚集在一起。時間附著：同時啟動的元件聚集在一起。程序附著：程序相接的元件聚集在一起。溝通附著：模組內的零件接受相同的輸入，並產生相同的輸出。順序附著：模組內一部分零件的輸出，是另一部分的輸入。功能附著：模組內的每一部分零件，都是為了執行某個特定的功能所必要的。物件附著：每一項功能或運算，都是為了物件本身屬性的修改或查詢（但是繼承會弱化內聚力）。,28,軟體設計的基本法則(5/9),耦合度由低到高分為：資料：模組間的資料分享透過參數進行。戳記：模組間共享一個複合的資料結構，彼此不知道對方會使用其中的哪一部分。控制：其中一個模組控制另一個的執行邏輯，並且告訴它該怎麼做。外部：模組間共享一個外部資料格式、通訊協定、設備介面等。共同：模組間共享同一個全域變數。內容：一個模組會修改或依賴另一個模組內部的工作細節。,29,軟體設計的基本法則(6/9),模組化雖可將一個複雜系統分解成簡單並易於處理的組件，但並非愈多模組愈好。任何東西都是有成本的，所以最佳的決策，通常落在兩個極端的中間。模組化亦復如是，過度地分解，會增加系統整合的成本，因此，兩者之間應取得一個平衡（如圖10.8）。,30,圖10.8 軟體成本與模組化之間的平衡,31,軟體設計的基本法則(7/9),逐步精細化是將抽象化的物件逐漸加入細節，以展現其具體的樣貌。功能分解或者結構化程式設計，就是此一準則的應用。逐步精細化的優點是符合直覺，適合用來設計演算法。但是並非所有問題都適合由上向下展開，尤其是複雜度主要與資料有關的問題，反而會產生不良的副作用。本方法也不必然導致好的模組化，因為是否建立副程式是獨立判斷的決定。,32,軟體設計的基本法則(8/9),資訊隱藏將模組內的資訊隱藏有許多好處，例如，降低模組間的耦合度，使得出現意外副作用的可能性降低；侷限區域內的設計決策對全體的影響；以及減輕人員的資訊超載，減少設計或瞭解系統所必須知道的資訊等。資訊隱藏的設計，強調經由受控制的介面進行通訊，避免使用全域變數或資料。不僅資訊隱藏，模組內部的執行細節也被封裝起來，避免外部任何直接的存取。,33,圖10.10 資訊隱藏的模組設計,演算法資料結構外部介面的細節資料使用的規範,34,軟體設計的基本法則(9/9),繼承是一種設計再用的機制，也是一個降低系統複雜度的好方法。透過繼承，可將原本複雜的事務加以歸納與整理。另一個好處，是改進系統承受變動的能力。透過繼承使用，元件可以被再定義，以適應變動的需要，而不必修改原始設計。過度使用繼承會增加系統的複雜度，且某種程度上破壞了模組化的價值。因此應避免過長的繼承路徑，且進行定期檢討與結構的重整。,35,軟體設計的基本法則(1/10),功能導向設計（或者又稱為結構化設計）：藉由對問題的分解，從概括著手，逐步由上而下將問題展開；如同建築師先構造出事物的整體，然後逐漸精細化，發展出構造的每個細節。物件導向設計：從資料與程序的抽象化入手，藉著資訊隱藏來避免複雜度的問題；先勾勒出物件架構的基本模型，然後向上組合發展出系統的樣貌。,目前最成熟的兩種軟體設計方法,36,系統設計的方法(2/10),功能導向設計的基本精神，是從系統應具備的功能角度切入，利用資料流程圖為工具，描繪系統的實際作業現況，或概念上的邏輯模型。此一方法的特色，是可由粗略到精細，從上到下逐步分解，將大略的作業（或問題）分解成較小型的作業，並重複上述的動作，直到有關細節都已浮現為止。資料流程圖藉由描述資料的流向，說明系統中各個處理單元與資料之間的關係。,功能導向設計,37,系統設計的方法(3/10),外部實體（終結者、來源、目的）：以長方形或橢圓形表示，代表資料的來源或消失處。屬於系統模型之外，不必知道它是什麼或如何產生。處理單元：以圓形或圓角長方形表示，將流進的資料予以加工後流出。資料流：以箭頭表示，描述資料在任意兩個系統元件之間的流向。資料站：以兩條平行線（有時左端的開口會封起來）表示，代表資料暫時停留之處，停留時間可長可短。,資料流程圖由下列元件組成,38,圖10.11 資料流範例圖,39,系統設計的方法(4/10),優點:易於溝通、符號容易學習、不需要軟體專業知識、可清楚地定義系統範圍，並內含抽象化與模組化的設計法則。同一套工具可用於描述問題現況，以及對未來的系統期望。缺點:隨著系統的成長，系統易於過度複雜。,資料流程圖（DFD）,40,系統設計的方法(5/10),交易分析：所產生的結構圖，其副程式模組各自功能獨立。轉換分析：產生的副程式模組會被依序呼叫，以共同完成某項任務。轉換的步驟為：決定主要的資訊流（由輸入到輸出的主要流程）。找出其中負責最基礎運算的處理單元。重畫DFD，將輸入放在左邊而輸出放在右邊，中間是該處理單元。重畫資料流以產生結構圖初稿。,結構化方法提供的方式：,41,圖10.12 從資料流程圖轉換成模組結構圖,42,結構化設計的特色：以系統的邏輯模型為基礎，借助一套標準的設計準則與圖表等工具，逐層地將系統分解成多個大小適當、功能單一、具有一定獨立性的模組，把一個複雜的系統轉換成易於實現、易於維護的模組化結構。優點：系統開發的整體性和全局性；在整體考量的前提下分析及設計系統。開發流程清楚易懂，在專案上易於分階段管理。缺點：系統缺乏彈性，對於功能演化的適應性不佳。,系統設計的方法(6/10),43,早期的資料導向設計，以資訊工程方法為代表。經過長時間的演變，如今融入到物件導向方法中，並演化出完整的符號體系與方法論。物件導向方法有著許多優點，例如，可重複使用、高度模組化等。但其缺點，為系統易流於過度龐雜、結構鬆散。,系統設計的方法(7/10),物件導向設計,44,資訊的保留：候選物件的資訊必須被記住，才能使系統正常工作。必要的服務：候選物件擁有一組可標識的操作，而它們可以用某種方式修改物件屬性的值。包含多個屬性：單一或少量屬性的候選者，可被其它物件所包含，不需要獨立出來。共同屬性：候選物件擁有一組可被定義的共同屬性。共同操作：候選物件擁有一組可被定義的共同操作。基本需求：如，出現在問題領域的外部實體、生產或消費任何系統解決方案中運算所需的資訊等，都是必要的。,系統設計的方法(8/10),物件篩選的條件：,45,系統設計的方法(9/10),子系統層：包含每個子系統的描述，這些子系統使得系統能夠滿足顧客的需求，並實現支援顧客需求的基礎技術設施。類別與物件層：使得系統能以通用化方式建構，再逐漸趨近個別需求，這一層也包含了物件的設計。信息層：描述物件和其協作者之間溝通的細節，本層建立了系統的外部和內部介面。責任層：設計各個物件的屬性和操作的資料結構與演算法。,物件導向設計應包含的層次,46,系統設計的方法(10/10),目前軟體界的主流設計思想是物件導向方法。但是沒有任何設計是絕對的好或壞，端看如何應用而定。除了上述介紹的方法之外，實務上其實還存在著許多其它各式各樣的設計方法。,47,設計時應注意事項(1/3),不受到隧道視野的限制：應分析問題的本質，考慮各種替代手段、可能的變化與周邊需求。儘縮短軟體與實際問題間的智力距離：概念表達上的轉換，不止構成認知上的負擔，也會增加系統的複雜度，並形成錯誤的溫床，所以軟體系統的結構設計，應儘量類比於問題域的結構。必需是可追蹤的：因為系統的性能與問題需求間不是一對一的關係，有時一項性能會對應到多個需求上，所以設計模型如何滿足問題的需求，必需是可追蹤的。,軟體設計時應注意的事項：,48,設計時應注意事項(2/3),保持一致性和整體性：如果一項設計看上去像是一個人所完成的，那麼它就是一致的。由設計者負責整體的系統結構，其餘的從旁協助。在設計工作開始之前，開發團隊應先定義設計風格和樣式的規則。具備彈性以容納修改：軟體開發唯一不變的真理，就是變。所以好的設計應儘量提高系統彈性，以適應未來的改變。避免從頭做起：時間短暫而資源有限，設計應儘可能重用一些好的設計樣版或系統元件，將時間投入到真正需要構思和整合的元件上。,軟體設計時應注意的事項：,49,設計時應注意事項(3/3),進行品質評估：軟體最困難的就是不可見性，應思考如何讓系統的品質很容易被驗證。,軟體設計時應注意的事項：,50,設計是一項管理複雜度的活動，設計的品質決定系統的品質。可將軟體設計得很簡單，也可以很複雜，端看功力而定。化簡為繁是容易的；反之，化繁為簡則很困難。今日多人採用RUP或MSF等多循環式的軟體開發流程，強調快速實作，固然有其優點，相對的風險：系統可能缺乏清楚的架構設計、導致系統複雜度快速增加，造成後期開發與維護上的困難。相對地，如果事前有良好的規劃與設計，更能夠做到事半功倍，這只是取捨的問題。,結語,