Основы объектно-

ориентированного
программирования

Чернойван Василий Александрович

vchernoivan@gmail.com
http://chernoivan.ru/oop/
Требования
Модели процесса разработки ПО
“Водопад”
“Инкрементная”
 Что такое требования?
• Возможности системы, необходимые
пользователям для достижения целей —
функциональные требования (ФТ)

• Ограничения или условия, которым должна

удовлетворять система, не связанные
непосредственно с целями пользователей
(соответствие стандартам, спецификациям и
т. п.) — нефункциональные требования (НТ)
Нефункциональные требования
• Внешние интерфейсы
– Пользовательский
– Программные/аппаратные
• Характеристики и атрибуты качества
– Применимость (Usability)
– Надежность (Reliability)
– Производительность (Performance)
– Эксплуатационная пригодность
(Supportability)
• Ограничения (физические, юридические,
выбор платформы и пр.)
Явные и неявные требования
Для чего нужны требования?

• Выявить границы (рамки) проекта

• Определить приоритеты

• Выработать общее понимание между

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

• Заинтересованная сторона —
физическое лицо, группа лиц или
организация, которые могут влиять на
систему или на которых может повлиять
система

• Заказчик, пользователи системы, те, кто

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

Пользовательские цели
– Для чего конкретный пользователь
взаимодействует с системой
 Как получить требования?
• Сформулировать самостоятельно
• Анкетирование
• Интервью
• Семинары
• Наблюдение
– Активное
– Пассивное
• Прототипирование
Что дальше?
Требования: способы описания

• Список функциональности (feature list)

• Техническое задание (ТЗ)
• Пользовательские история (user story)
• Варианты использования (use case)
ФТ: список функций

• Требования формализуются при помощи

списка отдельных утверждений о
продукте
• Не формализует контекст и ценность
• Подходит для небольших проектов с
хорошо понятной предметной областью
ФТ: Техническое задание

• Формализованное описание
характеристик продукта.
• Предполагает использование модели
“водопад”
• Подходит, если изменения в продукте не
предполагаются (например, серийное
производство)
 ФТ: Пользовательские истории

• Способ формализации требований в рамках agile

подхода
• Командная
Люди и взаимодействие
работа и ответственность
важнее процессов
и инструментов
важнее людей и взаимодействий
• Ценность
Работающийдляпродукт
бизнесаважнее
важнее
работающего Agile
исчерпывающей манифест
продукта
документации
Гибкая
• Развитие
Сотрудничество разработка
партнёрства
с заказчиком
важнее важнее
согласования условий
сотрудничество с заказчиком
контракта
• Готовность к изменения
изменениямважнее
важнеереакции на
следования первоначальному плану
изменения
 ФТ: Пользовательские истории
• Короткий сценарий взаимодействия пользователя
и системы, выраженный на естественном языке
• Ответ на вопросы
• Кто? (роль)
• Что? (функциональность)
• Зачем? (цели)
• Чтобы рассчитать зарплату продавцам за
месяц, бухгалтер должен получить информацию
о сумме заказов, оформленных каждым из них.
 ФТ: Пользовательские истории
• ПИ — не спецификация требований, а повод их
обудить
• В процессе анализа уточняются
– Разбиваются на более мелкие
– Дополняются ограничениями (НТ)
– Дополняются условиями выполнения (ответ на
вопрос “как мы понимаем, что достигли целей”)
ФТ: Пользовательские истории

• В конце концов должны быть

– Независимыми (Independent)
– Обсуждаемыми (Negotiable)
– Ценными (Valuable)
– Оценимыми (Estimable)
– Небольшими (Small)
– Тестируемыми (Testable)
 ФТ: Варианты использования
• Формализованный сценарий взаимодействия
пользователей и системы, который
• Определяет результирующую ценность, т. е.
отвечает на вопросы «кто» и «зачем».
• Описывают функциональность и результаты, т. е.
«что» и «как»
• Пользовательские истории могут развиться в
варианты использования, когда мы отвечаем на
вопрос “как”
Варианты использования: атрибуты

– Название/Описание
– Цель
– Действующие лица
– Предусловия/постусловия
– Основной сценарий
– Альтернативные сценарии
– Ограничения
– Точки расширения
UseCase диаграмма: Актёр
UseCase диаграмма:
вариант использования
UseCase диаграмма:
обобщение
UseCase диаграмма:
включение
UseCase диаграмма:
включение
Артефакты анализа требований
• Видение (документ)
– Цели на уровне предприятия и системы
• Описание ролей
– Цели на уровне пользователей
• Пользовательские истории, варианты
использования
– Формализованные (более или менее) требования
• Диаграмма вариантов использования
– Требования, взгляд «сверху»
• Глоссарий
– Словарь предметной области
 Варианты использования:
best practices
• Фокус на ценности
• Избегайте “рутинных” сценариев
• Не описывайте реализацию
• Основной сценарий — когда всё хорошо
• Избегайте использования “Если”
• Альтернативные сценарии описывают отклонения
от основного
• Ссылки приводятся в альтернативных сценариях
• Старайтесь быть понятнее
 Пример
• В связи с открытием новой точки продаж магазину
бытовой техники требуется система автоматизации.
Требуется автоматизация
– Расчета заработной платы
– Учета скидочных/бонусных программ, акций.
– Расчета финансового результата
 Видение
• Стратегическая цель
– Увеличение оборота/прибыли путем расширения сети
продаж

• Информационной системы должна

– Автоматизировать работу точек продаж, чтобы открывать
новую точку максимально быстро
 Действующие лица
• Бухгалтер
– Ведение бух. учета
– Формирование финансовой и налоговой отчетности
• Директор филиала
– Общее руководство
– Прием на работу/увольнение
– Расчет и выдача ЗП
– Оплата счетов
• Мерчандайзер
– Руководит выкладкой товара
– Отслеживает остатки и формирует заявки на склад
– Отслеживает товар, который не продается
 Действующие лица
• Продавец-консультант
– Выкладывает товар
– Консультирует покупателей
– Осуществляет продажи (выписывает товарный чек)
• Старший по смене
– То же, что и продавец-консультант
– Заполнение табеля рабочего времени
• Кассир
– Принимает оплату по товарному чеку
 Действующие лица
• Клиент
– Инициирует процесс консультации и продажи

• Менеджер зоны приемки

– Принимает товар со склада
– Сверяет документы

• Завхоз
– Отвечает за административно-хозяйственные вопросы,
начиная от заказа воды и заканчивая покупкой и установкой
электроламп
 Истории
• Чтобы выдать зарплату сотруднику, директору
филиала нужно рассчитать почасовую, сдельную
части ЗП и распределить премиальный фонд

• Чтобы директор мог правильно рассчитать

почасовую часть ЗП старший по смене должен
заполнить табель рабочего времени

• Чтобы оприходовать товар менеджеру зоны

приёмки нужно сверить фактическое наличие
товара и приходную накладную
 Истории
• Чтобы совершить продажу, продавец-консультант
должен оформить товарный чек

• Чтобы покупка была оплачена, кассир принимает

оплату от клиента

• Чтобы избежать разночтений в наименованиях

система должна ежедневно синхронизировать
номенклатуру товара с ИС склада
 Вариант использования
• Название:
Рассчитать ЗП
• Описание:
Чтобы выдать зарплату сотруднику, директору филиала нужно
рассчитать почасовую, сдельную части ЗП и распределить
премиальный фонд.
• Цель:
Сформировать ведомость на выдачу ЗП
• Действующие лица:
директор
• Предусловия:
старшие по смене заполнили табель рабочего времени
• Постусловия:
сформирована ведомость на выплату ЗП
• Основной сценарий:
1.1. Проверка параметров
Директор просматривает для каждого сотрудника почасовую ставку,
процент с выручки для сдельной ЗП, Коэффициент трудового участия
(для расчета премии)
1.2. Контроль входных данных
Директор просматривает исходные данные — количество
отработанных часов и сумму выручки по каждому сотруднику.
1.3. Расчет ЗП
Исходя из установленных значений, табеля рабочего времени и
выручки по сотруднику за месяц система расчитывает ЗП (см.
документ «расчет ЗП»)
1.4. Формирование ведомости на выдачу ЗП
Директор формирует ведомость на выдачу ЗП, используя результаты
расчета
• Альтернативные сценарии:
2.1. Корректировка табеля рабочего времени
На шаге 1.1. основного сценария директор может добавить параметры
расчета ЗП, если они не были установлены (новый сотрудник)

2.2. Добавление штрафов/поощрений

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

2.3. Учет взаиморасчетов

На шаге 1.4. система по умолчанию учитывает взаиморасчеты с
сотрудником, например, выданные авансы. Директор может
откорректировать сумму взаиморасчетов, оформив приходный или
расходный кассовый ордер
• Точки расширения:
– Шаг «1.2. Контроль входных данных»
 Вариант использования
• Название:
Принять оплату
• Описание:
Чтобы покупка была оплачена, кассир принимает оплату от клиента
• Цель:
Принять оплату
• Действующие лица:
Покупатель — инициирует вариант использования
Кассир
• Предусловия:
Продавец-консультант сформировал товарный чек
• Основной сценарий:
1.1. Предъявление документов на оплату
Покупатель предъявляет товарный чек и товар
1.2. Контроль документов
Кассир проверяет соответствие товара чеку.
1.3. Прием оплаты
Кассир принимает от покупателя наличные
1.4. Формирование чека
Кассир вносит в систему данные об оплате, формирует кассовый чек,
прикрепляет его к товарному чеку и передает покупателю
Альтернативные сценарии:
2.1. Оплата кредитной картой
На шаге 1.3. покупатель может использовать кредитную карту,
в этом случае оплата принимается при помощи терминала приема
безналичных платежей
2.2. Оплата подарочным сертификатом
На шаге 1.3. покупатель может предъявить подарочный сертификат. Кассир
проверяет остаток на подарочном сертификате и (возможно частично, по
согласованию с покупателем) использует его для оплаты
2.3. Недостаточно средств
Если на шаге 1.3. выяснилось, что покупатель не в состоянии оплатить товар,
кассир должен изъять товар (его часть), внести изменения в чек (в
бумажный и электронный вариант) и уведомить старшего по смене.
2.4. Документы не соответствуют предъявленному товару
Сценарий прерывается. Необходимо заново оформить товарный чек
Диаграмма вариантов использования
Спасибо за внимание.
Вопросы?