CC BY
26
В данном варианте в пакет Project Repository добавлены интерфейс I.Repository и два конкретных типа DbRepository и XmlRepository. Из диаграммы видно, что количество зависимостей между классами увеличилось столь серьезно, что для управления ими требуется принципиально новый, более эффективный подход. Таким подходом сегодня является шаблон Внедрение зависимости (Dependency Injection). Реализующие его программные компоненты принято называть DI-кон-тейнерами. На диаграмме используется DI-контей-нер Unity для платформы .NET компании Microsoft.
Основная задача контейнера - предоставить клиенту полностью инициализированный объект со всеми зависимостями, не обременяя клиента знаниями об этих зависимостях. Например, когда классу AssessmentManager требуется экземпляр класса, реализующего IRepository, ему совсем необязательно знать конкретный тип и тот факт, что этот тип, например DbRepository, зависит от интерфейса ILogger. Класс AssessmentManager требует экземпляр нужного типа у контейнера, а контейнер исследует требуемый тип и пытается создать экземпляр, внедряя нужные зависимости. Действуя по цепочке, контейнер в итоге создает полный граф объектов, готовых к использованию клиентом.
Для того чтобы контейнер знал, какой тип соответствует интерфейсу, его необходимо предварительно сконфигурировать. Большинство DI-кон-тейнеров поддерживают возможность задания конфигурации на уровне внешних текстовых фай-
лов, что позволяет исключить необходимость перекомпиляции приложения при замене одного конкретного типа-сервиса. Такой подход обеспечивает высокую гибкость и позволяет создавать приложения, в полной мере отвечающие принципу слабой связанности.
Рассмотренные в данной работе подходы и структурные модели могут успешно применяться при создании систем различного назначения и уровня сложности. Использование проверенных методик, являющихся квинтэссенцией опыта ведущих мировых экспертов в области программной инженерии, позволяет создавать качественное ПО, отвечающее современным требованиям. Дальнейшее изучение и применение подобных практик является актуальной задачей для представителей российской IT-отрасли.
Литература
1. Гамма Э. [и др.]. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб: Питер, 2007. 366 с.
2. Нильссон Джимми. Применение DDD и шаблонов проектирования. Проблемно-ориентированное проектирование приложений с примерами на C# и .NET. М. : Издат. дом «Виль-ямс», 2008.
3. Крэг Ларман. Применение UML и шаблонов проектирования. М.: Издат. дом «Вильямс», 2002. 624 с.
4. Андрейчиков А.В., Андрейчикова О.Н. Анализ, синтез, планирование решений в экономике: учебник. М.: Финансы и статистика, 2004. 464 с.
5. Саати Т. Принятие решений при зависимостях и обратных связях: Аналитические сети. М.: ЛКИ, 2007.
6. Руководство по архитектуре приложений Microsoft. Microsoft Press, 2009.
УДК 004.91
СИСТЕМА ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ ПРИ ФОРМИРОВАНИИ ЭЛЕКТРОННЫХ УЧЕБНЫХ КУРСОВ
М.С. Тимченко
(Самарский государственный аэрокосмический университет им. академика С.П. Королева,
т/о@}еЬйгаА. сот)
Статья посвящена новой технологии информационной поддержки процесса создания электронных учебных курсов на основе объектной модели управления текстовыми данными.
Ключевые слова: электронный учебный курс, система обработки текста, технология объектной обработки документов.
Основным недостатком текстовых редакторов (процессоров) является низкая автоматизация процесса обработки текста. На практике при необходимости разделить большой документ на части или изменить формат некоторых его составляющих пользователь делает это вручную. К примеру, в документе с определенным количеством предложений для изменения их внешнего вида он самостоятельно выполняет некую последователь-
ность операций для каждого из составляющих документ элементов.
Для преодоления этих недостатков был предложен новый принцип обработки данных, основанный на объектной модели управления текстом. Человек, читая текст, воспринимает отдельные символы, используя пробелы, объединяет их в слова, точки воспринимает как разделители предложений, предложения обобщает в главы. Слож-
ность в оперировании машиной текстовыми блоками заключается в том, что при одинаковой логике вариантов компоновки этих блоков бесчисленное множество.
Решить эту проблему можно с помощью технологии обработки данных, оперирующей логическими единицами документа - текстовыми объектами, такими как символ, слово, предложение, абзац, глава, раздел. Одной из ее ключевых особенностей является возможность анализа списка правил, предоставляемых пользователем, в соответствии с которыми изменяется внутреннее содержание документа.
Чтобы реализовать предложенный метод, необходимо поставить и решить задачу управления многоуровневой иерархической системой данных в электронном документе.
Пусть задана модель электронного документа в формате множества символов О, которые сводятся в таблицу вида q[n, Е, Ь, Ср, VI], где п - порядковый номер элемента в системе электронного документа; Е - номер группы элементов на уровне электронного документа; Ь - уровень нахождения элемента; 1 - признак принадлежности элемента (тега) документа к одному из уровней иерархии документа, главы, абзаца, заголовка, текста; Ср -код тега, который сопоставляется с таблицей тегов; VI - параметр элемента или текстовое значение элемента.
Причем всю систему элементов электронного документа можно представить в виде системы взаимоподчиненных элементов, находящихся на различных уровнях г (рис. 1).
q1[n, Е, 1, Ср, VI] 1=1
Ог1[п, Е, 1, Ср, VI] 1=г—1
Яг[п, Е, г, Ср, VI]
1=г
Рис. 1. Многоуровневая система взаимоподчиненных элементов
Всю иерархическую систему электронного документа можно разбить на ряд двухуровневых систем. Выделим двухуровневую иерархическую систему, принадлежащую г-1 и г уровням, г-1еЯ, геЯ, и опишем механизм ее функционирования: Ог, qr-lеQr, г, г-1еЯ, 0,-1
и Ог,^ =<2г» г,г-16 к,
4,-1=1
где г - индекс номера уровня иерархического уровня системы г = 1,И; Я - множество индексов уровней системы; qг - индекс номера подсистемы г = уровня ц = 1,0Г ; Ог - множество индексов подсистем, находящихся на геЯ уровне; qг-1еQг-1 - индекс подсистемы г-1 уровня; Ог-1 -множество индексов подсистем, находящихся на г-1 уровне; эти подсистемы являются управляющими для геЯ уровня; ч ^ е Ог ч ^ - индекс
подсистемы геЯ уровня, замыкающейся на qг-1 подсистему г-1еЯ уровня; цг г ^ = 1,0Г>Ч ; , где q
является частью множества главы, абзаца, заголовка, текста; ^ - множество индексов подсистем г уровня, замыкающихся на qг_1 подсистемы.
Пусть X = {ху, 1,] = 1^} - матрица неизвестных, отображающих элементы структуры списков и краткое содержание электронных документов; X с X - вектор неизвестных, отображающий элементы структуры списков и краткое содержание электронных документов двухуровневой иерархической системы, верхняя управляющая система которой принадлежит уровню г-1еЯ и определена индексом qг_1еQг_1; X ^ е X ^ -
вектор неизвестных, отображающий элементы структуры списков и краткое содержание электронных документов двухуровневой иерархической системы уровня геЯ, замыкающейся на qг_1 е Ог-1 уровня г-1 е Я.
Для модели заданы глобальные ограничения по времени обработки информации, накладываемые на модуль управления иерархической системы электронных данных: О (X ) ^ Т, где
^ 1 (•) = 1 ¡(*),1 е Я.} - комплекс данных, расположенных на уровне г-1еЯ; Т={^, 1еЯ} - нормативы времени, определенные для анализа данных, расположенных на уровне г-1 е Я.
Векторные критерии, характеризующие эффективность работы программного комплекса обработки данных, представлены в виде набора
я*^)-{с^^=},
где К - множество индексов критериев, определяющих функционирование программного комплекса обработки данных, расположенных на уровне qг_1.
Для qг_1еQг_1 набора критериев, определяющих функционирование модели на геЯ уровне, существует замыкающееся на qг_1еQг_1 множество индексов подсистем.
Общая модель постановки задачи оптимизации, включающая в себя целевую функции и ограничения:
(ХЧ, ,4,- ) - ^ЧТ ,4,-1 (Х„ ,4,- )' к - КЧ, ,4,-1 }'
а -10 .
Данная модель относится к классу моделей многокритериальной оптимизации, где в качестве целевой функции оптимизации выступает время обработки данных с учетом ограничений на критерии функционала документа и минимальное количество критериев.
Цель каждой системы данных состоит в минимизации критериев времени их обработки, то есть возникает векторная задача многокритериальной оптимизации:
т^-!«-{Саг.«'14 ->'К.,,,-, }
где f - функция оптимизации по критерию кеК; К - множество критериев оптимизации.
Оп _ (•) < Т - функция ограничения по вре-
Чг 'Чг-1
мени (оптимизация).
X „ > 0 - необходимое минимальное ко-
Чг ' Чг-1
личество критериев.
Такие задачи выполняются на нижнем уровне иерархии. Сформулированная модель направлена на решение двух основных проблем:
1) координация управляющих воздействий при обработке взаимоподчиненных элементов, находящихся на различных уровнях иерархии;
2) выработка оптимального решения по многим показателям функционирования системы.
Для управляющего множества данных, находящихся на уровне г-1еЯ с соответствующими элементами уровня геЯ, замыкающихся на qr_1еQr_1, векторная задача примет вид
т^Чг-Д )-{{С,.«' к- 1'КЧг,Чг-1 }'Ч, - ^} , с,.« <т, сЧ,,Чг-,(-) <т, Ч,-^о;;:,
Х^,Чг-1 ^ 0 , Ч, - l'Qг,Чг-l . Модель управления многомерной иерархической системы данных представлена в виде:
тад)-{{{^(О'1 -1;кч::Ч: }'
- 1'0Г,^ } 'Ч,-1 -1,0^}', -1,»}, С(Х)<Т,
{К,*.« < т'Ч, -^о;:;} 'Ч- -^о^} > , -1»,
X;с X, - 1'0Г,^, ;,-1 - , , -1,», X £ 0.
Такая задача относится к классу многовекторных задач математического программирования (Я-векторной). Для решения поставленной задачи разработан программный комплекс, схематично представленный на рисунке 2.
Обобщенно работу комплекса можно представить в виде трех основных этапов.
1. Пользователь в текстовом виде построчно записывает правила, в соответствии с которыми будет обрабатываться электронный документ. Правила описывают загрузку исходного документа, его изменение и обратную запись на диск.
2. Запускается команда на выполнение написанных правил.
3. Система обрабатывает правила, изменяя содержимое документа.
На входе в систему поступает текст в виде файлов MS DOC, DOCX или HTML-страниц, содержащих различные элементы (таблицы, формулы, рисунки, сложные составные объекты MS Office).
На выходе - текст в виде файлов или HTML-страниц, служебные данные для быстрой навигации и поиска по обработанным массивам.
Пользователь инициирует процесс обработки правил, в ходе которого на экран выводится информация о текущем процессе обработки: количество загруженных документов, сформированные текстовые объекты, выгруженные файлы, дополнительная информация по документам.
Выводимая информация представлена в виде отчетов с автоматической группировкой по категориям. По завершении обработки пользователь продолжает работу с документами средствами сторонних производителей или встроенными средствами системы.
Результатом является полноценный электронный учебный курс, содержащий страницы ин-
Рис. 2. Блок-схема информационной технологии объектной обработки текста
формации и их список в форме древовидной структуры, возможность перемещения по содержанию, текстовый поиск, функции добавления закладок.
Литература
1. Джеф Р. Интерфейс: новые направления в проектировании компьютерных систем. СПб: Символ-Плюс, 2005.
2. Майоров А.Н. Теория и практика создания тестов для системы образования. М.: Народное образование, 2000. 352 с.
3. Портянкин И. Swing. Эффективные пользовательские интерфейсы. Библиотека программиста. СПб: Питер, 2005.
4. Ротштейн А.П., Штовба С.Д. Нечеткая надежность алгоритмических процессов. Винница: Континент-Прим, 1997. 142 с.
УДК 519.876.5
АВТОМАТИЗАЦИЯ ПРОЦЕССОВ УПРАВЛЕНИЯ СЕРВИС-ОРИЕНТИРОВАННЫМИ СИСТЕМАМИ
А.Н. Сорокин,, к.т.н.. (Вологодский государственный технический университет, arseny_sorokin@mail.ru)
Важными функциями системного управления являются анализ причин сбоев при работе системы и облегчение процесса принятия управленческих решений. В данной статье обсуждаются вопросы анализа и моделирования распределенных гетерогенных сервис-ориентированных систем. Рассматривается методика анализа таких систем, построенная на основе аппарата сетей Петри. Описывается инструментальное средство имитационного моделирования и анализируются сервис-ориентированные системы.
Ключевые слова: сервис-ориентированные системы, имитационное моделирование, сети Петри, объектно-ориентированные сети Петри.
По формальному определению специалистов корпорации IBM, сервис-ориентированная архитектура (СОА) - это прикладная архитектура, в которой все функции определены как независимые сервисы с вызываемыми интерфейсами. Обращение к этим сервисам в определенной последовательности позволяет реализовать тот или иной бизнес-процесс.
Системы, которые построены в соответствии с новейшими распределенными технологиями, - это совокупности большого числа объектов, взаимодействующих с помощью сообщений и находящихся между собой в отношениях различных типов. Поэтому особенно актуальной представляется задача моделирования и анализа сложных распределенных сервис-ориентированных систем. Опираясь на труды предшественников, автор видит путь ее решения в применении аппарата модифицированных объектно-ориентированных сетей Петри для описания механизмов взаимодействия отдельных компонентов в распределенных гетерогенных сервис-ориентированных системах.
Описание методики
Методика исследования разрабатываемой сервис-ориентированной системы заключается в следующем.
1. На основе формализованного описания предметной области строятся модели распределенной системы на уровнях статической модели, бизнес-процессов и отдельных сервисов.
На уровне статической модели описывается структура исследуемой системы: эксперт создает
структуру исследуемой распределенной сервис-ориентированной системы. На уровне бизнес-процессов определяются взаимосвязи и зависимости между отдельными сервисами. На уровне сервисов описывается сложная динамика взаимодействия сервисов, моделируется внутренняя структура отдельных сервисов.
2. Модели, построенные с использованием аппарата сетей Петри, могут быть проанализированы с помощью стандартных, а также модифицированных математических и программных средств.
3. В процессе исследования могут потребоваться уточнение и корректировка построенных моделей. После этого процесс построения и анализа моделей можно повторить.
Определим основные задачи предлагаемой методики.
1. Проверка корректности системных взаимодействий. Переход от централизованных к распределенным системам управления породил высокий параллелизм и асинхронность процессов в них. Проверка (верификация) качественной корректности предполагает анализ следующих свойств: живость (при существовании всех условий для активизации процесса), отсутствие тупиков (при взаимоблокировке нескольких процессов), ограниченность (при ограниченности каких-либо ресурсов), безопасность (устранение критических состояний системы).
2. Балансирование системы - определение узкого места, то есть компонента, имеющего наибольшую загрузку (коэффициент загрузки) и выравнивание нагрузки.
