有些朋友在Essay写作的时候不知道Essay写作摘要怎么写，这篇文章为大家讲解Essay写作摘要，祝大家留学顺利。
写一个有效的摘要是艰苦的工作，但会被引诱别人来了解你的出版物，这对你的Essay影响力都睡有所增加。确保自己能写出一个良好的摘要，摘要中所有组件一个都不能少，下文则为大家一一介绍。
在Essay摘要的定义
因为在网上搜索数据库通常只包含摘要，至关重要的是写你一个完整的工作，但简洁的描述，潜在读者诱使获取全文的复印件。本文介绍如何编写为会议和期刊Essay了良好的计算机体系结构的摘要。作家应遵循组成的清单：动机，问题的陈述，方法，结果和结论。根据这一清单应增加人们花时间来获取和阅读您的完整纸张的机会。
写一个好的摘要的重要性
现在，使用在线发布数据库的盛行，写一个很好的摘要比十年前变得更加重要。摘要一直担任“推销”你的工作的功能。但现在，而不是仅仅说服读者继续阅读所附本文的其余部分，摘要必须说服读者离开办公室的舒适性和去从库追捕文章的复印件（或者更糟，获取一个通过后馆际互借漫长的等待）。在商业环境中，一个“执行摘要”，往往是谁重要的人阅读报告的唯一的一块;它应该是在内容上类似的如果不是口气期刊Essay摘要。
摘要：一种方法来揭示问题，结果
我们为什么要关心这个问题，结果如何？如果问题显然不是“有趣”这可能是最好先放动机;但如果你的工作是被广泛认为是重要的问题逐步取得进展，那么它可能是最好首先把问题陈述，表明这一块你掰工作的更大的问题。这部分应该包括你的工作的重要性，该地区的困难，它可能如果成功的影响。
问题陈述：
什么问题是你想解决？什么是你的工作范围（广义的方法，或特定的情况）？要小心，不要使用太多行话。在某些情况下是合适的动机之前，把问题的陈述，但通常如果大多数读者已经明白为什么这个问题很重要，这样才有效。
做法：
你是如何去解决或作出有关问题的进展？你用仿真，分析模型，样机制造，或现场数据的分析为实际的产品？什么是你的工作的程度（你看一个应用程序或一百节目20种不同的编程语言？）你控制什么重要的变量，忽略或测量？
结果：
答案是什么？具体来说，最擅长计算机体系结构的Essay得出结论，事情是这么多％的更快，更便宜，更小，或以其他方式比什么都好。把结果在那里，在数字。避免含糊不清，手挥舞着的结果，如“非常”，“小”或“显著”。如果你必须是模糊的，你只给授权这样做时，你可以谈论的订单数量级的提高。有在这里，你不应该提供可以很容易误解的数字张力，但在另一方面，你没有足够的空间为所有的注意事项。
How to Write an Abstract
Writing an efficient abstract is hard work, but will repay you with increased impact on the world by enticing people to read your publications. Make sure that all the components of a good abstract are included in the next one you write.
The definition of abstract in thesis
Because on-line search databases typically contain only abstracts, it is vital to write a complete but concise description of your work to entice potential readers into obtaining a copy of the full paper. This article describes how to write a good computer architecture abstract for both conference and journal papers. Writers should follow a checklist consisting of: motivation, problem statement, approach, results, and conclusions. Following this checklist should increase the chance of people taking the time to obtain and read your complete paper.
The importance of writing a good abstract
Now that the use of on-line publication databases is prevalent, writing a really good abstract has become even more important than it was a decade ago. Abstracts have always served the function of "selling" your work. But now, instead of merely convincing the reader to keep reading the rest of the attached paper, an abstract must convince the reader to leave the comfort of an office and go hunt down a copy of the article from a library (or worse, obtain one after a long wait through inter-library loan). In a business context, an "executive summary" is often the only piece of a report read by the people who matter; and it should be similar in content if not tone to a journal paper abstract.
Abstract: a way to reveal the problem and the result
Why do we care about the problem and the results? If the problem isn't obviously "interesting" it might be better to put motivation first; but if your work is incremental progress on a problem that is widely recognized as important, then it is probably better to put the problem statement first to indicate which piece of the larger problem you are breaking off to work on. This section should include the importance of your work, the difficulty of the area, and the impact it might have if successful.
Problem statement:
What problem are you trying to solve? What is the scope of your work (a generalized approach, or for a specific situation)? Be careful not to use too much jargon. In some cases it is appropriate to put the problem statement before the motivation, but usually this only works if most readers already understand why the problem is important.
Approach:
How did you go about solving or making progress on the problem? Did you use simulation, analytic models, prototype construction, or analysis of field data for an actual product? What was the extent of your work (did you look at one application program or a hundred programs in twenty different programming languages?) What important variables did you control, ignore, or measure?
Results:
What's the answer? Specifically, most good computer architecture papers conclude that something is so many percent faster, cheaper, smaller, or otherwise better than something else. Put the result there, in numbers. Avoid vague, hand-waving results such as "very", "small", or "significant." If you must be vague, you are only given license to do so when you can talk about orders-of-magnitude improvement. There is a tension here in that you should not provide numbers that can be easily misinterpreted, but on the other hand you don't have room for all the caveats.
