河北工業(yè)大學軟件工程教師課件第四節(jié)軟件設計

1、第四講 設計工程（Design Engineering）Welcome to Software EngineeringLecture 4Zhang JPage 2目標：n 掌握設計工程的基本知識；n 了解基本的體系結構設計方法和模型；n 了解構件級設計的基本原則與方法； n 掌握用戶界面設計的一些原則與基本設計活動。 Page 3內(nèi)容n 設計工程n 體系結構設計n 構件設計n 用戶界面設計n 設計文檔與有效性驗證Page 4 1 設計工程1.1 軟件工程中的設計 設計是一個把問題轉換成解決方案的創(chuàng)造性過程； 設計解決的是“如何實現(xiàn)系統(tǒng)”的問題； 從工程管理的角度，軟件設計可以分成概要設計（總體

2、設計、系統(tǒng)設計）與細節(jié)設計（詳細設計）Page 5設計的重要性n設計提供了軟件的表示，使得軟件的質量評價成為可能。設計提供了軟件的表示，使得軟件的質量評價成為可能。n軟件設計是將用戶要求準確地轉化成為最終軟件產(chǎn)品的唯軟件設計是將用戶要求準確地轉化成為最終軟件產(chǎn)品的唯一途徑。一途徑。n軟件設計在軟件過程中處于技術核心，它是建?；顒拥淖钴浖O計在軟件過程中處于技術核心，它是建?；顒拥淖詈笠粋€軟件工程活動后一個軟件工程活動，是后續(xù)開發(fā)步驟及軟件維護工作的，是后續(xù)開發(fā)步驟及軟件維護工作的基礎。基礎。 如果沒有設計，建立的將是一個不穩(wěn)定的系統(tǒng)如果沒有設計，建立的將是一個不穩(wěn)定的系統(tǒng) ：Page 6設計的

3、重要性Programs no design just like buildings no blueprintPrograms no design just like buildings no blueprint咋還要圖呢？Page 7從分析模型到設計模型Page 8從分析模型到設計模型Anal ysi s M odeluse-cases - text use-case di agram s acti vi ty di agram s swi m l ane di agram sdata fl ow di agram s control -fl ow di agram s processi ng

4、 narrati vesf fl lo o w w - -o o r ri ie e n n t te e d d e e l le e m m e e n n t ts sb b e e h h a a v v i io o r ra a l le e l le e m m e e n n t ts sc c l la a s ss s- -b b a a s se e d de e l le e m m e e n n t ts ss sc c e e n n a a r ri io o - -b b a a s se e d de e l le e m m e e n n t ts sc

5、l ass di agram s anal ysi s packages CRC m odel s col l aborati on di agram s state di agram s sequence di agram sD D a a t ta a / / C C l la a s ss s D D e e s si ig g n nA A r rc c h h i it te e c c t tu u r ra a l l D D e e s si ig g n nI In n t te e r rf fa a c c e e D D e e s si ig g n nC C o o

6、 m m p p o o n n e e n n t t- - L L e e v v e e l l D D e e s si ig g n nDesi gn M odelPage 91.2 設計概念1.2.1 1.2.1 模塊化模塊化 easier to build, easier to change, easier to fix .Page 101.2.1 1.2.1 模塊化模塊化n 在計算機軟件領域，模塊化的概念已被推崇了近四十年。目前，幾乎所有的軟件體系結構都體現(xiàn)了模塊化的思想，即把軟件劃分為可獨立命名和編址的構件，每個構件稱為一個模塊模塊，每個模塊完成一個子功能，當把所有模塊組裝到

7、一起成為一個整體時，便可以完成指定的功能。n 模塊組成系統(tǒng)或子系統(tǒng)。n “一個復雜問題分割成若干個容易解決、容易管理的小問題后更易于求解”，模塊化正是以此為依據(jù)把系統(tǒng)劃分成若干個模塊，各個擊破。 Page 11模塊劃分與成本模塊劃分與成本n 如果模塊是相互獨立的，模塊越小，每個模塊的工作量越少；但當模塊數(shù)增加時，模塊間的聯(lián)系隨之增加，把這些模塊聯(lián)接起來的工作量也隨之增加。Page 121.2.2 1.2.2 信息隱藏與獨立性信息隱藏與獨立性n 信息隱藏原理信息隱藏原理：模塊應該設計得使其所含信息（過程和數(shù)據(jù)）對于那些不需要這些信息的模塊來說不可訪問；每個模塊只完成一個相對獨立的特定功能；模塊之

8、間僅交換那些為完成系統(tǒng)功能必須交換的信息，即模塊應該功能獨立的。 n 采用信息隱藏原理指導模塊設計有很多好處：采用信息隱藏原理指導模塊設計有很多好處： 1）它支持模塊的并行開發(fā)； 2）減少測試和后期維護的工作量。因為測試和維護階段不可避免地要修改設計和代碼，模塊對大多數(shù)數(shù)據(jù)和過程處理細節(jié)的隱藏可以減少錯誤向外傳播。 3）整個系統(tǒng)擴充功能只需“插入”新模塊，原有的多數(shù)模塊無須改動。 Page 131.2.2 1.2.2 信息隱藏與獨立性信息隱藏與獨立性Page 14模塊獨立性（模塊獨立性（IndependencyIndependency）n 如果說，一個模塊在不需要另一個模塊的情況下，能夠完整地

9、執(zhí)行其功能，我們就稱這兩個模塊是完全獨立的。n 模塊獨立性的概念是模塊化、抽象和信息隱藏概念的直接產(chǎn)物，模塊獨立性是通過開發(fā)具有“專一”功能和“避免”與其他模塊過多交互作用的模塊來達到的。 n 模塊獨立性可用兩個定性準則來度量：耦合性耦合性（coupling）和內(nèi)聚性內(nèi)聚性（cohesion）。n 耦合是模塊之間相對獨立性的量度，而內(nèi)聚則是模塊功能相對強度的量度。 Page 15耦合性（耦合性（couplingcoupling）n 耦合性是對軟件程序結構中各個模塊之間相互關聯(lián)程度的一種度量。n 耦合的強弱取決于模塊間接口的復雜性、進入或調用模塊的位置、方式以及通過接口傳送數(shù)據(jù)的多少等。n 在設

10、計軟件時應追求盡可能松散耦合松散耦合的系統(tǒng)。因為對這類系統(tǒng)中任一模塊的設計、測試和維護相對獨立。由于模塊間聯(lián)系較少，錯誤在模塊間傳播的可行性也隨之變小。模塊間的耦合程度直接影響系統(tǒng)的可理解性、可測試性、可靠性和可維護性。 Page 16內(nèi)聚性（內(nèi)聚性（cohesioncohesion）n 內(nèi)聚是信息隱藏和局部化概念的自然擴展，它標志一個模塊內(nèi)部各成分彼此結合的緊密程度。 n 內(nèi)聚和耦合是相互關聯(lián)的。在程序結構中各模塊的內(nèi)聚程度越高，模塊間的耦合程度就越低。但這也不是絕對的。n 軟件概要設計的目標是力求增加模塊的內(nèi)聚，盡量減少模塊間的耦合。但增加內(nèi)聚比減少耦合更重要，應當把更多的注意力集中到提高

11、模塊的內(nèi)聚程度上來。 Page 171.2.3 1.2.3 抽象抽象n 人類在認識復雜現(xiàn)象的過程中使用的最強有力的思維工具就是抽象抽象。人們在實踐中認識到，在現(xiàn)實世界中一定事物、狀態(tài)或過程之間總存在著某些相似的方面（共性）。n 把這些相似的地方集中和概括起來，暫時忽略它們之間的差異，這就是抽象?；蛘哒f，抽象就是抽出事物的本質特性而暫時不考慮它們的細節(jié)。n 一個復雜的動態(tài)系統(tǒng)首先可以用一些高級的抽象概念構造和理解，這些高級概念又可以用一些較低級的概念構造和理解，如此進行下去，直至最低層次的具體元素。 n 軟件工程過程的每一步都是對較高一級抽象的解作一次較具體化的描述。 Page 18過程抽象與數(shù)

12、據(jù)抽象過程抽象與數(shù)據(jù)抽象implemented with a knowledge of the object that is associated with enterPage 19過程抽象與數(shù)據(jù)抽象過程抽象與數(shù)據(jù)抽象implemented as a data structurePage 20 “逐步求精”是與“抽象”密切相關的一個概念，它由N.Wirth提出，可視為一種早期的自頂向下設計策自頂向下設計策略略，其主要思想是：針對某個功能的宏觀描述，用逐步求精的方法不斷地分解，逐步確立過程細節(jié)，直至該功能用程序語言描述的算法實現(xiàn)為止。 因為求精的每一步都是用更為詳細的描述替代上一層次的抽象描述，

13、所以在整個設計過程中產(chǎn)生的、具有不同詳細程度的各種描述，組成了系統(tǒng)的層次結構。層次結構的上一層是下一層的抽象，下一層是上一層的求精。 1.2.1.2.4 4 逐步求精（細化）逐步求精（細化） Page 21openwalk to door;reach for knob;open door;walk through;close door.repeat until door opensturn knob clockwise;if knob doesnt turn, then take key out; find correct key; insert in lock;endifpull/push

14、doormove out of way;end repeat1.2.1.2.4 4 逐步求精（細化）逐步求精（細化） Page 221.3 設計過程活動n 體系結構設計n 抽象描述n 接口設計n 組件設計n 數(shù)據(jù)結構設計n 算法設計Page 23軟件設計過程Page 242. 體系結構設計n 體系結構（architecture,又稱架構）設計的任務是要識別出組成系統(tǒng)的子系統(tǒng)并建立子系統(tǒng)的控制和通信框架。n 體系結構設計的輸出是軟件體系結構的描述。n 體系結構設計是聯(lián)系需求描述與其他設計活動的橋梁。Page 25進行體系結構設計的好處n 有利于有利于Stakeholders之間進行溝通之間進行溝

15、通nArchitecture may be used as a focus of discussion by system stakeholders.n 有利于系統(tǒng)分析有利于系統(tǒng)分析nMeans that analysis of whether the system can meet its non-functional requirements is possible.n 有利于大規(guī)模復用有利于大規(guī)模復用nThe architecture may be reusable across a range of systems.Page 26體系結構與系統(tǒng)特性n 性能n Localize crit

16、ical operations and minimise communications. Use large rather than fine-grain components.n 保密性n Use a layered architecture with critical assets in the inner layers.n 安全性n Localize safety-critical features in a small number of sub-systems.n 可用性n Include redundant components and mechanisms for fault t

17、olerance.n 可維護性n Use fine-grain, replaceable components.Page 27體系結構之間的沖突n Using large-grain components improves performance but reduces maintainability.n Introducing redundant data improves availability but makes security more difficult.n Localizing safety-related features usually means more communi

18、cation so degraded performance.Page 282.1 系統(tǒng)構成n 體系結構設計的第一個階段通常是將一個系統(tǒng)分解成一組相互作用的子系統(tǒng)系統(tǒng)構成。n 通?？梢圆捎梅綁K圖來描述系統(tǒng)結構的概況，而用其它的一些特別模型來表示子系統(tǒng)如何分享數(shù)據(jù)，如何分配功能以及連接方式Page 29例：打包機器人控制系統(tǒng)Page 30方塊圖的特點n 非常抽象-不顯示組件之間的本質關系和子系統(tǒng)的外部特征，只給出系統(tǒng)構成的高層抽象；n 有利于不同層次的系統(tǒng)參與人員進行交流與溝通。Page 31體系結構設計決策n 體系結構設計是一個創(chuàng)造性的過程，所以不同類型的系統(tǒng)的設計過程與設計活動是不盡相同的。

19、n 然而，在體系結構設計過程中的一些問題的研究是適合所有系統(tǒng)設計的，因此從問題決策角度看待體系結構設計比從活動角度看待它更加有效。Page 32n Is there a generic application architecture that can be used?n How will the system be distributed?n What architectural styles are appropriate?n What approach will be used to structure the system?n How will the system be decomp

20、osed into modules?n What control strategy should be used?n How will the architectural design be evaluated?n How should the architecture be documented?體系結構設計要考慮的問題Page 33系統(tǒng)的組成n 系統(tǒng)的組成反映的是系統(tǒng)組織所采用的基本策略。n 三種應用廣泛的組成類型：n數(shù)據(jù)中心體系結構（容器模型）；n客戶/服務器體系結構；n抽象機或分層體系結構。Page 342.1.1 數(shù)據(jù)中心體系結構（容器）n 構成系統(tǒng)的子系統(tǒng)之間交換信息通?？梢圆捎靡?/p>

21、下兩種方式：n所有共享數(shù)據(jù)放到一個中心數(shù)據(jù)庫（容器）中，所有子系統(tǒng)都能從中存取數(shù)據(jù)；n每一個子系統(tǒng)維持自己的一個數(shù)據(jù)庫，子系統(tǒng)之間的數(shù)據(jù)交互通過消息傳遞來實現(xiàn)。n 當系統(tǒng)中存在大量的數(shù)據(jù)共享時，數(shù)據(jù)中心（容器）模型是最為常用的體系結構風格。Page 352.1.1 數(shù)據(jù)中心體系結構（容器）Page 36例：CASE工具集的體系結構Page 37數(shù)據(jù)中心模型的特點n 優(yōu)點優(yōu)點n共享大量數(shù)據(jù)的有效方式，不同子系統(tǒng)間無需數(shù)據(jù)轉換;n子系統(tǒng)無需去考慮數(shù)據(jù)如何被集中管理的；n共享數(shù)據(jù)模型是以容器模式發(fā)布的。n 缺點缺點n子系統(tǒng)必須與容器數(shù)據(jù)模型相一致才能共享數(shù)據(jù)；n數(shù)據(jù)進化會比較困難而且代價較高；n將容

22、器分布到多臺機器上比較困難。Page 382.1.2 客戶/服務器體系結構n 客戶/服務器模型是一個分布式系統(tǒng)模型，數(shù)據(jù)和加工過程在多個處理器之間分配；n 這種模型的主要組成：n一組為其它子系統(tǒng)提供服務的單機服務器；n一組向服務器請求服務的客戶機；n連接客戶機與服務器的網(wǎng)絡。Page 39例：電影圖片系統(tǒng)的體系結構Page 40客戶-服務器模型的特點n 優(yōu)點：n 分布式數(shù)據(jù)處理與共享;n 有效地利用網(wǎng)絡，并且可以使用較便宜的硬件設備;n 可以容易地添加或更新服務器，不會影響系統(tǒng)其它部分。n 缺點：n 沒有統(tǒng)一的共享數(shù)據(jù)模型，所以子系統(tǒng)可以以不同的方式組織數(shù)據(jù)，不利于新增服務器的數(shù)據(jù)集成；n 每

23、個服務器需要自己負責數(shù)據(jù)管理；n 缺少對于服務器名稱和服務狀態(tài)的集中管理。Page 412.1.3 分層（抽象機）體系結構n 這種模型把系統(tǒng)組織成一系列的層次（抽象機），每一層提供一組服務；n 這種模型支持增量式的開發(fā)，不同層次的服務可以單獨交付；n 層與層之間以接口相聯(lián)系，一個接口發(fā)生改變，只有毗鄰的層會受到影響；Page 42例：版本管理系統(tǒng)Page 43經(jīng)典的三層結構數(shù)據(jù)庫數(shù)據(jù)庫銷售組件銷售組件支付組件支付組件表示層表示層業(yè)務邏輯層業(yè)務邏輯層數(shù)據(jù)訪問層數(shù)據(jù)訪問層數(shù)據(jù)庫訪問組件數(shù)據(jù)庫訪問組件Page 442.2 模塊化分解n 模塊化分解要將子系統(tǒng)分解成模塊；n 系統(tǒng)分解與模塊分解之間并沒有

24、嚴格的界限。n 子系統(tǒng)與模塊主要是功能粒度的區(qū)別：n子系統(tǒng)是功能相對獨立的一個系統(tǒng)（由模塊構成），向其它的子系統(tǒng)提供服務；n模塊是一個向系統(tǒng)內(nèi)其它組件提供服務的系統(tǒng)組件，功能粒度通常不足以作為一個系統(tǒng)考慮。Page 45模塊分解策略n 兩個重要分解策略：n面向對象架構模型，將系統(tǒng)分解成一組相互通信的對象，對象間以消息的方式進行協(xié)作；n面向功能的數(shù)據(jù)流（流水線）架構模型，將系統(tǒng)分解成一些功能模塊（過濾器），這些模塊接受輸入，進行處理產(chǎn)生輸出。 n 可能的話，設計之初要盡量避免并發(fā)設計，這樣可以在設計、實現(xiàn)、測試等工作相對容易。Page 462.2.1 面向對象架構模型n 這種方法把系統(tǒng)分解成一些

25、具有良好接口的松散耦合的對象。n 面向對象的分解考慮如何識別對象類、對象屬性以及對象操作。n 實現(xiàn)時，對象從類中產(chǎn)生，再使用某種控制模型來協(xié)調對象間的操作。Page 47例：發(fā)票處理系統(tǒng)Page 48對象方法的特點n 優(yōu)點：n對象間是松耦合，所以對象可以在不影響其他對象的情況下進行修改；n對象可以映射現(xiàn)實世界的實體，易理解，可復用；n面向對象實現(xiàn)語言已經(jīng)廣泛應用；n 問題：n對象通過接口被使用，如果接口發(fā)生變更，可能對所有使用該對象的用戶都會產(chǎn)生影響；n對復雜實體的映射比較困難。Page 492.2.2 面向功能的數(shù)據(jù)流模型n 這種方式中，子系統(tǒng)被分解成功能函數(shù)，函數(shù)處理輸入產(chǎn)生輸出；n 當轉

26、換作為一個單獨的過程時，這種模型有時被稱為管道與過濾器（Unix術語）；n 當對數(shù)據(jù)的處理順序進行時，這種模型也被稱為批處理模型；n 這種模型在數(shù)據(jù)處理系統(tǒng)中應用普遍，而對于交互式系統(tǒng)不太適合。Page 50例：發(fā)票處理系統(tǒng)Page 51數(shù)據(jù)流模型的特點n 優(yōu)點：n支持函數(shù)轉換的復用；n很直觀，易溝通；n比較容易添加新的函數(shù)轉換；n實現(xiàn)容易。n 問題：n把數(shù)據(jù)和操作分開考慮，則需要定義一種對所有數(shù)據(jù)都通用的標準格式，這樣做既增加了系統(tǒng)的負擔又可能無法集成那些不兼容的數(shù)據(jù)格式轉換；n基于事件的交互式系統(tǒng)很難用數(shù)據(jù)流模型來表示。Page 522.2.3 結構化架構設計方法n 從系統(tǒng)設計的角度出發(fā)，

27、軟件設計方法可以分為三大類。第一類是根據(jù)系統(tǒng)的數(shù)據(jù)流進行設計，稱為面向數(shù)據(jù)流的面向數(shù)據(jù)流的設計設計或者過程驅動的設計，以結構化設計方法結構化設計方法為代表。第二類是根據(jù)系統(tǒng)的數(shù)據(jù)結構進行設計，稱為面向數(shù)據(jù)結構面向數(shù)據(jù)結構的設計的設計或者數(shù)據(jù)驅動的設計，以LCP（程序邏輯構造）方法、Jackson系統(tǒng)開發(fā)方法和數(shù)據(jù)結構化系統(tǒng)開發(fā)（DSSD）方法為代表。第三類設計方法即面向對象的設計面向對象的設計。Page 53n 結構化設計方法是基于模塊化、自頂向下細化、結構化程序設計等程序設計技術基礎上發(fā)展起來的。該方法實施的要點是： 建立數(shù)據(jù)流的類型。 指明流的邊界。 將數(shù)據(jù)流圖映射到系統(tǒng)結構。 用“因子化

28、”方法定義控制的層次結構。 用設計測量和一些啟發(fā)式規(guī)則對結構進行細化。n 數(shù)據(jù)流可以分成變換型數(shù)據(jù)流和事務性數(shù)據(jù)流，相應得到的系統(tǒng)結構也分為變換型系統(tǒng)結構和事務型系統(tǒng)結構 2.2.3 結構化架構設計方法Page 54在系統(tǒng)結構圖（在系統(tǒng)結構圖（SCSC）中的模塊中的模塊 n 在系統(tǒng)結構圖中不能再分解的底層模塊為原子模原子模塊塊。如果一個軟件系統(tǒng)的全部實際加工（數(shù)據(jù)計算或處理）都由底層的原子模塊來完成，而其它所有非原子模塊僅僅執(zhí)行控制或協(xié)調功能，這樣的系統(tǒng)就是完全因子分解的系統(tǒng)。如果系統(tǒng)結構圖是完全因子分解的，就是最好的系統(tǒng)。 Page 55n 一般地，在系統(tǒng)結構圖中有一般地，在系統(tǒng)結構圖中有4

29、 4種類型的模塊：種類型的模塊： v 傳入模塊傳入模塊 ：從下屬模塊取得數(shù)據(jù)，經(jīng)過某些處理，再將其傳送給上級模塊。v 傳出模塊傳出模塊 ：從上級模塊獲得數(shù)據(jù)，進行某些處理，再將其傳送給下屬模塊。v 變換模塊變換模塊 ：即加工模塊。它從上級模塊取得數(shù)據(jù)，進行特定的處理，轉換成其它形式，再傳送回上級模塊。大多數(shù)計算模塊（原子模塊）屬于這一類。v 協(xié)調模塊協(xié)調模塊 ：對所有下屬模塊進行協(xié)調和管理的模塊。 在系統(tǒng)的輸入輸出部分或數(shù)據(jù)加工部分可以找到這樣的模塊。在一個好的系統(tǒng)結構圖中，協(xié)調模塊應在較高層出現(xiàn)。 在實際系統(tǒng)中，有些模塊屬于上述某一類型，還有一些模在實際系統(tǒng)中，有些模塊屬于上述某一類型，還有

30、一些模塊是上述各種類型的組合。塊是上述各種類型的組合。 在系統(tǒng)結構圖（在系統(tǒng)結構圖（SCSC）中的模塊中的模塊 Page 56在系統(tǒng)結構圖（在系統(tǒng)結構圖（SCSC）中的模塊中的模塊 Page 572.2.3.12.2.3.1變換型數(shù)據(jù)流與變換變換型數(shù)據(jù)流與變換型系統(tǒng)結構型系統(tǒng)結構n 變換型數(shù)據(jù)處理問題的工作過程大致分為三步，即取得數(shù)取得數(shù)據(jù)，變換數(shù)據(jù)據(jù)，變換數(shù)據(jù)和給出數(shù)據(jù)給出數(shù)據(jù)。n 變換數(shù)據(jù)是數(shù)據(jù)處理過程的核心工作，而取得數(shù)據(jù)只不過是為它做準備，給出數(shù)據(jù)則是對變換后的數(shù)據(jù)進行后處理工作。 n 典型的變換型數(shù)據(jù)流圖具有如下結構特點：信息外部表示內(nèi)部表示時間輸入流輸出流變換中心Page 58例子

31、：例子：1：輸入A2：A-B變換中心4：C-D6：輸出E3：B-C5：D-EABC(邏輯輸入)ED(邏輯輸出)加工1取得系統(tǒng)物理輸入數(shù)據(jù)A ，加工2和3對輸入數(shù)據(jù)進行簡單處理，得到系統(tǒng)邏輯輸入C。加工4作為系統(tǒng)核心處理構件，進行C-D數(shù)據(jù)變換，獲得系統(tǒng)邏輯輸出D。加工5對系統(tǒng)邏輯輸出數(shù)據(jù)進行格式轉換等，加工6進行系統(tǒng)數(shù)據(jù)物理輸出。Page 59n 系統(tǒng)的結構圖由輸入、中心變換和輸出等三部分組成。 系統(tǒng)結構圖系統(tǒng)結構圖Page 60系統(tǒng)結構圖系統(tǒng)結構圖n 設計時，需要區(qū)分輸入流、輸出流和中心變換部分，即標明流的邊標明流的邊界界。（不同的設計人員可能選擇不同的流邊界，這將導致不同的系統(tǒng)結構圖。）

32、n 首先設計主模塊首先設計主模塊，用程序名字為它命名，將它畫在與中心變換相對應的位置上。做為系統(tǒng)的頂層，它調用下層模塊，完成系統(tǒng)所要做的各項工作。n 在系統(tǒng)結構的第一層，為每一個邏輯輸入設計一個輸入模塊，它為主模塊提供數(shù)據(jù)；為每一個邏輯輸出設計一個輸出模塊，它將主模塊提供的數(shù)據(jù)輸出；為中心變換設計一個變換模塊，它將邏輯輸入轉換成邏輯輸出。第一層模塊與主模塊之間傳送的數(shù)據(jù)應與數(shù)據(jù)流圖相對應。（后續(xù)）Page 61n 然后自頂向下，逐層細化自頂向下，逐層細化，設計中、下層模塊。這一步工作是為每一個輸入模塊、輸出模塊、變換模塊設計它們的從屬模塊。n 輸入模塊要向調用它的上級模塊提供數(shù)據(jù)，因而它必須有

33、兩個下屬模塊：一個是接收接收數(shù)據(jù)；另一個是把這些數(shù)據(jù)變換變換成它的上級模塊所需的數(shù)據(jù)。n 輸出模塊是從調用它的上級模塊接收數(shù)據(jù)用以輸出，因而也應當有兩個下屬模塊：一個是將上級模塊提供的數(shù)據(jù)變換變換成輸出的形式；另一個是將它們輸出輸出。n 中心變換模塊的下層模塊沒有通用的設計方法，一般應參照數(shù)據(jù)流圖的中心變換部分和功能分解的原則來考慮如何對中心變換模塊進行分解。 系統(tǒng)結構圖系統(tǒng)結構圖Page 622.2.3.22.2.3.2事務型數(shù)據(jù)流與事務型系事務型數(shù)據(jù)流與事務型系統(tǒng)結構統(tǒng)結構n 事務型數(shù)據(jù)處理問題的工作機理是接受一項事務，根據(jù)事務處理的特點和性質，從若干個操作序列從若干個操作序列中選擇分派一

34、個中選擇分派一個適當?shù)?，然后給出結果。n 我們把完成選擇分派選擇分派任務的部分叫做事務處理中事務處理中心心，或分派部件。Page 632.2.3.22.2.3.2事務型數(shù)據(jù)流與事務型系事務型數(shù)據(jù)流與事務型系統(tǒng)結構統(tǒng)結構Page 64事務型分析的映射方式事務型分析的映射方式DGFE接收通路C通路B通路A通路總控E調度DGA-CTLB-CTLC-CTLFPage 65n 事務流應映射為包含一個輸入分支一個輸入分支和一個分類事務處一個分類事務處理分支理分支的程序結構。n 輸入分支結構的開發(fā)與變換流的方法類似。n 分類事務處理分支結構包含一個調度模塊調度模塊，它調度和控制下屬的操作模塊。n 事務型系統(tǒng)

35、結構圖在數(shù)據(jù)處理中經(jīng)常遇到，但是更多的是變換型與事務型系統(tǒng)結構圖的結合。例如，事務型系統(tǒng)結構中的某個分支本身又具有變換型的特點。 Page 662.3 控制模型n 控制模型考慮子系統(tǒng)之間的控制流，這是分解模型不考慮的問題。n 對控制流建模有兩種一般性的方法：n集中式控制集中式控制n One sub-system has overall responsibility for control and starts and stops other sub-systems.n基于事件的控制基于事件的控制n Each sub-system can respond to externally genera

36、ted events from other sub-systems or the systems environment.Page 672.3.1 集中控制n 這種控制方式中有一個子系統(tǒng)被指定為系統(tǒng)控制器來負責管理其他子系統(tǒng)的執(zhí)行。n 這種控制模型按子系統(tǒng)順序執(zhí)行還是并行執(zhí)行分為兩類：n 調用調用- -返回模型返回模型nTop-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems.n

37、 管理者模型管理者模型nApplicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes. Can be implemented in sequential systems as a case statement.Page 68調用-返回模型Page 69實時系統(tǒng)控制Page 702.3.2 事件驅動系統(tǒng)n 事件驅動的控制模型通過外部產(chǎn)生的事件來驅動系統(tǒng)。n 有兩種主要的事件驅動模型：n廣播模型廣播模型

38、n An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so;n中斷驅動模型中斷驅動模型n Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing.Page 71廣播模型n 廣播模型對于基于網(wǎng)絡的分布式系統(tǒng)很有效。n 這種模型中，子系統(tǒng)注冊其感興趣的特別事件，當這些

39、事件發(fā)生時，控制就被轉移到能處理這些事件的子系統(tǒng)。n 這種模型的控制策略不在事件和消息處理器的內(nèi)部。由子系統(tǒng)決定需要哪些事件，消息處理器只負責將事件發(fā)給它們。n 這種模型易于新系統(tǒng)的集成，缺點是子系統(tǒng)不能知道是否和什么時侯事件將會被處理。Page 72選擇性廣播Page 73中斷驅動系統(tǒng)n 這種模型在需要對外部事件做出迅速處理的實時系統(tǒng)中非常有用。n 每種中斷類型對應一種要處理的事件，分別與一個內(nèi)存地址相連，該內(nèi)存地址存放的是與中斷類型相對應的事件處理器的地址。n 這種控制的優(yōu)點是能夠對事件做出非常迅速的反應，缺點在于它的編程較為復雜且不易驗證有效性。Page 74中斷驅動控制Page 753

40、 構件級設計建模n 構件級設計是要在接近代碼的抽象級上表示內(nèi)部數(shù)據(jù)結構和每個構件的處理細節(jié)。n 構件級設計定義了數(shù)據(jù)結構、算法、接口特征和分配給每一個軟件構件的通信機制。n 構件級設計是把高層設計模型轉化為可運行程序的橋梁。Page 763.1 什么是構件？n Unified Modeling Language Specification OMG01 把構件定義為： n “ 系統(tǒng)中某一定型化的、可配置的和可替換的部件，該部件封裝了實現(xiàn)并暴露一系列的接口”。n OO 觀點: 一個構件包含一組協(xié)作類。n 傳統(tǒng)觀點: 一個構件就是程序的一個功能要素，程序由處理邏輯以及實現(xiàn)處理邏輯所需的內(nèi)部數(shù)據(jù)結構以

41、及能夠保證構建被調用和實現(xiàn)數(shù)據(jù)傳遞的接口構成。傳統(tǒng)的構件通常稱為模塊。Page 77面向對象構件P rin tJo bc o m p u te Jo bin itia te Jo bnum berO fPages num berO fSides paperType paperW eight paperSize paperC olor m agnification colorRequirem ents productionFeatures collationO ptions bindingO ptions coverStock bleed priority totalJobC ost W O n

42、um ber P ri n tJ o bcom putePageC ost() com putePaperC ost () com puteProdC ost () com puteTotalJobC ost() buildW orkO rder() checkPriority () passJobto Production() e l a b o ra te d d e s i g n c l a s s co m p u teJo bcom putePageC ost () com putePaperC ost () com puteProdC ost () com puteTotalJo

43、bC ost () in itiateJo bbuildW orkO rder() checkPriority () passJobto Production()d e sig n c o m p o n e n tn u m b e rO fP a g e s n u m b e rO fS id e s p a p e rT y p e m a g n ific a tio n p ro d u c tio n F e a tu re sP rin tJo bc o m p u te Jo b C o st() p a ssJo b to P rin te r() a n a ly sis

44、 c la ssPage 78傳統(tǒng)構件Com putePageCostdesi gn com ponentaccessCostsDBgetJobDatael aborated m odul ePageCosti n: j ob si ze i n: col or =1, 2, 3, 4 i n: pageSi ze = A, B, C, B out: BPC out: SF i n: num ber Pages i n: num ber Docs i n: si des= 1, 2 i n: col or =1, 2, 3, 4 i n: page si ze = A, B, C, B out

45、: page cost j ob si ze (JS) = num ber Pages * num ber Docs;l ookup base page cost (BPC) - - accessCostsDB (JS, col or ); l ookup si ze f actor ( SF) - - accessCostDB (JS, col or , si ze) j ob com pl exi ty f actor (JCF) = 1 + (si des- 1)*si deCost + SFpagecost = BPC * JCF getJobData (num ber Pages,

46、num ber Docs, si des, col or , pageSi ze, pageCost)accessCostsDB ( j obSi ze, col or , pageSi ze, BPC, SF)com putePageCost ()Page 793.2 基本設計原則（OO）n 開關原則 (OCP)： “一個模塊（構件）應該對外延具有開放性，對修改具有封閉性”。n Liskov Liskov 替換原則 (LSP)： “子類可以替換它們的基類”。 n 依賴倒置原則 (DIP)： “依賴于抽象，而非具體實現(xiàn)“。 n 接口分離原則 (ISP)： “多個用戶專用接口比一個通用接口要好”

47、。n 發(fā)布復用等價性原則 (REP)：“復用的粒度就是發(fā)布的粒度”。 n 共同封裝原則 (CCP)：“一同變更的類應該合在一起 ”。n 共同復用的原則 (CRP)： “不能一起復用的類不能被分到一組”。 Page 80基本設計原則（OO）Page 813.3 構件級設計指導方針n構件n 對那些已經(jīng)確定為體系結構模型一部分的構件應該建立命名約定，并對其做進一步的細化和精化，使其成為構件級模型的一部分。n接口n 接口提供關于通信和協(xié)作的重要信息 （也可以幫助我們實現(xiàn)OCP原則）。n依賴與繼承n 為了提高可讀性，依賴關系是自左向右，繼承關系是自下（派生類）向上（基類）。構件間的依賴通過接口表示，而不

48、是構件到構件。Page 823.4 設計傳統(tǒng)構件n 設計傳統(tǒng)構件的工作主要集中在對模塊算法（程序邏輯）的設計上。n 算法設計是最接近編碼的設計活動。n 算法設計的步驟:n復查組件的設計描述；n使用逐步求精法來開發(fā)算法；n使用結構化程序設計方法來實現(xiàn)算法邏輯；n使用形式化方法來驗證算法邏輯。Page 83逐步求精Page 84結構化程序設計方法的特點n 使用限定好的一組邏輯構造：n順序型n條件型 if-then-else, select-casen循環(huán)型 do-while, repeat untiln 能夠提高代碼的可讀性和可測試性；Page 85算法設計模型n 我們需要在一個能夠進行質量復查的

49、細節(jié)層次上描述算法。n 描述方法通常包括:n 圖形法 (e.g. flowchart, box diagram)n 判定表n 偽碼 (e.g., PDL)Page 86圖形化表示方法流程圖ax1x2b3x45cdefgxxadd a condition Z, if true, exit the programPage 87判定表C Co on nd di i t ti i o on ns sregul ar custom er si l ver custom er gol d custom er speci al di scountR Ru ul l e es sno di scount ap

50、pl y 8 percent di scount appl y 15 percent di scount appl y addi ti onal x percent di scountTFTTTTTF13564FTTT2R Ru ul l e es sPage 88程序設計語言 (PDL)if-then-elseif condition x then process a; else process b; endif PDLeasy to combine with source code machine readable, no need for graphics input graphics

51、can be generated from PDL enables declaration of data as well as procedure easier to maintainPage 894 面向對象的設計方法n 面向對象的設計過程同樣包括體系結構設計、組件設計、數(shù)據(jù)庫設計和算法設計等活動。n 面向對象的設計建模是在面向對象分析模型的基礎上進行進一步的分析擴展，搭建目標系統(tǒng)的解決方案。Page 90面向對象的設計項目干系人Mental Modle需求模型（需求分析）架構模型（架構設計）設計模型（構件設計）解決方案模型編碼NFRsFRsn架構設計與構件設計共同構成系統(tǒng)的解決方案。Pa

52、ge 914.1 軟件架構設計n 軟件架構（Software Architecture）就是關于如何構建軟件的一些最重要的設計決策，這些決策往往將圍繞將系統(tǒng)分成哪些部分、各部分之間如何交互展開的。Page 92架構的類比-建造房屋Page 93為房屋建立一個模型- - 對早期成就的模仿對早期成就的模仿 - - 從失敗中學習從失敗中學習 - - 對其他影響因素對其他影響因素的綜合的綜合 - - 試驗試驗任何時候要拋棄已經(jīng)任何時候要拋棄已經(jīng)具有的習慣時，特別是大的項目中，您最好具有的習慣時，特別是大的項目中，您最好要用多十倍的努力、要用多十倍的努力、多十倍的調查多十倍的調查. - LeMessui

53、erPage 94常見民用建筑的種類n 社區(qū)n住宅, 公寓, 花園, 教育, 醫(yī)院, 宗教設施n 商業(yè)n商店和零售店, 飯店, 賓館, 寫字樓, 銀行, 機場n 工業(yè)n工業(yè)建筑, 實驗室, 農(nóng)場建筑n 休閑n運動場館, 戲劇院和電影院, 博物館Page 95民用建筑中的受力壓縮壓縮Load拉伸拉伸LoadPage 96多角度的視圖場地場地結構結構服務服務空間計劃空間計劃 材料材料Page 97軟件構架中的受力性能性能容量容量功能性功能性可用性可用性恢復力恢復力失效安全失效安全容錯能力容錯能力Have an architecture that makes sense before you wri

54、te 3.5 millionlines of code. - Patrick Naugton技術因素技術因素Page 98軟件架構視圖n 一個架構視圖是對于從某一視角或某一點上看到的系統(tǒng)所做的簡化描述，描述中涵蓋了系統(tǒng)的某一特定方面，而省略了與此方面無關的實體。 -Philippe KruchtenPage 99辦公室里的爭論n 辦公室里，關于什么是軟件架構，爭論正酣：n 程序員說，軟件架構就是要決定需要編寫哪些類、使用那些現(xiàn)成的框架。n 程序經(jīng)理笑了，他說，軟件架構就是模塊的劃分和接口的定義。n 系統(tǒng)分析員笑了，他說軟件架構就是為業(yè)務領域對象的關系建模。n 配置管理員笑了，他說軟件架構就是開

55、發(fā)出來以及編譯后的軟件到底是個啥結構。n 數(shù)據(jù)庫工程師笑了，他說軟件架構規(guī)定了持久化數(shù)據(jù)的結構。n 部署工程師笑了，他說軟件架構規(guī)定了軟件部署到硬件的策略。n 用戶笑了，他說軟件架構規(guī)定了一個個功能子系統(tǒng)如何劃分。n 大家想了想說，這些架構視圖好像我們都需要啊！n 軟件架構師哭了Page 100軟件架構為誰設計客戶用戶開發(fā)人員管理人員軟件架構師業(yè)務目標約束條件功能和運行期質量開發(fā)期質量管理的基礎Page 101架構設計的5視圖法邏輯架構開發(fā)架構運行架構物理架構數(shù)據(jù)架構功能需求數(shù)據(jù)需求開發(fā)期質量屬性安裝和部署需求運行期質量屬性Page 102例：設備調試系統(tǒng)案例設備調試員數(shù)據(jù)采集器查看設備狀態(tài)定

56、時器發(fā)送調試命令設備用例圖：Page 103邏輯架構n 應用層負責設備狀態(tài)的顯示，并提供模擬控制臺供用戶發(fā)送調試命令；n 通訊層負責在RS323協(xié)議之上實現(xiàn)一套專用的應用協(xié)議；n 負責對調試設備的具體控制。應用層(from Logical View)通訊層(from Logical View)設備控制層(from Logical View)Page 104物理架構機調試機數(shù)采器設備專有連接專有連接桌面部分嵌入部分Page 105邏輯層到物理層的映射桌面部分嵌入部分應用層通訊層設備控制層Page 106架構設計流程1.為系統(tǒng)選擇架構類型2.為架構重要用例創(chuàng)造一個詳細的部署圖3.精煉架構模型來滿足

57、NFRs4.創(chuàng)建和測試架構基線5.在Tier和Layer圖中記錄技術選擇6.從最終的、詳細的部署圖中創(chuàng)建一個架構模板Page 107為架構中重要的用例創(chuàng)建詳細的部署圖為系統(tǒng)選擇一個架構類型 精化架構模型來滿足非功能性需求(NFRs) 創(chuàng)建架構體系的基線在Tier 和 Layer圖中記錄技術選擇ArchCode SRSClient Server Client Server client domainBackendCOBRASwing DBMSPC Ultra60 SunFire TcpPage 108選擇架構類型 選擇可使用的架構依賴于很多因素，包含：系統(tǒng)需求的平臺約束用戶交互作用模式持續(xù)性機制

58、數(shù)據(jù)和事務的完整性Page 109選擇架構類型n 數(shù)以百計的成功軟件架構。他們之間有一些共同類型：獨立應用（Standalone application）客戶服務器（層）應用（Client/Server(2-tiers)applications） N層應用（N-tiers applications） Web-centric（N層）應用（Web-centricn-tiers applications） 企業(yè)N層應用（Enterprise n-tiers applications）Page 110獨立應用n 沒有外部數(shù)據(jù)源(所有的應用數(shù)據(jù)都在文件服務中)n 沒有網(wǎng)絡通信(所有的應用組件都在一臺機器

59、中)Page 111客戶服務器（層）應用n 胖客戶端(業(yè)務邏輯在客戶端)n 數(shù)據(jù)存儲者管理數(shù)據(jù)的完整性Page 112N-層應用n 瘦客戶端(業(yè)務邏輯在應用服務端)n 應用服務器管理數(shù)據(jù)完整性Page 113Web-Centric(N-層)應用n Web瀏覽器成為瘦客戶端n Web服務器提供表示和業(yè)務邏輯Page 114企業(yè)（N-層）應用類型Page 115企業(yè)（N-層）應用類型n 兩個瘦客戶端 Web瀏覽器為Internet使用者提供 GUI瘦客戶端為Intranet使用者提供n Web應用服務器提供表示邏輯n 應用服務器提供業(yè)務邏輯Page 116酒店預定系統(tǒng)架構Page 117創(chuàng)建詳細的

60、部署圖n 為架構有影響的用例設計組件n 將設計組件置于架構模型中n 將設計和基礎結構組件合并后然后在畫出詳細的部署圖Page 118詳細的部署圖Page 119創(chuàng)建架構模板n 簡化詳細的部署圖讓其只剩下設計組件：邊界，服務，實體。n 取代具有類型的設計組件名字（for example, ResvSvcImpl_Stub becomesServiceImpl_Stub）Page 120架構模板實例Page 121應用SunTone 架構方法論n SunTone 架構方法論推薦了下列架構維度：用tier層次結構分離應用程序的邏輯關系。用layer層次結構來組織組件及容器關系。系統(tǒng)質量通過tier層