《电子工程师手册》学习资料（英文版）Chapter 90 Software Engineering.pdf_大学文库

90 Software engineering d Techniques Methods·Int on modelin Implementation Modeling. CASI 2 Testing, Debugging, and Verification The Origins and Causes of Software Defects. The Taxonomy and Carl A Argila Efficiency of Software Defect Removal. Pre-Test Defect Removal Software Engineering Con Testing Software. Selecting an Optimal Series of Defect Prevention and Removal Operations. Post-Release Defect Removal. Recent Capers Jones Industry Trends in Software Quality Control Software Productivity Research, Inc Analysis of Algorithms. Flow of Control. Abstraction Johannes J Martin Modularity. Simple Hierarchical Structuring. Object-Oriented University of New Orleans Programming.Program Testing 90.1 Tools and Techniquesl Carl A. argila The last decade has seen a revolution in software engineering tools and techniques. This revolution has been fueled by the ever-increasing complexity of the software component of delivered systems. Although the software component of delivered systems may not be the most expensive component, it is usually, however, "in series with the hardware component; if the software doesnt work, the hardware is useless Traditionally, software engineering has focused primarily on computer programming with ad hoc analysis and design techniques. Each software system was a unique piece of intellectual work; little emphasis was placed on architecture, interchangeability of parts, reusability, etc. These ad hoc software engineering methods resulted in the production of software systems which did not meet user requirements, were usually delivered over budget and beyond schedule, and were extraordinarily difficult to maintain and enhance. In an attempt to find some solutions to the" software crisis, "large governmental and private organizations motivated the development of so-called"waterfall"methods. These methods defined formal requirement definition and analysis phases, which had to be completed before commencing a formal design stage, which in turn had to be completed before beginning a formal implementation phase, etc. Although waterfall methods vere usually superior to ad hoc methods, large and complex software systems were still being delivered over budget and beyond schedule, which did not meet user requirements. There were several reasons for this. First, waterfall methods focus on the generation of work products rather than"engineering. Simply put, writing documents is not the same as doing good engineering. Second, the waterfall methods do not support the evolution of system requirements throughout the development life cycle. Also, the prose English specifications roduced within the waterfall methods are not well suited to describing the complex behaviors of software systems The material in this article was originally published by CRC Press in The Electrical Enginee Richard C. Dorf, Editor. 1993. c 2000 by CRC Press LLC

© 2000 by CRC Press LLC 90 Software Engineering 90.1 Tools and Techniques Approach • Methods • Information Modeling • Essential Modeling • Implementation Modeling • CASE Tools 90.2 Testing, Debugging, and Verification The Origins and Causes of Software Defects • The Taxonomy and Efficiency of Software Defect Removal • Pre-Test Defect Removal • Testing Software • Selecting an Optimal Series of Defect Prevention and Removal Operations • Post-Release Defect Removal • Recent Industry Trends in Software Quality Control 90.3 Programming Methodology Analysis of Algorithms • Flow of Control • Abstraction • Modularity • Simple Hierarchical Structuring • Object-Oriented Programming • Program Testing 90.1 Tools and Techniques1 Carl A. Argila The last decade has seen a revolution in software engineering tools and techniques. This revolution has been fueled by the ever-increasing complexity of the software component of delivered systems. Although the software component of delivered systems may not be the most expensive component, it is usually, however, “in series” with the hardware component; if the software doesn’t work, the hardware is useless. Traditionally, software engineering has focused primarily on computer programming with ad hoc analysis and design techniques. Each software system was a unique piece of intellectual work; little emphasis was placed on architecture, interchangeability of parts, reusability, etc. These ad hoc software engineering methods resulted in the production of software systems which did not meet user requirements, were usually delivered over budget and beyond schedule, and were extraordinarily difficult to maintain and enhance. In an attempt to find some solutions to the “software crisis,” large governmental and private organizations motivated the development of so-called “waterfall” methods. These methods defined formal requirement definition and analysis phases, which had to be completed before commencing a formal design stage, which in turn had to be completed before beginning a formal implementation phase, etc. Although waterfall methods were usually superior to ad hoc methods, large and complex software systems were still being delivered over budget and beyond schedule, which did not meet user requirements. There were several reasons for this. First, waterfall methods focus on the generation of work products rather than “engineering.” Simply put, writing documents is not the same as doing good engineering. Second, the waterfall methods do not support the evolution of system requirements throughout the development life cycle. Also, the prose English specifications produced within the waterfall methods are not well suited to describing the complex behaviors of software systems. 1 The material in this article was originally published by CRC Press in The Electrical Engineering Handbook, Richard C. Dorf, Editor, 1993. Carl A. Argila Software Engineering Consultant Capers Jones Software Productivity Research, Inc. Johannes J. Martin University of New Orleans

斗1! The basic, underlying philosophy of how software systems should be developed changed dramatically in 1978 when Tom DeMarco published his truly seminal book, Structured Analysis and System Specification [DeMarco, 1979]. DeMarco proposed that software systems should be developed like any large, engineering systems--by first building scale models of proposed systems so as to investigate their This model-based software engineering approach is analogous to that used by architects to specify and design large complex buildings(see Fig. 90.1). We build scale models of software systems for the same reason that architects build scale models of houses, so that users can visualize living with the systems of the future. These models serve as vehicles for communication and negotiation between users, developers, sponsors, builders, etc. Model-based software engineering holds considerable promise for enabling large, complex software systems to be developed on budget, within schedule, while meeting user requirements [see Harel, 1992] As shown in Fig. 90.2, a number of specific software development models may be built as part of the software development process. These models may be built by different communities of users, developers, customers, etc. Most importantly, however, these models are built in an iterative fashion. Although work products( documents, milestone reviews, code releases, etc )may be delivered chronologically, models are built iteratively throughout the software systems development life cycle In Fig. 90.3 we illustrate the distinction between methodology tool, and work product. A number of differing software development methods have evolved, all based on the underlying model-based philosophy. Different methods may in fact be used for the requirements and analysis phases of project development than for design and implementation. These differing methods may or may not integrate well. Tools such as CASE may support all, or only a part, of a given method. Work products, such as document production or code generation, may be generated manually or by means of Case tools This article will present a synopsis of various practical software engineering techniques which can be used to construct software development models; these techniques are illustrated within the context of a simple case udy system A h One of the most widely accepted approaches in the software engineering industry is to build two software development models. An essential model captures the behavior of a proposed software system, independent aplementation specifics. An essential model of a software system is analogous to the scale model of a house built by an architect; this model is used to negotiate the essential requirements of a system between customers and developers. A second model, an implementation model, of a software system describes the technical asv ne of a proposed system within a particular implementation environment. This model is analogous to the deta e 2000 by CRC Press LLC

© 2000 by CRC Press LLC The basic, underlying philosophy of how software systems should be developed changed dramatically in 1978 when Tom DeMarco published his truly seminal book, Structured Analysis and System Specification [DeMarco, 1979]. DeMarco proposed that software systems should be developed like any large, complex engineering systems—by first building scale models of proposed systems so as to investigate their behavior. This model-based software engineering approach is analogous to that used by architects to specify and design large complex buildings (see Fig. 90.1). We build scale models of software systems for the same reason that architects build scale models of houses, so that users can visualize living with the systems of the future. These models serve as vehicles for communication and negotiation between users, developers, sponsors, builders, etc. Model-based software engineering holds considerable promise for enabling large, complex software systems to be developed on budget, within schedule, while meeting user requirements [see Harel, 1992]. As shown in Fig. 90.2, a number of specific software development models may be built as part of the software development process. These models may be built by different communities of users, developers, customers, etc. Most importantly, however, these models are built in an iterative fashion. Although work products (documents, milestone reviews, code releases, etc.) may be delivered chronologically, models are built iteratively throughout the software system’s development life cycle. In Fig. 90.3 we illustrate the distinction between methodology, tool, and work product. A number of differing software development methods have evolved, all based on the underlying model-based philosophy. Different methods may in fact be used for the requirements and analysis phases of project development than for design and implementation. These differing methods may or may not integrate well. Tools such as CASE may support all, or only a part, of a given method. Work products, such as document production or code generation, may be generated manually or by means of CASE tools. This article will present a synopsis of various practical software engineering techniques which can be used to construct software development models; these techniques are illustrated within the context of a simple case study system. Approach One of the most widely accepted approaches in the software engineering industry is to build two software development models. An essential model captures the behavior of a proposed software system, independent of implementation specifics. An essential model of a software system is analogous to the scale model of a house built by an architect; this model is used to negotiate the essential requirements of a system between customers and developers.A second model, an implementation model, of a software system describes the technical aspects of a proposed system within a particular implementation environment. This model is analogous to the detailed FIGURE 90.1 Model-based software engineering

Model erarchy o声 2… 画画) FIGURE 90.4 Software engineering methods overview. When a station selection button is momentarily depressed, the RBS causes a new station to be selected. Th selection is made on the basis of station-setting information stored within the RBS. The RBS can"memorize new station selections in the following manner: When a given station selection button is depressed longer tha momentary depressions of this button will result in this"memorized"station being selected. The RBS also performs a muting function. While a station is being selected, the rBS will cause the audio system to mute the audio output signal. The RBS will also cause the audio output signal to be muted until new station selection has been successfully memorized. The RBS interfaces with the front-panel station selection buttons by"reading a single-byte memory location Each bit position of this memory location is associated with a particular front-panel station selection button. The value of 0 in a given bit position indicates that the corresponding button is not depressed. The value of 1 in that bit position indicates that the corresponding button is depressed. For example, 0000 0000 indicates no station selection buttons are currently depressed; 0000 0010 indicates that the second button is currently resse The RBS interfaces with the tuning system by means of a common memory location. This single-byte memory location contains a non-negative integer value which represents a station selection.( For example, 0000 0000 might represent 87. 9 MHz, 0000 0001 might represent 88.1 MHz, etc. ) The RBS may "read"this memory location to"memorize"a current station selection. The RBS may also"write"to this memory location to cause the tuning system to select another station Finally, the RBS interfaces with the audio system by sending two signals. The RBS may send a MUTE-ON ignal to the audio system causing the audio system to disable the audio output. A MUTE-OFF signal would cause the audio system to enable the audio output. Information Modeling The construction of an information model is fundamental to so-called object-oriented approaches. An mation model captures a"view"of an application domain within a software system will be built Information models are based on entity-relationship diagrams and underlying textual information. A sample e 2000 by CRC Press LLC

© 2000 by CRC Press LLC When a station selection button is momentarily depressed, the RBS causes a new station to be selected. This selection is made on the basis of station-setting information stored within the RBS. The RBS can “memorize” new station selections in the following manner: When a given station selection button is depressed longer than “momentarily” (say, for more than 2 seconds), the currently selected station will be “memorized.” Future momentary depressions of this button will result in this “memorized” station being selected. The RBS also performs a muting function. While a station is being selected, the RBS will cause the audio system to mute the audio output signal. The RBS will also cause the audio output signal to be muted until a new station selection has been successfully memorized. The RBS interfaces with the front-panel station selection buttons by “reading” a single-byte memory location. Each bit position of this memory location is associated with a particular front-panel station selection button. The value of 0 in a given bit position indicates that the corresponding button is not depressed. The value of 1 in that bit position indicates that the corresponding button is depressed. (For example, 0000 0000 indicates no station selection buttons are currently depressed; 0000 0010 indicates that the second button is currently depressed, etc.) The RBS interfaces with the tuning system by means of a common memory location. This single-byte memory location contains a non-negative integer value which represents a station selection. (For example, 0000 0000 might represent 87.9 MHz, 0000 0001 might represent 88.1 MHz, etc.) The RBS may “read” this memory location to “memorize” a current station selection. The RBS may also “write” to this memory location to cause the tuning system to select another station. Finally, the RBS interfaces with the audio system by sending two signals. The RBS may send a MUTE-ON signal to the audio system causing the audio system to disable the audio output. A MUTE-OFF signal would cause the audio system to enable the audio output. Information Modeling The construction of an information model is fundamental to so-called object-oriented approaches. An information model captures a “view” of an application domain within which a software system will be built. Information models are based on entity-relationship diagrams and underlying textual information. A sample FIGURE 90.4 Software engineering methods overview

SSTEM SYSTEM VENT MUTING 匙EA 2. BUTTON RELEASE recerved 2. BUTTON PUSH onds aher e MUTING FIGURE 90.7 RBS object interface specificatio For each object there is an object interface specification(as shown in Fig. 90.7)which shows the public and private interfaces to an object. An event list is also associated with this specification; it shows how the object will respond to external stimuli. a hierarchy of transformation diagrams is associated with each object specification(as shown in Fig. 90. 8 for the RBS). This diagram defines all of the functions or"methods"which the object performs Some behavior may be expressed by means of a state transition diagram(Fig. 90.9 Implementation Modeling Two principal activities must be accomplished in transitioning from the essential to the implementation model. First, all of the methods and data encapsulated by each object must be mapped to the implementation environ- ment. This process is illustrated in Fig. 90.10. Second, all of the details which were ignored in the essential model (such as user interfaces, communication protocols, hardware limitations, etc. )must now be accounted for Each component of the essential model must be allocated to hardware processors. Within each hardware processor, allocation must be continued to the task level. Within each task, the computer program controlling that task must be described. This latter description is accomplished by means of a module structure chart. As illustrated in Fig. 90.11 for one component of the RBS, the module structure chart is a formal description of each of the computer program units and their interfaces. CASe Tools The term computer-aided software engineering(CASE) is used to describe a collection of tools which automate all or some of various of the software engineering life cycle phases. These tools may facilitate the capturing, tracking and tracing of requirements, the construction and verification of essential and implementation models and the automatic generation of computer programs. Most Case tools have an underlying project repository which stores project-related information, both textual and graphical, and uses this information for producing CASE tool features may include trac Maintenance of all project-related information · Model verification Facilitation of model validation e 2000 by CRC Press LLC

© 2000 by CRC Press LLC For each object there is an object interface specification (as shown in Fig. 90.7) which shows the public and private interfaces to an object. An event list is also associated with this specification; it shows how the object will respond to external stimuli. A hierarchy of transformation diagrams is associated with each object specification (as shown in Fig. 90.8 for the RBS). This diagram defines all of the functions or “methods” which the object performs. Some behavior may be expressed by means of a state transition diagram (Fig. 90.9). Implementation Modeling Two principal activities must be accomplished in transitioning from the essential to the implementation model. First, all of the methods and data encapsulated by each object must be mapped to the implementation environment. This process is illustrated in Fig. 90.10. Second, all of the details which were ignored in the essential model (such as user interfaces, communication protocols, hardware limitations, etc.) must now be accounted for. Each component of the essential model must be allocated to hardware processors. Within each hardware processor, allocation must be continued to the task level. Within each task, the computer program controlling that task must be described. This latter description is accomplished by means of a module structure chart. As illustrated in Fig. 90.11 for one component of the RBS, the module structure chart is a formal description of each of the computer program units and their interfaces. CASE Tools The term computer-aided software engineering (CASE) is used to describe a collection of tools which automate all or some of various of the software engineering life cycle phases. These tools may facilitate the capturing, tracking and tracing of requirements, the construction and verification of essential and implementation models and the automatic generation of computer programs. Most CASE tools have an underlying project repository which stores project-related information, both textual and graphical, and uses this information for producing reports and work products. CASE tool features may include: • Requirements capture, tracing, and tracking • Maintenance of all project-related information • Model verification • Facilitation of model validation FIGURE 90.7 RBS object interface specification

Object interface specification: A component of the essential model; it describes all of the public and private interfaces to an object. State transition diagram: A component of the essential model; it describes event-response behaviors Transformation diagram: A component of the essential model; it describes system functions or"methods. Related Topic 90.3 Programming Methodology erences C. Argila," Object-oriented real-time systems development"(video course notes), Los Angeles: University of Southern California lITV, June 11, 1992. G. Booch, Object-Oriented Design with Applications, Redwood City, Calif. Benjamin/Cummings, 1991 P Coad and E. Yourdon, Object-Oriented Analysis, 2nd ed, New York: Prentice-Hall, 1991 P Coad and E Yourdon, Object-Oriented Design, New York: Prentice-Hall, 1991 T. DeMarco, Structured Analysis and System Specification, New York: Prentice-Hall, 1979 D. Harel,Biting the silver bullet, "Computer, January 1992 J. Rumbaugh et al, Object-O esign, New York: Prentice-Hall, 1991 S. Shlaer and S. Mellor, Object-Oriented Systems Analysis: Modeling the World in Data, New York: Prentice-Hall, 88 Shlaer and S Mellor, Object Life-Cycles: Modeling the World in States, New York: Prentice-Hall, 1992. P. Ward and S. Mellor, Structured Development for Real-Time Systems, New York: Prentice-Hall, vol. 1, 1985; ol.2,1985;vol.3,1986. E Yourdon and L. Constantine, Structured Design, 2nd ed, New York: Prentice-Hall, 1975, 1978. Further information A video course presenting the software engineering techniques described here is available [see Argila, 1992] The author may be contacted for additional information and comments at(800)347-6903 90.2 Testing, debugging, and Verification Achieving acceptable levels of software quality has been one of the most troublesome areas of software neering since the industry began. It has been so difficult to achieve error-free software that, historically, cost of finding and fixing"bugs"has been the most time-consuming and expensive aspect of large-scale software Software quality control is difficult to achieve, but the results of the careful application of defect prevention and defect removal techniques are quite good. The software producers who are most effective in quality control discover several derivative benefits as well: software with the highest quality levels also tends to be the leas expensive to produce, tends to have minimum schedules during development, and also tends to have the highest levels of post-release user satisfaction s The topic of defect prevention is outside the primary scope of this article. However, it is important to note that the set of technologies associated with defect prevention must be utilized concurrently with the technologies defect removal in order to achieve high levels of final quality. The technologies which prevent defects are those concerned with optimizing both clarity and structure and with minimizing ambiguity. Joint application design (JAD) for preventing requirements defects; prototyping; reuse of certified material; clean-room development; any of the standard structured analysis, design, and coding techniques; and quality function deployment(QFD for evaluating end-user quality demands are examples of the technologies associated with defect I Many aspects of total quality management(TQM) programs are also associated with defect prevention e 2000 by CRC Press LLC

© 2000 by CRC Press LLC Object interface specification: A component of the essential model; it describes all of the public and private interfaces to an object. State transition diagram: A component of the essential model; it describes event-response behaviors. Transformation diagram: A component of the essential model; it describes system functions or “methods.” Related Topic 90.3 Programming Methodology References C. Argila, “Object-oriented real-time systems development” (video course notes), Los Angeles: University of Southern California IITV, June 11, 1992. G. Booch, Object-Oriented Design with Applications, Redwood City, Calif.: Benjamin/Cummings, 1991. P. Coad and E. Yourdon, Object-Oriented Analysis, 2nd ed., New York: Prentice-Hall, 1991. P. Coad and E. Yourdon, Object-Oriented Design, New York: Prentice-Hall, 1991. T. DeMarco, Structured Analysis and System Specification, New York: Prentice-Hall, 1979. D. Harel, “Biting the silver bullet,” Computer, January 1992. J. Rumbaugh et al., Object-Oriented Modeling and Design, New York: Prentice-Hall, 1991. S. Shlaer and S. Mellor, Object-Oriented Systems Analysis: Modeling the World in Data, New York: Prentice-Hall, 1988. S. Shlaer and S. Mellor, Object Life-Cycles: Modeling the World in States, New York: Prentice-Hall, 1992. P. Ward and S. Mellor, Structured Development for Real-Time Systems, New York: Prentice-Hall, vol. 1, 1985; vol. 2, 1985; vol. 3, 1986. E. Yourdon and L. Constantine, Structured Design, 2nd ed., New York: Prentice-Hall, 1975, 1978. Further Information A video course presenting the software engineering techniques described here is available [see Argila, 1992]. The author may be contacted for additional information and comments at (800) 347-6903. 90.2 Testing, Debugging, and Verification Capers Jones Achieving acceptable levels of software quality has been one of the most troublesome areas of software engineering since the industry began. It has been so difficult to achieve error-free software that, historically, the cost of finding and fixing “bugs” has been the most time-consuming and expensive aspect of large-scale software development. Software quality control is difficult to achieve, but the results of the careful application of defect prevention and defect removal techniques are quite good. The software producers who are most effective in quality control discover several derivative benefits as well: software with the highest quality levels also tends to be the least expensive to produce, tends to have minimum schedules during development, and also tends to have the highest levels of post-release user satisfaction. The topic of defect prevention is outside the primary scope of this article. However, it is important to note that the set of technologies associated with defect prevention must be utilized concurrently with the technologies of defect removal in order to achieve high levels of final quality. The technologies which prevent defects are those concerned with optimizing both clarity and structure and with minimizing ambiguity. Joint application design (JAD) for preventing requirements defects; prototyping; reuse of certified material; clean-room development; any of the standard structured analysis, design, and coding techniques; and quality function deployment (QFD) for evaluating end-user quality demands are examples of the technologies associated with defect prevention. Many aspects of total quality management (TQM) programs are also associated with defect prevention