Wrong task dependency computation

Question

Hello,

I am using plantuml 1.2018.08

With the following plantuml script

@startuml

[SA] lasts 2 days

[LLA1] lasts 8 days

[BS] lasts 3 days 

[LLA1] -> [BS]

[SA] -> [LLA1]

@enduml

Task BS is not correctly scheduled. I would expect it to start on the 11th day, after [LLA1] has ended. Instead, the dependency goes backwards in time and starts on the 9th day.

Can someone explain this behavior ? This seems counter intuitive. How can I configure it ?

Kind regards,

Answer 1

I think this is a problem in the plantuml parser as it apparently  does no know the offset for the 'LLA1' task.

Rearranging to:

@startuml
[SA] lasts 2 days

    [LLA1] lasts 8 days

    [BS] lasts 3 days
    [SA] -> [LLA1]
    [LLA1] -> [BS]
@enduml

solves the problem, see http://www.plantuml.com/plantuml/uml/SoWkIImgAStDuOeETenLo4aiBYbMC598IQmivk9I089e7nz7GvY41RA4Kp1Cs1Wih00M1XkZQmVLXp0290ZMmyN5vP2QbmAq4W00

Comments

Thanks for your answer.

Should I raise a bug ticket ? Where ?

---

The people from plantuml are reading this as well, so they should see it as well and the item is marked as "bug" so should be OK.

---

Yes, we use this forum as bug manager, so it's ok.

However, even if the behaviour of your initial diagram is odd, it's consistent with our design.

Let me explain why:
We want to keep this Gantt feature as simple as possible, and we don't want to add a complex solver inside our code.
When you start with :
[LLA1] -> [BS]
it just "pushes" BS tasks so that it starts just after LLA1 (result http://www.plantuml.com/plantuml/uml/SoWkIImgAStDuOeETenLo4aiBYbMC598IQmivehsyN4qX8bPGCMSWc4Ync0H1PWoNJi5a2INEj0WC0yYpkMGcfS2D1y0 )
Then when you add [SA] -> [LLA1]  it again just "pushes" LLA1 so that it starts after SA. And it does *not* push BS. Of course, with this simple example, it could sound logical to also push BS to respect the constraint given by "[LLA1] -> [BS]". But what if other dependencies are present ? In that case, we would need a complex expert system that would try to respect all constraints given by the user.

So as Albert mentioned it, the solution is to be careful in the line's order, knowing the fact that each arrow only "push" a single task.
This way, our design is simple and easy to understand.
Tell us if it's an issue for you !

Thanks,

---

I honestly think this is an issue, for at least two reasons:

* this behavior is unconsistent with other plantuml diagrams (class, sequence and deployment) where the write order of the edges has no effect on the end result
* above all, when this behavior triggers, the output Gantt is **wrong**: the suggested end date is false with no warning shown to the users.

I noticed the issues thanks to the backwards arrows on the output. But they can be hard to see when tasks are numerous or short.

At the very least, some kind of feedback should be given to the users.

Is the required system that complex ? Maybe this is a consequence of allowing too much freedom ?

For instance, the backward constraints of the "Complex example" do not make sense to me. I would suggest constraining  Gantts to DAG of tasks. Then, solving the constraints only require walking the DAG from start ot end.

 I am not a native english speaker. Please forgive me if my comment seems rude.
PlantUML is an amazing piece of software. If I can help, I will.

---

No problem, we can think about it.

> I would suggest constraining  Gantts to DAG of tasks.
> Then, solving the constraints only require walking the DAG from start ot end.
Which means some code to be written :-)
Please note that constraint are not always  as simple as "->" (see http://www.plantuml.com/plantuml/uml/VP51IqCn48JlxrVCpMCfek2jw4657Zm87a8FqMoVWP0yTaTB_xrfC9RwQ2zXONU-cTsiZ5uv-amExaKB2_UJ88Z5CM-GlD6ml4RmUuFF0T7mKL9HgMN6sdzB3gABTHm_UP--P72lOiJKKPrnTmxnKDIdnQEAvDPjWGpTSajHp9DT6QhnuDuqKa0nMdUwEJhLaLhmWlufwgySkmDA_p2tSyo9MoMqg8Dxpf5jRdTiGsKgoitvPI_h-XcMXnHubsqbuFzfUuJJaBEXjkcgFksRVm00 for example)

Anyway, we could discuss about it. We could add a "mode" that would change the behaviour of the gantt construction. By default, the mode would be "lenient" (as current behaviour).
We could add a mode "solve" that would try to solve user's constraint (using DAG as you suggest).
Another mode could be "control" that would do the same as "lenient" *but* will raise an error if some input contraint is not satisfied.

For example, what do you expect for :

@startuml
[A] lasts 3 days
[B] lasts 3 days
[C] lasts 3 days
A->B
B->C
C->A
@enduml

or for :

@startuml
[A] lasts 3 days
[B] lasts 3 days
[C] lasts 3 days
[B] starts 5 days after [A]'s end
[B] starts 3 days after [A]'s end
@enduml

---

> Please note that constraint are not always  as simple as "->" (see http://www.plantuml.com/plantuml/uml/VP51IqCn48JlxrVCpMCfek2jw4657Zm87a8FqMoVWP0yTaTB_xrfC9RwQ2zXONU-cTsiZ5uv-amExaKB2_UJ88Z5CM-GlD6ml4RmUuFF0T7mKL9HgMN6sdzB3gABTHm_UP--P72lOiJKKPrnTmxnKDIdnQEAvDPjWGpTSajHp9DT6QhnuDuqKa0nMdUwEJhLaLhmWlufwgySkmDA_p2tSyo9MoMqg8Dxpf5jRdTiGsKgoitvPI_h-XcMXnHubsqbuFzfUuJJaBEXjkcgFksRVm00 for example)

Yes, sorry. I was a bit thrown off by the display (backward arrows) of those more advanced constraints. I thought arrows were only for strict task dependencies (like B requires A to proceed). You will require a more complex solver in that case (https://github.com/chocoteam/choco-solver ?)

I would be OK with both examples failing to compile honestly: such cases highlight logical errors in the user mind. Silently generating the gantt chart would do more harm than good IMO. A warning could be emitted in second case.

Can I ask what is the roadmap regarding Gantt charts ? I am surprised you already support advanced constraints, and yet, full blown Gantt chart support with resource constraints and critical path detection is hard!