In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…
Sequence diagrams, the only good thing UML brought to software development
181–190 of 427 posts
Re: Sequence diagrams, the only good thing UML brought to software development
#182Earlier quoted context omitted.
"real UML has never been tried" significantly more interesting technological failures deserve dibs on this excuse
Some of these methodologies and their tools have been used very successfully. By people who built complex systems that really needed to come together and work correctly. I'm addressing the masses of us Webrogrammers, who classify all that space as "UML", and dismiss it. Not everyone is just going to be tossing (ChatGPT-assisted) sprint tasks over the wall, while calculating when to make their next job hop. Some teams…
On the contrary, people who are doing routine webdev are the ones who can afford the overhead of doing this nonsense, whereas for people who actually have to make something complex that works it will sink them.
Re: Sequence diagrams, the only good thing UML brought to software development
#183https://sequencediagram.org/ is the best text-to-sequence-diagram tool. Its the only one of these which lets you draw sequence diagram with your mouse too and will generate text accordingly. Completely offline (localstorage) and also supports saving to onedrive and google drive.
Re: Sequence diagrams, the only good thing UML brought to software development
#184In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…
The risk and complexity dictate how much architecture and engineering are involved and with all things, businesses will try to get by with a bare minimum. The automotive, chemical, and other industrial sectors invest a lot in software architecture and enterprise architecture because the risk is so high. But even a medium size e-commerce platform has very low risk or complexity.
Re: Sequence diagrams, the only good thing UML brought to software development
#185[0] https://www.rfc-editor.org/rfc/rfc793
Edit: there are a form of sequence diagram in an early FTP specification from 1971: https://www.rfc-editor.org/rfc/rfc172.html
Re: Sequence diagrams, the only good thing UML brought to software development
#186Sequence 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?
https://www.rfc-editor.org/rfc/rfc793
See figures 7-14.
Re: Sequence diagrams, the only good thing UML brought to software development
#187In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…
Has anything replaced UML? I mean, if there are teams out there that aren't shunning design, what do they use to create architecture diagrams?
I was eager to use UML when it came out but I agree with the article, the only thing I kept was sequence diagrams. Most of the rest of it was just a complicated way to represent stuff that is best represented in code or plain documentation.
I’m also not afraid to use stuff that’s out of fashion. I use simplified ER diagrams, and even flow charts on occasion.
But the tool I use most often in design is SQL DDL…
I have also used Mermaid (using a modified Docsy theme in Hugo) and it is also great. Using Typora to edit Mermaid is also excellent.
Re: Sequence diagrams, the only good thing UML brought to software development
#188In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…
Yeah, hard disagree on all that. As someone who lived through that era professionally, and who has had an "architect" title in the past, I was actually resistant to ever stepping into that role, because I had so many bad experience with the Formal Architecture Methodology crew, who would produce the most absurd and out-of-touch designs. There's a reason that "architecture astronaut" is a term from that era. Lots of p…
Re: Sequence diagrams, the only good thing UML brought to software development
#189Sequence diagrams are very useful, but UML just adopted a representation that already existed decades before. For example, the original 1981 TCP specification in RFC 793 [0] has ASCII sequence diagrams (see figures 7 to 14, etc). I don't know if they predate that - less from that era is online - but I wouldn't be surprised. [0] https://www.rfc-editor.org/rfc/rfc793 Edit: there are a form of sequence diagram in an ear…
Re: Sequence diagrams, the only good thing UML brought to software development
#190Earlier quoted context omitted.
Maybe before you actually start writing code its nice to create some domain diagrams which you can convert to class diagrams. Saves a ton of time. And you have good discussions about the general high level workings of an architecture. Can be done on a whiteboard. Make some pics and start coding.
Assuming that you're using a modern IDE: it is an order of magnitude quicker to model the domain (classes + attributes) in code and project them as diagrams, say with graphvis. High level boxes are great for thinking about systems but the key there is abstraction - minimal viable level of detail..