But it is a great tragedy that we don't have some standardized vocabulary for sketching software architecture (ownership vs. flow of control between components, for example). Something beyond just boxes and arrows. To use for sketching and absolutely nothing else, of course.
I do still use sort-of-UML diagrams for sketching architecture at the 10,000ft level, after the software has been written as, as a kindness to those who follow in the piece of documentation that hovers somewhere around how to build the project. I'm not sure they are truly useful anywhere else. But they are useful.
Note the last fading vestiges of my Rational UML Training Course (unspeakable waste of time and money) in this diagram from the architecture page of one of my personal projects:
I think they're interesting in that they borrow useful vocabulary from UML, but they also a need to invent vocabulary that (probably) isn't in UML. Also that it's probably not valid UML, but I don't care. And that the basic information it provides is which of seven files/classes you would start in, when trying to fix a bug, before you started crawling through the remaining 174 files and ~250-ish classes.
And most interesting of all: that there is no standardized notation conventions to deal with such diagrams that I would expect anyone to understand. I don't think it's reasonable to expect anyone who started programming in the last 20 years to even know what UML is.
My vision of Rational and Grady Booch, while living through that period...
- Grady Booch, an unassuming genius, who had a modest but really very good idea.
- Rational: An insane pack of underfed marketing guys, probably run by a relative of Elizabeth Holmes, who had absolutely zero understanding of the underlying problems UML was designed to address. Ever promising, never delivering.
Maybe it's time to revisit Grady Booch's modest but really very good idea, and consider whether it can be rescued from the horror that UML became.
I do still use sort-of-UML diagrams for sketching architecture at the 10,000ft level, after the software has been written as, as a kindness to those who follow in the piece of documentation that hovers somewhere around how to build the project. I'm not sure they are truly useful anywhere else. But they are useful.
Note the last fading vestiges of my Rational UML Training Course (unspeakable waste of time and money) in this diagram from the architecture page of one of my personal projects:
I think they're interesting in that they borrow useful vocabulary from UML, but they also a need to invent vocabulary that (probably) isn't in UML. Also that it's probably not valid UML, but I don't care. And that the basic information it provides is which of seven files/classes you would start in, when trying to fix a bug, before you started crawling through the remaining 174 files and ~250-ish classes.And most interesting of all: that there is no standardized notation conventions to deal with such diagrams that I would expect anyone to understand. I don't think it's reasonable to expect anyone who started programming in the last 20 years to even know what UML is.
My vision of Rational and Grady Booch, while living through that period...
- Grady Booch, an unassuming genius, who had a modest but really very good idea.
- Rational: An insane pack of underfed marketing guys, probably run by a relative of Elizabeth Holmes, who had absolutely zero understanding of the underlying problems UML was designed to address. Ever promising, never delivering.
Maybe it's time to revisit Grady Booch's modest but really very good idea, and consider whether it can be rescued from the horror that UML became.