【文章內(nèi)容簡介】 )《 面向?qū)ο蠹?術(shù)與 UML》課程教學(xué)教案 (項煒 ) 11 ? 是否客戶和系統(tǒng)的用戶對用例的名稱和描述 理解 相同？ 檢查點(diǎn)列表 : 需求 : 用例描述 ? 用例的 執(zhí)行者 是否明確？ ? 用例執(zhí)行的 目的 是否明確？ ? 用例簡述是否正確描述了用例的 功能 ? 用例 事件流 開始和結(jié)束的時機(jī)和方式是否明確 ? 角色和用例之間的交互序列是否 滿足 了用戶的期望？ ? 角色交互和信息交換是否 明確 ？ ? 是否有用例過于 復(fù)雜 ？ 檢查點(diǎn)列表 : 需求 : 詞匯表 ? 每一個詞匯的 定義 是否全是清晰和精確 的？ ? 每一個詞匯是否都 被使用 在了某個用例的描述中？ ? 在角色和用例的描述中，每個詞匯的含義是否 一致 ？ 本章小結(jié) 本章小結(jié)： 需求總結(jié) ? 需求的主要產(chǎn)出是什么？ ? 需求的產(chǎn)出有什么用途？ ? 用例模型是什么？ ? 角色是什么？ ? 用例是什么？列舉出用例屬性的一些例子 ? 用例和場景有何不同？ ? 附加說明是什么？包含什么內(nèi)容？ ? 詞匯表是什么？包含什么內(nèi)容？ 第三章 分析和設(shè)計概述 章節(jié)目標(biāo) 理解分析和設(shè)計的核心 術(shù)語 、 概念 ； 了解分析和設(shè)計的 實際 過程 ，包括角色、工件和工作流程； 解釋分析和設(shè)計的 差異 。 特定情景下的分析和設(shè)計 分析和設(shè)計的目的是： ? 將需求 轉(zhuǎn)化 為系統(tǒng)設(shè)計 ? 使系統(tǒng)具有更加健壯的 架構(gòu) ? 是設(shè)計和實現(xiàn)環(huán)境相匹配，做性能設(shè)計 ? 商務(wù)規(guī)則為系統(tǒng)結(jié)構(gòu)提供 場景 ? 需求規(guī)則為分析和設(shè)計提供了基本 輸入 ? 測試規(guī)則測試了在分析和設(shè)計階段的系統(tǒng) ? 環(huán)境規(guī)則發(fā)展和維護(hù)了在分析階段使用的工件 ? 管理原則規(guī)劃整個項目和每一次迭代（迭代項目中）。 20202020(上 )《 面向?qū)ο蠹?術(shù)與 UML》課程教學(xué)教案 (項煒 ) 12 分析和設(shè)計概述 ? 輸入 ： USECASE 模型（角色、用例、用例描述）、術(shù)語表和附加規(guī)范（補(bǔ)充說明）。 ? 產(chǎn)出 ：設(shè)計 模型（作為源代碼抽象的模型） ? 展開 ：設(shè)計活動圍繞架構(gòu)的概念展開。架構(gòu)優(yōu)先：其可行性和正確性是早期設(shè)計迭代周期的主要關(guān)注點(diǎn)。通過抽象忽略其細(xì)節(jié)，展現(xiàn)其主要特征使之具體化。架構(gòu)不僅為了開發(fā)好的設(shè)計模型，還將提高實現(xiàn)過程的質(zhì)量。架構(gòu)由架構(gòu)文檔記錄。 ? 架構(gòu)文檔不在這次課程范圍，但我們會討論其內(nèi)容及如何解釋。 分析和設(shè)計綜述（ 1）核心概念 ? 從定義分析和設(shè)計工作流程的核心術(shù)語及概念開始。 分析和設(shè)計對比（參看幻燈片） ? 關(guān)注點(diǎn)不同 ：分析和設(shè)計的差別在于關(guān)注點(diǎn)和側(cè)重點(diǎn)。 ? 分析的目標(biāo) ：理解問題并建立一個可視化的分 析模型，而不去考慮實現(xiàn)的技術(shù)細(xì)節(jié)。分析關(guān)注于把功能需求轉(zhuǎn)化為軟件中的概念，目的是得到系統(tǒng)中的對象，側(cè)重于行為的封裝。以便盡快轉(zhuǎn)入設(shè)計及其他階段。 ? 設(shè)計的目標(biāo) ：細(xì)化分析模型，開發(fā)一個設(shè)計模型，以便迅速過渡到編碼階段。在設(shè)計中，我們必須適應(yīng)實現(xiàn)環(huán)境和分布環(huán)境。實現(xiàn)環(huán)境是開發(fā)者必須滿足的環(huán)境，它是分布環(huán)境中軟件的超集和硬件的子集。 ? 建模的目標(biāo) ：從一個和現(xiàn)實世界緊密類似的對象模型出發(fā)，找出更為普遍的解決方法。由此而創(chuàng)建模擬現(xiàn)實世界的模型，更為強(qiáng)大、能更簡單地解決問題。 分析和設(shè)計并不是由下而上或由上而下的 ? 分析 和設(shè)計并不是由下而上或由上而下的。 ? 用例從左側(cè)進(jìn)入并定義一個中間層：分析類。 ? 定義的子系統(tǒng)移動到上部，定義的設(shè)計類移動到下部。 ? 分析可以是上到中、中到上、下到上地移動。不能說哪一個路徑更重要，而是必須覆蓋所有的路徑以保證系統(tǒng)的正確性。 ? 所有四種路徑同等重要，這就是由上到下或由下到上無法解決問題的原因。 什么是架構(gòu)？ ? 架構(gòu) Architecture（體系結(jié)構(gòu)）：一組關(guān)于下述問題的重要決定：軟件系統(tǒng)的組織方式，構(gòu)成系統(tǒng)的模型元素和它們接口的選擇，以及由這些模型元素之間的協(xié)作所描述的行為；這些結(jié)構(gòu)元素和行為元素 如何進(jìn)一步組成較大的系統(tǒng)，以及指導(dǎo)這種組織（這些元素和它們的接口、協(xié)作和組合）的結(jié)構(gòu)風(fēng)格。軟件體系結(jié)構(gòu)不僅關(guān)注結(jié)構(gòu)和行為，也關(guān)注使用關(guān)系、功能性、性能、彈性、復(fù)用、可理解性、經(jīng)濟(jì)和技術(shù)約束與折中以及審美考慮。 ? 軟件架構(gòu)包含：組成系統(tǒng)的結(jié)構(gòu)元素和它們的接口；元素協(xié)作的特定行為；將結(jié)構(gòu)元素和行為元素結(jié)合成一個大的子系統(tǒng)；體系結(jié)構(gòu)風(fēng)格支配了組織結(jié)構(gòu)。 ? 架構(gòu)可以是靜態(tài)的也可以是動態(tài)的。 ? 相同系統(tǒng)的架構(gòu)應(yīng)該是類似的（已用過的特殊類型）：體系結(jié)構(gòu) =元素 +形式 +基本原理。 ? 基本原理決定一個好架構(gòu)的核心部分。 ? 模式是將元素 聚合為某種形式的指導(dǎo)方針。 架構(gòu)約束設(shè)計和實現(xiàn) ? 架構(gòu)包括一套整體設(shè)計的結(jié)論、規(guī)則或者設(shè)計約束和結(jié)構(gòu)的模式。 20202020(上 )《 面向?qū)ο蠹?術(shù)與 UML》課程教學(xué)教案 (項煒 ) 13 ? 架構(gòu)結(jié)論是最底層的結(jié)論，改變它將帶來巨大的影響。 ? 架構(gòu)可以被看作一套核心設(shè)計結(jié)論的集合。 ? 架構(gòu)是對系統(tǒng)的最初限制，這些限制往往也是最重要的。他們組成了軟件設(shè)計的最基礎(chǔ)的結(jié)論。 ? 架構(gòu)為設(shè)計提供了一個框架，因此架構(gòu)也被稱作戰(zhàn)略式的設(shè)計。 ? 一個系統(tǒng)架構(gòu)師的工作就是消除非必須的工作。隨著對代碼的越發(fā)接近，這些工作就會被除去（架構(gòu)限制著設(shè)計、設(shè)計限制著實現(xiàn)）。這樣做是非常有用的，因為在實現(xiàn)過程中，我們可以增 加其他方面（例如，提高質(zhì)量和性能）的工作。 軟件架構(gòu)：“ 4+1 視圖”模型 ? 上面的圖表說明了 Rational 公司用來描述軟件架構(gòu)的模型。 ? 不同的組織對架構(gòu)有不同的看法。在一個指定的項目中，通常有許多投資人，他們對姚開發(fā)的系統(tǒng)都有它們自己的看法。我們的目標(biāo)是為這些不同的投資人提供一個系統(tǒng)來滿足他們所關(guān)心的，而忽略一些其他的細(xì)節(jié)。 ? 為了滿足這些不同的需求， Rational 公司定義了“ 4+1 視圖”模型。一個架構(gòu)視圖是對系統(tǒng)從特殊觀點(diǎn)或者優(yōu)勢來進(jìn)行簡單描述（或抽象），覆蓋特定的關(guān)注點(diǎn)，并忽略與這個關(guān)聯(lián)聯(lián)系不緊密的 實體。視圖是模型的“片段”，而不是所有的系統(tǒng)都需要所有的視圖（例如，單一處理器：舍棄分布視圖；單一進(jìn)程：舍棄過程視圖；小程序：舍棄實現(xiàn)視圖等）。 ? 一些項目可以記錄所有這些視圖，或者附加一些視圖。具體視圖的數(shù)量依賴所開發(fā)的系統(tǒng)。 ? 這些視圖中的每一個，以及用來代表他們的 UML 符號，將在以后的章節(jié)討論。 分析和設(shè)計綜述（ 2）分析和設(shè)計工作流程 ? 僅僅由開發(fā)者、活動和工件并不能組成一個進(jìn)程。我們需要一種描述活動的方法，一些有價值的結(jié)果，以及開發(fā)者之間的交互結(jié)果。工作流程是一個活動序列，而且可以產(chǎn)生能夠看得見的價 值。 ? 在 UML 術(shù)語中，工作流程可以用順序圖、交互圖或者活動圖來表示。我們使用 RUP中的一些活動圖。對每一個核心工作流程，都有一個活動圖與之對應(yīng)。這個圖說明了工作流程，根據(jù)工作流程的細(xì)節(jié)來描述的。 ? 這張幻燈片說明了分析和設(shè)計的工作流程。早期的“ Elaboration Phase”階段關(guān)注為系統(tǒng)創(chuàng)建一個初始的架構(gòu)（定義一個備選架構(gòu)），來為主要的分析階段提供一個起始點(diǎn)。如果架構(gòu)已經(jīng)存在（可以從前期的迭代、項目、或者一個用程序的框架得來），工作的重點(diǎn)就變?yōu)榧?xì)化架構(gòu)，分析行為和創(chuàng)建一套初始化的元素來提供適當(dāng)?shù)男袨椋ǚ?析行為）。 ? 當(dāng)初始化的元素定義完之后，它們就要被進(jìn)一步細(xì)化。設(shè)計組件和設(shè)計實施組件將會產(chǎn)生一套組件，這套組件為了滿足系統(tǒng)需要提供了適當(dāng)?shù)男袨?。與此并列的是數(shù)據(jù)庫設(shè)計。結(jié)果是產(chǎn)出在實現(xiàn)階段進(jìn)一步細(xì)化的一套初始化組件。 分析和設(shè)計活動綜述 ? 在分析和設(shè)計中，我們從 USECASE 模型和設(shè)計階段的輔助規(guī)范著手，以作為源代碼抽象的設(shè)計模型的產(chǎn)出而結(jié)束。 ? 設(shè)計活動以架構(gòu)概念為中心。在早期迭代設(shè)計中，這種架構(gòu)的產(chǎn)出以及正確性是我們主要的關(guān)注點(diǎn)。架構(gòu)是一個重要工具，使用它不但可以開發(fā)一個好的設(shè)計模型，而且可以提高系統(tǒng)開 發(fā)過程中模塊的質(zhì)量。 ? 本課程的關(guān)注點(diǎn)在設(shè)計行為。系統(tǒng)架構(gòu)是的行為要討論，但是我們將更多地給出一20202020(上 )《 面向?qū)ο蠹?術(shù)與 UML》課程教學(xué)教案 (項煒 ) 14 些架構(gòu)的結(jié)論。架構(gòu)和設(shè)計都將在單獨(dú)的章節(jié)中展開。 軟件架構(gòu)師的責(zé)任 軟件系統(tǒng)架構(gòu)師的任務(wù)是在整個項目過程中領(lǐng)導(dǎo)和協(xié)調(diào)技術(shù)以及工件。軟件系統(tǒng)架構(gòu)師為每一個架構(gòu)視圖建立全面的結(jié)構(gòu)：分解視圖、元素分組、以及這些主要分組間的接口。因此，與其他角色相比，軟件系統(tǒng)架構(gòu)師的觀點(diǎn)決定著系統(tǒng)的廣度和深度?？偟膩碚f，軟件系統(tǒng)架構(gòu)師必須是全面的、成熟的、具有快速掌握問題的豐富經(jīng)驗、良好素質(zhì)，缺少全部信息時的關(guān)鍵判斷。更專業(yè)地說，系統(tǒng) 架構(gòu)師或架構(gòu)師團(tuán)隊中的一員，必須具有以下技能： ? 同時具有解決問題領(lǐng)域和軟件工程領(lǐng)域中對需求的徹底理解。如果一個團(tuán)隊具有這些品質(zhì)就可以在團(tuán)隊中擴(kuò)散，但至少得有一個軟件架構(gòu)師可以提供一個項目全局性的看法。 ? 具有領(lǐng)導(dǎo)才能，以此在技術(shù)方面驅(qū)動不同的團(tuán)隊，在壓力下做出關(guān)鍵的結(jié)論，并堅持這些結(jié)論。為了更有效，軟件系統(tǒng)架構(gòu)師和項目經(jīng)理必須緊密合作。軟件系統(tǒng)架構(gòu)師領(lǐng)導(dǎo)技術(shù)問題，項目經(jīng)理領(lǐng)導(dǎo)行政性問題。軟件系統(tǒng)架構(gòu)師必須有權(quán)利在技術(shù)方面做出決定。 ? 具有交流能力，以此獲得信任，說服別人，激發(fā)別人以及指導(dǎo)別人。軟件系統(tǒng)架構(gòu)師不能 被規(guī)則所領(lǐng)導(dǎo)，而只需得到項目其他成員的同意。為了更加有效，軟件系統(tǒng)架構(gòu)師必須在項目組中贏得其他人的尊重，包括項目經(jīng)理、客戶、用戶團(tuán)體及管理團(tuán)隊。 ? 針對目標(biāo)并且嚴(yán)格地以結(jié)果為前提。軟件系統(tǒng)架構(gòu)師是項目中的技術(shù)驅(qū)動力量，而不是空想家或夢想家。一個成功的軟件系統(tǒng)架構(gòu)師的職業(yè)生涯是在一系列不確定性