-1

Please explain the difference between the waterfall model and the object oriented model.

Since the books and web sites that I've seen didn't provide much information about it, I need someone to explain it to me.

2 Answers 2

14
  • Waterfall model is a software development process consisting of a sequence of phases (requirements, design, construction, testing, deployment, maintenance), followed from first to last one, without going back and without using iterations (unlike in Agile models).

    Waterfall model helps modeling project management.

  • Object-oriented model is a representation of a piece of software as a set of objects interacting between each other, with a goal to reduce the complexity of the system and enable developers to work on a specific object, while treating other objects as black boxes, with the requirement to know only their interfaces, and not their actual implementation.

    Object-oriented model helps modeling the architecture and the design of an application.

As you can see, Waterfall model and object-oriented model cannot be compared. I hope the previous paragraphs make it clear what those two models are about. If not, Wikipedia has a good article about Waterfall model (as well as the close V-model), as well as a detailed article about OOP.

5

These are completely different beasts.

The waterfall model is one of the ways to organize software development process dividing it into sequential stages known as Requirements, Design, Implementation, Verification, Maintenance. For example, your boss told you you have to develop an online shop. According to the waterfall model you first have to analyze the task inside out, gather all the possible information, may be talk to the customers, etc. in order to gain full information about the requirements of the project. Then you sit down and write a detailed technical specification of the project where you try to account for every possible detail and every possible requirement of the customer.

Then follows the planning stage where you design you software. It is this stage where you can choose an objected oriented design, functional programming, aspect-oriented design or some other model for your software and make a bunch of other important decisions about how you will structure it. If you choose an objected-oriented paradigm, you then decompose everything into basic entities (Customer, Warehouse, Transaction, etc.) modelled by objects, then you design their interfaces and data structures using UML.

And only after all this lengthy preparation to begin to actually write code (the implementation stage). At this stage you try to follow the specification prepared at the design stage as closely as possible. Only after the software process is fully written comes the verification stage (where your testers test your software to ensure that it fully conforms to the specs and then the same is done by your customer). After your customer hopefully accepts your software begins the maintenance stage where update the software and correct the bugs.

The most cited problem with this is approach is that the actual writing of code happens very late. You have to actually be done with a tonne of bureaucratic stuff before you can write even a single line of code. On the hand, imagine that your customer decides to make some significant changes while you are writing the soft. With the waterfall model that actually means that you have to stop writing the code and basically start over the whole process from the very beginning, i.e. collect the requirements, then update the specs and only then begin to changing the soft. It is because of its rigidity the waterfall model which once was the predominant model in the software development world now has been overshadowed in most fields by more flexible models.

The object oriented programming is a programming paradigm. It is a way you design your software, as I already mentioned. It is very well suited for modelling real-world situations because here everything is regarded as objects. Continuing the online shop example, you could use Customer, Transaction, Currency, Warehouse, Product, ProductCategory, Shopping Cart and a whole bunch of other objects. In your code they then would be coded as classes. Every object here has properties. For example, Shopping Cart can have number of items in the cart as its property. Also objects have methods which are ways to interact with other objects. For example, the Shopping Cart can have add (to allow Customer to add stuff to the shopping cart), remove, empty and other methods.

Not the answer you're looking for? Browse other questions tagged or ask your own question.