如何設計一個應用軟件
當今時代軟件行業各種新的技術層出不窮。但是我認為軟件行業最根本的技術在于以下幾個內容：
1、操作系統。
2、編譯系統。
3、數據庫管理系統。
4、協議。
5、算法。
6、應用軟件。
這六種技術構成了各種各樣新技術的根基。
計算機發展至今，以應用軟件種類最為煩多。國外有著眾多商業化的應用軟件提供商。Windows下我們所熟知的應用軟件有：MS Office\Photoshop\Flash\Firework等。我這里所討論的應用軟件指的是經典的應用軟件，它們有一些共同的特點：可以創建新的文檔，可以保存文檔，可以讀取文檔，可以對文檔按要求進行修修改改。Windows下記事本可以認為是最簡單最基本的應用程序。而其它一些軟件，例如掃雷、紙牌歸入游戲軟件，winamp歸入娛樂軟件，DAEMON Tools Lite歸為工具軟件，它們均不歸入我在這里所討論的應用軟件。
國內的應用軟件能夠在國際舞臺上占據一席之地的并不多。歸根結底是利益的問題，因為應用軟件的開發存在著開發周期長、設計非常重要、需要開發人員多、投入大等問題，并且短期內不能實現贏利。我們可以想像，從頭開發一個類似于Photoshop的軟件，需要多少人月才能完成。因此國內的許多廠商寧可花費巨資去開發游戲，因為游戲有有效的贏利方式。
應用軟件的開發需要沉淀。這里的沉淀理解為“一個城市有著深厚文化的沉淀”的沉淀。因為應用軟件總是在不斷的升級過程中。升級似乎不會有盡頭。升級也伴隨著操作系統的升級。有時可能需要將應用軟件從一個平臺移動到另一個平臺上。升級的主要目的是增加新的功能，增加合理的智能提示，校正以前的一些BUG，改變更加優美的界面等等。例如我們所熟知的MS Office的升級之路：MS Office 97/MS Office 2000/MS Office XP/ MS Office 2007，這中間可能還會有我漏掉的一些版本。
很顯然，應用軟件的設計非常重要。一個好的設計可以使得優秀的軟件在升級過程中后來居上，一個不好的設計可能會使得開發陷入泥潭，使得升級工作無法進行。
以下內容我以我所寫的MyUML建模軟件為例，討論如何設計一個應用軟件，希望能夠給希望從事這一領域的人們一點啟示。myuml在ww.myuml.net下載。
寫MyUML的過程中，我感覺到寫應用軟件可以歸納為一個框架模式，我這里所說的模式可以理解為“分析和設計模式”中的模式。實質上這種模式類似于MVC模式，我只不過是將其具體化、拓展。
一、首先要考慮開發平臺、開發語言。
如果使用Java語言進行開發，可能就不需要考慮運行的操作系統了。例如建模軟件中的argoUML，在Linux和Windows下都能不做更改、很好的運行。但是Java語言所寫的軟件在速度上還是偏慢，不過隨著電腦硬件速度的提高，這個問題正在得到解決。
如果在Windows下進行開發，可能還需要考慮微軟公司的ActiveX技術，通俗的講，就是可以直接在瀏覽器中使用我們所編寫的應用程序打開我們的應用程序所支持的文檔，或者在Word中直接插入我們的應用程序所支持的文檔，或者在我們的應用程序中插入Excel文檔等等。
我一直比較偏愛c++，因此使用了c++來寫這一個應用程序。為了便于移植，沒有考慮微軟公司的COM技術。
二、應用軟件的內核：對象或者數據結構+算法
很顯然，面向對象相對于面向過程更適用于寫應用軟件。
這里涉及到主要問題是應用軟件應該采用怎么樣的對象來表達對應的文檔。
注意在此時，我們的應用程序還沒有任何圖形化的界面。我們希望能做的內核能夠達到這樣的要求就行了：在測試程序中，說的通俗一點，就是我們寫一個main函數，然后在該函數中，我們可以創建一個對象，然后調用該對象的各種方法，跟蹤其方法，查看是否能夠實現要求。
例如我寫MyUML的過程中，就一直使用這種方法來測試內核的正確性。我會創建一個模型對象，然后調用這個對象的“添加包”方法、“添加類”方法等等。做這些事的時候，我甚至根本就沒有考慮過以后的用戶接口界面也就是圖形界面究竟是什么樣子。
三、應用軟件的文檔：文件、文件格式、文件保存及讀取。
通常來說，一個實用的應用軟件，其文檔所對應的對象（或者數據結構）是非常復雜非常龐大的。例如Word，一篇文檔可能包括各種不同格式的文字、插入的圖像、自己繪制的圖形、甚至還有鏈接的Excel對象等等。因此這里還有一個大的問題需要解決：如何將這個對象的所有信息正確地保存到文件上及如何將其從文件中正確的讀取出對應的文檔對象？
解決這個問題同樣有多種方式，一種方式是創建自己的專有文件格式，例如DOC文檔、FLASH動畫文檔、Photoshop所創建的PSD文檔，這時自己可能需要做詳細的文檔（這里的文檔指的是記錄這些專有文件格式的文檔），將這些格式進行記錄，供開發人員參考。第二種方式是采用公開的文件格式，當然最好采用標準化后的文件格式。第三種方式是采用XML來記錄文件格式。
我使用的是第三種方式。XML用來記錄對象信息有一種獨天得厚的優勢。當然具體內容請各位朋友們參考相關書籍。在這里涉及到第一個支持庫的問題：是使用已有的XML解析庫還是自己寫一個XML解析庫？當然網上也有開源的高手們所寫的XML解析庫拿來參考。我最后選擇了APACHE的XERCES_C解析庫。
談到庫的時候順便談一下STL庫。STL雖然是一個標準庫，但是有許多實現。到底選擇哪一個呢？仁者見仁，智者見智。我選擇的是STL port。
這些庫中也可能會存在BUG或者不足之處。當然出現BUG的可能性是非常非常小的。如果碰到對中文的支持不夠，改為Unicode編碼即可。同時建議我們寫程序的時候，如果有用到這些庫，最好循規蹈矩，不要玩花樣。
四、應用軟件的界面及各種輔助庫。
如果內核寫出了一個大概，就可以考慮寫界面。根據我的經驗，內核不可能一次到位，最終還是要修改的，不過只要將內核和界面的接口處理好，實現我們軟件工程中的最小耦合，內核和界面的相互間的影響并不大。
商業廠家可以請專業人士設計界面。相對來說，界面離不開:框架窗口、菜單、工具欄。用戶使用應用軟件通常從菜單入手或者從工具欄入手。
我們個人寫界面通常也不大可能直接從Windows SDK寫起，當然排除一些高手。順便提一句，我看過羅云彬先生的《Win32匯編教程》（書名忘記了，大致是這個意思，現在我這里不能上網，不能確定），看完后，我認為完全可以從匯編語言寫界面，不過效率可能會低一點。
界面庫也有許多可以供選擇。Windows下最有名的當然是MFC了。我寫MyUML的時候，QT還沒有出LGPL許可證，c系的圖形庫我用著實在是有些不習慣。最后我選擇了MFC。
同時我們可能還需要一些寫一些輔助庫來實現我們的應用程序。例如在MyUML建模軟件中，需要處理繪圖，因此我將相應的繪圖的功能寫在一個圖形庫中。
五、應用軟件的視圖
視圖的功能是將文檔以可視的方式顯示給用戶。我們可能會需要以不同的方式查看文檔，或者我們需要查看文檔的不同內容，因此可能需要有多個視圖。
例如在MyUML建模軟件中，我們可能需要查看一個模型的內容，這個模型中有哪些包、有哪些圖、有哪些類等等，這里我們需要用一種視圖來表示模型的內容。通常使用樹的方式比較合適。我們也可能需要查看一個類的屬性，一個圖的內容。這時圖的內容可以使用MFC中CView類的派生類的方式，而類的屬性可以使用一個對話框來表示，它們都可以視為視圖。盡管在MFC中視圖類是一種特殊的類。
洋洋灑灑寫了這么多。真正實現一個實用的的應用軟件的時候，可能會遇到各種各樣的困難，但是這些困難都是可以一一克服的。因為別人能做到的，我們也能做到。