Unified Modeling Language

From Free net encyclopedia

Image:Mergefrom.gif It has been suggested that Superstep be merged into this article or section. ([[{{{2|: talk:Unified_Modeling_Language}}}|Discuss]])

The Unified Modeling Language (UML) is a non-proprietary, object modeling and specification language used in software engineering. UML includes a standardized graphical notation that may be used to create an abstract model of a system: the UML model.

UML is officially defined at the Object Management Group by the UML metamodel (a Meta-Object Facility metamodel serialized in XMI). UML is a General Purpose Modeling language. While UML was designed to specify, visualize, construct, and document software-intensive systems, UML is not restricted to modeling software. UML has its strengths at higher, more architectural levels and has been used for modeling hardware (engineering systems) and is commonly used for business process modeling, systems engineering modeling, and representing organizational structure among many other domains.

UML has been important in the early ages of Model Driven Engineering or Model-Driven Architecture. By establishing a consensual agreement on the various graphical shapes commonly used to represent common concepts like classes, inheritance, agregation, states, transitions, etc. UML has allowed to concentrate on more fundamental issues.

Contents

[edit]

History

When Rational Software Corporation hired James Rumbaugh from General Electric in 1994 they became the source of the two most popular object-oriented modeling approaches of the day : Rumbaugh's OMT (which was better in analysis) and Grady Booch's Booch method (which was better in design). Together Rumbaugh and Booch attempted to reconcile their two approaches and started work on a Unified Method.

In June 1995 the Object Management Group (OMG) put out a call for a common modeling approach to reconcile the greater than 50 named approaches in the market. This effort was pushed significantly by Ivar Jacobson of Objectory and Richard Soley of OMG.

In 1995, Rational acquired Objectory and with it got the help of Ivar Jacobson, the developer of the OOSE method. Together, Rumbaugh, Booch, and Jacobson, often called the three amigos, redirected their efforts from developing a unified method to developing a unified notation to answer the call from OMG.

With this leadership of three leading OO methodologists at Rational, a team of experts representing many companies was assembled to submit their Unified Modeling Language (UML) proposal to OMG. In 1996, a team known as the UML Partners was convened for this purpose. The consortium included Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments, and Unisys. In the complex technical/political negotiations that characterize OMG standard development, the several competitor proposals were either dropped or merged with the UML proposal, adding IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies, and Softeam to the UML Partners. By the fall of 1997, after much public review and comment, the UML standard, (by now called UML 1.1) was approved by OMG.

As a notation, the influence of the OMT style is most apparent (e.g., in boxes for classes and objects). Though the Booch cloud notation was dropped, the Booch capability to specify lower-level design detail was embraced. The concept and notation of use cases (from Objectory) was integrated into the notation. Concepts from many other software-development methods (e.g., Class-Relation (circa 1994 from the French company Softeam), CRC Cards (circa 1989 from Kent Beck and Ward Cunningham), and OORam) were subsumed under the idea of supporting all these methods with a single modeling language. UML is useful in a variety of engineering problems, from single process, single user applications to concurrent, distributed systems, making UML rich but large.

It is now an international standard:

ISO/IEC 19501:2005 Information technology -- Open Distributed Processing -- Unified Modeling Language (UML) Version 1.4.2

UML has since been revised and grown, with several releases (the major being UML 1.3 and 1.5), fixing some dead ends and adding new notational capabilities. Many industry firms have now contributed to the standard. The current standard is UML 2.0., a major rewrite. The latest UML version prior to 2.0 was 1.5; this 1.5 version will continue to be the official current version until all four components of UML 2 are completed and ratified.

The first part of UML 2.0, the Superstructure which describes the new diagrams and modeling elements available, was adopted by the OMG in October 2004. Other parts of UML 2, notably the infrastructure, the object constraint language (OCL) and the diagram interchange were yet to be completed and ratified as of November 2005.

The final UML 2.0 specification has been declared available and has been added to OMG's formal specification library. The other parts of the UML specification, the UML 2.0 infrastructure, the UML 2.0 Diagram Interchange, and UML 2.0 OCL specifications have been adopted but are not yet considered available.

As change is inevitable, a UML 2.1 revision has been underway for some time now. The outcome of this work should be available soon (first semester 2006) in the form of an XMI 2.1 version of the UML 2.1 version. The corresponding XMI 2.1 file will be made available from the OMG ADTF group.

Most of the commercially successful modeling tools now support most of UML 2.0, leaving only the rarely used features left to implement. Of course, it will take some time for the tools that are in the hands of the developers to reach this level of compliance.

[edit]

Methods

UML is not a method by itself, however it was designed to be compatible with the leading object-oriented software development methods of its time (e.g., OMT, Booch, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notation (e.g., OMT) and new methods have been created based on UML. Most known is Rational Unified Process (RUP) created by the Rational Software Corporation. 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.

[edit]

Modeling

It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphical representation of a system's model. The model also contains a "semantic backplane" — textual documentation such as written use cases that drive the model elements and diagrams.

There are three prominent parts of a system's model:

Functional Model

Showcases the functionality of the system from the user's Point of View.
Includes Use Case Diagrams.

Object Model

Showcases the structure and substructure of the system using objects, attributes, operations, and associations.
Includes Class Diagrams.

Dynamic Model

Showcases the internal behavior of the system.
Includes Sequence Diagrams, Activity Diagrams and State Machine Diagrams.

Models can be exchanged among UML tools by using the XML-based XMI format.

[edit]

Diagrams

Image:Uml hierarchie des diagrammes.png

In UML 2.0 there are 13 types of diagrams. To understand them, it is sometimes useful to categorize them hierarchically, as shown in the hierarchy chart on the right.

Structure Diagrams emphasize what things must be in the system being modeled:

Behavior Diagrams emphasize what must happen in the system being modeled:

Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.

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.

Diagrams can be exchanged among UML tools by using the Diagram Interchange (DI, XMI[DI]) standard.

In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is always allowed in a UML diagram.

[edit]

Concepts

UML uses the following concepts:

For Structure

Actor, Attribute, Class, Component, Interface, Object, Package.

For Behavior

Activity, Event, Message, Method, Operation, State, Use Case.

For Relationships

Aggregation, Association, Composition, Depends, Generalization (or Inheritance).

Other Concepts

[edit]

Criticism

Although UML is a widely recognized and used standard, it is criticized for imprecise semantics leading to subjective interpretation and difficulties in the formal test phases of development. In one remedy to this form of misinterpretation, authors provide some form of explanation of their models in the form of narration or copious diagram notes.

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. The constraints of distributed system development are not an inherent part of UML, much as the plot of a novel is not part of the rules of grammar.

UML is often considered to be too bloated, too fine-grained in many aspects. Though details best captured in source code may be difficult to capture using UML notation, people often try to do so. 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 scope of a technique such as model-driven architecture requires an expressive, general notation such as UML 2.0.

A third problem leading to criticism and dissatisfaction is the large-scale adoption of UML by people without the required skills, often when management forces UML upon them. An ACM article, Self-diagnosis and early treatment are crucial in the fight against UML Fever is an amusing but all-too-true account of this and related issues.

Another perspective holds that it is a working system that is important, not beautiful models. As Jack Reeves succinctly put it, "The code is the design." [1][2] Pursuing this notion leads to the need for better ways of writing software; UML has value in approaches that compile the models to generate source or executable code. This however, may still not be sufficient since UML as a language does not exhibit Turing completeness, and any generated source or executable code would be limited to what a UML interpreting tool can discern or assume.

[edit]

Extensions

When it is necessary to introduce new notations or terminologies, UML provides user-defined extensions through the use of stereotypes, tagged values and constraints. Currently there are two extensions defined, namely Business and Objectory Process extensions.

Magnus Penker and Hans-Erik Eriksson (2000) describe Business Extensions in Business Modeling with UML.

Ovidiu S. Noran at the Griffith University compares UML and IDEF in "Business Modelling: UML vs. IDEF". [3]

Peter Coad et al. (1999) have also suggested a small set of UML colors.

[edit]

See also

Template:Col-beginTemplate:Col-2

Template:Col-2

Template:Col-end

[edit]

References

  • {{cite book 
| first= Michael Jesse
| last = Chonoles
| coauthors = James A. Schardt
| year = 2003
| title = UML 2 for Dummies
| publisher = Wiley Publishing
| id=ISBN 0-7645-2614-6

}}

  • {{cite book 
| first= Peter
| last = Coad
| coauthors = Eric Lefebvre; Jeff De Luca
| year = 1999
| title = Java Modeling In Color With UML: Enterprise Components and Process
| publisher = Prentice Hall
| id=ISBN 0-130-11510-X

}}

  • {{cite book 
| first = Martin
| last = Fowler
| authorlink = Martin Fowler
| year =
| title = UML Distilled: A Brief Guide to the Standard Object Modeling Language
| edition = 3rd ed.
| publisher = Addison-Wesley
| id = ISBN 0321193687

}}

  • {{cite book 
| first= Ivar
| last = Jacobson
| coauthors = Grady Booch; James Rumbaugh
| authorlink = Ivar Jacobson
| year = 1998
| title = The Unified Software Development Process
| publisher = Addison Wesley Longman
| id=ISBN 0-201-57169-2

}}

  • {{cite book 
| first = Robert Cecil
| last = Martin
| authorlink = Robert Cecil Martin
| year = 2003
| title = UML for Java Programmers
| publisher = Prentice Hall
| id = ISBN 0-13-142848-9

}}

  • {{cite book 
| first = Magnus
| last = Penker
| coauthors = Hans-Erik Eriksson
| year = 2000
| title = Business Modeling with UML
| publisher = John Wiley & Sons
| id = ISBN 0-471-29551-5

}}

  • {{cite web 
| author = Ovidiu S. Noran
| year=
| url = http://www.cit.gu.edu.au/~noran/Docs/UMLvsIDEF.pdf
| title = Business Modelling: UML vs. IDEF
| format = PDF
| accessdate = 2005-12-28

}}

  • {{cite web 
| author = Tom Gooch
| year =
| url = http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/history_of_uml.htm
| title = History of UML
| accessdate = 2005-12-28

}}

[edit]

External links

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.
ca:UML

cs:Unified Modeling Language da:UML de:Unified Modeling Language es:Lenguaje Unificado de Modelado eo:UML fr:Unified Modeling Language gl:Linguaxe Unificada de Modelado it:Unified Modeling Language he:UML lt:Unified Modeling Language nl:Unified Modeling Language ja:統一モデリング言語 pl:UML pt:UML ro:UML ru:UML sk:Unified Modeling Language sl:Unified Modelling Language fi:UML-mallinnus sv:UML vi:Ngôn ngữ mô hình hóa thống nhất uk:UML zh:统一建模语言

Retrieved from "http://www.netipedia.com/index.php/Unified_Modeling_Language"