Object Oriented Development Cycle
Object Oriented development activities include:
Requirements Elicitation - Analysis
- System Design
- Object Design
- Implementation
- Testing
Requirements Elicitation
During requirements elicitation, the client and developers define the purpose of the system.The result of this activity is a description of the system in terms of actors and use cases. Actors represent the external entities that interact with the system. Actors include roles such as end users, other computers the system needs to deal with (e.g., a central bank computer, a network), and the environment (e.g., a chemical process). Use cases are general sequences of events that describe all the possible actions between an actor and the system for a given piece of functionality.
Analysis
During analysis, developers aim to produce a model of the system that is correct, complete,consistent, and unambiguous. Developers transform the use cases produced during requirements elicitation into an object model that completely describes the system. During this activity, developers discover ambiguities and inconsistencies in the use case model that they resolve with the client. The result of analysis is a system model annotated with attributes, operations, and associations. The system model can be described in terms of its structure and its dynamic interoperation.
System Design
During system design, developers define the design goals of the project and decompose the system into smaller subsystems that can be realized by individual teams. Developers also select strategies for building the system, such as the hardware/software platform on which the system will run, the persistent data management strategy, the global control flow, the access control policy, and the handling of boundary conditions. The result of system design is a clear description of each of these strategies, a subsystem decomposition, and a deployment diagram
representing the hardware/software mapping of the system. Whereas both analysis and system design produce models of the system under construction, only analysis deals with entities that the client can understand. System design deals with a much more refined model that includes many entities that are beyond the comprehension (and interest) of the client.
Implementation
During implementation, developers translate the solution domain model into source code. This includes implementing the attributes and methods of each object and integrating all the objects such that they function as a single system. The implementation activity spans the gap between the detailed object design model and a complete set of source code files that can be compiled.
Testing
During testing, developers find differences between the system and its models by executing the system (or parts of it) with sample input data sets. During unit testing, developers compare the object design model with each object and subsystem. During integration testing, combinations of subsystems are integrated together and compared with the system design model. During system testing, typical and exception cases are run through the system and compared with the requirements model. The goal of testing is to discover as many faults as possible such that they can be repaired before the delivery of the system. The planning of test phases occurs in parallel to the other development activities: System tests are planned during requirements elicitation and analysis, integration tests are planned during system design, and unit tests are planned during object design.
Unified Process
A software development process describes an approach to building, deploying, and possibly maintaining software. The Unified Process has emerged as a popular software development process for building object-oriented systems. In particular, the Rational Unified Process or RUP, a detailed refinement of the Unified Process, has been widely adopted.
The Most Important UP Idea: Iterative Development
The UP promotes several best practices, but one stands above the others: iterative development. In this approach, development is organized into a series of short, fixed-length (for example, four week) mini-projects called iterations; the outcome of each is a tested, integrated, and executable system. Each iteration includes its own requirements analysis, design, implementation, and testing activities.
The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system. The system grows incrementally over time, iteration by iteration, and thus this approach is also known as iterative and incremental development.
Notice in this example that there is neither a rush to code, nor a long drawn-out design step that attempts to perfect all details of the design before program- ming. A "little" forethought regarding the design with visual modeling using rough and fast UML drawings is done; perhaps a half or full day by developers doing design work in pairs.
The result of each iteration is an executable but incomplete system; it is not ready to deliver into production. The system may not be eligible for production deployment until after many iterations; for example, 10 or 15 iterations.
The output of an iteration is not an experimental or throw-away prototype, and iterative development is not prototyping. Rather, the output is a production-grade subset of the final system.
Although, in general, each iteration tackles new requirements and incremen- tally extends the system, an iteration may occasionally revisit existing software and improve it; for example, one iteration may focus on improving the performance of a subsystem, rather than extending it with new features.
Benefits of Iterative Development
Benefits of iterative development include:
- early rather than late mitigation of high risks (technical, requirements, objectives, usability, and so forth.
- early visible progress..
- early feedback, user engagement, and adaptation, leading to a refined system that more closely meets the real needs of the stakeholders
- managed complexity; the team is not overwhelmed by "analysis paralysis" or very long and complex steps
- the learning within an iteration can be methodically used to improve the development process itself, iteration by iteration.
The UP Phases and Schedule-Oriented Terms
A UP project organizes the work and iterations across four major phases:
- Inception— approximate vision, business case, scope, vague estimates.
- Elaboration—refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates.
- Construction—iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.
- Transition—beta tests, deployment.
This is not the old "waterfall" or sequential lifecycle of first defining all the requirements, and then doing all or most of the design.
Inception is not a requirements phase; rather, it is a kind of feasibility phase, where just enough investigation is done to support a decision to continue or stop.
Similarly, elaboration is not the requirements or design phase; rather, it is a phase where the core architecture is iteratively implemented, and high risk issues are mitigated.
