這是我在csdn博客的第2篇技術(shù)文章,本來按原計劃是要介紹開源ajax框架buffalo的第2部分,即js<>java的序列化,這里面涉及不少設(shè)計模式的運用和JAVA SE知識,代碼精簡,比較精彩。但是由于個人時間有限,在抉擇之后,打算先寫一篇關(guān)于面向?qū)ο?/strong>分析的文章,也算是對自己過去1年多在這方面學習的總結(jié)。我選了比較簡單且大家也比較熟悉的案例來分析,案例雖然簡單,但是基本的分析方法和推導過程還是一致的,我主要想講的是原始需求是怎么通過層層分析和推導而形成最后可執(zhí)行代碼的,限于自己的個人能力,如果有謬論和錯誤之處,還望同行多指教和幫助,共同進步。
原始需求描述如下:某公司鑒于業(yè)務和員工的快速發(fā)展,為了提升整體工作效率,公司準備開發(fā)一套員工報賬系統(tǒng),取代原來的人工處理方式,更加方便的服務于員工日常的賬務操作。財務部門能夠通過賬務系統(tǒng)定期向各部門負責人反映賬務統(tǒng)計情況,并設(shè)置和維護相關(guān)額度準則。系統(tǒng)應該具有基于先進技術(shù)的操作界面。
這段描述里包含的業(yè)務目標大致有二:
1.為員工提供賬務的自動化辦理,提高辦事效率,方便員工。
2.方便財務部門管理好賬務信息。
這些業(yè)務目標一般在項目的招標書里都有相關(guān)的描述,也可以由開發(fā)方整理得出。之所以這里要把業(yè)務目標列出來,是因為我所采取的方法里,業(yè)務目標是進行需求分析的第一步,接下來的推導過程和業(yè)務模型的建立都是根據(jù)業(yè)務目標開始的。
整理出了業(yè)務目標后,接下來先不要一頭扎進具體的業(yè)務流程和業(yè)務細節(jié)之中去,應該先把涉眾找出來,整理出一份涉眾分析報告,涉眾就是和這個項目相關(guān)的人。也不要就去考慮技術(shù)實現(xiàn)細節(jié),要用什么先進的技術(shù),界面如何美觀,性能如何優(yōu)越等等,雖然這些確實重要,但是相比起來,忠實的實現(xiàn)涉眾的期望,滿足涉眾的需求才是最為重要,也是一個項目成敗的關(guān)鍵。在實際的項目中,我們可以通過需求調(diào)研找出相關(guān)的涉眾,這里我就直接列出本案例的涉眾分析報告:
員工:公司的正式錄用雇員; 期望:通過網(wǎng)上辦理賬務業(yè)務申請,計算機控制流程。
部門經(jīng)理:部門負責人,負責審核員工提交的申請;期望:方便審核操作,通過計算機代替原來的手工審核方式。
公司主任:公司負責人,負責2次審核員工提交的申請;期望:方便審核操作,通過計算機代替原來的手工審核方式,界面友好易用。
財務主任:公司財務部門負責人,負責發(fā)放報賬款項; 期望:通過計算機轉(zhuǎn)賬的方式替代原來的人為付款方式。
以上的涉眾分析報告是很簡單的了,在實際稍微復雜些的項目中要下功夫好好整理清楚一份完整的文檔才是,因為接下來的業(yè)務用例獲取工作也是在此基礎(chǔ)上展開的。
這里先羅嗦下業(yè)務用例和平時開發(fā)中的我們開發(fā)人員從項目經(jīng)理或者需求人員手中拿到的需求文檔中的用例什么區(qū)別。按我個人理解來說后者是系統(tǒng)用例,兩者的關(guān)鍵區(qū)別在于抽象層次和用例粒度的不同,系統(tǒng)用例是以人與計算機的每次交互為單位的,而業(yè)務用例則是在較高的層次上用于確立業(yè)務需求范圍和描述系統(tǒng)功能性需求的。也就是說我們在描述業(yè)務用例的時候,可以不用去考慮具體和計算機相關(guān)的實現(xiàn)步驟和細節(jié),從而降低我們?nèi)四X需要考慮的復雜度,專注于確立業(yè)務需求范圍,抽象就是面向?qū)ο蟮膬?yōu)勢所在,不用像過程化思維那樣通盤考慮,因為人腦能接受的信息量是有限的。系統(tǒng)用例一般是從業(yè)務用例中推導出來的,本文之后會有關(guān)于這方面的推導過程。
不知道有沒跑題,羅嗦了一段,現(xiàn)在回來,分析下本案例中的業(yè)務用例獲取工作。說到用例,就必須結(jié)合邊界和業(yè)務主角,否則用例的粒度就會出現(xiàn)問題,因為用例是以參與者(業(yè)務主角)為核心的,是由業(yè)務主角發(fā)起的以達到業(yè)務主角完整目標為標準的。要獲取用例就必須先得出邊界,邊界有了,那么邊界外的業(yè)務主角就有了,那么業(yè)務主角對這個邊界內(nèi)的目標就是用例了。用 UML 表示如下:
出處:CSDN
責任編輯:bluehearts
上一頁 下一頁 面向?qū)ο蠓治鲞^程案例實戰(zhàn) [2]
◎進入論壇網(wǎng)絡編程版塊參加討論
|