新軟件建模技術(shù)

新軟件建模技術(shù)第一頁，共七十五頁，編輯于2023年，星期三1.1UML和對象思想U(xiǎn)ML是標(biāo)準(zhǔn)的圖形化表示法，并不是OOA/D，沒有掌握如何創(chuàng)建優(yōu)秀的面向?qū)ο笤O(shè)計(jì)，或者如何評估和改進(jìn)現(xiàn)有設(shè)計(jì)，那么學(xué)習(xí)UML或者UMLCASE工具是毫無意義的。對象思想才是重點(diǎn)和難點(diǎn)。第二頁，共七十五頁，編輯于2023年，星期三1.2OOD的原則和模式系統(tǒng)設(shè)計(jì)中的關(guān)鍵問題：應(yīng)該如何為對象分配職責(zé)（Responsibility）？對象之間應(yīng)該如何協(xié)作？什么樣的類應(yīng)該做什么樣的事？模式：某些針對設(shè)計(jì)問題的，經(jīng)過反復(fù)驗(yàn)證的解決方案可以（和已經(jīng)）被表示為最佳時(shí)間的原則、起始或模式（pattern），即問題-解決方案公式，這些公式是系統(tǒng)化的、典范的設(shè)計(jì)原則。第三頁，共七十五頁，編輯于2023年，星期三1.3用例OOD（以及所有軟件設(shè)計(jì)）與作為其先決活動的需求分析（requirementsanalysis）具有緊密聯(lián)系，而在需求分析中通常包含用例的編寫。第四頁，共七十五頁，編輯于2023年，星期三1.4什么是分析和設(shè)計(jì)分析（analysis）強(qiáng)調(diào)的是對問題和需求的調(diào)查和研究，而不是解決方案。需求分析：對需求的調(diào)查研究。面向?qū)ο蠓治觯簩︻I(lǐng)域?qū)ο蟮恼{(diào)查研究。設(shè)計(jì)（design）：強(qiáng)調(diào)的是滿足需求的概念（邏輯）上的解決方案（在軟件和硬件方面），而不是實(shí)現(xiàn)。例如，對數(shù)據(jù)庫方案和軟件對象的描述。設(shè)計(jì)細(xì)想通常排斥底層或“顯而易見”的細(xì)節(jié)。最終，設(shè)計(jì)可以實(shí)現(xiàn)，而實(shí)現(xiàn)（入如代碼）則表達(dá)了真實(shí)而完整的設(shè)計(jì)。第五頁，共七十五頁，編輯于2023年，星期三1.5什么是面向?qū)ο蠓治龊驮O(shè)計(jì)在面向?qū)ο蠓治鲞^程中，強(qiáng)調(diào)的是在問題領(lǐng)域內(nèi)發(fā)現(xiàn)和描述對象（或概念）。例如，在航班信息系統(tǒng)中包含飛機(jī)、航班、和飛行員在面向?qū)ο笤O(shè)計(jì)過程中，強(qiáng)調(diào)的是定義軟件對象以及如何寫作以實(shí)現(xiàn)需求。例如，軟件對象Plane可以有tailNumber屬性和getFlightHistory方法。最后，在實(shí)現(xiàn)或面向?qū)ο蟪绦蛟O(shè)計(jì)過程中，會實(shí)現(xiàn)設(shè)計(jì)出來的對象，入Java中的Plane類。第六頁，共七十五頁，編輯于2023年，星期三第七頁，共七十五頁，編輯于2023年，星期三1.5面向?qū)ο蟮姆治雠c設(shè)計(jì)例子一個(gè)簡單的例子—“擲骰子游戲”（dicegame），在這個(gè)游戲中游戲者擲出兩個(gè)骰子。如果總點(diǎn)數(shù)為7就贏了，否則就輸了。第八頁，共七十五頁，編輯于2023年，星期三1.5.1定義用例需求分析可能包括人們?nèi)绾问褂脩?yīng)用的情節(jié)或場景，這些情節(jié)或場景可以被編寫為用例（UseCase）。用例不是面向?qū)ο笾破?，而只是對情?jié)的記錄。但用例是需求分析中的一種常用工具。骰子游戲：第九頁，共七十五頁，編輯于2023年，星期三1.5.2定義領(lǐng)域模型面向?qū)ο蠓治鲫P(guān)注從對象的角度創(chuàng)建領(lǐng)域描述，需要鑒別重要的概念、屬性和關(guān)聯(lián)。結(jié)果可以表示為領(lǐng)域模型（domainmodel）（展示重要的領(lǐng)域概念或?qū)ο螅?。領(lǐng)域模型不是對軟件對象的描述，而是真是世界領(lǐng)域中的概念和想象的可視化。因此也被稱為概念對象模型（conceptualobjectmodel）。第十頁，共七十五頁，編輯于2023年，星期三第十一頁，共七十五頁，編輯于2023年，星期三1.5.3分配對象職責(zé)并繪制交互圖第十二頁，共七十五頁，編輯于2023年，星期三第十三頁，共七十五頁，編輯于2023年，星期三1.5.4定義設(shè)計(jì)類圖第十四頁，共七十五頁，編輯于2023年，星期三2.迭代、進(jìn)化和敏捷迭代開發(fā)是OOA/D成為最佳實(shí)踐的核心。敏捷實(shí)踐是有效應(yīng)用UML的關(guān)鍵。UP是相對流行的、示范性的迭代方法。相對于順序或“瀑布”（waterfall）生命周期，迭代和進(jìn)化式開發(fā)對部分系統(tǒng)及早地引入了編程和測試，并重復(fù)這一循環(huán)。這種方式通常會在還沒有詳細(xì)定義所有需求的情況下開始開發(fā)，同時(shí)使用反饋來明確和改進(jìn)演化中的規(guī)格說明。依賴于短時(shí)快速的開發(fā)步驟、反饋和改寫來不斷明確需求和設(shè)計(jì)。第十五頁，共七十五頁，編輯于2023年，星期三2.1UP軟件開發(fā)過程：描述了構(gòu)造、部署以及維護(hù)軟件的方式。統(tǒng)一過程已經(jīng)成為一中流行的構(gòu)造面向?qū)ο笙到y(tǒng)的迭代軟件開發(fā)過程。UP把普遍認(rèn)可的最佳實(shí)踐結(jié)合起來，成為聯(lián)系緊密并具有良好文檔的過程描述。第十六頁，共七十五頁，編輯于2023年，星期三2.2迭代和進(jìn)化式開發(fā)迭代開發(fā)（iterativedevelopment）是UP和大多數(shù)其他現(xiàn)代方法中的關(guān)鍵實(shí)踐。在這種生命周期法中，開發(fā)被組織成一系列國定的短期小項(xiàng)目，稱為迭代（iteration）；每次迭代都產(chǎn)生經(jīng)過測試、集成并可執(zhí)行的局部系統(tǒng)。每次迭代都具有各自的需求分析、設(shè)計(jì)、實(shí)現(xiàn)和測試活動。迭代生命周期基于對經(jīng)過多次迭代的系統(tǒng)進(jìn)行持續(xù)擴(kuò)展和精化，并以循環(huán)反饋和調(diào)整為核心驅(qū)動力，使之最終成為適當(dāng)?shù)南到y(tǒng)。隨著時(shí)間和一次又一次迭代的遞進(jìn)，系統(tǒng)增量式地發(fā)展完善，因此這一方法也被稱為迭代增量式開發(fā)。因?yàn)榉答伜驼{(diào)整使規(guī)格說明和設(shè)計(jì)不斷進(jìn)化，所以這種方法也被稱為迭代和進(jìn)化式開發(fā)。第十七頁，共七十五頁，編輯于2023年，星期三2.3為什么要使用迭代開發(fā)減少項(xiàng)目失敗的可能性，提高生產(chǎn)率，降低缺陷率。在早期緩解高風(fēng)險(xiǎn)早期可見的進(jìn)展早期反饋、用戶參與和調(diào)整，會產(chǎn)生更接近涉眾真是需求的精化系統(tǒng)?？煽貜?fù)雜性：團(tuán)隊(duì)不會被“分析癱瘓”或長期且復(fù)雜的步驟所淹沒。一次迭代中的經(jīng)驗(yàn)可以被系統(tǒng)地用于改進(jìn)開發(fā)過程本身，并如此反復(fù)進(jìn)行下去。第十八頁，共七十五頁，編輯于2023年，星期三2.4一次迭代持續(xù)的時(shí)間在每個(gè)開發(fā)周期中有一個(gè)實(shí)用的策略，那就是為這個(gè)開發(fā)周期加上一個(gè)“時(shí)間盒”—即一段固定的時(shí)間。在這個(gè)開發(fā)周期中所有的工作都應(yīng)在這個(gè)時(shí)間內(nèi)完成。一般來說，兩周到兩個(gè)月是比較合適的時(shí)間盒值，如果時(shí)間再短一點(diǎn)，將很難完成任務(wù)；如果時(shí)間再長一些，一個(gè)開發(fā)周期中遇到的各種問題的復(fù)雜性將難以處理，并且得到反饋信息的時(shí)間將拖后。要成功實(shí)施“時(shí)間盒”調(diào)度，必須仔細(xì)選擇所要處理的需求，并確保開發(fā)小組對所做出的選擇負(fù)責(zé)。第十九頁，共七十五頁，編輯于2023年，星期三2.5瀑布生命周期在瀑布（或順序）生命周期中，試圖在編程之前（詳細(xì)）定義所有或大部分需求。而通常于編程之前創(chuàng)建出完整的設(shè)計(jì)（或模型集）。同樣，試圖在開始前定義“可控的”計(jì)劃或時(shí)間表。但常常是“事與愿違”第二十頁，共七十五頁，編輯于2023年，星期三2.6如何進(jìn)行迭代和進(jìn)化式分析和設(shè)計(jì)

在第1次迭代之前，召開第一個(gè)時(shí)間定量需求工作會議。在第1次迭代之前，召開迭代計(jì)劃會議，（選擇用例（或子集），在特定的時(shí)間內(nèi)完成）。在3-4周內(nèi)完成第1次迭代。在第1次迭代即將結(jié)束是，召開第2次需求工作會議，對上一次會議的所有材料進(jìn)行復(fù)雜和精化。于周五上午，舉行下一迭代計(jì)劃會議。以相同步驟進(jìn)行第2次迭代。反復(fù)進(jìn)行4次迭代和5次需求工作會，這樣在第4次迭代結(jié)束時(shí)，可能已經(jīng)詳細(xì)記錄了約80-90%的需求，但只實(shí)現(xiàn)了系統(tǒng)的10%。帶該推進(jìn)了整個(gè)項(xiàng)目的20%。在UP術(shù)語中，這是細(xì)化階段（elaborationphase）的結(jié)束。此后，一般不需要再召開需求工作會議；需求已經(jīng)穩(wěn)定了，接下來是一系列為期3周的迭代，在最有一個(gè)周五召開的迭代計(jì)劃會議上選擇適宜的下一步工作，每次迭代都要反復(fù)詢問：“就我么現(xiàn)在所知，下一個(gè)3周應(yīng)該完成的、最關(guān)鍵的技術(shù)和業(yè)務(wù)特性是什么”第二十一頁，共七十五頁，編輯于2023年，星期三2.7UP的其他關(guān)鍵實(shí)踐在早期的迭代中解決高風(fēng)險(xiǎn)和高價(jià)值的問題不斷讓用戶參與評估、反饋和需求在早期迭代中建立內(nèi)聚的核心架構(gòu)不斷驗(yàn)證質(zhì)量：提早、經(jīng)常和實(shí)際的測試進(jìn)行一些可視化建模認(rèn)真管理需求實(shí)行變更請求和配置管理第二十二頁，共七十五頁，編輯于2023年，星期三2.8UP階段初始（Inception）：大體上的構(gòu)想、業(yè)務(wù)案例、范圍和模糊評估。細(xì)化（Elaboration）：已精化的構(gòu)想、核心架構(gòu)的迭代實(shí)現(xiàn)、高風(fēng)險(xiǎn)的解決、確定大多數(shù)的需求以及進(jìn)行更為實(shí)際的評估。構(gòu)造（Construction）：對遺留下來的風(fēng)險(xiǎn)較低和比較簡單的元素進(jìn)行迭代實(shí)現(xiàn)，準(zhǔn)備部署。移交（Transition）：進(jìn)行beta測試和部署。第二十三頁，共七十五頁，編輯于2023年，星期三第二部分第二十四頁，共七十五頁，編輯于2023年，星期三1.初始階段初始階段是建立項(xiàng)目共同設(shè)想和基本范圍的比較簡短的起始步驟。為了在隨后的細(xì)化階段哪能夠開始編程，它將包括對10%的用例進(jìn)行分析、關(guān)鍵的非功能需求的分析、業(yè)務(wù)案例創(chuàng)建和開發(fā)環(huán)境的準(zhǔn)備。在該階段考慮以下幾類問題：項(xiàng)目的設(shè)想和業(yè)務(wù)案例是什么？是否可行？購買還是開發(fā)？初略估算一下成本項(xiàng)目應(yīng)該繼續(xù)下去還是停止？第二十五頁，共七十五頁，編輯于2023年，星期三2.進(jìn)化式需求第二十六頁，共七十五頁，編輯于2023年，星期三2.1定義需求需求（requirement）就是系統(tǒng)（更廣義的說法是項(xiàng)目）必須提供的能力和必須遵從的條件。在變更不可避免，涉眾意愿不明朗的情況下，UP更推崇“一種系統(tǒng)的方法來尋找、記錄、組織和跟蹤系統(tǒng)不斷變更的需求”。通過迭代巧妙地進(jìn)行需求分析，而非草率和隨意為之。需求分析最大的挑戰(zhàn)是尋找、溝通和記住什么是真正的需求，并能夠清楚地講解給客戶和開發(fā)團(tuán)隊(duì)。第二十七頁，共七十五頁，編輯于2023年，星期三2.2進(jìn)化式需求與瀑布式需求第二十八頁，共七十五頁，編輯于2023年，星期三2.3尋找需求可以采用的方法與客戶一同編寫用例開發(fā)者與客戶共同參加需求討論會請客戶代理參加焦點(diǎn)小組向客戶演示每次迭代的成果以及求得反饋。第二十九頁，共七十五頁，編輯于2023年，星期三2.4需求的類型和種類需求按照“FURPS+”模型進(jìn)行分類：功能性（Functional）：特性、功能、安全性可用性（Usability）：人性化因素、幫助、文檔性能（Performance）：響應(yīng)時(shí)間、吞吐量、準(zhǔn)確性、有效性、資源利用率?？芍С中裕⊿upportability）：適應(yīng)性、可維護(hù)性、國際化、可配置性。第三十頁，共七十五頁，編輯于2023年，星期三2.4需求的類型和種類(續(xù))“+”是指一些輔助性的和次要的因素：實(shí)現(xiàn)（Implementation）：資源限制、語言和工具、硬件等。接口（Interface）：強(qiáng)加于外部系統(tǒng)接口之上的約束。操作（Operation）：對其操作設(shè)置的系統(tǒng)管理。包裝（Packaging）：授權(quán)（Legal）：許可證或其他方式。在進(jìn)行架構(gòu)分析的時(shí)候，質(zhì)量屬性對系統(tǒng)架構(gòu)具有極大影響。功能性需求和非功能性需求第三十一頁，共七十五頁，編輯于2023年，星期三2.5UP制品如何組織需求用例模型：一組使用系統(tǒng)的典型場景。主要用于功能（行為）需求補(bǔ)充性規(guī)格說明：用例之外的所有內(nèi)容。詞匯表：重要的術(shù)語。設(shè)想：概括了高階需求，這些需求在用例模型和補(bǔ)充性規(guī)格說明中進(jìn)行細(xì)化。也概括了項(xiàng)目的業(yè)務(wù)案例。幫助快速了解項(xiàng)目的主要思想。業(yè)務(wù)規(guī)則：描述凌駕于某一軟件項(xiàng)目的需求或政策。第三十二頁，共七十五頁，編輯于2023年，星期三3用例用例是文本形式的情節(jié)描述，用以說明某參與者使用系統(tǒng)以實(shí)現(xiàn)某些目標(biāo)。廣泛應(yīng)用于需求的發(fā)現(xiàn)和記錄中。不是圖形，而是文本。通過編寫使用系統(tǒng)實(shí)現(xiàn)用戶目標(biāo)的情節(jié)來發(fā)現(xiàn)和記錄功能性需求，也就是使用的案例。第三十三頁，共七十五頁，編輯于2023年，星期三3.1定義：參與者、場景和用例參與者（actor）是某些具有行為的事物，可以是人（由角色標(biāo)識）、計(jì)算機(jī)系統(tǒng)或組織。場景（scenario）是參與者和系統(tǒng)之間的一系列特定的活動和交互，也稱用例實(shí)例（Usecaseinstance）。是使用系統(tǒng)的一個(gè)特定情節(jié)或用例的一條執(zhí)行路徑。用例（Usecase）就是一組相關(guān)的成功和失敗場景的集合，用來描述參與者如何使用系統(tǒng)來實(shí)現(xiàn)其目標(biāo)。第三十四頁，共七十五頁，編輯于2023年，星期三3.2用例和用例模型用例模型是所有書面用例的集合，是系統(tǒng)功能性和環(huán)境的模型。用例是文本文檔，而非圖形；用例建模主要是編寫文本的活動，而非制圖。用例模型可以包含UML的用例圖，以顯示用例和參與者的名稱及其關(guān)系。UML用例圖可以為系統(tǒng)及其環(huán)境提供良好的語境圖（contextdiagram：顯示了領(lǐng)域內(nèi)的廣義應(yīng)用（或者是目標(biāo)系統(tǒng)）和與之通信的其他實(shí)體或抽象物之間的數(shù)據(jù)流。），也為按名稱列出用例提供了快捷方式。不是面向?qū)ο笏赜械?。第三十五頁，共七十五頁，編輯?023年，星期三3.3為什么使用用例缺少用戶參與用戶參與是項(xiàng)目失敗的主要原因之一，所以任何有利于用戶參與的方法是絕度值得的。用例是一中優(yōu)秀的方法，使領(lǐng)域?qū)＜一蛐枨筇峁┱咦约壕帉懀ɑ騾⑴c編寫）用例稱為可能，并使這項(xiàng)工作難度降低。用例的另一個(gè)價(jià)值是強(qiáng)調(diào)了用戶的目標(biāo)和觀點(diǎn)。“誰使用系統(tǒng)，他們使用的典型場景是什么？他們的目的是什么？”（以客戶為中心）。用例被推薦作為發(fā)現(xiàn)和定義需求的核心機(jī)制。第三十六頁，共七十五頁，編輯于2023年，星期三3.4參與者的三種類型主要參與者（primaryactor）：具有用戶目標(biāo)，并通過使用系統(tǒng)的服務(wù)實(shí)現(xiàn)。（發(fā)現(xiàn)驅(qū)動用例的用戶目標(biāo)）協(xié)助參與者（supportingactor）：為系統(tǒng)提供服務(wù)。（為了明確外部接口和協(xié)議）幕后參與者（offstageactor）：在用例行為中具有影響或利益。（）為了確保滿足所有的重要事物第三十七頁，共七十五頁，編輯于2023年，星期三3.5表示法：用例的三種常用形式摘要：簡潔的一段式概要，常用于主成功場景。使用時(shí)機(jī)：在早期需求分析中，為快速了解主題和范圍。非正式：非正式的段落式。用幾個(gè)段落覆蓋不同場景。使用時(shí)機(jī)：在早期需求分析中，為快速稍微詳細(xì)了解主題和范圍。詳述：詳細(xì)描述所有步驟及各種變化，同時(shí)具有補(bǔ)充部分，如前置條件和成功保證。使用時(shí)機(jī)：確定并以摘要形式編寫了大量用例后，在第一次需求討論會中，詳細(xì)編寫其中少量具有重要架構(gòu)意義和高價(jià)值的用例。（教材P49-55）第三十八頁，共七十五頁，編輯于2023年，星期三3.6發(fā)現(xiàn)用例1）選擇系統(tǒng)邊界。2）確定主要參與者；3）確定每個(gè)主要參與者的目標(biāo)；4）定義滿足用戶目標(biāo)的用例，根據(jù)其目標(biāo)對用例命名。通常，用戶目標(biāo)級的用例和用戶目標(biāo)是一一對應(yīng)的。第三十九頁，共七十五頁，編輯于2023年，星期三3.7測試有用的用例老板測試：EBP（基本業(yè)務(wù)過程）測試：一個(gè)人于某個(gè)時(shí)刻在一個(gè)地點(diǎn)所執(zhí)行的任務(wù)，用以響應(yīng)業(yè)務(wù)事件。該任務(wù)能增加可量化的業(yè)務(wù)價(jià)值，并以持久狀態(tài)留下數(shù)據(jù)。用例不是單獨(dú)的一小步；如：刪除一條記錄用例主成功場景應(yīng)該是5-10步驟；用例不能持續(xù)數(shù)日或多個(gè)會話過程；第四十頁，共七十五頁，編輯于2023年，星期三3.8活動圖活動圖：UML包含一種有助于使工作流和業(yè)務(wù)過程可視化的圖用例涵蓋過程和工作流分析，所以活動圖能夠稱為編寫用例文本的有用的輔助措施。第四十一頁，共七十五頁，編輯于2023年，星期三第四十二頁，共七十五頁，編輯于2023年，星期三3.9在迭代過程中如何使用用例用例驅(qū)動開發(fā):功能需求首先記錄在用例；用例是迭代計(jì)劃的重要部分。迭代工作是通過選擇一些用例場景或整個(gè)用例來定義的。用例實(shí)現(xiàn)驅(qū)動設(shè)計(jì)：設(shè)計(jì)協(xié)作對象和子系統(tǒng)是為了執(zhí)行或?qū)崿F(xiàn)用例；用例通常會影響用戶手冊的組織；為重要用例的最常用場景創(chuàng)建UI“向?qū)А被蚩旖莘绞娇梢苑奖銏?zhí)行常用任務(wù)。第四十三頁，共七十五頁，編輯于2023年，星期三4迭代1—領(lǐng)域模型領(lǐng)域模型是OO分析中最重要的和經(jīng)典的模型。確定一組概念類是OO分析的核心。闡述了領(lǐng)域中的重要概念；可以作為設(shè)計(jì)某些軟件對象的靈感來源；領(lǐng)域模型的范圍限定于當(dāng)前迭代所開發(fā)的用例場景；能夠不斷演進(jìn)用以展示相關(guān)的重要概念。第四十四頁，共七十五頁，編輯于2023年，星期三4.1什么是領(lǐng)域模型對領(lǐng)域內(nèi)的概念類或現(xiàn)實(shí)世界中的對象可視化表示。也稱概念模型、領(lǐng)域?qū)ο竽Ｐ秃头治鰧ο竽Ｐ?。UML表示法，領(lǐng)域模型被描述為一組沒有定義操作（方法的特征標(biāo)記）的類圖，它可以展示：領(lǐng)域?qū)ο蠡蚋拍铑惛拍铑愔g的關(guān)聯(lián)概念類的屬性。第四十五頁，共七十五頁，編輯于2023年，星期三4.1什么是領(lǐng)域模型（續(xù)）領(lǐng)域模型是可是化字典，表示領(lǐng)域的重要概念、領(lǐng)域詞匯和領(lǐng)域的內(nèi)容信息。領(lǐng)域模型不是軟件對象。領(lǐng)域模型不是數(shù)據(jù)模型：不會排除需求中沒有明確要求記錄其相關(guān)信息的類；不會排除沒有屬性的類；（充當(dāng)純行為角色的概念類）第四十六頁，共七十五頁，編輯于2023年，星期三4.2概念類概念類（conceptualclass）是思想、事物或?qū)ο?，可以從符號、?nèi)涵和外延來考慮。符號：表示概念類的詞語或圖形；內(nèi)涵：概念類的定義；外延：概念類所適用的一組示例；第四十七頁，共七十五頁，編輯于2023年，星期三4.3為什么要創(chuàng)建領(lǐng)域模型降低與OO建模之間的表示差異：領(lǐng)域?qū)榆浖惖拿Q要源于領(lǐng)域模型中的名稱，以使對象具有源于領(lǐng)域的信息和職責(zé)。第四十八頁，共七十五頁，編輯于2023年，星期三4.4如何創(chuàng)建領(lǐng)域模型以當(dāng)前迭代中所要設(shè)計(jì)的需求為界：尋找概念類將其繪制為UML類圖中的類；添加關(guān)聯(lián)和屬性。第四十九頁，共七十五頁，編輯于2023年，星期三4.5如何找到概念類重用或修改現(xiàn)有模型；使用分類列表；（P104-105）確定名詞短語。（P105-106）第五十頁，共七十五頁，編輯于2023年，星期三4.6準(zhǔn)則：報(bào)表對象—模型中是否要包括“票據(jù)”票據(jù)是POS領(lǐng)域的重要術(shù)語，但也許它只是銷售和支付數(shù)據(jù)的報(bào)表，因此是一種信息的重復(fù)。是否應(yīng)該將票據(jù)包含在（當(dāng)前迭代周期）領(lǐng)域模型中？第五十一頁，共七十五頁，編輯于2023年，星期三4.7使用領(lǐng)域術(shù)語第五十二頁，共七十五頁，編輯于2023年，星期三4.8屬性與類在創(chuàng)建領(lǐng)域模型常犯的錯(cuò)誤：把應(yīng)該是概念類的事物表示為屬性。準(zhǔn)則：任務(wù)某概念類X不是現(xiàn)實(shí)世界中的數(shù)字或文本，那么X可能是概念類而不是屬性。比如：Store（商店是否作為Sale的一個(gè)屬性）？Destination（目的機(jī)場）是否應(yīng)作為Flight（航班）的一個(gè)屬性？第五十三頁，共七十五頁，編輯于2023年，星期三4.9“描述”概念類描述類：包含描述其他事物的信息。為什么要使用描述類？在以下情況下需要增加描述類：需要有關(guān)商品或服務(wù)的描述獨(dú)立于任何商品或服務(wù)的實(shí)例。刪除其所描述事物的實(shí)例后，導(dǎo)致信息丟失，而這些信息是需要維護(hù)的，但是被錯(cuò)誤地與所刪除的事物關(guān)聯(lián)起來。減少冗余或重復(fù)信息。第五十四頁，共七十五頁，編輯于2023年，星期三4.10銷售點(diǎn)終端問題域中的后選概念POSTITEMStoreSalePaymentProductCatalogProductSpecificationSalesLineItemCashierCustomerManager第五十五頁，共七十五頁，編輯于2023年，星期三4.10關(guān)聯(lián)關(guān)聯(lián)（association）是類（類的實(shí)例）之間的聯(lián)系，表示有意義和值得關(guān)注的連接。關(guān)聯(lián)能夠滿足當(dāng)前所開發(fā)場景的信息需求，并且有助于理解領(lǐng)域。UML中，關(guān)聯(lián)被定義為“兩個(gè)或多個(gè)類元之間的語義聯(lián)系，涉及這些類元實(shí)例之間的連接”。第五十六頁，共七十五頁，編輯于2023年，星期三4.11何時(shí)需要關(guān)聯(lián)由于領(lǐng)域模型是從概念角度出發(fā)的，所以是否需要記錄關(guān)聯(lián)，要基于現(xiàn)實(shí)世界的需要，而不是基于軟件的需要（盡管在實(shí)現(xiàn)過程中，會有出現(xiàn)大量對關(guān)聯(lián)的需要）。準(zhǔn)則：在領(lǐng)域模型中要考慮如下關(guān)聯(lián)：如存在需要保持一段時(shí)間的關(guān)系，將這種語義表示為關(guān)聯(lián)（“需要記住”的關(guān)聯(lián)）；從常見關(guān)聯(lián)類表中派生出的關(guān)聯(lián)。準(zhǔn)則：應(yīng)該避免加入大量關(guān)聯(lián)。關(guān)聯(lián)不是關(guān)于數(shù)據(jù)流、數(shù)據(jù)庫外鍵聯(lián)系、實(shí)例變量或軟件中的對象連接語句；關(guān)聯(lián)聲明的是針對現(xiàn)實(shí)領(lǐng)域從純概念的角度看有意義的關(guān)系。這些關(guān)系大部分將作為（設(shè)計(jì)模型和數(shù)據(jù)模型中的）導(dǎo)航和可見性路徑在軟件中加以實(shí)現(xiàn)。領(lǐng)域模型不是數(shù)據(jù)模型；添加關(guān)聯(lián)是為了突出對重要關(guān)系的理解，而非記錄對象或數(shù)據(jù)結(jié)構(gòu)。第五十七頁，共七十五頁，編輯于2023年，星期三4.12關(guān)聯(lián)表示法關(guān)聯(lián)被表示為類之間的連線。多重性：表示在特定時(shí)刻（而不是在一段時(shí)間之內(nèi)）有效關(guān)系的實(shí)例數(shù)量。關(guān)聯(lián)的末端可以包含多重性表達(dá)式：指明類實(shí)例之間的數(shù)量關(guān)系。命名：“類名-動詞短語-類名”角色：關(guān)聯(lián)的每一端稱為角色第五十八頁，共七十五頁，編輯于2023年，星期三第五十九頁，共七十五頁，編輯于2023年，星期三4.13屬性屬性是對象的邏輯數(shù)據(jù)值。確定概念類的屬性能夠滿足當(dāng)前所開發(fā)場景的信息需求。當(dāng)需求建議或暗示需要記住信息時(shí)，引入屬性。第六十頁，共七十五頁，編輯于2023年，星期三4.14屬性類型領(lǐng)域模型中的屬性通常應(yīng)該是簡單數(shù)據(jù)類型。簡單數(shù)據(jù)類型指的是一組值，而這組值的標(biāo)識本身不具有任何意義。第六十一頁，共七十五頁，編輯于2023年，星期三4.15何時(shí)定義新的數(shù)據(jù)類型在領(lǐng)域模型里，把最初被認(rèn)為是數(shù)字或字符串的數(shù)據(jù)類型表示為新的數(shù)據(jù)類型：由不同的小節(jié)組成；具有與之相關(guān)的操作；具有其他屬性；單位數(shù)量；具有以上性質(zhì)的一個(gè)或多個(gè)類型的抽象。第六十二頁，共七十五頁，編輯于2023年，星期三4.16任何屬性都不表示為外部鍵領(lǐng)域模型里的屬性不應(yīng)該用于表示概念類的關(guān)系。應(yīng)使用關(guān)聯(lián)而不是屬性來表示類型關(guān)聯(lián)。第六十三頁，共七十五頁，編輯于2023年，星期三4.17對數(shù)量和單位建模大部分用數(shù)字表示的數(shù)量不應(yīng)該表示為純數(shù)字。一般做法：把數(shù)量表示為一個(gè)單獨(dú)的Quantity（數(shù)量類），并且將該類關(guān)聯(lián)到Unit（單位類）。第六十四頁，共七十五頁，編輯于2023年，星期三5系統(tǒng)順序圖系統(tǒng)順序圖是系統(tǒng)調(diào)查過程的一部分，這個(gè)調(diào)查過程主要是查明要建立的系統(tǒng)是一個(gè)什么樣的系統(tǒng)，因此，系統(tǒng)順序圖是分析模型的一部分。展示了參與者向系統(tǒng)發(fā)起的事件。

系統(tǒng)順序圖（systemsequencediagram）展示了在一個(gè)特殊的用例場景（用例執(zhí)行過程的一個(gè)特定實(shí)例或?qū)崿F(xiàn)路徑—用例生效的一個(gè)真實(shí)例子）中系統(tǒng)外部參與者發(fā)起的事件、事件的順序以及各個(gè)系統(tǒng)之間的交互時(shí)間等。在順序圖中，所有的系統(tǒng)都被當(dāng)作黑盒子看待，順序圖的重點(diǎn)是參與者發(fā)起的跨越系統(tǒng)邊界的事件第六十五頁，共七十五頁，編輯于2023年，星期三第六十六頁，共七十五頁，編輯于2023年，星期三5.1系統(tǒng)行為在進(jìn)行邏輯設(shè)計(jì)之前軟件應(yīng)用系統(tǒng)將如何工作，必須對系統(tǒng)行為進(jìn)行調(diào)查，并且要將系統(tǒng)行為定義為一個(gè)“黑盒子”。系統(tǒng)行為（systembehavior）描述了系統(tǒng)做什么，而不解釋系統(tǒng)怎么做。系統(tǒng)順序圖是對系統(tǒng)行為所做的描述的一部分。第六十七頁，共七十五頁，編輯于2023年，星期三5.2系統(tǒng)事件和系統(tǒng)操作系統(tǒng)事件（systemevent）是有某個(gè)參與者發(fā)起的指向某個(gè)系統(tǒng)