Unified Modeling Language

The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system.[1]

The creation of UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design. It was developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software in 1994–1995, with further development led by them through 1996.[1]

In 1997 UML was adopted as a standard by the Object Management Group (OMG), and has been managed by this organization ever since. In 2005 UML was also published by the International Organization for Standardization (ISO) as an approved ISO standard.[2] Since then the standard has been periodically revised to cover the latest revision of UML.[3]

UML logo

History

OO Modeling languages history
History of object-oriented methods and notation

Before UML 1.0

UML has been evolving since the second half of the 1990s and has its roots in the object-oriented programming methods developed in the late 1980s and early 1990s. The timeline (see image) shows the highlights of the history of object-oriented modeling methods and notation.

It is originally based on the notations of the Booch method, the object-modeling technique (OMT) and object-oriented software engineering (OOSE), which it has integrated into a single language.[4]

Rational Software Corporation hired James Rumbaugh from General Electric in 1994 and after that the company became the source for two of the most popular object-oriented modeling approaches of the day:[5] Rumbaugh's object-modeling technique (OMT) and Grady Booch's method. They were soon assisted in their efforts by Ivar Jacobson, the creator of the object-oriented software engineering (OOSE) method, who joined them at Rational in 1995.[1]

UML 1.x

Under the technical leadership of those three (Rumbaugh, Jacobson and Booch), a consortium called the UML Partners was organized in 1996 to complete the Unified Modeling Language (UML) specification, and propose it to the Object Management Group (OMG) for standardisation. The partnership also contained additional interested parties (for example HP, DEC, IBM and Microsoft). The UML Partners' UML 1.0 draft was proposed to the OMG in January 1997 by the consortium. During the same month the UML Partners formed a group, designed to define the exact meaning of language constructs, chaired by Cris Kobryn and administered by Ed Eykholt, to finalize 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.[1][6]

After the first release a task force was formed[1] to improve the language, which released several minor revisions, 1.3, 1.4, and 1.5.[7]

The standards it produced (as well as the original standard) have been noted as being ambiguous and inconsistent.[8][9]

Cardinality notation

As with database Chen, Bachman, and ISO ER diagrams, class models are specified to use "look-across" cardinalities, even though several authors (Merise,[10] Elmasri & Navathe[11] amongst others[12]) prefer same-side or "look-here" for roles and both minimum and maximum cardinalities. Recent researchers (Feinerer,[13] Dullea et al.[14]) have shown that the "look-across" technique used by UML and ER diagrams is less effective and less coherent when applied to n-ary relationships of order strictly greater than 2.

Feinerer says: "Problems arise if we operate under the look-across semantics as used for UML associations. Hartmann[15] investigates this situation and shows how and why different transformations fail.", and: "As we will see on the next few pages, the look-across interpretation introduces several difficulties which prevent the extension of simple mechanisms from binary to n-ary associations."

UML 2

UML 2.0 major revision replaced version 1.5 in 2005, which was developed with an enlarged consortium to improve the language further to reflect new experience on usage of its features.[16]

Although UML 2.1 was never released as a formal specification, versions 2.1.1 and 2.1.2 appeared in 2007, followed by UML 2.2 in February 2009. UML 2.3 was formally released in May 2010.[17] UML 2.4.1 was formally released in August 2011.[17] UML 2.5 was released in October 2012 as an "In progress" version and was officially released in June 2015.[17] Formal version 2.5.1 was adopted in December 2017.[18]

There are four parts to the UML 2.x specification:

  • The Superstructure that defines the notation and semantics for diagrams and their model elements
  • The Infrastructure that defines the core metamodel on which the Superstructure is based
  • The Object Constraint Language (OCL) for defining rules for model elements
  • The UML Diagram Interchange that defines how UML 2 diagram layouts are exchanged

The current versions of these standards are[19]:

  • UML Superstructure version 2.4.1
  • UML Infrastructure version 2.4.1
  • OCL version 2.3.1
  • UML Diagram Interchange version 1.0.

It continues to be updated and improved by the revision task force, who resolve any issues with the language.[20]

Design

UML offers a way to visualize a system's architectural blueprints in a diagram, including elements such as:[4]

Although originally intended for object-oriented design documentation, UML has been extended to a larger set of design documentation (as listed above),[21] and been found useful in many contexts.[22]

Software development methods

UML is not a development method by itself;[23] however, it was designed to be compatible with the leading object-oriented software development methods of its time, for example OMT, Booch method, Objectory and especially RUP that it was originally intended to be used with when work began at Rational Software.

Modeling

It is 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 set of diagrams need not completely cover the model and deleting a diagram does not change the model. The model may also contain documentation that drives the model elements and diagrams (such as written use cases).

UML diagrams represent two different views of a system model:[24]

UML models can be exchanged among UML tools by using the XML Metadata Interchange (XMI) format.

In UML, one of the key tools for behavior modelling is the use-case model, caused by OOSE. Use cases are a way of specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do.[25]

Diagrams

UML 2 has many types of diagrams, which are divided into two categories.[4] Some types represent structural information, and the rest represent general types of behavior, including a few that represent different aspects of interactions. These diagrams can be categorized hierarchically as shown in the following class diagram:[4]

Hierarchy of UML 2.2 Diagrams, shown as a class diagram

These diagrams may all contain comments or notes explaining usage, constraint, or intent.

Structure diagrams

Structure diagrams emphasize the things that must be present in the system being modeled. Since structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems. For example, the component diagram describes how a software system is split up into components and shows the dependencies among these components.

Behavior diagrams

Behavior diagrams emphasize what must happen in the system being modeled. Since behavior diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems. As an example, the activity diagram describes the business and operational step-by-step activities of the components in a system.

Interaction diagrams

Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled. For example, the sequence diagram shows how objects communicate with each other regarding a sequence of messages.

Metamodeling

M0-m3
Illustration of the Meta-Object Facility

The Object Management Group (OMG) has developed a metamodeling architecture to define the UML, called the Meta-Object Facility.[26] MOF is designed as a four-layered architecture, as shown in the image at right. It provides a meta-meta model at the top, called the M3 layer. This M3-model is the language used by Meta-Object Facility to build metamodels, called M2-models.

The most prominent example of a Layer 2 Meta-Object Facility model is the UML metamodel, which describes the UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe runtime instances of the system.[27]

The meta-model can be extended using a mechanism called stereotyping. This has been criticised as being insufficient/untenable by Brian Henderson-Sellers and Cesar Gonzalez-Perez in "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0".[28]

Adoption

UML has been marketed for many contexts.[22][29]

It has been treated, at times, as a design silver bullet, which leads to problems. UML misuse includes overuse (designing every part of the system with it, which is unnecessary) and assuming that novices can design with it.[30]

It is considered a large language, with many constructs. Some people (including Jacobson) feel that UML's size hinders learning (and therefore, using) it.[31]

See also

References

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.

  1. ^ a b c d e Unified Modeling Language User Guide, The (2 ed.). Addison-Wesley. 2005. p. 496. ISBN 0321267974. , See the sample content, look for history
  2. ^ "ISO/IEC 19501:2005 - Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2". Iso.org. 2005-04-01. Retrieved 2015-05-07.
  3. ^ "ISO/IEC 19505-1:2012 - Information technology - Object Management Group Unified Modeling Language (OMG UML) - Part 1: Infrastructure". Iso.org. 2012-04-20. Retrieved 2014-04-10.
  4. ^ a b c d "OMG Unified Modeling Language (OMG UML), Superstructure. Version 2.4.1". Object Management Group. Retrieved 9 April 2014.
  5. ^ Andreas Zendler (1997) Advanced Concepts, Life Cycle Models and Tools for Objeckt-Oriented Software Development. p.122
  6. ^ "UML Specification version 1.1 (OMG document ad/97-08-11)". Omg.org. Retrieved 2011-09-22.
  7. ^ "UML". Omg.org. Retrieved 2014-04-10.
  8. ^ Génova et alia 2004 "Open Issues in Industrial Use Case Modeling"
  9. ^ "Will UML 2.0 Be Agile or Awkward?" (PDF). Retrieved 2011-09-22.
  10. ^ Hubert Tardieu, Arnold Rochfeld and René Colletti La methode MERISE: Principes et outils (Paperback - 1983)
  11. ^ Elmasri, Ramez, B. Shamkant, Navathe, Fundamentals of Database Systems, third ed., Addison-Wesley, Menlo Park, CA, USA, 2000.
  12. ^ ER 2004 : 23rd International Conference on Conceptual Modeling, Shanghai, China, 8-12 November 2004 Archived 27 May 2013 at the Wayback Machine
  13. ^ "A Formal Treatment of UML Class Diagrams as an Efficient Method for Configuration Management 2007" (PDF). Retrieved 2011-09-22.
  14. ^ "James Dullea, Il-Yeol Song, Ioanna Lamprou - An analysis of structural validity in entity-relationship modeling 2002" (PDF). Retrieved 2011-09-22.
  15. ^ ""Reasoning about participation constraints and Chen's constraints" S Hartmann - 2003" (PDF). Retrieved 2013-08-17.
  16. ^ "UML 2.0". Omg.org. Retrieved 2011-09-22.
  17. ^ a b c "UML". Omg.org. Retrieved 2011-09-22.
  18. ^ "UML 2.5.1 specification". Omg.org. Retrieved 2018-10-24.
  19. ^ OMG. "OMG Formal Specifications (Modeling and Metadata paragraph)". Retrieved 2016-02-12.
  20. ^ "Issues for UML 2.6 Revision task Force mailing list". Omg.org. Retrieved 2014-04-10.
  21. ^ Satish Mishra (1997). "Visual Modeling & Unified Modeling Language (UML): Introduction to UML". Rational Software Corporation. Accessed 9 November 2008.
  22. ^ a b "UML, Success Stories". Retrieved 9 April 2014.
  23. ^ John Hunt (2000). The Unified Process for Practitioners: Object-oriented Design, UML and Java. Springer, 2000. ISBN 1-85233-275-1. p.5.door
  24. ^ Jon Holt Institution of Electrical Engineers (2004). UML for Systems Engineering: Watching the Wheels IET, 2004, ISBN 0-86341-354-4. p.58
  25. ^ Manuel Almendros-Jiménez, Jesús & Iribarne, Luis. (2007). Describing Use-Case Relationships with Sequence Diagrams. Comput. J.. 50. 116-128. 10.1093/comjnl/bxl053.
  26. ^ Iman Poernomo (2006) "The Meta-Object Facility Typed" in: Proceeding SAC '06 Proceedings of the 2006 ACM symposium on Applied computing. pp. 1845-1849
  27. ^ "UML 2.4.1 Infrastructure". Omg.org. 2011-08-05. Retrieved 2014-04-10.
  28. ^ B. Henderson-Sellers; C. Gonzalez-Perez (2006). "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". in: Model Driven Engineering Languages and Systems. Springer Berlin / Heidelberg.
  29. ^ "UML 2.5: Do you even care?". "UML truly is ubiquitous"
  30. ^ "Death by UML Fever".
  31. ^ "Ivar Jacobson on UML, MDA, and the future of methodologies".

Further reading

External links

Activity diagram

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e., workflows), as well as the data flows intersecting with the related activities. Although activity diagrams primarily show the overall flow of control, they can also include elements showing the flow of data between activities through one or more data stores.

Actor (UML)

An actor in the Unified Modeling Language (UML) "specifies a role played by a user or any other system that interacts with the subject.""An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data),

but which is external to the subject.""Actors may represent roles played by human users, external hardware, or other subjects. Actors do not necessarily represent specific physical entities but merely particular facets (i.e., “roles”) of some entities that are relevant to the specification of its associated use cases. A single physical instance may play the role of several different actors and a given actor may be played by multiple different instances."UML 2 does not permit associations between Actors. The use of generalization/specialization relationship between actors is useful in modeling overlapping behaviours between actors and does not violate this constraint since a generalization relation is not a type of association.Actors interact with use cases.

Component diagram

In Unified Modeling Language (UML), a component diagram depicts how components are wired together to form larger components or software systems.

They are used to illustrate the structure of arbitrarily complex systems.

Deployment diagram

A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. To describe a web site, for example, a deployment diagram would show what hardware components ("nodes") exist (e.g., a web server, an application server, and a database server), what software components ("artifacts") run on each node (e.g., web application, database), and how the different pieces are connected (e.g. JDBC, REST, RMI).

The nodes appear as boxes, and the artifacts allocated to each node appear as rectangles within the boxes. Nodes may have subnodes, which appear as nested boxes. A single node in a deployment diagram may conceptually represent multiple physical nodes, such as a cluster of database servers.

There are two types of Nodes:

Device Node

Execution Environment NodeDevice nodes are physical computing resources with processing memory and services to execute software, such as typical computers or mobile phones. An execution environment node (EEN) is a software computing resource that runs within an outer node and which itself provides a service to host and execute other executable software elements.

Event (UML)

An event in the Unified Modeling Language (UML) is a notable occurrence at a particular point in time.

Events can, but do not necessarily, cause state transitions from one state to another in state machines represented by state machine diagrams.

A transition between states occurs only when any guard condition for that transition are satisfied.

Grady Booch

Grady Booch (born February 27, 1955) is an American software engineer, best known for developing the Unified Modeling Language (UML) with Ivar Jacobson and James Rumbaugh. He is recognized internationally for his innovative work in software architecture, software engineering, and collaborative development environments.

James Rumbaugh

James E. Rumbaugh (born August 22, 1947) is an American computer scientist and object-oriented methodologist who is best known for his work in creating the Object Modeling Technique (OMT) and the Unified Modeling Language (UML).

List of Unified Modeling Language tools

This article compares UML tools. UML tools are software applications which support some functions of the Unified Modeling Language.

Meta-Object Facility

The Meta-Object Facility (MOF) is an Object Management Group (OMG) standard for model-driven engineering. Its purpose is to provide a type system for entities in the CORBA architecture and a set of interfaces through which those types can be created and manipulated. The official reference page may be found at OMG's website.

Object Constraint Language

The Object Constraint Language (OCL) is a declarative language describing rules applying to Unified Modeling Language (UML) models developed at IBM and is now part of the UML standard. Initially, OCL was merely a formal specification language extension for UML. OCL may now be used with any Meta-Object Facility (MOF) Object Management Group (OMG) meta-model, including UML. The Object Constraint Language is a precise text language that provides constraint and object query expressions on any MOF model or meta-model that cannot otherwise be expressed by diagrammatic notation. OCL is a key component of the new OMG standard recommendation for transforming models, the Queries/Views/Transformations (QVT) specification.

Package (UML)

A package in the Unified Modeling Language is used "to group elements, and to provide a namespace for the grouped elements". A package may contain other packages, thus providing for a hierarchical organization of packages.

Pretty much all UML elements can be grouped into packages. Thus, classes, objects, use cases, components, nodes, node instances etc. can all be organized as packages, thus enabling a manageable organization of the myriad elements that a real-world UML model entails.

Package diagram

A package diagram in the Unified Modeling Language depicts the dependencies between the packages that make up a model.

Profile (UML)

A profile in the Unified Modeling Language (UML) provides a generic extension mechanism for customizing UML models for particular domains and platforms. Extension mechanisms allow refining standard semantics in strictly additive manner, preventing them from contradicting standard semantics.Profiles are defined using stereotypes, tag definitions, and constraints which are applied to specific model elements, like Classes, Attributes, Operations, and Activities. A Profile is a collection of such extensions that collectively customize UML for a particular domain (e.g., aerospace, healthcare, financial) or platform (J2EE, .NET).

Sequence diagram

A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams are typically associated with use case realizations in the Logical View of the system under development. Sequence diagrams are sometimes called event diagrams or event scenarios.

A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.

Systems Modeling Language

The Systems Modeling Language (SysML) is a general-purpose modeling language for systems engineering applications. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems.

SysML was originally developed by an open source specification project, and includes an open source license for distribution and use. SysML is defined as an extension of a subset of the Unified Modeling Language (UML) using UML's profile mechanism. The language's extensions were designed to support systems engineering activities.

Timing diagram (Unified Modeling Language)

A timing diagram in the Unified Modeling Language 2.0 is a specific type of interaction diagram, where the focus is on timing constraints.

Timing diagrams are used to explore the behaviors of objects throughout a given period of time. A timing diagram is a special form of a sequence diagram. The differences between timing diagram and sequence diagram are the axes are reversed so that the time increases from left to right and the lifelines are shown in separate compartments arranged vertically.

There are two basic flavors of timing diagram: the concise notation, and the robust notation .

UML tool

A UML tool or Unified Modeling Language tool is a software application that supports some or all of the notation and semantics associated with the Unified Modeling Language (UML), which is the industry standard general-purpose modeling language for software engineering.

UML tool is used broadly here to include application programs which are not exclusively focused on UML, but which support some functions of the Unified Modeling Language, either as an add-on, as a component or as a part of their overall functionality.

Use case diagram

A use case diagram at its simplest is a representation of a user's interaction with the system that shows the relationship between the user and the different use cases in which the user is involved. A use case diagram can identify the different types of users of a system and the different use cases and will often be accompanied by other types of diagrams as well. The use cases are represented by either circles or ellipses.

XML Metadata Interchange

The XML Metadata Interchange (XMI) is an Object Management Group (OMG) standard for exchanging metadata information via Extensible Markup Language (XML).

It can be used for any metadata whose metamodel can be expressed in Meta-Object Facility (MOF).

The most common use of XMI is as an interchange format for UML models, although it can also be used for serialization of models of other languages (metamodels).

Unified Modeling Language
Actors
Concepts
Diagrams
Derived languages
Other topics
Fields
Concepts
Orientations
Models
Software
engineers
Related fields
ISO standards by standard number
1–9999
10000–19999
20000+

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.