最後一篇讀書筆記看的不是這本書了，是網上看到的乙個文章的摘要和一些自己的感悟，雖然不是太理解，但是對類的使用以及內聚和耦合有了一定的理解。
設計良好的程式要最大化類的內聚同時要最小化類的耦合；遵循demeter法則就是在類方法內用於指向物件的訊息，那麼耦合和內聚的原理就可以實現；訪問程式方法的過度使用會產生不用思考的類；混合例項的內聚，雖然不是想要的，可能偶爾還是需要的，因為程式設計環境不支援動態分類；當設計c/s合作時，需要考慮sql介面的五個層次，第五層sql允許使用者直接對資料庫程式設計；儲存過程和觸發器嚴重影響了程式設計的伺服器方面；程式導航圖擴充套件了視窗導航圖以包含資料庫方面的考慮。事務是資料庫工作的邏輯單元，它開始於乙個一致的資料庫狀態，並保證它在結束時也是乙個一致的狀態；事務保證資料庫併發和資料庫恢復；傳統的資料庫應用要求短事務，一些新的資料庫應用則用長事務來工作。雙向工程是設計模型和程式處於同步的過程，但它們可以各自進化；雙向工程組合了從設計模型出發的前向工程和從程式出發的逆向工程；雙向工程一般獨立適用於客戶機程式和資料庫程式。
類模型和bced類包反映了應用類，而不是儲存資料庫結構，實體類表示了應用中的永久資料庫物件，但不是資料庫中的永久類；永久資料庫層可以是關聯式資料庫，物件關聯式資料庫或者物件資料庫；資料庫模型是表示資料庫結構的這種抽象，包含三種抽象，分別是：外部資料模型，邏輯資料模型和物理資料模型；資料庫包並不能匯出資料庫模型，它是由資料庫建模匯出來的。應用和資料庫之間的對映，由資料庫包負責，可能是錯綜複雜的問題，對映的困難有兩個：資料庫的儲存結構對物件導向範例做不了什麼，其次資料庫幾乎都不是為單個應用設計的。物件資料庫管理系統的最大目的是進行資料庫與應用程式設計語言的透明式整合，其建模語言是物件和文字，每個物件都有乙個oid，文字沒有oid，其值是它的識別符號；odb乙個主要的好處是在於對文字和物件型別的內部支援，這使得odb成為物件導向is開發的自然的實現平台,其支援關聯和泛化關係（聚合通過強制關聯來支援）；odmg物件模型定義了兩種泛化關係：即isa（相當於對介面的繼承）和extends關係（相當於實現繼承）；odbms配有內部操作來支援文字和物件型別；odb的任務是為物件導向模型建立乙個物件導向實現，可以對映實體類，關聯，聚合和泛化。物件關聯式資料庫組合了老式關係模型和新式物件模型，其表中的列可以取內部或使用者定義型別作為它的值；物件表是具有一列或多列的列的集合；行型別允許表可以甚至不需要使用結構化型別或集合就有相對複雜的內部結構；結構化型別可以用來定義引用型別；對映不是針對抽象的sql標準來做的，而是針對實際的ordb來做的；rdb模型中主要建模語言是由列組成的關係表，其不支援物件型別，結構化型別，集合和引用；關聯式資料庫用乙個列或行的表來定義資料；乙個關係錶用其列的固定的集合來定義；rdb模型利用引用完整性約束來維護表之間的關係；規則和描述性引用完整性約束支援在資料庫中定義簡單的業務規則；關係檢視是乙個被儲存和命名的sql查詢；關聯到rdb的對映涉及表之間使用引用完整性約束；觸發器可以用來對從隱含在uml類模型中的業務規則中捕捉出來的語義進行程式設計，正規化化會進一步影響這個對映。
《需求工程 軟體建模與分析》讀書筆記3
在讀完 需求工程 軟體建模與分析 的前三部分後，我對軟體需求有了初步的了解，在之後的閱讀中我開始了對這本書的第四部分，需求的文件化和驗證，在這與部分的閱讀中我開始了解到了需求文件的書寫規範，這一部分在軟體需求中同樣十分重要。需求工程 軟體建模與分析 在需求的文件化和驗證中主要分兩個部分講述，分別是需...
《需求工程 軟體建模與分析》讀書筆記三
需求規格說明活動就是將需求極其軟體解決方案進行定義和文件化，並傳遞給開發人員的需求工程活動。編寫需求規格說明文件 清晰明確結構化的文件可以將軟體系統的需求資訊和解決方案更好的傳遞給所有的開發者 可以拓展人們的知識記憶能力 可以成為各方人員之間有關軟體系統的協議基準 可以成為專案開發活動的乙個重要依據...
《需求工程 軟體建模與分析》讀書筆記三
最近讀完了 需求工程 軟體建模與分析 這本書，這次我主要讀了第五部分 需求管理與工程管理 分為三章，需求管理 需求工程的過程管理 需求工程中的專案管理。需求管理中包括維護需求基線，實現需求跟蹤，控制變更，實踐中需求管理。需求管理的重要任務 交流涉眾的需要，將需求應用 實施到解決方案，驅動設計和實現工...