Category Archives: UML Modeling

The Unified Modeling Language allows for object oriented analysis and design, also called OOA/OOD. These articles provide explanations of how, when, or why to use UML models as part of business requirements management. UML models often enhance the requirements definition process, improve communication of requirements, and simplify the transition from requirements to design.

Uncovering Requirements With UML Class Diagrams Part 5


In this article, we build on our ability to represent straight forward business relationships in UML class diagrams. These relationships describe how two objects are related to each other. Representing relationships in class diagrams helps us to better understand the domain and helps us to uncover hidden requirements. Occasionally, we have to deal with more complex relationships that involve more than two objects to properly describe. This does not happen as frequently, but when it does, our modeling efforts are more likely to uncover overlooked requirements. In this article we learn how to describe relationships that involve more than two objects.

Continue reading Uncovering Requirements With UML Class Diagrams Part 5

Uncovering Requirements With UML Class Diagrams Part 4


The hardest part of gathering requirements effectively is uncovering the requirements that people don’t immediately tell you. You have to ask the right questions. And one of the best ways to find the right questions to build a class diagram of the business domain. This article continues our introduction to class diagrams.

Continue reading Uncovering Requirements With UML Class Diagrams Part 4

Uncovering Requirements With UML Class Diagrams Part 3


UML Class Diagrams are very effective at uncovering requirements. They give us insight into how the business thinks about objects and their relationships. And from that understanding, we think to ask questions we might otherwise overlook. In this part of our series, we look at how to represent when one object is made up of other objects. The two types of relationships we explore are composition and aggregation.

Continue reading Uncovering Requirements With UML Class Diagrams Part 3

Uncovering Requirements With UML Class Diagrams Part 2

front loader

We continue our exploration of UML Class Diagrams with this article that explores how to represent basic business relationships in a class diagram. Drawing these relationships can dramatically clarify requirements documents. Using a class diagram to supplement other requirements documents provides for a centralized reference that enables a shared understanding of the problem domain. That understanding prevents mistakes in interpreting requirements.

Continue reading Uncovering Requirements With UML Class Diagrams Part 2

Uncovering Requirements With UML Class Diagrams Part 1


UML Class Diagrams can be used not only for documenting software design, but for documenting software requirements. One of the challenges in writing clear, unambiguous requirements is being precise about what a particular word means. This is especially true with symbolic terms like “quote” or “customer” – where everyone knows what they mean – but they mean different things to different people.

Continue reading Uncovering Requirements With UML Class Diagrams Part 1

How To Draw an Asynchronous Process


Documenting processes is something most business analysts have to do. The goal of documenting the process is to communicate requirements. By establishing a shared understanding of the process, you can establish the context for the requirements. Easy processes are easy to draw and understand. When documenting a more complex process, you need to provide the same clarity and consistency. In this article we show how to document asynchronous process steps to maximize the clarity of the documentation.

Continue reading How To Draw an Asynchronous Process

APR: Updated Domain Model

model steamboat

More iteration in our agile project. In this article, we make several updates to the domain model (UML class diagram) based upon discussions on all of the articles in the series. More than a couple dozen in the last day. Thanks to everyone who has helped with feedback and encouragement – just awesome!

Continue reading APR: Updated Domain Model

APR: Domain Model – UML Class Diagram

model steamboat

Along with design sketches and requirements, as part of the concurrent design and requirements development for our agile project, we have created a UML class diagram representing the domain. This iterative process allows us to incorporate the benefits of each perspective rapidly with the others in our race to prototype a working site.

This article reviews the domain model.

Continue reading APR: Domain Model – UML Class Diagram

APR: Mixing It Up With Design And Requirements

prototyping flow
With a definition of the important use cases for our agile project, we can move to the logical next step – which is what exactly?


Continue reading APR: Mixing It Up With Design And Requirements

How To Use UML Statechart Substates


UML Statecharts can be very effective modeling tools for describing systems and software requirements. They provide a clear framework for identifying business rules. The same business rules often apply to multiple states – defining a commonality for those states. There is an element called a substate in UML statecharts that can be used to make it more obvious that a particular business rule applies to multiple states.

A Simple UML Statechart

We documented business rules with a UML statechart in a previous article, that describes the possible states of a customer order. Those states are saved, placed, charged, shipped, delivered, and cancelled.

uml statechart 1
We defined a series of transitions and talked about the rules associated with those transitions. Imagine that the business rules changed, and customers were allowed to cancel orders even after they had been shipped (as long as they hadn’t been delivered).

Commonality In UML Statechart States

This could serve as an indication that there is a relevant commonality between the states: placed, charged, and shipped. All of these states represent an order that is “in process.” The customer has officially asked us for something, we have not delivered it yet (from the customer’s perspective), and the order has not been cancelled.

You can think of our states as having a hierarchy. You can create a state called “In Process” that generalizes the three states placed, charged, and shipped. By introducing this notion of generalization, we create “substates.”
uml statechart state hierarchy
UML Statecharts allow you to draw these substates inside of a larger superstate. The superstate is drawn with a rounded-corner rectangle, like the other states – but it includes a horizontal bar at the top that allows you to easily show the name of the superstate, separated from the information describing the substates.

UML statechart substate
Notice that the transitions between the substates are the same ones that were defined when the “In Process” superstate did not exist. You can have transitions between substates, and to and from substates to other states that are outside of the superstate. You can also have transitions that go directly to or come directly from the superstate.

uml statechart 2
Notice the single “cancel order” transition that comes from the superstate, In Process. This represents that the transition can be from any of the substates of In Process. The “deliver order” transition can only come from the Delivered substate. The transition “submit order” goes directly from the Saved state to the Placed substate.


The technique of using substates within UML statecharts allows for cleaner documentation when there are notions that present commonality (like business rules) that justify generalizing multiple states into a single state. This technique allows you to reduce the number of business rules that you must maintain, and makes the diagram easier to read.