Sequence diagrams for showing specific interactions, box-and-line diagrams for showing static relations.
Sequence diagrams, the only good thing UML brought to software development
41–50 of 427 posts
Re: Sequence diagrams, the only good thing UML brought to software development
#42I used sequence diagrams in the 80s doing network protocol design. UML was apparently published in 1995
Re: Sequence diagrams, the only good thing UML brought to software development
#43University in the late 2000's was teaching UML and out of all of the different diagrams and notations, sequence is the only one I have consistently used since then. The rest of the diagrams felt like they mostly were used in big design documents that stopped being written as agile (or a bastardized form of it) permeated more and more organizations.
Re: Sequence diagrams, the only good thing UML brought to software development
#44On a related note, I've found that GPT4 is surprisingly good at building basic sequence diagrams, either based on a description or for open-source projects. E.g.
* "Write a MermaidJS sequence diagram showing a banking application's interaction between a customer, authentication service, business logic, and database"
* "Include database transactions in the sequence diagram"
* "Include OAuth in the sequence diagram"
Or for an open-source library:
* "Write a MermaidJS sequence diagram showing a CRUD Flask application"
* "Include actual function names of the Flask and SQLAlchemy API calls"
* "Add a redis cache"
Re: Sequence diagrams, the only good thing UML brought to software development
#45Sequence diagrams were not original to UML.
Sadly, I cannot remember the method they stole it from. I do remember it was created by a man working for Hewlett-Packard in Britain who published a book around 1993.
Does anyone remember?
Re: Sequence diagrams, the only good thing UML brought to software development
#46Spot on, I agree that sequence diagrams are super useful, I see them used all the time in FAANG. I do really wonder why UML is still taught in universities, as the article states, it's pretty useless. I took a masters Software Engineering course at Georgia Tech two years ago and a big part of the class was learning UML. That time was mostly wasted as I've never used any of it and never met anyone who has used it. It…
Every software engineering team in my 20+ years career actually used 2-5 types of UML diagrams: classes, sequences, deployment, activity, state. I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. There’s certainly some value in it.
With the odd caveat that you probably use sketches of these diagrams? As soon as you are trying to cram in all of the extra details stuff like class diagrams can do, you are probably wasting time.
Re: Sequence diagrams, the only good thing UML brought to software development
#47I work with non-distributed (ish) systems, and I use watered down class diagrams much more often than sequence diagrams. But even when I was working on more distributed systems, I found more value in state machines and simplified class diagrams, actually. I think most cases where you're using a sequence diagram, a state machine is a better tool. Both for thought, and for implementation. Surfacing implicit state machi…
The problem with state machines that I run into often when using them, is "multi-dimensional" states. When managing to get that right they are great, otherwise you get loads of edges...
I'm not sure what you mean by "multi-dimensional" states. Is it something that statecharts [1] can help with?
Re: Sequence diagrams, the only good thing UML brought to software development
#48Spot on, I agree that sequence diagrams are super useful, I see them used all the time in FAANG. I do really wonder why UML is still taught in universities, as the article states, it's pretty useless. I took a masters Software Engineering course at Georgia Tech two years ago and a big part of the class was learning UML. That time was mostly wasted as I've never used any of it and never met anyone who has used it. It…
Every software engineering team in my 20+ years career actually used 2-5 types of UML diagrams: classes, sequences, deployment, activity, state. I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. There’s certainly some value in it.
> I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not.
I suspect that's true: teams with a very immature engineering culture probably do use a lot more UML. It's a good way to feel like you're doing something useful instead of actually doing the hard part. Mature teams write code.
Re: Sequence diagrams, the only good thing UML brought to software development
#49Yeah, Mermaid gets it. Mermaid . . wait a second . . oh, ok, these are the same people that do Mermaid.js, they're just trying to make a living doing it. Another useful chart type provided by Mermaid.js is the git diagram, which I use all the time when brainstorming change processes, especially for other folks who might not be git-conversant. https://mermaid.js.org/syntax/gitgraph.html
I find Mermaid's syntax difficult to use and understand past the simplest examples. I've also run into some strange edge cases with it, but can't remember the details right now.
Out of these text-to-diagram tools, D2's syntax seems the friendliest to me. See https://text-to-diagram.com/.
Re: Sequence diagrams, the only good thing UML brought to software development
#50Earlier quoted context omitted.
UML is both broader and more formal that ER
Can you give an example? Some try to put too much detail into ER diagrams in my opinion. A Data Dictionary is usually a better place for such details. ERD's should mostly be to illustrate relationships. One trend/fad was to put words describing links between tables, but I usually didn't find such helpful. Maybe if the wording was done well it would help, but most seem forced in practice. Good naming takes experience.…
> A Data Dictionary is usually a better place for such details.
Self-documenting code/schemas are an even better place.
...sometimes I feel like I'm the only one in the world who uses DB-level metadata (e.g. `sp_addextendedproperty` in SQL Server) to attach explanatory notes and other metadata to database objects, including columns and constraints - and it gets better because I modified my Entity Framework scaffolding templates to then include those comments in the generated C# code as XML-doc (or JS Doc comments in TypeScript) - and the entire DB schema is also kept in source-control (using SSDT).
Additionally, because CHECK constraints in SQL are declarative it means I don't need to write-up a human-readable explanation of (for example) the format restrictions based on a column in the CHECK constraint, because it's immediately visible and obvious (and yes, my scaffolding templates also include the CHECK's expression in C# code-comments too for-reference).
----
Another technique I'm a huge fan of now is using predicate-types (similar to dependent-types) by taking advantage of class-invariants: so I have my own zero-overhead (i.e. elided structs) like `NonEmptyImmutableList` which immediately lets everyone know that if that's passed as a parameter then it won't ever be empty - whereas if the code used the stock `List` or `IReadOnlyList` types you'd have to write-up how that list should be used - which no-one should have to do.
I just lament that my daily-driver languages (namely C#) make it kinda tedious to define types like that.