Unified Modeling Language
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, representing organizational structure, and systems engineering modeling.
As discussed here, the UML is an open method used to specify, visualize, construct, and document the artifacts of an object-oriented software-intensive system under development. The UML represents a compilation of best engineering practices that have proven to be successful in modeling large, complex systems, especially at the architectural level.
History
UML subsumes the concepts of several software development methods, including Booch, OMT, OOSE, Class-Relation and OOram. The idea is to support these methods by fusing their notation into a single, common, usable modeling language. UML is useful in a variety of engineering problems, from single process, single user applications to concurrent, distributed systems.
UML has become an industry standard, created under the auspices of the Object Management Group (OMG). OMG called for information on object-oriented methodologies, information that would shape a rigorous software modeling language. Many industry leaders responded in earnest to help create the standard.
Different modeling aspects
There are three prominent aspects of the modeled system that are handled by UML: the Functional Model, the Object Model and the Dynamic 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 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.
RUP
UML is not a method and does not force one, however it is recommended by the Rational Unified Process created by the Rational Software Corporation. Other development methods such as the Dynamic Systems Development Method also use UML techniques.
UML concepts
UML uses the following concepts:
- There is a multiplicity notation which corresponds to Database modeling cardinality, eg: 1, 0..1, 1..*
- 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.
Specification versions
There are several versions of UML specification. The current official version is UML 2.0. According to the OMG web site (http://www.uml.org/#UML2.0):
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 (http://www.omg.org/cgi-bin/doc?ptc/2004-10-02) 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 (http://www.omg.org/technology/documents/formal/uml.htm).
UML Diagram types
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. 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.
Two forms of interaction among use cases are part of the UML technique. The OMG standard describes graphical notation for these interactions. 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.
In another form of interaction, a given use case may extend another. In this situation, the behavior of the second use case is added to the entire behavior of the first.
Class Diagram
This diagram describes the structure of a simple Restaurant System. UML shows Inheritance relationships with a triangle; and containers with diamond shape. Additionally, the role of the relationship may be specified as well as the cardinality. The Restaurant System has any number of Food dishes(*), with one Kitchen(1), a Dining Area(contains), and any number of staff(*). All of these objects are associated to one Restaurant.
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)
Above is the collaboration diagram of the (simple) Restaurant System. Notice how you can follow the process from object to object, according to the outline below:
- 1. Order Food
- 1.1 Order Food
- 2. Serve Wine
- 3 Pickup
- 3.1 Serve Food
- 4 Pay
- 5.Not pay
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.
Statechart Diagram
See Harel Statechart.
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.
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.
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.
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 describe Business Extensions in Business Modeling with UML[1] (http://www.allaboutall.info/article/Unified_Modeling_Language#endnote_Penker).
Ovidiu S. Noran at the Griffith University compares UML and IDEF in Business Modelling: UML vs. IDEF (http://www.cit.gu.edu.au/~noran/Docs/UMLvsIDEF.pdf).
Peter Coad et al. have also suggested a small set of UML color standards in their book Java Modeling In Color With UML[2] (http://www.allaboutall.info/article/Unified_Modeling_Language#endnote_Coad).
See also
References
- ^ Magnus Penker, Hans-Erik Eriksson: Business Modeling with UML, John Wiley & Sons Inc., ISBN 0-471-29551-5
- ^ Peter Coad, Eric Lefebvre, Jeff De Luca: Java Modeling In Color With UML: Enterprise Components and Process, Prentice Hall, 1999, ISBN 0-130-11510-X
- Robert Cecil Martin: UML for Java Programmers, Prentice Hall, 2003, ISBN 0-13-142848-9
External links
| 
