В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 35
Текст из файла (страница 35)
Эти операции могут переопределяться вклассах-потомках, если представляемые ими элементы алгоритма нужно изменить посравнению с имеющейся реализацией по умолчанию.• Фабричные методы (factory methods), предназначенные для создания объектов, которыесвязаны с работой конкретного варианта алгоритма. Они реализуются по образцу, такженазываемому «фабричный метод».
Суть такого метода в том, что при его вызове мыточно не знаем, объект какого конкретного класса будет создан — это зависит оттекущей конфигурации системы.Динамика. Типичный сценарий работы шаблонного метода показан на Рис. 56. Длянаглядности на этой диаграмме операции, выполняемые в одном объекте, разделены междудвумя виртуальными объектами: первый представляет все действия, выполняемые в рамкахабстрактного класса, определяющего шаблонный метод, а второй — те действия, которые(пере)определяются в конкретном подклассе.Abstract Class Methodsmethod()Concrete Class Methodsconcrete operationabstract operation 1default hook operationabstract operation 2overriden hook operationРисунок 56.
Сценарий работы шаблонного метода.Реализация. Основные шаги реализации следующие.• Определить основные шаги алгоритма. Определить набор данных, которыми онпользуется.• Выделить среди шагов алгоритма те, которые зависят от конкретных политик.Определить для каждого такого шага абстрактный метод.114•Выделить среди данных, которыми пользуется алгоритм, те, чья структура зависитот политик или конкретного варианта алгоритма. Определить для порождения такихданных фабричные методы, а для операций над ними — абстрактные методы. Дляих представления могут понадобиться дополнительные классы, но изменяемая частьданных должна, по возможности, находиться в абстрактном классе, определяющемшаблонный метод.• Реализовать общую схему алгоритма в теле шаблонного метода.
Выделить егоэлементы, используемые несколько раз или представляющие собой отдельныеоперации, в отдельные методы абстрактного класса.• Определить, какие дополнительные возможности по вариации поведения алгоритмамогут понадобиться. Определить для таких возможностей методы-перехватчики.• Определить несколько наиболее часто используемых вариантов алгоритма.Реализовать их в виде подклассов определяющего шаблонный метод класса,определив в них методы, которые представляют абстрактные операции, и, если этонеобходимо, переопределив методы-перехватчики.Следствия применения образца.Достоинства• Общая часть алгоритма реализуется явно и может быть легко переиспользована.• Изменяемые части алгоритма могут варьироваться удобным образом, не влияя другна друга и давая в результате различные его модификации.• Алгоритм может быть параметризован большим набором политик, для каждой изкоторых возможна реализация по умолчанию.Недостатки• Снижение понятности кода за счет сложного потока управления.• Снижение производительности в случае большого числа параметров, из которых вкаждом конкретном варианте алгоритма используется лишь несколько.Примеры.
Шаблонные методы очень часто используются при построении библиотечныхклассов и каркасов приложений.Жизненный цикл компонентов EJB реализован в виде шаблонного метода, в которомабстрактной операцией служит создание объектов данного компонента. Имеется такженесколько операций-перехватчиков, позволяющих разработчику компонентаспецифическим образом обрабатывать переход компонента из одного состояния в другое.Другой пример — реализация метода start(), запускающего отдельный поток в Java.Инструкции, выполняемые в рамках потока, помещаются в метод run() объекта классаThread или класса, реализующего интерфейс Runnable.
Этот метод служит операциейперехватчиком для метода start() — реализация метода run() по умолчанию ничего неделает.Образцы организации и образцы процессовОбразцы организации работ и образцы процессов существенно отличаются от остальных видовобразцов, рассматриваемых здесь. Они фиксируют успешные практики по организациидеятельности, связанной с разработкой ПО (или другими сложными видами деятельности). Такиеобразцы только поддерживают проектирование и разработку ПО, не давая вариантов самихпроектных решений.Образцы этого вида чаще всего извлекаются из форм организации работ и процессов,принятых в успешных компаниях-производителях ПО. Плодотворность их использованияоценивается управленцами достаточно субъективно.
При этом, однако, для признания некотороговида организации работ образцом, необходимо успешное ее использование для решения одних итех же задач в нескольких организациях.Шаблон для описания таких образцов выглядит следующим образом.115•••Название образца.Контекст использования, включающий основную решаемую задачу и начальные условия.Действующие силы — проблемы, ограничения, требования, рассуждения и идеи, подвоздействием которых вырабатывается решение.• Решение — описание используемой формы организации работ, выделяемых подзадач,выполняемых действий, используемых техник.• Итоговый контекст — описание ожидаемых результатов использования образца,обоснование того, что его применение даст нужный эффект.В качестве примера образца организации работ приведем процесс инспекции программ (Faganinspection process), определенный Майклом Фаганом (Michael Fagan) [4,5] (похожий процесс,называемый технической экспертизой, technical review, может быть найден в [6]).Инспекция программ по ФагануНазвание.
Инспекция программ по Фагану (Fagan inspection process).Контекст использования. Поиск ошибок на ранних этапах разработки программногообеспечения — при подготовке требований, проектировании, начальных этапахкодирования, планировании тестов.Действующие силы.• Усилия, необходимые для исправления ошибки, и, соответственно, ее стоимостьвозрастают в зависимости от этапа проекта, на котором она обнаружена.
Изэмпирических данных известно, что каждый раз при переходе через границу междуфазами (при использовании водопадной модели разработки) подготовка требований– проектирование – кодирование – тестирование – эксплуатация трудозатраты наисправление найденных на данном этапе ошибок возрастают в 3-5 раз. Прииспользовании итеративных моделей затраты возрастают меньше, но не намного.Поэтому, чем раньше ошибки будут обнаруживаться, тем эффективней будетразработка в целом.• Членам команды разработчиков надо понимать, над чем работает каждый из них икакие решения он использует.
Это помогает значительно повысить эффективностьсобственной работы.• Каждый артефакт — требования, проектные документы, код, тестовые планы —должен быть подготовлен на нужном уровне качества, прежде чем он будетиспользован для дальнейшей работы.• Знания о найденных ошибках позволяют членам команды избегать их повторения, атакже обращать больше внимания на компоненты, которые оказались наиболееподвержены ошибкам на предыдущих этапах.Решение. Несколько членов команды разработчиков проводят тщательную инспекциюрезультатов работы одного из них. Такие инспекции основываются на первичныхдокументах, чтобы проверить соответствие им вторичных документов.
Первичные ивторичные документы для каждого вида деятельности в ходе разработки, для которыхпроведение инспекций эффективно, представлены в Таблице 8.Выделяются следующие роли участвующих в процессе инспекции лиц.• Ведущий (moderator). Он руководит проведением инспекции, руководит собраниями,фиксирует обнаруженные ошибки, назначает время проведения собраний, срокиподготовки отчетов, следит за исправлением найденных ошибок.В качестве ведущего должен использоваться компетентный разработчик илиархитектор, не вовлеченный в проект, материалы которого инспектируются.• Автор (author). Это автор первичного документа или человек, имеющий достаточнополное представление о нем.
Его обязанности — подготовить рассказ об основных116••положениях первичного документа и отвечать на вопросы, возникающие у членовинспектирующей команды по его поводу.Интерпретатор (reader). Это автор вторичного документа, который разработан всоответствии с первичным. Его обязанности — объяснить участникам инспекцииосновные идеи, лежащие в основе его интерпретации первичного документа, иотвечать на их вопросы по поводу вторичного документа.Инспектор (tester).
В ходе всей инспекции он анализирует вторичный документ,проверяя его на соответствие первичному.Вид деятельностиАнализ требованийПроектированиеПервичные документыМодели предметной области,составленные заказчиками ипользователями требованияТребования к ПОКодированиеПроектная документацияТестированиеТребования к ПО, проектнаядокументация, кодВторичные документыТребования к ПООписание архитектуры, проектнаядокументацияКод, проектная документация наотдельные компонентыТестовые планы и наборытестовых вариантовТаблица 8. Первичные и вторичные документы на разных этапах разработки.Обычно рекомендуется использовать не более 4-х человек в команде, проводящейинспекцию.
Расширение ее возможно в особых случаях и только за счет разработчиков,которым непосредственно придется иметь дело с инспектируемыми вторичнымидокументами.Сам процесс инспекции состоит из следующих шагов.1. Планирование (planning).На этом шаге ведущий должен убедиться в том, что первичный и вторичный документыготовы к проведению инспекции — они существуют, написаны достаточно понятно, сдостаточной степенью детализации.Кроме того, на этом шаге проводиться планирование всего хода инспекции —определяются участники, их роли, назначаются сроки проведения собраний и время,выделяемое на выполнение каждого шага.2.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
