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. 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 Reusability. % What kind of language can alleviate difficulties with communication & complexity hopefully well? 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. 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 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. 7

8 What is Object-Orientation - Subclass vs. Superclass A A A B B B C C A A <<instanceof>> B <<instanceof>> B A A B B <<instanceof>> c: C <<instanceof>> c: C 8

9 What is Object-Orientation - Polymorphism Objects of different classes respond to the same message differently. Person name SSN Student Employee emp-id paytuition std-id level paytuition In-State Student Out-ofState Student state paytuition paytuition 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] 10

11 How to Do OOAD Where to Use OO? Software Lifecycle Systems Engineering Project Planning Architectural Design Detailed Design Implementation Quality Assurance Requirements Analysis Maintenance Something missing? Release What s yours like? 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. 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 13

14 JACOBSON METHODOLOGIES Use Cases. Object Oriented Software Engineering. Object Oriented Business Engineering. 14

15 OO SOFTWARE DEVELOPMENT LIFE CYCLE 15

16 UML The UML consists of the following diagrams: 16

17 UNIT-II Use-Case Models Object Analysis Object relations Attributes Methods Class and Object responsibilities Case Studies. 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. 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. 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:. 20

21 The OOA Process (Con t) 6. Iterate and refine: If needed, repeat the preceding steps. Develop UseCases, ADs Identify Actors prototyping Develop Interaction Diagrams Identify Classes, Relationships, Attributes & Methods Refine and iterate O-O Analysis USE CASE KEY CONCEPTS 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. 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 uses Borrow books extends Checking Library Card uses Inter library loan Circulation Clerk Member Return Books Performing research Reading books Newspaper Supplier Purchasing Supplies 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 Test2 Realized by Specified by Test3 Design1 Test Use cases Design2 Design4 Implementation Design3 Analysis Design 23

24 Use Case Diagram Notation Actor Association Use Case Use case with Extension points <<Uses>> <<Extends>> 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. 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. 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 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. 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 29

30 COMMON CLASS PATTERNS APPROACH Concept class Event Class Organizations Class People Class Places Class Tangible things and devicesclass 30

31 USE CASE DRIVEN APPROACH SEQUENCE DIAGRAM Actor Class Synchronous message Asynchronous message Focus of Control Return message Termination lifeline 31

32 CASE STUDY- EXAMPLE 32

33 UNIT-III Design Processes Design Axioms Class Design Object Storage Object Interoperability Case Studies 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 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 35

36 THE ORIGIN OF COROLLARY C7E07&index=2 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. 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. 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 39

40 FIVE RULES FOR A GOOD 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. 40

41 CORBA 41

42 COOPERATIVE PROCESSING 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. 43

44 Object oriented database management systems: 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 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. 46

47 OBJECT ORIENTED DESIGN PROCESS 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 48

49 UNIT-IV User Interface Design View layer Classes Micro-Level Processes View Layer Interface Case Studies. 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 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 51

52 DESIGNING ACCESS LAYER Translate the request Translate the result 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. 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 54

55 USER INTERFACE DESIGN PROCESS Analyse and understand user activities Produce paperbased design prototype Design prototype Evaluate design with end-users Produce dynamic design prototype Executable prototype Evaluate design with end-users Implement final user interface 55

56 CONTROL PANEL INTERFACE Grid Busy Title JSD. example Method JSD Type Network Units cm Selection Process Reduce Full OUIT PRINT NODE LINKS FONT LABEL EDIT 56

57 FORM-BASED INTERFACE NE W BOOK Title ISBN Author Price Publisher Publication date Edition Number of copies Classification Date of purchase Loan status Order status 57

58 MULTIPLE USER INTERFACE Gr aphical user interface Command language interface GUI manager Command language interpreter Operating system 58

59 INFORMATION PRESENTATION Information to be displayed Presentation software Display 59

60 TEXTUAL HIGHLIGHTING! The filename you have chosen h as been used. Please choose an other name Ch. 16 User interface design OK Cancel 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 61

62 DESIGN FACTORS IN MESSAGE WORDING Context Experience Skill level Style Culture The user guidance system should be aware of what the user is doing and should adjust the output message to the current context. As users become familiar with a system they become irritated by long, meaningful messages. However, beginners find it difficult to understand short terse statements of the problem. The user guidance system should provide bothtypes of message and allow the user to control message conciseness. Messages should be tailored to the user s skills as well as their experience. Messages for the different classes of user may be expressed in different ways depending on the terminology 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 possible, the designer of messages should be familiar with the culture of the country where the system is sold. There are distinct cultural differences between Europe, Asia and America. A suitable message for one culture might be unacceptable in another. 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. 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. 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. 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. 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". 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 69

70 D/F B/W BLACK BOX AND WHITE BOX 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 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 OBJECTORIENTATION 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. 73

74 EXAMPLE FOR TEST CASE DOCUMENT 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. 75

76 Steps to create a Test plan: 1.Objectives of the test. 2.Development of a test case 3.Test analysis 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 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. 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 8090npercent 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 79

80 CUSTOMER FEEDBACK 80