軟件項目技術路線

（若有幫助請點贊）

篇一：大型軟件系統技術路線分析

大型軟件系統技術路線分析

縱觀全球大型軟件系統軟件系統技術發展路線，歷經了二十多年的時間，逐步從vb、.NET向J2EEjava全面遷移，迄今為止，所有的集團客戶和高端政府機關在大型軟件系統技術的選擇上，幾乎清一色的選擇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的企業級應用服務器是基于WebServices的新一代應用服務器。在設計上突出了XML的應用，比如XML在本地化的存儲及各種處理；通過SOAP與.NET及通過IIOP與CORBA的連接等。

WebServer

基于對本系統需求的深入分析，我們建議采用B/A/D應用模式，這樣，這樣，跨系統平臺、性能優異的WebServer是我們必須要認真考慮的。

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組件模型中持久化服務（persistenceservices）的一部分，基于消息的通訊由Java消息服務（JMS）API來處理，而界面表示正是Java服務器頁面（JSP）和JavaServlets的拿手好戲。

WebService

我們將要建造的是一個縱向、橫向交錯聯結的、綜合的系統，里面的各種軟件平臺共存，而又存在著互聯互通的需要，WebService正是解決這一問題的有效解決方案。同樣的，J2EE框架對WebService技術也提供了強大的支持。

J2EE框架通過一組API包(JAXM、JAXP、JAXR、JAX-RPC)對WebServices提供支持。J2EE的WebServices一般是通過EJB來實現，然而也可以把提供WebServices實現的Java應用獨立出來，這完全依賴于設計和構建應用程序的業務處理和數據邏輯層。有多家公司已經構建了基于J2EE的集成開發環境(IDE)和應用服務器，他們中的多數已經開始在產品中支持WebServices的創建、部署和運行，對WebServices標準的支持和復雜的程度因產品而異。多個獨立的公司，包括IBM、BEA、Oracle、HP、Sun等，在它們的基于J2EE的開發工具和應用服務器中正在提供對WebServices的支持。當在這個技術領域中有多個競爭產品時，就意味著沒有單個公司的壟斷了。在過去的幾年中，J2EE已經被證明是一個穩定的、可擴展的、成熟的平臺。新增的、對WebServices的支持是這個平臺的又一個特征

篇二：技術路線

技術路線

系統的建設將采取如下總體技術思路，兼并考慮平臺的整體性與可擴充性。

1.打造地理信息服務平臺

本系統采用主流GIS平臺（如：ESRI產品系列）、大型關系數據庫技術（如：Oracle）、主流軟件開發技術和現代網絡通訊技術，充分考慮與其他信息系統的開放互聯、多源數據接口、數據之間的關聯以及網絡環境的開放性的基礎上，形成以完備的地理信息數據庫為基礎，以開放的專題地理信息服務平臺為依托，集成城市政府部門相關應用，建成信息化建設的重要空間基礎地理信息服務平臺。

2.統一的基礎平臺和應用平臺

本系統充分考慮到個國土各個部門的業務需要，充分保證數據的共享和功能互操作。同時，平臺還要具備良好的可維護性和擴展性。因此，本系統采用統一的基礎平臺。包括操作系統平臺、數據庫平臺、地理信息系統平臺和應用平臺。采用統一平臺，可避免不必要的系統間數據的轉換、功能的接口、以及系統升級擴展時大量的維護工作量，保證系統的一致性和穩定性。

3.面向對象的軟件設計思想

在軟件開發技術中，面向對象的軟件開發技術成為當今主流。本信息平臺的建設與開發將采用面向對象的軟件工程方法。

4.基于關系數據庫的空間與非空間數據一體化管理

基于關系數據庫統一管理空間數據與非空間數據可以有效地實現空間與非空間數據關聯和集成。而且由于空間數據與非空間數據都以數據表或視圖的形式存貯，可以方便的采用數據庫逆向工程的方法自動提取元數據，因此，可以方便地實現基于元數據信息資源管理。

5.基于元數據統一管理信息平臺

信息平臺的元數據除管理業務公用基礎數據外，還要管理各個部門子系統可以共享數據的元數據，為實現數據的集成提供服務。

6.元數據驅動的平臺架構

為了提高系統的可擴展性，系統將采用元數據驅動平臺架構加以實現，根據信息資源管理統一平臺之數據平臺（包括基礎地理信息系統、基本單位信息系統）的特點，在GIS基礎軟件與實際應用系統之間增

加一層統一的、元數據驅動的應用平臺，將數據平臺各組成系統（基礎地理信息系統、基本單位信息系統）的應用模型（如圖層顯示控制、數據關聯、數據域）和應用組件的共性進行抽象通過UML模型和元數據加以描述，開發元數據驅動的應用組件（應用組件首先通過訪問元數據來控制對具體數據庫的訪問），基于元數據驅動組件搭建應用平臺。

當系統的數據擴展時，通過修改平臺的元數據，實現應用組件對新擴展數據的訪問和處理，對于功能的擴展，通過定制元數據驅動的功能擴展插件的形式實現，使基于平臺定制的系統具有較強的可擴展性。

7.面向服務的軟件架構（SOA）的應用

根據平臺公用性和基礎性的特點，系統軟件架構將盡可能采用面向服務的軟件架構SOA

（Service-OrientedArchitecture）。系統設計與開發過程中盡可能將系統提供對外服務的應用程序功能封裝和發布為Web服務（WebService），通過服務注冊和服務目錄，向服務消費者（各種組件或部門的應用系統）提供Web服務，使系統的功能可以采用松耦合的方式實現集成，并使平臺提供功能服務具有可擴展性。

篇三：技術路線

1、技術路線是指申請者對要達到研究目標準備采取的技術手段、具體步驟及解

決關鍵性問題的方法等在內的研究途徑.合理的技術路線可保證順利的實現既定目標.技術路線的合理性并不是技術路線的復雜性；

例：

三、研究方案及技術路線

1．總體思路

為了有效開展區域荒漠化過程的聯網研究，選擇策勒、額濟納、沙坡頭和奈曼四個野外站（其中3個為國家生態開放站），分別以策勒河下游、甘肅黑河下游、石羊河流域、內蒙古西遼河流域為對象，在每個站設立相同的研究內容和觀測項目，按照統一的方法進行樣地選擇和布設儀器設備，并以中國生態系統研究網絡制定的水、土、氣、生觀測規范為主要方法進行野外調查和觀測，從而取得具有可比性的觀測數據；同時，充分利用各野外臺站水、土、氣、生長期積累的觀測數據和資料，通過認真整理和系統分析，從中總結和找出荒漠化的水、土、氣、生時序變化過程和規律；另外，采取時空轉換的方法，即在每個站點周圍選擇具有一定荒漠化梯度的地塊作為系列研究樣地，在樣地內同步進行水、土、氣、生的觀測和調查，通過時空轉換方法進行荒漠化過程的研究；為了彌補梯度取樣觀測存在的不足，還要采取點面結合的方法，在面上開展荒漠化典型地段的調查和取樣；在取得大量觀測和研究數據的基礎上，利用相關分析、多元回歸分析、主分量分析、以及多因子參數化建模的方法，沿著水、土、氣、生過程-水、土、氣、生相互作用機制-水、土、氣、生過程空間分異規律這樣一個遞進程序開展相關研究。

2．技術路線

本課題采取的技術路線見下圖：

3．研究方法

本課題野外樣地選擇、儀器設置、調查觀測、室內分析等研究方法均參照"中國生態系統研究網絡"組織編寫的以下觀測規范執行。

陸地生態系統水文觀測規范，2007，北京，中國環境科學出版社；

陸地生態系統土壤觀測規范，2007，北京，中國環境科學出版社；

陸地生態系統氣候觀測規范，2007，北京，中國環境科學出版社；

陸地生態系統生物觀測規范，2007，北京，中國環境科學出版社。

另外，課題還將根據實際需要，編制一些進行聯網研究的方法和標準

技術路線是要寫你怎么去完成你的研究內容，使用什么方法等。技術路線是“怎么做”，研究內容是“做什么”，兩者不一樣。技術路線不一定非要用圖來表示，純文字也可以，只要能讓人看明白。實施方案和技術路線。

畢業論文的技術路線就是研究方法。根據專業、題目而定。例如寫：理論結合實際法、問卷調查分析法等。有不清楚的，可用百度輸入“溫州文海寫作事務所”看一下他們怎么說的。不過這個世態炎涼，什么都要錢。

一直想寫一篇這樣的總結性文章，但不是沒有時間就是沒有勇氣寫下去，因為怕別人丟臭雞蛋。這兩天有時間，終于鼓起勇氣，將這篇文章寫來下！也希望對一些正在尋找更好發展的朋友能有點幫助，也希望對于一些技術跟管理方面的牛人，能給予一些建議。作為一名項目經理、系統架構師或技術骨干，其水平如何，關系到公司的項目管理、軟件質量管理等方面的問題。項目經理或技術骨干應該要起帶頭作用，使整個團隊的開發及管理能達到一種更高的水

平。那作為一名項目經理或公司技術骨干應該學會那些工具及知識點呢？涉及到這一塊的工具及技術點非常多，如何去選擇，是擺在項目經理、系統架構師跟技術骨干面前的問題。根據公司及團隊的情況，選擇合適的工具或技術框架，這一點非常重要。在項目的不同階段，需要有不同的工具來支持。按照軟件系統的生命周期的六個階段，一般分為需求分析階段、系統設計階段、系統開發階段、軟件測試階段、系統發布階段、系統維護階段，這幾個階段都需要有不同工具的支持。一、需求分析階段：第一、項目管理及需求管理工具項目管理工具很多公司都在使用，為什么要使用這些工具？假如沒有使用這些工具，而...

一直想寫一篇這樣的總結性文章，但不是沒有時間就是沒有勇氣寫下去，因為怕別人丟臭雞蛋。這兩天有時間，終于鼓起勇氣，將這篇文章寫來下！也希望對一些正在尋找更好發展的朋友能有點幫助，也希望對于一些技術跟管理方面的牛人，能給予一些建議。

作為一名項目經理、系統架構師或技術骨干，其水平如何，關系到公司的項目管理、軟件質量管理等方面的問題。項目經理或技術骨干應該要起帶頭作用，使整個團隊的開發及管理能達到一種更高的水平。

那作為一名項目經理或公司技術骨干應該學會那些工具及知識點呢？涉及到這一塊的工具及技術點非常多，如何去選擇，是擺在項目經理、系統架構師跟技術骨干面前的問題。根據公司及團隊的情況，選擇合適的工具或技術框架，這一點非常重要。在項目的不同階段，需要有不同的工具來支持。

按照軟件系統的生命周期的六個階段，一般分為需求分析階段、系統設計階段、系統開發

階段、軟件測試階段、系統發布階段、系統維護階段，這幾個階段都需要有不同工具的支持。

一、需求分析階段：

第一、項目管理及需求管理工具

項目管理工具很多公司都在使用，為什么要使用這些工具？假如沒有使用這些工具，而是使用Excel或Word進行記錄，那當需求變更？需求實現情況的跟蹤？軟件是否能按時交付？將是一件非常煩鎖且容易出錯的事情。一個軟件項目、開發團隊能否獲得成功，管理非常關鍵。比較有名的商業化工具有：MicroSoftProjectServer及Project2003、IBMRationalRequisitePro、JIRA、PowerDesinger。比較有名的開源需求管理工具包括：OSRMT(OpenSourceRequirementsManagementTools)、Xplanner、Openworkbench等等。

很多軟件公司都會使用SharePoint，在SharePoint平臺上，只要你想得到，基本上都可以通過配置方式來滿足你的業務需求。在SharePoint上，可以跟MicroSoftProjectServer很好的結合，再配置Project2003為客戶端，進行公司的項目管理。也許對Project操作習慣的問題，在Web界面進行項目管理的時候，總覺得很不方便。

IBMRationalRequisitePro（）可以算是最骨灰級的一個軟件了，假如你公司整個軟件生命周期管理都是采用IBM的解決方案，那使用RequisitePro是一個非常好的解決方案。需要這些軟件可以到IBM官方網站上去下載一個最新版本，或者在電驢上面下載一些“特別”版本。設計工具、管理工具的完美結合，這個正是IBMRationalRequisitePro的強項。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來畫系統結構圖、關鍵流程圖、系統部署結構圖等。MicroSoftVisio也提供了UML的功能，可以用它來畫用例圖、類圖、狀態圖，時序圖等，但一般這個功能很少使用。至少我基本上不用。

MindManager（）是一個非常好用的工具，我們用來描述我們的思維，很多人都不喜歡通過軟件來描述，而是通過一張紙，然后在上面進行涂鴉，接著跟客戶或團隊進行思維溝通。MindManager很好地解決了這個問題。MindManager跟Office結合得非常完美，可以生成Word、Excel、PDF等文件。這個工具是我一直在使用的一個軟件，非常好用。最新版本為7，大家有興趣可以下載一個試用一下，也可以在網搜搜索一些“特別”版本。

二、系統設計階段：

第一、系統設計工具

主流的系統設計工具有大家非常熟悉的Rose2003，不過，現在已經不叫Rose了，現在IBM最新的設計工具是RSA（RationSoftwareArchitect），BorlandTogether，SyBasePowerDesinger，MicroSoftVisio，對于開源的系統設計工具也有很多，比如ArgoUML、DBDesigner等等。

RSA（）：IBM最新的設計工具，它是一個基于Eclipse平臺的一個工具，對于你使用RSA，那也許你會將你的整個團隊的工具都采用IBM的整套解決方案，使用RequisitePro來進行需求管理、使用RSA來進行建模、使用ClearCase來進行配置管理、使用ClearQuest來進行缺陷跟蹤、使用RFT(RationalFunctionalTester)來進行測試……RSA有一個最大的優點，那就是跟Word結合得非常好。這一點可以肯定。

Together（）：Borland公司的NB的設計工具，Together2006版本也是一個基于Eclipse平臺的軟件，功能也是非常強大，其所見所得的功能，是我非常喜歡它的一個原因。還有一個原因就是基于Eclipse平臺，這個可以跟我的開發工具很完美地整合在一起。不過，整合要注意一個問題，那就是Eclipse兼容性問題，這一點是非常煩人的。PowerDesigner（）：PowerDesigner是“一站式”建模與設計解決方案，物理數據模型的數據庫平臺無關性，所見即所得，反向工程，報表生成等等功能，使得它成為數據庫設計人員心目中最好的產品，它的易用性深深地吸引了我！特別它的

Repository模型庫的功能，更讓我們實現了模型設計的版本控制。最新的PowerDesigner，使得我覺得它是一件藝術品。做設計的人員一般會使用PowerDesigner來進行數據庫物理模型設計，它是我心目中的首選工具。之前曾經對比過RSA、Together、ERWin的數據庫模型設置工具，最終我還是更加喜歡使用PowerDesigner，也許，我的操作習慣已經被

PowerDesigner腐蝕。

第二、開發的技術框架

技術框架的選擇是非常關鍵，一個好的技術框架，可以讓我們的開發更加快速、團隊的分工更加合理、系統能夠支持多種數據庫平臺、我們的維護更加方便。

Web前端MVC框架是Struts2。Struts2可以說是Struts穿上了WebWork的外衣，其內核大部分都是采用了WebWork的技術，并且基于AOP的設計思想，讓我們在軟件設計上的能夠更加多地體現“高內聚，低耦合”的設計思想。

J2EE框架是Spring，作為一個開源的J2EE框架，雖然它沒有太多的新技術點，但它的整

合性，拿得我們的開發更加簡單，IOC、AOP、事務處理、開源框架的整合支持等等，使得作為一個J2EE框架的首選。

持久層框架是Hibernate，作為一個開源的項目，我想，沒有一個開源項目的社區能夠你Hibernate一樣，豐富的文檔，活躍的社區，基于Hibernate的開發團隊的龐大，使得它作為持久層框架的首先。基于Hibernate，我們可以開發出數據庫平臺無關性的產品。但是，Hibernate也有自身的問題，假如使用不當，也許會有所失控，一旦失控，它所帶來的，就是性能問題。對于最新的Hibernate3，存儲過程的支持，外部SQL的定制，很好地解決了這個問題。但在關聯關系上，使用還是要小心為好。

頁面框架，可以多考慮使用DIV技術、JSTL標簽庫、Struts2標簽庫、DWR、AJAX、XML+XSLT等技術來讓我們頁面更好維護，使用OSCache緩存技術來提高我們頁面的訪問速度。

第三、開發規范的定制

文件命名規范、數據庫設計規范、編碼規范、團隊協作規定等等一些規范性的東西，需要在系統開發前就規定好，并且做相應的培訓。QA也要做好監督的作用，定期做評審工作，對已發生的問題及可能出現的問題，及早發現，及早處理。

第四、開發工具的選擇

團隊一定要選擇同樣的開發工具，開發工具相同，軟件版本相同。為什么要這樣子做，其實假如你作為一個TeamLeader，你會在管理你的團隊的時候發現很多問題，而解決這個問題，那在項目編碼前，就把什么東西都規定好，以免其中發生問題，影響整個團隊的開發速度。開發工具的選擇也是非常重要的，目前企業用得比較多的開發工具有：Eclipse、Jbuilder、NetBeans、IDEA。

Jbuilder：最新的Jbuilder版本是2007，2007版基本上可以算是重新開發的版本，因為它是基于Eclipse之上的。我算是Borland公司最為忠實的Fans啦，從Jbuilder6，到

Jbuilder7，再到Jbuilder8，再到Jbuilder9、JbuilderX，Jbuilder2005，Jbuilder2006，我經常跟我學生說，對于Jbuilder，相信沒有人比我更熟悉他了，做Java開發接近6年時間，超過4年的時間，每天都都在使用的工具，Jbuilder見證了我的長成。使用過Jbuilder的人很多人知道一點，就是Jbuilder的盜版問題，安裝完Jbuilder之后，假如你一個不小心，沒有安裝防火墻，那Jbuilder會不時通過8888端口向Borland總部發送一些你的計算機信息，這個是一種非常可怕的“木馬”，什么是“木馬”？這個就是！這種情況自從JbuilderX以后就一直有。假如你不怕Borland公司的人跟工商局過來查你公司的軟件的話，那選擇Jbuilder是一個不錯的選擇。作為JavaIDE開發平臺的老大，Jbuilder在企業應用開發是非常有優勢的，特別是開發EJB跟WebService，偶只能用一個句來形容，那就是牛。Jbuilder2007，王者歸來，相信對于很多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）也是一個非常好的免費的開發工具