Введение в концепции программирования. Лекция 2

И. Л. Мусабиров, П. В. Окопный,
при участии канд. пед. наук, доц. Н. Г. Дмошинской

NOSoc.io

Анонс

В понедельник (9.12) в 16 часов лекция Ношира Контрактора (SONIC, SyndioSocial) в 410 аудитории.

Тема: «Требуется сборка: сотрудничество в 21 веке и сетевая наука»

Разбор полётов

  • Русский язык!
  • Оформление работ

  • Имя файла с домашней работой: hw2_Фамилия_Имя_НомерГруппы.[doc|pdf|odt|txt]

  • Распределение оценок.

  • Honour code:

    • Указать на листочке с кем обсуждали.
    • Обсуждение не происходит над отчётом – каждый пишет свой отчёт своими словами.

  • Вопрос 1B: Эвристическое VS алгоритмическое решение

Анализ проблемы. Системы. Обобщение

  • Система. Открытые vs закрытые
    • Проблема vs Цель
    • Информационные системы
    • Социотехнические системы

Анализ проблемы. Когда задача не игрушечная

  • Алгоритма из 6 шагов не хватает
  • Проблема vs Потребность (В контексте процесса более высокого уровня)
  • Стейколдеры, интересы и потребности
    • Выявление и типизация стейкхолдеров
    • Выявление их потребностей, интересов и проблем

“Как (роль) я хочу (цель), чтобы (контекст потребности)”

Пирамида требований

Requirements Pyramide

Use Case -- фиксируем поведение системы

UC описывает последовательность взаимодействия эктора и системы, приводящее к ценному для этого эктора результату

  • Последовательность взаимодействия: Описывает набор атомарных взаимодействий (interactions) между пользователем и системой, инициируемую Эктором. Каждое действие в последовательности атомарно, то есть выполняется целиком или не выполняется совсем.
  • Система: System under development
  • Ценный результат:
    • Для кого?
    • В каком контексте?
    • Определяет детальность UC

Зачем нужны UC (Алистер Коберн)

  • Список “Эктор – цель” составляет кракое описание ценности, приносимой системой пользователям и организации и составляет основу планирования проекта
  • Основной сценарий UC является соглашением сторон о том, что система должна (и что не должна) делать, определяя контекст для каждого требования

Зачем нужны UC (2)

  • Условия расширения дают механизм исследования неочевидных ветвлений, потенциальных отказов, которые иногда поглощают до 80% времени проекта, позволяя заранее отмечать возможные трудности и неясности
  • Сценарии UC повзоляют ответить на многие сложные вопросы о деталях бизнес-логики, используя традиционную систему (if…then…else), которой легко оперировать и разработчикам и аналитикам

Зачем нужны UC (3)

  • Полный набор (модель) UC показывает, что разработчики продумали все пользовательские потребности и цели по отношению к системе

Use Case modelling

UC описывает последовательность взаимодействия эктора и системы, приводящее к ценному для этого эктора результату

Use Case model: Эктор

Эктор – кто-то или что-то взаимодействующее с системой извне

Классы:

  • Users (Пользователи)
  • Системы/Приложения
  • Устройства

Use Case model: Стейкхолдеры и экторы

  • Стейкхолдер vs эктор
  • Экторы. Напоминание о границах системы

Типы (по отношению к системе: Кто кого пинает):

  • Первичные
  • Вторичные

Use Case model. Список "Эктор -- цель"

  • Выявление экторов
  • Выявление целей
  • Опять вполне социологическая задачка: анализ связей, соцсетей и источников
  • (*) Планирование разработки: приоритет(заказчик) и трудоёмкость (разработчик)

Use Case model. Список "Эктор -- цель" (2)

Проект: ИС взаимодействия с клиентами банка

Включает сеть банкоматов, терминалы оплаты по картам, инфокиоски, интернет-банк.

  • Клиент банка

    • Снять деньги со счёта.
    • Заплатить за телефон.

  • Торговая точка

    • Принимать платежи от клиентов (через терминал).

Use Case

Структура UC

  • Заголовок
  • Эктор
  • Краткое описание
  • Поток событий
    • Основной поток (Basic flow)
    • Альтернативные потоки (Alternative flows)
  • Затрагиваемые стейкхолдеры
  • Предусловия
  • Гарантии успеха и минимальные гарантии
  • Затрагиваемые сущности предметной области

UC structure (2)

  • Заголовок – цель эктора в контексте системы
  • Эктор
  • Краткое описание

UC structure (3)

  • Затрагиваемые стейкхолдеры
  • Предусловия
  • Гарантии успеха и минимальные гарантии

UC structure (4)

  • Поток событий (Flow of events)
    • Основной поток (Basic flow)
    • Альтернативные потоки (Alternative flows)

UC structure (5)

  • Поток событий (Flow of events)
    • Основной поток (Basic flow)
    • Альтернативные потоки (Alternative flows)

UC structure (5a)

Пример: Оплата по карте в терминале. Basic flow

  • Получаем с ККМ сумму
  • Приглашаем пользователя вставить карту
  • Подтверждаем работоспособность карты
  • Подтверждаем правильность пин-кода
  • Вызываем Процедуру Списания
  • Просим забрать карту

Каких шагов не хватает?

UC structure (6)

  • Поток событий (Flow of events)
    • Основной поток (Basic flow)
    • Альтернативные потоки (Alternative flows):
    • Условие расширения
    • Обработчик расширения

UC structure (6a)

Пример: Оплата по карте в терминале. Alternative flows

Терминал не может связаться с сервером
  1. Шаг обработки расширения
  2. ….

Ещё примеры?

UC structure (7)

  • Поток событий (Flow of events)
    • Основной поток (Basic flow)
    • Альтернативные потоки (Alternative flows):
    • Условие расширения
    • Обработчик расширения

UC structure (7a)

Терминал не может связаться с сервером
  1. Отобразить сообщение о невозможности оплаты
  2. Предложить повторить операцию

UC structure (7b)

Подумаем над примером

Банк вернул ответ “недостаточно средств”

1 …

Сущности и изменения их состояний

  • Счёт

    • Номер счёта
    • Имя клиента
    • Состояние: Активный/заблокированный

  • Карта

    • Номер карты
    • Пин-код (и код безопасности)
    • Имя на карте
    • Срок действия

Полный пример UC(1)

  • Заголовок

    Снятие денег со счёта клиентом через банкомат

  • Эктор

    Клиент банка

  • Краткое описание

    Клиент снимает деньги со своего счёта в банке с использованием банковской карты

Полный пример UC(2). Basic flow

Предусловие:

  • Вставлена банковская карта поддерживаемой системы (Visa, Mastecard)
    1. Клиент вводит пин-код
    2. Система подтвержает правильность введённого пин-кода
    3. Клиент вводит требуемую сумму
    4. Система подтверждает возможность выдачи введённой суммы
    5. Система учитывает выданную сумму
    6. Система выдаёт требуемую сумму
    7. Система возвращает клиенту банковскую карту
    8. Система выдаёт клиенту чек

Полный пример UC(3). Alternative flow

На шаге Система подтвержает правильность введённого пин-кода

Условие: введён неправильный пин-код

  1. Система сообщает клиенту об ошибке при проверке пин-кода
  2. Система подтверждает возможность повторного введения пин-кода
  3. Возврат к шагу Клиент вводит пин-код основного потока

Полный пример UC(4). Затрагиваемые стейкхолдеры

  • Банк
  • Кредитный отдел банка
  • Служба финансового мониторинга

Полный пример UC(5). Гарантии успеха и минимальные гарантии

  • Гарантии успеха
    • Транзакция проведена по счёту клиента
    • Клиент получил запрошенную сумму денег и чек
    • Клиент получил свою карту назад
  • Минимальные гарантии
    • Клиент получил свою карту назад
    • Деньги со счёт клиента не были списаны

Полный пример UC(2). Затрагиваемые сущности

  • Банковская карта
  • Счёт клиента

Полный пример UC-модели

  • Клиент
    • Снять деньги со счёта
    • Положить деньги на счёт
    • Заплатить
    • за телефон
    • коммунальные услуги
    • Заплатить за товар в торговой точке
  • Торговая точка
    • Получить отчётность
    • Вернуть платёж клиенту
  • Предприятие-работодатель
    • Начислить зарплату сотруднику