Введение в концепции программирования. Лекция 2
author: И. Л. Мусабиров, П. В. Окопный,
date: при участии канд. пед. наук, доц. Н. Г. Дмошинской
Примеры/задания:
- сэмл репорт
- десижн тейблз
- диаграммы сущностей и переходов состояний
Анонс
type: prompt
В понедельник (9.12) в 16 часов лекция Ношира Контрактора (SONIC, SyndioSocial) в 410 аудитории.
Тема: «Требуется сборка: сотрудничество в 21 веке и сетевая наука»
Разбор полётов
Notes:
- “координально”, “удовлетворяет поставленный критерий”
- Самый оптимальный, самый наилучший
- эффективный-оптимальный, лучший-наилучший
Оформление: фамилия-группа: титульный лист и нижний колонтитул
Оценки: кривая симметричная (среднее и медиана совпадают), но сдвинута почти на единицу.
У кого в табличке есть модификатор + – можно обсудить на консультации
Остальным тоже можно обсудить на консультации, но в третью очередь (второе ДЗ, оценки с плюсиком, оценки без плюсика)
Отвратительно сделано задание по домашнему чтению.
Планирование времени: др включает проект, он не расчитан на один присест (будет занимать 5-7 часов). Нужно использовать домашнее чтение и консультацию.
Honour code.
- Что это такое.
- Будет (скорее всего) один вариант основного задания.
- Можно обсуждать.
- Указать в работе с кем обсуждали.
- Обсуждение не происходит над отчётом – каждый пишет свой отчёт своими словами.
- Часть (а возможно и все) работы обсудим на последней паре. Не касается минимальных оценок.
1B: упражнение примеры (вода из смесителя, поиск вирусов базы/сигнатуры vs эвристики)
Анализ проблемы. Системы. Обобщение
- Система. Открытые vs закрытые
- Проблема vs Цель
- Информационные системы
- Социотехнические системы
Notes:
- Система. Границы систем (разные перспективы)
- (часы? самолет?)
- Системы жизнеобеспечения (космические станции, подводные лодки)
- Пример: вентилятор и кондинционер. Оба – открытые системы. Закрытая и открытая – система циркуляции воздуха в комнате
- В контексте системы: Проблема и Цель – (Состояния системы)
- Информационные входы и выходы (широкий и узкий смысл). Обработка (процессинг), технология. Информационные технологии
- Поэтому в узком смысле ИС предполагает ИТ: базы данных, программы и т.д. Но традиционный читальный зал – тоже ИС.
- Социотехнические системы рассматривают взаимодействие людей и технологии в рабочем контексте. Это подход к проектированию сложных рабочих процессов. В ещё более широком смысле – взаимодействие между социальной инфраструктурой и человеческим поведением.
- ИС можно рассматривать как социотехнические системы и с этой точки зрения смотреть на нижеизложенное.
Анализ проблемы. Когда задача не игрушечная
- Алгоритма из 6 шагов не хватает
- Проблема vs Потребность (В контексте процесса более высокого уровня)
- Стейколдеры, интересы и потребности
- Выявление и типизация стейкхолдеров
- Выявление их потребностей, интересов и проблем
“Как (роль) я хочу (цель), чтобы (контекст потребности)”
Notes:
- В первой лекции мы рассмотрели игрушечные задачки, сейчас посмотрим, как проектируются реальные информационные системы
- В дом. задании часть была сформулирована как потребности (хочет, нужно), часть – проблемы
- Упражнение “потребность-задача”, “проблема-задача”
Формула роли: “как (роль) я хочу (цель), чтобы (контекст потребности)”
Типы стейкхолдеров: первичные (используют систему), вторичные (пользуются результатами первых), третичные (обслуживают систему)
Вполне социологическая задачка (вспоминаем, что ИС = социотехническая система). Причём качественная (Анализ коммуникаций, документов-источников, наблюдение, кейс-анализ)
Пирамида требований
Notes:
- Пирамида требований
- Немного о нефункциональных требованиях и ограничениях
- Use Case как способ фиксации поведенческих требований к системе
- Откуда у системы поведение? Система как компромис интересов стейкхолдеров
- Диалог или Распасовка
Use Case – фиксируем поведение системы
UC описывает последовательность взаимодействия эктора и системы, приводящее к ценному для этого эктора результату
- Последовательность взаимодействия: Описывает набор атомарных взаимодействий (interactions) между пользователем и системой, инициируемую Эктором.
Каждое действие в последовательности атомарно, то есть выполняется целиком или не выполняется совсем.
- Система: System under development
- Ценный результат:
- Для кого?
- В каком контексте?
- Определяет детальность UC
Notes:
- Атомарность: атом – не делимый, Пример: покупка (обмен деньги-товар)
- System under development (границы обусловлены целью и сдвигаются)
- Ценный результат:
- Для кого? (для эктора)
- В каком контексте? (контекст “бизнес”-процесса) (“в котором эктор является воркером”). Сравнить с интересом стейкхолдера: контекст над-процесса
- Определяет детальность UC (нажать кнопку/ввести пин – не UC)
Зачем нужны UC (Алистер Коберн)
- Список “Эктор – цель” составляет кракое описание ценности, приносимой системой пользователям и организации и составляет основу планирования проекта
- Основной сценарий UC является соглашением сторон о том, что система должна (и что не должна) делать, определяя контекст для каждого требования
Зачем нужны UC (2)
- Условия расширения дают механизм исследования неочевидных ветвлений, потенциальных отказов, которые иногда поглощают до 80% времени проекта, позволяя заранее отмечать возможные трудности и неясности
- Сценарии UC повзоляют ответить на многие сложные вопросы о деталях бизнес-логики, используя традиционную систему (if…then…else), которой легко оперировать и разработчикам и аналитикам
Зачем нужны UC (3)
- Полный набор (модель) UC показывает, что разработчики продумали все пользовательские потребности и цели по отношению к системе
Use Case modelling
type:section
UC описывает последовательность взаимодействия эктора и системы, приводящее к ценному для этого эктора результату
Use Case model: Эктор
Эктор – кто-то или что-то взаимодействующее с системой извне
Классы:
- Users (Пользователи)
- Системы/Приложения
- Устройства
Notes:
- Эктор всегда вне системы
- Он пинает систему, она оказывает ему услуги
- Примеры на разные классы
Use Case model: Стейкхолдеры и экторы
- Стейкхолдер vs эктор
- Экторы. Напоминание о границах системы
Типы (по отношению к системе: Кто кого пинает):
Notes:
- Упражнение стейколдер не-эктор, стейкхолдер-эктор
- Упражнение на смену границ. Бизнес-система vs Программная система. Эктор -> worker
- Упражнение первичный-вторичный, вторичный-воркер
Use Case model. Список “Эктор – цель”
- Выявление экторов
- Выявление целей
- Опять вполне социологическая задачка: анализ связей, соцсетей и источников
- (*) Планирование разработки: приоритет(заказчик) и трудоёмкость (разработчик)
Notes:
Ревью + интерактивное дополнение списка для примера системы
Use Case model. Список “Эктор – цель” (2)
Проект: ИС взаимодействия с клиентами банка
Включает сеть банкоматов, терминалы оплаты по картам, инфокиоски, интернет-банк.
Клиент банка
- Снять деньги со счёта.
- Заплатить за телефон.
Торговая точка
- Принимать платежи от клиентов (через терминал).
Notes:
У клиента могут быть и другие цели - вопрос к аудитории - какие ещё? (обмен валюты, заработать на процентах, взять кредит, счёт для юрлица для приёма платежей и т.д.)
Система объединяет разные подсистемы, но мы концентрируемся на целях экторов.
Вопросы:
- Какие ещё экторы? (банк, налоговая..)
- Какие у них цели?
Use Case
type: section
Структура UC
- Заголовок
- Эктор
- Краткое описание
- Поток событий
- Основной поток (Basic flow)
- Альтернативные потоки (Alternative flows)
- Затрагиваемые стейкхолдеры
- Предусловия
- Гарантии успеха и минимальные гарантии
- Затрагиваемые сущности предметной области
Notes:
Смысл:
UC structure (2)
type:section
- Заголовок – цель эктора в контексте системы
- Эктор
- Краткое описание
Notes
- Заголовок — цель эктора в контексте системы (банкомат)
- Разбираем примеры целей и не-целей. Контекст. Нет абстрактных “функций” вне вэлью эктора
UC structure (3)
- Затрагиваемые стейкхолдеры
- Предусловия
- Гарантии успеха и минимальные гарантии
Notes
- Затрагиваемые стейкхолдеры. Вернее: стейкхолдеры, интересы которых затрагиваются. (Банкомат: банк, охрана, финансовый надзор)
- Заголовок — цель эктора в контексте системы (банкомат: заплатить кредит)
- Предусловия:
- Условие логического типа (можем проверить ложь-истина).
- UC не выполняется, если оно не приняло значение ИСТИНА (TRUE).
- Мы не проверяем его выполнение в рамках UC
- Пример: (банкомат оборудован кэш-ином, вставлена карта и введен пин-код)
- Успешное завершение UC
- = достижение цели
- (срабатывают гарантии успеха): карточку вернули пользователю, деньги в хранилище, сумма учтена на кредитном счету
- Мы убеждаемся (ensure), что все задействованные сущности находятся в нужном состоянии
- НО: цель может быть и не достигнута:
- (срабатывают минимальные гарантии):
- Пример: карточку вернули пользователю, нет изменений по счету, банкомат готов к работе
- Опять, убеждаемся, что все сущности в нужном состоянии
UC structure (4)
- Поток событий (Flow of events)
- Основной поток (Basic flow)
- Альтернативные потоки (Alternative flows)
Notes:
- Шаги — диалог между системой и эктором (гарантии! система как компромисс!)
- Flow of events: текстовое описание.
- Не совсем псевдокод, но более формальный язык
- Используем проектный словарь (контролируемый словарь): имена вовлеченных стейкхолдеров, ролей, сущности, статуы, единые для проекта
UC structure (5)
- Поток событий (Flow of events)
- Основной поток (Basic flow)
- Альтернативные потоки (Alternative flows)
Notes:
- Basic flow (shortest sunny day path)
- Основной поток: sunny day scenario (быстро/наиболее частотным образом достигаем цели)
- Основной поток определяет часть соглашения по поведению системы в рамках UC
- В основном потоке нет условий (система ничего не проверяет), мы находимся в режиме ensure (Система подтверждает)
- Это позволяет сфокусировться на цели и держать основной поток коотким
UC structure (5a)
Пример: Оплата по карте в терминале. Basic flow
- Получаем с ККМ сумму
- Приглашаем пользователя вставить карту
- Подтверждаем работоспособность карты
- Подтверждаем правильность пин-кода
- Вызываем Процедуру Списания
- Просим забрать карту
Каких шагов не хватает?
Notes:
UC structure (6)
- Поток событий (Flow of events)
- Основной поток (Basic flow)
- Альтернативные потоки (Alternative flows):
- Условие расширения
- Обработчик расширения
Notes:
- Альтернативные потоки:
- Начинаем с выявления условий расширения (ЛОГИЧЕСКИХ УТВЕРЖДЕНИЙ)
- Почти самый важный кусок во всем!
- Обдумывать условия отказов и ветвлений
- Это анализ What-If, предмет мозгового штурма
UC structure (6a)
Пример: Оплата по карте в терминале. Alternative flows
Терминал не может связаться с сервером
1 Шаг обработки расширения
2 ….
Ещё примеры?
Notes:
- Введен неправльный пин-код
- Банк вернул ответ “недостаточно средств”
UC structure (7)
- Поток событий (Flow of events)
- Основной поток (Basic flow)
- Альтернативные потоки (Alternative flows):
- Условие расширения
- Обработчик расширения
UC structure (7a)
Терминал не может связаться с сервером
1 Отобразить сообщение о невозможности оплаты
2 Предложить повторить операцию
UC structure (7b)
Подумаем над примером
Банк вернул ответ “недостаточно средств”
1 …
Сущности и изменения их состояний
Счёт
- Номер счёта
- Имя клиента
- Состояние: Активный/заблокированный
Карта
- Номер карты
- Пин-код (и код безопасности)
- Имя на карте
- Срок действия
Notes:
- Пример сущностей в UC (счёт, карта, …?)
- Движение по состояниям (счёт: меняется с активного на заблокированный)
- Слоты-переменные
- Типы переменных
- Числовые
- Строковые
- Логические
Вопрос в зал: приведите ещё возможные примеры сущностей и их атрибутов
Полный пример UC(1)
Полный пример UC(2). Basic flow
Предусловие:
- Вставлена банковская карта поддерживаемой системы (Visa, Mastecard)
- Клиент вводит пин-код
- Система подтвержает правильность введённого пин-кода
- Клиент вводит требуемую сумму
- Система подтверждает возможность выдачи введённой суммы
- Система учитывает выданную сумму
- Система выдаёт требуемую сумму
- Система возвращает клиенту банковскую карту
- Система выдаёт клиенту чек
Notes:
вопрос: на каких шагах что-то может пойти не так?
Полный пример UC(3). Alternative flow
На шаге Система подтвержает правильность введённого пин-кода
Условие: введён неправильный пин-код
- Система сообщает клиенту об ошибке при проверке пин-кода
- Система подтверждает возможность повторного введения пин-кода
- Возврат к шагу Клиент вводит пин-код основного потока
Notes:
На шаге 2 возможен ещё один альт. поток. Какой?
Вернутся на слайд назад к basic flow. Задание аудитории (на 5 мин, по группам): придумать (и записать к себе в тетрадку) ещё один альт. поток и расказать по шагам.
Полный пример UC(4). Затрагиваемые стейкхолдеры
- Банк
- Кредитный отдел банка
- Служба финансового мониторинга
Полный пример UC(5). Гарантии успеха и минимальные гарантии
- Гарантии успеха
- Транзакция проведена по счёту клиента
- Клиент получил запрошенную сумму денег и чек
- Клиент получил свою карту назад
- Минимальные гарантии
- Клиент получил свою карту назад
- Деньги со счёт клиента не были списаны
Полный пример UC(2). Затрагиваемые сущности
- Банковская карта
- Счёт клиента
Полный пример UC-модели
- Клиент
- Снять деньги со счёта
- Положить деньги на счёт
- Заплатить
- за телефон
- коммунальные услуги
- Заплатить за товар в торговой точке
- Торговая точка
- Получить отчётность
- Вернуть платёж клиенту
- Предприятие-работодатель
- Начислить зарплату сотруднику