Pdf on ooad

Over-Riding allows us to write a specialised draw method for the EstateCar class - There is no need to write a new draw method for the SaloonCar class as the Car class provides a suitable enough draw method. All we have to do is write a new draw method in the EstateCar class with the exact same method name. So, Over-Riding allows:. A more straightforward API where we can call methods the same name, even thought these methods have slightly different functionality.

Over-Loading is the second form of polymorphism. The same method name can be used, but the number of parameters or the types of parameters can differ, allowing the correct method to be chosen by the compiler.

For example:. However, when we pass two String objects instead of two int variables then we expect different functionality. In other words the strings should be concatenated. An abstract class is a class that is incomplete, in that it describes a set of operations, but is missing the actual implementation of these operations.

Abstract classes:. For example: In the Vehicle class example previously the draw method may be defined as abstract as it is not really possible to draw a generic vehicle. By doing this we are forcing all derived classes to write a draw method if they are to be instantiated.

As discussed previously, a class is like a set of plans from which you can create objects. In relation to this analogy, an abstract class is like a set of plans with some part of the plans missing.

The draw has been written in all of the classes and has some functionality. The draw in the Vehicle has been tagged as abstract and so this class cannot be instantiated - i. In Figure 1. Therefore, it is possible to create objects of SaloonCar.

If we required we could also tag the draw method as abstract in a derived class, for example we could also have tagged the draw as abstract in the Car class. This would mean that you could not create an object of the Car class and would pass on responsibility for implementing the draw method to its children - see Figure 1.

The abstract draw method in the Vehicle and Car classes. As discussed previously, object-oriented programming has been around since the s. Formal design processes when using objects involves many complex stages and are the debate of much research and development. Analyse the problem - The programmer must find the important concepts of the problem. The Waterfall Model [1] , as illustrated in Figure 1. It is the most common software development life cycle model and is particularly useful when specifying overview project plans, as it fits neatly into a Gantt chart format [2].

Requirements Definition : The customer must define the requirements to allow the developer to understand what is required of the software system. If this development is part of a larger system then other development teams must communicate to develop system interfaces. Analysis :The requirements must be analysed to form the initial software system model.

Design : The design stage involves the detailed definition of inputs, outputs and processing required of the components of the software system model.

Coding : The design is now coded, requiring quality assurance of inspection, unit testing and integration testing. System Tests : Once the coding phase is complete, system tests are performed to locate as many software errors as possible.

This is carried out by developer before the software is passed to the client. The client may carry out further tests, or carry out joint tests with the developer. Installation and Conversion : The software system is installed. As part of a larger system, it may be an upgrade; in which case, further testing may be required to ensure that the conversion to the upgrade does not effect the regular corporate activity.

Operation and Maintenance : Software operation begins once it is installed on the client site. Maintenance will be required over the life of the software system once it is installed.

The Waterfall Model is a general model, where in small projects some of the phases can be dropped. In large scale software development projects some of these phases may be split into further phases. At the end of each phase the outcome is evaluated and if it is approved then development can progress to the next phase.

If the evaluation is rejected then the last phase must be revisited and in some cases earlier phases may need to be examined. The thinner lines show a retrace of steps to the same phase or previous phases. The Spiral Model [3] was suggested by Boehm as a methodology for overseeing large scale software development projects that show high prospects for failure. It is an iterative model that builds in risk analysis and formal client participation into prototype development.

This model can be illustrated as in Figure 1. The spiral, as shown in Figure 1. More advanced forms of this model are available for dealing with further communication with the client. The spiral model is particularly suited to large scale software development projects and needs constant review. For smaller projects an agile development model is more suitable. One object-oriented methodology is based around the re-use of development modules and components. In others words, this model represents the artifacts of the system.

Coad-Yourdon methodology has its primary strength in system analysis. Functionality is restricted within objects. Metjodology represented by a thick horizontal or vertical line. Jacobaon be viewed as the implementation of a system of design patterns. If two operations of a single object are concurrent in nature, then that object is split among different threads. Servers as a contract between customer and developer. The iterative process helps to reduce confusion around what the system is really suppose to do and what the users really want.

In the object-oriented paradigm this is accomplished by defining methods that invoke services on objects. Now, we will look at the relative advantages and disadvantages of structured analysis approach and object-oriented analysis approach. The earliest stages of this process are analysis and design. The iterative process either adds new or more clearly defines existing properties, unlike the traditional approach that would re-hash specifications that are already done.

Jacbson may be either unidirectional or bidirectional. It is represented by a labeled arrow. 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.

Through a link, one object may invoke the methods or navigate through another object. The system is conceived as a set of interacting subsystems that in turn is composed of a hierarchy of interacting objects, grouped into classes.

If you find an error or have a suggestion for improving our content, we would appreciate your feedback. Systems with multiple CPUs inherently permit concurrent threads of control; but systems running on a single CPU use appropriate algorithms to give equitable CPU time to the threads so as to enable concurrency.

Constraints in classes restrict the range and type of values that the attributes may take. Polymorphism allows objects with different internal structures to have a common external interface.

As it follows a top-down approach in contrast to bottom-up approach of object-oriented analysis, it can be more easily comprehended than OOA. Each of the state machines has its own initial and final states. Architecture Centric Architecture centric means that the underlying software architecture of the evolving system specification drives the specification, constructions, and documentation of the system. Modern object. The functional, or external, view describes the system in terms of behavior of the system in terms of messages passed among objects and state changes withing an object.

Iterative and Incremental Modern object-oriented systems analysis and design approaches emphasize iterative and incremental development that undergoes continuous testing and refinement throughout the life of the project.

The systems analyst does this by working with the user to create a functional representation of the system under study. Next, the analyst attempts to build a structural representation of the evolving system. Using the structural representation of the system, the analyst distributes the functionality of the system over the evolving structure to create a behavioral representation of the evolving system. All three architectural views of the system are interlinked and dependent on each other.

This modularity makes system development easer to grasp, easer to share among members of a project team, and easer to communicate to users. The project team actually is creating reusable pieces that can be plugged into other systems efforts or used as starting points for other projects.

Users typically do not think in terms of data or process; instead, they see their business as a collection of logical units that contain both - so communicating in terms of objects improves the interaction between a user and an analyst or developer.