Всемогущие коллеги

Всемогущие коллеги (перевод англ. Colleagues almighty по аналогии с названием фильма Bruce Almighty) - статья опубликованная в сборнике работ «Научная мысль кавказа».

В сборнике статья называется «Разработка унифицированной архитектуры построения расширяемого программного обеспечения»

Современные измерительные системы, состоящие из аппаратной и программной частей способны решать множество задач. Однако, в силу своей многофункциональности и универсальности, программные части таких систем необходимо часто дорабатывать (улучшать старую и добавлять новую функциональность). Давно известно, что монолитные, то есть состоящие из одного исполнимого файла, программы не самое лучшее решение для создания сложных и больших программных систем, функциональность которых часто дополняется. Даже для небольшой модификации необходима перекомпиляция всей программы, её переустановка, что создает большие и часто непреодолимые трудности. Решение описанных проблем давно найдено. Оно заключается в разделении монолитного исполняемого файла на части, так называемые подключаемые модули или плагины. Развитой поддержкой плагинов обладают такие популярные программные продукты как Microsoft Outlook, Eclipse, Firefox. Таким образом, сомневаться в необходимости разделения не приходится. В данной статье исследуется не сама необходимость создания систем основанных на плагинах, а то, как эту поддержку организовать. Распространенным[1] подходом к созданию таких систем является определение некого фиксированного интерфейса для плагинов плюс создание некой подсистемы для загрузки плагинов. Все плагины в такой системе должны обязательно поддерживать этот заранее определенный интерфейс. Это требование и есть основной недостаток, так как разработчику системы необходимо определить интерфейс для плагинов, которые будут написаны в будущем, то есть в общем случае неизвестно для чего. Понятно, что сделать это невозможно, поэтому разработчикам приходится вводить поддержку плагинов для определенных частей программы. Отсюда следует, что если разработчик текстового редактора, создавая программу, добавил возможность создавать плагины для сохранения файлов в разные форматы, то дополнить программу новыми способами форматирования текста вы не сможете. Даже если в программе будет такая возможность, она будет недоступна извне. В настоящей работе поставлена и решена задача разработки архитектурного решения, позволяющего создавать программы, в которых заложено новое свойство – создавать плагины не ограниченные фиксированным интерфейсом. Кроме разработки самой архитектуры, пред авторами стояла задача её базовой реализации, то есть создание каркаса(framework)[2] приложений. Мудрый архитектор редко использует самодельные архитектуры, в большинстве случаев он использует и комбинирует разработанные и многократно проверенные в деле заготовки, созданные другими архитекторами. Такие заготовки называются паттерны[2,3]. Рассмотрим два широко известных паттерна: «медиатор» и «команда»[3]. Паттерн медиатор определяет объект, инкапсулирующий способ взаимодействия множества объектов. Медиатор обеспечивает слабую связанность системы[2], избавляя объек¬ты от необходимости явно ссылаться друг на друга и, позволяя тем самым незави¬симо, изменять взаимодействия между ними. Диаграмма классов[4] этого паттерна представлена на рисунке 1.

Рисунок 1 – паттерн «медиатор» на диаграмме классов IMediator – интерфейс для обмена информацией с объектами TColleague. TConcreteMediator – реализует кооперативное поведение, координируя действия объектов TColleague. TColleague – общий предок коллег. TConcreteColleague – конкретный потомок класса TColleague.

Свойство этого паттерна избавлять объек¬ты от необходимости явно ссылаться друг на друга, делает его отличным кандидатом на роль менеджера плагинов, ведь плагины с одной стороны не должны ничего знать друг о друге (их разрабатывают разные люди в разное время, знать о других плагинах разработчики часто не могут физически), а с другой стороны они должны взаимодействовать между собой. Паттерн команда инкапсулирует запрос как объект, позволяя тем самым задавать параметры клиентов для обработки соответствующих запросов, ставить запросы в очередь или протоколировать их, а также поддерживать отмену операций, рисунок 2.

Рисунок 2 – паттерн «команда» на диаграмме классов TCommand – объявляет интерфейс для выполнения операции. TConcreteCommand – определяет связь между объектом-получателем TReceiver и действием. TReceiver – располагает информацией о способах выполнения операций, необходимых для удовлетворения запроса.

Этот паттерн удобно использовать для организации взаимодействия между плагинами, так как заранее предугадать какие именно запросы и с какими параметрами будут передаваться плагинами невозможно, а использование паттерна команда освобождает систему от такой необходимости. В Интернете есть несколько примеров[5] организации программных систем на основе выше описанных паттернов, идеи которых были использованы при разработке данной системы. Так как для реализации каркаса был использован язык Delphi и среда разработки BDS2006[6], то для физического разделения системы были использованы bpl пакеты[7]. Однако использование пакетов – это не обязательное, а лишь одно из возможных в данной архитектуре решений. Так как в данной архитектуре используется паттерн медиатор, а объекты, взаимодействующие через медиатор называются коллеги[3], то было решено называть плагины в системах созданных на основе данного каркаса «коллегами», чтобы подчеркнуть ту универсальность, которую получает разработчик коллег. Ядро всего каркаса, который получил название MediatorProject[8], составляет всего один bpl пакет. В нем находятся три необходимых для работы класса. Первый – синглетон[3] TSystemMediator. Это медиатор, который содержит в себе список подключенных к нему коллег, методы для их подключения и отключения, а так же метод для передачи команд от одного коллеги к другому. Второй – общий для всех коллег предок TCustomColleague, в конструкторе которого выполняется подключение к медиатору. И третий – TCustomCommand предок для всех классов команд. В этом классе содержаться методы необходимые для работы с командами. Выше описанные классы представлены на диаграмме классов рисунок 3.

Рисунок 3 – ядро каркаса MediatorProject TCustomColleague – общий предок всех коллег. TCustomCommand – общий предок команд. TSystemMediator – класс-синглетон, выступающий в роли медиатора. TColleaguesList – класс, реализующий список коллег.

Взаимодействие в системе построенной на основе описанного каркаса происходит следующим образом. В любой момент времени один из коллег инициирует взаимодействие, посылая медиатору одну из доступных команд. Медиатор отсылает эту команду всем известным ему коллегам. Каждый коллега, получив команду, сам решает каким образом её обработать. Если коллега может обработать команду, то он либо посылает новую команду, либо модифицирует полученную. За корректным освобождением памяти следит сам медиатор. Эта схема «общения» показана на диаграмме взаимодействия[4], рисунок 4.

Рисунок 4 – взаимодействие коллег через медиатор на диаграмме последовательности

В каркас так же включен необязательный в данной архитектуре, но упрощающий создание программ, пакет с классом TPluginLoader, который при загрузке ищет и загружает коллег. В довершении ко всему каркас был оснащен базовыми коллегами для работы с настройкам, и для протоколирования операций, а медиатор дополнен возможностями отложенной доставки команд. Создать приложение на основе описанного каркаса очень просто, для этого надо скопировать пакет с медиатором и базовыми классами для коллег и команд. Скопировать пакет с загрузчиком коллег или реализовать его самостоятельно. Создать модуль для конкретных команд. После этого можно приступать к созданию конкретных коллег, которые и будут реализовывать требуемую функциональность. Типичная структура проекта на основе каркаса MediatorProject, показана на рисунке 5.

Рисунок 5 – структура проекта, основанного на каркасе MediatorProject

Таким образом, разработанная архитектура, и реализованный на её основе каркас, о которых говорится в данной статье, годятся для создания программных систем любой сложности. Они были применены на практике для создания целой серии различных систем. Ода из них – это программная часть комплекса FreGraf[9]. Комплекс FreGraf предназначен для измерения параметров пьезопреобразователей и пьезоэлементов. Благодаря тому, что для создания этого программного продукта был использован описанный каркас, уже через пол года, после запуска системы в эксплуатацию она была расширена коллегой для проведения автоматических (не требующих присутствия оператора) измерений, хотя изначально такая возможность не планировалась. На рисунке 6 представлено главное окно программы и окна двух запущенных коллег.

Рисунок 6 – главное окно программы KFreGraf и окна двух запушенных коллег

Каркас MediatorProject доступен для использования всеми желающими. Сам каркас, а также обучающие материалы по его применению можно получить на странице проекта: http://www.ksoftware.ru/MediatorProject/

1. http://www.excode.ru/art802p2.html Подгружаемые модули.

2. Применение UML 2.0 и шаблонов проектирования. Крэг Ларман. 736 стр., с ил.; ISBN 978-5-8459-1185-8, 0-13-148906-2.

3. Приемы объектно-ориентированного проектирования. Паттерны проектирования. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. СПб: Питер, 2001. — 368 с.: ил. ISBN 5-272-00355-1.

4. UML. Основы (2-е издание). Фаулер М., Скотт К. ISBN: 5-93286-032-4.

5. http://rsdn.ru/article/patterns/patterns.xml Практика применения паттернов проектирования.

6. http://www.codegear.com/

7. Delphi 5. Руководство разработчика. Стив Тейксейра, Ксавье Пачеко. 832 стр., с ил.; ISBN 5-8459-0066-2, 0-672-31781-8; формат 70х100/16; серия Руководство разработчика; 2000, 2 кв.; Вильямс.

8. http://www.ksoftware.ru/MediatorProject/

9. http://www.ksoftware.ru/KFreGraf/, http://www.ksoftware.ru/projects/Device/KFreGraf3.html