Столкнулся с проблемой подготовки документации по архитектуре и бизнес-логики проекта:
Проект достаточно большой и распределенный (.net, c#, файлов больше 200).

Описал каждый namespase, класс, методы и переменные класса — нихрена не понятно, путаница =(
Описал (типа дерева или xml) структуру и зависимости классов и namespace-ов — куча букав, не понятно нихрена =/
Нарисовал схему, где все namespace и классы соединены стрелочками, согласно зависимостям — получился непонятный клубок =0

Подскажите, пожалуйста — может есть какие методики или даже готовые средства, чтобы провести, фактически, реверс-инжиниринг?
Какие бывают инструменты, чтобы все наглядно визуализировать и отоборазить структуру и бизнес-логику проекта? — проблема именно с инфографикой, потому что по-отдельности все достаточно понятно, просто всего очень много и все достаточно громоздкое.
Я сам, по-старинке, кроме Ворда и Визио ничего толкового не знаю(
Если есть какие-нибудь примеры качественного описания похожего по масштабам проекта — буду мегапризнателен!

NE>Какие бывают инструменты, чтобы все наглядно визуализировать и отоборазить
mindmaps
программа например freemind

Здравствуйте, NoExp, Вы писали:

NE>Столкнулся с проблемой подготовки документации по архитектуре и бизнес-логики проекта:
NE>Проект достаточно большой и распределенный (.net, c#, файлов больше 200).

NE>Описал каждый namespase, класс, методы и переменные класса — нихрена не понятно, путаница =(
NE>Описал (типа дерева или xml) структуру и зависимости классов и namespace-ов — куча букав, не понятно нихрена =/
NE>Нарисовал схему, где все namespace и классы соединены стрелочками, согласно зависимостям — получился непонятный клубок =0

А все потому, что твои документы находятся по сути на том же уровне что и код.
Документация такого рода обычно не дает ничего нового по сравнению с кодом.
Только когда ты уже понимаешь код, то ты можешь понять документ и сказать "да, так и есть".
Польза от картинок, полученных с помощью реверс-инжиниринга тоже в общем нулевая.

Что же реально помогает понять код? На мой взляд вещи это следующие вещи:
— Описание модели предметной области. Если ты не понимаешь какие задачи решает система,
то никогда не поймешь, как устроен твой код. Будешь понимать отдельные методы или какие-то несущественные мелочи,
но в целом систему ты скорей всего не поймешь.
— Общая архитектура системы (подсистемы, модули и интерфейсы). Это даст представление о статической структуре системы.
— Описание динамики системы для некоторых самых важных use case'ов. Кстати, эти самые use case тоже стоит выделить.

Когда высокоуровневые вещи описаны, можно думать о том, что требует более детального описания.
Например можно описать, как подсистемы, модули и пр. ложаться на код.

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

P.S. Кстати 200 файлов C# — это мало на самом деле.
Более того, сколько файлов — это вообще не важно.

Здравствуйте, NoExp, Вы писали:

NE>Подскажите, пожалуйста — может есть какие методики или даже готовые средства, чтобы провести, фактически, реверс-инжиниринг?

Не, средств нет, придется думать, пытаться что-то понять, и результат полученного понимания — отразить в документе.

А иначе обязательно будет фигня непонятная получаться. Неожиданно, правда?

NE>Какие бывают инструменты, чтобы все наглядно визуализировать и отоборазить структуру и бизнес-логику проекта? — проблема именно с инфографикой, потому что по-отдельности все достаточно понятно, просто всего очень много и все достаточно громоздкое.

Кстати, а кто и в каких ситуациях это читать будет — уже решили?

Здравствуйте, Gaperton, Вы писали:

G>Кстати, а кто и в каких ситуациях это читать будет — уже решили?

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

Здравствуйте, NoExp, Вы писали:

G>>Кстати, а кто и в каких ситуациях это читать будет — уже решили?

NE>Читать будет ведущий разработчик проекта, которому он передается в наследство.

Лекции не канают? Надо для одного человека обязательно "учебник" писать?