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

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

Поскольку форма оплаты может быть разная, а в будущем предполагается использовать для оплаты услуг кредитные карточки, то логично предусмотреть разбиение сущности Оплата на категориальные сущности: Наличные, КредитКарта и Безналичный (рисунок 3.2).

Рисунок 3.2

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

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

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

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

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

Полная схема модели данных представлена в Приложении Б.

4 Связь модели данных с моделью процессов

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

Работа системы начинается с выдачи каталога «свободных» товаров выбранного наименования. Информация о товарах, поступающая на управление работы Выдача каталога товаров связана со следующими данными: все поля таблицы НаименованиеТовара и поля КодНаименования, КодТовара, НаименованиеТовара, Модель, СтоимостьПроката, Статус, МестоХранения таблицы Товар. Такие атрибуты сущности Товар как ДатаПоступления, Поставщик и т.п. не используются в данной работе, т.к. представляют интерес только при приобретении новых товаров или проведении учета. В процессе выполнения работы из всех товаров выбранного наименования исключаются те, которые на день оформления находятся в аренде. Информация в таблицах базы данных на этом этапе не изменяется, каталог формируется на основе запросов к существующим записям. Таким образом, данные, используемые в этой работе, доступны только для чтения и работе не разрешается производить никаких операций, изменяющих данные (рисунок 4.1).

Рисунок 4.1

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

Регистрация клиента заключается  в добавлении новой записи в список клиентов (на вход поступает Список клиентов пункта и на управление Информация о клиенте). В этом случае разрешается добавлять записи в таблицу Клиент (рисунок 4.2).

Рисунок 4.2

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

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

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

Рисунок 4.3

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

Рисунок 4.4

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

5 Расчеты и оценки

5.1 Расчет требуемых ресурсов вычислительных средств

Реализация ИС предполагается в  среде MS Office 2000 Professional, поэтому требования к ресурсам будут в основном определяться минимальными требованиями к оборудованию для нормального функционирования данного пакета программ.

Стандартные требования для установки MS Office 2000 Proffessional.

Процессор. Pentium 75 или выше.

Память. Для Windows 95 или Windows 98: 16 Мб памяти для операционной системы и дополнительно 4Мб памяти для каждого одновременно запущенного приложения. (8 Мб для приложения Outlook).

Для Windows NT Workstation 4.0: 32 Мб памяти для  операционной системы и дополнительно 4 Мб памяти для каждого одновременно выполняющегося приложения (8 Мб для приложения Outlook).

Жесткий диск. 217 Мб.

Монитор. Монитор VGA, рекомендуется  монитор Super VGA.

Рассчитаем примерный объем  хранимых данных для оценки необходимого свободного места на жестком диске.

Каждая запись о товаре занимает около 130 байт. Для хранения информации о 3000 товарах необходимо 390 Кбайт. Запись в таблице Клиент занимает около 136 байт информации, следовательно, для хранения 30000 записей потребуется около 5 Мбайт. Если предположить, что в день будет оформляться примерно 10 заказов, то в год информации о заказах накопится примерно на 14400*(70 байт+50 байт)+14400*20байт/3=1824000 байт (70 байт занимает запись в таблице Заказ, 50 байт – в таблице Оплата, 20 байт – в таблице Пени, предполагается, что каждый заказ связан с одной оплатой и каждый третий заказ будет связан с уплатой Пени).

Таким образом, для хранения данных потребуется 7-8 Мбайт на жестком диске. На хранение других объектов базы данных (форм, отчетов, макросов, модулей) необходимо предусмотреть 10-15 Мбайт. Таким образом, на сервере потребуется минимум 7-8 Мбайт свободного места, а на клиентских машинах 10-15 Мбайт (если не установлен MS Office, то еще 217 Мбайт).

В данной реализации предполагается, что сервер будет использоваться для хранения данных, а остальные объекты базы данных будут располагаться на клиентских машинах. Система будет функционировать по технологии файл-сервер, поэтому минимальные требования к клиентским машинам будут определяться стандартными требованиями к установке MS Office, приведенными выше. Для повышения производительности труда оператора системы на его рабочее место рекомендуется установить монитор SVGA 17’’.

5.2 Расчет по функционально-ориентированной метрике

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

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

Первый тип пользовательской формы  представлен на рисунке 5.1 (форма Клиенты).

Рисунок 5.1

 

При расчетах по функционально-ориентированной  метрике используется 5 информационных характеристик:

1. Количество внешних вводов: 3 (Добавить, Удалить, Изменить); каждый элемент ввода состоит из 10 элементов данных (8 полей ввода, 1 поле со списком, 1 командная кнопка).

2. Количество внешних выводов: 1 (сообщение уведомления); элемент вывода состоит из 1 элемента данных (командная кнопка).

3. Количество внешних запросов: 0.

4. Количество внутренних логических файлов: 2 (таблица Клиент, таблица СтатусКлиента); таблица Клиент состоит из 10 элементов данных, таблица СтатусКлиента – из 3.

5. Количество внешних интерфейсных файлов: 0.

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

После сбора всей необходимой информации подсчитаем общую функциональную метрику (таблица 5.1).

Таблица 5.1

	Н	С	В	Итого
Внешние вводы	0 * 3 = 0	3 * 4 = 12	0 * 6 = 0	12
Внешние выводы	1 * 4 = 4	0 * 5 = 0	0 * 7 = 0	4
Внешние запросы	0 * 3 = 0	0 * 4 = 0	0 * 6 = 0	0
Внутренние логические файлы	2 * 7 = 14	0 * 10 = 0	0 * 15 =0	14
Внешние интерфейсные файлы	0 * 5 = 0	0 * 7 = 0	0 * 10 = 0	0
Общее количество FP				30

Аналогичным образом рассчитаем функциональность второго типа пользовательской формы (рисунок 5.2). Результаты расчета в таблице 5.2.

Рисунок 5.2

Таблица 5.2

	Н	С	В	Итого
Внешние вводы	0 * 3 = 0	0 * 4 = 0	1 * 6 = 0	6
Внешние выводы	1 * 4 = 4	0 * 5 = 0	1 * 7 = 7	11
Внешние запросы	2 * 3 = 6	0 * 4 = 0	0 * 6 = 0	6
Внутренние логические файлы	4 * 7 = 28	0 * 10 = 0	0 * 15 =0	28
Внешние интерфейсные файлы	0 * 5 = 0	0 * 7 = 0	0 * 10 = 0	0
Общее количество FP				51

С учетом того, что в проекте  предполагается использование 7 пользовательских форм первого типа и 5 пользовательских форм второго типа, подсчитаем общую функциональную метрику для всего проекта:

FP = 7 * 30 + 5 * 51 = 465

Полученную общую метрику необходимо субъективным образом взвесить, используя  следующую формулу:

FP = Общее_количество * (0,65+ 0,01 * å¹⁴_i=1F_i),                    (5.1)

где F_i – коэффициенты регулировки сложности.

Таблица 5.3 – Определение системных параметров приложения

№	Системный параметр	Описание	Коэф.
1	Передача данных	Сколько средств связи  требуется для передачи или обмена информацией с приложением или системой?	2
2	Распределенная обработка  данных	Как обрабатываются распределенные данные и функции обработки?	3
3	Производительность	Нуждается ли пользователь в фиксации времени ответа или  производительности?	3
4	Распространенность используемой конфигурации	Насколько распространена текущая аппаратная платформа, на которой  будет выполняться приложение?	0
5	Скорость транзакций	Как часто выполняются  транзакции? (каждый день, каждую неделю, каждый месяц)	5
6	Оперативный ввод данных	Какой процент информации надо вводить в режиме онлайн?	4
7	Эффективность работы конечного  пользователя	Приложение проектировалось  для обеспечения эффективной  работы конечного пользователя?	5
8	Оперативное обновление	Как много внутренних файлов обновляется в онлайновой транзакции?	3
9	Сложность обработки	Выполняет ли приложение интенсивную логическую или математическую обработку?	2
10	Повторная используемость	Приложение разрабатывалось  для удовлетворения требований одного или многих пользователей?	0
11	Легкость инсталляции	Насколько трудны преобразование и инсталляция приложения?	0
12	Легкость эксплуатации	Насколько эффективны и/или  автоматизированы процедуры запуска, резервирования и восстановления?	2
13	Разнообразные условия размещения	Была ли спроектирована, разработана и поддержана возможность  инсталляции приложения в разных местах для различных организаций?	0
14	Простота изменений	Была ли спроектирована, разработана и поддержана в приложении простота изменений?	0