![CR Categories and Subject Descriptors D1.5 [Software] Programming](https://img.doczj.com/imge9/0706trkpanbfoiysn744-91.webp)
![CR Categories and Subject Descriptors D1.5 [Software] Programming](https://img.doczj.com/imge9/0706trkpanbfoiysn744-72.webp)
R E V E R S E E N G I N E E R I N G
B Y V I S U A L I Z I N G A N D Q U E R Y I N G
A. M ENDELZON
Computer Systems Research Institute, University of Toronto, Toronto M5S 1A1, Canada
J. S AMETINGER
CD Laboratory for Software Engineering, Institut für Wirtschaftsinformatik, University of Linz, Altenbergerstr. 69, A-4040 Linz, Austria*)
CR Categories and Subject Descriptors: D1.5 [Software]: Programming Techniques—Object-oriented Programming; D2.8 [Software Engineering]: Metrics—Complexity Measures; D2.10 [Software Engineering]: Design—Representation.
General Terms: Software Maintenance, Reverse Engineering, Visualization. Additional Key Words and Phrases: Metrics, Constraints, Design Patterns, Object-oriented Programming.
Please send correspondence and proofs for correction to
Johannes Sametinger
CD Laboratory for Software Engineering, Institut für Wirtschaftsinformatik, University of Linz, Altenbergerstr. 69, A-4040 Linz, Austria
E-Mail: sametinger@swe.uni-linz.ac.at
Tel.: ++43/732/2468/9435
Fax: ++43/732/2468/9430
*)This work has been done during a research visit at the Computer Systems Research Institute of the University of Toronto.
R E V E R S E E N G I N E E R I N G
B Y V I S U A L I Z I N G A N D Q U E R Y I N G
S u m m a r y
The automatic extraction of high-level structural information from code is impor-tant both for software maintenance and reuse. Instead of using special purpose tools, we explore the use of a general purpose data visualization system called Hy+ for querying and visualizing information about object-oriented software systems. Hy+ supports visualization and visual query of arbitrary graph-like databases. We store information about software systems in a database and use the general purpose tool Hy+ for analyzing the source code and visualizing various relationships. In this paper we demonstrate the use of Hy+ for evaluating software metrics, ve-rifying constraints, and identifying design patterns. Software metrics can be used to find components with low reusability or components that are hard to understand. Checking the source code against constraints can help bring design flaws to l i g h t, eliminate sources of errors, and guarantee consistent style. Identifying design pat-terns in a software system can reveal design decisions and help in understanding the code. We conclude that the flexibility achieved by using a general purpose s y-stem like Hy+ give this approach advantages over special purpose reverse-enginee-ring tools, although specialized tools will have better performance and more know-ledge of specific software engineering tasks. Combining the advantages of the t w o approaches is an interesting challenge.
Program comprehension plays a major role in software maintenance. The increased reuse of software components facilitated and supported by object-oriented programming makes program comprehension even more important, as existing software must be un-derstood both during development and maintenance.
Very often the only information a programmer can trust is the source code. It is the only accurate, complete and up-to-date representation of a program. However, source code listings are hardly suited to represent design decisions, global system structure, or in-teractions among components. The extraction of high-level structural information from code, called reverse engineering (Chikofsky et al., 1990), is important both for soft-ware maintenance and reuse.
Analyzing the source code can help to find components with certain properties, to find possible bottlenecks and weak points of a system, to identify components and their re-lationships, and to better duplicate the chain of reasoning of the original authors. Software metrics can be used to find components with low reusability or components that are hard to understand. Checking the source code against various constraints can help to bring design flaws to light, to eliminate sources of errors, and to guarantee con-sistent style. Identifying design patterns in a software system can reveal important facts about the design.
A large amount of information together with complex relationships among various ob-jects characterizes most of today's software systems. Tool support is indispensable for successful analysis. Instead of developing several tools for the various activities men-tioned above, we have used a general purpose tool for visualizing and querying soft-ware structure. Besides saving the effort of developing separate tools, this has the ad-vantage that a general purpose tool can easily be extended for future applications. We chose the Hy+ and Graphlog system (Mendelzon, 1993) because of its power and high flexibility. In this paper we demonstrate the power of visualizing and querying in the reverse engineering domain by applying the Hy+ visualization system and Graphlog vi-sual query language to the specification of metrics, constraints and design patterns. In Section 2 we introduce Hy+ and Graphlog. In Section 3 we discuss software metrics, in Section 4 constraints, and in Section 5 design patterns. We conclude in Section 6.
1 . H Y+ A N D G R A P H L O G
The Hy+ system is a generic tool for visualizing objects and relationships among them. Hy+ supports a novel visual query language called GraphLog.
Hy+ provides a user interface with extensive support for visualizing structural (or rela-tional) data as hygraphs(Consens et al., 1994), an extension of graphs inspired by Harel's higraphs (Harel, 1988). For simplicity, in this paper we only use standard di-rected graphs, a subset of the hygraph formalism.
The Hy+ system supports visualization of the actual database instances, not just dia-grammatic representations of the database schema. The use of a query language is es-sential in making this approach scale up to large database instances. This is accomplis-hed in two ways.
The first one is the ability to define new relationships by using queries. This is the tra-ditional way of using database queries: the newly defined relationship either gives a direct answer to a user question, or it provides a new view on the existing data. The derived data can later be presented visually by the system. In this way, users can abstract irrelevant details or aggregate information into visualizations of manageable size.
The second capability is a way of using queries to decide what data to show. The user can selectively restrict or filter (Consens et al., 1994) the information to be displayed. Selective data visualization can be used to locate relevant data, to restrict visualization to interesting portions of the data (that is, deciding what data to present) and to control the level of detail at which the data is presented (that is, to choose how to see the data).
To specify queries, Hy+ supports a visual pattern-based notation. The patterns are ex-pressions of the GraphLog query language. We give a short introduction to GraphLog here; a full definition can be found in (Consens, 1989 and Consens et al., 1990). In the remainder of the paper, we will introduce the basic functionality of GraphLog through examples. These examples demonstrate the application of GraphLog to compute soft-ware metrics, verify constraints, and find design patterns in a database describing the structure of an object-oriented software system.
Hy+ databases are graphs whose nodes are labeled with ground terms and whose edges are labeled with predicates. Database instances of the object-oriented or relational model can easily be visualized as graphs. For example, an edge labeled p(X) from a node labe-led T_1 to a node (containing a node) labeled T_2 corresponds to tuple (T_1, T_2, p(X)) of relation p in the relational model. No key is associated with the relation p.
For example, suppose we have a database containing all classes and methods of some software system we want to explore. This database can be viewed by Hy+ as a graph in which the nodes represent software objects such as classes and methods and the edges represent relationships. A node is labeled by a Prolog-like term, in which functors are used for typing purposes. For example, a method node might be labeled by a two-place functor method(Name, Class) giving the name of the method and the name of the class in which it appears. Methods with the same name appearing in different classes will be represented by different nodes. Edges are labeled by predicates of the form p(F1, ..., FN), where the Fi's are terms. The meaning of a predicate p(F1, ..., FN) between a node labeled F and a node labeled G is the literal p(F, G, F1, ..., FN). The frequent case where relationships are binary and have no extra attributes is represented by labe-ling the edge with just the predicate name p. For example, each link in the inheritance hierarchy is represented by an edge labeled superclass between two classes. Additionally, a method edge exists to connect classes and their methods. Chapter 6
describes in more detail the contents of the database and how it is automatically con-structed from the system's source code. Hy+ provides different ways of visualizing such a graph and manipulating the visualizations; more information on this functionality can be found in (Consens et al., 1994). Figure 1 shows a small portion of such a data-base.
GraphLog queries are sets of graphs whose nodes are labeled by terms, and each edge is labeled by an edge label. Node labels can be more general than those in database graphs, because they can include variables; edge labels may not only include variables, but also regular expressions. An edge in a query graph may match a path in the database graph, where the labels along the path are constrained by the regular expression.
Fig. 1: Visualization of a sample database
There are two types of queries: define and filter. In both, the query hygraph represents a pattern; the query evaluator searches the hygraph designated as the database for all occurrences of that pattern. The difference between the two types of queries stems from their interpretation of distinguished elements, explained below.
A hygraph pattern in a define query (which is enclosed in a defineGraphLog box) must have only one distinguished edge labeled by a positive literal. The meaning of the [define] query hygraph is to define the predicate in this distinguished literal in terms of the rest of the pattern. The semantics of define queries is given by a translation to strati-fied Datalog (Consens, 1989). Each define graph translates to a rule with the label of the distinguished edge in the head, and as many literals in the body as there are non-distinguished edges in the graph. Additional rules may be necessary to define the predi-cates of non-distinguished edges that are labeled by regular expressions. The generation of these additional rules is based on the structure of the regular expression. Figure 2 shows how the relation subclass can be defined using the relation superclass.
Fig. 2: Define query Fig. 3: Filter query
A graph pattern in a filter query (which is enclosed in a showGraphLog box) may have several distinguished nodes and edges. The meaning of a filter query graph is: for each
instance of the pattern found in the database, retain the database objects that match the distinguished objects in the query. Given a graph in a showGraphLog box, for each distinguished edge, we generate a set of define queries that match the distinguished ob-ject, that is, when they are evaluated they determine all instances of the edge that exist in the portions of the database that match the hygraph pattern. The query evaluator evalua-tes each of the define queries in turn. The results are combined, and the answer to the filter query is found. Figure 3 shows a very simple filter query.
GraphLog has the ability to collect multisets of tuples and to compute aggregate functi-ons on them. The aggregate functions supported in GraphLog are the unary operators MAX, MIN, COUNT, SUM, and AVG. They are allowed to appear in the arguments of the distinguished relation of a define query as well as in its incident nodes. As an example of the use of aggregation in GraphLog, consider the defineGraphLog box of Fig. 4. It defines the relation coupled between two classes. The relation coupled(C1, C2, N)) is defined between C1 and C2, when class C1 has a total of N variables of type C2.
Fig. 4: Aggregate function in a query
2 . M E T R I C S
Measures about the size and complexity of software systems are helpful for estimating costs and schedules, improving software quality, and anticipating and reducing future maintenance requirements (Chidamber et al., 1991). Software metrics are desired by software managers for project planning and evaluation, and can be used to enforce quality-assurance.
In the reverse engineering process extracting measures from an existing software sy-stem can help in finding candidates for
?components with low reusability
Classes with a large number of methods are more likely to be application specific and thus less reusable than others. If this is not the case they might be candidates for a redesign.
?components that require extensive testing
Errors in leaf classes are more local than in classes with many children (subclasses).
The greater the number of code lines is in a method, the greater is the probability of an error in that method.
?components that are hard to understand
Encapsulation is important for hiding details and prohibiting unallowed access to the details of certain components. Inter-object coupling should be kept to a minimum.
Understanding and testing of highly coupled classes tends to be more difficult. Metrics oriented towards object-oriented systems can also aid in evaluating the degree of object-orientation. This becomes important considering the need for many conven-tional programmers to switch to object-oriented thinking.
Environments for the evaluation of metrics do exist. For example, ATHENA allows easy implementation of design and code metrics with a specially designed specification language (Tsalidis et al., 1992). We did not try to support the measure of well-known metrics like McCabe or Halstead. Their benefit in object-oriented systems is less impor-tant than in conventional ones, because the complexity of these systems shifts from statements and functions to components and their interactions.
With Graphlog's ability to specify arithmetic expressions in queries it is a rather straight-forward process to evaluate various metrics. We will demonstrate on a simple example how easy it is to extract measures from (both object-oriented and conventional) software systems.
In object-oriented systems dynamic binding complicates the comprehension process, because sending a message can cause the invocation of many methods. Suppose we want to know all those methods (and their corresponding classes) of which a call can result in more than, let's say, 20 different method calls; i.e., we want to know whether a certain method is overridden in more than 20 subclasses, because tracing the control flow in that case is understandably difficult. Let us see how we could find such me-thods using Hy+ and Graphlog.
To find methods that are overridden in more than 20 subclasses, suppose first that our database contains an edge labeled ovCount, that connects each method M to a node la-beled with the number of methods that override M. Then all we need to do is filter out from the graph those methods connected by an ovCount edge to an integer greater than 20. Fig. 5 shows a filter query that does this.
Fig. 5: Filtering methods with ovCount>20
Recall a filter query is interpreted as a graph pattern; for each instance of the pattern found in the database, the distinguished (bold) objects are retained and displayed as part of the answer. In this example, the pattern requires methods M that are overridden by a number NR of methods, where NR>20; the distinguished object is just the ovCount edge. The answer, shown in Fig. 6, will be a set of edges connecting all methods of interest to the count of methods that override them.
Fig. 6: Result of the ovCount query
Instead of just showing how many times each method is overridden, we would pro-bably be interested in knowing in which classes the overrides occur. To see this, we simply add to the filter query another method node M2 and a distinguished overrides edge from M2 to M. To avoid a too complex answer for this paper we additionally spe-cify the method name Draw of class VObject instead of M in Fig. 7, thus restricting the answer to overriding methods of this particular method. The answer, shown in Fig. 8, will then show all the classes where each of the methods of interest is defined or redefi-ned. In this case, we can see that method Draw of class VObject is overridden 32 times (ovCount). On the left side all the overriding methods are listed.
Fig. 7: Extended filter query
Fig. 8: Result of filter query in Fig. 7
We could add even more information by adding a separate showGraphLog box reque-sting that the subclass hierarchy be also displayed, as shown in the left box of Fig. 9. C1 is a direct or indirect subclass of class CompositeVObject, which is indicated by the use of transitive closure in the regular expression subclass+. The transitive closure is drawn dashed to indicate that it may match a path of arbitrary length in the database, not just an edge. For the resulting nodes the subclass relationship is shown in the answer (indicated by the distinguished subclass relation to C2). And again we restrict the query to a certain subclass hierarchy (class CompositeVObject) in order to get an answer that is not too complex to be clearly shown in this paper. The answer is in Fig. 10.
Fig. 9: Filter query for additionally displaying the subclass hierarchy
Fig. 10: Result of the query specified in Fig. 9
Unfortunately, the relations overrides and ovCount do not exist in our database. But with Graphlog we can easily define new relations based on existing ones. (This gives us the flexibility to define arbitrary metrics.) Thus, in Fig. 11 we define ovCount as being the number of methods M1 that override M2. Note that this is a define query. The distinguished object, i.e., the one being defined, is the ovCount relationship. This query also shows the use of aggregation, in this case to count, for each method M2, how many methods M1 override it.
Fig. 11: Definition of the relation ovCount
Finally, we define the relation overrides. A method in class C1 overrides another me-thod in class C2 if both have the same name (without taking parameters into account), and C1 is a superclass of C2. This fact is expressed by drawing two classes (see Fig.
12) each with a method named M. C2 is a direct or indirect superclass of C1, which is indicated by the use of transitive closure in the regular expression superclass+. And, of course, C1 and C2 have to be different. This is ensured by drawing a non-equals edge between them. The crossing-out of an edge is GraphLog's general mechanism to indi-cate negation.
Fig. 12: Definition of the relation overrides
As result of the query described above we obtain the graph shown in Fig. 6 shown above. The methods are specified by name of method and name of class. Thus, the methods PrintOn of class EvtHandler and ReadFrom of class VObject are overridden by 28 methods, and so on.
Examples for metrics that can be specified in a very similar way include:
?methods per class
?depth of inheritance
?number of children (subclasses)
?coupling between objects
?response for a class
?lines of code (for classes, methods, functions, files)
?number of methods (for clients/heirs/friends)
?number of (instance) variables
?number of strongly coupled classes
These metrics are targeted at the source code only. It is often argued that monitoring metrics after coding is far too late in a software project. It is possible with Hy+ to shift the focus to other software artifacts, e.g., requirement specification. However, it has not been our goal to provide a general software metrics tool with Hy+, but rather to use its flexibility for program comprehension and reverse engineering purposes.
We have used Hy+ to extract measures from a large C++ class library in order to easily find out things listed above. The library (application framework) ET++ (Weinand et al., 1989) has been made by rather experienced programmers. Therefore, it was not our goal to detect flaws but rather to support the comprehension process by visualizing the system structure and to give prominence to classes and methods with certain characte-ristics. On the other hand, querying student projects helped in locating sources of trou-ble, which were then discussed in order to improve the design and/or eliminate existing flaws.
3 . C O N S T R A I N T S
With most programming languages we are not able to express many important con-straints about our software systems. Such constraints contain design, implementation and stylistic conventions and are necessary to improve software quality like reliability, maintainability, and readability. Automatic detection of violations can help to ensure project or company wide styles for programs, and to eliminate a variety of sources of troubles. In the software maintenance and also the reverse engineering process this is important as well (Chowdhury et al., 1993).
There are different ways to detect constraint violations. Assertions or annotations are available for various languages like Ada, Eiffel, and C++. CCEL, the C++ Constraint Expression Language, is a very powerful language, that allows users to specify and automatically detect violations of C++ constraints (Meyers et al., 1993).
The following constraints are taken from (Chowdhury et al., 1993), (Meyers, 1992) and (Meyers et al., 1993), where they are explained in more detail. We will list some examples for design, implementation, and stylistic constraints.
D ESIGN C ONSTRAINTS
Design constraints are not specific to a certain programming language. They can, ho-wever, be specific to certain libraries and/or applications. Typical examples are:?Subclasses must not redefine inherited non-virtual method.
? A method in a certain class must be overridden in all subclasses of that class.
? A class should not have any public data members (encapsulation).
?Structures in C++ should not be used like classes, i.e., they should have only pu-blic members, no methods and should not have a base class.
I MPLEMENTATION C ONSTRAINTS
Implementation constraints are design-independent. Violations against them can lead to incorrect program behavior. Thus, it makes sense to have a closer look at locations where implementation constraints are violated. Typical examples are:
?An assignment operator and a copy constructor must be defined for classes that de-clare a pointer member.
?Every base class should declare a virtual destructor.
?Every class with a constructor should declare a destructor and vice-versa.
?If there exist multiple public inheritance paths from a derived class to one of its base classes, then all these paths should be declared virtual.
S TYLISTIC C ONSTRAINTS
Some set of naming conventions are adopted in almost all software projects. They are intended to increase the readability of software systems. Typical examples are:?Class and method names must begin with an upper case letter.
?Constants and global variables must begin with the lower case letters 'c' and 'g', respectively.
?Public, protected and private members of a class must be specified in this order.?Variable (or any other) names may not contain any underscore characters ("_"), or two consecutive underscore characters ("__").
The power of Hy+ and Graphlog depends on the database being queried. Basically, we are able to check against all constraints that can, for example, be specified with CCEL. However, we have to admit, that for efficiency reasons we do not store as much infor-mation as would be necessary to compete with CCEL. But in contrast to CCEL we gra-phically define queries in order to find violations against various constraints. And addi-tionally, we do not need a special language and a separate, constraint specific tool. We are currently working on investigating also the dynamic behaviour of object-oriented software systems. Whereas CCEL is limited to check against static information we will be able to process dynamic information as well.
Finding stylistic constraints is rather trivial, because in Graphlog we can use regular expressions. Fig. 13 shows how to simply find classes which start with a lower case letter and therefore violate one of the stylistic constraints mentioned above.
Fig. 13: Definition of classes with lower case letters
A more complex, but still simple example is how to find classes that redefine non-vir-tual methods (design constraint). For that purpose we need the relation overrides defi-ned in Fig. 12. In C++ it is sufficient (and necessary) that the first method in the inheri-tance path is declared as virtual. We define the relation overridesVirtual between a me-thod M3 and a method M2 if M3 overrides M2 and M2 overrides another method M1 which is virtual (see Fig. 14). The attributes node contains information about a method; virtual(yes) indicates that the method has been defined as virtual.
Fig. 14: Definition of the relation overridesVirtual
Next, we can simply define the relation overridesNonVirtual, see Fig. 15. Method N overrides a non-virtual method M when N overrides M and the relation overridesVirtual does not hold between M and N.
Fig. 15: Definition of methods that override non-virtual methods
We have been rather successful in checking student projects against constraint violati-ons. This is not surprising. For example, our students liked to have public data mem-bers, hardly ever implemented a copy constructor or an assignment operator, and some of them did not clean up their systems with destructors. This has become better now, because we explicitly mention these points in the lectures.
However, one of the amazing facts was that there were constraint violations in the fra-mework ET++ that could lead to incorrect program behavior, although the framework had been in use by many programmers for years. We found two classes with non-vir-tual methods that were overridden in subclasses. Additionally, in ET++ classes assign-ment operators are not defined. However, this is not a problem as long as all objects are declared as being pointers. But users of the framework could run into troubles.
4 . D E S I G N P A T T E R N S
Reverse engineering involves the identification of groups of building blocks like modu-les and subsystems. For example, the Rigi system gives support for subsystem struc-ture identification (Müller, 1993). In object-oriented systems the identification of modu-les, i.e., classes, becomes obsolete. Thus, we tried to go one step further by identifying design patterns in a subject system. With patterns piecework is standardized to larger units. For example, a symphony consists of single notes, but various patterns (which are well-known to composers and other musicians) express the design of a piece of music. Software design patterns capture the intent behind the design of a software sy-stem. For example, many times there exists a special arrangement of classes and/or ob-jects in order to avoid reuse errors. A subsystem is a set of classes with high cohesion within themselves and low coupling to classes outside the subsystem. Design patterns can correspond to subsystems, but often they have a finer level of granularity.
Design patterns have been identified to avoid dependence on (Gamma et al., 1993):?classes when creating objects,
?particular operations,
?specific representation or implementation,
?particular algorithms, and
?subclassing as extension mechanism.
Examples of such patterns are:
?Chains of responsibility
create hierarchies of responsibilities, typically arranged from more specific to more general, amongst objects for handling a request.
?Factory methods
allow base classes to create instances of subclass-dependent objects.?Flyweights
provide stateless objects that can be shared.
?Glue objects
provide a higher level of encapsulation for subsystems by providing an interface for clients to access services of and the objects in a subsystem.
?Solitaires
are classes that have only one instance (e.g., to access unique global services and variables).
For more patterns and more details see (Gamma, 1993) and also (Coad, 1992). Research work on design patterns is still going on and it is not yet clear, which patterns will become widely accepted. But they promise to be one further step in increasing the abstraction level in software development. They can help both in improving the deve-lopment process and in recapturing design decisions behind the structure of certain parts in a system.
Recapturing design decisions is the crucial point in reverse engineering. This can be done a lot easier if existing design patterns can be identified in a given architecture. Design patterns could be made visible in software systems by special language con-structs or special conventions for comments, i.e., annotations. But such constructs or conventions won't be available as long as the fundamentals of the patterns are not clear. Besides, this would help only for identifying patterns in future software systems.
Many of the patterns published so far do not have a clear, identifiable structure. Most of them are defined by various inheritance and use relations. We tried to find some heuri-stics in order to find possible candidates for various patterns. Sometimes naming con-ventions are the only way for successful identification. The following heuristics can be used to identify the patterns presented above:
?Chains of responsibility
Classes with “Handler” (e.g., EvtHandler) or “Delegate” in their name or classes that maintain a reference to objects of the same class might be candidates for re-sponsibility chains.
?Factory methods
Possible factory methods are virtual methods containing the words “Make” or “Create”, e.g., DoMakeWindow, MakeMenus, CreateScrollbar.
?Flyweights
Any classes without state or only minimal state (<3 instance variables) are possible flyweights.
?Glue objects
We can look for subsystems that have no references to the outer world and vice versa, i.e., a class’ subclasses do not have references to classes other than themsel-ves, and classes outside this subtree do not have any references to any of these subclasses.
?Solitaires
We regard all classes as possible solitaires that have at least one static method and/or variable.
With Graphlog it is very simple to define queries in order to find possible design pat-terns with the heuristics described above. For example, the query for finding factory methods is rather trivial, all we have to do is to look for virtual methods containing the word "Make" or "Create". This is easy with Graphlog, because it not only provides arithmetic functions but also lets the user specify regular expressions.
We will demonstrate how we can easily specify the more complex query to find subsy-stems that have no references outside and vice versa. Figure 16 defines the relation pGlue, which holds for classes that do not have subclasses with a reference outside the subtree of the class (relation subclassHasRefOutside) and that do not have classes outside the subtree with a reference inside the subtree (relation notSubclassHasRefIn-
side). The superclass relations to a superclass and from a subclass indicate that we do not want to check root and leaf classes.
Fig. 16: Definition of pGlue
Next, we define the relation subclassHasRefOutside, which is true if anyone of the subclasses has a reference outside the class. For this purpose we use another relation hasRefOutside, see Fig. 17.
Fig. 17: Definition of subclassHasRefOutside and hasRefOutside
The relation isOfType has been defined in the database already. It simply indicates that the type of a variable is of a certain class. The relation notSubclassHasRefInside is very similar to subclassHasRefOutside, see Fig. 18.
Fig. 18: Definition of notSubclassHasRefInside
The output of a Graphlog query can be modeled very flexible as well. Besides simply showing the resulting methods (and corresponding classes) the result can, for example, be embedded in the inheritance tree with all classes. Figure 19 shows part of the inheri-tance tree with factory methods. On the screen different colors make the distinction between the relations superclass and factoryMethod easier.
Fig. 19: Factory methods and the inheritance tree
We have to stress that the results yielded by the design pattern queries neither contain all patterns in a software system nor contain only patterns. The heuristics used are helpful in finding possible candidates for certain patterns, i.e., the final decision can be made only by looking at the source code.
We tried to identify design patterns in the application framework ET++. Although we have not been able to define heuristics for all patterns we were able to extract useful in-formation for the comprehension process. For example, a lot of factory methods could be identified that even programmers who were familiar with the inspected class library were not aware of. Factory methods are available not only for application, document and dialog classes, which are used by application programmers, but also for system, window and printer classes, which have not to be extended in order to build applicati-ons. In student projects we have never found any of these design patterns. This stems from the fact that they are not experienced enough to make good (excellent?) designs, their projects are rather small, and they know nothing about these patterns because they have to learn more fundamental things.
The Graphlog queries we used so far are custom tailored to the application framework ET++. More research work has to be done on the design patterns and, subsequently, on the heuristics and queries in order provide users with a powerful tool for extracting de-
sign decisions from a given software system.
5 . D E F I N I N G T H E D A T A B A S E F O R R E V E R S E
E N G I N E E R I N G P U R P O S E S
Information about a software system can be obtained by doing syntax and semantics analysis and storing everything a compiler has to know about a system, i.e., structural information (classes, methods) as well as detailed information about the definition and the use of any identifiers. One possible way to get this information is to extend any tool that has information about a software system, e.g., a compiler or a programming envi-ronment, in order to output the desired information in the desired format. We extended the programming environment DOgMA (Sametinger, 1992) to generate structural in-formation in the GXF format (Eigler, 1993), which can be read by Hy+. Hy+ stores both databases and queries in the GXF format, see Fig. 20.
Fig. 20: Architectural overview
We tried to keep the database very simple, reducing the amount of information where-ver possible, trying to find a good compromise between less information, that can easily and efficiently be retrieved from software systems, and still useful queries, that allow software engineers to support their comprehension process.
For the queries described in this paper we used the following information in our data-base:
?classes:class name, line numbers, super classes
?methods method name, class name, line numbers, virtual, scope ?variables:variable name, class name, line number, reference, scope, type ?files file name, number of lines
The number of metrics, constraints and design patterns that can be evaluated, checked and identified, respectively, depends on the amount of information in the database. With the information shown above we cannot, for example, determine the metric lack of cohesion in methods, see (Chidamber et al., 1991). Also, some constraints listed in
(Meyers, 1992) require information about parameter types and single statements, e.g., constraints on the assignment operator:
?do not return a reference to *this
?assign a value to all data members
?do not assign a value to self
?return type must be a reference to the class
It is not possible to check for these constraints without the necessary information. With little effort, however, this and other information can be added to the database as well. In contrast to metrics and constraints, more information in the database would not help much in recognizing more design patterns. To achieve better results we need more rese-arch work being done on the design patterns themselves.
6 . C O N C L U S I O N
The importance of program comprehension, the necessity of getting familiar with unknown source code, and extracting information from low level data increases with the object-oriented programming paradigm. The comprehension process could additio-nally benefit from extending the database and finding more valuable queries. Especially, taking dynamic behavior into consideration could bring new insights.
Reverse engineering activities become necessary not only for maintenance but also for development purposes. With Hy+ and Graphlog we have a very flexible tool that can be used for those purposes. Special purpose tools—like ATHENA, CCEL and Rigi—are custom tailored and can hardly be surpassed by general purpose tools in their applica-tion domains. However, the power of Hy+ and Graphlog lies in its universality, which makes it more easily applicable also for future formulations of questions. Additionally, the visualization and navigation features can help in mastering the complexity of large-scale software systems. In this papers we mainly focused on querying features, but Hy+ also offers a lot of functionality for adjusting the visualization of results (e.g., using fisheye views), applying filters, etc. (Consens et al., 1991) and (Mendelzon, 1993). And, even if Hy+ and Graphlog are not applicable in certain domains for per-formance reasons (which might become true when the database becomes very exten-sive), they are excellent tools for evaluating needed functionality before special purpose tools are being built.
7 . R E F E R E N C E S
Chikofsky E.J. and Cross II J.H. (1990). Reverse Engineering and Design Recovery: A Taxonomy, IEEE Software, Vol. 7, No. 1, pp. 13-17.
Chidamber S.R. and Kemerer C.F. (1991). Towards a Metrics Suite for Object Oriented Design, OOPSLA '91 Proceedings, pp. 197-211.
蓄电池放电容量测试仪产品功能 ●测试电压范围宽，覆盖10V-300V电压范围电池组放电测试，最大放电电流达到120A，用户只需要一台RTKR-8400蓄电池放电容量测试仪就可以满足多种电压等级的电池组测试，大大节约购买仪表资金，而且方便实用 ●支持恒流、恒功率、恒阻值三种放电测试模式，能满足多种测试要求。当需要检测蓄电池容量时，可以选择恒流放电模式，准确测试蓄电池组的实际容量；当需要检测蓄电池带载能力时，可以选择恒功率测试模式，准确模拟蓄电池组真实负载时的后备供电时间。恒阻值放电模式多用于直流电流输出性能检测 ●5.7英寸超大触摸屏：采用大尺寸触摸屏，可直接在屏上进行点击操作，简单明了。放电过程中可查看所有的放电参数，并且可显示单体电压柱状图 ●采用蓝牙无线单体监测模块：兼容2V/6V/12V单体电压监测
●每个无线监测模块可同时监测4个单体：相比每个模块监测一只单体电压方法，需要配置的模块数量只是其1/4（48V只需6个监测模块），让无线模块接线操作更加简便 ●在线补偿式放电功能：在线放电时，主机显示电流=电池组放电电流=主机内部假负载电流+实际负载电流，由于在线放电时实际负载电流会随着在线电压的变化而变化，主机内部假负载电池也会自动进行调整，以保证蓄电池组一直以真正的恒流方式放电 ●单体电压停机门限可设置多节：如此可在一次连续不中断的放电测试中发现多节落后单体电池 ●功耗部分采用航空合金电热元件：电热转换效率高，安全系数高，体积小、重量轻 ●放电电流自动计算功能：内置各小时率放电系数，可放电根据被测电池的标称容量和需要的放电率来自动计算需要设置的放电电流 ●测试过程中，各单体电压实时检测和显示：并在主机屏幕上呈现出各单体电压柱状图的变化轨迹，还能自动实时呈现出电压最高与最低的单体，帮助您快速分析单体变化的趋势●放电参数预设功能：允许预先内置多达8种常用的放电参数设置，很多情况下无须重新设置放电参数，方便使用者放电操作，加快测试速度。使用者也可以对内置的预放参数进行修改 蓄电池放电容量测试仪技术参数
2018全国生物卷（Ⅱ卷） 1．下列关于人体中蛋白质功能的叙述，错误的是 A．浆细胞产生的抗体可结合相应的病毒抗原 B．肌细胞中的某些蛋白质参与肌肉收缩的过程 C．蛋白质结合Mg2+形成的血红蛋白参与O2运输 D．细胞核中某些蛋白质是染色体的重要组成成分 2．下列有关物质跨膜运输的叙述，正确的是 A．巨噬细胞摄入病原体的过程属于协助扩散 B．固醇类激素进入靶细胞的过程属于主动运输 C．神经细胞受到刺激时产生的Na+内流属于被动运输 D．护肤品中的甘油进入皮肤细胞的过程属于主动运输 3．下列有关人体内激素的叙述，正确的是 A．运动时，肾上腺素水平升高，可使心率加快，说明激素是高能化合物 B．饥饿时，胰高血糖素水平升高，促进糖原分解，说明激素具有酶的催化活性 C．进食后，胰岛素水平升高，其即可加速糖原合成，也可作为细胞的结构组分 D．青春期，性激素水平升高，随体液到达靶细胞，与受体结合可促进机体发育 4．有些作物的种子入库前需要经过风干处理。与风干前相比，下列说法错误的是
A．风干种子中有机物的消耗减慢 B．风干种子上微生物不易生长繁殖 C．风干种子中细胞呼吸作用的强度高 D．风干种子中结合水与自由水的比值大 5．下列关于病毒的叙述，错误的是 A．从烟草花叶病毒中可以提取到RNA B．T2噬菌体可感染肺炎双球菌导致其裂解 C．HIV可引起人的获得性免疫缺陷综合征 D．阻断病毒的传播可降低其所致疾病的发病率 6．在致癌因子的作用下，正常动物细胞可转变为癌细胞。有关癌细胞特点的叙述错误的是 A．细胞中可能发生单一基因突变，细胞间黏着性增加 B．细胞中可能发生多个基因突变，细胞的形态发生变化 C．细胞中的染色体可能受到损伤，细胞的增殖失去控制 D．细胞中遗传物质可能受到损伤，细胞表面糖蛋白减少 29．（8分）为研究垂体对机体生长发育的作用，某同学用垂体切除法进行实验。在实验过程中，用幼龄大鼠为材料，以体重变化作为生长发育的检测指标。回答下列问题： （1）请完善下面的实验步骤 ①将若干只大鼠随机分为A、B两组后进行处理，A组(对照组)的处理是_____________；B组的处理是_____________。 ②将上述两组大鼠置于相同的适宜条件下饲养。 ③___________。
雅思口语part2话题万能模板：事件类今天三立在线教育雅思网为大家带来的是雅思口语part2话题万能模板：事件类的相关资讯，备考的烤鸭们，赶紧来看看吧！ 首先我们来说说“一件从数学中学到的事情”，拿到这个话题，先不要急着回答，可以用笔稍微构思一下思路，该怎么回答。首先，可以说一下这件事是什么、发生在什么时候，也就是作文中的事件和事件，这里需要注意的就是具体描述一下什么事但是又不能啰嗦累赘，而时间则可以大致概括点明即可。我们就从资料中的例子来说：高中的时候从乘法表中学到的一件事。 然后，要具体叙述一下这件事，即是最重要的部分，发生的地方、牵扯到的人物、以及这件事情影响到你的原因，为什么影响到你…… 资料例子来说：在高中的一次数学竞赛中失败，以至于灰心丧气，甚至对自己产生怀疑，而此时数学老师拿乘法的规则来比喻人生中的失败与成功的关系来鼓励我，以至于我从失败中走出来，从新赢得了下一次的数学竞赛。这件事情使我明白了，生活就如同数学乘法，有无数种可能，多种多样，我们要坦然面对。 而这里的例子看似像我们中文作文中的思路，但是关键在于它表述方式以及用词造句，不能太中式化。这里的重点，就是描述事件经过，即“在高中的一次数学竞赛中失败，以至于灰心丧气，甚至对自己产生怀疑，而此时数学老师拿乘法的规则来比喻人生中的失败与成功的关系来鼓励我，以至于我从失败中走出来，从新赢得了下一次的数学竞赛。”而老师的话则是重中之重，因为他让我明白了道理“生活就如同数学乘法，有无数种可能，多种多样，我们要坦然面对。”也是我深深牢记的原因，以及这件事对我影响深刻的原因。
而最后，只需要简单概括，从这件事中学到的东西即可。其实这个话题思路并不是很难，关键在于烤鸭们的表述以及词汇的积累。 其实，大家都知道事件类话题是雅思口语考试中最简单的、最容易描述，却也是最常见的话题，所以大家要多注意积累素材、思考思路。其实“A way of communication”和“A good parent”这两个话题也可以用这个例子来阐述回答，而最关键的则是把老师的那段话稍作转述即可。例如，“A way of communication”我们可以先描述手机及其性能作用，以及现今的流行趋势，然后从一件事引到交流方式，还是那件事，还是那写话，只不过要突出老师用短信的方式告知我，最后，简单概述手机的用处及好处即可。是不是很简单呢?同样的，“A good parent”只需要根据情况把那些话转述为父母亲对你说的话，已经对你的影响，所以一个模板真的是百用哦! 那么我们赶紧来看看还有哪些话题可以这样转换呢? 多米诺骨牌效应：=Something you learned from math=Something you learned from your family=A piece of advice=A change you had=An important stage in your life=A text message you got=A letter you got=An E-mail you got=A way of communication=An important decision you made=A person who helped you=A kind thing someone did to you=A family member you love talking to=A good parent=An elderly family member=A neighbor=A good friend=A teacher=A science course you took=A subject you love/d at school=Your personality=First day of college=Your experience of getting money as a gift=Your experience of getting congratulations=A person you helped=A thing your friend did made you admire.
RTBO-4815蓄电池智能活化仪RTBO-4815Online Battery Discharge Tester 使用说明书 User's Manual 武汉锐拓普电力设备有限公司 W uhan Retop Electric Device Co.,L TD
目录 1概述(2) 1.1设备特点(2) 1.2系统组成(2) 1.3设备型号(2) 2主要技术参数(3) 3.基本工作原理(4) 4.使用与操作说明(5) 4.1设备面板说明(5) 4.2使用环境要求(5) 4.3仪器连接(5) 4.4通信故障模块修复配置(6) 4.5设备启动与参数预置(7) 4.6放电执行与监视(8) 4.7在线放电方式(9) 4.8离线放电方式(11) 4.9数据处理(12) 5故障模块修复(13) 6使用注意事项(14) 7售后服务(14) 8RTBO前台软件操作说明(15)
1.概述 1.1设备特点 在所有信息化、自动化程度不断提高的运行设备、运行网络系统中,不间断供电是一个最基础的保障.而无论是交流还是直流的不间断供电系统，蓄电池作为备用电源在系统中起着极其重要的作用。平时蓄电池处于浮充备用状态，一旦交流电失电或其它事故状态下，蓄电池则成为负荷的唯一能源供给者。 我们知道,蓄电池除了正常的使用寿命周期外，由于蓄电池本身的质量如材料、结构、工艺的缺陷及使用不当等问题导致一些蓄电池早期失效的现象时有发生。为了检验蓄电池组的可备用时间及实际容量，保证系统的正常运行，根据电源系统的维护规程,需要定期或按需适时的对蓄电池组进行容量的核对性放电测试,以早期发现个别的失效或接近失效的单体电池予以更换,保证整组电池的有效性;或者对整组电池的预期寿命作出评估. 武汉锐拓普电力设备有限公司经多年研制，以其专有技术，开发成功系列化的、智能化程度和精度极高的RTBO-4815蓄电池智能活化仪。本测试仪可在蓄电池在线状态下,作为放电负载,通过连续调控放电电流，实现设定值的恒流放电。在放电时，当蓄电组端电压或单体电压,跌至设定下限值、或设定的放电时间到、或设定的放电容量到,仪器自动停止放电,并记录下所有有价值的、连续的过程实时数据. 本测试仪系统对单体电池的电压监测信息,采用无线中继接入,简单、安全、精确. 本仪器有非常人性化的人机界面,不仅可以在菜单的提示下完成各种设置和数据查詢,而且放电的过程数据,均保存在设备的内存中,通过数据接口可以读取、转存,并通过上位机的专用软件,对数据进行分析,生成需要的曲线和报表. 本仪器有完善的保护功能,不仅有声、光告警,而且还有明确的界面提示. 本仪器体积小、重量轻、使用简单、测量精度高，规格齐全.可使用于24V、48V、72V、110V、220V、480V、600V等系列的蓄电池组。 1.2系统组成 RTBO-4815蓄电池智能活化仪是由主机、单体电池检测模块和测试电缆组成. 主机由彩色显示触摸屏、数据处理单元、数据采集单元、辅助电源单元、放电单元和面板操作单元组成. 1.3设备型号 本测试仪型号为:RTBO—XX YY 表征:RTBO—蓄电池容量测试仪型号 XX—放电电压等级 YY—放电电流等级
绝密★启用前 2017年普通高等学校招生全国统一考试（卷） 生物 1．下列关于糖类化合物的叙述，正确的是 A．葡萄糖、果糖、半乳糖都是还原糖，但元素组成不同 B．淀粉、糖原、纤维素都是由葡萄糖聚合而成的多糖 C．蔗糖、麦芽糖、乳糖都可与斐林试剂反应生成砖红色沉淀 D．蔗糖是淀粉的水解产物之一，麦芽糖是纤维素的水解产物之一 2．下列关于探索DNA 是遗传物质的实验，叙述正确的是 A．格里菲思实验证明DNA 可以改变生物体的遗传性状 B．艾弗里实验证明从S 型肺炎双球菌中提取的DNA 可以使小鼠死亡 C．赫尔希和蔡斯实验中离心后细菌主要存在于沉淀中 D．赫尔希和蔡斯实验中细菌裂解后得到的噬菌体都带有32P 标记 3．下列关于肽和蛋白质的叙述，正确的是 A．琢鄄鹅膏蕈碱是一种环状八肽，分子中含有8 个肽键 B．蛋白质是由2 条或2 条以上多肽链构成的 C．蛋白质变性是由于肽键的断裂造成的 D．变性蛋白质不能与双缩脲试剂发生反应
4．下列关于用显微镜观察细胞的实验，叙述正确的是 A．转换物镜时应该手握物镜小心缓慢转动 B．以洋葱鳞片叶表皮为材料不能观察到质壁分离 C．丹芋染色后的花生子叶细胞中可观察到橘黄色颗粒 D．在新鲜黑藻小叶装片中可进行叶绿体形态观察和计数 5．某小组开展酵母菌培养实验，下图是摇瓶培养中酵母种群变化曲线。下列相关叙述正确的是 A．培养初期，酵母因种竞争强而生长缓慢 B．转速150 r/min 时，预测种群增长曲线呈“S冶型 C．该实验中酵母计数应采用稀释涂布平板法 D．培养后期，酵母的呼吸场所由胞外转为胞 6．下列关于人类遗传病的叙述，正确的是 A．遗传病是指基因结构改变而引发的疾病 B．具有先天性和家族性特点的疾病都是遗传病 C．杂合子筛查对预防各类遗传病具有重要意义 D．遗传病再发风险率估算需要确定遗传病类型 7．下列关于生物进化的叙述，错误踿踿的是 A．某物种仅存一个种群，该种群中每个个体均含有这个物种的全部基因 B．虽然亚洲与澳洲之间存在地理隔离，但两洲人之间并没有生殖隔离 C．无论是自然选择还是人工选择作用，都能使种群基因频率发生定向改变 D．古老地层中都是简单生物的化石，而新近地层中含有复杂生物的化石 8．下图为突触结构示意图，下列相关叙述正确的是
雅思口语part2中不建议背诵范文 背诵的痕迹如果比较明显在雅思口语中是很不利的，下面一起来看看有哪些需要注意的吧！ 雅思口语part 2中不建议背诵范文 有很多同学常常觉得雅思口语考试从6分到7分是一个不可逾越的鸿沟，其实大家如果能够将自己的语言丰富一些，细节描述更多一些，获得7分以上，还是很有机会的。 对于一些描述性的雅思口语part 2题目，不少同学表示可说的内容比较少，所以在2分钟之内的表达显得干巴巴的，没有什么实质性的东西。事实上，如果能够提升自己对于细节的专注程度，在part 2的考试中能够令人眼前一亮。 我们以“描述你在特殊场合穿着的衣服”这个话题为例。如果仅仅描述一件衣服，那么可说的内容很少。但是如果我们更加专注于如何描述这件衣服的背景和增添一些比较地道的描述，那么实际的效果是大不相同的。仅以下文为例，供广大考生参考。 Describe a piece of clothing you wear on a special occasion Key points：Graduation，school，pink dress，accessory， Actually，in my high school，students are required to wear the school uniforms each day at school. Everyone looks the same to a great extent.【程度的描述】No one's special. So after a while，we all have the similar physical features. Baggy pants，oversized jackets，and big glasses on our faces，【生动的描述】of course【的语序】. Lucky enough【选取比较自然的连接词】，we had a graduation ceremony，and the high school allowed us to wear something casual 【转换词性】on that very day. For this special day，I picked up a really nice dress. My mum and I found it at an elegant shopping mall，which was stunning in the store window.【还是细节描写，而且增添了背景故事】I had my eyes on that dress immediately. It was a pink dress with a black leather belt，which was neither too fancy nor too formal.【加入形容的部分】It boasts an graceful cutting style with a U-neck shape. Somehow，it reminded me of a typical Chanel dress.【加入了西方背景知识】My mum said it might be too mature for my age，but I believe it was OK.【自然
DCE4850 智能蓄电池放电仪 一、产品特点 ● 采用蓝牙无线单体监测技术，避免了有线监测复杂的接线方式，每个无线模块都可支持 2V/6V/12V单体电压监测。 ● 每个无线监测模块可同时监测4个单体，相比每个模块监测一只单体电压方法，需要配置 的模块数量只是其1/4（48V只需6个监测模块），让无线模块接线操作更加简便。 ● 支持多组（最多4组）蓄电池组离线或在线放电测试，能同时测试到每一组蓄电池组的实 际放电电流。（同时测试多组须增加选配电流钳） ● 电流连续可调，自动保持恒定。在线放电时，主机显示电池组放电总电流=主机内部假负 载总电流+实际负载总电流，由于在线放电时实际负载总电流会随着在线电压的变化而变化，主机内部假负载总电流也会自动进行调整，以保证蓄电池组一直以真正的恒定电流放电。如果同时测试多组电池，主机上除显示放电总电流外，还会显示各组电池的实际放电电流。 ● 单体电压停机门限可设置多节，普通容量测试仪的单体电压停机门限自动默认为一节电 池，任意一节单体电池电压到达门限，主机即停止放电，而本容量测试仪可人工设定N节单体电池电压达到停机门限才停止放电，如此可在一次连续不中断的放电测试中发现多节落后单体电池。 ● 可并接多台小巧的恒流扩展模块，满足更大放电电流的需要，主机可控制恒流模块同时启 动和同时停止。 ● 功耗部分采用航空合金电热元件，电热转换效率高，安全系数高，体积小、重量轻； ● 放电电流自动计算功能，内置各小时率放电系数，用户可根据被测电池的标称容量和所需 要的放电小时率来自动计算需要设置的放电电流大小。 ● 智能菜单式操作，使用者无需培训，即可轻松操作。 ● 英寸超大触摸屏：采用超大触摸屏，可直接在屏上进行点击操作，简单明了。放电过程中 可查看所有的放电参数，并且可显示单体电压柱状图。 ● 放电测试过程中，各单体电压实时检测和显示，并在主机屏幕上呈现出各单体电压柱状图 的变化轨迹（可显示各单体电池起始电压位置和当前电压位置），还能实时显示一组电池中电压最高与最低的单体编号和数值，避免用户看走眼。
锂离子脱嵌和充放电原理 从微观世界（原子级）来观察电池正负极的结构，各极活性物质的结晶结构为层叠状，这种结构使锂离子的嵌入（脱嵌）变得容易。锂离子在分子间作用力的作用下为固定状态。当对正负极施加电场时，锂离子只需要较低的能量就能发生迁移，进行嵌入。锂离子电池充放电的机制也可以用图1 来说明。图中方程式中的正极活性物质为锰酸锂。 图1 放电时电极周围的变化 图1 是放电时锂离子嵌入和迁移的示意图。在负极，碳层之间存在锂离子，负极比正极的能量高。外部存在负载时，负极的锂离子释放电子，向能量低的正极迁移。从负极脱嵌的锂离子，通过电解液和隔膜小孔向正极迁移，嵌入层状结构的正极活性物质中。同时，电子被接收，锂离子被固定而变得稳定。如果过放电，锂离子过多地聚集在正极，会使内阻增大，电池发热，导致急剧劣化。从图1 中可见，负载电流（电池容量）几乎是由可移动的锂离子数量决定的。电子从集流体活性物质中穿过，到达外部端子。正极的集流体为铝，负极的集流体为铜。这样做的理由是：在正负极各自的电势下，铝和铜是不会被锂离子
掺杂（渗透）的金属。 充电时电极周围的变化 图2 显示了充电时锂离子的嵌入和迁移过程。 图2 充电时，外部电压施加在外部端子上，强制产生与放电反应相反的反应。由此，正极的锂离子释放电子，在电场作用下通过电解液迁移到负极，嵌入负极的活性物质内部。同时，电子被接收，锂离子被负极活性物质固定。锂离子在电解液中快速迁移，在负极表面减速，在负极活性物质内部非常缓慢地扩散。这与汽车离开高速公路，进入普通公路，然后驶入自家附近街道的过程相似。充电时，锂离子在负极表面呈现拥堵状态。 充电时电池在劣化 作为电解液的有机溶剂在正极分解，在负极表面与锂离子发生反应，形成固体电解质界面膜（SEI）。因此，迁移的锂离子数量减少，导致电池容量下降。充电时，在负极表面刻意制造这个让化学反应容易发生的状态。这与后面讲到的电池劣化相关内容也有关联。另外，过充电使锂离子在负极过多聚集，内阻
绝密★启用前全国Ⅱ卷 2019年普通高等学校招生全国统一考试 理科综合能力测试 生物试题 注意事项： 1．答卷前，考生务必将自己的姓名、准考证号填写在答题卡上。 2．回答选择题时，选出每小题答案后，用铅笔把答题卡上对应题目的答案标号涂黑，如需改动，用橡皮擦干净后，再选涂其它答案标号。回答非选择题时，将答案写在答题卡上，写在本试卷上无效。 3．考试结束后，将本试卷和答题卡一并交回。 可能用到的相对原子质量：H 1 C 12 N 14 O 16 F 19 Na 23 S 32 Cl 35.5 As 75 I 127 Sm 150 一、选择题：本题共13个小题，每小题6分。共78分，在每小题给出的四个选项中，只有一项是符合题 目要求的。 1．在真核细胞的内质网和细胞核中能够合成的物质分别是 A．脂质、RNA B．氨基酸、蛋白质 C．RNA、DNA D．DNA、蛋白质 2．马铃薯块茎储藏不当会出现酸味，这种现象与马铃薯块茎细胞的无氧呼吸有关。下列叙述正确的是A．马铃薯块茎细胞无氧呼吸的产物是乳酸和葡萄糖 B．马铃薯块茎细胞无氧呼吸产生的乳酸是由丙酮酸转化而来 C．马铃薯块茎细胞无氧呼吸产生丙酮酸的过程不能生成ATP D．马铃薯块茎储藏库中氧气浓度的升高会增加酸味的产生 3．某种H﹢-ATPase是一种位于膜上的载体蛋白，具有ATP水解酶活性，能够利用水解ATP释放的能量逆浓度梯度跨膜转运H﹢。①将某植物气孔的保卫细胞悬浮在一定pH的溶液中（假设细胞内的pH高于细胞外），置于暗中一段时间后，溶液的pH不变。②再将含有保卫细胞的该溶液分成两组，一组照射蓝光后溶液的pH明显降低；另一组先在溶液中加入H﹢-ATPase的抑制剂（抑制ATP水解），再用蓝光照射，溶液的pH不变。根据上述实验结果，下列推测不合理的是 A．H﹢-ATPase位于保卫细胞质膜上，蓝光能够引起细胞内的H﹢转运到细胞外
雅思口语万能模板 今天给大家收集了雅思口语万能模板，快来一起学习吧,下面就和大家分享，来欣赏一下吧。 雅思口语万能模板：自我介绍Sample Sample1: My name is ________. I am graduate from ________ senior high school and major in ________. There are ________ people in my family. My father works in a computer company. And my mother is a housewife. I am the youngest one in my family. In my spare time, I like to read novels. I think reading could enlarge my knowledge. As for novels, I could imagine whatever I like such as a well-known scientist or a kung-fu master. In addition to reading, I also like to play PC games. A lot of grownups think playing PC games hinders the students from learning. But I think PC games could motivate me to learn something such as English or Japanese.My favorite course is English because I think it is interesting to say one thing via different sounds. I wish my English could be improved in the next four years and be able to speak fluent English in the future.
产品技术规范书 设备名称: 智能蓄电池放电无线监测仪型号: 生产厂家: 产品编码: 品牌:
一、概述 智能蓄电池放电无线监测仪是专门针对蓄电池组进行核对性放电实验、容量测试、电池组日常维护、工程验收以及其它直流电源带载能力的测试而设计。采用最新的无线通讯技术，通过PC机监控软件可对蓄电池放电过程进行实时监测，监控每节电池的放电过程。 智能蓄电池放电无线监测仪功耗部分采用新型PTC陶瓷电阻作为放电负载，完全避免了红热现象，安全可靠无污染。整机由微处理器控制，液晶显示、中文菜单。外观设计新颖,体积小、重量轻、移动方便。各种放电参数设定完成后，自动完成整个恒流放电过程。完全实现智能化。使整个放电过程更安全。 智能蓄电池放电无线监测仪系列便携、智能化的专业设计使放电测试工作变得简捷、轻松，大大降低了专业维护人员的劳动强度，也提高了放电测试的科学性和智能化。 二、主要功能特点 ●采用PTC陶瓷电阻，避免了红热现象，使整个放电过程更安全。 ●具有无线通讯功能，无线采集盒与放电主机及上位机监控PC机三者之间通过无线方式 进行通讯。简化接线，灵活方便。 ●无线采集盒可对每节电池进行监测，实现对电池组放电过程的完整监控。 ●设备安装、调试、维护简便，各采集模块前后采用隔离技术，安全性、可靠性程度高●配备的PC机监测系统，可实时监测整个放电过程，并把监测到的总电压、放电电流和 各单体电池电压等数据进行分析、并可生成相应的数据报表。直观反应蓄电池组性能的曲线，图形、报表等，并可打印、查询。 ●有USB接口，可将放电过程的数据存入U盘，并导入PC机。PC数据管理软件可对 电池放电的过程进行分析、并可生成相应的数据报表。使数据的转存更加方便。 ●采用智能单片机ARM控制、液晶中英文显示。菜单操作简单明了。 ●自动保护功能，设定放电时长到、放电容量到；蓄电池组电压低于设定的最低保护电压； 负载连线出现异常等，自动停止放电并报警，同时自动记录停机方式。 ●可设定测试/放电终止条件，包括单体电池电压、电池组终止电压、放电电流、放电时 间。 ●可通过短时放电（10分钟）来预估蓄电池组容量。 ●可记录测试/放电过程每节电池放电情况，主要是电池组总容量、总电压、总电流以及 电压最低的单体电池的电压变化情况。 三、主要技术参数
目录 1．前言 (2) 2．功能概述 (3) 3．仪器外观 (5) 4．接线方式 (6) 5．主功能菜单 (7) 6．电池静态参数测量模式 (8) 7．电池容量测量模式 (12) 8．单独充电模式 (14) 9．单独放电模式 (14) 10．程控电源模式 (14) 11．程控电子负载模式 (15) 12．电压与内阻表模式 (16) 13．仪器校准模式 (16) 14．读码功能（DS2502兼容码） (17) 15．仪器特性指标 (18)
前言 常见的可充电电池包含锂电池，镍镉电池，镍氢电池，以及密封铅酸蓄电池等。 其中，锂电池具有容量大，重量轻，循环次数高等特点，广泛应用于移动电话，PDA,数码相机，摄像机，笔记本电脑等领域，是目前最为先进的可充电电池。这里所指锂电池是成品锂电池包，由锂电芯（锂离子电芯或者锂聚合物电芯）加锂电池保护板组成。 镍镉电池是比较早应用的可充电电池，具有成本较低，低内阻，能够大电流放电的特点，至今在一些电动工具、电动车上面有广泛应用。 镍氢电池和镍镉电池类似，但是因为不含重金属，所以对环境的污染较小，目前在一些常见的消费类电子产品中应用广泛，已基本取代以前镍镉电池的应用领域。 小型密封铅酸电池，又称免维护铅酸电他，目前工艺成熟，目前主要应用在固定式后备电源场合，如不间断电源，应急照明灯等等场合。 针对这些可充电电池的生产检测需要，特研制了专用的可充电电池综合检测仪，本测试仪可以对电池的一些基本参数做一个定量的精确的测量，可以测量电池的开路电压，内阻，充电，放电性能，电池容量特别针对锂电池的功能还有过充电保护，过放电保护，过电流保护，短路保护等功能，并测出过相应的数值，极大的方便了电池的生产和售前售后服务工作。采用非常简单的几个步骤就可以直观的判断电池的性能和好坏，同时也具有快速筛选的功能，可以设定测量参数的上限和下限，可以容易的从一批电池成品中快速检测出不良电池，提高生产效率。另外，也附加了一些特别的功能，使之具有一些通用仪器设备的特征，扩大了设备的使用灵活性，以及具有应用范围广泛的特点。 此外，本测试仪可根据客户的需要提供软件升级服务，在基本型号的基础上，可以通过软件升级为可连接电脑的型号，可以通过电脑来设置和保存测试数据，自动记录测试结果。也可以通过电池条码来记录每块电池的测试数据，有利于生产质量的分析控制，产品追朔等等。另外，可以通过加装硬件升级模块来提高电压和内阻的测试精度上升一个数量级，来满足更苛刻的质量要求。
绝密★启用前 2019年普通高等学校招生全国统一考试（江苏卷） 生物 选择题 一、单项选择题：本题包括20小题，每小题2分，共计40 分。每小题只有一个 ．．．．选项符合题意。 1．下列关于细胞内蛋白质和核酸的叙述，正确的是 A．核酸和蛋白质的组成元素相同 B．核酸的合成需要相应蛋白质的参与 C．蛋白质的分解都需要核酸的直接参与 D．高温会破坏蛋白质和核酸分子中肽键 2．下列关于细胞生命活动的叙述，错误 ．．的是 A．细胞分裂间期既有基因表达又有DNA复制 B．细胞分化要通过基因的选择性表达来实现 C．细胞凋亡由程序性死亡相关基因的表达所启动 D．细胞癌变由与癌有关基因的显性突变引起 3．赫尔希和蔡斯的T2噬菌体侵染大肠杆菌实验证实了DNA是遗传物质，下列关于该实验的叙述正确的是A．实验中可用15N代替32P标记DNA B．噬菌体外壳蛋白是大肠杆菌编码的 C．噬菌体DNA的合成原料来自大肠杆菌
D．实验证明了大肠杆菌的遗传物质是DNA 4．下列关于生物变异与育种的叙述，正确的是 A．基因重组只是基因间的重新组合，不会导致生物性状变异 B．基因突变使DNA序列发生的变化，都能引起生物性状变异 C．弱小且高度不育的单倍体植株，进行加倍处理后可用于育种 D．多倍体植株染色体组数加倍，产生的配子数加倍，有利于育种 5．如图为燕麦胚芽鞘经过单侧光照射后，甲、乙两侧的生长情况，对照组未经单侧光处理。下列叙述正确的是 A．甲为背光侧，IAA含量低于乙侧和对照组 B．对照组的燕麦胚芽鞘既不生长也不弯曲 C．若光照前去除尖端，甲、乙两侧的生长状况基本一致 D．IAA先极性运输到尖端下部再横向运输 6．下列关于种群和群落的叙述，正确的是 A．种群是生物进化的基本单位，种群内出现个体变异是普遍现象 B．退耕还林、退塘还湖、布设人工鱼礁之后都会发生群落的初生演替 C．习性相似物种的生活区域重叠得越多，对资源的利用越充分 D．两只雄孔雀为吸引异性争相开屏，说明行为信息能够影响种间关系 7．下列关于观察植物细胞有丝分裂实验的叙述，正确的是 A．只有从新生的根尖上取材，才能观察到有丝分裂 B．解离时间要尽量长，以确保根尖组织细胞充分分离 C．滴加清水、弄碎根尖以及压片都有利于细胞的分散 D．临时装片镜检时，视野中最多的是处于分裂中期的细胞 8．如图为突触传递示意图，下列叙述错误 ．．的是
小黑雅思口语万能连接词地点描述 Like I’m fairly keen on… I’m really into… I’m quite a big fan of… I simply adore… I’m quite enthusiastic/passionate about… I generally prefer…to… I’m pretty fond of … I’m totally mad about… I’m obsessed with… I’m fascinated by… dislike I’m not so keen on… I’m really not that fond of … I’m not much of a fan of… I really cant stand… 迅速回答 Well, actually… Sure, obviously… Ok, certainly… Of course, you know… Of course, it goes without saying that…不确定 I think I would have to say that it really depends. Well, quite honestly I don’t think I’ve ever thought about hat, but I guess…Actually, this isn’t something that I’ve ever considered, but in short… I’m not really sure how to put this, but I suppose generally speaking… 种类 There’s quite a mixed variety of …There’s quite a wide range of… There’s fairly broad range of… There’s quite an extensive diversityof …There’s quite a diverse mixture of… 虚拟语气 If I lived in Mediterranean, I would/could/might…… 假设 If …, then I will most likely do….
分享常用的雅思口语句型模版 本文三立在线老师为大家整理了一些雅思口语模板句型，希望同学们都能取得好成绩。 I get up at six o''clock.我六点起床。 I meet the boss himself.我见到了老板本人。 I owe you for my dinner.我欠你晚餐的钱。 I really enjoyed myself.我玩得很开心。 I''m fed up with my work !我对工作烦死了! It''s no use complaining.发牢骚没什么用。 She''s under the weather.她心情不好。 The child sobbed sadly. 小孩伤心地抽泣着。 The rumor had no basis. 那谣言没有根据。 They praised him highly.他们大大地表扬了他。 Winter is a cold season.冬天是一个寒冷的季节。 You can call me any time. 你可以随时打电话给我。 What shall we do tonight?我们今天晚上去干点儿什么呢? What''s your goal in life?你的人生目标是什么? When was the house built?这幢房子是什么时候建造的? Why did you stay at home?为什么呆在家里? Would you like some help?需要什么帮助吗?
You mustn''t aim too high你不可好高骛远。 You''re really killing me!真是笑死我了! You''ve got a point there. 你说得挺有道理的。 Being criticized is awful !被人批评真是痛苦! 15 divided by 3 equals 5.15 除以3 等于5. All for one ，one for all.我为人人，人人为我。 East，west，home is best. 金窝，银窝，不如自己的草窝。 He grasped both my hands. 他紧握住我的双手。 He is physically mature.他身体已发育成熟。 I am so sorry about this. 对此我非常抱歉(遗憾)。 以上是三立在线老师带来的关于分享常用的雅思口语句型模版的详细内容，希望各位考生能从中受益，并不断改进自己的备考方法提升备考效率，从而获得理想的考试成绩。
万能雅思口语话题高分模板句今天三立在线教育雅思网为大家带来的是万能雅思口语话题高分模板句的相关资讯，备考的烤鸭们，赶紧来看看吧！ 遇到口语新题卡壳时，你需要这些句子 1. This is a tough question. I have never heard about it, nor have I ever read about it (倒装句丰富句型). 2. Give me a few seconds for me to search every piece of information in my head now. 3. It is an abstract question. I know little about it. 4. Are you asking me something about+你重复一下句子中的关键词…? 5. Have I given enough information? It would be great if you could give me more. 6. Am I making myself clear? 7. Now you want me to talk about it. But I don't have too much to say. 8. Give me a few seconds for me to organize my thought a little bit. 遇到话题来不及思考是，你需要一些简单过渡词 如果你不需要这么长的思考时间，你可以说这些简单的过渡词： 1.“well” 2.“you know” 3.“actually”
蓄电池放电仪主要功能 蓄电池放电仪主要是专门用于电力、电信、铁路、电池生产企业或其它行业对蓄电池组(24V、48V、110V、220V、400V、600V)、进行日常维护、容量检测以及检验直流电源带载能力而设计。功耗电元件采用新型PTC，体积小、重量轻、移动方便。整机由微处理器控制，液晶显示、中文菜单。放电电流以1A为单位(0A~300A)连续可设。放电参数可按键盘输入，也可由计算机下传设置。参数一旦设定，自动完成整个放电过程。完全实现智能化。可生成各种直观反应蓄电池组性能的曲线、柱图、报表等，并可放大、查询、打印。可以对电池性能进行分析。 1.微电脑控制、液晶显示、中文菜单；实时显示各种检测数据（电压、电流，放电开始时间及时长，容量、电压保护低限等）随时了解设备运行状态。 2.键盘操作：通过键盘设置各种放电参数及机器运行的各种指令（也可通过计算机下传）。 3.自动保护：设定放电时长或放电容量到，蓄电池组电压低于设定的保护电压或负载连线出现异常，自动停止放电并报警。同时自动记录停机方式。 4.掉电功能：在放电过程中如意外停电，自动保存所设置的放电参数，等来电后 自动持续放电，各种放电数据连续存储，且不会对设备造成损坏。 5.数据采集：放电开始二分钟以较快的的频率采集存储数据，以后每分钟一次。 便于对蓄电池组性能的分析。 6.数据处理：检测到的各种数据可通过232通讯口或USB口上传计算机，经专用软件（随机配置）进行处理，生成各种直观反应蓄电池组性能的曲线、柱图、报表等，并可放大、查询、打印。 7.修正功能：对电压、电流值无论在放电前或放电过程中都可进行修正（校验）。 8.数据存储：可自动存储每次放电不超过15小时连续八次的放电数据，掉电不丢失。 9.功耗元件：采用新型金属PTC，安全无污染、体积小、重量轻、散热快 尊敬的客户： 感谢您关注我们的产品，本公司除了有此产品介绍以外，还有10KV高压绝缘 垫,ZGF-2mA/60KV直流高压发生器,硅橡胶高压线,继电保护试验装置，微水测试仪，安全工器具力学性能试验机，双钳相位伏安表，100A回路电阻测试仪等等的介绍，您如果对我们的产品有兴趣，咨询。谢谢！
RTKC-II 便携式智能蓄电池充电机 一、产品概况： RTKC-II便携式智能充电机是采用当今最先进的边缘谐振软开关技术，可带电插拔，模块与模块之间采用自带二极管隔离设计，防止模块间相互影响。模块内部自带CPU，模块所有基准校准和控制功能，采用12位D/A完成，替代所有电位器，避免了电位器固有的温度系数和机械特性所引起的参数漂移。 二、产品主要特点及功能： ● 输出过压保护：输出电压过高对用电设备会造成灾难性事故，为杜绝此类 情况发生，本系列高频模块内设有过压保护电路，出现过压后模块自动锁死，相应模块故障指示灯亮，故障模块自动退出工作而不影响整个系统正常运行；过压保护点一般设为313V±2V（220V），过压报警点软件可设定。 ● 输出限流保护：模块输出电流最大限制为额定输出电流的倍（可设定），恒 流降压工作方式. ● 短路保护：整流模块输出特性如图3-1，输出短路时模块在瞬间把输出电压 拉低到几乎为零，限制短路电流在限流点之下，此时模块输出功率很小，以达到保护模块的目的。模块可长期工作在短路状态，不会损坏，排除故障后模块可自动恢复工作。 ● 模块并联保护：每个模块内部均有二极管并联保护电路，绝对保证故障模块 自动退出系统，而不影响其它正常模块工作。模块并机可直接在输出端相连。 ● 风扇启动：设有两档风扇启动功能，当输出电流大于25%30%额定值时，或当 模块内部温度高于60℃时，模块会启动强力风扇。 ● 过温保护：如环境温度过高、风机停转等情况下，模块检测散热器温度超过 85℃时自动关机保护，温度降低到76℃时模块自动启动。 ● 测量输出电压和输出电流以及模块的工作状态，并通过LCD中文显示，直观 方便。 ● 报警：在模块出现故障时模块会发出声光报警，同时LCD上显示故障信息， 用户能方便的对模块故障定位，便于及时排除故障。 项目技术指标 交流输入三相四线输入380V四线制；50Hz 电压变化范围323V-437V 频率变化范围50Hz±10% 直流输入直流输出额定电压220V, 80-286V 直流输出额定电流10A, 15A 输出限流范围（10%—100%）x额定电流稳压精度≤% 稳流精度≤% 纹波系数≤% 工作效率≥94% 动态响应≤200μS 绝缘绝缘电阻DC500V, ＞2MΩ 绝缘强度AC1500V/50Hz,1min,无闪络