作者：rick1126
email: rickzhang@sina.com
日期：2001-7-13 10:56:16
1.3 方法學介紹

    方法學時一組過程和啟發式, 用以減少程序設計問題的復雜性

1.3.1 復雜性

     【程序設計指定原則對付復雜性】

       . 內部原則體現在程序自身的結構中, 機靈而有見解的程序員可以通過程序設計語言的表達方式了解這種內部原則		程序的本質
       . 外部原則體現在程序的源信息中, 一般被描述為"設計文檔"(非產品文檔)					程序的分析

       . 好的程序設計可以從外部原則上降低程序的結構方面的復雜性, 是程序成敗的戰略上的問題
       . 好的程序實現可以從內部原則上降低程序的代碼方面的復雜性, 是程序成敗的戰術上的問題

1.3.2 內部原則

     【歷史回顧 - 程序演化從處理內部原則開始】

       . 程序設計模型強加于內部開始, 標志性革命是為內存未知何機器指令指定別名
       . 命名子程序開始了面向過程的程序設計模型的歷史

1.3.3 外部原則

     【程序設計的通常背景】

       . 設計本身 -- 如何使得程序工作, 并且如何使得程序易于維護
       . 開發人員 -- 不能假設開發小組是穩定的, 人員流動要求新老交替之時的交流 -- 文檔就是形式之一

     【外部原則面臨的問題】

       . 通訊 -- 交流問題
         - 好的方法( 外部原則 )應當是幫助人們進行思考和分析
         - 需要不斷得到短期回報, 才能夠激勵小組不斷進步; 這是除了邏輯因素以外的精神因素的考慮

       . 量級 -- 外部原則所占比重
         - 大型程序需要比較完善的外部原則, 因為問題比較復雜不是每一個新程序員都可以馬上入手
         - 中小型程序根據需要部分的實現外部原則
         * 記住, 就商品角度而言, 外部原則不占客戶所付金錢的份額; 但是對于軟件企業則是一筆可以增值的財富
         * 軟件公司乃至現在的一些公司除了物流( 生產資料 + 生產力 )管理以外, 其中在信息時代重要的一個特色就是信息管理
         * 信息管理很大一部分除了新的動態信息以外還有就是過去的一些靜態信息的管理
         * 歷史地看問題往往可以為預測和對應新的問題給出很好的借鑒, 辯證唯物主義也不僅僅是在意識形態上才可以體現價值

       . 問題層面
         - 項目設計往往分為3個層次 -- 問題空間, 解空間和機器空間
         - 外部原則往往有可能脫離機器空間給出通用的設計( 解空間 )
         
1.3.4 對象設計的五個階段

     【設計過程】

       . 抽象 - 對象發現, 通過尋找外部因素與界線, 系統中的元素副本和最小概念單元得到
       . 繼承 - 對象裝配
       . 聯系 - 系統構造, 建立各個類型之間的層次和關系
       . 改進 - 系統擴充
       . 復用 - 對象重用

       * 比照IDEF方法可見上述方法還是本著將問題逐步細化的原則. 區別在于IDEF是面向數據, 自頂而下, 相關的方法使用流程描述, 是一個非閉合環節; 而OOP則從顯示世界出發從主要矛盾之中獲得對象抽象類, 不但面向數據而且將相關的操作一起實現了封裝, 而且對象之間的通訊也使用了消息方式, 因此更接近于自然的解決方案.

     【開發原則】
       
       . 將特殊問題歸結為一個基類, 解決問題的過程就是類型成長的過程
       . 基本類型才是系統的主要內容
       . 解決問題的過程也是學習的過程
       . 在開發編程的時候可以實現模塊方式的點到面的方式, 使用類的目的就是減少各個模塊之間的耦合性, 增加聚合性; 只要接口保持穩定, 不當地實現方法可以使用新的方法完善乃至替代.
       . 接口的劃分要求明確和簡單, 復雜的問題可以使用組合等方式解決; 遵循由簡到繁的邏輯原則, 否則無法將一個復雜的類型簡單化

1.3.5 方法承諾什么

     【切記教條化】

       . 方法從概念觸發僅僅是一些規則和啟發, 提供更好的分析和思考的方式. 
       . 不能指望方法本身去解決問題
       . 不能死板的看待方法, 應當經驗和實際情況相結合, 有發展的進行思考

     【方法的目標在于提高效率】

       . 解決問題, 不但是部分的也要考慮到對于全局的整體性影響

1.3.6 方法應當提供什么

     【基本功能】

       . 通訊約定
       . 支持項目結構化系統
       . 可以使用一些抽象的形式化工具進行描述 ( 比如: 文檔, UML, IDEF的設計產物 )

     【通訊約定】

       . 敵對性環境		表示當事人互相之間存在認識上的差異乃至沖突, 使用約定可以規范各自的行為, 明確分工
       . 信息約定		表明意見一致的標準

     【系統結構化】

       . 系統的基本類型
       . 類型之間如何連接成為一個工作系統

     【描述工具 -- 符號原則】

       . 不包含不需要的東西, 否則不但容易引起誤解, 同時也需要為此花費進行維護
       . 可以在較高的層次上創建一些必要時候展現的隱藏層次
       . 符號最小化
       . 類設計符號最小化, 如果該符號無助于表達OPP語言描述可以去掉
       . 內部實現的非重要性, 有時候內部實現往往是一種成規, 由于其往往和具體的計算機相關, 因此不能保證它不會妨礙到系統設計
       . 符號簡單化

     【精神因素 -- 積極性】

       . 項目開發或者公司最為重要就是積極性
       . 管理技術不能夠忽視在整個系統開發過程中的主體 -- 人的精神因素

     【不要犯經驗主義的錯誤】

       . 相關書籍
         -- << 軟件的創造力 >> ( Software Creativity, Robert Glass )
         -- << 人件 >>	 ( PeopleWare, Tom Demarco & Timothy Lister )
         -- << 復雜性 >>	 ( Complexity, M. Michell Waldrop )




〖個人理解〗

  這里主要討論了一些高層次的方法問題和觀念問題. 作為開發者, 對于先進的設計方法, 應該本著學習和實踐的態度, 一旦將方法死板和教條化, 難免犯經驗主義的錯誤, 畢竟方法僅僅是理論層面的事情, 解決問題還是需要實踐. 我認為開發程序, 特別是新項目往往是犯錯和學習的過程.

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～