Object-oriented analysis and design
|Wikiversity has learning materials about Object Oriented Software Design|
Object-oriented analysis and design (OOAD) is an approach to modeling an application that is used at the beginning of the software life cycle when using an object-oriented approach to software development.
The object-oriented paradigm emphasizes modularity and re-usability. The goal of an object-oriented approach is to satisfy the "open closed principle". A module is open if it supports extension. 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.
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.
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".
In some approaches to software development -- known collectively as waterfall models -- the 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.
The alternative to waterfall models are iterative models. This distinction was popularized by Barry Boehm in 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 -- and not seen as a source of error -- to 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.
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.
In the early days of object-oriented technology there were many different methodologies for software development, often tied to specific Computer Aided Software Engineering (CASE) tool vendors. Some of the most popular early methodologies were from Object-Oriented gurus such as Grady Booch, Joseph Rumbaugh, Ivar Jacobsen, Sally Shlaer, and Stephen Mellor.
At the present time (December 2013) the most popular methodology for object-oriented analysis and design is the Rational Unified Process. Rational was originally founded by Grady Booch, but they acquired and incorporated various aspects from the other leaders in the object-oriented world to attempt to develop a process that gave developers the best features of the various methods.
The purpose of any analysis phase in the software life-cycle is to create a model of the system's functional requirements that is independent of implementation constraints. The main difference between object-oriented analysis and other forms of analysis is that in the object-oriented approach we organize requirements around objects. Objects integrate both behavior (process) and state (data) modeled after the real world objects that the system interacts with. In other forms of analysis the two models: process and data are considered separately. For example, data may be modeled using entity-relation models and behavior as flow charts or structure charts.
The primary tasks in object-oriented analysis are:
- Find the objects
- Organize the objects
- Describe how the objects interact
- Define the behavior of the objects
- Define the internals of the objects
Common models used in object-oriented analysis are use cases and object models. Use cases describe scenarios for standard domain functions that the system must accomplish. Object models describe the names, class relations (e.g. circle is subclass of shape), operations, and properties of the main objects. User-interface mockups or prototypes can also be created in this phase.
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 software platforms, the performance requirements, persistent storage and transaction, usability of the system, and limitations imposed by budgets and time. Concepts in the analysis model are mapped onto implementation classes and interfaces resulting in a model of the solution domain, i.e., a detailed description of how the system is to be built.
- Grady Booch. "Object-oriented Analysis and Design with Applications, 3rd edition":http://www.informit.com/store/product.aspx?isbn=020189551X Addison-Wesley 2007.
- Rebecca Wirfs-Brock, Brian Wilkerson, Lauren Wiener. Designing Object Oriented Software. Prentice Hall, 1990. [A down-to-earth introduction to the object-oriented programming and design.]
- A Theory of Object-Oriented Design: The building-blocks of OOD and notations for representing them (with focus on design patterns.)
- Martin Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997. [An introduction to object-oriented analysis with conceptual models]
- Bertrand Meyer. Object-oriented software construction. Prentice Hall, 1997
- Craig Larman. Applying UML and Patterns - Introduction to OOA/D & Iterative Development. Prentice Hall PTR, 3rd ed. 2005.,mnnm,n,nnn
- Setrag Khoshafian. Object Orientation.
- Norbisrath Zündorf Jubeh, Ulrich Albert Ruben (2013). Story Driven Modeling. Amazon Createspace. p. 333. ISBN 9781483949253.
- ATLAS Transformation Language ATL
- Class-Responsibility-Collaboration card (CRC cards)
- Domain-driven design
- Domain Specific Language (DSL)
- Domain-specific modelling (DSM)
- Meta-Object Facility MOF
- Model Driven Engineering (MDE)
- Model-based testing (MBT)
- Object-oriented modeling
- Object-oriented programming
- Object-oriented user interface
- Object modeling language
- Software analysis pattern
- Story-driven modeling
- Unified Modeling Language UML
- XML Metadata Interchange XMI
- Meyer, Bertrand (1988). Object-Oriented Software Construction. Cambridge: Prentise Hall International Series in Computer Science. p. 23. ISBN 0-13-629049-3.
- Jacobsen, Ivar; Magnus Christerson, Patrik Jonsson, Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 15,199. ISBN 0-201-54435-0.
- Boehm B, "A Spiral Model of Software Development and Enhancement", IEEE Computer, IEEE, 21(5):61-72, May 1988
- "Rational Unified Process Best Practices for Software Development Teams". Rational Software White Paper (TP026B). 11/01. Retrieved 12 December 2013.
- Jacobsen, Ivar; Magnus Christerson, Patrik Jonsson, Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 77–79. ISBN 0-201-54435-0.
- Conallen, Jim (2000). Building Web Applications with UML. Addison Wesley. p. 147. ISBN 0201615770.
- Article Object-Oriented Analysis and Design with UML and RUP an overview (also about CRC cards).
- Applying UML - Object Oriented Analysis & Design tutorial
- OOAD & UML Resource website and Forums - Object Oriented Analysis & Design with UML.
- Software Requirement Analysis using UML article by Dhiraj Shetty.
- Article Object-Oriented Analysis in the Real World