In software engineering, Unified Modeling Language (UML) is a non-proprietary, third generation modeling and specification language. However, the use of UML is not restricted to model software. It can be used for modeling hardware (engineering systems) and is commonly used for business process modeling, organizational structure, and systems engineering modeling. The UML is an open method used to specify, visualize, construct, and document the artifacts of an object-oriented software-intensive system under development. The UML represents a compilation of best engineering practices which have proven to be successful in modeling large, complex systems, especially at the architectural level.

This diagram describes the functionality of the (simple) Restaurant System. The Food Critic actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef Actor can Cook Food. Use Cases are represented by ovals and the Actors are represented by stick figures. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modelled, the actors are not.
The OMG defines a graphical notation for use cases, but it refrains from defining any written format for describing use cases in detail. Many people thus suffer under the misapprehension that a use case is its graphical notation; when in fact, the true value of a use case is the written description of scenarios regarding a business task.

This diagram describes the structure of a simple Restaurant System. UML shows Inheritance relationships with a triangle; and containers with diamond shape. Additionally, the role of the relationship may be specified as well as the cardinality. The Restaurant System has any number of Food dishes(*), with one Kitchen(1), a Dining Area(contains), and any number of staff(*). All of these objects are associated to one Restaurant.

http://upload.wikimedia.org/wikipedia/en/2/20/Restaurant-UML-SEQ.gif
This diagram describes the sequences of messages of the (simple) Restaurant System. This diagram represents a Patron ordering food and wine; drinking wine then eating the food; finally paying for the food. The dotted lines extending downwards indicate the timeline. The arrows represent messages (stimuli) from an actor or object to other objects. For example, the Patron sends message 'pay' to the Cashier. Half arrows indicate asynchronous method calls.

Above is the collaboration diagram of the (simple) Restaurant System. Notice how you can follow the process from object to object, according to the outline below:
*1. Order Food
*1.1 Order Food
*2. Serve Wine
*3 Pickup
*3.1 Serve Food
*4 Pay
A Collaboration diagram models the interactions between objects in terms of sequenced messages. Collaboration diagrams represent a combination of information taken from Diagram|Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
Collaboration and sequence diagrams describe similiar information, and as typically implemented, can be transformed into one another without difficulty.
However, collaboration diagrams use the free-form arrangement of objects and links as used in Object diagrams. In order to maintain the ordering of messages in such a free-form diagram, messages are labeled with a chronological number and placed near the link the message is sent over. Reading a Collaboration diagram involves starting at message 1.0, and following the messages from object to object.
In UML 2.0, the Collaboration diagram has been simplified and renamed the Communication diagram.

See http://en.wikipedia.org/wiki/State_diagram#Harel_statechart.

Activity diagrams represent the business and operational workflows of a system. An Activity diagram is a variation of the state diagram where the "states" represent operations, and the transitions represent the activities that happen when the operation is complete.
This activity diagram shows the actions that take place when completing a (web) form.
The user starts by filling out the form, then it is checked; the result of the check determines if the form has to be filled out again or if the activity is completed.

Deployment diagrams serve to model the hardware used in system implementations and the associations between those components. The elements used in deployment diagrams are nodes (shown as a cube), components (shown as a rectangular box, with two rectangles protruding from the left side) and associations.
This deployment diagram shows the hardware used in a small office network. The application server (node) is connected to the database server (node) and the database client (component) is installed on the application server. The workstation is connected (association) to the application server and to a printer.

Although UML is a widely recognized and used standard, it is criticized for having imprecise semantics, which causes its interpretation to be subjective and therefore difficult for the formal test phase. This means that when using UML, users should provide some form of explanation of their models.
Another problem is that UML doesn't apply well to distributed systems. In such systems, factors such as serialization, message passing and persistence are of great importance. UML lacks the ability to specify such things. For example, it is not possible to specify using UML that an object "lives" in a server process and that it is shared among various instances of a running process.
At the same time, UML is often considered to have become too bloated, and fine-grained in many aspects. Details which are best captured in source code are attempted to be captured using UML notation. The 80-20 rule can be safely applied to UML: a small part of UML is adequate for most of the modeling needs, while many aspects of UML cater to some specialized or esoteric usages.
(However, the comprehensive scope of UML 2.0 is appropriate for model-driven architecture.)
A third problem which leads to criticism and dissatisfaction is the large-scale adoption of UML by people without the required skills, often when management forces UML upon them.

UML서적관련추천 - 1002 형의 OP 게시판 펌

http://www.codeproject.com/cpp/oopuml.asp - UML 강좌
http://blog.empas.com/huikyun/ - UML에 대해서 잘 정리된 블로그
http://www.sparxsystems.com.au/resources/uml2_tutorial/ - 좋은 UML 튜토리얼

난 이게 무언지 잘 모르겠다. 다만 객체를 잘 표현할 수 있는 방법이다. - 이승한
----
프로그래밍분류