Earlier quoted context omitted.
Sequence and activity diagrams were already present in Jacobsons original method, which again is based on the "Ericsson Approach" (originating in 1967), long before UML; they were called interaction diagram and state transition graph.
Who's Jacobson? Google doesn't turn anything up. Neither does "Ericsson Approach" for that matter..
Sequence diagrams, the only good thing UML brought to software development
291–300 of 427 posts
Re: Sequence diagrams, the only good thing UML brought to software development
#292Earlier quoted context omitted.
UML didn't help though because it is never kept up to date with what the code really is
How was it supposed to keep up? The most popular programming languages did not introduce concepts that are too hard to reflect with UML. Or do you mean the problem of maintaining documentation?
Maintaining documentation. UML cannot go even one developer-week without being updated, but the developer will often not do that. By the time your UML is a month out of date it is useless at best, and misleading at worst.
Re: Sequence diagrams, the only good thing UML brought to software development
#293Earlier quoted context omitted.
People who say that don't understand design patterns and have never worked on a very large project with code dating back a few decades. Design patterns are what let you deal with the mess that results from that.
So, here's something I hate on this site. Arguments that are made in the fashion "People who disagree with me must not understand X". When in fact you're often talking to some of the smartest people in programming on here (though, maybe not in other things.) It's possible to understand design patterns and work in a language that doesn't require them as much. Here's a talk about it from 2009 with regards to python. ht…
Some design patterns work around a bad language, but most are about complex problems. They are a way of describing abstraction, and that is what languages are about.
Re: Sequence diagrams, the only good thing UML brought to software development
#294I agree with the article that sequence diagrams are great, but I’ve also used state diagrams (not the formal kind from UML) a fair bit for sketching state transitions.
Re: Sequence diagrams, the only good thing UML brought to software development
#295Earlier quoted context omitted.
> And they'd know the classics, like memorizing all design patterns. That sentence is bringing back ptsd-like flashbacks. I remember distinctly how much everyone thought that approach you describe was broken when it was the trendy thing. I'm not sure how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. [The…
To be fair to the design patterns people, a lot of them got baked into pieces of infrastructure like web servers and frameworks, while others are part of frequently included libraries. If I went through and inspected any Node, Rails, Django, etc app I would find many Gang of Four design patterns, but very few of them would be in the project-specific code. They got implemented well, and now programmers can build new t…
this.
Back in the day (before open sourse became so prevalent), lots of software was designed from scratch with the minimal use of outside components and frameworks.
Today OSS frameworks (especially web frameworks) and libraries, PaaS, and Cloud provides you with an already baked-in design patterns. So there is less need in SW Architect and proper design.
Also, most of the Gang of Four patterns are just addressing the deficiences of OOP and older PLs, so if you're using a modern PL with closures/etc. there is no need in them.
EDIT:
Novadays a vast majority of design patterns are dealing with the complexities of microservices architecture, so if your product is a monolith then there is no need in them.
IMO the most useful design patterns are the ones dealing with error handling, reliability, and the essential complexity comming from the real world and human actors, not the self-inflicted accidental complexity comming from the bad design decisions. The good SW Architect should be able to help in avoiding that.
Re: Sequence diagrams, the only good thing UML brought to software development
#296In 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…
I disagree. Software back then used to just fail as often, there was just less of it. Now there's lots of working software, most software sucks and lots of it fails. But the people paying well, and enabling their teams usually get good software at a reasonable price reflecting the complexity.
The project management triangle never stopped existing.
Re: Sequence diagrams, the only good thing UML brought to software development
#297Earlier quoted context omitted.
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…
I don't think it was software architecture, UML or design patterns that was bad. I think the 'Open-Closed Principle' is one of the worst ideas to ever gain popular acceptance. For anyone who didn't live through that time, the Open-Closed Principle states that software should be open for extension, but closed for modification. However, you could also rephrase that principle to be: 'you should always prematurely abstra…
This is very on point. Premature abstraction has always a struck me as way now evil than what premature optimization can create.
Every class has an interface abstraction, or worse inheritance hierarchy, that adds friction to change, even though it's the only implementation.
When something similar comes along it's pressed into that shape, because the abstraction is already there.
It's like this meme video where it's hard to watch all the round and triangular pieces being fit in the square hole.
And the problem is that while software is more flexible than traditional architecture, hence soft, the complexity limit is also soft or virtually non-existent. So in software it's worth more to be simple and flexible than to have a plan that's long and detailed.
Re: Sequence diagrams, the only good thing UML brought to software development
#298Earlier quoted context omitted.
> Maybe in the not-too-distant future we will have AI grokking large code bases and cranking out accurate, useful, UML diagrams out of it. > All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey. I spent a bit of time prototyping this recently. It's definitely possible. Rational Rose also had the capability to generate diagrams from code though. I don't remembe…
The problem isn't generating UML from code, the problem is generating useful UML from code. Where those boxes are in relation to each other matters. You can't just randomly throw boxes and lines on the page, you need to arrange them so that boxes that we can tell what things are related by how close they are to each other. Automatic UML doesn't capture that. Sometime you have complexity in code that needs tobe hidden…
> Or you manually update UML in theory, but in practice just let it slide as the week after you know something else will change and you don't nees it today anyway.
I've heard this argument many times, but how is it different from keeping documentation, comments, tests, or the issue tracker up to date?
They all require some discipline, but if the team finds value in any of these things, they would make an effort to keep them synchronized with the code.
Besides, I suggest not falling in the trap of having formal design documents early on in the project's lifetime. Rather start with informal diagrams and sketches, and once the design has mostly settled, switch to something like UML. This would mean it wouldn't require changes every other week.
As for automatically generating, and dynamically arranging diagrams, this is more up to the generating tool than UML. These tools are still stuck using decades old technology at this point AFAIA, but there's no reason that a smarter tool couldn't do the things you mention.
Re: Sequence diagrams, the only good thing UML brought to software development
#299Earlier quoted context omitted.
We haven't told ourselves that shipping garbage in short cycles is the only way to do things. The market has pretty much determined that companies that over invest in formal software design activities lose out competitively in the long run, and the survivors are the ones with the right balance. You're welcome to prove the market wrong.
In truth it depends on the software. For web or phone or desktop apps which can be upgraded on the fly, short cycles are ok. On the other hand, Boeing's crappy software practices resulting in the 737-MAX crashes are an area where short-cuts killed people.
So much this. Coding to marketing dictums on the cycle of days/weeks is completely NOTHING like engineering solutions where subtle design issues can make the difference between life and death (or IRL super good thing A and IRL super bad thing B).
Re: Sequence diagrams, the only good thing UML brought to software development
#300Earlier 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..
If you're creating diagrams with graphvis, you're just coding on another language. The benefits of diagrams appear when you draw them by hand (or graphically by mouse).