Проектирование UML для приложений Meteor

Question

В настоящее время я борюсь за правильное проектирование приложения Meteor/NodeJS, так что кто-то еще может выбрать работу, где я ее оставил.

Приложение само по себе будет использоваться для сотрудничества между различными сторонами-учеными. Поскольку я выполняю этот проект как часть стажировки, я знаю, что я собираюсь оставить его в конце марта 16 года. Из-за этого крайне важно оставить его в состоянии, когда кто-то еще может легко отладить мелкие проблемы или добавить небольшие расширения.

Поскольку основная технология Meteor, мне сложно представить, как создать UML для приложения JavaScript. Я немного разбираюсь в разработке UML для C++ или Java. Концепция классов поддерживается в ES6, но использовать их, похоже, не очень метеорный подход. Прочитав о MVC и Meteor in the meteor cookbook, мне стало ясно, что .html-файлы представляют собой модель, файлы .js - это контроллер, а файлы .css - это представление ... по крайней мере, в клиентской части. Кажется, что это лучший подход, чтобы определить каждый предмет приложения и поместить его в свой собственный пакет внутри метеор. Я попытался отобразить это в UML, но результат просто показался мне слишком раздутым.

После игры вокруг в течение некоторого времени, я пришел с чем-то вроде этого:

Внутри пакета сети у меня есть разные папки для каждого случая использования. Из них можно увидеть зависимости для варианта использования. Например, для использования в случае использования для входа требуется пакет проверки и пакет langString и т. Д.

Конечной целью должен быть набор диаграмм для самого приложения и отдельных пакетов, из которых кто-то может понять, что происходит. В то же время, поскольку я работаю один в этом проекте, также не нужно тратить слишком много времени на разработку этих диаграмм.

То, что я на самом деле ищу, - это некоторые передовые методы, используемые другими людьми для разработки таких приложений. Я был бы рад любой помощи. Благодаря!

Answer 1

В то время как UML имеет некоторые хорошие идеи, я обычно не вижу, чтобы он использовался в реальном мире за пределами, возможно, для первоначального проектирования сложных систем. Проблема с его использованием для текущей документации системы - она ​​никогда не обновляется и быстро не обновляется. Как правило, это справедливо для любой документации приложения.

Общепринятая передовая практика заключается в том, чтобы убедиться, что ваш код сам документирует, чисто написан с четкими файлами, именами функций и переменных и комментариями, где вам нужно объяснить, что происходит. Из этого довольно легко ознакомиться с кодом и посмотреть, что происходит, когда вам нужно понять новое приложение или новую часть большой системы.

Если происходят сложные вещи, документ стиля блок-схемы может помочь с общей перспективой архитектуры, но это должно быть достаточно высокоуровневым, поэтому его не нужно обновлять при каждом изменении низкого уровня.

Я действительно не вижу необходимости в документах на уровне вашего показа в примере (хотя я знаю, что вы выбрали что-то простое для примера.) Очевидно, что если у вас есть страница входа имеют login.html, login.css и login.js, и оттуда должно быть просто следовать коду, чтобы узнать, какие поля они обращаются, где хранятся данные и т. д.

Желаю лучшего способа получить системную документацию легко, но, к сожалению, она всегда неактуальна и оказывается бесполезной довольно быстро.