Unified Modeling Language (UML) is standard for modeling real-world objects in developing an object-oriented design methodology. It's notation is derived from and combines three methods of object-oriented design and analysis methodologies:

UML tries to specify: class (of objects), object, association, responsibility, activity, interface, use case, package, sequence, collaboration, and state.

thanks to:
http://www.whatis.com
Because Rational Software led the development of UML, and because it's quite good, Rational Rose is the most commonly used UML modeling tool. It integrates with most development languages, so that you can create your UML model and produce skeleton code automatically (eg java classes).
One of the justifications for UML is that (since it's a standard) you can switch between different UML tools without having to relearn the software or diagrams. This has led to many other vendors providing UML tools, some for free (yay). iLogix put out one (for which the basic version is free) called Rhapsody. I've just tried it and it seems useable, but probably will be better in a couple of versions. Rational Rose can be a bit expensive so it's nice to have a free option.
I'm sure lots of other vendors have tools too, eg Sybase ObjectArchitect, etc, etc.

UML is a language used to aid the process of software development. When first learning it, much of it will seem silly and some of it will seem bizarre. After seeing it succesfully used, its usefulness will come into focus.

It is not a language in the sense that most programmers will probably think. It can not be used to write a program. It is not compiled, it does not actually *DO* anything. It is more a standardized set of symbols and diagram types used to visualize a software system.

UML has shown tremendous acceptance in the development community and UML interfaces have become an incorporated part of such model-build-deploy products as TogetherSoft and Rational Rose.

The strongest aspect of UML is its incorporation of views. In the development of a software system, there is a confusing issue of perspective. One system will be designed by one group, written by another, used by another, deployed by another, marketed by another and so on. All of these groups of people will have differing perspectives. To cope with this issue, UML takes into account 5 types of perspective, or view, pertaining to any given piece of software. Any UML diagram will fall into one of these 5 categories.

User View

This is the highest-level and simplest of the views. This view represents how the user will view the software. These diagrams should be very simple. If your user view is complicated, forget about it.

The user view is composed of one type of diagram:

  • Use Case Diagrams: A use case will show the over-all functionality of software. "Manager checks employee work schedules" could be a verbalization of a use case diagram for one piece of software. It ignores how the software goes about performing its task and focuses on what is being performed.

Structural View

(aka Structural Model View): This view should be thought of from the pespective of a system architect. It represents the classes, objects, and their associations. This view does not display how the classes and objects actually behave, only their relationships.

The structural view is composed of two diagram types.

  • Class Diagrams: These diagrams express the classes that compose a system. They show the components of the software and how those components relate to one another. These diagrams are heavily used in design.
  • Object Diagrams: An object diagram shows instances of classes. Usually your object diagrams will be specific instances of your class diagrams. These diagrams are useful in checking a design for flaws.

Behavioral view

(aka Behavioral Model View, Dynamic View, Process View, Concurrent View, Collaborative View): This view is the largest and most complex. It represents the actual behavior of the software. It contains diagrams representing the inner-workings of the classes and their behaviors in respect to one another. This view is most useful to the people who actually write the code for the software.

The behavioral view is composed of 4 diagram types.

Implementation View

(aka Component View, Development View): This view demonstrates the organization and dependencies of the actual system and its pieces. This view has only one type of diagram.

  • Component Diagram: A component diagram shows the organization and dependencies of a systems actual parts. Executable files are mapped to their objects, objects mapped to source files, etc. This diagram is useful for source management and any task in which an understanding of the actual file-layout of the system is meaningful.

Environment View

This view represents the environment in which the software will exist when finished. This view has one diagram type.

These five views are the core of understanding the basics of UML. However, there is much more to the language. Each diagram type has its own set of symbols and conventions, and each view can easily be conufused and misinterpreted if not looked at from the proper perspective. In any system of development, management of the UML charts can be a full-time job.

It is also important that not all software designs will implement all of the views and diagrams. Some instances can use only one diagram, while others will require all of them. It is recommended to seek the advice of a professional if considering the implementation of UML for important software.


More thorough discussion found in: UML in a Nutshell by Sinan Si Alhir published by your good friends at O'Reilly.

Log in or register to write something here or to contact authors.