USER SYSTEM FIGURE 90.5 RBS information model information model for the RBS is shown in Fig. 90.5. Entities(shown as rectangles)represent"things"or " objects"in the application domain Entities may be established by considering principal nouns or noun phrases in the application domain Entities have attributes associated with them which express the qualities of the entity. Entities participate in relationships; these are shown as diamonds in the entity-relationship diagram Relation hips may be determined by considering principal verbs or verb phrases in the application domain. Relationships have cardinality associated with them and entities may participate conditionally in relationships. Finally, there are special kinds of relationships which show hierarchical relationships between objects Essential Modeling The essential model consists of a number of graphical components with integrated textual information. Figure 90.6 shows the object collaboration model for the RBS. This model depicts how a collection of objects or entities can communicate(by exchanging messages)to perform the proposed system functions. An event list is part of this model; it shows what responses must be produced for a given external stimulus. UTTON 阳E MUTING CONTROLLE SYSTEM RESPONSE outton depressed. 1, Mute audio syster n-mute audio system FIGURE 90.6 RBS object collaboration model. e 2000 by CRC Press LLC
© 2000 by CRC Press LLC information model for the RBS is shown in Fig. 90.5. Entities (shown as rectangles) represent “things” or “objects” in the application domain. Entities may be established by considering principal nouns or noun phrases in the application domain. Entities have attributes associated with them which express the qualities of the entity. Entities participate in relationships; these are shown as diamonds in the entity-relationship diagram. Relationships may be determined by considering principal verbs or verb phrases in the application domain.Relationships have cardinality associated with them and entities may participate conditionally in relationships. Finally, there are special kinds of relationships which show hierarchical relationships between objects. Essential Modeling The essential model consists of a number of graphical components with integrated textual information. Figure 90.6 shows the object collaboration model for the RBS. This model depicts how a collection of objects or entities can communicate (by exchanging messages) to perform the proposed system functions. An event list is part of this model; it shows what responses must be produced for a given external stimulus. FIGURE 90.5 RBS information model. FIGURE 90.6 RBS object collaboration model
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
ELCTNN I PROD PRODUCE MEMORIZE MEMORIZE COMPLETE FIGURE 90.8 RBS transformation diagram IDLE BUTTON PUSHED TRIGGER MUTE AUDIO SYSTEM boREL LEASE ON RELEASE MESSAGE FOR COMPLETION SELECT COMPLETE MEMORIZE COMPLETE TRIGGER UNMUTE AUDIO SYSTEM FIGURE90.9RBS state transition diagram. Document production Configuration management Collection and reporting of project management data Case data exchange e 2000 by CRC Press LLC
© 2000 by CRC Press LLC • Document production • Configuration management • Collection and reporting of project management data • CASE data exchange FIGURE 90.8 RBS transformation diagram. FIGURE 90.9 RBS state transition diagram
OBJECT 1 OBJECT 2 DATA ETHOD HTTTTII P PROCESSOR 2 PROCESSOR N TASK o…oooo.o MODULES FIGURE 90.10 Implementation modeling COMPETE MESSGE MEASURE ° ELE AUDIO PUSH SAGE MESSAGE SYSTEM FIGURE 90.11 RBS module structure chart Defining Terms CASE: Computer-aided software engineering. A general term for tools which automate various of the software engineering life cycle phases. Essential model: A software engineering model which describes the behavior of a proposed software system independent of implementation aspects. Implementation model: A software engineering model which describes the technical aspects of a proposed system within a particular implementation environment. Information model: A software engineering model which describes an application domain as a collection of bjects and relationships between those objects Module structure chart: A component of the implementation model; it describes the architecture of a single computer program. Object: An"entity or" thing"within the application domain of a proposed software system Object collaboration model: A component of the essential model; it describes how objects exchange messages in order to perform the work specified for a proposed system. e 2000 by CRC Press LLC
© 2000 by CRC Press LLC Defining Terms CASE: Computer-aided software engineering. A general term for tools which automate various of the software engineering life cycle phases. Essential model: A software engineering model which describes the behavior of a proposed software system independent of implementation aspects. Implementation model: A software engineering model which describes the technical aspects of a proposed system within a particular implementation environment. Information model: A software engineering model which describes an application domain as a collection of objects and relationships between those objects. Module structure chart: A component of the implementation model; it describes the architecture of a single computer program. Object: An “entity” or “thing” within the application domain of a proposed software system. Object collaboration model: A component of the essential model; it describes how objects exchange messages in order to perform the work specified for a proposed system. FIGURE 90.10 Implementation modeling. FIGURE 90.11 RBS module structure chart
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