Lecture07 (Лекции по Технологии программирования. Компонентный подход)

Технологии программирования. Компонентный подходВ. В. КуляминЛекция 7. Образцы проектированияАннотацияРассматривается понятие образца проектирования, классификация образцов проектирования инекоторые широко используемые примеры образцов анализа и архитектурных стилей.Ключевые словаОбразец проектирования, архитектурный стиль, идиома, образец анализа, образец организации,образец процесса, архитектурный стиль «каналы и фильтры», архитектурный стиль«многоуровневая система».Текст лекцииОбразцы человеческой деятельностиЧем отличается работа опытного проектировщика программного обеспечения от работыновичка? Имеющийся у эксперта опыт позволяет ему аккуратнее определять задачи, которыенеобходимо решить, точнее выделять среди них наиболее важные и менее значимые, четчепредставлять ограничения, в рамках которых должна работать будущая система.

Но важнее всегото, что эксперт отличается накопленными знаниями о приемлемых или не приемлемых вопределенных ситуациях решениях, о свойствах программных систем, обеспечиваемых ими, испособностью быстро подготовить качественное решение сложной проблемы, опираясь на этизнания.Давней мечтой преподавателей всех дисциплин является выделение таких знаний «в чистомвиде» и эффективная передача их следующим поколениям специалистов. В областипроектирования сложных систем на роль такого представления накопленного опыта во второйполовине XX века стали претендовать образцы проектирования (design patterns или простоpatterns), называемые также типовыми решениями или шаблонами. Наиболее широко образцыприменяются при построении сложных систем, на которые накладывается множестворазнообразных требований.

Одной из первых работ, которая систематически излагает довольнобольшой набор образцов, относящихся именно к разработке программ, стала книга [1].На основе имеющегося опыта исследователями и практиками разработки ПО выделеномножество образцов — типовых архитектур, проектных решений для отдельных подсистем имодулей или просто программистских приемов, — позволяющих получить достаточнокачественные решения типовых задач, а не изобретать каждый раз велосипед.Более того, люди, наиболее активно вовлеченные в поиск образцов проектирования в середине90-х годов прошлого века, пытались создать основанные на образцах языки, которые, хотя и былибы специфичными для определенных предметных областей, имели бы более высокий уровеньабстракции, чем обычные языки программирования. Предполагалось, что человек, знакомый стаким языком, практически без усилий сможет создавать приложения в данной предметнойобласти, компонуя подходящие образцы нужным способом.

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

Изменить код других модулей системы достаточно тяжело, так как вызовы операцийданного модуля используются во многих местах. А если придется работать с несколькимиразными версиями — не менять же код каждый раз!Другим примером такой ситуации является разработка набора тестов для некоторых операций.Хотелось бы, чтобы с помощью этого набора можно было бы тестировать любую возможнуюреализацию функций, выполняемых этими операциями. Если функции достаточно частовстречаются, например, совместно реализуют очередь, хранящую некоторые элементы, то такаявозможность очень полезна. Но у каждого набора операций может быть свой интерфейс,переделывать все тесты под который слишком трудоемко.Если можно представить набор требуемых операций как интерфейс некоторого класса вобъектно-ориентированном языке программирования, достойно выйти из такой ситуации поможетобразец проектирования адаптер (adapter).ClientTargetInterface+ operation1(Param1)+ operation2(Param2)+ operation3()AdapterImplementation+ operation1(Param1)+ operation2(Param2)+ operation3()+ implOp1(ImplPar1)+ implOp2(ImplPar2)+ implOp3()Рисунок 39.

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

При этом каждый раз объем дополнительной работы достаточно мал(если, конечно, полученная реализация действительно реализует нужные функции), а код клиентаостается неизменным.Образец проектирования нельзя выдумать или изобрести. Некоторый шаблон решения можносчитать кандидатом в образцы проектирования, если он неоднократное применялся для решенияодной и той же задачи на практике, если решения на его основе использовались в нескольких (какминимум, трех) случаях, в различных системах.Образцы проектирования часто сильно связаны друг с другом в силу того, что они решаютсмежные задачи. Поэтому часто наборы связанных, поддерживающих друг друга образцовпредставляются вместе в виде систем образцов (pattern system) или языка образцов (patternlanguage), в которых указаны возникающие между ними связи и описываются ситуации, вкоторых полезно совместное использование нескольких образцов.По типу решаемых задач выделяют следующие разновидности образцов.•Образцы анализа (analysis patterns).Они представляют собой типовые решения при моделировании сложных взаимоотношениймежду понятиями некоторой предметной области.

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

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

ниже), образцы анализа используютсяпри концептуальном моделировании и не отражают прямо возможную реализацию такоймодели в виде конкретного кода участвующих в ней классов. Например, поле X классаконцептуальной модели в реализации может остаться полем, а может превратиться в паруметодов getX() и setX() или в один метод getX() (т.е. в свойство, property, в терминах C#и JavaBeans).• Архитектурные образцы или архитектурные стили (architectural styles, architecturalpatterns).Такие образцы представляют собой типовые способы организации системы в целом иликрупных подсистем, задающие некоторые правила выделения компонентов и реализациивзаимодействий между ними.• Образцы проектирования (design patterns) в узком смысле.Они определяют типовые проектные решения для часто встречающихся задач среднегоуровня, касающиеся структуры одной подсистемы или организации взаимодействия двухтрех компонентов.• Идиомы (idioms, programming patterns).Идиомы являются специфическими для некоторого языка программирования способамиорганизации элементов программного кода, позволяющими, опять же, решить некоторуючасто встречающуюся задачу.• Образцы организации (organizational patterns) и образцы процессов (process patterns).Образцы этого типа описывают успешные практики организации разработки ПО илидругой сложной деятельности, позволяющие решать определенные задачи в рамкахнекоторого контекста, который включает ограничения на возможные решения.Для описания образцов были выработаны определенные шаблоны.

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

В рамках образца компоненты принято именовать исходя из ролей,которые они в нем играют.o Динамика — основные сценарии совместной работы компонентов образца.o Реализация — возможные проблемы при реализации и способы их преодоления,примеры кода на различных языках (в данном курсе мы будем использовать дляпримеров только язык Java). Варианты и способы уточнения данного образца.o Следствия применения образца — какими дополнительными свойствами,достоинствами и недостатками, обладают полученные на его основе решения.• Известные примеры использования данного образца.• Другие образцы, связанные с данным.Далее в этой лекции рассматриваются некоторые из известных образцов в соответствии сприведенной классификацией. Другие образцы будут упоминаться в последующих лекциях прирассмотрении способов решения тех или иных задач, а также библиотек языков Java и C#.Образцы анализаОбразец анализа является типовым решением по представлению набора понятий некоторойпредметной области в виде набора классов и связей между ними.

Основной источник описанийвыделенных образцов анализа — это работы Мартина Фаулера (Martin Fowler) [2,3].В качестве примера образцов анализа рассмотрим группу образцов, связанных спредставлением в программной системе данных измерений и наблюдений.Наиболее простым образцом этой группы является образец величина (quantity). Результатыбольшинства измерений имеют количественное выражение, однако, если представлять их в видеатрибутов числовых типов (рост — 182, вес — 83), часть информации пропадает. Пока всепользователи системы и разработчики, вносящие в нее изменения, помнят, в каких единицахизмеряются все хранимые величины, все в порядке, но стоит хоть одному ошибиться — ирезультаты могут быть весьма серьезны.

Такого рода ошибка в 1998 году вывела из строяамериканский космический аппарат Mars Climate Orbiter, предназначавшийся для исследованияклимата Марса. Данные о текущих параметрах движения аппарата поступали на Землю,обрабатывались, и результирующие команды отправлялись обратно. При этом процедурымониторинга и управления движением на самом аппарате воспринимали величину импульса какизмеренную в Ньтонах на секунду, а программы обработки данных на Земле — как значениеимпульса в фунтах силы на секунду.