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

Основы проектирования программ. Этапы создания программного обеспечения.

Содержание:

Введение

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

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

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

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

Этапы создания программного обеспечения

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

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

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

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

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

Рис. 1.1. Факторы, определяющие параметры разрабатываемого программного обеспечения

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

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

Анализ, формальная постановка и выбор метода решения

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

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

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

S = а x b,

где S - площадь; а, b - длины сторон.

Результат получают перемножением аргументов.

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

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

Полная модель должна включать также указание типов переменных.

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

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

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

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

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

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

Проектирование

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

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

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

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

Различают последовательности действий (вычислений) линейной, разветвленной и циклической структуры.

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

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

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

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

На изображение схем алгоритмов существует ГОСТ 19.701-90, согласно которому каждой группе действий ставится в соответствие блок особой формы.

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

В случае, когда схема алгоритма не умещается на листе, используют соединители.

Схема алгоритма детально отображает особенности разработанного алгоритма.

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

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

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

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

Реализация

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

Рис.1.2. Схема процесса подготовки программы к выполнению

На рис. 1.2 представлена схема процесса подготовки программы к выполнению.

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

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

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

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

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

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

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

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

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

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

Модификация

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

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

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

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

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

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

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

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

Рис. 1.3. Процесс выполнения программы (а) и ее отладки с помощью отладчика (б)

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

Создание программного обеспечения на примере электронной регистратуры

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

Формулирование требований к системе. Постановка задачи

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

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

административного Web-приложения – Back-офиса;
Web-приложения для пациентов, врачей и регистраторов – Front-офиса.

Средствами Back-офиса администраторы системы решают все задачи, связанные с ее эксплуатацией.

В рамках Front-офиса необходимо реализовать 3 интерфейса:

интерфейс пациента;
интерфейс регистратора;
интерфейс врача.

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

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

Обеспечить реализацию всех базовых стадий получения талона на прием к врачу, связанных с оформлением заявки на прием, ее подтверждением и отметкой о явке.
Исходя из концепции деления системы на Front-офис и Back-офис, провести разделение проекта на две части: клиентское и администраторское приложение, причем клиентское приложение подразделено на 3 взаимозависимых интерфейса.
Предоставить средства для навигации по базе данных на нескольких уровнях доступа (регистратор, врач, пациент и администратор).
Реализовать специфические возможности системы.

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

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

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

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

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

Архитектура системы

На основе анализа, проведенного выше, можно предложить следующую архитектуру (рис.2.1).

Архитектура приложения

Рис.2.1. Архитектура приложения

Основные архитектурные принципы:

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

Проектирование базы данных

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

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

Упрощенно, (первое определение Кодда) СУБД – это система, в которой выполняются, как минимум, два условия:

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

Основным понятием РБД являются сущности.

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

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

Таблица 2.1

Перечень сущностей предметной области

Название и обозначение сущности	Ключ сущности и его обозначение	Атрибуты сущности и их обозначение
Учреждение (Учреждение)	Код учреждения (КодУч)	Наименование (НазвУч) Адрес (АдресУч) Телефон (ТелефонУч) Имя руководителя (ИмяРукУч) Должность руководителя (ДолжРукУч)
Подразделение (Подразделение)	Код подразделения (КодПд)	Наименование (НазвПд) Адрес (АдресПд) Телефон (ТелефонПд) Имя руководителя (ИмяРукПд) Должность руководителя (ДолжРукПд)
Отделение (Отделение)	Код отделения (КодОтд)	Наименование (НазвОтд)
Учетная запись (УчЗапись)	Код учетной записи (КодУЗ)	Имя входа (ИмяВхУЗ) Пароль (ПарольУЗ) Имя (ИмяУЗ) Фамилия (ФамУЗ) Отчество (ОтчУЗ) Электронная почта (ЭлПочтаУЗ) Телефон (ТелефонУЗ) Должность (ДолжУЗ) Место работы (МестоРабУЗ) Роль(РольУЗ)
Врач (Врач)	Код учетной записи (КодУЗ)	Специализация (СпецВр) Кабинет (КабВр)
Регистратор (Регистратор)	Код учетной записи (КодУЗ)
Администратор (Администратор)	Код учетной записи (КодУЗ)	Примечание (ПримАдм)
Расписание приема (Расписание)	Код интервала (КодИнт)	Дата (ДатаИнт) Время начала (ВрНачИнт) Время завершения (ВрЗавИнт)
Талон (Талон)	Код талона (КодТал)	Дата талона (ДатаТал) Время начала (ВрНачТал) Время завершения (ВрЗавТал) Статус регистратора (СтатРегТал) Статус пациента (СтатПацТал) Статус врача (СтатВрТал) Причина отказа (ПричОткТал)
Пациент (Пациент)	Код пациента (КодПац)	Имя (ИмяПац) Фамилия (ФамПац) Отчество (ОтчПац) Дата рождения (ДатаРождПац) Адрес (АдресПац) ОМС серия (ОМССерПац) ОМС номер (ОМСНомПац) ОМС компания (ОМСКомПац) Электронная почта (ЭлПочтаПац) Телефон (ТелефонПац)

Таким образом, схемы сущностей имеют вид:

Учреждение (КодУч, НазвУч, АдресУч, ТелефонУч, ИмяРукУч, ДолжРукУч).
Подразделение (КодПд, НазвПд, АдресПд, ТелефонПд, ИмяРукПд, ДолжРукПд).
Отделение (КодОтд, НазвОтд).
УчЗапись (КодУЗ, ИмяВхУЗ, ПарольУЗ, ИмяУЗ, ФамУЗ, ОтчУЗ, ЭлПочтаУЗ, ТелефонУЗ, ДолжУЗ, МестоРабУЗ, РольУЗ).
Врач (КодУЗ, СпецВр, КабВр).
Регистратор (КодУЗ).
Администратор (КодУЗ, ПримАдм).
Расписание (КодИнт, ДатаИнт, ВрНачИнт, ВрЗавИнт).
Талон (КодТал, ДатаТал, ВрНачТал, ВрЗавТал, СтатРегТал, СтатПацТал, СтатВрТал).
Пациент (КодПац, ИмяПац, ФамПац, ОтчПац, ДатаРождПац, АдресПац, ОМССерПац, ОМСНомПац, ОМСКомПац, ЭлПочтаПац, ТелефонПац).

Анализ сущностей позволяет выделить связи между ними. Перечень связей между сущностями представлен в таблице 2.2.

Таблица 2.2

Перечень связей между сущностями

Связь	Идентификатор
Подразделение ОТНОСИТСЯ к учреждению	Подразделение_ОТНОСИТСЯ_Учреждение
Отделение ОТНОСИТСЯ к подразделению	Отделение_ОТНОСИТСЯ_Подразделение
Регистратор РЕГИСТРИРУЕТ в подразделении	Регистратор_РЕГИСТРИРУЕТ_Подразделение
Врач РАБОТАЕТ в отделении	Врач_РАБОТАЕТ_Отделение
Врач ПРИНИМАЕТ по расписанию приема	Врач_ПРИНИМАЕТ_Расписание_приема
Врач ПРИНИМАЕТ по талону	Врач_ПРИНИМАЕТ_Талон
Пациент ЗАПИСАН по талону	Пациент_ЗАПИСАН_Талон
Администратор ИМЕЕТ учетную запись	Администратор_ИМЕЕТ_Учетная_запись
Регистратор ИМЕЕТ учетную запись	Регистратор_ИМЕЕТ_Учетная_запись
Врач ИМЕЕТ учетную запись	Врач_ИМЕЕТ_Учетная_запись

Диаграмма ER-типа для рассматриваемой предметной области показана на рис.2.1.

CDM

Рис.2.1. Диаграмма ER-типа

Реализация системы

Приложение пользователя предназначено для конечных пользователей (пациентов). Для начала работы с системой необходимо подключится к сети Интернет и ввести в поле ввода адреса любого браузера адрес http://www.health.ru (или http://localhost/health/index.php при использовании локальной версии).

После ввода соответствующего URL загружается главная страница.

Главная страница предоставляет доступ к системе «Электронная регистратура». Главная страница интерфейса пользователя представлена на рис.2.2.

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

Основные этапы записи на прием.

1. Выбор медицинского учреждения.
2. Выбор врача.
3. Просмотр расписания приема.
4. Запись на прием.
5. Печать талона.

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

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

Каждый пункт меню (шаг, этап) имеет три состояния: пройденный, текущий и следующий. Каждое состояние этапа выделено визуально и функционально. Пройденный этап является ссылкой и имеет соответствующую визуальную акциденцию – подчеркивание. Текущий шаг не является ссылкой и имеет самое яркое и контрастное цветовое решение. Следующие шаги неактивны и имеют приглушенный серый цвет.

Рис. 2.3. Основное пошаговое меню

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

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

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

Рис.2.4. Второй этап – выбор врача

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

Рис.2.5. Третий этап – просмотр расписания приема

Расписание приема представлено на ближайшие 2 недели: текущую и следующую. Таблица приема разделена по столбцам-дням и строкам – времени приема. Интервал приема – 15 минут. В ячейках таблицы применено цветовое кодирование по принципу «светофора», т.к. эта нотация общепринята и всем известна. «Зеленый цвет» – запись на прием возможна, «желтый свет» - прием возможен, но по «живой очереди» непосредственно в поликлинике, «красный цвет» - запись невозможна, т.к. талоном уже воспользовались (другой пациент записан на это время). Активными ссылками являются только метка «Свободно».

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

Рис.2.6. Четвертый этап – заполнение личных данных

Рис.2.7. Четвертый этап. Диагностируемые ошибки при заполнении формы

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

Рис. 2.8. Пятый этап – печать талона

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

Рис.2.9. Вид талона на печатном носителе

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

Тестирование системы

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

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

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

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

Так как в ходе экспериментальной проверки система правильно представляла содержимое выходных отчетов, то можно сделать вывод о корректном представлении основных выходных данных.

В результате тестирование ошибок обнаружено не было.

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

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

Заключение

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

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

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

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

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

Разработанная система обладает высокой степенью эффективности и максимально проста в использовании.

Список использованной литературы

Архангельский А.Я. Delphi 5. Справочное пособие. – М., ЗАО «Издательство «Бином», 2001
Дайитбегов Д.М., Черноусов Е.А. Основы алгоритмизации и алгоритмические языки (второе издание). – М.: Финансы и статистика, 1992
Дейт К. Введение в системы баз данных / Пер. с англ. - М.:Наука, 1980. -463с.
Джерк Н. Разработка приложений для электронной коммерции. Библиотека программиста. - СПб.: Питер, 2001.-512 с.
Иванова Г.С. Технологии программирования. Москва 2002. Издательство МГТУ им. Н.Э.Баумана.
Йодан Э. Структурное проектирование и конструирование программ. -, Мир, 1979
Кастаньетто Дж., Рават Х., Шуман С., Сколло К., Велиаф Д. Профессиональное PHP программирование. – Пер. с англ. – СПб:Символ-Плюс, 2001. – 912 с., ил.
Лэнгсам Й., Огенстайн М., Тененбаум А. Структуры данных для персональных ЭВМ. – М.: Мир, 1989
Матросов А.В., Сергеев А.О., Чаунин М.П. HTML 4.0. – СПб.: БВХ – Санкт-Петербург, 2000. – 672 с.
Фролов А.В., Фролов Г.В. Создание Web-приложений: Практическое руководство. – М.: Издательско-торговый дом «Русская редакция», 2001.-1040 с.
Фролов А.В.,Фролов Г.В. Базы данных в Интернете: практическое руководство по созданию Web-приложений с базами данных. М.: Издательско-торговый дом «Русская редакция», 2000.-765 с.

Хоумер А.,Улмен К. Dynamic HTML: справочник. – СПб.: Питер, 2000.-512 с.