UML Project

Система обработки заказов

Описание

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

Система должна обеспечивать возможность добавления новых заказов, изменения ранее введённых в неё заказов, учёта выполнения заказов, проведения инвентаризаций на складе с составлением описей. При получении нового заказа система должна также послать сообщение бухгалтерской системе, которая выписывает счёт. Любой заказ может содержать одну или более товарных позиций. Для каждой позиции заказа указывается наименование товара и его количество. Заполненный заказ получает кладовщик, который начинает сборку заказа. Если для каждой позиции товара на складе находится товар в достаточном количестве, то товар резервируется, и заказ помечается выполненным. Если требуемого товара нет на складе, то заказ может быть отменен, либо выполнение заказа задерживается до поступления товара на склад.

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

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

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

База данных системы будет поддерживаться реляционной СУБД. Система должна обеспечивать возможность продавцам вводить новые заказы и изменять заказы, хранящиеся в системе. Заказ может быть изменён до тех пор пока не закончились работы на складе по его сборке. Собранные (выполненные) заказы поставляются заказчикам, внесение в них изменений запрещено. Дата окончания сборки заказа хранится в системе. По её наступлении заказ считается выполненным. Не выполненный заказ может быть отменен.

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

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

Заведующий складом использует систему, чтобы напечатать остатки -- опись, в которой указывается текущее количество предметов мебели на складе. Остатки определяются системой по данным последней инвентаризации и данным о выполнении заказов. Например, если по данным инвентаризации было 10 стульев и 8 стульев отмечены как выполненные позиции заказов введённых после инвентаризации, (т. е. стулья переданы заказчикам или отложены в собираемые заказы), то текущий остаток -- 2 стула. При проведении инвентаризации для каждого предмета мебели со склада вводится текущее его количество, относительно которого будут рассчитываться остатки до следующей инвентаризации.

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

Глоссарий:

Бухгалтерская система (Accounting System)	Внешняя система, в которую передаются данные обо всех введённых заказах.
Заведующий складом (Warehouseman)	Пользователь системы. Имеет возможность распечатать остатки по состоянию склада на какой-либо день и провести инвентаризацию, т. е. ввести в систему данные о реальном (не рассчитанном) количестве хранимой мебели.
Заказ (Order)	Непустой перечень требуемых заказчиком позиций. Дата заказа указывает момент его создания. Дата поставки заказа отмечает день к которому должны быть завершены работы по сборке и поставке заказа. Дата выполнения заказа указывает день, когда была помечена выполненной последняя из невыполненных позиций заказа.
Заказчик (Customer)	Покупатель мебельного магазина. Данные о покупателе включают в себя ф., и., о., контактный телефон, адрес для доставки мебели.
Инвентаризационная опись (Inventory)	Перечень, в котором для каждого предмета мебели, хранящегося на складе, указано его количество.
Кладовщик (Stockman)	Пользователь системы. Работник склада, отвечающий за сборку заказов. Может помечать позиции заказов как выполненные, а невыполненные заказы -- как отменённые.
Остатки (Balance)	Данные о количестве предметов мебели на складе, рассчитываемые по сведениям из последней инвентаризации и данным о выполненных позициях заказов.
Позиция заказа (Order Item)	Один или более одинаковых предметов мебели, указанных в заказе. Позиция характеризуется наименованием, количеством, номером по порядку и статусом (выполнена или нет)
Предмет мебели (Article of furniture)	Предмет обстановки, хранящийся на складе. Может быть указан в позиции заказа. Характеризуется наименованием. Количество предметов мебели указывается в инвентаризационных описях.
Продавец (Salesperson)	Пользователь системы. Автор произвольного количества заказов. Может вводить заказы и изменять введённые им ранее заказы.

Диаграмма вариантов использования

Use Case Model

Исходя из потребностей действующих лиц, системный аналитик может предложить следующие варианты использования: Войти в систему, CRUD данных о заказах, Распечатать остатки, Провести инвентаризацию, Выполнить заказ, Отменить заказ. CRUD расшифровывается как Create, Read, Update, Delete (или как Create, Retrieve, Update, Destroy). Предполагается, что вариант использования «CRUD данных о заказах» описывает все функции системы, предоставляемые продавцу для управления сведениями о заказах.

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

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

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

Для каждого варианта использования составляется описание. Выполняют эту работу use case писатели.

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

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

Вариант использования «CRUD данных о заказах»:

• Краткое описание Данный вариант использования позволяет продавцу ввести данные о новом заказе изменить ранее введённых заказ или удалить заказ. Сведения о заказе включают в себя данные о заказчике, дату поставки заказа и перечень позиций в заказе. Система присваивает заказу дату создания. Новые сведения о заказе (изменения в заказе или сведения об удалении заказа) передаются системой в бухгалтерскую систему. Основной поток событий 1. Продавец сообщает о желании работать с заказами. 2. Система запрашивает связь с бухгалтерской системой. 3. Бухгалтерская система подтверждает, что связь установлена. 4. Система запрашивает требуемое действие (ввести заказ, изменить заказ, удалить заказ). 5. Продавец сообщает системе свой выбор. 6. Согласно выбору продавца выполняется один из подчинённых потоков (ввести, изменить или удалить заказ). 7. Система заканчивает сеанс связи с бухгалтерской системой. 8. Бухгалтерская система подтверждает, что сеанс закончен. Подчинённые потоки: 6.А. Ввести заказ 1. Система запрашивает данные о заказе. 2. Продавец вводит данные о заказчике и дате поставки заказа. 3. Для каждой позиции нового заказа выполняется: 3.1. Продавец вводит наименование и количество. 3.2. Система подтверждает, что наименование и количество указаны верно. 4. Продавец сообщает системе о необходимости сохранить заказ. 5. Система сохраняет данные о заказе. 6. Система передаёт данные о заказе бухгалтерской системе. 7. Управление передаётся на шаг 7 основного потока событий 6.Б. Изменить заказ 1. Система выводит список заказов, созданных текущим пользователем. 2. Продавец выбирает заказ из списка. 3. Система выводит все сведения о заказе. 4. Продавец изменяет сведения о заказе и сообщает системе о необходимости сохранить заказ. 5. Система подтверждает, что изменённые сведения о заказе корректны. 6. Система сохраняет данные о заказе. 7. Система передаёт данные об изменении заказа бухгалтерской системе. 8. Управление передаётся на шаг 7 основного потока событий 6.В. Удалить заказ 1. Система выводит список заказов, созданных текущим пользователем. 2. Продавец выбирает заказ из списка. 3. Система выводит все сведения о заказе и запрашивает подтверждение удаления заказа. 4. Продавец подтверждает системе необходимость удаления заказа. 5. Система удаляет все данные о заказе. 6. Система сообщает бухгалтерской системе об удалении заказа. 7. Управление передаётся на шаг 7 основного потока событий Альтернативные потоки 3.А. Бухгалтерская система недоступна 1. Система обнаруживает, что невозможно установить связь с бухгалтерской системой. 2. Система выдаёт сообщение об ошибке. 3. Вариант использования завершается. 6.А.3.2.А. Ошибка при вводе позиции заказа 1. Система обнаруживает, что наименование предмета мебели либо количество указаны неверно. 2. Система выдаёт сообщение об ошибке. 3. Управление передаётся на шаг 3 подчинённого потока 6.А. Ввести заказ. 6.Б.5.А. Ошибка при вводе позиции заказа 1. Система обнаруживает, что изменённые сведения о заказе некорректны. 2. Система выдаёт сообщение об ошибке. 3. Управление передаётся на шаг 3 подчинённого потока 6.А. Ввести заказ. 6.А.4.А., 6.Б.4.А, 6.В.4.А. Отмена действия с заказом 1. Продавец сообщает системе об отмене операции с заказом. 2. Управление передаётся на шаг 7 основного потока событий Предусловия Перед началом выполнения данного варианта использования продавец должен войти в систему. Постусловия Если вариант использования завершится успешно, операция с данными о заказе, требуемая продавцом, будет осуществлена, изменения в данных о заказах будут внесены в систему обработки заказов и переданы в бухгалтерскую систему. В противном случае система гарантирует, что изменения в данных о заказе не будут произведены, и что продавец получит доступ к данным только о своих заказах.

Структура модели

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

В системе обработки заказов можно выделить следующие ключевые абстракции: Order (данные о заказе), OrderItem (данные о позиции заказа), ArticleOfFurniture (данные о предмете мебели), Customer (данные о заказчике), User (учётная запись пользователя системы). Ассоциации между абстракциями показывают типы соединений между экземплярами ключевых абстракций. Мощности у полюсов указывают ограничения на количество соединений у одного экземпляра. Ассоциация может быть рефлексивной, т. е. соединяющей класс с ним самим. Такая связь описывает соединения между разными экземплярами одного класса. Чтобы различать роли объектов, участвующих в таких соединениях, полюсам рефлексивных ассоциаций обязательно дают имена. Также поступают при наличии двух ассоциаций между одной парой классов. Иногда имена полюсов указывают, чтобы пояснить назначение конкретной ассоциации. На диаграмме классов помимо ассоциаций могут присутствовать и другие связи. Так, связь между классом User и перечислимым типом TypeOfUser, указывает, что описание класса зависит от описания типа (так как атрибут type имеет тип TypeOfUser).