Объектно-ориентированное проектирование ПС (часть 2) - презентация, доклад, проект скачать

Нажмите для полного просмотра!

Объектно-ориентированное проектирование ПС (часть 2), слайд №1

Объектно-ориентированное проектирование ПС (часть 2), слайд №2

Объектно-ориентированное проектирование ПС (часть 2), слайд №3

Объектно-ориентированное проектирование ПС (часть 2), слайд №4

Объектно-ориентированное проектирование ПС (часть 2), слайд №5

Объектно-ориентированное проектирование ПС (часть 2), слайд №6

Объектно-ориентированное проектирование ПС (часть 2), слайд №7

Объектно-ориентированное проектирование ПС (часть 2), слайд №8

Объектно-ориентированное проектирование ПС (часть 2), слайд №9

Объектно-ориентированное проектирование ПС (часть 2), слайд №10

Объектно-ориентированное проектирование ПС (часть 2), слайд №11

Объектно-ориентированное проектирование ПС (часть 2), слайд №12

Объектно-ориентированное проектирование ПС (часть 2), слайд №13

Объектно-ориентированное проектирование ПС (часть 2), слайд №14

Объектно-ориентированное проектирование ПС (часть 2), слайд №15

Объектно-ориентированное проектирование ПС (часть 2), слайд №16

Объектно-ориентированное проектирование ПС (часть 2), слайд №17

Объектно-ориентированное проектирование ПС (часть 2), слайд №18

Объектно-ориентированное проектирование ПС (часть 2), слайд №19

Объектно-ориентированное проектирование ПС (часть 2), слайд №20

Объектно-ориентированное проектирование ПС (часть 2), слайд №21

Объектно-ориентированное проектирование ПС (часть 2), слайд №22

Объектно-ориентированное проектирование ПС (часть 2), слайд №23

Объектно-ориентированное проектирование ПС (часть 2), слайд №24

Объектно-ориентированное проектирование ПС (часть 2), слайд №25

Объектно-ориентированное проектирование ПС (часть 2), слайд №26

Объектно-ориентированное проектирование ПС (часть 2), слайд №27

Объектно-ориентированное проектирование ПС (часть 2), слайд №28

Объектно-ориентированное проектирование ПС (часть 2), слайд №29

Объектно-ориентированное проектирование ПС (часть 2), слайд №30

Объектно-ориентированное проектирование ПС (часть 2), слайд №31

Объектно-ориентированное проектирование ПС (часть 2), слайд №32

Объектно-ориентированное проектирование ПС (часть 2), слайд №33

Объектно-ориентированное проектирование ПС (часть 2), слайд №34

Объектно-ориентированное проектирование ПС (часть 2), слайд №35

Объектно-ориентированное проектирование ПС (часть 2), слайд №36

Объектно-ориентированное проектирование ПС (часть 2), слайд №37

Объектно-ориентированное проектирование ПС (часть 2), слайд №38

Объектно-ориентированное проектирование ПС (часть 2), слайд №39

Объектно-ориентированное проектирование ПС (часть 2), слайд №40

Объектно-ориентированное проектирование ПС (часть 2), слайд №41

Объектно-ориентированное проектирование ПС (часть 2), слайд №42

Объектно-ориентированное проектирование ПС (часть 2), слайд №43

Объектно-ориентированное проектирование ПС (часть 2), слайд №44

Объектно-ориентированное проектирование ПС (часть 2), слайд №45

Объектно-ориентированное проектирование ПС (часть 2), слайд №46

Объектно-ориентированное проектирование ПС (часть 2), слайд №47

Объектно-ориентированное проектирование ПС (часть 2), слайд №48

Объектно-ориентированное проектирование ПС (часть 2), слайд №49

Объектно-ориентированное проектирование ПС (часть 2), слайд №50

Объектно-ориентированное проектирование ПС (часть 2), слайд №51

Объектно-ориентированное проектирование ПС (часть 2), слайд №52

Объектно-ориентированное проектирование ПС (часть 2), слайд №53

Объектно-ориентированное проектирование ПС (часть 2), слайд №54

Объектно-ориентированное проектирование ПС (часть 2), слайд №55

Объектно-ориентированное проектирование ПС (часть 2), слайд №56

Объектно-ориентированное проектирование ПС (часть 2), слайд №57

Объектно-ориентированное проектирование ПС (часть 2), слайд №58

Объектно-ориентированное проектирование ПС (часть 2), слайд №59

Объектно-ориентированное проектирование ПС (часть 2), слайд №60

Объектно-ориентированное проектирование ПС (часть 2), слайд №61

Объектно-ориентированное проектирование ПС (часть 2), слайд №62

Объектно-ориентированное проектирование ПС (часть 2), слайд №63

Объектно-ориентированное проектирование ПС (часть 2), слайд №64

Объектно-ориентированное проектирование ПС (часть 2), слайд №65

Объектно-ориентированное проектирование ПС (часть 2), слайд №66

Объектно-ориентированное проектирование ПС (часть 2), слайд №67

Объектно-ориентированное проектирование ПС (часть 2), слайд №68

Объектно-ориентированное проектирование ПС (часть 2), слайд №69

Объектно-ориентированное проектирование ПС (часть 2), слайд №70

Объектно-ориентированное проектирование ПС (часть 2), слайд №71

Объектно-ориентированное проектирование ПС (часть 2), слайд №72

Объектно-ориентированное проектирование ПС (часть 2), слайд №73

Объектно-ориентированное проектирование ПС (часть 2), слайд №74

Объектно-ориентированное проектирование ПС (часть 2), слайд №75

Объектно-ориентированное проектирование ПС (часть 2), слайд №76

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Объектно-ориентированное проектирование ПС (часть 2). Доклад-сообщение содержит 76 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

Объектно-ориентированное проектирование ПС (часть 2) Лекция 8

Слайд 2

Описание слайда:

Шаблон Controller Проблема Кто должен отвечать за обработку системных сообщений? Решение Обязанности по обработке системных сообщений назначаются классу, который: представляет систему в целом; представляет сценарий некоторого прецедента, в рамках которого обрабатываются системные сообщения

Слайд 3

Описание слайда:

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

Слайд 4

Описание слайда:

1-Й ВАРИАНТ Все системные операции выполняются одним внешним контроллером

Слайд 5

Описание слайда:

2-Й ВАРИАНТ Системные операции распределены между несколькими контроллерами прецедента

Слайд 6

Описание слайда:

Выбор варианта Выбор между вариантом использования внешнего контроллера (facade controller) и вариантом контроллеров прецедентов определяется, в основном требованиями соблюдения малой степени сцепления и высокой связности

Слайд 7

Описание слайда:

РЕАЛИЗАЦИЯ ПРЕЦЕДЕНТА «ОФОРМЛЕНИЕ ПРОДАЖИ» Реализация прецедента показывает, как определенный прецедент представляется в рамках модели проектирования в терминах взаимодействующих объектов

Слайд 8

Описание слайда:

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

Слайд 9

Описание слайда:

Прецедент «Оформление продажи» На текущей итерации рассмотрены следующие системные события и соответствующие операции: Начать оформление покупки (makeNewSale) Ввести данные товара (enterItem) Завершить оформление покупки (endSale) Оформить платеж (makePayment) Для наглядности каждая операция будет представлена отдельной диаграммой

Слайд 10

Описание слайда:

Операция makeNewSale Операция makeNewSale() Ссылки Прецеденты: Оформление продажи Предусловия Отсутствуют Постусловия Создан экземпляр s класса Sale Экземпляр s связан с объектом класса Registor Установлены атрибуты экземпляра s

Слайд 11

Описание слайда:

Диаграмма последовательности

Слайд 12

Описание слайда:

Операция enterItem Операция enterItem(iID: ItemID, quantity: integer) Ссылки Прецеденты: Оформление продажи Предусловия Инициирована продажа Постусловия Создан экземпляр sli класса SalesLineItem Экземпляр sli связан с объектом класса Sale Атрибуту sli.quantity присвоено значение quantity Экземпляр sli связан с классом ProductSpecification

Слайд 13

Описание слайда:

Обработка enterItem Ранее было установлено, что объект Sale должен создаваться объектом Registor Объект Sale создает объект SalesLineItem и добавляет его в свой контейнер Затем необходимо получить описание товара ProductSpecification для экземпляра SalesLineItem Кто должен поставлять эту информацию?

Слайд 14

Описание слайда:

Класс ProductCatalog На основе анализа предметной области и в соответствии с шаблоном Expert эта обязанность должна быть назначена классу ProductCatalog Этот класс должен содержать коллекцию экземпляров класса ProductSpecification Запрос на получение описания товара должен отправлять объект Register

Слайд 15

Описание слайда:

Диаграмма кооперации

Слайд 16

Описание слайда:

Операция endSale Операция endSale() Ссылки Прецеденты: Оформление продажи Предусловия Инициирована продажа Постусловия Атрибуту isComplete экземпляра класса Sale присвоено значение true

Слайд 17

Описание слайда:

Диаграмма кооперации

Слайд 18

Описание слайда:

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

Слайд 19

Описание слайда:

Операция makePayment Операция makePayment(amount: Money) Ссылки Прецеденты: Оформление продажи Предусловия Инициирована продажа Постусловия Создан экземпляр p класса Payment Экземпляр p связан с объектом класса Sale Атрибуту amountTendered присвоено значение amount Экземпляр Sale связан с экземпляром класса Store для его добавления в журнал продаж

Слайд 20

Описание слайда:

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

Слайд 21

Описание слайда:

Регистрация покупки

Слайд 22

Описание слайда:

Вычисление сдачи В роли частичных экспертов могут выступать объекты классов: Sale (информация о полной стоимости) Payment (информация о внесенной покупателем сумме) Экземпляр класса Sale является создателем объекта класса Payment и может запросить у него сумму платежа

Слайд 23

Описание слайда:

Вычисление сдачи

Слайд 24

Описание слайда:

РЕАЛИЗАЦИЯ ПРЕЦЕДЕНТА «ЗАПУСК СИСТЕМЫ» Практически все системы включают прецедент «Запуск системы» и системную операцию, связанную с запуском приложения

Слайд 25

Описание слайда:

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

Слайд 26

Описание слайда:

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

Слайд 27

Описание слайда:

Выбор исходного объекта В качестве исходного выбирается объект, наиболее приближенный к корню иерархии объектов В нашем случае это может быть Register либо Store Исходя из требования высокой степени связности, выберем объект Store

Слайд 28

Описание слайда:

Операция StartUp Операция StartUp() Ссылки Прецеденты: Запуск системы Предусловия Отсутствуют Постусловия Создан экземпляр класса Store Создан экземпляр pc класса ProductCatalog Экземпляр pc связан с экземпляром класса Store Создан экземпляр ps класса ProductSpecification Экземпляр ps связан с объектом класса Product Catalog

Слайд 29

Описание слайда:

Операция StartUp Постусловия (продолжение) Создан экземпляр класса Register Экземпляр класса Store связан с экземпляром класса Register Экземпляр pc связан с экземпляром класса Register

Слайд 30

Описание слайда:

Диаграмма кооперации

Слайд 31

Описание слайда:

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

Слайд 32

Описание слайда:

Связь уровней приложения

Слайд 33

Описание слайда:

СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ

Слайд 34

Описание слайда:

Идентификация классов На основе анализа диаграмм взаимодействия можно выделить следующие классы: Register Sale ProductCatalog ProductSpecification SalesLineItem Store Payment

Слайд 35

Описание слайда:

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

Слайд 36

Описание слайда:

Методы классов

Слайд 37

Описание слайда:

Ассоциации и навигация Линии связи и навигации устанавливаются на основе анализа диаграмм взаимодействия Такие ассоциации интерпретируются как видимость целевого класса для класса-источника, обеспечиваемая с помощью атрибутов (атрибут класса-источника является ссылкой на экземпляр целевого класса)

Слайд 38

Описание слайда:

Ассоциации между классами

Слайд 39

Описание слайда:

Отношения зависимости Означает наличие у одного из классов информации о другом классе Изображается пунктирной линией Объект класса Register получает информацию об объекте класса ProductSpecification в виде возвращаемого значения метода getSpecification, а объект класса Sale – через параметр метода makeLineItem

Слайд 40

Описание слайда:

РЕАЛИЗАЦИЯ И ТЕСТИРОВАНИЕ

Слайд 41

Описание слайда:

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

Слайд 42

Описание слайда:

Порядок реализации классов Классы нужно реализовывать и тестировать в рамках модулей, начиная с минимально сцепленных В нашем проекте это классы Payment и ProductSpecification Затем реализуются классы со все большей степенью сцепления Примеры реализации

Слайд 43

Описание слайда:

Вариант последовательности реализации

Слайд 44

Описание слайда:

Тестирование модулей Осуществляется с использованием утилит модульного тестирования (NUnit, JUnit и т.д.) Широко используемой является практика программирования на основе тестирования, когда тесты пишутся до написания кода Тем самым обеспечивается тотальный и неформальный характер тестирования

Слайд 45

Описание слайда:

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

Слайд 46

Описание слайда:

Переход к новой итерации

Слайд 47

Описание слайда:

ВТОРАЯ ИТЕРАЦИЯ

Слайд 48

Описание слайда:

Задачи Реализация поддержки внешних служб (начисление налоговых платежей) Сложные правила вычисления стоимости Подключаемые бизнес-правила

Слайд 49

Описание слайда:

Задача1: Поддержка внешних служб Каждая из систем начисления налоговых платежей имеет собственный интерфейс и обладает собственным поведением Необходимо обеспечить возможность подключения разрабатываемой системы к любой из систем начисления налоговых платежей

Слайд 50

Описание слайда:

Шаблон Adapter Проблема Как обеспечить взаимодействие с различными внешними системами? Решение Преобразовать интерфейс внешней системы к другому виду с помощью промежуточного объекта-адаптера

Слайд 51

Описание слайда:

Пример

Слайд 52

Описание слайда:

Шаблон Factory Проблема Какой класс должен отвечать за создание объектов-адаптеров? Как определять тип создаваемого адаптера? Решение Создать искусственный (не представляющий понятия предметной области) объект и назначить ему группу обязанностей по созданию других объектов

Слайд 53

Описание слайда:

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

Слайд 54

Описание слайда:

Объект-фабрика

Слайд 55

Описание слайда:

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

Слайд 56

Описание слайда:

Шаблон Singleton Использование объекта-фабрики порождает новую проблему проектирования – кто должен создавать саму фабрику и как получить к ней доступ? При этом очевидно, что в рамках приложения нужен всего лишь один экземпляр фабрики, доступ к которому возможен для любых объектов

Слайд 57

Описание слайда:

Шаблон Singleton Проблема Как обеспечить взаимодействие с объектом-фабрикой различных объектов системы, используя при этом единственную точку доступа? Решение Определить статический метод класса, возвращающий объект-фабрику

Слайд 58

Описание слайда:

Шаблон Singleton

Слайд 59

Описание слайда:

Реализация метода getInstance() // статический метод public static synchronized ServicesFactory getInstance( ) { if (instance == null) instance = new ServicesFactory( ); return instance; }

Слайд 60

Описание слайда:

Пример обращения к объекту-фабрике public class Register { public void initialize ( ) { …выполняем необходимые действия // обращаемся к объекту-фабрике через вызов // статического метода getInstance ( ) ServicesFactory. getInstance ( ). getAccountAdapter(); …выполняем необходимые действия } // другие методы }

Слайд 61

Описание слайда:

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

Слайд 62

Описание слайда:

Шаблон Strategy Проблема Как спроектировать надежные, но изменяемые алгоритмы (стратегии)? Каким способом вносить изменения? Решение Определить для каждого алгоритма отдельный класс со стандартным интерфейсом

Слайд 63

Описание слайда:

Шаблон Strategy

Слайд 64

Описание слайда:

Терминология Объекты классов, реализующих различные стратегии называются объектами стратегий Объект, к которому применяется варьируемый алгоритм называется контекстным объектом В нашем примере контекстным объектом является объект класса Sale

Слайд 65

Описание слайда:

Взаимодействие объекта-стратегии с объектом Sale При отправке объекту класса Sale сообщения getTotal он делегирует часть своих задач объекту стратегии При этом контекстный объект передает объекту стратегии ссылку на самого себя (this) для обеспечения параметрической видимости

Слайд 66

Описание слайда:

Взаимодействие объекта-стратегии с объектом Sale

Слайд 67

Описание слайда:

Создание объектов стратегий Так же, как и в случае адаптеров, создание объектов стратегий следует осуществлять на основе шаблона Factory Единственный объект-фабрика должен получать и выполнять запрос на создание объекта стратегии определенного типа

Слайд 68

Описание слайда:

Фабрика стратегий

Слайд 69

Описание слайда:

Создание объекта стратегии

Слайд 70

Описание слайда:

Почему две фабрики «Каждому виду объектов своя фабрика» – такой подход позволяет понизить степень связанности в системе Объект-фабрика ServicesFactory имеет дело только с объектами-адаптерами, а объект-фабрика PricingStrategyFactory – с объектами-стратегиями

Слайд 71

Описание слайда:

Задача 3:Подключение бизнес-правил Требуется подключить правила, отменяющие некоторые действия, например: при наличии подарочного сертификата может быть приобретен только один товар – все операции enterItem, кроме первой должны быть отменены; при проведении благотворительной акции могут приобретаться товары стоимостью не выше некоторой пороговой

Слайд 72

Описание слайда:

Генератор правил Реализацию тех или иных бизнес-правил целесообразно выделить в особую подсистему – «генератор правил» Правила и их реализация подвержены частым изменениям, поэтому связывание с этой подсистемой должно быть минимальным

Слайд 73

Описание слайда:

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

Слайд 74

Описание слайда:

Шаблон Facade В данном случае можно определить подсистему «генератор правил», которую можно реализовать либо на основе шаблона Strategy, либо с помощью интерпретатора правил, считывающих и интерпретирующих набор правил if – then Фасадный объект для такой подсистемы можно назвать RuleEngineFacade

Слайд 75

Описание слайда:

Пример обращения к объекту фасада public class Sale { public void makeLineItem ( ) { SalesLineItem sli = new SalesLineItem (spec, quant); // обращение к фасадному объекту if (RuleEngineFacade.getInstance( ).isInvalid(sli, this)) return; lineItems.add(sli); } // другие методы }