軟體專案技術路線
篇一：大型軟體系統技術路線分析
大型軟體系統技術路線分析
縱觀全球大型軟體系統軟體系統技術發展路線，歷經了二十多年的時間，逐步從vb、.NET向J2EE java全面遷移，迄今為止，所有的集團客戶和高階政府機關在大型軟體系統技術的選擇上，幾乎清一色的選擇JAVA品臺，而且面向集團化的大型軟體系統定位的企業，如九思軟體、東軟集團，也統統在此路線上完成系統的架構和功能設計。
在國外，JAVA技術已成為解決大型應用的事實標準，符合J2EE規範的應用伺服器則是構建面向物件的多層企業應用的中間核心平臺。因其具有易移植性，廣開放性、強安全性和支援快速開發等特性，成為面向物件開發組織應用的首選平臺。參照文件如下：
基於J2EE應用伺服器支援EJB元件開發技術，包括訊息佇列、負載均衡機制和交易管理等。支援中大型網站和中大型組織應用等需要大規模跨平臺、網路計算的領域。 軟體構造有幾個不可逆轉的發展方向:XML資料結構、面向物件的構件技術、網路化應用。其中Java 因為與平臺無關、安全、穩定、易開發、好維護、很強的網路使用性等, 而成為主流環境。 J2EE是企業級應用的標準。
J2EE平臺提供了一個基於元件的方法，來設計、開發、裝配及部署企業級應用程式，並提供了多層的分散式的應用模型、元件再用、一致化的安全模型以及靈活的事務控制機制。使之具有重用的能力，並集成了基於XML的資料交換 一個統一的安全模式及靈活的事務控制。
J2EE應用程式由元件構成。一個J2EE元件是自包含的，與其相關的語氣它元件通訊的類及檔案整合到J2EE應用程式的功能軟體單元。J2EE規範定義了下面一些元件：
1）、執行在客戶端的應用客戶程式及小程式。
2）、運行於伺服器網路的Servlet&Jsp元件。
3）、運行於服務端的企業邏輯元件。
J2EE元件用Java語言編寫，透過相同的方法編譯。J2EE元件與標準Java類的不同之處在於J2EE元件整合到了應用程式中，與J2EE規範相容，並部署到負責執行、管理的J2EE伺服器上。
基於J2EE企業級應用伺服器的結構
基於J2EE的企業級應用伺服器是基於Web Services 的新一代應用伺服器。在設計上突出了XML的應用，比如XML在本地化的儲存及各種處理；透過SOAP與 .NET及透過IIOP與CORBA的連線等。
Web Server
基於對本系統需求的深入分析，我們建議採用B/A/D應用模式，這樣，這樣，跨系統平臺、效能優異的Web Server是我們必須要認真考慮的。
Servlets 是網路化的元件, 被應用於網路伺服器的功能的擴充套件。 它從客戶主機(如: 瀏覽器)得到命令和要求， 並將內容反饋給主機， 實現從HTML介面傳遞到網路商務系列。 無論如何, Servlets是不必要連線到網路伺服器上的， 它們可被作為普通的命令要求元件， Servlets 更適合於實現簡單要求的需要， 並且不需要應用軟體伺服器的管理。
JSP與Servlets非常相似。 事實上, 它們的最大區別是JSP為非純Java程式碼, 更易於感知。 如果希望看到並感覺到配置是與其它配置分開的, 並且易於維護, 可以使用JSP，JSP擅長於此，它們易於被編寫及維護。
XML
當前，對XML的技術應用如火如荼，在我們的系統解決方案中，XML技術的應用也是不可缺的重要組成部分，這就要求我們選擇的技術架構必須提供對XML技術強大支援。
當前，J2EE架構在廠商市場和開發者社群中倍受推崇。作為一種工具，可擴充套件標記語言（XML）簡化了資料交換、程序間訊息交換這一類的事情，因而對開發者逐漸變得有吸引力，並開始流行起來。自然，在J2EE架構中訪問或整合XML解決方案的想法也很誘人。因為這將是強大系統架構同高度靈活的資料管理方案的結合。 XML的應用似乎是無窮無盡的，但它們大致上可以分為三大類：
1.簡單資料的表示和交換（針對XML的簡單API（SAX）和文件物件模型（DOM）語法解析，不同的文件型別定義（DTDs）和概要（schemas））
2.面向訊息的計算（XML-RPC（遠端過程呼叫），SOAP協議，電子化業務XML（ebXML））
3.使用者介面相關、表示相關的上下文（可擴充套件樣式表語言（XSL），可擴充套件樣式表語言轉換（XSLT））
這幾類應用在J2EE架構中恰好有天然的對應：資料表示和交換功能是EJB元件模型中持久化服務（persistence services）的一部分，基於訊息的通訊由Java訊息服務（JMS）API來處理，而介面表示正是Java伺服器頁面（JSP）和Java Servlets的拿手好戲。
Web Service
我們將要建造的是一個縱向、橫向交錯聯結的、綜合的系統，裡面的各種軟體平臺共存，而又存在著互聯互通的需要，Web Service正是解決這一問題的有效解決方案。同樣的，J2EE框架對Web Service技術也提供了強大的支援。
J2EE框架透過一組API包(JAXM、JAXP、JAXR、JAX-RPC)對Web Services提供支援。J2EE的Web Services一般是透過EJB來實現，然而也可以把提供Web Services實現的Java應用獨立出來，這完全依賴於設計和構建應用程式的業務處理和資料邏輯層。有多家公司已經構建了基於J2EE的整合開發環境(IDE)和應用伺服器，他們中的多數已經開始在產品中支援Web Services的建立、部署和執行，對Web Services標準的支援和複雜的程度因產品而異。多個獨立的公司，包括IBM、BEA、Oracle、HP、Sun等，在它們的基於J2EE的開發工具和應用伺服器中正在提供對Web Services的支援。當在這個技術領域中有多個競爭產品時，就意味著沒有單個公司的壟斷了。在過去的幾年中，J2EE已經被證明是一個穩定的、可擴充套件的、成熟的平臺。新增的、對Web Services的支援是這個平臺的又一個特徵
篇二：技術路線
技術路線
系統的建設將採取如下總體技術思路，兼併考慮平臺的整體性與可擴充性。
1. 打造地理資訊服務平臺
本系統採用主流GIS平臺（如：ESRI產品系列）、大型關係資料庫技術（如：Oracle）、主流軟體開發技術和現代網路通訊技術，充分考慮與其他資訊系統的開放互聯、多源資料介面、資料之間的關聯以及網路環境的開放性的基礎上，形成以完備的地理資訊資料庫為基礎，以開放的專題地理資訊服務平臺為依託，整合城市政府部門相關應用，建成資訊化建設的重要空間基礎地理資訊服務平臺。
2. 統一的基礎平臺和應用平臺
本系統充分考慮到個國土各個部門的業務需要，充分保證資料的共享和功能互操作。同時，平臺還要具備良好的可維護性和擴充套件性。因此，本系統採用統一的基礎平臺。包括作業系統平臺、資料庫平臺、地理資訊系統平臺和應用平臺。採用統一平臺，可避免不必要的系統間資料的轉換、功能的介面、以及系統升級擴充套件時大量的維護工作量，保證系統的一致性和穩定性。
3. 面向物件的軟體設計思想
在軟體開發技術中，面向物件的軟體開發技術成為當今主流。本資訊平臺的建設與開發將採用面向物件的軟體工程方法。
4. 基於關係資料庫的空間與非空間資料一體化管理
基於關係資料庫統一管理空間資料與非空間資料可以有效地實現空間與非空間資料關聯和整合。而且由於空間資料與非空間資料都以資料表或檢視的形式存貯，可以方便的採用資料庫逆向工程的方法自動提取元資料，因此，可以方便地實現基於元資料資訊資源管理。
5. 基於元資料統一管理資訊平臺
資訊平臺的元資料除管理業務公用基礎資料外，還要管理各個部門子系統可以共享資料的元資料，為實現資料的整合提供服務。
6. 元資料驅動的平臺架構
為了提高系統的可擴充套件性，系統將採用元資料驅動平臺架構加以實現，根據資訊資源管理統一平臺之資料平臺（包括基礎地理資訊系統、基本單位資訊系統）的特點，在GIS基礎軟體與實際應用系統之間增
加一層統一的、元資料驅動的應用平臺，將資料平臺各組成系統（基礎地理資訊系統、基本單位資訊系統）的應用模型（如圖層顯示控制、資料關聯、資料域）和應用元件的共性進行抽象透過UML模型和元資料加以描述，開發元資料驅動的應用元件（應用元件首先透過訪問元資料來控制對具體資料庫的訪問），基於元資料驅動元件搭建應用平臺。
當系統的資料擴充套件時，透過修改平臺的元資料，實現應用元件對新擴充套件資料的訪問和處理，對於功能的擴充套件，透過定製元資料驅動的功能擴充套件外掛的形式實現，使基於平臺定製的系統具有較強的可擴充套件性。
7. 面向服務的軟體架構（SOA）的應用
根據平臺公用性和基礎性的特點，系統軟體架構將盡可能採用面向服務的軟體架構SOA
（Service-Oriented Architecture）。系統設計與開發過程中儘可能將系統提供對外服務的應用程式功能封裝和釋出為Web服務（Web Service），透過服務註冊和服務目錄，向服務消費者（各種元件或部門的應用系統）提供Web服務，使系統的功能可以採用松耦合的方式實現整合，並使平臺提供功能服務具有可擴充套件性。
篇三：技術路線
1、 技術路線是指申請者對要達到研究目標準備採取的技術手段、具體步驟及解
決關鍵性問題的方法等在內的研究途徑.合理的技術路線可保證順利的實現既定目標.技術路線的合理性並不是技術路線的複雜性；
例：
三、研究方案及技術路線
1．總體思路
為了有效開展區域荒漠化過程的聯網研究，選擇策勒、額濟納、沙坡頭和奈曼四個野外站（其中3個為國家生態開放站），分別以策勒河下游、甘肅黑河下游、石羊河流域、內蒙古西遼河流域為物件，在每個站設立相同的研究內容和觀測專案，按照統一的方法進行樣地選擇和佈設儀器裝置，並以中國生態系統研究網路制定的水、土、氣、生觀測規範為主要方法進行野外調查和觀測，從而取得具有可比性的觀測資料；同時，充分利用各野外臺站水、土、氣、生長期積累的觀測資料和資料，透過認真整理和系統分析，從中總結和找出荒漠化的水、土、氣、生時序變化過程和規律；另外，採取時空轉換的方法，即在每個站點周圍選擇具有一定荒漠化梯度的地塊作為系列研究樣地，在樣地內同步進行水、土、氣、生的觀測和調查，透過時空轉換方法進行荒漠化過程的研究；為了彌補梯度取樣觀測存在的不足，還要採取點面結合的方法，在面上開展荒漠化典型地段的調查和取樣；在取得大量觀測和研究資料的基礎上，利用相關分析、多元迴歸分析、主分量分析、以及多因子引數化建模的方法，沿著水、土、氣、生過程-水、土、氣、生相互作用機制-水、土、氣、生過程空間分異規律這樣一個遞程序序開展相關研究。
2．技術路線
本課題採取的技術路線見下圖：
3．研究方法
本課題野外樣地選擇、儀器設定、調查觀測、室內分析等研究方法均參照"中國生態系統研究網路"組織編寫的以下觀測規範執行。
陸地生態系統水文觀測規範，2007，北京，中國環境科學出版社；
陸地生態系統土壤觀測規範，2007，北京，中國環境科學出版社；
陸地生態系統氣候觀測規範，2007，北京，中國環境科學出版社；
陸地生態系統生物觀測規範，2007，北京，中國環境科學出版社。
另外，課題還將根據實際需要，編制一些進行聯網研究的方法和標準
技術路線是要寫你怎麼去完成你的研究內容，使用什麼方法等。技術路線是“怎麼做”，研究內容是“做什麼”，兩者不一樣。技術路線不一定非要用圖來表示，純文字也可以，只要能讓人看明白。 實施方案和技術路線。
畢業論文的技術路線就是研究方法。根據專業、題目而定。例如寫：理論結合實際法、問卷調查分析法等。有不清楚的，可用百度輸入“溫州文海寫作事務所”看一下他們怎麼說的。不過這個世態炎涼，什麼都要錢。
一直想寫一篇這樣的總結性文章，但不是沒有時間就是沒有勇氣寫下去，因為怕別人丟臭雞蛋。這兩天有時間，終於鼓起勇氣，將這篇文章寫來下！也希望對一些正在尋找更好發展的朋友能有點幫助，也希望對於一些技術跟管理方面的牛人，能給予一些建議。 作為一名專案經理、系統架構師或技術骨幹，其水平如何，關係到公司的專案管理、軟體質量管理等方面的問題。專案經理或技術骨幹應該要起帶頭作用，使整個團隊的開發及管理能達到一種更高的水
平。那作為一名專案經理或公司技術骨幹應該學會那些工具及知識點呢？涉及到這一塊的工具及技術點非常多，如何去選擇，是擺在專案經理、系統架構師跟技術骨幹面前的問題。根據公司及團隊的情況，選擇合適的工具或技術框架，這一點非常重要。在專案的不同階段，需要有不同的工具來支援。按照軟體系統的生命週期的六個階段，一般分為需求分析階段、系統設計階段、系統開發階段、軟體測試階段、系統釋出階段、系統維護階段，這幾個階段都需要有不同工具的支援。一、需求分析階段：第一、專案管理及需求管理工具 專案管理工具很多公司都在使用，為什麼要使用這些工具？假如沒有使用這些工具，而 ...
一直想寫一篇這樣的總結性文章，但不是沒有時間就是沒有勇氣寫下去，因為怕別人丟臭雞蛋。這兩天有時間，終於鼓起勇氣，將這篇文章寫來下！也希望對一些正在尋找更好發展的朋友能有點幫助，也希望對於一些技術跟管理方面的牛人，能給予一些建議。
作為一名專案經理、系統架構師或技術骨幹，其水平如何，關係到公司的專案管理、軟體質量管理等方面的問題。專案經理或技術骨幹應該要起帶頭作用，使整個團隊的開發及管理能達到一種更高的水平。
那作為一名專案經理或公司技術骨幹應該學會那些工具及知識點呢？涉及到這一塊的工具及技術點非常多，如何去選擇，是擺在專案經理、系統架構師跟技術骨幹面前的問題。根據公司及團隊的情況，選擇合適的工具或技術框架，這一點非常重要。在專案的不同階段，需要有不同的工具來支援。
按照軟體系統的生命週期的六個階段，一般分為需求分析階段、系統設計階段、系統開發
階段、軟體測試階段、系統釋出階段、系統維護階段，這幾個階段都需要有不同工具的支援。
一、需求分析階段：
第一、專案管理及需求管理工具
專案管理工具很多公司都在使用，為什麼要使用這些工具？假如沒有使用這些工具，而是使用Excel或Word進行記錄，那當需求變更？需求實現情況的跟蹤？軟體是否能按時交付？將是一件非常煩鎖且容易出錯的事情。一個軟體專案、開發團隊能否獲得成功，管理非常關鍵。比較有名的商業化工具有：MicroSoft Project Server及Project 2003、IBM Rational RequisitePro、JIRA、PowerDesinger。比較有名的開源需求管理工具包括：OSRMT(Open Source Requirements Management Tools)、Xplanner、Openworkbench等等。
很多軟體公司都會使用SharePoint，在SharePoint平臺上，只要你想得到，基本上都可以透過配置方式來滿足你的業務需求。在SharePoint上，可以跟MicroSoft Project Server很好的結合，再配置Project 2003為客戶端，進行公司的專案管理。也許對Project操作習慣的問題，在Web介面進行專案管理的時候，總覺得很不方便。
IBM Rational RequisitePro（ ）可以算是最骨灰級的一個軟體了，假如你公司整個軟體生命週期管理都是採用IBM的解決方案，那使用RequisitePro是一個非常好的解決方案。需要這些軟體可以到IBM官方網站上去下載一個最新版本，或者在電驢上面下載一些“特別”版本。設計工具、管理工具的完美結合，這個正是IBM Rational RequisitePro的強項。RequisitePro跟Offce結合得也是非常完美。
JIRA（ ）原來只是一個缺陷跟蹤系統，你可以在JIRA上面建立新的ISSUE，當ISSUE分配給某個程式設計師時，系統會自動傳送一封郵件給該程式設計師，提示有新的BUG。JIRA也有提供一個Eclipse外掛，你可以在Eclipse上面，查到屬於自己的ISSUE，並快速解決。現在JIRA也可以用來做專案管理，在操作方面非常人性化，個人一直非常喜歡使用JIRA來進行專案管理、缺陷管理，再結合Eclipse，簡直就是完美！但作為商業的軟體，價格也非常貴，網際網路上也有很多Crack，大家有興趣也可以搜一下。
OSRMT（http://sourceforge.net/projects/osrmt ）是一個開源的需求管理工具，分為客戶端跟伺服器，也提供了一個安裝介面供使用者安裝，做開源的已經算是做得非常完美了。當前最新版本是V1.5，有興趣的朋友可以下載一個最新版本玩一下，操作還算是挺人性化的。
Xplanner
Xplanner（ ）是每個搞設計的人都會用的一個工具，我們一般使用Visio來畫系統結構圖、關鍵流程圖、系統部署結構圖等。MicroSoft Visio也提供了UML的功能，可以用它來畫用例圖、類圖、狀態圖，時序圖等，但一般這個功能很少使用。至少我基本上不用。
MindManager（ ）是一個非常好用的工具，我們用來描述我們的思維，很多人都不喜歡透過軟體來描述，而是透過一張紙，然後在上面進行塗鴉，接著跟客戶或團隊進行思維溝通。MindManager很好地解決了這個問題。MindManager跟Office結合得非常完美，可以生成Word、Excel、PDF等檔案。這個工具是我一直在使用的一個軟體，非常好用。最新版本為7，大家有興趣可以下載一個試用一下，也可以在網搜搜索一些“特別”版本。
二、系統設計階段：
第一、系統設計工具
主流的系統設計工具有大家非常熟悉的Rose2003，不過，現在已經不叫Rose了，現在IBM最新的設計工具是RSA（Ration Software Architect），Borland Together，SyBase PowerDesinger，MicroSoft Visio，對於開源的系統設計工具也有很多，比如ArgoUML、DBDesigner等等。
RSA（ ）：IBM最新的設計工具，它是一個基於Eclipse平臺的一個工具，對於你使用RSA，那也許你會將你的整個團隊的工具都採用IBM的整套解決方案，使用RequisitePro來進行需求管理、使用RSA來進行建模、使用ClearCase來進行配置管理、使用ClearQuest來進行缺陷跟蹤、使用RFT(Rational Functional Tester)來進行測試……RSA有一個最大的優點，那就是跟Word結合得非常好。這一點可以肯定。
Together（ ）：Borland公司的NB的設計工具，Together 2006版本也是一個基於Eclipse平臺的軟體，功能也是非常強大，其所見所得的功能，是我非常喜歡它的一個原因。還有一個原因就是基於Eclipse平臺，這個可以跟我的開發工具很完美地整合在一起。不過，整合要注意一個問題，那就是Eclipse相容性問題，這一點是非常煩人的。PowerDesigner（ ）： PowerDesigner是“一站式”建模與設計解決方案，物理資料模型的資料庫平臺無關性，所見即所得，反向工程，報表生成等等功能，使得它成為資料庫設計人員心目中最好的產品，它的易用性深深地吸引了我！特別它的
Repository模型庫的功能，更讓我們實現了模型設計的版本控制。最新的PowerDesigner，使得我覺得它是一件藝術品。做設計的人員一般會使用PowerDesigner來進行資料庫物理模型設計，它是我心目中的首選工具。之前曾經對比過RSA、Together、ERWin的資料庫模型設定工具，最終我還是更加喜歡使用PowerDesigner，也許，我的操作習慣已經被
PowerDesigner腐蝕。
第二、開發的技術框架
技術框架的選擇是非常關鍵，一個好的技術框架，可以讓我們的開發更加快速、團隊的分工更加合理、系統能夠支援多種資料庫平臺、我們的維護更加方便。
Web前端MVC框架是Struts 2。Struts 2可以說是Struts穿上了WebWork的外衣，其核心大部分都是採用了WebWork的技術，並且基於AOP的設計思想，讓我們在軟體設計上的能夠更加多地體現“高內聚，低耦合”的設計思想。
J2EE框架是Spring，作為一個開源的J2EE框架，雖然它沒有太多的新技術點，但它的整
合性，拿得我們的開發更加簡單，IOC、AOP、事務處理、開源框架的整合支援等等，使得作為一個J2EE框架的首選。
持久層框架是Hibernate，作為一個開源的專案，我想，沒有一個開源專案的社群能夠你Hibernate一樣，豐富的文件，活躍的社群，基於Hibernate的開發團隊的龐大，使得它作為持久層框架的首先。基於 Hibernate，我們可以開發出資料庫平臺無關性的產品。但是，Hibernate也有自身的問題，假如使用不當，也許會有所失控，一旦失控，它所帶來的，就是效能問題。對於最新的Hibernate3，儲存過程的支援，外部SQL的定製，很好地解決了這個問題。但在關聯關係上，使用還是要小心為好。
頁面框架，可以多考慮使用DIV技術、JSTL標籤庫、Struts 2標籤庫、DWR、AJAX、XML+XSLT等技術來讓我們頁面更好維護，使用OSCache快取技術來提高我們頁面的訪問速度。
第三、開發規範的定製
檔案命名規範、資料庫設計規範、編碼規範、團隊協作規定等等一些規範性的東西，需要在系統開發前就規定好，並且做相應的培訓。QA也要做好監督的作用，定期做評審工作，對已發生的問題及可能出現的問題，及早發現，及早處理。
第四、開發工具的選擇
團隊一定要選擇同樣的開發工具，開發工具相同，軟體版本相同。為什麼要這樣子做，其實假如你作為一個Team Leader，你會在管理你的團隊的時候發現很多問題，而解決這個問題，那在專案編碼前，就把什麼東西都規定好，以免其中發生問題，影響整個團隊的開發速度。開發工具的選擇也是非常重要的，目前企業用得比較多的開發工具有：Eclipse、Jbuilder、NetBeans、IDEA。
Jbuilder：最新的Jbuilder版本是2007，2007版基本上可以算是重新開發的版本，因為它是基於Eclipse之上的。我算是Borland公司最為忠實的Fans啦，從Jbuilder6，到
Jbuilder7，再到Jbuilder8，再到Jbuilder9、Jbuilder X，Jbuilder 2005，Jbuilder 2006，我經常跟我學生說，對於Jbuilder，相信沒有人比我更熟悉他了，做Java開發接近6年時間，超過4年的時間，每天都都在使用的工具，Jbuilder見證了我的長成。使用過Jbuilder的人很多人知道一點，就是Jbuilder的盜版問題，安裝完Jbuilder之後，假如你一個不小心，沒有安裝防火牆，那Jbuilder會不時透過8888埠向Borland總部發送一些你的計算機資訊，這個是一種非常可怕的“木馬”，什麼是“木馬”？這個就是！這種情況自從Jbuilder X以後就一直有。假如你不怕Borland公司的人跟工商局過來查你公司的軟體的話，那選擇Jbuilder是一個不錯的選擇。作為Java IDE開發平臺的老大，Jbuilder在企業應用開發是非常有優勢的，特別是開發EJB跟WebService，偶只能用一個句來形容，那就是牛。Jbuilder 2007，王者歸來，相信對於很多Borland的Fans，還是非常喜歡並樂意去嘗試的，不過，價格還是會讓很多公司都受不了、速度會讓很多程式設計師也受不了。我的Jbuilder的緣分到2006就基本上已經結束了。現在我的開發環境基本上都是Eclipse。
Eclipse：IBM捐出來的好東西，發展挺快的，現在已經到了Eclipse3.3，非常好用的一個工具。但Eclipse只是一個基礎平臺，假如你需要其他的功能，那你需要下載相關的外掛進行擴充套件，下載的外掛要注意一下跟Eclipse平臺的相容性問題。Eclipse+MyEclipse
（ ）是個是很多WEB開發人員都是在採用的一個整合工具，但MyEclipse要錢，如果公司願意為此支付29.9美元的話，那它是一個非常好的選擇；比MyEclipse更上一個檔次的還有Exadel（/web/portal/home ），不過，價格貴得離譜，因為它本身就是一家諮詢服務公司做出來，主要還是靠諮詢服務，培訓掙錢，並且，執行時的不穩定，也讓我放棄了選擇這個外掛作為我的開發工具，雖然這個工具真的是很強大。Eclipse+WTP（http://www.eclipse.org ）也是一個非常好的免費的開發工具
軟體專案技術路線
篇一：大型軟體系統技術路線分析
大型軟體系統技術路線分析
縱觀全球大型軟體系統軟體系統技術發展路線，歷經了二十多年的時間，逐步從vb、.NET向J2EE java全面遷移，迄今為止，所有的集團客戶和高階政府機關在大型軟體系統技術的選擇上，幾乎清一色的選擇JAVA品臺，而且面向集團化的大型軟體系統定位的企業，如九思軟體、東軟集團，也統統在此路線上完成系統的架構和功能設計。
在國外，JAVA技術已成為解決大型應用的事實標準，符合J2EE規範的應用伺服器則是構建面向物件的多層企業應用的中間核心平臺。因其具有易移植性，廣開放性、強安全性和支援快速開發等特性，成為面向物件開發組織應用的首選平臺。參照文件如下：
基於J2EE應用伺服器支援EJB元件開發技術，包括訊息佇列、負載均衡機制和交易管理等。支援中大型網站和中大型組織應用等需要大規模跨平臺、網路計算的領域。 軟體構造有幾個不可逆轉的發展方向:XML資料結構、面向物件的構件技術、網路化應用。其中Java 因為與平臺無關、安全、穩定、易開發、好維護、很強的網路使用性等, 而成為主流環境。 J2EE是企業級應用的標準。
J2EE平臺提供了一個基於元件的方法，來設計、開發、裝配及部署企業級應用程式，並提供了多層的分散式的應用模型、元件再用、一致化的安全模型以及靈活的事務控制機制。使之具有重用的能力，並集成了基於XML的資料交換 一個統一的安全模式及靈活的事務控制。
J2EE應用程式由元件構成。一個J2EE元件是自包含的，與其相關的語氣它元件通訊的類及檔案整合到J2EE應用程式的功能軟體單元。J2EE規範定義了下面一些元件：
1）、執行在客戶端的應用客戶程式及小程式。
2）、運行於伺服器網路的Servlet&Jsp元件。
3）、運行於服務端的企業邏輯元件。
J2EE元件用Java語言編寫，透過相同的方法編譯。J2EE元件與標準Java類的不同之處在於J2EE元件整合到了應用程式中，與J2EE規範相容，並部署到負責執行、管理的J2EE伺服器上。
基於J2EE企業級應用伺服器的結構
基於J2EE的企業級應用伺服器是基於Web Services 的新一代應用伺服器。在設計上突出了XML的應用，比如XML在本地化的儲存及各種處理；透過SOAP與 .NET及透過IIOP與CORBA的連線等。
Web Server
基於對本系統需求的深入分析，我們建議採用B/A/D應用模式，這樣，這樣，跨系統平臺、效能優異的Web Server是我們必須要認真考慮的。
Servlets 是網路化的元件, 被應用於網路伺服器的功能的擴充套件。 它從客戶主機(如: 瀏覽器)得到命令和要求， 並將內容反饋給主機， 實現從HTML介面傳遞到網路商務系列。 無論如何, Servlets是不必要連線到網路伺服器上的， 它們可被作為普通的命令要求元件， Servlets 更適合於實現簡單要求的需要， 並且不需要應用軟體伺服器的管理。
JSP與Servlets非常相似。 事實上, 它們的最大區別是JSP為非純Java程式碼, 更易於感知。 如果希望看到並感覺到配置是與其它配置分開的, 並且易於維護, 可以使用JSP，JSP擅長於此，它們易於被編寫及維護。
XML
當前，對XML的技術應用如火如荼，在我們的系統解決方案中，XML技術的應用也是不可缺的重要組成部分，這就要求我們選擇的技術架構必須提供對XML技術強大支援。
當前，J2EE架構在廠商市場和開發者社群中倍受推崇。作為一種工具，可擴充套件標記語言（XML）簡化了資料交換、程序間訊息交換這一類的事情，因而對開發者逐漸變得有吸引力，並開始流行起來。自然，在J2EE架構中訪問或整合XML解決方案的想法也很誘人。因為這將是強大系統架構同高度靈活的資料管理方案的結合。 XML的應用似乎是無窮無盡的，但它們大致上可以分為三大類：
1.簡單資料的表示和交換（針對XML的簡單API（SAX）和文件物件模型（DOM）語法解析，不同的文件型別定義（DTDs）和概要（schemas））
2.面向訊息的計算（XML-RPC（遠端過程呼叫），SOAP協議，電子化業務XML（ebXML））
3.使用者介面相關、表示相關的上下文（可擴充套件樣式表語言（XSL），可擴充套件樣式表語言轉換（XSLT））
這幾類應用在J2EE架構中恰好有天然的對應：資料表示和交換功能是EJB元件模型中持久化服務（persistence services）的一部分，基於訊息的通訊由Java訊息服務（JMS）API來處理，而介面表示正是Java伺服器頁面（JSP）和Java Servlets的拿手好戲。
Web Service
我們將要建造的是一個縱向、橫向交錯聯結的、綜合的系統，裡面的各種軟體平臺共存，而又存在著互聯互通的需要，Web Service正是解決這一問題的有效解決方案。同樣的，J2EE框架對Web Service技術也提供了強大的支援。
J2EE框架透過一組API包(JAXM、JAXP、JAXR、JAX-RPC)對Web Services提供支援。J2EE的Web Services一般是透過EJB來實現，然而也可以把提供Web Services實現的Java應用獨立出來，這完全依賴於設計和構建應用程式的業務處理和資料邏輯層。有多家公司已經構建了基於J2EE的整合開發環境(IDE)和應用伺服器，他們中的多數已經開始在產品中支援Web Services的建立、部署和執行，對Web Services標準的支援和複雜的程度因產品而異。多個獨立的公司，包括IBM、BEA、Oracle、HP、Sun等，在它們的基於J2EE的開發工具和應用伺服器中正在提供對Web Services的支援。當在這個技術領域中有多個競爭產品時，就意味著沒有單個公司的壟斷了。在過去的幾年中，J2EE已經被證明是一個穩定的、可擴充套件的、成熟的平臺。新增的、對Web Services的支援是這個平臺的又一個特徵
篇二：技術路線
技術路線
系統的建設將採取如下總體技術思路，兼併考慮平臺的整體性與可擴充性。
1. 打造地理資訊服務平臺
本系統採用主流GIS平臺（如：ESRI產品系列）、大型關係資料庫技術（如：Oracle）、主流軟體開發技術和現代網路通訊技術，充分考慮與其他資訊系統的開放互聯、多源資料介面、資料之間的關聯以及網路環境的開放性的基礎上，形成以完備的地理資訊資料庫為基礎，以開放的專題地理資訊服務平臺為依託，整合城市政府部門相關應用，建成資訊化建設的重要空間基礎地理資訊服務平臺。
2. 統一的基礎平臺和應用平臺
本系統充分考慮到個國土各個部門的業務需要，充分保證資料的共享和功能互操作。同時，平臺還要具備良好的可維護性和擴充套件性。因此，本系統採用統一的基礎平臺。包括作業系統平臺、資料庫平臺、地理資訊系統平臺和應用平臺。採用統一平臺，可避免不必要的系統間資料的轉換、功能的介面、以及系統升級擴充套件時大量的維護工作量，保證系統的一致性和穩定性。
3. 面向物件的軟體設計思想
在軟體開發技術中，面向物件的軟體開發技術成為當今主流。本資訊平臺的建設與開發將採用面向物件的軟體工程方法。
4. 基於關係資料庫的空間與非空間資料一體化管理
基於關係資料庫統一管理空間資料與非空間資料可以有效地實現空間與非空間資料關聯和整合。而且由於空間資料與非空間資料都以資料表或檢視的形式存貯，可以方便的採用資料庫逆向工程的方法自動提取元資料，因此，可以方便地實現基於元資料資訊資源管理。
5. 基於元資料統一管理資訊平臺
資訊平臺的元資料除管理業務公用基礎資料外，還要管理各個部門子系統可以共享資料的元資料，為實現資料的整合提供服務。
6. 元資料驅動的平臺架構
為了提高系統的可擴充套件性，系統將採用元資料驅動平臺架構加以實現，根據資訊資源管理統一平臺之資料平臺（包括基礎地理資訊系統、基本單位資訊系統）的特點，在GIS基礎軟體與實際應用系統之間增
加一層統一的、元資料驅動的應用平臺，將資料平臺各組成系統（基礎地理資訊系統、基本單位資訊系統）的應用模型（如圖層顯示控制、資料關聯、資料域）和應用元件的共性進行抽象透過UML模型和元資料加以描述，開發元資料驅動的應用元件（應用元件首先透過訪問元資料來控制對具體資料庫的訪問），基於元資料驅動元件搭建應用平臺。
當系統的資料擴充套件時，透過修改平臺的元資料，實現應用元件對新擴充套件資料的訪問和處理，對於功能的擴充套件，透過定製元資料驅動的功能擴充套件外掛的形式實現，使基於平臺定製的系統具有較強的可擴充套件性。
7. 面向服務的軟體架構（SOA）的應用
根據平臺公用性和基礎性的特點，系統軟體架構將盡可能採用面向服務的軟體架構SOA
（Service-Oriented Architecture）。系統設計與開發過程中儘可能將系統提供對外服務的應用程式功能封裝和釋出為Web服務（Web Service），透過服務註冊和服務目錄，向服務消費者（各種元件或部門的應用系統）提供Web服務，使系統的功能可以採用松耦合的方式實現整合，並使平臺提供功能服務具有可擴充套件性。
篇三：技術路線
1、 技術路線是指申請者對要達到研究目標準備採取的技術手段、具體步驟及解
決關鍵性問題的方法等在內的研究途徑.合理的技術路線可保證順利的實現既定目標.技術路線的合理性並不是技術路線的複雜性；
例：
三、研究方案及技術路線
1．總體思路
為了有效開展區域荒漠化過程的聯網研究，選擇策勒、額濟納、沙坡頭和奈曼四個野外站（其中3個為國家生態開放站），分別以策勒河下游、甘肅黑河下游、石羊河流域、內蒙古西遼河流域為物件，在每個站設立相同的研究內容和觀測專案，按照統一的方法進行樣地選擇和佈設儀器裝置，並以中國生態系統研究網路制定的水、土、氣、生觀測規範為主要方法進行野外調查和觀測，從而取得具有可比性的觀測資料；同時，充分利用各野外臺站水、土、氣、生長期積累的觀測資料和資料，透過認真整理和系統分析，從中總結和找出荒漠化的水、土、氣、生時序變化過程和規律；另外，採取時空轉換的方法，即在每個站點周圍選擇具有一定荒漠化梯度的地塊作為系列研究樣地，在樣地內同步進行水、土、氣、生的觀測和調查，透過時空轉換方法進行荒漠化過程的研究；為了彌補梯度取樣觀測存在的不足，還要採取點面結合的方法，在面上開展荒漠化典型地段的調查和取樣；在取得大量觀測和研究資料的基礎上，利用相關分析、多元迴歸分析、主分量分析、以及多因子引數化建模的方法，沿著水、土、氣、生過程-水、土、氣、生相互作用機制-水、土、氣、生過程空間分異規律這樣一個遞程序序開展相關研究。
2．技術路線
本課題採取的技術路線見下圖：
3．研究方法
本課題野外樣地選擇、儀器設定、調查觀測、室內分析等研究方法均參照"中國生態系統研究網路"組織編寫的以下觀測規範執行。
陸地生態系統水文觀測規範，2007，北京，中國環境科學出版社；
陸地生態系統土壤觀測規範，2007，北京，中國環境科學出版社；
陸地生態系統氣候觀測規範，2007，北京，中國環境科學出版社；
陸地生態系統生物觀測規範，2007，北京，中國環境科學出版社。
另外，課題還將根據實際需要，編制一些進行聯網研究的方法和標準
技術路線是要寫你怎麼去完成你的研究內容，使用什麼方法等。技術路線是“怎麼做”，研究內容是“做什麼”，兩者不一樣。技術路線不一定非要用圖來表示，純文字也可以，只要能讓人看明白。 實施方案和技術路線。
畢業論文的技術路線就是研究方法。根據專業、題目而定。例如寫：理論結合實際法、問卷調查分析法等。有不清楚的，可用百度輸入“溫州文海寫作事務所”看一下他們怎麼說的。不過這個世態炎涼，什麼都要錢。
一直想寫一篇這樣的總結性文章，但不是沒有時間就是沒有勇氣寫下去，因為怕別人丟臭雞蛋。這兩天有時間，終於鼓起勇氣，將這篇文章寫來下！也希望對一些正在尋找更好發展的朋友能有點幫助，也希望對於一些技術跟管理方面的牛人，能給予一些建議。 作為一名專案經理、系統架構師或技術骨幹，其水平如何，關係到公司的專案管理、軟體質量管理等方面的問題。專案經理或技術骨幹應該要起帶頭作用，使整個團隊的開發及管理能達到一種更高的水
平。那作為一名專案經理或公司技術骨幹應該學會那些工具及知識點呢？涉及到這一塊的工具及技術點非常多，如何去選擇，是擺在專案經理、系統架構師跟技術骨幹面前的問題。根據公司及團隊的情況，選擇合適的工具或技術框架，這一點非常重要。在專案的不同階段，需要有不同的工具來支援。按照軟體系統的生命週期的六個階段，一般分為需求分析階段、系統設計階段、系統開發階段、軟體測試階段、系統釋出階段、系統維護階段，這幾個階段都需要有不同工具的支援。一、需求分析階段：第一、專案管理及需求管理工具 專案管理工具很多公司都在使用，為什麼要使用這些工具？假如沒有使用這些工具，而 ...
一直想寫一篇這樣的總結性文章，但不是沒有時間就是沒有勇氣寫下去，因為怕別人丟臭雞蛋。這兩天有時間，終於鼓起勇氣，將這篇文章寫來下！也希望對一些正在尋找更好發展的朋友能有點幫助，也希望對於一些技術跟管理方面的牛人，能給予一些建議。
作為一名專案經理、系統架構師或技術骨幹，其水平如何，關係到公司的專案管理、軟體質量管理等方面的問題。專案經理或技術骨幹應該要起帶頭作用，使整個團隊的開發及管理能達到一種更高的水平。
那作為一名專案經理或公司技術骨幹應該學會那些工具及知識點呢？涉及到這一塊的工具及技術點非常多，如何去選擇，是擺在專案經理、系統架構師跟技術骨幹面前的問題。根據公司及團隊的情況，選擇合適的工具或技術框架，這一點非常重要。在專案的不同階段，需要有不同的工具來支援。
按照軟體系統的生命週期的六個階段，一般分為需求分析階段、系統設計階段、系統開發
階段、軟體測試階段、系統釋出階段、系統維護階段，這幾個階段都需要有不同工具的支援。
一、需求分析階段：
第一、專案管理及需求管理工具
專案管理工具很多公司都在使用，為什麼要使用這些工具？假如沒有使用這些工具，而是使用Excel或Word進行記錄，那當需求變更？需求實現情況的跟蹤？軟體是否能按時交付？將是一件非常煩鎖且容易出錯的事情。一個軟體專案、開發團隊能否獲得成功，管理非常關鍵。比較有名的商業化工具有：MicroSoft Project Server及Project 2003、IBM Rational RequisitePro、JIRA、PowerDesinger。比較有名的開源需求管理工具包括：OSRMT(Open Source Requirements Management Tools)、Xplanner、Openworkbench等等。
很多軟體公司都會使用SharePoint，在SharePoint平臺上，只要你想得到，基本上都可以透過配置方式來滿足你的業務需求。在SharePoint上，可以跟MicroSoft Project Server很好的結合，再配置Project 2003為客戶端，進行公司的專案管理。也許對Project操作習慣的問題，在Web介面進行專案管理的時候，總覺得很不方便。
IBM Rational RequisitePro（ ）可以算是最骨灰級的一個軟體了，假如你公司整個軟體生命週期管理都是採用IBM的解決方案，那使用RequisitePro是一個非常好的解決方案。需要這些軟體可以到IBM官方網站上去下載一個最新版本，或者在電驢上面下載一些“特別”版本。設計工具、管理工具的完美結合，這個正是IBM Rational RequisitePro的強項。RequisitePro跟Offce結合得也是非常完美。
JIRA（ ）原來只是一個缺陷跟蹤系統，你可以在JIRA上面建立新的ISSUE，當ISSUE分配給某個程式設計師時，系統會自動傳送一封郵件給該程式設計師，提示有新的BUG。JIRA也有提供一個Eclipse外掛，你可以在Eclipse上面，查到屬於自己的ISSUE，並快速解決。現在JIRA也可以用來做專案管理，在操作方面非常人性化，個人一直非常喜歡使用JIRA來進行專案管理、缺陷管理，再結合Eclipse，簡直就是完美！但作為商業的軟體，價格也非常貴，網際網路上也有很多Crack，大家有興趣也可以搜一下。
OSRMT（http://sourceforge.net/projects/osrmt ）是一個開源的需求管理工具，分為客戶端跟伺服器，也提供了一個安裝介面供使用者安裝，做開源的已經算是做得非常完美了。當前最新版本是V1.5，有興趣的朋友可以下載一個最新版本玩一下，操作還算是挺人性化的。
Xplanner
Xplanner（ ）是每個搞設計的人都會用的一個工具，我們一般使用Visio來畫系統結構圖、關鍵流程圖、系統部署結構圖等。MicroSoft Visio也提供了UML的功能，可以用它來畫用例圖、類圖、狀態圖，時序圖等，但一般這個功能很少使用。至少我基本上不用。
MindManager（ ）是一個非常好用的工具，我們用來描述我們的思維，很多人都不喜歡透過軟體來描述，而是透過一張紙，然後在上面進行塗鴉，接著跟客戶或團隊進行思維溝通。MindManager很好地解決了這個問題。MindManager跟Office結合得非常完美，可以生成Word、Excel、PDF等檔案。這個工具是我一直在使用的一個軟體，非常好用。最新版本為7，大家有興趣可以下載一個試用一下，也可以在網搜搜索一些“特別”版本。
二、系統設計階段：
第一、系統設計工具
主流的系統設計工具有大家非常熟悉的Rose2003，不過，現在已經不叫Rose了，現在IBM最新的設計工具是RSA（Ration Software Architect），Borland Together，SyBase PowerDesinger，MicroSoft Visio，對於開源的系統設計工具也有很多，比如ArgoUML、DBDesigner等等。
RSA（ ）：IBM最新的設計工具，它是一個基於Eclipse平臺的一個工具，對於你使用RSA，那也許你會將你的整個團隊的工具都採用IBM的整套解決方案，使用RequisitePro來進行需求管理、使用RSA來進行建模、使用ClearCase來進行配置管理、使用ClearQuest來進行缺陷跟蹤、使用RFT(Rational Functional Tester)來進行測試……RSA有一個最大的優點，那就是跟Word結合得非常好。這一點可以肯定。
Together（ ）：Borland公司的NB的設計工具，Together 2006版本也是一個基於Eclipse平臺的軟體，功能也是非常強大，其所見所得的功能，是我非常喜歡它的一個原因。還有一個原因就是基於Eclipse平臺，這個可以跟我的開發工具很完美地整合在一起。不過，整合要注意一個問題，那就是Eclipse相容性問題，這一點是非常煩人的。PowerDesigner（ ）： PowerDesigner是“一站式”建模與設計解決方案，物理資料模型的資料庫平臺無關性，所見即所得，反向工程，報表生成等等功能，使得它成為資料庫設計人員心目中最好的產品，它的易用性深深地吸引了我！特別它的
Repository模型庫的功能，更讓我們實現了模型設計的版本控制。最新的PowerDesigner，使得我覺得它是一件藝術品。做設計的人員一般會使用PowerDesigner來進行資料庫物理模型設計，它是我心目中的首選工具。之前曾經對比過RSA、Together、ERWin的資料庫模型設定工具，最終我還是更加喜歡使用PowerDesigner，也許，我的操作習慣已經被
PowerDesigner腐蝕。
第二、開發的技術框架
技術框架的選擇是非常關鍵，一個好的技術框架，可以讓我們的開發更加快速、團隊的分工更加合理、系統能夠支援多種資料庫平臺、我們的維護更加方便。
Web前端MVC框架是Struts 2。Struts 2可以說是Struts穿上了WebWork的外衣，其核心大部分都是採用了WebWork的技術，並且基於AOP的設計思想，讓我們在軟體設計上的能夠更加多地體現“高內聚，低耦合”的設計思想。
J2EE框架是Spring，作為一個開源的J2EE框架，雖然它沒有太多的新技術點，但它的整
合性，拿得我們的開發更加簡單，IOC、AOP、事務處理、開源框架的整合支援等等，使得作為一個J2EE框架的首選。
持久層框架是Hibernate，作為一個開源的專案，我想，沒有一個開源專案的社群能夠你Hibernate一樣，豐富的文件，活躍的社群，基於Hibernate的開發團隊的龐大，使得它作為持久層框架的首先。基於 Hibernate，我們可以開發出資料庫平臺無關性的產品。但是，Hibernate也有自身的問題，假如使用不當，也許會有所失控，一旦失控，它所帶來的，就是效能問題。對於最新的Hibernate3，儲存過程的支援，外部SQL的定製，很好地解決了這個問題。但在關聯關係上，使用還是要小心為好。
頁面框架，可以多考慮使用DIV技術、JSTL標籤庫、Struts 2標籤庫、DWR、AJAX、XML+XSLT等技術來讓我們頁面更好維護，使用OSCache快取技術來提高我們頁面的訪問速度。
第三、開發規範的定製
檔案命名規範、資料庫設計規範、編碼規範、團隊協作規定等等一些規範性的東西，需要在系統開發前就規定好，並且做相應的培訓。QA也要做好監督的作用，定期做評審工作，對已發生的問題及可能出現的問題，及早發現，及早處理。
第四、開發工具的選擇
團隊一定要選擇同樣的開發工具，開發工具相同，軟體版本相同。為什麼要這樣子做，其實假如你作為一個Team Leader，你會在管理你的團隊的時候發現很多問題，而解決這個問題，那在專案編碼前，就把什麼東西都規定好，以免其中發生問題，影響整個團隊的開發速度。開發工具的選擇也是非常重要的，目前企業用得比較多的開發工具有：Eclipse、Jbuilder、NetBeans、IDEA。
Jbuilder：最新的Jbuilder版本是2007，2007版基本上可以算是重新開發的版本，因為它是基於Eclipse之上的。我算是Borland公司最為忠實的Fans啦，從Jbuilder6，到
Jbuilder7，再到Jbuilder8，再到Jbuilder9、Jbuilder X，Jbuilder 2005，Jbuilder 2006，我經常跟我學生說，對於Jbuilder，相信沒有人比我更熟悉他了，做Java開發接近6年時間，超過4年的時間，每天都都在使用的工具，Jbuilder見證了我的長成。使用過Jbuilder的人很多人知道一點，就是Jbuilder的盜版問題，安裝完Jbuilder之後，假如你一個不小心，沒有安裝防火牆，那Jbuilder會不時透過8888埠向Borland總部發送一些你的計算機資訊，這個是一種非常可怕的“木馬”，什麼是“木馬”？這個就是！這種情況自從Jbuilder X以後就一直有。假如你不怕Borland公司的人跟工商局過來查你公司的軟體的話，那選擇Jbuilder是一個不錯的選擇。作為Java IDE開發平臺的老大，Jbuilder在企業應用開發是非常有優勢的，特別是開發EJB跟WebService，偶只能用一個句來形容，那就是牛。Jbuilder 2007，王者歸來，相信對於很多Borland的Fans，還是非常喜歡並樂意去嘗試的，不過，價格還是會讓很多公司都受不了、速度會讓很多程式設計師也受不了。我的Jbuilder的緣分到2006就基本上已經結束了。現在我的開發環境基本上都是Eclipse。
Eclipse：IBM捐出來的好東西，發展挺快的，現在已經到了Eclipse3.3，非常好用的一個工具。但Eclipse只是一個基礎平臺，假如你需要其他的功能，那你需要下載相關的外掛進行擴充套件，下載的外掛要注意一下跟Eclipse平臺的相容性問題。Eclipse+MyEclipse
（ ）是個是很多WEB開發人員都是在採用的一個整合工具，但MyEclipse要錢，如果公司願意為此支付29.9美元的話，那它是一個非常好的選擇；比MyEclipse更上一個檔次的還有Exadel（/web/portal/home ），不過，價格貴得離譜，因為它本身就是一家諮詢服務公司做出來，主要還是靠諮詢服務，培訓掙錢，並且，執行時的不穩定，也讓我放棄了選擇這個外掛作為我的開發工具，雖然這個工具真的是很強大。Eclipse+WTP（http://www.eclipse.org ）也是一個非常好的免費的開發工具