Object oriented analysis emphasizes investigating the problem domain to identify relevant objects and their relationships. The key goals are to define relevant classes and their attributes, operations, relationships, and behaviors through iterative refinement. Various analysis methods take different approaches, but generally involve use case modeling, class modeling, and behavior modeling.

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.

7. Key Difference STRUCTURED OBJECT ORIENTED 1. DFD'S 1. USE CASE MODEL 2. DECISION TABLE/TREE 2. OBJECT MODEL - Find classes & class relations - Object relations : 1. Sequence Diagram 2. Collaboration Diagram 3. State Machine Diagram 3. ER ANALYSIS

8. The OOA Landscape Different Object Oriented Analysis Methods : BOOCH METHO RUMBAUGH METHOD JACOBSON METHOD COAD AND YOURDON METHOD WIRFS-BROCK METHOD

9. Booch Method Strongly emphasizes the iterative process and the creativity of the developer as essential components in OO Design. The method is more a set of heuristics and no strict baselines or order of work exists

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.

11. Rumbaugh Method Developed the object modelling technique(OMT) for analysis, system design, object-level design and implementation. Three models of the system are developed initially and then refined in all these phases. 1. Object Model 2. Dynamic Model & 3. Functional Model

12. Object Model describes the static structure of the system with classes and their relationships. Dynamic Model captures the temporal aspects of the object model with events and states of the objects. Functional Model describes the computation in terms of how output values are derived from input values.

13. Jacobson Method Also called OOSE (object-oriented software engineering). Traditional methods treat functions and data as separate. Such approach often leads to problem during maintenance. Object Oriented S/W Engineering do not separate functions and data, but views them as an integrated whole.

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.

15. 1. Finding Class and Object : Specifies how classes and objects should be found. 2. Identifying Structures : It is done in two different ways. Generalization-Specification Structure The Whole-Part Structure 3. Identifying Subjects : It is done by partitioning the class and objects models into larger units. Subject is group of classes and objects.

16. 4. Defining Attributes : It is done by identifying information and the associations that should be associated with each and every instance. The identified attributes are place in correct level of inheritance hierarchy. 5. Defining Services : It means defining the operations of the classes.

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 .

20. Unified Approach To OOA Grady Booch, James Rumbaugh, and Ivar Jacobson collaborated to combine the best features of their individual object-oriented analysis and design methods into a unified method. The result, called the Unified Modelling Language (UML)

21. Views Of System In UML User Model View : This view represents the system (product) from the user’s (called actors in UML) perspective. Structural Model View : Data and functionality are viewed from inside the system. That is, static structure (classes, objects, and relationships) is modeled.

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. .

23. Domain Analysis The objective of domain analysis is to define a set of classes (objects) that are encountered throughout an application domain. These can then reused in many applications.

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.

26. Components Identified 1. Static view of semantic classes : Requirements are assessed and classes are extracted (and represented) as part of the analysis model. 2. Static view of attributes : Every class must be explicitly described. The attributes associated with the class Provide a description of the class.

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.

30. Use-Cases use-cases model the system from the end-user’s point of view. To define the functional and operational requirements of the system. To provide a clear and unambiguous description of how the end-user and the system interact with one another.

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.