Misplaced Pages

Unified Modeling Language: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 04:00, 1 April 2014 editMonkbot (talk | contribs)Bots3,695,952 editsm Task 1c: Fix CS1 deprecated date parameter errors← Previous edit Revision as of 13:39, 7 April 2014 edit undoMthinkcpp (talk | contribs)716 edits See previous reason →External linksNext edit →
(16 intermediate revisions by the same user not shown)
Line 2: Line 2:
] ]


The '''Unified Modeling Language''' ('''UML''') is a general-purpose ] in the field of ]. The basic level provides a set of graphic notation techniques to create ] of ]-intensive systems. Higher levels cover process-oriented views of a system. It was developed by ], ] and ] at ] in the 1990s.<ref>Marc Hamilton (1999) ''Software Development: A Guide to Building Reliable Systems'' p.48</ref> It was adopted by the ] (OMG) in 1997, and has been managed by this organization ever since. In 2000 the Unified Modeling Language was accepted by the ] (ISO) as a standard for modeling software-intensive systems. The '''Unified Modeling Language''' ('''UML''') is a general-purpose ] in the field of ].
The basic level provides a set of graphic notation techniques to create ] of ]-intensive systems. Higher levels cover process-oriented views of a system.
It was created and developed by ], ] and ] at ] in the 1990s.<ref>Marc Hamilton (1999) ''Software Development: A Guide to Building Reliable Systems'' p.48</ref>
In 1997 is was adopted by the ] (OMG), and has been managed by this organization ever since. In 2000 the Unified Modeling Language was accepted by the ] (ISO) as a standard for modeling software-intensive systems.


== Overview == == Overview ==
Line 17: Line 23:
* reusable ].<ref name = "OMG00">Grady Booch, Ivar Jacobson & James Rumbaugh (2000) {{dead link|date=September 2011}}, Version 1.3 First Edition: March 2000. Retrieved 12 August 2008.</ref> * reusable ].<ref name = "OMG00">Grady Booch, Ivar Jacobson & James Rumbaugh (2000) {{dead link|date=September 2011}}, Version 1.3 First Edition: March 2000. Retrieved 12 August 2008.</ref>


UML has synthesized the notations of the ], the ] (OMT) and ] (OOSE) by fusing them into a single, common and widely usable modeling language.<ref>{{cite web|url=http://www.omg.org/spec/UML/2.4.1/Superstructure |title=OMG Unified Modeling Language (OMG UML), Superstructure. Version 2.4.1 |publisher=Object Management Group |accessdate=2013-03-28}}</ref> UML aims to be a standard modeling language which can model concurrent and ]. UML has synthesized the notations of the ], the ] (OMT) and ] (OOSE) by fusing them into a single, common and widely usable modeling language.<ref>{{cite web|url=http://www.omg.org/spec/UML/2.4.1/Superstructure |title=OMG Unified Modeling Language (OMG UML), Superstructure. Version 2.4.1 |publisher=Object Management Group |accessdate=2013-03-28}}</ref>

UML models may be automatically transformed to other representations (e.g. Java) by means of ]-like transformation languages. UML is ], with two mechanisms for customization: ]s and ]s.


== History == == History ==
Line 27: Line 31:
=== Before UML 1.x === === Before UML 1.x ===
After ] hired ] from ] in 1994, the company became the source for two of the most popular object-oriented modeling approaches of the day:<ref>Andreas Zendler (1997) ''Advanced Concepts, Life Cycle Models and Tools for Objeckt-Oriented Software Development''. p.122</ref> Rumbaugh's ] (OMT) and ]'s method known as ] (OOD). They were soon assisted in their efforts by ], the creator of the ] (OOSE) method. Jacobson joined Rational in 1995, after his company, Objectory AB,<ref>Objectory AB, known as Objectory System, was founded in 1987 by Ivar Jacobson. In 1991, It was acquired and became a subsidiary of Ericsson.</ref> was acquired by Rational. The three methodologists were collectively referred to as the "Three Amigos". After ] hired ] from ] in 1994, the company became the source for two of the most popular object-oriented modeling approaches of the day:<ref>Andreas Zendler (1997) ''Advanced Concepts, Life Cycle Models and Tools for Objeckt-Oriented Software Development''. p.122</ref> Rumbaugh's ] (OMT) and ]'s method known as ] (OOD). They were soon assisted in their efforts by ], the creator of the ] (OOSE) method. Jacobson joined Rational in 1995, after his company, Objectory AB,<ref>Objectory AB, known as Objectory System, was founded in 1987 by Ivar Jacobson. In 1991, It was acquired and became a subsidiary of Ericsson.</ref> was acquired by Rational. The three methodologists were collectively referred to as the "Three Amigos".

In 1996, Rational concluded that the abundance of modeling languages was slowing the adoption of object technology,{{Citation needed|date=December 2010}} so repositioning the work on a unified method, they tasked the "Three Amigos" with the development of a ] Unified Modeling Language. Representatives of competing object technology companies were consulted during ] '96;{{Citation needed|date=December 2010}} they chose ''boxes'' for representing classes rather than the ''cloud'' symbols that were used in Booch's notation.


Under the technical leadership of the "Three Amigos", an international consortium called the ] was organized in 1996 to complete the ''Unified Modeling Language (UML)'' specification, and propose it as a response to the OMG ]. 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 ] and administered by ], 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.<ref>{{cite web|url=http://www.omg.org/cgi-bin/doc?ad/97-08-11 |title=UML Specification version 1.1 (OMG document ad/97-08-11) |publisher=Omg.org |accessdate=2011-09-22}}</ref> Under the technical leadership of the "Three Amigos", an international consortium called the ] was organized in 1996 to complete the ''Unified Modeling Language (UML)'' specification, and propose it as a response to the OMG ]. 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 ] and administered by ], 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.<ref>{{cite web|url=http://www.omg.org/cgi-bin/doc?ad/97-08-11 |title=UML Specification version 1.1 (OMG document ad/97-08-11) |publisher=Omg.org |accessdate=2011-09-22}}</ref>


=== UML 1.x === === UML 1.x ===
As a modeling notation, the influence of the OMT notation dominates (e.&nbsp;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 ] notation from Objectory and the ] notation from Booch were integrated with the rest of the notation, but the ] was relatively weak in UML 1.1, and was not really fixed until the UML 2.0 major revision.{{Citation needed|date=December 2010}} As a modeling notation, the influence of the OMT notation dominates (e.&nbsp;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 ] notation from Objectory and the ] notation from Booch were integrated with the rest of the notation/


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 "] 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. 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 "] 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.
Line 52: Line 54:
The current versions of these standards follow: UML Superstructure version 2.4.1, UML Infrastructure version 2.4.1, OCL version 2.3.1, and UML Diagram Interchange version 1.0.<ref name="Versions">{{cite web|author=OMG|title=Catalog of OMG Modeling and Metadata Specifications|url=http://www.omg.org/technology/documents/modeling_spec_catalog.htm|accessdate = 2012-02-21}}</ref> The current versions of these standards follow: UML Superstructure version 2.4.1, UML Infrastructure version 2.4.1, OCL version 2.3.1, and UML Diagram Interchange version 1.0.<ref name="Versions">{{cite web|author=OMG|title=Catalog of OMG Modeling and Metadata Specifications|url=http://www.omg.org/technology/documents/modeling_spec_catalog.htm|accessdate = 2012-02-21}}</ref>


It has been noted that UML 2.x is large by ] a co-architect of UML who felt that the application of ] to the problem was worth considering.<ref>"Ivar Jacobson on UML, MDA, and the future of methodologies" (video of interview, transcript available), 24 October 2006. Retrieved 2009-05-22</ref>
Although many ]s support some of the new features of UML 2.x, the OMG provides no ] to objectively test compliance with its specifications.


== Topics == == Design/Usage ==


=== Software development methods === === Software development methods ===
Line 76: Line 78:
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. 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,{{Citation needed|date=December 2010}} a comment or note explaining usage, constraint, or intent is allowed in a UML diagram. A comment or note explaining usage, constraint, or intent is allowed in a UML diagram.


==== Structure diagrams ==== ==== Structure diagrams ====
Line 134: Line 136:


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 M0-model and UML structure models, Meta-Object Facility metamodels are usually modeled as UML class diagrams. A supporting standard of the Meta-Object Facility is ], which defines an XML-based exchange format for models on the M3-, M2-, or M1-Layer. 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 M0-model and UML structure models, Meta-Object Facility metamodels are usually modeled as UML class diagrams. A supporting standard of the Meta-Object Facility is ], which defines an XML-based exchange format for models on the M3-, M2-, or M1-Layer.

== Criticisms ==
{{Criticism section|date=December 2010}}
Although UML is a widely recognized and used modeling standard, it is frequently{{Citation needed|date=October 2011}} criticized for the following:

;Standards bloat: ], 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.<ref name="BMpaper">{{cite web|author=Bertrand Meyer|title=UML: The Positive Spin|url=http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html|accessdate = 2008-03-31}}</ref> ], a co-architect of UML, said that objections to UML 2.0's size were valid enough to consider the application of ] to the problem.<ref>"Ivar Jacobson on UML, MDA, and the future of methodologies" (video of interview, transcript available), 24 October 2006. Retrieved 2009-05-22</ref> 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.<ref>See the ] article '''' for an amusing account of such issues.</ref> In practice, people often draw diagrams with the symbols provided by their ], but without the meanings those symbols are intended to provide. Simple user narratives e.g. "what I do at work ..." have shown to be much simpler to record and more immediately useful.{{Citation needed|date=October 2011}}
;Linguistic incoherence: The standards have been cited as being ambiguous and inconsistent.<ref>Génova et alia 2004 "Open Issues in Industrial Use Case Modeling"</ref><ref>{{cite web|url=http://www.cs.tut.fi/~kk/webstuff/mofKalvot.pdf |title=Metamodeling and Meta-Object Facility (MOF) |format=PDF |accessdate=2011-09-22}}</ref><ref>{{cite web|url=http://www.uml-forum.com/docs/papers/CACM_Jan02_p107_Kobryn.pdf |title=Will UML 2.0 Be Agile or Awkward? |format=PDF |accessdate=2011-09-22}}</ref> The UML 2.0 standard still suffers many issues.<ref>{{cite web|url=http://www.mendeley.com/research/a-precise-approach-for-the-analysis-of-the-uml-models-consistency |title=A Precise Approach for the Analysis of the UML Models Consistency |doi=10.1007/11568346_9 |publisher=Mendeley.com |accessdate=2011-09-22}}</ref><ref>{{cite web|url=http://www.omg.org/issues/uml2-rtf.open.html |title=OMG UML Issues |publisher=Omg.org |accessdate=2011-09-22}}</ref>
;Capabilities of UML and implementation language mismatch: Typical of other notational systems, 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, since the intersection set between UML and implementation language may be that much smaller or equal in size.{{Citation needed|date=February 2013}}
;Dysfunctional 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 several 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.<ref name="faq">{{cite web|author=UML Forum|title=UML FAQ|url=http://www.umlforum.com/faq/|accessdate = 2013-02-21}}</ref> The Diagram Definition OMG project is another alternative.<ref name="DD">{{cite web|author=OMG|title=Diagram Definition, Version 1.0|url=http://www.omg.org/spec/DD/1.0/|date=2012-07-01|accessdate = 2013-02-21}}</ref>

;Cardinality notation: As with database Chen, Bachman, and ISO ]s, class models are specified to use "look-across" ], even though several authors (],<ref>Hubert Tardieu, Arnold Rochfeld and René Colletti La methode MERISE: Principes et outils (Paperback - 1983)</ref> Elmasri & Navathe <ref>Elmasri, Ramez, B. Shamkant, Navathe, Fundamentals of Database Systems, third ed., Addison-Wesley, Menlo Park, CA, USA, 2000.</ref> amongst others <ref>{{dead link|date=September 2011}}</ref>) prefer same-side or "look-here" for roles and both minimum and maximum cardinalities. Recent researchers (Feinerer,<ref>{{cite web|url=http://publik.tuwien.ac.at/files/pub-inf_4582.pdf |title=A Formal Treatment of UML Class Diagrams as an Efficient Method for Configuration Management 2007 |format=PDF |accessdate=2011-09-22}}</ref> Dullea et. alia <ref>{{cite web|url=http://www.ischool.drexel.edu/faculty/song/publications/p_DKE_03_Validity.pdf |title=James Dullea, Il-Yeol Song, Ioanna Lamprou - An analysis of structural validity in entity-relationship modeling 2002 |format=PDF |accessdate=2011-09-22}}</ref>) 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 >2.

:In Feinerer it says "Problems arise if we operate under the look-across semantics as used for UML associations. Hartmann <ref>{{cite web|url=http://crpit.com/confpapers/CRPITV17Hartmann.pdf |title="Reasoning about participation constraints and Chen's constraints" S Hartmann - 2003 |format=PDF |accessdate=2013-08-17}}</ref> investigates this situation and shows how and why different transformations fail." ''(Although the "reduction" mentioned is spurious as the two diagrams 3.4 and 3.5 are in fact the same)'' and also "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."

;Exclusive: The term "unified" applies only to the unification of the many prior existing and competing ]s. Important well known and popular techniques, almost universally used in industry, such as ]s and ]s were not included in the specification.{{Citation needed|date=July 2011}}

Modeling experts have written criticisms of UML, including ] and ] in "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0".<ref name="UsesAbusesStereotype">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.</ref>

;Complexity: UML has been criticized for being extremely complex compared to other tools.<ref>{{cite web
|url=http://lists.suckless.org/dev/1105/7901.html
|title= Suckless UML
|author=Uriel |date=May 2011
}}</ref>


== See also == == See also ==
Line 252: Line 230:
--> -->
* of the ] – Resources that include the latest version of the UML specification from the group in charge of defining the UML specification * of the ] – Resources that include the latest version of the UML specification from the group in charge of defining the UML specification
* – An ] article about the abuse of UML
* – Introductory article for UML. Retrieved 2011-01-29 * – Introductory article for UML. Retrieved 2011-01-29
* - Includes latest notation documentation. * - Includes latest notation documentation.

Revision as of 13:39, 7 April 2014

UML logo

The Unified Modeling Language (UML) is a general-purpose modeling language in the field of software engineering.

The basic level provides a set of graphic notation techniques to create visual models of object-oriented software-intensive systems. Higher levels cover process-oriented views of a system.

It was created and developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software in the 1990s.

In 1997 is was adopted by the Object Management Group (OMG), and has been managed by this organization ever since. In 2000 the Unified Modeling Language was accepted by the International Organization for Standardization (ISO) as a standard for modeling software-intensive systems.

Overview

A collage of UML diagrams.

Although originally intended for object-oriented design documentation, the Unified Modeling Language (UML) has been extended to cover process-oriented design documentation, and now 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.

The Unified Modeling Language (UML) offers a standard way to visualize a system's architectural blueprints, including elements such as:

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.

History

History of object-oriented methods and notation.

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

Before UML 1.x

After Rational Software Corporation hired James Rumbaugh from General Electric in 1994, the company became the source for two of the most popular object-oriented modeling approaches of the day: Rumbaugh's Object-modeling technique (OMT) and Grady Booch's method known as 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".

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/

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

UML 2.x

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.

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. UML 2.4.1 was formally released in August 2011. UML 2.5 was released in October 2012 as an "In process" version and has yet to become formally released.

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. The UML Diagram Interchange that defines how UML 2 diagram layouts are exchanged

The current versions of these standards follow: UML Superstructure version 2.4.1, UML Infrastructure version 2.4.1, OCL version 2.3.1, and UML Diagram Interchange version 1.0.

It has been noted that UML 2.x is large by Ivar Jacobson a co-architect of UML who felt that the application of intelligent agents to the problem was worth considering.

Design/Usage

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, such as IBM Rational Unified Process (RUP). Others include Abstraction Method and Dynamic Systems Development Method.

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 model also contains documentation that drives the model elements and diagrams (such as written use cases).

UML diagrams represent two different views of a system model:

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

Diagrams overview

UML diagram types
Structural UML diagrams
Behavioral UML diagrams

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:

Hierarchy of UML 2.2 Diagrams, shown as a class diagram.
Hierarchy of UML 2.2 Diagrams, shown as a 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.

A comment or note explaining usage, constraint, or intent is allowed in a UML diagram.

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.

  • Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.
  • Component diagram: describes 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: describes 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 an example modeled system at a specific time.
  • Package diagram: describes 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 <<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype. The extension relation (solid line with closed, filled arrowhead) indicates what metamodel element a given stereotype is extending.

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.

  • Activity diagram: describes the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
  • UML state machine diagram: describes the states and state transitions of the system.
  • Use Case Diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.

Interaction diagrams

Interaction diagrams, a subset of behavior 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: provides an overview 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: 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.

Meta modeling

Illustration of the Meta-Object Facility.
Main article: Meta-Object Facility

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 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 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, the model that 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 instance of the system.

Beyond the M3-model, the Meta-Object Facility describes the means to create and manipulate models and metamodels by defining Common Object Request Broker Architecture (CORBA) interfaces that describe those operations. Because of the similarities between the Meta-Object Facility M0-model and UML structure models, Meta-Object Facility metamodels are usually modeled as UML class diagrams. A supporting standard of the Meta-Object Facility is XMI, which defines an XML-based exchange format for models on the M3-, M2-, or M1-Layer.

See also

Screenshot of Umbrello UML Modeller.

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. Marc Hamilton (1999) Software Development: A Guide to Building Reliable Systems p.48
  2. Satish Mishra (1997). "Visual Modeling & Unified Modeling Language (UML) : Introduction to UML". Rational Software Corporation. Accessed 9 November 2008.
  3. Grady Booch, Ivar Jacobson & James Rumbaugh (2000) OMG Unified Modeling Language Specification, Version 1.3 First Edition: March 2000. Retrieved 12 August 2008.
  4. "OMG Unified Modeling Language (OMG UML), Superstructure. Version 2.4.1". Object Management Group. Retrieved 28 March 2013.
  5. Andreas Zendler (1997) Advanced Concepts, Life Cycle Models and Tools for Objeckt-Oriented Software Development. p.122
  6. Objectory AB, known as Objectory System, was founded in 1987 by Ivar Jacobson. In 1991, It was acquired and became a subsidiary of Ericsson.
  7. "UML Specification version 1.1 (OMG document ad/97-08-11)". Omg.org. Retrieved 22 September 2011.
  8. "UML 2.0". Omg.org. Retrieved 22 September 2011.
  9. "UML". Omg.org. Retrieved 22 September 2011.
  10. "UML". Omg.org. Retrieved 21 February 2012.
  11. "UML". Omg.org. Retrieved 7 August 2013.
  12. OMG. "Catalog of OMG Modeling and Metadata Specifications". Retrieved 21 February 2012.
  13. "Ivar Jacobson on UML, MDA, and the future of methodologies" (video of interview, transcript available), 24 October 2006. Retrieved 2009-05-22
  14. John Hunt (2000). The Unified Process for Practitioners: Object-oriented Design, UML and Java. Springer, 2000. ISBN 1-85233-275-1. p.5.door
  15. Jon Holt Institution of Electrical Engineers (2004). UML for Systems Engineering: Watching the Wheels IET, 2004, ISBN 0-86341-354-4. p.58
  16. UML Superstructure Specification Version 2.2. OMG, February 2009.
  17. Iman Poernomo (2006) "The Meta-Object Facility Typed" in: Proceeding SAC '06 Proceedings of the 2006 ACM symposium on Applied computing. pp. 1845-1849

Further reading

External links

Unified Modeling Language
Actors
Concepts
Object oriented
Structure
Behavior
Relationships
Extensibility
Other
Diagrams
Structure
Behaviour
Interaction
Derived languages
Other topics
Software engineering
Fields
Concepts
Orientations
Models
Developmental
Other
Languages
Related fields
ISO standards by standard number
List of ISO standards – ISO romanizations – IEC standards
1–9999
10000–19999
20000–29999
30000+

Categories:
Unified Modeling Language: Difference between revisions Add topic