Prof. Dr. Hongwei Zhang 张洪伟 zhang_hw 99@hotmail. com http: //www. mhhe. com/ SOFTWARE ENGINEERING: A Practitioner's Approach w/ E-Source on CD-ROM, Fifth Edition Author: Roger S. Pressman, Chapter 1 - The Product Overview • Software is designed and built by software engineers. • Software is used by virtually everyone in society. • Software engineers have a moral obligation to build reliable software that does no harm to other people. 1
• Software users are only concerned with whether or not software products meet their expectations and make their tasks easier to complete. • Software engineers view computer software, as being made up of the programs, documents, and data required to design and build the system. Software • Software is both a product and a vehicle for developing a product. 2
• Software does not wear out, but it does deteriorate. • Currently, most software is still custom-built. Software Application Types • System software • Real-time software • Business software • Engineering and scientific software • Embedded software • Personal computer software • Web-based software Artificial intelligence software • Software is engineered not manufactured. 3
• Giving software projects to outside parties to develop solves software project management problems. The reality is people who can抰 manage internal software development problems will struggle to manage or control the external development of software too. • Adding people is a good way to catch up when a project is behind schedule. The reality is that adding people only helps the project schedule when is it done in a planned, well-coordinated manner. • A general statement of objectives from the customer is all that is needed to begin a software project. The reality is without constant communication between the customer and the developers it is impossible to build a software product that meets the customer's real needs. 4
• Project requirements change continually and change is easy to accommodate in the software design. The reality is that every change has far-reaching and unexpected consequences. Changes to software requirements must be managed very carefully to keep a software project on time and under budget. • Once a program is written, the software engineer's work is finished. The reality is that maintaining a piece of software is never done, until the software product is retired from service. 5
• There is no way to assess the quality of a piece of software until it is actually running on some machine. The reality is that one of the most effective quality assurance practices (formal technical reviews) can be applied to any software design product and can serve as a quality filter very early in the product life cycle. • The only deliverable from a successful software project is the working program. The reality is the working program is only one of several deliverables that arise from a well-managed software project. The documentation is also important since it provides a basis for software support after delivery. 6
Software engineering is all about the creation of large and unnecessary documentation. The reality is that software engineering is concerned with creating quality. This means doing things right the first time and not having to create deliverables needed to complete or maintain a software product. This practice usually leads to faster delivery times and shorter development cycles. 7
Chapter 2 - The Process Overview • The roadmap to building high quality software products is software process. • Software processes are adapted to meet the needs of software engineers and managers as they undertake the development of a software product. • A software process provides a framework for managing activities that can very easily get out of control. • Different projects require different software processes. 8
• The software engineer's work products (programs, documentation, data) are produced as consequences of the activities defined by the software process. • The best indicators of how well a software process has worked are the quality, timeliness, and long-term viability of the resulting software product. Software Engineering Software engineering encompasses a process, management techniques, technical methods, and the use of tools. 9
Generic Software Engineering Phases • Definition phase - focuses on what (information engineering, software project planning, requirements analysis). • Development phase - focuses on how (software design, code generation, software testing). • Support phase - focuses on change (corrective maintenance, adaptive maintenance, perfective maintenance, preventative maintenance). Software Engineering Umbrella Activities • Software project tracking and control • Formal technical reviews Software quality assurance 10
• Software configuration management • Document preparation and production • Reusability management • Measurement • Risk management Common Process Framework • Software engineering work tasks • Project milestones • Work products Quality assurance points 11
Software Engineering Institute (SEI) Capability Maturity Model (CMM) • Level 1: Initial (ad hoc software processes) • Level 2: Repeatable (able to repeat earlier successes) • Level 3: Defined (management and engineering processes documented, standardized, and integrated into organization-wide software process) • Level 4; Managed (software process and products are quantitatively understood and controlled using detailed measures) 12
• Level 5: Optimizing (continuous process improvement is enabled by quantitative feedback from the process and testing innovative ideas) Software Process Models • Linear Sequential Model (old fashioned but reasonable approach when requirements are well understood) Prototyping Model (good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product) 13
• Rapid Application and Development (RAD) Model (makes heavy use of reusable software components with an extremely short development cycle) • Incremental Model (delivers software in small but usable pieces, each piece builds on pieces already delivered) • Spiral Model (couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model) • Win-Win Spiral Model (eliciting software requirements defined through negotiation between customer and developer, where each party attempts to balance technical and business constraints) 14
• Concurrent Development Model (similar to spiral model often used in development of client/server applications) • Component-Based Development (spiral model variation in which applications are built from prepackaged software components called classes) • Formal Methods Model (rigorous mathematical notation used to specify, design, and verify computerbased systems) Fourth Generation (4 GT) Techniques (software tool is used to generate the source code for a software system from a high level specification representation) 15
Chapter 10 - System Engineering Overview • Before software can be engineered, the system it is part of must be understood. The overall objective of the system must be determined, the role of the system elements (hardware, software, people, data, etc. ) must be identified, and the operational requirements must be created. A representation (i. e. prototype, specification, symbolic model) of the system is produced as the result of the system engineering process. It is important that system engineering work products be managed using the quality assurance techniques discussed in Chapter 8. 16
Systems • Don't take a "software-centric" view of the system; consider all system elements before focusing on software. • Good system engineering begins with a clear understanding of the "world view" and progressively narrows until technical detail is understood. • Complex systems are actually a hierarchy of macroelements that are themselves systems 17
Computer-Based System Elements • Software • Hardware • People • Database • Documentation • Procedures 18
System Engineering Hierarchy • World view • Domain view • Element view • Detailed view 19
System Modeling • Define the processes that serve the needs of the view under consideration • Represent the process behavior and the assumptions on which the behavior is modeled • Explicitly define the exogenous (links between constituents) and endogenous (links between constituent components) input to the model 20
• Represent all linkages (including outputs) required to understand the view System Model Restraining Factors • Assumptions • Simplifications • Limitations • Constraints • Preferences 21
System Simulation • If simulation capability is not available for a reactive system, project risk increases. • Consider using an iterative process model that will allow the delivery and testing of incrementally more complete products. 22
Business Process Engineering Hierarchy • Information Strategy Planning (world view) • Business Area Analysis (domain view) • Business System Design (element view - software engineers) Construction and Integration (detailed view - software engineers) 23
Business Process Engineering Architectures • Data architecture - provides framework for information needs of a business or business function • Applications architecture - those system elements that transform objects within the data architecture for some business purpose • Technology infrastructure - provides foundation for the data and application architectures 24
Product Engineering Hierarchy • Requirements engineering (world view) • Component engineering (domain view) • Analysis and Design modeling (element view - software engineers) Construction and Integration (detailed view - software engineers) 25
Requirements Engineering • Requirements elicitation (find out from customers what the product objectives are, what is to be done, how the product fits into business needs, and how the product is used on a day to day basis) • Requirements analysis and negotiation (requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs) 26
• Requirements specification (work product produced describing the function, performance, and development constraints for a computer-based system) • System modeling (system representation that shows relationships among the system components) • Requirements validation (examines the specification to ensure requirement quality and that work products conform to agreed upon standards) Requirements management (set of activities that help project team to identify, control, and track requirements and changes as project proceeds) 27
Traceability Tables • Features traceability table • Source traceability table • Dependency traceability table • Subsystem traceability table • Interface traceability table 28
System Model Template • User interface · Input · Process and control functions · Output · Maintenance and self test Systems Modeling Process 29
• System Context Diagram (SCD) - top level node in system hierarchy used to establish the boundary between the system being implemented (system model template serves as its basis) • System Flow Diagram (SFD) - refinement of the process and control functions from SCD, derived by identifying the major subsystems and lines of information flow (precursor to Data Flow Diagram discussed in Chapter 12) 30
• Initial SFD is becomes the top level node of a hierarchy of more successively more detailed SFD's • System Specification - developed by writing narrative description for each subsystem and definitions for all data that flow between subsystems 31
Chapter 11 - Analysis Concepts and Principles Overview After system engineering is completed, software engineers need to look at the role of software in the proposed system. Software requirements analysis is necessary to avoid creating a software product that fails to meet the customer's needs. Data, functional, and behavioral requirements are elicited from the customer and refined to create a specification that can be used to design the system. Software requirements work products must be reviewed for clarity, completeness, and consistency. 32
Requirements Analysis • Software engineering task that bridges the gap between system level requirements engineering and software design. • Provides software designer with a representation of system information, function, and behavior that can be translated to data, architectural, and component-level designs 33
• Expect to do a little bit of design during analysis and a little bit of analysis during design. Software Requirements Analysis Phases • Problem recognition • Evaluation and synthesis (focus is on what not how) • Modeling • Specification • Review 34
Software Requirements Elicitation • Customer meetings are the most commonly used technique. • Use context free questions to find out customer's goals and benefits, identify stakeholders, gain understanding of problem, determine customer reactions to proposed solutions, and assess meeting effectiveness. If many users are involved, be certain that a representative cross section of users is interviewed. 35
Facilitated Action Specification Techniques (FAST) • Meeting held at neutral site, attended by both software engineers and customers. • Rules established for preparation and participation. • Agenda suggested to cover important points and to allow for brainstorming. • Meeting controlled by facilitator (customer, developer, or outsider). • Definition mechanism (flip charts, stickers, electronic device, etc. ) is used. • Goal is to identify problem, propose elements of solution, negotiate different approaches, and specify a preliminary set of solution requirements. 36
Quality Function Deployment (QFD) • Translates customer needs into technical software requirements. • Uses customer interviews, observation, surveys, and historical data for requirements gathering. • Customer voice table (contains summary of requirements) Normal requirements (must be present in product for customer to be satisfied) 37
• Expected requirements (things like ease of use or reliability of operation, that customer assumes will be present in a professionally developed product without having to request them explicitly) • Exciting requirements (features that go beyond the customer's expectations and prove to be very satisfying when they are present) • Function deployment (used during customer meetings to determine the value of each function required for system) 38
• Task deployment (examines the behavior of product within it environment) Value analysis (used to determine the relative priority of requirements during function, information, and task deployment) • Information deployment (identifies data objects and events produced and consumed by the system) 39
Use-Cases • Scenarios that describe how the product will be used in specific situations. • Written narratives that describe the role of an actor (user or device) as interaction with the system occurs. • Use-cases are designed from the actor's point of view. • Not all actors can be identified during the first iteration of requirements elicitation, but it is important to identify the primary actors before developing the use -cases. 40
Analysis Principles • The information domain of the problem must be represented and understood. • The functions that the software is to perform must be defined. Software behavior must be represented. 41
• Models depicting information, function, and behavior must be partitioned in a hierarchical manner that uncovers detail. • The analysis process should move from the essential information toward implementation detail. Information Domain • Encompasses all data objects that contain numbers, text, images, audio, or video. 42
• Information content or data model (shows the relationships among the data and control objects that make up the system) • Information flow (represents the manner in which data and control objects change as each moves through the system) Information structure (representations of the internal organizations of various data and control items) 43
Modeling • Data model (shows relationships among system objects) • Functional model (description of the functions that enable the transformations of system objects) • Behavioral model (manner in which software responds to events from the outside world) Partitioning • Process that results in the elaboration of data, function, or behavior. 44
• Horizontal partitioning is a breadth-first decomposition of the system function, behavior, or information, one level at a time. • Vertical partitioning is a depth-first elaboration of the system function, behavior, or information, one subsytem at a time. Software Requirements Views Essential view - presents the functions to be accomplished and the information to be processed without regard to implementation 45
• Implementation view - presents the real world manifestation of processing functions and information structures. • Avoid the temptation to move directly to the implementation view, assuming that the essence of the problem is obvious. 46
Software Prototyping • Throwaway prototyping (prototype only used as a demonstration of product requirements, finished software is engineered using another paradigm) • Evolutionary prototyping (prototype is refined to build the finished system) • Customer resources must be committed to evaluation and refinement of the prototype. Customer must be capable of making requirements decisions in a timely manner. 47
Prototyping Methods and Tools • Fourth generation techniques (4 GT tools allow software engineer to generate executable code quickly) ·Reusable software components (assembling prototype from a set of existing software components) ·Formal specification and prototyping environments (can interactively create executable programs from software specification models) 48
Specification Principles • Separate functionality from implementation. • Develop a behavioral model that describes functional responses to all system stimuli. • Define the environment in which the system operates and indicate how the collection of agents will interact with it. Create a cognitive model rather than an implementation model. 49
• Recognize that the specification must be extensible and tolerant of incompleteness. • Establish the content and structure of a specification so that it can be changed easily. Specification Representation • Representation format and content should be relevant to the problem. • Information contained within the specification should be nested. • Diagrams and other notational forms should be restricted in number and consistent in use. 50
• Representations should be revisable. Specification Review Conducted by customer and software developer. • Once approved, the specification becomes a contract for software development. • The specification is difficult to test in a meaningful way. Assessing the impact of specification changes is hard to do. 51
Chapter 12 - Analysis Modeling The analysis model is the first technical representation of a system. Analysis modeling uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way. Building analysis models helps make it easier to uncover requirement inconsistencies and omissions. Two types of analysis modeling are commonly used: structured 52
analysis (discussed in this chapter) and objectoriented analysis (discussed in Chapter 21). Data modeling uses entity-relationship diagrams to define data objects, attributes, and relationships. Functional modeling uses data flow diagrams to show data are transformed inside the system. Behavioral modeling uses state transition diagrams to show the impact of events. Analysis work products must be reviewed for completeness, correctness, and consistency. The SEPA web site contains descriptions of several classical analysis techniques (DSSD, JSD, SADT). 53
Structured Analysis (De. Marco) • Analysis products must be highly maintainable, especially the software requirements specification. • Problems of size must be dealt with using an effective method of partitioning. • Graphics should be used whenever possible. • Differentiate between the logical (essential) and physical (implementation) considerations. • Find something to help with requirements partitioning and document the partitioning before specification. 54
• Devise a way to track and evaluate user interfaces. • Devise tools that describe logic and policy better than narrative text. Analysis Model Objectives • Describe what the customer requires. • Establish a basis for the creation of a software design. Devise a set of requirements that can be validated once the software is built. 55
Analysis Model Elements • Data dictionary - contains the descriptions of all data objects consumed or produced by the software • Entity relationship diagram (ERD) - depicts relationships between data objects • Data flow diagram (DFD) - provides an indication of how data are transformed as they move through the system; also depicts functions that transform the data flow (a function is represented in a DFD using a process specification or PSPEC) • State transition diagram (STD) - indicates how the system behaves as a consequence of external 56
• events, states are used to represent behavior modes. Arcs are labeled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC) Data Modeling Elements (ERD) • Data object - any person, organization, device, or software product that produces or consumes information • Attributes - name a data object instance, describe its characteristics, or make reference to another data object Relationships - indicate the manner in which data objects are connected to one another 57
Cardinality and Modality (ERD) • Cardinality - in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object (1: 1, 1: N, M: N) • Modality - zero (0) for an optional object relationship and one (1) for a mandatory relationship Functional Modeling and Information Flow (DFD) 58
• Shows the relationships of external entities, process or transforms, data items, and data stores • DFD's cannot show procedural detail (e. g. conditionals or loops) only the flow of data through the software • Refinement from one DFD level to the next should follow approximately a 1: 5 ratio (this ratio will reduce as the refinement proceeds) To model real-time systems, structured analysis notation must be available for time continuous data and event processing (e. g. Ward and Mellor or Hately and Pirbhai) 59
Behavioral Modeling (STD) • State transition diagrams represent the system states and events that trigger state transitions • STD's indicate actions (e. g. process activation) taken as a consequence of a particular event • A state is any observable mode of behavior • Hatley and Pirbhai control flow diagrams (CFD) can also be used for behavioral modeling 60
Creating Entity Relationship Diagrams • Customer asked to list "things" that application addresses, these things evolve into input objects, output objects, and external entities • Analyst and customer define connections between the objects • One or more object-relationship pairs is created for each connection The cardinality and modality are determined for an object-relationship pair 61
• Attributes of each entity are defined • The entity diagram is reviewed and refined Creating Data Flow Diagram • Level 0 data flow diagram should depict the system as a single bubble • Primary input and output should be carefully noted • Refinement should begin by consolidating candidate processes, data objects, and data stores to be represented at the next level 62
• Label all arrows with meaningful names • Information flow must be maintained from one level to level • Refine one bubble at a time • Write a PSPEC (a "mini-spec" written using English or another natural language or a program design language) for each bubble in the final DFD 63
Creating Control Flow Diagrams • Begin by stripping all the data flow arrows form the DFD • Events (solid arrows) and control items (dashed arrows) are added to the diagram • Add a window to the CSPEC (contains an STD that is a sequential specification of the behavior) for each bubble in the final CFD Data Dictionary Contents 64
• Name - primary name for each data or control item, data store, or external entity • Alias - alternate names for each data object • Where-used/how-used - a listing of processes that use the data or control item and how it is used (e. g. input to process, output from process, as a store, as an external entity) • Content description - notation for representing content Supplementary information - other data type information, preset values, restrictions, limitations, etc. 65
Chapter 13 - Design Concepts and Principles Overview A software design is a meaningful engineering representation of some software product that is to be built. A design can be traced to the customer's requirements and can be assessed for quality against predefined criteria. During the design process the software requirements model is transformed into design models that describe the details of the data structures, system architecture, interface, and components. Each design product is reviewed for quality before moving to the next phase of software development. 66
Design Specification Models • Data design - created by transforming the analysis information model (data dictionary and ERD) into data structures required to implement the software Architectural design - defines the relationships among the major structural elements of the software, it is derived from the system specification, the analysis model, and the subsystem interactions defined in the analysis model (DFD) 67
• Interface design - describes how the software elements communicate with each other, with other systems, and with human users; the data flow and control flow diagrams provide much the necessary information • Component-level design - created by transforming the structural elements defined by the software architecture into procedural descriptions of software components using information obtained from the PSPEC, CSPEC, and STD Design Guidelines A design should • exhibit good architectural structure • be modular 68
• contain distinct representations of data, architecture, interfaces, and components (modules) • lead to data structures that are appropriate for the objects to be implemented and be drawn from recognizable design patterns • lead to components that exhibit independent functional characteristics • lead to interfaces that reduce the complexity of connections between modules and with the external environment • be derived using a reputable method that is driven by information obtained during software requirements analysis 69
Design Principles The design • process should not suffer from tunnel vision • should be traceable to the analysis model • should not reinvent the wheel • should minimize intellectual distance between the software and the problem as it exists in the real world 70
• should exhibit uniformity and integration • should be structured to accommodate change • should be structured to degrade gently, even with bad data, events, or operating conditions are encountered • should be assessed for quality as it is being created should be reviewed to minimize conceptual (semantic) errors 71
Fundamental Software Design Concepts • Abstraction - allows designers to focus on solving a problem without being concerned about irrelevant lower level details (procedural abstraction - named sequence of events, data abstraction - named collection of data objects) • Refinement - process of elaboration where the designer provides successively more detail for each design component • Modularity - the degree to which software can be understood by examining its components independently of one another 72
• Software architecture - overall structure of the software components and the ways in which that structure provides conceptual integrity for a system • Control hierarchy or program structure - represents the module organization and implies a control hierarchy, but does not represent the procedural aspects of the software (e. g. event sequences) Structural partitioning - horizontal partitioning defines three partitions (input, data transformations, and output); vertical partitioning (factoring) distributes control in a top-down manner (control decisions in top level modules and processing work in the lower level modules) 73
• Data structure - representation of the logical relationship among individual data elements (requires at least as much attention as algorithm design) • Software procedure - precise specification of processing (event sequences, decision points, repetitive operations, data organization/structure) • Information hiding - information (data and procedure) contained within a module is inaccessible to modules that have no need for such information 74
Modular Design Method Evaluation Criteria • Modular decomposability - provides systematic means for breaking problem into subproblems • Modular composability - supports reuse of existing modules in new systems • Modular understandability - module can be understood as a stand-alone unit • Modular continuity - side-effects due to module changes minimized Modular protection - side-effects due to processing errors minimized 75
Control Terminology • Span of control (number of levels of control within a software product) • Depth (distance between the top and bottom modules in program control structure) • Fan-out or width (number of modules directly controlled by a particular module) • Fan-in (number of modules that control a particular module) • Visibility (set of program components that may be called or used as data by a given component) 76
• Connectivity (set of components that are called directly or are used as data by a given component) Effective Modular Design • Functional independence - modules have high cohesion and low coupling • Cohesion - qualitative indication of the degree to which a module focuses on just one thing Coupling - qualitative indication of the degree to which a module is connected to other modules and to the outside world 77
Design Heuristics for Effective Modularity • Evaluate the first iteration of the program structure to reduce coupling and improve cohesion. • Attempt to minimize structures with high fan-out; strive for fan-in as structure depth increases. • Keep the scope of effect of a module within the scope of control for that module. 78
• Evaluate module interfaces to reduce complexity, reduce redundancy, and improve consistency. • Define modules whose function is predictable and not overly restrictive (e. g. a module that only implements a single subfunction). Strive for controlled entry modules, avoid pathological connection (e. g. branches into the middle of another module) 79
Chapter 14 – Design Method 14. 1 Architectural Design Overview Architectural design represents the structure of the data and program components required to build a computerbased system. A number of architectural "styles" exist. Architectural design begins with data design and proceeds to the derivation of one or more representations of the architectural structure of the system. The resulting architectural model encompasses both the data architecture and the program structure. The architectural model is subjected to software quality review like all other design work products. 80
Software architecture is a representation that enables a software engineer to • Analyze the effectiveness of the design in meeting stated requirements • Consider architectural alternatives • Reduce the risk associated with the construction of the software Examine the system as a whole 81
Data Design Principles • Systematic analysis principles applied to function and behavior should also be applied to data. • All data structures and the operations to be performed on each should be identified. • Data dictionary should be established and used to define both data and program design. • Low level design processes should be deferred until late in the design process. • Representations of data structure should be known only to those modules that must make direct use of the data contained within in the data structure. 82
• A library of useful data structures and operations should be developed. • A software design and its implementation language should support the specification and realization of abstract data types. Architectural Styles Data centered - data store (e. g. file or database) lies at the center of this architecture and is accessed frequently by other components that modify data 83
• Data flow - input data is transformed by a series of computational or manipulative components into output data • Call and return - program structure decomposes function into control hierarchy with main program invokes several subprograms • Object-oriented - components of system encapsulate data and operations, communication between components is by message passing 84
• Layered - several layers are defined, each accomplishing operations that progressively become closer to the machine instruction set Architecture Design Assessment Questions • How is control managed within the architecture? • Does a distinct control hierarchy exist? • How do components transfer control within the system? How is control shared among components? 85
• What is the control topology? • Is control synchronized or asynchronous? • How are data communicated between components? • Is the flow of data continuous or sporadic? • What is the mode of data transfer? • Do data components exist? If so what is their role? 86
• How do functional components interact with data components? • Are data components active or passive? • How do data and control interact within the system? Architecture Trade-off Analysis Method 1. Collect scenarios Elicit requirements, constraints, and environmental description 87
1. Describe architectural styles/patterns chosen to address scenarios and requirements (module view, process view, data flow view) 2. Evaluate quality attributes independently (e. g. reliability, performance, security, maintainability, flexibility, testability, portability, reusability, interoperability) 3. Identify sensitivity points for architecture (any attributes significantly affected by variation in the architecture) 4. Critique candidate architectures (from step 3) using the sensitivity analysis (conducted in step 5) Architectural Complexity (similar to coupling) 88
• Flow dependencies - represent dependence relationships between producers and consumers of resources • Constrained dependencies - represent constraints on the relative flow among a set of components • Sharing dependencies - represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers Mapping Requirements to Software Architecture in Structured Design Establish type of information flow (transform flow - overall data flow is sequential and flows along a small number of straight line paths; transaction flow - a single data item triggers information flow along one of many paths) 89
• Flow boundaries indicated • DFD is mapped into program structure • Control hierarchy defined • Resultant structure refined using design measures and heuristics • Architectural description refined and elaborated Transform Mapping 90
• Review fundamental system model • Review and refine data flow diagrams for the software • Determine whether the DFD has transform or transaction characteristics • Isolate the transform center by specifying incoming and outgoing flow boundaries • Perform first level factoring • Perform second level factoring Refine the first iteration architecture using design heuristics for improved software quality 91
Transaction Mapping • Review fundamental system model • Review and refine data flow diagrams for the software • Determine whether the DFD has transform or transaction characteristics • Identify the transaction center and flow characteristics along each action path • Map the DFD to a program structure amenable to transaction processing • Factor and refine the transaction structure and the structure of each action path 92
Refine the first iteration architecture using design heuristics for improved software quality Refining Architectural Design • Processing narrative developed for each module Interface description provided for each module Local and global data structures are defined • Design restrictions/limitations noted • Design reviews conducted Refinement considered if required and justified 93
Chapter 14. 3 - User Interface Design Overview This chapter introduces the principles of user interface design as it relates to the development of software products. Proper interface design begins with careful analysis of the user, the task and the environment. Once the user's tasks are identified, user scenarios are created and validated. Good user interfaces are designed, they don't happen by chance. Prototyping is a common approach to user interface design. Early involvement of the user in the design process makes him or her more likely to accept the final product. User interfaces must be field tested and validated prior to general release. 94
Place User in Control • Define interaction in such a way that the user is not forced into performing unnecessary or undesired actions • Provide for flexible interaction (users have varying preferences) Allow user interaction to be interruptible and reversible 95
• Streamline interaction as skill level increases and allow customization of interaction • Hide technical internals from the casual user • Design for direct interaction with objects that appear on the screen Reduce User Memory Load • Reduce demands on user's short-term memory • Establish meaningful defaults 96
• Define intuitive short-cuts • Visual layout of user interface should be based on a familiar real world metaphor • Disclose information in a progressive fashion Make Interface Consistent • Allow user to put the current task into a meaningful context • Maintain consistency across a family of applications If past interaction models have created user expectations, do not make changes unless there is a good reason to do so 97
User Interface Design Models • Design model (incorporates data, architectural, interface, and procedural representations of the software) • User model (end user profiles - novice, knowledgeable intermittent user, knowledgeable frequent users) • User's model or system perception (user's mental image of system) • System image (look and feel of the interface and supporting media) User Interface Design Process (Spiral Model) 98
• User, task, and environment analysis and modeling • Interface design • Interface construction • Interface validation Task Analysis and Modeling Software engineer studies tasks human users must complete to accomplish their goal in the real world without the computer and map these into a similar set of tasks that are to be implemented in the context of the user interface 99
• Software engineer studies existing specification for computer-based solution and derives a set of tasks that will accommodate the user model, design model, and system perception • Software engineer may devise an object-oriented approach by observing the objects and actions the user makes use of in the real world and model the interface objects after their real world counterparts Interface Design Activities • Establish the goals and intentions of each task • Map each goal/intention to a sequence of specific actions (objects and methods for manipulating objects) 100
• Specify the action sequence of tasks and subtasks (user scenario) • Indicate the state of the system at the time the user scenario is performed • Define control mechanisms • Show control mechanisms affect the state of the system • Indicate how the user interprets the state of the system from information provided through the interface Interface Design Issues System response time (time between the point at which user initiates some control action and the time when the system responds) 101
• User help facilities (integrated, context sensitive help versus add-on help) • Error information handling (messages should be nonjudgmental, describe problem precisely, and suggest valid solutions) • Command labeling (based on user vocabulary, simple grammar, and have consistent rules for abbreviation) User Interface Evaluation Cycle 102
1. Preliminary design 2. Build first interface prototype 3. User evaluates interface 4. Evaluation studied by designer 5. Design modifications made 6. Build next prototype 7. If interface is not complete then go to step 3 103
User Interface Design Evaluation Criteria • Length and complexity of written interface specification provide an indication of amount of learning required by system users Number of user tasks and the average number of actions per task provide an indication of interaction time and overall system efficiency 104
• Number of tasks, actions, and system states in the design model provide an indication of the memory load required of system users Interface style, help facilities, and error handling protocols provide a general indication of system complexity and the degree of acceptance by the users 105
Chapter 14. 4 - Component Level Design Overview The purpose of component level design is to translate the design model into operational software. Component level design occurs after the data, architectural, and interface designs are established. Component-level design represents the software in a way that allows the designer to review it for correctness and consistency, before it is built. The work product produced is the procedural design for each software component, represented using graphical, tabular, or textbased notation. 106
Structured Programming • Each block of code has a single entry at the top • Each block of code has a single exit at the bottom • Only three control structures are required: sequence, condition (if-then-else), and repetition (looping) Reduces program complexity by enhancing readability, testability, and maintainability 107
Design Notation • Flowcharts (arrows for flow of control, diamonds for decisions, rectangles for processes) • Box diagrams (also known as Nassi-Scheidnerman charts - process boxes subdivided to show conditional and repetitive steps) • Decision table (subsets of system conditions and actions are associated with each other to define the rules for processing inputs and events) • Program Design Language (PDL - structured English or pseudocode used to describe processing details) 108
Program Design Language Characteristics • Fixed syntax with keywords providing for representation of all structured constructs, data declarations, and module definitions • Free syntax of natural language for describing processing features • Data declaration facilities for simple and complex data structures Subprogram definition and invocation facilities 109
Design Notation Assessment Criteria • Modularity (notation supports development of modular software) • Overall simplicity (easy to learn, easy to use, easy to write) • Ease of editing (easy to modify design representation when changes are necessary) • Machine readability (notation can be input directly into a computer-based development system) • Maintainability (maintenance of the configuration usually involves maintenance of the procedural design representation) 110
• Structure enforcement (enforces the use of structured programming constructs) • Automatic processing (allows the designer to verify the correctness and quality of the design) • Data representation (ability to represent local and global data directly) • Logic verification (automatic logic verification improves testing adequacy) Easily converted to program source code (makes code generation quicker) 111
Chapter 16 ? Software Testing Techniques Overview The importance of software testing to software quality can not be overemphasized. Once source code has been generated, software must be tested to allow errors to be identified and removed before delivery to the customer. While it is not possible to remove every error in a large software package, the software engineer抯 goal is to remove as many as possible early in the software development cycle. It is 112
important to remember that testing can only find errors, it cannot prove that a program is bug free. Two basic test techniques involve testing module input/output (black-box) and exercising internal logic of software components (white-box). Formal technical reviews by themselves can not find allow software defects, test data must also be used. For large software projects, separate test teams may be used to develop and execute the set of test cases used in testing. Testing must be planned and designed. The SEPA web site contains the template for a generic test plan. 113
Software Testing Objectives • Testing is the process of executing a program with the intent of finding errors. • A good test case is one with a high probability of finding an as-yet undiscovered error. • A successful test is one that discovers an as-yetundiscovered error. Software Testing Principles • All tests should be traceable to customer requirements. • Tests should be planned long before testing begins. 114
• The Pareto principle (80% of all errors will likely be found in 20% of the code) applies to software testing. • Testing should begin in the small and progress to the large. • Exhaustive testing is not possible. • To be most effective, testing should be conducted by an independent third party. Software Testability Checklist • Operability (the better it works the more efficiently it can be tested) Observabilty (what you see is what you test) 115
• Controllability (the better software can be controlled the more testing can be automated and optimized) • Decomposability (by controlling the scope of testing, the more quickly problems can be isolated and retested intelligently) • Simplicity (the less there is to test, the more quickly we can test) • Stability (the fewer the changes, the fewer the disruptions to testing) • Understandability (the more information known, the smarter the testing) 116
Good Test Attributes • A good test has a high probability of finding an error. • A good test is not redundant. • A good test should be best of breed. A good test should not be too simple or too complex 117
Test Case Design Strategies • Black-box or behavioral testing (knowing the specified function a product is to perform and demonstrating correct operation based solely on its specification without regard for its internal logic) • White-box or glass-box testing (knowing the internal workings of a product, tests are performed to check the workings of all insdependent logic paths) 118
Basis Path Testing • White-box technique usually based on the program flow graph • The cyclomatic complexity of the program computed from its flow graph using the formula V(G) = E ? N + 2 or by counting the conditional statements in the PDL representation and adding 1 • Determine the basis set of linearly independent paths (the cardinality of this set id the program cyclomatic complexity) Prepare test cases that will force the execution of each path in the basis set. 119
Control Structure Testing • White-box techniques focusing on control structures present in the software • Condition testing (e. g. branch testing) focuses on testing each decision statement in a software module, it is important to ensure coverage of all logical combinations of data that may be processed by the module (a truth table may be helpful) • Data flow testing selects test paths based according to the locations of variable definitions and uses in the program (e. g. definition use chains) • Loop testing focuses on the validity of the program loop constructs (i. e. simple loops, 120
• concatenated loops, nested loops, unstructured loops), involves checking to ensure loops start and stop when they are supposed to (unstructured loops should be redesigned whenever possible) Graph-based Testing Methods • Black-box methods based on the nature of the relationships (links) among the program objects (nodes), test cases are designed to traverse the entire graph Transaction flow testing (nodes represent steps in some transaction and links represent logical connections between steps that need to be validated) 121
• Finite state modeling (nodes represent user observable states of the software and links represent transitions between states) • Data flow modeling (nodes are data objects and links are transformations from one data object to another) • Timing modeling (nodes are program objects and links are sequential connections between these objects, link weights are required execution times) Equivalence Partitioning • Black-box technique that divides the input domain into classes of data from which test cases can be derived 122
• An ideal test case uncovers a class of errors that might require many arbitrary test cases to be executed before a general error is observed • Equivalence class guidelines: 1. If input condition specifies a range, one valid and two invalid equivalence classes are defined 2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined 3. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined If an input condition is Boolean, one valid and one invalid equivalence class is defined 123
Boundary Value Analysis • Black-box technique that focuses on the boundaries of the input domain rather than its center • BVA guidelines: 1. If input condition specifies a range bounded by values a and b, test cases should include a and b, values just above and just below a and b 2. If an input condition specifies and number of values, test cases should be exercise the minimum and maximum numbers, as well as values just above and just below the minimum and maximum values 3. Apply guidelines 1 and 2 to output conditions, test cases should be designed to produce the minimum and maxim output reports 124
4. If internal program data structures have boundaries (e. g. size limitations), be certain to test the boundaries Comparison Testing • Black-box testing for safety critical systems in which independently developed implementations of redundant systems are tested for conformance to specifications Often equivalence class partitioning is used to develop a common set of test cases for each implementation 125
Orthogonal Array Testing • Black-box technique that enables the design of a reasonably small set of test cases that provide maximum test coverage • Focus is on categories of faulty logic likely to be present in the software component (without examining the code) • Priorities for assessing tests using an orthogonal array 1. Detect and isolate all single mode faults 2. Detect all double mode faults 3. Mutimode faults Specialized Testing 126
• Graphical user interfaces (see Chapter 31 and the SEPA web checklist) • Client/server architectures (see Chapter 28) • Documentation and help facilities (see Chapter 8 and Chapter 15) • Real-time systems 1. Task testing (test each time dependent task independently) 2. Behavioral testing (simulate system response to external events) 3. Intertask testing (check communications errors among tasks) System testing (check interaction of integrated system software and hardware) 127
Chapter 17 - Software Testing Strategies Overview This chapter describes several approaches to testing software. Software testing must be planned carefully to avoid wasting development time and resources. Testing begins "in the small" and progresses "to the large". Initially individual components are tested using white box and black box techniques. After the individual components have been tested and added to the system, integration testing takes place. Once the full software product is completed, system testing is performed. The Test Specification document should be reviewed like all other software engineering work products. A sample Test Specification document appears on the SEPA web site. 128
Strategic Approach to Software Testing • Testing begins at the component level and works outward toward the integration of the entire computer-based system. • Different testing techniques are appropriate at different points in time. • The developer of the software conducts testing and may be assisted by independent test groups for large projects. • The role of the independent tester is to remove the conflict of interest inherent when the builder is testing his or her own product. 129
• Testing and debugging are different activities. • Debugging must be accommodated in any testing strategy. • Make a distinction between verification (are we building the product right? ) and validation (are we building the right product? ) Strategic Testing Issues • Specify product requirements in a quantifiable manner before testing starts. Specify testing objectives explicitly. 130
• Identify the user classes of the software and develop a profile for each. • Develop a test plan that emphasizes rapid cycle testing. • Build robust software that is designed to test itself (e. g. uses anitbugging). • Use effective formal reviews as a filter prior to testing. • Conduct formal technical reviews to assess the test strategy and test cases. Unit Testing 131
• Black box and white box testing. • Module interfaces are tested for proper information flow. • Local data are examined to ensure that integrity is maintained. • Boundary conditions are tested. • Basis path testing should be used. • All error handling paths should be tested. Drivers and/or stubs need to be developed to test incomplete software. 132
Integration Testing • Top-down integration testing 1. Main control module used as a test driver and stubs are substitutes for components directly subordinate to it. 2. Subordinate stubs are replaced one at a time with real components (following the depth-first or breadth-first approach). 3. Tests are conducted as each component is integrated. 4. On completion of each set of tests and other stub is replaced with a real component. 133
5. Regression testing may be used to ensure that new errors not introduced. • Bottom-up integration testing 1. Low level components are combined in clusters that perform a specific software function. 2. A driver (control program) is written to coordinate test case input and output. 3. The cluster is tested. Drivers are removed and clusters are combined moving upward in the program structure. 134
• Regression testing (check for defects propagated to other modules by changes made to existing program) 1. Representative sample of existing test cases is used to exercise all software functions. 2. Additional test cases focusing software functions likely to be affected by the change. 3. Tests cases that focus on the changed software components. • Smoke testing 1. Software components already translated into code are integrated into a build. 135
2. A series of tests designed to expose errors that will keep the build from performing its functions are created. 3. The build is integrated with the other builds and the entire product is smoke tested daily (either top-down or bottom integration may be used). General Software Test Criteria • Interface integrity (internal and external module interfaces are tested as each module or cluster is added to the software) Functional validity (test to uncover functional defects in the software) 136
• Information content (test for errors in local or global data structures) • Performance (verify specified performance bounds are tested) Validation Testing • Ensure that each function or performance characteristic conforms to its specification. · Deviations (deficiencies) must be negotiated with the customer to establish a means for resolving the errors. 137
· Configuration review or audit is used to ensure that all elements of the software configuration have been properly developed, cataloged, and documented to allow its support during its maintenance phase. Acceptance Testing • Making sure the software works correctly for intended user in his or her normal work environment. • Alpha test (version of the complete software is tested by customer under the supervision of the developer at the developer抯 site) Beta test (version of the complete software is tested by customer at his or her own site without the developer being present) 138
System Testing • Recovery testing (checks the system抯 ability to recover from failures) • Security testing (verifies that system protection mechanism prevent improper penetration or data alteration) • Stress testing (program is checked to see how well it deals with abnormal resource demands ? quantity, frequency, or volume) • Performance testing (designed to test the run-time performance of software, especially real-time software) Debugging 139
• Some people are better at debugging than others. • Common approaches: 1. Brute force (memory dumps and run-time traces are examined for clues to error causes) 2. Backtracking (source code is examined by looking backwards from symptom to potential causes of errors) 3. Cause elimination (uses binary partitioning to reduce the number of locations potential where errors can exist) 140
• Debugging (removal of a defect) occurs as a consequence of successful testing. Bug Removal Considerations • Is the cause of the bug reproduced in another part of the program? • What "next bug" might be introduced by the fix that is being proposed? What could have been done to prevent this bug in the first place? 141
Chapter 19 Object-Oriented Concepts and Pricinples Overview This chapter provides an introduction to object-oriented programming and management principles for objectoriented projects. Object-oriented software engineering process is similar to that found in the rapid prototyping or spiral paradigms. Even though, object-oriented software engineering follows the same steps as the conventional approach (analysis, design, implementation, and testing) it is 142
harder to separate them into discrete activities. The next 3 chapters deal with the topics of objectoriented analysis, object-oriented design, and object-oriented testing. Evolutionary Object-Oriented Process Model • Customer communication • Planning Risk analysis 143
• Engineering construction and analysis • Identify candidate classes • Look-up classes in library Extract classes if available • Engineer classes if not available 144
o. Object-oriented design (OOD) o. Object-oriented programming (OOP) o. Object-oriented analysis (OOA) o. Object-oriented testing (OOT) • Put new classes in library • Construct Nth iteration of the system Customer evaluation 145
Object-Oriented Concepts • Objects - encapsulates both data (attributes) and data manipulation functions (called methods, operations, and services) • Class - generalized description (template or pattern) that describes a collection of similar objects • Superclass - a collection of objects • Subclass - an instance of a class • Class hierarchy - attributes and methods of a superclass are inherited by its subclasses 146
• Messages - the means by which objects exchange information with one another • Inheritance - provides a means for allowing subclasses to reuse existing superclass data and procedures; also provides mechanism for propagating changes • Polymorphism - a mechanism that allows several objects in an class hierarchy to have different methods with the same name (instances of each subclass will be free to respond to messages by calling their own version of the method) Advantages of Object-Oriented Architectures Implementation details of data and procedures and hidden from the outside world (reduces the propagation of side effects when changes are made). 147
• Data structures and operators are merged in single entity or class (this facilitates reuse) • Interfaces among encapsulated objects are simplified (system coupling is reduced since object needs not be concerned about the details of internal data structures) Class Construction Options • Build new class from scratch without using inheritance 148
• Use inheritance to create new class from existing class contains most of the desired attributes and operations • Restructure the class hierarchy so that the required attributes and operations can be inherited by the newly created class Override some attributes or operations in an existing class and use inheritance to create a new class with (specialized) private versions of these attributes and operations. 149
Chapter 20 Object-Oriented Analysis Overview This chapter describes the process of creating an objectoriented analysis (OOA) model for software development projects. The OOA model is composed of graphical or text-based representations that define class attributes, relationships, behaviors, and inter-class communication. OOA begins with scenario-based descriptions (use cases) of how actors (people, 150
machines, systems) in the problem space interact with the product to be built. Class-Responsibility. Collaborator modeling translates use-case information into representations of classes and their collaborations. An object-relationship model can be built from the collaborator network. The object-behavior model is represented using a state transition diagram. The OOA model needs to be reviewed for quality like any other software engineering product. 151
OOA Tasks 1. Basic user requirements must be communicated between the customer and the software engineer. 2. Classes must be identified (e. g. define attributes and methods) 3. Specify class hierarchy 4. Represent object-to-object relationships 5. Model object behavior 6. Reapply 1 through 5 iteratively until model is complete 152
OOA Generic Steps • Elicit customer requirements for system • Identify scenarios or use cases • Select classes and objects using basic requirements as a guide Identify attributes and operations for each system object 153
• Define structures and hierarchies that organize classes • Build object-relationship model • Build object-behavior model • Review OOA model against use-cases (scenarios) Unified Modeling Language Perspectives 154
• User model view (describes usage scenarios from the end -user's perspective) • Structural model view (static structure of data and functionality is modeled - classes, object, relationships) • Behavioral model view (represents dynamic system aspects - interactions or collaborations between structural elements in the user and structural models) • Implementation model view (representing the structural and behavioral aspects of the system as they are to be built) Environment model view (representation of the structural and behavioral aspects of the environment in which the system will be implemented) 155
Domain Analysis Activities • Define the domain to be investigated • Categorize the items extracted from the domain • Collect a representative sample of applications in the domain • Analyze each application in the sample • Identify candidate reusable objects • Indicate reasons the objects may be reused 156
• Define adaptations of the objects that may be reused • Estimate percentage of applications in the domain that might make reuse of the objects • Identify objects by name and use configuration management techniques to control them • Develop an analysis model for the objects OOA Model Generic Components Static view of semantic classes (classes based on semantics of customer requirements) 157
• Static view of attributes (attributes describe classes and suggest operations relevant to classes) • Static view of relationships (represent relationships in a way that allows identification of operations and the design of a messaging approach) • Static view of behaviors (behaviors accommodating system usage scenarios implemented by sequences of operations) • Dynamic view of communication (among objects based on events that cause state transitions) 158
• Dynamic view of control and time (describe the nature and timing of events causing state transitions) Use Case Objectives • Define the functional and operational requirements of system by defining a scenario of usage agreed upon by the end-user and software engineer • Provide an unambiguous description of how the end-user and system interact with one another Provide a basis for validation testing 159
Class-Responsibility-Collaborator (CRC) Modeling • Develop a set of index cards that represent the system classes • One class per card • Cards are divide into three sections (class name, class responsibilities, class collaborators) • Once a complete CRC card set is developed it is reviewed examining the usage scenarios 160
Criteria for Inclusion of a Class on a CRC Card • Class information should be retained • Provides needed services • Contains multiple attributes • Common set of attributes apply to all object occurrences • Common set of operations apply to all object occurrences External entities that produce or consume information 161
Allocating Responsibilities to Classes • Distribute system intelligence evenly • State each responsibility as generally as possible • Information and its related behaviors should reside within the same class • Localize all information about one thing in a single class • Share responsibilities among related classes when appropriate 162
Collaborators • Any time a class cannot fulfill a responsibility on its own it needs to interact with another class • A server object interacts with a client object to fulfill some responsibility Reviewing CRC Models • Each review participant is given a subset of the CRC cards (collaborating cards must be separated) All use-case scenarios and use-case diagrams should be organized into categories 163
Review leader chooses a use-case scenario and begins reading it out loud · · Each time a named object is read a token is passed to the reviewer holding the object's card · When the reviewer receives the token, he or she is asked to describe the responsibilities listed on the card · The group determines whether one of the responsibilities on the card satisfy the use-case requirement or not 164
·If the responsibilities and collaborations on the index card cannot accommodate the use-case requirements then modifications need to be made to the card set Deriving the Object-Relationship Model • Using the CRC model a network of collaborators can be drawn Reviewing the CRC model index card, responsibilities and collaborators are evaluated, each unlabeled connected line is named 165
• Once the named relationships are established each end is evaluated to determine cardinality (0 to 1, 1 to 1, 0 to many, 1 to many) • Continue the process until a complete object-relationship model has been produced Object-Behavior Model Construction 166
• Evaluate all use-cases to understand the sequence of interaction within the system • Identify events that drive the interaction sequence and how events relate to specific objects • Create an event-trace for each use-case • Build a state transition diagram for the system Review the object behavior model to verify accuracy and consistency 167
Chapter 21 Object-Oriented Design Overview This chapter discusses the steps required to develop an object-oriented software design from an object-oriented analysis model. Object-oriented design (OOD) is divided into two major activities: system design and object design. System design defines the product architecture (the system functions and classes encapsulated in the subsystems). System design focuses on the specification of three components: the user interface, data management functions, and task management facilities. Object design focuses on the internal details of the individual classes and the messaging scheme. 168
The design specification document form the SEPA web site is applicable to OOD. The OOD projects must be reviewed to ensure quality. Object-Oriented Design Layers Responsibilities layer (highest layer - contains data structure detail and algorithmic detail for each object's attributes and operations) 169
• Message layer (establishes the internal and external interfaces for the system, including the details of communication among object collaborators) • Class and object layer (contains class hierarchy including representations of each object) • Subsystem layer (lowest level - contains representations of each of the subsystems and the necessary infrastructure that enable the software to achieve the customer's requirements) Object-oriented Design Issues • Decomposability - facility of design method that allows the designer to decompose the problem into easily solved subproblems 170
• Composability - degree to which design method ensures that modules constructed for one project can be reused in another • Understandablity - ease with which a component can be understood without examining other components • Continuity - ability to isolate changes made in one module and restrict the propagation of changes to other modules • Protection - architectural characteristic that reduces the propagation of side effects when errors occur Generic Object-Oriented Design Steps Describe each subsystem and allocate it to processors and tasks 171
• Choose a design strategy for implementing data management, interface support, and task management • Design an appropriate system control mechanism • Perform object design by creating a procedural representation for each operation and data structures for each attribute • Perform message design using collaborations between objects and object-relationships • Create a messaging model 172
• Review the design model and iterate as required Unified Approach to Object-Oriented Design System design - UML (unified modeling language) design activity that focuses on software architecture and definition of subsystems • Object design - UML design activity that focuses on describing object and their interactions at a level of detail that will allow them to be implemented in some programming language 173
Object-Oriented System Design Process • Partition the analysis model into subsystems • subsystems should have well defined communication interfaces • with few exceptions classes should collaborate within their subsystem • keep number of subsystems small • partition subsystem internally to reduce complexity • Identify concurrency dictated by the problem 174
• Allocate subsystems to processors and tasks • allocate each subsystem to an independent processor (or) • allocate subsystems to same processor and provide concurrency support through operating system features • Develop user interface design • Choose basic strategy for implementing data management • management of data critical to the application itself • creation of infrastructure for storage and retrieval of objects Identify global resources and control mechanisms to access them 175
• Design control mechanism for system (including task management) • Consider how subsystem boundary conditions should be handled • list each request (contract) that can be made by subsystem collaborators • for each contract note the operations required to implement the responsibilities implied by the contract • for each contract create a table with these entries: type, collaborators, class, operation, message format 176
• if subsystem interaction modes are complex create a subsystem-collaboration diagram • Review and consider trade-offs Object Design Process • Object descriptions • protocol description - object interface specified by defining each message an object can receive and the operation triggered by message (or) implementation description - shows implementation details for each operation implied a message passed to the object 177
• Designing algorithms and data structures • algorithm categories: data manipulation, computation, monitors • refinement of operation programs defined during OOA • Design optimization • review object-relationship model to ensure implemented design leads to efficient resource utilization, add redundancy where necessary • revise attribute data structures and related operation algorithms to improve processing efficiency 178
• Modularity is important aspect of object-oriented design quality (the program design language should support object definition) • create attributes to save derived information and avoid recomputation Design Pattern Specification Components • Name • Intent Design forces motivating the pattern 179
• Solution that mitigates these design forces • Classes required to implement the solution • Responsibilities and collaborations among the solution classes • Implementation suggestions • Source code examples or templates 180
• Cross-references to related design patterns Using Design Patterns in Object-Oriented Design • Inheritance - makes use of an existing design pattern to create a template for a new subclass Composition - assembling complex objects or subsystems out of selected design patterns using only interface information 181
Chapter 22 Object-Oriented Testing Overview This chapter discusses the testing of object-oriented systems. The process of testing object-oriented systems begins with a review of the object-oriented analysis and design models. Once the code is written object-oriented testing (OOT) begins by testing "in the small" with class testing (class operations and collaborations). As classes are integrated to become subsystems class collaboration problems are investigated. Finally, use-cases from the OOA model are used to uncover software validation errors. OOT similar to testing conventional software in that test cases are developed to exercise the classes, their collaborations, and behavior. OOT differs from conventional software 182
testing in that more emphasis is placed assessing the completeness and consistency of the OOA and OOD models as they are built. OOT tends to focus more on integration problems than on unit testing. The test plan specification template from the SEPA web site is applicable to object-oriented testing as well. Object-Oriented Testing Activities • Review OOA and OOD models Class testing after code is written 183
• Integration testing within subsystems • Integration testing as subsystems are added to the system • Validation testing based on OOA use-cases Testing OOA and OOD Models • Correctness of OOA and OOD models • syntactic correctness judged by ensuring that proper modeling conventions and symbolism have been used • semantic correctness based on the model's conformance to the real world problem domain 184
• Consistency of OOA and OOD models • assess the class-responsibility-collaborator (CRC) model and object-relationship diagram • review system design (examine the object-behavior model to check mapping of system behavior to subsystems, review concurrency and task allocation, use-case scenarios to exercise user interface design) • test object model against the object relationship network to ensure that all design object contain necessary attributes and operations needed to implement the collaborations defined for each CRC card review detailed specifications of algorithms used to implement operations using conventional inspection techniques 185
Assessing the Class Model 1. Revisit the CRC model and the object-relationship model 2. Inspect the description of each CRC card to determine if a delegated responsibility is part of the collaborator's definition 3. Invert the connection to ensure that each collaborator that is asked for service is receiving requests from a responsible source 4. Using the inverted connections from step 3, determine whether other classes might be required or whether responsibilities are properly grouped among classes 186
5. Determine whether widely requested responsibilities might be combined into a single responsibility 6. Steps 1 to 5 are applied iteratively to each class and through the evaluation of the OOA model Object-Oriented Testing Strategies • Unit testing in the OO context smallest testable unit is the encapsulated class or object 187
• similar to system testing of conventional software • do not test operations in isolation from one another • driven by class operations and state behavior, not algorithmic detail and data flow across module interface • Integration testing in the OO context • focuses on groups of classes that collaborate or communicate in some manner • integration of operations one at a time into classes is often meaningless • thread-based testing (testing all classes required to respond to one system input or event) 188
• use-based testing (begins by testing independent classes first and the dependent classes that make use of them) • cluster testing (groups of collaborating classes are tested for interaction errors) • regression testing is important as each thread, cluster, or subsystem is added to the system • Validation testing in the OO context • focuses on visible user actions and user recognizable outputs from the system • validation tests are based on the use-case scenarios, the object -behavior model, and the event flow diagram created in the OOA model conventional black-box testing methods can be used to drive the validation tests 189
Test Case Design for OO Software • Each test case should be uniquely identified and be explicitly associated with a class to be tested · State the purpose of each test · List the testing steps for each test including: · list of states to test for each object involved in the test • list of messages and operations to exercised as a consequence of the test 190
• list of exceptions that may occur as the object is tested • list of external conditions needed to be changed for the test • supplementary information required to understand or implement the test OO Test Design Issues • White-box testing methods can be applied to testing the code used to implement class operations, but not much else Black-box testing methods are appropriate for testing OO systems 191
• Fault-based testing • best reserved for operations and the class level • uses the inheritance structure • tester examines the OOA model and hypothesizes a set of plausible defects that may be encountered in operation calls and message connections and builds appropriate test cases • misses incorrect specification and errors in subsystem interactions 192
• Object-oriented programming brings additional testing concerns • classes may contain operations that are inherited from super classes • subclasses may contain operations that were redefined rather than inherited • all classes derived from an previously tested base class need to be thoroughly tested • Scenario-based testing • using the user tasks described in the use-cases and building the test cases from the tasks and their variants 193
• uncovers errors that occur when any actor interacts with the OO software • concentrates on what the use does, not what the product does you can get a higher return on your effort by spending more time on reviewing the use-cases as they are created, than spending more time on use-case testing • Testing surface structure (exercising the structure observable by end-user, this often involves observing and interviewing users as they manipulate system objects) • Testing deep structure (exercising internal program structure - the dependencies, behaviors, and communications mechanisms established as part of the system and object design) 194
Class Level Testing Methods • Random testing (requires large numbers data permutations and combinations and can be inefficient) • Partition testing (reduces the number of test cases required to test a class) • state-based partitioning (tests designed in way so that operations that cause state changes are tested separately from those that do not) • attribute-based partitioning (for each class attribute, operations are classified according to those that use the attribute, those that modify the attribute, and those that do not use or modify the attribute) category-based partitioning (operations are categorized according to the function they perform: initialization, computation, query, termination) 195
Inter-Class Test Case Design • Multiple class testing • for each client class use the list of class operators to generate random test sequences that send messages to other server classes • for each message generated determine the collaborator class and the corresponding server object operator • for each server class operator (invoked by a client object message) determine the message it transmits 196
• for each message, determine the next level of operators that are invoked and incorporate them into the test sequence • Tests derived from behavior models • test cases must cover all states in the state transition diagram breadth first traversal of the state model can be used (test one transition at a time and only make use of previously tested transitions when testing a new transition) test cases can also be derived to ensure that all behaviors for the class have been adequately exercised. 197
Скачать презентацию Prof Dr Hongwei Zhang 张洪伟 zhang_hw 99 hotmail com
edc0d1ebcdda6105820982ba00cf7d8d.ppt