В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 18
Текст из файла (страница 18)
кто предложил это требование).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.
(Необязательно) Допущения об окружении и ходе работы системы, использованные приразработке данного варианта. В полностью готовом варианте эти допущения либо должны58быть подтверждены и стать ограничениями системы, либо должны давать началоразличным сценариям работы.Кроме того, варианты использования могут дополняться диаграммами других видов — преждевсего, сценарными диаграммами и диаграммами активностей, описывающими последовательностидействий участвующих компонентов, диаграммами состояний и переходов компонентов идиаграммами классов этих компонентов, и др.
Все эти виды диаграмм будут рассматриваться влекции, посвященной архитектуре ПО.Литература к Лекции 4[1] J. A. Zachman. A Framework for Information Systems Architecture. IBM Systems Journal,vol. 26, no. 3, pp. 276-292, 1987.[2] J. F. Sowa and J. A. Zachman.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
