文档库 最新最全的文档下载
当前位置:文档库 › FOCLASA 2005 Preliminary Version A Framework for Engineering Interactions in Java-based Com

FOCLASA 2005 Preliminary Version A Framework for Engineering Interactions in Java-based Com

FOCLASA 2005 Preliminary Version A Framework for Engineering Interactions in Java-based Com
FOCLASA 2005 Preliminary Version A Framework for Engineering Interactions in Java-based Com

FOCLASA2005Preliminary Version

A Framework for Engineering Interactions in

Java-based Component Systems

Antonio Natali,Enrico Oliva,Alessandro Ricci,Mirko Viroli DEIS,Alma Mater Studiorum,Universit`a di Bologna,

via Venezia52,I-47023Cesena,Italy

{anatali,eoliva}@deis.unibo.it

{a.ricci,mirko.viroli}@unibo.it

Abstract

This paper describes a Java-based framework for the development of component-based software systems supporting the speci?cation of the logic of component inter-actions as a?rst-class aspect.Java is used as the reference development language. On the one side,the framework makes it possible to specify the logic of interaction at the component-level,in terms of input and output interfaces,the events generated and observed by a component,and related information about the management of the control?ow.On the other side,it is possible to specify the logic of interaction at the inter-component level,providing a modelling and linguistic support for designing and(dynamically)programming the glue among the components,enabling general forms of observation,control and construction of the interaction space.

As a result,the framework supports the coordination of components at di?erent levels:from interoperability among heterogeneous and unknown components,to the support for dynamic introduction,removal and update of components,to general coordination patterns,such as work?ow.

The framework adopts?rst-order logic as the reference computational model for describing and de?ning the logic of interaction:the modalities adopted by compo-nents to interact,the coordination laws gluing the components and the interaction events occurring in the system are expressed as facts and rules.They compose the (evolving)logic theories describing and de?ning the interaction at the system level, and can be observed and controlled at runtime to allow dynamic re-con?gurability. 1Introduction

Nowadays component-based technologies and frameworks(often referred to as componentware)can be considered mainstream approaches for designing and developing complex software systems[13].Examples of most used frame-works include EJB(Enterprise Java beans)as part of the J2EE architec-ture,CCM(CORBA Component Model)as part of CORBA middleware,and This is a preliminary version.The?nal version will be published in

Electronic Notes in Theoretical Computer Science

URL:www.elsevier.nl/locate/entcs

DCOM/COM+and its future incarnations on https://www.wendangku.net/doc/f14858140.html, platform[13].Also some service-oriented frameworks,such as OSGi[11],can be considered essen-tially as component-based frameworks,where components are called services.

Generally speaking,existing mainstream approaches are all essentially based on a sort of“LEGO-like”vision of software systems:the focus is on the notion of component as a basic brick to compose systems,both at design and runtime.The composition is made possible essentially by explicitly declar-ing the interfaces that a component provides for exploiting its services and requires for being able to realise its services.Interfaces act as the formal de-scription of the dependencies which connect together the components—as the joints for(LEGO)bricks.Accordingly,this leads software engineers to reason on application design and development in terms of structural composition of entities.

Actually,such an approach can be considered quite weak when dealing with the engineering of modern software systems,where component interactions and related dynamics are essential elements.Current mainstream approaches do not provide?rst-class support for specifying and managing interactions among components:most of the support concerns solving static dependencies where components are(dynamically)introduced or removed from the system. Back to the LEGO-metaphor,it is not su?cient to have bricks which are composed and linked together for asserting that the overall brick construction works from a dynamic point of view:some kind of dynamics and interaction can lead the overall system to break down,even if the bricks are(statically) connected in a right way and do their job properly.

In this work we present a framework for supporting component-based sys-tems on top of object-oriented mainstream technologies such as Java,which provides a?rst-class support for representing,enacting and controlling the interactions inside the system.The approach does not consider the individual component as the center of the design and development of a component-based systems:this role is instead played by the the logic of interaction,which glues components together,according to a notion of interaction richer than the one that can be speci?ed e.g.with standard object-oriented interfaces.In particu-lar,the framework makes it possible to characterise the logic of interaction at two di?erent levels:at the component level,specifying the interactive capa-bilities of individual components;and at the system level,specifying the laws that de?ne and govern interactions which do not concern a speci?c compo-nent of the system,but characterise the overall ensemble of the components together.

In the overall,the framework makes it possible to design and develop component-systems adopting mainstream technologies—including other component-based framework such as OSGi and EJB—but providing a sup-port for managing interactions at an higher level of abstraction,focussing on the logic of interaction.

The remainder of this article is organised as follows:Section2presents

2

Fig.1.Architectural view of components and kernel

the principles on which the framework is based,Section3describes how the framework is realised on top of the Java platform,Section4focuses on a concrete instance of kernel based on?rst-order logic,Section5exempli?es the approach describing a simple component-based system built on the framework, and?nally Section6concludes the paper.

2The Framework:Vision

The framework introduces two?rst-class abstractions to represent the compo-nents and the environment where they are immersed,so as to better support both the micro(component)and macro(system)levels:actors1and kernels (see Fig.1).

Actors play the role of components of a system,as the basic unit of de-ployment,embedding some kind of business logic.They are meant to execute some kind of task such as the provision of a service,triggered by the recep-tion of some form of stimuli.As components,actors can be introduced and removed dynamically into/from the kernel.

Kernels explicitly represent component environments,providing actors with speci?c services for supporting their interaction.A system then is com-posed by a kernel and a dynamic set of actors,linked and connected through the same kernel.To some extent,the kernel abstraction is similar to the notion of container as found in current component frameworks,extended toward the idea of con?gurable and programmable coordination medium[4].As happens for the actors,also kernels can be dynamically extended and replaced.

1In spite of the name,the notion of actor is not directly linked to the actor abstraction as introduced by Carl Hewitt,but it rather refers to a component capable of interacting,as explained in the following

3

2.1Interaction Signals and Interaction Primitives

From the interaction viewpoint,actors can be conceived as normal objects with the capability of generating and perceiving interaction signals.In particular, they provide their service by reacting to the reception of some interaction signals,and trigger the execution of services by generating signals.

Interaction signals are the basic bricks of the vocabulary of interac-tion which can be used to de?ne the logic of interaction characterising the component-system.In this framework such a notion is represented in the sim-plest way,as a couple(n,v),where n identi?es the name of the signal and v the information content.Each component is characterised by the set of interaction signals that it can eventually generate(output interface)and the set of interaction signals that it can receive(input interface)during its life. Such sets must be explicitly de?ned for each component and are declared/ published in the environment when the component is introduced in the sys-tem.So,interaction signals are meant to specify a form of interaction among actors minimising the(static)dependencies among them:the components do not interact directly with other components directly knowing their references and invoking methods,but indirectly generating and perceiving shared set of signals.

For what concerns the output interface,the kernel provides actors with a basic set of interaction primitives,which actors can use to generate interaction signals.Such primitives are actually important for characterising some basic aspect of the interaction semantics,in particular the attitude or intention of the act and what is expected from that act.Currently the basic set accounts for three primitives:

?notify-used to emit an interaction signal to make some kind of information related to the state or the behaviour of the component observable to other components.The actor emitter is not interested in receiving any kind of information as a result of the operation;

?inform-used to emit an interaction signal to inform its environment of some information,in order to trigger some kind of activity or to answer to a request received in the past.The primitive succeeds if(and when)the information has been completely delivered into the environment,otherwise a InformException is generated;

?invoke-used to emit an interaction signal to execute a service and receive the corresponding result.The primitive works then as a traditional RPC or method invocation,with the result provided as the return parameter of the call.The primitive generates an exception InvokeException if the service cannot be delivered.

It is worth noting that all the primitives are meant to generate a signal without specifying the target actor:the component or set of components that will receive the signal depend on the speci?c logic of interaction de?ned for the

4

Fig.2.Kernel default behaviour for notify,inform and invoke primitives system and enacted by the kernel,as shown in next subsection.

Generally speaking the set of the primitives de?nes and constrains the expressiveness of the interaction support provided by a kernel.The objective here is to factorise the interaction needs that are most frequently found when building component-based systems,abstracting away from how interaction takes place(e.g.either through message passing or shared memory,either local or distributed)and which technology is used,focussing exclusively on the logics of the interaction.Accordingly,the same primitives—with the same semantics—could be supported at the deployment stage by di?erent kinds of kernel,adopting di?erent kind of implementation strategies and technologies, depending on the computational and hardware environment.

Dually to the set of interaction primitives to emit signals,each actor must provide an interface with a doAction operation,which is used—from the environment point of view—to obtain the services that the actor is able to deliver.In particular,doAction speci?es the behaviour of the actor reacting to the reception of any interaction signal that the actor declared among its input signals.The operation can directly return some result—representing the return value of the service invoked,and can generate a DoActionException to represent some kind of runtime error related to the execution of the service, for instance a(semantic)violation of the contract due to wrong arguments. The execution of the service can result also in the generation of output signals (using notify/inform/invoke primitives),for instance for notifying some kind of event or for executing some other services.

2.2Kernel mediation and Interaction Laws

The role of the kernel is then to act as the glue which enables,mediates and controls the generation of output interaction signals of some components which can become input interaction signals for other components.In other words,

5

from a logical point of view,the kernel plays the role of a interaction arti-fact,factorising services for managing component dependencies and dynamic interactions.

The default behaviour of a kernel is to enable interactions based on the name of interaction signals that actors declared to generate or to perceive.In particular(see Fig.2for a graphical description):

?a signal generated by an actor with a notify causes the execution of the doAction operation—with the interaction signal as a parameter—of all the actors that listed the signal among the input ones.The emitter actor is not interested in knowing any information about the e?ects of the invocation,so the kernel could e.g.to do its best in order to realise the call as asynchronously as possible;

?a signal generated with an invoke causes the execution of doAction on one actor chosen among all the actors that listed the signal among the input ones.The return value of the invoke primitive is directly the result provided by the doAction operation.In particular,the kernel is meant to provide the best e?ort to?nd an actor executing the action without failures.So,if the execution of the operation on the chosen actor fails(with the generation of a DoActionException),another actor is to be—e.g.non-deterministically —selected from the remaining ones and the operation doAction is to be executed again on it;If no actor is found providing the services without exceptions,then the invoke fails by generating a InvokeException.

?a signal generated with an inform causes the execution of a doAction on all the actors that listed the signal among the input ones.The primitive succeeds if the kernel is able to deliver the signal to everyone,i.e.to exe-cute the doAction on all the actors,in spite of the possible generation of a DoActionException by each actor.

Besides these basic interaction primitives,the kernel can actually be extended to provides services for de?ning interaction laws in order to directly support some basic patterns of interaction,beyond the basic gluing behaviour.These laws can be speci?ed during the(re-)con?guration stage of the system,which can take place anytime during the execution of the applications.The patterns currently supported in the framework are actually some of the most frequently used ones in mainstream component-based systems,such as Enterprise Java Beans,but working here at an higher level of abstraction:

?event-listening–the kernel provides a support for allowing a dynamic set of listener/reacting actors to observe a speci?c interaction signal generated by a speci?c emitter actor;

?interaction-vetoing–the kernel provides a support for realising vetoed in-teractions,i.e.interactions which actually take place only if no registered actor issues a veto.More precisely,the kernel service makes it possible to specify that a speci?c input signal for a speci?c receiver actor could be ve-

6

toed by a certain vetoer actor;dynamically,an interaction signal directed to the receiver is actually dispatched to the component only if none actors speci?ed as vetoers disagree.

More complex laws can be obtained by composing the speci?cation of mul-tiple simple reactions and veto rules.Others are currently investigated to realise more coordination-oriented interaction patterns,enriching the basic support provided by the kernel.Examples include the ability to specify con-straints such as the order in which listeners are to be informed,or atomic-ity/consistency as in transaction-like scenarios.

It is worth noting that enriching the description of interaction aspects with semantics information improves the support for the principle of local development of components,and—more generally—for engineering open and extensible https://www.wendangku.net/doc/f14858140.html,ponents are typically designed and developed without an a-priori knowledge of the speci?c environments where they will be deployed to;the availability of information concerning the semantics of the interaction of a component—beyond the pure syntactic aspects—simpli-?es their integration and dynamic gluing by the kernel:for instance,this is achieved by applying some kind of coordination rules to enable interoperabil-ity among components in spite of syntax and semantics mismatches among the interactions signals generated/perceived.

2.3Wired and In-The-Space Interaction Modalities

The kernel realises its mediation role by injecting into the actors the logics necessary to realise interactions.In particular,this can take place according to two basic di?erent modalities,called in-the-space and wired,which can basically be seen as di?erent implementation approaches for the kernel.In the former,the kernel is actually a logical and runtime entity,shared and accessed any time a component is generating signals or is stimulated with signals;in this case the logics injected into the components simply provides for basic interaction acts towards the kernel.In the latter,all the peer-to-peer logics of interaction is injected in the components,without any runtime centralising entity.In other words,in the wired case the kernel is completely distributed and injected directly in the components;the component system at runtime becomes an interaction network,with actors playing the roles of the nodes,logically immersed in a shared environment,but actually wired in order to have direct,non-mediated interaction.

3Speci?cation and Implementation Issues

In this section we describe the main aspects of the current design of this framework,including speci?cation of architecture and implementation details.

The relationship between kernel and actor is realised exploiting the in-

7

Fig.3.Architectural view of elements in the framework

version of control(IoC)pattern2:some con?guration code is in charge of injecting a reference to the kernel inside the actor,so that the latter can di-rectly access its environment without being responsible for retrieving it.In Figure3,the elements that compose the framework are represented.On the one hand,an actor component should provide the interface IActor—namely by implementing it—,de?ning the operations that it makes available to the other actors and to the kernel.These include the methods to con?gure the actor itself,as well as the method implementing the services realised by the actor,used to receive signals.On the other hand,the actor component should require the interface IKernel—namely,the kernel referenced by the actor through the IoC pattern should implement the IKernel interface.This in-terface includes the methods to register an actor to the kernel,to declare its input and output signals,and to invoke kernel interaction primitives(to emit signals).

Table1shows a possible way to classify these operations.The IActor interface is used at con?guration-time to inject the kernel into the actor in-stance,and by the kernel at interaction-time to invoke services.Dually,the IKernel interface is used at con?guration-time to register an actor and its signals,and by the actors at interaction-time to invoke interaction primitives. Operations IActor IKernel

Con?guration time Injecting the kernel Registering and declaring

signals to the kernel

Interaction time Requesting execution of ac-

tions/services

Invoking the interaction

primitives

Table1

Interfaces structure

2The IoC pattern is now becoming a standard approach for developing containers in component-based systems(https://www.wendangku.net/doc/f14858140.html,/Java/Article/27583)

8

3.1IActor

In the actual incarnation of our framework an actor is expressed as a Java class,which has to implement the standard interface IActor:

interface IActor extends IActionBase,IActorSpecification{} This interface simply extends IActionBase and IActorSpecification,respec-tively describing interaction-time and con?guration-time functionality.The former simply provides method doAction—which has the semantics described in previous section—is used to execute a service realised by the actor.In particular,this is invoked by kernel as a response of a request coming from another actor,achieving both the execution of a service and the return of a result.One such invocation can also fail for a number of reasons—wrong arguments,failures in accessing back-end services,and so on—in which case the execution throws an exception.

interface IActionBase{

Object doAction(String actionName,Object arg)

throws DoActionException;

}

The argument actionName represents the name of the service requested,the ar-gument arg the input information provided for describing details of the requested service;the output result is given type Object for generality.

The interface IActorSpecification provides all the operations used at con?guration-time,by which the presence of the actor in the system can be con?g-ured.

public interface IActorSpecification{

public String getName();

public String[]getInputSignals();

public String[]getOutputSignalsNotify();

public String[]getOutputSignalsInvoke()

public String[]getOutputSignalsInform()

public void setKernel(IKernel kernel);

public IKernel getKernel();

public boolean isActive();

}

The method getName returns the name of the Actor—unique in the running application.The method getInputSignals is used by the kernel to retrieve all the input signals that the actor is able to process,namely,the actionName it is willing to accept by a doAction.The methods getOutputSignalsNotify/Invoke/Inform return the output signals that the actor can generate,namely the list of actionName for the services it can request—either through a notify,invoke,or inform.The methods setKernel and getKernel store and retrieve the reference to the kernel where the actor is connected to—according to the IoC pattern.In the current version of the framework the actors implement other interfaces that allow to inject in the actor also some basic support of the JavaBeans component framework.

9

3.2IKernel

IKernel is the standard interface which any kernel has to implement,providing those methods that each actor has access to—in order to either interact with others or to register its input and output signals.

interface IKernel{

void notify(IActor emitter,String signalName,Object args);

void inform(IActor emitter,String signalName,Object args)

throws InformException;

Object invoke(IActor emitter,String signalName,Object args) throws InvokeException;

void declareNode(String name,Class clazz,Object obj);

void declareInputSignals(IActor receiver,String[]signals);

void declareOutputSignalsNotify(IActor emitter,String[]signals); void declareOutputSignalsInvoke(IActor emitter,String[]signals); void declareOutputSignalsInform(IActor emitter,String[]signals); }

As an actor can invoke a service in three di?erent styles,this interface provides the three corresponding methods notify,inform,and invoke.Method notify is used to send a signal to interested actors without actually caring about any reply result or either any acknowledgment,hence it throws no exception.Method inform is used to send a signal to interested actors:no result is returned,but the end of the operation means that all the interested actors processed the signal.Finally,method invoke is used to request a service to one agent that can execute it,correspondingly receiving a reply.In all cases,the kernel has the burden to retrieve actors(one or more)able to execute a service with the speci?ed name,invoke their doAction name,and properly providing acknowledgment/reply to the emitting actor.

The other methods are used by the actor to register information about its in-terface—in the component-based acceptation of the term.Methods declareNode, declareInputSignal and declareOutputSignals,respectively register the pres-ence of the actor in the system,its input signals(the services it realises),and its output signals(the services it invokes on other actors).

3.3Interaction Laws

Other than providing a basic interaction support,conceptually linking input and output signals and guaranteeing the three di?erent semantics of service requests, a kernel can be implemented so as to support interaction laws.These are used in all those cases where a more advanced coordination ability is to be charged upon the kernel.As explained in previous section,examples of such laws include those supporting event-listening and vetoer semantics.

Each such law is associated with a proper interface that the kernel class has to implement.This interface provides the method(or methods)used to con?gure the interaction law,thus extending the underlying semantics of subsequent calls to methods IKernel.invoke,https://www.wendangku.net/doc/f14858140.html,rm,and IKernel.notify.This mech-anism is thus used to change the default semantics of a kernel,where signals are

10

associated to output signals solely based on the matching of their names.

For the event-listener interaction law,we have for instance the interface: public interface IReactInteraction{

public void reactInteraction(

IActor reactor,IActor emitter,String signalName);

}

Method reactInteraction is to be implemented to realize the pattern publish-subscribe:this is used to register the reactor to receive invocations of the signal with name signalName executed by the actor emitter—namely reactor will observe actions signalName of the emitter.One such law constrains the space of interaction and limit the notify method of an actor for a determined signal and only to the actor indicated in reactInteraction.Actually reactInteraction can be exploited in the framework also for supporting the wired modality as described in previous section.In particular,by calling a set of reactInteraction(O,E,S)we ?x the set of speci?c observers{O}that can observe the signal S emitted by E.By doing so,at con?guration time the kernel(in the reactInteraction)can inject in the emitter actor a support for sending the signal directly to the speci?ed observers, without the mediation of the kernel itself.

Similarly,the vetoing functionality is supported by interface:

public interface IVetoInteraction{

public void vetoInteraction(

IActor vetoer,IActor receiver,String signalName);

}

By calling method vetoInteraction,the kernel is con?gured so that actor vetoer can negatively reply to an output signal signalName produced by actor receiver.

These laws are just a subset of those a kernel can implement:further laws can be realised by adding new interfaces.

4A Logic-based Kernel

While developing our framework,we experimented various implementations for the kernel,providing di?erent ways to represent and manage interactions based on di?erent kinds of lower-level technologies.

Among the others,we found the logic programming paradigm quite useful.The corresponding kernel,called Logic Kernel,adopts?rst-order logic for describing and enacting the logic of interaction,including both the interaction capabilities of individual actors,and the coordination laws which de?ne how the interactions are globally managed.In other words,the kernel handles as logic theories both the con?guration of the system—actors immersed in the environment,their set of input/output interaction signals,and the laws governing interactions—and the interaction events that dynamically occur.The mediation and coordination activities of this kernel are then realised by exploiting a logic engine(based on Prolog),properly handling the occurring interactions based on the interaction laws and the actors con?guration.

11

4.1Implementation

This kernel is realised following the“in the space”modality,namely,as a run-time abstraction where interaction signals are rei?ed and properly managed.It is imple-mented through a class LogicKernel implementing interface IKernel—namely,

a component providing the IKernel interface.Moreover,it also implements the interface IContextLocal that provides functionality to load,save and execute a

logic theory,con?guring and modifying the kernel at run-time.The implementa-

tion of this class is based on the tuProlog open source project we developed[5] (https://www.wendangku.net/doc/f14858140.html,).This is a lightweight Prolog engine and

API written in Java which provides smooth integration of Prolog and Java pro-gramming,allowing to either represent and invoke Prolog goals from Java,as well

as calling Java libraries within Prolog theories.

public interface IContextLocal{

public alice.tuprolog.Prolog getPrologEngine();

public void register(String term,Object obj);

public boolean loadTheory(String absPath);

public boolean saveTheory(String absPath);

public String standardQuery(String queryS);

public String query(String queryS);

public String nextSolution();

public alice.tuprolog.SolveInfo solve(String queryS);

}

Basically,this interface provides a wrapper to the API of tuProlog,with methods

to handle basic Prolog primitives to load and save theories,execute queries and retrieve solutions,and so on.

By exploiting these functions,the LogicKernel has to realize the methods pro-

vided by the IKernel interface.The methods supporting con?guration simply cause

a term—also called here a tuple—containing information on the arguments to

be rei?ed in the knowledge base as follows:

declareNode—This method is used to register an actor in the kernel;an invoca-

tion is represented by the tuple node(NodeName,Class). declareInputSignals—This method is used to register the input signals

an actor is interested in receiving;an invocation is represented by a tuple

reacts(Reactor,ActionName)for each signal speci?ed in the input array. declareOutputSignalsNotify/Invoke/Inform—These three methods are used

to register the output notify/invoke/inform signals an actor may receive;an invocation is represented by a tuple declaresNotify(Emitter,ActionName), declaresInvoke(Emitter,ActionName),or declaresInform(Emitter,ActionName), for each signal speci?ed in the input array.

These tuples are then actually seen as Prolog facts reacts/2,declaresNotify/2, declareInvoke/2,declareInform/2and node/2,inserted dynamically in the knowledge based at con?guration time.

Other than con?guration details,also the occurrence of interactions between

actors are inserted in the knowledge base dynamically.A method trace in class

12

LogicKernel writes in the knowledge base a term of the kind out(Emitter, ActionName,Arg),where Emitter is the agent responsible for the interaction, ActionName is the signal name,and Arg is the signal argument.

When a method invoke,inform,or notify is invoked on the kernel,a corresponding prolog predicate invokeInTheSpace/4,informInTheSpace/3,and notifyInTheSpace/3is called,which is in charge of allowing the proper actors to perceive the signal,supporting the precise semantics of each of the three primitive.

The implementation of predicate invokeInTheSpace/4is as follows: invokeInTheSpace(Emitter,ActionName,Arg,Res):-

reacts(Reactor,ActionName),

node(Reactor,Class),

declares(Emitter,ActionName),

Reactor<-doAction(ActionName,Cmd)returns Res,

!.

While the?rst three arguments are as usual,the last is an output,providing invo-cation result.The predicate orderly(i)retrieves a Reactor willing to accept the signal,(ii)checks whether it is registered as a node,(iii)checks whether it declared the corresponding input signal,and?nally(iv)invokes method doAction on it, returning result Res.Note that in tuProlog,binary in?x predicate<-is used to invoke the method speci?ed on the right-side over the Java object identi?ed by the reference speci?ed on the left-side—with the optional?nal part returns specify-ing the result.If such an invocation fails for some reason,predicate<-fails:for the backtracking semantics of Prolog this causes predicate reacts to?nd another solution,namely another Reactor.If the invocation is instead successful,the cut predicate!completes the execution.In the end,this preserves the semantics of invoke primitive:the kernel will keep looking for one(and precisely one)actor that successfully executes the service requested.

The implementation of predicate notifyInTheSpace/3is as follows: notifyInTheSpace(Emitter,ActionName,Arg):-

reacts(Reactor,ActionName),

node(Reactor,Class),

declaresNotify(Emitter,ActionName),

Reactor<-doAction(ActionName,Arg),

fail.

notifyInTheSpace(Emitter,ActionName,Arg).

Di?erently from the previous case,this predicate does not provide replies,but sim-ply returns when its task is over.As a proper actor is found and its doAction method is invoked,meta-predicate fail causes the Prolog engine to backtrack and ?nd another actor by predicate reacts.When no more such actors exist,the sec-ond clause positively terminates the invocation.Note that if some invocation of doAction would fail,this does not interfere at all with the engine execution.This behaviour preserves the semantics of notify primitive:the kernel should?nd all actors interested in the noti?cation—the emitting actor being not interested about some registered actor not perceiving the noti?cation.

Finally,the implementation of predicate informInTheSpace/3is as follows:

13

Fig.4.Inspector tool

informInTheSpace(Emitter,ActionName,Arg):-

assert(proceed(Emitter,ActionName)),

reacts(Reactor,ActionName),

proceed(Emitter,ActionName),

node(Reactor,Class),

declaresNotify(Emitter,ActionName),

retract(proceed(Emitter,ActionName)),

Reactor<-doAction(ActionName,Arg),

assert(proceed(Emitter,ActionName)),

fail.

informInTheSpace(Emitter,ActionName,Arg):-

proceed(Emitter,ActionName),

retract(proceed(Emitter,ActionName)).

This is similar to predicate notifyInTheSpace.The main di?erence is that a fact proceed is rei?ed in the space at the beginning and is dropped if some doAction fails.As it is dropped the execution terminates negatively,otherwise when all actors have been informed without exceptions the execution returns positively. This behaviour preserves the semantics of inform primitive:the kernel should?nd all actors interested in being informed—the emitting actor being interested in whether all registered actors correctly perceived the signal.

A main advantage of the logic kernel approach is that it allows for easily track-ing the occurrence of interactions and their management,namely,the true run-time behaviour of the application.Figure4shows the Inspector tool of the frame-work,used to display all the relevant information about state and evolution of the logic kernel.In particular,this tool can inspect the current kernel con?guration (button selfDescribe),the interactions occurred and rei?ed as out tuples(but-ton showInteractions),the logic theory governing interaction laws—namely,the coordination behaviour in the system—(button showTheory).The inspector tool can be used to debug application and to modify the laws of interaction at run time, to see and experiment di?erent system evolutions.

So,typically the logic kernel is used in prototyping and debugging stages:when the logic of interaction has proven correct a more e?cient version of the system can be obtained by wiring the interactions by means of the reactInteraction kernel

14

primitive.In particular,in the Logic-Kernel such a primitive wires the emitter and observers actors using the Java event-listener pattern.

5A Simple Example:the Ping-Pong System

To give a?avour of framework classes and behaviour,here we consider a very simple system,referred to as Ping-Pong,made by two components which must be coordinated by a simple rule.The source code of the Java classes implementing this example is reported in Fig.5.The components are represented by the classes PingActor and PongActor,referred here as respectively the ping actor and the pong actor.The behaviour of the components is very simple:they react to the reception of a speci?c input signal(ping for the ping actor,pong for the pong actor),and after doing their job(just sleeping in our implementation)they emit a speci?c output signal(pong for the ping actor and ping for the pong actor).Actors share the same interaction signals:the signal generated by an actor triggers the execution of the service by the other actor.

The simple coordination rule that we want to realise accounts for stopping the interaction between the actors after N stages,i.e.after N generations of the ping-pong couple of signals.The rule must be speci?ed and enforced without changing the behaviour of the individual actors.For this purpose,we de?ne a vetoing interaction law,with a new actor acting as vetoer of the input signals noti?ed to the ping actor. The vetoer essentially counts the number of times a ping signal is noti?ed to the actor and gives its consensus for the delivery of the signal to the ping actor only if the number of signals is less than the N value.

Finally,in the main class the various parts of the system are created and con-?gured,including the kernel,the actors and the vetoing interaction law making the vetoActor a vetoer for the input signal of pingActor.A ping signal is generated in order to trigger the activities of the components.

6Related Work and Conclusion

Several models and architectures for component speci?cation and component com-position can be found in literature,both in the context of coordination models and languages[12,8]and in the context of software architectures[6],including ADL (architectural description language)approaches such as[9,7,10].Among the others, two recent and notable examples are respectively Reo[1]and Rainbow[3].Dif-ferently from these approaches,the framework presented in this paper takes as a reference context component-based technologies and frameworks that are currently used in the mainstream,in particular based on object-oriented languages such as Java.The objective is to inject in such contexts some of the principles and visions that typically characterise most of the approaches found in the research,such as the focus on interaction and coordination as a main engineering dimension,and the in-troduction of?rst-class abstractions(media)for their speci?cation and management (exogenous coordination).

A distinguishing point of the framework with respect to current approaches in literature is the investigation of?rst-order logic for specifying and representing the logic of interaction,including the interaction contracts of the components(ac-

15

public class PingActor extends AbstractActor{

public PingActor(String logo){

super(logo);

}

public void doAction(String actionName,Object args)throws DoActionException{ try{

Thread.sleep(1000);

kernel.notify("ping","noArg");

}catch(Exception ex){throw new DoActionException();}

}

public String[]getInputSignals(){return new String[]{"pong"};}

public String[]getOutputSignalsNotify(){return new String[]{"ping"};}

}

public class PongActor extends AbstractActor{

public PongActor(String logo){

super(logo);

}

public void doAction(String actionName,Object args)throws DoActionException{ try{

Thread.sleep(2000);

kernel.notify("pong","noArg");

}catch(Exception ex){throw new DoActionException();}

}

public String[]getInputSignals(){return new String[]{"ping"};}

public String[]getOutputSignalsNotify(){return new String[]{"pong"};}

}

public class VetoActor extends AbstractActor{

private int count;

private int max;

public VetoActor(String logo){

super(logo);

count=0;

}

public VetoActor(String logo,int max){

super(logo);

count=0;

this.max=max;

}

public Object doAction(String actionName,Object args)throws DoActionException{ return(count++>=max);

}

public String[]getInputSignals(){return new String[]{"pong"};}

}

}

public class TestPingPong{

public static void main(String[]args){

kernel=new LogicKernel();

ping=new PingActor("pingActor");

ping.setKernel(kernel);//injection of the kernel

pong=new PongActor("pongActor");

pong.setKernel(kernel);//injection of the kernel

veto=new VetoActor("vetoActor",3);

veto.setKernel(kernel);//injection of the kernel

kernel.vetoInteraction(veto,ping,ping.getInputSignals()[0]);

kernel.notify("ping","noArgs");

}

}

Fig.5.Code for the Ping-Pong Example

16

tors),the interaction/coordination laws gluing the components and the interaction events actually happening at runtime.A somewhat similar approach working on mainstream technologies is given by Composition-Filters—exploited in the context of Aspect-Oriented Programming—where declarative rules are superimposed for intercepting,?ltering,re-routing,and changing the message tra?c among objects to support certain inter-and intra-class cross-cutting concerns[2].

Several research lines will be explored in future works.Among the others:the enhancement of the basic set of interaction/coordination laws directly supported by the kernel;the exploitation of the logic-based kernel for the engineering of self-adapting and self-healing systems;the de?nition of a formal model for the framework in order to specify and understand more rigorously the behaviour of component-based system built on top it.

References

[1]Arbab,F.,Abstract behavior types:a foundation model for components and their

composition,Science of Computer Programming55(2005),pp.3–52.

[2]Bergmans,L.and M.Aksit,Composing crosscutting concerns using composition

?lters,Communications of the ACM44(2001),pp.51–57.

[3]Cheng,S.-W.,A.-C.Huang,D.Garlan,B.Schmerl and P.Steenkiste,Rainbow:

Architecture-based self adaptation with reusable infrastructure,IEEE Computer 37(2004),pp.3–52.

[4]Denti,E.,A.Natali and A.Omicini,Programmable coordination media,in:

D.Garlan and D.Le M′e tayer,editors,Coordination Languages and Models–

Proceedings of the2nd International Conference(COORDINATION’97),LNCS 1282(1997),pp.274–288.

[5]Denti,E.,A.Omicini and A.Ricci,Multi-paradigm Java-Prolog integration

in tu Prolog,Science of Computer Programming(2005),in press.Available at https://www.wendangku.net/doc/f14858140.html,/10.1016/j.scico.2005.02.001.

[6]Garlan,D.,Software architecture:a roadmap,in:A.Finkelstein,editor,The

Future of Software Engineering,ACM Press,2000.

[7]Garlan,D.,R.T.Monroe and D.Wile,Acme:an architecture description

interchange language.,in:CASCON,1997,p.7.

[8]Gelernter,D.and N.Carriero,Coordination languages and their signi?cance,

Communication of the ACM35(1992),pp.96–107.

[9]Luckham,D.C.and J.Vera,An event-based architecture de?nition language,

IEEE Transactions on Software Engineering21(1995),pp.717–734.

[10]Magee,J.,N.Dulay,S.Eisenbach and J.Kramer,Specifying distributed software

architectures.,in:ESEC(1995),pp.137–153.

[11]Osgi service platform,https://www.wendangku.net/doc/f14858140.html,(1999).

17

[12]Papadopoulos,G. A.and F.Arbab,Coordination models and languages,

Advances in Computers46(1998),pp.329–400.

[13]Szyperski,C.,D.Gruntz and S.Murer,“Components Software:Beyond Object-

Oriented Programming,”Addison-Wesley,2002.

18

材料科学基础期末试题

材料科学基础考题 I卷 一、名词解释(任选5题,每题4分,共20分) 单位位错;交滑移;滑移系;伪共晶;离异共晶;奥氏体;成分过冷答: 单位位错:柏氏矢量等于单位点阵矢量的位错称为单位位错。 交滑移:两个或多个滑移面沿着某个共同的滑移方向同时或交替滑移,称为交滑移。滑移系:一个滑移面和此面上的一个滑移方向合起来叫做一个滑移系。 伪共晶:在非平衡凝固条件下,某些亚共晶或过共晶成分的合金也能得全部的共晶组织,这种由非共晶成分的合金所得到的共晶组织称为伪共晶。 离异共晶:由于非平衡共晶体数量较少,通常共晶体中的a相依附于初生a相生长,将共晶体中另一相B推到最后凝固的晶界处,从而使共晶体两组成相相间的组织特征消失,这种两相分离的共晶体称为离异共晶。 奥氏体:碳原子溶于丫-Fe形成的固溶体。 成分过冷:在合金的凝固过程中,将界面前沿液体中的实际温度低于由溶质分布所决定的凝固温度时产生的过冷称为成分过冷。 二、选择题(每题2分,共20分) 1. 在体心立方结构中,柏氏矢量为a[110]的位错(A )分解为a/2[111]+a/2[l11]. (A)不能(B)能(C)可能 2. 原子扩散的驱动力是:(B ) (A)组元的浓度梯度(B)组元的化学势梯度(C)温度梯度 3?凝固的热力学条件为:(D ) (A)形核率(B)系统自由能增加 (C)能量守衡(D)过冷度 4?在TiO2中,当一部分Ti4+还原成Ti3+,为了平衡电荷就出现(A) (A)氧离子空位(B)钛离子空位(C)阳离子空位 5?在三元系浓度三角形中,凡成分位于( A )上的合金,它们含有另两个顶角所代表的两 组元含量相等。 (A)通过三角形顶角的中垂线 (B)通过三角形顶角的任一直线 (C)通过三角形顶角与对边成45°的直线 6?有效分配系数k e表示液相的混合程度,其值范围是(B ) (A)1vk e

生物化学试卷A答案

华中科技大学生命学院2007-2008学年度第一学期考试试卷 《生物化学》考试试题A卷答案 闭卷考试时间:150分钟 专业班级姓名学号分数 一名词解释(20分) 1.基本氨基酸 构成蛋白质的20种α-氨基酸。包括Gly、Ser、Thr、Cys、Gln、Tyr、Asn、Lys、Arg、 His、Glu、Asp,Ile、Leu、Val、Trp、Phe、Met、Ala、Pro。 2.蛋白质的等电点 在某一pH下蛋白质的净电荷为零。在电场中不泳动,该pH即称为该蛋白质的等电 pH(pI)。不同的蛋白质由于带有可电离R基团的氨基酸残基含量各异,有不同的等电点pI。由于蛋白质能同某些阴离子或阳离子结合,所以它们的等电点将随着介质的离子组成而有所变动. 3.结构域 指蛋白质构象中折叠相对比较紧密的区域,结构域之间在空间结构上相对独立,每个 结构域均具备小的球蛋白的性质。结构域作为蛋白质的折叠单位、结构单位、功能单位和 遗传单位。结构域的类型有全平行α螺旋式,平行或混合型β折叠片式,反平行β折叠片式, 富含金属或二硫键式等。 4.别构酶 服从别构调节的酶。例如天冬氨酸转氨甲酰酶(ATCase)。别构酶多为寡聚蛋白,有 一个或多个别构部位,可以结合别构调节物,并通过异促协同,改变酶与底物的结合。别 构酶具有与简单的非调节酶不同的理化性质和动力学行为。 5.维生素PP和NAD+ 维生素PP包括烟酸和烟酰胺,属于水溶性维生素。缺乏时可引起癞皮病,但是由于分布广泛,一般不会发生缺乏症。NAD+,即烟酰胺腺嘌呤二核苷酸,是维生素PP的辅酶形式。NAD+作为许多脱氢酶的辅酶,参与氧化还原,在这些反应中,以NAD+? NADH形式传递电子。 6.DNA变性 指在某些理化因素作用下,DNA两条链间的氢键断裂,两链分开的过程。高温、酸碱、有机溶剂、射线、脲、胍、甲酰胺均可引起DNA变性。变性后DNA的理化性质发生变化,

电气设备检测技术

第一次作业完整版 填空题: 1、抑制干扰信号的硬件措施有硬件滤波器、差动平衡系统和电子鉴别系统。 2、传统的避雷器是由放电间隙和碳化硅阀片电阻构成。 3、局部放电信号的监测方法可分为电测法和非电测法两种。 4、气相色谱分析的气体分离功能由色谱柱完成。 5、气体传感器可分为干式和湿式两大类。 6、抑制干扰信号的软件措施有数字滤波器、平均技术、逻辑判断和开窗。 7、变压器放电量的在线标定通常采用套管末屏注入法。 8、色谱分析常用的鉴定器有热导池鉴定器TCD和氢火焰离子化鉴定器FID两种。 9、光电信号的调制方式主要有调幅式调制、调频式调制和脉码调制-光强调制三种。 10、一般新纸的聚合度n等于1300左右。 11、抑制干扰信号的软件措施有数字滤波器、平均技术、逻辑判断和开窗。 12、抽真空取气方法的油中溶解气体在线监测装置根据产生真空的方式不同,可以分为波纹管法和真空泵脱气法 判断题 1、在线监测系统的信号处理和诊断子系统一般在主控室内。正确 2、线性度是传感器输出量和输入量间的实际关系与它们的拟合直线之间的最大偏差与满量程输出值之比。正确 3、根据振动的频率来确定所测量的量,随频率的减低可分别选用位移传感器、速度传感器和加速度传感器。错误 4、比色法传感器属于湿式气体传感器。正确 5、当水树增加时,直流叠加电流迅速降低。错误 6、H2,CO,N2等溶解度低的气体的奥斯特瓦尔德系数随温度的上升而基本不变。正确 7、频率响应特性是传感器的静态特性。错误 8、变压器油在300℃~800℃时,热分解产生的气体主要是氢气和乙炔,并有一定量的甲烷和乙烯。错误 单选题: 1、单晶型光电导探测器常用材料为(D )。 2、频率为60kHz~100MHz的振动信号选用(C )监测。 3、下列干扰信号中属于脉冲型周期性干扰信号有(B )。 4、氧化锌阀片的介电常数er为(B )。 5、对额定电压为6.6kV的电力电缆,若直流泄漏电流(C )是好电缆 6、电机绝缘内部放电放电电压最低的是(D )。 7、根据GB/T17623-1998和IEC60599-1999,20℃时O2在矿物绝缘油中的奥斯特瓦尔德系数为(A )。 8、监测系统按(B )分为便携式和固定式。 第二次作业的论述题 1、电力设备状态维修的主要优点。答:(1)可有效地使用没备,提高没备利用率。(2)降低备件的库存量以及更换零部件与维修所需费用。(3)有目标地进行维修,可提高维修水平,使设备运行更安全可靠。(4)可系统地对没备制造部门反馈设备的质量信息,用以提高产品的可靠性。 2、变压器油的"呼吸作用”。答:变压器油的"呼吸作用”是指变压器负载在一天

《电气设备状态监测与故障诊断技术》复习提纲(附答案)

《电气设备状态监测与故障诊断技术》复习提纲 1 预防性试验的不足之处(P4) 答: 1、需停电进行试验,而不少重要电力设备,轻易不能停止运行。 2、停电后设备状态(如作用电压、温度等)与运行中不符,影响判断准确度。 3、由于是周期性定期检查,而不是连续的随时监测,绝缘仍可能在试验间隔期发生故障。 4、由于是定期检查和维修,设备状态即使良好时,按计划也需进行试验和维修,造成人力 物力浪费,甚至可能因拆卸组装过多而造成损坏,即造成所谓过度维修。 2 状态维修的原理(P4) 答:绝缘的劣化、缺陷的发展虽然具有统计性,发展的速度也有快慢,但大多具有一定的发展期。在这期间,会有各种前期征兆,表现为其电气、物理、化学等特性有少量渐进的变化。随着电子、计算机、光电、信号处理和各种传感技术的发展,可以对电力设备进行在线状态监测,及时取得各种即使是很微弱的信息。对这些信息进行处理和综合分析,根据其数值的大小及变化趋势,可对绝缘的可靠性随似乎做出判断并对绝缘的剩余寿命做出预测,从而能早期发现潜伏的故障,必要时可提供预警或规定的操作。 3 老化的定义(P12) 答:电气设备的绝缘在运行中会受到各种因素(如电场、热、机械应力、环境因素等)的作用,部将发生复杂的化学、物理变化,会导致性能逐渐劣化,这种现象称为老化。 4 电气设备的绝缘在运行常会受到哪些类型的老化作用?(P12) 答:有热老化、电老化、机械老化、环境老化、多应力老化等。 5 热老化的定义(P12) 答:由于在热的长期作用下发生的老化称为热老化。 6 什么是8℃规则?(P13) 答:根据V.M.Montsinger提出的绝缘寿命与温度间的经验关系式可知,lnL和t呈线性关系,并且温度每升高8℃,绝缘寿命大约减少一半,此即所谓8℃规则。 7 可靠性、失效与故障的定义(P21) 答:可靠性:产品在规定条件下和规定的时间区间完成规定功能的能力。 失效:产品终止完成规定功能的能力这样的事件。 故障:产品不能执行规定功能的状态。 8 典型的不可修复元件,其失效率曲线呈什么形状?有哪些组成部分?(P22) 答:典型的不可修复元件,一般为电子器件,其失效率曲线呈浴盆状,可分为三个部分:早期失效期、恒定失效期和耗损失效期。 9 寿命试验的目的和方式(26)

材料科学基础试题

第一章原子排列 本章需掌握的内容: 材料的结合方式:共价键,离子键,金属键,范德瓦尔键,氢键;各种结合键的比较及工程材料结合键的特性; 晶体学基础:晶体的概念,晶体特性(晶体的棱角,均匀性,各向异性,对称性),晶体的应用 空间点阵:等同点,空间点阵,点阵平移矢量,初基胞,复杂晶胞,点阵参数。 晶系与布拉菲点阵:种晶系,14种布拉菲点阵的特点; 晶面、晶向指数:晶面指数的确定及晶面族,晶向指数的确定及晶向族,晶带及晶带定律六方晶系的四轴座标系的晶面、晶向指数确定。 典型纯金属的晶体结构:三种典型的金属晶体结构:fcc、bcc、hcp; 晶胞中原子数、原子半径,配位数与致密度,晶面间距、晶向夹角 晶体中原子堆垛方式,晶体结构中间隙。 了解其它金属的晶体结构:亚金属的晶体结构,镧系金属的晶体结构,同素异构性 了解其它类型的晶体结构:离子键晶体结构:MgO陶瓷及NaCl,共价键晶体结构:SiC陶瓷,As、Sb 非晶态结构:非晶体与晶体的区别,非晶态结构 分子相结构 1. 填空 1. fcc结构的密排方向是_______,密排面是______,密排面的堆垛顺序是_______致密度为___________配位数是________________晶胞中原子数为___________,把原子视为刚性球时,原子的半径是____________;bcc结构的密排方向是_______,密排面是_____________致密度为___________配位数是________________ 晶胞中原子数为___________,原子的半径是____________;hcp结构的密排方向是_______,密排面是______,密排面的堆垛顺序是_______,致密度为___________配位数是________________,晶胞中原子数为 ___________,原子的半径是____________。 2. bcc点阵晶面指数h+k+l=奇数时,其晶面间距公式是________________。 3. Al的点阵常数为0.4049nm,其结构原子体积是________________。 4. 在体心立方晶胞中,体心原子的坐标是_________________。 5. 在fcc晶胞中,八面体间隙中心的坐标是____________。 6. 空间点阵只可能有___________种,铝晶体属于_____________点阵。Al的晶体结构是__________________, -Fe的晶体结构是____________。Cu的晶体结构是_______________, 7点阵常数是指__________________________________________。 8图1是fcc结构的(-1,1,0 )面,其中AB和AC的晶向指数是__________,CD的晶向指数分别 是___________,AC所在晶面指数是--------------------。

生物化学试题及答案(6)

生物化学试题及答案(6) 默认分类2010-05-15 20:53:28 阅读1965 评论1 字号:大中小 生物化学试题及答案(6) 医学试题精选2010-01-01 21:46:04 阅读1957 评论0 字号:大中小 第六章生物氧化 【测试题】 一、名词解释 1.生物氧化 2.呼吸链 3.氧化磷酸化 4. P/O比值 5.解偶联剂 6.高能化合物 7.细胞色素 8.混合功能氧化酶 二、填空题 9.琥珀酸呼吸链的组成成分有____、____、____、____、____。 10.在NADH 氧化呼吸链中,氧化磷酸化偶联部位分别是____、____、____,此三处释放的能量均超过____KJ。 11.胞液中的NADH+H+通过____和____两种穿梭机制进入线粒体,并可进入____氧化呼吸链或____氧化呼 吸链,可分别产生____分子ATP或____分子ATP。 12.ATP生成的主要方式有____和____。 13.体内可消除过氧化氢的酶有____、____和____。 14.胞液中α-磷酸甘油脱氢酶的辅酶是____,线粒体中α-磷酸甘油脱氢酶的辅基是____。 15.铁硫簇主要有____和____两种组成形式,通过其中的铁原子与铁硫蛋白中的____相连接。 16.呼吸链中未参与形成复合体的两种游离成分是____和____。 17.FMN或FAD作为递氢体,其发挥功能的结构是____。 18.参与呼吸链构成的细胞色素有____、____、____、____、____、____。 19.呼吸链中含有铜原子的细胞色素是____。 20.构成呼吸链的四种复合体中,具有质子泵作用的是____、____、____。 21.ATP合酶由____和____两部分组成,具有质子通道功能的是____,____具有催化生成ATP 的作用。 22.呼吸链抑制剂中,____、____、____可与复合体Ⅰ结合,____、____可抑制复合体Ⅲ,可抑制细胞色 素c氧化酶的物质有____、____、____。 23.因辅基不同,存在于胞液中SOD为____,存在于线粒体中的 SOD为____,两者均可消除体内产生的 ____。 24.微粒体中的氧化酶类主要有____和____。 三、选择题

电气测试技术林德杰课后答案

1-1 答:应具有变换、选择、比较和选择4种功能。 1-2 答:精密度表示指示值的分散程度,用δ表示。δ越小,精密度越高;反之,δ越大,精密度越低。准确度是指仪表指示值偏离真值得程度,用ε表示。ε越小,准确度越高;反之,ε越大,准确度越低。精确度是精密度和准确度的综合反映,用τ表示。再简单场合,精密度、准确度和精确度三者的关系可表示为:τ=δ+ε。 1-5 答:零位测量是一种用被测量与标准量进行比较的测量方法。其中典型的零位测量是用电位差及测量电源电动势。其简化电路如右下图所示。图中,E 为工作电源,E N 为标准电源,R N 为标准电阻,E x 为被测电源。 测量时,先将S 置于N 位置,调节R P1,使电流计P 读书为零,则N N 1R E I =。然后将S 置于x 位置,调节R P2,使电流计P 读书为零,则x x R E I =2。由于两次测量均使电流计P 读书为零,因此有 N N N N 21E R R E R E x R x E I I x x =?=?= 零位测量有以下特点: 1) 被测电源电动势用标准量元件来表示,若采用高精度的标准元件,可有效提高测量精度。 2) 读数时,流经E N 、E x 的电流等于零,不会因为仪表的输入电阻不高而引起误差。 3) 只适用于测量缓慢变化的信号。因为在测量过程中要进行平衡操作。 1-6答:将被测量x 与已知的标准量N 进行比较,获得微差△x ,然后用高灵敏度的直读史仪表测量△x ,从而求得被测量x =△x +N 称为微差式测量。由于△x <N ,△x <<x ,故测量微差△x 的精度可能不高,但被测量x 的测量精度仍然很高。 题2-2 解:(1) ΔA =77.8-80=-2.2(mA ) c =-ΔA =2.2(mA ) %.%.-%A ΔA γA 75210080 22100=?=?=

材料科学基础试卷(带答案)

材料科学基础试卷(一) 一、概念辨析题(说明下列各组概念的异同。任选六题,每小题3分,共18分) 1 晶体结构与空间点阵 2 热加工与冷加工 3 上坡扩散与下坡扩散 4 间隙固溶体与间隙化合物 5 相与组织 6 交滑移与多滑移 7 金属键与共价键 8 全位错与不全位错 9 共晶转变与共析转变 二、画图题(任选两题。每题6分,共12分) 1 在一个简单立方晶胞内画出[010]、[120]、[210]晶向和(110)、(112)晶面。 2 画出成分过冷形成原理示意图(至少画出三个图)。 3 综合画出冷变形金属在加热时的组织变化示意图和晶粒大小、内应力、强度和塑性变化趋势图。 4 以“固溶体中溶质原子的作用”为主线,用框图法建立与其相关的各章内容之间的联系。 三、简答题(任选6题,回答要点。每题5分,共 30 分) 1 在点阵中选取晶胞的原则有哪些? 2 简述柏氏矢量的物理意义与应用。 3 二元相图中有哪些几何规律? 4 如何根据三元相图中的垂直截面图和液相单变量线判断四相反应类型? 5 材料结晶的必要条件有哪些?

6 细化材料铸态晶粒的措施有哪些? 7 简述共晶系合金的不平衡冷却组织及其形成条件。 8 晶体中的滑移系与其塑性有何关系? 9 马氏体高强度高硬度的主要原因是什么? 10 哪一种晶体缺陷是热力学平衡的缺陷,为什么? 四、分析题(任选1题。10分) 1 计算含碳量0.04的铁碳合金按亚稳态冷却到室温后,组织中的珠光体、二次渗碳体和莱氏体的相对含量。 2 由扩散第二定律推导出第一定律,并说明它们各自的适用条件。 3 试分析液固转变、固态相变、扩散、回复、再结晶、晶粒长大的驱动力及可能对应的工艺条件。 五、某面心立方晶体的可动滑移系为(111) [110].(15分) (1) 指出引起滑移的单位位错的柏氏矢量. (2) 如果滑移由纯刃型位错引起,试指出位错线的方向. (3) 如果滑移由纯螺型位错引起,试指出位错线的方向. (4) 在(2),(3)两种情况下,位错线的滑移方向如何? (5) 如果在该滑移系上作用一大小为0.7的切应力,试确定单位刃型位错和螺型位错 线受力的大小和方向。(点阵常数0.2)。 六、论述题(任选1题,15分) 1 试论材料强化的主要方法、原理及工艺实现途径。 2 试论固态相变的主要特点。 3 试论塑性变形对材料组织和性能的影响。

农作物种植技术(北方版)专业

玉米合理密植的原则 ①根据品种特性确定密度:早熟、矮杆的品种密度大,晚熟、高杆的品种密度小 ②根据地力、水肥条件确定密度:肥地密,薄地稀。水地密,旱地稀。 ③根据播期确定密度:夏播玉米密,春播玉米稀。 ④根据气候条件确定密度:地势高,气候低应密。地势低,气候高应稀。 玉米穗期、花粒期的生育特点. 玉米穗期是营养生长与生殖生长并进期,此期不仅茎叶生长旺盛,而且雌、雄穗先后开始分化 玉米花粒期营养器官基本形成,植株进入以开花、散粉、受精结实为主的生殖生长时期。包括开花受精和子粒发育,是决定粒数和粒重的关键时期中耕培土的概念及作用 培土就是把行间的土壤培在玉米根部形成土垄。作用:能增加表土受光面积及防止倒伏 玉米去雄的好处与方法是什么? 去雄就是拔除玉米的雄穗。去雄可以节省养分,使雌穗早吐丝,受精结实好;降低株高,改善中上部叶片光照条件;将部分玉米螟带出田外,减少螟害。是一种简便易行的增产措施。 去雄应在雄穗刚抽出而未散粉时进行。最好选在晴天10:00至15:00时去雄,以利伤口愈合,避免病菌感染。阴雨连绵或高温干旱时,不宜去雄,以免花粉减少,影响授粉。一般采用隔行或隔株进行,地头地边的雄穗应保留,全天去雄不应超过1/2。 小麦前期。中期。后期的生育特点、主攻目标、管理技术 小麦青干逼熟的原因 小麦在灌浆期间,遇到高温、赶海、伴随的强风,出现“干热风”现象。使小麦植株体内水分供应失调,影响子粒中养分积累的一种异常现象 防止小麦倒伏的方法 ①选用抗到品种②打好播种基础③控制合理群体④科学用肥⑤控旺转壮 什么是少耕和免耕?具体做法是什么? 少耕是指在常规耕作基础上尽量减少土壤耕作次数或全田间隔耕种、减少耕作面积的一类耕作方法 免耕是指农作物播种前不用犁、耙整理土地,直接在茬地上播种,播后及农作物生育期间也不使用农具进行土壤管理的耕作方法, 做法:①用生物措施代替土壤耕作②用化学措施及其他新技术代替土壤耕作③采用先进的机具代替土壤耕作 什么是轮作?什么是连作?轮作的作用是什么?连作的危害是什么? 轮作是在同一田地上有顺序的轮换种植不同种类农作物的种植方式 连作是在同一田地上连年种植相同种类的农作物的种植方式 轮作的作用:①减轻农作物病虫害②充分利用土壤养分③减轻田间杂草危害④改善土壤理化性状 连作的危害:①土壤养分结构失调,有害物质增加②土壤物理结构破坏③生物结构破坏 单作是在同一块田地上种植一种农作物的种植方式 间作是在同一田地上于同一生长期内,分行或分带相间种植两种或两种以上农作物的种植方式 套作是在前季农作物生长后期株行间播种或移栽后季农作物的种植方式 作用:①增产②增效③稳产保收④协调农作物争地的矛盾

生物化学试卷及答案

生物化学试卷(A)及答案 1、蛋白质的变性作用:天然蛋白质因受物理、化学因素的影响,使蛋白质分子的构象发生了异常变化,从而导致生物活性的丧失以及物理、化学性质的异常变化。但一级结构未遭破坏,这种现象称为蛋白质的变性作用。 2、结构域:对于较大的蛋白质分子或亚基,多肽链往往由两个或两个以上相对独立的三维实体缔合而成三级结构,这种相对独立的三维实体称结构域。 3、氧化磷酸化:伴随电子从底物到氧的传递,ADP被磷酸化形成ATP的酶促过程即是氧化磷酸化作用。 4、酶的活性中心:是指结合底物和将底物转化为产物的区域,通常是相隔很远的氨基酸残基形成的三维实体。 5、冈崎片段:由于亲代DNA双链在复制时是逐步解开的,因此,随从链的合成也是一段一段的。DNA在复制时,由随从链所形成的一些子代DNA短链称为冈崎片段。 6、Km值:是当酶促反应速度达到最大反应速度一半时的底物浓度,它的单位是mol/L,与底物浓度的单位一样。 7、糖异生作用:由非糖物质前体合成葡萄糖的作用称为糖异生作用。 8、密码子的摆动性:密码子的专一性主要取决于前两位碱基,第三位碱基重要性较低,可以有一定程度的摆动,称为摆动性或变偶性。 9、转录的不对称性:在DNA分子双链上只有某一区段或者一股链用作模板指引转录,另一股链不转录,这称为转录的不对称性 10、操纵子:是指在转录水平上控制基因表达的协调单位。它包括启动子(P)、操纵基因(O)以及在功能上彼此相关的几个结构基因(S)。 二、填空题:(将正确答案填在括号内,每题1分,共25分) 1、在20种氨基酸中,酸性氨基酸有谷氨酸和天冬氨酸2种,具有羟基的氨基酸是丝氨酸和苏氨酸,能形成二硫键的氨基酸是半胱氨酸。 2、酶的活性中心包括催化部位(基团),结合部位(基团)两部分。 3、在脂肪酸氧化过程中,脂肪酸活化产生的脂肪酰CoA由脂酰肉碱带通过线粒体内膜。 4、多肽链中氨基酸之间通过肽键相连,核酸分子中核苷酸之间通过3’,5’-

电气测试技术第三版_课后习题答案(林德杰)

l第一章思考题与习题 1-2 图1.6为温度控制系统,试画出系统的框图,简述其工作原理;指出被控过程、被控参数和控制参数。 解:乙炔发生器中电石与冷水相遇产生乙炔气体 并释放出热量。当电石加入时,部温度上升,温度 检测器检测温度变化与给定值比较,偏差信号送到控 制器对偏差信号进行运算,将控制作用于调节阀,调 节冷水的流量,使乙炔发生器中的温度到达给定值。 系统框图如下: 被控过程:乙炔发生器 被控参数:乙炔发生器温度 控制参数:冷水流量 1-3 常用过程控制系统可分为哪几类? 答:过程控制系统主要分为三类: 1. 反馈控制系统:反馈控制系统是根据被控参数与给定值的偏差进行控制的,最终达到或消除或减小偏差的目的,偏差值是控制的依据。它是最常用、最基本的过程控制系统。 2.前馈控制系统:前馈控制系统是根据扰动量的大小进行控制的,扰动是控制的依据。由于没有被控量的反馈,所以是一种开环控制系统。由于是开环系统,无法检查控制效果,故不能单独应用。 3. 前馈-反馈控制系统:前馈控制的主要优点是能够迅速及时的克服主要扰动对被控量的影响,而前馈—反馈控制利用反馈控制克服其他扰动,能够是被控量迅速而准确地稳定在给定值上,提高控制系统的控制质量。 3-4 过程控制系统过渡过程的质量指标包括哪些容?它们的定义是什么?哪些是静态指标?哪些是动态质量指标? 答:1. 余差(静态偏差)e:余差是指系统过渡过程结束以后,被控参数新的稳定值y(∞)

与给定值c 之差。它是一个静态指标,对定值控制系统。希望余差越小越好。 2. 衰减比n:衰减比是衡量过渡过程稳定性的一个动态质量指标,它等于振荡过程的第 一个波的振幅与第二个波的振幅之比,即: n <1系统是不稳定的,是发散振荡;n=1,系统也是不稳定的,是等幅振荡;n >1,系统是稳定的,若n=4,系统为4:1的衰减振荡,是比较理想的。 衡量系统稳定性也可以用衰减率φ 4.最大偏差A :对定值系统,最大偏差是指被控参数第一个波峰值与给定值C 之差,它衡量被控参数偏离给定值的程度。 5. 过程过渡时间ts :过渡过程时间定义为从扰动开始到被控参数进入新的稳态值的±5%或±3% (根据系统要求)围所需要的时间。它是反映系统过渡过程快慢的质量指标, t s 越小,过渡过程进行得越快。 6.峰值时间tp : 从扰动开始到过渡过程曲线到达第一个峰值所需要的时间,(根据系统要求)围所需要的时间。称为峰值时间tp 。它反映了系统响应的灵敏程度。 静态指标是余差,动态时间为衰减比(衰减率)、最大偏差、过程过渡时间、峰值时间。 第二章 思考题与习题 2-1 如图所示液位过程的输入量为Q1,流出量为Q2,Q3,液位h 为被控参数,C 为容量系数,并设R1、R2、R3均为线性液阻,要求: (1) 列出过程的微分方程组; (2) 求过程的传递函数W 0(S )=H (S )/Q 1(S ); (3) 画出过程的方框图。 解:(1)根据动态物料平衡关系,流入量=流出量: B B n ' = B B B '-= ?dt dh )Q Q (Q 321=+-h d ?

材料科学基础期末考试

期末总复习 一、名词解释 空间点阵:表示晶体中原子规则排列的抽象质点。 配位数:直接与中心原子连接的配体的原子数目或基团数目。 对称:物体经过一系列操作后,空间性质复原;这种操作称为对称操作。 超结构:长程有序固溶体的通称 固溶体:一种元素进入到另一种元素的晶格结构形成的结晶,其结构一般保持和母相一致。 致密度:晶体结构中原子的体积与晶胞体积的比值。 正吸附:材料表面原子处于结合键不饱和状态,以吸附介质中原子或晶体内部溶质原子达到平衡状态,当溶质原子或杂质原子在表面浓度大于在其在晶体内部的浓度时称为正吸附; 晶界能:晶界上原子从晶格中正常结点位置脱离出来,引起晶界附近区域内晶格发生畸变,与晶内相比,界面的单位面积自由能升高,升高部分的能量为晶界能; 小角度晶界:多晶体材料中,每个晶粒之间的位向不同,晶粒与晶粒之间存在界面,若相邻晶粒之间的位向差在10°~2°之间,称为小角度晶界; 晶界偏聚:溶质原子或杂质原子在晶界或相界上的富集,也称内吸附,有因为尺寸因素造成的平衡偏聚和空位造成的非平衡偏聚。 肖脱基空位:脱位原子进入其他空位或者迁移至晶界或表面而形成的空位。 弗兰克耳空位:晶体中原子进入空隙形而形成的一对由空位和间隙原子组成的缺陷。 刃型位错:柏氏矢量与位错线垂直的位错。 螺型位错:柏氏矢量与位错线平行的位错。 柏氏矢量:用来表征晶体中位错区中原子的畸变程度和畸变方向的物理量。 单位位错:柏氏矢量等于单位点阵矢量的位错 派—纳力:位错滑动时需要克服的周围原子的阻力。 过冷:凝固过程开始结晶温度低于理论结晶温度的现象。 过冷度:实际结晶温度和理论结晶温度之间的差值。 均匀形核:在过冷的液态金属中,依靠金属本身的能量起伏获得成核驱动力的形核过程。 过冷度:实际结晶温度和理论结晶温度之间的差值。 形核功:形成临界晶核时,由外界提供的用于补偿表面自由能和体积自由能差值的能量。 马氏体转变:是一种无扩散型相变,通过切变方式由一种晶体结构转变另一种结构,转变过程中,表面有浮凸,新旧相之间保持严格的位向关系。或者:由奥氏体向马氏体转变的

农作物栽培技术手册

目录 玉米生产技术规程 一、种子和种子处理 (4) 二、选茬、耕整地 (4) 三、施肥 (5) 四、播种 (5) 五、田间管理 (5) 六、收获 (5) 玉米机械化行间覆膜生产技术技术规程 一、选地整地........................................... ........................................... (6) 二、品种选择........................................... . (6) 三、地膜选用........................................... (6) 四、播期:........................................... ............................................. . (6) 五、施肥........................................... ............................................ ..... (6) 六、化学除草........................................... (6) 七、田间管理.......................................................................... .. (6) 水稻生产技术规程 一、寒地水稻农时标准 (7) 二、寒地水稻生产用种标准 (8) 三、寒地水稻旱育壮苗标准 (8) (一)旱育壮苗量化标准............................................................................ (8) (二)水稻旱育壮苗外部形态五项标准 (8) 四、寒地水稻培育旱育种壮苗技术标准 (9) (一)寒地旱育水稻育秧田标准 (9) (二)寒地水稻种子处理技术 (9) (三)寒地水稻置床处理技术标准 (11) (四)寒地水稻播种技术标准 (12) (五)寒地水稻秧田管理技术标准 (12)

生物化学试卷及答案

生物化学试卷 一、单项选择题 1.测得某一蛋白质样品的氮含量为0.80g,此样品约含蛋白质多少?答()A.4.00g B.5.00g C.6.40g D.6.00g 2.维持蛋白质二级结构的主要化学键是:答()A.盐键B.疏水键C.肽键D.氢键 3.具有四级结构的蛋白质特征是:答()A.分子中必定含有辅基B.每条多肽链都具有独立的生物学活性 C.依赖肽键维系四级结构的稳定性D.由两条或两条以上具在三级结构的多肽链组成 4.Km值的概念是:答()A.与酶对底物的亲和力无关B.是达到Vm所必须的底物浓度 C.同一种酶的各种同工酶的Km值相同D.是达到1/2Vm的底物浓度 5.酶原所以没有活性是因为:答()A.酶蛋白肽链合成不完全B.活性中心未形成或未暴露 C.酶原是普通的蛋白质D.缺乏辅酶或辅基 6.有机磷杀虫剂对胆碱酯酶的抑制作用属于:答()A.可逆性抑制作用B.竞争性抑制作用 C.非竞争性抑制作用D.不可逆性抑制作用 7.肌糖原分解不能直接补充血糖的原因是:答()A.肌肉组织是贮存葡萄糖的器官B.肌肉组织缺乏葡萄糖激酶 C.肌肉组织缺乏葡萄糖-6-磷酸酶D.肌肉组织缺乏磷酸酶 8.下列哪个激素可使血糖浓度下降?答()A.肾上腺素B.胰高血糖素C.生长素D.糖皮质激素E.胰岛素 9.体内转运一碳单位的载体是:答()A.叶酸 B.维生素B12 C.硫胺素D.生物素E.四氢叶酸 10.肝细胞胞液中的NADH进入线粒体的机制是:答()A.肉碱穿梭B.柠檬酸-丙酮酸循环C.α-磷酸甘油穿梭D.苹果酸穿梭 11.氨中毒的根本原因是:答()A.肠道吸收氨过量B.氨基酸在体内分解代谢增强C.肾功能衰竭排出障碍D.肝功能损伤,不能合成尿素E.合成谷氨酸酰胺减少

1078电气设备检测技术

[1078]《电气设备检测技术》 1、国标GB 7252-2010规定300kV及以上变压器、电抗器油中乙炔溶解气体含量的注意值为(B)ppm。 1. A. 0.5 2. B. 1 3. C. 2 4. D. 5 2、国标GB 7252-2010规定200kV及以下变压器、电抗器油中乙炔溶解气体含量的注意值为(D)ppm。 1. A. 0.5 2. B. 1 3. C. 2 4. D. 5 3、根据GB/T17623-1998和IEC60599-1999,20℃时,CO在矿物绝缘油中的奥斯特瓦尔德系数为(C)。 1. A. 0.09 2. B. 0.17 3. C. 0.12 4. D. 0.05 4、根据6kV-XLPE电缆的交流击穿电压与在线监测得到的正切间的关系可知,当 正切占大于(B)时,绝缘可判为不良。 1. A. 0.5% 2. B. 1.0% 3. C. 2.0%

4. D. 5.0% 5、下列干扰信号中不属于脉冲型干扰信号的是(A) 1. A. 高频保护信号、高次偕波 2. B. 雷电、开关、继电器的断合 3. C. 高压输电线的电晕放电 4. D. 相邻电气设备的内部放电 6、频率为20kHz以下的振动信号选用(A)监测。 1. A. 加速度传感器 2. B. 超声传感器 3. C. 声发射传感器 4. D. 速度传感器 7、电机绝缘内部放电放电电压最低的是(D)。 1. A. 绝缘层中间 2. B. 绝缘与线棒导体间 3. C. 绝缘与防晕层间的气隙或气泡里 4. D. 绕组线棒导体的棱角部位 8、根据GB/T17623-1998和IEC60599-1999,20℃时,H2在矿物绝缘油中的奥斯特瓦尔德系数为(D)。 1. A. 0.09 2. B. 0.17 3. C. 0.12 4. D. 0.05

材料科学基础试题库

一、单项选择题(请在每小题的4个备选答案中,选出一个最佳答案, 共10小题;每小题2分,共20分) 1、材料按照使用性能,可分为结构材料和 。 A. 高分子材料; B. 功能材料; C. 金属材料; D. 复合材料。 2、在下列结合键中,不属于一次键的是: A. 离子键; B. 金属键; C. 氢键; D. 共价键。 3、材料的许多性能均与结合键有关,如大多数金属均具有较高的密度是由于: A. 金属元素具有较高的相对原子质量; B. 金属键具有方向性; C. 金属键没有方向性; D.A 和C 。 3、下述晶面指数中,不属于同一晶面族的是: A. (110); B. (101); C. (011- );D. (100)。 4、 面心立方晶体中,一个晶胞中的原子数目为: A. 2; B. 4; C. 6; D. 14。 5、 体心立方结构晶体的配位数是: A. 8; B.12; C. 4; D. 16。 6、面心立方结构晶体的原子密排面是: A. {111}; B. {110}; C. (100); D. [111]。 7、立方晶体中(110)和(211)面同属于 晶带 A. [110]; B. [100]; C. [211]; D. [--111]。 6、体心立方结构中原子的最密排晶向族是: A. <100>; B. [111]; C. <111>; D. (111)。 6、如果某一晶体中若干晶面属于某一晶带,则: A. 这些晶面必定是同族晶面; B. 这些晶面必定相互平行; C. 这些晶面上原子排列相同; D. 这些晶面之间的交线相互平行。 7、金属的典型晶体结构有面心立方、体心立方和密排六方三种,它们的晶胞中原子数分别为:A. 4, 2, 6; B. 6, 2, 4; C. 4, 4, 6; D. 2, 4, 6 7、在晶体中形成空位的同时又产生间隙原子,这样的缺陷称为: A. 肖脱基缺陷; B. 弗兰克缺陷; C. 线缺陷; D. 面缺陷 7、两平行螺旋位错,当柏氏矢量同向时,其相互作用力:

园林地被植物栽植技术

园林地被植物栽植技术 一、地被植物种植(改造)前的准备 (一)场地清理与平整 1、深度在20公分以内的不利于植物生长的有害物质、杂物、砖块必须清除。 2、种植床内杂草(原有地被植物)必须清除。 3、场地初步平整,挖除突起部分,填平低洼地方,确保种植床密实度均匀。 (二)地形处理 地被种植床应排水良好,一般做成3%。的排水坡度。如果临近建筑,应从地基向外倾斜,直到边缘。 (三)施基肥 种植地被前,要求在地表均匀撒施复合肥,每平方撒 15克,撒施后与10-15公分土层均匀混合。 (四)深翻土壤、种植床细平整 消毒、施肥后进行种植床细整。土粒不超过2公分,边整边衬,不留坑洼,整理成符合排水要求的种植床。 二、地被植物种植 1 、种植株行距为10 x 10公分行列种植,种植深度略深于根系,分株后的小株放于种植坑,用土回填踩实。 2、种植完逐一踩实,让根系与土壤结合密实,扶正苗

木 。 三、清理施工现场 种植完毕,清理现场,杂物分类堆放整齐

园林绿化技能大赛评分办法 为进一步调动我市园林绿化技术工人学技术和提高技 能的积极性,根据园林绿化技能大赛要求,特制定园林绿化技术大赛评分办法。 一、理论部分 1、满分100分。 2、内容为《园林绿化》中的“序言”和“绿化工”部分。 3、题型:填空题(20分)、选择题(20)、判断题(20 分)、简答题(20分)、论述题(20分)。 二、实际操作部分 (一)园林植物品种及植物病虫害识别(满分100分) 1、植物识别(满分50分): (1)对常见的25种植物在规定的时间内进行识别,限时10分钟完成。 (2)每答对一种得2分。 (3)分组进行。 2、植物病虫害辨认(满分50分): (1)对常见的25种植物病虫害在规定时间内进行识别, 限时10分钟完成。 (2)每答对一种得2分 (3)分组进行。

生物化学试题及答案.

生物化学试题及答案(6) 第六章生物氧化 【测试题】 一、名词解释 1.生物氧化 2. 呼吸链 3.氧化磷酸化 4. P/O 比值 5.解偶联剂 6.高能化合物 7.细胞色素 8.混合功能氧化酶 二、填空题 9.琥珀酸呼吸链的组成成分有 ___ 、 __ 、___ 、 _ 、____ 。 10.在NADH氧化呼吸链中,氧化磷酸化偶联部位分别是、、___ ,此三处释放的能量均超过 __ KJ 11.胞液中的NADH+H通+过______ 和_________________________________ 两种穿梭机制进入线粒体,并可进入_________________ 氧化呼吸链或______________________________ 氧化呼 吸链,可分别产生 __ 分子ATP 或分子ATP。 12.ATP 生成的主要方式有___ 和。 13.体内可消除过氧化氢的酶有 __ 、 ___ 和。 14.胞液中α- 磷酸甘油脱氢酶的辅酶是___ ,线粒体中α- 磷酸甘油脱氢酶的辅基是___ 。 15.铁硫簇主要有__ 和____ 两种组成形式,通过其中的铁原子与铁硫蛋白中的____ 相连接。 16.呼吸链中未参与形成复合体的两种游离成分是____ 和__ 。 17.FMN 或FAD 作为递氢体,其发挥功能的结构是 __ 。 18.参与呼吸链构成的细胞色素有、 ____ 、____ 、___ 、____ 、___ 。 19.呼吸链中含有铜原子的细胞色素是 __ 。 20.构成呼吸链的四种复合体中,具有质子泵作用的是___ 、___ 、___ 。 21.ATP 合酶由_ 和____ 两部分组成,具有质子通道功能的是____ ,__ 具有催化生成ATP 的作用。 22.呼吸链抑制剂中, __ 、_____ 、 _ 可与复合体Ⅰ结合, ____ 、___ 可抑制复合体Ⅲ,可抑制细胞色素c 氧化酶的物质有 __ 、___ 、___ 。 23.因辅基不同,存在于胞液中SOD 为__ ,存在于线粒体中的SOD 为___ ,两者均可消除体内产生的 24.微粒体中的氧化酶类主要有 __ 和 三、选择题

《材料科学基础》试题大全

《材料科学基础》试题库 一、名词解释 1、铁素体、奥氏体、珠光体、马氏体、贝氏体、莱氏体 2、共晶转变、共析转变、包晶转变、包析转变 3、晶面族、晶向族 4、有限固溶体、无限固溶体 5、晶胞 6、二次渗碳体 7、回复、再结晶、二次再结晶 8、晶体结构、空间点阵 9、相、组织 10、伪共晶、离异共晶 11、临界变形度 12、淬透性、淬硬性 13、固溶体 14、均匀形核、非均匀形核 15、成分过冷 16、间隙固溶体 17、临界晶核 18、枝晶偏析 19、钢的退火,正火,淬火,回火 20、反应扩散 21、临界分切应力 22、调幅分解 23、二次硬化 24、上坡扩散 25、负温度梯度 26、正常价化合物 27、加聚反应 28、缩聚反应 29、 30、 二、选择

1、在柯肯达尔效应中,标记漂移主要原因是扩散偶中_____。 A、两组元的原子尺寸不同 B、仅一组元的扩散 C、两组元的扩散速率不同 2、在二元系合金相图中,计算两相相对量的杠杆法则只能用于_____。 A、单相区中 B、两相区中 C、三相平衡水平线上 3、铸铁与碳钢的区别在于有无_____。 A、莱氏体 B、珠光体 C、铁素体 4、原子扩散的驱动力是_____。 A、组元的浓度梯度 B、组元的化学势梯度 C、温度梯度 5、在置换型固溶体中,原子扩散的方式一般为_____。 A、原子互换机制 B、间隙机制 C、空位机制 6、在晶体中形成空位的同时又产生间隙原子,这样的缺陷称为_____。 A、肖脱基缺陷 B、弗兰克尔缺陷 C、线缺陷 7、理想密排六方结构金属的c/a为_____。 A、1.6 B、2×√(2/3) C、√(2/3) 8、在三元系相图中,三相区的等温截面都是一个连接的三角形,其顶点触及_____。 A、单相区 B、两相区 C、三相区 9、有效分配系数Ke表示液相的混合程度,其值范围是_____。(其中Ko是平衡分配系数) A、1

相关文档