12.2. Семейства приложений

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

Существуют различные специализации семейств приложений, приведем некоторые из них.

1. Платформенная специализация, при которой для разных платформ разрабатываются свои версии приложения. Например, приложение может иметь версии для платформ Windows NT, Solaris или Linux. В данном случае функциональность приложения обычно не меняется; подвергаются изменениям только те компоненты, которые отвечают за взаимодействие с аппаратными средствами и операционной системой.

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

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

Чтобы наглядно представить эту технологию повторного использования, рассмотрим архитектуру системы управления ресурсами, изображенную на рис. 12.7. Подобные системы используются в организациях для отслеживания активов (ресурсов, запасов) и управления ими. Например, система управления ресурсами энергосистемы должна отслеживать все стационарные энергообъекты и соответствующее оборудование. В университетах система управления ресурсами может отслеживать оборудование, используемое в учебных лабораториях.

Рис. 12.7. Обобщенная система управления ресурсами

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

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

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

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

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

Рис. 12.8. Библиотечная система

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

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

Обобщенный процесс создания нового приложения состоит из следующих этапов:

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

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

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

4. Адаптация выбранной системы. Для системы разрабатываются новые модули, а существующие адаптируются к новым требованиям.

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

Рис. 12.9. Процесс разработки нового члена семейства приложений

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

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