《Thinking in UML》學(xué)習(xí)總結(jié)

@(總結(jié))[思考|學(xué)習(xí)|記錄](méi)

@[toc]

簡(jiǎn)要

最近看完了這本書(shū)髓棋，感覺(jué)還是很有內(nèi)容的告材，從面向過(guò)程到面向?qū)ο笳秤牛瑥默F(xiàn)實(shí)世界到計(jì)算機(jī)軟件闹获，不僅講述了方法敛瓷，同時(shí)還帶給我一種做軟件的思想学赛，當(dāng)我有了這種思想后年堆，也常常會(huì)用到生活的其他領(lǐng)域中，比如邊界這種思想盏浇”渖ィ總而言之，這本書(shū)值得一看缠捌，而且還得多看幾遍才能明白其中的方方面面锄贷。

面向過(guò)程和面向?qū)ο?/h2>

面向過(guò)程和面向?qū)ο蠖际鞘菍?duì)世界的認(rèn)識(shí)方式，只是角度不一樣曼月。

面向過(guò)程

• 定義： 面向過(guò)程認(rèn)為世界是由一個(gè)個(gè)關(guān)聯(lián)的小系統(tǒng)構(gòu)成谊却，這些小系統(tǒng)有著明確的開(kāi)始和結(jié)束，而且開(kāi)始和結(jié)束之間有著嚴(yán)謹(jǐn)?shù)囊蚬P(guān)系哑芹，既然如此炎辨，當(dāng)我們分析出小系統(tǒng)的每個(gè)步驟和影響這個(gè)系統(tǒng)的走向的因素，就可以完全定義這個(gè)系統(tǒng)聪姿。
• 分析方法： 找到開(kāi)始碴萧，然后順藤摸瓜，分析每一個(gè)步驟末购，直到結(jié)束破喻。每一個(gè)步驟都是不可或缺的。這種方法在我們學(xué)習(xí)一個(gè)東西的時(shí)候會(huì)經(jīng)常用到盟榴。
• 缺點(diǎn)： 本身蘊(yùn)含著一個(gè)前提假設(shè)曹质，就是這個(gè)系統(tǒng)是穩(wěn)定的，所有的工作成果都依賴于這個(gè)過(guò)程的步步分析∮鸬拢看看這個(gè)定義和方法几莽，就可以看到如果要分析的東西很復(fù)雜，邏輯很亂的話宅静，要去順藤摸瓜章蚣，一步一步去分析，是很困難的姨夹。

面向?qū)ο?/h3>

• 定義： 面向?qū)ο笳J(rèn)為世界是由一個(gè)個(gè)相互獨(dú)立的對(duì)象組成纤垂，這些對(duì)象之間并無(wú)因果關(guān)系，只有在某個(gè)外部力量作用下匀伏，這些對(duì)象才會(huì)依據(jù)某種規(guī)律相互傳遞信息洒忧，這些交互構(gòu)成了生動(dòng)世界的一個(gè)“過(guò)程”蝴韭。
• 分析方法： 通過(guò)uml建模來(lái)分析够颠。
• 缺點(diǎn)： 現(xiàn)實(shí)世界和對(duì)象世界存在差距，這個(gè)差距很難跨越榄鉴，如果需要跨過(guò)這道鴻溝履磨，就需要解決三個(gè)問(wèn)題：如何從現(xiàn)實(shí)世界映射到對(duì)象世界？如何在對(duì)象世界中描述現(xiàn)實(shí)世界庆尘？如何驗(yàn)證對(duì)象世界是否正確描述了現(xiàn)實(shí)世界剃诅？
  
  1.9.png

建模公式

2.1.png

• 問(wèn)題領(lǐng)域是由多個(gè)抽象角度組合的，比如筷子和勺子的區(qū)別是什么驶忌？就可以從形狀矛辕、用途等抽象角度去分析這個(gè)問(wèn)題。就不用去全盤(pán)考慮一個(gè)問(wèn)題付魔，全盤(pán)考慮不僅考慮了事物聊品，也把事物之間的關(guān)系也考慮進(jìn)去了，所以會(huì)不斷地在做平衡几苍。而從多個(gè)抽象角度去分析翻屈，就是把問(wèn)題領(lǐng)域分成多個(gè)細(xì)小的問(wèn)題，最后組合起來(lái)就可以了妻坝，它是先考慮事物伸眶，然后再來(lái)考慮關(guān)系，這樣會(huì)比較輕松點(diǎn)刽宪。
• 人厘贼、事、物圣拄、規(guī)則在建模過(guò)程中是常見(jiàn)的嘴秸，這也是去模擬現(xiàn)實(shí)世界，在什么條件下要達(dá)到什么目的，看起來(lái)比較簡(jiǎn)單的事赁遗。

用例驅(qū)動(dòng)

• 軟件的開(kāi)發(fā)可以通過(guò)用例來(lái)驅(qū)動(dòng)署辉，用例是一個(gè)抽象的結(jié)果，也就是問(wèn)題領(lǐng)域的一個(gè)描述角度岩四，要解決一個(gè)問(wèn)題哭尝，只要找到這個(gè)問(wèn)題領(lǐng)域的所有必要的用例就相當(dāng)于近似找到了這個(gè)問(wèn)題的解，也就是從過(guò)個(gè)角度去描述問(wèn)題剖煌，從多個(gè)角度去抽象問(wèn)題材鹦。
• 當(dāng)找到了用例后，要做的就是實(shí)現(xiàn)這個(gè)用例耕姊，也就是為這個(gè)用例提供用例場(chǎng)景桶唐，在確定用例場(chǎng)景的過(guò)程中，可以找到要實(shí)現(xiàn)這個(gè)用例所需要的人茉兰、事尤泽、物、規(guī)則规脸，如果找到了坯约，那么問(wèn)題的一個(gè)抽象角度就完成了，這個(gè)問(wèn)題就解決了一部分莫鸭，不考慮設(shè)計(jì)的話闹丐，應(yīng)該就可以直接編碼了，現(xiàn)在開(kāi)發(fā)java web應(yīng)用有mvc的模式被因，正好對(duì)應(yīng)著這四要素：人->發(fā)請(qǐng)求的用戶卿拴，事->view，視圖層梨与，這個(gè)視圖層不是純粹的幾張頁(yè)面啊堕花，而是相對(duì)于用戶來(lái)說(shuō)，看到的一個(gè)應(yīng)用的整體蛋欣，只不過(guò)實(shí)際能看到的只是用戶交互的頁(yè)面航徙，所以視圖層可以當(dāng)做是應(yīng)用的邊界，物->model層陷虎，就是實(shí)體了到踏，規(guī)則->controller層，就是控制層了尚猿；這些確定后呢窝稿，以目前的工作經(jīng)驗(yàn)來(lái)說(shuō)，就可以實(shí)現(xiàn)功能了凿掂。
• 當(dāng)對(duì)每個(gè)用例都實(shí)現(xiàn)后伴榔，就會(huì)產(chǎn)生很多這樣的人纹蝴、事、物踪少、規(guī)則塘安，為了代碼的規(guī)范呢，就會(huì)對(duì)這些元素合并的合并援奢，刪除的刪除兼犯，拆分的拆分，但是用例還是不變集漾。

抽象層次

• 抽象層次越高的東西切黔，就越容易理解和處理，因?yàn)槠帘蔚男畔⒃蕉嗑咂畔⒘吭缴傥诚肌２⒉皇窃骄唧w的東西越容易理解，具體事物如樹(shù)葉驱显、手機(jī)诗芜，要具體描述一片樹(shù)葉是不是要用專業(yè)的生物學(xué)術(shù)語(yǔ)，由什么細(xì)胞組成秒紧、葉綠素绢陌、表皮組織等等挨下，一般人看到這樣的描述是云里霧里的熔恢，還不如說(shuō)這片葉子顏色是什么，形狀如何等等臭笆，這些描述也要用抽象的詞語(yǔ)去描述才行叙淌，不能把顏色說(shuō)成是由紅黃綠三種顏色按什么比例去組合，誰(shuí)知道組合后是什么顏色愁铺，我們的大腦又不是機(jī)器能記住這么多組合鹰霍，只能說(shuō)紅色，然后就會(huì)想到茵乱，像五星紅旗那種顏色茂洒，這樣就可以理解了。
• 抽象有兩種方法瓶竭，一種是自頂向下督勺，一種是自底向上。自頂向下適合從頭開(kāi)始了解一個(gè)新的事物斤贰，自底向上適合在實(shí)踐中去改進(jìn)事物智哀。在軟件開(kāi)發(fā)中，主體應(yīng)該采用自頂向下的方法荧恍，開(kāi)始用少量的概念去覆蓋需求瓷叫，再逐步降低抽象層次，直到編碼。同時(shí)輔以自底向上的方法摹菠，通過(guò)總結(jié)在較低抽象層次的實(shí)踐經(jīng)驗(yàn)來(lái)改進(jìn)較高層次的概念來(lái)提升軟件質(zhì)量盒卸。
• 那么建模過(guò)程中，應(yīng)該在什么時(shí)候選擇什么樣的抽象層次次氨，以及總共要抽象多少層次世落，也就是說(shuō)用例要選擇一個(gè)怎樣的粒度，這是一個(gè)問(wèn)題糟需。

視圖

• 首先視圖是用來(lái)干什么的需要知道屉佳，建模的目的是為了向軟件相關(guān)人展示將要生產(chǎn)的軟件產(chǎn)品，通過(guò)什么來(lái)展示呢洲押，視圖是一個(gè)很好的方法武花，不同的視圖可以展示軟件的不同方面，靜態(tài)的杈帐、動(dòng)態(tài)的体箕、結(jié)構(gòu)性的、邏輯性的等等挑童，然后uml建模中就有對(duì)應(yīng)的用例圖累铅、對(duì)象圖、類(lèi)圖站叼、包圖娃兽、活動(dòng)圖等。
• 在給軟件相關(guān)人展示軟件的方方面面時(shí)尽楔，需要注意選擇的視角是否合適投储，也就是被展示的人在他的所處環(huán)境中是否看到了他應(yīng)該看到的東西，也就是視角要選對(duì)阔馋，比如針對(duì)業(yè)務(wù)員玛荞，他可能只關(guān)心表單的填寫(xiě)，對(duì)經(jīng)理呕寝，他會(huì)關(guān)心整個(gè)業(yè)務(wù)的流程勋眯，對(duì)程序員，他關(guān)心業(yè)務(wù)的流程和類(lèi)的設(shè)計(jì)下梢。

對(duì)象分析的方法

• 獨(dú)立性客蹋。對(duì)象之間是互相獨(dú)立的。對(duì)象是在實(shí)現(xiàn)用例怔球，也就是在確定用例場(chǎng)景時(shí)找到的嚼酝，但是找到的一切有名字的事物，也就是對(duì)象竟坛，它們都不應(yīng)該是和這個(gè)場(chǎng)景綁定的钧舌，換句話說(shuō)洼冻，對(duì)象是離散的撞牢，即使是這個(gè)場(chǎng)景中得到的屋彪，也不過(guò)是對(duì)象在這個(gè)場(chǎng)景的映射（這讓我想到線性空間里映射）绒尊，所以在建模過(guò)程中婴谱，要想深入了解對(duì)象蟹但，就需要分析很多該對(duì)象的實(shí)例參與的場(chǎng)景，以獲得該對(duì)象的諸多側(cè)面信息谭羔，然后通過(guò)歸納整理這些側(cè)面信息抽象出對(duì)象的一般特性华糖。這就是對(duì)象分析的方法。有項(xiàng)目經(jīng)驗(yàn)的人在做過(guò)很多項(xiàng)目后瘟裸，看到許多相似的對(duì)象或者函數(shù)客叉，就會(huì)產(chǎn)生強(qiáng)烈的把它們公共化的思想，這就是抽象的原動(dòng)力景描，當(dāng)然在寫(xiě)代碼的時(shí)候十办，也會(huì)有這樣的想法。獨(dú)立性帶來(lái)的正是正是對(duì)象的可抽象能力和可擴(kuò)展能力超棺。
• 原子性。在統(tǒng)一抽象層次上呵燕，對(duì)象是不可再分的棠绘，所以對(duì)于各個(gè)對(duì)象的認(rèn)識(shí)應(yīng)該附加上在對(duì)象的邊界上，而不應(yīng)該去關(guān)注對(duì)象的內(nèi)部細(xì)節(jié)再扭。這就是面向接口編程氧苍。
• 抽象性。對(duì)象是可抽象的泛范。對(duì)象是具有多個(gè)方面的，每個(gè)方面都對(duì)應(yīng)著一個(gè)場(chǎng)景赡突，因?yàn)閷?duì)象的總是從場(chǎng)景中分析得來(lái)的浪南，它在場(chǎng)景中肯定展現(xiàn)了它的一個(gè)方面⌒跫牵總可以將對(duì)象的某一方面抽象出來(lái)，讓其作為對(duì)象的一個(gè)代表在場(chǎng)景中交互憔四。通常這種抽象會(huì)以接口來(lái)命名甸赃。在spring源碼中络断，有很多接口，各種實(shí)現(xiàn)錯(cuò)綜復(fù)雜锥惋，之所以會(huì)這樣那樣的實(shí)現(xiàn)接口，就是因?yàn)樵O(shè)計(jì)者的思想里有這種對(duì)象是可抽象的概念，一個(gè)對(duì)象從無(wú)到有丛忆，一直實(shí)現(xiàn)接口座哩，一直獲得各種能力，這是對(duì)抽象性概念的應(yīng)用屿良。
• 層次性。對(duì)象是具有層次性的。層次越高贰逾，描述越粗略，適用性越廣言缤，層次越低，描述越具體哮独，使用性也窄分飞。這需要根據(jù)問(wèn)題的復(fù)雜性來(lái)分層次讯檐，復(fù)雜的問(wèn)題自然層次分的多一點(diǎn)才好理解。

獲取需求

定義邊界

• 之所以要定義邊界挖垛，是因?yàn)橐@取業(yè)務(wù)用例。軟件剛開(kāi)始時(shí)，是一團(tuán)迷霧凭舶。

  
  
  3.14.png

• 怎樣定義呢钥顽？可以根據(jù)業(yè)務(wù)目標(biāo)來(lái)定義闽铐。拿用電客戶服務(wù)來(lái)舉例：

  
  
  9.2.png
  
  

  該業(yè)務(wù)目標(biāo)是“為用電客戶提供業(yè)務(wù)辦理自動(dòng)化服務(wù)澳叉，提高辦事效率五督，方便客戶，為客戶提供更好的服務(wù)”淆储，配上這張圖就可以看出業(yè)務(wù)主角是誰(shuí)了，我們認(rèn)為邊界外面的才是業(yè)務(wù)主角点额，而邊界內(nèi)的只能算是業(yè)務(wù)工人，他們是不能提供用例的，只能是用電客戶有資格提出用例珠十，也就是提出他們的期望焙蹭，用電客戶希望可以辦理業(yè)務(wù)和交費(fèi)，那用例就是如此了，邊界內(nèi)的那些部門(mén)所做的事情都是為了滿足這兩個(gè)需求拼余；到了這里呢，我們通過(guò)這次的邊界定義獲得了一個(gè)大概印象亭姥，可以為我們獲取用例奠定基礎(chǔ)。接下來(lái)再看一個(gè)邊界绍载，根據(jù)另外一個(gè)業(yè)務(wù)目標(biāo)定義的，每一個(gè)業(yè)務(wù)目標(biāo)都有一個(gè)邊界存在阳谍。

  
  
  9.3.png
  
  可以看到剛剛的業(yè)務(wù)工人搖身一變成了業(yè)務(wù)主角了，然后呢，就可以在這個(gè)業(yè)務(wù)目標(biāo)下獲得一些用例递沪。

業(yè)務(wù)用例必須是以達(dá)到業(yè)務(wù)主角的完整業(yè)務(wù)目標(biāo)為標(biāo)準(zhǔn)，而不能以實(shí)現(xiàn)業(yè)務(wù)主角業(yè)務(wù)目標(biāo)的步驟為標(biāo)準(zhǔn)檩奠。

發(fā)現(xiàn)主角

9.2.1.png

9.5.png

業(yè)務(wù)主角區(qū)別于系統(tǒng)參與者，系統(tǒng)參與者是系統(tǒng)的實(shí)際操作者，通常都有id悔捶，而業(yè)務(wù)主角是用來(lái)分析業(yè)務(wù)的，而業(yè)務(wù)的分析界都是要與客戶交流并達(dá)成共識(shí)的堂淡。因此業(yè)務(wù)主角不應(yīng)當(dāng)被過(guò)分地抽象化和虛擬化，應(yīng)當(dāng)能能夠映射到現(xiàn)實(shí)業(yè)務(wù)中的工作崗位設(shè)置、工作職責(zé)說(shuō)明等祭务，并且使用客戶習(xí)慣的業(yè)務(wù)術(shù)語(yǔ)來(lái)命名。

獲取業(yè)務(wù)用例

邊界定義好了拌倍，業(yè)務(wù)主角找好了找爱，就是獲取業(yè)務(wù)用例的時(shí)候了寺谤，該怎么獲取呢？可以從崗位手冊(cè)泵琳、業(yè)務(wù)流程指南蛔垢、職務(wù)說(shuō)明等一些文件獲得，還有一種很重要的方法艺玲，就是業(yè)務(wù)主角訪談搁拙。通忱业猓可以問(wèn)如下問(wèn)題：

• 您對(duì)系統(tǒng)有什么期望字柠？
• 您打算在這個(gè)系統(tǒng)里做些什么事情？
• 您做這件事的目的是什么节槐？

• 您做完這件事希望有一個(gè)什么樣的結(jié)果？

  
  
  9.7.png

9.8.png

9.9.png

在定義邊界時(shí)沃测，可以看到業(yè)務(wù)主角的業(yè)務(wù)目標(biāo)食茎，從目標(biāo)上看只能得到一個(gè)大概的用例蒂破，然而業(yè)務(wù)主角需要做什么具體的事情并不清楚，這就要通過(guò)各種方式去尋找業(yè)務(wù)具體想做的事情是什么别渔。

業(yè)務(wù)建模

一個(gè)完整的業(yè)務(wù)模型包括：

• 業(yè)務(wù)用例視圖
• 業(yè)務(wù)用例場(chǎng)景
• 業(yè)務(wù)用例規(guī)約
• 業(yè)務(wù)規(guī)則
• 業(yè)務(wù)對(duì)象模型
• 業(yè)務(wù)用例實(shí)現(xiàn)視圖
• 業(yè)務(wù)用例實(shí)現(xiàn)場(chǎng)景
• 包圖
  當(dāng)然在實(shí)際開(kāi)發(fā)中附迷，并不要做這么全面，只要能做到理解業(yè)務(wù)就可以了哎媚。

業(yè)務(wù)用例場(chǎng)景

場(chǎng)景是說(shuō)某個(gè)業(yè)務(wù)用例的實(shí)際實(shí)現(xiàn)過(guò)程秋度，包括涉及的步驟纸颜、經(jīng)過(guò)哪些角色處理、出現(xiàn)問(wèn)題怎么辦等等周霉。
業(yè)務(wù)用例的視圖之前說(shuō)過(guò)峡懈，但是業(yè)務(wù)用例場(chǎng)景的視圖怎么表示呢雾狈？
有三種：

• 活動(dòng)圖
• 時(shí)序圖

• 協(xié)作圖

  
  
  9.14.png

如果想強(qiáng)調(diào)參與該業(yè)務(wù)的各參與者的職責(zé)和活動(dòng)绞愚，可以選擇活動(dòng)圖遂赠；如果想強(qiáng)調(diào)該業(yè)務(wù)的完成時(shí)間順序，并且在完成的過(guò)程中傳遞的信息是什么，可以選擇時(shí)序圖授药；如果想強(qiáng)調(diào)參與該業(yè)務(wù)的各參與者之間的交互過(guò)程，可以選擇協(xié)作圖览濒。

業(yè)務(wù)用例規(guī)約

規(guī)約是對(duì)場(chǎng)景視圖的文字描述改基，其中的過(guò)程描述可以認(rèn)為是活動(dòng)圖的文字版，因?yàn)槲淖置枋鰜?lái)得嚴(yán)謹(jǐn)，所以用例規(guī)約還是必要的臀稚，寧可省略活動(dòng)圖，也不要去省略用例規(guī)約缰泡，不然看著圖去開(kāi)發(fā)革屠，理解會(huì)有不同吐咳，不如白紙黑字寫(xiě)的清楚。

9.1.table.png

業(yè)務(wù)規(guī)則

如果業(yè)務(wù)規(guī)則只用于一個(gè)用例，直接寫(xiě)在規(guī)約里就可以类垦，如果用于多個(gè)用例挚冤，就要編寫(xiě)專門(mén)的業(yè)務(wù)規(guī)則文檔绸狐。

業(yè)務(wù)對(duì)象模型

業(yè)務(wù)對(duì)象模型就是對(duì)業(yè)務(wù)場(chǎng)景中涉及到的一些業(yè)務(wù)實(shí)體建模卤恳。

業(yè)務(wù)用例實(shí)現(xiàn)視圖

一個(gè)業(yè)務(wù)用例可能有不同的實(shí)現(xiàn)，也就是有不同的場(chǎng)景寒矿，即實(shí)現(xiàn)方式不同突琳。如：

9.15.png

一般一個(gè)業(yè)務(wù)用例實(shí)現(xiàn)對(duì)應(yīng)著一個(gè)業(yè)務(wù)用例場(chǎng)景。

業(yè)務(wù)用例實(shí)現(xiàn)場(chǎng)景

業(yè)務(wù)用例實(shí)現(xiàn)場(chǎng)景的建模方式和業(yè)務(wù)用例場(chǎng)景的建模方式有點(diǎn)差別符相。用例場(chǎng)景著重表示業(yè)務(wù)是怎樣執(zhí)行的拆融，并沒(méi)有去描述這些執(zhí)行步驟是如何實(shí)現(xiàn)的，而用例實(shí)現(xiàn)場(chǎng)景就是著重描述步驟是如何實(shí)現(xiàn)的啊终，是如何通過(guò)人機(jī)交互來(lái)完成業(yè)務(wù)的镜豹。

9.16.png

如果說(shuō)業(yè)務(wù)用例場(chǎng)景是跟客戶就業(yè)務(wù)達(dá)成共識(shí)，那么業(yè)務(wù)用例實(shí)現(xiàn)場(chǎng)景就是跟客戶就如何操作達(dá)成共識(shí)蓝牲。

包圖

包是用來(lái)分類(lèi)元素的趟脂。業(yè)務(wù)建模中，包圖更多用于信息分類(lèi)例衍。例如將業(yè)務(wù)用例分類(lèi)昔期，將參與者分類(lèi)，因此更多地采用領(lǐng)域包的版型佛玄，領(lǐng)域包就是根據(jù)業(yè)務(wù)的不同來(lái)定義的一種分包方式硼一。

9.17.png

但是分包還有按業(yè)務(wù)部門(mén)分、按業(yè)務(wù)過(guò)程分等等梦抢。

領(lǐng)域模型

• 首先解釋下領(lǐng)域是什么意思般贼。

在解決問(wèn)題的時(shí)候，我們通常會(huì)分解一個(gè)大問(wèn)題奥吩，得到很多個(gè)小問(wèn)題具伍，而這些小問(wèn)題是相互獨(dú)立的，那么每個(gè)小問(wèn)題是可以叫做一個(gè)領(lǐng)域的圈驼。

• 它和業(yè)務(wù)用例模型有什么區(qū)別呢？

在建模的方式上望几，還是有很所不同的绩脆，業(yè)務(wù)用例建模針對(duì)的是業(yè)務(wù)目標(biāo)來(lái)建模，確定一個(gè)業(yè)務(wù)用例是從人做事的角度，說(shuō)明一個(gè)業(yè)務(wù)目標(biāo)是由哪些人做哪些事來(lái)構(gòu)成的靴迫；領(lǐng)域建模是針對(duì)一個(gè)整體提出許多關(guān)心的問(wèn)題惕味，再針對(duì)每個(gè)問(wèn)題求解。這些問(wèn)題不會(huì)覆蓋所有的業(yè)務(wù)范圍玉锌，相互之間也沒(méi)什么因果關(guān)系名挥。

• 為什么需要領(lǐng)域模型呢？

首先主守，用例分析方法是有缺陷的禀倔，它能很好地說(shuō)一個(gè)系統(tǒng)的功能性需求，從什么人做什么事的角度來(lái)將系統(tǒng)定義清楚参淫，但是它忽略了一些關(guān)聯(lián)性的問(wèn)題救湖。
從需求上來(lái)說(shuō)待秃，通過(guò)用例分析獲得的用例一般都是相互獨(dú)立的齐媒，但從系統(tǒng)的角度來(lái)說(shuō)梧乘，有些問(wèn)題是跨多個(gè)用例的艾船。單個(gè)用例場(chǎng)景有時(shí)是無(wú)法描述一個(gè)問(wèn)題的惹悄。領(lǐng)域模型就可以處理這種情況畦戒，提出一個(gè)問(wèn)題季俩，然后求解昼蛀，在求解的過(guò)程中借用用例模型棕兼，將獨(dú)立的用例場(chǎng)景通過(guò)問(wèn)題串在一起將其“系統(tǒng)化”陡舅。
其次就是用例分析方法只能分析功能性需求，特別適合交互密集的需求程储。對(duì)于非功能性需求和計(jì)算密集型的需求則顯得很為難蹭沛。例如，用戶有一個(gè)需求是用戶界面可以個(gè)性化章鲤，這是一個(gè)非功能性需求摊灭，這時(shí)使用用例分析方法是很難分析的，但是如果把它轉(zhuǎn)化成一個(gè)領(lǐng)域模型來(lái)看败徊，得到結(jié)果可能是一個(gè)portal解決方案帚呼，這樣問(wèn)題領(lǐng)域就轉(zhuǎn)化成技術(shù)選型的問(wèn)題了。

• 領(lǐng)域模型的作用是什么皱蹦？

在軟件開(kāi)發(fā)過(guò)程中煤杀，通常有一個(gè)疑惑，就是需求轉(zhuǎn)到設(shè)計(jì)這層總是不好把握沪哺，總覺(jué)得沒(méi)有根據(jù)沈自，心里沒(méi)底。在這方面除了分析模型可以處理辜妓，領(lǐng)域模型也可以幫助到枯途。
領(lǐng)域模型對(duì)系統(tǒng)的架構(gòu)和框架的建立可以起到指導(dǎo)作用忌怎。例如我們可以針對(duì)事務(wù)處理、日志處理酪夷、消息機(jī)制榴啸、編程模型建立領(lǐng)域模型，然后就可以吧業(yè)務(wù)對(duì)象和事務(wù)晚岭、日志這些屬于架構(gòu)和框架范圍的東西結(jié)合起來(lái)鸥印。
有時(shí)候業(yè)務(wù)對(duì)象到設(shè)計(jì)類(lèi)是有一定差距的，這就需要有一定的范式或指導(dǎo)來(lái)幫助進(jìn)行這種轉(zhuǎn)化坦报。分析類(lèi)是有效的過(guò)渡類(lèi)型库说，但是由于分析類(lèi)是由用例推導(dǎo)出來(lái)的，同樣是不能描述非功能性需求燎竖，也不能表達(dá)跨用例的問(wèn)題璃弄。但如果對(duì)這個(gè)問(wèn)題建立領(lǐng)域模型，就可以得到業(yè)務(wù)對(duì)象是由哪些領(lǐng)域類(lèi)組成构回，在項(xiàng)目的早期能知道業(yè)務(wù)對(duì)象的關(guān)系夏块，對(duì)于設(shè)計(jì)類(lèi)來(lái)說(shuō)是很有幫助的，起碼知道在設(shè)計(jì)類(lèi)時(shí)哪些東西是必要的纤掸。

• 什么時(shí)候需要建立領(lǐng)域模型呢脐供？

簡(jiǎn)單需求無(wú)需建立。
對(duì)核心業(yè)務(wù)建立借跪。
針對(duì)難點(diǎn)建立政己。
關(guān)注非功能性需求。

• 建立領(lǐng)域模型的步驟是什么掏愁？

提出領(lǐng)域問(wèn)題

• 就是對(duì)需要建模的核心業(yè)務(wù)或者其他提出問(wèn)題歇由，這些問(wèn)題可能來(lái)自于企業(yè)的各個(gè)部門(mén)或者其他

  
  
  9.18.png

分析領(lǐng)域問(wèn)題

• 對(duì)每一個(gè)問(wèn)題通過(guò)和它有關(guān)的業(yè)務(wù)用例場(chǎng)景圖來(lái)分析，得到業(yè)務(wù)對(duì)象模型果港。

  
  
  9.19.png

• 得到問(wèn)題領(lǐng)域變量

  
  
  9.20.png

建立領(lǐng)域模型

• 上述的問(wèn)題領(lǐng)域變量就是領(lǐng)域模型的基本構(gòu)成了沦泌。但是還不一定是最終的結(jié)果，在后續(xù)的開(kāi)發(fā)過(guò)程中辛掠，隨著業(yè)務(wù)的深入谢谦，可以增加、減少萝衩、合并這些變量回挽。

  
  
  9.21.png

驗(yàn)證領(lǐng)域模型

• 和業(yè)務(wù)用例模型一樣，領(lǐng)域模型也分靜態(tài)模型和動(dòng)態(tài)模型猩谊。為了驗(yàn)證得到的領(lǐng)域模型是否是滿足業(yè)務(wù)要求千劈，可以把這些領(lǐng)域?qū)ο蟠氲礁鱾€(gè)業(yè)務(wù)用例模型中，看是否符合要求牌捷。

  
  
  9.23.png

提取業(yè)務(wù)規(guī)則

• 業(yè)務(wù)規(guī)則主要分三類(lèi)：全局規(guī)則墙牌，交互規(guī)則袁梗，內(nèi)稟規(guī)則。

• 全局規(guī)則是適用于系統(tǒng)大部分業(yè)務(wù)或系統(tǒng)設(shè)計(jì)的憔古，是跨用例的規(guī)則。全局規(guī)則是與用例無(wú)關(guān)的淋袖，是和系統(tǒng)具備的特性相關(guān)的鸿市。實(shí)際上，通常如授權(quán)即碗、備份焰情、事務(wù)等特性都是由系統(tǒng)框架去實(shí)現(xiàn)的，并不會(huì)分散到具體的功能中單獨(dú)去實(shí)現(xiàn)它們剥懒。AOP模式就是試圖將全局規(guī)則從業(yè)務(wù)邏輯當(dāng)中剝離出來(lái)的一種編程模型内舟。

  
  
  9.2.table.png

• 交互規(guī)則是產(chǎn)生于用例場(chǎng)景中，通常這部分規(guī)則是最復(fù)雜初橘，也最不穩(wěn)定验游。大家所說(shuō)的需求經(jīng)常變更相信絕大部分就來(lái)自于此。如果需求無(wú)可避免地變更保檐，那么將交互規(guī)則單獨(dú)提取出來(lái)耕蝉，通盤(pán)考慮并設(shè)計(jì)成為擴(kuò)展性較強(qiáng)的結(jié)構(gòu)就是一種有效的應(yīng)對(duì)手段。在應(yīng)付交互規(guī)則時(shí)夜只，我們可以采用很多設(shè)計(jì)模式來(lái)保證擴(kuò)展性垒在。應(yīng)用設(shè)計(jì)模式最重要的一點(diǎn)就是弄明白設(shè)計(jì)模式的意圖和應(yīng)用條件，交互規(guī)則恰恰提供了這些信息扔亥，我們就可以針對(duì)交互規(guī)則來(lái)決定是否應(yīng)當(dāng)采用某個(gè)設(shè)計(jì)模式场躯。

• 內(nèi)稟規(guī)則是指那些業(yè)務(wù)對(duì)象本身自有的。比如電話號(hào)碼的位數(shù)旅挤、身份證的位數(shù)踢关。通常寫(xiě)在業(yè)務(wù)對(duì)象描述文檔中。如：

  
  
  9.3.table.png

獲取非功能性需求

• 如何獲得非功能性需求呢谦铃？說(shuō)簡(jiǎn)單也簡(jiǎn)單耘成，說(shuō)復(fù)雜也復(fù)雜。簡(jiǎn)單是因?yàn)榉枪δ苄孕枨罂偸潜容^固定的幾個(gè)范圍驹闰，完全可以通過(guò)固定的程序一個(gè)一個(gè)收集整理瘪菌。說(shuō)復(fù)雜是因?yàn)殡S著軟件規(guī)模的不斷擴(kuò)大和應(yīng)用環(huán)境的日趨復(fù)雜，要確定的非功能性需求指標(biāo)需要考慮越來(lái)越多的因素嘹朗。非功能性需求主要圍繞下面幾個(gè)方面展開(kāi)：
• 可靠性：安全性师妙、事務(wù)性和穩(wěn)定性。

• 獲取安全性需求時(shí)屹培，應(yīng)該充分考慮業(yè)務(wù)內(nèi)容和應(yīng)用環(huán)境默穴。
• 事務(wù)性就是保障系統(tǒng)的ACID能力怔檩。
• 穩(wěn)定性由故障的頻率、嚴(yán)重性蓄诽、可恢復(fù)性薛训、可預(yù)見(jiàn)性、準(zhǔn)確性和平均故障間隔時(shí)間（MTBF）等一些指標(biāo)構(gòu)成仑氛。

• 可用性：是用來(lái)衡量人們對(duì)軟件產(chǎn)品的滿意程度乙埃。

• 容易學(xué)習(xí)。
• 使用效率：客戶需要多長(zhǎng)時(shí)間锯岖、執(zhí)行多少操作才能完成一個(gè)關(guān)鍵任務(wù)介袜？
• 記憶性：當(dāng)客戶離開(kāi)再次回來(lái)工作時(shí)，他的工作是否能記憶下來(lái)以便繼續(xù)工作出吹？
• 錯(cuò)誤恢復(fù)：當(dāng)系統(tǒng)出現(xiàn)故障時(shí)遇伞，客戶是否能夠從故障中恢復(fù)他已經(jīng)完成的工作？
• 主觀滿意度捶牢。
• 人員因素：軟件是否遵循了以用戶為中心的設(shè)計(jì)方式鸠珠。例如，界面布局是否符合客戶的操作習(xí)慣叫确；操作是否沿用了客戶認(rèn)同的術(shù)語(yǔ)跳芳；操作方式是否與客戶的工作習(xí)慣相符等。
• 美觀竹勉。
• 用戶界面的一致性：軟件是否能帶給用戶一致的操作體驗(yàn)飞盆。不一致的比如要跳到下一個(gè)界面，有的地方要點(diǎn)擊菜單次乓，有的地方要點(diǎn)擊按鈕吓歇，有的地方要點(diǎn)擊超鏈接。
• 聯(lián)機(jī)幫助和環(huán)境相關(guān)幫助票腰。
• 向?qū)Ш痛?/li>
• 用戶手冊(cè)和培訓(xùn)資料

• 有效性：性能城看、可伸縮性、可擴(kuò)展性杏慰。

• 性能包括速度测柠、并發(fā)性、吞吐量缘滥、響應(yīng)時(shí)間轰胁、資源占用率等一些指標(biāo)。
• 可伸縮性是指當(dāng)向系統(tǒng)中增加資源時(shí)的性能改善朝扼，例如cpu赃阀、內(nèi)存或計(jì)算機(jī)等∏嬗保可伸縮性同時(shí)又分為垂直伸縮和水平伸縮兩種情況榛斯。垂直伸縮性指為系統(tǒng)換置更高級(jí)观游、快速的設(shè)備時(shí)性能的改善程度。水平伸縮性是指當(dāng)為現(xiàn)有的應(yīng)用程序添加額外的驮俗、負(fù)載均衡的服務(wù)器時(shí)性能的改善程度懂缕。
• 可擴(kuò)展性包含資源可擴(kuò)展性、應(yīng)用可擴(kuò)展性和技術(shù)升級(jí)可擴(kuò)展性王凑。資源可擴(kuò)展性指軟件系統(tǒng)對(duì)增加改變提佣。應(yīng)用可擴(kuò)展性是指，當(dāng)硬件資源擴(kuò)大時(shí)荤崇，應(yīng)用是否能相應(yīng)獲得性能提升的能力。技術(shù)升級(jí)可擴(kuò)展性是指潮针，隨著某項(xiàng)技術(shù)的升級(jí)术荤，系統(tǒng)性能是否能夠隨之提升的能力。

• 可移植性每篷。
• 在獲取非功能性需求時(shí)瓣戚，需要需求人員主動(dòng)去引導(dǎo)，因?yàn)榭蛻舨皇怯?jì)算機(jī)專家焦读，除了可用性之外子库，基本不考慮其他非功能性需求。即使提出矗晃，也是非常模糊仑嗅。

需求分析

關(guān)鍵概念分析

• 需求分析的工作就是找到關(guān)鍵用例，然后對(duì)這些用例進(jìn)行分析张症，并建立概念模型仓技。
• 概念用例始于業(yè)務(wù)用例，而且是關(guān)鍵的業(yè)務(wù)用例俗他。我們獲取概念用例的目的是為了完成業(yè)務(wù)主線脖捻，因此，概念用例不必那么在意業(yè)務(wù)細(xì)節(jié)兆衅，而只需要非常概括地展現(xiàn)出能夠完成業(yè)務(wù)主線的那一部分即可地沮。
• 建立概念模型和建立業(yè)務(wù)模型差不多，都是通過(guò)一些時(shí)序圖羡亩、活動(dòng)圖摩疑、協(xié)作圖來(lái)分析用例，然后得到一些關(guān)鍵對(duì)象夕春，這些對(duì)象都是一些實(shí)體對(duì)象未荒，模型就是由這些關(guān)鍵對(duì)象構(gòu)成的。
• 得到的這些實(shí)體對(duì)象顯然不能使一個(gè)系統(tǒng)運(yùn)行及志，可以采用分析模型的方式來(lái)實(shí)現(xiàn)核心業(yè)務(wù)片排。

業(yè)務(wù)架構(gòu)

• 業(yè)務(wù)架構(gòu)在軟件開(kāi)發(fā)中是很重要的寨腔，在某一行業(yè)做產(chǎn)品，做到最后就是沉淀出這個(gè)行業(yè)的業(yè)務(wù)架構(gòu)率寡，然后這些業(yè)務(wù)架構(gòu)就可以不斷地使用迫卢，或重新構(gòu)建成該行業(yè)的其他的產(chǎn)品，或作為咨詢冶共。
• 但是業(yè)務(wù)架構(gòu)的沉淀不是一朝一夕能達(dá)到的，首先有經(jīng)驗(yàn)豐富的架構(gòu)師捅僵，他在這個(gè)行業(yè)見(jiàn)過(guò)很多類(lèi)似的項(xiàng)目，知道該沉淀什么東西上荡，然后就是做產(chǎn)品的時(shí)候不斷改進(jìn)馒闷，持續(xù)總結(jié)酪捡。
• 它和軟件架構(gòu)是相輔相成的關(guān)系，但是軟件架構(gòu)要服務(wù)于業(yè)務(wù)架構(gòu)纳账，就像搭積木逛薇，業(yè)務(wù)架構(gòu)師積木，軟件架構(gòu)是搭積木的方法疏虫，也就是策略永罚，所以業(yè)務(wù)架構(gòu)是很重要的，畢竟巧婦難為無(wú)米之炊卧秘。
• 業(yè)務(wù)架構(gòu)由諸多構(gòu)件組成尤蛮，這些構(gòu)件可以是一個(gè)業(yè)務(wù)功能單元，也可以是一個(gè)業(yè)務(wù)邏輯斯议。
• 該怎么來(lái)構(gòu)建業(yè)務(wù)架構(gòu)呢产捞？

• 采用自頂向下的方法，之前的業(yè)務(wù)用例模型哼御、領(lǐng)域模型坯临、概念模型在這里就派上了用場(chǎng)；業(yè)務(wù)用例模型提供了業(yè)務(wù)的細(xì)節(jié)恋昼，領(lǐng)域模型說(shuō)明了要關(guān)注的問(wèn)題看靠，概念模型抓住了核心業(yè)務(wù)，有這些基礎(chǔ)液肌，一般來(lái)說(shuō)挟炬，對(duì)這個(gè)項(xiàng)目有了一定的把握。
• 最好從概念模型入手，因?yàn)楦拍钅Ｐ桶盐罩麄€(gè)核心業(yè)務(wù)谤祖，只要掌握了核心業(yè)務(wù)，就有自信說(shuō)把握了整個(gè)項(xiàng)目凸主。從核心業(yè)務(wù)流程找到粗粒度的構(gòu)件卿吐，然后再細(xì)分這些構(gòu)件嗡官，每個(gè)粗粒度的構(gòu)件分出來(lái)的多個(gè)小構(gòu)件應(yīng)該可以用一個(gè)邏輯構(gòu)件關(guān)聯(lián)起來(lái)谨湘，形成一個(gè)整體。這些構(gòu)件就是積木续担。
• 當(dāng)這些構(gòu)件做好后物遇，不能認(rèn)為這些構(gòu)件做的就一定對(duì)，因?yàn)榧词乖谶@個(gè)企業(yè)可以用起趾，在別的企業(yè)就有可能用不了了眶根。所以一般要做很多個(gè)項(xiàng)目属百，不斷調(diào)整族扰，不斷去積累才會(huì)在最后沉淀出一些可以拼圖的構(gòu)件怒竿。
• 在構(gòu)建業(yè)務(wù)架構(gòu)的時(shí)候愧口，我們會(huì)發(fā)現(xiàn)這和功能分解有什么區(qū)別呢耍属？再往上說(shuō)厚骗，這和面向過(guò)程的結(jié)構(gòu)化設(shè)計(jì)方法有什么區(qū)別呢？首先冲秽，面向過(guò)程是什么呢锉桑，在前面已經(jīng)講過(guò)民轴，結(jié)構(gòu)化設(shè)計(jì)方法得到是將過(guò)程分解成子系統(tǒng)或功能模塊后裸，比如一個(gè)項(xiàng)目按部門(mén)分微驶、按業(yè)務(wù)分，都只是業(yè)務(wù)員處理過(guò)程中的一個(gè)小的過(guò)程容燕。但是這樣分的話有什么根據(jù)嗎蘸秘？?jī)H僅是它是這個(gè)過(guò)程的一個(gè)小過(guò)程這樣的理由就可以了嗎醋虏？看來(lái)是不夠充分的颈嚼。而面向?qū)ο蟮姆椒ㄖ校瑯I(yè)務(wù)架構(gòu)建立的方法有著嚴(yán)密的推導(dǎo)過(guò)程叫挟，它從業(yè)務(wù)用例模型抹恳、領(lǐng)域模型奋献、概念模型中推導(dǎo)。每個(gè)業(yè)務(wù)構(gòu)件的產(chǎn)生都來(lái)自于各類(lèi)模型和場(chǎng)景宣吱。雖然每個(gè)構(gòu)件看起來(lái)是一個(gè)功能點(diǎn)凌节，但是應(yīng)該被看作是功能點(diǎn)的集合，是一個(gè)大的功能點(diǎn)卒煞。比如管理申請(qǐng)單構(gòu)件畔裕，這個(gè)構(gòu)件里面就包括申請(qǐng)單的生命周期管理扮饶，從產(chǎn)生到使用乍构，圍繞申請(qǐng)單這個(gè)實(shí)體類(lèi)岂丘，提供一系列的服務(wù)和接口奥帘，就好像是一個(gè)巨大的類(lèi)一般寨蹋。這點(diǎn)在結(jié)構(gòu)化設(shè)計(jì)中是做不到的钥庇。并且难述，結(jié)構(gòu)化設(shè)計(jì)讓我們感覺(jué)到“分解”的意思胁后，而業(yè)務(wù)架構(gòu)的方法則是“抽取”的感覺(jué)攀芯。

系統(tǒng)分析

確定系統(tǒng)用例

• 系統(tǒng)用例從業(yè)務(wù)用例細(xì)化而來(lái)，和業(yè)務(wù)用例的主要區(qū)別是描述的主體不一樣氧秘，業(yè)務(wù)用例以業(yè)務(wù)為主搔确，系統(tǒng)用例以系統(tǒng)為主膳算，是站在計(jì)算機(jī)的角度來(lái)看涕蜂，所以不是所有的業(yè)務(wù)用例都能轉(zhuǎn)化成系統(tǒng)用例瘦真，因?yàn)橛行┦虑橛?jì)算機(jī)是做不到的诸尽，只能人工來(lái)做您机。
• 一般來(lái)說(shuō)，首先分析業(yè)務(wù)用例場(chǎng)景仲闽，找到某某做什么赖欣，然后這些就是系統(tǒng)用例的來(lái)源顶吮，使用映射、抽象湃交、合并藤巢、拆分腮敌、演繹這些方法來(lái)確定系統(tǒng)用例。
• 確定系統(tǒng)用例后录淡，就要描述系統(tǒng)用例嫉戚，描述系統(tǒng)用例的過(guò)程帆啃，也是系統(tǒng)建模的過(guò)程努潘，和業(yè)務(wù)建模的過(guò)程差不多，采用的工具都是用例場(chǎng)景压怠、用例規(guī)約菌瘫、對(duì)象模型、用例實(shí)現(xiàn)宫患、用例實(shí)現(xiàn)場(chǎng)景等娃闲。只不過(guò)我們的視角和建模目的已經(jīng)從原來(lái)的描述業(yè)務(wù)、理解業(yè)務(wù)變成描述系統(tǒng)属拾、理解系統(tǒng)。

分析業(yè)務(wù)規(guī)則

• 業(yè)務(wù)規(guī)則常常被看做是程序邏輯的一部分逞频，導(dǎo)致業(yè)務(wù)規(guī)則要更改的時(shí)候襟诸，程序的控制邏輯也要作相應(yīng)的修改。程序的控制邏輯是指要完成某個(gè)功能需要怎么去進(jìn)行，而業(yè)務(wù)規(guī)則是指這個(gè)行業(yè)在進(jìn)行某個(gè)業(yè)務(wù)時(shí)需要遵守的規(guī)則刨疼，按理說(shuō)這兩個(gè)應(yīng)該要區(qū)分開(kāi)來(lái)，業(yè)務(wù)規(guī)則是會(huì)經(jīng)常變的迎卤。
• 對(duì)于整個(gè)系統(tǒng)都適用的這種全局規(guī)則應(yīng)該交給架構(gòu)師去處理，比如說(shuō)這個(gè)系統(tǒng)運(yùn)行的所有數(shù)據(jù)都要有備份樟凄，這時(shí)候如果讓程序員來(lái)實(shí)現(xiàn)，是一件很痛苦的事情叔壤，每次操作數(shù)據(jù)庫(kù)時(shí)都要考慮備份的事情炼绘，都要編寫(xiě)和這有關(guān)的代碼疟呐，分散了對(duì)業(yè)務(wù)邏輯的注意脚曾，不太好，架構(gòu)師來(lái)處理就不一樣了萨醒，他們站在系統(tǒng)的頂層斟珊，使用一些設(shè)計(jì)或者是框架苇倡，就可以實(shí)現(xiàn)富纸，讓程序員不必關(guān)注這塊囤踩。
• 對(duì)于交互規(guī)則堵漱，最好將他們獨(dú)立成一個(gè)對(duì)象或者模塊去使用愉镰，不應(yīng)該把他們混入到業(yè)務(wù)邏輯代碼中碗降。
• 對(duì)于內(nèi)稟規(guī)則爪幻，則讓程序員去處理好了，將它們封裝在對(duì)象中吭产，也不要混入業(yè)務(wù)邏輯代碼中邑蒋。

用例實(shí)現(xiàn)

• 系統(tǒng)用例只是描述系統(tǒng)需求束莫，是一種設(shè)想饿敲，用例實(shí)現(xiàn)是要把這種設(shè)想變成實(shí)現(xiàn)渠啤，我們采用的是面向?qū)ο蟮姆椒▉?lái)分析僵腺，所以把設(shè)想變成實(shí)現(xiàn)就要用對(duì)象之間的交互來(lái)完成毙玻，那就要找到對(duì)象了幌氮。
• 首先就需要有系統(tǒng)用例、業(yè)務(wù)規(guī)則這些原材料隘马，采用分析模型工具來(lái)得到分析類(lèi)對(duì)象酿愧。
• 得到的分析類(lèi)模型是需求通往實(shí)現(xiàn)的一道橋梁，它有很多優(yōu)點(diǎn)财岔。分析類(lèi)高于設(shè)計(jì)實(shí)現(xiàn)，高于語(yǔ)言實(shí)現(xiàn)，高于實(shí)現(xiàn)方式当叭。

軟件架構(gòu)和框架

• 架構(gòu)描述的是軟件應(yīng)該做成什么樣，是藍(lán)圖坞琴，而框架是半成品的項(xiàng)目忍啤。好比建房子粟焊，架構(gòu)師說(shuō)房子的墻壁應(yīng)該刷成白色顿苇，那用什么樣的油漆是框架說(shuō)了算短条，架構(gòu)只是描述要的樣子就可以了。所以架構(gòu)的東西一般會(huì)經(jīng)常拿來(lái)給別人說(shuō)鼎兽，抽象的東西會(huì)比較容易懂潘明，適合的人群種類(lèi)也多撵幽，而框架是程序員接觸的多哆窿，也只有他們才會(huì)懂，這是實(shí)現(xiàn)的細(xì)節(jié)。
• 大部分的軟件架構(gòu)都是由一個(gè)設(shè)計(jì)思想坪蚁，加上若干設(shè)計(jì)模式奏司，在規(guī)定一系列的接口規(guī)范乔询、傳輸協(xié)議、實(shí)現(xiàn)標(biāo)準(zhǔn)等文檔構(gòu)成的韵洋。比如說(shuō)j2ee規(guī)范描述了一系列邏輯部件竿刁，如session bean、entity bean麻献、message driven bean们妥、jaas猜扮、jdbc等勉吻，描述了這些部件的職責(zé)和它們的規(guī)范，約定了這些部件之間交互的接口和協(xié)議旅赢、標(biāo)準(zhǔn)齿桃，如soap、rmi煮盼、webservice等短纵。并規(guī)劃出一個(gè)如何利用這些部件實(shí)現(xiàn)一個(gè)應(yīng)用系統(tǒng)的藍(lán)圖。
• 軟件框架是可執(zhí)行的僵控，就是可以在計(jì)算機(jī)上運(yùn)行香到。它通常是針對(duì)架構(gòu)中某一特定問(wèn)題提供解決方案和輔助工具。比如ibm的WebSphere是j2ee架構(gòu)的一個(gè)實(shí)現(xiàn)报破，Struts悠就、jsf、webwork是mvc架構(gòu)的實(shí)現(xiàn)充易。
• 如果說(shuō)業(yè)務(wù)架構(gòu)是拼圖單元的話梗脾，軟件架構(gòu)就是拼圖的方法。拼圖的方法不盡相同盹靴，但是無(wú)論如何炸茧，最后的結(jié)果都是將業(yè)務(wù)單元拼成了一幅完整的業(yè)務(wù)拼圖瑞妇。可以說(shuō)業(yè)務(wù)架構(gòu)+軟件架構(gòu)=業(yè)務(wù)系統(tǒng)梭冠。
• 當(dāng)軟件架構(gòu)確定后辕狰，接下來(lái)要做的事就是把軟件架構(gòu)應(yīng)用到業(yè)務(wù)系統(tǒng)中去。系統(tǒng)分析中控漠，有提到使用分析模型來(lái)分析系統(tǒng)用例場(chǎng)景得到分析類(lèi)柳琢，而系統(tǒng)用例是從概念模型中細(xì)化出來(lái)的，所以只要把分析類(lèi)代入到軟件架構(gòu)中润脸，就可以驗(yàn)證軟件架構(gòu)是否滿足需求柬脸。

分析模型

• 軟件架構(gòu)包括軟件層次、每一層次的職責(zé)毙驯、層次之間的接口倒堕、傳輸協(xié)議和標(biāo)準(zhǔn)以及每一層次上所采用的軟件框架。
• 在把分析類(lèi)代入到軟件架構(gòu)的過(guò)程中爆价，首先做的是先分析好每一個(gè)分析類(lèi)它應(yīng)該處在軟件架構(gòu)的哪一個(gè)層次上垦巴，然后針對(duì)每一層次畫(huà)出分析模型圖，因?yàn)槊恳粚哟味加衅鋵?duì)應(yīng)的框架铭段，所以可以從所使用的框架的架構(gòu)設(shè)計(jì)思想以及這一層的業(yè)務(wù)得到分析模型圖骤宣，進(jìn)而得到分析類(lèi)圖。如果偷點(diǎn)懶序愚，就可以將這些分析類(lèi)一一對(duì)應(yīng)轉(zhuǎn)化為設(shè)計(jì)類(lèi)憔披，然后交互開(kāi)發(fā)。
• 對(duì)于直接把需求轉(zhuǎn)到設(shè)計(jì)類(lèi)的朋友來(lái)說(shuō)爸吮，分析模型可能是多余了芬膝，對(duì)于有經(jīng)驗(yàn)的設(shè)計(jì)人員來(lái)說(shuō)，分析模型不值一提形娇，機(jī)械并且沒(méi)有挑戰(zhàn)锰霜。但是，越簡(jiǎn)單的事越容易做好桐早，越不容易出錯(cuò)癣缅。而且分析模型利于經(jīng)驗(yàn)的傳播。
• 得到分析模型是粗放的哄酝，僅僅是對(duì)需求的一個(gè)最基本的實(shí)現(xiàn)友存。很多時(shí)候我們需要對(duì)這種實(shí)現(xiàn)進(jìn)行優(yōu)化，以滿足一些靈活性炫七、擴(kuò)展性方面的要求爬立。在優(yōu)化的時(shí)候可以關(guān)注以下幾點(diǎn)：容易變化的需求，這種就需要一定的擴(kuò)展能力去應(yīng)對(duì)万哪，例如采用一些設(shè)計(jì)模式侠驯；結(jié)構(gòu)化和耦合度調(diào)整抡秆，不好的結(jié)構(gòu)是網(wǎng)狀結(jié)構(gòu)的，好的結(jié)構(gòu)是樹(shù)形結(jié)構(gòu)吟策，對(duì)象之間的依賴是單向的儒士，不交叉的；交互集中點(diǎn)調(diào)整檩坚，若一個(gè)對(duì)象的交互非常多着撩，他依賴或關(guān)聯(lián)到很多類(lèi)，這個(gè)對(duì)象就是問(wèn)題多發(fā)地帶了匾委，優(yōu)化的方法一般有重新規(guī)劃職責(zé)拖叙、增加冗余對(duì)象、增加中間調(diào)和對(duì)象等方法赂乐。

組件模型

• 組件不是一種物理結(jié)構(gòu)薯鳍，不像包結(jié)構(gòu)會(huì)將類(lèi)組織在一起存放，組件是邏輯地引用挨措、使用這些類(lèi)挖滤，這些類(lèi)組織在一起的目的不是為了存放，而是為了完成一組特定的功能浅役。
• 什么時(shí)候考慮建立組件模型呢斩松？

• 如果實(shí)施的項(xiàng)目是一個(gè)分布式系統(tǒng)，那么各節(jié)點(diǎn)上的部署的應(yīng)用程序通常應(yīng)當(dāng)建立組件模型觉既。
• 如果實(shí)施的項(xiàng)目需要向第三方提供支持服務(wù)惧盹。
• 如果實(shí)施的項(xiàng)目需要將某部分業(yè)務(wù)功能單獨(dú)抽取出來(lái)形成一個(gè)可復(fù)用的單元，在許多系統(tǒng)或子系統(tǒng)中使用時(shí)
• 如果實(shí)施的項(xiàng)目需要與其他現(xiàn)存系統(tǒng)或第三方系統(tǒng)集成奋救，集成的接口部分應(yīng)當(dāng)建立組件模型岭参。
• 如果實(shí)施的項(xiàng)目采用了構(gòu)件化的軟件架構(gòu)反惕，例如soa尝艘，則應(yīng)當(dāng)建立組件模型。

• 組件只維護(hù)服務(wù)接口和調(diào)用實(shí)現(xiàn)類(lèi)的方式姿染”澈ィ或者說(shuō)組件只有服務(wù)信息與服務(wù)實(shí)現(xiàn)的綁定信息，而不包含實(shí)現(xiàn)細(xì)節(jié)悬赏。這種情況下狡汉，組件充當(dāng)了服務(wù)調(diào)用者與服務(wù)實(shí)現(xiàn)之間的代理和中介的作用。
• 也正因?yàn)楹蛯?shí)現(xiàn)的隔離闽颇，組件可以復(fù)用盾戴，可以獨(dú)立變化，可獨(dú)立部署兵多。

部署模型

• 部署模型是軟硬件相結(jié)合的產(chǎn)物尖啡。最直觀的理解橄仆，就是哪些軟件部分部署到哪些硬件設(shè)備上。

系統(tǒng)設(shè)計(jì)

接口設(shè)計(jì)

• 在設(shè)計(jì)接口時(shí)衅斩，可以基于相同行為設(shè)計(jì)盆顾，也可以基于相同服務(wù)設(shè)計(jì)。相同行為就是有相同方法的類(lèi)畏梆，相同服務(wù)就是業(yè)務(wù)流程相似您宪，但是業(yè)務(wù)內(nèi)容不一樣。

包設(shè)計(jì)

• 分包的目的除了將程序文件分類(lèi)管理奠涌，最重要的就是要讓軟件組織有序并且職責(zé)清晰宪巨。一般來(lái)說(shuō)，分包應(yīng)當(dāng)遵循自頂向下原則溜畅、職能集中原則和互不交叉原則揖铜。
• 通常情況下，應(yīng)當(dāng)遵循先應(yīng)用自頂向下原則达皿，再應(yīng)用職能集中天吓，再應(yīng)用互不交叉原則的順序。即先將類(lèi)按軟件層次分包峦椰，在每個(gè)軟件層次中再按職能集中原則分包龄寞，最后再按互不交叉原則調(diào)整的順序分包。

數(shù)據(jù)庫(kù)設(shè)計(jì)

• 面向?qū)ο笠晥D為動(dòng)態(tài)的世界建模汤功，它要描述的是世界運(yùn)行的過(guò)程和規(guī)律物邑，進(jìn)而適應(yīng)發(fā)展和變化，面向?qū)ο罂偸窃谧兓刑幚砀鞣N各樣的變化滔金。關(guān)系模型為靜態(tài)的世界建模色解，它通過(guò)數(shù)據(jù)快照記錄下了世界在某一時(shí)刻的狀態(tài)，在任何你可以訪問(wèn)它的時(shí)候餐茵，它都是靜止的科阎。
• 面向?qū)ο笾铝τ诮鉀Q計(jì)算邏輯問(wèn)題，關(guān)系模型致力于解決數(shù)據(jù)的高效存取問(wèn)題忿族。

書(shū)籍資源

鏈接:https://pan.baidu.com/s/1oF7-1sCh3fp7xLHwUKLr4g 密碼:lh75