И. Соммервилл - Инженерия программного обеспечения (1133538), страница 35
Текст из файла (страница 35)
4. Отображение системы точек зрения, которая показывает системные объекты, определенные на основе информации, заключенной в опорных точках зрения. Рис. бЗ. Мезмд ЧОИ) Точки зрения и информация о сервисах в методе ЧОКП собираются с помощью стандартных форм (шаблонов точек зрения и шаблонов описания сервисов). В методе ЧОКП также используются различные графические представления, включая диаграммы иерархии точек зрения, подобные показанным на рис. 6.7, и сценарии событий (пример сценария показан на рис. 6.8).
Я покажу использование метода ЧОКП на первых трех шагах анализа требований для системы управления банкоматами. Банкомат имеет встроенное программное обеспечение для управления аппаратными средствами и для связи с центральной базой данных банков. ских счетов. Банкомат принимает запросы клиента, выдаст наличные деньги, информацию о счете, изменяет данные в базе данных банка и т.д. Банкоматы одного банка могут позволить клиентам других банков использовать какую.то часть своих сервисов (обычно зто снятие со счета наличных денег н запрос о текущем балансе счета). Первым шагом в формировании требований является идентификация опорных точек зрения. Во всех методах формирования требований, основанных на использовании точек зрения, начальная идентификация явллется наиболее трудной задачей.
Один из подходов к идентификации точек зрения — метод "мозговой атаки", когда определяются потенциальные системные сервисы и органиэации, взаимодействующие с системой. Организуется встреча лиц, участвующих в формировании требований, которые предлагают свои точки зрения. Зги точки зрения представляются в виде диаграммы, состоящей из ряда круговых областей, отображающих возможные точки зрения (рнс. 6.4). Во время "мозговой атаки" необходимо идентифицировать потенциальные опорные точки зрения, системные сервисы, входные данные, нефункциональные требования, управляющие события и исключительные ситуации. Источниками информации, которые можно использовать в создании этого начального образа системы, мокнут служить документы, описывающие назначение системы, знания инженеров-программистов иэ предыдущих проектов или опыт клиентов банка.
Может быть проведен опрос менеджеров банка, об. служнвзющего персонала, консультантов, инженеров и клиентов. 134 х1асть 11. Требования Следующей стадией процесса формирования требований будет идентификация опорных точек зрения (на рис. 6.4 показаны в виде темных круговых областей) и сервисов (показаны в виле затененньпс областей). Сервисы должны соотвегспювать опорным точкам зрения. Но мо. гуг бьггь сервисы, которые не поставлены им в соответствие. Это означает, что на начальном этапе "мозговой атаки" некоторыс опорные точки зрения не были идентифицированы.
Например, д>и сервисов "Удаленное обновление ПО" и "Удаленная диагностика" (см. рис. 6.4) необходимо иметь точку зрения об обслуживании программного обеспечение. Рис. 6.4. Диаграмма иде>стификавии точек>)мнил На рис. 6.6 пою>вано распределение сервисов для некоторых идентифицированных на рис.
6.4 точек зрения. Один н тот жс сервис может быть соотнесен с несколькими точками зрения. ВЛАЙЕмЕЦ СЧЕТА ИНОСТРАННЫЙ КНИЕНТ КдССИР БАНКА Рис. Г>.5. Сероиеи, сосо>кеспскые с точками >Рекал 6. Разработка требований 155 Точки зрения также определяют входные данные и управляющую информацию для сервисов. Например, банкомат должен определять остаток денег после выдачи наличных. На ранних этапах процесса формирования требований эти данные и управляющая информация идентифицируются просто по имени. На рис. 6.6 представлена управляющая информация для точки зрения владельца счета, сервисы которой показаны на рис. 6.5.
Управляющая информация вводится с помощью кнопок на панели банкомата, данные— посредством клиентской карточки или клавиатуры банкомата. Рис. 6.6. Длиные и улрпепяюелпя инфермпаил Информация, извлеченная из точек зрения, используется для заполнения форм шаб. эонов точек зрения и органиэации точек зрения в иерархию наследования. Это позволяет увидеть общие точки зрения и повторно использовать информацию в иерархии наследо. вания. Сервисы. данные и управляющая информация наследуются подмножеством точек зрения.
На рис. 6.7 показана часть иерархии точек зрения для системы банкоматов. Для простоты здесь представлены только сервисы, связанные с двумя точками зрения, без учета рядаточекзрения работниковбанка. Рис. 6.7. Иерпрлил мочек эреиил 136 з1асть 11, Требования Следующая стадия процесса формирования требований — получение более детальной информации относительно сервисов, используемых сервисами данных, и управляющих данных. Эта информация извлекается из мнений лиц, формирующих требования, связанные с каясдой опорной точкой зрения. Для этого используются шаблоны точек зрения и описания сервисов в виде сценариев событий. Эти сценарии обсуждаются в следующем разделе.
Шаблоны точек зрения, описания сервисов и сценарии событий разрабатываются для всех идентифицированных опорных точек зрения и сервисов. Поскольку в методе ЧОВ11 необходимо обрабатывать большие объемы информации, поддержка САЗЕ. средств значительно облегчает использование этого метода. САЗЕ- средства для метода ЪОК11 можно свободно загрузить с ггеЬ.страницы данной книги. 6.2.2.
Сценарии Люди обычно легче воспринимают примеры из реальной жизни, чем абстрактные описания. Они легко понимают и могут оценить сценарии взаимодействия с программной системой. Специалисты могут использовать информацию, полученную из обсуждения сценариев взаимодействия с системой, для формулирования требований. Сценарии особенно полезны для детализации уже сформулированных требований, по. скольку описывают последовательность интерактивной работы пользователя с системой. Каждый сценарий описывает одно или несколько возможных взаимодействий.
В настоящее время разработаны многочисленные формы сценариев, которые предоставляют различную информацию нв разных уровнях детализации системы. Сценарий начинается с общего описания, затем постепенно детализируется для создания полного описания взаимодействия пользователя с системой. В большинстве случаев сценарий включает следующее.
1. Описание состояния системы в начале сценария. 2. Описание нормального протекания событий. 3. Описание исключительных ситуаций и способов их обработки. 4. Информацию относительно других действий, которые можно осуществлять во время выполнения сценария. 5. Описание состояния системы после завершения сценария. Первоначальное описание сценария может быть выполнено неформально в процессе опроса лиц, формирующих требования. Альтернативой может служить структурный подход-раэработкасценариев событий или вариантовиспользования. Сценарии событий Сценарии событий используются в методе ЧОИ) для документирования поведения системы, представленного определенными событиями. Каждое событие, например вставку карточки в банкомат или выбор сервиса, можно документально подтвердить отдельным сценарием.
Сценарии включают описание потоков данных, системных операций и исключительных ситуаций, которые могут возннкнугь. На рис. 6.8 показан сценарий события "Начало транзакции", которое инициируется клиентои, вставляющим свою карточку в банкомат. В схемах сценариев событий используется ряд условных обозначений. 1. Данные, поступающие в систему или исходящие из нее, представлены в эллипсах. 2. Управляющал информация показана стрелками в верхней части прямоугольников, б. Разработка требований 137 3.
Внутрисистемные данные показаны справа от прямоугольников. 4. Исключительные ситуации показаны в нижней части прямоугольников. Там, где возможно несколько исключительнык ситуаций, они заключаются в общий прямо. угольник, как показано на рис. б.8. 5. Имя следующего события, ожидаемого после завершения сценария, приводится в затененном прямоугольнике. На рис. 6.8 видно. что, когда карточка вставлена, запрашивается персональный идентификационный номер клиента (Р1Х-кодр Если карточка действительна, она может обрабатываться банкоматом, тогда управление переходит к следующей сталин сценария. ...1..
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
