A use case diagram generator for actors and flows

A use case diagram generator in Mermaid is a workaround, because Mermaid has no use case diagram type. You model actors as circles and use cases as rectangles on a flowchart, and you say that out loud so nobody thinks the ovals are hiding in a menu.

I looked for a keyword. There isn't one. useCaseDiagram is not a diagram I can open, and the preview is right to reject it. UML's picture, stick figures beside ovals inside a system boundary, is a real notation. This file does not draw it. If you need the stick figures and the ovals for a class that grades notation, use a tool that has them and check that tool's version. If you need the actors and the goals in a repo, the workaround is honest enough, and it's diffable.

The flowchart syntax page is where the circle and the rectangle come from. This page is only about using them as a use case picture. The examples gallery is a different post. I won't paste ten examples here and call that a generator.

There is no use case keyword

The first line of a Mermaid file is a diagram keyword the library knows. Flowchart, sequence, class, ER, state, and the rest. Use case is not on that list. I've watched someone hunt a settings panel for it, then blame the editor. The editor can't offer a type the language doesn't have.

So the generator is a flowchart with a convention you document above the fence. One sentence is enough: "Circles are actors. Rectangles are use cases. A subgraph is the system boundary. Arrows mean the actor is involved, not that step A happens before step B." Without that sentence, a reader will treat the picture as a process, because it is a flowchart and flowcharts are processes. Flow charts are the page for that other reading. You are borrowing the shapes and refusing the reading. Say so.

I don't invent a header like usecase to feel official. A fake keyword fails the parse, and a comment that says %% usecase is fine only as a note to editors. The renderer ignores %% comments. The next human might not. Keep the convention in the markdown, where conventions can be sentences.

Circles for actors, rectangles for use cases

An actor is someone or something outside the system that has a goal. A guest, a member, a clerk, a payment provider if the provider kicks off work. I draw actors as circle nodes: guest(("Guest")). The double parentheses are the circle. The word in the middle is the name. This is not a stick figure. It will not become one if you pick a different theme.

A use case is a goal, named as a verb phrase the actor would recognize. "Sign in," not "AuthController." "Reset password," not "POST /password." I draw those as rectangles: login["Sign in"]. A rectangle is not an oval. I don't apologize with a rounded node to get closer to UML. Rounded nodes in a flowchart mean something else to people who know the stencil, and "almost an oval" is how a convention rots. Rectangle means use case, in this file, because I said so above the figure.

An arrow from an actor to a use case means the actor takes part in that goal. It does not mean the actor does the goal before the next rectangle. There is no order in a use case picture. If your arrows are a sequence, you drew a flow and mislabeled it. I check this by covering the circles and reading the rectangles. If they only make sense left to right, I built a process chart. Making a flow chart is the right repair for that file. Don't keep forcing it to be a use case diagram because the ticket said those words.

The system boundary is a subgraph titled with the system name. Actors stay outside the subgraph. Use cases stay inside. That placement is the whole boundary. Mermaid will not stop you from putting an actor inside. You stop you.

Sign-in, reset, and who is allowed to care

A guest can create an account or sign in. A member can sign in or reset a password. The guest doesn't get the reset, because this product only resets for an account that exists, and the guest isn't one yet. That's a product choice. The picture should make it visible, not "simplify" by giving every actor every rectangle.

flowchart LR
    guest(("Guest"))
    member(("Member"))
    subgraph Account
        signup["Create an account"]
        login["Sign in"]
        reset["Reset password"]
    end
    guest --> signup
    guest --> login
    member --> login
    member --> reset

LR puts actors on the left and the system on the right, which is the reading I want. It is not a timeline. signup, login, and reset are ids. The labels are the goals. If the label changes from "Sign in" to "Log in," the arrows still point at login. I don't use the label as the id, because a question mark or a parenthesis in a goal will break an unquoted label later.

Both actors point at login. That's one use case with two actors, not two use cases that happen to share a name. I see people duplicate the rectangle so each actor has a private box. Then a change to the sign-in rules gets applied to one box. The other box keeps the old goal. One rectangle, two arrows.

The guest has no arrow to reset. If support later decides guests can start a reset with an email, you add the arrow in the same change as the feature. You don't add it now "so the diagram is complete." Complete, here, would mean a feature you don't have.

I left the password rules out of the rectangle. "Reset password" is the goal. The token expiry is a requirement, and it belongs in the paragraph under the figure or in the ticket. A use case bubble stuffed with rules is a spec pretending to be a shape. The shape is the name of the goal. The spec can be long.

A boundary, and a goal two actors share

A buyer places an order, tracks it, and may cancel it. A clerk may also cancel it. The clerk does not place the buyer's order. The boundary is the shop, not "the company."

flowchart LR
    buyer(("Buyer"))
    clerk(("Clerk"))
    subgraph Shop
        place["Place an order"]
        track["Track a shipment"]
        cancel["Cancel an order"]
    end
    buyer --> place
    buyer --> track
    buyer --> cancel
    clerk --> cancel

The shared goal is cancel. I want a reviewer to see that the clerk and the buyer can both reach it, and then to ask whether the rules are the same. Often they aren't. The buyer cancels before shipment. The clerk cancels after a fraud flag. If those are different goals, they need different rectangles: "Cancel my order" and "Cancel a flagged order." One rectangle says the goal is the same. Don't share the rectangle to save a line if the goal isn't shared.

Nothing in this picture is an include or an extend. UML has dashed arrows and those stereotypes for a reason, and also as a way to make a simple goal look like a methodology. Mermaid won't draw <<include>> as a use case relation. If place-order always includes "calculate tax," I can add a rectangle and a labeled arrow, place -->|includes| tax, and I will also write that this is not UML's include. I'd rather keep tax inside the place-order story until someone is maintaining tax as its own goal. A forest of includes is how use case diagrams become unread. I stop at goals an actor would name.

The clerk is a circle, same as the buyer. A role isn't a different shape. If I need a system actor, a nightly job that cancels unpaid orders, I still use a circle and I name it "Unpaid-order job" so nobody thinks it's a person. A rectangle labeled "System" is not an actor. It's a confused use case.

A prompt that asks for the workaround

The blank page is the reason I use a generator at all. I don't ask it for "a use case diagram." I ask it for the workaround, or I get a keyword that doesn't exist and a confident explanation.

This is the prompt I actually send, with the nouns swapped:

"Draw a flowchart, left to right. Do not use a useCaseDiagram keyword, because Mermaid has none. Actors are circle nodes: buyer, clerk. Use cases are rectangles inside a subgraph named Shop: place an order, track a shipment, cancel an order. Arrows from buyer to all three. Arrow from clerk to cancel only. No step order. No extra systems. No stick figures."

The AI flowchart generator is the right tool for that prompt, not a class-diagram generator and not a sequence one. The guide to AI Mermaid prompts is the longer version of naming the type and the closed list. You get five free AI uses in total. A use case picture is a fair spend when the actors and the goals are already listed. It is a poor spend when you hope the model will discover your actors. It will discover a payment gateway, an admin, and a notification service. Delete those if you didn't name them. Deleting is the point of a closed list.

After the draft, I check four things. Are actors circles, outside the subgraph? Are goals rectangles, inside it? Does any arrow imply an order the prompt forbade? Did a node get the id end? The model likes a node called end. Change it before you read the goals, or the file may not parse and you'll "simplify" the picture to make the error go away. The error was the id. The goals were fine.

I edit by hand after that. The AI doesn't get a second use to change "Sign in" to "Log in." That's a label. I can type a label.

What the stick figures were doing

Stick figures mean "outside the system, has a goal." Ovals mean "the goal, described in the actor's language." The boundary means "this system, not the world." Include and extend mean "this goal always pulls in that one" and "this goal sometimes adds that one," and half the time they mean the author had learned the words that week.

You can keep the first three meanings in the workaround. Circles, rectangles, subgraph. You cannot keep the silhouette. Anyone who has graded UML will notice. Good. Let them notice. Write the sentence above the figure so they don't think you failed to find the oval tool. You found the absence and you chose text.

I don't redraw this in a UML tool for the repo copy. I might redraw it for a slide if the audience is a course. The repo copy stays Mermaid, because the next change is an arrow, and an arrow is a one-line diff. A slide is a picture. Pictures don't review well a month later.

If what you actually wanted was the actor's experience over time, with a sense of which step hurts, that's a journey, not a use case. The journey diagram page is the shape for "browse, pay, wait, and the wait is the bad part." A use case diagram will not show that the wait is worse than the payment. It will show that the buyer is involved in tracking. Those are different sentences. I've used a use case picture to smuggle a journey, and the scores people cared about had nowhere to sit.

Ways the workaround starts lying

The convention is small, so the lies are specific.

1. Putting the actor inside the subgraph. Then the boundary says the guest is part of the account system. They aren't. They're outside, poking it.
2. Naming rectangles with controller or endpoint names. The actor doesn't want "SessionsController." They want to sign in. If the review is about endpoints, this is the wrong picture.
3. Reading the arrows as a sequence because flowchart LR looks like a pipeline. Cover the arrowheads and see if an order is still implied by position. If you need the order, you don't need this convention.
4. One rectangle per actor for the same goal. Sign-in is one use case. Two boxes will drift.
5. Adding include arrows until every internal step is a use case. "Hash the password" is not a goal a guest would name. Keep it in the writeup.
6. A node id of end, or a use case labeled in a way that the id becomes end. Call the id finish or closeAccount and quote the label if it has punctuation.

A seventh, which is a writing failure more than a syntax failure. The diagram lists goals the product doesn't have, because a template did. Delete the template's goals. A generator that starts from "banking app" will include "take a loan." If you don't take a loan, the oval you didn't draw is still a rectangle in the file, and someone will schedule it.

How to make a diagram is the general path from an empty file to a picture, if the convention above is clear and the blank page is the rest of the problem. I wouldn't start there if you already know the actors. Start with the two figures on this page and replace the nouns.

Open the editor and paste the shop example before you ask a tool for stick figures. Change one actor, delete one goal you don't offer, and read the arrows as involvement. If you hear yourself saying "and then," you're holding a flow chart. That's allowed. It just isn't this picture.