Нужен совет, как документировать программы

Question

Я знаю основные вещи об UML: - вариант использования - Диаграмма деятельности - Диаграмма классов - Диаграмма последовательности

Все они кажутся мне великолепными. У меня может быть общее «видение» или «понимание» системы или приложения. Но просто "генерал".

Подумайте об этом примере: программисту приходится иметь дело с приложением впервые. Все упомянутые мной документы UML помогут ему получить общее представление о системе. Но однажды его начальник говорит ему: «Есть проблема с« процессом расчета », проверьте его».

Программист должен будет поговорить с пользователем и попытаться понять, в какой форме пользователь обнаружил проблему. Это был Form_Payr.1.2.aspx, когда нажимали кнопку «Ок». Затем программист вернется на свое место и должен просмотреть, что происходит в Form_Payr.1.2.aspx, какие классы и методы вызываются из его кода VB, если процесс выполняется на бизнес-уровне или в хранимых процедурах в базе данных, и, наконец, получить в чем проблема. Программист выполняет все эти задачи только с IDE и отладкой.

Мой вопрос: - Есть ли какой-либо документ или схема UML, в которых будут отображаться, какие программы (vb или aspx) вызывают то, что clases или методы, и какие процессы они выполняют, так что будет проще или быстрее проводить обслуживание.

• Есть ли рекомендации по документированию такого рода карт?

Answer 1

• Есть ли какой-либо документ или схема UML, которые будут отображать, какие программы (vb или aspx) вызывать какие классы или методы, и какие процессы они запустить, так что будет проще или быстрее проводить техническое обслуживание.

Да - вы уже упомянули наиболее важные диаграммы (последовательность / активность). Проблема не в диаграмме, а в том, что диаграмма соответствует коду.

• Есть ли лучшая практика о том, как [документировать] такие карты?

На уровне детализации, на который вы ссылаетесь, фактически невозможно вручную создать диаграммы, отражающие код. Это просто слишком много усилий, чтобы поддерживать оба. У вас есть два варианта:

1. Создание ручных диаграмм на более высоком уровне абстракции. Они могут дать представление о том, как работает система, но не помогут с деталями. Вам все еще понадобится процесс их активного поддержания, иначе они станут устаревшими и бесполезными. Из-за накладных расходов (время и дисциплина) диаграммы вручную имеют тенденцию хорошо работать для документирования основных шаблонов в вашем решении; например ключевые архитектурные механизмы или доменные концепции. Они, как правило, меняются не так часто и дают ценный обзор системы.
2. Убедитесь, что код и диаграммы автоматически синхронизируются. Практически это означает создание одного из другого. Оба возможны.

Существует два основных подхода к варианту (2). Разработка на основе моделей обычно выступает за создание кода из моделей. Это может (и работает) работать, но это парадигма, которую вы должны купить. Если вам удобнее писать код, то есть инструменты, которые будут генерировать диаграммы из кода, например, Enterprise Architect . Я считаю, что Visual Studio также поддерживает это, хотя не использовал его.

НТН.

Answer 2

Я не уверен, что любое количество UML-диаграмм действительно поможет разработчику отследить ошибку.Вот для чего нужны отладчики и IDE.Упомянутые вами диаграммы и карты, очевидно, документируют, что должно произойти, хотя проблема может заключаться в том, что происходит что-то еще.Это может быть в любой момент времени.Это может даже быть трудно воспроизвести, потому что это где-то состояние гонки.Мой совет, инвестируйте в хорошую IDE, отладчик и профилировщик и поощряйте ваших разработчиков справляться с ними.