Software & Systems

Непрерывное развитие подходов к проектированию и разработке ПО требует выработки новых типовых решений, объединяющих в себе опыт и знания ведущих специалистов отрасли и предоставляющих решение общей проблемы в рамках конкретного контекста. Подобные типовые решения принято называть шаблонами проектирования, или паттернами проектирования (англ. 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 или AnalyticNet­workProcess в классе AssessmentManager. Между ядром системы и библиотекой методов может появиться третья зависимость, а за ней четвертая и так далее. Кроме того, потребуется перекомпиляция ядра системы для того, чтобы изменения вступили в силу. Таким образом, подобная архитектура системы не обладает свойством слабой связанности и может привести к снижению качества программного продукта.

Чтобы уменьшить количество связей между классом AssessmentManager и классами, реализующими методы поиска решения, можно воспользоваться шаблоном Factory (Фабрика) [1]. Для этого в модель добавлен еще один уровень, содержащий вспомогательный функционал для связи ядра системы с библиотекой методов – пакет Method Infrastructure. В данный пакет следует включить класс MethodFactory и интерфейс IMethod, представляющий собой контракт, описывающий общую функциональность, которую должны реализовывать конкретные классы-мето­ды. Классы AnalyticHierarchyProcess и AnalyticNet­workProcess связываются с интерфейсом IMethod отношением реализации (рис. 2).

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

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

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

Рассмотрим модель системы, более приближенную к реальности, которая, кроме прочих, включает следующие пакеты:

·     контракты сквозной функциональности (Crosscutting Interfaces) – пакет содержит интерфейсы компонентов, отвечающих за общие аспекты работы системы (в данном примере журналирование и разграничение прав доступа);

·     сквозная функциональность (Crosscutting) –содержит конкретные классы, связанные с соответствующими интерфейсами из пакета Crosscutt­ing Interfaces отношением реализации;

·     DI-контейнер (DI-Container) – является центральным звеном инфраструктурного слоя системы, обеспечивающим связь остальных компонентов между собой (рис. 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.