Проектирование системы

2 Разработка модели процессов объекта профессиональной деятельности

2.1 Построение модели прецедентов

Требования, предъявляемые к функционированию проектируемой системы, удобно выразить с помощью диаграммы прецедентов  использования, которая на понятном и доступном языке описывает основные процессы, происходящие в системе и значения этих процессов для актеров (пользователей системы). Такая диаграмма приведена на рисунке 2.1.

Рисунок 2.1 – Диаграмма прецедентов  использования системы

Наиболее подробное описание сценариев приведем для прецедента «Оформить выдачу товара», сценарии к другим прецедентам, относящимся к основным процессам работы прокатного пункта, опишем в более краткой форме.

2.1.1 Прецедент «Оформить выдачу  товара»

Основной исполнитель: оператор.

Заинтересованные лица и их требования:

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

Предусловия: оператор идентифицирован и аутентифицирован.

Результаты (постусловия): данные о сделке сохранены. Процент от сделки начислен оператору. Акт подтверждения сгенерирован и заверен обеими сторонами. Бухгалтерская и складская информация обновлена. Налоги начислены.

Основной (успешный) сценарий:

1. Оператор узнает у клиента  и вводит в систему наименование желаемого товара.

2. Система выводит список всех  единиц данного наименования  товара с указанием описания  товара, стоимости за каждый день  проката, места расположения товара  на складе.

3. Оператор предлагает клиенту  выбрать конкретную единицу товара.

4. Оператор регистрирует клиента  в системе.

5. Оператор уточняет у клиента  и вводит в систему срок  проката на выбранную единицу  товара.

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

7. Клиент оплачивает  услуги  проката.

8. Система устанавливает метку,  что данный товар находится  в прокате.

9. Система генерирует договор  о предоставлении услуг проката  данному клиенту в 2х экземплярах  (для клиента и оператора) с  указанием срока возврата.

10. Договор подписывается клиентом  и оператором, а также заверяется печатью.

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

Альтернативные потоки:

2а. Все единицы данного наименования  товара находятся у клиентов.

Система выводит ожидаемые сроки  возврата для каждой единицы товара.

Оператор сообщает информацию о  сроках возврата клиенту.

4а. Клиент уже зарегистрирован  в системе (обращается не в  первый раз).

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

2.1.2 Прецедент «Оформить возврат  товара»

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

1. Клиент подходит с товаром и договором к оператору.

2. Оператор вводит в систему  идентификатор клиента.

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

4.Оператор выбирает из списка  возвращаемый товар.

5. Оператор забирает и проверяет товар.

6. Система снимает с товара  метку «Находится в прокате»  и генерирует чек, подтверждающий  возврат данного товара.

7. Клиент покидает пункт проката  с чеком.

Альтернативные потоки:

3а. Срок возврата товара прошел.

   1. Система вычисляет пени  за просрочку по определенным правилам.

   2. Клиент выплачивает пени.

   3. Система генерирует чек,  подтверждающий возврат товара  и оплату пени.

5а. Клиент желает продлить  срок действия проката.

   1. Оператор вводит новый  срок возврата.

   2. Система по определенным правилам рассчитывает стоимость услуг и генерирует новый договор.

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

5б.  Возвращаемый товар имеет повреждения.

   1. Специалист оценивает стоимость  повреждений.

   2. Клиент выплачивает штраф.

   3. Система генерирует чек, подтверждающий  возврат товара и оплату штрафа.

2.1.3 Прецедент «Добавить новый  товар»

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

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

2. Система предлагает ввести параметры товара (наименование, стоимость и т.п.).

3. Заведующий складом вводит необходимые  данные о товаре.

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

2.1.4 Прецедент «Удалить товар»

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

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

2. Система предлагает выбрать товар  из каталога.

3. Администратор указывает данный  товар.

4. Система удаляет выбранный товар из каталога.

2.2 Построение модели процессов

На основе модели прецедентов построим модель процессов в методологии IDEF0. Модель IDEF0 представляет собой совокупность работ, преобразующих входы в выходы с использованием механизмов и управления. Модели процессов помогают понять особенности функционирования системы и взаимодействия с внешней средой. Для определения контекста модели процессов необходимо задать область моделирования, цель моделирования и точку зрения. Приведем пример построения модели IDEF0 для процесса предоставления товара клиенту, впервые обратившемуся в прокатный пункт, в аренду (прокат), т.к. этот процесс является основным при работе пункта проката.

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

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

Точка зрения. Модель строится с точки зрения разработчика данной системы.

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

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

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

Диаграмма декомпозиции состоит  из 3 блоков, ее вид показан в приложении А.

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

Перед выбором клиентом товара система  генерирует каталог «свободных»  товаров, т.е. находящихся в настоящий  момент на складе в состоянии готовности к выдаче. На вход работы Выдача каталога товаров поступает запрос товара клиентом. Из всего списка товаров под управлением информации о товарах формируется набор «свободных» товаров выбранного наименования.

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

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

3 Разработка модели данных объекта профессиональной деятельности

Модель данных проектируемой системы  разрабатывается с учетом предъявляемых  к ней функциональных требований. База данных системы состоит из следующих сущностей: Клиент, СтатусКлиента, Сотрудник, Должность, Товар, НаименованиеТовара, Поставщик, Заказ, Пеня, Штраф, Оплата, ВидОплаты, КредитКарта, Безналичный. Рассмотрим основные сущности системы подробнее.

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

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

Учет товаров, имеющихся в прокатном  пункте, ведется в связанных таблицах Товар и НаименованиеТовара. В таблице Товар указывается модель товара и код наименования товара, к которому он принадлежит (например, товар телевизор Sony 5340FT  принадлежит к наименованию Телевизор),  отражаются основные сведения о приобретенном товаре (КодПоставщика, ДатаПоступления, Цена) и стоимость услуги проката конкретной единицы данного товара.

В проектируемой базе данных можно  создать сущность КопииТоваров и связать ее идентифицирующей связью с сущностью Товар (рисунок 3.1).

Рисунок 3.1

Сущность КопииТоваров использовалась бы для идентификации конкретной единицы однотипного товара. Например, при приобретении 10 одинаковых чайников нет смысла хранить 10 одинаковых записей о поставщике, цене, дате приобретения, стоимости проката и т.п. С другой стороны, для клиента прокатного пункта представляет интерес конкретная единица (копия) чайника, поэтому необходимо ее идентифицировать. Когда атрибут КодТовара мигрирует в сущность КопииТоваров, то каждый экземпляр КопииТоваров зависит и от атрибута КодТовара и от атрибута НомерКопии, которые уникальным образом его определяют (ни один из этих двух атрибутов не может сам по себе уникальным образом определить конкретную копию товара).

Однако введение дополнительной таблицы  приведет к необходимости написания сложных запросов при формировании каталога товаров и снижению производительности системы (увеличению времени формирования каталога «свободных» товаров). Кроме того, вряд ли в прокатном пункте будет много копий товаров (приобретаемых в одно и то же время, у одного  и того же поставщика по одной и той же цене), поэтому создание отдельной таблицы КопииТоваров, скорее всего, не будет оправдано. Исходя из вышесказанного, проведем денормализацию: объединим таблицы Товар и КопииТоваров.

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