英文文献：
Unified Modeling Language
Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering. The standard is managed, and was created by, the Object Management Group.
UML includes a set of graphic notation techniques to create visual models of software-intensive systems.
Overview
The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software intensive system under development. UML offers a standard way to visualize a system's architectural blueprints, including elements such as:
• actors
• business processes
• (logical) components
• activities
• programming language statements
• database schemas, and
• reusable software components.
UML combines techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies. UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language. UML aims to be a standard modeling language which can model concurrent and distributed systems. UML is a de facto industry standard, and is evolving under the auspices of the Object Management Group (OMG). OMG initially called for information on object-oriented methodologies that might create a rigorous software modeling language. Many industry leaders have responded in earnest to help create the UML standard.
UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG. UML is extensible, offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles have been improved with the UML 2.0 major revision.
History
Before UML 1.x
After Rational Software Corporation hired James Rumbaugh from General Electric in 1994, the company became the source for the two most popular object-oriented modeling approaches of the day: Rumbaugh's Object-modeling technique (OMT), which was better for object-oriented analysis (OOA), and Grady Booch's Booch method, which was better for object-oriented design (OOD). They were soon assisted in their efforts by Ivar Jacobson, the creator of the object-oriented software engineering (OOSE) method. Jacobson joined Rational in 1995, after his company, Objectory AB, was acquired by Rational. The three methodologists were collectively referred to as the Three Amigos, since they were well known to argue frequently with each other regarding methodological practices.
In 1996 Rational concluded that the abundance of modeling languages was slowing the adoption of object technology, so repositioning the work on a unified method, they tasked the Three Amigos with the development of a non-proprietary Unified Modeling Language. Representatives of competing object technology companies were consulted during OOPSLA '96; they chose boxes for representing classes over Grady Booch's Booch method's notation that used cloud symbols.
Under the technical leadership of the Three Amigos, an international consortium called the UML Partners was organized in 1996 to complete the Unified Modeling Language (UML) specification, and propose it as a response to the OMG RFP. The UML Partners' UML 1.0 specification draft was proposed to the OMG in January 1997. During the same month the UML Partners formed a Semantics Task Force, chaired by Cris Kobryn and administered by Ed Eykholt, to finalize the semantics of the specification and integrate it with other standardization efforts. The result of this work, UML 1.1, was submitted to the OMG in August 1997 and adopted by the OMG in November 1997.
UML 1.x
As a modeling notation, the influence of the OMT notation dominates (e. g., using rectangles for classes and objects). Though the Booch "cloud" notation was dropped, the Booch capability to specify lower-level design detail was embraced. The use case notation from Objectory and the component notation from Booch were integrated with the rest of the notation, but the semantic integration was relatively weak in UML 1.1, and was not really fixed until the UML 2.0 major revision.
Concepts from many other OO methods were also loosely integrated with UML with the intent that UML would support all OO methods. Many others also contributed, with their approaches flavouring the many models of the day, including: Tony Wasserman and Peter Pircher with the "Object-Oriented Structured Design (OOSD)" notation (not a method), Ray Buhr's "Systems Design with Ada", Archie Bowen's use case and timing analysis, Paul Ward's data analysis and David Harel's "Statecharts"; as the group tried to ensure broad coverage in the real-time systems domain. As a result, UML is useful in a variety of engineering problems, from single process, single user applications to concurrent, distributed systems, making UML rich but also large.
The Unified Modeling Language is an international standard:
ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2
Development toward UML 2.0
UML has matured significantly since UML 1.1. Several minor revisions (UML 1.3, 1.4, and 1.5) fixed shortcomings and bugs with the first version of UML, followed by the UML 2.0 major revision that was adopted by the OMG in 2005.
There are four parts to the UML 2.x specification:
1. the Superstructure that defines the notation and semantics for diagrams and their model elements;
2. the Infrastructure that defines the core metamodel on which the Superstructure is based;
3. the Object Constraint Language (OCL) for defining rules for model elements;
4. and the UML Diagram Interchange that defines how UML 2 diagram layouts are exchanged.
The current versions of these standards follow: UML Superstructure version 2.2, UML Infrastructure version 2.2, OCL version 2.0, and UML Diagram Interchange version 1.0.
Although many UML tools support some of the new features of UML 2.x, the OMG provides no test suite to objectively test compliance with its specifUnified Modeling Language topicsications.
Software Development Methods
UML is not a development method by itself, however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT, Booch method, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notations (for example OMT), and new methods have been created based on UML. The best known is IBM Rational Unified Process (RUP). There are many other UML-based methods like Abstraction Method, Dynamic Systems Development Method, and others, designed to provide more specific solutions, or achieve different objectives.
Modeling
It is very important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphic representation of a system's model. The model also contains a "semantic backplane" — documentation such as written use cases that drive the model elements and diagrams.
UML diagrams represent two different views of a system model:
• Static (or structural) view: Emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams.
• Dynamic (or behavioral) view: Emphasizes the dynamic behaviour of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.
UML models can be exchanged among UML tools by using the XMI interchange format.
Diagrams overview
UML 2.2 has 14 types of diagrams divided into two categories. Seven diagram types represent structural information, and the other seven represent general types of behavior, including four that represent different aspects of interactions. These diagrams can be categorized hierarchically as shown in the following class diagram:
UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams; this flexibility has been partially restricted in UML 2.0. UML profiles may define additional diagram types or extend existing diagrams with additional notations.
In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is allowed in a UML diagram.
Structure diagrams
Structure diagrams emphasize what things must be in the system being modeled:
• Class diagram: the class diagrams describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.
• Component diagram: depicts how a software system is split up into components and shows the dependencies among these components.
• Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible.
• Deployment diagram: serves to model the hardware used in system implementations, and the execution environments and artifacts deployed on the hardware.
• Object diagram: shows a complete or partial view of the structure of a modeled system at a specific time.
• Package diagram: depicts how a system is split up into logical groupings by showing the dependencies among these groupings.
• Profile diagram: operates at the metamodel level to show stereotypes as classes with the <
Since structure diagrams represent the structure they are used extensively in documenting the architecture of software systems.
Behavior diagrams
Behavior diagrams emphasize what must happen in the system being modeled:
• Activity diagram: represents the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
• State machine diagram: standardized notation to describe many systems, from computer programs to business processes.
• Use case diagram: shows the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.
Since behavior diagrams illustrate the behaviour of a system, they are used extensively to describe the functionality of software systems.
Interaction diagrams
Interaction diagrams, a subset of behaviour diagrams, emphasize the flow of control and data among the things in the system being modeled:
• Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
• Interaction overview diagram: are a type of activity diagram in which the nodes represent interaction diagrams.
• Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.
• Timing diagrams: are a specific type of interaction diagram, where the focus is on timing constraints.
The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.
Criticisms
Although UML is a widely recognized and used modeling standard, it is frequently criticized for the following:
Standards bloat
Bertrand Meyer, in a satirical essay framed as a student's request for a grade change, apparently criticized UML as of 1997 for being unrelated to object-oriented software development; a disclaimer was added later pointing out that his company nevertheless supports UML. Ivar Jacobson, a co-architect of UML, said that objections to UML 2.0's size were valid enough to consider the application of intelligent agents to the problem. It contains many diagrams and constructs that are redundant or infrequently used.
Problems in learning and adopting
The problems cited in this section make learning and adopting UML problematic, especially when required of engineers lacking the prerequisite skills. In practice, people often draw diagrams with the symbols provided by their CASE tool, but without the meanings those symbols are intended to provide.
Linguistic incoherence
The extremely poor writing of the UML standards themselves -- assumed to be the consequence of having been written by a non-native English speaker -- seriously reduces their normative value. In this respect the standards have been widely cited, and indeed pilloried, as prime examples of unintelligible geekspeak.
Capabilities of UML and implementation language mismatch
As with any notational system, UML is able to represent some systems more concisely or efficiently than others. Thus a developer gravitates toward solutions that reside at the intersection of the capabilities of UML and the implementation language. This problem is particularly pronounced if the implementation language does not adhere to orthodox object-oriented doctrine, as the intersection set between UML and implementation language may be that much smaller.
Disfunctional interchange format
While the XMI (XML Metadata Interchange) standard is designed to facilitate the interchange of UML models, it has been largely ineffective in the practical interchange of UML 2.x models. This interoperability ineffectiveness is attributable to two reasons. Firstly, XMI 2.x is large and complex in its own right, since it purports to address a technical problem more ambitious than exchanging UML 2.x models. In particular, it attempts to provide a mechanism for facilitating the exchange of any arbitrary modeling language defined by the OMG's Meta-Object Facility (MOF). Secondly, the UML 2.x Diagram Interchange specification lacks sufficient detail to facilitate reliable interchange of UML 2.x notations between modeling tools. Since UML is a visual modeling language, this shortcoming is substantial for modelers who don't want to redraw their diagrams.
Modeling experts have written sharp criticisms of UML, including Bertrand Meyer's "UML: The Positive Spin", and Brian Henderson-Sellers and Cesar Gonzalez-Perez in "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0".
Illustration of the Meta-Object Facility. (I didn't know how to edit the Labels so changed the explanation to match them)
The Object Management Group (OMG) has developed a metamodeling architecture to define the Unified Modeling Language (UML), called the Meta-Object Facility (MOF). The Meta-Object Facility is a standard for model-driven engineering, designed as a four-layered architecture, as shown in the image at right. It provides a meta-meta model at the top layer, called the M0 layer. This M0-model is the language used by Meta-Object Facility to build metamodels, called M1-models. The most prominent example of a Layer 2 Meta-Object Facility model is the UML metamodel, the model that describes the UML itself. These M2-models describe elements of the M2-layer, and thus M2-models. These would be, for example, models written in UML. The last layer is the M3-layer or data layer. It is used to describe runtime instance of the system.
Beyond the M3-model, the Meta-Object Facility describes the means to create and manipulate models and metamodels by defining CORBA interfaces that describe those operations. Because of the similarities between the Meta-Object Facility M3-model and UML structure models, Meta-Object Facility metamodels are usually modeled as UML class diagrams. A supporting standard of Meta-Object Facility is XMI, which defines an XML-based exchange format for models on the M3-, M2-, or M1-Layer.
中文翻译：
统一建模语言（部分中文翻译）
统一建模语言（UML，Unified Modeling Language）是非专利的第三代建模和规约语言。UML是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。
UML集成了Booch，OMT和面向对象软件工程的概念，将这些方法融合为单一的，通用的，并且可以广泛使用的建模语言。UML打算成为可以对并发和分布式系统的标准建模语言。
UML并不是一个工业标准，但在Object Management Group的主持和资助下，UML正在逐渐成为工业标准。OMG 之前曾经呼吁业界向其提供有关面向对象的理论及实现的方法，以便制作一个严谨的软件建模语言（Software Modeling Language）。有很多业界的领袖亦真诚地回应OMG，帮助她建立一个业界标准。
模型
在UML系统开发中有三个主要的模型：
功能模型：从用户的角度展示系统的功能，包括用例图。
对象模型：采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类图。
动态模型：展现系统的内部行为。包括序列图，活动图，状态图。
区分UML模型和UML图是非常重要的，UML图，包括用例图、协作图、活动图、序列图、部署图、构件图、类图、状态图，是模型中信息的图形表达方式，但是UML模型独立于UML图存在。XML的当前版本只提供了模型信息的交换，而没有提供图信息的交换。
UML使用一套与Java语言或其他面向对象语言等价物，同时也是本体论等价物的图形标记。
UML并不是一个方法学，也不要求使用一个方法学，但是UML对于Rational 统一过程来说是必不可少的。
图形
UML 2.0 中一共定义了13 种图示（diagrams）。为方便了解，可分类成右侧的结构。
结构性图形（Structure diagrams） 强调的是系统式的建模：
类别图 (Class Diagram)
元件图(Component diagram)
复合结构图(Composite structure diagram)
部署图(Deployment diagram)
对象图(Object diagram)
套件图(Package diagram)
行为式图形（Behavior diagrams） 强调系统模型中触发的事件：
活动图(Activity diagram)
状态机图 (State Machine diagram)
用例图 (Use Case Diagram)
沟通性图形（Interaction diagrams）, 属于行为图形的子集合，强调系统模型中的资料流程：
通信图(Communication diagram)
交互概述图(Interaction overview diagram) (UML 2.0)
顺序图(Sequence diagram)
时间图(UML Timing Diagram) (UML 2.0)
协定状态机是状态机的子变种。它用来塑造网络通讯协定模型。
UML 并不限定 UML 要素型别非得是某图形上的型别。一般来说，每个 UML 要素大约会出现在图的所有型别。这种弹性在 UML 2.0 部分被限定。
为了要保持工程图的传统，在您的 UML 图上加注用途、约束、或意图永远无伤大雅。
UML 2为了符合模型驱动架构（Model Driven Architecture）的需求做了大幅度的修改除在图形基础上扩充及变化了部份的展现方式外，也增加了一些图形标准元件，比前一版多出了由顺序图与互动图所混合而成的互动概图(Interaction Overview Diagram)、强调时间点的时序图(Timing Diagram)与合成结构图(Composite Structure Diagram)，此外，在UML2中，UML1合作图转变为通讯图(Communication Diagram)，且在顺序图中也添加了互动框(Interaction Frame)的概念，还有增加一些运算子(如sd、loop、alt等)。同时，UML2支援模型驱动架构(MDA)倡议，提供稳定的基础架构，容许软件开发程序增添自动化作业。此外，MDA把大型的系统分解概念成几个元件模型，并与其他模型保持连结，使得UML更加精确。
UML 从来源中使用相当多的概念. 我们将之定义于统一建模语言术语汇表。下面仅列代表性的概念.
对于结构而言
执行者，属性，类，元件，接口，对象，包。
对于行为而言
活动，事件，讯息，方法，操作，状态，用例。
对于关系而言
聚合，关联，组合，相依，广义化 (or 继承)。
其他概念
构造型 — 这规范符号应用到的模型
多重性 — 多重性标记法与数据库建模基数对应，例如： 1, 0..1, 1..*
角色
