Лекция 5

и доп. — М.: Высш. шк., 2006. - 454 с.
Орлов

С.А.. Технологии разработки программного обеспечения. М.,ПИТЕР, 2002.-464с.
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб: Питер, 2001. — 368 с.: ил. (Серия «Библиотека программиста»)
Макконнелл С. Совершенный код. Мастер-класс / Пер. с англ. — М. : Издательско- торговый дом «Русская Редакция» ; СПб.: Питер, 2005. — 896 стр.:

анализ (Object Oriented Analysis);
объектно-ориентированное проектирование (Object Oriented Design);
объектно-ориентированное программирование (Object

Oriented Programming).

классов и объектов.
Результаты объектно-ориентированного анализа являются основой для проектирования

разрабатываемого ПС.
Этапы объектно-ориентированного анализа:
построение информационной модели. Целью этого этапа является определение всех объектов, которые составляют анализируемую систему, а также связей между ними;
построение модели состояний. Целью этого этапа является изучения поведения объектов анализируемой системы, выявленных на предыдущем этапе, во времени;
модель процессов. Каждое действие разбивается на несколько процессов.

объектной декомпозиции и приемы представления логической и физической, а также

статической и динамической моделей проектируемой системы.

Объектно-ориентированное программирование обеспечивает реализацию классов на выбранном языке программирования для получения конкретных результатов.

аудитория и последовательность восприятия
Масштаб проекта
Ссылки на источники
Общее описание
Видение продукта
Функциональность

продукта
Классы и характеристики пользователей
Среда функционирования продукта (операционная среда)
Рамки, ограничения, правила и стандарты
Документация для пользователей
Допущения и зависимости

Функциональность системы
Функциональный блок X (таких блоков может быть несколько)
Описание и приоритет
Причинно-следственные связи, алгоритмы (движение процессов, workflows)
Функциональные требования
Требования к внешним интерфейсам
Интерфейсы пользователя (UX)
Программные интерфейсы
Интерфейсы оборудования
Интерфейсы связи и коммуникации
Нефункциональные требования
Требования к производительности
Требования к сохранности (данных)
Критерии качества программного обеспечения
Требования к безопасности системы
Прочие требования
Приложение А: Глоссарий
Приложение Б: Модели процессов и предметной области и другие диаграммы
Приложение В: Список ключевых задач

of» иерархия).

определены в их общем классе. Термины «экземпляр класса» и «объект»

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

доступ к состоянию, но не изменяет его;
Итератор - доступ к

содержанию объекта по частям, в строго определенном порядке;
Конструктор - создает объект и инициализирует его состояние;
Деструктор - разрушает объект и освобождает занимаемую объектом память.

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

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

операции, отношения и семантику (смысл). Любой объект – это экземпляр

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

классов);
зависимость (отображает влияние одного класса на другой класс);
обобщение-специализация («is

а»-отношение);
целое-часть («part of»-отношение).

из трех типов:
один-к-одному;
один-ко-многим;
многие-ко-многим.

муж, а у европейского мужа одна жена;
у восточной жены

один муж, а у восточного мужа сколько угодно жен;
у заказа один клиент, а у клиента сколько угодно заказов;
человек может посещать сколько угодно зданий, а в здании может находиться сколько угодно людей.

поведение, определенные в одном другом (простое наследование) или во многих

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

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

Графически

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

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

операции из различных классов (но относящихся к общему суперклассу). Вызов

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

в виде трех взаимосвязанных моделей:
1) объектной модели, которая представляет

статические, структурные аспекты системы;
2) динамической модели, которая описывает работу отдельных частей системы;
3) функциональной модели, в которой рассматривается взаимодействие отдельных частей системы (как по данным, так и по управлению) в процессе ее работы.

с целью исключения схожих (синонимичных) понятий и уточнения имен, классификацию

объектов, выделение классов;
3) определение взаимосвязей между объектами;
4) определение атрибутов объектов и методов (определение уровней доступа и проектирование интерфейсов классов);
5) исследование качества модели.

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

обычных языках программирования;
3) выполнение программы заключается в создании объектов и передаче им последовательности сообщений.
Объектная модель базируется на четырех главных принципах: абстрагировании; инкапсуляции; модульности; иерархии.

процесс (даже если оно приводит к аккуратному результату)
Проектирование связано

с определением компромиссов и приоритетов
Проектирование подразумевает ограничение возможностей
Проектирование — недетерминированный процесс
Проектирование — эвристический процесс
Проектирование — постепенный процесс

классов, адаптированных для решения общей задачи проектирования в конкретном контексте.

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

проектирования, ее решения и их последствия. С помощью словаря паттернов

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

— назначение;
— известен также под именем;
— мотивация;
—

применимость;
— структура;
— участники;
— отношения;
— результаты;
— реализация;
— пример кода;
— известные применения;
— родственные паттерны .

процесс инстанцирования (создания экземпляра класса). Они позволяют сделать систему независимой

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

семейств, связанных между собой, или независимых объектов, конкретные классы которых

неизвестны.
2. Adapter {адаптер). Преобразует интерфейс класса в некоторый другой интерфейс, ожидаемый клиентами. Обеспечивает совместную работу классов, которая была бы невозможна без данного паттерна из-за несовместимости интерфейсов.
3. Bridge {мост). Отделяет абстракцию от реализации, благодаря чему появляется возможность независимо изменять то и другое.
4. Builder {строитель). Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.
5. Chain of Responsibility {цепочка обязанностей). Можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.
6. Command {команда). Инкапсулирует запрос в виде объекта, позволяя тем самым параметризовывать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций.

представления иерархий типа «часть-целое». Позволяет клиентам работать с единичными объектами

так же, как с группами объектов.
8. Decorator {декоратор). Динамически возлагает на объект новые функции. Декораторы применяются для расширения имеющейся функциональности и являются гибкой альтернативой порождению подклассов.
9. Facade {фасад). Предоставляет унифицированный интерфейс к множеству интерфейсов в некоторой подсистеме. Определяет интерфейс более высокого уровня, облегчающий работу с подсистемой.
10. Factory Method {фабричный метод). Определяет интерфейс для создания объектов, при этом выбранный класс инстанцируется подклассами.
11. Flyweight {приспособленец). Использует разделение для эффективной поддержки большого числа мелких объектов.
12. Interpreter {интерпретатор). Для заданного языка определяет представление его грамматики, а также интерпретатор предложений языка, использующий это представление.

составного объекта, не раскрывая его внутреннего представления.
14. Mediator {посредник).

Определяет объект, в котором инкапсулировано знание о том, как взаимодействуют объекты из некоторого множества. Способствует уменьшению числа связей между объектами, позволяя им работать без явных ссылок друг на друга. Это, в свою очередь, дает возможность независимо изменять схему взаимодействия.
15. Memento {хранитель). Позволяет, не нарушая инкапсуляции, получить и сохранить во внешней памяти внутреннее состояние объекта, чтобы позже объект можно было восстановить точно в таком же состоянии.
16. Observer {наблюдатель). Определяет между объектами зависимость типа «один ко многим», так что при изменении состояния одного объекта все зависящие от него получают извещение и автоматически обновляются.
17. Prototype {прототип). Описывает виды создаваемых объектов с помощью прототипа и создает новые объекты путем его копирования.
18. Proxy {заместитель). Подменяет другой объект для контроля доступа к нему.

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

20. State {состояние). Позволяет объекту варьировать свое поведение при изменении внутреннего состояния. При этом создается впечатление, что поменялся класс объекта.
21. Strategy {стратегия). Определяет семейство алгоритмов, инкапсулируя их все и позволяя подставлять один вместо другого. Можно менять алгоритм независимо от клиента, который им пользуется.
22. Template Method {шаблонный метод). Определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры.
23. Visitor {посетитель). Представляет операцию, которую надо выполнить над элементами объекта. Позволяет определить новую операцию, не меняя классы элементов, к которым он применяется.

использование решений из уже завершенных успешных проектов позволяет быстро приступить

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

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

собственный интерфейс обращения к ней
Задача Необходимо использовать только определенное подмножество

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

повторного использования
Высокий коэффициент объединения по входу
Низкий или средний коэффициент разветвления

по выходу
Портируемость
Минимальная, но полная функциональность
Стратификация
Соответствие стандартным методикам
Уровни проектирования

зависимостей от ОС

если оно упрощает проектирование
Используйте сокрытие информации
Определите области вероятных изменений
Поддерживайте сопряжение

слабым
Старайтесь использовать популярные шаблоны проектирования