软件开发方法外文文献

Software Development Methodologies Introduction

Software methodologies are concerned with the process of creating software - not so much the technical side but the organizational aspects. In this, the first of two articles, I will introduce the different types of methodologies. I will describe them from an historical perspective, as one way to understand where we are and where we are going is to know where we have been.

There will also be a subsequent companion article looking at the current state of the art and what I believe the future holds. This second article is given the rather controversial title of "Why Creating Software is not Engineering", which I will, of course, explain. In the 2nd article I will discuss several popular agile methodologies particularly their most important aspects (such as unit testing), which are generally neglected or glossed over.

Before beginning I should warn the reader of my penchant for analogy. Actually this whole article is one big analogy stretched almost to breaking point. I like them because many of the concepts in software development are abstract and hard to grasp, but using a familiar real-world situation, like taking a taxi to the pub, can clarify the ideas. Of course, there is always the caveat that no analogy is perfect. Be careful to understand the similarities and the differences.

Ad-hoc

Historically, the first methodology was basically no methodology at all. This is generally called the "ad hoc" methodology.

We'll start with a simple scenario. You are to meet your friend Jim at the Station Hotel. You have no idea where that is but you jump in a cab and tell the taxi driver where you want to go. A few minutes later you arrive at your destination safely and without wasting any drinking time!

In this analogy you are the "customer" and the taxi driver is the "developer". The above is the ideal case where the customer knows where they want to go and the developer knows how to get there. Unfortunately the real world is never this simple. Consider these variations.

Problems

1. You tell the driver where to go but you end up at the train station not the Station Hotel. Obviously he misheard you and after all many of his passengers go there.

You clarify the situation but the taxi driver is uncommunicative and you end up at the wrong hotel. Eventually, you work out that the driver does not speak English well.

At some point you give up. If you are really persistent you might get to your destination but by then Jim has already left.

2. You ask the taxi driver to take you to the Station Hotel to which the immediate reply is "Which one?". Apparently, there are three within a ten mile radius and you don't know which one Jim went to. You try them all but can't find Jim.

The driver suggests it might be the "Fire Station Hotel" which was actually not far from where you started.

3. The taxi driver kindly informs you that your destination is quite distant and you do not have

enough money. He suggests that you take the bus.

Of course, the bus is slow and does not go directly past the pub. You get there eventually.

4. The taxi takes you straight to the hotel but it's closed for business.

5. You are half way there when you realise you need to post a letter. Then Jim calls your mobile and says that he has gone to a different hotel. Then you get stuck in traffic and also need to use the bathroom. The whole trip is much longer and more expensive than expected.

6. The taxi driver seems to know where to go but is inexperienced and after quite a while he realises that he is going completely the wrong direction. Several times he has to backtrack but eventually finds the destination though the trip takes much longer than expected.

I'm sure you can think of many more things that can go wrong.

Summary

The ad-hoc methodology can work provided you have a simple problem. If the customer knows exactly what they want and the developer knows how to give it to them and has the right tools to do so (a reliable vehicle and a street directory if necessary) then there is a good chance of success. However, most of the time you get there late or not at all.

The above scenarios represent several common problems seen in software development, namely miscommunication (1), a customer who doesn't know exactly what they want (2) or thinks they do until they try it (4), changing requirements (5) and inexperienced developers (6). I leave it the reader to work out what scenario 3 means.

Waterfall

OK, you want to avoid all the above problems, but what do you do? Conventional wisdom is to ask an expert for help and there are many willing helpers ready to provide their services, for a fee, of course. You find that you need an "analyst" to work out where you really want to go and a "designer" to provide detailed unambiguous instructions on how to get there.

The analyst works out by deduction and/or educated guesswork exactly which "Station Hotel" you want. Perhaps they even manage to contact Jim to confirm the location. They also find out the exact address and the opening hours.

Now you know exactly where you want to go but how to get there? The designer provides a "specification" or instructions for getting to the hotel - eg proceed 2 miles to the roundabout, take the 3rd exit, etc. To ensure that the driver understands the instructions the essential parts are even translated into his native language. A good designer might also try to anticipate problems and have contingency plans - eg, if the freeway has heavy traffic to take an alternative route.

The essential point of the specification is to have the trip completely and thoroughly planned before starting out. Everybody involved reads the specification and agrees that this should get the customer to the pub on time. Can you see a problem with this approach?

While the analyst/designer is busy at work you (the customer) are getting a bit nervous. It's been some time and you still haven't gone anywhere. You also want feedback that once you start the trip everything will stay on track, since your experience of taxi journeys is that they can be very unpredictable and the driver never gives any indication of whether he is lost or on course.

You need a "plan" so that you can check that everyone is doing there job and that if something is amiss it will be immediately apparent. The plan will also require the driver to regularly report his position so you know if he is going to be late or not get there at all. For a large project you will need a "project manager" to formulate the plan.

Problems

This all sounds very thorough and reassuring but there are many problems with this approach. 1. First the taxi driver has to read and understand the whole specification before starting out - for example, he might have to work out where he can buy fuel if necessary. The specification is complex and detailed and it can take some time before the driver understands it enough to begin.

2. The taxi driver attempts to follow the specifications exactly but there are a few small ambiguities and he makes a wrong assumption. By the time he realises the mistake he has gone for miles in the wrong direction and has to backtrack.

3. There are crucial assumptions in the specification that nobody checked. For example, you can never get a taxi after 8pm on a Friday. The designer had not considered this but his excuse is that it was outside his purview - the customer should know this since he is the one that catches taxis and after all he signed off on the specification.

4. Things happen that were not anticipated. For example, unexpected traffic snarls cause slow progress.

5. There are problems that the designer was not aware of. For example, roadworks that require a lengthy detour. The taxi driver knew about it but nobody asked him.

6. There are problems that nobody was aware of. For example, the planned route goes the wrong way down a one-way street, even though it was not marked as such on any map.

7. There are some things that you (the customer) forgot to mention - eg, you need to stop at the bank to get some cash on the way. It seems like a minor thing to you, but the designer complains that it completely invalidates most of the specifications (though he exaggerates of course).

8. There are unexpected events that nobody could have anticipated such as a major accident that causes traffic chaos.

9. The taxi driver becomes annoyed and frustrated with the process. "Just tell me where you want to go!"

10. The project plan estimates that the journey will take an hour. The passenger immediately starts reading a book or falls asleep in the back seat. The taxi driver thinks it will take half that time, especially as he knows a shortcut. He dawdles for awhile, makes some detours to take care of some personal business, and loses track of the time. The customer wakes up and wonders where he is - the driver assures him that all is going to plan.

However by now there is only 15 minutes to go and he's hardly made any progress. He finds the road for his shortcut has been closed, then gets booked for speeding. In the end he makes a huge effort and only arrives 20 minutes late. Ironically, he is praised by all for being so dedicated.

11. The designer knows from past experience that taxi drivers vary widely in ability. The specification is written to the lowest common denominator, even though this demeans the average taxi driver.

12. The designer knows that the taxi driver has a tendency to deviate from his specification. This

can be at the behest of his passenger (see 7 above), or he may take the scenic route to make the trip more pleasant (and increase the fare), or take a shortcut that may save time but has many risks involved, or simply take a diversion out of some personal interest.

To counter this, the designer will try to limit the information provided to the driver to only what they need to know. As an extreme example the designer might cover all the windows of the taxi and make the driver navigate entirely using the odometer and a compass. Obviously, this a very dangerous approach as the driver has no feedback at all in order to correct for even the slightest deviation from the course.

13.You start the journey but there are a lot of problems and delays. You manage to contact Jim and arrange to meet him at a nearby hotel which is actually more convenient for both of you. (Unfortunately this completely invalidates the specification which is discarded.)

Summary

The waterfall model can work if everything goes to plan, but in a complex project things rarely do. The crux of the problem is the reliance on getting the specification perfect before attempting to implement it. Unfortunately, even if you get close to getting it right at the start things will change. For most real-world projects this means this approach is doomed to failure, or at best a late and over-budget project and a very frustrating experience.

The above scenarios represent several common problems with the waterfall methodology namely the difficulty of understanding (1) and following the specifications (2) and getting them right in the first place (3, 5, 6, 7). The process does not cope with change (4, 8, 13) and does not make best use of the developers (9, 11, 12).

A major problem is that without hard deliverable milestones most developers will procrastinate at the start (10). However, to be fair this behaviour is reinforced by the fact that the most projects have major changes (or are even cancelled) well after development has started. To the developer there is no point in working hard at the start when in all likelihood the effort will be wasted.

Prototype

The prototype methodology addresses the major problem of the waterfall methodology's "specification", which is that you are never sure it will work until you arrive at your destination. It is difficult or impossible to prove that the specification is correct so we instead create a simple working example of the product, much like an architect would create a scale model of a proposed new building.

To continue our taxi analogy the designer, or a delegate, grabs a motorbike to first check that you can actually get to the Station Hotel and even explore a few alternative routes. When the motorbike driver has found a good way the actual taxi trip can begin.

Problems

1. A motorbike is not a car. It can bypass traffic snarls or pass through narrow lanes that a car cannot. In his eagerness to prove the feasibility of the trip the designer may gloss over the fact that the taxi trip will take a lot longer.

2. To you (the customer) it seems that creating a prototype is a waste of time, since your trip can't begin until the motorbike has arrived. (The taxi could start out before the motorbike arrives but there is always the risk that a better route is found and the taxi has to backtrack.)

3. You decide that if the motorbike can get there so easily why not just jump on the back and avoid taking the more expensive taxi trip altogether. The problem with this is the motorbike trip may be far less pleasant. Moreover, the motorbike is not designed to take a passenger and can become unstable with you and your luggage causing an accident.

Summary

The prototype approach is good if there are a lot of unknowns about how the best approach or even the feasibility of the project. Different routes can be quickly explored and the best decided on. However, if the best route is obvious and well travelled then creating a prototype is unnecessary. In the end completing the project may not be made that much easier by having a prototype.

The above scenarios represent these problems often encountered with prototypes: creating the final product can be a lot more difficult than creating the prototype (1) and the use of a prototype may not be of much benefit anyway (2). A major problem is that once a customer tries a working prototype of the software there can be pressure to simply use the prototype rather than develop the full product even though the prototype may be completely unsuitable in many non-obvious ways (3)

4GL

This is not so much a methodology as an approach that tries to use new technology. The idea, pushed heavily in the 1980's, is that very high level languages could be developed to allow users to create their own applications. These so-called "4th generation languages" were supposedly easy enough for anyone to use.

In our analogy this is like getting rid of the taxi driver altogether. Of course, most people can't drive taxis (in the analogy) so we need a simple system where the user just has simplified controls. Unfortunately, the only way this was possible is to create a huge network of guidance rails to keep the taxis on track.

Problems

1. You get in the taxi, enter the destination, and you get an obscure error message. You go nowhere.

2. The cost of the rail network is enormous so it doesn't go to very many destinations yet.

3. You need to go by a long and circuitous route even though your destination is not that far away.

Summary

The idea is good but in general it is not workable. Perhaps one day, with advances in AI, this

approach can work.

The above problems mean: the technology is not good enough (1) and expensive to develop (2). In practice the product is slow and cumbersome (3) and gives generally unsatisfactory results compared to other methods (2).

Iterative

The precursor to today's agile methodologies (see below) can be loosely grouped as "iterative". They are also often described as "cascade" methods as they are really just a series of small waterfalls.

I am not going to discuss these in detail as they were not very widely used (except nominally) or very successful. They were more an attempt to fix the problems of the waterfall methodology rather than to bypass them altogether. As such they had many of the same problems, and even exacerbated some.

Agile

The main problem with the waterfall approach is that it takes a lot of effort up front effort in planning, analysis and design. When it comes to the actual implementation there are so many variables and unknowns that it is very unlikely to go to plan.

The prototype approach meant we could eliminate some of this uncertainty by demonstrating that there is a reasonable chance of success. However, there is still a lot of up front effort to design and build the prototype even before we even start the real development.

What if we could divide the project into a sequence of steps so that at each stage we can demonstrate that we are closer to the final product? After each step we produce a working (but not final) product so that the customer can see that the project is on the right track.

To continue our taxi analogy we can start our journey immediately since we know that to get to any of the possible destinations we have to take the main road into town. When we come to a point where there is uncertainty we stop to assess the position and choose the best path. Further, by continually re-assessing we can adapt to any unforeseen and new developments.

On the surface this looks very much like the "ad hoc" methodology in that you just jump in the taxi and go. Indeed, it does empower the taxi driver with finding the best way again but the feedback mechanism allows more people to see what is happening and to keep things on course. It also does not preclude the use of extra team members to ensure the trip is smooth and trouble free. A navigator could monitors traffic conditions, looks for trouble spots and try to find the best way to the destination. A mechanic could ensure that the taxi is always in good condition and will not break down.

But there are still pitfalls to watch out for.

Problems

1. You (the passenger) are sure you know where you want to go, the trip proceeds smoothly but when you get there you find that nobody else thinks it is the right place. Jim is not there but at another hotel.

2. The trip is proceeding smoothly but when you are halfway there things change completely - Jim rings to say he has gone in the opposite direction. There is a lot already invested in the trip so there is a reluctance to just abandon it and start again - after all that is the "waterfall" way of doing things.

3. The direct route is straight down the hill and over the old bridge. A much slower path is taken to mitigate the risks and so the customer always has the destination in sight. The quickest way would have been the direct route but was not seen as the "right" way to do it.

4. There are two equally good ways to the destination, via the north or south side of the mountain. However, the driver wants to go one way and the navigator the other. As a compromise they choose the worst possible way - right over the top of the mountain.

Summary

The advantage of the agile methodology is that the development team is happy since they are empowered not just to drive the taxi but to navigate and ensure that everything goes smoothly. The customer is happy because he knows the driver is not lost and, even if he is late, at every stage he knows where he is and still has a good idea when he will get there.

However, there are still potential problems to watch out for. One problem is a customer representative who does not really know what is best for the "real" customer (1). Agile methods are evolutionary but sometimes you can't evolve the existing software into what is really required (2). For a simple, well understood project "ad hoc" may still be better (3). Finally group decisions may not always be the best decisions (4).

Totalitarian

Finally, I introduce a class of methodology that I have experienced but never seen described. In many ways it is like the agile methodology taken to the extreme. The customer is highly involved in the development and releases are not every few weeks but daily or even more often.

This typically occurs when the customer is a former taxi driver and wants complete control of the product and the process; hence I have called this methodology "totalitarian". An alternative name might be "back seat driver".

Problems

1. At every turn you (the passenger) check the roadmap and make suggestions or even tell the driver he is going the wrong way. The taxi driver has to stop and check to make sure but mainly to reassure the passenger.

2. With the constant barrage of instructions the driver becomes confused and even forgets where he is going. The immediate direction is constantly changing.

3. The driver stops thinking about where he is going and just follows your direction. You end up at the end of a dead-end one -way street.

Summary

This approach has no advantage over the agile and has many disadvantages. First, like the waterfall approach it disempowers the developers (2, 3), with consequent effects on their quality of work and hence productivity. There is no clear goal and no sense of accomplishment as there is at the end of each sprint in the agile approach.

It is also difficult to make any sort of significant change to a piece of software and keep it in a consistent state (1, 2). For this reason producing a new "release" should not be attempted more often than weekly. Developers need time to do their own testing and integrate input from different team members. Using this approach you can waste time chasing your own tail, by tracking down non-problems that would eventually "come out in the wash".

Further, the customer needs to do a lot of testing to provide daily feedback. Testing the same thing many times becomes tedious and eventually the customer becomes less diligent and bugs get past them.

Conclusion

Unfortunately when developing software there are many more variables and unknowns than in a simple taxi trip. In this strange world the Station Hotel may not be stationary hotel - it can move or even dispappear or there can be a myriad of hotels all seemingly the same. The roads may be unmapped and always changing.

I should also mention that there are things that can go wrong that are beyond the bounds of any development methodology - the Station Hotel may explode, who knows? There are car accidents and break downs.

I hope this article has given you insight into the different software development methodologies. In my next article I will look at the state of the art, in particular some agile methodologies. I will also emphasize what areas I believe are important and what the future may hold.

软件开发概念和设计方法大学毕业论文外文文献翻译及原文

毕业设计（论文）外文文献翻译 文献、资料中文题目：软件开发概念和设计方法文献、资料英文题目： 文献、资料来源： 文献、资料发表（出版）日期： 院（部）： 专业： 班级： 姓名： 学号： 指导教师： 翻译日期： 2017.02.14

外文资料原文 Software Development Concepts and Design Methodologies During the 1960s, ma inframes and higher level programming languages were applied to man y problems including human resource s yste ms,reservation s yste ms, and manufacturing s yste ms. Computers and software were seen as the cure all for man y bu siness issues were some times applied blindly. S yste ms sometimes failed to solve the problem for which the y were designed for man y reasons including: ?Inability to sufficiently understand complex problems ?Not sufficiently taking into account end-u ser needs, the organizational environ ment, and performance tradeoffs ?Inability to accurately estimate development time and operational costs ?Lack of framework for consistent and regular customer communications At this time, the concept of structured programming, top-down design, stepwise refinement，and modularity e merged. Structured programming is still the most dominant approach to software engineering and is still evo lving. These failures led to the concept of "software engineering" based upon the idea that an engineering-like discipl ine could be applied to software design and develop ment. Software design is a process where the software designer applies techniques and principles to produce a conceptual model that de scribes and defines a solution to a problem. In the beginning, this des ign process has not been well structured and the model does not alwa ys accurately represent the problem of software development. However,design methodologies have been evolving to accommo date changes in technolog y coupled with our increased understanding of development processes. Whereas early desig n methods addressed specific aspects of the

快速外文文献翻译

快速外文文献翻译 在科研过程中阅读翻译外文文献是一个非常重要的环节，许多领域高水平的文献都是外文文献，借鉴一些外文文献翻译的经验是非常必要的。由于特殊原因我翻译外文文献的机会比较多，慢慢地就发现了外文文献翻译过程中的三大利器：Google“翻译”频道、金山词霸（完整版本）和CNKI“翻译助手"。 具体操作过程如下： 1.先打开金山词霸自动取词功能，然后阅读文献； 2.遇到无法理解的长句时，可以交给Google处理，处理后的结果猛一看，不堪入目，可是经过大脑的再处理后句子的意思基本就明了了； 3.如果通过Google仍然无法理解，感觉就是不同，那肯定是对其中某个“常用单词”理解有误，因为某些单词看似很简单，但是在文献中有特殊的意思，这时就可以通过CNKI的“翻译助手”来查询相关单词的意思，由于CNKI的单词意思都是来源与大量的文献，所以它的吻合率很高。 另外，在翻译过程中最好以“段落”或者“长句”作为翻译的基本单位，这样才不会造成“只见树木，不见森林”的误导。 注： 1、Google翻译：https://www.sodocs.net/doc/b814124495.html,/language_tools google，众所周知，谷歌里面的英文文献和资料还算是比较详实的。我利用它是这样的。一方面可以用它查询英文论文，当然这方面的帖子很多，大家可以搜索，在此不赘述。回到我自己说的翻译上来。下面给大家举个例子来说明如何用吧比如说“电磁感应透明效应”这个词汇你不知道他怎么翻译， 首先你可以在CNKI里查中文的，根据它们的关键词中英文对照来做，一般比较准确。 在此主要是说在google里怎么知道这个翻译意思。大家应该都有词典吧，按中国人的办法，把一个一个词分着查出来，敲到google里，你的这种翻译一般不太准，当然你需要验证是否准确了，这下看着吧，把你的那支离破碎的翻译在google里搜索，你能看到许多相关的文献或资料，大家都不是笨蛋，看看，也就能找到最精确的翻译了，纯西式的！我就是这么用的。 2、CNKI翻译：https://www.sodocs.net/doc/b814124495.html, CNKI翻译助手，这个网站不需要介绍太多，可能有些人也知道的。主要说说它的有点，你进去看看就能发现：搜索的肯定是专业词汇，而且它翻译结果下面有文章与之对应（因为它是CNKI检索提供的，它的翻译是从文献里抽出来的），很实用的一个网站。估计别的写文章的人不是傻子吧，它们的东西我们可以直接拿来用，当然省事了。网址告诉大家，有兴趣的进去看看，你们就会发现其乐无穷！还是很值得用的。https://www.sodocs.net/doc/b814124495.html, 3、网路版金山词霸（不到1M）：https://www.sodocs.net/doc/b814124495.html,/6946901637944806 翻译时的速度： 这里我谈的是电子版和打印版的翻译速度，按个人翻译速度看，打印版的快些，因为看电子版本一是费眼睛，二是如果我们用电脑，可能还经常时不时玩点游戏，或者整点别的，导致最终SPPEED变慢，再之电脑上一些词典（金山词霸等）在专业翻译方面也不是特别好，所以翻译效果不佳。在此本人建议大家购买清华大

人工智能专业外文翻译-机器人

译文资料： 机器人 首先我介绍一下机器人产生的背景，机器人技术的发展，它应该说是一个科学技术发展共同的一个综合性的结果，同时，为社会经济发展产生了一个重大影响的一门科学技术，它的发展归功于在第二次世界大战中各国加强了经济的投入，就加强了本国的经济的发展。另一方面它也是生产力发展的需求的必然结果，也是人类自身发展的必然结果，那么随着人类的发展，人们在不断探讨自然过程中，在认识和改造自然过程中，需要能够解放人的一种奴隶。那么这种奴隶就是代替人们去能够从事复杂和繁重的体力劳动，实现人们对不可达世界的认识和改造，这也是人们在科技发展过程中的一个客观需要。 机器人有三个发展阶段，那么也就是说，我们习惯于把机器人分成三类，一种是第一代机器人，那么也叫示教再现型机器人，它是通过一个计算机，来控制一个多自由度的一个机械，通过示教存储程序和信息，工作时把信息读取出来，然后发出指令，这样的话机器人可以重复的根据人当时示教的结果，再现出这种动作，比方说汽车的点焊机器人，它只要把这个点焊的过程示教完以后，它总是重复这样一种工作，它对于外界的环境没有感知，这个力操作力的大小，这个工件存在不存在，焊的好与坏，它并不知道，那么实际上这种从第一代机器人，也就存在它这种缺陷，因此，在20世纪70年代后期，人们开始研究第二代机器人，叫带感觉的机器人，这种带感觉的机器人是类似人在某种功能的感觉，比如说力觉、触觉、滑觉、视觉、听觉和人进行相类比，有了各种各样的感觉，比方说在机器人抓一个物体的时候，它实际上力的大小能感觉出来，它能够通过视觉，能够去感受和识别它的形状、大小、颜色。抓一个鸡蛋，它能通过一个触觉，知道它的力的大小和滑动的情况。第三代机器人，也是我们机器人学中一个理想的所追求的最高级的阶段，叫智能机器人，那么只要告诉它做什么，不用告诉它怎么去做，它就能完成运动，感知思维和人机通讯的这种功能和机能，那么这个目前的发展还是相对的只是在局部有这种智能的概念和含义，但真正完整意义的这种智能机器人实际上并没有存在，而只是随着我们不断的科学技术的发展，智能的概念越来越丰富，它内涵越来越宽。 下面我简单介绍一下我国机器人发展的基本概况。由于我们国家存在很多其

毕业设计外文翻译资料

外文出处： 《Exploiting Software How to Break Code》By Greg Hoglund, Gary McGraw Publisher : Addison Wesley Pub Date : February 17, 2004 ISBN : 0-201-78695-8 译文标题： JDBC接口技术 译文： JDBC是一种可用于执行SQL语句的JavaAPI（ApplicationProgrammingInterface应用程序设计接口）。它由一些Java语言编写的类和界面组成。JDBC为数据库应用开发人员、数据库前台工具开发人员提供了一种标准的应用程序设计接口，使开发人员可以用纯Java语言编写完整的数据库应用程序。 一、ODBC到JDBC的发展历程 说到JDBC，很容易让人联想到另一个十分熟悉的字眼“ODBC”。它们之间有没有联系呢？如果有，那么它们之间又是怎样的关系呢？ ODBC是OpenDatabaseConnectivity的英文简写。它是一种用来在相关或不相关的数据库管理系统（DBMS）中存取数据的，用C语言实现的，标准应用程序数据接口。通过ODBCAPI，应用程序可以存取保存在多种不同数据库管理系统（DBMS）中的数据，而不论每个DBMS使用了何种数据存储格式和编程接口。 1．ODBC的结构模型 ODBC的结构包括四个主要部分：应用程序接口、驱动器管理器、数据库驱动器和数据源。应用程序接口：屏蔽不同的ODBC数据库驱动器之间函数调用的差别，为用户提供统一的SQL编程接口。 驱动器管理器：为应用程序装载数据库驱动器。 数据库驱动器：实现ODBC的函数调用，提供对特定数据源的SQL请求。如果需要，数据库驱动器将修改应用程序的请求，使得请求符合相关的DBMS所支持的文法。 数据源：由用户想要存取的数据以及与它相关的操作系统、DBMS和用于访问DBMS的网络平台组成。 虽然ODBC驱动器管理器的主要目的是加载数据库驱动器，以便ODBC函数调用，但是数据库驱动器本身也执行ODBC函数调用，并与数据库相互配合。因此当应用系统发出调用与数据源进行连接时，数据库驱动器能管理通信协议。当建立起与数据源的连接时，数据库驱动器便能处理应用系统向DBMS发出的请求，对分析或发自数据源的设计进行必要的翻译，并将结果返回给应用系统。 2．JDBC的诞生 自从Java语言于1995年5月正式公布以来，Java风靡全球。出现大量的用java语言编写的程序，其中也包括数据库应用程序。由于没有一个Java语言的API，编程人员不得不在Java程序中加入C语言的ODBC函数调用。这就使很多Java的优秀特性无法充分发挥，比如平台无关性、面向对象特性等。随着越来越多的编程人员对Java语言的日益喜爱，越来越多的公司在Java程序开发上投入的精力日益增加，对java语言接口的访问数据库的API 的要求越来越强烈。也由于ODBC的有其不足之处，比如它并不容易使用，没有面向对象的特性等等，SUN公司决定开发一Java语言为接口的数据库应用程序开发接口。在JDK1．x 版本中，JDBC只是一个可选部件，到了JDK1．1公布时，SQL类包（也就是JDBCAPI）

外文翻译---硬件软件的设计和开发过程知识讲解

附录 一、英文原文 Hardware/Software Design and Development Process Everett Lumpkin and Michael Gabrick Delphi Corporation, Electronics and Safety Division INTRODUCTION Process and technology advancements in the semiconductor industry have helped to revolutionize automotive and consumer electronics. As Moore’s Law predicted, the increase in complexity and operating frequencies of today’s integrated circuits have enabled the creation of system applications once thought to be impossible. And systems such as camera cell phones, automotive infotainment systems, advanced powertrain controllers and handheld personal computers have been realized as a result. In addition to the increases in process technology, the Electronic Design Automation (EDA) industry has helped to transform the way semiconductor integrated circuits (IC) and subsequent software applications are designed and verified. This transformation has occurred in the form of design abstraction, where the implementation continues to be performed at higher levels through the innovation of design automation tools. An example of this trend is the evolution of software development from the early days of machine-level programming to the C++ and Java software written today. The creation of the assembler allowed the programmer to move a level above machine language, which increased the efficiency of code generation and documentation, but still tied the programmer to the underlying hardware architecture. Likewise, the dawn of C / C++ compilers, debuggers and linkers helped to move the abstraction layer further away from the underlying hardware, making the software completely platform independent, easier to read, easier to debug and more efficient to manage. However, a shift to higher levels of software abstraction has not translated to a reduction in complexity or human resources. On the contrary, as integrated systems have become more feature rich, the complexity of the operating system and corresponding applications have increased rapidly, as have the costs associated with the software implementation and verification activities. Certainly the advancements in embedded software tools such as static code checkers, debuggers and hardware emulators have helped to solve some of the software verification problems, but software verification activities have become more time and resource consuming than the actual software creation. Time-to-market constraints have pushed software verification activities to the system-level, and led to a greater demand for production hardware to be made available earlier in

英文文献翻译

中等分辨率制备分离的 快速色谱技术 W. Clark Still,* Michael K a h n , and Abhijit Mitra Departm(7nt o/ Chemistry, Columbia Uniuersity,1Veu York, Neu; York 10027 ReceiLied January 26, 1978 我们希望找到一种简单的吸附色谱技术用于有机化合物的常规净化。这种技术是适于传统的有机物大规模制备分离，该技术需使用长柱色谱法。尽管这种技术得到的效果非常好，但是其需要消耗大量的时间，并且由于频带拖尾经常出现低复原率。当分离的样本剂量大于1或者2g时，这些问题显得更加突出。近年来，几种制备系统已经进行了改进，能将分离时间减少到1-3h，并允许各成分的分辨率ΔR f≥（使用薄层色谱分析进行分析）。在这些方法中，在我们的实验室中，媒介压力色谱法1和短柱色谱法2是最成功的。最近，我们发现一种可以将分离速度大幅度提升的技术，可用于反应产物的常规提纯，我们将这种技术称为急骤色谱法。虽然这种技术的分辨率只是中等（ΔR f≥），而且构建这个系统花费非常低，并且能在10-15min内分离重量在的样本。4 急骤色谱法是以空气压力驱动的混合介质压力以及短柱色谱法为基础，专门针对快速分离，介质压力以及短柱色谱已经进行了优化。优化实验是在一组标准条件5下进行的，优化实验使用苯甲醇作为样本，放在一个20mm*5in.的硅胶柱60内，使用Tracor 970紫外检测器监测圆柱的输出。分辨率通过持续时间（r）和峰宽（w,w/2）的比率进行测定的（Figure 1），结果如图2-4所示，图2-4分别放映分辨率随着硅胶颗粒大小、洗脱液流速和样本大小的变化。

文献综述_人工智能

人工智能的形成及其发展现状分析 冯海东 （长江大学管理学院荆州434023） 摘要：人工智能的历史并不久远，故将从人工智能的出现、形成、发展现 状及前景几个方面对其进行分析，总结其发展过程中所出现的问题，以及发展现状中的不足之处，分析其今后的发展方向。 关键词：人工智能，发展过程，现状分析，前景。 一．引言 人工智能最早是在1936年被英国的科学家图灵提出，并不为多数人所认知。 当时，他编写了一个下象棋的程序，这就是最早期的人工智能的应用。也有著名的“图灵测试”，这也是最初判断是否是人工智能的方案,因此，图灵被尊称为“人工智能之父”。人工智能从产生到发展经历了一个起伏跌宕的过程，直到目前为止，人工智能的应用技术也不是很成熟，而且存在相当的缺陷。 通过搜集的资料，将详细的介绍人工智能这个领域的具体情况，剖析其面临的挑战和未来的前景。 二．人工智能的发展历程 1. 1956年前的孕育期 (1) 从公元前伟大的哲学家亚里斯多德(Aristotle)到16世纪英国哲学家培根(F. Bacon)，他们提出的形式逻辑的三段论、归纳法以及“知识就是力量”的警句，都对人类思维过程的研究产生了重要影响。 （2）17世纪德国数学家莱布尼兹(G..Leibniz)提出了万能符号和推理计算思想，为数理逻辑的产生和发展奠定了基础，播下了现代机器思维设计思想的种子。而19世纪的英国逻辑学家布尔（G. Boole）创立的布尔代数，实现了用符号语言描述人类思维活动的基本推理法则。 （3） 20世纪30年代迅速发展的数学逻辑和关于计算的新思想，使人们在计算机出现之前，就建立了计算与智能关系的概念。被誉为人工智能之父的英国天才的数学家图灵（A. Tur-ing）在1936年提出了一种理想计算机的数学模型，即图灵机之后,1946年就由美国数学家莫克利（J. Mauchly）和埃柯特（J. Echert）研制出了世界上第一台数字计算机，它为人工智能的研究奠定了不可缺少的物质基础。1950年图灵又发表了“计算机与智能”的论文，提出了著名的“图灵测试”，形象地指出什么是人工智能以及机器具有智能的标准，对人工智能的发展产生了极其深远的影响。 （4） 1934年美国神经生理学家麦克洛奇(W. McCulloch) 和匹兹(W. Pitts )建立了第一个神经网络模型，为以后的人工神经网络研究奠定了基础。 2. 1956年至1969年的诞生发育期 (1)1956年夏季，麻省理工学院（MIT)的麦卡锡（J．McCarthy）、明斯基（M. Minshy）、塞尔夫里奇（O. Selfridge)与索罗门夫(R. Solomonff)、 IBM的洛

毕业设计外文翻译附原文

外文翻译 专业机械设计制造及其自动化学生姓名刘链柱 班级机制111 学号1110101102 指导教师葛友华

外文资料名称： Design and performance evaluation of vacuum cleaners using cyclone technology 外文资料出处：Korean J. Chem. Eng., 23(6), (用外文写) 925-930 (2006) 附件： 1.外文资料翻译译文 2.外文原文

应用旋风技术真空吸尘器的设计和性能介绍 吉尔泰金，洪城铱昌，宰瑾李， 刘链柱译 摘要：旋风型分离器技术用于真空吸尘器 - 轴向进流旋风和切向进气道流旋风有效地收集粉尘和降低压力降已被实验研究。优化设计等因素作为集尘效率，压降，并切成尺寸被粒度对应于分级收集的50％的效率进行了研究。颗粒切成大小降低入口面积，体直径，减小涡取景器直径的旋风。切向入口的双流量气旋具有良好的性能考虑的350毫米汞柱的低压降和为1.5μm的质量中位直径在1米3的流量的截止尺寸。一使用切向入口的双流量旋风吸尘器示出了势是一种有效的方法，用于收集在家庭中产生的粉尘。 摘要及关键词：吸尘器; 粉尘; 旋风分离器 引言 我们这个时代的很大一部分都花在了房子，工作场所，或其他建筑，因此，室内空间应该是既舒适情绪和卫生。但室内空气中含有超过室外空气因气密性的二次污染物，毒物，食品气味。这是通过使用产生在建筑中的新材料和设备。真空吸尘器为代表的家电去除有害物质从地板到地毯所用的商用真空吸尘器房子由纸过滤，预过滤器和排气过滤器通过洁净的空气排放到大气中。虽然真空吸尘器是方便在使用中，吸入压力下降说唱空转成比例地清洗的时间，以及纸过滤器也应定期更换，由于压力下降，气味和细菌通过纸过滤器内的残留粉尘。 图1示出了大气气溶胶的粒度分布通常是双峰形，在粗颗粒（>2.0微米）模式为主要的外部来源，如风吹尘，海盐喷雾，火山，从工厂直接排放和车辆废气排放，以及那些在细颗粒模式包括燃烧或光化学反应。表1显示模式，典型的大气航空的直径和质量浓度溶胶被许多研究者测量。精细模式在0.18?0.36 在5.7到25微米尺寸范围微米尺寸范围。质量浓度为2?205微克，可直接在大气气溶胶和 3.85至36.3μg/m3柴油气溶胶。

人力资源战略与变革外文文献翻译中英文

外文文献翻译原文及译文 （节选重点翻译） 人力资源战略与变革外文文献翻译中英文 文献出处：Handbook of Human Resources Management, 2015, pp 1-18 译文字数：5800多字

英文 Human Resources Strategy and Change: Competence Development in a Changed Environment Michiel Berg Abstract Building competence in a changing environment is a journey. It is a journey where it is essential to have communicated and envisaged a picture of the destination. The details of this envisaged picture will look different probably upon "arrival" at the end of the journey. However, communicating the destination is essential. It helps employees to understand what the direction is. It helps employees and managers to use existing competencies along the way. Moving ahead very often demonstrates unexpected strengths in colleagues one has not been aware of. Moving ahead with a plan can also show the team their current level of competence and the desired state of competence. Explaining and talking about these differences may often prove not to be that easy and clear for many involved. A changing environment shows also weaknesses of current practices, processes, and services. It requires strong managerial skills to keep discussions having a focus on the future and preventing these discussions to turn into complaint sessions of past events. Human Resources practices and processes are executed in a triangle of employees, managers, and

软件开发外文翻译

软件开发外文翻译本页仅作为文档页封面，使用时可以删除 This document is for reference only-rar21year.March

Requirements Phase The chances of a product being developed on time and within budget are somewhat slim unless the members of the software development team agree on what the software product will do. The first step in achieving this unanimity is to analyze the client’s current situation as precisely as possible. For example, it is inadequate to say, “ They need a computer-aided design system because they claim their manual design system, there is lousy. “ Unless the development team knows exactly what is wrong with the current manual system, there is a high probability that aspects of the new computerized system will be equally “lousy. “ Similarly, if a personal computer manufacturer is contemplating development of a new operating system, the first step is to evaluate the firm’s current operating system and analyze carefully exactly why it is unsatisfactory. To take an extreme example, it is vital to know whether the problem exists only in the mind of the sales manager, who blames the operating system for poor sales, or whether users of the operating system are thoroughly disenchanted with its functionality and reliability. Only after a clear picture of the present situation has been gained can the team attempt to answer the critical question, What must the new product be able to do The process of answering this question is carried out during the requirements phase. A commonly held misconception is that , during the requirements phase, the developers must determine what software the client wants. On the contrary, the real objective of the requirements phase is to determine what software the client needs. The problem is that many clients do not know what they need. Furthermore, even a client who has a good idea of what is needed may have difficulty in accurately conveying these ideas to the developers, because most clients are less computer literate than the members of the development team.

外文文献翻译——参考格式

广东工业大学华立学院 本科毕业设计（论文） 外文参考文献译文及原文 系部经济学部 专业经济学 年级 2007级 班级名称 07经济学6班 学号 16020706001 学生姓名张瑜琴 指导教师陈锶 2011 年05月

目录 1挑战：小额贷款中的进入和商业银行的长期承诺 (1) 2什么商业银行带给小额贷款和什么把他们留在外 (2) 3 商业银行的四个模型进入小额贷款之内 (4) 3.1内在的单位 (4) 3.2财务子公司 (5) 3.3策略的同盟 (5) 3.4服务公司模型 (6) 4 合法的形式和操作的结构比较 (8) 5 服务的个案研究公司模型：厄瓜多尔和Haiti5 (9)

1 挑战：小额贷款中的进入和商业银行的长期承诺 商业银行已经是逐渐重要的运动员在拉丁美洲中的小额贷款服务的发展2到小额贷款市场是小额贷款的好消息客户因为银行能提供他们一完整类型的财务的服务，包括信用，储蓄和以费用为基础的服务。整体而言，它也对小额贷款重要，因为与他们广泛的身体、财务的和人类。如果商业银行变成重的运动员在小额贷款，他们能提供非常强烈的竞争到传统的小额贷款机构。资源，银行能廉宜地发射而且扩张小额贷款服务rela tively。如果商业广告银行在小额贷款中成为严重的运动员，他们能提出非常强烈的竞争给传统的小额贷款机构。然而，小额贷款社区里面有知觉哪一商业银行进入进入小额贷款将会是短命或浅的。举例来说，有知觉哪一商业银行首先可能不搬进小额贷款因为时候建立小额贷款操作到一个有利润的水平超过银行的标准投资时间地平线。或，在进入小额贷款，银行之后可能移动在－上面藉由增加贷款数量销售取利润最大值－或者更坏的事，退出如果他们是不满意与小额贷款的收益性的水平。这些知觉已经被特性加燃料商业银行的情形进入小额贷款和后来的出口之内。在最极端的，一些开业者已经甚至宣布，”降低尺度死！”而且抛弃了与主意合作的商业银行。 在最 signific 看得到的地方，蚂蚁利益商业银行可能带给小额贷款，国际的ACCION 发展发射而且扩张的和一些商业银行的关系小额贷款操作。在这些情形的大部分方面， ACCION 和它的合伙人正在使用方法，已知的当做服务公司模型，表演早答应当做一个能工作的方法克服真正的。 商业银行的障碍进入和穿越建立长命的小额贷款操作一个商业银行 这论文描述如何服务公司模型、住址商业银行中的主要议题进入进小额贷款，监定成功建立的因素动作井小额贷款服务公司，和礼物结果和小额贷款的课servic e 公司用最长的经验，在海地和审判官席 del 的 SOGEBANK│ SOGESOL 初期结果指出那这服务公司模型表现一重要的突破在促成商业银行进入和留在小额贷款。在厄瓜多尔的 Pichincha│ CREDIFE。初期结果指出服务公司模型在促成商业广告中表现一次重要的突破银行进入而且留在小额贷款。

论文《人工智能》---文献检索结课作业

人工智能 【摘要】：人工智能是一门极富挑战性的科学，但也是一门边沿学科。它属于自然科学和社会科学的交叉。涉及的学科主要有哲学、认知科学、数学、神经生理学、心理学、计算机科学、信息论、控制论、不定性论、仿生学等。人工智能(Artificial Intelligence)，英文缩写为AI。它是研究、开发用于模拟、延伸和扩展人的智能的理论、方法、技术及应用系统的一门新的技术科学。人工智能是计算机科学的一个分支，它企图了解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器，该领域的研究包括机器人、语言识别、图像识别、自然语言处理和专家系统等1。 【关键词】：人工智能；应用领域；发展方向；人工检索。 1．人工智能描述 人工智能(Artificial Intelligence) ，英文缩写为AI。它是研究、开发用于模拟、延伸和扩展人的智能的理论、方法、技术及应用系统的一门新的技术科学2。人工智能是计 算机科学的一个分支，它企图了解智 能的实质，并生产出一种新的能以人 类智能相似的方式作出反应的智能 机器，该领域的研究包括机器人、语 言识别、图像识别、自然语言处理和 专家系统等。“人工智能”一词最初 是在1956 年Dartmouth学会上提出 的。从那以后,研究者们发展了众多 理论和原理,人工智能的概念也随之扩展。人工智能是一门极富挑战性的科学，从事这项工作的人必须懂得计算机知识，心理学和哲学。人工智能是包括十分广泛的科学，它由不同的领域组成，如机器学习，计算机视觉等等，总的说来，人工智能研究的一个主要目标是使机器能够胜任一些通常需要人类智能才能完成的复杂工作。但不同的时代、不同的人对这种“复杂工作”的理解是不同的。例如繁重的科学和工程计算本来是要人脑来承担的，现在计算机不但能完成这种计算, 而且能够比人脑做得更快、更准确，因之当代人已不再把这种计算看作是“需要人类智能才能完成的复 1.蔡自兴，徐光祐.人工智能及其应用.北京：清华大学出版社，2010 2元慧·议当人工智能的应用领域与发展状态〖Ｊ〗．2008

毕业设计外文翻译

毕业设计（论文） 外文翻译 题目西安市水源工程中的 水电站设计 专业水利水电工程 班级 学生 指导教师 2016年

研究钢弧形闸门的动态稳定性 牛志国 河海大学水利水电工程学院，中国南京，邮编210098 nzg_197901@https://www.sodocs.net/doc/b814124495.html,，niuzhiguo@https://www.sodocs.net/doc/b814124495.html, 李同春 河海大学水利水电工程学院，中国南京，邮编210098 ltchhu@https://www.sodocs.net/doc/b814124495.html, 摘要 由于钢弧形闸门的结构特征和弹力，调查对参数共振的弧形闸门的臂一直是研究领域的热点话题弧形弧形闸门的动力稳定性。在这个论文中，简化空间框架作为分析模型，根据弹性体薄壁结构的扰动方程和梁单元模型和薄壁结构的梁单元模型，动态不稳定区域的弧形闸门可以通过有限元的方法，应用有限元的方法计算动态不稳定性的主要区域的弧形弧形闸门工作。此外，结合物理和数值模型，对识别新方法的参数共振钢弧形闸门提出了调查，本文不仅是重要的改进弧形闸门的参数振动的计算方法，但也为进一步研究弧形弧形闸门结构的动态稳定性打下了坚实的基础。 简介 低举升力，没有门槽，好流型，和操作方便等优点，使钢弧形闸门已经广泛应用于水工建筑物。弧形闸门的结构特点是液压完全作用于弧形闸门，通过门叶和主大梁，所以弧形闸门臂是主要的组件确保弧形闸门安全操作。如果周期性轴向载荷作用于手臂，手臂的不稳定是在一定条件下可能发生。调查指出:在弧形闸门的20次事故中，除了极特殊的破坏情况下，弧形闸门的破坏的原因是弧形闸门臂的不稳定;此外，明显的动态作用下发生破坏。例如:张山闸，位于中国的江苏省，包括36个弧形闸门。当一个弧形闸门打开放水时，门被破坏了，而其他弧形闸门则关闭，受到静态静水压力仍然是一样的，很明显，一个动态的加载是造成的弧形闸门破坏一个主要因素。因此弧形闸门臂的动态不稳定是造成弧形闸门(特别是低水头的弧形闸门)破坏的主要原是毫无疑问。

外文翻译--企业品牌战略研究

外文译文二： 企业品牌战略研究 Kapferer,J.H Strategic Brand Mnanagement [J]. Kogan Page,London [J]. Marketing Science,2010(2):52-61. 在经济全球化的今天，如何适应国际化潮流，建立强势品牌，提高竞争能力，已经成为国内企业面临的迫切问题。本文在分析我国企业营销品牌战略发展状况的基础上，从品牌战略的内涵与其功能意义入手，探讨了品牌战略在企业营销中的作用。企业需要综合运用多种竞争手段提高品意，搞好品牌定位，塑造良好品牌形象。 一、日系品牌全线崩溃 2006年11月22日上午，NEC宣布将推出2G及2.5G手机市场，这意味着继夏普、松下、东芝、三菱、三洋之后又一家日本手机厂商退出中国市场，日系手机除京瓷外几乎全部退出中国2G手机市场的争夺。 如果我们总结今天的中国家电市场与十年前有什么不同的话，我想，最大的不同就是，日系企业在中国的繁荣已经渐行渐远。 对于日系手机败退，乃至日系家电走到中国市场的低谷，主要原因有以下几点：一是企业制度呆板，决策困难，反应速度慢，与另市场现实格格不入，难以适应快速变化的中国市场;二是市场营销能力弱，产品规划能力不强，很难根椐自己对市场的判断与预测推出迎合消费需求的产品，一直处于跟风的被动局面，无法满足中国市场的需要;三是未能把握住产业转型最佳时机，是日系家电企业失去市场主导地位的重要原因。 日系企业在中国市场上走到边缘是否引起我们民族企业的深思？欲走国际化路线的企业又 是否从“日系企业”的背后吸取教训？ 二、我国企业实施品牌战略的现状分析处 1、众多昔日名牌“昙花一现” 中外企业在市场上的品牌大战，使刚刚成长起来的民族品牌受到极大的冲击。上世纪80年代稍有知名度的品牌，不是被抢注商标，就是被收购、挤垮，即使残留下来的也是惨淡经营，真正发展起来的极为有限。这里典型的案例，上世纪80年代至90年代初期，曾在空调界创下奇迹的华宝空调，在1998年被科龙收购，其后的品牌形象就一再下滑。

安卓应用开发基础论文中英文对照资料外文翻译文献

安卓应用开发基础论文中英文对照 资料外文翻译文献 中英文对照资料外文翻译文献安卓应用开发基础在Java编程语言编写的Android应用程序的Android的SDK工具编译代码以及与任何数据和到一个Android的包，一个归档文件档案资源的.apk后缀，所有的在一个单一的代码.apk文件被认为是一个应用程序，是Android的文件，供电设备来安装应用程序。一旦安装在设备上，每个Android应用程序的生命在它自己的安全沙箱：而Android操作系统是一个多用户Linux系统中，每个应用程序是一个不同的用户。默认情况下，每个应用程序的系统分配一个唯一的Linux用户ID，系统设置所有的应用程序中的文件权限，以便只有用户ID分配给该应用程序可以访问它们。每个进程都有它自己的虚拟

机，因此应用程序的代码在从其他应用程序隔离运行。默认情况下，每个应用程序运行在它自己的Linux进程。Android的启动过程时，应用程序的任何组件需要被执行，然后关闭该进程时，它不再需要或恢复时，系统必须为其他应用程序的内存。这样一来，Android系统实现了最小特权原则，也就是说，每个应用程序，默认情况下，只能访问的组件，它需要做的工作，没有更多，这将创建一个非常安全的环境，使应用程序无法访问的，这就是它没有给予许可制度的部分。但是，有一个应用程序的方法与其他应用程序和应用程序访问系统服务的数据：这有可能为两个应用程序安排共享相同的Linux用户ID，在这种情况下，它们能够相互访问的文件。为了节约使用相同的用户ID系统资源，应用程序还1 可以安排运行在相同的Linux进程和共享同一个VM。应用程序可以请求访问权限，如用户的联