3 Функциональные требования к системе

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

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

- определить общие границы и контекст моделируемой предметной области;

- сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

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

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

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

Проектируемая система состоит из двух частей.

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

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

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

Итак, система представляет собой совокупность мобильных устройств, оснащенных АРМ Курьеров, объединенных в единое целое через АРМ Диспетчера (рисунок 3, таблица 5).

Рисунок 3 – Общая структура АИС

Таблица 5 – Реестр основных компонентов системы

Теперь более детально определим функциональные требования к клиентской части системы (рисунок 4, таблица 6).

Рисунок 4 – Диаграмма прецедентов для клиентской части системы, размещаемой на коммуникаторах с ОС Android (АРМ Курьера)

Таблица 6 – Реестр вариантов использования для АРМ Курьера

Проведем декомпозицию объекта АРМ Диспетчера по выполняемым функциям (рисунок 5, таблица 7).

Рисунок 5 – Диаграмма прецедентов для стационарной, серверной части системы (АРМ Диспетчера)

Таблица 7 – Реестр вариантов использования для АРМ Курьера