23 ms·

Sequence diagrams, the only good thing UML brought to software development

• 111111IIIIIII 3y ago
  I reached the same conclusion within approximately 1 week of first learning about UML.
• baudaux 3y ago
  Plantuml is a really convenient tool for drawing diagrams
  • rvbissell 3y ago
    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.
    • andrewshadura 3y ago
      It exists. Ditaa.
• knsv 3y ago
  Sequence diagrams really shine when you’re documenting different parts of a system and the various ways these parts interact with each other.
  • Veuxdo 3y ago
    You could say that's the only thing they can do, by definition.
• qznc 3y ago
  I like the arrow semantics: Dashed with line tip is „depends on“. Straight with triangle tip is „inherits from“. Standardizing them is useful.
• eurekin 3y ago
  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
• jxramos 3y ago
  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.
• thesnide 3y ago
  I discovered FMC some time ago, and it really feels "UML, the good parts". Fundamental Modeling Concepts http://fmc-modeling.org/ 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)
• lunatuna 3y ago
  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 3y ago
    I agree, not having to be an expert in order to understand is important!
• Dig1t 3y ago
  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.
  • knsv 3y ago
    Was it easier the second time around? :)
  • civilized 3y ago
    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)
    • ryanisnan 3y ago
      I'd offer another, possible reason: - University professors who remain exclusively in academia missed the rising tide and teach what they know
    • comfypotato 3y ago
      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.
• JohnFen 3y ago
  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.
• simmerup 3y ago
  UML is also really useful for modelling relational databases
  • DaiPlusPlus 3y ago
    May I ask what you feel UML brings-to-the-table that we don't already get with existing (non-UML) ER-diagrams?
    • intrasight 3y ago
      UML is both broader and more formal that ER
      • tabtab 3y ago
        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 3y ago
          > 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.
• strictfp 3y ago
  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.
• tedivm 3y ago
  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 3y ago
    Thanks I am happy to hear that!
• MilStdJunkie 3y ago
  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 https://mermaid.js.org/syntax/gitgraph.html
  • imiric 3y ago
    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/ https://text-to-diagram.com/.
    • MilStdJunkie 3y ago
      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.
      • MikeSchurman 3y ago
        pandia has a nice ring to it, wikipedia: In Greek mythology, the goddess Pandia or Pandeia was a daughter of Zeus and the goddess Selene, the Greek personification of the moon.
• hcarvalhoalves 3y ago
  > 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 https://c4model.com
• syntheweave 3y ago
  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.
• zabzonk 3y ago
  UML is completely crap as a design language. But it can sometimes be useful as a documentation language.
  • pydry 3y ago
    It's crap at that too. It was an excuse to sell rational rose. It doesn't need to be excused.
    • zabzonk 3y ago
      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.
• tonnydourado 3y ago
  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 3y ago
    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 3y ago
      I'm not sure what you mean by "multi-dimensional" states. Is it something that statecharts [1] can help with? [1] https://statecharts.dev/ https://statecharts.dev/
      • barrkel 3y ago
        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 3y ago
          That’s where statecharts can help.
      • RossBencina 3y ago
        UML Statecharts are Harel Statecharts, which are hierarchical state machines. Described here: Statecharts - A visual formalism for complex systems. David Harel. 1987 https://archive.org/details/7.-statecharts https://archive.org/details/7.-statecharts Looks like you can also freely download the paper from here: https://www.sciencedirect.com/science/article/pii/0167642387900359 https://www.sciencedirect.com/science/article/pii/0167642387...
• tabtab 3y ago
  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 3y ago
  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.
  • kazinator 3y ago
    > 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 3y ago
      I'll draw those diagrams... on a whiteboard, sans boxes (Tufte). Great for point-in-time communication, less useful as specifications.
• Scubabear68 3y ago
  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…
• Veuxdo 3y ago
  Sequence diagrams for showing specific interactions, box-and-line diagrams for showing static relations.
• galkk 3y ago
  > 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.
• readthenotes1 3y ago
  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?
  • atribecalledqst 3y ago
    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.
  • ofrzeta 3y ago
    "UML 2.0 Sequence Diagram is strongly inspired by the ITU-T MSC" https://en.wikipedia.org/wiki/Message_sequence_chart https://en.wikipedia.org/wiki/Message_sequence_chart
  • mhandley 3y ago
    There are sequence diagrams in the original 1981 TCP specification: https://www.rfc-editor.org/rfc/rfc793 https://www.rfc-editor.org/rfc/rfc793 See figures 7-14.
• convolvatron 3y ago
  I used sequence diagrams in the 80s doing network protocol design. UML was apparently published in 1995
• sylens 3y ago
  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.
• neuronexmachina 3y ago
  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"
• TacticalCoder 3y ago
  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 3y ago
  I don't really see them as an advance on the century old flow charts.
  • Kon-Peki 3y ago
    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.
• myth2018 3y ago
  > 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 3y ago
  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 3y ago
    J2EE hasn't been called that in 20 years. It's JEE now, and it's much nicer.
• narag 3y ago
  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.
• therealmarv 3y ago
  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 3y ago
    You're lucky if that was the most useless thing you learned. Many peoples' degrees were useless in their entirety!
  • lost_tourist 3y ago
    state diagrams and sequence charts for me, for sure
• th3h4mm3r 3y ago
  I'm totally agree.
• manbash 3y ago
  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.
• smusamashah 3y ago
  https://sequencediagram.org/ 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 3y ago
    Good tool. They really need to change the cursor on hover to give some hint that you can draw arrows that way!
  • tandr 3y ago
    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.
• manuel_w 3y ago
  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 3y ago
    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...
• neilv 3y ago
  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.)
  • mikepurvis 3y ago
    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.
• RandyRanderson 3y ago
  With any non-trivial set of messages, seq diagrams become unwieldy. Always use communication diagrams over sequence as a first choice.
  • preseinger 3y ago
    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"
• kazinator 3y ago
  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.
• deleted 3y ago
  [deleted]
• Supermancho 3y ago
  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.
• rTX5CMRXIfFG 3y ago
  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.
• talkingtab 3y ago
  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 3y ago
  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.
• c4mpute 3y ago
  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.
• perrygeo 3y ago
  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.
• Graffur 3y ago
  When will people learn.. you need to write down stuff. Pictures are a good addition to writing, not the other way around.
• gratitoad 3y ago
  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.
• throwawaymaths 3y ago
  Oh come on. Uml database tables aren't half bad
• draw_down 3y ago
  [dead]
• ghamelin 3y ago
  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-works-using-sequence-diagrams-h9g https://dev.to/appmap/quickly-learn-how-new-to-you-code-work...
• brikelly 3y ago
  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 https://www.youtube.com/watch?v=8l4-hNih_GQ
• blueberrychpstx 3y ago
  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!?
• nivertech 3y ago
  not only, also UML Statecharts[1,2] basd on Harel Statechars[3] -- 1. https://en.wikipedia.org/wiki/UML_state_machine https://en.wikipedia.org/wiki/UML_state_machine 2. https://en.wikipedia.org/wiki/State_diagram#Harel_statechart https://en.wikipedia.org/wiki/State_diagram#Harel_statechart 3. https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.pdf https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts....
• ThinkBeat 3y ago
  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.
  • snapdaddy 3y ago
    I agree completely. I tend to do 'UML light', where I don't worry about the finer details (e.g. marking fields public or private). The best solution is one where I can sketch out the outlines of a class and have some tool automatically generate UML which I can then edit. And C4 diagrams are great for explaining software architecture, which wouldn't have been possible without UML and esp. class diagrams.
• jacobr1 3y ago
  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.
• travisgriggs 3y ago
  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.
• barbariangrunge 3y ago
  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
• treprinum 3y ago
  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.
• jacobsenscott 3y ago
  I use sequence diagrams the most, but I also like the state charts, and the simple class diagrams.
• michaelsbradley 3y ago
  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/resources/statecharts.pdf https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/res... [2] https://en.wikipedia.org/wiki/UML_state_machine https://en.wikipedia.org/wiki/UML_state_machine [3] https://userweb.cs.txstate.edu/~rp31/papersSP/stateMate.pdf https://userweb.cs.txstate.edu/~rp31/papersSP/stateMate.pdf [&] https://www.w3.org/TR/scxml/ https://www.w3.org/TR/scxml/ [&] https://github.com/jbeard4/SCION https://github.com/jbeard4/SCION [&] https://github.com/statelyai/xstate https://github.com/statelyai/xstate [&] https://www.rtsys.informatik.uni-kiel.de/en/archive/kieler 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.html https://www.wisdom.weizmann.ac.il/~harel/reactive_systems.ht...
• sirwhinesalot 3y ago
  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.
• da39a3ee 3y ago
  I'm sure mermaid is nice but if you haven't tried https://swimlanes.io/ 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.
• 0xDEF 3y ago
  State machines and activity diagrams have their uses.
• w1nst0nsm1th 3y ago
  I would also add Flow Diagram.
• contingencies 3y ago
  https://www.mcternan.me.uk/mscgen/ https://www.mcternan.me.uk/mscgen/
• scotty79 3y ago
  Hierarchical finite state machines are nice too.
• scotty79 3y ago
  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.
• deleted 3y ago
  [deleted]
• avodonosov 3y ago
  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.
• dahwolf 3y ago
  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.
  • rr808 3y ago
    Now hardware and bandwidth is so cheap now you dont have to care about design so much. Make a service, JSON in JSON out. Some kind of loose versioning but no formal schema and fix it up as it goes.
  • shinycode 3y ago
    So sad and so true
  • colordrops 3y ago
    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.
    • phs318u 3y ago
      Just as well we no longer cargo-cult any practices these days.
      • deleted 3y ago
• garganzol 3y ago
  Several phrases from that era are still echoing in my head from time to time: Grady Booch, Rational Rose.
• huydotnet 3y ago
  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 https://chatuml.com
• mhandley 3y ago
  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 https://www.rfc-editor.org/rfc/rfc793 Edit: there are a form of sequence diagram in an early FTP specification from 1971: https://www.rfc-editor.org/rfc/rfc172.html https://www.rfc-editor.org/rfc/rfc172.html
  • esfandia 3y ago
    Exactly, UML mostly borrowed from existing representations and its purpose was standardizing semantics and providing some consistency among the diagrams.
  • Rochus 3y ago
    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.
    • cachvico 3y ago
      Who's Jacobson? Google doesn't turn anything up. Neither does "Ericsson Approach" for that matter..
      • agumonkey 3y ago
        This guy https://en.wikipedia.org/wiki/Ivar_Jacobson https://en.wikipedia.org/wiki/Ivar_Jacobson
        • cachvico 3y ago
          Thanks!
      • Rochus 3y ago
• deleted 3y ago
  [deleted]
• mehh 3y ago
  Use case diagrams are also very useful, I find in clarifying why are we building something.
• CyrsBel 3y ago
  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.
• golemiprague 3y ago
  [dead]
• cynicalsecurity 3y ago
  UML is dead. Let is rest in peace.
• dakial1 3y ago
  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/ https://sequencediagram.org/
• _dain_ 3y ago
  is there any way for blind people to read UML diagrams? they don't seem very accessible.
• rerdavies 3y ago
  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.
• Rochus 3y ago
  So we're back in the sixties, even 20 years before Objectory, see e.g. https://web.archive.org/web/20060622072014if_/http://www.tcrug.org:80/Documents/PPM02%20final.ppt https://web.archive.org/web/20060622072014if_/http://www.tcr....
• deleted 3y ago
  [deleted]
• interrupt21h 3y ago
  UML may be one of the slickest things to collaborate with ChatGPT on...It's one of those things that can be incredibly useful but more often than not the time suck just isn't worth it...well- just describe the type of graph you want in plain English and the type of markup to use. For example this single prompt (real)... ”Please convert the following to a PlantUML flow diagram. Partition if necessary." [Source Code]
• rektide 3y ago
  I adore how well this article cites sources at the top. Gold links to let others build the case. I don't know how important it could have been, but the threads here don't talk a lot about UML being more than just a design tool. We think of it as a way to draw pretty diagrams for documents. And we think of architect astronauts who alas all too often weren't great peers, weren't wise experienced seasoned sages. But there was a subtle current of an idea, that coding might evolve beyond source files of text that were hand authored. Computer aided code. UML still seems like a potential good/great intermediary target for machine learning to me, or for refactoring. If we could better get UML snapshots of the code & transmogify them into new shapes/states. UML got damned as much as anything because it existed in a pre-predominantly-open-source world, where it was interlinked with wild & complex vendor tools & methodologies, ans these kinds of flexible abstract representation malleable code systems existed in limited/weak forms, deeply tied to ultra expensive 100% proprietary tools, that only a scant % of people who'd touched uml had any knowledge of, and few of them ever really witnessed any tapping the power of these possibilities. What we think of uml is just a shadow of a bigger idea.
• phendrenad2 3y ago
  UML was a good idea, but at some point it became this ever-expanding attempt to model every business process and left software far behind.
• nobodyandproud 3y ago
  UML as a 4GL and coding the “important parts” died and I’m glad for it. Turning visualizations and encoding all interfaces and interactions made things cryptic. Using diagrams sparsely to explain the main design ideas visually? Absolutely.
• PaulHoule 3y ago
  UML isn't that bad but it isn't that good. I was involved in a project based on OMG's Meta Object Facility. The MOF is a tiny system which was designed to be sufficient for bootstrapping an implementation of UML 2 but I found out that the bootstrapping is not so straightforward (I think you have to manifest some objects from UML 1 that doesn't exist in UML 2) and there are some chicken-and-egg problems to resolve but I think it would be possible to build something that, in several stages, can build a complete set of stubs for UML 2 itself as well as any objects defined inside UML 2. I got my project done without doing the whole bootstrap so I am still wondering... I've solved so many chicken-and-egg problems that nobody else has and it's earned me just about $0 and 0 cents.
• meling 3y ago
  I agree with the article that sequence diagrams are great, but I’ve also used state diagrams (not the formal kind from UML) a fair bit for sketching state transitions.
• latency-guy2 3y ago
  UML is also good for another thing, and that's been endless amounts of blog spam and article fodder
  • rswail 3y ago
    and consulting fees!
• kitd 3y ago
  Sequence diagrams are good when you're already inside the system. Showing my age here but IMO, for sketching a high-level view of the whole system and how its components interact, nothing beats SSADM's data flow diagrams. You can go as detailed as you like. Break up parts into a new component: draw a ring around them, network traffic: note where the flows cross the rings and document the message sizes and rates. Sigh Happy days ...
• wangvnn 3y ago
  object interaction diagram is better than sequence diagram
• hasa 3y ago
  I remember times in 90's when we planned a software system in UML powered tool called Rational Rose. Oh my god its was clumsy and slow process. But yes, sequence diagrams are very useful tool.
• jillesvangurp 3y ago
  I've use sequence diagrams a few times. I find any kind of diagram tooling to be a tedious time sink. The resulting output is a talking point at best. Some window dressing for a presentation or internal document. Fluff you add to impress some easily impressed managers or clients. I always feel slightly dirty doing stuff like this. I have UML distilled on my shelf. A signed copy even. Haven't opened it in over two decades. It's obsolete. Diagrams are communication and marketing assets at best. They are not creative tools. You create them for other people; not for yourself. And it takes a lot of effort to create them. If you measure the value of your time in dollars per hour (as your clients/employer should be doing), a good diagram can be several hours of work. So, it's expensive. A few hundred dollars is nothing. Next time you see a diagram, ask yourself the question "would I pay 300$ for this thing?". In my case, the answer predictably is "hell no" 100% of the time. Asking the question is kind of answering it. Diagrams are rarely helpful. Either they are way to simple to add much value or way to detailed and hard to understand. There seems no middle ground here. So, you have three or four things with some arrows and labels. Well, yay! Tell me something I didn't know already. Diagrams are low value window dressing. A literal waste of time and money. I do them rarely, reluctantly, and only when people really insist on them (and I'll push back a little). I find tools in this space tedious and frustratingly slow to use. I have more interesting things to do typically. If I do them at all, they are going to be a quick and dirty job. It's not just me. Objectively, diagrams are very uncommon in software development these days. They are not part of regular software development processes, clients don't ask for them anymore, the vast majority of projects (and close to 100% of OSS projects) don't have them, etc.
  • self 3y ago
    > And it takes a lot of effort to create them. Have you tried mermaidjs? It's probably related to mermaidchart.com -- I don't know. The first sequence diagram in the article boils down to this: sequenceDiagram Customer->>Bank: Login request Bank-->>Customer: Login approval with a fancier image for the customer than a box. Try it out at https://mermaid.live https://mermaid.live (linked from https://mermaid.js.org/ https://mermaid.js.org/) Or this one, from a service I worked on a couple of years ago: sequenceDiagram Title: Service Signup autonumber User ->> App: User enters email address and password App ->> Server: Makes API call to register the user alt is not registered or already registered Server ->> App: Sends a token for authenticated API calls App ->> App: Generates unique ID App ->> Server: Makes API call to link user's account with unique ID else some other error Server ->> App: Returns [TODO: add error cases here] error App ->> User: Display error end I hated drawing diagrams with a mouse, but when I found mermaid, I started using sequence diagrams everywhere. > Diagrams are low value window dressing. It's about communication, as the article said. The people who needs the diagrams the most are often not tech-savvy.
• psychoslave 3y ago
  UML is great to clarify situations that are harder to grasp with other communication tools. And by communication, I don’t mean only with other, but also with oneself. Cerntainly UML is not always the best tool, but I see no point to pretend it’s a garbage toolbox no one should care about except for the only tool that ever helped for the work you had to do.
• justsayinghi 3y ago
  I actually used a sequence diagram today. I put it together for a meeting, to provide some visual guidance while descussing the architecture of a component, and the expected inputs and outputs of it. Helpful for aligning expectations and to spark more dialog. I also use hierarchy diagrams, but a lot less often. Those are used for documenting the architecure of classes that can be annoying to navigate their code through.
• consultSKI 3y ago
  Wrong. Never used them, probably never will. >> The programming use case died because, according to Hillell Wayne, “even most proponents of UML considered it a terrible idea.” When Ivar Jacobson's Use Cases were added to UML it was a day to celebrate for me and many others. I still create them 30 years later with other methodologies, even ones with no direct tie to software development like Dr. Eli Goldratt's TOC (Theory of Constraints).
• pyb 3y ago
  Am I the only one who finds sequence diagrams hard to read?
• lbriner 3y ago
  A strange conclusion for something that has been around for so long. It's a bit like saying the horse-drawn carriages are no good because cars. When UML was released, waterfall was pretty much the only model for Development and was understandably slow, expensive and risky. UML with processes like UP were used to bring in some order and standardisation to the picture. I used to use it a lot and it was really annoying because I just wanted to code but even in the early 2000s, release cycles were long (2-4 weeks) and mistakes would take a long time to spot and rework. Like all tools, we didn't always use it and we didn't always add 100% detail but we did use it. I don't use it as much any more because code is quick to produce, quick to review, to merge, to fail and to rework. That doesn't mean we shouldn't design up-front but there are many more use-cases where the time and effort of design is just not worth it. I still use class diagrams sometimes, although they are not really something specific to UML but I have also used state diagrams, again for specific scenarios, but let's just understand tools and decide when and where they are useful.
• billfruit 3y ago
  I personally think Statecharts are a more useful construct than sequence diagrams. It encodes complex behaviour that a developer can use as a guide to develop. More importantly it gives a good inkling of what behaviour is allowed and what is not allowed. For example a statechart can encode that a traffic light can only turn green from amber and not from red. It also has "H" history state which remembers which substate it was last in, when the system entered this composite state, the previous time. This allows to model behaviour that relies upon "memory" or past behaviour which is very common in real systems.
• magwa101 3y ago
  [dead]
• henry871 3y ago
  [flagged]
• henry871 3y ago
  [flagged]
• micy87 3y ago
  [flagged]
• micy87 3y ago
  [flagged]
• anna022 3y ago
  [flagged]
• anna022 3y ago
  [flagged]
• stive923 3y ago
  [flagged]
• stive923 3y ago
  [flagged]
• mark09237 3y ago
  [flagged]
• mark09237 3y ago
  [flagged]
• Alexa871 3y ago
  [flagged]
• Alexa871 3y ago
  [flagged]
• crazy8923 3y ago
  [flagged]
• crazy8923 3y ago
  [flagged]
• bad89 3y ago
  [flagged]
• bad89 3y ago
  [flagged]
• boy8768 3y ago
  [flagged]
• boy8768 3y ago
  [flagged]
• helloguy77 3y ago
  [dead]
• helloguy77 3y ago
  [dead]
• friends34 3y ago
  [flagged]
• friends34 3y ago
  [flagged]
• crush0923 3y ago
  [flagged]
• crush0923 3y ago
  [flagged]
• world9871 3y ago
  [flagged]
• world9871 3y ago
  [flagged]
• earth9802 3y ago
  [flagged]
• earth9802 3y ago
  [flagged]
• earth9802 3y ago
  [flagged]
• earth9802 3y ago
  [flagged]
• clark9082 3y ago
  [flagged]
• clark9082 3y ago
  [flagged]
• bereb092 3y ago
  [flagged]
• bereb092 3y ago
  [flagged]
• kerim023 3y ago
  [flagged]
• kerim023 3y ago
  [flagged]
• maltem02 3y ago
  [flagged]
• maltem02 3y ago
  [flagged]
• annael32 3y ago
  [flagged]
• annael32 3y ago
  [flagged]
• data871 3y ago
  [flagged]
• data871 3y ago
  [flagged]
• computerboy891 3y ago
  [flagged]
• computerboy891 3y ago
  [flagged]
• appleboy9081 3y ago
  [dead]
• appleboy9081 3y ago
  [dead]
• mango912 3y ago
  [flagged]
• mango912 3y ago
  [flagged]
• tiger923 3y ago
  [dead]
• tiger923 3y ago
  [dead]
• cat81 3y ago
  [flagged]
• cat81 3y ago
  [flagged]
• doggy89021 3y ago
  [flagged]
• doggy89021 3y ago
  [flagged]
• chemist823 3y ago
  [flagged]
• chemist823 3y ago
  [flagged]