Лекция 05 (выявление и моделирование требований

Технология разработки
программного обеспечения
Лекция 5
Процесс разработки ПО
Процесс разработки ПО
• Выявление и описание требований – сбор данных о том, что
должна делать система;
• Планирование проекта разработки – оценка трудоемкости,
составление календарного планы, планирование качества,
управление рисками;
• Выявление вариантов использование
– моделирование вариантов использования
• Анализ – уточнение и структурирование требований
– моделирование хода анализ;
• Проектирование – реализация требований в архитектуре системы
– моделирование хода проектирование;
• Реализация (кодирование) – построение программного
обеспечения;
• Тестирование – проверяется, отвечает ли реализация
предъявляемым требованиям;
• Внедрение – передача ПО заказчику и организация его
практического применения.
Моделирование требований
Процесс разработки ПО
• Выявление и описание требований – сбор данных о том, что
должна делать система;
• Планирование проекта разработки – оценка трудоемкости,
составление календарного планы, планирование качества,
управление рисками;
• Выявление вариантов использование
– моделирование вариантов использования
• Анализ – уточнение и структурирование требований
– моделирование хода анализ;
• Проектирование – реализация требований в архитектуре системы
– моделирование хода проектирование;
• Реализация (кодирование) – построение программного
обеспечения;
• Тестирование – проверяется, отвечает ли реализация
предъявляемым требованиям;
• Внедрение – передача ПО заказчику и организация его
практического применения.
Требования заказчиков
• Функциональные требования.
• Не функциональные.
Функциональные требования
• Функциональные требования определяют
ожидаемое поведение системы – какие выходные
данные и какое поведение должно быть получено
при заданных входных данных.
• Для каждого функционального требования
должно быть детально описаны:
– все входные данные и их источники;
– единицы измерения и интервалы допустимых входных
значений;
– все выполняемые операции над входными данными;
– порядок проверки правильности входных данных;
– описание процесса преобразования входных данных в
выходные данные.
Не функциональные требования
1. требования к производительности;
2. проектные ограничения налагаемые на
реализацию;
3. требования к внешним интерфейсам.
Сценарии
• Людям обычно проще пояснить свои требования к ПО
путем их связывания с реальной жизнью (а не с
абстрактными понятиями).
• Они могут понимать и критиковать сценарии (ситуации)
того, как они могут взаимодействовать с ПС.
• Специалисты по выявлению и описанию требований к
ПО могут использовать информацию, полученную из
такого обсуждения, для формулировки реальных
требований к системе.
• Сценарии м.б. особенно полезными для добавления
деталей к общим описаниям требований.
• Сценарии являются описаниями примеров сеансов
взаимодействия пользователей с системой.
Варианты использования
(прецеденты)
• Традиционный подход к описанию
функциональных требований состоит в
– выявлении сценариев работы будущего ПО и
– их описании в виде вариантов использования (или
прецедентов).
• Варианты использования (ВИ, Use Cases)
специфицируют (детально описывают)
функциональность системы путем описания ее
поведения, зафиксированного в виде
взаимодействий пользователя с данной
системой.
Моделирование вариантов
использования
• Варианты использования – это специальный
способ записи требований.
• Моделирование вариантов использования
обычно происходит следующим образом:
1.Устанавливаются границы будущей системы.
2.Выявляются актеры.
3.Выявляются варианты использования :
- определяется вариант использования;
- устанавливаются основные и альтернативные потоки.
4.Предыдущие шаги повторяются, пока варианты
использования, актеры и границы системы не
стабилизируются.
Контекст системы
(границы системы)
• Контекст системы отделяет систему от остального
мира.
• Надо определить,
1.что является частью системы (находится внутри границ
системы) и
2.что находится вне системы (вне ее границ).
• Точное определение границ системы обычно играет
важную роль в выявлении функциональных (а иногда и
нефункциональных) требований.
• Актеры размещаются вне границ блока, а ВИ – внутри.
• В начале моделирования ВИ имеется лишь
предварительное представление о том, где находятся
границы системы.
• По мере выявления актеров и ВИ контекст системы
обретает все более четкие очертания.
Актеры
• Актеры – это роли, исполняемые сущностями,
непосредственно взаимодействующими с системой.
• Актер определяет роль, которую выполняет некоторая
внешняя сущность при непосредственном
взаимодействии с данной системой.
• Он может представлять роль пользователя или роль,
исполняемую другой системой или частью аппаратных
средств, которые касаются границ системы.
Выявление актеров
• Чтобы выявить актеров, нужно ответить на
вопросы:
–
–
–
–
–
–
–
Кто или что использует систему?
Какие роли они играют во взаимодействии?
Кто устанавливает систему?
Кто или что запускает и выключает систему?
Кто обслуживает систему?
Какие системы взаимодействуют с данной системой?
Кто или что получает и предоставляет информацию
системе?
– Происходит ли что-нибудь в точно установленное
время?
При моделировании актеров необходимо
помнить следующее:
• Актеры всегда являются внешними по
отношению к системе, следовательно, находятся
вне вашего контроля.
• Актеры взаимодействуют непосредственно с
системой – так они помогают в определении
контекста системы.
• Актеры представляют роли, исполняемые
людьми или сущностями по отношению к
системе, а не конкретных людей или сущностей.
• Один человек или сущность может играть по
отношению к системе множество ролей
одновременно или последовательно во времени.
Описания актера
• У каждого актера должно быть короткое,
осмысленное с прикладной точки зрения имя.
• Каждого актера должно сопровождать
краткое описание (одна или две строчки),
объясняющее, что данный актер из себя
представляет с прикладной точки зрения.
• Как и в классах, в обозначении актеров могут
быть представлены
– атрибуты актера и
– события, на которые он должен реагировать.
Определение вариантаиспользования
• Вариант использования описывает поведение,
демонстрируемое системой с целью получения
значимого результата для одного или нескольких актеров.
• Вариант использования описывает работу с системой
конкретного актера:
– варианты использования всегда инициируются актером;
– варианты использования всегда описываются с точки зрения
актеров.
Выявление вариантов использования
• Для выявления прецедента, нужно ответить на
вопросы:
1.Как каждый из актеров использует систему?
2. Что система делает для каждого актера?
• Выявление прецедентов начинается со списка
актеров.
• Затем рассматривается, как каждый актер
собирается использовать систему.
• Каждому варианту использования должно быть
присвоено короткое описательное имя
(описывающее действие).
• Моделирование вариантов использования это
итеративный процесс, осуществляемый путем
поэтапного уточнения.
• Все начинается с имени вариантов
использования, а детали дополняются позже.
• Эти детали состоят из исходного краткого
описания, которое уточняется до полной
спецификации.
Полезный список вопросов, на
которые следует ответить:
1. Какие функциональные возможности понадобятся
конкретному актеру от системы?
2. Система сохраняет и извлекает информацию?
3. Если да, какой из актеров инициирует это поведение?
4. Что происходит, когда система изменяет состояние
(например, при запуске и выключении системы)?
5. Кто-нибудь из актеров получает при этом уведомление?
6. Какие-либо внешние события оказывают влияние на
систему?
7. Как система узнает об этих событиях?
8. Система взаимодействует с какой-либо внешней
системой?
9. Система генерирует какие-либо отчеты?
Диаграмма вариантов использования
Словарь проекта
(глоссарий проекта)
• В глоссарии проекта должна быть отражена бизнестерминология и жаргон.
• Глоссарий проекта является, один из важных
артефактов проекта.
• Любая область деятельности имеет собственный
уникальный язык, и основной целью процесса
выработки и анализа требований является понимание
и фиксация этого языка.
• Глоссарий обеспечивает словарь ключевых деловых
терминов и определений.
• Он должен быть понятен всем участникам проекта,
включая все заинтересованные стороны.
• Кроме определения ключевых терминов глоссарий
проекта должен включать синонимы и омонимы.
Описание варианта использования
• Для каждого варианта использования (ВИ)
составляется:
– спецификация ВИ – текстовый документ
содержащий сжатое, но полное описание данного
ВИ;
– диаграмма ВИ – графическое описание связей
• между актерами и вариантами использования;
• между различными вариантами использования.
Спецификация варианта
использования
• Для спецификации вариантов использования нет UML
стандарта
• Обычно в шаблон простой спецификации ВИ входит
следующая информация:
1.имя прецедента;
2.ID прецедента;
3.краткое описание – абзац, в котором изложена цель
прецедента;
4.актеры, задействованные в прецеденте;
5.предусловия – условия, которые должны выполниться, чтобы
прецедент мог осуществиться; это ограничения на состояние
системы;
6.основной поток – шаги выполнения прецедента;
7.постусловия – условия, которые должны выполниться по
окончанию прецедента;
8.альтернативные потоки – список альтернативных основному
потоку событий.
Спецификация прецедентов
Пример программного обеспечения
аукциона
• Требуется разработать ПО для проведения
электронных аукционов.
• Продавцы размещают на продажу товары
(лоты), задает начальную цену и срок торгов.
• Покупатели могут назначать за товары свои
цены.
• Кто предложит наибольшую цену в течении
срока торгов, тот и получает право на покупку
товара за предложенную цену.
Спецификация первого варианта
использования
• ВИ1: Размещение некоторого элемента на аукционе.
– Основной актер: Продавец (Seller)
– Предусловие: Продавец должен подключиться к системе (logged
in).
• Основной успешный сценарий:
1.
2.
3.
4.
Продавец отправляет элемент (его категорию, описание,
изображение и т.п.) на аукцион.
Система показывает продавцу ранее выставленные на продажу
элементы.
Продавец определяет начальную цену торгов и время закрытия
аукциона.
Система принимает данный элемент и публикует его.
• Не стандартные сценарии:
– 2 a) В данной категории нет ранее выставленных на
продажу элементов.
• Система сообщает продавцу о такой ситуации.
Спецификация второго варианта
использования
• ВИ2: Выполнение торгов
– Основной актер: Покупатель
– Предусловие : Покупатель должен подключиться к системе (logged in).
• Основной успешный сценарий:
1. Покупатель выполняет поисковый запрос, или выполняет просмотр и выбор
нужного элемента.
2. Система показывает рейтинг продавца, начальную запрашиваемую цену,
текущую цену и высшую цену; просит покупателя предложить свойю цену.
3. Покупатель вводит предлагаемую цену, за которую он согласен купить
данный элемент.
4. Система принимает предлагаемую цену; блокирует деньги на счете
покупателя.
5. Система обновляет текущую цену; информирует других пользователей;
обновляет записи для данного элемента.
• Не стандартные сценарии :
– 3 a) Предлагаемые цены меньше чем максимальная предложенная цена.
• Система просит покупателя ввести новую цену.
– 4 a) Покупатель не имеет достаточно денег на своем счету.
• Система прерывает покупку и просит покупателя увеличить кол-во денег
на его счету.
Спецификация третьего варианта
использования
• ВИ3: Завершение аукциона
– Первичный актер: Аукционная система.
– Предусловие: Достигнуто завершение последней даты
проведения торговли.
• Основной успешный сценарий :
1. Выбрать покупателя предложившего наивысшую цену; послать эл.
письма выбранному покупателю и продавцу с информацией о
конечной цене элемента; послать email другим участникам торга.
2. Списать деньги со счета покупателя и записать их на счет продавца.
3. Разблокировать все деньги заблокированные у участников торга.
4. Передать со счета продавца комиссионные деньги на счет
организации аукциона.
• Не стандартные сценарии: Нет
Ветвление в варианте использования
• Для представления ответвления
потока используйте ключевое
слово Если (If).
• Пример, показывает хорошо
структурированный поток событий
с двумя ветвями.
• Каждая ветвь начинается с
ключевого слова Если и простого
логического выражения, такого как
Если пользователь вводит новое
количество, которое может быть
истинным (true) или ложным
(false).
• Структурированный текст под
выражением Если – это то, что
произойдет, если логическое
выражение истинно.
Ветвление в варианте использования
Повторение в потоке
• Иногда некоторое действие в потоке событий
необходимо повторить несколько раз.
• В моделировании ВИ это встречается не часто,
но нужно иметь некоторую стратегию для их
обработки.
• Спецификация UML не определяет способа
представления повторений в потоке, поэтому
предлагаются простые выражения с
ключевыми словами Для (For) и Пока (While).
Ключевое слово Для (For)
• Смоделировать повторение можно с помощью
ключевого слова Для.
n. Для (выражение, описывающее итерации)
n.1. Сделать что-то
n.2. Сделать что-то другое
n.3. …
n+1.
• Выражение, описывающее итерации, – это
некоторое выражение, результат которого –
количество итераций.
• Каждая структурированная строка после
выражения Для повторяется столько раз, сколько
определено в выражении.
Ключевое слово Пока (While)
• Ключевое слово Пока (While) используется
для моделирования последовательности
действий в потоке событий, которые
осуществляются до тех пор, пока некоторое
логическое условие истинно.
n. Пока (логическое условие)
n.1. Сделать что-то
n.2. Сделать что-то другое
n.3. …
n+1.
Моделирование альтернативных
потоков
• У каждого варианта использования есть один основной
поток и может быть множество альтернативных
потоков.
• Они являются альтернативными путями в варианте
использования, которые перехватывают ошибки,
ответвления и прерывания основного потока.
• Альтернативные потоки часто не возвращаются в
основной поток варианта использования.
Спецификация варианта использования с
альтернативными потоками
Альтернативный поток
InvalidEmailAddress
Альтернативный поток Cancel
Выявление альтернативных потоков
• Чтобы выявить альтернативные потоки, нужно
внимательно изучить основной поток.
• На каждом шаге основного потока
необходимо искать:
– возможные альтернативы основному потоку;
– ошибки, которые могут возникнуть в основном
потоке;
– прерывания, которые могут случиться в
конкретной точке основного потока;
– прерывания, которые могут произойти в любой
точке основного потока.
Отображение требований
• При отображении требований
устанавливаются взаимосвязи между
описанием требований и моделью вариантов
использования.
• Описание требований и модель ВИ
обеспечивают две «базы данных»
функциональных требований.
• Важно сопоставить эти две модели, чтобы
выяснить, нет ли в одной из них чего-то, что не
охвачено в другой, и наоборот.
Отображение требований (2)
• Между отдельными функциональными
требованиями и вариантами использования
могут быть отношения «многие-ко-многим».
– один прецедент будет охватывать множество
отдельных функциональных требований, и
– одно функциональное требование может
появляться в нескольких разных прецедентах.
Когда применять моделирование
вариантов использования
• Варианты использования хорошо применять
для определения функциональности системы.
• Они плохо подходят для выявления
ограничений системы.
• Варианты использования фиксируют
функциональные требования и поэтому не
эффективны для систем, в которых
доминируют нефункциональные требования.
Когда следует применять варианты
использования
• Варианты использования являются лучшим
выбором для фиксирования требований в тех
случаях, когда:
– в системе преобладают функциональные
требования;
– в системе много типов пользователей, которым
она предоставляет разные функциональные
возможности (много актеров);
– в системе много интерфейсов (много актеров).
Когда следует применять варианты
использования
• Варианты использования не стоит применять
в тех случаях, когда:
– в системе преобладают нефункциональные
требования;
– в системе мало пользователей;
– в системе мало интерфейсов.
Дополнительные возможности
моделирования вариантов
использования
Обобщение актеров
• Обобщение актеров выносит поведение,
общее для двух или более актеров, в
актера-родителя.
• Общее поведение можно вынести путем
обобщения актеров.
Например
• Создается абстрактный актер, называемого Purchaser
(покупатель), который взаимодействует с прецедентами
ListProducts, OrderProducts и AcceptPayment.
• Customer и SalesAgent – это конкретные актеры, потому что
данные роли могут выполнять реальные люди (или другие
системы).
• Purchaser – абстрактный актер, поскольку он является
абстракцией, введенной просто для представления общего
поведения (возможности делать покупки) двух конкретных
актеров.
• Customer и SalesAgent наследуют все роли и отношения с
прецедентами своего абстрактного родителя.
Обобщение вариантов
использования
• Обобщение ВИ выполняется, если есть один
или более ВИ, которые на самом деле
являются уточнениями (специализациями)
более общего прецедента.
• Данный прием следует применять, только
если он упрощает модель ВИ.
• Обобщение ВИ выносит поведение, общее
для одного или более ВИ, в родительский ВИ.
Обобщение вариантов использования
• При обобщении ВИ дочерние ВИ представляют
более специализированные формы их
родителей.
• Потомки могут:
– наследовать возможности родительского ВИ;
– вводить новые возможности;
– переопределять (менять) унаследованные
возможности.
• Дочерний ВИ автоматически наследует все
возможности своего родителя.
• Однако не все возможности ВИ могут быть
переопределены.
Описание родительского варианта
использования FindProduct
Описание дочернего варианта
использования FindBook
Отношение «include»
• Иногда в вариантах использования содержится
многократное описание одних и тех же действий.
• Например, рассмотрим систему Personnel (персонал)
– Практически любое действие системы начинается с получения
данных о конкретном служащем.
– Если бы эту последовательность событий приходилось писать
каждый раз, когда необходимы данные служащего, прецеденты
имели бы повторяющиеся части.
• Отношение «include», устанавливаемое между ВИ,
позволяет включить поведение одного ВИ в поток другого
варианта использования.
• Отношение «include» выносит шаги, общие для нескольких
ВИ, в отдельный вариант использования, который потом
включается в остальные.
Прецеденты системы Personnel
Включение прецедента
Отношение «extend»
• Отношение «extend» предоставляет возможность
ввести новое поведение в существующий вариант
использования.
• Базовый вариант использования предоставляет набор
точек расширения (extension points) – точек входа, в
которые может быть добавлено новое поведение.
• А расширяющий вариант использования предоставляет
ряд сегментов вставки, которые можно ввести в
базовый прецедент в места, указанные точками входа.
• Отношение «extend» может использоваться для того,
чтобы точно указать, какие именно точки
расширения базового варианта использования
подлежат расширению.
Отношение «extend»
Обозначение точек расширения
Расширяющий прецедент
Когда применять дополнительные
возможности
• Применяйте дополнительные возможности, только если
они упрощают модель и делают ее более понятной.
• Применяйте дополнительные возможности, только если
они упрощают модель варианта использования.
• Лучшие модели вариантов использования – это простые
модели.
• Модель варианта использования – это описание
требований, то есть она должна быть понятной не только
разработчикам моделей, но и заинтересованным
сторонам.
• Простая модель вариантов использования, в которой
дополнительные возможности применяются редко или
вообще отсутствуют, предпочтительнее модели,
переполненной дополнительными возможностями.
Советы и рекомендации по
написанию прецедентов
1. Делать варианты использования
короткими и простыми.
2. Уделять основное внимание на «что
требуется», а не «как делается».
3. Избегать функциональной декомпозиции.
Избегайте функциональной
декомпозиции