Прежде всего, вы вообще не обязаны документировать все в UML-диаграммах.Потому что рабочее программное обеспечение важнее, чем полная документация.Однако UML может быть чрезвычайно полезен для выделения некоторых менее тривиальных аспектов вашего программного обеспечения, которые трудно найти в коде.И я бы посоветовал сосредоточиться на этих аспектах.
Теперь все, что вы должны делать в UML, зависит от того, что вы собираетесь представлять в своей модели, и от того, как вы используете js.
UML различает структурные диаграммы , чтобы показать статическое представление вашего программного обеспечения, и поведенческие диаграммы , чтобы показать его динамику.
Структурные диаграммы
Это может быть менее привлекательным для вас, поскольку JS основан на прототипе и предлагает большую гибкость в отношении логики ввода, в отличие от довольно статического классана основе представления UML.
Тем не менее, вы все равно могли бы извлечь выгоду из концепции классов и использовать диаграммы классов , чтобы показать либо ваше намерение проекта (то есть ваше мысленное представление о категоризации объектов), либо прототип, используемый длясоздавать экземпляры объектов (особенно если вы проектируете некоторые объекты, действуя по существу как прототип, делая их де-факто представителями классов).Конечно, если ваш JS-дизайн совсем не объектно-ориентирован, нет смысла отображать вашу программу на концепции ОО (см. здесь ).
Обратите внимание, что унаследованная объектная диаграмма может иметь больше смысла для вас, поскольку она позволяет объяснить отношения между объектами, а не классами (см. Также здесь )
В обоих случаях вас может особенно заинтересовать зависимость использования , которая помогает связать статические элементы (то есть объекты или классы) с поведенческими намерениями.
Наконец, диаграммы пакетов могут быть использованы, например, чтобы показать общую картину ваших .js файлов и их зависимостей.Это не в смысле традиционных пакетов Java, но также может быть полезным.
Диаграммы поведения
Здесь я бы сделал вид, что все эти диаграммы могут иметь смысл для вас.
Самое первое, что приходит мне в голову, это диаграмма последовательности .Потому что это помогает визуализировать ожидаемые взаимодействия между несколькими объектами , и их трудно обнаружить, просто просматривая код.
В некоторых случаях также может помочь диаграмма состояния машины .Это имеет особый смысл, если поведение зависит от некоторой переменной состояния или если вы хотите показать полный жизненный цикл объекта.
Наконец, вы можете рассмотреть диаграмму активности .Это особенно полезно, если вы хотите показать поток управления или объектов в вашей системе.Если вы с ними не знакомы и, если хотите, упростите до крайности, это своего рода супер-блок-схема, но там, где стрелки не обозначают jus, представляют собой «следующую операцию», но могут также представлять объекты, которые передаются между операциями.