一切皆可抽象

嘴唇干裂可用石膏蜂蜜糊劑治療，效果極佳。用法：取熟石膏50克，過80目篩，加蜂蜜50克，冰塊3克，攪勻裝瓶備用。每日涂患處2～3次。一般3～4天即可治愈

道是悟的 而非學的 悟即思考
吾當生命不息 思考不止

思考的源泉來源于實踐和理論
理論在于多讀書 叫厚積 玄覽
實踐在于模擬 行動
思考在于從實踐和理論中 薄發 滌慮 抽取

行動當有目標指導約束監控 而不至偏離
快速行動當有成熟的模式資源培訓組織管理以及強大的支持力
吾輩注定做了實作者 就踏踏實實的實實在在做些事情

軟件設計通過軟件統設計模型來表示（參見《再議模型》），軟件設計評價是對軟件系統設計模型的評價。在這里，我們使用源系統表示軟件要實現自動化的系統，它處于實體空間；目標系統表示要實現的軟件本身，它處于形式空間。軟件表示模型（即系統分析模型和系統設計模型，參見《再議模型》）是溝通源系統和目標系統的橋梁。表示模型的形成需要一個過程，我們稱其為過程空間。下面我們使用圖形方式來描述：

?????????????? 這樣，軟件設計評價應該具有三類標準，分別是實體空間標準、過程空間標準和形式空間標準。

??????????????
??????????? 實體空間標準以源系統做為標準來度量系統設計模型。這依賴于我們對于源系統的認識程度，我們知道應該具有這樣一個標準，但實行起來非常困難。設計的合理性就是實體空間標準，它沒有一個具體的內容和形式。

??????????????
??????????? 過程空間標準在設計評價中經常被使用。它可以看作實體空間的間接標準，基于分析模型和設計模型是出于同一實體，其中具有自然的關聯。我們說，設計是否附合需求，就是檢驗設計模型和分析模型的一致性。

???????????????
??????????? 形式空間標準以目標系統的角度檢驗系統設計。從上述兩種標準，可以保證目標系統的功能滿足源系統，但不能保證目標系統在運行狀態下的質量屬性。所以形式空間標準是從目標系統的質量出發來考察系統設計的。考慮到質量，我們使用McCall/GE質量模型，它圍繞產品改進、產品運行、產品移交三種使用情況來組織質量屬性，可以看出是基于目標系統的。國際上有很多現行的基于質量評價系統設計的方法，我們后面會參考其中的部分。
??????????? 雖然從理論上我們可以知道軟件設計評價具有三類標準，但卻沒有辦法真正按照這些標準去檢驗一個軟件的設計。

??????????????
??????????? 實體空間標準應該是一個軟件設計最終應該附合的標準。但是，這個標準很難直接應用于軟件設計模型上，因為軟件設計是思維的產物，在實體上檢驗這個產物是否正確，恐怕只能說“實踐是檢驗真理的唯一標準”了。只有在錯誤非常明顯的情況下，這個標準才會起作用。

???????????????
??????????? 過程空間標準相對好一些。通過和軟件生產過程前期階段產物進行對比，可以找到其中不一致的地方，這可能就是設計上的問題了。同時，現代軟件開發一般采用迭代的方式進行，設計活動可能分多次進行。這種迭代也要求我們檢查設計對需求的覆蓋情況。

???????????????
??????????? 通過形式空間標準對軟件設計進行檢驗時，往往并不存在一個唯一的檢驗標準。這是因為實際軟件的質量要求不是唯一的，不同的軟件有不同的質量屬性要求。而特定軟件的質量要求，是在需求分析、設計的過程中逐步形成的。這些質量要求，最終成為我們檢驗軟件設計的標準之一。

??????????????? 根據這些標準，我們現在設計一個軟件設計評價表模版：

????????????????? 軟件設計評價表
????????????????? 軟件名稱 迭代周期
????????????????? 設計人員
????????????????? 評審人員
????????????????? 設計合理性
??????????????????
??????????????????
??????????????????
??????????????????
????????????????? 需求附合度
????????????????? 功能點覆蓋率（FPC）?%重點功能點覆蓋率（IFPC）?%
????????????????? 優先功能覆蓋率（PFPC）?%需求一致度(Should be 100%)?%
????????????????? 質量屬性
????????????????? 模塊性權重在過程中確定權重分數，100分制，下同
????????????????? 可修改性權重權重之和應為100%
????????????????? 可擴展性權重下同
????????????????? 性能權重?
????????????????? 可靠性權重?
????????????????? 可用性權重?
????????????????? 可移植性權重?
????????????????? 可維護性權重?
????????????????? 靈活性權重?
????????????????? 可重用性權重?
????????????????? 可理解性權重?
????????????????? 彈性權重?
????????????????? 安全性權重?
????????????????? 容錯性權重?
????????????????? 評審結論
??????????????????
??????????????????
??????????????????
??????????????????

??????????????? 在設計合理性方面，主要考慮以下內容：

????????????? 類的職責單一、明確
????????????? 模塊結構清晰、完整
????????????? 活動、行為描述清晰
????????????? 實體關聯清楚，狀態合理

??????????????? 對需求附合度的要求要在評價之間確定。

???????????????
??????????? 質量屬性的評價權重一般在設計開始之前確定，這個工作多數在架構設計時刻完成。最后，
根據質量屬性的權重，可以計算設計的總體質量分數。這些都是最終評審結論的素材。

???????????????
??????????? 一般來說，對于設計的評價通過建立場景的方法來實現。比如評價可修改性，一般先建立一個修改的場景，
對設計進行模擬修改，觀察其是否易于修改。有些質量屬性無法通過這種方法檢驗，只能通過對設計模型進行觀察得出
結論。
????????????

巖前倚杖看云起；
松下操琴待鶴歸。

閱透人情知紙厚
踏穿世路知山平

多言即少味，
無欲斯有為。

寵辱不驚，看庭前花開花落；
去留無意，望天上云卷云舒。

長空有月明兩岸；
秋水不波行一舟。

香分花上露;
水吸石中泉。

月下共對一壺酒,
花前相看知心人。

繁忙?? 繁雜的忙 讓你勞累卻不解決實質問題
忙碌 忙的碌碌無為
忙亂? 忙的都亂了 不如不忙
慌忙 呵呵 別慌 慢慢來

所以我發明了個? 忙果 忙的結了大結果（果實的果喲 不是惡果）

重購的基本思想：
第一，提取，包括類（子類，超類等），函數。也就是把表達一個單獨的邏輯含義的包裝在一起，更好的表現他獨立的意義。
這個里面就有一系列的Extract方法，Extract Method，Extract Class，把長的邏輯表達式也表示為由意義的單元。
第二，為變量函數等選擇合適的地方，可能他們更多的與其他的類或者函數交互因而更應該那個類的方法或者變量。有一系列的
Move方法。move from，to，up，down。
第三，替換，用類型和Override來替代Switch，用Stratey，State模式來特換函數，以提供可變的行為。改變函數名，類的名
字，讓他們更有意義。
第四，所謂的臭味，如同我們維護別人的代碼，看著看著我們就忘了他在做什么了。這個里面有兩個最突出的臭味，大和長
（男人會認為有什么不對嗎？個人感覺挺好的，特別是如果你身邊有個馬SS的話）。大的函數，大的類，長長的參數，長長的
數據成員等等。這時就要把他們break into pieces.
第五，重構的方法學，小步前進，重視單元測試，持續重構。

?

項目管理：
1，合理的計劃制訂和風險應對措施以及團隊構建結構
2，深入了解團隊成員并結合1的成果進行合理的分工或者人員招聘
3，建立完善的資源獲取渠道和高效的溝通渠道
4，建立高效的培訓指導機制和目標注入方式
5，和上層，客戶，市場部門，質量部門等協同部門間平等且直通的渠道

架構設計：
1，優秀的架構和簡潔的接口（簡潔如藝術的優雅）
2，明晰的層次和良好的擴展
3，可檢測的性能指標設計

概要設計：
1，合理的功能劃分和類骨架設計
2，主要流程的時序設計
3，核心實體以及配置文件的數據結構
4，技術難點的攻克和核心算法的設計

詳細設計：
1，類屬性和方法的設計和核心程序的實現
2，內部流程的時序

?

代碼實現：
1，標準的注釋 簡賅的語言
2，良好的程序結構和異常處理

質量保證：
1，每日的簡短跟蹤和每日的實現部署
2，嚴格的質量指標制訂
3，嚴格的版本控制和資源控制

業務用例對角色（什么樣的個體和接口訪問到我們識別出來的各種業務任務）
業務對象對業務對象（各個業務對象之間是如何彼此交互的，和他們共享信息的種類）
用例對用例（任務彼此之間的依賴，和被一定的過程共享的公用任務

用例設計誤區
用例被創建的太大或者太小 －－ 粒度問題
用例在跨越團隊的情況下不一致? －－ 用例一致性（形式 含義）
沒有對用例分組的包進行良好的計劃? －－ 模塊劃分不合理
不合理的對模型的訪問進行控制，導致在團隊分析協作的過程中發生沖突? －－ 開放式團隊管理
過于細致的定義用例，在用例進入原型、設計和開發任務之前就定義每一件事情? －－ 粒度太小 需求確定的可以這么做 不穩定的當抽象為主 對應變更
定義用例時過于簡單，使需求被工程團隊可以有眾多的解釋? －－ 言語還是不確定 無法用語言表達的借助圖形 圖形無法描述的 定義術語集合 語言支持

角色模型
模塊模型

在從用例向設計類轉化的過程中，我們希望能夠實現：

將分析小組的知識傳授給工程團隊。?? －－ 文檔傳承 結構合理易于理解的文檔（加以詳細注釋）不失為最好的選擇
識別能夠滿足所有需求的技術方案 — 或者，什么地方不是可能的，識別與技術方案沖突的需求，并確定是否他們是重要的或者被改變或者被刪除。
?－－ 需求階段應該加入這樣的分析和模型了
識別能夠幫助確定團隊結構、架構層次和對于購買軟件的候選的接口。
?－－ 整合好的方案 不能整合的以清晰的頭腦單做
指定技術方案的細節并開始計劃如何在團隊之中分配工作。
?－－
基于設計模型的細化時間進行計劃和預算的預估。
?－－ 經驗 改進
分配類到平臺、產品和私有代碼。
?－－ 拿手完
為了反饋和同步的目的，生成軟件架構文檔，軟件架構文檔能夠被分發到內部和外部的團隊成員。
?－－ 傳承溝通

我們如何組織通用的服務？
回答：公用服務被單獨的放在一個子包中（日志服務；數據同步和備份服務；訪問控制服務和登陸服務）。
我們應該在 shipping 和 part management 之間畫線嗎？
回答: 我們不需要連接他們兩個。
我們根據領域還是架構來定義子系統？
回答：架構在大多數地方都能與領域結合。
我們允許包之間的雙向依賴嗎？
回答：不。這是違背我們內部設計指導方針的不好的設計實踐。
MDA 的觀點下有四個原則：

以一種定義良好的符號表示的模型是理解企業級方案系統的基礎。
系統的構建能夠圍繞著一系列模型通過使用在模型之間的一系列轉換被組織的，并且能被組織到一個分層的和轉換的體系架構框架中。
以一系列元模型來描述模型的一種正式的支持能力能夠使在模型中有意義的集成和轉換變得容易，并且是通過工具實現自動化的基礎。
接受和廣泛采納基于模型的方法需要工業的標準提供開放性給客戶，并鼓勵供應商之間的競爭。

OMG已經定義了一系列的層次和轉換，他們為MDA提供了概念性的框架和詞匯表。
特別的，OMG 確定了四種模型類型：
計算無關的模型（CIM），
平臺無關的模型（PIM），
被一個平臺模型（PM）描述的平臺相關的模型（PSM）和
一個實現相關的模型（ISM）。

問題領域模型和方案領域模型
業務建模 數據建模 安全建模 性能建模
狹義上講，它是關于一個系統的不同抽象模型，和在模型之間定義良好的模型轉換的。
廣義上講，它是關于抽象的各種級別上的模型，這些抽象作為基礎為軟件架構服務，這些架構最終將通過各種實現技術被實現。

癡人癡夢斥恥淚
緣散緣盡怨鴛恨

立絕壁頂望三千尺深溝
握金剛鉆鑿五萬里長卷

傾半生力寫七仞行酸詩
給一張臉抽九百團紅印

春時青草綠欲滴
冬秋枯黃灶底柴
青春人生過有時
惜時打拼遍嘗味

?

住田園種梯田年年穿戴田產棉
聽泉聲飲冽泉天天侍弄泉澆園
剩余的糧食和棉賣成錢
換來閑錢買來了紙和鹽
寫下了酸文撞倒了醋壇
可憐不可憐 唉 夢醒了

在浮躁的年代里，我們進取心太切，患得患失；虛榮心太強，戰戰兢兢。一心爭強好勝，惟恐榜上無名。
???? 說起來夸夸其談、頭頭是道，做起事來心中無數、手足無措。
在浮躁的年代里，我們嘩眾取寵,急功近利，惟名是圖。于是我們盲目追趕朝流、投機取巧，不做實事、也做不出實事。
在浮躁的年代里，我們為達目的，不擇手段。于是我們盜版，隨意踐踏別人的勞動成果，侵犯別人的知識產權。
在浮躁的年代里，我們隨波逐流，沒有主見，沒有定力，人云亦云。于是我們只能整天圍著Microsoft、IBM、SUN轉圈。

因為我們浮躁，所以我們沒有目標。
因為我們浮躁，所以我們沒有發明C/C++、Java、Ruby，甚至面對Spring、Hibernate，我們也只有膜拜。
因為我們浮躁，所以我們做學問只得天天面對無趣的English，并美其名曰：“師夷長技以自夷”。
做官因為浮躁，所以成為庸官；做學問因為浮躁，所以一事無成；做人因為浮躁，所以為人淺薄。
在浮躁的年代里做學問難，做好學問更是難上加難！

??????????????? －－－－－以上引自某強人貼????

當浮躁成為流行的時候? 給你打招呼的時候 我會說：這兩天你浮躁了嗎
你會說 當然浮躁了 不浮躁別人不給發工資呀

為了不浮躁，先用好別人的東西，再創新出自己的產品！！
8月18 Infoer-BDF(bussiness data flow)-EAI For Soa 第一版一定出品。