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

В таблице 3.1 представлен пример списка Внутри/Вне, который мы составили для системы отслеживания запросов на покупку.

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

Используйте список Внутри/Вне для предметов, относящихся как к функциональной области действия, так и к области проектирования разрабатываемой системы.

Таблица 3.1. Пример списка Внутри/Вне

3.1. Функциональная область действия.

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

Список Действующее лицо/Цель.

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

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

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

Таблица 3.2. Пример списка Действующее лицо/Цель

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

Краткие описания вариантов использования.

Я буду постоянно напоминать о том, как важно управлять своими силами и, когда возможно, работать с низким уровнем точности. Список Действующее лицо/Цель представляет собой низший уровень точности описания поведения системы. Он очень полезен для работы с общим описанием системы. Следующий уровень точности будет либо основным сценарием, либо кратким описанием варианта использования.

Краткое описания варианта использования — это описание поведения варианта использования в двух-шести предложениях, где упоминаются лишь наиболее значительные действия и сбои. Оно напоминает разработчикам о том, что делается в варианте использования, и полезно для оценки сложности работы. Группы, строящие новую систему из готовых коммерческих компонентов (COTS), используют это описание при выборе компонентов. Некоторые проектные группы, например, имеющие очень хорошо налаженный внутренний обмен информацией и постоянное общение с пользователями, никогда ничего не пишут сверх этих кратких описаний вариантов использования в качестве требований. Остальная информация для требований появляется в ходе непрерывных обсуждений, представлена прототипами и регулярно поставляемыми дополнениями.

Таблица 3.3. Пример кратких описаний вариантов использования

Можно подготовить краткое описание варианта использования как таблицу, расширение списка Действующее лицо/Цель или непосредственно в виде части тела варианта использования в первом приближении. Пример краткого описания из таблицы 3.3 любезно предоставлен Полом Фордом, Стивом Янгом и Полом Бузайдом из компании Navigation Technologies.

3.2. Область действия проектирования.

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

Далее под областью действия подразумевается область действия проектирования, потому что функциональная область действия адекватно определяется списком Действующее лицо/Цель и вариантами использования. Область действия проектирования имеет отношение к каждому варианту использования.

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

Обычно писатели считают область действия системы настолько очевидной, что даже не упоминают ее. Однако это не так. Один автор думает, что областью действия является вся корпорация (см. рис. 3.1), другой считает областью действия все программные системы компании, третий подразумевает под ней новую систему клиент-сервер, тогда как четвертый думает только о клиенте либо только о сервере. Читатели, которые не знают об этих значениях по умолчанию, плохо ориентируются в таком документе или неправильно его понимают.

■ Невымышленная история.

Чтобы помочь составить заявку на подряд для разработки большой системы в заданное время и с фиксированными затратами, мы разобрали некоторые примеры проектов. Я выбрал принтер и описал его функцию. Эксперт по информационным системам рассмеялся. "Вы, привыкшие к персональному компьютеру, с ума меня сведете", — сказал он. "Вы что думаете, мы используем маленький лазерный принтер, чтобы печатать наши счета? У нас огромная система печати с цепным печатающим устройством, очередью ввода/вывода и прочим. Мы производим счета коробками!".

Я был потрясен. "Вы хотите сказать, что принтер не входит в область действия системы?".

"Конечно, нет! Мы будем использовать систему печати, которая у нас уже есть".

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

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

Что можно сделать, чтобы правильно понять документ?.

Единственный ответ, который я нашел — это снабдить каждый вариант использования меткой его области действия проектирования с помощью особых имен для наиболее значительных областей действия. Предположим, что компания MyTelCo проектирует систему NewApp, которая включает подсистему Searcher. Ниже следуют имена областей действия проектирования:.

■ Предприятие (MyTelCo) Ик. Вы обсуждаете поведение целой организации или предприятия для достижения цели основного действующего лица. Запишите в поле Область действия варианта использования название организации (MyTelCo), а не просто “компания”. Обсуждая отдел, употребляйте его название. Варианты использования для бизнеса пишутся в области действия предприятия.

■ Система (NewApp) ®. Это оборудование или программное обеспечение, которое вам поручили разрабатывать. Вне системы находятся все части оборудования, программного обеспечения и людских ресурсов, с которыми система должна взаимодействовать.

■ Подсистема (Seacher) 0®>. Вы раскрыли главную систему и собираетесь рассмотреть, как работает ее часть.

Использование графических пиктограмм для выделения области действия проектирования.

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

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

■ Областью действия варианта использования для бизнеса является предприятие. Обозначается пиктограммойдомика. Домик будет серым, если вы рассматриваете предприятие в целом как “черный ящик”. Если вы говорите об отделах и о персонале предприятия, оставьте домик белым.

■ Область действия варианта использования для системы — это компьютерная система. Значок — ящик: серый, если вы трактуете систему как “черный ящик”, и белый, если вы касаетесь работы ее компонентов.

■ Вариант использования для компонента относится к подсистеме или к компоненту разрабатываемой системы. В качестве графического символа компонента используется болт (см. варианты использования 13 — 17).

Примеры области действия проектирования.

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

(1) Область действия предприятие — система.

Предположим, мы работаем на телефонную компанию MyTelCo, которая разрабатывает новую систему Acura для приема заказов на обслуживание и модернизацию. Acura состоит из рабочей станции, подключенной к серверу. Сервер будет соединен с мэйнфреймом, на котором работает старая система BSSO. Система BSSO представляет собой обычный терминал, подключенный к мэйнфрейму. Нам не разрешили вносить в нее какие-либо изменения, мы можем только использовать ее интерфейсы.

К основным действующим лицам для Acura относятся клиент, служащий, различные администраторы и BSSO (последняя вне нашей области действия).

Определим цели, которые должна поддерживать система. Наиболее очевидная — “добавить новую услугу”. Основным действующим лицом для этой цели будет служащий компании, действующий от имени заказчика. Создадим несколько вариантов использования.

Теперь нужно установить, что представляет собой разрабатываемая система. Оказывается, нас интересуют две вещи:.

■ MyTelCo. Нам хотелось бы знать, как выглядит для пользователя обслуживание компанией MyTelCo, как реализуются новые услуги в полной форме — от первоначального запроса до выполнения и предоставления. Этот вопрос интересен вдвойне. Администраторы компании захотят узнать, какой представляется новая система внешнему миру, а группа разработчиков — увидеть контекст, в котором будет существовать новая система.

Этот вариант использования будет написан для области действия предприятия (ЦЦ), причем в поле области действия будет записано MyTelCo, и в варианте использования не будут упомянуты внутренние действующие лица (служащие, отделы, компьютеры). Этот вид варианта использования часто называют вариантом использования для бизнеса, так как он описывает деятельность предприятия.

■ Асига. Нам хотелось бы знать, что представляет собой обслуживание этой системой с точки зрения служащего или клиента, с одной стороны, и с точки зрения системы BSSO, с другой. К этому варианту использования разработчики относятся с наибольшим вниманием, так как он точно устанавливает, что они должны создавать. Вариант использования будет написан для области действия системы (в), в поле области действия будет записано Асига. В нем будут свободно фигурировать служащие, отделы и другие компьютерные системы, но никак не подсистемы рабочей станции и сервера.

Создадим два варианта использования. Чтобы не излагать одну и ту же информацию дважды, напишем вариант использования для предприятия на более высоком уровне (знак воздушного змея), показывая, как MyTelCo отвечает на запрос, предоставляет услугу, возможно, даже записывает стоимость на счет клиента и получает оплату. Задача варианта использования для предприятия — показать контекст, в котором будет работать новая система. Далее подробно опишем обработку запроса в течение 5-20 мин в варианте использования для цели пользователя и области действия Асига.

Вариант использования 6 # Добавить новую услугу (предприятие) Р.

Основное действующее лицо: клиент.

Область действия: MyTelCo.

Уровень: обобщенный.

1.

Клиент звонит в MyTelCo, запрашивает новую услугу...

2.

MyTelCo предоставляет... и т.д. ...

Вариант использования 7 в Добавить новую услугу (Асига) ЗЛ.

Основное действующее лицо: служащий (от имени внешнего клиента).

Область действия: Асига.

Уровень: цель пользователя.

1.

Клиент звонит в компанию, служащий обсуждает запрос с клиентом.

2.

Служащий находит клиента в системе Acura.

3.

Acura представляет текущий пакет услуг данного клиента... и т.д. ...

Для областей действия рабочей станции Acura или сервера Acura никаких вариантов использования писать не будем, поскольку нам это не очень интересно. Позднее кто-нибудь из группы разработчиков может заняться документированием проекта подсистем Acura с помощью вариантов использования. Тогда они напишут два варианта использования — один для области действия рабочей станции Acura, другой для области действия сервера Acura. Мой опыт показывает, что до подобных вариантов использования дело не доходит, так как существуют другие адекватные способы документирования архитектуры подсистем.

(2) Несколько компьютеров на одно приложение.

Следующая ситуация не столь тривиальна и весьма сложна. Сделаем надстройку над ситуацией MyTelCo.

Acura постепенно заменит BSSO. Запросы новой услуги будут записываться в Acura, а затем преобразовываться с помощью BSSO. Со временем набор функций Acura расширится. Эти две системы должны сосуществовать и синхронизироваться друг с другом. Таким образом, варианты использования придется написать для обеих систем: для новой Acura и для модифицированной для синхронизации с ней BSSO.

Сложность данной ситуации в том, что существуют четыре варианта использования: два для Acura и два для BSSO. Есть один вариант использования для каждой системы со служащим в качестве основного действующего лица и другой, в котором основное действующее лицо — это еще одна компьютерная система. Сократить эту четверку никак нельзя, но она смущает читателей, поскольку выглядит избыточной.

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

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

Вариант использования 8 0 Ввести и обновить запросы (объединенная система) Р.

Основное действующее лицо: служащий (от имени внешнего клиента).

Область действия: компьютерные системы, включая Acura и BSSO (см.

диаграмму).

Уровень: обобщенный Основной сценарий:.

1.

Служащий добавляет новую услугу в Acura.

2.

Acura записывает запрос новой услуги в BSSO.

3.

Некоторое время спустя служащий обновляет запрос услуги в BSSO.

4.

BSSO записывает обновленный запрос в Acura.

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

Вариант использования 9 Я Добавить новую услугу (в Acura) 33

Основное действующее лицо: служащий (от имени внешнего клиента).

Область действия: Acura Уровень: цель пользователя ... тело варианта использования ...

Вариант использования 10 ИР Записать запрос на новую услугу (в BSSO)

Основное действующее лицо: Acura Область действия: BSSO Уровень: цель пользователя ... тело варианта использования ...

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

0 Обновить запрос на обслуживание (в BSSO) 33.

Основное действующее лицо: служащий (от имени внешнего клиента)

Область действия: BSSO Уровень: цель пользователя ... тело варианта использования ...

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

Ш Записать обновленный запрос (в Асига)

Основное действующее лицо: BSSO Область действия: Асига Уровень: цель пользователя ... тело варианта использования ...

Если вы используете UML-диаграммы вариантов использования, можете не писать, а рисовать вариант использования обобщенного уровня. Это все же не уменьшает путаницы с четырьмя вариантами использования для цели пользователя, поэтому для каждого варианта следует записать основное действующее лицо, область действия и уровень. Может быть, стоит добавить диаграмму области действия.

Рис. 3.3, Комбинированная диаграмма варианта использования для Acura-BSSO. Здесь показаны связи четырех вариантов использования наиболее ясно, но эта диаграмма не является стандартной, поскольку на ней один вариант использования системы запускает другой.

Лично я не считаю, что это вносит ясность. Я бы предпочел нестандартную диаграмму варианта использования (см. рис. 3.3), чтобы показать связь двух систем. Эта диаграмма более наглядна, но ее труднее сопровождать. Диаграмма должна помогать вам и вашим читателям лучше понимать друг друга.

(3) Варианты использования "Гайки и болты".

Посмотрим, какдокументируют структуру проекта с помощью вариантов использования. Группа начала с 18-страничного, полного диаграмм описания правил для разрабатываемой системы. Было решено, что его слишком трудно читать, и начались эксперименты с вариантом использования как методом описания.

Группа решала эту задачу неделю. Сначала они набросали 40 вариантов использования, чтобы охватить все запросы, которые может обрабатывать главная ЭВМ. Используя расширения и список изменения данных, они сократили количество вариантов использования до шести.

Для большинства читателей эти варианты использования будут малопонятными. Полагаю, однако, что среди них есть технари-программисты, ищущие способы документирования своих проектов. Поэтому я включил эти варианты использования, чтобы показать, как эта группа документировала внутреннюю архитектуру и применяла список изменений. Обратите внимание, что подчиненные варианты использования подчеркнуты. Автор вариантов использования — Дэйл Маргел из Калгари.

Общее описание:.

Общая архитектура должна уметь решать параллельные задачи. Для этого она должна поддерживать потоки процессов и блокировку ресурсов. Эти функции выполняет система параллельного обслуживания (Concurrency Service Framework, CSF). CSF используется объектами клиента для защиты критичных разделов кода от небезопасного доступа со стороны множества процессов.

Вариант использования 13 Ф® Организовать последовательный доступ к ресурсу ^.

Основное действующее лицо: объект клиента CSF.

Область действия: система параллельного обслуживания (CSF).

Уровень: цель пользователя Основной сценарий:.

1.

Клиент CSF запрашивает блокировку ресурса, чтобы обеспечить к нему определенный доступ.

2.

Программа блокировки ресурса возвращает управление клиенту CSF, чтобы он мог использовать этот ресурс.

3.

Клиент CSF использует ресурс.

4.

Клиент CSF информирует программу блокировки ресурса.

о завершении работы с ресурсом.

5.

По завершении работы клиента CSF программа блокировки ресурса восстанавливает прежнее состояние ресурса.

Расширения:.

2а. Программа блокировки ресурса обнаруживает, что клиент CSF уже имеет доступ к этому ресурсу:.

2а 1. Программа блокировки ресурса применяет к запросу политику преобразования блокировки (вариант использования 14).

2Ь. Программа блокировки ресурса обнаруживает, что ресурс уже используется:.

2Ы. Программа блокировки ресурса применяет политику.

совместимости (вариант использования 15), чтобы обеспечить доступ клиенту CSF.

2с. Время блокировки ресурса не истекло:.

2с1. Программа блокировки ресурса запускает таймер занятости.

За. Заданный таймером занятости интервал истекает, прежде чем клиент информирует программу блокировки ресурса, что он закончил работу: За1. Программа блокировки ресурса посылает процессу клиента сообщение об исключительной ситуации.

За2. Отказ!.

4а. Программа блокировки ресурса обнаруживает ненулевое значение счетчика блокировок у клиента CSF:.

4а 1. Программа блокировки ресурса уменьшает значение счетчика обращений для запроса.

4а2. Успех!.

5а. Программа блокировки ресурса обнаруживает, что ресурс в настоящий момент не используется:.

5а 1. Программа блокировки ресурса применяет политику выбора доступа (вариант использования 16) для предоставления доступа одному из стоящих в очереди клиентов.

5Ь. Таймер занятости все еще работает:.

5Ы. Программа блокировки ресурса отменяет таймер занятости. Список изменений в технологии и данных:.

1. Указанный в запросе доступ может быть:.

• Монопольный » Совместный.

2с. Тайм-аут в блокировке ресурса может определять:.

• Клиент CSF.

* Политика блокировки ресурса.

♦ Глобальное значение по умолчанию.

Вариант использования 14 Ф® Применить политику преобразования блокировки КЗ.

Основное действующее лицо: объект клиента CSF Область действия: система параллельного обслуживания (CSF).

Уровень: подфункция Основной сценарий:.

1.

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

2.

Программа блокировки ресурса проверяет, не имеет ли уже клиент CSF совместного доступа к ресурсу.

3.

Программа блокировки ресурса проверяет, нет ли клиента CSF, ожидающего повышения уровня доступа.

4.

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

5.

Программа блокировки ресурса предоставляет клиенту CSF монопольный доступ к ресурсу.

6.

Программа блокировки ресурса увеличивает значение счетчика блокировок для клиента CSF.

Расширения:.

1а. Программа блокировки ресурса обнаруживает, что запрашивается совместный доступ:.

1 at. Программа блокировки ресурса увеличивает значение счетчика блокировок для клиента CSF.

1а2. Успех!.

2а. Программа блокировки ресурса обнаруживает, что клиент CSF уже имеет монопольный доступ:.

2а1. Программа блокировки ресурса увеличивает значение счетчика блокировок для клиента CSF.

2а2. Успех!.

За. Программа блокировки ресурса обнаруживает, что существует другой клиент CSF, ожидающий повышения уровня доступа:.

За1. Сигнализировать клиенту, что запрошенный доступ не может быть предоставлен.

За2. Отказ!.

4а. Программа блокировки ресурса обнаруживает, что существуют другие клиенты CSF, использующие ресурс:.

4а1. Программа блокировки ресурса переводит клиент в режим ожидания доступа к ресурсу (вариант использования 17).

Вариант использования 15 Ф® Применить политику совместимости доступа КЗ.

Основное действующее лицо: объект клиента CSF.

Область действия: система параллельного обслуживания (CSF).

Уровень: подфункция Основной сценарий:.

1.

Программа блокировки ресурса проверяет, запрашивается ли совместный доступ.

2.

Программа блокировки ресурса проверяет, используется ли в настоящий момент ресурс как совместный.

Расширения:.

2а. Программа блокировки ресурса обнаруживает, что запрашивается монопольный доступ:.

2а 1. Программа блокировки ресурса переводит клиент в режим ожидания доступа к ресурсу (вариант использования 17). Процесс возобновляется позже в результате проведения стратегии обслуживания блокировки.

2Ь. Программа блокировки ресурса обнаруживает, что в данный момент ресурс используется монопольно:.

2Ы. Программа блокировки ресурса переводит клиент в режим ожидания доступа к ресурсу (вариант использования 17). Изменения:.

1. Критерий совместимости может изменяться.

Вариант использования 16 О* Применить политику выбора доступа КЗ.

Основное действующее лицо: объект клиента CSF Область действия: система параллельного обслуживания (CSF).

Уровень: подфункция Основной сценарий:.

Цель в контексте: программа блокировки ресурса должна определять, какой запрос в режиме ожидания (если таковые имеются) следует обслужить.

Примечание: эта стратегия может меняться.

1.

Программа блокировки ресурса выбирает запрос, который ожидает дольше всех.

2.

Программа блокировки ресурса предоставляет доступ выбранному запросу (выбранным запросам), делая соответствующий процесс работоспособным.

Расширения:.

1а. Программа блокировки ресурса не находит ожидающих запросов:.

1а1. Успех!.

1Ь. Программа блокировки ресурса обнаруживает запрос, ожидающий повышения уровня доступа от разделяемого до монопольного:.

1Ы. Программа блокировки ресурса выбирает запрос на повышение уровня доступа.

1с. Программа блокировки ресурса выбирает запрос на разделяемый доступ.

1 с 1. Программа блокировки ресурса повторяется (шаг 1), пока не выберет следующий запрос на монопольный доступ. Изменения:.

1. Критерий выбора может изменяться.

Вариант использования 17 0» Перевести клиент в режим ожидания доступа к ресурсу Ю>.

Основное действующее лицо: объект клиента CSF Область действия: система параллельного обслуживания (CSF).

Уровень: подфункция Основной сценарий:.

Используется: программой блокировки ресурса СС 2,4.

1.

Программа блокировки ресурса приостанавливает процесс клиента CSF.

2.

Клиент CSF ждет возобновления процесса.

3.

Процесс клиента CSF возобновлен.

Расширения:.

1а. Программа блокировки ресурса обнаруживает, что был определен тайм-аут ожидания:.

1 а 1. Программа блокировки ресурса запускает таймер.

2а. Время ожидания истекает:.

2а 1. Сигнализировать клиенту CSF, что запрошенный доступ не может быть предоставлен.

2а2. Отказ!.

Список изменений в технологии и данных:.

1а1. Тайм-аут ожидания блокировки может определять:.

« Клиент CSF.

« Политика блокировки ресурса » Глобальное значение по умолчанию.

3.3. Предельные варианты использования.

В подразделе Область действия предприятие — система я рекомендовал писать два варианта использования: один для разрабатываемой системы, а другой — для внешней области действия. Теперь мы можем более конкретно поговорить о том, i как для каждого варианта использования найти самую ближнюю (предельную, j outermost) область из внешних областей действия проектирования, к которой ва- j риант использования еще применим, и написать вариант использования обобщен- 1 ного уровня для этой области действия.

j Вариант использования написан для области действия проектирования. Обычно j можно найти более широкую область действия проектирования, которая еще имеет ] основное лицо, действующее вне нее. Если вы продолжите расширение этой области действия, то достигнете точки, в которой дальнейшее расширение перенесет основное j действующее лицо внутрь области действия. Это и есть предельная область дейст- j вия. Иногда предельная область действия — это предприятие, отдел или просто j компьютер. Часто компьютерный отдел является основным действующим лицом в ва- j риантах использования, описывающих компьютерную безопасность, отдел сбыта — > основным действующим лицом в вариантах использования, посвященных рекламе, а I клиент — основным действующим лицом в вариантах использования для главных | функций системы.

| Обычно существуют только от двух до пяти предельных вариантов использова- j ния для системы в целом, так что не каждый вариант использования пишется дваж- j ды. Их так мало, потому что каждый объединяет основные действующие лица, ! имеющие сходные цели, в одной области действия проектирования и собирает все ! варианты использования более низкого уровня для этих действующих лиц.

: Я рекомендую писать предельные варианты использования, поскольку это зани- j мает мало времени и обеспечивает отличный контекст для набора вариантов исполь- j зования. Такие варианты использования показывают преимущества, которые i система предоставляет своим самым внешним пользователям. Они также обеспечивают оглавление для просмотра описания поведения системы.

j Рассмотрим предельные варианты использования, разработанные для компании i MyTeiCo и ее системы Acura.

MyTelCo решила предоставить Интернет-клиентам непосредственный : доступ к Acura, чтобы разгрузить своих служащих. Acura будет также форми- j ровать отчеты об объеме продаж каждого служащего. Кому-то придется орга- i низовать уровни безопасности доступа для клиентов и служащих. У нас есть четыре варианта использования: Добавить услугу (с помощью клиента), Добавить услугу (с помощью служащего), Сформировать отчет об объеме продаж и Организовать управление безопасностью доступа. Придется написать все четыре варианта использования с системой Acura в каче- ; стве области действия SuD. Нужно определить предельную область действия для каждого из них.

•.

Клиент находится вне MyTelCo, поэтому мы имеем один предельный вариант использования с клиентом в качестве основного действующего лица и MyTelCo в качестве области действия. Это будет вариант использования обобщенного уровня, трактующий MyTelCo как “черный ящик”, отвечающий на запрос клиента, предоставляющий услугу и тд. Практически этот вариант использования намечен в варианте использования 6.

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

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

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

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

3.4. Использование рабочих результатов определения области действия.

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

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

Рано или поздно вы, вероятно, увидите, что вам необходим четвертый элемент — концепция новой системы. Концепция объединяет все аспекты обсуждения и помогает решить, что следует внести в область действия в первую очередь.

Когда вы это проделаете, у вас будет четыре рабочих результата, которые помогут сформировать область действия системы:.

■ Концепция.

■ Диаграмма области действия проектирования.

■ Список Внутри/Вне.

■ Список Действующее лицо/Цель.

Эти результаты переплетены, и вы, скорее всего, будете изменять их по мере формирования области действия предстоящей разработки.

3.5. Упражнения.

Область действия проектирования.

3.1.

Назовите по крайней мере пять областей действия проектирования системы, о которой, с точки зрения пользователя, можно было бы сказать: "... Дженни стоит перед банкоматом своего банка.

Темно. Она вводит свой личный номер и ищет кнопку Ввод...”.

3.2.

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

3.3.

Для какой системы вы пишете требования? Что представляет собой ее пространство? Что внутри нее? С какими внешними объектами она должна взаимодействовать? В какую систему входит эта система и что находится снаружи этой внешней системы, с чем она должна поддерживать связь? Дайте название внешней системе.

3.4.

Создайте диаграмму нескольких областей действия для системы личного консультанта по финансам (PAF; см. упражнение 4.4).

3.5.

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

3.6.

В чем разница между двумя вариантами использования для бизнеса, если область действия предприятия рассматривается как "черный ящик" и как “прозрачный ящик"}