ЧЕЛОВЕКО-МАШИННОЕ ВЗАИМОДЕСТВИЕ Лекция 6 преподаватель кафедры ТМСИ Губин Максим Владимирович МОДЕЛИРОВАНИЕ ИНТЕРФЕЙСА. - презентация

1 ЧЕЛОВЕКО-МАШИННОЕ ВЗАИМОДЕСТВИЕ Лекция 6 преподаватель кафедры ТМСИ Губин Максим Владимирович МОДЕЛИРОВАНИЕ ИНТЕРФЕЙСА

2 Методы проектирования Эвристические методы Метод итераций (последовательного приближения) Метод декомпозиции Метод контрольных вопросов Метод мозговой атаки (штурма) Теория решения изобретательских задач (ТРИЗ) Метод морфологического анализа Функционально-стоимостной анализ Методы конструирования Экспериментальные методы Цели и виды экспериментальных методов Планирование эксперимента Машинный эксперимент Мысленный эксперимент Формализованные методы Методы поиска вариантов решений Методы автоматизации процедур проектирования Методы оптимального проектирования Задачи оптимального проектирования Методы принятия решений Однокритериальные задачи Задачи многокритериальной оптимизации Принятие решений в условиях неопределенности 2

3 Перед проектированием Каково ваше видение проекта? Реально ли осуществить задуманное? Что лучше: купить или разработать? В какую сумму обойдется реализация проекта? Стоит ли браться за проект? 3

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

5 Архитектурные уровни проекта Графический интерфейс пользователя Представление объектов предметной области Вспомогательные технические службы (например, обмен информацией с базой данных) 5

6 Начальная фаза Представить масштаб проекта, сформулировать свое видение и оценить затраты Основная проблема: прийти к соглашению относительно сути проекта и целесообразности инвестиций. 6

7 Приблизительный перечень артефактов начальной фазы АртефактПояснение Видение проектаОписываются общие задачи и ограничения, приводится заключение Модель прецедентовОписываются функциональные и нефункциональные требования Дополнительная спецификация Описываются другие требования Словарь терминовСодержит ключевую терминологию по предметной области Перечень рисков и план управления ими Описываются экономические и технические риски, а также риски связанные организацией планирования и ресурсами, идеи по преодолении рисков Прототипы и обоснования идеи Приводятся для лучшего осмысления проекта и оценки технических идей План итерацийОписываются действия для первой итерации План разработкиПриблизительный план, описание средств, человеческих ресурсов, необходимых навыков и других ресурсов Перечень документовОписание этапов проекта. Набор документов для каждого этапа разрабатывается отдельно. 7

8 Требования Основная задача – определить требования, найти, обсудить и зафиксировать их в форме понятной и клиентам и членам команды разработчиков. Предполагается, что требования должны постоянно корректироваться в процессе разработки прецедентов. Требования можно разделить на две категории: Функциональные (относятся к поведению системы); Нефункциональные (относятся к атрибутам качества). 8

9 Типы требований Функциональные: свойства, возможности, безопасность. Удобство: человеческий фактор, справочная система, документация. Надежность: частота сбоев, возможность восстановления и предсказуемость. Производительность: время отклика, точность, доступность, использование ресурсов. Возможность поддержки: адаптивность, возможность поддержки, соответствие международным стандартам, возможность конфигурирования. Реализация: требования к ресурсам, языки и средства, аппаратное обеспечение. Интерфейс: ограничения накладываемые необходимостью взаимодействия с внешними системами. Операции: управление системой и её параметры. Пакетирование. Юридические вопросы: авторское право. 9

10 Факторы риска для программных проектов 10

11 Описание требований в контексте модели прецедентов Прецедент – это набор сценариев использования, в котором каждый экземпляр сценария представляет собой последовательность действий, выполняемых системой для достижения некоторого результата конкретного исполнителя. Сценарий – это последовательность действий или взаимодействий между исполнителями и системой. Его иногда называют экземпляром прецедента. Прецеденты – механизм упрощения этапа формулирования требований к системе. Основная идея – исследование и формулировка функциональных требований путем описания историй из «жизни системы». Прецеденты – это требования к системе (хотя и не все требования). 11

12 Пример прецедента Обработка продажи (process sale). Покупатель подходит к кассе с выбранными товарами. Кассир с помощью POS-системы регистрирует каждый товар. Система отображает информацию о каждом наименовании товара и вычисляет общую сумму. Покупатель вводит требуемую информацию, система ее верифицирует и регистрирует. Система выполняет инвентаризацию. Покупатель получает товарный чек и покидает магазин с покупками. 12

13 Другие сценарии Обработка продажи (process sale). Покупатель подходит к кассе с выбранными товарами. Кассир с помощью POS-системы регистрирует каждый товар. Система отображает информацию о каждом наименовании товара и вычисляет общую сумму. Покупатель вводит требуемую информацию, система ее верифицирует и регистрирует. Система выполняет инвентаризацию. Покупатель получает товарный чек и покидает магазин с покупками. Возврат товара. Покупатель подходит к кассе с товарами, подлежащим возврату. Кассир использует POS-систему для регистрации каждого возвращаемого товара ….. Отказ оплаты по кредитной карточке. Если в авторизации отказано, то кассир информирует об этом покупателя и предлагает ему другой способ оплаты. Ошибка идентификации товара. Если идентификатор товара в системе не обнаружен, то система уведомляет об этом кассира и предлагает ему вручную ввести идентификационный код. Проблемы с коммутацией с внешней системой вычисления налога. 13

14 Степень формализации прецедента Сжатый – аннотация в виде одного абзаца. Обычно так описывают только главный успешный сценарий. Свободный – неформальный стиль описания, несколько абзацев и несколько сценариев. Развернутый – самый подробный стиль описания, детализируются все шаги и варианты развития сценария. 14

15 Детальное описание прецедента 15

16 16

17 17

18 18

19 19

20 Как определить прецедент? 1. Выделить задачи (цели) пользователей. 2. Определить для каждой из них отдельный прецедент. Вместо вопроса «Каковы прецеденты для данной системы?» возникает вопрос «Каковы задачи исполнителей?» Прецедент описывает типичные взаимодействия пользователей с системой. 20

21 Семинар для формулирования требований к системе Основные вопросы: Что делает система? определяет процедуры и функции системы, а также определяет их сложность и структуру. Каковы задачи исполнителей? определяет потребности заинтересованных лиц в контексте обсуждаемой системы. Определение корреляции этих вопросов помогает находить более эффективные решения. 21

22 Определение основных исполнителей, задач и прецедентов 1. Определить рамки системы: Программное приложение, Аппаратно-программный комплекс, Включает ли конкретных исполнителей или всю организацию. 2. Идентификация основных исполнителей, потребности и цели которых удовлетворяются системой. 3. Для каждого исполнителя определить его задачи. 4. Определить прецеденты, удовлетворяющие потребностям каждого исполнителя, присвоить им имена в соответствии с задачами. Обычно прецеденты соответствуют задачам пользователя. 22

23 Исполнители и задачи Вопросы, задаваемые при определении исполнителей и задач: Кто запускает и выключает систему? Кто системный администратор? Кто контролирует деятельность и производительность системы? 23 Почему исполнителем для прецедента «Оформление продажи» является кассир а не покупатель? Почему покупатель не включен в список исполнителей?

24 Основные исполнители и их задачи Имя прецедента начинается с существительного, описывающего действие. Исключение: прецедент управление, который описывает сразу несколько действий, например, создание, восстановление, обновление и удаление. 24

25 Исполнители Исполнитель – это сущность, обладающая поведением. К числу исполнителей может относится и сама разрабатываемая система, если она вызывает службы других систем. Исполнители бывают: Основные – их задачи выполняются с использованием системы, например, кассир. Вспомогательные – обслуживают систему, например, служба авторизации платежей. Закулисные – заинтересованы в реализации, но не являются ни основными ни вспомогательными, например, налоговая служба. 25

26 Диаграмма прецедентов 26

27 Диаграмма прецедентов – это отличное изображение системного контекста, поскольку она отображает границы системы, внешние для системы понятия и способы использования системы. Основное внимание при работе над прецедентами следует уделять написанию текстовых документов, а не составлению диаграмм. 27

28 Требования в списках низкоуровневых свойств Основной мотив описания прецедентов – определение требований в контексте задачи (целей) и сценариев использования системы. Некоторые требования лучше описывать в дополнительной спецификации в виде сгруппированных по функциональному назначению списков. 28

29 Проблемы со списками Списки могут занимать десятки страниц. Сложно определять требования в общем контексте для таких списков. Решение – реализовать прецеденты для групп в списке. Если используются и списки и прецеденты, то требуется большее время для осмысления и согласования этих методов. 29

30 Списки высокоуровневых свойств системы Часто функциональные свойства системы описывают в кратких списках свойств высокого уровня в рамках документа «Видение». Это небольшой список, как правило не более 10 элементов. Список свойств системы: Регистрация продаж. Авторизация платежей (кредитных, чековых). Системное администрирование (управление пользователями, безопасностью, прочее). Автоматическая обработка информации о продажах. Взаимодействие с внешними системами в реальном времени (вычисление налоговых отчислений, системы складского учета, авторизация платежей). …. 30

31 Что лучше? Списки низкоуровневых свойств Списки высокоуровневых свойств Диаграммы прецедентов 31

32 32

33 Рекомендации по организации семинаров 33

34 Дополнительная спецификация Необходимо определить другие требования: Соглашение о лицензировании, Возможность поддержки системы, Требования к производительности и удобству, Надежность, Международные соглашения и стандарты, Физические требования к окружающей среде, Другие требования. Здесь содержится все что не вошло в документ «Видение» и словарь терминов. 34

35 Атрибуты словаря терминов Синонимы Описания Форматы Взаимосвязи с другими элементами Диапазон значений Правила проверки корректности 35

36 Диаграммы последовательностей Диаграмма последовательностей – это схема, которая для определенного сценария прецедента показывает генерируемые внешними исполнителями события и их порядок, а также события, генерируемые внутри самой системы. Назначение диаграммы – отображение событий, передаваемых исполнителями системе через её границы. 36

37 37

38 Диаграммы последовательностей строят на основе описания прецедентов. 38

39 Модели предметной области Модель предметной области используется для основы разработки программных объектов. Модель предметной области отображает основные классы понятий (концептуальные классы) предметной области, которые являются важными на этапе объектно- ориентированного анализа. Модель предметной области – это визуальное представление концептуальных классов и объектов реального мира в терминах предметной области. 39

40 Принципы создания модели предметной области 1. Составьте список кандидатов на роль концептуальных классов на основе списка категорий и метода анализа текстового описания. 2. Отобразите их в модели предметной области. 3. Добавьте необходимые ассоциации, отражающие связи, для которых требуется выделение памяти. 4. Добавьте атрибуты, необходимые для выполнения информационных требований. 40

41 Список кандидатов на роль концептуальных классов Запись Элемент Магазин Продажа Платеж Каталог продукции Спецификация продукта Запись позиции продажи Кассир Клиент Менеджер 41

42 Связь концептуальных классов и программных классов 42

43 43

44 Исходная модель предметной области 44

45 Рекомендации по назначению ассоциаций 45

46 Модель предметной области 46

47 Модель предметной области с атрибутами 47

48 48

49 Системные операции Описание системных операций содержит детальное поведение системы в терминах изменения состояния объектов модели предметной области после выполнения системных операций. Описания системных операций нужны в случае неудовлетворительного описания прецедентов. Прецеденты – основной источник информации о требованиях к проекту. 49

50 Пример Весь набор операций, выполняемых в процессе всех прецедентов, определяет открытый системный интерфейс, в ракурсе которого система рассматривается как единый компонент или класс. UML-систему в целом можно представить в виде одного класса. 50

51 Пример описания системной операции: enterItem При описании операций в модель предметной области зачатую приходится вводить новые концептуальные классы, атрибуты или ассоциации. 51

52 Рекомендации по составлению описаний 1. Определите системные операции из диаграмм последовательностей. 2. Составьте описание для сложных системных 3. При описании постусловий используйте следующие категории: Создание и удаление экземпляра Модификация атрибута Формирование и разрыв ассоциаций 52

53 Диаграмма взаимодействий: вычисление общей суммы продаж 53

54 Фрагмент предметной области 54

55 Связывание уровней интерфейса и предметной области Класс SaleJFrame не принимает участия в обработке а делегирует функцию уровню реализации. 55

56 Реализация прецедента Реализация прецедента – это концепция, позволяющая сохранить связь между требованиями, выраженными в виде прецедентов, и процессом проектирования объектов, которые этим требованиям удовлетворяют. Реализация прецедентов показывает, как определенный прецедент реализуется в рамках модели проектирования в терминах взаимодействующих объектов. 56

57 Диаграмма последовательности Диаграммы взаимодействия являются стандартным средством, используемым для иллюстрации реализации прецедента. Из диаграммы последовательности можно получить диаграмму взаимодействия. 57

58 Фрагмент диаграммы взаимодействия 58 Диаграммы взаимодействия являются стандартным средством, используемым для иллюстрации реализации прецедента.

59 Видимость объектов При разработке взаимодействующих между собой объектов следует обеспечить требуемый уровень видимости. 59

60 Формы видимости Видимость через атрибут Видимость через параметр Локальная видимость Глобальная видимость 60

61 Видимость посредством атрибута Объект ProguctCatalog виден для объекта Register, т.к. ProguctCatalog является атрибутом объекта Register. 61

62 Видимость посредством параметра Экземпляр ProductSpecification передается в качестве параметра. 62

63 Диаграмма классов с указанием методов 63

64 Диаграмма классов с видимостью посредством параметров 64

65 Обозначения для членов класса 65

66 Информация о членах классов для приложения розничная торговля 66

67 Изображение тела метода на диаграмме 67

68 68

69 Реализация класса Register 69

70 Диаграмма состояний: оформление продажи Диаграмма состояний иллюстрирует допустимый порядок внешних событий, требуется для сложных прецедентов. 70

71 Основной успешный сценарий (main success scenario, MSS) 1. Покупатель подходит к кассовому аппарату системы с выбранными товарами 2. Кассир открывает новую продажу 3. Кассир вводит идентификатор товара 4. Система записывает наименование товара и выдает его описание, цену и общую стоимость. Цена вычисляется на основе набора правил. Кассир повторяет действия, описанные в пп. 3-4 для каждого наименования товара 71

72 72