[ZT] Object-Oriented Software Engineering Methodology practices

Stave Halladay and Michael Wiebel, two American scholars studying object-oriented software engineering, once said: "General Object-Oriented Programming

The idea of process (OOP) is nothing more than a group of people who use the clever and flexible techniques for the 'object' they have racked their brains to abstract.

Even the best OOP programmers can deal with development projects of medium scale. If the programmer's experience is insufficient, the system

The scale is very large, so using OOP can only introduce you into the boundless mud ."

On the one hand, almost no software engineering scholar believes that OOP is perfect, and on the other hand, OOP is very powerful, almost every

New program development tools or languages all adopt the OOP idea. On the one hand, more and more "open-ended" programs are being used as they wish.

Processing "objects", on the other hand, after nearly 30 years of accumulation, the structured software methods that have the largest majority of users are shrinking ......

In the face of this reality, experts studying software engineering methodologies have pointed out: "An important issue facing the software development methodology is:

It theoretically understands the natural rationality of OOP with powerful vitality and improves the Object-Oriented Software Engineering Methodology System ."

Over the past one year, we have developed some practical systems at home and abroad to thoroughly study and explore object-oriented software engineering methods.

Especially in the phase I Engineering Practice of Beijing public computer system, drawing on foreign software design experience, the object-oriented

The software engineering method has benefited a lot.

1. Is it "design-oriented" or "program-oriented"
Whether to use only OOP or OOSE (Object-Oriented Software Engineering) in a system development process depends on whether the entire development process is

"Design-dominated" or "program-dominated ".

In recent years, a large number of advanced program development tools have entered China, which undoubtedly plays a significant role in improving the efficiency of software development. However

The mistakes of Program-oriented software developers in "program-Based System" and "algorithm-based design" have become more and more common.

Generally, software developers (including programmers who only see programs without a system) think that software development should not be "system design-dominated ".

Instead, it should be dominated by program algorithms ". However, the results are usually the opposite if you use the following questions.

Question 1: Do I select the development methodology before designing and selecting software development tools?

The so-called methodology refers to a series of methods, technologies and specifications for organizing the software production process. Methodology is a long-term failure and successful experience of software developers.

From the idea of software reuse, the value of methodology reuse is far from comparable to that of some program components.

Take the Beijing Public region system as an example. First, in the system investigation phase, we learned that the system should be developed in stages (incremental. Because

During the period of institutional reform, the user requirements and system structure of the system have changed significantly during the lifetime of the system. This indicates that the target system should have strong maintainability,

That is, the development results of each phase should have a high reusable rate in subsequent projects. Second, the workload of Phase I project is quite large (the final results include 124

Module, 72 types of reports, 119 database tables, 439 windows, and 912 data windows). Developers are not familiar with the public sector business and are mostly experienced.

Insufficient college students lack the ability to understand their needs. This shows that the development methodology used must be able to minimize repetitive work and achieve development through

Share and reuse of the results in the process; it is necessary to support adjustment processes that eliminate the requirement understanding error, so that the design changes in the downstream finished stage are easier to carry out.

.

Before developing this system, we undertook a downstream development task for foreign software. Because of its object-oriented software design

They are deeply aware of the gaps in software development methodologies and technologies at home and abroad, and are very inspired.

Refer to the foreign software development workload calculation method we undertake, that is, the encoding and testing of only 120 downstream modules (including reports) is 41 person-months, that

Since its upstream design, the development workload of nearly 200 modules and reports and more than 100 database tables should be at least 120 man-months. By

In the use of object-oriented software engineering methods, although the majority of developers experience is insufficient, but the total working hours of the first phase of the project are eventually controlled at 80 people

Within a month, the cost is reduced by about 1/3. At the same time, the maintainability, reusability, and other functions and performance indicators of the system exceed the requirements we used previously.

The system developed by the construction method.

For software developers who stay on program-dominated development, the reasons for their selection of OOP are often passive. In fact, in the program-dominated

The term "methodology" is not found in the developer's dictionary, or the term "methodology" is confused with "program algorithm. Consider OOP

All of OOSE is even more strange.

Question 2 is the starting point of object abstraction a real-world problem description or an executable instance object?

In the early stage of abstraction in the real world, object-oriented methods are not very different from other methods. They must begin with the problem description in the real world.

Build a real-world problem model based on the knowledge and experience of user interfaces and problem fields, that is, determine what the target system is "doing ". Surface

The Problem Analysis Model of the object is described from three aspects: the object model (static structure of the object) and the dynamic model (sequence of object interaction)

And function model (data transformation and functional dependency ). The abstract principles, hierarchy principles, and segmentation principles of software engineering are also applicable to object-oriented methods.

That is, the object abstraction and functional abstraction principles are the same. They are also subdivided from advanced to low-level, from logic to physical. Each level of abstraction is repeated.

Like modeling (Object Recognition) → Dynamic Modeling (Event Recognition) → functional modeling (Operation recognition) process until each object instance is physically (programmed)

Code.

Whether object abstraction is based on logic or physical level is the same as whether to select methodology before development. It is also a trial to distinguish OOSE from OOP.

Shi. Because many tools or languages (such as Pb, C ++, and motif) Support Oop, some program-level system developers can easily

Logical abstraction directly develops physical objects. In the early stages, we were unaware of the scourge of system development from the physical layer, that is, instance objects.

This kind of freetier OOP not only fails to take advantage of the superiority of the object-oriented method, but also brings a lot of rework work to the later stages of development.

Similar to the previous use of structured methods, we have also introduced prototype methods in the system design phase, so that we can use the system sample, that is, the prototype and user-to-user

To avoid or reduce future rework. Most OOP tools provide convenience for prototype development. The problem lies in prototype and final

Relationship between products, that is, whether the prototype is a logical object or a physical object sample. If it is the latter, it is equivalent to the final product. Let's try again when the wood is finished

User Review: if a problem is found, you can either repeat the problem or force the user to perform the test. As a matter of fact, we open a logic object for design review

A considerable part of the prototype is rejected by users. However, the physical-level development of object instances has not yet been performed, but the superclass object prototype is used to simulate

Such as events and operations. Therefore, it is not difficult to modify the object model, dynamic model, or functional model.

Question 3: In the design phase, do you need to design a superclass first, and do you want to complete the implementation of the superclass before the Instance Object design starts?

The software developed by the object-oriented method is highly reusable, including the internal and external reuse of the development project. Reuse

Dependent on the super-class design, the object system without the super-class is like "using the washing machine as a rice tank" and cannot make the best use of the product. Super class design is good or bad. First of all

Depending on the internal reuse rate, the internal reuse rate is high, and the external reuse rate is also high.

Due to the tight system development schedule and heavy workload, our development team is young, our experience and manpower are insufficient, and the internal reuse rate is high.

It is undoubtedly our savior. It can reduce repetitive work, simplify Unified Specifications, solve complex problems in a unified manner, and facilitate unified maintenance.

The generalization principle of super class abstraction, that is, instance object, is taken into consideration in the following aspects:

(1) Look for the common behavior of most instance objects.

For example, print reports, query static code tables, and input database table data.

(2) The design of the super-class polymorphism should ensure that the use of the super-class inheritance relationship can meet the operation requirements of each subclass.

For example, inheriting from the same "data input" ancestor window, you can complete data input for different structure database tables.

(3) It facilitates the concealment of information, does not damage the integrity of data, and simplifies complex problems.

For example, maintain a database table set with complex relationships, structures, and related access operations. If you do not use a generalization class to close the data

To encapsulate the structure and related operations, the lower-level programmer must have a deep understanding of the database table design and ensure the program algorithm.

Design should not undermine data consistency, which will greatly increase the difficulty of programming and testing, requiring programmers to have a wealth of experience. And adopt

After such generalized classes (public functions and public stored procedures), all the programmer has to do is send "messages" and get "output information.

(4) It is conducive to implementing development specifications and unified interface style.

The biggest practice we have gained in developing foreign software is that we have strict requirements on User Interface (reports, screens) renewals in foreign countries. Institute

The height, width, and start position of a screen button are specified by the X and Y Coordinates precise to the third digit after the decimal point. Such products make people look

It is pleasing to the eye. However, if everyone makes fine adjustments to the interface window and buttons, the workload will inevitably multiply. Use screen templates

Super class inheritance relationships, combined with special processing, can solve the problem.

Obviously, the design and implementation of superclasses must be completed before programmers generally develop instance objects. That is to say, OOSE's upstream System Design

Personnel must be both technical (design and programming) and be able to undertake the program implementation and testing tasks of super-class objects. This is consistent with the upper-layer system of the structured method.

The designers can basically be different from programming. At the same time, superclass objects must frequently absorb the feedback from the special process in the downstream development process (including

User feedback. As a result, it is difficult for oose designers to design and implement super-class objects as they do with structured methods.

After entering the programming stage, it can be a little easier, and they are always inseparable from the programming site.

If superclass objects are not pre-designed and developed during the design phase, most developers of the same project do not have any ancestor objects that can be inherited together.

And does not even use inheritance relationships within the scope of each developer's own role. This is not just oose, but it is barely called oop.

Question 4: how to deal with the ing of Object Model object-oriented relational database model?

Object-Oriented Database Design methods can be used for various databases, such as hierarchical, network, and relational databases. Of course, they also include object-oriented databases.

The Database Design in oose undoubtedly must adopt the object-oriented database design method.

The database design, also known as the database model, is basically composed of three layers: The External Model of the DB Design is viewed from the perspective of a specific dB application;

From the perspective of organizations or enterprises, the DB Design is the conceptual model. The DB Design, that is, the internal model, that processes the characteristics and limitations of specific DBMS. With

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 the local DB from a specific application perspective.

. Interfaces between the external mode and the logical mode are views, stored procedures, and other DB processors on the server.

In the abstract object model, each application is a sub-object of one or more super-class objects.

Ing an object model to a conceptual model is critical to the design of database table objects. The fewer and simpler interfaces between the external mode and the conceptual Mode

The better, such a program is easy to design and the database and program are easy to maintain. That is to say, localization is an important design principle.

Oop is mostly the back-end processing of databases and is based on existing databases. Therefore, whether or not you have performed Object Modeling in the problematic world or

Object models can be reasonably mapped to database logic models (object-oriented database design), and OOP can all work.

Question 5: when programming, do I first check whether there are reusable (inherited) objects? Do I participate in the feedback of lower-level objects on upper-level objects and super-class objects?

It may be necessary for a program to focus on its own share of the structured method, but as a developer of the program design in the object-oriented method, it should

First, check whether there are any objects in the object data dictionary that have been completed by other developers and can be reused by themselves with a little special features. In general

Sharing and reuse should be centrally managed by upper-layer designers to ensure consistency of object styles and avoid conflicts. However, the independence and encapsulation of Objects

And polymorphism are easy to reuse, Which is incomparable to structured systems, and reuse is one of the most important ideas of software development methodology. Upper Layer

It is often impossible for designers to understand all aspects. developers who understand software design theories should adopt the least effort and most effective method even when developing lower-level programs.

Rate programming method, that is, a large number of reuse objects.

When inheriting superclass and reusing others' objects, if any unreasonable design is found, it should be promptly reflected to the Owner of object development.

For upper-level designers, on the one hand, programs should be encouraged to achieve reuse of existing objects, and on the other hand, developers should share the number of objects through

Data Dictionary enables reuse of individual objects to be immediately reflected in the overall object model to ensure consistency during design changes.

2. Comparison between object-oriented and structured methods
Analysis is the problem abstraction (what to do), design is the problem solving (how to do it), and implementation is the problem solution (result ). Any methodology for the objective world

The process of abstraction and solution is the same. In the problem abstraction stage, the structured method is oriented to the process and finds the problem node based on the data transformation process,

Break down the problem. Therefore, unlike the object model emphasized by the object-oriented method, the functional model that describes data transformation is the focus of the structured method.

. If the features in the problematic world are more complex or important than data, structured methods should still be the preferred methodology. If the data structure is complex

There are not many changes. For example, process-oriented analysis and design will bring great confusion to downstream development if there is a systematic change.

Due to different processes, process-oriented functional modules are sometimes different from person to person. The object-oriented object details

Points, starting from the objects in the same problem field, different people have a high rate of reaching the same conclusion.

In terms of design, structured methodologies generate a top-down, well-structured system structure. Each module may maintain strong independence, but it

It is often independent from the database structure, and there is no ing between the function module and the database logic mode. It is difficult to encapsulate the program and data structure together. For example

If the data structure is complex, it is difficult to guarantee the module independence. The abstract system structure of object-oriented methods is usually not the same as the system structure generated by structured methods.

Simple, but it can be mapped to the database structure, it is easy to encapsulate the program and data structure.

There is a "formal principle" in the basic principles of software engineering, that is, the abstract conclusions of the problematic world should be based on the formal language (Graphic Language,

Pseudo code language. Data Flow Diagram, system structure diagram, data dictionary, state transition diagram, and object relationship diagram can be used for structured methods.

And the object-oriented method can use the object model diagram, data dictionary, dynamic model diagram, and functional model diagram.

Similar to the State Migration diagram, the dynamic model diagram is similar to the State Migration diagram. The function model diagram is similar to the data flow diagram.

The public sector system has more than 100 database tables, but the data processing (transformation) is simple. What if the structured methodology was selected at the beginning?

?

There will be no major difference in the initial stage of problem abstraction. Because there are few data transformations, operations on objects and objects can be considered one-to-one correspondence, that is, the most

The object model described at the beginning is basically the same as the functional model. Take the planning management system as an example. The objects are plan administrators and planning administrators.

, Budget overview administrator, statistics administrator. Functions (Operations) include planning, planning, budget summary, and statistics.

The problem exists in the lower abstraction layer.

First, the design of many public superclasses is contrary to the structured method, because it destroys the continuity of the process and the logical hierarchy of the system structure,

Put some lower-layer modules and objects without semantics in Process Analysis on the upper layer of the system structure. Therefore, if you use a structured method, you must inherit

The link is changed to the call relationship of the lower-level module. However, in fact, some statuses (attribute values) of the ancestor object are determined by directly getting instructions from the master module.

From the control point of view, it is indeed in the upper level of the system. If you use a structured method, the result is either to change the system structure to a network type.

To lose the structural features, or give up the design scheme that completes repetitive work in a unified manner.

Secondly, the ing design from the application object model to the Database concept mode is also a sign that the system adopts the object-oriented method. If

The data structure of the objective world may be mapped to the database schema. Because of roads, maintenance units, management units, road conditions, bridges, tunnels and

There are multiple complex relationships between various entities such as the Green Conditions on the road. The results may define a relational database structure like a spider,

This greatly increases the burden of Database Front-end application programming and database maintenance.

In short, if the system uses a structured method, both the system structure and the database structure may become a mesh structure and have nothing to do with each other. Currently

The system structure and database structure both have multiple inheritance structures, and there is a ing relationship between them. Obviously, the former is more complex than the latter,

Poor maintainability, difficult internal reuse, and low reuse rate.

In fact, no matter what methodology is used to develop software, the software handed over to the user should meet the current needs of the user. Users will not

It is found that the benefits brought by developers using advanced methodologies are the first benefit of developers because they greatly reduce the development burden. However

With the passage of time, the biggest benefit is the user, because the long-term quality of the software (including low maintenance costs and long life cycle) brings to the user

Is fundamental.

Iii. methodology is not a law
We understand the methodology as follows:

(1) The purpose of the methodology is to allow future generations to share the success of their predecessors, avoid the failure of their predecessors, and focus their attention on creativity in areas not yet explored.

Labor. Therefore, there is no conflict between methodology and developers' creativity. It neither relies on authority to define non-boundary nor

Give general conclusions through proof and reasoning as the law does. A metaphor is like a world view.

(2) There is no universal methodology, and any methodology has its own limitations. Therefore, software developers do not have to stick to certain characteristics.

Methodology.

For example, the object model graph of the object-oriented method is much simpler and clearer than the structure diagram and data flow diagram of the structured method.

If the public sector system is described in an object model chart, it takes at least dozens of pages. Since the top functional model is consistent with the object model

We use the system structure diagram of the structured method.

(3) Facts show that the OOSE method driven by OOP is indeed more natural than the structured method to abstract the real world, and some OOP engineers

It is indeed quite mature. On the contrary, although structured methods and structured program development tools on open platforms cannot be said to be stuck

Progress is limited.

(4) based on our experience, we have the following suggestions for OOSE practice:

1 It is recommended that all developers be trained on the object-oriented methodology after the methodology is selected.
2 because of the advance development of super-class objects, the upstream design workload of OOSE is heavier than the upstream work workload of the structured method.

Human resources should be more adequate. Otherwise, it is easy to cause confusion and ineffective work to be added or modified several times after downstream development.
3. Because the system has more object classes, an electronic dictionary of object data should be established to facilitate internal reuse and sharing.

Unified Classification Management.
4. There should be strict naming rules. If possible, the naming rules should be integrated into the data dictionary.
5. After underlying development is rolled out, if you find that some instance objects should be generalized into new superclasses, you must append the new superclasses as soon as possible.

DESIGN: The faster the change, the better.
6. After sub-objects inherit from super-class objects, it is common to discover the defects of the super-class design. There should be smooth feedback channels within the development team,

Make the superclass correct in time. Sub-objects cannot be easily blocked, and the system loses unified control. Comply with

Inheritance relationships for instance object development should become the concept of all developers.
7. The benefits of object-oriented design become more significant later, especially in terms of system maintenance and expansion.