Вы находитесь на странице: 1из 64

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ЮЖНО-УРАЛЬСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

681.3 (076.5)+681.3(076.5)
П121

С. Т. Касюк

КУРСОВАЯ РАБОТА
ПО ДИСЦИПЛИНЕ «ИНФОРМАТИКА»

Методическое руководство
для студентов специальности 210100

Челябинск
2006
Министерство образования и науки Российской Федерации
Южно-Уральский государственный университет
Кафедра «Автоматика и управление»

681.3 (076.5)+681.3(076.5)
П121

С.Т. Касюк

КУРСОВАЯ РАБОТА
ПО ДИСЦИПЛИНЕ «ИНФОРМАТИКА»

Методическое руководство
для студентов специальности 210100

Одобрено учебно-методическим советом


приборостроительного факультета

Челябинск
2006
УДК 681.5(076.5)+681.3(076.5)

АННОТАЦИЯ

Касюк С. Т. Курсовая работа по дисциплине «Информатика»: Методическое


руководство для студентов специальности 210100. — Челябинск: Из-во ЮУрГУ,
2006. — ___ с, ил. ___

Методическое руководство предназначено для студентов специальности


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

Ил. _____, список лит. — _______ назв.

Одобрено учебно-методической комиссией приборостроительного факультета.

Рецензент: ___________

© Издательство ЮУрГУ, 2006.


ПРЕДИСЛОВИЕ

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


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

С. Т. Касюк
Челябинск, 2006 г.

3
ГЛАВА 1. ПОСТАНОВКА ЦЕЛИ И ЗАДАЧ КУРСОВОЙ РАБОТЫ

1.1. Введение в базы данных

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


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

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

Системы управления базами данных (СУБД) — это компьютерные


программы, которые помогают сохранять, вызывать, сортировать, анализировать,
и распечатывать информацию, хранящуюся в БД.
В СУБД информация хранится в таблице, которая очень напоминает
электронные таблицы. Заголовки колонок называют именами полей, а сами
колонки — полями. Строки данных называют записями. В строках таблицы
хранится информация об элементах, — ими могут оказаться люди, компании,
продукты, детали, заказы и т.п. В столбцах содержатся конкретные данные об
элементах. Если строки таблицы соответствуют людям, то в таблице среди прочих
могут быть столбцы для фамилии и адреса. Как правило, база данных включает
несколько таблиц.
Каждая таблица БД содержит ключевое поле или «ключ». Ключевое поле —
поле, содержащее уникальное значение, полностью идентифицирующее запись
таблицы. По значению ключевого поля всегда можно однозначно сказать о какой
записи идет речь, не может существовать двух записей с одинаковыми
«ключами».
В СУБД должны быть реализованы следующие операции над данными:
1) операция «Запомнить», позволяющая занести в базу данных новую запись;
2) операция «Обновить», позволяющая изменять значение элементов

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

1.3. Физическая организация данных в СУБД

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


реализованных с помощью двумерных или n-мерный массивов данных, либо
древовидных иерархических структур, либо сетевых структур, представляющих
собой сложную многосвязную структуру с большим количеством взаимных
соединений и т.д.
Наиболее простой формой организации таблицы в памяти ЭВМ является
использование двунаправленных связанных списков. Каждый узел списка
содержит: 1) адресные поля — адреса предыдущего и следующего узлов; 2) поля
информации — данные, которые содержатся в записи таблицы. Наличие адресных
полей позволяет размещать узлы списка произвольно в любом свободном участке
оперативной памяти, при этом последовательность расположения задается
указателями.

1.4. Цель курсовой работы

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


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

1.5. Задачи курсовой работы

Для достижения поставленной цели студенту необходимо решить


следующие задачи:
1. Разработать структуру программной системы.
2. Спроектировать структуру хранения информации БД в оперативной
памяти и в файле на жестком диске.
3. Разработать алгоритмы работы программных компонентов и модулей.
4. Разработать интерфейс оператора.
5. Произвести кодирование программных модулей и сборку системы.
6. Произвести тестирование и отладку системы.
7. Разработать руководство оператора программы.
В приложении 1 приведен бланк задания на курсовой проект.

5
1.6. Требования к составу и оформлению пояснительной записки

Состав пояснительной записки должен быть следующий:


1. Титульный лист.
2. Задание на курсовой проект (бланк задания приведен в приложении 1).
3. Аннотация.
4. Содержание.
5. Введение.
6. Главы основной части:
6.1. Постановки цели и задач курсового проектирования.
6.2. Основные этапы и технологии разработки программных систем.
6.3. Разработка программного комплекса:
6.3.1. Проектирование программной системы.
6.3.2. Кодирование и тестирование модулей.
6.3.3. Сборка и тестирование системы.
6.3.4. Эксплуатация и сопровождение системы.
6.4. Разработка руководства оператора программного комплекса.
6.5. Раздел охраны труда оператора.
7. Заключение.
8. Литература.
Приложение А. Текст программы.
Приложение В. Схема программы.
Приложение С. Распечатка файла с базой данных.
Оформление пояснительной записки осуществляется согласно стандарта
СТП ЮУрГУ 04-2001 «Курсовое и дипломное проектирование. Общие
требования к оформлению».

6
2. ОСНОВНЫЕ ЭТАПЫ И ТЕХНОЛОГИИ
РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ

2.1. Фундаментальные процессы разработки ПО

Cуществуют фундаментальные базовые процессы, без реализации которых


не может обойтись ни одна технология разработки программных продуктов:
1. Разработка спецификации ПО. Это фундамент любой программной
системы. Спецификация определяет все функции и действия, которые будет
выполнять разрабатываемая система.
2. Проектирование и реализация ПО. Это процесс непосредственного
создания ПО на основе спецификации.
3. Аттестация ПО. Разработанное программное обеспечение должно быть
аттестовано на соответствие требованиям заказчика.
4. Эволюция ПО. Любые программные системы должны модифицироваться
в соответствии с изменениями требований заказчика.

2.2. Модели процесса создания ПО

Модель процесса создания программного обеспечения — это общее


абстрактное представление данного процесса. Каждая такая модель представляет
процесс создания ПО в каком-то своем «разрезе», используя только
определенную часть всей информации о процессе.
Основные модели создания программного обеспечения следующие:
1. Каскадная модель. Основные базовые виды деятельности, выполняемые
в процессе создания ПО (спецификации, проектирование и производство,
аттестация и модернизация ПО), представляются как отдельные этапы этого
процесса.
2. Эволюционная модель разработки ПО. Здесь последовательно
перемежаются этапы формирования требований, разработки ПО и его аттестации.
Первоначальная программная система быстро разрабатывается на основе
некоторых абстрактных общих требований. Затем они уточняются и
детализируются в соответствии с требованиями заказчика. Далее система
дорабатывается и аттестуется в соответствии с новыми уточненными
требованиями.
3. Модель формальной разработки систем. Модель основана на
разработке формальной математической спецификации программной системы и
преобразовании этой спецификации посредством специальных математических
методов в исполняемые программы. Проверка соответствия спецификации и
системных компонентов также выполняется математическими методами.
4. Модель разработки ПО на основе ранее созданных компонентов.
Предполагается, что отдельные составные части программной системы уже
существуют, т.е. созданы ранее. В этом случае технологический процесс создания

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

2.3. Каскадная модель

Основные принципиальные этапы каскадной модели отражают все базовые


виды деятельности, необходимые для создания ПО:
1. Анализ и формирование требований. Путем консультаций с заказчиком
ПО определяются функциональные возможности, ограничения и цели
создаваемой программной системы.
2. Проектирование системы и программного обеспечения. Процесс
проектирования системы разбивает системные требования на требования,
предъявляемые к аппаратным средствам, и требования к программному
обеспечению системы. Разрабатывается общая архитектура системы.
Проектирование ПО предполагает определение и описание основных
программных компонентов и их взаимосвязей.
3. Кодирование и тестирование программных модулей. На этой стадии
архитектура ПО реализуется в виде множества программ или программных
модулей. Тестирование каждого модуля включает проверку его соответствия
требованиям к данному модулю.
4. Сборка и тестирование системы. Отдельные программы и
программные модули интегрируются и тестируются в виде целостной системы.
Проверяется, соответствует ли система своей спецификации.
5. Эксплуатация и сопровождение системы. Обычно (хотя и не всегда)
это самая длительная фаза жизненного цикла ПО. Система инсталлируется, и
начинается период ее эксплуатации. Сопровождение системы включает
исправление ошибок, которые не были обнаружены на более ранних этапах
жизненного цикла, совершенствование системных компонентов и "подгонку"
функциональных возможностей системы к новым требованиям.
К недостаткам каскадной модели можно отнести негибкое разбиение
процесса создания ПО на отдельные фиксированные этапы. В этой модели
определяющие систему решения принимаются на ранних этапах и затем их
трудно отменить или изменить, особенно это относится к формированию
системных требований. Поэтому каскадная модель применяется тогда, когда
требования формализованы достаточно четко и корректно.

8
2.4. Эволюционная модель

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


версия программного продукта, которая передается на испытание пользователям,
затем она дорабатывается с учетом мнения пользователей, получается
промежуточная версия продукта, которая также проходит испытание
пользователем , снова дорабатывается и так несколько раз, пока не будет получен
необходимый программный продукт. Отличительной чертой данной модели
является то, что процессы специфицирования, разработки и аттестации ПО
выполняются параллельно при постоянном обмене информацией между ними.
Различают два подхода к реализации эволюционного метода разработки:
1. Подход пробных разработок. Здесь большую роль играет постоянная
работа с заказчиком (или пользователями) для того, чтобы определить полную
систему требований к ПО, необходимую для разработки конечной версии
продукта. В рамках этого подхода вначале разрабатываются те части системы,
которые очевидны или хорошо специфицированы. Система эволюционирует
(дорабатывается) путем добавления новых средств по мере их предложения
заказчиком.
2. Прототипирование. Здесь целью процесса эволюционной разработки
ПО является поэтапное уточнение требований заказчика и, следовательно,
получение законченной спецификации, определяющей разрабатываемую систему.
Прототип обычно строится для экспериментирования с той частью требований
заказчика, которые сформированы нечетко или с внутренними противоречиями.
Эволюционный подход часто более эффективен, чем подход, построенный
на основу каскадной модели, особенно если требования заказчика могут меняться
в процессе разработки системы. Достоинством процесса создания ПО,
построенного на основе эволюционного подхода, является то, что здесь
спецификация может разрабатываться постепенно, по мере того как заказчик (или
пользователи) осознает и сформулирует те задачи, которые должно решать
программное обеспечение. Вместе с тем данный подход имеет и некоторые
недостатки:
1. Многие этапы процесса создания ПО не документированы.
Менеджерам проекта создания ПО необходимо регулярно документально
отслеживать выполнение работ. Но если система разрабатывается быстро, то
экономически не выгодно документировать каждую версию системы.
2. Система часто получается плохо структурированной. Постоянные
изменения в требованиях приводят к ошибкам и упущениям в структуре ПО. Со
временем внесение изменений в систему становится все более сложным и
затратным.
3. Часто требуются специальные средства и технологии разработки
ПО. Это вызвано необходимостью быстрой разработки версий программного
продукта. Но, с другой стороны, это может привести к несовместимости
некоторых применяемых средств и технологий, что, в свою очередь, требует
наличия в команде разработчиков специалистов высокого уровня.
9
Эволюционный подход наиболее приемлем для разработки небольших
программных систем (до 100000 строк кода) и систем среднего размера (до
500000 строк кода) с относительно коротким сроком жизни.

2.5. Формальная разработка систем

Этот подход к созданию ПО имеет много черт, сходных с каскадной


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

2.6. Разработка ПО на основе ранее созданных компонентов

В большинстве программных проектов применяется повторное


использование некоторых программных модулей. Это обычно случается там, где
разработчики проекта знают о ранее созданных программных продуктах, в
составе которых есть компоненты, приблизительно удовлетворяющие
требованиям разрабатываемых компонентов. Компоненты модифицируются в
соответствии с новыми требованиями и затем включается в состав новой системы.
Этапы разработки следующие:
1. Анализ компонентов. Имея спецификацию требований, на этом этапе
осуществляется поиск компонентов, которые могли бы удовлетворить
сформулированным требованиям. Обычно невозможно точно сопоставить
функции, реализуемые готовыми компонентами, и функции, определенные
спецификацией требований.
2. Модификация требований. На этой стадии анализируются требования с
учетом информации о компонентах, полученной на предыдущем этапе.
Требования модифицируются таким образом, чтобы максимально использовать
возможности отобранных компонентов. Если изменение требований невозможно,
повторно выполняется анализ компонентов для того, чтобы найти какое-либо
альтернативное решение.

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

2.7. Проектирование и реализация ПО

Реализация программного обеспечения — это процесс перевода системной


спецификации в работоспособную систему. Этап реализации всегда включает
процессы проектирования и программирования, но если для разработки ПО
применяется эволюционный подход, этап реализации также может включать
процесс внесения изменений в системную спецификацию.
На этапе проектирования ПО определяется его структура, данные, которые
являются частью системы, интерфейсы взаимодействия системных компонентов и
иногда используемые алгоритмы. Проектировщики сразу никогда не получают
законченный результат — процесс проектирования обычно проходит через
разработку нескольких промежуточных версий ПО. Проектирование предполагает
последовательную формализацию и детализацию создаваемого ПО с
возможностью внесения изменений в решения, принятые на более ранних стадиях
проектирования.
Основные этапы процесса проектирования следующие:
1. Архитектурное проектирование. Определяются и документируются
подсистемы и взаимосвязи между ними.
2. Обобщенная спецификация. Для каждой подсистемы разрабатывается
обобщенная спецификация на ее сервисы и ограничения.
3. Проектирование интерфейсов. Для каждой подсистемы определяется и
документируется ее интерфейс. Спецификации на эти интерфейсы должны быть
точно выраженными и однозначными, чтобы использование подсистем не
требовало знаний о том, как они реализуют свои функции.
4. Компонентное проектирование. Проводится распределение системных
функций (сервисов) по различным компонентам и их интерфейсам.
5. Проектирование структур данных. Детально разрабатываются
структуры данных, необходимые для реализации программной системы.
6. Проектирование алгоритмов. Детально разрабатываются алгоритмы,
предназначенные для реализации системных сервисов.

11
2.8. Методы проектирования

Во многих проектах разработки ПО процесс проектирования выполняется с


помощью специально подобранных методов. Наиболее разработанным подходом к
проектированию ПО обладают так называемые структурные методы, которые
предлагают множество формализованных нотаций и нормативных руководств для
проектирования программных продуктов. В качестве примера таких методов
можно назвать структурное проектирование, структурный анализ систем, а также
разнообразные методы, основанные на объектно-ориентированном подходе.
Каждый структурный метод включает такие компоненты, как модель
процесса проектирования, стандартизованные нотации для представления
структуры системы, форматы. Учетов, правила и нормативные указания по
проектированию. Хотя разработано большое количество таких методов, они
имеют нечто общее. Структурные методы поддерживают или по крайней мере
некоторые из перечисленных ниже моделей систем.
1. Модель потоков данных, где система моделируется в виде потока данных,
преобразуемых в этой системе.
2. Модель «сущность-связь», которая применяется для описания сущностей
(объектов программной системы) и связей между ними. Эта модель часто
используется при проектировании структур баз данных.
3. Структурная модель, предназначенная для документирования системных
компонентов и их взаимосвязей.
4. Объектно-ориентированные методы, с помощью которых получают
иерархическую модель системы, модели статических и динамических отношений
между объектами и модель взаимодействия объектов во время работы системы.

2.9. Программирование и отладка

Процесс программирования обычно следует непосредственно за процессом


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

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

2.10. Аттестация программных систем

Аттестация ПО, или более обобщенно — верификация и аттестация,


предназначена показать соответствие системы ее спецификации, а также
ожиданиям и требованиям заказчика и пользователей. К процессу аттестации
также можно отнести элементы контроля, такие как инспекция и оценивание,
которые выполняются на каждом этапе создания ПО — от формирования общих
требований до кодирования программ. Однако основные действия по аттестации
выполняются после завершения реализации — на этапе тестирования
законченной системы.
Процесс тестирования состоит из нескольких этапов.
1. Тестирование компонентов. Тестируются отдельные компоненты для
проверки правильности их функционирования. Каждый компонент тестируется
независимо от других.
2. Тестирование модулей. Программный модуль — это совокупность
зависимых компонентов, таких как описание класса объектов, декларирование
абстрактных типов данных и набор процедур и функций. Каждый модуль
тестируется независимо от других системных модулей.
3. Тестирование подсистем. Тестируются наборы модулей, которые
составляют отдельные подсистемы. Основная проблема, которая часто
проявляется на этом этапе, — несогласованность модульных интерфейсов.
Поэтому при тестировании подсистем основное внимание уделяется
обнаружению ошибок в модульных интерфейсах путем прогона их через все
возможные режимы.
4. Тестирование системы. Из подсистем собирается конечная система. На
этом этапе основное внимание уделяется совместимости интерфейсов подсистем
и обнаружению программных ошибок, которые проявляются в виде
непредсказуемого взаимодействия между подсистемами. Здесь также проводится
аттестация системы, т.е. проверяется соответствие системной спецификации ее
функциональных и нефункциональных показателей, а также оцениваются
интеграционные характеристики системы.
5. Приемочные испытания. Это конечный этап процесса тестирования,
после которого система принимается к эксплуатации. Здесь система тестируется с
привлечением данных, предоставляемых заказчиком системы, а не на основе
тестовых данных, как было на предыдущем этапе. На этом этапе могут
проявиться ошибки, допущенные еще на этапе определения системных
требований, поскольку испытания с реальными данными могут дать иной
результат, чем тестирование со специально подобранными тестовыми данными.

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

2.11. Эволюция программных систем

Исторически сложилось так, что существует четкая «демаркационная


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

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

15
3. ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3.1. Проектирование программной системы

3.1.1. Архитектурное проектирование

Введение

Архитектурным проектированием называют первый этап процесса


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

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

Структурирование системы

На первом этапе процесса проектирования архитектуры система


разбивается на несколько взаимодействующих подсистем. На самом абстрактном
уровне архитектуру системы можно изобразить графически с помощью схемы, в
которой отдельные подсистемы представлены отдельными блоками. Если
подсистему также разбить на несколько частей, то эти части изображаются
прямоугольниками внутри больших блоков. Потоки данных и потоки управления
между подсистемами обозначается стрелками. Такая схема дает общее
представление о структуре системы.
Возможная структура разрабатываемой программной системы показана на
рис. 3.1.1. Данные хранится в подсистеме хранения информации. Оператор
программы через управляющую подсистему осуществляет доступ к подсистемам,
в которых реализованы: 1) сохранение БД, 2) загрузка БД, 3) ввод информации в
БД, 4) удаление информации из БД, 5) изменение информации в БД и 6) выборка
информации из БД по какому-либо критерию.

Оператор ЭВМ

Управляющая подсистема

Подсистема поиска Подсистема ввода, Подсистема


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

Файловая Подсистема хранения информации


система
компьютера

Рис. 3.1.1

Модели управления

В модели структуры системы показаны все подсистемы, из которых она


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

17
необходимо управлять ими. В структурных моделях нет никакой информации об
управлении. Однако разработчик архитектуры должен организовать подсистемы
согласно некоторой модели управления, которая дополняла бы имеющуюся
модель структуры. В моделях управления на уровне архитектуры проектируется
поток управления между подсистемами.
Можно выделить два основных типа управления в программных системах.
1. Централизованное управление. Одна из подсистем полностью отвечает
за управление, запускает и завершает работу остальных подсистем. Управление от
первой подсистемы может перейти к другой подсистеме, однако потом
обязательно возвращается к первой.
2. Управление, основанное на событиях. Здесь вместо одной подсистемы,
ответственной за управление, на внешние события может отвечать любая
подсистема. События, на которые реагирует система, могут происходить либо в
других подсистемах, либо во внешнем окружении системы.
Централизованное управление. В модели централизованного управления
одна из систем назначается главной и управляет работой других подсистем. Такие
модели можно разбить на два класса, в зависимости от того, последовательно или
параллельно реализовано выполнение управляемых подсистем:
1. Модель вызова-возврата. Это модель организации вызова программных
процедур «сверху вниз», в которой управление начинается на вершине иерархии
процедур и через вызовы передается на более нижние уровни иерархии. Данная
модель применима только в последовательных системах.
2. Модель диспетчера. Данная модель применяется в параллельных
системах. Один системный компонент назначается диспетчером и управляет
запуском, завершением и координированием других процессов системы.
Для разрабатываемой программной системе применимо централизованное
управление в котором реализована модель вызова-возврата. Возможная схема
работы разрабатываемой системы приведена на рис. 1.3.2. В управляющей
подсистеме существует цикл выбора подсистем: 1) на экран выводится экранное
меню, 2) оператором осуществляется выбор необходимой подсистемы и
3) осуществляется запуск подсистемы. Данные в подсистему хранения
информации загружаются из файла БД через подсистему работы с файлами.
Информация из БД может извлекаться, добавляться, обновляться,
просматриваться, удаляться и сортироваться. При этом оператору выводятся
соответствующие сообщения; он осуществляет выбор пунктов экранного меню и
ввод информации. Все изменения в БД сохраняются в файле.

18
3.1.2. Схема работы системы

19
Модульная декомпозиция

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


следует этап декомпозиции подсистем на модули.
Рассмотрим две модели, используемые на этапе модульной декомпозиции:
1. Объектно-ориентированная модель. Система состоит из набора
взаимодействующих объектов.
2. Модель потоков данных. Система состоит из функциональных модулей,
которые получают на входе данные и преобразуют их некоторым образом в
выходные данные. Такой подход часто называется конвейерным.
В объектно-ориентированной модели модули представляют собой объекты
с собственными состояниями и определенными операциями над этими
состояниями. В модели потоков данных модули выполняют функциональные
преобразования. В обеих моделях модули реализованы либо как
последовательные компоненты, либо как процессы.
Объектные модели. Объектно-ориентированная архитектурная модель
структурирует систему в виде совокупности слабо связанных объектов с четко
определенными интерфейсами. Объекты вызывают сервисы, предоставляемые
другими объектами.
Преимущества объектно-ориентированного подхода хорошо известны.
Поскольку объекты слабо связаны между собой, можно изменять реализацию того
или иного объекта, не воздействуя на остальные объекты. Структуру системы
легко понять, так как объекты часто являются объектами реального мира. Для
непосредственной реализации системных компонентов можно использовать
объектно-ориентированные языки программирования.
Вместе с тем объектно-ориентированный подход имеет и недостатки. При
использовании сервисов объекты должны явно ссылаться на имена других
объектов и знать их интерфейс. Если при изменении системы требуется изменить
интерфейс, необходимо оценить эффект от такого изменения с учетом всех
пользователей изменяемого объекта.
Многие объекты реального мира сложно представить в виде системных
объектов.
Модели потоков данных. В управляемой потоками данных модели данные
проходят через последовательность преобразований. Каждый шаг обработки
данных реализован в виде преобразования. Данные, поступающие на вход
системы, проходят через все преобразования и достигают выхода системы.
Преобразования могут выполняться последовательно или параллельно. Обработка
данных может быть пакетной или поэлементной.
Если преобразования представлены в виде отдельных процессов, такую
модель иногда называют конвейером или моделью фильтров. Последняя
поддерживает конвейеры, которые действуют как хранилища данных, и набор
команд, представляющих функциональные преобразования. Здесь используется
термин «фильтр», поскольку преобразование «фильтрует» данные во время
обработки потока данных.
20
Различные варианты модели потоков данных возникли вместе с появлением
первых компьютеров, предназначенных для автоматизированной обработки
данных. Когда преобразования последовательно обрабатывают пакеты данных,
такая архитектурная модель называется пакетной последовательной моделью.
Она является основой для многих классов систем обработки данных. Примером
могут быть системы (например, системы обработки счетов), которые генерируют
большое количество выходных отчетов, полученных с помощью несложных
вычислений, но с большим количеством входных записей.
Применительно к поставленной задаче разработки СУБД необходимо
использовать объектную модель. Модульная декомпозиция разрабатываемой
программной системы будет следующая:
• Управляющая подсистема — функция main().
• Подсистема хранения информации — динамическая информационная
структура двунаправленный связанный список.
• Подсистема работы с файлами: функция сохранения данных save() и
функция загрузки данных из файла load().
• Подсистема просмотра и поиска записей: функция вывода
содержимого базы данных на экран print() и функция выборки
информации из базы данных по какому-либо критерию query().
• Подсистема ввода, удаления и обновления данных: функция ввода
новой записи в базу данных input(), функция удаление записи из базы
данных delete(), функция изменения значений элементов
существующих в базе данных записей refresh().

3.1.2. Проектирование структуры данных

Таблицу БД (подсистему хранения информации) целесообразно реализовать


в виде двунаправленного линейного связанного списка (см. рис. 3.1.3).
Достоинство данной реализации заключается в том, что над списком могут
выполняться все операции, реализуемые над записями в СУБД:
• получение доступа к k-му узлу для проверки или изменения
содержимого его полей;
• вставка нового узла сразу после или до k-го узла;
• удаление k-го узла;
• сортировка узлов в порядке возрастания значений в определенных
полях этих узлов;
• поиск узла с заданным значением в некотором поле.
Реализация двунаправленного связанного списка на языке Си не
представляет трудностей. Узел списка — структура, имеющая следующие поля:
prior — поле адреса предыдущего элемента; next — поле адреса следующего
элемента; info — данные, которые хранятся в записи. Доступ к списку
осуществляется через глобальный указатель FIRST.

21
Рис. 3.1.3. Графическое представление
линейного двунаправленного связанного списка

3.1.3. Проектирование интерфейсов


программных модулей

Программа будет состоять из набора функций: void main(void),


void save(void), void load(void), void input(void), void delete(void), void print(void),
void query(void), void refresh(void), void sort(void). Вызов функций, реализующих
основные операции СУБД, будет осуществляться оператором из функции main().
После выполнения операции над данными, происходит возврат в вызывающую
функцию. Все функции не имеют формальных параметров и не возвращают
значений.
Доступ к двунаправленному связанному списку из функций можно
осуществить через глобальный указатель FIRST, для удобства работы со списком
можно использовать ещё одну переменную n — количество записей.
В таблице 3.1 представлен вариант использования переменные FIRST и n в
функциях («+» — переменная используется; «-» — переменная не используется).

Таблица 3.1

Переменные Использование Использование


глобального указателя глобальной переменной
Функции
FIRST n
void main(void) - -
void save(void) + +
void load(void) + +
void input(void) + +
void delete(void) + +
void print(void) + -
void query(void) + -
void refresh(void) + -
void sort(void) + -

22
3.1.4. Проектирование алгоритмов

Функция main()

В функции main() организован бесконечный цикл, в котором: 1) на экран


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

Функция save()

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


Если информация в оперативной памяти имеется, то производятся следующие
действия:
1. Открытие файла.
2. Запись в файл количество записей n.
3. В цикле поля записей сохраняются в файле. Для доступа к узлам
используется указатель p1, который первоначально инициализируется значением
указателя FIRST. Перемещение указателя по узлам осуществляется следующим
образом: p1=p1->next.
4. Файл закрывается и функция заканчивает работу.
На рис. 1.3.5. приведена возможная схема функции save().

Функция load()

Функция производит проверку наличия данных в оперативной памяти. Если


информация в оперативной памяти имеется, то у оператора запрашивается, нужно
ли производить загрузку. В случае положительного ответа, содержимое БД в
оперативной памяти будет утеряно.
Загрузка данных производится следующим образом:
1. Происходит открытие файла.
2. Считывается количество записей.
3. В цикле производится формирование списка и запись данных в узлы.
После выполнения цикла файл закрывается, и функция заканчивает работу.
На рис. 1.3.6. приведена возможная схема функции load().

23
Рис. 1.3.4. Схема функции main()

24
Рис. 1.3.5. Схема функции save()

25
Рис. 1.3.6. Функция load()

Функция input()

Функция производит проверку наличия данных в оперативной памяти. Если


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

26
1. Глобальная переменная n увеличивается на единицу.
2. Выделяется память под новую запись.
3. Производится ввод данных в запись.
Затем файл закрывается, и функция заканчивает работу.
На рис. 1.3.7 приведена возможная схема функции input().

Рис. 1.3.7. Схема функции input()

Функция delete()

Функция производит проверку наличия данных в оперативной памяти. Если


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

27
Рис. 1.3.8. Схема функции delete().

Функция print()

Функция производит проверку наличия данных в оперативной памяти. Если


БД в оперативной нет, то функция заканчивает работу.
Информация из записей таблицы выводится в цикле на экран. Для
просмотра узлов списка используется указатель p1, значение которого изменяется
следующим образом: p1=p1->next.
На рис. 1.3.9 приведена возможная схема функции print().

28
Рис. 1.3.9. Схема функции print().

Функция query()

Функция производит проверку наличия данных в оперативной памяти. Если


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

29
Рис. 1.3.10. Схема функции query()

Функция refresh()

Функция производит проверку наличия БД в оперативной памяти. Если


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

30
Рис. 1.3.11. Схема функции refresh()

Функция sort()

Функция производит проверку наличия данных в оперативной памяти. Если


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

31
Рис. 1.3.12. Схема функции sort()

3.1.5. Проектирование интерфейса оператора

Введение

Проектирование вычислительных систем охватывает широкий спектр


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

Принципы проектирования интерфейса

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


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

32
• Руководство оператора. Интерфейс должен предоставлять
необходимую информацию в случае ошибок оператора и поддерживать средства
контекстно-зависимой справки.
• Учет разнородности пользователей. В интерфейсе должны быть
средства для удобного взаимодействия с пользователями, имеющими разный
уровень квалификации и различные возможности.
В интерфейсах должны быть средства, по возможности предотвращающие
ошибки пользователя, а также позволяющие корректно восстановить
информацию после ошибок. Эти средства бывают двух видов:
1. Подтверждение деструктивных действий. Если пользователь выбрал
потенциально деструктивную операцию, то он должен еще раз подтвердить свое
намерение.
2. Возможность отмены действий. Отмена действия возвращает систему в
то состояние, в котором она находилась до их выполнения. Не лишней будет
поддержка многоуровневой отмены действий, так как пользователи не всегда
сразу понимают, что совершили ошибку.

Взаимодействие с оператором

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


обеспечения с оператором ЭВМ:
1. Непосредственное манипулирование. Оператор взаимодействует с
объектами на экране. Например, для удаления файла оператор просто
перетаскивает его в корзину.
2. Выбор из меню. Оператор выбирает команду из списка пунктов меню.
Очень часто выбранная команда воздействует только на тот объект, который
выделен на экране. При таком подходе для удаления файла пользователь сначала
выбирает файл, а затем команду на удаление.
3. Заполнение форм. Оператор заполняет поля экранной формы. Некоторые
поля могут иметь свое меню (выпадающее меню или списки). В форме могут
быть командные кнопки, при щелчке мышью на которых инициируют некоторое
действие. Чтобы удалить файл с помощью интерфейса, основанного на форме,
надо ввести в поле формы имя файла и затем щелкнуть на кнопке удаления,
присутствующей в форме.
4. Командный язык. Оператор вводит конкретную команду с параметрами,
чтобы указать системе, что она должна дальше делать. Чтобы удалить файл,
оператор вводит команду удаления с именем файла в качестве параметра этой
команды.
5. Естественный язык. Пользователь вводит команду на естественном
языке. Чтобы удалить файл, пользователь может ввести команду «удалить файл с
именем XXX».

33
Представление информации

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


данных пользователям. Данные в системе могут отображаться по-разному:
например, вводимая информация может отображаться непосредственно на
дисплее (например, текст в текстовом редакторе) или преобразовываться в
графическую форму. Хорошим тоном при проектировании систем считается
отделение представления данных от самих данных.
Чтобы найти наилучшее представление информации, необходимо знать, с
какими данными работают пользователи и каким образом они применяются в
системе. Принимая решение по представлению данных, разработчик должен
учитывать ряд факторов:
1. Что нужно пользователю — точные значения данных или соотношения
между значениями?
2. Насколько быстро будут происходить изменения значений данных?
Нужно ли немедленно показывать пользователю изменение значений?
3. Должен ли пользователь предпринимать какие-либо действия в ответ на
изменение данных?
4. Нужно ли пользователю взаимодействовать с отображаемой
информацией посредством интерфейса с прямым манипулированием?
5. Информация должна отображаться в текстовочисловом формате? Важны
ли относительные значения элементов данных?

Требования к интерфейсу оператора в курсовой работе

При запуске программы на экран должно выводится меню СУБД с


указанием основных функций программы, для вызова которых оператор должен
выбрать соответствующий пункт (см. рис. 1.3.13). В рамках данной курсовой
работы не предусматривается разработка графического интерфейса оператора,
поэтому для вызова различных функций можно использовать запрос номера
функции с помощью scanf(). При выполнении операций над данными программа
должна генерировать соответствующие сообщения оператору, который в ответ на
них выбирает различные опции — вводит номера с помощью функции scanf().
Ввод информации в БД можно организовать с помощью следующий функций:
scanf() — числа и строки без пробелов; gets() — строки с пробелами; getchar() —
символы. Перед выводом информации целесообразно производить очистку экрана
с помощью функции clrscr(). Задавать положение курсора можно с помощью
функций gotoxy() и printf().

34
Меню оператора ЭВМ:
1. Сохранение данных в файле.
2. Загрузка базы данных из файла.
3. Ввод новой записи в базу данных.
4. Удаление записи из базы данных.
5. Вывод на экран содержимого базы данных.
6. Выборка информации из базы данных.
8. Сортировка записей в базе данных.
9. Изменение значений элементов записей.
0. Окончание работы с программой.

Выберите пункт меню:

Рис. 1.3.13. Пример экранного меню СУБД

3.2. Кодирование и тестирование функций

3.2.1. Введение в кодирование

Процесс кодирования (программирования) обычно следует непосредственно


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

3.2.2. Узел списка и глобальные переменные

Записи таблицы БД будут хранится в узле списка, реализованном в виде


следующей структуры:

35
struct NODE
{
struct NODE *prior; /*указатель на предыдущий элемент*/
struct NODE *next; /*указатель на следующий элемент*/
тип_1 имя_поля_1; /*объявление информационных полей*/
тип_2 имя_поля_2;
тип_3 имя_поля_3;
………………………………………….
тип_n имя_поля_n;
};

Для работы со списком применяются глобальные указатели

struct NODE *p1,*p2, *p3; /* дополнительные указатели */


/* для работы со списком */

также используется указатель FIRST, хранящий адрес начала списка:

struct NODE *FIRST; /*указатель на первый элемент списка*/

3.2.2. Главная функция main()

В функции main() реализован механизм управления БД с помощью


экранного меню. В бесконечном цикле while происходит очистка экрана, вывод на
экран меню и запрос у оператора пункта меню. Затем с помощью оператора switch
происходит выбор и вызов необходимой функции. В случае, если оператор
выбрал нулевой пункт, происходит выход из программы с помощью функции
exit().
Текст функции main() приведен ниже:

void main()
{
int NOP; /*номер пункта в меню оператора*/
while(1) /*цикл для работы с базой*/
{
clrscr();
printf("\n\t Меню оператора ЭВМ:");
printf("\n\t 1. Сохранение данных в файле.");
printf("\n\t 2. Загрузка базы данных из файла.");
printf("\n\t 3. Ввод новой записи в базу данных.");
printf("\n\t 4. Удаление записи из базы данных.");
printf("\n\t 5. Вывод на экран содержимого базы
данных.");

36
printf("\n\t 6. Выборка информации из базы
данных.");
printf("\n\t 8. Сортировка записей в базе данных.");
printf("\n\t 9. Изменение значений элементов
записей.");
printf("\n\t 0. Окончание работы с программой.");

printf("\n\n\t Выберите пункт меню: ");


scanf("%u",&NOP); /*ввод номера пункта меню*/

switch(NOP) /*выбор одной из функций*/


{
case 1:
save();
break;
case 2:
load();
break;
case 3:
input();
break;
case 4:
delete();
break;
case 5:
print();
break;
case 7:
query();
break;
case 8:
sort();
break;
case 9:
refresh();
break;
case 0:
exit();
default:
printf("\n\tНеверно! Такого пункта меню не
существует.");
}
}
}

37
3.2.3. Функция сохранения данных в файле save()

Функция save() производит запись в файл содержимого таблицы БД.


Функция производит проверку наличия БД в оперативной памяти, если значение
указателя FIRST равно NULL, то работа функции завершается.
Функция открывает файл database.txt в режиме записи. В файл
записывается количество узлов n. В цикле производится сохранение информации
из узлов списка в файле с помощью функции fpintf(). Просмотр узлов
производится с помощью указателя p1, который первоначально
инициализируется значением FIRST. Цикл заканчивается в случае, если в
указатель p1 было записано значение NULL из поля next последнего узла.

void save()
{
clrscr();
if(FIRST==NULL)
{
printf("\n\tДанных в оперативной памяти нет.");
printf("\n\tЗапись в файл не производится.");
getch();
return;
}

p1=FIRST; /*перемещение на начало списка*/

FILE *stream; /*открытие файла для записи*/

if((stream=fopen("database.txt","w"))==NULL)
{
реrrоr("Ошибка открытия файла.");
return;
}

fprintf(stream,"%u\n", n);

do
{
fprintf(stream,"%формат_1",p1->имя_поля_1);
fprintf(stream,"%формат_2",p1->имя_поля_2);
fprintf(stream,"%формат_3",p1->имя_поля_3);
…………………………………………………………………………………………………………………
fprintf(stream,"%формат_n",p1->имя_поля_n);
/* Запись в файл данных из полей*/

38
/* с помощью функции fprintf().*/

p1=p1->next; /*перемещение по списку*/

while(p1!=NULL);

fclose(stream); /*закрытие файла*/


printf("\n\tБaзa данных сохранена в файле
DATABASE.txt");
getch();
}

3.2.4. Функция загрузки данных из файла load()

Функция load() проверяет, есть ли БД в оперативной памяти. При наличии


данных, выводится предупреждение «Содержимое базы в оперативной памяти
будет утеряно», и у оператора запрашивается, нужно ли производить загрузку.
При загрузке данных открывается файл database.txt в режиме чтения. Из
файла считывается количество записей в таблице n. Далее формируется узел
списка, в поля prior и next которого запивается значение NULL. В
информационные поля узла загружаются данные из файла с помощью функции
fscanf(). В цикле производится выделение памяти под узлы и подключение узлов к
списку, а также загрузка данных из файла в узлы.
Текст функции load() приведен ниже:

void load()
{
int punct;
clrscr();

if(FIRST!=NULL) /*В оперативной памяти*/


/*имеется база данных.*/
{
printf("\n\tСодержимое базы в оперативной памяти
будет утеряно!");
printf("\n\tПродолжить?");
printf("\n\n\t1) Да. 2) Heт.");
scanf("%d",&punct);
if(punct=2)
return;
}

FILE *stream; /*Объявление указателя на файл.*/


n=0; /*Количество записей в базе данных.*/
39
if((stream=fopen("database.txt","r"))==NULL)
{
реrrоr("Ошибка открытия файла.");
return;
}

fscanf(stream,"%u",&n);

FIRST=(struct NODE*)malloc(sizeof(struct NODE));


FIRST->prior=NULL;
p1=FIRST;
fscanf(stream,"%формат_1",&FIRST->имя_поля_1);
fscanf(stream,"%формат_2",&FIRST->имя_поля_2);
fscanf(stream,"%формат_3",&FIRST->имя_поля_3);
………………………………………………………………………………………………………………
fscanf(stream,"%формат_3",&FIRST->имя_поля_n);

for(i=1;i<=n-1;i++)
{
p1->next=(struct NODE*)malloc(sizeof(struct NODE));
p2=p1;
p1=p1->next;

fscanf(stream,"%формат_1",&p1->имя_поля_1);
fscanf(stream,"%формат_2",&p1->имя_поля_2);
fscanf(stream,"%формат_3",&p1->имя_поля_3);
………………………………………………………………………………………………………………
fscanf(stream,"%формат_3",&p1->имя_поля_n);

p1->prior=p2;
}
p1->ptrn2=NULL;

/*База данных загружена в ОЗУ.*/


printf("\n\tБaзa данных загружена из файла.");
getch();
}

3.2.5. Функция ввода новой записи в базу данных input()

Функция input() вводит новую запись в таблицу БД. Если БД в оперативной


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

void input()
{
int punct;
clrscr();
if(FIRST==NULL) /*Базы данных нет*/
/*в оперативной памяти.*/
{
printf("n\tБaзы данных нет в оперативной памяти.");
printf("\n\tПродолжить?");
printf("\n\n\t1) Да. 2) Heт.");
scanf("%u",&punct);
if(punct=2)
return;

FIRST=(struct NODE*)malloc(sizeof(struct NODE));


FIRST->prior=NULL;
FIRST->next=NULL;
printf("\n\tВведите значение поля 1:");
fscanf(stream,"%формат_1",&FIRST->имя_поля_1);
printf("\n\tВведите значение поля 2:");
fscanf(stream,"%формат_2",&FIRST->имя_поля_2);
printf("\n\tВведите значение поля 3:");
fscanf(stream,"%формат_3",&FIRST->имя_поля_3);
………………………………………………………………………………………………………………
printf("\n\tВведите значение поля n:");
fscanf(stream,"%формат_3",&FIRST->имя_поля_n);
}

p1=FIRST; /*Установка указателя на начало списка.*/


p2=(struct NODE *)malloc(sizeof(struct NODE));
/*Выделение памяти под новый узел.*/
FIRST=p2;
FIRST->prior=NULL;
FIRST->next=p1;

printf("\n\tВведите значение поля 1:");


scanf("%формат_1",&FIRST->имя_поля_1);

41
printf("\n\tВведите значение поля 2:");
scanf("%формат_2",&FIRST->имя_поля_2);
printf("\n\tВведите значение поля 3:");
scanf(stream,"%формат_3",&FIRST->имя_поля_3);
………………………………………………………………………………………………………………
printf("\n\tВведите значение поля n:");
scanf("%формат_n",&FIRST->имя_поля_n);
}

3.2.6. Функция удаление записи из базы данных delete()

Функция delete() осуществляет удаление записи из таблицы БД. Для


идентификации удаляемой записи у оператора запрашивается, какое значение
хранится в первом поле удаляемого узла.
Поиск адреса узла осуществляется в цикле while; результат поиска — адрес
узла p1. Удаление узла производится следующим образом:

p2=p1->prior;
p3=p1->next;
p2->next=p3;
p3->prior=p2;
free(p1);

Текст функции delete() приведен ниже:

void delete()
{
тип_1 pole_1;
clrscr();
if(FIRST==NULL) /*Базы данных нет*/
/*в оперативной памяти.*/
{
printf("\n\tБaзы данных нет в оперативной памяти.");
getch();
return;
}

printf("\n\tВведите значения поля 1 удаляемого узла:);


scanf("%формат_1",&pole_1);

p1=FIRST;

42
while(pole_1!=p1->поле_1||p!=NULL);
p=p->next;

if(p1==NULL)
{
printf("\n\tУдаляемый узел не найден.");
getch();
return;
}

p2=p1->prior;
p3=p1->next;
p2->next=p3;
p3->prior=p2;
free(p1); /*Освобождение памяти,*/
/*отведенной под узел.*/
}

3.2.7. Функция вывода содержимого базы данных на экран print()

Функция print() выводит на экран содержимое узлов начиная с первого,


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

void print()
{
int i=0;
clrscr();
if(FIRST==NULL)
{
printf("\n\tБaзы данных в оперативной памяти нет.");
getch();
return;
}

p1=FIRST;

while(p1!=NULL)
{
printf("\nЗапись %u:\n",i);
printf("\t%формат_1",pl->имя_поля_1);
printf("\t%формат_2",pl->имя_поля_2);
printf("\t%формат_3",pl->имя_поля_3);
43
………………………………………………………………………………………………
printf("\t%формат_n",pl->имя_поля_n);

p1=p1->next;
}
}
3.2.8. Функция выборки информации из базы данных
по какому-либо критерию query()

Функция query() проверяет наличие БД в оперативной памяти. Если данные


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

void query()
{
clrscr();
<тип> kritery; /*Критерий запроса.*/
if(FIRST==NULL) /*Базы данных нет */
/*в оперативной памяти.*/
{
printf("\n\tБaзы данных нет в оперативной памяти.");
getch();
return;
}

printf("\n\tВведите информацию для запроса:");


scanf("%<формат>", &kritery);

p1=FIRST;

printf("\n\tРезультат выполнения запроса\n");

while(p1!=NULL)
{
if(<критерий запроса … kritery >)
{
printf("%формат_1",p1->имя_поля_1);
printf("%формат_2",p1->имя_поля_2);
printf("%формат_3",p1->имя_поля_3);
……………………………………………………………………………………………
printf("%формат_n",p1->имя_поля_n);
}
pl=pl->next;

44
}
}

3.2.9. Функция изменения значений элементов существующих


в базе данных записей refresh()

Функция refresh() осуществляет проверку наличия БД в оперативной


памяти. Затем у оператора, для идентификации обновляемой записи,
запрашивается, какое значение хранится в первом поле удаляемого узла.
Поиск адреса узла осуществляется в цикле while; результат поиска — адрес
узла p1. Если значение p1 не равно NULL, то узел обнаружен. У оператора
запрашивается обновленная информация и сохраняется в узле.

void refresh()
{
clrscr();
if(FIRST==NULL) /*Базы данных нет */
/*в оперативной памяти.*/
{
printf("\n\tБaзы данных нет в оперативной памяти.");
getch();
return;
}

p1=FIRST;

printf("\n\tВведите значения поля 1 обновляемого узла:);


scanf("%формат_1",&pole_1);

p1=FIRST;

while(pole_1!=p1->поле_1||p!=NULL);
p=p->next;

if(p1==NULL)
{
printf("\n\Узел, в котором необходимо обновить
информацию, не найден.");
getch();
return;
}

printf("\n\tВведите значение поля 1:");


scanf("%формат_1",&FIRST->имя_поля_1);

45
printf("\n\tВведите значение поля 2:");
scanf("%формат_2",&FIRST->имя_поля_2);
printf("\n\tВведите значение поля 3:");
scanf(stream,"%формат_3",&FIRST->имя_поля_3);
………………………………………………………………………………………………………………
printf("\n\tВведите значение поля n:");
scanf("%формат_n",&FIRST->имя_поля_n);
}

3.2.10. Функция сортировки записей в базе данных sort()

Ниже приведена функция сортировки двунаправленного связанного списка,


использующая алгоритм сортировки слиянием. Данный алгоритм хорошо
зарекомендовал себя при сортировке списков. Функция sort() использует
дополнительную функцию-компаратор cmp(), которая вычисляет разность
значений в первом поле двух узлов с заданными адресами a и b.

/*Функция вычисления разности полей у двух узлов.*/

<тип> cmp(struct NODE *a, struct NODE *b)


{
return a-><поле_1> - b-><поле_1>;
}

void sort(void)
{

struct NODE *list=FIRST;


struct NODE *p, *q, *e, *tail, *oldhead;
int insize, nmerges, psize, qsize, i;
int is_circular=0;
int is_double=0;

if (!list) /*Если список пуст.*/


{
printf("\n\tБaзы данных нет в оперативной памяти.");
getch();
return;
}

insize = 1;

while (1)
{
p = list;
46
oldhead = list;
list = NULL;
tail = NULL;
nmerges = 0;
while (p)
{
nmerges++;
q = p;
psize = 0;
for (i = 0; i < insize; i++)
{
psize++;
if (is_circular)
q = (q->next == oldhead ? NULL : q->next);
else
q = q->next;
if (!q)
break;
}

qsize = insize;

while (psize > 0 || (qsize > 0 && q))


{
if (psize == 0)
{
e = q; q = q->next; qsize--;
if (is_circular && q == oldhead)
q = NULL;
}
else if (qsize == 0 || !q)
{
e = p; p = p->next; psize--;
if (is_circular && p == oldhead)
p = NULL;
}
else if (cmp(p,q) <= 0)
{
e = p; p = p->next; psize--;
if (is_circular && p == oldhead)
p = NULL;
}
else
{
47
e = q; q = q->next; qsize--;
if (is_circular && q == oldhead)
q = NULL;
}

if (tail)
{
tail->next = e;
}
else
{
list = e;
}

if (is_double)
{
e->prev = tail;
}

tail = e;
}

p = q;
}

if (is_circular)
{
tail->next = list;
if (is_double)
list->prev = tail;
}
else
tail->next = NULL;

if (nmerges <= 1)
{
FIRST=list;
return;
}
insize *= 2;
}
}

48
ГЛАВА 4. РУКОВОДСТВО ОПЕРАТОРА
ПРОГРАММНОЙ СИСТЕМЫ

Документация пользователя поставляется вместе с программной системой и


должна содержать следующие сведения:
1. Функциональное описание, в котором кратко представлены
функциональные возможности системы. Прочитав функциональное описание и
вводное руководство, пользователь должен определить, та ли это система, которая
ему нужна.
2. Информация по инсталляции системы. Здесь должны быть
представлены сведения о дисках, на которых поставляется система, описание
файлов, находящихся на этих дисках, и минимальные требования к
конфигурации. В документе должна быть инструкция по инсталляции и более
подробная информация по установке файлов, зависящих от конфигурации
системы.
3. Вводное руководство, представляющее неформальное введение в
систему, описывающее ее «повседневное» использование. В этом документе
должна содержаться информация о том, как начать работу с системой, как
использовать общие возможности системы. Все описания должны быть снабжены
примерами и содержать сведения о том, как восстановить систему после ошибки
и как начать заново работу.
4. Справочное руководство, в котором описаны возможности системы и их
использование, представлен список сообщений об ошибках и возможные
причины их появления, рассмотрены способы восстановления системы после
выявления ошибок.
5. Руководство администратора, необходимое для некоторых типов
программных систем. В нем дано описание сообщений, генерируемых системой
при взаимодействии с другими системами, и описаны способы реагирования на
эти сообщения. Если в систему включена аппаратная часть, то в руководстве
администратора должна быть информация о том, как выявить и устранить
неисправности, связанные с аппаратурой, как подключить новые периферийные
устройства и т.п.
Разработчикам программной системы обычно подготавливают для
заказчика следующие документы, согласно стандарту «Единая система
программной документации»:
• Описание программы. Данный документ содержит описание
программы согласно ГОСТ 19.402-78 «Описание программы». Структура
примерно следующая: титульный лист, аннотация, содержание, общие сведения,
функциональное назначение, описание логической структуры, используемые
технические средства, вызов и загрузка, входные данные, выходные данные и т.д.
• Текст программы. Документ содержит исходный текст программы
согласно ГОСТ 19.401-78 «Текст программы. Требования к содержанию и
оформлению». Структура документа следующая: титульный лист, аннотация, код
программы.
49
• Руководство оператора. Документ содержит описание работы
оператора с программным комплексом согласно ГОСТ 19.505-79 «Руководство
оператора. Требования к содержанию и оформлению». Структура документа
примерно следующая: титульный лист, аннотация, содержание, и т.д.
• Руководство системного программиста. Документ содержит
описание администрирования программного комплекса согласно ГОСТ 19.503-79
«Руководство системного программиста. Требования к содержанию и
оформлению». Структура документа примерно следующая: титульный лист,
аннотация, содержание, общие сведения о программе, структура программы,
настройка программы, проверка программы, дополнительные возможности,
сообщения системному программисту.
В рамках данной курсовой работы предусматривается только разработка
руководства оператора, содержащее: назначение программы, условия
выполнения программы, выполнение программы, сообщения оператору и т.д.

50
ГЛАВА 5. ОХРАНА ТРУДА ОПЕРАТОРА

5.1. Основы эргономики рабочего места

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


целью создания оптимальных условий труда, способствующих росту его
производительности при обеспечении всех необходимых потребностей работника.
Основными задачами эргономики являются:
• создание оптимальных условий труда человека в соответствии с его
физическими возможностями;
• сохранение здоровья и работоспособности человека;
• обеспечение безопасности труда.
Оснащение рабочего места должно производиться на основе анализа
процессов, осуществляемых на данном рабочем месте, и соответствовать
требованиям нормативного документа СанПиН 2.2.2.542-96 «Гигиенические
требования к видеодисплейным терминалам, персональным электронно-
вычислительным машинам и организации работы».
Персональный компьютер должен соответствовать эргономическим
требованиям. Уровень излучения дисплея должен удовлетворять определенным
стандартам, наиболее известные из которых — MPR-II, TCO’99, ISO 9241-3, EPA
Energy Star и др.
При организации рабочего места оператора ЭВМ необходимо правильно
спланировать информационное и моторное поле.
В информационном поле оператора различают три зоны:
• в первой располагается устройство отображения информации
(монитор);
• во второй и третьей зоне располагаются дополнительные средства,
помогающие оператору в работе (например, плакаты).
В моторном поле оператора также различают три зоны:
• Первая зона — зона оптимальной досягаемости, в этой зоне должна
располагаться клавиатура.
• Вторая зона — зона легкой досягаемости, в ней могут располагаться,
например, мышь или блокнот.
• Третья зона досягаемости редко используется, в ней лучше всего
располагать книги.

5.2. Режим труда и отдыха при работе с ЭВМ

Психофизиологические требования к рабочему месту оператора ЭВМ


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

51
организовываться в зависимости от вида и категории трудовой деятельности
согласно СанПиН 2.2.2.542-96.
По виду трудовой деятельности работу оператора можно отнести к группе
А — работа по считыванию информации с экрана ВДТ или ПЭВМ с
предварительным запросом. Для данной группы существуют три категории
тяжести и напряженности работы с ЭВМ и монитором, определяющиеся по
суммарному числу считываемых знаков за рабочую смену:
• 1 категория — до 20 000 знаков;
• 2 категория — до 40 000 знаков;
• 3 категория — до 60 000 знаков.
Продолжительность обеденного перерыва определяется Кодексом законов о
труде и Правилами внутреннего трудового распорядка предприятия.
Для обеспечения оптимальной работоспособности и сохранения здоровья
профессиональных пользователей, на протяжении рабочей смены должны
устанавливаться регламентированные перерывы. Время регламентированных
перерывов в течение рабочей смены следует устанавливать в зависимости от ее
продолжительности, вида и категории трудовой деятельности.
Продолжительность непрерывной работы без регламентированного
перерыва не должна превышать двух часов.
Во время регламентированных перерывов с целью снижения нервно-
эмоционального напряжения, утомления зрительного анализатора, устранения
влияния гиподинамии, предотвращения развития утомления целесообразно
выполнять комплексы упражнений для глаз, для улучшения мозгового
кровообращения, для снятия утомления с плечевого пояса и рук, а также общего
воздействия.
В случаях возникновения у пользователя зрительного дискомфорта и других
неблагоприятных субъективных ощущений, несмотря на соблюдение санитарно-
гигиенических, эргономических требований, режимов труда и отдыха следует
применять индивидуальный подход в ограничении времени работ с ЭВМ.
Коррекцию длительности перерывов для отдыха или проводить смену
деятельности на другую, не связанную с использованием ЭВМ.

5.3. Организация рабочего места оператора ЭВМ

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


рабочего места оператора могут влиять на чувство физического комфорта и
производительность труда.
При расположении в помещении нескольких рабочих мест с ЭВМ
необходимо учитывать расстояния между рабочими столами с видеомониторами
(в направлении тыла поверхности одного видеомонитора и экрана другого
видеомонитора), которое должно быть не менее 2,0 м, а расстояние между
боковыми поверхностями видеомониторов — не менее 1,2 м.
Оконные проемы в помещениях должны быть оборудованы регулируемыми
устройствами типа жалюзи, занавесей, внешних козырьков и др. Шкафы, сейфы,
52
стеллажи для хранения дисков, дискет, комплектующих деталей, запасных блоков
ВДТ и ПЭВМ, инструментов, следует располагать в подсобных помещениях.
При отсутствии подсобных помещений допускается размещение шкафов,
сейфов и стеллажей в помещениях непосредственного использования ЭВМ при
соблюдении требований к площади помещений и требований.
При конструировании оборудования и организации рабочего места следует
обеспечить соответствие конструкции всех элементов рабочего места и их
взаимного расположения эргономическим требованиям с учетом характера
выполняемой пользователем деятельности, комплексности технических средств,
форм организации труда и основного рабочего положения пользователя.
Конструкция рабочего стола должна обеспечивать оптимальное размещение
на рабочей поверхности используемого оборудования с учетом его количества и
конструктивных особенностей (размер системного блока и монитора, клавиатуры
и др.), характера выполняемой работы. При этом допускается использование
рабочих столов различных конструкций, отвечающих современным требованиям
эргономики.
Конструкция рабочего стула (кресла) должна обеспечивать поддержание
рациональной рабочей позы при работе, позволять изменить позу с целью
снижения статического напряжения мышц шейно-плечевой области и спины для
предупреждения развития утомления. Тип рабочего стула (кресла) должен
выбираться в зависимости от характера и продолжительности работы с учетом
роста пользователя.
Рабочий стул (кресло) должен быть подъемно-поворотным и регулируемым
по высоте и углам наклона сидения и спинки, а также расстоянию спинки от
переднего края сиденья, при этом регулировка каждого параметра должна быть
независимой, легко осуществляемой и иметь надежную фиксацию.
Поверхность сиденья, спинки и других элементов стула (кресла) должна
быть полумягкой, с нескользящим, не электризующимся и
воздухонепроницаемым покрытием, обеспечивающим легкую очистку от
загрязнения.
Для комфортной работы с ЭВМ должен выполняться ряд условий:
• Дисплей необходимо расположить так, чтобы на него не попадал
прямой солнечный свет.
• Дисплей должен поворачиваться в горизонтальном и вертикальном
направлении.
• Клавиатура не должна быть жестко связана дисплеем.
• Должна обеспечиваться возможность регулировки яркости и резкости
изображения на дисплее.
• Кнопки на передней панели системного блока должны располагаться
таким образом, чтобы обеспечить к ним удобный доступ со стороны операторы.
• Клавиатура должна располагаться под удобным для работы углом к
поверхности стола (5 — 15 градусов);
Клавиши клавиатуры должны нажиматься мягко.

53
Экран видеомонитора должен находиться от глаз пользователя на
оптимальном расстоянии 600-700 мм, но не ближе 500 мм с учетом размеров
алфавитно-цифровых знаков и символов.
В помещении ежедневно должна проводиться влажная уборка.
Помещение должно быть оснащено аптечкой первой помощи и
углекислотными огнетушителями. Также обеспечивается рациональный режим
труда и отдыха, установленный с учетом психофизической напряженности труда,
динамики функционального состояния систем организма и работоспособности,
предусматривает соблюдение регламентированных перерывов.
Для поддержания нормальной работоспособности рекомендуется соблюдать
следующие мероприятия: продолжительность работы с ЭВМ не должна занимать
50% рабочего времени, при этом время непрерывной работы не более 1,5-3 часов;
время перерыва — 10-15мин. Необходим также перерыв на обед.

5.4. Параметры помещений

Размеры помещения — площадь, объем — должны в первую очередь


соответствовать количеству персонала и размещаемым техническим средствам.
Для обеспечения нормальных условий труда санитарные нормы СанПиН
2.2.4.548-96 устанавливают следующие требования: на одного работника должен
приходиться объем производственного помещения не менее 20 куб. м, площадь —
не менее 6 кв.м.

5.5. Микроклимат помещений

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


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

54
Таблица 5.1
Оптимальные нормы микроклимата для помещений с ПЭВМ

Скорость
Категория Температура Относительная
Период года движения
работ воздуха, 0С влажность,%
воздуха, м/с
легкая 1а 23…25 40…60 0.1
Теплый
легкая 1б 22…24 40…60 0.2
легкая 1а 22…24 40…60 0.1
Холодный
легкая 1б 21…23 40…60 0.1

5.6. Уровень шума в помещениях

Шум — это всякий нежелательный для человека звук. Сильный шум в


условиях производства снижает производительность труда (до 40-60%).
Источником шума в офисных помещениях часто являются механические
устройства ЭВМ. Человек, работая при шуме, привыкает к нему, но
продолжительное действие сильного шума вызывает общее утомление, может
привести к ухудшению слуха, а иногда и к глухоте. Эти вредные последствия
проявляются тем больше, чем сильнее шум и продолжительнее его воздействие.
Согласно СН 2.2.4/2.1.8.562-96 нормируемой шумовой характеристикой рабочих
мест является уровень звукового давления в децибелах.
Снижение шума в источнике излучения можно обеспечить применением
упругих прокладок между основанием машины, прибора и опорной
поверхностью. В качестве прокладок используются резина, войлок, пробка,
различной конструкции амортизаторы.
Не менее важным для снижения шума в процессе эксплуатации является
вопрос правильной и своевременной регулировки, смазывания и замены
механических узлов шумящего оборудования.
Рациональная планировка помещения, размещения оборудования является
важным фактором, позволяющим снизить шум при существующем оборудовании.

5.7. Освещение помещений

При работе с ЭВМ, как правило, применяется естественное боковое


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

55
В качестве источников света при искусственном освещении должны
применятся преимущественно люминесцентные лампы. Одним из недостатков
таких ламп является высокая пульсация светового потока, вызывающая
утомление зрения. Поэтому коэффициент пульсации освещенности
регламентирован в пределах 10-20% в зависимости от разряда зрительной работы.
Согласно СНиП 23-05-95 «Естественное и искусственное освещение»
искусственное освещение в помещениях с ПЭВМ должно соответствовать
нормам, приведенным в таблице 5.2.

Таблица 5.2

Нормы освещенности в помещениях с ЭВМ

Характеристика Рабочая Плоскость Освещение, лк


работы поверхность
Работа с экранами Экран Вертикальная более 300
ПЭВМ Клавиатура Горизонтальная 300...500
Стол Горизонтальная 300...500

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


отраженная блесткость, которая приводит к перенапряжению и усталости.
Согласно СанПиН 2.2.2.542-96 яркость светящихся поверхностей (окна,
светильники и др.), находящиеся в поле зрения, должна быть не более
200 кд/кв. м, а при отраженной блесткости яркость бликов на экране ПЭВМ не
должна превышать 40 кд/кв. м и яркость потолка, при применении системы
отраженного освещения, не должна превышать 200 кд/кв. м.
Рациональное цветовое оформление помещения направленно на улучшение
санитарно-гигиенических условий труда, повышение его производительности и
безопасности. Окраска помещений влияет на нервную систему человека, его
настроение и, в конечном счете, на производительность труда. Основные
производственные помещения целесообразно окрашивать в соответствии с цветом
технических средств. Освещение помещения и оборудования должно быть
мягким, без блеска.
Следует ограничивать отраженную блесткость на рабочих поверхностях за
счет правильного выбора типов светильников и расположения рабочих мест по
отношению к источникам искусственного освещения. Яркость бликов на экране
дисплея не должна превышать 40кд/кв.м
Следует ограничивать неравномерность распределения яркости в поле
зрения оператора ЭВМ. Соотношение яркости между рабочими поверхностями не
должно превышать 3:1 — 5:1, а между рабочими поверхностями и поверхностями
стен и оборудования — 10:1.
Для обеспечения нормируемых значений освещенности в помещении
следует проводить чистку стекольных рам и светильников не реже двух раз в год
и проводить своевременную замену перегоревших ламп.
56
5.8. Уровень электромагнитных излучений

Основным источником различного вида излучений на рабочем месте


являются мониторы. Спектр их излучений включает в себя рентгеновскую,
ультрафиолетовую и инфракрасную области, а также широкий диапазон
электромагнитных волн других частот. Из вышеперечисленных излучений
наиболее опасно рентгеновское, обладающее большой проницаемостью.
Нормирование электромагнитных полей радиочастот осуществляется по
СанПиН 2.2.2.542-96. Согласно данному стандарту предельно допустимая
напряженность на рабочем месте не должна превышать в течение рабочего дня на
расстоянии 50 см от видеомонитора:
• 25 В/м для диапазона 5 Гц — 2 кГц;
• 2,5 В/м для диапазона 2 кГц — 400 кГц.
Для предотвращения облучения оператор должен находится на расстоянии
не менее 30 см от экрана монитора.

5.9. Электробезопасность рабочих мест

Для предотвращения образования статического электричества в


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

5.10. Пожарная безопасность помещений

Пожар — неконтролируемое горение, развивающееся во времени и в


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

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

58
ЛИТЕРАТУРА

1. Стандарт предприятия. Курсовое и дипломное проектирование. Общие


требования к оформлению. СТП ЮУрГУ 04-2001/Составители: Сырейщикова
Н.В., Гузеев В.И., Сурков И.В., Винокурова Л.В., — Челябинск: ЮУрГУ, 2001. —
49 с.
2. Соммервилл И. Инженерия программного обеспечения, 6-е издание.:
Пер. с англ. — М. : Издательский дом «Вильямс», 2002. — 624 с.
3. Голенищев Э.П., Клименко И.В. Информационное обеспечение систем
управления. Серия «Учебники и учебные пособия». Ростов н/Д: «Феникс»,
2003 — 352 с.
4. Подбельский В.В., Фомин С.С. Программирование на языке Си: Учеб.
пособие. — 2-е доп. изд. — М: Финансы и статистика, 2002. — 600 с.

58
ПРИЛОЖЕНИЕ 1

БЛАНК ЗАДАНИЯ НА КУРСОВУЮ РАБОТУ

Южно-Уральский государственный университет


Кафедра «Автоматика и управление»

Задание
на курсовую работу
по дисциплине ЕН.Ф.02 «Информатика»

Ф. И. О. студента ______________________
Факультет, группа _____________________
Задание № _________Вариант №_________

Целью работы является создание компьютерной программы, которая


позволяет сохранять, вызывать, сортировать, анализировать и распечатывать
информацию, хранящуюся в базе данных.
Для достижения указанной цели необходимо решить следующие задачи:
1. Разработать таблицу базы данных на базе двунаправленного связанного
списка. Поля таблицы следующие (п. 1 варианта):
2. Разработать структуру программы, в которой реализуются следующие
операции над данными:
— запись базы данных в файл;
— загрузка базы данных из файла;
— инициализация базы данных;
— ввод новой записи в базу данных;
— удаление записи из базы данных;
— распечатка базы данных;
— извлечение информации из базы данных по следующему критерию (п. 2
варианта):____________________________________________________________
_____________________________________________________________________;
— сортировка записей в базе данных по значениям ключевого поля;
— изменение значений записей, существующих в базе данных.
3. Разработать и выполнить схему программы согласно ГОСТ 19.701-
90 «Схемы алгоритмов, программ, данных и систем».
4. Разработать программу на языке Си.
5. Разработать руководство для оператора программы.
6. Привести результат работы программы:
— файл с таблицей базы данных;
— файл с результатом выполнения запроса.

Руководитель Касюк С. Т. Студент ___________________


60
ОГЛАВЛЕНИЕ

ПРЕДИСЛОВИЕ....................................................................................................... 3
1. ПОСТАНОВКА ЦЕЛИ И ЗАДАЧ КУРСОВОЙ РАБОТЫ.............................. 4
1.1. Введение в базы данных............................................................................... 4
1.2. Понятие системы управления базами данных............................................ 4
1.3. Физическая организация данных в СУБД.................................................. 5
1.4. Цель курсовой работы.................................................................................. 5
1.5. Задачи курсовой работы............................................................................... 5
1.6. Требования к составу и оформлению пояснительной записки................. 6
2. ОСНОВНЫЕ ЭТАПЫ И ТЕХНОЛОГИИ РАЗРАБОТКИ
ПРОГРАММНЫХ СИСТЕМ.............................................................................. 7
2.1. Фундаментальные процессы разработки ПО............................................. 7
2.2. Модели процесса создания ПО.................................................................... 7
2.3. Каскадная модель.......................................................................................... 8
2.4. Эволюционная модель.................................................................................. 9
2.5. Формальная разработка систем.................................................................... 10
2.6. Разработка ПО на основе ранее созданных компонентов......................... 10
2.7. Проектирование и реализация ПО............................................................... 11
2.8. Методы проектирования............................................................................... 12
2.9. Программирование и отладка...................................................................... 12
2.10. Аттестация программных систем.............................................................. 13
2.11. Эволюция программных систем................................................................ 14
3. ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.................. 16
3.1. Проектирование программной системы..................................................... 16
3.1.1. Архитектурное проектирование........................................................ 16
3.1.2. Проектирование структуры данных.................................................. 21
3.1.3. Проектирование интерфейсов программных модулей.................... 22
3.1.4. Проектирование алгоритмов.............................................................. 23
3.1.5. Проектирование интерфейса оператора............................................ 32
3.2. Кодирование и тестирование функций....................................................... 35
3.2.1. Введение в кодирование..................................................................... 35
3.2.2. Узел списка и глобальные переменные............................................ 35
3.2.2. Главная функция main()...................................................................... 36
3.2.3. Функция сохранения данных в файле save().................................... 38
3.2.4. Функция загрузки данных из файла load()........................................ 39
3.2.5. Функция ввода новой записи в базу данных input()........................ 40
3.2.6. Функция удаление записи из базы данных delete().......................... 42
3.2.7. Функция вывода содержимого базы данных на экран print()......... 43
3.2.8. Функция выборки информации из базы данных
по какому-либо критерию query()...................................................... 44
3.2.9. Функция изменения значений элементов существующих
в базе данных записей refresh().......................................................... 45
3.2.10. Функция сортировки записей в базе данных sort()....................... 46
61
4. ГЛАВА 4. РУКОВОДСТВО ОПЕРАТОРА ПРОГРАММНОЙ СИСТЕМЫ.. 49
5. ОХРАНА ТРУДА ОПЕРАТОРА ПРОГРАММНОЙ СИСТЕМЫ................... 51
5.1. Основы эргономики рабочего места........................................................... 51
5.2. Режим труда и отдыха при работе с ЭВМ.................................................. 51
5.3. Организация рабочего места оператора ЭВМ............................................ 52
5.4. Параметры помещений................................................................................. 54
5.5. Микроклимат помещений............................................................................ 54
5.6. Уровень шума в помещениях....................................................................... 55
5.7. Освещение помещений................................................................................. 55
5.8. Уровень электромагнитных излучений....................................................... 57
5.9. Электробезопасность рабочих мест............................................................ 57
5.10. Пожарная безопасность помещений......................................................... 57
ЛИТЕРАТУРА.......................................................................................................... 58
ПРИЛОЖЕНИЕ 1. БЛАНК ЗАДАНИЯ НА КУРСОВУЮ РАБОТУ.................. 60

62
С.Т. Касюк

КУРСОВАЯ РАБОТА
ПО ДИСЦИПЛИНЕ «ИНФОРМАТИКА»

Методическое руководство
для студентов специальности 210100

Издательство Южно-Уральского государственного университета


__________________________________________________________________
ИД №00200 от 28.09.99. Подписано в печать __.__.2005. Формат
60*84 1/16. Печать офсетная. Усл. печ. л. 8,60, Уч.-изд. л. 9,5.
Тираж 90 экз. Заказ 252/395. Цена 150 р.
__________________________________________________________________
УОП Издательства. 454080, г. Челябинск, пр. им. В. И. Ленина, 76.