轉(zhuǎn)載來自： https://bit-kaki.blog.csdn.net/article/details/80067462

最近終于把《大象》這本書讀完了，從去年11月到現(xiàn)在涎永，用了整整五個月妈倔。
一方面是因為這段時間工作上的事情贬堵，生活上的事情都比較多松忍，很少有整塊時間閱讀宏所；

讀完最后的感覺仿佛自己打通了任督二脈，很多以前工作上的問題一下子茅塞頓開。
一個系統(tǒng)從零到一，以前知道大概怎么做，現(xiàn)在總算明白一些為什么這么做以及使用UML的好處是什么？
雖然書中有部分內(nèi)容自己并不完全贊同咨跌，但這本書整體的思想上給了我很大的啟發(fā)沪么。

總的來說硼婿，拋開具體的工具和概念，我覺得這本書給了我以下幾點啟示：
1.UML是一種語言
語言是用來溝通的主要方式，包含了單詞和語法
UML 的單詞就是各種元素、視圖和模型，語法就是建模的方法
語言最基本的功能是能清楚地表達和傳遞信息
UML最基本的就是通過模型將需要做的系統(tǒng)清楚表示出來

2.UML采用的是面向?qū)ο蟮姆椒?br> 面向?qū)ο笫且环N認知世界的方法冀偶，在面向?qū)ο蠓椒ɡ铮磺杏忻值臇|西都是對象
對象和對象之間彼此獨立，只有在某個特定場景下欺劳，它們的某一個特定實例才相互聯(lián)系在一起
每個對象都是一個整體淡诗，內(nèi)部不可分割哄辣，外部只能通過邊界和其他對象對接
對象參與每個場景時都會展現(xiàn)其某一個方面性質(zhì)杉编，這方面性質(zhì)都可以抽象出來

3.建模的實質(zhì)是將現(xiàn)實世界抽象為模型
同樣的事物在不同的世界觀的人眼里會產(chǎn)生不同的結果，而這個世界觀在建模里對應的是抽象角度
一旦決定了抽象角度倘零，就確定了一個目標
一個由抽象角度確定了的目標需要由靜態(tài)事物加上特定條件下產(chǎn)生的一個特定場景來完成，即靜態(tài)的事情（物）+特定的條件（規(guī)則）+特定的動作（參與者的驅(qū)動）=特定的場景（事件）
建模其實也就是由人+事+物+規(guī)則霉晕，將現(xiàn)實世界抽象為模型

4.項目的啟動
項目的啟動首先源自“老大”的愿景，在老大看來，為什么要開發(fā)這個系統(tǒng)
然后是進行涉眾分析掌猛，誰關心這個系統(tǒng)丐黄？會涉及到他的什么利益接校？
再次是投入，愿意花多少錢杜顺，允許多少時間？
最后是風險峭火，比如客戶參與少；沒有度量方式为鳄；技術風險俊扭；重要人物反對姐仅；以前曾被取消過……

5.客戶訪談技巧
一般來說系統(tǒng)分析員是計算機專家行冰，習慣于從計算機角度來看問題录别；客戶是業(yè)務專家盈咳，習慣身邊的人也熟悉這個業(yè)務領域。
所以系統(tǒng)分析員需要改變自己的立場，了解業(yè)務是什么茄螃，還要弄清業(yè)務為什么。
首先捻勉，應該有一個詳細的涉眾分析報告，循序漸進地從接觸到深入了解客戶脑融；
其次狰挡，不要急于深入業(yè)務細節(jié)耀态，而是先就一些大框框進行溝通姑廉，借此習慣和了解對方的溝通方式；
再次，雙方的時間是有限的，因此每一次會面都需要爭分奪秒，用最快的時間把問題搞清楚；
最后，系統(tǒng)分析員需要承擔每次會談結果記錄，并且需要正式的反饋和確認远寸，以便之后和客戶在需求變更時候有依據(jù)女器。

6.需求獲取
在對每個業(yè)務進行需求調(diào)研時候首先要明確該業(yè)務的邊界惕艳，每個邊界的劃分則指明了需求分析的起點
找到業(yè)務主角涮因，訪談業(yè)務主角或者從業(yè)務主角的角度來看與系統(tǒng)的交互今瀑，就可以得到業(yè)務用例
根據(jù)業(yè)務用例用合適的視圖表達出來就構建除了業(yè)務模型
業(yè)務建模常見的視圖有兩種：活動圖和時序圖
活動圖中活動是主要的內(nèi)容，表達的內(nèi)容是業(yè)務主角或業(yè)務工人做什么；時序圖中棍矛，消息是主要的內(nèi)容季蚂，表達的內(nèi)容是業(yè)務主角或業(yè)務工人之間傳遞的是什么

7.需求分析
需求分析首先要找到關鍵概念践宴，關鍵概念是指支撐起客戶整個業(yè)務架構的那條主線锦溪，在UML方法里，就是由一些關鍵的業(yè)務用例構成
根據(jù)各個關鍵概念平道，梳理出相關的概念用例悦冀，獲取概念模型
每個概念模型表示一個功能要出，各個概念模型之間通過軟件架構聯(lián)系起來
從概念模型入手，根據(jù)找到業(yè)務主線找到每個大的業(yè)務構件，再通過領域模型分解為小的構件,再根據(jù)概念模型找到各個小的構件之間的依賴關系。
如此就得到了項目的業(yè)務架構

8.系統(tǒng)分析和設計
將每個業(yè)務模型抽象為描述系統(tǒng)的模型痹雅，就得到了系統(tǒng)模型
業(yè)務用例抽象為系統(tǒng)用例的基本方法有：映射货岭、抽象、合并、拆分、演繹等
系統(tǒng)分析的成果是獲取到系統(tǒng)的每個分析類，這些分析類基本上可以分為實體、邊界、控制三類眯停，和開發(fā)中的MVC正好對應
將分析類的成果考慮具體實現(xiàn)語言和實現(xiàn)方式族操，也就是系統(tǒng)設計，得到的成果就是開發(fā)中可直接用的類鸠蚪、包和接口

9.理論和實際
《大象》這本書盡管作者舉了很多生動的例子，畫了大量的圖滋迈，但整體來說是依然是非常枯燥的
對于書中理論欠雌，抽象程度都比較高但骨，專業(yè)的詞匯也比較多，所以看下去真的很難
不過UML作為目前可視化建模語言的工業(yè)標準赠摇，其本身也源于面向?qū)ο蠓治龊驮O計的方法
目的就是為了更清晰肌割、簡單的表達軟件設計中的動態(tài)和靜態(tài)信息
所以如果能結果實際項目來看會往往覺得豁然開朗的感覺卧蜓，但強行去從概念理解往往會讓自己更懵
另外我覺得uml的學習最大的成果是有這樣一種思維方式，如何分析和設計一個系統(tǒng)
但真正在無比推崇“敏捷開發(fā)”的現(xiàn)在把敞，我覺得uml很多時候還不如一個高真的axure更能傳遞清楚軟件設計的信息

（一）為什么需要UML弥奸？

一、UML的定義

UML,即Unified Modeling Language又稱統(tǒng)一建模語言或標準建模語言奋早，是始于1997年一個OMG（對象管理組織）標準盛霎，它是一個支持模型化和軟件系統(tǒng)開發(fā)的圖形化語言，為軟件開發(fā)的所有階段提供模型化和可視化支持耽装，包括由需求分析到規(guī)格愤炸，到構造和配置。

UML是一種是面向?qū)ο筌浖臉藴驶ＵZ言掉奄，要弄清UML规个，首先得搞清楚面向?qū)ο蠛兔嫦蜻^程。

二姓建、面向?qū)ο蠛兔嫦蜻^程

面向?qū)ο蠛兔嫦蜻^程是兩種不同描述世界的方法诞仓。

面向過程：世界視為過程，世界由一個個相互關聯(lián)的小程序構建來的引瀑。但是構成一個系統(tǒng)的因素太多狂芋，要把所有可能的因素都考慮到，把所有因素的因果分析都分析清楚憨栽，再把這個過程模擬出來實在是太困難了帜矾。

面向?qū)ο螅菏澜缫暈閷ο螅澜缬梢粋€個相互獨立屑柔、相互之間沒有因果關系的對象構成屡萤。但是難點在于為什么這樣抽象對象？怎樣組合對象掸宛？對象的組合表達了怎樣的含義死陆？

以知乎上的一個例子來區(qū)分面向過程和面向?qū)ο螅?/p>

面向過程：
為了把大象裝進冰箱，需要3個過程。
1) 把冰箱門打開（得到打開門的冰箱）
2) 把大象裝進去（打開門后措译，得到里面裝著大象的冰箱）
3) 把冰箱門關上（打開門别凤、裝好大象后，獲得關好門的冰箱）

每個過程有一個階段性的目標领虹，依次完成這些過程规哪，就能把大象裝進冰箱：
冰箱開門(冰箱)
冰箱裝進(冰箱, 大象)
冰箱關門(冰箱)

面向?qū)ο螅?br> 為了把大象裝進冰箱，需要做三個動作（或者叫行為）塌衰。
每個動作有一個執(zhí)行者诉稍，它就是對象。
1) 冰箱最疆，你給我把門打開
2) 冰箱杯巨，你給我把大象裝進去（或者說，大象努酸，你給我鉆到冰箱里去）
3) 冰箱服爷，你給我把門關上

依次做這些動作矾端，就能把大象裝進冰箱：
冰箱.開門()
冰箱.裝進(大象)
冰箱.關門()

三晤碘、面向?qū)ο蟮睦щy

面向?qū)ο笫前咽澜缈醋魇怯稍S多對象組成的，然而現(xiàn)實世界和對象世界之間存在著一道溝壑都办，這道溝壑的名字叫抽象烙荷，抽象是面向?qū)ο蟮木杷冢瑫r也是面向?qū)ο蟮睦щy所在檬寂。要跨越這道溝壑终抽，我們需要：

一種把現(xiàn)實世界映射到對象世界的方法；
一種從對象世描述現(xiàn)實世界的方法桶至；
一種驗證對象世界行為是否正確反映了現(xiàn)實世界的方法昼伴。

而UML就是跨越這道溝壑的方法。

四镣屹、UML的特點

UML是一種建模用的語言圃郊，就是一種建模用的語言，包含模型和關系女蜈，類似于語言中的基本詞匯和語法持舆。

UML的特點是統(tǒng)一，形成一種標準讓人和機器都能讀懂伪窖。

UML的優(yōu)點是可視化逸寓，通過原模型和表示法，更加準確直觀表達出文字難以表達的內(nèi)容覆山。

五竹伸、從現(xiàn)實世界到業(yè)務模型

建模是對客觀事物建立一種抽象方法，用來表征事物以及對事物本身的理解簇宽。

知道如何抽象現(xiàn)實世界:人勋篓、事吧享、物、規(guī)則譬嚣，人驅(qū)動系統(tǒng)钢颂、事體現(xiàn)過程、物記錄結果孤荣、規(guī)則是控制甸陌；

在UML里：參與者（actor）代表人，用例（use case）代表事盐股，業(yè)務對象模型（business object model）代表物钱豁，業(yè)務場景（business scenario）代表規(guī)則。

image

六疯汁、從業(yè)務模型到概念模型

UML通過稱之為概念化的過程（Conceptual）來建立適合計算器理解和實現(xiàn)的模型牲尺，這個模型成為分析模型（Analysis Mode）。

原模型包含：邊界類幌蚊、實體類谤碳、控制類。

邊界類類似于系統(tǒng)中的界面溢豆，決定操作能不能做蜒简，代表了事；
實體類由領域模型轉(zhuǎn)化而來漩仙，重新表達了業(yè)務實體搓茬，代表了物；

控制類表達了需求中的動態(tài)信息队他，體現(xiàn)了規(guī)則卷仑。

image

七、從概念模型到設計模型

實現(xiàn)類可以簡單地從分析類映射而來：

邊界類可以被轉(zhuǎn)化為操作界面或者系統(tǒng)接口麸折；
控制類可以被轉(zhuǎn)化為計算程序或者控制程序锡凝，例如工作流、算法題等垢啼。

實體類可以轉(zhuǎn)化為數(shù)據(jù)庫表窜锯、XML文檔等。

image

UML的三個模型的建立過程解決了面向?qū)ο蟮娜齻€困難膊夹。

image

（二）建某幕耄基礎

一、建模

建模（Modeling）放刨，是指通過對客觀事物建立一種抽象的方法用以表征事物并獲得對事物本身的理解工秩，同時把這種理解概念化，并這些邏輯概念組織起來，構成一種對所觀察的對象的內(nèi)部結構和工作原理的便于理解的表達助币。

建模主要包含兩個問題浪听，一個是怎么建？另一個是模是什么眉菱？

怎么建迹栓？

同樣的事物在不同的世界觀的人眼里會產(chǎn)生不同的結果，而這個世界觀在建模里對應的是抽象角度俭缓，抽象的角度不同決定了建模方向的不同克伊。

無論在需求分析、系統(tǒng)分析還是系統(tǒng)設計上华坦，要采用面向?qū)ο蟮姆椒ㄔ复担诿鎸栴}領域的時候首先不要決定去通盤考慮，而是找出問題領域里包含的抽象角度惜姐，把抽象角度找全了犁跪，并且這些角度都分析清楚了，問題領域也就解決了歹袁。

做需求的時候坷衍，首要目標不是要弄清楚業(yè)務是如何一步一步完成的，而是要弄清楚有多少業(yè)務的參與者条舔？每個參與者的目標是什么?參與者的目標就是抽象角度枫耳，也就是用例。

模是什么孟抗？

一旦決定了抽象角度嘉涌，就確定了一個目標。

一個由抽象角度確定了的目標需要由靜態(tài)事物加上特定條件下產(chǎn)生的一個特定場景來完成夸浅，即靜態(tài)的事情（物）+特定的條件（規(guī)則）+特定的動作（參與者的驅(qū)動）=特定的場景（事件）

這個就是上一章里說到認識世界的四個要素聯(lián)系起來了：人、事扔役、物帆喇、規(guī)則。

綜合以上所示亿胸，建模公式的就是：

image

二坯钦、用例驅(qū)動

從建模公式我們可以知道，要想解決問題領域就需要歸納出所有必要的用例侈玄，實現(xiàn)了這些用例婉刀，問題也就解決了。

所以為了實現(xiàn)這些用例序仙，我們就需要實現(xiàn)與之相關的分析突颊、設計、實現(xiàn)、測試律秃，這就是用例驅(qū)動爬橡。

用例具體可以驅(qū)動的具體內(nèi)容有：

邏輯視圖：建模公式中的“人”、“事”棒动、“物”糙申、“規(guī)則”是如何分類資質(zhì)的；

進程視圖：建模公式中的“人”船惨、“事”柜裸、“物”、“規(guī)則”是如何交互的粱锐，它們的關系如何疙挺；

部署視圖：建模公式中的“人”、“事”卜范、“物”衔统、“規(guī)則”是如何部署在物理節(jié)點上的；

實施視圖：建模公式中的“人”海雪、“事”锦爵、“物”、“規(guī)則”是如何構成系統(tǒng)的“零部件”奥裸，以及我們?nèi)绾谓M織人力生產(chǎn)和組裝這些“零部件”以堅持最終系統(tǒng)险掀；

用例驅(qū)動視圖為：

image

三、抽象層次

抽象層次是面向?qū)ο蠓椒ㄖ袠O其重要但又非常難以掌握的技巧湾宙，抽象層次越高樟氢，具體信息越少，概括能力越強

抽象層次是為了幫助人去更容易理解事物侠鳄，它將一部分具體的信息封裝起來用一個新的概念去替代埠啃，比如長度的單位，天所學所用的光年相對于米伟恶、公里這些常見單位來說更加抽象碴开，但說太陽系距離銀河系中心大約有27000光年就比說這個距離是255439722759681600000米更容易讓人理解

抽象有兩種方法，一種是自頂向下博秫，另一種是自底向上潦牛。

自頂向下的方法適用于讓人們從頭認識一個事物；

自底向上的方法適用于在實踐中改進和提高認識挡育。

軟件開發(fā)中巴碗，主體上應當采用自頂向下的方法，用少量的概念覆蓋系統(tǒng)需求即寒，再逐步降低抽象層次橡淆，直到代碼編寫召噩。同時應當輔以自底向上的方法，通過總結在較低抽象層次的實踐經(jīng)驗來改進較高層次的概念以提升軟件質(zhì)量明垢。

四蚣常、視圖

視圖用于組織UML元素，表達出模型的某一方面的含義痊银。

視角是人們觀察事物的角度抵蚊。

針對每個視圖來說，不同的視角展示了同樣信息的不同認知角度以便于理解溯革。

在建模里贞绳，UML里定義了用例圖、對象圖致稀、類圖冈闭、包圖、活動圖等不同的視圖抖单，不同類型的視圖表示從不同的視角描述了一個軟件的結構和組成萎攒，而所有這些視圖的集合表達了一個軟件的完整含義。

一個好的模型矛绘，需要為特定的信息選擇正確的視圖耍休，為特定的干系人展示正確的視角。

image

五货矮、對象分析方法

一切都是對象

在面向?qū)ο蠓椒ɡ镅蚓磺杏忻值臇|西都是對象，都應當使用對象的觀點來看待它囚玫。

對象都是獨立的

對象和對象之間都是天然獨立的喧锦，只有在某個特定場景下，它們的某一個特定實例才相互聯(lián)系在一起抓督。

對象都具有原子性

無論在什么時候燃少，在分析過程中都應當將對象視為一個原子，原子是個整體铃在，內(nèi)部不可分割供汛，外部通過邊界和其他對象對接。這種方式也叫做面向接口編程涌穆。

對象都是可抽象的

對象參與每個場景時都會展現(xiàn)其某一個方面性質(zhì)，這方面性質(zhì)都可以抽象出來雀久。對象所參與的場景越多宿稀，其越具有抽象價值。

對象都有層次性

對象都是有抽象層次的赖捌，高層次描述粗略但適應范圍廣祝沸，低層次描述精確但適應能力窄矮烹。需要根據(jù)問題領域的復雜程度設定多個抽象層次并使用合適的抽象程度對象進行描述。

image

（三）UML核心元素之參與者罩锐、用例

一奉狈、版型

在UML里有一個概念叫版型（stereotype），也被稱為類型涩惑、構造型仁期。

版型是由UML里的元素擴展而來，每個元模型都有很多版型竭恬，比如用例有“業(yè)務用例”跛蛋、“業(yè)務用例實現(xiàn)”等版型。當我們需要時候我們也可以根據(jù)UML里的元素自定義版型來輔助建模痊硕。

二赊级、參與者

參與者（actor）是在系統(tǒng)之外與系統(tǒng)交互的某人或某事物，在建模過程中處于核心地位岔绸。

參與者和系統(tǒng)之間有一個明確的邊界理逊，參與者只能存在于邊界之外，邊界之內(nèi)的所有人和事物都不是參與者盒揉。

image

每個用例都必須有參與者晋被，參與者可以非人，但一定是啟動業(yè)務的主角预烙。

三墨微、業(yè)務主角和業(yè)務工人

業(yè)務主角（business actor）是參與者的一個版型，用于定義業(yè)務的參與者扁掸。業(yè)務主角是與業(yè)務系統(tǒng)有著交互的人和事物翘县，他們用來確定業(yè)務范圍。

業(yè)務范圍：項目所涉及的所有客戶業(yè)務谴分，有沒有計算機系統(tǒng)參與都客觀存在锈麸；

系統(tǒng)范圍：軟件將要實現(xiàn)對應業(yè)務的系統(tǒng)功能。

業(yè)務主角是針對業(yè)務范圍來說的牺蹄，是客觀存在的忘伞，考慮業(yè)務主角時候需要拋開計算機的概念，這樣才能徹底搞清楚客戶的業(yè)務沙兰。

接下來這段完全就是我的親身經(jīng)歷氓奈，所以貼上來以作鞭策。

image

業(yè)務工人（business worker）是指的系統(tǒng)邊界內(nèi)鼎天，被動參與了業(yè)務的執(zhí)行過程的人舀奶。

四、參與者相關關系

涉眾（stakeholder）斋射，也稱為干系人育勺，是與要建設的這個系統(tǒng)有利益相關的一切人和事但荤。參與者就是涉眾代表，對系統(tǒng)提出要求來獲得他所代表的涉眾的利益涧至。

用戶（user）腹躁，指的是系統(tǒng)的使用者，是參與者的代表南蓬，一個用戶可以代理多個參與者纺非。

角色（role），指的是參與者的職責蓖康，一個角色代表了系統(tǒng)中的一類職責铐炫。

image

五、用例

用例的基本概念

用例（Use case）是一種把現(xiàn)實世界的需求捕獲下來的方法蒜焊。用例定義了一組用例實例倒信，其中每個實例都是系統(tǒng)所執(zhí)行的一系列操作，這些操作生成特定主角可以觀測的值泳梆。

在UML里鳖悠，除了用例之外，所有其他元素都是封裝獨立的优妙。用例推動這些UML元素關聯(lián)起來乘综，從而實現(xiàn)某個功能。所以說用例是UML建模中最重要的一個元素套硼。

一個完整的用例定義由參與者卡辰、前置條件、場景邪意、后置條件構成九妈。如下圖所示：

image

一個系統(tǒng)的功能性是有一些對系統(tǒng)有愿望的參與者要做的一些事情構成的，事情完成后就達成了參與者的一個愿望，當全部參與者的所有愿望都能夠通過用例來達到，那么這個系統(tǒng)就被確定下來了狠毯。

用例的特征

用例是相對獨立的。

用例的執(zhí)行結果對參與者來說是可觀測和有意義的晶疼。

image

這件事必須由一個參與者發(fā)起。不存在沒有參與者的用例又憨，用例不應該自動啟動翠霍，也不應該主動啟動另一個用例。

image

用例必然是以動賓短語形式出現(xiàn)的蠢莺。

image

一個用例就是一個需求單元寒匙、分析單元、設計單元浪秘、開發(fā)單元蒋情、測試單元，甚至部署單元耸携。

image

用例的粒度

用例的粒度是指的一個用例所描述事件的大小棵癣。

在業(yè)務建模階段，用例的粒度以每個用例能夠說明一件完整的事情為宜夺衍，即一個用例可以描述一項完整的業(yè)務流程狈谊。

在系統(tǒng)建模階段，用例視角是針對計算機的沟沙，因此用例的粒度以一個用例能夠描述操作者與計算機的一次完整交互為宜河劝。

現(xiàn)實情況中，根據(jù)系統(tǒng)的大小選擇不同用例粒度矛紫，可以更好適應其需求范圍赎瞎。

不論粒度如何選擇，必須把握的原則是在同一個需求階段颊咬，所有用例的粒度應該是同一個量級的务甥。

用例的獲得

用例的來源就是參與者對系統(tǒng)的期望。

一個明確的有效的目標才是一個用力的來源喳篇。

一個真實的目標應當完備地表達主角的期望敞临。

一個有效的目標應當在系統(tǒng)邊界內(nèi)，由主角發(fā)動麸澜，并具有明確的后果挺尿。

六、用例相關的誤區(qū)

用例和功能的誤區(qū)

用例需要從使用者的觀點出發(fā)來描述軟件炊邦；功能是脫離使用者的愿望而客觀存在的编矾。

用例是系統(tǒng)性的，以開燈為例铣耘，需要描述誰在什么情況下通過什么方式開燈結果是什么洽沟；功能是孤立的，只要按下開關燈就亮蜗细。

用例可以解釋為一系列完成一個特定目標的功能的組合裆操，針對不同的應用場景，這些功能體現(xiàn)不同的組合方式炉媒。

目標和步驟的誤區(qū)

一個用例是參與者對目標系統(tǒng)的一個愿望踪区，一個完整的事件，為了完成這個事件需要經(jīng)由很多步驟吊骤，但這些步驟不能夠完整地反映參與者的目標缎岗，不能夠作為用例。

用例粒度的誤區(qū)

用例的粒度不是越小越好白粉，太小了會使建模無比繁瑣且沒意義传泊；

一個系統(tǒng)里用例粒度如果不一鼠渺，會使系統(tǒng)邊界不確定，從而系統(tǒng)結構混亂眷细。

七拦盹、業(yè)務用例和業(yè)務用例實現(xiàn)

業(yè)務用例（business use case）是用例版型中的一種，專門用于需求階段的業(yè)務建模溪椎。

image

業(yè)務模型是針對客戶業(yè)務的模型普舆，與計算機系統(tǒng)建模無關，只是業(yè)務領域的一個模型校读。

業(yè)務用例的參與者是業(yè)務主角沼侣，如果說用例是用來獲取功能性需求，那么業(yè)務用例用來獲取功能性業(yè)務歉秫。

業(yè)務用例實現(xiàn)（business use case realization）是用例版型中的一種蛾洛，專門用于需求階段的業(yè)務建模。

image

業(yè)務用例實現(xiàn)是業(yè)務用例的一種實現(xiàn)方式端考，表達了同一項業(yè)務的不同實現(xiàn)方式雅潭。

業(yè)務用例和業(yè)務用例實現(xiàn)的關系舉例如圖

image

（四）UML核心元素之邊界類、實體類

一却特、邊界

邊界在UML圖符里定義只是一個簡單的矩形框扶供，矩形框的四個邊決定了邊界的內(nèi)外。

邊界本質(zhì)上是面向?qū)ο蠓椒ǖ囊粋€很重要的概念裂明，與封裝的概念相似椿浓。在面向?qū)ο罄铮魏我粋€對象都有一個邊界闽晦，外界只能通過這個邊界來認識對象扳碍，與對象打交道。

邊界決定視界仙蛉；
邊界決定抽象層次笋敞。

邊界是無形的，但是在面向?qū)ο蟮姆椒ɡ镘瘢瑥臉I(yè)務建模到接口設計邊界都可以發(fā)揮重要的作用夯巷。

二、業(yè)務實體

image

業(yè)務實體是類的一種版型哀墓，特別用于在業(yè)務建模階段建立領域模型趁餐，代表業(yè)務角色執(zhí)行業(yè)務用例時所處理或使用的“事物”。

業(yè)務實體是來自現(xiàn)實世界的篮绰，所有業(yè)務實體在現(xiàn)實世界里都有與之對應的事物后雷；
業(yè)務實體一定是在分析業(yè)務流程的過程當中發(fā)現(xiàn)的，與業(yè)務用例場景無法的事物，即使存在臀突，也不會為它建模勉抓；
業(yè)務實體具有對象的所有性質(zhì)，包括屬性候学、方法和對象的獨立性琳状。

屬性是用來保存業(yè)務實體特征的一個記錄，業(yè)務實體的屬性集合決定了它的唯一性盒齿；
方法是訪問一個業(yè)務實例的句柄，它規(guī)定了外部可以怎樣來使用它困食。

獲取業(yè)務實體：

1. 建立業(yè)務用例場景边翁；
2. 從業(yè)務用例場景中逐個分析動詞后面的名次，它們就是業(yè)務實體的備選對象硕盹；
3. 分析這些業(yè)務實體之間的關系符匾，并決定哪些應當單獨建模，哪些應當作為屬性瘩例。

三啊胶、包

image

包是一種容器，就如文件夾一樣垛贤。

包可以容納任何UML元素焰坪，也包括子包。包之間的關系定義只有依賴關系聘惦，好的分包具有高內(nèi)聚某饰，低耦合的性質(zhì)。

• 領域包（Domain Package）用于分類業(yè)務領域內(nèi)的業(yè)務單元善绎，每個包代表業(yè)務的一個領域黔漂，領域包視圖可用于展示這些業(yè)務領域的高層次關系；
• 子系統(tǒng)（Subsystem）用于分類系統(tǒng)內(nèi)的邏輯對象并形成子系統(tǒng)禀酱，子系統(tǒng)包視圖可用于展示系統(tǒng)的高層次邏輯結構關系炬守；
• 組織結構包（Organization unit）用于分類業(yè)務領域中的組織結構，它可以直接用來表述企業(yè)的資質(zhì)結構剂跟；
• 層包（Layer）用于分類軟件中的層次减途，層可以用于展示軟件的架構信息。

四浩聋、分析類

分析類用于獲取系統(tǒng)中主要的“職責簇”观蜗，代表系統(tǒng)的原型類，是系統(tǒng)必須處理的主要抽象概念的“第一個關口”衣洁。

分析類可以產(chǎn)生系統(tǒng)的的設計類和子系統(tǒng)墓捻。

分析類是從業(yè)務需求向系統(tǒng)設計轉(zhuǎn)化過程中最為主要的元素，它們在高層次抽象出系統(tǒng)實現(xiàn)業(yè)務需求的原型，業(yè)務需求通過分析類邏輯化砖第，被計算機所理解撤卢。

分析類包含三種，分別是邊界類（boundary）梧兼、控制類（control）和實體類（entity）放吩。

邊界類

image

邊界類是一種用于對系統(tǒng)外部環(huán)境與其內(nèi)部運作之間的交互進行建模的類。

• 參與者與用例之間應當建立邊界類羽杰；
• 用例與用例之間如果有交互渡紫，應當為其建立邊界類；
• 如果用例與系統(tǒng)邊界之外的非人對象有交互考赛，比如第三方系統(tǒng)惕澎，應當為其建立邊界類；
• 在相關聯(lián)的業(yè)務對象有明顯的獨立性要求颜骤，也應當為它們建立邊界類唧喉。

從架構角度上來說，邊界類主要位于展現(xiàn)層忍抽。

控制類

image

控制類用于對一個或幾個用例所特有的控制行為進行建模八孝。
控制類來源于對用例場景當中動詞的分析和定義，包括限制動詞的描述鸠项。
從架構角度上來說干跛，控制類主要位于業(yè)務邏輯層。

實體類

image

實體類是用于對必須存儲的信息和相關行為建模的類祟绊。
實體類源于業(yè)務建模中的業(yè)務實體驯鳖。
從架構角度上來說，實體類主要位于數(shù)據(jù)持久層久免。

分析類的三高

分析類是從業(yè)務需求向系統(tǒng)設計轉(zhuǎn)化過程中最為主要的元素浅辙，它們在高層次抽象出系統(tǒng)實現(xiàn)業(yè)務需求的原型，業(yè)務需求通過分析類被邏輯化阎姥，成為可以被計算機理解的語義记舆。

• 高于設計實現(xiàn)
• 高于語言實現(xiàn)
• 高于實現(xiàn)方式

分析類的抽象層次較高，只需要專注在實現(xiàn)需求上呼巴，也因此比設計和實現(xiàn)更加穩(wěn)定泽腮。

五、設計類

設計類是系統(tǒng)實施中一個或多個對象的抽象衣赶，設計類所對應的對象取決于實施語言诊赊。設計類用于設計模型中，它直接使用與編程語言相同的語言來描述府瞄。

設計類由類型碧磅、屬性和方法構成，設計類的名稱、屬性和方法也直接映射到編碼中相應的class鲸郊、property和method丰榴。

類
類對對象進行定義，而對象又實現(xiàn)用例秆撮。
類是對對象某一方面特征的歸納和抽象四濒，而對象則是類實例化的結果。

屬性
屬性是對象特征职辨，屬性同時表明了對象的唯一性盗蟆。

方法
方法是訪問對象或影響其他對象的屬性或關系的唯一途徑，由類進行定義舒裤。

可見性
類的屬性和方法都有可見性的定義姆涩，常見的有：

• 公有：除了類本身以外，屬性和方法對其他模型元素也是可視的惭每。
• 保護：屬性和方法只對類本身、它的子類或友元是可視的亏栈。
• 私有：屬性和方法只對類本身和類的友元是可視的台腥。
• 實施：屬性和方法只在類本身的內(nèi)部是可視的。

（五）UML核心元素之關系绒北、組件和節(jié)點

一黎侈、關系

關系抽象出對象之間的聯(lián)系，讓對象構成某個特定的結構闷游。

關聯(lián)關系（association）

image

關聯(lián)關系是用一條直線表示的峻汉，描述不同類的的對象之間的結構關系。

image

單向關聯(lián)關系是用一條帶剪頭的直線來表示脐往，表明A關聯(lián)B休吠，但是B不關聯(lián)A，比如用力模型里业簿，參與者單向關聯(lián)用例瘤礁。

依賴關系（dependency）

image

依賴關系是用一條帶箭頭的虛線表示的，用來描述一個對象的修改會導致另一個對象修改梅尤。
依賴關系也有單向依賴和雙向依賴之分柜思，但雙向依賴非常不推薦。

擴展關系（extends）

image

擴展關系是用一條帶箭頭的虛線加版型<<extends>>來表示的巷燥，特別用于在用例模型中說明向基本用例中的某個擴展點插入擴展用例赡盘。
擴展用例是用例場景中的某個“支流”，是一種可選的缰揪，即使該擴展用例不存在陨享，其基本用例也是完整的。
使用場景有：
表明用例的某一部分是可選的系統(tǒng)行為；
表明只在特定條件下才執(zhí)行分支流霉咨，比如觸發(fā)警報蛙紫；
表明可能有一組行為段，其中的一個或多個段可以在基本用例的擴展點處插入途戒；
表明多個基本用例中都有可能出發(fā)一個可選的分支流坑傅。

包含關系（include）

image

包含關系是用一條帶箭頭的虛線加版型<<include>>來表示的，特別用于用例模型里執(zhí)行基本用例的用例實例過程中插入的行為段喷斋。
包含用例是用例場景里關鍵的核心業(yè)務唁毒，是一種必選的，如果包含用力不存在星爪，其基本用例也就不完整了浆西。
使用場景有：
從基本用例中分解出這樣的行為：它對于了解基本用的主要目的并不是必需的，只有它的結果比較重要顽腾；
分解出兩個或更多個用例所共有的行為近零。

實現(xiàn)關系（realize）

image

實現(xiàn)關系是用一條帶空心箭頭的虛線表示，特別用于在用例模型中連接用例和用力實現(xiàn)抄肖，說明基本用例的一個實現(xiàn)方式久信。
實現(xiàn)所代表的含義是，基本用例描述了一個業(yè)務目標漓摩，但是該業(yè)務目標有多種可能的實現(xiàn)途徑裙士，每一種實現(xiàn)途徑可以用用例實現(xiàn)來表示，而用例實現(xiàn)和基本用例之間就構成了實現(xiàn)關系管毙。

精化關系（refine）

image

精化關系是用一條帶剪頭的虛線加版型<<refine>>來表示腿椎，特別用于用例模型，一個基本用例可以分解出許多更小的關鍵精化用例夭咬，用來更細致地展示基本用例的核心業(yè)務啃炸。
精化關系也可以用于模型與模型之間，表示某個模型是通過精化另一個模型而得來的卓舵。
精化關系的子對象并沒有增加肮帐、減少、改變基本對象的行為和屬性边器，僅僅是更加細致和明確化训枢。

泛化關系（generalization）

image

泛化關系是用一條帶空心箭頭的直線表示，說明兩個對象之間的繼承關系忘巧。
泛化關系的子對象繼承了基本對象的所有特征恒界，并且子對象可以增加、改變基本對象的行為和屬性砚嘴。

聚合關系（aggregation）

image

聚合關系是用一條帶空心菱形箭頭的直線表示十酣，常用于類圖涩拙，表達實體整體由部分構成的語義。
聚合關系的整體和部分不是強依賴耸采，即使整體不存在了兴泥，部分仍然存在。

組合關系（composition）

image

組合關系是用一條帶實心菱形箭頭的直線表示虾宇，常用于類圖搓彻，表達實體整體擁有部分的語義。
組合關系是一種強依賴的特殊聚合關系嘱朽，如果整體不存在了旭贬，部分也將消亡。

二搪泳、組件

image

組件是系統(tǒng)中實際存在的可更換部分稀轨，符合一套接口標準并實現(xiàn)一組接口。
一個組件應當是一個獨立的業(yè)務模塊岸军，有著完備的功能奋刽，可獨立部署，一個組件可以看成是一個完備的服務艰赞。
組件一般都是在較高的抽象層次定義的佣谐，在許多應用項目中并不需要組件建模。但是离陶，如果采用了組件化的開發(fā)架構旺韭，或者從一開始就決定采用組件化開發(fā)模式，那么從系統(tǒng)分析開始就應當著手建立組件模型，并在后續(xù)的模型中逐步精化擦俐。

三、節(jié)點

image

節(jié)點是帶有至少一個處理器坤候、內(nèi)存以及可能還帶有其他設備的處理元素喜每。
在實際工作中，一般說來服務器是己、工作站或客戶機都可以稱為一個節(jié)點又兵。

（六）UML核心視圖之靜態(tài)視圖：用例圖、類圖

靜態(tài)視圖
靜態(tài)視圖就是表達靜態(tài)事物的卒废，只描述事物的靜態(tài)結構沛厨，不描述其動態(tài)行為。

用例圖
用例圖采用參與者和用例作為基本元素摔认，以不同的視角展現(xiàn)系統(tǒng)的功能性需求逆皮。
對客戶來說，用例圖是他們業(yè)務領域的邏輯化表達参袱；對建設單位來說电谣，用例圖是系統(tǒng)藍圖和開發(fā)的依據(jù)秽梅。

業(yè)務用例視圖
業(yè)務用例視圖需要從業(yè)務主角和業(yè)務模塊兩個視角來展現(xiàn)業(yè)務建模的結果。

從業(yè)務主角的視角有利于向業(yè)務主角確認其業(yè)務目標是否都已經(jīng)齊全剿牺。

image

從業(yè)務模塊視角有利于從業(yè)務的完整性角度出發(fā)檢查完成某個業(yè)務的所有業(yè)務主角和業(yè)務用例是否已經(jīng)齊全企垦。

image

業(yè)務用例實現(xiàn)視圖
業(yè)務用例實現(xiàn)視圖展現(xiàn)業(yè)務用例有哪些實現(xiàn)途徑。

業(yè)務用例是業(yè)務需求晒来，而業(yè)務用例實現(xiàn)則是業(yè)務的實現(xiàn)途徑钞诡。

image

概念用例視圖
概念用例視圖用于展現(xiàn)從業(yè)務用力中經(jīng)過分析分解出來的關鍵概念用例，并表示概念用例和業(yè)務用例之間的關系潜索，包括擴展臭增、包含和精化關系等。

image

系統(tǒng)用例視圖

系統(tǒng)用視圖以業(yè)務用例為單位竹习，將對業(yè)務用例進行分析后得到的系統(tǒng)用例展現(xiàn)出來誊抛。

image

系統(tǒng)用例實現(xiàn)視圖
系統(tǒng)用例實現(xiàn)視圖展現(xiàn)系統(tǒng)用例的實現(xiàn)方式。

image

小結
用例圖包括業(yè)務用例視圖整陌、業(yè)務用例實現(xiàn)視圖拗窃、概念用例視圖、系統(tǒng)用例視圖和系統(tǒng)用例實現(xiàn)視圖泌辫。
在實際項目中随夸，不是所有的用例圖都一定要采用。根據(jù)情況可進行適當裁減震放，在許多項目中實際只有系統(tǒng)用例視圖宾毒。

類圖
類圖用于展示系統(tǒng)中的類及其相互之間的關系。
類圖是現(xiàn)實世界問題領域的抽象對象的結構化殿遂、概念化诈铛、邏輯化描述。

概念層類圖
概念層類圖位于業(yè)務建模階段墨礁，描述的是現(xiàn)實世界中問題領域的概念理解幢竹，以領域模型圖來表示的。

image

說明層類圖
說明層類圖位于概念模型階段恩静，描述的是問題領域在接口層次的抽象描述焕毫，以分析類和分析模型圖來表示。

image

實現(xiàn)層類圖
實現(xiàn)層類圖位于設計階段驶乾，描述的代碼的實現(xiàn)邑飒，類圖中的類直接映射到可執(zhí)行代碼，必須明確采用哪種實現(xiàn)語言级乐、什么設計模式幸乒、什么通信標準、遵循什么規(guī)范等唇牧。

image

（七）罕扎、UML核心視圖之動態(tài)視圖：活動圖聚唐、時序圖

動態(tài)視圖
動態(tài)視圖是描述事物動態(tài)行為的，不能獨立存在腔召，必須特指一個靜態(tài)視圖或UML元素杆查，說明在靜態(tài)視圖規(guī)定的事物結構下它們的動態(tài)行為。

活動圖

image

活動圖描述了為了完成某一個目標需要做的活動以及這些活動的執(zhí)行順序臀蛛。
UML中有兩個層面的活動圖亲桦，一種用于描述用例場景，另一種用于描述對象交互浊仆。

活動圖實際上描述的是業(yè)務流程客峭，是一種過程化的分析方法，因此在使用活動圖時候抡柿，要隨時保持清醒的頭腦舔琅，活動圖只是我們用來描述業(yè)務目標的達成過程并借此來發(fā)現(xiàn)對象的工具，不是我們的分析目標洲劣，也不是編程的依據(jù)备蚓，它只是對象的應用場景之一。

用例活動圖
用例表達了參與者的一個目標囱稽，用例場景則描述了如何來達到這個目標郊尝，而活動圖用來描述用例場景，也就是業(yè)務流程战惊。

image

對象活動圖
對象活動圖用于展示對象的交互流昏。

image

泳道
活動圖描述了業(yè)務流程中活動的執(zhí)行順序，卻沒有描述出執(zhí)行業(yè)務流程的職責吞获；而在面向?qū)ο蟮姆治鲇^點里况凉，業(yè)務的執(zhí)行過程不是重要的，對象職責才是最重要的衫哥。所以引入了泳道技術茎刚。
泳道代表了一個特定的類襟锐、人撤逢、部門、層次等對象的職責區(qū)粮坞。將登機的用例活動圖加入泳道以后蚊荣，可以得到：

image

業(yè)務場景建模
在實際情況中，客戶的業(yè)務通常是以業(yè)務流程的形式存在的莫杈，所以我們經(jīng)常以業(yè)務主角作為泳道互例，以從業(yè)務主角出獲取的業(yè)務用例作為活動來編排活動圖。這樣的好處有：
幫助發(fā)現(xiàn)業(yè)務用例
幫助檢查業(yè)務用例粒度
幫助檢查業(yè)務主角
幫助檢查業(yè)務用例

用例場景建模
在獲取業(yè)務用例之后筝闹，我們經(jīng)常以業(yè)務主角和業(yè)務工人作為泳道媳叨、以工作單元作為活動來編排活動圖來描述用例場景腥光。這樣的好處有：
幫助發(fā)現(xiàn)概念用例
幫助發(fā)現(xiàn)角色
幫助發(fā)現(xiàn)業(yè)務實體
幫助建立領域模型

時序圖

image

時序圖用于描述按時間順序排列的對象之間的交互模型
時序圖中包含對象和主角實例，以及說明它們?nèi)绾谓换サ南⒑眩饕脕泶_定對象的職責和接口武福。

業(yè)務模型時序圖
業(yè)務模型時序圖用于為領域模型中的業(yè)務實體交互建模，目標是實現(xiàn)業(yè)務用例痘番。

image

概念模型時序圖
概念模型時序圖是依據(jù)業(yè)務模型場景采用分析類來重新繪制一遍捉片，目標同樣是實現(xiàn)業(yè)務用例。
因為分析類本身代表了系統(tǒng)原型汞舱，所以這時的時序圖已經(jīng)有了實現(xiàn)的影子伍纫。

image

設計模型時序圖
設計模型時序圖使用設計類作為對象繪制，目標是實現(xiàn)概念模型中的某個事件流昂芜，一般以一個完整交互為單位莹规，消息細致到方法級別。
因為設計模型時序圖工作量實在太大说铃，不需要為每一個交互都繪制時序圖访惜，但一定要有足夠的概念模型時序圖來支撐需求與實現(xiàn)之間的過渡。

（八）腻扇、項目開始前的準備工作

一债热、了解問題領域
軟件是一種工具，是用來輔助人們解決某一問題的幼苛。軟件的價值就在于它能夠符合問題領域的需要窒篱，并達到人們解決問題的期望。軟件項目總是從了解問題領域開始的舶沿。
1.了解業(yè)務概況
2.整理業(yè)務目標

二墙杯、做好涉眾分析

在了解業(yè)務概況和業(yè)務目標以后，首先要做的不是去了解業(yè)務的細節(jié)括荡，而是去發(fā)現(xiàn)與這個目標相關的人和物高镐。

1.什么是涉眾。涉眾是與要建設的業(yè)務系統(tǒng)相關的一切人和事畸冲，他們與項目有利益關系嫉髓，都可能對系統(tǒng)建設造成影響。

2.如何發(fā)現(xiàn)和定義涉眾邑闲。

業(yè)主：系統(tǒng)的出資方算行、投資者——關心的是建設成本、建設周期以及建成后的效益苫耸。
業(yè)務提出者：業(yè)務范圍州邢、業(yè)務模式和業(yè)務規(guī)則的制定者——關心系統(tǒng)建設能夠帶的社會影響、效率提升褪子、管理改進量淌、成本節(jié)約等宏觀效果骗村。
業(yè)務管理者：實際管理和監(jiān)督業(yè)務執(zhí)行的人員——關心系統(tǒng)將如何實現(xiàn)他們的管理職能，如何下達指令呀枢、如何得到反饋叙身、如何評估結果等。系統(tǒng)建設的好壞與業(yè)務管理者的關系最多硫狞，也是系統(tǒng)分析員最需要下功夫的信轿。
業(yè)務執(zhí)行者：底層的業(yè)務操作人員——關心系統(tǒng)會給他們帶來什么樣的方便，或怎樣的改變他們的工作模式残吩。
第三方：與這項業(yè)務有關系的财忽，但并非業(yè)務方的其他人或事——對系統(tǒng)不會產(chǎn)生決定性影響，但大多會起到限制作用泣侮。
承建方：你的老板——關心通過這個項目是否能賺到錢即彪、是否能積累核心競爭力、是否能樹立品牌活尊、是否能開拓市場隶校。
相關的法律法規(guī)——既指的國家和地方法律法規(guī)，也指的行業(yè)規(guī)范和標準蛹锰。
用戶：預期的系統(tǒng)使用者深胳，涉眾代表——實實在在參與系統(tǒng)的，需要編程實現(xiàn)的系統(tǒng)中一個角色铜犬。

3.涉眾分析報告
涉眾概要：為每個涉眾進行編號舞终，并說明涉眾的基本信息和涉眾在系統(tǒng)中的角色。涉眾分析時候最重要的是準確描述涉眾情況和他們對系統(tǒng)建設的期望癣猾，而不是進入業(yè)務細節(jié)敛劝。
涉眾簡檔：描述涉眾在系統(tǒng)中承擔的職責，以及涉眾在系統(tǒng)中的成功標準纷宇。
用戶概要：說明代表涉眾使用系統(tǒng)的用戶說明夸盟。業(yè)務需求來自于涉眾，但是界面需求很可能來自預期的系統(tǒng)用戶像捶。
用戶簡檔：將一些典型的用戶代表的一些信息描述出來上陕。
消費者統(tǒng)計：說明系統(tǒng)的預期使用人群和他們的特點，使用系統(tǒng)的頻率和方式作岖，消費者對此系統(tǒng)的普遍期望等唆垃。

三五芝、規(guī)劃業(yè)務范圍
在開始進行需求之前痘儡，必須先規(guī)劃業(yè)務范圍。這個范圍并不是指系統(tǒng)的建設范圍枢步，而是指出需求調(diào)研應當被局限在哪些部分沉删。
1.規(guī)劃業(yè)務目標
取消一個業(yè)務目標渐尿；
調(diào)整一個業(yè)務目標。
2.規(guī)劃涉眾期望
取消一個涉眾矾瑰；
減少一個涉眾期望砖茸；
調(diào)整一個涉眾期望。

四殴穴、整理好你的思路
根據(jù)涉眾分析報告就可以有的放矢地根據(jù)涉眾關心的問題規(guī)劃出需求調(diào)研計劃凉夯。
1.劃分優(yōu)先級
涉眾優(yōu)先級標準：根據(jù)涉眾是業(yè)務核心成員、主要業(yè)務模塊的參與者還是邊緣業(yè)務模塊的參與者進行排序采幌；
期望優(yōu)先級標準：根據(jù)期望是核心業(yè)務劲够、核心業(yè)務的重要輔助部分還是一些邊緣業(yè)務進行排序劃分。
優(yōu)先級矩陣：

2.規(guī)劃需求層次
第一層次：業(yè)務架構休傍。圍繞業(yè)務背景征绎、業(yè)務目標、業(yè)務目標人員磨取、業(yè)務參與人員人柿、組織結構、崗位設置等展開忙厌，建立業(yè)務用例模型的業(yè)務用例視圖凫岖、領域模型視圖。
第二層次：業(yè)務流程逢净。針對每個業(yè)務目標隘截，將參與這個業(yè)務目標的業(yè)務目標人員。業(yè)務參與人員汹胃。組織結構和崗位設置組織起來婶芭，建立業(yè)務用例實現(xiàn)、用例場景着饥、分析場景在內(nèi)的完整業(yè)務用例模型和概念模型犀农。
第三層次：工作細節(jié)。針對每個參與上述業(yè)務流程的參與者展開宰掉，建立系統(tǒng)用例模型呵哨、初步的分析模型和初步的軟件架構。

3.需求調(diào)研計劃
需求調(diào)研計劃是項目計劃的一部分轨奄，該計劃規(guī)定了哪些優(yōu)先級的期望在什么時候進展到什么需求層次孟害，由誰來負責。

五挪拟、客戶訪談技巧
1.溝通的困難
一般來說系統(tǒng)分析員是計算機專家挨务，習慣于從計算機角度來看問題；客戶是業(yè)務專家，習慣身邊的人也熟悉這個業(yè)務領域谎柄。
所以系統(tǒng)分析員需要改變自己的立場丁侄，了解業(yè)務是什么，還要弄清業(yè)務為什么朝巫。
首先鸿摇，應該有一個詳細的涉眾分析報告，循序漸進地從接觸到深入了解客戶劈猿；
其次拙吉，不要急于深入業(yè)務細節(jié)，而是先就一些大框框進行溝通揪荣，借此習慣和了解對方的溝通方式庐镐；
再次，雙方的時間是有限的变逃，因此每一次會面都需要爭分奪秒必逆，用最快的時間把問題搞清楚；
最后揽乱，系統(tǒng)分析員需要承擔每次會談結果記錄名眉，并且需要正式的反饋和確認，以便之后和客戶在需求變更時候有依據(jù)凰棉。

2.溝通的技巧
建立平等的對話平臺——系統(tǒng)分析員應當首先學習業(yè)務相關的背景知識损拢，在與客戶交談過程中不僅僅是詢問和聆聽，還要參與撒犀；其次福压，適當將技術與業(yè)務結合起來，以淺顯易懂的方式引導客戶理解一些技術層面的知識或舞；
做足準備工作——在短時間內(nèi)把粗略的業(yè)務搞清楚荆姆，談話過程中不僅是充當提問者和聆聽者的角色，而且要能和客戶就某些業(yè)務問題交換意見映凳，才能得到客戶的信任胆筒，引起交流的興趣；
以我為主——每次談話都要有明確的目標诈豌；
改變溝通策略——了解對方的溝通習慣和思維方式仆救，并根據(jù)這個適當改變溝通的策略；
把握需求節(jié)奏——每次不要涉及太多的問題矫渔，把握好需求層次彤蔽；
記錄和反饋——記錄每次談話的結果，形成文檔后交還給客戶閱讀庙洼。

（九）顿痪、需求獲取

一镊辕、定義邊界
定義邊界的目的是為我們確定一個分析的起點。
每個業(yè)務目標都會有一個邊界存在员魏，每個邊界的劃分則指明了需求分析的起點。

二叠聋、發(fā)現(xiàn)主角
不是所有的涉眾都會成為業(yè)務主角撕阎，只有那些直接與系統(tǒng)交互的涉眾才能被稱為業(yè)務主角。一個涉眾可以衍生出多個主角碌补。
涉眾雖然是系統(tǒng)的利益相關者虏束，但卻未必直接與系統(tǒng)交互，他可以找到替代他行使利益的另一個角色厦章。
業(yè)務主角總是在邊界之外镇匀，只有邊界之外的事物才有權利向由邊界代表的系統(tǒng)提出要求。
業(yè)務主角可能帶代表了多個涉眾利益袜啃，對系統(tǒng)也有著許多要求汗侵，但是對于一個特定的邊界來說，由于邊界代表了某個業(yè)務目標群发，那些與業(yè)務目標無關的要求也不應當在該邊界中體現(xiàn)出來晰韵。
業(yè)務主角，之所以加上業(yè)務二字熟妓，是因為業(yè)務主角確實區(qū)別于系統(tǒng)參與者雪猪，它有可能不會轉(zhuǎn)化成一個系統(tǒng)參與者，但能夠映射到現(xiàn)實業(yè)務中的工作崗位設置起愈、工作職能說明只恨。

三、獲取業(yè)務用例
獲取業(yè)務用例的方法有很多抬虽，可以從崗位手冊官觅、業(yè)務流程指南、職務說明等一些文件中獲得阐污，也可以從涉眾分析中獲得靈感缰猴。
除此之外，還一種方法就是業(yè)務主角訪談疤剑，可以通過以下問題引導業(yè)務主角代表說出他們的業(yè)務需求：
您對系統(tǒng)有什么期望
您打算在這個系統(tǒng)里做些什么事情变丧？
您做這件事的目的是什么？
您做完這件事希望有一個什么樣的結果虹茶？

業(yè)務用例找到了后撮奏，還應當用適當?shù)囊晥D把它們展現(xiàn)出來。
業(yè)務用例獲取到已經(jīng)把客戶的業(yè)務弄清楚了就可以考慮結束了弯菊，不必等到事無巨細每件事都定義清楚纵势。可以采用迭代式開發(fā)。

四钦铁、業(yè)務建模
業(yè)務用例場景用來描述該業(yè)務的實際過程中是如何做的软舌，主要用到了活動圖、時序圖牛曹、協(xié)作圖佛点。
活動圖側重于描述參與業(yè)務的各個參與者在該業(yè)務當中所執(zhí)行的活動。這種圖適合于分析參與者的職責黎比，并且有利于將業(yè)務用例分解成為更小的單元超营，為獲得概念用例乃至系統(tǒng)用例帶來好處。

image

時序圖用于描述對象之間按一定的順序互通消息而完成一個特定的目標阅虫。

image

活動圖和時序圖的差別：
活動圖強調(diào)職責演闭，時序圖強調(diào)順序；
活動圖中活動是主要的內(nèi)容颓帝，表達的內(nèi)容是業(yè)務主角或業(yè)務工人做什么米碰；時序圖中，消息是主要的內(nèi)容购城，表達的內(nèi)容是業(yè)務主角或業(yè)務工人之間傳遞的是什么见间。

協(xié)作圖本質(zhì)上與時序圖是可以互換的，只是表達不同的視角工猜。

image

五米诉、領域模型
領域是我們分析問題時將整體分解以后的相對獨立的部分。
實際工作中篷帅，并不需要把問題完全分解成領域史侣，也不需要為每個領域都建模，而只挑選那些對業(yè)務來說重要的魏身、對過程來說核心的或者對系統(tǒng)來說復雜和困難的哪些部分來建模惊橱。

提出領域問題
了解關心該領域的所有可能的涉眾是如何理解和要求該領域的。問題來源于業(yè)務核心箭昵、重點税朴、難點，也可能來源于特殊的應用環(huán)境或客戶特殊的要求家制，

分析領域問題
根據(jù)提出的領域問題提出假設正林，再獲取解決方案。

建立領域模型
繪制出領域模型靜態(tài)圖颤殴，繪制出領域?qū)ο竺倮㈩I域?qū)ο笾g的關系以及領域?qū)ο笈c業(yè)務對象之間的關系。

驗證領域模型
驗證領域模型的正確性以及業(yè)務用例如何使用這些領域模型涵但。

領域模型和用例分析方法
用例分析方法可以說明一個系統(tǒng)的功能性需求杈绸，但是對于一個關聯(lián)性的問題帖蔓，因為用例本身是獨立的，無法表達涉及跨越多個用例的問題瞳脓。此時用領域模型可以很好解決這個問題塑娇。
用例分析方法只能夠分析功能性需求，對于非功能性需求只能用領域模型來分析劫侧。

問題領域的原則
1.簡單需求無需建立領域模型埋酬；
2.只針對核心業(yè)務建立；
3.針對難點建立板辽；
4.關注非功能性需求奇瘦。

領域模型與用例模型
在針對功能性需求時候棘催，領域模型是對用例模型的抽象劲弦、優(yōu)化和擴展。

六醇坝、提煉業(yè)務規(guī)則
業(yè)務規(guī)則是用來指導人們怎么做系統(tǒng)邑跪。

全局規(guī)則
全局規(guī)則是指那些對于系統(tǒng)大部分業(yè)務或系統(tǒng)設計都起約束作用的規(guī)則，主要用來限制功能性需求呼猪。

交互規(guī)則
交互規(guī)則產(chǎn)生于用例場景當中画畅，活動轉(zhuǎn)移、狀態(tài)變遷和對象交互時必然會有的一些限制性條件宋距。

內(nèi)稟規(guī)則
內(nèi)稟規(guī)則是指那些業(yè)務對象本身具備的轴踱，并且不因為外部的交互而變化的規(guī)則。

七谚赎、非功能性需求
可靠性
可靠性包括安全性淫僻、事務性和穩(wěn)定性三個方面

可用性
可用性用來衡量人們使用一個軟件產(chǎn)品的滿意程度

有效性
有效性包括性能、可伸縮性壶唤、可擴展性三個方面雳灵。

可移植性

（十）、需求分析

一闸盔、關鍵概念分析
關鍵概念是指支撐起客戶整個業(yè)務架構的那條主線悯辙，在UML方法里，就是由一些關鍵的業(yè)務用例構成迎吵。
需求分析就是要找到這些關鍵的業(yè)務用例躲撰，并且對它們進行分析，建立概念模型击费，依據(jù)概念模型搭建業(yè)務架構茴肥，然后為了驗證這個架構或者進行技術可行性分析開發(fā)出系統(tǒng)原型。

概念模型始于業(yè)務用例荡灾，是針對需求中的關鍵業(yè)務瓤狐，或者說業(yè)務核心來建立的瞬铸。
概念模型是需求轉(zhuǎn)入系統(tǒng)之間的橋梁。

獲取概念用例
概念模型的構建是通過圍繞業(yè)務主線础锐，從業(yè)務用例當中挑選出一些業(yè)務用例進行關鍵概念分析嗓节。

當關鍵業(yè)務用例挑選出來之后，根據(jù)業(yè)務主線的需要皆警，為這些業(yè)務用例找出概念用例拦宣。

image

分析概念用例
分析概念用例的過程也業(yè)務用例建模一樣，仍然是繪制概念用例的場景圖（活動圖信姓、時序圖等）鸵隧，然后從中找到關鍵的對象，最后再為這些關鍵對象繪制一些協(xié)作圖以說明這些對象之間的關系和交互場景意推。

建立概念模型
每分析清楚一個概念用例豆瘫，就能得到它的關鍵對象。
關鍵對象都是一些實體對象菊值，需要采用MVC模式進行分析外驱，用這三個元素建立實現(xiàn)用例場景的對象模型。

每個概念模型表示一個功能腻窒，各個概念模型之間通過軟件架構聯(lián)系起來昵宇。

image

領域模型和概念模型
概念模型不一定針對業(yè)務，針對的是問題儿子，這些問題可以與業(yè)務無關瓦哎。
概念模型是只針對業(yè)務的，它要解決的問題從業(yè)務理解向系統(tǒng)理解轉(zhuǎn)化之前柔逼，通過概念建模來在項目早起發(fā)現(xiàn)并解決問題蒋譬。

二、業(yè)務架構
一個基本原則：技術服務于業(yè)務卒落。
業(yè)務架構羡铲，實際上就是對需求細致分析和深刻理解的基礎上，抽象出若干相對獨立的業(yè)務模塊儡毕，形成自洽的業(yè)務構件也切。
從概念模型入手，根據(jù)找到業(yè)務主線找到每個大的業(yè)務構件腰湾，再通過領域模型分解為小的構件,再根據(jù)概念模型找到各個小的構件之間的依賴關系雷恃。
每個業(yè)務構件的產(chǎn)生都來自于各類模型和場景，都是“功能點”的集合费坊。
業(yè)務構件可以封裝業(yè)務實體以及對業(yè)務實體的處理倒槐，也可以只封裝處理邏輯。
業(yè)務架構是拼圖單元的話附井，軟件架構就是拼圖的方法讨越，可以說業(yè)務架構+軟件架構=業(yè)務系統(tǒng)两残。

建模的價值，關于每種模型的價值把跨，可以更深的感受下：

image

三人弓、系統(tǒng)原型
拋棄型原型，就是當原型目的達到后着逐，原型的使命也就結束了崔赌。主要用于驗證核心業(yè)務的理解是否正確。
漸進型原型耸别，從開發(fā)原型時健芭，就考慮將來要在它基礎上逐步完善，乃至形成最終系統(tǒng)秀姐。主要用于吧核心業(yè)務慈迈、業(yè)務架構和軟件架構結合起來。

（十一）囊扳、系統(tǒng)分析

一吩翻、確定系統(tǒng)用例
系統(tǒng)用例由業(yè)務用例抽象而來兜看，系統(tǒng)用例描述系統(tǒng)锥咸，業(yè)務用例描述業(yè)務。
業(yè)務用例抽象為系統(tǒng)用例的基本方法有：
映射：映射是最簡單最直接的方法细移；
抽象：當業(yè)務場景當中的備選用例不能夠被直接映射時搏予，需要進行一些抽象；
合并：當業(yè)務場景當中的備選用例不具備獨立性時弧轧，它必然是其他某個時間的組成部分雪侥；
拆分：有時業(yè)務用例場景當中的一個備選用例粒度很大，就需要進行拆分精绎；
演繹：有時業(yè)務用例場景當中找不到備選用例速缨，或者不適合用計算機來實現(xiàn)，但是能夠遇見到某個可能的系統(tǒng)用例潛伏在這個場景當中代乃，就需要演繹找出來旬牲。
在確定系統(tǒng)用例后，可以采用活動圖搁吓、時序圖原茅、交互圖等進行系統(tǒng)用例的描述。

軟件工程當中堕仔，需求的可追溯性是很重要的擂橘。從業(yè)務需求到系統(tǒng)需求的過程關鍵就在映射、抽象摩骨、合并通贞、差分和演繹的過程能否被記錄下來朗若。
根據(jù)階段不同，使用不同的粒度：在業(yè)務建模階段昌罩，用例的粒度以每個用例能夠說明一件完整的事情為宜捡偏；在概念建模階段，用例的粒度以每個用例能描述一個完整的事件流為宜峡迷；在系統(tǒng)建模階段银伟，用例的粒度以一個用例能夠描述操作者與計算機的一次完整交互為宜。

二绘搞、分析業(yè)務規(guī)則
業(yè)務規(guī)則對一個組織的運轉(zhuǎn)來說至關重要彤避，從管理制度到業(yè)務手冊、從操作規(guī)范到崗位指南夯辖，業(yè)務規(guī)則充斥著整個企業(yè)的方方面面琉预。
分析業(yè)務規(guī)則的目的是從業(yè)務規(guī)則當中發(fā)現(xiàn)出那些將對系統(tǒng)構成重大影響的部分，將其轉(zhuǎn)化為系統(tǒng)需求蒿褂，并且針對這一部分進行有針對性的架構圆米、框架、程序的設計啄栓。

分析全局規(guī)則
全局規(guī)則是那些對于系統(tǒng)大部分業(yè)務或系統(tǒng)設計都起約束作用的那些規(guī)則娄帖。
全局規(guī)則在應用程序當中就被反應到了軟件結構當中，通過軟件架構來對用例產(chǎn)生影響昙楚。

分析交互規(guī)則
交互規(guī)則產(chǎn)生于用例場景當中近速。用例場景是由活動圖、交互圖等來描述的堪旧，不論是活動削葱、狀態(tài)還是業(yè)務對象，它們在活動轉(zhuǎn)移淳梦、狀態(tài)變遷和對象交互時必然會有一些限制性條件析砸，這些條件就是交互規(guī)則。
交互規(guī)則產(chǎn)生于用例場景當中爆袍，很可能是跨用例的首繁，為了避免依賴的出現(xiàn)，應當將較復雜的交互規(guī)則設計成單獨的對象或模塊螃宙。

分析內(nèi)稟規(guī)則
內(nèi)稟規(guī)則是業(yè)務對象本身具備的蛮瞄，并且不因為外部的交互而變化的規(guī)則。
內(nèi)稟規(guī)則非常類似于對象的封裝原則谆扎，所以交給程序員來處理即可挂捅。

三、用例實現(xiàn)
一個用例可能有多個用例實現(xiàn)堂湖，每個用例實現(xiàn)都是設想的一種實現(xiàn)方式闲先。
要為用例實現(xiàn)建模状土，我們需要經(jīng)過一下三個步驟：
1.需要再用例場景當中發(fā)現(xiàn)和定義實體對象；
2.需要用控制對象來操作和處理實體對象當中的數(shù)據(jù)伺糠；
3.需要用邊界對象來構建接受外部指令的界面蒙谓。
用邊界對象、控制對象和實體對象實現(xiàn)場景后训桶，我們就得到了分析類圖累驮。

分析類是高層次抽象出系統(tǒng)實現(xiàn)業(yè)務需求的原型，業(yè)務需求通過分析類被邏輯化舵揭，成為可以被計算機理解的語義谤专。分析類抽象層次高于設計實現(xiàn)，高于語言實現(xiàn)午绳，也高于實現(xiàn)方式置侍。
高于設計實現(xiàn)意味著，在為需求考慮系統(tǒng)實現(xiàn)的時候拦焚，可以不理會復雜的設計要求蜡坊，專心地為從需求到實現(xiàn)搭建一座橋梁；
高于語言實現(xiàn)意味著赎败，在為需求考慮系統(tǒng)實現(xiàn)的時候秕衙，可以不理會采用哪一種語言來編寫，而能專注在需求實現(xiàn)上螟够；
高于實現(xiàn)方式意味著灾梦，在為需求考慮系統(tǒng)實現(xiàn)的時候峡钓，可以不考慮采用哪一種具體實現(xiàn)方式妓笙，只需要用一個程序邏輯來完成需求即可。

四能岩、軟件架構和框架
架構設計考慮使用一個軟件層次結構寞宫、一個或多個軟件框架以及連接這些軟件層次和軟件框架之間的接口，將功能性需求和非功能性需求有機結合在一起拉鹃，在進行系統(tǒng)設計之前就充分考慮到了系統(tǒng)各功能部件如何在整個系統(tǒng)內(nèi)安置辈赋。
軟件架構是一種思想，一個系統(tǒng)藍圖膏燕，對軟件結構組成的規(guī)劃和職責設定钥屈。軟件架構的意義就是要將這些可邏輯劃分的部分獨立出來，用約定的接口和協(xié)議將它們有機地結合在一起坝辫，形成職責清晰篷就、結構清楚的軟件架構。
軟件框架是是軟件架構的一種實現(xiàn)近忙，是一個半成品竭业。它通常針對一個軟件架構當中某一個特定的問題提供解決方案和輔助工具智润。

五、分析模型
分析類的推導過程為：
1未辆、通過用例確定了系統(tǒng)需求窟绷；
2、通過用例實現(xiàn)咐柜，得到了系統(tǒng)需求的計算機視角理解兼蜈；
3、規(guī)定了軟件架構拙友，確定了軟件層次饭尝；
4、在每一個軟件層次上決定了適用的軟件框架献宫；
5钥平、分析了用例實現(xiàn)在每個軟件層次上是如何動作的；
6姊途、根據(jù)每個軟件層次上所使用的軟件框架并使用分析類來實現(xiàn)用例涉瘾；
7、綜合各個軟件層次得到的分析類捷兰，形成分析模型立叛；
8、得到實現(xiàn)了系統(tǒng)需求最基本的類和類方法贡茅。

六秘蛇、組件模型
組件是用來容納分析類或設計類的，建立組件的目的是為了將一些類組織在一起完成一組特定的功能顶考。
組件可以看成一種特殊的包赁还，不應當包含實現(xiàn)細節(jié)，只包含服務的接口驹沿，同時只維護調(diào)用服務的實現(xiàn)方式艘策。
組件是可復用的單元。
組件是可獨立變化的單元渊季。
組件是可獨立部署的單元朋蔫。
組件可在軟件架構支持環(huán)境下自由組裝。

七却汉、部署模型
部署模型又稱為實施模型驯妄，它主要的作用就是定義構成應用程序的各個部分在物理結構上的安裝和部署位置。
部署模型與應用程序和運行環(huán)境有關合砂。

（十二）青扔、系統(tǒng)設計

一、系統(tǒng)設計和系統(tǒng)分析的差別
系統(tǒng)分析是在不考慮具體實現(xiàn)語言和實現(xiàn)方式的情況下，將需求在軟件架構和框架下進行的計算機模擬赎懦。
系統(tǒng)分析的目的是確定系統(tǒng)應當做成什么樣的設想雀鹃，而系統(tǒng)設計的目的是將這些設想轉(zhuǎn)化為可實施的步驟。

二励两、設計模型 將分析模型里邊界類黎茎、實體類和控制類根據(jù)所選用的實現(xiàn)語言變成設計類，細化一下已有方法当悔，補充一些類屬性傅瞻，就完成了最基本的設計模型。
如果系統(tǒng)中許多功能具備相似的實現(xiàn)模式盲憎，則沒有必要逐一建立設計模型嗅骄。
為相似的功能建立指導性的設計模型，為復雜和特殊的功能建立設計模型饼疙。

三溺森、接口設計
應當為每一個對象都設計接口，每個接口都對應一個實現(xiàn)類窑眯。
為具有相似行為的對象設計接口屏积，將相同的行為提取出來形成接口。
為軟件各層次設計接口磅甩，各層之間交互過程通過接口完成炊林。

四、包設計
軟件世界分包的應當遵循自頂向下原則卷要、職能集中原則和互補交叉原則渣聚。
自頂向下的原則，分包時要像組織機構一樣僧叉，從頂級包自頂向下延伸奕枝，避免平行化無層次分包。自頂向下的另一個重要含義是下層包不能夠訪問上層包彪标，并且不能夠跨層訪問包倍权，但同層次的包可以互相訪問。

image

職能集中的原則捞烟，分包時盡量將與一組業(yè)務功能有關的類分在同一個包里。

image

互不交叉的原則当船，分包時包與包之間的類盡量獨立题画，不要讓他們產(chǎn)生相互依賴關系。
避免交叉依賴有兩種方法德频，一種是將交叉依賴的類單獨分包苍息；另一種是增加新的類，并單獨分包。

（十三）竞思、在提煉中思考

一表谊、理解用例的本質(zhì)
用例是系統(tǒng)思維
系統(tǒng)是一個封閉的、由一系列相互關聯(lián)盖喷、相互影響的物質(zhì)構成的集合爆办。所謂系統(tǒng)思維，就是考慮系統(tǒng)內(nèi)事物的互相影響课梳，歸納距辆、抽象系統(tǒng)內(nèi)的運行規(guī)律。
軟件不是孤立存在的暮刃，在設計時我們必須將軟件置于它所處的系統(tǒng)環(huán)境中：使用者、硬件、網(wǎng)絡复旬、應用環(huán)境等踪宠，并采用系統(tǒng)思維來分析和設計它。
用例具有系統(tǒng)性：
用例是相對獨立的氧猬；
不存在沒有參與者的用例挫望，用例不應該自動啟動，也不應該主動啟動另一個用例狂窑；
用例的執(zhí)行結果對參與者來說是可觀測的和有意義的媳板；
用例必然是以動賓短語形式出現(xiàn)的。

用例是面向服務的
面向服務架構的第一條準則是：業(yè)務驅(qū)動服務泉哈，服務驅(qū)動技術蛉幸。
SOA的開發(fā)過程與用例的分析過程也有著極高的相似程度。

image

二丛晦、理解用例驅(qū)動
用例與項目管理
在項目管理中奕纫，工作包占據(jù)了非常重要的地位。
在UML里烫沙，系統(tǒng)用例實現(xiàn)就是項目管理中的工作包匹层。
項目管理中，一個工作包的工作量控制在1至2個人周是比較容易控制的锌蓄；在系統(tǒng)用例里升筏，如果工作量大于這個時間，則需要通過用例實現(xiàn)來減少每個工作包的工作量瘸爽。

image

用例與可擴展架構
業(yè)務驅(qū)動技術您访，一個好的可擴展架構是基于好的業(yè)務架構之上的。
業(yè)務架構從用例而來剪决，每個用例定義了參與者對系統(tǒng)的要求灵汪，而業(yè)務系統(tǒng)檀训，則需要將這些相對獨立的業(yè)務單元結合起來，形成更大的業(yè)務享言。
在需要擴展的系統(tǒng)里峻凫，用例與用例之間必須避免緊耦合。
可擴展架構览露，其關鍵就在如何定義每個用例的接口荧琼，以及如何使用是和的技術架構來保證業(yè)務單元之間的交互來提供可擴展能力。
用例不但驅(qū)動軟件過程肛循，也驅(qū)動技術架構铭腕。

三、理解建模的抽象層次
將事物按層次劃分是人們歸納和理解事物的重要形式多糠。
層次不交叉累舷，在描述事物的過程中，同一層的描述內(nèi)容是“等值”的夹孔。
在進行分析設計之前被盈，應當根據(jù)業(yè)務的復雜程度事先決定需要用多少個抽象層次來描述，并定義每個抽象層次要解決的業(yè)務問題搭伤，或者說定義每個抽象層次的關鍵特征只怎。
UML建模是以用例為基礎的，用例的粒度則和抽象層次直接相關怜俐，

四身堡、劃分子系統(tǒng)的問題
計算機子系統(tǒng)描述了一個軟件的內(nèi)部構成，它的劃分依據(jù)是對象依賴拍鲤，目標是構建擴展下好的軟件結構贴谎；
業(yè)務子系統(tǒng)描述的是軟件的展現(xiàn)形式，以用戶部門或者業(yè)務為依據(jù)進行劃分季稳。
用戶所謂的子系統(tǒng)擅这，只是軟件展示出來的樣子，從面向?qū)ο蟮挠^點來看景鼠，軟件內(nèi)部應當維持最佳的對象結構仲翎，然后通過接口向外部展現(xiàn)外部所需要的樣子。

image

五铛漓、學會使用系統(tǒng)邊界
對象是由邊界來“封裝”的溯香，接口正是邊界的體現(xiàn)。
描述系統(tǒng)時候票渠，邊界用來定義系統(tǒng)的范圍逐哈，因為系統(tǒng)是由用例表示的，系統(tǒng)邊界由用例構成问顷。
描述用例時候昂秃，邊界類是用例與外界的唯一通道，邊界類“封裝”了用例杜窄，用例邊界由邊界類來決定肠骆。
描述對象時候，對象封裝的結果是出現(xiàn)了一組接口方法塞耕，對象的邊界由這邊接口方法約束蚀腿。

根據(jù)系統(tǒng)的復雜程度、業(yè)務需求規(guī)模大小決定用例的粒度扫外，用邊界分析的方法可以幫助確定用例的粒度莉钙。
邊界分析的方法主要有兩種：一種是根據(jù)業(yè)務從整體到局部；另一種是按照人邊界和物邊界進行劃分筛谚。

采用邊界分析方法進行分析磁玉，可以得到封裝度極好、接口處清晰明了驾讲、抽象層次井然有序的分析結果蚊伞。

六、學會從接口認識事物
人們認知現(xiàn)實世界和認識軟件的過程是一致的吮铭，是從接口（表象）來認識對象而不是從對象內(nèi)部（本質(zhì)）來認識對象的时迫。
將邊界分析得到的結果中，每個邊界都用接口來替代谓晌，就可以確定整個系統(tǒng)行為掠拳。

七、學會正確選擇
一個系統(tǒng)有多個涉眾纸肉，也有多個指標溺欧，所以對系統(tǒng)有多種期望和多個要求。所以即使在明確的期望和要求下毁靶，也需要變換立場來審視問題胧奔，做出取舍和平衡，得出最合理的設計预吆。
此時可以用SWTO分析方法來進行判斷龙填。
S：stretch（優(yōu)點）
W：weakness（缺點）
T：threat（威脅）
O： opportunity（機會）

image

image

在需求分析和設計過程中，我們也需要改變立場來獲得對需求更為深入的理解拐叉。
在需求分析中過程岩遗，我們還可以多次變換視角，通過邊界的改變得出不同參與者與不同用例凤瘦。

八宿礁、學會使用設計模式
設計模式是面向?qū)ο笤O計原則和方法的應用，是在具體實踐過程中解決某類問題而產(chǎn)生的經(jīng)驗總結和最佳實踐蔬芥。
要使用好的設計模式首先要打好基礎梆靖，即你已經(jīng)完全掌握了設計模式的意圖和適用性控汉。