Презентация Объектно-ориентированное проектирование ПС онлайн
На нашем сайте вы можете скачать и просмотреть онлайн доклад-презентацию на тему Объектно-ориентированное проектирование ПС абсолютно бесплатно. Урок-презентация на эту тему содержит всего 96 слайдов. Все материалы созданы в программе PowerPoint и имеют формат ppt или же pptx. Материалы и темы для презентаций взяты из открытых источников и загружены их авторами, за качество и достоверность информации в них администрация сайта не отвечает, все права принадлежат их создателям. Если вы нашли то, что искали, отблагодарите авторов - поделитесь ссылкой в социальных сетях, а наш сайт добавьте в закладки.
Оцените презентацию от 1 до 5 баллов!
- Тип файла:ppt / pptx (powerpoint)
- Всего слайдов:96 слайдов
- Для класса:1,2,3,4,5,6,7,8,9,10,11
- Размер файла:1.69 MB
- Просмотров:69
- Скачиваний:0
- Автор:неизвестен
Слайды и текст к этой презентации:
№1 слайд
Содержание слайда: Объектно-ориентированное проектирование ПС
Лекция 7
№2 слайд
Содержание слайда: Способы декомпозиции системы
Функциональная декомпозиция– на основе потока данных с выделением обрабатывающих функций
Объектная декомпозиция – на основе выделения сущностей, обладающих собственными наборами данных, состояниями и наборами операций
№3 слайд
Содержание слайда: Способы декомпозиции системы
В первом случае внимание концентрируется на порядке происходящих событий (действиях)
Во втором – на агентах, являющихся либо объектами, либо субъектами действий
№4 слайд
Содержание слайда: Структурные единицы
Основной структурной единицей при функциональной декомпозиции является процедура, как программная реализация алгоритма
Основной структурной единицей при объектно-ориентированной декомпозиции является объект как объединение данных и действий над ними
№5 слайд
Содержание слайда: Начало проектирования
Результаты анализа предметной области представляются в виде диаграммы прецедентов с описанием прецедентов
Следующий шаг – создание концептуальной модели разрабатываемой системы, т.е. описание ее в терминах предметной области
№6 слайд
Содержание слайда: Ключевые абстракции
В концептуальной модели используются ключевые абстракции предметной области
Ключевая абстракция - это класс или объект, который входит в словарь проблемной области
№7 слайд
Содержание слайда: Выделение объектов
Ключевые абстракции определяют границы системы: выделяют то, что входит в нее и важно для нас, а также устраняют все лишнее
На более поздних этапах проектирования большинство ключевых абстракций будут отображены в программные классы
№8 слайд
Содержание слайда: ПРЕЦЕДЕНТЫ И ТРЕБОВАНИЯ
№9 слайд
Содержание слайда: Требования
Уточним понятие прецедента и его связь с понятием «требования к программной системе»
Требования (requirements) – это возможности или условия, которым должна удовлетворять разрабатываемая система
№10 слайд
Содержание слайда: Требования и риски
№11 слайд
Содержание слайда: Формулировка требований
Требования к системе могут быть представлены в виде списка кратких утверждений типа: «система должна обеспечивать выполнение такой-то операции»
Такой подход связан, по крайней мере, с двумя недостатками:
нечеткостью формулировки требований,
неполнотой их списка
№12 слайд
Содержание слайда: Формулировка требований
Для описания функциональных требований к системе был предложен подход, основанный на использовании прецедентов (Ivar Jacobson, 1986)
Прецедент (use case) – это описание способа использования системы с целью получения некоторого результата, значимого для исполнителя
№13 слайд
Содержание слайда: Прецедент и сценарии
Прецедент однозначно связан с результатом, но достижение одного и того же результата может происходить разными путями, в зависимости от тех или иных условий
Конкретная последовательность действий или взаимодействий между системой и исполнителем в рамках одного прецедента называется сценарием (scenario)
№14 слайд
Содержание слайда: Прецедент и сценарии
Таким образом, прецедент – это набор различных сценариев использования системы для получения одного и того же значимого результата
Сценарий, реализующийся с наибольшей вероятностью, называется основным, а остальные сценарии – альтернативными
№15 слайд
Содержание слайда: Исполнитель
Под исполнителем (actor) в предыдущих определениях понималась некоторая сущность, обладающая поведением (человек или организация, представленные ролью, или компьютерная система)
№16 слайд
Содержание слайда: ПРИМЕР РАЗРАБОТКИ
Это т пример описан в книге Крэга Лармана «Применение UML и шаблонов проектирования»
№17 слайд
Содержание слайда: Постановка задачи
Разработать программное обеспечение для системы организации товарооборота и обработки платежей в магазинах розничной торговли
№18 слайд
Содержание слайда: Модель разработки
Разработка системы будет вестись в рамках модели RUP - адаптивного итеративного процесса с постепенным наращиванием функциональности ПС и уточнением требований посредством механизма обратной связи
№19 слайд
Содержание слайда: Фазы процесса разработки
Начало – анализ проблемы, формирование представлений о функциях системы и основных требованиях к ней
Развитие –реализация базовой части системы и уточнение требований; осуществляется через последовательность итераций
№20 слайд
Содержание слайда: Фазы процесса разработки
Конструирование – разработка системы в полном объеме и окончательная формулировка требований; осуществляется через последовательность итераций, каждая из которых завершается созданием релиза
Внедрение – развертывание системы и бета-тестирование
№21 слайд
Содержание слайда: ЭТАП НАЧАЛО
Основные задачи:
формирование представления о проекте
формулирование исходных требований к системе
оценка стоимости проекта
идентификация основных рисков
№22 слайд
Содержание слайда: Анализ предметной области
Предметная область – ро́зничная торго́вля (англ. retail)
Что делается – производится продажа товаров конечному потребителю (частному лицу)
Как делается – покупатель отбирает необходимые ему товары и производит оплату в кассе
№23 слайд
Содержание слайда: Анализ предметной области
Где делается – основным предприятием розничной торговли является магазин (дискаунтер, универмаг, универсам и т.д.)
Кто делает – субъектами процесса розничной торговли являются продавец (менеджер торгового зала, кассир) и покупатель
№24 слайд
Содержание слайда: Анализ предметной области
Когда делается – каждый магазин имеет фиксированный график работы
Зачем делается – розничная торговля обеспечивает удовлетворение потребностей населения в товарах различного назначения и получение торговой прибыли
№25 слайд
Содержание слайда: Проблемы
Низкая скорость выполнения операции оплаты покупок
Ошибки кассиров при подсчете стоимости товаров и расчете с покупателями
Сложность ведения учета проданных товаров
Большие объемы работ по подготовке данных для системы анализа
№26 слайд
Содержание слайда: Пути решения
Создание компьютеризированной системы оплаты покупок Point-Of-Sale (POS-система)
Интеграция этой системы с существующими компьютерными системами поддержки торговой деятельности – системой складского учета, системой анализа торговой деятельности, бухгалтерской системой
№27 слайд
Содержание слайда: POS-терминал
POS-система реализуется в виде набора POS-терминалов
Каждый POS-терминал представляет собой программно-аппаратный комплекс, установленный на месте, где кассир осуществляет прием платежей от клиентов (АРМ кассира)
№28 слайд
Содержание слайда: Аппаратная часть
Аппаратная часть POS-терминала включает:
системный блок ПК,
фискальный регистратор,
POS-монитор кассира,
денежный ящик,
программируемую клавиатуру,
считыватель карт,
считыватель штрих-кодов
№29 слайд
Содержание слайда: Фискальный регистратор
Фискальный регистратор (ФР) – это устройство, обеспечивающее не корректируемую ежесуточную или ежесменную регистрацию наличных денежных расчетов и энергонезависимое долговременное хранение итоговой информации
Он сохраняет результаты продаж в фискальной памяти в течение всего срока его эксплуатации, а также распечатывает чеки покупателя.
№30 слайд
Содержание слайда: Аппаратная часть POS-терминала
№31 слайд
Содержание слайда: Интерфейс пользователя
POS-терминал должен иметь интерфейс взаимодействия с пользователем для
поиска нужного товара и получения его характеристик;
формирования и печати чеков;
подсчета сдачи;
выполнения различных отчетов
№32 слайд
Содержание слайда: Определение границ системы
Границы системы проще всего определить установив основных исполнителей, потребности которых удовлетворяются данной системой
Для этого надо ответить на вопросы:
Кто будет снабжать систему информацией?
Кто будет получать информацию от системы?
Кто будет осуществлять поддержку и обслуживание системы?
Использует ли система внешние ресурсы?
№33 слайд
Содержание слайда: Границы системы
№34 слайд
Содержание слайда: Основные исполнители
Кассир
оформляет продажи,
выполняет возврат товара,
регистрирует выручку;
Системный администратор
редактирует список пользователей,
управляет безопасностью;
№35 слайд
Содержание слайда: Основные исполнители
Менеджер
включает систему,
выключает систему
Система анализа торговой деятельности
анализирует информацию о продажах и оценивает производительность
№36 слайд
Содержание слайда: Прецеденты
Следует иметь в виду, что прецеденты могут быть определены на разных уровнях детализации
При анализе требований следует сосредоточить внимание на уровне элементарных бизнес-процессов, т.е. задач достаточно высокого уровня
Основной сценарий таких прецедентов содержит 5 – 10 шагов
№37 слайд
Содержание слайда: Прецеденты для POS-системы
Включение системы
Регистрация в системе
Оформление покупки
Возврат товара
Регистрация выручки
Управление списком пользователей
Управление безопасностью
Анализ деятельности
Выключение системы
№38 слайд
Содержание слайда: Ранжирование прецедентов
Учитываются следующие факторы:
влияние на архитектуру (например, добавление новых классов);
наличие рискованных, срочных или сложных функций;
потребность в дополнительных исследованиях;
степень важности соответствующего бизнес-процесса
№39 слайд
Содержание слайда: Ранжирование прецедентов
№40 слайд
Содержание слайда: Функциональные требования
Требования этой категории исследуются и формулируются в процессе разработки модели прецедентов (вариантов использования)
Как правило, одной задаче исполнителя соответствует один прецедент
№41 слайд
Содержание слайда: Диаграмма прецедентов
№42 слайд
Содержание слайда: Описание прецедентов
Диаграмма прецедентов дает наглядное изображение системного контекста – границ системы, внешние по отношению к ней понятия и способы использования системы
Однако, для формулирования и анализа требований необходимо детальное текстовое описание прецедентов
№43 слайд
Содержание слайда: Описание прецедентов
Текстовое описание прецедента может быть развернутым или кратким
На начальном этапе развернутое описание дается лишь для основных прецедентов (10-20% от их общего числа)
Пример развернутого описания для прецедента Оформление продажи
№44 слайд
Содержание слайда: Диаграммы и описания прецедентов
Важно иметь в виду, что главное в работе над прецедентами – это составление их описаний, основных и альтернативных сценариев, т.е. текстовых документов
Диаграммы прецедентов играют важную, но второстепенную роль, помогая наглядно представить связи прецедентов с исполнителями, а также взаимосвязи прецедентов
№45 слайд
Содержание слайда: Нефункциональные требования
Определяются в дополнительной спецификации
Приведем пример такой спецификации для POS-системы
№46 слайд
Содержание слайда: Эргономичность
Для достижения высокой скорости обслуживания покупателей при его высоком качестве необходимо:
обеспечить минимальное время отклика системы,
текст должен быть виден с расстояния 1 м,
не должно быть мерцания экрана,
предупреждающие сообщения должны сопровождаться звуковыми сигналами
№47 слайд
Содержание слайда: Надежность
При сбое в работе внешних систем (анализ деятельности) необходимо обеспечить возможность локальной обработки данных, их сохранение и последующую передачу
Этот вопрос требует дальнейшей проработки
№48 слайд
Содержание слайда: Производительность
Покупатель хочет оформить покупку как можно быстрее
Одна из основных причин задержки – низкая скорость авторизации
Необходимо обеспечить выполнение авторизации менее, чем за 1 минуту в 90% случаев
№49 слайд
Содержание слайда: Недостатки существующих решений
Не обеспечивается автоматический переход из интерактивного в автономный режим при сбоях внешних систем;
Отсутствие простой возможности интеграции с внешними системами;
Отсутствие поддержки новых терминальных технологий
№50 слайд
Содержание слайда: Итоги этапа Начало
Выделены основные исполнители, задачи и прецеденты
Выполнено ранжирование и описание прецедентов
Сформулированы в черновом варианте требования к системе
№51 слайд
Содержание слайда: ЭТАП РАЗВИТИЕ
Создается базовая архитектура системы
Производится разрешение высоких рисков
Определяется большинство требований (до 80% прецедентов получают развернутое описание)
Полностью разрабатывается некоторый фрагмент системы
№52 слайд
Содержание слайда: Первая итерация
Программная реализация базового сценария прецедента Оформление продажи
Реализация прецедента Включение системы (необходим для предыдущего)
Взаимодействие с внешними службами не реализуется
№53 слайд
Содержание слайда: Словарь предметной области
Для дальнейшей работы над системой требуется выделить основные сущности предметной области и зафиксировать их в словаре
Register – реестр (терминал)
Item – товар
Store – магазин
Sale – продажа
Sales LineItem – элемент продажи
№54 слайд
Содержание слайда: Словарь предметной области
Cashier –кассир
Customer – покупатель
Manager – менеджер
Payment – платеж
Product Catalog – каталог товаров
Product Specification – спецификация товара
№55 слайд
Содержание слайда: Концептуальная модель
Выделенные таким образом сущности рассматриваются как классы понятий предметной области или концептуальные классы
Описание предметной области в терминах концептуальных классов называется концептуальной моделью предметной области
№56 слайд
Содержание слайда: Концептуальная модель
Отображает наиболее важные для цели моделирования классы понятий предметной области (концептуальные классы)
Кроме того концептуальная модель может отображать
ассоциации между концептуальными классами,
атрибуты концептуальных классов
№57 слайд
Содержание слайда: Классы и атрибуты
№58 слайд
Содержание слайда: Концептуальная модель
№59 слайд
Содержание слайда: Поведение системы
Это описание действий, выполняемых системой, без детализации механизма их реализации
Для визуального представления поведения системы используют диаграмму последовательностей системы
№60 слайд
Содержание слайда: Диаграммы последовательностей
Диаграммы последовательностей – это составная часть модели прецедентов, позволяющая визуализировать взаимодействие объектов в процессе реализации прецедента
№61 слайд
Содержание слайда: Диаграмма последовательностей
№62 слайд
Содержание слайда: Системные операции
Диаграмма последовательностей системы позволяет выделить набор системных операций
Операцией называется любое преобразование объекта или запрос к объекту
Операция называется системной, если в качестве объекта выступает система в целом
№63 слайд
Содержание слайда: Описание операций
Операции требуют отдельного описания, если они достаточно сложны и их содержание не раскрыто в описании соответствующего прецедента
№64 слайд
Содержание слайда: Структура описания операции
№65 слайд
Содержание слайда: Категории постусловий
Создание или удаление экземпляра объекта
Модификация атрибута экземпляра объекта
Формирование или разрыв ассоциации
№66 слайд
Содержание слайда: Системные операции POS
№67 слайд
Содержание слайда: Системные операции POS
№68 слайд
Содержание слайда:
№69 слайд
Содержание слайда: Модель проектирования
Созданием концептуальной модели завершается анализ требований в рамках первой итерации
На следующем этапе внимание фокусируется на разработке проектного решения, удовлетворяющего требованиям данной итерации, т.е. модели проектирования
№70 слайд
Содержание слайда: Концептуальные и программные классы
Концептуальная модель содержит концептуальные классы с указанием их атрибутов
Модель проектирования содержит программные классы с указанием их атрибутов и методов
№71 слайд
Содержание слайда:
№72 слайд
Содержание слайда: Распределение обязанностей
Основной задачей этапа проектирования является построение логики взаимодействия объектов, обеспечивающей выполнение системных требований
Это достигается путем распределения обязанностей объектов
№73 слайд
Содержание слайда: Знания и действия
Обязанность определяется как контракт объекта и делятся на
знания (наличие информации об инкапсулированных данных, о связанных объектах)
действия (выполнение вычислений, создание экземпляра, инициирование действий других объектов или управление ими)
№74 слайд
Содержание слайда: Реализация обязанностей
Обязанности реализуются посредством методов программных классов
Метод может реализовывать обязанность самостоятельно, либо во взаимодействии с методами других классов
№75 слайд
Содержание слайда: Диаграммы взаимодействия
Для визуализации распределения обязанностей между объектами используют диаграммы взаимодействия двух видов:
диаграммы кооперации,
диаграммы последовательностей
В обоих случаях взаимодействие объектов представляется в виде обмена сообщениями
№76 слайд
Содержание слайда: Шаблоны
Распределение обязанностей подчиняется ряду принципов, обобщающих практический опыт проектирования программных систем
Эти принципы формулируются в виде шаблонов проектирования (design patterns)
№77 слайд
Содержание слайда: Шаблон Expert
Проблема Каков наиболее общий принцип распределения обязанностей?
Решение Назначить обязанность классу, владеющему информацией, необходимой для выполнения обязанности
№78 слайд
Содержание слайда: Формулировка обязанности
Вычислить общую сумму продажи
Какая информация нужна для выполнения этой обязанности?
стоимость каждого вида товаров,
цену каждого вида товаров
Какой класс должен выполнять эту обязанность?
№79 слайд
Содержание слайда: Вычисление общей стоимости
№80 слайд
Содержание слайда: Распределение обязанностей
Класс Sale – эксперт для вычисления общей суммы продажи
Класс Sales LineItem– эксперт для вычисления промежуточной суммы элемента продажи
Класс Product Specification – эксперт для определения цены товара
№81 слайд
Содержание слайда: Диаграмма кооперации
№82 слайд
Содержание слайда: Создание программных объектов
Объекты программных классов должны быть созданы, чтобы их можно было использовать
Проблема Какие классы должны отвечать за создание объектов классов Sale, Sales LineItem, Product Specification?
№83 слайд
Содержание слайда: Шаблон Creator
Решение Назначить классу B создавать объекты класса A, если выполняется одно из условий:
Класс B агрегирует объекты A
Класс B содержит объекты A
Класс B записывает объекты A
Класс B активно использует объекты A
Класс B обладает данными для инициализации объектов класса A
№84 слайд
Содержание слайда: Шаблон Creator
Под агрегацией классом B объектов класса A подразумевается, что последние являются составляющими частями объектов класса B
Если же объект класса B выступает лишь в роли контейнера для объектов класса A, то говорят, класс B содержит объекты класса A
№85 слайд
Содержание слайда: Выявление объекта-создателя
№86 слайд
Содержание слайда: Шаблон Creator
Определяет способ распределения обязанностей, связанный с процессом создания объектов
Основное назначение – выявление объекта-создателя:
класс-контейнер
класс-регистратор
класс, владеющий информацией, необходимой при инициализации объекта
№87 слайд
Содержание слайда: Создание объектов SalesLineItem
Класс Sale агрегирует объекты класса SalesLineItem и поэтому является хорошим кандидатом на роль создателя объектов этого класса
№88 слайд
Содержание слайда: Диаграмма последовательностей
№89 слайд
Содержание слайда: Обеспечение низкого сцепления
Необходимо создать объект Payment и связать его с объектом Sale
Возможны два альтернативных пути:
объект Payment создается объектом Register, который затем уведомляет об этом объект Sale;
объект Payment создается объектом Sale, который получает соответствующее указание от объекта Register
№90 слайд
Содержание слайда: Два способа создания Payment
№91 слайд
Содержание слайда: Шаблон Low Coupling
Этот шаблон поддерживает независимость классов и слабое сцепление между ними
В соответствии с данным шаблоном предпочтение следует отдать второму способу, т.к. при этом не возникает дополнительной связи между Register и Payment
№92 слайд
Содержание слайда: Шаблон Low Coupling
Высокая степень сцепления объектов сама по себе не является проблемой
Рекомендуется избегать ее в двух случаях:
для классов, являющихся достаточно общими по своей природе и многократно используемыми;
для неустойчивых и подверженными частому изменению элементов системы
№93 слайд
Содержание слайда: Шаблон High Cohesion
Проблема Как обеспечить управление сложностью?
Решение Распределить обязанности способом, обеспечивающим высокую степень функциональной связности
Функциональная связность– это мера взаимосвязи обязанностей класса
Класс с низкой степенью связности выполняет много разнородных функций
№94 слайд
Содержание слайда: Два способа создания Payment
№95 слайд
Содержание слайда: Шаблон High Cohesion
Классы с высокой степенью связности просты в понимании, поддержке и повторном использовании
Сцепление и связность взаимозависимы: неправильное сцепление порождает слабую связность, и наоборот
№96 слайд
Содержание слайда: Конец лекции
Скачать все slide презентации Объектно-ориентированное проектирование ПС одним архивом:
