在這里，需要解釋一下所謂的“三層”結構模型：用戶界面層、事務規則層和數據層。三層結構是對客戶/服務器結構的擴展，在客戶/服務器模型把用戶界面和數據存貯與處理分離的基礎上，三層結構把事務規則獨立成為一層。為什么呢？大家知道，在一個系統中，最容易發生變化的是系統的界面，其次是系統的處理邏輯、規則和功能，最穩定的是系統中的數據。如果我們把處理邏輯放在客戶端，那么對處理邏輯的任何一點修改都要對每個客戶進行修改；反過來，對用戶界面的改動也可能會影響到處理邏輯。如果我們把處理邏輯放在服務器一端呢？勢必會影響到數據的穩定性。所以，把處理邏輯單獨分為一層，可以使系統的結構更加清晰、可擴展性、穩定性更強，為以后的擴充和維護帶來了極大的好處�，F在很多公司都出品自己的專門用于中間的事務規則層的所謂“應用服務器”，包括NetScape的Application Server、Microsoft的Transaction Server等等。隨著Internet和WWW的發展和“瘦客戶”的流行，用戶界面逐漸向瀏覽器上靠攏，而應用服務器和Web服務器的結合也日漸緊密，這些發展對進一步降低成本，增強系統的擴充性、可配置性、可管理性等等都起到了很大作用。
面向對象軟件工程的一個很大的好處就是在分析和設計之間沒有什么明顯的區別，更不會有傳統軟件工程中在分析和設計之間的語義上的鴻溝。在分析進行到一定程度時，把具體實現環境的因素考慮進來，就自然過渡到了設計階段。由于我們的小例子使用文件系統存貯ToDo表的信息，所以我們需要一個CFile類來封裝文件系統的功能和操作。
至此，我們的小例子的靜態結構分析和設計已經有了初步的成果。接下來，可以根據這些成果分析和設計系統的動態結構。這包括細化和修改Use Case的描述，比如把類的操作和對象之間的消息相對應、充填參數等等，還有為比較復雜的類設計狀態圖等工作。因為這個例子比較簡單，沒有什么比較復雜的類，所以沒有必要設計狀態圖，只需要細化一下Use Case的順序圖就可以了。
這些分析和設計的工作經常是相互影響和促進的。你常常會在分析動態結構的時候，發現漏掉了一個類、一個屬性，或者需要加上一個操作；而隨著對靜態結構的進一步深入刻畫，對類之間的關聯、消息傳遞的設計也會不斷發生變化。所以我們要不斷的對設計方案進行深化和細化，直到達到一個穩定的狀態，這時我們就可以考慮系統的實現了。
實現模型
在邏輯模型建立之后，我們可以建立實現模型。
在實現模型中，我們定義一些組成軟件系統的部件，比如DLL庫啦，EXE文件啦，Java Applet啦，ActiveX Control啦，Web頁面啦等等。定義這些部件和它們之間的關系，對代碼的自動生成、軟件系統的配置、測試管理、軟件的打包發行等等都有很大的好處。
對于我們這個小例子，只有一個部件——最終的EXE文件ToDoList。
在ROSE中的Component View包中，我們創建這個部件。然后可以將各個類拖動到這個部件上，這表示這些類最終是用這個部件實現的。
做完了所有這些活，我們就可以自動生成代碼了！ROSE可以自動生成C++、Java、CORBA IDL、Visual Basic、Visual C++、Oracle Schema等等不同語言和系統的代碼，并且可以進行“雙向工程”——模型和代碼之間的雙向轉換，大大減輕了代碼書寫的工作�？墒谴a生成內容很多，已經不是我們這個簡單的教程所能包容的了。只有等以后有時間在作個專題吧。很期待吧？呵呵，那就請你多支持我嘍！
文章來源于領測軟件測試網 http://www.kjueaiud.com/
