Object-Oriented Analysis and Design (Part 4)
Object-Oriented Analysis and Design (Part 4)
In the final part of our four part series, we look at some myths surrounding object-oriented design, and how to convince management that it's worthwhile.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
This is the last article in four part series. Here I will discuss some non-technical issues that I faced in my object-oriented design and programming journey. If you're new to the series, feel free to check out Part 1, Part 2, and Part 3!
Why Your Last Design Attempt Failed
Many developers have attempted to design a software project properly but have failed or could not continue. Therefore, I have put together a list of problems or misconceptions about object-oriented analysis and design and how to tackle them.
If You Could Just Learn How to Design Perfectly
Perfect design at the start of the project is a myth. Your design will evolve, change, be corrected and modified over time. Many people think that they have to design perfectly at the beginning and then consider that design document as a sacred scripture. The truth is no one can come up with a perfect design at the start.
Software design is a heuristic process. It's something that you update over the lifetime of your project. There is no formula that you can use to produce best object-oriented design every time. It involves trials and painful errors from which you can learn and then apply what you've learned to your future projects.
You Have to Do Complete Analysis and Design Before Coding
Many developers and students believe that analyzing all requirements and all designing should be done before coding starts and during construction, one cannot change or extend it.
This is not true. If during coding, a team or developer realizes that the design can be extended or reduced, then it should be.
Similarly, when working in iterative development, usually 10 percent of all the requirements are tackled during one iteration. Therefore, you have to design for only 10 percent of all the requirements or user stories. If you have 10 user stories, then tackle the most important story (as indicated by the customer) in the first iteration and design for that only.
You Have to Give Enough Time to Design
When I started to become seriously interested in object-oriented design, I was spending weeks on design, thinking about how to come up with a perfect and complete design. But during coding, things did not work out as they were supposed to and I was disappointed.
The rule of thumb is that you should not give more than one day for a three-week iteration. I only give 2 to 4 hours to design before jumping to code. This does not mean you cannot go back to designing for a couple of hours during construction. You can meet with your teammates and discuss design decisions during construction as well.
You Believe UML (Unified Modeling Language) is Everything
If someone told you that UML modeling is everything and recommends some expensive CASE (Computer-Aided Software Engineering) tool, then you should come and look at my journal. Most of my designs never get to the CASE tool that our company has. When designing in teams, we use whiteboards and take a picture of them and then post these pictures in the project directory.
I believe design is not something that you draw using beautiful boxes of colors and properly align them. A rough diagram on paper is as effective as a diagram drawn using a CASE tool. OOAD is about getting a big picture and communicating this with your peers and with yourself when you are writing the code.
UML is just a tool that you can use to translate your design ideas and which can be shared with other developers. Simply learning UML will not make you a good designer.
You Have to Apply All the Patterns and Principles
If you know about all the object-oriented design principles and patterns, then you might have realized that you want to apply all of these principles and patterns before moving to construction. If you do this, then you will not be successful. Use the principles and patterns according to the situation or problem at hand and you will be able to design a good piece of software.
I suggest that you develop your own priority list of patterns and principles that you fully understand. Then, apply these patterns according to the problem that is in front of you.
You Don’t Know How to Handle Your Boss / Manager
It is possible that your boss may resist while you come up with the idea of object-oriented analysis and design. In your boss's eyes, it looks like an additional task which will not add any lines of code to your software. Also, it is also possible that your boss is not from a programming background and will not realize the importance of OOAD.
There are two kinds of bosses:
- Quality driven.
- Schedule driven.
Identify what influences your boss or manager. If your boss is quality driven, then you can show him the benefits of an object-oriented analysis and design and how it help him achieve the better quality features like modularity, readability, and reliability.
If your boss is schedule driven, then the first thing that you can do is show him that analysis and design activities will not take much time (only 2-8 hours in a 3 weeks iteration). You can also show them how other time-saving benefits, such as a good design, can save time later in the project, like when you have to update or change some features of a piece of code.
Write what you like about the post in the comments section. You can visit www.objectorienteddesign.org for a small report that discussed applying object-oriented principles to real life examples.
Published at DZone with permission of Muhammad Umair . See the original article here.
Opinions expressed by DZone contributors are their own.