Difference between Structured and Object-Oriented Analysis
Analysis simple means to study or examine the structure of something, elements, system requirements in detail, and methodical way. Structured analysis and Object-oriented analysis both are important for software development and are analysis techniques used in software engineering. But both are different from each other.
1. Structured Analysis :
Structured analysis is method of development that allows and gives permission to the analyst to understand and know about the system and all of its activities in a logical way. It is simply a graphic that is used to specify the presentation of the application.
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.
2. Object-Oriented Analysis :
Object-Oriented Analysis (OOA) is technical approach generally used for analyzing and application designing, system designing, or even business designing just by applying object-oriented programming even with the use of visual modeling throughout the process of development to just simply guide the stakeholder communication and quality of the product. it is actually a process of discovery where a team of development understands and models all the requirements of the system.
Difference Between Structured and Object-oriented analysis :
Structured Analysis Object-Oriented Analysis The main focus is on process and procedures of system. The main focus in on data structure and real-world objects that are important. It uses System Development Life Cycle (SDLC) methodology for different purposes like planning, analyzing, designing, implementing, and supporting an information system. It uses Incremental or Iterative methodology to refine and extend our design. It is suitable for well-defined projects with stable user requirements. It is suitable for large projects with changing user requirements. Risk while using this analysis technique is high and reusability is also low. Risk while using this analysis technique is low and reusability is also high. Structuring requirements include DFDs (Data Flow Diagram), Structured English, ER (Entity Relationship) diagram, CFD (Control Flow Diagram), Data Dictionary, Decision table/tree, State transition diagram. Requirement engineering includes Use case model (find Use cases, Flow of events, Activity Diagram), the Object model (find Classes and class relations, Object interaction, Object to ER mapping), Statechart Diagram, and deployment diagram. This technique is old and is not preferred usually. This technique is new and is mostly preferred.