В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 18

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 18)

Это позволит отказаться от реализации наименееважных и наиболее трудоемких, не соответствующих бюджету проекта функций еще до ихдетальной проработки, а также выявить возможные проблемные места проекта — наиболеетрудоемкие и неясные из вошедших в него функций.Правила работы с требования к ПО и более общими системными требованиями (к программноаппаратной системе), определяются следующими двумя стандартами IEEE.• IEEE 830-1998 Recommended Practice for Software Requirements Specifications [7](рекомендуемые методы спецификации требований к ПО).Описывает структуру документов для фиксации требований к ПО.54•Кроме того, он определяет характеристики, которыми должен обладать правильносоставленный набор требований.o Корректность или адекватность (соответствие реальным потребностям).o Недвусмысленность (однозначность понимания).o Полнота (отражение всех выделенных потребностей и всех возможных ситуаций, вкоторых придется работать системе).o Непротиворечивость (согласованность между различными элементами).o Упорядоченность по важности и стабильности.o Проверяемость (выполнение каждого требования нужно уметь проверять некоторымдостаточно эффективным способом — непроверяемые требования должны бытьудалены из рассмотрения или сведены к проверяемым вариантам).o Модифицируемость (оформление в удобных для внесения изменений структуре истилях).o Прослеживаемость в ходе разработки (возможность увязать требование с подсистемами,модулями и операциям, ответственными за его выполнение, и с тестами, проверяющимиего выполнение).IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications [8](руководство по разработке спецификаций требований к системам).Описывает правила построения требований для программно-аппаратных систем в целом.Он выделяет следующие необходимые свойства набора требований.o Однократное упоминание отдельных требований.o Отсутствие пересечений между требованиями.o Явное указание связей между требованиями.o Полнота.o Непротиворечивость.o Определение ограничений, области действия и контекста для каждого требования.o Модифицируемость.o Конфигурируемость, удобство поддержки.o Подходящий для определения системы уровень абстракции.Кроме того, следующие свойства считаются необходимыми для отдельного требования.o Абстрактность — формулировка, независимая от возможных реализаций.o Недвусмысленность.o Прослеживаемость.o Проверяемость.Стандарт предписывает определять следующие атрибуты для каждого требования.o Уникальный идентификатор.o Приоритет, важность реализации с точки зрения пользователей.o Критичность для построения и успешности системы с точки зрения аналитиков.o Осуществимость с точки зрения готовности пользователей к новой функции,имеющихся технологий и стоимости реализации.o Риски высокой стоимости, последствий использования для окружающей среды ипользователей, конфликтов со стандартами и законодательством.o Источник (т.е.

кто предложил это требование).o Тип требования. Возможные типы определяются так (многие из них соответствуютатрибутам качества, рассматриваемым в следующей лекции):ƒ Требования на входные данные.ƒ Требования на выходные данные.55ƒƒНадежность (reliability, например, среднее время работы между отказами).Работоспособность (availability, например, необходимое отношение временифункционирования к полному времени работы).ƒ Удобство сопровождения (maintainability, например, удобство замены компонента).ƒ Производительность (performance, например, среднее время ожидания ответа).ƒ Доступность (accessibility, например, разные способы доступа для новичков иопытных пользователей).ƒ Ограничения окружающей среды (например, максимальный уровеньзадымленности, при котором гарантируется работоспособность).ƒ Эргономичность (ergonomic, например, использование набора цветов, понижающихутомляемость глаз).ƒ Безопасность (safety, например, допустимые уровни электромагнитного излученияразличных частот).ƒ Защищенность (security, например, ограничения доступа для разных пользователей).ƒ Требования к оборудованию (например, использование обычной электросети).ƒ Транспортируемость (transportability, например, ограничения веса).ƒ Удобство обучения (например, включение обучающих материалов).ƒ Документированность (например, наличие встроенной документации).ƒ Внешние интерфейсы (например, поддержка стандартных форматов документов).ƒ Тестируемость (например, поддержка удаленной диагностики).ƒ Условия необходимого качества (например, максимально допустимая погрешностьпроизводимых измерений).ƒ Следование корпоративным и законодательным нормам (например, законам обохране труда).ƒ Совместимость с известными системами.ƒ Следование стандартам и технологическим нормам.ƒ Конвертация данных (например, из старой версии системы).ƒ Возможности роста (например, возможное увеличение числа пользователей).ƒ Удобство развертывания (например, время, необходимое для приведения вработоспособное состояние).В дополнение к перечисленному стандарт IEEE 1233 выделяет следующие ошибки,которых необходимо избегать при определении требований.o Описание возможных решений вместо требований.

Эта информация важна, но должнаоформляться в отдельных документах.o Слишком детальные спецификации, описывающие требования к слишком мелкимэлементам системы или описывающие требования, в точности соответствующиехарактеристикам определенных систем.o Слишком сильные ограничения, не вытекающие из реальных потребностей.o Нечеткие требования, которые могут быть непроверяемыми и субъективными(«минимизировать уровень погрешности», «удобный для пользователей интерфейс»),или сформулированы в виде, открытом для пополнения неопределенными элементами(с указанием «и т.д.» или «включая, но не ограничиваясь следующим...»).o Несформулированные предположения о режимах работы, свойствах окружения, оготовности других систем или принятии законов и стандартов, находящихся в стадииразработки.Варианты использованияНаиболее широко распространенными техниками фиксации требований в настоящий моментявляются структурированные текстовые документы и диаграммы вариантов использования, окоторых уже заходила речь при обсуждении RUP.Вариантом использования (use case) называют некоторый сценарий действий системы,который обеспечивает ощутимый и значимый для ее пользователей результат.

На практике в виде56одного варианта использования оформляется сценарий действий системы, который будет, скореевсего, неоднократно возникать во время ее работы и имеет достаточно четко определенныеусловия начала выполнения и завершения.Примеры вариантов использования:• Покупатель в Интернет-магазине выбирает товар. Для этого он может выбрать категориютовара, фирму-изготовителя или группу таких фирм и отфильтровать оставшиеся товары поцене, габаритам и цвету. Определившись, он выбирает товар, кликая на соответствующемзначке мышкой.• Оператор системы контроля качества газопровода ищет участки газопровода сповышенным риском возникновения аварии. Для этого он выбирает группу ранееслучившихся аварий, фильтруя их по дате, нанесенному ущербу, типу аварии и запускаетпроцедуру анализа характеристик соответствующих участков газопровода на совпадение,по крайней мере, двух характеристик. При таком анализе учитываются изготовитель труб иих партия, история хранения труб на складах, землепроходческая бригада, бригадасварщиков, показатели нескольких последних проведенных инспекций, показателихимической активности грунтов, наличие близлежащих предприятий, влияющих нахимические и электрические характеристики грунтов.

После этого на карте выделяютсяучастки, характеристики которых также попадают под найденный «шаблон аварии».В языке UML вариант использования изображается в виде овала, помеченного именемпредставляемого варианта. Варианты использования могут быть связаны с участвующими в нихдействующими лицами (actors), изображаемыми в виде человечков и представляющимиразличные роли пользователей системы или внешние системы, взаимодействующие с ней.Варианты использования могут быть связаны друг с другом тремя видами связей: обобщением(generalization), расширением (extend relationship) и включением (include relationship).Действующие лица также могут быть связаны друг с другом с помощью связей обобщения(generalization).Поиск товараЗаказ товараПокупательВыбор способаоплатыДобавлениетовараУдалениетовараОператор сайтаРисунок 21.

Набросок диаграммы вариантов использования для Интернет-магазина.Если несколько вариантов использования имеют много общего в структуре выполняемых в ихрамках сценариев и в достигаемых целях, можно выделить обобщающий их вариантиспользования, содержащий общие части описываемого ими поведения. Обобщаемые вариантыуточняют обобщающий их вариант. При этом обычно сценарий работы обобщаемого вариантасостоит из нескольких кусков — последовательности действий, выполняемых в рамках сценарияработы общего варианта использования, перемежаются с последовательностями, специфическимидля частного. Например, если система регистрации заказов в магазине позволяет оформить заказ(данные о котором в дальнейшем будут присутствовать в системе) как при помощи сайтамагазина, так и по телефону, то варианты использования «Заказ товара через сайт» и «Заказ товарапо телефону» могут быть обобщены в варианте «Заказ товара».Вариант использования A расширяет (extends) другой вариант использования B, если в ходесценария работы A при определенных условиях надо включить полный сценарий работы B.57Например, оператор сайта магазина может удалить товар, введя его идентификатор; а еслиидентификатор ему не известен, а известна лишь марка товара и производитель, он долженсначала найти такой товар и определить идентификатор в его описании, а затем уже удалитьтовар.

Соответственно, вариант использования «Удаление товара» будет расширять вариантиспользования «Поиск товара».УдалениетовараЗаказ товараПокупательВедениеданныхextendОператор сайтаincludeincludeПоиск товараextendВыбор способаоплатыИзменениеданных о товареПоиск покатегориямДобавлениетовараПоиск попроизводителюРисунок 22. Доработанная диаграмма вариантов использования для Интернет-магазина.Вариант использования A включает (includes, или использует, uses) вариант использованияB, если A всегда в некоторый момент включает полностью сценарий работы B. Например, приоформлении заказа покупатель всегда должен определить способ его оплаты.

Значит, вариантиспользования «Заказ товара» включает вариант «Определение способа оплаты».Обобщение между действующими лицами вводится, если задачи, решаемые однимдействующим лицом с помощью данной системы, являются подмножеством задач, решаемыхдругим действующим лицом. Например, обычный оператор сайта может иметь права только навнесение дополнений и изменений в данные, но не иметь прав на приостановку работы сайта иизменение структуры, которые имеет администратор сайта. В то же время администратор можетделать все, что может обычный оператор сайта. Соответственно, администратор сайта являетсяспециальным частным случаем оператора.Хорошо описанный вариант использования имеет следующие атрибуты [9].1. Имя, ясно говорящее о назначении варианта использования.2. Описание.

Несколько предложений, описывающих этот вариант использования.3. Частота. Насколько часто данный вариант использования возникает.4. Предусловия. Все условия запуска варианта использования.5. Постусловия. Все условия, которые должны быть выполнены после успешного выполненияварианта использования.6. Основной сценарий работы, который используется в большинстве случаев.7. Альтернативные сценарии, возникающие иногда. Для каждого альтернативного сценарияуказываются условия его запуска.8. (Необязательно) Задействованные действующие лица.9. (Необязательно) Расширяемые варианты использования.10. (Необязательно) Включаемые варианты использования.11. (Необязательно) Статус: «в разработке», «готов к проверке», «в процессе проверки»,«подтвержден», «отвергнут».12.

Характеристики

Список файлов книги