Мои Конспекты
Главная | Обратная связь

...

Автомобили
Астрономия
Биология
География
Дом и сад
Другие языки
Другое
Информатика
История
Культура
Литература
Логика
Математика
Медицина
Металлургия
Механика
Образование
Охрана труда
Педагогика
Политика
Право
Психология
Религия
Риторика
Социология
Спорт
Строительство
Технология
Туризм
Физика
Философия
Финансы
Химия
Черчение
Экология
Экономика
Электроника

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





Помощь в ✍️ написании работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

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

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код снова неверный, карточка возвращается. После события "Подтверждение пользователя" можно переходить к следующей стадии сценария "Выбор сервиса".

Доверь свою работу ✍️ кандидату наук!
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой



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







©2015-2020 mykonspekts.ru Все права принадлежат авторам размещенных материалов.