И. Соммервилл - Инженерия программного обеспечения (1133538), страница 36
Текст из файла (страница 36)
Рис 6.В. Суанприй сабытил "Нпчлао тнрпязякуии" На первой стадии сценария возможны три исключительные ситуации. 1. Нумеышениелимивю вфечеяи олскдпния Клиент может не успеть ввести Р1Х-код в от. веденное для ввода время. Карточка возвращается. 2. Недояусткчал каРточка. Карточка не опознаетсл и возвращается. 3. Ичржляис карточки. Карточка удерживается банкоматом. Каждую исключительную ситуацию можно определить более подробно, построив от. дельные диаграммы потоков данных и управления. Общая диаграмма сценария также может быть снабжена комментариями с дополнительной информацией, содержащей описание действий, которые должны быть предприняты при возникновении исключительной ситуации.
"Проверка пользователя" — стадия проверки соответствия Р1Х-кода номеру счета клиента. Номер счета является выходными данными этой стадии. Возможная исключитель- 138 ьуасть 11. Требования ная ситуация — ввод неверного Р(Х-кода, в этом случае Р1Х-код запрашивается снова. На диаграмме показано, что повторный запрос может опять привести к исключительной ситуации. Если повторно введенный Р1Х-код снова неверный, карточка возвращается. После события "Подтверждение пользователя" можно переходить к следующей стадии сценария "Выбор сервиса". Варианты использования Варианты использованил (иле-сазе) [186) — это методика формирования требований, основанная на сценариях.
Они стали основой нотаций в языке моделирования ()МУ. при описании объектных моделей систем. В самой простой форме в варианте использования определены действующие лица (в НМ(. онн называются аквмрани), т.е. пользователи, во. влеченные во взаимодействие, и имена типов взаимодействия. Нв рис,6.9 представлен простейший вариант использования, где показаны основные элементы обозначений.
Действующие лица (актеры) изображены в виде стилизованных фигурок людей, а каждый класс взаимодействия представлен поименованным эллипсом. Множество вариантов использования охватывает все возможные взаимодействия, которые будут отражены в системных требованиях. На рис.6.10 показаны варианты использования, описывающие взаимодействие читателей и библиотеки. Предоставление услуг (сазвисов) Рис. б.9. Прасвмйтий вариант использования Предоставление услуг Пользовэтвль библиотеки с) — 1 Управление пользователями Персснвл — С:) Постатщиш Услуги каталоге Рпс. б.
1О. Впри акты использования для Спбливпики Иногда неясно, является ли вариант использования сценарием или, как предложено в [117], совокупностью сценариев, где каждый сценарий является "нитью", проходящей через вариант использования. В последнем случае возможны сценарии для нормального взаимодействия плюс сценарии для каждого возможного исключительного случая. В языке ()МЕ предусмотрено совместное использование диаграмм последовательностей и вариантов использовання. что существенно расширяет информационные возможности графического представления вариантов использования. Эти диаграммы показыва- б. Разработка требований 139 ют актеров, вовлеченных во взаимодействие, систеиные объекты, с которыми они взаимодействуют, и действия, которые связаны с этими объектами.
На рис.Б.11 показаны взаимодействия при покупке книг и создании каталога библиотеки. Язык моделирования Ь1МЬ фактически является птюидарзюм лля объектноориентированного представления вариантов использования, применяемых при формировании требований. Я покажу другие аспекты 11МЬ в главе 7, описывающей моделирование систем, и в главе 12, посвященной объектночтриентированному проектированию. % бкземплвр; Библиотечный зкземппер Составитель каталога Персовзп библиотеки Поставщик книг Наыв карточка Покупка книг Каталожная карточка Удаление из квтвлогз Рис. 6. 11.
Сиена иосыдоваметлнэлти уиракииия каэиыогаи 6.2.3. Этнографический подход Системы программного обеспечения не существуют изолированно от окружающего мира. Они эксплуатируются в определенной социальной и организационной среде, по. этому системные требования должны разрабатываться с учетом этой среды. Учет социальных и организационных требований часто имеет большое значение для успеха системы на рынке программных продуктов. Многие представленные на рынке программные системы практически не имеют спроса именно потому, что не учитывают важности социальных и организационных требований.
Этнографический подход к формированию системных требований используется для понимания н формирования социальных н организационных аспектов эксплуатации системы. Разработчик требований погружается в рабочую среду, где будет использоваться система. Его ежедневная работа связана с наблюдением и протоколированием реальных действий.
выполняемых пользователями системы. Значение этнографического подхода заключается в том, что он помогает обнаружить неявные требования к системе, которые отралтают реальные аспекты ее эксплуатации, а не формальные умозрительные процессы. Обычно людям трудно четко описать все аспекты выполняемой работы, поскольку способ выполнения часто определяется нх характером и практическим опытом. Они понимают свою работу, но не могут объяснить ее взаимосвязь с другимн видами работ, выполняемых в организации. Социальные и организационные факторы, которые оказывают влияние на работу, но не являются очевидными, могут стать явными, если описаны беспристрастными наблюдателями. 140 Часть 11.
Требования В [328) этнографический подход использован для изучения работы офиса. Показано, что фактическая работа, выполняемал в офисе, более сложна и динамична, чем предусматривает простая модель, принятал для системы автоматизации делопроизводства. Это расхождение между реальной работой и моделью послужило причиной того, что офисные системы автоматизации не показывали той эффективности, на которую были рассчитаны. Этнографический подход также применялся при формировании требований для систем управления воздушными перевозками [36. 168], систем управления диспетчерскими службами метрополитена [159), финансовых систем [169] и других [287, 65]. Этнографический подход к формированию требований можно объединить с прототипированием (рис.6.12).
Этнографический подход позволяет получить требования, кото. рые учитываются в разрабатываемом прототипе. Кроме того, этнографический подход используется при решении конкретных проблем прототипирования и при оценивании созданного прототипа [322). Рис. 6.12. Иепоеыование этноерафичешоео иоохооп и тфототипированил йея фоуеиированил еяребоепний Этнографический подход позволяет детализировать требования для критических систем, чею не всегда можно добиться другими методами разработки требований. Однако, поскольку этот иетод ориентирован на конечного пользователя, он не может охватить все требования предметной области и требования организационного характера.
Поэтому он не является всеохватывающим подходом в формировании требований и должен использоваться совместно с такимн подходами, как анализ вариантов использования. 6.3. Аттестация требований Атгестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибки в спецификации требований могут привести к переделке систеи ы и большим затратам, если будут обнаружены ао время процесса разработки системы или после введения ее в эксплуатацию, Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намною выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изиенение требований обычно влечет за собой значительные изменения в системе, после внесения которых она должна пройти повторное тестирование.
Во время процесса аттестации должны быть выполнены различные типы проверок документации требований. 1, Проверка правильности оеребовпиий. Пользователь иожет считать, что система необходима для выполнения некоторых определенных функций. Однако дальнейшие размышления и анализ могут привести к необходимости введения дополнительных или новых функций. Системы предназначены для разных пользователей с различ. 6. Разработка требований 141 2. Проверка иа неиротиооречивостаь Спецификация требований не должна содержать про.
3. Провеуоса иа ипеиоту. Спецификация требований должна содержать требования, ко- торые определяют все системные функции и ограничения, налагаемые на систему. 4. Проверка на выполнимость. На основе знания существующих технологий требования Существует рлд методов аттестации требований, которые можно использовать совместно или каждый в отдельности. 1.
Ойор туийюпний Требования системно анализируются рецензентами. Этот процесс обсуждается в следующем разделе. 2. Прототипирование На этом этапе прототип системы демонстрируется конечным 3. 4. ными потребностями, и поэтому набор требований будет представлять собой неко. тарый компромисс между требованиями пользователей системы. тиворечий. Это означает, что в требованиях не должно быть противоречащих друг щзузу ограничений или различных описаний одной и той же системной функции. должны быть проверены на возможность их реального выполнения. Здесь также проверяются возможности финансирования и график разработки системы. пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
