Реферат: Автоматизированная информационная система Учет экономической деятельности мукомольного цеха

Содержание:

Список сокращений ………………………….………………………………….3

Введение …………………………………………………………………………4

1. Анализ деятельности малых производственных предприятий.

1.1. Структура АИС…………….…………...…………………………………6

1.2. Функциональная схема подсистемы «Учет деятельности малых производственных цехов»………………………………...…………………..10

2. Основные принципы создания БД.

2.1. Требования, которым должна удовлетворять организация БД………..13

2.1.1.Установление многосторонних связей………………………….....13

2.1.2. Производительность………………………………………………..13

2.1.3. Минимальные затраты………………………………………….….14

2.1.4. Минимальная избыточность……………………………………….14

2.1.5. Возможность поиска……………………………………………….14

2.1.6. Целостность…………………………………………………………14

2.1.7. Безопасность и секретность…………………………………..……15

2.1.8. Связь с прошлым……………………………………………….…..15

2.1.9. Связь с будущим……………………………………………………15

2.1.10. Простота использования……………………….…………………16

2.2. Основы построения банков данных……………………………………..16

2.3. Язык SQL как стандартный язык БД………………………………...…..19

2.3.1. Язык SQL………………………………………………………..…..19

2.3.2. Достоинства SQL………………………………………………...…21

2.4. Архитектуры БД…………………………………………………………..25

2.5. Проблема проектирования БД……………………………………….…..29

3. Среда Delphi как средство для разработки СУБД.

3.1. Программный продукт Delphi………………………………………..…..31

3.2. Высокопроизводительный компилятор в машинный код…………...…33

3.3. Мощный объектно-ориентированный язык…………………………….34

3.4. Объектно-ориентированная модель программных компонент…….….35

3.5. Библиотека визуальных компонент………………………………….….36

3.6. Формы, модули и метод разработки «Two-Way Tools»……………..….39

3.7. Масштабируемые средства для построения БД……………………..….40

3.8. Настраиваемая среда разработчика…………………………………..….43

3.9. Незначительные требования к аппаратным и программным

средствам……………………………………………………………………….45

4.Описание программы.

4.1.Структура хранения информации……………………………………..….46

4.2. Структура БД………………………………………………………….…..46

4.3. Интерфейс программы……………………………………………………53

4.4. Экранные формы………………………………………………………….54

4.5. Руководство пользователя……………………………………….……….55

5. Безопасность и экологичность проекта.

5.1. Анализ основных опасностей и вредных факторов…………………….61

5.1.1. Комплекс мер по охране труда оператора ПЭВМ………………..61

5.1.1.1. Шум и вибрация…………………………………………....63

5.1.1.2. Планировка рабочего места…………………………….....63

5.1.1.3. Освещение………………………………………………….65

5.1.1.4. Статическое электричество………………………….…….65

5.1.1.5. Излучение……………………………………………….….66

5.1.1.6. Пожарная безопасность на РМ………………………...….66

5.1.2. Производственные шумы и вибрация……………………………..66

5.2. Расчёт уровня звукового давления………………………………..……..67

5.3. Расчёт искусственного освещения в операторной ЭВМ………...……..68

6. Организационно-экономическая часть проекта.

6.1. Организация разработки программного продукта……………………...71

6.1.1 Состав и структура проекта…………………………………….….71

6.1.2 Новизна и сложность разработки…………………………….……72

6.1.3 Перечень работ и стадии их выполнения……………………...….73

6.1.4 Трудоемкость выполняемых работ…………………………….….75

6.1.5 Планирование разработки и внедрения………………………..….75

6.1.6 Расчет и оптимизация параметров сетевого графика…………….77

6.2. Стоимость программного продукта……………………………………..82

6.2.1 Затраты на создание программного продукта………………….…82

6.2.2 Цена программного продукта………………………………….…..82

6.3. Оценка ожидаемого экономического эффекта……………………...…..86

6.3.1 Выбор метода расчета……………………………………………...86

6.3.2 Сведения о базовом и внедряемом вариантах……………………86

6.3.3 Капитальные затраты……………………………………………....86

6.3.4 Текущие затраты……………………………………………...…….87

6.3.5 Расчет экономического эффекта…………………………………..88

Заключение...………………………………………………………………….….89

Список литературы…………………………………………………………...….90

СПИСОК СОКРАЩЕНИЙ

АБД – администратор БД;

АИС – автоматизированная информационная система;

АРМ – автоматизированное рабочее место;

АСУ – автоматизированные системы управления;

АСУ П – АСУ предприятия;

АСУ ТП – АСУ технологических процессов;

БД — база данных;

ГОСТ – государственный стандарт;

ПАЗ – противоаварийная защита;

ПТК – программно-технический комплекс;

ПЛК – программно-логический контроллер;

ФЗП – фонд заработной платы;

п/с – подсистема;

п/ф – полуфабрикат;

СтП – стандарт предприятия;

СУБД — система управления базами данных;

ТУ – технические условия;

ТЭП – технико-экономические показатели;

ЯОД – язык описания данных;

Введение

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

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

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

Современные СУБД обеспечивают:

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

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

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

Для разработки АИС «Учёт деятельности малых производственных предприятий» была выбрана интегрированная среда разработки Delphi 5 для WINDOWS – приложений. АИС «Учёт деятельности малых производственных предприятий» предназначена предоставлять оперативную информацию для АРМ Руководства, подготавливать информацию для дальнейшего анализа, снижать объёмы бумажного документооборота и д.р.

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

ГЛАВА 1. Анализ деятельности малых производственных предприятий.

1.1. Структура АИС.

Рассмотрим структуру АИС малого производственного предприятия и ее взаимосвязи с другими системами.


Рис.1.1. Группы АИС.

При рассмотрении АИС будем использовать восемь групп АИС (рис.1.1), в соответствии со структурой предприятия.

Взаимосвязи АИС «Основное производство и контроль качества»:

Основное производство и контроль качества – одна из важнейших подсистем АСУ промышленного предприятия. В этой подсистеме ведутся все первичные документы по основной производственной деятельности и создается отчётная информация, с которой работают другие подсистемы. Подсистема выполняет сразу несколько функций: Планирование производства, Учёт производства, Контроль качества производства и Анализ. П/с «Основное производство и контроль качества» обменивается информацией со многими подразделениями предприятия.

Взаимосвязи внутри АИС «Основное производство и контроль качества» представлены на рис.1.2.


Рис. 1.2. Взаимосвязи внутри АИС «Основное производство и контроль качества».

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

Обмен информацией с п/с «Финансовый учёт» идет по налогам (план и факт выплат), договорным обязательствам, затратам, планируемому и фактическому производству.

При расчёте себестоимости продукции и учёте производства, используется информация о затратах на вспомогательные ресурсы, поступающая из п/с «Учёт вспомогательного производства». Это сметы затрат, планы ремонтов, планы строительства.

При расчёте выполнения плана производства, учитывается информация о движении ресурсов, поступающая из этой же п/с.

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

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

П/с «Учет персонала» передает в п/с «Основное производство и контроль качества» информацию о сотрудниках и данные по плановому ФЗП. Эти данные участвуют в расчете себестоимости продукции.

Вся отчётность п/с «Основное производство и контроль качества» передается в п/с «Управление и анализ» для проведения дальнейшего анализа и планирования, в т.ч. стратегического.

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

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

П/с «Учёт деятельности производственных цехов» состоит из подсистем отображённых на рис.1.3.


Рис.1.3. П/с «Учёт деятельности производственных цехов».

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

П/с «Планирование и учет ТЭП» связана большей частью с п/с «Технологический контроль производства». Из п/с «Технологический контроль производства» передаются ТЭП, нормы расхода ресурсов по производству, потребности в ресурсах, план и факт потерь в производстве. Из п/с «Учет деятельности производственных цехов» передается отчетность по производству (ежесуточная, ежемесячная). В п/с «Материальный учёт сырья» передается информация о плане производства. С п/с «Контроль качества» происходит обмен данными по смете содержания.

П/с «Материальный учет сырья» передает плановую и фактическую информацию о поставках сырья и отгрузке продукции организациям-поставщикам.

П/с «Технологический контроль производства» передает в п/с «Планирование и учёт ТЭП» технические показатели, нормы расхода ресурсов по производству, потребности в ресурсах, план и факт потерь в производстве, а в п/с «Учет деятельности производственных цехов» — нормы расхода ресурсов и потерь, регламенты производства. Из п/с «Контроль качества» в п/с «Технический контроль производства» поступает отчетность о качестве, из п/с «Статистический учет качества» — результаты статистического анализа качества, из п/с «Учет деятельности производственных цехов» — отчетность по фактическому производству.

П/с «Оперативный контроль за деятельностью предприятия» получает из п/с «Учет деятельности производственных цехов» оперативную информацию по производству, а из п/с «Контроль качества» — оперативную информацию о качестве.

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

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

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

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

П/с «Учет деятельности производственных цехов» делится на следующие функциональные модули (рис.1.4.):

Учет движения сырья, полуфабрикатов, продукции.

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

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

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

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


Рис.1.4.Функциональная схема п/с «Учет деятельности

производственных цехов».

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

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

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

Первая подсистема выполняется на микропроцессорном программно-технологическом комплексе (ПТК) с сетевой структурой.

Подсистема автоматической противоаварийной защиты (ПАЗ) выполняется на высоконадёжном микропроцессорном программно-логическом контроллере (ПЛК) с горячим резервом входов/выходов, процессора, блока памяти.

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

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

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

• об объемах поступления сырья на установки

• об объемах переработки на установках

• об объемах сжега на установке (для некоторых установок)

• об объемах цеховой отгрузки (например, отгрузка кокса)

• о расходе топлива по установкам

• о расходе топлива на нужды ТЭЦ

• о потерях по установкам

• о выработках газа (для некоторых установок)

• об остатках продукции в цехах (например, остатки кокса)

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

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

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

Создание АИС «Учет деятельности малых производственных предприятий» открывает большие возможности перед пользователями и руководством.

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


ГЛАВА 2. Основные принципы создания баз данных.

2.1. Требования, которым должна удовлетворять организация базы данных.

Изучением этого вопроса долгое время занимались различные группы людей в учреждениях, использующих ЭВМ, в правитель­ственных комиссиях, на вычислительных центрах коллективного пользования. Комитет CODASYL опубликовал отчеты на эту тему (CODASYL—организация, разработавшая язык КОБОЛ). Организации пользователей IBM SHARE и GUIDE в своем отчете сформулировали требования к системе управления базами дан­ных. Организация ACiM (Association for Computing Machi­nery) также занималась изучением этого вопроса.

Ниже перечислены основные требования к организации базы данных.

2.1.1. Установление многосторонних связей .

Различным программистам требуются различные логические файлы. Эти файлы получаются из одной и той же совокупности данных. Между элементами запоминаемых данных могут суще­ствовать различные связи. Некоторые базы данных будут содер­жать сложные переплетения взаимосвязей. Метод организации данных должен быть таким, чтобы обеспечивалась возможность удобного представления этих взаимосвязей и быстрого согласова­ния вносимых в них изменений. Система управления базами дан­ных должна обеспечивать возможность получения требуемых логи­ческих файлов из имеющихся данных и существующих между ними связей. Необходимо, чтобы существовало хотя бы небольшое с ходство между представлением логического файла в прикладной программе и способом физического хранения данных.[7, 10, 11].

2.1.2. Производительность .

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

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

2.1.3. Минимальные затраты .

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

2.1.4. Минимальная избыточность .

В системах обработки, существовавших до использования си­стем управления базами данных, информационные фонды облада­ли очень высоким уровнем избыточности. Большинство ленточных библиотек содержало большое количество избыточных данных. Даже при использовании баз данных по мере возрастания инфор­мации, объединяемой в интегрированные базы данных, потен­циальная возможность появления избыточных данных постепенно увеличивается. Избыточные данные дороги в том смысле, что они занимают больше памяти, чем это необходи­мо, и требуют более одной операции обновления. Целью организации базы данных должно быть уничтожение избыточных данных там, где это выго дно, и контроль за теми про­тиворечиями, которые вызываются наличие м избыточных данных.[7, 10, 11].

2.1.5. Возможности поиска .

Пользователь базы данных может обращаться к ней с самыми различными вопросами по поводу хранимых данных. В большин­ стве современных коммерческих приложений типы запросов предо­пределены, и физическая организация данных разрабатывается для их обработки с требуемой скоростью. Возросшие требования к системам заключаются в обеспечении обработки таких запро­сов или формирования таких ответов, которые заранее не запла­нированы. [7, 10, 11].

2.1.6. Целостность .

Если база данных содержит данные, используемые многими пользователями, очень важно, чтобы элементы данных и связи между ними не разрушались. Необходимо учитывать возможность возникновения ошибок и различного рода случайных сбоев. Хра­нение данных, их обновление, процедуры включения данных должны быть такими, чтобы система в случае возникновения сбоев могла восстанавливать данные без потерь. Необходимо, чтобы вы­числительная система гарантировала целостность хранимых в ней данных.[7, 10, 11].

2.1.7. Безопасность и секретность .

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

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

Секретность определяют как право отдельных лиц или орга­низаций определять, когда, как и какое количество соответствую­щей информации может быть передано другим лицам или орга­низациям. [7, 10, 11].

2.1.8. Связь с прошлым .

Организации, которые в течение какого-то времени эксплуати­руют системы обработки данных, затрачивают значительные сред­ства на написание программ, процедур и организацию хранения данных. В том случае, когда фирма начинает использовать на вычислительной установке новое программное обеспечение управ­л ения базами данных, очень важно, чтобы при этом она могла работать с уже существующими на этой установке программами, обрабатываемые данные можно было бы соответствующим образом преобразовывать. Такое условие требует наличия програм­м ной и информационной совместимости, и ее отсутствие может стать основным сдерживающим фактором при переходе к новым системам управления базами данных. Важно, однако, чтобы про­блема связи с прошлым не сдерживала развитие средств управ­ления базами данных. [7, 10, 11].

2.1.9. Связь с будущим .

Особенно важной представляется связь с будущим. В будущем данные и среда их хранения изменятся по многим направлениям. Любая коммерческая организация со временем претерпевает из­менения. Особенно дорогими эти изменения оказываются для пользователей системами обработки данных. Огромные затраты, которые требуются для реализации самых простых изменений, сильно тормозят развитие этих систем. Эти затраты расходуются на преобразование данных, перезапись и отладку прикладных программ, явившихся результатом внесения изменений. Со време­нем число прикладных программ в организации растет, и поэтому перспектива перезаписи всех этих программ кажется нереальной. Одна из самых важных задач при разработке баз данных—запла­нировать базу данных таким образом, чтобы изменения ее можно было выполнять без модификации прикладных программ.[7, 10, 11].

2.1.10. Простота использования .

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

Интерфейс программного обеспечения должен быть ориентирован на конечного пользователя и учитывать возможность того, что пользователь не имеет необходимой базы знаний по теории баз данных. [7, 10, 11].

2.2. Основы построения банков данных.

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

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

Для обеспечения гибкости использования данных необходимо учитывать два аспекта разработки БД:

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

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

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

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

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

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

В каждой СУБД прежде всего есть трансляторы или интерпретаторы с языка описания данных (ЯОД) и с языка манипулирования данными (ЯМД), единые для всей базы данных (БД).

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

ЯМД представлен системой команд манипулирования данными. В нем могут быть, например, следующие команды:

1. Произвести выборку из базы данных конкретного данного, значение которого удовлетворяет заданным условиям;

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

Системы управления базой данных подразделяют на две группы в зависимости от способа реализации ЯМД:

1. СУБД с включающим языком;

2. СУБД с базовым языком.

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

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

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

Этот штат должен включать лиц, имеющих опыт работы в таких областях, как программное обеспечение СУБД, операционные системы, техническое обеспечение ЭВМ, прикладное программирование, системное программирование.

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

Функции АБД следующие:

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

— координировать все действия по проектированию, реализации и ведения БД;

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

— решать вопросы, связанные с расширением БД в связи с изменением границ ПО;

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

— контролировать избыточность и противоречивость данных, их достоверность;

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

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

2.3.Язык SQL как стандартный язык баз данных.

Стремительный рост популярности SQL является одной из самых важных тенденций в современной компьютерной промышленности. За несколько последних лет SQL стал единственным языком баз данных. На сегодняшний день SQL поддерживают свыше ста СУБД, работающих как на персональных компьютерах, так и на больших ЭВМ. Был принят, а затем дополнен официальный международный стандарт на SQL. Язык SQL является важным звеном в архитектуре систем управления базами данных, выпускаемых всеми ведущими поставщиками программных продуктов, и служит стратегическим направлением разработок компании Microsoft в области баз данных. Зародившись в результате выполнения второстепенного исследовательского проекта компании IBM, SQL сегодня широко известен и в качестве мощного рыночного фактора.[13]

2.3.1. Язык SQL .

SQL является инструментом, предназначенным для обработки и чтения данных, содержащихся в компьютерной базе данных. SQL — это сокращенное название структурированного языка запросов (Structured Query Language ). Как следует из названия, SQL является языком программирования, который применяется для организации взаимодействия пользователя с базой данных. На самом деле SQL работает только с базами данных реляционного типа. Согласно принятой схеме, в вычислительной системе имеется база данных, в которой хранится важная информация. Если вычислительная система относится к сфере бизнеса, то в базе данных может храниться информация о материальных ценностях, выпускаемой продукции, объемах продаж и зарплате. В базе данных на персональном компьютере может храниться информация о выписанных чеках, телефонах и адресах или информация, извлеченная из более крупной вычислительной системы. Компьютерная программа, которая управляет базой данных, называется системой управления базой данных , или СУБД .

Если пользователю необходимо прочитать данные из базы данных, он запрашивает их у СУБД с помощью SQL. СУБД обрабатывает запрос, находит требуемые данные и посылает их пользователю. Процесс запрашивания данных и получения результата называется запросом к базе данных: отсюда и название — структурированный язык запросов .

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

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

· Чтение данных . SQL дает пользователю или приложению возможность читать из базы данных содержащиеся в ней данные и пользоваться ими.

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

· Управление доступом . С помощью SQL можно ограничить возможности пользователя по чтению и изменению данных и защитить их от несанкционированного доступа.

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

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

Таким образом, SQL является достаточно мощным языком для взаимодействия с СУБД.

Во-вторых, SQL — это не полноценный компьютерный язык типа COBOL, FORTRAN или С. В SQL нет оператора IF для проверки условий, нет оператора GOTO для организации переходов и нет операторов DO или FOR для создания циклов. SQL является подъязыком баз данных, в который входит около тридцати операторов, предназначенных для управления базами данных. Операторы SQL встраиваются в базовый язык, например COBOL, FORTRAN или С, и дают возможность получать доступ к базам данных. Кроме того, из такого языка, как С, операторы SQL можно посылать СУБД в явном виде, используя интерфейс вызовов функций.

Наконец, SQL — это слабо структурированный язык, особенно по сравнению с такими сильно структурированными языками, как С или Pascal. Операторы SQL напоминают английские предложения и содержат «слова-пустышки», не влияющие на смысл оператора, но облегчающие его чтение. В SQL почти нет нелогичностей, к тому же имеется ряд специальных правил, предотвращающих создание операторов SQL, которые выглядят как абсолютно правильные, но не имеют смысла.

Несмотря на не совсем точное название, SQL на сегодняшний день является единственным стандартным языком для работы с реляционными базами данных. SQL — это достаточно мощный и в то же время относительно легкий для изучения язык.[13, 8].

2.3.2. Достоинства SQL .

SQL — это легкий для понимания язык и в то же время универсальное программное средство управления данными.

Успех языку SQL принесли следующие его особенности:

• независимость от конкретных СУБД;

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

• наличие стандартов;

• одобрение компанией IBM (СУБД DB2);

• поддержка со стороны компании Microsoft (протокол ODBC);

• реляционная основа;

• высокоуровневая структура, напоминающая английский язык;

• возможность выполнения специальных интерактивных запросов:

• обеспечение программного доступа к базам данных;

• возможность различного представления данных;

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

• возможность динамического определения данных;

• поддержка архитектуры клиент/сервер.

Все перечисленные выше факторы явились причиной того, что SQL стал стандартным инструментом для управления данными на персональных компьютерах, мини-компьютерах и больших ЭВМ. Ниже эти факторы рассмотрены более подробно.[13, 8, 17].

Независимость от конкретных СУБД

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

Переносимость с одной вычислительной системы на другие

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

Стандарты языка SQL

Официальный стандарт языка SQL был опубликован Американским институтом национальных стандартов (American National Standards Institute — ANSI) и Международной организацией по стандартам (International Standards Organization — ISO) в 1986 году и значительно расширен в 1992 году. Кроме того, SQL является федеральным стандартом США по обработке информации (FIPS — Federal Information Processing Standard) и, следовательно, соответствие ему является одним из основных требований, содержащихся в больших правительственных контрактах, относящихся к области вычислительной техники. В Европе стандарт X/OPEN для переносимой среды программирования на основе операционной системы UNIX включает в себя SQL в качестве стандарта для доступа к базам данных. SQL Access Group — консорциум поставщиков компьютерного оборудования и баз данных — определил для SQL стандартный интерфейс вызовов функций, который является основой протокола ODBC компании Microsoft и входит также в стандарт X/OPEN. Эти стандарты служат как бы официальной печатью, одобряющей SQL, и они ускорили завоевание им рынка.[13, 8, 17].

Одобрение SQL компанией IBM (СУБД DB2)

SQL был придуман научными сотрудниками компании IBM и широко используется ею во множестве пакетов программного обеспечения. Подтверждением этому служит флагманская СУБД DB2 компании IBM. Все основные семейства компьютеров компании IBM поддерживают SQL: система PS/2 для персональных компьютеров, система среднего уровня AS/400. система RS/6000 на базе UNIX, а также операционные системы MVS и VM больших ЭВМ. Широкая поддержка SQL фирмой IBM ускорила его признание и еще в самом начале возникновения и развития рынка баз данных явилась своего рода недвусмысленным указанием для других поставщиков баз данных и программных систем, в каком направлении необходимо двигаться.

Протокол ODBC и компания Microsoft

Компания Microsoft рассматривает доступ к базам данных как важную часть своей операционной системы Windows. Стандартом этой компании по обеспечению доступа к базам данных является ODBC (Open Database Connectivity — взаимодействие с открытыми базами данных) — программный интерфейс, основанный на SQL. Протокол ODBC поддерживается наиболее распространенными приложениями Windows (электронными таблицами, текстовыми процессорами, базами данных и т.п.), разработанными как самой компанией Microsoft, так и другими ведущими поставщиками. Поддержка ODBC обеспечивается всеми ведущими реляционными базами данных. Кроме того, ODBC опирается на стандарты, одобренные консорциумом поставщиков SQL Access Group, что делает ODBC как стандартом де-факто компании Microsoft, так и стандартом, независимым от конкретных СУБД.[13, 8, 17].

Реляционная основа

SQL является языком реляционных баз данных, поэтому он стал популярным тогда, когда популярной стала реляционная модель представления данных. Табличная структура реляционной базы данных интуитивно понятна пользователям, поэтому язык SQL является простым и легким для изучения. Реляционная модель имеет солидный теоретический фундамент, на котором были основаны эволюция и реализация реляционных баз данных. На волне популярности, вызванной успехом реляционной модели, SQL стал единственным языком для реляционных баз данных.[13, 8, 17].

Высокоуровневая структура, напоминающая английский язык

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

Интерактивные запросы

SQL является языком интерактивных запросов, который обеспечивает пользователям немедленный доступ к данным. С помощью SQL пользователь может в интерактивном режиме получить ответы на самые сложные запросы в считанные минуты или секунды, тогда как программисту потребовались бы дни или недели, чтобы написать для пользователя соответствующую программу. Из-за того, что SQL допускает немедленные запросы, данные становятся более доступными и могут помочь в принятии решений, делая их более обоснованными.[13, 8, 17].

Программный доступ к базе данных

Программисты пользуются языком SQL, чтобы писать приложения, в которых содержатся обращения к базам данных. Одни и те же операторы SQL используются как для интерактивного, так и для программного доступа, поэтому части программ, содержащие обращения к базе данных, можно вначале тестировать в интерактивном режиме, а затем встраивать в программу. В традиционных базах данных для программного доступа используются одни программные средства, а для выполнения немедленных запросов — другие, без какой либо связи между этими двумя режимами доступа.[13, 8, 17].

Различные представления данных

С помощью SQL создатель базы может сделать так, что различные пользователи базы данных будут видеть различные представления её структуры и содержимого. Например, базу данных можно спроектировать таким образом, что каждый пользователь будет видеть только данные, относящиеся к его подразделению или торговому региону. Кроме того, данные из различных частей базы данных могут быть скомбинированы и представлены пользователю в виде одной простой таблицы. Следовательно, представления можно использовать для усиления защиты базы данных и ее настройки под конкретные требования отдельных пользователей.[13, 8, 17].

Полноценный язык для работы с базами данных

Первоначально SQL был задуман как язык интерактивных запросов, но сейчас он вышел далеко за рамки чтения данных. SQL является полноценным и логичным языком, предназначенным для создания базы данных, управления ее защитой, изменения ее содержимого, чтения данных и совместного использования данных несколькими пользователями, работающими параллельно. Приемы, освоенные при изучении одного раздела языка, могут затем применяться в других командах, что повышает производительность работы пользователей.[13, 8, 17].

Динамическое определение данных

С помощью SQL можно динамически изменять и расширять структуру базы данных даже в то время, когда пользователи обращаются к ее содержимому. Это большое преимущество перед языками статического определения данных, которые запрещают доступ к базе данных во время изменения ее структуры. Таким образом, SQL обеспечивает максимальную гибкость, так как дает базе данных возможность адаптироваться к изменяющимся требованиям, не прерывая работу приложения, выполняющегося в реальном масштабе времени.[13, 8, 17].

Архитектура клиент/сервер

SQL — естественное средство для реализации приложений клиент/сервер. В этой роли SQL служит связующим звеном между клиентской системой, взаимодействующей с пользователем, и серверной системой, управляющей базой данных, позволяя каждой системе сосредоточиться на выполнении своих функций. Кроме того, SQL позволяет персональным компьютерам функционировать в качестве клиентов по отношению к сетевым серверам или более крупным базам данных, установленным на больших ЭВМ; это позволяет получать доступ к корпоративным данным из приложений, работающих на персональных компьютерах.[13, 8, 17].

2.4. Архитектуры баз данных .

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

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

Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу.

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

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

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

Местоположение Ядра БД и баз данных зависит от используемой архитектуры. Имеется три разновидности архитектур баз данных:

• локальные базы данных и архитектура «файл-сервер»;

• архитектура «клиент-сервер»;

• многозвенная (трехзвенная N-tier или multi-tier) архитектура.

Использование той или иной архитектуры накладывает сильный отпечаток на общую идеологию работы приложения, на программный код в приложении, на состав компонентов для работы с БД, используемых в приложении (прежде всего это касается невизуальных компонентов).[4, 15].

Локальные базы данных и архитектура «файл-сервер»

При работе с локальными базами данных сами БД расположены на том же компьютере, что и приложения, осуществляющие доступ к ним. Работа с БД происходит в однопользовательском режиме. Ядро БД распложено на компьютере пользователя. Приложение ответственно за поддержание целостности БД и за выполнение запросов к БД. Общая схема однопользовательской архитектуры показана на рис.2.2.

При работе в архитектуре «файл-сервер» БД и приложение расположены на файловом сервере сети (например, Novell NetWare). Возможна много­пользовательская работа с одной и той же БД, когда каждый пользователь со своего компьютера запускает приложение, расположенное на сетевом сервере.


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

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

Кардинальных различий с точки зрения архитектуры между одно­пользовательской архитектурой и архитектурой «файл-сервер» нет. И в том и в ином случае в качестве СУБД применяются так называемые «персональные» (или «локальные») СУБД такие как Paradox, dBase и пр. Сама база данных в этом случае представляет собой набор таблиц, индексных файлов, файлов полей комментариев (мемо-полей) и пр., хранящихся в одном каталоге на диске в виде отдельных файлов.[4].

Удаленные базы данных и архитектура " клиент-сервер"

Архитектура «файл-сервер» неэффективна, по крайней мере, в двух отношениях:

1. При выполнении запроса к базе данных, расположенной на файловом сервере, в действительности происходит запрос к локальной копии данных на компьютере пользователя. Поэтому перед выполнением запроса данные в локальной копии обновляются из реальной БД. Данные обновляются в полном объеме. Так, если таблица БД состоит из 1000 записей, а для выполнения запроса (например, выдать сумму премий за октябрь в отделе Y) реально нужно 10 записей, все равно перегоняются все 1000 записей. Таким образом, не нужно иметь слишком много пользователей и запросов от них, чтобы серьезно ''забить" сеть, что, конечно же, не может не сказаться на ее быстродействии.

2. Обеспечение целостности БД производится из приложений. Это потенциальный источник ошибок, нарушающих физическую и логическую целостность БД, поскольку различные приложения могут производить контроль целостности БД по-разному, взаимоисключающими способами, или не проводить такого контроля вовсе. Намного эффективнее управлять БД из единого места и по единым законам, нежели из разных приложений и по потенциально разным законам (все зависит от того, как написано приложение). Поэтому безопасность при работе в архитектуре «файл-сервер» невысока и всегда присутствует элемент неопределенности. Секретность и конфиденциальность при работе с БД в архитектуре «файл-сервер» обеспечить также тяжело — любой, кто имеет доступ в каталог сетевого сервера, где хранится БД, может изменять таблицы БД любым образом, копировать их, заменять и т.д. [4].

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

Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД. SQL-сервер – это специальная программа, управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети «путешествуют» только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в мин имальное время с наименьшими накладными расходами.

Все это повышает быстродействие системы и снижает время ожидания результата запроса.

При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, исполь­зующих эту БД. Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый SQL-серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно. Таким образом, функциями приложения-клиента являются:

1. посылка к серверу запросов;

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

3. реализация интерфейса пользователя.

SQL-сервер — это программа, расположенная на компьютере сетевого сервера. SQL-сервер должен быть загружен на момент принятия запроса от клиента. Функциями сервера БД являются:

1. прием запросов от приложений-клиентов, интерпретация запросов, выполнение запросов в БД, отправка результата выполнения запроса приложению-клиенту;

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

3. хранение бизнес-правил, часто используемых запросов в уже интерпретированном виде;

4. обеспечение одновременно безопасной и отказоустойчивой многопользовательской работы с одними и теми же данными. В архитектуре «клиент-сервер» используются так называемые «удаленные» (или «промышленные») СУБД. Промышленными они называются из-за того. что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. Локальные СУБД предназначены для однопользовательской работы или для обеспечения работы информационных систем, рассчитанных на небольшие группы пользователей.[4, 15, 11].

К разрядку промышленных СУБД принадлежат: Oracle, Gupta, Informix, Sybase, MS SQL Server, DB2, InterBase и ряд других.

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

Кроме этого, существует отдельная категория сотрудников, называемых администраторами баз данных. Как правило, это администраторы сервера, разработчики БД или пользователи, имеющие привилегии на создание, изменение, настройку оптимальных параметров отдельных серверных БД. Администраторы БД также отвечают за предоставление прав на разно­уровневый доступ к сопровождаемым ими БД для других пользователей.[4, 15, 11].

Использование архитектуры «клиент-сервер»:

1. резко уменьшает сетевой трафик:

2. понижает сложность приложений-клиентов (поскольку тем уже нет необходимости обеспечивать целостность и безопасность БД и следить за параметрами многопользовательской работы с БД);

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

4. повышает надежность БД, ее целостность, безопасность и секретность.

2.5. Проблемы проектирования БД.

Объединение программного обеспечения СУБД, прикладного программного обеспечения, реализованной базы данных, операционной системы (ОС) и аппаратных средств в одну систему для информационного обслуживания пользователей известно под названием система баз данных. Хотя технология применения СУБД, ОС и прикладных программ, хорошо известна, необходимо уделить внимание эффективному использованию этих средств с различными структурами баз данных. Так, главная проблема, стоящая перед администратором БД, заключается не в том, как использовать ее наиболее эффективно. Эта проблема может быть сформулирована в виде нескольких вопросов, возникающих в течение жизненного цикла приложения:

1. Что представляют собой требования пользователей и в какой форме они могут быть выражены?

2. Как эти требования могут быть преобразованы в эффективную структуру базы данных?

3. Как часто и каким образом структура базы данных должна перестраиваться в соответствии с новыми и/или изменяющимися требованиями?

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

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

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

ГЛАВА 3. Среда Delphi как средство для разработки СУБД .

3.1. Программный продукт Delphi .

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

Среди большого разнообразия продуктов для разработки приложений Delphi занимает одно из ведущих мест. Delphi отдают предпочтение разработчики с разным стажем, привычками, профессиональными интересами. С помощью Delphi написано колоссальное количество приложений, десятки фирм и тысячи программистов-одиночек разрабатывают для Delphi дополнительные компоненты.[4].

В основе такой общепризнанной популярности лежит тот факт, что Delphi, как никакая другая система программирования, удовлетворяет изложенным выше требованиям. Действительно, приложения с помощью Delphi разрабатываются быстро, причем взаимодействие разработчика с интерактивной средой Delphi не вызывает внутреннего отторжения, а наоборот, оставляет ощущение комфорта. Delphi-приложения эффективны, если разработчик соблюдает определенные правила (и часто — если не соблюдает). Эти приложения надежны и при эксплуатации обладают предсказуемым поведением.[4, 22].

Пакет Delphi — продолжение линии компиляторов языка Pascal корпорации Borland. Pascal как язык очень прост, а строгий контроль типов данных способствует раннему обнаружению ошибок и позволяет быстро создавать надежные и эффективные программы. Корпорация Borland постоянно обогащала язык. Когда-то в версию 4.0 были включены средства раздельной трансляции, позже, начиная с версии 5.5, появились объекты, а в состав шестой версии пакета вошла полноценная библиотека классов Turbo Vision, реализующая оконную систему в текстовом режиме работы видеоадаптера. Это был один из первых продуктов, содержавших интегрированную среду разработки программ.

В классе инструментальных средств для начинающих программистов продуктам компании Borland пришлось конкурировать со средой Visual Basic корпорации Microsoft, где вопросы интеграции и удобства работы были решены лучше. Когда в начале 70-х годов Н. Вирт опубликовал сообщение о Pascal, это был компактный, с небольшим количеством основных понятий и зарезервированных слов язык программирования, нацеленный на обучение студентов. Язык, на котором предстоит работать пользователю Delphi, отличается от исходного не только наличием множества новых понятий и конструкций, но и идейно: в нем вместо минимизации числа понятий и использования самых простых конструкций (что, безусловно, хорошо для обучения, но не всегда оправдано в практической работе), предпочтение отдается удобству работы профессионального пользователя. Как язык Turbo Pascal естественно сравнивать с его ближайшими конкурентами — многочисленными вариациями на тему языка Basic (в первую очередь с Visual Basic корпорации Microsoft) и с C++.[4, 6]. Я считаю, что Turbo Pascal существенно превосходит Basic за счет полноценного объектного подхода, включающего в себя развитые механизмы инкапсуляции, наследование и полиморфизм. Последняя версия языка, применяемая в Delphi, по своим возможностям приближается к C++. Из основных механизмов, присущих C++, отсутствует только множественное наследование. (Впрочем, этим красивым и мощным механизмом порождения новых классов пользуется лишь небольшая часть программистов, пишущих на С++.) Плюсы применения языка Pascal очевидны: с одной стороны, в отличие от Visual Basic, основанного на интерпретации промежуточного кода, для него имеется компилятор, генерирующий машинный код, что позволяет получать значительно более быстрые программы. С другой — в отличие от C++ синтаксис языка Pascal способствует построению очень быстрых компиляторов. [6].

Среда программирования напоминает пакет Visual Basic. В вашем распоряжении несколько отдельных окон: меню и инструментальные панели, Object Inspector (в котором можно видеть свойства объекта и связанные с ним события), окна визуального построителя интерфейсов (Visual User Interface Builder), Object Browser (позволяющее изучать иерархию классов и просматривать списки их полей, методов и свойств), окна управления проектом (Project Manager) и редактор.

Delphi содержит полноценный текстовый редактор типа Brief, назначения клавиш в котором соответствуют принятым в Windows стандартам, а глубина иерархии операций Undo неограниченна. Как это стало уже обязательным, реализовано цветовое выделение различных лексических элементов программы. Процесс построения приложения достаточно прост. Нужно выбрать форму (в понятие формы входят обычные, диалоговые, родительские и дочерние окна MDI), задать ее свойства и включить в нее необходимые компоненты (видимые и, если понадобится, неотображаемые): меню, инструментальные панели, строку состояния и т. п., задать их свойства и далее написать (с помощью редактора исходного кода) обработчики событий. Object Browser Окна типа Object Browser стали неотъемлемой частью систем программирования на объектно-ориентированных языках. Работа с ними становится возможной сразу после того, как вы скомпилировали приложение.

Projeсt Manager — это отдельное окно, где перечисляются модули и формы, составляющие проект. При каждом модуле указывается маршрут к каталогу, в котором находится исходный текст. Жирным шрифтом выделяются измененные, но еще не сохраненные части проекта. В верхней части окна имеется набор кнопок: добавить, удалить, показать исходный текст, показать форму, задать опции и синхронизировать содержимое окна с текстом файла проекта, т. е. с головной программой на языке Pascal.

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

Visual Component Library (VCL) Богатство палитры объектов для построения пользовательского интерфейса — один из ключевых факторов при выборе инструмента визуального программирования. При этом для пользователя имеет значение как число элементов, включенных непосредственно в среду, так и доступность элементов соответствующего формата на рынке. [4, 22].

3.2. Высокопроизводительный компилятор в машинный код .

Компиляторы языка Pascal компании Borland никогда не заставляли пользователя подолгу ждать результатов компиляции. Производители утверждают, что на сегодня данный компилятор — самый быстрый в мире. Компилятор, встроенный в Delphi позволяет обрабатывать 120 тыс. строк исходного текста в минуту на машине 486/33 или 350 тыс. — при использовании процессора Pentium/90. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL. Кроме того, Delphi обеспечивает быструю разработку без необходимости писать вставки на Си или ручного написания кода (хотя это возможно).

В смысле проектирования Delphi мало, чем отличается от проектирования в интерпретирующей среде, однако после выполнения компиляции мы получаем код, который исполняется в 10-20 раз быстрее, чем тоже самое, сделанное при помощи интерпретатора. Кроме того, компилятор компилятору рознь, в Delphi компиляция производится непосредственно в родной машинный код, в то время как существуют компиляторы, превращающие программу в так называемый p-код, который затем интерпретируется виртуальной p-машиной. Это не может не сказаться на фактическом быстродействии готового приложения.

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

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

3.3. Мощный объектно-ориентированный язык .

Совместимость с программами, созданными ранее средствами Borland Pascal, сохраняется, несмотря на то, что в язык внесены существенные изменения. Необходимость в некоторых усовершенствованиях давно ощущалась. Самое заметное из них — аппарат исключительных ситуаций, подобный тому, что имеется в C++, был первым реализован в компиляторах корпорации Borland. Не секрет, что при написании объектно-ориентированных программ, активно работающих с динамической памятью и другими ресурсами, немалую трудность представляет аккуратное освобождение этих ресурсов в случае возникновения нештатных ситуаций. Особенно это актуально для среды Windows, где число видов ресурсов довольно велико, а неряшливая работа с ними может быстро привести к зависанию всей системы. Предусмотренный в Delphi аппарат исключений максимально упрощает кодирование обработки нештатных ситуаций и освобождения ресурсов.

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

· введено понятие класса.

· реализованы методы классов, аналогичные статическим методам C++. Они оперируют не экземпляром класса, а самим классом.

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

· введена обработка исключительных ситуаций. В Delphi это устроено в стиле С++. Исключения представлены в виде объектов, содержащих специфическую информацию о соответствующей ошибке (тип и место- нахождение ошибки). Разработчик может оставить обработку ошибки, существовавшую по умолчанию, или написать свой собственный обработчик. Обработка исключений реализована в виде exception-handling blocks (также еще называется protected blocks ), которые устанавливаются ключевыми словами try и end. Существуют два типа таких блоков: try...except и try...finally .

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

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

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

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

Язык программирования Delphi базируется на Borland Object Pascal.

Кроме того, Delphi поддерживает такие низкоуровневые особенности, как подклассы элементов управления Windows, перекрытие цикла обработки сообщений Windows, использование встроенного ассемблера.[22].

3.4. Объектно-ориентированная модель программных компонент .

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

В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. На Delphi можно одинаково хорошо писать как приложения к корпоративным базам данных, так и, к примеру, игровые программы. Во многом это объясняется тем, что традиционно в среде Windows было достаточно сложно реализовывать пользовательский интерфейс. Событийная модель в Windows всегда была сложна для понимания и отладки. Но именно разработка интерфейса в Delphi является самой простой задачей для программиста.

Благодаря такой возможности приложения, изготовленные при помощи Delphi, работают надежно и устойчиво. Delphi поддерживает использование уже существующих объектов, включая DLL, написанные на С и С++, OLE сервера, VBX, объекты, созданные при помощи Delphi. Из готовых компонент работающие приложения собираются очень быстро. Кроме того, поскольку Delphi имеет полностью объектную ориентацию, разработчики могут создавать свои повторно используемые объекты для того, чтобы уменьшить затраты на разработку.

Delphi предлагает разработчикам — как в составе команды, так и индивидуальным — открытую архитектуру, позволяющую добавлять компоненты, где бы они ни были изготовлены, и оперировать этими вновь введенными компонентами в визуальном построителе. Разработчики могут добавлять CASE-инструменты, кодовые генераторы, а также авторские help’ы, доступные через меню Delphi. [22].

3.5. Библиотека визуальных компонент .

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

Этот костяк называется Visual Component Library (VCL). В VCL есть такие стандартные элементы управления, как строки редактирования, статические элементы управления, строки редактирования со списками, списки объектов. Еще имеются такие компоненты, которые ранее были доступны только в библиотеках третьих фирм: табличные элементы управления, закладки, многостраничные записные книжки. Все объекты разбиты на страницы по своей функциональности и представлены в палитре компонент .

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

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

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

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

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

TPopupMenu позволяет создавать всплывающие меню. Этот тип меню появляется по щелчку правой кнопки мыши на объекте, к которому привязано данное меню. У всех видимых объектов имеется свойство PopupMenu, где и указывается нужное меню. Создается PopupMenu аналогично главному меню.

TLabel служит для отображения текста на экране. Можно изменить шрифт и цвет метки, если дважды щелкнуть на свойство Font в Инспекторе Объектов. Это легко сделать и во время выполнения программы, написав всего одну строчку кода.

TEdit — стандартный управляющий элемент Windows для ввода. Он может быть использован для отображения короткого фрагмента текста и позволяет пользователю вводить текст во время выполнения программы.

TMemo — иная форма TEdit. Подразумевает работу с большими текстами. TMemo может переносить слова, сохранять в ClipBoard фрагменты текста и восстанавливать их, и другие основные функции редактора. TMemo имеет ограничения на объем текста в 32Кб, это составляет 10-20 страниц (есть подобные компоненты, где этот предел снят).

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

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

TRadioButton позволяет выбрать только одну опцию из нескольких.

TListBox нужен для показа прокручиваемого списка. Классический пример ListBox’а в среде Windows — выбор файла из списка в пункте меню File | Open многих приложений. Названия файлов или директорий и находятся в ListBox’е.

TComboBox во многом напоминает ListBox, за исключением того, что позволяет водить информацию в маленьком поле ввода сверху ListBox. Есть несколько типов ComboBox, но наиболее популярен спадающий вниз (drop-down combo box), который можно видеть внизу окна диалога выбора файла.

TScrollbar — полоса прокрутки, появляется автоматически в объектах редактирования, ListBox’ах при необходимости прокрутки текста для просмотра.

TGroupBox используется для визуальных целей и для указания Windows, каков порядок перемещения по компонентам на форме (при нажатии клавиши TAB).

TRadioGroup используется аналогично TGroupBox, для группировки объектов TRadioButton.

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

TBitBtn — кнопка вроде TButton, однако на ней можно разместить картинку (glyph). TBitBtn имеет несколько предопределенных типов (bkClose, bkOK и др), при выборе которых кнопка принимает соответствующий вид. Кроме того, нажатие кнопки на модальном окне приводит к закрытию окна с соответствующим модальным результатом.

TSpeedButton — кнопка для создания панели быстрого доступа к командам (SpeedBar). Пример — SpeedBar слева от Палитры Компонент в среде Delphi. Обычно на данную кнопку помещается только картинка (glyph).

TTabSet — горизонтальные закладки. Обычно используется вместе с TNoteBook для создания многостраничных окон. Название страниц можно задать в свойстве Tabs.

TNoteBook — используется для создания многостраничного диалога, на каждой странице располагается свой набор объектов. Используется совместно с TTabSet.

TTabbedNotebook — многостраничный диалог со встроенными закладками, в данном случае — закладки сверху.

TMaskEdit — аналог TEdit, но с возможностью форматированного ввода. Формат определяется в свойстве EditMask. В редакторе свойств для EditMask есть заготовки некоторых форматов: даты, валюты и т.п.

TOutline — используется для представления иерархических отношений связанных данных. Например — дерево директорий.

TStringGrid — служит для представления текстовых данных в виде таблицы. Доступ к каждому элементу таблицы происходит через свойство Cell.

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

TImage — отображает графическое изображение на форме. Воспринимает форматы BMP, ICO, WMF. Если картинку подключить во время дизайна программы, то она прикомпилируется к EXE файлу.

TShape — служит для отображения простейших графических объектов на форме: окружность, квадрат и т.п.

TBevel — элемент для рельефного оформления интерфейса.

THeader — элемент оформления для создания заголовков с изменяемыми размерами для таблиц.

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

TTimer — таймер, событие OnTimer периодически вызывается через промежуток времени, указанный в свойстве Interval. Период времени может составлять от 1 до 65535 мс.

TPaintBox — место для рисования. В обработчики событий, связанных с мышкой передаются относительные координаты мышки в TPaintBox, а не абсолютные в форме.

TFileListBox — специализированный ListBox, в котором отображаются файлы из указанной директории (св-во Directory). На названия файлов можно наложить маску, для этого служит св-во Mask. Кроме того, в св-ве FileEdit можно указать объект TEdit для редактирования маски.

TDirectoryListBox — специализированный ListBox, в котором отображается структура директорий текущего диска. В св-ве FileList можно указать TFileListBox, который будет автоматически отслеживать переход в другую директорию.

TDriveComboBox — специализированный ComboBox для выбора текущего диска. Имеет свойство DirList, в котором можно указать TDirectoryListBox, который будет отслеживать переход на другой диск.

TFilterComboBox — специализированный ComboBox для выбора маски имени файлов. Список масок определяется в свойстве Filter. В свойстве FileList указывается TFileListBox, на который устанавливается маска.

С помощью последних четырех компонент (TFileListBox, TDirectoryListBox, TDriveComboBox, TFilterComboBox) можно построить свой собственный диалог выбора файла, причем для этого не потребуется написать ни одной строчки кода.

TMediaPlayer — служит для управления мультимедийными устройствами (типа CD-ROM, MIDI и т.п.). Выполнен в виде панели управления с кнопками Play, Stop, Record и др. Для воспроизведения может понадобиться как соответствующее оборудование, так и программное обеспечение. Подключение устройств и установка ПО производится в среде Windows. Например, для воспроизведения видео, записанного в формате AVI, потребуется установить ПО MicroSoft Video (в Windows 3.0, 3.1, WFW 3.11).

TOLEContainer — контейнер, содержащий OLE объекты. Поддерживается OLE 2.02

TDDEClientConv,TDDEClientItem, TDDEServerConv, TDDEServerItem — 4 объекта для организации DDE. С помощью этих объектов можно построить приложение как DDE-сервер, так и DDE-клиент.

TChartFX — деловая графика. Компонент позволяет строить всевозможные графики и гистограммы.

3.6. Формы, модули и метод разработки «Two-Way Tools» .

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

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

Такая синхронизация и делает Delphi two-way-инструментом , обеспечивая полное соответствие между кодом и визуальным представлением. Как только добавляется новый объект или код, Delphi устанавливает “кодовую синхронизацию” между визуальными элементами и соответствующими им кодовыми представлениями.

Two-way tools однозначное соответствие между визуальным проектированием и классическим написанием текста программы Это означает, что разработчик всегда может видеть код, соответствующий тому, что он построил при помощи визуальных инструментов и наоборот.

Визуальный построитель интерфейсов (Visual User-interface builder) дает возможность быстро создавать клиент-серверные приложения визуально, просто выбирая компоненты из соответствующей палитры. В процессе построения приложения разработчик выбирает из палитры компонент, готовые компоненты как художник, делающий крупные мазки кистью. Еще до компиляции он видит результаты своей работы — после подключения к источнику данных их можно видеть отображенными на форме, можно перемещаться по данным, представлять их в том или ином виде.[4, 22].

3.7. Масштабируемые средства для построения баз данных .

Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре — процессоре баз данных Borland Database Engine (BDE). Его интерфейс с прикладными программами называется Integrated Database Application Programming Interface (IDAPI). В принципе, сейчас не различают эти два названия (BDE и IDAPI) и считают их синонимами. BDE позволяет осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных. Кроме BDE, Delphi позволяет осуществлять доступ к базам данных, используя технологию (и, соответственно, драйверы) Open DataBase Connectivity (ODBC) фирмы Microsoft. Но, как показывает практика, производительность систем с использованием BDE гораздо выше, чем оных при использовании ODBC. ODBC драйвера работают через специальный «ODBC socket», который позволяет встраивать их в BDE.

Все инструментальные средства баз данных Borland — Paradox, dBase, Database Desktop — используют BDE. Все особенности, имеющиеся в Paradox или dBase, “наследуются” BDE, и поэтому этими же особенностями обладает и Delphi.

Библиотека объектов содержит набор визуальных компонент, значительно упрощающих разработку приложений для СУБД с архитектурой клиент-сервер. Объекты инкапсулируют в себя нижний уровень — Borland Database Engine.

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

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

Таблицы сохраняются в базе данных. Некоторые СУБД сохраняют базу данных в виде нескольких отдельных файлов, представляющих собой таблицы (в основном, все локальные СУБД), в то время как другие состоят из одного файла, который содержит в себе все таблицы и индексы (InterBase). Например, таблицы dBase и Paradox всегда сохраняются в отдельных файлах на диске. Директорий, содержащий dBase .DBF файлы или Paradox .DB файлы, рассматривается как база данных. Другими словами, любой директорий, содержащий файлы в формате Paradox или dBase, рассматривается Delphi как единая база данных. Для переключения на другую базу данных нужно просто переключиться на другой директорий. InterBase сохраняет все таблицы в одном файле, имеющем расширение .GDB, поэтому этот файл и есть база данных InterBase.

Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в онлайновом режиме. Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (к примеру, небольшую систему учета медицинских карточек для одного компьютера), может использовать для хранения информации файлы формата .dbf (как в dBase или Clipper) или .db (Paradox). Если же он будет использовать локальный InterBase for Windows 4.0 (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер.

Масштабируемость на практике — одно и то же приложение можно использовать как для локального, так и для более серьезного клиент-серверного вариантов.[4, 22].

В состав пакета Delphi также входит множество утилит для работы и управления базами данных. Вот некоторые из них.

Database Desktop — это утилита, во многом похожая на Paradox, которая поставляется вместе с Delphi для интерактивной работы с таблицами различных форматов локальных баз данных — Paradox и dBase, а также SQL-серверных баз данных InterBase, Oracle, Informix, Sybase (с использованием SQL Links). Она позволяет создавать как структуру реляционных таблиц, так и всевозможные ограничения целостности таблиц, индексы, первичные ключи и внешние ключи.

WISQL (Windows Interactive SQL) — интерактивное средство посылки SQL-запросов к InterBase (в том числе и локальному InterBase), входящее в поставку Delphi, позволяет создавать таблицы — через посылку SQL-запросов.Database Desktop не обладает всеми возможностями по управлению SQL-серверными базами данных. Поэтому с помощью Database Desktop удобно создавать или локальные базы данных, или только простейшие SQL-серверные базы данных, состоящие из небольшого числа таблиц, не очень сильно связанных друг с другом. Если же необходимо создать базу данных, состоящую из большого числа таблиц, имеющих сложные взаимосвязи, можно воспользоваться языком SQL. Можно записать всю последовательность SQL-предложений в один так называемый скрипт и послать его на выполнение. Конкретные реализации языка SQL незначительно отличаются в различных SQL-серверах, однако базовые предложения остаются одинаковыми для всех реализаций. Практика показывает, что если нет необходимости создавать таблицы во время выполнения программы, то лучше воспользоваться WISQL.

InterBase — это система управления реляционными базами данных, поставляемая корпорацией BORLAND для построения приложений с архитектурой клиент-сервер произвольного масштаба: от сетевой среды небольшой рабочей группы с сервером под управлением Novell NetWare или Windows NT на базе IBM PC до информационных систем крупного предприятия на базе серверов IBM, Hewlett-Packard, SUN и т.п.

В пакет Delphi входит однопользовательская версия InterBase для Windows — Local InterBase. Используя Local InterBase можно создавать и отлаживать приложения, работающие с данными по схеме клиент-сервер, без подключения к настоящему серверу. В дальнейшем потребуется только перенастроить используемый псевдоним базы данных и программа будет работать с реальной базой без перекомпиляции. Кроме того, Local InterBase можно использовать в приложениях для работы с данными вместо таблиц Paradox.

Важной составной частью приложения является вывод данных на печать — получение отчета. В пакет Delphi входит средство для генерации и печати отчетов — ReportSmith . Вы можете объединить отчет с приложениями Delphi. Также, библиотека визуальных компонент Delphi включает специальный компонент TReport. В данном уроке показано, как использовать компоненту TRepor и рассмотрены основные принципы проектирования отчетов в ReportSmith.

Borland ReportSmith является инструментом для получения отчетов и интегрирован в среду Delphi. Отчет может быть добавлен к приложениям Delphi. Отчеты могут быть созданы для SQL БД или локальных БД и не требуют знания сложных команд БД. Интерфейс ReportSmith использует стандартные инструменты Windows типа tool bar, formatting ribbon, и «drag and drop». Если пользователь уже знаком с интерфейсом стандартных Windows-программ, типа Word for Windows или Quattro Pro for Windows, ему будет «знаком» и интерфейс ReportSmith. ReportSmith предлагает 4 типа отчетов: Табличный, Кросс-таблица(CrossTab), Форма(Form) и Наклейка(Label).

ReportSmith использует концепцию «живых данных», т.е. работа происходит с настоящими данными все время, а не только тогда, когда запускается просмотр (preview). Кроме этого, ReportSmith легко работает с чрезвычайно большими БД при помощи адаптивной технологии управления памятью. В ReportSmith можно управлять тем, где сохраняется результат выборки данных из БД: в локальный памяти клиентской PC, на жестком диске клиентской PC, или на сервере.

3.8. Настраиваемая среда разработчика .

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

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

Поскольку в Delphi программа строится визуальным образом, все эти компоненты имеют свое графическое представление в поле форм для того, чтобы можно было бы ими соответствующим образом оперировать. Но для работающей программы видимыми остаются только визуальные компоненты. Компоненты сгруппированы на страницах палитры по своим функциям. К примеру, компоненты, представляющие Windows «common dialogs» все размещены на странице палитры с названием «Dialogs» (рис.3.1.­­).

Рис.3.1. Страница палитры Delphi c названием «Dialogs».

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

В Delphi можно определить свою группу компонент и разместить ее на странице палитры, а если возникнет необходимость, перегруппировать компоненты или удалить неиспользуемые.

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

· Графический отладчик . Delphi обладает мощнейшим, встроенным в редактор графическим отладчиком, позволяющим находить и устранять ошибки в коде. Можно установить точки останова, проверить и изменить переменные, при помощи пошагового выполнения в точности понять поведение программы. Если же требуются возможности более тонкой отладки, можно использовать отдельно доступный Turbo Debugger, проверив ассемблерные инструкции и регистры процессора.

· Инспектор объектов . Этот инструмент представляет из себя отдельное окно, где вы можете в период проектирования программы устанавливать значения свойств и событий объектов (Properties & Events).

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

· Навигатор объектов. Показывает библиотеку доступных объектов и осуществляет навигацию по приложению. Можно посмотреть иерархию объектов, перекомпилированные модули в библиотеке, список глобальных имен вашего кода.

· Дизайнер меню. Можно создавать меню, сохранить созданные в виде шаблонов и затем использовать в их в любом приложении.

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

1. Эксперт форм, работающих с базами данных.

2. Эксперт стилей и шаблонов приложений.

3. Эксперт шаблонов форм.

В состав RAD Pack входит эксперт для преобразования ресурсов, изготовленных в Borland Pascal 7.0, в формы Delphi. Уже появились эксперты, облегчающие построение DLL и даже написание собственных экспертов:

· Интерактивная обучающая система. Позволяет более полно освоить Delphi. Она являются не просто системой подсказок, а показывает возможности Delphi на самой среде разработчика.

3.9. Незначительные требования к аппаратным и программным средствам .

Delphi это высокопроизводительный инструмент создания приложений. Версия Delphi 2.0, которая появилась в начале 1996 года, включает полный 32-разрядный компилятор для использования в Windows 95 или в Windows NT.

Для запуска Delphi требуется 386 компьютер с 4MB памяти. Более подходящей машиной будет 486DX 66MHz с 8MB ОЗУ.

ГЛАВА 4. Описание программы.

4.1. Структура хранения информации.

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

Существует два способа организации информационных массивов:

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

В наше время при создании АСУ требуется качественно новый подход к организации данных. К организации данных в АСУ предъявляют два основных требования:

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

— Максимальная возможная независимость от прикладных программ.

Выполнение этих требований привело к созданию единой (для всех задач системы) базы данных БД. Преимущества БД в АСУ состоят в следующем:

а) Централизованное управление всеми ресурсами, синхронная поддержка данных для всех приложений.

б) Отсутствие проблемы избыточности данных вследствие их интеграции.

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

г) Унификация средств организации данных и независимость прикладных программ от организации данных. Исходя из приведенных доводов, была выбрана организация базы данных.

4.2. Структура БД.

При проектировании БД необходимо решить вопрос о наиболее эффективной структуре данных. Основные цели, которые при этом преследуются:

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

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

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

Главная задача данной работы заключается в необходимости автоматизации производственных цехов, а также возможность предоставления оперативной информации по установкам, за определенный период или за конкретные дни для АРМ Руководства. Для её решения была разработана АИС, в состав которой входят пока девять таблиц (файлов, имеющих расширение dbf).

Структура таблицы «Переработка, выработка»( Per _ Vur . dbf )

Описание поля

Поле

Тип

Ширина поля

Дата ввода

DATA_V

D

Код движения

KOD_DV

N

1 0

Код установки

KOD_USTN

N

3 0

Код продукции

KOD_PROD

С

10

Количество

KOLVO

N

15 3

Индекс: P_V.NTX по DTOS (DATA_V) + STR(KOD_USTN, 3)

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

Структура таблицы «Отгрузка, сжег»( Otg _ Sjog . dbf )

Индекс: O_S.NTX по DTOS (DATA_V) + STR(KOD_USTN, 3)

Описание поля

Поле

Тип

Ширина поля

Дата ввода

DATA_V

D

Код расхода

KOD_RAS

N

1 0

Код установки

KOD_USTN

N

3 0

Код продукции

KOD_PROD

С

10

Количество

KOLVO

N

15 3

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

Структура таблицы «Расход топлива»( RAS _ TOP . dbf )

Описание поля

Поле

Тип

Ширина поля

Дата ввод

DATA_V

D

Код установки

KOD_USTN

N

3 0

Количество пропана

KOL_PROPAN

N

7 3

Количество мазута

KOL_MAZYT

N

7 3

Количество сухого

газа

KOL_CUXGAZ

N

7 3

Количество летучих газов

KOL_LETGA

N

7 3

Количество вакуумный дистиллят

KOL_VAKDIS

N

7 3

Индекс: R_T.NTX по DTOS (DATA_V) + STR(KOD_USTN, 3)

Интерес представляют данные о расходе топлива по каждой установке.

Структура таблицы «Потери при переработке»(Ро t _ Per . dbf )

Индекс: P_P.NTX по DTOS (DATA_V) + STR(KOD_USTN, 3)

Описание поля

Поле

Тип

Ширина поля

Дата ввода

DATA_V

D

Код установки

KOD_USTN

N

3 0

Код продукции

KOD_PROD

С

10

Потери фактические

POT_PHACT

N

15 3

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

Структура таблицы «Расход реагентов»( RAS _ Reag . dbf )

Индекс: R_R.NTX по DTOS (DATA_V) + STR(KOD_USTN, 3)

Описание поля

Поле

Тип

Ширина поля

Дата ввода

DATA_V

D

Код установки

KOD_USTN

N

3 0

Код продукции

KOD_PROD

С

10

Количество

KOLVO

N

15 3

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

Структура таблицы «Тип движения»( DV _ RAS . dbf )

Описание поля

Поле

Тип

Ширина поля

Код движения

KOD_DV

N

1 0

Тип движения

TYPE_DV

С

1 0

Индекс: Т_D.NTX по KOD_DV

В данной таблице находятся данные по типу движения на всех установках.

Структура таблицы «Тип расхода»( Typ _ R . dbf )

Индекс: T_R.NTX по KOD_RAS

Описание поля

Поле

Тип

Ширина поля

Код расхода

KOD_RAS

N

1 0

Тип расхода

TYPE_RAS

С

20

В этой таблице находятся данные по типу расхода на всех установках.

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

Структура таблицы «Справочник установок»(SРR USTN . dbf )

Индексы:

SPR_UST1.NTX по KOD_USTN

SPR_UST2.NTX по STR(KOD_PODR,2,0)+STR(KOD_USTN,3,0)

SPR_UST3.NTX по NAME_USTN

Описание поля

Поле

Тип

Ширина поля

Код подразделения

KOD_PODR

N

2 0

Код установки

KOD_USTN

N

3 0

Наименование установки

NAME_USTN

С

30

Краткое наименование установки, отделения

NCUT_USTN

С

10

Начальник установки

IDENT

N

6 0

Номер телефона в цеху начальника установки

NOM_TEL

С

10

Номер счета

NOM_SCHET

С

6

Код затрат

KOD_ZATR

С

1

Мат. Ответственное лицо

MAT_OTV

N

6 0

Номер тел. Материал. отв. лица в цехе

MAT_TEL

С

10

Признак включения установки в расчет для ПЭО

FOR_PLANO

L

1 0

Признак включения установки для показа зарплаты

FOR_ОTIZ

L

1 0

Ссылка на справочник департаментов

ID_DEP

N

6 0

SPR_ UST4.NTX по KOD_ZATR

Данные по установкам находятся в этой таблице.


Структура таблицы «Справочник марок продукции»(Р R M . dbf )

Индексы:

PR_M1 .NTX по KOD_PRОD

PR_M2.NTX по NAME_PROD

Описание поля

Поле

Тип

Ширина поля

Код вида

К_VID

С

2

Код семейства

К_SEM

С

3

Код продукции

KOD_PROD

С

10

Название продукции

NAME_ PROD

С

30

Качество, техн. условия

ТЕХ_USL

С

20

Цена за единицу продукции

CENA_T

N

14 2

Единица измерения

ED_IZM

N

2 0

Вес вагона продукции

STAT_NAG

N

7 3

Прейскурант

N_POS_PRE

С

5

Индекс бензина

IND_BENZ

N

1 0

Плотность бензина

PLOTN

N

7 4

Номер счета

NOM_SCHET

С

4

Таможенная пошлина

ТАМ

N

5 2

Аварийная карта

AVKAR

С

3

Краткое наименование

CUT_PROD

С

15

Температура

ТЕМ

N

3 0

Тип пломбы

PLOMBA

С

1

PR_ M3.NTX по К_VID+K_SEM+KOD_PROD

Данные о свойствах и показателей продукта находятся в этой таблице.


Таблица 1. Схема взаимосвязи таблиц.


4.3. Интерфейс программы.

Программа разрабатывалась в среде Borland DELPHI 5.0 компании Inprise Corporation. Выбор данной среды обусловлен следующими причинами:

1. Данная среда является ведущей RAD-системой (средой быстрой разработки приложений) на рынке благодаря следующим особенностям:

1.1. Визуальная среда разработки.

1.2. Полное использование возможностей среды WIN32.

1.3. Гибкость языка Object Pascal .

2. Наибольший опыт разработчика работы именно в этой среде.

3. Пожелание заказчика (в перспективе возможна доработка этого приложения силами других разработчиков).

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

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

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

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

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

Приложение состоит из одной или нескольких форм.

Каждая форма может:

1. Хранить и использовать свои «собственные » не визуальные компоненты;

2. Использовать не визуальные компоненты, хранящиеся в одном или нескольких модулях данных;

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

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

4.4. Экранные формы.

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

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

• frMainForm — основная форма программы. Содержит основное меню. Вызывает другие окна.

• frAddPerVir — форма ввода параметров по переработке и выработке.

• frAddOtgCjog — форма ввода параметров по отгрузке.

• frAddRasTop- форма ввода параметров по расходу топлива.

• frReport — отчёт по переработке и выработке.

Структура взаимодействия окон приведена на рис. 4.1.

Рис.4.1. Структура приложения

4.5. Руководство пользователя.

При запуске программы открывается главная форма (рис.4.2.).


Рис.4.2. Основное окно программы.

В ней располагается главное меню приложения содержащее следующие пункты:

• Информация по цехам

1. Переработка и выработка по установкам

2. Отгрузка, сжег

3. Расход топлива

4. Потери при переработке

5. Расход реагентов

• Информация по ТЭЦ

1. Расход топлива на ТЭЦ

• Сводки и отчёты

1. Деятельность установок
2. Сводка по расходу топлива

3. Отчёт о расходе реагентов

4. Справка о выходах н/п

5. Расчёт потерь

• О программе

1. Выход

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

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

Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом ( primary key ) таблицы и часто являются числами. Если одна таблица содержит первичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом ( foreign key ) .

Вот пример запроса для отображения данных о переработке и выработке по установкам:

SELECT Per_vur.DATA_V, Dv_ras.TYPE_DV, Spr_ustn.NCUT_USTN,

Pr_m.NAME_PROD, Per_vur.KOLVO, Per_vur.KOD_DV,

Per_vur.KOD_USTN, Per_vur.KOD_PROD

FROM "..\word\Per_Vur.DBF" Per_vur

INNER JOIN "..\word\Dv_Ras.DBF" Dv_ras

ON (Per_vur.KOD_DV=Dv_ras.KOD_DV)

INNER JOIN "..\word\Spr_ustn.DBF" Spr_ustn

ON (Per_vur.KOD_USTN = Spr_ustn.KOD_USTN)

INNER JOIN "..\word\Pr_m.DBF" Pr_m

ON (Per_vur.KOD_PROD = Pr_m.KOD_PROD)

где SELECT, FROM, WHERE, INNER JOIN — операторы языка SQL;

Per__Vur.DBF, Dv_Ras.DBF, Spr_ustn.DBF, Pr_m.DBF — название таблиц;

DAТA_V, TYPE_DV, NCUT_USTN — название полей соответствующих таблиц.

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

Предложение FROM, задает имена таблиц к которым делается запрос.

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

Еще на главной форме существуют кнопки управления:

Добавить — Для добавления новой записи в соответствующую таблицу

Удалить — Для удаления выбранной записи из таблицы

Фильтр — Для выполнения поиска необходимой записи в соответствующей таблице

Выход — Закрытие приложения

При нажатии на кнопку «Добавить» открывается следующая форма (рис. 4.3.)

Здесь мы можем установить необходимые нам значения для новой записи. Данные для выпадающих списков формируются из существующих таблиц (справочников). В данном, конкретном случае из таблицы «Установки», «Продукция» и «Тип движения».


Рис.4.3. Окно ввода новой записи.

Вот фрагмент кода отображающий в выпадающем списке записи справочника «Тип движения»:

Table1. Active :=true;

with Table1 do

begin

ComboBox1.Items.Clear;

first;

while not EOF do

begin

СomboBox1.Items.Add(FieldByName('TYPE_DV').AsString);

Next;

end;

first;

ComboBox1.Text:=FieldByName('TYPE_DV').AsString;

end;

При нажатии кнопки «Ввод» в таблице создаётся новая запись. Соответственно «Отмена» — означает не производить изменения в таблице. При нажатии на кнопку «Удалить», из таблицы удаляется соответствующая запись.


Рис.4.4. Фильтр

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

Чтобы устранить эти трудности необходимо нажать на кнопку «Фильтр» (рис.4.4.).

В выпадающем списке выбрать нужное нам значение записи и отметить галочкой (рис.4.5.).


Рис.4.5.

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

Выбрав пункт меню «Сводки и отчёты» мы можем создать отчет по данным соответствующих таблиц.

Отчет создается с помощью элемента QuickReport. Когда приложение запущено и выбран, к примеру, пункт «Отчёт о деятельности предприятия», отчёт будет выглядеть так (рис.4.6.).


Рис.4.6.

ГЛАВА 5. Безопасность и экологичность проекта.

Введение

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

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

5.1. Анализ основных опасностей и вредных факторов.

5.1.1. Комплекс мер по охране труда оператора ПЭВМ.

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

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

На качество и безопасность работ операторов влияет огромное число факторов. Работа большинства сотрудников сопряжена с умственным трудом. Так, операторы ЭВМ в течение рабочего дня должны воспринимать огромный объём информации и точно на неё реагировать. Значительное умственное напряжение и другие нагрузки приводят к изменению у работников функционального состояния центральной нервной системы нервно-мышечного аппарата рук. Для предупреждения переутомления и повышения трудоспособности необходимы и правильный режим труда и отдыха, и оптимальные микроклиматические условия, и правильная организация рабочего места. Нерациональная конструкция рабочего места вызывает необходимость поддержания вынужденной рабочей позы. Длительный дискомфорт вызывает повышенное напряжение мышц и обуславливает развитие общего утомления и снижение работоспособности. При длительной работе за дисплеем у операторов отличается выраженное напряжение зрительного аппарата с появлением жалоб на неудовлетворительность работой, нарушение сна, усталости и болезненных ощущений в области глаз, в пояснице и др. Работа с дисплеем связана с малой подвижностью и действием небольшой группы мышц, что может привести к профессиональному заболеванию – остеохондрозу. Необходимо проводить физические разминки во время перерыва. Для снятия психоэмоционального напряжения дополнительные перерывы в соответствии с санитарными нормами (10-30 минут) должны быть распределены по всему рабочему дню.

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

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

— в холодные периоды года температура воздуха, скорость его движения и относительная влажность должны соответственно составлять: 22-24 С; 0,1 м/с; 40-60%.

— в теплое время года соответственно: 23-25 С; 0,1-0,2 м/с; 40-60%.

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

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

5.1.1.1. Шум и вибрация.

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

В помещениях операторов ЭВМ уровень шума не должен превышать 65 дБА. На рабочих местах в помещениях для размещения шумных агрегатов вычислительных машин (АЦПУ, принтеры и т.д.) уровень шума не должен превышать 75 дБА.

Снижение вибрации и шума, создаваемого на рабочих местах внутренними источниками, а также шума, проникающего извне, осуществляется следующими методами: уменьшением шума в источнике, оборудование, аппараты, приборы необходимо устанавливать на спец. фундаменты и амортизирующие прокладки. Стены и потолки производственных помещений, где установлены ЭВМ и др. оборудование, являющееся источником шумообразования, должны быть облицованы звукопоглощающим материалом с максимальным коэффициентом звукопоглощения в области частот 63-8000 Гц, независимо от количества единиц установленного оборудования. В качестве звукопоглощающего материала, могут быть использованы перфорированные плиты, панели и др. материал аналогичного назначения, а также плотная хлопчатобумажная ткань, которой драпируются потолок и стены. Также можно использовать подвесные акустические потолки.

5.1.1.2. Планировка рабочего места.

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

Высота рабочей поверхности стола должна регулироваться в пределах 680-800 мм; при отсутствии такой возможности должна составлять 725 мм.

Дисплей должен удовлетворять следующим требованиям:

— важнейшие элементы конструкции должны быть расположены в центре поля зрения (клавиатура);

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

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

— экран видеомонитора должен находиться от глаз пользователя на оптимальном расстоянии 600-700 мм, но не ближе 500 мм с учётом размеров знаков и символов.

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

— для экрана: белый на черном;

— для клавиатуры: черный на белом.

Наиболее удобно сиденье, имеющее выемку, соответствующую форме бедер и наклон назад. Спинка стула должна быть изогнутой формы, обнимающей поясницу. Высота её – 300 мм, ширина – не менее 380 мм, радиус изгиба – 300-350 мм. Рабочий стул (кресло) должен быть снабжен подъёмно-поворотным механизмом, обеспечивающим регуляцию высоты сидения и спинки. Рабочее кресло должно иметь подлокотники. Регулировка каждого параметра должна легко осуществляться, быть независимой и иметь надёжную фиксацию. На рабочем месте необходимо предусматривать подставку для ног.

Клавиатура должна располагаться на поверхности стола таким образом, чтобы соответствовать локтю сидящего оператора. Его рука должна быть согнута на 90 градусов в локтевом суставе, а предплечье – лежать горизонтально. Клавиатуру следует располагать на расстоянии 100-300 мм от края, обращенного к пользователю.

Помещения и их размеры должны соответствовать количеству работающих и размещаемому в них КТС. Расстояние между рабочими столами с видеомониторами должно быть не менее 2,0 м, а расстояние между боковыми поверхностями видеомониторов – не менее 1,2 м. В помещениях с ПЭВМ ежедневно должна проводиться влажная уборка, необходимо наличие аптечки первой помощи и углекислотного огнетушителя.

5.1.1.3. Освещение.

Правильное освещение рабочего места оператора облегчает его труд, снижает утомление, повышает производительность труда, снижает опасность производственного травматизма. Освещение может быть естественным и искусственным. Естественное освещение создаётся в производственных помещениях через оконные и другие остеклённые проёмы, искусственное – светильниками. Искусственное освещение в помещениях следует осуществлять в виде комбинированной системы освещения с использованием люминесцентных источников света в светильниках общего назначения. В качестве источников общего освещения должны использоваться лампы типа ЛБ и ДРЛ с индексом цветопередачи не менее 70 (R>70), в качестве светильников – установки с преимущественно отраженным или рассеянным светом. Светильники общего освещения следует располагать над рабочим столом в равномерно прямоугольном порядке. Для предотвращения засветок экрана дисплея прямыми световыми потоками должны применяться светильники общего назначения, расположенные между рядами рабочих мест. При этом линии светильников располагаются параллельно светопроёмам.

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

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

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

5.1.1.4. Статическое электричество.

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

5.1.1.5. Излучение.

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

5.1.1.6. Пожарная безопасность на РМ.

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

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

Всё это приводит к принятию серьёзных мероприятий защиты от пожаров, определяемых СП 512-78 «Инструкции по проектированию зданий и помещений для ЭВМ» и СНиП 11-2-80 «Противопожарные нормы проектирования зданий и сооружений». В этих документах изложены основные требования к огнестойкости зданий и сооружений, противопожарным преградам, эвакуации людей из зданий и помещений.

5.1.2. Производственные шумы и вибрация.

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

Нормирование шумов в производственных помещениях осуществляется по предельным спектрам или в дБ в соответствии с ГОСТ 12.1.036-81 «Шум. Общие требования безопасности». Предельные нормы шумов производственного помещения определяются характером выполнения работ. Максимальный уровень непостоянного шума на рабочих местах не должен превышать 125 дБ. Запрещается кратковременное пребывание в зонах с уровнями звукового давления свыше 135 дБ.

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

Перечень мероприятий для борьбы с шумом включает:

— увеличение жесткости конструкций;

— замена металла на пластмассы если позволяет технология;

— замена зубчатых передач на фрикционные;

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

— удаление рабочих мест из шумных зон, дополнительный отдых рабочих шумных цехов и помещений;

— применение индивидуальных средств защиты (наушники, шлемы, вкладыши) и др.

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

5.2. Расчёт уровня звукового давления в операторной ЭВМ.

В случае, когда несколько источников шума (ИШ) и расчётная точка (РТ) находятся в помещении, уровень звукового давления определяется по следующей формуле:

, (1)

где m — количество источников шума в помещении (в нашем случае это могут быть кондиционеры, сервера и т.д.);

Ф — фактор направленности источника шума:

— Ф = 1 — для источника с равномерным излучением;

— Ф = 2 — для источника с равномерным излучением на отражающей плоскости;

— Ф = 4 — для источника с равномерным излучением вблизи двухгранного угла;

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

В — постоянная помещения (м2 ), определяемая из соотношения В1000 * m, где В1000 — постоянная помещения на эталонной частоте 1000 Гц, устанавливаемая из таблицы в зависимости от объема помещения V, m -частотный множитель, определяемый в зависимости от объема помещения по таблице;

Li — уровень звуковой мощности i-го источника шума, дБ;

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

Рассчитаем уровень звукового давления в операторной ЭВМ (см. рис.5.1):

рис.5.1. План помещения с расстановкой источников шума.

Исходные данные

№ИШ

L

lмах

R

r/ lмах

Ф

c

S

1

20

0.45

0.5

1.1

2

100

2.8

1.570795

2

5

0.45

1

2.2

2

3.2

1.05

6.28318

3

15

0.45

2.5

5.6

2

31.6

1

39.26988

4

5

0.45

3.5

7.8

2

3.2

1

76.96986

5

35

0.6

5

8.3

2

3162.3

1

1570795

V = 60

В1000 = 10

m = 0.75

В = 7.5

Подставляя исходные данные в формулу (1) получаем результат :

L = 32,92 дБ.

Вывод: в данном помещении уровень звукового давления не превышает норм установленных в соответствии с ГОСТом 12.1.036-81 «Шум. Общие требования безопасности».

5.3.Расчёт искусственного освещения в операторной ЭВМ.

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

Расчёт искусственного освещения сводится к определению числа светильников:

Е — нормируемая освещенность, Лк.(для нашего случая »300)

(выбирается из таблиц);

k3 — коэффициент запаса » 1.3;

А — площадь пола, м2 (=50 м2 );

z — коэффициент, учитывающий неравномерность освещенности

(Для ламп накаливания =1.5, для люминесцентных =1.1.);

— количество ламп в одном светильнике (=2);

— световой поток лампы (Для ламп ЛБ-40 = 3000 лм.);

— коэффициент использования светильников. Определяется по индексу помещения:

а — ширина помещения, м;

b — длина помещения, м;

h — высота подвеса светильников над рабочей поверхностью, м.

Принимая, что а=5 м., b=10 м., h=2 м., вычисляем =1.66. Теперь по таблице соответствия определяем, что =0.33.

Подставляя все необходимые данные получаем:

= 300*1.3*50*1.1 / 2*3000*0.33 » 10

Таким образом, получаем, что для освещения нашего помещения необходимо 10 светильника, по 2 лампы марки ЛБ-40 в каждом.

Схема расположения светильников в помещении.

Вывод: В результате правильного расчёта освещения, у операторов ЭВМ уменьшается риск профессиональных заболеваний (в основном потеря зрения), утомлённость и как следствие — повышается производительность труда.

ГЛАВА 6.Организационно-экономическая часть проекта.

Введение

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

Исходными данными для планирования являются объемные и трудовые нормативы. На основании объемных нормативов устанавливается состав выполняемых работ. Трудовые нормативы определяют затраты времени в нормо-часах на выполнение каждой работы.

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

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

6.1. Организация разработки программного продукта.

6.1.1. Состав и структура проекта.

Анализ ранее выполненных разработок программных продуктов (ПП) и рекомендации Государственных стандартов «Единая система программной документации» (ГОСТ 19.001) позволяют представить структуру проекта и стадии решаемых задач в виде дерева целей, изображенного на рис. 6.1.

┌────────────────────────────┐

│ Разработка программного │

│ продукта │

└─────────────┬──────────────┘

┌────────────┬─────────────┴─┬──────────────┬──────────┐

┌─────┴─────┬──────┴───────┬───────┴──────┬───────┴──────┬───┴─────┐

│техническое│ эскизное │ техническое │ рабочее │внедрение│

│задание │проектирование│проектирование│проектирование│ │

├───────────┼──────────────┼──────────────┼──────────────┼─────────┘

│ ├выбор метода ├разработка ├разработка ├сдача ПП

├постановка │ решения │ алгоритма │ программ │ заказчику

│ задачи ├опредедение ├опредедение ├тестирование ├сопровож-

├сбор исход.│ конфигурации │ форм данных │ и отладка │ дение ПП

│ материалов│ тех.средств ├разработка ├разработка

├составление├разработка │ тех.экон-го │ сопроводите-

│ Т.З. │ архитектуры │ обоснования │ льной доку-

│ системы │ целесообраз- │ ментации

│ программ │ ности внедре-│ испытание ПП

├организация │ ния продукта

│ разработки ├составление

│ пояснительной

│ записки

Рис. 6.1 Дерево целей разработки ПП.

6.1.2. Новизна и сложность разработки.

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

Таблица 6.1.

Оценка новизны ПП.

NNпп

Признак

Новизны

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

признака

Коэф.новизны

1

2

3

Степень новизны

разработки

Язык написания программы

Степень использования в программе типовых алгоритмов

Является развитием определенного параметрического

ряда программ

Необходимо изучить и освоить

до 70%

1,6

2,5

1,0

Коэффициент новизны равен:

Кн = (1,6 + 2,5 + 1,0)/3 = 1,7

Таблица 6.2.

Оценка сложности ПП.

NNпп

Признак

Сложности

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

Признака

Коэф.сложности

1

2

3

4

5

Количество операторов в программе

Уровень языка программирования

Категория программы

Интерфейс с пользователем

Операционная и технологическая среда

до 5000

Высокого

уровня F,dB

Организации

данных

Среднего

уровня

Хорошо

известна

0,7

1,6

1,6

1,6

0,7

Коэффициент сложности равен:

Kc = (0,7 + 1,6 + 1,6 + 1,6 + 0,7)/5 =1,3

6.1.3. Перечень работ и стадии их выполнения.

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

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

Перечень конкретных работ с указанием стадий их выполнения и объема выпускаемой документации (в листах формата А4) приведен в табл. 6.3.

Таблица 6.3.

Перечень выполняемых работ.

NNпп

Наименование работы

Стадия

разр.

Колич.

форм А4

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

Формулировка проблемы и постановка задачи

Сбор и проработка исходных материалов

Обоснование необходимости разработки

Разработка структуры вх/вых данных, функций интерфейса с пользователем

Обоснование принципиальной возможности решения задачи

Составление, согласование и утверждение ТЗ

Подготовка графической части проекта

Опред. требований к пр-ме и техн-м средствам

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

Разработка общего алгоритма решения задачи

Определение конфигурации техн-х средств

Составление плана разработки программного продукта в виде сетевого графика

Разработка структуры программы

Изображение сетевого графика на плакате

Уточнение вх/вых данных и определение форм их представления

Определение объема и трудоемкости выполненных работ

Выбор методов решения задачи

Опред. затрат на разработку и внедрение ПП

Описание ограничений и допущений, связанных с методом решения задачи

Оценка ожидаемого экон… эф. от внедрения ПП

Обоснование выбора языка программирования

Описание лог-й структуры и функ-й пр-мы

Оформление и утверждение пояснительной записки проекта

Разработка алгоритма программы

Написание программы

Тестирование программы

Разработка руководства оператора

Компоновка и отладка программы

Проведение пред.приемо-сдаточных исп-ий

Сдача программного продукта заказчику

ТЗ

ТЗ

ТЗ

ЭП

ЭП

ТЗ

ТП

ТЗ

ТЗ

ЭП

ТП

ЭП

ТП

ТП

ТП

ТП

ЭП

ТП

ТП

ТП

ТП

ТП

ТП

ТП

РП

РП

РП

РП

РП

ВН

2

120

2

7

4

4

24

2

3

8

3

6

4

8

3

4

4

6

2

6

1

2

85

6

16

6

8

8

10

25

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

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

Трудоемкость выполнения любой работы определяется по формуле:

Тр = Тб * Кн * Кс * Кэ * Кв * Р ** 0.8, (1)

где Тб — норма времени (трудоемкость в нормо-часах разработки

базового документа формата А4).

Кн — коэффициент новизны ПП.

Кс — коэффициент сложности ПП.

Кэ — коэффициент стадии (этапа) разработки.

Кв — коэффициент трудоемкости вида работы.

Р — количество листов разрабатываемых документов,

приведенных к формату А4.

Величина нормы времени Тб и значение коэффициентов Кэ и Кв приняты в соответствии с методическими рекомендации кафедры 115. Значения коэффициентов новизны и сложности разработки приняты в соответствии с табл. 6.1, 6.2. Количество листов разрабатываемых документов в формате А4 приведено в табл. 6.3.

Норма времени, значения указанных коэффициентов и насчитанные величины трудоемкости выполняемых работ приведены в табл. 6.6, 6.7.

6.1.5. Планирование разработки и внедрения.

Для планирования разработки программного продукта используется метод сетевого планирования и управления (СПУ), основой которого являетя сетевой график.

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

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

Исходные данные с указанием номеров очередных работ и их взаимосвязи с другими работами показаны в табл. 6.4.

Результаты построения сетевого графика с помощью программы p51.exe представлены в табл. 6.5, где указаны номера и коды (предшествующее и последующее события) всех выполняемых работ, а также несколько фиктивных работ. Построенный согласно этой таблице сетевой график в масштабе времени изображен на рис. 6.2.

Исходные номера и взаимосвязи работ (информация для справки).

+-----------------------------------------------------------+

¦ очередн. предшеств. послед.¦ очередн. предшеств. послед.¦

+-----------------------------+-----------------------------¦

¦ 1 0 0 0 0 0 0 ¦ 2 0 0 0 0 0 0 ¦

¦ 3 1 0 0 0 0 0 ¦ 4 8 0 0 0 0 0 ¦

¦ 5 8 0 0 0 0 0 ¦ 6 2 0 0 0 0 0 ¦

¦ 7 1 3 0 0 0 0 ¦ 8 2 3 6 7 4 5 ¦

¦ 9 5 0 0 0 0 0 ¦ 10 4 11 17 16 12 0 ¦

¦ 11 4 0 0 0 0 0 ¦ 12 10 0 0 0 0 0 ¦

¦ 13 16 10 12 14 0 0 ¦ 14 4 0 0 0 0 0 ¦

¦ 15 5 9 18 0 19 0 ¦ 16 4 11 17 0 0 0 ¦

¦ 17 4 11 0 0 0 0 ¦ 18 5 9 0 0 0 0 ¦

¦ 19 15 0 0 0 0 0 ¦ 20 24 0 0 0 0 0 ¦

¦ 21 15 19 0 0 24 0 ¦ 22 8 0 0 0 24 0 ¦

¦ 23 13 0 0 0 24 0 ¦ 24 23 21 22 0 0 0 ¦

¦ 25 20 0 0 0 0 0 ¦ 26 20 25 0 0 0 0 ¦

¦ 27 20 25 26 0 0 0 ¦ 28 25 0 0 0 0 0 ¦

¦ 29 25 26 27 28 0 0 ¦ 30 29 0 0 0 0 0 ¦

+-----------------------------------------------------------+

Перенумерация исходных работ в расчетные (информ. для справки).

+-----------------------------------------------------------+

¦ Расчетные 1 2 3 4 5 6 7 8 9 10 11 12 ¦

¦ Исходные 1 2 3 6 7 8 22 4 5 11 14 9 ¦

+-----------------------------------------------------------¦

¦ Расчетные 13 14 15 16 17 18 19 20 21 22 23 24 ¦

¦ Исходные 17 18 16 15 10 19 12 21 13 23 24 20 ¦

+-----------------------------------------------------------¦

¦ Расчетные 25 26 27 28 29 30 31 32 33 34 35 36 ¦

¦ Исходные 25 26 28 27 29 30 0 0 0 0 0 0 ¦

+-----------------------------------------------------------+

Таблица 6.4.

Номера работ и их взаимосвязи.

+-----------------------------------------------------------+

¦ очередн. предшеств. послед.¦ очередн. предшеств. послед.¦

+-----------------------------+-----------------------------¦

¦ 1 0 0 0 0 0 0 ¦ 2 0 0 0 0 0 0 ¦

¦ 3 1 0 0 0 0 0 ¦ 4 2 0 0 0 0 0 ¦

¦ 5 1 3 0 0 0 0 ¦ 6 2 3 4 5 8 9 ¦

¦ 7 6 0 0 0 23 0 ¦ 8 6 0 0 0 0 0 ¦

¦ 9 6 0 0 0 0 0 ¦ 10 8 0 0 0 0 0 ¦

¦ 11 8 0 0 0 0 0 ¦ 12 9 0 0 0 0 0 ¦

¦ 13 8 10 0 0 0 0 ¦ 14 9 12 0 0 0 0 ¦

¦ 15 8 10 13 0 0 0 ¦ 16 9 12 14 0 18 0 ¦

¦ 17 8 10 13 15 19 0 ¦ 18 16 0 0 0 0 0 ¦

¦ 19 17 0 0 0 0 0 ¦ 20 16 18 0 0 23 0 ¦

¦ 21 15 17 19 11 0 0 ¦ 22 21 0 0 0 23 0 ¦

¦ 23 22 20 7 0 0 0 ¦ 24 23 0 0 0 0 0 ¦

¦ 25 24 0 0 0 0 0 ¦ 26 24 25 0 0 0 0 ¦

¦ 27 25 0 0 0 0 0 ¦ 28 24 25 26 0 0 0 ¦

¦ 29 25 26 28 27 0 0 ¦ 30 29 0 0 0 0 0 ¦

+-----------------------------------------------------------+

Таблица 6.5.

Номера и коды работ сетевого графика.

+----------------------------------------------------------------+

¦ Номер 1 2 3 4 5 6 7 8 ¦

¦ Код 1- 2 1- 3 2- 4 3- 5 4- 5 5- 6 6-19 6- 7 ¦

+----------------------------------------------------------------¦

¦ Номер 9 10 11 12 13 14 15 16 ¦

¦ Код 6- 8 7- 9 7-17 8-10 9-11 10-12 11-13 12-14 ¦

+----------------------------------------------------------------¦

¦ Номер 17 18 19 20 21 22 23 24 ¦

¦ Код 13-15 14-16 15-17 16-19 17-18 18-19 19-20 20-21 ¦

+----------------------------------------------------------------¦

¦ Номер 25 26 27 28 29 30 31 32 ¦

¦ Код 21-22 22-23 22-24 23-24 24-25 25-26 0- 0 0- 0 ¦

+----------------------------------------------------------------+

6.1.6. Расчет и оптимизация параметров сетевого графика.

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

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

Исходные данные, необходимые для расчета и оптимизации параметров сетевого графика приведены в табл. 6.6, 6.7.

Результаты расчета параметров сетевого графика приведены в табл.6.8, 6.9. Эпюра минимальной потребности в исполнителях, построенная согласно таблицы 6.10, приведена на рис. 6.2. План-график выполнения всего комплекса работ представлен в табл. 6.11.

Tаблица 6.6.

Общие сведения по выполнению работ.

══════════════════════════════════

1. Количество работ сети: 30 5. Процент дополн. зарплаты: 8

2. Срок выполнения заказа: 60 дн. 6. Процент отчислений на

3. Коэффициент новизны: 1.7 социальное страхование: 37

4. Коэффициент сложности: 1.3 7. Время разработки типового

документа формата А4: 1.7 час.

Tаблица 6.7.

Параметры выполняемых работ.

+-------------------------------------------------------------+

¦ работа в сети коэфф. коэфф. колич. часовая проц. проц. ¦

¦================= этапа трудо- доку- тариф- пре- кос- ¦

¦ но- тру- выпол- емк. ментов ная мии венн. ¦

¦ мер код доем- нения вида форм. став- и рас- ¦

¦ кость работы работы А-4 ка допл. ходов ¦

+-------------------------------------------------------------¦

¦ 1 1- 2 39. 3.0 2.00 2 7.20 25 80 ¦

¦ 2 1- 3 10. 3.0 .02 120 6.40 20 100 ¦

¦ 3 2- 4 26. 3.0 1.30 2 6.40 20 80 ¦

¦ 4 3- 5 33. 2.3 .80 7 6.40 20 80 ¦

¦ 5 4- 5 34. 2.3 1.30 4 6.80 20 80 ¦

¦ 6 5- 6 48. 3.0 1.40 4 7.20 25 100 ¦

¦ 7 6-19 23. 1.6 .30 24 5.60 20 100 ¦

¦ 8 6- 7 29. 3.0 1.50 2 7.20 20 80 ¦

¦ 9 6- 8 27. 3.0 1.00 3 6.40 20 80 ¦

¦ 10 7- 9 59. 2.3 1.30 8 6.80 25 80 ¦

¦ 11 7-17 19. 1.6 1.30 3 6.80 25 100 ¦

¦ 12 8-10 22. 2.3 .60 6 6.40 20 150 ¦

¦ 13 9-11 22. 1.6 1.20 4 6.40 20 80 ¦

¦ 14 10-12 10. 1.6 .30 8 6.00 20 100 ¦

¦ 15 11-13 12. 1.6 .80 3 6.00 20 80 ¦

¦ 16 12-14 11. 1.6 .60 4 6.00 20 150 ¦

¦ 17 13-15 34. 2.3 1.30 4 6.40 20 80 ¦

¦ 18 14-16 15. 1.6 .60 6 5.60 20 150 ¦

¦ 19 15-17 14. 1.6 1.30 2 6.40 20 80 ¦

¦ 20 16-19 15. 1.6 .60 6 5.60 20 80 ¦

¦ 21 17-18 8. 1.6 1.30 1 6.40 20 80 ¦

¦ 22 18-19 12. 1.6 1.10 2 6.40 20 80 ¦

¦ 23 19-20 63. 1.6 .30 85 6.80 25 80 ¦

¦ 24 20-21 30. 1.6 1.20 6 6.00 25 80 ¦

¦ 25 21-22 35. 1.0 1.00 16 6.00 25 200 ¦

¦ 26 22-23 13. 1.0 .80 6 6.00 20 200 ¦

¦ 27 22-24 8. 1.0 .40 8 6.00 20 80 ¦

¦ 28 23-24 24. 1.0 1.20 8 6.00 25 200 ¦

¦ 29 24-25 21. 1.0 .90 10 6.00 25 200 ¦

¦ 30 25-26 24. .8 .60 25 6.00 25 150 ¦

+-------------------------------------------------------------+

Таблица 6.8.

Параметры событий сети.

+----------------------------------------------------------------------+

¦ Номер ¦ Срок свершения ¦ Формулировка ¦

¦ собы- ¦----------------¦ события ¦

¦ тия ¦ ранний поздний ¦ ¦

+----------------------------------------------------------------------¦

¦ 1 ¦ .0 .0 ¦ Работа по разработке ПП начата ¦

¦ 2 ¦ 3.5 3.5 ¦ Проблемы сформулированы, задача поставлена ¦

¦ 3 ¦ 3.5 3.5 ¦ Информация для решения проблемы собрана ¦

¦ 4 ¦ 6.5 6.5 ¦ Необходимость и разработки определены ¦

¦ 5 ¦ 10.0 10.0 ¦ Возможность решения задачи обоснована ¦

¦ 6 ¦ 14.5 14.5 ¦ ТЗ разработано и утверждено ¦

¦ 7 ¦ 18.0 18.0 ¦ Требования сформулированы ¦

¦ 8 ¦ 19.5 19.5 ¦ Стадии разработки и состав работ определен ¦

¦ 9 ¦ 22.5 22.5 ¦ Общий алгоритм разработан ¦

¦ 10 ¦ 24.0 24.0 ¦ План сетевого графика разработан ¦

¦ 11 ¦ 25.5 25.5 ¦ Структура программы разработана ¦

¦ 12 ¦ 27.5 27.5 ¦ Сетевой график построен ¦

¦ 13 ¦ 28.0 28.0 ¦ Формы представления данных уточнены ¦

¦ 14 ¦ 31.0 31.0 ¦ Трудоемость работ определена ¦

¦ 15 ¦ 31.5 31.5 ¦ Возможность решения задачи обоснована ¦

¦ 16 ¦ 34.5 34.5 ¦ Затраты на разработку и внедрение определены¦

¦ 17 ¦ 34.0 34.0 ¦ Конфигурация технических средств определена ¦

¦ 18 ¦ 35.5 35.5 ¦ Язык программирования выбран ¦

¦ 19 ¦ 38.0 38.0 ¦ Проектирование ПП закончено ¦

¦ 20 ¦ 42.5 42.5 ¦ Материалы для пояснительной записки получены¦

¦ 21 ¦ 46.0 46.0 ¦ Мат.модели и алгоритмы прогр.модулей разраб.¦

¦ 22 ¦ 49.5 49.5 ¦ Программа разработана ¦

¦ 23 ¦ 52.0 52.0 ¦ Программа протестирована ¦

¦ 24 ¦ 55.0 55.0 ¦ Программа для ее проверки готова ¦

¦ 25 ¦ 57.5 57.5 ¦ Приемо-сдаточные испытания закончены ¦

¦ 26 ¦ 60.5 60.5 ¦ Работы по внедрения ПП закончены ¦

+----------------------------------------------------------------------+

Таблица 6.9.

Сроки выполнения работ и потребность в исполнителях.

+----------------------------------------------------------------------+

¦ Работа ¦ Трудоем- ¦ Начало ¦ Продолжи- ¦ Окончание ¦ Потребность¦

¦------------¦ кость ¦ работы ¦ тельность ¦ работы ¦ в исполни- ¦

¦ номер код ¦ час ¦ день ¦ дни ¦ дни ¦ телях ¦

+----------------------------------------------------------------------¦

¦ 1 1- 2 39.0 .0 3.5 3.5 1.33 ¦

¦ 2 1- 3 10.0 .0 3.5 3.5 .38 ¦

¦ 3 2- 4 26.0 3.5 3.0 6.5 1.09 ¦

¦ 4 3- 5 33.0 3.5 6.5 10.0 .69 ¦

¦ 5 4- 5 34.0 6.5 3.5 10.0 1.24 ¦

¦ 6 5- 6 48.0 10.0 4.5 14.5 1.47 ¦

¦ 7 6-19 23.0 14.5 23.5 38.0 .12 ¦

¦ 8 6- 7 29.0 14.5 3.5 18.0 1.15 ¦

¦ 9 6- 8 27.0 14.5 5.0 19.5 .68 ¦

¦ 10 7- 9 59.0 18.0 4.5 22.5 1.64 ¦

¦ 11 7-17 19.0 18.0 16.0 34.0 .15 ¦

¦ 12 8-10 22.0 19.5 4.5 24.0 .62 ¦

¦ 13 9-11 22.0 22.5 3.0 25.5 1.00 ¦

¦ 14 10-12 10.0 24.0 3.5 27.5 .42 ¦

¦ 15 11-13 12.0 25.5 2.5 28.0 .74 ¦

¦ 16 12-14 11.0 27.5 3.5 31.0 .44 ¦

¦ 17 13-15 34.0 28.0 3.5 31.5 1.24 ¦

¦ 18 14-16 15.0 31.0 3.5 34.5 .51 ¦

¦ 19 15-17 14.0 31.5 2.5 34.0 .80 ¦

¦ 20 16-19 15.0 34.5 3.5 38.0 .51 ¦

¦ 21 17-18 8.0 34.0 1.5 35.5 .60 ¦

¦ 22 18-19 12.0 35.5 2.5 38.0 .74 ¦

¦ 23 19-20 63.0 38.0 4.5 42.5 1.69 ¦

¦ 24 20-21 30.0 42.5 3.5 46.0 1.17 ¦

¦ 25 21-22 35.0 46.0 3.5 49.5 1.26 ¦

¦ 26 22-23 13.0 49.5 2.5 52.0 .77 ¦

¦ 27 22-24 8.0 49.5 5.5 55.0 .20 ¦

¦ 28 23-24 24.0 52.0 3.0 55.0 1.04 ¦

¦ 29 24-25 21.0 55.0 2.5 57.5 .98 ¦

¦ 30 25-26 24.0 57.5 3.0 60.5 1.04 ¦

+----------------------------------------------------------------------+

Таблица 6.10.

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

+----------------------------------------------------------------------+

¦ Время (дни) .0 3.5 6.5 10.0 14.5 18.0 19.5 22.5 ¦

¦ Потребность 1.7 1.8 1.9 1.5 2.0 2.6 2.5 1.9 ¦

+----------------------------------------------------------------------¦

¦ Время (дни) 24.0 25.5 28.0 31.5 34.0 35.5 38.0 42.5 ¦

¦ Потребность 1.7 1.4 2.0 1.6 1.2 1.4 1.7 1.2 ¦

+----------------------------------------------------------------------¦

¦ Время (дни) 46.0 49.5 52.0 55.0 60.5 .0 .0 .0 ¦

¦ Потребность 1.3 1.0 1.2 1.0 .0 .0 .0 .0 ¦

+----------------------------------------------------------------------+


Таблица 6.11.

План-график выполнения комплекса работ.

+----------------------------------------------------------------------------------------------------------------------+

¦ NN Про- На- Окон-¦

¦ ра- дол- ча- Время выполнения работ ча- ¦

¦ бо- жит. ло ние ¦

¦ ты дни день день¦

¦-------------====*====1====*====2====*====3====*====4====*====5====*====6====*====7====*====8====*====9====*====0-----¦

¦ 1 3.5 .0-----… 3.5¦

¦ 2 3.5 .0-----… 3.5¦

¦ 3 3.0 3.5....------… 6.5¦

¦ 4 6.5 3.5....------------… 10.0¦

¦ 5 3.5 6.5.........-------… 10.0¦

¦ 6 4.5 10.0...............--------…… 14.5¦

¦ 7 23.5 14.5......................----------------------------------------… 38.0¦

¦ 8 3.5 14.5......................-------… 18.0¦

¦ 9 5.0 14.5......................----------… 19.5¦

¦ 10 4.5 18.0............................---------… 22.5¦

¦ 11 16.0 18.0............................----------------------------… 34.0¦

¦ 12 4.5 19.5...............................--------… 24.0¦

¦ 13 3.0 22.5....................................------… 25.5¦

¦ 14 3.5 24.0......................................-------… 27.5¦

¦ 15 2.5 25.5.........................................-----… 28.0¦

¦ 16 3.5 27.5............................................-------… 31.0¦

¦ 17 3.5 28.0.............................................-------… 31.5¦

¦ 18 3.5 31.0..................................................-------… 34.5¦

¦ 19 2.5 31.5...................................................-----… 34.0¦

¦ 20 3.5 34.5........................................................------… 38.0¦

¦ 21 1.5 34.0.......................................................---… 35.5¦

¦ 22 2.5 35.5.........................................................-----… 38.0¦

¦ 23 4.5 38.0.............................................................---------… 42.5¦

¦ 24 3.5 42.5.....................................................................-------… 46.0¦

¦ 25 3.5 46.0...........................................................................------… 49.5¦

¦ 26 2.5 49.5................................................................................-----… 52.0¦

¦ 27 5.5 49.5................................................................................----------… 55.0¦

¦ 28 3.0 52.0....................................................................................------… 55.0¦

¦ 29 2.5 55.0.........................................................................................------… 57.5¦

¦ 30 3.0 57.5.........................................................................................------… 57.5¦

+----------------------------------------------------------------------------------------------------------------------+


6.2. Стоимость программного продукта.

6.2.1.Затраты на создание программного продукта.

Стоимость выполнения каждой работы создания ПП определяется как сумма заработной платы работников и накладных (косвенных) расходов по формуле:

Ср = sum ( Зr + Нr ), (2.1)

r — R

где Зr — заработная плата и отчисления на социальное страхование при выполнении r-той работы;

Нr — величина накладных расходов, связанных с выполнением r-той работы;

R — множество выполняемых работ.

Величина заработной платы на выполнение r-той работы равна:

Зr = Зоr + Здr + Зсr, (2.2)

Зоr = Тr * Счr * ( 1 + Кпr ), (2.3)

Здr = Кд * Зоr, (2.4)

Зсr = Кс * ( Зоr + Здr ), (2.5)

где Зоr — основная заработная плата на выполнение r-той работы;

Тr — трудоемкость работы в нормочасах;

Счr — средняя часовая тарифная ставка выполнения работы;

Кпr — коэффициент премий и доплат;

Здr — дополнительная заработная плата;

Кд — коэффициент дополнительной заработной платы;

Зсr — отчисления на соц. страхование;

Кс — коэффициент отчислений на соц. страхование.

Величина накладных расходов связанных с выполнением r-той работы, определяется по формуле:

Нr = ( Зr*Кнr )/100, (2.6)

где Кнr — процент накладных расходов.

Исходные данные для расчета затрат на выполняемые работы приведены в табл. 6.6, 6.7. Смета затрат на выполнение каждой работы рассчитана на ЭВМ и приведена в табл. 6.12. Экономическая характеристика разработки и внедрения программного продукта приведена в табл. 6.13.

6.2.2.Цена программного продукта.

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

Цр = Спп*(1+Кр)*(1+Пт/100)/Рпп, (2.7)

где Спп — себестоимость создания программного продукта;

Кр — коэффициент рентабельности разработки;

Кт — процент торговой наценке к оптовой цене;

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

Затраты на создание программного продукта, то есть его себестоимость, составляют 17 643 руб. Коэффициент рентабельности, определяющий прибыль от реализации программного продукта, принятом равным 0,2. Ожидается, что в текущем году будет продано три экземпляра программного продукта с торговой наценкой 70 %.

В этом случае розничная цена программного продукта устанавливается равной:

Цр = 17643*(1+0,2)*(1+70/100)/3 = 11 997 руб.


Таблица 6.12.

Смета затрат на выполняемые работы.

+-------------------------------------------------------------------------------------------------------+

¦ ¦ трудоем- ¦ средняя ¦ процент ¦ основная ¦ дополн. ¦ отчисл. ¦ сумма ¦ накладн.¦ общая ¦

¦ номер ¦ кость ¦ часовая ¦ премии ¦ зарплата ¦ зарплата ¦ на соц. ¦ зарплаты ¦ расходы ¦ сумма ¦

¦ работы ¦ нормо- ¦ ставка ¦ и ¦ ¦ ¦ страхов.¦ и отчисл.¦ ¦ затрат ¦

¦ ¦ час ¦ руб/час ¦ доплат ¦ руб. ¦ руб. ¦ руб. ¦ руб. ¦ руб. ¦ руб. ¦

+-------------------------------------------------------------------------------------------------------¦

¦ 1 39. 7.20 25.00 351.00 28.08 140.26 519.34 415.47 934.81 ¦

¦ 2 10. 6.40 20.00 76.80 6.14 30.69 113.63 113.63 227.27 ¦

¦ 3 26. 6.40 20.00 199.68 15.97 79.79 295.45 236.36 531.80 ¦

¦ 4 33. 6.40 20.00 253.44 20.28 101.27 374.99 299.99 674.98 ¦

¦ 5 34. 6.80 20.00 277.44 22.20 110.87 410.50 328.40 738.90 ¦

¦ 6 48. 7.20 25.00 432.00 34.56 172.63 639.19 639.19 1278.37 ¦

¦ 7 23. 5.60 20.00 154.56 12.36 61.76 228.69 228.69 457.37 ¦

¦ 8 29. 7.20 20.00 250.56 20.04 100.12 370.73 296.58 667.31 ¦

¦ 9 27. 6.40 20.00 207.36 16.59 82.86 306.81 245.45 552.26 ¦

¦ 10 59. 6.80 25.00 501.50 40.12 200.40 742.02 593.62 1335.64 ¦

¦ 11 19. 6.80 25.00 161.50 12.92 64.54 238.96 238.96 477.91 ¦

¦ 12 22. 6.40 20.00 168.96 13.52 67.52 249.99 374.99 624.98 ¦

¦ 13 22. 6.40 20.00 168.96 13.52 67.52 249.99 199.99 449.99 ¦

¦ 14 10. 6.00 20.00 72.00 5.76 28.77 106.53 106.53 213.06 ¦

¦ 15 12. 6.00 20.00 86.40 6.91 34.53 127.84 102.27 230.11 ¦

¦ 16 11. 6.00 20.00 79.20 6.34 31.65 117.18 175.78 292.96 ¦

¦ 17 34. 6.40 20.00 261.12 20.89 104.34 386.35 309.08 695.44 ¦

¦ 18 15. 5.60 20.00 100.80 8.06 40.28 149.14 223.72 372.86 ¦

¦ 19 14. 6.40 20.00 107.52 8.60 42.96 159.09 127.27 286.36 ¦

¦ 20 15. 5.60 20.00 100.80 8.06 40.28 149.14 119.31 268.46 ¦

¦ 21 8. 6.40 20.00 61.44 4.92 24.55 90.91 72.73 163.63 ¦

¦ 22 12. 6.40 20.00 92.16 7.37 36.83 136.36 109.09 245.45 ¦

¦ 23 63. 6.80 25.00 535.50 42.84 213.99 792.33 633.86 1426.19 ¦

¦ 24 30. 6.00 25.00 225.00 18.00 89.91 332.91 266.33 599.24 ¦

¦ 25 35. 6.00 25.00 262.50 21.00 104.89 388.39 776.79 1165.18 ¦

¦ 26 13. 6.00 20.00 93.60 7.49 37.40 138.49 276.98 415.47 ¦

¦ 27 8. 6.00 20.00 57.60 4.61 23.02 85.22 68.18 153.40 ¦

¦ 28 24. 6.00 25.00 180.00 14.40 71.93 266.33 532.66 798.98 ¦

¦ 29 21. 6.00 25.00 157.50 12.60 62.94 233.04 466.07 699.11 ¦

¦ 30 24. 6.00 25.00 180.00 14.40 71.93 266.33 399.49 665.82 ¦

+-------------------------------------------------------------------------------------------------------¦

¦ ИТОГО 740. 5856.90 468.55 2340.42 8665.87 8977.45 17643.32 ¦

+-------------------------------------------------------------------------------------------------------+


Таблица 6.13.

Экономическая характеристика проекта.

════════════════════════════════════

1. Заданное время выполнения проекта — 60 дней

2. Общая трудоемкость выполнения проекта — 740 нормо-часов

3. Средняя потребность в исполнителях — 1.54

4. Затраты на создание

программного продукта — 17.643 тыс.руб.

6.3. Оценка ожидаемого экономического эффекта.

6.3.1. Выбор метода расчета.

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

Годовой экономический эффект определяется по формуле:

Эг = [( Тб + Ен * Кб ) — ( Тв + Ен * Кв )]*B, (3.1)

где Тб, Тв — годовые текущие затраты в базовом и внедряемом вариантах;

Кб, Кв — капитальные вложения в базовом и внедряемом вариантах;

Ен — нормативный коэффициент эффективности капитальных вложений, равный 0.3;

B — число единиц ПП, внедрённого в текущем году.

Срок окупаемости затрат в годах определяется по формуле:

Ток = ( Кв — Кб ) / Эг, (3.2)

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

6.3.2. Сведения о базовом и внедряемом вариантах.

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

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

6.3.3. Капитальные затраты.

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

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

Кб = 1200 * 2 + 24 * 100 = 4800 руб.

Капитальные затраты во внедряемом варианте определяются стоимостью программного продукта, 11 997 руб. и 50% стоимости и установки компьютера, которые приняты равными 9000 руб.

Кв = 11997 + 9000 = 20 997 руб.

6.3.4. Текущие затраты.

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

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

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

В базовом варианте занято 2 человека с основной зарплатой в 1000 рублей каждый. Их годовая заработная плата равна:

Зоб = 2 * 1000 * 12 = 24 000 руб.

Зсб = 0.37 * Зоб = 8 880 руб.

Зб = 24000 + 8880 = 32 880 руб.

Накладные расходы приняты равными 70 % заработной платы:

Нб = 32880 * 0.7 = 23 020 руб.

Текущие расходы в базовом варианте составляют:

Тб = 32880 + 23020 = 55 900 руб.

Во внедряемом варианте занят 1 человек с зарплатой в 1600 руб. выполняет работу с использованием программного продукта за 50 % времени. Его годовая заработная плата за аналогичную работу равна:

Зов = 1 * 1600 * 12 * 0.5 = 9 600 руб.

Звс = 0.37 * 9600 = 3 550 руб.

Зв = 9600 + 3550 = 13 150 руб.

Накладные расходы приняты равными 180 % заработной платы:

Нв = 13150 * 1.8 = 23 670 руб.

Текущие расходы во внедряемом варианте составляют:

Тв = 13150 + 23670 = 36 820 руб.

6.3.5. Расчет экономического эффекта.

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

Эг =(55900 + 0.3*4800) — (36820 + 0.3*20997) = 14 220 руб.

Срок окупаемости произведенных затрат равен:

Ток = (20997 — 4800)/14220 = 1.1 года

Выводы

1. Планом создания программного продукта предусмотрено проведение 30 работ, последовательность выполнения которых устанавливается сетевым графиком. Согласно разработанной методике, определена трудоемкость выполнения каждой работы. Общая трудоемкость выполнения проекта составляет 740 нормо-часов. При выбранной структуре сетевого графика расчет и оптимизация на ЭВМ его параметров позволили определить сроки выполнения каждой работы и минимальное потребное количество ее исполнителей. Установлено, что при заданном сроке выполнения всех работ, равном 60 дням, средняя потребность в исполнителях составит 1.54.

2. Затраты на создание программного продукта, то есть его себестоимость, составляет 17 643 руб. Розничная цена программного продукта установлена в 11 997 руб. Ожидается, что в текущем году разработанным программным продуктом воспользуются три потребителя.

3. Уменьшение трудоемкости и числа работников дает возможность получить годовой экономический эффект при использования программного продукта каждым потребителем 14 220 руб. Срок окупаемости дополнительных капитальных затрат потребителя равен 1,1 года.

Заключение

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

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

Говоря о проблемах взаимодействия человека с ТС АСУ и практической реализации интерфейса взаимодействия, нельзя опустить такой важный вопрос, как унификация и стандартизация. Использование типовых решений, модульного принципа проектирования систем отображения и обработки информации приобретает всё более широкие масштабы, что, впрочем, вполне естественно.

Особый упор при внедрении данных задач, проектирование и разработка АИС «Учет деятельности малых производственных цехов», следует конечно придавать современным CASE-средствам разработки программ, так как они наиболее оптимально позволяют проектировать решения в основе которых лежат, в первую очередь, требования к согласованному пользовательскому интерфейсу, каковым и является интерфейс Windows. Никакие продукты других фирм, доступные сегодня, не обеспечивают одновременную простоту использования, производительность и гибкость в такой степени, как Delphi. Этот язык заполнил брешь между языками 3-го и 4-го поколений, соединив их сильные стороны и создав мощную, и производительную среду разработки.

Список литературы :

по профилирующему разделу:

1. Дж. Тельман, «Основы систем баз данных», Москва,'Финансы и статистика', 1983г.

2. Дейт К., «Введение в системы баз данных», Москва, 'Hаука', 1980 г.

3. Когловский М.Р., «Технология баз данных на персональных ЭВМ», Москва, 'Финансы и статистика', 1992 г.

4. Шумаков П. В., «Delphi 3.0 и создание баз данных». Москва 1997г.

5. Джон Матчо, Дэвид Р.Фолкнер. «Delphi» — пер. с англ. — М.: Бином, 1995г.

6. A.M.Епанешников. Епанешников В.А., «Программирование в среде Delphi 2.0», М.: Диалог-Мифи, 1997г.-235с.

7. Дж. Мартин., «Организация баз данных в вычислительных системах», М: Мир 1978г.

8. С.М.Диго, «Проектирование и использования баз данных». Москва: Финансы и статистика 1995.

9. Горев А., Ахаян Р., Макашарипов С., «Эффективная работа с СУБД».СПб.: Питер, 1997.— 704 с., ил.

10. Атре Ш., «Структурный подход к организации баз данных». – М.: Финансы и статистика, 1983. – 320 с.

11. Бойко В.В., Савинков В.М., «Проектирование баз данных и информационных систем». – М.: Финансы и статистика, 1989. – 351 с.

12. Джексон Г., «Проектирование реляционных баз данных для использования с микроЭВМ». -М.: Мир, 1991. – 252 с.

13. Кириллов В.В., «Структурированный язык запросов (SQL)». – СПб.: ИТМО, 1994. – 80 с.

14. Мейер М., «Теория реляционных баз данных». – М.: Мир, 1987. – 608 с.

15. Тиори Т., Фрай Дж., «Проектирование структур баз данных». В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.

16. Цикритизис Д., Лоховски Ф., «Модели данных». – М.: Финансы и статистика, 1985. – 344 с.

17. «Paradox for Windows: Практическое руководство». Под редакцией Оспищева Д. А. Издательство АОЗ «Алевар», 1993.

18. Брябрин В.М., «Программное обеспечение персональных ЭВМ», Москва, 'Hаука', 1989 г.

19. Шафрин Ю.А., «Основы компьютерной технологии». М., 1998

20. «Кибернетические диалоговые системы», И.П.Кузнецов.

21. «Рекоммендации по общепользовательскому интерфейсу», Microsoft, редакция 1995г.

22. Тейксейра, Стив, Пачеко, Ксавье. Delphi 4. «Руководство разработчика».СПб: Издательский дом 'Вильямс' 1999г.-912с.

23. Ден Оузьер, Стив Гробман, Стив Батсон. DELPHI. «Освой самостоятельно» Перевод с англ.-М.: Восточная Книжная Компания, 1997г.-624с.

24. Калянов Г.Н., «Консалтинг при автоматизации предприятий»: Научно-практическое издание. Серия «Информатизация России на пороге 21 века» – М.: СИНТЕГ, 1997г.-316с.

25. Питер Колетски и др. ORACLE DESIGNER «Настольная книга пользователя».Второе издание.Издательство 'Лори' 1999г.

26. Касьянова Г.Ю., Колесников С.Н., " Управленческий учёт по формуле 'три в одном' " М.: Издательство-консультационная компания 'Статус Кво 97', 1999г.-328с.

по разделу безопасность и экологичность труда:

1. ГОСТ 24.525-80. Нормы и требования по охране окружающей среды.

2. «Справочник проектировщика. Защита от шума» под ред. Юдина – М.: Энергоиздат, 1982 г.

3. Суворов Г.А., «Гигиеническое нормирование производственных шумов и вибраций» – М.: Медицина, 1984 г.

4. СанПиН 2.2.2.542-96, «Гигиенические требования к видеодисплейным терминалам, персональным ЭВМ и организации работы».

по экономическому разделу:

1. Брудник С.С. и др. «Экономическое содержание дипломных проектов», М.: ГАНГ, 1990г.

2. Брудник С.С., Кочегарова И.А., Степин Ю.П., Чикиров А.Б., «Определение экономической эффективности программных средств в АСУ» –М.: ГАНГ, 1995г.

3. Обучающая программа «Расчет экономической эффективности промышленной продукции»

еще рефераты
Еще работы по информатике, программированию