Xreferat.com » Рефераты по информатике и программированию » Автоматизированное рабочее место регистрации и документирования комплекса средств автоматизации

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

код)

2

слово

0

0

0

0

0

0

0

0

0

0

0

0

0

1

0

1

3

слово

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

4

слово

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

5

слово

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0


№ устройства = 000001 для ПУ1,

№ устройства = 001000 для ПУ2,

№ устройства = 001111 для ПУ3.

Наличие “0” или “1” в разрядах [0-5] 2-го слова кодограммы свидетельствует о наличии соответствующих признаков, смысловое содержание которых следующее:

для ПУ1 [0,1] разряды 2-го слова

[0] р. “1” - ПУ1 заблокировано по ФК оператором;

[0] р. “0” - ПУ1 разблокировано по ФК оператором;

[1] р. “1” - ПУ1 неисправно;

[1] р. “0” - ПУ1 исправно.


для ПУ2 [2,3] разряды 2-го слова

[2] р. “1” - ПУ2 заблокировано по ФК оператором;

[2] р. “0” - ПУ2 разблокировано по ФК оператором;

[3] р. “1” - ПУ2 неисправно;

[3] р. “0” - ПУ2 исправно.


для ПУ3 [4,5] разряды 2-го слова

[4] р. “1” - ПУ3 заблокировано по ФК оператором;

[4] р. “0” - ПУ3 разблокировано по ФК оператором;

[5] р. “1” - ПУ3 неисправно;

[5] р. “0” - ПУ3 исправно.


Кодограмма регистрации БС для Ш1, Ш2, Ш3 выглядит следующим образом:

№ слова

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

0

0

слово

№ устройства

(в двоичном коде)

1

0

1

1

0

Часы

(двоичный код)

1

слово

Минуты (двоичный код)

Секунды (двоичный код)

2

слово

0

0

0

0

0

0

0

0

0

0

0

0

0

1

0

0

3

слово

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

4

слово

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

5

слово

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0



№ устройства = 000000 для Ш1,

№ устройства = 000111 для Ш2,

№ устройства = 001011 для Ш3.

Наличие “0” или “1” в разрядах [0-2] 2-го слова кодограммы свидетельствует о наличии соответствующих признаков, смысловое содержание которых следующее:

для Ш1 [0] разряд 2-го слова

“1” - Ш1 неисправен;

“0” - Ш1 исправен.


для Ш2 [1] разряд 2-го слова

“1” - Ш2 неисправен;

“0” - Ш2 исправен.


для Ш3 [2] разряд 2-го слова

“1” - Ш3 неисправен;

“0” - Ш3 исправен.


3.2. Обоснование необходимости организации базы данных

3.2.1. Понятие базы данных

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

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

Слова “динамически обновляемая” означают, что соответствие БД текущему состоянию предметной области обеспечивается не периодически (раз в месяц, неделю, день), а в режиме реального времени.

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

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

Современный подход требует, чтобы в программе были лишь перечислены необходимые для обработки данные и заданы требуемые форматы их представления. При этом описание баз данных становится независимым от программ пользователей и составляет самостоятельный объект хранения. Эти описания обычно называют метаданными [5].

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


3.2.2. Достоинства интеграции данных.

Отметим некоторые достоинства интеграции данных.

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

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

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

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

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

Обычно выделяются два аспекта независимости приложений от организации данных: логическая и физическая независимость. Первая предполагает возможность “безболезненного” изменения параметров логической организации БД, а вторая – изменения хранения данных в памяти ЭВМ.


3.2.3. Проблемы интеграции данных

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

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

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

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


3.2.4. Необходимость организации БД на АРМ РД

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

  • прием данных, круглосуточно поступающих от ВК;

  • выдачу информации в ВК;

  • регистрацию поступивших данных в памяти ЭВМ;

  • документирование данных, размещенных в информационных массивах.

Согласно с функциональным назначением, проектирование БД на АРМ РД должно решить следующие задачи:

  • создать “динамическую” модель предметной области системы (в которой соответствие БД текущему состоянию предметной области обеспечивается не периодически, а в режиме реального времени);

  • обеспечить эффективность функционирования, т.е. обеспечить требования ко времени реакции системы на запросы и обновления БД;

  • обеспечить централизованное хранение данных в памяти ЭВМ;

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

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

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

Эти задачи можно осуществить при помощи создания единого хранилища – базы данных и использования средств СУБД.


3.3. Логическая организация базы данных

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

  • информации обмена по КС;

  • информации обмена между Ш1, Ш2, Ш3, и ВК;

  • сбойной информации обмена по КС;

  • сбойной информации между Ш1, Ш2, Ш3 и ВК;

  • информации о НЛИ;

  • информации ФК;

  • информации НСД;

  • информации НСД ОП;

  • информации о БС устройств.

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

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


  1. Дата отправки кодограммы;

  2. Время отправки кодограммы;

  3. Направление (от ПУ1, информация в КС3 и т.п.);

  4. Режим работы;

  5. Источник (откуда пришла кодограмма);

  6. Вид сообщения (БС, НСД, и т.п.);

  7. Количество сбойных кодограмм;

  8. Содержание сбойных кодограмм;

  9. Тип устройства, от которого пришла кодограмма;

  10. Признак (сообщения от нескольких устройств приходят в одной кодограмме);

  11. Значение контрольной суммы при пуске ВК;

  12. Значение периодически вычисляемой контрольной суммы;

  13. Текст сообщения, содержащегося в кодограмме.

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


Отношение 1: “Вся информация”. Ключевыми доменами являются первые два поля: “Дата”, “Время”.

Отношение 2: “Оперативная информация”. Ключевыми доменами в данном отношении являются “Дата”, “Время”, “Направление”, “Режим работы”, “Источник”, “Вид сообщения”.

Отношение 3: “Информация Ш” Ключевыми доменами являются “Дата”, “Время”, “Направление”, “Режим работы”.

Отношение 4: “Сбойные кодограммы”. Ключевыми доменами являются: “Дата”, “Время”, “Направление”, “Количество”, “Вид сообщения”, “Слово1”, “Слово2”, “Слово3”, “Слово4”.

Отношение 5: “Функциональный контроль”. Ключевыми доменами являются: “Дата”, “Время”, “Тип”, “Признак”, “Вид сообщения”.

Отношение 6: “Связь с ВК”. Ключевыми доменами являются “Дата”, “Время”.

Отношение 7: “Текущая контрольная сумма”. Ключевыми доменами являются:

“Дата”, “Время”.

Отношение 8: “Контрольная сумма при пуске ВК”. Ключевыми доменами являются: “Дата”, “Время”.

При формировании отношений были поставлены следующие цели: осуществить группировку записей в такие структуры, которые достаточно малы по размеру и поэтому управляемы. При этом данные могут дублироваться, например, отношение ФК может включать в себя информацию о связи с ВК. Однако созданием отношения “Связь с ВК” мы выделяем его в логически самостоятельное отношение и тем самым уменьшаем время поиска важной для нас информации. Это означает, что информация, требующая к себе первостепенного внимания, выделяется в отдельные отношения с целью уменьшения времени поиска по БД, давая возможность персоналу, обслуживающему КСА своевременно реагировать на изменения, возникающие в системе.

С такой же целью выделяется в отдельные отношения информация контрольного суммирования, информация контрольного суммирования при пуске ВК, информация Ш.

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

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

Информация фиксируется в восьми не связанных друг с другом таблицах, и один пользователь, например, может иметь доступ только к БД “Информация контрольного суммирования”, другой – к БД “Информация Ш”. В дипломном проекте рассматривается только та информация, которая содержится в БД ФК.

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

Вид полей БД ФК представлен на рис. 19.


Структура БД ФК включает в себя следующие элементы: “Дата”, “Время”, “Тип устройства”, “Признак” (признак группирования информации), “Вид сообщения” (БС, НСД, ФК, НЛИ, и т.д.), “Текст сообщения”. В поле “Текст сообщения" находится сообщение типа: “НСД снято”, или “Нет связи по линии 1”, или “разблокировано по ФК”, и т.п., т.е. раскрывается конкретное значение поступившего по устройству сообщения. Остальные элементы, перечисленные ранее, являются ключевыми, и служат для поиска последнего элемента “Текст сообщения”.


3.4. Выбор СУБД

Выделение СУБД - претендентов

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

На выбор СУБД – претендентов наибольшее влияние оказывает согласование ряда параметров среды реализации и СУБД. Наиболее значимые параметры перечислены ниже (в скобках указаны характеристики АРМ РД):

  • тип ЭВМ (IBM PC AT на базе процессора Intel 80386);

  • операционная система (MS DOS);

  • объем оперативной памяти (2Мб);

  • объем дисковой памяти (160 МБ);

  • выбранная для реализации модель данных (реляционная).

    Перечислим СУБД подобного класса: D-Base, Clipper, Paradox. Перед тем как приступить к сравнительному анализу моделей баз данных, и, следовательно, к окончательному выбору СУБД, необходимо выделить набор факторов, которые влияют на окончательный выбор варианта.

    Наиболее часто используемые факторы оценки моделей баз данных:

  • трудоемкость реализации приложений;

  • стоимость эксплуатации информационной системы;

  • возможность совмещения разработки БД с ранее выполненными программными реализациями;

  • прогнозируемые сроки реализации информационной системы;

  • затраты на обучение персонала.

На этом этапе необходимо несколько детализировать требования к реализуемому ПО АРМ РД.

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

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

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

В качестве программного продукта для создания ПО АРМ РД была выбрана разработка фирмы Borland – язык программирования Турбо Си++ версии 3.0 и библиотека стандартных программ на языке Турбо Си++ Paradox Engine для реализации обслуживания реляционных баз данных.

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

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

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

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


Основные характеристики системы Paradox.

Таблицы Paradox - это стандартные файлы DOS с расширением “.DB”. Имена таблиц отвечают стандартным соглашениям об идентификации файлов, принятым в ОС MS DOS.

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

Каждая запись может включать до 255 полей, а каждое поле до 255 символов.

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

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

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

Конечно, нельзя однозначно сказать, что выбранная СУБД идеально соответствует поставленной перед разработчиками задаче. Для иллюстрации сравним Paradox Engine и СУБД Paradox с внутренним языком программирования PAL.

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

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

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

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

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

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

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

Можно сделать вывод, что на выбор СУБД повлияли следующие факторы:

  1. Наличие опыта программирования на языке Турбо Си++, у разработчиков, что позволяет снизить временные и материальные затраты на их переобучение.

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

  3. Обеспечение гибкости ПО и высокого уровня управления программами.

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

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


4. Структура комплекса программ АРМ РД

4.1. Обоснование структуры комплекса программ

4.1.1. ПО общесистемного назначения

Структура комплекса программ АРМ РД представлена на рис. 20 и является логическим продолжением реализации функционального назначения АРМ РД.

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

Исходными данными предусмотрено, что в качестве среды функционирования выбирается операционная система MS DOS с файловой оболочкой Norton Commander.

Для работы с файлами в составе ПО АРМ РД предусмотрены общесистемные утилиты (архиваторы, антивирусы, и т.п.). Для оформления документации, записок, отчетов предусмотрен текстовый редактор LEXICON.

Для создания специального ПО для АРМ РД используются следующие программные продукты:

  • Язык программирования Турбо Cи++ версии 3.0;

  • PX Engine - библиотеки функций на языке Borland Cи++, для создания БД в формате Paradox;

  • CXL - библиотеки функций на языке Borland C++ для создания оконного интерфейса пользователя.


4.1.2. ПО специального назначения

ПО специального назначения представляет собой программные средства, используемые на этапе эксплуатации АРМ РД (см. рис. 20). Его условно можно разделить на три группы:

  1. Операционная система MS DOS

  2. Библиотеки используемых функций (LIB) включают библиотеки используемых функций языка Borland С++, PX Engine - библиотеки функций языка С++ для создания БД в формате Paradox, CXL – библиотеки функций языка С++ для создания оконного интерфейса.

  3. Исполяемые модули программ, обеспечивающие следующие функции:

  • управляющая программа (MAIN);

  • функции создания прототипов БД и первичных ключей к ним (INITENG);

  • функции записи информации и внесения изменений в БД (ZAPBD);

  • функции формирования и исполнения запросов (INQUIRY), включает программы обработки запросов для 3-х форм представления БС (BS-INQ);

  • функции службы администрирования БД (CR_ARMBD – создание базы данных администратора, CREAT_FA – создание файла администратора, BDADM – работа с БД администратора – создание списка пользователей, регистрация и удаление пользователей);

  • функции архивирования и работы с архивом (ARCH).

4.1.3. Требования, предъявляемые к специальному ПО АРМ РД

1. Требования по обеспечению надежности.

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

2. Требования по обеспечению удобства эксплуатации.

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

3. Требования к операционной и программной совместимости.

Программное обеспечение средств регистрации и документирования АРМ должно обеспечивать:

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

4.2. Программная реализация

Постановка задачи

Задачей данного дипломного проекта является разработка программ формирования и обработки запросов для трех форм представления БС и выдача их на экран монитора и принтер.

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

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

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

Вид представления информации после преобразования БС на экран монитора и принтер

Исходя из соображений практического смысла были выбраны 3 формы представления БС: компактная-символическая, табличная, справочная (первая, вторая и третья формы представления БС соответственно).

Первая форма представления БС.

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

1-5 поля - ключевые. Поле 6 - БС технических устройств в позиционном коде. Для каждого устройства определено фиксированное количество этих байтов (максимальное значение 4 группы или 4слова).

Пример кодирования одного слова для устройства i (рис.22) - значение 035007 надо интерпретировать как:



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

Вторая форма представления БС.

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

Третья форма представления БС.

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


Ш-1

Неисправно направление связи С1 по передаче от ВК к Ш по причине неполучения от Ш-1 кодограмм по времени.

ОТСУТСТВУЕТ СИГНАЛ СЕТЬ1

Заменить блок А4 в стойке П1

Ш-1 заблокирован функциональной задачей


Определение реализуемых функций программ обработки запросов для 3-х форм представления БС

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

Для первой формы представления БС:

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

  • по всей БД (дата и время не используются);

  • в едином интервале по дате и времени;

  • в указанном интервале времени по каждому дню интервала дат;

  • за один день в указанном интервале времени.

  1. Расшифровка БС заданных оператором устройств, учитывая интервал поиска.

  2. Выдача расшифрованных БС на монитор или принтер в первой форме представления. Как видно из описанного выше, первая форма представления БС выдается , на экран монитора в виде, представленном на рис. 21.

Для второй формы представления БС:

  1. Нахождение необходимой записи БС в БД по конкретному устройству, заданному оператором, используя различные варианты поиска:

  • по всей БД ;

  • в едином интервале по дате и времени;

  • в интервале времени по каждому дню интервала дат;

  • за один день в указанном интервале времени.

Можно отметить, что варианты поиска по БД для первой и второй форм представления БС совпадают.

  1. Расшифровка БС заданного оператором устройства, учитывая интервал поиска.

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

Для третьей формы представления БС:

1. Нахождение последней по времени или одной записи по

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

Поможем написать работу на аналогичную тему

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

Похожие рефераты: