五 業務流程圖
聊到這裡，其實還是一行**也沒寫，呵呵，不過我們已經成功了一大半。架子已經有了，現在就差專案的業務流程了。
曾記得有次面試，面試官鄙視做客戶端或桌面應用程式的人，讓我感到很不爽，不過後來這個面試官居然成為我的領導。如果誰敢鄙視桌面應用程式，那我就會問他，中國除了求伯君的
wps，還有什麼比較拿得出手的軟體呢？
adobe
、autodesk
有誰能超越？其實桌面應用程式的業務流程複雜度遠遠超過伺服器業務流程的複雜度。如果誰把伺服器的業務流程設計的如同桌面應用程式，我想他一定是活得不耐煩了。
如果是設計終端，一般我使用
uml的活**和時序圖來描述業務流程，當然也需要結合產品經理們畫的流程圖了。
如果是設計服務端，我往往什麼圖也不畫，而是使用偽**來描述。因為服務端的流程往往非常簡單，它著重強調的是效能。如果終端也使用偽**，那死定了，呵呵！
在寫偽**的過程中，核心業務類就基本確定了，介面也可確定個大概（功能可以確定，但引數往往難以確定）。這裡捎帶提一句，我以前追求的
gof設計模式，在這裡就可以很好滴發揮作用了，
ooa的分析模式也可以被充分利用了。
其實到了這一步，幾乎架構設計就基本完成了。但還有三個比較大的東西需要我們做一下，那就是資料結構、演算法和介面協議。不過這三個東西是劃分到架構設計裡還是概要設計裡，就很難再區分了。我的經驗是，盡量把核心的東西都定義出來，這樣能保證後面的堆砌**過程不會偏離自己的設計，軟體質量有保障。如果把前面
5張圖紙叫做軟體工程的話，則可以把偽**過程叫做軟體過程。當你把軟體流程、資料結構、**風格等等這些都定義好以後，後面的過程則會非常順利且快速，專案絕對會按照自己預想的進度保質保量地完成。這裡想說的話還很多，以後有機會再展開吧。
軟體架構設計
首先我們應該了解什麼是軟體架構設計？架構大體分為以下幾種 邏輯架構 模組劃分 介面定義 領域模型 開發架構 技術選型 檔案劃分 編譯關係 物理架構 硬體分布 軟體部署 方案優化 執行架構 技術選型 控制流劃分 同步關係 資料架構 技術選型 儲存格式 資料分布 程式設計師向架構師轉型的關鍵突破 學會系...
軟體架構設計
在嵌入式軟體開發的專案中，很少見到有專案架構師這一工作職稱，但是大型專案的總是會有架構師一說。1 為什麼嵌入式開發很少會出現架構師這一職責。嵌入式開發的專案，一般有兩種模式 一類是 完全由開發人員自己設計 排除庫函式 另一類是基於固有的作業系統進行開發。前者一般都是針對特定應用，所有 的規模不會很大...
軟體架構設計
本章考點主要集中在 基於構件的開發模型，架構風格，架構評估，架構與質量屬性，設計模式。縱觀軟體架構技術的發展過程，可以認為經歷了4個階段 無架構設計階段 以組合語言進行小規模應用程式開發為特徵 萌芽階段 出現了程式結構設計主題，以控制流圖和資料流圖構成軟體結構為特徵。初級階段 出現了從不同側面描述系...