Главная | Обратная связь | Поможем написать вашу работу!

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

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

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

На основе этого подхода разработан метод VORD (Viewpoint-Oriented Requirements Definition – определение требований на основе точек зрения) для формирования и анализа требований [203, 204]. Основные этапы метода VORD показаны на рис. 6.3.

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

2. Структурирование точек зрения – создание иерархии сгруппированных точек зрения. Общесистемные сервисы предоставляются более высоким уровням иерархии и наследуются точками зрения низшего уровня.

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

4. Отображение системы точек зрения, которая показывает системные объекты, определенные на основе информации, заключенной в опорных точках зрения.

Рис. 6.3. Метод VORD

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

Я покажу использование метода VORD на первых трех шагах анализа требований для системы управления банкоматами. Банкомат имеет встроенное программное обеспечение для управления аппаратными средствами и для связи с центральной базой данных банковских счетов.

Банкомат принимает запросы клиента, выдает наличные деньги, информацию о счете, изменяет данные в базе данных банка и т.д. Банкоматы одного банка могут позволить клиентам других банков использовать какую-то часть своих сервисов (обычно это снятие со счета наличных денег и запрос о текущем балансе счета).

Первым шагом в формировании требований является идентификация опорных точек зрения. Во всех методах формирования требований, основанных на использовании точек зрения, начальная идентификация является наиболее трудной задачей. Один из подходов к идентификации точек зрения – метод "мозговой атаки", когда определяются потенциальные системные сервисы и организации, взаимодействующие с системой. Организуется встреча лиц, участвующих в формировании требований, которые предлагают свои точки зрения. Эти точки зрения представляются в виде диаграммы, состоящей из ряда круговых областей, отображающих возможные точки зрения (рис. 6.4).

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

Следующей стадией процесса формирования требований будет идентификация опорных точек зрения (на рис. 6.4 показаны в виде темных круговых областей) и сервисов (показаны в виде затененных областей). Сервисы должны соответствовать опорным точкам зрения. Но могут быть сервисы, которые не поставлены им в соответствие. Это означает, что на начальном этапе "мозговой атаки" некоторые опорные точки зрения не были идентифицированы. Например, для сервисов "Удаленное обновление ПО" и "Удаленная диагностика" (см. рис. 6.4) необходимо иметь точку зрения об обслуживании программного обеспечения.

Рис. 6.4. Диаграмма идентификации точек зрения

На рис. 6.5 показано распределение сервисов для некоторых идентифицированных на рис. 6.4 точек зрения. Один и тот же сервис может быть соотнесен с несколькими точками зрения.

Рис. 6.5. Сервисы, соотнесенные с точками зрения

Точки зрения также определяют входные данные и управляющую информацию для сервисов. Например, банкомат должен определять остаток денег после выдачи наличных. На ранних этапах процесса формирования требований эти данные и управляющая информация идентифицируются просто по имени. На рис. 6.6 представлена управляющая информация для точки зрения владельца счета, сервисы которой показаны на рис. 6.5. Управляющая информация вводится с помощью кнопок на панели банкомата, данные – посредством клиентской карточки или клавиатуры банкомата.

Рис. 6.6. Данные и управляющая информация

Информация, извлеченная из точек зрения, используется для заполнения форм шаблонов точек зрения и организации точек зрения в иерархию наследования. Это позволяет увидеть общие точки зрения и повторно использовать информацию в иерархии наследования. Сервисы, данные и управляющая информация наследуются подмножеством точек зрения. На рис. 6.7 показана часть иерархии точек зрения для системы банкоматов. Для простоты здесь представлены только сервисы, связанные с двумя точками зрения, без учета ряда точек зрения работников банка.

Рис. 6.7. Иерархия точек зрения

Следующая стадия процесса формирования требований – получение более детальной информации относительно сервисов, используемых сервисами данных, и управляющих данных. Эта информация извлекается из мнений лиц, формирующих требования, связанные с каждой опорной точкой зрения. Для этого используются шаблоны точек зрения и описания сервисов в виде сценариев событий. Эти сценарии обсуждаются в следующем разделе. Шаблоны точек зрения, описания сервисов и сценарии событий разрабатываются для всех идентифицированных опорных точек зрения и сервисов.

Поскольку в методе VORD необходимо обрабатывать большие объемы информации, поддержка CASE-средств значительно облегчает использование этого метода. CASE-средства для метода VORD можно свободно загрузить с Web-страницы данной книги.

Сценарии

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

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

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

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

Варианты использования

Варианты использования (use-case) [186] – это методика формирования требований, основанная на сценариях. Они стали основой нотаций в языке моделирования UML при описании объектных моделей систем. В самой простой форме в варианте использования определены действующие лица (в UML они называются актерами), т.е. пользователи, вовлеченные во взаимодействие, и имена типов взаимодействия. На рис. 6.9 представлен простейший вариант использования, где показаны основные элементы обозначений. Действующие лица (актеры) изображены в виде стилизованных фигурок людей, а каждый класс взаимодействия представлен поименованным эллипсом. Множество вариантов использования охватывает все возможные взаимодействия, которые будут отражены в системных требованиях. На рис. 6.10 показаны варианты использования, описывающие взаимодействие читателей и библиотеки.

Рис. 6.9. Простейший вариант использования

Рис. 6.10. Варианты использования для библиотеки

Иногда неясно, является ли вариант использования сценарием или, как предложено в [117], совокупностью сценариев, где каждый сценарий является "нитью", проходящей через вариант использования. В последнем случае возможны сценарии для нормального взаимодействия плюс сценарии для каждого возможного исключительного случая.

В языке UML предусмотрено совместное использование диаграмм последовательностей и вариантов использования, что существенно расширяет информационные возможности графического представления вариантов использования. Эти диаграммы показывают актеров, вовлеченных во взаимодействие, системные объекты, с которыми они взаимодействуют, и действия, которые связаны с этими объектами. На рис. 6.11 показаны взаимодействия при покупке книг и создании каталога библиотеки.

Язык моделирования UML фактически является стандартам для объектно-ориентированного представления вариантов использования, применяемых при формировании требований. Я покажу другие аспекты UML в главе 7, описывающей моделирование систем, и в главе 12, посвященной объектно-ориентированному проектированию.

Рис. 6.11. Схема последовательности управления каталогом

⇐ Предыдущая 40 41 42 43 444546 47 48 49 Следующая ⇒