《軟件工程》自考重點(diǎn)難點(diǎn)匯集

1、應(yīng)考指導(dǎo)一、課程介紹1、課程性質(zhì)軟件工程是全國高等教育自學(xué)考試計(jì)算機(jī)及應(yīng)用（獨(dú)立本科段）的一門專業(yè)課。軟件工程是研究軟件開發(fā)的一門課程， 其主要內(nèi)容包括： 軟件開發(fā)所需要的過程、活動(dòng)和任務(wù)，以及這些活動(dòng)和任務(wù)的組織、實(shí)施和管理。2、指定教材本課程指定教材為軟件工程 ，全國高等教育自學(xué)考試指導(dǎo)委員會(huì)組編，王立福主編，機(jī)械工業(yè)出版社出版， 2011 年版。新版教材與2000 年版相比，無論是內(nèi)容還是內(nèi)容的組織，都有了很大的變化。整個(gè)知識(shí)體系、章節(jié)安排、內(nèi)容選取都不一樣，這是考生一定要注意的。新版教材的內(nèi)容組織特點(diǎn)主要體現(xiàn)在：基于對(duì)軟件開發(fā)本質(zhì)的認(rèn)識(shí)，講解軟件工程的兩大技術(shù)問題：一是開發(fā)邏輯，二是開

2、發(fā)途徑。開發(fā)邏輯涉及軟件生存周期過程、軟件生存周期模型（有關(guān)過程、活動(dòng)和任務(wù)的組織框架）以及項(xiàng)目軟件生存周期的規(guī)劃與監(jiān)控。開發(fā)途徑涉及結(jié)構(gòu)化方法和面向?qū)ο蠓椒?，以及支持軟件評(píng)估所需要的軟件測(cè) 試技術(shù)等。3、章節(jié)體系 TOC o 1-5 h z 本課程共有8 章：第 1 章：回答什么是軟件開發(fā)的本質(zhì)第 2 章：軟件需求與軟件需求規(guī)約第 3 章：結(jié)構(gòu)化方法第 4 章：面向?qū)ο蠓椒?UML第 5 章：面向?qū)ο蠓椒?RUP第 6 章：軟件測(cè)試。第 7 章：軟件生存周期過程及管理第 8 章：集成化能力成熟度模型CMMI二、考情分析. 歷年真題的分布情況2011 年 10 月、 2012 年 01 月、

3、2012 年 10 月三次考試。 通過對(duì)2011年10月、2012年01月這兩次真題的分析，各章所占分值 的分布情況如下表所示:年份章名、題型、2011-102012-01一、緒論（單項(xiàng)、填空題）3分3分一、軟件需求與軟件需求規(guī)約911三、結(jié)構(gòu)化方法（單、填、簡(jiǎn)答、綜合）25分25分四、面向?qū)ο蠓椒?UML （單、填、簡(jiǎn)答）11分11分五、面向?qū)ο蠓椒?RUP （單、填、簡(jiǎn)答）12分12分六、軟件測(cè)試（單、填、簡(jiǎn)答、綜合）25分23分七、軟件生存周期過程及管理(單、填、簡(jiǎn))10分10分八、集成化能力成熟度模型 CMMI55從上面的統(tǒng)計(jì)數(shù)據(jù)可以看出：主要的分值分布在第3章和第6章，分別占到總分的

4、25%fe右。第1章和第8章的考核知識(shí)點(diǎn)相對(duì)較少。.題型分析本課程的考試題型分為：(1)單項(xiàng)選擇題，共15小題，每小題2分，共30分(2)填空題，共20個(gè)空，每空1分，共20分(3)簡(jiǎn)答題，共6小題，每小題5分，共30分(4)綜合應(yīng)用題，共2題，每題10分，共20分.復(fù)習(xí)方法(1)以教學(xué)大綱為準(zhǔn)繩。自學(xué)考試的原則是：考試范圍既不超出大綱又不超出教材范圍。所以考生一定根據(jù)教學(xué)大綱規(guī)定的考試內(nèi)容和考核要求，認(rèn)真學(xué)習(xí)教材, 要全面、系統(tǒng)了解教材中的基本概念、基本知識(shí)。要用2）有的放矢。在學(xué)習(xí)的過程中，為了達(dá)到“事半功倍”有限的時(shí)間去抓重點(diǎn)，對(duì)重點(diǎn)內(nèi)容要進(jìn)行深入細(xì)致的學(xué)習(xí)。3）注意學(xué)習(xí)方法，理論聯(lián)系實(shí)

5、際，注重理解重視理論聯(lián)系實(shí)際， 訓(xùn)練并逐漸提高運(yùn)用所學(xué)理論分析和解決實(shí)際案例的能力。考生應(yīng)當(dāng)注意在全面系統(tǒng)學(xué)習(xí)教材的基礎(chǔ)上，盡可能多地了解和分析實(shí)際案例，以便更深刻地領(lǐng)會(huì)教材的內(nèi)容，提高分析和解決實(shí)際問題的能力。4）合理安排時(shí)間，抓住學(xué)習(xí)重點(diǎn)根據(jù)實(shí)際情況自己安排，利用平時(shí)空余時(shí)間觀看網(wǎng)絡(luò)課件，形成基本的了解。接下來認(rèn)真地做一些練習(xí)題，不清楚的地方再回過頭去看看書，并注意對(duì)不同的知識(shí)點(diǎn)進(jìn)行比較，加深印象。第一章 緒論復(fù)習(xí)建議：本章內(nèi)容較少，主要是讓大家了解軟件工程的提出的背景-軟件危機(jī)以及軟件工程研究的內(nèi)容?？荚囶}目類型主要是單項(xiàng)選擇題、填空題，題量在3%5%之間。第一節(jié) 軟件工程概念的提出與發(fā)

6、展軟件危機(jī)1 ） 速度 ：軟件的發(fā)展水平遠(yuǎn)遠(yuǎn)滯后于硬件的發(fā)展水平，生產(chǎn)率低下，軟件制造仍然是一種人工集約生產(chǎn)方式2 ）質(zhì)量：軟件的質(zhì)量低下，不能滿足用戶的需求、適應(yīng)性差3 ）成本：軟件開發(fā)成本居高不下軟件開發(fā)的速度、 軟件制品的質(zhì)量、 軟件開發(fā)成本是軟件工程的三個(gè)核心問題軟件工程的發(fā)展20世紀(jì) 6080年代瀑布模型；過程化語言；支持工具2） 20 世紀(jì) 80 年代今軟件復(fù)用技術(shù)；軟件生產(chǎn)管理；面向?qū)ο笳Z言3）近幾年軟件復(fù)用技術(shù)：構(gòu)件技術(shù)、平臺(tái)技術(shù)、需求工程技術(shù)、領(lǐng)域分析技術(shù)、應(yīng)用集成技術(shù)等。第二節(jié) 軟件開發(fā)的本質(zhì)軟件 =程序 +文檔軟件開發(fā)的 本質(zhì) ： “映射” ，即實(shí)現(xiàn)問題空間的概念和處理邏

7、輯到解空間的概念和處理邏輯之間的映射。系統(tǒng)建模運(yùn)用所掌握的知識(shí)，通過抽象，給出系統(tǒng)的一個(gè)結(jié)構(gòu)。模型模型是一個(gè)抽象。模型是在特定意圖下所確定的角度和抽象層次上對(duì)物理系統(tǒng)的描述，通常包含對(duì)該系統(tǒng)邊界的描述、對(duì)系統(tǒng)內(nèi)各模型元素以及它們之間關(guān)系的語義描述。系統(tǒng)模型的類型1 ）概念模型：描述軟件是什么2 ）軟件模型：實(shí)現(xiàn)概念模型的軟件解決方案。包括設(shè)計(jì)模型、實(shí)現(xiàn)模型和部署模型。第二章 需求獲取復(fù)習(xí)建議：正確定義問題，是解決問題的基礎(chǔ)。需求獲取是軟件開發(fā)的第一步， 它的工作質(zhì)量決定了整個(gè)軟件開發(fā)工作的成敗， 因此本章的內(nèi)容是考核的重點(diǎn)內(nèi)容。考核的題目類型主要有：?jiǎn)雾?xiàng)選擇題、填空題、簡(jiǎn)答題，分值在10%左右

8、。內(nèi)容以基本概念、基本原理為主。第一節(jié) 需求與需求獲取需求的 定義一個(gè)需求是有關(guān)一個(gè)“要予構(gòu)造”的陳述，描述了待開發(fā)產(chǎn)品 / 系統(tǒng)功能能力、性能參數(shù)或其它性質(zhì)。需求的 基本性質(zhì)必要的無歧義的可測(cè)的可跟蹤的可測(cè)量的需求的 分類1） 功能需求，是整個(gè)需求的主體。非功能需求：性能需求、外部接口需求、設(shè)計(jì)約束和質(zhì)量屬性需求。能夠區(qū)分 哪些是功能需求，哪些是性能需求。接口需求的類別用戶接口硬件接口軟件接口通信接口內(nèi)存約束運(yùn)行地點(diǎn)需求設(shè)計(jì)約束需求法規(guī)政策硬件限制審計(jì)能力控制功能高級(jí)語言要求握手協(xié)議應(yīng)用的關(guān)鍵程度安全和保密質(zhì)量 屬性可靠性存活性可維護(hù)性用戶友好性需求發(fā)現(xiàn) 的技術(shù)自悟小組會(huì)提煉 TOC o 1

9、-5 h z 第二節(jié) 需求規(guī)約（SRS）需求規(guī)約的 定義/ 產(chǎn)品 / 系是一個(gè)軟件/ 產(chǎn)品 / 系統(tǒng)所有需求陳述的正式文檔，它表達(dá)了一個(gè)軟件統(tǒng)的概念模型。需求規(guī)約的基本性質(zhì)1 ）重要性和穩(wěn)定性程度：對(duì)需求進(jìn)行分級(jí)2 ）可修改的3 ）完整的：沒有被遺漏的需求4 ）一致的：不存在互斥的需求需求規(guī)約的格式IEEE標(biāo)準(zhǔn)830-1998（IEEE 1998）描述的需求規(guī)格說明書模板。半形式化的需求規(guī)約形式化的需求規(guī)約需求規(guī)約的 作用 需求規(guī)約是軟件開發(fā)組織和用戶之間一份事實(shí)上的技術(shù)合同書，是產(chǎn)品功能及其環(huán)境的體現(xiàn)需求規(guī)約是一個(gè)管理控制點(diǎn)對(duì)于產(chǎn)品 / 系統(tǒng)的而設(shè)計(jì)，需求規(guī)約是一個(gè)正式的、受控的起始點(diǎn)需求規(guī)

10、約是創(chuàng)建產(chǎn)品驗(yàn)收計(jì)劃和用戶指南的基礎(chǔ)第三章 結(jié)構(gòu)化方法復(fù)習(xí)建議：自頂向下，逐步求精。本章是整個(gè)課程的重點(diǎn)內(nèi)容，其基本思想、基本原理和基本方法是軟件工程理論體系中最經(jīng)典的內(nèi)容，考核題型涉及單項(xiàng)選擇題、填空題、簡(jiǎn)答題、綜合應(yīng)用題所有題目類型，占分值25%左右。建議考生在牢記基本概念、基本原理的基礎(chǔ)上，對(duì)綜合應(yīng)用題多下工夫，多做練習(xí)。第一節(jié) 結(jié)構(gòu)化需求分析需求分析面臨的 挑戰(zhàn)問題空間理解人與人之間的通信， “有效溝通”需求的變化性結(jié)構(gòu)化分析中的基本術(shù)語及表示方法數(shù)據(jù)流加工數(shù)據(jù)存儲(chǔ)數(shù)據(jù)源和數(shù)據(jù)潭數(shù)據(jù)流圖DFD圖用于建立系統(tǒng)功能 模型。是一種描述數(shù)據(jù)變換的圖形化工具，其中包含的元素可以是數(shù)據(jù)流、數(shù)據(jù)存儲(chǔ)

11、、加工、數(shù)據(jù)源和數(shù)據(jù)潭等。建模過程（繪制流程圖的過程）自頂向下、功能分解建立系統(tǒng)環(huán)境圖0 層圖：從 0 層圖開始對(duì)流程圖中的要素編號(hào)1 層圖【例題 】繪制數(shù)據(jù)流程圖（ 2008 年 10 月真題）某個(gè)學(xué)生成績(jī)管理系統(tǒng)的部分功能如下：1）基本信息管理：教務(wù)管理人員輸入或修改學(xué)期教學(xué)執(zhí)行計(jì)劃、學(xué)生名單和教師名單；2）學(xué)生選課：學(xué)生根據(jù)教學(xué)執(zhí)行計(jì)劃進(jìn)行選課；3）分配任課教師：教務(wù)管理人員為符合開課條件的課程分配教師，并打印任課通知單給教師；4） 成績(jī)管理： 每門課程的教師在考試評(píng)分結(jié)束后將考試成績(jī)交給教務(wù)管理人、成績(jī)統(tǒng)計(jì)分析員，教務(wù)管理人員輸入、維護(hù)成績(jī)，系統(tǒng)可生成成績(jī)單（發(fā)給學(xué)生） 表（發(fā)給教務(wù)管

12、理人員）請(qǐng)根據(jù)要求畫出該問題的分層數(shù)據(jù)流圖（要求畫出頂層和0層數(shù)據(jù)流圖）【解析】頂層圖：只包含數(shù)據(jù)源/數(shù)據(jù)潭以及相關(guān)的數(shù)據(jù)流和一個(gè)處理。任課通知學(xué)期教學(xué)執(zhí)行計(jì)劃成績(jī)選課信頂層圖教師信息0層圖要注意的問題：黑洞 (black hole) ，即只有輸入而沒有輸出。只有輸出而沒有輸入?；叶?(gray hole) ，即輸入不足以產(chǎn)生輸出。灰洞是經(jīng)常也是不易被察覺的錯(cuò)誤。加工處理只用來表示數(shù)據(jù)的處理和變化，避免將計(jì)算機(jī)命令作為處理。數(shù)據(jù)流必須起于且/ 或止于處理，即每一個(gè)數(shù)據(jù)流必須有一個(gè)處理與之有關(guān)，數(shù)據(jù)流不能起于數(shù)據(jù)存貯且止于一個(gè)數(shù)據(jù)源 / 數(shù)據(jù)潭或另一個(gè)數(shù)據(jù)存貯； 也不能起于某個(gè)實(shí)體且止于另一個(gè)數(shù)

13、據(jù)源 / 數(shù)據(jù)潭或數(shù)據(jù)存貯。數(shù)據(jù)字典定義數(shù)據(jù)流程圖中所有數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)。 TOC o 1-5 h z 順序結(jié)構(gòu)：+選擇結(jié)構(gòu)：|重復(fù)結(jié)構(gòu)：子界：m.n加工 的描述 1) 判定表判斷表 (Decision Table) 也稱為決策表，是一個(gè)二維表，它說明了每一種條件組合所產(chǎn)生的結(jié)果。該表分為四個(gè)象限(quadrants) 。左上限代表所有的條件左下限代表可能的結(jié)果c)右上限代表每一種條件的取值(用Y和N來表示)右下限用X 表示所對(duì)應(yīng)的條件組合所產(chǎn)生的結(jié)果【例題】 畫出顧客購貨的折扣政策的決策表。銷售商在給顧客的折扣時(shí)，要考慮付款日期和交易額這兩個(gè)因素。若付款日期在10天以內(nèi)(含10天)

14、，則當(dāng)交易額超過丫 10,000時(shí)，給予5%的折扣；當(dāng)交易額在 5,000到 10,000之間(含 5,000)時(shí)，給予3%的折扣；當(dāng)交易額低于 5,000時(shí)，沒有折扣。若付款日期超過10 天，則無論交易額多少，均不給任何折扣。【解析】判定樹判斷樹 (Decision Tree) 也稱為決策樹，是用來描述在一組不同的條件下，決策的行動(dòng)是根據(jù)不同條件及其取值來選擇的處理過程。業(yè)務(wù)規(guī)則的描述通?？梢允?用判斷樹這一過程描述工具。畫出顧客購貨的折扣政策的決策樹。銷售商在給顧客的折扣時(shí)，要考慮付款日期和交易額這兩個(gè)因素。若付款日期在10天以內(nèi)（含10天），則當(dāng)交易額超過丫 10,000時(shí)，給予5%的折

15、扣；當(dāng)交易額在 5,000到 10,000之間（含 5,000）時(shí)，給予3%的折扣；當(dāng)交易額低于 5,000時(shí)，沒有折扣。若付款日期超過10 天，則無論交易額多少，均不給任何折扣。解析：結(jié)構(gòu)化語言【例題】 用結(jié)構(gòu)化語言表達(dá)：顧客購貨的折扣政策。銷售商在給顧客的折扣時(shí)， 要考慮付款日期和交易額這兩個(gè)因素。 若付款日期在10天以內(nèi)（含10天），則當(dāng)交易額超過丫 10,000時(shí)，給予3%的折扣；當(dāng)交易額在 5,000到 10,000之間（含 5,000）時(shí)，給予2%的折扣；當(dāng)交易額低于 5,000時(shí)，沒有折扣。若付款日期超過10 天，則無論交易額多少，均不給任何折扣。IF 付款日期在10 日以上折扣

16、 =0ELSEIF 交易額 =10000折扣 =3%ELSEIF 交易額 =5000折扣 =2%ELSE折扣 =0需求驗(yàn)證驗(yàn)證每一個(gè)需求滿足5 個(gè)性質(zhì)驗(yàn)證需求規(guī)格說明書滿足4 個(gè)性質(zhì)第二節(jié) 結(jié)構(gòu)化設(shè)計(jì)分為總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)總體設(shè)計(jì)的 任務(wù)把系統(tǒng)的功能需求分配到一個(gè)特定的軟件體系結(jié)構(gòu)中。表達(dá)軟件體系結(jié)構(gòu)的 工具（ 1）模塊結(jié)構(gòu)圖2）層次圖(3) HIPO圖模塊結(jié)構(gòu)圖 結(jié)構(gòu)圖 （Structure Chart） 是對(duì)軟件總體結(jié)構(gòu)的一種圖形描述，它顯示了軟件的層次結(jié)構(gòu)、組織和通訊。也就是說，在結(jié)構(gòu)圖中，顯示了軟件是由哪些模塊組成的，這些模塊按照什么樣的層次結(jié)構(gòu)組織在一起以及模塊之間通過什么接口聯(lián)系在

17、一起。結(jié)構(gòu)圖也稱之為控制結(jié)構(gòu)圖、模塊結(jié)構(gòu)圖或系統(tǒng)結(jié)構(gòu)圖。模塊符號(hào)模塊調(diào)用關(guān)系模塊間的數(shù)據(jù)傳遞模塊間的控制信息傳遞循環(huán)調(diào)用結(jié)構(gòu)選擇調(diào)用結(jié)構(gòu)數(shù)據(jù)存儲(chǔ)層次圖層次圖中一個(gè)矩形框代表一個(gè)模塊，框間的連線表示調(diào)用關(guān)系（位于上方的矩形框所代表的模塊調(diào)用位于下方的矩形框所代表的模塊)HIPO圖HIPO圖是美國 舊M公司發(fā)明的“層次圖加輸入/處理/輸出圖”的英文縮寫。為 了使HIPO圖具有可追蹤性，在H圖(即層次圖)里除了頂層的方框之外，每個(gè)方框都加了編號(hào)。H圖+IPO圖總體設(shè)計(jì)步驟將DFD圖映射為設(shè)計(jì)層面的模塊及模塊調(diào)用。變換流(Transform Flow)?；谧儞Q流的數(shù)據(jù)流程圖是一個(gè)線性的順序 結(jié)構(gòu)，由

18、輸入臂、輸出臂和變換中心三部分組成。其中變換中心使系統(tǒng)數(shù)據(jù)發(fā)生本 質(zhì)的變化，輸入臂將物理輸入變換成邏輯輸入，而輸出臂則將邏輯輸出變換成物理 輸出。事務(wù)流(Transaction Flow)。事務(wù)流的數(shù)據(jù)流程圖中有一個(gè)事務(wù)處理中 心，它將輸入分為許多相互平行的加工路徑，然后根據(jù)輸入的屬性，選擇某一加工 路徑。如下圖所示。業(yè)務(wù)中心完成以下任務(wù)：接收事務(wù)(即輸入數(shù)據(jù))；分析每個(gè)事務(wù)并確定它的類型;根據(jù)事務(wù)的類型選取一條活動(dòng)通路?！纠}】控制結(jié)構(gòu)圖的繪制根據(jù)數(shù)據(jù)計(jì)算的數(shù)據(jù)流圖：畫出以轉(zhuǎn)換為中心的控制結(jié)構(gòu)圖?！窘馕觥窟@是一個(gè)典型的以“轉(zhuǎn)換為中心”結(jié)構(gòu)的分解，可以轉(zhuǎn)化為:數(shù)據(jù)計(jì)算輸入數(shù)據(jù)數(shù)據(jù)求解打印輸出總

19、結(jié)：任何處理都可以劃分為兩種轉(zhuǎn)換類型之一：以轉(zhuǎn)換為中心的分解和以業(yè) 務(wù)為中心結(jié)構(gòu)的分解。【例題】產(chǎn)生固定資產(chǎn)資料數(shù)據(jù)流程圖如下， 做出以業(yè)務(wù)為中心的模塊控制結(jié)構(gòu)圖【解析】這是以業(yè)務(wù)為中心的處理，根據(jù)模板，可以轉(zhuǎn)化為：報(bào)表制作報(bào)表類型報(bào)表調(diào)度.模塊化“分而治之”和“抽象”。把一個(gè)待開發(fā)的軟件分解成若干個(gè)簡(jiǎn)單的、具有高內(nèi)聚低耦合的模塊， 這一過程稱為模塊化。模塊化是系統(tǒng)設(shè)計(jì)基本原理/原則之一。.內(nèi)聚(Cohesion)是指一個(gè)模塊內(nèi)部個(gè)成分之間相互關(guān)聯(lián)程度的度量。也就是說，凝聚是對(duì)模塊內(nèi)各處理動(dòng)作組合強(qiáng)度的一種度量。很顯然，一個(gè)模塊的內(nèi)聚越大越好。(1)偶然凝聚可維護(hù)性最差(2)邏輯凝聚時(shí)間凝聚(

20、4)過程內(nèi)聚6）順序凝聚7）功能凝聚可維護(hù)性最好模塊 耦合耦合 （coupling） 是對(duì)兩個(gè)模塊之間聯(lián)接程度的一種度量。模塊間的依賴程度越大，則其耦合程度也就越大；反之，模塊間的依賴程度越小，則其耦合程度也就越小。很顯然， 為了使軟件具有較好的可維護(hù)性和可修改性， 模塊間的關(guān)聯(lián)程度即耦合程度應(yīng)越小越好。因?yàn)轳詈铣潭仍叫?，表明模塊間的獨(dú)立程度越大，這樣在修改一個(gè)模塊時(shí)，對(duì)其它模塊的影響程度就越小，從而使模塊的修改工作局限于一個(gè)最小范圍之內(nèi)。內(nèi)容耦合公共耦合數(shù)據(jù)耦合控制耦合耦合原則 是：盡量用數(shù)據(jù)耦合，少用控制耦合，限制公共耦合的范圍，避免使用內(nèi)容耦合。啟發(fā)式規(guī)則高內(nèi)聚、低耦合。1 ）改進(jìn)軟件結(jié)

21、構(gòu)，提高軟件獨(dú)立性。模塊分解2 ）模塊規(guī)模適中3 ）力求深度、寬度、扇出、扇入適中。深度：表示其控制的層數(shù)。寬度：同一層次上模塊總數(shù)的最大值。扇出：一個(gè)模塊直接控制的下級(jí)模塊的數(shù)目。扇入：有多少個(gè)上級(jí)模塊直接調(diào)用它。原則 ：頂層模塊扇出比較大，中間層模塊扇出較小，底層模塊具有較大的扇入。4 ） 盡量使模塊的作用域在其控制域內(nèi)。模塊的控制域：這個(gè)模塊本身以及所有直接或間接從屬它的模塊的集合。模塊的作用域：受該模塊內(nèi)一個(gè)判斷所影響的所有模塊的集合。盡力降低模塊接口的復(fù)雜度力求模塊功能可以預(yù)測(cè).詳細(xì)設(shè)計(jì)具體描述模塊結(jié)構(gòu)圖中的每一模塊，即給出實(shí)現(xiàn)模塊功能的實(shí)施機(jī)制，包括一組例程和數(shù)據(jù)結(jié)構(gòu)。.結(jié)構(gòu)化程序

22、設(shè)計(jì)方法一種基于結(jié)構(gòu)的編程方法， 即采用順序結(jié)構(gòu)、選擇結(jié)構(gòu)和重復(fù)結(jié)構(gòu)進(jìn)行編程，其中每一結(jié)構(gòu)只允許一個(gè)入口和一個(gè)出口。三種基本的控制結(jié)構(gòu)：(a)順序結(jié)構(gòu)，先執(zhí)行 A再執(zhí)行B;(b) IF-THEN-ELSE型選擇(分支)結(jié)構(gòu)；DO-WHILE型循環(huán)結(jié)構(gòu)14.詳細(xì)設(shè)計(jì)工具(1)程序流程圖程序流程圖：程序流程圖又稱為程序框圖，它是歷史最悠久使用最廣泛的描述過程設(shè)計(jì)的方法，然而它也是用得最混亂的一種方法。(2)盒圖(N-S圖)出于要有一種不允許違背結(jié)構(gòu)程序設(shè)計(jì)精神的圖形工具的考慮，Nassi和Shneiderman提出了盒圖，又稱為 N-S圖。(a)順序；(b) IF-THEN-ELSE型分支； CA

23、SE型多分支；(d)循環(huán)；(e)調(diào)用子程序A(3) PAD圖PAD是問題分析圖(Problem Analysis Diagram)的英文縮寫，自 1973年由日本日立公司發(fā)明以后，已得到一定程度的推廣。它用二維樹形結(jié)構(gòu)的圖來表示程序的控制流，將這種圖翻譯成程序代碼比較容易。下圖給出PAD圖的基本符號(hào)。(4)類程序設(shè)計(jì)語言PDLPDL也稱為偽碼，它是用正文形式表示數(shù)據(jù)和處理過程的設(shè)計(jì)工具。PDL具有嚴(yán)格的關(guān)鍵字外部語法，用于定義控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)；另一方面，PDL表示實(shí)際操作和條件的內(nèi)部語法通常又是靈活自由的，以便可以適應(yīng)各種工程項(xiàng)目的需要。因此，一般說來PDL是一種“混雜”語言，它使用一種語言

24、(通常是某種自然語言)的詞匯，同時(shí)卻使用另一種語言(某種結(jié)構(gòu)化的程序設(shè)計(jì)語言)的可以作為注釋工具直接插在源程序中間完整準(zhǔn)確地描述滿足需求規(guī)約所要求的所有功能模塊，以及伴隨功能模塊而出 現(xiàn)的非功能機(jī)制。設(shè)計(jì)規(guī)約包括概要設(shè)計(jì)規(guī)約和詳細(xì)設(shè)計(jì)規(guī)約。概要設(shè)計(jì)規(guī)約指明高層軟件體系結(jié)構(gòu)。系統(tǒng)環(huán)境軟件模塊的結(jié)構(gòu)模塊描述文件結(jié)構(gòu)和全局?jǐn)?shù)據(jù)文件的邏輯結(jié)構(gòu)測(cè)試需求詳細(xì)設(shè)計(jì)規(guī)約各處理過程的算法算法所涉及的全部數(shù)據(jù)結(jié)構(gòu)的描述【例題】根據(jù)下列變換型的數(shù)據(jù)流圖，設(shè)計(jì)出初始軟件結(jié)構(gòu)圖題40圖【答案】輸入模塊變換模塊輸出模塊G輸【解析】 入輸這是一入個(gè)典型的變換型數(shù)據(jù)流程圖,將其轉(zhuǎn)換為模塊控制圖時(shí)，第一層可歌分解為三個(gè)模塊：輸

25、大模塊、變換模塊、輸出模塊。包二模塊還可以繼續(xù)分解第四章面向?qū)ο蠓椒║ML復(fù)習(xí)建議：以不變應(yīng)萬變。統(tǒng)一建模語言（Unified Modeling Language , UMLUM亮目前流行的建模語言，特別是在網(wǎng)站開發(fā)中廣泛應(yīng)用。UML及很多的圖，每一種圖都有不同的圖形符號(hào)、作用，在什么情況下用何種 圖來描述是本章的重點(diǎn)內(nèi)容?？己祟}目類型包括單項(xiàng)選擇題、填空題、簡(jiǎn)答題，分值在10%15%之間。需要考生掌握各種UML圖的作用。面向?qū)ο蠼＿^程的步驟：需求獲取a） 建立用況（ use case ）模型和用況場(chǎng)景需求分析建立活動(dòng)圖和狀態(tài)圖類圖（建立域模型）順序圖（實(shí)現(xiàn)用況）編寫需求規(guī)格說明書需求驗(yàn)證第

26、一節(jié)UML術(shù)語表對(duì)象（ object ）對(duì)象（ object ）是系統(tǒng)中用來描述客觀事物的一個(gè)實(shí)體。一個(gè)對(duì)象由一組屬性 和對(duì)這組屬性進(jìn)行操作的一組方法組成。對(duì)象只描述客觀事物本質(zhì)的與系統(tǒng)目標(biāo)有關(guān)的特征。對(duì)象之間通過消息通信，一個(gè)對(duì)象通過向另一個(gè)對(duì)象發(fā)送消息激活某一個(gè)功能。類類( Class )是具有相同屬性、操作、關(guān)系和語義的一組對(duì)象的集合，它為屬于該類的全部對(duì)象提供了同一的抽象描述，其內(nèi)部包括屬性和服務(wù)兩個(gè)主要部分。類有超類( Superclass )和子類( Subclass )之分。(相對(duì)而言)對(duì)象與類的關(guān)系猶如程序設(shè)計(jì)語言中變量和類型的關(guān)系。對(duì)象是類的實(shí)例( Instance ) 。類

27、在類圖上使用包含三個(gè)部分的矩形來描述，如下圖 4-1 所示。最上面的部分顯示類的名稱，中間部分包含類的屬性，最下面的部分包含類的操作(或者說 方法 )。圖 4-1 ：類圖中的示例類對(duì)象屬性對(duì)象或類的屬性( attributes )描述了對(duì)象的具體特征。屬性有屬性名和屬性值(或稱屬性狀態(tài)) 。每條屬性可以包括屬性的可見性、屬性名稱、類型、缺省值和約束特性。UMLB定類的屬性的語法為:可見性 屬性名 ： 類型 = 缺省值 性質(zhì)串 可見性： public （+） 、 protected（#） 、 private （- ）、包內(nèi)的（）類的操作通常也被稱為功能，但是它們被約束在類的內(nèi)部，只能作用到該類的

28、對(duì)象上。操作名、返回類型和參數(shù)表組成操作界面。UML定操作白語法為：可見性 操作名 （參數(shù)表） : 返回類型 性質(zhì)串 例如：+取客戶地址（客戶名: 字符串） ：字符串接口接口是操作的一個(gè)集合，其中每個(gè)操作描述了類、構(gòu)件或子系統(tǒng)的一個(gè)服務(wù)。采用具有分欄和關(guān)鍵字 的矩形符號(hào)來表示采用小圓圈和半圓圈來表示協(xié)作協(xié)作是一個(gè)交互，涉及交互的三要素：交互各方、交互方式以及交互內(nèi)容。用況 ( use case ) / 用況對(duì)一組動(dòng)作序列的描述，系統(tǒng)執(zhí)行這些動(dòng)作應(yīng)產(chǎn)生對(duì)特定參與者有值的、可觀察的結(jié)果。主動(dòng)類至少具有一個(gè)進(jìn)程或線程的類。能夠啟動(dòng)系統(tǒng)的控制活動(dòng)，并且其對(duì)象的行為通常與其它元素行為并發(fā)的。表示方法：兩

29、條豎線。構(gòu)件系統(tǒng)設(shè)計(jì)中的一種模塊化部件，通過外部接口隱藏了它的內(nèi)部實(shí)現(xiàn)。制品系統(tǒng)中包含物理信息的、可替代的物理部件。節(jié)點(diǎn)節(jié)點(diǎn)是在運(yùn)行時(shí)存在的物理元素，通常表示一種具有記憶能力和處理能力的計(jì)算機(jī)資源。關(guān)聯(lián) ( Association )關(guān)聯(lián)反映了類和類之間的靜態(tài)關(guān)系。關(guān)聯(lián)在模型中，特別是在永久業(yè)務(wù)對(duì)象模型中是最基本的關(guān)系。鏈（ link ）是對(duì)象之間具有特定語義關(guān)系的抽象。關(guān)聯(lián)名導(dǎo)航角色可見性多重性：多重性（ Multiplicity ）定義了與一個(gè)對(duì)象 / 類相聯(lián)系的對(duì)象/類出現(xiàn)一次，該對(duì)象/ 類可能出現(xiàn)的最小和最大的數(shù)目。限定符聚合：一個(gè)類是另一類的一部分。組合：是聚合的一種特殊形式關(guān)聯(lián)類約

30、束泛化 / 繼承繼承：特殊類（子類）的對(duì)象擁有其一般類（超類）的全部屬性與服務(wù)，稱作特殊類對(duì)一般類的繼承( Inheritance ) 。利用繼承( inheritance ) ，子類可以繼 承父類的屬性和方法。子類父類也可分別叫做特殊類一般類、子類超類、派生類基類等。繼承反映了類之 間的一種聯(lián)系或結(jié)構(gòu):一般 -特殊結(jié)構(gòu)， 也稱分類結(jié)構(gòu)( Classification Structure ) ，是由一組具有繼承關(guān)系的類所組成的結(jié)構(gòu)。僅由一些單繼承關(guān)系的類形成的結(jié)構(gòu)又稱作層次結(jié)構(gòu)( Hierarchy Structure ) ；由一些存在多繼承關(guān)系的類形成的結(jié)構(gòu)又稱作網(wǎng)格結(jié)構(gòu)( Lattice

31、Structure ) 。多態(tài)性( Polymorphism )是指一般類中定義的屬性或服務(wù)被特殊類繼承之后，可以具有不同的數(shù)據(jù)類型或表現(xiàn)出不同的行為。這使得同一屬性或服務(wù)名在一般類及其各個(gè)特殊類中具有不同的語義。多態(tài)是指用同一界面形式表示不同對(duì)象類中的不同實(shí)現(xiàn)的能力。多態(tài)性的實(shí)現(xiàn)基于兩個(gè)基本原理：封裝和泛化。多態(tài)性實(shí)現(xiàn)的方法：1)泛化2)定義一個(gè)抽象類接口類細(xì)化是類目之間的語義關(guān)系，其中一個(gè)類目規(guī)約了保證另一類目執(zhí)行的契約。用空心三角形的虛線表示。依賴依賴是一種使用關(guān)系，用于描述一個(gè)類目使用另一類目的信息和服務(wù)。用有向虛線段表示。包包是模型元素的一個(gè)分組，一個(gè)包本身可以被嵌套在其它包中，并且

32、可以含有子包和其它類型的模型元素。第二節(jié) UML 的模型表達(dá)格式圖形化工具。圖的類別：（一）結(jié)構(gòu)圖1）對(duì)象結(jié)構(gòu)建模類圖和對(duì)象圖2）應(yīng)用結(jié)構(gòu)建模包圖、構(gòu)件圖、部署圖、組合結(jié)構(gòu)圖（二）行為圖對(duì)象交互建模順序圖、協(xié)作圖（通信圖、交互綜述圖、定時(shí)圖） 、狀態(tài)圖（狀 態(tài)機(jī)）對(duì)象行為建模用況圖、活動(dòng)圖類圖任何系統(tǒng)都需要從兩方面進(jìn)行描述：結(jié)構(gòu)信息和行為信息。系統(tǒng)的組成表達(dá)了系統(tǒng)各組成要素之間的聯(lián)系，稱為結(jié)構(gòu)；這些組成要素的執(zhí)行邏輯稱為行為。在面向?qū)ο蠓椒ㄖ?，系統(tǒng)的結(jié)構(gòu)信息是通過類圖（ class diagram ）來描述的；而系統(tǒng)行為信息則通過用況圖、交互圖（包括順序圖和協(xié)作圖）和狀態(tài)圖來描述的。也就是說，

33、前者說明了系統(tǒng)的組成部分是什么，而后者則說明了系統(tǒng)做什么。類圖（ class diagram ） 表達(dá)了系統(tǒng)的靜態(tài)結(jié)構(gòu)信息， 即系統(tǒng)是由哪些類組成的，這些類之間的關(guān)系是什么。類圖顯示系統(tǒng)各個(gè)部分以及怎樣將它們組裝起來; 但卻不能模擬組裝后系統(tǒng)的工作情況。構(gòu)造類圖的三個(gè)關(guān)鍵問題是：系統(tǒng)中有哪些需要關(guān)心的類？這些類是如何描述的？這些類之間的聯(lián)系是什么？創(chuàng)建一個(gè)系統(tǒng)的類圖，要涉及4 方面的工作：模型化待建系統(tǒng)中的概念，形成類圖中基本元素2）模型化待建系統(tǒng)中的各種關(guān)系，形成該系統(tǒng)的初始關(guān)系。3）模型化系統(tǒng)中的協(xié)作，給出該系統(tǒng)的最終類圖。4）模型化邏輯數(shù)據(jù)庫模式用況圖 （ use case 圖）用況是對(duì)

34、一個(gè)參與者 （ actor ） 使用系統(tǒng)的一項(xiàng)功能時(shí)所進(jìn)行的交互過程的一個(gè)文字描述序列。用況是系統(tǒng)、子系統(tǒng)或類與 外部的參與者（ actor ）交互的動(dòng)作序列的說明，包括可選的動(dòng)作序列和會(huì)出現(xiàn)異常的動(dòng)作序列。用況圖（Use Case Diagram）是指反映活動(dòng)者，系統(tǒng)邊界所封閉的用況，及活動(dòng) 者與用況之間，用況與用況之間關(guān)系的一種圖。個(gè) 模型元素：1 ）主題2 ）用況3 ） 參與者：系統(tǒng)用戶：是最常見的一種角色。是直接使用系統(tǒng)的人另一個(gè)系統(tǒng)：如DSS可作為MIS的一個(gè)活動(dòng)者。補(bǔ)貨系統(tǒng)可作為定單處理系統(tǒng)的活動(dòng)者。時(shí)間：當(dāng)經(jīng)過一定時(shí)間觸發(fā)系統(tǒng)中的某個(gè)事件時(shí)，時(shí)間就成了角色。例如定期的某些業(yè)務(wù)處理

35、工作。關(guān)聯(lián)泛化依賴.狀態(tài)圖對(duì)象或者類的整體行為的某些規(guī)則所能適應(yīng)的對(duì)象或類的狀況、情況、條件、形式或生存周期。僅當(dāng)對(duì)象的行為規(guī)則不同時(shí)，才稱對(duì)象處于不同的狀態(tài)。在由對(duì)象的全部屬性的屬性值集合所構(gòu)成的笛卡兒乘積中的每一個(gè)等價(jià)集合(即，使對(duì)象的服務(wù)呈現(xiàn)相同行為規(guī)則的屬性值的集合)稱之為對(duì)象的一種狀態(tài)。例如，對(duì)象發(fā)票(invoice )可以根據(jù)其付款的情況分為三個(gè)狀態(tài)：未付款(unpaid )、部分付款(partly paid )以及付清款(fully paid )。狀態(tài)圖(state chart diagram )使用狀態(tài)、事件和轉(zhuǎn)換來記錄對(duì)象在其生命周期中所歷經(jīng)的狀態(tài)序列。對(duì)象的初始狀態(tài)是圖中任

36、何事件都未對(duì)該對(duì)象起作用時(shí)的狀態(tài)。狀態(tài)代表對(duì)象生命周期中的某一瞬間。轉(zhuǎn)換表明作為對(duì)事件的響應(yīng)結(jié)果， 對(duì)象將從一種狀態(tài)轉(zhuǎn)換到另一種狀態(tài)并執(zhí)行某個(gè)動(dòng)作。觸發(fā)狀態(tài)轉(zhuǎn)換的事件在狀態(tài)轉(zhuǎn)換字符串中命名。 雙擊一個(gè)狀態(tài)轉(zhuǎn)換， 除事件簽名以外，還可用字符串為其加注臨界條件、動(dòng)作表達(dá)式等標(biāo)簽。. 順序圖順序圖( sequence diagram )表示了對(duì)象之間傳送消息的時(shí)間順序，也就是對(duì)象之間的交互順序， 這些交互是指在場(chǎng)景或用況的事件流中發(fā)生的。 每一個(gè)對(duì)象 (類)用一條生命線來表示即用垂直線代表整個(gè)交互過程中對(duì)象的生命期。生命線之間的箭頭連線代表消息。順序圖中的基本元素包括：活動(dòng)者，指用況中的活動(dòng)者。對(duì)象

37、，指在用況中的內(nèi)部對(duì)象。生命線：在順序圖中的一個(gè)對(duì)象下面的豎線，用以顯示這個(gè)對(duì)象的生命期。時(shí)間從上到下流過。生命線實(shí)際上顯示了消息的順序，在生命線之上的消息比在它 之下的消息先發(fā)生。在生命線中的棒形方框表示的是活動(dòng)生命線，用以強(qiáng)調(diào)一個(gè)對(duì) 象只有在一個(gè)場(chǎng)景的部分中處于活動(dòng)狀態(tài)。消息， 指場(chǎng)景內(nèi)由事件流定義的內(nèi)部事件成為在對(duì)象和活動(dòng)者或其他對(duì)象之間的消息。? 同步消息返回消息。同步消息假定有一個(gè)返回消息。同步消息用有實(shí)心的箭頭表示；返回消息用虛線、箭頭也不是實(shí)心來表示。? 反身消息消息的發(fā)送方和接收方是同一個(gè)對(duì)象。? 異步消息沒有返回值的消息。用非實(shí)心箭頭表示。? 定時(shí)消息對(duì)消息附加時(shí)間約束條件，

38、包括：發(fā)送時(shí)間、接收時(shí)間、已用時(shí)間等。第五章 面向?qū)ο蠓椒?RUP復(fù)習(xí)建議 ：RUP（ Rational Unified Process ，統(tǒng)一軟件開發(fā)過程）。掌握RU喳解決下列三個(gè)問題的基本方法。表達(dá)基本信息的術(shù)語用于組織基本信息的表達(dá)格式3） 在不同抽象層之間進(jìn)行“映射”的過程指導(dǎo)。本章考核題目類型包括單項(xiàng)選擇題、填空題、簡(jiǎn)答題，分值在10%15%L間。重點(diǎn)要掌握基本概念、基本原理。.迭代式開發(fā)在軟件開發(fā)的早期階段就想完全、準(zhǔn)確的捕獲用戶的需求幾乎是不可能的。實(shí) 際上，我們經(jīng)常遇到的問題是需求在整個(gè)軟件開發(fā)工程中經(jīng)常會(huì)改變。迭代式開發(fā) 允許在每次迭代過程中需求可能有變化，通過不斷細(xì)化來加深

39、對(duì)問題的理解。迭代 式開發(fā)不僅可以降低項(xiàng)目的風(fēng)險(xiǎn)，而且每個(gè)迭代過程都可以執(zhí)行版本結(jié)束，可以鼓 舞開發(fā)人員。.管理需求確定系統(tǒng)的需求是一個(gè)連續(xù)的過程，開發(fā)人員在開發(fā)系統(tǒng)之前不可能完全詳細(xì) 的說明一個(gè)系統(tǒng)的真正需求。RUP苗述了如何提取、組織系統(tǒng)的功能和約束條件并 將其文檔化，用況和腳本的使用已被證明是捕獲功能性需求的有效方法。.體系結(jié)構(gòu)組件使重用成為可能，系統(tǒng)可以由組件組成?；讵?dú)立的、可替換的、模塊化 組件的體系結(jié)構(gòu)有助于降低管理復(fù)雜性，提高重用率。RUP苗述了如何設(shè)計(jì)一個(gè)有彈性的、能適應(yīng)變化的、易于理解的、有助于重用的軟件體系結(jié)構(gòu)。.可視化建模RUP主往和UML系在一起，對(duì)軟件系統(tǒng)建立可視化

40、模型幫助人們提供管理軟件 復(fù)雜性的能力。RU喑訴我們?nèi)绾慰梢暬膶?duì)軟件系統(tǒng)建模，獲取有關(guān)體系結(jié)構(gòu)于 組件的結(jié)構(gòu)和行為信息。.驗(yàn)證軟件質(zhì)量在RU中軟件質(zhì)量評(píng)估不再是事后進(jìn)行或單獨(dú)小組進(jìn)行的分離活動(dòng)，而是內(nèi)建 于過程中的所有活動(dòng)，這樣可以及早發(fā)現(xiàn)軟件中的缺陷。.控制軟件變更迭代式開發(fā)中如果沒有嚴(yán)格的控制和協(xié)調(diào)，整個(gè)軟件開發(fā)過程很快就陷入混亂 之中，RUP苗述了如何控制、跟蹤、監(jiān)控、修改以確保成功的迭代開發(fā)。RUP!過軟件開發(fā)過程中的制品，隔離來自其他工作空間的變更，以此為每個(gè)開發(fā)人員建立安 全的工作空間。第一節(jié)RUP的特點(diǎn)以用況驅(qū)動(dòng)的、以 體系結(jié)構(gòu)為中心的迭代、增量式開發(fā)。用況驅(qū)動(dòng)(1)用況是能夠

41、向用戶提供有價(jià)值結(jié)果的系統(tǒng)中的一種功能(2)用況獲取的是功能需求在系統(tǒng)的生存周期中，以用況作為基礎(chǔ)，驅(qū)動(dòng)系統(tǒng)有關(guān)人員對(duì)所要建立系統(tǒng)的功能需求進(jìn)行交流，驅(qū)動(dòng)系統(tǒng)分析、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試等活動(dòng)，包括制定計(jì)劃、分配任務(wù)、監(jiān)控執(zhí)行和進(jìn)行測(cè)試等，并將它們有機(jī)地組織在一起，使各個(gè)階段中都可以回溯到用戶的實(shí)際需求。以體系結(jié)構(gòu)為中心系統(tǒng)體系結(jié)構(gòu)：是對(duì)系統(tǒng)語義的概括描述，對(duì)所有項(xiàng)目有關(guān)人員都是可以理解的。迭代與增量迭代是重復(fù)的部分增量是增加的部分一個(gè)迭代是一個(gè)完整的開發(fā)循環(huán)，產(chǎn)生一個(gè)可執(zhí)行的產(chǎn)品版本，是最終產(chǎn)品的一個(gè)子集，它增量式地發(fā)展，從一個(gè)迭代過程到另一個(gè)迭代過程到成為最終的系統(tǒng)。圖 5-1 RUP 迭代模型

42、二維開發(fā)模型：RU嗽件開發(fā)生命周期是一個(gè)二維的軟件開發(fā)模型。橫軸通過時(shí)間組織，是過程展開的生命周期特征，體現(xiàn)開發(fā)過程的動(dòng)態(tài)結(jié)構(gòu)，用來描述它的術(shù)語主要包括周期(Cycle ) 、階段(Phase) 、迭代( Iteration )和里程碑(Milestone ) ；縱軸以內(nèi)容來組織為自然的邏輯活動(dòng)，體現(xiàn)開發(fā)過程的靜態(tài)結(jié)構(gòu)，用來描述它的術(shù)語主要包括活 動(dòng)(Activity )、產(chǎn)物(Artifact )、工作者(Worker)和工作流(Workflow)。如圖 1:RU時(shí)的軟件生命周期在時(shí)間上被分解為四個(gè)順序的階段，分別是：初始階段 (Inception )、細(xì)化階段(Elaboration )、

43、構(gòu)造階段(Construction )和交付階段 (Transition )。每個(gè)階段結(jié)束于一個(gè)主要的里程碑( Major Milestones );每個(gè)階 段本質(zhì)上是兩個(gè)里程碑之間的時(shí)間跨度。在每個(gè)階段的結(jié)尾執(zhí)行一次評(píng)估以確定這 個(gè)階段的目標(biāo)是否已經(jīng)滿足。如果評(píng)估結(jié)果令人滿意的話，可以允許項(xiàng)目進(jìn)入下一 個(gè)階段。圖5-2 : RUP二維開發(fā)模型(1)初始階段初始階段的目標(biāo)是為系統(tǒng)建立商業(yè)案例并確定項(xiàng)目的邊界。為了達(dá)到該目的必 須識(shí)別所有與系統(tǒng)交互的外部實(shí)體，在較高層次上定義交互的特性。本階段具有非 常重要的意義，在這個(gè)階段中所關(guān)注的是整個(gè)項(xiàng)目進(jìn)行中的業(yè)務(wù)和需求方面的主要 風(fēng)險(xiǎn)。對(duì)于建立在原有系

44、統(tǒng)基礎(chǔ)上的開發(fā)項(xiàng)目來講，初始階段可能很短。初始階段 結(jié)束時(shí)是第一個(gè)重要的里程碑：生命周期目標(biāo)( Lifecycle Objective )里程碑。生 命周期目標(biāo)里程碑評(píng)價(jià)項(xiàng)目基本的生存能力。(2)細(xì)化階段細(xì)化階段的目標(biāo)是分析問題領(lǐng)域，建立健全的體系結(jié)構(gòu)基礎(chǔ)，編制項(xiàng)目計(jì)劃，淘汰項(xiàng)目中最高風(fēng)險(xiǎn)的元素。為了達(dá)到該目的，必須在理解整個(gè)系統(tǒng)的基礎(chǔ)上，對(duì)體 系結(jié)構(gòu)作出決策，包括其范圍、主要功能和諸如性能等非功能需求。同時(shí)為項(xiàng)目建 立支持環(huán)境，包括創(chuàng)建開發(fā)案例，創(chuàng)建模板、準(zhǔn)則并準(zhǔn)備工具。細(xì)化階段結(jié)束時(shí)第 二個(gè)重要的里程碑：生命周期結(jié)構(gòu)( Lifecycle Architecture )里程碑。生命周期 結(jié)構(gòu)

45、里程碑為系統(tǒng)的結(jié)構(gòu)建立了管理基準(zhǔn)并使項(xiàng)目小組能夠在構(gòu)建階段中進(jìn)行衡 量。此刻，要檢驗(yàn)詳細(xì)的系統(tǒng)目標(biāo)和范圍、結(jié)構(gòu)的選擇以及主要風(fēng)險(xiǎn)的解決方案。(3)構(gòu)造階段在構(gòu)建階段，所有剩余的構(gòu)件和應(yīng)用程序功能被開發(fā)并集成為產(chǎn)品，所有的功能被詳細(xì)測(cè)試。從某種意義上說，構(gòu)建階段是一個(gè)制造過程，其重點(diǎn)放在管理資源及 控制運(yùn)作以優(yōu)化成本、進(jìn)度和質(zhì)量。構(gòu)建階段結(jié)束時(shí)是第三個(gè)重要的里程碑：初始 功能(Initial Operational )里程碑。初始功能里程碑決定了產(chǎn)品是否可以在測(cè)試 環(huán)境中進(jìn)行部署。此刻，要確定軟件、環(huán)境、用戶是否可以開始系統(tǒng)的運(yùn)作。此時(shí) 的產(chǎn)品版本也常被稱為“ beta”版。(4)交付階段交付階

46、段的重點(diǎn)是確保軟件對(duì)最終用戶是可用的。交付階段可以跨越幾次迭代， 包括為發(fā)布做準(zhǔn)備的產(chǎn)品測(cè)試，基于用戶反饋的少量的調(diào)整。在生命周期的這一點(diǎn) 上，用戶反饋應(yīng)主要集中在產(chǎn)品調(diào)整，設(shè)置、安裝和可用性問題，所有主要的結(jié)構(gòu) 問題應(yīng)該已經(jīng)在項(xiàng)目生命周期的早期階段解決了。在交付階段的終點(diǎn)是第四個(gè)里程碑：產(chǎn)品發(fā)布(Product Release)里程碑。此時(shí)，要確定目標(biāo)是否實(shí)現(xiàn)，是否應(yīng)該開始另一個(gè)開發(fā)周期。在一些情況下這個(gè)里程碑可能與下一個(gè)周期的初始階段的結(jié) 束重合。第二節(jié)核心工作流RUP43有9個(gè)核心工作流，分為 6個(gè)核心過程工作流(Core Process Workflows) 和3個(gè)核心支持工作流(Co

47、re Supporting Workflows )。盡管6個(gè)核心過程工作流 可能使人想起傳統(tǒng)瀑布模型中的幾個(gè)階段，但應(yīng)注意迭代過程中的階段是完全不同 的，這些工作流在整個(gè)生命周期中一次又一次被訪問。9個(gè)核心工作流在項(xiàng)目中輪流被使用，在每一次迭代中以不同的重點(diǎn)和強(qiáng)度重復(fù)。(1)商業(yè)建模商業(yè)建模(Business Modeling )工作流描述了如何為新的目標(biāo)組織開發(fā)一個(gè)構(gòu) 想，并基于這個(gè)構(gòu)想在商業(yè)用況模型和商業(yè)對(duì)象模型中定義組織的過程，角色和責(zé) 任。(2)需求需求(Requirement)工作流的目標(biāo)是描述系統(tǒng)應(yīng)該做什么，并使開發(fā)人員和用 戶就這一描述達(dá)成共識(shí)。為了達(dá)到該目標(biāo)，要對(duì)需要的功能和約

48、束進(jìn)行提取、組織、 文檔化；最重要的是理解系統(tǒng)所解決問題的定義和范圍。(3)分析和設(shè)計(jì)分析和設(shè)計(jì)(Analysis & Design )工作流將需求轉(zhuǎn)化成未來系統(tǒng)的設(shè)計(jì)，為系統(tǒng)開發(fā)一個(gè)健壯的結(jié)構(gòu)并調(diào)整設(shè)計(jì)使其與實(shí)現(xiàn)環(huán)境相匹配，優(yōu)化其性能。分析設(shè)計(jì) 的結(jié)果是一個(gè)設(shè)計(jì)模型和一個(gè)可選的分析模型。設(shè)計(jì)模型是源代碼的抽象，由設(shè)計(jì) 類和一些描述組成。設(shè)計(jì)類被組織成具有良好接口的設(shè)計(jì)包(Package)和設(shè)計(jì)子系統(tǒng)(Subsystem),而描述則體現(xiàn)了類的對(duì)象如何協(xié)同工作實(shí)現(xiàn)用況的功能。設(shè)計(jì)活 動(dòng)以體系結(jié)構(gòu)設(shè)計(jì)為中心，體系結(jié)構(gòu)由若干結(jié)構(gòu)視圖來表達(dá)，結(jié)構(gòu)視圖是整個(gè)設(shè)計(jì) 的抽象和簡(jiǎn)化，該視圖中省略了一些細(xì)節(jié)，使

49、重要的特點(diǎn)體現(xiàn)得更加清晰。體系結(jié) 構(gòu)不僅僅是良好設(shè)計(jì)模型的承載媒介，而且在系統(tǒng)的開發(fā)中能提高被創(chuàng)建模型的質(zhì) 量。(4)實(shí)現(xiàn)實(shí)現(xiàn)(Implementation )工作流的目的包括以層次化的子系統(tǒng)形式定義代碼的組 織結(jié)構(gòu)；以組件的形式(源文件、二進(jìn)制文件、可執(zhí)行文件)實(shí)現(xiàn)類和對(duì)象；將開 發(fā)出的組件作為單元進(jìn)行測(cè)試以及集成由單個(gè)開發(fā)者(或小組)所產(chǎn)生的結(jié)果，使 其成為可執(zhí)行的系統(tǒng)。(5)測(cè)試測(cè)試(Test)工作流要驗(yàn)證對(duì)象間的交互作用，驗(yàn)證軟件中所有組件的正確集成，檢驗(yàn)所有的需求已被正確的實(shí)現(xiàn)，識(shí)別并確認(rèn)缺陷在軟件部署之前被提出并處理。RUP出了迭代的方法，意味著在整個(gè)項(xiàng)目中進(jìn)行測(cè)試，從而盡可能早地

50、發(fā)現(xiàn)缺陷,從根本上降低了修改缺陷的成本。測(cè)試類似于三維模型，分別從可靠性、功能性和 系統(tǒng)性能來進(jìn)行。(6)部署部署(Deployment)工作流的目的是成功的生成版本并將軟件分發(fā)給最終用戶。 部署工作流描述了那些與確保軟件產(chǎn)品對(duì)最終用戶具有可用性相關(guān)的活動(dòng)，包括： 軟件打包、生成軟件本身以外的產(chǎn)品、安裝軟件、為用戶提供幫助。在有些情況下， 還可能包括計(jì)劃和進(jìn)行 beta測(cè)試版、移植現(xiàn)有的軟件和數(shù)據(jù)以及正式驗(yàn)收。(7)配置和變更管理配置和變更管理工作流描繪了如何在多個(gè)成員組成的項(xiàng)目中控制大量的產(chǎn)物。配置和變更管理工作流提供了準(zhǔn)則來管理演化系統(tǒng)中的多個(gè)變體，跟蹤軟件創(chuàng)建過程 中的版本。工作流描述了

51、如何管理并行開發(fā)、分布式開發(fā)、如何自動(dòng)化創(chuàng)建工程。同時(shí)也闡述了對(duì)產(chǎn)品修改原因、時(shí)間、人員保持審計(jì)記錄。(8)項(xiàng)目管理軟件項(xiàng)目管理(Project Management平衡各種可能產(chǎn)生沖突的目標(biāo)， 管理風(fēng)險(xiǎn)， 克服各種約束并成功交付使用戶滿意的產(chǎn)品。其目標(biāo)包括：為項(xiàng)目的管理提供框架，為計(jì)劃、人員配備、執(zhí)行和監(jiān)控項(xiàng)目提供實(shí)用的準(zhǔn)則，為管理風(fēng)險(xiǎn)提供框架等。(9)環(huán)境環(huán)境(Environment )工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境，包括過程和工具。環(huán)境工作流集中于配置項(xiàng)目過程中所需要的活動(dòng)，同樣也支持開發(fā)項(xiàng)目規(guī)范的活動(dòng)，提供了逐步的指導(dǎo)手冊(cè)并介紹了如何在組織中實(shí)現(xiàn)過程。圖 5-3 RUP

52、核心概念需求獲取RU應(yīng)用用況（Use Case）技術(shù)來獲取需求。列出候選的需求：特征列表理解系統(tǒng)語境：領(lǐng)域模型或業(yè)務(wù)模型捕獲功能需求：用況模型捕獲非功能需求：補(bǔ)充需求或針對(duì)一些特定的用況特征 ：是一個(gè)新的項(xiàng)（ Item ）及其簡(jiǎn)要描述。領(lǐng)域模型 ：類圖業(yè) 務(wù)對(duì)象實(shí) 在對(duì)象事件業(yè)務(wù)對(duì)象模型： 交互圖、活動(dòng)圖1） 工作人員2） 業(yè)務(wù)實(shí)體3） 工作單元?jiǎng)?chuàng)建系統(tǒng)用況模型的活動(dòng)和任務(wù)：1 ）發(fā)現(xiàn)并描述參與者2 ）發(fā)現(xiàn)并描述用況3 ）確定用況的優(yōu)先級(jí)4 ）精化用況5 ）構(gòu)造用戶界面原型6 ）用況模型的結(jié)構(gòu)化需求分析在系統(tǒng)用況模型的基礎(chǔ)上，創(chuàng)建系統(tǒng)分析模型以及在該分析模型視角下的體系結(jié)構(gòu)描述。分析類： 是類

53、的一種衍型，很少有操作和特征標(biāo)記，而用責(zé)任來定義其行為，并且其屬性和關(guān)系也是概念性的。實(shí)體類、邊界類和控制類。存在三種不同類型的類：（ 1）實(shí)體類實(shí)體類描述要保存到持久存儲(chǔ)體中的信息。如：數(shù)據(jù)庫、各種形式的數(shù)據(jù)文件中的信息。包括：活動(dòng)者類。活動(dòng)者類代表出現(xiàn)在用況模型中的活動(dòng)者。活動(dòng)者是現(xiàn)實(shí)世界中與系統(tǒng)交互的人和/ 或機(jī)構(gòu)。例如，訂單處理系統(tǒng)中客戶是一個(gè)活動(dòng)者類。業(yè)務(wù)類描述業(yè)務(wù)的地點(diǎn)、物品、概念和事件。例如訂單處理系統(tǒng)中的訂單、商品等都是業(yè)務(wù)類。（ 2）邊界類也稱界面類（ UI 類） ，是組成系統(tǒng)用戶界面的屏幕顯示、菜單和報(bào)表。例如，訂單處理系統(tǒng)中客戶登錄系統(tǒng)的界面、顯示和編輯訂單的屏幕等都屬于

54、 UI 類。邊界類位于系統(tǒng)與外界的交界處。如：窗體類、報(bào)表類、描述通信協(xié)議的類、直接與外設(shè)交互的類、直接與外部系統(tǒng)交互的類。（ 3）控制類控制類是主要負(fù)責(zé)其它類工作的類。如：主程序類、主窗體類。分析包 :分析包體現(xiàn)了“局部化” 、 “問題分離”等軟件設(shè)計(jì)原理。分析包把一些變化限制到一個(gè)業(yè)務(wù)過程、一個(gè)參與者的行為或一組緊密相關(guān)的用況，形成一些不同的分析包。服務(wù)包和共享包。用況細(xì)化：（ 2）分析模型的表達(dá)（ 3）分析的主要活動(dòng)活動(dòng)1 ：體系結(jié)構(gòu)分析活動(dòng)2 ：用況分析設(shè)計(jì)層定義滿足需求規(guī)約所需要的軟件結(jié)構(gòu)。RUP的設(shè)計(jì)目標(biāo)：定義滿足系統(tǒng)/產(chǎn)品分析模型所規(guī)約需求的軟件結(jié)構(gòu)。個(gè) 術(shù)語：1 ） 設(shè)計(jì)類2

55、） 用況細(xì)化4 ）接口兩個(gè) 角度：1 ）系統(tǒng)設(shè)計(jì)模型2 ）表達(dá)物理分布的系統(tǒng)部署模型設(shè)計(jì)層的 術(shù)語設(shè)計(jì)類：是對(duì)系統(tǒng)實(shí)現(xiàn)中一個(gè)類或類似構(gòu)造的一個(gè)無縫抽象。了解設(shè)計(jì)類的主要特征：操作、屬性、關(guān)系、方法、實(shí)現(xiàn)需求、是否為主動(dòng)類。用況細(xì)化：描述一個(gè)特定用況是如何予以細(xì)化的。設(shè)計(jì)子系統(tǒng)接口設(shè)計(jì)模型、部署模型、體系結(jié)構(gòu)描述設(shè)計(jì)模型設(shè)計(jì)的 主要活動(dòng)活動(dòng) 1 ：體系結(jié)構(gòu)設(shè)計(jì)標(biāo)識(shí)節(jié)點(diǎn)和它們的網(wǎng)絡(luò)配置標(biāo)識(shí)子系統(tǒng)和它們的接口標(biāo)識(shí)在體系結(jié)構(gòu)方面有意義的設(shè)計(jì)類和它們的接口標(biāo)識(shí)一般性的設(shè)計(jì)機(jī)制活動(dòng)2 ：用況的設(shè)計(jì)）標(biāo)識(shí)參與用況細(xì)化的設(shè)計(jì)類）標(biāo)識(shí)參與用況細(xì)化的子系統(tǒng)和接口活動(dòng)3 ：類的設(shè)計(jì)）概括描述設(shè)計(jì)類）標(biāo)識(shí)操作）標(biāo)識(shí)屬

56、性） 描述方法） 描述狀態(tài)活動(dòng) 4 ：子系統(tǒng)設(shè)計(jì)） 維護(hù)子系統(tǒng)依賴） 維護(hù)子系統(tǒng)所提供的接口） 維護(hù)子系統(tǒng)內(nèi)容RUP的實(shí)現(xiàn)RU限現(xiàn)的目標(biāo)：于設(shè)計(jì)類和子系統(tǒng)生成構(gòu)件構(gòu)成進(jìn)行單元測(cè)試行集成和連接可執(zhí)行的構(gòu)件映射到部署模型RU限現(xiàn)的主要活動(dòng)：實(shí)現(xiàn)子系統(tǒng)實(shí)現(xiàn)類完成單元測(cè)試RUP的測(cè)試包括：內(nèi)部測(cè)試、中間測(cè)試和最終測(cè)試。RUPM試包括的主要活動(dòng)：計(jì)劃測(cè)試設(shè)計(jì)測(cè)試實(shí)現(xiàn)測(cè)試執(zhí)行集成測(cè)試執(zhí)行系統(tǒng)測(cè)試評(píng)價(jià)測(cè)試第六章 軟件測(cè)試復(fù)習(xí)建議錯(cuò)誤是不可避免的，我們要做的就是發(fā)現(xiàn)它，并改正它。軟件測(cè)試是保證軟件過程質(zhì)量和軟件產(chǎn)品質(zhì)量的基礎(chǔ)。因此軟件測(cè)試也是本課程的重點(diǎn)內(nèi)容，題目類型涉及單項(xiàng)選擇題、填空題、簡(jiǎn)答題、綜合應(yīng)用題

57、全部題型，分值在25%左右。本章既有基本概念，也有綜合應(yīng)用，要求考生多做練習(xí)。第一節(jié) 軟件測(cè)試目標(biāo)與軟件測(cè)試過程模型軟件測(cè)試的 對(duì)象軟件=程序+文檔測(cè)試對(duì)象：各個(gè)階段產(chǎn)生的源程序和文檔。軟件測(cè)試的 目的基于不同的立場(chǎng)，對(duì)軟件測(cè)試的目的存在著兩種完全對(duì)立的觀點(diǎn)。一種觀點(diǎn)是通過測(cè)試暴露出軟件中所包含的故障和缺陷（ 從用戶的角度）；另一種是希望測(cè)試成為表明軟件產(chǎn)品中不存在錯(cuò)誤的過程，驗(yàn)證該軟件中已正確地實(shí)現(xiàn)了用戶的要求，因此，它們傾向于選取導(dǎo)致程序失敗概率最小的測(cè)試實(shí)例和數(shù)據(jù)。顯然，第二種觀點(diǎn)對(duì)完善和提高軟件質(zhì)量和可靠性毫無價(jià)值，因此測(cè)試的目的應(yīng)該是通過軟件測(cè)試盡可能多地發(fā)現(xiàn)并改正軟件種存在的錯(cuò)誤。

58、軟件測(cè)試的 定義Glenford J. Myers 把這一觀點(diǎn)歸納為：測(cè)試是程序執(zhí)行的過程，其目的在于發(fā)現(xiàn)錯(cuò)誤。一個(gè)好的測(cè)試實(shí)例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤。一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。因此 , 軟件測(cè)試 （Software Testing） 是從引起和發(fā)現(xiàn)錯(cuò)誤的目的出發(fā)執(zhí)行某一程序的過程。錯(cuò)誤的類型功能錯(cuò)誤：處理功能說明不完整或不確切，致使編程時(shí)對(duì)功能有誤解而產(chǎn)生的錯(cuò)誤。系統(tǒng)錯(cuò)誤：與外部接口錯(cuò)誤、子程序調(diào)用錯(cuò)誤、參數(shù)使用錯(cuò)誤等。過程錯(cuò)誤：算術(shù)運(yùn)算錯(cuò)誤和邏輯運(yùn)算錯(cuò)誤數(shù)據(jù)錯(cuò)誤：數(shù)據(jù)結(jié)構(gòu)、實(shí)體、屬性錯(cuò)誤。編程錯(cuò)誤：語法錯(cuò)誤、程序邏輯錯(cuò)誤、編程書寫錯(cuò)誤等。軟件測(cè)試 過程模型1）測(cè)試設(shè)計(jì)

59、2）測(cè)試執(zhí)行3）測(cè)試結(jié)果比較第二節(jié) 軟件測(cè)試技術(shù)測(cè)試法分為黑盒法和白盒法。黑盒（ Black-box Testing ）法：黑盒法又稱為 功能測(cè)試 法，它是根據(jù)程序功能的分析，推演出由函數(shù)定義域中有代表性的元素組成測(cè)試集，這些數(shù)據(jù)應(yīng)包括對(duì)程序是有效的和無效的輸入，極端的、正常的和特殊的數(shù)據(jù)元素。因此，黑盒測(cè)試法是從外界來檢查模塊或程序的功能，也即根據(jù)模塊的輸入和輸出，得出所得結(jié)果得差異。這種測(cè)試無須知道模塊的內(nèi)部邏輯，而是給定一輸入，檢查是否會(huì)得到所期望的輸出。功能測(cè)試法又具體分為等價(jià)類法，邊值分析法，因果圖法和錯(cuò)誤猜測(cè)法等。白盒法（ White-box Testing ） ：白盒法也稱之為

60、結(jié)構(gòu)測(cè)試 或邏輯覆蓋法。它是根據(jù)對(duì)軟件內(nèi)部邏輯結(jié)構(gòu)的分析， 選取測(cè)試數(shù)據(jù)集 （即測(cè)試用例： Testing Case） ，而測(cè)試數(shù)據(jù)集對(duì)程序邏輯的覆蓋程度決定了測(cè)試完全性的程度。常用的幾個(gè)覆蓋標(biāo)準(zhǔn)有：語句覆蓋、判定覆蓋、條件覆蓋、判定 / 條件覆蓋、條件組合覆蓋。【例題？填空題】黑盒法又稱為 法，黑盒測(cè)試法是從外界來檢查模塊或程序的功能，也即根據(jù)模塊的輸入和輸出，得出所得結(jié)果得差異?！敬鸢浮抗δ軠y(cè)試路徑測(cè)試技術(shù) （白盒測(cè)試） 依據(jù)的是程序的邏輯結(jié)構(gòu)?？刂屏鞒虉D基本元素：過程塊、節(jié)點(diǎn)、判定。鏈、路徑的概念。注意 ：控制流程圖和程序流程圖的差別。測(cè)試策略路徑覆蓋：執(zhí)行所有可能穿過程序控制流程的路徑