This column goes out to all the IT professionals ... and I think I know who you are.
You live next door to your boss, your team members, and your users. You do the work of developer, administrator, and one-off magician. You usually don't have the luxury of knowing the requirements of a project, let alone generating a formal design. You want to practice design patterns and object-oriented architecture and design, but you have a list of bugs that dates back to JCL, you're trying to work out a particularly frustrating query optimization problem, and your boss is toying with yet another project-database idea.
>
What you really need is a way to find and fix the bugs in your teammates' code, avoid putting in bugs of your own, and quickly turn around your users' requests. You may feel far away from the world of analysis and design, but that world has the answer to your problems.
The answer is modeling.
The rules
Modeling is simply the practice of creating a small system that has some of the same features of a larger system. When applied to software, the word modeling usually conjures up images of wall-sized UML diagrams. Internal software, however, changes so quickly that such diagrams are usually out of date by the time they are printed. Fortunately, such large-scale and often unwieldy methods are not the only kind available for modeling software.
A software model does not have to start from scratch. It does not have to permeate the entire system. And, most importantly, it does not have to be set in stone before implementation begins. The only thing that a software model needs is a set of rules. I'm going to go out on a limb here with a generalization, but so far it appears to be true: The same four rules apply to all software models.
The four rules of software modeling are:
- Ownership
- Dependency
- Interface
- Identity
Unlike the rules of object-oriented design, these four apply to legacy systems as well as to new projects. Think back to the last serious bug that you fixed. You can probably identify a violation of one of these rules as the cause.
Briefly, ownership means that every object has exactly one owner (the object responsible for its creation and destruction), and that ownership is not transferable. Dependency means that any bit of data used to evaluate a dependent quantity is a precedent, and that dependents must be up to date whenever referenced. Interface means that every object implements some set of interfaces, and that these interfaces allow objects to be interchanged. Identity means that all objects have unique identity, that an interface inherently identifies an object, and that all clients accessing an identical object can expect uniform behavior.
Can you spot the bug?
The goal of this column is to explore the rules of software modeling and to demonstrate their application in day-to-day tasks. For the first few weeks, we will examine some common bugs to find their core modeling violation.
Take, for example, a financial ledger displayed in a list-view control. The ledger is an in-memory list of transaction objects. The ledger maintains a balance, and each transaction contains an amount. The pointer to each transaction is stored in the data area of the corresponding list item. When the user selects an item and presses the Delete key, the item subtracts the transaction amount from the ledger balance, deletes the transaction, and then removes itself from the list. When the user presses the F5 key, the list view removes all items, iterates through all transactions of the ledger, and adds a new item for each.
 |
|
Figure 1. Object diagram of a buggy financial ledger application. |
Can you spot the bug? Can you fix it? Next week, we will examine this bug to determine which of the four rules it violates. When you work from the mindset of software modeling, you will be able to quickly spot bugs and avoid writing them.
