Главная | Обратная связь | Поможем написать вашу работу!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проектные паттерны

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

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

Проектные паттерны (design patterns) [124] появились из идей, выдвинутых Кристофером Александером (Alexander, [8]), который предложил удобные и эффективные обобщенные паттерны разработки конкретных проектов. Паттерн – это описание проблемы и метода ее решения, позволяющее в дальнейшем использовать это решение в разных условиях. Паттерн не является детальной спецификацией. Скорее, он представляет собой описание, в котором аккумулированы знания и опыт. Паттерн – гарантированное решение общей проблемы.

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

В [124] определены четыре основных элемента проектного паттерна.

1. Содержательное имя, которое является ссылкой на паттерн.

2. Описание проблемной области с перечислением всех ситуаций, в которых можно использовать паттерн.

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

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

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

В качестве примера рассмотрим один из наиболее часто используемых паттернов, предложенных в работе [124], а именно Обозреватель (Observer) (см. врезку 14.1). Данный паттерн используется тогда, когда необходимы разные представления состояния объекта. Он выделяет нужный объект и представляет его в разных формах; на рис. 14.10 показаны два графических представления одного и того же набора данных.

Рис. 14.10. Различные представления данных

⇐ Предыдущая 97 98 99 100 101102103 104 105 106 Следующая ⇒