Быстрый поиск

Дипломная работа: Автоматизированная система управления документооборотом центральной заводской лаборатории. Подсистема регистрации и сопровождения заказов на испытания

Автоматизированная система управления документооборотом ЦЗЛ. Подсистема регистрации и сопровождения заказов на испытания.

Введение

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

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

Одна из областей применения компьютеров – это автоматизация процессов производства. В настоящее время все большее значение имеет ускоренное решение некоторых видов задач, что приводит к экономии ресурсов и времени. Автоматизированная система управления документооборотом ЦЗЛ решает именно эти две задачи.

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

1. Общая часть

1.1 Цель разработки

В данном дипломном проекте поставлена следующая задача: спроектировать и реализовать автоматизированную систему управления документооборотом центральной заводской лаборатории ОАО «ВМЗ». Техническое задание на проектирование необходимо разрабатывать на основании анализа текущей системы документооборота, сопровождающей процесс проведения испытаний в лабораториях ЦЗЛ.

1.1.1 Анализ использования разработки

Система предназначена для автоматизации процесса формирования и обработки заказов на испытание образцов продукции основных цехов ОАО «ВМЗ», а также записи и хранения их в электронном виде.

Объектом автоматизации является документооборот процесса подготовки, изготовления и испытания образцов продукции основных цехов ОАО «ВМЗ».

Автоматизированная система управления документооборотом ЦЗЛ ОАО «ВМЗ» (именуемая далее Система) разрабатывается для:

- формализации процесса формирования заказов на испытание образцов с единой системой нумерации;

- централизованного электронного учёта заказов на испытание образцов и результатов испытаний;

- практически полного упразднения бумажных журналов и протоколов,

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

- повышения оперативности поступления заказов и формирования протоколов и сертификатов на базе единой интегрированной автоматизированной системой оперативного управления производством (ИАСОУП) ОАО «ВМЗ».

Разрабатываемый программный продукт должен строиться по клиент-серверной архитектуре.

Серверная часть системы должна быть общей с интегрированной автоматизированной системой оперативного управления производством (ИАСОУП) и использовать в качестве хранилища данных единую базу данных (БД) в системе управления базами данных (СУБД) Oracle.

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

1.1.2 Характеристика объекта информатизации

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

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

Пробы сдаются сменному мастеру участка изготовления образцов. Сменный мастер регистрирует заказ в «журнале приёма проб». Объём и виды необходимых испытаний указываются цехом в заказе. Может указываться ссылка на научно-техническую документацию, в которой указано, какие образцы и каким образом необходимо изготавливать и / или непосредственно указываются виды и количество испытаний.

После изготовления образцов на участке изготовления производится регистрация в том же «журнале приёма проб» даты и времени сдачи и ответственного лица.

Заказ (ранее доставленный на участок изготовления образцов) вместе с образцами передаётся в одну из лабораторий.

В лабораториях заказ регистрируется в «журнале приёма образцов» в лаборатории механических испытаний (ЛМИ), журнале «Сталь. Результаты испытаний (трубные цеха)» в объединенной аналитической лаборатории (ОАЛ) и в аналогичных журналах в других лабораториях. Заказ, как документ, хранится в лаборатории в течение 5 лет.

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

Кроме журналов, результаты испытаний фиксируются в протоколе. Протокол оформляется в 2‑х экземплярах: один хранится в ЛМИ, второй – направляется в отдел технического контроля (ОТК) цеха.

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

1.2 Анализ методов решения

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

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

 Бизнес-компонента содержит логику, которая реализует манипуляции с выбранными данными по определенным правилам, т.е. бизнес-компонента – это обработка.

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

1.2.1 Однозвенные приложения

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

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

1.2.2 Двухзвенные приложения

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

Открытые системы создавались для того, чтобы выйти из ограниченности и закрытости персонального решения и получить доступ к внешним источникам информации. В клиент-серверной архитектуре пользователи получили доступ к реляционным данным, могут сгенерировать свои собственные отчеты и манипулировать выборками при помощи персональных электронных таблиц и инструментов анализа данных на своих персональных компьютерах. Двухзвенная клиент-серверная архитектура разделяет приложение на две части: вычисление настольным компьютером и хранение данных сервером. Теперь клиентская машина в общем случае может быть с любой операционной системой, от DOS до UNIX, серверная часть также может варьироваться от аппаратуры, возможно даже меньшей вычислительной мощности по сравнению с персональным компьютером пользователя до многопроцессорных кластеров или мэйнфреймов.

Граница между клиентом и сервером в таких системах проводится в произвольном месте и большей частью зависит от используемых инструментов. В наиболее популярных и распространенных клиент-серверных системах в качестве клиентской рабочей станции применяется Windows‑компьютер, а в качестве сервера – SQL сервер на основе Windows или UNIX. Инструментарий, при помощи которого создаются такие системы, позволяет разработчикам разрабатывать логику клиента и осуществлять простейшие запросные операции серверу. Такой тип клиент-серверной
архитектуры называют архитектурой с толстым клиентом, поскольку большая часть приложения, включая презентационную логику, бизнес-логику и логику доступа к данным, выполняется на персональном сетевом компьютере.

Двухзвенный клиент-серверный подход предоставляет значительные преимущества по сравнению с однозвенным подходом – проектирование происходит заметно быстрее, а сервер может быть довольно простым, поскольку большая часть сложной обработки возлагается на клиента. Следствием из этого является заметное удешевление системы, особенно серверной ее части. Появляется возможность не зависеть от платформы сервера, поскольку все базы данных от одного поставщика предоставляют одинаковый интерфейс независимо от платформы сервера. А такие интерфейсы, как ODBC (Microsoft) или IDAPI (Borland-Inprise) позволяют добиться и независимости от производителя БД.

Также двухзвенный подход обладает и недостатками. Это проблемы с безопасностью данных, проблемы с надежностью и управляемостью информационной системы, чрезмерные расходы при модификации и обслуживании информационной системы. Двухзвенная архитектура работает прекрасно, если имеется только одна реляционная БД, а клиентские приложения совершают четко определенные простые действия с данными. Hо по мере возрастания сложности системы – когда количество источников данных и количество пользователей возрастает – двухзвенная клиент-серверная система очень быстро исчерпывает возможности по развитию. Без жесткого контроля по безопасности, который могла бы предоставить только централизованная система, такой контроль должен возлагаться на каждое клиентское приложение в отдельности. По мере возрастания сложности клиентского приложения увеличивается и его размер, а, следовательно, и затраты.

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

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

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

Каждый производитель SQL-сервера поддерживает свой собственный протокол для обращения к данным, поэтому разработчику приходится каждый раз заново решать проблему установления соединения, синхронизации данных, безопасности и множество других мелких и неприятных технических проблем.

Клиентские приложения становятся все более сложными и все менее управляемыми. Это общая тенденция для двухзвенного клиент-серверного подхода.

Двухзвенная клиент-серверная архитектура – это архитектура, существенно зависящая от применяемых программных инструментов.

Возможности масштабирования и развития системы существенно ограничены. Двухзвенная архитектура позволяет весьма производительным способом использовать RAD-инструменты, однако стоимость масштабируемости, администрирования, развития такой архитектуры непомерно высока. И при всем при этом такая архитектура принципиально ограничивает доступ ко всем корпоративным данным и возможности интеграции всех систем в единое целое, поддержку одновременно и новых и прежних технологий.

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

1.2.3 Трехзвенные приложения

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

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

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

1.2.3.1 Модули и объекты

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

Страницы: 1, 2, 3, 4, 5, 6