Jump to content

Unified Modeling Language

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 199.181.134.220 (talk) at 20:40, 8 November 2005 (→History). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Unified Modeling Language (UML) is a non-proprietary, object modeling and specification language used in software engineering.

UML is not restricted to modeling software. As a graphical notation, UML can be used for modeling hardware (engineering systems) and is commonly used for business process modeling, systems engineering modeling, and representing organizational structure.

UML was designed to be used to specify, visualize, construct, and document the artifacts of an object-oriented software-intensive system under development. It represents an integrated compilation of best engineering practices that have proven to be successful in modeling large, complex systems, especially at the architectural level.

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 Grady and Jim 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 in Rational, a team of experts representing many companies were represented to submit their Unified Modeling Language (UML) proposal to OMG. The team, called the UML Partners, included Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, 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, 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.

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. The current standard is UML 2.0. Many industry firms have now contributed to the standard. 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 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 interange were yet to be completed and ratified as of November 2005.

Different modeling aspects

There are three prominent aspects of the modeled system that are handled by UML:

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 Statechart Diagrams.

Models vs. diagrams

It is important to distinguish between a UML model and a UML diagram or set of diagrams. A diagram is a graphical representation of the information in the model. The model exists independently. The model also contains a "semantic backplane" - textual documentation such as written use cases that drive the model elements and diagrams.

XMI is an XML-based format for exchanging models among UML tools. Diagrams can also be represented using the Diagram Interchange (DI, XMI[DI]) standard, but since it is relatively new very few tools support it.

A graphical notation

UML uses a graphical notation which has text equivalents in Java and other object-oriented languages, and also equivalents in high-level ontology languages which are discussed elsewhere. To show the degree of development of this language, it is possible to state concepts such as political processes in UML notation. Thus, it is possible to translate these schemas into executable programming.

Methods

UML is not a method by itself, however it was designed to be compatbile with the leading object-oriented 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.

UML concepts

UML uses the following concepts:

  • There are specialized classes for common uses, such as Role, Use Case
  • The concept of a stereotype is built-in to the language. It qualifies the symbol it is attached to.

Object Relationships

In a class diagram, UML uses the following Object Relationships:

Specification versions

There are several versions of UML specification. The crrent official version is UML 2.0. According to he OMG web site:

Adoption of the UML 2.0 Superstructure is complete - No further technical work is being done; in fact the Superstructure specification has been stable since it took its adopted form in October, 2004.

The final UML 2.0 specification is still in the editing phase, and has not been added to OMG's formal specification library. Most modeling tools in use do not yet fully support 2.0, or only support earlier versions, such as UML 1.5.

UML Diagram types

Hierarchy of UML 2.0 Diagrams

In UML 2.0 there are 13 types of diagrams. To understand them, it is sometimes useful to categorize them hierarchically into two categories: #Structure Diagrams (i.e., Class, Component, Object, Composite Structure, Deployment, and Package Diagrams) that emphasize what things must be in the system being modeled and #Behavior Diagrams (i.e., Activity, Use Case, and State Machine Diagrams) that emphasize what must happen in the system being modeled. Within the category of Behavior Diagrams there is a subcategory of #Interaction Diagrams (i.e., Sequence, Communication, Interaction Overview, and Timing Diagrams).

Other relationships among the diagrams exist, e.g., the Protocol State Machine is a kind of State Machine, and is sometimes given its own diagram type. To some an Object Diagram is a Class Diagram that happens to only have Objects — its separate existence is more for historical continuity than for logical need. And because of their shared notational mechanisms, an Interaction Overview Diagram can be considered a type of Activity Diagram. Similiarly a Use Case Diagram can be considered a type of Class Diagram because of their commmon notational elements.

Historically, UML has not strictly enforced the restrictions on diagrams, allowing notation from one diagram to appear on almost any other. While this flexibility has been partially restricted in UML 2.0, the boundaries between the various kinds of diagram types are still not strictly enforced.

Structure Diagrams

Class Diagram

The Class Diagram describes the structure of a system. UML has four object relationships:

Inheritance
The graphical representation of inheritance (also generalization or IS-A relationship) shows a triangle shape on the base class end of the tree of lines that interconnect one or more derived classes to their base class.
Aggregation and Composition
Aggregation and Composition are both sub-variants of the HAS-A relationship.
Aggregation occurs when a class is formed as a collection or container of other classes without a strong life cycle dependency of their instances. Its graphical representation is a clear diamond shape on the containing class end of the tree of lines that interconnect contained classes to the containing class.
Composition — in contrast — connotes a strong life cycle between objects of the container class and objects of the contained classes: objects of the contained classes cannot exist without the object that contains them (an instance of the container class). The graphical representation for this variant is a black diamond shape on the containing class end of the tree of lines that interconnect contained classes to the containing class.
Association / Multiplicity / Directed Association / Reflexive Association
Realization

Additionally, the role of the relationship may be specified as well as the cardinality.

Every class can have attributes/properties shown with at least their name, and can also show their type, initial value and other properties. It can also have operations/methods with at least their name, and can also show their parameters and return types.

Their visibility can be displayed as: 

   + Stands for public
   # Stands for protected
   - Stands for private

References: [1] [2] [3] [4] [5] [6] [7] [8]

Component Diagram

Object Diagram

Composite Structure (UML 2.0)

Deployment Diagram

Deployment diagrams serve to model the hardware used in system implementations and the associations between those components. The elements used in deployment diagrams are nodes (shown as a cube), components (shown as a rectangular box, with two rectangles protruding from the left side) and associations.

This deployment diagram shows the hardware used in a small office network. The application server (node) is connected to the database server (node) and the database client (component) is installed on the application server. The workstation is connected (association) to the application server and to a printer.

Package Diagram

Behavior Diagrams

Activity Diagram

Activity diagrams represent the business and operational workflows of a system. An Activity diagram is a variation of the state diagram where the "states" represent operations, and the transitions represent the activities that happen when the operation is complete.

This activity diagram shows the actions that take place when completing a (web) form. The user starts by filling out the form, then it is checked; the result of the check determines if the form has to be filled out again or if the activity is completed.

Use Case Diagram

The OMG defines a graphical notation for use cases, but it refrains from defining any written format for describing use cases in detail. Many people suffer under the misapprehension that a use case is its graphical notation. In fact, the true value of a use case lies in two areas.

The first is the written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems.

The second is the position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team.

It is common practice to create supplementary specifications to capture requirement details that lie outside the scope of use case descriptions. Examples of these topics include performance, scale/management issues, or standards compliance.

This diagram describes the functionality of a simplistic Restaurant System. Use cases are represented by ovals and the Actors are represented by stick figures. The Patron actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef actor can Cook Food. Note that both the Patron and the Cashier are required to Pay for Food. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modelled, the actors are not.

Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case.

Three major relationships among use cases are part of the UML technique. The OMG standard describes graphical notation for these relationships. In one form of interaction, a given use case may include another. The first use case often depends on the outcome of the included use case. This is useful for extracting truely common behaviors from several use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label <<include>>.

In another form of interaction, a given use case (the extension) may extend another (the extended). This relationship indicates that the behavior of the extention use case may be inserted in the extended use case under some condition. The notation is a dashed arrow from the extension to the extended use case, with the label <<extend>>.

In the third form of relationship among use cases, a generaliation/specialization relationship exists. A given use case may be a specialized form of an existing use case. The notaiton is a solid line ending in a hollow triangle drawn from the specialized to the more general use case.

Statechart Diagram

See Harel Statechart.

Interaction Diagrams

Sequence Diagram

This UML 1.x diagram describes the sequences of messages of the (simple) Restaurant System. This diagram represents a Patron ordering food and wine; drinking wine then eating the food; finally paying for the food. The dotted lines extending downwards indicate the timeline. The arrows represent messages (stimuli) from an actor or object to other objects. For example, the Patron sends message 'pay' to the Cashier. Half arrows indicate asynchronous method calls.

The UML 2.0 Sequence Diagram supports similar notation to the UML 1.x Sequence Diagram with added support for modeling variations to the standard flow of events.

Collaboration Diagram / Communication Diagram (UML 2.0)

A Collaboration diagram models the interactions between objects in terms of sequenced messages. Collaboration diagrams represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.

Collaboration and sequence diagrams describe similar information, and as typically implemented, can be transformed into one another without difficulty.

However, collaboration diagrams use the free-form arrangement of objects and links as used in Object diagrams. In order to maintain the ordering of messages in such a free-form diagram, messages are labeled with a chronological number and placed near the link the message is sent over. Reading a Collaboration diagram involves starting at message 1.0, and following the messages from object to object.

In UML 2.0, the Collaboration diagram has been simplified and renamed the Communication diagram.

Interaction Overview Diagram (UML 2.0)
Timing Diagram (UML 2.0)

Criticisms of UML

Although UML is a widely recognized and used standard, it is criticized for having imprecise semantics, which causes its interpretation to be subjective and therefore difficult for the formal test phase. This means that when using UML, users should provide some form of explanation of their models. 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.

At the same time, UML is often considered to have become too bloated, and fine-grained in many aspects. Details which are best captured in source code are attempted to be captured using UML notation. 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 comprehensive scope of UML 2.0 is appropriate for model-driven architecture.)

A third problem which leads to criticism and dissatisfaction is the large-scale adoption of UML by people without the required skills, often when management forces UML upon them.

Quotes

"The code is the design" -- Jack W. Reeves, a critic of UML, in a C++ Journal essay entitled 'What Is Software Design? (1992) [9] [10]

Extensions to UML

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". [11]

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

See also

References

  • . ISBN 0-13-142848-9. {{cite book}}: Missing or empty |title= (help); Unknown parameter |Author= ignored (|author= suggested) (help); Unknown parameter |Publisher= ignored (|publisher= suggested) (help); Unknown parameter |Title= ignored (|title= suggested) (help); Unknown parameter |Year= ignored (|year= suggested) (help)
  • . ISBN 0-471-29551-5. {{cite book}}: Missing or empty |title= (help); Unknown parameter |Author= ignored (|author= suggested) (help); Unknown parameter |Publisher= ignored (|publisher= suggested) (help); Unknown parameter |Title= ignored (|title= suggested) (help); Unknown parameter |Year= ignored (|year= suggested) (help)
  • . ISBN 0-130-11510-X. {{cite book}}: Missing or empty |title= (help); Unknown parameter |Author= ignored (|author= suggested) (help); Unknown parameter |Publisher= ignored (|publisher= suggested) (help); Unknown parameter |Title= ignored (|title= suggested) (help); Unknown parameter |Year= ignored (|year= suggested) (help)


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.

Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Unified_Modeling_Language&oldid=27754188"