{"id":6226,"date":"2022-05-26T04:11:39","date_gmt":"2022-05-26T04:11:39","guid":{"rendered":"https:\/\/www.booksofall.com\/in\/?post_type=product&p=6226"},"modified":"2022-06-15T05:12:53","modified_gmt":"2022-06-15T05:12:53","slug":"object-oriented-analysis-ooa","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/in\/object-oriented-analysis-ooa\/","title":{"rendered":"Object-Oriented Analysis (OOA)"},"content":{"rendered":"

Object-oriented analysis and design<\/b>\u00a0(OOAD<\/b>) is a technical approach for analyzing and designing an application, system, or business by applying\u00a0object-oriented programming<\/a>, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.<\/p>\n

OOAD in modern software engineering is typically conducted in an iterative and incremental way. The outputs of OOAD activities are analysis models (for OOA) and design models (for OOD) respectively. The intention is for these to be continuously refined and evolved, driven by key factors like risks and business value.<\/p>\n

History<\/span><\/h3>\n

In the early days of object-oriented technology before the mid-1990s, there were many different competing methodologies for software development and\u00a0object-oriented modeling<\/a>, often tied to specific\u00a0Computer Aided Software Engineering<\/a>\u00a0(CASE) tool vendors. No standard notations, consistent terms and process guides were the major concerns at the time, which degraded\u00a0communication efficiency<\/a>\u00a0and lengthened learning curves.<\/p>\n

Some of the well-known early object-oriented methodologies were from and inspired by gurus such as\u00a0Grady Booch<\/a>,\u00a0James Rumbaugh<\/a>,\u00a0Ivar Jacobson<\/a>\u00a0(the\u00a0Three Amigos<\/i>),\u00a0Robert Martin<\/a>,\u00a0Peter Coad<\/a>,\u00a0Sally Shlaer<\/a>,\u00a0Stephen Mellor<\/a>, and\u00a0Rebecca Wirfs-Brock<\/a>.<\/p>\n

In 1994, the\u00a0Three Amigos<\/i>\u00a0of Rational Software started working together to develop the\u00a0Unified Modeling Language<\/a>\u00a0(UML). Later, together with\u00a0Philippe Kruchten<\/a>\u00a0and Walker Royce (eldest son of\u00a0Winston Royce<\/a>), they have led a successful mission to merge their own methodologies,\u00a0OMT<\/a>,\u00a0OOSE<\/a>\u00a0and\u00a0Booch method<\/a>, with various insights and experiences from other industry leaders into the\u00a0Rational Unified Process<\/a> (RUP), a comprehensive iterative and incremental process guide and framework for learning industry best practices of software development and project management.\u00a0<\/sup>Since then, the\u00a0Unified Process<\/a>\u00a0family has become probably the most popular methodology and reference model for object-oriented analysis and design.<\/p>\n

Overview<\/span><\/h3>\n

The software life cycle is typically divided up into stages going from abstract descriptions of the problem to designs then to code and testing and finally to deployment. The earliest stages of this process are analysis and design. The analysis phase is also often called “requirements acquisition”.<\/p>\n

In some approaches to software development\u2014known collectively as waterfall models\u2014the boundaries between each stage are meant to be fairly rigid and sequential. The term “waterfall” was coined for such methodologies to signify that progress went sequentially in one direction only, i.e., once analysis was complete then and only then was design begun and it was rare (and considered a source of error) when a design issue required a change in the analysis model or when a coding issue required a change in design.<\/p>\n

The alternative to waterfall models are iterative models. This distinction was popularized by\u00a0Barry Boehm<\/a>\u00a0in a very influential paper on his Spiral Model for iterative software development. With iterative models it is possible to do work in various stages of the model in parallel. So for example it is possible\u2014and not seen as a source of error\u2014to work on analysis, design, and even code all on the same day and to have issues from one stage impact issues from another. The emphasis on iterative models is that software development is a knowledge-intensive process and that things like analysis can’t really be completely understood without understanding design issues, that coding issues can affect design, that testing can yield information about how the code or even the design should be modified, etc.<\/sup><\/p>\n

Although it is possible to do object-oriented development using a waterfall model, in practice most object-oriented systems are developed with an iterative approach. As a result, in object-oriented processes “analysis and design” are often considered at the same time.<\/p>\n

The object-oriented paradigm emphasizes modularity and re-usability. The goal of an object-oriented approach is to satisfy the\u00a0“open\u2013closed principle”<\/a>. A module is open if it supports extension, or if the module provides standardized ways to add new behaviors or describe new states. In the object-oriented paradigm this is often accomplished by creating a new subclass of an existing class. A module is closed if it has a well defined stable interface that all other modules must use and that limits the interaction and potential errors that can be introduced into one module by changes in another. In the object-oriented paradigm this is accomplished by defining methods that invoke services on objects. Methods can be either public or private, i.e., certain behaviors that are unique to the object are not exposed to other objects. This reduces a source of many common errors in computer programming.<\/sup><\/p>\n

The software life cycle is typically divided up into stages going from abstract descriptions of the problem to designs then to code and testing and finally to deployment. The earliest stages of this process are analysis and design. The distinction between analysis and design is often described as “what vs. how”. In analysis developers work with users and domain experts to define what the system is supposed to do. Implementation details are supposed to be mostly or totally (depending on the particular method) ignored at this phase. The goal of the analysis phase is to create a functional model of the system regardless of constraints such as appropriate technology. In object-oriented analysis this is typically done via use cases and abstract definitions of the most important objects. The subsequent design phase refines the analysis model and makes the needed technology and other implementation choices. In object-oriented design the emphasis is on describing the various objects, their data, behavior, and interactions. The design model should have all the details required so that programmers can implement the design in code.<\/p>\n

Object-oriented analysis<\/span><\/h3>\n

The purpose of any analysis activity in the\u00a0software life-cycle<\/a>\u00a0is to create a model of the system’s functional requirements that is independent of implementation constraints.<\/p>\n

The main difference between object-oriented analysis and other forms of analysis is that by the object-oriented approach we organize requirements around objects, which integrate both behaviors (processes) and states (data) modeled after real world objects that the system interacts with. In other or traditional analysis methodologies, the two aspects: processes and data are considered separately. For example, data may be modeled by\u00a0ER diagrams<\/a>, and behaviors by\u00a0flow charts<\/a>\u00a0or\u00a0structure charts<\/a>.<\/p>\n

Common models used in OOA are use cases and\u00a0object models<\/a>.\u00a0Use cases<\/a>\u00a0describe scenarios for standard domain functions that the system must accomplish. Object models describe the names, class relations (e.g. Circle is a subclass of Shape), operations, and properties of the main objects. User-interface mockups or prototypes can also be created to help understanding.<\/sup><\/p>\n

Object-oriented design<\/span><\/h3>\n
Main article:\u00a0Object-oriented design<\/a><\/div>\n

During object-oriented design (OOD), a developer applies implementation constraints to the conceptual model produced in object-oriented analysis. Such constraints could include the hardware and\u00a0software<\/a>\u00a0platforms, the performance requirements, persistent storage and transaction, usability of the system, and limitations imposed by budgets and time. Concepts in the analysis model which is technology independent, are mapped onto implementing classes and interfaces resulting in a model of the solution domain, i.e., a detailed description of\u00a0how<\/i>\u00a0the system is to be built on concrete technologies.<\/sup><\/p>\n

Important topics during OOD also include the design of\u00a0software architectures<\/a>\u00a0by applying\u00a0architectural patterns<\/a>\u00a0and\u00a0design patterns<\/a>\u00a0with the object-oriented design principles.<\/p>\n","protected":false},"excerpt":{"rendered":"