#
這篇也是轉(zhuǎn)載，改了中間部分內(nèi)。
在基于注解方式配置Spring
的配置文件中，你可能會(huì)見到<context:annotation-config/>這樣一條配置，他的作用是式地向 Spring
容器注冊(cè)
AutowiredAnnotationBeanPostProcessor、CommonAnnotationBeanPostProcessor、
PersistenceAnnotationBeanPostProcessor 以及 RequiredAnnotationBeanPostProcessor 這 4 個(gè)BeanPostProcessor。
注冊(cè)這4個(gè) BeanPostProcessor的作用，就是為了你的系統(tǒng)能夠識(shí)別相應(yīng)的注解。
例如：
如果你想使用@Autowired注解，那么就必須事先在 Spring 容器中聲明 AutowiredAnnotationBeanPostProcessor Bean。傳統(tǒng)聲明方式如下：
- <bean class="org.springframework.beans.factory.annotation. AutowiredAnnotationBeanPostProcessor "/>
如果想使用@ Resource 、@ PostConstruct、@ PreDestroy等注解就必須聲明CommonAnnotationBeanPostProcessor
如果想使用@PersistenceContext注解，就必須聲明PersistenceAnnotationBeanPostProcessor的Bean。
如果想使用 @Required的注解，就必須聲明RequiredAnnotationBeanPostProcessor的Bean。同樣，傳統(tǒng)的聲明方式如下：
- <bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"/>
一般來說，這些注解我們還是比較常用，尤其是Antowired的注解，在自動(dòng)注入的時(shí)候更是經(jīng)常使用，所以如果總是需要按照傳統(tǒng)的方式一條一條配置顯得有些繁瑣和沒有必要，于是spring給我們提供<context:annotation-config/>的簡(jiǎn)化配置方式，自動(dòng)幫你完成聲明。
不過，呵呵，我們使用注解一般都會(huì)配置掃描包路徑選項(xiàng)
- <context:component-scan base-package=”XX.XX”/>
該配置項(xiàng)其實(shí)也包含了自動(dòng)注入上述processor的功能，因此當(dāng)使用 <context:component-scan/> 后，就可以將 <context:annotation-config/> 移除了。
本文轉(zhuǎn)載：http://mushiqianmeng.blog.51cto.com/3970029/723880
有一段時(shí)間沒有關(guān)注spring了，spring2.5就蠻夠用的，spring3出來后一直沒怎么關(guān)注。
這幾天抽空關(guān)注一下。干咱這行的還是要緊跟時(shí)代變化啊。
下邊這些內(nèi)容是轉(zhuǎn)載51cto的一篇文章。
1、項(xiàng)目結(jié)構(gòu)與構(gòu)建變化
解壓后的立即發(fā)現(xiàn)，Spring 3.0的項(xiàng)目結(jié)構(gòu)已經(jīng)發(fā)現(xiàn)了巨大變化：
1、Spring3采用多項(xiàng)目結(jié)構(gòu)源碼組織，不再是以前的單一方式，共26個(gè)項(xiàng)目，差不多每個(gè)項(xiàng)目對(duì)于一個(gè)分發(fā)的jar包，不過有些項(xiàng)目是空的，或者是為了構(gòu)建而設(shè)。
2、不再提供完整打包文件spring.jar，而是20個(gè)jar（或稱bundle），一方面應(yīng)該也是向osgi靠攏。
Spring 3.0的readme中說道：
Note that this release does not contain a 'spring.jar' file anymore, in contrast to previous Spring generations. Furthermore, the jar file names follow bundle repository conventions now.
（51CTO編輯快譯：與之前的Spring版本相反，此次發(fā)布不再包括spring.jar文件了。新版本中的jar文件命名由bundle版本庫(kù)的規(guī)則所決定。）
3、采用Ivy為主構(gòu)建方式，當(dāng)然仍然有Maven，項(xiàng)目結(jié)構(gòu)由Maven管理。另外沒有打包全部的依賴包了，整個(gè)下載包比2.5的小了近一半
4、Spring3已經(jīng)完全采用Java5/6開發(fā)和編譯構(gòu)建，因此應(yīng)該是不再支持Java1.4及更早版本了
2、框架結(jié)構(gòu)的變化
框架結(jié)構(gòu)的架構(gòu)圖也進(jìn)一步演變了，不再是原來那個(gè)簡(jiǎn)單的方塊圖：
Spring3架構(gòu)圖
跟原來的相比，DAO、ORM、JEE等模塊被劃歸到了一起，成為“數(shù)據(jù)訪問/集成”部分，Web層突出了自己的MVC(Servlet)和Portlet，核心容器增加了表達(dá)式語言。另外，對(duì)測(cè)試的支持也放到了整個(gè)架構(gòu)中來了。所以整個(gè)框架重新劃分成了五部分。
因此，典型的全應(yīng)用場(chǎng)景也相應(yīng)變化，并提示使用自家的Tomcat：
關(guān)于eclipse的一些應(yīng)用，開發(fā)過程中用到了就隨手記下。
1.Web App Libraries and Eclipse Build Path
在eclipse下創(chuàng)建web項(xiàng)目，在build path下會(huì)對(duì)應(yīng)包含Web App Libraries 動(dòng)態(tài)加載項(xiàng)目下/WebContent/WEB-INF/lib所有的jar文件。
好處是在項(xiàng)目增加或刪除jar包時(shí)不用總是修改build path配置文件，從cvs同步代碼的時(shí)候保持這部分不變。
2.system library
有些jar在開發(fā)的時(shí)候要用到，但是部署的時(shí)候不用部署到服務(wù)器。
比如:jsp-api.jar,servelet.jar，這些文件在tomcat jboss 下已經(jīng)包含，重復(fù)部署的話會(huì)引起錯(cuò)誤。
我以前的做法是在anr build.xml文件中打包生成war時(shí)刪除對(duì)應(yīng)的jar包。
剛發(fā)現(xiàn)還有這么一種用法，在eclipse添加system library把jar添加到該庫(kù)下就不會(huì)部署到服務(wù)器。
如圖:主要tomcat-jar 一定要設(shè)置成system library
關(guān)于在創(chuàng)業(yè)公司工作的話題，以前跟同事討論過，剛看到這么一篇，轉(zhuǎn)載一下。
有人在Quora問了這個(gè)問題：What startup could make me a millionaire in four years if I got hired as an emplyee today？
Symbolic Analytics的創(chuàng)始人Brandon Smietana在下面做了很長(zhǎng)的回答，內(nèi)容很精彩，不過請(qǐng)勿對(duì)號(hào)入座：
大多數(shù)創(chuàng)業(yè)公司的退出（exit)，都是通過M&A（并購(gòu)），而不是通過IPO(首次公開募股），現(xiàn)在大多數(shù)的M&A價(jià)格都低于3000萬美元，最典型的價(jià)格是1500萬美元，現(xiàn)在我們來假設(shè)一個(gè)最樂觀的退出案例，從其中的數(shù)據(jù)中算出，我作為創(chuàng)始人和CEO，能夠拿多少錢；從而計(jì)算出，你，作為一個(gè)員工可能賺得的利益。
（一）
假定案例
1）我拿到1000萬的投資。
2）投資人擁有公司50%的股權(quán)（樂觀估計(jì)）。
3）我將公司以3000萬的價(jià)格出售。
4）我擁有30%的外流通股（Outstanding Share) ，非常樂觀的估計(jì)。
投資人還擁有優(yōu)先股，通過并購(gòu)，他們首先把自己投入的錢收回來，然后再參與省下的股權(quán)收益分紅。
1）在3000萬的退出中，投資人首先拿回他們投入的1000萬，剩下2000萬。
2）然后，優(yōu)先股股東吃掉省下2000萬的50%的利益分紅，于是他們拿走另外1000萬。
3）現(xiàn)在，整個(gè)脫售的現(xiàn)金只剩下1000萬，分享這份利益的關(guān)系者包括大眾股東，公司員工，創(chuàng)始人和管理團(tuán)隊(duì)。
我，作為創(chuàng)始人和CEO，享有最多的普通股股權(quán)，價(jià)值這1000萬美元的大概600萬。省下的400萬利益歸屬其他所有的普通股股東（包括所有的公司員工）
最典型的早期員工，在利益分紅中能拿到的資產(chǎn)不足CEO的1/30，因此，一位非常重要的早期員工，能夠從脫售中取得20萬美元的利益。
現(xiàn)在，讓我設(shè)想得不那么樂觀，相對(duì)實(shí)際一點(diǎn)。70%進(jìn)入A輪融資的創(chuàng)業(yè)者，除了工資，其他什么利益都無法從公司獲得。因此作為一名員工，
1）有70%的可能，如果你在A輪融資的時(shí)候加入創(chuàng)業(yè)公司，你的普通股是沒有價(jià)值的。
2）與A輪以前的早期員工相比，A輪以后的員工通過股權(quán)或者期權(quán)能拿到的利益要少很多。
3）在A輪融資以后，新員工能夠拿到的最好的股權(quán)大概在0.3%左右。
4）無論什么樣的員工，他們的股權(quán)都會(huì)在管理層更換或者新一輪融資中被稀釋。
（二）
如果我進(jìn)入的公司是”下一個(gè)Facebook”呢？
硅谷在過去的十年里發(fā)生了驚天動(dòng)地的變化。這些變化，同時(shí)作用并且影響著IT員工們能從公司那里獲取的利益。
如果你在1998年以前（包含1998年）加入了一家在將來很成功的創(chuàng)業(yè)公司，那你一定已經(jīng)賺了很多錢。但是，如果你加入的是Facebook，你所能獲取的利益價(jià)值可能就無法跟前者媲美了。那么，那些加入“下一個(gè)Facebook“的哥們兒，希望可能就更小了，以下是原因：
谷歌的早期員工在加入時(shí)，谷歌的估值還很低。
1）谷歌的估值，一路從4000萬漲到了2000億。
2）那些最早加入谷歌的清潔工，從谷歌獲得價(jià)值1000美元的股權(quán)，在2008年也價(jià)值400萬美元。
3）一個(gè)獲得了5萬美元股權(quán)的工程師，他的股權(quán)在2008年價(jià)值1億美元。
4）谷歌的大廚也獲得了價(jià)值2800萬的股權(quán)。
有四點(diǎn)原因說明，谷歌的員工為何能夠金融上收益如此好：
1）他們?cè)诠咎幱诤艿凸乐档臅r(shí)候獲得股票期權(quán)。
2）從A輪融資到現(xiàn)在，谷歌的估值漲了4000倍。
3）公司員工以人為的超低協(xié)議價(jià)格獲得購(gòu)買期權(quán)（大概只相當(dāng)于每股股價(jià)的1/10還要低），因?yàn)楫?dāng)時(shí)IRS(美國(guó)國(guó)稅局）的409（a)條款還不存在呢。
4）由于協(xié)議價(jià)格足夠低，因此員工在行權(quán)時(shí)，繳納的是資本利得稅15%（Capital Gain Tax），而不是收入稅50%（Income Tax treatment)。
當(dāng)谷歌發(fā)行股票給他的員工時(shí)：
1）公司處于低估值階段，而非后來的頂峰估值階段。
2）那時(shí)，美國(guó)國(guó)稅局還沒有執(zhí)行409(a)條款，409（a)條款明確規(guī)定了員工期權(quán)的估值。
在十年以前，創(chuàng)業(yè)公司都會(huì)以低于估值的協(xié)議價(jià)格發(fā)給員工期權(quán)，以吸引有識(shí)之士。員工因此有可能通過公司IPO而一夜致富，他們行權(quán)的協(xié)議價(jià)格大概之相當(dāng)于估值價(jià)的1/10。
而到今天，這么做就是不合法的了。現(xiàn)在，公司的主管們，依據(jù)83（b)條款，依然有權(quán)通過限制性股票（restricted stock)獲得低估股票（undervalued stock)；但是，現(xiàn)在獲得將理性期權(quán)（Incentive Stock Options)的員工，就必須遵循IRS的的409（a)條款。同時(shí)，現(xiàn)在的員工，在行權(quán)時(shí)更可能繳納50%的收入稅，而不是15%的資本利得稅。
隨著更高的早期估值，現(xiàn)在的員工已經(jīng)不太有可能有現(xiàn)金能夠行權(quán)，而且也不太有可能繳納資本利得稅，一般都繳納收入稅。409（a）條款通過明確規(guī)定，也防止了員工行權(quán)價(jià)像十年前那么低?，F(xiàn)在，一個(gè)創(chuàng)業(yè)公司的員工，如果行使價(jià)值200萬美元的ISO期權(quán)（國(guó)際標(biāo)準(zhǔn)期權(quán)），在繳納了加州稅或者德州稅之后，仍然可能面臨50%的收入稅。
一般情況下：創(chuàng)始人和主管們獲得的是依據(jù)83（b)條款的限制性股票（Restricted Stock),并且繳納的是15%的資本利得稅，員工則更可能時(shí)取得福利期權(quán)（Incentive Options), 稅率相對(duì)更高。
因此，作為一名員工，即便有一天你的公司被賣了，你也可能要繳納50%的收入稅。
200萬瞬間就只剩100萬，而現(xiàn)在，舊金山的房?jī)r(jià)是300萬。
（三）創(chuàng)業(yè)公司估值之于員工的影響
以前所有關(guān)于谷歌員工勝出的理由，現(xiàn)在都有可能不復(fù)存在了。
新的創(chuàng)業(yè)公司，如Facebook，獲得很高的早期估值，因此，早期員工能獲得的利益相比以前的創(chuàng)業(yè)公司，就少很多了。
更重要的是，現(xiàn)在只有越來越少的大型IPO，取而代之的是越來越多的小型M&A。
圖片一： 1992年 — 2009年 風(fēng)險(xiǎn)投資也IPO和M&A交易的比例
大多數(shù)公司并沒有谷歌和Facebook那樣做得很好。即便在Facebook，也只有一小部分員工積累財(cái)富。
Zuckerberg在Facebook的股權(quán)大致相當(dāng)于Facebook所有非主管的員工股權(quán)的總和（24%vs30%).。前50個(gè)Facebook的非主管員工所獲得的股權(quán)，差不多相當(dāng)于后面25000個(gè)員工的總和。
股權(quán)就是金字塔，越升一級(jí)，差俱就越大。
在一個(gè)以3000萬被并購(gòu)的公司退出案例里（見上），一個(gè)很成功的M&A退出。公司的CEO也差不多只能賺600萬美元。
（四）創(chuàng)業(yè)領(lǐng)域與員工回報(bào)的關(guān)系
有很多創(chuàng)業(yè)公司扎根在大眾互聯(lián)網(wǎng)領(lǐng)域（Customer Internet Space), 但是這個(gè)領(lǐng)域的投資回報(bào)率也最低。就拿Facebook舉例（最成功的消費(fèi)者互聯(lián)網(wǎng)公司之一），它從每一個(gè)月度活躍用戶那里只能產(chǎn)生3美元/年的利益。
很少的大眾互聯(lián)網(wǎng)公司能夠通過廣告獲得盈利，像Ad.ly, Digg, Myspace, Twitter,還有很多其他的公司都很難達(dá)到大規(guī)模盈利，即便是用戶量非常龐大。
一個(gè)大眾互聯(lián)網(wǎng)公司，如果每個(gè)月的活躍用戶數(shù)有50萬，依照Facebook的盈利推算，一年的盈利也只有150萬美元。因此，不要把大眾互聯(lián)網(wǎng)當(dāng)做救命稻草。
現(xiàn)如今，B2B/SaaS模式，以及生物技術(shù)市場(chǎng)，仍然能夠在市場(chǎng)上攫取上億的資金，但是，很少有人能有能力和經(jīng)驗(yàn)在這個(gè)市場(chǎng)里把公司做起來。但是，在這領(lǐng)域，卻有比大眾互聯(lián)網(wǎng)市場(chǎng)更多的盈利機(jī)會(huì)。
最有盈利空間的市場(chǎng)，最難發(fā)現(xiàn)創(chuàng)業(yè)公司。特別是，金融領(lǐng)域每年攫取的利潤(rùn)占全美公司利益的70%，但是，在硅谷卻很難發(fā)現(xiàn)金融創(chuàng)業(yè)公司，即便有，也基本是大眾金融服務(wù)。
Protip: 從數(shù)據(jù)和理論上看，如果你是A輪以后加入大眾互聯(lián)網(wǎng)公司的員工一枚，你的股權(quán)幾乎就不值錢了。
Hadoop最近很火，到處都能看到，查了一下資料大概先了解一下其運(yùn)行原理。
google在05年公開了Map/Reduce論文，MapReduce在處理巨量數(shù)據(jù)方面有明顯優(yōu)勢(shì)。
google公司一個(gè)技術(shù)大牛jefffery Dean提出的這個(gè)算法，隨后很多小牛紛紛實(shí)現(xiàn)了Mapreduce,Hadoop是它的java實(shí)現(xiàn)，MapReduce概念直接推動(dòng)了云計(jì)算概念的火爆。
沒有優(yōu)秀算法云是沒法搞的。
這篇文章對(duì)Map/Reduce原理講的很清楚。
http://www.chinacloud.cn/download/Tech/MapReduceOverview.pdf
這個(gè)是Apache關(guān)系Hadoop的文檔，安裝、開發(fā)示例都有。
http://hadoop.apache.org/common/docs/r0.19.2/cn/mapred_tutorial.html
因?yàn)橐恢痹谧銎髽I(yè)信息化方面的開發(fā)，有必要了解一下相關(guān)的理論。
同事推薦的幾本書。
霍頓(F.W.Horton)的信息資源管理(IRM)理論
威廉。德雷爾的數(shù)據(jù)管理(DA)理論
詹姆斯馬丁的信息工程方法論(IEM)
看了之后有些吃驚，很多概念和理論都是上世紀(jì)80年代，還有60年代就提出的概念，做了這么久的開發(fā)居然沒聽說過，在規(guī)劃方面沒有一定的理論指導(dǎo)，都是些野路子方法。
還有許多平時(shí)用到的概念和方法找到了淵源，原來是這哥們或那哥們提出，老外的版權(quán)意識(shí)就是強(qiáng)對(duì)幾十年前提出的理論都會(huì)整理出哪個(gè)觀點(diǎn)是哪個(gè)人提出的。
不然很多方法一直覺得理所當(dāng)然是那么用的，看過這些資料才知道理論提出的背景，除了這種理論解決哪些問題還有哪些方法，各有什么優(yōu)缺點(diǎn)。
信息工程理論總結(jié)起來，就是以數(shù)據(jù)規(guī)劃為基礎(chǔ)，自定向下規(guī)劃。并提供了一系列的技術(shù)用于自下向上的設(shè)計(jì)方法。對(duì)企業(yè)信息化中比較重要的業(yè)務(wù)流程有很大的篇幅。
目前的收獲是，1.在系統(tǒng)規(guī)劃方面有了完整的理論指導(dǎo)；2.了解了規(guī)劃、分析、設(shè)計(jì)階段會(huì)有哪些技術(shù)，哪些已掌握的技術(shù)需要加強(qiáng)、哪些技術(shù)需要學(xué)習(xí)。
老外的書翻譯過來的在中文版看著費(fèi)勁，找了本國(guó)內(nèi)編譯出版的，寫得不錯(cuò)。
信息工程與總體規(guī)劃概述。
本書討論計(jì)算機(jī)信息系統(tǒng)總體規(guī)劃的方法論，重點(diǎn)是總體數(shù)據(jù)規(guī)劃。
第一章是本文的綜述，目的是使讀者盡快了解信息工程概念和總體數(shù)據(jù)規(guī)劃方法的大意，因此是全書的提綱。
第二章到第四章是信息工程產(chǎn)生的背景和方法論的分析。這三章按三個(gè)主題展開：數(shù)據(jù)處理危機(jī)與轉(zhuǎn)折；信息工程的原理、方法與工具；信息工程與結(jié)構(gòu)化方法。
第五章到第十章比較全面深入地介紹總體數(shù)據(jù)規(guī)劃的一整套方法，是本書的主體。編者根據(jù)近幾年參與中大型企業(yè)計(jì)算機(jī)信息系統(tǒng)總體規(guī)劃設(shè)計(jì)工作的實(shí)踐，深感探討先進(jìn)科學(xué)的方法論的極端重要性，特別是總體數(shù)據(jù)規(guī)劃的內(nèi)容、方法，以及與后續(xù)開發(fā)工作的銜接等問題，更是迫切需要解決的。為此，我們較全面地翻譯介紹了詹姆斯·馬丁所倡導(dǎo)的一整套方法，供有興趣的讀者參考，從而盡快形成適合我國(guó)國(guó)情的總體規(guī)劃方法論。
第一章
從需求分析開始的傳統(tǒng)生命周期開發(fā)方法論
數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)是相對(duì)穩(wěn)定的，而數(shù)據(jù)的處理過程則是經(jīng)常變化的?？傮w數(shù)據(jù)規(guī)劃方法。
軟件工程僅僅是關(guān)于計(jì)算機(jī)軟件的規(guī)范說明、設(shè)計(jì)和編制程序的學(xué)科，實(shí)際上信息工程的一個(gè)組成部分。
信息工程的基本原理和前提是：
1.數(shù)據(jù)位于數(shù)據(jù)處理的中心。
2.數(shù)據(jù)是穩(wěn)定的，處理是多變的。數(shù)據(jù)類型是不變的。
只有建立的穩(wěn)定的數(shù)據(jù)結(jié)構(gòu)，才能是行政管理或者業(yè)務(wù)管理上的變化為計(jì)算機(jī)信息系統(tǒng)所適應(yīng)，這正是面向數(shù)據(jù)系統(tǒng)所具有的靈活性，面向過程系統(tǒng)往往不能適應(yīng)管理上的變化需求。
3.用戶必須真正參與開發(fā)工作。Design with,not design for.
第二章
信息工程的組成部分
自定向下規(guī)劃和自下向上設(shè)計(jì)方法論
重點(diǎn)分為三個(gè)部分：
企業(yè)模型、實(shí)體關(guān)系分析和數(shù)據(jù)模型的建立（即主題數(shù)據(jù)庫(kù)的規(guī)劃），以及數(shù)據(jù)分布規(guī)劃。
總體數(shù)據(jù)規(guī)劃簡(jiǎn)介
四類數(shù)據(jù)庫(kù)環(huán)境
1.數(shù)據(jù)文件；
2.應(yīng)用數(shù)據(jù)庫(kù)
3.主題數(shù)據(jù)庫(kù)
4.信息檢索系統(tǒng)
規(guī)劃方法
1.進(jìn)行業(yè)務(wù)分析建立企業(yè)模型
2.進(jìn)行實(shí)體分析建立主題數(shù)據(jù)庫(kù)模型
3.進(jìn)行數(shù)據(jù)分布分析
第三章
信息工程概貌
1.關(guān)于全面開放的規(guī)劃
2.關(guān)于業(yè)務(wù)分析
3.關(guān)于數(shù)據(jù)分析，數(shù)據(jù)可以表達(dá)成與使用無關(guān)
4.關(guān)于自動(dòng)化工具
信息工程的基本組成
1.企業(yè)模型，企業(yè)模型的開發(fā)是在戰(zhàn)略數(shù)據(jù)規(guī)劃期間進(jìn)行的。
2.借助實(shí)體關(guān)系分析，建立信息資源規(guī)劃。這是自頂向下的數(shù)據(jù)類型分析，這些數(shù)據(jù)是必須被保存起來的，還要分析他們之間是如何聯(lián)系的。
3.數(shù)據(jù)模型的建立，產(chǎn)生詳細(xì)的數(shù)據(jù)庫(kù)邏輯設(shè)計(jì)
導(dǎo)致信息工程產(chǎn)生的一個(gè)重要認(rèn)識(shí)，是組織中存在的數(shù)據(jù)可以描述成與這些數(shù)據(jù)如何使用無關(guān)的形式，而且數(shù)據(jù)需要建立起一定的結(jié)構(gòu)。這一點(diǎn)較面向?qū)ο蟮乃枷牒芙咏?，可以把?shù)據(jù)模型任務(wù)是數(shù)據(jù)對(duì)象。
信息工程的建設(shè)基礎(chǔ)
戰(zhàn)略的數(shù)據(jù)規(guī)劃工作
信息工程方法論
1.關(guān)于企業(yè)信息化戰(zhàn)略規(guī)劃的方法
2.關(guān)于信息系統(tǒng)設(shè)計(jì)實(shí)現(xiàn)的方法
3.關(guān)于自動(dòng)化開發(fā)工具
第四章結(jié)構(gòu)化方法與信息工程
信息工程是在進(jìn)行戰(zhàn)略需求規(guī)劃，信息需求規(guī)劃，總體數(shù)據(jù)規(guī)劃和數(shù)據(jù)分布規(guī)劃的基礎(chǔ)上，使用結(jié)構(gòu)化設(shè)計(jì)和結(jié)構(gòu)化編程的方法。
結(jié)構(gòu)化系統(tǒng)分析
數(shù)據(jù)流圖
結(jié)構(gòu)化系統(tǒng)設(shè)計(jì)
信息工程是面向數(shù)據(jù)的方法，結(jié)構(gòu)化方法是面向過程的方法。前者可以使用未來，后者只能使用過去和現(xiàn)在。
戰(zhàn)略需求規(guī)劃
戰(zhàn)略需求規(guī)劃是信息工程的基礎(chǔ)工作，不僅要對(duì)現(xiàn)有需求規(guī)劃，還要對(duì)未來需求規(guī)劃。
1.加強(qiáng)用戶之間的溝通合作。
2.加強(qiáng)高層領(lǐng)導(dǎo)者之間的溝通并為之提供支持。
3.提高資源需求預(yù)測(cè)和分配的準(zhǔn)確性。
4.提供內(nèi)部mis的可行點(diǎn)。
5.提出新穎而高質(zhì)量的應(yīng)用系統(tǒng)。
信息需求規(guī)劃
信息需求：
1.事務(wù)處理工作的管理信息需求；
2.高層領(lǐng)導(dǎo)者的管理信息需求；
3.企業(yè)發(fā)展和改革發(fā)展方面的信息需求；
傳統(tǒng)的軟件工程和數(shù)據(jù)庫(kù)技術(shù)盡管有分析設(shè)計(jì)方法，但缺乏自頂向下的規(guī)劃，不能適應(yīng)大型復(fù)雜系統(tǒng)的建設(shè)。信息工程強(qiáng)調(diào)總體規(guī)劃，形成了一套自頂向下規(guī)劃與自下向上設(shè)計(jì)的完成的方法學(xué)，為大型復(fù)雜系統(tǒng)的建設(shè)提供了保障。
第五章總體數(shù)據(jù)規(guī)劃的組織
戰(zhàn)略規(guī)劃
1.戰(zhàn)略業(yè)務(wù)規(guī)劃
2.戰(zhàn)略信息技術(shù)規(guī)劃
3.戰(zhàn)略數(shù)據(jù)規(guī)劃
戰(zhàn)略數(shù)據(jù)規(guī)劃，即總體數(shù)據(jù)規(guī)劃是信息工程規(guī)劃工作的核心和基礎(chǔ)，需要研究它的組織方法。
戰(zhàn)略規(guī)劃的目的是使信息系統(tǒng)的各部分能共同工作。
對(duì)戰(zhàn)略規(guī)劃的詳細(xì)程度要有恰當(dāng)?shù)睦斫狻?br />
第六章 企業(yè)模型
..........................
今天看了五章的內(nèi)容，休息一下。
忙完手頭工作繼續(xù)學(xué)習(xí)，2012-2-28
總體數(shù)據(jù)規(guī)劃的第一步是進(jìn)行業(yè)務(wù)分析，建立企業(yè)模型。(編者按：目前電信行業(yè)都已經(jīng)建立起了完善的企業(yè)模型，其他行業(yè)還沒看到)
企業(yè)模型是對(duì)企業(yè)結(jié)構(gòu)和業(yè)務(wù)活動(dòng) 本質(zhì)的、概況的認(rèn)識(shí)。
用職能區(qū)域--業(yè)務(wù)過程--業(yè)務(wù)活動(dòng) 這樣的層次結(jié)構(gòu)來描述。
1.研制一個(gè)表示企業(yè)各職能區(qū)域的模型；
2.擴(kuò)展上述模型，使它能表現(xiàn)企業(yè)的各項(xiàng)業(yè)務(wù)過程；
3.繼續(xù)擴(kuò)展上述模型，使它能夠表現(xiàn)企業(yè)的各項(xiàng)業(yè)務(wù)活動(dòng)。
依靠企業(yè)高層，分析企業(yè)的現(xiàn)行業(yè)務(wù)和長(zhǎng)遠(yuǎn)目標(biāo)，按照企業(yè)內(nèi)部的各種業(yè)務(wù)的邏輯關(guān)系，將他們劃分為不同的只能區(qū)域，弄清各職能區(qū)域包括的全部業(yè)務(wù)過程，再將各個(gè)業(yè)務(wù)過程細(xì)分為一些業(yè)務(wù)活動(dòng)。
建立分析企業(yè)模型的過程，是對(duì)現(xiàn)行業(yè)務(wù)系統(tǒng)再認(rèn)識(shí)的過程。
職能區(qū)域
職能范圍、業(yè)務(wù)范圍，是指一些主要的業(yè)務(wù)活動(dòng)區(qū)域，如銷售、市場(chǎng)、財(cái)務(wù)、認(rèn)識(shí)、生產(chǎn)。
職能模型，職能區(qū)域圖表
業(yè)務(wù)過程
企業(yè)模型的二級(jí)結(jié)構(gòu)是業(yè)務(wù)過程的識(shí)別、命名、定義。這項(xiàng)工作主要由分析人員來完成。
1.業(yè)務(wù)過程與組織結(jié)構(gòu)
2.識(shí)別業(yè)務(wù)過程的參考模式
產(chǎn)品、服務(wù)和資源四階段生命周期
計(jì)劃，獲得，保管，處置(編者按：原書有一張圖表，這里就不列出來了)，模式的每一階段都有一些業(yè)務(wù)過程的類型。
3.業(yè)務(wù)過程與負(fù)責(zé)人
4.經(jīng)驗(yàn)
業(yè)務(wù)活動(dòng)
每個(gè)業(yè)務(wù)過程中都存在一定數(shù)量的業(yè)務(wù)活動(dòng)
業(yè)務(wù)活動(dòng)分析
1.功能分解的程度
2.凝聚性活動(dòng)，1.產(chǎn)生清晰可識(shí)別的結(jié)果，2.有清楚的邊界，3.是一個(gè)執(zhí)行單元，4.自封閉的，獨(dú)立于其他活動(dòng)。
3.冗余活動(dòng)和功能組合，
企業(yè)模型的建立過程
可以理解為邏輯模型
企業(yè)模型的特點(diǎn)
完整性、適用性、永久性
關(guān)鍵成功因素
3~6個(gè)決定成功與否的因素
1.關(guān)鍵成功因素的確定
關(guān)鍵成功因素應(yīng)該成為最高層管理人員管理控制企業(yè)系統(tǒng)的基礎(chǔ)，對(duì)一個(gè)行業(yè)來講關(guān)鍵成功因素差不多是相同的。
如食品公司：廣告效果，貨物分發(fā)，產(chǎn)品革新
2.關(guān)鍵成功因素的審查
第七章主題數(shù)據(jù)庫(kù)
獨(dú)立于應(yīng)用的數(shù)據(jù)
數(shù)據(jù)庫(kù)環(huán)境的原則
1.企業(yè)的數(shù)據(jù)應(yīng)該得到直接管理，與使用的職能分開；
2.數(shù)據(jù)描述不應(yīng)由使用數(shù)據(jù)的應(yīng)用包含，而應(yīng)當(dāng)由獨(dú)立的數(shù)據(jù)管理員設(shè)計(jì)；
3.數(shù)據(jù)應(yīng)該獨(dú)立于現(xiàn)有機(jī)器資源；
4.使用統(tǒng)一的工具和設(shè)施管理資源；
5.有適當(dāng)?shù)陌踩捅Ｃ芸刂疲?br />6.高層管理人員要參與數(shù)據(jù)庫(kù)的總體規(guī)劃和決策。
面向過程的系統(tǒng)分析方法
面向數(shù)據(jù)的系統(tǒng)分析方法
主題數(shù)據(jù)庫(kù)與組織內(nèi)各類人、事、物相關(guān)，而不是與傳統(tǒng)的應(yīng)用相關(guān)。
總的來說這部分沒什么干貨，就是對(duì)前面方法論的細(xì)化和再次說明。
這本書側(cè)重于方法論和理論概念。在規(guī)劃部分有具體的指導(dǎo)，在具體分析和設(shè)計(jì)技術(shù)上著墨不多。
第八章實(shí)體活動(dòng)分析
第九章數(shù)據(jù)分布規(guī)劃
第十章規(guī)劃與開發(fā)建議
這兩天比較忙，后邊章先顧不上看了。
第八章和第九章應(yīng)該跟軟件工程里的內(nèi)容是一致的，原來項(xiàng)目開發(fā)時(shí)經(jīng)常要用到。第十章討論BSP方法，要了解一下。
因?yàn)轫?xiàng)目需要做了一個(gè)簡(jiǎn)單的工作流引擎，用于集成訂單管理(IOM)的生產(chǎn)調(diào)度。之前的文章有提到。原想著有這樣一個(gè)引擎來進(jìn)行生產(chǎn)調(diào)度，設(shè)計(jì)好業(yè)務(wù)流程后就可以面朝大海，春暖花開。在還生產(chǎn)系統(tǒng)對(duì)接的時(shí)候發(fā)現(xiàn)有一部分還是人工處理更好，畢竟不是所有的流程都能那么細(xì)致合理。
下面是我們的解決方案，圖片是從wps里另存出來的，不知道咋就變成黑底了。
1.1 問題描述
工作流引擎處理流程調(diào)度部分的內(nèi)容。客戶下訂單之后，協(xié)調(diào)各生產(chǎn)部門進(jìn)行工作。
最理想化的情況是對(duì)客戶發(fā)起的每一種操作都定義一組流程，在流程執(zhí)行的過程中每種狀下態(tài)當(dāng)有新的操作進(jìn)來也相應(yīng)定義一組流程，但這樣一來流程設(shè)計(jì)工作極其繁瑣，容易出錯(cuò)，不利于降低管理難度減輕管理工作量。
一個(gè)折中的方案是對(duì)執(zhí)行中的流程進(jìn)行流程合并。選擇對(duì)一部分操作不創(chuàng)建新流程，給用戶提示信息，由用戶覺得如何進(jìn)行手工操作。
1.2 問題分析
1.2.1 概念定義
生產(chǎn)平臺(tái)：生產(chǎn)平臺(tái)是由人和機(jī)器構(gòu)成的,能將一定輸入轉(zhuǎn)化為特定輸出的有機(jī)整體。對(duì)應(yīng)于工廠中的生產(chǎn)車間概念。
生產(chǎn)線：生產(chǎn)是與相關(guān)的一個(gè)部門或一組操作對(duì)應(yīng)的組織。類似于項(xiàng)目組的概念，是依據(jù)生產(chǎn)流程對(duì)生產(chǎn)能力的一種劃分方式。
產(chǎn)品：產(chǎn)品是指中企動(dòng)力運(yùn)用營(yíng)銷手段，將業(yè)務(wù)或業(yè)務(wù)組合附加上銷售對(duì)象、銷售地域、資費(fèi)計(jì)劃、銷售渠道、服務(wù)水平及配套資源屬性后的產(chǎn)物，是向客戶最終交付的、客戶可以購(gòu)買的產(chǎn)品單元組合實(shí)例。
產(chǎn)品單元：產(chǎn)品單元是業(yè)務(wù)在生產(chǎn)系統(tǒng)的具體表現(xiàn)。
產(chǎn)品單元與生產(chǎn)線之間是多對(duì)多的關(guān)系。如果一個(gè)產(chǎn)品單元需要跨多個(gè)生產(chǎn)線，引擎需要調(diào)度產(chǎn)品單元在不同生產(chǎn)線的生產(chǎn)過程。
流程組：流程組指由一系列操作流程組成的流程集合，有流程間的先后順序。流程組在此是由產(chǎn)品和操作類型共同決定的。
流程：流程是一系列操作環(huán)節(jié)的集合。環(huán)節(jié)間有并行和串行的關(guān)系。流程在此處是由平臺(tái)和操作類型決定的。
環(huán)節(jié)：環(huán)節(jié)是一系列操作的集合。環(huán)節(jié)此處定義是由一個(gè)人的一個(gè)或多個(gè)可并行的操作決定的。
任務(wù)：任務(wù)是可執(zhí)行的最小單位。任務(wù)具有原子性，是環(huán)節(jié)的組成部分。一般一個(gè)任務(wù)完成一個(gè)事務(wù)。
一個(gè)環(huán)節(jié)包含多個(gè)任務(wù)，一個(gè)流程包含多個(gè)環(huán)節(jié)，一個(gè)流程組包含多個(gè)流程。
1.2.2 問題描述
以一件定制服裝的過程為例，只是為了說明問題對(duì)流程做了簡(jiǎn)化。見下圖。
定制服裝生產(chǎn)流程：
最簡(jiǎn)化的情況，客戶在提交了定制服裝生產(chǎn)的要求后便不再干預(yù)，生產(chǎn)線就按流程走就可以了。
但是客戶可能會(huì)在生產(chǎn)的各個(gè)環(huán)節(jié)提出變更要求，已經(jīng)制作完成了客戶要求加個(gè)兜，已經(jīng)質(zhì)檢完成了客戶要求加個(gè)紐扣，已經(jīng)包裝好了客戶要求領(lǐng)子樣式改改。
如果把每一種可能都定義一組流程，就這個(gè)簡(jiǎn)化流程全部列出來也夠貼一面墻了。所以我們采取了一種折中的方案，在大多數(shù)情況下正在生產(chǎn)時(shí)客戶要求有變化，通過一個(gè)描述性的工單告訴生產(chǎn)線負(fù)責(zé)人暫停生產(chǎn)、并由負(fù)責(zé)人來決定回退到那個(gè)環(huán)節(jié)重新進(jìn)行。
如果都包裝好了客戶還要改，那就暫停當(dāng)前流程，走和客戶打官司的流程了，這種情況下需要一個(gè)流程。
本方案通過對(duì)生產(chǎn)中的流程進(jìn)行合并，減少流程定義的工作量和復(fù)雜程性度。
1.3 問題解決
1.3.1 工單
1.3.1.1 邏輯模型
訂單生成工單的過程，稱為合單。
|
訂單工單關(guān)系 |
工單屬性 |
|
|
|
現(xiàn)在所描述的都是對(duì)同一個(gè)訂購(gòu)實(shí)例所下各種訂單的合單處理情況。
1.訂購(gòu)實(shí)例第一次下訂單，根據(jù)訂單生成工單和工單明細(xì)。
2.訂購(gòu)實(shí)例第二次下訂單
a) 之前生成的工單已經(jīng)竣工，生成新工單和新工單明細(xì)。
b) 之前生成的工單還未生產(chǎn)，廢棄該工單，生成新工單和新工單明細(xì)
c) 之前生成的工單生產(chǎn)中，廢棄該工單，繼續(xù)沿用原工單編號(hào)，合并生成新工單和新工單明細(xì)。新工單狀態(tài)為生產(chǎn)中。
在工單明細(xì)表增加字段“產(chǎn)品單元變更標(biāo)識(shí)”，如果產(chǎn)品單元對(duì)應(yīng)的屬性內(nèi)容在兩次訂單中沒有變化，引擎不暫定產(chǎn)品單元觸發(fā)的流程。
1.3.2 流程實(shí)例化
1.3.2.1 邏輯模型
流程定義模型見下圖，概念定義部分對(duì)名詞有描述。
|
流程定義 |
流程實(shí)例化 |
|
|
|
在業(yè)務(wù)支撐系統(tǒng)經(jīng)常使用的一個(gè)概念，實(shí)例化。
用戶購(gòu)買一個(gè)產(chǎn)品后，就產(chǎn)生一個(gè)產(chǎn)品的實(shí)例化，區(qū)別于別的客戶購(gòu)買的同類產(chǎn)品，稱為訂購(gòu)實(shí)例。
定義一組流程用來處理產(chǎn)品生產(chǎn)過程，具體到某個(gè)訂購(gòu)實(shí)例的生產(chǎn)過程的實(shí)例化，就有了流程組實(shí)例、流程實(shí)例、環(huán)節(jié)實(shí)例和任務(wù)實(shí)例。
1.3.2.2 流程定義過程
有了流程定義的模型，我們就是可以設(shè)計(jì)或者叫定義產(chǎn)品的生產(chǎn)流程。
完成一件復(fù)雜的工作，總是需要一個(gè)步驟一個(gè)步驟的完成，每個(gè)步驟稱為一個(gè)環(huán)節(jié)，在這個(gè)環(huán)節(jié)下可能需要做幾個(gè)事情，每個(gè)要做的事情稱為一個(gè)任務(wù)。
1.根據(jù)生產(chǎn)部門劃分生產(chǎn)線
2.根據(jù)生產(chǎn)線+操作，定義流程，把流程中的任務(wù)根據(jù)負(fù)責(zé)人劃分為不同的環(huán)節(jié)。
3.按照產(chǎn)品涉及的流程劃分為不同的流程組。
1.3.2.3 流程實(shí)例化
1.實(shí)例化約束
a) 一個(gè)訂購(gòu)實(shí)例當(dāng)前只有一個(gè)運(yùn)行中的流程組實(shí)例；
b) 流程合并前先暫停，避免和引擎并發(fā)競(jìng)爭(zhēng)。
2.實(shí)例化過程
a) 接收工單，檢查訂購(gòu)實(shí)例當(dāng)前是否有流程組實(shí)例在運(yùn)行中；
i. 無，實(shí)例化一個(gè)新的流程組實(shí)例
ii. 檢查是否屬于同一個(gè)流程組定義
1. 是同一個(gè)流程組，進(jìn)行流程合并。
2. 不是同一個(gè)流程組，暫不實(shí)例化，待下一次輪詢?cè)偬幚怼?/span>
流程合并細(xì)節(jié)見《流程合并詳細(xì)設(shè)計(jì)》
1.3.3 流程引擎
1.3.3.1 模型狀態(tài)
1.已實(shí)例化
2.已分配(負(fù)責(zé)人)
3.執(zhí)行中
4.暫停
5.已完成
流程啟動(dòng)后按順序執(zhí)行，當(dāng)要回到上一步驟時(shí)，監(jiān)控頁面支持回退和回滾兩種操作。
回退，當(dāng)前執(zhí)行中/暫停的環(huán)節(jié)設(shè)置為已分配，上一環(huán)節(jié)由已完成設(shè)置為執(zhí)行中。
回滾，對(duì)任務(wù)可以執(zhí)行其反任務(wù)。
1.3.3.2 功能描述
1.引擎輪詢程序，檢查處于執(zhí)行中狀態(tài)的環(huán)節(jié)，如果環(huán)節(jié)下所有關(guān)鍵任務(wù)都已完成則環(huán)節(jié)進(jìn)入已完成狀態(tài)，下一環(huán)節(jié)進(jìn)入執(zhí)行中狀態(tài)。
2.環(huán)節(jié)實(shí)例化后處于已實(shí)例化狀態(tài)，用戶在任務(wù)分配頁面指定環(huán)節(jié)負(fù)責(zé)人，環(huán)節(jié)處于已分配狀態(tài)，上一環(huán)節(jié)完成后由引擎設(shè)置本環(huán)節(jié)進(jìn)入執(zhí)行中狀態(tài)。
3.鑒于引擎對(duì)執(zhí)行中的環(huán)節(jié)進(jìn)行調(diào)度工作，實(shí)例化程序和頁面監(jiān)控程序在對(duì)執(zhí)行中的環(huán)節(jié)操作時(shí)，需先暫停環(huán)節(jié)。
4.監(jiān)控頁面支持對(duì)流程、環(huán)節(jié)的回退，支持對(duì)任務(wù)的回滾。
之前做了一個(gè)簡(jiǎn)單的工作流引擎，干完了活做點(diǎn)理論總結(jié)。
項(xiàng)目見
工作流應(yīng)用---理論基礎(chǔ)篇、
工作流應(yīng)用---概念、模型這個(gè)工作流引擎主要是根據(jù)項(xiàng)目需求和網(wǎng)上看到的一些文章提到的概念做出來的，估計(jì)比較野路子，想著把概念和名詞向大師靠攏。
過了年剛來不忙，這幾天抽空看了兩本工作流方面的書，《工作流管理技術(shù)基礎(chǔ)》和《工作流管理：模型、方法和系統(tǒng)》，講的比較細(xì)致、對(duì)基礎(chǔ)概念講的很清楚，就是書老了點(diǎn)。
書中對(duì)XPDL標(biāo)準(zhǔn)做了詳細(xì)描述，對(duì)新出的BPEL沒有涉及。
我自己項(xiàng)目中用到的概念和大師們基本一致，大方向不錯(cuò)，看來網(wǎng)上找到的那幾篇文章挺靠譜的，當(dāng)時(shí)應(yīng)該隨手整理出來。
工作流引擎做的比較簡(jiǎn)單，沒有使用主流的petri技術(shù)，只支持項(xiàng)目需求更負(fù)責(zé)的需求就夠嗆了，回頭有空再改一版?？戳藭虐l(fā)現(xiàn)有這么多種模型實(shí)現(xiàn)方法早都有人研究很多年了。
這兩本書在超星網(wǎng)站都能找到電子版。
IPO模型，過程中的每一個(gè)活動(dòng)都由輸入(I)、處理(P)、輸出(O)三部分組成。
理論來自《科學(xué)管理》提出的科學(xué)管理原則：
一個(gè)組織的工作可以描述為一系列的任務(wù)，每個(gè)任務(wù)都是工人們具體、嚴(yán)謹(jǐn)?shù)幕顒?dòng)過程，管理就是在一定的計(jì)劃下讓這些任務(wù)以最優(yōu)的方式進(jìn)行。
常用的工作流模型：
1.基于活動(dòng)網(wǎng)絡(luò)的過程模型
組成模型的元素包括過程、活動(dòng)、模塊、控制連接弧、數(shù)據(jù)連接弧和條件。
以活動(dòng)作為構(gòu)成過程的基本單元，以連接弧體現(xiàn)過程邏輯，可以靈活的實(shí)現(xiàn)企業(yè)經(jīng)營(yíng)過程的建模，我做的那個(gè)基本上采用的就是這種模型。
過程：為完成目標(biāo)而定義的一系列步驟；
活動(dòng)：過程中的步驟；
模塊：跟過程的概念類似；區(qū)別在于是否可以多次重復(fù)使用
控制鏈接弧：定義兩個(gè)活動(dòng)間的執(zhí)行順序
數(shù)據(jù)連接?。憾x兩個(gè)活動(dòng)間的信息流
條件：定義過程執(zhí)行中的約束
定義在控制連接弧上的條件：轉(zhuǎn)移條件
活動(dòng)可以執(zhí)行和活動(dòng)被執(zhí)行：開始條件、結(jié)束條件。
優(yōu)點(diǎn)：
從系統(tǒng)分析的角度來看，有利于通過過程模型提取功能視圖和信息視圖、便于深入分析
從系統(tǒng)實(shí)現(xiàn)的角度來看，控制流管理和數(shù)據(jù)流管理分離，是不同性質(zhì)的流管理獨(dú)立。
2.事件驅(qū)動(dòng)的過程鏈模型
兼顧模型描述能力強(qiáng)和模型易讀兩個(gè)方面。
業(yè)務(wù)事件、業(yè)務(wù)功能、控制流、邏輯操作符、信息對(duì)象、組織單元
3.基于語言行為理論的工作流模型
IPO模型對(duì)于觀察信息和物流的流動(dòng)過程比較合適，但不利于不同角色間的委托和承擔(dān)行為。
語言行為理論則側(cè)重與解決，數(shù)據(jù)、物、人協(xié)作中IPO模型對(duì)人直接協(xié)作描述不足的情況。
聽上去不錯(cuò)，實(shí)際中沒有看到用這種模型的，google了一下相關(guān)資料，還只是一個(gè)理論在軟件領(lǐng)域用來進(jìn)行協(xié)作過程建模的很少。
簡(jiǎn)單了解一下先，等大師們研究明白了咱再學(xué)習(xí)。
4.基于petri網(wǎng)的工作流模型
這個(gè)東西看著挺復(fù)雜的，不過好多人都說是好東西，研究一下先。
找了兩本有關(guān)petri的書，都太理論化看不懂。還是《工作流管理：模型、方法和系統(tǒng)》講得比較通俗。
petri基本概念很好理解，不同于過程化分析，更接近面向?qū)ο蟮乃枷?。看起來我在這個(gè)項(xiàng)目中采用的分析方法更接近與petri，原來俺們樸素的想法跟大師很接近哦。
一般的面向?qū)ο蠓治龈鼈?cè)重與靜態(tài)結(jié)構(gòu)，在動(dòng)態(tài)模型部分描述的都不夠清楚。petri在動(dòng)態(tài)過程方面感覺很細(xì)致有效。據(jù)說還是經(jīng)過嚴(yán)格熟悉驗(yàn)證的分析方法，不過那些公式?jīng)]看懂，太費(fèi)勁。分析時(shí)用petri分析建模方法就可以了。
.....
上一篇講了工作流的主要概念和用途。
知道了要依靠工作流引擎來推動(dòng)流程向前。
這一篇講一個(gè)具體實(shí)現(xiàn)的例子,比較簡(jiǎn)單，對(duì)于復(fù)雜的流程關(guān)系定義處理不了，上下文參數(shù)構(gòu)建也不支持，這些依賴具體的業(yè)務(wù)領(lǐng)域模型處理了。
好在工作流基本的概念是有了，對(duì)于復(fù)雜的應(yīng)用可以借鑒成熟的產(chǎn)品，知道工作流是怎么回事了其他產(chǎn)品也就容易上手了。
工作流概念這一塊，目前也沒個(gè)統(tǒng)一規(guī)范，就自己搞了一套，沒采用那些推薦標(biāo)準(zhǔn)太復(fù)雜用不上。
要開發(fā)一個(gè)工作流引擎出來，跟其他開發(fā)沒有不同，概念、需求、建模。
一、搞清楚都要用到哪些概念
二、能夠提供哪些功能、準(zhǔn)備用例
三、建模
1.靜態(tài)模型
依據(jù)關(guān)鍵流程的用例推導(dǎo)概念、明確概念定義、支持概念所要用到的數(shù)據(jù)結(jié)構(gòu)
2.動(dòng)態(tài)模型
定義各功能模塊操作，并檢查是否覆蓋所有關(guān)鍵用例。
實(shí)際例子，懶得敲那么多字了，直接上圖
1.用例,用來確定系統(tǒng)邊界
2.主要概念，及概念見關(guān)系
3.流程生命周期定義
說明一下，分配狀態(tài)和運(yùn)行狀態(tài)是兩個(gè)維度的東西，為了省事就定義在一起了。
4.系統(tǒng)架構(gòu)
描述引擎的內(nèi)部構(gòu)成、引擎與外圍系統(tǒng)的關(guān)系。
這段時(shí)間因?yàn)轫?xiàng)目需要做了一小的工作流引擎，總結(jié)一下經(jīng)驗(yàn)。
大概會(huì)分為這么幾個(gè)階段來介紹。
1.理論基礎(chǔ)
2.實(shí)現(xiàn)技術(shù)
3.實(shí)際開發(fā)的一個(gè)例子。
如圖:
一、理論基礎(chǔ)
只是簡(jiǎn)單的討論原理，詳細(xì)數(shù)學(xué)理論不再這里討論，會(huì)在附錄里列出來，有興趣的同學(xué)自行查看。
1.概念
為了實(shí)現(xiàn)業(yè)務(wù)過程自動(dòng)化提出的概念。
以前去政府部門辦過事大家都有體會(huì)，那個(gè)迷茫啊困惑啊，很多連個(gè)辦事指南都沒有。
辦一件小事要蓋十幾個(gè)章，材料交上去后你根本不知道現(xiàn)在到了哪個(gè)部門，審核通過了沒人通知你，沒通過的話少什么資料也不告訴你，告訴你也不是一次都說，跑一趟說一點(diǎn)。通過了這個(gè)部門審核下一步應(yīng)該去哪也沒人告訴你。
這個(gè)時(shí)候有個(gè)對(duì)機(jī)關(guān)門清的人，知道哪里水深水淺，領(lǐng)著你辦下來該有多好，該請(qǐng)客請(qǐng)客該送禮送禮，少跑很多冤枉路，還能隨時(shí)查詢狀態(tài)。
這就是工作流引擎要做的事情。
2.發(fā)展歷史
工作流技術(shù)起源于二十世紀(jì)七十年代中期辦公自動(dòng)化領(lǐng)域的研究，由于當(dāng)時(shí)計(jì)算機(jī)尚未普及，網(wǎng)絡(luò)技術(shù)水平還很低以及理論基礎(chǔ)匱乏，這項(xiàng)新技術(shù)并未取得成功。
老外也是被扯皮扯怕了試圖改進(jìn)。
3.作用目標(biāo)
工作流將作為一個(gè)公共基礎(chǔ)子系統(tǒng)服務(wù)于整個(gè)平臺(tái)產(chǎn)品的人力工作流和業(yè)務(wù)工作流環(huán)節(jié)。
通過將工作活動(dòng)分解成定義良好的任務(wù)、角色、規(guī)則和過程來進(jìn)行執(zhí)行和監(jiān)控，達(dá)到提高生產(chǎn)組織水平和工作效率的目的。
人多了事情多了，扯皮的情況也就多了。為了避免扯皮建立一個(gè)協(xié)調(diào)中心，提供辦事指南，負(fù)責(zé)進(jìn)度管理，公共信息維護(hù)。
處理這種有復(fù)雜流程的事情目前有兩種解決思路:
1.針對(duì)業(yè)務(wù)領(lǐng)域開發(fā)一個(gè)系統(tǒng)，一個(gè)模塊處理完成一件事件后根據(jù)情況來決定下一步跳到哪個(gè)模塊，帶點(diǎn)什么參數(shù)。適應(yīng)于流程比較固定的業(yè)務(wù)，像財(cái)務(wù)系統(tǒng)雖然很復(fù)雜，但是各種處理規(guī)則都清清楚楚明明白白，也不會(huì)隨便變動(dòng)。
2.工作流方式，講流程跳轉(zhuǎn)規(guī)則由工作流引擎統(tǒng)一維護(hù)，每個(gè)具體執(zhí)行任務(wù)的模塊只管干自己的活，干完了告訴一聲引擎，由引擎通知下一個(gè)模塊。目前只能處理相對(duì)簡(jiǎn)單的一些工作流程，OA公文流轉(zhuǎn)，IOM生產(chǎn)系統(tǒng)調(diào)度這類規(guī)則不是很復(fù)雜，流程上下文較簡(jiǎn)單的情況。
對(duì)于特別復(fù)雜的流程，開發(fā)量反而比定制業(yè)務(wù)系統(tǒng)還要多。工作流理論需要再有一次提升才能解決這個(gè)問題。
4.體系特點(diǎn)
可維護(hù)性和可擴(kuò)展性
與業(yè)務(wù)系統(tǒng)實(shí)際關(guān)聯(lián)低偶合
可以擴(kuò)充表達(dá)式引擎，與界面綁定由界面引擎決定
可以適應(yīng)與審核等人力流程，也可以適用在無人干預(yù)的商業(yè)自動(dòng)化流程
安全性
易用性
5.模型表示
用例模型
應(yīng)用用例
擴(kuò)展用例
分析模型
架構(gòu)性重要分析元素
架構(gòu)性重要用例實(shí)現(xiàn)
設(shè)計(jì)模型
組件結(jié)構(gòu)
部署結(jié)構(gòu)
6.定義語言
7.參考資料