第10章体设计

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