What is UML?
The Unified Modeling Language (UML) was created to forge a common, semantically and syntactically rich visual modeling language for the architecture, design, and implementation of complex software systems both structurally and behaviorally. UML has applications beyond software development, such as process flow in manufacturing.
It is analogous to the blueprints used in other fields, and consists of different types of diagrams. In the aggregate, UML diagrams describe the boundary, structure, and the behavior of the system and the objects within it.
UML is not a programming language but there are tools that can be used to generate code in various languages using UML diagrams. UML has a direct relation with object-oriented analysis and design.
UML and its role in object-oriented modeling and design
There are many problem-solving paradigms or models in Computer Science, which is the study of algorithms and data. There are four problem-solving model categories: imperative, functional, declarative and object-oriented languages (OOP). In object-oriented languages, algorithms are expressed by defining ‘objects’ and having the objects interact with each other. Those objects are things to be manipulated and they exist in the real world. They can be buildings, widgets on a desktop, or human beings.
Object-oriented languages dominate the programming world because they model real-world objects. UML is a combination of several object-oriented notations: Object-Oriented Design, Object Modeling Technique, and Object-Oriented Software Engineering.
UML uses the strengths of these three approaches to present a more consistent methodology that's easier to use. UML represents best practices for building and documenting different aspects of software and business system modeling.
The history and origins of UML
Where and how did UML begin? Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980s as various methodologists experimented with different approaches to object-oriented analysis and design. The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994. Many users of OO methods had trouble finding complete satisfaction in any one modeling language, fueling the "method wars."
By the mid-1990s, new iterations of these methods began to appear and to incorporate each other’s techniques. This resulted in the emergence of a few clearly prominent methods.
Software engineers and other experts needed a simplified and consistent way to model systems, but new languages were cropping up at a rapid pace. UML itself was developed in late 1994, when the two creators of popular methodologies teamed up. Grady Booch and Jim Rumbaugh of Rational Software Corporation worked to unify the Booch and OMT (Object Modeling Technique) methods, and in 1995, Ivar Jacobson joined their endeavor. Their combined method was known as OOSE Method 1—Object-Oriented Software Engineering.
‘The Three Amigos’ of software engineering as they were known, had evolved other methodologies. They teamed up to provide clarity for programmers by creating new standards. The collaboration between Grady, Booch, and Rumbaugh made all three methods stronger and improved the final product.
The efforts of these thinkers resulted in the release of the UML 0.9 and 0.91 documents in 1996. It soon became clear that several organizations, including Microsoft, Oracle, and IBM saw UML as critical to their own business development. They, along with many other individuals and companies, established resources that could develop a full-fledged modeling language. The Three Amigos published The Unified Modeling Language User Guide in 1999, and an update which includes information about UML 2.0 in the 2005 Second Edition.
OMG: It has a different meaning
According to their website, The Object Management Group® (OMG®) is an international, open membership, not-for-profit technology standards consortium, founded in 1989. OMG standards are driven by vendors, end-users, academic institutions and government agencies. OMG Task Forces develop enterprise integration standards for a wide range of technologies and an even wider range of industries. OMG’s modeling standards, including the UML and Model Driven Architecture® (MDA®), enable powerful visual design, execution and maintenance of software and other processes.
OMG oversees the definition and maintenance of UML specifications. This oversight gives engineers and programmers the ability to use one language for many purposes during all phases of the software lifecycle for all system sizes.
The purpose of UML according to OMG
The OMG defines the purpose of the UML as:
- Providing system architects, software engineers, and software developers with tools for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes.
- Advancing the state of the industry by enabling object visual modeling tool interoperability. However, to enable meaningful exchange of model information between tools, agreement on semantics and notation is required.
UML meets the following requirements:
- Setting a formal definition of a common Meta-Object Facility (MOF)-based meta-model that specifies the abstract syntax of the UML. The abstract syntax defines the set of UML modeling concepts, their attributes and their relationships, as well as the rules for combining these concepts to construct partial or complete UML models.
- Providing a detailed explanation of the semantics of each UML modeling concept. The semantics define, in a technology independent manner, how the UML concepts are to be realized by computers.
- Specifying the human-readable notation elements for representing the individual UML modeling concepts as well as rules for combining them into a variety of different diagram types corresponding to different aspects of modeled systems.
- Defining ways in which UML tools can be made compliant with this specification. This is supported (in a separate specification) with an XML-based specification of corresponding model interchange formats (XMI) that must be realized by compliant tools.
UML and data modeling
The UML is popular among programmers, but isn’t generally used by database developers. One reason is simply that the UML creators did not focus on databases. Despite this, the UML is effective for high-level conceptual data modeling, and it can be used in different types of UML diagrams. You can find information about layering of an object-oriented class model onto a relational database in this article about Database Modeling in UML.
Updates in UML 2.0
UML is being continually refined. UML 2.0 extends UML specs to cover more aspects of development, including Agile. The goal was to restructure and refine UML so that usability, implementation, and adaptation are simplified. Here are some of the updates to UML diagrams:
- Greater integration between structural and behavior models.
- Ability to define hierarchy and breakdown a software system into components and sub-components.
- UML 2.0 raises the number of diagrams from 9 to 13.
UML terms glossary
Familiarize yourself with the UML vocabulary, with this list culled from the UML 2.4.1 document intended to help OMG non-members understand commonly used terms.
- Abstract syntax compliance Users can move models across different tools, even if they use different notations
- Common Warehouse Metamodel (CWM) Standard interfaces that are used to enable interchange of warehouse and business intelligence metadata between warehouse tools, warehouse platforms and warehouse metadata repositories in distributed heterogeneous environments
- Concrete syntax compliance Users can continue to use a notation they are familiar with across different tools
- Core In the context of UML, the core usually refers to the "Core package" which is a complete metamodel particularly designed for high reusability
- Language Unit Consists of a collection of tightly coupled modeling concepts that provide users with the power to represent aspects of the system under study according to a particular paradigm or formalism
- Level 0 (L0) Bottom compliance level for UML infrastructure - a single language unit that provides for modeling the kinds of class-based structures encountered in most popular object-oriented programming languages
- Meta Object Facility (MOF) An OMG modeling specification that provides the basis for metamodel definitions in OMG's family of MDA languages
- Metamodel Defines the language and processes from which to form a model
- Metamodel Constructs (LM) Second compliance level in the UML infrastructure - an extra language unit for more advanced class-based structures used for building metamodels (using CMOF) such as UML itself. UML only has two compliance levels
- Model Driven Architecture (MDA) An approach and a plan to achieve a cohesive set of model-driven technology specifications
- Object Constraint Language (OCL) A declarative language for describing rules that apply to Unified Modeling Language. OCL supplements UML by providing terms and flowchart symbols that are more precise than natural language but less difficult to master than mathematics
- Object Management Group (OMG) Is a not-for-profit computer industry specifications consortium whose members define and maintain the UML specification
- UML 1 First version of the Unified Modeling Language
- Unified Modeling Language (UML) A visual language for specifying, constructing, and documenting the artifacts of systems
- XMI An XML-based specification of corresponding model interchange formats
View the complete MOF document
Download the complete UML 2.4.1 Infrastructure document.
Modeling concepts specified by UML
System development focuses on three overall different system models:
- Functional: These are Use Case diagrams, which describe system functionality from the point of view of the user.
- Object: These are Class Diagrams, which describe the structure of the system in terms of objects, attributes, associations, and operations.
- Dynamic: Interaction Diagrams, State Machine Diagrams, and Activity Diagrams are used to describe the internal behavior of the system.
These system models are visualized through two different types of diagrams: structural and behavioral.
Object-oriented concepts in UML
The objects in UML are real world entities that exist around us. In software development, objects can be used to describe, or model, the system being created in terms that are relevant to the domain. Objects also allow the decomposition of complex systems into understandable components that allow one piece to be built at a time.
Here are some fundamental concepts of an object-oriented world:
- Objects Represent an entity and the basic building block.
- Class Blue print of an object.
- Abstraction Behavior of a real world entity.
- Encapsulation Mechanism of binding the data together and hiding them from outside world.
- Inheritance Mechanism of making new classes from existing one.
- Polymorphism It defines the mechanism to exists in different forms.
Types of UML diagrams
UML uses elements and associates them in different ways to form diagrams that represent static, or structural aspects of a system, and behavioral diagrams, which capture the dynamic aspects of a systems.
Structural UML diagrams
- Class Diagram The most commonly used UML diagram, and the principal foundation of any object-oriented solution. Classes within a system, attributes and operations and the relationship between each class. Classes are grouped together to create class diagrams when diagramming large systems.
- Component Diagram Displays the structural relationship of software system elements, most often employed when working with complex systems with multiple components. Components communicate using interfaces.
- Composite Structure Diagram Composite structure diagrams are used to show the internal structure of a class.
- Deployment Diagram Illustrates system hardware and its software. Useful when a software solution is deployed across multiple machines with unique configurations.
- Object Diagram Shows the relationship between objects using real world examples and illustrate how a system will look at any given time. Because data is available within objects, they can be used to clarify relationships between objects.
- Package Diagram There are two special types of dependencies defined between packages: package import and package merge. Packages can represent the different levels of a system to reveal the architecture. Package dependencies can be marked to show the communication mechanism between levels.
Behavioral UML diagrams
- Activity Diagrams Graphically represented business or operational workflows to show the activity of any part or component in the system. Activity diagrams are used as an alternative to State Machine diagrams.
- Communication Diagram Similar to sequence diagrams, but the focus is on messages passed between objects. The same information can be represented using a sequence diagram and different objects.
- Interaction Overview Diagram There are seven types of interaction diagrams, and this diagram shows the sequence in which they act.
- Sequence Diagram Shows how objects interact with each other and the order of occurrence. They represent interactions for a particular scenario.
- State Machine Diagram Similar to activity diagrams, they describe the behavior of objects that behave in varying ways in their current state.
- Timing Diagram Like Sequence Diagrams, the behavior of objects in a given time frame are represented. If there is a single object, the diagram is simple. With more than one object, interactions of objects are shown during that particular time frame.
- Use Case Diagram Represents a particular functionality of a system, created to illustrate how functionalities relate and their internal/external controllers (actors).
How to create a UML diagram: Tutorials and examples
To illustrate how to create different types of UML diagrams, try one or all of these tutorials to guide you through the process of drawing both structural and behavioral diagrams.
Structural Diagram Tutorial Examples
Class diagrams represent the static structures of a system, including its classes, attributes, operations, and objects. A class diagram can display computational data or organizational data in the form of implementation classes and logical classes, respectively. There may be overlap between these two groups.
- Classes are represented with a rectangular shape that is split into thirds. The top section displays the class name, while the middle section contains the class' attributes. The bottom section features the class operations (also known as methods).
- Add class shapes to your class diagram to model the relationship between those objects. You may need to add subclasses, as well.
- Use lines to represent association, inheritance, multiplicity, and other relationships between classes and subclasses. Your preferred notation style will inform the notation of these lines.
Component diagrams show how components are combined to form larger components or software systems. These diagrams are meant to model the dependencies of each component in the system. A component is something required to execute a stereotype function. A component stereotype may consist of executables, documents, database tables, files, or library files.
- Represent a component with a rectangle shape. It should have two small rectangles on the side, or feature an icon with this shape.
- Add lines between component shapes to represent the relevant relationships.
A deployment diagram models the physical deployment and structure of hardware components. Deployment diagrams demonstrate where and how the components of a system will operate in conjunction with each other.
- When drawing a deployment diagram, use the same notation that you use for a component diagram.
- Use a 3-D cube to model a node (which represents a physical machine or virtual machine).
- Label the node in the same style that is used for sequence diagrams. Add other nodes as needed, then connect with lines.
Behavioral Diagram Tutorial Examples
Activity diagrams show the procedural flow of control between class objects, along with organizational processes like business workflows. These diagram are made of specialized shapes, then connected with arrows. The notation set for activity diagrams is similar to those for state diagrams.
- Begin your activity diagram with a solid circle.
- Connect the circle to the first activity, which is modeled with a round-edged rectangle.
- Now, connect each activity to other activities with lines that demonstrate the stepwise flow of the entire process.
- You can also try using swimlanes to represent the objects that perform each activity.
USE CASE DIAGRAM
A use case is a list of steps that define interaction between an actor (a human who interacts with the system or an external system) and the system itself. Use case diagrams depict the specifications of a use case and model the functional units of a system. These diagrams help development teams understand the requirements of their system, including the role of human interaction therein and the differences between various use cases. A use case diagram might display all use cases of the system, or just one group of use cases with similar functionality.
- To begin a use case diagram, add an oval shape to the center of the drawing.
- Type the name of the use case inside the oval.
- Represent actors with a stick figure near the diagram, then use lines to model relationships between actors and use cases.
Sequence diagrams, also known as event diagrams or event scenarios, illustrate how processes interact with each other by showing calls between different objects in a sequence. These diagrams have two dimensions: vertical and horizontal. The vertical lines show the sequence of messages and calls in chronological order, and the horizontal elements show object instances where the messages are relayed.
- To create a sequence diagram, write the class instance name and class name in a rectangular box.
- Draw lines between class instances to represent the sender and receiver of messages.
- Use solid arrowheads to symbolize synchronous messages, open arrowheads for asynchronous messages, and dashed lines for reply messages.
Lucidchart makes it easy to draw UML diagrams
You can start UML diagramming now with Lucidchart. We make it simple, efficient, and even fun.
- Simple to use Ease of use If you’re making a UML diagram, you clearly know what you’re doing, but we want to make it as easy as possible to get the job done. You’ll save time with Lucidchart’s polished interface and smart drag-and-drop editor.
- Extensive shape library Draw state diagrams, activity diagrams, use case diagrams, and more. With an extensive shape and connector library, you'll find everything you need.
- Fully integrated Lucidchart is fully integrated with Google Apps. Once you get started with Lucidchart, you’ll be able to find us right in your Google Apps productivity suite along with Gmail and Google Drive. Plus, you can use the same login you use for Google.
- Enables collaboration You can easily share your UML diagram with your co-workers, clients, or your boss. Your diagrams can be embedded into a webpage or published as a PDF, and Lucidchart’s presentation mode turns your creation into a great-looking visual aid.
- Visio import/export It’s easy to import and export Visio files so you can save the work you've already done. The whole experience is fast and seamless.