On the maintenance of object-oriented software
Summary: 1 Problem 2 Object-Oriented Software is easy to modify, but it is not easy to understand the understanding of object-oriented software, analysis 3.1 understanding, analyzing the general method of object-oriented software 3.2 pairs (enabling procedures) Inheritance mechanism analysis 3.3 Analysis of class groups with close relationships 4 Dynamic coupling and polymorphism of object software 5 Suggest 6 Conclusion
Summary:
Developing software with object-oriented methods has gradually treated, and people generally think that the maintenance of object-oriented software should not be a problem, but the fact is not the case. With the widespread use of object-oriented technology, the problem-oriented software is not easy to maintain (the reason is that the maintainer is not easy to analyze, understanding such software) has become more and more prominent. Based on discussing object-oriented technology, this paper explores the maintenance of object-oriented software, and proposes the countermeasures.
1 question
All software has a cost-off maintenance phase. Many people 's experience shows that a few maintenance is a correction maintenance, most maintenance adaptability (or improved) maintenance. No matter how good a software is, the user will require a stronger function, better adaptability. Many years of practice showed that only constant maintenance, software products have vitality.
Now use the object-oriented method development software has gradually treated, because object-oriented has some advantages that the structured method does not have, and it is extremely beneficial to improve software development quality and development efficiency [1]. However, object-oriented software also requires high maintenance [2], which tends to exceed the investment in software development. Because the technologies used in development, the problems faced in software maintenance are different, so we must pay attention to the maintenance of object-oriented software. In view of this, this paper is preparing to explore the maintenance issues facing object-oriented software and the countermeasures we should take in detail according to the characteristics of object-oriented technology.
2 Object-oriented software is easy to modify but not easy to understand
Like all software, the maintenance of object-oriented software also requires two basic conditions: 1. Software to be maintained can be understood; 2. Software to be maintained can be modified, in software maintenance, only first understand the program, then modify the program .
The key issue of understanding the process is that maintenance personnel can reconstruct the source design and master the original designer's design ideas and methods, strategies. If these ideas, methods, strategies are concentrated in a small program, then it is easy to understand. However, programs developed with object-oriented technologies often exist in discontinuous blocks (such as a program may have a program, and there may be multiple separate methods in an object), and the maintainer will easily generate errors. Understand and make a wrong modification accordingly.
The main point of object-oriented technology is to abstract problems into individual objects and packaged [3]. The message delivery mechanism inside the object relies on the means of the message activation method, and the characteristics of parallel, inheritance, delivery, activation between the objects will inevitably lead to a large number of complex relationships between the software. These features inherently inherent, so that the methods of reading, analysis, and understanding procedures, which will greatly increase the difficulty of understanding software.
For a modification of a understanding software, it is much easier, because the objects in object-oriented software can reflect the static properties and dynamic behavior [4] of objective things [4], and the inheritance mechanism can reduce the modified amount to the lowest. Plus the object package installation (modification of an object does not affect other objects), so object-oriented software is easy to modify [5].
In summary, we can learn that if we have understood an object-oriented software, this software is easy to modify (compared to other types of software), but object-oriented software is not easy to understand.
3 understanding, analysis of object-oriented software
3.1 Understanding, analyzing the general method of object-oriented software
Understanding is the basis for maintenance, and the reconstruction of "source design map" is the basis of understanding. When reconstructing the "source design map", it is difficult to understand the original design because the object's polymorphism, inheritance mechanism, and dynamic joints are characterized. For the convenience of future maintenance, the software should be easily understood during development (but it is difficult to ensure the easy-to-understandability of the final software), the software development environment should also provide assistance The tool for original software design ideas and strategies (there is too little in the eye). When understanding a block in general habit, you should first complete the static analysis of the program. While accessing the document and program code, you must work hard to get the use and design ideas of this block. Maintenance personnel need to find where this block is called, the other procedures called by this code, the prerequisites, the function and data flow of these processes, so that this can be truly understood, master this code. For object-oriented code, some special points must be considered.
In order to understand the object-oriented software, the organizational structure of each object should be analyzed, and the interaction relationship between the objects, and the object, the object, object, object, the object, the object The relationship between and masters the conditions of the conditions, the source of the message, the source of the message and the passage of the message. Under the existing technical conditions, some things are often difficult to figure out by information, it is best to find the original developers, please introduce the necessary content.
3.2 Analysis of the inheritance mechanism of (make the program complicated)
In order to understand the procedure, you must understand the dependence of the program (including the calls of the data stream). The inheritance mechanism in the object-oriented program is found, and the dependence of the analyst has increased difficult. When analyzing a program, do you have to consider whether it exists in some specific context? Does this block depend on a method in a (some) object class [6]? What is headache is that this method may be manipulated by a member in its subclass, and an example of the method of manipulating the method can be described in a class or in a member in its subclasses. Take description [7]. In the example of FIG. 1, the instance varies "staff code" in the "Staff" class, which can be inherited by other subclasses. When the maintenance team is analyzed in the "Calculating Wage" method in the Technical Engineering class, if you encounter the "staff code", you can find this description and annotation to the upper (possibly multi-layer) class.
During the development of object-oriented software, as the new object is increasing, the level of inheritance may also increase, which often makes the inheritance relationship more complicated. For example: Maintenance personnel If you need to check a message to send, you need to check that several layers can determine the recipient of the message (ie, an object). This test has undoubtedly adding the difficulty of understanding the procedure.
In developing software, in order to avoid the encapsulation of the data, the programmer naturally makes the method in the object and simple, the number of small methods is greatly increased. These large amounts of small methods often make the inheritance relationship chains in the system become very long, obviously, this will also increase the difficulty of analysis.
3.3 Analysis of class groups with close relationships
There are always a close object in object-oriented software (they complete a specific task through close cooperation) [8], the author refers to the classic classes as a close-related group (hereinafter referred to as "secret group") . Maintainer wants to understand the methods in each class in the secret group, you must understand the entire operating mechanism of this secret group, which requires tracking all possible messaging sequences, which is quite huge. Therefore, the existence of the secret group increases the difficulty of reading and understanding the procedures. In the case where the analysis tool is currently lacking, for future maintenance, the activity process of the secret group must be recorded in the software document, and track the methods in each object. At test, you want to record the sequences, conditions, time, sources, and processing results of the message. This complete record can alleviate the analysis of the maintenance personnel, understand the difficulty of software, and ultimately improve the maintenanceability of the software. 4 Dynamic joints and polymorphisms for object software
Dynamic coupling and polymorphism will give software maintenance to analyze difficulties. For example, in the example of Figure 1, the "Print Waraction Table" method includes code of the following (Visual FoxPro 3.0 instructions) [9]:
THIS.JSGZ ()
This code issues a "calculation pay" message to the current object. But now there are three objects that contain "calculation wages". For the language supporting dynamic joins, it is clear that we cannot determine the one in these three methods according to this instruction. All maintaines have to take into account these three possibilities when analyzing this directive. These three methods must also be scanned for the analysis tools we use.
If only the static join is used, and the context of the code provides the corresponding information, it can be derived from the corresponding classes, but there is still misleading possible. Because processing a message can be used in a variety of methods, it is difficult to remember the response of these methods on the message, and the possibility of understanding mistakes occurs greatly.
The author believes that the key to generating difficulties is the semantics of the object. If the developer guarantees polymorphism, all methods have the same reflection to a message, then the problem will be less. But if the names are different, the maintainer will still misunderstand because a method has a small amount of different behavior, which will change the meaning of the entire code segment.
Maintenance personnel can find this inconsistency by comparing "external dependent map" [10]. The external dependent diagram is a relatively effective detection tool, and when a method is started, it can automatically use the method of data flow diagrams to determine the data item dependencies that may be established. If the designer can use the polymorphism correctly, the method with the same name will have the same form of external dependent diagram, so that the software tool can compare the external dependent diagram of the method started by the same message, and for different points Mark, facilitate the analysis of people.
For a software, polymorphism and dynamic join have two sides: the advantage is that the program has flexibility [4] (this is one of the object-oriented targets, but also its unique technological charm); disadvantage is to people Understanding software has brought difficulties, thereby increasing the difficulty of maintenance. In order to improve the maintenanceability of object-oriented software, there is currently a need for authorities to establish a control, standard for dynamic coupling and polymorphism, minimizing this arbitrary.
5 suggestions
In general, object-oriented methods have a lot of advantages, but there have been some difficulties on maintenance, mainly to increase the difficulties of the maintainer, analyze software. In order to reduce the difficulty of object-oriented software maintenance, it is recommended to adopt the following measures:
a. Develop maintenance tools for object-oriented software features to help people analyze and understand software.
b. Software developers should be particularly careful when using certain technologies (such as inheritance, dynamic coupling, etc.). Because these software mechanisms are similar to the GOTO statement in the traditional method, although there is a benefit, improper use will also bring difficulties in maintenance and debugging.
c. Development organizations of authoritative institutions or software should establish a standard for control, standardizing dynamic coupling and polymorphism, minimizing the arbitrariness of this aspect. In the absence of authoritative standards, the project group of development software should first determine their own standards, forming the standard, as part of the software document, to mitigate the difficulty of subsequent analysis. d. Developers should make records in the document, especially to record the activities and testing processes of the class groups with close relationships, so that the document can be as comprehensive as possible.
6 Conclusion
A few years ago, some scholars believe that the object-oriented method must replace the structured method. It seems that "replacement" is still too late, and there are more conjunctions. Because of an object-oriented method is still a technique to be improved, there is not much software developed using this technology, and the large-scale application software that is fully faced, has not entered the comprehensive maintenance stage, and people have lack maintenance experience. So we are currently lacking enough understanding and measures on the maintenance of object-oriented software, so we must pay close attention to the road to the future of large-scale maintenance work.
