上傳人：s***

認(rèn)證信息

認(rèn)證類型：個人認(rèn)證

認(rèn)證主體：胡**（實名認(rèn)證）

IP屬地：天津

IP屬地：天津 上傳時間：2022-10-13 格式：DOCX 頁數(shù)：11 大?。?00.33KB 積分：20 舉報 版權(quán)申訴

1、這是我在csdn博客的第2篇技術(shù)文章，本來按原計劃是要介紹開源ajax框架buffalo 的第2部分，即jsJava的序列化，這里面涉及不少設(shè)計模式的運用和JAVA SE知識， 代碼精簡，比較精彩。但是由于個人時間有限，在抉擇之后，打算先寫一篇關(guān)于面向?qū)ο蠓?析的文章，也算是對自己過去1年多在這方面學(xué)習(xí)的總結(jié)。我選了比較簡單且大家也比較 熟悉的案例來分析，案例雖然簡單，但是基本的分析方法和推導(dǎo)過程還是一致的，我主要想 講的是原始需求是怎么通過層層分析和推導(dǎo)而形成最后可執(zhí)行代碼的，限于自己的個人能力， 如果有謬論和錯誤之處，還望同行多指教和幫助，共同進(jìn)步。原始需求描述如下：某公司鑒于業(yè)務(wù)和員工的

2、快速發(fā)展，為了提升整體工作效率，公司 準(zhǔn)備開發(fā)一套員工報賬系統(tǒng)，取代原來的人工處理方式，更加方便的服務(wù)于員工日常的賬務(wù) 操作。財務(wù)部門能夠通過賬務(wù)系統(tǒng)定期向各部門負(fù)責(zé)人反映賬務(wù)統(tǒng)計情況，并設(shè)置和維護(hù)相 關(guān)額度準(zhǔn)則。系統(tǒng)應(yīng)該具有基于先進(jìn)技術(shù)的操作界面。這段描述里包含的業(yè)務(wù)目標(biāo)大致有二：為員工提供賬務(wù)的自動化辦理，提高辦事效率，方便員工。方便財務(wù)部門管理好賬務(wù)信息。這些業(yè)務(wù)目標(biāo)一般在項目的招標(biāo)書里都有相關(guān)的描述，也可以由開發(fā)方整理得出。之所以 這里要把業(yè)務(wù)目標(biāo)列出來，是因為我所采取的方法里，業(yè)務(wù)目標(biāo)是進(jìn)行需求分析的第一步， 接下來的推導(dǎo)過程和業(yè)務(wù)模型的建立都是根據(jù)業(yè)務(wù)目標(biāo)開始的。整理出了業(yè)務(wù)目標(biāo)后

3、，接下來先不要一頭扎進(jìn)具體的業(yè)務(wù)流程和業(yè)務(wù)細(xì)節(jié)之中去，應(yīng)該先 把涉眾找出來，整理出一份涉眾分析報告，涉眾就是和這個項目相關(guān)的人。也不要就去考慮 技術(shù)實現(xiàn)細(xì)節(jié)，要用什么先進(jìn)的技術(shù)，界面如何美觀，性能如何優(yōu)越等等，雖然這些確實重 要，但是相比起來，忠實的實現(xiàn)涉眾的期望，滿足涉眾的需求才是最為重要，也是一個項目 成敗的關(guān)鍵。在實際的項目中，我們可以通過需求調(diào)研找出相關(guān)的涉眾，這里我就直接列出 本案例的涉眾分析報告：員工：公司的正式錄用雇員；期望：通過網(wǎng)上辦理賬務(wù)業(yè)務(wù)申請，計算機(jī)控制流程。部門經(jīng)理：部門負(fù)責(zé)人，負(fù)責(zé)審核員工提交的申請；期望：方便審核操作，通過計算機(jī)代 替原來的手工審核方式。公司主任：公

4、司負(fù)責(zé)人，負(fù)責(zé)2次審核員工提交的申請；期望：方便審核操作，通過計算 機(jī)代替原來的手工審核方式，界面友好易用。財務(wù)主任：公司財務(wù)部門負(fù)責(zé)人，負(fù)責(zé)發(fā)放報賬款項；期望：通過計算機(jī)轉(zhuǎn)賬的方式替代 原來的人為付款方式。以上的涉眾分析報告是很簡單的了，在實際稍微復(fù)雜些的項目中要下功夫好好整理清楚一 份完整的文檔才是，因為接下來的業(yè)務(wù)用例獲取工作也是在此基礎(chǔ)上展開的。這里先羅嗦下業(yè)務(wù)用例和平時開發(fā)中的我們開發(fā)人員從項目經(jīng)理或者需求人員手中拿到 的需求文檔中的用例什么區(qū)別。按我個人理解來說后者是系統(tǒng)用例，兩者的關(guān)鍵區(qū)別在于抽 象層次和用例粒度的不同，系統(tǒng)用例是以人與計算機(jī)的每次交互為單位的，而業(yè)務(wù)用例則是 在

5、較高的層次上用于確立業(yè)務(wù)需求范圍和描述系統(tǒng)功能性需求的。也就是說我們在描述業(yè)務(wù) 用例的時候，可以不用去考慮具體和計算機(jī)相關(guān)的實現(xiàn)步驟和細(xì)節(jié)，從而降低我們?nèi)四X需要 考慮的復(fù)雜度，專注于確立業(yè)務(wù)需求范圍，抽象就是面向?qū)ο蟮膬?yōu)勢所在，不用像過程化思 維那樣通盤考慮，因為人腦能接受的信息量是有限的。系統(tǒng)用例一般是從業(yè)務(wù)用例中推導(dǎo)出 來的，本文之后會有關(guān)于這方面的推導(dǎo)過程。不知道有沒跑題，羅嗦了一段，現(xiàn)在回來，分析下本案例中的業(yè)務(wù)用例獲取工作。說到 用例，就必須結(jié)合邊界和業(yè)務(wù)主角，否則用例的粒度就會出現(xiàn)問題，因為用例是以參與者（業(yè) 務(wù)主角）為核心的，是由業(yè)務(wù)主角發(fā)起的以達(dá)到業(yè)務(wù)主角完整目標(biāo)為標(biāo)準(zhǔn)的。要獲

6、取用例就 必須先得出邊界，邊界有了，那么邊界外的業(yè)務(wù)主角就有了，那么業(yè)務(wù)主角對這個邊界內(nèi)的 目標(biāo)就是用例了。用UML表示如下：我們先來看看一個小例子，沒有引入邊界的概念對獲取用例有什么影響，比如我去食堂就 餐，要先領(lǐng)取餐具，然后點菜，打菜的阿姨幫忙盛菜，接著我刷卡付款，去盛飯和湯，之后 是找座位，最后才開始就餐。那么領(lǐng)取餐具，點菜，刷卡付款之類的算是一個用例嗎？說算 也算，說不算也不算。因為這要根據(jù)邊界來確定的，我們都知道用例是以主角發(fā)起的以完成 主角的完整目標(biāo)為標(biāo)準(zhǔn)的。這里的主角就是我本人，要確定我的目標(biāo)就必須先確定邊界，比 如以整個食堂為邊界，那么我去食堂的目的就是就餐，就餐才是我的完整目

7、標(biāo)，而其他諸如 領(lǐng)取餐具，點菜，刷卡付款之類的都不是我去食堂的目的，這些只是我完成就餐的步驟而已， 但如果把邊界粒度降低到食堂的內(nèi)部，那么這個時候領(lǐng)取餐具，刷卡付款之類的也是一個用 例了，雖然都是用例，但是和就餐這個用例的粒度是不同的，因為他們邊界所在的抽象層次 不同。所以要描述用例就必須先劃分出邊界來，主角站在邊界外對這個邊界提出目標(biāo)，一個 目標(biāo)就是一個用例，否則在描述系統(tǒng)的時候就會出現(xiàn)如我去食堂的目的是刷卡付款這樣的笑 話來，當(dāng)然了，除非我去食堂的目的真的只是為了付款?；氐奖疚牡陌咐衼?，開始進(jìn)行獲取業(yè)務(wù)用例的分析，剛才說了，要獲取用例必須先確 定好邊界，那么怎么確定邊界呢？這個時候我們前

8、面劃分業(yè)務(wù)目標(biāo)的作用就體現(xiàn)出來了，我 們可以以每個業(yè)務(wù)目標(biāo)為一個邊界，因為所有業(yè)務(wù)目標(biāo)匯集起來就表示達(dá)到了系統(tǒng)建設(shè)目標(biāo)， 而針對每個業(yè)務(wù)目標(biāo)定義的邊界，明確了哪些涉眾與這一業(yè)務(wù)目標(biāo)有關(guān)，他們作為業(yè)務(wù)主角站在這一邊界外提出他們的期望，這些期望作為用例都是為實現(xiàn)這一業(yè)務(wù)目標(biāo)服務(wù)的，獲取 業(yè)務(wù)用例的方向就明確了（不符合這一業(yè)務(wù)目標(biāo)的期望則不被采納）。如上圖，邊界和業(yè)務(wù)主角都已經(jīng)有了，接著就是找出用例了，我以員工賬務(wù)服務(wù)邊界為例， 根據(jù)涉眾分析報告和客戶訪談（這個在實際項目中需要好好歷練的，我覺得要有技巧引導(dǎo)客 戶，還要有較強(qiáng)的總結(jié)概括能力吧）得出的。假定我從與客戶訪談的結(jié)果中得出員工對這個 系統(tǒng)的期

9、望和目標(biāo)有通過計算機(jī)申請報銷業(yè)務(wù)，申請借款業(yè)務(wù)，這兩個期望都是與員工賬務(wù) 服務(wù)這個特定的業(yè)務(wù)目標(biāo)有關(guān)的，所以可以作為業(yè)務(wù)用例被納入到員工賬務(wù)服務(wù)邊界之中。 如果假設(shè)員工也可以參與管理賬務(wù)信息，那么得出的員工對系統(tǒng)的期望就不止這兩個，但是 分析的時候要注意與員工賬務(wù)服務(wù)這一業(yè)務(wù)目標(biāo)相關(guān)的期望只有申請報銷業(yè)務(wù)和申請借款 業(yè)務(wù)兩個，其他的期望是與管理賬務(wù)信息這個業(yè)務(wù)目標(biāo)有關(guān)，應(yīng)當(dāng)被劃分到管理賬務(wù)信息邊 界中去。有的人可能會問了，貌似部門經(jīng)理也有對員工賬務(wù)服務(wù)邊界有貢獻(xiàn)啊，不是有參與審核嗎， 為啥部門經(jīng)理審核賬單就不能算一個業(yè)務(wù)用例呢？之所以會出現(xiàn)這個疑惑和誤區(qū)還是因為 沒有分清楚邊界造成的。因為對于

10、員工賬務(wù)服務(wù)邊界來說，處于該邊界的之外的業(yè)務(wù)主角只 有員工，而部門經(jīng)理，公司主任，財務(wù)主任都是在這個邊界之內(nèi)的，他們的工作都只是完成 業(yè)務(wù)主角提出的業(yè)務(wù)用例的一個步驟，在這里他們作為業(yè)務(wù)工人無權(quán)提出業(yè)務(wù)用例，他們的 職責(zé)可以在繪制用例場景活動圖的時候通過泳道體現(xiàn)出來。接下來是建立業(yè)務(wù)模型階段，建立業(yè)務(wù)模型的目的是為了通過UML這種對象語言將現(xiàn)實世 界描述出來，是我們?yōu)榱死斫饪蛻舻臉I(yè)務(wù)并和客戶達(dá)成業(yè)務(wù)上的理解而建立的模型（我們的 系統(tǒng)將要面對的問題領(lǐng)域就是這個樣子），它不需要考慮計算機(jī)環(huán)境，相對于系統(tǒng)模型來說， 他沒有加入計算機(jī)元素，是對現(xiàn)實業(yè)務(wù)的一種直觀的理解。我們平時開發(fā)時接觸的軟件需 求規(guī)

11、格說明書來源于系統(tǒng)模型，他描述的是軟件系統(tǒng)要實現(xiàn)的功能范圍，和計算機(jī)環(huán)境密 切相關(guān)，軟件需求只是整個需求過程的一部分，可以從業(yè)務(wù)需求中推導(dǎo)出來的。業(yè)務(wù)模型主要包括業(yè)務(wù)用例，業(yè)務(wù)用例實現(xiàn)場景，業(yè)務(wù)規(guī)則，業(yè)務(wù)用例規(guī)約等等，限于 個人掌握程度及個人精力所限，本案例中我主要講述業(yè)務(wù)用例和業(yè)務(wù)用例場景圖，業(yè)務(wù)用例場景主要是描述業(yè)務(wù)用例的執(zhí)行過程，一般通過活動圖中的泳道來繪制，這里以“申請報銷” 用例來說明：卬通過IJ取1卬通過IJ取1角富整止（報銷申請的業(yè)務(wù)用例場景活動圖）申誦推常其他用例的場景圖也是依樣畫葫蘆了，再搭配上業(yè)務(wù)用例規(guī)約的文字描述（用例前置條件， 后置條件，流程等等），這個報銷申請用例的描

12、述也就基本形成了，所有的業(yè)務(wù)用例如此之 后形成業(yè)務(wù)模型，然后以業(yè)務(wù)模型為基礎(chǔ)，撰寫用戶業(yè)務(wù)需求說明書。接下來要做的就是引入計算機(jī)，降低用例粒度，進(jìn)入系統(tǒng)模型的建立過程。同樣這里也是 包括系統(tǒng)用例和系統(tǒng)用例場景，系統(tǒng)用例可以從業(yè)務(wù)用例場景中推導(dǎo)出來，業(yè)務(wù)用例場景一 般描述為某某做什么，某某做什么，這個某某做什么就是一個備選的系統(tǒng)用例，然后從備選 用例中確定系統(tǒng)用例，分析過程如下：員工申請報銷，這是一個填寫報賬單的過程，是通過計算機(jī)完成的，可以直接映射成 一個系統(tǒng)用例；部門經(jīng)理審核報賬單，這是通過計算機(jī)來操作決定是否通過審核，可以直接映射成一個系 統(tǒng)用例；部門經(jīng)理說明（填寫）拒絕原因，經(jīng)過分析，這

13、個備選用例其實是審核報賬單的結(jié)果之一， 也就是說審核報賬單中包含了說明拒絕原因這個行為，所以取消部門經(jīng)理說明（填寫）拒絕 原因的獨立用例資格，將它作為部門經(jīng)理審核報賬單的包含用例。公司主任審核報賬單，公司主任說明（填寫）拒絕原因同上。財務(wù)主任發(fā)放還款，這個備選用例是否能成為系統(tǒng)用例要看情況的，如果財務(wù)主任是人為的 發(fā)放現(xiàn)金或者人為的去銀行匯款轉(zhuǎn)賬，那么沒有通過計算機(jī)（意思是該系統(tǒng)）進(jìn)行操作，就 不能算是一個系統(tǒng)用例；而如果財務(wù)主任是通過系統(tǒng)提供的轉(zhuǎn)賬功能匯款的話，那么就是一 個系統(tǒng)用例?；仡櫳姹姺治鰣蟾婧笪覀兇_定這可以成為一個系統(tǒng)用例。接下來我們繪制系統(tǒng)用例場景，看看他們是如何通過人機(jī)交互，通

14、過計算機(jī)來實現(xiàn)的，以 員工申請報銷為例子，通過泳道繪制用例場景圖：其他系統(tǒng)用例的場景圖繪制也是依樣畫葫蘆了，這里就省略了。所有系統(tǒng)用例和系統(tǒng)用例 場景圖繪制出來后，再配合相應(yīng)的用例規(guī)則，用例規(guī)約（前置條件，后置條件，流程等），那么完整的系統(tǒng)用例模型就出來了，以此為基礎(chǔ)便可以撰寫系統(tǒng)需求文檔，即軟件需求規(guī)格 說明書。到此為止，用例已經(jīng)全部找出來了，接著就是要進(jìn)入用例實現(xiàn)階段了，因為用例只是描述 了系統(tǒng)應(yīng)該做什么，是對系統(tǒng)提出的設(shè)想，用例實現(xiàn)的目的就是實現(xiàn)需求，把設(shè)想變?yōu)楝F(xiàn)實， 由于我們采用的是面向?qū)ο蟮姆椒?，所以用例實現(xiàn)的過程就是用對象之間的交互來實現(xiàn)需求 的過程。不少人到這一步，包括我自己，可

15、能直接進(jìn)入類設(shè)計，數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計了，但是經(jīng)常說 不清楚類是如何推導(dǎo)出來的，為什么是設(shè)計2個類，為什么不是3個類？美其名曰：經(jīng)驗， 哈哈，無非就是拍腦袋拍出來的咯，尤其是在業(yè)務(wù)復(fù)雜的大型項目中，這種拍腦袋出來的設(shè) 計估計要經(jīng)過反復(fù)修改才能滿足需求?，F(xiàn)在我發(fā)現(xiàn)，原來從系統(tǒng)需求到設(shè)計之間可以通過分 析模型作為過渡，通過分析模型推導(dǎo)出設(shè)計模型，推導(dǎo)出設(shè)計類。分型模型就是采用分析類（邊界類，控制類，實體類）來實現(xiàn)用例場景的一種對象模型，這個抽象層次上需求已經(jīng)通 過對象之間的交互實現(xiàn)出來了，而又不必去關(guān)注具體的技術(shù)細(xì)節(jié)，如采用什么語言，什么框 架之類的，可能安心的為需求到設(shè)計之間的跨越做一個橋梁。繪制分

16、析類圖一般需求根據(jù)用 例場景來推導(dǎo)，先一步步的分析場景中的活動：創(chuàng)建新申請報賬單：這是一條由外面發(fā)出的命令，需要用邊界對象接受它；展現(xiàn)錄入新報賬單界面：這是一個控制邏輯，需要有控制對象處理；輸入報賬單信息：這是一個人工活動，由邊界接受，報賬單是一個實體對象；提交申請：這是一條外界發(fā)出的指令，由邊界對象接受；驗證信息：這是業(yè)務(wù)規(guī)則，通過控制對象來處理；保存申請單：這是一段處理邏輯，由控制對象處理，同時，報賬單作為實體對象封裝了要 處理的數(shù)據(jù)；發(fā)送郵件通知：這是一段處理邏輯，需要由控制對象處理；顯示結(jié)果：這個是處理結(jié)果，用控制對象處理，并反映到邊界對象。根據(jù)上面的分析，接下來我繪制出員工報銷申請用

17、例實現(xiàn)的分析類時序圖：申詰報賬控制報賬里題現(xiàn)錄入界面0驗證皺據(jù)正硝性0保存報賬單0申請報賬邊界在繪制該時序圖的過程中我們得到了關(guān)鍵對象以及這些對象的方法，接下來把這些對象及 其方法繪制在一個圖里，定義出他們的關(guān)系，就得出了分析類靜態(tài)圖：返回新報賬單).申詰報賬控制報賬里題現(xiàn)錄入界面0驗證皺據(jù)正硝性0保存報賬單0申請報賬邊界在繪制該時序圖的過程中我們得到了關(guān)鍵對象以及這些對象的方法，接下來把這些對象及 其方法繪制在一個圖里，定義出他們的關(guān)系，就得出了分析類靜態(tài)圖：返回新報賬單).返回結(jié)果0新建報賬單口填寫賬單信息A保存0創(chuàng)建新胃清U報昧單+保存(.).珈訥+新建報賬單Q : void申請報賬控制

18、小保存報賬里()-.void小發(fā)送郵件通葡()Redd小返回結(jié)(3 - void+新建報賬魚():void心驗證數(shù)據(jù)正磁性枸口申請報賬邊界+創(chuàng)建新申詩0 : Void+提交申請(.):void+展現(xiàn)錄入界面(.).： Oid(這個圖其實有點小問題，就是這個矩形元素代表的是設(shè)計類而不是分析類，分析類的 形狀應(yīng)該是繪制時序圖那時候的圓形，也沒有void這個語言層次的東西，我用的建模工具 是EA，不知道的是工具不支持在分析類中繪制方法，還是我自己沒找到。反正rose中是 可以的)用分析類對象實現(xiàn)用例場景的過程就是類的推導(dǎo)過程，現(xiàn)在我們已經(jīng)得到初試的類及其方 法，雖然看上去還很粗糙，但已經(jīng)脫離了需求視

19、角，進(jìn)入系統(tǒng)設(shè)計的視角了。這些分析類就是我們進(jìn)行系統(tǒng)設(shè)計的基礎(chǔ)了，分析類結(jié)合采用的具體框架(比如SSH)， 架構(gòu)等，就可以推導(dǎo)出設(shè)計類，產(chǎn)生設(shè)計模型了。推導(dǎo)設(shè)計類的過程由于要結(jié)合具體框架，可能要實現(xiàn)某某接口，繼承某個抽象類等原因， 這里就不說了，等過段時間我再新寫一篇文章來說吧。由于我工作中的項目采用SSH框架， 所以我曾經(jīng)疑惑覺得怎么沒有看到Action類啊，Service類呢，pojo呢，DAO呢，沒看到 啊！后來才恍然醒悟，哦，原來所處的抽象層次不同，分析模型的抽象層次比設(shè)計模型高， 不涉及到具體的框架，架構(gòu)，語言等實現(xiàn)方式，所以在這個抽象層次上，可以不去考慮實現(xiàn) 細(xì)節(jié)，屏蔽掉無關(guān)的信息

20、，而專注于通過分析類的3種對象之間的交互來實現(xiàn)需求，為需 求到設(shè)計之間搭建橋梁，設(shè)計模型就是在分析模型的基礎(chǔ)上結(jié)合具體框架，架構(gòu)，語言等實 現(xiàn)方式實例化分析模型的過程。完整而全面的分析模型就可以作為系統(tǒng)概要設(shè)計文檔了。其實我個人覺得，從業(yè)務(wù)模型到設(shè)計模型（中間可能還有概念模型），到分析模型，再到 設(shè)計模型，這種建模的過程就是一個降低抽象層次和邊界粒度的過程，類似于我們要描述一 個東西，比如汽車，我們可以這樣說：站在汽車這個抽象層次上，我們看到的是車身，輪胎 等邊界；降低抽象層次到車身上，我們面對的有方向盤，發(fā)動機(jī)，座位等邊界；站在發(fā)動機(jī) 這個抽象層次上，我們看到的是引擎，活塞等邊界。這個抽象層次可以一直 延伸下去，采用這種自頂向下的方法把一個事物描述清楚。抽象層次的好處是無論站在哪個 層次上都只需要面對有限的復(fù)雜度和結(jié)構(gòu)，從而幫助我們理解清楚這個層次