**Communication and simulation/code generation** Modeling really only serves two basic purposes: **communication** and **simulation**. Don’t confuse one for the other. Only those for simulation require stringent adherence to the rules of the language, and most are for communication. > [!tldr] TL;DR > Modeling for… > - simulation: adhere to the rules > - communication: keep it simple A big criticism of [[UML]] is that it’s overly-complicated. There are constructs for edge cases of edge cases, you can not glean the immediate message. The same has been, in my experience, true of most [[SysML]] models as well. If the purpose of the model is for **simulation** or for **generating code**, then completeness is necessary. If you're using UML for creating Java classes, then follow all conventions for [[Class Diagrams]]. If you're using SysML to check design parametrics against requirements & constraint blocks, then follow the necessary syntaxes. Otherwise don't. When it comes to _software development_, there are actual testing methods that can be (and should be) used. This means UML diagrams should probably be built for **communication**. This means jettisoning the details. Focus on what’s important from a [[Pareto Analysis]] perspective. > [!warning] > [[SysML]] and [[UML]] tools are built to support simulation & are probably overkill for communication. It seems to me that BPMN serves no purpose, aside from potentially being used as a visual configuration in a workflow management software. [[IDEF0]] is fantastic because it knows what it was for. When it comes to [[Enterprise Architecture]], modeling is _always_ for communication. This is why [[Archi]] doesn't have a million buttons and why [[Archimate]] is good. **** # More ## Source - self ## Related - [[UML]] - [[SysML]] - [[Systems Decomposition Rule of 7]] - [[Simplicity]] - [[Simple is Maintainable]]