Abstract

Deploying Non-Functional Aspects by Contract

Romulo Cerqueira, Sidney Ansaloni, Orlando Loques

IC/UFF

Niterói, RJ, Brazil

{curty, ansaloni, loques}@ic.uff.br

Alexandre Sztajnberg

DICC/IME/UERJ Rio de Janeiro, RJ, Brazil alexszt@ime.uerj.br

Abstract

This paper presents an approach to describe, deploy and manage component-based applications having dynamic functional and non-functional requirements, which include different types of QoS. The approach is centered on an ADL that allows functional and non-functional requirements to be described by high-level textual contracts. The meta information extracted from the software architecture description is used to guide configuration adaptations required to enforce the ruling contract. The infrastructure required to automatically manage these contracts follows a standard architectural pattern, which can be directly mapped to specific components included in a supporting middleware. This allows designers to write a contract and to follow a standard recipe to insert the extra code required to its enforcement in the supporting middleware. Also, the component configuration capability provided by the middleware helps to put in practice adaptations defined by a contract. Examples demonstrate how the approach and the associated middleware can be used to configure and to support applications with adaptive QoS requirements.

1. Introduction

We present an approach to describe, deploy and manage applications with service guaranties based on the contract concept. This approach defines the relationship between contracts, differentiated quality of services (QoS), and the resource management entities. In our proposal, differentiated quality of services is described by a special language associated to an Architectural Description Language. These descriptions are reflected in the R-RIO framework in two ways: (a) the mechanisms required to automatically manage these contracts follow a standard architectural pattern, which can be directly mapped to specific components included in the supporting middleware; (b) R-RIO connectors can encapsulate a set of different non-functional aspects, and these connectors can be reconfigured at run-time to provide adaptation capabilities.

In the next section we present R-RIO basic concepts. In the sequence we discuss how R-RIO handles the configuration of non-functional aspects in the architectural level using contracts. Then, we illustrate the use of the R-RIO framework with a comprehensive dynamically-adaptable application example. Finally, we present some related works and our concluding remarks.

2. R-RIO Framework

The Reflective-Reconfigurable Interconnectable Objects (R-RIO) framework integrates some key concepts of Software Architecture / Configuration Programming (SA/CP) and Meta-Level Programming (M-LP) approaches [1]. This integration helps to achieve separation of concerns, software reuse and the capability of supporting dynamic configuration. R-RIO framework includes the following elements:

a) A component model based on the concepts of SA/CP: (i) modules, application components that basically encapsulate functional concerns; (ii) connectors, used at the architecture level to define module’s interaction relationships. At the operating level, connectors represent, mediate and handle module interaction-domain concerns; (iii) ports, identify access points, through which modules and connectors provide or require services, and are also used to explicitly bind modules and connectors.

b) A software development methodology that stimulates the designer to comply with a simple meta-level programming discipline, where functional concerns are concentrated in the modules (base level) and non-functional concerns are encapsulated in connectors (meta-level).

c) CBabel, an ADL used to describe: (i) application's functional components and interaction topology, (ii) contracts specifying non-functional aspects, and (iii) planned reconfigurations. An architecture described with CBabel can be verified and compiled, resulting in a meta-level architecture description repository used to run and manage the architecture.

d) The Configurator, a reflective middleware [2] that provides distributed configuration management and executive services, used to make and control running images from an architecture description.

3. Non-functional aspects

In various application domains we have identified recurring non-functional aspects that should be considered since the design-time: (a) Interaction, to configure the characteristics of module interaction; (b) Distribution, to configure module location, distribution and communication; (c) Coordination, to handle module concurrency and synchronization; and (d) QoS, quality of service, regarding operational requirements, such as fault tolerance, security or communication parameters.

To specify non-functional aspects we use the architectural contract concept. In our approach, an architectural contract is a description where two parts express their requirements regarding the application's aspects, and rules for adaptation and negotiation in the presence of context changes.

In our proposal, a functional service is considered a specialized activity, constrained by restrictions that usually do not permit negotiation, defined through the specification of the application's architectural components and their interconnection topology. Non-functional services are defined by restrictions to application non-specific activities that can admit some negotiation on resource utilization. A non-functional contract can describe the use of shared resources an application is going to make and acceptable variations on the availability of those resources at design-time. A contract will be enforced at operation-time by a set of infrastructure components that implement the contract semantics.

In the next section we use QoS domain examples to illustrate our approach to treat non-functional aspects.

4. Examples

We borrowed a subset of the QML QoS language [3] and adapted its syntax and terminology to the software architecture description scope [1]. QoS categories associated to different non-functional aspects are described separately from the components. For instance, if transport performance is critical to an application, a Transport QoS category could be described, as shown in figure 1.

1 QoScategory Transport {

2 protocol: enum {UDP, TCP, RTP} ;

3 technology: enum {802.11LAN, CDLS, GSM};

4 slidingWindowSize: increasing numeric ;

5 send_buf-size: increasing numeric ;

6 recv_buf_size: increasing numeric ;

7 MSS: increasing numeric ;

8 }

Figure 1. Transport QoS category

In a Virtual Terminal application a possible QoS category, defining some of the emulation and security required properties, could be described as in figure 2.

1 QoS category Terminal {

2 port: enum {ssh , telnet};

3 cipherType: enum {idea, arcfour};

4 auth: enum {RSA, password, both};

5 connectionAttempts: increasing numeric;

6 X11forward: enum {yes, no};

7 }

Figure 2. Terminal QoS category

Figure 3, describes an architecture, that uses a virtual terminal facility, composed by a client and a server module (vtServer – lines 2-4, vtClient – lines 5-7), and its intended topology (lines 8-9).

1 module VirtualTerminal {

2 module {

3 in port (char) Recv;

4 } vtServer;

5 module {

6 out port (char) Send;

7 } vtClient;

8 instantiate vtClient at clientNode;

9 link vtClient to vtServer;

10 } vt;

11 start vt;

Figure 3. Virtual terminal functional composition

4.1 Contract with static adaptation

Considering the session establishment aspect, the designer has to select operating parameters related to communication and security. In our example, the first option is to connect to the server using SSH over TCP, and idea cryptography with password authentication. If this is not possible (eg. the server cannot work with this configuration), a TELNET connection over TCP can be accepted. However, in this case, more authentication options and a receive buffer size of at least 64 bytes are prescribed.

The CBabel associated contract (figure 4) describing these non-functional requirements specifies two services: one for the secure case (lines 2-5) and the other for the unsecured one (lines 6-9). Each of these intended services is fully defined by an associated profile that describes the set of required properties, each one associated with a given QoS category; i.e., the profile describes what should be provided by the supporting infrastructure. In the example, the secTerm profile (lines 15-20) describes the first operational choice and the unsecTerm profile (lines 21-26) the second option. Note that both of them require the TCP protocol. The preferred order for the use of the services is defined in the negotiation clause (lines 11-14). If none of them can be imposed after negotiation the client

is unable to open the session. In order to enforce the contract the middleware selects one or more connectors to support the best available service and accordingly configures the architecture. The middleware could configure either a secure or unsecure connector. After the session is established no other adaptation will occur.

1 contract {

2 service {

3 link vtClient.Send to vtServer.Recv

4 with profile secTerm;

5 } secure;

6 service {

7 link vtClient.Send to vtServer.Recv

8 with profile unsecTerm;

9 } unsecure;

10 negotiation {

11 secure -> unsecure;

12 unsecure -> out_of_service;

13 }

14 } vt;

15 profile {

16 Transport.protocol: TCP;

17 Terminal.port: ssh;

18 Terminal.cipherType: idea;

19 Terminal.auth: password;

20 } secTerm;

21 profile {

22 Transport.protocol: TCP;

23 Transport.recv_buf_size: > 64;

24 Terminal.port: telnet;

25 Terminal.auth: both;

26 } unsecTerm;

Figure 4. Virtual terminal QoS contract

4.2 Contract with dynamic adaptation

In a different use-case scenario, a sales-person has to visit potential consumers and be permanently connected to the main office database through a virtual terminal. She uses a mobile device that can run a virtual terminal client and provides communication with three possible operating modes:

? in the range of a cordless station base, it can operate over a regular wired telephone line;

? on the move, it can detect a cellular antenna and reconfigure to use a cellular connection;

? when immerse in a wireless network, it can use the available communication protocols.

For each operating mode there is an appropriate communication interface and a sensor that detects if the associated channel is available or not. While in operation the supporting middleware tries to establish a link using the best available channel. Figure 5 presents the application’s overall architecture. The dashed lines represent the links that can be dynamically established, guided by the negotiation policy and depending on resource availability.

Figure 5. Mobile device basic architecture The contract for this use-case (figure 6) defines three different services, each one associated to a different operating mode supported by the device. The support for each service is encapsulated in a connector. The negotiation clause (lines 14-18) defines that the best service is the wireless transport service. If this service is not available, a fixTel service should be tried and so on. Transitions between services depend on their availability. Either when the currently used link fails, or a preferable service becomes available, a service adaptation can take place. Other adaptation policies could be used, e.g., based on a reduced-cost or bandwidth criterion.

1 contract {

2 service {

3 link vtClient.Send to vtServer.Recv

4 with Transport.technology: 802.11LAN;

5 } wireless;

6 service {

7 link vtClient.Send to vtServer.Recv

8 with Transport.technology: CDLS;

9 } fixTel;

10 service {

11 link vtClient.Send to vtServer.Recv

12 with Transport.technology: GSM;

13 } celTel;

14 negotiation {

15 wireless -> fixTel;

16 fixTel -> celTel;

17 celTel -> out_of_service;

18 };

19 } vt;

Figure 6. Mobile device QoS contract

4.3 Composing Contracts

Contracts regarding different non-functional aspects (in the same or in different applications) can be orthogonal and cause no interference with each other. In this case, composing those contracts is immediate. In the general case, the composition process can lead to conflicts on the use of shared resources. In our proposal, the composition of contracts can be specified combining in a unique clause the negotiation clauses of the involved contracts. Conflicts could be handled assigning priorities to each of the composed contracts.

Regarding our example combining the two contracts is trivial. Services and profiles would be part

of the same contract and the unified negotiation clause would be described as in figure 7. We can note that both contracts are orthogonal, given that it is not necessary to combine states of the two sets of services in the same negotiation chain.

1 negotiation {

2 secure -> unsecure;

3 unsecure -> out_of_service;

4 wireless -> fixTel;

5 fixTel -> celTel;

6 celTel -> out_of_service;

7 }

Figure 7. Combining contracts

4.4 Support

CBabel described architectures, functional composition and non-functional contracts, are stored as meta-level information (figure 8). With this information a set of middleware components, arranged in a well-defined architectural pattern [4], will interact with the Configurator (section 2) to instantiate and bind application components, and enforce the contracts: Contract Manager interprets contract descriptions to extract the service negotiation state machine. When a negotiation is initiated, the Contract Manager identifies which service will be negotiated and sends the related configuration descriptions and the associated profiles to the Interactor. If every service inside a negotiation clause has been unsuccessfully tried, an out-of-service state is reached, and a contract violation message is returned to the user. As seen in the example, the contract manager can also start a negotiation when a preferable service becomes available.

The Interactor has some responsibilities: (a) translate service profiles properties into system-level support services and request those services with adequate parameters to the QoS Agent in order to instantiate / start modules with required QoS, (b) map the service link interaction information into a connector able to provide the required interaction QoS, (c) call the Configurator to actually perform architectural procedures (instantiate, link, start) on modules and connectors with the configured resource context, and (d) receive out-of-range notifications from the QoS Agent. When this occurs, based on its internal programming the Interactor can try to readapt the resource allocation, at resource-level (for instance changing resource parameters, if possible), or send an out-of-service notification the Contract Manager to initiate another architecture-level negotiation action. QoS Agents encapsulate the access to system level mechanisms. Their main responsibilities are to make the actual resource allocations, initiate local system services and to monitor required property values. According to the monitoring thresholds registered by the Interactor, the Agent can send back an out-of-range property notification.

Regarding our examples, the QoS Agent is responsible for verifying the availability of the virtual terminal properties (telnet or ssh ports, authentication, etc.) before establishing a terminal session. The QoS Agent also encapsulates the sensors functions, monitoring the transport channel operation. The Interactor is programmed to instantiate a combination of connectors with suitable parameters and to ask the QoS Agent to start some resource reservation procedures to maintain transport and security options for each service. Also, it registers with the QoS Agent the interest for new channel-available events. When a negotiation occurs (say, change from wireless to fixTel) the Contract Manager sends another service request to the Interactor that, by its turn, selects a connector encapsulating the required transport technology mechanism, and invokes the Configurator to dynamically change the architecture’s composition.

Figure 8. QoS supporting component infrastructure

5. Related work

QML [3], which was the main inspiration of our contract description language, is applied in the class-object context, and is not directly applicable to the implementation level. Quartz [5] provides an API to describe QoS requirements, through a set of parameters that are used to select components of the supporting middleware. The approach seems to be restricted to multimedia QoS requirements and relies on services particular to CORBA infrastructures. Our approach has similarities with the proposals presented in [6] and [7], which are in fact interrelated. Most of the elements of the pattern language describe in [6] have a counterpart in our proposal. For example, their Quality Connector performs functions similar to those provided by our Interactor and QoS Agent combined. [7] proposes a contract pattern that could be used to provide part of the support for dynamic adaptations required in our middleware. Our proposal provides an integrated framework to deploy QoS and other non-functional aspects, starting to handle these concerns from the architectural description. In addition, using our configuration programming environment, and the embedded architectural meta-level information, we can handle adaptations through component (re) configurations in a natural fashion.

6. Conclusion

We presented a unified approach to specify, deploy and manage applications having non-functional requirements. The approach allows non-functional aspects of an application, such as QoS requirements, to be specified using high-level contracts expressed in an extended ADL. Being centered on an ADL-based configuration middleware the framework inherits all its well-known benefits, among them the capability of reconfiguration, which helps to execute dynamic architectural adaptations in behalf of a contract.

Part of the codification related to a non-functional aspect can be encapsulated in connectors, that can be (re)configured at run-time in order to cater for the impositions defined by the associated contract. Also, the infrastructure required to enforce the contracts follows an architectural pattern that can be implemented by a standard set of components of the middleware. In this pattern, each component performs a well-defined role in the support of the contract. We have evaluated the approach through several case studies that showed that the code of these supporting components may change partly according to the specific contract. However, we should notice that the treatment of low-level details always has to be considered in any QoS aware application. We believe that our approach can help to identify the intervening points and make the required adaptations more rapidly.

We have used the described approach to specify a reasonable number of contracts, defined at the architecture description level. These contracts have been mapped to implementations using the pattern described in this paper. Through this activity, we have identified some recurrent structures inside the components of the pattern. We think that on making these structures explicit, and available to designers, the task of mapping architecture-level defined contracts to implementations can be simplified. Acknowledgments

Romulo Cerqueira is supported by Petrobras. Orlando Loques and Alexandre Sztajnberg are partially funded by CNPq (grants PDPG-TI 552137/2002 and 552192/2002, respectively).

7. References

[1] Loques, O., Sztajnberg, A., Leite, J. and Lobosco,

M., "On the Integration of Meta-Level Programming and Configuration Programming", Reflection and Software Engineering, LNCS V.

1826, pp.191-210, June, 2000.

[2] Sztajnberg, A. and Loques, O., "Reflection in the

R-RIO Environment", Workshop on Reflective Middleware, Palisades, NY, April, 2000.

[3] Frolund, S. and Koistinen, J., "Quality-of-service

specifications in distributed object systems", Distributed Systems Engineering, IEE, No. 5, pp.

179-202, UK, 1998.

[4] Carvalho, S. T, Lisb?a, J. and Loques, O, “A

Software Architecture Configuration Design Pattern”, 2nd Latin American Conference on Pattern Languages of Programming, Itaipava, RJ, Brazil, August, 2002.

[5] Siqueira F. Cahill, V., "Quartz: A QoS Architecture

for Open Systems", 18o Simpósio Brasileiro de Redes de Computadores, pp. 553-568, Belo Horizonte, MG, Brazil, May, 2000.

[6] Cross, J. K and Schmidt, D. ,"Quality Connector –

A Pattern Language for Provisioning and

Managing Quality-Constrained Services in Distributed Real-Time and Embedded Systems", 9th Conf. on Pattern Language of Programs, Monticello, Illinois, September, 2002.

[7] Zinky, J. A., Bakken, D. E., Schantz, R. E.,

"Architectural Support for Quality of Service for CORBA Objects", Theory and Practice of Object Systems, John Wiley & Sons, Inc., Vol.

3, No. 1, 1997.

如何写英文Abstract

How to Write an Abstract 一、什么是摘要Abstract? an abstract comprises one paragraph which describes the main content of a paper and appears at the very beginning of the paper. 摘要是叙述文章主要内容的一个段落，并且位于文章的开头部分。 摘要是以梗概形式呈现的一篇文章要点的总结，它强调了一篇文章所包含的重要的信息。它也可以帮助读者快速的了解到是否这篇文章是他们感兴趣的，是否他们需要来阅读整篇文章。而且，国家或国际出版社的编辑通常通过浏览投稿文章的摘要来决定是否投稿人的文章是可以被录用的。因此，对于学者和研究人员来说，写一份好的摘要至关重要。 二、写作Abstract的目的 对于科技论文的摘要，Abstract的目的有以下几点： 1.Introduce journal articles. https://www.wendangku.net/doc/f1261734.html,rm readers about article`s content. 3.Help readers decide whether or not to read article. 4.Overview conference programs,abstract collections,and book chapters. 三、学习写作Abstract的必要性 1.Helps you present complex information in a clear,concise manner. 2.Helps you read abstracts more effectively. 3.Helps you conduct research. 4.Helps you write abstracts for future publications. 5.Helps you condense report information into a short format for database searches. 四、Abstract的写作要求 https://www.wendangku.net/doc/f1261734.html,e one or more well-developed paragraphs,which are unified,coherent,concise,and able to stand alone（200-300 words). https://www.wendangku.net/doc/f1261734.html,e an introduction-body conclusion structure in which the parts of the parts of the report are discussed in order:purpose,researcquestions,method,findings,conclusions,recommendations.

abstract 的语步分析

Research article abstract 1.Introducing purpose This move gives a precise indication of the author’s intention, thesis or hypothesis which forms the basis of the research being reported. It may also include the goals or objectives of research or the problem that the author wishes to tackle. 2.Describing methodology In this move the author gives a good indication of the experimental design, including information on the data, procedures or method(s) used and, if necessary, the scope of the research being reported. 3.Summarizing results This is an important aspect of abstracts where the author mentions his observations and findings and also suggests solutions to the problem, if any, posed in the first move. 4.Presenting conclusions This move is meant to interpret results and draw inferences. It typically includes some indication of the implications and applications of the present findings.

UPPAAL建模工具教程

Uppaal4.0:Small Tutorial? 16November2009 1Introduction This document is intended to be used by newcomers to Uppaal and veri?cation.Students or engineers with little background in formal methods should be able to use Uppaal for practical purposes after this tutorial. Section2describes Uppaal and Section3is the tutorial itself. 2Uppaal Uppaal is a tool box for validation(via graphical simulation)and veri?cation(via automatic model-checking)of real-time systems.It consists of two main parts:a graphical user interface and a model-checker engine.The user interface is implemented in Java and is executed on the users work station.Version4.0of Uppaal requires that the Java Runtime Environment5or higher is installed on the computer.The engine part is by default executed on the same computer as the user interface,but can also run on a more powerful server. The idea is to model a system using timed automata,simulate it and then verify properties on it.Timed automata are?nite state machines with time(clocks).A system consists of a network of processes that are composed of locations.Transitions between these locations de?ne how the system behaves.The simulation step consists of running the system interactively to check that it works as intended.Then we can ask the veri?er to check reachability properties,i.e.,if a certain state is reachable or not.This is called model-checking and it is basically an exhaustive search that covers all possible dynamic behaviours of the system. More precisely,the engine uses on-the-?y veri?cation combined with a symbolic technique re-ducing the veri?cation problem to that of solving simple constraint systems[YPD94,LPY95].The veri?er checks for simple invariants and reachability properties for e?ciency reasons.Other prop-erties may be checked by using testing automata[JLS96]or the decorated system with debugging information[LPY97]. 3Learning Uppaal Uppaal is based on timed automata,that is?nite state machine with clocks.The clocks are the way to handle time in Uppaal.Time is continuous and the clocks measure time progress.It is allowed to test the value of a clock or to reset it.Time will progress globally at the same pace for the whole system. A system in Uppaal is composed of concurrent processes,each of them modeled as an automa-ton.The automaton has a set of locations.Transitions are used to change location.To control when to take a transition(to“?re”it),it is possible to have a guard and a synchronization.A guard is a condition on the variables and the clocks saying when the transition is enabled.The synchronization mechanism in Uppaal is a hand-shaking synchronization:two processes take a ?This description covers version4.0.7

Java中的abstract方法和abstract类的问题

Java中的abstract方法和abstract类的问题 当知道一个类的子类将不同的实现某个方法时，把该类声明为抽象类很有用，可以共用相同的父类方法，不必再定义。 抽象类和抽象方法的关系:含有抽象方法的类一定是抽象类，抽象类里不一定含有抽象方法。抽象类存在的意义是用来被继承的。一个类继承了一个抽象类，必须实现抽象类里面所有的抽象方法，否则，此类也是抽象类。 abstract修饰符用来修饰类和成员方法 1：用abstract修饰的类表示抽象类，抽象类位于继承树的抽象层，抽象类不能被实例化。2：用abstract修饰的方法表示抽象方法,抽象方法没有方法体。抽象方法用来描述系统具有什么功能，但不提供具体的实现。 abstract 规则： 1：抽象类可以没有抽象方法，但是有抽象方法的类必须定义为抽象类，如果一个子类继承一个抽象类，子类没有实现父类的所有抽象方法，那么子类也要定义为抽象类，否则的话编译会出错的。 2：抽象类没有构造方法，也没有抽象静态方法。但是可以有非抽象的构造方法 3：抽象类不能被实例化，但是可以创建一个引用变量，类型是一个抽象类，并让它引用非抽象类的子类的一个实例 4：不能用final 修饰符修饰 Q:java里面有抽象类么？和接口的区别是什么？ A:java中有抽象类,用关键字abstract修饰。 以下是我对这个问题的看法。 首先，从语法上讲，抽象类是一个类，根据java的单继承体系。如果它有子类，那么它的

子类只能继承它。 java允许实现多个接口。所以一个类可以实现多个接口 抽象类里面可以定义各种类型和访问权限的变量(就像普通类一样)，也可以定义各种访问权限的方法(就像普通类一样)。 但是接口不可以。在接口里面定义的方法默认就是public abstract的，变量默认就是public static final的。(不管你有没有加权限控制符，不加，默认就是这些权限；加错了，权限缩小了，那么就会报错) 其次，从意义上讲，如果继承一个抽象类，那么抽象类和它的子类就有父子关系，即有类的层次关系(这关系到类的设计问题)。 接口，在我看来，是一种契约或者协议，是一层提供给另一层的接口(可以想象成OSI各层之间的关系) 在某一层中有多个类协作实现这个层的功能，通过接口暴露出去。但这些类之间会有层次关系(is a,has a) Q:一个方法加abstract和不加abstract有什么区别？就是说不加有什么关系？加了又会怎样？ A:一方法要是加abstract，那么这个方法就是抽象的，须由子类去实现 抽象方法必须在抽象类当中，也就是说，一个类只要有一个方法是抽象的，那么这个类就必须是抽象类 抽象类里面的方法不一定要抽象的，也可以全都不是抽象的 抽象类不能实例化！ 所以可以想到，当你不想让你的类被别人实例化，只想这个类的子类可以实例化，那么只要将这个类声明为abstract的就可以了

学术论文写作的要点范文

一、研究生必备四本 俗话说好记性不如烂笔头，所以一定要首先养成做笔记的好习惯！作为研究生下面这几个本子是必不可少的。 1，实验记录本（包括试验准备本），这当然首当其冲必不可少，我就不多说了； 2，Idea记录本，每次看文献对自己有用的东西先记下，由此产生的idea更不能放过，这可是做研究的本钱，好记性不如烂笔头，以后翻翻会更有想法的； 3，专业概念以及理论进展记录本，每个人不可能对自己领域的概念都了如指掌，初入门者更是如此，这时候小小一个本子的作用就大了； 4，讲座记录本，这本本子可能有些零杂，记录听到的内容，更要记录瞬间的灵感，以及不懂的地方，不可小视！ 这四本是你必不可少的，不过作为我们这些非英语专业的研究生来说，还有一个应该具备的本子就是英语好句记录本。 二、论文写作要点 1、选题要小，开掘要深；不要题目很大，内容却很单薄。 2、写作前要读好书、翻阅大量资料、注意学术积累，在这个过程中，还要注重利用网络，特别是一些专业数据库 3、“选题新、方法新、资料新”的三新原则（老板教导的） 4、“新题新做”和“小题大做 总之，一点之见即成文。 三、如何撰写实验研究论文（唐朝枢） 论文发表意识：基础研究成果的表达方式；是否急于发表（创新与严谨的关系）；发表的论文与学位论文的区别（反映科学事实而不是反映作者水平） 论文格式：原著 original research paper, full length paper、review综述论文，快报、简报、摘要。不同于教科书、讲义，更不同于工作总结。 撰写前的准备工作：复习和准备好相关文献;再次审定实验目的(学术思想,Idea);实验资料完整并再次审核 1.Introduction:引言 问题的提出；研究的现状及背景；以前工作基础；本工作的目的；思路（可提假说）；对象；方法；结果。在…模型上，观察…指标，以探讨…（目的）

abstract结构分析

1.Urology is perceived as a competitivespecialty choice. Declining undergraduate exposure and thepreference for ‘‘lifestyle specialties’’ may jeopardize urology’s popularity. Our objective was to assess trends inapplication and matching rates to urology compared withother surgical specialties. 2. We reviewed data collected by CanadianResidency Matching Service (CaRMS) and the CanadianPost-MD Education Registry since expansion in Canadianmedical school enrollment began (2002-2011). The following were examined: applicant preference, number ofpositions, gender patterns, and match results. ‘‘Surgery’’included general surgery, orthopedics, plastics, ENT, and urology. 3.From 2002 to 2011 CaRMS applicantsincreased from 1117 to 2528 (126%). The number ofapplicants selecting surgery first increased from 178 to338(90%). The number of surgery positions increased from138 to 275 (100%). Urology positions increased from 15to 31 (113%). Applicants to urology increased only 40%(30-42). The proportion of all CARMs applicants selectingurology as their first choice decreased from 2.7% (30) to1.7% (42). The ratio of first choice urology applicants topositions decreased from 2 to 1.35. The probability ofmatching urology as first choice increased from 50% to76%. Female medical graduates increased from 51% to58%. The female applicants selecting surgery first increasedfrom 21% (49) to 41% (173). In contrast, females selectingurology first rose from 13% (4) to 17% (7). 4.Urology in Canada is becoming lesscompetitive. Residency positions have doubled since 2002whereas the number of applicants remains static. This trendwas not reflected in other surgical specialities. Factorsaccounting for this may include poor undergraduateexposure, demand for specialties with controllable lifestyles,gender shifts in undergraduate medicine, and lack of rolemodels. The need for undergraduate exposure to urologyand vetting numbers of residency positions remains a matterof paramount importance. ( JSurg 70:537-543. JC2013Association of Program Directors in Surgery. Published byElsevier Inc. All rights reserved.) BACKGROUND1: METHODS2: RESULTS3: CONCLUSION4:

期刊论文的分析技巧与程序总结

（1）Abstract： 说明这篇论文的主要贡献、方法特色与主要内容。只看Abstract 和Introduction便可以判 断出这篇论文的重点和你的研究有没有直接关连，从而决定要不要把它给读完。 （2）Introduction： Introduction 的功能是介绍问题的背景和起源，交代前人在这个题目上已经有过的主要贡献，说清楚前人留下来的未解问题，以及在这个背景下这篇论文的想解决的问题和它的重要性。对初学的学生而言，从这里可以了解以前研究的概况。通常我会建议初学的学生，对你的题目不熟时，先把跟你题目可能相关的论文收集个30～40篇，每篇都只读Abstract 和Introduction，而不要读Main Body（本文），只在必要时稍微参考一下后面的Illustrative examples和Conclusions，直到你能回答下面这三个问题： （2A）在这领域内最常被引述的方法有哪些？ （2B）这些方法可以分成哪些主要派别？ （2C）每个派别的主要特色（含优点和缺点）是什么？ 问题是，你怎么去找到这最初的30～40篇论文？有一种期刊论文叫做「review paper」，专门在一个题目下面整理出所有相关的论文，并且做简单的回顾。你可以在搜寻Compendex时在keywords 中加一个「review」而筛选出这类论文。然后从相关的数篇review paper 开始，从中根据title 与Abstract 找出你认为跟你研究题目较相关的30～40篇论文。 通常只要你反复读过该领域内30～40篇论文的Abstract 和Introduction，你就应该可以从Introduction的评论中回答（2A）和（2B）这两个问题。尤其要记得，当你阅读的目的是要回答（2A）和（2B）这两个问题时，你一定要先挑那些Introduction写得比较有观念的论文念（很多论文的Introduction 写得像流水帐，没有观念，这种论文刚开始时不要去读它）。假如你读过假如30～40篇论文的Abstract

语言学中的研究方法

第34卷第6期 唐山师范学院学报 2012年11月 Vol.34 No.6 Journal of Tangshan Teachers College Nov. 2012 ────────── 收稿日期：2012-03-25 作者简介：申丽红（1975-），女，河北邯郸人，博士研究生，讲师，研究方向为理论语言学及语言教学。 -24- 语言学中的研究方法 申丽红1,2 （1. 中国传媒大学 文学院，北京 100021；2. 河北联合大学 外国语学院，河北 唐山 063000） 摘 要：语言学作为社会科学和自然科学的交叉学科，近年来有了长足的发展。各家学者秉承不同的语言学理论，采用不同的研究方法对语言进行了多方位的研究。本文从语言学理论的不同发展阶段对语言学研究方法做一梳理。 关键词：语言学；定量研究；定性研究 中图分类号： H 0-05 文献标识码： A 文章编号：1009-9115(2012)06-0024-03 Some Research Methods of Linguistics SHEN Li-hong 1,2 (1. College of Liberal Arts, The Communication University of China, Beijing 100021, China; 2. College of Foreign Languages, Hebei United University, Tangshan 063000, China) Abstract: Linguistics, as a cross-discipline between natural and social science, has developed well in recent years. Different scholars did some researches on language with different theories and from different angles. A summary about the research methods of linguistics is made. Key Words: linguistics; quantitative research; qualitative research 语言是人类特有的宝贵财产，是人类社会生活的重要组成部分。随着社会发展，文明进步，人们开始从不同角度探索语言的奥秘，以揭示形形色色的言语背后所隐藏的规律，从而形成了林林总总的语言学流派和语言学理论。 任何一门学科的研究方法对于一门学科的发展都是至关重要的。在语言学发展的不同阶段，不同的语言学流派以不同的哲学基础建立起自己的理论框架后，因其学科发展的不同时期以及不同的研究目的而选用不同的研究方法来进行语言学相关研究。 一、语言学发展简史 西方的语言学研究自古希腊始，希腊著名的哲学家苏格拉底（Socrates, BC 470-BC 399），柏拉图（ Plato, BC 429-BC 347）和亚里士多德（Aristotle, BC 384- BC322）等通过对语言的辩论奠定了语言研究的哲学基础。此后语言学在西方历经中世纪、文艺复兴以及19世纪历史比较语言学的发展，随着一些人类学家、哲学家等相继加入语言学研究，语言学学科迅速发展。他们详细研究了语言的分类， 语言中的音变等，为现代语言学的诞生奠定了坚实的基础。 20世纪初，瑞士语言学家索绪尔提出的普通语言学理论使语言学真正成为了一门科学的学科。此后的布拉格学派、哥本哈根学派以及美国的结构主义学派基本上秉承了结构主义的衣钵，对语言的结构、音位等进行了详细的描写和切分。 20世纪50年代，乔姆斯基（Noam Chomsky ）提出了转换生成语法（Transformational-Generative Grammar ）。转换生成语法彻底颠覆了传统的结构主义语法，推动语言学研究进入当代语言学时期。乔姆斯基认为人类获得语言的过程无论采用“白板说”还是“刺激-反应”论都不足以说明问题，以此提出了“先天性假设”（innateness hypothesis ）。他认为人类的大脑先天被内置了一套“普遍语法”（universal grammar ）或“语言普遍现象”（linguistic universals ）。这种普遍语法在后天经验的触发下而形成各种各样的“个别语法”（particular grammar ）。语言学家的任务就是运用数学的运算原理，运用各种规则逐步推导以

Abstract Writing (论文摘要写作精简版)

Writing: Abstract WHAT IS AN ABSTRACT 1. The Definition of an Abstract 1 ) the objectives and scope of investigation; 2) the methods used; 3) the most important results; 4) conclusion or recommendation. 2. Features of Abstracts Brevity Accuracy Specificity Objectivity Informativeness Independency CLASSIFICATION OF ABSTRACTS 1.Indicative Abstracts https://www.wendangku.net/doc/f1261734.html,rmative Abstracts https://www.wendangku.net/doc/f1261734.html,rmative-indicative Abstracts 4.Other Types of Abstracts 1) Critical Abstracts 2) Mini-abstracts FUNCTIONS OF ABSTRACTS A Screening Device of Documents: An abstract gives readers the idea of what the article is about. A Self-contained Text: We’ll know the information it contains, without seeing the article . A Helpful Preview: It "frames" the article and prepares the reader for the main points to come. To Facilitate Indexing: It will improve the chances of having it read by the right people. STYLISTIC FEATURES OF ABSTRACTS 1. The Length of Abstracts 1) In general, there is a 100-300 word limit to the number of words in an abstract. 2) Do not confuse an abstract with a review. There should be no comment or evaluation. 3) Give information only once. 4) Do not repeat the information given in the title. 5) Do not include any facts or ideas that are not in the text. 6) For informative abstracts, include enough data to support the conclusions. 7) If reference to procedure is essential, try to restrict it to identification of method or process. 8) State results, conclusions, or findings in clear concise fashion. 9) Organize the information in the way that is most useful to the reader. (a thesis-first abstract) 2. Verbs and Tenses Used in Abstracts 1) Active verbs: use active verbs rather than passive verbs. 2) Present tense: background information, existing facts, what is in the paper and conclusion. 3) Past tense /present perfect tense: completed research, methodology or major activities results. 3. Words Used in Abstracts 1) Avoid use of highly specialized words or abbreviations. Define unfamiliar words. 2) Synthesize or rephrase the information into clear, concise statements. 3) Avoid using jargon. 4. Sentence Structures of Abstracts 1) Use third person sentences. 2) Use short sentences, but vary sentence structure. 3) Use complete sentences. 4) The first sentence should present the subject and scope of the report. The thesis or the writer's focus should be presented in the second sentence. The balance of the article is a summary of the important points of each section, including methods, procedures, results and conclusions. 5) Good abstracts are sure to include a variety of pat phrases: a. Background Information (Research has shown... It has been proposed... Another proposed property... The search is on for... One of the promising new...) b. Statement of the Problem (The objective of the research is to prove / verify... The experiment was designed to determine...) e. Statement of Procedure (To investigate this .... A group of 10 specimens / subjects ... Measurements

TOPSIS方法研究讲解

TOPSIS分析方法研究 摘要 本文主要介绍了TOPSIS分析方法理论及其主要思想，运用数学理论，对其算法进行了详细的分析，并指出原始方法存在的优缺点；在此基础上提出了一种改进的TOPSIS分析方法，给出具体求权重的方法，突出其客观公正性.本文还分析了TOPSIS方法逆序产生的原因及其改进的方法，突出其实用性，推广其应用范围. 关键词TOPSIS法; 改进的TOPSIS; 权重；逆序

TOPSIS ANALYSIS METHOD ABSTRACT This paper describes a method of theory—TOPSIS, and its main idea. Using mathematical theory, its algorithm for a detailed analysis and noted the advantages and disadvantages of the original methods. On this base ,an improved TOPSIS method is given, and specific for weight, in order to highlight its objective impartiality. The paper also analyzes the causes of TOPSIS Reverse and its improved methods, highlight its practicality and the promotion of its use. Keywords TOPSIS method; Improved TOPSIS; weight; Reverse

论文写作abstract

How to Write an Abstract for a Research Paper WANG Yan School of International Studies UIBE Issues to address: 1What is an abstract? 2Functions of an abstract 3Structure of an abstract 4Principles of abstract writing 1. What is an abstract? ?An abstract is a condensed version of a longer piece of writing that highlights the major points covered, concisely describes the purpose and scope of the writing, and reviews the writing's contents in abbreviated form. ?It is a concise and clear summary of a complete research paper. ?It tells the reader What you set out to do, and Why you did it,How you did it, What you found (recommendations).

2. Functions of an abstract ?An abstract is used to communicate specific information from the article.?It is aimed at introducing the subject to readers, who may then read the article to find out the author's results, conclusions, or recommendations. 2. Functions of an abstract ?The practice of using key words in an abstract is vital because of today's electronic information retrieval systems. ?Titles and abstracts are filed electronically, and key words are put in electronic storage. ?When people search for information, they enter key words related to the subject, and the computer prints out the titles of all the articles containing those key words. ?An abstract must contain key words about what is essential in an article so that someone else can retrieve information from it. 3. Structure of an abstract ?The components of an abstract ①Background Information ②Subject Matter/Problem Statement ③Purpose ④Method (and Data) ⑤Results / Findings ⑥Conclusion / Implications

抽象函数的解题方法与技巧窍门

抽象函数的解题方法与技巧 摘要：抽象函数是没有具体的解析式，只给出它的一些特征、性质或一些特殊关系式的函数。因而显得特别抽象。所以解决抽象函数问题需要从函数的本质出发，考虑其定义，性质，加之解决抽象函数问题时常用的技巧——赋值法，换元法等。尽可能使抽象函数变得不再抽象。 关键词：抽象函数；性质；求值；解析式；解题方法；技巧 Problem-solving methods and skills of abstract functions Xue Jie School of Mathematics and Statistics, Southwest University, Chongqing 400715, China Abstract:: abstract function is not analytic type specific, given only the function characteristics, its nature or some special relationship. So it is especially abstract. So to solve the abstract function problems need from the view of function essence, considering its definition, nature, and solve the abstract function problems commonly used techniques -- assignment method, substitution method etc.. As far as possible to make the abstract function is no longer abstract. Keywords: abstract function; property; evaluation; analytic method; problem solving skills; 1.提出问题的背景 抽象函数问题是函数中的一类综合性较强的问题，这类问题通过对函数性质结构的