Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Structured Anal...  UML: Use Case diagram for Create Invoice
Previous Previous
 
Next Next
New Post 11/18/2019 7:44 AM
Unresolved
User is offline David Jacobs
1 posts
No Ranking


UML: Use Case diagram for Create Invoice 

Hello all
I've just joined Modern Analyst and would like to ask for some advice.
I want to draw a use case diagram for Create Invoice (this is an example I am working on for my own edification).
I have two use case ovals, Create Invoice (Header) and Create Invoice Line.
This may not be the best way to approach it but it seems to me to be a two-way extend relationship.
The user can create an invoice header and optionally create lines (or add lines later).
And the user can create invoice lines, sometimes having to create a header first where one does not exist.
In UML would this be best as Create Invoice without the detail or drawn as how?
I believe a two-way extend is not a recommended construct for use case diagrams.
Many thanks in advance for any thoughts.
David Jacobs, business analyst

 

 

 
New Post 12/11/2019 10:42 PM
User is offline Stewart F
119 posts
7th Level Poster


Re: UML: Use Case diagram for Create Invoice 

Hi David, 

To answer your question directly - I don't thin it really matters which way you create your diagram. 

You are quite right that there needs to be a step to create an Invoice 'shell' or 'header' as you call it. So I agree with that approach, especially based the fact that everything else that is created needs to go somewhere. 

So common sense would say it should be a two-way extend. However, you are also right that usually UML steers you away from having such a approach. The only thing I can suggest is to keep it at one - 'create the invoice shell' and then build on top of that. 

Failing that, rules are to be broken !!

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Structured Anal...  UML: Use Case diagram for Create Invoice

Community Blog - Latest Posts

As Business Analysts in Agile teams, we often hear about Definition of Ready (DOR) and Definition of Done (DOD). But beyond the buzzwords, these two concepts are powerful tools to drive clarity, consistency, and quality in our work. Definition of Ready ensures a user story is truly ready for development. It answers: Is this story clear, feasible...
In today's fast-paced digital world, successful projects aren't just built on great code—they're built on clarity. And that clarity often comes from one key player: the Business Analyst. At the heart of every great product or system is a need—a business goal, a customer pain point, or a regulatory requirement. But busines...
I have always loved cooking. I learned from my Grandma June and her kitchen was her sanctuary, a small, warm sunlit space filled with jars of spices, stacks of cookbooks, and the comforting smell of something always on the stove or baking in the oven. Grandma June was as great a cook as she was a teacher to me. She never followed a recipe “to...

 






 

Copyright 2006-2025 by Modern Analyst Media LLC