UML建模方法論(下):系統(tǒng)建模
本篇文章是下面兩篇文章的后續(xù):《UML建模方法論(上):建模初期準(zhǔn)備》《UML建模方法論(中):業(yè)務(wù)建模》閱讀本篇文章前建議先閱讀上面兩篇文章。
五、系統(tǒng)建模
系統(tǒng)建模這里如果按照書中的方法同樣需要做很多的工作,包括:
- 概念用例
- 系統(tǒng)用例視圖
- 系統(tǒng)用例規(guī)約
- 補充規(guī)約
- 業(yè)務(wù)規(guī)則
- 系統(tǒng)用例實現(xiàn)
- 系統(tǒng)用例場景
- 分析對象
在這里我們還是和上面一樣,只用分析系統(tǒng)用例視圖模型和系統(tǒng)用例場景即可
5.1 系統(tǒng)用例視圖建模
什么是系統(tǒng)用例模型:
實際上,系統(tǒng)建模就是我們通常所說的需求獲取。
一般來說,系統(tǒng)二字可以省略, 所謂的系統(tǒng)用例就是我們熟悉的用例,系統(tǒng)用例模型也就是我們熟悉的用例模型。
所以這里也將省略系統(tǒng)二字, 直接使用用例模型這一叫法。
制作用例模型的作用:
1)系統(tǒng)的功能性需求完全由用例模型來表達(dá)。作為客戶方和開發(fā)方的契約,用例模型必須得到客戶的認(rèn)可。
2)用例模型從作用上講完全等同于"需求規(guī)格說明書”,它將作為合同附件來約定系統(tǒng)的開發(fā)范圍。
需求范圍不等于系統(tǒng)范圍,不是所有的需求都要在系統(tǒng)中實現(xiàn),例如那些不適合在計算機系統(tǒng)里運行的手工任務(wù):也不是所有的系統(tǒng)功能都是從需求當(dāng)中來的,例如那些系統(tǒng)管理類的功能。
3)另一方面,用例模型也是客戶理解系統(tǒng)的最重要途徑。如果客戶認(rèn)可用例模型, 開發(fā)方就可以認(rèn)為系統(tǒng)正是客戶所需要的。
如何獲取系統(tǒng)用例:
要找到系統(tǒng)用例,首先要分析業(yè)務(wù)用例場景,從業(yè)務(wù)用例場景當(dāng)中抽出那些可以在計算機當(dāng)中實現(xiàn)的單元來。
所以這里也說明了一個問題,產(chǎn)品經(jīng)理懂技術(shù)的重要性,懂技術(shù)的話,在這一個環(huán)節(jié)你可以清楚的知道哪些地方是可以由計算機來實現(xiàn)的,哪些可以轉(zhuǎn)化為系統(tǒng)用例;如果你不懂技術(shù)的話,就有可能漏掉一些可能的系統(tǒng)用例,不過好在一般情況下即使你不太懂技術(shù),大部分系統(tǒng)用例也很容易判斷出來。
業(yè)務(wù)用例場景通常被描述為某某做什么,然后某某又做什么……某某做什么就是系統(tǒng)用例的來源。
繼續(xù)分析我們的案例:
之前我們已經(jīng)繪制出了系統(tǒng)用例場景圖,接下來我們只需要從系統(tǒng)用例場景圖中找出系統(tǒng)用例即可。
簡單點說就是分析業(yè)務(wù)用例場景圖中的哪些步驟能通過計算機來代替:
上圖中紅色邊框的步驟都是可以轉(zhuǎn)換為系統(tǒng)用例的,也就是說這些步驟都可以在計算機上完成,由此我們得到系統(tǒng)用例圖:
說明:至此我們已經(jīng)推導(dǎo)出了我們需要做哪些功能,這里的每一個用例就是我們在系統(tǒng)需要去實現(xiàn)的功能,但是還沒結(jié)束,接下來是系統(tǒng)用例場景建模。
5.2 系統(tǒng)用例場景建模
和業(yè)務(wù)用例場景建模的區(qū)別:
與業(yè)務(wù)用例場景建模不同的是, 我們的視角和建模目的已經(jīng)從原來的描述業(yè)務(wù)、理解業(yè)務(wù)變成了理解系統(tǒng)、描述系統(tǒng)。這兩者的差別在于引入了計算機。
之前的描述是原來的業(yè)務(wù)是什么樣子,工作人員怎樣完成業(yè)務(wù),而現(xiàn)在的描述應(yīng)該變成計算機怎樣做, 工作人員怎樣操作計算機。
我們選取上面的“DEMO課排課”,“記錄跟進(jìn)信息”,“邀約家長試聽DEMO課”作為例子,來講解如何描述系統(tǒng)用例。
話不多說直接上圖:
DEMO課排課系統(tǒng)用例場景:
記錄跟進(jìn)信息系統(tǒng)用例場景:
邀約家長試聽DEMO課用例場景:
到了這一步我們的系統(tǒng)建模也就基本完成了,接下來只需要拿著這些系統(tǒng)用例場景圖開始畫原型就可以了
這里要注意:
業(yè)務(wù)用例場景圖就是我們經(jīng)常在說的業(yè)務(wù)流程圖,系統(tǒng)用例場景圖就是我們說的功能/任務(wù)流程圖,業(yè)務(wù)用例場景圖是用來描述業(yè)務(wù)的,系統(tǒng)用例場景圖是用來描述這個功能如何滿足用戶需求的,所以業(yè)務(wù)流程圖一定是不會包含計算機這個泳道的,而系統(tǒng)用例場景圖一定要包含計算機這個泳道。
六、結(jié)尾
到這里我們的整個建模方法論也就講完了,不知道大家現(xiàn)在對下面這些問題是否有一個比較清晰的答案了
- 為什么說做B端產(chǎn)品對于業(yè)務(wù)的理解非常重要?
- B端產(chǎn)品的功能是如何從業(yè)務(wù)出發(fā)一步一步推導(dǎo)出來的?
- 業(yè)務(wù)流程圖,任務(wù)/功能流程圖到底有什么區(qū)別?
再問大家一個問題:
產(chǎn)品經(jīng)理和交互設(shè)計師的工作界限在哪里,哪些工作是產(chǎn)品經(jīng)理做的,哪些工作是交互設(shè)計師做的?
說下我的理解哈,其實產(chǎn)品經(jīng)理只要把系統(tǒng)用例場景或者說/功能任務(wù)流程圖做出來,再把每個頁面必須要包含的信息給出來,接下來至于長什么樣就可以交給交互設(shè)計師發(fā)揮了。
如果有在深圳工作的產(chǎn)品小伙伴或者平時喜歡看書,學(xué)習(xí)和交流的小伙伴們可以加我微信哦~
作者:一點優(yōu)秀,坐標(biāo)深圳,教育行業(yè)產(chǎn)品經(jīng)理,微信號:gentleman52520,歡迎交流;
本文由 @一點優(yōu)秀 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議
很棒,謝謝分享
拜讀完作者這3篇文章,感覺作者對業(yè)務(wù)建模理解到位。想問下文中提到的如系統(tǒng)建模包含:概念用例、系統(tǒng)用例視圖、系統(tǒng)用例規(guī)約、補充規(guī)約、業(yè)務(wù)規(guī)則、系統(tǒng)用例實現(xiàn)、系統(tǒng)用例場景、分析對象,作者有沒比較好的推薦閱讀?
最后一段話是精髓。產(chǎn)品真的不是畫圖員。
說的很清晰,感謝分享!
寫的真的不錯!
這篇文章寫得非常不錯,給你點個贊
感覺文章好繞,想業(yè)務(wù)視圖和系統(tǒng)視圖有啥區(qū)別 ?
業(yè)務(wù)視圖里可包含不在系統(tǒng)實現(xiàn)的步驟
業(yè)務(wù)視圖是幫助你理解業(yè)務(wù)的,系統(tǒng)視圖是幫助你做功能設(shè)計的
棒棒噠,看書只能了解概念,得有個實際的應(yīng)用例子才能明白,謝謝
think in uml
寫的不錯 ??