需求分析與系統設計（三）

寫到這裏也算是本書的完結篇了，放到上中下里面就是下的概念，在章節末尾寫一些我讀此書感到受益的部分和相關的知識。

在課上常常聽到老師說一些關於軟件需求規格說明書的內容，關於需求規格說明，需求規格說明涉及對需求肯定期間定義的客戶需求進行嚴格的建模，重點放在那些系統將要提供的所指望的服務上。在規格說明階段一般不對系統約束作進一步的考慮，但系統約束能夠指導和驗證建模工做。這種指導和驗證採起體系機構優先權的形式。

軟件體系結構定義了系統中相互做用的軟件構件及子系統的結構和組織形式。書中引用一系列比較晦澀的詞彙，確實難以看懂但能夠進行羅列好比實現繼承的恰當使用擴展繼承，uml在以泛化調整繼承以及恰當的使用實現繼承方面都是很是獨特的。繼承的惟一恰當使用就是將繼承做爲類的增量式定義。子類具備比超類更多的特性。子類是超類的一種。這也是一般所說的擴展繼承。在擴展繼承中，特性的重載要謹慎使用，應該只容許使用特性更特殊化（如限制值得範圍或使操做的實現更高效），而不改變特性的含義。若是重載改變特性的含義，則子類對象就不能替換超類對象了。用新的特性擴展子類的定義。然而，有些繼承來的特性在子類中被禁止，所以使用繼承做爲一種限制機制也是可能的，這樣的繼承被稱爲限制繼承。一味的強調實現繼承，可能會在軟件模式的使用中形成軟件的複雜性增長，但咱們不使用繼承，那還要它有什麼用呢！有人曾言只要咱們禁止方便繼承就萬事大吉了。實現繼承按不少標準來講都是一件有風險的事情。若是不被適當地控制和管理，繼承會被過分使用以至濫用而產生問題，這些問題應該首先解決。這一點對具備幾百個類、幾千個對象、對象狀態動態變化以及演進的類結構的大型系統（如企業信息系統）開發來講尤是如此。在源程序中有基類，有調用，但每每基類會是很是脆弱的，每每使用不當就會bug頻頻，問題是指，在容許對超類（或多個超類，若是使用的是多重繼承的話）的實現進行演化的同時，使其子類仍然有效並可用的問題。這在任何狀況下都是一個嚴重的問題，特別是當咱們考慮能夠從系統開發團隊的控制範圍以外的外部資源中獲取超類的時候，更是如此。考慮到這樣的情景，你的應用繼承了一些超類，而這些超類構成了操做系統、數據庫系統。包可見性是java默認的。若是對java的屬性或操做沒有指定private、protected或public關鍵字（或對整個類沒有指定public關鍵字），那麼它們默認取得的可見性就是包可見性。包可見性意味着包中所含的全部其餘類均可以訪問這樣的一個屬性或操做。可是對全部其餘包中的類來講，這個屬性、操做或類看起來是私有的。保護的（和公共的）也具備包訪問性，但反過來並不成立。這意味着同一包中的其餘類可以訪問保護特性，但若是派生類和基類處於不一樣的包中，派生類就不能訪問那些具備包可見性的特性。

設計數據庫訪問和事務，應用程序須要與數據庫交換數據，客戶端程序必須採用數據庫語言（一般爲sql）來訪問和修改數據庫。資源子系統（以及rreader、rwriter等類）負責與數據庫通訊。然而，模型沒有說明如何實現通訊，此外，模型也沒有解釋如何保證業務事務的一致性。sql程序設計的層次，爲了弄清楚客戶端程序與數據庫服務器是如何通訊的，咱們就要認識到sql能夠表現爲不一樣的形式，而且能夠在程序設計抽象的不一樣層次上。第一次sql用作數據定義語言ddl。ddl是定義數據庫結構（數據庫模式）的規格說明語言。數據庫設計者和數據庫管理員dba是第一層sql的主要用戶。第二層sql用作數據操縱語言dml或查詢語言。然而，查詢語言這個術語有點用詞不當，由於第二層sql不只可以用來查詢數據，並且還可以用來修改數據。爲保證查詢能返回正確的結果，必須讓程序員可以逐漸瀏覽查詢所返回的記錄，而後依次一個記錄地決定若是處理這些記錄。這種一次一個記錄地處理能力稱爲臨時表，並且第二層以上的sql都有這個功能。