建站
咨詢
售后
建站咨詢
新聞中心
幾年前寫的了，這兩天整理東西的時(shí)候又給翻出來了，當(dāng)時(shí)是公司讓給我給設(shè)計(jì)人員講講如何寫面向?qū)ο蟮脑O(shè)計(jì)說明書，所以臨時(shí)東拼西湊的弄了這么個(gè)東西，畢竟是用于內(nèi)部培訓(xùn)的，有些東西都是直接從網(wǎng)上整段COPY的，最多就是用自己的話又修飾了一遍，在此說明一下，各位看到的時(shí)候，莫過多糾結(jié)于此 。
一. 引言
1.1 文檔概要
概要很簡(jiǎn)單...
1.2 編寫目的
解釋設(shè)計(jì)說明書里應(yīng)該寫些什么,在寫設(shè)計(jì)說明書之前應(yīng)該給我什么,寫完了設(shè)計(jì)說明書應(yīng)該達(dá)到什么樣的效果，或者換個(gè)說法，寫完了設(shè)計(jì)說明書我能給代碼開發(fā)人員什么。
1.3 背景
背景很復(fù)雜
1.4 定義
|
類型 |
名稱 |
定義 |
|
縮寫詞 |
RUP |
Rational Unified Process，統(tǒng)一軟件開發(fā)過程，由IBM提出的基于面向?qū)ο笄疫m應(yīng)于大型項(xiàng)目的程序開發(fā)方法論 |
|
OO |
Object Oriented,面向?qū)ο?/p> |
|
|
XP |
Extreme Programming極限編程 。一種認(rèn)為輕量的軟件開發(fā)方法論，強(qiáng)調(diào)架構(gòu)，文檔不如直接編程來得直接。適應(yīng)于小型項(xiàng)目的開發(fā)實(shí)踐 |
|
|
專門術(shù)語 |
||
1.5 預(yù)期的讀者和讀者建議
|
讀者類型 |
備注（建議） |
|
項(xiàng)目經(jīng)理 |
了解從需求到設(shè)計(jì)的全過程 |
|
需求分析人員 |
了解從需求到設(shè)計(jì)的全過程，著重看需求分析部分 |
|
系統(tǒng)設(shè)計(jì)人員 |
了解從需求到設(shè)計(jì)的全過程，著重看系統(tǒng)設(shè)計(jì)部分 |
|
開發(fā)人員 |
著重看系統(tǒng)設(shè)計(jì)推導(dǎo)部分對(duì)于各種圖例以及相關(guān)說明表的解釋。理解這些圖例及相關(guān)的說明表的具體意義，目的是能看懂概要設(shè)計(jì)說明書里的內(nèi)容。對(duì)于推導(dǎo)的過程則只須大致了解即可 |
二．參考文獻(xiàn)
《系統(tǒng)分析與設(shè)計(jì)》 JohnW.Satzinger Robert B.Jackson Stephen D.Burd 著朱群雄 汪曉勇 等譯 機(jī)械工業(yè)出版社
《大型軟件體系結(jié)構(gòu)：使用UML實(shí)踐指南》［美］Jeff Garland Richard Anthony著 葉俊民汪望珠 等譯 電子工業(yè)出版社
《設(shè)計(jì)模式精粹》［美］Alan Shalloway & James R.Trott 著熊節(jié) 譯 清華大學(xué)出版社
《編寫有效用例》［美］Alistair Cock Brun 著 機(jī)械工業(yè)出版社
《用例分析技術(shù)(原書第二版)》機(jī)械工業(yè)出版社
《OO系統(tǒng)分析員之路--用例分析系列》 coffeewoo
《RUP文檔模型》
#p#
三．內(nèi)容
3.1 需求分析
雖說本文檔是為設(shè)計(jì)說明書的編寫進(jìn)行服務(wù)。但我覺得如果要想明白設(shè)計(jì)階段能夠做些什么，就得知道前一階段能夠給我輸入些什么，設(shè)計(jì)的前一階段是需求。所以我們得搞明白需求能給我們輸入些什么。當(dāng)然要想搞明白需求能給我們輸入些什么。就又得搞明白需求的最終文檔是怎么一步一步分析出來的。要不然直接給我們一堆文字外加一堆UML圖。我們也搞不明白究竟是些什么東西。所以本文檔有必要從需求分析開始入手，一步一步推導(dǎo)到概要設(shè)計(jì)說明。詳細(xì)設(shè)計(jì)本文檔不作考慮。
本文檔采用的是面向?qū)ο蟮耐茖?dǎo)過程。而非面向過程的推導(dǎo)過程。所以在開始推導(dǎo)之前先給大家測(cè)一下，看看你到底是面向?qū)ο蟮某绷魅巳耗?，還是面向過程的遺老遺少。
如果你的分析習(xí)慣是在調(diào)研需求時(shí)最先弄清楚有多少業(yè)務(wù)流程，先畫出業(yè)務(wù)流程圖，然后順藤摸瓜，找出業(yè)務(wù)流程中每一步驟的參與部門或崗位，弄清楚在這一步參與者所做的事情和填寫表單的結(jié)果，并關(guān)心用戶是如何把這份表單傳給到下一個(gè)環(huán)節(jié)的。那么很不幸，你還在干著面向過程的事情。
如果你的分析習(xí)慣是在調(diào)研需求時(shí)最先弄清楚有多少部門，多少崗位，然后找到每一個(gè)崗位的業(yè)務(wù)代表，問他們類似的問題：你平時(shí)都做什么？這件事是誰交辦的？做完了你需要通知或傳達(dá)給誰？做這件事情時(shí)你都需要填寫些什么表格？....那么恭喜你，你已經(jīng)跟上了時(shí)代的潮流，進(jìn)入了OO人群的行列！
當(dāng)然是OO的先不要忙著得意，前路漫漫，還有的你走。是遺老遺少的也不用忙著灰心，改進(jìn)為時(shí)不晚。
本文檔主要采用了RUP（統(tǒng)一軟件開發(fā)過程）的思想。而非XP（極限編程）的思想。采用RUP并不是說RUP就比XP好。這兩個(gè)本身就無所謂誰好誰壞，因?yàn)樵谶m應(yīng)的對(duì)象上兩者是完全不同的。對(duì)于中小型公司和中小型軟件來說，XP是非常有效的管理方法，它能大大降低管理、開發(fā)成本和技術(shù)風(fēng)險(xiǎn)。不過要是對(duì)于大公司和大型項(xiàng)目來說，XP就不適用了，這時(shí)RUP卻表現(xiàn)的非常出色。你能想象波音公司用XP的方法來開發(fā)747是一個(gè)什么情形嗎？先不要管飛機(jī)將來是什么樣子，反正先造一架出來，出問題了，摔了找找原因，改進(jìn)改進(jìn)，重構(gòu)一下，再造一架....再摔了，沒關(guān)系，咱們不怕變更，再造就是了。如果真是這樣，恐怕波音公司早掛了。那XP什么情況下適用呢？如果你是一個(gè)雜貨店的老板，不知道什么樣的商品受歡迎，沒關(guān)系，我們可以先各進(jìn)一小批貨，賣上一段時(shí)間，然后看顧客的反應(yīng)，受歡迎的貨品我們就多進(jìn)一些，不受歡迎的嘛就少進(jìn)一些或者不進(jìn)，順便再和顧客多多交流一下，直接問問他們喜歡什么，不喜歡什么。不斷的改進(jìn)，不斷的完善。我想最后一定會(huì)顧客盈門的。但是假如這時(shí)這個(gè)老板非得先進(jìn)行一下什么市場(chǎng)調(diào)研，再做個(gè)什么商業(yè)方案，順便再搞搞風(fēng)險(xiǎn)評(píng)估，最后再進(jìn)行下客戶關(guān)系研究，消費(fèi)曲線分析。猛一點(diǎn)的，再加上個(gè)消費(fèi)心理問卷....估計(jì)還沒開業(yè)，就破產(chǎn)了。
在本文檔中采用RUP的過程僅僅是因?yàn)樗?，更?yán)謹(jǐn)一些。另外對(duì)于一些面向?qū)ο罄锏幕A(chǔ)理論，無論是對(duì)于RUP還是XP都還是適用的。在我看來 RUP 與 XP 的區(qū)別不在技術(shù)，僅在對(duì)于過程中對(duì)精細(xì)程度的把握尺度與迭代方式的不同而已。
注：使用的RUP的推導(dǎo)與分析和迭代過程，文檔并不一定采用RUP。
本文檔主要講的是推導(dǎo)過程，故對(duì)過程中的細(xì)節(jié)不作深入的描述。例如如何獲取“有效的”用例以及獲取用例時(shí)，所要考慮到的市場(chǎng)因素和風(fēng)險(xiǎn)因素，以及在需求分析和系統(tǒng)設(shè)計(jì)時(shí)的相關(guān)管理事項(xiàng)（例如需求會(huì)議召開，怎樣與客戶交流，進(jìn)度的控制，成本）等不作進(jìn)一步描述。相關(guān)內(nèi)容可自行參考有關(guān)書籍和論文。
最后再啰嗦一句：我本身對(duì)于面向?qū)ο蟮睦斫庖膊皇呛苌羁?，因時(shí)間緊迫，還有很多東西未完全吃透，故錯(cuò)誤肯定是在所難免的。如果不怕被誤導(dǎo)那么你可以放心大膽的往下看了，如果怕誤導(dǎo)，還是勸你就此打住比較合適。
下面我們正式開始推導(dǎo)過程。
- 尋找執(zhí)行者與設(shè)計(jì)用例
RUP是一種用例驅(qū)動(dòng)的迭代開發(fā)過程。那么何為用例驅(qū)動(dòng)呢？這個(gè)很好理解，看字面就能猜個(gè)八九分，就是一切從用例開始，然后一步一步推導(dǎo)出我們想要的結(jié)果。那么用例又是什么呢？這是我們提出來的第一問題
什么是用例 ???
我們先不忙著做出解答。先假設(shè)一段場(chǎng)景，AA公司是一家轉(zhuǎn)購(gòu)公司，他們從不同的供貨商那里進(jìn)貨后，然后再賣出去。最近他們想讓我們?nèi)樗麄冮_發(fā)一套系統(tǒng)，我們接到任務(wù)后給他們公司打了一個(gè)電話，他們?yōu)槲覀儼才帕艘晃讳N售經(jīng)理進(jìn)行電話交流。我們把這次交流的結(jié)果整理后，得到了如下的一段描述
目前隨著網(wǎng)絡(luò)的普及，很多的上班族趨向于采用使用網(wǎng)絡(luò)這種做在家里就可以購(gòu)物的方式。所以我們公司準(zhǔn)備開發(fā)一個(gè)網(wǎng)上的訂單平臺(tái)?？蛻艨梢?通過網(wǎng)絡(luò)查看我們發(fā)布的產(chǎn)品并選購(gòu)，然后通過銀行或者其它付款方式付款給我們，我們則通過快遞公司或者其它方式將產(chǎn)品直接送到客戶填寫的寄送地址?？蛻艨梢酝素?。并要求重新進(jìn)貨。當(dāng)然可能需要額外的支付一筆費(fèi)用。
看到這樣一段描述，你可能覺得大致清楚要做的是什么樣的東西了，但對(duì)于構(gòu)建一個(gè)系統(tǒng)來說，這樣的描述還差太多的東西，其中有很多的細(xì)節(jié)并沒有表述出來。然而不幸的事，往往在前期你也就只能從客戶那里挖出來這些東西了，尤其是你在調(diào)研時(shí)僅僅只和一個(gè)崗位的相關(guān)人員進(jìn)行了交流。當(dāng)然也許你的客戶夠?qū)I(yè)，你們的交流使你獲得了比這多的多的消息， 但無論如何， 你的經(jīng)驗(yàn)會(huì)告訴你：你第一次獲得的東西永遠(yuǎn)都不可能是完備的，你也永遠(yuǎn)不要奢望第一次就能講全部的需求都搞到手。
那么獲得了這樣一段并不完備的描述后，我們應(yīng)該做些什么呢？繼續(xù)追問？NO，能獲得這樣的需求在目前看來我們已經(jīng)做的足夠好了。 自己去完善客戶的需求并交付開發(fā)人員去開發(fā)？NO，要知道使用系統(tǒng)的是客戶而不是你。也許你可以為客戶設(shè)計(jì)一套流程，或者一個(gè)訂單的樣式，但那可能并不是客戶所需要的，假如你認(rèn)為客戶不大會(huì)授權(quán)你去為他們?cè)谀承┓矫孢M(jìn)行設(shè)計(jì)，你就千萬不要去自作主張。當(dāng)然絕大多數(shù)客戶都是懶惰的，大部分的情況是他們非常樂于讓我們先幫他們思考，然后他們?cè)谖覀兯伎嫉幕A(chǔ)上給出些意見就行了。是的，這就是我們下面要做的事――分析這段需求，找出這段需求中的隱藏信息，分析出他們要做的這套系統(tǒng)究竟會(huì)涉及到哪些人（涉眾），并簡(jiǎn)單的為每個(gè)涉眾列出你所能想到的他所要做的事情，然后將這些以易于客戶理解的方式告訴他們所有相關(guān)的人員，然后她們就會(huì)在此基礎(chǔ)上提出她們自己的想法，你記錄下她們的這些想法，對(duì)這些想法進(jìn)行分析后將它們補(bǔ)充到你的需求里，之后再將你這個(gè)最新的分析后的需求提交給客戶審查，如此迭代，直到客戶說OK，我要的就是這個(gè)東西。
如果你沒有和系統(tǒng)的所有相關(guān)者（涉眾）進(jìn)行過交談，并獲得了有用的信息。永遠(yuǎn)不要說你已經(jīng)做好了需求
下面我們就具體討論一下如何去分析這段需求。此時(shí)用例開始登場(chǎng)。當(dāng)然本文檔講的是一個(gè)推導(dǎo)過程，不是一個(gè)迭代過程，故在下面的描述中我們不考慮迭代的因素，所有的分析都是假設(shè)在一個(gè)很順利的環(huán)境中進(jìn)行，這樣也許會(huì)讓你覺得條理更清晰一些（包括上面那段不完備的描述在這里我們都假設(shè)他已經(jīng)是很完備的了）。
當(dāng)然在繼續(xù)往下介紹之前，為了更加專注于需求的功能要求，我會(huì)回避掉前面提到的一個(gè)概念“涉眾”，而改用“執(zhí)行者”代替。執(zhí)行者是涉眾的一個(gè)子集，涉眾是同你要開發(fā)的系統(tǒng)相關(guān)的一切人或物，而執(zhí)行者則是同你要開發(fā)的系統(tǒng)直接接觸的一切人或物。從這兩個(gè)定義上我們可以看出，涉眾可能不是這個(gè)系統(tǒng)的直接操作者，例如一個(gè)用于控制機(jī)床運(yùn)作的系統(tǒng)，財(cái)務(wù)部門可能不會(huì)去使用，但因?yàn)轫?xiàng)目的款項(xiàng)是由財(cái)務(wù)部支出，所以財(cái)務(wù)部門是和本系統(tǒng)相關(guān)的人或物，所以它是涉眾，但卻不是執(zhí)行者。
對(duì)于執(zhí)行者的確定過程，本文檔不再作相關(guān)的描述，下面只給出此描述里的執(zhí)行者的相關(guān)UML圖形
RUP的所有分析都是從確定執(zhí)行者開始的。以后的所有分析也都是基于執(zhí)行者，整個(gè)需求的獲取與分析過程都是圍繞著 某某執(zhí)行者 做了 某某事 進(jìn)行的。當(dāng)然這也是面向?qū)ο蟮姆治龇绞?，非?dú)RUP。
確定了執(zhí)行者，那么下面我們就開始為每個(gè)執(zhí)行者確定其所有的用例，這里已經(jīng)是第三次提到用例了。當(dāng)然在這里我還是不會(huì)給出他的定義，你目前要做的不是追問這個(gè)問題而是繼續(xù)的往下看。然后在下面的分析中總結(jié)一下自己對(duì)用例的理解，并自己給出一個(gè)定義或者不斷的修改你的定義。當(dāng)然在最后。我會(huì)在適當(dāng)?shù)牡胤浇o出用例的定義。這時(shí)你可以拿它和你的定義進(jìn)行比較。也許你會(huì)發(fā)現(xiàn)。其實(shí)你的定義比我給出的更加的精確，更加的好。當(dāng)然，你也可以完全不用去管用例的定義究竟是個(gè)什么東西。的確對(duì)于用例來說，他的定義并不是必須的。任何的定義恐怕也都是不完備的。
好的， 下面我們讓我們來開始提取用例吧，在提取之前請(qǐng)確保你能夠再次認(rèn)真的檢查一下執(zhí)行者，看看是否還有什么遺漏，確定沒有后再動(dòng)手，當(dāng)然遺漏總是難免的， 這并不要緊， 我們還可以在后面的用例分析中再將它加進(jìn)來。你現(xiàn)在只須做到一點(diǎn)即可：即是在用例分析前，你對(duì)執(zhí)行者的確定已經(jīng)做到了最好，這一點(diǎn)是很重要的。
對(duì)于執(zhí)行者來說，一個(gè)用例應(yīng)該是一個(gè)完整的任務(wù)。一個(gè)用例應(yīng)該是在一個(gè)相對(duì)連續(xù)的時(shí)間內(nèi)完成。如果有明顯的時(shí)間斷層，應(yīng)該考慮一下把你的用例進(jìn)行分解。成為多個(gè)用例。當(dāng)然這并不是一定的，這涉及到了用例提取的粒度問題，這個(gè)問題相當(dāng)?shù)膹?fù)雜，在此不作討論，否則這個(gè)文檔真要成為一本書了。不過還是建議你去查查相關(guān)的資料，因?yàn)檫@個(gè)也很重要。
下面我們給出上面AA公司經(jīng)理的一段描述的用例圖，這張是經(jīng)過一次討論后，得出的用例圖，從圖中可以看出來有些東西是在上面的那段描述中不曾出現(xiàn)的，這是討論的結(jié)果，其中討論的過程，在此不作敘述，怎么討論也不準(zhǔn)備花時(shí)間去寫,這些方面的具體內(nèi)容你可以自己去查看相關(guān)資料。
當(dāng)然這張圖僅僅只是經(jīng)過一次討論出來的結(jié)果，這個(gè)用例圖也并不是完善的，其中很多東西并沒有考慮到。例如財(cái)務(wù)的處理，銀行的轉(zhuǎn)帳等等都沒有考慮進(jìn)去。雖然如此，隨時(shí)的畫出用例圖卻是非常有必要的，因?yàn)槿魏我粋€(gè)未完成的用例圖都是我們目前分析的成果，我們以后的分析也都以這張圖作為基礎(chǔ)與參考，這樣會(huì)使我們更容易發(fā)現(xiàn)我們還有哪些方面沒有考慮到，一旦發(fā)現(xiàn)了沒有考慮到的事情，就馬上更新這張圖，將你的發(fā)現(xiàn)或者想法加進(jìn)去，當(dāng)然也要在合適的時(shí)間與地點(diǎn)將這張圖拿過去與客戶交流，并告訴他們這是我們目前分析出來的系統(tǒng)需求，有了這張圖客戶可以很容易的明白目前我們已經(jīng)做了哪些，還有哪些我們沒有考慮進(jìn)去，這時(shí)他就會(huì)告訴我們他們的想法。我們?cè)賹?duì)他的想法加以整理，再一次的更新這張圖。然后重復(fù)上述的步驟，直到客戶說OK。
#p#
當(dāng)然還是為了以后說明的方便，在此文檔中不描述迭代的過程，所以我們假設(shè)這種圖已經(jīng)是最終的用例圖了。
雖然這張用例圖已經(jīng)可以很清晰的描述了系統(tǒng)與所有相關(guān)執(zhí)行者之間所進(jìn)行的互動(dòng)操作。但在實(shí)際的分析過程中，只使用這一種圖往往是不夠的，在實(shí)際的分析過程中，我們會(huì)發(fā)現(xiàn) 為每個(gè)執(zhí)行者單獨(dú)列出他所涉及的一切用例對(duì)于發(fā)現(xiàn)執(zhí)行者還有什么操作沒有加進(jìn)去是很有用的，另外 為每個(gè)用例單獨(dú)列出一張相關(guān)執(zhí)行者 對(duì)于發(fā)現(xiàn)每個(gè)用例中還有那些相關(guān)人員沒有考慮進(jìn)去也是非常有用的。同時(shí)，對(duì)于一些典型的業(yè)務(wù)場(chǎng)景畫一張業(yè)務(wù)場(chǎng)景圖對(duì)于客戶理解用例以及在發(fā)現(xiàn)業(yè)務(wù)的大體流程上還缺少什么環(huán)節(jié)也是很有必要的。所以下面我們分別帖出這三種圖。
為每個(gè)執(zhí)行者列出他所涉及的所有用例(以客戶為例，實(shí)際操作中你需要為所有執(zhí)行者列出一張這樣的圖)
為每個(gè)用例列出所有相關(guān)的執(zhí)行者(以訂購(gòu)貨物為例，實(shí)際操作中你需要為每個(gè)用例列出一張這樣的圖)
業(yè)務(wù)場(chǎng)景圖（一次交易的場(chǎng)景）
我們?cè)谶@里第一次接觸到了場(chǎng)景這個(gè)概念，在下面我們還會(huì)遇到另外一種場(chǎng)景，用例場(chǎng)景。在這里還是不講場(chǎng)景究竟是個(gè)什么定義，通過業(yè)務(wù)場(chǎng)景和用例場(chǎng)景，大家可以自己去比較一下之間的異同，然后自己給出一個(gè)定義。在這個(gè)場(chǎng)景圖中，橢圓代表的是用例，方格的正式名稱叫泳道，在業(yè)務(wù)場(chǎng)景中，每個(gè)泳道代表一個(gè)執(zhí)行者，在用例場(chǎng)景中，會(huì)有所不同。大家注意一下之間的區(qū)別，同時(shí)大家在看這個(gè)場(chǎng)景圖時(shí)，是不是發(fā)現(xiàn)了有兩個(gè)訂購(gòu)貨物用例，那是因?yàn)榭蛻艉蜆I(yè)務(wù)代表都參與了這個(gè)用例。雖然在實(shí)際上訂購(gòu)貨物的過程中，并不一定需要客戶和客戶代表必須在一個(gè)連續(xù)的時(shí)間內(nèi)完成一系列動(dòng)作（用例的一種粒度劃分方法），對(duì)于傳統(tǒng)的電話訂購(gòu)方式一個(gè)訂購(gòu)的過程可能會(huì)涉及客戶和客戶代表，但在網(wǎng)購(gòu)當(dāng)中這種用例設(shè)定是不準(zhǔn)確的。事實(shí)上應(yīng)當(dāng)將它一分為二。一個(gè)是客戶的訂購(gòu)貨物用例，一個(gè)是客戶代表的審核訂購(gòu)信息用例，但是本文檔中為了展現(xiàn)用例分析中的更多細(xì)節(jié)，到目前為止，訂購(gòu)貨物用例一直被視為電話訂購(gòu)的情況。但在后面的用例場(chǎng)景分析時(shí)，我們將重新將訂購(gòu)貨物假定為只有客戶一人參與的用例（網(wǎng)購(gòu)時(shí)的情況）。另外從這張圖中，我們可以明顯的看出來許多的不協(xié)調(diào)，例如，這本身是一宗交易，卻從頭到尾，沒有看到錢的影子，因此看了這張圖后，我們就會(huì)考慮是否應(yīng)該將電子支付系統(tǒng)這個(gè)執(zhí)行者加進(jìn)去。在實(shí)際的分析過程中，這個(gè)回答是肯定的，但在這里，我們先不忙著管它。至于原因，后面會(huì)給你回答
在進(jìn)行下面的描述之前，我們將我們的用例圖修正一下，使之更適應(yīng)于網(wǎng)購(gòu)
修正后如下:
注意:本圖只是對(duì)訂購(gòu)貨物一處進(jìn)行了修改，實(shí)際上取消定單等地方也應(yīng)作相應(yīng)修改，為了節(jié)省時(shí)間，就先這樣了。當(dāng)然，如果你修正了用例圖，前面所涉及的一切用例相關(guān)的圖形都應(yīng)作相應(yīng)的修改。
用例是非常復(fù)雜的，僅僅用UML里的一個(gè)橢圓來代替，似乎太過簡(jiǎn)單了點(diǎn)。所以我們現(xiàn)在有必要引入一張表格――用例描述表對(duì)用例進(jìn)行更加詳盡的文字描述。用例描述表如下（以訂購(gòu)貨物用例為例，實(shí)際中你應(yīng)為每個(gè)用例都填寫這樣一張表格）
|
用例名稱 |
訂購(gòu)貨物用例 |
|
用例描述 |
客戶通過此用例完成對(duì)商品的訂購(gòu)功能 |
|
執(zhí)行者 |
客戶 |
|
前置條件 |
客戶已經(jīng)打開主頁(yè) |
|
后置條件 |
返回訂單編號(hào)給客戶 |
|
主過程描述 |
1.當(dāng)客戶在主頁(yè)選擇訂購(gòu)貨物，用例開始 2.客戶查找目錄，選擇需要訂購(gòu)的產(chǎn)品 3.對(duì)于每個(gè)商品 a）系統(tǒng)顯示商口的圖片價(jià)格等相關(guān)信息 b) 客戶將其加入購(gòu)物車 c) 系統(tǒng)自動(dòng)計(jì)劃購(gòu)物車內(nèi)的商品的價(jià)格總和 循環(huán)結(jié)束 4.客戶選擇購(gòu)買 5.系統(tǒng)要求用戶輸入用戶名和密碼 6.客戶鍵入用戶名和密碼，并提交 7.系統(tǒng)提示用戶填寫送貨地址等相關(guān)信息 8.客戶添寫送貨地址等相關(guān)信息，并提交 9.系統(tǒng)提示用戶填寫寄送方式 10. 用戶選擇寄送方式，并提交 11.系統(tǒng)提示用戶選擇支付方式、 12.客戶選擇使用銀行卡支付，并填寫相關(guān)信息，提交 13.系統(tǒng)顯示交易訂單，并將其作為未完成的訂單保存，并向電子支付系統(tǒng)要求支付。 14.支付確認(rèn)后，訂單被標(biāo)記為確認(rèn)。并提示用戶交易成功， 用例結(jié)束 |
|
分支過程描述 |
對(duì)于每個(gè)商品，在a)后選擇放棄，回到2 如果用戶之間已經(jīng)登錄，在4處直接跳至7 假如客戶選擇使用余額付款，在10處跳至13處 |
|
異常過程描述 |
如采用余額，用戶余額不足，計(jì)算機(jī)顯示余額和所需金額 |
|
業(yè)務(wù)規(guī)則 |
購(gòu)物車中至少有一個(gè)貨物，才能提交。 |
|
補(bǔ)充說明 |
可以看到在這個(gè)用例表中，我們已經(jīng)詳細(xì)的描述了用例的細(xì)節(jié)與步驟。其中的主過程描述又叫主成功用例場(chǎng)景，每個(gè)分支過程則獨(dú)自構(gòu)成一個(gè)分支用例場(chǎng)景。同時(shí)我們注意一下。主過程描述中的用粗字體表示的那個(gè)“電子支付系統(tǒng)”。是不是有點(diǎn)熟悉，在討論業(yè)務(wù)場(chǎng)景時(shí)，曾經(jīng)提到了他，并且當(dāng)時(shí)并沒有把他加入執(zhí)行者中去，為的就是在此處說明一個(gè)問題，就是在寫用例描述表時(shí)，我們也能夠發(fā)現(xiàn)一些曾經(jīng)忽略的執(zhí)行者或者用例。此時(shí)一旦發(fā)現(xiàn)，我們同樣必須及時(shí)的去更新用例圖。以使你的用例圖更加的完善更加的接近于客戶的要求。
雖然用一堆生澀的詞匯和句子是可以完全的表述一個(gè)用例，但是不免讓人覺得有點(diǎn)難以接受。沒有什么太直觀的印象，因此我們有必要再引入一些圖形。以使之形象化。用例場(chǎng)景圖 正好能夠滿足這個(gè)要求.每個(gè)用例場(chǎng)景圖，對(duì)應(yīng)著一個(gè)用例場(chǎng)景（一個(gè)用例有多個(gè)場(chǎng)景，一個(gè)主場(chǎng)景＋多個(gè)分支場(chǎng)景），在此我們只畫出主用例場(chǎng)景的 用例場(chǎng)景圖，分支場(chǎng)景將不再繪出，各位可自行去繪。
經(jīng)過了反復(fù)的迭代，分析以及與客戶的交流，目前我們已經(jīng)得到所有的用例以及他的場(chǎng)景，并一一用UML使之圖形化。同時(shí)這些用例及場(chǎng)景也已得到了客戶的認(rèn)可，并被認(rèn)為已經(jīng)能夠很好的描述出他們所希望的系統(tǒng)的樣子。那么下面我們可以放心的進(jìn)入建模的下一個(gè)環(huán)節(jié)――分析業(yè)務(wù)實(shí)體了，當(dāng)然在進(jìn)入下一環(huán)節(jié)之前，我還得履行此節(jié)開篇的諾言，給出用例的定義。
用例:還是不做介紹了，可能會(huì)誤導(dǎo)。
補(bǔ)充說明:在發(fā)現(xiàn)用例，尤其是粒度比較大的用例時(shí)，畫出事件表，對(duì)于分析有很大的幫助。詳細(xì)情況，請(qǐng)自己查看相關(guān)的文檔。
#p#
- 設(shè)計(jì)業(yè)務(wù)實(shí)體
從上一節(jié)里，我們繼承了諸多的成果，例如用例，場(chǎng)景以及花了N長(zhǎng)時(shí)間繪制的那一堆用例圖和場(chǎng)景圖。其中我們需要的是用例描述表和用例場(chǎng)景圖。這兩個(gè)可以幫助我們很好的去發(fā)現(xiàn)業(yè)務(wù)實(shí)體。
業(yè)務(wù)實(shí)體的命名其實(shí)很準(zhǔn)確，但是不太容易被程序員所理解。假如我講對(duì)象的話可能會(huì)讓你感覺更親切一些。但是我們要明白一點(diǎn)。業(yè)務(wù)實(shí)體和對(duì)象雖然有著密切的關(guān)系，但卻也有著本質(zhì)的區(qū)別。對(duì)象確切的說是面向?qū)ο缶幊痰囊粋€(gè)術(shù)語，是和計(jì)算機(jī)密切相關(guān)的，是一個(gè)設(shè)計(jì)階段的概念。而業(yè)務(wù)實(shí)體則仍是一個(gè)需求階段的概念，需求文檔是要給客戶看的。所以業(yè)務(wù)實(shí)體不會(huì)去考慮抽象，設(shè)計(jì)模式等。假如你在需求文檔里弄出個(gè)什么FACTORY，或者FA?ADE模式。就好比財(cái)務(wù)人員給你弄出些什么復(fù)式記帳法，借貸平衡，借方科目，貸方科目。亦或科技人員給你弄出些什么量子理論，測(cè)不準(zhǔn)原理。絕一點(diǎn)的哲學(xué)家再給你弄出些個(gè)什么奧卡姆剃刀，證偽主義一樣?？隙〞?huì)搞的客戶一頭霧水，不知所云。
業(yè)務(wù)實(shí)體是需求階段的概念，對(duì)象是設(shè)計(jì)階段的概念
要對(duì)業(yè)務(wù)實(shí)體進(jìn)行分析，我們先要從用例描述表和用例場(chǎng)景圖中分析出來究竟有哪些業(yè)務(wù)實(shí)體。這是一項(xiàng)技巧性很強(qiáng)的工作。有些簡(jiǎn)單的一眼就能看出來（名詞），有些則隱藏的很深，這需要有相當(dāng)?shù)慕?jīng)驗(yàn)和對(duì)實(shí)體的敏銳感知能力以及認(rèn)真仔細(xì)的態(tài)度。這不是本文檔要討論的。本文檔只講到這個(gè)步驟你要提取業(yè)務(wù)實(shí)體了就行了。
業(yè)務(wù)實(shí)體一般包括 實(shí)實(shí)在在的事物、角色、組織部門、設(shè)備、交互行為、地點(diǎn)位置等
下面我給出一張業(yè)務(wù)實(shí)體圖（只根據(jù)訂購(gòu)貨物用例簡(jiǎn)單的分析了一下，實(shí)體不是很全，實(shí)際當(dāng)中，你要把所有的實(shí)體都分析出來。本文檔只簡(jiǎn)單演示一下而已）
分析出來了有哪些業(yè)務(wù)實(shí)體。下一步就得分析業(yè)務(wù)實(shí)體的關(guān)系。圖如下
關(guān)系主要有一元（回歸）關(guān)系，二元關(guān)系，三元關(guān)系，N元關(guān)系，其中二元關(guān)系比較重要。其具體又分一對(duì)多，一對(duì)一，依賴，多對(duì)多等，具體請(qǐng)查閱相關(guān)資料。
理出來關(guān)系后。下一次我們開始分析業(yè)務(wù)實(shí)體的屬性。所謂屬性就是有關(guān)業(yè)務(wù)實(shí)體的一條特定信息。
屬性：有關(guān)業(yè)務(wù)實(shí)體的一條特定信息
對(duì)于業(yè)務(wù)實(shí)體的屬性在需求分析階段一般不采用UML圖形的方式，而是采用領(lǐng)域模型(業(yè)務(wù)實(shí)體)說明表的形式表示。領(lǐng)域模型說明表如下（以商品為例，實(shí)際中應(yīng)為每個(gè)實(shí)體寫一份這樣的說明）
|
實(shí)體名稱 |
商品 |
||
|
實(shí)體描述 |
每個(gè)商品都經(jīng)有上架（錄入商品信息），預(yù)購(gòu)（放入購(gòu)物車），賣出，退貨和下架幾個(gè)狀態(tài)，詳細(xì)請(qǐng)參看商品狀態(tài)圖 |
||
|
屬性名稱 |
類型 |
精度 |
說明(屬性的業(yè)務(wù)含義及業(yè)務(wù)規(guī)則) |
|
商品編號(hào) |
字符 |
12 |
商品類別編號(hào)(3位)+商品購(gòu)入年份(4位)+流水號(hào)(5)位 |
|
商品分類 |
數(shù)字 |
3 |
商品的分類 |
|
名稱 |
字符 |
100 |
商品的名稱 |
|
價(jià)格 |
數(shù)字 |
12 |
商品的價(jià)格 |
|
折扣 |
數(shù)字 |
6 |
折扣價(jià) |
|
產(chǎn)地 |
字符 |
100 |
商品產(chǎn)地 |
|
簡(jiǎn)介 |
字符 |
1000 |
商品的內(nèi)容簡(jiǎn)介，上架時(shí)錄入 |
|
狀態(tài) |
字符 |
1 |
商品的狀態(tài)，可參看商品狀態(tài)圖 |
下面給出說明書表提到的商品狀態(tài)圖。
當(dāng)然并不是每個(gè)實(shí)體都必須要畫出一個(gè)狀態(tài)圖，對(duì)于那些只有兩三個(gè)狀態(tài)或者沒有狀態(tài)的實(shí)體。完全可以不畫狀態(tài)圖。但對(duì)于有較多狀態(tài)的實(shí)體，建議還是不要偷懶的好。
好了，萬里長(zhǎng)征終于走了一半了。到目前為止，整個(gè)需求分析階段算是基本完成了?；仡櫼幌虑懊娴臄⑹?，從提取執(zhí)行者，到獲得用例，再而根據(jù)用例寫出業(yè)務(wù)場(chǎng)景，再對(duì)用例進(jìn)行詳細(xì)的分析從而勾勒出用例場(chǎng)景，最后再到發(fā)現(xiàn)業(yè)務(wù)實(shí)體，并理清他們之間的關(guān)系，同時(shí)對(duì)他們的屬性進(jìn)行挖掘。我們經(jīng)過了一個(gè)從朦朧到初步認(rèn)識(shí)的過程，在這段過程中，我們積累了很多的成果，也學(xué)會(huì)了畫許多樣的UML圖形，但是一切還是顯得那樣雜亂，還是顯得那樣沒有條理性，現(xiàn)在我急需的是一個(gè)文檔，對(duì)上面所述的一切進(jìn)行歸類與整理，以使之更容易被人所明白與理解。這個(gè)文檔就是需求說明書。本文檔提供一個(gè)需求說明書的例子(此文檔僅作例子，具體需求說明書版式，需采用公司統(tǒng)一標(biāo)準(zhǔn))，見附件1。需求說明書也將作為輸出文檔。輸出到下一個(gè)階段--設(shè)計(jì)階段。當(dāng)然實(shí)際的RUP要輸出的東西更多，具體可參見RUP相關(guān)資料。
3.2 系統(tǒng)設(shè)計(jì)
- 劃分子系統(tǒng)
這一過程理論上是屬于需求分析階段，當(dāng)用例越積越多時(shí)，就已經(jīng)有必要對(duì)用例進(jìn)行整理與分類，將功能相盡或者相關(guān)度較高的用例歸入一個(gè)比較大一點(diǎn)的類里，從而形成組件，再繼續(xù)歸類，從而形成子系統(tǒng)。當(dāng)然這一步，也可以放到設(shè)計(jì)階段來完成。所以將這一部分的內(nèi)容寫到了這里。如果需求階段已經(jīng)劃分了子系統(tǒng)，在設(shè)計(jì)階段直接繼承，如果沒有，則需在設(shè)計(jì)階段的第一環(huán)節(jié)劃分出子系統(tǒng)。對(duì)此我不準(zhǔn)備再作過多的敘述，各位可參考相關(guān)的資料。接口也同樣。須各位自行去查考相關(guān)的資料，這畢竟只是一個(gè)文檔，不是一本書。
要說明的一點(diǎn)是，在需求階段劃分出來的子系統(tǒng)，在設(shè)計(jì)階段需要再審查一下，進(jìn)行進(jìn)一步的優(yōu)化。優(yōu)化的過程貫穿于整個(gè)設(shè)計(jì)階段。接口也同樣。這就是跨階段的迭代，當(dāng)然要盡量避免這種跨階段的迭代。如果你有過多的跨階段迭代，就有必要重新審查一下你的需求分析做的是不是有什么問題了 。
- 設(shè)計(jì)”類”
類的設(shè)計(jì)是從分析業(yè)務(wù)實(shí)體（領(lǐng)域模型）開始的。最初的類的設(shè)計(jì)就是簡(jiǎn)單的將需求分析階段分析出來的業(yè)務(wù)實(shí)體用類的形式表現(xiàn)出來。當(dāng)然業(yè)務(wù)實(shí)體之間的關(guān)系，以及業(yè)務(wù)實(shí)體的屬性，也都應(yīng)一并繼承下來。做完了這些后我們要做的就是分析類的形為，類的形為也叫類的方法，有些書籍上也叫類的責(zé)任或者消息。當(dāng)然現(xiàn)在我們先不著急做這一步，先將上面分析出來的業(yè)務(wù)實(shí)體 轉(zhuǎn)成類的形式 再講。類圖如下
屬性信息我就不在這里表述出來了，實(shí)在是太煩了，時(shí)間也緊。
有了這張圖，下面我們開始在他的基礎(chǔ)上分析一下類的形為。分析類的形為的具體方法不在本文檔里進(jìn)行討論，相關(guān)的資料和書籍N多，可以自己去看。
下面僅列出經(jīng)過簡(jiǎn)單分析后重新更新過的類圖，在這個(gè)類圖中加入了形為
當(dāng)然這個(gè)類圖并不是完善的，也不一定是合理的，在此僅僅只是用來舉例而已，各位不用太過深究了。在進(jìn)行類的行為分析時(shí)一定要綜合所有的和類有關(guān)的用例進(jìn)行分析。同時(shí)記住一個(gè)很重要的觀點(diǎn)，就是類只對(duì)自己負(fù)責(zé)。用戶類絕不會(huì)去添加商品，因?yàn)樘砑由唐凡皇怯脩舻呢?zé)任，而應(yīng)該是購(gòu)物車或者訂單的責(zé)任。購(gòu)物車類也絕不會(huì)去登錄。因?yàn)榈卿浭怯脩舻呢?zé)任。而不是購(gòu)物車的責(zé)任。
不知道你是否還記得在進(jìn)行用例分析時(shí)，用例分析完成后，引入了業(yè)務(wù)場(chǎng)景和用例場(chǎng)景的概念。使之可以對(duì)用例的細(xì)節(jié)進(jìn)行分析，同時(shí)在分析業(yè)務(wù)場(chǎng)景和用例場(chǎng)景的同時(shí)，又進(jìn)一步的完善了用例。在類中也一樣。在把類分析出來后，便開始分析他的形為。然后根據(jù)形為開始分析他們之間的交互，在分析交互的過程中進(jìn)一步的去完善你的類。迭代，又是迭代。是的。在RUP中，迭代是無處不在的。
記住，從需求分析繼承過來的類并不是最終的類，需求分析階段主要面向的還是客戶，直接繼承過來的類還僅僅停留在業(yè)務(wù)的層面上，但在進(jìn)行設(shè)計(jì)時(shí)我們卻不得不考慮到業(yè)務(wù)在計(jì)算機(jī)里的實(shí)現(xiàn)問題，因此會(huì)對(duì)這些類進(jìn)行調(diào)整，優(yōu)化，擴(kuò)展，以使之更適應(yīng)于計(jì)算機(jī)的實(shí)現(xiàn)。這些調(diào)整包括運(yùn)用面向?qū)ο蟮囊恍┨匦?，例如繼承，重載等對(duì)類都行重構(gòu)。在重構(gòu)的同時(shí)?？赡軙?huì)出現(xiàn)許多與具體業(yè)務(wù)無關(guān)的類，雖說他們和業(yè)務(wù)沒有什么關(guān)系。但在使一個(gè)業(yè)務(wù)在計(jì)算機(jī)中得以實(shí)現(xiàn)時(shí)卻是必不可少的。所以這些類你也必須得如實(shí)的反應(yīng)于你更新后的類圖上。當(dāng)然現(xiàn)在我們還是先不著急去管這些，目前緊要的還是進(jìn)行類的交互分析。
#p#
在類的交互分析中最常用到的是順序圖和狀態(tài)圖。至于交互圖愛畫不畫
一般情況下，一個(gè)用例的一個(gè)場(chǎng)景必須對(duì)應(yīng)一個(gè)順序圖，順序圖是為了表現(xiàn)用例中所涉及的類之間的消息傳遞的過程,這個(gè)表述可能讓你有點(diǎn)不明白，換種說法，順序圖就是表現(xiàn)用例中所涉及的類之間的調(diào)用順序。其實(shí)第一種表述中的消息指的就是類的方法。前面也已經(jīng)指出過類的方法的表述有很多種，消息，責(zé)任，行為。但是無論怎么表述，內(nèi)容都還是一樣的，只是不同的表述用于不同的語境而已。這個(gè)知道即可。
狀態(tài)圖和順序圖有所不同，順序圖的主體是用例，而狀態(tài)圖的主體是類。狀態(tài)圖表現(xiàn)了一個(gè)類在其參與的所有用例中的狀態(tài)的改變及其觸發(fā)條件。狀態(tài)圖異常復(fù)雜，要想真正的理解恐怕還得你去找相關(guān)的資料多多的研究一下。這里不再作說明。、
下面我們延續(xù)上面的例子，繪制一張訂購(gòu)貨物的主場(chǎng)景的順序圖，狀態(tài)圖太復(fù)雜了，而且前面也沒有列舉其它的用例，所以在這里就不畫了。
訂購(gòu)貨物主成功場(chǎng)景順序圖
在這張圖中，并沒有畫出查找目錄的相關(guān)交互過程。那是因?yàn)楸疚臋n在進(jìn)行業(yè)務(wù)實(shí)體分析時(shí)，考慮到只是舉個(gè)例子而已，故只簡(jiǎn)單的畫了幾個(gè)實(shí)體，思考的并不是很全面。不小心將商品目錄這個(gè)業(yè)務(wù)實(shí)體給丟掉了。但又為了免于唐突，在這里也就沒有把和他相關(guān)的交互過程表現(xiàn)出來，要不然突然冒出來一個(gè)沒見過的類對(duì)象。反而更容易讓人糊涂。雖然這個(gè)業(yè)務(wù)實(shí)體很重要，但在這里我就不因?yàn)樗ジ轮暗南嚓P(guān)圖例了。這實(shí)在是太費(fèi)事了。大家知道怎么回事就成了。當(dāng)然在實(shí)際的操作過程中，這種思想可要不得。一旦你發(fā)現(xiàn)了這種問題，一定要一直的向上追朔，直到將所有相關(guān)的內(nèi)容和圖例全部更新為止。
當(dāng)然實(shí)際情況下，這張序列圖對(duì)于開發(fā)人員來說無疑是一個(gè)噩夢(mèng)，這個(gè)序列圖所表現(xiàn)的那個(gè)用例涉及了過多的間斷性動(dòng)作，導(dǎo)致了這個(gè)序列圖中很多動(dòng)作都是不連續(xù)的，如果用WEB開發(fā)的術(shù)語來講，就是這個(gè)序列圖中包含了過多的請(qǐng)求：在一個(gè)頁(yè)面只有一個(gè)HTTP連接的情況下頁(yè)面刷新一次叫一個(gè)請(qǐng)求，這樣在實(shí)現(xiàn)時(shí)就需要技術(shù)人員去把這個(gè)序列圖分解，然而這個(gè)分解過程是很痛苦的，當(dāng)然這不是開發(fā)人員的錯(cuò)，造成這種情況的原因是從一開始(進(jìn)行用例分析)的時(shí)候我們就沒有遵照前面提到的一條原則—一個(gè)用例最好是表示一個(gè)不間斷的動(dòng)作。當(dāng)然這個(gè)問題并不是不可解決的，因?yàn)橹灰獙⒃鹊哪莻€(gè)龐大的用例進(jìn)行分解就行了，當(dāng)然這也并不是說，這條用例就沒有存在的必要了，事實(shí)上恰恰相反，這種粗粒度的用例卻是必不可少的，因?yàn)榱６冗^細(xì)，就會(huì)導(dǎo)致用例膨脹，如果沒有這種粗粒度用例進(jìn)行歸類的話，會(huì)導(dǎo)致非常大的混亂，不易讓人理解。這就產(chǎn)生矛盾了，一方面你說一個(gè)用例最好表示一個(gè)不間斷的動(dòng)作，一方面又說大粒度的用例必不可少，^_! 你這不是自己打自己嘴巴嗎？事實(shí)也確實(shí)該打嘴巴，當(dāng)然打歸打問題還得解決，解決的方法其實(shí)很簡(jiǎn)單，只須再引入一些概念即可，即是用例的包含與繼承關(guān)系，大用例包含多個(gè)小用例，當(dāng)然包含的原始目的是為了用例的重用，但根據(jù)目前我的實(shí)際經(jīng)驗(yàn)，把一個(gè)大用例完全分解成各個(gè)小用例，然后大用例包含所有的分解后的小用例，這些小用例可以繼續(xù)分解，直到用例是表示一個(gè)連續(xù)的動(dòng)作（在WEB中則最有可能的是一次請(qǐng)求，或叫一次會(huì)話）為止，也就是說葉子節(jié)點(diǎn)上的用例都表示一個(gè)連續(xù)的動(dòng)作。繪制序列圖時(shí)，也只需繪制葉子節(jié)點(diǎn)上的用例即可。當(dāng)然以上是個(gè)人經(jīng)驗(yàn)之總結(jié)，對(duì)不對(duì)我也不太清楚，各位仔細(xì)掂量，附 用例與用例之間的包含與擴(kuò)展的原始意義 作為參考
用例與用例之間的包含與擴(kuò)展的原始意義：包含關(guān)系表示一種從屬關(guān)系，即子用例是主用例中相對(duì)獨(dú)立的、必須調(diào)用的一部分功能。在用例分析中，我們應(yīng)當(dāng)將多個(gè)用例都共有的、相對(duì)獨(dú)立的功能提取出來形成一個(gè)子用例，為日后代碼復(fù)用提供有力保障。擴(kuò)展關(guān)系表示一個(gè)功能是對(duì)另一個(gè)功能的擴(kuò)展，即被擴(kuò)展功能不一定調(diào)用擴(kuò)展功能，但擴(kuò)展功能是對(duì)被擴(kuò)展功能的加強(qiáng)與延伸。在繪制用例關(guān)系時(shí)，包含關(guān)系應(yīng)繪制成從主用例指向子用例的虛線箭頭，并標(biāo)注為“include”，表示主用例包含子用例；擴(kuò)展關(guān)系應(yīng)繪制成從擴(kuò)展用例指向被擴(kuò)展用例的虛線箭頭，并標(biāo)注為“extend”，表示擴(kuò)展用例是對(duì)被擴(kuò)展用例的擴(kuò)展。虛線箭頭在UML中代表的是一種依賴關(guān)系，即客戶元素了解供應(yīng)者，并且供應(yīng)者的變化會(huì)影響到客戶元素（依賴是從客戶元素指向供應(yīng)者的）。
通過對(duì)順序圖和狀態(tài)圖的分析，可以讓我們更有效的去完善類的屬性以及它的方法。從而，使我們的設(shè)計(jì)更加的接近于客戶的要求。但這還遠(yuǎn)遠(yuǎn)不夠，因?yàn)槟壳拔覀儍H僅是停留在完善的層次上，還不能說是一個(gè)優(yōu)秀的設(shè)計(jì)。甚至連成功的設(shè)計(jì)都還算不上。因?yàn)榈侥壳盀橹刮覀冞€沒有考慮到復(fù)用的問題。
復(fù)用大致分為三個(gè)層次。從低到高依次為，代碼級(jí)復(fù)用，組件級(jí)復(fù)用，服務(wù)級(jí)復(fù)用。
- 代碼級(jí)的復(fù)用：主要依靠面向?qū)ο蟮奶匦?，如繼承，重載，抽象等。此級(jí)別復(fù)用的執(zhí)行者是代碼開發(fā)人員。（注：建議用組合來代替繼承）
- 組件級(jí)的復(fù)用：主要依賴于設(shè)計(jì)模式，例如FACTORY，F(xiàn)A?ADE，ABSTRACT，F(xiàn)ACTORY等。這一層面的復(fù)用的執(zhí)行者一般為設(shè)計(jì)人員。
- 服務(wù)級(jí)的復(fù)用：這個(gè)復(fù)用的層次最高，理解也最為困難，如有興趣可自行查看關(guān)于SOA以及云計(jì)算的相關(guān)信息。個(gè)人認(rèn)為這個(gè)粒度太粗，把握起來很困難，實(shí)際運(yùn)行時(shí)，見機(jī)行事。
對(duì)于復(fù)用的其它相關(guān)知識(shí)，本文檔就不再做什么深入的討論了，各位也可自行查閱相關(guān)的資料，只要記住考慮復(fù)用是在已經(jīng)發(fā)現(xiàn)了盡可能完善的類后進(jìn)行的就可以了。當(dāng)然這也不一定，如果你的經(jīng)驗(yàn)夠豐富，可能不自覺的在設(shè)計(jì)前期就已經(jīng)將復(fù)用考慮進(jìn)去了，所以我們還是具體情況具體對(duì)待吧，不用搞的那么死。
- 數(shù)據(jù)庫(kù)相關(guān)
按著上面所述的步驟，經(jīng)過一次又一次的迭代，一次又一次的反復(fù)。終于興奮的發(fā)現(xiàn)，原來我們也可以做出優(yōu)秀的設(shè)計(jì)。于是乎我們迫不及待的將這些設(shè)計(jì)的成果發(fā)給了開發(fā)人員，并自信的對(duì)他們說如果照著這個(gè)做，保證能做出來一個(gè)優(yōu)秀的系統(tǒng)。然而事實(shí)呢，開發(fā)人員拿到我們這些所謂的優(yōu)秀成果?？峙鲁肆R爹罵娘罵你祖宗十八代，其它的什么事也做不了。的確，經(jīng)過上面的迭代，我們的設(shè)計(jì)看起來已經(jīng)非常的優(yōu)秀了，但事實(shí)的情況是：根本無法實(shí)現(xiàn)。因?yàn)榈侥壳盀橹刮覀冎辽龠€少考慮了一個(gè)極其重要的部分。那就是持久化支持，當(dāng)然這個(gè)名詞聽起來有點(diǎn)玄乎。說白了，就是怎么保存數(shù)據(jù)。再白一點(diǎn)就是講你的這個(gè)設(shè)計(jì)怎么和數(shù)據(jù)庫(kù)扯上關(guān)系(當(dāng)然你也可以使用其它存儲(chǔ)方法，但這里我們只考慮普遍情況)。
當(dāng)然這里我也只是講出有這么一個(gè)過程。具體怎么映射（扯關(guān)系就叫映射），是一個(gè)類映射成一張表呢，還是一個(gè)類映射成多張表呢，亦或多個(gè)類映射成一張表呢。又或者怎么處理有繼承關(guān)系的類到數(shù)據(jù)表的映射等等，諸如此類，請(qǐng)自己查閱相關(guān)文檔。當(dāng)然處理完成后。別忘了畫些ER圖啊什么的，這是必須的。
又經(jīng)過了一個(gè)漫長(zhǎng)的發(fā)現(xiàn)，分析，改正并不斷迭代的過程。終于，概要設(shè)計(jì)的所有東西我們都分析出來了，也完善了。什么子系統(tǒng)，組件，接口，類,以及他們之間的交互，包括數(shù)據(jù)庫(kù)都寫的很詳細(xì)很清楚并且很明白了，同時(shí)又不辭勞苦的用UML工具，將這些所對(duì)應(yīng)的什么子系統(tǒng)圖，組件圖，接口圖，類圖，類順序圖，類狀態(tài)圖，甚至類交互圖，包括ER圖也都畫出來了。然而你卻驚奇的發(fā)現(xiàn)。當(dāng)你再次把這些東西發(fā)給開發(fā)人員，然后告訴他們，你去實(shí)現(xiàn)吧的時(shí)候，他們?nèi)匀涣R了你的祖宗十八代。的確，這次你是沒有把數(shù)據(jù)庫(kù)設(shè)計(jì)給拉下，但如此混亂的一堆東西，恐怕也是沒幾個(gè)人能夠接受的吧。所以下面我們有必要象整理分析成果時(shí)一樣對(duì)設(shè)計(jì)成果也進(jìn)行一番整理。這并不是件麻煩的事，有現(xiàn)成的格式讓你套――概要設(shè)計(jì)說明書。按著概要設(shè)計(jì)書的目錄，將你之前那一堆毫無章法，東一個(gè)西一沱的所謂優(yōu)秀設(shè)計(jì)的混亂成果們，分門別類放進(jìn)去，然后你就可以將這個(gè)概念設(shè)計(jì)說明書放心的傳到下一個(gè)環(huán)節(jié)，順利的結(jié)束這段折磨人的旅途了。當(dāng)然如果下一環(huán)節(jié)是詳細(xì)設(shè)計(jì)說明書的話，恐怕還得逮著你。但一般情況下，詳細(xì)設(shè)計(jì)說明書的情況不多，一般都是直接到開發(fā)人員哪里去了。
結(jié)語:正如開篇所言，推導(dǎo)過程不是一個(gè)一成不變的東西，以上的東西僅供參考而已。
開發(fā)軟件不是生產(chǎn)產(chǎn)品，當(dāng)然開發(fā)軟件也不是搞藝術(shù)設(shè)計(jì)，確切的講，應(yīng)該是介于這兩者之間的東西。鼓勵(lì)創(chuàng)意的同時(shí)又約束部分的形為、需要流程而又不局限于流程。這就是軟件設(shè)計(jì)：一個(gè)世界上最差勁的藝術(shù)設(shè)計(jì)，外加一個(gè)世界上最糟糕的生產(chǎn)過程
當(dāng)前標(biāo)題：需求分析與系統(tǒng)設(shè)計(jì)的面向?qū)ο笸茖?dǎo)過程
地址分享：http://www.fisionsoft.com.cn/article/cogcoio.html
