6) Объектно-ориентированное программирование 1

Объектно-ориентированное проектирование ПС (часть 1)

Лекция 6

Декомпозиция системы (в частности- программной системы - ПС)

• Функциональная – на основе потока данных с выделением обрабатывающих функций
• Объектная – на основе выделения сущностей, обладающих собственными наборами данных, состояниями и наборами операций

отличия =

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

Структурные единицы

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

Начало проектирования

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

Пример разработки
Этот пример описан в книге Крэга Лармана «Применение UML и шаблонов проектирования»
Постановка задачи
Разработать программное обеспечение для системы организации товарооборота и обработки платежей в магазинах розничной торговли
Модель разработки
Разработка системы будет вестись в рамках модели RUP - адаптивного итеративного процесса с постепенным наращиванием функциональности ПС и уточнением требований посредством механизма обратной связи
Фазы процесса разработки
Начало – анализ проблемы, формирование представлений о функциях системы и основных требованиях к ней
Развитие –реализация базовой части системы и уточнение требований; осуществляется через последовательность итераций
Фазы процесса разработки
Конструирование – разработка системы в полном объеме и окончательная формулировка требований; осуществляется через последовательность итераций, каждая из которых завершается созданием релиза
Внедрение – развертывание системы и бета-тестирование
Этап Начало
Основные задачи:
формирование представления о проекте
формулирование исходных требований к системе
оценка стоимости проекта
идентификация основных рисков

Анализ предметной области
Предметная область – ро?зничная торго?вля (англ. retail)
Что делается – производится продажа товаров конечному потребителю (частному лицу)
Как делается – покупатель отбирает необходимые ему товары и производит оплату в кассе

Анализ предметной области
Где делается – основным предприятием розничной торговли является магазин (дискаунтер, универмаг, универсам и т.д.)
Кто делает – субъектами процесса розничной торговли являются продавец (менеджер торгового зала, кассир) и покупатель

Анализ предметной области
Когда делается – каждый магазин имеет фиксированный график работы
Зачем делается – розничная торговля обеспечивает удовлетворение потребностей населения в товарах различного назначения и получение торговой прибыли

Проблемы
Низкая скорость выполнения операции оплаты покупок
Ошибки кассиров при подсчете стоимости товаров и расчете с покупателями
Сложность ведения учета проданных товаров
Большие объемы работ по подготовке данных для системы анализа

Пути решения
Создание компьютеризированной системы оплаты покупок Point-Of-Sale (POS-система)
Интеграция этой системы с существующими компьютерными системами поддержки торговой деятельности – системой складского учета, системой анализа торговой деятельности, бухгалтерской системой

POS-терминал
POS-система реализуется в виде набора POS-терминалов
Каждый POS-терминал представляет собой программно-аппаратный комплекс, установленный на месте, где кассир осуществляет прием платежей от клиентов (АРМ кассира)

Аппаратная часть
Аппаратная часть POS-терминала включает:
системный блок ПК,
фискальный регистратор,
POS-монитор кассира,
денежный ящик,
программируемую клавиатуру, считыватель карт,
считыватель штрих-кодов
Интерфейс пользователя
POS-терминал должен иметь интерфейс взаимодействия с пользователем для
поиска нужного товара и получения его характеристик;
формирования и печати чеков;
подсчета сдачи;
выполнения различных отчетов
Определение границ системы
Границы системы проще всего определить установив основных исполнителей, потребности которых удовлетворяются данной системой
Для этого надо ответить на вопросы:
Кто будет снабжать систему информацией?
Кто будет получать информацию от системы?
Кто будет осуществлять поддержку и обслуживание системы?
Использует ли система внешние ресурсы?
Границы системы
Основные исполнители
Кассир
оформляет продажи,
выполняет возврат товара,
регистрирует выручку;
Системный администратор
редактирует список пользователей,
управляет безопасностью;

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

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

Ранжирование прецедентов
Функциональные требования
Требования этой категории исследуются и формулируются в процессе разработки модели прецедентов (вариантов использования)
Как правило, одной задаче исполнителя соответствует один прецедент

Диаграмма прецедентов
Описание прецедентов
Диаграмма прецедентов дает наглядное изображение системного контекста – границ системы, внешние по отношению к ней понятия и способы использования системы
Однако, для формулирования и анализа требований необходимо детальное текстовое описание прецедентов
Описание прецедентов
Текстовое описание прецедента может быть развернутым или кратким
На начальном этапе развернутое описание дается лишь для основных прецедентов (10-20% от их общего числа)
Пример развернутого описания для прецедента Оформление продажи
Сбор требований
Требования можно разбить на категории (модель FURPS+):
Functionality – функциональности,
Usability – эргономичности,
Reliability – надежности,
Performance – производительности,
Supportability – возможности поддержки,
+ – дополнительные требования (реализация, интерфейс, юридические вопросы и пр.)
Нефункциональные требования
Определяются в дополнительной спецификации
Приведем пример такой спецификации для POS-системы

Эргономичность
Для достижения высокой скорости обслуживания покупателей при его высоком качестве необходимо:
обеспечить минимальное время отклика системы,
текст должен быть виден с расстояния 1 м,
не должно быть мерцания экрана,
предупреждающие сообщения должны сопровождаться звуковыми сигналами
Надежность
При сбое в работе внешних систем (анализ деятельности) необходимо обеспечить возможность локальной обработки данных, их сохранение и последующую передачу
Этот вопрос требует дальнейшей проработки
Производительность
Покупатель хочет оформить покупку как можно быстрее
Одна из основных причин задержки – низкая скорость авторизации
Необходимо обеспечить выполнение авторизации менее, чем за 1 минуту в 90% случаев
Недостатки существующих решений
Не обеспечивается автоматический переход из интерактивного в автономный режим при сбоях внешних систем;
Отсутствие простой возможности интеграции с внешними системами;
Отсутствие поддержки новых терминальных технологий
Риски
Итоги этапа Начало
Выделены основные исполнители, задачи и прецеденты
Выполнено ранжирование и описание прецедентов
Произведена оценка рисков, связанных с основными прецедентами
Сформулированы в черновом варианте требования к системе
Этап Развитие
Создается базовая архитектура системы
Производится разрешение высоких рисков
Определяется большинство требований (до 80% прецедентов получают развернутое описание)
Полностью разрабатывается некоторый фрагмент системы
Первая итерация
Программная реализация базового сценария прецедента Оформление продажи
Реализация прецедента Включение системы (необходим для предыдущего)
Взаимодействие с внешними службами не реализуется

Словарь предметной области
Register – реестр (терминал)
Item – товар
Store – магазин
Sale – продажа
Sales LineItem – элемент продажи
Cashier –кассир
Customer – покупатель
Manager – менеджер

Словарь предметной области
Payment – платеж
Product Catalog – каталог товаров
Product Specification – спецификация товара
Поведение системы
Это описание действий, выполняемых системой, без детализации механизма их реализации
Для визуального представления поведения системы используют диаграмму последовательностей системы

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

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

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

Распределение обязанностей
Основной задачей этапа проектирования является построение логики взаимодействия объектов, обеспечивающей выполнение системных требований
Это достигается путем распределения обязанностей объектов
Знания и действия
Обязанность определяется как контракт объекта и делятся на
знания (наличие информации об инкапсулированных данных, о связанных объектах)
действия (выполнение вычислений, создание экземпляра, инициирование действий других объектов или управление ими)
Реализация обязанностей
Обязанности реализуются посредством методов программных классов
Метод может реализовывать обязанность самостоятельно, либо во взаимодействии с методами других классов
Диаграммы взаимодействия
Для визуализации распределения обязанностей между объектами используют диаграммы взаимодействия двух видов:
диаграммы кооперации,
диаграммы последовательностей
В обоих случаях взаимодействие объектов представляется в виде обмена сообщениями
Шаблоны
Распределение обязанностей подчиняется ряду принципов, обобщающих практический опыт проектирования программных систем
Эти принципы формулируются в виде шаблонов проектирования (design patterns)
Шаблон Expert
Проблема Каков наиболее общий принцип распределения обязанностей?
Решение Назначить обязанность классу, владеющему информацией, необходимой для выполнения обязанности
Формулировка обязанности
Вычислить общую сумму продажи
Какая информация нужна для выполнения этой обязанности?
стоимость каждого вида товаров,
цену каждого вида товаров
Какой класс должен выполнять эту обязанность?
Вычисление общей стоимости
Распределение обязанностей
Класс Sale – эксперт для вычисления общей суммы продажи
Класс Sales LineItem– эксперт для вычисления промежуточной суммы элемента продажи
Класс Product Specification – эксперт для определения цены товара
Диаграмма кооперации
Создание программных объектов
Объекты программных классов должны быть созданы, чтобы их можно было использовать
Проблема Какие классы должны отвечать за создание объектов классов Sale, Sales LineItem, Product Specification?
Шаблон Creator
Выявление объекта-создателя
Шаблон Creator
Определяет способ распределения обязанностей, связанный с процессом создания объектов
Основное назначение – выявление объекта-создателя:
класс-контейнер
класс-регистратор
класс, владеющий информацией, необходимой при инициализации объекта
Диаграмма последовательностей
Обеспечение низкого сцепления
Необходимо создать объект Payment и связать его с объектом Sale
Возможны два альтернативных пути:
объект Payment создается объектом Register, который затем уведомляет об этом объект Sale;
объект Payment создается объектом Sale, который получает соответствующее указание от объекта Register
Два способа создания Payment
Шаблон Low Coupling
Этот шаблон поддерживает независимость классов и слабое сцепление между ними
В соответствии с данным шаблоном предпочтение следует отдать второму способу, т.к. при этом не возникает дополнительной связи между Register и Payment
Шаблон Low Coupling
Высокая степень связности объектов сама по себе не является проблемой
Рекомендуется избегать ее в двух случаях:
для классов, являющихся достаточно общими по своей природе и многократно используемыми;
для неустойчивых и подверженными частому изменению элементов системы
Шаблон High Cohesion
Проблема Как обеспечить управление сложностью?
Решение Распределить обязанности способом, обеспечивающим высокую степень функционального зацепления
Функциональное зацепление – это мера взаимосвязи обязанностей класса
Класс с низкой степенью зацепления выполняет много разнородных функций
Два способа создания Payment
Шаблон High Cohesion
Классы с высокой степенью зацепления просты в понимании, поддержке и повторном использовании
Связывание и зацепление взаимозависимы: неправильное связывание порождает слабое зацепление, и наоборот
Шаблон Controller
Проблема Кто должен отвечать за обработку системных сообщений?
Решение Обязанности по обработке системных сообщений назначаются классу, который:
представляет систему в целом;
представляет сценарий некоторого прецедента, в рамках которого обрабатываются системные сообщения
Контроллеры
Классы, обязанности которых состоят в обработке системных сообщений называются классами контроллера
Классы контроллера не относятся к интерфейсу пользователя
В рассматриваемом примере возможны два варианта решения
1-й вариант
Все системные операции выполняются одним внешним контроллером
2-й вариант
Системные операции распределены между несколькими контроллерами прецедента
Выбор варианта
Выбор между вариантом использования внешнего контроллера (facade controller) и вариантом контроллеров прецедентов определяется, в основном требованиями соблюдения малой связности и высокой степени зацепления
Конец лекции