Diagram to show how one object "becomes" another?

Question

I am working in a purchasing system where we take calls:

public class Call 
{
    public List<CallItem> CallItems { get; set; }
}

The calls can be turned into quotes, where call items become quote lines:

public class Quote
{
    public List<QuoteSegment> QuoteSegments { get; set; }
}

public class QuoteSegment
{
    public List<QuoteLine> QuoteLines { get; set; }
}

And quotes can be accepted and turned into orders, where the quote lines become order lines:

public class Order 
{
    public List<OrderSegment> OrderSegments { get; set; }
}

public class OrderSegment
{
    public List<OrderLine> OrderLines { get; set; }
}

There are many transitions like this in our system, where one item can become another. The relationships between their attributes is not always obvious. It becomes time-consuming to read the code and try to trace through the flow of information.

Is there a suitable type of diagram, UML or otherwise, that can be used to show the in-depth relationships between two classes? So that I can show exactly which Call attributes map to which Quote attributes, which Quote attributes map to which Order attributes, and so on?

Answer 1

The main point of a diagram is to convey information. Exactly how it does so is usually a secondary concern. UML and other common types of diagram give us a shared diagrammatic language, but there's no reason you can't invent a type of diagram, as long as it says what you mean.

---

I'm not aware of any standard diagram format that conveys what you want out-of-the-box, but personally I'd approach it starting from something people are likely to know (in this case maybe a UML class diagram) and adding extra elements wherever that's helpful, doing my best to make it clear. I've heard these referred to as "UML-like" diagrams.

What about something like this?

Answer 2

You need to step away from the word "becomes" and maybe rethink your domain language.

In the code a Call object can't "become" a Quote object. My guess would be you create a new Quote based on the data from the Call and persist both of them to a db with a relationship. Maybe a shared key.

You can UML that up no problem because they are all operations common to programming languages and have representations in various design schemes.

Trying to make you design fit the domain language is a good idea, up to a point. Continuing to use the domain language when it is misleading is a bad idea.

For example, if I get a quote from you and then send a letter asking for a cheaper one; the Quote does not become a call and which is then updated and becomes a Quote again. You probably go back to the original Call and generate a new Quote. so you have 1 call and 2 quotes.

Answer 3

I would use an activity diagram:

As for your question about links between Quote and Order, it might be easier to understand if your domain model described what items are as Products or Services. If a Call/Quote just has "lines" or "segments" it's very abstract. If a call concerns products, which have prices, quantities, etc. it makes it easier to convert into an order.