И. Соммервилл - Инженерия программного обеспечения (1133538), страница 77
Текст из файла (страница 77)
система управления ресурсами энергосистемы должна отслеживать все стациопарпыс энсргообъскгы и соответствующее оборудование. В университетах сис. тема управления ресурсами может отслеживать оборудование, используемое в учебных лабораториях. Рис. 14. 7. Обобщен кпя сиаиежп упрпопенил рпурспии Очевидно, системы управления ресурсами будут отличаться лруг от друта в зависимости от типа ресурсов и от информации, необходимой для управления ими. Например, в приложении длл эцсргосистемы пс нужны средства, позволяющие изменять размещение ресурсов, так как все объекты энергосистемы стациоиарны.
Однако система учета ресурсов для университета должна иметь такую возможность, так как оборудование может переходить из одной лаборатории в друпую. Том нс менее все эти системы должны предоставлять основныс средства для управлс. ния ресурсами: возможность добавления и удаления ресурсов, формирование запросов, просмотр базы даниеля ресурсов и формирование отчетов. Следовательно, архитектура систсл~ управления ресурсами будет одинакова для целого семейства приложений, в котором отдсльные приложения поддерживают разные типы ресурсов.
Для того чтобы повторное использование систем было эффективным, на этапе создания архитектуры необходимо отделить основные средства системы от конкретной нп. формации об управляемых ресурсах и от доступа пользователей к этой информации. 11а рис. 14.7 разделение достигнуто благодаря многоуровневой архитектуре, в которой на одном уровне встроены описания ресурсов, формирование экранных форм и отчетов. Верхнис уровни системы используют эти описания в своих методах и нс содержат конкретной информации о ресурсах.
Посредством измснснпл уровня описаний можно создавать раз. личные приложснил управления ресурсами. Конечно, такой тип систсм можно выполнить в вндс объсктночзриснтированных, оп. рсдслив сначала объект абстрактного ресурса, а затем с помощью наследования — объект, зависящий от типа управляемого ресурса. В итоге такая архитектура будет немногим отличатыя от архитектуры.
изображенной на рис. 14.7. Однако для систем данного типа объектно-ориентированный подход не годится. Когда приложения рассчитаны на большие базы данных, содержащие миллионы записей, но относительно малос количество ти. пов логических модулей (соответствующих объектам и сущностям), очевидно, что объектно-ориснтированнал система работаст мснсс эффективно, чсм системы с рсляцион. ными базами данных. На момент написанил книги коммерческие объектно.ориснти- 14. Проектирование с повторным нсподъэованнем компонентов 297 рованные базы все еще остаются относительно медленными и не способными поддерживать сотни транзакций в секунду. Подобно тому как посредством описаний новых ресурсов можно создавать новые члены семейства приложений, с помощью включения новых модулей на системном уровне в систему можно добавить новые функциональные воэможности.
Для создания библиотечной системы (рис. 14.8) я адаптировал систему управления ресурсами, показанную на рис. 14.7. В результате в систему добавлены новые возможности для выдачи и возврата ресурсов и регистрации пользователей системой. На рис. 14.8 эти средства расположены справа. Так как программный доступ здесь не нужен, саиый верхний уровень системы поддерживает доступ к ресурсам только на уровне пользователя. Рис.
14.8, Библиоомчнол гиетежл В целом адаптация версии приложения в процессе его разработки приводит к тому, что значительная часть кода приложения используется повторно. Более того, накоплен. ный опыт часто можно использовать для разработки других систем, поэтому объединение разработчиков ПО в отдельную группу сокращает процесс нх обучения. Так как тесты для большинства компонентов приложения также можно использовать повторно, то полное время, необходимое на разработку приложения, значительно умен ыаается. Процесс адаптации семейства приложений для создания нового приложения состоит из нескольких этапов, представленных на рис.
14.9. Детали процесса могут значительно отличаться для разнык приклодпых областей и для различных организаций. Обобщенный процесс создания нового приложения состоит иэ следующих этапов. 1. Оггределекие требоооиий для нового приложению Данный этап — обычный процесс разработки требований.
Но так как система уже существует, естественно провести экспериментирование с ней и выявить те системные требования, которые необходи. мо изменить. 2. Выбор ноиболег лодходлгйего члена имейетлп яриложений. Выполняется анализ требав. ний, после чего выбирается наибалес подход>пций член семейства, требующий вне. сония минимальных изменений.
3. Пересмотр требоооиий. Как правило, появляется дополнительная информация, требующая внесения изменений в существующую систему. поэтому пересмотр требований на этом этапе позволяет уменьшить количество необходимых изменений. 298 з1асть П1.
Проектирование 4. Лдппмацкл вмэрлкиой сисэимм. Для системы разрабатываются новые модули, а суще- сгвуюгцие адаптируются к повылг требованиям. 5. Сюдпкие зювого члена сгззгйсима приложений. Для закаэчика создается новый член семейства приложений. На этом этапе выполняетгл документирование ключевых особенностей системы, чтобы в дальнейшеи ее можно было использовать как основу для разработки других систем. Рис.
И. й Лрокегс)лирабоэжи новою члена ссисйсэип яриложгкий В процессе создания нового члена семейства приложений часто требуется найти не. кнй компромисс между наиболес полным использованием существующих приложений и выполнением конкретных требований для нового приложения. Чем более детальны требования к системе, тем меньше вероятность, что имеющиеся компоненты будут соответствовать этим требованиям. Но практически всегда можно достигнуть определенного компромисса и ограничить объем изменений. вносимых в систему. тогда процесс создания новой системы выполняется быстро и с небольшими затратами.
За редким исключением, семейства приложений создаются из имеющихся приложений, т.с. организация создает приложения и зател~ при пеобходилюсти использует нх как основу для разработки нового приложения. Но вместе с тем внесение изменений наруша. ст структуру црнложеннл, поэтому рано нли поздно принимается решение о создании семейства обобщенных приложений. В этом случае активно используются знания, собранные в процессе создания исходной группы приложений.
14.3. Проектные паттерны Попытки повторно использовать дсйствуюв1ие компоненты постоянно ограничиваются конкретными решсниямн, принлтыми системными разработчиками. Решения могут относиться к отдельным алгоритмам, используемым при реализации компонентов, к объелтам н к типам лаппых в интерфейсах компонентов. Если решения противоречат конкретным требованиям к компонентам, то повторное использование компонентов либо невозможно, либо делает систему неэффективной.
Одни из способов решения данной проблемы — повторное использование более абстрэкгных структур, не содсржагцих деталей реализации. Такие структуры разрабатываются специально для того. чтобы соответствовать определенном» приложению. Первые реализациии этого подхода привели к документированию и опубликованию фундаментальных алгоритмов [201), а зател» к документированию абстрактных типов данных, таких как стеки, деревья и списки [э8). Совсем недавно такой способ гювторного испоаьзовання обоб. щен в понятии пазтерна. Проекппяс пазтерны (г)сз)яп рацегпз) [124) появились нз идей, выдвинутых Кристофером Ллсксандсром (А!схапг1ег, [8)), который предложил удобные и эффективные гзбобщсииыс паттсрны разработки конкретных проектов.
Пазтсрц — это описание про. 14. Проектирование с повторным использованием компонентов 299 блемы и метода ее решения, позволяющее в дальнейшем использовать зто решение в разных условиях. Паттерн не является детальной спецификацией. Скорее, он представляет собой описание, в котором аккумулированы знания н опыт. Патгерн — гарантированное решение общей проблемы. При создании ПО проектные патгерны всегда свлзаны с объектно.ориентированным проектированием. Чтобы обеспечить всеобщность, паттерны часто используют такие объектно. ориентированные понятия, как нагледовзиие и полиморфизм.
Однако общий принцип использования паттерноа одинаково применим при любом подходе к проектированию ПО. В (124] определены четыре основных элемента проектного паттериа. 1. Содержательное имя, которое является ссылкой на патгерн. 2. Описание проблемной области с перечислением всех ситуаций.
в которых можно испольэовать патгерн. 3, Описание решений с отдельным описанием различных частей решения и их взаимоотнщцсний. Это не описание конкретного проелта. а шаблон проектных решений, который можно использовать различными способами. В описании решений часто используются графические представления, которые показывают взаимоотношения между объектами и классами объектов в данном реп~сниц.
4. Описание "выходных" результатов — это описание результатов и компромиссов, необходимых для применения паттерна. Обычно используется для того, чтобы помочь разработчикам оценить конкретную ситуацию и выбрать длл цес наиболее подходянгнй паттерн. Часто в описание патгсрна вводятся икжс разделы мозщвавик (обоснованна полезности паттерна) и ярилина новак (описание ситуаций, в которых можно использовать паттерп).
В качестве примера рассмотрим один пз наиболее часто используемых паттернов, предложенных в работе [124], а именно Обозреватель (ОЬвегчсг) (см. врезку 14.1). Данный патгерн используется тогда, когда необходимы разные представления состояния объекта. Он выдсллст нужный объект н представляет его в разных формах; на рис. 14.10 показаны два графических представления одного и того же набора данных. 1тес. 14.10 Различные л]еедстааченил даакмх ЗОО 'Часть П1.
Проектирование ' Описа((Йе'йаттерйа (убозреватель' "~~~~~~У(б~ц(;.;:; .',-;Уз1~3~.. .ОВОЭРВВатеязу',о а)ф 'гй): .,'.:: )(,.Ч;::Отй)ХЧ1ГГаг(3 ' ' ' 'рЭ~~!'-:~'!~,Е делает отабражрйие состояния обьека от самого обьекта'ы йредгкбаеъразлгийае таа)еея состояншг').е При изменении состояния обьекта все првдсташюншг,автоматике чтобы отобразить происшедшие изменения из'загара'-''ыгч 'з-:Г 1'~ъе!чсвь проблемы. Во мнопа ситуациях требуется предсаквить инФорйзцою о'состоинии нвк яю обьекта несколькими разными способами, например используя графическое и табличное предо ' пения. Все представления взаимосвязаны и дшаны обновляться при изменении состррния, ..., ч"." Даишяй паттерн можно использовать во всех ситуациях, где требуется несколько 'разных йредставлений ' ' информации о состоянии обьекта'и гдв нвт необходимости знать форматы представлейия'данных о'соОпнсание ранения.
Структура патгврна показана на рис; 14.11.'В нем определены 'два'абстрвктнни. обьекта ЗпЬ)еся (данные) и:ОЬвегчег (Обозревшель)„' а также дяа конкретных )рбьвкта: ' :Сопсге(еЗцЬ)ес( (Конкретные данные) и СопсгетеОЬзепгег (Конкретный обозреватель);, которые ; наследуют свойства соответствующих абстрактных обьеюов. Отобршклвуяое состояние поддерживается : обьектом Сопсге)еЗиЬ)ес1, который таске 'наследует методы от ЗцЬ)есК позволяющие вму, доба :.
лять и удшмть обьекты ОЬзепгег (методы Ацасп и Ое1асЬ) и выдавать оповев(вине пйи измен состаяния,(метод йод(у).,:,, т;...,:л.; ..',', . ' "' ' '.;:.:,',.е, -Обьеа СопсгетеОЬзегчег обрабатывает копию состояния СопсгптеЗоЬ)ест (колию зпЬ)ес18 , полученную с помощью метода Ое)81ате (получить состояние)) и реализует метод 0рбате (Обнов интерфейса ОЬзепгег, который позволяет сохранять копии состояния. Сопсге1еОЬвегчег ваго чески отой)южает зто состояние.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
