Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
2
Содержание:
Введение
1. Разработка и анализ технического задания.
2. Разработка модели процессов объекта профессиональной деятельности.
5. Расчеты и оценки.
Заключение
Список использованной литературы
Цель выполнения данного реферата является создание и модернизация автоматизированного рабочего места (АРМ) технолога.
Создаваемая информационная система будет не первой подобной разработкой, но в отличие от предыдущих систем, которые были написаны под конкретную БД с «жестким» внутренним алгоритмом, будет являться гибкой, легко настраиваемой и не зависимой от СУБД.
1. Разработка и анализ технического задания.
В рамках курсового проекта необходимо на основе СУБД разработать программу для автоматизации рабочего места технолога станции с применением Web-технологии.
При создании необходимо разработать специальный алгоритм ввода поступающей информации, предусмотреть защиту от интерактивных ошибок пользователя. Количество связанных между собой справочников (таблиц) превышает 200 штук.
На железнодорожном транспорте ведутся разработки и внедрение АРМ работников массовых профессий, связанных с управлением информационным обеспечением перевозочного процесса.
Создание АРМ предусматривает повышение уровня использование пропускной способности, повышение производительности труда, улучшение условий труда.
Железнодорожные линии делятся на участки, а участки на перегоны. Границами смежных перегонов служат раздельные пункты: станции, разъезды, обгонные пункты. Границы участков –участковые или сортировочные станции.
Станцией называется раздельный пункт, имеющий путевое развитие, позволяющее производить операции по приёму, отправлению, скрещиванию и обгону поездов. На станциях размещены технические устройства, обеспечивающие пропускную и провозную способность железнодорожных линий: сооружения и устройства станционного хозяйства, локомотивные и вагонные депо, пункты технического обслуживания вагонов и т.д. От работы станции в значительной степени зависят: обеспечение выполнения плана перевозок пассажиров и груза; отправление поездов по графику и в соответствии с планом формирования поездов –полными по массе и длине, исправными в техническом и коммерческом отношении; безопасность движения поездов, их приёма, отправления, скрещивания, обгона и манёвров; регулярность, своевременность и сохранность доставки грузов; снижение себестоимости перевозок; выполнение комплексного показателя работы железных дорог –оборота вагона (за время своего оборота вагон находится в движении только 30% времени, а 70% –на станции).
Железнодорожные станции классифицируются по ряду признаков. По назначению и характеру работы они подразделяются на промежуточные, участковые сортировочные, грузовые, пассажирские и технические пассажирские. Так, например, на грузовых станциях производят приём, хранение, выдачу, погрузку и взвешивание грузов, а также расформирование и формирование отправительских маршрутов и передач. Грузовые операции выполняются на местах общего пользования и на подъездных путях предприятий.
Пути и стрелочные переводы –важнейшие технические устройства на станциях, предназначенных для перемещения поездов и маневровых составов. Путевое развитие включает пути главные, приёмоотправочные, сортировочные, вытяжные, погрузочно-разгрузочные, деповские, специального назначения.
Сортировочные пути - предназначены для сортировки вагонов по назначениям следования, накопления из них поездных составов или прицепочных групп вагонов согласно плану формирования.
На вытяжных путях - выполняют операции с составами поездов или группами вагонов, при которых их переставляют с приемоотправочных, погрузочно-разгрузочных или сортировочных путей для последующей сортировки по назначениям или подачи на другие пути.
У каждого станционного пути различают полную и полезную длину. Полная длина представляет собой расстояние между стыками рамных рельсов стрелочных переводов, ограничивающих данный путь (сквозной). Полезная длина –часть полной длины, в пределах которой можно устанавливать подвижной состав при безусловном обеспечении безопасности движения вагонов и локомотивов по соседним путям.
Необходимо разработать информационную систему по обработке справочной информации. К проектируемой системе предъявляются следующие функциональные требования:
На этапе предварительного проектирования к системе предъявляются следующие количественные характеристики:
В проектируемой системе следует предусмотреть наличие нескольких рабочих мест: администратора, технологов.
Рассмотрим возможные варианты при решении поставленной задачи.
Вариант №1 «Новый АРМ –новый модуль работы со справочниками»
При таком развитии событий получается, что каждый программист при создании нового АРМа пишет модуль для работы со своими справочниками. Это приведет к затягиванию внедрения АРМа.
Вариант №2 «Использование DBACCESS»
DBACCESS –программа поставляемая вместе с СУБД Informix, предназначена для написания и выполнения запросов. Использование данного инструмента крайне затруднительно, кроме того, он не обеспечивает проверку корректности ввода данных. При этом неизбежно будут появляться ошибки, которые трудно затем будет отследить.
Вариант №3 «Использование предыдущих разработок»
Использование предыдущих разработок возможно в ограниченном объеме, только при работе с некоторыми справочниками. Структура справочных таблиц меняется, предыдущие АРМы имеют «жесткий» внутренний алгоритм и подстройка структуры программы к структуре измененных данных займет много времени (изменение программы + тестирование). Предыдущие разработки реализовывались на внутреннем языке СУБД Informix 4GL. Кроме того, при смене СУБД старые разработки пришлось бы переписывать заново.
Вариант №4 «Разработка информационной системы»
Разработка информационной системы позволит:
Таким образом, разработка ИС является наилучшим вариантом решения поставленной задачи.
Проанализируем возможные варианты реализации предъявленных требований к создаваемой информационной системе.
Исходя из функциональных требований, система, предполагает наличие нескольких рабочих мест с разными правами доступа к информации, но использующих одни и те же данные, то целесообразно базу данных расположить на сервере и обеспечить совместный доступ к данным по локальной сети.
Каждому пользователю в соответствии с занимаемой должностью должны быть назначены права на доступ к базе данных. Для идентификации пользователей, у каждого должны быть собственное уникальное имя и пароль. Возможно (при наличии нескольких человек, обладающих одними и теми же правами или занимающими одинаковые должности) объединить несколько пользователей в группы и назначить права группам.
Необходимо разработать удобный интерфейс, позволяющий, по возможности, минимизировать ошибки пользователей при работе (предусмотреть маски ввода, контроль введенных значений и т.п.), т.к. ошибки могут отрицательно сказаться на финансовом положении организации, использующей данную систему.
При вводе данных ИС посылает запросы к серверу БД, который в ответ посылает по сети требуемый блок данных. После получения его система выполняет действия, описанные в конфигурационном файле.
Вывод: Для построения ИС расположим БД на выделенном сервере с доступом к нему по сети. Другие способы реализации в данном случае не эффективны.
Для решения поставленной задачи будет использован СУБД Informix, т.к. он используется в настоящее время. Выбор СУБД Informix вызван также необходимостью поддержки существующих АРМов, большинство которых написаны на PHP, 4GL, ECSQL. Достоинства Informix:
MS SQL Server и DB2 имеют такую же производительность и масштабируемость как и Informix, обеспечивают поддержку крупных баз данных, но в настоящее время используется Informix.
СУБД Informix вполне удовлетворяет требованиям, предъявляемым к проектируемой системе: защита информации осуществляется на уровне пользователя, возможно использование совместного доступа к данным.
СУБД Informix физически расположен на сервере под управлением ОС Unix. Физический сервер должен оставаться работоспособным при одновременном обращении 12 пользователей, т.е. иметь достаточную: вычислительную мощность, количество памяти и свободного пространства жестком диске достаточного для размещения ОС и БД.
На стороне клиента будет использоваться один из Web-броузеров (Internet Explorer, Netscape, Opera или Mozilla).
В виду перехода, в ближайшее время, на СУБД Oracle 8.1.7 выбирается язык реализации Java, доступ к БД будет осуществляться через JDBC. Применение JDBC позволит, не изменяя внутреннего содержимого программы, легко перейти на другую СУБД путём смены JDBC-драйвера.
2. Разработка модели процессов объекта профессиональной деятельности.
Требования, предъявляемые к функционированию проектируемой системы, удобно выразить с помощью языка прецедентов. Прецедент –это набор сценариев, в котором каждый экземпляр сценария представляет собой последовательность действий, выполняемых системой или актером для достижения результата. Таким образом, с помощью прецедентов на понятном и доступном языке можно описать основные процессы, происходящие в системе и значения этих процессов для актера (пользователя системы).
В виду большого количества справочников будут рассмотрены лишь некоторые из них. Такая диаграмма приведена на рисунке 2.1.
Рисунок 2.1 –Диаграмма прецедентов использования системы
Основной исполнитель: технолог.
Заинтересованные лица и их требования
Предусловия
Технолог аутентифицирован.
Результаты (постусловия)
Данные сохранены. Технолог занимается другими обязанностями. Поезд отправлен в нужном направлении. Груз получен. Налоги начислены.
Основной (успешный) сценарий
Альтернативные сценарии.
В случае неудачной аутентификации технолога, он должен обратиться к администратору, с просьбой предоставить ему доступ к БД. Реализуется средствами Unix, Web-сервера и СУБД.
На основе модели прецедентов построим модель процессов в методологии IDEF0. Модель IDEF0 представляет собой совокупность работ, преобразующих входы в выходы с использованием механизмов и управления. Модели процессов помогают понять особенности функционирования системы и взаимодействия с внешней средой. Для определения контекста модели процессов необходимо задать область моделирования, цель моделирования и точку зрения. В качестве примера построим модель для процесса ввода информации в справочник «Специализация путей».
Область моделирования. К внешней среде отнесем администратора и технолога. Технолог или администратор взаимодействует с системой посредством пользовательского интерфейса. При моделировании процессов интерес будут представлять отклики системы на действия оператора при введении информации о справочниках и в справочники.
Цель моделирования дать четкое и однозначное понимание процесса функционирования системы при вводе информации о справочниках и в справочники. Наиболее полно определить назначение каждой работы, производимой системой.
Точка зрения. Модель строится с точки зрения разработчика данной системы. Основная работа, производимая системой, –«Ввод справочной информации». На вход системы поступают различная информация в зависимости от назначения справочника.
На вход системе поступает информация об исходных данных и имени таблицы, куда собираемся вводить справочную информацию. Все эти элементы будут преобразованы или использованы данной работой в качестве «входных данных». В качестве управления выступает действия технолога. Механизм, без которого невозможно управление системой представлен технологом.
Последовательность работ отражена на диаграмме (см. Приложение 1) порядком их следования (сверху вниз, слева направо). Технологу сначала предлагается выбрать таблицу, которая будет хранить вводимую справочную информацию.
Модель данных проектируемой системы разрабатывается с учетом предъявляемых к ней функциональных требований. База данных системы состоит из следующих сущностей: Специализация путей, Станции, Станционные пути, Назначение плана формирования.
Сущность Специализация путей должна содержать:
Сущность Станции должна содержать:
Сущность Станционные пути должна содержать:
Сущность Назначение плана формирования должна содержать:
В ERWin можно задавать идентифицирующие и неидентифицирующие связи
Идентифицирующей связью называется связь, которая добавляет признаки идентичности в дочернюю сущность путем миграции ключей родительской сущности в область ключевых атрибутов дочерней и таким образом делая дочернюю сущность зависимой от родительской в смысле своей идентичности.
Можно задать также и такую связь, которая не ставит дочернюю сущность в зависимость от родительской. Этот тип связи называется неидентифицирующей связью. В ERwin такая связь обозначается пунктирной линией с жирной точкой на конце, соответствующем дочерней связи. При неидентифицирующей связи атрибуты первичного ключа родительской сущности мигрируют в область данных (неключевая область), которая расположена под чертой в дочерней сущности. В данной работе неидентифицирующая связь не используется (см. Приложение 2).
При проектировании информационной системы необходимо указать разработчику какие действия, над какими данными может выполнять конкретная работа. Для этого используется связь модели данных, построенной в ERWin и модели процессов, построенной в BPWin. Проследим процесс преобразования данных при вводе данных в сущность «Специализация путей».
Работа системы начинается с загрузки файла конфигурации. При этом происходит чтение и отображения содержимого сущности «Специализация путей», а также подготовка формы для ввода исходных данных. После этого Исходные данные и Готовая форма для ввода поступают в качестве входных данных в работу Ввод исх. данных.
В качестве управления выступает Выбор, а в качестве механизма Технолог и Система.
Работа Выбор пути формирования поезда заключается в выборе пути, на котором будет сформирован состав (исходя из исходных данных).
После выбора пути формирования номер пути поступает в качестве входных данных на работу Выбор станции назначения будущего поезда, где выбирается, до какой станции идет сформированный поезд.
Результат выбора технолога в предыдущей работе передаётся на вход Выбор доминирующего назначения поезда. Здесь выбирается, в каком основном направлении будет следовать поезд.
В работе Выбор сопутствующего назначения поезда будет выбираться на основании Кода доминирующего направления, т.е. через какие дороги, станции будет следовать поезд.
На вход работе Анализ введённой информации, поступают: Код станции, Код доминирующего направления, Код сопутствующего направления. Здесь происходит сравнение кодов назначений и установка Флага доминирования.
На основании предыдущих результатов и кода станции система выбирает из сущности «Назначения плана формирования» максимальное и минимальное значение графиковой длины и на основании только Кода станции выбирается максимальное и минимальное значение графикового веса.
5. Расчеты и оценки.
Реализация системы предполагается на языке 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 и СУБД предполагается осуществлять через сеть. Два жестких диска необходимы для того, чтобы отделить операционную систему от баз данных. Необходимо для облегчения перестановки ОС. Большой объем жесткого диска для БД связан с необходимостью хранить резервные копии всех БД, а также ежедневные копии БД для быстрого восстановления в случае сбоя.
Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассматривается не размер, а функциональность или полезность продукта. Для примера рассчитаем функциональность одной из пользовательских форм, которая будет использована в конечном продукте.
При расчетах по функционально-ориентированной метрике используется 5 информационных характеристик:
. Количество внешних вводов: 1 (кнопка OK); данный элемент ввода состоит из 7 элементов данных (1 поле ввода, 5 полей со списком, 1 командная кнопка).
. Количество внешних выводов: 1 (сообщение уведомления); элемент вывода состоит из 1 элемента данных (командная кнопка).
. Количество внешних запросов: 0.
. Количество внутренних логических файлов: 4 (справочник ДоминирующееНаправление, справочник сопутствующееНаправление, таблица Станции, таблица Пути); таблица Станции состоит из 6 элементов данных, справочник ДоминирующееНаправление, справочник сопутствующееНаправление и таблица Станции –из 3.
. Количество внешних интерфейсных файлов: 0.
Далее, для каждой информационной характеристики по известным таблицам определяются ранг и оценка сложности.
После сбора всей необходимой информации подсчитаем общую функциональную метрику (таблица 5.2).
Таблица 5.2
|
Н |
С |
В |
Итого |
|
|
Внешние вводы |
* 3 = 0 |
* 4 = 4 |
* 6 = 0 |
|
|
Внешние выводы |
* 4 = 4 |
* 5 = 0 |
* 7 = 0 |
|
|
Внешние запросы |
* 3 = 0 |
* 4 = 0 |
* 6 = 0 |
|
|
Внутренние логические файлы |
4 * 7 = 28 |
* 10 = 0 |
* 15 =0 |
28 |
|
Внешние интерфейсные файлы |
* 5 = 0 |
* 7 = 0 |
* 10 = 0 |
|
|
Общее количество FP |
6 |
Аналогичным образом рассчитаем функциональность второго типа пользовательской формы (рисунок 5.2). Результаты расчета в таблице 5.2.
Таблица 5.2
|
Н |
С |
В |
Итого |
|
|
Внешние вводы |
* 3 = 0 |
* 4 = 4 |
* 6 = 0 |
|
|
Внешние выводы |
* 4 = 4 |
* 5 = 0 |
* 7 = 7 |
|
|
Внешние запросы |
* 3 = 3 |
* 4 = 0 |
* 6 = 0 |
|
|
Внутренние логические файлы |
* 7 = 14 |
* 10 = 0 |
* 15 =0 |
|
|
Внешние интерфейсные файлы |
* 5 = 0 |
* 7 = 0 |
* 10 = 0 |
|
|
Общее количество FP |
С учетом того, что в проекте предполагается использование 3 пользовательских форм первого типа и 2 пользовательских форм второго типа, подсчитаем общую функциональную метрику для всего проекта:
FP = 3 * 36 + 2 * 32 = 172
Полученную общую метрику необходимо субъективным образом взвесить, используя следующую формулу:
FP = Общее_количество * (0,65+ 0,01 * 14i=1Fi), (5.1)
где Fi –коэффициенты регулировки сложности.
Таблица 5.3 –Определение системных параметров приложения
|
№ |
Системный параметр |
Описание |
Коэф. |
|
1 |
Передача данных |
Сколько средств связи требуется для передачи илиобмена информацией с приложением или системой? |
|
|
2 |
Распределенная обработка данных |
Как обрабатываются распределенные данные и функции обработки? |
|
|
3 |
Производительность |
Нуждается ли пользователь в фиксации времени ответа или производительности? |
|
|
4 |
Распространенность используемой конфигурации |
Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение? |
|
|
5 |
Скорость транзакций |
Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц) |
|
|
6 |
Оперативный ввод данных |
Какой процент информации надо вводить в режиме онлайн? |
|
|
7 |
Эффективность работы конечного пользователя |
Приложение проектировалось для обеспечения эффективной работы конечного пользователя? |
|
|
8 |
Оперативное обновление |
Как много внутренних файлов обновляется в онлайновой транзакции? |
|
|
9 |
Сложность обработки |
Выполняет ли приложение интенсивную логическую или математическую обработку? |
|
|
10 |
Повторная используемость |
Приложение разрабатывалось для удовлетворения требований одного или многих пользователей? |
|
|
11 |
Легкость инсталляции |
Насколько трудны преобразование и инсталляция приложения? |
|
|
12 |
Легкость эксплуатации |
Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления? |
|
|
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. Информатика. Базовый курс /Симонович С.В. и др. - СПб: Издательство «Питер», 2000.
2. Землянский А.А. Информационные технологии в экономике. - М.: Колос, 2004.
. Информатика для юристов и экономистов./ Под ред. С.В. Симоновича. - СПб.: Питер, 2004.
. Информатика и математика для юристов/Под ред. проф. Х.А. Андриашина, проф. С.Я. Казанцева. - М.: ЮНИТИ-ДАНА, Закон и право, 2003.
. Ляхович В.Ф. Основы информатики. - Р н/Д: Изд-во «Феникс», 2000.
. Симонович С.В., Евсеев Г.А и др. Общая информатика. - М.: АСТ-ПРЕСС, Инфорком - Прес, 2001.
. Степанова Е.Е., Хмелевская Н.В. Информационное обеспечение управленческой деятельности. - М.: Форум-Инфра-М, 2004
. Шафрин Ю.А. Информационные технологии: в 2 частях. Ч.1, 2:. - М.: Лаборатория базовых знаний, 2001 г.
. Экономическая информатика: Учебник / Под ред. В.П. Косарева и Л.В. Еремина. - М.: Финансы и статистика, 2001.