Why Should I Model My Applications?

You might be surprised that our first response to the question, “Why should I model my applications?” is that there are times when modeling applications is probably overkill. For instance, if the application is trivial, or if your development tools are powerful enough that you can “assemble” most of your application, or if your developers have developed similar applications and already know exactly how to implement the solution, modeling your application might be unnecessary.

However, for those of you who are building serious, business-critical applications, application modeling is necessary. In Chapter 2, “Business Models,” we discussed some reasons for modeling your business, and many of those reasons apply to modeling applications. First, understanding what you already have is key, as most development efforts are not “greenfield” projects. Usually, some existing systems and software are in place that your team might not be familiar with and that needs to be interfaced to or modified. It's easier to understand existing applications through viewing a model than through tediously reading their code.

From the Real World—Tag! You're It (Again)! We discussed a situation in Chapter 2 in which I inherited a critical application that had no documentation, that was missing some of the code and data files, and that no one understood (a situation in which many developers have found themselves). You might recall it took weeks to understand the application and longer to truly comprehend the underlying concepts and get the application up and running again. Also, additional time was lost and additional cost incurred when dealing with new users who did not understand how or why the application operated as it did. If there had been a model of this application, most of these problems and their corresponding costs would have been avoided. But let us continue with the rest of the story. After a series of “renovations” of this application, it was in very good shape, everything was operational, and all the pieces were accounted for and were under version control. There was even a preliminary set of documentation. Everything was on track. However, there was no model of this application (my organization did not do application modeling). There were a few minor, non-critical defects that needed to be ferreted out, but they didn't impede operation and wouldn't prohibit delivery. What a great time to take some vacation. So I did. I came back refreshed and ready to continue with the renovation of this application. As I worked, I noted some odd behaviors that I had not seen before. The application still operated well enough, but it was doing things that it should not have been doing, such as sending duplicate messages to the operator. Were these intentional (resulting from some distant corner of the application I hadn't examined) or were they a defect? The application certainly hadn't been behaving like this before I left. After a few days of digging through the code, I found that the code was different. A few subtle changes had been made. More investigation revealed that one of the new users had raised a concern about the application's operation to my manager. For some reason, the boss decided to “fix” the code without telling anyone. Yes, he did change the application's behavior to satisfy this one user. In the process, he introduced a handful of new, real defects. He might have been able to make a correct change if we had a model of the software, but like many programmers who inherit software, he did not have a model. He did a quick assessment of the code and made the changes, “fixing” the “problem” without understanding the side effects (defects) he was causing.

Lessons Learned Models of your applications, especially the more intricate or critical applications, require time to create, but they can save much more time when changes need to be made to your software. When you go on vacation, lock up your code. Configuration management is critical for successful development.

Another reason you should model your applications is because when you are designing new applications, changes often occur during your design phase. Having a model makes it much easier to assess the impact of changes that might be made because you can see the parts of the application that will be impacted. As indicated in the sidebar “From the Real World—Tag! You're It (Again)!,” when code needs to be changed, the design models can be examined to see if the proposed changes might break the application elsewhere.

A visual model of your application also makes it much easier for you to determine whether your design is meeting the needs of the business. You can literally point to the element that is satisfying a requirement instead of pointing to a stack of textual specifications.

Lastly, as we said earlier, a model provides a “point-of-focus” to enable your stakeholders to discuss and resolve design issues. As the former United States President Dwight Eisenhower said, “Plans are nothing; planning is everything.” It's not just the models themselves; it's the process and thinking that you must go through to create the models that provide tremendous value. Modeling forces you to think, and by thinking it through, you will create better designs.

Our Second Response

Our second response to those who ask why they should model their applications is quite simple: You already model anyway. You just don't call it modeling.

Remember the definitions of a model in Chapter 1, “Introduction to the UML ”—a model is a representation of something not yet built. Walk around the cubicles in most software development departments and look at the whiteboards. You will find all manner of models scrawled upon them: block diagrams that model the structure of programs and their subroutines, flowcharts modeling the control flow of programs, long partitioned rectangles modeling record structures, a network of interconnected squares modeling the linkages on a web site, and yes, even some UML diagrams. These are all examples of modeling. Modeling is simply a technique used as part of the analysis and design of software and systems, and many of you are already doing it, just not in a formalized way. UML merely brings a formal approach, symbology, and meaning to your modeling activities.

Behind the Question

Often, there are really other questions (or fears) behind the “why model applications” question. Most people who ask why they should model applications already understand why they should. What they are really asking is related to other factors. Managers, for instance, often ask this question because they are really concerned about the time it takes to model. They do not realize that the reason coding takes up the majority of effort in a development project can often be attributed to incomplete design. The job of resolving the design details is passed down the line and left to the programmers to perform while they are writing code. Management does not see this “hidden design” because it is embedded within the coding efforts. As we said earlier, you really are doing modeling (i.e., design); you just call it something else.

Other managers only measure progress by counting how many lines of code have been written. These people usually come from the “Ready-Set-Code!” school of software development. This is an unfortunate (and prevalent) mentality in our industry. If this describes you, you also need to think about the larger issues: meeting the business's needs, producing a resilient design, creating a high-quality product, and the various other benefits of modeling cited in this and earlier chapters.

Cost is also behind the question of whether to model. The cost is not really in the modeling itself (as discussed earlier in this chapter, you will do this work eventually, whether formally modeling or not). The real cost is the up front investment in skilled people or in training your existing staff to learn to model properly. However, this “one time” cost is recovered in every subsequent project you do, primarily through reduced rework and defect removal costs (recall the chart in Figure 3-1). The focus should be on creating an application that works as intended (otherwise, if it does not do what your customer wants, all your time and money has been wasted) and the total lifecycle cost of the application. Anyway, as a manager, isn't staff development part of your job?

Similarly, if you are a programmer asking this question, and none of the previous discussion moves you, we would ask why you wouldn't want to learn a new skill? After all, a programmer's employability rests on his skills. Also, do you really want to be just a coder? Or do you want to earn that “software engineer” title? Are you satisfied with hammering nails? Or do you want to be the architect of that cathedral? UML isn't going away. You should add it to your skill set.