2 Описание информационных объектов и потоков

2.1 Описание информационных объектов

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

- Диспетчер службы ПЧ.

- ДСП станции.

- Локомотивная бригада.

2.2 Описание информационных потоков

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

3. Основные технические решения

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

3.1.1. Логическая и компонентная архитектура систем

Компонентная архитектура будет состоять из:

1. MySQL 5.0;

2. MySQL Workbench;

3. PHP 5.0;

4. HTML 5;

5. CSS

6. Java

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

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

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

- WEB-Сервер - сервер, принимающий HTTP-запросы от клиентов, обычно веб-браузеров, и выдающий им HTTP-ответы, как правило, вместе с HTML-страницей, изображением, файлом, медиа-потоком или другими данными. Реализован на Apach, для обработки будет служить PHP версии 5.0;

- WEB-Клиент – Средства, с помощью которых идет отображение интерфейса программы. HTHM 5, CSS 3, Java.

Ни рисунке 1 представлена логическая архитектура описанная выше.

Рис.1. Логическая архитектура.

3.1.2. Функциональная структура системы

Функциональная структура потоков данных представлена в Приложении 1.

3.2. Решения по взаимосвязям ас со смежными системами, обеспечению ее совместимости

Не планируется внедрение ИС «Информационное сопровождение» со смежными системами.

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

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

- основной режим, в котором все подсистемы выполняют свои основные функции;

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

В основном режиме функционирования система обеспечивает:

- работу пользователей в режиме – 24 часа в день, 7 дней в неделю (24х7);

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

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

- техническое обслуживание;

- модернизация аппаратно-программного комплекса;

- устранение аварийных ситуаций.

Сценарии проведения их диагностирования:

Подсистема сбора, обработки и загрузки данных:

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