6 DESIGN II DETAILED DESIGN Develop Architecture see

6. DESIGN II: DETAILED DESIGN

Develop Architecture - see chapter 5 Identify corporate practices Software Engineering Roadmap: Chapter 6 Focus Perform Detailed Design - apply design patterns - accommodate use cases supply methods - exploit libraries (Java, Swing…) - describe methods where required - develop detailed object models - dev. detailed logic (pseudo-code) Plan project Analyze requirements Maintain Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Chapter Learning Goals • Understand how design patterns describe some detailed designs • Specify classes and functions completely • Specify algorithms – use flowcharts – use pseudocode Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Introduction to Detailed Design Objective: To fully prepare for implementation of a system that meets requirements. Outcomes: (1) blueprints (models), (2) associated details (documentation), (3) detailed implementation plan for construction, integration and testing

Relating Use Cases, Architecture, & Detailed Design 1. Use case -analysis “Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes. ” 2. Domain classes 3. Architecure Cable Auto Road Pylon

Relating Use Cases, Architecture, & Detailed Design 1. Use case (part of requirements) “Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes. ” 2. Domain classes 3. Architecure (not specifically required) Cable Auto Road (added for detailed design) 4. Detailed Design Smith Hill Pylon Support use case Guardrail Auto Cable Road Pylon Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Jones Hollow

• What is the difference between high-level (architectural) design and detailed design? • High-Level Design • Detailed Design

1. Begin with architectural models -- see chapter 5 • class model: domain & architectural classes • overall state model* • overall data flow model* • use case model Typical Roadmap for Detailed Design 2. Introduce classes & design patterns* which connect the architecture classes with the domain classes -- sections 1 and 5 • concentrate on riskiest parts first; try alternatives 3. Refine models, make consistent, ensure complete For each class. . . 4. Specify class invariants* -- section 3. 1 For each method. . . For each unit. . . 5. Specify methods with pre- and post-conditions, flowcharts* & pseudocode* -- sections 3 and 4 6. Sketch unit test plans -- see chapter 8 7. Inspect test plans & design -- section 9 * if applicable 8. Release for implementation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Organize the Team for Detailed Design 1/2 1. Prepare for a detailed design kick-off meeting. – Ensure team members aware of the models (views) they are expected to produce • typically object model, sequence diagrams, state, & data flow – Ensure team members aware of the notation expected • typically: UML plus a pseudocode standard and/or example – Design leader prepares list of modules – Design leader creates a meeting agenda – Project leader allocates time to agenda items (people can speak about detailed designs indefinitely if allowed to!) • allocate the time among the agenda items Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Organize the Team for Detailed Design 2/2 2. Hold the kick-off meeting – Designate someone to monitor the agenda item time – Confirm that the architecture is ready for detailed design • Make sure that module interfaces the are clear – revise as a group if not • Don’t try to develop detailed designs as a group – not necessary: individuals have the responsibility – groups are seldom good at designing details together – Allocate modules to members • Request time estimates to design lead by a fixed date – Write out the conclusions and copy/e-mail every member – Decide how and when the results are to be reviewed 3. Update the documentation set – more detailed schedule with modules & inspections 4. Inspect the detailed designs (see section 9) 5. Rework as a result of inspections 6. Conduct post mortem and write out lessons learned Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Unified Software Development Process: Design U. P. Term 1* 2 3 Inception Elaboration Construction Requirements Transition Jacobson et al: Analysis Design Implementation Test (Jacobson et al) Prelim. Iter. iterations #1 *Key: terminology used in this book Iter. #n #n+1 1 = “Requirements” …. . Iter. #m 2 = “Achitecture” Iter. …. . #m+1 3= Iter. #k “Detailed design”

Analysis 1. Conceptual & abstract 2. Applicable to several designs 3. «control» , «entity» & «boundary» class stereotypes 4. Less formal 5. Less expensive to develop Design 1/2 After Jacobson et al: USDP 1. Concrete: implementation blueprint 2. Specific for an implementation 3. No limit on class stereotypes 4. More formal 5. More expensive to develop (~ 5 times)

Analysis Design 6. Outlines the design 6. Manifests the design (architecture one view) 7. Emerges from conceptual thinking 8. Flexibility still exists for process modifications 2/2 After Jacobson et al: USDP 7. May use tools (e. g. visual, round-trip engineering) 8. Maintaining estabished process is a high priority 9. Relatively unconstrained 9. Constrained by the analysis & architecture 10. Less focus on sequence diagrams 10. More focus on seq. diag. 11. Few layers 11. Many layers

Designing Against Interfaces Client code Used code Billing. Client Customer list. Customers() bill() print. Accounts() -- written in terms of Customer (not specific types of Customer) Abstract layer Regular. Customer bill() print. Accounts() Concrete (non-abstract) layer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Reusing Components • Reusable functionality is becoming more convenient to locate and use – Microsoft. NET freamework – COM objects / OMG’s CORBA – Javascript libraries – Java. Beans (servlet code) – Ruby on Rails – PHP libraries – Git. Hub code – Python libraries

2. Sequence and data flow diagrams for detailed design

Refine Models for Detailed Design 1/2: Sequence Diagrams 1. Begin with the sequence diagrams constructed for detailed requirements and/or architecture (if any) corresponding to the use cases. 2. Introduce additional use cases, if necessary, to describe how parts of the design typically interact with the rest of the application. 3. Provide sequence diagrams with complete details – be sure that the exact objects & their classes are specified – select specific function names in place of natural language (calls of one object to another to perform an operation) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Refine Models for Detailed Design 2/2: Data Flow Diagrams 1. Gather data flow diagrams (DFD’s) constructed for detailed requirements and/or architecture (if any). 2. Introduce additional DFD’s, if necessary, to explain data and processing flows. 3. Indicate what part(s) of the other models the DFD’s corresponds to. – e. g. , “the following DFD is for each Account object” 4. Provide all details on the DFD’s – indicate clearly the nature of the processing at each node – indicate clearly the kind of data transmitted – expand processing nodes into DFD’s if the processing description requires more detail Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

: Encounter Game Requirements: Sequence Diagram for Engage Foreign Character Use Case freddie: : Engagement Foreign Display Character : Player Character 1. 1 create; display 1. 2 create 2. 1 execute 2. 2 change quality values 3. 1 Display result 3. 2 create Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

: Encounter game Cast freddie: Foreign Character engagement: Engagement 1. 1 display. Foreign. Char() : Engagement Display 1. 2 display() 1. 3 new Engagement() : Player’s main character 2. execute() 2. 1 set. Player. Quality() 2. 2 set. Quality() 2. 3 set. Foreign. Quality() 3. 1 new Engagement. Display() 2. 4 set. Quality() 3. 2 display. Result() Design: Sequence Diagram for Encounter Foreign Character Use Case Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Classes of the Encounter. Foreign. Character Use Case Engagement execute() Engagement. Display display. Result() Encounter. Game Encounter. Cast display. Foreign. Char() set. Player. Quality() set. Foreign. Quality() Player. Character set. Quality() Foreign. Character set. Quality() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Detailed Data Flow Diagram for a Banking Application custome r info Account. get. Deposit() User Customer. get. Details() Account screen template Depositscreen. display() status Customer local log unacceptable ATM users Account. verify. Password() password Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Account. get. Password()

CRC Cards • Class Responsibility and Collaboration cards provide an effective technique for exploring the possible ways of allocating responsibilities to classes and the collaborations that are necessary to fullfil the responsibilities. • A helpful demonstration: – https: //www. youtube. com/watch? v=5 Ips. Mwx. L 37 k

Design Refinement with CRC Cards • Exercise: • Use Case: You are registering for a new course in astronomy. You require permission from the instructor and you must interact with the registrars office to signup and pay for the course. • Develop the classes and responsibilities using CRC cards

3. Specifying classes and functions

Specify A Class 1. Gather the attributes listed in the SRS. – if the SRS is organized by class 2. Add additional attributes required for the design. 3. Name a method corresponding to each of the requirements for this class. – easy if the SRS is organized by class 4. Name additional methods required for the design. 5. Show the attributes & methods on the object model. 6. State class invariants. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Specify a Function 1. Note the section(s) of the SRS or SDD which this function (method) satisfies. 2. State what expressions the function must leave invariant. 3. State the method’s pre-conditions (what it assumes). 4. State the method’s post-conditions (its effects). 5. Provide pseudocode and/or a flowchart to specify the algorithm to be used. – unless very straightforward Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Classes at Detailed Design Data type Range Default value Security issues +: visible from without Interface specs Functional details Invariants Canister + num. Canisters: int - num. Wafers: int - size: float + display() - get. Num. Slots. Open() + set. Status() Responsibilities: -- describes each canister undergoing fabrication Class name Attribute: type Operations Place for comments Instance details Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. Specifying algorithms

Flowchart Example N for set. Name() Set _name to “default. Name" Parameter & settings make sense? N Y Nominal path Parameter name too long? Y protected final void set. Name( String a. Name ) { // Check legitimacy of parameter and settings if( ( a. Name == null ) || ( max. Num. Chars. In. Name() <= 0 ) || ( max. Num. Chars. In. Name() > alltime. Limit. Of. Name. Length() ) ) { _name = new String( "default. Name" ); System. out. println ( "default. Name selected by Game. Character. set. Name()"); } Set _name Truncate else to parameter name // Truncate if a. Name too long if( a. Name. length() > max. Num. Chars. In. Name() ) _name = new String ( a. Name. get. Bytes(), 0, max. Num. Chars. In. Name() ); else // assign the parameter name _name = new String( a. Name ); } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Pseuodocode Example FOR number of microseconds supplied by operator IF number of microseconds exceeds critical value See later Try to get supervisor's approval section tbd for inspection IF no supervisor's approval results of this pseudocode abort with "no supervisor approval for . . unusual duration" message ENDIF

//p FOR number of microseconds supplied by operator for( int i = 0; i < num. Microsecs; ++I ) { //p IF number of microseconds exceeds critical value if( num. Microsecs > XRay. Policies. CRITICAL_NUM_MICROSECS ) Pseudocode int supervisor. Microsecs. Approval = Extraction //p Try to get supervisor's approval get. Approval. Of. Super. For. Long. Exposure(); //p IF no supervisor approval if( supervisor. Microsecs. Approval <= 0 ) throw ( new Supervisor. Microsecs. Approval. Exception() ); . . Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Advantages of Pseudocode & Flowcharts · Clarify algorithms in many cases · Impose increased discipline on the process of documenting detailed design · Provide additional level at which inspection can be performed · Help to trap defects before they become code · Increases product reliability · May decrease overall costs Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Disadvantages of Pseudocode & Flowcharts · Creates an additional level of documentation to maintain · Introduces error possibilities in translating to code · May require tool to extract pseudocode and facilitate drawing flowcharts Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

5. Design Patterns II: Techniques of detailed design

Apply Design Patterns in Detailed Design 1. Become familiar with the design problems solved by design patterns – at a minimum, understand the distinction among (C) creational vs. (S) structural vs. (B) behavioral patterns Consider each part of the detailed design in turn: 2. Determine whether the problem has to do with (C) creating something complex, (S) representing a complex structure, or (B) capturing behavior 3. Determine whethere is a design patterns that addresses the problem – try looking in the category identified (C, S, or B) • use this book and/or Gamma et al [Ga] 4. Decide if benefits outweigh drawbacks – benefits usually include increased flexibility – drawbacks increased class complexity(? ), less efficient(? ) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

User Interface Design • System users often judge a system by its interface rather than its functionality • A poorly designed interface can cause a user to make catastrophic errors • Poor user interface design is the reason why so many software systems are never used

User-Centred design • User-centred design is an approach to UI design where the needs of the user are paramount and where the user is involved in the design process • UI design always involves the development of prototype interfaces • See UI_design. ppt

7. Standards, notation and tools for detailed design

IEEE 1016 -1987 Software Design Document Table of Contents (Reaffirmed 1993) 1. Introduction 4. Dependency description 1. 1. Purpose Architecture 4. 1 Intermodule dependencies 1. 2. Scope 4. 2 Interprocess dependencies 1. 3. be. Definitions, acronyms 4. 3 Data dependencies Can replaced with: & abbreviations 5. Interface description 6. 1 Class#1 detailed design 2. References 5. 1 Module interface 6. 1. 1 Attributes 3. Decomposition description 5. 1. 1 Module 1 description Methods 3. 1. 6. 1. 2 Module decomposition 5. 1. 2 Module 2 description 6. 1. 3 Instance 1 details 3. 1. 1 Module description 5. 2 Process interface 6. 1. 4. Other: 2 description 3. 1. 1 Module 5. 2. 1 Process 1 description - UI detailsprocess (if applicable) 3. 2 Concurrent 5. 2. 2 Process 2 description decomposition 6. Detailed design 3. 2. 1 Process 1 description 6. 1 Module detailed design 3. 2. 2 Process 2 description 6. 1. 1 Module 1 detail 3. 3 Data decomposition 6. 2. 2 Module 2 detail 3. 3. 1 Data entry 1 description 6. 2 Data detailed design 3. 3. 2 Data entry 2 description 6. 2. 1 Data entity 1 detail 6. 2. 2 Data entity 2 detail

8. Effects on projects of completing detailed designs

1. Make sure the SDD reflects latest version of detailed design, as settled on after inspections. 2. Give complete detail to the schedule (SPMP). 3. Allocate precise tasks to team members (SPMP). 4. Improve project cost & time estimates (see below). 5. Update the SCMP to reflect the new parts. 6. Review process by which the detailed design was created, & determine improvements. Include. . . – time taken; broken down to include • preparation of the designs • inspection • change – defect summary Bring the Project Up-to-Date After Completing Detailed Design • number remaining open, found at detailed design, closed at detailed design • where injected; include previous phases & detailed design stages Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Estimate Size & Time from Detailed Designs 1. Start with the list of methods – ensure completeness, otherwise underestimate will result 2. Estimate the lines of code (LOC) for each – classify as very small, medium, large, very large • normally in ± 7% / 24% / 38% / 24% / 7% proportions – use personal data to covert to LOC • otherwise use Humphry’s table below 3. Sum the LOC 4. Covert LOC to person-hours – use personal conversion factor if possible • otherwise use published factor 5. Ensure that your estimates of method sizes and time will be compared and saved at project end. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

9. Quality in detailed designs

Inspect‡ Detailed Designs 1 of 2 1. Prepare to record metrics during the design process. – Include (1. 1) time taken; (1. 2) type of defect; (1. 3) severity 2. Ensure each architecture module is expanded. 3. Ensure each detail is part of the architecture. – if a detail does not belong to any such module, the architecture may have to be revised 4. Ensure the design fulfills its required functions 5. Ensure that design is complete (classes & methods) 6. Ensure that the design is testable. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. ‡ See chapter 1 for inspection procedures.

7. Check detailed design for -– simplicity a design that few can understand (after a legitimate effort!) is expensive to maintain, and can result in defects – generality enables design of similar applications? – expandability enables enhancements? – efficiency speed, storage Inspect Detailed Designs 2 of 2 – portability 8. Ensure all details are provided – only code itself is excluded as a “detail” – the detail work must be done eventually, and this is the best time to do it: don’t postpose Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Inspection for Defects • Identify defect and its type • Specify its severity (two methods following slides) • Identify the source of the defect – so that the defect does not occur in another project … • At another time, usually one person works on a resolution to defect

Severity Description Urgent Failure causes system crash, unrecoverable data loss; or jeopardizes personnel High Causes impairment of critical system functions, and no workaround solution does exist Medium Causes impairment of critical system functions, though a workaround solution does exist Low Causes inconvenience or annoyance None of the above Table 6. 2 IEEE 1044. 1 Severity classification Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Table 6. 3 Defect severity classification using Triage Severity Description Major Requirement(s) not satisfied Medium Neither major nor trivial Trivial A defect which will not affect operation or maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Types of Defects (1) (IEEE) • [PS] Logic problem (forgotten cases or steps; duplicate logic; extreme conditions neglected; unnecessary functions; misinterpretation; missing condition test; checking wrong variable; iterating loop incorrectly etc. ) • [PS] Computational problem (Equation insufficient or incorrect; precision loss; sign convention fault) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Types of Defects (3) • [XDOC, PS] Data problem (sensor data incorrect or missing; operator data incorrect or missing; embedded data in tables incorrect or missing; external data incorrect or missing; output data incorrect or missing; input data incorrect or missing) • [XDOC, PS] Documentation problem (ambiguous statement etc. ) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Types of Defects (4) • [XDOC, PS] Document quality problem (Applicable standards not met etc. ) • [XDOC, PS] Enhancement (change in program requirements etc. ) • [XDOC, PS] Failure caused by a previous fix Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Types of Defects (5) • [PS] Suspect performance problem (inefficient logic, data structure) • [XDOC, PS] Interoperability problem (not compatible with other software or component) • [XDOC, PS] Standards conformance problem Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Pseudocode for Inspection 1 IF a. Quality is not recognized Log error to log file 2 Inform user qualities unchanged 3 4 ELSE set. Quality() IF a. Quality. Value out of boundsshould be 5 mentioned Log error to log file 6 Inform user qualities unchanged 7 ELSE 8 Set the stated quality to 9 a. Quality. Value 10 Reduce the remaining qualities, Make these preconditions; . . . retaining their mutual proportion, don’t check. Lacks detail on how to allocate . . . making the sum of qualities unchanged the remaining quality values Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Case Study

Detailed Design of Role. Playing. Game Package Game. State RPGame handle. Event() state handle. Event() { state. handle. Event(); } . .

Detailed Design of Role. Playing. Game Package Mouse. Listener { r. PGame. S. handle. Event(); } r. PGame. S RPGMouse. Event. Listener mouse. Enter() Game. State RPGame handle. Event() state. S handle. Event() { state. S. handle. Event(); } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

User event. Target : RPGame : Game. State : RPGMouse. Event. Listener 1. mouse action 2. mouse. Clicked() 3. handle. Event ( Event ) 4. handle. Event ( Event) Sequence Diagram for Handling Mouse Events Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

RPG Video Game Architecture Packages -showing domain classes only Role. Playing. Game «framework package» Characters «framework package» «application package» Encounter. Characters «uses» «application package» «uses» Encounter. Game Engagement. Display Encounter. Character Game. Environment Player. Character «framework package» Foreign. Character Player. Quality. Window Encounter. Environment «application package» Area Game. Artifacts «framework package» «uses» Encounter. Area. Connection. Hyperlink Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Mouse. Listener Encounter. Game. Displays Encounter. Cast Encounter. Display. Item Encounter. Display Qual. List. Displ Detailed Design of Encounter. Game. Displays Sub-package Set. Qual. Value. Displ Engagement. Display Set. Quality. Display Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Reporting handle. Event() Preparing handle. Event()

User : Engagement. Display Sequence Diagram for Dismissing Engagement Display : RPGMouse Event. Listener 1. hit dismiss button 2. mouse. Clicked() : Reporting. Encounter : Encounter. Game 3. handle. Event() 4. handle. Event() 5. set. Visible( false ) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 6. set. State (new Waiting())

Sequence Diagram for Player Completes Setup User : Player. Quality. Window : Setting. Up : RPGMouse Event. Listener 1. hit dismiss button 2. mouse. Clicked() : Encounter. Game 3. handle. Event() 4. handle. Event() 5. set. Visible( false ) 6. set. State (new Waiting()) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

User : Area. Connection. Hyperlink 1. hit area connection hyperlink : RPGMouse Event. Listener : Encounter. Cast : Waiting : Encounter. Environment : Encounter. Game 2. mouse. Clicked() 3. handle. Event() 5. set. Visible( false ) 4. handle. Event() 6. display. Area() 7. display. Player. Character() If foreign character present Sequence Diagram for Player Moves to Adjacent Area 8. display. Foreign. Character() 9. set. State (new Engaging()) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Detailed Design of Encounter. Characters Package Characters «framework package» Game. Character Encounter. Characters «application package» Encounter. Character «facade» Encounter. Cast Player. Character Foreign. Character Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Encounter. Environment Package Game. Environment Game. Character Game. Area. Connection . .

Encounter. Environment Package Game. Environment Game. Character Game. Area. Connection Area Encounter. Environment Encounter. Area. Connection. Hyperlink Encounter. Environment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.