Misplaced Pages

Unified Modeling Language

Article snapshot taken from[REDACTED] with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

This is an old revision of this page, as edited by MDE (talk | contribs) at 22:10, 3 August 2006. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 22:10, 3 August 2006 by MDE (talk | contribs)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

The Unified Modeling Language (UML) is a non-proprietary, object modeling and specification language used in software engineering. UML is a general-purpose modeling language that includes a standardized graphical notation that may be used to create an abstract model of a system, sometimes referred to as the UML model. UML may be considered as an extensible modeling language since it offers a profile mechanism to customize the language. If a concept you need is not present in the base language, you may introduce it by defining a stereotype. The semantics of extension by profiles has been improved with the UML 2.0 major revision.

UML is officially defined at the Object Management Group (OMG) by the UML metamodel – a Meta-Object Facility metamodel (MOF). Like other MOF-based specifications, the UML metamodel and UML models may be 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 is also commonly used for business process modeling, systems engineering modeling, and representing organizational structures. The Systems Modeling Language (SysML) is a Domain-Specific Modeling language for systems engineering that is defined as a UML 2.0 profile.

UML has been a catalyst for the evolution of model-driven technologies, which include ModelDriven Development (MDD), Model Driven Engineering (MDE), and model-driven architecture. By establishing an industry consensus on a graphic notation to represent common concepts like classes, components, generalization, aggregation, and behaviors, UML has allowed software developers to concentrate more on design and architecture.

In the initial MDA view, PIMs and PSMs could be expressed in the UML language. It is also possible to transform a UML model serialized in XMI into a Java or EJB implementation by using a Model Transformation Language or MTL. The standard way recommended by OMG for achieving this is to use the newly defined QVT standard. UML has also an optional graph navigation and constraint language called OCL; in its navigational aspect, this has a similar relationship to UML as XPath has to XML.

History

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 OMT, which was better for object analysis, and Grady Booch's Booch method, which was better for object design. Together Rumbaugh and Booch attempted to reconcile their two approaches and started work on a Unified Method.

They were soon assisted in their efforts by Ivar Jacobson, the creator of the OOSE method. Jacobson joined Rational in 1995, after his company, Objectory, 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 preferences.

In 1996 the Three Amigos decided that a Unified Modeling Language was more viable than a Unified Method, and redirected their efforts to respond to the OMG Request for Proposal (RFP) for an object modeling language ("Object Analysis & Design RFP-1",OMG document ad/96-05-01), which was issued in June 1996.

Under the technical leadership of 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.

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. For example CRC Cards (circa 1989 from Kent Beck and Ward Cunningham), and OORam were retained. 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 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, which is the current OMG standard.

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.

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 (for example OMT, Booch, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notation (for example OMT), and new methods have been created based on UML. Most well known is 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 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 XMI format.

Diagrams

Hierarchy of UML 2.0 Diagrams, shown as a class diagram

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 XMI (also DI, XMI).

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

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

Criticism

Although UML is a widely recognized and used modeling standard, it is frequently criticized for the following deficiencies:

  1. Language bloat. UML is often criticized as being gratuitously large and complex. It contains many diagrams and constructs that are redundant or infrequently used. This criticism is more frequently directed at UML 2.0 than UML 1.0, since the former includes many more design-by-committee compromises than the latter. The 80-20 rule needs to be better applied to UML, since only a relatively small number of its diagrams and constructs are commonly used. The other constructs should be added via model libraries and layers. In this manner, the Agile modelers can access an agile "Core UML" and the MDA advocates will have access to a comprehensive general-purpose modeling language. Although UML layering is theoretically supported by the UML 2.0 specification, it does not appear that vendors are implementing it.
  2. Imprecise semantics. Since UML is specified by a combination of itself (abstract syntax), OCL (well-formedness rules) and English (detailed semantic), it lacks the rigor of a language precisely defined using formal language techniques. In some cases, the UML abstract syntax, OCL and English are inconsistent with each other, in other cases they are incomplete. The imprecision of the UML specification has undesirable consequences for users and tool vendors alike, since tool vendors are forced to make implementation decisions that are inconsistent with the specification and other implementations.
  3. Problems in learning and adopting. The problems cited above make learning and adopting UML problematic, especially when management forces UML upon persons who lack the prerequisite skills. An ACM article, Self-diagnosis and early treatment are crucial in the fight against UML Fever is an amusing, but realistic, account of this and related issues.
  4. Only the code is in sync with the code. 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." 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. On the other hand, perhaps you should just sketch your models on a whiteboard and then code from there.
  5. Cumulative Impedance/Impedance mismatch UML, like any language or notation is able to represent some architectures, designs or approaches better (more compactly, with less effort, etc) than others. The same is true for the implementation language. Thus a developer ends up (more often than not) operating at the intersection of the natural capabilities/strengths of UML and the implementation language. This causes the developer to overlook possibly more efficient designs, leading to a suboptimal implementation. The problem is particularly pronounced if the implementation language does not follow the orthodox object-oriented doctrine.
  6. Aesthetically inconsistent. The adhoc mixing of abstract notation (ovals, boxes), stick figures and 3-D boxes makes UML ugly. Arguing that these are used in different diagram types (eg "use-case" vs "deployment") of the notation is insufficient, as it is seems possible to provide a consistent and asthetically pleasing means to indicate the type of diagram element. Presumably this is an artifact of the design by committee.

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".
  • Peter Coad et al. (1999) have also suggested a small set of UML colors.
  • Scott Ambler has done extensive work defining how to data model with the UML.

See also

Notes

  1. OMG → Object Management Group
  2. ^ XMI → XML Metadata Interchange
  3. MDA → Model-driven architecture
  4. PIM → Platform-independent model
  5. PSM → Platform-specific model
  6. EJB → Enterprise JavaBean
  7. QVT → Queries/Views/Transformations
  8. ^ OCL → Object Constraint Language
  9. XML → Extensible Markup Language
  10. ^ OMT → Object-modeling technique
  11. OOSE → Object-oriented software engineering
  12. OMG. "Object Analysis & Design RFP-1". Retrieved 2006-07-02.
  13. UML Specification v. 1.1 (OMG document ad/97-08-11)
  14. CRC Card → Class-Responsibility-Collaboration card
  15. OORam → Object Oriented Role Analysis Method

References

  • Ambler, Scott William (2004). The Object Primer: Agile Model Driven Development with UML 2. Cambridge University Press. ISBN 0-521-54018-6.
  • Chonoles, Michael Jesse (2003). UML 2 for Dummies. Wiley Publishing. ISBN 0-7645-2614-6. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Coad, Peter (1999). Java Modeling In Color With UML: Enterprise Components and Process. Prentice Hall. ISBN 0-130-11510-X. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd ed. ed.). Addison-Wesley. ISBN 0321193687. {{cite book}}: |edition= has extra text (help)
  • Jacobson, Ivar (1998). The Unified Software Development Process. Addison Wesley Longman. ISBN 0-201-57169-2. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Martin, Robert Cecil (2003). UML for Java Programmers. Prentice Hall. ISBN 0-13-142848-9.
  • Penker, Magnus (2000). Business Modeling with UML. John Wiley & Sons. ISBN 0-471-29551-5. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Ovidiu S. Noran. "Business Modelling: UML vs. IDEF" (PDF). Retrieved 2005-12-28.
  • Tom Gooch. "History of UML". Retrieved 2005-12-28.

External links


This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

Categories:
Unified Modeling Language Add topic