I'm a software engineer with experience across the software development lifecycle. My primary interest is software development methodologies and software process improvement.
Having a common modeling language is a good thing. I don't want to have to explain my particular modeling notation to every developer reading what I produce. Having well-defined languages is a good thing. Of course, UML isn't a silver bullet. We have many, many programming languages. There's no reason why we can't have many modeling languages as well. But having well-defined languages instead of everyone using arbitrary symbols is a good thing. UML, as a language, is pretty comprehensive. I'd recommend learning it and using it where appropriate to talk about systems.
Martin Fowler wrote about four of them - sketch, notes, blueprint, and programming language. UML is a rich language, but that doesn't mean that you need to use every single feature it provides. Pick and choose appropriately and make your models at the appropriate level for the target audience. But stick to the rules that the language provides so that people can easily understand the notation used. Personally, I don't believe in UML as a Blueprint as I believe that code is the representation of the design of a software system. I haven't seen or read about any huge successes with UML as a Programming Language, either. However, UML as sketches or notes make perfect sense to me.
Understanding architectural viewpoints and perspectives is a good thing. To this end, you should learn other modeling languages. I haven't used it in actual work yet, but I'm interested in Simon Brown's work on C4 Modeling for Software Architecture - this was mentioned elsewhere in the comments. For database-intensive systems, Crow's foot or Chen's notation for ER diagrams is useful. I've used the IDEF modeling notations, too, with decent luck. SysML is a good compliment to UML for systems engineering. There are special symbol sets for Cisco or AWS networks. Depending on your audience, some or all of these can be used for different models of your system. I also believe that most modeling languages can have the modes that Martin Fowler described.
I think this may have been a little scattered, but it's my general take on the usefulness of UML.
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
I agree with you that UML isn't a silver bullet. I thinkt that creating class diagrams consumes a lot of time and gives us just a litte benefit and force us to update those diagrams after single change in code which could be frustrating :( On the other hand I love sequence diagrams espesially when we are going outside current domain. To sum up my plan is to get to know all UML diagrams and possibilities and apply those which will be most beneficial for my in my daily work.
I plan dive deeper into Simon Brown'sC4 model. On first glance it looks nice and promising but I need more time to investigate it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Having a common modeling language is a good thing. I don't want to have to explain my particular modeling notation to every developer reading what I produce. Having well-defined languages is a good thing. Of course, UML isn't a silver bullet. We have many, many programming languages. There's no reason why we can't have many modeling languages as well. But having well-defined languages instead of everyone using arbitrary symbols is a good thing. UML, as a language, is pretty comprehensive. I'd recommend learning it and using it where appropriate to talk about systems.
Martin Fowler wrote about four of them - sketch, notes, blueprint, and programming language. UML is a rich language, but that doesn't mean that you need to use every single feature it provides. Pick and choose appropriately and make your models at the appropriate level for the target audience. But stick to the rules that the language provides so that people can easily understand the notation used. Personally, I don't believe in UML as a Blueprint as I believe that code is the representation of the design of a software system. I haven't seen or read about any huge successes with UML as a Programming Language, either. However, UML as sketches or notes make perfect sense to me.
Understanding architectural viewpoints and perspectives is a good thing. To this end, you should learn other modeling languages. I haven't used it in actual work yet, but I'm interested in Simon Brown's work on C4 Modeling for Software Architecture - this was mentioned elsewhere in the comments. For database-intensive systems, Crow's foot or Chen's notation for ER diagrams is useful. I've used the IDEF modeling notations, too, with decent luck. SysML is a good compliment to UML for systems engineering. There are special symbol sets for Cisco or AWS networks. Depending on your audience, some or all of these can be used for different models of your system. I also believe that most modeling languages can have the modes that Martin Fowler described.
I think this may have been a little scattered, but it's my general take on the usefulness of UML.
Thanks for your opinion.
I agree with you that UML isn't a silver bullet. I thinkt that creating class diagrams consumes a lot of time and gives us just a litte benefit and force us to update those diagrams after single change in code which could be frustrating :( On the other hand I love sequence diagrams espesially when we are going outside current domain. To sum up my plan is to get to know all UML diagrams and possibilities and apply those which will be most beneficial for my in my daily work.
I plan dive deeper into Simon Brown's C4 model. On first glance it looks nice and promising but I need more time to investigate it.