軟件設計畢業論文

導言：作為寫作愛好者，不可錯過為您精心挑選的1篇軟件設計畢業論文，它們將為您的寫作提供全新的視角，我們衷心期待您的閱讀，并希望這些內容能為您提供靈感和參考。

軟件設計畢業論文:面向服務架構的ERP軟件設計新思路

摘要：傳統構架下的ERP軟件，在實際應用中出現了許多問題。文章介紹了一種新的軟件架構方法――面向服務架構（SOA）的理念及其特點，并對面向服務架構的ERP和面向對象架構的ERP分別在體系結構和開發方法上作比較，最后選取SAP公司的NetWeaver和ESA產品設計理念作為案例，進一步闡述了SOA思想在ERP設計中的應用特點和優勢。

關鍵詞：面向服務架構（SOA）；面向對象架構（OOA）；軟件設計

0 引言

ERP由最初的財務軟件逐漸發展起來，內容越來越豐富，功能也越來越齊全[1]。到目前為止，ERP的產品模式最常見的有兩種：通用型ERP和專業型ERP。通用型ERP，顧名思義，是適用于多種行業的套裝軟件。通過對其進行二次開發、系統配置，達到滿足不同行業的管理信息化需求。它的拓展性好、通用性高，成為目前的主流。專業型ERP，也稱之為行業型軟件，是專門針對某一特定（或相近）行業設計和定制的，便于滿足目標行業的個性化管理需求。

但這兩種ERP產品都存在各自的缺陷，從而導致了應用實施過程中出現了很多問題，最終以失敗告終的案例也不在少數。如通用型ERP，它的優點也正是它缺點所在。通用代表了缺乏個性，流程固化，不能針對不同企業做出有效的變化，只能通過企業進行業務流程再造，來滿足ERP產品的需求，忽視了企業的個性化需求；專業型ERP的最大缺陷是它的開發成本高，使企業望而卻步，同時適用的企業并不多，所以這種專用型ERP，企業很少主動開發，往往是在目標企業提出某種需求的前提之下，進行定制開發，需要很高的成本。

傳統ERP產品存在的這些缺陷，大部分原因是其架構理念的落后，開發方法的局限。現在，面向服務架構（SOA，Service Oriented Architecture）這種新的架構理念被引入到ERP軟件的設計與開發中，為傳統ERP產品走出困境帶來了希望，為ERP領域的又一次革命性的飛躍奠定了基礎。

1 面向服務架構SOA

早在1996 年，Gartner Group就已經明確地提出了SOA的理念，但目前尚未有一個統一的、業界廣泛接受的定義[2]。IBM的高級軟件工程師李珉先生說過，不同行業的人可以從不同的視角來理解SOA，從程序員的角度，SOA是一種全新的開發技術，新的組件模型，比如說Web Service；從架構設計師的角度，SOA就是一種新的設計模式，方法學；從業務分析人員的角度，SOA就是基于標準的業務應用服務。

一般認為：SOA――面向服務架構是一個組件模型，它將應用程序的不同功能單元――服務，通過服務間定義良好的接口和契約聯系起來。接口采用中立的方式定義，獨立于具體實現服務的硬件平臺、操作系統和編程語言，使得構建在這樣系統中的服務可以使用統一和標準的方式進行通信。其中服務，是指僅基于兩個組件接口之間的契約，由一個組件提供其行為方法給另一個使用。

SOA中一般都包含三個角色：服務的提供者、服務的請求者、服務[3]。三個角色是根據對服務提出不同的需求和行使的不同功能來劃分的。它們的關系可以簡單理解為：服務的提供者將它提供服務的具體描述在服務，以方便服務的請求者查詢；服務的請求者通過對服務搜索，查找到需要的服務及其提供者的地址；最后是服務的提供者與服務的請求者進行直接的綁定，完成服務（見圖1）。 舉個最簡單的例子，我們若要在網上下載一首歌，先可以通過搜索引擎GOOGLE等，搜索可下載這首歌的網站，獲知這首歌的免費下載的地址，最后我們直接鏈接這個地址下載歌。在這個過程，網站即相當于一個服務，我們是服務的請求者，而最后那個下載地址背后的服務器為服務的提供者。

圖1SOA 三者關系圖

SOA主要特征是將應用程序功能包裝成服務，服務間彼此獨立，可單獨作為組件使用。它具備松散耦合，提供粗粒度的服務和標準化的接口等。SOA旨在提供一個通用的，可互操作的和有彈性的行業標準架構，可以在軟件基礎架構之上建立一系列可重復利用的服務，實現企業適應業務流程變化的需求。

2 基于SOA的ERP與傳統架構下的ERP的比較分析

2.1 ERP傳統體系結構和基于SOA的ERP體系結構的區別

傳統的ERP軟件在其體系結構上可以分為三層：表現層、業務邏輯層和數據庫[4]。在這種體系結構下，其客戶端訪問存在很多的問題。如表現層在訪問業務邏輯層的各個業務對象時，一個客戶端可能同時訪問多個業務對象，一個業務對象也可能同時被多個不同的客戶端訪問。因此它們之間關系雜亂、復雜，造成層與層之間的耦合性強；表現層與業務邏輯層相互依賴，訪問接口不是公開標準的，而是依賴于特定的接口函數，一旦其中的某一層發生改變，其接口函數也要作相應的改變，導致系統地擴展性和維護性差（見圖2）。

圖2傳統ERP體系結構

將SOA思想引入ERP軟件的設計開發之后，其傳統的三層體系結構，將會在概念上演變為四層結構，包括表現層、服務層、業務邏輯層和數據庫。其中，服務層是抽象層，是獨立的、由可重用的、基于標準的服務組成。每一個具體的服務包含了接口部分和實現部分，其接口部分定義了服務使用者和服務提供者進行程序訪問的契約；實現部分包含了服務作用和商業邏輯等信息（見圖3）。

由圖3與圖2比較可以清楚地看到兩者的區別，SOA架構的四層體系結構，客戶端并不像傳統的體系結構直接調用業務對象實現最終目的，而是通過調用一個獨立的服務，服務再調用相關的業務對象去實現最終目的。由于它調用服務的接口包含在服務層內，所以，各個層之間都是獨立的、松耦合的，沒有很強的依賴性。任何一層發生變化，只要接口不變，不會影響服務的實現，有利于系統地擴展和維護。

因此，設想以SOA思想實現的ERP軟件，具備很強的彈性，可以根據不用企業的不同需求進行調整，符合企業的個性化需求，具體會在后面的實例中說明。

圖3 SOA四層體系結構

2.2采用SOA和OOA進行ERP軟件設計開發的區別

ERP軟件發展至今，它的開發方法由最初的面向過程（POA）的開發方法，發展到面向對象（OOA），至現在提出的面向服務（SOA）的開發方法[5]。面向對象的開發方法是目前ERP軟件開發中的主流技術，但它本身存在很多的缺陷。它對編程語言有很強的依賴性，封裝粒度小，耦合度高，未形成標準的模型和概念，從而難以形成標準和開發規范，不能達到軟件重用的可移植性和互操作性，產生了大量的“對象孤島”。

相對于傳統的面向對象體系結構的緊耦合，SOA是一個粗粒度、松耦合的面向服務架構，其服務之間通過公開、精確定義的接口進行通訊，不涉及底層具體編程接口和通訊模型，服務與服務之間是相互獨立的，且服務可以被重復調用，也可以被任何潛在需求者調用。

以下是某公司針對訂購產品這一實務做出的一系列數據處理的例子，分別從面向對象架構與面相服務架構這兩種不同架構理念對軟件設計開發的不同要求做出的比較（見圖4）。

面向對象設計中，公司在生產和銷售產品的時候，是根據收到的采購訂單進行的。采購訂單有很多屬性，但它的訂單編號是唯一的。根據其訂單編號，編制公司的銷售訂單。根據其銷售訂單中產品清單編號主碼，關系到產品清單。最后根據其具體產品編號關系到產品目錄，一層一層的處理數據。以上過程，就是軟件面向對象架構的最基本思路，對象之間繼承關系的依賴性很強，層層相扣。因此，對象的分析與設計及編程實現，要求很高，也很復雜。

圖4面向對象架構與面向服務架構

現采用面向服務架構思想對軟件進行開發。可以把所有相關的主體分為三個層次，從基礎的對象層，到由不同對象組成的組件層，至最終的服務層。關于這項訂購實務，公司要處理的有四個基本對象，采購方信息處理，采購訂單，產品清單，與產品目錄；組件層包括采購方信息和單據兩個實體；而它們都包含在訂購產品這項服務中。那么公司在開發這項訂購產品服務的時候，可以把它分為若干部分，從對象這個最小粒度開始，再組合成不同的組件，到最終完成一項服務。這樣對開發人員技術的要求會低一點，且不同部門可同時進行軟件開發。

這里需要說明的是，SOA并不是OOA的完全替代，如開發人員對單個對象，或組件乃至整個服務采用面向對象的架構設計，但在整體上是面向服務的，主要原因是接口的設計。

2.3 SAP的NetWeaver平臺和ESA思想

目前，SOA的思想被越來越多的用于ERP產品的開發上，ERP產品的巨頭SAP也不例外。企業服務架構ESA就是SAP基于SOA的思想提出的新產品的模式。提到ESA就不得不提到它的另一個產品NetWeaver，因為企業服務架構是建立在這個技術平臺之上的。

NetWeaver是SAP于04年正式推出的一個產品，它是一個底層技術平臺，SAP的很多新產品的應用都是跑在這個平臺上，相當于一個中間件產品。它主要提供了以下四方面的功能，人員集成，信息集成，流程集成和應用平臺。它是由交換架構XI,主數據管理MDM，解決管理Solution Manager等組件構成。它是目前支持所有SAP應用的基礎產品，是企業應用軟件的開發平臺、同時又為企業搭建一個基于NetWeaver的面向服務的IT架構。

SAP的企業服務架構并不是簡單的技術層面的SOA，而是面向企業層面的，它將原有的ERP、SCM、PLM等模塊在NetWeaver這個技術平臺上集成，組合成業務流程平臺（見圖5）。企業在這一個平臺上可以共享很多組件，不同的企業也可以根據不同的需求，增加或選用不同的企業服務庫，或自主開發部分功能，實現企業的個性化。

圖5 SAP NetWeaver平臺業務組件

SAP的一位主管曾作過這樣一個比喻，將軟件的企業服務架構化比作電路的集成化。集成塊(IC)本身是功能模塊化設計的，但它是更復雜電路的基本組件，設計一個個的集成塊，把他們組成電子設備，而不再是從電阻、電容、電感、晶體管等基本元件來組建電路。以后軟件業業一樣，要設計這些“集成塊”和利用這些“集成塊”，這些“集成塊”就是企業服務(Enterprise Service)。 這也是面向服務架構思想在ERP軟件開發和產品發展中應用的最佳體現。

3 總結

面向服務架構（SOA）得到了各大軟件公司的重視，如IBM、Oracle、SAP等，說明其理念是先進的，相對于傳統的架構模式存在很大優勢。本文也具體闡述了其存在的優勢，但大部分也只存在于理論，因每個公司對SOA的理解各不相同，基于此理論設計開發出的產品也是各有特點，沒有得到一致的公認。

本文分析了SAP基于SOA思想提出的ESA這個思想，其最終產品仍處于開發階段，只能對其主導思想略為闡述。現在是SOA亂戰時代，但可以預見，隨著SOA思想的發展和完善，以及在軟件業的廣泛應用，它的優勢會逐步顯現出來，為傳統的ERP軟件帶來革命性的轉變。

軟件設計畢業論文:如何利用嵌入式軟件設計SoC

美國Globalpress公司舉辦的2007電子高峰會議上，舉辦了一場SoC(系統芯片)的專題討論會：設計師如何利用嵌入式軟件作為SoC器件設計的關鍵。會議上的專家各抒己見。

完整方案比單個硬件重要

主持人：Gartner公司的高級分析師JohnBarber

軟件在嵌入式產品中的份量越來越重。自2000年來，價值觀念發生了巨大的變化，2000年以前，主張是器件，即讓我們的器件與競爭對手的性能、品質進行對比具有優勢，這就是那時形成鮮明特色的關鍵。現今，制造商和客戶需要的是解決方案，而不僅僅是器件。我的價值主張，我的鮮明特色，必須是完整的解決方案，包括與硬件一塊推出的可以立即投入大批量制造的軟件棧。

硬件與軟件將設法整合到單個流程

Mentor Graphics系統級設計總監BillChown

我們過去所從事的是硬件設計，現在則還需要輔以軟件應用方面的大量工作。但這兩者的“婚姻”卻并不幸福。在兩者之間，我們需要填補在基礎架構方面的鴻溝，如今的硬件小是從頭設計的，需要進行基礎架構的復用。需要復用的包括處理單元、內存、接口器件……許多基礎設計事先已經被人們所了解、得到了分析和預先進行了配置。我們需要把它插入到系統中，提供針對硬件的軟什能力，以及針對具體應用的軟件能力。在用戶對硬件和應用軟件的使用目標的這兩個空間之間，我們必，壩確保能讓他們尋求到與他們的具體需求相應的問題所在，但是最大限度減小他們仡存兩個空間之間的工作量。

EDA代表電子沒計自動化，但我們有時候會迷失，而忘卻了“自動化”一詞正是我們在這個空間中應該完成的工作。我們應該回顧在這個流程中應該實現自動化的對象是什么?那并不僅僅意味著工具的改進，而且意味著我們能通過標準化來簡化問題。

總結一下，我們能讓人們去做的事情，是從一個任系統空間中的概念設計，一直到完成整個流程。慨念設計上的革新是關鍵，我們需要靈活多樣；隨著設計的進行，我們需要嘗試不同的解決方案。如果我不知道我往做什么，就無法去嘗試替代方案。所以良好的分析將告訴我，我所做的工作將會把我帶向何方。這些不同的任務中的每一項，都對應著每一個團隊所從事的領域。因此，這是一個復雜的世界，但我們將設法將其整合到一起。在實現整合的過程中，我們應該能加速、改動，并將來自于不同領域的軟件與硬件、系統與驗證集成到單個流程中。

軟件的關鍵作用是保證批量

MIPS Technologies公司市場行銷副總裁Jack Browne

在SoC設計時，我們所面臨的挑戰是多方面的。首先我們希望能向市場上推出種類多樣的產品。以MIPS公司為例，有3種不同的微架構系列，10種不同的處理器內核。我們必須具有某種能讓我們能投入制造的業務模式，因為本公司的業務模式是基于IP(知識產權)使用費的，我們的年收入的一半來自于授權和版權使用費。客戶的產品要達到制造批量，交貨則需要3-4年；他們拿到所設計出的芯片，要2年，然后他們再讓OEM來設計出系統，而這又要花上2年。所以，該供應鏈有一個問題：如果我的收入嚴格取決于制造批量，你應該如何來支付這些開發的費用?費用的支付要延后4年，財經界是不能容忍戰略性項目上的虧損的，你必須展示出業務的良好性。

另外一個挑戰是，你希望進入不同的、類型各異的市場。其中每個市場的成功的臨界數量(客戶數量)是不同的。同時你還必須支持不同的OS(操作系統)。你必須有解決所有這些問題的方案。我們的做法是，承認人們有一個平臺。軟件，無論是Linux還是其他的實時操作系統，一直到應用層次。我們所追求的關鍵一點，是使用硬件抽象層。從根本上來說，如果我有兩家不同的客戶，他們決定購買不同的套裝，或者甚至不同的USB控制器，則通過硬件抽象層，如你的PC中的BIOS，我可以實現不同的偏好，而不用移植操作系統。

你去考察供應鏈上的不同玩家的商業模式的話，就會發現，將操作系統移植到另一個硬件平臺上的工作并不能提供多少余地。如果你所選擇的應用不對路的化，則很難實現足夠的產量。如果你考察如今的標準數字電視的話，就會發現其中有些采用了300萬行的軟件。而你將看到2年后的HDTV將采用500萬行的軟件，而且其中有16個處理器，用于處理不同的任務。

所以軟件的關鍵作用就是保證批量。如何找到一個合理的財經運作模式，是EDA、IP公司、半導體公司、軟件公司共同努力解決的挑戰。

多處理器的軟件設計法

Tensilica公司市場行銷副總裁SteveRoddy

軟件的重要性到底有多高?有人認為市場規模尚小，有些人認為它很重要，另一些人則主張我們處在一個臨界階段，許多軟件都實現了移植。

3種現點也許都是正確的，具體取決于其市場。但我想退一步思考一下處理器也許倒也無妨。一個有趣的問題是，如今和未來的應用應該需要多少個處理器?這里借用ITRS(國際半導體技術發展路線圖)，來展示在每個工藝節點對應著的、每個SoC上平均使用的處理器的數量(圖2)。當前，ITRS宣稱每個SoC上平均有32個可編程器件。我們知道，有些可能數量會多些，有些則少些。Tensilica與Cisco合作，推出了基于130nm節點的、采用192個處理器的設計。所以處理器的數量會出現迅速增長。而軟件正是在此之上運行的。

是的，軟件的復雜程度和架構的復雜程度都正在增加。即便處理器的數量在增長，它們并不全都一模一樣。這些器件上將出現多樣化的處理器。

關于嵌入式的設計，很明顯的一點是，軟件的形式必然迥異于普通的通用型軟件。事實上，嵌入式世界迥異于與通用型軟件世界。在通用型應用的世界中，如Intel和AMD，在處理器上運行的軟件在器件開始推出時尚不為人所知。因此一般采用通用型的計算，對于通用型的計算，人們采用通用的SMP Die Bucket架構。在嵌入式世界中，如果你設計用于路由器的芯片的話，它就是供路由器專用的。優點就在于你知道器件的用途，所以其設計會針對具體應用進行優化，讓人們能利用專用的處理器，如可重構的和可擴展的處理器，以節省面積、成本和功耗。因此兩者的設計之道大相徑庭。擁有許多可重編程的處理器，并不意味著你有一個全新的世界。系統架構和硬件架構研發者努力解決這個問題已經有幾十年了。他們將其稱為SoC，現在人們以處理器為單位進行設計，而不是硬件模塊，他們在系統中引入了許多軟件的東西。但這并不意味著在設計這些東西的方式上會遇到什么危機。

設計這些系統的風格，仍然具有一個SoC 只有一個處理器的年代的SoC設計、架構所具備的那種多樣性。你可以讓處理器間具有一個看起來非常傳統的聯系，采用SMP通用型架構，你可以讓處理器之間根據具體應用來建立互動關系，你可以在處理器間建立硬件風格的數據流。事實上，某些處理器甚至根本都不清楚芯片上有其他處理器的存在。這些東西的實現有多種多樣的途徑，成功的關鍵是功能劃分，人們可以在功能模塊中放入標準、API，事實上，在這些系統上運行的軟件，可以造成復雜性極大增長，而我們在實現上仍然感受不到危機的存在，通過功能劃分，經過優化的處理器、經過優化的API將通用型的程序與軟件的所有復雜性隔離開來。

設計者完全可以利用直截了當的設計方法來掌握如此復雜的，設計數百萬行程序的軟件工作。

軟件發揮至關重要的作用

Wipro公司半導體／消費事業單位副總裁Siby Abraham

今天，推動半導體業發展的仍然是摩爾定律。對我來說，在設計中如何放入更多的邏輯、在一定的芯片面積上能放入多少個晶體管這一問題所帶來的痛苦和挑戰一這是技術經理和工程師們關心的問題，倒還比不上呈指數化增長的IC設計成本。源程序的復雜性的日益增長，而成本的上漲幅度超過了硬件的。

如今，邏輯電路的80％都被復用。這意味著SoC上只有20％的邏輯是用來體現其不同之處的。這也就是利用軟件來實現SoC鮮明特色的地方。我們所看到的趨勢是，根據我們過去4年所從事的項目，我們在軟件和半導體業摸爬滾打了多年，SoC的未來在于多核架構方面的改進，而這正是軟件發揮其效用的地方。

如今，我們的軟件還不能有效而自然地利用好多架構帶來的優勢。挑戰在于，軟件工程師如何能利用眾多核架構帶來的優點。我們已經看到了在SoC中對軟件的多方面的應用。軟件的挑戰，可以認為與硬件工程師們所面臨的挑戰是一樣的。

我們今天所看到的更重要的一點是，現在需要那些不僅僅把自己劃入硬件工程師或軟件工程師等類別的工程師們，他們了解更多的專業，從而能利用眾多領域的知識。我們看到一個大挑戰，有的客戶要求在產品供貨時就能提供軟件。

我們所看到的技術上的挑戰，價格、性能、功耗，而如今軟件團隊也將承擔相應的責任。如果沒有可調試性，硬件團隊將困難重重。

軟件設計畢業論文:虛擬心電監護系統軟件設計

摘要：在LabVIEW圖形化的編程環境下，利用MIT-BIH生理信號數據庫和LabVIEW的各種控件，實現對心電信號的采集讀取、濾波、保存和回放。通過改進普通閾值法，利用“雙閾值+校正閾值”的方法實現自動實時計算心率，對異常心電給予報警提示。同時，本系統設置了眾多交互按鈕，使得此心電監護系統功能多樣、人機界面簡潔友好、操作方便。

關鍵詞：心電信號；虛擬儀器；虛擬心電監護儀；LabVIEW

前言

當今心臟病已成為威脅人類健康最嚴重的疾病之一，因此需要一種能夠連續記錄或者智能記錄并分析心臟活動的心電監護系統，對患者進行實時監護。至今心電監護技術經過40年的臨床實踐和技術發展，其監護內容和儀器技術有了相當的發展。目前國內外心電監護的發展呈現出模塊化設計、長時數據保存、低功耗小型化、網絡信息化趨勢。理論和技術的不斷發展也為心電監護的進一步研究創造了條件。

LabVIEW是一種基于圖形編程語言－G語言的可視化開發平臺，多被應用于儀器控制、數據采集、數據分析等領域。鑒于實際心電監護儀難以普及和虛擬儀器的強大優勢，我們采用LabVIEW的開發環境、設計了虛擬心電監護儀系統，實現了對心電信號進行采集讀取、濾波、保存和回放，自動計算心率并對異常心電給予報警。此心電監護儀可以實現長時間的數據保存，而且操作界面簡潔友好，便于掌握。

心電監護系統

此心電監護系統采用模塊化設計，包括讀取模塊、濾波模塊、保存和回放模塊、心率計算和異常報警模塊，各模塊間的關系如圖1所示。我們采用的數據取自心電數據庫、不需濾波，因此略去濾波模塊；其中“雙閾值+校正閾值”的設計方法包含在心率計算與異常報警模塊中，引入校正閾值的目的是為了“放大”心電的某些波段，針對性的檢測某些心臟疾病。

系統子模塊的實現

讀取模塊

獲取心電信號有三種主要方式：數據采集卡現場采集：軟件仿真心電信號；從數據庫中讀取。鑒于開發成本和真實性，我們采用最后一種方法。

我們采用著名的MIT-BIH數據庫，其心電數據由.atr.dat.hea三種文件描述。我們采用LabVIEW腳本接口控件MATLAB Script Node，利用讀取心電數據的MatLab程序rddata.m，讀取心電信號，輸出心電波形。

濾波模塊

心電信號總是存在各種干擾，如工頻干擾、基線飄移、肌電干擾等，噪聲嚴重時可完全淹沒ECG(心電)信

號，因此必須消除噪聲，對心電信號進行濾波處理。

由于本設計采用的心電數據基本不需濾波處理，故這里的濾波是為校正閾值而設計的特殊處理模塊。我們選用的是平滑濾波器，它能很好地濾除心電信號中混雜的高頻噪聲信號。

保存和回放模塊

本模塊是以“寫入測量文件”和“讀取測量文件”控件為核心，輔以“數據轉換”控件，可以實現心電異常時自動保存以及有選擇地回放，可以在8道(可增刪)心電通道間任意切換，也可以選擇保存的文件類型。

這里，“數據轉換”控件的運用體現了LabVIEw數據流編程的思想。即每個控件都是對數據流進行操作，但作用的數據類型不同，其間通信必須先轉換數據類型。

心率計算和心電異常報警模塊

此模塊是虛擬心電監護儀的核心，也是用戶最關心的功能模塊。目前ECG自動檢測技術的研究主要集中在QRS波，P波和T波檢測，ST段檢測等方面，QRS波檢測是ECG檢測中的首要問題。

QRs波群檢測方法有閾值法、面積法、幅值法、神經網絡法、模式匹配法等。面積法和幅值法易受到噪聲干擾。后幾種方法較為復雜，運算量大且計算速度較慢，不適用于實時處理系統的要求。本系統采用的是改進的閾值法，可以概括為“雙閾值+校正閾值”。心電異常報警就是根據雙閾值和校正閾值的檢測數據，利用布爾運算判斷分析，結果送前面板顯示。

此方法的設計原理和思想與普通閾值法相似，即以檢測QRs波波峰的個數作為計算心率的依據，不同的是，此法采用雙閾值，利用“波峰峰值檢測”控件，設置兩個不同的波峰檢測閾值，一個閾值較大，用于檢測R波：一個閾值較小，用于檢測過強的T波和R波(本系統的檢測閾值可以在前面板中設置)，得到兩個檢測心率，然后利用比較、布爾運算，分析心電信號的異常情況并適時報警。針對心電的某些特征信號、這里設計了校正閾值算法，用于特定心電異常的檢測(如高頻噪聲干擾，可以選用平滑濾波器，設置合適閾值，校正檢測心率)。

此算法優點是計算量小，實時性好，便于在線分析；開放性強，可以擴展檢測閾值數量，提高分析的可信度；可以根據需要設置校正閾值。此法缺點是手動設定閾值，可以添加自學習模塊加以改進，利用自學習算法可實現。

“雙閾值”法可以解決普通閾值法中存在的幅度大的T波誤檢或低壓的QRS波被漏檢情況，而“校正閾值”能夠解決噪聲干擾造成的心率誤檢等(取決于校正算法)。總之，與普通閾值法相比，該算法極大地提高了系統的抗噪能力，并減低了誤判率。當然，可以根據需要，增加閾值檢測數目、以及采用其它校正算法，使其不僅僅局限于校正噪聲干擾造成的心率誤檢。

該心電監護系統的前面板和程序框圖分別見圖2和圖3。

結語

本文闡述了基于LabVIEW的虛擬心電監護系統的設計，該系統用戶界面友好、使用方便，充分發揮了LabVIEW的優勢；本心電監護儀實現了心電信號讀取、濾波、保存和回放，并且可以自動保存異常數據，實時報警和簡易的心電分析。

軟件設計畢業論文:手機應用軟件設計和開發的方法探討

摘要：分析了手機應用運行環境的特點，并針對這些特點提出相應的對策；同時，針對手機中應用程序顯示區域小，CPU處理速度和內存容量限制，應用程序的實時性要求和開發環境的封閉性等特點，提出了一些設計策略和解決方案。

關鍵詞：手機；應用軟件；設計；對策

0　引言

用戶在使用手機中無時無刻不在和手機上的應用程序打交道，手機應用程序設計得好壞直接影響用戶對該款手機的感受。手機的應用程序的好壞決定了一款手機的內在品質，從而在很大程序上決定了一款手機在市場上的命運。本文結合筆者開發手機應用程序的經驗，探討手機上應用軟件的設計和開發方法。

1　手機應用軟件的特點分析

目前市場上的手機分兩類：功能手機(Feature Phone)和智能手機(Smart Phone)。雖然這兩類手機還沒有一個明確的界線，但是手機上運行的應用程序都有如下特點：

顯示區域小為了方便攜帶和按鍵，大屏的像素點為128x160、160x24、240x320等。

CPU處理速度和內存容量比段小基于成本的考慮，手機上的處理器(MCU)的頻率較低，一般只有幾十M，智能手機稍高，一般200―400M。內存(RAM和FLASH)一般為8M，16M，智能手機一般32M，64M。

和移動網絡的交互密切，實時性強能與移動網絡隨時隨地通信，交換語音和數據信息。對于來自移動網絡的來電，短消息，彩信，推消息(Push message)等，應用程序必須能及時提示用戶，并能讓用戶方便地處理這些信息。這一點也是手機產品和其他的PDA，PMP等產品的最大區別，同時對這些信息的處理也是手機軟件設計和開發的關鍵點和難點。

軟件的開發環境千差萬別，因而手機應用程序的運行環境相差甚遠現在市場上的手機的開發環境要么是手機的芯片開發商提供，要么是獨立的軟件公司提供，還沒有一個統一的開發標準。各個平臺的軟硬件環境差別很大，在一個平臺上的應用程序根本不能在另外一個平臺上運行。手機應用軟件開發和平臺緊緊地綁定在一起，軟件的可移植性極差。

2　手機應用軟件設計和開發的對策

針對上述手機應用軟件的特點，在進行手機應用軟件設計和開發的時候必須有清醒的認識，并預先有相應的解決方案，在項目進行到中間或者最后才發現或者考慮這些問題為時太晚。下面是筆者認為在手機應用軟件設計和開發上總體需要把握好的關鍵點。

2．1怎樣應對應用程序顯示區域小

應用程序的界面風格應一致。好的做法是設計一個共用的應用程序的基類(接口)，所有的應用程序都從這個基類(接口)繼承；設計一組公共的顯示控件，這些控件的顯示風格可以通過配置文件進行設置。這樣可以很方便地達到“換膚”的功能，從而滿足用戶界面上個性化的需求。

多用圖標和簡潔文字來表達界面的含義。由于顯示區域的限制，手機很難像PC那樣利用多重窗口，基本上是一個應用程序占用整個窗口。采用統一的圖標和簡潔的文字能達到界面意義明確，表達意義形象的目的，這比冗長的文字更能吸引人的注意，使人記憶深刻，從而給用戶良好的使用體驗。如果能結合富有表現力的動畫圖片更好。因此，必須設計的圖形控件有：應用窗口類，圖片類，動畫類，圖片標簽類，進度條類，單行列表類，多行列表類，單選列表類，多選列表。在手機應用窗口中應該充分利用這些類來設計有特色的用戶界面。

設計一個通用的合理的輸入法接口。輸入法的設計在手機應用程序中有重要的地位。輸入法的設計在實現的時候要考慮的實際問題有：

(1)怎么方便地切換各種輸入。例如，可以考慮用#，*鍵來切換各類文字的輸入。另外，標點字符和數字等由于使用的頻率很高，可以考慮增加快捷菜單或者快捷鍵操作的輸入方法。

(2)待選字符的安排是否合理，操作是否方便。例如圖1所示界面是筆者設計的中文編輯界面。

說明：如果用戶輸入xyz所在的按鍵。則在區域1顯示所有的待選拼音／筆畫。在這個時候用戶可以按左右方向按鍵來選擇待選拼音／筆畫。用戶按OK鍵，在區域2，高亮(Highlight)顯示的是第一個待選漢字。這時按左右按鍵高亮光標在待選漢字間移動。如果漢字太多，可以按上下按鍵來在前一頁和后一頁漢字之間切換。按OK鍵，高亮選定的漢字將被輸入到編輯界面上。在區域3，是區域2高亮漢字的聯想詞組。用戶可以長按1-9鍵將顯示的詞組直接輸入到編輯界面(不需要高光選擇)。短按一次取消鍵(C鍵)刪除編輯界面的一個漢字，快速短按兩次，刪除編輯界面的一行漢字，長按取消鍵，全部刪除編輯界面的漢字。

上面舉的例子只是中文的輸入，實際情況是還需要英文字母，英文單詞，標點符號等字符的輸入。所以，輸入法的軟件設計的細節問題很多，各個應用的需求千差萬別，需要我們在開始設計軟件時充分考慮輸入法接口的可擴展性和靈活性。

2．2怎樣應對CPU處理速度和內存容量的限制

設計或者選定一個合理而高效的系統架構。好的應用程序需要一個好的系統框架。針對手機的CPU和內存的特點，手機的應用程序的運行環境和PC上的程序運行環境有很大的不同，用表1總結如下：

通過上面的對比，可以看出，手機的設計應注意以下幾點：

(1)以當前手機的硬件為基準，采取適度超前的原則來定義系統架構。整個架構不必大而且全，要小而精，并盡量做到架構中的各個部件具有很好的可裁減性。這樣的系統架構才能滿足各種不同的硬件需要。

(2)精心設計架構中的每一個部件，消除系統冗余的代碼；合理定義接口，系統的架構才能清晰容易被人理解，并且系統的可靠性也高。只有這樣，整個系統架構的代碼占用的內存少，應用程序在運行的時候占用的內存和CPU資源少。

(3)應用程序可以在PC上模擬運行。一般手機上調試應用程序的過程比較復雜，如果一個很小的改動都要到手機上去調試很浪費時間，同時，在PC上調試程序也比在手機上調試程序方便得多。一個好的程序架構的基本要求是絕大部分的應用都可以在PC機上模擬開發完成。

精心設計應用程序。應用程序的執行效率和應用程序的設計密切相關。對于手機上的應用程序，不同的設計策略有不同的結果。例如：對于一個電話本的應用程序，讀取所有電話記錄至少有兩種方法：一種是在一開機的時候就讀；另外一種是在電話本應用打開的時候才讀。實際情況是前一種情況較好，因為，這樣用戶每次進入電話本的時候手機可以很快地顯示所有的電話記錄，后者則慢得多，在有些系統中可能是難以忍受，必須提前準備好數據。

在設計應用程序中著重考慮的問題有：

(1)程序的處理效率是否高；

(2)程序的內存占用和CPU是否太多；

(3)用戶的操作是否方便，應用的響應速度是否足夠快；

(4)界面的定義是否美觀，和系統的總體風格相一致；

2．3怎樣應對應用程序的實時性要求

手機最重要的功能是通話和通信。這些一般和無線網絡都有密切的關系。對于來自無線網絡的來電，短消息，推消息等，必須有一個應用來統一調度和處理這些消息和信息。筆者稱之為待機管理應用。待機管理應用是底層軟件和其他應用程序的調度員，同時它也負責待機界面下的界面顯示和其他應用不方便處理的一些任務。如果用圖來表示，那么它在整個系統中的位置如圖2所示。

待機管理應用的特點是：(1)一開機就首先運行；(2)總是處于運行或者待命狀態，不會退出。

因此，這個應用的穩定性要求就特別高。在軟件設計的時候要特別注意功能劃分，如果某項功能能在其它的應用中處理，該功能應盡量分到別的應用中去，以免待機管理過于復雜，影響系統的穩定性。

待機管理應用的功能一般如下：

(1)處理與充電器和電池有關的消息。例如：插入充電器，如果是在開機，則在待機下顯示充電動畫；拔掉充電器，關閉充電動畫的顯示等；

(2)處理開機動畫或者問候語的顯示；

(3)如果底層協議報告SIM卡設置了PIN碼，啟動SIM卡的PIN碼輸入界面；如果還設置了手機密碼，則啟動手機的密碼輸入界面；

(4)顯示待機下面的各種狀態圖標，網絡注冊的信息，時間和日期信息，各種應用圖標的排列；

(5)顯示屏幕保護的界面；

(6)處理用戶在待機狀態下的各種按鍵操作，例如：如果用戶短按了數字1所在的按鍵，則要啟動號碼編輯應用或者界面，如果用戶在應用圖標或者菜單中按或者點擊了某一個應用，則要啟動該應用；

(7)顯示各種系統狀態，例如：未接來電和短消息的提示，電池電量不足的提示，鬧鐘的提示等；

(8)轉發底層的各種消息給相應的應用程序，為其他的上層應用提供統一、簡潔的接口。這樣做的原因是通過對底層消息的封裝和轉換，能簡化其他應用處理。并且使待機管理應用能及時了解系統當前的狀態，并及時通知給用戶。

2．4怎樣應對應用程序的開發環境的封閉性

正如上面提到的，現在市場上主流的手機開發平臺很多，并且還不斷有新的平臺涌現，怎樣開發能在各種不同的平臺上有很強移植性的應用程序對程序設計和開發人員是一個艱巨的任務。筆者結合自己的經歷認為可行的思路如下：

(1)應用的用戶界面和實際的處理邏輯盡量分開，將一些可以共用的處理邏輯提煉成共用的函數接口。例如：日程應用的陰陽歷轉換算法，電話本中的首字母查找算法等都可以放在一個單獨文件或者庫文件中，這樣的代碼可以很方便地移植到其他的平臺上。

(2)編寫代碼的時候，數據結構的定義和函數的處理要考慮不同硬件平臺的差別。一個好的做法是定義一個平臺上通用的數據類型定義，而不是直接使用設計語言里面原始定義的數據類型。例如：如果是在C／C++的開發平臺上，我們可以定義一個文件types．h，它里面包含如下通用類型的定義：

typedef char BOOLEAN；

typedef unsigned char BYTE；

typedef char CHAR；

typedef unsigned short WCHAR；

typedef char INT8；

typedef unsigned char UINT8；

typedef shOrt INTl6；

typedef unsigned short UINT16；

typedef long INT32；

typedef unsigned long UINT32；

typedef long LONG；

typedef unsigned long ULONG；

在程序中，所有數據結構的數據項，函數的參數和返回值，類的成員數據都用上面的這些通用類型，這樣編寫的軟件的可移植性就可以大大提高。

如果可能，多采用成熟的第三方軟件或者知名的開源代碼庫。

手機的應用經常碰到部分模塊是自己開發還是采用第三方軟件的問題。為了軟件的可移植性，加快軟件的開發速度，這些模塊應該多采用專業公司開發的成熟軟件或者采用穩定的開源軟件。這比自己重新開發好、快捷方便得多，開發成本也比較少。例如：現在很多手機都支持MP4播放，這樣就涉及音視頻編解碼的問題，如果可能，選擇一個經過市場驗證，可移植性強的第三方或者開源的音視頻編解碼庫比自己進行開發要合算得多，這樣的應用程序的可移植性比自己在特定平臺上全部由自己開發的應用程序要好。

3　結束語

手機上的應用程序開發環境現在還是一個比較封閉，與應用程序耦合比較緊密的系統；應用程序的設計和開發相對復雜，對應用的穩定性，安全性，實時性要求也比較高。無論是對手機系統平臺的設計人員還是開發人員，只有在了解其特點的基礎上才能提出有針對性的方案。本文指出了這些特點并闡述了筆者的觀點，希望能起到拋磚引玉的作用。

軟件設計畢業論文:遙測文件截取器軟件設計與實現

摘 要:為解決大容量遙測數據文件的快速分割,軟件針對遙測文件以幀為基本單位且每幀頭都含有時碼的特點,設計按特征參數截取、按時間截取以及按幀序數截取等三種方法以滿足不同的截取要求。遙測參數的解算調用已成熟的動態鏈接庫,對于一些耗時的運算使用了二分搜索等優化算法。該軟件操作方便、截取效率高,在型號應用中發揮了重要作用。

關鍵詞:遙測; 文件截取; 軟件設計; 二進制; 數據圖形顯示

0 引 言

隨著科技的進步,空空導彈的研制越來越復雜。相應地就有越來越多的數據信息需要遙測傳輸,這必然導致遙測接收的數據文件較大。以3 Mb/s碼率計,10 min的遙測數據就有214 MB之多。數據處理軟件往往需要經過異步幀提取,有效位屏蔽,甚至經過費時的字符串處理[1]才能得到最終結果。所以當用戶處理這種大文件時往往需要等待很長的時間。如果能夠把這樣大的文件分割成較小的幾個文件然后分別處理,那么處理軟件的運行時間就可以縮短到用戶可以忍受的程度。

另一方面,空空導彈的發射試驗往往比較短暫,從導彈離開載機直到導彈爆炸只有不到1 min的時間。數據分析人員最關心的也正是這段時間的數據。而實際遙測中,為了確保數據的可靠接收,會從發射前5 min開始記錄直到遙測信號完全消失才停止記錄。

這種情況下,如果能夠根據導彈發射的特征信號(比如導彈與發射架分離的信號)來截取遙測數據文件也具有重要的實際意義。

本文通過對實際需求的分析,提出了按遙測幀數、時間和特征參數三種文件截取方法,并在VC 6.0平臺上予以實現。

1 軟件設計

1.1 功能設計

在空空導彈遙測中,待傳輸的信號都是先通過多路復用組裝成一個N字節長的遙測幀然后調制傳輸。在接收端解調后先通過幀同步獲得該N字節長的遙測幀,然后在幀頭加入8 B的時碼(又稱為B碼)來表示接收到該幀的時刻,如圖1所示。這樣存盤后的文件字節數是N+8的整數倍[2]。

圖1 遙測幀發送接收過程

因為遙測數據按幀存放,所以有意義的最小分割單位是幀而不是字節,對文件的截取最后都要歸結到按幀來截取。因此,軟件的第一個功能同時也是最基本的功能就是按幀的起止序號進行分割。

由于文件中每一幀數據的幀頭都有B碼,所以將該B碼換算成實際時間之后也可以根據時間進行截取。

數據分析人員一般要求提取導彈發射后到爆炸這一時間段的數據,所以利用導彈發射電氣分離信號(ES)的跳變,截取跳變時刻前5 s直到跳變時刻后50 s的數據能夠確保覆蓋所需數據,同時盡量減小數據文件的大小。

典型的電氣分離信號圖形如圖2所示。

圖2 典型電氣分離信號圖形

(a) ES沒有跳變 (b) ES有跳變(c) ES有跳變,信號有野點

(a)圖導彈未發射,(b)圖導彈發射,(c)圖導彈正常發射但信號有野點

通過對圖2的分析可以得出以下結論:ES跳變點需要通過計算的來判決,比如當前數據點與下一數據點之差超過信號范圍的2/3,那么就認為當前點為跳變點。但是對于圖2(c)中有野點的情況這種判決方法就有可能導致誤判。所以最好的辦法是讓用戶參與跳變點的判決。軟件自動找到第一個跳變點,用戶可以通過快捷鍵[3]找到下一個跳變點,直到正確的跳變點為止。

這種設計方法杜絕了跳變點的誤判,同時又能直觀快捷地輔助用戶找到跳變點,另外還簡化了軟件的設計。

1.2 模塊設計

分割一個文件的流程[4],如圖3所示。

分析圖3可以得出軟件必須的幾個模塊:

(1) 打開待分割文件并自動生成分割后文件;

(2) 分割方式選擇;

(3) 特征參數數據繪制;

(4) 起止幀序數選擇;

(5) 起止時間選擇;

(6) 是否需要剔除無效幀。

最終確定的軟件界面[5-6]如圖4所示。

圖3 文件分割流程圖

圖4 軟件界面

2 軟件實現

2.1 按特征參數分割

按特征參數分割涉及到遙測參數解算。程序運行時首先加載動態鏈接庫dbreader.dll,postpro.dll和eu.dll。在OnInitDialog中調用函數GetTMFrameFormatInfo來獲取遙測幀格式,包括遙測幀的長度,碼率,同步碼位置等信息。然后調用函數GetTMParaAllRecord來獲取所有參數在遙測幀中的位置信息,解算方法等。

當用戶從程序界面的參數下拉列表框中選擇一個參數時,觸發CBN_SELCHANGE事件并調用消息函數[7]。在消息函數中根據參數是幀同步數據還是幀異步數據分別調用GetASyncParaValue函數或EUConvert函數解算出數據,同時從數據中找出跳變點,然后在圖形控件上繪出曲線。

2.2 按B碼時間分割

要想根據時間信息來查找對應的遙測幀就需要將該時間和文件中各遙測幀頭的B碼代表的時間進行比較。如果采用遍歷查找的方法,對于總幀數為N的文件,理論上需要比較(N+1)/2次,要找到起、止兩個時間對應的幀就要比較N+1次。這對于較大的文件來說消耗的時間會很長。

在遙測文件中,每幀數據都是按接收到的先后順序從前往后依次存放。也就是說,搜索的目的序列是有序的。對于這種情況,可以采用折半查找法[8]進行搜索。理論證明,采用折半查找最多需要的比較次數為Иlog2(n+1),搜索起、止兩個時間共需比較2*log2(n+1)次。

2.3 按幀序數分割

三種分割方式最后都歸結到按幀分割。按幀分割惟一復雜的地方就是剔除無效幀。要剔除無效幀需要將每一幀數據的同步碼取出來和標準的同步碼進行比較。如果差異位數超過容許值就丟棄該幀,否則保留。很多程序都采用依次右移一位,看二者最低位是否相同,如果不同則計數加1,循環直到兩個數都為零的方法。

這種方法效率非常低。本文采用了如圖5所示的計算方法[9]。

圖5 計算同步碼錯誤位數

這種算法的關鍵在兩處:首先對兩個被比較數a和b按位異或,結果c的二進制數中為1的位置就是a和b不一致的位置。然后c不停地與c-1按位與[3]并將結果賦給c,直到c為0。通過歸納法可以證明c與c-1按位與可以消掉c的從低位往高位數的第一個1,所以c的二進制值有幾個1就循環幾次。

3 結 語

本遙測軟件采用模塊化設計,便于實現和測試。同時結合遙測文件的結構,實現了按幀序數、按時間和按特征參數三種分割方法,較好地滿足了型號遙測數據處理的需求。從軟件的設計可以看出,對于較復雜的軟件采用自頂向下,逐漸細化的分析方法,分模塊設計[10];對于影響程序性能的處理過程有針對性地進行優化,可以有效地提高程序的可靠性和性能并簡化設計過程。

軟件設計畢業論文:20kg級自主水下機器人控制軟件設計與實現

(中國海洋大學 信息科學與工程學院， 山東 青島266100)

摘要：介紹了用于對20 kg級便攜式AUV的運行狀態進行控制的軟件設計以及實現。該軟件是基于MFC對話框運行于Windows操作系統下的程序，使用了多線程編程技術和串口通信技術。串口操作線程用于向串口讀取或寫入數據，并且在處理后把最終結果發送給主線程和導航線程。在主線程中將數據顯示到界面上，在導航線程根據導航算法計算出用于導航的數據并寫入串口以控制AUV的運行狀態，包括AUV上浮、下潛、前進、后退、左轉彎、右轉彎。實驗結果表明，該軟件達到了預定效果。

關鍵詞：便攜式AUV； 多線程； 串口通信； MFC

自主式水下機器人（Autonomous Underwater Vehicle,AUV）代表著未來水下機器人的發展方向，因而是世界各國研究的熱點［1］。而便攜式AUV由于使用方便，可執行環境評估、水文地理、輔助水道測量、港口安全、巖屑區域繪圖等工作以及可以用在未來戰爭中［2］，將是未來AUV發展的重點。

本文主要論述了便攜式AUV控制軟件的設計及其實現，該軟件主要用于監視AUV在水下運行時的狀態信息以及控制AUV的運行。AUV在水下運行時的狀態信息包括位置信息、航向、艙內溫濕度、推進器轉速、舵的方向角以及在水面時GPS傳感器數據等信息，該軟件將這些信息顯示到界面上最終實現對AUV的監控和導航。

1便攜式AUV系統簡介

該小型AUV由兩個密封艙組成，前艙安置了傳感器系統，后艙安置了AUV推進器以及方向舵的控制系統。兩個密封艙中間放置的一個垂直推進器用來控制AUV的上下運動，后艙安放了用于控制AUV水平方向的水平推進器和方向舵。系統搭載了AHRS、數字羅盤、GPS等傳感器，這些傳感器采集到的數據用于AUV的導航。AHRS傳感器用來測量AUV的航向角、俯仰角、橫滾角、3個方向的速度、加速度；數字羅盤測量AUV的航向角等信息控制軟件對一串口進行操作，該串口連接與AUV進行通信的無線模塊。將從無線模塊接收到的數據經過慣性導航算法處理，根據協議將慣性導航算法處理結果發送到AUV，最終實現對AUV的控制。

2串口通信

串口在做文件處理時，簡單的應用可以采用查詢方式或定時方式，復雜的可以采用事件驅動的方式。所謂事件驅動，即當串口有數據進入輸入緩沖區時，自動執行接收程序。利用WinAPI讀/寫串口操作可以有同步方式與異步方式。所謂同步方式是指發出寫命令時，直到有數據寫入到輸出緩沖區寫函數才返回。異步方式的重疊方式是指發出寫操作命令后，不管寫操作是否完成，寫函數馬上返回，寫操作在后臺繼續進行，寫操作完成后通過某種方式通知調用寫操作的線程。這樣避免了主線程被掛起，提高了程序的工作效率［34］。

2.1串口通信設置

在實現串口通信時，首先在界面上設置串口號、波特率、校驗等信息。單擊按鈕打開串口，進入命令響應函數OnBtnOpen()，利用API函數打開并對串口進行配置［56］。最后使用API函數CreateThread創建一個線程。由于軟件工作過程中需要傳送的數據量不大，所以僅僅打開一個串口。

主線程打開串口具體流程圖如圖1所示。

圖1打開串口、創建線程流程圖在主線程中打開串口的代碼如下：

m_hCom=CreateFile(m_port,GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,NULL)

在串口操作線程中使用API函數ReadFile用于讀取串口數據ReadFile(hCom,buf,19,&Length,&Eol)；而在該線程中向AUV發送控制指令時使用：

fState=WriteFile(m_hCom,buf,19,&m_bytes,&m_osWrite)

2.2串口通信協議

串口通信必須遵守一定的通信協議，才可實現該控制軟件與AUV的正常通信。串口通信數據格式如圖2所示，圖中Data0，Data1，Data2…代表一個字（2 B）。

圖2串口通信數據格式發送或接收的一幀數據最長為19 B，Data0中第1個字節代表指令(0xA1）、請求(0xB2)或者正常應答(0xC3)等含義；Data0中第2個字節代表具體指令、請求何種信息或者某種信息的應答。Data1，Data2，…代表發送或者接收到的數據。開關機指令長度為19 B，第19字節控制8個繼電器，1，0分別表示開、關第零位控制總電源。開機、關機指令前18 B分別是：

~A16613579BDF02468ACE13579BDF02468A

~A166DF9B5713CE8A4602DF9B5713CE8A46

開機指令的第19個字節根據需要選擇相應的繼電器開啟或關閉；關閉指令第19個字節為0x00，所有的繼電器關閉。

3軟件實現

3.1多線程實現

一個進程可有多個線程，使用多線程可提高軟件的執行效率。該控制軟件共有3個線程組成，包括一個主線程、一個導航線程和在成功打開串口后利用API函數CreateThread［78］創建的一個串口操作線程（如圖3所示）。

圖3多線程組織結構串口操作線程讀取串口數據，并提取有效數據，接著利用函數PostMessage將有效數據分別傳送到主線程和導航線程。主線程將有效數據根據協議進行解包并把數據包中包含的AHRS、數字羅盤、GPS等傳感器和推進器、前艙環境參數等數據顯示到界面上。當使用搖桿控制AUV的運行時主線程每隔0.5 s從USB接口接收數據，并轉換成推進器轉速以及方向舵的方向角信息，且將這些信息發送到串口操作線程寫入串口。

在主線程中創建串口操作線程的代碼如下：

hThread=CreateThread（NULL,0,ThreadProc,

(LPVOID)this,0,NULL);

在串口操作線程中將有效數據發送到主線程的代碼如下：

PostMessage(*pDlg,WM_MYMSG1,

(WPARAM)buf,(LPARAM)Length);

3.2關鍵算法

由于慣性導航系統提供的位置估計精度會隨時間而漂移，所以導航線程采用基于GPS/INS的組合導航［9］算法，用GPS輔助導航，即用GPS信息輔助修正慣導系統的輸出，包括航向角和速度。對AUV的航向角信息修正是通過經典的PID控制算法來實現的，如圖4所示。

圖4AUV PID航向角閉環控制算法設Ji-1，Ji為AUV的2個節點，AUV即A點從Ji-1到Ji 點運行。設正北方向矢量為k=(1,0)，根據圖5按照下式可計算出角度θ。角度θ計算公式為：

θ=AJie北|AJi|?|e北|

=（Jix-Ax,Jiy-Ay）?（0,1）(Jix-Ax)2+(Jiy-Ay)2?02+12

=Jiy-Ay(Jix-Ax)2+(Jiy-Ay)2

在AUV進行Ji-1~Ji段的航行時，AUV根據導航算法不斷算出坐標并判斷是否到達指定區域，當離指定區域為R時（R很小），即可判定到達指定區域。在到達指定區域之前不斷利用AUV PID航向角閉環控制算法修正航向角θ，最終實現AUV的GPS/INS組合導航。

圖5航向角計算圖解4控制軟件界面及實驗結果

4.1軟件界面

本文設計的軟件界面左側上半部分和右側主要實現對AUV的控制，界面左側中下部分的3個儀表盤和TAB頁控件顯示AUV的各個狀態信息。

單擊開機、關機按鈕將實現AUV的開啟與關閉；單擊詢問AUV按鈕，此時應答情況為AUV存在，表示監控軟件與AUV的通信正常，否則應該檢查無線模塊和AUV。單擊前艙參數、GPS經緯度、GPS時間、推進器狀態、AUV航向角等按鈕將持續獲得AUV相應的信息；步進電機控制按鈕用于實現方向舵的調整，進而實現AUV方向的調整。為了防止步進電機失步，這里還特意設計了步進電機的微調按鈕，目的是在步進電機失步時將方向舵調整回原位置。

該控制軟件還以儀表盤的方式顯示推進轉速、羅盤、溫、濕度等信息。

以速度儀表盤為例，當從串口接收到的數據中提取出水平推進器或垂直推進器速度信息時，將速度信息存放到成員變量m_Spd1或者m_Spd2。利用API函數得到控件IDC_STATIC_SPD的區域坐標rect2，調用API函數InvalidateRect(&rect2)重繪，將進入函數CDspsockDlg::OnPaint()重繪。利用MFC中的函數Pie，Ellipse，SetBkColor，TextOut［10］畫出儀表盤背景。最后通過下列兩個公式將速度值轉換成對話框上的坐標值，調用函數畫一條連接該區域中心位置到該點(a1,b1)的直線［11］，最終實現儀表指針隨速度值的變化。坐標（a1，b1）計算公式如下：b1=60sin((m_Spd1×3/25+150)π/180)

a1=60cos((m_Spd1×3/25+150)π/180)4.2實驗結果

軟件運行期間界面顯示如下。圖6顯示了溫、濕度分別是32°，51.5°；單擊復位按鈕、溫濕度指針將分別指向-30°，20°位置處；圖6還顯示了2個推進器的速度信息，其中水平推進器速度為1 180 r/min，垂直推進器速度為0，此時AUV在水平方向運動垂直方向靜止。

軟件設計畢業論文:軟件設計類課程實踐性教學的研究與實踐

摘要：本文深入分析了計算機實踐性教學的內涵，探討了軟件設計類課程實踐環節的組織模式，研究了這一方案的可行性。

關鍵詞：實踐性教學；軟件設計；課程改革；計算機專業；項目實訓

0引言

從1956年哈爾濱工業大學率先開辦“計算裝置與儀器”專業算起，到現在普遍采用的“計算機科學與技術”專業，計算機專業教育在中國的大學里已經走過了50年的歷程。70%以上的本科學校開設了計算機專業，在校學生近30萬[1]，其規模居所有本科專業的首位。加上專科、高職、中職在內，其數量還要大得多。計算機專業人才在信息化建設過程起著舉足輕重的作用。然而，企業面對十里挑一的大好形勢，卻經常會找不到合適的人才，造成這種局面的主要原因是學校培養與單位需要存在一定的脫節現象，主要表現為重理論輕實踐，動手能力差，因而改革實踐環節提高學生的操作技能成為高校計算機類專業的必經之路。

1軟件設計類課程實踐性教學的內涵

實踐性教學是指為配合理論教學，培養學生分析問題和解決問題的能力，加強專業訓練和鍛煉學生實踐能力而設置的教學環節，通常有兩種落實途徑：一是隨堂實踐，即課程作業、實驗、上機操作等；二是集中實踐，即社會調查、各類實習及見習、課程設計以及畢業論文或畢業設計。教學計劃中規定的作業、實驗、實習等環節和集中實踐環節是學生必修的內容，在課程和專業學習中具有突出的地位。不同專業的實踐性教學方式，教學管理和考核辦法也不相同，但都是以專業培養目標作為前提。對于計算機(包括軟件工程)專業的軟件設計類課程，其教學目的就是培養合格的軟件工程師，適應軟件設計和項目管理崗位的需要。

1.1軟件工程師崗位需求

任何一個軟件企業，開發團隊都需要這樣三類人才：一是既懂技術又懂管理的軟件人才即系統分析師(高級)，二是軟件工程師(中級)，三是程序員(初級)，這三類人員在軟件企業的正常比例應該是呈金字塔結構，根據國際經驗，高、中、初級軟件專業人才的比例應基本維持在1：4：8。通常系統分析師由研究生承擔，軟件工程師由本科生承擔，程序員則由大專生以及專門培訓機構的學員完成。如圖1所示。

從圖1可以看出，計算機專業的本科生對應軟件工程師崗位，在軟件開發團隊中處于中間層，優秀者可以上升到系統分析員層次。同時，軟件工程師也要兼任程序員角色，因為不少軟件企業規模較小，難以按照軟件工程的規范細化分工，需要能做分析、能寫代碼、能做實施甚至用戶培訓的“多面手”。作為高校，必須充分考慮這種情況，以培養軟件工程師為主線，也要提高系統分析能力，同時還應該加強代碼編寫的訓練。

1.2軟件設計類課程實踐性教學的內涵

軟件設計類課程主要包括計算機語言類、開發類、設計類、制作類和工程類課程，共同的特點都是經過系統學習，既能夠按照規范獨立設計小型軟件，組成團隊后又能夠設計出具有實用價值的中大型軟件。

軟件設計類課程實踐性教學標目的是培養學生兩個方面的能力：即獨立編程能力和項目合作開發能力。一方面，能夠利用所學語言和平臺設計小型軟件，同時能夠按照項目分工，在項目經理(負責人)的統一安排下，在技術上服從既定的設計方案完成模塊的開發，并做好相應的文檔。良好的責任心、解決問題的獨立編程能力和分工合作制的團結協作精神是必須重點培養的內容。軟件設計類課程實踐性教學的內涵如圖2所示：

2軟件設計類課程實踐性教學的組織

按照軟件設計類課程實踐性教學的內涵，一般應包括3個環節：課堂實驗實訓、課程設計、項目實踐，分階段實施。其具體安排如圖3所示：

2.1課堂實驗實訓環節

如果一門課程的教學任務規定在一個學期內完成，課堂實驗實訓環節應該安排在學期的前半部分進行，以講授語法、數據類型、常用類庫、開發平臺為主。學生所學知識和編程技術有限，難以形成完整的程序思路，實踐環節只能是練習基本功單獨完成，以每一次堂或者每一個章節為單位安排學生進行相關的訓練，以熟練掌握語法的基本用法，為后一階段的課程設計做準備。老師指導時，要注意培養學生良好的編程習慣，包括標識符的規范化命名、注釋語句的廣泛運用、編程語句的縮進格式、幫助文檔的使用方法，逐漸形成編程思想。

為了配合實踐性教學，教材的選擇也十分關鍵，最好是采用基于案例教學法或者項目驅動教學法的教材，這種教材往往會通過一些典型的實例或企業項目組織內容，大部分章節的主題相對集中，圍繞項目展開講述，特別適合于實踐性教學。如果采用實踐性較弱的教材，老師需要自行補充一些實習實訓內容讓學生當場消化吸收。

2.2課程設計環節

這一階段十分關鍵，完全模擬軟件企業的開發流程組成小組共同完成一個中小型項目的設計，一般安排在后半學期進行。這時要求學生停止其它課程的學習，每天八小時工作制，甚至晚上可以加班加點，專心設計項目，其最終成果包括軟件和文檔以及用戶操作手冊。以每班30人為例，可以考慮分為5個小組，每組6人，每個小組安排組長(項目負責人或稱項目經理)一人，組長的職責是：組織成員實地項目調研、模塊劃分與任務分工、接口的確定、進度的監督與協調、集成測試等，組長直接接受指導老師的安排。鑒于組長在在項目設計過程所處的重要地位，老師在確定組長時，至少考慮三個方面：一是組織能力，二是專業技能的基本功，三是責任心。

這一過程通常安排兩周到三周集中在校內機房(實訓中心)進行，老師每天針對總體要求及當天的任務進行講解，然后分小組實施。選擇課題時，不宜太復雜，應盡可能讓大多數課題組可以在規定的時間內做完。一般選取學生們比較熟悉的內容，如學生成績管理系統、班級管理系統、教材管理系統、倉庫管理系統、工資管理系統、就業反饋跟蹤系統、水電費管理系統等，這些課題的要求大家都比較清楚，在校內即可進行客戶調研和需求分析，同時也具有較強的推廣價值，為將來的職業奠定基礎。這時每個人同學都應該至少準備一本項目開發類指導書作為參考，因為涉及到數據庫、界面、網絡通信、硬件編程等方面的知識，僅僅靠教材還不夠。

2.3項目實踐環節

項目實踐環節是學生到軟件研發企業(校外實訓基地)全程參與項目開發的過程，一般應安排在學期的最后一到兩周或者利用假期頂崗實習，因為經過了課程設計，學生基本掌握了軟件企業的開發流程和一般方法，進入軟件公司后就能夠較快地進入程序員角色，而不至于膽怯，也不會無所適從。完成本部分實踐內容要做好以下三個方面的工作：

確定好項目指導老師：企業開發與在學校進行課程設計并不盡相同，軟件公司具有自己的風格，往往更加愿意采用自己熟悉的開發工具，以達到客戶的需求作為目標，并不一定會使用最新技術，這點與教學理念不同。理想的方案是由任課老師帶隊進入軟件企業(校外實訓基地)，并選擇目前正在開發的項目經理擔任總負責人(校外實踐指導老師)，任課老師也參與項目實踐并組織學生實施，因為一個優秀的項目經理不一定是優秀的老師，能做軟件不見得會上課，項目負責人與任課老師共同配合更能發揮各自的優勢，便于學生理解項目思想和相互溝通。經過簡短的培訓后，由模塊責任人指導學生設計或者由學生獨立完成，一切按照企業的開發規范進行。考慮到軟件企業一次難以容納過多實習生的特點，也可考慮將項目拿到學校來做，或者將項目經理請到學校現場指導，以節省時間和費用。

確定項目指導方法：開發應用項目沒有現成的教材，需求分析、概要設計說明書、詳細設計說明書、數據庫和數據字典就是設計的依據，老師必須嚴格按照這些文檔指導學生進行設計，定期檢查學生的進度及過程，一旦發現偏差，及時糾正，將錯誤消滅在萌芽狀態。

及時組織項目總結：每天規定一個時間，將同組學生集中起來，針對當天完成的任務進行總結，交流自己的想法，提出存在的問題，集體討論，這樣就能夠做到日日有收獲，天天有提高，從而鍛煉自己的實戰水平和組織經驗。

3軟件設計類課程實踐性教學效果的考核

軟件設計類課程實踐性教學效果的考核也是一個較難把握的環節，既要考核學生的獨立編程能力，也要考查其團隊協作精神，同時還要考慮其組織能力、表達能力、文檔編寫能力、紀律性等內容。為了客觀科學地評價學生的實際效果，最好是分階段考核，各部分按照一定的比例綜合得到總成績，可以等級表示，也可以用分數反映。

在課堂實驗實訓階段，可以由任課老師根據每一次操作任務的完成情況進行登記評分，重點考察其規范程度，對于具有創新性的作品，可以適當加分，并在全班展示，讓設計者講解思路，為其它同學提供啟示。

課程設計階段的考核由指導老師和項目組長組織學生共同進行，首先由組長匯報課題的設計思想、主要技術、任務分工等情況，并演示軟件，大家可以相互提問。老師根據項目完成效果確定這個組的等級，然后由各位成員介紹自己所設計的模塊，老師重點檢查此模塊的功能、難易程度、技術含量、界面美觀等因素，再確定其成績或者等級，這時還要充分考慮組長對成員在設計階段各方面的綜合表現。

項目實踐階段的考核由校外指導老師和校內老師組成考核小組，利用項目匯報加平時表現的形式評定，既要考察項目的完成情況，也要考察各位學生在企業實習期間的領悟能力、工作主動性、團隊合作情況、算法的復雜性、程序的規范性等方面，其主要依據是提交的軟件(包括源代碼)以及各種文檔。

實際上，對于實踐性教學的考核可以采用靈活的方式進行，不拘一格，比如聘請行業專家、現場答辯、隨機抽題、項目論文等形式，只要能夠檢查學生的真實技能即可。

4我們的實踐

我們學校十分重視實踐性教學，長期堅持強化學生的動手操作能力和實戰水平、力爭與企業零距離接軌的做法。為了提高程序設計類課程的實踐性教學效果，主要采取了以下措施：

4.1嚴把教師關

教師是實踐性教學效果的基本保證，學生的水平在一定程度上反映了教師的水平，既具有扎實的理論功底，也擁有豐富的項目經驗是優秀教師的標準。一方面，我們積極將已有教師定期送到企業實地參加項目開發實踐，積累經驗，另一方面，不斷從軟件企業引進專業技術人才，將他們的成功案例帶回學校，同時，每年組織專業教師進行實踐性教學能力考核，通過考核者才能承擔課程設計和項目實踐的教學任務，并頻發相應證書，作為教師晉升職稱和評先評優的重要指標。

4.2實踐性教學環節流程化

改革原來的學期一貫制，將一個學期分為兩個階段，前一階段以學習基礎理論為主，隨堂考試，在學期的最后幾個禮拜專門安排做課程設計，一般開設兩門小課，專心實踐，在項目指導老師的統一安排下，綜合運用本學期所學的程序設計工具，結合前面所學內容，以項目小組的形式，完成一個小型軟件的設計，成績計入學生檔案，完成者才能獲得相應的學分。暑假或者寒假以及最后一個學期，老師分批帶領學生前往校外實訓基地或軟件企業從事項目開發，作為社會實踐或畢業設計的成績，并要求撰寫項目總結或論文。

4.3實驗室環境企業化

聘請軟件企業技術人員設計實驗室(實訓中心)建設方案，將原來的布局改造成軟件研發中心或者工作室模式，服務器、網絡設備、數據庫完全仿真企業的環境，將開發流程和軟件文檔國家標準打印并懸掛在墻上，并購置專業書籍存放在實驗室，讓學生一旦進入實驗室，就能迅速感受到真實的企業氛圍，還能方便查閱相關資料。

4.4實踐項目規范化

教師和軟件企業合作開發一整套實踐教材，采用項目驅動、案例教學作為主要方法，將常用軟件項目的全部開發過程編寫到教材中，源程序存放在服務器，供學生編程參考。每次課程設計或者項目實踐后都要評比出優秀作品，將其全部程序及文檔資料保存下來，供以后教學和低年級學生使用。

經過近幾年學生的反饋情況，我們的改革收到了良好的效果，學生在校期間已經具備了一定的經驗，走入社會即可迅速融入開發團隊，勝任軟件工程師職責，深受單位的好評，不少畢業生特別是原來擔任過項目小組長的學生很快即可成為業務骨干或者項目經理。

5結束語

高校教學與行業脫節是普遍存在的現象，程序設計類課程實踐性教學更是一個永恒的話題。所幸的是，學校和企業都充分意識到了這一點，各高校正在采取積極的舉措消除這一段距離，企業已變得越來越務實，不斷細化崗位職責。隨著校企合作的深入，訂單培養方式的持續，相信在不遠的將來，這種差距會越來越小，直到完全消失，那時學校、企業、學生三方都能成為實實在在的受益者。

軟件設計畢業論文:PBL的改進及在“軟件設計模式”課程教學中的應用研究

摘要：本文討論了軟件設計模式課程教學中的幾個問題，介紹了經典的PBL教學法及其不足，對其教學過程設計進行了改進并給出了一個教學案例，另外本文還就應用PBL教學法的注意事項進行了討論。

關鍵詞：PBL；軟件設計模式；計算機教學；面向對象；教學方法

“軟件設計模式”是一門理論性和實踐性都非常強的課程，內容抽象難懂，目前的大部分教材僅僅在一般意義上給出了各種模式的定義、結構、代碼框架，授課時容易出現內容空泛、言之無物的情形，學生感覺這門課程比較困難。如何根據學生的特點，選用合適的教材，采用適當的教學方法是提高軟件設計模式教學效果所必須要解決的問題。本科學生的特點我們很難改變，教材問題可以通過授課教師的主觀努力，以講義和補充材料的方式加以解決，而本文則主要討論軟件設計模式的教學方法問題，即在軟件設計模式課程的教學中如何使用PBL教學方法來提高教學效果。

1PBL及改進的教學過程設計

PBL(Problem-based Learning)是一種行之有效的“做中學”教學方法，最初是由Barrows在加拿大McMaster大學提出來的一種教學策略和課程設計思想，符合以學生為中心的自我引導學習的建構主義學習理論。有效的PBL可以提高學生下面這幾方面的能力和素質：解決問題的技能；思維能力；團隊合作能力，包括賞識和包容異類學習同伴的精神；組織利用時間的技能；獲取和評價信息的能力；傳播信息的技能；計算機運用能力等。

在教學中引進PBL教學法后我們發現該方法的不足之處，主要問題是：時間消耗量大，學生學習的效率不高；在班級規模較大時，教師對教學的組織和教學過程的控制也存在很大的困難；以小組為單位，容易造成學生能力發展不均衡，出現小組內某些學生成為主導，另一些學生則濫竽充數的情況。為此我們對PBL方法作了一些修改，教學過程設計如下：

(1) 提出一個與本次課程要學習的設計模式相關的設計問題。這一步非常關鍵，提出的設計問題必須與學生已有的基礎較接近，規模適中，是學生可能完成的任務。這樣可以激發學生的學習興趣。

(2) 講授與該設計模式相關的面向對象的設計原則。對這些原則的講授可以貫穿在該門課程的整個教學過程中，適當的重復和強調可以加深學生的印象，促使學生在其今后的設計中自覺運用設計原則，即使不套用設計模式，也能產生良好的設計方案。

(3) 給學生留出時間，讓學生設計前面問題的解決方案。要求每個學生自己進行設計，但允許和同學討論。

(4) 抽取并公布學生的設計方案，組織同學討論其優劣，對比與事先提出的設計目標的差距并分析原因。

(5) 以相應設計模式的思路，對學生的方案進行改進，并給出其簡單實現。

(6) 從上述實例中提煉出要講授的設計模式，總結其意圖、結構、角色、示意性代碼，分析其可能的變化。

(7) 布置一個類似的設計問題作為課偶作業，要求學生給出完整的設計和實現。

我校“軟件設計模式”課程只有32個學時，在這么短的學時內讓學生完整深入地掌握23個設計模式是不現實的。

我們在制定教學大綱時充分考慮到了這個問題，選取了其中一部分作為課堂教學的內容，選取的準則是：①是常用模式；②在模式分類中具有代表性。其余的設計模式則留給學生課后自學。

2一個基于PBL的設計模式教學案例

Strategy Pattern(策略模式)是一種常用的重要的設計模式，下面以該設計模式的教學為例，說明PBL教學方法的應用。

(1) 提出問題。某公司銷售打印機時有一定的折扣讓利給顧客，但折扣計算的方法有很多種，如不打折、每臺減扣固定的金額、按售價的5%打折等。現在要為該公司開發銷售系統，實現打印機銷售時的折扣計算，要能夠靈活地選用折扣計算方法，并且可以很容易地增加或修改折扣計算方法，而不至于對整個系統的維護造成困難。

(2) 相關設計原則的講授。本設計模式主要涉及三個面向對象的設計原則：針對接口編程，而不是針對實現編程；優先選用對象組合，而不是類繼承的軟件復用方式；分離變化，并對變化進行單獨封裝以使得今后對軟件的維護局部化。在講授這三個原則時，各舉簡單的例子加以說明。

(3) 讓學生解決第一步提出的問題，給出設計方案。設計時盡量運用前面講授的三個設計原則。要求每個學生自己動手，但鼓勵討論。

(4) 抽取學生的設計方案，并比照第一步提出的設計目標進行分析討論。由于時間關系，不可能對每個學生的方案進行討論，一般鼓勵學生主動提交，主動提交的學生一般認為自己的設計方案較好，此外也可以選一個不理想的設計方案進行討論。

學生的設計方案五花八門，圖1是其中的一種。

圖1 學生的一個設計方案

該設計方案部分運用了講授的設計原則，如PrinterSaler使用抽象類Printer而不是直接使用具體類HPPrinter等，這體現出學生試圖運用針對接口編程的原則；該方案將計算折扣的方法單獨抽象成一個接口，但卻是用打印機的具體類來實現該接口的，說明了設計者意識到計算折扣是變化的部分，試圖將其分離出來，但卻沒有將它進行獨立的封裝，因此對改善系統的可維護性和折扣方法的靈活選用并無多大幫助，而且由于抽象類Printer沒有實現該接口，使得PrinterSaler通過使用Prinetr來計算折扣難以實現。

通過分析和討論(這一過程要鼓勵學生參與發言，而不是教師唱獨角戲)學生的方案，指出其不足，并一步步加以優化，最后可以得到基于Strategey模式的設計方案，如圖2所示。

圖2 基于Strategy Pattern的設計方案

在此強調由于折扣計算方法的分離和單獨封裝，就可以通過實例化不同的具體折扣計算類ConcreteDiscount并賦值給Printer的引用變量(假定為Discount)，然后通過調用discount.calcDiscount()靈活選用相應的折扣計算方法；折扣計算方法可以被所有打印機類復用，甚至可以被其他類復用；而且修改或增加新的折扣計算方法也不會影響其他打印機類的代碼。

(5) 為了使學生有更為切身的體驗，給出上述設計方案的實現代碼，編譯并演示運行結果。

(6) 從上述實例中提煉出要講授的設計模式，總結其意圖、結構、角色、示意性代碼，分析其可能的變化。

(7) 布置一個類似的設計問題，作為作業，要求學生給出完整的設計和實現，提交實驗報告。

軟件設計畢業論文:面向財務應用的軟件設計課程教學模式

摘要：為了培養既懂財務又懂軟件開發技術的復合型人才，根據金融財務類應用的需要，本文提出了一個面向軟件課程設計的教學模型。融合計算機基礎理論、軟件開發技術、軟件工程學原理以及CMM軟件過程體系，構建了教學模式框架。該模型具有良好的課程總體結構以及動態適應新技術發展的能力，該模型適合財務類院校軟件復合性人才培養的需要。

關鍵詞：軟件課程設計；財務應用；復合型人才；教學模式

1引言

目前，中國軟件產業計劃以超常規的發展速度在世界上占有一席之地。 軟件產業近年來已成為中國電子信息產業中增長最快的部分之一。在新一輪的國際分工中，高附加值、低成本、智力密集型的軟件與信息服務業正逐步向亞太地區轉移，這給中國和印度等國的軟件產業帶來巨大的發展機遇。盡管中國軟件產業已從初始階段進入成長階段，一些軟件企業正在一步步正規化；但是軟件企業和軟件人才結構不合理：幾乎沒有從事個人消費者軟件的企業；大部分軟件人才為編程工程師，缺少軟件架構師、項目經理、測試員等。另一方面，隨著IT技術的飛速發展和日新月異，特別是互聯網技術的發展和應用，企業能夠在一個全新的、統一的高科技信息技術的環境支撐下來建立和實施現代企業管理。財務軟件系統的應用已經普及，但我國財務軟件的發展前景卻不容樂觀，財務管理人員隊伍普遍存在知識老化，不能適應網絡經濟時代對財務管理工作的需求，也不能很好地理解和使用財務軟件和信息系統，直接影響了財務軟件的使用效果和財務軟件產業的發展。會計制度體系的變革和會計理論研究的滯后是制約財務軟件和財務信息系統的模型進行創新設計的重要瓶頸，影響了財務軟件產業的發展。

財務軟件設計的復合型人才在財務軟件產業發展中處于最重要的地位。財務軟件設計的復合型人才必須在財務和計算機軟件設計兩個領域都非常有專長，成為這兩個領域里的行家里手。所以，培養高級的、現代化的財務軟件設計的復合型人才勢在必行。目前我國財經高等院校和大部分綜合類高等院校、成人高校和新興的職業技術學院都開設有計算機專業和財會專業。但從橫向上看，這兩個專業在課程的設置上還存在著“單打一”的現象；從縱向上看，課程的深度，尤其是計算機網絡知識和財會知識的結合程度比較膚淺，學財會的學生僅僅掌握數據庫的操作和簡單的憑證輸入及報表編制是遠遠不夠的。從將來培養高級會計軟件工程人員的角度出發，計算機和財會專業應互相滲透、互相兼容，讓學生“兩條腿”跑步，對于這類學校的計算機專業更要調整軟件課程設計模式，

使學生能夠迎接當今財務軟件產業的挑戰，獲得更多的工作機遇。

軟件設計課程是一門綜合性的實踐課程，其通過合理的軟件項目，來鍛煉學生的分析、設計、編程、測試、維護等多方面的綜合能力，既要學生掌握應用領域的專業知識，又要學會應用計算機軟件的專業理論來解決應用領域的實際問題。如何通過軟件課程設計來提高學生在未來工作中的適應能力，是目前軟件教育業普遍關注的核心問題。如何使軟件課程設計具備靈活的面向財務應用的適應能力，也成為金融財務類院校探討的熱點[1、2]。本文針對培養財務軟件設計開發的復合型人才的需要、結合計算機基礎理論、軟件開發技術、軟件工程學原理[3]以及軟件過程模型[4~6]的特點，提出了一個軟件課程設計動態模型。其可以根據學生的不同層次、不同的培養目標，定制裁剪，該模型適合財務類院校軟件復合性人才培養的需要。

2面向財務應用的軟件設計課程教學模式

2.1 課程目的

面向財務應用的軟件設計課程教學目的如下：

1) 鍛煉學生綜合分析、設計、開發軟件產品的能力；

2) 融合學生已經學過的計算機課程、財務會計課程的內容，使理論與實踐相結合；

3) 根據當前的技術發展水平和社會財務軟件行業的需求，適當擴充學生的新技術的容量；

4) 掌握規范的軟件開發過程、管理過程，與國際軟件界接軌；

5) 財務管理系統對軟件設計的要求。

2.2教學模式的框架

面向財務應用的軟件設計課程教學模式應該根據財務復合型人才培養的需要，結合現有的計算機基礎理論的教育，同時融合現代軟件工程學的思想，制定相應的教學框架。該教學模式的框架結構如圖1所示。

圖1中的有向邊表示各個部分之間的依賴關系，各個組成部分描述如下：

(1) 軟件、財務基礎課程

該部分是“軟件課程設計”的必要基礎條件，應在開設“軟件課程設計”之前完成。主要有：離散數學、數據結構、數據庫原理、過程程序設計、面向對象的程序設計原理、計算機系統結構、計算機網絡、操作系統、會計學、財務管理、會計信息化。

(2) 各類應用模型

主要探討與企業應用相關的領域模型，不僅僅限于財務軟件系統。其可以包括如下內容：

1) 電子商務；

2) 企業資源管理；

3) 客戶關系管理；

4) 供應鏈管理模型；

5) Internet多媒體應用；

6) 財務管理等等。

(3) 研究的軟件課題集

根據(2)所描述的應用領域，根據學生的不同層次和培養目標，抽象領域應用模型，形成供軟件課程設計所需的軟件課題集。每個軟件課題既要包括該軟件所需的應用領域背景、領域知識、領域模型，又要包含該軟件系統開發的所有文檔、過程文檔、以及學生實際開發過程文檔、評測文檔、改進文檔等等。該部分是該模型的核心，其的構建需要若干周期的軟件開發和學生實踐才能獲得，同時還要考慮軟件應用領域和軟件技術變化發展的因素。

(4) 當前流行的軟件技術

主要包括當前業界盛行的開發技術。這些技術不僅是學生完成該課程所需要，而且也是當前主流的軟件開發技術和工具；學生掌握這些技術后，在就業的競爭中，可以發揮重要作用。并且這些技術應該隨著產業的發展而變化發展。目前主流的技術有：

1) 基于微軟.net技術的應用開發模式，如Windows OS、C++、C#、VB、ASP、SQL SERVER等；

2) 基于SUN公司的JAVA2(EJB)、SUNOne技術的應用開發模式，如LINUX、JAVA Bean、JAVA2 EJB、JSP、ORACLE等；

3) 基于OMG的CORABA技術的應用開發模式，如C++、ORACLE、UNIX等。

(5) CMM體系

CMM模型已經在業界得到公認，并且如果軟件企業要想獲得美國的軟件開發資格，必須要通過CMM認證。如果學生在學校能夠了解CMM體系，那么其在今后的企業工作過程中就可以很好地適應企業認證的需要，同時也增加了學生的就業競爭力。CMM體系分為三個層次:1)PSP(The Personal Software Process)規范；2)TSP(The Team Software Process)規范；3)CMM(Capability Maturity Model)規范。由于該體系過于龐大、抽象，學生掌握比較困難，所以可以重點培訓PSP和TSP過程規范。

(6) 課程過程文檔集

課程過程文檔是掌握學生學習情況的重要依據。學生的學習過程的記載可以參見PSP模型，但又不可生搬硬套。PSP的許多文檔過于繁瑣，實踐證明學生感到其過于單調，往往會影響學生的學習興趣。在構建過程文檔的時候，還要引進PSP模型中的小組過程信息，使過程和軟件項目的整體所統一。

(7) 課程評測系統和評測規范

評測系統要根據學生開發的軟件產品原型、課程過程文檔集以及評測規范來進行。評測不僅要對軟件原型的功能、性能進行檢驗，還要評測軟件過程文檔的規范性、完整性。更重要的一點，要評測學生的應用領域知識、背景的掌握情況；必要時可以給被評測者一個新的應用領域模型，來檢測其對新問題的處理能力。評測規范應該根據實際情況而定，既要檢驗學生的專業深度，又要考慮其應用知識面的廣度；既要定量考慮，也要定性分析。有關具體評測方法可以參見CMM體系。

(8) 課程的實際效果

課程的目的是培養應用領域復合人才，課程的實際效果的檢驗需要學生的實際就業情況、實際工作情況而定。可以建立一套學生跟蹤系統，和學生簽訂檢驗合同。畢業就業的學生定期把自己的工作情況反饋給該跟蹤系統，跟蹤系統根據這些反饋進行整理分析，以便動態調整該課程模式的實施。

2.3課程模型的實現模式

在課程模式框架圖中，涉及的范圍太廣，學生很難掌握，所以可以根據學生的實際情況分解成四種實現模式：

(1) 單一技術模式

單一技術模式主要培養學生的軟件開發技術，同時要掌握個體軟件過程技術。根據本模型框架，可以裁剪為如下內容：

1) 具體一門技術；

2) 一個簡單的應用模型；

3) 財務系統分析工作；

4) 基礎軟件工程學；

5) PSP規范、財務管理標準及規范。

(2) 軟件開發規范模式

軟件開發規范模式主要培養學生的軟件開發技術，同時要掌握軟件過程模型，重點為CMM體系。根據本模型框架，可以裁剪為如下內容：

1) 具體一門技術；

2) 一個簡單的應用模型；

3) 財務系統分析工作；

4) 基礎軟件工程學；

5)PSP規范、TSP規范、財務管理標準及規范。

(3) 復合模式

復合模式主要培養學生的領域問題解決能力、掌握軟件開發技術，同時要求掌握軟件過程模型，重點為CMM體系。根據本模型框架，可以裁剪為如下內容：

1) 具體一門技術；

2) 一個中等難度的應用模型；

3) 財務系統分析工作；

4) 基礎軟件工程學；5)PSP規范、TSP規范、財務管理標準及規范。

(4) 高級模式(研究生)

高級模式主要培養學生的領域問題分析能力、掌握建模技術、開發技術、管理技術，同時要掌握軟件過程模型，重點為CMM體系；這個模式需要學生已經具備良好的軟件開發技術和軟件工程學原理。根據本模型框架，可以裁剪為如下內容：

1) 一個大的應用模型；

2) PSP規范、TSP規范、CMM規范、財務管理標準及規范。

2.4實施部驟

該模型的實施步驟如下：

(1) 模型集構建

1) 收集已經完成的應用項目；

2) 項目歸類；

3) 項目抽象成應用模型；

4) 給出評測標準(規范)。

(2) 確定實現模式

1) 了解學生基礎情況；

2) 測試學生的能力；

3) 選定一個實現模式。

(3) 學時安排包括

1) 新技術培訓；

2) 項目開發、評測；

3) 總體評測、評分。

3結束語

企業財務電算化的普及，是提高企業科學管理水平、增強競爭力的核心。培養既懂財務、又會軟件設計、同時具備軟件過程規范的復合型人才是企業的需要，同時也是金融財務類院校的責任。有效的軟件課程設計的教學模式是培養復合型人才的關鍵，本文提出的模型對這方面進行了初步探討。有關具體內容還需在實際的教學過程中細化、研究。

軟件設計畢業論文:根據社會現代服務業要求建設創意與軟件設計專業

摘要：專業建設只有根據社會產業需求進行才有生命力。隨著現代服務業的快速發展，社會急需創意與軟件設計人員，所以重點建設好創意與軟件設計類專業，培養適應軟件、創意設計等現代高端服務業發展要求的有用、適用人才是當務之急。本文闡述了上述觀點。

關鍵詞：創意產業；現代服務業；軟件產業；專業建設

1專業設置的必要性

為加快無錫國家動畫產業基地建設，促進動漫產業發展，無錫市政府先后出臺《市政府關于鼓勵和扶持動漫產業的若干政策意見》和相關補充條款。為加快發展我市軟件產業，加快經濟增長方式轉變，無錫市政府又制定了《市政府關于加快無錫市軟件產業發展的意見》，要求到“十一五”期末，無錫要培育一批骨干龍頭軟件企業，要成為江蘇省內乃至國內重要的軟件產業基地之一，到2010年要完成軟件業銷售收入300億元，全市擁有省認定的軟件企業200家。為搶抓國際服務外包轉移機遇，加快集聚國際服務外包和軟件出口企業，把無錫太湖保護區建設成 “中國服務外包示范區”，無錫市人民政府制訂了《市政府關于集聚國際服務外包和軟件出口企業“123”計劃的政策意見》，提出到2010年末，全市要集聚國際服務外包和軟件出口企業100家，每家企業從業人員超過2000人，年出口超過3000萬美元。

產業發展、人才需求對職業教育提出了新要求，同時也為職業教育提供了新機遇。我校將緊緊抓住這一機遇，以服務為宗旨，以就業為導向，總結現有動漫、軟件和設計專業的辦學經驗，開設創意與軟件設計類專業，重點培養無錫服務外包產業發展所需的軟件、創意設計、動漫影視類中端及實用性人才。

2專業設置的可行性

學校信息類和藝術類專業已開設多年，形成了一支結構合理、業務精良的師資隊伍，取得了明顯的辦學成果，為創意與軟件設計類專業建設奠定了良好的基礎。學校早在上個世紀80年代初就引進計算機課程教學，1993年設置計算機技術及應用專業，并很快開發出軟件、維修、網絡等專業發展方向。順應地方經濟發展對人才的要求，1999年學校又設置多媒體制作專業。2004年，在全國的同類型學校中，率先與印度國家信息技術學院(NIIT)合作，培養軟件開發人才。2006年與匯眾益智科技有限公司合作，培養游戲人才。2007年增設影視動漫專業，并于同年秋季首次招生。

學校擁有一支專兼職結合，結構合理的專業教師隊伍。學校現有信息和藝術設計類專業教師44人，其中高級職稱教師11人，中高級職稱教師占本專業教師的62%。享有國務院津貼專家1人，特級教師2人，省市級骨干教師9人。雙師型教師26人，現已參加NIIT培訓8人，參加游戲動漫培訓并獲得相關技能證書6人。21人碩士研究生畢業或在職攻讀碩士學位。學校還擁有一支由行業專家、企業技術骨干組成的兼職教師隊伍。他們參與專業開發、課程改革和教學活動，是學校的寶貴資源。

學校堅持從產業結構調整和社會崗位的變化來謀劃專業設置，堅持面向職業需求，以培養學生能力為本位實施課程改革，加強專業建設。2004年計算機技術及應用專業被評為江蘇省示范專業，2007年“FLASH動畫制作”課程被評為無錫市優秀課程。在校學生參加各級各類技能大賽，多次獲獎。

學校已建成“三中心五室”實訓基地。“三中心”為網絡中心、信息技術研發中心、計算機技能綜合實訓中心；“五室”為游戲動畫制作實訓室、NIIT軟件開發實訓室、計算機網絡實訓室、多媒體工作室和美術基礎實訓室。基本滿足當前教學需要。

3專業設置方案

(1) 專業設置、學制和培養目標

培養目標：培養大專層次的創意與軟件設計產業所需的中端及實用型技能人才，見表1。

學制：初中起點五年。

(2) 教學設施和實訓基地建設

學校將本著配套、實用、先進的原則，加大投入，增添創意與軟件設計類專業教學所需的設施設備，并建成1200O的校內實訓基地，見表2。

說明：動漫實訓基地包括渲染工作室、手繪工作室、模型工作室、美術工作室、動作捕捉室、影視高端實訓室、專家指導工作室、攝影棚、放映室、衍生產品工作室等。

基地建成后，學校還將以此為載體，面向社會開展技能培訓和職業資格認定；主動迎接企業教育社會化的任務，承接企業訂單，參與企業技術改造和產品研發，使其成為產教研合作的新平臺。

(3) 教師隊伍建設

專業建設，教師是關鍵。除借助國家、省、市已有的各類師資培訓途徑培養教師外，學校擬針對專業教師專業知識豐富、實踐經驗不足、動手能力不強的現實，加強校本培養和培訓。一方面學校將花大力氣從企業引進有志于學校教育的實用型專業技術人才；另一方面繼續推行專業教師下企業實踐的制度，每年至少選派一位教師下大企業進行為期6個月到1年的實踐。另外，學校還設想依托已有的“大昭”工作室，鼓勵教師搞專業開發、技術改造、技術創新和產品生成，培養本專業的技術領袖。

(4) 教材建設

教材建設是專業建設的重要內容，但目前這類專業可供選擇的教材不多。學校將根據教學計劃、教學大綱選擇優秀教材，并根據前期開設NIIT軟件技術、游戲動漫等專業的經驗，繼續引進與國際接軌、符合企業要求的優質教育資源，還將組織教師自主開發、編寫順應產業發展、適合于教學、有利于提高學生動手能力的教材，見表3。

(5) 校企合作

職業教育的本質是向企業提供人力資源，所以職業院校和企業有著天然的聯系，校企合作就成為學校和企業的共同選擇。下一階段，學校將繼續加強與企業的合作，在為企業輸送人才的同時，依托企業培養師資和學生，實現“雙贏”。

根據無錫產業的發展走向，動漫影視、動漫游戲、軟件、創意設計類人才的需求是大量的。我們將延續學校近百年辦學所形成的厚重文化，解放思想、搶抓機遇，提升傳統優勢專業，拓展創意與軟件設計等新專業，為無錫經濟跨越式發展提供智力支持和人才支撐。