其他

最近系統學習了一個系統可靠性及其相關知識，今天在這總結一下。 首先，什麼是系統的可靠性呢？系統的可靠性是指在規定的時間內及規定的環境下完成規定功能的能力，也就是系統的無故障運行機率。 我會從以下幾個方面來歸納主要內容： 1. 故障模型 2. 可靠性模型 3. 可靠性指標 4. 可靠性設計 故障模型 系統故障是指硬體或者軟體的錯誤狀態，一般引進故障的原因是這些：組件的失效、環境的物理幹擾、操作錯誤或不正確的設計。 按照時間的長短，故障可以分為：永久性、間歇性、瞬時性。

    最近，GIX4項目需要開展客戶化工作。同時，下一期sprint中，客戶還要求大幅度提升產品的效能。針對所存在的問題，開發人員決定開一系列的技術討論會。    我總結了目前遇到的和可能遇到的問題：客戶化：    實體類客戶化        各客戶對同一產品表現出的需求，要求實體類在一定程式上各不相同。這就需要領域模型做到可以客戶化。    介面客戶化        需求不同，介面自然也需要客戶化。這是一般性需求。效能：    實體類最佳化       

文章目錄 ArchiMate 和 TOGAF (the Open Group Architecture Framework) 的關係架構金字塔架構組成架構描述圖例每層通用描述業務功能（Functions ）和角色（Actors）產品（Product）和服務（Services）服務（Services）和介面（Interfaces）商務程序（Business

此文屬轉載，原文連結：http://www.cnblogs.com/viter/archive/2010/11/03/1868377.html本文如下： 我承認，這個標題很沉重。我有幸使用了一個開源的項目作為小範圍內的二次開發應用。這個項目其實是挺大的，開原始碼僅是其中一部分，在二次開發中我對原始碼作了一些改進，都是一些必要的改進以及發現的BUG；這些BUG在後續的開源參與者一一修複。我想說的是重構過程中的一些小問題。一、如果你決定重構代碼，特別是別人的代碼，最好對整個項目有一個清晰的認識，最好

最近涉及重構話題的文章不少啊，其實我也一直在憧憬重構，重構很綠色，重構很河蟹，重構令人很激動，重構可能讓人死得很慘。我在這裡，就列舉一下Refactorman的種種死法，以警後人：一、一邊重構，一邊要完成日常任務……1. 疲於奔命，過勞而死。2. 吃領導給的鴨梨太大被噎死。3. 滿腦子都是代碼，在上班路上不留神撞上了寶馬。4. 冷落了女友，受失戀打擊跳樓而死。5. 無暇社交，不懂人情世故，失意而死。6. 為了說服領導和同事，心力交瘁而死。二、重構過程中……7. 被以前的混賬代碼氣死。8.

    本篇反思總結了一般的學習過程。掌握學習的方法，可以讓你更高效地進行學習。這對於天天要學新技術的IT人員來說，是非常重要的。    本文反思了自己學習WPF過程中出現的一些問題，然後對以後學習的方法進行了重新設計。    本文的主要內容：與學習相關的哲學思想原來的學習方案設計工具的反思沒學好的原因新的方案相關哲學理論   

　　製作原型是業務人員應該掌握的一項基本技能，這篇主要給大家介紹一個我認為比較好的一個工具：GUI Design Studio，大家可以到官方網站下載試用，如果用於個人學習，也可以上網搜到破解：）　　軟體協助文檔有個記事本的例子,如果參考做完就能大致瞭解如何做原型了.

“After a storm comes a calm.” — Matthew Henry       本篇文章翻譯自《http://sourcesofinsight.com/2010/08/15/day-15-achieve-a-peaceful-calm-state-of-mind/》。 你的結果    經過本次課程和訓練，你將可以把你的思維從混亂中擺脫，讓你的大腦保持在一個清醒、放鬆、敏銳的狀態。什麼是大腦的最佳狀態    回憶一下，曾經在什麼時候，你大腦是你認為的最佳狀態呢？   

    這篇文章還是對工作內容的總結，主要是總結一下這幾天做的產品的客戶化工作內容。    關於產品線工程中客戶化的理論知識和概念，請見金根的《產品線工程》。具體的，OEA架構中的客戶化理論，見：《軟體產品線工程方法：如何在OpenExpressApp做客戶化工作》。    本文主要從以下幾個方面來敘述如何在OEA架構中設計和實現客戶化架構：OEA客戶化架構設計目標 方案設計 具體實現設計目標支援實體類的擴充。 支援實體擴充包的動態載入。 支援介面擴充及介面擴充包的動態載入。

    上篇 已經就客戶化的整體方案進行了敘述，這次主要是說明一些細節部分的設計。類型的視圖中繼資料    基於OEA架構的GIX4項目中，客戶化工作主要是對各客戶版本中類型的視圖資訊進行定義。是包含這些類型的類圖： 圖1 客戶化API中的類型視圖中繼資料  屬性繼承    在應用程式定義中，需要支援繼承類型的視圖資訊定義，也就是說，在基類上定義的視圖資訊，子類在沒有定義的情況下，直接使用基類的定義；當然，也可以為具體的子類做特殊的定義。   

    上篇文章《OEA中的AutoUI重構（2）- 評審會議前的總體設計》寫了在“OEA架構”中進行AutoUI模組重構的設計方案。最近項目組已經召開了評審會議，並對該設計進行了審核、建議。本篇文章主要記錄其中一些主要的改動。 設計改動    大家認為 AggregateBlocks 和 BlockDefinition 的設計過於複雜，不易於理解。考慮的東西太多，有過度設計之嫌，所以這一處的設計改為使用Composite模式來組合“UI塊”：     

    以下，我使用一個執行個體，分享一下用於簡化泛型API設計的小技巧，“如何在泛型方法調用時，過濾掉可以隱式推斷出的泛型參數”：原有設計：    系統中原來有這樣一個靜態泛型API：protected static PropertyInfo<TProperty> RegisterProperty<TOwner, TProperty>(Expression<Func<TOwner, TProperty>>

    本篇主要描述GIX4項目中如何把單獨的模組設計為一個“外掛程式”，如何把它組裝到系統中。至於為什麼加引號，之後會有說明。原理    在基於產品線開發時，7，2，1的產品功能分類中，20%的功能是需要在產品線主幹中包含進來的。這些功能一般會被設計為“可選包”。在某一客戶版本產品的裝配階段，在“可選包”集合中挑選需要的功能，進行組裝，得到最終的產品。具體內容，見：《軟體產品線工程方法：如何在OpenExpressApp做客戶化工作》。   

    本篇部落格簡單描述了Repository模式在OEA中的應用。不使用Repository時的問題    OEA架構中使用了DDD的思想，面向領域對象進行開發。在DDD中，有很多重要的概念，例如：彙總實體物件、值對象、倉儲、工廠、服務等。（不太瞭解的Repository和DDD的朋友，可以看Evans寫的《Domain Driven Design》。）   

    這次總結一個個人認為的反模式：“綁定子類的泛型層基類”，這個模式在一些著名的架構中也見到過，如果CSLA、BlogEngine。我自己在原來的寫的架構中，也用到過。    當然了，個人認為是反模式，各們同仁並不一定這樣認為，仁者見仁，智者見智了。不過我好幾次都是受盡折磨，所以決定寫出來給大家分享下心得。 模式介紹    “層基類”是MF提出的一個基本模式，詳見：《Layer

    OEA架構的核心之一是AutoUI，其職責是面向領域模型及UI元模型進行產生統一的介面。    在本次的反覆式開發法中，需要對命令按鈕的產生方式進行一些定製。由於原來並沒有為這樣的需求留有特別的擴充點，加之原來的產生代碼是過程式的代碼、且也變得比較冗長，所以我們決定對這一部分的代碼進行重構。原來的模式    曆史代碼中，為某一實體類產生命令按鈕的流程是這樣的：找到實體類可用的所有命令按鈕中繼資料。對它們進行過濾，依靠許可權、版本的客戶化元資訊等。構造幾個產生控制項的List容器，分別是：

   “Life is not measured by the number of breaths we take, but by the moments that take our breath away.” — Hilary Cooper    生命的意義不在於你花了多少時間，而在於生命中有多少讓你屏住呼吸的時刻。 你的結果     注意！經過本次訓練，你將會成為一個“精力旺盛的強人”。:)   

    之前已經寫了一篇關於其中Command模組的重構：《OEA中AutoUI重構(1) - Command自動產生》。Command自動產生的重構作為本次重構的一個“前鋒戰”，嘗試用OO的方式把原來的過程式的介面自動產生流程進行最佳化，以支援更好的可擴充性。Command自動產生較為獨立，所以就單獨先進行了重構，目前重構已經完成，效果較好：和原有系統完成相容，同時插入了更多必需的擴充點。   

    前不久學習了《EFCachingProvider》，該擴充包不但可以用於EntityFramework的擴充，所有與資料庫連接相關的應用程式都可以使用類似的方案進行擴充。今天做個小的總結，以方便以後回顧。 總體描述    關於EFCachingProvider是什麼及如何使用它，請看園子的這篇文章：《 Entity Framework 緩衝處理與日誌監控 》。我主要說一下內部代碼實現的原理機制。    園子文章的圖中，畫出了EFCachingProvider所擴充的位置：