Thank you for your article.
I like the length and the content is easy to understand.
As the "Diagrams are the ultimate engineering tool" theme suggests, it offers only a positive perspective, as expected.
I can't quite agree with the only positive opinion.
For example "Arrows compose: an arrow from A to B, followed by an arrow from B to C means that changing A will impact C.",
this depends on what kind of diagram it is. For example, the arrows in a UML class diagram are not intuitive to a novice.
Also, some companies have their own style of diagramms, and even those aren't exactly easy to understand. Among other things, I think it depends on the design selection for the various parts.
In summary, however, I agree that diagramms are extremely useful and often necessary.
They do often require a good amount of experience in the field the diagrams are about, or in similar fields. They do however often function in a similar manner. If in a class diagram you have an arrow going from Job to QueueWorker to AbstractWorker to WorkerPool, it means there is some relation of jobs to worker pools. Similarly, in a data pipeline diagram, a connection from a user to a gateway to a S3 storage to the datalake makes it clear that user data is related to the datalake, even if the meaning of the arrows isn't exactly clear to say, a business analyst.
It is a good point to raise and I will try to go further into it in a future article!
Arrows imply a simple, one directional relationship that doesn't provide a lot of value in terms of communicating how a system works. Arrows have their place of course (UML sequence diagrams spring to mind) but if you are not describing something simple like a request or a query they gloss over key relationships. This is probably why UML itself has a dozen or so styles of arrow to describe class relationships.
isn't indicating the direction of a relationship (which you of course need to ascribe some meaning) more useful than non directional? But I agree, the meaning of an arrow while it can be informal at times, needs to be shared amongst the participants. For flow contrl / state machines, I use arrows to mean "from this state, you can get to this state", and then potentially annotate the arrow with a condition that would cause that transition.
Were you referring to the * ... 1 annotations you can use in class diagrams?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hello Manuel Odendahl,
Thank you for your article.
I like the length and the content is easy to understand.
As the "Diagrams are the ultimate engineering tool" theme suggests, it offers only a positive perspective, as expected.
I can't quite agree with the only positive opinion.
For example "Arrows compose: an arrow from A to B, followed by an arrow from B to C means that changing A will impact C.",
this depends on what kind of diagram it is. For example, the arrows in a UML class diagram are not intuitive to a novice.
Also, some companies have their own style of diagramms, and even those aren't exactly easy to understand. Among other things, I think it depends on the design selection for the various parts.
In summary, however, I agree that diagramms are extremely useful and often necessary.
For sure, diagrams are not "easy".
They do often require a good amount of experience in the field the diagrams are about, or in similar fields. They do however often function in a similar manner. If in a class diagram you have an arrow going from Job to QueueWorker to AbstractWorker to WorkerPool, it means there is some relation of jobs to worker pools. Similarly, in a data pipeline diagram, a connection from a user to a gateway to a S3 storage to the datalake makes it clear that user data is related to the datalake, even if the meaning of the arrows isn't exactly clear to say, a business analyst.
It is a good point to raise and I will try to go further into it in a future article!
Yup. Arrows are problematic when you are trying to represent control flow. Best to just avoid them... go with a line :-)
Why do you think arrows are problematic for control flow? I actually always use arrows (in every diagram), almost never just lines.
Arrows imply a simple, one directional relationship that doesn't provide a lot of value in terms of communicating how a system works. Arrows have their place of course (UML sequence diagrams spring to mind) but if you are not describing something simple like a request or a query they gloss over key relationships. This is probably why UML itself has a dozen or so styles of arrow to describe class relationships.
isn't indicating the direction of a relationship (which you of course need to ascribe some meaning) more useful than non directional? But I agree, the meaning of an arrow while it can be informal at times, needs to be shared amongst the participants. For flow contrl / state machines, I use arrows to mean "from this state, you can get to this state", and then potentially annotate the arrow with a condition that would cause that transition.
Were you referring to the * ... 1 annotations you can use in class diagrams?