科学文献

In Elizabeth Burd and Arie van Deursen,editors,Proc.9th Working Conference on Reverse Engineering.IEEE,Los Alamitos,2002

A Study on the Current State of the Art in Tool-Supported UML-Based Static

Reverse Engineering

Ralf Kollmann,Petri Selonen,Eleni Stroulia,Tarja Syst¨a,Albert Z¨u ndorf

(kollmann@tzi.de,pselonen@cs.tut.?,stroulia@cs.ualberta.ca,

tsysta@cs.tut.?,zuendorf@upb.de)

University of Bremen,Department of Computer Science,Germany

Tampere University of Technology,Software Systems Laboratory,Finland

University of Alberta,Computing Science Center,Canada

Technical University of Braunschweig,Institute for Software,Germany

Abstract

Today,software-engineering research and industry alike recognize the need for practical tools to support reverse-engineering activities.Most of the well-known CASE-tools nowadays support reverse engineering in some way.But al-though the Uni?ed Modeling Language(UML)has emerged as the de facto standard for the abstract graphical represen-tation of object-oriented software systems,there does not yet exist a standard scheme for representing the reverse en-gineered models of software systems.Due to the differences in understanding and application of the UML notation and the proprietary extensions that different tools adopt,it is often dif?cult to ensure that model semantics remains un-ambiguous when working with different tools at the same time.

In this paper,we examine the capabilities of the two most successful industrial-strength CASE-tools in reverse engi-neering the static structure of software systems and com-pare them to the results produced by two academic proto-types.The comparisons are carried out both manually and automatically using a research prototype for manipulating and comparing UML models.

Keywords:UML,static reverse engineering,empirical study,tool evaluation

1Introduction

Reverse engineering techniques have been subject to re-search for many years and have become quite well-known by the time.Lots of subordinate and related?elds of re-search have developed,and especially their relations to soft-ware modeling has been recognized and elaborated,result-ing in comparably new developments as round-trip engi-neering.In line with the recognition of a need for tool support in software modeling and development,it has be-come more and more common for modern CASE-tools to also support reverse engineering to a certain degree.

In most cases,the reverse engineering facilities provided by CASE-tools supporting the Uni?ed Modeling Language (UML)[9]are limited to class diagram extraction.In the case of Java software systems,package hierarchies are usu-ally shown as well.However,for understanding the under-lying architectural decisions,a class diagram provides only limited help.Abstracting class diagrams into component diagrams and recognition of design patterns,for instance, are very desirable for real UML-based reverse engineering support.

While a class diagram shows the static information at the lowest level possible in UML,it nonetheless represents an abstraction of the actual object-oriented subject system itself.As a modeling language,UML does not tell how the model is to be implemented.More speci?cally,there is no one-to-one mapping between class diagram elements and the source code.For instance,composition and ag-gregation relationships can be implemented similarly even though they are conceptually different.Associations in gen-eral are dif?cult to be detected,especially for dynamically typed languages.Also,other language dependent dif?cul-ties occur:usage of abstract classes and interfaces in purely object-oriented languages(such as Java and Smalltalk)dif-fers from their usage in hybrid languages(e.g.,C++).Even the interpretation of generalization at the design level differs from inheritance at the source code level:in model inheri-tance,it is used for subtyping,while in the source code it is used,e.g.,for subclassing.

Because of the differences in concepts at the design and

implementation levels,interpretations are necessary for the extraction of class diagrams from the source code.Cur-rently,no standard way to do that exists.Moreover,the tools do not allow the user to in?uence the interpretations. Instead,the interpretations are typically built in the algo-rithms.

These built-in interpretations are tool-dependent and can be harmful by leading to inconsistencies,misunderstand-ings,and limitations.However,the interpretations them-selves seem to be less harmful than hiding the rationale behind them from the end user.If the CASE-tool sup-ports round-trip engineering,the same interpretations can and should be used consistently both in reverse engineer-ing and in code generation.The danger of misunderstand-ings becomes less crucial the better the user understands the interpretations and the limitations of the tool.While tools supporting code generation often allow the user to in?uence coding conventions,it is surprising that similar customiz-ability is rarely supported when reverse engineering class diagrams from the source code,especially since construct-ing abstractions requires understanding and is thus known to be a process that should be carried out(semi-)manually.

In this paper,we aim at examination of the current sit-uation by performing a case study and by comparing the results of the different tools.The examination also serves the CASE-tools users in understanding the built-in interpre-tations and limitations of the tools.We chose two popular commercial CASE-tools and two research prototypes espe-cially targeted on UML-based reverse and round-trip engi-neering.The examined commercial CASE-tools are To-gether[17]and Rational Rose[13],and the research pro-totypes are IDEA[4,6]and FUJABA[18].The reverse engineering support of these tools was compared by using them for analyzing the subject Java software system Math-aino[3,16].A suite of model properties capturing impor-tant design decisions has been identi?ed and and used as a measure for comparing the results of each tool.

In addition,the class diagrams extracted by Together, Rose,and IDEA have been stored in UML1.3/XMI1.1for-mat[12]and imported to a modeling tool TED[19],where automatic model comparison is carried out using a research prototype for manipulating and comparing UML models.

2Examined Tools

Together Together supports reverse engineering of soft-ware systems developed in C++,Java,C#,VB,etc.When reverse engineering a Java program,Together constructs a tree view similar to the one produced by Rose but it also produces the UML class diagram at the same time(assum-ing that the user has chosen this type of diagram to start with).Together is able to reverse engineer the information from the source code(.java?les),byte code(.class?les),jar?les,or packed zip?les,but the models it extracts are not exactly the same across these types of input.The Java reverse engineer can be given instructions on the?les,di-rectories(packages),and libraries(for instance,Java foun-dation classes)to be examined.Furthermore,Together can provide,upon demand,a large array of metrics on the code examined(e.g.LOC,Halstead,complexity)and audits on the coding style used.

Rose Rational Rose supports reverse engineering of,e.g., C++and Java software systems.When reverse engineer-ing a Java program,Rose constructs a tree view that con-tains classes,interfaces,and association found at the high-est level.Methods,variables etc.are nested under the owner classes.Rose also constructs(on demand)a class diagram representation of the extracted information and generates a default layout for it.Additionally,Rose automatically con-structs a package hierarchy as a tree view.Rose is able to reverse engineer the information from the source code (.java?les),byte code(.class?les),jar?les,or packed zip ?les.Quite similar to Together,the Java reverse engineer-ing module can be given instructions on?les,directories, packages,and libraries to be examined.

Idea The reverse engineering tool IDEA has been devel-oped at University of Bremen,Germany,within the UML-AID(Abstract Implementation and Design with the Uni-?ed Modeling Language)project.The central subject of IDEA is the redocumentation of Java programs using the UML.Although reverse engineering of program behaviour has been addressed,too[5],the focus is on the static analy-sis of object-oriented structures using UML class diagrams. They are generally considered the most-employed and best-understood diagrams included in the UML.

To hold the program information in a data structure, a metamodel for the Java language has been developed, whose instances represent complete programs.A transla-tion framework is employed to create UML models from the Java models,providing a standardized translation scheme. In several successive steps,transformations are applied to the model with the goal of creating an abstract design level representation of the examined program.These are the same features that have been applied for the study presented in this paper and include for example recognition of con-tainer classes,multiplicities and inverse associations[4].

Recent research addresses the extension of IDEA’s func-tionality by several metric-based analyses[6].These allow to visualize metrics graphically in the context of their under-lying architecture,what makes it possible to understand the composition of metric values.The primary subject of this approach,however,is an algorithm for metric-based parti-tioning of large diagrams that allows selective visualization of semantically coherent diagram regions.

Fujaba Fujaba is a UML based CASE-tool that has been developed since1998at University of Paderborn.It sup-ports code generation from class diagrams as well as activ-ity diagrams,statecharts and collaboration diagrams.This allows to use UML as a kind of visual programming lan-guage for the development of full?edged applications with-out any manual coding.Fujaba aims to provide round-trip engineering support:if some developer or other tools (e.g.a version control system)modify the generated code and if these modi?cations stick to certain coding standards, then the Fujaba environment is able to analyze the changed code and to(re)create the corresponding UML speci?ca-tion.Again,this covers the static structure,i.e.the class diagrams,as well as the dynamic structure,i.e.the method bodies.To some extent,this round-trip engineering func-tionality may also be used for reverse engineering foreign code.This holds especially for class diagrams.

3A Case Study

3.1Examined Model Properties

Number of Classes(NOC)This is a general measure for the overall size of a software module.NOC values can be counted in various ways,depending on handling of special cases like container classes,inner classes and representation of interfaces.Therefore,high NOC values may indicate a more detailed representation.

Number of Associations(NOA)This metric measures the amount of interconnectedness in a module.However, more care has to be taken when interpreting NOA values than concerning NOC.Low NOA values may hint on an im-precise reverse engineering algorithm,but can also be the result of abstraction steps,for example recognition of in-verse associations.As in the latter case,low values are con-sidered better,NOA should be measured both before and after doing abstractions.

Types of Associations The UML supports different kinds of associations like directed,bidirectional,aggregation and composition.Additionally,the meaning of an association may be modi?ed by applying adornments(e.g.tags or qual-i?ers)to its ends.In this section,we examine,which UML adornments and association kinds have been encountered, and under which conditions they have been employed in re-verse engineering.This allows conclusions about the mean-ing that has been imposed on a feature by a particular tool. Handling of Interfaces An interface is a speci?er for the externally-visible operations of a class,component,or other classi?er(including subsystems)without speci?ca-tion of internal structure[10].In UML diagrams,inter-

faces are drawn as classi?er rectangles(with a stereotype Interface)or as circles.The interfaces are attached by a dashed generalization arrow to classi?ers that support it.

This indicates that the class provides(implements)all of the operations of the interface.The circle notation is used when the operations of the interface are hidden.

A class that uses or requires the operations supplied by the interface may be attached to the circle by a dashed ar-row pointing to the circle.From the reverse engineering point of view,generation of such dependencies is important for understanding the usage of interfaces and for conclud-ing component structures and dependencies(e.g.,to abstract class diagrams to a component diagram).Furthermore,dif-ferent ways of handling interfaces have impact on the NOC metric and possibly on the readability of the respective class diagram.

Handling of Java Collection classes Java collection classes are an implementation-speci?c means to handle col-lections(e.g.sets,list or maps)of objects.In design,such features do not appear,but are rather modeled by using asso-ciation adornments like multiplicity or quali?ers.We exam-ine,whether the reverse engineering algorithms in charge recognize Java collections and their contained types,or han-dle them like ordinary classes.Container resolution is im-portant not only in design recovery,but also in metric-based analysis[6].

Multiplicities In the UML,to-many associations between objects are described by means of multiplicities.Precise in-formation about multiplicities is dif?cult to derive and re-quires ideally dynamic analysis techniques,which are not supported currently by the tools observed here.We exam-ine,if and to what extent multiplicities are recognized by means of the available static analysis methods.

Role Names The function of role names at association ends is comparable to that of attribute names in the sense of giving to an association between classes a meaningful descriptor,which depends on the end its attached to.There-fore in reverse engineering,role names can hold relevant additional information about the system infrastructure.We examine,whether role names are used and if,what kind of information they represent.

Inner classes Java inner classes,too,are an implementation-speci?c feature that hides a class def-inition within the speci?cation of another class.Thus, recognizing inner classes is important to re?ect the entire system structure.

Together

84

39

3+42

Interfaces4

38+45

N/A

N/A

variable names

Neither tool generated any aggregation nor composition relationships.

Handling of Java Collection Classes Rose and Together handle container classes similarly.The container types of attributes used in the Mathaino core package(namely,Vec-tors)were not represented differently from any other at-tribute types;they are written(as strings)in the variable compartment of the class.That is,if a class has a variable, say v,the type of which is Vector,the variable compartment contains a string v:java.util.Vector.

4.2Idea

When reverse engineering the Mathaino core package with IDEA,several transformation steps have been applied to the basic implementation level UML model to recognize the examined model properties.Descriptions of these steps are included in the following sections about the analysis re-sults.

After doing the transformations,the pre-de?ned metrics suite has been calculated.Since some characteristics of the UML model change during the transformation steps,the metrics have been calculated anew after each step.

Metric Calculations For calculation of the NOC metric, both the number of classes from the mathaino core package as well as the total number of classes related to it(e.g.by UML associations)have been counted.Inner classes have been taken into account in addition to plain classes,if they were de?ned uniquely with a separate name.Classes from external packages were considered,if a relationship(or ref-erence from method bodies)to the Mathaino core package existed.

In total,42classes have been discovered.This number is composed of39plain classes and three named(unique) inner classes(in total,45inner classes have been found,but anonymous inner classes were not considered here).Ad-ditionally,35external classes have been found,resulting in a total of77classes(not counting the anonymous inner classes).

The initial number of associations was56.As ex-pected,this number was reduced after each transformation step.During container resolution,two associations were discarded,because the respective contained classes were of type String,which is handled like a primitive type and not shown as an individual class(cf.section4.2;NOA af-ter container resolution was54).Finally,seven association pairs have been merged to bidirectional associations,result-ing in a?nal NOA of47.

Handling of Interfaces For interfaces,the default UML metamodel representation as subclasses of Classi?er is used.This means that they appear in the resulting class diagrams as separate interface rectangles.The number of interfaces is independent from the number of classes and no subset of the latter.Four interfaces have been found in the core package and another six external interfaces have been in use,summing up to a total of10.

Role Names Role names are derived from the identi?ers of non-primitive attributes and are shown at the target asso-ciation end of directed associations.In the special case of an association depicting the relationship of an inner class to its de?ning class,the keyword’this’is used at role name at the association end of the de?ning class.When merging di-rected associations,both role names are taken,resulting in an undirected association with role names at both ends. Handling of Java Collection Classes At implementation level,containers are shown as individual classes.To reveal the true relationships between a source object and the ob-jects stored in a container,a resolution process is employed that analyses the source code for accesses to the interface of container objects[4].

While examining the Mathaino core package,16con-tainer type attributes have been found,all of which were Vectors.15of these could be resolved.Two could not be represented graphically because the type of the contained objects was String,which is not represented in the diagram as an individual class but handled as a primitive attribute. These were rendered using the textual UML attribute nota-tion with a multiplicity attached.Finally,one container at-tribute could not be resolved at all,because the source code of its containing class did not contain any invocations of the container attribute’s store operation.Since IDEA examines the source code for invocations of the collection classes’in-terface to determine the contained type,this one was not resolvable.Because of the single remaining association,the container class Vector was kept in the diagram.

For the graphical representation of the resolved contain-ers,the UML quali?er notation has been employed[4], which shows a quali?ed attribute(the vector index)at the association source end and a0..1multiplicity at the target end,denoting that the number of contained elements is?-nite.Experience with this UML notation has shown that it is not always suitable in large diagrams.The problem is that the notation consists of two parts(one at each associ-ation end),but that it is not always possible to view both ends at the same time.Having only the multiplicity end without the quali?er tends to be confusing,since only the source end,but not the target end shows gives a hint on the quali?er of the association.We have circumvented this UML-speci?c problem by extending the quali?er notation by a tagged value quali?ed at the target association end.

Merging Inverse Associations We discovered seven pairs of potentially inverse associations[4].All of them were unique,that is,no ambiguities with other associations were encountered during the merging process.Therefore, we decided to merge all of them.Three different kinds of inverses have been found:

Between independent classes.In this case,prede?ned pairs of role names or known relations from the design can be taken as hints for merging.When these are not available,it is only possible to analyze the role names and rule out ambiguities.

Between class and contained class(i.e.a class whose objects are stored in a container attribute of the source class).These are considered related because of the to-many association between source and targets.

Between class and inner class.These were considered inherently associated because of the tight relation be-tween inner class and de?ning class(cf.section4.2).

To recognize the second group of inverses,the sequence of model abstraction steps is crucial,as they can only be discovered after resolution of container classes.

Aggregation and Composition According to the UML speci?cation documents[11][10],aggregation is an infor-mal feature that is not characterizable in a precise way,as would be required to recognize it from the source code. Different than composition,aggregation has a rather im-precise de?nition,which describes a whole-part relation-ship between source and target classes.The best way to recover this relation from existing programs is suf?cient knowledge of the software architecture.Since we did not have a person locally available knowing the system in de-tail,we decided to use aggregation only in one rather clear case,namely where a role name(at the association be-tween classes MathainoDesktopHandler and Mathaino-MainFrame)contained the keyword“owner”and thus sug-gested an aggregation relationship.

In the UML,composition de?nes constraints about the instances of classes,not about classes themselves.There-fore,correct recognition of composition requires dynamic analysis techniques,which are not yet supported by IDEA. However,this is subject to future work.

Multiplicities The following multiplicity values and ranges are discovered by the IDEA tool:

’0..1’The target element is initialized somewhere in the source code(at an unknown position).It cannot be determined statically,whether an initialization will actually happen at runtime.

’1’The target element is de?nitely initiated at object creation time,i.e.either in the constructor or the class initialization block.

’*’The star multiplicity represents a container class,

e.g.a Set or a Collection.When using the quali?er

notation for Lists,Vectors or arrays,the multiplicity ’0..1’is used together with a quali?er.The meaning of this is that every index is assigned zero or exactly one element(the list is?nite).

Of these multiplicities,all but’*’have been encountered in the Mathaino core package.The star multiplicity was not used,because the only container type employed was Vec-tor,which is represented using the aforementioned quali?er notation.

Inner Classes IDEA recognizes non-anonymous inner classes by parsing the byte code.These are represented like conventional classes,using the Java naming convention for inner class names(as UML does not include this concept). Since an association to an inner class is implicitly bidirec-tional(based on the way inner classes are realized in Java), this construct can be considered the pure form of an inverse association.For each inner class,an association to its de?n-ing class is shown with the role name’this’,to indicate ac-cessibility of the de?ning class from within the inner class.

Class Compartment Details All standard UML class compartment details like(class name,attributes and meth-ods)are supported at implementation detail level.For at-tributes,visibility,identi?er,type and an optional multiplic-ity for arrays are shown.

Resolution of method signatures includes identi?ers of parameters,which facilitates understanding of internal structural relations and metrics analyses[6].Thus,the com-plete design and implementation level signature information is available in the class diagram.

4.3Fujaba

At the time of the writing,reverse engineering the Math-aino package with FUJABA does not(yet)produce sophis-ticated results.Especially,FUJABA is not yet able to deal with the to-many associations in Mathaino,reasonably.Ac-cording to the round-trip engineering approach,FUJABA assumes that all attributes are encapsulated with certain ac-cess methods where the method names contain the attribute name.The Mathaino system does not employ such access methods.Instead,the private container attributes are used directly within various logical methods.Due to the lack of explicit access methods,the analysis of container/Vector entry types is not even triggered.Instead,uni-directional to-one associations to the class Vector are created.Similarly,

FUJABA is not yet able to merge any pair of uni-directional associations to one bi-directional association.In FUJABA, this merge relies on the existence of explicit access meth-ods that call each other,mutually.Without explicit access methods,this feature is not even triggered.

Generally,FUJABA provides a very?exible reverse en-gineering mechanism,that e.g.allows the user to de?ne ap-plication speci?c patterns for the detection of certain higher level design pattern elements.Unfortunately,this does not yet apply for basic reverse engineering features like associ-ation detection.Due to this case study,this will be?xed in the near future.

Classes FUJABA is able to identify the top-level classes and all explicit,named inner classes.However,FUJABA ignores anonymous inner classes since it does not use this construct in forward engineering and thus it does not ex-pect it in reverse engineering.However,this information is provided by our parser and the FUJABA team is currently discussing,whether such anonymous inner classes should be contained in the class diagram.In addition to the Math-aino classes,FUJABA shows all non-primitive classes that are used as attribute types as the target of to-one associa-tions.Classes used as parameter or return types or for local variables are shown optionally.

Handling of Interfaces Interface classes are shown as usual classes with the stereotype Interface.Classes im-plementing the interface inherit from it.Interface usage is not depicted,although usage information is provided by the FUJABA parser.An optional incorporation of uses relation-ships is current work.

Role Names Role names are derived from the identi?ers of non-primitive attributes and are shown at the target as-sociation end of directed associations.When merging di-rected associations,both role names are taken,resulting in an undirected association with role names at both ends. Handling of Java Collection Classes FUJABA uses an adaptable list of pre-de?ned container classes.Attributes of this type are automatically examined for their entry type by looking for usages of their add methods.On success such container attributes are turned into to-many associa-tions.However,due to performance reasons,currently this mechanism is triggered through a name based identi?ca-tion of encapsulating access methods.This heuristic did not work for the Mathaino system.

Merging Inverse Associations The merging of pairs of inverse associations is(again)based on the identi?cation of access methods that call each other mutually.While this works great in round-trip engineering,this did not work for the Mathaino system.The FUJABA team currently consid-ers additional heuristics.

Aggregation and Composition In FUJABA,aggregation and composition is re?ected in certain“isolateYourselfAnd-BecomeGarbageCollected”methods,that are forwarded to contained elements in case of a composition relationship. The Mathaino system does not contain such methods. Multiplicities Due to conceptual considerations,FU-JABA does not support lower multiplicity bounds,neither for to-one nor for to-many associations,neither on forward nor on reverse engineering.Thus,non-primitive attributes are shown using a0..1multiplicity and container attributes with identi?ed entry types are shown using a0..n multiplic-ity.

Inner Classes Named inner classes are shown as usual classes in the class diagram.If applicable,the optionally shown package name contains the surrounding class and or method name.So far,anonymous inner classes are ignored. Class Compartment Details All standard UML class compartment details like(class name,attributes and meth-ods)are supported at implementation detail level.For at-tributes,visibility,identi?er,type and an optional multiplic-ity for arrays are shown.Method signatures include identi-?ers and types of parameters.Since this easily overcrowds the class diagram,the attribute and the method compart-ment may be collapsed by default if they exceed a certain size.The next version of FUJABA will provide scrollers for large attribute or method departments.

4.4Comparison of the Models on a Common Re-

search Platform

The CASE tools examined in this paper,and in general, fall short on supporting the comparison of different UML models against each other.Some CASE tools do offer pro-?ling utilities for measuring a prede?ned set of metrics,but they differ signi?cantly from each other,making it dif?cult to compare the results in a uniform manner.Furthermore, none of the tools is able to deduce the semantically equiv-alent elements between individual UML models and com-pare their internal states.To compare the models produced by the tools on a common research platform,they were ex-ported into TED[19]using an XMI bridge,where they were compared using a set of UML model operations of the BMO (Basic Model Operations)toolkit[7].

A UML model operation produces a new UML diagram on the basis of existing ones.Set operations comprise one

fundamental category of model operations.They apply set theoretical operations(i.e.union,difference or intersection) for two diagrams of the same type,and are typically func-tions with signature D x D D,D denoting a UML dia-gram type.In addition to the manual analysis of the models produced by individual CASE tools and the comparison of the results by hand,set operations,together with a few cus-tomized scripts,were used for alternative automatic com-parison of the UML models under a common workbench.

In this particular case study,the BMO toolkit was used to compare the three models produced by Rational Rose, Together,and IDEA.The models were?rst analyzed using a prede?ned metrics calculation schema,and subsequently set operations were performed on the models in order to ?nd the possible interesting commonalities and differences between them.Even with a relatively small system as Math-aino,it becomes evident that manual comparison of the models is tedious at best,especially for larger scale stud-ies.

Only the IDEA model(as it was saved in XMI)con-formed to the manually calculated metrics.Both Rose and Together models contained model elements external to the core kapor.ca.ualberta.cs.mathaino pack-age(i.e.,our primary interest).Together omits the pack-age structure,placing every model element under a com-mon package thus making it impossible to restrict the data only to that of the Mathaino core.For example,there were 121classes,43associations,and12interfaces in the To-gether model.Rose generates model elements other than those covered in this case study,namely stereotypes,com-ments,components(re?ecting the Java package structure) etc.

The differences in metrics from different tools also point out the weaknesses of XMI and especially the different XMI export implementations of the tools.Therefore more in-teresting than single model metrics are the differences and properties that can be instantly spotted.The BMO tool tries to draw the attention of the user on the potentially interest-ing properties and evident differences.

Table2shows the number of counterpart classes,inter-faces,operations,attributes,associations,and generaliza-tions found between different models by BMO.The coun-terpart elements are decided with a set of heuristic rules based on naming conventions,relationships,and element environment.A name-based recognition technique works especially well with models produced by a revenge engi-neering process due to its requirements on unique identi?er naming imposed by a programming language.

After a counterpart relationship has been generated, BMO allows the results of the operations to be visualized in TED.Since the different CASE-tools excel in different areas of reverse engineering,union operation can be used for combining these models into a more complete repre-

Rose

Together IDEA

5039

24

538448

437341

912

612

Table https://www.wendangku.net/doc/e22498125.html,mon elements found by the

CASE tools

sentation of the original system.Difference operation can be used for exploring the model features generated by only one of the CASE-tools,and intersection shows the minimal submodel that both the CASE-tools agree on.

The most useful operation in the context of this case study is the symmetric difference,which can be used to vi-sually differentiate between the interpretations of different CASE tools.Symmetric difference shows the parts gen-erated only by one tools but not by the other.The differ-ences typically result from different capabilities and inter-pretations of the

tools.

https://www.wendangku.net/doc/e22498125.html,parison of the models gener-

ated by Rose and IDEA.

Figure1shows a portion of a TED class diagram de-scribing the symmetric difference of IDEA and Rose mod-els,centered on the MathainoMainFrame class.TED is not able to use visual cues such as colors for differentiating the sources of different model elements,but with the help of the textual description produced by BMO,the origin of the elements can be deduced.

It is immediately evident from the picture how Rose is able to generate the(unnamed)inner classes,but IDEA

generates multiplicities,association end role names and a composition relationship.The parallel associations be-tween MathainoMainFrame and MathainoDesktopHandler classes,the upper generated by Rose and the lower by IDEA,show the different capabilities of the tools,and also reveal the potential problems when combining the results. The multiplicities0*,which allow any cardinalities,are due to the XMI bridge we use;the XMI exporter of Rose generates default multiplicities.The techniques described here help to pinpoint the potentially interesting differences between the models,and in the context of this case study, the capabilities of the tools themselves.

4.5Comparison of the Results

We compared the results of the examined tools in two different categories:basic and advanced concepts.Basic concepts refer to the UML core elements like classes and associations,and demands that the results are a valid rep-resentation of the underlying software module(i.e.no cen-tral elements have been omitted or represented imprecisely). The second category evaluates the tools’capability to gen-erate a more abstract representation rather than a plain im-plementation level view.This includes strategies for design recovery and recognition of facts that are not immediately visible from the source code.

Basic concepts All of the examined tools succeeded in recognizing the basic UML features like classes,interfaces and associations.Only in one case Together failed to recog-nize a part of the plain associations.At this level,the results could be compared easily using metrics like NOC and NOA. The numbers were generally identical for all tools and the occurring differences could be explained by the different approaches or ways to count.For example,anonymous in-ner classes and package-external classes are handled differ-ently by each tool.Similar differences existed for associa-tions.Concluding,the creation of a correct implementation-view representation could be handled by all four tools. Advanced concepts In the second,advanced comparison, it could be seen that the reverse engineering capabilities of the industrial tools do not go far beyond the basic UML features.More abstract representations and recognition of advanced features are clearly the domain of the research tools:These managed to recognize all of the features from the property suite either completely or at least to a certain degree,while the industrial tools did not address several of them at all(for example,multiplicities,inverse associations and container resolution have not been addressed by the in-dustrial tools).

This leaves the impression that understanding and appli-cation of the UML in reverse engineering is still at a rather low level in industry.Our observation is underpinned by the fact that when comparing different tool versions from the previous two years,no major advancements could be found for the reverse engineering modules of the industrial tools.

The advanced concepts are semantically more challeng-ing to be concluded than the basic concepts.This means that they provide better support for the user in understanding the software.On the other hand,it means that interpretations are needed.Therefore,the generation of the advanced con-cepts should be subjected to user acceptance.In a desirable case,the user involvement is supported either by allowing the user to con?gure the interpretations or by a providing fa-cilities for incremental generation of different concepts(as done,e.g.,in IDEA).

5Related Work

Various empirical studies on comparisons of reverse en-gineering,program comprehension,and information ex-tracting tools have been presented[2,8,1,14].

Bellay and Gall presented a study in which they com-pared four reverse engineering tools by applying them to a commercial embedded software system,written in C[2]. They aimed at pointing out the differences in capabilities and identifying their strengths and weaknesses,especially considering their usability,extensibility,and applicability for analyzing embedded software systems.The tools used in the study vary signi?cantly in terms of notations used. In fact,some of the tools did not have any graphical repre-sentation on the information extracted.Similar studies have been reported by Storey in[15].In our case study,in turn, the models used are standard,namely,UML.We focused on the interpretations between the source code and the class diagram models,rather than tried to draw conclusions on the overall capabilities of the tools.The tools in our study are mostly used for software development.The reverse en-gineering facilities are provided mainly to support round-trip engineering.This is natural,since reverse engineering techniques are and should be used as a part of the software development process as well.Therefore,our study aims at supporting the tool users to understand the interpretations and limitations not only when an unknown software system is analyzed,but also when a familiar OO system is devel-oped.

Armstrong and Trudeau compared traditional reverse en-gineering tools in their capability and applicability in ar-chitecture recovery[1].They considered information ex-traction,classi?cation,and visualization.Armstrong and Trudeau found differences in the capabilities of the tools in extracting information,namely,in parsing C code.This is in line with the study by Murphy et al.[8],in which three source code parsers were compared with respect to their ca-

pabilities in call graph extraction.The classi?cation facil-ities in the tools are implemented to support construction of high-level models and at analyzing the constructed mod-els in general.This is understood to be a manual or semi-automated process in reverse engineering.The classi?ca-tion,as well as the visualization,was supported differently in the tools analyzed.Generating a class diagram for an OO subject system can be seen to contain all these three as-pects:the results of parsing are visualized as a model more abstract than the information captured in the source code. It is worth noticing that this process is carried out automat-ically in the tools used in this case study.Since the map-ping between the code and the class diagram is not straight-forward,hard-wired interpretations have been implemented in the algorithms used.On the other hand,the class dia-gram itself still describes information at a rather low level of abstraction,decreasing the severity of the interpretations. Also,since in round-trip engineering the code is often gen-erated automatically,the same interpretations used for that can also be used when generating class diagrams from the code.

6Summary and Conclusion

Reverse engineering of UML models for the subject object-oriented software system can be carried out roughly according two principles:(1)pulling out as much informa-tion as possible from the subject system and modeling it somehow using UML models or(2)aiming at design level models that are populated with the source code informa-tion whenever it is convenient.To some extent,the for-mer resembles the traditional bottom-up reverse engineer-ing,while the latter has a top-down?avor.

The motivation for this paper was to?nd out to what ex-tent the UML is used or applicable in tool-supported reverse engineering.In the presented study,four tools from both industry and research have been compared concerning their reverse engineering capabilities.We carried out both man-ual and automated comparisons.The manual comparison is needed to understand the interpretations and mappings used to generate a class diagram.With automatic comparison, in turn,metrics data as well as differences and similarities between models can be quickly and easily found https://www.wendangku.net/doc/e22498125.html,-ing a standardized notation such as UML for the represen-tation of software models makes it possible to successfully exploit model manipulation operations,such as set opera-tions,for model analysis and comparison also with reverse engineered models.It is very dif?cult,if not impossible, to build such a workbench for empirical evaluations of tra-ditional reverse engineering tools because of the notational differences.Even though in this study we focused on class diagrams,similar model operations can be built,e.g.,for high-level component diagrams.The bottleneck in this ap-proach is the exchange format:even though XMI1.1has its severe limitations,it is currently the only common exchange format supported by the UML-based CASE-tool vendors.

Our examination shows that although all tools provide a reliable reverse engineering functionality,only the research prototypes provided algorithms for advanced analyses.The focus in the reverse engineering facilities of the industrial tools,in turn,seem to be on the UML core features.De-spite of the constantly ongoing development,the advanced reverse engineering strategies have not been considered in these tools.

Concerning the industrial tools,one crucial problem is matureness of UML support in general.They do not support the UML notation in its entirety.For example,Together has only limited support for association classes and quali?ers, and both Rose and Together do not support n-ary associa-tions.Although Together is easily extensible via its Ope-nAPI and Rose via its Rose Extensibility Interface(REI), the underlying data model contains lots of simpli?cations that make it hard(and sometimes impossible)to re?ect the full richness of the UML metamodel.

References

[1]M.Armstrong and C.Trudeau.Evaluating Architectural Ex-

tractors.In5th Working Conference on Reverse Engineer-ing,pages30–39.Hawaii,USA,1998.

[2] B.Bellay and H.Gall.A comparison of four reverse engi-

neering tools.In4th Working Conference on Reverse Engi-neering,pages2–11.The Netherlands,1997.

[3]R.V.Kapoor and E.Stroulia.Mathaino:Simultaneous

Legacy Interface Migration to Multiple Platforms.In9th International Conference on Human-Computer Interaction, pages(vol.1)51–https://www.wendangku.net/doc/e22498125.html,wrence Erlbaum Associates,5-10 August2001,New Orleans,LA,USA,2001.

[4]R.Kollmann and M.Gogolla.Application of UML Associa-

tions and Their Adornments in Design Recovery.In P.Aiken and E.Burd,editors,Proc.8th Working Conference on Re-verse Engineering(WCRE),pages81–90.IEEE,Los Alami-tos,2001.

[5]R.Kollmann and M.Gogolla.Capturing Dynamic Pro-

gram Behaviour with UML Collaboration Diagrams.In P.Sousa and J.Ebert,editors,Proc.5th European Confer-ence on Software Maintenance and Reengineering,pages 58–67.IEEE,Los Alamitos,2001.

[6]R.Kollmann and M.Gogolla.Metric-Based Selective

Representation of UML Diagrams.In T.Gyim′o thy and

F.B.e Abreu,editors,6th European Conference on Soft-

ware Maintenance and Reengineering.IEEE,Los Alamitos, 2002.Best Paper Award.

[7]J.Koskinen,J.Peltonen,P.Selonen,T.Syst¨a,and

K.Koskimies.Towards Tool Assisted UML Development Environments.In7th Symposium on Programming Lan-guage and Software Tools,2001.

[8]G.Murphy,D.Notkin,W.Griswold,and https://www.wendangku.net/doc/e22498125.html,n.An empir-

ical study of static call graph extractors.ACM Trans.Softw.

Eng.Methodol.,7(2):158–191,1998.

[9]OMG,editor.OMG Uni?ed Modeling Language Speci?ca-

tion,Version1.3,June1999.Object Management Group, Inc.,Framingham,Mass.,Internet:http://www.omg.

org,1999.

[10]OMG.UML Notation Guide.In OMG Uni?ed Modeling

Language Speci?cation,Version1.3,June1999[9],chap-ter3.

[11]OMG.UML Semantics.In OMG Uni?ed Modeling Lan-

guage Speci?cation,Version1.3,June1999[9],chapter2.

[12]OMG.UML Model Interchange.In OMG,editor,OMG

Uni?ed Modeling Language Speci?cation,Version 1.4, February2001,chapter3.Object Management Group,Inc., Framingham,Mass.,Internet:https://www.wendangku.net/doc/e22498125.html,, 2001.

[13]Rational Software Corporation.Rose Enterprise Edition,

2002.https://www.wendangku.net/doc/e22498125.html,.

[14]S.Sim,M.-A.Storey,and A.Winter.A Structured Demon-

stration of Five Program Comprehension Tools:Lessons Learnt.In7th Working Conference on Reverse Engineering, pages210–212.Brisbane,Queensland,Australia,2000. [15]M.-A.Storey.A cognitive framework for describing and

evaluating software exploration tools.Technical report,Si-mon Fraser University,1998.PhD Thesis.

[16] E.Stroulia and R.V.Kapoor.Reverse Engineering Inter-

action Plans for Legacy Interface Migration.In Computer Aided User-Interface Design.Kluwer Academic,2002(to appear).

[17]TogetherSoft Corporation.Together5,2001.http://

https://www.wendangku.net/doc/e22498125.html,.

[18]University of Paderborn.Fujaba,2002.http://www.

fujaba.de.

[19]J.Wikman.Evolution of a distributed repository-based ar-

chitecture.Technical report,Department of Software Engi-neering and Computer Science,Research Report1998:14, Blekinge Institute of Technology,Sweden,1998.Elec-tronic Proceedings of the First Nordic Software Architecture Workshop NOSA’98.

科技论文设计参考文献地格式

科技论文写作指南 (依据中国科技论文在线网站的相关内容改编) 返回 科技论文是科技发展及现代化建设的重要科技信息源，是记录人类科技进步的历史性文件。什么是科技论文？它与一般的科技文章有什么不同？怎样写好科技论文？这些都是广大科技工作者感兴趣的问题。因此，本站刊登“科技论文写作指南”，以期进一步提高科技论文的整体水平。 一、科技论文的含义 科学技术论文简称科技论文。它一般包括：报刊科技论文、学年论文、毕业论文，学位论文 ( 又分学士、硕士、博士论文 ) 。科技论文是在科学研究、科学实验的基础上，对自然科学和专业技术领域里的某些现象或问题进行专题研究，分析和阐述，揭示出这些现象和问题的本质及其规律性而撰写成的文章。也就是说，凡是运用概念、判断、推理、论证和反驳等逻辑思维手段，来分析和阐明自然科学原理、定律和各种问题的文章，均属科技论文的范畴。科技论文主要用于科学技术研究及其成果的描述，是研究成果的体现。运用它们进行成果推广、信息交流、促进科学技术的发展。它们的发表标志着研究工作的水平为社会所公认，载入人类知识宝库，成为人们共享的精神财富。科技论文还是考核科技人员业绩的重要标准。 二、科技论文的特点 1．科学性 科学性又称真理性，是保证学术论文质量的最基本的要求。科学性的内涵通常可分解为真实性、准确性、可重复性、可比性和逻辑性。 （1）真实性 文案大全

论文必须内容真实，资料可靠。作者要求具有严谨的治学作风和实事求是的科学态度，做到科研设计缜密，努力避免技术性失误，并且客观地记述科研数据，尊重事实，不凭主观臆断和个人好恶随意取舍客观数据或歪曲结论。 （2）准确性 论文的数据、引用的资料应准确无误，其结论和评价应恰如其分地反映客观事物及其运动规律。要求作者仔细观察实验过程，并对实验数据进行精确记录；写作时要选择最恰当的词语，仔细推敲相近词在表述上的细微差别，力争把写入的内容准确到表述出来。 （3）可重复性 读者如采用论文介绍的技术和方法，在相同的条件下，应获得与论文相同的结果和结论。只有在研究中真正揭示了研究对象的内部联系，并掌握了该对象的变化规律，才能保证论文结果和结论的可重复性。这就要求作者科研设计必须合理，写作时要详细介绍必要的、关键的内容，尤其是自己创新或改进的技术和方法，以便读者可重复出同样的结果。有了可重复性的成果，才有推广和应用价值，也才有确定的经济价值和社会价值。 （4）可比性 论文的结果可与其他相同或相近的课题已报道的结果进行比较，以确定其是否具有先进性。这就需要设立对比观察，并用统计学的方法处理观察结果。没有可比性的论文，其可行程度会大大降低。 （5）逻辑性 论文要求必须脉络清晰，结构严谨，论证的展开应符合思维的客观规律。这就要求作者在选题、提出假设、搜集素材、推断结论以及论文写作的全过程中，都必须严格遵守逻辑学的基本规律，不能出现违背逻辑学原理和规律的错误。 文案大全

古典文献学书目

张舜徽：《中国文献学》，郑州：中州书画社，1982；上海：上海古籍出版社，2005。洪湛侯：《中国文献学新编》，杭州：杭州大学出版社，1994。 孙钦善：《中国古文献学史》，北京：中华书局，1994。 杜泽逊：《文献学概要》，北京：中华书局，2001。 黄永年：《古文献学四讲》，厦门：鹭江出版社，2003。 张三夕主编：《中国古典文献学》，武汉：华中师范大学出版社，2003。 孙钦善：《中国古文献学》，北京：北京大学，2006。 张舜徽：《文献学论著辑要》，西安：陕西人民出版社，1985。 余嘉锡：《古书通例》，上海：上海古籍出版社．1985。 邱陵：《书籍装帧艺术简史》，哈尔滨：黑龙江人民出版社，1984。 韩仲民：《中国书籍编纂史稿》，北京：中国书籍出版社，1988。 来新夏：《中国古代图书事业史》，上海：上海人民出版社，1990。 曹之：《中国古籍编撰史》，武汉：武汉大学出版社，1999。 魏隐儒：《古籍版本鉴定丛谈》，北京：印刷工业出版社，1984。 戴南海：《版本学概论》，成都：巴蜀书社，1989。 严佐之：《古籍版本学概论》，上海：华东师范大学出版社，1989。 李致忠：《古书版本学概论》，北京：书目文献出版社，1990。 曹之：《中国古籍版本学》，武汉：武汉大学出版社，1992，2002（重印）。 姚伯岳：《版本学》，北京：北京大学出版社，1993。 程千帆、徐有富：《校雠广义?版本编》，济南：齐鲁书社，1998。 黄永年：《古籍版本学》，南京：江苏教育出版社，2005。 戴南海：《校勘学概论》，西安：陕西人民出版社，1986。 倪其心：《校勘学大纲》，北京：北京大学出版社，1987。 管锡华：《校勘学》，合肥：安徽教育出版社，1991。 程千帆、徐有富：《校雠广义?校勘编》，济南：齐鲁书社，1998。 余嘉锡：《目录学发微》，北京：中华书局，1963；成都：巴蜀书社，1991。 来新夏：《古典目录学浅说》，北京：中华书局，1981。 程千帆、徐有富：《校雠广义?目录编》，济南：齐鲁书社，1988。 周少川：《古籍目录学》，郑州：中州古籍出版社，1996。

中国专利文献编号

中国专利说明书的编号体系由于1989年和1993年的两次调整而分为三个阶段：1985年~1988年为第一阶段，1989年~1992年为第二阶段，1993年以后为第三阶段。列表举例说明如下。 第一阶段：1985年~1988年的编号体系 此阶段的编号特点： （1）三种专利申请号由8位数字组成，按年编排。如88100001，前两位数字表示受理专利申请的年号，第三位数字表示专利申请的种类，1—发明、2—实用新型、3—外观设计，后五位数字表示当年申请顺序号。 （2）一号多用，所有文献号沿用申请号。专利号前的ZL 为汉语“专利”的声母组合， 一 般用在专利公报或检索工具中。 共用一套号码的编号方式，突出的优点是方便查阅, 易于检索。不足之处是：由于专利审查过程中的撤回、驳回、修改或补正，使申请文件不可能全部公开或按申请号的顺序依次公开，从而造成文献的缺号和跳号（号码不连贯）现象，给文献的收藏与管理带来诸多不便。因此， 1989年中国专利文献编号体系作了调整。 第二阶段：1989年~1992年的编号体系 此阶段的编号特点： （1）自1989年开始出版的专利文献中，三种专利申请号由9位数字组成，按年编排。如 89103229.2，增加小数点后面的计算机校验码，其它含义不变。 （2）自 1989年开始出版的所有专利说明书文献号均由7位数字组成，按各自流水号序列 顺排，逐年累计。起始号分别为：发明专利申请公开号自CN1030001A 开始，发明专利申请审定号自CN1003001B 开始，实用新型申请公告号自CN2030001U 开始，外观设计申请公告号自CN3003001S 开始。首位数字表示专利权种类：1—发明，2—实用新型，3—外观设计。 1993年1月1日起实施修改后的专利法，伴随1994年中国加入专利合作条约（PCT ），1995年4月开始公布进入中国国家阶段的国际申请，为此中国专利文献编号体系又有新变化。

文献综述 完整版

文献综述 近十年白居易诗歌平淡美研究综述 一、国内外研究现状概述 近十年来关于白居易的研究也是古代文学研究领域的一大趋势。主要集中在白居易的诗歌研究、散文研究、思想研究、生存哲学研究等4个方面。据不完全统计，近十年来关于白居易研究的著作大致有陈友琴《白居易资料汇编》（中华书局，2005年再版）、付兴竹《白居易散文研究》（中国社会科学出版社，2007年版）、刘维，焦淑清《白居易传》（辽海出版社，2009年版）、蹇长春《白居易评传》（南京大学出版社，2011年版）等4部；研究论文达4500多篇，其中硕士学位论文余篇、博士学位论文余篇。研究领域得到很大的拓展，研究视角和方法更加多元化，研究观念也较为开放自觉。近十年来白居易研究主要的研究方向体现在白居易的诗歌研究、散文研究、思想研究、生存哲学研究等4个方面。 在白居易研究的多个方面上，成就较为突出地是关于诗歌的研究。据不完全统计，十年来关于白居易诗歌方面研究的著作有乔立智《白居易诗歌词汇研究》（北京人民出版社，2012年版）、付兴林，倪超《<长恨歌>及李扬题材唐诗研究》（中国社会科学出版社，2013年版）、张中宇《白居易<长恨歌>研究--中华文史新刊，2005年版》、胡奇光《中国古代语言艺术史》（上海人民出版社，2010年版）等4部；研究论文达200篇，其中硕士学位论文50余篇，博士学位论文达4篇。涉及的研究范围很广泛，在研究视角与方法上呈现多样性，在观念上也比先前更为开放自觉。近十年来白居易诗歌研究的主要内容多体现在诗歌对后世文学的影响研究、诗歌语言词汇研究、诗歌意象研究、诗歌对外翻译研究、审美研究等5个方面。在不同程度上，都取得了相应的成果，50多篇硕博学位论文对白居易诗歌的相对应之处都进行了深入的探讨研究，整体上对全面了解白居易及其诗歌做出了较大贡献，对白居易集的

和生活有关的科学论文参考文献

和生活有关的科学论文参考文献 居家生活与储藏空间的科学理念 现在都市的房子昂贵，人们都在绞尽脑汁使自己买的房子物有所值。一般看楼盘都关注房子的套型、舒适度、交通便利，却往往忽视了房子能否储藏的空间。当住进来后才感觉房子越住空间越来越小，事实上各功能房间的进深、宽度的比例将影响到装修时留有储物空间的大小。 一、设计观念 随着生活水平的提高，物质的丰富多样化，大小家庭的储物空间越来越重视。房子布局合理虽然重要，具体到每个房间的长宽比时，能否给储藏留有足够的空间也同样重要。这将给居住者们今后生活中大小物品的存放减少不必要的麻烦。 "以人为本"的设计理念，在各种报章媒体中频频出现，有时也成为一个时髦的标签，贴在了某个设计作品上。对于从事住宅设计的设计师来说，第一重要的是真正地从生活需求出发，认认真真地观察生活，感受生活;第二重要的是真诚地了解当地人们生活习惯和生活方式，用心来做设计。我们可以没有理论，但是我们不能没有思考。 花大钱追求豪华奢侈生活的业主毕竟数量有限，广大百姓对居住环境的要求只是舒适﹑整洁﹑温情，体现居住者的生活情趣，良好的空间感受、生活习惯便捷﹑生活方式的关切，将其生活内容体现在设计中远胜于那些抽象莫名的理论，没实用性的艺术美感去误导业主，千万不要让自己仓促的设计造成人们日常生活的麻烦。 二﹑储藏空间设计原则 生活中的物品零零碎碎﹑各种各样，又是不可缺少的，该怎样来安排呢?首先在设计住宅时应考虑各类房间都有自己的储物空间待装修时留有余地，以个人设计经验认为首先储藏室一般为1.5m?~3 m?，格式根据具体情况设计为“U“ “ L” “Ⅱ”型，又分为进人和不进人。譬如各类房间进出口处、房间进深及高度、内墙及结构的边角部分的利用，都是今后生活中大大小小物品的存放空间。第二、就近原则，尽量将各个功能房间中所需使用的物品储存于相应的房间中，便于日常取用。第三、儿童及老人房储存设计中考虑到生活自理能力和孩子的动手能力，为居住者日常生活提供良多便利。第四、现在住宅套型的灵活性和多样性，在套型之间、楼层之间的变换给同一居住者在不同时期对空间需求有不同的选择。譬如套之间的墙体拆除形成大的空间，楼层之间可以形成跃层式住宅，给居住者新的空间。这些变换都随着家庭结构、时间的变化而改变，从而对储物空间的选择性更为灵活。另外，安全因素隐蔽性也是不能忽视的，以待装修时考虑。 三﹑居家新生活

(完整word版)2020复旦050104中国古典文献学考研考试科目、参考书目、真题等汇总,推荐文档

一、2020-2021复旦大学中国古典文献学考研研究方向及考试科目 考研研究方向： 07中国文献学史 08古文字学 09古文献与古文字 10文字学 11敦煌学 考试科目： ①101思想政治理论; ②201英语一(或)203日语(或)241法语(或)242德语; ③705文学语言综合知识; ④810目录版本学（07方向） ①101思想政治理论; ②201英语一(或)203日语(或)241法语(或)242德语; ③707古汉语与上古史 ④812古文字学（08、09、10方向） ①101思想政治理论; ②201英语一(或)203日语(或)241法语(或)242德语; ③735敦煌文献学; ④891古代汉语（11方向） 二、2020-2021复旦大学中国古典文献学考研参考书目 复旦大学官网不公布参考书目，以下书目仅供参考： 古代文学用的是袁行霈编的中国文学史四卷本 外国文学是郑克鲁的外国文学史配套崇文书局出的外国文学史辅导及习题集现当代文学就是以三十年、洪子诚和陈思和老师的当代文学史 文学理论的东西：古代文论与西方文论、文学理论 大量复旦老师的专著论文 严家炎的二十世纪中国文学史，新中国文学史 复旦出的中国文学史新著、分体文学史 王力《中国古代文化常识》 《辞海》文学卷 王力先生的《古代汉语》 郭锡良老师的《古代汉语》 ps:欢迎后台留言补充书目~ 三、复旦大学2016古籍所【050104中国古典文献学】702+803真题回忆

702 文史知识 一、填空：2分×11个 1、对联：__________，青山无古今。 2、明代唐寅字____号____。 3、明天启七年干支丁卯，则天启辛酉是天启____年。清乾隆五年干支庚申，则乾隆五十五年干支____年。 4、《瓯北诗话》作者是____朝代的____，《元丰类稿》作者是____朝代的____，《殷卜辞中所见先公先王考》作者是____朝代的____。 二、名解：6分×8个 1、等因奉此 2、歌行体 3、朴学 4、会稽 5、光禄寺 6、《通鉴纪事本末》 7、燕行使 8、南怀仁 三、问答：40分×2个 1、4选1作答，用浅近文言，写500字左右提要： 《史记评林》《四库提要辨证》《世说新语》《石渠宝笈》 2、阅读文本：（就是伯夷叔齐不食周粟，首阳山采薇那一段，好像以前看过，哭，考试时紧张的忘记出处了，还好不用答出处，百度了一下，是《史记·伯夷列传》，原文：简体，横排，左-右） 夫武王已平殷乱天下宗周而伯夷叔齐耻之义不食周粟隐于首阳山采薇而食之及饿且死作歌其辞曰登彼西山兮采其薇矣以暴易暴兮不知其非矣神农虞夏忽焉没兮我安适归矣于嗟徂兮命之衰矣遂饿死于首阳山 （1）简转繁，标点（包括专名号）； （2）运用学过的文史知识，用规范的现代汉语，对短文写1000字左右札记————然后我可耻的只会大作文+对联干支…丢人啊～选了《世说新语》竟然没写完五百字～———— 803 古籍校读 一、选段：（原文：繁体，横排，左-右，有标点，标点正误夹杂） 是书首有自序云凡三十篇为二十卷今自忠志至肉攫部凡二十九篇尚阙其一考语资篇后有云客徵鼠虱事余戏摭作破虱录今无所谓破虱录者盖脱其一篇独存其篇首引语缀前篇之末耳至其续集六篇十卷合前集为三十卷诸史志及诸家书目并同而胡应麟笔丛云酉阳杂俎世有二本皆二十卷无所谓续者近於太平广记中抄出续记不及十卷而前集漏轶者甚多悉抄入续记中为十卷俟好事者刻之又似乎其书已佚应麟复为抄合者然不知应麟何以得其篇目岂以意为之耶其书多诡怪不经之谈荒渺无稽之物而遗文秘籍亦往往错出其中故论者虽病其浮夸而不能不相徵引自唐以来推为小说之翘楚莫或废也其曰酉阳杂俎者盖取梁元帝赋访酉阳之逸典语

中国专利文献

中国专利文献 §2.1.1 中国专利说明书 中国各类专利说明书自1985年9月10日开始出版以来，随专利审批程序的变化不断推陈出新。 1.1985-1992年出版的专利说明书： 1985年，专利法规定对发明专利申请实行“早期公开、延迟审查”制，专利申请自实质审查开始、到授予专利权期间内设异议程序；对实用新型、外观设计专利申请实行初步审查制，专利申请从初审公告开始到授予专利权期间内设异议程序。 ①发明专利申请公开说明书（文献类型识别代码A）：这是一种未经实质性审查、尚 未授予专利权的说明书。发明专利申请提出后，经初步（形式）审查合格后，自申 请日（或优先权日）起满18个月予以公布，并出版发明专利申请公开说明书。（1985 年出版至今）。 ②发明专利申请审定说明书（文献类型识别代码B）：这是一种经过实质性审查、尚 未授予专利权的说明书。1985年专利法规定，发明专利申请自申请日起3年内，专 利局可根据申请人随时提出的请求，对其申请进行实质性审查。经实审合格的，做 出审定予以公告，并出版发明专利申请审定说明书。自公告日起3个月为异议期，期满无异议或异议理由不成立的，对专利申请授予发明专利权。（1985-1992年间出 版）。 ③实用新型专利申请说明书（文献类型识别代码U）：实用新型专利提出申请后，初 步审查合格即行公告，并出版实用新型专利申请说明书。自公告日起3个月内异议 期，期满无异议或异议理由不成立的，对专利申请授予实用新型专利权。（1985-1992 年间出版）。 ④外观设计专利公告（专利公报）（文献类型识别代码S）：专利提出申请后，初步审 查合格即行公告。由于外观设计专利申请公告仅由简要说明、图片或照片组成，因 而不出版说明书单行本，只在专利公报上进行公告。自公告日起3个月为异议期，期满无异议或异议理由不成立的，对专利申请授予外观设计专利权。（1985-1992年 间出版）。

文献综述 完整版

XXX大学 文献综述 ***届 离子液体+ 溶剂二元体系电导率、表面 张力物性研究进展 学生姓名XXX 学号XXX 院系XXX 专业XXX 指导教师XXX 填写日期XXX 离子液体 + 溶剂二元体系电导率、表面 张力物性研究进展

摘要 离子液体作为一种新型的绿色溶剂，其物理化学性质的研究受到了普遍的关注,采用离子液体与各类溶剂形成二元体系研究究引起了全世界研究者的关注。针对离子液体二元体系常规理化性质的研究有利于了解离子液体的结构特性及新型离子液体的开发。离子液体二元体系的理化性质除受到温度和离子液体本身结构的影响外，还受到二元体系中溶剂极性和各组分含量等的影响。本文综述了离子液体的电导率、表面张力的研究进展。研究发现大部分离子液体的表面张力γ随温度升高而减小，同一种离子液体浓度越高,表面张力越小，表面张力随含水量的增加而增加；离子液体在相同温度下电导率随浓度的增加而增大，相同浓度下电导率随温度的升高而增大。 关键词：离子液体；电导率；表面张力 离子液体具有与传统有机溶剂截然不同的性质和特点，其化学稳定性好、溶解性好、熔点低、不易挥发、可传热、可流动、对环境污染少，可作为绿色溶剂用于化学反应和分离过程，近年来受到了人们的广泛关注和被广泛应用，例如精细化学品合成、高分子聚合物及有关合成、分离萃取、消除环境污染、太阳能电池和燃料电池等[1]。离子液体成为国内外研究的热点之一，目前已广泛应用于催化、材料和萃取分离[2-5]等领域由于离子液体所具备的这些优点，近年来离子液体越来越多地被作为一种可设计的功能型分子，即所谓的功能化离子液体(TSIL)。功能化离子液体是指在阳离子或阴离子上引入官能团的离子液体，但其与离子液体是一个不可分割的整体。由于功能化离子液体的核心离子与官能团影响着反应过程，与溶解于其中的溶质产生相互作用，导致最终过程优化的实现，更加符合实验和工业需求而受到重视。 本文结合国内外的研究情况，不仅对离子液体+溶剂二元体系表面张力实验测定工作进展做了归纳，还对电导率方面的研究做了相应的综述。 1.离子液体+溶剂二元体系表面张力 目前，关于离子液体表面张力的研究还十分有限，表面张力是表面化学中最

中国科学引文数据库(CSCD)简介

附件2： 中国科学引文数据库（CSCD）简介 中国科学引文数据库创建于1989年，通过清华大学和中国科学院资源与技术的优势结合和多年的数据积累，目前已发展成为我国规模最大、最具权威性的科学引文索引数据库——中国的《科学引文索引》（SCI），为中国科学文献计量和引文分析研究提供了强大工具。中国科学引文数据库（CSCD）为年刊，收录我国数学、物理、化学、天文学、地学、生物学、农林科学、医药卫生、工程技术、环境科学和管理科学等领域出版的中英文科技核心期刊和优秀期刊近千种。 数据库的来源期刊每两年进行一次评选，分为核心库和扩展库两部分内容。其中，核心库的来源期刊经过严格的评选,是各学科领域中具有权威性和代表性的核心期刊；扩展库的来源期刊也经过大范围的遴选，是我国各学科领域较优秀的期刊。2011-2012版本的中国科学引文数据库共遴选了1124 种期刊，其中英文刊110 种，中文刊1014 种；核心库期刊 751 种（以C为标记）扩展库期刊 373 种（以E为标记）。 中国科学引文数据库是我国第一个引文数据库。曾获中国科学院科技进步二等奖。1995年CSCD出版了我国的第一本印刷本《中国科学引文索引》，1998年出版了我国第一张中国科学引文数据库检索光盘，1999年出版了基于CSCD和SCI数据，利用文献计量学原理制作的《中国科学计量指标：论文与引文

统计》，2003年CSCD上网服务，推出了网络版，2005年CSCD 出版了《中国科学计量指标：期刊引证报告》。2007年中国科学引文数据库与美国Thomson-Reuters Scientific合作，中国科学引文数据库将以ISI Web of Knowledge为平台，实现与Web of Science的跨库检索，中国科学引文数据库是ISI Web of Knowledge平台上第一个非英文语种的数据库。 中国科学引文数据库目前已在我国各大科研院所、高等学校的课题查新、基金资助、项目评估、成果申报、人才选拔以及文献计量与评价研究等多方面作为权威文献检索工具获得广泛应用。主要包括：自然基金委国家杰出青年基金指定查询库；第四届中国青年科学家奖申报人指定查询库；自然基金委资助项目后期绩效评估指定查询库；众多高校及科研机构职称评审、成果申报、晋级考评指定查询库；自然基金委国家重点实验室评估查询库；中国科学院院士推选人查询库；教育部学科评估查询库；教育部长江学者；中科院百人计划等。

中国科技论文参考文献范例

https://www.wendangku.net/doc/e22498125.html, 中国科技论文参考文献 一、中国科技论文期刊参考文献 [1].走向繁荣的中国科技期刊研究——庆祝《中国科技期刊研究》创刊25周年. 《中国科技期刊研究》.被中信所《中国科技期刊引证报告》收录ISTIC.被北京大学《中文核心期刊要目总览》收录PKU.被南京大学《核心期刊目录》收录CSSCI.2015年10期.刘雪立. [2].《中国科技期刊研究》创刊25周年感悟. 《中国科技期刊研究》.被中信所《中国科技期刊引证报告》收录ISTIC.被北京大学《中文核心期刊要目总览》收录PKU.被南京大学《核心期刊目录》收录CSSCI.2015年10期.马智. [3].《中国科技期刊研究》论文被WebofScience数据库引用分析. 《中国科技期刊研究》.被中信所《中国科技期刊引证报告》收录ISTIC.被北京大学《中文核心期刊要目总览》收录PKU.被南京大学《核心期刊目录》收录CSSCI.2014年9期.鲍国海. [7].《新疆医科大学学报》被“中国科技核心期刊”收录的启示. 《中国科技期刊研究》.被中信所《中国科技期刊引证报告》收录ISTIC.被北京大学《中文核心期刊要目总览》收录PKU.被南京大学《核心期刊目录》收录CSSCI.2013年4期.周芳. [8].中国科技核心期刊网站建设现状. 《中国科技期刊研究》.被中信所《中国科技期刊引证报告》收录ISTIC.被北京大学《中文核心期刊要目总览》收录PKU.被南京大学《核心期刊目录》收录CSSCI.2011年5期.程维红.任胜利.路文如.严谨.王应宽.方梅. [9].《电力系统自动化》和《高电压技术》入选“第2届中国精品科技期刊”. 《电力系统自动化》.被中信所《中国科技期刊引证报告》收录ISTIC.被EI收录EI.被北京大学《中文核心期刊要目总览》收录PKU.2011年24期. [10].中国科技服务业区域非均衡发展及影响因素研究. 《科技管理研究》.被中信所《中国科技期刊引证报告》收录ISTIC.被北京大学《中文核心期刊要目总览》收录PKU.被南京大学《核心期刊目录》收录CSSCI.2016年1期.张清正.魏文栋.孙瑜康. 二、中国科技论文参考文献学位论文类

中国古典文献学参考书目

中国古典文献学参考书目 来源：李士彪柘人的日志 中国古典文献学参考书目 （据说是北师大教授郭英德推荐的书目。不是很多，但看完这些也就够了。） 通用书目： 张舜徽：《中国文献学》，郑州：中州书画社，1982；上海：上海古籍出版社，2005。洪湛侯：《中国文献学新编》，杭州：杭州大学出版社，1994。 孙钦善：《中国古文献学史》，北京：中华书局，1994。 杜泽逊：《文献学概要》，北京：中华书局，2001。 黄永年：《古文献学四讲》，厦门：鹭江出版社，2003。 张三夕主编：《中国古典文献学》，武汉：华中师范大学出版社，2003。 孙钦善：《中国古文献学》，北京：北京大学，2006。 张舜徽：《文献学论著辑要》，西安：陕西人民出版社，1985。 古籍编纂学书目 余嘉锡：《古书通例》，上海：上海古籍出版社．1985。 邱陵：《书籍装帧艺术简史》，哈尔滨：黑龙江人民出版社，1984。 韩仲民：《中国书籍编纂史稿》，北京：中国书籍出版社，1988。 来新夏：《中国古代图书事业史》，上海：上海人民出版社，1990。 曹之：《中国古籍编撰史》，武汉：武汉大学出版社，1999。 古籍版本学书目

魏隐儒：《古籍版本鉴定丛谈》，北京：印刷工业出版社，1984。 戴南海：《版本学概论》，成都：巴蜀书社，1989。 严佐之：《古籍版本学概论》，上海：华东师范大学出版社，1989。 李致忠：《古书版本学概论》，北京：书目文献出版社，1990。 曹之：《中国古籍版本学》，武汉：武汉大学出版社，1992，2002（重印）。姚伯岳：《版本学》，北京：北京大学出版社，1993。 程千帆、徐有富：《校雠广义·版本编》，济南：齐鲁书社，1998。 黄永年：《古籍版本学》，南京：江苏教育出版社，2005。 古籍校勘学书目 戴南海：《校勘学概论》，西安：陕西人民出版社，1986。 倪其心：《校勘学大纲》，北京：北京大学出版社，1987。 管锡华：《校勘学》，合肥：安徽教育出版社，1991。 程千帆、徐有富：《校雠广义·校勘编》，济南：齐鲁书社，1998。 古籍目录学书目 余嘉锡：《目录学发微》，北京：中华书局，1963；成都：巴蜀书社，1991。来新夏：《古典目录学浅说》，北京：中华书局，1981。 程千帆、徐有富：《校雠广义·目录编》，济南：齐鲁书社，1988。 周少川：《古籍目录学》，郑州：中州古籍出版社，1996。 何新文：《中国文学目录学通论》，南京：江苏教育出版社，2001。 补：《古籍整理学》，刘琳、吴洪泽著，成都：四川大学出版社，2003。

中国专利文献介绍

中国专利文献 中国各类专利说明书自1985年9月开始出版以来，随专利审批程序的变化不断推陈出新。现将不同审批阶段出版的专利说明书汇总如下： 1985-1992年： 发明专利申请说明书，文献类型识别代码A 这是一种未经实质性审查、尚未授予专利权的说明书。发明专利申请提出后，经初步（形式）审查合格，自申请日（或优先权日）起满18个月即行公布，出版发明专利申请公开说明书。1985年出版至今。 发明专利申请审定说明书，文献类型识别代码B 这是一种经过实质性审查、也尚未授予专利权的说明书。1985年专利法规定，发明专利申请自申请日起3年内，专利局可根据申请人随时提出的请求，对其申请进行实质性审查。经实审合格的，作出审定予以公告，出版发明专利申请审定说明书。自公告日起3个月内为异议期，期满无异议或异议理由不成立，对专利申请授予发明专利权。1985年至1992年期间出版。 实用新型专利申请说明书，文献类型识别代码U 我国专利法对实用新型专利申请实行初步审查制，专利提出申请后，初步审查合格即行公告，出版实用新型专利申请说明书。自公告日起3个月内为异议期，期满无异议或异议理由不成立，对专利申请授予实用新型专利权。1985年至1992年期间出版。 外观设计申请公告，文献类型识别代码S 外观设计专利申请同样实行初步审查制。专利提出申请后，初步审查合格即行公告。由于外观设计说明书仅由简要说明、图片或照片组成，因而不出版说明书单行本，只在专利公报上进行公告。自公告日起3个月内为异议期，期满无异议或异议理由不成立，对专利申请授予外观设计专利权。1985年至1992年期间出版。 为减少重复出版，对上述授权的三种专利一般不再出版专利说明书。如果经异议或无效程序，对发明专利申请审定说明书或实用新型专利申请说明书做出较大修改，才出版相应的经修改后的发明专利说明书或实用新型专利说明书。这两种专利说明书只出过若干件。 1993年后： 1993年实施第一次修改后的专利法，由于取消了三种专利申请授权前的异议程序，专利说明书出现新的类型： 发明专利说明书，文献类型识别代码C 发明专利申请经实审合格即可授予专利权，自1993年1月1日起开始出版发明专利说明书，从而取代了发明专利申请审定说明书的出版。 实用新型专利说明书，文献类型识别代码Y 实用新型专利申请经初审合格即可授予专利权，自1993年1月1日起开始出版实用新型专利说明书，从而取代了实用新型专利申请说明书的出版。 外观设计授权公告，文献类型识别代码D 外观设计专利申请经初审合格即可授予专利权，自1993年1月1日起开始在外观设计公报中公告，外观设计申请公告也随之取消。 下列示意图可对以上7种类型说明书的产生和取缔进行归纳、总结。

如何阅读科技文献

同研究生谈科技文献阅读 彭渤 科技文献阅读在科研活动中占有十分重要的地位。在我看来，阅读专业文献应贯穿科研活动的整个过程。信息时代，面对浩如烟海的专业科技文献，究竟应该如何来阅读呢？这是很多研究生问我的问题。以前在讲授《文献阅读与科技论文写作》这门课程，与学生讨论交流时，这个问题是大家课堂问得最多的问题。一些学生甚至毕业后，还发邮件来问这个问题。但我想，不同的学者对这个问题有不同的体会和答案。这里谈谈自己的体会，仅供参考。并期以抱砖引玉。 1. 科技文献的作用。阅读文献，首先应明确文献在科研工作，特别是基础研究中的作用。文献在科研活动中具有如下三方面的作用或者功能。(1) 文献资料构筑了某个领域的研究背景。即一般基金申请书中的“国内外研究现状部分”的内容，或者文章本身的引言部分的内容。一份基金申请书，或者一篇投稿的论文，对某领域研究背景的表述和分析，是最能反映申请书或者论文水平的部分。一项研究起点高低的程度，全在于其对研究背景的把握和分析。因而作者对相关文献资料的占有程度、把握水平和理解深度，是决定某项研究水平高低的关键之一。(2) 文献资料为科研工作奠定研究基础。一项研究设计的研究内容、技术路线和研究方案，在理论上是否成立，在实践上是否可行，文献资料的分析能够帮助你作出判断。因此，文献资料在理论上为科研工作奠定了研究的理论基础，在实践上为科研工作创造了一定的工作条件。(3) 文献资料是“巨人的肩膀”。科技创新不是喊口号，更不是“无源之水”。她需要“土壤”，需要根基。这个“土壤”和根基的重要组成部分，就是文献资料。在这个“土壤”和根基上，发生知识“火花”的碰撞，实现科技创新，其实就是站在了“巨人的肩膀”之上的认识升华、技术革新或者理论突破。因此，文献资料是创新“火花”的源头，是“巨人的肩膀”。 2. 阅读科技文献的目的。上述科技文献在科研活动中所起的作用表明，阅读参考文献的主要目的之一就是提升学术水平。在笔者看来，具体包括如下四个方面。(1) 丰富基础知识。文献与专著等书籍不同，文献传播的知识常常是零散的，而一般专著或者教材包容的知识具一定的系统性。但文献，特别是新近文献，常常传播最新的知识点。因而，通过阅读某个领域的新近文献，追踪阅读历史文献，能为读者打下某个研究领域全面、深刻、丰厚的知识基础。使初学者由入门进步到专业水平。进而可达到通观全局，充满自信的程度。(2) 把握学术观点。在同一个研究领域，不同的学者从不同的研究层面、(对地质学、地理学等自然科学而言)不同的研究地域、不同的研究方法，甚至不同的研究水平和不同的实验条件等，对同一问题可能得到不同的认识，形成不同的学术观点。通过广泛的阅读、分析和思考，就会对不同的学术观点有全面的把握。认识(归纳、总结)不同学术观点形成的环境条件、适用范围、优点和不足等，对于进一步的科研工作十分重要。(3) 学习技术方法。大家在看文献时应该注意到，发表的专业科技文献，一般都包括研究方法的详尽表述这部分内容。特别是外文文献。这是因为方法决定结果。因而，阅读参考文献，能够达到全面了解某个领域使用的主要研究方法和技术手段的目的。如沉积物重金属元素赋存状态的研究，就有逐级化学萃取分离分析、单矿物分析、元素地球化学分析等主要的研究方法。其中化学逐级分离分析的方法又有5步法、3步法、2步法等。所有这些方法都在有关文献中有详细的表述。如果你也试图研究沉积物中重金属的活性问题，那就得首先从文献资料中，对这些方法有全面的认识。再结合自己的研究课题，确定你自己研究中采用的方法。这个过程本身就需要你有一定的见解和创新能力。(4) 积累研究素材。科学研究得到科学结论、学术观点和理论认识，都需要以客观事实为基础。即需要合理的素材来作支撑。这个研究素材可以是你通过科学考察、科学实验分析得到，也可以通过文献资料来获取。对文献资料把握得好，常常能起到事

自然科学类论文参考文献范例

https://www.wendangku.net/doc/e22498125.html, 自然科学类论文参考文献 一、自然科学类论文期刊参考文献 [1].2005～2007年我国自然科学类期刊自引率统计分析. 《中国科技期刊研究》.被中信所《中国科技期刊引证报告》收录ISTIC.被北 京大学《中文核心期刊要目总览》收录PKU.被南京大学《核心期刊目录》收录CSSCI.2010年6期.徐自超. [2].基于因子分析的120种自然科学类期刊的综合评价. 《山东农业大学学报（自然科学版）》.被中信所《中国科技期刊引证报告》收录ISTIC.被北京大学《中文核心期刊要目总览》收录PKU.2014年2期.梁凤鸣.侯丽娟.时群. [3].大学学报 《中国科技期刊研究》.被中信所《中国科技期刊引证报告》收录ISTIC.被北 京大学《中文核心期刊要目总览》收录PKU.被南京大学《核心期刊目录》收录CSSCI.2013年4期.吕文红.刘霞.高丽华. [7].基于协调视角的广东省自然科学类“211工程”学科建设项目资金管 理模式的改进——以华南师范大学的调研数据为例. 《广东科技》.2012年5期.黄英.何林.李松. [8].师范大学自然科学类通识选修课的新模式探索. 《课程教育研究》.2016年3期.张小燕. [9].我国自然科学类博物馆非正规教育属性分析. 《黑龙江科技信息》.2012年14期.刘君普. [10].高校自然科学类学报编校质量分析. 《传媒》.被北京大学《中文核心期刊要目总览》收录PKU.2014年2期.李文竹.杨春兰. 二、自然科学类论文参考文献学位论文类 [1].高中生自然科学类科普读物阅读现状的调查研究.被引次数：3 作者：房小敏.课程与教学论·生物东北师范大学2010（学位年度） [2]中国自然科学类博物馆五十年发展史. 作者：董远军.科学技术史华南农业大学2009（学位年度）

中国历史文献学的发展历程

中国历史文献学的发展历程 中国历史文献学是一门以历史文献及其整理研究工作为研究对象的，以复原、求真和致用为主要任务的专科文献学。其研究范围主要包括：学科基本理论、历史文献及其产生发展过程、研究和整理历史文献的方法以及中国历史文献学发展史。他从属于历史学，具有综合性、基础性和实践性的突出特点。作为一门古老而又年轻的学科，中国历史文献学面临着加强学科理论建设、实现研究手段现代化等多重任务和发展趋向。 一、文献与历史文献 文献二字联成一词，最早见于《论语·八佾篇》。该篇记载：“子曰：‘夏礼吾能言之，气不足征也；殷礼吾能言之，宋不足征也。文献不足故也。足，则吾能征之矣。’”汉宋学者注疏时都把“文”释为典籍，“献”释为贤人或贤人言论。最早以“文献”名书的是宋末元初的马端临，他写了一部贯通历代典章制度的著作，取名为《文献通考》。在《自叙》中他解释说：“凡叙事，则本之经史而参之以历代会要，以及百家传记之书。信而有征者从之，乖异传疑者不录，所谓文也。凡论事，则先取当时臣僚之奏疏，次及近代诸儒之评论，以至名流之言谈、稗官之记录，凡一话一言，可以订典故之得失，证史传之是非者，则采而录之，所谓献也。” 从孔子到马端临，随着社会的发展和学术的进步，特别是书写工具的改进与印刷术的发明和广泛运用，贤者的言谈高见很容易见诸笔

端，各种口头传说和议论也逐渐通过各种书面的形式记录下来，于是人们越来越重视典籍而轻视传闻，相应地“文献”也由一个联合式的合成词逐渐向偏义复合词的方向演变。这里，需要指出的是马端临将文献的内容区分为“叙事”和“论事”两大类，并且将两者并重，对我们是有启发意义的。白寿彝先生认为历史文献有记注和撰述之别，记注即历史记录，而撰述要有史识。，在发现一件不经常见的文献，往往表现得相当激动，而对于历史的撰述的重要性，往往估计不足。这是带有片面性的。 今人对“文献”的理解，，归纳起来大致有两类：一类是文史学界的文献概念，如郑鹤声、郑鹤春称：“结集、翻译、编纂诸端，谓之文，审订、讲习、印刻诸端谓之献。”王欣夫认为：“文献指一切历史性的材料。 张舜徽先生认为：“‘文献’既是一个旧名词，自有它原来的含义和范围。我们今天既要借用这一名词，便不应抛弃它的含义而填入别的内容。近人却把具有历史价值的古迹、古物、模型、绘画，概称为历史文献，这便推广了它的含义和范围，和‘文献’二字的原意是不相符合的。当然，古代实物上载有文字的，如龟甲、金石上面的刻辞，竹简缯帛上面的文字，便是古代的书籍，是研究、整理历史文献的重要内容，必须加以重视。至于地下发现了远古人类的头盖骨或牙齿，那是古生物学的研究范围；在某一墓葬中出土了大批没有文字的陶器、铜器、漆器等实物，有必要考明其形制、时代和手工艺的发展情况，那是古器物学的研究范围。这些都是考古学家的职志，和文献学

专利信息检索(专利文献信息基础(2012版)试卷一)——64分

专利文献信息基础（2012版）试卷一 64分 (共16道题，共100分，限时：180分钟，还剩86分钟14秒) 多选题 1. 要检索“通用电气公司”在中国申请的有关“医用核磁共振成像”的技术主题，该技术主题对应的IPC类号为A61B5/055，应该（）。 (5分) A. 在“分类号”中输入：A61B5/055，同时在“申请（专利权）人”中输入：通用电气 B. 在“优先权”中输入：医用and 核磁and共振成像，同时在“申请（专利权）人”中输入：通用电气 C. 在“主分类号”中输入：A61B5/055，同时在“申请（专利权）人”中输入：通用电气 D. 在“摘要”或“名称”中输入：医用and 核磁and共振成像，同时在“申请（专利权）人”中输入：通用电气 2. 要检索有关稀土荧光材料的国外专利信息，可通过以下哪些途径进行？ (5分) A. 查找“稀土荧光材料”对应的英文主题词，用英文词在“espacenet”数据库中进行检索； B. 用“稀土荧光材料”的中文主题词查出一些中国专利文献，然后照出所对应的IPC分类号；用分类号在“espacenet”数据库中进行检索； C. 查找国外有关公司的名称，用公司的名称在“espacenet”数据库中进行检索； D. 查找“稀土荧光材料”对应的英文主题词，通过查阅科技文献。 3. 某公司的主要产品是稀土荧光材料，为了进一步提升产品的技术含量，该公司准备开发新型稀土荧光材料。在开发之前，公司欲进行专利信息的全面检索，以便为开发提供一些参考。此时该公司了解到国外某

公司甲有类似产品。请问该公司可通过以下哪些途径进行专利信息检索（）。 (5分) A. 主题词——稀土荧光材料； B. 稀土荧光材料所对应的IPC分类号； C. 国外某公司甲的公司名称； D. 通过查阅科技文献。 4. 一种纤维素酶制备魔芋甘露寡糖的生产方法，该方法为：酶解、过滤、脱色、浓缩、干燥，其特征在于：按魔芋精粉1g∶80－120u酶活单位投入纤维素酶、半纤维素酶混合物，纤维素酶、半纤维素酶混合物中酶活比例为2.5－3.5∶1；酶解终止后依次采用离心过滤、膜过滤，得到甘露寡糖混合液和滤渣；离心过滤除掉粗渣，超滤膜过滤得到甘露寡糖混合液，去掉大分子；所用的过滤膜的孔径为2－10微米。该技术主题对应的IPC类号为C12P19/00，其类名为：含有糖残基的化合物的制备。请问检索与该技术主题“纤维素酶制备魔芋甘露寡糖”有关的专利信息，应该通过以下哪些检索策略进行最全面检索？ (5分) A. 纤维素酶and 魔芋and 甘露寡糖； B. C12P19/00 and (甘露寡糖or魔芋or纤维素酶)； C. 纤维素酶and 魔芋甘露寡糖； D. C12P19/00 and纤维素酶and 魔芋甘露寡糖。 5. GE公司在中国申请的专利CN95190062.5，它是（）途径申请中国专利的。 (5分)

文献综述的主要方法

文献综述的主要方法 文献综述抽取某一个学科领域中的现有文献，总结这个领域研究的现状，从现有文献及过去的工作中，发现需要进一步研究的问题和角度。 文献综述是对某一领域某一方面的课题、问题或研究专题搜集大量情报资料，分析综合当前该课题、问题或研究专题的最新进展、学术见解和建议，从而揭示有关问题的新动态、新趋势、新水平、新原理和新技术等等，为后续研究寻找出发点、立足点和突破口。 文献综述看似简单．其实是一项高难度的工作。在国外，宏观的或者是比较系统的文献综述通常都是由一个领域里的顶级“大牛”来做的。在现有研究方法的著作中，都有有关文献综述的指导，然而无论是教授文献综述课的教师还是学习该课程的学生，大多实际上没有对其给予足够的重视。而到了真正自己来做研究，便发现综述实在是困难。 约翰W.克雷斯威尔（John W. Creswell）曾提出过一个文献综述必须具备的因素的模型。他的这个五步文献综述法倒还真的值得学习和借鉴。 克雷斯威尔认为，文献综述应由五部分组成：即序言、主题1（关于自变量的）、主题2（关于因变量的）、主题3（关于自变量和因变量两方面阐述的研究）、总结。 1. 序言告诉读者文献综述所涉及的几个部分，这一段是关于章节构成的陈述。在我看也就相当于文献综述的总述。 2. 综述主题1提出关于“自变量或多个自变量”的学术文献。在几个自变量中，只考虑几个小部分或只关注几个重要的单一变量。记住仅论述关于自变量的文献。这种模式可以使关于自便量的文献和因变量的文献分开分别综述，读者读起来清晰分明。 3. 综述主题2融合了与“因变量或多个因变量”的学术文献，虽然有多种因变量，但是只写每一个变量的小部分或仅关注单一的、重要的因变量。 4. 综述主题3包含了自变量与因变量的关系的学术文献。这是我们研究方案中最棘手的部分。这部分应该相当短小，并且包括了与计划研究的主题最为接近的研究。或许没有关于研究主题的文献，那就要尽可能找到与主题相近的部分，或者综述在更广泛的层面上提及的与主题相关的研究。 5. 在综述的最后提出一个总结，强调最重要的研究，抓住综述中重要的主题，指出为什么我们要对这个主题做更多的研究。其实这里不仅是要对文献综述进行总结，更重要的是找到你要从事的这个研究的基石（前人的肩膀），也就是你的研究的出发点。 在我看来，约翰.W.克雷斯威尔所提的五步文献综述法，第1、2、3步其实在研究实践中都不难，因为这些主题的研究综述毕竟与你的研究的核心问题有距离。难的是第4步，主题3的综述。难在哪里呢？一是阅读量不够，找不到最相