They all require some discipline, but if the team finds value in any of these things, they would make an effort to keep them synchronized with the code.īesides, I suggest not falling in the trap of having formal design documents early on in the project's lifetime. I've heard this argument many times, but how is it different from keeping documentation, comments, tests, or the issue tracker up to date? > Or you manually update UML in theory, but in practice just let it slide as the week after you know something else will change and you don't nees it today anyway. Or you manually update UML in theory, but in practice just let it slide as the week after you know something else will change and you don't nees it today anyway. Either you generate UML and have the above problems. Next week there is a minor requirement change (new features we always knew were coming and planned for even), and now the code changed. related to this when i'm interested in one error path how do you hide the others? I don't care about rare error cases most of the time, but automatic UML can't know what is the complexity needed for rare cases and what is complexity you need to show the junior on the first day. Sometime you have complexity in code that needs tobe hidden by default. You can't just randomly throw boxes and lines on the page, you need to arrange them so that boxes that we can tell what things are related by how close they are to each other. Where those boxes are in relation to each other matters. The problem isn't generating UML from code, the problem is generating useful UML from code. 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 :). They want the digestible high level vision of the important bits, or the bits that are relevant to the conversation taking place. 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. That said, I can make a PlantUML diagram much more correct than a whiteboard.Īll that said I too would love for more of that to be automated increasingly through AI. 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. I used to whiteboard for this, but that hasn't carried over well in the remote world. 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'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. In contrast to the other UML diagram types that have strange notations and the information is more densely packed. 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. 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. 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. 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 industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers. The only reason the other diagram types fell out of favor is because of the development methodology change starting in the early 2000s. Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. I also find sequence diagrams to be the most useful, but disagree that the rest of UML is useless.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |