Useful UML Modeling: The Goldilocks Conundrum

Useful UML Modeling: The Goldilocks Conundrum

(Editor’s Note: Welcome to our new series — Useful UML Modeling. The goal of this multi-part series is to get back to basics and help make modeling more practical and useful for you. The Unified Modeling Language (UML) has been around formally for more than a decade. The UML superstructure specification is more than 700 pages long and quite complex. Many texts have been written to try to explain what it all means. And yet many modelers still struggle with the UML, often falling into the same pitfalls as their colleagues. Often this is due to misunderstanding, misuse, or over-simplification of the basic elements of the UML. These articles will approach this topic from a pragmatic, practical (instead of theoretical) point of view.For you who never had the opportunity to learn about UML modeling, we will help you build a solid foundation. For those who have done some modeling, but have been too busy to build a deeper understanding, these brief articles should fit well in your busy schedule. And you modeling experts, the basics are the foundation your expertise is built upon. These articles can refresh those foundational concepts for you. And everyone can learn from other’s real world experiences so you don’t make an embarrassing error on a critical project. )

The Goldilocks Conundrum

Use cases are by far the most commonly used element of the UML. This is also the area where modelers have the most difficulties. Use cases appear to be so simple and easy to use. Remember, as Jim Horning said: “Nothing is as simple as we hope it will be.”

The Basics

A use case represents a series of interactions between your system and an actor, which yields a valuable result to the actor. An actor is a role that a person, system, or other entity plays when interacting with the system. Figure 1 shows these elements in a use case diagram. Figure 1: Use case diagram.

The Problem

Just as Goldilocks could not find suitable sleeping arrangements, modelers often have problems with the abstraction level of a use case. In other words, is it too big? Too small? Once upon a time, at a job interview, the interviewer told me one of his people had created a use case model where every use case was equivalent to an operation on a class. Too small! She was thinking bottom-up, from an implementation point-of-view. Recall that a use case is a series of interactions, not one step. Use cases (a.k.a. system use cases) capture the functionality that the system will provide to the actor. This functionality is specified in the multiple flows of the use case, each of which has multiple steps. On the other hand, when people approach modeling top-down from a business point of view, they may create a use case such as sales (in the retail domain). Too big! Yes, your business may process sales, but that is what your business does, not what your system does. These larger use cases are often referred to as business use cases. System use cases are developed to specify what the system does to support the business use cases.An example of a simple business use case model is shown in Figure 2. You can see these business use cases are quite large. Their scope is that of whole business functions. These use cases are why external people (i.e. business actors) come to your business (i.e. for what your business does, not what your systems do). A Retail Customer wants Customer Service. The Credit Company does Billing. These business use cases typically take a very long time to complete (e.g. Shipping products, especially during the holiday season).

Figure 2: Business use case diagram.

Bottom Line

By comparison, a system use case diagram, shown in Figure 3, depicts its support of part of this business (i.e. processing a sale). Here you see system use cases are smaller in scope than the business use cases. They are shorter in duration (e.g. Assemble Order). In addition, the diagram includes workers inside your business that perform the use cases. Also, a number of the system use cases are typically needed to fulfill a single business use case. Finally, what is not in the system use case diagram? Not everything that the business does will be automated by the system use cases. For example, the actual physical shipping is part of the business function, but is not a system use case (not all operational business activities are automated).

Figure 3: System use case diagram.In summary, there are key characteristics that distinguish business use cases from system use cases.Keeping these characteristics in mind will help you define use cases that are “just right.”

Share the Post:
XDR solutions

The Benefits of Using XDR Solutions

Cybercriminals constantly adapt their strategies, developing newer, more powerful, and intelligent ways to attack your network. Since security professionals must innovate as well, more conventional endpoint detection solutions have evolved

AI is revolutionizing fraud detection

How AI is Revolutionizing Fraud Detection

Artificial intelligence – commonly known as AI – means a form of technology with multiple uses. As a result, it has become extremely valuable to a number of businesses across

AI innovation

Companies Leading AI Innovation in 2023

Artificial intelligence (AI) has been transforming industries and revolutionizing business operations. AI’s potential to enhance efficiency and productivity has become crucial to many businesses. As we move into 2023, several

data fivetran pricing

Fivetran Pricing Explained

One of the biggest trends of the 21st century is the massive surge in analytics. Analytics is the process of utilizing data to drive future decision-making. With so much of

kubernetes logging

Kubernetes Logging: What You Need to Know

Kubernetes from Google is one of the most popular open-source and free container management solutions made to make managing and deploying applications easier. It has a solid architecture that makes

ransomware cyber attack

Why Is Ransomware Such a Major Threat?

One of the most significant cyber threats faced by modern organizations is a ransomware attack. Ransomware attacks have grown in both sophistication and frequency over the past few years, forcing

data dictionary

Tools You Need to Make a Data Dictionary

Data dictionaries are crucial for organizations of all sizes that deal with large amounts of data. they are centralized repositories of all the data in organizations, including metadata such as