Object-Oriented Software Engineering Methodology Practice Zhao Xiaohua (this article reprinted from Software Engineering Expert Network www.21cmm.com, does not mean GIGIX perspective) Two research-oriented Software Enginee (Stave Halladay and Michael Wiebel) said: "General Object-oriented programming (OOP) thinking is just a group of blackcombies, and the randomly strained skills are used for them to random the abstract 'object'. Even the best OOP programmers, they can deal with the limit It is also the medium-sized development project. If the programmer has insufficient experience, the system is very large, then OOP can only introduce you in a marginal mud. "On the one hand, almost no software engineers think that OOP is perfect. There is no lack, on the other hand, the OOP is like a broken bamboo. Almost every newly launched program development tool or language has adopted OOP ideas; on the one hand, more and more "Wu Huan" is in the case of non-charter, and the object you want to deal with " "On the other hand, after nearly 30 years has had the largest atrophy of structural software methods for most users ... facing this reality, experts in studying software engineering methods have pointed out:" Currently placed in software An important issue in front of the development methodology is: from the theoretical understanding of the natural rationality of powerful vitality, and improve the object-oriented software engineering methodology system. "For the development practice of some practical systems at home and abroad, The software engineering method has conducted a more in-depth study and discussion, especially in the first phase of the Beijing Highway Bureau computer system, drawing on foreign software design experience, which has used object-oriented software engineering methods, and benefits a lot. First, it is "design lead" or "program leading" in a system development process only OOP or an OOSE (object-oriented software engineering) method, the key to see the entire development process is "design lead" or "program leading". In recent years, a large number of advanced procedures development tools have entered my country, which has a great role in improving software development efficiency. However, they tend to lead the program leading software developers in the "programming system", "aliened by an alien design", the deeper. The general software developers (including programmers who see programs that are not available) believe that software development should not be "system design lead" and lead to "program algorithm". However, with the following questions, the result is often the opposite. Question 1 Is it possible to develop methodology before performing software design and selection software development tools? The so-called methodology refers to a series of methods, techniques, and specifications of the organizational software production process. Methodology is the theoretical summary of software developers failing and successful experience. From the idea of software reuse, the value of methodology reuse is more than certain programs components. Taking Beijing Municipal Highway Bureau as an Example. First, we learned in the system survey phase: this system should be developed (increted). Due to the period of institutional reform, the user needs and system structures in the system survival are much more. This indicates that the target system should have strong maintenance, that is, each period of development results should have a high reusability in subsequent engineering. Second, the first phase of the project is quite large (the last results include 124 modules, 72 types of reports, 119 database tables, 439 windows, 912 data windows), and developers don't understand the road bureau business, more experience Insufficient college students, the ability to understand demand is low. This indicates that the development methodology must maximize repetitive labor, realize the achievements sharing and reuse of the development process; it must support the elimination of demand to understand the error, so that the design changes in the downstream finished product stage are easier. Before developing this system, we undertake a downstream development task of foreign software. Since it adopts object-oriented software design, we have deeply realized that domestic and foreign software development methods and technical gaps are quite inspired.
Referring to our consolidation of foreign software development efforts, only 120 modules (including reports) coding and testing are 41 months, then the highway system starts nearly 200 modules and reports from upstream design, more than 100 databases The development effort of the table should be at least 120 people. Due to the use of object-oriented software engineering methods, despite most of the experience insufficient experience, the first phase of the project is still controlled within 80 people, and the cost is about 1/3. At the same time, the system maintains maintenanceability, reuse and other functions and performance indicators, exceeds the system we have developed in the past. For software developers who stayed in program leading levels, they choose OOP's reasons to be passive. In fact, in the dictionary of the program dominant developer, it is found that "Methodology" is not found in the "Methodology" and "Program Algorithm". As for the view of OOP as OOSE, it is more insufficient. Question 2 Abstract starting point is the real world problem, or can be executed instance object? In the real world's early abstract phase, the object-oriented method is not much different from other methods, and it is necessary to depart from the real world, that is, from the user interface, the knowledge and experience in the field, to construct the real world problem model, that is Determine the target system "What to do". Object-oriented problem analysis model describes 3 sides, ie object models (static structures of objects), dynamic models (sequence of object interactions) and functional models (data transformation, and functional dependencies). Software engineering abstraction, hierarchical principles and segmentation principles are also suitable for object-oriented methods, namely the object abstraction and functional abstraction principles, and from advance to low, logic to physical, step by step. Each level of abstraction is repeated object modeling (object recognition) → dynamic modeling (event identification) → function modeling (operation identification) process until each object instance is all implemented on physical (program coding). The object abstraction is from logic or physical stage, just like the development before the development, is also a tribute to OOSE and OOP. Because many tools or languages (such as PB, C , Motif) support OOP, some program-level system developers can directly develop physical objects without logic abstraction, and do not know from physical layers, examples. It is not only the advantages that the OOP you want is not only unable to play the superiority of the object. It also brings a lot of return work in the future. As in the past, we have also introduced prototyping methods in the system design phase to use system samples, namely prototypes, and user-dialogue, and to seek the need to understand, avoid or reduce post-renewers. Most OOP tools provide convenience to the development prototype, the problem is the relationship between prototypes and final products, that is, prototype is a sample of logical objects or physical objects. If the latter is equal to the final product. When the wood has become a boat, let the user review. If the problem is found, it is either to move back, or forced users to cut the appropriate performance. In fact, we are based on the prototypes developed based on logical objects for design review, and quite partially vetoed by the user. However, since the physical level development has not been carried out, it is not difficult to use the superclass model prototype uniform analog object event and operation, whether it is an object model, a dynamic model or a functional model, and it is not difficult to modify. Question 3 Whether the design phase is designed to design a superclass, do you complete the implementation of the superclass object before the instance object design begins? Software-oriented software has strong reusability, which includes reuse and external reuse of the development project. Reuse is contained in superclass design, without superclad object system is better than "put the washing machine as a rice cylinder", can not be used. The super-class design is good, first look at the high low reuse rate, the internal reuse rate is high, and the inevitable external reuse rate is also high.
Due to the tightening of the system development, the workload is large, and our development team is young, experience and manpower is insufficient, and the overcase development of the internal reuse rate is undoubtedly our savior. It can reduce labor, easy to unify specifications, unified research on complex issues, uniformly solve, and make it easy to maintain. For the generalization of the extensive abstraction of the superclass, we are considered from the following aspects: (1) Find the common behavior of most instance objects. For example, "Print Report", "Query Static Code Table", "Enter Database Table Data", etc. (2) Supected polymorphism design To ensure that the use of superclass inheritance relationships can meet the operation requirements of each subclass. For example, inheriting the same "data entry" ancestor window, you can complete data entry of different structural database tables. (3) Conservatives are convincing, and the integrity of the data will not be damaged, which is beneficial to simplify complex issues. For example, maintenance of database table sets with complex relationships, structures, and related access operations. If you do not use a generalization class to encapsulate the data structure and its related operations, the next programmer must operate the library table must have an in-depth understanding of the library table design, and ensure that the program algorithm can not destroy the relevant consistency of data. This will greatly increase the difficulty of programming and testing, requiring programmers to have rich experience. After using this general function (public function, public storage procedure), the programmer is just issued to "message" and "output information". (4) It is conducive to the implementation of development specifications, unified interface styles. We have developed the maximum wear of foreign software: foreign countries' strict requirements for user interfaces (reports, screens). All screen buttons are high, wide, and the starting position is used to specify the X and Y coordinations of 3 digits after the decimal point. The product that comes out makes people look at the pleasing sense. But if everyone is doing interface windows, the fine adjustment of the button is bound to grow. Using the inheritance relationship of the screen interface mode superclass, combined with specialization, the problem can be solved. Obviously, the superclass design and implementation must be completed before the programmer is generally developed. That is, the upstream system designer of OOSE must be civil and military (design and programming), which can take advantage of the programs for super-class objects to implement and test tasks. This is different from the upper system designer of the structured method. At the same time, the superclassic object must often absorb feedback during the downstream development process (including feedback from the user), perform corresponding adjustment modifications. Therefore, OOSE has a designer design and implementation of the designer that is difficult to enter the programming phase, and they often do not have to be able to deal with the program. If the design phase does not design and develop super-class objects, there is no ancestral object that can be inherited between most developers of the same project, even inherited inheritance, then this is not only not OOSE, it is very boring for OOP. Question 4 How do I handle object-oriented object-oriented database mode mappings? Object-oriented database design methods can be used in various databases, such as hierarchical, network type, relational, and other-oriented types. Database design in OOSE will undoubtedly use object-oriented database design methods. The database design is also known as the database mode, which is basically constructed from 3 hierarchical modes: from the specific DB application perspective; external mode of DB design; DB design, DB design procedure from the organization or enterprise perspective, concept mode; processing corresponds to specific DBMS features Limited DB design is internal mode. Specifically, the internal mode is the SQL definition of the database. The logical mode is the logical definition of the table set, and the external mode is partial DB from a particular application angle. The interface between external mode and logical mode is a view, stored procedure, or other DB handler that is resident in server-side.
If in an abstract object model, each app is a child object of one or more superclass objects, then selecting the appropriate subdivision of the object model mapped to the conceptual model, which is the key to the database library table object design. The less interface between external mode and concept mode, the more simple and better, such program is simple, and databases and programs are easy to maintain. That is, localization is an important design principle. OOP is mostly backed by the database, which is based on the existing database. Therefore, OOP can work whether or not the object model is used to model the object model, and whether the object model is rationally mapped to the database logic mode (object-oriented database design). Question 5 Do you first investigate if there is a reusable (inherited) object, whether to participate in the next object to the upper object, superclatrifier feedback? The program that bury his own shackles may be necessary, but developers who are programmed in the object-oriented method should first go to investigate the object data dictionary, there is no other developers who have completed it. Reusable objects. In general, the sharing of objects should be managed by the upper designer to ensure the consistency of object style and avoid conflicts. However, the independence, encapsulation and polymorphism of the object is very easy to reuse. This is one of the most important ideas of the structuring system, and is one of the most important ideas of software development methodology. Upper designers are often impossible, understand the developers of software design theory, even if only the underlying procedure should also use the most labor-saving, most efficient programming methods, a large number of reuse objects. When inheriting a super-class object and reusing others, if you find an unreasonable place, you should reflect the bearers developed to the object. For the upper design person, on the one hand, the program should be encouraged to reuse the existing objects. On the other hand, the object data dictionary should be shared, so that individual object reuse can be reflected in the overall object model to ensure design changes. consistency. Second, the object-oriented method and structured method comparative analysis is the problem abstraction (what to do), design is a problem solving (how to do), the implementation is the solution of the problem (result). This is true for any way to learn the abstraction and solving process of objective world. In the problem abstract phase, the structured method is the process of finding the problem in accordance with the process of data transformation, and the problem is decomposed. Therefore, different object models that emphasize the object-oriented method, the functional model of the data transformation is the focus of the structured method. If the problem world is more complicated or more important, then the structured method should still be the preferred methodology. If the data structure is complicated and the transformation is not much, if there is a process dominant analysis and design, once there is a system change, it will bring a big chaos to the downstream development. Due to different understandings of the process, the functional modules divided by the process-oriented functional segmentation may vary from person to person. Object-oriented object segmentation, from the object of the same problem, different people have higher ratios to the same conclusions. In design, structured methodology generates a system structure that is clear and structured. Each module may maintain strong independence, but it is often independent with the database structure, and there is no mapping relationship between functional modules and database logic mode. The program is difficult to encapsulate with the data structure. If the data structure is complex, the module independence is difficult to guarantee. Object-oriented method Abstract system structure is often not simpler than the system structure generated by the structured method, but it can be mapped to the database structure, and it is easy to implement the package and data structure. There is a "formal principle" in the basic principles of software engineering, that is, the abstract conclusions of the problem world should be expressed in formal language (graphical language, pseudo-code language, etc.). Structured method can use data flow diagrams, system structural diagrams, data dictionaries, state transition diagrams, entity relationship diagrams; and object-oriented methods can use object model diagrams, data dictionaries, dynamic model diagrams, function models Fig.
Among them, the combination of the object model diagram approximation system structure and the real relationship diagram, dynamic model diagram similar state migration diagram, function model diagram similar data flow map. The highway system has more than 100 database tables, but the data processing (transformation) is very simple. What happens if the structured methodology is selected? There is no difference in the initial phase of the problem abstraction. Since the data transformation is small, the operation of the object and the object can be regarded as one, that is, the object model described in the initial problem is basically consistent. Take the planned management office system as an example, the object is a planned administrator, planning administrator, a budget administrator, statistical administrator, and function (operation) is a plan, planning, a budget, and statistics. The problem exists in the lower abstraction. First, many public super-class object design is contrary to the structured method, because it destroys the continuity of the process and the logical hierarch of the system structure, put some lower module and no semantic object in process analysis, and placed on the upper layer of the system structure. . Therefore, if the structured method is used, the inheritance relationship must be changed to the next module call relationship. But in fact, some status of the ancestors (attribute value) is determined directly from the master module; from the control perspective, it is indeed in the upper layer of the system. If the structured method is used, the result will be either to turn the system structure into a network, lose structured features, or give up this unified design of repetitive labor. Second, the mapping design of the application of the object model to the database concept mode is also a sign using the object-oriented method. If the structured method is used, the database mode may map the objective world's data structure. Due to road, support units, management units, road conditions, bridges, tunnels, and roads on greening, there is a complex multiple relationship between all entities such as greening on the road, and the results may define a relationship library structure like spider network, which greatly aggravates The burden on the application programming and database maintenance of the database front end. In summary, if the system uses structured methods, system structures, and database structures may become a mesh structure, and they are not related to each other. The object-oriented method, system structure, and database structure currently adopted are multi-inheritance structures, and there is a mapping relationship. Obviously the former has high complexity, poor maintainability, and low internal reuse, and low reuse rate. In fact, whether it is using what methodological development software, it should be software that meets the current needs of users. The user will not find out the benefits of developers to use advanced methods to learn from the short term, and the developers are the first to benefit due to great reducing development burden. But over time, the maximum benefit is obtained or the user, because the long-term quality of the software (including low maintenance costs and long living cycle) is fundamental to the user. Third, the methodology is that the idea is not the law for the law. We understand: (1) Methodology is to make the future people to share the success of the former, avoid the failure of the former, and the attention has not been developed Creative labor in the field. Therefore, the creativity of methodology and developers is never conflict. It is neither a non-boundary as authority as laws, and cannot give universal conclusions like the law. If you must make a metaphor, it is better than the world of people. (2) Methodology of the four seas that have not been placed, any party law has its limitations, so software developers are not necessarily to be in a particular methodology. For example, an object model diagram of an object-oriented method, this formal language is far less than the structured method of the structured method, and the data flow diagram is simply clear, and if the road bureau system is expressed in the object model map, at least dozens of pages. Since the uppermost functional model is consistent with the object model, we use the system structure diagram of the structured method. (3) The fact that the OOSE method driven by OOP is indeed a realistic world than the structured method, and some OOP tools are indeed quite mature.
