評審OOA模型的目的是為了保證在實現系統之前，能夠正確理解和解釋用戶的需求。

如果在系統開始運行之后才發現對用戶的需求理解錯了或解釋錯了。當系統正式運行之后再修正這種錯誤，所付出的代價要遠遠大于在項目的分析階段修正錯誤所付出的代價。

評審過程應是非正式的，持續的，貫穿在項目的整個生存期中的過程。就是說首先把OOA模型充分地文檔化，分發給各評審者，然后召集評審會，共同評審。OOA模型的一個評審策略

建立一個評審檢查表，列出各種評審項目。

對這些評審項目進行評審，目的是確保OOA模型的語法正確性，確保“建立模型正確”。

可將檢查表嵌入到每個屬性、服務、對象中去，跟蹤定義-使用情況。

好處：評審過程已成為開發過程的一部分。所生成的管理報告可以監控、跟蹤工程進度，保證每一模型成分的質量。OOA模型—評審者的檢查表OOA模命令約定語法需求風格約定型層次對象-類唯一性應用領域形式唯一性應用領域形式唯一性應用領域形式包含規則事件識別器事件響應器響應性信息封裝單個事件識別器重載獨立性包含所有對象-類主題結構整體-部分,實例對整體-部分,類屬類實例重復度和參與度泛化-特化,類對類繼承一致對初始屬性層的分至少一個屬性層屬性規格說明（續）泛化-特化,繼承屬性唯一性應用領域形式無冗余的實例關系（續）有助于將某些新技術應用到主流項目中。在一段時期內所實現的線程構成最終產品的一PDC與原來的OOA模型盡可能相近而減少測通過OOD將面向對象系統結構分為4個部分，利用以上準則來檢查ECS的OOD設計，看是否按預定日期交付你的第一個項目完全是出于士就是說，它們可以將事務規則、用戶界面技術類“召喚按鈕”封裝了如何將寄存器值轉換為OOA模型—評審者的檢查表在完全掌握了這些新技術在實現了第一個項目后，組織機構會有一些號為奇數，向上的召喚按鈕編號為偶數。改動，或者在軟件中增加一個新的特性，都可將檢查表嵌入到每個屬性、服務、對象中對象發送一個消息,詢問輸入寄存器的當前值.OOA模型—評審者的檢查表（續）OOA模命令約定語法需求風格約定型層次屬性與包含規則的一致性精確定義繼承的一致性類的屬性的一致性存儲數據的一致性至少有一個相關的封裝的服務實例關系的一致性屬性與實例關系的一致性屬性-消息的一致性服務規格說明與輸入/精確定義每個服輸出消息與屬性的一致務性(續)無‖外部‖訪問服務唯一性應用領域形式(續)OOA模型—評審者的檢查表（續）OOA模命令約定語法需求風格約定型層次服務對初始參數層的分層無‖外部‖訪問消息規格說明至少一個類的服務至少一個實例的服務服務與封裝屬性的一致性繼承的一致性類服務的一致性存儲數據的一致性實例關系的一致性服務-消息的一致性過程描述記號與風格

現有的所有檢查表都無法保證語義正確性，即是否建立了“正確的模型”。

對語義正確性的評審采用的策略類似于在開發面向用戶的文檔時采用的策略，將模型的行為對照用戶描述的場景或用戶事例，一一加以確認。

需要有關人員共同討論，不一定舉行正式的評審會議。

檢查語義正確性從事件-響應模型和EROI圖入手，走查每一個場景或事例，一步一步驗證事件如何識別，相關響應如何產生。

在評審過程中使用CASE工具，可以動態地描述和執行OOA模型。

在實際的項目評審中，可以采用兩個顯示器：一個顯示器用來顯示OOA模型，另一個顯示器用來顯示EROI圖表。

對于這樣的正式評審，需要一個“驅動者”，一個“記錄者”。驅動者控制計算機設備、巡航OOA模型和EROI圖，記錄者訪問公共CASE工具庫。

在一步一步走查事件或場景，驗證OOA模型的行為時，他們可以對OOA模型、EROI圖或其他工作結果進行可視化的交互修改。

評審者可以利用這些手段，監控、改變、標記OOA模型的動態行為。

在實際項目中，應把以上建議轉換為方針和過程。一個好的項目管理所應具備的基本特點之一就是要堅持文檔化和評審。

生成一個好的系統，需要有許多素質良好的工作人員，好的構思，還需要好的項目管理。

在面向對象開發模式中，分析和設計之間的界限是模糊的。

通常，分析涉及系統做什么，設計則涉及需求如何實現。

分析通常建立在“完美的”技術的假設之上，而對于設計，則通常涉及具體的實現環境，包括系統的運行硬件平臺、操作系統、使用的編程語言等。OOD表示法

OOD涉及到實現，它的表示涉及任務、模塊、處理器、隊列，以及其他硬件/軟件等。

用圖形表示表達設計。

OOD的表示法應盡可能地接近OOA表示法。OOD策略

問題：利用OOA模型描述的需求，軟件工程師應當如何策劃面向對象的設計？從哪兒開始著手？采取什么步驟？應該得出什么類型的體系結構或結構？OOD的評價準則

制定評價準則的目的是使得我們能夠以一種客觀的方法來對一個設計作出評價。

以往評價一個項目的設計時，常用效率、完備性、靈活性等指標來衡量。

老的設計方法,如結構化設計方法，有它自己的一套完善的設計準則。其中最著名、最重要的概念是模塊的耦合、內聚性。而針對OOD的準則與它們很類似，其中有一些準則在本質上與老的方法相同，有些具有面向對象的獨特特點。其他問題

用OOD方法產生的設計還不是軟件的最終成品。必須將這個設計翻譯成語言程序，然后對產生的代碼進行測試。

編程語言對設計過程及設計者的設計思想都將產生巨大的影響。

連面向對象的方法也會受到編程語言的影響。一些商品化的OOD形式就受到Ada、Eiffel、C++、Smalltalk、Java等語言的影響。OOD體系結構

最早Smalltalk公司提出了一種稱之為MVC(Model-View-Controller)的結構。將OOD體系結構分為三個主要成分：

模型:(Model)為底層應用建立模型的類和對象；

視圖:(View)為用戶提供與模型有關的類接口視圖的類和對象；

控制器:(Controller)用于控制（或同步）其他類的行為的類和對象。MVC模型模型視圖控制器

我們的OOD體系結構與MVC結構類似，但增加了一個成分：數據庫管理部分。OOD模型的體系結構問題領域部分人機交互部分任務管理部分數據管理部分類邊界類與對象層實例邊界實例連接屬性層屬性服務層消息服務結構層主題層主題

這個體系結構中使用的類和對象與OOA模型中的一樣，然后圍繞著這些類和對象，又加入了另外一些類和對象，用來處理與實現有關的活動，如任務管理(TMC)、數據管理(DMC)以及人機交互(HIC)。

OOD方法與以往方法不同，它以OOA模型為設計的雛形。

由于OOA和OOD采用相同的基本圖形表示法，更容易體現OOA與OOD工作的連續性和無縫隙性。

通過OOD將面向對象系統結構分為4個部分，通過人機交互部分(HIC)與外部世界接口。產生的問題是：作為系統的核心—問題領域部分將與外部世界隔絕，不再與外部世界交往。

代替方案是將OOD體系結構設計為：每個類和對象都

知道如何在終端用戶的PC機或終端上與終端用戶進行交互；

知道如何讀寫磁盤文件中的數據。

問題是：改變用戶接口和數據庫容易破壞體系結構，使得類和對象的內部結構更為復雜。ECS的OOD問題

設計ECS系統的體系結構的策略基本按照前面所述的方法。在建立OOD模型時，必須考慮實現時所加的各種限制。在OOA模型的基礎上增加相應的類和對象。

性能限制：如電梯每到一個樓層時都要減速，乘客就不得不忍受失重狀態，需要考慮調度算法，讓ECS來預測什么時候電梯應停在某一樓層。

功能限制：超重傳感器如果在夏天校準，可能在冬天超重狀態檢測不到。可能需要增加“溫度計”對象，調整傳感器讀數的安全性。

系統的可靠性和一致性：傳感器可能會失效，需要加入一個輪詢機制定時詢問傳感器的狀況，并把結果傳給封裝傳感器的對象。也可以增加用于監控傳感器的對象。

開發環境：系統如何實現？對開發環境有什么限制？多重異步通信靠什么支持？如果分析模型中存在多繼承，而編程語言只能支持單繼承，應如何調整？

初始化活動和結束活動：執行初始化活動和結束活動的過程是必不可少的。必須在問題領域或或其他部分說明。例如，早上ECS如何開始運行：晚上電梯關閉后如何結束運行.

人機交互：對人機界面是否有特殊的設計限制？發給電梯機構的通信指令中是否存在什么協議？是否可能是校驗和？對于具有智能輔助或聯機文檔的幫助工具有什么協議？對于需求文檔中未提到的，設計者可以不考慮。

數據庫管理：系統將管理什么類型的數據？

可復用性：可以考慮購買一個商品類庫來實現OOA的對象。盡可能保證設計出來的對象在將來的系統中也能用。要點

從OOA轉到OOD需要在OOA模型的基礎上加入實現方面的限制。

OOA模型需要用實現技術和環境方面的詳細的規格說明來加以補充。

OOD模型類似于構造藍圖。OOD模型以最完整的形式全面地定義了如何用特定的實現技術建立起一個目標系統。

在OOA模型和OOD模型中使用了共同的表示法。這有助于從分析到設計的轉換。

與OOA模型一樣，OOD模型也有5層結構，又被劃分成了4個組成部分。

問題解決部分(ProblemDomainComponent)

人機界面部分(HumanInterfaceComponent)

任務管理部分(TaskManagementComponent)

數據管理部分(DataManagementComponent)

這些組成部分把實現技術隱藏起來，使之與系統的基本問題領域行為分離開來。這種策略能夠幫助提高產品的可復用性。

對于HIC，要精心設計窗口和屏幕，為用戶提供友好的GUI。

與OOA模型一樣，OOD中各部分的構造是不斷循環反復的,而不是一個個相繼順序構造的。

首先復制OOA模型為OOD模型的問題領域部分，然后對這個部分進行修改。

利用可復用的設計／編程方面的類

根據需要,把從類庫或其他來源得到的可用的既存類增加到問題解決方案中去。

標明既存類中不需要的屬性和操作。

增加從既存類到OOA類之間的泛化-特化關系，盡可能繼承既存類的屬性和方法。

把OOA類中因繼承既存類而成為多余的屬性和操作標出。

修改OOA類的結構和連接。

加入泛化類以建立類間協議

有時某些OOA類要求一組類似的服務。此時，以這些OOA類為子類，定義一個父類。

該父類定義為所有這些子類共用的一組服務名，作為公共的協議，用來與DMC或其他外部系統部件通信。這些服務都是虛函數。

在各個子類中定義其實現。

對繼承進行調整

在OOA模型中可能包括有多繼承關系,但實現時使用的程序設計語言可能只有單繼承，甚至沒有繼承機制，這樣就需變更PDC中類的層次結構。

針對單繼承語言的調整

把子類對象看做是一個父類對象所扮演的角色，通過實例連接把多繼承的層次結構轉換為單繼承的層次結構。

把多繼承的層次結構平鋪，成為單繼承的層次結構。在這種情況下，有些屬性或操作在同層的子類中會重復出現。

針對無繼承語言的調整

當使用無繼承的程序設計語言時，必須把具有繼承關系的類層次結構平鋪開來，成為一組類和對象。人人人角色醫生教授醫生教授醫生角色教授角色醫學教授醫學教授通過實例連接分解多繼承平鋪為繼承多繼承

修改設計以提高性能

提高執行效率和速度是系統設計的主要指標之一。有時，必須改變問題領域的結構以提高效率。

如果類之間經常需要傳送大量消息，可合并相關的類，使得通信成為對象內的通信，或者使用全局數據作用域，打破封裝的原則，以減少消息傳遞引起的速度損失。

增加某些屬性到原來的類中，或增加低層的類，以保存暫時結果，避免每次都要重復計算造成速度損失。

軟件的效率性能很重要。但要作出平衡，要使PDC與原來的OOA模型盡可能相近而減少測試開銷和維護開銷。

為提高性能，在對OOA模型進行大規模的改動之前，應考慮下面一些問題：

如果沒有性能準則，不要去人為地建立。

當軟件運行在一個CPU速度很快的計算機上，并是單機的人機交互時，大多數的時鐘周期都用在了等待用戶輸入上。

不要認為象C++之類的OOPL就一定效率不高。有一些事實表明，非OOPL的緊湊代碼的效率比OOPL的效率高,在多數情況下，OOPL的效率損失約為10%。且用非OOPL編程會令程序員非常疲勞，易出錯。

提高一個現存系統的工作效率比重新設計一個高效的系統要容易。如果對設計有性能要求，只需加入少量的工作就可以了。

通常系統80%的開銷都集中在20%的代碼段上。與其為了盡量處處節省系統開銷而破壞完善的系統結構，還不如找出系統開銷最集中的地方，只對那部分做優化。

預測軟件開銷集中在什么地方是困難的,進行優化最有效的方法是在系統運行時使用性能監測工具對系統進行觀測。一些像繼承、動態綁定、消息傳遞等處理雖然看起來簡單，但需要大量的系統開銷;有的代碼看起來復雜，但效率不見得低。在代碼復雜性與運行的低效之間沒有相關性。

提高性能最好的方法是采用最出色的解決方案，而不是拼命地去節省幾個微秒、幾個字節。這個結論在面向對象技術出現是這樣，在面向對象領域仍然是這樣。ECS的PDC

決定使用一個中央控制器（電梯控制器）控制和協調電梯的所有動作，包括解決電梯每到一個樓層減速問題。

增加“電梯監視器”，用一個獨立的對象來執行監測功能（性能、安全性等）。在提交給實現者的規格說明中，將這個類放在一個與ECS的主處理器分離的處理器上.

每個類增加服務SelfTest來增強每個類的性能。在運行時執行有必要驗證其功能的操作，并向電梯監視器報告。1電梯馬達11電梯111,m1面板超載傳感器11電梯調度器到達面板目的地面板電梯控制器11,m電梯事件1電梯監視器1,m樓層11到達事件召喚事件1目的地事件ECS問題領域部分召喚面板要點

完整的未經改動的OOA模型將成為初始的OOD模型的PDC部分。

根據實現技術及實現方面的限制，修改原始的PDC部分，但保留在OOA模型中所捕獲到的基本的系統行為，

如果使用可復用的類，那么它也要引入到PDC中。

由于性能、將來的復用、程序設計語言的限制、規范化等原因，可能還需要對PDC作出一些其他改動。

設計一個良好的用戶界面是成功地實現一個軟件系統的關鍵.

在開發OOA模型時，有意避開了如窗口、屏幕等依賴于實現的細節，目的是讓系統規格說明獨立于實現。

HIC部分在系統行為和用戶交互的實現之間架起了一座橋梁。例如，可用GUIHIC或語音對答式HIC實現用戶界面。ECS的HIC

ECS的HIC由各種電梯按鈕、指示燈及它們的接口組成，不存在屏幕、窗口等用戶界面需要進行設計。按鈕人機交互部分目的地按鈕召喚按鈕上行召喚按鈕下行召喚按鈕指示燈人機交互部分目的地指示燈到達指示燈召喚指示燈上行召喚指示燈下行召喚指示燈

ECS的HIC由各種按鈕和指示燈對象組成。這些對象封裝了如何接收按鈕被按下的機制，以及如何激活指示燈的機制。

例如，考慮召喚請求如何發生。在OOA模型中敘述“當召喚請求發生時，對象‘召喚事件’將向對象‘召喚面板’報告召喚事件的發生。”等等。

實際上，“召喚事件”在它接收到從“召喚按鈕”發送來的消息之前，根本就不理會周圍的任何事務。

這個從“召喚按鈕”發送來的消息是向類“召喚事件”報告有一個召喚事件發生了。―召喚事件”的執行機制PDCHIC召喚事件召喚按鈕報告

我們有一個召喚！總結

每一個組織和用戶都有他的文化背景。可能不僅僅意味著語言、傳統和習慣。由于所建立的系統面對的是用戶，因此，其界面必須必須與用戶的文化背景相一致。

一種適應用戶文化背景的有效方法是“直觀表示”。其目的是讓人機界面適應用戶。常用的直觀表示是預置一些用戶常用的標準形式，學習和掌握它非常簡單和容易。

使用用戶開發的場景或用況來驅動界面。在執行一個特定的工作時，用戶界面應能告訴用戶下面將做什么。

使用工具定義一個高層的用戶界面和一些詳細的對話框，然后定義HIC對象，從而完成設計。建立原型時必須對所有HIC設計進行嚴格的檢驗。

HIC設計并不是一個僅當OOA模型完成后才開始的處理。事實上，在建立OOA模型的同時就開始著手HIC的設計了。在開發目標系統的HIC時，應允許用戶對其試用。

多數用戶都不會從頭開始設計HIC類。

事實上，使用各種所謂的可視化開發環境，如Delphi,PowerBuilderVasualBasic員可能連HIC都不要。直接使用這些工具提供等，開發人的控件，就可以作出用戶界面。

用戶可以不需要HIC，但不能免去用戶界面的設計。使用菜單樹或狀態-遷移圖，連同某些原型，來說明用戶界面的設計思想。

在應用中，每一個對象中的每一個服務最終都要被分配給某一個計算機任務。這樣一些任務可以被看作是一些獨立的可調度的實體。

在ECS系統中有大量的系統必須對其響應的異步事件。下面將介紹ECSOOD模型的任務管理部分（TMC）。

首先，要標識一些新的類，這些類建立后將負責處理并發、中斷、調度（在操作系統級）以及其他有關特定平臺的一些問題.

TMC把與特定硬/軟件平臺有關的處理機制封裝在自己內部，對系統的其他部分隱藏起來，一旦決定將ECS移植到另一個平臺上時，只需替換TMC中的類就可以了。

為建立TMC，首先要找出可能被封裝在TMC類中那些與特定平臺有關的部分。還要找出任務協調部分，通信的發、收關系，處理器的分配（客戶-服務器）或者消息/線程序列等。ECS的類與對象

考察ECSOOA/OOD工作表格,可以發現中斷處理和寄存器訪問是設計需求的重要部分。中斷召喚按鈕中斷目的地按鈕中斷到達中斷電梯就緒中斷寄存器輸入寄存器輸出寄存器

可以用一個類的集合來表示以上的中斷和寄存器訪問類。

與事件–響應模型中其他事件不同，超載事件沒有相應的中斷，故沒有“超載中斷”類。在設計中采用輪詢超載傳感器的方式產生超載事件。

下面完整地說明一下召喚事件的機制。

當召喚按鈕被按下時（在ECS之外），產生了一個中斷，終止正在運行的程序。同時一個二進制數存儲到輸入寄存器中。―召喚事件”的執行機制PDCHICTMC召喚事件召喚按鈕召喚中斷

按下按鈕輸入我們有一個召喚！寄存器

召喚按鈕共78個（除第1層和第40層各有1個外，其他每層各有2個）。向下的召喚按鈕編號為奇數，向上的召喚按鈕編號為偶數。零表示當前沒有按下按鈕。因此，存入輸入寄存器中的二進制數的范圍是00000000,00000010-01001111。

一旦按下召喚按鈕，第一個反應是“召喚中斷”類被喚醒，并報告“我接收到一個召喚”。

相應的“召喚中斷”對象就向“輸入寄存器”對象發送一個消息,詢問輸入寄存器的當前值.

中斷優先級規定這個值只能由“召喚中斷”對象獲取.

這個“召喚中斷”對象向類“召喚按鈕”發送一個消息，告訴它：你的一個按鈕按下了。

類“召喚按鈕”封裝了如何將寄存器值轉換為按鈕號碼的機制，它通知相應“召喚按鈕”對象：你被按下了，你要開始工作了。

“召喚按鈕”對象向類“召喚事件”發送一個消息，然后開始進行事件的處理。

封裝需要做許多工作，這些開銷是必要的。如決定增加第三個按鈕用于召喚運貨電梯，只需改動一個類“召喚按鈕”即可，而系統其他部分可一概不予改動。

在ECS中沒有數據管理部分，所有在對象中存儲的數據都駐留在內存中。

DMC說明了對系統生成的永久數據的訪問和管理，這些數據將可以在設計的其他部分中使用。之所以將數據庫管理技術從OODPDC中分離出來，是為了將來更換DBMS時可以只修改DMC讓系統其他部分可一概不動。

創建DMC的最簡單的策略就是請求。但這不一定是唯一的，也不一定是最好的。

標準

可復用性

可理解性

可以用一個簡單的場景說明在一個基于對象的系統中可能需要大量的通信和協調工作。這個代價必須付出，以獲取復用性、可維護性、可擴展性等優點。

評價面向對象設計的準則:

耦合性準則——指系統各個具體成份之間相互連接或相互依賴的強度。

這些成分之間的耦合度應當最小化；

應當盡量減少對象之間的消息數目及消息本身的復雜性；

耦合會通過泛化–特化或整體–部分層次結構產生。這要通過內聚性準則來衡量。

內聚性準則——描述系統組成中各元素的關聯度或強度。應盡量避免內聚性低。在面向對象設計時，從3個層次來考察內聚性：

單個服務的內聚性；

封裝在類和對象中的數據和服務的內聚性；

整個類的層次結構的內聚性。

從微觀的層次上，對服務的內聚性評價與結構化設計中的相同：一個服務應只執行一個功能；

在類層次結構這一級上，可以通過檢查子類重載或刪除從它們的父類中繼承的屬性和服務的多少來進行評價。

重點在于設計的明確性——看不懂OOD設計，就無法復用它。建議：

命名屬性和服務的詞要求前后一致；

避免使用過多的消息模板；

不要對類的定義摸棱兩可，遵從類的現有協議或行為。層次結構和因子分解準則

類的層次結構不要太深，也不要太淺。

一個約有100個類的中等規模的系統中，泛化–特化結構和整體–部分結構的層次大概有72層。影響層次的因素有程序設計語言、用單繼承還是多繼承等。

保持類和對象的簡單性

平均起來，每個服務所使用的屬性不應超過1~2個，而且有2／3應當能夠追溯到OOA模型。

除了處理內部事務所用的私有服務外，類所具有的公共服務不應多于6~7個。

對象之間的耦合不能過多。一個對象可能自己不能響應一個外部事件，但它不能與多于72個對象交互來完成某件事情。

保持消息協議的簡單性——復雜的消息協議常常意味著在類或對象之間有很強的耦合。一個消息需要的參數不多于3個，否則是對類的層次結構沒有做很好的分解。

保持服務的簡單性——使用某種高級語言編寫程序代碼，盡可能把為每個服務所編寫的代碼限制在一頁紙之內。使用Smalltalk語言，每個服務的代碼行數通常不超過10行。

將設計的易變性降到最低——一個差的設計會在項目的開發過程中或在日后的維護工作中顯示出一定的易變性。

例如，為改正軟件缺陷，對一個類作一些小改動，或者在軟件中增加一個新的特性，都會在許多其他類中引起一連串的反應。

利用配置管理，可以對類的變更及變更時的影響進行跟蹤和分析，檢測項目穩定性。系統整體規模的最小化——系統規模越大越不好。中型應用的類層次不應超過幾十個，每個類所包含的子類只應有十幾個左右。重視場景評價的能力——評價一個設計的好壞可以通過執行各個類和對象的行為來實現。如果無法做行為的測試，說明各個類的職責沒有描述清楚，或沒有考慮清楚。

利用以上準則來檢查ECS的OOD設計，看是否有需要改進的地方。例如

觀察對象之間的協同情況，檢查

對象之間傳遞大而復雜的數據結構(差耦合)

在對象之間進行長距離接力傳遞的數據

檢查對象中的服務，看封裝機制是否完全。

檢查繼承的層次結構，確保父類不依賴子類。

檢查父類與子類之間的消息通信。

通過檢查，了解當前的層次結構的狀況，發掘出更好的層次結構。

最后檢查OOD的命名約定。這些名字是否與對象的數據和服務相符？如果不符，為什么不符？事例分析系統的質量問題

良好的設計來自于良好的分析。

一個好的設計是從預分析技術開始的。從產生的OOA/OOD模型來看，幾乎所有的對象都是高內聚、低耦合的。因為它們是在對應用領域概念進行基于語言的分析后產生的。

ECS系統的大部分設計簡單明了，對象包含了數量合理的屬性和服務，耦合性和內聚性也很好。但在作出決策建立集中控制的“控制器”和“調度”類時存在一些問題。為提高效率和調度，降低了許多類的可復用性。

關于OOA模型的文檔編制和評審過程方面的大部分說明也同樣適用于OOD模型，一個明顯的區別則在于OOD模型的文檔所面對的對象是設計人員和實現人員，而不是用戶。

OOD模型的文檔好比建筑師設計出來的建筑樓房用的藍圖，應具有詳細的細節。其詳細程度應當能讓實現系統的人清楚地知道他們所要建立的系統到底是一個什么樣的系統。

各個項目要求的詳細程度各不相同。最重要的是看實現人員是誰。

在小規模的項目中，實現人員就是設計人員。這時，幾乎不要求或很少要求設計文檔。

如果設計人員在某一個大陸上，而實現人員在另一個大陸上，就需要大量細節的說明。

不同的項目可能有不同的文檔標準需求。

為了更好地描述OOD模型，可以使用任何類型的圖形表示工具或其他規格說明。在與實現人員就設計進行通信時，這些圖形表示和規格說明是很有用的。

我們希望將所開發的用戶界面屏幕放到設計文檔中。對于某些系統時序圖、算法規格說明、圖解、統計–預報曲線、電子數據表格、流程圖等，都可以放在設計文檔中。

設計評審過程是一個持續進行的過程，與項目組織的文化背景有關，與正式的里程碑評審過程不同。

事件、場景、使用事例的概念是設計評審的依據。為了識別事件并產生相應的響應，必須給出所有的設計。結論是：如果在一個給定的設計中說明了所有的系統事件和響應，那么這個系統就一定能成功！程序設計語言的考慮

以往談到復用，總是想到代碼復用。現在談復用時，是指復用事務規則、需求、環境、文件、體系結構、測試計劃等。事實上，軟件工程生存期內所有的工作結果都可以被復用。面向對象是一種先進的技術，它使得可以復用的東西遠遠超過了代碼。

可以使用非面向對象程序語言實現面向對象程序。理由是：

許多老程序員對面向對象不熟悉，但他們了解業務和事務規則。

以前遺留下來的大量程序代碼全部重寫是不明智的。

每個項目都有自己獨特的應用環境。有些項目不可能將程序轉換為面向對象的程序。

對于面向微處理器的嵌入的、實時的程序，只能用普通的匯編語言編寫程序。

有的人只學習了C++的語法，而沒有學習任何有關面向對象的開發模式。其結果就是自頂向下，從功能上分解對象。所以應首先在OOA和OOD方面對程序員進行培訓。一個迭代的軟件開發過程

任何一個軟件系統的分析和設計都是在整個軟件開發過程的上下文環境中執行的。開發過程會影響對象技術。但總的說來，開發過程獨立于開發環境或開發過程。

如果一個項目的各個階段和工作成果在一個可控制的和可管理的方式下可以重做，那么這樣的軟件開發過程就是一個迭代的過程。

對于一個大而復雜的軟件系統，采用迭代的軟件開發過程非常重要。

下圖給出一個通用的迭代的軟件開發過程，這個過程稱為基于線程的開發過程。

圖中的各種活動并不是以瀑布流水的方式組織起來的。這些活動進行了一次又一次。

用于履行這種迭代的機制就是線程。從概念上，可以認為線程就是事件的分片實現。其他信息,OOD工作表格文獻,手冊,類似預分析基本模型產品等活動預分析工作產品(OOA工作表格,OOAOODE/R,初始GUI布局)分初始GUI布局(包括各種功能定義,圖形用戶界面設計設計模型各種軟件需求配各種需數據定義等。)GUI求定義,各建模種需OOP求支持包括：追蹤能力矩陣,配置管理,各種管理報告,各種度量等Deploy-實現ment文檔產品項目數據庫

在實現時，線程可以是系統的一個工作片段。可以認為系統一次在執行一個線程。

優點：很多問題，如誤解了用戶要求或技術缺陷等，能夠在開發過程的早期被暴露出來。

下圖描述了項目開發組在某一天根據迭代的開發過程進行的活動。

首先，根據所標識的需求和項目計劃，選擇出當天所要實現的線程，再開會討論。

可能提出的線程中有一些不能實現，這些線程就需要修改，或者對需求提出質疑。最后，用戶要求中不能實現的部分要重新商定。初始線程標識需求選擇一個線程將線程標記于矩陣中與開發組會商要更改RDM修改RDM嗎？要建立或修改線程嗎？基于線程的實現流程圖

然后將所驗收的線程交給開發組，一個組負責設計用戶界面，一個組負責面向對象建模。

兩個組完成設計后，線程的設計交給實現組，他們將其快速實現，解決所發現的問題。

一天結束時，項目開發組對這天實現的線程進行評審。評審使用系統的一個實際可以運行的版本，將所實現的線程納入該版本。有些線程可以接受，有些現成需要重做。

在一段時期內所實現的線程構成最終產品的一個不完整版本。將線程分布到各組將線程分布到各組產生OOM線程段需要產生數產生實現方案產生數據庫據庫實現方案嗎？評審線程線程可接受嗎？解除處理基于線程的實現流程圖(續)在快速應用開發(RAD)環境下實現面向對象的設計

目前存在多種應用程序構造系統，即RAD環境。用這些RAD工具開發應用程序，其優點在于復用和可維護性。

原因在于RAD工具通常不支持事物分離規則。就是說，它們可以將事務規則、用戶界面技術以及數據庫訪問技術等集成在單個單元之中（如VisualBasic表格）。由于它以快速系統展開為基礎，因而RAD工具的成本是合理的。

使用RAD工具，應當遵守基本的面向對象開發模式。需要有項目標準和開發人員守則。

將所有的問題領域部分中的對象映射到RAD部分中，稱之為“RAD對象”。使所有的系統邏輯都包含在其中。這種實現獨立于用戶界面和數據庫問題。

所有人機交互部分中的對象應作為RAD的屏幕和表格實現。這部分可能不封裝事務規則或數據庫訪問規則，屏幕和表格只與RAD對象通信。

所有的數據庫接口都通過RAD對象實現。

對象的屬性和服務都是由RAD工具提供的程序設計語言的變量和子程序。

RAD對象之間的消息傳遞都通過函數或子程序調用來完成。

實例連接、泛化-特化關系、整體-部分關系由RAD對象間的共享變量實現。對基于對象的設計進行測試

將系統級測試與對象級測試區分開是很重要的。下面就前面介紹的分析和設計技術的范圍內進行討論。系統級的測試

黑盒測試

這種測試基于系統級的規格說明。規格說明包括需求定義模型、事件－響應模型和用戶界面規格說明。黑盒測試的目的是要確認功能的執行與規格說明相一致。

測試的最有效方法是建立應用領域的場景(即使用實例)。從用戶角度捕捉系統行為。

黑盒測試必須要有實際用戶，最好是在一個真實世界的環境中進行。

黑盒測試需要兩類測試人員：一類是熟悉開發方法的人，他們能夠看懂各種圖表、符號；另一類是用戶，他們對用戶界面最有發言權。

黑盒測試的優點是不需要特殊的測試環境。在普通開發環境中利用發布前的各種結果就可以做。但需要說明的是，要保存所有測試的日志和記錄。白盒測試

基于各種設計文檔中所定義的內部系統結構。

這些文檔包括EROI圖、OOA和OOD模型以及GUI設計文檔等。

在EROI圖中定義的類所能識別的每一個事件都必須經過驗證。

各個類之間的協同，以及EROI圖中所定義的對事件的響應也必須經過驗證。

這種驗證不包括服務級的測試。因為它屬于對象級測試。

總的來講，白盒測試是在相關的黑盒測試完成之后進行的。

白盒測試最好由不屬于該項目組織的人來做。

要求執行白盒測試的人熟悉開發環境和設計方法，對應用領域的知識不是必須的。

由一個項目組的成員來測試另一個項目組的工作成果，往往是很有效的。

白盒測試的準備工作由一個獨立的小組完成。首先建立測試環境。其次，要求能夠訪問軟件的消息、屬性，及其他軟件成分。

這種測試環境應當有助于維護所有已完成的測試的日志和記錄。事實上，這些日志和記錄可能會建立某種與合同有關的里程碑。對象級的測試

對象級測試獨立于任何特定的應用系統。

由于對象可以在許多不同的應用程序中復用，因此必須在通用的復用環境中執行。

對象級黑盒測試

對每一個對象進行的黑盒測試是通過一個對象級的測試臺來完成的。這個測試臺能夠讓對象接收消息，并能對所生成的消息進行顯示、捕捉和分析。

黑盒測試應當由開發組進行。

這種測試要求在消息的源端或目的端用虛擬的樁(stub)操作代替實際的源端服務或目的端服務，以便獨立地對每個服務進行測試。

每個對象還應帶有一個用戶手冊，這個用戶手冊中的對象描述應獨立于任何特定應用。它是黑盒測試的基礎。對象級的白盒測試

對象級的白盒測試也是由開發組完成的。該測試主要是對所有的服務及其組成部分進行檢查，以確認它們與服務的規格說明和屬性定義是一致的。

該測試要求使用特定的測試平臺，測試平臺能將所要測試的對象從其他對象中分離出來，從而獨立于其他對象和應用環境。

由于提交大而復雜的軟件系統所造成的在預算和進度上不斷增加的壓力，促使許多開發機構從當前傳統的軟件開發方法倉促地轉向面向對象方法。

我們給出12個步驟，幫你轉向面向對象的方法。我們不能保證這些步驟很容易實現，但按這些步驟認真去做，肯定不會失敗。步驟1：接受必然發生的事情

不遠的將來，面向對象方法將會在各種軟件開發方法中占據統治地位：

在質量和產量方面它占有巨大的潛能；

經銷商的支持正在迅速增長；

第一批采納面向對象方法的團體正在顯示他們的成功；

許多重要的標準正在制定中，有些已公布；

接受這些必然發生的事情，在思想上建立起這些概念，這是通向成功的關鍵因素。

沒有回頭路可走。步驟2：理解，理解，還是理解

轉向面向對象的原因—復用(Reuse)。

復用能帶來高的投資回報率(48個月后達30:1)。

進行復用不一定非用面向對象方法，但面向對象方法能使復用成為可能。

面向對象方法所帶來的收益將在下一個項目中得到。也許可能要到再下一個項目。

轉向面向對象的過程有兩種觀點：逐漸演變或全新變革。必須了解哪種方式適合自己。

對大多數人來講，完全拋棄以前的所有成果從頭開始是一種很愚蠢的做法。步驟3：對財產進行評估

在評估軟件開發過程時，要識別和區分工作產品和人工制品。

工作產品是指作為特定項目的里程碑應當提交的成果；

人工制品是指在開發過程中產生的不交付的成果，如數據流圖、結構圖等。

這些人工制品應成為面向對象過程的一部分。

還需要評估人力資源。

然后擬訂過渡計劃，標識出新的面向對象工作產品和支持這些工作產品的人工制品，將這些對應到當前的過程中。步驟4：標識一個“共生項目”(Symbioject)

如果對一個新的陌生的技術沒有充分了解，沒有弄清它對項目、組織和人員有什么影響之前，貿然使用它開發一個重大項目是非常莽撞的。

理想的做法是先上一個試驗性的項目，它與負有重大任務的項目有共