面向?qū)ο蠓治鲞^程案例實(shí)戰(zhàn)

1、面向?qū)ο蠓治鲞^程案例實(shí)戰(zhàn)2010/08/15/5813667.aspx這是我在csdn博客的第2篇技術(shù)文章，本來按原計(jì)劃是要介紹開源ajax框架buffalo的第2部分，即js<>java的序列化，這里面涉及不少設(shè)計(jì)模式的運(yùn)用和JAVA SE知識(shí)，代碼精簡，比較精彩。但是由于個(gè)人時(shí)間有限，在抉擇之后，打算先寫一篇關(guān)于面向?qū)ο蠓治龅奈恼?，也算是?duì)自己過去1年多在這方面學(xué)習(xí)的總結(jié)。我選了比較簡單且大家也比較熟悉的案例來分析，案例雖然簡單，但是基本的分析方法和推導(dǎo)過程還是一致的，我主要想講的是原始需求是怎么通過層層分析和推導(dǎo)而形成最后可執(zhí)行代碼的，限于自己的個(gè)人能力，如果有謬論和錯(cuò)誤之處

2、，還望同行多指教和幫助，共同進(jìn)步。原始需求描述如下：某公司鑒于業(yè)務(wù)和員工的快速發(fā)展，為了提升整體工作效率，公司準(zhǔn)備開發(fā)一套員工報(bào)賬系統(tǒng)，取代原來的人工處理方式，更加方便的服務(wù)于員工日常的賬務(wù)操作。財(cái)務(wù)部門能夠通過賬務(wù)系統(tǒng)定期向各部門負(fù)責(zé)人反映賬務(wù)統(tǒng)計(jì)情況，并設(shè)置和維護(hù)相關(guān)額度準(zhǔn)則。系統(tǒng)應(yīng)該具有基于先進(jìn)技術(shù)的操作界面。這段描述里包含的業(yè)務(wù)目標(biāo)大致有二：1.為員工提供賬務(wù)的自動(dòng)化辦理，提高辦事效率，方便員工。2.方便財(cái)務(wù)部門管理好賬務(wù)信息。這些業(yè)務(wù)目標(biāo)一般在項(xiàng)目的招標(biāo)書里都有相關(guān)的描述，也可以由開發(fā)方整理得出。之所以這里要把業(yè)務(wù)目標(biāo)列出來，是因?yàn)槲宜扇〉姆椒ɡ?，業(yè)務(wù)目標(biāo)是進(jìn)行需求分析的第一步，接

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

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

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

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

7、堂的目的就是就餐，就餐才是我的完整目標(biāo)，而其他諸如領(lǐng)取餐具，點(diǎn)菜，刷卡付款之類的都不是我去食堂的目的，這些只是我完成就餐的步驟而已，但如果把邊界粒度降低到食堂的內(nèi)部，那么這個(gè)時(shí)候領(lǐng)取餐具，刷卡付款之類的也是一個(gè)用例了，雖然都是用例，但是和就餐這個(gè)用例的粒度是不同的，因?yàn)樗麄冞吔缢诘某橄髮哟尾煌?。所以要描述用例就必須先劃分出邊界來，主角站在邊界外?duì)這個(gè)邊界提出目標(biāo)，一個(gè)目標(biāo)就是一個(gè)用例，否則在描述系統(tǒng)的時(shí)候就會(huì)出現(xiàn)如我去食堂的目的是刷卡付款這樣的笑話來，當(dāng)然了，除非我去食堂的目的真的只是為了付款。 回到本文的案例中來，開始進(jìn)行獲取業(yè)務(wù)用例的分析，剛才說了，要獲取用例必須先確定好邊界，那么怎么確

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

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

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

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

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

13、審核報(bào)賬單中包含了說明拒絕原因這個(gè)行為，所以取消部門經(jīng)理說明（填寫）拒絕原因的獨(dú)立用例資格，將它作為部門經(jīng)理審核報(bào)賬單的包含用例。公司主任審核報(bào)賬單，公司主任說明（填寫）拒絕原因 同上。財(cái)務(wù)主任發(fā)放還款，這個(gè)備選用例是否能成為系統(tǒng)用例要看情況的，如果財(cái)務(wù)主任是人為的發(fā)放現(xiàn)金或者人為的去銀行匯款轉(zhuǎn)賬，那么沒有通過計(jì)算機(jī)（意思是該系統(tǒng)）進(jìn)行操作，就不能算是一個(gè)系統(tǒng)用例；而如果財(cái)務(wù)主任是通過系統(tǒng)提供的轉(zhuǎn)賬功能匯款的話，那么就是一個(gè)系統(tǒng)用例。回顧涉眾分析報(bào)告后我們確定這可以成為一個(gè)系統(tǒng)用例。接下來我們繪制系統(tǒng)用例場(chǎng)景，看看他們是如何通過人機(jī)交互，通過計(jì)算機(jī)來實(shí)現(xiàn)的，以員工申請(qǐng)報(bào)銷為例子，通過泳道繪制用

14、例場(chǎng)景圖：其他系統(tǒng)用例的場(chǎng)景圖繪制也是依樣畫葫蘆了，這里就省略了。所有系統(tǒng)用例和系統(tǒng)用例場(chǎng)景圖繪制出來后，再配合相應(yīng)的用例規(guī)則，用例規(guī)約（前置條件，后置條件，流程等），那么完整的系統(tǒng)用例模型就出來了，以此為基礎(chǔ)便可以撰寫系統(tǒng)需求文檔，即軟件需求規(guī)格說明書。到此為止，用例已經(jīng)全部找出來了，接著就是要進(jìn)入用例實(shí)現(xiàn)階段了，因?yàn)橛美皇敲枋隽讼到y(tǒng)應(yīng)該做什么，是對(duì)系統(tǒng)提出的設(shè)想，用例實(shí)現(xiàn)的目的就是實(shí)現(xiàn)需求，把設(shè)想變?yōu)楝F(xiàn)實(shí)，由于我們采用的是面向?qū)ο蟮姆椒?，所以用例?shí)現(xiàn)的過程就是用對(duì)象之間的交互來實(shí)現(xiàn)需求的過程。不少人到這一步，包括我自己，可能直接進(jìn)入類設(shè)計(jì)，數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計(jì)了，但是經(jīng)常說不清楚類是如何推導(dǎo)

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

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

17、以及這些對(duì)象的方法，接下來把這些對(duì)象及其方法繪制在一個(gè)圖里，定義出他們的關(guān)系，就得出了分析類靜態(tài)圖：（這個(gè)圖其實(shí)有點(diǎn)小問題，就是這個(gè)矩形元素代表的是設(shè)計(jì)類而不是分析類，分析類的形狀應(yīng)該是繪制時(shí)序圖那時(shí)候的圓形，也沒有 void 這個(gè)語言層次的東西，我用的建模工具是 EA ，不知道的是工具不支持在分析類中繪制方法，還是我自己沒找到。反正 rose 中是可以的）用分析類對(duì)象實(shí)現(xiàn)用例場(chǎng)景的過程就是類的推導(dǎo)過程，現(xiàn)在我們已經(jīng)得到初試的類及其方法，雖然看上去還很粗糙，但已經(jīng)脫離了需求視角，進(jìn)入系統(tǒng)設(shè)計(jì)的視角了。這些分析類就是我們進(jìn)行系統(tǒng)設(shè)計(jì)的基礎(chǔ)了，分析類結(jié)合采用的具體框架（比如SSH），架構(gòu)等，就可以

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

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