Introducciòn a uml

Introduction to the Unified Modeling Language
Terry Quatrani, UML Evangelist
If you’re a complete UML beginner, then consider this as UML 101, a basic introduction to the notational elements of the UML. This article was first published on the Rational Developer Network after presentation at the RUC 2001.

Before joining Rational, in 1993, I worked for another well-known technology company,only there I was using OMT (the methodology developed by Jim Rumbaugh and company). Then I became a Technical Representative at Rational, and went from using OMT and rectangles, to using the Booch methodology and clouds. Back then, Rational only had 300 employees, and the UML was just a glimmer in the eyes of those who would go on to be known as “the Three Amigos.” So I guess I date myself a bit bysaying that I was doing OO development before UML came along, but that admission does give me a certain amount of credibility to talk to you about UML, don’t you think?

The Importance of Modeling
When my son was 13, my husband and I thought he should have some space of his own. So we called in Leon the handyman and sat around the kitchen table. “What do you want?” he asked. Simple…a fewclosets, some electrical outlets, a cable hookup. Leon went off and remodeled the basement, and life was good. That is until winter came along and poor Michael comes upstairs and says, “Mom, I’m cold.” You see, we hadn’t thought about putting heat in the basement. So we decided to put in a gas fireplace. However, we don’t have natural gas where I live, so we had to get a propane tank. Unfortunately, theonly place it would fit was over in one corner, with all the storage in the other corner, and everything else in a third corner. The result is that you can’t sit in my basement and see the TV and the fireplace at the same time. If we’d done some planning, we would have been able to design a room that was much more functional and comfortable. Now in this instance we made some mistakes, but itwasn’t a serious disaster. Think about building a skyscraper, though. No one would dream of a major construction project without thorough blueprints. That’s blueprints plural, because it’s important to not only have one plan of the skyscraper – you need to have multiple plans. The electrician needs a view to show where the wiring goes. The plumber needs another plan so he doesn’t put a sink in theelevator. And the carpenters need to know where to put this expensive crown molding in the CEO’s office. Different workers need different views of what they’re trying to build. And that’s what we’re doing with software. That different view is what we mean when we talk about the logical view, the use case view, the component view, and the deployment view – all the different views of the applicationunder construction. So whose view should you model? Well, everybody involved in the project lifecycle is going to do some sort of modeling; they just might be doing different things. The business modeler will model different requirements than the application modeler will, but they are all creating a view that is important to their world of the application. And the language they use to do this is theUnified Modeling Language.

What is UML?

The easiest answer to that question is a quote: “The UML is the standard language for specifying, visualizing, constructing, and documenting all the artifacts of a software system.” The more complex answer requires a short history lesson, because the UML is really a synthesis of several notations by Grady Booch, Jim Rumbaugh, Ivar Jacobson and manyothers.

Figure 1: How it all began Back in the late 80s, when I started modeling, there were many different methodologies. And each methodology had its own notations. The problem was that if different people were using different notations, somewhere along the line somebody had to do a translation. A lot of times, one symbol meant one thing in one notation, and something totally different in...