面向對象的軟件工程和面向對象的方法學(xué)是前人經(jīng)驗的積累，我覺(jué)得應用軟件建模的可以用四個(gè)階段：需求建模、分析建模、構架建模、設計模式。
如何獲取需求，如何對描述問(wèn)題域的需求模型導出分析模型，如何進(jìn)行架構建模、設計出高度可擴展性的良好架構，如何應用設計模式、對模型進(jìn)行不斷改進(jìn)和重構，這些都是必須實(shí)踐的問(wèn)題，也是必須從各種各樣方法學(xué)進(jìn)行學(xué)習的問(wèn)題。
在需求方面，根據不同的情況，Use case, Use map, CRC都是可以利用的，還有Alistair Cockburn的用例模版；
在建模方面，UML是標準，建模過(guò)程中需要經(jīng)常借鑒分析模式的內容，分析模式對系統問(wèn)題域的建模作用是無(wú)窮的，對諸如party , business rule , inventory , account這樣的東西，對問(wèn)題域的分析和分析模型的抽象獲取很有幫助；
對于軟件體系架構建模也有很多前人的經(jīng)驗供參考與借鑒，在此基礎上根據應用系統的不同環(huán)境靈活應用對架構建模非常有益，比如在《Pattern-Oriented Software Architecture (面向模式的軟件體系架構) 》中首次提出了8種體系結構模式： 層（Layers）、管道和過(guò)濾器(Pipes and Filters) 、黑板(Black board )、代理者（Broker）、模型-視圖-控制器（Model-View-Controller）、表示-抽象-控制（Presentation-Abstraction-Control）、微核（Microkernel）、映像（Reflection）
在設計時(shí)，通過(guò)建立的模型從而應用設計模式是常用的方法，發(fā)覺(jué)設計模式社團是如此的豐富，以至于你幾乎很難再去構造出新的模式，但根據長(cháng)期的使用積累，對具體的一些場(chǎng)景會(huì )有一些小的發(fā)現。譬如，在系統里使用factoryMethod創(chuàng )建對象，Observer, strategy 實(shí)現MVC，用command和來(lái)實(shí)現undo , redo,用fa?ade模式來(lái)進(jìn)行層與層之間的交互，State模式應用，例如購物過(guò)程（登錄、下單、結賬），Singleton就不用說(shuō)了，使用模式進(jìn)行分析和設計是如此靈活、有效，我覺(jué)得他們能解決設計中大部分問(wèn)題。
根據不同的實(shí)現語(yǔ)言，應用一些面向對象的基本技巧如idiom , refactoring對模型進(jìn)行重構、優(yōu)化也非常重要。
1、需求建模
在軟件工程中，用例是一種在開(kāi)發(fā)新系統或者軟件改造時(shí)捕獲潛在需求的技術(shù)。每個(gè)用例提供了一個(gè)或多個(gè)場(chǎng)景，該場(chǎng)景揭示了系統是如何同最終用戶(hù)或其它系統交互的，從而獲得一個(gè)明確的業(yè)務(wù)目標。用例要避免技術(shù)術(shù)語(yǔ)，取而代之的是最終用戶(hù)或者領(lǐng)域專(zhuān)家的語(yǔ)言。用例一般是由軟件開(kāi)發(fā)者和最終用戶(hù)共同創(chuàng )作的。
需求建模誤區：在需求獲取的過(guò)程中有一個(gè)非常容易犯錯的誤區即把軟件的用戶(hù)界面模型當成需求模型，其中在網(wǎng)站類(lèi)的軟件項目尤為突出，從事網(wǎng)站或者類(lèi)似的軟件需求的許多人都不懂真正的軟件需求是什么東西，甚至包括一些SAP/ERP項目這類(lèi)都是同樣的問(wèn)題，盡管那不是網(wǎng)站，他們犯的一般共同的錯誤就是把網(wǎng)頁(yè)表現形式（那其實(shí)是美工的工作），以及內容的采排看作是需求，完全沒(méi)有一個(gè)用例的觀(guān)念。
2、分析建模：
面向對象開(kāi)發(fā)過(guò)程中一個(gè)很重要的原則是：設計軟件使得軟件的結構反映問(wèn)題的結構。按照這樣的一個(gè)原則，我們發(fā)現從分析到設計所得到的模型最終都存在某種內在的相似性，使得大多數人覺(jué)得它們之間沒(méi)有多大的區別。事實(shí)是否如此呢？
分析和設計之間還是存在著(zhù)不同之處，這些不同之處也就是分析模式的用武之地。在進(jìn)行分析時(shí)想方設法去理解問(wèn)題的本質(zhì)，這不僅僅是用用例(Use Case)列出需求清單這么簡(jiǎn)單的事情。在軟件建模過(guò)程中，經(jīng)過(guò)需求建模，從問(wèn)題域得到系統的需求模型，從需求獲取的角度上看這是一件很有價(jià)值的事，但并不代表著(zhù)就可以直接進(jìn)入到設計階段，對捕獲的需求模型進(jìn)行深入分析、抽象，引用業(yè)界已有的分析模式對需求模型描述的問(wèn)題域進(jìn)行進(jìn)一步抽象，獲得分析模型。
3、架構建模
在開(kāi)發(fā)過(guò)程中得到的一些好的架構經(jīng)驗總結，稱(chēng)之為架構框架。所謂的架構框架實(shí)際上是一種可重用的架構模式，這種模式是從好的架構模式里總結出來(lái)，這些架構模式可以進(jìn)一步地被其他人所重用。
在經(jīng)歷60年代的軟件危機之后，使人們開(kāi)始重視軟件工程的研究。來(lái)自不同應用領(lǐng)域的軟件專(zhuān)家總結了大量的有價(jià)值的知識。 當初，人們把軟件設計的重點(diǎn)放在數據結構和算法的選擇上，如Knuth提出了數據結構+算法=程序。 但是隨著(zhù)軟件系統規模越來(lái)越大、越來(lái)越復雜，使軟件系統的架構越來(lái)越重要。
軟件設計的一個(gè)核心問(wèn)題是能否使用重復的體系架構，即能否達到體系架構級的軟件重用。也就是說(shuō)，能否在不同的軟件系統中，使用同一體系架構?；谶@個(gè)目的，許多學(xué)者們開(kāi)始研究和實(shí)踐軟件體系架構的模式問(wèn)題。在《Pattern-Oriented Software Architecture (面向模式的軟件體系架構) 》中首次提出了8種體系結構模式： 層（Layers）、管道和過(guò)濾器(Pipes and Filters) 、黑板(Black board )、代理者（Broker）、模型-視圖-控制器（Model-View-Controller）、表示-抽象-控制（Presentation-Abstraction-Control）、微核（Microkernel）、映像（Reflection）。
4、設計模式
設計模式是支撐架構的一種重要組件，這與建筑有很相象的地方，一個(gè)建筑物建立設計需要建筑架構設計，在具體施工中，有很多建筑方面的規則和模式。 在一定程度上，架構設計是骨架，設計模式就是肉
設計模式是在一定的上下文環(huán)境中，用于解決一定的問(wèn)題，在尋求解決方案時(shí)會(huì )遇到的一些阻力以及給出的解決方案。在設計模式使用的過(guò)程中，靈活應用是關(guān)鍵，一般有兩種方案能夠幫助開(kāi)發(fā)、設計人員比較好的使用設計模式：一是，根據場(chǎng)景，但凡設計模式都是在一定場(chǎng)景下某些問(wèn)題的解決方案，對系統進(jìn)一步分析，找出適合一些被廣泛承認的設計模式使用的場(chǎng)景，并根據模式給出解決方案；二是、重構設計方案，設計進(jìn)行的過(guò)程中對已有的設計方案進(jìn)行重構，一個(gè)可改進(jìn)的設計，設計方案本身會(huì )呈現一些與“臭味道”，重設計模式的角度，對設計方案不斷重構，也是一種設計良好系統的方法。
在系統的進(jìn)一步設計和開(kāi)發(fā)中，必將用到大量的設計模式，模式并非發(fā)明的，是在應用的過(guò)程中發(fā)現的，作者也試圖去發(fā)現一些在某些場(chǎng)景中的某些問(wèn)題的通用解決方案，并歸納成模式。設計模式的靈活應用也是很有意義的，這就需要根據個(gè)體的經(jīng)驗和掌握程度來(lái)決定。
五、綜述
在以上應用軟件建模的幾個(gè)領(lǐng)域中，每一個(gè)領(lǐng)域都解決了軟件模型構建過(guò)程中一定層面上的問(wèn)題，這些都是值得研究的重點(diǎn)。對這幾個(gè)領(lǐng)域模型的了解、學(xué)習、使用、總結、抽象，試著(zhù)自己提出在一定上下文環(huán)境中針對一些特定問(wèn)題的解決方案的模式，這些工作我認為都是很有意義的。
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
