Sunday, May 2, 2010

Modeling Existing Systems

Modeling software is an expensive activity. Building software models can be expensive for a multitude of reasons. The most obvious being the time lost for unsuccessful designs. Software models take time to put together. Unless you are sketching, the goal being to not spend a lot of time on them. Contrast this with a failed initial software implementation with no up-front modeling. There is a high probability of reusable software components that may be salvaged from the failure. Developers tend to become fixated on functional software. If something that at least somewhat functional comes out of a disaster, it will still help with morale.

So, if detailed modeling has no place in up-front software development, does it have any place in software development? Creating a detailed model of an existing software system may prove valuable. The key to modeling existing software systems is to pin-point exactly where the design has gone wrong. This is nearly impossible to spot during initial development. Especially under time constraints when the priority of design takes a back seat in favor of a functional system.

The obvious drawback to up-front modeling in software development is that promotes a waterfall approach. The waterfall approach doesn't work as well as an iterative and incremental approach, if at all. This doesn't mean you shouldn't be spending any time modeling, it means any up-front models created should be treated as informal at best. Perhaps it makes more sense to not even call them models because that suggests a level of formality we want to stay away from initially. Simple diagrams treated as sketches are a good practice to follow early on.

Formal models of software systems created after the system in question has been deployed in a real environment can prove valuable. The reason for this being that you have a functional system that is relatively stable. This is because after a system has been deployed for a while, hundreds if not thousands, of smaller bugs have been eliminated. These are the types of bugs that a software model isn't likely to solve in a timely manor. With the smaller issues mostly removed, we are free to tackle larger design issues that aren't easily solved with code.

One of the first things you might want to model are the dependencies between the packages and modules that make up the system. I've tried this before and was amazed at the problems I was able to see before even trying to model inheritance between classes. When you have several dependency lines crossing one another, it just looks bad. This is often a reflection of a sub-optimal design. The poorly painted picture provides quite the motivation to fix these issues. The same goes for class hierarchies. The relationships among the elements in the system, not just inheritance, are worth modeling. The value of modeling the details of each element isn't as high. Encapsulation also applies to software models to a certain degree.