Software & Systems

Предметно-ориентированное проектирование (domain-driven design, DDD) – одна из основных методологий разработки сложных программных систем [1]. Его ключевым аспектом является разработка архитектуры программных объектов на основе модели предметной области, то есть разработка совокупности взаимосвязанных програм- мных объектов, описывающих различные стороны определенной области применения системы (области бизнеса). Объекты домена позволяют реализовать (имитировать) сущности области применения системы и формализовать бизнес-правила, реализуемые ею. Использование модели предметной области является типовым решением, позволяющим упростить реализацию сложной бизнес-логики программной системы, которая характеризуется множеством объектов, правил, условий использования и особенностей поведения [2].

При проектировании ПО сложных АСУ, как правило, используются основные архитектурные шаблоны корпоративных программных приложений [2]. В соответствии с концепцией слоев (layers, [2]) ПО в общем случае разделяется на три слоя: представление, предметная область и источник данных.

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

Как правило, модель предметной области содержит ряд общесистемных объектов, составляющих ее ядро. Например, в АСУ техническим обеспечением (ТехО) ВМФ в состав общесистемных объектов входят элементы организационно-штатной структуры обеспечиваемых подразделений, типы и экземпляры материально-технических средств, виды технического обеспечения и т.д. Нередко общесистемные объекты составляют основу информационно-лингвистического обеспечения системы, входят в состав рубрикаторов, классификаторов и справочников, используются при разработке протоколов информационного взаимодействия АСУ с другими системами.

В ходе проектирования архитектуры специального ПО (СПО) АСУ по модели предметной области (Model-Driven Design, [1]) определяется набор программ (программных компонентов), каждая из которых реализует часть модели. При этом используются классические паттерны GRASP [3] с целью обеспечения максимального зацепления и минимальной связности между программами. В итоге СПО АСУ состоит из обладающих высоким зацеплением слабосвязанных программ, реализующих части модели предметной области. Компоненты СПО выполняют свои функции, управляя состоянием объектов ядра либо других програм- мных объектов, реализующих отношения с ними. Такими отношениями являются зависимости, обобщения и ассоциации [4]. Реализация компонентами СПО разных частей модели предметной области приводит к тому, что функционал системы выстраивается вокруг общесистемных объектов. Например, разработка разного рода планов выполняется компонентом планирования, формирование выходных отчетов и формализованных документов – программой формирования отчетов, нормативная и справочная информация – программой ведения нормативно-справочной информации и т.д. (рис. 1).

На завершающем этапе разработки АСУ в результате произошедших изменений организационно-штатной структуры автоматизируемых объектов и бизнес-процессов, выполняемых должностными лицами, возникла задача предоставления группе пользователей централизованного доступа ко всей информации по общесистемным объектам. Отсутствие централизованного доступа приводило к тому, что пользователям системы приходилось многократно переключаться между разными программами для сбора всей необходимой информации по одним и тем же общесистемным объектам и для доступа к требуемым функциям (методам) ее обработки. Фактически требовалось обеспечить адаптируемость АСУ к подобным изменениям условий ее применения.

Реализация централизованного доступа к информации об общесистемных объектах должна была исключить необходимость переключения между программами СПО АСУ при сборе определенной информации. Имеющаяся архитектура СПО не позволяла предоставлять централизованный доступ ко всей необходимой информации – пользователю приходилось одновременно запускать несколько программ и переключаться между ними.

Список функций, выполняемых компонентами СПО, может быть сформирован управляющей программой автоматически путем опроса компонентов в момент начальной инициализации. При его проведении компоненты СПО сообщают управляющей программе перечень выполняемых ими функций применительно к типам (классам) и конкретным экземплярам общесистемных объектов. Взаимодействие с управляющей программой можно возложить на фасады компонентов СПО. Фасад является типовым решением, позволяющим упростить вызов функций, реализуемых различными компонентами (Facade [6]). Его применение позволяет скрыть сложность компонентов СПО путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам компонента.

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

Реестр функций можно представить, например, в виде таблицы, в которой классы общесистемных объектов сопоставлены с функциями, выполняемыми компонентами СПО.

Помимо централизованного доступа к функционалу системы, сформированное информационно-функциональное пространство может быть использовано для контекстной группировки методов (функций) обработки информации. Управляющая программа может предоставлять доступ только к тому функционалу, который напрямую связан с классом обрабатываемого в данный момент общесистемного объекта. При этом для пользователя системы останется прозрачным состав компонентов СПО, реализующих требуемые функции. Пользователю не придется переключаться между разными программами, реализующими требуемые ему функции. Контекстный объект может быть задан пользователем при помощи средств графического интерфейса программы, например, посредством выделения строки таблицы или вершины дерева, связанной с тем или иным общесистемным объектом. «Выстраивание» функционала системы вокруг общесистемного объекта позволяет собирать всю доступную в системе информацию о нем (информационный срез) без применения поисковых систем.

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

В соответствии с подходом к оценке зацепления и связности [7] понизить связность можно с помощью разработки дополнительных абстракций в виде абстрактных программных классов-интер­фейсов, например «Регистратор» и «Компонент» (рис. 3).

Управляющая программа реализует интерфейс «Регистратор», фасады компонентов СПО – интерфейс «Компонент». Реализация фасадами интерфейсов по взаимодействию с управляющей программой в общем случае позволит минимизировать повышение связности компонентов СПО. Фасады компонентов абстрагированы от технической реализации управляющей программы, с одной стороны, и управляющая программа от реализации фасадов – с другой.

Введение метода mreg регистрации функций компонента в его фасад приводит к тому, что для каждого класса общесистемного объекта, используемого методами какого-либо фасада, будет существовать пара пересекающихся множеств {Ii, Ij}: (\"eÎEi)½$(Ii, Ij)½(IiÇIj)¹0.

При этом количество таких пар будет равно числу методов, реализуемых фасадом: ½Ii, Ij½= =½Mj½.

Таким образом, получается, что величина ½Qi½ уменьшается на значение ½Mj½. Следовательно, реализация методов регистрации функционала компонентов в фасадах не приводит к снижению их зацепления.

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

Такой подход к реализации централизованного доступа к функционалу системы был применен при разработке АСУ ТехО ВМФ, в состав технологической платформы которой входит управляющая программа «менеджер доменов», выполняющая типовые технологические функции, а также анализирующая конфигурацию установленного СПО.

Менеджер доменов позволяет регистрировать функции, выполняемые программами СПО, и предоставлять оператору (пользователю программы) централизованный доступ к ним. В состав фасадов компонентов СПО АСУ были добавлены специальные методы, реализующие взаимодействие с менеджером доменов и предоставляющие сведения о собственных методах обработки общесистемных объектов. В результате взаимодействия доработанных фасадов компонентов СПО АСУ с менеджером доменов удалось сформировать единое информационно-функциональное пространство, использованное для обеспечения функционирования информационного портала. Таким образом, была реализована адаптируемость АСУ ТехО ВМФ к новым условиям применения без изменения архитектуры СПО.

На основании изложенного можно сделать следующие выводы.

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

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

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

Литература

1.     Эванс Э. Предметно-ориентированное проектирование. Структуризация сложных программных систем. М.: Вильямс, 2011.

2.     Фаулер М., Райс Д., Фоммел М., Хайет Э., Ми Р., Стаффорд Р. Архитектура корпоративных программных приложений. М.: Вильямс, 2006.

3.     Ларман К. Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку. М.: Вильямс, 2013.

4.     Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. М.: ЯМК Пресс; СПб: Питер, 2004.

5.     Купер А., Рейман Р., Кронин Д. Об интерфейсе. Основы проектирования взаимодействия. СПб: Символ-Плюс, 2009.

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

7.     Hitz M., Montazeri B., Measuring Coupling and Cohesion In Object-Oriented Systems, Proc. Int. Sympos. on Applied Corporate Computing (Oct. 25–27), Monterrey, Mexico, 1995.

References

1.  Evans E., Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003.

2.  Fowler M., Rice D., Foemmel M., Hieatt D., Me R., Staf-ford R.,  Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.

3.   Larman C.,  Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design and Iterative Development, Prentice Hall, 2005.

4.  Booch G., Rumbaugh J., Jacobson I.,  The Unified Model-ing Language. User Guide, Addison-Wesley, 2005

5.  Cooper A., Reimann R., Cronin D., About Face 3. The Es-sentials of Interaction Design, Wiley Publ., 2007.

6.  Gamma E., Helm R., Johnson R., Vlissides J., Design Pat-terns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.

7.  Hitz M., Montazeri B., Proc. Int. Symp. on Applied Corpo-rate Computing, Monterrey, Mexico, Okt., 1995.