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

 

Реализация системы предполагается на языке Java. Требования к ресурсам обусловлены в основном минимальными требованиями для нормального функционирования ОС и библиотек Java.

Требования для компьютера технолога:

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

Память: Для Windows 95 или Windows 98: 64 Мб памяти для операционной системы.

Для Windows NT 4.0: 128 Мб памяти для операционной системы.

Жесткий диск: 1 Гб.

Монитор: Монитор SVGA 17’’.

Рассчитаем примерный объем хранимых данных для оценки необходимого свободного места на жестком диске. Каждая запись в Специализации путей занимает около 40 байт. 5000 записей займет 200 Кбайт. Запись о Станции будет примерно занимать 50 байт и при хранении 60000 станций объём составит 3Мбайта. Оставшиеся сущности в целом будут занимать приблизительно 1Мбайт. Таким образом, для хранения годовой информации, при условии, что за сутки будет оправлено 20 поездов до 100 станций, потребуется 365*40*20*100= 29200000 байт. Таким образом, для хранения годовой информации о 20 поездах идущих до 100 станций в сутки потребуется 30 Мбайт. Весь этот объём данных будет храниться на отдельном диске, на сервере, кроме этого там будут храниться ежедневные копии БД (так называемых level backup), что дополнительно потребует около 2 Мбайт. Требования к серверу БД связаны с тем, что все действия (операции) с БД будет выполнять именно сервер БД, а компьютер технолога будет только отображать результат действий сервера. Кроме того, данный сервер будет использован для работы других АРМов и на нем будут работать несколько разных БД (10-15).

Требования для сервера БД:

Процессор: Pentium II 400 или выше.

Память: 512 Мб.

Жесткие диски: 4,3 Гб для системы + 10 Гб для хранения баз данных.

Монитор: Монитор SVGA 14’’(может отсутствовать).

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

 

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

 

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

Рис. 5.2

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

1. Количество внешних вводов: 1 (кнопка OK); данный элемент ввода состоит из 7 элементов данных (1 поле ввода, 5 полей со списком, 1 командная кнопка).

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

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

4. Количество внутренних логических файлов: 4 (справочник ДоминирующееНаправление, справочник сопутствующееНаправление, таблица Станции, таблица Пути); таблица Станции состоит из 6 элементов данных, справочник ДоминирующееНаправление, справочник сопутствующееНаправление итаблица Станции  – из 3.

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

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

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

 

Таблица 5.2

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

 

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

Таблица 5.2

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

 

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

 

FP = 3 * 36 + 2 * 32 = 172

 

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

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

 

Каждый коэффициент может принимать следующие значения: 0 — нет влияния, 1 - случайное, 2 — небольшое, 3 — среднее, 4 — важное, 5 — основное.

Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (таблица 5.3).

В результате количество функциональных указателей равно:

 

FP = 172 * (0.65 + 0.29) = 162

Используя таблицу перевода, а также учитывая, что реализация ИС предполагается с использованием языка Visual Basic, получим LOC-оценку проекта:162 * 32 = 5184 (строк кода).

Заключение

 

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

Система реализуется с помощью СУБД Informix с использованием языка Java. Данная СУБД была выбрана в связи с тем, что данная СУБД используется в настоящее время.

Язык Java была выбрана в виду направленности отдела ВЦЛП на Web-разработку, а также из-за перехода на другую СУБД (Oracle 8.1.7) с целью снижения возможных изменений внутреннего содержания программы.

Библиографический список

 

1. Серверы корпоративных баз данных. www.citforum.ru;

2. П. Ноутон, Г.Шильдт. Java ^тм 2: Пер. с англ.- СПб.: БХВ-Петербург, 2001.