Object Oriented Systems Development Life Cycle
Object Oriented Systems Development Life Cycle
- System development can be viewed as a process
- the development itself, in essence, is a process of change, refinement, transformation, or addition to existing product.
- The process can be divided into small, interacting phases – subprocesses. Each subprocess must have the following:
- A description in terms of how it works
- Specification of the input required for the process
- Specification of the output to be produced
- the software development process can be viewed as a series of transformations, where the output of one transformation becomes the input of the subsequent transformation.
- Transformation 1 (analysis) – translates the users’ needs into system requirements and responsibilities.
Transformation 2 (design) – begins with a problem statement and ends with a detailed design that can be transformed into an operational system.
Transformation 3 (implementation) – refines the detailed design into the system deployment that will satisfy users’ needs.
- An example of the software development process is the waterfall approach, which starts with deciding what is to be done. Once the requirements have been determined, we next must decide how to accomplish them. This is followed by a step in which we do it, whatever “it” has required us to do. We then must test the result to see if we have satisfied the users’ requirements. Finally, we use what we have done.
- To achieve high quality in software we should be able to answer the following questions:
- How do we determine that the system is ready for delivery?
- Is it now an operational system that satisfies users’ needs?
- Is it correct and operating as we thought it should?
- Does it pass an evaluation process?
- Blum describes a means of system evaluation in terms of four quality measures:
- Correspondence – measures how well the delivered system matches the needs of the operational environment, as described in the original requirements statement.
- Validation – task of predicting correspondence.
- Correctness – measures the consistency of the product requirements with respect to the design specification.
- Verification – exercise of determining correctness.
- Verification: Am I building the product right?
Validation: Am I building the right product?
- Validation begins as soon as the project starts, but verification can begin only after a specification has been accepted.
- The object-oriented software development life cycle (SDLC) consists of three macro processes:
- object-oriented analysis
- object-oriented design
- object-oriented implementation.
- Object oriented systems development includes these activities:
- Object-oriented analysis – use-case driven
- Object-oriented design
- Component-based development
- Incremental testing
- The object-oriented systems development approach. Object-oriented analysis corresponds to transformation 1; design to transformation 2, and implementation to transformation 3
- The object-oriented analysis phase of software development is concerned with determining the system requirements and identifying classes and their relationships to other classes in the problem domain.
- Actors: The users of the system.
- Use case: A typical interaction between a user and a system that captures users’ goals and needs. You capture a use case by talking to typical users, discussing the various things they might want to do with the system.
- Scenarios: Used to help analysts understand requirements. Scenarios are a great way of examining who does what in the interactions among objects and what role they play, that is, their interrelationships.
- Collaboration: The intersection among objects’ roles to achieve a given goal is called collaboration. The scenarios represent only one possible example of the collaboration. To understand all aspects of the collaboration and all potential actions, several different scenarios may be required, some showing usual behaviors, others showing situations involving unusual behavior or exceptions.
- Use-case modeling: Expressing these high-level processes and interactions with customers in a scenario and analyzing it is referred to as use-case modeling.
- The 80-20 rule generally applies for documentation: 80 percent of the work can be done with 20 percent of the documentation.
- The goal of object-oriented design is to design the classes identified during the analysis phase and the user interface. During this phase, we identify and define additional objects and classes that support implementation of the requirements.
- The activities and focus of object-oriented analysis and object-oriented design are intertwined – grown, not built.
- First, build the object model based on objects and their relationships, then iterate and refine the model:
- Design and refine classes
- Design and refine attributes
- Design and refine methods
- Design and refine structures
- Design and refine associations
- Here are a few guidelines to use in your object-oriented design:
- Reuse, rather than build, a new class. Know the existing classes.
- Design a large number of simple classes, rather than a small number of complex classes.
- Design methods.
- Critique what you have proposed. If possible, go back and refine the classes.
- Although the object-oriented analysis and design describe the system features, it is important to construct a prototype of some of the key system components shortly after the products are selected.
- a prototype is a version of a software product developed in the early stages of the product’s life cycle for specific experimental purposes.
- A prototype enables you to fully understand how easy or difficult it will be to implement some of the features of the system.
It also can give users a chance to comment on the usability and usefulness of the user interface design and it lets you assess the fit between the software tools selected, the functional specification, and the users’ needs.
Prototype can further define the use cases, and it actually makes use-case modeling much easier.
Prototypes have been categorized in various ways:
- A horizontal prototype is a simulation of the interface (that is, it has the entire user interface that will be in the full-featured system) but contains no functionality.
- A vertical prototype is a subset of the system features with complete functionality. The principal advantage of this method is that the few implemented functions can be tested in great depth. Generally prototypes are hybrid between the two.
- An analysis prototype is an aid for exploring the problem domain. It is used to inform the user and demonstrate the proof of a concept. In full featured system, only the concept is used and not the code.
- A domain prototype is an aid for the incremental development of the ultimate software solution. This can evolve into a deliverable product.
The purpose of the prototype review is threefold:
- To demonstrate that the prototype has been developed according to the specification and that the final specification is appropriate.
- To collect information about errors or other problems in the system, such as user interface problems that need to be addressed in the intermediate prototype stage.
- To give management and everyone connected with the project the first (or it could be second or third …) glimpse of what the technology can provide.
- CASE Tools: Computer Aided Software Engineering (CASE) tools allow their users to rapidly develop information systems. The main goal of CASE technology is the automation of the entire information systems development life cycle process using a set of integrated software tools, such as modeling, methodology, and automatic code generation.
- A new generation of CASE tools is beginning to support Component Based Development.
- Component Based Development: CBD is an industrialized approach to the software development process. Application development moves from custom development to assembly of prebuilt, pretested, reusable software components that operate with each other
- Software Components: The software components are the functional units of a program, building blocks offering a collection of reusable services.
- Rapid Application Development: RAD is a set of tools and techniques that can be used to build an application faster than typically possible with traditional methods. The term often is used in conjunction with software prototyping. RAD does not replace the system development life cycle but complements it, since it focuses more on process description and can be combined perfectly with the object-oriented approach. The task of RAD is to build the application quickly and incrementally implement the design and user requirements, through tools such as Delphi, Visual Age, Visual Basic, or Power Builder.
- Testing should be integral part of SDLC.
- A major benefit of object-oriented system development is reusability, and this is the most difficult promise to deliver on. You must effectively evaluate existing software components for reuse by asking the following questions as they apply to the intended application:
- Has my problem already been solved?
- Has my problem been partially solved?
- What has been done before to solve a problem similar to this one?
- The reuse strategy can be based on the following:
- Information hiding (encapsulation)
- Conformance to naming standards
- Creation and administration of an object repository
- Encouragement by strategic management of reuse as opposed to constant redevelopment
- Establishing targets for a percentage of the objects in the project to be reused (i.e. 50 percent reuse of objects)