hy do we need to model software? After all, aren't the acts of coding and refactoring of that code enough? That depends on what is meant by enough! You could code up some software, hand it in, and go through a constant refactoring process with the client. This is how most software is developed today. However, times are changing. A decade ago, a game would have been developed by a single developer in the basement. Graphics were primitive and it was enough to produce a few sprites, some cute screens, and an occasional story line.

Today it takes a team of experts. Graphics gods, story tellers, and code gurus all come together to develop the newest and latest games. The bar has been raised. This is the future of software development—the developer will be joined by requirements experts, GUI masters, and software designers/architects. The teams that operate this way will raise the bar for the client, just as in the game industry. Communicating in bits, bytes, and code will be replaced by a common language, from requirements and design to coding and transition. Code will be developed from common models to meet the client's requirements and needs. This is why you need to know something about modeling software.

Modeling software requires a standard language. This is not a new concept, but until recently there were many standards from the structured diagrams of IBM, Data-Flow, IDEF0, OMT, and Yourdan, to the dozens of other modeling standards. Today one language is fast becoming the standard. The Object Management Group (OMG) has adopted the Unified Modeling Language, or UML, and it is approaching critical mass for becoming the only standard for modeling software. (See the sidebar, "A Brief History of UML")

UML for the Software Developer
While UML has 16 different diagram types for modeling, we will concern ourselves with only three. Each of the three modeling diagrams represents a different facet of software and they work together to complete a picture.

In object-orientated design and development we focus on classes, their behavior, and how they relate to reality. In UML, these three areas are represented by static diagrams, behavior diagrams, and physical diagrams respectively. In this article we will focus on class diagrams. The first part covered here will look at how classes are represented in UML and how they relate to code. The second part (which will be in the next article) will cover how the classes relate to one another.