A picture is worth a thousand words

Understanding a software design proposal is so much easier once you can actually visualize it. While writing diagrams might take you an extra effort, the small time investment will pay off when others will require less time to understand your proposal.

Software is a means, not a goal

We are writing software to support other people business requirements. Understanding business goals are the first step towards coming up with an effective design proposal. After gathering input from your product owner, you should write down the business story. Writing it makes you reason more about the business goal and the product owner can validate your comprehension.

After the business goals are clear you need to move to technical challenges. A software design proposal is derived from both business and technical requirements. The quality of service may pose certain challenges that are better addressed by a specific design pattern or software architecture.

The class diagram drawing hassle

My ideal diagram drawing tool will simply transpose my hand-drawing sketches to a digital format. Unfortunately, I haven’t yet found such tool, so this is how I do it:

1. I hand draw all concepts and interactions on a piece of paper. That’s the most rapid way of design prototyping. While I could use a UML drawing tool, I prefer the paper-and-pencil approach, because changes require much less effort
2. Once I settle for a design proposal, I start writing down the interfaces and request/response objects in plain Java classes. Changing the classes is pretty easy, thanks to IntelliJ IDEA refactoring tools.
3. When all Java classes are ready, I simply delegate the class diagram drawing to IntelliJ IDEA

In the end, this is what you end up with:

Insert details about how the information is going to be processed

DOWNLOAD NOW