Доброго времени суток уважаемые коллеги.

Задача: Провести реинжинириг АСУ и представить результат в виде наглядных диаграмм, чтобы по полученным диаграммам была возможность понять что и как работает и как и что нужно менять в случае необходимости доработок системы.

Исходные данные: Система имеющая сложную распределенную структуру. Имеются все исходные коды, разработчики которые ее писали, и некоторая документация.

Какие на данном этапе возникли вопросы:

Внимательно поизучав структурные диаграммы UML родилась следующая идея:
Верхний уровень (СУБД, АСУ) изображать с использованием диаграммы Deployment Diagram,

следующий этап детализации диаграмма Component Diagrams, где изображаются модули из которых состоит сама АСУ,

следующий этап детализации это Class Diagram  которая уже отображает состав классов конкретного модуля системы.

Как средство моделирования используется EA.

Прокоментируйти или посоветуйте

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

А поведение как описывать будете?

Denis
Какие конкртено диаграммы поведения использовать я думаю буду разбираться как только будет подробная структура самой АСУ. Или Вы можете уже что то посоветовать?
Сейчас больше интересует подходит ли выше изложенный способ описания струтуры АСУ? Советы, комментарии подсказки:)

Зачем делать работу, которую за вас уже сделали?

Есть такое понятие - представление (view). В UML 1 имеется 5 представлений, в UML 2 их уже 8.
Надо сначала решить, какие представления вам нужны.
Для каждого представления уже расписано какие требуются диаграммы.

Denis
А можно мат.часть в форме ссылочки на тему Вашего последнего ответа. Заранее благодарен

Из книг всегда советую http://www.books.ru/shop/books/355101 , но это справочник.
А так поищите в интернете "uml + представления"

Denis
Ну про представления мы с Вами как раз и начали разговор, динамика, статика...
Спасибо эта книга у меня уже на столе.
Но может вы тогда посоветуете подход  к реинжинирингу?

Предлагаю познакомится со статьей http://www.osp.ru/os/2006/03/1156601/.

Как я понимаю, раз возникла потребность в реинжиниринге, то существуют определенные проблемы, которые и следует решить. Если есть понимание проблемы, то возможно существуют и некоторое понимание как их решать.
АСУ - вещь сложная и описание ее статической структуры и архитектуры не решит проблемы, а чего там следует поменять.
Мне кажется, что следует описать процессы того как используется система. Затем можно предложить варианты по изменению поцессов, чтобы понять, что следует менять в системе и как.

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

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

magicmhz, что в вашем понимании реинжинириг?
Насколько я понимаю, у вас реинжинириг == reverse engineering? Или я не прав?

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

Забавная ситуация, неужели денег девать некуда? Или это дипломная работа?

Вот представим на секунду ситуацию.
У вас есть стиральная машина. Отлично стирает. Все делает хорошо. Но не известно как. Т.е. разработчик -производитель знает, но вот нужна наглядная схема. Вопрос а зачем? Если все довольны, то зачем?

А затем, чтобы не получилось так:
1. Команда разработки вся встала и ушла, а в программе стирки надо что-то поменять, а то белье не выжимается.
2. Чтобы не покупать еще одну стиралку, кот. выжимает, а про то, что первая выжимает - никто не знает.

magicmhz,
Эд правильно сказал - нужно определиться с целями ваших действий. И относительно этих целей\задач и выдерживать нужную степень детализации представления внутренностей системы.

А затем, чтобы не получилось так:
1. Команда разработки вся встала и ушла, а в программе стирки надо что-то поменять, а то белье не выжимается.
2. Чтобы не покупать еще одну стиралку, кот. выжимает, а про то, что первая выжимает - никто не знает.

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

В случае с АСУ, конечно, дело сложнее, нужно затребовать проектную документацию. Правда, если это не противоречит это интересам самого разработчика. Ведь покупка АСУ не означает, что тебе должны также продать и всю ее начинку...

Задача: Провести реинжинириг АСУ и представить результат в виде наглядных диаграмм, чтобы по полученным диаграммам была возможность понять что и как работает и как и что нужно менять в случае необходимости доработок системы.

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

Исходные данные: Система имеющая сложную распределенную структуру. Имеются все исходные коды, разработчики которые ее писали, и некоторая документация.

Какие на данном этапе возникли вопросы:

Внимательно поизучав структурные диаграммы UML

Почему вы думаете, что показать то, как РАБОТАЕТ система, можно с помощью диаграмм, показывающих СТРУКТУРНО-ЛОГИЧЕСКИЙ состав? Допустим, к вам в руки попадает чертёж какого-либо механизма – понять, как именно он работает в общем случае достаточно сложно. РАБОТАЕТ – значит ЧТО и КАК ПРОИСХОДИТ во ВРЕМЕНИ (хотя бы последовательность). Структурные диаграммы – это про то, ИЗ ЧЕГО СОСТОИТ и КАК ЭТИ ЧАСТИ СООТНОСЯТСЯ. Т.е. они нужны как онтологический базис ("а что вообще участвует в РАБОТЕ?"), но не достаточны.

...родилась следующая идея: Верхний уровень (СУБД, АСУ) изображать с использованием диаграммы  Deployment Diagram, следующий этап детелизации диаграмма Component Diagrams, где изображаются модули из которых состоит сама АСУ, следующий этап детализации это Class Diagram  которая уже отображает состав классов конкретного модуля системы.

Ну это смотря откуда смотреть Если как обычно принято, сверху вниз от бизнеса к технологиям, то Диаграмма размещения (связь программных компонентов и оборудования) и Диаграмма компонентов (взаиомоотношения программных компонентов) – это как раз приземлённый, физический уровень – Диаграмма классов. Ну да ладно, это мелочи.

По сути – помимо упомянутых 3-х категорий диаграмм вам может сильно помочь разбиение системы на бизнес-компоненты и их описание при помощи Диаграммы пакетов способов применения (Use Case Package) и текстом например в виде вики-сайта. Это на уровне бизнес-задач и бизнес-функций системы. На уровне внутренней реализации этих Б-Ф и Б-З как взаимодействия программных компонентов может сильно помочь описание архитектурно-значимых Способов Применения (Use Case) через Диаграмму последовательности и сопроводительное описание.

Ну начнем по порядку, Эдуард на Ваш вопрос ко мне со 100 процентной точностью ответил  bas, за что ему отдельное спасибо.
Denis Да именно, реверс инжиниринг.
Денис Денис бесспорно никто не собирается решать такую задачу исключительно диаграммами, но наглядность это основное и лучше диаграмм врят ли что то найдется. Возможно Вы меня немного не так поняли - нужно понять именно структурный аспект системы, т.е. к примеру у нас есть машина, нам нужно получить ее чертежи, а то как на ней ездить будут (динамический аспект), это не важно. Динамический аспект поведения системы, он ясен, есть инструкции, регламенты и многолетний опыт эксплуатации системы. Опять же после того как будет ясна структура системы, можно будет уже и изобразить ее поведение в динамике. А по поводу Вашего послденего абзаца - возможно есть какие нибудь примеры?