Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Моделирование бизнес-процессов и спецификация требований 271

Продолжение

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

образца

Объединение

фрагментов

Удаление лишних

вариантов исполь-

зования

Проблема

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

ния, описывающие очень

маленькие или изолиро-

ванные фрагменты пове-

дения, не выражают дос-

таточной для понимания

информации относитель-

но услуг, предоставляе-

мых системой (Транзак-

ции, значимые для поль-

зователей)

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

ния, результаты которых

незначительны, отвлека-

ют внимание и затрудня-

ют понимание системы

Предлагаемое решение

Объединяйте небольшие

взаимосвязанные вариан-

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

фрагменты вариантов ис-

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

использования, связан-

ные общей целью

Удалите варианты ис-

пользования, которые не

дают Ничего существен-

ного для системы или вы-

пали из текущего актив-

ного списка вариантов

использования

Варианты использования, безусловно, не единственный спо-

соб выражения функциональных требований. Это объясняется

следующими причинами:

• их описания слишком подробны. Заинтересованные лица

зачастую желают видеть лишь краткий перечень основных

функций;

• некоторые важные функции системы легче выразить

крат-

кой форме без привязки к именам вариантов использова-

ния.

Следовательно, помимо вариантов использования, функции

системы можно выразить через ее свойства (system features),

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

Более строго

контексте Rational Unified Process системное свой-

ство определяется как «наблюдаемая извне и обеспечиваемая

системой функция, которая непосредственно удовлетворяет пот-

ребности заинтересованного лица». Свойство можно облечь в

следующую лингвистическую форму:

система будет выполнять

«свойство

X»,

272 Глава 3

Спецификация требований в технологии Rational Unified

Process не требует обязательного моделирования бизнес-процес-

сов организации, для которых создается ПО, однако наличие

бизнес-моделей существенно упрощает построение системной

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

ли к начальной версии модели вариантов использования приме-

няются следующие правила.

• Для каждого исполнителя в модели бизнес-анализа, кото-

рый в перспективе станет пользователем новой системы, в

модели вариантов использования создается действующее

лицо

таким же наименованием.

В состав

действующих лиц

включаются также внешние системы, ифающие в бизнес-

процессах пассивную роль источников информации.

• Варианты использования для данного действующего лица

создаются на основе анализа обязанностей соответствую-

щего исполнителя (в простейшем случае для каждой опера-

ции исполнителя создается вариант использования, реали-

зующий данную операцию в системе).

Такая начальная версия модели описывает минимальный вари-

ант

системы,

пользователями которой являются только исполните-

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

дальнейшем

процессе развития сис-

темы ее непосредственными пользователями будут становиться

действующие лица бизнес-процессов, то модель вариантов исполь-

зования будет соответствующим образом модифицироваться.

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

дующем примере.

3-4.2.

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

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

В данном подразделе рассматривается спецификация требо-

ваний

системе регистрации

для

учебного заведения, бизнес-мо-

дель которого описана в подразд. 3.3.2.

Уточненная постановка

задачи для

системы

Перед руководителем информационной службы университе-

та ставится задача разработки автоматизированной системы ре-

гистрации студентов на дополнительные платные курсы. Систе-

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

Моделирование бизнес-процессов и спецификация требований 273

просматривать свои табели успеваемости с персональных компь-

ютеров, подключенных к локальной сети университета. Профес-

сора должны иметь доступ к системе, чтобы указать курсы, кото-

рые они будут читать, и проставить оценки за курсы.

Из-за недостатка средств университет не в состоянии заме-

нить всю существующую систему. Остается функционировать в

прежнем виде база данных, содержащая всю информацию о кур-

сах (каталог курсов). Эта база данных поддерживается реляцион-

ной СУБД. Новая система будет работать с существующей БД в

режиме доступа, без обновления.

В начале каждого семестра студенты могут запросить каталог

курсов, содержащий список курсов, предлагаемых в данном се-

местре. Информация о каждом курсе должна включать имя про-

фессора, наименование кафедры и требования к предваритель-

ному уровню подготовки (прослушанным курсам).

Новая система должна позволять студентам выбирать 4 курса

в предстоящем семестре. В дополнение к этому каждый студент

может указать 2 альтернативных курса на тот случай, если какой-

либо из выбранных им курсов окажется уже заполненным или от-

мененным. На каждый курс может записаться не более 10 и не

менее 3 студентов (если менее 3, то курс будет отменен). В каж-

дом семестре существует период времени, когда студенты могут

изменить свои планы (добавить или отказаться от выбранных

курсов). После того, как процесс регистрации некоторого студен-

та завершен, система регистрации направляет информацию в

расчетную систему, чтобы студент мог внести плату за семестр.

Если курс окажется заполненным в процессе регистрации, сту-

дент должен быть извещен об этом до окончательного формиро-

вания его личного учебного плана.

В конце семестра студенты должны иметь доступ к системе

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

кольку эта информация конфиденциальная, система должна

обеспечивать ее защиту от несанкционированного доступа.

Глоссарий проекта

Термин Значение

Курс Учебный курс, предлагаемый университетом.

274

Глава 3

Термин

Конкретный курс

Каталог курсов

Расчетная система

Оценка

Профессор

Табель

успеваемости

Список курса

Студент

Учебный график

Значение

Конкретное чтение данного курса в конкрет-

ном семестре (один и тот же курс может вес-

тись в нескольких параллельных сессиях).

Включает точные дни недели и время.

Полный каталог всех курсов, предлагаемых

университетом.

Система обработки информации об оплате за

курсы.

Оценка, полученная студентом за конкрет-

ный курс.

Преподаватель университета.

Все оценки за все курсы, полученные студен-

том

данном семестре.

Список всех студентов, записавшихся на

конкретный курс.

Личность, проходящая обучение в универси-

тете.

Курсы, выбранные студентом в текущем се-

местре.

Описание дополнительных спецификаций

Функциональные

возможности:

• Система должна обеспечивать многопользовательский ре-

жим работы.

• Если конкретный курс оказывается заполненным в то вре-

мя,

когда студент формирует свой учебный фафик, включа-

ющий данный курс, то система должна известить его об

этом.

Удобство

использования:

• Пользовательский интерфейс должен быть Wmdows-сов-

местимым.

Надежность.

• Система должна быть в работоспособном состоянии 24 часа

в день

дней в неделю, время простоя - не более 10%.

Производительность.

• Система должна поддерживать до 2000 одновременно рабо-

тающих с центральной базой данных пользователей и до 500

Моделирование бизнес-процессов и спецификация требований 275

пользователей, одновременно работающих с локальными

серверами.

Безопасность.

• Система не должна позволять студентам изменять любые

учебные графики, кроме своих собственных, а также не

должна позволять профессорам модифицировать конкрет-

ные курсы, выбранные другими профессорами.

• Только профессора имеют право ставить студентам оценки.

• Только регистратор может изменять любую информацию о

студентах.

Проектные

ограничения,

• Система должна быть интефирована с существующей сис-

темой каталога курсов, функционирующей на основе реля-

ционной СУБД.

Создание начальной

версии

модели вариантов использования

Действующие

лица:

• Регистратор

—

формирует учебный план и каталог курсов,

записывает студентов на курсы, ведет все данные о курсах,

профессорах, успеваемости и студентах.

• Расчетная система

—

получает отданной системы информа-

цию по оплате за курсы.

• Каталог курсов

—

база данных, содержащая информацию о

курсах.

Варианты

использования.

Исходя из потребностей действующих лиц, выделяются сле-

дующие варианты использования:

• Войти в систему;

• Зарегистрировать студента на курсы;

• Вывести табель успеваемости;

• Назначить курсы для преподавания;

• Проставить оценки;

• Вести информацию о профессорах;

• Вести информацию о студентах;

• Закрыть регистрацию.

Начальная версия диафаммы вариантов использования по-

казана на

рис.

3.19.

276 Глава 3

Rational Rose>

соиг5егед:^|1а1у$|^^Ш»:||Ше:ШШ::еШ^

ШШ.

Ш.^^^

!^Ш...^^^^»^

Bei»»t

^гу

Регистра-

Вести информацию о \ Проставить оценки

студентах

Вести информацию о

профессорах

^Ш^-

Каталог

курсов

Расчетная

система

Рис. 3.19. Начальная версия диаграммы вариантов использования

Модификация модели вариантов использования

Согласно постановке задачи в состав пользователей системы

следует ввести студентов и профессоров. При этом в описание

действующих лиц и вариантов использования вносятся измене-

ния. Модифицированная версия диаграммы вариантов использо-

Моделирование бизнес-процессов и спецификация требований 277

V Rationar Rose,- с€шг$егед^па1у8ШШ111:1ШШ;:СШ^!;ШШШш?^^

.Шш ш 3^^ %w^

Войти в систему

Пользователь

Каталог курсов

Выбрать курсы для

преподавания

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

Г^ ^^Вести информацию

-HF-^

профессорах

Регистратора

Закрыть регистрацию

ш^-^^^Ж^;

Вести информацию о

студентах

- - - ^ f

Расчетная

система

Рис.

3.20. Модифицированная диаграмма вариантов использования для

системы регистрации

вания показана на рис. 3.20. Поскольку вход в систему полностью

одинаков для регистратора, студента и профессора, их поведение

можно обобщить и ввести новое действующее «Пользователь» (су-

пертип) с общим вариантом использования «Войти в систему»,

подтипами которого являются Регистратор, Студент и Профессор.

278 Глава 3

Действующие

лица:

• Студент - записывается на курсы и просматривает табель

успеваемости.

• Профессор

—

выбирает курсы для преподавания и ставит

оценки.

• Регистратор

—

формирует учебный план и каталог курсов,

ведет все данные о курсах, профессорах и студентах.

• Расчетная система

—

получает от данной системы информа-

цию об оплате за курсы.

• Каталог курсов

—

база данных, содержащая информацию о

курсах.

Варианты

использования:

• Войти в систему;

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

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

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

• Проставить оценки;

• Вести информацию о профессорах;

• Вести информацию о студентах;

• Закрыть регистрацию.

Примеры спецификаций вариантов использования

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

систему».

Краткое

описание.

Данный вариант использования описывает вход пользователя

в систему регистрации курсов.

Основной

поток

событий.

Данный вариант использования начинает выполняться, когда

пользователь хочет войти в систему регистрации курсов.

Система запрашивает имя пользователя и пароль.

Пользователь вводит имя и пароль.

Система подтверждает имя и пароль, после чего открывает-

ся доступ в систему

Альтернативные

потоки.

Неправильное

имя/пароль.

Если во время выполнения основного потока обнаружится,

что пользователь ввел неправильное имя и/или пароль, система

Моделирование бизнес-процессов и спецификация требований 279

выводит сообщение об ошибке. Пользователь может вернуться к

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

этом выполнение варианта использования завершается.

Предусловия,

Отсутствуют.

Постусловия.

Если вариант использования выполнен успешно, пользова-

тель входит в систему.

противном случае состояние системы не

изменяется.

Вариант использования ^(Зарегистрироваться

на

курсы»:

Краткое

описание.

Данный вариант использования позволяет студенту зарегист-

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

может изменить свой выбор (обновить или удалить курсы), если

изменение выполняется в установленное время в начале семест-

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

ных курсов текущего семестра.

Основной поток

событий.

Данный вариант использования начинает выполняться, когда

студент хочет зарегистрироваться на предлагаемые курсы или из-

менить свой фафик курсов.

Система запрашивает требуемое действие (создать график,

обновить график, удалить график).

Когда студент указывает действие, выполняется один из

подчиненных потоков (создать, обновить, удалить или принять

график).

Создать

график.

Система выполняет поиск

каталоге доступных предлагае-

мых курсов и выводит их список.

Студент выбирает из списка

основных курса и

альтерна-

тивных курса.

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

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

Обновить

график.

Система выводит текущий график студента.

Система выполняет поиск в каталоге доступных предлагае-

мых курсов и выводит их список.

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

бавляя предлагаемые курсы.

280 Глава 3

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

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

Удалить

график.

Система выводит текущий график студента.

Система запрашивает у студента подтверждения удаления

графика.

Студент подтверждает удаление.

Система удаляет фафик. Если график включает предлагае-

мые курсы, на которые записался студент, он должен быть удален

из списков этих курсов.

Принять график.

Для каждого выбранного, но еще не «зафиксированного»

предлагаемого курса в фафике система проверяет выполнение

студентом предварительных требований (прохождение опреде-

ленных курсов), факт открытия предлагаемого курса и отсутствие

конфликтов фафика. Затем система добавляет студента в список

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

фафик сохраняется в системе.

Альтернативные

потоки.

Сохранить

график.

любой момент студент может вместо принятия фафика сох-

ранить его. В этом случае шаг «Принять фафик» заменяется на

«Незафиксированные» предлагаемые курсы помечаются в

фафике как «выбранные».

График сохраняется в системе.

Не

выполнены предварительные

требования,

курс заполнен или

имеют место

конфликты графика.

Если во время выполнения подчиненного потока «Принять

фафик» система обнаружит, что студент не выполнил необходи-

мые предварительные требования или выбранный им предлагае-

мый курс заполнен, или имеют место конфликты фафика, то вы-

дается сообщение об ошибке. Студент может либо выбрать дру-

гой предлагаемый курс и продолжить выполнение варианта ис-

пользования, либо сохранить фафик, либо отменить операцию,

после чего основной поток начнется с начала.

График

не найден.

Если во время выполнения подчиненных потоков «Обновить

фафик» или «Удалить фафик» система не может найти график

студента, то выдается сообщение об ошибке. После того, как