數據結構和演算法的論文

1. 分布式系統領域有哪些經典論文

分布式領域論文譯序
sql&nosql年代記
SMAQ：海量數據的存儲計算和查詢
一．google論文系列
1. google系列論文譯序
2. The anatomy of a large-scale hypertextual Web search engine (譯 zz)
3. web search for a planet :the google cluster architecture(譯)
4. GFS：google文件系統 (譯)
5. MapRece: Simplied Data Processing on Large Clusters (譯)
6. Bigtable: A Distributed Storage System for Structured Data (譯)
7. Chubby: The Chubby lock service for loosely-coupled distributed systems (譯)
8. Sawzall:Interpreting the Data--Parallel Analysis with Sawzall (譯 zz)
9. Pregel: A System for Large-Scale Graph Processing (譯)
10. Dremel: Interactive Analysis of WebScale Datasets(譯zz)
11. Percolator: Large-scale Incremental Processing Using Distributed Transactions and Notifications(譯zz)
12. MegaStore: Providing Scalable, Highly Available Storage for Interactive Services(譯zz)
13. Case Study GFS: Evolution on Fast-forward (譯)
14. Google File System II: Dawn of the Multiplying Master Nodes
15. Tenzing - A SQL Implementation on the MapRece Framework (譯)
16. F1-The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business
17. Elmo: Building a Globally Distributed, Highly Available Database
18. PowerDrill：Processing a Trillion Cells per Mouse Click
19. Google-Wide Profiling:A Continuous Profiling Infrastructure for Data Centers
20. Spanner: Google』s Globally-Distributed Database(譯zz)
21. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure(筆記)
22. Omega: flexible, scalable schelers for large compute clusters
23. CPI2: CPU performance isolation for shared compute clusters
24. Photon: Fault-tolerant and Scalable Joining of Continuous Data Streams(譯)
25. F1: A Distributed SQL Database That Scales
26. MillWheel: Fault-Tolerant Stream Processing at Internet Scale(譯)
27. B4: Experience with a Globally-Deployed Software Defined WAN
28. The Datacenter as a Computer
29. Google brain-Building High-level Features Using Large Scale Unsupervised Learning
30. Mesa: Geo-Replicated, Near Real-Time, Scalable Data Warehousing(譯zz)
31. Large-scale cluster management at Google with Borg
google系列論文翻譯集(合集)
二．分布式理論系列
00. Appraising Two Decades of Distributed Computing Theory Research
0. 分布式理論系列譯序

1. A brief history of Consensus_ 2PC and Transaction Commit (譯)
2. 拜占庭將軍問題 (譯) --Leslie Lamport
3. Impossibility of distributed consensus with one faulty process (譯)
4. Leases：租約機制 (譯)
5. Time Clocks and the Ordering of Events in a Distributed System(譯) --Leslie Lamport
6. 關於Paxos的歷史
7. The Part Time Parliament (譯 zz) --Leslie Lamport
8. How to Build a Highly Available System Using Consensus(譯)
9. Paxos Made Simple (譯) --Leslie Lamport
10. Paxos Made Live - An Engineering Perspective(譯)
11. 2 Phase Commit(譯)
12. Consensus on Transaction Commit(譯) --Jim Gray & Leslie Lamport
13. Why Do Computers Stop and What Can Be Done About It?(譯) --Jim Gray
14. On Designing and Deploying Internet-Scale Services(譯) --James Hamilton
15. Single-Message Communication(譯)
16. Implementing fault-tolerant services using the state machine approach
17. Problems, Unsolved Problems and Problems in Concurrency
18. Hints for Computer System Design
19. Self-stabilizing systems in spite of distributed control
20. Wait-Free Synchronization
21. White Paper Introction to IEEE 1588 & Transparent Clocks

22. Unreliable Failure Detectors for Reliable Distributed Systems
23. Life beyond Distributed Transactions:an Apostate』s Opinion(譯zz)
24. Distributed Snapshots: Determining Global States of a Distributed System --Leslie Lamport
25. Virtual Time and Global States of Distributed Systems
26. Timestamps in Message-Passing Systems That Preserve the Partial Ordering
27. Fundamentals of Distributed Computing:A Practical Tour of Vector Clock Systems
28. Knowledge and Common Knowledge in a Distributed Environment
29. Understanding Failures in Petascale Computers
30. Why Do Internet services fail, and What Can Be Done About It?
31. End-To-End Arguments in System Design
32. Rethinking the Design of the Internet: The End-to-End Arguments vs. the Brave New World
33. The Design Philosophy of the DARPA Internet Protocols(譯zz)
34. Uniform consensus is harder than consensus
35. Paxos made code - Implementing a high throughput Atomic Broadcast
36. RAFT:In Search of an Understandable Consensus Algorithm
分布式理論系列論文翻譯集(合集)
三．資料庫理論系列
0. A Relational Model of Data for Large Shared Data Banks --E.F.Codd 1970
1. SEQUEL：A Structured English Query Language 1974
2. Implentation of a Structured English Query Language 1975
3. A System R: Relational Approach to Database Management 1976
4. Granularity of Locks and Degrees of Consistency in a Shared DataBase --Jim Gray 1976
5. Access Path Selection in a RDBMS 1979
6. The Transaction Concept:Virtues and Limitations --Jim Gray
7. 2pc-2階段提交：Notes on Data Base Operating Systems --Jim Gray
8. 3pc-3階段提交：NONBLOCKING COMMIT PROTOCOLS
9. MVCC：Multiversion Concurrency Control-Theory and Algorithms --1983
10. ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging-1992
11. A Comparison of the Byzantine Agreement Problem and the Transaction Commit Problem --Jim Gray
12. A Formal Model of Crash Recovery in a Distributed System - Skeen, D. Stonebraker
13. What Goes Around Comes Around - Michael Stonebraker, Joseph M. Hellerstein
14. Anatomy of a Database System -Joseph M. Hellerstein, Michael Stonebraker
15. Architecture of a Database System(譯zz) -Joseph M. Hellerstein, Michael Stonebraker, James Hamilton
四．大規模存儲與計算(NoSql理論系列)
0. Towards Robust Distributed Systems：Brewer's 2000 PODC key notes
1. CAP理論
2. Harvest, Yield, and Scalable Tolerant Systems
3. 關於CAP
4. BASE模型：BASE an Acid Alternative
5. 最終一致性
6. 可擴展性設計模式
7. 可伸縮性原則
8. NoSql生態系統
9. scalability-availability-stability-patterns
10. The 5 Minute Rule and the 5 Byte Rule (譯)
11. The Five-Minute Rule Ten Years Later and Other Computer Storage Rules of Thumb
12. The Five-Minute Rule 20 Years Later(and How Flash Memory Changes the Rules)
13. 關於MapRece的爭論
14. MapRece：一個巨大的倒退
15. MapRece：一個巨大的倒退(II)
16. MapRece和並行資料庫，朋友還是敵人？(zz)
17. MapRece and Parallel DBMSs-Friends or Foes (譯)
18. MapRece:A Flexible Data Processing Tool (譯)
19. A Comparision of Approaches to Large-Scale Data Analysis (譯)
20. MapRece Hold不住？(zz)
21. Beyond MapRece：圖計算概覽
22. Map-Rece-Merge: simplified relational data processing on large clusters
23. MapRece Online
24. Graph Twiddling in a MapRece World
25. Spark: Cluster Computing with Working Sets
26. Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing
27. Big Data Lambda Architecture
28. The 8 Requirements of Real-Time Stream Processing
29. The Log: What every software engineer should know about real-time data's unifying abstraction
30. Lessons from Giant-Scale Services
五．基本演算法和數據結構
1. 大數據量，海量數據處理方法總結
2. 大數據量，海量數據處理方法總結(續)
3. Consistent Hashing And Random Trees
4. Merkle Trees
5. Scalable Bloom Filters
6. Introction to Distributed Hash Tables
7. B-Trees and Relational Database Systems
8. The log-structured merge-tree (譯)
9. lock free data structure
10. Data Structures for Spatial Database
11. Gossip
12. lock free algorithm
13. The Graph Traversal Pattern
六．基本系統和實踐經驗
1. MySQL索引背後的數據結構及演算法原理
2. Dynamo: Amazon』s Highly Available Key-value Store (譯zz)
3. Cassandra - A Decentralized Structured Storage System (譯zz)
4. PNUTS: Yahoo!』s Hosted Data Serving Platform (譯zz)
5. Yahoo!的分布式數據平台PNUTS簡介及感悟(zz)
6. LevelDB：一個快速輕量級的key-value存儲庫(譯)
7. LevelDB理論基礎
8. LevelDB：實現(譯)
9. LevelDB SSTable格式詳解
10. LevelDB Bloom Filter實現
11. Sawzall原理與應用
12. Storm原理與實現
13. Designs, Lessons and Advice from Building Large Distributed Systems --Jeff Dean
14. Challenges in Building Large-Scale Information Retrieval Systems --Jeff Dean
15. Experiences with MapRece, an Abstraction for Large-Scale Computation --Jeff Dean
16. Taming Service Variability,Building Worldwide Systems,and Scaling Deep Learning --Jeff Dean
17. Large-Scale Data and Computation:Challenges and Opportunitis --Jeff Dean
18. Achieving Rapid Response Times in Large Online Services --Jeff Dean
19. The Tail at Scale(譯) --Jeff Dean & Luiz André Barroso
20. How To Design A Good API and Why it Matters
21. Event-Based Systems:Architect's Dream or Developer's Nightmare?
22. Autopilot: Automatic Data Center Management
七．其他輔助系統
1. The ganglia distributed monitoring system:design, implementation, and experience
2. Chukwa: A large-scale monitoring system
3. Scribe : a way to aggregate data and why not, to directly fill the HDFS?
4. Benchmarking Cloud Serving Systems with YCSB
5. Dynamo Dremel ZooKeeper Hive 簡述
八. Hadoop相關
0. Hadoop Reading List
1. The Hadoop Distributed File System(譯)
2. HDFS scalability:the limits to growth(譯)
3. Name-node memory size estimates and optimization proposal.
4. HBase Architecture(譯)
5. HFile：A Block-Indexed File Format to Store Sorted Key-Value Pairs
6. HFile V2
7. Hive - A Warehousing Solution Over a Map-Rece Framework
8. Hive – A Petabyte Scale Data Warehouse Using Hadoop

轉載請註明作者：phylips@bmy 2011-4-30

2. 怎樣寫計算機應用技術的畢業論文

計算機應用技術的畢業論文怎麼寫?學術堂給了九條建議:

1、寫論文是個系統工程.跟寫paper不一樣,所以從一開始就要有個整體思維和計劃,比如文獻管理,文獻索引,數據管理,表格圖片管理等等.建議一開始就建立一個文件夾,裡麵包括各個方面的子文件夾,分門別類,系統管理,事半功倍.

2、寫作講究一氣呵成.看很多人寫論文,今天寫了半頁,明天寫了幾百字,痛苦至極.寫之前莫不如先思考,理清思路,然後再動筆.有時候寫順了,一兩天寫出一個paper來都不奇怪.

3、不要期待一稿定乾坤.寫論文最重要的是第一稿,因為從無到有是最艱難的,第一稿出來之後再修改,無論修改意見多麼尖銳和繁多,都不會太難.俗話說百煉成鋼,論文也一樣,往往最終稿跟第一稿相比總是面目全非的.所以,對於第一稿,要快,而不是要精.

4、不要著急生成bibliography文獻列表.因為這個文獻列表一旦插入進來,在改動的時候總會一遍又一遍的更新,有的時候word也會崩潰,導致論文保存不當或者丟失.如果用endnote之類的軟體,寫的時候,在插入文獻的地方用{作者名,年份等信息},最後一起生成列表就好.

5、論文跟paper的思路還是有區別的.對於論文來說,精煉並不是最主要的要求,詳實最重要.而對於paper,精煉最重要,因為雜志往往有字數限制而且精煉的文字會更被雜志青睞.所以,在寫論文的時候,一定要力求詳盡,尤其是第一稿,之後修改的時候可以略作刪減.

6、你總會發現,word會時不時"出問題".比如目錄格式為什麼總不對,為什麼目錄"只更新頁碼"的選項沒有了,橫頁上怎麼在左邊插入頁碼,頁腳的頁碼如何自定義,如何區分插入分頁符和分節符等等.記住,一旦遇到類似問題,要第一時間弄清楚並解決.不是Word設計的有問題,是你還不會使用它.大部分時候,網上搜一下問題就解決了.這樣這些問題就不會在後期困擾你.

7、及時與導師溝通論文的寫作進度和要求.每個導師都有不同的習慣,比如我在香港的導師非全稿不看,而現在的德國老闆讓我寫完一章她就改一章.最終質量控制都在導師手裡,所以溝通最重要.

8、把論文當做你嚴謹科研的起點.大家都知道,論文沒人看,就算最後存檔在圖書館,可能永遠也沒有人看.但是,論文的寫作過程中收獲是寫paper無法比擬的,論文寫作的機會不多,也就是說,系統寫一個作品的機會不多(那些可以出書的大牛略過哈).寫paper多了,你會發現其實paper很好寫,都是一個套路,論文則不然,論文太多系統的東西,方方面面十分廣泛.所以,如果你將來真的打算做一個嚴謹的科學工作者,那麼請認真的寫好你的論文,就算它將來沒有人翻閱.而且論文往往很長,而大部分都不願意讀自己寫的東西,以至於論文很多地方可能自己都沒有讀過.

9、論文文件命名.這是個小問題,每個人可能習慣都不同.我有個小建議,就是用論文名稱_Version No._年月日.比如AAA and BBB_V2_20130501.這里版本號很重要.有時候我們經常只放時間,但是到頭來你會發現其實時間不重要,因為最終你瀏覽文件夾肯定要按照修改時間排序,而且很多時候去找以前的文件,時間你已經記不清了.這樣版本就很有用,第一版是初稿,第二版是改過一次的,以此類推.當然,在時間後面還可以加上修改人的名字,證明是誰改過的等等.

3. 誰有數據結構演算法演示的畢業論文

多數論文存在著兩條或兩條以上的線索。如《藤野先生》，文章除了以作者與藤野先生交往為敘事線索（明線）外，還有作者愛國主度思想感情這一暗線。
記敘的順序要求掌握的是順敘、倒敘、插敘三種。順敘指記敘的時候按照事情發生、發展、和結局的順序來寫，前因後果、條理很清楚

4. 求一篇關於 軟體體系結構分析 的論文

軟體體系結構論文：一種面向方面軟體體系結構模型
摘 要: 為了分離軟體系統中的核心關注點和橫切關注點，通過引入面向方面軟體開發的思想設計了一種面向方面軟體體系結構模型，並詳細分析了該模型的三個基本構成單元，即構件、連接件和方面構件。最後通過一個網上支付實例驗證了該模型具有一定的理論意義和實用價值。
關鍵詞: 面向方面軟體體系結構;橫切關注點;構件;連接件;方面構件
20世紀60年代的軟體危機使得人們開始重視軟體工程的研究。起初，人們把軟體設計的重點放在數據結構和演算法的選擇上，然而隨著軟體系統規模越來越大，對總體的系統結構設計和規格說明變得異常重要。隨著軟體危機程度的加劇，軟體體系結構(software architecture)這一概念應運而生。軟體體系結構著眼於軟體系統的全局組織形式，在較高層次上把握系統各部分之間的內在聯系，將軟體開發的焦點從成百上千的代碼上轉移到粒度較大的體系結構元素及其交互的設計上。與傳統軟體技術相比，軟體體系結構理論的提出不僅有利於解決軟體系統日益增加的規模和復雜度的問題，有利於構件的重用，也有利於軟體生產率的提高。面向方面軟體開發(AOSD)認為系統是由核心關注點(corn concern)和橫切關注點(cross-cutting concern)有機地交織在一起而形成的。核心關注點是軟體要實現的主要功能和目標，橫切關注點是那些與核心關注點之間有橫切作用的關注點，如系統日誌、事務處理和許可權驗證等。AOSD通過分離系統的橫切關注點和核心關注點，使得系統的設計和維護變得容易很多。
Extremara大學的Navasa等人［1］在2002年提出了將面向方面軟體開發技術引入到軟體體系結構的設計中，稱之為面向方面軟體體系結構(aspect oriented software architecture，AO-SA)，這樣能夠結合兩者的優點，但是並沒有給出構建面向方面軟體體系結構的詳細方法。
盡管目前對於面向方面軟體體系結構這個概念尚未形成統一的認識，但是一般認為面向方面軟體體系結構在傳統軟體體系結構基礎上增加了方面構件(aspect component)這一新的構成單元，通過方面構件來封裝系統的橫切關注點。目前國內外對於面向方面軟體體系模型的研究還相對較少，對它的構成單元模型的研究更少，通常只關注方面構件這一構成單元。方面構件最早是由Lieberherr等人［2］提出的，它是在自適應可插拔構件(adaptive plug and play component，APPC)基礎之上通過引入面向方面編程(AOP)思想擴展一個可更改的介面而形成的，但它關於請求介面和服務介面的定義很模糊，未能給出一個清晰的方面構件模型。Pawlak等人［3］提出了一個面向方面的框架，該框架主要包含了一個方面構件模型———java方面構件(Java aspect component，JAC)，但該方面構件模型僅包含了切點(pointcut)，並把AOP中裝備(advice)集成到了切點的表達式中，它主要從實現的角度進行了闡述，並沒有給出詳細的方面構件模型。本文沒有隻關注面向方面軟體體系結構中方面構件這一構成單元模型，還詳細分析了它的另外兩個構成單元，即構件和連接件，因為面向方面軟體體系結構各部分之間是相互關聯的。
1面向方面軟體體系結構相關概念
面向方面軟體體系結構涉及諸多概念，以下將分別介紹。軟體體系結構在軟體工程領域有著廣泛的影響，但當前仍未形成一個統一的、標準的定義。目前國內外普遍認可的看法是軟體體系結構包含構件、連接件和約束［4］。其中約束描述了體系結構配置和拓撲的要求，確定了體系結構的構件與連接件的連接關系。這樣就可以把軟體體系結構寫成
軟體體系結構(software architecture)=構件(components)+
連接件(connectors)+約束(constraints)
構件是軟體體系結構的基本元素之一。一般認為，構件是指具有一定功能、可明確辨識的軟體單位，並且具備語義完整、語法正確、有可重用價值的特點，然而目前對於構件的具體結構及構成並沒有一個統一的標准［5］，而且一些主要的構件技術也沒有使用相同的構件類型。另外，當前被廣泛接受的構件定義並不包含具體的軟體構件模型(software component model)。例如，Szyperski等人［6］給出了軟體構件一個很有名的定義:軟體構件是一個僅帶特定契約介面和顯式語境依賴的結構單位，它可以獨立部署，易於第三方整合。但是關於軟體構件模型有一個被普遍接受的觀點是:軟體構件是一個具有服務提供和服務請求功能的軟體單元［7］。
連接件是軟體體系結構另一個基本的構成元素，是用來建立構件間交互以及支配這些交互規則的構造模塊。連接件最先是由Shaw［8］提出來的，她建議把連接件作為軟體體系結構中第一類實體，用來表示普通構件之間的交互關系。目前對於連接件尚未形成統一的認識，盡管在軟體體系結構中強調了連接件存在的必要性，但是關於連接件模型的研究還很少，連接件的實際應用還不成熟。
面向方面軟體體系結構在傳統軟體體系結構的基礎上增加了方面構件單元。通常認為，方面構件是封裝了系統橫切關注點的一類特殊的構件。目前關於方面構件模型的研究還處於起步階段。
2面向方面軟體體系結構模型
由於傳統軟體體系結構模型包含構件、連接件和約束，而面向方面軟體體系結構是在傳統軟體體系結構的基礎之上擴展了方面構件，所以面向方面軟體體系模型結構包含構件、連接件、方面構件和約束。其中約束描述了面向方面體系結構配置和拓撲的要求，確定了體系結構的構件、連接件和方面構件之間的連接關系，而構件、連接件、方面構件是它的三個基本的構成單元。以下對這三個構成單元的模型進行詳細的設計。
2.1構件模型
構件模型由以下幾個要素構成(圖1):
(a)埠。
構件的服務請求和服務提供功能是通過埠來實現的。埠是構件與外部環境進行交互的惟一通道。一般的構件模型通常採用兩種埠，即雙向埠和單向埠。在使用雙向埠的構件模型中，服務請求和服務提供功能可以在同一個埠中實現。本文中的構件模型使用單向埠，此種埠分為請求埠和服務埠兩種類型。
(a)服務埠。構件通過服務埠向其他構件提供服務。構件通過服務埠向其他構件的請求消息進行應答，返回響應消息。每個服務埠對應一個介面。
(b)請求埠。構件通過請求埠向其他構件請求服務。構件為了實現自己的業務功能，需要通過請求埠向其他構件發送請求消息。每個服務埠也對應一個介面。
(b)介面。
它定義了一個到多個業務功能。這些業務功能由服務埠進行提供，並由請求埠進行使用。一個介面限定了一個特定埠可以進行的交互功能，介面是構件間交互的契約。通常的介面類型有:Java Interface、WSDL 1．1 portTypes和WSDL 2．0 Interfaces等，也可以自定義介面類型。
(c)屬性。
與類或對象相似，構件也具有屬性，屬性可以在構件使用前進行配置，它能夠反映構件在交互過程中狀態的變化。
2.2連接件模型
連接件是用來建立構件間交互以及支配這些交互規則的體系結構構造模塊。連接件為構件間信息交互提供傳輸和路由服務。在最簡單的情況下，構件之間可以直接完成交互，這時體系結構中的連接件就退化為直接連接。在更為復雜的情況下，構件間交互的處理和維持都需要連接件來實現。對於構件而言，連接件是構件的粘合劑，是構件交互的實現，也可以看做是一種特殊的構件［8］。與構件相似，連接件也具有埠。連接件的埠可分為兩種類型，即源埠(source port)和目標埠(target port)。源埠用於接收構件請求埠中的消息，目標埠用於向構件服務埠中輸入消息。連接件通常需要使用一種合適的綁定(binding)機制，構件的請求埠使用這種綁定機制來描述服務請求的方法，構件的服務埠也使用這種機制來描述構件進行請求的方式。常用的綁定機制有:WebService Binding和JMS Binding等，也可以自定義綁定機制。與構件一樣，連接件也具有屬性，來表示構件間交互的狀態變化，如圖2所示。

2.3復合構件模型
構件可分為兩種，即原子構件和復合構件。前者是不可再分的構件。後者是可再分構件，它封裝了若干個子構件。子構件間通過連接件相互連接，且子構件的埠也可以暴露成為復合構件的埠，子構件也可能是復合構件。如圖3所示:復合構件A包含兩個子構件B和D，子構件B和D通過連接件C進行相連，構件B的服務埠E暴露成為復合構件A的服務埠F，其請求埠G暴露成為A的請求埠H。
2.4方面構件模型
方面構件是面向方面軟體體系結構的一個核心的構成單元，它封裝了橫切關注點，這是與傳統軟體體系結構最大的不同之處。圖4給出了方面構件模型，與普通構件一樣，方面構件也有服務埠和請求埠以及屬性，但是它還有普通構件所沒有的方面埠。當一個構件具有一個方面埠時，即可認為此構件就是方面構件。一個方面埠中包含若干個方面，這與一般面向方面編程(AOP)技術中方面概念有所不同。面向方面編程具有以下四個基本概念:方面(aspect)、連接點(joinpoint)、通知(advice)和切點(pointcut)。連接點是應用程序執行過程一個定義明確的位置，如方法調用是一種典型的連接點。切點是一系列連接點的集合，是方面的作用點。通知表述了在切點所選定的連接點處要執行的動作，常見通知類型有before、around和after等，分表代表在連接點之前、連接點附近和連接點之後執行相應的通知代碼。方面是用來描述和實現橫切關注點的基本單位，由切點和通知構成。方面埠中的方面橫切關注的是構件，這與一般AOP(如AspectJ)橫切關注的對象(object)不同，由於構件能夠表達對象所不能表達的請求服務的能力［9］，這使得方面埠中方面所採用的連接點模型和切點語言具有很大的不同。

2.4.1連接點模型
該連接點模型包含兩種不同類型的連接點，即構件服務埠中的服務提供操作和請求埠的服務請求操作。由於構件的內部結構通常被視為黑盒，因此連接點模型應該僅考慮構件的外部可見元素，如構件請求埠和服務埠中的服務操作。如果連接點模型包含構件的屬性，那麼它將會破壞構件的分裝性。
2.4.2切點語言
用來選用連接點的切點語言基於切點表達式，表1給出了切點的五個組成部分，即component、jp_type、port、interface和service，然後分別對其進行了說明。其中，jp_type代表選用的連接點類型，可以是請求埠中的服務、服務埠中的服務或所有埠中的服務，詳細如表1。表2給出了切點語言的一些例子，其中正則表達式基於java．util．regexp包。

2.5面向方面軟體體系結構模型
面向方面軟體體系結構由構件、連接件、方面構件組成，詳細請參見圖6。

3基於面向方面軟體體系結構模型的網上支付實例
近年來，網上購物發展迅速，網上支付是消費者主要的支付手段之一，圖7給出了基於面向方面軟體體系結構的網上支付模型，它由四個原子構件，即一個復合構件、兩個方面構件和三個連接件組成。其中WebClientComponent代表客戶端構件，它可以向網上銀行構件WebBankComponent請求AccountService()服務，該服務有三個參數，即username、password、cost，分別對應於用戶的網上銀行賬戶名、密碼及購買商品的消費金額。
〈component name="WebClientComponent"〉〈required．port name="WebClientRequest"〉
〈java．interface interface="AccountServiceInterface"〉〈service name="AccountService()"〉
〈param name="username"type="string"/〉
〈param name="password"type="string"/〉
〈param name="cost"type="float"/〉
〈/service〉〈/java．interface〉
〈/required．port〉
〈/component〉
連接件AccountServiceConnector用於連接客戶端構件和網上銀行構件，它採用WebServiceBinding綁定機制。
〈connector name="AccountServiceConnector"binding="WebServi-ceBinding"/〉
〈source name="S"/〉〈target name="T"〉
〈/connector〉
〈connect．source from="WebClientComponent．WebClientRequest"to="S"/〉
〈connect．target from="T"to="WebBankComponent．Bank-Re-sponse"/〉
網上銀行構件是一個復合構件，由賬戶服務構件Account-ServiceComponent、賬戶資料庫連接件AccountDBConnector和賬戶資料庫構件AccountDBComponent組裝而成。其中該復合構件的服務埠也使用介面AccountServiceInterface，這是為了兼容客戶端構件請求埠使用的介面。
身份驗證構件AuthenticationComponent用於驗證用戶的身份信息，它通過UserInfoConnector連接件訪問用戶信息資料庫構件UserInfoDBComponent。
pointcut="WebBankComponent;BankResponse;AccountServiceInterface;AccountService()"
是該方面構件的方面埠中使用切點的表達式。
為了保證資料庫構件UserInfoDBComponent和AccountDB-Component的安全性，方面構件SecurityComponent使用方面埠Security監視這兩個構件的服務埠，使得在這兩個構件服務調用之前增加日誌和事務功能，而日誌和事務功能在系統中通常表現為橫切關注點，面向方面軟體體系結構能夠對它進行很好的封裝，便於設計和維護。
〈aspect．component name="SecurityComponent"〉〈aspect．port name="Security"〉〈aspect〉〈pointcut="UserInfoDBComponent;UserInfoResponse;*;*|Ac-countDBComponent;AccountDBResponse;*;*"/〉〈advice．role="before"action="Log()"/〉〈advice．role="before"action="Transaction()"/〉〈/aspect〉〈/aspect．port〉〈required．port name="UserInfoRequest"/〉〈/aspect．component〉
4結束語
本文給出了一種面向方面軟體體系結構模型，詳細設計了它的三個基本構成單元模型，即構件、連接件和方面構件;最後通過一個網上支付實例驗證了該模型有效性和實用性，為面向方面軟體體系結構的實際應用奠定了一定的基礎。筆者將繼續完善該模型的相關理論，研究面向方面軟體體系結構的工程化應用方法。
參考文獻:
［1］FABRESSE L，DONY C，HUCHARD M．Foundations of a simpleand unified component-oriented language［J］．Journal of ComputerLanguages，Systems＆Structures，2008，34(2-3):130-149．
［2］LIEBERHERR K，LORENZ D，MEZINI M．Programming with as-pectual components，T R NU-CSS-99-01［R］．［S．l．］:NoutheastamUniversity，1999．
［3］PAWLAK R，SERNTURIER L，DUCHIEN L D，et al．JAC:an as-pect-based distributed dynamic framework［J］．Software Practiceand Experiences，2004，34(12):1119-1148．
［4］李千目．軟體體系結構設計［M］．北京:清華大學出版社，2008．
［5］馬亮，孫春艷．軟體構件概念的變遷［J］．計算機科學，2002，29(4):28-30．
［6］SZYPERSKI C，GRUNTZ D，MURER S．Component software:be-yond object-oriented programming［M］．2nd ed．［S．l．］:Addison-Wesley，2002．
［7］LAU K K，WANG Z．Software component models［J］．IEEE TransSoft Eng，2007，33(10):709-724．
［8］SHAW M．Procere calls are the assembly language of software in-terconnection:connectors deserve first-class status［C］//Proc of InICSE Workshop on Studies of Software Design．1993:17-32．
［9］NAVASA A，PREZ M A，MURILLO J M，et al．Aspect orientedsoftware architecture:a structural perspective［C］//Proc of Workshopon Early Aspects．2002．

5. 計算機論文如何寫

首先是選題，一般老師都會提供若干個選題給你選，其中必然包括幾個「XX系統的設計與開發」，這樣的選題就是符合我們前面的假設和預想的。盤他！假設我現在選了一個題目是「基於SSM的XX網上商城的設計與開發」。

選完題目就面臨著一個問題：是先做開發還是先寫文章，或者是一邊寫一邊開發。我的建議是一邊寫一邊開發。原因是：開發的過程是需要寫一些文案的，比如需求分析、資料庫的表結構的關系、整個系統的交互邏輯等等。而這些文案是可以出現在我們的論文當中的。

那接下來就說一下如何開發和寫文論，當然某些開發過程我只能粗略的說一下。

1.摘要：

這是所有論文的第一個小title，說他惡心有時候也惡心，說他簡單也是蠻簡單的。那麼這一部分究竟是要寫什麼的？由於這一部分需要展現出做這個系統的必要性、開發這個系統的實現方式、系統的功能和系統的作用。所以可以這樣寫：

隨著中國經濟的高速發展以及網路技術的普及，互聯網的技術得到全面的發展，中國的各行各業都在互聯網的影響下發生了變革。互聯網的快速發展催生了許多產業，其中最具代表性的便是電子商務，電子商務使得企業和客戶的營銷關系由實體店銷售准換為網路電子商務營銷。馬雲曾說：「讓天底下沒有難做的生意」，越來越多的店家選擇在網上開店，使得交易不再限制於天南地北，同時也大大降低了店家的經營成本，在提高收益的同時，也方便了客戶，本課題正式在這種背景下應運而生。

本課題介紹了「基於SSM的XX網上商城」的開發環境、需求分析、界面設計和資料庫設計以及涉及到的框架。

本系統採用了B/S架構，使用了Java、HTML、JS等語言，使用了主流的後台開發框架SSM(spring+springMVC+Mybatis)，以及採用了開源的輕量級資料庫Mysql進行開發，為網路商城提供了前端展示和後台管理的模塊，實現了注冊、登錄以及購物等主要功能，為消費者提供了便捷快速的購物體驗，以及為提高了店家的銷售效率。

關鍵字：網上商城，SSM，Java，HTML，JS，MySQL

（關鍵字一般就是把摘要中提及到的關鍵性技術提取出來，讓閱讀者一目瞭然，知道哪些是重點）

Abstract：......

（英文摘要建議谷歌翻譯，然後把明顯錯誤的地方修改一下即可）

2.第一章：引言

這一部分也是比虛的，其實隨便扯一扯就可以了，一般包含以下幾部分1.背景2.研究內容。其中背景主要講一些關於社會發展的趨勢導致了一些什麼問題，而這些問題又應該如何去解決，多說幾句，寫到兩三百字即可。研究內容就是針對上述的背景我們如何進行改進。細心的同學可能會說，感覺跟摘要有些重復。是的！這兩部分內容其實是挺重復的，但是沒關系，不過不要使用完完全全一樣的話去描述，因為最後論文查重的時候會對文章自引用進行查重的。這一部分也是三五百字即可。

3.第二章：系統的開發技術介紹

這一部分是需要我們在正式開發之前做好的技術調研，然後對這一部分的技術進行詳細的介紹。這一部分我不可能細講，因為內容太多了，而且對於不同的項目有不同的內容，在查閱資料的過程也是提升技術的一個重要的環節，你可以真真切切的了解到開發一個工程是需要哪方面的知識，因此我就對我所選的這個課題應該使用到的技術棧進行一下介紹，也算是拋磚引玉，各位同學可以根據自己的實際情況進行撰寫。

開發不同的系統雖然涉及到的業務邏輯不同，處理方式也千差萬別，但是本質上都是一樣的，都是前端界面通過伺服器跟資料庫進行數據交互的一個過程，涉及到的內容也無非就是前端、後台和伺服器。但是有一個需要注意的點，就是不要把HTML、JAVA等使用的語言介紹也給堆在這里，老師沒細看還好，細看還是會顯得太水字數了，記住，寫工程性的課題不怕沒字數。那問題來了，語言介紹不給寫那應該些什麼呢？應該寫涉及到的框架、使用的工具。這些就夠了，隨隨便便就幾千字了。下面舉例簡單說明一下。

a. 前端

強調一下，不要把HTML、CSS等一下前端的規范展開來寫，可以輕描淡寫，但篇幅不能過多。這里可以寫前端框架的使用，比如使用npm管理包（可以介紹一下npm以及在工程中的使用）、vue的使用（同樣可以介紹vue框架以及應用）、element（element以及使用他的好處）等等。也希望同學在做畢設的過程中要真的去了解這些技術並且去使用它，相信我，看完再去用你的技術會有質的飛躍。

b. 後台

這一部分是重點，對於本課題來說，標題就寫了是基於SSM的。對於這個java框架並不熟悉的同學來說建議先去查一下資料，而且很多同學會有疑問，使用技術框架的目的就是為了讓開發更加的便捷和快速，但是為什麼我們自己在開發的過程中會感覺好像變得更加復雜？很負責任的告訴你，是正常的。因為框架不僅會幫我們封裝好一些常用的方法，而且會考慮到更新迭代以及代碼可讀性等等的一系列的問題，某些規定和配置我們之所以沒有感受到他的好處是因為這種校園內的開發並不涉及生產問題，也不會有很多的更新迭代，更加不會考慮到代碼的可讀性。例如spring的工廠，一開始使用的時候很多同學會覺得為什麼我new一個類的時候還要去改配置文件，直接new不香嗎？直接new是很香，但是你考慮到真正去工作的時候，假設你要改類的一些關系的時候，還要去改代碼，當工程一大，代碼去哪裡找呢？一個一個文件看嗎？顯然是非常不可取的，效率非常低，這個時候配置文件的優勢就發揮出來了，直接修改配置文件，不需要更改代碼，耦合性也大大的降低。好像跑題了，說了這么多就告訴同學們，要沉住氣，理解框架這樣設計背後的原因，對大家自身技術的提高非常的有幫助！

那這一部分我們就可以介紹spring（包括spring的IOC、spring的工廠、spring的AOP等等，並且可以在論文中強調如何應用到我們的系統當中）、springMVC（這一部分可以講解srpingMVC作為一個連接前端和資料庫的工具在實際工作過程中的具體流程，也可以講述springMVC的分層的概念以及如何應用）、Mybatis（包括跟JDBC的關系、mybatis依賴的配置、使用到的介面、動態代理、一級緩存和二級緩存以及延遲載入等等的一些技術問題）

c. 伺服器和資料庫

這一部分可以介紹一下用來搭建伺服器的工具和所使用的資料庫。假設你是使用了雲伺服器來搭建了，可以詳細介紹一下雲伺服器的搭建過程包括防火牆、埠等等內容。一般伺服器使用tomcat進行搭建，可以把tomcat介紹一下並且介紹一下tomcat是如何監聽和解析用戶請求的具體流程。

一般小型的項目採用MySQL作為資料庫，可以詳細說一下選擇MySQL的原因，比如相對於Oracle的好處。可以介紹一下MySQL資料庫的一些特點包括分頁、是否支持事務等等。

4.第三章：需求分析

這一部分是針對具體的業務場景來分析需要開發哪些功能，這一部分可以讓你感受一下產品經理的職責，只不過不需要跟程序員對接，因為你自己就是程序員哈哈。一般來說分成兩部分就可以了，一部分是對於前端的業務流程，另一部分就是後台伺服器的業務流程，可以使用一些軟體來繪畫流程圖，想圖個方便可以直接使用word自帶的圖形進行編寫，也不至於難看，就比較簡約。想做的好看點的話個人推薦使用xmind，非常簡單，可以快速做出美觀的流程圖。如果沒有什麼思路，那前端就按照著使用者的邏輯去寫，比如用戶需要注冊、登錄、找回密碼、購物、退貨等操作，那後端就對應著這些前端邏輯需要有相應的業務處理。個人感覺這一部分比較好寫，就不再贅述。

5.第四章：系統的設計和實現

這一部分可以挑選一些有代表性的功能出來細講，有些同學可能會有疑問，論文可不可以貼代碼呢？答案是可以的。但是我個人的建議是貼偽代碼，不要把你寫的長篇大論的代碼全部放進去，不好看而且邏輯混亂，應該做的是把代碼抽取為偽代碼，貼代碼的目的是為了讓閱讀者清晰地讀懂你是如何實現這個功能的，他並不會在意你的語法你的命名。下面列舉若干個可以寫的內容，並不限於此。

a. SSM框架的整合。如何使用Spring來整合並且管理SpringMVC和Mybatis.

b. 客戶登錄狀態保存的實現。這一部分可能會涉及到cookies，sessions以及http報文解析等等，都可以詳解。

c. 後台商品管理的功能。這一部分可以根據管理員的後台管理功能進行描寫。

d. 商品搜索功能。可以涉及到資料庫的模糊搜索。

e. 資料庫表格的設計。可以體現資料庫表格設計的時候如何遵守三範式。

f. 可以寫在開發過程中遇到的一些疑難雜症。

g. 可以寫開發過程中使用到的一些比較具有亮點的語言特性。比如java的多線程、lambda表達式。又比如實現注冊功能的時候使用的正則表達式。

……

等等數不勝數。

6.第五章：運行結果

這一部分非常好寫了。截取一些關於你的系統的界面並且介紹一下功能，盡量說詳細點，就ok了。

7.第六章：總結以及展望

這一部分也是比較水的一部分，但是也希望同學們認真寫一寫。可以寫一下你開發這個項目的過程中學習到了什麼，可以是XX技術，也可以是艱苦奮斗的精神……。展望可以寫有望發展成另外一個淘寶……開玩笑開玩笑，總之劈里啪啦湊個幾百字即可。

8.參考文獻

把你開發過程中參考過的文章、論文貼進去之後，往往會發現參考文獻不夠，太少了！那怎麼辦呢？那就貼一些關於使用的技術的文章或者參考手冊咯，雖然大部分是沒看過的，但是還是希望大家可以多少看一看（正義之氣躍然紙上）。去知網查找參考文章然後添加到你的參考文獻是非常方便的，只需要找到對應的文章並且選擇「引用」功能，即可自動生成引用的文字，直接復制到你的論文中。

9.致謝

第一步，感謝你的導師，感謝你的院領導，感謝你的校領導。說的好聽後可能答辯的時候不會太為難你……然後你要感謝你的家人你的舍友你的朋友或者是你家的狗（開玩笑），都可以的，這一部分又輕輕鬆鬆兩百字。

至此，一篇計算機論文就寫完了，是不是覺得挺簡單的呢？以上內容皆由學術堂提供整理。

6. 電子信息工程 畢業論文（設計）

畢業論文 (設計)指導書

（適用於2007屆電子信息工程、計算機控制專業）
目 錄
畢業論文（設計）任務書

一．畢業論文（設計）的目的和任務
二．畢業論文（設計）的程序和步驟
三．畢業論文（設計）的結構與要求
四．畢業論文（設計）的指導工作及對學生的要求
五．畢業論文（設計）與答辯的時間安排
六．畢業論文（設計）成績的評定
七．畢業論文（設計）參考選題
八．附件

山東水利職業學院 信息工程系
2007屆學生畢業設計(論文)任務書
指導教師 職 稱 需要學生人數及專業
課題名稱
課題內容及意義
對學生的要求
進度安排
參考文獻
備註：學生分為計算機應用、電子信息、網路技術、計算機控制等專業。
一．畢業論文（設計）的目的和任務
根據國家教育部的要求，高等學校畢業生在畢業前要進行撰寫論文或進行畢業設計（統稱畢業環節），這是高等教育不可或缺的一個重要環節。畢業環節注重理論與實踐相結合，將課堂學到的知識與實際工作中的問題結合起來，培養學生解決實際問題的能力，同時也增強了學生適應實際工作的能力，是邁向實際工作崗位前的一次重要演練。
通過畢業論文（設計），使學生運用所學的軟、硬體知識，獨立分析解決計算機應用的實際問題，掌握應用軟體開發的基本模式和步驟，以達到將理論知識學以致用、融會貫通的目的。
學生論文（設計）要完成的任務是：
1．根據所選畢業論文（設計）的題目，到各有關單位進行現場實習和調研，搜集並整理有關資料、文獻。
2．根據實習和調研所掌握的資料，對論文（設計）題目中所涉及的問題進行分析論證，提出見解，編寫應用程序，最終完成論文（設計）。
二．畢業實習與論文（設計）的程序和步驟：
畢業論文（設計）的工作大致可分為如下階段：
（一）選題階段
根據給出的論文題，按自身的理解和對題目的熟悉程度，填報論文題目，學生也可自行選擇未給出的論文題。學生須明確所選題目的要求及深度。學校根據學生填報的畢業論文（設計）志願，在綜合評定後，最終確定學生的論文題目，並指定指導教師。自選題須經指導教師認證。
（二）撰寫論文階段
在教師的指導下，對所選題目目前的狀況及用戶的要求進行需求分析，提出解決方案，畫出系統流程圖，編寫程序，進行上機調試，最終完成論文（設計）。
（三）畢業答辯階段
學生按期做完畢業論文（設計）後，交給指導教師審閱，教師要寫出審閱意見，並在論文上簽字。在沒有特殊情況下，學生均須進行畢業答辯。
答辯按以下程序進行：
1．學生向答辯委員會報告本人論文的主要內容；
2．答辯委員會和參加老師對論文提出問題；
3．學生對所提問題進行答辯；
4．答辯委員會給出答辯成績。
三．畢業論文（設計）的結構與要求
◆畢業論文或畢業設計報告字數不少於12000字
◆畢業論文（設計）任務書
◆目錄
◆中文摘要
◆英文摘要（Abstract）（可選）
◆前言：本課題研究的意義、國內外相關課題的狀況介紹等。
◆系統的需求分析：系統需求、本課題任務及目的等。
◆系統開發工具：本課題使用的軟體工具介紹等。
◆系統設計與開發：本課題程序結構、數據結構、演算法、系統開發流程、主要模塊及其原程序注釋、遇到的問題及解決方案等。
◆代碼調試與系統測試：應用程序測試、系統測試等。
◆總結：系統的功能、使用說明、存在的問題、收獲和體會等。
◆附錄
◆參考文獻
四、畢業論文（設計）的指導工作及對學生的要求
（一）指導教師的主要工作
指導學生擬定論文進度，布置給學生應完成的工作並檢查其執行情況，每周至少半天時間對所帶學生進行指導。引導學生擬定論文提綱，幫助學生分析論文所涉及的問題，對方案的可行性、流程的正確性、程序的嚴謹性等進行審查，並提出意見，做好論文的審閱和學生的釋疑工作。
（二）對學生的要求
1、擬定個人工作計劃，搜集、閱讀、分析、整理有關資料；
2、復習有關專業理論及編程需用的程序語言，做好實習、撰寫論文准備工作。
3、在畢業環節過程中，要嚴肅認真，積極主動，獨立思考，努力鑽研。對論文內容要充分理解和把握，要有自己的獨立見解，不應簡單抄襲資料。做好答辯的准備工作。
4、遵守實習、勞動紀律，注意安全。服從教師指導，虛心向實習單位的工作按質、按量、按期完成畢業論文。
五．畢業論文（設計）與答辯的時間安排
序號 專業名稱 畢業設計時間 備注
1 電子信息專業（04級普通、對口） 第10周～第18周(2007.5.7~2007.7.6)
2 計算機控制及應用專業（04級普通） 第10周～第18周(2007.5.7~2007.7.6)
答辯時間另行通知。以上時間如有變化，會及時通知。
六．畢業論文（設計）成績的評定
畢業論文的成績分為：優、良、中、及格、不及格五級。
畢業論文的成績將綜合考慮畢業環節個人表現、論文水平及畢業答辯的情況。
七．畢業論文（設計）參考選題
設計題目一 三相非同步電動機轉速控制系統
1、 任務
設計一個小型計算機控制系統，控制三相非同步電動機的轉速。要求在一定范圍內電機轉速保持在設定轉速上。
2、要求
(1)、電機轉速控制范圍為0-1200RPM。
（2）、要求設置相應的按鈕使用戶能夠設置電機轉速、演算法參數大小以及電機的啟動和停止等。
（3）、電機控制演算法可以採用PID演算法、模糊控制演算法、模糊PID控制演算法等。
（4）、電動機的轉速調整通過晶閘管調壓模塊調整加到三相交流非同步電動機的電壓來實現。
（5）、要求在系統處於穩定狀態時，系統的設置值與實際輸轉速之間的誤差（即穩態誤差）控制在15%以內。

設計題目二 電烤箱溫度控制系統
1、任務
設計一個電烤箱溫度控制系統，要求在一定范圍內電烤箱溫度保持在設定溫度上。
2、要求
(1)、溫度范圍為0-200℃。
（2）、溫度值、控制參數等可以手動設置並能顯示設定溫度、實際溫度、控制參數等
（3）、系統的啟動和停止等操作可以通過鍵盤控制。
（4）、溫度控制精度要求在正負5℃。

設計題目三 自動往返小車的設計
1、任務
設計製作一款具有智能判斷自動往返功能的小車，能沿設定軌道自動往返。路長20厘米，並在路的兩邊貼有黑線軌道，路中間貼有數片鐵片，路兩頭有路障。
2、要求
（1）、能在路兩頭自動往返行駛
（2）、尋跡功能（按路面的黑色軌道行駛）。
（3）、檢測路面所放置的鐵片的個數的功能。
（4）、計算並顯示所走的路程和行走的時間，並可發聲發光。

設計題目五、自動水溫控制系統
1、任務
設計並製作一個水溫自動控制系統，控制對象為1升凈水，容器為搪瓷器皿。水溫可以在一定范圍內由人工設定，並能在環境溫度降低時實現自動控制，以保持設定的溫度基本不變。
2、要求
（1）溫度設定范圍為40～90℃，最小區分度為1℃，標定溫度≤1℃。
（2）環境溫度降低時（例如用電風扇降溫）溫度控制的靜態誤差≤1℃。
（3）用十進制數碼管顯示水的實際溫度。
設計題目六、數字式工頻有效值多用表
1、任務
設計並製作一個能同時對一路工頻交流電（頻率波動范圍為50 ±1Hz、有失真的正弦波）的電壓有效值、電流有效值、有功功率、無功功率、功率因數進行測量的數字式多用表。參見附圖。
2、要求
（1）測量功能及量程范圍
a、 交流電壓：0～500V；
c、 有功功率：0～25kW；
d、 無功功率：0～25kvar；
e、 功率因數（有功功率/視在功率）：0～1 。
為便於本試題的設計與製作，設定待測0～500V的交流電壓、0～50A的交流電流均已經相應的變換器轉換為0～5V的交流電壓。
（2）准確度
a、 顯示為 位（0.000～4.999），有過量程指示；
b、 交流電壓和交流電流：±（0.8％讀數＋5個字），例：當被測電壓為300V時，讀數誤差應小於±（0.8％×300V＋0.5V）＝±2.9V ；
c、 有功功率和無功功率：±（1.5％讀數＋8個字）；
d、 功率因數：±0.01 。
（3）功能選擇：用按鍵選擇交流電壓、交流電流、有功功率、無功功率和功率因數的測量與顯示
設計題目七、液體點滴速度監控裝置
1、任務
設計並製作一個液體點滴速度監測與控制裝置，示意圖如右圖所示。
2、要求
（1）在滴斗處檢測點滴速度，並製作一個數顯裝置，能動態顯示點滴速度（滴/分）。
（2）通過改變h2控制點滴速度，如右圖所示；也可以通過控制輸液軟管夾頭的松緊等其它方式來控制點滴速度。點滴速度可用鍵盤設定並顯示，設定范圍為20~150(滴/分)，控制誤差范圍為設定值 ±10% ±1滴。
（3）調整時間≤3分鍾（從改變設定值起到點滴速度基本穩定，能人工讀出數據為止）。
（4）當h1降到警戒值（2~3cm）時，能發出報警信號。
3、說明
（1）、控制電機類型不限，其安裝位置及安裝方式自定。
（2）、儲液瓶用醫用250毫升注射液玻璃瓶（瓶中為無色透明液體）。
（3）、受液瓶用1.25升的飲料瓶。
（4）、 點滴器採用針柄顏色為深藍色的醫用一次性輸液器（滴管滴出20點蒸餾水相當於1ml±0.1ml）。
（5）、賽區測試時，僅提供醫用移動式點滴支架，其高度約1.8m，也可自帶支架；測試所需其它設備自備。
（6）、滴速夾在測試開始後不允許調節。
（7）、發揮部分第（2）項從站功能中，c中的「異常情況」自行確定。
設計題目八、自動控制升降旗系統
1. 任務
設計一個自動控制升降旗系統，該系統能夠自動控制升旗和降旗，升旗時，在旗桿的最高端自動停止；降旗時，在最低端自動停止。
自動控制升降旗系統的機械模型如圖所示。旗幟的升降由電動機驅動，該系統有兩個控制按鍵，一個是上升鍵，一個是下降鍵。
2. 要求
（1）、按下上升按鍵後，國旗勻速上升；上升到最高端時自動停止上升；按下下降按鍵後，國旗勻速下降，下降到最低端時自動停止。
（2）、能在指定的位置上自動停止。
（3）、為避免誤動作，國旗在最高端時，按上升鍵不起作用；國旗在最低端時，按下降鍵不起作用。
（4）、升降旗的時間均為43秒鍾，與國歌的演奏時間相等。
（5）數字即時顯示旗幟所在的高度，以厘米為單位，誤差不大於2厘米。
附件一：
山東水利職業學院 信息工程系
畢業論文（設計）撰寫規范

一、論文印裝
（一）裝訂要求
論文一律用A4（210mm279mm）標准大小的白紙列印並裝訂（左裝訂）成冊。論文在列印時，要求紙的四周留足空白邊緣，以便裝訂和批註。每頁的上邊距和左邊距側(訂口)應分別留邊25 mm，下邊距和右邊距(切口)應分別留邊20 mm。
（二）字體要求
1. 論文標題： 小2宋體字，黑體；
小標題1： 小3宋體字，黑體；
小標題2： 4號宋體字，黑體；
2. 正文標題： 參考（五）正文部分；
3. 正 文： 小4宋體字；
4. 參考文獻： 5號宋體字；
5. 英文摘要： 標題：小3， 正文：小4，字體 ：Times New Roman
二、論文結構及要求
畢業論文由以下部分組成：
1.封面；2.畢業設計（論文）任務書；3.中文摘要；4.英文摘要；5.目錄；6.正文；
7.結論；8.致謝；9.參考文獻；10.有關圖紙(大於3#圖幅時單獨裝訂)。
（一）封面及畢業設計（論文）任務書
封面是論文的外表面，提供應有的信息，並起保護作用。
封面上包括下列內容：
1.論文題目，用三號宋體字標注在題目欄；
2.論文的作者和指導教師；
3.所屬系（部、中心）、專業、年級、學號。論文封面（見附件八）。
任務書由指導教師填寫，經系（部、中心）或教研室主任簽字後生效。
（二）中英文摘要（中文在前，英文在後）及關鍵詞
摘要是論文內容的簡要陳述，應盡量反映論文的主要信息，內容包括研究目的、方法、成果和結論，不含圖表，不加註釋，具有獨立性和完整性。中文摘要一般為300 字左右，英文摘要應與中文摘要內容完全相同。
「摘要」字樣位置居中。
關鍵詞是為了滿足文獻標引或檢索工作的需要而從論文中選取出的用以表示全文主題內容信息的詞或片語。關鍵詞包括主題和自由詞：主題詞是專門為文獻的標引或檢索，盡量從《漢語主題詞表》中選用；自由詞則是未規范化的即還未收入主題詞表中的詞或片語。
每篇論文中應列出3～5個關鍵詞，它們應能反映論文的主題內容。其中主題詞應盡可能多一些，關鍵詞作為論文的一個組成部分，列於摘要段之後。撰寫要求有英文摘要的論文，還應列出與中文對應的英文關鍵詞（Key words）。
關鍵詞排在摘要正文部分下方。
（三）目錄
目錄按三級標題編寫，要求層次清晰，且要與正文標題一致。主要包括緒論、正文主體、結論、致謝、主要參考文獻及附錄等。
（四）緒論
1.緒論
其目的是向讀者交代本研究的來龍去脈，作用在於使讀者對論文先有一個總體的了解。緒論要寫得自然、概括、簡潔、確切。
2.緒論的內容有如下幾項：
（1）研究的目的、范圍和背景。
（2）理論依據、實驗基礎和研究方法。
（3）預期的結果及其地位、作用和意義。
（五）正文
正文是論文的核心部分，論文的論點、論據和論證都在這里闡述，因此它要佔主要篇幅。由於論文作者的研究工作涉及的學科、選題、研究對象和研究方法、工作進程、結果表達方式等差異很大，所以對正文中要寫的內容不作統一規定；但總的思路和結構安排應當符合「提出論點，通過論據或數據對論點加以論證」這一共同的要求。正文必需客觀真切、准確完備、合乎邏輯、層次分明。
1.對正文主題的要求
（1）主題新穎，研究、解決、創立需研究和解決的問題。
（2）主題深刻，抓住問題的本質，揭示事物的主要矛盾，總結出事物存在、運動、變化和發展的客觀規律。
（3）主題集中，一篇論文只有一個中心，要使主題集中，凡於本文主題無關或關系不大的內容不應涉及，不過多闡述，否則會使問題繁雜，脈絡不清，主題淡化。
（4）主題鮮明，論文的中心思想地位突出，除了在論文的題目、摘要、前言、結論部分明確地點出主題外，在正文部分更要注意突出主題。
2.對結構的要求
論文撰寫通行的題序層次大致有以下幾種格式：
第一種 第二種 第三種 第四種
一、 第一章 第一章 1.
（一） 一、 第一節 1.1
1. （一） 一、 1.1.1
（1） 1. （一） 1.1.2（1）
格式是保證文章結構清晰、綱目分明的編輯手段，撰寫畢業論文可任選其中的一種格式，但所採用的格式必須符合上表規定，並前後統一，不得混雜使用。格式除題序層次外，還應包括分段、行距、字體和字型大小等。
第一層次（章）題序和標題居中放置，其餘各層次（節、條、款）題序和標題一律沿版面左側邊線頂格安排。第一層次（章）題序和標題距下文雙倍行距。段落開始後縮兩個字。行與行之間，段落和層次標題以及各段落之間均為單倍行距。
第一層次（章）題序和標題用小三號宋體字，黑體。題序和標題之間空兩個字，不加標點。
第二層次（節）題序和標題用四號宋體字，黑體。
第三層次（條）及以下各層次題序及標題一律用小四號宋體字，黑體。
（六）結論
結論即結束語、結語，是在理論分析和實驗驗證的基礎上，通過嚴密的邏輯推理得出的有創造性、指導性、經驗性的結果描述。結論作為單獨一章排列，但標題前不加「第XXX章」字樣。結論是整個論文的總結，應以簡練的文字說明論文所做的工作，一般不超過兩頁。
（七）致謝
對指導教師和給予指導或協助完成畢業設計（論文）工作的組織和個人表示感謝。文字要簡捷、實事求是，切忌浮誇和庸俗之詞。
（八）主要參考文獻
1.參考文獻
參考文獻應是論文作者親自考察過的對畢業論文有參考價值的文獻。參考文獻應具有權威性，要注意引用最新的文獻。參考文獻在整個論文中出現的次序用[1]、[2]、[3]……形式統一排序，依次列出。
2.參考文獻的表示格式為：
著作：[序號]作者.譯者.書名.版本.出版地：出版社，出版時間.引用部分起止頁
期刊：[序號]作者.譯者.文章題目.期刊名.年份.卷號(期數). 引用部分起止頁
會議論文集：[序號]作者.譯者.文章名.文集名 .會址.開會年.出版地：出版者.出版時間.引用部分起止頁
例：
[1] 劉國均,陳紹業.圖書館目錄.第1版.北京:高等教育出版社，1957
[2] 傅秉義,陳運泰,祁貴中.地球物理學基礎.北京:科學出版社，1958,447
[3] 華羅庚,王元.論一致分布與近似分析.中國科學，1973（4）：339~357
三、其他要求
（一）表格
論文的表格可以統一編序（如：表15），也可以逐章單獨編序（如：表2.5），採用哪種方式應和插圖及公式的編序方式統一。表序必須連續，不得重復或跳躍。
表格的結構應簡潔。
表格中各欄都應標注量和相應的單位。表格內數字須上下對齊，相鄰欄內的數值相同時，不能用『同上』、『同左』和其它類似用詞，應一一重新標注。
表序和表題置於表格上方中間位置，無表題的表序置於表格的左上方或右上方（同一篇論文位置應一致）。
（二）圖
插圖要精選。圖序可以連續編序（如 圖52），也可以逐章單獨編序（如 圖6.8），採用哪種方式應與表格、公式的編序方式統一，圖序必須連續，不得重復或跳躍。僅有一圖時，在圖題前加『附圖』字樣。畢業設計（論文）中的插圖以及圖中文字元號應列印，無法列印時一律用鋼筆繪制和標出。
由若干個分圖組成的插圖，分圖用a,b,c,……標出。
圖序和圖題置於圖下方中間位置。
（三）公式
論文中重要的或者後文中須重新提及的公式應注序號並加圓括弧，序號一律用阿拉伯數字連續編序（如：（45））或逐章編序（如（6.10）），序號排在版面右側，且距右邊距離相等。公式與序號之間不加虛線。
（四）數字用法
公歷世紀、年代、年、月、日、時間和各種計數、計量，均用阿拉伯數字。年份不能簡寫，如1999年不能寫成99年。數值的有效數字應全部寫出，如：0.50；2.00不能寫作0.5；2。
（五）軟體
軟體流程圖和原程序清單要按軟體文檔格式附在論文後面。
（六）工程圖按國標規定裝訂
圖幅小於或等於3#圖幅時應裝訂在論文內，大於3#圖幅時按國標規定單獨裝訂作為附圖。
（七）計量單位的定義和使用方法按國家計量局規定執行。

（八）附錄
1.附錄
附錄是論文主體的補充項目，為了體現整篇論文的完整性，寫入正文又可能有損於論文的條理性、邏輯性和精煉性，這些材料可以寫入附錄段，但對於每一篇論文並不是必須的。
2.附錄大致包括如下一些材料：
（1）比正文更為詳盡的理論根據、研究方法和技術要點，建議可以閱讀的參考文獻的題錄，對了解正文內容有用的補充信息等；
（2）由於篇幅過長或取材於復製品而不宜寫入正文的材料；
（3）一般讀者並非必要閱讀，但對本專業同行很有參考價值的資料；
（4）某些重要的原始數據、數學推導、計算程序、框圖、結構圖、統計表、計算機列印輸出件等。
（5）附錄段置於參考文獻表之後，附錄中的插圖、表格、公式、參考文獻等的序號與正文分開，另行編制，如編為「圖1」，「圖2」；「表1」，「表3」；「式（1）」，「式2」；「文獻[1]」，「文獻[2]」等。
四、畢業設計（論文）裝訂順序
（一）畢業設計（論文）封面
（二）畢業設計（論文）任務書
（三）中文摘要、關鍵詞
（四）英文摘要、關鍵詞
（五）目錄
（六） 正文
（七） 附錄
（八） 封底

7. 計算機專業發表論文

您好，

如果是計算機專業的同學可以建議做網路方面的論文研究，這方面比較熱門、資料繁多、可借鑒性強；

其他如資料庫較之演算法以及數據結構相對可參考資料更為多一些。

相關範文：

Oracle資料庫的備份和恢復The Backup and Restoration of Database Oracle

摘要：本文從Oracle的體系結構開始，由原理到實踐，論述了Oracle資料庫備份的方式和策略。包括IMP/EXP， RMAN，OS備份等。
Abstract: Starting from the architecture of ORACLE, this paper discusses the backup method and strategy of database Oracle, including IMP/EXP, PMAN and OS theoretically and practically.

關鍵字：Oracle, 備份, 恢復, RMAN
Keywords: Oracle; Backup; Restoration; RMAN

概述
在大型軟體運行系統中，存在著很多備份策略，如RAID技術，CLUSTER技術等等。很多時候，這些系統的備份就能夠解決資料庫備份的問題。但是，這種備份成本很高。同時，硬體的備份有時根本滿足不了現實的需要，如果用戶不小心誤刪了一個表，又想恢復的時候，資料庫的備份就變的重要了。
Introction: In the running system of some big software, there exist many backup strategies such as RAID technology and CLUSTER technology etc. In most cases, these system backup strategies can fulfill the database backup. However the cost is rather high. At the same time, hardware backup sometimes is far from the actual requirement. The database backup becomes very important when a table is deleted by accident and needs to be restored.
Oracle的運行方式
Oracle資料庫有兩種運行方式：一是歸檔方式（ARCHIVELOG），歸檔方式的目的是當資料庫發生故障時最大限度恢復資料庫，可以保證不丟失任何已提交的數據；二是不歸檔方式(NOARCHIVELOG)，只能恢復資料庫到最近的回收點（冷備份或是邏輯備份）。根據資料庫的高可用性和用戶可承受丟失的工作量的多少，對於實時性要求高的資料庫，強烈要求採用為歸檔方式；不歸檔方式只用在那些開發和調試的資料庫等。
如何改變資料庫的運行方式，在創建資料庫時，作為創建資料庫的一部分，就決定了資料庫初始的存檔方式。一般情況下為NOARCHIVELOG方式。當資料庫創建好以後，根據我們的需要把需要運行在歸檔方式的資料庫改成ARCHIVELOG方式。 操作如下。
1. 關閉資料庫，備份已有的數據，改變資料庫的運行方式是對資料庫的重要改動，所以要對資料庫做備份，對可能出現的問題作出保護。
2. 修改初試化參數，使能自動存檔。
修改（添加）初始化文件init[SID].ora參數：
log_archive_start=true #啟動自動歸檔
log_archive_format=ARC%T%S.arc #歸檔文件格式
log_archive_dest=/archdir/arch #歸檔路徑
在8i中，可以最多有五個歸檔路徑，並可以歸檔到其它伺服器，如備用資料庫(standby database)伺服器。
3. 啟動Instance到Mount狀態，即載入資料庫但不打開資料庫。
$> svrmgrl
SVRMGRL> connect internal
SVRMGRL> startup mount
SVRMGRL> alter database archivelog; // 使資料庫運行在歸檔方式
SVRMGRL> alter database open;
Oracle的備份方案
按照備份的方式，可以分為邏輯備份、冷備份（離線備份）、熱備份（聯機備份），其中冷備份與熱備份又可以合稱為物理備份。按照備份的工具，可以分為EXP/IMP備份、操作系統備份、RMAN、第三方工具備份，如VERITAS等。下面分別介紹Oracle本身提供的幾種備份工具和操作。
1. EXP/IMP備份（邏輯備份）
EXP/IMP屬於邏輯備份的范疇，邏輯備份是指只備份資料庫中的數據但不記錄數據物理位置的一種備份。導出為資料庫作一個二進制的備份，並且這個備份只能由其姊妹程序imp（import）來讀取。具體的使用方法如下。（因為EXP和IMP使用上參數基本相同，所以只以EXP為例。）
EXP的命令格式和參數
格式:KEYWORD=value 或 KEYWORD=(value1,value2,...,valueN)
常式: EXP SCOTT/TIGER GRANTS=Y TABLES=(EMP,DEPT,MGR)
USERID 必須是命令行中的第一個參數

關鍵字 說明（默認） 關鍵字 說明（默認）
USERID 用戶名/口令 FULL 導出整個文件 (N)
BUFFER 數據緩沖區的大小 OWNER 所有者用戶名列表
FILE 輸出文件 (EXPDAT.DMP) TABLES 表名列表
COMPRESS 導入一個范圍 (Y) RECORDLENGTH IO記錄的長度
GRANTS 導出許可權 (Y) INCTYPE 增量導出類型
INDEXES 導出索引 (Y) RECORD 跟蹤增量導出 (Y)
ROWS 導出數據行(Y) PARFILE 參數文件名
CONSTRAINTS 導出限制 (Y) CONSISTENT 交叉表一致性
LOG 屏幕輸出的日誌文件 STATISTICS 分析對象 (ESTIMATE)
DIRECT 直接路徑 (N) TRIGGERS 導出觸發器 (Y)
FEEDBACK 顯示每 x 行 (0) 的進度 FILESIZE 各轉儲文件的最大尺寸
QUERY 選定導出表子集的子句
註：可以通過exp －help命令查看exp的使用方法；imp -help命令查看imp的使用方法.

2. 操作系統備份（冷備份和熱備份）
操作系統備份有兩類，冷備份（Cold backup）和熱備份（Hot backup）。操作系統備份和上面的邏輯備份有本質的區別，它將拷貝整個的數據文件。
 冷備份
在文件級備份開始前資料庫必須徹底關閉。關閉操作必須用帶有normal、immediate、transaction選項的shutdown來執行。
資料庫使用的每個文件都被備份下來，這些文件包括： 所有數據文件、所有控制文件、所有聯機重做日誌文件和INIT.ORA文件(建議)。
作冷備份一般步驟是：
1) 正常關閉要備份的實例(instance);
2) 備份整個資料庫到一個目錄
3) 啟動資料庫
即：
SVRMGRL>connect internal
SVRMGRL >shutdown immediate
SVRMGRL >!cp <file> <backup directory>
or
SVRMGRL >!tar cvf /dbbak/fullbk.tar /u01/oracle/oradata/dbname
SVRMGRL >startup
 熱備份
熱備份是當資料庫打開時的操作系統備份。熱備份只能用於ARCHIVELOG方式的資料庫。熱備份沒有必要備份聯機日誌，但必須是歸檔狀態，在實例恢復的時候，可能需要用到歸檔日誌。當前聯機日誌一定要保護好或是處於鏡相狀態，當前聯機日誌的損壞，對於資料庫的損壞是巨大的，只能以數據的丟失來進行資料庫的恢復工作。對於臨時表空間，存放的是臨時信息，在熱備份是也可以考慮不用備份，如果臨時文件發生故障，可以刪除該數據文件與表空間，重建一個臨時表空間。
熱備份備份的內容和冷備份備份的內容一樣，操作一般步驟是：
1) 備份的表空間通過使用ALTER TABLESPACE …… BEGIN BACKUP使表空間進入熱備份方式。
2) 用類似冷備份的操作系統命令對組成表空間的數據文件進行拷貝。
3) 使用ALTER TABLESPACE …… END BACKUP命令使表空間脫離熱備份方式。
4) 使用ALTER DATABSE …… BACKUP CONTROLFILE命令備份控制文件。
即：
SVRMGRL>connect internal;
SVRMGRL>alter tablespace User begin backup;
SVRMGRL>!cp /u01/oradata/dbname/user01.ora /dbbak/user01.ora
SVRMGRL>alter tablespace User end backup;
SVRMGRL>alter database backup controlfile to <fielname>;
or
SVRMGRL>alter database backup controlfile to trace;
注意：因為熱備份的時候，用戶還在操作資料庫，所以最好是讓每個表空間處於備份狀態的時間最短，這樣就要求一個表空間一個表空間的備份，不要一起使表空間處於備份狀態而同時拷貝數據文件。
3. RMAN
Recovery Manager（RMAN）是一個使DBA能很方便地對資料庫執行備份和恢復任務的Oracle應用工具，能夠提供DBA對企業資料庫備份與恢復操作的集中控制。RMAN只能用於ORACLE8或更高的版本中。它能夠備份整個資料庫或資料庫部件，其中包括表空間、數據文件，控制文件和歸檔文件。RMAN可以按要求存取和執行備份和恢復。
RMAN支持六種不通的類型的備份，經常用到的有兩種：
FULL 資料庫全備份，包括所有的數據塊。
INCREMENTAL 增量備份，是指只備份在同級別或更低級別上進行的前一次備份之後的作過改動的那些數據塊。這其中需要一個0級的增量作為增量的基礎，它備份包括全部曾經被資料庫使用過的數據塊（但不是完全資料庫備份）。RMAN共可以支持7級增量。
BACKUP，RESTORE，RECOVER是RMAN最基本的三個命令，分別可以進行資料庫的備份，復原以及恢復操作。 restore命令用於恢復來自備份集或映像拷貝的數據文件、控制文件或歸檔重做日誌。recovery命令用於進行介質恢復應用重做日誌文件。
RMAN的備份信息一般保存在恢復目錄中，恢復目錄也是一個資料庫，只不過這個資料庫用來保存備份信息，一個恢復目錄可以用來保存多個資料庫的備份信息。 RMAN也可以在沒有恢復目錄(NOCATALOG)下運行，這個時候備份信息保存在控制文件。這種情況比較危險，因為一旦控制文件被破壞，將導致所有資料庫備份信息的丟失和恢復的失敗，而且，沒有恢復目錄，很多RMAN的命令將不被支持。所以對於重要的資料庫，建議創建恢復目錄。
創建恢復目錄一般有以下步驟。（例子資料庫為db）
1) 為目錄創建一個單獨的表空間
SQL>create tablespace tsrman datafile 』/dbbak/rman/rsrman.dbf』 size 50M;
2) 創建RMAN用戶
SQL>create user rman identified by rman default tablespace rsrman temporary tablespace temp;
3) 給RMAN授予許可權
SQL>grant connect, resource, recovery_catalog_owner to rman;
4) 打開RMAN
$rman
5) 連接恢復目錄資料庫
RMAN>connect catalog rman/rman@db
6) 創建恢復目錄
RMAN>create catalog tablespace tsrman

在對某個資料庫進行備份之前，必須先在恢復目錄上注冊該資料庫，這一過程操作如下（假定目標資料庫連接字元串為db100）。
1) 連接到恢復目錄資料庫
$rman rman/rman@db
2) 在RMAN中連接到目標資料庫（即要進行備份的資料庫）
RMAN>connect target sys/change_on_install@db100
3) 注冊資料庫
RMAN>register database;
注冊完資料庫後，就可以進行資料庫的備份了。有完全資料庫備份、表空間備份、控制文件備份、和歸檔日誌備份等。操作分別如下。
1) 完全資料庫備份
要求：ARCHIVELOG模式，在DB OPEN的情況下進行資料庫完全備份。
RMAN>run{
allocate channel c1 type=disk;
backup database;
release channel c1;
}
2) 表空間備份
要求：ARCHIVELOG模式
RMAN>run{
allocate channel c1 type=disk;
backup tablespace 「ts_users」 filesperset 3 format 『aatst_%t%s.%p』;
release channel c1;
}
3) 控制文件備份
RMAN>run{
allocate channel c1 type=disk;
backup current controlfile tag=weekly_sat_backup;
release channel c1;
}
在對資料庫進行完全備份時，控制文件自動包含其中。也可以在表空間或數據文件的備份中包含一個控制文件。
RMAN>run{
allocate channel c1 type=disk;
backup tablespace 「ts_users」
filesperset 3 format 『aatst_%t%s.%p』;
include current controlfile;
release channel c1;
}
4) 歸檔日誌備份
通過查詢數據字典表V$ARCHIVED_LOG獲取要備份的日誌序列號，然後執行命令：
RMAN>run{
allocate channel c1 type=disk;
backup archivelog low logseq 3 high logseq 10 thread 1;
release channel c1;
}
Oracle的備份策略
正確的備份策略不僅能保證資料庫伺服器的24*7的高性能的運行，還能保證備份與恢復的快速性與可靠性。我們將以RMAN的多級增量備份作為一個備份策略的例子來討論。採用多級備份就是為了減少每天備份所需要的時間，而又保證系統有良好的恢復性。恢復時間與備份時間要有一個權衡。比如只要進行一個資料庫的全備份，然後就只備份歸檔也可以保證能把資料庫恢復到最新的狀態，但是這樣的恢復時間將是不可容忍的。多級備份也正是為了解決這種問題，結合某些應用的特點，可以採用如下的備份策略：
 每個月做一個資料庫的全備份（包括所有的數據和只讀表空間）；
 每個星期一做一次零級備份（不包含只讀表空間）；
 每個星期三做一次一級備份；
 每天做一次二級備份。
 每天做一次恢復目錄的熱備份。
 任何資料庫的更改需要重新同步CATALOG目錄並重新備份（如添加數據文件）或重新備份（如修改表空間為只讀）。
 每次備份後都可以備份歸檔日誌或定期備份歸檔日誌。如果可能，可以直接備份到磁帶上。
Oracle的恢復
下面的操作約定恢復目錄存儲在db118中，目標資料庫是db100。
1. 資料庫恢復
1) 啟動SQL*PLUS，使用正確的init.ora文件，使用NOMOUNT選項啟動目標資料庫實例。
2) 啟動RMAN並連接到恢復目錄，如下：
$rman catalog rman/rman@db118
恢復管理器: Release 9.2.0.1.0 - Proction
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
連接到恢復目錄資料庫
RMAN>
3) 連接到目標資料庫
RMAN>connect target internal/oracle@db100
連接到目標資料庫: db (DBID=1142471523)
4) 一旦連接到目標資料庫，執行restore命令執行全資料庫恢復
RMAN>run{
2>allocate channel c1 type disk;
3>restore database;
4>release channel c1;
}
2. 表空間和數據文件恢復
要執行表空間或數據文件恢復，資料庫必須以ARCHIVELOG模式運行，並且用戶需要擁有介質恢復所需的歸檔重做日誌文件。在試圖恢復表空間之前，必須保證表空間已離線。RMAN命令如下：
run{
allocate channel c1 type disk;
sql 「alter tablespace users_data offline immediate」;
restore tablespace users_data;
recover tablespace users_data;
sql 「alter tablespace users_data online」;
}
上面的腳本執行了以下的工作：
1) RMAN分配通道從c1用於恢復操作。
2) 將表空間users_data離線
3) RMAN從備份集中恢復屬於表空間的數據文件
4) 通過介質恢復提供所需的歸檔日誌文件，恢復屬於表空間users_data的數據文件。
5) RMAN將表空間聯機。
在腳本執行期間，如果不能把數據文件恢復到指定位置，在執行restore命令前使用set newname命令。
3. 控制文件恢復
1) 啟動SQL*PLUS，使用正確的init.ora文件，使用NOMOUNT選項啟動目標資料庫實例。
2) 啟動RMAN並連接到恢復目錄，如下：
$rman catalog rman/[email protected]
恢復管理器: Release 9.2.0.1.0 - Proction
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
連接到恢復目錄資料庫
RMAN>
3) 連接到目標資料庫
RMAN>connect target internal/[email protected]
連接到目標資料庫: db (DBID=1142471523)
4) 一旦連接到目標資料庫，執行restore命令恢復控制文件
RMAN>run{
2>allocate channel c1 type disk;
3>restore controlfile;
4>}
小結
保證Oracle資料庫的安全是系統安全的重要組成部分，必須要設計完善的資料庫備份和恢復方案。Oracle提供的各種工具結合起來使用能夠使資料庫的備份和恢復變得簡單。在實際的Oracle資料庫的備份和恢復中，會有許多不通的和復雜的情況出現，針對不同的情況，要本著使數據具有最大的可恢復性和恢復時間最短的原則去進行資料庫的恢復，這需要大量的實踐和經驗積累。

參考文獻
[1] Oracle8i Backup and Recovery Guide Oracle Document
[2] Oracle8i Recovery Manager User』s Guide and Reference Oracle Document
[3] Oracle9i：A Beginner』s Guide (美) Michael Abbey Michael Corey Ian Abramson 2002.3 機械工業出版社
[4] Oracle8i備份與恢復手冊 (美)Rama Velpuri Anand Adkoli 蔣蕊 王磊等譯 2001.9 機械工業出版社

僅供參考，請自借鑒

希望對您有幫助

8. 弄畢業實驗,但是數據結構與演算法都與別人相反要怎麼寫論文

不知道你是不是寫（數據挖掘）這類的論文呢~~你自己在網上看下吧~

9. 畢業論文格式word

畢業論文格式範文word

摘 要

數據結構演算法設計和演示(C++)-樹和查找是在面向對象思想和技術的指導下，採用面向對象的編程語言(C++)和面向對象的編程工具(Borland C++ Builder 6.0)開發出來的小型應用程序。它的功能主要是將數據結構中鏈表、棧、隊列、樹、查找、圖和排序部分的典型演算法和數據結構用面向對象的方法封裝成類，並通過類的對外介面和對象之間的消息傳遞來實現這些演算法，同時利用C++ Builder 6.0 中豐富的控制項資源和系統資源對演算法實現過程的流程和特性加以動態的演示，從而起到在數據結構教學中幫助理解、輔助教學和自我學習的作用。

關鍵詞：數據結構;面向對象;可視化;演算法

The Subject of Undergraate Graation Project of HEAU

Abstract

外文摘要要求用英文書寫，內容應與“中文摘要”對應。使用第三人稱，最好採用現在時態編寫。

“Abstract”不可省略。標題“Abstract”選用模板中的樣式所定義的“標題1”，再居中;或者手動設置成字體：黑體，居中，字型大小：小三，多倍行距1.5倍行距，段後11磅，段前為0。

標題“Abstract”上方是論文的英文題目，字體：Times New Roman，居中，字型大小：小三，行距：多倍行距 1.25，間距：前段、後段均為0行，取消網格對齊選項。 Abstract正文選用設置成每段落首行縮進2字，字體：Times New Roman，字型大小：小四，行距：多倍行距 1.25，間距：前段、後段均為0行，取消網格對齊選項。

Key words與Abstract之間空一行。Key words與中文“關鍵詞”一致。詞間用分號間隔，末尾不加標點，3-5個，Times New Roman，小四，加粗。

Key Words：Write Criterion;Typeset Format;Graation Project (Thesis)

目 錄

1 引言 .......................... 1 2 線性表的基本理論知識 ............................. 1 2.1 線性表的定義 ....... 1 2.2線性順序表 ............ 1 2.2.1三級標題名 ......... 1 2.2.2三級標題名 ......... 1 2.3線性鏈表 ................ 1 3 設計的主體內容 ...... 1 3.1 系統結構的設計 ... 1 3.2交互界面的設計和實現 ........................... 2 3.3 線性表的00P序設計 .............................. 2 3.3.1線性表的順序存儲的實現 .................... 2 3.3.2 線性表的鏈表存儲的實現 ................... 2 4 結果分析與討論 ...... 3 5 結語 .......................... 4 參考文獻 ...................... 5 致 謝 ............................ 6 附錄1：附錄一題目 ... 7 附錄2：附錄二題目 ... 8

1 引言

計算機與網路技術的高速發展，特別是面向對象技術的出現，使得C++的軟體開發得到了迅速普及。

本課題主要 ………………

2 線性表的基本理論知識

2.1 線性表的定義

線性表是最簡單、最常用的一種數據結構。線性表[1]是n(n>=0)個數據元素的.有限序列。

……。

2.2線性順序表

線性表的順序存儲結構的特點是為表中相鄰的元素ai和ai+1 賦以相鄰的存儲位置。

2.2.1三級標題名 2.2.2三級標題名

1)四級以下標題 2)四級以下標題

2.3線性鏈表

線性表的鏈式存儲結構的特點是用一組任意的存儲單元存儲線性表的數據元素(這組元素可以是連續的,也可以是不連續的)[1]。

……。

3 設計的主體內容

在著手進行上機設計之前首先做好大量准備:應熟悉課題，進行調查研究，收集國內、外資料、分析研究;交互界面的設計和實現。

……。

3.1 系統結構的設計

……。

3.2交互界面的設計和實現

„„由公式(1)給出：

3.3 線性表的00P序設計

計算機內部可以採用兩種不同方法來表示一個線性表,它們分別是順序表示法和鏈表表示法。

……。

3.3.1線性表的順序存儲的實現

…… 以上是順序表的實現過程,第1-16行包含了list類的說明,接下來是成員函數的定義。 ……。

3.3.2 線性表的鏈表存儲的實現

……

鏈表的實現包括兩個類定義，第一個是link類，第二個是list類。由於一個鏈表由若干個單獨的鏈結點對象組成，因此一個鏈結點應當作為單獨的link類實現。

.3. 4 結果分析與討論

例如由於起初未能真正掌握各種控制項的功能，我設想是要一個下拉菜單，但是學識膚淺的我試了很多種就是達不到我要的效果，……。

……

關於……的影響如表4-1所示。

5 結語

本課題採用C++語言、面向對象的設計方法實現數據結構的重要演算法。 ……

……而且還存在著許多不足之處。如： …… 。

參考文獻

[1] 嚴蔚敏，吳偉民.數據結構(C語言版)[M]. 北京：清華大學出版社，1997.4

[2] 沈晴霓，聶青，蘇京霞.現代程序設計—C++與數據結構面向對象的方法與實現[M].北京：北京理工大學出版社，2002.8

[3] Thomas Connolly Carolyn Begg. Database Systems [M].北京：電子工業出版社，2004.7

[4] Roger Bate, Sandy Shrum, CMM Integration Framework[J], CMU/SEI Spotlight 1998.9

[5] J P Kuilboer,N Ashrafi, Software Process and Prot Improvement[J]. An Empirical Assessment,2000.4

[6] 張美金 著. 基於ASP技術的遠程教育系統體系結構的研究. http://172.50.0.88:86 /~cddbn/Y517807/pdf/,2003-05-01.

[7]王偉國，劉永萍，王生年，徐曉鵬.B/S模式網上考試系統分析與設計[J].石河子大學學報(自然科學版)，2003，6(2):145-147

[8] …

[9] …

[10] …

注 釋

①

②

致 謝

大學四年的學習生活即將結束，在此，我要感謝所有曾經教導過我的老師和關心過我的同學，他們在我成長過程中給予了我很大的幫助。本文能夠成功的完成，要特別感謝我的導師XXX教授的關懷和教導。………。

附錄1：附錄一題目

附錄2：附錄二題目

;

10. 計算機軟體技術基礎淺談論文

計算機軟體技術基礎是模擬工程與自動化專業的核心課程之一，該課程是整合課程，主要包括c++面向對象程序設計、演算法與數據結構、操作系統、軟體工程等方面的內容，知識龐雜且難以掌握。下面是我給大家推薦的計算機軟體技術基礎淺談論文，希望大家喜歡!

計算機軟體技術基礎淺談論文篇一

《計算機軟體技術基礎課程的案例建設》

摘要：案例教學能有效提高學生分析問題和解決問題的能力，是現代教育的常用教學方法之一。文章分析案例教學中的案例特徵，以實際工程項目的一個子系統為背景，設計實時模擬監視系統案例並介紹案例的具體建設情況，指出該案例對提高學生的學習興趣以及分析問題和解決問題的能力具有明顯的效果。

關鍵詞：軟體技術基礎;案例教學;案例建設;實時模擬;監視系統

1、計算機軟體技術基礎課程中案例教學的必要性

計算機軟體技術基礎是模擬工程與自動化專業的核心課程之一，是一門應用性很強的專業基礎課。該課程是整合課程，主要包括c++面向對象程序設計、演算法與數據結構、操作系統、軟體工程等方面的內容，知識龐雜且難以掌握。學生在學習該課程之後常常感到困惑：所學知識有什麼用，怎樣運用所學知識?一些學生雖然能夠在考試中考出高分，卻不知道怎樣解決實際問題。如何使學生認識所學知識的用途，融會貫通並靈活運用，是這門課應重點考慮的問題。目前，案例教學在法律類和管理類課程教學中的地位和作用已在教育界達成共識。教育部高等學校計算機科學與技術教學指導委員會於2006年6月發布了《關於進一步加強高等學校計算機基礎教學的意見暨計算機基礎課程教學基本要求(試行)》白皮書，明確指出在教學方法和手段上運用案例教學的必要性，因此，將案例教學作為一種教學方法引入工科類課程的教學，具有可行性和必要性。

2、認識案例

案例教學法就是在教師的指導下，根據教學目的和要求，以案例為基本素材，把學生帶人特定的教學情境中進行思考，以此加深學生對基本原理和概念的理解，進而培養並提高學生運用理論知識分析問題和鋸決問題能力的一種教學方法。

案例是案例教學的基礎，離開了案例，案例教學就無從談起。案例與一般教學中的例題有著本質區別，案例教學中的案例是將多個知識點融人一個整體來解決實際問題，涉及的知識面廣，知識間具有連貫性和系統性，涵蓋的知識具有綜合性的特點，知識和原理蘊藏於案例之中。一般教學中的例題往往是配合某一章節或某一知識點，從某個角度、某個方面或某個層次反映所學理論和方法，起著驗證和說明作用，常常帶有為講知識而杜撰例子的痕跡，各個例題之間相對獨立，涵蓋的知識單一，知識和原理孤立地呈現在學生面前。一般說來，工科類課程的案例應具有以下基本特徵。

1)真實性。

客觀真實性是案例的基本特徵。教學案例應源於真實，取材於工程實際或科研課題，但是又要高於真實。為了突出主題，可以對真實做一定的刪減處理。

2)綜合性。

案例應是綜合知識的載體，既要以學生已掌握的知識為依據輻射足夠多的知識點，又要在匹配教學內容的基礎上對知識有一定程度的擴展。

3)完整性。

案例是完整過程的載體，涉及了解背景、查詢資料、分析信息、發現問題、探求方法、採取行動、解決問題的全過程。

4)啟發性。

案例教學著眼於能力的培養，希望得到的不是案例的標准答案，而是解決問題的思維方法和能力。案例中，解決問題的方式是開放性的，可以留給學生想像的空間和發揮的餘地。

5)實踐性。

學生可以對案例進行復現、改進和完善，也可以按照自己的思考去實現，增強理論應用於實際的能力，實現從理論到實踐的轉化。

3、案例建設

案例教學的前提是高質量的案例，高質量的案例既要覆蓋足夠的知識，又要控制合適的規模。規模過小，則不能溶入足夠的知識，也不能提供足夠的研討與思維空間;規模過大，則在短時間內難以被學生接受，不能得到預期的教學效果。筆者以實際工程項目衛星實時模擬系統的一個子系統為案例背景，在突出主題的前提下，進行了適當的詳略及刪減處理，形成了“實時模擬監視系統”案例。

3.1 案例背景簡介

衛星實時模擬系統能夠對衛星的方案、設計、集成、測試和運行各個階段進行模擬驗證，是提高衛星總體設計水平的重要手段，其網路關系連接如圖1所示。在此系統中，模擬模型解算、物理設備介面等苛刻實時約束的節點通過反射內存互聯，構成實時內環，外環則通過普通網路互聯，將人機交互、可視化、數據處理等實時約束弱的節點互聯，內、外環都可以根據需要擴充且內環不受外環影響，苛刻實時得到保障。轉發計算機完成內存數據的提取並轉發外環，模擬管理計算機則同時管理內、外環系統。衛星模擬監控是衛星實時模擬過程中的重要一環，它將抽象的模擬活動形象化，並及時將信號數據以各種方式反饋給用戶，以利於用戶分析、理解和決策。衛星實時模擬監控系統，能夠模擬通過控制、監視和測量星上設備的工作狀態實現實時連續地記錄工作過程、測試數據和描繪曲線。圖1中，人機交互計算機、曲線顯示計算機和三維顯示等外環計算機共同實現模擬監視功能。我們將人機交互計算機和曲線顯示計算機的功能提取出來，要求系統具有一定的通用性，能夠適應不同監視任務和不同數據類型，形成“實時模擬監視系統”案例。

3.2 實時模擬監視系統案例

實時模擬監視系統的工作原理為：轉發計算機完成內存數據的提取並轉發外環，外環上的實時模擬監視系統首先進行初始化，隨後自動生成系統主界面。系統支持兩種運行模式：監視模式和回放模式。在監視模式下，系統既要處理主界面信息，又要處理網路數據。主界面信息的處理包括響應用戶交互消息、更新實時監視界面、實時繪制曲線;網路數據的處理包接監聽網路埠，接收、解析和保存數據包，將有效數據寫入共享數據結構，供給系統繪制曲線。在回放模式下，不再需要對網路進行監聽，直接讀取監視模式下保存的原始數據文件，然後進行相應處理即可。

為實現上述目的，使系統具有一定的通用性，我們設計了如下方案：

(1)在軟體工程思想指導下，進行需求分析、總體設計、詳細設計、編碼實現以及綜合測試。通過該案例，讓學生對軟體工程思想指導下的軟體開發全過程有一個感性認識;

(2)採用多線程技術實現監視模式下的主界面信息處理和網路數據處理，僅用單線程實現回放模式;

(3)設計一個數據包發送測試程序，模擬轉發計算機的功能。

為此，我們結合本課程的基本知識點將系統的主要功能模塊劃分為界面管理和數據處理兩大部分，界面管理部分主要承擔主界面信息的處理，數據處理部分則主要負責數據的處理。

3.2.1 界面管理

系統運行過程中始終需要對系統主界面進行管理。從運行初期的生成主界面，到運行中的監視過程的顯示，再到最終的系統結束，都需要對主界面進行即時的調整。為了提高通用性，系統採用基於配置文件的方式，通過用戶提供的配置文件，動態改變系統監視任務，也就是說，系統能夠改變每次運行時的任務，主界面顯示的內容具有不確定性。

1)讀取配置文件，獲取初始化信息。

系統運行之前，需要進行初始化，這就需要系統讀取配置文件，包括全部信號、實時顯示信號、數據包類型等配置文件。用戶必須按照約定的正確格式提供配置文件，否則系統有可能無法正確識別相關信息。從軟體工程的角度，配置文件的設計與確定應在總體設計階段完成。配置文件的類型、組織方式以及數據正確性的檢驗，都是學生可以自由發揮和擴展的內容。

2)自動生成實時監視界面。

監視對象的不確定性使得系統的監視界面無法固定，然而，不能將界面的生成工作完全交給用戶完成，這就需要設計一種適用於不同監視任務的界面生成演算法，使系統將界面生成工作承擔下來。另外，系統界面的尺寸等信息是用戶所不知道的，因此被監視的信號在系統主界面中的顯示位置無法由用戶設定，這就需要系統自己完成界面的排布任務。因此，要求設計一個具有較強通用性的監視界面自適應生成演算法，這部分涉及演算法設計和計算機系統配置的獲取等基礎知識，演算法設計是學生能夠自由發揮並出彩的部分。

3)定時更新監視界面。

為了實現實時監視功能，系統需要對監視界面進行定時更新，以顯示當前被監視信號的實時數據。為了滿足用戶的不同需求，系統提供0.5s、1s、2s三種刷新頻率。系統可以根據用戶選擇的刷新頻率對主界面進行更新。這部分主要涉及定時器的使用。

4)處理用戶交互消息。

系統需要對用戶的交互消息進行處理，主要為滑鼠消息，包括運行模式的切換、模擬的開始與結束、載入歷史數據包文件等。這部分涉及所選編程環境下的消息響應機制問題。

3.2.2 數據處理

系統在運行過程中，需要對數據包進行接收、解析和存儲，還要為曲線繪制提供原始數據，因此需要設計一個專用的數據結構。

1)接收網路數據包。

在監控模式下，系統既要處理主界面信息，又要通過網路接收數據包。為了避免“漏掉”數據包，系統必須對網路持續進行監聽。如果主線程將大量時間用在網路監聽上，勢必無法對用戶的交互做出及時響應。因此，需要將數據包的接收放在一個單獨的線程中。這涉及操作系統進程管理的相關概念，是多線程程序設計技術的典型應用;也涉及網路通信技術，需要了解網路通信協議等相關知識。

2)解析數據包。

在接收到數據包後，需要將數據包內的數據進行解析，獲得數據包內的數據，將最新的數據更新至系統對應的變數中，以供實時顯示。解析數據包涉及網路通信程序設計技術。

3)保存原始數據包。

系統要求有回放功能，因此需要將接收到的數據包寫入文件，進行永久保存。數據包的保存有兩種方式：解析後按段保存和作為整體進行二進制保存。第一種方法耗時，需較大工作量。第二種方法簡便，工作量小。顯然第二種方法更適合本系統。由於系統必須適應兩種類型的數據包，因此，進行數據保存時，採用以形參類型為區別的方式進行同名函數的重載，實現兩種類型數據包文件的存儲。這部分功能涉及C++面向對象程序設計中的重載技術以及文件操作技術。

4)讀取數據文件，獲取數據包。

在回放模式下，系統不再對網路進行監聽，不進行數據包的接收，需要通過讀取之前保存的原始數據包文件獲得數據包。原始數據包文件保存的是二進制形式的數據包，系統每次讀取之後需要對數據包進行解析，這與接收到數據包的過程是一樣的，不同之處在於回放過程不再需要將數據包進行保存。這涉及C++面向對象程序設計中的文件操作，同時，通過監視模式下的多線程程序設計與回放模式下的單線程程序設計的對比，使學生真切感受並理解多線程程序設計技術及其應用場合等。

5)共享數據。

系統嵌套了曲線繪制模塊，因此，數據處理與曲線繪制之間需要有一塊共享數據內存。在收到數據包並解析後，馬上將有用的信息寫入該共享內存。寫入操作由數據包接收線程處理，讀取操作由主線程內的曲線繪制模塊完成，因此，需要對兩個線程進行同步。這涉及數據結構的設計和操作系統的同步與互斥。

6)快速查找。

系統支持大數據量下的模擬監視，對數據的快速查找有較高的需求，因此，需要設計支持快速查找的哈希表數據結構，包括哈希函數的確定、沖突的解決等，這涉及數據結構的哈希表技術。

4、結語

“實時模擬監視系統”案例，涵蓋了軟體工程、c++面向對象程序設計、演算法與數據結構、操作系統和網路通信等計算機軟體技術基礎課程及其先導與後繼課程的知識點，是一個與學生所學專業密切相關的實際應用系統，容易引起學生的興趣，也容易被學生理解和接受。這樣的案例既與教學目標相吻合，又便於教師駕馭和把握。

從學生反饋的情況看，學生普遍認為，案例教學法方式新穎，實時模擬監視系統案例與專業基礎結合緊密;能引導學生積極思考，提高學生的學習興趣以及分析問題和解決問題的能力。該案例在教學過程中取得了明顯的教學效果。

為了更好地開展案例教學，我們必須把建設高質量的案例作為重點來抓，選擇合適的案例背景，制定合理的案例建設計劃。實踐證明，只有經過長時間的積累、認真的思考、精心的選擇和多次教學實踐，才能獲得高質量的教學案例;只有經過團隊的長期努力，才能建設高質量的教學案例庫。

點擊下頁還有更多>>>計算機軟體技術基礎淺談論文