Обобщенный алгоритм проектирования

Обобщенный алгоритм проектирования

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

Под проектной процедурой понимают формализованную совокупность действий, в результате выполнения которой получают проектное решение.

Проектное решение - промежуточное или конечное описание объекта проектирования, необходимое и достаточное для рассмотрения и определения дальнейшего направления или окончания проектирования.

Проектные операции - это действия или формализованная совокупность действий, алгоритм которых остается неизменным для ряда проектных процедур.

Каждая стадия проектных работ может быть описана в терминах проектных процедур и операций с учетом их логических связей. Весь процесс проектирования после этого становится логически увязанной системой стадий, процедур и операций. Эту систему называют обобщенным алгоритмом проектирования. (См. алгоритм на рис.).

Для каждой степени детализации описания объекта (иначе говоря, для каждого уровня иерархической структуры проектируемого объекта: объект (0-уровень) —> обеспечивающие подсистемы (1 уровень) —> узлы (2 уровень) —>. —> элементы (последний к-тый уровень)) выполняется следующая последовательность проектных операций:

формализация целей проектной задачи,

анализ исходных данных,

выработка предварительных предложений о средствах достижения целей (декомпозиция объекта проектирования на составляющие части или синтез структуры),

моделирование выбранных классов или типов объектов проектирования в виде соотношений Y = F(X, Q), LV(Z) = f(Z) или других ММ, о которых речь пойдет далее; ограничений Y<ТТ, Y>ТТ. и функционалов качества I = K(Y),

5) выработку вариантов проектных решений на основе анализа моделей,

6) испытание и структурное согласование предварительных проектных решений,

7) принятие окончательных проектных решений,

документирование результатов проектирования как законченного фрагмента проекта.

Обобщенный алгоритм проектирования

Как видно из рисунка, для каждого уровня представления объекта проектирования (на рисунке он обозначен как k+1) на предыдущем уровне формулируется техническое задание, которое формализуется в виде соотношений (3) для выходных параметров:

Собственно проектирование начинается с синтеза структуры и разработки соответствующей математической модели. Как уже говорилось ранее, некоторые внутренние параметры в такой модели могут изменяться проектировщиком. Такие параметры называются проектными и для них определяются начальные или базовые значения. Источниками для определения этих значений могут быть справочники, прототипы или они могут рассчитываться по формулам конструктора.

Далее выполняется проектная процедура анализа – расчет выходных параметров по математической модели. Обратите внимание! Решающие блоки 1, 2, 3 в этом алгоритме отображают проектные решения, которые должны дать ответ на вопрос: заканчивать или продолжать процесс проектирования?

На рисунке проектные процедуры анализа, оптимизации и синтеза выделены двойными линиями, что позволяет убедиться в том, что эти процедуры являются вложенными.

Решающий блок 4 отражает факт итерационности процесса проектирования. Изменения параметров проектирования могут привести к многократному анализу, если результаты анализа для области определения проектных параметров являются неудовлетворительными, вносятся изменения в структуру объекта, что потребует внесения изменений в математическую модель объекта. Возможен и такой вариант, когда все возможные изменения в структуре объекта не приводят к желаемому проектному решению, тогда необходимо вносить изменения в формулировку технического задания. Как правило, это происходит в таких случаях, когда неверно определяются ограничения для противоречивых выходных параметров (подумайте, какие противоречивые выходные параметры Вы знаете для САУ).

Для уяснения сущность проектных процедур анализа, синтеза и оптимизации обратимся к явной ММ объекта проектирования, отражающей его функциональный аспект:

где Y также, как в формуле (1.1) - вектор выходных характеристик (параметров), а в векторе X выделены в отдельные составляющие U- вектор проектных параметров (они потому и названы проектными, что проектировщик их может назначать, исходя из тех или иных требований к объекту проектирования) иW- вектор остальных внутренних параметров, Q - вектор воздействий на элемент внешних факторов, иначе вектор внешних воздействий, F - вектор-функция, отражающая влияние внутренних и внешних параметров на выходные.

Проектная процедура синтеза заключается в построении структурной схемы объекта проектирования, назначении (выделении) проектных параметров U, определении области допустимых значений этих параметров, построении структурной схемы объекта проектирования и вычислении номинальных (базовых) значений этих параметров.

Процедура анализа состоит в определении, удовлетворяют ли техническим требованиям выходные параметры объекта проектирования при выбранной схеме и значениях проектных параметров. Иными словами, определяется, удовлетворяются ли соотношения:

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

Проектная процедура оптимизации заключается в вычислении таких значений проектных параметров, при которых критерий функционирования объекта проектирования принимает экстремальное значение.

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

Сложность алгоритма проектирования, с одной стороны, и наличие современных технических средств обработки информации, с другой стороны, предопределяют целесообразность и возможность автоматизированного проектирования.

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

Таким образом, развитые САПР, обеспечивающие высокую степень автоматизации, должны представлять проектировщику возможности использования баз развивающихся знаний в той или иной области проектирования:

формализованных описаний объектов проектирования в виде их ММ;

эффективные алгоритмы оценки точности и прогноза состояния моделей;

реализацию алгоритмов генерации вариантов и поиска оптимальных проектных решений;

информационного обеспечения процесса моделирования и принятия решений;

документирования этапов проектирования;

эффективного диалога проектировщика с системой на основе применения проблемно-ориентированных языков программирования и проектирования.

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

Итак, для получения максимального эффекта автоматизации проектирования САПР должен удовлетворять запросы проектировщика; проектировщик обязан в полной мере учитывать специфику и реальные возможности системы.

Система автоматизированного проектирования (САПР) определена в ГОСТ 23501.0-79 как организационно-техническая система, состоящая из комплекса средств автоматизации проектирования (КСАП), взаимодействующего с подразделениями проектной организации, и выполняющая автоматизированное проектирование.

Рисунок Структура ПО САПР

Как и любая сложная система САПР состоит из подсистем (см. рисунок). В САПР различают подсистемы проектирующие и обслуживающие.

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

Обслуживающие подсистемы обеспечивают функционирование проектирующих подсистем, их совокупность часто называют системной средой или оболочкой САПР. Такими подсистемами являются: подсистемы управления проектными данными (PDM–ProductDataManagement),управления процессом проектирования (DesPM–DesignProcessManagement), пользовательского интерфейса для связи разработчиков с ЭВМ,CASE(ComputerAidedSoftwareEngineering) для разработки и сопровождения программного обеспечения САПР, обучающие подсистемы для освоения пользователями технологий, реализованных в САПР.

Средства автоматизации проектирования структурируются по видам обеспечения: математическое обеспечение, программное обеспечение, техническое обеспечение, информационное обеспечение, организационное обеспечение, методическое обеспечение.

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

Информационное описание объекта проектирования реализуется при автоматизации проектирования в информационном обеспечении САПР. Информация об объектах проектирования представляется в виде документов на машинных носителях, содержащих сведения справочного характера о материалах, комплектующих изделиях, типовых проектных решениях, параметров элементов, сведения о состоянии текущих разработок в виде промежуточных и окончательных проектных решений, структур проектных объектов и т.п. Основная составная часть ИО САПР - банк данных, состоящий из БД и СУБД.

БД - сами данные, находящиеся на машинных носителях информации, т.е. в запоминающих устройствах ЭВМ и структурированные в соответствии с принятыми в БД правилами. СУБД - совокупность программных средств, обеспечивающих функционирование банка данных. С помощью СУБД производится запись данных в банк, их выборка по запросам пользоватлей и прикладных программ, обеспечивается защита данных от искажений и от несанкционированного доступа и т.п.

Лингвистическое обеспечение - совокупность языков проектирования, предназначенных для описания процессов автоматизированного проектирования и проектных решений. Это язык общения проектировщика с ЭВМ. В развитых САПР таких языков может быть несколько, причем каждый из них основывается на правилах формализации естественного языка и использует методы сжатия и развертывания текста.

Методическое обеспечение составляют документы, регламентирующие состав, правила отбора и эксплуатации средств автоматизированного проектирования. Допускается и более широкая трактовка понятия методического обеспечения, при котором под ним понимается совокупность математического, лингвистического обеспечения и названных документов, реализующих правила использования средств проектирования.

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

Типовой пример № 1 проектных решений

Данный расчет электрических нагрузок кафе-закусочной, расположенное по адресу: г.Ростов-на-Дону ул.Малиновского, заказчик Иванов И. И. выполнен на основании СП31-110-2003 «Проектирование и монтаж электроустановок жилых и общественных зданий»; «Нормативов для определения расчетных электрических нагрузок зданий (квартир), коттеджей, микрорайонов(кварталов) застройки и элементов городской распределительной сети (Изменения и дополнения раздела 2 «Расчетные электрические нагрузки» Инструкции по проектированию городских электрических сетей РД 34.20.185-94»).

Данный расчет электрических нагрузок кафе-закусочной, расположенное по адресу: г.Ростов-на-Дону ул.Малиновского, заказчик Иванов И. И. выполнен на основании СП31-110-2003 «Проектирование и монтаж электроустановок жилых и общественных зданий»; «Нормативов для определения расчетных электрических нагрузок зданий (квартир), коттеджей, микрорайонов(кварталов) застройки и элементов городской распределительной сети (Изменения и дополнения раздела 2 «Расчетные электрические нагрузки» Инструкции по проектированию городских электрических сетей РД 34.20.185-94»).

Исходными данными для расчета нагрузок является задание заказчика.

Питающее напряжение 380/220 В .

Кафе является потребителем III -ей категории надежности электроснабжения.

Освещение помещений кафе выполнено светильниками с люминесцентными лампами общей мощностью: Руст = 2,1 кВт

Разработка принципов проектного решения

Submitted by MuHyc on Втр, 02/07/2012 - 21:38

Исходя из результатов анализа производственного потенциала, тенденций развития производительности и основных требований логистической концепции были приняты предварительные решения относительно принципа проектного решения. Это позволило уже заблаговременно поставить вопрос о выборе проектного решения и направлений работы, а также последствий этого и подвести реализуемые принципы проектного решения под последующие этапы проектирования. Как показывает практический опыт, этот важный этап разработки должен был опираться на знание научно обоснованных инновационных альтернативных принципов решения проблем заводского и цехового структурирования, на практический опыт применения аналогичных промышленных решений (с соответствующими ссылками), а также на критерии их реализуемости.

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

Для обеспечения реализации актуальных в данной ситуации задаваемых параметров (загрузка станочного оборудования, транспортно-складских операций, изменения в оперативном управлении), а также контроля хода производства было необходимо сформировать поток материалов и контейнеров таким образом, чтобы обеспечить его сквозной охват по времени и месту (идентификацию), а также адресность мест размещения палетных контейнеров.

Размер серии в год запуска проекта

Количество видов деталей

Затраты рабочего времени в год запуска проекта [в часах]

Основной ассортимент Аппараты

Аппарат системы X

Аппарат системы Y

Остальной ассортимент Отдельные детали

Илл. 8.12. Приблизительные значения основных показателей производственной программы заготовительного производства (год запуска проекта)

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

Исходя из целей рационализируемого объекта, в качестве решающих рассматривались следующие критерии выбора нового принципа проектного решения (1-й этап реконструкции):

• охват всего участка заготовительного производства (принцип целостности), включая интерфейсы предшествующих и последующих участ-ков,-

• применение инновационных систем материальных потоков, предусматривающих минимизацию потребности в площадях;

• возможность автоматизации части функций (сокращение операторских функций до предела);

• реализация компьютерного управления материальным потоком (применение систем планирования производства и сбора производственных данных);

• полное использование системных размеров производственного участка, намеченного к реализации;

• возможность использования имеющегося обрабатывающего оборудования и рабочих мест (смешанная система);

• обеспечение сжатия процесса (расширение производства на меньшей площади);

• пригодность системного решения к пошаговой реконструкции и расширению (увеличение производственной мощности, инвестиционные этапы — очереди реконструкции);

• обеспечение гибкости в условиях смены производственных задач (динамика производственной программы);

• применение системного решения, по которому имеется достаточный опыт использования (с соответствующими ссылками).

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

Основным принципом решения проблемы конфигурации по типу IGFA является взаимное размещение определенного количества станочных и/или ручных рабочих мест и центрально/периферийно размещенного складского комплекса (палетного склада); конфигурирование на выбранном уровне (автоматизация) транспортно-передаточных механизмов с учетом системных требований и наличия интерфейсов и целенаправленное управление этим производственным комплексом с помощью интегрированных систем планирования производства (PPS), включая устройства обратной связи.

Опираясь на указанные цели, критерии отбора и основные особенности организации производства по типу IGFA, в данном случае были рассмотрены альтернативные варианты организации производства по типу IGFA/«A» и IGFA/«B». Основной вариант «Б» был исключен из рассмотрения из-за непригодности решения проблемы материального потока. На илл. 8.13 приведены варианты решения для всего комплекса заготовительного производства (павильон шедового типа) по варианту IGFA/«A», а также по альтернативному варианту IGFA/«B», которые определяют принципиально возможное поле выбора принципа проектного решения.

При почти одинаковых инвестиционных затратах на оба проектных решения предварительный выбор был сделан в пользу решения по варианту IGFA/«B» (базисный вариант) в качестве дальнейшего направления работы. Тем самым была конкретизирована поставленная задача: произвести реконфигурацию всего участка заготовительного производства путем создания двух параллельных интегрированных производственных участков с автономными материальными потоками и управлением, придав им конфигурацию основного варианта IGFA/«B».

- Новое гибкое взаимное расположение оборудования

- Складской комплекс для выполнения всех заявок производства

- Ассортимент и взаимное расположение оборудования остаются сохраненными

- Площади цеха продолжают оставаться гибко загружаемыми (никаких новых фиксированных точек)

- Внедрение проектного решения (этап перестройки) не создает проблем — создание склада на периферийной площади

- Частичная перестройка в павильоне

- Необходима полная реконфигурация цеха (новая планировка)

- Ассортимент и новое взаимное расположение оборудования неизбежно ведут к прогрессивным изменениям (пересмотр технологии)

- Непосредственное взаимное расположение рабочих мест и стеллажей — не вызывающее проблем транспортное решение — в высокой степени принудительный характер перемещения

- Исключительно компактное с территориально-пространственной точки зрения проектное решение

- Наличие проверенных проектных решений управления

- Множество образцовых примеров подобных проектных решений (с соответствующими ссылками)

- Применение проверенных транспортно-складских технологий

- Единое направление главного материального потока

НОУ ИНТУИТ

Аннотация: Рассматривается понятие образца проектирования, классификация образцов проектирования и некоторые широко используемые примеры образцов анализа и архитектурных стилей.

Чем отличается работа опытного проектировщика программного обеспечения от работы новичка? Имеющийся у эксперта опыт позволяет ему аккуратнее определять задачи, которые необходимо решить, точнее выделять среди них наиболее важные и менее значимые, четче представлять ограничения, в рамках которых должна работать будущая система. Но важнее всего то, что эксперт отличается накопленными знаниями о приемлемых или неприемлемых в определенных ситуациях решениях, о свойствах программных систем, обеспечиваемых ими, и способностью быстро подготовить качественное решение сложной проблемы, опираясь на эти знания.

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

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

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

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

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

Другим примером такой ситуации является разработка набора тестов для некоторых операций. Хотелось бы, чтобы с помощью этого набора можно было бы тестировать любую возможную реализацию функций, выполняемых этими операциями. Если функции достаточно часто встречаются, например, совместно реализуют очередь. хранящую некоторые элементы, то такая возможность очень полезна. Но у каждого набора операций может быть свой интерфейс. переделывать все тесты под который слишком трудоемко.

Если можно представить набор требуемых операций как интерфейс некоторого класса в объектно-ориентированном языке программирования, достойно выйти из такой ситуации поможет образец проектирования адаптер (adapter) .

Рис. 7.1. Структура классов-участников образца "адаптер"

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

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

Образцы проектирования часто сильно связаны друг с другом в силу того, что они решают смежные задачи. Поэтому часто наборы связанных, поддерживающих друг друга образцов представляются вместе в виде систем образцов (pattern system) или языка образцов (pattern language). в которых указаны возникающие между ними связи и описываются ситуации, в которых полезно совместное использование нескольких образцов:

По типу решаемых задач выделяют следующие разновидности образцов.

• Образцы анализа (analysis patterns) .

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

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

В отличие от образцов проектирования и идиом (см. ниже), образцы анализа используются при концептуальном моделировании и не отражают прямо возможную реализацию такой модели в виде конкретного кода участвующих в ней классов. Например, поле X класса концептуальной модели в реализации может остаться полем, а может превратиться в пару методов getX() и setX() или в один метод getX() (т.е. в свойство, property. в терминах C# и JavaBeans ).

Лекция 9

Абстракция перенаправляет запросы клиента к одной из реализаций Implementora.

• реализация отделяется от интерфейса;

• чтобы заменить реализацию нет необходимости перекомпилировать абстракцию и ее клиента;

• система становится более легко модифицируемой.

Пример: Пусть есть абстракция Shape (форма), в ней есть операция draw(), отвечающая за отрисовку. В каждой конкретной форме (Rectangle, Circle) отрисовка реализуется с помощью примитивов drawLine(), drawCircle(), описанном в интерфейсе Drawing, реализуемом разными графическими пакетами DrawingV1, DrawingV2, рассчитанными на работу с разными графическими устройствами Driver1, Driver2. Диаграмма классов:

Если не применять образец, то у Rectangle и Circle могли бы быть два наследника, каждый из которых рассчитан на работу с одним из двух графических устройств. Т. е. в иерархии форм было бы 7 классов (см на рис. Shape, Rectangle, V1Rectangle, V2Rectangle, Circle, V1Circle, V2Circle).

RectangleV # drawLine() Если добавить ещё формы – наследницы Shape – Triangle, PolyLine, то в первом случае при их отрисовке дополнительные классы не нужны, так как можно воспользоваться реализациями Drawing. Во втором случае иерархия разрастается, в ней становится классов (добавляются Triangle, TriangleV1, TriangleV2, PolyLine, PolyLineV1, PolyLineV2).

Аналогично применение паттерна Мост выгодно при добавлении поддержки еще одного графического устройства Driver3. Будет достаточно добавить новую реализацию интерфейса Drawing – класс DrawingV3, вместо того, чтобы заводить каждой конкретной фигуре наследника с реализацией отрисовки для нового устройства (RectangleV3, CircleV3, TriangleV3, PolyLineV3).

том, чтобы предоставить точку входа в подсистему (или пакет) в виде прокси-класса.

Тем самым от внешних классов скрывается внутреннее устройство подсистемы или пакета, Client Facade уменьшается количество связей между Идея продемонстрирована на диаграмме классов справа.Без фасада клиентский класс подсистемы. Это означает, что эти классы подсистеме. Все это противоречит инкапсуляции, даёт клиенту много лишних сведений об устройстве подсистемы, снижает её модифицируемость, увеличивает количество связей между подсистемой и классами, использующими её.

Пример: подсистема BillingSystem системы регистрации на курсы реализует доступ к внешней расчетной системе. Прокси-класс скрывает детали подсистемы, реализует её интерфейс. Реализация операции заключается в формировании параметра для вызова метода BillingSystemInterface::submit(theTransaction) и самого вызова этой операции.

submitBill(forStudent. Student, forTuition. double) Диаграмма взаимодействия объектов при использовании образца Фасад.

1: submitBill(Student, double) Proxy (Заместитель) Классификация: структурный образец.

Назначение: для объекта создается суррогат, контролирующий доступ.

Мотивация: есть «тяжелый» класс, объекты которого разумно создавать по требованию – эта обязанность возлагается на легкие суррогаты.

• удаленный заместитель (тяжелый объект невыгодно перемещать с узла на узел, поэтому на другом узле его представляет заместитель);

• защищающий заместитель (проверяет права доступа).

Proxy – заместитель, хранящий ссылку на реальный объект;

Class_Client – клиентский класс;

Subject –общий интерфейс для класса и его заместителя;

RealClass – класс, для которого создается заместитель.

Заместитель получает запрос клиента и переадресует его реальному классу.

Детали взаимодействия зависят от вида заместителя. См. для защищающего заместителя:

Результаты (зависят от вида заместителя):

удаленный заместитель скрывает тот факт, что реальный объект находится на другом узле (можно экономить сетевой трафик, если создать локальный заместитель удаленного объекта с копиями часто используемых атрибутов);

виртуальный заместитель оптимизирует приложение («тяжелые» объекты создаются по требованию, пока в их создании нет необходимости, их представляют «легкие»

защищающий заместитель обеспечивает нужный режим доступа к объекту.

Цепочка обязанностей (Chain of Responsibility) Классификация: образец поведения.

Назначение: избежать привязки отправителя запроса к получателю, давая возможность передать запрос через многих (заранее неизвестно скольких) посредников.

• есть более одного объекта, способного обработать запрос, настоящий обработчик неизвестен и должен быть найден автоматически (передадим по цепочке, пока ктонибудь не обработает);

• адресат запроса не указан, но один из группы;

Handler – обобщенный обработчик, все специальные обработчики в цепочке являются его подклассами;

• ConcreteHandler – конкретный обработчик:

o обрабатывает запрос;

o знает следующего по цепочке;

o если может обработать – обрабатывает, иначе передает дальше.

• Client – отправляет запрос началу цепочки.

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

ослабляется связность (клиент связан лишь с началом цепочки);

гибкость в распределении обязанностей;

нет гарантий, что запрос будет обработан, может дойти до конца цепочки и пропасть.

Iterator (Итератор) Классификация: образец поведения.

Назначение: дать последовательный доступ к набору однородных объектов, не раскрывая его внутреннего представления.

Ситуация применимости: есть структура данных, для которой нужно реализовать один или несколько способов обхода – каждый осуществляется отдельным итератором.

• Iterator – общий интерфейс для доступа и обхода структуры данных;

• ConcreteIterator – o конкретный способ обхода;

o помнит позицию курсора (текущий элемент);

• Aggregate – интерфейс для создания итератора;

• ConcreteAggregate – реализация интерфейса Aggregate.

поддерживаются разные способы обхода;

упрощается интерфейс Aggregate;

есть возможность иметь одновременно несколько активных обходов (столько, сколько объектов-итераторов).

Strategy (Стратегия) Классификация: образец поведения.

Назначение: Определяет семейство алгоритмов, инкапсулирует каждый из них и делает их взаимозаменяемыми.

Узнайте, что такое Саентология.

Ваша жизнь поменяется.

Мотивация: есть несколько алгоритмов решения одной задачи, которые нежелательно «зашивать» в клиентский класс.

• Имеется много родственных классов, отличающихся только поведением.

• Необходимо иметь несколько разных реализаций одной операции.

• Нужно скрыть от клиента сложные, специфичные для алгоритма структуры данных.

• Упрощение кода метода, представляющего собой длинное ветвление или switch.

• Strategy – интерфейс общий для семейства алгоритмов;

• ConcreteStrategy – конкретная стратегия, реализующая интерфейс;

• Context – контекст, направляющий запросы клиента стратегиям;

Client – клиентский класс.

• Иерархия классов стратегий определяет семейство алгоритмов или поведений, которые можно повторно использовать.

• Инкапсуляция алгоритма в отдельный класс позволяет изменять его независимо от контекста.

• Избавляемся от if и switch (улучшаем читаемость кода).

• Интерфейс класса Strategy общий для всех подклассов ConcreteStrategy – неважно, сложна или тривиальна их реализация. Поэтому вполне вероятно, что некоторые стратегии не будут пользоваться всей передаваемой им информацией, особенно простые.

Приведем пример использования образца для реализации разных стратегий расчета налогов:

Предполагается, что объект класса Config сообщает SalesOrder ссылку на объекталгоритм расчета налогов (либо экземпляр USTax, пригодный для США, либо CanTax, пригодный для Канады). Если потребуется добавить новые способы расчета, достаточно добавить подклассы CalcTax. Обратите внимание, что в примере вместо интерфейса и реализации используется абстрактный класс и связи обобщения.

Альтернативой предложенному решению является внесение внутрь SalesOrder::calcTax() логики выбора схемы расчета и реализация расчетов в отдельных операциях SalesOrder. Модифицируемость такого решения ниже, чем при использовании образца.

Decorator (Декоратор) Классификация: структурный образец.

Назначение: добавление объекту новых обязанностей в динамике. Альтернатива подклассам.

Мотивация: Например, хотим, чтобы библиотека GUI могла добавлять свойства (рамку) или новое поведение (прокрутку) к любому элементу GUI. Для этого «оборачиваем» элемент GUI в объект-декоратор. Декоратор имеет тот же интерфейс. Он переадресует запросы элементу, который в него «завернут».

• для динамического, прозрачного для клиентов добавления обязанностей объектам;

• для реализации обязанностей, которые могут быть сняты с объекта;

• когда расширение путем порождения подклассов по каким-то причинам неудобно или невозможно.

• Component – интерфейс для декорируемых объектов;

• ConcreteComponent – класс декорируемых объектов;

• Decorator – декоратор, ссылающийся на декорируемый объект и определяющий интерфейс для декораторов, соответствующий интерфейсу Component;

• ConcreteDecorator – реализует какое-либо дополнительное поведение;

• Client – клиентский класс.

обязанности. Обязанности могут быть добавлены или выполнения программы. ConcreteComponent декораторов обеспечивает сочетание добавляемых общий интерфейс, они + addedBehaviour() Decorator::defaultMethod(); + addedBehaviour() • Получаемая система состоит из множества мелких объектов, которые похожи друг на друга. Проектировщик, разбирающийся в устройстве системы, может легко настроить ее, но постороннему изучать и отлаживать ее тяжело.

Рассмотрим пример, в котором для класса Ticket применены две обертки для печати с верхним и нижним колонтитулом. Диаграмма классов приведена выше.

Диаграмма коммуникации, демонстрирующая цепочку объектов, задействованных при печати билета:

Observer (Наблюдатель) Классификация: образец поведения.

Назначение: Определяет зависимость типа «один ко многим» между объектами так, что при изменении состояния одного объекта все зависящие от него оповещаются об этом и автоматически обновляются..

Мотивация: таблица и связанные диаграммы, «издатель» и «подписчики» и т. п..

• при модификации одного объекта требуется изменить другие и заранее неизвестно, сколько именно объектов нужно изменить;

• один объект должен оповещать других, не делая предположений об уведомляемых объектах.

• Observable – интерфейс наблюдаемых объектов, который предоставляет операции для присоединения и отделения наблюдателей;

• Observer – интерфейс наблюдателей с операциями для обновления наблюдающих объектов при изменении субъекта;

• ConcreteObservable – реализация наблюдаемых объектов;

• ConcreteObserver – реализация объектов-наблюдателей.

последовательности на следующей странице.

• Субъекту неизвестны конкретные классы наблюдателей. Связи между субъектами и наблюдателями сведены к минимуму.

• Последствия изменений в субъекте непредсказуемы. Безобидная, на первый взгляд, операция над субъектом может вызвать целый ряд обновлений наблюдателей и зависящих от них объектов.

Приведем пример использования образца для реализации оповещения при изменении данных о клиенте. Например, изменение состояния (State) может влиять на отправку писем клиенту. Если вызывается Customer::setState(), то в теле его метода срабатывает вызов Customer::notify(), при обработке которого будут вызваны операции update() у всех наблюдателей, подписавшихся на изменения в конкретном экземпляре класса Customer.

Менее подходящим решением является явный вызов операций нужных объектов из тела метода, обновляющего объект Customer, так как возникают явные зависимости между классами и помимо собственно обновления метод содержит реализацию посторонней бизнес-логики:

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

Литература к лекции Гамма Э. Хелм Р. Джонсон Р. Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – СПб. Питер, 2007.

Фаулер М. Архитектура корпоративных приложений. – М. Вильямс, 2007.

Дж. Кериевски. Рефакторинг с использованием шаблонов. – М. Вильямс, 2006 г.

Кулямин В. В. Технологии программирования. Компонентный подход. – М. Бином.

Лаборатория знаний. Фримен Э. Фримен Э. и др. Паттерны проектирования – СПб: Питер, 2011.

Главная >>История - Книги, пособия, учебники, издания, публикации. Cпециальность 07.00.00

«Кафедра отечественной истории и политологии ИГУ за 50 лет: люди, судьбы, книги Иркутск 2008 1 УДК 373 ББК 74.584 (2 Рос — 4 Ирк) 7 К 30 Редакционная коллегия: Зуляр Ю.А. д.и.н. профессор Иванов А.А. д.и.н. профессор Казарин В.Н. д.и.н. профессор Камынин Н.А. к.и.н. доцент Труфанова В.В. к.и.н. доцент Рецензенты: Дулов А.В. д.и.н. профессор Шалак А.В. д.и.н. профессор Кафедра отечественной истории и политологии ИГУ за 50 лет: люди, судьбы, книги: Биобиблиографический словарь. –. »

«Annotation http://ezoki.ru/ -Электронная библиотека по эзотерике Путь без пути — это новая книга о бесконечном непути, называемом Дао. Такие древние мудрецы Китая, как Лао-цзы, Чжуан-цзы и Ли-цзы, придали свою собственную уникальную форму тому, что не имеет формы. В этой книге, где написаны непринуждённые беседы современного просветлённого Учителя, Ошо, мы встречаемся с современным даосским мудрецом. Бхагаван Шри Раджниш Дао: путь без пути Беседа первая ВОЛЬНАЯ СМЕРТЬ Когда Ли-цзы закусывал на. »

«Харьковский национальный университет имени В. Н. Каразина Харьковское областное историко-археологическое общество L au r e a К 80-летию профессора Владимира Ивановича Кадеева Харьков Константа 2007 УДК 94(100)+902/904](082) ББК 63.3(0)я4+63.4я4 Л28 Главный редактор С. И. Посохов Редакционная коллегия: К. Ю. Бардола, С. В. Дьячков (отв. редактор), А. П. Мартемьянов, И. П. Сергеев, С. Б. Сорочан, Ю. И. Цитковская. Художник С. Э. Кулинич Издается по решению правления Харьковского областного. »

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

«2010 12 No.16 Это весёлое, лёгкое имя – Пушкин. (Пушкин в творчестве Андрея Битова и Беллы Ахмадулиной) Н. Ю. Буровцева/ Nataliya Burovtseva Department of Russian, Tamkang University (1799-1837). Abstract The classic writings and literary works about them are important part of literature.There is no doubt that Alexander Pushkin (1799-1837) is an important person in the interpretation of Russian literature. Not only many specialists in study of literature, but also the writers and poets all of. »

«СМИРНОВ МАКСИМ ГЕОРГИЕВИЧ ФИЛОСОФИЯ МАДХАВА САДАШИВА ГОЛВАЛКАРА Специальность: 09.00. 03 - история философии ДИССЕРТАЦИЯ на соискание ученой степени кандидата философских наук Научный руководитель – доктор философских наук, профессор Любутин К.Н Екатеринбург 2002 Оглавление ВВЕДЕНИЕ ГЛАВА I. СОВРЕМЕННАЯ ИНДИЙСКАЯ ФИЛОСОФИЯ. ТРАДИЦИИ ИНДУИЗМА И НЕОИНДУИЗМА § 1. ОСОБЕННОСТИ ИНДИЙСКОЙ ФИЛОСОФИИ § 2. ЭТАПЫ СТАНОВЛЕНИЯ И. »

«О. В. Марченко (Москва, РГГУ) Символика сердца в размышлениях Вяч. Иванова, В. Эрна и о. П. Флоренского: некоторые замечания О вещая душа моя! О, сердце, полное тревоги, О, как ты бьешься на пороге Как бы двойного бытия. (Ф.И. Тютчев) Нижеследующие заметки – попытка прояснить ряд моментов довольно известного, но, как представляется, весьма сложного, странного и даже загадочного, текста, принадлежащего перу Флоренского, сопровождаемого эпиграфом из Вяч. Иванова и посвященного их общему другу. »

«Глава I. ОБЩИЕ ПОЛОЖЕНИЯ Статья 1. Сельское поселение и его статус. 1. Муниципальное образование Новоспасское сельское поселение Заинского муниципального района Республики Татарстан наделено статусом сельского Поселения. 2. Официальное наименование муниципального образования – Новоспасское сельское Поселение Заинского муниципального района Республики Татарстан (далее – Поселение). 3. Муниципальное образование Новоспасское сельское поселение входит в состав Заинского муниципального района. »

«1 Новизна и новаторство. (Этюды о единстве людского рода и безграничности культурных контактов) Посвящается моей матери: Демченко Евгении Григорьевне. Предисловие: Предлагаемый вниманию непредубежднного читателя труд, являющийся итогом 40-летней научной деятельности его автора, точнее одного из направлений моей исследовательской деятельности, посвящен важнейшему вопросу истории человечества. Речь идт не о частных проблемах искусства введения читателя в курс истории знаний, а попытке изложить. »

«Марина Кузьмина Свет и тени Мемориала Комсомольск-на-Амуре 2009 год Эту книгу можно назвать исторической справкой об общественной организации. Можно назвать хроникой жизни и деятельности общественной организации. Во всяком случае, это попытка проследить судьбу одной отдельно взятой общественной организации, родившейся в послеперестроечный период и успешно выдержавшей испытания временем. 2 Кузьмина М.А. Свет и тени Мемориала. - Комсомольск-на-Амуре. – 2009. – 194 стр. с цв. вкл. © Кузьмина М.А. »

«Е. Н. АЛДАШОВА, А. Н. АЛДАШОВ ЗАЩИТА ЦЕРКВИ В РОССИЙСКОМ ЗАКОНОДАТЕЛЬСТВЕ КОНЦА ХV – ПЕРВОЙ ПОЛОВИНЫ XVII в. Православию с его многовековой историей, традициями, обычаями, культурой, а также значительным влиянием в современной России отведена особая роль. Главным для сегодняшнего дня становится решение проблемы: сможет ли православие стать одним из определяющих факторов стабильного развития страны, повлиять на расстановку политических сил, решить проблему мирного сосуществования различных. »

«Annotation Литературные критики высоко оценили простоту и парадоксальную многомерность текстов Павича, виртуозную эксцентричность формы. Они рассматривают Павича как знаковую фигуру современной прозы – писателя XXI века. Страшные любовные истории – сборник новых рассказов М.Павича, где каждая вещь делает нас соучастниками некоей магической игры, затеянной писателем. Излюбленные темы Павича – любовь, смерть, загадочные сны, прошлое – вновь звучат в его прозе. Милорад Павич Одиннадцатый палец. »

«БИОЛОГИЯ И ЭКОЛОГИЯ Судницына Д. Н. РАЗНООБРАЗИЕ ВОДОРОСЛЕЙ ОЗЁР И РЕК ПСКОВСКОЙ ОБЛАСТИ Известный русский географ П. П. Семенов-Тян-Шанский территорию Северо-Запада Русской равнины по праву называл озерным краем. Только на территории Псковской области располагается свыше 3700 озер общей площадью 3261 км2 (Лесненко, Абросов, 1973). Озера располагают огромными природными ресурсами, среди которых, в первую очередь, выделяются пресная вода и рыба. Качество воды и рыбные богатства во многом. »

«Мнемотехника шаг за шагом Курс дистанционного обучения Мнемотехника шаг за шагом состоит из пяти разных, но взаимосвязанных курсов, упражнения которых обеспечивают постепенное наращивание объема и сложности запоминаемого материала. Ниже вы можете ознакомиться с кратким описанием каждого учебного курса и с планами уроков. Интенсивный тренинг (вводный курс, 12 уроков). Детальная проработка отдельных приемов запоминания. Постепенное наращивание объема запоминаемой за раз информации до 100. »

«Суслов Вольт Николаевич Покладистый Ложкин (Стихи, рассказы, фельетоны) Вольт Николаевич Суслов СУСЛОВ ВОЛЬТ НИКОЛАЕВИЧ ПОКЛАДИСТЫЙ ЛОЖКИН Стихи, рассказы, фельетоны Содержание ОСОБОЕ ЛЕКАРСТВО ПЯТЁРКА ПО ЧТЕНИЮ ТЁПЛЫЕ СЛОВА В АДРЕС ТРОЕЧНИКА КРУТИТСЯ ДИСК ТЕЛЕФОННЫЙ ПОДЗАТЫЛЬНИК РАЗГОВОР КАК Я ДАЛ СЛОВО (Честный рассказ одного моего знакомого) ДВА СЛОНА, ЛУНА И ЗМЕИ МУХА АЛАТУРЫ А Я, РЕБЯТА, ТУТ ЖИВУ АЛЛО. УБЕДИТЕЛЬНО ПРОШУ ВАС. »

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ СИБИРСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ СИБИРСКИЙ ЭКСПЕРТНЫЙ КЛУБ МАКРОРЕГИОН СИБИРЬ: ПРОБЛЕМЫ И ПЕРСПЕКТИВЫ РАЗВИТИЯ Красноярск СФУ 2013 1 УДК 332.26+330.101.54 ББК 65.049+60.59 М168 А в т о р с к и й к о л л е к т и в: А. В. Усс, В. Л. Иноземцев, Е. А. Ваганов, А. З. Швиденко, В. С. Ефимов (отв. за вып.), А. В. Лаптева, П. М. Вчерашний, Н. Г. Типенко, А. Г. Коржубаев, В. А. Крюков, В. И. Нефёдкин, И. В. Семыкина, А. В. Ефимов, Е. Б. Бухарова, А. »

«Author: Юрченко Аркадий Васильевич Хронология событий. Ищу истину: 20.64-85. 20-й век. 1964-1985гг. При Брежневе, Анд ОТ ГЕОРГИЯ ПОБЕДОНОСЦА ДО РОМАНОВЫХ. (ХРОНОЛОГИЯ ИСТОРИЧЕСКИХ СОБЫТИЙ. ИЩУ ИСТИНУ) Содержание (Оглавление) 1.1.1. От автора. 1.1.2. Словарь. Значения древних слов, фраз и названий. 1.1.3. Великие люди мира и просто знаменитости. 1.2.1. Азбука кириллицы. Попытки прочтения. 1.2.2. О латинских и славянских языках. 1.2.3. О русской письменности. 1.2.4. Арабские надписи на русском. »

«ЕТНОПОЛІТИКА 225 УДК 323.12 А.Р. Никифоров, доцент, канд. ист. наук, Таврический национальный университет им. В.И. Вернадского пр. В.И. Вернадского, 4, г.Симферополь, 95007 E-mail: nandrey@bk.ru КРЫМСКОЕ РЕГИОНАЛЬНОЕ СООБЩЕСТВО В ТРЕХ ПРОЕКЦИЯХ И ИЗМЕРЕНИЯХ Предлагаются геополитический, исторический и социологический уровни измерения крымского регионального сообщества (КРС). Обосновывается вывод о латентном существовании КРС еще до периода его политического оформления в виде автономной. »

«Республика Шеврон—20 лет в Казахстане Республика Chevron—20 лет в Казахстане Июнь 2013 ©2013 Этот доклад подготовлен общественной организацией Crude Accountability, которая занимается вопросами защиты прав человека и охраны окружающей среды в Каспийском регионе и на черноморском побережье России. Организация сотрудничает с местным населением и общественностью, чьи права нарушаются в ходе разработки и транспортировки нефтегазовых ресурсов. Благодарность: Crude Accountability искренне благодарит. »

«УДК 316(059) В сборнике представлены статьи ведущих белорусских и российских социологов, посвященные актуальным проблемам развития белорусского общества, социальной теории, методологии и методикам социологических исследований. Рассчитан на студентов, аспирантов, профессиональных социологов, а также читательскую аудиторию, интересующуюся современным социальным развитием Беларуси. Р е д а к ц и о н н а я к о л л е г и я: И. В. Котляров (главный редактор), В. Л. Абушенко (зам. главного редактора). »