среда, 23 марта 2011, SychevIgor

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

Правильные архитекторы, аналитики строят диаграммы сами, на основе опыта, информации от пользователя и так далее.

В Visual Studio 2010 и ряде плагинов к ней есть возможность генерировать диаграммы из кода (классы, последовательности, архитектурные и так далее). Хочу показать, как можно этими диаграмма запутать не подготовленный разум, запутаться самому и дать пару вредных и не очень советов.

Возможность создавать такие диаграммы есть в версии Ultimate точно.

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

Диаграммы классов

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

Диаграммы сборок и пространств имен

Второй по значимости после возможности генерации диаграмм классов является составление диаграмм зависимостей сборок, классов, namespace-ов. Если проект большой то лучше всего помогает понять на начальном уровне Диаграмма по сборкам и пространствам имен. Тут можно понять архитектуру приложения, если есть описание к ней, то вообще все отлично.

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

Диаграммы последовательностей

Можно генерировать диаграммы последовательностей, которые некоторым образом могут описывать алгоритмы... Именно алгоритмы конкретные ,в которых все зависимости внутри.

Упаси вас Разум пытаться генерировать код по методам, которые вызывают десяток методом в каждом котором есть по алгоритмы, иначе выглядеть это будет вот так а то и хуже.

Как пускать пыль в глаза

Первый вредный совет для студентов. Я сейчас пишу диплом и известно, что сама работа не всех интересует, всем интересно правильное оформление диплома. Часто у хороших программистов тяжело получается писать диплом, так как надо соблюдать тысячи формальностей. На пример все любят, когда есть куча картинок и диаграмм, так кажется что проект реально крутой. Генерация диаграмм по коду может очень сильно пустить пыль в глаза и напугать всех, какой крутой проект. Ну примерно вот так это будет

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

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

Уже лучше.

У меня в проекте есть тесты, которые тестируют работу. Любые тесты добавляют дополнительные зависимости и добавляют сложность на диаграмму(я не против тестов, но на диаграмме они добавляют сложность). Я предпочитаю не отрисовывать зависимости от тестовых сборок, потому что они являясь частью проекта, сами не исполняются во время работы программе, а нужны лишь для тестирования. Удалив сборки с тестами с рисунка, все становится еще проще

После чего окидываем взглядом результат. VS считает, что элемент некого типа и массив этого типа - это разные вещи. Я абсолютно согласен, но если ты используешь массивы типа [,] ; [][]; [] ; [,,][] то на диаграмме 4 дополнительных классов, которые только загромождают картину. Убрали. Заодно удалим файлы конфигов и ресурсов, которые не помогают понять картину, а являются инфраструктурой .net

Все стало просто.

И тут можно обнаружить очень интересные уже моменты, когда все чисто и прозрачно. Есть точка входа, и есть классы, которые не достижимы из нее, такие про запас. У меня на рисунке они выделены желтым цветом. Конечно эти классы, могут быть нужны для других проектов, но у меня то один! Я их написал про запас и забыл интегрировать их вызов. Классы есть, но по сути нет.

О чем я не рассказал

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

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

Выводы от КЭПа.

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

Из обсуждения в твиттере:

Я не утверждаю, что это uml диаграммы соответсвующие стандарту какому- либо. Этого в статье нет. Это диаграммы, которые генерируются в vs2010.

В комментариях было указано, что есть для подписчиков technet-msdn Feature Pack в котором есть возможность генерировать по коду диаграмму классов, такие же как и руками. Я скачал пакет, посмотрел мануалы как делается, вот что получилось. Да оно куда больше похоже на те диаграммы, которые делаются руками. Но особой разницы, кроме того, что можно разложить по пакетам пока не обнаружил. Связи- это реализация интерфейсов.

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

Если есть предложения и пожелание, буду рад обсудить.

P.S. Это моя первая попытка использования http://msug.vn.ua , по этому не судите строго верстку.

---