4 ms·

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?

by lainga 3y ago

doctor_eval 3y ago
I can’t remember where I read this (Martin Fowler maybe?), but I agree that “box and line” diagrams should be enough for most design cases. 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.
- ozim 3y ago
  I like use case diagrams as well. Thing is these should be short lived and used to make specific illustration in specific time. Not some holy grail of documentation that people should take as some god given truth for whole life of the system.
  - doctor_eval 3y ago
    Yeah, I posted elsewhere in this thread that I'm a big fan of Jack Reeves' essays on "code as design"; namely, that the code is what's important, and the design is just scaffolding. "The following essays by Jack W. Reeves offer three perspectives on a single theme, namely that programming is fundamentally a design activity and that the only final and true representation of "the design" is the source code itself. This simple assertion gives rise to a rich discussion—one which Reeves explores fully in these three essays." https://www.developerdotstar.com/mag/articles/reeves_design_main.html https://www.developerdotstar.com/mag/articles/reeves_design_...
  - macdaknife 3y ago
    Yes, actors and actions. It's the crux of the use case. I'm still operating under the assumption that UML invented the modern use case. I will not be googling this next.
rerdavies 3y ago
Aggressive IDE-supported semi-automated refactoring has replaced UML. Modern languages have been designed with toolability in mind. Modern IDEs allow ruthless redesign of the architecture of code on the fly, allowing architecture to be modified to reflect actual need rather being a fairytale written before the first line of code gets written. Teams aren't shunning design. They're just doing it incrementally, because as it turns out, trying to design a piece of software before the first line of code is written doesn't actually work. Even in peak UML (2000 or so) there were no really practical UML diagramming tools. (Rational Rose was impractically expensive, and buggy enough that it was a race to see if it wouldn't crash before you actually finished your diagram). Corel Draw had passable UML diagraming support. But I don't imagine it still does.
rswail 3y ago
C4 is more than adequate. Draw the boxes and lines and make sure that people understand what they mean. Describe the system from the perspective of the reader. Just like a real architect will have different drawings/plans/elevations for their customer, the planning authorities, and the builder. The architecture diagrams are meant to communicate the design, not comply with some over-worked standard. UML was a clusterfuck that evolved from the trifecta of late 90s OOP (inheritance not composition), design patterns that mostly provided fill-ins for what was missing from Java as a language, the ridiculous concepts of generating code from diagrams that could be regenerated from code, which never, ever, worked, in the same way that ORMs have an impedance mismatch between OO and relational logic. It was yet another silver bullet, the late 70s/early 80s had "structured programming", the late 80s/early 90s had CASE, the 90s had all the stupid diagramming tools where people argued about the shape of the bubbles and what arrows to put on the lines. There was also the Capability Maturity Model, where everyone was trying to get to "Level 5" which was only useful if you were doing exactly the same software over and over again, along with the "6 Sigma" and "Black Belt" nonsense. The 2000s had the "iterative Rational Unified Process" (an excuse to sell expensive tools from IBM), along with CORBA et al. The last decade has suffered from the Agile-with-a-capital-A and especially "Scaled Agile" which is just an excuse for project managers to again treat programmers as fungible, while losing all of the affordances of actual project management, like GANTT, critical path, S curves, earned value etc. Sprints are nonsense, so is "t shirt" sizing and velocity and burn down charts, and retrospectives and scrum "masters". There are a couple of useful things: * Domain Driven Design, using Names That Make Sense To The Customer * Entity Relationship Diagrams, where the Entities are the same Names as the DDD * State Diagrams for those Entities, describing the events that will cause them to change state * Event definitions that match the State Diagram transitions, where externally generated events end up being your external API. Bah, I've been in this industry for almost 40 years and its the same shit over and over, just with different names, and different consultants selling expensive courses.

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?

by lainga 3y ago

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?

doctor_eval 3y ago

I can’t remember where I read this (Martin Fowler maybe?), but I agree that “box and line” diagrams should be enough for most design cases. 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.

ozim 3y ago
I like use case diagrams as well. Thing is these should be short lived and used to make specific illustration in specific time. Not some holy grail of documentation that people should take as some god given truth for whole life of the system.
- doctor_eval 3y ago
  Yeah, I posted elsewhere in this thread that I'm a big fan of Jack Reeves' essays on "code as design"; namely, that the code is what's important, and the design is just scaffolding. "The following essays by Jack W. Reeves offer three perspectives on a single theme, namely that programming is fundamentally a design activity and that the only final and true representation of "the design" is the source code itself. This simple assertion gives rise to a rich discussion—one which Reeves explores fully in these three essays." https://www.developerdotstar.com/mag/articles/reeves_design_main.html https://www.developerdotstar.com/mag/articles/reeves_design_...
- macdaknife 3y ago
  Yes, actors and actions. It's the crux of the use case. I'm still operating under the assumption that UML invented the modern use case. I will not be googling this next.

rerdavies 3y ago

Aggressive IDE-supported semi-automated refactoring has replaced UML. Modern languages have been designed with toolability in mind. Modern IDEs allow ruthless redesign of the architecture of code on the fly, allowing architecture to be modified to reflect actual need rather being a fairytale written before the first line of code gets written. Teams aren't shunning design. They're just doing it incrementally, because as it turns out, trying to design a piece of software before the first line of code is written doesn't actually work. Even in peak UML (2000 or so) there were no really practical UML diagramming tools. (Rational Rose was impractically expensive, and buggy enough that it was a race to see if it wouldn't crash before you actually finished your diagram). Corel Draw had passable UML diagraming support. But I don't imagine it still does.

rswail 3y ago

C4 is more than adequate. Draw the boxes and lines and make sure that people understand what they mean. Describe the system from the perspective of the reader. Just like a real architect will have different drawings/plans/elevations for their customer, the planning authorities, and the builder. The architecture diagrams are meant to communicate the design, not comply with some over-worked standard. UML was a clusterfuck that evolved from the trifecta of late 90s OOP (inheritance not composition), design patterns that mostly provided fill-ins for what was missing from Java as a language, the ridiculous concepts of generating code from diagrams that could be regenerated from code, which never, ever, worked, in the same way that ORMs have an impedance mismatch between OO and relational logic. It was yet another silver bullet, the late 70s/early 80s had "structured programming", the late 80s/early 90s had CASE, the 90s had all the stupid diagramming tools where people argued about the shape of the bubbles and what arrows to put on the lines. There was also the Capability Maturity Model, where everyone was trying to get to "Level 5" which was only useful if you were doing exactly the same software over and over again, along with the "6 Sigma" and "Black Belt" nonsense. The 2000s had the "iterative Rational Unified Process" (an excuse to sell expensive tools from IBM), along with CORBA et al. The last decade has suffered from the Agile-with-a-capital-A and especially "Scaled Agile" which is just an excuse for project managers to again treat programmers as fungible, while losing all of the affordances of actual project management, like GANTT, critical path, S curves, earned value etc. Sprints are nonsense, so is "t shirt" sizing and velocity and burn down charts, and retrospectives and scrum "masters". There are a couple of useful things: * Domain Driven Design, using Names That Make Sense To The Customer * Entity Relationship Diagrams, where the Entities are the same Names as the DDD * State Diagrams for those Entities, describing the events that will cause them to change state * Event definitions that match the State Diagram transitions, where externally generated events end up being your external API. Bah, I've been in this industry for almost 40 years and its the same shit over and over, just with different names, and different consultants selling expensive courses.