Моделирование приложения. Когда использовать какую диаграмму?
Мой проект тем временем становился все больше и больше. Теперь я теряюсь в своем коде и даже меняю вещи, которые были зафиксированы в моей памяти. Это ужасно, потому что по мере роста моих строк кода моя производительность снижается. Я просто хочу добиться того, чтобы моя производительность оставалась постоянной. Теперь я хочу получить свое заявление на бумаге, чтобы вернуть обзор, если я снова потерян, и иметь что-то, к чему я могу придерживаться. Но я не знаю, как правильно моделировать. Я попытался смоделировать его в виде диаграммы состояний, но это, например, неприменимо, если код просто выполняет построчно то, что не имеет состояния. В этом случае блок-схема будет в порядке. Но я не знаю, как это смешивать, чтобы это имело смысл в целом.
Как я должен начать получать вещи на бумаге? Какова обычная практика для моделирования большего приложения? Когда я использую какую диаграмму?
Решение
Чтобы понять ход программы, вы можете использовать диаграммы деятельности. Чтобы понять взаимодействие между объектами, вы можете использовать диаграммы последовательности. Чтобы понять модули, вы можете использовать диаграммы классов и, возможно, включить связанные классы в пакет. Затем вы можете нарисовать высокоуровневые зависимости между модулями. Это даст вам высокий уровень, а также немного подробную информацию об уровне вашего проекта.
Другие решения
В ответ на комментарий «Но как бы вы кого-нибудь проиллюстрировали, как приложение работает в целом?»: Для большого приложения вы не можете. Как работает MsWord в целом?
Чтобы показать, как работают части в приложении, вы используете случаи применения. С этого момента вы используете диаграммы классов (состав), диаграммы последовательности (поток программы) и диаграммы состояний (укажите), если необходимо, чтобы показать дизайн для каждого варианта использования. Ваш код должен отражать эти диаграммы
Разработка на основе моделей позволяет обеспечить качество программного обеспечения. Прежде всего, независимо от того, насколько это дорого или отнимает много времени, это следует делать для всех проектов, особенно когда масштаб проекта увеличивается. У меня та же проблема с нашим собственным проектом, который был разработан первым без каких-либо моделей. Так что наберитесь терпения.
Первый шаг в реализации системы для реализации, это описать, что должна делать система, что можно наблюдать, как происходит взаимодействие с пользователями и другими системами. Диаграмма вариантов использования — ваш способ ответить на эти вопросы.
Тогда вы можете подумать, сколько классов вам может понадобиться. В вашем случае, поскольку вы уже закодировали какую-то часть, подумывает о том, как разделить основную функциональность на множество небольших классов и установить связь между ними. Там вам нужна диаграмма классов.
Эти два наиболее распространенных обозначения, которые вы должны иметь, по крайней мере, чтобы иметь представление о вашей общей структуре.
Если у вас сейчас много классов, то как ведет себя система? Как порядок или последовательность данных и рабочий процесс? В вашем наиболее важном сценарии, какие вызовы в какой последовательности должны выполняться для выполнения задачи? Вот почему вам нужна диаграмма последовательности или диаграмма сотрудничества.
Я бы сказал, начать с этого и продолжить больше моделей после этого.
Чтобы распутать большой беспорядок, я бы начал с того, чтобы решить, каковы различные темы приложения. Например, в автомобиле без водителя у вас могут быть обработка изображений, обнаружение и предотвращение посторонних тел, обнаружение и отслеживание дорог, регулирование скорости, навигация и т. Д. Если вы смешиваете свои темы в одном модуле, у вас возникают проблемы. Каждый из этих предметов может быть пространством имен. Затем разделите ваши классы / модули на соответствующие им пространства имен. Выясните, как ваши классы могут обрабатывать различные варианты использования, и при необходимости добавлять / удалять классы. Затем следуйте правилам книги «Чистый код» и придерживайтесь простых методов.
Представление 4 + 1 в архитектуре указывает на то, что не существует единого представления, которое описывает всю систему. 4 + 1 обсуждается с использованием логических представлений, представлений разработки, процессов, физических представлений и сценариев. Все они имеют аналоги UML.