為了完整地說明乙個系統，有必要採用多種模型。需求規格說明以敘述性的使用者需求作為輸入，構造出規格說明模型作為輸出。
需求規格說明涉及對需求確定期間定義的客戶需求進行嚴格的建模，重點放在那些系統將要提供的所期望的服務（功能性需求）上。軟體體系結構定義了系統中相互作用的軟體構件及子系統的結構和組織形式。模式—檢視—控制器（mvc）框架支援大多數現代體系結構框架及相關模式，模型物件表示資料物件——應用問題域中的業務實體和業務規則。mvc幾乎是所有現代框架的骨架，後來進一步擴充套件到企業和電子商務系通過。物件的狀態由它的屬性值和關聯決定。因為物件狀態是由資料結構確定，所以資料結構模型就稱為狀態規格說明書。類模型是物件導向系統開發的基礎，類建立了乙個基礎，在這個基礎上，系統的狀態和行為才是可見的。關聯連線著系統中的物件，它們使物件間的協作變得更容易。聚合及其更強的形式——復合，表示復合類和乙個構建類之間的「整體—部分」語義。泛華關係是乙個或多個類的公共特徵（屬性和操作）可以抽象到乙個更一般化的類中，將一般類與特殊類連線起來。介面雖然沒有實現，但卻提供了某些最強大的建模能力，介面沒有屬性、關聯或狀態，所有操作都隱含是公共的和抽象的。建模涉及系統的定義，模型不是乙個可執行系統，不顯示例項物件。
行為規格說明提供系統的操作檢視，主要任務是定義應用領域中的用例，並確定在這些用例的執行中將涉及哪些類，標誌類操作和物件之間的訊息傳遞。乙個用例表示：乙個完整的功能，乙個外部可見的功能，乙個正交功能，由乙個參與者啟動的乙個功能，給參與者傳遞確切值的乙個功能。活動模型廣泛地應用於設計中。順序圖和通訊圖是兩種互動圖，它們展現了物件之間為完成乙個用例、一項活動、乙個操作或其他行為構件所需的互動模式。類將一組操作作為服務提供給系統中的其他類，這組操作就確定了類的公共介面。狀態圖是表示狀態及狀態轉換的圖，可以為每個具有令人感興趣的動態行為的類建立狀態模型，但並不是類圖中所有的類都屬於這個範疇。
軟體開發的實際情況要複雜得多，複雜的問題不會有簡單的解決方案，物件為構造當前的複雜系統提供了一種流行技術。我們所討論的分析建模概念足以產生完整的分析模型，但這些模型處於乙個較高的抽象層次上，沒有對分析建模階段允許的所有可能的細節進行詳盡的描述。在使用uml時，有超出其固有能力的需求，為了這個目的，uml標準提供了擴充套件機制，如構造型、約束、標籤定義和標籤值。可見性的概念和相對的封裝思想在附錄有關類內部的可見性，類屬性和操作的整套可見性標誌是：公共可見性、私有可見性、保護可見性、包可見性。匯出資訊是一種應用於屬性或關聯的約束，匯出資訊在模型中是冗餘的。限定關係是在二元關聯的一端，有乙個屬性框，框中包含乙個或多個屬性，這些屬性可以作為乙個索引碼，用於穿越從被限定的源類到關聯另一端的目標類的關聯，有些人喜歡，有些人不喜歡。類之間的關係有：關聯、聚合、泛化。泛化引入了額外的類，並將它們分為一般類和較特殊的類，在模型中建立超類—子類關係。封裝要求只能通過物件介面中的操作才能訪問物件的狀態（屬性值），封裝與繼承和查詢能力是正交的，他不得不與這兩個特性一起折中考率。當以可替換性為目標來使用泛化時，他就同介面繼承概念是同一詞了。聚合是一種包含關係。乙個復合類包含乙個或多個構件類，構件類是其復合類的元素。現在的程式設計環境普遍忽視聚合，在這種情況下，雖然物件應用開發方法將聚合結合進來作為乙個建模選擇，但卻很少重視它。泛化是超類—子類的關係，聚合更接近超集—子集的關係。聚合提供了關注點的分離—允許每個類保持封裝，他關注類的特定行為，使其不受父類實現的約束。
《需求分析與系統設計》閱讀筆記（二）
最近的課程中老師一直在強調需求分析這個部分，最近讀書也讀到了這個部分，現在簡談各個階段的常用方法，方便自己以後查閱。軟體工程團隊接活兒的時候需要明確使用者需要什麼，專業一點的說法就是需求確定。雖然這個部分從技術角度上來講在整個需求處理過程中最低，但一旦沒有完成好帶來的後果是最糟的。為了完成業務需求，...
《需求分析與系統設計》閱讀筆記四
資訊系統從定義上就是多使用者系統。多個使用者和應用程式可以通過資料庫管理系統併發訪問同乙個資料庫。應用程式依賴與資料庫的不僅僅是資料，還有資料庫提供的解決併發衝突 保證資料的安全訪問 保證資料一致性 事務錯誤恢復等功能。類模型和 子系統中只包含應用類，而不包含資料庫結構的儲存。實體類表示應用程式中持...
《需求分析與系統設計》閱讀筆記（五）
本學期的人機互動，net，軟體開發案例分析三門課程中，都考察過介面設計，在大作業要求中介面設計佔了相當的比重。在軟體開發過程中，需求分析有著明確的準則，模型，那麼介面設計有沒有呢，答案顯然是肯定的。使用者介面開發開始於需求分析階段中早期的gui窗體草圖。gui窗體在學習過程中我已經接觸過了，但要說對...