Love-Hate Relationship with UML Diagrams

[marcialwushu]

https://creately.com/blog/diagrams/advantages-and-disadvantages-of-uml/

[marcialwushu]

https://dev.to/rafalpienkowski/do-developers-still-need-uml-ajh

https://c4model.com/

https://www.youtube.com/watch?v=m76bR16EhrU

https://empirical-software.engineering/publications/#fse14-sketches

https://empirical-software.engineering/research/

[marcialwushu]

[marcialwushu]

http://agilemodeling.com/artifacts/componentDiagram.htm

[marcialwushu]

https://www.autosar.org/fileadmin/user_upload/standards/adaptive/17-03/AUTOSAR_TPS_ManifestSpecification.pdf

[marcialwushu]

https://www.sparxsystems.com.au/products/ea/

No meu trabalho anterior, eu estava usando o Enterprise Architect (EA) . Essa ferramenta possui a capacidade de gerar código com base no diagrama de classes UML e de gerar diagrama de classes com base no código escrito. Minha equipe foi ainda mais longe e um de nós escreveu um plug-in personalizado para a EA, que produz documentação com base no modelo definido. Os documentos gerados dessa maneira eram enviados aos nossos clientes e subcontratados.

[marcialwushu]

https://www.sourcetrail.com/

[marcialwushu]

https://twitter.com/ThePracticalDev/status/932330636291043330

Você também pode ver os comentários ao Tweed neste post: twitter.com/ThePracticalDev/status ... por exemplo, a resposta de Simon Brown, que mantém uma ferramenta para fazer diagramas para arquitetos.

[marcialwushu]

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.

[marcialwushu]

Você não leu os "Design Patterns", do GoF? Está cheio de diagramas UML.

Você não gerou uma documentação a partir do código, usando Doxigen ou similar? Ele gera os relacionamentos de classe UML.

Você não usou o MySQL Workbench ou software similar? Ele mostra o relacionamento entre tabelas como Classes UML.

Você não explicou algo com um fluxograma? Claro que é muito parecido com os diagramas UML.

Realmente, a UML é apenas para padronizar algum tipo de gráfico usual para fornecer uma linguagem comum para todos. Talvez você não consiga criar um sem nenhum erro, mas certamente pode ler um diagrama UML.

Por exemplo, pode ser interessante descrever um padrão, como o Abstract Factory ( sourcemaking.com/design_patterns/a ... ), ou um fluxo de trabalho representado por um diagrama de atividades ou casos de uso para mostrar o comportamento desejado etc.

Sugiro que você tente plantuml ( plantuml.com ) para começar a explicar suas apresentações, e certamente aprenderá como usá-lo rapidamente.

[marcialwushu]

https://www.synopsys.com/blogs/software-security/cost-to-fix-bugs-during-each-sdlc-phase/

http://blog.celerity.com/the-true-cost-of-a-software-bug

https://crossbrowsertesting.com/blog/development/software-bug-cost/

[marcialwushu]

Não é necessário em 'design indiferente à arquitetura'

Um termo cunhado por George Fairbanks, 'design indiferente à arquitetura' é uma situação em que a UML é considerada desnecessária.

Na sua essência, um design indiferente à arquitetura refere-se a uma arquitetura de software simples e básica e não precisa de nenhum diagrama complexo para representar ou explicar o design. Se as empresas enfatizarem mais a codificação formal e houver uma cultura predominante de documentação mínima de design, a UML será considerada desnecessária.