1. INTRODUCTION TO OBJECT ORIENTED ANALYSIS

2. . Analysis emphasizes an investigation of the problem and requirements, rather than a solution. In Object Oriented Analysis , there is an emphases on finding and describing the objects or concepts in the problem domain.

3. . PURPOSE 1. How to characterize a system. 2. To know what are the different Relevent objects. 3. How do they relate to one another. 4. How to specify or model a problem to create effective design. 5. Examine requirements, analyze their implications.

4. Intend To define all classes that are relevant to the problem to be solved— the operations and attributes associated with them, the relationships between them, and behaviour they exhibit. To accomplish this, number of tasks must occur - 1. Basic user requirements must be known.

5. 2. Classes must be identified (i.e., attributes and methods are defined). 3. A class hierarchy must be specified. 4. Object-to-object relationships (object connections) should be represented. 5. Object behaviour must be modelled. 6. Tasks 1 through 5 are reapplied iteratively until the model is complete.

6. Conventional Vs OO Analysis Structured Analysis treats processes and data as Separate components. Whereas OO Analysis Combines data and the process that acts on the data into objects.

10. The Process Of OOD Generally Tracks Following Order Of Events 1. Identify classes and objects at a given level of abstraction. 2. Identify the semantics of these classes and objects. 3. Identify the relationships among these classes and objects. 4. Implement these classes and objects.

14. Coad And Yourdon Method The idea in this method is to extend the model with respect to processes, human interfaces and DBMS issues. The method consists of following 5 steps.

17. Wirfs-brock Method Wirfs-Brock, do not make a clear distinction between analysis and design tasks. Rather a continuous process that begins with the assessment of a customer specification and ends with design is proposed.

18. Generic Steps For OOA 1. Elicit customer requirements for the system. 2. Identify scenarios or use-cases. 3. Select classes and objects using basic requirements as a guide. 4. Identify attributes and operations for each system object.

19. 5. Define structures and hierarchies that organize classes. 6. Build an object-relationship model. 7. Build an object-behaviour model. 8. Review the OO analysis model against use- cases or scenarios .

22. Behavioural Model View : This part of the analysis model represents the dynamic or behavioural aspects of the system Implementation Model View : The structural and behavioural aspects of the system are represented as they are to be built. Environment Model View : The structural and behavioural aspects of the environment in which the system is to be implemented are represented. .

24. Domain Analysis Process Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain

25. Generic Component Of OO Analysis Model Static components : This are structural in nature and indicate characteristics that hold throughout the operational life of an application. Dynamic Components : Focus on control and are sensitive to timing and event processing. They define how one object interacts with other objects over time.

27. 3. Static view of relationships : Represent the relationships so that operations can be identified and the design of a messaging approach can be accomplished. 4. Static view of behaviours : define a set of behaviours that accommodate the usage scenario (use-cases) of the system.

28. 5. Dynamic view of communication : Describes how object communicate with one another based on the series of events that cause transition from one state to another. 6. Dynamic view of control and time : The nature and timing of events that cause transitions among states are described.

29. OBJECT ORIENTED PROCESS Techniques that may be used to gather basic customer requirements and then define an analysis model for an object- oriented system.

31. Class-Responsibility-Collaborator Modeling Once basic usage scenarios have been developed for the system, it is time to identify candidate classes and indicate their responsibilities and collaborations. Called Class- responsibility-collaborator (CRC) modeling. It provides a simple means for identifying and organizing the classes that are relevant to system or product requirements.