需求的OO描述方法課件

需求的OO描述方法本章內(nèi)容先導案例概述1

統(tǒng)一建模語言和對象管理組織2

OO的需求3

系統(tǒng)活動：OO的用例/場景視圖4

確定輸入和輸出——系統(tǒng)順序圖5

問題域建?！蚰Ｐ皖悎D6

OO模型的集成要點回顧閱讀章節(jié)要求06六月20232/117先導案例無限電子公司：供應鏈一體化06六月20233/117概述在OOA中需要使用事實發(fā)現(xiàn)技術。事實發(fā)現(xiàn)行為稱做發(fā)現(xiàn)活動，發(fā)現(xiàn)必須先于理解。本章學習發(fā)現(xiàn)的下一個階段：建立理解。事件發(fā)生在系統(tǒng)必須響應的商業(yè)環(huán)境中。事件被定義和記錄在事件表中。新系統(tǒng)必須能夠通過運行系統(tǒng)活動(用例)來響應商業(yè)事件。06六月20234/117系統(tǒng)的信息(包含在商業(yè)過程中的事物信息)存儲需求或使用傳統(tǒng)方法中的ERD進行記錄，或用OO方法中的類圖進行記錄。學習：使用OO的分析模型和技術來理解和定義新系統(tǒng)的需求。OO的分析和OO設計之間的界限并不明顯，因為系統(tǒng)的設計就是對分析階段中用于定義需求的模型進行改進和擴展得到的。06六月20235/117面向對象分析(OOA)系統(tǒng)分析過程中使用對象建模的方法被稱為面向對象分析(OOA)。06六月20236/117OOA技術用于研究現(xiàn)有對象，看它們是否能夠被復用或者被調整用于新的用途；定義各種新對象和修改后的對象，它們將與現(xiàn)有對象一起組合成一個有用的企業(yè)計算應用系統(tǒng)。06六月20237/117對象建模(ObjectModeling)是一種用于辨識系統(tǒng)環(huán)境中的對象和這些對象之間關系的技術。對象建模方法要求使用完全不同于數(shù)據(jù)建模和過程建模的方法和圖形記號。06六月20238/117術語對象:某種存在的，或者能被看到、觸摸或以其他方式感覺到的事物，用戶就該事物存儲數(shù)據(jù)和相關行為。屬性:表示關于一個對象相關特征的數(shù)據(jù)。對象實例:由描述特定的人、地點、事物或者事件的屬性值構成。行為:指的是對象可以做的事情，以及在對象數(shù)據(jù)(或屬性)上執(zhí)行的功能。在OO環(huán)境中，對象的行為通常被稱為方法、操作或者服務。封裝：幾項內(nèi)容一起打包成一個單元(信息隱藏)。06六月20239/117考慮我們所處的環(huán)境教室中的所有人，我們中的每一個都代表人對象的一個實例;我們中的每一個都可以按照一些公共屬性描述，例如：姓名、社會保險號、電話號碼、地址等。06六月202310/117對象的行為當看到周圍環(huán)境中的門對象時，可能僅僅看到一個不能思考的靜止對象——幾乎很少執(zhí)行什么動作。在用于系統(tǒng)開發(fā)的OO方法中，門對象可以同假定能夠在其上的行為相關聯(lián)。例如，門可以打開，可以關閉，可以鎖上，或者可以開鎖。所有這些行為都與門對象相關，并且由門對象實現(xiàn)，而不是由其他對象實現(xiàn)。06六月202311/117以電話對象為例什么行為同一個電話相關聯(lián)？隨著技術的進步，我們實際上有了語音激活的電話，我們可以應答、撥號、掛斷，還可以執(zhí)行其他與電話相關的行為。因此，用于系統(tǒng)開發(fā)的OO方法要求我們調整通?？创龑ο蟮姆绞?。06六月202312/117重要的OO原理對象單獨地負責執(zhí)行任何在其數(shù)據(jù)(或屬性)上操作的功能或者行為。例如：只有你(一個對象)可以修改(行為)你的名字和家庭住址(你的屬性)。引出對象的一個重要概念，即封裝。對象的屬性和行為都被封裝到一起作為那個對象的一部分。訪問或修改對象屬性只能通過那個對象的行為來實現(xiàn)。06六月202313/1171統(tǒng)一建模語言和對象管理組織OMG是一個由800多個軟件銷售商、開發(fā)商和組織組成的共同體，他們致力于發(fā)展和傳播OO系統(tǒng)。成立于1989年。使命：在分布式計算系統(tǒng)的開發(fā)中提高應用對象技術的理論和實踐水平。目標：為基于廣泛接口規(guī)格的OO的應用程序提供一個通用的體系框架。06六月202314/1172OO的需求系統(tǒng)開發(fā)過程開始于確定事件和事物。事件：新系統(tǒng)所必須考慮的商業(yè)過程；事物：包含在商業(yè)過程中的問題域對象。過程和對象通常一起定義(不斷切換)。必須學會將所有不同的模型和它們組合在一起生成完整的系統(tǒng)功能需求圖。本章主要討論一個關于模型的集合，它根據(jù)OO方法中的用例來捕獲系統(tǒng)需求四種模型——用例圖、用例描述、活動圖和系統(tǒng)順序圖，用來從不同的觀點描述系統(tǒng)用例。06六月202315/117使用模型來記錄需求最大的好處在于它能幫助系統(tǒng)開發(fā)員仔細和清楚地考慮處理的細節(jié)，以及系統(tǒng)相關人員的信息需求。06六月202316/117四種模型1.用例圖2.系統(tǒng)順序圖3.消息4.狀態(tài)圖06六月202317/1171.用例圖一種用以顯示不同的用戶角色和這些用戶角色如何使用系統(tǒng)的圖。以圖形化的方式描述系統(tǒng)與外部系統(tǒng)和用戶的交互。換言之，它們以圖形化的方式描述誰將使用系統(tǒng)，以及用戶期望以什么方式與系統(tǒng)交互。06六月202318/117目的：識別新系統(tǒng)的“用法”或用例，即識別如何使用系統(tǒng)。用例圖本質上是事件表的延伸。用例圖是用于記錄系統(tǒng)必須支持的所有功能的一種簡便方法。可以用一個綜合的用例圖來描述整個系統(tǒng)。活動圖可以用來定義用例。06六月202319/1172.系統(tǒng)順序圖(SSD)在用例或場景中，用于顯示外部參與者和系統(tǒng)之間的消息順序的圖。以圖形化的方式描述在一個用例或操作的執(zhí)行過程中對象如何通過消息互相交互，說明了消息如何在對象之間被發(fā)送和接收以及發(fā)送的順序。用來定義一個用例的輸入和輸出，以及在用戶和系統(tǒng)之間交互的順序。用于聯(lián)系用例詳細描述或活動圖。順序圖中，出入系統(tǒng)的信息流被稱為消息。06六月202320/1173.消息用例內(nèi)部對象之間的通信。當一個對象調用另一個對象的方法(行為)以請求信息或者某些動作時發(fā)生的通信。06六月202321/1174.狀態(tài)圖一種用以顯示對象在各階段中的生命和轉換的情況的圖。用于建模一個特定對象的動態(tài)行為，說明一個對象的生命周期——對象可以經(jīng)歷各種狀態(tài)，以及引起對象從一個狀態(tài)向另一個狀態(tài)轉換的事件。

狀態(tài)圖表(狀態(tài)圖)描述了每個對象狀態(tài)的集合。類圖中所標識的一些對象有些狀態(tài)情形需要跟蹤，這些狀態(tài)直接決定了對象的處理過程。06六月202322/117

客戶訂單有幾個比較重要的狀態(tài)條件，它們控制訂單的處理過程，例如，訂單只有在完成后才會發(fā)貨。狀態(tài)圖標識這些狀態(tài)條件并且標明允許的處理過程。同時，狀態(tài)圖也可用于設計過程，以確定系統(tǒng)本身的各種狀態(tài)，以及能夠處理的可允許的事件上。狀態(tài)圖既可以看做是分析工具，也可以看做是設計工具。06六月202323/1173系統(tǒng)活動：OO的用例/場景視圖3.1

用例和參與者3.2

用例圖3.3

開發(fā)用例圖3.4

用例詳細描述06六月202324/117用例分析的目標用來標識和定義系統(tǒng)必須支持的所有商業(yè)過程。分析員在綜合等級和詳細等級兩個層次上定義用例。事件表和用例圖為一個系統(tǒng)提供了所有用例的綜合。關于每個用例的詳細信息使用用例描述、活動圖和系統(tǒng)順序圖，或者這些模型的組合進行說明。06六月202325/1173.1用例和參與者用例：系統(tǒng)運行的活動，通常由系統(tǒng)用戶來響應需求。用例中蘊涵使用系統(tǒng)的人：參與者。參與者通常處于自動化系統(tǒng)邊界之外，但是它也有可能是系統(tǒng)手動部分的成員。06六月202326/117參與者與事件的源的區(qū)別參與者的概念與在事件表中所定義的事件的“源”在內(nèi)涵上略有不同。事件的源：指事件的發(fā)起者，例如一個用戶，并且它通常在系統(tǒng)(包括手動系統(tǒng))的外部。參與者實際上是親自和計算機系統(tǒng)進行交互的人。06六月202327/117定義參與者①和系統(tǒng)進行交互的人定義為參與者。(自動化系統(tǒng)所必須響應的交互)②將能夠接觸自動系統(tǒng)的人定義為參與者。有些參與者可能是其他的系統(tǒng)或者從系統(tǒng)接受服務的設備。③把參與者看成一個角色。④考慮參與者和用例，認為用例是參與者想要完成的目標。06六月202328/117例：RMO中用例“產(chǎn)生新訂單”的情況可能會涉及一個銷售代表在電話里與一名客戶進行交談。如果這位客戶直接在Internet上訂貨，那他也是個參與者。標志目標的方法：訂單職員使用系統(tǒng)來生成新訂單。

3.2用例圖用例圖：概括有關參與者和用例信息的一個圖形化的模型。

1.自動化邊界和組織

2.組織用例圖的方法

3.用例之間的關系

4.用例圖與事件表的比較06六月202329/117例：有一個參與者的簡單用例。*1.自動化邊界和組織在全套的用例上畫一條邊界線。該邊界是自動化邊界。它表示環(huán)境(參與者的居住地)和自動系統(tǒng)的內(nèi)部功能之間的邊界。06六月202330/117員對前面的圖進行了擴展，增加了參與者和用例。在該實例中，訂單員和用戶都可直接訪問系統(tǒng)。正像有關系線連接表示的那樣，每個參與者可以操作所有的用例。2.組織用例圖的方法⑴使用子系統(tǒng)⑵包含涉及一個特定參與者的所有用例06六月202331/117⑴使用子系統(tǒng)訂單輸入子系統(tǒng)用例圖，顯示系統(tǒng)邊界06六月202332/117員RMO客戶支持系統(tǒng)用例圖(子系統(tǒng))06六月202333/117*⑵包含涉及一個特定參與者的所有用例06六月202334/117圖表示了與一個客戶參與者相關的所有用例。該圖在表明所有通過Internet訪問的活動時非常有用。分析員可以選擇繪制基于項目團隊需要的用例圖。如果計劃與市場部門經(jīng)理會面討論所有涉及直接客戶交互的用例，則圖中的用例圖會很有用。3.用例之間的關系⑴擴展⑵包含⑶泛化06六月202335/117<<包含>>關系通常在用例圖的開發(fā)過程中，一個用例需要用到通用子程序所提供的服務。例如，“訂單輸入子系統(tǒng)”的兩個用例是“產(chǎn)生新訂單”、“更新訂單”，這兩個用例均須檢查客戶的賬號是否正確。因此，可以定義一個通用的子程序來完成這個功能，并且它變成了一個附加用例。06六月202336/117有<<包含>>關系用例的訂單輸入子系統(tǒng)關系可讀做“產(chǎn)生新訂單<<包含>>驗證用戶賬號”。<<包含>>關系也稱<<包括>>關系或者<<使用>>關系。06六月202337/117名為“驗證用戶賬號”的用例，它被“產(chǎn)生新訂單”、“更新訂單”兩個用例調用。用例之間的關系由帶箭頭的連接線表示?！皺z查條目可用性”可能是<<包含>>關系的一部分。分析員可定義兩種類型的<<包含>>關系：一種是通用內(nèi)部子程序，如“驗證用戶賬號”，它不被外部參與者直接引用；另一種是能被外部參與者直接引用，如“檢查條目可用性”。⑴擴展當某個基本用例由于需要附加一個用例來擴展或延伸其原有功能時，附加的擴展用例與原有的基本用例之間的關系就體現(xiàn)為擴展關系。在UML中可使用帶有<<extend>>說明的依賴關系表示“擴展關系”。例：網(wǎng)上購物系統(tǒng)中有“支付”用例，而“網(wǎng)上支付”用例是“支付”用例的擴展用例。06六月202338/117支付網(wǎng)上支付<<extend>>基本用例擴展用例*從基本用例A到擴展用例B的擴展關系表明：按基本用例A中指定的條件，把擴展用例B的行為插入到由A中的擴展點定義的位置。也就是說基本用例A可以單獨存在，但在一定的條件下，它的行為可被另一個用例B的行為擴展。一個用例可以擴展多個用例，一個用例也可以被多個用例擴展。擴展用例不能作為動作序列單獨出現(xiàn)，但基本用例在缺少任何擴展用例的情況下也必須是獨立的用例。06六月202339/117⑵包含

如果在若干個用例中有某些相同的動作，則可把這些相同的動作提取出來單獨構成一個用例(稱抽象用例)。(將多個用例中的公共部分抽取出來作一個單獨用例)。當某個用例使用該抽象用例時，就好像這個用例包含了抽象用例中的所有動作。UML中使用帶有<<include>>說明的依賴關系表示“包含關系”。例：網(wǎng)上購物系統(tǒng)中有一個“訂購”用例，而“查詢”用例是“訂購”用例的包含用例。06六月202340/117*訂購查詢<<include

>>包含用例

如果從用例A到用例B存在包含關系，則用例A在它內(nèi)部說明的某一位置上顯式地使用用例B的行為的結果。被包含的用例B作為包含它的用例A的功能的一部分出現(xiàn)?？梢园寻P系想像為基本用例調用供應者用例，基本用例僅僅依賴供應者用例執(zhí)行的結果，而不依賴供應者用例的內(nèi)部結構。一個用例可以包含多個用例，一個用例也可以被多個用例包含。06六月202341/117例：網(wǎng)上訂購商品軟件系統(tǒng)需要對顧客的信用進行檢查，檢查輸入的信用卡號是否有效，信用卡是否有足夠的資金支持本次訂購。由于該功能在“訂購”過程中使用，因此是包含關系。在執(zhí)行“改變訂購量”用例時，只有預定量改變時才執(zhí)行“檢查信用”用例，如果預訂量不改變，則不執(zhí)行“檢查信用”用例。由于“檢查信用”用例是可選執(zhí)行的，因此，用例之間存在擴展關系。箭頭從可選運行的用例“檢查信用”指向被擴展的用例。06六月202342/117顧客訂購檢查信用<<include

>>改變預訂量<<extend

>>擴展和包含之間的異同兩種關系意味著從幾個用例中抽取那些公共的行為并放入一個單獨的用例中，而這個用例被其他用例擴展或包含。包含和擴展的目的是不同的。通常在描述一般行為的變化時采用擴展關系；在兩個或多個用例中出現(xiàn)重復描述又想避免這種重復時，可以采用包含關系。06六月202343/117⑶泛化從用例A到用例B之間的泛化關系表明：父用例表示通用的行為序列。通過插入額外的步驟或定義步驟，子用例特化父用例。UML表示用例泛化的方法與類相同。例：在線股票經(jīng)紀人系統(tǒng)把通用用例“做交易”特化為子用例“交易債券”、“交易股票”和“交易期權”。父用例包含所有交易類型都會執(zhí)行的步驟，如輸入交易密碼。每個子用例都包含了針對某種交易類型特別安排的額外步驟，如輸入期權的行權日期。06六月202344/117做交易交易債券交易股票交易期權4.用例圖與事件表的比較①模型的觀點有細微的不同②標識臨時事件和狀態(tài)事件時有差別③定義一個用例支持多個商業(yè)事件06六月202345/117①模型的觀點有細微的不同事件表通常注意商業(yè)過程。它通過標識商業(yè)事件，以及這些事件的外部、初始化源的信息來關注商業(yè)過程。外部的源是引起商業(yè)事件初始化的原因，并且它們能從自動系統(tǒng)中輕松的移除。用例圖強調了自動系統(tǒng)。因為它只與自動系統(tǒng)相連，所以參與者與自動系統(tǒng)有聯(lián)系并且不一定是商業(yè)事件的發(fā)起者。06六月202346/117②標識臨時事件和狀態(tài)事件時有差別由于用例通常被外部參與者初始化，所以如果分析員不仔細標識每一個事件，那么臨時事件和狀態(tài)事件經(jīng)常被忽略。用例定義太窄將成為用例建模的一個缺陷。如：在線系統(tǒng)菜單常包括用于表示事件表中臨時事件的菜單選項，以便這樣的事件能夠被用戶觸發(fā)并且作為純粹的臨時事件。建議：為每個臨時事件和狀態(tài)事件創(chuàng)建用例以確保這些需求不被忽略。06六月202347/117③定義一個用例支持多個商業(yè)事件滿足3個標準，則定義一個用例：本質上相同的處理發(fā)生在自動系統(tǒng)內(nèi)部；本質上相同的信息被更新；本質上相同的信息從事件中輸入和輸出。例：開發(fā)事件表過程中，添加新用戶和更新用戶兩個事件已被標識出來。從系統(tǒng)觀點出發(fā)，兩個商業(yè)事件的用例幾乎一樣，因為它們都包含更新用戶文件?？啥x一個單獨的用例來支持這兩個商業(yè)事件，該用例可命名為“維護客戶賬戶信息”。06六月202348/117分析員會同時完成事件表和用例圖，并不斷更新。在商業(yè)事件對單一、簡單的數(shù)據(jù)文件或表進行基本的文件維護時，這些條件常常能夠滿足。有時單一事件可觸發(fā)非常復雜的處理需求，這將使系統(tǒng)活動分解為兩個用例以更好地管理系統(tǒng)復雜性，使其變得更加有意義。3.3開發(fā)用例圖1.兩個切入點2.兩步迭代3.CRUD分析06六月202349/1171.兩個切入點⑴若創(chuàng)建了事件表，則用事件表標識用例⑵標識使用系統(tǒng)的參與者和它們執(zhí)行的功能06六月202350/117⑴若創(chuàng)建了事件表，則用事件表標識用例仔細分析事件表中的每個事件以確定系統(tǒng)為支持這些事件、發(fā)起這個事件的參與者，以及由于該事件而觸發(fā)的其他用例所執(zhí)行的處理。當一個模型轉向另一個更詳細的模型時需要不斷精煉，仔細分析事件和事件表非常重要。開發(fā)人員可將一個單一的事件標識為用例，如所需的處理很相似，可把幾個事件組合成一個單獨的用例；或如果處理很復雜，也可標識多個用例。多個用例的標識通常發(fā)生在它們有<<包含>>關系和兩個用例從一個大用例分解得到時，或發(fā)生在一個附加用例按照通用子程序的方式被定義時。06六月202351/117該圖顯示的客戶支持子系統(tǒng)是使用該方法開發(fā)。圖中定義的絕大多數(shù)用例直接來自事件表。用例名稱來自事件表的活動/用例欄中的描述。例外:①由于臨時事件通常可手動發(fā)起,所以要為每個臨時用例使用標識外部參與者選項。

②“客戶修改賬戶信息”事件。在該實例中，用例定義擴展到和所有維護客戶信息相關的場景中。同樣，該用例被命名為維護客戶賬戶信息，指的是添加、更新和刪除。這些都是用例對事件表進行提煉更新的例子。06六月202353/117RMO客戶支持系統(tǒng)的完整事件表⑵標識使用系統(tǒng)的參與者和它們執(zhí)行的功能若沒創(chuàng)建事件表，則開發(fā)用例圖的另一個切入點是標識使用系統(tǒng)的參與者和它們執(zhí)行的功能。記住兩個前提條件：為一個自動系統(tǒng)創(chuàng)建自動化邊界，這樣標識的參與者就能和這個系統(tǒng)進行聯(lián)系；必須假定擁有完美的技術，確定用例是基于商業(yè)事件而不是像登錄系統(tǒng)一樣的技術活動。只有給出上述前提，才可通過兩步迭代來開發(fā)用例圖。06六月202354/1172.兩步迭代⑴標識系統(tǒng)的參與者⑵開發(fā)這些角色的目標表06六月202355/117⑴標識系統(tǒng)的參與者參與者通常由用戶扮演。不能把參與者列成如Bob先生這樣的形式，而應該標識出這些人所處的特定的角色。記住，在一個系統(tǒng)中同一個人可以有多個特定的角色。理解和辨識系統(tǒng)所有可能使用的角色是重要的。其他的系統(tǒng)也可以成為系統(tǒng)的參與者。06六月202356/117⑵開發(fā)這些角色的目標表目標指參與者執(zhí)行完成一些商業(yè)功能的任務。目標通常是類似營銷、接受用戶反饋或者訂單發(fā)貨這樣的任務。目標是能夠被標識和描述的工作單元。在目標完成時，系統(tǒng)數(shù)據(jù)在一段時間內(nèi)是不會改變的。兩個步驟常應用于項目組成員和用戶的集體討論中，并沒什么捷徑可以用來發(fā)現(xiàn)或標識用例。06六月202357/1173.CRUD分析將標識后的用例與域模型類圖進行比較(復查)。需要類圖中每個類都有足夠的用例來支持創(chuàng)建新對象實例、讀取或者報告這些對象、更新這些對象并且在許多例子中刪除對象實例。檢查在域模型類圖中的每個類并確定在用例圖中有用例來支持所有適合該應用的CRUD功能。06六月202358/117RMO的一個活動數(shù)據(jù)矩陣06六月202359/117CRUD分析需要類圖中每個類都有足夠的用例來支持創(chuàng)建新對象實例、讀取或者報告這些對象、更新這些對象產(chǎn)且在許多例子中刪除對象實例。用例不應該命名為創(chuàng)建或者更新，但是潛在的處理可以添加新的實例或者更新已存在的實例。例如，一個名為“記錄支付情況”的用例并沒有清楚地指出一個新的支付對象被創(chuàng)建，但是用例的詳細描述卻指出這個對象被創(chuàng)建了。用例“產(chǎn)生新訂單”可以創(chuàng)建訂單條目對象和更新庫存條目對象。在其他例子中，許多用例以維護兩字開頭命名，以覆蓋常規(guī)的添加、更新、讀取和刪除操作。06六月202360/117為了做CRUD分析，只須看一下在域模型類圖中的每個類并確定在用例圖中有用例來支持所有適合該應用的CRUD功能。切記：在集成系統(tǒng)中，一個系統(tǒng)可能負責創(chuàng)建對象，而另外的系統(tǒng)可以只更新它們。CRUD分析方法提供了一種交叉檢驗方法(不是最終的解決方案)，并且提供了確認重要的系統(tǒng)集成需求的機會，這些需求如果不用該方法逆行分析可能就不明顯了。06六月202361/1173.4用例詳細描述0.場景或者用例實例1.簡單描述2.中間描述3.完全展開描述4.活動圖描述06六月202362/1170.場景或者用例實例用例中步驟的一個特定順序。一個用例可以有幾個不同的場景。商業(yè)步驟的變化存在于單一用例中。不同的參與者調用用例，有不同的活動流。為了完成商業(yè)過程，用例要包括完整的步驟順序。每個活動流都是一個有效的順序。不同的活動流稱為場景(也稱用例實例)。場景是對一個用例中的一套內(nèi)部活動的識別和描述。它代表通過用例的惟一路徑。06六月202363/117通常商業(yè)步驟的變化存在于單一用例中?！爱a(chǎn)生新訂單”用例，根據(jù)哪些參與者調用用例，將有不同的活動流。訂單職員通過電話來建立新訂單的過程與用戶通過Internet建立訂單的過程是非常不同的?？梢园慈齻€獨立的詳細描述等級進行用例描述。06六月202364/1171.簡單描述用于非常簡單的用例，特別是當要開發(fā)的系統(tǒng)是一個很小并且易于理解的應用時。一個簡單的用例通常有單一的場景和即使有也很少的異常條件。用于和活動圖進行連接的簡單描述為簡單用例提供了可靠的描述。06六月202365/117“產(chǎn)生新訂單”用例的簡單描述當用戶電話訂購時，訂單支援和系統(tǒng)會檢驗用戶信息，創(chuàng)建一個新訂單，將各條目加入訂單中，檢驗支付款項，創(chuàng)建這個訂單交易，最后完成訂單。通常，像“產(chǎn)生新訂單”這樣的用例是很復雜的，它們可以用中間或者完全展開描述進行描述。06六月202366/1172.中間描述中間等級的用例描述擴展了簡單描述，它包括了用例的內(nèi)部活動流。如果有多個場景，其中每個活動流都被單獨的進行描述。如果它們需要，還可以記錄下其他條件。06六月202367/117產(chǎn)生新訂單電話訂購場景的中間描述06六月202368/117注意：每個場景都描述了用戶和系統(tǒng)所需要執(zhí)行的處理，同時還列出了異常條件。每一步都進行了標號，以方便閱讀。在許多方法中，描述都是結構化英語，它包括了順序、分支和循環(huán)。產(chǎn)生新訂單Web訂購場景的中間描述3.完全展開描述完全展開描述是記錄用例的最正式的方法。它要花費較多的工作在這個層次上定義所有的組件，但它仍然是描述用例內(nèi)部活動流的首選方法。如果創(chuàng)建完全展開用例描述，更有可能完全理解商業(yè)過程和系統(tǒng)支持它們的方式。06六月202370/117創(chuàng)建新訂單的網(wǎng)上訂購場景的完全展開圖06六月202371/117產(chǎn)生新訂單電話訂購場景的完全展開描述06六月202372/1171、2行標識所記錄用例的內(nèi)部用例和場景。給用例添加帶有擴展名的惟一標識符，以標識特定的場景?；蛑谱髟摫砀竦娜藛T姓名。標識發(fā)起該用例的觸發(fā)器。從兩個角度描述觸發(fā)器：標識觸發(fā)處理的商業(yè)事件、用例已經(jīng)開始運作的活動。用例和場景的簡單描述。分析員只須復制他們先前建立的簡單描述。標識一個或多個參與者?？梢詮椭朴美龍D本身所包含的一些信息。標識其他用例和它們與該用例相關聯(lián)的方式，如<<包含>>關系標識相關人員，而不是特定的參與者?？梢允菦]調用但對用例結果感興趣的用戶

前提條件:在用例初始化之前必須為真的一組條件。后續(xù)條件:在用例執(zhí)行完成時必須為真的一組條件。最后兩行描述用例活動流的詳細信息。*4.活動圖描述使用活動圖是記錄用例場景的另外一種方式。在實例中，活動圖將作為一種有效的技術用于記錄每個用例場景的活動流?；顒訄D可以用來支持任何等級的用例描述。活動圖和完全展開描述中的兩列(參與者、系統(tǒng))描述非常相似。創(chuàng)建活動圖的好處在于它更加形象，并且有助于用戶和開發(fā)人員一起工作來完整地記錄用例。06六月202373/117活動圖以圖形化方式描述一個業(yè)務過程或者一個用例的活動的順序。它也可以用于建模一個操作要執(zhí)行的動作，以及那些動作的結果?；顒訄D用于記錄商業(yè)過程工作流。06六月202374/117電話訂購場景的活動圖圖中，客戶和訂單職員交互，輪流使用系統(tǒng)。因用例的目的是說明參與者和系統(tǒng)間的相互作用，故圖中包含訂單職員和計算機系統(tǒng)的活動圖矩形區(qū)。為幫助理解場景的所有活動流，觸發(fā)這一步驟的客戶也要包括進來。客戶矩形區(qū)是可選的附加項，它有助于理解整個工作流。Web訂購場景的活動圖圖中用戶是與計算機系統(tǒng)相互作用的參與者，所以只需要兩個矩形區(qū)來描述場景中的步驟。4確定輸入和輸出——系統(tǒng)順序圖4.0

交互圖4.1

系統(tǒng)順序圖符號4.2

開發(fā)系統(tǒng)順序圖06六月202377/1174.0交互圖在OO方法中，信息流是通過向參與者或內(nèi)部對象來回發(fā)送消息而形成的。系統(tǒng)順序圖(SSD)用于描述進出自動系統(tǒng)的信息流，所以一個系統(tǒng)順序流記錄輸入和輸出并且標識了參與者和系統(tǒng)之間的交互。系統(tǒng)順序圖是交互圖的一種。交互圖：用于顯示對象間的相互作用的協(xié)作圖或順序圖。06六月202378/1174.1系統(tǒng)順序圖符號1.線條2.帶下劃線的對象名稱和矩形框3.虛線4.生命線之間箭頭5.系統(tǒng)順序圖的例子6.消息06六月202379/117用例圖與SSD在用例圖中，參與者“使用”系統(tǒng)。在SSD中參與者如何通過輸入數(shù)據(jù)和獲得輸出數(shù)據(jù)來和系統(tǒng)進行交互才是重點。兩個圖有著相同的思想，不同的描述等級。06六月202380/1171.線條代表和系統(tǒng)交互的參與者(人或角色)。06六月202381/1172.帶下劃線的對象名稱和矩形框標記為:系統(tǒng)的方框是代表整個自動系統(tǒng)的對象。在SSD和所有交互圖中，分析員使用對象符號代替類符號。對象符號表明方框指的是一個獨立的對象而不是所有類似對象的類。符號由帶有下劃線的對象名稱和一個矩形框組成，其中冒號是可選的，是對象符號的一部分。在交互圖中消息通過獨立對象(不是類)進行發(fā)送和接收。在SSD中，只有代表整個系統(tǒng)的對象才會被包括進來。06六月202382/1173.虛線稱為生命線。在整個SSD期間內(nèi)，生命線或者對象生命線僅僅是這個對象(參與者或對象)的擴展。06六月202383/1174.生命線之間箭頭代表參與者和系統(tǒng)的發(fā)送和接收。每個箭頭都有一個起點和終點。消息的起點是箭頭尾部的生命線所指的發(fā)送它的參與者或對象。消息的目標參與者或對象是由箭頭所指向的生命線指示的。生命線目的是指示參與者和對象發(fā)送和接收消息的順序。06六月202384/1175.系統(tǒng)順序圖的例子06六月202385/117和消息一起發(fā)送的輸入數(shù)據(jù)被括在圓括號中，在該例中它是一種用來確定特定條目的數(shù)據(jù)。語法是帶有用括號括起來的輸入?yún)?shù)的消息名。該語法形式常附加在實線箭頭上。6.消息標有記號的消息用來描述消息的目的，以及被發(fā)送的任何輸入數(shù)據(jù)。在順序圖中，消息被認為是在目的對象上調用的一種活動，它更像一條命令語句。箭頭代表消息和輸入數(shù)據(jù)。實線箭頭：其上附帶有用括號括起來的輸入?yún)?shù)的消息名。虛線箭頭：指明一個響應或應答，其返回消息(條目信息)，它們通常緊跟在啟動消息的后面。：注釋信息。06六月202386/117消息的符號消息的完整符號：*[真/假條件]返回值:=消息名(參數(shù)列表)消息的任何部分都可省略。06六月202387/117消息符號的組成星號(*)：表示消息的重復或者循環(huán)。方括號[]：表示真/假條件。值為真，消息被發(fā)送。否則消息不發(fā)送。消息名：對所需服務的描述。在虛線返回消息時，它被省略，而僅顯示返回的數(shù)據(jù)參數(shù)。參數(shù)列表(帶有圓括號表示啟動消息；沒有圓括號表示返回消息):顯示消息傳遞的數(shù)據(jù)。與消息處于同一線上(需要:=)的返回值:用于描述從目的對象返回到源對象的消息響應數(shù)據(jù)。06六月202388/117*[真/假條件]返回值:=消息名(參數(shù)列表)重復消息06六月202389/117消息和返回數(shù)據(jù)可顯示在一個步驟中。返回數(shù)據(jù)作為返回值標識在賦值操作符(:=)的左邊。

4.2開發(fā)系統(tǒng)順序圖1.開發(fā)SSD所需要的條件2.基于活動圖開發(fā)SSD步驟3.RMO例06六月202390/1171.開發(fā)SSD所需要的條件SSD通常用來和用例描述相聯(lián)系，以幫助記錄用例中一個單獨的用例或場景的詳細信息。開發(fā)SSD需要有用例的詳細描述：完全展開形式、活動圖。使用活動圖的優(yōu)點：很容易確定輸入或輸出何時發(fā)生。06六月202391/117電話訂購場景的簡化活動圖

2.基于活動圖開發(fā)SSD步驟首先確定系統(tǒng)邊界，即訂單職員矩形區(qū)和計算機系統(tǒng)矩形區(qū)之間的豎線部分。

⑴標識輸入消息

⑵描述從外部參與者到系統(tǒng)的消息

⑶在輸入消息上確定并添加特定條件

⑷確定并添加輸出返回消息06六月202393/117

順序圖的目的就是描述自動計算機系統(tǒng)的輸入和輸出，所以順序圖將只包括訂單職員和計算機系統(tǒng)。在順序圖中將兩個參與者都包含進來也是正確的，但只包含系統(tǒng)和其中發(fā)送輸入和接收輸出的參與者將使得重點更加突出。06六月202394/117⑴標識輸入消息在例圖中，有三個地方的工作流穿過訂單職員和系統(tǒng)之間的邊界線。在每一個工作流穿過自動化邊界的地方，都須輸入數(shù)據(jù)，因此同樣需要消息。06六月202395/117⑵描述從外部參與者到系統(tǒng)的消息消息名：要反映參與者向系統(tǒng)請求的服務。參數(shù)列表：開發(fā)人員要確定數(shù)據(jù)參數(shù)通常需要數(shù)次的迭代，才能找到一個正確而又完整的列表。確定數(shù)據(jù)參數(shù)的規(guī)則：根據(jù)類圖來確定數(shù)據(jù)參數(shù)(類中一些恰當?shù)膶傩钥梢杂米鰠?shù)列表)。06六月202396/117“產(chǎn)生新建訂單”用例電話訂購場景的SSDstartOrder：本用例的前提條件是用戶應存在。后續(xù)條件是訂單必須與一個客戶相關聯(lián)。addItem：需要參數(shù)來標識目錄中的條目，以及要購買的數(shù)量。completeOrder：基于活動圖，須輸入支付數(shù)量。06六月202397/117⑶在輸入消息上確定并添加特定條件本例中，有迭代框和與之相關的真/假條件(在方括號中)。06六月202398/117⑷確定并添加輸出返回消息顯示返回消息的兩種選擇：①在消息上添加返回值②用虛線箭頭表示一個獨立的返回消息。活動圖可提供關于返回消息的線索，但并沒有一個標準的規(guī)則，當工作流中的轉換箭頭從系統(tǒng)出發(fā)到達外部參與者的時候，不一定總會產(chǎn)生一個輸出。06六月202399/117系統(tǒng)分析的目標是理解和發(fā)現(xiàn)，所以應該與用戶一起工作，以便準確定義工作流是如何運作的，以及什么樣的信息需要作為輸出被傳遞和提供。這是一個迭代過程，在這些圖反映用戶需要之前，需要多次地修改。06六月2023100/1173.RMO例產(chǎn)生新訂單用例的Web訂購場景的簡化系統(tǒng)順序圖。06六月2023101/117Web訂購場景活動圖SSD5問題域建模——域模型類圖由于事物存在于真實的對象中，而對象是OO方法的基礎，所以類圖常被認為是所有UML模型中最重要的一個。事實上，類圖是OO開發(fā)中的一個焦點。每個其他的UML模型必須與類圖一致。域模型類圖只是一個開始。06六月2023103/117定義系統(tǒng)需求時開發(fā)人員只關注用戶問題域類，定義這些系統(tǒng)需求而建立的類圖稱為域模型類圖或簡稱為域模型，因為它顯示的類是用戶問題域中的一部分。域模型類圖并不顯示方法，相反它主要關注的是用戶真實世界的對象。06六月2023104/117域模型類