Do software developers actually use UML diagrams, and more specifically object models, domain models, system sequence diagrams and operation contracts? I am taking a computer science degrees, and we're spending a lot of time (significantly more than programming) learning about UML and different types of diagrams. But currently, I have a feeling it is just academic bureaucracy. Are these models actually relevant or can you be a good developer without them? Right now, I feel like only Design Class Diagrams are useful.
-
2It depends on a number of factors, including the size and complexity of the software project. Every software project has some of these diagrams, some have all of them. Small to medium sized software projects can be successfully executed without any diagrams at all, but in my experience, there is always at least an informal diagram of the project, even if it doesn't strictly conform to UML specifications.– Robert HarveyMar 13 at 19:08
-
I've heard developers say that formal use of UML on big projects doesn't work, because the diagrams need extensive edits and some times uneffective or wrong. Would you say these diagrams mostly have a place in the initial stages of a project?– TimMar 13 at 19:22
-
1Sometimes the goal of an exercise is not developing the immediate activity you are doing (drawing) it could be reinforcing other things like abstract or side thinking. I was 14y when I learned software programming. I spent the first year drawing pseudo-code, drawing charts and solving bool algebra on a whiteboard before coding my first line of code. Coding is anecdotal, reasoning, abstraction, side thinking are way more important.– LaivMar 14 at 7:14
-
2These diagrams can be a valuable tool for communication, for explaining and discussing the design. Not just during the initial stages when you originally create it, but also later on as it involves, and especially when new people join. But that also means they have to be kept in synch with the code, and despite promises from tool makers, that never really works automatically. So you have to do it manually, and that in turn basically never works unless you confine the diagrams to a small set of high-level abstract views of the system, and maybe some details of important special cases.– Michael BorgwardtMar 14 at 12:40
Add a comment
|
5 Answers
Do people use them?
Yes. And no. Mostly no.
An UML diagram won't execute. You can't write unit tests against it.
There are tools that will take production code / tables, even development stubs, and turn them into UML / ERD that you can paste into a PPT deck. Doing the {edit, run} cycle in that direction can be a whole lot more productive than attempting to iterate on diagrams from which you then try to produce working code. The stick figures don't diff, they don't show up in PRs.
There is always a discovery process, where stake holders and engineers figure out what details are easy or hard to obtain, and what brings the greatest business value so we should do that first. And then iterate. An evolving diagram can help with that process, inexpensively. Dealing with drift between diagram and evolving implementation tends to get uglier as the months go by. If you find diagrams help communication, then use them.
I have seen UML diagrams used to good effect when scoping off-shore contract projects. We iterate a few times, and then the artifact is frozen in a contract. It's not Agile, but it can accomplish well-understood business objectives.
-
"An UML diagram won't execute." - a bunch of people in the 2000s wanted very much to change that. I had a CS PhD tell me in 2008 that actually writing code was totally going to be obsolete because MDD was the future. Mar 14 at 12:34
-
2"If you find diagrams help communication, then use them." -- I have found this to be the critical justification for spending the time to create diagrams. For example, a less experienced team might benefit from the visual depiction of application structure that a class diagram shows. It can also help a group of experienced developers agree on the names of things and code organization during the initial design phase of a feature. These diagrams are useful similar to blueprints for a building. Good before and during construction, but less and less useful the longer you go after construction. Mar 14 at 14:19
-
2(continued...) When you work with a team that is already accustomed to naming conventions, how your project organizes code, and business rules, these kinds of documents become less beneficial. I've experienced it both ways: an inexperienced team that needed the visuals, which then transitioned to an experienced team that no longer needed them. UML diagrams should be an artifact of the software design process, not the desired output. The desired output of the software design process is working software in the shortest amount of time. UML diagrams should be created to facilitate this end result. Mar 14 at 14:24
But currently, I have a feeling it is just academic bureaucracy.
I very much sympathize with that sentiment.
However, it is not just academic bureaucracy. There is value to it in certain scenarios, but you don't concretely use these tools in a lot of simpler scenarios. As a junior, you will not be working in the kinds of complex scenarios that require these diagrammatic solutions.
Once you're a senior or an architect, or (worst case) if you're working in a hellishly complex development landscape; these tools will help you wrangle the jungle of code into some sort of order. Without those tools, you will be hopelessly lost and it will be a very unhappy situation to be in.
Are these models actually relevant or can you be a good developer without them?
There are different things that can make a developer a good developer.
Take the example of a battlefield medic versus a hospital surgeon. These two doctors have very different metrics as to what makes them a good doctor. Putting superglue on a wound is acceptable for the battlefield medic, but it is virtually inexcusable in a hospital setting. Expecting a sterile room is sensible for a hospital surgeon but would be inexcusable if a battlefield medic would demand it before they treated anyone.
Developers who wield UML diagrams are able to design and architect large scale solutions while breaking it down into simple, digestible subcomponents. That is definitely a valuable contribution.
However, if something breaks in production code, the developer who doesn't know how to debug/fix it until he consults the diagrams is going to be an obstacle.
At the same time, a hands-on developer will be great at debugging and quick thinking, but they might not be great at managing a large scale enterprise project.
So which developer is the better developer? The answer is that there is no direct comparison, they both have their strengths.
Personally, I never bothered with UML diagrams when I was in school. However, when I started working and started to progress beyond the junior developer role, it started to make sense to use diagrams to make sense of parts of our work, at which point I started to incorporate them into my process.
Do I use them everywhere, or every time? Definitely not. But if I need to communicate or track something complex, I do whip out a diagram to help explain the complexities.
If your teacher is claiming that development must originate from a diagrammatic approach, they are patently incorrect in terms of how the sector works in reality. But that's not the same as saying that it doesn't add value.
-
I have been superglued back together in a hospital. It was a very minor injury, and superglue is easier than stitching.– Simon BMar 15 at 12:42
-
@SimonB: I doubt you mean the superglue that you get from a stationery shop, which is what I was referring to. It is true that in recent years they've created medical grade glues as an alternative to stitching, but it's not formally called superglue (which I suspect is even a brand name)– FlaterMar 15 at 22:39
-
You probably won't use diagrams much and if you do, give me a shout, I want to see that company.
I'm a Java Developer with 12 years of experience, I've been working for corporations, startup, as a freelancer and employee. I have seen a software documentation worth mentioning once and it was an amateur set of text based Confluence pages. The ER diagrams are the only exception, but are a rare species as well. But I still think it's worth doing at school, it gives you some mental model in your head and it will help you thinking.
I haven't seen anyone ever really designing software, I haven't seen anyone analyzing software, requirements engineering is Utopia. You don't need anything like that on a simple project and when the project gets complicated, then it too late to fix it by documentation and nobody really knows, how to do it and where is any added value worth its cost. Your teacher is disconnected from the reality.
-
1This is anecdotal, but also happens to be my experience of about 15 years of software development as well, for what its worth. I also don't recall any other dev every trying to sell me on using things like UML because they had a good project experience using it. We've used Visio to chart a few pathways once or twice but that's about it.– GHPMar 14 at 13:49
Some UML diagrams are more useful than others.
Sequence Diagrams
There have been a couple of cases where I found it helpful to be able to refer to a Sequence diagram to understand a complex protocol (where there were 3 or 4 systems interacting - IMO in a non obvious way).
Class diagrams
I have found that creating a class diagram of a few key classes in a code base can be helpful for "onboarding" type documentation, so that a new developer can more quickly understand the key concepts / what to look at without having to feret around in the code base.
Secondly
IF YOU ARE USING A UML TOOL THAT CAN DO CODE GENERATION...
If can be helpful for "green field" type projects such as:
- Adding a new Public API.
- A large new module.
- A dramatic refactor (think largely throwing away the old code).
In such a case you can design the key classes, throw in the properties and core methods - it is easy to see/add an extra class etc. Then when you are happy with the basic design you can code generate all the class stubs.
You can then write all your tests, as you have concrete signatures to test.
This use case probably doesn't fit the "methodology" of UML since you are only really using the tool for your own benefit (rather than to convey meaning to others), but I have found it helpful.
ERD Diagrams
I think most people would consider Entity Relationship Diagrams (typically used to visualize databases) as being distinct/seperate thing from UML, but they basically provide the same function as class diagrams (albeit specialized for the data model) - to make it easier to understand the structure.
I haven't designed a database using an ERD tool - but when I join a project, that has a sizable relational database, one of the first things I do is generate an ERD so I can try to make sense of it.
Other Diagrams
I occasionally see some of the other UML diagrams in documentation. But I don't recall ever having an "ah hah" moment - saying something like that diagram really helped clarify a critical detail.
Where the rubber hits the road is this:
- Good ERD tooling is something that I would consider paying money for.
- I will use UML functions in tooling I already have, but UML functionality is not something that would affect my purchase decision.
I have worked for 9 years as a C++ developer in the Automotive industry. Since we work on safety-critical software, we always end up working on showcasing our architecture for review. This is possible in a simple way with UML diagrams. Once we have at least partial approval, we will then go ahead with the implementation.
I felt it helped develop structured and maintainable software since we need to support any software for 10-15 years. The number of people working on the software is huge, considering the lifespan of the software. So, having UML capture our architectural decisions helps the next generation of developers understand the use cases and any particular issues we face with our customers.
Based on the other answers, I feel that UMLs usage may be strictly followed in safety-critical applications and not so much in consumer applications.
