Пример использования объектно-ориентированного подхода

В данном примере используется методика Rational Unified Process, описанная в предыдущем подразделе.

Постановка задачи

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

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

Студент может выбрать 4 курса в предстоящем семестре. В до­полнение к этому каждый студент может указать 2 альтернатив­ных курса на тот случай, если какой-либо из выбранных им кур­сов окажется уже заполненным или отмененным. На каждый курс может записаться не более 10 и не менее 3 студентов (если менее 3, то курс будет отменен). В каждом семестре существует период времени, когда студенты могут изменить свои планы (добавить или отказаться от выбранных курсов). После того, как процесс ре­гистрации некоторого студента завершен, регистратор направляет информацию в расчетную систему, чтобы студент мог внести пла­ту за семестр. Если курс окажется заполненным в процессе реги­страции, студент должен быть извещен об этом до окончательно­го формирования его личного учебного плана. В конце семестра студенты могут просмотреть свои табели успеваемости.

Создание модели бизнес-процессов

Действующие лица:

1. Студент — записывается на курсы и просматривает свой табель ус­певаемости.

2. Профессор — выбирает курсы для преподавания и ставит оценки за курсы.

3. Расчетная система - получает информацию по оплате за курсы.

4. Каталог курсов — база данных, содержащая информацию о курсах.

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

Исходя из потребностей действующих лиц, выделяются следующие варианты использования (Business Use Case):

1. Зарегистрироваться на курсы;

2. Просмотреть табель успеваемости;

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

4. Проставить оценки.

Диаграмма вариантов использования для модели бизнес-процессов показана на рис. 3.17.

Пример спецификации Business Use Case: «Зарегистрироваться на курсы»:

Наименование:

Зарегистрироваться на курсы

Краткое описание

Рис. 3.17. Диаграмма вариантов использования для модели

бизнес-процессов

Данный Business Use Case позволяет студенту зарегистрироваться на предлагаемые курсы в текущем семестре. Студент может изменить свой выбор, если изменение выполняется в установленное время в начале се­местра.

Основной сценарий:

1. Студент приходит к регистратору и просит зарегистрировать его на предлагаемые курсы или изменить свой график курсов.

2. В зависимости от запроса студента, выполняется один из подчи­ненных сценариев (создать график или изменить график).

Подчиненный сценарий «Создать график»:

1. Регистратор выполняет поиск в каталоге доступных в настоящий момент курсов и выдает студенту их список.

2. Студент выбирает из списка 4 основных и 2 альтернативных курса.

3. Регистратор формирует график студента.

4. Выполняется подчиненный сценарий «Принять график».

Подчиненный сценарий «Изменить график»:

1. Регистратор находит текущий график студента.

2. Регистратор выполняет поиск в каталоге доступных в настоящий момент курсов и выдает студенту их список.

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

4. После выбора регистратор обновляет график.

5. Выполняется подчиненный сценарий «Принять график».

Подчиненный сценарий «Принять график»:

1. Для каждого выбранного студентом курса регистратор подтверж­дает выполнение студентом предварительных требований (прохождение определенных курсов), факт открытия предлагаемого курса и отсутствие конфликтов графика.

2. Регистратор вносит студента в список каждого выбранного пред­лагаемого курса. Курс фиксируется в графике.

Альтернативные сценарии.

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

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

Система каталога курсов недоступна:

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

Регистрация на курсы закончена:

Если в самом начале выполнения регистрации окажется, что регист­рация на текущий семестр уже закончена, то процесс завершится.

Создание модели бизнес-анализа

Исполнители.

1. Регистратор — формирует учебный план и каталог курсов, записы­вает студентов на курсы, ведет все данные о курсах, профессорах, успеваемости и студентах.

Сущности.

2. Студент.

3. Профессор.

4. График студента (список курсов).

5. Курс (в программе обучения).

6. Конкретный курс (курс в расписании).

Диаграмма классов для модели бизнес-анализа, описывающей Business Use Case «Зарегистрироваться на курсы», приведена на рис. 3.18.

Рис. 3.18. Диаграмма классов модели бизнес-анализа

3.4.

СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ

К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ²³

3.4.1.

ОСНОВЫ СПЕЦИФИКАЦИИ ТРЕБОВАНИЙ

К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

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

Для выявления требований используются (в различных соче­таниях) следующие методы:

1. собеседование (интервьюирование);

2. анкетирование;

3. моделирование и анализ бизнес-процессов (далее будет рас­смотрена методика перехода от объектной бизнес-модели к системным требованиям);

4. сессии по выявлению требований (мозговой штурм);

5. создание и демонстрация пользователям работающих про­тотипов приложений (для выявления замечаний и дополни­тельных требований).

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

1. опрашиваемое лицо может свободно и открыто отвечать на вопросы и почувствовать себя участником проекта;

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

Недостатки метода собеседования:

2. метод трудоемкий и дорогой, поэтому может оказаться не­практичным;

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

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

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

Анкетирование позволяет с помощью анкет получать сведения от большого количества людей, контролируя правильность их от­ветов. При работе с большой аудиторией этот метод наиболее эф­фективен. Преимущества метода анкетирования заключаются в следующем:

1. люди могут заполнять и возвращать анкеты в удобное для них время;

2. люди склонны сообщать в ответах действительные факты, если анкетирование анонимное;

3. это относительно недорогой способ сбора данных с участи­ем большого количества людей.

Недостатки метода анкетирования:

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

2. нет возможности пояснить или переформулировать непра­вильно понятые вопросы, наблюдать и анализировать реак­цию респондента на отдельные вопросы;

3. подготовка анкет может потребовать много времени.

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

Основная идея создания прототипа состоит в быстрой пост­ройке модели системы, которая, как предполагается, нужна пользователю. Обычно в прототипах многие детали опускаются, в том числе процедуры контроля входных данных, обработки ошибок, резервного копирования и восстановления данных. Не учитываются также производительность и масштабируемость. Создание прототипа никак не противоречит и не препятствует применению других методов получения требований от пользова­теля. Однако иногда только с помощью прототипа удается заста­вить клиента начать обсуждение требований, которые при другом подходе кажутся слишком абстрактными. Кроме того, работа с прототипом часто помогает получить требования, которые в про­тивном случае так и остались бы неизвестными. Прототип хорош еще и тем, что он является неким осязаемым доказательством (или иллюзией) прогресса в разработке системы. А в некоторых случаях он может даже поддерживать какие-то ограниченные ра­бочие возможности системы. К сожалению, как отмечалось в гла­ве 1, реальный опыт работы с прототипами свидетельствует, что их создание обычно препятствует любому официальному доку­ментированию требований, следовательно, требования формули­руются только в виде кода. Детали работы системы, игнорируе­мые прототипом (обработка ошибок, резервное копирование и др.), могут так и не появиться в виде требований.

Выявленные в результате применения перечисленных мето­дов требования к ПО оформляются в виде ряда документов и мо­делей. К основным документам, регламентируемым технологией Rational Unified Process, относятся:

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

2. Словарь предметной области (глоссарий) — определяет об­щую терминологию для всех моделей и описаний требова­ний к системе. Глоссарий предназначен для описания терминологии предметной области и может быть использован как словарь данных системы.

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

Примеры документов приведены в подразд. 3.4.2.

Функциональные требования к системе моделируются и до­кументируются с помощью вариантов использования (use case), которые в контексте процесса управления требованиями тракту­ются следующим образом:

1. вариант использования фиксирует соглашение между участ­никами проекта относительно поведения системы;

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

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

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

1. Действующие лица и цели (перечисляются действующие лица и все их цели, которые будет обеспечивать система).

2. Краткое изложение варианта использования (в один абзац) или основной поток событий (без анализа возможных оши­бок).

3. Условия отказа (анализ мест возникновения возможных ошибок в основном потоке событий).

4. Обработка отказа (написание альтернативных потоков со­бытий).

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

Методика моделирования вариантов использования в техно­логии Rational Unified Process предусматривает специальное сог­лашение, связанное с группировкой структурных элементов и диаграмм модели. Это соглашение включает следующие правила:

1. Все действующие лица, варианты использования и диаграм­мы вариантов использования помещаются в пакет с именем Use Case Model.

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

структуризации модели в соответствии с типами пользовате­лей (действующих лиц);

функциональная декомпозиция;

разделение модели на пакеты между группами разработчиков (в качестве объектов управления конфигурацией).

Все рекомендации по написанию качественных вариантов ис­пользования, включая перечисленные в подразд. 2.5.1, можно из­ложить в виде набора образцов, которые перечислены в табл. 3.3.

Таблица 3.3

Образцы написания вариантов использования

Наименование образца	Проблема	Предлагаемое решение
Формирование команды разработчиков
Небольшая команда разработ­чиков	Участие слишком многих людей в написании вари­анта использования не­эффективно; компромисс между многими различ­ными точками зрения мо­жет привести к неудовлетворительным резуль­татам при создании сис­темы	Ограничьте число разра­ботчиков, отрабатываю­щих детали варианта ис­пользования, двумя или тремя людьми. Для под­ключения дополнитель­ных участников используйте образец Двухуров­невое рецензирование
Состав сторонних участников	Невозможно удовлетво­рить потребности всех за­интересованных лиц, не обмениваясь информаци­ей с ними	Активно привлекайте за­казчиков и заинтересо­ванных лиц в вашей орга­низации к разработке ва­риантов использования
Сбалансированная команда	Команда из близких по роду деятельности, оди­наково мыслящих людей может создать небольшой набор ограниченных ва­риантов использования, не удовлетворяющий об­щим потребностям	Формируйте команду из людей с различными спе­циализациями, представ­ляющими интересы раз­личных заинтересован­ных лиц. Команда долж­на включать как разра­ботчиков, так и пользова­телей
Организация процесса разработки
Глубина после об­щего представле­ния	Невозможно продвигать­ся вперед и создавать на­бор согласованных вари­антов использования, ес­ли тратить впустую время на последовательное на­писание подробных вари­антов использования	Разрабатывайте сначала общее представление ва­риантов использования, затем постепенно добав­ляйте детали, работая с группой взаимосвязан­ных вариантов использо­вания
Итерационная разработка	Разработка вариантов ис­пользования за один про­ход затруднительна, ус­ложняет внесение допол­нительной информации и затрудняет выявление факторов риска	Разрабатывайте варианты использования итераци­онно, повышая на каждой итерации их точность и корректность
Множество форм	Различные проекты тре­буют различную степень формальности и различные шаблоны. Использо­вать один и тот же шаб­лон вариантов использо­вания непродуктивно	Выбирайте формат вари­антов использования, ос­новываясь на проектных рисках и предпочтениях участников
Двухуровневое ре­цензирование	Многие заинтересован­ные лица могут пожелать принять участие в рецен­зировании вариантов ис­пользования. Это слиш­ком долгое и дорогостоя­щее занятие	Используйте два вида ре­цензирования: первое, проводимое небольшой группой внутренних участников, может вы­полняться многократно; второе, проводимое пол­ной группой, выполняет­ся, как правило, один раз
Своевременное завершение	Разработка модели вари­антов использования сверх потребностей заин­тересованных лиц и раз­работчиков приводит к напрасным тратам ресур­сов и затягивает проект	Прекращайте разработку вариантов использова­ния, как только они дос­тигают необходимой пол­ноты и удовлетворяют потребности участников проекта
Свобода творчества	Чрезмерное внимание к стилю написания вариан­тов использования тор­мозит работу	Небольшие различия в стиле написания вариан­тов использования несу­щественны. Если вариант использования достиг не­обходимой полноты, его автор имеет право на сти­листические отступления
Организация набора вариантов использования
Общепринятая четкая концепция	Недостаточно четкое представление о системе может привести к неуве­ренности и противопо­ложным мнениям среди заинтересованных лиц и быстро парализовать про­ект	Необходимо подготовить и утвердить концепцию системы, в которой четко определены ее цели и роль в деятельности орга­низации. Распространите концепцию среди всех участников проекта
Видимые границы	Если вы не определили границы системы, ее масштаб будет расти не­контролируемым образом	Установите четкую и ви­димую границу между системой и внешней сре­дой, перечислив людей и оборудование, взаимо­действующих с данной системой
Ясный состав действующих лиц	Если выявлять только пользователей системы, игнорируя роли, которые они играют по отноше­нию к системе, можно упустить существенную часть поведения системы или ввести избыточное поведение	Идентифицируйте действующих лиц, с кото­рыми должна взаимодей­ствовать система, и роли, которые они играют по отношению к системе. Четко опишите каждую роль
Транзакции, зна­чимые для пользо­вателей	Система несовершенна, если она не может пре­доставить пользователям необходимые услуги и не выполняет цели и задачи,, определяемые ее концеп­цией	Идентифицируйте важ­ные, значимые услуги, которые система предос­тавляет действующим ли­цам для удовлетворения их потребностей
Разворачива­ющееся представ­ление	Количество шагов в опи­сании поведения системы превышает возможности охвата и интересы раз­личных типов читателей вариантов использования	Создайте иерархическую организацию набора ва­риантов использования, которую можно развер­нуть для большей детали­зации, или свернуть, что­бы скрыть детали и пока­зать контекст
Отдельный вариант использования
Законченная единственная цель	Неправильно заданные цели не дают разработчи­кам четко определить, где заканчивается один вариант использования и на­чинается другой	Каждый вариант исполь­зования должен иметь за­конченную и четко опре­деленную цель, которая может находиться на лю­бом уровне образца Раз­ворачивающееся предс­тавление
Имя в виде гла­гольной фразы	Бессмысленные, слиш­ком общие имена вариан­тов использования не да­ют читателям правильно­го представления, на них сложно ссылаться	Именуйте каждый вари­ант использования актив­ной глагольной фразой, отражающей цель основ­ного действующего лица
Сценарий и фраг­менты	Читатели должны иметь возможность легкого сле­дования по интересующе­му их сценарию, в про­тивном случае они могут утратить интерес или по­терять важную информа­цию	Основной сценарий дол­жен быть предельно простым, без анализа воз­можных ошибочных си­туаций. Фрагменты сце­нария, отражающие аль­тернативы, должны рас­полагаться под ним
Исчерпывающие альтернативы	Вариант использования может иметь много аль­тернатив. Отсутствие не­которых из них означает, что разработчики непра­вильно понимают поведе­ние системы, и система может получиться несо­вершенной	Описывайте все альтерна­тивы и ошибочные ситуа­ции, которые могут иметь место в варианте исполь­зования
Перегрузка ин­формацией	Включение нефункцио­нальных требований в ва­риант использования мо­жет быстро привести его в неопределенное и беспо­рядочное состояние	Включите дополнитель­ные позиции в шаблон варианта использования за пределами текста сце­нария, чтобы отразить полезную дополнитель­ную информацию
Точность и читае­мость	Варианты использова­ния,, слишком сложные для нетехнических специ­алистов или слишком неточные для разработчи­ков, несовершенны и мо­гут привести к созданию неадекватной системы	Сделайте вариант ис­пользования достаточно читаемым, чтобы заинте­ресованные лица могли в нем разобраться и оце­нить его, и достаточно точным, чтобы разработ­чики понимали, что им делать
Сценарии и шаги
Обнаруживаемые условия	Разработчики вариантов использования всегда ре­шают проблему, сколько и какие условия включить в их описание	Включайте только реаль­но обнаруживаемые усло­вия. Объединяйте усло­вия, которые оказывают на систему одинаковое воздействие
Уровни шагов	Чрезмерно крупные или мелкие шаги сценария ва­рианта использования де­лают вариант использова­ния трудным для воспри­ятия и понимания	Оставляйте в сценарии от трех до девяти шагов. В идеальном случае все ша­ги должны быть на близ­ких уровнях и на уровне абстракции, следующем за целью варианта ис­пользования
Выполнение цели действующего ли­ца	У читателей и разработ­чиков возникают пробле­мы в понимании поведе­ния системы, если неяс­но, какое действующее лицо отвечает за выпол­нение шага сценария, и что оно делает для его за­вершения	При описании каждого четко указывайте, какое действующее лицо вы­полняет действие, и что оно получает по его за­вершении
Продвижение впе­ред	Разработчики должны ре­шить, как много поведе­ния включить в каждый шаг. Слишком много де­талей делает вариант ис­пользования длинным и трудным для чтения	Исключайте или объеди­няйте шаги, которые не означают никакого дви­жения вперед для действу­ющего лица. Упрощайте фрагменты, которые от­влекают внимание читате­ля от Движения вперед
Нейтральность к технологии	Включение технологи­ческих ограничений и де­талей реализации в опи­сание варианта использо­вания увеличивает слож­ность и затрудняет пони­мание его цели	Описание варианта ис­пользования должно быть нейтральным по отноше­нию к технологии
Связи между вариантами использования
Общее поведение	Описание одинаковых шагов в различных вари­антах использования за­нимает лишнее время и затрудняет понимание об­щих процессов в модели вариантов использования	Выражайте общие дей­ствия в виде «включае­мых» вариантов исполь­зования
Перемещение аль­тернатив	Длинные или сложные описания альтернатив могут занять доминирую­щее положение и пока­заться более важными, чем они заслуживают	Рассмотрите возможность выделения сложных аль­тернатив в отдельный ва­риант использования
Абстракция	Попытка описать в одном варианте использования две или более различных альтернатив, ни одна из которых не является до­минирующей, приводит к проблемам	Создайте обобщенный абстрактный вариант ис­пользования. Поместите каждый отдельный вари­ант сценария, уточняю­щий абстракцию, в спе­циализированный вари­ант использования
Модификация существующих вариантов использования
Удаление изли­шеств	Чрезмерно длинный ва­риант использования гро­моздок и труден для рабо­ты, уводит в сторону вни­мание пользователей	Переместите длинный, громоздкий фрагмент или слишком сложное расши­рение в отдельный вари­ант использования
Объединение фрагментов	Варианты использова­ния, описывающие очень маленькие или изолиро­ванные фрагменты пове­дения, не выражают дос­таточной для понимания информации относитель­но услуг, предоставляе­мых системой (Транзак­ции, значимые для поль­зователей)	Объединяйте небольшие взаимосвязанные вариан­ты использования или фрагменты вариантов ис­пользования в варианты использования, связан­ные общей целью
Удаление лишних вариантов исполь­зования	Варианты использова­ния, результаты которых незначительны, отвлека­ют внимание и затрудня­ют понимание системы	Удалите варианты ис­пользования, которые не дают ничего существен­ного для системы или вы­пали из текущего актив­ного списка вариантов использования

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

1. их описания слишком подробны. Заинтересованные лица зачастую желают видеть лишь краткий перечень основных функций;

2. некоторые важные функции системы легче выразить в крат­кой форме без привязки к именам вариантов использова­ния.

Следовательно, помимо вариантов использования, функции системы можно выразить через ее свойства (system features), представляющие собой высокоуровневые, краткие утверждения. Более строго в контексте Rational Unified Process системное свой­ство определяется как «наблюдаемая извне и обеспечиваемая системой функция, которая непосредственно удовлетворяет пот­ребности заинтересованного лица». Свойство можно облечь в следующую лингвистическую форму: система будет выполнять «свойство X».

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

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

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

Такая начальная версия модели описывает минимальный вари­ант системы, пользователями которой являются только исполните­ли бизнес-процессов. Если в дальнейшем в процессе развития сис­темы ее непосредственными пользователями будут становиться действующие лица бизнес-процессов, то модель вариантов исполь­зования будет соответствующим образом модифицироваться.

Применение данных правил будет проиллюстрировано в сле­дующем примере.

3.4.2.