OOAD: The most important *underdog*
During my time at an engineering college, I had a lot of subjects to read and study. Not being a fan of my college’s syllabus structure, I can safely say, I survived… well pretty gracefully the 3 years of intense Computer science; considering the very first year as an attempt by the existing education system to help the student ease into the college level from a school level studies! Required!.
Lot of subjects that build up the foundation of the Computer Science, a basic programming course, subjects on organizing data, defining an informal process design, the working of Integrated Circuits that fire up the industry, principle design, interaction between the human and the machine, global interconnectivity and sharing of data, specific technologies in interconnected networks, technologies that might define the future computing, and a lot more. I have tried to explain the subjects without taking the actual name. Full marks to write the actual subject names!. It’s easy.
These subjects were fun to learn, and I enjoyed it a lot – (^ survived gracefully – you get the idea why!). But there was this subject, somewhere midway. By the prevailing notion of the folks around me then, it goes this way – “It is a damn easy subject, Makes the right boxes – scores the marks”. Well, it was pretty easy. But the subject was not the one people technically cared for. I guess, it remained a set of boxes for a lot of people; I guess I am included.
The reason I say, I am included is pretty genuine. Recalling a certain interview with a company, I was asked – “What, in your opinion were the most important subjects in your engineering courseware?”. The interviewer was cheekily looking for a smart answer. I remember blurting out – four subjects. One to do with the software development, one to do with organising data and efficient running processes on the data, an introductory programming course, and a tech of the future that I like. What I missed, in my opinion, was the same subject I talked about in the last para. A thing, I mostly use for my projects but call it bad luck, it didn’t strike my mind.
For folks who know me, I do a lot of self-analysis. Not always but occasionally. Sitting just prior to writing this, well ahead of my post self-analysis on the questions, the interviewer had asked me, I was completely struck by the simplicity yet the intensity of this particular question.
Object-oriented Analysis and Design
Appending this to the answer I gave, it would have been perfect and more convincing-assuming the work that the company was doing is strictly around these principles – something that is common. OOAD, as it is called in some academics, is one of the most important fundamental courseware – like a building block. The subject details a follow-up to an important computer science paradigm -OO- or Object Oriented paradigm. A way to see everything as objects with some sort of state, behaviour and individual attributes. As Grady Booch, a renowned computer scientist dealing with Unified Modelling Language; or the boxes; said,
“Object Oriented Analysis is a method of analysis that examines the requirement from the perspective of the class and objects in the vocabulary of the problem definition”
He further states about Object Oriented Design that,
“It is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design”
Combining both to one simple definition, Object-oriented analysis and design (OOAD) would be a popular technical approach for analysing, designing an application, system, or business by applying the object-oriented paradigm and visual modelling throughout the development life cycles to foster better stakeholder communication and product quality.
It is the core to the efficient Software development model, the Unified Process and modelling language and also to the Object Oriented System that most of the modern software development is based on. It presents a blueprint to the ace developers to have a clear idea of how to deal with Objects and Classes – the atomic units to their problem statement, and their relationships with each other and the overall system. Well, It doesn’t end just there.
I am forced to call it an underdog, primary reason being the way most of us ignore its importance. For a singular project, skipping these techniques might sometimes bail us out, but not on a nonsingular-team based project, ignoring these techniques might well be seen in abundance of poor code implementations of the problem, showing a disconnect between the existing relationship with the atomic units and overall system. That’s bad Strategy!. Not only there is a disconnect with the atomic units, there is a physical disconnect with the shareholders of the problem – the designer, the programmer, the tester and so on. All in all, using them in our solutions will only give way to better and easier software development practices aimed at a long-term, far-sighted sustainable development.
That’s the beauty of it. Well, it is high time to start them in our solution building process and for better software development experiences.
That’s the end. Follow to see more. Total noob in writing blogs. Educate others. Have a great stay on the Internet.