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.
|
|
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 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.
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.