Is modeling an important part of software design or just a waste of time?
Analysis paralysis is the term used when a team or individual has spent an inordinate amount of time analyzing a problem and an insufficient amount of time solving the problem. Analysis paralysis, by the way, is far less common than the "dive in and damn the sharks" approach to programming. However, it does happen. Chances are, you will meet someone who has had a bad experience (or who has heard horror stories about "someone elses" project) with the overly elaborate modeling, design and documentation of a project. This will lead such a programmer to eschew modeling. While they are absolutely correct in their apprehension of a design phase that has gotten out of hand, it is unnacceptable and immature for a senior programmer to hold an absolute view that denies the place of modeling and design in software engineering.
I will borrow an analogy from Grady Booch. If you are about to construct a dog house, you probably won't bother with creating a blueprint. In fact, the project may take longer and will not result in a better dog house. However, if you are about to build a house for people, generally speaking, you would be expected to have blueprints and the time required to create them would be recovered in the construction phase. The planning should also decrease materials costs, since you will be less likely to purchase materials that don't work or that you don't need. And the building is more likely to be structurally sound. In addition, you can give your customer a good idea of what he or she is buying before building has begun. Finally, when the building is completed, should a difference of opinion arise, the blueprint can serve as a document to prove that the building was built to an agreed upon plan, or that it has deviated from that plan.
However, modeling, like other software engineering activities, can be performed via a great number of methods. The good news is that formal methods and tools do exist.
The method used here will be the Unified Modeling Language (UML). Note that it is called a language as opposed to a method or process. I am not sure if this is a point of controversy in the object modeling world, but I think it should be. The UML supplies a set of symbols such as rectangles that may be used to represent a class in a class diagram or ovals to represent a state that may be used in a state diagram. So, what we have is a set of symbols that represent software modeling notions. You can model a lot of systems with these symbols and as time goes on, new elements are added to the language. The UML is currently in release 1.2 and 1.3 is supposed to be right around the corner. But is the UML really a language? Personally, I do not believe it is.
A very short history of the UML
The UML was developed by the so-called Three Amigos (Grady Booch, Ivar Jacobson, and James Rumbaugh). Previously, they had separately developed object-oriented analysis and design tools such as the Booch Method and the OMT. They fought wars over whether a class should be depicted by a cloud or a rectangle. The started companies that sold overpriced software tools for implementing their methods. They wrote books. And people like myself sat on the sidelines and waited for the dust to settle. When it did, the Object Management Group (OMG) had formed and the Three Amigos had joined forces and created the UML and the OMG said it was good. If you want the unexpurgated story, go to the OMG home page http://www.omg.com.
And now for a bit of cynicism. I absolutely believe that a modeling process is necessary. And I do not think the UML does a bad job of it. Right now, Rational Rose seems to have the edge on the UML tools front. The pricing of their products is outrageous and is out of reach for the individual home developer or for small companies on a budget. Normally, that would be just fine with me. But it seems that forces have conspired to make it appear that Rational Rose products are needed to perform UML modeling. That is not true. However, some type of tool really is required. There is a reason that architects have largely abandoned pencil and paper for CAD/CAM!
You may be able to save money by purchasing Visio. Visio is a general graphing tool that has been on the market for quite some time and last I looked, they were up to version 5. There is a standard Visio edition and a professional Visio edition. Visio supports the UML standard, but they may not be as up-to-date as the Rose product and it certainly is not as powerful as the Rose tool. But if you just want to learn and practice, it may be a good place to start.
Occassionally, however, it seems that for every Rational Rose solution, there is a Free Software Foundation solution or a Linus Torvald...
What is the Software Lifecycle?
A Complete Example of a software project using formal methods
The Teacher Project
This is a complete design and implementation of a piece of software
with the goal of solving a real world problem.
The problem: to create a user interface with database capabilities
for creating a teacher's gradebook.
To solve this problem, I am using a few tools. Mainly, I am looking
at the Unified Modeling Language (UML) to construct a model before I
begin programming. Also, I am looking at the basic software
lifecycle, which, according to the UML way of looking at things, has
four stages. Note, that other models use other ways of mapping the
lifecycle. This is just one way.
There are four stages of the software lifecycle in this model.
The four stages are:
