Анализ взаимосвязей объектов моделей в PowerDesigner или что такое Link&Sync

добавлено: 25 май 11
понравилось:0
просмотров: 7908
комментов: 4

теги:

Автор: AnyaNartova

Продолжая цикл публикаций о продукте Sybase PowerDesigner, мне хотелось бы рассказать об одной из его наиболее интересных и важных возможностей, - о создании и анализе связей между всеми моделями проекта.
Как говорилось в моем предыдущем посте – PowerDesigner, - это инструмент, позволяющий создавать модели самого различного вида, охватывая весь процесс моделирования. В одном инструменте можно описать требования к системе, все необходимые бизнес-процессы, спроектировать модель данных и сгенерировать все необходимое для ее физической реализации, а также создать объектную модель будущей системы. При необходимости, возможно решить и более сложные задачи – например, - описание процесс перемещения данных из оперативной базы в хранилище или проектирование архитектуры предприятия в целом. Казалось бы – зачем решать настолько разные, на первый взгляд, задачи в одном инструменте, какие преимущества это дает?

Одним из основных преимуществ такого подхода, на мой взгляд, является возможность выстраивания взаимосвязей между различными слоями моделирования, а также возможность анализа этих взаимосвязей. Так или иначе, любая модель на любом уровне служит одной цели: описать (или задокументировать) функционирование уже имеющейся в наличии или планируемой системы или набора систем, функционирующих в компании. Это описание необходимо для того, чтобы иметь детальное представление о структуре и функциональных возможностях имеющихся и/или планирующихся к разработке систем, и, что наверно, более важно, для возможности внесения изменений в системы на этапе проектирования и оценки трудозатрат, которые потребуются на эти изменения.
Представим себе пример компании, в которой функционируют интернет-магазин и склад товаров и эти две системы никак не связаны между собой. В сущности «Продукт» системы интернет магазина присутствует характеристика «наличие товара на складе», но до недавнего времени значение этого параметра велось вручную, за что был ответственен работник склада, комплектующий поставки в соответствии с полученными из интернет-магазина заказами. Такой подход не мог дать гарантии точности значения параметра наличия товара на складе, что стало приводить к большому количеству недоразумений с потенциальными покупателями. Поэтому было принято решение провести интеграцию этих двух систем, - чтобы информация о наличии товара на складе автоматически попадала в карточку продукта и при этом указывалось, какое число экземпляров данного продукта имеется на складе в данный момент. С другой стороны, в складскую систему, должны попадать данные о резервировании продукта в интернет-магазине.
Если рассуждать логически, - видимо для реализации этой системы потребуется изменение сущности «Продукт» в системе интернет-магазина, и сущности «Товар», на складе. Какие еще дополнительные объекты базы это может затронуть? Хранимые процедуры, триггеры, представления? Видимо, потребуется изменение интерфейсов редактирования данных сущностей. Какие объекты и классы отвечают за данные интерфейсы? Какие еще объекты могут быть затронуты этим изменением? Видимо поменяются какие-то бизнес-процессы – какие и как? Если мы будем вносить изменения в текущую систему – не затронем ли мы еще какие-либо требования и ограничения? А если еще имеется хранилище данных, в которое попадает информация о заказах и описаны ETL процедуры перемещения данных? Как это отразится на них?
Даже на таком, относительно несложном примере видно, что для того, чтобы качественно ответить на вопрос – какие именно изменения в системах нужно произвести, чтобы выполнить требующуюся задачу и сколько времени это займет, - потребуется довольно детальный анализ имеющихся систем на самых различных уровнях. Если при этом нет автоматизированной системы, которая могла бы помочь провести подобный анализ – вероятность ошибки довольно высока.
PowerDesigner позволяет существенно снизить объем головной боли, при решении подобных задач. Достигается это за счет наличия следующих возможностей.

1. Все модели PowerDesigner связаны между собой. Можно выделить слеующие основные типы связей.

1. Прямая связь объектов модели через свойства объектов. Примерами могут служить: колонки в таблице содержат ссылку на таблицу, а таблица имеет список колонок; таблица содержит ссылку на владельца (owner); объект, описывающий связь (relationship) между таблицами содержит информацию о таблицах-участниках связи, а таблица – в свою очередь – содержит список ссылок на все имеющиеся у нее входящие и выходящие связи.

2. Связь между объектами разных моделей одного типа. Чаще всего, такие связи возникают при использовании ссылок на объекты (shortcat) или копий объектов (replica). Например, в одной из моделей создан список базовых объектов (своего рода, библиотека), используемых в других моделях, более специфично описывающих предметную область. В этом случае в модели предметной области создается ссылка на объект из модели-библиотеки (например, - ссылка на таблицу). Ссылка на объект является полноценным представителем объекта и может участвовать в тех же связях, что и исходный объект: например, в случае таблицы это означает, что можно создавать связь между таблицами текущей модели и таблицей-ссылкой.

3. Связь, создавшаяся в ходе генерации одной модели из другой: например из концептуальной модели данных можно сгенерировать физическую и наоборот, из любой из моделей данных можно сгенерировать объектно-ориентированную модель. В процессе такой генерации, во всех объектах сгенерированной модели будет сохранена информация об объектах, послуживших источниками генерации. Кстати, наличие этой связи позволяет довольно легко выполнять и обратную генерацию, обеспечив, таким образом, процесс циклического проектирования: например, - от концептуальной модели данных к физической, а за ней – к генерации БД и наоборот.

4. Мэппинг объектов. В PowerDesigner встроен инструмент под названием редактор мэппингов, позволяющий показать связи между сущностями и их атрибутами в моделях одного или нескольких типов. Можно показать связь между сущностями и атрибутами концептуальной модели и таблицами и колонками – физической; между атрибутами атрибутами и сущностями логической модели и классами и их переменными – объектно ориентированной. Или связь между объектами XML-модели и атрибутами и сущностями концептуальной модели. Наиболее классическим примером использования редактора мэппингов может выступать демонстрация связи между таблицами и колонками оперативной системы и системы хранилища. Обе эти системы описаны в физических диаграммах, но структура данных, как правило, отлична.

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

6. И последнее – это так называемая дополнительная связь (extendend dependency), - она позволяет связать любой объект из любой модели с любым другим объектом любой другой модели. Наличие такой возможности позволяет любые связи между объектами моделей, семантика которых не соответствует ни одному из вышеперечисленных типов.

2. Связи любого объекта можно проанализировать на любую глубину.

PowerDesigner позволяет просмотреть все вышеперечисленные связи любого своего объекта – они видны в карточке свойств объекта, и уже одно это может существенно упростить анализ взаимосвязей системы. Однако, если необходимо внести какое-либо изменение в систему, - удалить или изменить какой-либо объект, - анализа ближайших взаимосвязей объекта как правило бывает недостаточно, - необходимо видеть всю цепочку. Вот как раз в таких случаях приходит на помощь вторая важная функция PowerDesigner – Анализ влияния и происхождения объекта (Impact and Lineage Analysis). Эта функция позволяет проследить происхождение объекта на всю глубину цепочки, и понять – на какие объекты влияет данный объект, - тоже на всю глубину цепочки. Крайне важно, что данная функция является кроссмодельной – то есть в результаты анализа включаются объекты из всех моделей, которые каким-то образом связаны с анализируемым объектом.
Доступно два вида представления результатов анализа: в режиме preview – где объекты отражаются в виде дерева; и в режиме диаграммы, - где объекты представлены в графическом виде, а связи между ними показывают тип связи между объектами. Представление-диаграмма сохраняется в PowerDesigner в виде отдельной модели и может быть сохранено для дальнейшего использования. Например – можно сохранить два результата анализа одного и того же объекта, выполненных в разное время, а затем сравнить эти результаты между собой воспользовавшись стандартным механизмом сравнения моделей PowerDesigner.

Для наглядной демонстрации рассмотрим пример.

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

Из нее была сгенерирована физическая модель:
Картинка с другого сайта.

Между концептуальной и физической моделью задан мэппинг:
Картинка с другого сайта.

Теперь проанализируем объект Product из физической модели. Результаты анализа в режиме Preview будут выглядеть следующим образом:
Картинка с другого сайта.

А в режиме диаграммы – вот так:
Картинка с другого сайта.

Пунктирной линией на диаграмме обведен объект, анализ которого выполнялся. Сверху, расположены объекты, от которых зависит анализируемый объект, а снизу, - те, которые зависят от него. Объекты, от которых зависит анализируемый объект, помечены обозначением [Lineage] - происхождение, а объекты, которые зависят от анализируемого – обозначением [Change] – влияние. Если мы хотим изменить анализируемый объект, то в этом случае наиболее важными будут объекты с пометкой [change], поскольку изменение нашего объекта отразится на них.

Рассмотрим происхождение объекта. В нашем примере анализируемым является объект Table Product из модели Физическая Схема магазина. Анализ показывает, что он был сгенерирован (Generation Origin) из сущности Entity Продукт модели Концептуальная Схема магазина. Также наша таблица связана (Outgoing References) с таблицей Table Category, той же физической модели, которая, в свою очередь, была сгенерирована из сущности Entity Категория концептуальной модели. Также в анализе происхождение мы видим наличие мэппинга между таблицей Product и сущностью Продукт, - и между таблицей Category и сущностью Категория соответственно.

Теперь посмотрим на анализ влияния. Мы видим, что единственная выходящая ссылка из анализируемого объекта Table Product, указывает на мэппинг между этой таблицей и соответствующей ей сущностью Продукт из концептуальной модели. Изменение таблицы Product может оказать непосредственное влияние на этот мэппинг. Источник мэппинга – это сущность Продукт, которая, в свою очередь, связана с сущностью Категория. Соответственно, они тоже, теоретически могут быть затронуты изменением. Сущность Категория служит источником для сгенерированной таблицы Category из физической модели, а значит, она тоже, в свою очередь может быть затронута изменением.

Комментарии


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

  • 25 мая 2011, 16:23 AnyaNartova

    Чтобы описать функции PD хотя бы в общих чертах используя сквозной пример, понадобится целую книгу написать, - в статью это никак не влезет. :) Поэтому я стараюсь выдавать информацию по частям.
    Что касается объема вывалившейся при анализе информации - есть возможность настройки параметров анализа и включения/выключения различных типов анализируемых объектов. И вы правы - эта функция действительно необходима, т.к. при большом кол-ве связей диаграмма может получиться довольно громоздкой.

  • 29 мая 2011, 21:18 Роман Дынник

    Доступненько ))
    Но получившиеся в результате Impact Analysis наверное стоило бы прокомментировать и разобрать подробнее.

  • 30 мая 2011, 11:23 AnyaNartova

    Спасибо :) Я постараюсь в ближайшее время добавить пару абзацев с комментами к диаграмме.



Необходимо войти на сайт, чтобы оставлять комментарии