Методы и средства разработки И. Томский политехнический университет р. В. Ковин, Е. А. Мирошниченко
 Скачать 2.85 Mb.
|
|
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное автономное образовательное учреждение высшего образования «НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» Р.В. Ковин, Е.А. Мирошниченко Методы и средства разработки информационных систем ЛАБОРАТОРНЫЙ ПРАКТИКУМ Томск 2021 2 Введение Лабораторный практикум посвящен решению практических задач по проектированию информационных систем, включая эскизное и техническое проектирование, описание решений с помощью диаграмм UML, проектирование моделей баз данных и интерфейсов пользователя. Практикум содержит 12 лабораторных работ, относящихся к 9 разделам дисциплины. Особенностью данного практикума является то, что лабораторные работы связаны с разработкой некоторой системы. Задание выдается студенту индивидуально (см. приложение), а каждая лабораторная посвящена отдельному этапу разработки системы. Содержание практикума соответствует рабочей программе дисциплины «Методы и средства разработки информационных систем» для студентов, обучающихся по направлению 09.03.02 Информационные системы и технологии. 3 1. ЛАБОРАТОРНАЯ РАБОТА №1. Пользовательские истории. Варианты использования ЦЕЛЬ РАБОТЫ Изучение и получение навыков работы описания вариантов использования и пользовательских историй. Введение Существуют различные методики для выявления требований к поведению системы и их фиксации. В данной лабораторной работе рассматриваются пользовательские истории и варианты использования, но в большей степени внимание уделяется вариантам использования. 1.1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 1.1.1. Пользовательские истории (User Stories) Пользовательские истории (англ. User Stories) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории — быстрый способ документировать требования, без необходимости разрабатывать обширные формализованные документы и впоследствии тратить ресурсы на их поддержание. Цель пользовательских историй состоит в том, чтобы быть в состоянии оперативно и без накладных затрат реагировать на быстро изменяющиеся требования реального мира. Пользовательские истории традиционно применяются в гибких методологиях разработки. Для описания пользовательских историй используется следующий формат: As a {user type}, I can {do something} so that {I receive some benefit} Как {тип пользователя} я могу {делать что-нибудь} для того, чтобы {получить некоторую выгоду} Примеры: • As a course participant, I can submit a question so that I get my concerns about the course materials addressed. 4 • As a course instructor, I can view all course participant questions so that I can respond in a timely manner. • Как модератор форума я могу удалять непристойные сообщения участников для того, чтобы поддерживать порядок на форуме. Преимущества пользовательских историй: • Истории короткие. Они представляют маленькие кусочки бизнес-ценности, которые можно реализовать в период от нескольких дней до нескольких недель. • Позволяют разработчикам и клиентам обсуждать требования на протяжении всей жизни проекта. • Нуждаются в очень небольшом обслуживании. • Рассматриваются только в момент использования. • Поддерживают близкий контакт с клиентом. • Позволяют разбить проект на небольшие этапы. • Подходят для проектов, где требования изменчивы или плохо поняты. • Облегчают оценку заданий. Недостатки пользовательских историй: • Без определенных приемочных испытаний являются открытыми для различных интерпретаций, что усложняет их использование как основу для соглашения. • Требуют близкого контакта с клиентом на протяжении всего проекта, что в некоторых случаях может быть сложно либо приводить к накладным затратам. • Могут плохо масштабироваться на больших проектах. • Полагаются на компетентность разработчиков. • Используются для начала дискуссии. К сожалению, они могут не фиксировать окончание дискуссии и таким образом не в состоянии служить надежным методом документации системы. 1.1.2. Варианты использования (Use Cases) Вариант использования (ВИ), сценарий использования, прецедент использования (англ. use case) — это описание поведения системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. 5 Вариант использования— формальное описание взаимодействия системы и пользователя при решении конкретной задачи. Каждый ВИ нацелен на конкретную задачу и описывает некоторое функциональное требование. Вариант использования описывает, «кто» и «что» может сделать с рассматриваемой системой, или что система может сделать с «кем» или «чем». Методика вариантов использования применяется для выявления требований к поведению системы. Рассмотрим цели ВИ. ВИ рассматривают систему как «черный ящик». Взаимодействия с системой, включая системные ответы, описываются с точки зрения внешнего наблюдателя. При этом внимание сосредотачивается на том, что система должна сделать, а не как это должно быть сделано. Достоинства модели вариантов использования заключаются в том, что она: • определяет пользователей и границы системы; • определяет системный интерфейс; • удобна для общения пользователей с разработчиками; • используется для написания тестов; • является основой для написания пользовательской документации; • хорошо вписывается в любые методы проектирования (как объектно- ориентированные, так и структурные). Различают два уровни описания ВИ: • Абстрактный уровень / Бизнес-сценарий использования — описывает процесс, ценный для бизнес-агента. • Системный уровень / Системный сценарий использования описывает, что актор может сделать, взаимодействуя с системой. Обычно описывается на уровне функций системы. К каждому ВИ предъявляются требования. ВИ должен: • Описывать, что именно система должна сделать, чтобы актор достиг своей цели. • Не затрагивать деталей реализации. • Иметь достаточный уровень детализации. • Не описывать пользовательские интерфейсы и экраны. Это делается во время проектирования пользовательского интерфейса. Различают три уровня детализации при описании ВИ (рис. 1.1). 6 1. Краткий. На этом уровне ВИ описывается в несколько предложений. 2. Обычный. На этом уровне ВИ описывается в несколько абзацев. 3. Детализированный. На этом уровне ВИ представляет собой формальный документ, основанный на подробном шаблоне с различными разделами. Именно этот вариант (детализированный) подразумевается в большинстве случаев под понятием варианта использования. Рис. 1.1. Уровни детализации при описании ВИ Как правило такой формальный документ состоит из следующих разделов: Название / Имя Цель Акторы Стейкхолдеры Предварительные условия / Начальное состояние Активаторы Порядок событий / Основной сценарий Альтернативные сценарии В этом списке разделы, не являющиеся обязательными, отмечены курсивом. Назначение, рекомендуемая форма записи и примеры этих разделов показаны в таблице: 7 Раздел Назначение Форма записи Примеры Название / Имя 1 Краткое описание достижимой цели Желательно в формате глагол- существительное Открыть документ, Купить товар Цель Описывает то, чего пользователь намеревается достигнуть с этим ВИ Кратко, до нескольких предложений Возможность работы с документом Акторы Кто-то или что-то вне системы и влияющий на систему или находящийся под её влиянием Может быть человеком, устройством, другой системой или подсистемой, или временем. Человек в реальном мире может быть представлен несколькими акторами Участник форума, Модератор форума, Администратор системы Стейкхолдеры Человек или группа, которых затрагивает ВИ Кратно в виде названия должности, подразделения, организации и ФИО финансовый отдел Предварительные условия / Формулировка условий, при которых данный Краткое описание Документ выбран, пользователь в 8 Раздел Назначение Форма записи Примеры Начальное состояние 1 ВИ может быть инициирован роли «Редактор документов» Выполнен ВИ «Выбрать документ», пользователь авторизован в системе Активаторы Активатор — это событие, инициирующее выполнение сценария. Событие может быть: внешним временным внутренним Краткое описание Загрузка веб- страницы Срабатывание датчика пожарной системы Порядок событий / Основной сценарий 1 Описание типичного хода событий Обычно ряд пронумерованных шагов 1. Пользователь инициировал открытие документа 2. Система открыла документ для просмотра 1 Даны два альтернативных названия раздела. Можно использовать любой из них 9 Раздел Назначение Форма записи Примеры Альтернативные сценарии Описание нетипичного хода событий. Предусловие: <описание условия, при которых возникает альтернативный сценарий> Ряд пронумерованных шагов с описанием. Каждый альтернативный сценарий описывается отдельно и нумеруется. Название раздела можно не писать Альтернативный сценарий №1 Предусловие: на шаге 2 основного сценария произошла ошибка. 3. Система информирует пользователя об ошибке. Конец Примечание 1. Если для всех ВИ стейкхолдеры и/или акторы идентичны, то их можно не описывать в каждом ВИ, а описать перед всеми ВИ в виде замечания. Примечание 2. Если инициатором ВИ является человек (пользователь), а не система (ее часть, сервис, сигнал, таймер и т.п.) и в первом шаге сценария описывается такое действие по инициации, то раздел Активатор не используется. В качестве примера опишем ВИ открытия документа для некоторой системы. Акторы__10_Пользователь_Стейкхолдеры'>ВИ «Открыть документ» Цель Возможность работы с документом Акторы 10 Пользователь Стейкхолдеры Пользователь, финансовый отдел Начальное состояние Документ выбран, пользователь в роли «Редактор документов» Основной сценарий 1. Пользователь инициировал открытие документа 2. Система открыла документ для просмотра Альтернативный сценарий №1 Предусловие: на шаге 2 Основного сценария доступ к документу закрыт. 3. Система информирует пользователя об отсутствии доступа к документу Аналогично опишем ВИ «Отправить электронное письмо» для некоторой почтовой программы. ВИ «Отправить электронное письмо» Цель Отправить созданное письмо с проверкой корректности его атрибутов. Начальное состояние Выполнен ВИ «Создать новое письмо» или ВИ «Создать ответ на письмо». Акторы Пользователь Основной сценарий 1. Пользователь выполняет команду отправки письма. 2. Программа проверяет, правильно ли заполнено поле «Адрес». 3. Если нет, программа сообщает об ошибке и отменяет отправку. Конец. 4. Если да, то программа проверяет, заполнено ли поле «Тема». 5. Если нет, программа выдает предупреждение, но не отменяет отправку. 6. Программа помещает письмо в папку «Исходящие» и отсылает его. 7. После отправки программа перемещает письмо в папку «Отправленные». 11 Сценарий обработки ошибок 2 Предусловие: на шаге 6 основного сценария происходит ошибка отправки письма (сбой сети и т. п.) 7. Программа сообщает об ошибке и предлагает сохранить текст письма в файл. 8. Если пользователь согласен сохранить текст, выполняется ВИ «Сохранить черновик в файл». На рис. 1.2 представлено графическое изображение этого альтернативного сценария (белые прямоугольники шагов 7 и 8). Рис. 1.2. Графическое изображение альтернативного сценария Если альтернативных сценариев много и часть из них является терминальными (рис. 1.3), то описание всех альтернативных ВИ становится громоздким и сложным для восприятия. Рис. 1.3. Графическое изображение множества альтернативных сценариев 2 Специальный вид альтернативного сценария. 12 В этом случае допускается не оформлять их как альтернативные, а включать в текст основного сценария. В нашем примере шаг 6 может быть записан так: 1. Программа помещает письмо в папку «Исходящие» и отсылает его. Если происходит ошибка отправки письма (сбой сети и т. п.), то программа сообщает об ошибке и предлагает сохранить текст письма в файл. Если пользователь согласен сохранить текст, выполняется ВИ «Сохранить черновик в файл». Конец. Ключевое слово, позволяющее включить альтернативный сценарий в основной, это «ЕСЛИ». На практике могут использоваться различные синонимы: «В СЛУЧАЕ», «КОГДА» и др. Однако не следует увлекаться этим и включать в один шаг основного сценария сразу несколько альтернативных. Это может ухудшить понимание шага сценария. При написании сценариев рекомендуется применять простое правило — чередование шагов Актор-Система: 1. Пользователь выполнил… 2. Система… 3. Пользователь выполнил… 4. Система… 5. Пользователь выполнил… 6. Система… Это правило позволяет продемонстрировать действия актора (пользователя) и реакцию на него системы. В дальнейшем именно такие сценарии могут стать основой для тестовых сценариев. Рассмотрим типовые ошибки описания сценариев. В следующем примере не раскрыта промежуточная реакция системы: 1. Пользователь выполнил… 2. Пользователь выполнил… 3. Пользователь выполнил… 4. Пользователь выполнил… 5. Система… В следующем примере не раскрыта конечная реакция системы: 1. Пользователь выполнил… 2. Система… 13 3. Пользователь выполнил… 4. Система… 5. Пользователь выполнил… В следующих примерах сделано излишнее акцентирование на интерфейсе пользователя 1. Пользователь нажал на кнопку «Открыть» 2. Система показала документ в новом окне. Документ представлен в видах: оглавление и основной текст 1. Пользователь нажал на кнопку «Открыть» 2. Система показала диалоговое окно, содержащее список файлов, список папок, дисков и сетевых подключений 3. Пользователь, используя мышь выбрал нужный файл и нажал кнопку «Открыть» 4. Система…. 1.2. ПРАКТИЧЕСКАЯ ЧАСТЬ 1.2.1. Практическое задание В качестве практического задания необходимо: 1. Описать пользовательские истории для системы, создаваемой студентом в рамках индивидуального задания на дисциплину. 2. Описать варианты использования для системы, создаваемой студентом в рамках индивидуального задания на дисциплину. Для описания можно использовать текстовый редактор Microsoft Word или подобный. 1.2.2. Список контрольных вопросов для самопроверки 1. Для чего используются варианты использования и пользовательские истории? 2. Какие обстоятельства затрудняют применение пользовательских историй? 3. Какой уровень детализации традиционно применяется при описании ВИ? 14 1.3. ТРЕБОВАНИЯ К ОТЧЕТУ Отчет должен содержать следующие разделы: 1. Титульный лист, оформленный согласно утвержденному образцу. 2. Цели и задачи выполняемой лабораторной работы. 3. Пошаговое описание выполняемых заданий лабораторной работы: 4. Ответы на контрольные вопросы. 5. Заключение. 15 2. ЛАБОРАТОРНАЯ РАБОТА №2. Диаграммы UML. Диаграмма вариантов использования ЦЕЛЬ РАБОТЫ Изучение и получение навыков создания диаграмм вариантов использования. Введение Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Умение создавать такую диаграмму является важным навыком для специалистов, имеющих отношение к разработке программного обеспечения. 2.1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 2.1.1. Основные элементы диаграммы Диаграмма вариантов использования (англ. use case diagram) в UML — диаграмма, отражающая отношения между акторами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне. Прецедент (ВИ) соответствует отдельному сервису системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Основное назначение диаграммы — описание функциональности и поведения, позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать проектируемую или существующую систему. На рис. 2.1 показаны основные элементы диаграммы: актор и ВИ / прецендент. 16 Рис. 2.1. Основные элементы диаграммы ВИ На диаграмме актор и ВИ соединяются сплошными линиями без стрелок (рис. 2.2). Рис. 2.2. Пример связей актора с ВИ 2.1.2. Отношения между элементами Между ВИ могут быть разные отношения. Отношение обобщения служит для указания того факта, что некоторая сущность А может быть обобщена до сущности В. В этом случае сущность А будет являться специализацией сущности В. На диаграмме данный вид отношения можно отображать только между однотипными сущностями (между двумя вариантами использования или двумя актерами). Отношение показывается в форме стрелки с не закрашенным треугольником. Треугольник ставится у более общего прецедента (рис. 4.3). 17 Рис. 2.3. Пример обобщения между ВИ Обобщение между акторами показано на рис. 4.4. Рис. 2.4. Пример обобщения между акторами Отношение включения указывает, что некоторое заданное поведение одного варианта использования обязательно включается в качестве составного компонента в |