毕业设计外文翻译(计算机专业)_Spring框架

英文原文

Spring contains a lot of functionality and features, which are well-organized in seven modules shown in the diagram below. This section discusses each the of modules in turn.

The Core package is the most fundamental part of the framework and provides the Dependency Injection features allowing you to manage bean container functionality. The basic concept here is the BeanFactory, which provides a factory pattern removing the need for programmatic singletons and allowing you to decouple the configuration and specification of dependencies from your actual program logic.

On top of the Core package sits the Context package, providing a way to access beans in a framework-style manner, somewhat resembling a JNDI-registry. The context package inherits its features from the beans package and adds support for text messaging using e.g. resource bundles, event-propagation, resource-loading and transparent creation of contexts by, for example, a servlet container.

The DAO package provides a JDBC-abstraction layer that removes the need to do tedious JDBC coding and parsing of database-vendor specific error codes. Also, the JDBC package provides a way to do programmatic as well as declarative transaction management, not only for classes implementing special interfaces, but for all your POJOs (plain old java objects).

The ORM package provides integration layers for popular object-relational mapping APIs, including JDO, Hibernate and iBatis. Using the ORM package you can use all those O/R-mappers in combination with all the other features Spring offers, like simple declarative transaction management mentioned before.

Spring's AOP package provides an AOP Alliance compliant aspect-oriented programming implementation allowing you to define, for example, method-interceptors and pointcuts to cleanly decouple code implementing functionality that should logically speaking be separated. Using source-level metadata functionality you can incorporate all kinds of behavioral information into your code, a little like .NET attributes.

Spring's Web package provides basic web-oriented integration features, such as multipart functionality, initialization of contexts using servlet listeners and a web-oriented application context. When using Spring together with WebWork or Struts, this is the package to integrate with.

Spring's Web MVC package provides a Model-View-Controller implementation for web-applications. Spring's MVC implementation is not just any implementation, it provides a clean separation between domain model code and web forms and allows you to use all the other features of the Spring Framework like validation.

Spring's web MVC framework is designed around a DispatcherServlet that dispatches requests to handlers, with configurable handler mappings, view resolution, locale and theme resolution as well as support for upload files. The default handler is a very simple Controller interface, just offering a ModelAndView handleRequest(request,response) method. This can already be used for application controllers, but you will prefer the included implementation hierarchy, consisting of, for example AbstractController, AbstractCommandController and SimpleFormController. Application controllers will typically be subclasses of those. Note that you

can choose an appropriate base class: If you don't have a form, you don't need a FormController. This is a major difference to Struts.

You can use any object as a command or form object - there's no need to implement an interface or derive from a base class. Spring's data binding is highly flexible, for example, it treats type mismatches as validation errors that can be evaluated by the application, not as system errors. So you don't need to duplicate your business objects' properties as Strings in your form objects, just to be able to handle invalid submissions, or to convert the Strings properly. Instead, it is often preferable to bind directly to your business objects. This is another major difference to Struts which is built around required base classes like Action and ActionForm - for every type of action.

Compared to WebWork, Spring has more differentiated object roles. It supports the notion of a Controller, an optional command or form object, and a model that gets passed to the view. The model will normally include the command or form object but also arbitrary reference data. Instead, a WebWork Action combines all those roles into one single object. WebWork does allow you to use existing business objects as part of your form, but only by making them bean properties of the respective Action class. Finally, the same Action instance that handles the request is used for evaluation and form population in the view. Thus, reference data needs to be modeled as bean properties of the Action too. These are arguably too many roles for one object.

Spring's view resolution is extremely flexible. A Controller implementation can even write a view directly to the response, returning null as ModelAndView. In the normal case, a ModelAndView instance consists of a view name and a model Map, containing bean names and corresponding objects (like a command or form, containing reference data). View name resolution is highly configurable, either via bean names, via a properties file, or via your own ViewResolver implementation. The abstract model Map allows for complete abstraction of the view technology, without any hassle. Any renderer can be integrated directly, whether JSP, V elocity, or any other rendering technology. The model Map is simply transformed into an appropriate format, such as JSP request attributes or a Velocity template model..

Pluggability of other MVC implementations

There are several reasons why some projects will prefer to use other MVC implementations. Many teams expect to leverage their existing investment in skills and tools. In addition, there is a large body of knowledge and experience avalailable for the Struts framework. Thus, if you can live with Struts' architectural flaws, it can still be a viable choice for the web layer. The same applies to WebWork and other web MVC frameworks.

If you don't want to use Spring's web MVC, but intend to leverage other solutions that Spring offers, you can integrate the web MVC framework of your choice with Spring easily. Simply start up a Spring root application context via its ContextLoaderListener, and access it via its ServletContext attribute (or Spring's respective helper method) from within a Struts or WebWork action. Note that there aren't any "plugins" involved, so no dedicated integration is necessary. From the web layer's point of view, you'll simply use Spring as a library, with the root application context instance as the entry point.

All your registered beans and all of Spring's services can be at your fingertips even without

Spring's web MVC. Spring doesn't compete with Struts or WebWork in this scenario, it just addresses the many areas that the pure web MVC frameworks don't, from bean configuration to data access and transaction handling. So you are able to enrich your application with a Spring middle tier and/or data access tier, even if you just want to use, for example, the transaction abstraction with JDBC or Hibernate.

Features of Spring MVC

Spring's web module provides a wealth of unique web support features, including:

Clear separation of roles - controller, validator, command object, form object, model object, DispatcherServlet, handler mapping, view resolver, etc. Each role can be fulfilled by a specialized object.

Powerful and straightforward configuration of both framework and application classes as JavaBeans, including easy referencing across contexts, such as from web controllers to business objects and validators.

Adaptability, non-intrusiveness. Use whatever controller subclass you need (plain, command, form, wizard, multi-action, or a custom one) for a given scenario instead of deriving from a single controller for everything.

Reusable business code - no need for duplication. You can use existing business objects as command or form objects instead of mirroring them in order to extend a particular framework base class.

Customizable binding and validation - type mismatches as application-level validation errors that keep the offending value, localized date and number binding, etc instead of String-only form objects with manual parsing and conversion to business objects.

Customizable handler mapping and view resolution - handler mapping and view resolution strategies range from simple URL-based configuration, to sophisticated, purpose-built resolution strategies. This is more flexible than some web MVC frameworks which mandate a particular technique.

Flexible model transfer - model transfer via a name/value Map supports easy integration with any view technology.

Customizable locale and theme resolution, support for JSPs with or without Spring tag library, support for JSTL, support for Velocity without the need for extra bridges, etc.

A simple but powerful tag library that avoids HTML generation at any cost, allowing for maximum flexibility in terms of markup code.

Data Access using O/R Mappers

Spring provides integration with Hibernate, JDO, Oracle TopLink, Apache OJB and iBATIS SQL Maps: in terms of resource management, DAO implementation support, and transaction strategies. For example for Hibernate, there is first-class support with lots of IoC convenience features, addressing many typical Hibernate integration issues. All of these support packages for O/R mappers comply with Spring's generic transaction and DAO exception hierarchies. There are usually two integration styles: either using Spring's DAO 'templates' or coding DAOs against plain Hibernate/JDO/TopLink/etc APIs. In both cases, DAOs can be configured through Dependency

Injection and participate in Spring's resource and transaction management.

Spring's adds significant support when using the O/R mapping layer of your choice to create data access applications. First of all, you should know that once you started using Spring's support for O/R mapping, you don't have to go all the way. No matter to what extent, you're invited to review and leverage the Spring approach, before deciding to take the effort and risk of building a similar infrastructure in-house. Much of the O/R mapping support, no matter what technology you're using may be used in a library style, as everything is designed as a set of reusable JavaBeans. Usage inside an ApplicationContext does provide additional benefits in terms of ease of configuration and deployment; as such, most examples in this section show configuration inside an ApplicationContext.

Some of the the benefits of using Spring to create your O/R mapping DAOs include:

Ease of testing. Spring's inversion of control approach makes it easy to swap the implementations and config locations of Hibernate SessionFactory instances, JDBC DataSources, transaction managers, and mapper object implementations (if needed). This makes it much easier to isolate and test each piece of persistence-related code in isolation.

Common data access exceptions.Spring can wrap exceptions from you O/R mapping tool of choice, converting them from proprietary (potentially checked) exceptions to a common runtime DataAccessException hierarchy. This allows you to handle most persistence exceptions, which are non-recoverable, only in the appropriate layers, without annoying boilerplate catches/throws, and exception declarations. You can still trap and handle exceptions anywhere you need to. Remember that JDBC exceptions (including DB specific dialects) are also converted to the same hierarchy, meaning that you can perform some operations with JDBC within a consistent programming model.

General resource management. Spring application contexts can handle the location and configuration of Hibernate SessionFactory instances, JDBC DataSources, iBATIS SQL Maps configuration objects, and other related resources. This makes these values easy to manage and change. Spring offers efficient, easy and safe handling of persistence resources. For example: Related code using Hibernate generally needs to use the same Hibernate Session for efficiency and proper transaction handling. Spring makes it easy to transparently create and bind a Session to the current thread, either by using an explicit 'template' wrapper class at the Java code level or by exposing a current Session through the Hibernate SessionFactory (for DAOs based on plain Hibernate3 API). Thus Spring solves many of the issues that repeatedly arise from typical Hibernate usage, for any transaction environment (local or JTA).

Integrated transaction management. Spring allows you to wrap your O/R mapping code with either a declarative, AOP style method interceptor, or an explicit 'template' wrapper class at the Java code level. In either case, transaction semantics are handled for you, and proper transaction handling (rollback, etc) in case of exceptions is taken care of. As discussed below, you also get the benefit of being able to use and swap various transaction managers, without your Hibernate/JDO related code being affected: for example, between local transactions and JTA, with the same full services (such as declarative transactions) available in both scenarios. As an additional benefit,

JDBC-related code can fully integrate transactionally with the code you use to do O/R mapping. This is useful for data access that's not suitable for O/R mapping, such as batch processing or streaming of BLOBs, which still needs to share common transactions with O/R mapping operations.

To avoid vendor lock-in, and allow mix-and-match implementation strategies. While Hibernate is powerful, flexible, open source and free, it still uses a proprietary API. Furthermore one could argue that iBA TIS is a bit lightweight, although it's excellent for use in application that don't require complex O/R mapping strategies. Given the choice, it's usually desirable to implement major application functionality using standard or abstracted APIs, in case you need to switch to another implementation for reasons of functionality, performance, or any other concerns. For example, Spring's abstraction of Hibernate transactions and exceptions, along with its IoC approach which allows you to easily swap in mapper/DAO objects implementing data access functionality, makes it easy to isolate all Hibernate-specific code in one area of your application, without sacrificing any of the power of Hibernate. Higher level service code dealing with the DAOs has no need to know anything about their implementation. This approach has the additional benefit of making it easy to intentionally implement data access with a mix-and-match approach (i.e. some data access performed using Hibernate, and some using JDBC, others using iBA TIS) in a non-intrusive fashion, potentially providing great benefits in terms of continuing to use legacy code or leveraging the strength of each technology.

The Spring transaction abstraction

Spring provides a consistent abstraction for transaction management. This abstraction is one of the most important of Spring's abstractions, and delivers the following benefits: Provides a consistent programming model across different transaction APIs such as JTA, JDBC, Hibernate, iBA TIS Database Layer and JDO.

Provides a simpler, easier to use, API for programmatic transaction management than most of these transaction APIs

Integrates with the Spring data access abstraction

Supports Spring declarative transaction management

Traditionally, J2EE developers have had two choices for transaction management: to use global or local transactions. Global transactions are managed by the application server, using JTA. Local transactions are resource-specific: for example, a transaction associated with a JDBC connection. This choice had profound implications. Global transactions provide the ability to work with multiple transactional resources. (It's worth noting that most applications use a single transaction resource) With local transactions, the application server is not involved in transaction management, and cannot help ensure correctness across multiple resources.

Global transactions have a significant downside. Code needs to use JTA: a cumbersome API to use (partly due to its exception model). Furthermore, a JTA UserTransaction normally needs to be obtained from JNDI: meaning that we need to use both JNDI and JTA to use JTA. Obviously all use of global transactions limits the reusability of application code, as JTA is normally only available in an application server environment.

The preferred way to use global transactions was via EJB CMT (Container Managed Transaction): a form of declarative transaction management (as distinguished from programmatic transaction management). EJB CMT removes the need for transaction-related JNDI lookups--although of course the use of EJB itself necessitates the use of JNDI. It removes most--not all--need to write Java code to control transactions. The significant downside is that CMT is (obviously) tied to JTA and an application server environment; and that it's only available if we choose to implement business logic in EJBs, or at least behind a transactional EJB facade. The negatives around EJB in general are so great that this is not an attractive proposition, when there are alternatives for declarative transaction management.

Local transactions may be easier to use, but also have significant disadvantages: They cannot work across multiple transactional resources, and tend to invade the programming model. For example, code that manages transactions using a JDBC connection cannot run within a global JTA transaction.

Spring resolves these problems. It enables application developers to use a consistent programming model in any environment. You write your code once, and it can benefit from different transaction management strategies in different environments. Spring provides both declarative and programmatic transaction management. Declarative transaction management is preferred by most users, and recommended in most cases.

With programmatic transaction management developers work with the Spring transaction abstraction, which can run over any underlying transaction infrastructure. With the preferred declarative model developers typically write little or no code related to transaction management, and hence don't depend on Spring's or any other transaction API.

中文译文

Core包是框架的最基础部分，并提供依赖注入（Dependency Injection）特性来使你可管理Bean容器功能。这里的基础概念是BeanFactory，它提供Factory模式来消除对程序性单例的需要，并允许你从程序逻辑中分离出依赖关系的配置和描述。

构建于Beans包上Context包，提供了一种框架式的Bean访问方式，有些象JNDI注册。Context包的特性得自Beans包，并添加了文本消息的发送，通过比如资源串，事件传播，资源装载的方式和Context的透明创建，如通过Servlet容器。

DAO包提供了JDBC的抽象层，它可消除冗长的JDBC编码和解析数据库厂商特有的错误代码。该包也提供了一种方法实现编程性和声明性事务管理，不仅仅是针对实现特定接口的类，而且对所有的POJO。

ORM包为流行的关系－对象映射APIs提供了集成层，包括JDO，Hibernate和iBatis。通过ORM包，你可与所有Spring提供的其他特性相结合来使用这些对象/关系映射，如前边提到的简单声明性事务管理。

Spring的AOP包提供与AOP联盟兼容的面向方面编程实现，允许你定义，如方法拦截器和切点，来干净地给从逻辑上说应该被分离的功能实现代码解耦。使用源码级的元数据功能，你可将各种行为信息合并到你的代码中，有点象.Net的attribute。

Spring的Web包提供了基本的面向Web的综合特性，如Multipart功能，使用Servlet 监听器的Context的初始化和面向Web的Applicatin Context。当与WebWork或Struts 一起使用Spring时，这个包使Spring可与其他框架结合。

Spring的Web MVC包提供了面向Web应用的Model-View-Controller实现。 Spring 的MVC实现不仅仅是一种实现，它提供了一种domain model代码和web form的清晰分离，这使你可使用Spring框架的所有其他特性，如校验.

Spring的web框架是围绕分发器（DispatcherServlet）设计的，DispatcherServlet 将请求分发到不同的处理器，框架还包括可配置的处理器映射，视图解析，本地化，主题解析，还支持文件上传。缺省的处理器是一个简单的控制器（Controller）接口，这个接口仅仅定义了ModelAndView handleRequest(request,response)方法。你可以实现这个接口生成应用的控制器，但是使用Spring提供的一系列控制器实现会更好一些，比如AbstractController，AbstractCommandController，和SimpleFormController。应用控制器一般都从它们继承。注意你需要选择正确的基类：如果你没有表单，你就不需要一个FormController。这是和Structs的一个主要区别。

你可以使用任何对象作为命令对象或表单对象：不必实现某个接口或从某个基类继承。Spring的数据绑定相当灵活，例如，它认为类型不匹配这样的错误应该是应用级的验证错误，而不是系统错误。所以你不需要为了处理无效的表单提交，或者正确地转换字符串，在你的表单对象中用字符串类型重复定义你的业务对象属性。你应该直接绑定表单到业务对象

上。这是和Struts的另一个重要不同，Struts是围绕象Action和ActionForm这样的基类构建的，每一种行为都是它们的子类。

和WebWork相比，Spring将对象细分成不同的角色：它支持的概念有控制器（Controller），可选的命令对象（Command Object）或表单对象（Form Object），以及传递到视图的模型（Model）。模型不仅包含命令对象或表单对象，而且也包含任何引用数据。但是，WebWork的Action将所有的这些角色都合并在一个单独的对象里。WebWork允许你在表单中使用现有的业务对象，但是只能把它们定义成不同Action类的bean属性。更重要的是，在运算和表单赋值时，使用的是同一个处理请求的Action实例。因此，引用数据也需要被定义成Action的bean属性。这样在一个对象就承担了太多的角色。

对于视图：Spring的视图解析相当灵活。一个控制器实现甚至可以直接输出一个视图作为响应，这需要使用null返回ModelAndView。在一般的情况下，一个ModelAndView实例包含视图名字和模型映射表，模型映射表提供了bean的名字及其对象（比如命令对象或表单对象，引用数据等等）的对应关系。视图名解析的配置是非常灵活的，可以通过bean 的名字，属性文件或者你自己的ViewResolver来实现。抽象的模型映射表完全抽象了表现层，没有任何限制：JSP，Velocity，或者其它的技术——任何表现层都可以直接和Spring 集成。模型映射表仅仅将数据转换成合适的格式，比如JSP请求属性或者Velocity模版模型。

MVC实现的可扩展性

许多团队努力争取在技术和工具方面能使他们的投入更有价值，无论是现有的项目还是新的项目都是这样。具体地说，Struts 不仅有大量的书籍和工具，而且有许多开发者熟悉它。因此，如果你能忍受Struts的架构性缺陷，它仍然是web层一个很好的选择。WebWork 和其它web框架也是这样。

如果你不想使用Spring的web MVC框架，而仅仅想使用Spring提供的其它功能，你可以很容易地将你选择的web框架和Spring结合起来。只要通过Spring的ContextLoadListener启动一个Spring的根应用上下文，并且通过它的ServletContext属性（或者Spring的各种帮助方法）在Struts或WebWork的Action中访问。注意到现在没有提到任何具体的“plugins”，因此这里也没有提及如何集成：从web层的角度看，你可以仅仅把Spring作为一个库使用，根应用上下文实例作为入口。

所有你注册的bean和Spring的服务可以在没有Spring的web MVC下被访问。Spring 并没有在使用方法上和Struts或WebWork竞争，它只是提供单一web框架所没有的功能，从bean的配置到数据访问和事务处理。所以你可以使用Spring的中间层和（或者）数据访问层来增强你的应用，即使你只是使用象JDBC或Hibernate事务抽象这样的功能。

Spring MVC框架的特点

如果仅仅关注于web方面的支持，Spring有下面一些特点：

清晰的角色划分：控制器，验证器，命令对象，表单对象和模型对象；分发器，处理器映射和视图解析器；等等。

直接将框架类和应用类都作为JavaBean配置，包括通过应用上下文配置中间层引用，例如，从web控制器到业务对象和验证器的引用。

可适应性，但不具有强制性：根据不同的情况，使用任何你需要的控制器子类（普通控制器，命令，表单，向导，多个行为，或者自定义的），而不是要求任何东西都要从Action/ActionForm继承。

可重用的业务代码，而不需要代码重复：你可以使用现有的业务对象作为命令对象或表单对象，而不需要在ActionForm的子类中重复它们的定义。

可定制的绑定和验证：将类型不匹配作为应用级的验证错误，这可以保存错误的值，以及本地化的日期和数字绑定等，而不是只能使用字符串表单对象，手动解析它并转换到业务对象。

可定制的处理器映射，可定制的视图解析：灵活的模型可以根据名字/值映射，处理器映射和视图解析使应用策略从简单过渡到复杂，而不是只有一种单一的方法。

可定制的本地化和主题解析，支持JSP，无论有没有使用Spring标签库，支持JSTL，支持不需要额外过渡的Velocity，等等。

简单而强大的标签库，它尽可能地避免在HTML生成时的开销，提供在标记方面的最大灵活性。

使用ORM工具进行数据访问

Spring在资源管理，DAO实现支持以及实物策略等方面提供了与Hibernate, JDO和iBATIS SQL映射的集成。对Hibernate，Spring使用了很多IoC的方便的特性提供了一流的支持，帮助你处理很多典型的Hibernate整合的问题。所有的这些都遵守Spring通用的事务和DAO异常体系.。

当您选择使用O/R映射来创建数据访问应用程序的时候，Spring的增加部分就会向您提供重要的支持。首先你应该了解的是，一旦你使用了Spring对O/R映射的支持，你不需要亲自作所有的事情。在决定花费力气，冒着风险建造类似的内部底层结构之前，我们都建议您考虑和利用Spring的解决方案。不管你使用的是何种技术，大部分的O/R映射支持都可以以library样式被使用，因为所有的东西都是被设计成一组可重复利用的JavaBeans。在ApplicationContext和BeanFactory中使用更是提供了配置和部署简单的好处，因此，这一章里的大多数例子都是在ApplicationContext中配置。

使用Spring构建你的ORM应用的好处包括:

测试简单. Spring的IoC使得很容易替换掉不同的实现，Hibernate SessionFacotory 的位置，datasource, 事务管理, 映射对象的实现。这样就很容易隔离测试持久化相关代码的各个部分。

异常包装。 Spring能够包装Hibernate异常，把它们从专有的，checked exception 变为一组抽象的runtime exception。这样你就可以仅仅在恰当的层处理大部分的不可恢复的异常，使你避免了很多讨厌的catch/throw以及异常声明。你还是可以在你需要的地方捕捉和处理异常。回想一下JDBC异常（包括与DB相关的方言）被转变为同样的异常体系，这就意味着你可以在一致的编程模型中处理JDBC操作。

通用的资源管理。 Spring的application context能够处理诸如Hibernate 的SessionFactory， JDBC的datasource，iBatis的SQLMaps配置对象以及其他相关资源的定位和配置。这使得这些配置的值很容易被管理和修改。Spring提供了有效，简单和安全的Hibernate Session处理。一般的使用Hibernate的代码则需要使用同一个Hibernate Session对象以确保有效和恰当地事务处理。而Spring让我们可以很容易透明地创建和绑定一个session到当前线程；你可以使用以下两种办法之一：声明式的AOP方法拦截器，或通过使用一个外部的template包装类在Java代码层次实现。这样，Spring就解决了在很多Hibernate论坛上出现的使用问题。

综合的事务管理。 Spring允许你包装你的ORM代码，通过使用声明式的AOP方法拦截器或者在代码级别使用外部的template包装类。不管使用哪一种，事务相关的语义都会为你处理，万一有异常发生也会帮你做适当的事务操作（比如rollback）。就象我们下面要讨论的一样，你能够使用和替换各种transaction managers，却不会使你的Hibernate相关的代码受到影响。更好的是，JDBC相关的代码可以完全和Hibernate代码integrate transactionaly。这对于处理那些没有用Hibernate或iBatis实现的功能非常有用。

避免绑定特殊的技术，允许mix-and-match的实现策略。虽然Hibernate非常强大，灵活，开源而且免费，但它还是使用了自己的特定的API。此外有人也许会争辩：iBatis 更轻便而且在不需要复杂的O/R映射策略的应用中使用也很优秀。能够选择的话，使用标准或抽象的API来实现主要的应用需求，通常是更好的。尤其，当你可能会因为功能，性能或其他方面的原因而需要切换到另一个实现的时候。举例来说，Spring对Hibernate事务和异常的抽象，以及能够让你轻松交换mapper和DAO对象（实现数据访问功能）的IoC机制，这两个特性可以让你在不牺牲Hibernate性能的情况下，在你的应用程序中隔离Hibernate 的相关代码。处理DAO的高层次的service代码不需要知道DAO的具体实现。这个方法可以很容易使用mix-and-match方案互不干扰地实现数据访问层（比如在一些地方用Hibernate，一些地方使用JDBC，其他地方使用iBatis），mix-and-match有利于处理遗留下来的代码以及利用各种技术（JDBC,Hibernate,iBatis）的长处.。

Spring提供了一致的事务管理抽象。这个抽象是Spring最重要的抽象之一，它有如下的优点：

为不同的事务API提供一致的编程模型，如JTA、JDBC、Hibernate、iBATIS数据库层和JDO

提供比大多数事务API更简单的，易于使用的编程式事务管理API

整合Spring数据访问抽象

支持Spring声明式事务管理

传统上，J2EE开发者有两个事务管理的选择: 全局事务或局部事务。全局事务由应用服务器管理，使用JTA。局部事务是和资源相关的：例如，一个和JDBC连接关联的事务。这个选择有深刻的含义。全局事务可以用于多个事务性的资源（需要指出的是多数应用使用单一事务性的资源）。使用局部事务，应用服务器不需要参与事务管理，并且不能帮助确保跨越多个资源的事务的正确性。

全局事务有一个显著的不利方面，代码需要使用JTA：一个笨重的API（部分是因为它的异常模型）。此外，JTA的UserTransaction通常需要从JNDI获得，这意味着我为了JTA 需要同时使用JNDI和JTA。显然全部使用全局事务限制了应用代码的重用性，因为JTA通常只在应用服务器的环境中才能使用。

使用全局事务的比较好的方法是通过EJB的CMT （容器管理的事务）：声明式事务管理的一种形式（区别于编程式事务管理）。EJB的CMT不需要任何和事务相关的JNDI查找，虽然使用EJB本身肯定需要使用JNDI。它消除大多数——不是全部——书写Java代码控制事务的需求。显著的缺点是CMT绑定在JTA和应用服务器环境上，并且只有我们选择使用EJB实现业务逻辑，或者至少处于一个事务化EJB的外观（Facade）后才能使用它。EJB 有如此多的诟病，当存在其它声明式事务管理时，EJB不是一个吸引人的建议。

局部事务容易使用，但也有明显的缺点：它们不能用于多个事务性资源，并且趋向侵入的编程模型。例如，使用JDBC连接事务管理的代码不能用于全局的JTA事务中。

Spring解决了这些问题。它使应用开发者能够使用在任何环境下使用一致的编程模型。你可以只写一次你的代码，这在不同环境下的不同事务管理策略中很有益处。Spring 同时提供声明式和编程式事务管理。

使用编程式事务管理，开发者直接使用Spring事务抽象，这个抽象可以使用在任何底层事务基础之上。使用首选的声明式模型，开发者通常书写很少的事务相关代码，因此不依赖Spring或任何其他事务API。

信息与计算科学中英文对照外文翻译文献

(文档含英文原文和中文翻译) 中英文对照外文翻译 基于拉格朗日乘数法的框架结构合理线刚度比的研究 【摘要】框架结构是一种常见的多层高层建筑结构；列的合理线刚度比研究是框架结构优化设计中的一个重要方面。本论文研究合理线刚度比时，框架梁、柱的

侧移刚度根据拉格朗日乘数法结构优化的理论和在框架梁、柱的总物质的量一定的前提下，取得最高值。与传统的估计方法和试算梁柱截面尺寸不同，梁、柱的合理的截面尺寸可以在初步设计阶段由派生的公式计算。这种方法不仅作为计算框架梁、柱的截面尺寸基础，确认初步设计阶，而且也被用做类似的结构梁柱合理线刚度比研究的参考。此外，在调整帧梁、柱的截面尺寸的方法的基础上，降低柱的轴向的压缩比，从而达到剪切压缩比和提高结构的延展性。 【关键词】拉格朗日数乘法框架结构刚度比截面尺寸 1 引言 在混凝土框架结构初步设计的期间，通常，框架梁截面高度通过跨度来估算，和截面宽度根据高宽比估算; 框架柱的截面尺寸是根据柱轴压缩的支持柱的面积的比率估算[1]。然而，在估计过程中，初步设计阶段中的一个重要的链，未考虑到柱侧移刚度的影响[2]。列侧移刚度越大，结构层间位的刚度越大，剪切型框架结构的层间位移将越较小。所以，总结构越小的侧向位移将减少地震灾害[3] 所造成的损失。论文的核心是如何得到列侧移刚度的最大值。 同时，列侧移刚度的值与框架梁-柱线刚度直接相关。本论文的目的是为了得到一个合理的框架梁 - 柱的线刚度比，在某个控制范围内获得列侧移刚度的最大值。 计算列横向位移的方法有两种方法：刚度拐点点法和修改拐点法。拐点的方法假定关节的旋转角度为0（当梁柱线性刚度比是大于或等于3时，柱的上端和下端的关节的旋转角度可以取为0，因为它实际上是相当小），即梁的弯曲刚性被视为无穷大。拐点的方法主要是应用于具有比较少层的框架结构。但对于多层、高层框架结构，增加柱截面会导致梁柱线刚度比小于3，在水平荷载作用下，框架结构的所有关节的旋转角度的横向位移会发生不可忽视。因此，一位日本教授武藤提出修改拐点法[4]，即D-值方法。本文采用D-值列侧移刚度的计算法，因为它着重于多层、高层框架结构。 少数在国内外对框架梁柱合理线刚度比的研究，只有梁七黹，源于列侧移刚度的计算方法，比D-值法更加应用广泛；申得氏指出在多层、高层框架结构的柱侧向刚度计算中存在的问题，补充和修改底部和顶部层的列侧向刚度计算公式;

毕业设计外文翻译资料

外文出处： 《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）

冲压模具技术外文翻译(含外文文献)

前言 在目前激烈的市场竞争中，产品投入市场的迟早往往是成败的关键。模具是高质量、高效率的产品生产工具，模具开发周期占整个产品开发周期的主要部分。因此客户对模具开发周期要求越来越短，不少客户把模具的交货期放在第一位置，然后才是质量和价格。因此，如何在保证质量、控制成本的前提下加工模具是值得认真考虑的问题。模具加工工艺是一项先进的制造工艺，已成为重要发展方向，在航空航天、汽车、机械等各行业得到越来越广泛的应用。模具加工技术，可以提高制造业的综合效益和竞争力。研究和建立模具工艺数据库，为生产企业提供迫切需要的高速切削加工数据，对推广高速切削加工技术具有非常重要的意义。本文的主要目标就是构建一个冲压模具工艺过程，将模具制造企业在实际生产中结合刀具、工件、机床与企业自身的实际情况积累得高速切削加工实例、工艺参数和经验等数据有选择地存储到高速切削数据库中，不但可以节省大量的人力、物力、财力，而且可以指导高速加工生产实践，达到提高加工效率，降低刀具费用，获得更高的经济效益。 1.冲压的概念、特点及应用 冲压是利用安装在冲压设备（主要是压力机）上的模具对材料施加压力，使其产生分离或塑性变形，从而获得所需零件（俗称冲压或冲压件）的一种压力加工方法。冲压通常是在常温下对材料进行冷变形加工，且主要采用板料来加工成所需零件，所以也叫冷冲压或板料冲压。冲压是材料压力加工或塑性加工的主要方法之一，隶属于材料成型工程术。 冲压所使用的模具称为冲压模具，简称冲模。冲模是将材料（金属或非金属）批量加工成所需冲件的专用工具。冲模在冲压中至关重要，没有符合要求的冲模，批量冲压生产就难以进行；没有先进的冲模，先进的冲压工艺就无法实现。冲压工艺与模具、冲压设备和冲压材料构成冲压加工的三要素，只有它们相互结合才能得出冲压件。 与机械加工及塑性加工的其它方法相比，冲压加工无论在技术方面还是经济方面都具有许多独特的优点，主要表现如下； (1) 冲压加工的生产效率高，且操作方便，易于实现机械化与自动化。这是

框架结构毕业设计任务书和指导书范本

框架结构毕业设计任务书和指导书 1 2020年4月19日

毕业设计基本要求 1目的 （1）综合运用所学专业理论知识与设计技能，处理建筑设计中有关方针、政策、功能、经济、安全、美观等方面的问题。解决总体、单体、空间等关系，以创造富有时代气息的优美建筑形象与环境。依据建筑设计完成结构体系的布置、结构在各种荷载工况下的计算、构造和施工图。 （2）掌握一般建筑工程的设计思路，进而举一反三熟悉有关建筑工程的设计、施工、预算等建设过程。为即将走上工作岗位奠定基础。 （3）学以致用，学习科学技术和技能的目的是应用。一个工程师在设计、建设实际工程中应具备的知识，都是我们在毕业设计中应予以加强的。因此深切领悟总体概念设计、掌握具体理论设计和实际工程技术处理措施的结合作为重点来训练。 （4）树立正确的设计思想，全面对待建筑与结构的关系， 2 2020年4月19日

培养勤奋、严谨、认真的工作作风及分析解决一般工程技术问题的能力。 （5）掌握调查研究、理论联系实际的学习方法，养成既能独立思考，又能相互配合密切合作的工作态度。 （6）使学生对一般工业与民用建筑的土建设计的内容和构成有比较全面的了解，并熟悉有关设计标准、规范、手册和工具书，增强毕业后到生产第一线工作的适应能力。 2成果形式及要求 （1）计算书和说明书： 字数应不少于1万字，书写要工整，字迹要清楚，可采用计算机打印。计算书内容要阐明设计依据或标准，方案构思、特点、必要的经济指标，结构选型、构造处理、材料特点及计算上的主要问题，还应包括结构计算全过程，计算要正确、完整、思路清晰、简图明了。计算书格式：应严格按照毕业设计手册中的要求。 （2）图纸： 3 2020年4月19日

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

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

机械设计外文翻译(中英文)

机械设计理论 机械设计是一门通过设计新产品或者改进老产品来满足人类需求的应用技术科学。它涉及工程技术的各个领域，主要研究产品的尺寸、形状和详细结构的基本构思，还要研究产品在制造、销售和使用等方面的问题。 进行各种机械设计工作的人员通常被称为设计人员或者机械设计工程师。机械设计是一项创造性的工作。设计工程师不仅在工作上要有创造性，还必须在机械制图、运动学、工程材料、材料力学和机械制造工艺学等方面具有深厚的基础知识。如前所诉，机械设计的目的是生产能够满足人类需求的产品。发明、发现和科技知识本身并不一定能给人类带来好处，只有当它们被应用在产品上才能产生效益。因而，应该认识到在一个特定的产品进行设计之前，必须先确定人们是否需要这种产品。 应当把机械设计看成是机械设计人员运用创造性的才能进行产品设计、系统分析和制定产品的制造工艺学的一个良机。掌握工程基础知识要比熟记一些数据和公式更为重要。仅仅使用数据和公式是不足以在一个好的设计中做出所需的全部决定的。另一方面，应该认真精确的进行所有运算。例如，即使将一个小数点的位置放错，也会使正确的设计变成错误的。 一个好的设计人员应该勇于提出新的想法，而且愿意承担一定的风险，当新的方法不适用时，就使用原来的方法。因此，设计人员必须要有耐心，因为所花费的时间和努力并不能保证带来成功。一个全新的设计，要求屏弃许多陈旧的，为人们所熟知的方法。由于许多人墨守成规，这样做并不是一件容易的事。一位机械设计师应该不断地探索改进现有的产品的方法，在此过程中应该认真选择原有的、经过验证的设计原理，将其与未经过验证的新观念结合起来。 新设计本身会有许多缺陷和未能预料的问题发生，只有当这些缺陷和问题被解决之后，才能体现出新产品的优越性。因此，一个性能优越的产品诞生的同时，也伴随着较高的风险。应该强调的是，如果设计本身不要求采用全新的方法，就没有必要仅仅为了变革的目的而采用新方法。 在设计的初始阶段，应该允许设计人员充分发挥创造性，不受各种约束。即使产生了许多不切实际的想法，也会在设计的早期，即绘制图纸之前被改正掉。只有这样，才不致于堵塞创新的思路。通常，要提出几套设计方案，然后加以比较。很有可能在最后选定的方案中，采用了某些未被接受的方案中的一些想法。

多层混凝土框架结构设计文献综述

多层混凝土框架结构设计 1.前言 随着社会的发展,钢筋混凝土框架结构的建筑物越来越普遍.由于钢筋混凝土结构与砌体结构相比较具有承载力大、结构自重轻、抗震性能好、建造的工业化程度高等优点；与钢结构相比又具有造价低、材料来源广泛、耐火性好、结构刚度大、使用维修费用低等优点。因此，在我国钢筋混凝土结构是多层框架最常用的结构型式。近年来，世界各地的钢筋混凝土多层框架结构的发展很快，应用很多。 一般框架结构是由楼板、梁、柱及基础4种承重构件组成的，由主梁、柱与基础构成平面框架，各平面框架再由连续梁连接起来而形成的空间结构体系。文献[1]认为，在合理的高度和层数的情况下，框架结构能够提供较大的建筑空间，其平面布置比较的灵活，可适合多种工艺与使用功能的要求。 多层钢筋混凝土框架结构设计可以分为四个阶段：一是方案设计，二是结构分析，三是构件设计，四是绘施工图。结构分析和构件设计是结构设计中的计算阶段，在现代，已由电子计算机承担这一工作，常采用PKPM建模计算。但是，结构的计算并不能代替结构的设计。文献[2]中认为：良好的结构设计的重要前提，应该是合理组织与综合解决结构的传力系统、传力方式，良好的结构方案是良好结构设计的重要前提。2.关于框架结构设计文献回顾 2.1框架结构的优缺点 框架结构体系是由横梁与柱子连接而成.梁柱连接处(称为节点)一般为刚性连接,有时为便于施工和其他构造要求,也可以将部分节点做成铰接或者半铰接.柱支座一般为固定支座,必要时也可以设计成铰支座.框架结构可以分为现浇整体式,装配式,现浇装配式. 文献[3]中提到:框架结构的布置灵活,容易满足建筑功能和生工艺的多种要求.同时,经过合理设计,框架结构可以具有较好的延性和抗震性能.但是,框架结构承受水平力(如风荷载和水平地震作用)的能力较小.当层树较多或水平力较大时,水平位移较大,在强烈地震作用下往往由于变形过大而引起非结构构件(如填充墙)的破坏.因此,为了满足承载力和侧向刚度的要求,柱子的截面往往较大,既耗费建筑材料,又减少使用面积.这就使框架结构的建筑高度受到一定的限制.目前,框架结构一般用于多层建筑和不考虑抗震设防,层数较少的的高层建筑(比如,层数为10层或高度为30米以下) 2.3框架结构的布置 多层框架结构的平面布置形式非常的灵活，文献[4]中将框架结构按照承重方式的不同分为以下三类：(1)横向框架承重方案,以框架横梁作为楼盖的主梁,楼面荷载主要由横向框架承担.由于横向框架数往往较少,主梁沿横向布置有利于增强房屋的横向刚度.同时,主梁沿横向布置还有利于建筑物的通风和采光.但由于主梁截面尺寸较大,当房屋需要大空间时,净空较小,且不利于布置纵向管道. (2)纵向框架承重方案以框架纵梁作为楼盖的主梁,楼面荷载由框架纵梁承担.由于横梁截面尺寸较小,有

本科毕业设计方案外文翻译范本

I / 11 本科毕业设计外文翻译 <2018届） 论文题目基于WEB 的J2EE 的信息系统的方法研究 作者姓名[单击此处输入姓名] 指导教师[单击此处输入姓名] 学科(专业 > 所在学院计算机科学与技术学院 提交日期[时间 ]

基于WEB的J2EE的信息系统的方法研究 摘要：本文介绍基于工程的Java开发框架背后的概念，并介绍它如何用于IT 工程开发。因为有许多相同设计和开发工作在不同的方式下重复，而且并不总是符合最佳实践，所以许多开发框架建立了。我们已经定义了共同关注的问题和应用模式，代表有效解决办法的工具。开发框架提供：<1）从用户界面到数据集成的应用程序开发堆栈；<2）一个架构，基本环境及他们的相关技术，这些技术用来使用其他一些框架。架构定义了一个开发方法，其目的是协助客户开发工程。 关键词：J2EE 框架WEB开发 一、引言 软件工具包用来进行复杂的空间动态系统的非线性分析越来越多地使用基于Web的网络平台，以实现他们的用户界面，科学分析，分布仿真结果和科学家之间的信息交流。对于许多应用系统基于Web访问的非线性分析模拟软件成为一个重要组成部分。网络硬件和软件方面的密集技术变革[1]提供了比过去更多的自由选择机会[2]。因此，WEB平台的合理选择和发展对整个地区的非线性分析及其众多的应用程序具有越来越重要的意义。现阶段的WEB发展的特点是出现了大量的开源框架。框架将Web开发提到一个更高的水平，使基本功能的重复使用成为可能和从而提高了开发的生产力。 在某些情况下，开源框架没有提供常见问题的一个解决方案。出于这个原因，开发在开源框架的基础上建立自己的工程发展框架。本文旨在描述是一个基于Java的框架，该框架利用了开源框架并有助于开发基于Web的应用。通过分析现有的开源框架，本文提出了新的架构，基本环境及他们用来提高和利用其他一些框架的相关技术。架构定义了自己开发方法，其目的是协助客户开发和事例工程。 应用程序设计应该关注在工程中的重复利用。即使有独特的功能要求，也

机械类外文翻译

机械类外文翻译 塑料注塑模具浇口优化 摘要:用单注塑模具浇口位置的优化方法，本文论述。该闸门优化设计的目的是最大限度地减少注塑件翘曲变形，翘曲，是因为对大多数注塑成型质量问题的关键，而这是受了很大的部分浇口位置。特征翘曲定义为最大位移的功能表面到表面的特征描述零件翘曲预测长度比。结合的优化与数值模拟技术，以找出最佳浇口位置，其中模拟armealing算法用于搜索最优。最后，通过实例讨论的文件，它可以得出结论，该方法是有效的。 注塑模具、浇口位臵、优化、特征翘曲变形关键词: 简介 塑料注射成型是一种广泛使用的，但非常复杂的生产的塑料产品，尤其是具有高生产的要求，严密性，以及大量的各种复杂形状的有效方法。质量ofinjection 成型零件是塑料材料，零件几何形状，模具结构和工艺条件的函数。注塑模具的一个最重要的部分主要是以下三个组件集:蛀牙，盖茨和亚军，和冷却系统。拉米夫定、Seow(2000)、金和拉米夫定(2002) 通过改变部分的尼斯达到平衡的腔壁厚度。在平衡型腔充填过程提供了一种均匀分布压力和透射电镜,可以极大地减少高温的翘曲变形的部分～但仅仅是腔平衡的一个重要影响因素的一部分。cially Espe,部分有其功能上的要求,其厚度通常不应该变化。 pointview注塑模具设计的重点是一门的大小和位臵,以及流道系统的大小和布局。大门的大小和转轮布局通常被认定为常量。相对而言,浇口位臵与水口大小布局也更加灵活,可以根据不同的零件的质量。 李和吉姆(姚开屏,1996a)称利用优化流道和尺寸来平衡多流道系统为multiple 注射系统。转轮平衡被形容为入口压力的差异为一多型腔模具用相同的蛀牙,也存

框架结构设计外文翻译

毕业设计(论文)外文资料翻译 系：机械工程系 专业：土木工程 姓名： 学号： 外文出处：Design of prestressed (用外文写) concrete structures 附件： 1.外文资料翻译译文；2.外文原文。

附件1：外文资料翻译译文 8-2简支梁布局 一个简单的预应力混凝土梁由两个危险截面控制：最大弯矩截面和端截面。这两部分设计好之后，中间截面一定要单独检查，必要时其他部位也要单独调查。最大弯矩截面在以下两种荷载阶段为控制情况，即传递时梁受最小弯矩M G的初始阶段和最大设计弯矩M T时的工作荷载阶段。而端截面则由抗剪强度、支承垫板、锚头间距和千斤顶净空所需要的面积来决定。所有的中间截面是由一个或多个上述要求，根它们与上述两种危险截面的距离来控制。对于后张构件的一种常见的布置方式是在最大弯矩截面采用诸如I形或T形的截面，而在接近梁端处逐渐过渡到简单的矩形截面。这就是人们通常所说的后张构件的端块。对于用长线法生产的先张构件，为了便于生产，全部只用一种等截面，其截面形状则可以为I形、双T形或空心的。在第5 、 6 和7章节中已经阐明了个别截面的设计，下面论述简支梁钢索的总布置。 梁的布置可以用变化混凝土和钢筋的办法来调整。混凝土的截面在高度、宽度、形状和梁底面或者顶面的曲率方面都可以有变化。而钢筋只在面积方面有所变化，不过在相对于混凝土重心轴线的位置方面却多半可以有变化。通过调整这些变化因素，布置方案可能有许多组合，以适应不同的荷载情况。这一点是与钢筋混凝土梁是完全不同的，在钢筋混凝土梁的通常布置中，不是一个统一的矩形截面便是一个统一的T形，而钢筋的位置总是布置得尽量靠底面纤维。 首先考虑先张梁，如图 8-7，这里最好采用直线钢索，因为它们在两个台座之间加力比较容易。我们先从图（a）的等截面直梁的直线钢索开始讨论。这样的布置都很简单，但这样一来，就不是很经济的设计了，因为跨中和梁端的要求会产生冲突。通常发生在跨度中央的最大弯矩截面中的钢索，最好尽量放低，以便尽可能提供最大力臂而提供最大的内部抵制力矩。当跨度中央的梁自重弯矩M G相当大时，就可以把c.g.s布置在截面核心范围以下很远的地方，而不致在传递时在顶部纤维中引起拉应力。然而对于梁端截面却有一套完全不同的要求。由于在梁端没有外力矩，因为在最后的时刻，安排钢索要以c.g.s与 c.g.c在结束区段一致，如此同样地获得克服压力分配的方法。无论如何，如果张应力在最后不能承受，放置 c.g.s.

本科毕业设计外文翻译

Section 3 Design philosophy, design method and earth pressures 3.1 Design philosophy 3.1.1 General The design of earth retaining structures requires consideration of the interaction between the ground and the structure. It requires the performance of two sets of calculations: 1）a set of equilibrium calculations to determine the overall proportions and the geometry of the structure necessary to achieve equilibrium under the relevant earth pressures and forces; 2）structural design calculations to determine the size and properties of thestructural sections necessary to resist the bending moments and shear forces determined from the equilibrium calculations. Both sets of calculations are carried out for specific design situations (see 3.2.2) in accordance with the principles of limit state design. The selected design situations should be sufficiently Severe and varied so as to encompass all reasonable conditions which can be foreseen during the period of construction and the life of the retaining wall. 3.1.2 Limit state design This code of practice adopts the philosophy of limit state design. This philosophy does not impose upon the designer any special requirements as to the manner in which the safety and stability of the retaining wall may be achieved, whether by overall factors of safety, or partial factors of safety, or by other measures. Limit states (see 1.3.13) are classified into: a) ultimate limit states (see 3.1.3); b) serviceability limit states (see 3.1.4). Typical ultimate limit states are depicted in figure 3. Rupture states which are reached before collapse occurs are, for simplicity, also classified and

机械图纸中英文翻译汇总

近几年，我厂和英国、西班牙的几个公司有业务往来，外商传真发来的图纸都是英文标注，平时阅看有一定的困难。下面把我们积累的几点看英文图纸的经验与同行们交流。 1标题栏 英文工程图纸的右下边是标题栏（相当于我们的标题栏和部分技术要求），其中有图纸名称（TILE）、设计者（DRAWN）、审查者（CHECKED）、材料（MATERIAL）、日期（DATE）、比例（SCALE）、热处理（HEAT TREATMENT）和其它一些要求，如： 1)TOLERANCES UNLESS OTHERWISE SPECIFIAL 未注公差。 2)DIMS IN mm UNLESS STATED 如不做特殊要求以毫米为单位。 3)ANGULAR TOLERANCE±1°角度公差±1°。 4)DIMS TOLERANCE±0.1未注尺寸公差±0.1。 5)SURFACE FINISH 3.2 UNLESS STATED未注粗糙度3.2。 2常见尺寸的标注及要求 2.1孔（HOLE）如： （1）毛坯孔：3"DIAO+1CORE 芯子3"0+1; （2）加工孔：1"DIA1"; （3）锪孔：锪孔(注C＇BORE=COUNTER BORE锪底面孔); （4）铰孔：1"/4 DIA REAM铰孔1"/4; （5）螺纹孔的标注一般要表示出螺纹的直径，每英寸牙数（螺矩）、螺纹种类、精度等级、钻深、攻深，方向等。如： 例1.6 HOLES EQUI-SPACED ON 5"DIA (6孔均布在5圆周上（EQUI-SPACED=EQUALLY SPACED均布） DRILL 1"DIATHRO＇ 钻1"通孔（THRO＇=THROUGH通） C/SINK22×6DEEP 沉孔22×6 例2.TAP7"/8-14UNF-3BTHRO＇ 攻统一标准细牙螺纹，每英寸14牙，精度等级3B级 （注UNF=UNIFIED FINE THREAD美国标准细牙螺纹） 1"DRILL 1"/4-20 UNC-3 THD7"/8 DEEP 4HOLES NOT BREAK THRO钻 1"孔，攻1"/4美国粗牙螺纹，每英寸20牙，攻深7"/8,4孔不准钻通（UNC=UCIFIED COARSE THREAD 美国标准粗牙螺纹）

框架结构文献综述

浅谈我国多层混凝土框架结构设计1.前言 随着社会的发展,钢筋混凝土框架结构的建筑物越来越普遍.由于钢筋混凝土结构与砌体结构相比较具有承 载力大、结构自重轻、抗震性能好、建造的工业化程度高等优点；与钢结构相比又具有造价低、材料来源广泛、耐火性好、结构刚度大、使用维修费用低等优点。因此，在我国钢筋混凝土结构是多层框架最常用的结构型式。近年来，世界各地的钢筋混凝土多层框架结构的发展很快，应用很多。 一般框架结构是由楼板、梁、柱及基础4种承重构件组成的，由主梁、柱与基础构成平面框架，各平面框架再由连续梁连接起来而形成的空间结构体系。文献[1]认为，在合理的高度和层数的情况下，框架结构能够提供较大的建筑空间，其平面布置比较的灵活，可适合多种工艺与使用功能的要求。 多层钢筋混凝土框架结构设计可以分为四个阶段：一是方案设计，二是结构分析，三是构件设计，四是绘施工图。结构分析和构件设计是结构设计中的计算阶段，在现代，已由电子计算机承担这一工作，常采用PKPM建模计算。但是，结构的计算并不能代替结构的设计。文献[2]中认为：良好的结构设计的重要前提，应该是合理组织与综合解决结构的传力系统、传力方式，良好的结构方案是良好结构设计的重要前提。 2.关于框架结构设计文献回顾 2.1框架结构的优缺点 框架结构体系是由横梁与柱子连接而成.梁柱连接处(称为节点)一般为刚性连接,有时为便于施工和其他构 造要求,也可以将部分节点做成铰接或者半铰接.柱支座一般为固定支座,必要时也可以设计成铰支座.框架结构可以分为现浇整体式,装配式,现浇装配式. 文献[3]中提到:框架结构的布置灵活,容易满足建筑功能和生工艺的多种要求.同时,经过合理设计,框架结构 可以具有较好的延性和抗震性能.但是,框架结构承受水平力(如风荷载和水平地震作用)的能力较小.当层树 较多或水平力较大时,水平位移较大,在强烈地震作用下往往由于变形过大而引起非结构构件(如填充墙)的 破坏.因此,为了满足承载力和侧向刚度的要求,柱子的截面往往较大,既耗费建筑材料,又减少使用面积.这就 使框架结构的建筑高度受到一定的限制.目前,框架结构一般用于多层建筑和不考虑抗震设防,层数较少的的高层建筑(比如,层数为10层或高度为30米以下) 2.3框架结构的布置 多层框架结构的平面布置形式非常的灵活，文献[4]中将框架结构按照承重方式的不同分为以下三类：(1)横向框架承重方案,以框架横梁作为楼盖的主梁,楼面荷载主要由横向框架承担.由于横向框架数往往较少,主梁沿横向布置有利于增强房屋的横向刚度.同时,主梁沿横向布置还有利于建筑物的通风和采光.但由于主梁截面尺寸较大,当房屋需要大空间时,净空较小,且不利于布置纵向管道.

框架结构外文翻译

南京工程学院毕业设计 外文资料翻译 学生姓名：顾建祥 学号： 240095319 班级名称： K建工ZB093 所在院系：康尼学院

Underground Space Utilization The rapid growth of world civilization will have a significant impact on the way humans live in the future. As the global population increases and more countries demand a higher standard of living, the difficulty of doing this is compounded by three broad trends: the conversion of agricultural land to development uses; the increasing urbanization of the world`s population; and growing concern for the maintenance and improvement of the environment, especially regarding global warming and the impact of population growth. Underground space utilization, as this chapter describes, offers opportunities for helping address these trends. By moving certain facilities and function underground, surface land in urban areas can be used more effectively , thus freeing space for agricultural and recreational purpose. Similarly, the use of terraced earth sheltered housing. Using underground space also enables humans to live more comfortably in densely populated areas while improving the quality of live. On an urban or local level, the use of underground facilities is rising to accommodate the complex demands of today`s society while improving the environment . For example, both urban and rural areas are requiring improved transportation, utility, and recreational services. The state of traffic congestion in many urban areas of the world is at a critical level for the support of basic human living, and it is difficult if not impossible to add new infrastructure at ground level without causing an unacceptable deterioration of the surface environment or an unacceptable relocation of existing land uses and neighborhoods. On a national level in countries around the world, global trends are causing the creation and extension of mining developments and oil or gas recovery at greater depths and in more inaccessible or sensitive locations. Three trends have also led to the developments of improved designs for

土木工程毕业设计文献综述钢筋混凝土框架结构

文献综述 钢筋混凝土框架结构 1.前言 随着经济的发展、科技进步、建筑要求的提升，钢筋混凝土结构在建筑行业得到了迅速发展。随着建筑造型和建筑功能要求日趋多样化，无论是工业建筑还是民用建筑，在结构设计中遇到的各种难题日益增多，钢筋混凝土结构以其界面高度小自重轻，刚度大，承载能力强、延性好好等优点，被广泛应用于各国工程中，特别是桥梁结构、高层建筑及大跨度结构等领域，已取得了良好的经济效益和社会效益。而框架结构具有建筑平面布置灵活、自重轻等优点，可以形成较大的使用空间，易于满足多功能的使用要求，因此，框架结构在结构设计中应用甚广。为了增强结构的抗震能力，框架结构在设计时应遵循以下原则：“强柱弱梁、强剪弱弯、强节点强锚固”。 2.现行主要研究 2.1预应力装配框架结构 后浇整体节点与现浇节点具有相同的抗震能力;钢纤维混凝土对减少节点区箍筋用量有益,但对节点强度、延性和耗能的提高作用不明显。与现浇混凝土节点相比,预应力装配节点在大变形后强度和刚度的衰减及残余变形都小;节点恢复能力强;预制混凝土无粘结预应力拼接节点耗能较小,损伤、强度损失和残余变形也较小。装配节点力学性能受具体构造影响很大,过去进行的研究也较少,一般说,焊接节点整体性好,强度、耗能、延性等方面均可达到现浇节点水平;螺栓连接节点刚度弱,变形能力大,整体性较差。因此,这一类节点连接如应用于抗震区,需做专门抗震设计。 2.2地震破坏 钢筋混凝土在地震破坏过程中瞬态震动周期逐步延长，地震动的低频成分是加剧结构破坏的主要因素，峰值和持时也是非常重要的原因。瞬态振型的变化与结构的破坏部位直接相关。结构破坏过程中，瞬态振型参与系数变化不大。结构瞬态振动周期

毕业设计(论文)外文翻译(译文)

编号：桂林电子科技大学信息科技学院 毕业设计(论文)外文翻译 （译文） 系（部）：机电工程系 专业：机械设计制造及自动化 学生姓名：李汉显 学号：1153100506 指导教师单位：桂林航天工业学院 姓名：陈志 职称：讲师 2015年5 月28日

无损检测技术在检测石油管道时的可靠性 卡瓦略·库切答（a）；雷贝洛（b）；米纳拉辛苏扎·苏哲（b）； 湖奈保尔·苏格瑞勒（c）；萨拉?迪基·苏亚雷斯（d） a、华盛顿苏亚雷斯马路大学科学技术中心，1321；巴西福塔雷萨行政长官,埃德森奎罗兹临时选举委员会:60,811 - 905 b、巴西里约热内卢联邦大学临时选举委员会:21941 - 972 c、巴西里约热内卢联邦大学土木工程系 d、巴西里约热内卢大学城临时选举委员会:21949 - 900 文章内容 文章背景：2006年11月9日收到 2008年5月21日修改后的表格 2008年5月27日认可 关键词：无损检测；可靠性；超声检测；X线摄影 摘要 这项工作的目的是评估无损检测技术（NDT）在检查石油工业中的管道焊缝的可靠性。X射线，手动和全自动的超声波都利用了脉冲回波和光线干涉原理。三个层面的缺陷分析为：缺乏渗透（LP），缺乏融合（LF）和削弱（UC）。这些测试是对含焊缝缺陷已被人为地确定为标本的管道进行测试。结果表明：全自动超声波检测缺陷与手动超声波、X光测试相比更具有优越性。此外，人工神经网络已被用于探测缺陷和缺陷的自动分类。 1简介 在长距离的流体（包括石油和天然气）传输过程中，管道运输时最安全最经济的方法。由于这一点和管道的效率，他们已用了几十年。但是由于种种因素，如腐蚀，疲劳，甚至侵蚀所增加泄漏的危险，甚至破裂，这些都是现在应该考虑的关键问题。还应该指出，许多管道铺设在接近道路，铁路，水路甚至在城市或在其下方。因此，必须有方法监测，评价和肯定管道的完整性，减少泄漏的风险，从而避免环境破坏和人群危害。多年来，无损检测在石油管道的状态检测中显示了其高效性。 无损检测技术正被研究的越来越深，同时已经作为评估工程结构、工程系统使用寿命的方法。这项研究特别注意了石油工业可能发生的设备故障导致严重后果，比如环境污染和人员伤亡。然而，一般认为应考虑采取最适当的参数来选择无损技术，剩下的就是它的使用可靠性，其中一个检测与确定缺陷大小的评估检测概率曲线（POD）是最具代表性的。 对于管道检测的两种技术超声波和X线检查比传统方法更具有出色的效率和易于