I’ve seen a lot of questions about Unified Modeling Language (UML) that center around “Is UML still relevant today?” and “How is it used in an Agile environment?”. I will try to address these questions in this blog post.
What is UML?
UML stands for “Unified Modeling Language”. Here is a definition of UML:
” The goal of UML is to provide a standard notation that can be used by all object-oriented methods and to select and integrate the best elements of precursor notations. UML has been designed for a broad range of applications. Hence, it provides constructs for a broad range of systems and activities (e.g., distributed systems, analysis, system design and deployment). “
“In 1994, Jim Rumbaugh, the creator of OMT, stunned the software world when he left General Electric and joined Grady Booch at Rational Corp. The aim of the partnership was to merge their ideas into a single, unified method (the working title for the method was indeed the “Unified Method”). “
Visual Paradigm website
What’s the primary purpose of UML?
The Visual Paradigm website summarizes the primary goals of UML as follows:
- “Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models.
- Provide extensibility and specialization mechanisms to extend the core concepts.
- Be independent of particular programming languages and development processes.
- Provide a formal basis for understanding the modeling language.
- Encourage the growth of the OO tools market.
- Support higher-level development concepts such as collaborations, frameworks, patterns and components.
- Integrate best practices.“
UML is typically used to simplify a lot of written documentation. It provides a visual model of how a system works and how it is designed.
UML is intended to satisfy a broad variety of interests. It consists of a number of different diagram types that show the system from different perspectives. Those diagram types can be grouped into two major categories:
- Structure Diagrams – “Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other.”
- Behavior Diagrams – “Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time”
For further detail on UML diagrams, the Visual Paradigm website is a very good source.
How Does UML Fit Into a Software Development Process?
UML diagrams are heavily-associated with what is called “Big upfront design”. That is typically what is called a “Waterfall process where:
- The requirements for the process, as well as
- The design of the software to satisfy those requirements can be defined in some level of detail upfront prior to the start of the project.
In that kind of environment, UML diagrams are a way of presenting a visual, diagramatic view of what is in the requirements documents and how the design will be implemented and that can be particularly useful for large, complex projects.
UML obviously works best in a sequential Waterfall process as shown here:
In this type of process,
- The requirements definition phase would typically take place first
- Then, UML behavior diagrams might be used to define the most critical behavioral characteristics of the system from a user perspective
- Those diagrams might then serve as input to the design process where the design of the system would be laid out to satisfy those requirements
- Once the design process is complete, UML structure diagrams might be used to define the expected overall structure of the system from a design perspective
- Those diagrams might then serve as input to the development process to implement the design of the system
In this type of environment, the UML diagrams provide two different kinds of value – UML:
- Provides a communications mechanism to summarize the information that is in various project documents. That is useful to transition that information from one phase to the next
- Can also be used for support purposes after the project has been completed. refer back to how the design of the system was created
- Can potentially play a role in defining and standardizing the system architecture of the solution. That can be particularly important in large, complex, enterprise-level projects where it is important to have a clear and consistent architecture for solutions
Is UML Still Relevant Today? What Is the Role of UML in an Agile Development Process?
Many companies are moving to an Agile development process for software development which raises the question: “Is UML still useful in an Agile environment?”. In an Agile environment,
- The requirements for the project and the design of the software are normally not defined in detail prior to the start of the project
- Both the requirements and the design typically evolve and are further extrapolated as the project was in progress
- In an Agile environment, there is also normally much less reliance on formal project documentation
The difficulty of using UML diagrams in that environment should be obvious:
- There is typically insufficient information at the beginning of the project to define the requirements and the design in detail prior to the start of the project
- It might require a lot of effort to continuously update UML diagrams as the project is in progress to reflect any changes
- It raises questions as to who would benefit from maintaining and updating those UML diagrams and how they would benefit from it
The general rule I use for any kind of documentation is that:
- We shouldn’t create documentation for the sake of creating documentation
- Documentation should create some kind of value for someone and
- That value should be sufficient to overcome the costs of creating and maintaining that documentation
Agile is redefining how software is developed and raises some significant questions about “Is UML still relevant today?”.
The value of UML diagrams in an Agile environment is limited and the effort required to continuously update the diagrams as the project is in progress may not be worth the effort. However, there are a couple of reasons why UML diagrams might still be useful:
- Support – There might be some value in having UML diagrams as an aid for supporting the system once development has been completed
- Architecture – There might also be some value in using UML to define and standardize the architecture of the solution
Both of those functions would depend heavily on the complexity of the system, the criticality of the business functionality it provides, and the overall support strategy for the system.
You can find related articles on the topic of “Agile Development” here:
You will find much more detail on this in my Online Agile Project Management Training.