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

• Часть 1
• Часть 2

При переносе атрибутов внутри и между сущностями можно воспользоваться техникой “drag & drop”, выбрав кнопку в палитре инструментов.

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

Рис. 17. Иллюстрация разрешения
связи многие ко многим

Следует заметить, что автоматического решения проблемы связи многие ко многим не всегда оказывается достаточно. В данном примере один и тот же пациент может много раз посещать врача, поэтому для того, чтобы идентифицировать визит необходимо в состав первичного ключа таблицы “Visit” добавить, например, дату-время посещения.

Иерархия категорий представляет собой особый тип объединения сущностей, которые разделяют общие характеристики. Например, в организации работают служащие, занятые полный рабочий день, совместители и консультанты. Из их общих свойств можно сформировать обобщенную сущность (родовой предок), чтобы представить информацию общую для всех типов служащих. Специфическая для каждого типа информация может быть расположена в категориальных сущностях. Для моделирования категорий служит кнопка в палитре инструментов. Для каждой категории можно указать дискриминатор – атрибут родового предка, который показывает как отличить одну категориальную сущность от другой (Атрибут “Тип” на рис. 18).

Рис. 18. Иерархия категорий

При создании реальных моделей данных количество сущностей и атрибутов может исчисляться сотнями. Для более удобной работы с большими моделями в ERwin’е предусмотрены предметные области (Subject Area), в которые можно включить тематически общие сущности. Для создания предметных областей нужно вызвать диалог Subject Area Editor (меню Edit/ Subject Area…), в котором указывается имя предметной области и входящие в нее сущности. Все изменения, сделанные в предметной области, автоматически отображаются на общей модели

Рис. 19. Диалог Subject Area Editor.

Физический уровень представления модели зависит от выбранного сервера (меню Server/ Target Server..). На физическом уровне модель данных необходимо дополнить такой информацией как учет ограничений ссылочной целостности, хранимые процедуры, триггеры, индексы. Триггеры и хранимые процедуры представляют собой программный код и хранятся на сервере. ERwin обеспечивает мощный инструментарий для создания триггеров: шаблоны и библиотеки макросов. Макросы содержат наиболее часто используемые данные и конструкции. Для редактирования шаблонов триггеров используется редактор Trigger Template Editor (для его вызова следует кликнуть правой кнопкой по таблице и выбрать пункт Trigger в появившемся меню).

Рис. 20. Диалоги Trigger Template Editor
и ERwin Template Toolbox

По умолчанию ERwin генерирует триггеры, дублирующие декларативную ссылочную целостность (опцию можно отменить).

После завершения проектирования модель может быть перенесена в среду целевой СУБД-сервера. Для этого нужно выбрать в главном меню Tasks / Forward Engineer. Можно либо сгенерировать схему БД, либо скрипт на диалекте SQL, соответствующем заранее выбранному серверу. Возможна обратная задача – по существующей схеме БД сгенерировать графическую модель данных. Возможно также выравнивание схемы БД с моделью данных. Для этого следует использовать соответствующую кнопку в панели инструментов (см. таблицу 1). В процессе выравнивания появляется диалог, в котором предлагается указать объекты БД для переноса в графическую модель и объекты модели для переноса в схему БД.

Рис. 21. Диалог Complete Compare-
Resolve Differeces

Для генерации клиентской части во-первых, необходимо выбрать язык программирования (меню Client/ Target Client…, можно выбрать Visual Basic либо Power Builder; далее в примере используется Visual Basic), затем на физическом уровне для каждой колонки необходимо указать свойства – тип визуального представления (style), код валидации и начальное значение (для задания свойств следует кликнуть по таблице правой кнопкой мыши, в контекстном меню выбрать VB Extended Att). Каждое из этих свойств можно предварительно описать в соответствующем редакторе (кнопка …).

После задания свойств для каждой колонки следует сохранить модель. Техника генерации приложения зависит от конкретной среды программирования. Рассмотрим в качестве примера MS Visual Basic 5.0. В среде Visual Basic 5.0 следует выбрать в меню Add-Ins / ERwin / Form Wizard. В появившемся диалоге

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

Связывание модели
данных и модели процессов

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

Рис. 22. Редактор стиля

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

Для экспорта модели данных из ERwin’а в BPwin необходимо в ERwin’е открыть модель, войти в меню File, выбрать опцию Bpwin / Export, выбрать имя файла *.eax и нажать OK. Появится сообщение “Export Successful”.

Затем в BPwin’е нужно открыть желаемую модель процесса, выбрать из меню File / Import / Erwin (EAX)..., выбрать имя файла и нажать OK. Появится протокол импорта. Нужно закрыть диалог протокола и в следующем диалоге кликнуть по кнопке Accept Changes. Теперь можно связать сущности и атрибуты со стрелками. Правой кнопкой нужно кликнуть по стрелке и выбрать в контекстном меню Arrow Data. Появляется диалог Arrow Data Editor. В нем необходимо указать сущности и атрибут(ы), связанные со стрелкой и кликнуть по кнопке OK, чтобы сохранить изменения.

Если в процессе связывания стрелок с объектами модели данных окажется, что каких либо сущностей или атрибутов не хватает, их можно добавить (меню Edit / Entity/Attribute Dictionary), а затем экспортировать в ERwin (в BPwin’е меню File / Export / ERwin(BPX), в ERwin’е меню BPwin / Import) .

Как было указано выше, работы могут воздействовать на данные. Для документирования такого воздействия необходимо кликнуть правой кнопкой мыши по желаемой работе и выбрать Data Usage Editor.

В появившемся диалоге Data Usage Editor нужно в верхнем списке кликнуть по имени стрелки, с которой были связаны сущности и атрибуты. В нижнем левом окне появится список связанных сущностей. Если выбрать сущность, то, во-первых, в правом окне появится список соответствующих атрибутов, во- вторых, в центре открываются окна выбора CRUD (Create, Retrieve, Update, Delete). Если кликнуть по атрибуту, то значение окон выбора меняется на IRUN (Insert, Retrieve, Update, Nullify). Ассоциации CRUD и IRUN –это правила использования сущностей и атрибутов работами. Данные не могут использоваться работами произвольно. Стрелки входа представляют данные, которые работа преобразовывает в выход или потребляет. Такие данные могут быть восстановлены (Retrieve), обновлены (Update), удалены (Delete), но не могут быть созданы (Create). Стрелки контроля могут быть только восстановлены (Retrieve) и не могут быть изменены. Стрелки выхода могут быть обновлены (если им соответствуют данные стрелок входа) или созданы (Create).

Результат связывания объектов модели процессов можно отобразить в отчете Data Usage Report (меню Report / Data Usage Report).

Групповая разработка моделей данных и моделей процессов с помощью Logic Works Model Mart

ModelMart является системой групповой разработки крупных проектов, которая интегрирует инструментальные средства системных аналитиков и разработчиков БД. Одной из проблем, возникающей при многопользовательской работе с моделями, является разграничение прав доступа. Поскольку ModelMart является специализированным хранилищем моделей, помимо разграничения прав доступа на уровне модели возможно регулирование прав на уровне отдельных элементов модели. Для управления правами доступа в состав ModelMart включена утилита ModelMart Security Manager.

Рис.23 ModelMart Security Manager – диалог формирования групп пользователей

Для начала работы необходимо установить сеанс связи с ModelMart, нажав кнопку (из дополнительной линейки инструментов ModelMart среды ERWin’а или BPWin’а) и набрать имя и пароль пользователя в появившемся диалоге. После успешного входа становится доступной кнопка , которая вызывает диалог Security Manager.

Рис.24. Users in ModelMart– диалог внесения новых пользователей

В окне диалога Security Manager можно задать группу пользователей и права каждой группы (кнопка Profile…) на создание, редактирование и удаление библиотек и моделей. В случае работы с моделями данных в ERWin’е можно также задать права на создание, редактирование и удаление для предметных областей (Subject Area) и сущностей. Нажав на кнопку Users…, можно вызвать диалог внесения новых пользователей ModelMart, которых необходимо предварительно завести как пользователей БД (в примере – Oracle).

Не все пользователи БД могут быть пользователями ModelMart, но все пользователи ModelMart должны быть пользователями БД.

Затем можно внести пользователей ModelMart в ту или иную группу пользователей ModelMart. На рис.1 показано, что пользователь SYSTEM внесен в группу Administrator, пользователь SCOTT- в группу Architect. Следовательно, если в течение жизненного цикла разработки проекта роль проектировщика меняется, администратор ModelMart может соответственно менять права доступа без изменения его прав как пользователя БД, что дает возможность гибкого управления проектами.

Рис.25. ModelMart Security Profile Manager – диалог задания прав группам пользователей

Если пользователь имеет соответствующие привилегии, он может создать библиотеку моделей ModelMart, нажав кнопку . В состав библиотеки могут входить модели процессов BPWin’а или модели данных и отдельные предметные области моделей данных ERWin’а (диалог создания предметных областей вызывается кнопкой ) . Принцип работы с библиотеками моделей является весьма полезным при работе с большим количеством моделей, поскольку можно формировать библиотеки готовых решений (как для моделей процессов, так и для моделей данных) и добавлять в новый проект модели-блоки из заранее сформированных библиотек. Для создания новой модели в ModelMart , добавления, открытия и сохранения модели служат кнопки . Создать или сохранить модель можно только в составе какой-либо библиотеки. При открытии модели возникает диалог Open ModelMart Diagramm, в котором можно указать опции блокировки модели.

Рис.26. Диалог Open ModelMart Diagramm

Открытие модели в режиме Read Only означает, что измененную модель нельзя будет сохранить в репозитории. В режиме Locked модель блокируется и другие пользователи не смогут изменить модель. В режиме Unlocked все пользователи могут открыть и изменить модель, при попытке сохранить модель, измененную и сохраненную другим пользователем во время сеанса работы возникает диалог - Intelligent Conflict Resolution, показывающий различия текущей и имеющейся в репозитории моделей. Открытую модель можно перевести в режим Locked, нажав кнопку .

Рис.27. Диалог Review Changes

Кнопка вызывает диалог ModelMart Merge Manager, который служит для слияния моделей. В зависимости от настройки, слияние может быть проведено в одну из существующих, либо во вновь создаваемую диаграмму. Обновление загруженной диаграммы можно осуществить кликнув по кнопке .

Список изменений, сделанных в процессе работы с моделью, показывается в диалоге Review Changes (вызывается кнопкой ).

Рис.28. ModelMart Synchronizer.

Хранимые в репозитории модели можно сравнивать (кнопка ). В диалоге Version Manager следует выбрать сравниваемые версии и кликнуть по кнопке Diff. В появившемся диалоге Version Differences отображается список отличий версий.

В репозитории ModelMart реализована функциональность синхронизации моделей процессов и моделей данных, которая ранее была реализована в ERWin’е и BPWin’е путем экспорта и импорта через файлы .bpx -.eax (см. предыдущий раздел). Для синхронизации моделей необходимо кликнуть по кнопке .

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

Создание объектной модели с помощью Rational Rose

Классический структурный подход к созданию информационных систем предполагает последовательную реализацию этапов анализа, проектирования, создания модулей, объединения модулей в единую систему, тестирования и внедрения. Применение CASE-технологий и CASE – средств, подобных описанным выше ERWin”у и BPWin”у, позволяет в несколько раз сократить время разработки информационных систем и значительно снизить вероятность появления ошибок за счет автоматизации начальных этапов разработки (а, как следствие- более качественного планирования и проектирования ) и автоматической генерации структуры сервера БД и кода клиентского приложения. Однако, эта технология не лишена недостатков. Код клиентского приложения генерируется на основе информации о структуре БД (см. предыдущий раздел). К структуре БД предъявляются определенные требования (нормализации), в результате чего данные хранятся в таблицах БД не всегда в той же форме, в которой они должны представляться на экранных формах. Другими словами, если код приложения генерируется не на основе описания предметной области, невозможно построить эффективное приложение со сложной бизнес-логикой. Кроме того, при структурном подходе к разработке информационных систем, риск остается большим на всех этапах создания системы вплоть до этапа тестирования, когда мы можем обнаружить допущенные ошибки и оценить состоятельность системы. В случае обнаружения ошибки, необходимо вернутся на тот этап разработки, на котором допущена ошибка, и заново пройти последующие этапы.

Альтернативой структурному подходу стали лишенные перечисленных недостатков объектно-ориентированные методы разработки информационных систем. В начале девяностых годов был предложен разработанный на основе наиболее популярных объектных методов - OMT (Rumbaudh), Booch и OOSE (Jacobsom) универсальный язык объектного проектирования – Unified Modeling Language, UML (The Unified Method, Draft Edition (0.8). Rational Software Corporation, October 1995). Одним из CASE-средств, поддерживающих язык UML, является выпущенный фирмой Rational Software программный пакет Rational Rose, который позволяет генерировать код приложения, в полной мере отвечающий бизнес-правилам и с наименьшим риском.

Снижение риска в объектной технологии достигается за счет реализации технологии итерационной разработки (так называемая спиральная модель жизненного цикла разработки). Разработка состоит из ряда итераций, которые в дальнейшем приводят к созданию информационной системы. Каждая итерация может приводить к созданию фрагмента или новой версии и включает этапы выработки требований, анализа, проектирования, реализации и тестирования. Поскольку тестирование проводится на каждой итерации, риск снижается уже на начальных этапах жизненного цикла разработки.

Модель представляет собой совокупность диаграмм, описывающих различные аспекты структуры и поведения информационной системы. Для просмотра модели в Rational Rose используется иерархический навигатор модели – Browser. В дальнейшем будет описан интерфейс версии Rational Rose for Java (version 4.0).

Рассмотрим в общих чертах некоторые диаграммы UML.

Диаграммы использования системы (Use Cases) показывают, какая функциональность должна быть реализована в системе, основные функции, которые должны быть включены в систему (use case), их окружение (actors) и взаимодействие функций с окружением. Воздействующие объекты (actors) не являются частью системы – это конечные пользователи или другие программы, взаимодействующие с проектируемой информационной системой. Функциональность (use case) - последовательность действий, выполняемых системой, которые приводят к определенным результатам, необходимым для конкретного воздействующего объекта.

Рис.29. Диаграмма Use Cases. Здесь Customer, Salespeople – Actors; Register for Order, Validate User – Use case

Диаграммы Use Cases включают отношения и ассоциации, показывающие взаимодействие между воздействующими объектами и функциями (изображаются в виде стрелок) и примечания (note), которые могут быть привязаны к любому объекту диаграммы Use Cases. Для создания новой диаграммы Use Cases следует правой кнопкой мыши кликнуть в навигаторе модели по закладке Use Case View и выбрать во всплывающем меню пункты New / Use Case. Для внесения в диаграмму Use Case и установления связей между ними следует использовать кнопки палитры инструментов Rational Rose.

Рис.30. Диаграмма классов

Диаграммы классов. Под объектом в UML понимается некоторое абстрактное представление конкретного объекта предметной области. Каждый объект имеет состояние, поведение и индивидуальность. Например, объект “Проект” может иметь два состояния – “открыт” и “закрыт”. Поведение объекта определяет, как объект взаимодействует с другими объектами. Индивидуальность означает, что каждый объект уникален и отличается от других объектов. Под классом понимается описание объектов, обладающих общими свойствами (атрибутами), поведением, общими взаимоотношениями с другими объектами и общей семантикой. Класс является шаблоном для создания новых объектов. Для внесения нового класса в диаграмму классов нужно использовать кнопку в палитре инструментов.

Если система содержит большое количество классов, они могут быть объединены в пакеты (package).

Каждый класс может иметь атрибуты ( свойства ). Так, на рис. 30 класс Customer Information (информация о клиенте) имеет атрибуты CustomerID (идентификатор клиента), Name (имя) и Account (счет). Кроме того, каждый класс может методы (operations) – некоторые действия, которые описывают поведение объектов класса. На рис. 30 класс Customer Information имеет метод Check Account. Для внесения свойств класса следует правой кнопкой мыши кликнуть по классу и выбрать во всплывающем меню пункт Specification.

Классы могут иметь взаимосвязи (relationship), называемые отношениями. В нотации UML имеется несколько типов отношений. Отношение использования (associations, кнопка палитры инструментов) показывает, что объект одного класса связан с одним или несколькими объектами другого класса. Отношение включения (aggregation, кнопка ) является частным случаем отношения использования. Оно показывает, что один объект является частью другого. При воздействии на один объект, связанный отношением включения, некоторые операции автоматически могут затронуть другой объект. Например, на рис. 30 класс Customer Information связан отношением включения с классом Contract. При удалении объекта класса Customer Information (информация о клиенте) должны удаляться все объекты класса Contract (относящиеся к данному клиенту контракты). Каждая связь может быть охарактеризована определенной фразой, называемой именем роли. Связь между классами Customer Information и Contract имеет имя negotiates. Каждая связь может иметь индикатор множественности, который показывает, сколько объектов одного класса соответствует объекту другого класса. На рис. 30 связь negotiates имеет индикатор 1..* (один или много).

Наследование (inheritance) описывает взаимосвязь между классами, когда один класс (называется подклассом, subclass) наследует структуру и/или поведение одного или нескольких классов. На рис. 30 подкласс VIP наследует свойства и поведение класса Customer Information. Связь классов в иерархии наследования называется отношением наследования (generalization, кнопка ).

Временная диаграмма (Sequences) демонстрирует поведение объектов во времени. Она показывает объекты и последовательность сообщений, посылаемых объектами. Сообщения на диаграмме сценариев изображаются в виде стрелок.

Архитектура приложения описывается в диаграммах компонент (Component Diagram), которые описывают вхождение классов и объектов в программные компоненты системы (модули, библиотеки и т.д.) и диаграммы развертывания (Deployment Diagram), при помощи которых документируется размещение программных модулей на узлах (физических и логических устройствах) системы. Здесь эти диаграммы не рассматриваются.

Рис.31. Временная (Sequence )диаграмма

Генерация кода осуществляется на основе диаграмм классов. Для генерации необходимо выбрать пункт меню Tools / Java / Generate Java.

Ниже приведен код на языке Java, соответствующий классу Customer Information:

//## //## Source file: Customer__Information.java
//## //## Subsystem: Component View
//## //## Module: Customer Information
//##begin module.cm preserve=no
/* %X% %Q% %Z% %W% */
//##end module.cm
//##begin module.cp preserve=no
//##end module.cp
//##begin module.additionalImports preserve=no
//##end module.additionalImports
//##begin module.imports preserve=yes
//##end module.imports
//=====================================
//##begin module.declarations preserve=no
//##end module.declarations
//##begin module.additionalDeclarations preserve=yes
//##end module.additionalDeclarations
public class Customer__Information {
//##begin Customer__Information.initialDeclarations preserve=yes
//##end Customer__Information.initialDeclarations
public int m_CustomerID;
private int m_Name;
private int m_Account;
public Vector m_negotates = new Vector();
public void Check_Account() {
//##begin Customer__Information::Check Account%3561A0AF032A.body preserve=yes
//##end Customer__Information::Check Account%3561A0AF032A.body
}
//##begin Customer__Information.additionalDeclarations preserve=yes
//##end Customer__Information.additionalDeclarations
}

При генерации кода Rational Rose включает строки комментария, начинающиеся последовательностью символов “//##” . Сгенерированный код (в отличие от кода, сгенерированного ERWin) не является готовым приложением. Здесь генерируются лишь заголовки методов (Check_Account), сами методы необходимо дописывать вручную.

Рис. 32. Модель данных

Создание модели данных на основе объектной модели с помощью ERWin Translation Wizard

Rational Rose позволяет строить объектную модель, но не может построить модель данных или сгенерировать системный каталог сервера БД. Для решения этой задачи фирмой Logic Works выпущена утилита ERWin Translation Wizard, позволяющая перегрузить объектную модель в ERWin и автоматически получить на ее основе модель данных. После инсталляции ERWin Translation Wizard вызывается из среды Rational Rose. Для того, чтобы классы могли быть конвертированы в сущности модели данных, они должны быть определены как Persistent. Для этого необходимо правой кнопкой мыши кликнуть по классу, выбрать во всплывающем меню Specifications… / Detail / Persistence . ERWin Translation Wizard позволяет как сгенерировать диаграмму классов на основе модели данных, так и модель данных на основе диаграммы классов. На рис. 32 показана модель данных (физический взгляд), полученная на основе диаграммы классов, представленной на рис. 30. Модель данных может быть использована для генерирования системного каталога сервера БД (см. предыдущий раздел).

В таблице показано соответствие между объектами диаграммы классов и объектами модели данных при перегрузке моделей из Rational Rose в ERWin и обратно.

1. Маклаков С.В. Erwin расширяет свои возможности. - Компьютер пресс, 3, 1998
2. Дейта К. Дж. Введение в системы баз данных/ -Киев^ Диалектика, 1998

Контактный телефон:
7 (095) 135-2519 Маклаков Сергей
E-mail: maklakov@ interface.ru [an error occurred while processing this directive]

Версия для печати