ПРОЕКТИРОВАНИЕ МОДЕЛИ ДАННЫХ ДЛЯ СОЗДАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДОМЕННОГО ЦЕХА ПО ТЕХНОЛОГИИ POWER DESIGNER

Power Designer компании Sybase реализует объектно-ориентированную методологию на основе стандарта UML и предназначен для моделирования данных [1]. Его можно эффективно использовать при создании информационных систем (ИС) как на фазе анализа требований, так и на фазе проектирования систем [2]. Этап реализации ИС завершается работами на сервере и в среде разработки приложений клиента, т.е. без использования Power Designer.

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

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

Рисунок 1. Диаграмма деятельности доменного цеха в виде BPMN-модели

Power Designer существенно превосходит авторитетный Rational Rose по средствам моделирования деятельности [2, 3, 5]. Так, с помощью модуля BPMN Power Designer можно построить диаграмму деятельности, которая отображает служебные роли персонала цеха и работы для регистрации в ИС (см. рис.1) [5]. Логические операторы ИЛИ/И на рис. 1 показывают возможные и обязательные компоненты для включения в состав шихты или доменной продувки. Полученная диаграмма может служить базой для разработки ведущей диаграммы UML – диаграммы вариантов использования (UseCase), управляющей всем процессом разработки [4]. Для создания этой диаграммы выделим из числа работников цеха тех, кто будет допущен к формированию и извлечению информации на рабочей станции (РС) нашей ИС – это начальник смены, мастер домны, сотрудники физико-химической лаборатории и оператор РС. Указанные субъекты становятся действующими лицами (actor) диаграммы, определяющей цели и задачи разработки ИС. Для формирования UseCase будем опираться на представления бизнес-модели на рис.1. В результате этого получим диаграмму UseCase на рис.2. Для завершения этой разработки все варианты использования необходимо специфицировать, т.е. определить содержание и формы представления информации каждого UseCase. Например, для варианта использования “Приготовить шихту” можно записать: “Состав шихты зависит от сорта выплавляемого чугуна или ограничивается наличием доступных сырьевых ресурсов. В состав шихты может входить или железная руда, или окатыши, или агломерат, а также металлолом; топливом доменного процесса обычно является кокс (или древесный уголь, а также природный газ). Качество кокса отличается содержанием серы и зависит от поставщика; обычным компонентом шихты являются флюсы. В зависимости от состава рудных примесей в качестве флюса могут применяться известняк, песчаник, кремнезем и др.”. В спецификации  варианта использования “Получить продукты литья” можно записать: “Продуктами доменной плавки являются жидкий чугун (тонн), шлак (тонн), колошниковый газ (м3) и, после очистки, доменная пыль(тонн). Сортность чугуна зависит от содержания углерода (1-7%) и состава примесей – серы (<0,1%), марганца, фосфора, кремния (в %) и др. Часть шлака отправляется на гранулирование для последующего применения, остальной шлак – на золоотвал (обычно 40—50%)”. Аналогично нужно специфицировать остальные UseCase. Приведенные спецификации будут служить основой для конструирования классов и определения их атрибутов

Рисунок 2. Диаграмма вариантов использования для ИС доменного цеха.

После завершения специфицирования всех UseCase работы на фазе анализа требований считаются выполненными и можно переходить к фазе проектирования. Прежде всего необходимо классифицировать всех участников доменного процесса по исполняемым ролям. Основные рабочие цеха – горновые, газовщики, водопроводчики и др.- это объекты класса Рабочий_цеха. Вспомогательных работников – энергетиков, слесарей-ремонтников, лаборантов, специалистов КИП, др. – отнесем к классу Персонал_цеха. Руководителей, мастеров и бригадиров цеха отнесем к классу Управл_персон. Далее необходимо разработать диаграмму взаимодействия (кооперации) объектов. Для этого нужно извлекать из потоков событий всех UseCase на рис.2 объекты классов, посылающих или принимающих сообщения (message) других объектов. Выделенные объекты должны быть соотнесены с каким-либо классом. По соображениям удобства некоторые объекты могут быть неименованными (анонимными). На рис. 3 представлена полученная диаграмма.

Рисунок 3. Диаграмма кооперации объектов классов доменного цеха

Все объекты и классы, появившиеся в результате построения этой диаграммы, зарегистрированы в браузере PowerDesigner обособленными группами. В составе всех классов, принимавших сообщения, имеются операции. После перетаскивания (drag&drop) пиктограмм классов на пустое рабочее поле  вновь открытой диаграммы Class получают множество несвязанных классов с пустыми полями атрибутов. Далее требуется определить отношения ассоциаций между классами и задать атрибуты, отвечающие интересам заказчика. Например, для класса Чугун нужно задать: марка чугуна, содержание углерода и серы (%), количество литья (в тоннах), фамилии мастера и лаборанта, принимавших литье, и дату. PowerDesigner требует при формировании атрибутов задавать и типы данных из некоего списка предопределенных типов. Эти типы позднее могут будут уточнены для выбранного сервера. Полученная таким путем диаграмма классов приведена на рис. 4.

Рисунок 4. Диаграмма классов доменного цеха

Следующим шагом проекта будет запуск из меню Tools генератора CDM – концептуальной модели данных – и настройка его опций. PowerDesigner проверяет работу генератора (check model) и при обнаружении ошибок в модели выводит сообщения или предупреждения. Полученная модель CDM представлена на рис. 5.

Рисунок 5. Концептуальная модель данных доменного цеха

Как видим, линии ассоциаций приняли вид “гусиных лапок”, пропали поля операций классов, а для всех данных символьного типа (Char) задана длина (1), что необходимо исправить вручную с учетом длины вводимых данных. Кроме того, в браузере PowerDesigner появились сущности с именами бывших классов. Прежде, чем запустить генератор логической модели данных LDM необходимо в каждой сущности CDM определить первичный ключ, а в опциях генератора LDM обязательно включить проверку модели, т.к. этот генератор может выявить много ошибок. Основной результат работы генератора LDM – это выполнение миграции ключей в связанных сущностях и образование внешних ключей (Foreign Key) (cхему LDM опускаем).

На заключительном шаге проектирования необходимо создать физическую модель данных с помощью генератора FDM. При настройке опций этого генератора обязателен выбор сервера для организации базы данных (БД) и приведение типов данных модели в соответствие с выбранным сервером. Сгенерированная модель данных приведена на рис. 6. В данной модели воплощены все цели, предусмотренные вариантами использования (рис.2): предусмотрены регистрация состава шихты, продуктов литья, расхода ресурсов, отказов оборудования и др.

Рисунок 6. Физическая модель данных доменного цеха для сервера MS SQL Server

Теперь можно из меню Database запустить генератор из пункта Generate Database и получить SQL- скрипт для развертывания БД на сервере. Приводим для примера небольшой фрагмент этого скрипта: go

if exists (select 1 from dbo.sysreferences r join dbo.sysobjects o on (o.id = r.constid and o.type = 'F') where r.fkeyid = object_id('Шихта') and o.name = 'FK_ШИХТА_ASSOCIATI_УПРПЕРСО') alter table Шихта drop constraint FK_ШИХТА_ASSOCIATI_УПРПЕРСО go

Выполнение операций на сервере и разработка приложений клиента составляют содержание этапа реализации ИС и здесь не рассматриваются. Как видим, PowerDesigner является эффективным инструментом быстрой разработки систем как на фазе анализа требований, так и на фазе проектирования ИС.

Список литературы:

1. Анна Нартова. PowerDesigner 15. Моделирование данных.- Издательство “Лори”, 2012
2. Salikov V.A.  Analysis and specify requirement at information systems with Power Designer // Eastern European Scientific Journal (Gesellschaftswissenschaften): Düsseldorf (Germany): Auris Verlag, 2016, № 5.
3. Саликов В.А. Проектирование информационных систем по технологии Rational Rose. Учебное пособие для дипломников. Издатель: LAP LAMBERT Academic Publishing, Saarbrücken, Deutschland, 2016- 128 c.: ил.
4. Якобсон  А, Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.- Питер, 2002.
5. Business Process Modeling. PowerDesigner. Document ID: DC38088-01-1510-01. Sybase, Inc. Dublin, 2009.