山東大學軟件工程碩士專業學位論文格式(范本)_第1頁
山東大學軟件工程碩士專業學位論文格式(范本)_第2頁
山東大學軟件工程碩士專業學位論文格式(范本)_第3頁
山東大學軟件工程碩士專業學位論文格式(范本)_第4頁
山東大學軟件工程碩士專業學位論文格式(范本)_第5頁
已閱讀5頁,還剩6頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、山東大學軟件工程碩士專業學位論文格式山東大學軟件工程碩士專業學位論文格式 8 1. 8附錄、附圖表 13 1. 9引文出處及參考文獻 13 1. 10致謝 15 1. 11攻讀學位期間發表的學術論文目錄 15 論文內容組織結構 15 論文主要內容寫作說明 1. 論 1. 4.2論文的正文 1. 需求分析 系統概要設計 3. 系統詳細設計 4. 系統實現與測試 20 1. 4.3 結論 20 201X04更新第一部分 山東大學學位論文規范等。論文中的操作步驟盡量統一用 (1) 、 (2)及以下層次的編號。 3 文中并列內容應盡量避免使用 、 、 等項目符號,以免論文顯得內容較散,更像技術報告,不

2、像科學論文。 4 文中不用、 或a、b、 作為順序編號。也不用 一、 二、三 及 (一)、 (二)、 (三) 作為順序編號。 5 標題由詞組或短語組成,要簡短明確,標題末不帶 句號 、 冒號 等標點符號。層次以下的內容一般不用標題。同一層次標題在語法結構上應盡量對等。 6 不出現 孤立 編號,例如,不應出現只有 1. 1.1而無 1. 續編號的情況。如確實需要該標題,可采用不帶編號和標志的標題,字體字號與同等層次標題相同(目錄中不必列出)。 7 正文中不使用 加粗 功能企圖達到突出重點的目的。論文中的各級標題舉例要求如下: 標題 格式 示例一級標題 小三號 黑體 加粗 摘要 第1章 緒 論二級

3、標題 四號 黑體 加粗 1.1 系統開發背景 系統概要設計三級標題 小四號 黑體 加粗 3. 系統功能架構設計四級標題小四號 黑體 加粗 3. 1 系統*設計正文 小四號 宋體 我就是宋體小四號注意: 各級標題一定要用Word的標題工具設置(建議使用 格式樣式和格式 功能),以便整篇文章統一并可以自動生成目錄。不要自己排格式和設置字體,以免無法生成目錄。 (3)論文用紙及打印規格。論文用紙一律為A 4,一般每行3234字,每頁2931行,雙面打印。紙張規格、尺寸每頁印刷版面尺寸每行打印字數 每頁打印行數含篇眉,頁碼 不含篇眉,頁碼 A4 146x240 146x220 3234字 2931行頁

4、眉: 從摘要開始到最后,在每一頁的最上方,用5號宋體,居中排列,頁眉之下劃一條單實線(1鎊),頁眉用 山東大學碩士學位論文 字樣的名稱。如下圖: 段落、頁邊距、字間距和行間距: 上下頁邊距: 54m,左右頁邊距: 3.17 m;字間距: 標準;行間距: 1.5倍行距;段落按照標題級別不同,分別采用不同的段后間距: 標題級別 段前間距 段后間距一級標題 24鎊 二級標題 鎊 1.5行三級標題 pt 1.5行(可適當調節各級標題的段前、段后間距,以利于控制正文合適的換頁位置) (4)論文中的制圖、制表等要求。論文中的制圖、制表、公式、符號必須遵循國家規定的標準,具體如下: 插圖要求,所有插圖按分章

5、編號,如第1章的第1張插圖為 圖1-1 *圖 ,字體可以用宋體5號字。所有插圖均需有圖注論文集中析出的文獻著者題名見: 文集編者文集名版本出版地: 出版者,出版年頁碼示例如下: 胡海昌中厚板彎曲理論的一種更精確的解耦方案見: 黃克智,徐秉業固體力學及其工程應用北京: 清華大學出版社,199385 89 WEinstEIn L,Sartz M N. Pathogeni properties of invading niroorganisma. In: Sodeman W A, Jr., Sodeman W A,ed. Pathologi phsiolog: mehanisms of diseas

6、e. Philadephi a: Saunder,7 472學位論文的著錄格式序號 作者. 題名: . 學位授予單位所在地: 學位授予單位, 學位授予年專利的著錄格式序號 專利申請者. 專利題名. 專利國別, 專利文獻種類, 專利號. 出版日期技術標準的著錄格式序號 技術標準發布單位. 技術標準代號. 技術標準名稱. 出版地: 出版者, 出版年注: 工程碩士論文的參考文獻除論文、著作、書等以外,也可以出現少量的技術標準、技術報告和網站資源等作為參考文獻。 1. 10致謝致謝: 系對給予各類資助、指導和協助完成研究工作以及提供各種對論文工作有利條件的單位和個表示的感謝。致謝應實事求是,切忌浮夸之

7、詞,不能千篇一律,要寫自己真實的想法,一般不超過半頁紙。 1. 11攻讀學位期間發表的學術論文目錄攻讀學位期間發表的學術論文目錄: 按學術論文發表的時間順序,列出本人在攻讀學位期間發表或已錄用的主要學術論文清單,包括論文發表刊物名稱、卷冊號、頁號、年月及論文署名位次。學位論文評閱及答辯情況: 論文答辯通過后,送校學位辦公室、圖書館和檔案館的論文需將學位論文評閱及答辯情況填入相應的表格中。 1.3 論文內容組織結構 軟件工程碩士的論文的主要內容結構應按照如下方式進行組織,作者也可以根據自己研究設計開發系統的實際情況做一些微調,但一般以下內容不可或缺。第1章 緒論 1.1 系統開發背景 外同類課題

8、(或技術開發)狀況 1.3解決的主要問題 工作(非研究性論文不使用 主要貢獻 的說法) 的組織結構第2章 需求分析 1系統概述 2系統目標和解決的問題 3系統需求獲取模式(避免引用過多人所共知的理論) 4系統需求問題描述 4.1系統功能性需求 系統非功能性需求第3章 系統架構概要設計 3.1 系統設計目標和原則 3.2 系統技術架構設計(架構、安全架構、系統邏輯、部署架構、實現架構、數據架構等幾個方面,作者可以進行選擇性的撰寫。) 3.3 系統功能架構第4章 系統詳細設計(避免出現過多同類材料的羅列和堆積)統建模(盡量使用UML語言) 4. 1.1系統的靜態結構圖 4. 的動態結構圖系統數據庫

9、設計(包括但不僅限于: 系統E-R圖、數據庫表設計等。)第5章 系統實現與測試系統總體實現- 5具體關鍵實現 5+1系統測試, 5. 1系統測試的環境與方案 5. 2系統測試數據與過程 5. 4系統測試結果與分析第6章 結論系統不足之處和展望 1.4 論文主要內容寫作說明 1. 4.1緒論 緒論應是全文的濃縮,而摘要則是緒論的濃縮。緒論簡要說明系統設計開發的背景、從國內外相關領域以及用戶角度介紹有關的開發技術分析,采用技術的原因,需要多查詢一下資料,可以是專業知識知名網站,以及系統解決的主要問題和論文的重點工作等。每章節抽出幾個核心的工作,一般通俗的有關技術知識,在緒論中不必贅述。為了反映出作

10、者確已掌握了所從事軟件工程領域的堅實的基礎理論和寬廣的專業知識,具有開闊的科學視野,對研究開發方案作了充分論證設計,緒論應單獨成章,列為第一章,并用足夠的文字敘述。 1. 正文論文的正文主要包括需求分析、系統概要設計、系統詳細設計以及系統的實現與測試(如沒有測試,可不寫該部分)等部分。該部分是論文核心部分,占主要篇幅。正文必須實事求是,客觀真切,準確完備,合乎邏輯,層次分明,簡便可讀。正文應圖文并茂,對于工程性論文來說,沒有圖表、純文字描述的論文很難形成一篇好的文章 1. 需求分析部分在系統需求分析章節中,主要是為作者設計開發的一個新系統定義業務需求,主要回答的是 系統開發的用戶需要什么?什么

11、樣的需求導致了本系統的實施和開發?通過作者開發設計的系統用戶得到什么? 在系統概述中主要利用敘述、圖表等方式,概括性的描述系統的業務模型及有關業務流程現狀和總體要求;需求獲取模式部分主要介紹需求獲取的過程和相關的需求獲取采用的技術,如果需求獲取技術不占主要篇幅,沒有什么特色也可以簡寫,或與 4節合并;在需求問題描述中,重點要有較大的篇幅,主要從功能需求(funtional requirement)和非功能性需求(nonfuntional requirement)兩部分進行描述,其中功能需求主要描述作者開發設計的系統提供的活動和服務,重點是通過需求用例建模,其軟件制品表現為系統用例圖(use-a

12、se diagram)和系統用例場景或系統用例描述(use-ase narrative)。論文在該部分描述中,作者可根據自己開發設計系統功能包的大小,對系統的核心用例、有突破性的業務用例等重點進行用例描述,但避免全部在論文中羅列出來,作者可以用作為論文附件的形式進行附錄,在描述功能性需求時作者需要體現論文寫作設計的思想,不是把作者實際項目中所設計的全部用例以及用例描述都放在該部分內容章節里面,從而將論文寫成清單式的技術報告。非功能性需求主要描述作者開發設計的一個滿意系統的其他特征、特點和約束條件。非功能性需求的內容一般用非量化的指標來表示。作者在論文寫作中其表現形式可以為圖表的形式來展現。如:

13、 系統要求的可靠性指標(包括故障率、可恢復性和可維護性等),可以以補充性規格描述等方式描述,這部分也可以包含對開發環境的描述等。注: 該部分內容應該涉及和體現需求分析的主要分析文檔,如: 用例圖、業務流程圖等。 系統概要設計部分系統概要設計主要是描述設計開發的系統的總體框架,主要關注結構、模塊性、基本構件和主要控制流等方面,作者也要論述解釋架構視圖為何如此,在架構中作者要從某個角度觀察系統的窗口,只強調關鍵信息或想法,忽略其他。在這一章節中作者主要介紹設計架構要達到的目標和遵循的原則以及技術架構主要包括功能視圖、邏輯視圖、進程視圖、部署視圖、數據視圖、安全視圖、實現視圖等主要部分作者在寫該部分

14、內容過程中,如果沒有特色的內容可以適當進行一些論述,要對特色的重點部分進行論述,作者在寫作中要對所設計得到的每個架構圖表之前都要進行簡要的論述,闡明設計該圖表的方法,體現作者設計的思想,同時應體現作者完成該部分內容所應完成的工作量。各類視圖主要說明如下: 邏輯視圖: 最重要的層、子系統、包、框架、類、接口等概念性組織。概括了主要軟件元素的功能;展示了描述系統關鍵方面的重要用例場景;UP設計模型的視圖,是使用UML包、類和交互圖的可視化。進程視圖: 進程和線程。描述了他們的職責、協作以及分配給他們的邏輯元素;UP設計模型的視圖,是使用UML類圖和交互圖的可視化,其中使用了UML進程和線程表示法。

15、部署視圖: 進程和構件在處理節點上的物理部署以及節點之間的配置;UP部署模型的視圖,使用UML部署的可視化。數據視圖: 數據流、持久性數據模式、對象與持久性數據之間的模式映射,對象到數據庫、存儲過程以及觸發器的映射機制;UP數據模型的部分視圖,使用UML類圖的可視化用于描述數據模型;用UML活動圖表示數據流。安全視圖: 概述了安全模式和架構中實施安全的控制點;可以作為UP部署模型的視圖,使用UML部署圖的可視化,突出了關鍵安全控制點和相關文件。實現視圖: 實現模型;包含源代碼、可執行文件等;實現模型包括Web頁面、DLL、可執行文件、源代碼等;UP實現模型的視圖,用文字或者UML包圖和構件圖表

16、示。該部分內容有關知識請參閱Appling UML and Patterns(Seond Edition)第五部分,細化迭代 3,第32章,架構分析和SAD的介紹。對于框架(如持久性框架、交互框架等)也可以在這里描述。注: 在描述架構設計思想時體現設計模式,描述時還要注意的是不要用通用的結構,描述一定有具體的結構圖,最好有特色,有思想。 3. 系統詳細設計部分在該章節中作者主要根據UML模型圖中的靜態結構圖(如類圖、對象圖),類之間的關系、交互圖(順序圖、協作圖)和狀態圖(狀態圖、活動圖)來對系統進行詳細的描述。作為論文,作者不需要將系統所有上述內容進行細化描述,和在論文中進行羅列,要重點描述

17、設計的思想、設計方法、設計模式和設計理論,描述有特色的設計、有一定難度的設計和有一定復雜度的設計,其他可以作為論文附件進行附錄。同時作者要對系統數據庫進行有關的設計,包括表的設計,表關系的設計、OR轉換,持久性的問題,存儲問題。這部分設計主要描述設計中的問題,設計的方法,包括設計模式,以及設計的結果,描述為什么會得到這樣的設計,以及這樣設計的好處。注意: 描述的方法,對于同樣一個業務流程或操作的問題,在需求分析要用用例描述來描述,在設計中就要用順序圖或活動圖描述,在實現時就要用算法、流程圖或者偽代碼描述等,但同一業務或操作最好不要在各個部分描述。 4. 系統實現與測試部分作者在寫該部分內容時如

18、果從具體功能實現的角度描述,論文可能羅列太多,缺乏思想性。作者應重點從如下角度去挖掘該部分內容,首先從系統實現總體的角度用一節對系統的實現給出一個總體性的論述,并有適當的主要界面和2-4個主要的圖表,可以3-5頁;其次作者可以抽出關鍵的,復雜的功能算法實現,數據結構、數學模型、界面設計、交互設計、并發控制、性能設計、通訊協議,接口等分別進行一節的描述,可以以流程圖和偽代碼等形式進行描述,一定要避免大篇幅的代碼附寫在該部分章節內容中。在系統測試該部分內容中,如果作者的論文測試沒有特色就增加一節簡單的描述作為軟件開發過程的一個步驟,也可以不寫。如果作者的論文主要從測試角度來撰寫,可以按照軟件工程的角度來進行撰寫,把軟件測試按照一個項目進行組織管理,從測試背景、國內外測試相關技術、測試需求、測試方案和用例

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論