Lecture08 (1133565), страница 3
Текст из файла (страница 3)
Определить для таких возможностей методы-перехватчики.• Определить несколько наиболее часто используемых вариантов алгоритма.Реализовать их в виде подклассов определяющего шаблонный метод класса,определив в них методы, которые представляют абстрактные операции, и, если этонеобходимо, переопределив методы-перехватчики.Следствия применения образца.Достоинства• Общая часть алгоритма реализуется явно и может быть легко переиспользована.• Изменяемые части алгоритма могут варьироваться удобным образом, не влияя другна друга и давая в результате различные его модификации.• Алгоритм может быть параметризован большим набором политик, для каждой изкоторых возможна реализация по умолчанию.Недостатки• Снижение понятности кода за счет сложного потока управления.• Снижение производительности в случае большого числа параметров, из которых вкаждом конкретном варианте алгоритма используется лишь несколько.Примеры.
Шаблонные методы очень часто используются при построении библиотечныхклассов и каркасов приложений.Жизненный цикл компонентов EJB реализован в виде шаблонного метода, в которомабстрактной операцией служит создание объектов данного компонента. Имеется такженесколько операций-перехватчиков, позволяющих разработчику компонентаспецифическим образом обрабатывать переход компонента из одного состояния в другое.Другой пример — реализация метода start(), запускающего отдельный поток в Java.Инструкции, выполняемые в рамках потока, помещаются в метод run() объекта классаThread или класса, реализующего интерфейс Runnable. Этот метод служит операциейперехватчиком для метода start() — реализация метода run() по умолчанию ничего неделает.Образцы организации и образцы процессовОбразцы организации работ и образцы процессов существенно отличаются от остальных видовобразцов, рассматриваемых здесь. Они фиксируют успешные практики по организациидеятельности, связанной с разработкой ПО (или другими сложными видами деятельности).
Такиеобразцы только поддерживают проектирование и разработку ПО, не давая вариантов самихпроектных решений.Образцы этого вида чаще всего извлекаются из форм организации работ и процессов,принятых в успешных компаниях-производителях ПО. Плодотворность их использованияоценивается управленцами достаточно субъективно. При этом, однако, для признания некотороговида организации работ образцом, необходимо успешное ее использование для решения одних итех же задач в нескольких организациях.Шаблон для описания таких образцов выглядит следующим образом.• Название образца.• Контекст использования, включающий основную решаемую задачу и начальные условия.• Действующие силы — проблемы, ограничения, требования, рассуждения и идеи, подвоздействием которых вырабатывается решение.• Решение — описание используемой формы организации работ, выделяемых подзадач,выполняемых действий, используемых техник.• Итоговый контекст — описание ожидаемых результатов использования образца,обоснование того, что его применение даст нужный эффект.В качестве примера образца организации работ приведем процесс инспекции программ (Faganinspection process), определенный Майклом Фаганом (Michael Fagan) [4,5] (похожий процесс,называемый технической экспертизой, technical review, может быть найден в [6]).Инспекция программ по ФагануНазвание.
Инспекция программ по Фагану (Fagan inspection process).Контекст использования. Поиск ошибок на ранних этапах разработки программногообеспечения — при подготовке требований, проектировании, начальных этапахкодирования, планировании тестов.Действующие силы.• Усилия, необходимые для исправления ошибки, и, соответственно, ее стоимостьвозрастают в зависимости от этапа проекта, на котором она обнаружена. Изэмпирических данных известно, что каждый раз при переходе через границу междуфазами (при использовании водопадной модели разработки) подготовка требований– проектирование – кодирование – тестирование – эксплуатация трудозатраты наисправление найденных на данном этапе ошибок возрастают в 3-5 раз. Прииспользовании итеративных моделей затраты возрастают меньше, но не намного.Поэтому, чем раньше ошибки будут обнаруживаться, тем эффективней будетразработка в целом.• Членам команды разработчиков надо понимать, над чем работает каждый из них икакие решения он использует.
Это помогает значительно повысить эффективностьсобственной работы.•Каждый артефакт — требования, проектные документы, код, тестовые планы —должен быть подготовлен на нужном уровне качества, прежде чем он будетиспользован для дальнейшей работы.• Знания о найденных ошибках позволяют членам команды избегать их повторения, атакже обращать больше внимания на компоненты, которые оказались наиболееподвержены ошибкам на предыдущих этапах.Решение.
Несколько членов команды разработчиков проводят тщательную инспекциюрезультатов работы одного из них. Такие инспекции основываются на первичныхдокументах, чтобы проверить соответствие им вторичных документов. Первичные ивторичные документы для каждого вида деятельности в ходе разработки, для которыхпроведение инспекций эффективно, представлены в Таблице 8.Выделяются следующие роли участвующих в процессе инспекции лиц.• Ведущий (moderator). Он руководит проведением инспекции, руководит собраниями,фиксирует обнаруженные ошибки, назначает время проведения собраний, срокиподготовки отчетов, следит за исправлением найденных ошибок.В качестве ведущего должен использоваться компетентный разработчик илиархитектор, не вовлеченный в проект, материалы которого инспектируются.• Автор (author).
Это автор первичного документа или человек, имеющий достаточнополное представление о нем. Его обязанности — подготовить рассказ об основныхположениях первичного документа и отвечать на вопросы, возникающие у членовинспектирующей команды по его поводу.• Интерпретатор (reader).
Это автор вторичного документа, который разработан всоответствии с первичным. Его обязанности — объяснить участникам инспекцииосновные идеи, лежащие в основе его интерпретации первичного документа, иотвечать на их вопросы по поводу вторичного документа.• Инспектор (tester). В ходе всей инспекции он анализирует вторичный документ,проверяя его на соответствие первичному.Вид деятельностиАнализ требованийПроектированиеПервичные документыМодели предметной области,составленные заказчиками ипользователями требованияТребования к ПОКодированиеПроектная документацияТестированиеТребования к ПО, проектнаядокументация, кодВторичные документыТребования к ПООписание архитектуры, проектнаядокументацияКод, проектная документация наотдельные компонентыТестовые планы и наборытестовых вариантовТаблица 8.
Первичные и вторичные документы на разных этапах разработки.Обычно рекомендуется использовать не более 4-х человек в команде, проводящейинспекцию. Расширение ее возможно в особых случаях и только за счет разработчиков,которым непосредственно придется иметь дело с инспектируемыми вторичнымидокументами.Сам процесс инспекции состоит из следующих шагов.1. Планирование (planning).На этом шаге ведущий должен убедиться в том, что первичный и вторичный документыготовы к проведению инспекции — они существуют, написаны достаточно понятно, сдостаточной степенью детализации.Кроме того, на этом шаге проводиться планирование всего хода инспекции —определяются участники, их роли, назначаются сроки проведения собраний и время,выделяемое на выполнение каждого шага.2. Обзор (review).Проводится собрание, на котором автор представляет наиболее существенныеположения первичного документа и отвечает на вопросы участников о нем.Первичный и вторичный документы выдаются на руки участникам инспекции длядальнейшей работы.Ведущий объясняет задачи данной инспекции, вопросы и моменты, на которые стоитобратить особое внимание, а также сообщает, какие ошибки были уже обнаружены врассматриваемых документах, чтобы участники группы имели представление об ихпроблемных местах.3.
Подготовка (preparation).Каждый из участников тщательно изучает оба документа самостоятельно, пытаясьпонять заложенные в них решения и проследить их реализацию.Часто на этом этапе обнаруживаются ошибки, но гораздо меньше, чем на следующем.4. Совместная инспекция (inspection meeting).Проводится совместное собрание, на котором интерпретатор рассказывает об основныхидеях и техниках, использованных во вторичном документе, а также объясняет, почемубыли приняты те или иные решения и почему они соответствуют первичномудокументу.Участники задают вопросы и акцентируют внимание на проблемных местах.
Как тольковедущий по ходу собрания замечает ошибку (или кто-то обращает его внимание на нее),он сообщает о ней и убеждается, что все участники согласны с тем, что это именноошибка, т.е. несоответствие между первичным и вторичным документами. Каждаяошибка фиксируется, описывается ее положение, она классифицируется по некоторойсхеме, например, критическая (приводящая к ошибке в работе системы) илинекритическая (связанная с опечатками, излишней сложностью или неудобствоминтерфейса и пр.).5.
Доработка (rework).В ходе доработки интерпретатор исправляет обнаруженные ошибки.6. Контроль результатов (follow-up).Результаты доработки проверяются ведущим. Он проверяет, что все найденные ошибкибыли исправлены и что не было внесено новых ошибок. Если по результатам инспекциибыло переработано более 5% вторичного документа, следует провести полнуюинспекцию вновь. Иначе ведущий сам определяет, насколько документ подготовлен кдальнейшему использованию.Кроме того, ведущий подготавливает отчет обо всех обнаруженных ошибках дляпоследующего использования в других инспекциях и при оценке качества результатовразработки.Итоговый контекст.
В результате проведения инспекций повышается качество проектныхдокументов и кода, разработчики знакомятся ближе с работой друг друга и с задачамипроекта в целом, углубляют понимание проблем проекта и используемых в нем решений.Кроме того, руководитель проекта получает надежные данные о качестве результатовразработки.Руководитель должен понимать, что результаты инспекций не должны использоваться какпоказатель качества работы разработчиков, иначе все положительные эффекты от ихпроведения пропадают — разработчики начинают неохотно участвовать в инспекциях,скрывают детали своей работы, снисходительнее относятся к ошибкам других в расчете навзаимность и пр.При выполнении этого условия инспекции являются эффективным средством обнаруженияошибок на ранних этапах.
Статистика показывает, что они находят до 80% ошибок,обнаруживаемых за весь период разработки ПО.Литература к Лекции 8[1] G. E. Krasner, S. T. Pope. A cookbook for using the Model-View-Controller user interfaceparadigm in Smalltalk-80. Journal of Object-Oriented Programming, 1(3), pp. 26–49, AugustSeptember 1988. SIGS Publications, NY, USA, 1988.[2] CORBA Event Service Specification, version 1.2. Object Management Group, October 2004.Доступен как http://www.omg.org/cgi-bin/apps/doc?formal/04-10-02.pdf.[3] Э. Гамма, Р. Хелм, Р. Джонсон, Дж.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
