It's a good subject to discuss. I've some opinions about it:
I think UML is a good way to understand complex domains and software architectures. It provides a fast and top-down vision of the problem. However, I don't like it for documentations, class modeling or other complex and variable operations that needs to be maintained. Programmers don't like to maintain documentation, diagrams or any other artifact that isn't the code base.
I like to use UML for fast operations, for example, when i'm working on a complex task and I need to understand an implemantion that needs to be refactored.
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.
First thank you that you as an author of first comment :) and yes your comment is very helpful.
I'm the same opinion as you that UML can help with splitting complex task into smaller. In my opinion it's easier and faster to detect come issues with UML. It'll save developer's time in the future.
I agree that creating and updating documentation in UML is painful. I think that depending on details level we should use UML or unit tests and comments in code as documentation. (By the way I'm a big fan of unit tests). As an example, interactions between two system or system components, architecture of used in system components should be done in UML but implementation details should be documented via a unit tests and comments in code.
I think that depending on details level we should use UML or unit tests and comments in code as documentation.
Agreed.
I use UML diagrams for top-level documentation, like to show how systems are related to each other. And I find it much more practical to document low-level stuff with the code side by side, in the form of unit tests and code comments, because this way its easier to find the documentation when you need it most and more convenient to update. I do use UML diagrams for low-level stuff on the occasions I need to discuss really complex logic with my colleagues before coding starts.
And for databases, I always design the database on ER diagrams before writing the necessary migration queries, because it is easier to visualise how different DB designs might affect read/write efficiencies.
I think all software professionals should learn to read and write UML diagrams. But when and where they will find it appropriate to use is subjective to the nature of the project (outsourced vs. in-house, waterfall vs. agile, cost of installation / updates) and their team culture. Traditional software delivery business models would favour the use UML diagram more.
Regarding the point of maintaining both the documentation and the UML diagrams, aren't there program which will autogenerate/update the UML based on code changes? As well as generate the entire "scaffolding" of classes and functions specified by the UML (can't remember that right word… boilerplate code?)?
If yes, do they work in practice, or are they more trouble than the benefit they provide?
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.
In my previous work I was using Enterprise Architect (EA). This tool has ability both to generate code based on UML class diagram and to generate class diagram based on written code. My team went even further and one of us has written a custom plugin to EA which produce documentation based on defined template. Generated in such a way documents were sending to our customers and subcontractors.
Documentation was generated fully automatically. It looked nice and its update was super easy. I only needed to update documentation in code. Unfortunately this plugin didn't apply to behavior diagrams. Of course developer needed remember to update documentation in code and generate the documentation.
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.
Hi, Rafal.
It's a good subject to discuss. I've some opinions about it:
I think UML is a good way to understand complex domains and software architectures. It provides a fast and top-down vision of the problem. However, I don't like it for documentations, class modeling or other complex and variable operations that needs to be maintained. Programmers don't like to maintain documentation, diagrams or any other artifact that isn't the code base.
I like to use UML for fast operations, for example, when i'm working on a complex task and I need to understand an implemantion that needs to be refactored.
I hope this helps.
First thank you that you as an author of first comment :) and yes your comment is very helpful.
I'm the same opinion as you that UML can help with splitting complex task into smaller. In my opinion it's easier and faster to detect come issues with UML. It'll save developer's time in the future.
I agree that creating and updating documentation in UML is painful. I think that depending on details level we should use UML or unit tests and comments in code as documentation. (By the way I'm a big fan of unit tests). As an example, interactions between two system or system components, architecture of used in system components should be done in UML but implementation details should be documented via a unit tests and comments in code.
Agreed.
I use UML diagrams for top-level documentation, like to show how systems are related to each other. And I find it much more practical to document low-level stuff with the code side by side, in the form of unit tests and code comments, because this way its easier to find the documentation when you need it most and more convenient to update. I do use UML diagrams for low-level stuff on the occasions I need to discuss really complex logic with my colleagues before coding starts.
And for databases, I always design the database on ER diagrams before writing the necessary migration queries, because it is easier to visualise how different DB designs might affect read/write efficiencies.
I think all software professionals should learn to read and write UML diagrams. But when and where they will find it appropriate to use is subjective to the nature of the project (outsourced vs. in-house, waterfall vs. agile, cost of installation / updates) and their team culture. Traditional software delivery business models would favour the use UML diagram more.
Regarding the point of maintaining both the documentation and the UML diagrams, aren't there program which will autogenerate/update the UML based on code changes? As well as generate the entire "scaffolding" of classes and functions specified by the UML (can't remember that right word… boilerplate code?)?
If yes, do they work in practice, or are they more trouble than the benefit they provide?
In my previous work I was using Enterprise Architect (EA). This tool has ability both to generate code based on UML class diagram and to generate class diagram based on written code. My team went even further and one of us has written a custom plugin to EA which produce documentation based on defined template. Generated in such a way documents were sending to our customers and subcontractors.
Documentation was generated fully automatically. It looked nice and its update was super easy. I only needed to update documentation in code. Unfortunately this plugin didn't apply to behavior diagrams. Of course developer needed remember to update documentation in code and generate the documentation.