Скачать презентацию
Идет загрузка презентации. Пожалуйста, подождите
Презентация была опубликована 10 лет назад пользователемВиктория Мынкина
1 Технология разработки программного обеспечения Лекция 5 Процесс разработки ПО
2 Выявление и описание требований – сбор данных о том, что должна делать система; Планирование проекта разработки – оценка трудоемкости, составление календарного планы, планирование качества, управление рисками; Выявление вариантов использование – моделирование вариантов использования Анализ – уточнение и структурирование требований – моделирование хода анализ; Проектирование – реализация требований в архитектуре системы – моделирование хода проектирование; Реализация (кодирование) – построение программного обеспечения; Тестирование – проверяется, отвечает ли реализация предъявляемым требованиям; Внедрение – передача ПО заказчику и организация его практического применения.
3 Процесс разработки ПО на основе моделирования 1.Моделирование 1.моделирование требований – сбор данных о том, что должна делать система; 2.моделирование хода анализ – уточнение и структурирование требований; 3.моделирование хода проектирование – реализация требований в архитектуре системы; 2.Реализация проекта (кодирование) – построение программного обеспечения; 3.Тестирование – проверяется, отвечает ли реализация предъявляемым требованиям; 4.Внедрение – передача ПО заказчику и организация его практического применения.
4 Моделирование требований
5 Процесс разработки ПО Выявление и описание требований – сбор данных о том, что должна делать система; Планирование проекта разработки – оценка трудоемкости, составление календарного планы, планирование качества, управление рисками; Выявление вариантов использование – моделирование вариантов использования Анализ – уточнение и структурирование требований – моделирование хода анализ; Проектирование – реализация требований в архитектуре системы – моделирование хода проектирование; Реализация (кодирование) – построение программного обеспечения; Тестирование – проверяется, отвечает ли реализация предъявляемым требованиям; Внедрение – передача ПО заказчику и организация его практического применения.
6 Требования заказчиков Функциональные требования. Не функциональные.
7 Спецификация требований Окончательным результатом работы с требованиями является документ спецификации требований к ПО (СТПО, SRS) – техническое задание. В ходе анализа выполняется формальное моделирование решаемой проблемы, но это еще не СТПО. По существу, моделирование является инструментом, который помогает получить основательные и полные знания о предлагаемой системе. Моделирование является инструментом, который помогает получить основательные и полные знания о предлагаемой системе. Моделирование обычно фокусирует внимание на структуре проблемы, а не на ее внешнем поведении.
8 Функциональные требования Функциональные требования определяют ожидаемое поведение системы – какие выходные данные и какое поведение должно быть получено при заданных входных данных. Для каждого функционального требования должно быть детально описаны: – все входные данные и их источники; – единицы измерения и интервалы допустимых входных значений; – все выполняемые операции над входными данными; – порядок проверки правильности входных данных; – описание процесса преобразования входных данных в выходные данные.
9 Не функциональные требования 1.требования к производительности; 2.проектные ограничения налагаемые на реализацию; 3.требования к внешним интерфейсам.
10 Общая структура СТПО документа В руководстве IEEE рекомендуется следующая структура спецификаций требований к ПО: 1.Введение 1.1. Цель 1.2. Масштаб 1.3. Определения, сокращённое имя и аббревиатуры 1.4. Ссылки 1.5. Общий обзор 2.Общее описание 2.1. Представление продукта Функции продукта Характеристики пользователей Общие ограничения Предположения и зависимости. 3. Детальные требования
11 Сценарии Людям обычно проще пояснить свои требования к ПО путем их связывания с реальной жизнью (а не с абстрактными понятиями). Они могут понимать и критиковать сценарии (ситуации) того, как они могут взаимодействовать с ПС. Специалисты по выявлению и описанию требований к ПО могут использовать информацию, полученную из такого обсуждения, для формулировки реальных требований к системе. Сценарии м.б. особенно полезными для добавления деталей к общим описаниям требований. Сценарии являются описаниями примеров сеансов взаимодействия пользователей с системой.
12 Варианты использования (прецеденты) Традиционный подход к описанию функциональных требований состоит в – выявлении сценариев работы будущего ПО и – их описании в виде вариантов использования (или прецедентов). Варианты использования (ВИ, Use Cases) специфицируют (детально описывают) функциональность системы путем описания ее поведения, зафиксированного в виде взаимодействий пользователя с данной системой.
13 Моделирование вариантов использования Варианты использования – это специальный способ записи требований. Моделирование вариантов использования обычно происходит следующим образом: 1.Устанавливаются границы будущей системы. 2.Выявляются актеры. 3.Выявляются варианты использования : - определяется вариант использования; - устанавливаются основные и альтернативные потоки. 4.Предыдущие шаги повторяются, пока варианты использования, актеры и границы системы не стабилизируются.
14 Контекст системы (границы системы) Контекст системы отделяет систему от остального мира. Надо определить, 1.что является частью системы (находится внутри границ системы) и 2.что находится вне системы (вне ее границ). Точное определение границ системы обычно играет важную роль в выявлении функциональных (а иногда и нефункциональных) требований. Актеры размещаются вне границ блока, а ВИ – внутри. В начале моделирования ВИ имеется лишь предварительное представление о том, где находятся границы системы. По мере выявления актеров и ВИ контекст системы обретает все более четкие очертания.
15 Актеры Актеры – это роли, исполняемые сущностями, непосредственно взаимодействующими с системой. Актер определяет роль, которую выполняет некоторая внешняя сущность при непосредственном взаимодействии с данной системой. Он может представлять роль пользователя или роль, исполняемую другой системой или частью аппаратных средств, которые касаются границ системы.
16 Выявление актеров Чтобы выявить актеров, нужно ответить на вопросы: – Кто или что использует систему? – Какие роли они играют во взаимодействии? – Кто устанавливает систему? – Кто или что запускает и выключает систему? – Кто обслуживает систему? – Какие системы взаимодействуют с данной системой? – Кто или что получает и предоставляет информацию системе? – Происходит ли что-нибудь в точно установленное время?
17 При моделировании актеров необходимо помнить следующее: Актеры всегда являются внешними по отношению к системе, следовательно, находятся вне вашего контроля. Актеры взаимодействуют непосредственно с системой – так они помогают в определении контекста системы. Актеры представляют роли, исполняемые людьми или сущностями по отношению к системе, а не конкретных людей или сущностей. Один человек или сущность может играть по отношению к системе множество ролей одновременно или последовательно во времени.
18 Описания актера У каждого актера должно быть короткое, осмысленное с прикладной точки зрения имя. Каждого актера должно сопровождать краткое описание (одна или две строчки), объясняющее, что данный актер из себя представляет с прикладной точки зрения. Как и в классах, в обозначении актеров могут быть представлены – атрибуты актера и – события, на которые он должен реагировать.
19 Определение варианта- использования Вариант использования описывает поведение, демонстрируемое системой с целью получения значимого результата для одного или нескольких актеров. Вариант использования описывает работу с системой конкретного актера: – варианты использования всегда инициируются актером; – варианты использования всегда описываются с точки зрения актеров.
20 Выявление вариантов использования Для выявления прецедента, нужно ответить на вопросы: 1.Как каждый из актеров использует систему? 2. Что система делает для каждого актера? Выявление прецедентов начинается со списка актеров. Затем рассматривается, как каждый актер собирается использовать систему. Каждому варианту использования должно быть присвоено короткое описательное имя (описывающее действие).
21 Моделирование вариантов использования это итеративный процесс, осуществляемый путем поэтапного уточнения. Все начинается с имени вариантов использования, а детали дополняются позже. Эти детали состоят из исходного краткого описания, которое уточняется до полной спецификации.
22 Полезный список вопросов, на которые следует ответить: 1.Какие функциональные возможности понадобятся конкретному актеру от системы? 2.Система сохраняет и извлекает информацию? 3.Если да, какой из актеров инициирует это поведение? 4.Что происходит, когда система изменяет состояние (например, при запуске и выключении системы)? 5.Кто-нибудь из актеров получает при этом уведомление? 6.Какие-либо внешние события оказывают влияние на систему? 7.Как система узнает об этих событиях? 8.Система взаимодействует с какой-либо внешней системой? 9.Система генерирует какие-либо отчеты?
23 Диаграмма вариантов использования
24 Словарь проекта (глоссарий проекта) В глоссарии проекта должна быть отражена бизнес- терминология и жаргон. Глоссарий проекта является, один из важных артефактов проекта. Любая область деятельности имеет собственный уникальный язык, и основной целью процесса выработки и анализа требований является понимание и фиксация этого языка. Глоссарий обеспечивает словарь ключевых деловых терминов и определений. Он должен быть понятен всем участникам проекта, включая все заинтересованные стороны. Кроме определения ключевых терминов глоссарий проекта должен включать синонимы и омонимы.
25 Описание варианта использования Для каждого варианта использования (ВИ) составляется: – спецификация ВИ – текстовый документ содержащий сжатое, но полное описание данного ВИ; – диаграмма ВИ – графическое описание связей между актерами и вариантами использования; между различными вариантами использования.
26 Спецификация варианта использования Для спецификации вариантов использования нет UML стандарта Обычно в шаблон простой спецификации ВИ входит следующая информация: 1.имя прецедента; 2.ID прецедента; 3.краткое описание – абзац, в котором изложена цель прецедента; 4.актеры, задействованные в прецеденте; 5.предусловия – условия, которые должны выполниться, чтобы прецедент мог осуществиться; это ограничения на состояние системы; 6.основной поток – шаги выполнения прецедента; 7.постусловия – условия, которые должны выполниться по окончанию прецедента; 8.альтернативные потоки – список альтернативных основному потоку событий.
27 Спецификация прецедентов
29 Пример программного обеспечения аукциона Требуется разработать ПО для проведения электронных аукционов. Продавцы размещают на продажу товары (лоты), задает начальную цену и срок торгов. Покупатели могут назначать за товары свои цены. Кто предложит наибольшую цену в течении срока торгов, тот и получает право на покупку товара за предложенную цену.
30 Спецификация первого варианта использования ВИ1: Размещение некоторого элемента на аукционе. – Основной актер: Продавец (Seller) – Предусловие: Продавец должен подключиться к системе (logged in). Основной успешный сценарий: 1.Продавец отправляет элемент (его категорию, описание, изображение и т.п.) на аукцион. 2.Система показывает продавцу ранее выставленные на продажу элементы. 3.Продавец определяет начальную цену торгов и время закрытия аукциона. 4.Система принимает данный элемент и публикует его. Не стандартные сценарии: – 2 a) В данной категории нет ранее выставленных на продажу элементов. Система сообщает продавцу о такой ситуации.
31 Спецификация второго варианта использования ВИ2: Выполнение торгов – Основной актер: Покупатель – Предусловие : Покупатель должен подключиться к системе (logged in). Основной успешный сценарий: 1.Покупатель выполняет поисковый запрос, или выполняет просмотр и выбор нужного элемента. 2.Система показывает рейтинг продавца, начальную запрашиваемую цену, текущую цену и высшую цену; просит покупателя предложить свойю цену. 3.Покупатель вводит предлагаемую цену, за которую он согласен купить данный элемент. 4.Система принимает предлагаемую цену; блокирует деньги на счете покупателя. 5.Система обновляет текущую цену; информирует других пользователей; обновляет записи для данного элемента. Не стандартные сценарии : – 3 a) Предлагаемые цены меньше чем максимальная предложенная цена. Система просит покупателя ввести новую цену. – 4 a) Покупатель не имеет достаточно денег на своем счету. Система прерывает покупку и просит покупателя увеличить кол-во денег на его счету.
32 Спецификация третьего варианта использования ВИ3: Завершение аукциона – Первичный актер: Аукционная система. – Предусловие: Достигнуто завершение последней даты проведения торговли. Основной успешный сценарий : 1.Выбрать покупателя предложившего наивысшую цену; послать эл. письма выбранному покупателю и продавцу с информацией о конечной цене элемента; послать другим участникам торга. 2.Списать деньги со счета покупателя и записать их на счет продавца. 3.Разблокировать все деньги заблокированные у участников торга. 4.Передать со счета продавца комиссионные деньги на счет организации аукциона. Не стандартные сценарии: Нет
33 Ветвление в варианте использования Для представления ответвления потока используйте ключевое слово Если (If). Пример, показывает хорошо структурированный поток событий с двумя ветвями. Каждая ветвь начинается с ключевого слова Если и простого логического выражения, такого как Если пользователь вводит новое количество, которое может быть истинным (true) или ложным (false). Структурированный текст под выражением Если – это то, что произойдет, если логическое выражение истинно.
34 Ветвление в варианте использования
35 Повторение в потоке Иногда некоторое действие в потоке событий необходимо повторить несколько раз. В моделировании ВИ это встречается не часто, но нужно иметь некоторую стратегию для их обработки. Спецификация UML не определяет способа представления повторений в потоке, поэтому предлагаются простые выражения с ключевыми словами Для (For) и Пока (While).
36 Ключевое слово Для (For) Смоделировать повторение можно с помощью ключевого слова Для. n. Для (выражение, описывающее итерации) n.1. Сделать что-то n.2. Сделать что-то другое n.3. … n+1. Выражение, описывающее итерации, – это некоторое выражение, результат которого – количество итераций. Каждая структурированная строка после выражения Для повторяется столько раз, сколько определено в выражении.
38 Ключевое слово Пока (While) Ключевое слово Пока (While) используется для моделирования последовательности действий в потоке событий, которые осуществляются до тех пор, пока некоторое логическое условие истинно. n. Пока (логическое условие) n.1. Сделать что-то n.2. Сделать что-то другое n.3. … n+1.
40 Моделирование альтернативных потоков У каждого варианта использования есть один основной поток и может быть множество альтернативных потоков. Они являются альтернативными путями в варианте использования, которые перехватывают ошибки, ответвления и прерывания основного потока. Альтернативные потоки часто не возвращаются в основной поток варианта использования.
41 Спецификация варианта использования с альтернативными потоками
42 Альтернативный поток Invalid Address
43 Альтернативный поток Cancel
44 Выявление альтернативных потоков Чтобы выявить альтернативные потоки, нужно внимательно изучить основной поток. На каждом шаге основного потока необходимо искать: – возможные альтернативы основному потоку; – ошибки, которые могут возникнуть в основном потоке; – прерывания, которые могут случиться в конкретной точке основного потока; – прерывания, которые могут произойти в любой точке основного потока.
45 Отображение требований При отображении требований устанавливаются взаимосвязи между описанием требований и моделью вариантов использования. Описание требований и модель ВИ обеспечивают две «базы данных» функциональных требований. Важно сопоставить эти две модели, чтобы выяснить, нет ли в одной из них чего-то, что не охвачено в другой, и наоборот.
46 Отображение требований (2) Между отдельными функциональными требованиями и вариантами использования могут быть отношения «многие-ко-многим». – один прецедент будет охватывать множество отдельных функциональных требований, и – одно функциональное требование может появляться в нескольких разных прецедентах.
48 Когда применять моделирование вариантов использования Варианты использования хорошо применять для определения функциональности системы. Они плохо подходят для выявления ограничений системы. Варианты использования фиксируют функциональные требования и поэтому не эффективны для систем, в которых доминируют нефункциональные требования.
49 Когда следует применять варианты использования Варианты использования являются лучшим выбором для фиксирования требований в тех случаях, когда: – в системе преобладают функциональные требования; – в системе много типов пользователей, которым она предоставляет разные функциональные возможности (много актеров); – в системе много интерфейсов (много актеров).
50 Когда следует применять варианты использования Варианты использования не стоит применять в тех случаях, когда: – в системе преобладают нефункциональные требования; – в системе мало пользователей; – в системе мало интерфейсов.
51 Дополнительные возможности моделирования вариантов использования
52 Обобщение актеров Обобщение актеров выносит поведение, общее для двух или более актеров, в актера-родителя. Общее поведение можно вынести путем обобщения актеров.
53 Например
55 Создается абстрактный актер, называемого Purchaser (покупатель), который взаимодействует с прецедентами ListProducts, OrderProducts и AcceptPayment. Customer и SalesAgent – это конкретные актеры, потому что данные роли могут выполнять реальные люди (или другие системы). Purchaser – абстрактный актер, поскольку он является абстракцией, введенной просто для представления общего поведения (возможности делать покупки) двух конкретных актеров. Customer и SalesAgent наследуют все роли и отношения с прецедентами своего абстрактного родителя.
56 Обобщение вариантов использования Обобщение ВИ выполняется, если есть один или более ВИ, которые на самом деле являются уточнениями (специализациями) более общего прецедента. Данный прием следует применять, только если он упрощает модель ВИ. Обобщение ВИ выносит поведение, общее для одного или более ВИ, в родительский ВИ.
57 Обобщение вариантов использования При обобщении ВИ дочерние ВИ представляют более специализированные формы их родителей. Потомки могут: – наследовать возможности родительского ВИ; – вводить новые возможности; – переопределять (менять) унаследованные возможности. Дочерний ВИ автоматически наследует все возможности своего родителя. Однако не все возможности ВИ могут быть переопределены.
59 Описание родительского варианта использования FindProduct
60 Описание дочернего варианта использования FindBook
61 Отношение «include» Иногда в вариантах использования содержится многократное описание одних и тех же действий. Например, рассмотрим систему Personnel (персонал) – Практически любое действие системы начинается с получения данных о конкретном служащем. – Если бы эту последовательность событий приходилось писать каждый раз, когда необходимы данные служащего, прецеденты имели бы повторяющиеся части. Отношение «include», устанавливаемое между ВИ, позволяет включить поведение одного ВИ в поток другого варианта использования. Отношение «include» выносит шаги, общие для нескольких ВИ, в отдельный вариант использования, который потом включается в остальные.
62 Прецеденты системы Personnel
63 Включение прецедента
65 Отношение «extend» Отношение «extend» предоставляет возможность ввести новое поведение в существующий вариант использования. Базовый вариант использования предоставляет набор точек расширения (extension points) – точек входа, в которые может быть добавлено новое поведение. А расширяющий вариант использования предоставляет ряд сегментов вставки, которые можно ввести в базовый прецедент в места, указанные точками входа. Отношение «extend» может использоваться для того, чтобы точно указать, какие именно точки расширения базового варианта использования подлежат расширению.
66 Отношение «extend»
67 Обозначение точек расширения
68 Расширяющий прецедент
69 Когда применять дополнительные возможности Применяйте дополнительные возможности, только если они упрощают модель и делают ее более понятной. Применяйте дополнительные возможности, только если они упрощают модель варианта использования. Лучшие модели вариантов использования – это простые модели. Модель варианта использования – это описание требований, то есть она должна быть понятной не только разработчикам моделей, но и заинтересованным сторонам. Простая модель вариантов использования, в которой дополнительные возможности применяются редко или вообще отсутствуют, предпочтительнее модели, переполненной дополнительными возможностями.
70 Советы и рекомендации по написанию прецедентов 1.Делать варианты использования короткими и простыми. 2.Уделять основное внимание на «что требуется», а не «как делается». 3.Избегать функциональной декомпозиции.
71 Избегайте функциональной декомпозиции
Еще похожие презентации в нашем архиве:
© 2024 MyShared Inc.
All rights reserved.