Diagrams&#x2F;notation I&#x27;ve found useful:<p>++ <i>E-R (entity-relationship) diagrams</i>.  I find it easier to look at boxses for each table follow the lines signifying relationships to other boxes.  The &quot;crows feet&quot; can signify 1-to-many.  The diagram is easier than reading a sequential list of SQL CREATE TABLE statements and making a mental note of &quot;FOREIGN KEY&quot; strings and mentally backtracking to the parent table.<p>++ <i>swim lanes</i> to show how the &quot;state&quot; of a system is supposed to change with &quot;time&quot;.  This can succinctly show how data &quot;flows&quot; without having to actually run a program and watch variables in a debugger to manually recreate the &quot;swim lane&quot; in your head.<p>++ <i>truth tables</i> to summarize combinations of valid&#x2F;invalid business rules and associated side effects.  A grid is easier than parsing a long (and often nested) list of if&#x2F;then&#x2F;else&#x2F;switch statements.<p>As for UML, the notation never seems to be that succinct or helpful to me.  On the surface level, it seems that UML (for code) should have the same return-on-investment as E-R (for db tables) but it doesn&#x27;t in my experience.<p>I also wonder if there is a cultural component to UML usage.  It doesn&#x27;t seem like tech companies (such as Microsoft&#x2F;Google&#x2F;Amazon&#x2F;Ubisoft&#x2F;etc) internally use UML as a prerequisite step for building systems.  On the other hand, I could see more UML usage at non-tech companies (such as banks&#x2F;manufacturing&#x2F;government) building line-of-business CRUD apps.  Grady Booch (Booch &amp; UML notation) did consulting about software methodology at non-tech companies so that may have been a factor.