I try hard not to be an immature commentator, but I've yet to see anybody think around a UML tool. And it's somehow ironic that I shut off 99.999% of the UML/OO world because reading anything about lisp/haskell/forth/prolog made my brain think a dozen orders of magnitude more than anything I did with UML, which finally was an effort that felt going somewhere.
All I remember about UML is useless semantic debates (activity vs states on time axis) or shallow bikesheeding sessions about UML profiles (we actually had hours "talking" about whether we should use plain or hollow dash.. I mean really) for clueless clients stuck in manual FTP workflows.
It's possible that these people were operating at higher thinking levels than I was capable of doing.. but even if so, I'd rather enjoy my own quirks and live in picolisp.
I can remember deciding protocols (actual protocols, not data types) around message sequence diagrams, and a lot of people certainly think around entity-relationship models (yeah, those are UML too).
You will notice that those aren't the design of OO systems that UML was created for, but they exist. Also, there are better diagrams for protocols than message sequence UML, but those don't have good tooling.
Besides those, use-case diagrams are nice too. They also emanate that strong feeling that they don't describe the correct idea (just like message sequence for protocols), but I don't know of a better replacement, just worse ones. People try to replace this one with all kinds of canvas too, but those just bring different problems.
> a lot of people certainly think around entity-relationship models (yeah, those are UML too).
Chen notation entity-relationship models are about 20 years older tha the first work on UML. UML class diagram notation is sometimes pressed into service for ER Modeling by people already invested in UML, but that’s about the extent of the relationship.
> Besides those, use-case diagrams are nice too. They also emanate that strong feeling that they don't describe the correct idea (just like message sequence for protocols), but I don't know of a better replacement, just worse ones.
The problem I have with Use Case models is that they combine abstract requirements/domain modeling with implementation design in an opinionated OO way. They may be the best way to do those together in one diagram, but I just think that’s usually a bad idea to do. For the first part, I think Level 0 Yourdon-style DFDs are a better tool; for the second, if you need OO-focused diagrams, I would probably go with UML class diagrams, recognizing that interactions are nouns in the domain.
When people get to publish papers in distributed computing, they always use free-hand drawn graphs, not UML.
The format varies a lot, but there is a popular one where time usually flows at the horizontal, lanes do not necessarily go through all of the diagram, the arrows are more angular, and there are very diverse conventions on the message label. The angular arrows are a very impactful change by themselves.
There are also data flow diagrams, when you don't need to represent causality.
protocols design would have been a step up already, but I find sequence diagram barely adequate here, better than nothing but really a disgrace compared to a lot of tools we use (property based testing for instance, or state space like proofs, instead of ad-hoc manual drawing you know)
I think this is a good comment, not immature. I think I understand where you're coming from.
I've been a Common Lisp fan for a while. As has been said by others who've used it, even if you don't use it in your daily work, it changes your thinking.
I think UML was (is still for a few?) the standard way to define structure and interactions.
UML seems to me to have a high amount of ceremony. For something as complex as say, a jet engines control system, perhaps this is reasonable?
.. I also like the idea of enjoying "my own quirks". This fits with the dedication in SICP, https://web.mit.edu/alexmv/6.037/sicp.pdf .
I think that it’s extraordinarily important that we in computer science keep fun in computing
A great idea. The trick is to be able to keep a job while doing that. Looks like you've somehow done that with picolisp!
What is an "FTP workflow" in this context. "File Transfer Protocol" doesn't make much sense to me here and I couldn't find anything that would. I'm also at a loss at "hollow dash" TBH.
"Workflow" is a term of art in business software that typically encodes into software what would have been the movement of paper around an office in the past.
In an old paper office, documents would go into people's inboxes for decision making, and would be forwarded to someone else when done. Think of customer service taking a report from a customer (this is the inbox for Customer Support), turning that into an entry in an internal bug database (the inbox for a developer), and then into a code fix up for review (the inbox for a different developer), and so on. This is a workflow. Work literally flows from one person to another throughout the organization.
Where integration between different software systems occurs, there's a spectrum of choices, from humans poking data into UIs through to direct API calls. One of the cheaper automated-yet-ad-hoc integrations is a script which FTPs files into well-known directories, often with semantically significant directory and file name conventions (e.g. dates or company codes). The receiving system polls the FTP location for new data (frequently CSV files), often using regexes or other techniques to extract metadata from filenames (since CSV doesn't really support non-repeating metadata).
So FTP workflows is an ad-hoc workflow integration using FTP to connect two different software systems, replicating what would have been done by paper 20 years ago.
It probably does actually mean "File Transfer Protocol". Its not uncommon (or wasn't at least) to find workflows that rely on data files of a specific format (to varying degrees) being FTP'd into the right server and then processed by that server.
For example, I found this [1] randomly while googling.
Thanks for trying to answer it. I'm still confused why it should be a "hollow dash". I mean "hollow arrow" would make perfect sense, but dash? Maybe I'm overthinking it;-)
> for clueless clients stuck in manual FTP workflows
This kills my soul. UML is being presented as a way to abstract away from the actual processes. But not everything can be abstracted away. The fact that we need to picture a UML diagram to represent a user stuck in FTP is outright a waste of time, money and human labor.
Don’t worry. UML is just not very good. I have tried it myself and I also have never seen a decent sized project that was designed successfully with UML. People don’t understand the diagrams and they are hard to iterate on. Working with UML is tedious instead of supporting you.
I use it too for first thoughts about the project. It is also a decent reference. But once the project has a "personality" the UML goes away pretty much. And only the complex stuff needs the UML. The simple patterns are complete unto themselves.
> It is perhaps unfortunate that no design (sorry, “emergent” design) is the best practice that has replaced it.
I can't really agree with this. I design and build very large scale systems. We don't use UML, but it's possible to rigorously design and plan without UML.
Our designs are typically made of JSON data models, operations that take and return those models, and sequence diagrams that show the temporal relationship of the operations. It's not fancy, but it's dead simple, still pretty rigorous, but not too rigorous. Our implementations end up looking pretty much exactly like what we planned (even though they aren't actually JSON), and anyone can read and understand them.
Sometimes we build critical systems that require very rigorous design, to the point where we use TLA+ to catch design flaws. And sometimes it's just some internal UI and we slap together a bunch of random stuff haphazardly. And various degrees in between. I wouldn't characterize the "best practice" as "never design", it's more like "design, but not too much". UML is usually "too much", or places the focus on things that don't really matter.
(Note, I don't have much experience with UML, I dipped my toes in it a long time ago and ran away screaming.)
Yeah. "Rigor of the design" and "medium of expression of the design" are two independent axes. You can have a sloppy design expressed in UML, or you can have a rigorous design expressed in UML. Or you can have a sloppy or rigorous design expressed in something else.
The question then is: Is UML a good notation for expressing designs? And I think the general consensus is, "no". It's too high-ceremony for how much it aids communication.
And if you're going really rigorous, well, I'm going to guess that TLA+ doesn't read UML diagrams...
> UML is usually "too much", or places the focus on things that don't really matter.
Design is important where separate teams and systems interface. It's less important when a team understands the system well. That's what class diagrams aren't very useful. That, and I can explore them in my IDE, and really, complex class hierarchies are a smell that something's over-engineered.
Design your API like you’re expecting to be the next Stripe. Then add a little more context. You’ll never get recognized but your documentation will be amazing.
Think: “how am I proactively planning on getting promoted so I can forget all this?”
It's unfortunate that the customization of UML is not more accessible. This could cover exactly the use case "a reduced, specialized subset" with full editor support.
May I ask where you work? Leslie Lamport has been asking around for examples of companies using TLA+ internally; he'd be interested in hearing your story.
I also had an Enterprise Architect license, which I paid for myself - it's an impressive product. But what most people don't get about UML is that it works best as a documentation and explanation tool, not a design tool. I've never seen a project that successfully used UML (or other structured graphical languages) for design on a realistic (say 5 man year) project - it would be interesting to hear if anyone else here has, and even more interesting (and believable) to see the actual design.
Edit: reduced 10 man year to 5. 10 is too long & overmanned (though I have worked, unhappily, on such projects).
Agree with this and I think it's the crucial point. Where I've had the most success with UML-like tools and diagrams is early on in a project since its much faster to rip up and rebuild a few diagrams. The diagrams also help with getting consensus among stakeholders that this direction makes sense and doesn't have any glaring holes.
Later on you can drop the diagrams entirely and perhaps keep them as some onboarding documentation if they're still useful.
Yes, exactly. Modelling things has many uses (collaborative thinking, communication, dependency tracing, complexity management etc.) and specifying things is probably one of the least useful of these. I work with UML (and Sparx EA) primarily as a high-level architecture tool. Once everybody has a rough shared understanding of what and why we are building, people get to coding and UML stops. Should we get to a problem, we dig up the initial idea, validate it, us it for problem-solving and move on. Sometimes sequence diagrams might be used for making sure everybody has the same understanding of how an interaction should go. But that’s it. Communication, problem-solving, knowledge management. And not specification.
I find Enterprise Architect to be very bloated. I use it on occasion but the useful stuff is rather hard to find. I'm using this on a ~500 person year project though I am not sure project size is an important differentiator.
As a person who enjoys “shitting JavaScript into containers,” I also think something was lost in the abandonment of UML. There’s something wrong about the fact that software engineering isn’t actually engineering in the traditional sense. Not because we’re not beholden to a monopolistic cabal like the IEEE or bar association, but because it’s always felt like current-form software engineering isn’t actually engineering. The problem space isn’t so different from what it was 30 years ago, yet people solve the same problems over and over again with different tools instead of reducing them to some fundamental principles like UML and working from those. But UML was either the wrong set of principles or came at the wrong time. I like to think software development will revisit something like UML in the future, because there’s just something so compelling about not solving the same problems over and over again in slightly different ways.
> There’s something wrong about the fact that software engineering isn’t actually engineering.
Well, the point is that UML isn't engineering, either. The visual syntaxes are overly baroque, and in many cases add little or nothing over just stating the exact same information in plain text (though there are of course exceptions, where "tracing" linkages visually, looking at containment etc. can actually help when surveying a design).
And the whole OOAD/RUP methodology of "just list plausible 'objects' from the overall problem domain and reflect them directly in the design and implementation" does not exactly help, either. It mistakes what "objects" in the OOP sense are supposed to be used for.
Yeah I agree with you. Clearly something was wrong with UML. I didn't mean something was lost with the abandonment of UML in particular. Just that nothing has come up to replace it and people just write the same code over and over again, poorly. And that there is no real "software engineering" discipline in the same way that civil engineering or electrical engineering exist. I guess it's still just too early in the history of software to really break it down into a discipline.
In mission critical software, software engineering feels like engineering. A friend of mine that has a company focused in this niche jokes around that his IDE is Microsoft Word :)
I think I know what you mean, but could you break that down for me just in case?
And what is mission critical? Aerospace control software? Wouldn’t it be nice if all software was “mission critical”? Not all houses are skyscrapers, but all houses are designed and built to industry acceptable specs and if those specs are wrongly designed or executed incorrectly there are consequences, and rightly so I think.
> Wouldn’t it be nice if all software was “mission critical”
Nope. There are times for nice, strong houses; and there are times for chicken coops made out of duct tape, rusty steel wire and bent nails. As long as they keep chickens in, it is all fine.
It is up to management to decide what kind of structure are they going to build.
That said, there are disturbingly many cases when people don't pay attention to security, and then there are personal data leaks. The handling of personal data should be regulated, verified, and there should be severe consequences for leaks caused by negligence.
As for the rest -- let people do whatever they want. No backups? sure. 'SELECT *' on index.php? you are paying for the servers, go ahead.
> It is up to management to decide what kind of structure are they going to build.
It'd be nice if management was held more accountable when they choose duct tape/rust steel wire/bent nails construction techniques to build multi story apartment blocks instead of chicken coops. But we haven't even solved that problem for actual apartment blocks yet, so I won't be holding my breath for that accountability for software projects any time soon...
The incentives are different. Time to market and exponential growth are not the main concerns. You have financial incentives, enforced by your contract, to deliver documentation and to test every delivery under rigorous QA.
I think this friend is working on satellite software and also (counter intuitively for me) accounting software with anti-fraud semantics.
The Arduino code that blinks my festival costume blinky lights is not mission critical.
The MCAS software on a 737MAX8 should be considered mission critical, but apparently wasn't treated as such at least not by upper management or beancounters who had final say.
NASA's Mars Rover control software is mission critical, and they use coding standards, formal methods, and tools to verify its correctness.
In between is a very very wide grey area. The marketing department thinks the cross domain analytics tracking code on their website is "absolutely mission critical!", but it's built on top of a pile of other people's php and javascript that's way closer to my Arduino blinky light code than to Mars Rovers LOC-4 (Level Of Compliance) or other NASA LOC-5 and 6 code.
Quite what software should possibly be regulated like skyscrapers or houses, and what software should be unregulated like a camp ground, or when that camp ground grows into a shantytown that starts requiring house-like regulation - seems to be a thing that there are no "industry standards" for yet (at least perhaps, cynically, not beyond "maximising shareholder value" or "not leaving money on the table"...)
As you said, mission critical is not always treated as mission critical. Ariane 5 maidens launch failure was due to a software bug. Here some footage from the launch: https://www.youtube.com/watch?v=PK_yguLapgA
Aero space would be considered safety critical, which implies even higher levels of rigor (and regulation). Mission critical can apply to any setting where a lot of money or other resources are at stake wrt. the software functioning correctly.
A lot of companies in that domain also prefer hiring them over CS people, it's a culture thing.
Many of them hired EEs in the 70s/80s (and earlier) who became managers. At the time it made more sense (fewer CS folks) but it established a culture of preferring engineers to computer scientists/programmers/(these days)software engineers. I even left a job because they straight up told me no non-EE would ever become a lead (over a 99% software activity). I appreciated their honesty and found the exit.
The usual justification for perpetuating it has to do with the 1% of the job that touches hardware, but IME it's usually either truly specialized and most of the EEs couldn't do it either, or trivial (following directions from the electrical engineering team that actually designed the hardware).
I think there's value in hiring people who have been trained in a standardized process that prioritizes chains of responsibility, detailed analysis and reliability over velocity, flexibility and bug-tolerance.
Plus, these days, the usual electrical engineering curriculum is ~50% programming, which is more than can be said for some CS curricula (which aren't standardized the way ABET does for EE).
That's a very odd assessment, but that's, like, totally your opinion, man.
> I think there's value in hiring people who have been trained in a standardized process that prioritizes chains of responsibility, detailed analysis and reliability over (velocity, flexibility and bug-tolerance.*
You write this as if that's what CS people are taught (to make crappy systems and crappy code), which may be a common feature of many programmers, it is not the thing they're taught to do in school. At least not if they halfway paid attention.
There's a risk vs productivity balance. Most people develop for systems which are connected to the internet and can be updated on demand, in that case it makes sense to "shit out javascript" because we can go back and optimise and fix things later. That doesn't mean you can't use proper design patterns, but you shouldn't front-load work for something which is most likely going to be wrong for the customer when they see it regardless.
The fact that we can iterate on something once it's released means that engineering in a software sense is different from any other discipline which we call engineering.
On of the main differences is that until things get to the point of being a running system, software is relatively easy to change. It's also a lot easier to test than than, say, airplanes, and the consequences of a mistake are often, but not always, less.
It really isn't. Not when any change can easily be the source of new defects/bugs, and the bugs get exponentially harder and costlier to fix the later they're introduced in the software creation process.
Software is relatively easy to change compared to other engineering disciplines. It isn't universally easy to change, but it is relatively easy to change compared to rewiring a plane to convert from CAN bus to Ethernet or other things. Or changing out the engines on an aircraft. Or changing a bridge's support structure without taking it down.
There's definitely something missing when you don't have a common or standard visual language for communicating ideas between different engineers/teams.
Something I never really put together until seeing it written up in the recent threads on HN about UML is the way in which it was largely a dead evolutionary end for software and that other approaches (e.g. agile) took a different evolutionary fork and appear to have won out for now. Thinking on it now the comparison is more than the obvious "waterfall sux" reduction, but entire ecosystems of support tooling, with millions of man-hours, billions of dollars, and entire forests of printed material was built on a faulty metaphor.
UML reeks of bad academic thought. What I mean is that strange sort of thinking that seems to infiltrate certain upper strata academic circles where some obscure thinkery is apparently "all of the work" and the detailed work of actually building the thing is just hand-waved away as "something the research assistants will grind out and I won't be troubled with". It's where folks who build an overly complicated wall-sized "design" diagram declare that the project is done, even if literally tens of thousands of hours remain to get to lights on.
More constructively, it turns out UML does have its place in some niche areas for design, and it's a good skillset to have to document certain complex systems for turnover and as inspiration for communication-via-picture, but it's not fundamentally a good toolset in its original incarnation that comes from a valid set of assumptions.
I found when learning it in college software engineering courses that there was also a subtext that came through which I believe drove the sudden adoption in enterprise. The long-standing desire to turn software development into a consultancy and drive development into commodity. Remember, UML's heyday coincided neatly with the drive to offshore complex software projects to warehouses full of cheap barely skilled development labor.
Billions upon billions of failed, intricately designed, software projects now pave the paths of the agile botanical garden reserve.
"It's where folks who build an overly complicated wall-sized "design" diagram declare that the project is done, even if literally tens of thousands of hours remain to get to lights on."
Well, no sane person would say that. When you have that wall sized UML modeslls, you can maybe call your design phase to be done, but never the project.
And you can argue, that if you done the design right, the rest is just grind till all is implemented. But it is quite hard to get the design right at first try ...
There's this common lack-of-self-awareness thing about people that undoubtedly are experts in their fields: "I've been doing X for 10 years and then I encountered Y and, suddenly, everything clicked." And then they go full post hoc / propter hoc and start praising the Y thing as something that one has to start learning from the very beginning.
While the truth is - everything "clicked" because you was doing it for 10 years, not because you started using Y. And Y is extremely confusing and off-putting for anyone who don't have the full context of your experience.
I used to develop a CASE platform for mission/safety-critical technical developers -- aerospace, datacomm, complex embedded (not corporate "MIS", which has morphed into "enterprise"). My company did some work that was ahead of its time, some of which would still be considered new and cool today on HN (and also boring stuff).
Based the recent carpet-bombing of UML comments on HN, I have a new theory about UML, and it's no longer that dotcommers have the strength of opinion that can only come from narrow experience (nor that the barrage is an accident of what I call blog-arbitrage)... :)
When Java first came out, it was one of the coolest things to be using. Then Java became an "enterprise" thing, and became very different. I'm wondering whether enterprise-sales-capture is what happened to UML.
Maybe the dynamic is IBM trying to sell enterprise products and training, orgs doing enterprise development wanting to have documentation and process standards, orgs mandating UML, lots of developers going through UML training, developers seeing UML as a checkbox expectation/requirement (like TPS cover sheets, rather than as a tool they find useful), etc.?
And that dynamic has driven the evolution of UML, as well as the examples-in-practice to which most developers have been exposed?
FWIW, even if UML has gone in a direction that's not applicable to a lot of developers, you can still draw upon it, and the earlier methodologies and notations, if you use it when it's beneficial. If you want slightly more visual class/entity relationship diagrams (visual association role multiplicity, and generalization triangle where it belongs :), you can use OMT. If you're doing concurrent and hierarchical state models, there's UML or Statecharts. Never underestimate the power of an old-school DFD for talking about processes and data flows in a way that all stakeholders can understand and reason about. And everyone gets old-school control-flow flowcharts for steps/branches/loops. And you can even explain event trace diagrams to any stakeholder, if you walk them through the important real-world example, and they see it as worthwhile.
I'd like to hear what others think but for me, UML is essentially just class and sequence diagrams. The other diagram types are either overly complex, not widely known (thus no incremental communicative value) or undifferentiated from text (use case diagrams for example).
Class and sequence diagrams are pretty simple and in my opinion can, in small doses, be more effective for communicating ideas than only code in some circumstances.
I don't think UML is evil or even bad, it ultimately just isn't very important.
There’s a trope I’ve noticed with UML discussions and articles, which is that UML and agile are diametrically opposed.
This is not strictly the case. There’s nothing in UML or agile that says you cannot update a diagram in a sprint.
The supposed opposition comes from, not technical reasons, but the manner of thinking that each encourages. The promise of UML is that if you diagram the problem, all things will flow from it (implementation and documentation), this implies a design upfront and lends its self naturally to the waterfall approach, though this need not necessarily be the case.
And most tools were tailored towards that use case!
The (open source) exception that I remember from back in the day was Green UML.
Their sourceforge is still live and saying "green is a LIVE round-tripping editor, meaning that it supports both software engineering and reverse engineering."
Renaming a method in a reverse engineered UML diagram and seeing that reflected in code was pretty neat.
I never got why this isn't a standard feature until now. Hearing about the relationship between UML and broken project management I get it (I wasn't into that at that time, except that I never bought into the waterfall promise).
Let's hope someone will revive UML as a code navigation and round trip refactoring tool. That would help a lot and nicely fit an agile approach.
> some pre-lapsarian school of thought from back when programmers used to think, and weren’t just shitting javascript into containers at ever-higher velocities.
I am sometimes curious why people kept talking about a "dying" thing rather just letting it die quietly. Does it imply an underlying sentiment that we all hope someday there is a UML alternative that is truly successful?
No, if we consider UML a visual programming language, there are the languages that everyone hates and those that no one uses.
I consider these UML hate articles as valuable as those anti-OOP ones, while all OS GUIs and mainstream languages have some kind of OOP support in them.
A: You di not know how many years we spent on training on that. Always thinking great may be, but let us talk something we can manipulate and explain to the users. Then hq continued our training. Go to A:
I find myself in the position of seeking UML/BPML in a time that nobody much wants to invest on this kind of structural definition.
My dayjob is bound in delivery of a public interest process and so the mechanistic expression of that process is what motivates me to do this. But, its an uphill struggle.
I take issue with lumping UML and BPM together. Yes I know IBM/OMG has worked hard to make BPML an application of UML to leverage/repurpose their investment, just like UML itself was portrayed as "unifying" earlier OO and ER modelling techniques. But I don't believe it was for the better of BPM adoption. I know for sure that around 2000-2005 there was BPEL. It sure had its own problems (one being that it was criticized as not being "real" BPM, another being that devs didn't like XML and misunderstood BPEL as a programming language competing with eg Java, a further one being that it went down when the WS-* SOA death star became out of fashion). But it still was remotely successful in describing interactions between "web services" as it was called then, and would still be very useful to describe and execute interactions/integrations in today's SaaS landscape. And yes, WSDL (2001 or earlier) could describe today's idiotic "REST" interfaces squeezing every invocation parameter into URL query params for some reason (and JSON for responses) even if the consumer is neither a browser, nor does HATEOS; we've just stagnated since.
I remember spending way too much time generating UML class diagrams in Rational ROSE for an Ada project which was definitely not built using OOD/OOP (It was an older code base we were porting from SPARC/Solaris to RHEL/x64).
It was the stupidest thing ever. All driven by contract requirements (contractor shall bring documentation up to date etc.).
Why yes, this was in the defense industry. Same project where progress was measured using SLOC.
UML to a language/system and vice versa could be great, but separately maintaining UML as a representation isn't something that seems super useful to me.
Snippet: "UML was going to be the "blueprints" of code, and software architects would develop UML diagrams similar to how building architects create blueprints for houses. But as it turned out, that was a false premise. The real blueprints for software ended up being the code itself. And the legacy of UML lives on in simpler boxes and arrow diagrams."
As someone who studied architecture and spent 3 years in studio doing nothing but design, I would like to clarify the essential conceptual error here.
Architects do not design with blueprints. While design methodologies do vary and make use of sketches, rough drawings, perspectives, models (usually hot glued bits of cardboard and balsa wood), and finally drafting, the blueprint proper is an end product and that too comes in design and construction flavors. The actual workers realizing an architectural design work with what is called a "working drawing":
UML is 'working drawing' for software (and it actually does to a respectable extent deliver on that). The conceptual error of IBM et al. was pushing UML as a design tool, and UML as a medium for exploring software design.
Here is how I used to design after considering the 'program' (what the structure is supposed to provide) and the 'site': First step was coming up with a concept for the design. The concept didn't even have to be directly related to buildings per se; one major project was based on EPR [Einstein–Podolsky–Rosen paradox]. The process of coming up with a concept usually did entail doing conceptual sketches, but also quite a bit of text. Just writing thoughts.
After the concept was established, there would come more concrete sketches, and finally on the drafting board, layer upon layer of 'trace paper' -- translucent paper -- that I drafted over and over again. Each layer added and/or modified the layer behind it. The initial layer, for me, was a governing grid. The final draft on the trace paper was candidate design. After that, I would place velum over the trace and draft the pristine design drawing.
The comment I cited calls "code" the "real blueprint" of code. As a software practitioner, this does not map to my experience as a designer of software, and for reasons stated above, in my mind speaks of a misunderstanding of what a "blueprint" is.
Certainly, I do 'sketches in code'. Many projects that end up with elaborate modules in files and/or class hierarchies are first sketched in a single file. I like Go a lot for this reason: I just work through my thoughts in a single file and then elaborate the design when I am satisfied with the approach and functionality.
Now the open question remains as to whether we can have a 'formal mechanism' for doing 'conceptual sketches' for software. What would the equivalent of trace-paper be for code (outside of say git branches?) What is the equivalent of glued bits of balsa wood and cardboard? Perspectives?
This is a difficult problem given that a 'visual vocabulary' for code needs to capture a great deal of semantics whereas artifact design permits 'squinting'.
I think UML is a valiant effort for a visual, formal, vocabulary of capturing a final design, software as is, but it (or rather the tooling around it) is far too cumbersome to serve a fluid means for the dynamic and volatile process of designing.
I agree. The whiteboard is still the most effective tool for communicating and playing with ideas.
I've yet to encounter a software-based set of tools that rivals it in the context of sketching out and sharing ideas and concepts (especially in an interactive manner).
The reMarkable tablet and similar tools expand on a whiteboard's features without getting in the way of the existing ones. Only downside is scale, though it's amazing to dream of a wall-sized reMarkable.
Seeing the discussion here, I'm feeling that the good parts of UML has not found favour with many people: the Harel Statecharts, they were semantically rich and could easily describe complex behaviour. Infact they are better than Sequence diagrams to specify which sequences are legal and which are not valid.
I don't see any post-UML method that provides the same expressivity as Statecharts for that purpose.
The problem with UML diagrams as a design tool is that all the culture around them is using them in a really fine grained manner, with every class and even methods stuffed in there. A map in 1:1 scale with the territory gets unwieldy really quick.
What I actually do is sequence diagrams in PlantUML.
In org-mode, one can do keep a bit of Agile documentation near the code. This delivers communication value without the documentation turning into a career path.
I have always been looking for something to UML as markdown to HTML. Any idea? Not text based tools though. PlantUML is nice, but it already feels like coding instead of modeling.
I work on a large project and I find it impossible to work on without UML. No one else on my team draws them and that doesn't make them any less useful to me. I just think some people think better visually. I wonder if it's related to being an autodictat. My programming grey matter was formed with concrete exploration as a kid as opposed to learning later in life when more abstract thinking is possible, who knows?
I suspect more people could benefit from using it if they spent time with it. I don't think I'm that odd. I was around when writing automated tests was becoming common practice and I saw all the resistance and hate for something that is hard to know the benefit of until you do it. That might be in play and I suspect a lot of the resistances was because enterprise software development tried to make it into some oppressive process.
I had a look at this, but I'm having a pretty hard time telling if these diagrams actually make things more straightforward. My guess is that quite a few people would find a pseudocode listing more readable, but I'm open to alternative takes.
To each their own, of course, and if you like it and it helps you then right on! But as an outsider, none of those diagrams are more useful to me because they use UML shapes than a plain box-and-arrows diagram (sequence diagrams excepted, but those predate UML).
Diagramming is very useful. I just don’t see the value of dogmatically following UML-style formatting.
Alright, I concede that’s a good point. You’re using a diagram to communicate an idea, and it’d be a pain in the neck to have to teach everyone a new vocabulary before you start each meeting. In your experience, do people understand enough UML that you don’t have to explain it?
I was thinking about this conversation overnight, and I wonder if a “UML 2” or “UMLite” that had a very limited vocabulary and a narrow set of use cases would be well received. Basically, not “here is how you can describe every noun, verb, and relationship in your enterprise so you can automate them” but “here’s how we draw classes, databases, and sequence diagrams to communicate with other people”. I’d be all over that.
All I remember about UML is useless semantic debates (activity vs states on time axis) or shallow bikesheeding sessions about UML profiles (we actually had hours "talking" about whether we should use plain or hollow dash.. I mean really) for clueless clients stuck in manual FTP workflows.
It's possible that these people were operating at higher thinking levels than I was capable of doing.. but even if so, I'd rather enjoy my own quirks and live in picolisp.