Model Your Design Before You Begin Coding
Nick Poulakis MCSD

I recently began work on version 2 of an application that I had developed for a client about a year ago. The client had distributed the application to its customers and received feedback for enhancements and new functionality missing from Version 1. Version 1 was coded in a very VB 6 way, lots of .Bas modules, many public functions, and a rather large public declarations module for shared variables within the application. We were under a very strict delivery schedule and the initial requested functionality was not very complex. However as often happens, after development began, additional features were added to the application without the luxury of additional time to stop development and design a good model for this “simple” application that was rapidly becoming quite complex. I was never happy with this (lack of design) so I saw this as a good opportunity to put to use my modeling skills and try to Object Orient this project (as much as possible in VB 6). Initially, the client balked at the time table I had laid out to model the application (7 – 10 days), but there were several key points that were brought up in our discussions for version 2 that made it very clear that a well laid out design with defined objects was indeed very important for this project to succeed.

Complete backwards compatibility was vital. We did not want existing users of the application to loose any access to existing data.
Extensibility for future versions needs to be built in.
The ability to be able to toggle back and forth between the old data structures and the new data structures was vital!

The current version did not allow for any of this functionality so we needed to show our client that the added upfront time for modeling and object definition would be worth the cost. We began by looking at the current structure and documented what was wrong with it (and what was right with it). We then went through the Verb and Noun process of discovering what was an object and what that object could do. This helped in defining what object methods and object properties are. By taking the time to do this upfront (approximately 8 days) before diving in to writing the actual code, we were able to clearly see object hierarchies, what object was the parent to another object, thus allowing us to correctly define where all of our public methods belonged. Now each object was the owner of the methods and properties that were directly related to that object. By doing this we basically removed all of our global variables and assigned them as properties to the owning objects and removed all of our public methods and assigned them to their owning objects. This process made the code easier to maintain and infinitely easier to step through and debug. This object model communicated to the client our understanding of the system requirements that they presented to us. Having the client give us the “OK” at the analysis stage saved many hours and many dollars down the road. The client was very pleased with this process, as it added a level of clarity and involvement on their end that was missing in the development of Version 1. The client was kept informed at every step of the way during this process and their input on design issues was encouraged.

After completing the object model we moved on to Use Case Scenarios to define expectations of what actually occurs during system use and what is the expectation of the desired outcome to the user. Here is where we separated the “Functional Requirements” from the “Technical Requirements”. Functional requirements have more to do with how the system performs from the users’ perspective, goals of the usage, look and feel of the application and ease of use. Technical requirements have more to do with how a system is built internally in order to meet the functional requirements that have been defined.

From here we moved on to modeling Sequence Diagrams to determine method calls and data flow within the application. We used UML to visually display this to the client and to the developers that were to work on the project. This portrays a drawing of process interaction between objects in the application that allowed us to catch missing functionality and functionality that had been needlessly duplicated.

By taking the time to properly model and diagram objects and process flows upfront and not just dive in and start coding we have created a solid object model that meets all of the defined requirements that our client has presented to us, and created a highly extensible application that will easily move forward to version 3 or 4. I know that it’s always temping to jump right in and start coding, but try to discipline yourself to always model out the design of your application prior to coding. I guarantee that you will reap the rewards of doing so down the road when the actual coding starts. Coding the actual objects is much easier when there are clear definitions of what each object consists of and what each object actually does and does not do. The added upfront time is more than made up for on the backend of the development timetable. We estimated 10 full weeks of development for version 2 and at six weeks we had already implemented 85% of the new functionality. We gained a 20-25% savings in development time, due to the time we spent up front!