И. Соммервилл - Инженерия программного обеспечения (1133538), страница 74
Текст из файла (страница 74)
Многие компании, например Нек!егг-Рас!гаЫ, успешно применлют повторное использование в своих разработках [139). Опыт этой компании представлен в фундаментальной книге [187). Успешное использование компонентов в приложениях Ч1зна! Вавка Ч!апа! С++ и )ага продемонстрировало важность повторного использования.
Разработка ПО, основанная на повторном использовании компонентов, становится широко распространенным рентабельным подходом к разработке программных продуктов [331, 3э). Вместе с тем подходу к разработке ПО с повторным использованием компонентов присущ рад недостатков и проблем (табл. 14.2), которые препятствуют запланированному сокращению расходов на разработку проекта.
14. Проектирование с повторным использованием компонентов 287 Альтернативой повторному использованию программных компонентов является применение программных генераторов. Согласно этому подходу информация, необходимая для повторного использования, записывается в систему генератора программ с учстоы знаний о той предметной области, где будет эксплуатироваться разрабатываемая система. В данном случае в системной спецификации должно быть точно указано, какие именно компоненты выбраны для повторного использования, а также описаны их интерфейсы и то, как они должны компоноваться.
На основе такой информации генерируется система ПО (рис. 14.1). )лис. 14.1. Генфироооиие и рог)гамм Повторное использование, основанное на генераторах программ. возможно только тагла, когда можно идентифицировать предметные абстракции и их отображение в испалняеллый код. Поэтоллу для компоновки и управления предллетными абстракциями используются, как правило, проблемно-зависимые языки (напрпмер. языки четвертого поколения). Вот предлгстиые области, в которых применение такого подхода может быть успешным.
1. Гегге)гооло)гы и)гиложеггий ды ой)гоооогки экоиаиичесхих доиимх. На входе генератора— описание приложения на языке четвертого поколения или диалоговая система, где пользователь определяет экранные форллы и способы обработки данных. На выходе — программа на каком-либо языке програлгмироваыия, например СОВО1.
или БО! .. 2. Геке)гоогоры п)гогромлг синоюкпгческого оиолиэооггро. На входе генератора — грамматическое описание языка, на выходе — программа грамматического разбора языковых конструкций. 3. Геке)эо игори кодов САБЕч)гедетв. На входе генераторов — архитектура ПО, а иа выхо- де — программная реализация проектируемой системы. Разработка ПО с использованном программных генераторов экономически выголиа, однако существенно зависит от полноты и корректности определения абстракций предметной области.
Данный паллад лгажно широко использовать в перечисленных выше предметньш областях н в меньшей степени при разработке систем управления и контроля (261). Главное преимущество этого подхода состоит в относительной легкости разработки программ с помощью генераторов.
Однако необходимость глубокого понимания предметной области и ее моделей ограничивает применимость данного метода. 14.1. Покомнонентная разработка Метод покомпонентной разработки ПО с повторным использованием компонентов появлися в конце 1990-х гадов как альтернатива обьектно.ориентированному подходу 288 'Часть Ш. Проектирование 1. Компонент — это независимо выполняемый программный объект. Исходный код компонента может быть недоступен, поэтому такой компонент не компилируется совместно с другими компонентами системы. 2.
Компоненты объявляют свой интерфейс и все взаимодействия с ними осуществляются с его помощью. Интерфейс компонента описывается в терминах параметризованных операций, а внутреннее состояние компонента всегда скрыто. Компоненты определяются через свои интерфейсы. В болыпинстве случаев компоненты можно описать в виде двух взаимосвязанных интерфейсов, как показано на рис. 14.2. ° Ииоеерфейе иоеоиыейиха сервисов, который определяет сервисы, предоставляемые компонентом. ° Ииоирфееи зоироеое, который определяет, какие сервисы доступны компоненту из сисгемы, использующей этот компонент. Интерфейс зв нтврфвйс еютывввн сервисов Рис !4.2. Иитмуефйиы хаияоиеито В качестве примера рассмотрим компонент (рис.
14ЗК который предоставляет сервисы вывода документов на печать. В нашем примере поддерживаются следующие сервисы: печать документов, просмотр состояния очереди на конкретном принтере, регистрация и удаление принтеров из системы, передача документа с одного принтера на другой и удаление документа из очереди на печать.
Очень важно, чтобы компьютернал платформа, на кразработке систем, который не привел к повсеместному повторному использованию программных компонентов, как предполагалось изначально. Отдельные классы объектов оказались слишком детализированными и специфическими: их требовалось связывать с приложением либо во время компиляции, либо при компоновке системы.
Использование классов обычно предполагает наличие детальных данных о классах, что делает доступным исходный код, ио для коммерческих продуктов исходный код открыт очень редко. Несмотря па ранние оптимистические прогнозы, значительное развитие рынка отдельных программных объектов и компонентов так и не состоялось. Компоненты более абстрактны, чем классы объектов. Поэтому их можно считать независимыми поставщиками сервисов. Если система запрашивает какой-либо сервис, вызывается компонент, предоставляющий этот сервис независимо от того, где выполняется компонент и иа каком языке написан. Примером простейшего компонента может быть отдельная математическая функция, вычисляющая, например, квадратный корень числа. Для вычисления квадратного корня программа вызывает компонент, который может выполнить данное вычисление.
На другом конце масштабной линейки компонентов находятгя системы, которые предоставляют полный вычислительный сервис. Взгляд на компонент как на поставщика сервисов определяется двумя основными ха. рактеригтиками компонентов, допускающими их повторное использование. 14. Проектирование с повторным использованием компонентов 289 которой исполняется компонент, предоставляла сервис (назовем его ФайпОпПринтер), позволяющий извлечь файл описания принтера, и сервис КомПринтер, передающий команды на конкретный принтер. рфэйс яостазввм севВисвв Рис. 14.У.
Коииоигит глужбм иоиоти Компоненты мокнут существовать на разных уровнях абстракции — от простой библио. течной подпрограммы до целых пргиожсний, таких как М!сгоэой Ехсе!. В работе [228) определено пять уровней абстракции компонентов. 1. Функциональная аЫлракиил. Компонент реализует отдельную функцию, например математическую. В сущности, интерфейсом поставщика сервисов здесь является сама функция. 2. Бгссисэммнал г)эулии>>сока, В данном случае компонент — это набор слабо связанных между собой программных объектов и подпрограмм, например объявлений дап. ных, функций и т.п. Интерфейс поставщика сервисов состоит иэ названий всех объектов в группировке. $.
Лбстракиии данных. Компонент является абстракцией данных пли классом, описанным па объектно-ориентированном языке. Интерфейс поставппгка сервисов саста. ит из методов (операций), обеспечивающих создание, изменение и получение доступа к абстракции данных. 4. Лбстракйии клагмфоо. Здесь компонент — это группа связанных классов. работающих совместно. Такие компоненты иногда называют структурой. Интерфейс по. ставщнка сервисов является композицией всех интерфейсов объектов, составляющих структуру (см. раздел 14.1.1). 5. Сисиммиые абгтракиии. Колпюиспт являегсл полностью автономной спсгемой, 11овторпос использование абстракций спстелгного уровня иногда называют повтор. нылг использованием коммерческих продуктов. Интерфейсом поставщика сервисов па этом уровне является так называемый программный интерфейс приложений (Арр!!саг)оп Ргойгзппп!п81щег(асс — АР1).
который предоставляет доступ к систем. ным командам и методам. Повторное использование коммерческих продуктов рассматривается в разделе 14.1.2. Подход покомпонентной разработки систем можно интегрировать в общий процесс создания ПО путем добавления специальных этапов, на которых отбираются н адаптируются повторно используемые компоненты (рис.
14.4). Проектировщики системы раэраба. тывают системную архитектуру на высоком уровне абстракции, составлля спецификации 290 кйасть 111. Проектирование системных компонентов. В дальнейшем эти спецификации используются для поиска повторно используемых компонентов. Они включаются в систему либо на уровне системной архитектуры, либо иа более низких детализированных уровнях. разрабоца Спецафк- йомск компонентов Интеграция системной ' цяроеакне дпя повторного нейденямх эркатекттрм компонентов использования компонентов Риг.
14 4. уйгтгг(тамия нввгггорнвгв иснсзлзввпиия коиививкмвв в тфвцгггрвз]гвбвглки ЛО Хотя такой подход может привести к значительному увеличению количества повторно используемых компонентов, ои, а сущности, противоположен подходу, применяемом> в дртгих инженерных дисциплинах, где процесс проектирования подчинен идее повторного использования. Перед началом этапа проектированил разработчики выполняют поиск компонентов. подходягцих для повторного использования.