sdt-book-2006 (1133574), страница 18
Текст из файла (страница 18)
На практике в виде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. 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.59Лекция 5. Качество ПО и методы его контроляАннотацияРассматривается понятие качества ПО, характеристики и атрибуты качества, связь атрибутовкачества с требованиями.
Дается краткий обзор различных методов контроля качества ПО, с болеедетальным рассмотрением тестирования и проверки свойств на моделях.Ключевые словаКачество ПО, функциональность, надежность, удобство использования, производительность,удобство сопровождения, переносимость, методы контроля качества, тестирование, проверкасвойств ПО на моделях, ошибки в ПО.Текст лекцииКачество программного обеспеченияКак проверить, что требования определены достаточно полно и описывают все, что ожидаетсяот будущей программной системы? Это можно сделать, проследив, все ли необходимые аспектыкачества ПО отражены в них. Именно понятие качественного ПО соответствует представлению отом, что программа достаточно успешно справляется со всеми возложенными на нее задачами и неприносит проблем ни конечным пользователям, ни их начальству, ни службе поддержки, ниспециалистам по продажам.
Да и самим разработчикам создание качественной программыприносит гораздо больше удовольствия.Если попросить группу людей высказать своё мнение по поводу того, что такое качественноеПО, можно получить следующие варианты ответов.• Его легко использовать.• Оно демонстрирует хорошую производительность.• В нем нет ошибок.• Оно не портит пользовательские данные при сбоях.• Его можно использовать на разных платформах.• Оно может работать 24 часа в сутки и 7 дней в неделю.• В него легко добавлять новые возможности.• Оно удовлетворяет потребности пользователей.• Оно хорошо документировано.Все это действительно имеет непосредственное отношение к качеству ПО.
Но эти ответывыделяют характеристики, важные для конкретного пользователя, разработчика или группы такихлиц. Для того, чтобы удовлетворить потребности всех сторон (конечных пользователей,заказчиков, разработчиков, администраторов систем, в которых оно будет работать,регулирующих организаций и пр.), для достижения прочного положения разрабатываемого ПО нарынке и повышения потенциала его развития необходим учет всей совокупности характеристикПО, важных для всех заинтересованных лиц.Приведенные выше ответы показывают, что качество ПО может быть описано большимнабором разнородных характеристик. Такой подход к описанию сложных понятий называетсяхолистическим (от греческого слова ολοσ, целое).
Он не дает единой концептуальной основы длярассмотрения затрагиваемых вопросов, какую дает целостная система представлений (например,Ньтоновская механика в физике или классическая теория вычислимости на основе машинТьюринга), но позволяет, по крайней мере, не упустить ничего существенного.Качество программного обеспечения определяется в стандарте ISO 9126 [1] как всясовокупность его характеристик, относящихся к возможности удовлетворять высказанные илиподразумеваемые потребности всех заинтересованных лиц.Тот же стандарт ISO 9126 [1-4] дает следующее представление качества.60Различаются понятия внутреннего качества, связанного с характеристиками ПО самого посебе, без учета его поведения; внешнего качества, характеризующего ПО с точки зрения егоповедения; и качества ПО при использовании в различных контекстах — того качества, котороеощущается пользователями при конкретных сценариях работы ПО.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
