[HN Gopher] Sequence diagrams, the only good thing UML brought t...
___________________________________________________________________
Sequence diagrams, the only good thing UML brought to software
development
Author : knsv
Score : 397 points
Date : 2023-06-15 16:27 UTC (6 hours ago)
(HTM) web link (www.mermaidchart.com)
(TXT) w3m dump (www.mermaidchart.com)
| baudaux wrote:
| Plantuml is a really convenient tool for drawing diagrams
| rvbissell wrote:
| I yearn for something that lets me draw sequence diagrams as
| human-readable ascii art (instead of declarative statements as
| with PlantUML,) but that is also rigorous enough to be rendered
| to a professional looking PNG when the situation requires it.
| perrygeo wrote:
| Sequence diagrams are a secret weapon for designing any complex
| system. The y direction (relative time) actually means something,
| unlike most abstract diagrams. The x direction (actors)
| highlights the discrete set of participants. The arrows actually
| mean something - bugs and features and new problems all exist at
| interactions between actors and be systematically decomposed into
| work items, just find the arrows.
|
| I know there are more formal tools (The P language comes to mind)
| but it's hard to beat the simplicity of markdown that gets
| rendered directly in github's UI.
| travisgriggs wrote:
| As a general rule I've come to believe that anything with
| "unified" (or the like) in its title is destined for doom of
| there's a sales/marketting/monetization agenda behind it. And if
| it's a bunch of hackers who agreed to clean up a mess, then it is
| often successful.
| mehh wrote:
| Use case diagrams are also very useful, I find in clarifying why
| are we building something.
| blueberrychpstx wrote:
| I'll just hop in here without reading the article and say that
| I've actually been using UML (plantUML specifically if that
| matters) to communicate with LLMs about software structure with
| some pretty good success.
|
| Turns out computers are good at dealing with symbols, who knew!?
| smusamashah wrote:
| https://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.
| xnx wrote:
| Good tool. They really need to change the cursor on hover to
| give some hint that you can draw arrows that way!
| tandr wrote:
| This is insanely good, thank you very much for the link! Should
| be a great tool to "bootstrap" some diagrams during brainstorm
| meetings, or just to put into documentation, and be able to
| change them later.
| Veuxdo wrote:
| Sequence diagrams for showing specific interactions, box-and-line
| diagrams for showing static relations.
| CyrsBel wrote:
| UML is really powerful but definitely could be more simplified to
| just be basic charts. The problem is that sometimes you need to
| see the full complexity to be able to start simplifying systems.
| The real issue involving a decades-old process that gets in the
| way isn't actually UML though it appears at first to fit that
| description. It's actually scrum. Scrum-based methodologies on
| how to deliver value to the business. Scrum eventually forces
| engineers to make trade-offs like how thorough their UML and
| regular flowcharts can be which is not a scalable way to build
| quality products. The charts should be precisely as complex as is
| needed to accomplish the business objective and ensure that the
| business is always able to be in the best starting position
| possible to continue working on a piece of code or a system with
| just that documentation as the starting point. Sometimes this
| does mean that a demo may be just a bunch of UML or simpler
| flowcharts that have more breadth instead of user functionality.
|
| UML makes sure that product functionality knowledge can be more
| easily restored or understood from an engineering mindset. It
| encodes a lot of information into the format and simpler options
| exist too. But I have to say once again that you almost got it
| right as to which decades-old development methodology is pretty
| deprecated despite still being in fashion - it's not at the
| diagramming layer, it's at the project management layer.
| Rochus wrote:
| So we're back in the sixties, even 20 years before Objectory, see
| e.g.
| https://web.archive.org/web/20060622072014if_/http://www.tcr....
| barbariangrunge wrote:
| I like sequence diagrams for understanding unfamiliar or complex
| code that I need to work with.
|
| Go in, head spins, make a sequence diagram, grok, then make your
| change.
|
| They're awesome for that, and they make decent notes later, but
| realistically they'll be out of date by the next time you look at
| them. I recommend plantuml for this: very friendly syntax, git
| friendly, and easy to regenerate over time as the code changes
| convolvatron wrote:
| I used sequence diagrams in the 80s doing network protocol
| design. UML was apparently published in 1995
| thesnide wrote:
| I discovered FMC some time ago, and it really feels "UML, the
| good parts".
|
| Fundamental Modeling Concepts http://fmc-modeling.org/
|
| Used consistently it really helps a lingua franca across teams.
| Which was the UML aim all along, but it got caught in into
| "Enterprise Bloat" (like SOAP or XML)
| sylens wrote:
| University in the late 2000's was teaching UML and out of all of
| the different diagrams and notations, sequence is the only one I
| have consistently used since then. The rest of the diagrams felt
| like they mostly were used in big design documents that stopped
| being written as agile (or a bastardized form of it) permeated
| more and more organizations.
| Graffur wrote:
| When will people learn.. you need to write down stuff. Pictures
| are a good addition to writing, not the other way around.
| garganzol wrote:
| Several phrases from that era are still echoing in my head from
| time to time: Grady Booch, Rational Rose.
| da39a3ee wrote:
| I'm sure mermaid is nice but if you haven't tried
| https://swimlanes.io/ then you're really missing out! It's
| fantastically low friction; so much so that you can use it as a
| thinking aid.
| neuronexmachina wrote:
| On a related note, I've found that GPT4 is surprisingly good at
| building basic sequence diagrams, either based on a description
| or for open-source projects. E.g.
|
| * "Write a MermaidJS sequence diagram showing a banking
| application's interaction between a customer, authentication
| service, business logic, and database"
|
| * "Include database transactions in the sequence diagram"
|
| * "Include OAuth in the sequence diagram"
|
| Or for an open-source library:
|
| * "Write a MermaidJS sequence diagram showing a CRUD Flask
| application"
|
| * "Include actual function names of the Flask and SQLAlchemy API
| calls"
|
| * "Add a redis cache"
| 0xDEF wrote:
| State machines and activity diagrams have their uses.
| nivertech wrote:
| not only, also UML Statecharts[1,2] basd on Harel Statechars[3]
|
| --
|
| 1. https://en.wikipedia.org/wiki/UML_state_machine
|
| 2. https://en.wikipedia.org/wiki/State_diagram#Harel_statechart
|
| 3.
| https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts....
| lunatuna wrote:
| This title and article feels plucked out of my brain. Most of my
| work is a lot of integrations and the best way to get a room full
| of devs to get what is going on is via sequence diagrams. Every
| other method, formal or made up, is weak compared to a basic
| sequence diagram. You can expand from there if needs be but I
| find it gets people thinking in a more complete way, gets the
| details out and what ifs and what abouts, and then you have a
| nice target that teams hit with very high accuracy and
| completeness.
|
| It is one of the few (only) diagram types that is easy to draw
| and fairly close to the real world implementation. Most other
| formal approaches are wonky abstractions that only true
| practitioners can make sense of.
| knsv wrote:
| I agree, not having to be an expert in order to understand is
| important!
| golemiprague wrote:
| [dead]
| readthenotes1 wrote:
| Sequence 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?
| mhandley wrote:
| There are sequence diagrams in the original 1981 TCP
| specification:
|
| https://www.rfc-editor.org/rfc/rfc793
|
| See figures 7-14.
| ofrzeta wrote:
| "UML 2.0 Sequence Diagram is strongly inspired by the ITU-T
| MSC"
|
| https://en.wikipedia.org/wiki/Message_sequence_chart
| atribecalledqst wrote:
| TCP/IP Illustrated by W. Richard Stevens has sequence diagrams,
| although that book dates to 1994 which is right around the time
| UML was originally being developed. So, it's not a strong data
| point.
|
| I'm positive you're right that sequence diagrams existed
| independently of / prior to UML though.
| contingencies wrote:
| https://www.mcternan.me.uk/mscgen/
| manuel_w wrote:
| I would really like to use UML as documentation language more
| often, but I have yet to find a nice drawing that is simple,
| stupid and runs natively on GNU/Linux.
| mxmlnkn wrote:
| I also had a lot of problems finding usable software for
| drawing UML diagrams. In the end, I used UMLet, it worked
| sufficiently for my tiny class diagram and was easy to use and
| I could rearrange everything minutely as opposed to the
| underperforming auto-layouting done by PlantUML. I also tried
| around with StarUML but somehow it didn't stick. Time has been
| wasted in trying to recreate the same diagram in all these
| tools...
| syntheweave wrote:
| I've been toying with flow-based programming again, and it works
| relatively well as an implementation choice for the same "high
| level" that sequence diagrams cover: The parts of a lifeline that
| need to wait are reified as stalled information packets, while
| request/response APIs are wrapped into nodes(which I've found is
| a good starting point for practical application - make a library
| of nodes from API calls). The rest is defined by graph wiring and
| data types.
|
| As a graph model, FBP lets you fan out widely, but that is
| something you don't actually want to do most of the time: the
| benefit I am seeking it out for is in the bounded buffers adding
| backpressure regulation and debuggability. As such I've currently
| settled on mostly defining ports in terms of structured data
| types, then doing destructuring/merging/splitting in custom
| processors.
| ThinkBeat wrote:
| I thought UML was pretty great when it came out. It attempted to
| establish a uniform manner to model and communicate out software
| models / systems.
|
| I still think it is great. People who never learned about UML
| tend to reinvent some such thing when they wish to communicate
| the same structures and information.
|
| Then you end up with 10 different people drawing approximately
| the same information in 10 different forms, and all will require
| some level of explanation of notation and grammar for others to
| grok it.
|
| A class diagram can contain a lot of rather valuable information.
|
| I do agree that sequence diagrams are great, but if you rip them
| out of context and throw the rest in the bin it can only
| partially communicate, whereas if you had the object model to
| study as well as the sequence diagrams new connections can be
| quickly made.
|
| To this day I prefer to create my object structures in a UML
| diagram. Plenty of software takes it creates the code, or takes
| the code and produces the diagram.
|
| I love creating the diagram(s) when I first start working on an
| existing system.
|
| What I have seen of code generation off of sequence diagrams have
| bit hit or miss. more miss. But reverse engineering sequence
| diagrams can be quite revealing.
| gratitoad wrote:
| Weird, I just discovered and made my first UML sequence diagrams
| yesterday and today it's at the top of HN. Super useful for
| describing my problem and quite straightforward.
| dakial1 wrote:
| I'm not a developer (more like a translator) and love sequence
| diagrams. They are so useful to explore system and data flow
| designs.
|
| Also my favorite tool for them: https://sequencediagram.org/
| Dig1t wrote:
| Spot on, I agree that sequence diagrams are super useful, I see
| them used all the time in FAANG.
|
| I do really wonder why UML is still taught in universities, as
| the article states, it's pretty useless. I took a masters
| Software Engineering course at Georgia Tech two years ago and a
| big part of the class was learning UML. That time was mostly
| wasted as I've never used any of it and never met anyone who has
| used it.
|
| It wasn't my first time learning it either, we also had a section
| on it in my undergrad software engineering course. So I learned
| the same useless stuff twice.
| ignite wrote:
| I have an undergrad friend. Learning this last semester. It's
| still taught, and it's still not used.
| layer8 wrote:
| It would be useful if everyone would at least be vaguely
| familiar with basic UML notation, i.e. action vs. object,
| multiplicity, connectors (association vs. composition vs.
| dependency vs. specialization, interface/implementation), class
| vs. instance, fork/join, swimlanes, etc. Otherwise you have to
| clarify over and over what means what in a diagram.
|
| One powerful aspect of UML is that you can combine different
| diagram types. For example, you can use activity-diagram
| elements in parts of a sequence diagram.
|
| For pragmatic use, "UML Distilled" [0] by Martin Fowler is a
| good introduction and reference.
|
| [0] https://martinfowler.com/books/uml.html
| esfandia wrote:
| It's certainly given too much importance in the curriculum, but
| the idea of having a common language (with standard semantics)
| for sharing design decisions is valuable.
|
| I'd argue the issue is that because UML is not seen as
| valuable, everyone improvises their own dialect when drawing
| stuff, and so since nobody trusts people following correct
| diagram semantics (e.g., meaning of different arrow shapes),
| nobody trusts the resulting diagrams either, further
| reinforcing the notion that it's useless.
| giobox wrote:
| Sequence diagrams aside (they are useful!), I also felt far too
| much time was wasted on UML in my university course. The only
| small argument I can see in favor is perhaps to encourage some
| thinking and discussion around software design among students
| in an educational context, even if I've never once seen it used
| in industry. I can't say I'd miss it's removal all that much
| either though.
| anonzzzies wrote:
| > I see them used all the time in FAANG.
|
| Does that mean something? Besides you saying you worked in
| them? It's a question ; I don't know.
| fkyoureadthedoc wrote:
| [flagged]
| Dig1t wrote:
| It is shorthand for saying that it is used by engineers
| working on high-profile, high-impact, software that ships to
| hundreds of millions of people. Some people might argue that
| these teams work on some of the most important software in
| the world. So if the people who work on this important
| software do a thing, like use sequence diagrams, that is a
| decently good signal that the thing is useful.
| musha68k wrote:
| Also used a lot in automotive software development
| processes for example. Basically, the more safety critical
| a system is the more formal diagramming / modelling there
| will be part of the design and development process. It's
| important to be able to reason about complexities of such
| systems across a team / teams.
| knsv wrote:
| Was it easier the second time around? :)
| civilized wrote:
| Why the university teaches outdated useless stuff? My guesses:
|
| - For the university, it fills out offerings and takes up
| credit hours, keeps the tuition dollars flowing
|
| - For the teacher, it's something they already know how to
| teach, so it doesn't require nearly as much effort to teach as
| something more useful but maybe less familiar
|
| - Universities are trusted with the decisions of what to teach
| and don't face much short-term accountability, so there's no
| real downside to teaching a useless course for another year
|
| - They probably don't know it's useless. (They also don't care
| to find out because of the aforementioned points)
| marcosdumay wrote:
| It exists, you will see it, and when that happens you will be
| expected to understand what is there.
|
| So it is well worth 1 hour or 2 to look at it.
| ryanisnan wrote:
| I'd offer another, possible reason:
|
| - University professors who remain exclusively in academia
| missed the rising tide and teach what they know
| comfypotato wrote:
| My graduate program did not teach UML, but I did learn it
| during my undergrad program. It was a relatively small part
| of the major software engineering course. It introduced the
| idea of formally specifying software, and it forced me to
| reestablish, visualize, and otherwise integrate what I was
| simultaneously learning about things like interfaces and
| inheritance. It was presented as an educational tool and not
| at all that we would be using it in industry. Far from
| useless or out of date in an educational context.
| hollander wrote:
| Isn't UML about conceptual thinking first, before you loose
| yourself in editing?
| petsfed wrote:
| That was my take on it. How do you get students to practice
| the process of thinking conceptually first, then evaluate
| how thorough the planning is, without some tool like UML?
| Its one thing to lecture your students on the necessity of
| planning ahead. Its quite another to evaluate whether or
| not they know how to plan ahead.
|
| Granted, UML is not used hardly anywhere, but I must've
| learned 30 different specific software tools in college
| that I never used outside of college. However, I've used
| _something like_ each one of them. I took a technical
| drawing class in high school and I still use some of the
| techniques I learned in that, even though absolutely no one
| uses t-squares, triangles, and _actual paper_ in modern
| technical drawing today.
|
| There's a fair argument re: how much planning and
| conceptualizing should be done ahead of starting the Agile
| process, and also a fair argument re: what that planning
| should look like (crude flowchart? UML-compliant class
| diagram?). But in rejecting the UML _tool_ , are we
| rejecting also the idea of advanced planning too? Like, how
| completely do you need to reject advance planning that it
| takes the Agile loop to reveal that the customer actually
| needs software that uses an observer pattern?
| duped wrote:
| There's a bureaucratic reason too. Changing curricula is not
| fast and can take years (depending on the institution of
| course).
|
| My department profs actually got in a bit of trouble with the
| university because they took the course that they should use
| for undergrad/graduate mentoring (something like a "special
| studies in XXX" placeholder, usually for independent or small
| group study that was special enough for course credit) and
| used it to create their own courses outside the review of
| approving a new course with a distinct number and credit
| count.
|
| The reason they did it in the first place was because if they
| wanted to change the curricula for the existing courses,
| remove course numbers, or create new ones, the bureaucracy
| would take 4-8 semesters to get approval and complete. By
| which time some of the material was obsolete. One of the
| profs got fired and the rest quit, eventually.
| TheCondor wrote:
| "Useless" is a strong word. Definitely a bit less useful than
| intended though.
|
| Before UML, it's hard to capture the state of corporate
| software development that allowed the insanity to take part.
| I mean, UML was the marriage of two different approaches to
| drawing object models that were locked in a battle: OMT and
| Booch method. There weren't tons of open forums for
| discussion and debate like the internet has now, there were
| conferences and such and these guys were basically trying to
| create formal methods for objects in a vacuum.
|
| It was kind of existential stuff for a lot of the smaller
| players in the industry, everyone saw value in this newer
| approach to building software. "Reusable components" seemed
| huge. Tooling was expensive, training was expensive.
| Microsoft was moving as a scary rate, connect your cart to
| the wrong horse and it could cost you the company... On some
| of the usenet forums, about the most open discussion there
| was at the time, I read debates about the virtue of C++ style
| multiple inheritance vs single inheritance and there were
| product matrices for programming tools that had check boxes
| for crap like that. C++ and CLOS both supported multiple
| inheritance so to the casual observer they were "better." Now
| I've never seen serious industrial software written in CLOS
| or anyone even considering it but it "had the features." It
| was just a different and crazy time, kind of amazing how open
| source/free/libre has altered things, the entire culture of
| building software is different and probably more healthy.
|
| Anyone want to shit on design patterns next?
| tempaway12754 wrote:
| [flagged]
| ivan_gammel wrote:
| Every software engineering team in my 20+ years career actually
| used 2-5 types of UML diagrams: classes, sequences, deployment,
| activity, state. I think it mostly depends on maturity of the
| team and engineering culture, whether UML is used or not.
| There's certainly some value in it.
| pydry wrote:
| >I think it mostly depends on maturity of the team
|
| yep. kids out of college feel most inclined to use it.
| marcosdumay wrote:
| I don't think I have ever seen anybody actually getting value
| from a class diagram. I have seen many people creating them,
| but they are always useless.
|
| I also don't think the UML variant of state machines and
| workflow are any popular. But well, there is probably
| somewhere where people use them. Also, those lists usually
| ignore entity-relationship diagrams, where UML just adopted
| the popular format (without even minor changes, like for
| workflows), and thus everybody uses the UML one.
|
| But yes, people don't remember about deployment diagrams.
| Those are used a lot.
| ivan_gammel wrote:
| > I have seen many people creating them, but they are
| always useless.
|
| Not every artifact is worth keeping, instead the value can
| come from the process of creation as a way to structure
| your thoughts or to explain or brainstorm possible
| solution. The value of class diagrams for those people is
| in the moment and it's ok to throw them away later if they
| _become_ useless.
| francois14 wrote:
| Class diagrams are a good way to detect circular
| dependencies.
| marcosdumay wrote:
| If your class diagram is comprehensive enough to get
| circular dependencies, then I'm completely sure1 nobody
| will use them for anything.
|
| Computers are much better at this kind of checks anyway,
| and they don't need diagrams.
|
| 1 - Instead of "well, maybe it's possible despite I never
| seeing it"
| taeric wrote:
| With the odd caveat that you probably use sketches of these
| diagrams? As soon as you are trying to cram in all of the
| extra details stuff like class diagrams can do, you are
| probably wasting time.
| ivan_gammel wrote:
| I do not understand your question. If I do not deviate from
| convention but omit unimportant details, is it a sketch for
| you?
|
| If you have a project document template from PMBoK, do you
| feel obliged to fill all the sections or you document only
| information relevant to your project? With UML it's the
| same: it offers a lot, but you do not have to use
| everything to produce a conforming diagram.
| taeric wrote:
| It it a sketch if you don't include every detail that UML
| was specifically designed to convey? Yeah? Noting that a
| sketch is not a derogatory phrase here.
|
| Note that, for many of these diagrams, they existed
| before UML. It was an attempt to formalize them. In
| classes, they are often used as code generation tools in
| an attempt to keep a 1:1 between document and code.
| Laudable, but I have yet to see that work out well.
|
| To your point, I think, the same ultimately goes for
| document templates. Way too many are used prescriptively
| as a way to make a successful project. Much to the
| chagrin of the document writer when the project fails.
| Often miserably. To the point that I'm convinced most
| accurate project documents are after the fact. Certainly
| not waterfall to the project that they are describing.
| feoren wrote:
| > I think it mostly depends on maturity of the team and
| engineering culture, whether UML is used or not.
|
| I suspect that's true: teams with a very immature engineering
| culture probably do use a lot more UML. It's a good way to
| feel like you're doing something useful instead of actually
| doing the hard part. Mature teams write code.
| ableeb wrote:
| Mature teams document their code
| ivan_gammel wrote:
| Part of engineering culture in general, not just software
| engineering, is ability to share knowledge though
| documentation and best practices. If you share the source
| code, you communicate your solution on a very low level. It
| is often necessary to zoom out to see the big picture and
| there visualization helps. You can create ad-hoc diagrams,
| but their expressive power is low: without a convention
| it's basically just space, text, arrows and generic shapes.
| To increase the expressive power you need a visual language
| in which different shapes and lines have some semantics.
| And here comes UML and other diagram languages. If you are
| not using them, it is likely that you are not communicating
| efficiently. Can a mature team fail at communication? I
| leave the answer to you.
| prepend wrote:
| > Mature teams write code.
|
| Sounds very Dunning-Krugerish "smart people like me do X
| and not smart people do Y"
|
| Coding and documenting aren't exclusive. Modeling is part
| of documenting. UML is a type of modeling.
|
| I would think effective teams will want to build good
| software. And to build good software they'll want to
| capture requirements, communicate with other teams, and
| test their software. Design helps with this and is part of
| coding.
|
| At the end of a successful day, I should have some updated
| models, some code, and some running software. If someone
| wants to see what I did, they'd likely read through
| different parts.
|
| Just like trying to figure out a stage by just reading
| models sucks, so does trying to figure it out by just
| running the software.
| [deleted]
| poulsbohemian wrote:
| >That time was mostly wasted as I've never used any of it and
| never met anyone who has used it.
|
| So here's the conflict: if we agree that planning is good,
| communication is good, and that it is faster / cheaper to
| design before we build rather than rushing in to build
| something, then is it not a good idea to have something _like_
| UML in our tool kit? Perhaps UML was too complicated or
| overbearing, but I 've always felt like a _universal_ tool to
| describe aspects of the software we are building is
| fundamentally a good concept. Further, it feels like the right
| idea to document / designing up front in a way that increases
| buy-in and communicates what we are doing.
|
| So if not UML, then what?
| gautamdivgi wrote:
| Activity diagrams do a decent job too. But yes, sequence and
| activity diagrams are all I have used.
| JohnFen wrote:
| Although I never use any aspect of UML in my work, I absolutely
| benefitted from learning it. Learning how to model things in UML
| required me to change the way I broke down and formalized
| problems and solutions. That change stuck with me, and I've very
| much benefitted from it, for the rest of my career.
| neilv wrote:
| Thinking "the only good thing" is understandable, since there's a
| lot of noise, but that talk discourages people from learning a
| lot of good stuff that's buried.
|
| Before UML, there were many methodologies. UML was started by a
| unified team of some of the most noted OO methodologists.
|
| There was a lot of good thinking, but one of the adoption
| problems we had before UML (as tools developers and
| methodologists) was that many people got a poor introduction to
| it, and missed the whole point.
|
| For example, on a diagram metamodel that emphasized formalizing
| and visualizing the relationships among objects... some people
| would think it was a TPS Cover Sheet task, to laboriously draw
| their class inheritance hierarchy and summarize their attributes
| and method signatures, for purely corporate bureaucratic reasons.
|
| You could also contrast people who needed to build complex
| embedded system behavior, for whom Statecharts were a very
| valuable tool for keeping the model manageable -- distinguished
| from people who were told to do it when it wasn't appropriate,
| and they just kinda tried to document their code control flow by
| misusing that same diagram notation.
|
| Today, I can't blame people for not understanding, since most
| examples they'll now see are incorrect noise, and the current UML
| spec itself doesn't do this reputation any favors.
|
| Half-seriously, maybe we could use a reset, in which people who
| neither know or care what they're doing _stop being required to
| go through the motions of pretending to do it_. Also stop trying
| to have people who don 't actually use it teach it to students
| who just want a good grade in the class (for their FAANG job
| application), and who have little-to-no experience necessary to
| appreciate the real thing. Also don't make it a marketable resume
| keyword. Then the only people who will be doing or talking about
| it are people who care enough to figure out the genuine merits,
| with no incentive to pretend.
|
| Then, ideally, the only time others will see it is when someone
| whips out a formalized diagram for something complicated, and
| proceeds to start explaining it by walking the audience through
| the diagram... Some people in the audience will get the tingles,
| as they're not only understanding, but they're also sensing a
| very powerful modeling tool that would address some problems that
| they and their team have in their work. (Realistically, this
| would start to happen, but as soon as it becomes a resume keyword
| or interview ritual, history would repeat, but maybe that time
| with a larger mitigating mass of people who understand and
| appreciate.)
| galaxyLogic wrote:
| > Before UML, there were many methodologies.
|
| UML really wasn't a methodology. It was a "visual modeling
| language" telling you how you should draw a picture of a code
| construct.
|
| It didn't give much (if any?) advise on which development tasks
| you should do in which order. It was just a TOOL that could be
| used as part of your SW development activities.
|
| I'm not sure how people used it. Did they first draw the
| picture and then code, or vice versa? Or maybe drawing the
| pictures was optional? A "Software Development Method" should
| answer such questions, among others.
|
| A note about words: "Methodology" means something like "study
| of methods". A more proper word for individual documented or
| prescribed approaches to how to develop software would be
| simply "method". A "method" tells you how to do something.
| esfandia wrote:
| Definitely, bad diagrams (as opposed to bad diagram notation)
| give UML a bad name. Your example of the misuse of state
| diagrams as a glorified flowchart is something I see very
| often.
|
| Undergraduate students probably don't have the experience and
| design maturity to fully appreciate when and how to use most
| UML diagrams. I think you need to get stuck at design problems
| a few times before you can appreciate the need to capture ideas
| using the right diagram, and then you might be ready to adopt
| some standard so you can share your design decisions with
| others in a way that correctly captures and conveys just the
| right amount of detail.
| bsenftner wrote:
| Sounds like you never had to deliver something created with
| that god awful Rational Rose crapware. Who's genius idea was to
| use UML as a code skeleton generator? That is a perfect the
| recipe to guarantee your non-lead developers never gain any
| ownership nor intimacy with the software they are working on.
|
| The only organizations using UML were bureaucratic heavy
| nightmare places to work too.
| Xelbair wrote:
| >There was a lot of good thinking, but one of the adoption
| problems we had before UML (as tools developers and
| methodologists) was that many people got a poor introduction to
| it, and missed the whole point.
|
| Not really, UML was doomed from start due to increased time to
| market metric. And frankly you can read the code if you are
| working on the already built system. Remember that software
| usually does not need to be correct, or even well designed to
| support a business case. It is one of software greatest
| strengths and weaknesses compared to other disciplines.
|
| It does helps in some integration tasks, and works decently as
| schema definition language that's format agnostic.
|
| I'll also concede that state diagrams are good, but well.. they
| are also quite simple.
|
| Then there's readability issue - unless you worked tons with
| UML you WILL make mistakes when it comes to object relationship
| counts, and there's a lot of other non-obvious gotchas for
| newcomers(i used to teach reading entity relationship diagrams
| to non-technical people so they could understand the model they
| were working with, as it was a part of legal bill).
|
| Not to mention that only proponents of UML that i've personally
| met, were people who were stuck in academia, and never worked
| on any real software product..
|
| And even for R&D work on a harder problems it's usually easier
| to write a toy side project and test solutions.
|
| Code you write in such toy project IS an entity relationship
| model. Tests, and example usage is a happy path of sequence.
| etc.
| neilv wrote:
| You might enjoy looking a little deeper. For one example:
|
| > _I 'll also concede that state diagrams are good, but
| well.. they are also quite simple._
|
| One of the goals of state modeling is to simplify. A
| sufficient metamodel will include (in addition to states and
| transitions on events that people might see in automata
| theory and misc. CS education) less-simple features like
| concurrency, superstates, transition guards, maybe real-time
| constraints.
|
| When you need a nontrivial system to actually work, in all
| cases, (not just toss your sprint task over the wall, and
| then do bug tasks later) good use of the abstractions of this
| "simple" diagram, and inspecting it, will tend to avert
| problems that even an unusually conscientious programmer
| might miss in just code. And it also helps communicate less-
| ambiguously to others who come later and need to evolve the
| code. Unlike formal proofs, it's pretty accessible to read.
|
| (It can be _too_ accessible, in that people who are
| accustomed to seeing hand-wavy business diagrams with ad hoc
| notation used inconsistently think they also get the gist of
| this diagram, while not realizing how much more rigorous it
| is. But that 's not a big problem -- you just have to walk
| them through it, ask questions to confirm facts expressed,
| emphasize when something has to be precise and exhaustive,
| etc. The problems are more when the diagram is poor, yet the
| technical appearance confers an undeserved aura of
| respectability, and people who can't tell the difference, act
| on that, but that's not unique to these diagrams.)
| theK wrote:
| > good use of the abstractions of this "simple" diagram,
| and inspecting it, will tend to avert problems that even an
| unusually conscientious programmer might miss in just code
|
| Very good point. If you have expertly written UML and an
| expert viewer, they will get quite a lot out of it. One of
| the biggest issues I have seen with UML documentation is
| that it is extremely difficult to keep it in sync with what
| the actual implementation does. In one of my past jobs we
| actually had started an effort to quelch this by generating
| plantml from code but it never really came to fruition.
| zby wrote:
| Is ERD part of UML? I find ERDs useful representations of
| databases. They can be generated automatically and are very
| good for quickly locating the right tables for a query. So I
| wanted to add a comment stating this to the parent - but then
| I googled to check if they really are part of UML - and it
| seems that they predate UML and are not really related.
| neilv wrote:
| A subset of UML's static object modeling diagram notation
| (which they adapted from OMT) can be used like ERDs, for a
| relational database without an ORM.
| codeulike wrote:
| Correct uml didn't have anything to say about relational
| databases.
|
| I use two types of diagrams:
|
| Erds
|
| and
|
| Random blocks and arrows and icons that mean whatever I
| want them to mean for that particular diagram, based on
| whatever concept I want to communicate at that point. Maybe
| it's network architecture, maybe it's dataflows, maybe it's
| software components. Each diagram comes with some text
| explaining what it represents.
| tomohawk wrote:
| > increased time to market
|
| I've seen people spend days and days trying to save a few
| hours of paper design time.
|
| We often do quick paper or marker board designs, which often
| have some UML. You don't want to spend more than 10% of your
| time on this, but it can save quite a bit of time to market.
| If someone _really_ wants the design saved somewhere, we just
| take a pic and upload it.
| ajmurmann wrote:
| I think you are right and it depends so much on what you
| are building and in what context.
|
| If shipping is expensive, you build something complex and
| correctness matters, you want to go all in on design and
| verification. You might even want to use TLA+ to verify
| your algorithms beforehand.
|
| If you build a SaaS app that people use for leisure and is
| mostly CRUD, you probably don't need UML diagrams for the
| vast majority of your work. Exceptions will be the larger
| systems design where you still need to plan things like DB
| sharding approach, services etc.
| AnimalMuppet wrote:
| > Half-seriously, maybe we could use a reset, in which people
| who neither know or care what they're doing stop being required
| to go through the motions of pretending to do it.
|
| UML. Use what you need, but _need what you use_.
|
| Come to think of it, that probably applies to abstraction. And
| threads. And probably several other things.
| jacobr1 wrote:
| Part of the disconnect is formal modeling methods vs informal.
| There is tremendous value in having a shared understanding of
| the architecture of system such as how components interact, the
| data model and any type of sequence or state modeling if
| needed. That can sometimes be accomplished just with ephemeral
| whiteboard diagrams and sometimes more complex situations
| require deeper analysis.
|
| The challenge comes when trying to document the entirety of the
| system, and keep that up to date. The overhead is too high and
| complexity is such that it defeats the value of a model used to
| communicate shared understanding.
| commandlinefan wrote:
| I like the class diagram notation, although I get frustrated at
| the tendency to try to auto-generate it, which ends up
| including way more detail than is useful.
| mikepurvis wrote:
| I wonder if there's a parallel here with the journey that some
| people go on with respect to design documentation in general.
| In can be easy to have a mandate from on high that your process
| should be research -> planning -> design -> review ->
| implementation -> review -> ship, and that the design doc is
| the key deliverable between the design and implementation
| stages. You can even argue that this is an "agile" process, if
| there's a feedback loop that permits the design to be revised
| as further discovery emerges during implementation.
|
| But the reality is that an awful lot of the software we build
| just isn't complex enough to warrant all this ceremony. It's
| not branchy, there's no significant error handling to talk
| about, no big new dependencies being added, no security
| implications, no long-term maintenance of an external
| interface-- it's just grabbing widgets from pile A,
| frobnicating them, and dropping them on pile B. There's barely
| enough there to even _unit test_ much less write a "design
| doc" about and agonize over in a meeting with bigwigs.
|
| And unfortunately a lot of the projects that junior developers
| start out with look exactly like this. Boring, obvious code
| that does one thing in the exact boring, obvious way that you'd
| expect. So it's easy to fall out of the habit of thinking
| intentionally about design, until you're suddenly faced with a
| big thorny problem that legitimately has multiple paths
| forward, and what starts as a rubber-duck conversation with the
| person beside you eventually becomes "hmm... I think I need to
| write down a page or two that describes these options, gives
| background on why the choice matters, describes why the
| selection was made that was made; then maybe afterward I'll
| circulate that document to my colleagues for their review and
| thumbs-up, because maybe there's something I'm overlooking here
| that they could contribute to?"
|
| Oh wait.
| 0x69420 wrote:
| "real UML has never been tried"
|
| significantly more interesting technological failures deserve
| dibs on this excuse
| neilv wrote:
| 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 will have to build complex things that work, and they
| can benefit from informed and judicious use of abstractions
| and views on the system.
| lmm wrote:
| > 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 will have to build complex
| things that work, and they can benefit from informed and
| judicious use of abstractions and views on the system.
|
| 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.
| throwawaymaths wrote:
| Oh come on. Uml database tables aren't half bad
| [deleted]
| mhandley wrote:
| Sequence 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
| esfandia wrote:
| Exactly, UML mostly borrowed from existing representations and
| its purpose was standardizing semantics and providing some
| consistency among the diagrams.
| Rochus wrote:
| 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.
| TacticalCoder wrote:
| On the subject: diagonal lines in UML diagrams or not? I've seen
| both but somehow diagonals do feel wrong to me. I feel like only
| horizontal lines should be used, as is the case in TFA.
|
| I'm also nearly sure that in the beginning it was the only way:
| there weren't diagonal lines drawn across the diagrams.
|
| So: only horizontal lines or are diagonals cromulent?
| gumby wrote:
| I don't really see them as an advance on the century old flow
| charts.
| Kon-Peki wrote:
| The flowcharts (that I've seen) don't do a good job of
| capturing who does what in the process, whereas sequence
| diagrams do.
|
| Side note - my father, during his career, had a huge collection
| of flowchart stencil sets that he used; I really wish that I
| had a chance to grab them.
| hcarvalhoalves wrote:
| > Comprehensibility > Comprehensiveness #
|
| > The most common failure mode for sequence diagrams is over-
| complication. (This also is the failure mode for most diagrams,
| as I wrote in an article on flow charts).
|
| Agreed.
|
| UML - with the goal of being a graphical language for _complete_
| specification of a system (both for code generation as well as to
| have diagrams generated from code introspection) - has to be
| exhaustive, therefore fails at showing the big picture.
|
| Use of UML that could accommodate multiple levels of abstraction
| would fix that. I believe this is what C4 [1] tries to achieve
| with 4 levels of diagram. Unfortunately everybody who invents a
| new diagram model also reinvents the wheel and throws the entire
| UML away. One could easily use UML visual language, but just
| standardise on using the 4 levels diagrams of C4.
|
| [1] https://c4model.com
| treprinum wrote:
| Haha, I used to work on standardizing architecture of a large US
| enterprise conglomerate and we found out that the sequence
| diagrams were the only useful thing from it all.
| simmerup wrote:
| UML is also really useful for modelling relational databases
| DaiPlusPlus wrote:
| May I ask what you feel UML brings-to-the-table that we don't
| already get with existing (non-UML) ER-diagrams?
| intrasight wrote:
| UML is both broader and more formal that ER
| tabtab wrote:
| Can you give an example? Some try to put too much detail
| into ER diagrams in my opinion. A Data Dictionary is
| usually a better place for such details. ERD's should
| mostly be to illustrate relationships.
|
| One trend/fad was to put words describing links between
| tables, but I usually didn't find such helpful. Maybe if
| the wording was done well it would help, but most seem
| forced in practice. Good naming takes experience. Maybe let
| newbies draft the phrases, but have someone with experience
| review it. I.e, mentoring.
| DaiPlusPlus wrote:
| > A Data Dictionary is usually a better place for such
| details.
|
| Self-documenting code/schemas are an even better place.
|
| ...sometimes I feel like I'm the only one in the world
| who uses DB-level metadata (e.g. `sp_addextendedproperty`
| in SQL Server) to attach explanatory notes and other
| metadata to database objects, including columns and
| constraints - and it gets better because I modified my
| Entity Framework scaffolding templates to then include
| those comments in the generated C# code as XML-doc (or JS
| Doc comments in TypeScript) - and the entire DB schema is
| also kept in source-control (using SSDT).
|
| Additionally, because CHECK constraints in SQL are
| declarative it means I don't need to write-up a human-
| readable explanation of (for example) the format
| restrictions based on a column in the CHECK constraint,
| because it's immediately visible and obvious (and yes, my
| scaffolding templates also include the CHECK's expression
| in C# code-comments too for-reference).
|
| ----
|
| Another technique I'm a huge fan of now is using
| predicate-types (similar to dependent-types) by taking
| advantage of class-invariants: so I have my own zero-
| overhead (i.e. elided structs) like
| `NonEmptyImmutableList<T>` which immediately lets
| everyone know that if that's passed as a parameter then
| it won't ever be empty - whereas if the code used the
| stock `List<T>` or `IReadOnlyList<T>` types you'd have to
| write-up how that list should be used - which no-one
| should have to do.
|
| I just lament that my daily-driver languages (namely C#)
| make it kinda tedious to define types like that.
| intrasight wrote:
| >DB-level metadata
|
| I've used it for years - usually auto-populated from the
| model that builds the relational schema (like you had
| done). Same for constraints. By coincidence, I just
| convinced my team to start using sp_addextendedproperty.
|
| That's the advantage of using a higher-level notation,
| such as UML or code-first EF, for your ORM.
|
| Good idea on the C# type naming conventions.
| [deleted]
| myth2018 wrote:
| > the only good thing UML brought to software development
|
| Interesting perspective, which differs from my own experience
| though. I found some value in class and package diagrams, which
| proved helpful in detecting problematic relationships between
| packages at a very early stage. Deployment diagrams have aided me
| in resource planning and communicating with deployment teams. On
| the other hand, I've personally never used sequence diagrams
| beyond academical assignments or simply satisfying my curiosity.
|
| However I definitely agree that UML is extremely bloated. It
| introduced a myriad of problems so that they could sell solutions
| in the form of courses, books and certifications. Rational's
| acquisition by IBM certainly didn't help matters either. And the
| reference guide by Booch/Rumbaugh/Jacobson is severely painful to
| read.
| remote_phone wrote:
| I am thankful I managed to completely avoid both UML and J2EE in
| my career. Those embody the worst of so called Software
| engineering practices that I saw in my 30 years of working. It's
| governmental bureaucracy embedded into technology that made it
| demonstrably worse.
| MockObject wrote:
| J2EE hasn't been called that in 20 years. It's JEE now, and
| it's much nicer.
| 111111IIIIIII wrote:
| I reached the same conclusion within approximately 1 week of
| first learning about UML.
| narag wrote:
| I like state diagrams, but someone told me that they predate UML,
| I don't know, they're useful.
|
| The bad thing about UML was demanding all kind of diagrams for
| every project, whether it made sense to do it or not.
|
| UML is neither the only "method over common sense" software
| ideology out there nor it will be the last one.
| draw_down wrote:
| [dead]
| jacobr1 wrote:
| Also Service Blueprints. I find some flavor of Service or
| Business Process blueprint invaluable who collaborating outside
| of engineering to understand how a system will be delivered.
| These are just 90 degree rotated sequence diagrams.
| jacobsenscott wrote:
| I use sequence diagrams the most, but I also like the state
| charts, and the simple class diagrams.
| RandyRanderson wrote:
| With any non-trivial set of messages, seq diagrams become
| unwieldy. Always use communication diagrams over sequence as a
| first choice.
| preseinger wrote:
| to the contrary, the whole reason patterns like sequence
| diagrams are so great is because they make it clear when you're
| trying to put too much information into a single visualization
|
| your "non-trivial" is my "too much"
| zabzonk wrote:
| UML is completely crap as a design language. But it can sometimes
| be useful as a documentation language.
| pydry wrote:
| It's crap at that too. It was an excuse to sell rational rose.
| It doesn't need to be excused.
| zabzonk wrote:
| i agree that rose was crap. but some other tools, such as
| enterprise architect were not so bad, despite the name. and
| the ent arch guys were always very helpful. this would be
| something like 20 years ago - gosh.
| therealmarv wrote:
| I still remember of a professor in my university who has written
| also an UML book. He said it will be the most important thing in
| your software career and you will use it nearly daily in your
| future as software engineer. I was sceptical because it was too
| much preaching for my taste. Turns out I was right.
|
| 20 years later: I used it very seldom and definitely NOT in my
| daily software development tasks. Actually the sequence diagrams
| were really the most useful of them all for me too.
| esafak wrote:
| You're lucky if that was the most useless thing you learned.
| Many peoples' degrees were useless in their entirety!
| knsv wrote:
| Sequence diagrams really shine when you're documenting different
| parts of a system and the various ways these parts interact with
| each other.
| Veuxdo wrote:
| You could say that's the only thing they can do, by definition.
| dahwolf wrote:
| 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 using
| UML or otherwise. And they'd know the classics, like memorizing
| all design patterns. Finally, they'd use formalized architectural
| decision making methodologies to justify tech choices.
|
| Nobody seems to do anything like that anymore. Everybody is half-
| assing design or skipping it entirely. Solutions are reinvented
| and tech choices made on a whim by the loudest person whom won't
| see the consequences of it anyway. Because we've told ourselves
| that shipping garbage in short cycles is the one and only way to
| do things.
| lainga wrote:
| 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 wrote:
| 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 wrote:
| 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.
| opportune wrote:
| That's because software architecture is something any senior
| employee should be able to do, and it's not as important as
| people thought.
|
| Like many abandoned corporate practices, I think it was
| abandoned for good reason. It may have made sense under
| different circumstances, like when you had a large army of
| cheap offshore devs who could not be trusted to architect a
| maintainable application.
|
| If I had some ivory tower "architect" trying to interfere with
| my work I'd be so pissed. Anybody I've seen with that title,
| that wasn't doing 1P cloud consulting where the title means
| something different, usually had no clue what they were doing
| and had been given the title as a soft retirement.
| eropple wrote:
| As much as I do think that software architecture does matter
| (though it should probably be somebody with a staff or
| principal hat, not a specific job title) I recently took a
| job at a place that really does like architect titles. Mine's
| even "lead architect".
|
| It is pretty funny when somebody runs into me and realizes
| for the first time that I have the job because I build stuff
| and write code, not because I'm good at LucidChart. I'm
| planning things out beyond immediate needs, but not because
| I'm looking for job security--it's because I've built the
| thing we're doing before and would like to not make the same
| mistakes I've made in the past. I'm over here demanding
| adequate standards of code and low- to mid-level design, and
| the "wait he's serious?" of it is sometimes honestly pretty
| fun to run up against.
|
| I am good at LucidChart though.
| yafbum wrote:
| _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.
| ilyt wrote:
| And they just shipped garbage in longer cycles... as anyone
| that had to deal with such designed legacy apps can confirm.
| RachelF wrote:
| 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.
| maximinus_thrax wrote:
| > Everybody is half-assing design or skipping it entirely.
| Solutions are reinvented and tech choices made on a whim by the
| loudest person whom won't see the consequences of it anyway.
| Because we've told ourselves that shipping garbage in short
| cycles is the one and only way to do things.
|
| I agree. I don't personally fetishize the old slow processes
| nor ivory tower architectures, but I think there's a healthy
| spectrum between that and the complete 'software fuckery' (http
| s://web.archive.org/web/20160308032127/https://medium.co...)
| lmm wrote:
| We stopped doing that stuff because it was useless. We
| eliminated those practices and that profession because it was
| actively harmful to making good software. All those decision
| making methodologies consistently lead to worse technology
| choices than one dude actually trying to write some code with
| the thing for half an hour.
| icedchai wrote:
| UML is mostly useless, but thinking ahead, even a bit, has
| value. I've seen stuff shipped in a sprint that was not used
| by any actual end users, only to be "redone" in the next
| sprint.
| lmm wrote:
| My experience is that shipping stuff that doesn't get used
| by any actual end users is more often caused by thinking
| ahead too much than by thinking ahead too little.
| shinycode wrote:
| So sad and so true
| colordrops wrote:
| The pendulum swung, and now we bias towards action rather than
| design. But to be honest, the "software architect" era wasn't
| great either, with people in the role sometimes not qualified,
| spending months on an architecture behind the curtain,
| releasing some over-verbose spec document that doesn't match
| the product needs, cargo-culting the latest fad from Martin
| Fowler.
| beyonddream wrote:
| I am curious to know what are these "formalized architectural
| decision making methodologies" ? Any books that u know of that
| cover these topics ?
| jt2190 wrote:
| "Rational Unified Process"
| https://en.m.wikipedia.org/wiki/Rational_unified_process
| beyonddream wrote:
| Oh this! I suffered learning this during college ;)
| cptskippy wrote:
| The problem you're describing Exists in all engineering
| disciplines. You don't hire firm to feasibility studies,
| develop a design plan, do a materials bid, sub contract
| clearing and construction for your mailbox installation do you?
| Most people hire a dude hanging out at Home Depot and pay him a
| flat fee.
|
| 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.
| mytailorisrich wrote:
| The problem is that the expection was to document the software
| design in excruciating details (e.g. class diagrams with all
| fields and methods, etc.) before any coding. To the extreme you
| were meant to all the coding in your head and a Word document
| before doing it again in your IDE.
|
| This wastes a huge amount of time and usually the documents
| become obsolete as soon as you try to actually run some code.
|
| This is the very issue the Agile manifesto identifies and
| proposes a solution to when it says " _working software over
| comprehensive documentation_ ". 'Comprehensive' is a key word
| as they don't mean NO documentation but effectively just what's
| needed to plan and help people understand the code.
| hejcloud wrote:
| German speaking. You can take German IT to get an idea what
| would have happened to SWE if you'd have kept those
| bureaucratic methods from the 2000s as the backbone of all SWE
| endeavors: a horrible, expensive, non-working mess with barely
| any progress.
|
| I think what many people, esp. from outside the SWE world,
| don't get: Software engineering is a deeply social kind of
| work. There are dozens of solutions for the given problems, you
| have to agree on one that works for all peers. That's the job.
| Optimizing it for drawing funny diagrams is not an issue if not
| for communication.
| _dain_ wrote:
| I'm not familiar with how IT works in Germany. What's
| different about it? Got any stories?
| devin wrote:
| I'm also interested in the german software engineering
| culture. And also, heavy plus to this being a social problem
| more than a "engineers just need more time" problem. I tried
| to articulate this in another comment of mine but mostly beat
| around the bush. This is more directly what I was attempting
| to say.
| qwertywert_ wrote:
| Overdesign is one of the worst things to do. Trying to make
| something fit perfectly into some obscure pattern with horrible
| class hierarchies. Look at the linux kernel sources, it does
| not look "beautiful" to some architects but the actual ideas
| and patterns are simple, anyone can jump into it if they know
| C.
| mkozlows wrote:
| 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 people make bad designs today, sure, but it's not for a
| lack of formal methodologies, because average design quality
| was way worse back in the design patterns 'n' UML days.
| contravariant wrote:
| Could we bring back the UI people from that era though?
| Trying to standardize good software is insane but having a
| consistent UI with standard elements for all programs that's
| usable with both mouse and keyboard was kind of nice.
| fmajid wrote:
| Seconded. I once went to an IBM seminar with Grady Booch and
| seldom have I heard such an inane string of platitudes.
| Architecture Astronauts are the worst, and if there is one
| thing Agile can legitimately claim for, it's getting us rid
| of that plague.
| doctor_eval wrote:
| I agree with you both except that architects are alive and
| well. I worked with an ex IBM architect a couple of years
| ago. Lovely guy but for someone designing software systems,
| I found it remarkable that he didn't know how to write
| code.
| doctor_eval wrote:
| I don't think this is any more true than it ever was. If
| anything, the rise of open source libraries, GitHub and friends
| has made it easier than ever to reuse software and avoid NIH.
| This has lead to a different set of problems, but relative to
| when I was writing C in the 90s I'd say software reuse and
| design is far advanced from those days.
|
| I do however agree that design is sorely missing from the
| current software project management zeitgeist, which means it's
| done in a more ad hoc way. People are taking frameworks like
| Scrum far too literally, and I agree that in some cases there
| is little vision or overall architecture because the framework
| doesn't include these things. There should be design and review
| activities both before and after coding, but these are largely
| neglected from most project management frameworks. Scrum for
| example doesn't even include backlog management, which in my
| work is a critical activity.
|
| While that doesn't mean design, architecture and scope
| management is not done, it's certainly less visible than it
| might be.
|
| All of that said, I'm a big believer that the ultimate
| expression of any design is code. The design artefacts that
| come before code is written are scaffolding, age quickly, and
| are soon useless. So there's not much need to keep them around,
| and they are mostly of interest as preliminary directions.
|
| In this regard I'm a big fan of Jack Reeves essays from the
| same period at
| https://www.developerdotstar.com/mag/articles/reeves_design_...
| peanut-walrus wrote:
| Software architects, much like real architects, often end up
| with absolutely beautiful elegant designs which are unfit for
| purpose and have leaky roofs.
| ilyt wrote:
| No, that's the era of worst, shittiest legacy software to date.
| The computers were just fast enough to handle layers and layers
| of extraction and _oh boy_ industry loved to pile them one and
| UML was just another way to pile up the rot
| jrochkind1 wrote:
| > 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
| phrase "architecture astronaut" was a common epithet, and not a
| friendly one]
|
| That above paragraph [without the brackets], ironically, could
| certainly be said of "agile" more recently too. I don't know
| 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.
|
| But yeah, I'm pretty convinced going back to appointing some
| almighty deity architecture astronaut who isn't responsible for
| or involved in any implementation (let alone operations!), who
| hands down plans from on high after "memorizing all design
| patterns" and drafting some diagrams, never sullied by "contact
| with the enemy"... no thank you, but thank you.
|
| ----
|
| Instead of just complaining about that though, what I'll say in
| addition is -- I think the real problem is that engineers
| aren't given the _time_ to carefully consider top-level
| designs. it 's a basic business/resource issue -- until
| engineers have more breathing room to talk to each other and
| research and consider and come to decisions in an unhurried
| way, the top-level design stuff will remain chaotic. It's not
| an issue of appointing an ivory tower "architect", or something
| solved by it.
|
| Although sure, there should be senior and even "staff" or
| "principal" people with more authority/responsibility for
| higher-level designs.
|
| Everyone should be responsible for design at the level they are
| working. Everyone needs enough time to feel like they are doing
| it well, instead of running on a sweatshop code production
| treadmill.
| devin wrote:
| I tend to agree about the time thing, namely that people
| aren't given enough of it to sit down and take their time
| with design decisions. If you squint you can kind of see that
| "software architects" are a business's way of creating a
| "solution" to this problem, but with lackluster results.
|
| That said, I've been at places where management did a pretty
| good job of making sure that there was enough time to do this
| kind of work with middling results. People have to enjoy the
| work or feel invested in a way that makes them care about "3
| years from now", and sadly in a lot of places there's a lot
| of "whatever, it'll be fine for as long as I work here."
|
| It seemed to me that in let's say 50% of cases, having the
| extra time didn't really matter. Assumptions about what was
| being built were proven incorrect not long after a design was
| laid down and work had begun, or particular engineering types
| would create increasingly complicated designs with their time
| rather than doing the hard work of distilling the problem,
| sometimes including $PET_TECHNOLOGY as part of their
| solution.
|
| The "let's design something truly great" really has to be in
| a team's DNA in my experience or you wind up with a good
| design that isn't followed, one person who does all the work,
| a gold plated design, etc.
| jrumbut wrote:
| 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 things
| that would have taken too long to do before.
|
| And that was the intent of the Gang of Four book, not to
| teach you patterns you should copy mindlessly, but to give
| examples of how to identify and extract useful patterns from
| the software you've already written and describe them to
| others. Since that is a lot more difficult than memorization,
| very few took up that work.
| greiskul wrote:
| Design patterns are missing language features.
|
| http://norvig.com/design-patterns/
| _proofs wrote:
| while i feel as if i largely understand what you're pointing
| out, i kinda want to offer my own speculation as a SWE who is
| very guilty in thinking in terms of sequence diagrams (and also
| more formal UML) -- sometimes UML is so fucking bogged down
| with (impl) _details_ , i am just over here going "i don't give
| a shit about the (impl) details, i just want to know the
| abstract concept(s), and logical _flows_ , and focus on
| necessary system interactions" -- bc i can (and should at this
| stage) worry about (impl) details later.
|
| i prefer to reason about a system and component relationships
| using, say, a single word as representation, instead of glaring
| at one or many inheritance directionals, interface details, and
| other "field" information, which is usually conveyed in a UML
| node.
|
| i do not think the lack of formalism is a degradation -- we
| work with _abstractions_ after-all, so it makes sense to
| further leverage that fact and express things simply, at a
| high-level, and straight-forwardly -- you can pack a lot into a
| single word.
|
| of course as the nature of any tool, there is a time and a
| place for its application. but i don't think it is fair to call
| it a degradation.
| ghamelin wrote:
| Agreed. We published a post recently about how to interpret a
| sequence diagram based on the 7 basic features and how our dev
| tool makes them automatic and interactive.
| https://dev.to/appmap/quickly-learn-how-new-to-you-code-work...
| [deleted]
| avodonosov wrote:
| State machine diagram maye useful from time to time.
|
| Object diagrams are sometimes great illustrations of how data is
| structured. I specifically recommend object diagrams, not class
| diagrams for that. If you are learning unfamiliar system just by
| reading the code and making user interactions, its easy to loose
| track what is recorded where. Collecting your observations on a
| diagram you draw gradually will help to acumulate details and
| build a clear picture.
|
| Maintaining several simple object diagrams for main usage
| scenarious may help future newcomer developers to quickly grasp
| the implementation backbone.
| tonnydourado wrote:
| I work with non-distributed (ish) systems, and I use watered down
| class diagrams much more often than sequence diagrams.
|
| But even when I was working on more distributed systems, I found
| more value in state machines and simplified class diagrams,
| actually. I think most cases where you're using a sequence
| diagram, a state machine is a better tool. Both for thought, and
| for implementation. Surfacing implicit state machines can require
| some extra upfront design, but if you have a non-trivial amount
| of states, it's pretty much guaranteed to be worth it.
| knsv wrote:
| The problem with state machines that I run into often when
| using them, is "multi-dimensional" states.
|
| When managing to get that right they are great, otherwise you
| get loads of edges...
| sidpatil wrote:
| I'm not sure what you mean by "multi-dimensional" states. Is
| it something that statecharts [1] can help with?
|
| [1] https://statecharts.dev/
| barrkel wrote:
| The cross product of multiple state machines, I expect. If
| you try and use a single state diagram to encode the
| product of states, everything multiplies.
| michaelsbradley wrote:
| That's where statecharts can help.
| tonnydourado wrote:
| Not sure what you mean by multidimensional states?
| hwayne wrote:
| The car can be in drive, neutral, or reverse, the light can
| be red, green, yellow, or broken, the seatbelt can be off
| or on. That's 24 states.
| tonnydourado wrote:
| Ah, ok. That's kind of what I meant by upfront design,
| though. Yeah, mapping this out is gonna suck, but it's
| better than having it hidden in a bunch of ifs.
| th3h4mm3r wrote:
| I'm totally agree.
| scotty79 wrote:
| Hierarchical finite state machines are nice too.
| manbash wrote:
| I consider myself an advocate of sequence diagrams (of all other
| UML diagrams), so I wonder why the article doesn't mention that
| this type of diagrams is meant to depict testable flows the
| software components.
|
| It's nice and all that you can clarify to your team what you want
| to gain (the big picture), and it's also nice if you want to
| explain how (details), but in my opinion it's not worth much if
| your sequence diagram doesn't explain test cases clearly and
| expect for them to be written.
| Supermancho wrote:
| Even the second graphic in that article is confusing enough that
| I would be asked to redraw it in a different way. A clever tool
| that programmers can learn and understand is often, not expedient
| or less efficient for others.
| kazinator wrote:
| For understanding the structure of an object in memory, and box
| and arrow diagram of a few example _instance_ is worth a hundred
| diagrams showing _type_.
|
| UML is useless to the extent that type is useless.
|
| The exact shape in which constructed class instances are hooked
| up together can easily be where all the semantics lies.
| qznc wrote:
| I like the arrow semantics: Dashed with line tip is ,,depends
| on". Straight with triangle tip is ,,inherits from".
| Standardizing them is useful.
| cynicalsecurity wrote:
| UML is dead. Let is rest in peace.
| michaelsbradley wrote:
| Statecharts[1] predate UML, and became part of UML[2].
|
| From the time of their invention to the present, people have
| devised systems for serializing (i.e. as data structures and
| code) statecharts and translating them to (or interpreting them
| as) executable programs[3].
|
| While they may not be all the rage and take some discipline to
| learn and use effectively (what software tool/concept doesn't?),
| they can be a valuable tool for building reactive systems:
| A typical reactive system exhibits the following distinctive
| characteristics: It continuously interacts with its
| environment, using inputs and outputs that are either
| continuous in time or discrete. The inputs and outputs are
| often asynchronous, meaning that they may arrive or change
| values unpredictably at any point in time. This should be
| contrasted with transformational systems, in which the timing of
| the inputs and outputs is much more predictable. A
| transformational system repeatedly waits for all its
| inputs to arrive, carries out some processing, and outputs
| the results when the processing is done. It must be
| able to respond to interrupts, that is, high-priority
| events, even when it is busy doing something else.
| Its operation and reaction to inputs often reflects stringent
| time requirements. It has many possible
| operational scenarios, depending on the current mode of
| operation and the current values of its data as well as its
| past behavior. It is very often based on interacting
| processes that operate in parallel. Examples
| of reactive systems include on-line interactive systems,
| such as automatic teller machines (ATMs) and flight reservation
| systems; computer-embedded systems, such as avionics, automotive,
| and telecommunication systems; and control systems, such
| as chemical and manufacturing systems.
|
| -- Harel and Politi, _Modeling Reactive Systems with Statecharts:
| The STATEMATE Approach_ (1998) [4]
|
| [1]
| https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/res...
|
| [2] https://en.wikipedia.org/wiki/UML_state_machine
|
| [3] https://userweb.cs.txstate.edu/~rp31/papersSP/stateMate.pdf
|
| [&] https://www.w3.org/TR/scxml/
|
| [&] https://github.com/jbeard4/SCION
|
| [&] https://github.com/statelyai/xstate
|
| [&] https://www.rtsys.informatik.uni-kiel.de/en/archive/kieler
|
| [&] search the web and you'll find more
|
| [4]
| https://www.wisdom.weizmann.ac.il/~harel/reactive_systems.ht...
| tabtab wrote:
| UML was yet another fad overdone. Many IT fads do produce useful
| niches or specific products, but the impression given at the time
| is they'll replace most of what came before. That's rarely the
| case. I can list about 25 "trends" like that since the late 80's.
| Chasing fads has gummed up too many stacks and standards.
| imiric wrote:
| I also find sequence diagrams to be the most useful, but disagree
| that the rest of UML is useless. Class, component, package,
| activity and state machine diagrams are all useful ways to model
| the structure and behavior of a system visually.
|
| The only reason the other diagram types fell out of favor is
| because of the development methodology change starting in the
| early 2000s. The industry started rejecting Waterfall, early
| design and system architects, in favor of Agile, just-in-time
| design and empowering developers. So we saw no need for these
| visual design tools to model the entire system, since we ended up
| changing the design during the lifetime of the project anyway.
| The drawback of this, of course, is that with the Agile approach
| these diagrams never end up being made, so developers are left to
| assemble their own mental model of the system, which hurts the
| overall comprehension. Most developers IME actively reject these
| diagrams because they are quickly outdated, or require constant
| changes to keep up to date, which is true, but this is not unlike
| documentation, comments, and a myriad other things that needs to
| be synced with the code.
|
| Yet sequence diagrams are useful in a wide variety of use cases,
| and let's face it, they're the easiest ones to comprehend, and
| are even understandable by a non-technical audience. In contrast
| to the other UML diagram types that have strange notations and
| the information is more densely packed.
| Kwpolska wrote:
| Class diagrams feel pointless to me, this information works
| better as code, and how do you draw a class diagram with more
| than 10 classes and keep it readable?
| prepend wrote:
| I think class diagrams are a good way to visually display
| classes and hierarchy. If I have a package or module that has
| 10 classes and I want to show inheritance, properties, and
| methods I think it's easier to show the class diagram then
| hand someone 10+ source files.
|
| Also, class diagrams are more useful when you can't give out
| source.
|
| That being said, I think you can autogenerate class diagrams
| from code so it's not like you should spend a lot of time
| making them.
| johannes1234321 wrote:
| If you use class diagrams to show the "truth" you are in
| painland in my experience.
|
| However I sometimes find them useful to extract key parts of
| the system and showing their interaction. Cutting away many
| attributes, many helper classes, many other things.
|
| That can lead to pictures which are quick to grasp and then
| allow further digging based on code.
| holoduke wrote:
| 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.
| radicalbyte wrote:
| 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..
| holoduke wrote:
| Dont you want to discuss and talk about a design before
| you even touch a keyboard? In my projects we always
| discus high level overviews with pen and whiteboards.
| Nobody should even dare to touch a keyboard.
| lesuorac wrote:
| > The only reason the other diagram types fell out of favor is
| because of the development methodology change starting in the
| early 2000s. The industry started rejecting Waterfall, early
| design and system architects, in favor of Agile, just-in-time
| design and empowering developers.
|
| I dunno, whenever I heard people say they're doing Agile all I
| see is them doing Waterfall without documentation.
| codalan wrote:
| UML was (and still is) really useful when embarking on a
| greenfield design. Most people I've worked with know some basic
| UML notation, so when it comes to whiteboarding and refining
| the design, it makes sense to go with that.
|
| In terms of artifacts for future maintainers? Maybe not as
| helpful. As previous posters have mentioned, the diagrams go
| stale very quickly if the engineering department isn't
| disciplined about keeping documentation up to date. But this is
| true for any documentation.
|
| Some diagrams (class and activity, in particular) are less
| valuable as time passes. I can get the idea of the class
| structure by just looking at the code itself. The class diagram
| just ends up being a stale representation of the code.
|
| It is unfortunate that UML has developed a reputation as being
| overly complex. Now I see more ad-hoc diagrams being created,
| with whatever notation/symbols make sense to author, rather
| than using a common diagram system that can be read by many.
| kazinator wrote:
| > _Class, component, package, activity and state machine
| diagrams are all useful ways to model the structure and
| behavior of a system visually._
|
| I completely agree with you.
|
| It's a good way for _other people_ to present information, for
| me to look at.
|
| I just won't do it myself.
|
| It's not only me; and that's why it's dead.
|
| I won't do it because the first thing that comes to mind is how
| it will go out of date in a month, and have to be maintained to
| stay accurate.
|
| 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.
| slowmovintarget wrote:
| I'll draw those diagrams... on a whiteboard, sans boxes
| (Tufte). Great for point-in-time communication, less useful
| as specifications.
| lemmsjid wrote:
| I've taken a throwaway approach to diagramming, where I'll
| produce them more or less on demand for a meeting or
| presentation, but not think of them as an enduring artifact.
| PlantUML is my friend here because I can knock out ugly but
| gets-the-point-across diagrams in 30 minutes before a meeting
| and check them into source control, so I can then take the
| bones of older diagrams and rework them for a fresh meeting.
|
| I used to whiteboard for this, but that hasn't carried over
| well in the remote world. What I miss about whiteboarding
| though is that you can tell a story as you draw, so whoever's
| viewing can watch something unfold from a blank slate while
| I'm walking them through the history of whatever system we're
| describing. That said, I can make a PlantUML diagram much
| more correct than a whiteboard.
|
| All that said I too would love for more of that to be
| automated increasingly through AI. And I suppose it should
| make sense conceptually, because for me the value of a
| crafted diagram over an automated one is that no one really
| wants to look at the insane ERD of an OLTP database or a
| production object model. They want the digestible high level
| vision of the important bits, or the bits that are relevant
| to the conversation taking place. So it's a summarization
| problem. How to get the right data to produce a correct
| summary is interesting--I'm sure if I look there's a dozen
| papers to read on a similar subject :).
| 4lejandrito wrote:
| For whiteboarding remotely I use https://excalidraw.com. I
| use it exactly for your use case. I've told live stories
| with it.
| theK wrote:
| excalidraw is great especially the paid product. One of
| the cases of a very good open core business plan. I hope
| they do well.
| theK wrote:
| That's a great approach that has worked for me too. I think
| plant is a great little system. Not only can you get your
| point over in a handful of lines of text but I have found
| out that it is quite easy to generate the plantuml
| programmatically. So instead of having to keep docs and
| code in sync you can end up generating your graphs in ci.
| The upside compared to big diagramming products is that
| plant requites no boilerplate and you can provably grep and
| sed most diagrams out of your codebase which is a quite low
| barrier to entry.
| agumonkey wrote:
| surprisingly, for average crowds, who usually describe stuff
| in fluffy text, UML-like diagrams suddenly feel like going
| from VB5 to python3
| johnyzee wrote:
| > _Most developers IME actively reject these diagrams because
| they are quickly outdated, or require constant changes to keep
| up to date_
|
| Plans are useless, but planning is indispensable. The act of
| diagramming things up front is useful to get you thinking about
| the problem space and come up with the outline of a solution.
| After that, keeping the initial design documents up-to-date is
| optional, and often might not be necessary.
| imiric wrote:
| I think about it the other way around, actually.
|
| During the prototyping phase diagrams do help, but they're
| usually sketches written on paper or whiteboard. You don't
| want to waste time with tools and strict specifications to
| design perfect diagrams, mostly because the design will
| change frequently, and you don't want your tools getting in
| the way.
|
| Later on, once the design has settled down and maybe once
| development has started, those initial diagrams are mostly
| worthless, but you _do_ want neat and professionally done
| design documents that describe the system. This allows you to
| share them with coworkers, and quickly onboard other
| developers to the project. Hopefully by then the design won't
| change frequently, which would make updating these a chore.
| cubefox wrote:
| People who say "UML is useless" basically say "diagrams are
| useless". Which obviously isn't true. The alternative to UML is
| everyone inventing their own "diagram language" when they want
| to visualize something.
|
| Moreover, I think comparing different UML diagrams can also be
| enlightening for university students. E.g. state machine
| digrams look quite similar to activity diagrams, but the former
| emphasize states and the latter actions. And class diagrams let
| you learn the connection between class structures of OOP
| languages and database structures.
|
| UML lets you visually learn the abstract higher level concepts
| without having to rely on irrelevant specifics of practical
| implementations, or just on dry theoretical text.
| pshc wrote:
| The superior alternative is drawing a diagram on a piece of
| paper to exercise the mind and show to collaborators, and
| never setting foot anywhere close to the UML tarpit.
| IshKebab wrote:
| > everyone inventing their own "diagram language"
|
| This is clearly better than UML. UML is full of shorthands
| that nobody remembers. That's worse than people making
| labelled custom diagrams.
|
| Here's an example:
|
| https://buck2.build/docs/concepts/concept_map/
|
| Imagine how much worse that would be with UML arrows.
| cubefox wrote:
| That concept map example is only a loose association of
| ideas, where the nodes aren't of the same type (e.g. event,
| state, class etc), or sorted into types, and apparently
| included quite arbitrarily. Mind maps are similarly loose.
| UML is for when you want more precise diagrams about a
| fixed subject matter.
|
| I agree on the "shorthands", like empty/filled arrows, that
| people may not know. But there isn't much alternative to
| such shorthands other than leaving them out completely,
| which wouldn't be an advantage. In diagrams some
| information is either conveyed succinctly or not at all.
| The "alternative" is a block of text instead of a diagram.
| radicalbyte wrote:
| UML as a projection is fine and a valuable tool.
|
| Starting with UML to describe a set of classes or - worse yet
| - an entire system is lunacy and a massive red flag.
| pavon wrote:
| There are other types of diagrams beyond what UML formalizes.
| For example, Data Flow diagrams can be very helpful, but they
| don't exist in UML (Component, Composite Structure, and
| Activity diagrams all have similarities with Data Flow
| diagrams, but none are really a great fit).
| auggierose wrote:
| The nice thing about visual stuff is that it is self-
| explanatory. Instead of needing to read a book about UML
| first, maybe just use some prose in addition to your
| diagrams, and you don't need UML at all then. That's also
| more flexibel.
| bigbillheck wrote:
| > it is self-explanatory
|
| It most certainly is not.
| _dain_ wrote:
| is there any way for blind people to read UML diagrams? they
| don't seem very accessible.
| Scubabear68 wrote:
| I am shocked - I completely agree with the author on all points!
|
| Sequence diagrams are awesome. The rest of UML (and all the crazy
| Rational Rose nonsense!) was so much angst over such petty things
| on notation.
|
| And then there is the dumpster fire called Enterprise
| Architect...
| swayvil wrote:
| Be me, writing VB for state gov thing. Tell me to figure out UML.
| Boggled and fried.
| strictfp wrote:
| Class diagrams and object diagrams are also really useful, for
| instance when making presentations.
|
| The problem with UML is that the industry went overboard with
| it's usage, like it did with pretty much every tech trend.
| scotty79 wrote:
| UML would be fine if it was not treated as a design tool, but as
| an inspection and visualisation tool of already (partially) built
| systems.
|
| The way it is today is that when somebody insists on designing in
| UML the design gets created then implementation is at best only
| attempted, before the whole thing gets scrapped and the actual
| working system is built because most systems are only discovered
| as they are being built.
| eurekin wrote:
| I'm still waiting intently for debugging tools to be able to
| create * object * diagrams of an running app. Debuggers are
| excellent, but I keep forgetting, if the object in question is
| @Hdj637 or @HU83NS
| rTX5CMRXIfFG wrote:
| Class diagrams are pretty good too? When done with just a few
| types, that is, and without all the complex unnecessary nearly-
| Java-specific stuff that they added later on.
| huydotnet wrote:
| Sequence diagram is not the only useful thing. A mix of component
| + flow diagram can be helpful to sketch out architecture ideas
| too.
|
| I use diagrams a lot at work, to the point that I get tired of
| drawing or writing UML code, so I built a text-to-diagram tool
| [1] to help translate ideas in my mind into diagrams. Quite fun
| to use.
|
| [1]: https://chatuml.com
| talkingtab wrote:
| Sequence diagrams are outstandingly good and useful. I have a
| very complex set of interactions between two different servers
| involving user interfaces, back ends and server to server fetches
| (somewhat like Oauth but more). Using sequence diagrams to
| document this complex process helped me identify mistakes and
| allowed me to simplify the process. Highly recommended.
| kovacs wrote:
| I feel validated by this headline/post. I've said the same thing
| over and over in my career and am always astounded when I get
| pushback on using them as a means to describe systems and
| interactions, including from some managers (that weren't coders
| very long), that would claim "nobody uses them, just read the
| code".
|
| I don't know how you communicate how systems work without them.
| You either create a terrible non visual version in the docs or a
| person ends up drawing them on a whiteboard from memory to pass
| that knowledge down.
| sirwhinesalot wrote:
| I disagree that sequence diagrams are the only useful thing in
| UML. I will say the the most taught diagram type (class diagrams)
| is not only by far the most useless, it is downright detrimental
| to use.
|
| Wouldn't be surprised if the main reason UML ended so despised is
| 99% to do with class diagrams.
|
| Sequence diagrams are really nice though.
| tedivm wrote:
| I really love Mermaid Diagrams. This is one of the best libraries
| to come out. I'm writing a book, and being able to generate
| diagrams with mermaid and then customize the CSS to meet the
| guidelines from my editor has been fantastic. I've started
| including a lot more diagrams in my projects and documentation as
| well. It's just such a good tool.
| knsv wrote:
| Thanks I am happy to hear that!
| w1nst0nsm1th wrote:
| I would also add Flow Diagram.
| c4mpute wrote:
| I think autogenerating UML from existing code to get an overview
| over e.g. your database schema, state machine or class hierarchy
| is fine. Hand-drawn UML is useless busywork, it is usually faster
| and quicker to just write the code. Also, autogenerated UML
| doesn't go stale as easily, since you can just automatically
| recreate it.
|
| And I agree, the most useful diagram type is a sequence diagram.
| The rest is often useless because OOP has declined, weird arrow
| types are unintuitive, language features do not always correspond
| to UML features and UML tooling doesn't fit very well into common
| software development methods. E.g. you cannot 'git diff' UML
| diagrams; while it would be theoretically possible (git diff can
| take helpers), no software implements this, that I know of.
|
| Overall, about UML's decline, good riddance. Throwing boxes and
| arrows at a whiteboard occasionally (without tons of formal
| semantics) is all anyone needs.
| MilStdJunkie wrote:
| Yeah, Mermaid gets it. Mermaid . . wait a second . . oh, ok,
| these are the same people that do Mermaid.js, they're just trying
| to make a living doing it.
|
| Another useful chart type provided by Mermaid.js is the git
| diagram, which I use _all the time_ when brainstorming change
| processes, especially for other folks who might not be git-
| conversant.
|
| https://mermaid.js.org/syntax/gitgraph.html
| imiric wrote:
| I find Mermaid's syntax difficult to use and understand past
| the simplest examples. I've also run into some strange edge
| cases with it, but can't remember the details right now.
|
| Out of these text-to-diagram tools, D2's syntax seems the
| friendliest to me. See https://text-to-diagram.com/.
| MilStdJunkie wrote:
| Is there a way to get a git diagram out of D2? It does have
| nicely streamlined syntax.
|
| One thing that worries me is that the profusion of text-based
| graph description languages will result in a family of
| software that's unparseable due to its success. We have
| Graphviz, GNUplot, PlantUML, BlockDiag, Mermaid, Kroki, Vega,
| and too many others to count - but we don't have a Pandoc.
| galkk wrote:
| > Contrary to our expectations and previous work, the majority of
| sketches and diagrams contained at least some UML elements.
|
| I don't have access to the paper, but I can't shake the feeling
| that those "some UML elements" were boxes with class names in
| them or something like that.
| jxramos wrote:
| I just referenced the concept of multiplicity in the values of
| pytest fixtures a single fixture may return just yesterday and I
| referenced it in the context of UML to make my point. Numerical
| distinctions in instance counts and collections and what not is a
| valuable articulation I think UML encapsulates. Maybe there's
| other ways to communicate this concept but if someone talks of
| multiplicity in software design UML is directly where my mind
| goes.
| brikelly wrote:
| Sequence diagrams are great, but creating them by hand is a pain.
| It's not just manual toil, they also go out of date. AppMap
| (where I work) can generate them automatically based on runtime
| analysis of an application:
| https://www.youtube.com/watch?v=8l4-hNih_GQ
| rerdavies wrote:
| 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:
| https://rerdavies.github.io/pipedal/Architecture.html
|
| 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.
___________________________________________________________________
(page generated 2023-06-15 23:00 UTC)