SEZ6C/SEE6C/PED2A OBJECT ORIENTED ANALYSIS AND DESIGN. Unit : I -V

Transcription

1 SEZ6C/SEE6C/PED2A OBJECT ORIENTED ANALYSIS AND DESIGN Unit : I -V

2 UNIT-I System Development Object Basics Development Life Cycle Methodologies Patterns Frameworks Unified Approach UML. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 2 / 75

3 Why an Object Orientation Higher Level of abstraction Seamless transition among different phases of software development. Encouragement of good programming techniques. Promotion of % ooad What kind of language can alleviate difficulties with communication & complexity hopefully well? SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 3

4 WATERFALL APPROACH SEZ6C//SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 4

5 OBJECT BASICS An "object" is anything to which a concept applies, in our awareness Things drawn from the problem domain or solution space. E.g., a living person in the problem domain, a software component in the solution space. A structure that has identity and properties and behavior It is an instance of a collective concept, i.e., a class. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 5

6 What is Object-Orientation - Abstraction and Encapsulation Abstraction Focus on the essential Omits tremendous amount of details Focus on what an object is and does Encapsulation a.k.a. information hiding Objects encapsulate: property behavior as a collection of methods invoked by messages state as a collection of instance variables SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 6

7 What is Object-Orientation? - Class <<instanceof> > <<instanceof> > <<instanceof> > Class Car Attributes Model Location #Wheels = 4 Operations Start Accelerate What is CLASS? a collection of objects that share common properties, attributes, behavior and semantics. A collection of objects with the same data structure (attributes, state variables) and behavior (function/code/operations) in the solution space. Classification Grouping of common objects into a class. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 7

8 What is Object-Orientation - Subclass vs. Superclass A A A B B B C C A A A A B <<instanceof>> B <<instanceof>> B <<instanceof>> B <<instanceof>> c: C c: C SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 8

9 What is Object-Orientation - Polymorphism Objects of different classes respond to the same message differently. Person name SSN paytuition Student std-id level paytuition Employee emp-id In-State Student paytuition Out-of- State Student state paytuition SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 9

10 What is Object-Orientation? -State What is STATE? "State" is a collection of association an object has with other objects and object types. What is STATE CHANGE? A "state change" is the transition of an object from one state to another. What is EVENT? An "event" is a noteworthy change in state [Rumbaugh] SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 10

11 How to Do OOAD Where to Use OO? Software Lifecycle Systems Engineering Requirements Analysis Project Planning Architectural Design Detailed Design Quality Assurance Maintenance Implementation Release Something missing? What s yours like? SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 11

12 How to Do OOAD OMT as Object-Oriented Methodology OMT (Object Modeling Technique) by James Rumbaugh Object Model: describes the static structure of the objects in the system and their relationships -> Object Diagrams. Dynamic Model: describes the interactions among objects in the system -> State Diagrams. Functional Model: describes the data transformation of the system -> DataFlow Diagrams. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 12

13 Booch method Class diagramsdescribe roles and responsibilities of objects Object diagrams describe the desired behavior of the system in terms of scenarios State transition diagrams state of a class based on a stimulus Module diagrams to map out where each class & object should be declared Process diagrams to determine to which processor to allocate a process Interaction diagrams describes behavior of the system in terms of scenarios SEZ6C/SEE6A/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 1 3

14 JACOBSON METHODOLOGIES Use Cases. Object Oriented Software Engineering. Object Oriented Business Engineering. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 1 4

15 OO SOFTWARE DEVELOPMENT LIFE CYCLE SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 1 5

16 UML The UML consists of the following diagrams: SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 1 6

17 UNIT-II Use-Case Models Object Analysis Object relations Attributes Methods Class and Object responsibilities Case Studies. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 17

18 OBJECT ORIENTED ANALYSIS PROCESS Identifying use cases Object Analysis Classification Identifying Object relationships Attributes and Methods. WHAT IS ANALYSIS? Analysis is the process of transforming a problem definition from a fuzzy set of facts and myths into a coherent statement of a system s requirements. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 18

19 Where Should We Start? 1. Examination of existing system documentation. 2. Interviews. 3. Questionnaire. 4. Observation. Requirements Difficulties Three most common sources of requirements difficulties are: 1. Incomplete requirements. 2. Fuzzy descriptions (such as fast response). 3. Unneeded features. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 19

20 The Object-Oriented Analysis (OOA) Process The process consists of the following steps: 1. Identify the actors: Who is using the system? Or, in the case of a new system, who will be using system? 2. Develop a simple business process model using UML activity diagram. 3. Develop the use case: What the users are doing with the system? Or, in the case of a new system, what users will be doing with the system? 4. Prepare interaction diagrams: Determine the sequence. Develop collaboration diagrams. 5. Classification develop a static UML class diagram:. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 20

21 The OOA Process (Con t) 6. Iterate and refine: If needed, repeat the preceding steps. Identify Actors Develop Use- Cases, ADs prototyping Develop Interaction Diagrams Identify Classes, Relationships, Attributes & Methods Refine and iterate USE CASE KEY CONCEPTS O-O Analysis Use case. Use case is a special flow of events through the system. Actors. An actor is a user playing a role with respect to the system. In a system. This simply means that the actors communicate with the system's use case. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 21

22 Extends Associations The extends association is used when you have one use case that is similar to another use case but does a bit more or Is more specialized; in essence, it is like a subclass. Library Borrow books uses Member Checking Library Card extends uses Inter library loan Circulation Clerk Return Books Performing research Reading books Newspaper Purchasing Supplies Supplier SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 22

23 Use case Driven Capture the user s needs (requirements - in users context) - Helps in Project Scheduling Analyse to specify the needs Design to realize the needs Implement to implement the needs Test to verify the needs Implemented by Verified by Test1 Test3 Realized by Test2 Use cases Specified by Design2 Design1 Test Design3 Design4 Implementation Analysis Design SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 23

24 Use Case Diagram Notation Actor Association Use Case Use case with Extension points <<Uses>> <<Extends>> SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 24

25 Documentation An effective document can serve as a communication vehicle among the project's team members, or it can serve as initial understanding of the requirements. All documents should share a common cover sheet that identifies the document, the current version, and the individual responsible for the content. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 25

26 80 20 Rule 80 percent of the work can be done with 20 percent of the documentation. The trick is to make sure that the 20 percent is easily accessible and the rest (80 percent) is available to those (few) who need to know. FAMILIAR VOCABULARY Use a vocabulary that your readers understand and are comfortable with. The main objective here is to communicate with readers and not impress them with buzz words. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 26

27 Classification The identification of classes and objects is the hardest part of object-oriented design. Booch Discovery recognize key abstractions and mechanisms from problem domain Invention devise generalized abstractions and new mechanisms that specify how objects collaborate SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 27

28 Approaches for Identifying Classes The noun phrase approach. The common class patterns approach. The use-case driven approach. The class responsibilities collaboration (CRC) approach. NOUN PHRASE APPROACH Using this method, you have to read through the Use cases, interviews, and requirements specification carefully, looking for noun phrases. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 28

29 NOUN PHRASE APPROACH All plurals are changed into singular Nouns are listed List divided into three categories Relevant classes Fuzzy classes (those classes that are not sure about) Irrelevant classes SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 29

30 COMMON CLASS PATTERNS APPROACH Concept class Event Class Organizations Class People Class Places Class Tangible things and devicesclass SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 30

31 USE CASE DRIVEN APPROACH SEQUENCE DIAGRAM Actor Class Synchronous message Asynchronous message Focus of Control Return message Termination lifeline SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 31

32 CASE STUDY- EXAMPLE SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 32

33 UNIT-III Design Processes Design Axioms Class Design Object Storage Object Interoperability Case Studies SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 33

34 Object-Oriented Design Process and Design Axioms Analysis Phase Class s attributes, methods and associations are identified Physical entities, players and their cooperation are identified Objects can be individuals, organizations or machines Design Phase Using Implementation language appropriate data types are assigned Elevate the model into logical entities (user interfaces) Focus is on the view and access classes (How to maintain information or best way to interact with a user) C7E07 SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 34

35 COROLLARY Corollary 1 Uncoupled design with less information content Corollary 2 Single process Corollary 3 Large number of simple classes Corollary 4 Strong mapping Corollary 5 Standardization Corollary 6 Design with inheritance SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 35

36 THE ORIGIN OF COROLLARY C7E07&index=2 SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 36

37 Design Patterns: Pattern name Rationale and motivation Classes Advantages/Disadvantages Examples Designing Classes: The Process Apply design axioms to design classes, their attributes, methods, associations, structures and protocols. Refine and complete the static UML class diagram by adding details to that diagram. Refine attributes Design methods and the protocols by utilizing a UML activity diagram to represent the methods s algorithm. Refine the associations between classes Refine the class hierarchy and design with inheritance. Iterate and refine. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 37

38 Class Visibility: Private Protocol Public Protocol Protected protocol Designing classes: Refining Attributes In the design phase, detailed information must be added to the model. The main goal of this activity is to refine existing attributes or add attributes that can elevated the system into implementation. Attributes Types: 1.Single-value attributes 2.Multiplicity or multivalue attributes 3.Reference to another object, or instance connection. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 38

39 UML Attribute Presentation: The following is the attribute presentation suggested by UML: Visibility name:type-expression=initial-value Where visibility is one of the following: + public visibility # protected visibility - private visibility Designing methods and protocols: A class can provide several types of methods: Constructor Destructor Conversion method Copy method Attribute set Attribute get SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 39

40 FIVE RULES FOR A GOOD TM DESIGN 1.If it looks messy, then it s probably a bad design 2.If it is too complex, then it s probably a bad design. 3.If it is too big, then it s probably a bad design. 4.If people don t like it, then it s probably a bad design. 5.If it doesn t work, then it s probably a bad design. Design issues: Avoiding Design pitfalls Keep a careful eye on the class design and make sure that an object s role remains well defined. If an object loses focus, you need to modify the design. Apply corollary 2.(single purpose) Move some functions into new classes that the object would use. Apply corollary1(uncoupled design with less information content) Break up the class into two or more classes. Apply corollary3(large number of simple classes) Rethink the class definition based on experience gained. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 40

41 CORBA SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 41

42 COOPERATIVE PROCESSING SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 42

43 Rules of object-oriented system: 1.The system must support complex objects. 2.Object identity must be supported. 3.Object must be encapsulated. 4.The system must support types or classes. 5.The system must support inheritance. 6.The system must avoid premature binding. 7.The system must be computationally complete. Rules make it a DBMS: 1.It must be persistent, able to remember an object state. 2.It must be able to manage very large database. 3.It must accept concurrent users. 4.It must be able to recover from hardware and software failures. 5.Data query must be simple. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 43

44 Object oriented database management systems: SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 44

45 Object Relation mapping: 1.Table-Class mapping 2.Table-multiple classes mapping 3.Table-inherited classes mapping 4.Tables-inherited classes mapping MULTI DATABASE SYSTEMS SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 45

46 Designing access layer classes: 1.Translate the request 2.Translate the results. The Process: 1.For every business class identified, mirror the business class package. 2.Define relationships. 3.Simplify classes and relationships. 1.Redundant classes 2.Method classes 4. Iterate and refine. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 46

47 OBJECT ORIENTED DESIGN PROCESS SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 47

48 REFINING ATTRIBUTES Attributes types 1. Single value attributes 2. Multiplicity or multivalue attributes 3. References to another object Attributes presentation : + public visibility # protected visibility - private visibility SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 48

49 UNIT-IV User Interface Design View layer Classes Micro-Level Processes View Layer Interface Case Studies. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 49

50 USER INTERFACE DESIGN Designing effective interfaces for software systems Objectives To suggest some general design principles for user interface design To explain different interaction styles To introduce styles of information presentation To describe the user support which should be built-in to user interfaces To introduce usability attributes and system approaches to system evaluation SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 50

51 DESIGNING VIEW LAYER CLASSES : 1.Designing View Layer classes 2.Macro level UI design process Micro level UI design activities 2.1 Designing the view layer objects by applying design axioms and corollaries 2.2 Prototyping the view layer interface 3. Testing the usability and user satisfaction 4. Refining and iterating the design SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 51

52 DESIGNING ACCESS LAYER Translate the request Translate the result SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 52

53 UI DESIGN RULES: 1. UI design rule 1: Making the interface simple(application of Corollary 2) 2. UI design rule 2: Making the interface transparent and natural.(application of Corollary 4) 3. UI design rule3:allowing users to be in control of the software(application of Corollary 1) -- Make the interface forgiving. Make the interface visual Provide immediate feedback. Avoid modes. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 53

54 GRAPHICAL USER INTERFACES Most users of business systems interact with these systems through graphical interfaces although, in some cases, legacy text-based interfaces are still used ADVANTAGES: They are easy to learn and use. Users without experience can learn to use the system quickly. The user may switch quickly from one task to another and can interact with several different applications. Information remains visible in its own window when attention is switched. Fast, full-screen interaction is possible with immediate access to anywhere on the screen SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 54

55 USER INTERFACE DESIGN PROCESS Analyse and understand user activities Produce paperbased design prototype Evaluate design with end-users Design prototype Produce dynamic design prototype Evaluate design with end-users Executable prototype Implement final user interface SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 55

56 CONTROL PANEL INTERFACE Title JSD. example Grid Busy Method JSD Type Network Units cm OUIT Selection Process Reduce Full PRINT NODE LINKS FONT LABEL EDIT SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 56

57 FORM-BASED INTERFACE NEW BOOK Title ISBN Author Publisher Edition Classification Date of purchase Price Publication date Number of copies Loan status Order status SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 57

58 MULTIPLE USER INTERFACE Gr aphical user interface Command language interface GUI manager Command language interpreter Operating system SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 58

59 INFORMATION PRESENTATION Information to be displayed Presentation software Display SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 59

60 TEXTUAL HIGHLIGHTING! The filename you have chosen has been used. Please choose an other name Ch. 16 User interface design OK Cancel SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 60

61 COLOR USE GUIDELINES Don't use too many colours Use colour coding to support use tasks Allow users to control colour coding Design for monochrome then add colour Use colour coding consistently Avoid colour pairings which clash Use colour change to show status change Be aware that colour displays are usually lower resolution SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 61

62 DESIGN FACTORS IN MESSAGE WORDING Context Exp erien ce Skill level Style Cult ure The user guidance s y stem should be aware of what t he user is doing and should adjust the output message to the current context. As us ers become familiar wit h a sy s tem they become irritated by long, meaningful messages. However, begin ners find it difficult to understand short terse statements of the problem. The user guidance system should provide both types of message and allow the user to control message conciseness. Messages should be tailored to the user s skills as well as their experience. M essages for the different classes of user may be expressed in different ways depending on the t ermino logy which is familiar to the reader. Messages should be positive rather than negative. They should use the active rather than the passive mode of address. They should never be insulting or try to be funny. Wherever p o ssible, t he des igner of mes sages s hould be familiar with the culture of the country where the system is sold. There are dist inct cult ural d ifferences bet ween Europ e, Asia and America. A suitable message for one culture might be unaccep table in an other. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 62

63 Guidelines for designing forms and Data entry windows: Navigating rows in a table, such as moving forward and backward, and going to the first and last record. Adding and deleting rows. Changing data in rows. Saving and abandoning changes We can put controls anywhere on a window. When entering data, users expect to type information from left to right and top to bottom. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 63

64 Guidelines for designing Dialog boxes and Error messages: A dialog box provides an exchange of information or a dialog between the user and application. Your error message should be positive. For eg., instead of displaying you have typed an illegal date format, display the message Enter date format mm/dd/yyyy. Your error message should be constructive. Your error message should be brief and meaningful. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 64

65 UNIT-V Quality Assurance Tests Testing Strategies Object orientation on testing Test Cases test Plans Continuous testing Debugging Principles System Usability Measuring User Satisfaction Case Studies. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 65

66 Quality Assurance Tests To develop and deliver robust systems, we need a high level of confidence that Each component will behave correctly. Collective behavior is correct No incorrect collective behavior will be produced. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 66

67 Types of Errors: Language Errors Run-time Errors Logic Errors SEZ6C-/SEE6C/PED2AOBJECT ORIENTED ANALYSIS AND DESIGN 67

68 QUALITY ASSURANCE TESTS Quality assurance (QA) is a way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers; which ISO 9000 defines as "part of quality management focused on providing confidence that quality requirements will be fulfilled". SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 68

69 Black Box Testing: Black Box Testing, also known as BehavioralTesting, is a software testing method in which the internal structure/ design/ implementation of the item being tested is not known to the tester SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 69

70 D/F B/W BLACK BOX AND WHITE BOX SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 70

71 TOP-DOWN TESTING Top-down testing is an approach to integratedtesting where the top integrated modules are testedand the branch of the module is tested step by step until the end of the related module SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 71

72 BOTTOM UP TESTING Bottom-up testing is an approach to integrated testing where the lowest level components are tested first, then used to facilitate the testing of higher level components SEZ6C-/SEE6C/PED2AOBJECT ORIENTED ANALYSIS AND DESIGN 72

73 IMPACT OF OBJECT- ORIENTATION ON TESTING Some types of errors could become less plausible. Some types of errors could become more plausible. Some new types of errors might appear. IMPACT OF INHERITANCE IN TESTING The base class contains methods inherited() and redefined() The derived class redefines the redefined()method. The derived::redefined has to be tested afresh since it is a new code. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 73

74 EXAMPLE FOR TEST CASE DOCUMENT SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 74

75 Guidelines for developing Quality Assurance Test Cases: Developing which feature or service your test attempts to cover. If the test case is based on a use case, it is a good idea to refer to the use-case name. Specify what you are testing and which particular methods, then specify what you are going to do to test the feature. Test the abnormal but reasonable use of the object s methods. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 75

76 Steps to create a Test plan: 1.Objectives of the test. 2.Development of a test case 3.Test analysis SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 76

77 Myers s Debugging principles: 1.Bug Locating principles. Think If you reach an impasse, sleep on it. If the impasse remains, describe the problem to someone else. Use debugging tools. Experimentation should be done as a last resort. Debugging Principles Where there is one bug, there is likely to be another. Fix the error, not just the symptom of it. The Probability of the solution being correct drops as the size of the program increases. Beware of the possibility that an error correction will create a new error SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 77

78 Usability Testing. The ISO defines Usability as Effectiveness Efficiency Satisfaction with which a specified set of users can achieve a specified set of tasks in particular environments. The ISO definition requires: Defining tasks. What are the tasks? Defining users. Who are the users? A means for measuring effectiveness, efficiency and satisfaction. SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 78

79 Guidelines for Developing Usability Testing: The usability testing should include all of a software s components. Usability testing need not be very expensive or elaborate. All tests need not involve many subjects. Quick, iterate tests with a small, well-targeted sample of 6 to 10 participants can identify 80-90npercent of most design problems. Apply usability testing early and often. Recording the Usability Test: Record the test results using 1.A portable tape recorder 2.Video camera SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 79

80 CUSTOMER FEEDBACK SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 80