在面向?qū)ο蟮男枨蠓治龇椒ㄖ校琔ML的地位是不容動搖的。
在和很多做產(chǎn)品做需求的小伙伴聊過后發(fā)現(xiàn)大家對UML的了解非常的少，在之前組織的需求分析實戰(zhàn)中也發(fā)現(xiàn)了這一點。
反而對程序員GG來說，UML的普及率會更高一些。
有的人會說，我不用UML，需求分析的也挺好的啊，產(chǎn)品做的也沒什么問題啊。
如果你正面臨著下面這些問題，我建議你看一下這篇文，并且學(xué)習(xí)并應(yīng)用UML。
- 我對自己的產(chǎn)品功能了如指掌，但是卻無法總結(jié)出所有的系統(tǒng)角色特征
- 測試寫的用例我提不出意見，但是測試結(jié)束后我卻經(jīng)常發(fā)現(xiàn)之前沒有想到過的用例
- 在做原型及需求文檔時，有時候會遺漏某個功能或者場景
- 與程序猿經(jīng)常無法溝通，我覺得自己寫的文檔、畫的原型已經(jīng)很清晰了，但是他們就是看不懂
- 我完全不知道產(chǎn)品中的業(yè)務(wù)主流程在執(zhí)行的過程中會有哪些對象參與
什么是UML？
統(tǒng)一建模語言（UML，UnifiedModelingLanguage）是面向?qū)ο筌浖臉?biāo)準(zhǔn)化建模語言。UML因其簡單、統(tǒng)一的特點，而且能表達(dá)軟件設(shè)計中的動態(tài)和靜態(tài)信息，目前已成為可視化建模語言的工業(yè)標(biāo)準(zhǔn)。在軟件無線電系統(tǒng)的開發(fā)過程中，統(tǒng)一建模語言可以在整個設(shè)計周期中使用，幫助設(shè)計者縮短設(shè)計時間，減少改進(jìn)的成本，使軟硬件分割最優(yōu)。
簡而言之就是一種語言，一種規(guī)范。
就好像音樂用五線譜、簡譜表達(dá)，數(shù)學(xué)用公式表達(dá)，需求模型用UML來表達(dá)。
曾經(jīng)有的人希望在需求階段將UML做的很規(guī)范，并可以由此直接生成代碼。就像現(xiàn)在的原型可以直接生成頁面代碼一樣。
現(xiàn)在已經(jīng)有很多工具可以做到這些了，雖然生成的代碼不是那么的讓人滿意。
但是不排除未來掌握UML和業(yè)務(wù)的人員直接跳過程序員編寫軟件產(chǎn)品。
UML帶給需求分析什么？
以小婧使用UML的經(jīng)驗來看，UML會給需求分析及需求相關(guān)人員提供更清晰、明確的目標(biāo)。
我經(jīng)常說，用UML重點是要充分應(yīng)用它面向?qū)ο蟮姆治龇椒ā?br> 也就是在做業(yè)務(wù)分析的時候，將信息抽象成對象進(jìn)行分析，可以使得自己避開“干擾”信息，抓住“主線”。
你會對你的解決方案更加有信心，知道哪些地方存在改善的空間，會給用戶帶來什么價值。
如果發(fā)生需求變更，你也會很清晰的識別出影響點。
你設(shè)計出來的產(chǎn)品和業(yè)務(wù)流程會更加連貫、合理、有邏輯性，模塊及功能之間的耦合關(guān)聯(lián)也非常清晰。
就好像你看蜘蛛網(wǎng)仿佛毫無章法，但是仔細(xì)看來卻是一件完美的藝術(shù)品。
UML適用于哪些階段？
我們從UML的定義也可以看出，UML主要是服務(wù)于設(shè)計的。在需求分析階段，我們?nèi)绻芎芎玫氖褂肬ML，將會為代碼設(shè)計提供很好的支持。
UMLChina在《軟件方法》一書中提出了一個概念叫核心工作流。使用核心工作流可實現(xiàn)“低成本制造好賣的產(chǎn)品”。
1 業(yè)務(wù)建?！M織要解決什么問題
做產(chǎn)品需求的人都知道，我們需要去找甲方的痛點也就是問題，如果我們的產(chǎn)品可以很好的解決問題，那么人家就愿意付錢，我們就能盈利。
而你的產(chǎn)品能帶給用戶什么價值，這個價值到底是否足夠大到吸引用戶來付費。你可以通過業(yè)務(wù)建模來進(jìn)行分析。要知道引進(jìn)一個軟件系統(tǒng)，和招聘一名新員工沒有本質(zhì)的區(qū)別。我以前經(jīng)常會被challenge的問題是：我為什么要買你們的系統(tǒng)，我用Excel也管的挺好的。
業(yè)務(wù)建模階段思考的焦點是：組織內(nèi)系統(tǒng)之間
推薦UML元素：用例圖、類圖、序列圖
2需求——為了解決組織的問題，待開發(fā)系統(tǒng)應(yīng)該提供什么功能和性能
這里強迫我們從“賣”的角度思考哪些是干系人在意的，哪些不是。
需求階段思考的焦點是：系統(tǒng)邊界
推薦的UML元素：用例圖、文本
3分析——為了提供功能，系統(tǒng)內(nèi)部應(yīng)該有什么樣的核心機制
在用戶的整個業(yè)務(wù)流程中，你的產(chǎn)品是在哪個部分起什么作用的。大部分的軟件產(chǎn)品的作用就是取代人工，實現(xiàn)自動化。以前我們?nèi)ゲ宛^點菜需要服務(wù)員拿個小單子來寫你點了哪些菜，或者直接人腦記憶；付款的時候，老板要收集小單子或者記錄在小本子上，以便休息的時候計算營業(yè)額。但是現(xiàn)在我們?nèi)コ燥垼苯右粋€IPAD，菜單、點菜、消費記錄全部自動化。裝在IPAD里的系統(tǒng)是通過分析得到的。
在分解階段思考的焦點是：系統(tǒng)內(nèi)核心域
推薦的UML元素：類圖、序列圖、狀態(tài)機圖
4設(shè)計——試了提供性能，系統(tǒng)的核心機制如何選定技術(shù)實現(xiàn)
主要聚焦：系統(tǒng)內(nèi)各域之間
UML：不畫，代碼即設(shè)計
從上面幾個階段我們可以看出，對于我們產(chǎn)品需求人員需要掌握的UML其實只有那么幾種：用例圖、序列圖、類圖、狀態(tài)圖。
有人會問，為什么沒有活動圖（流程圖）？
我覺得如果你和用戶或者業(yè)務(wù)人員溝通，可以使用活動圖、但是如果你是為研發(fā)、設(shè)計服務(wù)，建議使用序列圖。因為序列圖會強迫你去思考所有的動作背后的目的。
怎么畫UML？
關(guān)于各種圖的具體畫法我覺得大家去問度娘會得到比我這有限篇幅更詳細(xì)的信息。
而針對用例圖，我最近看到一種說法，覺得很有意思，在本文中做一個分享。
潘加宇老師在《軟件方法》中提到了兩種用例圖：業(yè)務(wù)用例圖和系統(tǒng)用例圖。
之前有小伙伴說，測試和開發(fā)看不懂他畫的用例圖，很苦惱。我仔細(xì)看了下，確實是有些表述不清。因為他把業(yè)務(wù)用例圖和系統(tǒng)用例圖弄在一起了。
業(yè)務(wù)用例圖
業(yè)務(wù)用例圖主要是用在業(yè)務(wù)建模的階段，目的是從甲方的角度來定位系統(tǒng)應(yīng)該提供的價值。
所以業(yè)務(wù)用例圖研究的對象是甲方組織。甲方的組織里面包括哪些角色，哪些軟件系統(tǒng)，哪些部門？而我們的系統(tǒng)將承擔(dān)這些對象中的哪些對象的大部分職責(zé)？
另外一方面，業(yè)務(wù)用例圖的Actor執(zhí)行者是業(yè)務(wù)執(zhí)行者，即組織外與組織交互的人群或組織。
比如你的甲方是某商業(yè)銀行，其Actor是儲戶、企業(yè)用戶、人民銀行。研究的是他們將會與商業(yè)銀行產(chǎn)品什么用例。
系統(tǒng)用例圖
系統(tǒng)用例圖主要使用在需求階段，我們其實最常用的是系統(tǒng)用例圖。系統(tǒng)用例圖的主要研究對象是系統(tǒng)，也就是我們待開發(fā)的軟件系統(tǒng)。
系統(tǒng)用例圖的執(zhí)行者是在系統(tǒng)外與系統(tǒng)發(fā)生功能性交互的其他系統(tǒng)。所以重點在于這個執(zhí)行者與系統(tǒng)發(fā)生功能性交互。
比如前些日子小婧的身份證過期了去辦身份證（我又暴露年齡了）。身份證辦理系統(tǒng)的執(zhí)行者包括：辦證人員、數(shù)碼相機、指紋采集儀。這里要注意的是我并不是系統(tǒng)的執(zhí)行者，至少在這個非自助的系統(tǒng)中，我不是。
寫在最后
在實際的產(chǎn)品需求分析過程中使用UML，不論對你的產(chǎn)品還是你自己而言都會收益頗多。
但是和所有的方法一樣，在學(xué)習(xí)和實踐一種新的方法時會面臨很多的挑戰(zhàn)，也會有很多的問題。
單純就從UML的角度來說，我覺得有這樣幾個方法可以來學(xué)習(xí)實踐：
- 對自己產(chǎn)品進(jìn)行梳理，嘗試用UML的用例圖、序列圖（時序圖）繪制現(xiàn)有系統(tǒng)業(yè)務(wù)，并與開發(fā)人員討論。通常來說，開發(fā)對UML的了解會更深入，這可能是和現(xiàn)在常見的開發(fā)語言，比如C系列、Java等也是面向?qū)ο蟮恼Z言有關(guān)。
- 度娘UML的繪制方法?，F(xiàn)在很多文章和博客都介紹的很詳細(xì)。
- 通過閱讀一些比較經(jīng)典的UML書籍。
- 歡迎和小婧進(jìn)行溝通交流。
小婧是一名行走在產(chǎn)品路上的資深業(yè)務(wù)分析師（BA），如果想與我同行，就請關(guān)注我吧！
