Программное обеспечение
<<  Технология разработки программного обеспечения Компьютер: друг или враг  >>
Актеры
Актеры
Определение варианта-использования
Определение варианта-использования
Диаграмма вариантов использования
Диаграмма вариантов использования
Спецификация прецедентов
Спецификация прецедентов
Технология разработки программного обеспечения
Технология разработки программного обеспечения
Ветвление в варианте использования
Ветвление в варианте использования
Технология разработки программного обеспечения
Технология разработки программного обеспечения
Технология разработки программного обеспечения
Технология разработки программного обеспечения
Моделирование альтернативных потоков
Моделирование альтернативных потоков
Спецификация варианта использования с альтернативными потоками
Спецификация варианта использования с альтернативными потоками
Альтернативный поток InvalidEmailAddress
Альтернативный поток InvalidEmailAddress
Альтернативный поток Cancel
Альтернативный поток Cancel
Технология разработки программного обеспечения
Технология разработки программного обеспечения
Например
Например
Технология разработки программного обеспечения
Технология разработки программного обеспечения
Технология разработки программного обеспечения
Технология разработки программного обеспечения
Описание родительского варианта использования FindProduct
Описание родительского варианта использования FindProduct
Описание дочернего варианта использования FindBook
Описание дочернего варианта использования FindBook
Прецеденты системы Personnel
Прецеденты системы Personnel
Включение прецедента
Включение прецедента
Технология разработки программного обеспечения
Технология разработки программного обеспечения
Отношение «extend»
Отношение «extend»
Обозначение точек расширения
Обозначение точек расширения
Расширяющий прецедент
Расширяющий прецедент
Избегайте функциональной декомпозиции
Избегайте функциональной декомпозиции
Картинки из презентации «Технология разработки программного обеспечения» к уроку информатики на тему «Программное обеспечение»

Автор: Тузовский. Чтобы познакомиться с картинкой полного размера, нажмите на её эскиз. Чтобы можно было использовать все картинки для урока информатики, скачайте бесплатно презентацию «Технология разработки программного обеспечения.pptx» со всеми картинками в zip-архиве размером 7185 КБ.

Технология разработки программного обеспечения

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

Технология разработки программного обеспечения

другие презентации на тему «Технология разработки программного обеспечения»

«Программное обеспечение» - Базы данных и СУБД. Приложения общего назначения. Графические редакторы: __________. Приложения общего назначения: текстовые и графич.редакторы и др. Прикладное программное обеспечение. Программные продукты, являющиеся частью новых технологий. Системное программное обеспечение. Операционные системы: Windows, Linux и др.

«Классификация программного обеспечения» - Что такое библиотека стандартных подпрограмм ? Самые яркие программы для Windows. Издательские системы: Программы для работы с изображениями: Fotoshop, CorelDrive, и др. Классификация программного обеспечения. 2.4. Уникальные программы. Какие функции выполняет операционная система ? На рынке ПО постоянно появляются программные продукты трудно или просто не возможно.

«Разработка программ» - Выполняет трансляцию программа tasm.exe (tasm32.exe). Выполняет компоновку программа tlink.exe (tlink32.exe). Компоновка - процесс формирования загрузочного модуля из нескольких объектных модулей. Выполняется отладка программой td.exe (td32.exe). 1. Схема процесса разработки программ на ассемблере: Сохранить файл с расширением - asm, например, LR1.ASM.

«Программное обеспечение компьютера» - Инструментальное. Программное обеспечение компьютера. Системы программирования — инструмент для работы программиста. Главной частью системного ПО является операционная система (ОС). Системное. ОС работает с пользователем в интерактивном (диалоговом) режиме. Некоторые ОС: MS-DOS, Windows, Linux. Программное обеспечение.

«Методические разработки» - Введение «Декоративное вязание крючком» «Декоративное вязание на спицах» Приложения Литература. Методические разработки (6 класс – 2 вариант). Сборник программ по технологии для 1-4 и 5-9 классов Направления: «Технология. Методическое обеспечение учащихся 5-7 класс (новинки -2008-2009 г.). Программа по «Технологии».

«Программное обеспечение компьютера 10 класс» - Инструментарий программирования. Подразделение. Прикладное ПО. Программное обеспечение. Разработка современного ПО требует очень высокой квалификации от программистов. Сервисные программы. Главной частью системного программного обеспечения является операционная система (ОС). Операционная система. Интерактивный режим.

Программное обеспечение

33 презентации о программном обеспечении
Урок

Информатика

130 тем
Картинки
900igr.net > Презентации по информатике > Программное обеспечение > Технология разработки программного обеспечения