Part 1: UML Overview
UML Diagrams Guide
What is modeling?
Modeling is a way to visualize your software application design and check it against requirements before your team starts to code.
In the same way an architect creates a blueprint before starting construction on a skyscraper, a developer can use modeling diagrams to solidify and test what they are going to create before they start coding.
Mapping out a plan is the first step to any project, and modeling is an essential part of any software project, small or large. For an application to function well, it must be architected to enable scalability, security, and execution.
Using Unified Modeling Language (UML) diagrams, you can visualize and verify the designs of your software systems before code implementation makes changes difficult and expensive to execute.
What is the Unified Modeling Language?
According to the Scope of the latest version of UML 2.5’s specification documentation, “the objective of UML is to provide 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.”
UML itself is not a programming language, though there are tools that can generate code using UML diagrams. UML is a modeling language for designing systems. It was created by combining several object-oriented notations—Object-Oriented Design (i.e., Booch), Object Modeling Technique (OMT), and Object-Oriented Software Engineering (OOSE)—making it a natural fit for object-oriented languages and environments like C++, Java, and C#; however, you can also use it to model non-OO applications in languages like Fortran, VB, or COBOL.
Because UML establishes a standard semantic and syntactic structure, you can use it to model almost any type of application, regardless of your hardware, operating system, programming language, or network. UML allows you to specify, visualize, and document models of software systems both structurally and behaviorally before coding.
History of the UML
UML was developed by Grady Booch, Ivar Jacobson, and James Rumbaugh (aka ‘The Three Amigos’) in the mid-90’s. The initial versions of UML were created by integrating three of the leading object-oriented methods—namely Booch, OMT, and OOSE developed by UML’s founders, respectively. It also incorporated best-practices from modeling language design, object-oriented programming, and architectural description languages. The result of their efforts led to the release of UML 0.9 and 0.91.
In 1996, The Three Amigos led a consortium called the UML Partners to complete the UML specification. The partnership included several important individuals and organizations, including HP, DEC, IBM, and Microsoft. The resulting UML 1.1 was proposed to the Object Management Group (OMG) for standardization and adopted in November 1997. OMG has managed the language ever since.
With the help of an even larger consortium, UML 2.0 was introduced in 2005 and published as an approved standard by the International Organization for Standardization (ISO). After the release of several more versions, the current version, UML 2.5, was released in October 2012 as an “In process” version that was officially released in June 2015.
Benefits of UML
Modeling your software before you build it provides a number of benefits to teams. For one, it helps establish a logical order of a team’s activities. Knowing what artifacts need to be developed helps define the tasks that teams will need to complete. And modeling helps your team establish criteria for monitoring and measuring a project’s products and activities.
While some people might worry that using UML diagrams could lock them into a waterfall style of software development, that isn’t necessarily true. UML diagrams can be created and used at various stages of development, and they can be continuously updated and iterated on.
Other key benefits include:
- Reducing redundancies. Diagrams make it easier for programmers to see redundant code and reuse portions of code that already exist rather than rewriting those functions.
- Simplifying changes. Making changes to diagrams at the start is much easier than reprogramming code later. It saves your team valuable time and money.
- Clarifying ambiguity. You can only go so far with design documentation. In the long run, you’ll need it to communicate with new or far away developers unfamiliar with the history of your product.
Why choose UML specifically?
UML is the most widely used and understood modeling language. UML is, by far, the most popular modeling language used today. That ubiquity is itself a benefit because most developers, regardless of their specialties or work history, will be familiar with at least some UML diagrams. And because they are meant to be understood by any type of programmer, they don’t require the ability to read a certain programming language to be useful.
Three of the most popular UML diagrams will cover most of your modeling needs. Though there are 14 different types of UML diagrams for modeling applications, in practice, developers only use a few to document their software systems. The most common UML diagrams you’ll see and use are class diagrams, sequence diagrams, and use case diagrams. That means knowing how to create and read only 20% of this language will suffice for most of your projects.
Types of UML diagrams
As of UML 2.5, there are now fourteen officially recognized UML diagrams which are split into two main types:
1. Structure diagrams show how the static parts of a system relate to each other. Each element represents a particular concept and may include abstract, real-world, and implementation factors.
2. Behavior diagrams show the dynamic behavior of all objects in a system, including changes to the system over time. Interaction diagrams can be thought of as a subset of behavior diagrams.
There are seven structure diagrams in UML 2.5:
- Class diagrams show the structure of a system as related classes and interfaces with their features, constraints, and relationships.
- Component diagrams show components and the dependencies between them.
- Composite structure diagrams show the internal structure of a classifier and the behavior of collaborations the structure makes possible.
- Deployment diagrams show a system’s various hardware and the software deployed on it.
- Object diagrams show a real-world example of a structure at a specific time.
- Package diagrams show packages and the dependencies between those packages.
- Profile diagrams show custom stereotypes, tagged values, and constraints.
There are also seven behavior diagrams, the last four of which fall under the interaction diagram subset:
- Activity diagrams show business or operational workflows of components in a system.
- Use Case diagrams show how functionalities relate under particular actors.
- State machine diagrams show the states and state transitions of a system.
- Communication diagrams* show the interactions between objects in terms of sequenced messages.
- Interaction overview diagrams* show an overview of the flow of control with nodes that represent interactions or interactions uses.
- Sequence diagrams* show how objects communicate and the sequence of their messages.
- Timing diagrams* show timing constraints of a system in a given time frame.