CC BY
60
существующую СЭМ новых датчиков пиргелиометров, которые улавливают интенсивность солнечного излучения. Ответственный за закупку и установку ведет переговоры с поставщиками, закупает приборы, собирает команду установщиков и контролирует процесс установки.
По завершению установки новых датчиков и прокладки необходимых кабелей для включения их в СЭМ за работу принимается отдел по обеспечению техническому и программному обеспечению. Программист изменяет алгоритм работы системы для программной интеграции нового оборудования, задает новые правила воздействий на автоматы. Специалист по аппаратному обеспечению улучшает аппаратную часть для ускорения работы системы с учетом дополнительных потоков информации. Энергоменеджер взаимодействуя с начальниками подчиненных ему подразделений тестирует работу СППР и обновленной СЭМ в целом. Одновременно ведется работа по составлению новых норм и правил пользования потребителями ТЭР. Дополнительная информация об интенсивности солнечного излучения позволит СППР более эффективно управлять автоматами, воздействующими на источники освещения или отопительную систему. Что приведет к уменьшению энергозатрат.
Выводы
Использование объектно-ориентированного подхода к проектированию СЭМ позволит справиться со сложностью и неоднородностью системы. Классификация и определение общих свойств позволяет ускорить процедуры идентификации объектов, объединять подобные объекты и создавать один алгоритм действия для группы (класса) объектов, что упростит реализацию и ускорит работу СЭМ.
Литература
1. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч; пер. с англ. И. Романовского; под ред. Ф. Андреева - М.: Невский Диалект, 2000. - 359 с.
2. Министерство энергетики РФ // MINENERGO.GOV.RU: ежедн. интернет-изд. 2008. 22 июля. URL: http://minenergo.gov.ru (дата обращения 06.04.2013)
УДК 681.3
ИНТЕЛЛЕКТУАЛЬНАЯ СИСТЕМА ПРОЕКТИРОВАНИЯ ВЕБ-ПРИЛОЖЕНИЙ
Грегер Сергей Эдуардович, доцент, Уральский федеральный университет имени первого Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (фил.), Россия,
Нижний Тагил, [email protected]
В процессе проектирования декомпозицию системы разработки информационных систем обычно производят, исходя из максимальной независимости подсистем. Однако декомпозицию можно произвести в соответствии со взглядом на систему разных групп разработчиков (рис.1). Для каждой подсистемы указаны основные понятия ее предметной области.
Результатом взаимодействия всех этих подсистем и будет являться информационная система (ИС). Подобное деление проявляется как на уровне моделирования, когда каждая подсистема имеет свои группы описаний, представленные в соответствующих моделях, библиотеки модели и инструменты, так и на уровне реализации — каждая подсистема реализуется специфическими для нее программными компонентами. Результирующая ИС может быть рассмотрена как конфигурация взаимодействия групп объектноориентированных компонент. В свою очередь, каждая из групп компонент является результатом деятельности конкретной подсистемы проектирования во взаимодействии с другими подсистемами. Выявление совместно используемых понятий, моделей и т.п.,
50
принадлежащих разным подсистемам, позволяет сформировать единое информационное пространство взаимодействия этих подсистем, включающее общую, разделяемую модель данных. В этом случае различные описания системы не создаются в форме отдельных документов, а хранятся виде взаимосвязанных информационных единиц, готовых для объединения в той или иной форме. Таким образом, речь идет о хранении информации в виде базы фактов и базы знаний об организации этих фактов и доступе к этой информации с разнообразными запросами. Можно сделать вывод о том, что определяющим способом интеграции моделей является согласование понятий, определяющих представления моделей, что вводит необходимость семантического анализа как этапа проектирования системы. Инструментом проектирования в этом случае становится интеллектуальная система проектирования.
Рис.1 - Декомпозиция информационной системы
Под интеллектуальной системой обычно понимается любое программное средство, в архитектуре которого явно выделена база знаний [1]. Информационные системы, основанные на знаниях, строятся как специализированные оболочки над системой знаний сформулированных в терминах некоторой онтологии. В качестве формальной модели интеллектуальной системы можно использовать определение онтологической системы [2]:
2° = <Ometa, {Odst}, 2inf >,
где
Ometa— онтология верхнего уровня (метаонтология);
{Od&t} — множество предметных онтологий и онтологий задач предметной области;
^ — модель машины вывода, ассоциированной с онтологической системой ^ .
Под онтологией здесь понимается кортеж:
O = <C, R, F>
где:
С — множество концептов онтологии;
R — множество отношений между концептами онтологии;
51
F — множество функций интерпретации, заданных на концептах и отношениях.
Онтология включает в себя набор определений понятий предметной области и их взаимосвязей. Система проектирования должна интегрировать знания подсистем и позволять использовать эти знания при решении задач. Каждой из подсистем в общей модели проектирования можно сопоставить свою онтологию. Интеграция обеспечивается наличием метаонтологии, и все частные онтологии строятся на основе системы понятий, определенной в ней. Таким образом, можно представить модель информационной системы в процессе проектирования как кортеж онтологий:
OApp=<Meta, OApp, ODomain, OTask, ONav, OInfo, OComp, OGui, R>
где:
Meta — метаонтология;
OApp — онтология приложения;
ODomain — онтология предметной области;
OTask — онтология задач.
ONav — онтология навигации;
OInfo — онтология информационных элементов;
OComp — онтология компонентов;
OGui — онтология пользовательского интерфейса;
R — множество бинарных отношений между концептами и индивидуалами онтологий.
Каждая частная онтология отображается через отношения из R в некоторые подграфы других онтологий. Интеллектуальная система проектирования, являющаяся инструментальной оболочкой для такого информационного пространства, должна позволять хранить онтологию и знания каждой из подсистем проектирования, а также обеспечивать использование при решении задач тех информационных компонентов, которые в этом случае необходимы, то есть допускать интеграцию знаний и онтологий разных разделов области в рамках одного информационного ресурса. Таким образом, к информационной системе, основанной на знаниях, предъявляются требования:
1. Обеспечение возможности изменения знаний, структура которых определяется онтологией ПО.
2. Наличие средств модификации системы понятий предметной области.
3. Наличие возможности интеграции систем понятий из различных разделов ПО.
В этом случае знания, скрытые в кодах программного обеспечения, в компонентных моделях дизайна приложения и в других реализационных описаниях систем, будут представлены в виде сущностного, не зависящего от деталей реализации описания создаваемой системы. Таким образом, процесс проектирования в качестве своего контекста имеет сеть различных онтологий и решателей задач над нею. Решатели задач обеспечивают различные интерпретации сети онтологий, к которым следует отнести задачи генеративного программирования — полное или частично автоматизированное создание программных компонент. Обеспечение процесса проектирования и генерации компонентов требует методов и инструментов управления как для каждой отдельно взятой онтологии, так и для взаимного согласования указанных «универсальных» онтологий.
Для реализации такой системы проектирования нами был выбран подход, когда различным семантикам описания моделей ставятся в соответствие специализированные редакторы, реализующие эти семантики. Интеграция моделей производится с использованием редактора метаонтологии. Для этого в метаонтологии введены понятия, позволяющие определять виды деятельности, их результаты и исполнителей. Архитектура интеллектуальной системы проектирования представлена на рисунке 2.
Редактор навигационной модели использует онтологию навигации [3] для построения навигационной модели в терминах узлов и ссылок, определяя навигационный контекст и способ представления узла.
Редактор задач позволяет формировать требования к системе в терминах задач, процессов и исполнителей, связывая каждую задачу с элементами предметной области и
52
компонентом-исполнителем задачи.
Редактор пользовательского интерфейса позволяет определять шаблоны разметки вебстраниц приложения, моделировать визуальные элементы, определять для них источники данных, связывать элементы разметки шаблонов с конкретными визуальными элементами.
Редактор компонентов на основе модели предметной области позволяет определять схемы объектно-ориентированных классов и конкретизировать эти схемы с учетом программной системы, в контексте которой компоненты будут созданы.
Рис. 2 - Архитектура интеллектуальной системы проектирования
Каждый редактор использует семантику предметной области, соответствующей подсистемы проектирования. Соответствующая модель, выраженная в терминах этой семантики и представленная выбранным способом визуализации, сохраняется в общей базе знаний системы проектирования. Хранение всех онтологий производится с использованием объектной базы данных [4]. Средством управления метаонтологией будет редактор концептуальных моделей [5], который будет строиться как манипулятор объектами, каждый из которых представляет собой ОО-реализацию элемента нотации метамодели [6].
Интеллектуальная система реализована на основе системы управления содержимым (CMS) Plone [7]. Выполнение инструментальной оболочки в виде веб-приложения позволяет обеспечить совместный удаленный доступ членам различных групп разработчиков, участвующих в проекте, причем распределение прав доступа в этом случае обеспечивается средствами CMS. И наконец, встраивание разрабатываемого комплекса в любой портал, также реализованный на Plone, предоставляет возможность управления порталом через редактирование соответствующих онтологий, а расширение возможностей портала — как через введение новых понятий в указанные онтологии, так и путем создания и подключения новых онтологических моделей.
Все редакторы имеют общую модель, UML-диаграмма модели классов редактора представлена на рисунке (Рис.3). В соответствии с этой моделью каждый редактор включает класс Model, который реализует интерфейс IContainer из API CMS Plone, определяющий поведение контейнера элементов с операциями управления этими элементами. Каждому редактору сопоставляется некоторая онтология, реализуемая внешним по отношению к редактору классом.
53
Рис. 3 - Общая диаграмма классов редактора
Модель включает в себя элементы, тип которых определяется связанной с редактором онтологией. Кроме того, элементы модели могут быть связаны между собой ссылками, при этом элементы могут принадлежать разным моделям. Таким образом, редактор представляет собой некоторый виртуальный контейнер, определенный на подграфе объектноориентированной семантической сети. Над этой сетью может быть определено неограниченное количество виртуальных редакторов различных типов.
Множество редакторов объединяются в разделы портала стандартными средствами управления контентом CMS Plone.
Литература
1. Клещев А.С., Шалфеева Е.А. Грибова В.В. Системы управления интеллектуальными Интернет-приложениями // Владивосток: ИАПУ ДВО РАН. - 2010. - с. 31.
2. Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных систем. -СПб. Питер. 2000. -384 с.
3. Грегер С.Э. Проектирование и реализация навигационной онтологии сайта. // Объектные системы - 2012: материалы VI Международной научно- практической конференции (Ростов-на-Дону, 10-12 мая 2012 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону:ШИ ЮРГТУ (НПИ), 2012. -с. 19-24.
4. Поршнев С.В. Грегер С.Э Совместное использование онтологической модели и объектной моделей при проектировании и реализации информационных WEB-систем // Естественные и технические науки. - №6. - 2011. - с. 461-468
5. Грегер С.Э. Редактор метамодели онтологической системы // Объектные системы - 2012: материалы VI Международной научно- практической конференции (Ростов-на-Дону, 10-12 мая 2012 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2012. - с. 88-92.
6. Сковородин Е.Ю. Грегер С.Э. Построение онтологического портала с использованием объектной базы // Объектные системы - 2010: Материалы I Международной научнопрактической конференции. - Ростов-на-Дону, 2010 г. - с. 74-78.
7. Грегер С.Э. Администрирование и интерфейс пользователя CMS Plone (монография) -Нижний Тагил: Федер. Агентство по образованию, ГОУ ВПО "УГТУ-УПИ им.первого Президента России Б.Н.Ельцина". Нижнетагил. технол. ин-т (фил.) НТИ(ф) УГТУ-УПИ. -140с, 2009.
54
УДК 004.431.4
АВТОМАТИЗАЦИЯ РАБОЧИХ ПРОЦЕССОВ ПРЕДПРИЯТИЯ С ИСПОЛЬЗОВАНИЕМ COMINDWARE TRACKER
Трифонова Анна Александровна, студентка 5 курса, Ивановский государственный химикотехнологический университет, Россия, Иваново, [email protected]
Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, Ивановский государственный химикотехнологический университет, Россия, Иваново, [email protected]
Введение
Перед любым предприятием по мере его развития рано или поздно встает задача автоматизации управления бизнес-процессами. Решить эту задачу можно различными способами, каждый из которых будет иметь собственные преимущества и недостатки. Распространенным способом является создание решения на базе готовой программной платформы. Такой программной платформой могут послужить процессно-ориентированные системы, в частности workflow-системы, получившие распространение в последние несколько лет [1].
В данной статье рассматривается возможность автоматизации процесса выполнения заказа на полиграфическом производстве за счет создания решения в одной из существующих систем. В качестве такой системы была выбрана платформа Comindware Tracker [2]. Она представляет собой программное обеспечение для управления совместной работой, которое позволяет обеспечить коллективную работу различных отделов и команд. Система позволяет в визуальной среде создавать, автоматизировать и оптимизировать процессы, организовывать управление объектами (запросами, требованиями, заказами и др.), автоматически назначать задачи сотрудникам.
1. Постановка задачи
Пусть имеется следующая задача. На полиграфическом предприятии процесс формирования и выполнения заказа происходит следующим образом:
• клиент описывает заказ менеджеру;
• менеджер составляет паспорт заказа, содержащий следующую информацию: данные о заказчике, сроках выполнения, используемых материалах, технологиях, описание наносимых изображений и их цветность, данные о макетах и шаблонах, расчет стоимости единичного изделия и тиража, а также данные менеджера, принимавшего заказ;
• копия паспорта заказа отдается дизайнеру, разрабатывающему изображение и (или) макет;
• после создания макета и утверждения его заказчиком паспорт заказа передается инженеру по фотовыводу, который занимается подготовкой фотоформ;
• после того, как фотоформы подготовлены и проверены на корректность, паспорт заказа передается мастеру цеха;
• мастер цеха, основываясь на данных имеющихся у него на текущий момент паспортов, распределяет задания между работниками цеха (шаблонщиками, печатниками и работниками, отвечающими за дополнительные операции);
• после выполнения задания работником в паспорте делается пометка о выполнении заказа и он передается менеджеру;
• заказчик оплачивает заказ (если им не была осуществлена 100%-ая предоплата) и забирает готовые изделия.
В настоящий момент основным инструментом согласования действий между сотрудниками, участвующими в процессе выполнения заказа, является паспорт заказа, а именно, его бумажная копия. Передача необходимой для работы информации в таком виде
55
