Software & Systems

Изменение требований пользователя всегда является головной болью для разработчика программных систем, особенно если оно возникает на последней стадии проекта.

Одним из наиболее важных решений обозначенной проблемы может являться необходимость ²изменчивой² предметной области пользователя уже на этапе проектирования. Идея решения состоит в том, чтобы механизм реагирования на изменения требований к программной системе был заложен в сам проект, что позволит в дальнейшем выпускать новые версии без задержек со стороны разработчика.

Указанного результата мы можем достичь, если предоставим пользователю средства и способы самостоятельного изменения и расширения функциональных возможностей используемой им программной системы. Основой такого средства является открытая программная система, под которой понимается архитектурное и техническое решение, позволяющее модифицировать программу для расширения или изменения ее функциональных возможностей без вмешательства в ее исходный код. Открытые программные системы делятся на следующие классы: программированные управляющие алгоритмы; взаимозаменяемые модули; интерфейс программирования.

В общем случае открытая система состоит из двух базовых частей – ядра и внешних компонент. Ядро системы инкапсулирует сервисы предметной области и предоставляет средства функционирования для внешних модулей, решающих конкретную задачу предметной области.

В зависимости от класса открытой системы взаимоотношение частей будет складываться по-разному.

Программированные управляющие алгоритмы предполагают, что компоненты создаются на языке программирования высокого уровня, который содержит конструкции и сервисы, ориентированные на предметную область пользователя.

Таким языком не обязательно должен являться традиционный язык программирования, похожий на С++, Java или Pascal. В каждой предметной области есть свои выразительные средства, которые могут быть использованы для описания процессов, в них происходящих. Задача проектировщика состоит в том, чтобы найти эти средства и применить их в создаваемой программной системе.

Взаимозаменяемые модули предполагают, что внешний компонент выполняет низкоуровневые задачи, например взаимодействие с определенной системой аутентификации пользователя. Таким образом, при выборе другой системы аутентификации достаточно просто будет заменить компонент.

Интерфейс программирования похож на программированные управляющие алгоритмы, с той лишь разницей, что модули создаются теми же средствами, что и ядро открытой программной системы.

Однако проектирование открытых программных систем сопряжено с рядом трудностей, и прежде всего это касается проектирования сервисов предметной области. Понятие сервиса основано на понятии управляющего алгоритма, формальная модель которого описана в [4]. Здесь мы лишь определим, что управляющим является алгоритм, создаваемый пользователем открытой программной системы на основе определения последовательности взаимодействия с сервисами предметной области, необходимой для решения конкретных задач пользователя.

Проектирование сервисов может быть выполнено на основе прецедентной модели компании IBM [3] или с использованием других подходов [1].

Одним из важных этапов прецедентной модели проектирования является формализация функциональных требований путем построения диаграммы прецедентов. Именно здесь впервые и становится возможным выбрать архитектурное решение ²открытая программная система². На основании чего принимается такое решение? Во-первых, возможна ли детализация крупных прецедентов в нескольких вариантах либо их количество неопределенно, а во-вторых, может ли один и тот же прецедент быть выполнен по разным алгоритмам в зависимости от обстоятельств либо количество таких алгоритмов заранее определить невозможно. Будем называть такие прецеденты открытыми и обозначать их на диаграммах UML со стереотипом <> (см. рис.).

На рисунке показан фрагмент диаграммы прецедентов некоторой информационной системы для обслуживания торгового склада. Если реализация таких прецедентов, как ²Регистрация в системе², ²Прием товара² и ²Отпуск товара² не требуют каких-либо изменений в дальнейшем, то этого же нельзя сказать о ²формировании отчетов², так как отчеты могут быть самые разнообразные и определяться конкретным пользователем программной системы.

Таким образом, вполне логично принять решение об использовании архитектурного решения "открытая программная система², но при этом возникает необходимость проектирования сервисов предметной области и реализации открытого прецедента.

На первом этапе проектирования сервисов предметных областей необходимо выполнить их идентификацию. Для этого автор рекомендует придерживаться следующей последовательности действий.

1.    Определите, какие бизнес-сущности используются для реализации открытых прецедентов. Для каждой бизнес-сущности необходимы сервисы, связанные с поиском конкретного объекта в базе данных, изменения свойств объекта, сортировки и т.д.

2.    Определите, есть ли необходимость при реализации открытого прецедента отображения какого-либо интерфейса пользователя. Будут ли это какие-то стандартные диалоги для данной предметной области или требуется динамическое конструирование, например, редактор свойств объекта для его визуальной настройки. Для каждой панели диалога или динамически создаваемых окон создайте отдельные сервисы, которые будут реализованы в ядре.

3.    Определите, есть ли необходимость при реализации открытого прецедента доступа к сервисам операционной системы. Для каждого требуемого сервиса операционной системы создайте высокоуровневую обертку (wrapper), которая будет реализована ядром программной системы.

4.    Определите перечень событий, которыми инициируется выполнение прецедента. Каждый модуль, реализующий прецедент, будет иметь реализацию обработчиков этих событий. Обратите внимание на необходимость добавления специальных событий – загрузка компонента, реализующего открытый прецедент, и его завершение.

5.    Определите целесообразность сохранения настроек компонент, реализующих открытые прецеденты. Если это необходимо, то добавьте к списку событий еще сохранение настроек и восстановление. Сама технология сохранения настроек и их восстановления может быть реализована на основе механизма сериализации, что является стандартом.

На втором этапе необходимо определить интерфейсы ядра программной системы и модулей, реализующих открытые прецеденты. Для этого рекомендуется придерживаться следующего алгоритма.

1)  Из перечня идентифицированных сервисов составьте интерфейс ядра открытой программной системы. Этот интерфейс должен быть известен всем компонентам, отвечающим за реализацию открытых прецедентов.

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

На третьем этапе необходимо выбрать одну из технологий реализации открытых программных систем, учитывая следующие критерии.

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

·      Взаимозаменяемые модули следует выбирать, если при реализации открытого прецедента нет необходимости в использовании сервисов предметной области либо эти сервисы предоставляются внешней системой, например конкретной СУБД.

·        Интерфейс программирования следует выбирать, если разрабатывать отдельный язык описания алгоритмов нет необходимости или же это сильно удорожает проект, ведет к увеличению сроков его реализации, либо заказчик имеет возможность своими силами создавать компоненты, реализующие открытые прецеденты в рамках технологии, по которой будет создана программная система.

Предлагаемый подход был успешно апробирован в ряде коммерческих и некоммерческих проектов, что доказывает его эффективность, предоставляя разработчику полноценную методику проектирования программ, основанных на архитектурном решении ²открытая программная система².

Список литературы

1.     Бондаренко М.Ф., Маторин С.И., Соловьева Е.А. Моделирование и проектирование бизнес-систем: методы, стандарты, технологии: Учебное пособие. – Харьков: Компания СМИТ, 2004.

2.     Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – СПб.: Питер, 2001.

3.     Кратчен Ф. Введение в Rational Unified Process. 2-е изд. / Пер. с англ. – М.: Издат. дом «Вильямс», 2002.

4.     Системы управления, информационные и измерительные технологии, радиоэлектроника: Тематич. сб. науч. тр. / Отв. ред. Л.С. Казаринов. – Челябинск: Изд.-во. ЮУрГУ, 2005.

5.     Цытович П.Л. Структурные модели программных систем // Компьютеры+Программы. – 2004. – №11. – С.44-48.