Author "Software Architecture for Developers" | Creator of the "C4 model for visualising software architecture" | Founder at Structurizr | Software architecture training at architectis.je
UML is definitely worth learning, and there's a lot of good stuff in there when used sparingly. As others have said already, you need to watch that the diagrams don't become out of date when compared to the source code. Also, and I have no empirical evidence to back this up(*), very few people seem to use UML nowadays, so you have to take into account the potential learning curve of your team members. A couple of recommendations ... (1) ensure that everybody on your team understands the abstractions you are using on your diagrams (be careful with terms like "component", "module", "service", "subsystem", etc) and (2) ensure that every UML diagram has a key/legend to make the notation you are using explicit.
This is a pretty large topic, so a couple of starting points you might want to take a look at are my C4 model (this is an abstraction-first approach to diagramming; compatible with UML) and my Visualise, Document and Explore Your Software Architecture talk that looks at diagramming from a number of different perspectives.
(*) I've run diagramming workshops for over 10K people around the world, and most of what I see is "boxes and lines" rather than UML
Section 3.3.3 of my paper on "Sketches and Diagrams in Practice" describes that most sketches and diagrams in our study were rather informal and only 9% of them were classified as "pure" UML diagrams.
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've look on your research. I like your poster: Sketches and Diagrams in Practice very much. It would be great if you could attach it in this discussion. I think it mainly agrees with this discussion participants opinions :)
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'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've just seen your presentation on OpenSlava 2017. It was really nice and descriptive. I like the approach to treat diagrams as a map with a different level of details on it.
Things which I'll keep in my mind:
always add a legend to a diagram
I hate when people are using acronyms, symbols etc. which can be confusing and/or be interpreted in many of ways
create documentation which could be read in 1-2 hours to get an introduction into project
I agree that 1-2 hours should be enough to catch big picture, and should be enough for reader to know where to look in code for more details.
An extra thought. You said that 1 on 10 people knows UML. I'm just wondering how would a group consisting of 10 people who know UML handle with your exercise with diagram creation and interpretation. Would they be confused or would they read it slightly? It could be very interesting and funny experiment.
Once again thanks for your opinion in this discussion.
Author "Software Architecture for Developers" | Creator of the "C4 model for visualising software architecture" | Founder at Structurizr | Software architecture training at architectis.je
Thanks again, I'm glad you found the talk useful. :-)
Yes, I've run my diagramming workshop for teams that have told me they "use UML for everything", and surprisingly the diagrams they produced were the same confused collections of boxes and lines. These diagrams were not particularly UML either, although a few UML notational elements (e.g. interface "lollipops", or the "cup and ball", etc) are often thrown in for good measure. Although I ask groups to use pen and paper, some insist on using electronic tools because they "want to get the UML notation correct". This generally doesn't help either, because you get diagrams like this, which are just meaningless.
In summary, even when I work with teams that "use UML", after some discussion, it turns out that most of them only use class and sequence diagrams, which isn't sufficient for describing software architecture (IMHO, of course). I've seem a very small number of people take a "pure UML" approach to my diagramming workshop, but that tends to make matters worse because nobody else understands the notation being used.
A big problem here is that it's really hard to find a good set of example UML diagrams based upon a real case-study, so everybody's view of UML is wildly different. This again comes back to abstractions. If you can figure out what abstractions (and, therefore, levels of detail) you want to show, the rest falls into place easily. This is why the C4 model exists, and why it's an abstraction-first approach.
I am dearly interested what you think about the AUTOSAR specifications if you mind to take a quick look at them. I'll hold back my opinion on this until I've heard at least one educated judgement from someone else.
Author "Software Architecture for Developers" | Creator of the "C4 model for visualising software architecture" | Founder at Structurizr | Software architecture training at architectis.je
I've been pointed to AUTOSAR before, but I don't generally work in the automotive industry, so I'm not sure I can offer much in the way of an opinion about it. I hope there is a good amount of benefit given the specification is 270 pages though. :-)
Some other verticals have their own domain-specific modelling languages too; embedded software immediately springs to mind, where I've seen domain-specific "architecture description languages" used. In my experience, even these teams (and those creating comprehensive documentation for regulatory purposes) are seeking ways to improve their communication. For some, UML is a good fit. For others, not so much.
Sequence diagrams for interaction and activity flow diagrams for logic. The rest, not so much. Aside from that I also find use in ER and DFDs. One of the greatest uses is when I want to clarify things for myself.
I hear this same response from a lot of people. I think UML is a great attempt and standardizing modeling and diagrams. Its not perfect, and its huge, but I think worth learning especially in big complex software systems. If you give 10 developers a task to diagram something, and all 10 will have something different, some may be better than others. And you would have to learn what each of the 10's modeling shapes/components meant to that author, every time, instead of already knowing by learning and using UML once.
In big software systems in the enterprise. it makes a lot of sense to make a document/model/diagram that can be read by everyone, and is a proven way that works by software experts to describe or model something in that system using visual shapes/aid. And UML can be extended, its not perfect and doesn't always fit. But I definitely think its worth the time to learn and use, so everyone can be speaking the same language when it comes to modeling.
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.
Hi and thank you for your replay. I aware that other developers which I'm working with should understand me and my language which is in that case UML. In my opinion the biggest advantage of UML is that it is understand by developers accross companies and technologies. I can send a diagram written in UML to 3rd parties and I will be understand (or I hope I'll be :)).
Author "Software Architecture for Developers" | Creator of the "C4 model for visualising software architecture" | Founder at Structurizr | Software architecture training at architectis.je
Thanks, you're welcome! Yes, the biggest advantage of UML is that it should be understood by people in different teams and organisations, but that hasn't turned out to be the case unfortunately. As with any notation, it's easy to create diagrams that are meaningless. I always point to these examples ... I'm sure they are "correct" UML, but I don't really understand what that diagram is saying, what the responsibilities of the "components" are, etc.
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.
That's true that with UML we can easily create meaningless diagrams or diagrams which are only understandable for UML experts rather than regular developers. In general we should avoid that. I've been working with one architect which has created such a diagrams. They were hard to understand but I can in easy way generate C# classes based on those diagrams. That was quite comfortable :)
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.
UML is definitely worth learning, and there's a lot of good stuff in there when used sparingly. As others have said already, you need to watch that the diagrams don't become out of date when compared to the source code. Also, and I have no empirical evidence to back this up(*), very few people seem to use UML nowadays, so you have to take into account the potential learning curve of your team members. A couple of recommendations ... (1) ensure that everybody on your team understands the abstractions you are using on your diagrams (be careful with terms like "component", "module", "service", "subsystem", etc) and (2) ensure that every UML diagram has a key/legend to make the notation you are using explicit.
This is a pretty large topic, so a couple of starting points you might want to take a look at are my C4 model (this is an abstraction-first approach to diagramming; compatible with UML) and my Visualise, Document and Explore Your Software Architecture talk that looks at diagramming from a number of different perspectives.
(*) I've run diagramming workshops for over 10K people around the world, and most of what I see is "boxes and lines" rather than UML
Regarding empirical evidence, you may also have a look at my research :-)
sbaltes.github.io/projects/sketches/
Section 3.3.3 of my paper on "Sketches and Diagrams in Practice" describes that most sketches and diagrams in our study were rather informal and only 9% of them were classified as "pure" UML diagrams.
I've look on your research. I like your poster: Sketches and Diagrams in Practice very much. It would be great if you could attach it in this discussion. I think it mainly agrees with this discussion participants opinions :)
Thanks :-) I hope this works:
Thanks a lot I'll look at your research.
I've just seen your presentation on OpenSlava 2017. It was really nice and descriptive. I like the approach to treat diagrams as a map with a different level of details on it.
Things which I'll keep in my mind:
always add a legend to a diagram
I hate when people are using acronyms, symbols etc. which can be confusing and/or be interpreted in many of ways
create documentation which could be read in 1-2 hours to get an introduction into project
I agree that 1-2 hours should be enough to catch big picture, and should be enough for reader to know where to look in code for more details.
An extra thought. You said that 1 on 10 people knows UML. I'm just wondering how would a group consisting of 10 people who know UML handle with your exercise with diagram creation and interpretation. Would they be confused or would they read it slightly? It could be very interesting and funny experiment.
Once again thanks for your opinion in this discussion.
Thanks again, I'm glad you found the talk useful. :-)
Yes, I've run my diagramming workshop for teams that have told me they "use UML for everything", and surprisingly the diagrams they produced were the same confused collections of boxes and lines. These diagrams were not particularly UML either, although a few UML notational elements (e.g. interface "lollipops", or the "cup and ball", etc) are often thrown in for good measure. Although I ask groups to use pen and paper, some insist on using electronic tools because they "want to get the UML notation correct". This generally doesn't help either, because you get diagrams like this, which are just meaningless.
In summary, even when I work with teams that "use UML", after some discussion, it turns out that most of them only use class and sequence diagrams, which isn't sufficient for describing software architecture (IMHO, of course). I've seem a very small number of people take a "pure UML" approach to my diagramming workshop, but that tends to make matters worse because nobody else understands the notation being used.
A big problem here is that it's really hard to find a good set of example UML diagrams based upon a real case-study, so everybody's view of UML is wildly different. This again comes back to abstractions. If you can figure out what abstractions (and, therefore, levels of detail) you want to show, the rest falls into place easily. This is why the C4 model exists, and why it's an abstraction-first approach.
I am dearly interested what you think about the AUTOSAR specifications if you mind to take a quick look at them. I'll hold back my opinion on this until I've heard at least one educated judgement from someone else.
I've been pointed to AUTOSAR before, but I don't generally work in the automotive industry, so I'm not sure I can offer much in the way of an opinion about it. I hope there is a good amount of benefit given the specification is 270 pages though. :-)
Some other verticals have their own domain-specific modelling languages too; embedded software immediately springs to mind, where I've seen domain-specific "architecture description languages" used. In my experience, even these teams (and those creating comprehensive documentation for regulatory purposes) are seeking ways to improve their communication. For some, UML is a good fit. For others, not so much.
Sequence diagrams for interaction and activity flow diagrams for logic. The rest, not so much. Aside from that I also find use in ER and DFDs. One of the greatest uses is when I want to clarify things for myself.
I hear this same response from a lot of people. I think UML is a great attempt and standardizing modeling and diagrams. Its not perfect, and its huge, but I think worth learning especially in big complex software systems. If you give 10 developers a task to diagram something, and all 10 will have something different, some may be better than others. And you would have to learn what each of the 10's modeling shapes/components meant to that author, every time, instead of already knowing by learning and using UML once.
In big software systems in the enterprise. it makes a lot of sense to make a document/model/diagram that can be read by everyone, and is a proven way that works by software experts to describe or model something in that system using visual shapes/aid. And UML can be extended, its not perfect and doesn't always fit. But I definitely think its worth the time to learn and use, so everyone can be speaking the same language when it comes to modeling.
Hi and thank you for your replay. I aware that other developers which I'm working with should understand me and my language which is in that case UML. In my opinion the biggest advantage of UML is that it is understand by developers accross companies and technologies. I can send a diagram written in UML to 3rd parties and I will be understand (or I hope I'll be :)).
I'll look at C4 model and video from your presentation.
Thanks, you're welcome! Yes, the biggest advantage of UML is that it should be understood by people in different teams and organisations, but that hasn't turned out to be the case unfortunately. As with any notation, it's easy to create diagrams that are meaningless. I always point to these examples ... I'm sure they are "correct" UML, but I don't really understand what that diagram is saying, what the responsibilities of the "components" are, etc.
That's true that with UML we can easily create meaningless diagrams or diagrams which are only understandable for UML experts rather than regular developers. In general we should avoid that. I've been working with one architect which has created such a diagrams. They were hard to understand but I can in easy way generate C# classes based on those diagrams. That was quite comfortable :)