pushgift.blogg.se - Lucidchart vs omnigraffle

#LUCIDCHART VS OMNIGRAFFLE HOW TO#
#LUCIDCHART VS OMNIGRAFFLE SOFTWARE#

Unless you're using a really old version of Visio that uses a proprietary binary file format, modern diagramming tools tend to save diagrams as text, which is much easier to version control.

These tools don't really understand that two boxes on two diagrams represent the same thing from a conceptual point of view. Again, we're limited by the domain specific language of diagramming tools being "boxes and lines". You can't easily share items between diagrams. This happens because there's no concept of a "model" in general purpose diagramming tools. Once you have the same item on multiple diagrams, you need to manually make sure that you keep all copies in sync when you change the content or presentation of that item. You violate the DRY principle every time that you copy-paste an element or relationship to use on another diagram.

#LUCIDCHART VS OMNIGRAFFLE SOFTWARE#

Modelling software architecture with PlantUML covers this problem. The only way to do this with a general purpose diagramming tool is to copy-paste the original diagram multiple times, and make edits to those copies.

A version with larger fonts and less text, for presentations.

A version without technical information, for non-technical people.

A version with technical detail, for developers and architects.

For example, perhaps you'd like three versions of a System Context diagram: This lack of separation makes it very hard to create multiple versions of the same content for different purposes. Again, open up a diagram file in a text editor, and you'll see this for yourself. Remember the early days of the web, where we'd craft huge HTML files containing all of the information about content and presentation? The same is true of general purpose diagramming tools. This makes it very easy to mix multiple levels of detail in the same diagram, leading to something that often makes little sense. But a general purpose diagramming tool can't enforce this, because it doesn't know what a "container" or "component" is. For example, the C4 model says, "don't put components on a container diagram". UML, ArchiMate, and the C4 model all have rules about what you can and can't do. Now what? The tool can't guide you towards creating a good software architecture diagram, because it doesn't know that's what you're trying to do.

Some people really like the freedom that general purpose diagramming tools give you, but this freedom is exactly what gets most people into trouble.

Because these tools don't know that you're trying to create a software architecture diagram, they can't really help you do that.

Open up a diagram file in a text editor, and you'll see what I mean. The domain specific language of general purpose diagramming tools is basically "boxes and lines". For software architecture diagrams though, my recommendation is no, for a few reasons. It's "diagrams as text".īut you might be wondering, what about general purpose diagramming tools such as Visio, draw.io/, LucidChart, Gliffy, OmniGraffle, etc? Should they be used for creating software architecture diagrams? For the record, I want to say that these are all great tools and, like many other people, I do use them myself.

#LUCIDCHART VS OMNIGRAFFLE HOW TO#

Software architecture diagrams - which tool should we use? looks at how to generate software architecture diagrams with PlantUML, Mermaid, WebSequenceDiagrams, and Structurizr, all via the tooling agnostic, and open source, Structurizr DSL. "Which diagramming tool should we use?" is a question I'm asked frequently.