2. 程式人生 > 其它 >UML面向物件設計基礎(非同步圖書)_note2_第一部分完

UML面向物件設計基礎(非同步圖書)_note2_第一部分完

阿新 • • 發佈：2021-11-10

Meliir Page-Jones. UML面向物件設計基礎（非同步圖書）. 人民郵電出版社. Kindle 版本.

原文名稱fundamentals of object-oriented design in uml可以結合英文原版進行閱讀

第二章 面向物件簡史:

  1. 面向物件的起源

    1. Larry Constantine: 提出軟體在進行程式設計之間需要進行設計. 提出了耦合, 內聚的觀點

    2. J.Dahl 和 K.Nygaard: 引入了類的概念, 並令該概念出現在Simula語言中

    3. Alan Kay, Adele Goldberg, etc: 提出了Smalltalk語言, 這一語言包含了許多現在面向物件的概念如訊息和繼承

    4. Edsger Dijkstra: 提出軟體正確性的理念 (conscience of software correctness), 並提出了使用抽象層構造軟體的觀點, 在兩個相繼的層之間使用嚴格的語義區分, 是一種封裝方式 (看不懂)

    5. Barbara Liskov: 推動了抽象資料型別(ADT)的發展, 為面向物件奠定了基礎, 成果為CLU語言, 支援隱藏內部資料的表示法

    6. David Parnas: 提出了模組軟體構造原則. 其中一些資訊隱藏的基本思想可以應用到面向物件的系統中

    7. Jean Ichbiah etc: 開發了Green語言, 是被美國國防部採用的Ada語言(現稱Ada-83

      ), 建立了一般性和包的概念

    8. Bjarne Stroustrup: 建立了C++語言.(一句話頂千句話)

    9. Bertrand Meyer: 建立了Eiffel語言.(我覺得作者開始推銷自己的愛好了)

    10. Grady Booch, Ivar Jacobson, Jim Runbaugh: 建立UML統一建模語言(來了來了)

  2. 面向物件的成熟期

    1. 本章節主要介紹工業界如何促進面向物件時代的到來

    2. 面向物件軟體工程的歷史重演了傳統軟體工程的歷史

    3. 軟體設計是在編寫程式碼之前對程式碼的相關部分進行規劃. 這種行為可以為人們解決潛在的維護問題

    4. 再加上許多軟體雖然設計嚴謹,可維護性高,但是不能滿足使用者的需求. 為了滿足使用者的需求, 更多有規律的以及嚴格的分析方式應運而生

    5. 目前已經有計算機輔助軟體工程(CASE). 目前這些軟體已經在聯邦保護軟體中獲得了聲譽Federal Protection Program. 這些建模工具幫助我們進行需求的分析, 軟體的設計, 軟體構造, 使得軟體開發和維護更加容易被管理

    6. 面向物件的軟體設計不是萬能的, 如果不按照本書後面的內容進行精心設計, 那麼面向物件也不能提供可重用的以及可靠的軟體. 發生這種情況主要的原因是專案管理者對面向物件缺乏真正的認識

    7. 面向物件程式設計的概念大約在1980年代開始流行, 在1990開始出現面向物件的資料庫管理系統和麵向物件的建模工具

    8. 作者認為下一場與面向物件同等水平的計算機技術革命是分散式元件軟體, 這部分內容會在第15章進行一定的討論

  3. 類似工程學的面向物件

    1. 軟體工程可以根據以下分類: 類; 技術; 系統. 類是可以組合的基本構造單元, 通過適當的技術而產生系統

    2. 選擇有用的電路封裝在晶片中有賴於工程師對於電路的正確標識.人們會去購買晶片用於操作放大器,計時器,驅動器等, 但是沒有人願意去購買電晶體,電感器,以及電阻的大規模整合晶片然後從頭做起

      1. 在軟體中我們必須確保開發的類有效, 健壯, 易於抽象

    3. 如果IC不能被組合則幾乎是無用的, 而電子工程師們為了將IC組合在一起印刷出了電路板

      1. 在開發面向物件的軟體時,必須進行Macro層的設計(我理解是要進行最上層的巨集觀設計), 在這一層次上處理類以及物件之間的聯絡. 顯然類的內部設計與更高層次的類間設計有著緊密的關係. 和電子工程類似: PCB的佈局依賴於繼承於其上的IC的設計程度. (這翻譯真難受)

      2. 在類的內部層次和類間層次上都存在著物件設計的優劣. 因此好的面向物件系統的設計不僅取決於高質量的抽象還取決於建立這些抽象的上層技術

      3. 這裡的翻譯真的是不行… 把原文貼上來也好啊… 這裡是我的個人理解:

        對於軟體系統的層次,作者分成了三層, 由底層到高層分別為:
            1. 類層 -- 實現軟體的各個類
            2. 技術層 -- 實現類之間的互聯互通, 相互耦合的方式
            3. 系統層 -- 作者沒有太講清楚這一層是做什麼, 但是我覺得應該是指由技術層構建的模組在此拼裝為系統
        在開發面向物件軟體的時候, 我們首先進行系統層的設計, 再進行技術層的設計, 再進行類層的設計
        但是由於底層的設計也會影響上層的設計. 對於類的實現的設計也會影響到類間關係的設計.

  4. 面向物件的益處 (這個標題翻譯的有點問題)

    1. 面向物件不是萬能的, 其雖然是一個有效的開發方法, 但是還應理性地進行看待

    2. 面向物件對於企業的六個主要的軟體活動的影響:

      1. 對於使用者需求分析的影響:

        1. 已存在的問題:

          1. 對於使用者需求的結構化分析的主要難點是確定過程分析和資料分析之間的邊界

          2. 由過程分析獲得的資料流圖和通過資料分析得到的實體關係圖容易出現矛盾,難以共存

          3. 這些過程和資料的矛盾在一些實時系統中非常常見, 例如過程與資料模型的對應關係並不清晰

        2. 面向物件對這一問題的解決:

          1. 在軟體開發的生命週期的早期就開始將過程和資料研究融合在一起

          2. 在面向物件設計中動態與靜態分析(另一種方式的過程和資料分析)可以將過程和資料很好的結合起來

          3. 有人形容面向物件的動態與靜態分析描述為愛因斯坦相對論將空間與時間進行的融合

      2. 對於軟體設計的影響:

        1. 面向物件的優勢: 能夠使設計者將軟體中的棘手問題使用封裝特性封裝起來

        2. 一些常見的棘手問題如:

          1. 複雜資料結構

          2. 複雜組合邏輯

          3. 詳細的過程

          4. 資料間的關係

          5. 高深的演算法

          6. 複雜裝置驅動程式

        後續的閱讀筆記不再基於非同步圖書的翻譯, 而是基於英文原版

        1. 面向物件的缺點: 應用封裝和繼承特性使得結構本身變得複雜. In object orientation it is all too easy to create a Gordian hammock of inextricable interconnections (這裡的意思是會形成像吊床繩一樣難解的複雜互聯關係) that either is unbuildable or will result in a system that runs about as fast as a horse in a sack race.

        2. 為了解決這一問題, 作者在第二部分介紹UML的一些重要功能. 在第三部分作者會提供一些設計原則和標準幫助我們對於設計進行評價.

        3. 通過這些UML工具和評價標準達成的目標是: 使得建立的模型在構成一個系統的時候可以相互合作, 但是將其分開的情況之下又是maintainable的

        4. 雖然在軟體設計方面OOP可能需要一些額外的工作, 但是在完成整個軟體的設計以及開發之後會提供溫順但複雜的物件集合 — 幫助後續的維護與開發

      3. 對於軟體構建的影響:

        1. 主要的優勢點:

          1. reusability

            1. 對於程式碼的重用水平是在class level而不是在子程式水平

            2. 通過維護你自己的類庫, 你實際上是在開發一個專屬於你自己的高階程式語言

            3. 對於面向物件而言, 其有足夠的能力在你公司的專案之間到處遷移, 以一種自洽的軟體模組的形式

            4. 至少對於攜帶了輔助類的類而言, 其完全可以作為一個自洽的獨立模組存在

          2. reliability

            關於可靠性是老生常談的話題, 只有當你能夠以某種方式驗證自己程式碼的正確性時, 你才能認為你的程式碼具有了可靠性

            OOP中通過一種被稱作class invariants的斷言形式進行程式碼的正確性的判斷

            這種class invariants是通過提供一些所有滿足設計的物件都要滿足的條件達成的. 例如對於類Person而言, Person.birthdy <= todayDate是永遠成立的

            通過在程式碼中加上這樣的判斷斷言, 可以非常徹底的稽核程式碼的正確性. 在進行一次程式碼稽核的時候可以核查程式碼的中間狀態是否符合設計

            但是面向物件並不能保證程式碼完全正確. 面向物件的設計思路只是幫助你能夠更加便捷的確定你寫的程式碼和你腦海中的執行流程是一致的

          3. rebustness

            1. 魯棒性的定義 : 當出現錯誤的時候能夠從錯誤中恢復. 一般出現的錯誤有以下這幾種:

              1. 斷言不符合

              2. 記憶體衝突

              3. 外部裝置出錯

              4. 計算overflow

            2. 應用從這些問題中恢復的方法是: 捕獲這些異常情況, 然後開始執行一個子程式, 用於從錯誤中恢復

            3. 在一些OOP環境中, 你可以監控每一個class invariants以及其他的斷言判斷. 如果發生錯誤就進行應用恢復

            4. 當然一個可以選擇的方式是沒有錯誤處理, 也就是如果出現錯誤就讓應用崩潰掉. 當然這樣的設計不是具有魯棒性的設計

          4. extensibility

            1. 一個易於拓展的應用程式需要在設計領域和實現領域的同型性簡單來說就是令你的解決方案和問題符合. 為了達成這一目的, 你需要保證一個使用者的小小改動不會成為系統的噩夢

            2. 在面向物件的設計中, 相較於其他設計方法, 你會更少的建立一些晦澀難懂的構件. 因為OOP在進行構件的構建時站在一個較高的層次, 同時可以引用很多真實生活中的抽象概念. 所以OOP更加接近於同型性的目標

            3. 另外可拓展性和可繼承性是息息相關的. 人們試圖拓展一個系統的時候總是試圖在一些已經寫好的模組上增加一些功能. 例如: 我們不能簡單的使用客戶的概念, 我們要使用國內客戶和國外客戶. 對這種情況, 只需要對於父類進行繼承即可

          5. distributability (這裡不是可分佈性, 更多的是指泛用性)

            1. 在一個叫做CORBA的專案中, 程式設計師通過OOP將不同硬體平臺的介面進行了整合, 使得上層的應用開發人員只需要編寫簡單的單執行緒應用, 由CORBA處理複雜的底層細節

          6. storability

            1. 可儲存性, 這裡主要的案例是OOP資料庫. ODBMS可以儲存任何類. 通過提供面向物件的封裝,繼承,多型的特性. 目前已經存在OQL用於在資料庫中代替SQL

      4. 對於軟體維護的影響

        1. 重用性, 可靠性, 魯棒性, 可拓展性是軟體維護的四大支柱

        2. OOP以以下的方式減少維護成本;

          1. 可重用性減少了需要維護的程式碼量

          2. 可靠性減少使用者的抱怨和難以忍受的修正問題

          3. 魯棒性保證了應用在實際生產環境中不會完全崩潰

          4. 可拓展性保證了當使用者要求更多功能或者進行改進的時候不會代價過高

      5. 對於軟體使用的影響 — OOP是GUI軟體編寫的一個重要工具

        1. 概念上的: OOP和GUI介面在屬性上具有共通性 – 因為GUI設計中的按鍵以及選項是離散的, 每個控制元件都有其特定的資訊介面.

          1. 例如: 對於不同列表的設定可以通過繼承進行實現,

          2. 對於一個選項表加上一個Start按鈕的情況, Start按鈕的實際執行內容需要依賴選項表中被選中的選項. 這裡就是使用多型的好地方

        2. 實踐上的: 許多進行GUI程式設計的商業庫是通過OOP進行的, 因為GUI程式本身就有OOP的屬性

      6. 軟體專案管理:

        1. OOP的一些技術屬性對於專案管理也有價值

          1. 減少維護消耗以更好的處理軟體的積壓需求

          2. 公司組織架構上的改變

            1. OOP由於通過程式碼重用建立了很多的庫, 也就意味著需要要庫管理員

            2. 程式設計人員會被分為兩個部分, 一個思考如何建立新的類, 一個思考如何使用現有的類實現應用需求

            3. 通過增加重用性減少了對於實際碼程式碼的重視程度,而增加了對於需求的分析能力

            4. UML等工具的廣泛應用使得在需求分析領域和軟體設計領域的符號系統有了一致性

          3. 但是由於需要組織架構上的改變, 員工也需要適應自己的角色, 例如要學會如何設計類使得其更能被重用

        2. OOP在專案管理上的高效性需要專案管理人員將其當作實現專案管理的手段, 而不是實現專案管理的目的

        3. 在專案管理中使用OOP首先要知道你最關心的什麼效能指標, 然後通過OOP工具進行達成

        4. 如果在使用OOP的時候不明確自己的目標, 那麼由面向過程過度到面向物件的代價就似乎毫無意義了

        5. 只有你同時知道你在做什麼以及為什麼這麼做, 理財能通過耐心達成設計中的目標

  5. 本章小結

    1. OOP是軟體發展的一個正常步驟, 不能將其神化也不能忽視其意義

    2. OOP解決了以下兩個問題

      1. 解決了資料和過程之間的分裂, 在軟體設計和需求分析中使用不同符號的問題

      2. 解決了資訊與實時系統開發方法的分離問題.

    3. 通過class invariance達成可靠程式

    4. 通過重用減小維護成本

    5. 通過和GUI配合, 支援GUI程式的開發

    6. 只有通過良好的管理架構,才能充分發揮OOP的效果

  6. 習題

    1. IC之間的連線是匿名的. 但是物件之間的連線時具名的

相關推薦

UML面向物件設計基礎(非同步圖書)_note2_第一部分完

Meliir Page-Jones. UML面向物件設計基礎（非同步圖書）. 人民郵電出版社. Kindle 版本.

10月16日肖鵬-UML在動態面向物件設計中的應用-UMLChina講座

時間 北京時間 2020年10月16日（週五）19:00-20:00 地點 通過騰訊會議舉行，會議號：681 774 2045。

UML面向物件系統分析和設計：互動圖

UML面向物件系統分析和設計 1. 概述（互動圖） 互動圖是用來表達系統的各個物件之間如何互動，如何完成某個行為的動態模型工具。主要用於對用例圖中的控制流進行建模。一般要求每個用例使用一個互動圖進行描

Java(3)面向物件設計：圖書管理系統

一、功能調查與系統功能框架圖 1.功能調查： 圖書管理系統分為普通使用者與管理員兩種登入方式，然後通過輸入姓名、性別、年齡資訊進入系統，普通使用者可執行查詢、借閱、歸還圖書以及退出系統四大功能，而管理員擁

設計模式--7種面向物件設計原則

軟體設計模式的產生背景 1995 年，艾瑞克·伽馬（ErichGamma）、理査德·海爾姆（Richard Helm）、拉爾夫·約翰森（Ralph Johnson）、約翰·威利斯迪斯（John Vlissides）等 4 位作者合作出版了《設計模式：可複用面

Python面向物件程式設計基礎例項分析

本文例項講述了Python面向物件程式設計基礎。分享給大家供大家參考，具體如下：

JS面向物件程式設計基礎篇（一） 物件和建構函式例項詳解

本文例項講述了JS面向物件程式設計物件和建構函式。分享給大家供大家參考，具體如下：

JS面向物件程式設計基礎篇（二） 封裝操作例項詳解

本文例項講述了JS面向物件程式設計封裝操作。分享給大家供大家參考，具體如下：

JS面向物件程式設計基礎篇（三） 繼承操作例項詳解

本文例項講述了JS面向物件程式設計繼承操作。分享給大家供大家參考，具體如下：

SOLID：面向物件設計的前五項原則

S.O.L.I.D是Robert C. Martin提出的前五個面向物件設計（OOD）原則的首字母縮寫，他更為人所熟知的名字是Uncle Bob。

c++ 面向物件設計五大原則

面向物件設計（OOD）是面向物件程式設計（OOP）必不可少的一個環節，只有好的設計，才能保障程式的質量。面向物件設計的主要任務就是類的設計，不少面向物件（OO）的先驅和前輩已經提出了很多關於類的設計原則，用於

【設計模式】面向物件設計原則

面向物件設計原則 設計模式需要遵循基本的軟體設計原則。 可維護性(Maintainability)和可複用性(Reusability) 是衡量軟體質量的重要的兩個屬性：

python面向物件的基礎語法

目標 dir內建函式 定義簡單的類（只包含方法） 方法中的self引數 初始化方法 內建方法和屬性

Java---(三)面向物件程式設計基礎上

一:面向物件的基本概念 　　1.封裝性 　　　　含義: 　　　　　　①把物件的屬性和行為看成一個密不可分的整體,把這兩者\"封裝\"在一個不可分割的對立單位中

面向物件設計原則——開閉原則

什麼是開閉原則 開閉原則（Open Closed Principle，OCP），軟體實體應當對擴充套件開放，對修改關閉（Software entities should be open for extension，but closed for modification），這就是開閉原則的經典定義。

面向物件設計原則——里氏原則

里氏替換原則 里氏替換原則（Liskov Substitution Principle，LSP） 繼承必須確保超類所擁有的性質在子類中仍然成立

面向物件設計原則——依賴倒置原則

依賴倒置原則 依賴倒置原則（Dependence Inversion Principle，DIP） 原始定義： 高層模組不應該依賴低層模組，兩者都應該依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象

面向物件設計原則——介面隔離原則

介面隔離原則： 介面隔離原則（Interface Segregation Principle，ISP）要求程式設計師儘量將臃腫龐大的介面拆分成更小的和更具體的介面，

面向物件設計原則——迪米特法則

迪米特法則 迪米特法則（Law of Demeter，LoD）又叫作最少知識原則（Least Knowledge Principle，LKP)

面向物件--設計模式：單列模式

單例模式 1. 單例是什麼 舉個常見的單例模式例子，我們日常使用的電腦上都有一個回收站，在整個作業系統中，回收站只能有一個例項，整個系統都使用這個唯一的例項，而且回收站自行提供自己的例項。因此回收站是單例模