Lecture04 (1133561), страница 3
Текст из файла (страница 3)
Эта информация важна, но должнаоформляться в отдельных документах.o Слишком детальные спецификации, описывающие требования к слишком мелкимэлементам системы или описывающие требования, в точности соответствующиехарактеристикам определенных систем.o Слишком сильные ограничения, не вытекающие из реальных потребностей.o Нечеткие требования, которые могут быть непроверяемыми и субъективными(«минимизировать уровень погрешности», «удобный для пользователей интерфейс»),или сформулированы в виде, открытом для пополнения неопределенными элементами(с указанием «и т.д.» или «включая, но не ограничиваясь следующим...»).o Несформулированные предположения о режимах работы, свойствах окружения, оготовности других систем или принятии законов и стандартов, находящихся в стадииразработки.Варианты использованияНаиболее широко распространенными техниками фиксации требований в настоящий моментявляются структурированные текстовые документы и диаграммы вариантов использования, окоторых уже заходила речь при обсуждении RUP.Вариантом использования (use case) называют некоторый сценарий действий системы,который обеспечивает ощутимый и значимый для ее пользователей результат.
На практике в видеодного варианта использования оформляется сценарий действий системы, который будет, скореевсего, неоднократно возникать во время ее работы и имеет достаточно четко определенныеусловия начала выполнения и завершения.Примеры вариантов использования:• Покупатель в Интернет-магазине выбирает товар. Для этого он может выбрать категориютовара, фирму-изготовителя или группу таких фирм и отфильтровать оставшиеся товары поцене, габаритам и цвету. Определившись, он выбирает товар, кликая на соответствующемзначке мышкой.• Оператор системы контроля качества газопровода ищет участки газопровода сповышенным риском возникновения аварии. Для этого он выбирает группу ранееслучившихся аварий, фильтруя их по дате, нанесенному ущербу, типу аварии и запускаетпроцедуру анализа характеристик соответствующих участков газопровода на совпадение,по крайней мере, двух характеристик.
При таком анализе учитываются изготовитель труб иих партия, история хранения труб на складах, землепроходческая бригада, бригадасварщиков, показатели нескольких последних проведенных инспекций, показателихимической активности грунтов, наличие близлежащих предприятий, влияющих нахимические и электрические характеристики грунтов. После этого на карте выделяютсяучастки, характеристики которых также попадают под найденный «шаблон аварии».В языке UML вариант использования изображается в виде овала, помеченного именемпредставляемого варианта.
Варианты использования могут быть связаны с участвующими в нихдействующими лицами (actors), изображаемыми в виде человечков и представляющимиразличные роли пользователей системы или внешние системы, взаимодействующие с ней.Поиск товараЗаказ товараПокупательВыбор способаоплатыДобавлениетовараУдалениетовараОператор сайтаРисунок 21. Набросок диаграммы вариантов использования для Интернет-магазина.Варианты использования могут быть связаны друг с другом тремя видами связей: обобщением(generalization), расширением (extend relationship) и включением (include relationship).Действующие лица также могут быть связаны друг с другом с помощью связей обобщения(generalization).Если несколько вариантов использования имеют много общего в структуре выполняемых в ихрамках сценариев и в достигаемых целях, можно выделить обобщающий их вариантиспользования, содержащий общие части описываемого ими поведения.
Обобщаемые вариантыуточняют обобщающий их вариант. При этом обычно сценарий работы обобщаемого вариантасостоит из нескольких кусков — последовательности действий, выполняемых в рамках сценарияработы общего варианта использования, перемежаются с последовательностями, специфическимидля частного. Например, если система регистрации заказов в магазине позволяет оформить заказ(данные о котором в дальнейшем будут присутствовать в системе) как при помощи сайтамагазина, так и по телефону, то варианты использования «Заказ товара через сайт» и «Заказ товарапо телефону» могут быть обобщены в варианте «Заказ товара».Вариант использования A расширяет (extends) другой вариант использования B, если в ходесценария работы A при определенных условиях надо включить полный сценарий работы B.Например, оператор сайта магазина может удалить товар, введя его идентификатор; а еслиидентификатор ему не известен, а известна лишь марка товара и производитель, он долженсначала найти такой товар и определить идентификатор в его описании, а затем уже удалитьтовар.
Соответственно, вариант использования «Удаление товара» будет расширять вариантиспользования «Поиск товара».УдалениетовараЗаказ товараПокупательВедениеданныхextendОператор сайтаincludeincludeПоиск товараextendВыбор способаоплатыИзменениеданных о товареПоиск покатегориямДобавлениетовараПоиск попроизводителюРисунок 22.
Доработанная диаграмма вариантов использования для Интернет-магазина.Вариант использования A включает (includes, или использует, uses) вариант использованияB, если A всегда в некоторый момент включает полностью сценарий работы B. Например, приоформлении заказа покупатель всегда должен определить способ его оплаты. Значит, вариантиспользования «Заказ товара» включает вариант «Определение способа оплаты».Обобщение между действующими лицами вводится, если задачи, решаемые однимдействующим лицом с помощью данной системы, являются подмножеством задач, решаемыхдругим действующим лицом.
Например, обычный оператор сайта может иметь права только навнесение дополнений и изменений в данные, но не иметь прав на приостановку работы сайта иизменение структуры, которые имеет администратор сайта. В то же время администратор можетделать все, что может обычный оператор сайта. Соответственно, администратор сайта являетсяспециальным частным случаем оператора.Хорошо описанный вариант использования имеет следующие атрибуты [9].1.2.3.4.5.Имя, ясно говорящее о назначении варианта использования.Описание. Несколько предложений, описывающих этот вариант использования.Частота. Насколько часто данный вариант использования возникает.Предусловия. Все условия запуска варианта использования.Постусловия.
Все условия, которые должны быть выполнены после успешного выполненияварианта использования.6. Основной сценарий работы, который используется в большинстве случаев.7. Альтернативные сценарии, возникающие иногда. Для каждого альтернативного сценарияуказываются условия его запуска.8. (Необязательно) Задействованные действующие лица.9.
(Необязательно) Расширяемые варианты использования.10. (Необязательно) Включаемые варианты использования.11. (Необязательно) Статус: «в разработке», «готов к проверке», «в процессе проверки»,«подтвержден», «отвергнут».12. (Необязательно) Допущения об окружении и ходе работы системы, использованные приразработке данного варианта. В полностью готовом варианте эти допущения либо должныбыть подтверждены и стать ограничениями системы, либо должны давать началоразличным сценариям работы.Кроме того, варианты использования могут дополняться диаграммами других видов — преждевсего, сценарными диаграммами и диаграммами активностей, описывающими последовательностидействий участвующих компонентов, диаграммами состояний и переходов компонентов идиаграммами классов этих компонентов, и др.
Все эти виды диаграмм будут рассматриваться влекции, посвященной архитектуре ПО.Литература к Лекции 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. Extending and Formalizing the Framework for InformationSystems Architecture. IBM Systems Journal, vol. 31, no. 3, pp. 590-616, 1992.[3] E. Yourdon.
Modern Structured Analysis. Prentice Hall, 1988.[4] T. DeMarco. Structured Analysis and System Specification. A Yourdon Book, Yourdon Inc., NY,1979.[5] C. Sarson, T. Gane. Structured Systems Analysis. Englewood Cliffs, NJ.: Prentice-Hall, 1979.[6] P. Chen. The Entity-Relationship Model: Toward a Unified View of Data. ACM Transactions onDatabase Systems I (I).
March 1976, pp. 8-46.[7] IEEE 830-1998. Recommended Practice for Software Requirements Specifications. New York:IEEE, 1998.[8] IEEE 1233-1998. Guide for Developing System Requirements Specifications. New York: IEEE,1998.[9] А. Коберн. Современные методы описания требований к системам. М.: Лори, 2002.[10] И. Соммервилл. Инженерия программного обеспечения. М.: Вильямс, 2002.[11] Э. Дж.
Брауде. Технология разработки программного обеспечения. СПб.: Питер, 2004.[12] Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программномуобеспечению. Унифицированный подход. М.: Вильямс, 2002.[13] А. Якобсон, Г. Буч, Дж. Рамбо. Унифицированный процесс разработки программногообеспечения. СПб.: Питер, 2002..
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
