How to develop software

The well-known software crisis began to erupt in the mid-1960s. In order to overcome this crisis, the term software engineering was introduced at two consecutive prestigious NATO conferences in 1968 and 1969, and has continued to evolve and improve ever since. At the same time, software researchers are constantly exploring new software development methods. So far, eight types of software development methods have been formed.

One, 1972 Parnas method

Two, 1978 SASA method

Three, 1975 The data structure-oriented software development method (still widely used)

Four, problem analysis

Five, object-oriented software development methods

Six, visual development methods

Four, Parnas method

Five, object-oriented software development methods

Six, visual development methods

Six. p>

I. Parnas method

The earliest software development method was proposed by D. Parnas in 1972. Since software at that time had serious problems in terms of maintainability and reliability, the method proposed by Parnas was aimed at these two problems. First, Parnas proposed the principle of information concealment: list the factors that may change in the future during the outline design, and put these factors inside individual modules during module partitioning. In this way, when the software needs to be modified in the future due to the change of these factors, only these individual modules need to be modified, and other modules will not be affected. Information hiding technology not only improves the maintainability of software, but also avoids the spread of errors and improves the reliability of software. Now the principle of information hiding has become an important principle in software engineering.

The second principle proposed by Parnas is that software should be designed to take measures against all kinds of unexpected failures that may occur. Software is very fragile, it is likely to cause serious accidents because of a small error, so it is necessary to strengthen the prevention. For example, before assigning a device for use, the device status word should be taken to check whether the device is normal. In addition, the check between modules should also be strengthened to prevent the spread of errors.

Parnas provides insights into software development. Unfortunately, he does not give a clear workflow. So this method cannot be used independently, but only as a complement to other methods.

The second ?

In 1978, E. Yourdon and L. L. Constantine proposed a structured approach, that is, the SASD method, which can also be called the function-oriented software development method or data flow-oriented software development method. 1979 TomDeMarco further improved this method.

The Yourdon method was the most widely used software development method in the 1980s. It begins with a requirements analysis of the software using Structured Analysis (SA), followed by a general design using Structured Design (SD) methods, and ends with Structured Programming (SP). This method not only has clear development steps, SA, SD, SP complement each other, all in one go, and gives two types of typical software structure (transformational and transactional), easy to refer to, so that the success rate of software development is greatly improved, thus favored by software developers.

Three, data structure-oriented software development methods

Jackson method

In 1975, M. A. Jackson proposed a class of software development methods are still widely used. This method starts from the input and output data structure of the target system, derives the framework structure of the program, and then adds other details to get a complete program structure diagram. This approach is particularly effective for small to medium-sized systems with well-defined input and output data structures, such as file form processing in business applications. This method can also be combined with other methods for the detailed design of modules.

The Jackson method is sometimes referred to as the data structure-oriented approach to software design.

Warnier method

In 1974, J. D. Warnier proposed a software development method similar to the Jackson method.

There are three differences: one is that they use different graphical tools, using Warnier diagrams and Jackson diagrams, respectively; another difference is the use of different pseudo-code; the main difference is that in the construction of the program framework, the Warnier method only considers the input data structure, while the Jackson method not only considers the input data structure, but also considers the output data structure. .

Four, Problem Analysis Method

PAM Problem Analysis Method.PAM () is a software development method proposed by Hitachi in the late 1980s.

The PAM method hopes to balance the strengths of Yourdon's method, Jackson's method, and bottom-up software development methods while avoiding their shortcomings. Its basic idea is: taking into account the input and output data structures, guiding the decomposition of the system, and gradually synthesizing under the guidance of system analysis. The specific steps of this method are: derive the basic processing frames from the input and output data structures; analyze the sequential relationship between these processing frames; synthesize the processing frames step by step according to the sequential relationship until the PAD diagram of the whole system is drawn. As can be seen from the above steps, this method is essentially a comprehensive bottom-up approach, but before the gradual synthesis of a purposeful decomposition has been carried out, the purpose of which is to take into account the input and output data structure of the system.

Another advantage of the PAM approach is the use of the PAD diagram. This is a two-dimensional tree-structured diagram and is by far one of the best detailed design representations, far superior to NS diagrams and the PDL language.

This method is more popular in Japan and has a high success rate in software development. Because of the same gulf between the input and output data structures and the overall system, this approach is still only applicable to small and medium-sized problems.

Fifth, object-oriented software development methods

Object-oriented technology is a revolution in software technology, a milestone in the history of software development.

With the development of OOP (Object-Oriented Programming) to OOD (Object-Oriented Design) and OOA (Object-Oriented Analysis), the object-oriented software development methodology OMT () was eventually formed. This is a combination of bottom-up and top-down methods, and it is based on object modeling so that it not only takes into account the input and output data structures, but actually includes all the data structures of objects. So OMT completely realizes what PAM did not fully achieve. Not only that, OO technology in the requirements analysis, maintainability and reliability of the three key aspects of software development and quality indicators have made substantial breakthroughs, completely solved the serious problems in these areas, thus announcing the arrival of the end of the software crisis.

Bottom-up generalization

The first step in OMT is to construct a system model, starting with a statement of the problem. The system of classes is derived from the real system, i.e., the object model includes the attributes of classes, the inheritance relationships with subclasses and parent classes, and the associations between classes. A class is an abstraction of a set of concrete instances (objective objects) with similar properties and behaviors, and a parent class is a subsumption of several subclasses. Thus it is a bottom-up induction process. In the bottom-up induction process, top-down modifications may be required to make the entire class system more rational in order for the subclasses to inherit the attributes and behaviors of the parent class more rationally. Since this class system is constructed from concrete to abstract and back again, it conforms to the laws of human thinking, and thus can accomplish the task faster and more conveniently. This is in contrast to the top-down Yourdon method. Constructing a system model is the most difficult step in the Yourdon method, because the top-down "top" is an airy building that lacks a solid foundation, and the functional decomposition is quite arbitrary, so it requires the developer to have rich experience in software development. In OMT, this can be accomplished more quickly by the average developer. After the object model is established, it is easy to derive a dynamic model and a functional model on top of it. Together, these three models form the system model that requires a solution.

Top-down decomposition

After the system model has been created, the work is decomposition. Unlike the Yourdon method, which decomposes by function, in OMT decomposition is usually done by Service. A Service is a collection of related functions that have *** the same goal, such as I/O processing, graphics processing, and so on. This step of decomposition is usually very clear, and further decomposition of these subsystems is relatively easy because it is based on a more specific system model. So OMT also has the advantage of the top-down approach, i.e., it can effectively control the complexity of the module while avoiding the difficulties and uncertainties of functional decomposition in the Yourdon approach.

OMT is based on the object model

Each object class consists of data structures (attributes) and operations (behaviors), and all the data structures concerned (including input and output data structures) become the basis for software development. Therefore the gap between the input and output data structures in Jackson method and PAM and the whole system no longer exists in OMT.OMT not only has the advantages of Jackson method and PAM, but also can be applied to large systems. More importantly, in the Jackson and PAM methods, when their starting point input and output data structures (i.e., the boundaries of the system) change, the whole software must be pushed back. In OMT, however, a change in the system boundary is simply a matter of adding or subtracting a few objects, and the entire system is altered very little.

Thorough Requirements Analysis

Incomplete requirements analysis is one of the major causes of software failure. This danger persists even today. Traditional methods of software development do not allow the user's requirements to change during the development process, which leads to all sorts of problems. It is for this reason that prototyping methods have been proposed, with the introduction of exploratory, experimental and evolutionary prototypes that actively encourage users to improve their requirements. After each improvement in the requirements and the formation of new evolutionary prototypes for users to try, until the user is basically satisfied, greatly improving the success rate of the software. But it requires software developers to be able to quickly generate these prototypes, which requires the support of tools that automatically generate code.

OMT solves this problem completely. Because the requirements analysis process has been aligned with the system modeling process, the developer-user discussion begins with a concrete example (entity) that the user is familiar with. Developers must figure out the reality of the system in order to derive the system model, which makes users and developers have *** the same language, to avoid the traditional requirements analysis of the problems that may arise.

Maintainability is greatly improved

Software development methods prior to OMT were based on functional decomposition. This is despite the fact that software engineering has made great efforts to bring about major improvements in maintainability. But essentially, software based on functional decomposition is not easy to maintain. This is because any change in functionality will result in a major change in the software system developed, or even a complete overhaul of the system. More seriously, in such software systems, modification is difficult. For various reasons, even minor modifications may introduce new bugs. So traditional development methods are likely to cause a series of serious problems such as uncontrolled growth in software costs and lack of assurance of software quality. It is OMT that has led to a qualitative improvement in software maintainability.

OMT is based on an object model of the target system, not a decomposition of functions. Functionality is the use of objects, which depends on the details of the application and changes during development. Since objects exist objectively, the nature of an object is more stable than the use of an object when requirements change, resulting in a more stable software system built on an object structure.

More importantly, OMT completely solves the maintainability of software. In OO language, subclasses can not only inherit the attributes and behaviors of the parent class, but also can overload a certain behavior (virtual function) of the parent class. Using this feature, we can easily make functional modifications: introduce a subclass of a certain class and overload some behaviors (i.e., virtual functions or virtual methods) that are to be modified, i.e., redefine them. Since modifications are no longer introduced in the original program module, the modifiability of the software, and thus its maintainability, is completely solved.OO technology also improves the reliability and robustness of the software.

Six, visual development methods

Visual development is one of the two biggest hotspots in the software world in the 90s. With the rise of the graphical user interface, the user interface in the software system accounted for an increasing proportion, some even as high as 60 to 70%. The reason for this problem is that graphical

interface elements are inconvenient to generate. For this reason, Windows provides an Application Programming Interface (API), which contains more than 600 functions that greatly facilitate the development of graphical user interfaces. But in this batch of functions, a large number of function parameters and the use of a greater number of relevant constants, so that the development of Windows API-based development has become quite difficult. For this reason, Borland C introduced Object Windows programming. It encapsulates the various parts of the API in object classes, providing a large number of predefined classes and defining many member functions for these. Utilizing the inheritance of subclasses from the parent class, and instance references to functions of the class, application development can eliminate the need for a large number of class definitions, a large number of member function definitions, or only a few modifications to define subclasses.

Object Windows also provides a number of standard default treatments that greatly reduce the workload of application development. However, mastering them is still a heavy burden for non-specialists. For this reason people have developed a number of visual development tools using the Windows API or Borland C's Object Windows.

Visual development is in the visual development tools to provide a graphical user interface, through the operation of interface elements, such as menus, buttons, dialog boxes, edit boxes, radio boxes, check boxes, list boxes and scroll bars, etc., by the visual development tools to automatically generate applications.

This type of application software works in an event-driven manner. For each event, the system generates a corresponding message, which is then passed to the corresponding message response function. These message response functions are automatically loaded by the visual development tool when generating the software