CC BY
46
ского звена, что позволит более объективно интерпретировать полученные данные. Используя интерфейс интеллектуального блока, централизованные и обработанные данные, врач-инфекционист может в любой момент просмотреть БД, поставить окончательный диагноз и назначить курс лечения. Такая схема позволяет оперативно получать данные измерений иммуноферментного анализа, четко прослеживать историю болезни пациента. Первичное звено приемного отделения в сложных случаях или при недостаточной информации сможет оперативно воспользоваться интерпретацией данных без привлечения дополнительных источников для определения дальнейшей стратегии назначения анализов.
Для автоматизации процесса диагностики разработана программа паспортизации данных измерений иммуноферментного анализа в микропланшетном спектрофотометре с последующей передачей в систему диагностики. Интерфейс передачи данных между спектрофотометром и интеллектуальной системой разделен на три панели (рис. 3).
1. Панель управления импортом данных измерений позволяет работать с данными, поступающими с микропланшетного спектрофотометра.
2. Панель контроля значений входных данных позволяет связывать данные пациентов с номерами ячеек планшета.
3. Панель контроля целостности данных позволяет управлять данными пациентов в соответствии с их историей болезни.
В заключение можно сделать следующие выводы. Навыко-вычислительная система принятия решений в результате обучения на основе рекур-рентно-итерационного алгоритма выявляет разбросную зависимость между исходными факторами и соответствующими им решениями.
Весовые коэффициенты - навыки - формируются в результате автоматического обучения, отражают опыт и интуицию специалистов и характеризуют значимость исходных факторов.
Навыковая система диагностики «Гепатиты 1.0» принимает решения с точностью 98 %, объективно определяет влияние каждого фактора на принимаемое решение, что позволяет выявлять доминирующие и второстепенные факторы и рационально назначать анализы, учитывать совокупное влияние всех факторов, а также повысить качество и оперативность диагностики.
Литература
1. Галушкин А.И. Теория нейронных сетей. Кн. 1: Учеб. пособие для вузов; [под общ. ред. А.И. Галушкина]. М.: ИПРЖР, 2000. 416 с. (Нейрокомпьютеры и их применение).
2. Кавыгин В.В., Морозова В.П. Алгоритм естественного обучения // Всеросс. науч.-технич. конф. к 40-летию каф. ТМ ЛГТУ: сб. матер. Липецк: ЛГТУ, 2002. С. 33-37.
УДК 004.78
ПОСТРОЕНИЕ СЛАБОСВЯЗАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ ОЦЕНИВАНИЯ КАЧЕСТВА
ПРОЕКТНЫХ РЕШЕНИЙ
А.М. Веселовский
(Пензенская государственная технологическая академия, [email protected])
Рассматривается принцип слабой связанности классов программных объектов, предлагаются варианты объектно-ориентированных моделей архитектуры программного обеспечения, предназначенного для оценивания качества проектных решений.
Ключевые слова: программное обеспечение, оценивание качества проектных решений, принцип слабой связанности, объектно-ориентированные модели.
Непрерывное развитие подходов к проектированию и разработке ПО требует выработки новых типовых решений, объединяющих в себе опыт и знания ведущих специалистов отрасли и предоставляющих решение общей проблемы в рамках конкретного контекста. Подобные типовые решения принято называть шаблонами проектирования, или паттернами проектирования (англ. Design Pattern) [1]. Идея использования шаблонов стала общепринятой практикой в программной инженерии с момента широкого распространения объектно-ориентированного подхода (ООП), в связи
с чем большинство известных на сегодняшний день паттернов являются объектно-ориентированными.
В настоящее время в индустрии ПО наблюдается очередное смещение парадигм - от объектной ориентации к сервисам. Сервис-ориентированная архитектура (СОА) представляет собой модульный подход к разработке ПО, основанный на использовании сервисов (служб), обладающих автономностью, наличием явных границ, совместимостью по устанавливаемым правилам, раскрывающих схему и контракт, но не класс или тип [2].
С точки зрения стиля написания программ текущий переход от объектов к сервисам не вызывает такие фундаментальные изменения, как предыдущий коренной переход от процедур к объектам. Это можно объяснить и сравнительно небольшим временем существования СОА, и различными уровнями действия ООП и СОА. Если ООП имеет отношение к проектированию и программированию одной единицы развертывания, то СОА - к решению, состоящему из нескольких единиц. СОА определяет принципы взаимодействия сервисов, но не затрагивает их внутреннюю реализацию, поскольку они могут решаться по существующим подходам и методикам. Однако это не означает, что идеи СОА и ООП полностью изолированы друг от друга. На уровне единицы развертывания СОА смещает некоторые акценты и развивает ООП, обеспечивая возможность использования нового стиля проектирования для создания современных распределенных систем.
Одним из ключевых принципов разработки ПО применительно к распределенным системам является слабая связанность (англ. Low Coupling) [3]. Данный принцип ориентирован на минимизацию количества зависимостей между классами (подсистемами) и на достижение относительно слабых зависимостей между классами (подсистемами).
Система, спроектированная с учетом этого принципа, может легко модифицироваться, что особенно важно при построении крупных программных комплексов в условиях постоянно изменяющейся внешней среды для упрощения процессов модернизации и развития ПО.
Рассмотрим возможности применения принципа слабой связанности при построении ПО, предназначенного для оценки качества проектных решений. Под задачей оценки качества проектных решений в данной работе понимается проблема выбора оптимальной альтернативы с учетом различных критериев качества, например, выбор наилучшего места под строительство аэропорта, оптимального размещения средств охраны по периметру секретного объекта, определение наименее опасного для окружающей среды маршрута пролегания нефтепровода и множество других.
В настоящее время разработано большое количество формальных методов, предназначенных для решения многокритериальных задач, таких как метод анализа иерархий, метод аналитических сетей, методы линейной и нелинейной свертки, доминирования, последовательных уступок [4, 5]. Как правило, для достижения наивысшей степени объективности принимаемого решения (выбора оптимального варианта проекта) требуется применение нескольких методов, а также использование средств автоматизации.
Рассмотрим возможную архитектуру системы оценки качества проектов (рис. 1).
Множество функций системы распределено по трем пакетам:
• Project Quality Assessment Core - ядро системы оценки качества проектов;
• Project Repository - репозиторий проектов;
• Multi-Criteria Decision Analysis - библиотека методов решения многокритериальных задач.
Как видно из диаграммы, центральным звеном системы является класс AssessmentManager (менеджер оценки), который имеет три зависимости: класс DesignDecision (вариант проектного решения), а также классы AnalyticHierarchyProcess и AnalyticNetworkProcess, содержащие логику метода анализа иерархий и метода аналитических сетей соответственно. Данная модель является упрощенной и не отражает ряд вопросов, возникающих при реализации систем такого уровня сложности. Это сделано намеренно, чтобы вначале сконцентрироваться на проблеме связанности элементов системы в целом. Далее модель будет расширена.
При использовании этой программной модели могут возникнуть сложности в случае необходимости замены метода поиска оптимального решения, так как придется исправить все упоминания классов AnalyticHierarchyProcess или AnalyticNetworkProcess в классе AssessmentManager. Между ядром системы и библиотекой методов может появиться третья зависимость, а за ней четвертая и так далее. Кроме того, потребуется перекомпиляция ядра системы для того, чтобы изменения вступили в силу. Таким образом, подобная архитектура системы не обладает свойством слабой связанности и может привести к снижению качества программного продукта.
Чтобы уменьшить количество связей между классом AssessmentManager и классами, реализующими методы поиска решения, можно воспользоваться шаблоном Factory (Фабрика) [1]. Для этого в модель добавлен еще один уровень, содержащий вспомогательный функционал для связи ядра системы с библиотекой методов - пакет Method Infrastructure. В данный пакет следует включить класс MethodFactory и интерфейс
Рис. 1. Объектная модель подсистемы оценки качества проектов
IMethod, представляющий собой контракт, описывающий общую функциональность, которую должны реализовывать конкретные классы-методы. Классы AnalyticHierarchyProcess и AnalyticNet-workProcess связываются с интерфейсом IMethod отношением реализации (рис. 2).
Рис. 2. Использование шаблона Фабрика
В результате такого изменения модели произошло ослабление связанности ядра системы и библиотеки методов, так как взаимодействие класса AssessmentManager с наиболее изменчивой частью системы осуществляется теперь через интерфейс IMethod. Для получения экземпляра класса, реализующего интерфейс IMethod, объекту AssessmentManager необходимо обратиться к классу MethodFactory, который вернет нужный объект в зависимости от внешних условий (например,
значения в конфигурационном файле). При необходимости замены метода поиска потребуется перекомпилировать только инфраструктурный слой, а ядро системы останется неизменным.
Шаблон Фабрика позволяет изолировать изменчивую часть системы и таким образом управлять зависимостями, однако в реальных условиях зависимостей между классами может быть гораздо больше, и решение создать Фабрики для каждого уровня может оказаться неэффективным.
В рассмотренной до настоящего момента упрощенной модели системы не были освещены такие вопросы, как доступ к данным, разграничение прав доступа, журналирование событий и пр. Если доступ к данным может быть эффективно реализован в рамках единого слоя на примере классической модели архитектуры, то такие вопросы, как аутентификация и журналирование, относятся к так называемой сквозной функциональности (Crosscutting Concerns) [6], поскольку пронизывают различные слои приложения.
Рассмотрим модель системы, более приближенную к реальности, которая, кроме прочих, включает следующие пакеты:
• контракты сквозной функциональности (Crosscutting Interfaces) - пакет содержит интерфейсы компонентов, отвечающих за общие аспекты работы системы (в данном примере журнали-рование и разграничение прав доступа);
• сквозная функциональность (Crosscutting) -содержит конкретные классы, связанные с соответствующими интерфейсами из пакета Crosscutt-ing Interfaces отношением реализации;
• DI-контейнер (DI-Container) - является центральным звеном инфраструктурного слоя системы, обеспечивающим связь остальных компонентов между собой (рис. 3).
Рис. 3. Применение шаблона Внедрение зависимости
В данном варианте в пакет Project Repository добавлены интерфейс IRepository и два конкретных типа 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
СИСТЕМА ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ ПРИ ФОРМИРОВАНИИ ЭЛЕКТРОННЫХ УЧЕБНЫХ КУРСОВ
М.С. Тимченко
(Самарский государственный аэрокосмический университет им. академика С.П. Королева,
т/о@}еЬйгаА. сот)
Статья посвящена новой технологии информационной поддержки процесса создания электронных учебных курсов на основе объектной модели управления текстовыми данными.
Ключевые слова: электронный учебный курс, система обработки текста, технология объектной обработки документов.
Основным недостатком текстовых редакторов (процессоров) является низкая автоматизация процесса обработки текста. На практике при необходимости разделить большой документ на части или изменить формат некоторых его составляющих пользователь делает это вручную. К примеру, в документе с определенным количеством предложений для изменения их внешнего вида он самостоятельно выполняет некую последователь-
ность операций для каждого из составляющих документ элементов.
Для преодоления этих недостатков был предложен новый принцип обработки данных, основанный на объектной модели управления текстом. Человек, читая текст, воспринимает отдельные символы, используя пробелы, объединяет их в слова, точки воспринимает как разделители предложений, предложения обобщает в главы. Слож-
