Разработка автоматизированной системы учета движения ремонтируемой электроаппаратуры

АННОТАЦИЯ

Дипломный проект на тему «Разработка автоматизированной системы учета движения ремонтируемой электроаппаратуры» выполнялся по заказу ОАСУП ОАО СПО «Арктика».

Введение

содержит общие сведения о дипломном проекте, актуальность выбранной темы.

Постановка задачи включает в себя формулировку задания на дипломное проектирование.

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

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

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

Заключение

содержит окончательные выводы по результатам выполненного проекта.

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

Приложение содержит исходный код программы.

Графические материалы выполнены в форме презентации.

ВВЕДЕНИЕ

Целью данного дипломного проекта является: разработка автоматизированной системы учёта движения ремонтируемых электроприборов Открытого Акционерного Общества Северного Производственного Объединения «Арктика» (ОАО СПО «Арктика»), которая предназначена для введения новой технологии учета наличия и движения ремонтируемых электроприборов.

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

.В настоящее время для реализации данной задачи используется система АСУ РЭА, к возможностям которой относятся:

· учет накладных;

· отслеживание перемещений ремонтируемых приборов;

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

Главным недостатком существующей системы обработки информации в ОАО СПО «Арктика» — автоматизация учета только для одного конкретного заказа. Также данной системой не предусмотрено формирования ряда выходных документов. Много усилий затрачивается на получение справочной информации о характеристиках, степени готовности и нахождении ремонтируемых приборов, так как эти данные регистрируются в различных журналах, на составление отчетности, и при этом зачастую возникают ошибки, что приводит к непроизводительным затратам времени. Эффективность работы специалистов ОАО СПО «Арктика» часто зависит от правильности и своевременности полученной информации. Поэтому в целях повышения качества и оперативности обработки информации и экономии рабочего времени, было принято решение о создании единой информационной системы по ведению учета движения ремонтируемых приборов в подразделениях ОАО СПО «Арктика», осуществляющих ремонт и восстановление электроприборов.

Внедрение автоматизированной информационной системы учёта движения ремонтируемой электроаппаратуры в ОАО «СПО «Арктика» даст возможность решить следующие задачи:

· оперативное получение разного рода сведений о характеристиках и степени готовности ремонтируемых электроприборов;

· формирование, просмотр и редактирование накладных;

· формирование отчётности;

· ведение различной нормативно-справочной информации;

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

Решение данного комплекса задач позволит:

· избежать дублирования информации в различных учётных картотеках и журналах;

· ускорить обработку информации за счёт исключения её разрозненности;

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

· принятия своевременных управленческих решений на основе данных аналитических отчетов.

Учет электроприборов, имеющие гриф «Секретно» и «Совершенно секретно» введется по отдельным нормативным документам и данной системой не осуществляется.

В данном дипломном проекте представлены:

· Разработка проекта информационной системы учета средств измерений на базе современных CASEтехнологий, в данном случае — BPwin 4.0 и ERwin 4.0.

· Реализация данной задачи в СУБД Oracle.

· Разработка макета приложения в среде Borland Delphi 7.

1. ПОСТАНОВКА ЗАДАЧИ

1.1 Характеристика комплекса задач

Разработать автоматизированную систему (АС) учета движения ремонтируемых приборов договора, для: повышения скорости обработки информации; контроля своевременного выполнения работ; создания печатных форм отчётов.

1.2 Функции автоматизированной системы

Автоматизированная система управления планированием работ должна решать следующие задачи и отвечать следующим требованиям:

— обеспечить хранение данных на сервере СУБД «Oracle»;

— обеспечивать эффективность и быстроту поиска;

— предоставление различных видов отчетов в печатной форме;

— удобный пользовательский интерфейс.

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

1.3 Выходные и входные данные

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

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

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

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

Входная документация содержит первичную, не обработанную информацию, отражающую состояние объекта управления. Заполняется вручную, либо при помощи технических средств.

Документы можно классифицировать по ряду признаков:

По сфере деятельности — плановые, учетные, статистические, банковские, финансовые;

По отношению объекта управления — входящие (первичные), исходящие (сводные), промежуточные, архивные;

По содержанию хозяйственных операции — материальные, денежные, расчетные;

По способу использования — разовые и накопительные;

По способу заполнения — вручную или при помощи автоматизации.

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

Входная информация:

· номенклатура изделий и приборов, ремонтируемых ОАО СПО «Арктика»;

· сдаточная накладная.

Выходная информация:

· журнал учета накладных;

· отчеты;

· сдаточная накладная.

1.4 Требования к программному и техническому обеспечению АС

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

В качестве технических средств автоматизированной системы выступают:

1) сервер БД;

2) клиентские машины — компьютеры, присоединенные к локальной сети предприятия

3) Операционная система — MS Windows 2000 и выше;

2. АНАЛИТИЧЕСКАЯ ЧАСТЬ

2.1 Организационная структура предприятия

Федеральное Государственное Унитарное Предприятие «Северное Производственное Объединение «Арктика» вместе с крупнейшими российскими верфями ПО «Севмаш» и МП «Звездочка» входит в Государственный Российский Центр Атомного Судостроения (ГРЦАС), который базируется в городе Северодвинске Архангельской области.

СПО «Арктика» — многопрофильное производство с современной приборно-технологической базой, системой качества, сертифицированной в соответствии с международным стандартом, лицензиями и сертификатами на все виды выполняемых работ, высококвалифицированным персоналом. ФГУП «СПО «Арктика» располагая тремя видами производств: электромонтажное, электромеханическое и ремонтное совместно с судозаводами успешно решает поставленные задачи по строительству и ремонту судов и кораблей. Мощности электромеханического производства позволяют обеспечить комплектующим оборудованием не только военные заказы, но и удовлетворить потребности гражданских заказчиков.

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

Структура инженерных служб СПО «Арктики» включает проектно-конструкторское отдел (ПКО), Отдел Главного Технолога (ОГТ), Отдел Главного Метролога (ОГМетр), центральную заводскую лабораторию (ЦЗЛ), а также отделы автоматизированной системы управления, энергетики и другие подразделения, осуществляющих технологическую и организационную поддержку производства. Совместно с ведущими отечественными научно-исследовательскими и проектными организациями специалисты предприятия выпускают рабочую и технологическую документацию с учетом требований отечественных и зарубежных стандартов и нормативов.

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

СПО «Арктика», обладая высококвалифицированным персоналом и оснащенное современной компьютерной техникой, оборудованием, испытательными стендами, приборами по самой передовой технологии:

· выполняет электромонтажные работы на судах и кораблях военного и гражданского назначения; на морских ледостойких буровых платформах для добычи нефти и газа на месторождениях шельфа северных морей; на объектах нефтегазовых месторождений;

· разрабатывает и производит монтаж уникальных по конструкции и сложности волоконно-оптических кабельных судовых линий;

· производит регулировку, сервисное обслуживание и ремонт сложнейших систем: радиосвязи, радиолокации и радиоразведки, телевидения, навигации, гидроакустики и гидролокации, вычислительной техники, автоматики управления торпедным и ракетным оружием, корабельных механизмов защиты и управления ядерными реакторами;

· выполняет любые операции среднего ремонта электродвигателей, генераторов, преобразователей, распределительных устройств, станций управления и других видов электроаппаратов;

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

2.2 Организация предметной области

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

Учёт ремонтируемых электроприборов для нужд предприятия функционально связан со следующими подразделениями предприятия, осуществляющими ремонтно-восстановительные:

— Электромеханический отдел (ЭМО);

— Отдел выдачи и комплектации (ОВК);

— Цех 3;

— Цех 4;

— Цех 5;

— Цех 6;

— Цех 8.

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

2.2.1 Должностные обязанности кладовщика:

— Прием на склад и выдача со склада подразделениям предприятия приборов, проходящих ремонт.

— Проверка соответствия принимаемых приборов сопроводительным документам.

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

— Организация хранения поступивших приборов с целью предотвращения их порчи или утери.

— Оформление сдаточных накладных и материальных пропусков.

— Участие в инвентаризации подотчетных материальных ценностей.

— Учет находящихся на складе материальных ценностей и ведение отчетной документации по их движению.

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

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

2.2 Описание бизнес-процессов

После изучения и анализа предметной области были смоделированы бизнес-процессы с применением CASEсредства BPwin 4.0 Computer Associates.

После подписания договора на выполнение ремонтно-восстановительных работ, работниками цеха № 4 ОАО СПО «Арктика» и цеха № 16 ОАО «Звездочка» производится демонтаж приборов, входящих в номенклатуру изделий, ремонтируемых ОАО СПО «Арктика». Демонтированные приборы поступают на склады подразделений, ответственных за их ремонт. Передача приборов происходит по сдаточной накладной, оформляемой лицом, ответственным за демонтаж приборов. В накладной указывается: от какого и в какое подразделение поступают приборы, наименование изделия, номер схемы, наименование приборов, их количество, дата оформления, а так же росписи лиц, осуществляющих передачу и приемку приборов. В соответствии со сдаточной накладной, кладовщик осуществляет проверку наличия поступивших приборов и регистрирует накладную в журнале учета накладных. Поступившие приборы помещаются на склад подразделения, после чего работники, производящие ремонт изделия, к которому принадлежат приборы, производят их внешний осмотр, с целью установления комплектности изделия, а так же обнаружения физических повреждений. По результатам осмотра составляется «Акт внешнего осмотра» в котором указываются выявленные дефекты. Акт подписывается представителями подразделений, осуществляющими демонтаж и ремонт, представителями личного состава ремонтируемого заказа и главным строителем заказа.

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

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

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

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

После выполнения ремонтных работ производится приемка отремонтированных приборов службой контроля качества. Приемка производится на основании ГОСТ, ТУ и нормативных документов предприятия, регламентирующих порядок приемки отремонтированных приборов. В случае соответствия приборов нормам, сотрудник ОТК производит запись в журнал приемки изделий и вызывает представителя военной приемки, который и осуществляет окончательную приемку приборов по тем же документам. В случае обнаружения неустраненных дефектов или несоответствия приборов нормам, осуществляется возврат приборов в ремонт для устранения выявленных недостатков.

После приемки ремонта приборов представителем заказчика, отремонтированные приборы помещаются на склад подразделения, где хранятся до начала монтажных работ.

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

В результате анализа предметной области была разработана функциональная модель процесса учета движения ремонтируемой электроаппаратуры в соответствии с нотацией IDEF0 в инструментальной среде BPWin, приведенная на рисунках 2.1 -2.3.

Рис. 2.1. Функциональная модель «Учет движения ремонтируемых приборов».

Данная контекстная диаграмма разбивается на декомпозиционные диаграммы — «Регистрация в журнале учета», «Ремонт и предъявление приборов заказчику», «Оформление накладной и регистрация в журнале учета», которые приведены на рисунке 2.2.

Рис. 2.2. Декомпозированная функциональная модель «Учет движения ремонтируемых приборов».

Далее производится декомпозиция «Регистрация в журнале учета». Результат представлен на рисунке 2.3.

Рис. 2.3. Декомпозированная функциональная модель «Регистрация в журнале учета».

Далее производится декомпозиция «Ремонт и предъявление приборов заказчику». Результат представлен на рисунке 2.4.

Рис. 2.3. Декомпозированная функциональная модель «Регистрация в журнале учета».

2.4 Обзор существующих аналогов

На данный момент в АСУП ОАО СПО «Арктика» функционирует Автоматизированная Система Учета движения Ремонтируемой ЭлектроАппаратуры (АСУ РЭА). АСУ РЭА осуществляет учет и контролирует движение ремонтируемых приборов между подразделениями, позволяет оперативно получать информацию о состоянии прибора. При всех своих достоинствах, данная система имеет один существенный недостаток — на ней ведется единственный журнал учета накладных для конкретного заказа. Поэтому в разрабатываемой системе должна быть реализована возможность ведения нескольких журналов одновременно для заказов разных проектов, имеющих разную номенклатуру ремонтируемых изделий.

2.5 Характеристика инструментальных средств

2.5.1 Характеристика CASE — средств

Характеристика BPwin:

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

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

BPwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании. Встроенный механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности. Механизм вычисления расходов на основе выполняемых действий (Activity — Based Costing, ABC) — это технология, применяемая для оценки затрат и используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа.

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

Основные характеристики BPwin:

развитая методология функционального моделирования на основе IDEF0;

мощные редакторы для описания операций, связей и вычисления затрат на выполнение работ;

иерархическая структура диаграмм, облегчающая последовательное уточнение элементов модели;

контекстные диаграммы для описания границ системы, области действия, назначения объектов;

декомпозиционные диаграммы для описания особенностей взаимодействия различных процессов;

расширенные возможности по поддержанию ссылочной целостности;

поддержка методологии IDEF3;

экспорт моделей в средства имитационного моделирования;

интеграция и связь со средством проектирования баз данных ERwin (методология IDEF1X);

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

интеграция с ModelMart, поддерживающим мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания «компонент» модели. Для организации хранилища моделей в ModelMart используются СУБД на платформах Oracle, Sybase, Informix или SQL Server. Кроме того, поддерживаются прямые связи ModelMart с ERwin и BPwin;

удобный интерфейс пользователя. В распоряжении пользователей имеется проводник, ставший привычным в среде Windows 95/NT, позволяющий легко переходить с одной диаграммы на другую простым перемещением по «дереву» проводника;

расширенная архитектура. BPwin поддерживает 16 — и 32 — х разрядные системы, позволяя организовать совместную работу для всех участников проекта;

автоматическая поддержка изменения размеров. BPwin поддерживает автоматическую настройку размеров диаграмм и возможность изменения масштабов изображения моделей.

Характеристика ERwin:

Семейство продуктов ERwin фирмы PLATINUM — CA (США) относится к мощным персональным CASE — продуктам, предназначенным для моделирования баз данных самого различного типа. Отличительной чертой продуктов ERwin является высокая степень обеспечения согласованного взаимодействия между средствами создания баз данных и средствами разработки приложений в технологии клиент — сервер.

ERwin является наиболее популярным пакетом моделирования данных среди профессиональных разработчиков благодаря полной поддержке широкого спектра СУБД самого разного класса, включая Oracle, DB/2, Sybase, Informix, MS SQL Server, SQLbase, CA Ingres, Rdb, AS/400, Progress, Interbase, Watcom, в том числе: Clipper, Dbase, Access, FoxPro, Paradox.

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

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

Методологическую основу ERwin составляет технология IDEF1X (моделирование данных для реляционных СУБД). Результатом построения является ER — диаграмма («сущность — связь»). Графический подход к созданию моделей значительно упрощает процесс разработки.

Основные характеристики:

поддержка стандартной нотации IDEF1X для ER диаграмм моделей данных и нотации IE;

специальные реализации продукта с прямой поддержкой расширенного набора атрибутов в моделях данных для средств разработки приложений Visual Basic, Progress;

возможность импорта/экспорта данных из BPwin, Oracle Designer;

автоматическая генерация баз данных для широкого спектра целевых СУБД (Oracle, Microsoft SQLServer и другие);

поддержка проектирования информационных хранилищ ;

поддержка совместного проектирования ;

поддержка триггеров, хранимых процедур и шаблонов;

развитые средства проверки корректности моделей данных;

Reverse Engineering (генерация модели данных на основе анализа существующей базы данных), включая восстановление связей по индексам;

автоматическая генерация SQL DDL для создания баз данных;

полная совместимость и поддержка Oracle (более 20 — ти типов СУБД) на основе прямого доступа к системному каталогу баз данных (отпадает потребность в использовании ODBC);

глубокая интеграция с технологией и продуктами фирм Oracle, Microsoft на базе единого репозитория и эффективного обмена проектами; импорт/экспорт с Rational Rose (объектно-ориентированное средство проектирования информационных систем в стандарте UML);

автоматическая генерация экранных форм приложений для Delphi, Visual Basic, созданных на основе спроектированной модели данных.

Характеристика Rational Rose:

Rational Rose — CASE — средство фирмы Rational Software Corporation (США) предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.

Являясь объектно-ориентированным инструментом моделирования, Rose базируется на UML (Universal Modeling Language) — универсальном языке моделирования, который был разработан компанией Rational именно с целью создания наиболее оптимального и универсального языка для описания, как предметной области, так и конкретной задачи в программировании. Любая задача программируется при помощи определенных диаграмм. UML поддерживает построение следующих диаграмм:

диаграммы описаний технологий, процессов, функций;

диаграммы функций;

диаграммы классов;

диаграммы состояний;

диаграммы последовательностей действий;

диаграммы взаимодействий;

диаграммы компонентов;

диаграммы топологии.

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

Rational Rose позволяет:

проектировать системы любой сложности;

давать развернутое представление о проекте в сочетании со средствами документирования (SoDA);

проводить кодогенерацию;

проводить обратное проектирование имеющихся систем;

имеет открытый для дополнений интерфейс;

интегрируется со средствами разработки (Visual Studio);

поддержка языка UML;

наличие средств автоматического контроля, в том числе проверки соответствия двух моделей;

удобный для пользователя графический интерфейс;

многоплатформенность.

Интегрируемость с другими инструментальными средствами, поддерживающими жизненный цикл программных систем, в том числе со средством управления требованиями (Requisite Pro), со средствами тестирования (SQA Suite, Performance Studio), со средствами конфигурационного управления (ClearCase, PVCS).

2.5.2 Характеристика СУБД

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

Oracle — СУБД, использующая предоставляемые некоторыми серверными платформами средства параллельных вычислений — Oracle Parallel Server (до его появления параллельные вычисления использовались только для решения научных задач). При использовании параллельных вычислений Oracle Parallel Server дает возможность нескольким процессорам обращаться к одной базе данных, что позволяет обеспечить высокую скорость обработки транзакций.

Oracle Server — это реляционная СУБД, поддерживающая язык PL/SQL и механизм транзакций. Она обеспечивает очень высокое быстродействие системы в многопользовательском режиме. Кроме того, СУБД Oracle осуществляет автоматическую блокировку данных в этом режиме, что позволяет увеличивать общее количество пользователей в системе без снижения ее производительности.

СУБД Oracle обеспечивает надежную защиту информации, как от несанкционированного доступа, так и от сбоев системы. При создании приложений, СУБД позволяет часть обработки и контроля данных вынести на сервер. Oracle Server позволяет создавать хранимые процедуры, триггеры баз данных, функции, а также пакеты процедур и функций. В качестве процедурного языка используется расширение языка SQL, называемое PL/SQL.

2.5.3 Характеристика средств программирования и отладки

Характеристика TOAD:

В современной динамичной деловой среде, приложения и базы данных должны разрабатываться и поддерживаться во все более и более быстром темпе. Чтобы помочь разработчикам быстро и эффективно выполнять полученные задания, Quest Software предлагает TOAD — инструмент, радикально упрощающий разработку и поддержку приложений БД Oracle. TOAD обеспечивает единую среду для ускоренной разработки и тестирования PL/SQL, предоставляя быстрый доступ к объектам базы данных. Интуитивно понятный графический интерфейс пользователя TOAD обеспечивает профессиональную, мощную и компактную среду разработки и управления базой данных.

Применяя TOAD для управления объектами базы данных, пользователю вовсе не требуется иметь квалификацию эксперта. Модуль Schema Browser в TOAD позволяет быстро просматривать и управлять словарем данных. Щелчком мыши на выбранном объекте пользователь мгновенно получает подробную информацию, минуя длинную иерархию хранения объектов. В том же окне можно управлять всеми объектами.

Мощные редакторы TOAD повышают производительность разработчика, исключают ошибки и значительно сокращают сроки разработки. Редакторы позволяют пользователям работать одновременно с исходными кодами на нескольких языках (SQL, PL/SQL, HTML, Java) или с текстом. Заменяя традиционный способ выполнения запроса в командной строке или из сценария графическим интерфейсом, TOAD обеспечивает быструю и удобную среду разработки, легко конфигурируемую под предпочтения пользователя.

SQL Editor повышает производительность разработки за счет большого количества горячих клавиш, функций автокорректировки, опережающего ввода и цветового выделения синтаксиса. Удобные закладки позволяют разработчикам быстро перемещаться между несколькими областями программного кода. Полнофункциональная панель инструментов облегчает редактирование и тестирование. Всплывающие селекторы для выбора имен таблиц, имен столбцов и функций/ключевых слов Oracle. Procedure Editor позволяет пользователям работать с несколькими файлами, в параллельном режиме используя SCC — совместимое управление версиями. Одновременно могут компилироваться несколько объектов с согласованной компиляцией всех зависимых объектов.

Кроме того, редакторы TOAD тесно интегрированы с отладчиком PL/SQL Debugger, что позволяет пользователям тестировать только определенные области процедур, выполнять только текущий оператор, несколько операторов за курсором или только операторы до курсора. TOAD также предлагает SQL Modeler — средство для быстрого и легкого построения запросов. Достаточно перенести таблицы в SQL Modeler, и модуль автоматически сформирует запрос SQL. Удобная интегрированная среда позволяет уточнять критерии запроса, тестировать автоматически сгенерированные запросы SQL, просматривать планы выполнения и результаты запросов, сохранять выражения или копировать их в редактор. Применяя SQL Modeler, даже неопытные пользователи могут быстро создавать сложные запросы на уровне экспертов Oracle.

TOAD — один из компонентов семейства продуктов Development & Deployment компании Quest Software, которое позволяет разработчикам и АБД быстро разрабатывать, тестировать и внедрять приложения.

Характеристика Delphi и Borland C++Builder:

C++Builder и Delphi стали одними из самых популярных на сегодняшний день инструментов для создания как настольных, так и корпоративных информационных систем благодаря уникальному сочетанию удобства разработки пользовательских интерфейсов, компонентной архитектуры, однотипности доступа к разнообразным базам данных, начиная от плоских таблиц формата dBase и Paradox и кончая серверными СУБД. Во многом именно наличие таких продуктов стимулировало достаточно безболезненный перенос в архитектуру клиент/сервер ряда информационных систем, модернизация которых иными средствами была бы сопряжена с большими трудовыми и материальными затратами.

Следует отметить, что современные тенденции развития инструментальных средств таковы, что актуальным становится не просто появление новых гибких и мощных средств разработки, а создание семейств таких продуктов с похожими средами и принципами создания приложений, что в целом повторяет появившуюся примерно 4 года назад идеологию формирования офисных пакетов (текстовый процессор + электронная таблица + настольная СУБД + презентационный пакет) вместо выпуска отдельных офисных приложений. Если рассматривать линию продуктов Inprise, то в данный момент на рынке средств разработки присутствуют Delphi и C++Builder, а также сходные по методам создания приложений и среде JBuilder, IntraBuilder, Visual dBase.

Сходство C++Builder и Delphi не является чисто внешним. C++Builder обладает компонентной архитектурой и создан на основе библиотеки визуальных компонентов Delphi ставшей за последние два года весьма популярной среди разработчиков. По этой причине этот продукт имеет общую с Delphi библиотеку классов, часть из которых написана на Obiect Pascal.

Однако совместимость C++Builder и Delphi этим не исчерпывается. В проектах C++Builder можно использовать не только библиотеку компонентов Delphi, но и код, написанный на Object Pascal, а также формы и модули Delphi. Поддерживается визуальное наследование форм и модулей данных, в том числе и созданных в Delphi. Эти возможности появились благодаря включению в C++Builder обоих компиляторов C++ и Object Pascal.

Это означает, что можно создавать общие проекты, используя оба средства разработки — и C++BuiIder, и Delphi. Части одного приложения могут быть созданы с помощью двух средств, и теперь к работе над проектом можно привлекать разработчиков, использующих как Delphi, так и C++. Вовторых, и это очень важно, C++Builder может использовать компоненты, созданные для Delphi, а их за последние несколько лет создано огромное количество. Это богатство, накопленное разработчиками всего мира, сегодня способно удовлетворить самые причудливые запросы.

C++Builder предоставляет программисту широкие возможности повторного использования кода не только за счет наличия библиотеки компонентов, но и за счет поддержки стандарта ActiveX, что позволяет встраивать в приложения ActiveXкомпоненты как сторонних производителей, так и созданные собственноручно с помощью самого C++Builder.

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

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

2. ПРОЕКТНАЯ ЧАСТЬ

2.1 Определение функции системы

В рамках спроектированной информационной системы был разработан модуль «Учет движения ремонтируемых приборов». Ниже определены основные требования к данному модулю путем построения диаграммы вариантов его использования в нотации UML. Диаграмма приведена на рисунке 3.1, в таблице 3.1 приведено описание функций системы, в таблице 3.2 — описание взаимосвязей функций с объектами и пользователями.

Рис. 3.1. Диаграмма вариантов использования для пользователя.

Таблица 3.1. Описание функций системы

Таблица 3.2. Описание пользователей и объектов системы

2.2 Описание информационно-логической модели

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

Для построения информационно-логической модели было использовано CASE средство Erwin Computer Associates.

Информационно-логическая модель приведена на рисунках 3.1 — 3.3.

Рис. 3.2. Информационно-логическая модель комплекса задач «Учёт движения ремонтируемых приборов» на уровне сущностей.

Рис. 3.3. Информационно-логическая модель комплекса задач «Учёт движения ремонтируемых приборов» на уровне определений.

Рис. 3.4. Информационно-логическая модель комплекса задач «Учёт движения ремонтируемых приборов» на уровне атрибутов.

2.2.1 Описание состава сущностей

Сущность «Проект» характеризует проект, по которому построен ремонтируемый заказ.

Таблица 3.3.

Сущность «Проект»

Сущность «Заказ» характеризует ремонтируемый заказ.

Таблица 3.4.

Сущность «Заказ

Сущность «Изделие» характеризует ремонтируемое изделие.

Таблица 3.5.

Сущность «Изделие»

Сущность «Схема» характеризует наименование схемы, входящей в изделие Таблица 3.6.

Сущность «Схема»

Сущность «Тип прибора» характеризует тип прибора, входящего в изделие.

Таблица 3.7.

Сущность «Тип прибора»

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

Таблица 3.8.

Сущность «Прибор»

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

Таблица 3.9.

Сущность «Подразделение»

Сущность «Журнал накладных» характеризует журнал учета накладных, в котором хранится информация обо всех накладных, оформленных всеми подразделениями в процессе выполнения ремонтно-восстановительных работ.

Таблица 3.10.

Сущность «Журнал накладных»

2.3 Описание физической модели

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

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

Рис. 3.5. Физическая модель данных.

Описание физических таблиц

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

Таблица «Project» необходима для хранения информации о проектах ремонтируемых заказов.

Таблица 3.11.

Структура таблицы «PROJECT»

Таблица «Ship» необходима для хранения информации о ремонтируемых заказах.

Таблица 3.12.

Структура таблицы «SHIP»

Таблица «IZDELIE» необходима для хранения информации о ремонтируемых изделиях.

Таблица 3.13.

Структура таблицы «IZDELIE»

Таблица «SCHEMA» необходима для хранения информации о схемах, входящих в ремонтируемые изделий.

Таблица 3.14.

Структура таблицы «SCHEMA»

Таблица «DEVICE_TYPE» необходима для хранения информации о типах ремонтируемых приборов.

Таблица 3.15.

Структура таблицы «DEVICE_TYPE»

Таблица «DEVICE» необходима для хранения информации о ремонтируемых приборах.

Таблица 3.16.

Структура таблицы «DEVICE»

Таблица «PODRAZD» необходима для хранения информации о подразделениях.

Таблица 3.17.

Структура таблицы «PODRAZD»

Таблица «REG_BOOK» необходима для хранения информации о сформированных накладных.

Таблица 3.18.

Структура таблицы «REG_BOOK»

2.4 Построение динамической модели данных

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

Диаграмма состояния системы

Диаграмма состояния системы для роли «Пользователь» приведена на рисунке 3.6, на нем отображается состояние, в котором может находиться система и переходы из одного в другое состояние при определенных событиях программы или внешних воздействиях.

Рис. 3.6. Диаграмма состояния системы для роли «Пользователь».

Диаграмма деятельности системы

Диаграмма деятельности системы для роли «Пользователь» приведена на рисунке 3.8, на нем отображается последовательность бизнес-процессов или операций классов по принципу от активности к активности или от активности к состоянию.

Рис. 3.8. Диаграмма деятельности системы для роли «Пользователь»

Диаграмма топологии системы

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

Рис. 3.10 Диаграмма топологии системы.

Диаграмма последовательности (взаимодействия)

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

Обмен сообщениями происходит в определенной последовательности, и Sequence Diagram позволяют получить отражение этого обмена во времени.

Диаграммы последовательности (взаимодействия) пользователя, АС и СУБД приведены на рисунках 3.11.

Рис. 3.11. Диаграмма последовательности (взаимодействия) пользователя, АС и СУБД

2.5 Описание интерфейсов и результатов работы программы

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

Рис. 3.12. Главная форма приложения.

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

При нажатии кнопки «Просмотр журналов учета накладных» происходит переход на форму «Журналы учета накладных».

Рис. 3.13. Форма «Журналы учета накладных».

Пользователь может создавать накладные при нажатии кнопки «Новая накладная», просматривать накладные по подразделениям, при выборе их в соответствующем поле, создавать отчеты и осуществлять поиск.

При нажатии кнопки «Новая накладная» выводится форма «Новая накладная».

Рис. 3.14. Форма «Новая накладная».

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

Рис. 3.15. Форма «Журналы учета накладных» (Отчеты).

При выборе отчета «За период» появляется окно формы «Накладные за период», в которой пользователь указывает параметры отчета.

Рис. 3.16. Форма «Накладные за период».

При нажатии кнопки «Показать» производится предварительный просмотр отчета.

При выборе отчета «По изделию» появляется окно формы «Выберите изделие», в которой пользователь указывает параметры отчета.

Рис. 3.17. Форма «Выберите изделие».

При нажатии кнопки «Показать» производится предварительный просмотр отчета.

При выборе на форме «Журналы учета накладных» пункта меню «Поиск» производится поиск по подразделению и дате (рисунок 3.18. и рисунок 3.19.).

Рис. 3.18. Форма «Поиск по подразделению».

Рис. 3.19. Форма «Поиск по дате».

При выборе в главной форме «Просмотр информации о ремонте» появляется форма «Информация о ремонте».

Рис. 3.21. Форма «Информация о ремонте».

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

При выборе пункта «Добавить» в главном меню формы «Информация о ремонте» пользователь может заносить информацию в БД.

Рис. 3.22. Форма «Добавление».

При выборе в главной форме «Справочники» появляется форма «Справочная информация».

Рис. 3.23. Форма «Справочная информация».

Далее приведен внешний вид отчетов, генерируемых приложением.

Рис. 3.24. Отчет «Накладные, полученные за период».

Рис. 3.25. Отчет «Приборы, находящиеся в подразделении».

Рис. 3.26. Отчет «Приборы, требующие замены».

Рис. 3.27. Отчет «Приборы с массой «.

3. ЭКОНОМИЧЕСКАЯ ЧАСТЬ

Темой организационно-экономической части дипломного проекта является расчет сметы затрат необходимых для создания программы учета технической документации на предприятии. Затраты на разработку будут определяться по формуле З_пс = П_ок +Р_асх + 3_р + О_сн + Р_пр (руб.), (4.1)

где П_ок — стоимость покупных комплектующих (руб.);

Р_асх — стоимость расходных материалов (руб.);

З_р — заработная плата разработчиков программы (руб.);

О_сн — отчисления на социальные нужды (ЕСН) (руб.);

Р_пр — прочие прямые расходы (руб.).

3.1 Расчет стоимости покупных комплектующих и расходных материалов

За время подготовки и согласования технической документации проекта была потрачена 1 пачка бумаги формата А4 стоимостью 195 рублей. Кроме того, для распечатки документов использовались картриджи для струйного принтера, стоимость которых составляет в сумме 680 рублей. Тогда полная стоимость расходных материалов составит:

Р_асх = 195 + 680= 875 руб.

Полный перечень использованных расходных материалов с указанием их стоимости указан в таблице 4.1

Таблица 4.1

Стоимость затраченных расходных материалов

3.2 Расчет трудоемкости создания программы

Для того чтобы посчитать непосредственно затраты на программирование и отладку необходимо выяснить, сколько времени было отведено на создание и отладку программы. На основании данных, полученных в результате статистической обработки показателей вычислительного процесса, было определено, что средний расход машинного времени (ч/100 команд) для общесистемных задач, к которым можно отнести разработанный проект составляет 4 часа на 100 команд исходного кода. Общее число команд приравнено к числу строк программы. Просуммировав число строк во всех файлах, содержащих исходные тексты программы, можно получить общее число команд. В разработанной программе число команд примерно равняется 3200.

С_м = К_м * N_c (4.2)

где С_м — общий расход машинного времени;

К_м— средний расход машинного времени, который составляет 0,04 (ч/1 команду);

N_c— число команд.

На оформление документов (предпроектный анализ задач и формирование требований пользователя, разработка концепции создания программного изделия, разработка и согласование технического задания на создание программного изделия, оформление проектной и эксплуатационной документации, тестирование программы) затрачено 140 часов. Полная трудоемкость произведенных работ указана в таблице 4.2.

Таблица 4.2

Трудоемкость создания программного средства

3.3 Расчет заработной платы

Для расчета стоимости нормы-часа работы программиста принято 70 руб. в час. На разработку данного проекта было затрачено 315 часов, таким образом, стоимость разработки метода решения составил: Зр = 70*315=22 050 руб. Размер дополнительной заработной платы составляет 10% от размера основной, что составит 2205 руб.

Расчет единого социального налога

Ставка единого социального налога (ЕСН) на момент разработки составляет 26% от заработной платы. Тогда:

ЕСН=(22 050+2205) *0,26=6306,3 руб.

3.4 Расчет прочих прямых расходов

Расчет затрат на электроэнергию производится по формуле:

(руб.), (4.3)

где:Ц _{квт/руб} — цена одного киловатта электроэнергии = 1,92 руб.

Т — время затраченное на работу ПК = 300 часов Расчет затрат электроэнергии складывается из стоимости одного киловатта равного 1,92 рубля умноженного на количество машинного времени затраченного на разработку программного продукта равного 320 часов. В итоге затраты на электроэнергию составили:

З_эл= 1,92 * 300 = 576 руб.

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

(руб.), (4.4)

где: Vобъём скачанной информации (Мb);

Ц _Mb — цена одного мегабайта скачанной информации (руб.)

В рассматриваемом случае при работе в сети Интернет было скачано около 190 Mb информации, при цене одного мегабайта скачанной информации 1,90 руб. Тогда:

З_м.в.=190*1,90=361 руб.

Общая сумма прочих прямых расходов составила:

P_n= З_эл+ З_м.в (4.4)

P_n=576+361=937 руб.

Общий перечень прямых расходов представлен в таблице 4.3.

Таблица 4.3 Общий перечень прямых расходов

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

Таблица 4.4 Смета затрат на разработку программного продукта

3.5 Оценка экономической эффективности системы

Данная автоматизированная система разрабатывалась, как средство улучшения качества работы службы материально-технического снабжения. В этом случае прямой экономический эффект от внедрения рассчитать сложно, но несомненно, что внедрение данной разработки принесет значительный косвенный экономический эффект за счет ускорения и оптимизации времени оформления, поиска и просмотра документации. Это повысит качество труда специалистов ОАО СПО «Арктика».

4. ТРЕБОВАНИЯ К ТЕХНИКЕ БЕЗОПАСНОСТИ И ОХРАНЕ ЖИЗНЕДЕЯТЕЛЬНОСТИ

4.1 Анализ опасных и вредных факторов при работе на ЭВМ

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

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

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

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

Спектр излучений ЭЛТ включает рентгеновское излучение, электростатический потенциал (ловушка для пыли), а также низкои высокочастотные электрические и магнитные поля. Взаимодействие пучка электронов с люминофором в ЭЛТ приводит к возникновению электромагнитных излучений в оптическом (310¹²-310¹⁶ Гц) и рентгеновском диапазоне (310¹⁶-310¹⁹ Гц). Если защита от рентгеновских лучей, электрического заряда и электрических ударов в большинстве случаев гарантируется, то при уменьшении электромагнитных полей до разумных пределов у многих изготовителей возникают трудности. Широко распространено убеждение, что эти поля являются источником болезней или вызывают хронические заболевания: растворение амальгамы в зубных пломбах, нарушение сердечного ритма и повышенный риск образования раковых клеток.

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

4.2 Общие положения и область применения

Данные требования разработаны в соответствии с санитарно-эпидемиологическими правилами и нормативами ''Гигиенические требования к персональным электронно-вычислительным машинам и организации работы. СанПиН 2.2.2/2.4.1340−03, утвержденные Главным государственным санитарным врачом Российской Федерации и действующие на всей территории Российской Федерации с 30 июня 2003 года.

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

Требования определяют санитарно-эпидемиологические требования к:

— эксплуатации отечественных ПЭВМ, используемых на производстве;

— эксплуатации импортных ПЭВМ, используемых на производстве;

— организации рабочих мест с ПЭВМ.

Требования распространяются:

— на условия и организацию работы с ПЭВМ;

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

Рабочие места с использованием ПЭВМ должны соответствовать данным требованиям.

4.3 Организация рабочего места пользователя

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

— режим работы;

— рабочее место;

— освещенность;

— излучение экрана.

Нормальная и безопасная работа человека-оператора во многом зависит от того, в какой мере условия и режим его работы соответствуют оптимальным. Режим труда операторов зависит от характера работы: ввод данных, редактирование программ, считывание информации с экрана и т. д. Техника безопасности зависит от типа и конструкции ЭВМ. Необходимы перерывы 5−10 минут через каждый час работы и 15 минут — через два часа работы (за рубежом рекомендуется отдыхать каждый час). Рекомендуемое количество нажатий на клавиши — 10−12 тысяч в час (приблизительно 1700 слов) или 200 в минуту.

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

Рабочие зоны в зависимости от положения человека-пользователя делят на зоны для работы стоя и работы сидя. Однако именно положение пользователя сидя определяет форму его рабочего места. Для нормальной организации труда пользователя разместить все требующиеся ему, а также привлекающие его внимание во время работы предметы в зонах досягаемости. Однако практически все исследователи в области эргономики (проблемы человек — компьютер) считают, что нельзя найти идеального места, положения при работе, в котором можно было бы трудится в течение всего установленного времени. Для большинства людей наиболее оптимальным считается такое положение, которое можно перестроить не менее чем для двух позиций. Большое значение имеет в этом плане правильный выбор стола и стула для пользователя ЭВМ. Стул, в частности, должен иметь примерно пять параметров регулировки, особенно по росту, а также по положению подлокотников. Стул также должен иметь оптимальную опорную жесткость. Рекомендуется установка рабочего положения стула таким образом, чтобы линия взора оператора почти совпадала с центром экрана. Необходимо, чтобы расстояние между экраном и пользователем было не менее 50 см. Клавиатура не должна быть жестко связана с дисплеем и должна быть расположена на наиболее удобном для пользователя уровне.

4.4 Микроклимат, содержание аэроионов и вредных химических веществ в воздухе помещений эксплуатации ЭВМ

В производственных помещениях, в которых работа с ЭВМ является основной, должны обеспечиваться оптимальные параметры микроклимата. Параметры микроклимата приведены в таблице 5.1.

Таблица 5.1. Микроклимат помещений

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

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

Уровни положительных и отрицательных аэроионов в воздухе помещений с ЭВМ должны соответствовать нормам. Уровень аэроинов приведен в таблице 5.2. А Допустимое содержание вредных химических веществ в помещениях с ЭВМ приведено в таблице 5.3.

Таблица 5.2.

Уровень аэроионов

Допустимое содержание вредных химических веществ в помещениях с ЭВМ Таблица 5.3.

Допустимое содержание вредных химических веществ в помещениях с ЭВМ

4.5 Шум и вибрация

В помещениях, в которых работа на ЭВМ является основной (залы вычислительной техники и др.), во всех учебных помещениях с ЭВМ фоновый уровень шума не должен превышать 40 дБА, (при работе систем воздушного отопления, вентиляции и кондиционирования — 35 дБА), а во время работы на ЭВМ 50 дБА.

Время реверберации в помещениях с ЭВМ не должно быть более 1 с. Частотная характеристика времени реверберации в диапазоне частот 250−4000 Гц должна быть ровной, а на частоте 125 Гц спад времени реверберации должен составлять не более 5%.

4.6 Освещение

Освещение следует выбирать в зависимости от яркости экрана, его цвета, а также времени работы с экраном. Хорошее освещение необходимо для выполнения большинства задач, поставленных перед оператором. Чтобы правильно спланировать рациональную систему освещения, необходимо учитывать яркость источников света, их расположение в помещении, яркостный контраст между устройствами ЭВМ и фоном, блесткость поверхностей, качество и цвет светильников и поверхностей. Для малой и средней контрастности поверхности ЭВМ при темном фоне наименьший уровень освещенности должен быть 150 лк. Для большой контрастности при светлом или темном фоне наименьший уровень освещенности 100 лк. ЭВМ эксплуатируют в помещениях, где необходимо предусматривать систему искусственного освещения из люминесцентных ламп дневного света или ламп накаливания. Величина коэффициента искусственного освещения должна соответствовать нормативам уровня по СанПиН 2.2.2/2.4.1340−03 «Требования к освещению на рабочих местах, оборудованных ПЭВМ».

4.7 Требования к помещениям для эксплуатации ЭВМ

Помещения с ЭВМ должны иметь естественное и искусственное освещение. Естественное освещение должно осуществляться через светопроемы, ориентированные преимущественно на север и северо-восток и обеспечивать коэффициент естественной освещенности (КЕО) не ниже 1,2% в зонах с устойчивым снежным покровом и не ниже 1,5% на остальной территории.

Площадь на одно рабочее место с ЭВМ для пользователя должна составлять не менее 6,0 кв. м, а объем — не менее 20,0 куб. м.

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

Звукоизоляция ограждающих конструкций помещений с ВДТ и ПЭВМ должна отвечать гигиеническим требованиям и обеспечивать нормируемые параметры шума.

Для внутренней отделки интерьера помещений с ЭВМ должны использоваться диффузно — отражающие материалы с коэффициентом отражения для потолка — 0,7 — 0,8; для стен — 0,5 -0,6; для пола — 0,3 — 0,5. Полимерные материалы, используемые для внутренней отделки интерьера помещений с ВДТ и ПЭВМ, должны быть разрешены для применения органами и учреждениями Государственного санитарно — эпидемиологического надзора.

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

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

4.8 Требования к монитору

Очень важным звеном в охране здоровья пользователя, интенсивно работающего с компьютером, является монитор. Требования, предъявляемые к мониторам, можно подразделить на четыре группы: качество представления изображения, излучение, электрическая и механическая надежность.

Наиболее важными для монитора являются следующие технические параметры качества изображения: частота вертикальной синхронизации (кадровая развертка), частота горизонтальной синхронизации (строчная развертка) и полоса пропускания видеосигнала. Кадровая частота измеряется обычно в герцах и во многом определяет устойчивость изображения (отсутствие мерцаний). Как известно, человеческий глаз воспринимает смену изображений с частотой выше 20−25 Гц практически как непрерывное движение. Чем выше частота кадров, тем устойчивее изображение. Частота строк в килогерцах, вообще говоря, определяется произведением частоты вертикальной развертки на количество выводимых строк в одном кадре (разрешающая способность по вертикали). Полоса видеосигнала, измеряемая в мегагерцах, определяет самые высокие частоты в видеосигнале. Приблизительно эта величина может быть рассчитана как произведение количества точек в строке (разрешающая способность по горизонтали) на частоту строчной развертки. Иными словами, этот параметр отражает число точек в строке, которое монитор может воспроизвести за одну секунду.

При прочих равных условиях четкость изображения на мониторе тем выше, чем меньше размеры точек люминофора на внутренней поверхности экрана. Обычно говорят не о размерах самих точек, а о расстоянии между ними (dot per pitch). Этот параметр для различных моделей мониторов может лежать в диапазоне от 0,41 до 0,25 мм, однако для хороших моделей диапазон существенно сужается — от 0,28 до 0,25 мм.

4.9 Режим труда и отдыха

Режимы труда и отдыха при работе с ПЭВМ и ВДТ должны организовываться в зависимости от вида и категории трудовой деятельности.

Виды трудовой деятельности разделяются на 3 группы: группа, А — работа по считыванию информации с экрана ВДТ или ПЭВМ с предварительным запросом; группа Б — работа по вводу информации; группа В — творческая работа в режиме диалога с ЭВМ. При выполнении в течение рабочей смены работ, относящихся к разным видам трудовой деятельности, за основную работу с ПЭВМ и ВДТ следует принимать такую, которая занимает не менее 50% времени в течение рабочей смены или рабочего дня.

Для видов трудовой деятельности устанавливается 3 категории тяжести и напряженности работы с ВДТ и ПЭВМ, которые определяются: для группы, А — по суммарному числу считываемых знаков за рабочую смену, но не более 60 000 знаков за смену; для группы Б — по суммарному числу считываемых или вводимых знаков за рабочую смену, но не более 40 000 знаков за смену; для группы В — по суммарному времени непосредственной работы с ВДТ и ПЭВМ за рабочую смену, но не более 6 часов за смену.

Для обеспечения оптимальной работоспособности и сохранения здоровья профессиональных пользователей на протяжении рабочей смены должны устанавливаться регламентированные перерывы. Время регламентированных перерывов в течение рабочей смены следует устанавливать в зависимости от ее продолжительности, вида и категории трудовой деятельности. Продолжительность непрерывной работы с ВДТ без регламентированного перерыва не должна превышать 2 часов.

При 8-часовой рабочей смене и работе на ВДТ и ПЭВМ регламентированные перерывы следует устанавливать:

— для I категории работ — через 2 часа от начала рабочей смены и через 2 часа после обеденного перерыва продолжительностью 15 минут каждый;

— для II категории работ — через 2 часа от начала рабочей смены и через 1.5 — 2 часа после обеденного перерыва продолжительностью 15 минут каждый или продолжительностью 10 минут через каждый час работы;

— для III категории работ — через 1.5 — 2 часа от начала рабочей смены и через 1.5 — 2 часа после обеденного перерыва продолжительностью 20 минут каждый или продолжительностью 15 минут через каждый час работы.

4.10 Защита от статического электричества и электромагнитных излучений

Для предотвращения образования и защиты от статического электричества в помещениях ВЦ необходимо использовать нейтрализаторы и увлажнители, а полы должны иметь антистатическое покрытие. Защита от статического электричества должна проводиться в соответствии с санитарно-гигиеническими нормами допускаемой напряженности полей и не должна превышать 20 кВ в течение 1 часа (ГОСТ 12.1045−84).

В последнее время все большее распространение получают мониторы с низким уровнем излучения — так называемые LR-мониторы (Low Radiation). Эти устройства обычно отвечают одной из двух спецификаций, выработанных Шведским национальным советом по измерениям и тестированию MPR (Swedish National Board of Measurement and Testing). Первая спецификация (MPR I) касается в основном магнитных полей и определяет уровень излучения для частот в полосе от 1 до 400 кГц. Вторая спецификация (MPR II), принятая в декабре 1990 года была распространена и на электрические поля. Оба поля измеряются в двух полосах: 5 Гц — 2 кГц и 2 — 400 кГц. Напряженность электрического поля в нижней полосе не должна превышать 25 В/м, а в верхней 2,5 В/м, соответственно напряженность магнитного поля — 250 и 2,5 нанотесла. Электростатический потенциал должен быть ниже 500 В.

4.11 Требования к утилизации отходов при работе на компьютере

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

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

Городская свалка промышленных и бытовых отходов расположена на свободной территории в 8 км от предприятия. Накопитель твердых промышленных отходов расположен к юго-востоку от города на расстоянии 7 км на площадке, прилегающей к дороге, ведущей на свалку промышленных отходов.

В целях предотвращения загрязнения почвы, нереализуемые и опасные токсичные отходы 1−3 классов опасности, образующиеся в процессе выполнения работ, собираются в специальные контейнеры и складируются на временной площадке контейнерного хранения токсичных отходов на территории предприятия согласно инструкции 60.81−1.02.056−99.

Концентрация химических веществ в почве не должна превышать допустимые нормы согласно нормативным документам.

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

— обеспечивает хранение информации в СУБД «ORACLE»;

— предоставляет пользователям общие средства навигации и доступа к данным;

— обеспечивает интегрированные средства поиска;

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

ПЕРЕЧЕНЬ ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

электроапаратура автоматисированный програмный

1. Маклаков С. В., Bpwin и Erwin. CASE-средства разработки информационных

систем. — М.: Диалог-МИФИ, 2001.

2. Хомоненко А., Гофман В. Самоучитель Delphi. — Санкт-Петербург: «БХВПетербург», 2003.

3. Конноли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика — М.: Вильямс, 2003.

4. Архангельский А. Я. «Delphi 7. Справочное пособие», М.: Бином, 2003.

5. СанПиН 2.1.7.1322−03. Гигиенические требования к размещению и обезвреживанию отходов производства и потребления от 30 апреля 2003 г.

5. СанПиН 2.2.2/2.4−1340−03. Гигиенические требования к персональным электронно-вычислительным машинам и организации работы; от 3 июня 2003 г.

6. СанПиН 2.2.4.1329−03 Требования по защите персонала от воздействия импульсных электромагнитных полей, 2003.

7. Фаулер М., Скотт К. «UML в кратком изложении. Применение стандартного объектного языка моделирования», М.: Мир, 1999.

ПРИЛОЖЕНИЕ

ЛИСТИНГ ПРОГРАММЫ

unit UnitSelect;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ExtCtrls;

type

TFormSelect = class (TForm)

Panel1: TPanel;

Panel2: TPanel;

Panel3: TPanel;

Panel4: TPanel;

Panel5: TPanel;

Panel6: TPanel;

procedure Panel4Click (Sender: TObject);

procedure Panel3Click (Sender: TObject);

procedure Panel5Click (Sender: TObject);

procedure Panel6Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

FormSelect: TFormSelect;

implementation

uses UnitAutor, UnitJournal, UnitRepair, UnitSprav;

{$R *.dfm}

procedure TFormSelect. Panel4Click (Sender: TObject);

begin

FormJournal.Show;

FormSelect.Hide;

end;

procedure TFormSelect. Panel3Click (Sender: TObject);

begin

Application.Terminate;

end;

procedure TFormSelect. Panel5Click (Sender: TObject);

begin

FormRepair.Show;

FormSelect.Hide;

end;

procedure TFormSelect. Panel6Click (Sender: TObject);

begin

FormSprav.Show;

FormSelect.Hide;

end;

end.

unit UnitJournal;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ExtCtrls, DB, ADODB, StdCtrls, Grids, DBGrids, Menus;

type

TFormJournal = class (TForm)

Panel1: TPanel;

Panel2: TPanel;

Panel3: TPanel;

Panel4: TPanel;

GroupBox1: TGroupBox;

GroupBox2: TGroupBox;

ComboBoxPodrazd: TComboBox;

Label1: TLabel;

ADOTablePodrazd: TADOTable;

ADOConnectionJournal: TADOConnection;

ADOQueryViborNakl: TADOQuery;

DataSource1: TDataSource;

DBGrid1: TDBGrid;

ADOQueryViborNaklNUMBER: TStringField;

ADOQueryViborNaklDATE_CREATE: TDateTimeField;

ADOQueryViborNaklPODRAZD_NAME: TStringField;

ADOQueryViborNaklIZD_NAIM: TStringField;

ADOQueryViborNaklSHIP_ZAV_NOM: TStringField;

Panel5: TPanel;

Panel6: TPanel;

Panel7: TPanel;

Panel8: TPanel;

Panel9: TPanel;

Panel10: TPanel;

Panel11: TPanel;

ADOQueryDevice: TADOQuery;

DBGrid2: TDBGrid;

DataSource2: TDataSource;

Panel12: TPanel;

Panel13: TPanel;

Panel14: TPanel;

Panel15: TPanel;

Panel16: TPanel;

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

Panel17: TPanel;

procedure FormActivate (Sender: TObject);

procedure FormClose (Sender: TObject; var Action: TCloseAction);

procedure ComboBoxPodrazdClick (Sender: TObject);

procedure Panel6Click (Sender: TObject);

procedure Panel7Click (Sender: TObject);

procedure Panel8Click (Sender: TObject);

procedure Panel10Click (Sender: TObject);

procedure Panel11Click (Sender: TObject);

procedure Panel9Click (Sender: TObject);

procedure DBGrid1CellClick (Column: TColumn);

procedure Panel12Click (Sender: TObject);

procedure Panel13Click (Sender: TObject);

procedure Panel15Click (Sender: TObject);

procedure Panel16Click (Sender: TObject);

procedure Panel17Click (Sender: TObject);

procedure N3Click (Sender: TObject);

procedure N4Click (Sender: TObject);

procedure N5Click (Sender: TObject);

procedure N6Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

FormJournal: TFormJournal;

implementation

uses UnitAutor, UnitSelect, UnitNakl, UnitPeriod, UnitViborIzd,

UnitSearchDate, UnitSearchPodrazd;

{$R *.dfm}

procedure TFormJournal. FormActivate (Sender: TObject);

begin

ADOConnectionJournal.Connected:=true;

ADOTablePodrazd.Active:=true;

ADOTablePodrazd.Open;

ADOTablePodrazd.First;

ComboBoxPodrazd.Clear;

while ADOTablePodrazd. Eof=false do

begin

ComboBoxPodrazd.Items.Add (ADOTablePodrazd.FieldByName ('PODRAZD_NAME').AsString);

ADOTablePodrazd.Next;

end;

end;

procedure TFormJournal. FormClose (Sender: TObject;

var Action: TCloseAction);

begin

ADOTablePodrazd.Active:=false;

ADOConnectionJournal.Connected:=false;

end;

procedure TFormJournal. ComboBoxPodrazdClick (Sender: TObject);

begin

ADOTablePodrazd.Locate ('PODRAZD_NAME', ComboBoxPodrazd. Text,[]);

ADOQueryViborNakl.Parameters.ParamByName ('p').Value:=ADOTablePodrazd.FieldByName ('PODRAZD_ID').AsInteger;

ADOQueryViborNakl.Open;

end;

procedure TFormJournal. Panel6Click (Sender: TObject);

begin

FormSelect.Show;

FormJournal.Close;

end;

procedure TFormJournal. Panel7Click (Sender: TObject);

begin

ADOQueryViborNakl.First;

end;

procedure TFormJournal. Panel8Click (Sender: TObject);

begin

ADOQueryViborNakl.Prior;

end;

procedure TFormJournal. Panel10Click (Sender: TObject);

begin

ADOQueryViborNakl.Next;

end;

procedure TFormJournal. Panel11Click (Sender: TObject);

begin

ADOQueryViborNakl.Last;

end;

procedure TFormJournal. Panel9Click (Sender: TObject);

begin

ADOQueryDevice.Parameters.ParamByName ('p').Value:=ADOQueryViborNakl.FieldByName ('NUMBER').AsString;

ADOQueryDevice.Close;

ADOQueryDevice.Open;

end;

procedure TFormJournal. DBGrid1CellClick (Column: TColumn);

begin

ADOQueryDevice.Parameters.ParamByName ('p').Value:=ADOQueryViborNakl.FieldByName ('NUMBER').AsString;

ADOQueryDevice.Close;

ADOQueryDevice.Open;

end;

procedure TFormJournal. Panel12Click (Sender: TObject);

begin

ADOQueryDevice.First;

end;

procedure TFormJournal. Panel13Click (Sender: TObject);

begin

ADOQueryDevice.Prior;

end;

procedure TFormJournal. Panel15Click (Sender: TObject);

begin

ADOQueryDevice.Next;

end;

procedure TFormJournal. Panel16Click (Sender: TObject);

begin

ADOQueryDevice.Last;

end;

procedure TFormJournal. Panel17Click (Sender: TObject);

begin

FormNakl.Show;

FormJournal.Hide;

end;

procedure TFormJournal. N3Click (Sender: TObject);

begin

FormPeriod.Show;

end;

procedure TFormJournal. N4Click (Sender: TObject);

begin

FormViborIzd.Show;

end;

procedure TFormJournal. N5Click (Sender: TObject);

begin

FormSearchData.Show;

FormJournal.Hide;

end;

procedure TFormJournal. N6Click (Sender: TObject);

begin

FormSearchPodrazd.Show;

FormJournal.Hide;

end;

end.

unit UnitNakl;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, CheckLst, ComCtrls, ExtCtrls, DB, ADODB, Grids,

DBGrids;

type

TFormNakl = class (TForm)

Panel1: TPanel;

Panel2: TPanel;

Label1: TLabel;

Edit1: TEdit;

Label2: TLabel;

DateTimePicker1: TDateTimePicker;

GroupBox1: TGroupBox;

Label3: TLabel;

ComboBox1: TComboBox;

Label4: TLabel;

ComboBox2: TComboBox;

Label5: TLabel;

ComboBox3: TComboBox;

Panel3: TPanel;

ADOQuery1: TADOQuery;

Label7: TLabel;

ComboBox5: TComboBox;

ADOTableIzd: TADOTable;

ADOTableShip: TADOTable;

ADOQuery2: TADOQuery;

ADOQuery3: TADOQuery;

CheckListBox1: TCheckListBox;

Panel4: TPanel;

procedure FormActivate (Sender: TObject);

procedure Panel3Click (Sender: TObject);

procedure ComboBox5Click (Sender: TObject);

procedure ComboBox3Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

FormNakl: TFormNakl;

implementation

uses UnitJournal;

{$R *.dfm}

procedure TFormNakl. FormActivate (Sender: TObject);

begin

FormJournal.ADOTablePodrazd.Open;

FormJournal.ADOTablePodrazd.First;

while FormJournal.ADOTablePodrazd.Eof=false do

begin

ComboBox1.Items.Add (FormJournal.ADOTablePodrazd.FieldByName ('PODRAZD_NAME').AsString);

ComboBox2.Items.Add (FormJournal.ADOTablePodrazd.FieldByName ('PODRAZD_NAME').AsString);

FormJournal.ADOTablePodrazd.Next;

end;

ADOTableShip.Open;

ADOTableShip.First;

while ADOTableShip. Eof=false do

begin

ComboBox5.Items.Add (ADOTableShip.FieldByName ('SHIP_ZAV_NOM').AsString);

ADOTableShip.Next;

end;

end;

procedure TFormNakl. Panel3Click (Sender: TObject);

begin

FormJournal.Show;

FormNakl.Close;

end;

procedure TFormNakl. ComboBox5Click (Sender: TObject);

begin

;

ADOQuery2.Parameters.ParamByName ('p').Value:=ComboBox5.Items.Strings[ComboBox5.ItemIndex];

ADOQuery2.Close;

ADOQuery2.Open;

ADOQuery2.First;

while ADOQuery2. Eof=false do

begin

ComboBox3.Items.Add (ADOQuery2.FieldByName ('IZD_OBOZN').AsString);

ADOQuery2.Next;

end;

end;

procedure TFormNakl. ComboBox3Click (Sender: TObject);

begin

ADOQuery3.Parameters.ParamByName ('q').Value:=ComboBox5.Items.Strings[ComboBox5.ItemIndex];

ADOQuery3.Parameters.ParamByName ('p').Value:=ComboBox3.Items.Strings[ComboBox5.ItemIndex];

ADOQuery3.Close;

ADOQuery3.Open;

ADOQuery3.First;

while ADOQuery3. Eof=false do

begin

CheckListBox1.Items.Add (ADOQuery3.FieldByName ('DEV_NAME').AsString+' '+ADOQuery3.FieldByName ('SHEM_NOM').AsString+' '+ADOQuery3.FieldByName ('SHEMA_NAIM').AsString);

ADOQuery3.Next;

end;

end;

end.

unit UnitPeriod;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ComCtrls, ExtCtrls, StdCtrls, ADODB, DB, RpDefine, RpCon,

RpConDS;

type

TFormPeriod = class (TForm)

Panel1: TPanel;

DateTimePicker1: TDateTimePicker;

DateTimePicker2: TDateTimePicker;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

ComboBox1: TComboBox;

ComboBox2: TComboBox;

Label5: TLabel;

ADOTable1: TADOTable;

ADOTable2: TADOTable;

ADOQuery1: TADOQuery;

Panel2: TPanel;

Panel3: TPanel;

procedure Panel3Click (Sender: TObject);

procedure FormActivate (Sender: TObject);

procedure Panel2Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

FormPeriod: TFormPeriod;

Podrazd: String;

implementation

uses UnitJournal, UnitAutor, UnitOtchPeriod;

{$R *.dfm}

procedure TFormPeriod. Panel3Click (Sender: TObject);

begin

FormPeriod.Close;

end;

procedure TFormPeriod. FormActivate (Sender: TObject);

begin

ADOTable1.Open;

ADOTable1.First;

while ADOTable1. Eof=false do

begin

ComboBox1.Items.Add (ADOTable1.FieldByName ('PODRAZD_NAME').AsString);

ADOTable1.Next;

end;

ADOTable2.Open;

ADOTable2.First;

while ADOTable2. Eof=false do

begin

ComboBox2.Items.Add (ADOTable2.FieldByName ('SHIP_ZAV_NOM').AsString);

ADOTable2.Next;

end;

Podrazd:=FormJournal.ComboBoxPodrazd.Text;

end;

procedure TFormPeriod. Panel2Click (Sender: TObject);

begin

ADOQuery1.Parameters.ParamByName ('p').Value:=ComboBox1.Text;

ADOQuery1.Parameters.ParamByName ('q').Value:=ComboBox2.Text;

ADOQuery1.Parameters.ParamByName ('s').Value:=DateTimePicker1.DateTime;

ADOQuery1.Parameters.ParamByName ('r').Value:=DateTimePicker2.DateTime;

FormOtchPer.QRLabel3.Caption:=ComboBox1.Text;

FormOtchPer.QRLabel14.Caption:=ComboBox2.Text;

FormOtchPer.QRLabel5.Caption:=DateToStr (DateTimePicker1.DateTime);

FormOtchPer.QRLabel7.Caption:=DateToStr (DateTimePicker2.DateTime);

FormOtchPer.QRLabel17.Caption:=Podrazd;

ADOQuery1.Close;

ADOQuery1.Open;

FormOtchPer.QuickRep1.Preview;

end;

end.

unit UnitRepair;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ExtCtrls, ADODB, DB, StdCtrls, Grids, DBGrids, Menus;

type

TFormRepair = class (TForm)

Panel1: TPanel;

Panel2: TPanel;

Panel3: TPanel;

Label1: TLabel;

Label2: TLabel;

ComboBox1: TComboBox;

Label3: TLabel;

ComboBox2: TComboBox;

ADOConnection1: TADOConnection;

ADOTable1: TADOTable;

ADOQuery1: TADOQuery;

Panel4: TPanel;

ADOQuery2: TADOQuery;

DataSource1: TDataSource;

DBGrid1: TDBGrid;

ADOQuery2DEV_NAME: TStringField;

ADOQuery2TYPE_DEVICE: TStringField;

ADOQuery2SHEMA_NAIM: TStringField;

ADOQuery2SHEM_NOM: TStringField;

ADOQuery2ZAV_NOM: TStringField;

ADOQuery2STATUS: TStringField;

ADOQuery2RASPOLOG: TStringField;

ADOQuery2MASS: TFloatField;

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

ADOQuery3: TADOQuery;

ADOQuery4: TADOQuery;

N4: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

N7: TMenuItem;

N8: TMenuItem;

N9: TMenuItem;

N10: TMenuItem;

procedure FormActivate (Sender: TObject);

procedure ComboBox1Click (Sender: TObject);

procedure Panel4Click (Sender: TObject);

procedure ComboBox2Click (Sender: TObject);

procedure N2Click (Sender: TObject);

procedure N3Click (Sender: TObject);

procedure N5Click (Sender: TObject);

procedure N10Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

UserSrlect: integer;

end;

var

FormRepair: TFormRepair;

implementation

uses UnitSelect, UnitRepSTat, UnitOtchMass, UnitApp;

{$R *.dfm}

procedure TFormRepair. FormActivate (Sender: TObject);

begin

ADOTable1.Open;

ComboBox1.Clear;

ADOTable1.First;

while ADOTable1. Eof=false do

begin

ComboBox1.Items.Add (ADOTable1.FieldByName ('SHIP_ZAV_NOM').AsString);

ADOTable1.Next;

end;

end;

procedure TFormRepair. ComboBox1Click (Sender: TObject);

begin

ComboBox2.Clear;

ADOQuery1.Close;

ADOQuery1.Parameters.ParamByName ('p').Value:=ComboBox1.Items.Strings[ComboBox1.ItemIndex];

ADOQuery1.Open;

ADOTable1.First;

while ADOQuery1. Eof=false do

begin

ComboBox2.Items.Add (ADOQuery1.FieldByName ('IZD_OBOZN').AsString);

ADOQuery1.Next;

end;

end;

procedure TFormRepair. Panel4Click (Sender: TObject);

begin

FormSelect.Show;

FormRepair.Close;

end;

procedure TFormRepair. ComboBox2Click (Sender: TObject);

begin

ADOQuery2.Close;

ADOQuery2.Parameters.ParamByName ('p').Value:=ComboBox1.Text;

ADOQuery2.Parameters.ParamByName ('q').Value:=ComboBox2.Items.Strings[ComboBox2.ItemIndex];

ADOQuery2.Open;

end;

procedure TFormRepair. N2Click (Sender: TObject);

begin

ADOQuery3.Active:=true;

ADOQuery3.Parameters[0]. Value:=ComboBox1.Text;

with FormRepStat do

begin

QuickRep1.DataSet:=ADOQuery3;

QRDBText1.DataSet:=ADOQuery3;

QRDBText1.DataField:='IZD_OBOZN';

QRDBText2.DataSet:=ADOQuery3;

QRDBText2.DataField:='SHEMA_NAIM';

QRDBText3.DataSet:=ADOQuery3;

QRDBText3.DataField:='TYPE_DEVICE';

QRDBText4.DataSet:=ADOQuery3;

QRDBText4.DataField:='DEV_NAME';

QRDBText5.DataSet:=ADOQuery3;

QRDBText5.DataField:='SHEM_NOM';

QRLabel2.Caption:='замены';

QRLabel4.Caption:=ComboBox1.Text;

end;

ADOQuery3.Close;

ADOQuery3.Open;

FormRepStat.QuickRep1.Preview;

end;

procedure TFormRepair. N3Click (Sender: TObject);

begin

ADOQuery4.Active:=true;

ADOQuery4.Parameters[0]. Value:=ComboBox1.Text;

with FormRepStat do

begin

QuickRep1.DataSet:=ADOQuery4;

QRDBText1.DataSet:=ADOQuery4;

QRDBText1.DataField:='IZD_OBOZN';

QRDBText2.DataSet:=ADOQuery4;

QRDBText2.DataField:='SHEMA_NAIM';

QRDBText3.DataSet:=ADOQuery4;

QRDBText3.DataField:='TYPE_DEVICE';

QRDBText4.DataSet:=ADOQuery4;

QRDBText4.DataField:='DEV_NAME';

QRDBText5.DataSet:=ADOQuery4;

QRDBText5.DataField:='SHEM_NOM';

QRLabel2.Caption:='ремонта';

QRLabel4.Caption:=ComboBox1.Text;

end;

ADOQuery4.Close;

ADOQuery4.Open;

FormRepStat.QuickRep1.Preview;

end;

procedure TFormRepair. N5Click (Sender: TObject);

begin

UserSrlect:=1;

FormAPP.Show;

FormRepair.Hide;

end;

procedure TFormRepair. N10Click (Sender: TObject);

begin

FormAPP.Show;

FormRepair.Hide;

end;

end.

unit UnitSearchDate;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, DB, Grids, DBGrids, ADODB, ComCtrls, StdCtrls, ExtCtrls;

type

TFormSearchData = class (TForm)

Panel1: TPanel;

Label1: TLabel;

DateTimePicker1: TDateTimePicker;

ADOQuery1: TADOQuery;

DataSource1: TDataSource;

DBGrid1: TDBGrid;

ADOQuery1NUMBER: TStringField;

ADOQuery1DATE_CREATE: TDateTimeField;

ADOQuery1PODRAZD_NAME: TStringField;

ADOQuery1IZD_NAIM: TStringField;

ADOQuery1DEV_NAME: TStringField;

ADOQuery1SHEM_NOM: TStringField;

ADOQuery1SHIP_ZAV_NOM: TStringField;

Panel2: TPanel;

Panel3: TPanel;

Panel4: TPanel;

Label2: TLabel;

procedure Panel3Click (Sender: TObject);

procedure Panel4Click (Sender: TObject);

procedure FormActivate (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

FormSearchData: TFormSearchData;

implementation

uses UnitJournal;

{$R *.dfm}

procedure TFormSearchData. Panel3Click (Sender: TObject);

begin

FormJournal.Show;

FormSearchData.Close;

end;

procedure TFormSearchData. Panel4Click (Sender: TObject);

begin

ADOQuery1.Close;

ADOQuery1.Parameters.ParamByName ('p').Value:=DateTimePicker1.DateTime;

ADOQuery1.Open;

end;

procedure TFormSearchData. FormActivate (Sender: TObject);

begin

Label2.Caption:=FormJournal.ComboBoxPodrazd.Text;

end;

end.

unit UnitSearchPodrazd;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, ExtCtrls, DB, Grids, DBGrids, ADODB;

type

TFormSearchPodrazd = class (TForm)

Panel1: TPanel;

Panel2: TPanel;

Label1: TLabel;

Panel3: TPanel;

ComboBox1: TComboBox;

ADOQuery1: TADOQuery;

DataSource1: TDataSource;

DBGrid1: TDBGrid;

ADOQuery1NUMBER: TStringField;

ADOQuery1DATE_CREATE: TDateTimeField;

ADOQuery1DEV_NAME: TStringField;

ADOQuery1SHEM_NOM: TStringField;

ADOQuery1IZD_OBOZN: TStringField;

ADOQuery1SHIP_ZAV_NOM: TStringField;

procedure FormActivate (Sender: TObject);

procedure Panel3Click (Sender: TObject);

procedure ComboBox1Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

FormSearchPodrazd: TFormSearchPodrazd;

implementation

uses UnitJournal;

{$R *.dfm}

procedure TFormSearchPodrazd. FormActivate (Sender: TObject);

begin

Label1.Caption:='Накладные, поступившие в '+FormJournal.ComboBoxPodrazd.Text+' из';

ComboBox1.Items := FormJournal.ComboBoxPodrazd.Items;

end;

procedure TFormSearchPodrazd. Panel3Click (Sender: TObject);

begin

FormJournal.Show;

FormSearchPodrazd.Close;

end;

procedure TFormSearchPodrazd. ComboBox1Click (Sender: TObject);

begin

ADOQuery1.Close;

ADOQuery1.Parameters.ParamByName ('p').Value:=ComboBox1.Items.Strings[ComboBox1.ItemIndex];

ADOQuery1.Open;

end;

end.

unit UnitSprav;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ComCtrls, ExtCtrls, DB, ADODB, StdCtrls, DBCtrls, Menus;

type

TFormSprav = class (TForm)

Panel1: TPanel;

Panel2: TPanel;

Panel3: TPanel;

ADOTable1: TADOTable;

GroupBox1: TGroupBox;

Label1: TLabel;

ComboBox1: TComboBox;

GroupBox2: TGroupBox;

Label2: TLabel;

ComboBox2: TComboBox;

ADOQuery1: TADOQuery;

Label3: TLabel;

Edit1: TEdit;

Label4: TLabel;

Edit2: TEdit;

ADOQuery2: TADOQuery;

Label5: TLabel;

ComboBox3: TComboBox;

ADOQuery3: TADOQuery;

GroupBox3: TGroupBox;

ADOTable2: TADOTable;

Edit3: TEdit;

Label6: TLabel;

Label8: TLabel;

ComboBox4: TComboBox;

ADOQuery4: TADOQuery;

ListBox1: TListBox;

GroupBox4: TGroupBox;

Label7: TLabel;

ADOQuery5: TADOQuery;

ADOQuery6: TADOQuery;

Label9: TLabel;

Edit4: TEdit;

Label10: TLabel;

Edit5: TEdit;

Label11: TLabel;

Label12: TLabel;

Edit6: TEdit;

Label13: TLabel;

Edit7: TEdit;

Edit8: TEdit;

MainMenu1: TMainMenu;

N1: TMenuItem;

N501: TMenuItem;

N502: TMenuItem;

ADOQuery7: TADOQuery;

ADOQuery8: TADOQuery;

procedure Panel3Click (Sender: TObject);

procedure FormShow (Sender: TObject);

procedure ComboBox1Click (Sender: TObject);

procedure ComboBox2Click (Sender: TObject);

procedure ComboBox3Click (Sender: TObject);

procedure ComboBox4Click (Sender: TObject);

procedure ListBox1Click (Sender: TObject);

procedure N502Click (Sender: TObject);

procedure N501Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

FormSprav: TFormSprav;

i: integer;

implementation

uses UnitAutor, UnitSelect, UnitOtchMass;

{$R *.dfm}

procedure TFormSprav. Panel3Click (Sender: TObject);

begin

Application.Terminate;

end;

procedure TFormSprav. FormShow (Sender: TObject);

begin

ComboBox1.Clear;

ADOTable1.Active:=true;

ADOTable1.First;

while ADOTable1. Eof=false do

begin

ComboBox1.Items.Add (ADOTable1.Fields[1]. AsString);

ADOTable1.Next;

end;

end;

procedure TFormSprav. ComboBox1Click (Sender: TObject);

begin

ComboBox2.Clear;

ADOQuery1.Active:=true;

ADOQuery1.Parameters[0]. Value:= ComboBox1. Items[ComboBox1.ItemIndex];

ADOQuery1.Close;

ADOQuery1.Open;

while ADOQuery1. Eof = false do

begin

ComboBox2.Items.Add (ADOQuery1.Fields[0]. AsString);

ADOQuery1.Next;

end;

end;

procedure TFormSprav. ComboBox2Click (Sender: TObject);

begin

ADOQuery2.Active:=true;

ADOQuery2.Parameters[0]. Value:=ComboBox2.Items[ComboBox2.ItemIndex];

ADOQuery2.Close;

ADOQuery2.Open;

Edit1.Text:=ADOQuery2.Fields[0]. AsString;

Edit2.Text:=ADOQuery2.Fields[1]. AsString;

ADOQuery3.Active:=true;

ADOQuery3.Parameters[0]. Value:=ComboBox2.Items[ComboBox2.ItemIndex];

ADOQuery3.Close;

ADOQuery3.Open;

ADOQuery3.First;

while ADOQuery3. Eof=false do

begin

ComboBox3.Items.Add (ADOQuery3.Fields[0]. AsString);

ADOQuery3.Next;

end;

end;

procedure TFormSprav. ComboBox3Click (Sender: TObject);

begin

ComboBox4.Clear;

ADOTable2.Active:=true;

ADOTable2.Locate ('IZD_OBOZN', ComboBox3. Items[ComboBox3.ItemIndex],[]);

Edit3.Text:=ADOTable2.Fields[1]. AsString;

ADOQuery4.Active:=true;

ADOQuery4.Parameters[0]. Value:=ComboBox3.Items[ComboBox3.ItemIndex];

ADOQuery4.Close;

ADOQuery4.Open;

ADOQuery4.First;

while ADOQuery4. Eof=false do

begin

ComboBox4.Items.Add (ADOQuery4.Fields[0]. AsString);

ADOQuery4.Next;

end;

end;

procedure TFormSprav. ComboBox4Click (Sender: TObject);

begin

ListBox1.Clear;

ADOQuery5.Active:=true;

ADOQuery5.Parameters[0]. Value:=ComboBox4.Items[ComboBox4.ItemIndex];

ADOQuery5.Close;

ADOQuery5.Open;

ADOQuery5.First;

while ADOQuery5. Eof=false do

begin

ListBox1.Items.Add (ADOQuery5.Fields[0]. AsString+' '+ADOQuery5.Fields[1]. AsString);

ADOQuery5.Next;

end;

end;

procedure TFormSprav. ListBox1Click (Sender: TObject);

begin

ADOQuery5.RecNo:=ListBox1.ItemIndex+1;

ADOQuery6.Active:=true;

ADOQuery6.Parameters[0]. Value:=ADOQuery5.Fields[2].AsInteger;

ADOQuery6.Close;

ADOQuery6.Open;

Edit4.Text:=ADOQuery6.Fields[0]. AsString;

Edit5.Text:=ADOQuery6.Fields[1]. AsString;

Edit6.Text:=ADOQuery6.Fields[3]. AsString;

Edit7.Text:=ADOQuery6.Fields[4]. AsString;

Edit8.Text:=ADOQuery6.Fields[2]. AsString;

end;

procedure TFormSprav. N502Click (Sender: TObject);

begin

ADOQuery7.Active:=true;

ADOQuery7.Parameters[0]. Value:=ComboBox2.Text;

with FormOtchMass do

begin

QuickRep1.DataSet:=ADOQuery7;

QRDBText1.DataSet:=ADOQuery7;

QRDBText1.DataField:='IZD_OBOZN';

QRDBText2.DataSet:=ADOQuery7;

QRDBText2.DataField:='SHEMA_NAIM';

QRDBText3.DataSet:=ADOQuery7;

QRDBText3.DataField:='TYPE_DEVICE';

QRDBText4.DataSet:=ADOQuery7;

QRDBText4.DataField:='DEV_NAME';

QRDBText5.DataSet:=ADOQuery7;

QRDBText5.DataField:='SHEM_NOM';

QRDBText6.DataSet:=ADOQuery7;

QRDBText6.DataField:='MASS';

QRLabel2.Caption:='менее';

QRLabel5.Caption:=ComboBox2.Text;

QRExpr2.Expression:='SUM (MASS)';

end;

ADOQuery7.Close;

ADOQuery7.Open;

FormOtchMass.QuickRep1.Preview;

end;

procedure TFormSprav. N501Click (Sender: TObject);

begin

ADOQuery8.Active:=true;

ADOQuery8.Parameters[0]. Value:=ComboBox2.Text;

with FormOtchMass do

begin

QuickRep1.DataSet:=ADOQuery8;

QRDBText1.DataSet:=ADOQuery8;

QRDBText1.DataField:='IZD_OBOZN';

QRDBText2.DataSet:=ADOQuery8;

QRDBText2.DataField:='SHEMA_NAIM';

QRDBText3.DataSet:=ADOQuery8;

QRDBText3.DataField:='TYPE_DEVICE';

QRDBText4.DataSet:=ADOQuery8;

QRDBText4.DataField:='DEV_NAME';

QRDBText5.DataSet:=ADOQuery8;

QRDBText5.DataField:='SHEM_NOM';

QRDBText6.DataSet:=ADOQuery8;

QRDBText6.DataField:='MASS';

QRLabel2.Caption:='более';

QRLabel5.Caption:=ComboBox2.Text;

QRExpr2.Expression:='SUM (MASS)';

end;

ADOQuery8.Close;

ADOQuery8.Open;

FormOtchMass.QuickRep1.Preview;

end;

end.

unit UnitViborIzd;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ExtCtrls, DB, ADODB, StdCtrls;

type

TFormViborIzd = class (TForm)

Panel1: TPanel;

ComboBox1: TComboBox;

Label1: TLabel;

ComboBox2: TComboBox;

Label2: TLabel;

ADOTable1: TADOTable;

Panel2: TPanel;

Panel3: TPanel;

ADOQuery1: TADOQuery;

Label3: TLabel;

ADOQuery2: TADOQuery;

procedure FormActivate (Sender: TObject);

procedure Panel3Click (Sender: TObject);

procedure ComboBox1Click (Sender: TObject);

procedure Panel2Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

FormViborIzd: TFormViborIzd;

Podrazd: String;

implementation

uses UnitJournal, UnitOtchIZdelie;

{$R *.dfm}

procedure TFormViborIzd. FormActivate (Sender: TObject);

begin

ADOTable1.Open;

ADOTable1.First;

while ADOTable1. Eof=false do

begin

ComboBox1.Items.Add (ADOTable1.FieldByName ('SHIP_ZAV_NOM').AsString);

ADOTable1.Next;

end;

Podrazd:=FormJournal.ComboBoxPodrazd.Text;

Label3.Caption:=Podrazd;

end;

procedure TFormViborIzd. Panel3Click (Sender: TObject);

begin

FormViborIzd.Close;

end;

procedure TFormViborIzd. ComboBox1Click (Sender: TObject);

begin

ADOQuery1.Parameters.ParamByName ('p').Value:=ComboBox1.Text;

ADOQuery1.Close;

ADOQuery1.Open;

AdoQuery1.First;

while ADOQuery1. Eof=false do

begin

ComboBox2.Items.Add (ADOQuery1.FieldByName ('IZD_OBOZN').AsString);

ADOQuery1.Next;

end;

end;

procedure TFormViborIzd. Panel2Click (Sender: TObject);

begin

ADOQuery2.Close;

ADOQuery2.Parameters.ParamByName ('p').Value:=ComboBox1.Text;

ADOQuery2.Parameters.ParamByName ('q').Value:=ComboBox2.Text;

FormIZDOTCH.QRLabel2.Caption:=Podrazd;

FormIZDOTCH.QRLabel4.Caption:=ComboBox2.Text;

FormIZDOTCH.QRLabel6.Caption:=ComboBox1.Text;

ADOQuery2.Open;

FormIZDOTCH.QuickRep1.Preview;

end;

end.