Определение требования к информационной подсистеме
Варианты использования проектируемой информационной подсистемы действующими лицами бизнес-процесса
Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой и отражает представление о поведении системы с точки зрения пользователя.
Действующее лицо (actor) — это роль, которую пользователь играет по отношению к системе. Действующие лица делятся на три основных типа — пользователи системы, другие системы, взаимодействующие с данной, и время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе.
Для наглядного представления вариантов использования применяются диаграммы вариантов использования.
На диаграмме вариантов использования показано взаимодействие между вариантами использования и действующими лицами. Она отражает функциональные требования к системе с точки зрения пользователя. Таким образом, варианты использования — это функции, выполняемые системой, а действующие лица — это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. Направленная от варианта использования к действующему лицу стрелка показывает, что вариант использования предоставляет некоторую информацию, используемую действующим лицом.
Действующие лица могут играть различные роли по отношению к варианту использования. Они могут пользоваться его результатами и сами непосредственно в нем участвовать. Значимость различных ролей действующего лица зависит от того, каким образом используются его связи.
Цель построения диаграмм вариантов использования — документирование функциональных требований к системе в самом общем виде.
Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.
Достоинства модели вариантов использования заключаются в том, что она:
определяет пользователей и границы системы;
определяет системный интерфейс;
удобна для общения пользователей с разработчиками;
используется для написания тестов;
является основой для написания пользовательской документации;
хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).
В процессе курсового проектирования были выделены следующие участники процесса и их действия:
Клиент
Узнает о выполнении рейсов текущего дня;
Запрашивает информацию о расписании рейсов, стоимости билетов и наличии мест;
Покупает билеты.
База данных тарифов
База данных наличия билетов
Текущее время
Рисунок 1.3.1 - Диаграмма вариантов использования
Для того, чтобы учитывать временные изменения рейсах, которые будут выполняться, следует обновлять временным таймером через какой-то промежуток времени данные таблицы «Рейсы, которые будут выполняться». Обновление таблицы «Рейсы, которые будут выполняться» будет осуществляться сверху - вниз процедурой procedure TForm1.Button1Click(Sender: TObject). Данная процедура копирует нужные строчки таблицы «Рейсы» и помещает их в первую запись таблицы «Рейсы, которые будут выполняться», остальные записи в данной таблице будут сдвигаться вниз, при этом последняя запись в таблице будет стираться (т.е. сначала данные о рейсе будут находиться в первой строчке таблицы БД и по мере обновления будут спускаться по строчкам таблицы вниз, последняя строчка будет стираться).
Чтобы учитывать временные изменения в выполненных рейсах, следует обновлять временным таймером через какой-то промежуток времени данные таблицы «Выполненные рейсы». Обновление таблицы «Выполненные рейсы» будет осуществляться сверху - вниз процедурой procedure TForm1.Button2Click(Sender: TObject). Данная процедура копирует нужные строчки таблицы «Рейсы» и помещает их в первую запись таблицы «Выполненные рейсы», остальные записи в данной таблице будут сдвигаться вниз, при этом последняя запись в таблице будет стираться.
Из разработанных диаграмм вариантов использования и диаграммы деятельности можно выделить основные требования к подсистеме.
Требования к подсистеме:
предоставить информацию о расписании рейсов;
предоставить информацию о расписании рейсов, стоимости билетов, наличии мест;
продать билеты клиенту;
накопить данные о поступивших заказов;
подготовить информацию о выполненных рейсов;
подготовить информацию о предстоящих рейсах.
Функциональные возможности
- система должна обеспечивать многопользовательский режим работы;
- система должна реализовывать все вышеперечисленные варианты использования.
Удобство использования
- доступ к пользовательскому интерфейсу должен осуществляться через Web-браузер.
Надежность
- система должна быть в работоспособном состоянии 24 часа в сутки, 7 дней в неделю. Время простоя не более 10%.
Производительность
-система должна поддерживать до 10000 одновременно работающих с ней пользователей.
Безопасность
- система должна обеспечивать конфиденциальность частной информации;
Проектные ограничения
- система должна быть интегрирована с рядом существующих систем (БД наличия билетов, БД тарифов, маркетинговой БД).