Опорные точки зрения

Любая средняя или большая система ПО обычно имеет различные типы конечных пользователей. Многие лица, участвующие в формировании требований, в своих требованиях к системе выражают собственные интересы. Например, в процессе формировании требований для системы банкоматов участвуют следующие лица.

1. Обычные клиенты банка, пользующихся услугами банкоматов.

2. Представители других банков, имеющих взаимные соглашения с данным банком о со­вместном использовании банкоматов.

3. Менеджеры филиалов банка, получающих информацию из системы управления бан­коматами.

4. Сотрудники филиалов банка, вовлеченные в повседневную работу системы банкома­тов, обрабатывающие рекламации клиентов и т.д.

5. Администраторы баз данных, ответственные за связь банкоматов с базой данных клиентов.

6. Руководители службы безопасности банка, обеспечивающей защиту системы банкоматов.

7. Отдел маркетинга банка, использующий систему банкоматов как средство маркетинга.

8. Разработчики аппаратных и программных средств, ответственные за сопровождение и модернизацию аппаратных и программных средств.

Этот список показывает, что даже для относительно простой системы существует мно­го различных точек зрения, которые должны быть рассмотрены. Различные точки зрения на проблему позволяют увидеть ее с разных сторон. Однако эти взгляды не являются пол­ностью независимыми и обычно перекрывают друг друга, а потому могут служить основой общих требований.

Подход с использованием различных опорных точек зрения к разработке требова­ний признает эти различные (опорные) точки зрения и использует их в качестве основы построения и организации как процесса формирования требований, так и непосредственно самих требований. Сильная сторона анализа, ориентированного на различные опорные точки зрения, в том, что он признает множество взглядов и обеспечивает основу для обнаружения противоречий в требованиях, предложенных различными лицами.

Различные методы предлагают разные трактовки выражения "точка зрения". Точки зрения можно трактовать следующим образом.

1. Как источник информации о системных данных. В этом случае на основе опорных точек зрения строится модель создания и использования данных в системе. В процессе формирования требований отбираются все такие точки зрения, на их основе определяются данные, которые будут созданы или использованы при работе системы, и способы обработки этих данных. Методы SADT [299, 308, 7*] и CORE [242] используют эту интерпретацию точек зрения.

2. Как структура представлений. В этом случае точки зрения рассматриваются как особая часть модели системы [115, 260]. Например, на основе различных точек зрения могут разрабатываться модели "сущность-связь", модели конечного автомата и т.д.

3. Как получатели системных сервисов. В этом случае точки зрения являются внешними (относительно системы) получателями системных сервисов [202, 203]. Точки зре­ния помогают определить данные, необходимые для выполнения системных сер­висов или их управления.

Каждая из этих интерпретаций точек зрения имеет сильные и слабые стороны. Опорные точки зрения как источники информации о системных данных и как представления имеют ценность для обнаружения противоречий в требованиях [101]. Но использовать их в процессе структурного анализа требований затруднительно, поскольку здесь не фиксируются связи между точками зрения и типами участников формирования требований.

Сценарии

Люди обычно легче воспринимают примеры из реальной жизни, чем абстрактные описания. Они легко понимают и могут оценить сценарии взаимодействия с программной системой. Специалисты могут использовать информацию, полученную из обсуждения сценариев взаимодействия с системой, для формулирования требований.

Сценарии особенно полезны для детализации уже сформулированных требований, по­скольку описывают последовательность интерактивной работы пользователя с системой. Каждый сценарий описывает одно или несколько возможных взаимодействий. В настоя­щее время разработаны многочисленные формы сценариев, которые предоставляют раз­личную информацию на разных уровнях детализации системы.

Сценарий начинается с общего описания, затем постепенно детализируется для созда­ния полного описания взаимодействия пользователя с системой. В большинстве случаев сценарий включает следующее.

1. Описание состояния системы в начале сценария.

2. Описание нормального протекания событий.

3. Описание исключительных ситуаций и способов их обработки.

4. Информацию относительно других действий, которые можно осуществлять во время выполнения сценария.

5. Описание состояния системы после завершения сценария.

Первоначальное описание сценария может быть выполнено неформально в процессе опроса лиц, формирующих требования. Альтернативой может служить структурный под­ход — разработка сценариев событий или вариантов использования.

Сценарии событий

Сценарии событий используются в методе VORD для документирования поведения системы, представленного определенными событиями. Каждое событие, например встав­ку карточки в банкомат или выбор сервиса, можно документально подтвердить отдельным сценарием. Сценарии включают описание потоков данных, системных операций и ис­ключительных ситуаций, которые могут возникнуть. На рис. 6.8 показан сценарий собы­тия "Начало транзакции", которое инициируется клиентом, вставляющим свою карточку в банкомат.

В схемах сценариев событий используется ряд условных обозначений.

1. Данные, поступающие в систему или исходящие из нее, представлены в эллипсах.

2. Управляющая информация показана стрелками в верхней части прямоугольников.

3. Внутрисистемные данные показаны справа от прямоугольников.

4. Исключительные ситуации показаны в нижней части прямоугольников. Там, где возможно несколько исключительных ситуаций, они заключаются в общий прямо­угольник, как показано на рис. 6.8.

5. Имя следующего события, ожидаемого после завершения сценария, приводится в затененном прямоугольнике.

На рис. 6.8 видно, что, когда карточка вставлена, запрашивается персональный иден­тификационный номер клиента (PINкод). Если карточка действительна, она может обра­батываться банкоматом, тогда управление переходит к следующей стадии сценария.

Карточка присутствует

Рис. 6.8. Сценарий события "Начало транзакции" На первой стадии сценария возможны три исключительные ситуации.

1. Превышение лимита времени ожидания. Клиент может не успеть ввести PINкод в от­веденное для ввода время. Карточка возвращается.

2. Недопустимая карточка. Карточка не опознается и возвращается.

3. Удержание карточки. Карточка удерживается банкоматом.

Каждую исключительную ситуацию можно определить более подробно, построив от­дельные диаграммы потоков данных и управления. Общая диаграмма сценария также мо­жет быть снабжена комментариями с дополнительной информацией, содержащей описа­ние действий, которые должны быть предприняты при возникновении исключительной ситуации.

"Проверка пользователя" — стадия проверки соответствия PINкода номеру счета кли­ента. Номер счета является выходными данными этой стадии. Возможная исключительная ситуация — ввод неверного PINкода, в этом случае PINкод запрашивается снова. На диаграмме показано, что повторный запрос может опять привести к исключительной си­туации. Если повторно введенный PINкод снова неверный, карточка возвращается. После события "Подтверждение пользователя" можно переходить к следующей стадии сценария "Выбор сервиса".

Поиск по сайту: