BROADENING THE VIEW OF TESTING The construction of object-oriented software begins with the creation of analysis and
23.1 BROADENING THE VIEW OF TESTING The construction of object-oriented software begins with the creation of analysis and
design models (Chapters 21 and 22). Because of the evolutionary nature of the OO software engineering paradigm, these models begin as relatively informal represen- tations of system requirements and evolve into detailed models of classes, class con- nections and relationships, system design and allocation, and object design (incorporating a model of object connectivity via messaging). At each stage, the mod- els can be tested in an attempt to uncover errors prior to their propagation to the next iteration.
“Because of their It can be argued that the review of OO analysis and design models is especially ability to detect and
useful because the same semantic constructs (e.g., classes, attributes, operations, correct defects in
messages) appear at the analysis, design, and code levels. Therefore, a problem in upstream work
the definition of class attributes that is uncovered during analysis will circumvent side products, technical
reviews are at least effects that might occur if the problem were not discovered until design or code (or as important in
even the next iteration of analysis). controlling cost and
For example, consider a class in which a number of attributes are defined during schedule as testing.”
the first iteration of OOA. An extraneous attribute is appended to the class (due to a
Steve McConnell
misunderstanding of the problem domain). Two operations are then specified to manipulate the attribute. A review is conducted and a domain expert points out the error. By eliminating the extraneous attribute at this stage, the following problems and unnecessary effort may be avoided during analysis:
1. Special subclasses may have been generated to accommodate the unneces- sary attribute or exceptions to it. Work involved in the creation of unneces- sary subclasses has been avoided.
2. A misinterpretation of the class definition may lead to incorrect or extraneous class relationships.
CHAPTER 23
OBJECT-ORIENTED TESTING
3. The behavior of the system or its classes may be improperly characterized to accommodate the extraneous attribute.
If the error is not uncovered during analysis and propagated further, the following problems could occur (and will have been avoided because of the earlier review) dur- ing design:
1. Improper allocation of the class to subsystem and/or tasks may occur during system design.
2. Unnecessary design work may be expended to create the procedural design
for the operations that address the extraneous attribute.
3. The messaging model will be incorrect (because messages must be designed for the operations that are extraneous).
If the error remains undetected during design and passes into the coding activity, con- There’s an old saying
siderable effort will be expended to generate code that implements an unnecessary about “nipping
problems in the bud.” attribute, two unnecessary operations, messages that drive interobject communica- If you spend time
tion, and many other related issues. In addition, testing of the class will absorb more reviewing the OOA and time than necessary. Once the problem is finally uncovered, modification of the sys-
OOD models, that’s tem must be carried out with the ever-present potential for side effects that are caused what you’ll do.
by change. During later stages of their development, OOA and OOD models provide substantial information about the structure and behavior of the system. For this reason, these models should be subjected to rigorous review prior to the generation of code.
All object-oriented models should be tested (in this context, the term testing is used to incorporate formal technical reviews) for correctness, completeness, and consis- tency [MGR94] within the context of the model’s syntax, semantics, and pragmatics [LIN94].
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more