Разработка файлового менеджера

 

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

1Обзор литературы и анализ состояния проблемы

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

1.1Обзор литературы

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

Главным документом, описывающим платформу, является спецификация [1]. В ней дано полное описание всех возможностей и особенностей платформы. На текущий момент платформа быстро развивается, выходят новые версии спецификации, описывающие дополнительные возможности. Так же официально выпускается спецификация, которая описывает процесс запуска платформы [2].

Главной книгой после спецификации можно назвать источник [3]. В интернете можно встретить достаточно большое количество статей на эту тему, но многие из них являются переводом спецификации. Интерес вызывает статья [4] в которой автор приводит описание процесса загрузки платформы. В статье [5] описываются основные возможности платформы UEFI.

Наибольший интерес представляет спецификация [1], так как она содержит полное описание всех протоколов, что очень полезно при программировании на данной платформе.

1.2Анализ возможностей платформы

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

1.2.1Платформа имеет свои особенности, основные из которых перечислены ниже.

Поддержка GPT (GUID Partition Table). Способ разметки файловой системы GPT, замена старого MBR. В отличие от MBR, GPT поддерживает диски размером более 2ТБ и неограниченное количество разделов. Платформа UEFI по умолчанию поддерживает FAT32 с GPT-разделов. Способ разметки MBR платформой UEFI не поддерживается, совместимость с MBR осуществляется расширением CSM (Compatibility Support Module).

Платформа UEFI поддерживает два типа сервисов: boot services и runtime services. Первый работает только до загрузки ОС и обеспечивает взаимодействие с графическими и текстовыми терминалами, шинами, блочными устройствами и т.д. Второй - runtime services может использовать ОС, данный сервис не выгружается из памяти после запуска ОС. Один из примеров runtime services - variable service, который хранит значения в NVRAM.

В UEFI есть возможность использовать свои приложения и загружать свои драйверы. Для этого можно использовать консольный терминал UEFI Shell. Некоторые производители ВС включают его в прошивку с UEFI BIOS, но в большей части систем его нет. Терминал можно скачать из интернета и скопировать на съемный носитель или жесткий диск по определенному пути. Подробнее о UEFI Shell можно узнать из спецификации [6].

Так же UEFI поддерживает сетевые возможности.

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

В общем случае, для UEFI не требуется ставить загрузчик для поддержки мультизагрузки.

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

1.2.2Порядок загрузки UEFI BIOS так же стандартизирован.

На рисунке 1.1 представлена схема запуска платформы.

Рисунок 1.1 - Процесс запуска платформы UEFI

Сразу после включения питания начинается фаза Security (SEC) - это первая фаза загрузки, задачи которой следующие:

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

подготовить временную ОП;

проверить встроенное ПО на достоверность;

подготовить к запуску фазу PEI (как минимум передаются состояние платформы, адрес и размер временной памяти, адрес и размер стека подготовленные ранее).

Фактически для решения этих задач требуется:

сброс кэша и переход на главную процедуру инициализации;

переключение процессора в защищенный режим;

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

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

передача управления и данных в фазу PEI.

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

Следующая, вторая фаза, Pre EFI Initialization (PEI) должна инициализировать достаточное количество непрерывной ОП для того, чтобы можно было запустить фазу DXE, подготовить и передать в фазу DXE данные об обнаруженных устройствах, чтобы драйверы DXE смогли их правильно инициализировать.

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

Архитектура PEI позволяет независимую разработку и отладку модулей.

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

Фактически происходит так:

перенос данных из временной ОП в раннюю (временную) ОП, т.е. в кэш;

запуск модулей PEIM в порядке зависимостей между ними. Это цикл, который заканчивается в момент, когда не запущенных модулей не остается;

инициализация ЦП;

инициализация основной ОП и перенос в нее данных из временной ОП.

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

Формат модулей PEI может, как совпадать с форматом драйверов DXE (PE32+), так и отличаться от него заголовком, т.к. заголовок PE32+ содержит множество неиспользуемых в фазе PEI полей, а место в кэше процессора ограничено. Поэтому для PEIM был разработан специальный формат TE, заголовок которого содержит только необходимые поля. Также встречаются гибридные DXE/PEI-модули с двумя точками входа, но они обязаны быть в формате PE32+, поскольку иначе драйвер DXE такой модуль не запустит.

Последняя фаза инициализации DXE, во время нее выполняется основная и окончательная инициализация. Код DXE состоит из ядра, оно же DXE Foundation, диспетчера и драйверов. Ядро инициализирует и запускает различные службы UEFI: Boot Services, Runtime Services и DXE Services. Диспетчер отвечает за поиск и запуск DXE-драйверов, которые также имеют зависимости. Драйверы проводят окончательную инициализацию аппаратуры и предоставляют аппаратную абстракцию для служб. Весь код DXE, кроме Runtime-частей Foundation и Runtime DXE драйверов выгружается из памяти по окончанию фазы BDS.

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

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

Во время фазы DXE наступает момент, когда диспетчер загружает драйвер SMMInit, с которого и начинается подфаза SMM. Подфаза SMM - это специальный режим процессора, в который он переходит при получении специального прерывания - SMI, которое может быть как программным, так и аппаратным. Большую часть (или вообще все) источников SMI можно отключить, если переход в SMM не требуется. Код SMM выполняется в памяти SMRAM, которая становится недоступной для ОС после окончания фазы DXE, поскольку драйвер SMM намеренно закрывает к ней доступ. Код SMM выполняется и после окончания фазы DXE, до самого выключения ПК.

Драйвер SMMInit открывает память SMRAM, создает карту и структуры данных, необходимые для запуска других драйверов SMM, а перед окончанием фазы DXE полностью закрывает доступ к SMRAM. Драйверы SMM зависят от оборудования и не имеют доступа к интерпретатору байт-кода, поэтому написание драйверов SMM на EBC не поддерживается. Бывают эти самые драйверы двух видов: чистые SMM, которые загружаются по прерыванию непосредственно в SMRAM, и SMM/DXE-гибриды, которые сначала запускаются диспетчером DXE, а потом уже копируют часть себя в SMRAM. Драйвер SMMInit - именно такой гибрид. Для этой подфазы из постоянной памяти нужны драйверы SMM.

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

1.3Обзор аналогов и выбор прототипа

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

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

На рисунке 1.2 представлена экранная форма встроенной в UEFI BIOS утилиты для обновления прошивки.

Рисунок 1.2 - Интерфейс утилиты для обновления прошивки

На платформе UEFI BIOS открытым сообществом был разработан терминал EFI Shell, который позволяет запускать ПО на платформе, просматривать параметры ресурсов, драйверов, протоколов установленных в системе, а так же выполнять операции над файлами. Программа имеет текстовый интерфейс и является набором утилит вызываемых из общей консоли. Терминал не является встроенным ПО и может быть запущен из UEFI BIOS с файловой системы FAT12/16/32.

На рисунке 1.3 представлена экранная форма интерфейса EFI Shell.

Рисунок 1.3 - Интерфейс EFI Shell 2.0

Из описания аналогов для платформе UEFI BIOS можно заключить, что возможности рассмотренного ПО сильно ограничены. Его использование для задачи резервного копирования сильно ограничены, поэтому создание файлового менеджера для UEFI BIOS является не решенной задачей.

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

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

Среди файловых менеджеров с псевдографическим интерфейсом представляется интересным открытый проект FAR Manager. На рисунке 1.4 представлена экранная форма интерфейса FAR Manager.

Рисунок 1.4 - Интерфейс FAR Manager 3.0

Развитие проекта FAR Manager продолжается уже почти 14 лет. За такой продолжительный период проект существенно расширил круг своих возможностей, в первую очередь это стало возможно за счет расширяемости проекта с помощью плагинов. Важные плагины включены в основную программу, например, плагин для работы с FTP.

Среди наиболее востребованных возможностей FAR Manager можно отметить следующее:

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

перемещение, копирование, удаление каталогов и файлов;

переименование и редактирование атрибутов файла;

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

просмотр, создание и редактирование файлов (реализуется платинами);

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

и многое другое.

Данный проект является общепризнанным и популярным. Выбор данного ПО в качестве прототипа оправдан.

Выводы

В данном разделе проведен обзор не многочисленной литературы по данной тематике. Кратно изложены основные особенности платформы UEFI BIOS и представлен обзор аналогов файлового менеджера для других платформ.

2Разработка расширенного технического задания

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

2.1Цель дипломного проекта

Целью дипломного проектирования является создание файлового менеджера для платформы UEFI BIOS, представляющего пользовательский интерфейс со следующими основными возможностями:

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

перемещение, копирование, удаление каталогов и файлов;

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

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

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

Проект должен быть реализован на платформе UEFI BIOS, при помощи объектно-ориентированного программирования (ООП).

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

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

2.3Поддержка пользовательских сценариев

Для компенсации малого функционала интерфейса, в файловом менеджере необходимо реализовать поддержку пользовательских сценариев. Для ускорения и упрощения работ разработку можно сделать на основе проекта TinyJS. Проект TinyJS - это интерпретатор ограниченной реализации языка Java Script с открытым исходным кодом. Интерпретатор должен поддерживать файлы сценария в кодировке UTF-16 LE.

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

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

Идентификаторы - это лексема, являющаяся наименованием, некоторого объекта в исходном тексте сценария. Нельзя задавать имена идентификаторов одинаковые с ключевыми и зарезервированными словами. Задаваемые имена идентификаторов должны состоять из символов латинского алфавита, символа подчеркивания и цифр, причем имя не должно начинаться с цифр. Все идентификаторы сценариев чувствительны к регистру, то есть идентификаторы «id» и «Id» семантически различны.

Пример правильных имен идентификаторов - A, A0, _A0

Далее в таблице 2.1 приведен список ключевых и зарезервированных слов.

Таблица 2.1 - Список ключевых и зарезервированных слов

ЛексемаТипifКлючевое словоelseКлючевое словоdoКлючевое словоwhileКлючевое словоforКлючевое словоbreakКлючевое словоcontinueКлючевое словоfunctionКлючевое словоreturnКлючевое словоvarКлючевое словоtrueКлючевое слово, идентификаторfalseКлючевое слово, идентификаторnullКлючевое слово, идентификаторundefinedКлючевое слово, идентификаторnewЗарезервированное слово

Литерал - это лексема, описывающая отдельный элемент множества данных и содержащаяся непосредственно в программном коде.

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

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

Тип данных - это множество данных одинаковых по форме представления, но разных по значению.

Базовые типы данных делятся на:

специальные (null, undefined);

скалярные (логический, числовой, строковый);

составные (массивы, объекты).

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

Логический тип данных может иметь только два литеральных значения «true» и «false», «истина» и «ложь» соответственно. Конвертация из разных типов в логический тип данных происходит следующим образом: «null», «undefined», числовой - «0», строковый, если длина строки равна 0, становятся «false», все остальные значения переходят в «true».

Числовой тип данных состоит из множества целых чисел от минус 2147483648 до 2147483647. Литералом данного типа является строковое представление числа в десятичной системе счисления из данного диапазона. Например, «-123434». Конвертация в числовой тип происходит по следующим правилам:

«null» соответствует «0»;

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

«boolean» конвертируется в «0», если «false», в «1», если «true».

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

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

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

text string 1 name text \

text strung 2\n

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

Таблица 2.2 - Арифметические операторы

ОператорПриоритетКоличество операндовОперация-11Унарный минус-22Вычитание+22Сложение*22Умножение/22Деление%22Остаток от деления--11Декремент++11Инкремент

Таблица 2.3 - Бинарные операторы

ОператорПриоритетКоличество операндовОперация&72Поразрядное «И»|92Поразрядное «ИЛИ»^82Поразрядное исключающее «И»<<42Поразрядный сдвиг влево с учетом знака>>42Поразрядный сдвиг вправо с учетом знака

Таблица 2.4 - Операторы присваивания

ОператорПриоритетКоличество операндовОперация=132Присваивание+=, -=132Составные операторы присваивания. Между первым и вторым операндом выполняется соответствующая операция, а затем результат присваивается первому операнду.

Таблица 2.5 - Логические операторы

ОператорПриоритетКоличество операндовОперация!11Логическое отрицание<52Меньше, чем>52Больше, чем<=52Меньше или равно>=52Больше или равно==62Равенство!=62Неравенство===62Строгое соответствие!==62Строгое несоответствие&&102Логическое «И»||112Логическое «ИЛИ»

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

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

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

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

Оператор строгого соответствия отличается от оператора равенства тем, что сравнивает не только представление числа, но и тип.

Примеры работы операторов равенства и строгого соответствия -

== 4 - «истина», 4 === 4 - «ложь»== 1 - «истина», true === 1 - «ложь»

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

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

Пример однострочного комментария - //Этот текст будет проигнорирован интерпретатором.

Пример многострочного комментария - /* Этот текст будет проигнорирован интерпретатором*/

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

Пример инструкции -

= b + 5;

где, «+, =» - операции; «a», «b» - переменные; «5» - литерал.

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

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

Пример инструкции для объявления переменной «a»

var a;//переменная создана, но не проинициализирована= 5;//переменной присвоено значение пятьb = 5;//переменная создана и инициализирована значением пять

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

Пример переопределения переменной -

a = 5;//переменная создана и инициализирована значением пять= false;//переменная вновь инициализирована логическим значением «ложь»

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

Пример операторного блока

{ a = b + 5;= (a + 5) % 3; }

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

Пример основной способ объявления функции

function f0(x, y) { return x + y; };

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

Ключевое слово «return» определяет точку выхода из функции. Следующее за словом «return» значение возвращается функцией. Если после «return» следует «;», то возвращается значение «undefined». Тело функции может не содержать слова «return», в этом случае функция вернет «undefined» и завершится когда выполниться вся последовательность инструкции в операторном блоке.

Еще один способ описания функции, с помощью литерала функции. Такая функция называется лямбда-функция.

Пример объявления лямбда-функции -

var f1 = function(x, y) { return x + y; };

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

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

Пример объявления функции -

function f0(x, y) { return x + y; };f1 = f0;

После присваивания одна и та же функция становиться доступна через два идентификатора: «f0», «f1».

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

Пример вызова функции

(5);(5);

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

Пример локальных и глобальных переменных -

global = 1;//Объявление глобальной переменнойfunc(x, y)

{local = x + y;//Объявление локальной переменной/= local;local;

};

//Далее доступна только переменная global

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

Пример условного ветвления -

(a < 5) {

//Обработка при a < 5

}{

//Обработка при a >= 5

}

В случае если выражение, передаваемое оператору «if», вычисляется в «true», будет выполнен первый блок операторов, иначе - второй. Предложение «else» может быть опущено, если не требуется выполнять каких либо действий при вычислении логического условия в «false».

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

Пример цикла «for»

(var i = 0; i < 5; i++) {

var j = i;//Тело цикла выполниться пять раз

}

Цикл «for» выполняется до тех пор, пока выражение, указанное как условие, вычисляется в «true». Инициализирующее выражение вычисляется единственный раз - при начале исполнения оператора «for». Оно обычно используется для присваивания начальных данных переменным, используемым в выражении условия цикла. Выражение условие цикла вычисляется каждый раз перед выполнением тела цикла. Тело цикла может ни разу не выполниться, если на первом же проходе выражение условия вычисляется в «false». Обновляющее выражение вычисляется после каждого прохода цикла.

Конструкция «while» - это самый простой из операторов цикла. Тело цикла выполняется, пока значением выражения - условия является «true».

Пример цикла «while» -

i = 0;

while (i < 5) {j = i;//Тело цикла выполниться пять раз++;

}

В противоположность предыдущему оператору, тело «do...while» выполняется, пока выражение условия цикла вычисляется в «false».

Пример цикла « do...while » -

i = 0;

do {j = i;//Тело цикла выполниться пять раз++;

}(i >= 5)

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

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

Литеральное представление определяется перечислением значений в квадратных скобках «[ ]», при этом ключи будут иметь возрастающий от нуля индекс.

Пример объявления массива и добавления значений в массив

//Объявление массиваarr = [1, , text, [1, 2, 3], function(x, y) { return x + y;}, true];

arr[lenght] = 6;

//Получение элементов из массива:n0 = arr[0];//n0 станет числовой переменной со значением 1

var n1 = arr[1];//n1 станет undefined

var n2 = arr.lenght;//n2 станет числовой переменной со значением 6n3 = arr[lenght]//аналогично предыдущей строчке

Таблица 2.6 - Специальные операторы

ОператорПриоритетКоличество операндовОперация.01Доступ к свойству объекта[ ]01Доступ к элементу массива( )0Группировка операций или вызов функций,142Последовательное вычисление выражений

Выводы

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

3Разработка программного обеспечения

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

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

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

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

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

Рисунок 3.5 - Структура программы

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

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

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

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

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

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

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

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

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

3.2Разработка программных интерфейсов

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

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

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

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

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

копирование данных в объект;

перемещение данных внутри объекта;

частичное и полное сравнение данных объекта с другим объектном или его частью;

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

нахождение количество частичного и полного вхождения данных внешнего объекта в данные текущего объекта;

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

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

расширение массива на заданное количество элементов;

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

включение или исключение частично или полностью в объект данных из внешнего объекта или во внешний объект в заданное место.

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

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

Рисунок 3.6 - Схема наследования классов работы с данными

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

На рисунке 3.3 представлен класс FixByteArray.

Рисунок 3.7 - Класс FixByteArray

Основными данными класса являются: размер одного элемента массива (size_item), размер всего массива (size_byte) и указатель на массив (pointer). Так как данные сокрыты внутри класса, то для доступа к этим данным, введены одноименные методы, возвращающие значения соответствующих переменных.

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

Для удобства использования класса переопределен оператор обращения к элементам массива (operator[]). Так же реализован широкий набор перегруженных методов копирования данных (Copy) из другого массива, методы обмена данными (Replace) между массивами, методы сравнения содержимого массивов (Compire, Equal).

В классе присутствуют методы для нахождения индекса первого (IndexFirstOf), следующего (IndexNextOf), последнего (IndexLastOf), предыдущего (IndexPreviousOf) вхождения массива или под массива. Так же есть методы для подсчета количества вхождений (QuantityIncludeOf) массива или подмассива.

Метод определения вхождения индексов (CheckSegment) в заданном диапазоне в массив и коррекция индексов (CorrectSegment) для заданного диапазона.

На рисунке 3.4 представлен класс ByteArray.

Рисунок 3.8 - Класс ByteArray

В данном классе объявлены дополнительные данные: использованный размер массива (use_size) и шаг выделения памяти (step). Использованный размер определяет, сколько памяти из выделенной используется, а шаг выделения памяти определяет, с каким шагом будет увеличиваться или уменьшаться вся выделенная память для этого массива. Так как данные сокрыты внутри класса, то для доступа к этим данным, введены одноименные методы, возвращающие значения соответствующих переменных.

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

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

Так же есть методы для добавления (Add) и удаления (Delete) из заданного места определенного количества элементов или одного элемента в конце.

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

Шаблоны классов Array<T> и FixArray<T> переопределяют только оператор обращения к элементу массива и конструкторы под определенный тип.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее на рисунке 3.5 представлена схема наследования классов пользовательского интерфейса.

Рисунок 3.9 - Схема наследования классов пользовательского интерфейса

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

На рисунке 3.6 представлен класс Control.

Рисунок 3.10 - Класс Control

Класс содержит данные о положении и размере видимой обрасти на экране (window), указатель на родительский контейнер, к которому прикреплен элемент и флаг (parent), определяющий активность класса (focus).

Класс содержит конструктор по умолчанию, копирующий конструктор и конструктор привязки к контейнеру. Так же привязку к контейнеру и отсоединение можно осуществить с помощью методов определенных в классе (Connect, Disconnect).

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

Оставшиеся методы позволяют обновить размер элемента в соответствии с размером предоставляемым контейнером (Update), а так же получить этот размер без обновления размеров элемента (GetWindow) и получить размер всего имеющегося пространства для печати (GetDisplay).

На рисунке 3.7 представлен класс Container.

Рисунок 3.11 - Класс Container

Класс содержит данные о первом и втором элементе привязанных к контейнеру (first, second), данные о положении оси (axis) и пропорций (ratio) разделения пространства между ними. В классе есть методы для настройки и получения данных (Separator, Ratio).

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

В классе есть методы для привязки (Attach) и отсоединения (Detach) к определенному месту элемента, метод расчета размера присоединенного элемента (Rate), метод определения наличия связи между текущим контейнером и элементом (Detect).

Так же есть метод позволяющий обновить дочерние элементы (Update).

На рисунке 3.8 представлен класс Form.

Рисунок 3.12 - Класс Form

Класс содержит список указатели на элементы формы (control), количество элементов (number), индекс активного элемента (index), и признак повторения командного цикла (run).

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

В классе содержаться метод для определения количества элементов (NumberControl), методы для запуска (Show) и остановки (Hide) формы.

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

Среди метод работы с фокусом есть метод для получения указателя на активный элемент (GetFocus), метод получения текущего размера доступной обрасти окна (GetWindow), индекс активного элемента (GetIndex), метод перехода фокуса к следующему (NextFocus) или предыдущему (PreviousFocus) элементу из списка и метод инициализации списка элементов (LinkControl).

На рисунке 3.9 представлен класс Splitter.

Рисунок 3.13 - Класс Splitter

Класс является законченной реализацией абстрактного базового класса контейнера.

На рисунке 3.10 представлен класс Canvas.

Рисунок 3.14 - Класс Canvas

Класс содержит данные о стандартном цвете (standart), цвете фокуса (focus), положении курсора (position) и его видимости (visible). Класс содержит соответствующие методы работы с данными класса (StandartColor, FocusColor, ActiveColor, PositionCursor, VisibleCursor).

В классе присутствует метод позволяющий обновить размер элемента в соответствии с размером предоставляемым контейнером (Update).

Перед вызовом метода рисования (Draw) в прямоугольнике текста необходимо предварительно сохранить параметры вывода (BeginDraw), активировать требуемые параметры (FontDraw), а после восстановить старые параметры (EndDraw).

На рисунке 3.11 представлен класс Panel.

Рисунок 3.15 - Класс Panel

Класс дополняет базовый класс рамкой, которая рисуется согласно данным класса (border), которые можно получить (Border). Так же есть метод, рассчитывающий новый сокращенный размер (SizeContent) и переопределенный метод для обновления (Update), который теперь вызывает методы рисования (DrawContent, DrawUpText, DrawDownText, DrawFrame).

На рисунке 3.12 представлен класс ListBox.

Рисунок 3.16 - Класс ListBox

Класс содержит данные о индексе текущего (target_next) и текущего (target_last) активного элемента списка, индекс первого выводимого элемента списка (draw_item), а так же методы, которые возвращают эти значения (Target, LastTarget, FirstVisible).

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

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

В классе есть методы определяющие размеры списка данных (SizeList) и размеры информации о текущих данных (SizeInfo).

Класс содержит несколько методов обрабатывающих навигацию по элементам списка: переход к следующему (NextTarget) или предыдущему элементу списка (PreviousTarget), а так же переход к следующей (NextPageTarget) или предыдущей (PreviousPageTarget) странице списка элементов.

Класс содержит аналогичные базовому методы для работы с фокусом (TakeFocus, ReturnFocus, HandleEvent).

Для отрисовки списка присутствуют методы: определения атрибутов элемента списка (FontRecord), метод рисования списка (DrawContent), метод рисования элемента списка (DrawTarget), метод рисования активного элемента списка (DrawTarget), метод рисования информации об элементе списка (DrawRecordInfo), а так же метод обновления состояния списка (ChangeContent).

На рисунке 3.13 представлен класс ListSelectBox.

Рисунок 3.17 - Класс ListSelectBox

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

В классе содержаться данные о количестве выделенных элементов (is_select), списке элементов с флагом выделения (select_list) и цвете выделения (select). Так же есть методы, которые позволяют получать и изменять эти данные (SelectColor, IsSelect, Select, ClearSelect).

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

На рисунке 3.14 представлен класс ListFileBox.

Рисунок 3.18 - Класс ListFileBox

В классе содержаться данные о списке файлов (folder) и об иерархической структуре первого видимого файла (visible_position) и первого целевого файла (target_position).

Конструкторы аналогичны конструкторам базового класса.

В классе есть методы для привязки источника списка файлов (ViewFolder), входа в выбранную директорию (Enter) и выхода из директории (Exit). Так же методы для сохранения контекста текущей директории (SaveContextFolder) перед открытием новой и восстановление контекста родительской директории после закрытия предыдущей (RestoreContextFolder). Остальные методы наследуются от базового класса и имеют подобную функциональность.

На рисунке 3.15 представлен класс ListVolumeBox.

Рисунок 3.19 - Класса ListVolumeBox

В классе содержится указатель на список файловых систем (volume) и метод привязки списка к визуальному элементу (ViewVolume).

Конструкторы аналогичны конструкторам базового класса.

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

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

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

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

Рисунок 3.20 - Схема наследования классов работы с файлами

Классы IStatus, IMediaRecord, IFileRecord, IFile, IVolumeRecord, IVolume, IMediaLocator являются полностью абстрактными и определяют интерфейс для файловой системы.

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

На рисунке 3.17 представлен класс EFIMediaLocator.

Рисунок 3.21 - Класса EFIMediaLocator

Класс содержит данные об идентификаторе локатора, который необходим для реализации локатора (guid), который будет объединять различные реализации, данные о статусе последней операции (status), историю найденных файловых систем (history), количество найденных файловых систем (number) и список идентификаторов найденных файловых систем (id). Описанные данные возвращают соответствующие методы (LastStatus, LocatorGUID, Number, ID). Так же есть метод, который возвращает идентификатор файловой системы, с которой осуществлен запуск программы (StatusID).

Класс не содержит конструкторы.

В классе содержаться методы поиска активных файловых систем (Locate) и для получения интерфейса файловой системы (Volume), для определения текущего индекса файловой системы по идентификатору (Index), методы для добавления в список элементов активных файловых систем (AddID), очистки списка активных файловых систем (ClearID).

На рисунке 3.18 представлен класс EFIVolumeRecord.

Рисунок 3.22 - Класса EFIVolumeRecord

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

На рисунке 3.19 представлен класс EFIVolume.

Рисунок 3.23 - Класса EFIVolume

Класс содержит дескриптор файловой системы (handle), указатель на встроенный интерфейс файловой системы (volume), на корневой каталог (root) и информацию о файловой системе (info).

В классе есть методы для получения интерфейса работы с корневым каталогом (Root) и метод закрытия текущего интерфейса файловой системы (Close).

Прочие методы аналогичны классам предыдущего метода.

На рисунке 3.20 представлен класс EFIFileRecord.

Рисунок 3.24 - Класса EFIFileRecord

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

На рисунке 3.21 представлен класс EFIFile.

Рисунок 3.25 - Класс EFIFile

Класс содержит указатель на встроенный интерфейс файла (file) и информацию о файловой системе (info).

Класс содержит методы для открытия нового файла (Open), закрытия текущего (Close), удаления текущего (Delete), методы для получения или установки указателя на позицию внутри файла, для чтения информации о файле, содержащемся в каталоге или для чтения набора байт из файла (Read), для записи массива в файл (Write) и для сброса данных кешированых операции на жесткий диск (Flush).

Прочие методы аналогичны классам предыдущего метода.

3.3Разработка алгоритмов выполнения файловых операций на основе спроектированных интерфейсов

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

На рисунке 3.22 представлена схема алгоритма копирования.

Рисунок 3.26 - Схема алгоритма копирования

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

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

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

На рисунке 3.23 показана схема алгоритма копирования из директории в директорию.

Рисунок 3.27 - Схема алгоритма копирования из директории в директорию

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

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

На рисунке 3.24 показана схема алгоритма копирования из файла в директорию.

Рисунок 3.28 - Схема алгоритма копирования из файла в директорию

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

На рисунке 3.25 показана схема алгоритма копирования из файла в файл.

Рисунок 3.29 - Схема алгоритма копирования из файла в файл

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

На рисунке 3.26 представлена схема алгоритма удаления.

Рисунок 3.30 - Схема алгоритма удаления

Если удаляемы объект является директорией, то для каждого элемента директории рекурсивно вызывается алгоритм удаления, если файлом - удаляется.

3.4Разработка поддержки пользовательских сценариев

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

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

Функции встраиваются в интерпретатор по средствам метода AddNative объекта CTinyJS.

В интерпретатор встроены три функции.

Функция VolumeLocator() возвращает объект VolumeLocator для обеспечения доступа к файловым системам.

Функция Filter() возвращает объект Filter для обеспечения отсечения не нужных файлов при выполнении файловых операции.

Функция print(string) выводит форматированную текстовую строку в стандартный поток ввода/вывода.

Пример вывода текстовой строки с переходом на следующую строку -("Hello, world!!!\n");

В результате работы вышеприведенной строки в стандартный поток ввода вывода будет записана строка «Hello, world!!!» и специальным символом «\n» будет осуществлен переход на следующую строку.

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

На рисунке 3.27 изображена схема наследования классов интерпретатора пользовательских сценариев.

Рисунок 3.27 - Схема наследования классов интерпретатора пользовательских сценариев

Объект VolumeLocator применяется для получения доступа к файловым системам.

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

var sys = VolumeLocator();

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

Метод sys.Find() предназначен для обновления списка доступных файловых систем. Например, после подключения устройства хранения (Flash - накопителя) необходимо вызвать данный метод, чтобы можно было получить доступ к её файловой системе из пользовательского сценария. При запуске интерпретатора автоматически происходит формирование списка файловых систем, поэтому при неизменной конфигурации оборудования вызывать данный метод необязательно. Во всех остальных случаях необходимо обновить список файловых систем.

Метод sys.NumberVolume() возвращает значение количества файловых систем найденных последним вызовом Find();

Метод sys.Volume(index) принимает в качестве входного параметра - индекс и возвращает объект файловой системы. Индекс файловой системы в списке файловых систем - это целое число в диапазоне от нуля до количества файловых систем минус один [0, NumberVolume() - 1].

Функция sys.StartVolume() возвращает объект файловой системы, которая содержит файл запущенного интерпретатора, то есть если программа запущена с USB - накопителя, то данным методом будет возвращен объект файловой системы USB - накопителя.

Для всех далее описанных методов передаваемый путь может состоять из вложенных каталогов разделенных знаком «\», в том числе и служебных имен «.» и «..». Служебное имя «.» указывает на текущий каталог, то есть пути «.\dir1\dir12» и «dir1\dir12» равнозначны. Служебное имя «..» указывает на родительский каталог, то есть пути «dir1\..\dir1\dir12» и «dir1\dir12» равнозначны. Пример пути: «..\dir\file.txt»

Объект Volume применяется для получения доступа к файлам и директориям файловой системы. Объект создается методами Volume(index) и StartVolume() объекта VolumeLocator.

Пример создания объекта файловой системы Volume -

var vol = sys.StartVolume();

Метод vol.ID() возвращает идентификатор файловой системы. Идентификатор файловой системы неизменен для существующих портов ввода/вывода (например, USB-портов) на все время работы приложения. Если в течение времени работы приложения устройство хранения информации будет исключено, а затем включено в тот же самый порт, то после обновления конфигурации устройство хранения будет иметь тот же идентификатор.

Метод vol.CheckFile(path) принимает на вход путь до файла и определяет, существует ли по такому пути файл и на выходе возвращает логическое значение «истина» или «ложь». В случае если путь не указывает на файл или вовсе не существует, то возвращаемое значение будет «ложь», в противном случае «истина».

Метод vol.CheckFolder(path) принимает на вход путь до директории и определяет существует ли по такому пути директория и на выходе возвращает логическое значение «истина» или «ложь». В случае если путь не указывает на директорию или вовсе не существует, то возвращаемое значение будет «ложь», в противном случае «истина».

Метод vol.File(path) принимает на вход путь и возвращает объект файла. При создании объекта не производиться никаких проверок, то есть путь, передаваемый в метод, может не существовать или указывать на директорию, в любом случае объект файла будет создан.

Метод vol.Folder(path) принимает на вход путь и возвращает объект директории. При создании объекта не производиться никаких проверок, то есть путь, передаваемый в метод, может не существовать или указывать на файл, в любом случае объект файла будет создан.

Объект Folder применяется для получения информации о директории и выполнения операций над содержимым директории. Объект создается методом Folder(path) объектов Volume и Folder.

Пример создания объекта директории Folder -

var fol = vol.Folder(path);

Метод fol.Check() возвращает логическое значение «истина», если путь, указываемый при создании объекта директории, был верным и был получен доступ к объекту, в противном случае возвращаемое значение будет «ложь» и дальнейшие операции с таким объектом бессмысленны.

Метод fol.Size() - возвращает числовое значение «0», соответствующее файловому размеру директории.

Метод fol.OnlyRead() возвращает логическое значение «истина», если директория имеет установленный атрибут «только для чтения», в противном случае возвращаемое значение будет «ложь».

Метод fol.Hidden() возвращает логическое значение «истина», если директория имеет установленный атрибут «скрытый», в противном случае возвращаемое значение будет «ложь».

Метод fol.Arhive() возвращает логическое значение «истина», если директория имеет установленный атрибут «архивный», в противном случае возвращаемое значение будет «ложь».

Метод fol.System() возвращает логическое значение «истина», если директория имеет установленный атрибут «системный», в противном случае возвращаемое значение будет «ложь».

Метод fol.LastAccessDateTime() возвращает строковое представление даты и времени последнего открытия директории.

Метод fol.LastModificationDateTime() возвращает строковое представление даты и времени последнего изменения директории.

Метод fol.CreateDateTime() возвращает строковое представление даты и времени создания директории.

Метод fol.Name() возвращает строковое представление имени директории.

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

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

Метод fol.ResetFilePointer() сбрасывает счетчик, который указывает на порядковый номер следующего открываемого файла, в начальное значение. После сброса можно заново получить объекты файлов методом GetContentFile(), содержащиеся в директории.

Метод fol.ResetFolderPointer() сбрасывает счетчик, который указывает на порядковый номер следующей открываемой директории, в начальное значение. После сброса можно заново получить объекты директории методом GetContentFolder(), содержащиеся в родительской директории.

Метод fol.CheckFile(path) принимает на вход путь до файла и определяет существует ли по такому пути файл и на выходе возвращает логическое значение «истина» или «ложь». В случае если путь не указывает на файл или вовсе не существует, то возвращаемое значение будет «ложь», в противном случае «истина».

Метод fol.CheckFolder(path) принимает на вход путь до директории и определяет существует ли по такому пути директория и на выходе возвращает логическое значение «истина» или «ложь». В случае если путь не указывает на директорию или вовсе не существует, то возвращаемое значение будет «ложь», в противном случае «истина».

Метод fol.File(path) принимает на вход путь и возвращает объект файла. При создании объекта не производиться никаких проверок, то есть путь, передаваемый в метод, может не существовать или указывать на директорию, в любом случае объект файла будет создан.

Метод fol.Folder(path) принимает на вход путь и возвращает объект директории. При создании объекта не производиться никаких проверок, то есть путь, передаваемый в метод, может не существовать или указывать на файл, в любом случае объект файла будет создан.

Метод fol.Copy(filter, vol, path) не возвращает значений, принимает в качестве входных параметров объекты:

filter - объект фильтра определяет свойства, которыми должен соответствовать файл, чтобы быть скопированным;

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

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

Копирование содержимого директории источника производиться в директорию с аналогичным именем по путь назначения. Например, если директорией источником является «dir\source», а директорией назначения «dir\destination», то после успешного копирования содержимое директории источника будет находиться по пути «dir\destination\source».

Путь, в который осуществляется копирование, должен указывать на директорию, в противном случае копирование завершиться с ошибкой. Путь может не существовать, и будет создан, если только последняя директория в пути не существует, создать одновременно более одной вложенной директории нельзя. Например, путь назначения «dir\exist\notexist», где все директории, кроме последней, существуют, будет создан. Путь «dir\notexist\notexist», где существует только первая директория, создан не будет и операция копирования завершится с ошибкой.

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

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

До создания объектов методами File(path) и Folder(path) объектов Volume и Folder можно вызывать методы CheckFile(path) и CheckFolder(path) или после создания объектов вызвать метод объекта Check(), которые проверят корректность пути.

Объект File применяется для получения информации о файле и выполнения операций над файлом. Объект создается методом File(path) объектов Volume и Folder.

Пример создания объекта директории File -

var fol.File(folder/file.txt);

Метод file.Check() возвращает логическое значение «истина», если путь, указываемый при создании объекта файла, был верным и был получен доступ к объекту, в противном случае возвращаемое значение будет «ложь» и дальнейшие операции с таким объектом бессмысленны.

Метод file.Size() возвращает значение размера файла в байтах.

Метод file.ReadOnly() возвращает логическое значение «истина», если файл имеет установленный атрибут «только для чтения», в противном случае возвращаемое значение будет «ложь».

Метод file.Hidden() возвращает логическое значение «истина», если файл имеет установленный атрибут «скрытый», в противном случае возвращаемое значение будет «ложь».

Метод file.Archive() возвращает логическое значение «истина», если файл имеет установленный атрибут «архивный», в противном случае возвращаемое значение будет «ложь».

Метод file.System() возвращает логическое значение «истина», если файл имеет установленный атрибут «системный», в противном случае возвращаемое значение будет «ложь».

Метод file. LastAccessDateTime() возвращает строковое представление даты и времени последнего открытия файла.

Метод file.LastModificationDateTime() возвращает строковое представление даты и времени последнего изменения файла.

Метод file. CreateDateTime() возвращает строковое представление даты и времени создания файла.

Метод file.Name() возвращает строковое представление имени файла.

Метод file.Copy(filter, vol, path) не возвращает значений, принимает в качестве входных параметров объекты:

filter - объект фильтра определяет свойства, которыми должен соответствовать файл, чтобы быть скопированным;

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

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

Путь назначения должен является файлом. Копия файла создается с тем именем, который указан в пути. Например, если файлом источником является «dir\source.doc», а файлом назначения «dir\destination.doc», то после успешного копирования содержимое файла источника будет находиться по пути «dir\destination.doc».

Если путь назначения является директорией, то копия файла создается внутри директории с аналогичным именем. Например, если файлом источником является «dir\source.doc», а директорией назначения «dir\destination», то после успешного копирования содержимое файла источника будет находиться по пути «dir\destination\source.doc».

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

Метод file.CopyFile(vol, path) метод аналогичен методу Copy(filter, vol, path) за исключением того, что не принимает на вход объект фильтра, то есть, безусловно, копирует файл.

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

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

Пример создания объекта фильтра Filter -

var filter = Filter();

Метод filter.GetMaxLastAccessDateTime() возвращает верхнюю границу отрезка для пропускания по времени последнего доступа к файлу.

Метод filter.GetMaxLastModificationDateTime() возвращает верхнюю границу отрезка ограничения по времени последней модификации файла.

Метод filter.GetMaxCreateDateTime() возвращает верхнюю границу отрезка ограничения по времени создания файла.

Метод filter.GetMaxSize() возвращает верхнюю границу отрезка по размеру файла.

Метод filter.GetMinLastAccessDateTime() возвращает нижнюю границу отрезка для пропускания по времени последнего доступа к файлу.

Метод filter.GetMinLastModificationDateTime() возвращает нижнюю границу отрезка ограничения по времени последней модификации файла.

Метод filter.GetMinCreateDateTime() возвращает нижнюю границу отрезка ограничения по времени создания файла.

Метод filter.GetMinSize() возвращает нижнюю границу отрезка по размеру файла.

Метод filter.GetExactLastAccessDateTime() возвращает точное значение ограничения времени последнего доступа к файлу.

Метод filter.GetExactLastModificationDateTime() возвращает точное значение ограничения времени последней модификации файла.

Метод filter.GetExactCreateDateTime() возвращает точное значение ограничения времени создания файла.

Метод filter.GetExactSize() возвращает точное значение ограничения размера файла.

Метод filter.SetMaxLastAccessDateTime(value) устанавливает верхнюю границу отрезка для пропускания по времени последнего доступа к файлу.

Метод filter.SetMaxLastModificationDateTime(value) устанавливает верхнюю границу отрезка ограничения по времени последней модификации файла.

Метод filter.SetMaxCreateDateTime(value) устанавливает верхнюю границу отрезка ограничения по времени создания файла.

Метод filter.SetMaxSize(value) устанавливает верхнюю границу отрезка по размеру файла.

Метод filter.SetMinLastAccessDateTime(value) устанавливает нижнюю границу отрезка для пропускания по времени последнего доступа к файлу.

Метод filter.SetMinLastModificationDateTime(value) устанавливает нижнюю границу отрезка ограничения по времени последней модификации файла.

Метод filter.SetMinCreateDateTime(value) устанавливает нижнюю границу отрезка ограничения по времени создания файла.

Метод filter.SetMinSize(value) устанавливает нижнюю границу отрезка по размеру файла.

Метод filter.SetExactLastAccessDateTime(value) устанавливает точное значение ограничения времени последнего доступа к файлу.

Метод filter.SetExactLastModificationDateTime(value) устанавливает точное значение ограничения времени последней модификации файла.

Метод filter.SetExactCreateDateTime(value) устанавливает точное значение ограничения времени создания файла.

Метод filter.SetExactSize(value) устанавливает точное значение ограничения размера файла.

Метод filter.GetPatternName() возвращает шаблон имени файла.

Метод filter.SetPatternName(value) устанавливает шаблон имени файла.

Ограничения на параметры времени последнего доступа, модификации и создания задаются и возврящаются в виде строки формата «ГГГГ-ММ-ДД ЧЧ:ММ».

Пример задания даты и времени -

-04-02 12:00

Ограничения на размер файла задаются в десятичной системе счисления, в байтах.

Пример задания ограничения размера файла -

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

«*» предполагает наличие в позиции нахождения знака любых символов в количестве от нуля и более. Например, строка «file_of_*.doc» эквивалентна следующим вариантам: «file_of_.doc», «file_of_Mike.doc», «file_of_Anna.doc», и так далее.

«?» предполагает наличие в позиции нахождения выражения одного любого символа. Например, строка «file?.doc» эквивалентна следующим вариантам: «file1.doc», «fileA.doc», «file9.doc», и так далее, но не эквивалентна строке «file12.doc»

«[a-z]» предполагает наличие в позиции нахождения выражения одного символа из диапазона указанного в кавычках. Например, строка «file[0-9].doc» эквивалентна следующим вариантам: «file1.doc», «file5.doc», «file9.doc», и так далее, но не эквивалентна строке «fileA.doc» или «file12.doc».

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

Выводы

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

4Теория формальных языков

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

4.1Цепочки символов и операции над ними

Алфавитом называется непустое конечное множество символов.

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

Длиной цепочки является количество символов в ней. Например, цепочка имеет длину .

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

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

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

Над цепочками можно выделить следующие операции:

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

,

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

Обращение цепочки - это запись ее символов в обратном порядке, обозначается . Например, для цепочки ее обращение . Свойство операции обращения

.

Итерация цепочки раз - это ее сцепление (повторение) раз, обозначается .

Для пустой цепочки справедливы следующие равенства:

;

;

;

;

.

4.2Понятие языка. Способы задания языков

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

Цепочка символов является цепочкой над алфавитом , если в нее входят только символы этого алфавита.

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

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

Для любого языка справедливо .

Язык включает в себя язык

, если .

Два языка эквивалентны

, если и .

Конкатенацией (объединением) языков и называют язык , состоящий из всевозможных сцеплений цепочек языков и :

.

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

, для , для всех . .

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

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

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

указание способа порождения цепочек языка (задание грамматики языка) - применение т.н. генератора.

задание метода распознавания цепочек языка - использование распознавателя.

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

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

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

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

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

4.3Понятие грамматики. Форма Бэкуса-Наура

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

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

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

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

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

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

полный алфавит грамматики ; - множество правил вида

где ; - начальный (целевой) символ грамматики , с которого начинается процесс порождения цепочек языка.

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

Во множестве правил грамматики может быть несколько правил, имеющих одинаковые левые части, например

, , …,

Тогда эти правила записываются в одну строку

.

Рассмотренная форма записи правил грамматики называется формой Бэкуса-Наура. В ней, как правило, нетерминальные символы заключаются в угловые скобки .

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

. : ; ;

В данной грамматике множество нетерминальных символов содержит три элемента (символы ,,), множество терминальных символов - 12 элементов (10 цифр и два знака), множество P - 15 правил, записанных в три строки. Начальный символ грамматики - .

В грамматике можно изменить названия нетерминальных символов без какого-то изменения языка, заданного ею. Терминальные символы изменять нельзя, так как они соответствуют алфавиту задаваемого языка.

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

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

, .

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

, .

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

4.4Классификация грамматик по Хомскому

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

Пусть грамматика обозначена как

В соответствии с иерархией Хомского выделяют четыре типа грамматик.

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

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

Тип 1 - контекстно-зависимые и неукорачивающие грамматики. К этому типу относятся два основных класса грамматик.

Контекстно-зависимые грамматики имеют правила вида

, где , , .

Неукорачивающие грамматики имеют правила вид

где , .

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

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

Эти два класса грамматик эквивалентны.

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

Тип 2 - контекстно-свободные грамматики. Контекстно-свободные грамматики имеют правила вида , где , . В правой части у них стоит всегда хотя бы один символ.

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

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

Тип 3 - регулярные грамматики. К этому типу относятся два эквивалентных класса грамматик: леволинейные и праволинейные.

Леволинейные грамматики могут иметь правила двух видов

, или

где , .

Праволинейные грамматики имеют правила тоже двух видов

, или ,

где ,

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

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

4.5Классификация языков

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

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

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

Тип 1 - контекстно-зависимые (КЗ) языки.В общем случае время на распознавание языка типа 1 экспоненциально зависит от длины исходной цепочки символов.

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

Однако языки программирования имеют более простую структуру, поэтому в компиляторах КЗ-языки не применяются.

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

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

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

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

4.6Распознаватели. Задача разбора

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

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

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

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

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

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

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

Распознаватель входит в состав компилятора и является частью программного обеспечения компьютера. На рисунке 4.1 представлена условная схема распознавателя.

Рисунок 4.31 - Условная схема распознавателя

Основные компоненты распознавателя:

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

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

устройство управления (УУ), которое координирует работу распознавателя, имеет некоторое множество состояний и конечную память;

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

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

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

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

Такт состоит из следующих моментов:

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

в память помещается некоторая информация;

изменяется состояние УУ.

В процессе работы распознавателя происходит смена конфигураций. Конфигурация распознавателя (мгновенное описание) определяется следующими параметрами:

состояние УУ;

содержимое входной ленты и положение считывающей головки в ней;

содержимое внешней памяти.

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

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

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

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

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

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

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

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

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

По видам внешней памяти распознаватели бывают следующих типов:

распознаватели без внешней памяти;

распознаватели с ограниченной внешней памятью;

с неограниченной внешней памятью.

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

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

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

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

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

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

Для контекстно-свободных языков распознавателями являются односторонние недетерминированные автоматы с магазинной (стековой) внешней памятью. Кроме того, среди всего множества контекстно-свободных языков можно выделить подкласс детерминированных языков, для которых распознавателями являются детерминированные автоматы с магазинной памятью. Этот класс языков наиболее интересен для построения компиляторов.

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

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

4.8Определение и свойства регулярных выражений

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

Регулярное множество и регулярное выражение для некоторого алфавита определяется рекурсивно следующим образом:

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

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

где обозначает регулярное множество ;

если и - произвольные регулярные выражения, обозначающие регулярные множества и , то , , - регулярные выражения, обозначающие соответственно регулярные множества , , ;

ничто другое регулярным выражением и регулярным множеством не является.

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

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

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

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

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

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

и : , .

Пусть , , - регулярные выражения. Тогда свойства регулярных выражений можно записать в виде следующих выражений:

;

;

;

;

;

- ;

- ;

- ;

- ;

- ;

- ;

- ;

- ;

- .

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

4.9Способы задания регулярных языков

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

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

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

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

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

4.10Свойства регулярных языков

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

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

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

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

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

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

где , и тогда , ".

Пример. Рассмотрим язык

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

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

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

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

Выводы

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

5Защита целостности информации пользовательских сценариев

5.1Определение электронной цифровой подписи

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

Схема электронной подписи обычно включает в себя:

алгоритм генерации ключевых пар пользователя;

функцию вычисления подписи;

функцию проверки подписи.

Функция вычисления подписи на основе документа и секретного ключа пользователя вычисляет собственно подпись. В зависимости от алгоритма функция вычисления подписи может быть детерминированной или вероятностной. Детерминированные функции всегда вычисляют одинаковую подпись по одинаковым входным данным. Вероятностные функции вносят в подпись элемент случайности, что усиливает криптостойкость алгоритмов ЭЦП. Однако, для вероятностных схем необходим надёжный источник случайности (либо аппаратный генератор шума, либо криптографически надёжный генератор псевдослучайных бит), что усложняет реализацию.

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

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

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

Алгоритмы ЭЦП делятся на два больших класса: обычные цифровые подписи и цифровые подписи с восстановлением документа. Обычные цифровые подписи необходимо пристыковывать к подписываемому документу. К этому классу относятся, например, алгоритмы, основанные на эллиптических кривых (ECDSA, ГОСТ Р 34.10-2001, ДСТУ 4145-2002). Цифровые подписи с восстановлением документа содержат в себе подписываемый документ: в процессе проверки подписи автоматически вычисляется и тело документа. К этому классу относится один из самых популярных алгоритмов - RSA.

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

5.2Свойства электронной цифровой подписи

Цифровая подпись обеспечивает:

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

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

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

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

организацию юридически значимого электронного документооборота.

Возможны следующие угрозы цифровой подписи:

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

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

документы редко оформляют в виде Plain Text - файла, чаще всего в формате DOC или HTML.

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

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

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

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

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

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

Тем не менее, возможны ещё такие угрозы системам цифровой подписи:

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

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

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

5.3Управление ключами

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

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

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

5.4Криптосистема с открытым ключом

На рисунке 5.1 представлена схема криптосистемы с открытым ключом.

Рисунок 5.32 - Схема криптосистемы с открытым ключом

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

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

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

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

Рисунок 5.33 - Схема использования цифровой подписи

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

Выводы

В данном разделе рассмотрены вопросы защиты целостности информации пользовательского сценария: определения и свойства ЭЦП, криптосистема с открытым ключом и организация защиты целостности пользовательского сценария на основе системы с открытым ключом.

интерфейс алгоритм язык цифровой

6Экономическое обоснование разработки

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

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

6.1Расчет затрат на создание программного обеспечения, цены и прибыли от его реализации

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

руководитель (Р);

ведущий инженер-программист (ВИП);

инженер-программист (ИП);

оператор (О).

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

где - месячный оклад работника, руб;

- минимальный размер оплаты труда, руб (5554 руб);

- коэффициент профессиональной квалификационной группы (ПКГ) работника.

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

Таблица 6.7 - Состав разработчиков программного обеспечения

Наименование должностиЧисленность, челПКГМесячный оклад, руб.Руководитель11,458053,30Ведущий инженер-программист11,176498,18Инженер-программист11,16109,40Оператор11,045776,16

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

,

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

- минимальное время выполнения работы, часов;

- максимальное время выполнения работы, часов.

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

Таблица 6.8 - Трудоемкость выполнения работ

Наименование работычел-час

чел-час,

чел-часВ том числеР, чел-часВИП, чел-часИП, чел-часО, чел-часРазработка технического задания182824816--Изучение технического задания102016--88Настройка среды выполнения проекта446456--1640Подбор литературы263632824--Изучение литературы467664--3232Изучение платформы создания программного обеспечения240440360-80160120Изучение аналогов и выбор прототипа1902602323212080-Разработка структуры программного обеспечения2004003208016080-Написание программного обеспечения440640560-80160320Тестирование и отладка программного обеспечения150300240-2472144Разработка документации и чертежей7211296164040-Всего:143623762000144544648664

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

Специализированные исследования среды разработки:

подбор литературы;

изучение литературы;

изучение платформы создания программного обеспечения.

Создание программного обеспечения:

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

написание программного обеспечения;

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

Прочие затраты по разработке программного обеспечения:

разработка технического задания;

изучение технического задания;

настройка среды выполнения проекта.

Маркетинговые исследования:

изучение аналогов и выбор прототипа;

Оформление программного продукта:

разработка документации и чертежей;

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

Таблица 6.9 - Группы работ по созданию программного обеспечения

Наименование комплекса работОбозначение,

чел-часВ том числеР, чел-часВИП, чел-часИП, чел-часО, чел-час1. Специализированные исследования среды разработкиВи45681041921522. Создание программного обеспеченияВс1120802643124643. Прочие затраты по разработке программного обеспеченияВпр9681624484. Маркетинговые исследованияВми2323212080-5. Оформление программного продуктаВоф96164040-Всего:Во2000144544648664

Данные из таблицы 6.3 - исходные данные для расчета затрат на создание программного обеспечения.

Общие затраты на создание программного обеспечения определяются по формуле:

где - общие затраты на создание программного обеспечения, руб;

- затраты на разработку программного обеспечения, руб;

- затраты на оформление программного обеспечения, руб (15% от );

- затраты на маркетинговые исследования, руб (10% от );

Затраты на разработку программного обеспечения рассчитываются по формуле:

где - затраты на группы работ, руб;

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

- прочие затраты, связанные с разработкой программного обеспечения, руб (40% от ).

Затраты на проведение комплексов работ определяются по формуле:

где - ставка страховых взносов (34,2 % от );

- общий фонд оплаты труда работников, руб;

- накладные расходы организации, руб (100% от ).

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

где - затраты на выплату заработной платы работникам, руб;

- премия, предусмотренная для работников, руб (25 % от );

- выплаты по районному коэффициенту, руб (для г. Кирова 15 % от( + )).

Затраты на заработную плату работников, определяются по формуле:

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

- время участия работника определенной квалификации в разработке, часов (таблица (6.2));

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

- месячный оклад работника в соответствии с его категорией или тарифным разрядом ЕТС бюджетной сферы, руб;

- длительность смены, часов (8 часов);

- среднее число рабочих дней в месяце, дней (21 день).

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

где - затраты на электроэнергию, потребляемую компьютерами, руб;

- амортизационные отчисления от стоимости парка компьютеров, руб.

Затраты на электроэнергию, потребляемую компьютерами, определяются по формуле:

,

где - установленная мощность одного компьютера, кВт (0,7 кВт);

- время работы компьютеров, часов (2000 часов);

- стоимость одного кВт/час, руб (2,2 руб.).

Затраты на амортизационные отчисления определяются по формуле:

,

где - продолжительность осуществления проекта, месяц;

- число компьютеров, используемых в разработке, штук (2 штуки);

- стоимость одного компьютера, руб (25000 руб);

- срок полезного использования компьютеров, месяцев (36 месяцев).

Расчет сметы по формулам (6.1) - (6.10).

= (544 * 6498,18 + 648 * 6109,40) / 8 * 21 = 44606,55 руб.

= (144 * 8053,30 + 664 * 5776,16) / 8 * 21 = 29732,41 руб.

= 44606,55 + 29732,41 = 74338,96 руб.

= 74338,96 * 0,25 = 18584,74 руб.

= (74338,96 + 18584,74) * 0,15 = 13938,56 руб.

= 74338,96 + 18584,74 + 13938,56 = 106862,26 руб.

= (1 + 0,342) * 106862,26 = 36546,89 руб.

= 74338,96 * 1 = 74338,96 руб.

= 106862,26 + 36546,89 + 74338,96 = 217748,11 руб.

= 12 * 2 * 25000 / 36 = 16666,67 руб.

= 0,7 * 2000 * 2,2 = 3080 руб.

= 16666,67 + 3080 = 19746,67 руб.

= 217748,11 * 0,40 = 87099,24 руб.

= 217748,11 * 87099,24 + 19746,67 = 324594,02 руб.

= 324594,02 * 0,15 = 48689,10 руб.

= 324594,02 * 0,10 = 32459,40 руб.

= 324594,02 + 48689,10 + 32459,40 = 405744,52 руб.

Смета затрат на создание программного обеспечения приведена далее в таблице.

Таблица 6.10 - Смета затрат на создание программного обеспечения

Наименование статьи затратОбозначениеСумма, руб.Затраты на заработную плату программистов.44606,55Затраты на заработную плату других специалистов29732,41Итого затрат на заработную плату всех работников74338,96Премия18584,74Выплаты по районному коэффициенту13938,56Страховые взносы36546,89Накладные расходы74338,96Итого затрат на проведение комплексов работ217748,11Затраты, связанные с работой компьютера19746,67Прочие затраты87099,24Итого затрат на разработку программного продукта324594,02Затраты на оформление программного продукта48689,10Затраты на маркетинговые исследования32459,40Всего затрат на создание программного продукта405744,52

После расчёта общих затрат на создание программного обеспечения (таблица 6.4) определяются его проектные цены: цена создания , розничная цена (цена реализации) .

Цена создания определяется по формуле:

,

где - размер прибыли, руб.

Величина прибыли рассчитывается по формуле:

где - уровень рентабельности программного продукта, в размере 0,2.

Розничную цену программного обеспечения можно определить по формуле:

где - налог на добавленную стоимость, руб (18 %);

-наценка при реализации программного обеспечения через посредников, руб (15% от ).

Расчет цены программного обеспечения при продаже одной копии программного обеспечения по формулам (6.11) - (6.13).

= 405744,52 * 0,2 = 81148,90 руб.

= 405744,52 + 81148,90 = 486893,42 руб.

= 405744,52 * 0,18 = 73034,01 руб.

= 405744,52 * 0,15 = 60861,68 руб.

= 486893,42 + 73034,01 + 60861,68 = 620789,11 руб.

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

Таблица 6.11 - Расчет цены программного обеспечения

Наименование статьи затратОбозначениеСумма, рубЗатраты на создание программного обеспечения405744,52Прибыль от продажи одной копии программного обеспечения81148,90Цена создания одной копии программного обеспечения486893,42Налог на добавленную стоимость73034,01Торговая наценка60861,68Цена реализации (рыночная цена)620789,11

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

где - количество копий, снимаемых с оригинала программного обеспечения; - затраты на одно копирование программного обеспечения, руб. Затраты на одно копирование рассчитываются по формуле:

где - время одного копирования программного обеспечения, мин, (3 минуты);

- время подготовки носителя информация, мин (5 минут);

- стоимость одной минуты копирования, руб (5 рублей);

- розничная цена носителя информации, используемого под копию программного обеспечения, руб (15 рублей);

- затраты на копирование или печатание сопроводительной документации (инструкции для пользователя и др.) и приобретение упаковки для хранения этой документации и носителя информации, руб (принимается в размере 50% от МРОТ, = 2777 рубля).

Минимальная розничная цена программного обеспечения определяется по формуле:

где - ставка налога на добавленную стоимость, руб (18%);

- ставка торговой наценки, руб (15%).

Расчет цены программного обеспечения при продаже 10 копии программного обеспечения по формулам (6.14) - (6.16).

= (3 + 5) * 5 / 60 + 15 + 2777 = 2792,67 руб.

= (405744,52 / 10 + 2792,67) * (1 + 0,2) = 52040,55 руб.

= 52040,55 * (1 + 0,18) * (1 + 0,15) = 70619,02 руб.

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

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

Количество реализуемых копийЦена создания, рубРозничная цена, руб1490244,66652621052040,5570619,022027695,8837583,35013089,0717761,871008220,13811154,73

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

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

,

где - величина выручки от реализации программного продукта по рыночной цене, руб (выручка брутто);

- цена реализации разработанного программного обеспечения без учёта торговой наценки, руб;

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

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

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

- цена создания программного продукта, руб.

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

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

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

где - прибыль до налогообложения;

- прочие доходы, руб (3 % от );

- прочие расходы, руб (1 % от ).

Налог на прибыль определяется по формуле:

,

где - ставка налога на прибыль, руб (20%).

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

где - чистая прибыль фирмы, руб;

Расчет выручки и прибыли по формулам (6.17) - (6.22).

=665262 * 1 = 665262 руб.

= 490244,60 * 1 = 490244,60 руб.

= 81707,41 * (1 + 0,03 - 0,01) = 83341,56 руб.

= 83341,56 * 0,20 = 16668,31 руб.

= 83341,56 - 16668,31 = 66673,25 руб.

Чистую прибыль следует расходовать по следующим направлениям:

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

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

на благотворительные и экологические цели отчисляется 15 % прибыли;

на прочие цели отчисляется 10 % прибыли.

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

Таблица 6.13 - Формирование и использование выручки и прибыли

Наименование показателяОбозначениеСумма, рубВаловая выручка от реализации одной копии программного обеспечения по рыночной цене665262Налог на добавленную стоимость73034,01Выручка от продажи одной копии программного обеспечения по цене создания490244,60Общие затраты на создание и копирование программного обеспечения493037,27Прибыль от продажи программного обеспечения81707,41Прочие доходы2451,22Прочие расходы817,07Прибыль до налогообложения83341,56Налог на прибыль16668,31«Чистая» прибыль всего:66673,25на техническое развитие30002,96на оказание материальной помощи работникам20001,98на благотворительные и экологические цели10000,99на прочие цели6667,33

6.3Расчёт затрат, связанных с покупкой, внедрением и использованием программного продукта

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

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

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

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

- прочие капитальные затраты, связанные с внедрением программного обеспечения, руб (принимаются в размере 15 % от ).

Капитальные вложения на создание рабочего места пользователя программного обеспечения (без учёта износа), следует рассчитать по формуле:

где - необходимая площадь под рабочее место, кв. м. (4 кв. м.);

- стоимость одного квадратного метра площади, руб (16860 руб.);

- затраты на приобретение мебели, руб (15 % от Цком);

- время использования ЭВМ в течение года для решения всех задач с помощью купленного программного обеспечения, руб;

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

Общее время эксплуатации ЭВМ пользователем в течение года следует рассчитать по формуле:

где - длительность смены, часов (8 часов);

- число смен работы компьютера, шт (1 штука);

- среднее число рабочих дней в месяце, дней (21 дня);

- число месяцев в году, месяцев (12 месяцев);

- коэффициент использования компьютера в течение года (0,8).

Время использования ЭВМ в течение года для решения всех задач с помощью купленного программного продукта определяется по формуле:

где - время решения задач с помощью приобретаемого программного обеспечения в течение дня, часов (шесть часов);

- количество дней использования программного обеспечения в течение года, дней (100 дней).

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

где - рыночная цена ЭВМ на момент покупки программы, руб (цена ЭВМ принимается равной 25000 рублей);

- цена дополнительного технического оснащения компьютера, руб (принимается равной 30 % от );

- коэффициент, учитывающий затраты на транспортировку и установку компьютера и других технических средств, так как используется действующий компьютер, то = 0;

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

Расчет капитальных затрат на покупку и внедрение программного обеспечения по формулам (6.23) - (6.27).

= 6 * 100 = 600 часов.

= 8 * 1 * 21 * 12 * 0,8 = 1612,8 часов.

= (4 * 16860 + 0,15 * 25000) * 600 / 1612,8 = 26484,38 руб.

= 25000 * (1 + 0,3) * (1 + 0) * (1 - 0,3) × 600 / 1612,8 = 8463,54 руб.

= 620789,11 * 0,15 = 93118,37 руб.

= 620789,11 + 26484,38 + 8463,54 + 93118,37 = 748855,40 руб.

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

Таблица 6.14 - Капитальные затраты на покупку и внедрение программного обеспечения

Наименование затратОбозначениеСумма, рубЗатраты на покупку программного обеспечения620789,11Затраты на создание рабочего места26484,38Затраты на техническое оснащение рабочего места8463,54Прочие затраты93118,37Итого748855,40

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

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

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

- стоимость одного часа работы ЭВМ определённой модели у пользователя программного обеспечения, руб (без учёта амортизационных отчислений от стоимости приобретенного программного обеспечения примем 0,01 от минимальной заработной платы);

- рыночная цена купленного программного обеспечения, руб;

- предполагаемый срок использования программного обеспечения, лет (5 лет).

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

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

- затраты на решение задач, действующим способом, руб.

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

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

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

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

Областные и местные налоги и сборы, исчисляемые пропорционально затратам на оплату труда, следует определить формулой:

где - ставка сбора на содержание милиции и благоустройство территории;

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

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

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

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

= 600 * 55,54 + 620789,11 / 5 = 157481,82 руб.

= 0,3 * 5554 = 1666,20 руб.

= 3 * (66648 * (1 + 0,25) * (1 + 0,15)*(1 + 0,34) + 1666,20) = 130046,91

= 390140,73 - 157481,82 = 232658,91 руб.

= 748855,40 / 232658,91 = 3,22 года

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

Таблица 6.15 - Финансово-экономические показатели создания и использования программного обеспечения

Наименование показателяЕдиница измеренияЗначение показателяПоказатели фирмы-разработчика программного обеспеченияЧисло специалистов, участвующих в разработке программычел4Время создания программного обеспечениямес/чел3,125Число реализованных копийшт1Уровень рентабельности%20Затраты на создание программного обеспеченияруб405744,52Розничная цена 1 копиируб620789,11Балансовая прибыль от продажи программного обеспеченияруб83341,56Чистая прибыльруб66673,25Показатели фирмы-покупателя программного обеспеченияКапитальные затраты на покупку и внедрение программного обеспеченияруб748855,40Текущие расходы, связанные с использованием программного обеспеченияруб157481,82Годовая экономия от применения программного обеспеченияруб232658,91Расчетный срок окупаемости капитальных затратлет3,22

Выводы

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

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

7Обеспечение безопасности жизнедеятельности

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

Главным документом, регулирующим требования охраны труда, является трудовой кодекс российской федерации (ТК РФ), в частности 10 раздел «Охрана труда» и приказ министерства здравоохранения и социального развития от 12 апреля 2011 года номер 302н.

Согласно статье 209 ТК РФ:

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

Каждое мероприятие определяет набор требований к охране труда. В этой же статье дано определение требований охраны труда:

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

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

Для более полного рассмотрения вопросов данной главы целесообразно процитировать наиболее часто употребляемые термины из статьи 209 ТК РФ.

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

«Условия труда - совокупность факторов производственной среды и трудового процесса, оказывающих влияние на работоспособность и здоровье работника.»

«Безопасные условия труда - условия труда, при которых воздействие на работающих вредных и (или) опасных производственных факторов исключено либо уровни их воздействия не превышают установленных нормативов.»

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

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

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

Согласно статье 212 ТК РФ «работодатель обязан обеспечить: безопасность работников при эксплуатации зданий, сооружений, оборудования, осуществлении технологических процессов, а также применяемых в производстве инструментов, сырья и материалов»

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

Согласно пункту два приложения два приказа министерства здравоохранения и социального развития от 12 апреля 2011 года номер 302н к «работе по обслуживанию и ремонту действующих электроустановок с напряжением 42 вольта и выше переменного тока, 110 вольта и выше постоянного тока, а также монтажные, наладочные работы, испытания и измерения в этих электроустановках» допускаются работники, проходящие медицинский осмотр один раз в два года. Медицинский осмотр должен быть проведен офтальмологом, отоларингологом, неврологом на предмет остроты и поля зрения, вестибулярного анализа и аудиометрии. Так же должны отсутствовать дополнительные противопоказания:

стойкое понижение слуха (3 и более месяца) любой этиологии, одно- и двустороннее (острота слуха: шепотная речь не менее 3 метров) (кроме работ по ремонту и эксплуатации ЭВМ);

острота зрения с коррекцией ниже 0,5 на одном глазу и ниже 0,2 - на другом;

стойкое слезотечение, не поддающееся лечению;

ограничение поля зрения более чем на 20° по любому из меридианов;

нарушение функции вестибулярного анализатора любой этиологии;

беременность и период лактации.

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

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

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

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

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

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

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

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

предупреждения несчастных случаев на производстве.

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

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

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

Согласно статье 266 ТК РФ «лица в возрасте до восемнадцати лет принимаются на работу только после предварительного обязательного медицинского осмотра и в дальнейшем, до достижения возраста восемнадцати лет, ежегодно подлежат обязательному медицинскому осмотру».

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

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

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

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

Работники в возрасте до 21 года проходят периодические осмотры ежегодно.

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

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

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

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

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

Медицинская организация в 10-дневный срок с момента получения от работодателя поименного списка (но не позднее, чем за 14 дней до согласованной с работодателем даты начала проведения периодического осмотра) на основании указанного поименного списка составляет календарный план проведения периодического осмотра.

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

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

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

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

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

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

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

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

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

Статья 185 ТК РФ дает гарантии работникам, направляемым на медицинский осмотр, «на время прохождения медицинского осмотра за работниками, обязанными в соответствии с настоящим кодексом проходить такой осмотр, сохраняется средний заработок по месту работы».

7.2Обеспечение оптимальных параметров микроклимата в помещении вычислительного центра

Статья 219 ТК РФ говорит, что «каждый работник имеет право на: рабочее место, соответствующее требованиям охраны труда…». Одним из требовании охраны труда является соблюдений требований микроклимата помещений.

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

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

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

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

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

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

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

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

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

На нормируемые составляющие микроклимата влияет категория работы, определяемая на основе общих энергозатрат организма в ккал/ч (Вт). По этому показателю работы подразделяются на несколько категорий.

Категория Iа. Работы с интенсивностью энергозатрат до 120 ккал/ч (до 139 Вт), проводимые сидя и сопровождающиеся незначительным физическим напряжением (ряд профессий на предприятиях точного приборо- и машиностроения, на часовом, швейном производствах, в сфере управления и т. п.).

Категория Iб. Работы с интенсивностью энергозатрат 121-150 ккал/ч (140 -174 Вт), производимые сидя, стоя или связанные с ходьбой и сопровождающиеся некоторым физическим напряжением (ряд профессий в полиграфической промышленности, на предприятиях связи, контролёры, мастера в различных видах производства и т. п.).

Категория IIа. Работы с интенсивностью энергозатрат 151-200 ккал/ч (175 - 232 Вт), связанные с постоянной ходьбой, перемещением мелких (до 1 кг) изделий или предметов в положении стоя или сидя и требующие определённого физического напряжения (ряд профессий в механосборочных цехах машиностроительных предприятий, в прядильно-ткацком производстве и т. п.).

Категория IIб. Работы с интенсивностью энергозатрат 201 - 250 ккал/ч (233 -290 Вт), связанные с ходьбой, перемещением и переноской тяжестей до 10 кг и сопровождающиеся умеренным физическим напряжением (ряд профессий в механизированных литейных, прокатных, кузнечных, термических, сварочных цехах машиностроительных и металлургических предприятий и т. п.).

Категория III. Работы с энергозатратами более 250 ккал/ч (более 290 Вт), связанные с постоянным передвижением, перемещением значительных (свыше 10 кг) тяжестей и требующие больших физических усилий (ряд профессий в кузнечных цехах с ручной ковкой, литейных цехах с ручной набивкой и заливкой опок и т.п.).

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

температура воздуха, °С;

температура ограждающих поверхностей, °С;

скорость движения воздуха, м/с;

относительная влажность воздуха, %;

интенсивность теплового облучения, Вт/м2.

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

Этот эмпирический интегральный показатель характеризует сочетанное (комбинированное) действие на организм человека параметров микроклимата (температура, влажность, скорость движения воздуха и тепловое облучение) и оценивает его одночисловым показателем в градусах. Впервые он был установлен международным стандартом ИСО 7243-1982 «Окружающая среда с повышенной температурой - оценка влияния тепловой нагрузки на работающего человека, основанная на температурном по влажному и шаровому термометрам индексе» и обозначается как WBG - индекс.

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

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

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

Нормы параметров метеорологических условий в производственных помещениях регламентируются ГОСТ 12.1.005-88 «Общие санитарно-гигиенические требования к воздуху рабочей зоны». Стандарт устанавливает требования к показателям температуры воздуха, его относительной влажности, скорости движения воздуха для рабочей зоны производственных помещений в виде оптимальных и допустимых величин с учетом периода года и тяжести трудовой деятельности.

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

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

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

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

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

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

Выводы

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

Заключение

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

На основе экономических расчетов сделан вывод о целесообразности разработки. Определена цена создания программы - 405744,52 руб, рекомендуемая розничная цена в расчёте на одну копию - 620789,11 руб. Расчетная чистая прибыль от продаж составит 66673,25 руб.

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

Приложение

Авторская справка

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

Одновременно сообщаю, что:

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

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

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

. Данный проект не является результатом НИР или ОКР.

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

. Согласен на использование результатов своей работы безвозмездно в ВятГУ для учебного процесса.

. Использование моей дипломной работы в научных исследованиях оформляется в соответствии с законодательством РФ о защите интеллектуальной собственности.

«» 20г.Подпись автора

Сведения по авторской справке подтверждаю

«» 20г. Зав. Кафедрой

Перечень сокращений

ОС - операционная система

ПО - программное обеспечение

ВС - вычислительная система

ОП - оперативная память

ЦП - центральный процессор

УУ - устройство управления

КА - конечный автомат

ЭЦП - электронная цифровая подпись

Библиографический список

1. Unified Extensible Firmware Interface Specification, Version 2.3.1, Errata D, April, 2013 [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. UEFI Platform Initialization Specification, Version 1.3, September, 2008 [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. Zimmer, V. Beyond BIOS: developing with the Unified Extensible Firmware Interface [Текст] / Vincent Zimmer, Michael Rothman, Suresh Marisetty. - 2-е изд. - Intel Press, 2010.

4. Устройство файла UEFI BIOS, часть полуторная: UEFI Platform Initialization [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. Немного про UEFI и Secure Boot [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. UEFI Shell Specification Version 2.0, Errata A, September, 2008 [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. EDK II [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. EFI Shell [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. TinyJS [Электронный ресурс] - Электронные данные - Режим доступа: http://code.google.com/p/tiny-js

. Лафоре, Р. Объектно-ориентированное программирование в С++ [Текст]: пер. с англ. / Роберт Лафоре. - С.-Б.: «Питер», 2004. - 928 с.

. Шилдт, Г. Полный справочник по С++ [Текст]: пер. с англ. / Герберт Шилдт. - М.: «Вильямс», 2006. - 800 с.

12. В.Дж., Рейуорд-Смит. Теория формальных языков. Вводный курс [Текст]: пер. с англ. - М.: «Радио и связь», 1988. - 128 с.: ил.

. Пратт, Т. Языки программирования: реализация и разработка [Текст]: пер. с англ. / Т. Пратт, М. Зелковиц. - 4-е изд., - С.-П.: «Питер», 2002. - 690 с.

. Шнайдер, Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си [Текст]: пер. с англ. /Брюс Шнайдер. - 2-е изд., М.: «Триумф», 2002. - 816 с.

. Ященко, В.В. Введение в криптографию [Текст]: под общ. ред. В.В. Ященко. - 3-е изд., доп. -М.: МЦНМО: «ЧеРо», 2000. - 288 с.

. Электронная подпись [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. Криптосистема с открытым ключом [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. Защита программного обеспечения [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. Голдованская, Н.Г. Экономическое обоснование разработки программного обеспечения [Текст]: методические указания по выполнению экономического раздела дипломного проекта/ Н.Г. Голдованская, Л.Я. Хатиб. Киров, 2014

. Трудовой кодекс Российской Федерации от 30.12.01 №197-ФЗ [Электронный ресурс] - Электронные данные - Режим доступа: #"justify">. Кондиционер [Электронный ресурс] - Электронные данные - Режим доступа: http://ru.wikipedia.org/wiki/Кондиционер

Введение Файловые менеджеры являются неотъемлемой частью программной инфраструктуры любой операционной системы (ОС). Чтобы понять какие задачи должны реш

Больше работ по теме: