posts - 176, comments - 240, trackbacks - 0, articles - 7

          [導入]軟件建模的困境:總是貧血的

          Posted on 2005-11-16 20:10 canonical 閱讀(605) 評論(1)  編輯  收藏 所屬分類: 設計理論
              軟件世界與真實的,物理的世界有著本質的不同,其中一點在于軟件中的規則是根據需求制訂的而不是先驗的。我們在研究物理世界的時候,多少會有些唯物主義, 即紛繁蕪雜的表象下蘊含著自恰的,不變的規律。物理學的建模是多方位的,多層次的。同一個規律,在不同的簡化條件和不同的環境中我們會賦予它不同的名字。 在不同的抽象層面上,我們也可能會建立不同的模型。嚴格的說起來,這些模型之間可能存在著不一致性,但我們相信,存在著一個絕對精確的模型:無限的細節, 無限的關聯,完美的,自恰的,而我們所建立的所有物理模型都只是對該終極模型在某個層次,某個角度上的近似抽象,而每一個模型都有著自己的適用范圍。很多 時候物理學的建模是粗魯的,拋棄了大量似乎必須的要素,只因為物理學家相信物理學的直覺能夠將我們引導到正確的道路,不論我們做出什么樣的簡化和假設,只 要它是物理的,最終都會回歸到真實的世界。
              軟件是人為構造出來的,其體現的運行規律由外部需求所決定,而無法形成自我的證明。領域模型(Domain Model)隱喻式的期望能夠建立穩定的邏輯層,可這注定是困難的。我們在軟件設計中希望分層,職責單一,進行正交化設計。可是一個復雜系統的邏輯分解注 定是無法正交化的。非此即彼只存在于抽象的世界。多個復雜性層次上的結構交織在一起,使得我們難以建立穩定的根基。因為缺乏先驗的支配規則,我們鼓吹需求 到實現的1:1映射,實際上只是希望通過貧乏的唯一性來維護演變中的自恰性。真正實現了1:1映射是不是在系統中引入了人為的剛性? 在一定的情景下,為了達到最適的模型,我們需要各種Facade,我們需要1:n映射,抑或是m:n映射。被割裂了的聯系仍然需要通過各種service 在系統中重建出來。
           在建筑學的隱喻中,建筑設計師與建筑工人之間還存在著一個角色:土木工程師。他在物理結構的層面上而不是應用意義上把握整體 工程。在結構層次上我們是能夠進行有效的推理和判斷的。在軟件中也是一樣,拋去對象的業務含義,我們可以把它理解為一個Map,那對它可以進行那些操作是 可以預知的。只是我們對于軟件結構層面的了解還是太膚淺了。每個項目,大量的時間花費在編寫那些低層的與業務無關的模塊(或者說可以抽象出這些模塊),這 就如同每次建筑,都從制造磚塊開始一樣。材料的準備不是一朝一夕之功。在結構層上我們必須對系統形成深刻的理解,這不僅僅是業務建模的問題。

          Feedback

          # re: [導入]軟件建模的困境:總是貧血的  回復  更多評論   

          2005-12-30 21:28 by weide
          第一次覺得枯燥,第二次看還是枯燥

          枯燥之余又覺得精辟,里面用了物理和邏輯的一些術語把人帶入了另外的思維方式
          主站蜘蛛池模板: 巴青县| 加查县| 阜康市| 商城县| 桃园市| 靖边县| 延边| 临高县| 长葛市| 昌图县| 滨海县| 彭阳县| 府谷县| 胶南市| 石河子市| 湘乡市| 股票| 宁海县| 汕头市| 灯塔市| 明溪县| 富蕴县| 岢岚县| 新津县| 陕西省| 葫芦岛市| 海阳市| 吴川市| 米脂县| 左贡县| 达州市| 靖西县| 峨眉山市| 武威市| 理塘县| 鲁山县| 冀州市| 津南区| 大渡口区| 黄山市| 大埔区|