Реферат: Создание автоматизированного рабочего места технолога станции

/>/>/>/>/>/>/>/>/>Введение

Цель выполнения данного проекта является созданиеавтоматизированного рабочего места (АРМ) технолога станции.

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

1. Разработка и анализтехнического задания

/>/>/>/>/>/>/>/> 1.1 Описание предметной области

В рамках курсового проекта необходимо на основе СУБДразработать программу для автоматизации рабочего места технолога станции сприменением Web-технологии.

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

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

Создание АРМ предусматривает повышение уровняиспользование пропускной способности, повышение производительности труда,улучшение условий труда.

 1.1.1 Назначение и классификация станций

Железнодорожные линии делятся на участки, а участки наперегоны. Границами смежных перегонов служат раздельные пункты: станции,разъезды, обгонные пункты. Границы участков – участковые или сортировочные станции.

Станцией называется раздельный пункт, имеющий путевоеразвитие, позволяющее производить операции по приёму, отправлению, скрещиваниюи обгону поездов. На станциях размещены технические устройства, обеспечивающиепропускную и провозную способность железнодорожных линий: сооружения иустройства станционного хозяйства, локомотивные и вагонные депо, пунктытехнического обслуживания вагонов и т.д. От работы станции в значительнойстепени зависят: обеспечение выполнения плана перевозок пассажиров и груза;отправление поездов по графику и в соответствии с планом формирования поездов –полными по массе и длине, исправными в техническом и коммерческом отношении;безопасность движения поездов, их приёма, отправления, скрещивания, обгона иманёвров; регулярность, своевременность и сохранность доставки грузов; снижениесебестоимости перевозок; выполнение комплексного показателя работы железныхдорог – оборота вагона (за время своего оборота вагон находится в движениитолько 30% времени, а 70% – на станции).

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

 1.1.2 Техническое оснащение станций

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

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

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

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

/>/>/>/>/>/>/>/> 1.2 Разработка технического задания

Необходимо разработать информационную систему пообработке справочной информации. К проектируемой системе предъявляютсяследующие функциональные требования:

1. Система должна обеспечиватьдостоверность вводимых данных;

2. Система должна иметь графическийинтерфейс;

3. Должна защищать информацию отпосягательств со стороны неавторизованных пользователей;

4. Система должна обеспечиватьвозможность добавления новых, изменения существующих, удаление и поиск данных;

5. Система должна производитьжурналирование выполняемых действий;

6. Система должна обеспечиватьодновременную работу нескольких  технологов;

7. Система должна работать смножеством справочных таблиц (~200 шт.).

На этапе предварительного проектирования к системепредъявляются следующие количественные характеристики:

1. количество рабочих мест равно 12,т.к. столько рабочих мест технологов станций;

2. время реакции системы на действияпользователя должно быть как можно меньше.

В проектируемой системе следует предусмотреть наличиенескольких рабочих мест: администратора, технологов.

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

2. Технолог может работать всоответствии с правами, предоставленными ему администратором.

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

 1.3 Технико-экономическое обоснование

Рассмотрим возможные варианты при решении поставленнойзадачи.

Вариант №1 «Новый АРМ – новый модуль работы сосправочниками»

При таком развитии событий получается, что каждыйпрограммист при создании нового АРМа пишет модуль для работы со своимисправочниками. Это приведет к затягиванию внедрения АРМа.

Вариант №2 «Использование DBACCESS»

DBACCESS – программа поставляемая вместе с СУБД Informix,предназначена для написания и выполнения запросов. Использование данного инструментакрайне затруднительно, кроме того, он не обеспечивает проверку корректностиввода данных. При этом неизбежно будут появляться ошибки, которые трудно затембудет отследить.

Вариант №3 «Использование предыдущих разработок»

Использование предыдущих разработок возможно вограниченном объеме, только при работе с некоторыми справочниками. Структурасправочных таблиц меняется, предыдущие АРМы имеют «жесткий» внутренний алгоритми подстройка структуры программы к структуре измененных данных займет многовремени (изменение программы + тестирование). Предыдущие разработкиреализовывались на внутреннем языке СУБД Informix 4GL.Кроме того, при смене СУБД старые разработки пришлось бы переписывать заново.

Вариант №4 «Разработка информационной системы»

Разработка информационной системы позволит:

1. не зависеть от используемой СУБД,т.к. планируемый язык реализации Java (доступ к СУБД через JDBC);

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

3. сократить время других разработок,т.к. проектируемая ИС позволит вводить данные в справочные таблицы для каждогонового АРМа;

4. возможность одновременной работы сИС нескольких пользователей;

Таким образом, разработка ИС является наилучшимвариантом решения поставленной задачи.

/>/>/>/>/>/>/>/>/> 1.4 Анализ технического задания

Проанализируем возможные варианты реализациипредъявленных требований к создаваемой информационной системе.

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

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

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

При вводе данных ИС посылает запросы к серверу БД,который в ответ посылает по сети требуемый блок данных. После получения егосистема выполняет действия, описанные в конфигурационном файле.

Вывод: Дляпостроения ИС расположим БД на выделенном сервере с доступом к нему по сети.Другие способы реализации в данном случае не эффективны.

/>/>/>/>/>/>/>/>/> 1.5 Выбор средств решения выполнения технического задания

Для решения поставленной задачи будет использован СУБДInformix,  т.к. он используется в настоящее время. Выбор СУБД Informix вызван также необходимостью поддержки существующих АРМов, большинствокоторых написаны на PHP, 4GL, ECSQL. Достоинства Informix:

1. Имеет средства обеспеченияцелостности данных.

2. Informix поддерживает язык SQL.

3. Informix позволяет защищать базы данных на уровнепользователей.

4. В Informix’eимеются средства для организации совместного доступа к базе данных и механизмблокировки записей.

MS SQL Server и DB2 имеют такуюже производительность и масштабируемость как и Informix,обеспечивают поддержку крупных баз данных, но в настоящее время используется Informix.

СУБД Informix вполне удовлетворяет требованиям, предъявляемым кпроектируемой системе: защита информации осуществляется на уровне пользователя,возможно использование совместного доступа к данным.

СУБД Informix физически расположен на сервере под управлением ОС Unix.Физический сервер должен оставаться работоспособным при одновременном обращении12 пользователей, т.е. иметь достаточную: вычислительную мощность, количествопамяти и свободного пространства жестком диске достаточного для размещения ОС иБД.

На стороне клиента будет использоваться один из Web-броузеров(Internet Explorer, Netscape, Operaили Mozilla).

В виду перехода, в ближайшее время, на СУБД Oracle8.1.7 выбирается язык реализации Java, доступ к БД будет осуществлятьсячерез JDBC. Применение JDBC позволит, не изменяявнутреннего содержимого программы, легко перейти на другую СУБД путём смены JDBC-драйвера.

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

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

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

В виду большого количества справочников будутрассмотрены лишь некоторые из них. Такая диаграмма приведена на рисунке 2.1.

/>

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

2.1.1 Прецедент «Ввод информации поспециализации путей»

Основной исполнитель: технолог.

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

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

─ Администрация станция. Хочет быстро сформировать поезд и быстро отправитьего по назначению.

─ ГЖД. Хочет быстро перевезти груз и удовлетворить интересыполучателя груза.

─ Налоговые службы. Хотят получать налог от каждой сделки.

Предусловия

Технолог аутентифицирован.

Результаты (постусловия)

Данные сохранены. Технолог занимается другимиобязанностями. Поезд отправлен в нужном направлении. Груз получен. Налоги начислены.

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

1. Технолог выбирает из спискадоступных ему таблиц: таблицу специализации путей;

2. Система читает конфигурационныйфайл, описывающий логику ввода информации;

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

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

5. Выбирает станцию назначениябудущего поезда;

6. Выбирает доминирующее назначениебудущего поезда;

7. Выбирает сопутствующее назначение;

8. Система анализирует выбранныеназначения и выставляет флаг доминирующего назначения в true;

9. Система выбирает из таблицыназначения плана формирования значения:

· Минимальное и максимальноезначение графиковой длины;

· Минимальное и максимальноезначение графикового веса.

10. Технолог проверяет выбранныесистемой значения и подтверждает ввод.

Альтернативные сценарии.

В случае неудачной аутентификации технолога, он долженобратиться к администратору, с просьбой предоставить ему доступ к БД.Реализуется средствами Unix, Web-сервера и СУБД.

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

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

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

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

Точка зрения.Модель строится с точки зренияразработчика данной системы. Основная работа, производимая системой, – «Вводсправочной информации». На вход системы поступают различная информация взависимости от назначения справочника.

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

Последовательность работ отражена на диаграмме (см.Приложение 1) порядком их следования (сверху вниз, слева направо). Технологусначала предлагается выбрать таблицу, которая будет хранить вводимую справочнуюинформацию./>/>/>/>/>

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

Модель данных проектируемой системы разрабатывается сучетом предъявляемых к ней функциональных требований. База данных системысостоит из следующих сущностей: Специализация путей, Станции, Станционные пути,Назначение плана формирования.

Сущность Специализация путей должна содержать:

· Идентификатор;

· Номер пути, на котором будетсформирован поезд;

· Код станции, до которой пойдетпоезд (идентификатор из сущности Станции);

· Доминирующее направление, в какомнаправлении пойдет поезд;

· Сопутствующее направление, черезкакое направление будет проходить поезд;

· Флаг доминирующего направления,выставляется системой в случае совпадения Доминирующего и Сопутствующегонаправления;

· Графиковая длина  мин. и макс.,какой макс. и мин. длины может быть поезд, который пойдет до некоторой станции(заполняется системой из сущности Назначение плана формирования на основаниикода станции);

· Графиковый вес мин. и макс., какоймакс. и мин. вес может быть у поезда (заполняется системой из сущностиНазначение плана формирования на основании кода станции).

Сущность Станции должна содержать:

· Идентификатор;

· ЕСР станции, код станции описанныйв классификации МПС;

· Код дороги, к какой дорогепринадлежит станция;

· Наименование станции, какназывается станция (например, Орехово);

· Краткое наименование станции,сокращение (например, Орх.);

· Код пути, с какого путиотправляется поезд в Орехово (идентификатор из сущности Станционные пути).

Сущность Станционные пути должна содержать:

· Идентификатор;

· Номер пути, числовой номер пути;

· Номер пути, числовой номер путидля АСОУП;

· Условная длина пути;

· Код станции, код станции куда сданного пути отправляется поезд;

Сущность Назначение плана формирования должнасодержать:

· Идентификатор;

· Код станции, станция до которойидет поезд;

· Графиковая длина  мин. и макс.,какой макс. и мин. длины может быть поезд, который придет до данной станции;

· Графиковый вес мин. и макс., какоймакс. и мин. вес может быть у поезда, который придет до данной станции.

В ERWin можно задавать идентифицирующие и неидентифицирующиесвязи

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

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

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

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

Сущность Специализация путей связана с сущностями:Назначение плана формирования, Станции, Станционные пути связью один-ко-многим.

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

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

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

/>

 В качестве управления выступает Выбор, а вкачестве механизма Технолог и Система.

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

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

/>

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

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

На вход работе Анализ введённой информации,поступают: Код станции, Код доминирующего направления, Кодсопутствующего направления. Здесь происходит сравнение кодов назначений иустановка Флага доминирования.

/>

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

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

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

Реализация системы предполагается на языке 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 II400 или выше.

Память: 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 Внутренние логические файлы 4 * 7 = 28 0 * 10 = 0 0 * 15 =0 28 Внешние интерфейсные файлы 0 * 5 = 0 0 * 7 = 0 0 * 10 = 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 Общее количество FP 32

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

FP = 3 * 36 + 2 * 32 = 172

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

FP = Общее_количество * (0,65+0,01 * å14i=1Fi), (5.1)

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

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

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

Каждый коэффициент можетпринимать следующие значения: 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.