Учебное пособие 1288

- взаимодействует с бухгалтером на тему своего финансового статуса. Персонаж ожидает удобный и простой интерфейс фиксирования

трудозатрат, прозрачный контроль времени и оповещения о статусе календарного события/компенсации расходов. Также он хочет индивидуально общаться в удобной среде с менеджером и бухгалтером.

Теперь рассмотрим персонажа «Менеджер». Данный персонаж работает с продуктом, совершая следующие ежедневные активности:

-управление расписанием сотрудника;

-использование отчетов;

-взаимодействие со всеми типами пользователей.

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

Персонаж «Администратор» работает с продуктом, совершая следующие ежедневные активности:

-добавление сотрудников в систему;

-обновление информации о сотрудниках;

-выдача аккаунтов;

-загрузка и обновление данных отчетов;

-редактирование прав доступа;

-редактирование событий.

Персонаж ожидает возможность загрузки данных в разных форматах, удобного механизма регистрации, возможности редактирования информации о сотрудниках и их задачах.

Персонаж «Бухгалтер» работает с продуктом, совершая следующие ежедневные активности:

-использование финансовых отчетов;

-расчет заработной планы исходя из данных о трудозатратах;

-взаимодействие с сотрудником.

Персонаж ожидает возможность удобной работы с отчетами, гибкого механизма формирования финансовых отчетов и возможности общения с сотрудником. Также персонаж ожидает оповещения о финансовых изменениях от сотрудников.

На последнем этапе формирования персонажей им присваивается приоритет:

-сотрудник (второстепенный);

-менеджер (ключевой);

-администратор (второстепенный);

-бухгалтер (дополнительный).

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

11

1.5. Задание на лабораторную работу № 1

Задание

Выполнить подготовку к этнографическому интервью и произвести интервьюирование пользователя программного продукта, осуществляемое в рамках проекта по его модернизации.

При очном проведении занятий в роли интервьюируемого выступает преподаватель.

При дистанционном обучении в качестве программного продукта можно использовать бакалаврский дипломный проект, сайт ЭИОС ВГТУ или иные широко известные программные продукты.

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

Отчет

Отчет должен содержать:

-титульный лист;

-задание;

-описание набора моделей персонажей, включающее определение таких параметров как «Класс персонажа», «Активности персонажа», «Ожидания персонажа».

2. ЛАБОРАТОРНАЯ РАБОТА № 2 «Анализ требований. Диаграммы вариантов использования»

2.1. Общие сведения

Цель работы - изучение методов формализации требований персонажей.

2.2 Анализ требований

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

Леонид Новиков в русской редакции нотации RUP (Rational Unified Process) приводит следующее определение: «Требование – это условие или возможность, которой должна соответствовать система» [1].

В свою очередь в IEEE Std 610.12-1990 (IEEE Standard Glossary of Software Engineering Terminology) понятие требования трактуется шире. Требование – это:

1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей.

12

2.Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам.

3.Документированное представление условий или возможностей для пунктов 1 и 2.

Карл Вигерс определяет три уровня требований:

1.Бизнес-требования определяют высокоуровневые цели организации или клиента – заказчика.

2.Пользовательские требования описывают цели и задачи пользователей системы, которые должны выполняться пользователями при помощи создаваемого ПО.

3.Функциональные требования определяют функциональность ПО, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований.

Также выделяют нефункциональные требования. Нефункциональные требования регламентируют внутренние и внешние условия или атрибуты функционирования системы. Карл Вигерс выделяет следующие группы нефункциональных требований:

1.Атрибуты качества описывают дополнительные характеристики продукта в различных измерениях, важных для пользователей и разработчиков. Эти характеристики включают практичность, портабельность, целостность, эффективность, устойчивость.

2.Ограничения – это формулировка условия, которое модифицирует требование или набор требований, сужая выбор возможных решений.

3.Бизнес-правила включают корпоративную политику законодательные акты индустриальные стандарты учетную практику и алгоритмы вычислений.

4.Внешние интерфейсы.

Системные требования описывают высокоуровневые требования для ПО, которое содержит много подсистем.

Анализ требований включает три типа деятельности:

1.Сбор требований – общение с клиентами и пользователями, чтобы определить, каковы их требования; анализ предметной области.

2.Анализ требований – определение, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; решение этих проблем; выявление взаимосвязи требований.

3.Документирование требований – требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.

Анализ требований является длинным и трудным процессом, т.к. полнота

икачество анализа требований играют ключевую роль в успехе всего проекта. Для того, чтобы выявить требования от клиента (заказчика) существуют

следующие методы: проведение интервью и семинаров, использование фокусгрупп или создание списков требований контрактного стиля.

13

Более современные методы включают создание прототипов (макетов) и сценариев использования. Также можно использовать комбинацию этих методов, чтобы выявить точные более требования заинтересованных лиц.

2.3 Диаграммы вариантов использования

Для формализации функциональных требований в языке UML применяются диаграммы использования (прецедентов).

Диаграммы вариантов использования описывают взаимоотношения и зависимости между группами вариантов использования и действующих лиц, участвующими в процессе [2].

Диаграмму вариантов использования есть смысл строить во время изучения технического задания, т.к. она является исходным концептуальным представлением системы в процессе ее проектирования и разработки [3].

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

мой [4].

Важно понимать, что диаграммы вариантов использования не предназначены для отображения проекта и не могут описывать внутреннее устройство системы. Диаграммы вариантов использования предназначены для упрощения взаимодействия с будущими пользователями системы, с клиентами, и особенно пригодятся для определения необходимых характеристик системы. Другими словами, диаграммы вариантов использования говорят о том, что система должна делать, не указывая сами применяемые методы [2].

Прецеденты (варианты использования – Use Cases) – это подробные процедурные описания вариантов использования системы всеми заинтересованными лицами, а также внешними системами.

Заинтересованные лица и внешние системы рассматриваются как акторы (Actors) – действующие лица. Варианты обозначения акторов представлены на рис. 3.

а- «проволочный человечек»; б - класс с меткой «Actor»;

в- произвольное изображение

Рис. 3. Варианты обозначения акторов

14

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

Условное обозначение прецедента приведено на рисунке 4.

Рис. 4. Условное обозначение варианта использования

Интерфейсы (Interfaces) служат для спецификации параметров модели, которые видимы извне без указания их внутренней структуры. Применительно к диаграммам вариантов использования, интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор сервисов или функциональности для акторов. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат только операции без указания особенностей их реализации. Формально интерфейс эквивалентен абстрактному классу без атрибутов и методов с наличием только абстрактных операций [5].

Условное обозначение интерфейса приведено на рисунке 5.

Рис. 5. Условное обозначение интерфейса

Примечания (Notes) в языке UML предназначены для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта. В качестве такой информации могут быть комментарии разработчика (например, дата и версия разработки диаграммы или ее отдельных компонентов), ограничения (например, на значения отдельных связей или экземпляры сущностей) и помеченные значения. Применительно к диаграммам вариантов использования примечание может носить самую общую информацию, относящуюся к общему контексту системы [5].

Условное обозначение примечания представлено на рисунке 6.

Рис. 6. Условное обозначение примечания

15

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

–ассоциаций;

–обобщения;

–включения;

–расширения.

Отношение ассоциации (Association relationship) отображает возможность использования актором прецедента и обозначается сплошной линией (рисунок 7).

Рис. 7. Отношение ассоциации

Отношение обобщения (Generalization relationship) показывает, что компонент (актор или прецедент) является частным случаем другого компонента. Графически отношение обобщения обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования (рисунок 8) [6].

Рис. 8. Отношение обобщения

Отношения включения и расширения определяют связи между прецедентами. Отношение включения (Include relationship) указывает на то, что поведение одного прецедента включается в другой прецедент в качестве составного

компонента. Особенность включения заключается в том, что включаемый прецедент должен быть обязательным для дополняемого (включение должно быть безусловным, а дополняемый вариант использования без включения не сможет выполняться) [4]. Пример отношения включения представлен на рисунке 9.

Рис. 9. Отношение включения

16

В отличие от отношения включения, отношение расширения (Extend relationship) определяет потенциальную возможность включения поведения одного варианта использования в состав другого, т. е. дочерний вариант использования может как вызываться, так и не вызываться родительским.

Стрелка расширения должна быть направлена от включаемого варианта к базовому и иметь метку «extend».

Варианты использования, которые расширяют базовый, подключаются к нему (активируются при его выполнении) через так называемые точки расширения (extension points). Каждая точка расширения маркируется меткой и условием (condition) активации. Обычно перечень точек расширения указывается в базовом варианте использования ниже горизонтальной линии. Пример отношения расширения представлен на рисунке 10.

Рис. 10. Отношение расширения

Наиболее правильный порядок построения диаграмм вариантов использования следующий:

1.Выделить группы действующих лиц (работающих с системой поразному, часто из-за различных прав доступа).

2.Идентифицировать как можно больше вариантов использования (процессов, которые могут выполнять пользователи). При этом не следует делить процессы слишком мелко, нужно выбирать лишь те, которые дадут пользователю значимый результат.

3.Дополнить прецеденты словесным описанием (сценарием):

–для каждого прецедента создать разделы: «главная последовательность»

и«альтернативные последовательности»;

–при составлении сценария нужно упорно задавать заказчику вопросы «что происходит?», «что дальше?», «что еще может происходить?» и записывать ответы на них [4].

Некоторые рекомендации по построению диаграмм вариантов использования: 1. На диаграммах не следует отображать особенности реализации вариантов использования и внутренней организации системы, связанные со специфи-

кой используемых программных и аппаратных средств.

2. Для описания альтернативного поведения применяйте расширения, а не предложения с «если» в теле главного варианта использования.

17

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

4.Не допускайте деталей графического интерфейса пользователя в варианте использования.

5.Описывать систему следует с точки зрения пользователя.

Вкачестве примера на рисунке 11 представлена диаграмма вариантов использования для информационной системы «Пошив одежды по индивидуальным меркам».

Вданной системе выделены следующие действующие лица (акторы):

–руководитель;

–администратор;

–сотрудник;

–клиент.

Вприведенной диаграмме вариантов использования связи между акторами и прецедентами представляют собой отношения ассоциации.

Отношение включения используется между прецедентами «Создание заказа» и «Расчет метража». Это означает, что создание заказа не может быть выполнено без расчета метража.

Отношение расширения используется между прецедентами «Редактирование данных о заказе» и «Расчет метража». Это означает, что при редактировании данных о заказе не обязательно заново выполнять расчет метража. Расчет метража выполняется только в том случае, если изменились мерки клиента.

Отношение обобщения используется для прецедентов «Формирование отчета о заказах» и «Формирование отчета о расходе материалов». Эти прецеденты являются частными случаями прецедента «Формирование отчета».

ПО для построения диаграмм вариантов использования

Втаблице 1 приведено специализированное ПО для построения UMLдиаграмм.

18

В таблице 2 приведено ПО для построения графов и графические редакторы с возможностью построения диаграмм вариантов использования.

Таблица 2

ПО для построения графов и графические редакторы

2.4Задание на лабораторную работу №2

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

2.4.2Выполните построение диаграммы вариантов использования для персонажа, созданного при выполнении лабораторной работы № 1.

Отчет

Отчет должен содержать:

-титульный лист;

-задание;

-диаграммы вариантов использования для персонажей, созданных при выполнении ЛР № 1.

3. ЛАБОРАТОРНАЯ РАБОТА № 3 «Прототипирование пользовательского интерфейса»

3.1. Общие сведения

Цель работы – изучение методов и средств создания прототипов интерфейса информационной системы.

3.2 Прототипирование, как один из этапов построения оптимального интерфейса

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

20