CC BY
48
Хотя подобный формат результатов (рассматривающий целый комплекс элементов системы как одно целое) позволяет выбирать программно-аппаратные платформы для ИСУП, недостатки подобных источников для оценки производительности Java ПСП очевидны:
• SPECjAppServer2002 оценивает лишь малую долю возможностей J2EE 1.3 совместимых серверов приложений;
• довольно высокая стоимость бенчмарка и необходимых программно-аппаратных средств, а также жесткие ограничения на порядок публикации результатов ведут к отсутствию независимых результатов тестирования;
• отсутствие сопоставимых результатов (то есть осуществленных на фиксированных программно-аппаратных элементах с одним варьируемым элементом системы) делает невозможным адекватное сравнение производительности различных Java ПСП приложений и оценку влияния различных компонентов системы на общую производительность.
Для подобного SPECjAppServer2002 бенчмарка основное влияние на общую производительность системы оказывают следующие факторы: аппаратная конфигурация серверов приложений и базы данных; ПСП; используемый Java runtime; сервер базы данных и JDBC драйверы; производительность используемых сетевых интерфейсов (в общем случае как локальной, так и глобальной сетей).
Таким образом, для оценки производительности Java ПСП как самостоятельного элемента ИСУП можно предложить следующий эксперимент на основе выбранной категории Java ПСП и стандартных бенчмарков.
При фиксированных Java runtime, аппаратной конфигурации серверов приложений и базы данных, при сервере базы данных и JDBC драйвере, а также сетевых интерфейсах следует применить подобный SPECjAppServer2002 бенчмарк к каждому Java ПСП из выбранной на основании изложенного категории Java ПСП.
Результаты подобных бенчмарков могут помочь выбрать наиболее производительные Java ПСП. Однако даже столь подробные результаты стандартных бенчмарков мало говорят о производительности ПСП на конкретных приложениях. Единственным надежным подходом, позволяющим уже на ранних стадиях проектирования системы выбрать оптимальный сервер приложений и достаточно точно оценить необходимую аппаратную конфигурацию, является использование специализированных бенчмарков на основе архитектурных прототипов проектируемой системы.
При отсутствии таких универсальных бенч-марков (ранее они не были известны автору) их можно легко разработать для существующего архитектурного прототипа, используя средства записи информации (logging), например, пакет Log4j (http://logging.apache.org/log4j/docs/index.html) для регистрации информации от Apache Software Foundation, сохраняя информацию о времени вызова и возврата архитектурно значимых процедур. При этом следует учитывать время, затрачиваемое средствами регистрации информации на свои собственные вызовы.
Одним из важнейших показателей эффективности Java ПСП является соотношение стоимости оптимальной программно-аппаратной конфигурации на его основе и достижимой производительности. Для предварительного выбора программно-аппаратной конфигурации (Java ПСП, аппаратная архитектура, ОС, Java runtime, сервер базы данных) могут быть использованы результаты стандартных бенчмарков, например SPECjAppSer-ver2002. Однако для оптимального выбора Java ПСП и оценки требований к аппаратному обеспечению необходимы бенчмарки на основе архитектурных прототипов проектируемой системы.
Список литературы
1. Матрица Java ПСП на TheServerSide.com: http://www.theserverside.com/reviews/matrix.tss
2. Бенчмарк SPECjAppServer2002: http://www.spec-bench.org/jAppServer2002/
ПОДХОД К ПОСТРОЕНИЮ СИСТЕМЫ КЛАССА MRP II НА ОСНОВЕ ОБЪЕКТНЫХ ПРЕДСТАВЛЕНИЙ
В.А. Дубенецкий, A.B. Золотое
Новая экономическая ситуация ставит перед предприятиями ряд задач, которые ранее ими не рассматривались: повышение конкурентной борьбы, требование выпускать продукцию в соответствии с текущими заказами покупателей, а не с долгосрочными перспективными планами, необходимость оперативного принятия решений в
сложной экономической ситуации, укрепление связей между поставщиками, производителями и покупателями.
Современные информационные технологии помогают руководителям промышленных предприятий в решении этих задач. Одним из наиболее распространенных методов управления производ-
ством и дистрибуции в мире является стандарт MRP II (Manufacturing Resourse Planning), в котором описываются основные требования к информационным производственным системам.
MRP II - это набор проверенных на практике разумных принципов, моделей и процедур управления и контроля, служащих повышению показателей экономической деятельности предприятия. Стандарт фактически представляет собой функциональную спецификацию высокого уровня и задает функциональные требования к системам класса MRP II. Группы функций и функции согласованы с проверенной на практике обобщенной бизнес-моделью предприятия и призваны поддержать бизнес-процессы предприятия.
Однако в каждом применении приходится учитывать тысячи особенностей и частных детализаций общей модели, которые приводят к созданию заказной системы на базе некоторого ядра. Сопровождение множества реализаций становится практически невыполнимой задачей. Кроме того, конкретная реализация также подвержена серьезным изменениям в связи с изменениями продукции, предприятия, расширениями области приложения информационной системы (ИС).
Сделанную, отлаженную, внедренную и реально используемую систему трудно изменять. В результате ИС может стать тормозом развития предприятия. Причины известны. Например, конструкция ИС, жестко опирающаяся на детали вчерашних потребностей в ИС и способов выполнения управленческой деятельности. Или слишком "конкретное" программирование, замораживающее вчерашнее понимание управленцев и системных аналитиков.
Любая система класса MRP II (как, например, «РЕСУРС») рассчитана на множество реализаций и развитие. Поэтому имеет огромное количество параметров настройки и строится как специализированный инструментарий для реализации проектных решений в области управления предприятием. Часто система имеет свои развитые средства программирования и настройки. Проблема в том, какие модели предприятия используются в качестве основы для настройки и какими средствами осуществляется такая настройка.
Современные технологии и инструментальные средства визуального проектирования предоставляют все необходимое для построения модульной глубоко настраиваемой системы на основе объектно-ориентированного программирования. Однако параметризация периода компиляции ориентирована на группу разработчиков. Изменения на этом уровне происходят достаточно редко и обычно требуют переустановки всех реализаций системы. Кроме того, не представляется возможным на этом уровне учесть все особенности всех реализаций системы, которые к тому же быстро изменяются.
Настройку системы под конкретный проект внедрения желательно выполнять в рамках параметризации периода исполнения. Обеспечить такие возможности позволяет подход, основанный на динамическом описании модели предприятия и на использовании ее в качестве основы для обеспечения нужных свойств конкретной реализации.
Настройка системы всегда опирается на бизнес-модель предприятия, которая часто строится в стандартах IDEF0, IDEF3 и ER. К сожалению, не все проектные решения по настройке системы могут быть адекватно описаны в рамках перечисленных моделей. Это ограничения моделей, а не инструментария.
При создании системы «РЕСУРС» в качестве основы для описания проектных решений настройки предлагается использовать объектно-ориентированную модель предприятия. Основу такой модели составляет спецификация классов предметной области. Такую модель поддерживает инструментарий системы «РЕСУРС». Именно в понятиях этой модели требуется описать модель конкретного предприятия.
Стандарт MRP II основывается на простой и понятной процессной модели предприятия: продукция является результатом производственной деятельности, в процессе которой планируются, перемещаются, потребляются и учитываются различные ресурсы в соответствии с нормативами. Ключевыми моментами в рамках стандарта являются:
• спецификация продукции (услуг) - состав и операционная технология изготовления с указанием норм расхода требуемых ресурсов (bill of materials);
• спецификация производственных мощностей и трудовых ресурсов;
• состав и правила выполнения действий по управлению предприятием (хозяйственные операции, учетные и другие процессы) - бизнес-логика;
• модели и методы управления ресурсами.
Предлагаемый подход базируется на идее классификации сущностей предметной области, которая выполняется за несколько этапов:
- выделение базовых классов предметной области, обладающих высокой степенью абстрагирования и стабильностью спецификации;
- разработка средств поддержки этих классов как в СУБД, так и в приложении;
- разработка средств поддержки для динамического создания и спецификации подклассов в СУБД и в приложении;
- выделение производных классов предметной области применительно к каждому проекту внедрения индивидуально.
Особенностью производственных систем является наличие, по крайней мере, трех групп компонентов: 1) класс (объект) - задает структуру и
методы (например, сборочная единица); 2) элемент класса - описывает конкретные свойства и спецификацию его производства (сборочная единица. 410.00.112 корпус); 3) экземпляр - соответствует физическому объекту предметной области (сборочная единица. 410.00.112 корпус. партия 10001). Поэтому компоненты каждой из групп поддерживаются системой в соответствии с их спецификой.
Применительно к системам класса MRP II на основе анализа стандарта и опыта автоматизации предприятий были выделены следующие базовые классы предметной области: производственный элемент; субъект хозяйственной деятельности; документ; хозяйственная операция; событие; схема работ; позиция плана; накопитель; экономический элемент.
Для поддержки возможностей динамического описания модели были введены следующие базовые инструментальные классы (метаобъекты): подкласс (виртуальный объект); основание классификации; атрибут-строка; атрибут-ссылка на объект; атрибут-перечисление; атрибут-число; атрибут-дата; атрибут-агрегат; атрибут-функция (вычисляемый атрибут); перечисление (справочник).
При разработке класса производственный элемент использовались ЕСКД, ЕСТД, модели операционного описания деятельности, позволяющие учесть потребности в ресурсах при выполнении операции. Основной из них является модель детале-операций.
Для элементов и экземпляров поддерживается концепция жизненного цикла и сохранение истории. Ряд подклассов предопределен (например, материалы и комплектующие, продукция, оборудование), но их количество мало по сравнению с общим количеством подклассов в конкретном проекте внедрения (несколько тысяч).
Все базовые объекты имеют разветвленную схему классификации, каждая из которых должна быть сформирована и занесена в систему. Каждый узел схемы классификации является производным классом соответствующего базового класса. Однако, помимо параметров своего родителя, производный класс может иметь дополнительно собственные параметры. Именно в терминах классов и их свойств разрабатывается модель предприятия и осуществляется настройка системы.
Важнейшим является класс производственный элемент. Несколько первых уровней его классификации жестко определены в системе. Каждый производственный элемент может иметь спецификацию. Однако назначение спецификации для каждого подкласса может интерпретироваться по-разному. В качестве основных подклассов производственных элементов выделены: предметы труда, средства труда, технологические операции.
Принятая модель поддерживает многоаспектную многоуровневую классификацию всех объявляемых объектов. Система классификации существует самостоятельно и не связана с правилами формирования обозначений элементов. Каждый элемент должен быть отнесен к одному терминальному классу в каждой из альтернативных схем классификации. Новый элемент может быть объявлен только после выбора нужного терминального класса. Система классификации предоставляет следующие возможности:
• объявление дополнительных параметров для элементов каждого класса;
• ограничение поиска элементов рамками выбранного класса;
• распознавание класса элемента;
• изменение алгоритма обработки и представления данных в соответствии с описанием соответствующих классов.
Особое место занимает настройка бизнес-логики. Используемая в системе модель опирается на классы схема работ, событие и состояние, для которых также поддерживается классификация и настройка. Схема работ представляет собой взаимосвязанную совокупность работ и описывается как шаблон кооперации элементов системы и пользователей.
Работу можно представить как деятельность по изменению состояний элементов (экземпляров), создание новых элементов и удаление существующих. Работа проходит через ряд фаз. Поддерживается настройка таких компонентов, как сложные работы, планирование работ, контроль выполнения плана работ, очереди работ. Сложное поведение экземпляров описывается моделью коллективного взаимодействия автоматов. Функции переходов описываются в терминах ролей элементов, состояний, событий, прав доступа. Внутреннее представление полностью ориентировано на возможности СУБД.
Событие представляется как некоторый сигнал-сообщение с групповой рассылкой всем запросившим и ожидающим. Реакции на событие распределены в различных элементах, индивидуальны и зависят от контекста каждого из них.
В архитектуре системы «РЕСУРС», в которой практически реализован описываемый подход, выделено пять логических уровней приложения:
1) базовый уровень - обеспечивает моделирование базовых классов предметной области и базовых инструментальных классов;
2) уровень настройки - обеспечивает формирование метаданных предметной области для построения модели предприятия и настройку конфигурации системы управления;
3)уровень объекты MRP - обеспечивает ведение необходимых первичных данных и конкретизацию модели предприятия;
4) планирование и учет производственных ресурсов - поддерживает бизнес-процессы управления производственными ресурсами в соответствии с настроенной моделью предприятия и конфигурацией самой системы;
5) представление - обеспечивает пользовательский интерфейс.
Использование данного подхода позволяет предоставлять широкие возможности для построения схем классификации и схем взаимодействия с указанием заданных параметров классов, ориентированных на конкретное применение.
Разработка системы классов является предметом серьезной проектной работы на этапе разработки проекта внедрения и практически не требует поддержки и вмешательства группы программирования. Более того, работу по настройке может выполнять обученная группа внедрения от заказчика. Подробнее об использовании описанного подхода в практике проектирования можно ознакомиться на сайте www.isresurs.spb.ru.
Список литературы
1. Дубенецкий В.А., Советов Б.Я., Цехановский В.В. Модели информационных технологий организационного управления. // Сб. избран. работ по грантам в обл. информатики и систем управления. - Региональный центр науч.-технич. экспертизы при СПГЭТУ. -1996.
2. Дубенецкий В.А., Ильин В.П., Лачинов Е.С., Цехановский В.В. Объектно-риентированная технология автоматизированного проектирования распределенных информационных систем. // V междунар. конф.: "Региональная информатика-96".- СПб., 1996.
3. Дубенецкий В.А., Ильин В.П., Цехановский В.В. Объектно-ориентированная технология изучения и исследования предметной области системотехнического проектирования. // V междунар. конф.: "Региональная информатика-96". - СПб., 1996.
4. Дубенецкий В.А., Советов Б.Я., Цехановский В.В. Технология формализации структуры понятий предметной области и их функциональных взаимосвязей. // Матер. VI междунар. конф.: «Региональная информатика-98». - СПб., 1998.
5. Дубенецкий В.А., Цехановский В.В. Конструирование концептуальной модели предметной области на примере дискретного производства. // Матер. VII междунар. конф.: "Региональная информатика-2000". - СПб., 2000.
6. Дубенецкий В.А., Советов Б.Я., Цехановский В.В. Представление предметных областей в компьютерной среде. // VII междунар. конф.: "Современные технологии обучения". - СПб., 2001.
ИССЛЕДОВАНИЕ АЛГОРИТМОВ ПОСТРОЕНИЯ СТАТИЧЕСКОГО И ДИНАМИЧЕСКОГО РАСПИСАНИЙ ЗАПУСКА ЗАДАЧ ДЛЯ СИСТЕМЫ ОБРАБОТКИ ДАННЫХ
С.С. Егоров, В.Е. Миллер, Н.Г. Мустафин, Ю.В. Фомкин
Рассмотрим систему с жестким циклом реального времени (РВ) Ат, обрабатывающую информацию, снимаемую со множества однородных источников данных 1=1,2,...,М. Данные от источников могут обрабатываться с помощью N типов задач причем решение задачи ^ автоматически включает в себя решение задачи /¡+1, ¡=1,2,...^-1, над подмножеством того же набора данных. Решаемая на цикле РВ задача Z¡ может обрабатывать подмножество данных только от одного источника 1: Б1Д= с Бц.
На цикле РВ может быть решено Кц экземпляров задачи Z¡, каждый со своим набором данных. Будем считать, что все Кц являются делителями М. Информация на любом источнике данных может возникать случайно независимо друг от друга, причем момент времени ее возникновения не может быть сообщен системе обработки. Степень полноты ¡ данных источника 1 описывается множеством вероятностей {Рц}, ¡=1,2,.,N.
Е Р = 1
¡=1
(1)
Время актуальности данных типа ¡ источников А1ц ограничено и имеет функцию распределения вероятностей Оц(1;)=Р{А1ц<1;}. Если за время актуальности данных типа ¡ на источнике 1 системой
не будет решена одна из задач Zn, п< для источника 1, то данные будут потеряны.
Для решения задачи ^ система потребляет Кц количество ресурса 1, общая составляющая которого ограничена величиной К1тах, 1=1,2,...,Ь. Причем У1,Ц:К1тах > Кц > К1,ц +1.
Для описанной системы требуется построить расписание решения задач ^ над данными для обеспечения минимальной вероятности потери данных при существовании ограничений на потребляемые ресурсы системы.
Рассмотрим множество алгоритмов А(Г), где Г = {Г0, Гь ..., Г^ - вектор частот запуска на решение задач Z¡ каждого типа; Г0 - число циклов РВ, на которых не решаются никакие задачи; Гц -количество запусков задач ¡-го типа, необходимое для обработки всего множества данных. Любой из алгоритмов А(Г) является периодическим; период в циклах РВ равен
N М
Та(Г) = Го + Е Гц— . (2)
¡=1 КЦ
На периоде работы алгоритма задача типа Ц
М
решается Гц— раз, а средний интервал времени Кц
между последовательными попытками обработки
